Exchange 1018 error Event ID 116&200

[NETING]

I just started receiving this error on my 5.5 server.

MSExchangeIS (296) Synchronous read page checksum error -1018 ((1:3431997 1:4294967295) (4294967295-4294967295) (0-1065474177)) occurred. Please restore the databases from a previous backup.

It is event ID 116. The Category is Database Page Cache. The source is ESE97.
********************************************************8
It is always the same message. With the exception of this one which sometimes shows up as well.
MSExchangeIS (296) A read of the database file D:\exchsrvr\MDBDATA\PRIV.EDB between offsets 0x0000000345E3E000 and 0x0000000345E3EFFF failed after 16 failed read attempts with error -1018. There is a software or hardware problem affecting the database drive that must be corrected to preserve database integrity. Contact Microsoft Product Support Services.
For more information, search the Microsoft Knowledge Base at http: Event ID number.

The Source is ESE97. The Category is Database PageCache. The eventID is 200.

Again this is Exchange 5.5 on an NT server 4.0. All the latest serivce packs for server and for exchange are installed. Also, mail is currently working. The only thing is outbound messages hang in the outbound queue on the local clients for a few seconds more then normal. All and any insight would help as I am far from an Exchang eadministrator.

Thanks in advance.

 

[dennisbbb]

Hope this helps:

http://www.microsoft.com/exchange/techinfo/administration/55/1018.asp

Do an offline backup of the .edb files and start working with ESEfile untility.

http://support.microsoft.com/kb/248406

 

[NETING]

dennisbbb thanks for the fast response. Have you ran into this situation before?

 

[zbnet]

Remember, the ESEUTIL will have a go at fixing the errors in your database, but it won't remove the cause of the errors, which is usually something to do with the hardware, probably your raid disk controller. You need to find and fix the underlying problem, then you won't get any 1018s in the future.

Also, be careful with ESEUTIL - if you pick your options carelessly, you can end up with data loss.

 

[NETING]

zbnet...thanks...Is it true that I need the size of my information store times 2 in order to run the ESEUTIL?

 

[zbnet]

Depends on what options you select - you're thinking of the offline defrag, which writes a new copy of the store. If you're using ESEUTIL in check or fix mode, it isn't going to write a new copy of the database, which is why you can get data loss if you haven't got a backup and you don't like what it's done!

 

[NETING]

ZBNET thanks again. One final question. when i run the repair I will make sure to have an upto date image of the drive. Do you recommend running the utility in check or fix mode first?

 

[zbnet]

In this circumstance I don't recommend either - I would restore the last known good backup, and reply the transaction logs. ESEUTIL is for when all the other normal ways of dealing with store corruption are exhausted.

 

[NETING]

Thanks ZBNET...I take it you suggest to turnoff circular logging in order to replay the log files in future events...I actually ended by setting up another exchange in the same site and started moving mailboxes over to the new server. In the process, I moved half of my mailboxes (the more important ones) and now the 1018 errors are gone. The old exchange is now performing as good as new. The 2 servers are not splitting the load. It has now been about 5 days in it seems fine. Ever heard of this. I dont think it's a hardware issue...I did find a few mailboxes were approaching 2 GB..

 

[zbnet]

No one who cares about their data should be running circular logging on a production Exchange server - it's the first thing you turn off. Combined with nightly full online backups, and databases running on physically different drives to the transaction logs, this is the setup that means you have maximum protection for your users' precious email data.

You must have some hoarders if you have mailboxes as big as 2GB. Technically, there is no limit to the size of an individual mailbox - in theory, your entire store could be a single mailbox, which on Enterprise edition could be 16TB big!

1018s are almost always a hardware issue. Maybe the occurance of them has gone away because the overall load on the server has dropped since you moved some of the mailboxes. The errors might come back again if you just move the mailboxes back.