0

Why is that when a single disk fails from a RAID 6 setup MS SQL 2014 database corrupts with the following error:

DESCRIPTION: SQL Server detected a logical consistency-based I/O error: torn page (expected signature: 0x55555555; actual signature: 0xad191b0d). It occurred during a read of page (1:144366313) in database ID 19 at offset 0x0001135b5d2000 in file 'D:\MSSQL12.LIST133\MSSQL\DATA\test.mdf'. Additional messages in the SQL Server error log or system event log may provide more detail. This is a severe error condition that threatens database integrity and must be corrected immediately. Complete a full database consistency check (DBCC CHECKDB). This error can be caused by many factors; for more information, see SQL Server Books Online.

The RAID 6 status is healthy and hasn't change even with one disk failed (the issue should appear when 3 DISKs fail). How does the SQL knows what is going on with the DISK since it is not a software RAID 6? There is a seperate controller and a storage. Also what is the point of having spare disks in the RAID if the SQL is going to corrupt anyway? How can I avoid this?

3
  • That error tell you that the disk subsystem returned something else that what SQL server earlier told it to write. So apparently the disk subsystem doesn't handle the loss os a disk correctly. Also, I agree that CHECKSUM should be used instead of the much weaker torn page detection. – Tibor Karaszi Jan 19 at 12:52
  • If the disk subsystem is reporting a healthy status, it's not telling the truth. SQL Server isn't aware of the RAID implementation and only reports the corruption it sees after reading data. – Dan Guzman Jan 19 at 13:11
  • RAID 5 or 6 are inadequate for database storage, because they are usually used without any read checksum control, this type of control is wasting time to execute, Then many manufacturers or system ingeneers does not set it to verify the checksum... – SQLpro Jan 19 at 13:17
1

Firstly you should change your database page verification setting from tornpage to checksum to have more reliable identification of database corruption.

secondly SQL Server has detected an I/O error - not surprising if an entire disk failed (or was removed while you tested your test db). - Anyway you won't know if the database is corrupt until you complete the recommended action - DBCC CHECKDB

1
  • 1
    NOTE: you must rebuild (well everything) to make it use the CHECKSUM after you make the switch... all the data must be rewritten... otherwise only pages that are written after you make the switch will use CHECKSUM. – Jonathan Fite Jan 19 at 13:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy