Hi all! :)

We've seen a couple of these problems on one of our databases on a standalone server lately.
We had to do a repair and a dial-tone restore to get the customer up and running.

Information Store - MDB01 (9508) MDB01: The database page read from the file "E:\MDB01\MDB01.edb" at offset 282648936448 (0x00000041cf308000) (database page 8625760 (0x839E60)) for 32768 (0x00008000) bytes failed verification because it contains no page data.  The read operation will fail with error -1019 (0xfffffc05).  If this condition persists then please restore the database from a previous backup. This problem is likely due to faulty hardware. Please contact your hardware vendor for further assistance diagnosing the problem. 

Will this kind of corruption replicate between the servers in a DAG, or would a lagged DAG avoid this kinds of problems?

Cheers

Rolf

Hi all! :)

We've seen a couple of these problems on one of our databases on a standalone server lately.
We had to do a repair and a dial-tone restore to get the customer up and running.

Information Store - MDB01 (9508) MDB01: The database page read from the file "E:\MDB01\MDB01.edb" at offset 282648936448 (0x00000041cf308000) (database page 8625760 (0x839E60)) for 32768 (0x00008000) bytes failed verification because it contains no page data.  The read operation will fail with error -1019 (0xfffffc05).  If this condition persists then please restore the database from a previous backup. This problem is likely due to faulty hardware. Please contact your hardware vendor for further assistance diagnosing the problem. 

Will this kind of corruption replicate between the servers in a DAG, or would a lagged DAG avoid this kinds of problems?

Cheers

Rolf

Only logical errors within the database *could* possibly be replicated, not errors caused by hardware issues. The hardware issues still need to be fixed of course.

A lagged copy wont avoid the problem, but could help if you wanted to go w/o backups and have the ability to recover. 

Thanks for your reply Andy!

Okay, so in this case with the logical errors the only benefit with lagged DAG may be that you get a couple of hours head start, but we are still not guaranteed the logical error also will be replicated.

I will then suggest a non-lagged DAG, and daily full backup with incremental every other hour or so, so the time to getting things back up will be as short as possible. 

Thanks for your reply Andy!

Okay, so in this case with the logical errors the only benefit with lagged DAG may be that you get a couple of hours head start, but we are still not guaranteed the logical error also will be replicated.

I will then suggest a non-lagged DAG, and daily full backup with incremental every other hour or so, so the time to getting things back up will be as short as possible. 

Yea, the idea being there of course that if you discover the error, you can then activate and mount the lagged copy and replay the logs up to the point of the logical issue. Having said that, logical issues that would cause a corruption of the database are pretty rare now if at all. At Ignite, the Microsoft Engineers mentioned that Office 365 has had to activate a lagged copy only a few times and only for recovery purposes of lost email. not due to a corruption issue.

Great info from Andy, and apologies if I am stating that obvious however the 1019 issues wont just go away on their own.  That server has some type of serious issue going on that needs to be resolved immediately.  99% of the time in my experience its something to do with the Storage the server is using however it can also be caused by a bad motherboard, memory, firmware etc.   Also you mentioned doing a backup every other hour and I hope your doing that on an alternate server not the one with the 1019 since doing that will just exacerbate the issue since it will put the disk system under pressure and if that's where the issue is then the DB will just become more and more corrupt.

Hi,

As above mentioned, daily full backup with incremental every other hour might be a great solution.
Event 476 is always associated with a -1019 error in the Description section of the event. Error -1019 = 0xfffffc05 = Jet_errPageNotInitialized = Blank database page.
Error -1019 is reported when a page that is expected to be in use is not initialized or empty. If the page number field on a page in use is 0x00000000, a -1019 error is reported instead of a -1018 error, even though the page might also fail its checksum test.
A -1019 error may be caused because the file system was corrupted or it mapped pages into the database file that do not belong in the file.
A -1019 error may also be caused by Exchange if logical pointers or links between pages are inaccurate.

To solve this issue, please do one or more of the following:
1. Run system diagnostic tests. These tests may not be conclusive if the problem is infrequent and transient or only appears under very complex loads.
2. Consider migrating to different hardware.
3. Upgrade disk controller BIOS and firmware to the latest vendor revisions.
4. Repair the database by using the eseutil /p command, run eseutil /d, and then run isinteg -fix.
More details about 1019 error message, please refer to Understanding and analyzing -1018, -1019, and -1022 Exchange database errors.

Thanks

-1019 is physical corruption, not logical corruption. There's no danger in it logically corrupting your database, and this isn't a good justification for taking extra backups. The database copy will be page patched, and the it will even become healthy. If it is happening a lot, there is probably a hardware issue that needs attention.