Event ID 399- Database Page Cache
Hi guys For the past 2 weeks I have been gettting the Event ID above daily, sometimes twice, on one of my 6 Production Mailbox Servers (12 servers in total, Active Passive configuration) . It suggests to me that the Database in question has a problem, but seeing as there is no such thing as downtime in my environment I need an alternative means on repairing this than eseutil /r. I am tempted to create another Storage Group and migrate all users onto it, then ditch or repair the old one. We are talking about migrating 600 users off the DB but I cannot think of another option. Does anyone have experience of dealing with this type of event and could provide some insight as to how they approached it? Any help appreciated. Tom Below is excerpt of the details of the event: ""MSExchangeIS (7176) SG14: The database page read from the file "G:\SG14\db\EXMBX03SG14.edb" at offset 141399474176 (0x00000020ec10c000) (database page 17260677 (0x1076085)) for 8192 (0x00002000) bytes failed verification. Bit 7712 was corrupted and has been corrected. This could be a precursor to catastrophic failure in the storage sub-system"". p.s. We have 28 storage groups per server, across 6 Production servers, 4 Storage Groups per SAN LUN, so I would be surprised if the storage was actually the problem, considering the other 3 Databases are not reporting issues. However, this storage group Database is 150GB in size, the others on its LUN are about 50GB.
February 24th, 2010 11:41am
I would probably do exactly as you meantioned and create a new store and move the users then delete the old store. There is something wrong with it, and better to ditch it than fight it.Lots less down time moving a mailbox than running eseutil against it.
Free Windows Admin Tool Kit Click here and download it now
February 24th, 2010 1:10pm
We can see in the event that the Exchange Database Engine has detected a Page Level Corruption (References: KB 867626)
“Damage at the page level is typically caused by driver, firmware, or hardware issues, although page-level damage might also be caused by problems in Exchange”
-------------Refer to <Understanding and analyzing -1018, -1019, and -1022 Exchange database errors>
As you said, the issue doesn’t happen to other SGs on the same LUN, the cause is possible on the exchange. You may refer the reference above to repair the database, or move the data to a new database, it’s a good plan as Martin saidJames Luo TechNet Subscriber Support (http://technet.microsoft.com/en-us/subscriptions/ms788697.aspx) If you have any feedback on our support, please contact tngfb@microsoft.com
February 25th, 2010 6:08am
I would probably do exactly as you meantioned and create a new store and move the users then delete the old store. There is something wrong with it, and better to ditch it than fight it.Lots less down time moving a mailbox than running eseutil against it.
I'd also run hardware level diagnostics on the underlying storage array.Active Directory, 4th Edition - www.briandesmond.com/ad4/
Free Windows Admin Tool Kit Click here and download it now
February 25th, 2010 11:32pm
Indeed. Something bad is happening in the
background at the HW level.
"Brian Desmond -MVP-" wrote in message news:dacdbcff-cdd2-443f-9e66-02b9e504a729...
I would probably do exactly as you meantioned and create a new
store and move the users then delete the old store. There is something wrong
with it, and better to ditch it than fight it.Lots less down time
moving a mailbox than running eseutil against it.I'd
also run hardware level diagnostics on the underlying storage array.
Active Directory, 4th Edition -
www.briandesmond.com/ad4/
February 28th, 2010 3:24am
Hi,like everyone told move would be the better option then repairing database, since the dataabse size is 150 GB it would take days to comlete repair, defrag and isinteg.Hari
Free Windows Admin Tool Kit Click here and download it now
February 28th, 2010 10:58am