Fix SQL Database Cyclic Redundancy (CRC) Error

Encountered error: Msg 823, Level 24, State 2, Line 1

I/O error 23(Data error (cyclic redundancy check).) detected during read at offset 0x000001ac1c4000 in file ‘C:\Program Files\Microsoft SQL Server\MSSQL13.SQL2K16\MSSQL\DATA\MoreData.mdf’.

Did you know SQL Server operations are highly dependent on the disk subsystem? It is without doubt that a key component to SQL Server performance and availability is storage. In this article, we are going to address the issue of SQL Server encountering the Cyclic Redundancy Check (CRC) data error during normal operations. Below is an example of scenarios where users or the SQL Server can possibly encounter the CRC data error:

  • Backup and restore of the database
  • Querying the database
  • Starting SQL Server

So, what is CRC?

Before we jump into identifying the root cause for this error and a solution, let us first get a good grasp on what cyclic redundancy check means. A cyclic redundancy check (CRC) is a data verification algorithm that computers use to check the data on storage devices like SSD, HDD, CDs, Magnetic tapes, and more.

The causes of a cyclic redundancy check error can be of any of the following:

  • Registry Corruption
  • Cluttered hard disk
  • Unsuccessful program installation
  • Misconfigured files
  • File written on bad sector of hard disk

Regardless of the specific cause, the cyclic redundancy check error is a serious one and must be addressed immediately to avoid potential data loss or even total system failure.

How to identify the error?

Let’s look at the following two scenarios of the Cyclic Redundancy Check error:
Scenario 1 is when you encounter the error during the backup of a database. The next scenario is when you are querying the SQL database and it stops abruptly with the data check error.

When you encounter the error during a backup, you can revisit the SQL Server error logs to get more details on the error.

SQL Server Error Log

Example of verbose log is shown below:

10/18/2016 12:00:19 AM Creating backup of MoreData to C:\Program Files\Microsoft SQL Server\MSSQL13.SQL2K16\MSSQL\Backup\
10/18/2016 12:00:32 AM ERROR: Read on “C:\Program Files\Microsoft SQL Server\MSSQL13.SQL2K16\MSSQL\DATA\MoreData.MDF” failed: 23(Data error (cyclic redundancy check).)
BACKUP DATABASE is terminating abnormally.
10/18/2016 12:00:32 AM ERROR: Job finished (With Errors)

When Querying the database, you will receive the error on SQL Server Management Studio (SSMS) error pane.

Server: Msg 823, Level 24, State 2, Line 1
I/O error 23(Data error (cyclic redundancy check).) detected during read at offset 0x000001ac1c4000 in file ‘C:\Program Files\Microsoft SQL Server\MSSQL13.SQL2K16\MSSQL\DATA\MoreData.mdf’.

How to fix CRC error

Since the root cause is an I/O subsystem issue, it is important to fix the underlying storage issues and that in turn would most likely fix the cyclic redundancy check error in SQL. You will need to perform a “chkdsk” command on the disk in question and allow it to fix any error by using the /F parameter.

Below is a screenshot of the command to check and fix the F: drive.

A complete disk defragmentation is recommended after the “chkdsk” is completed with a successful repair of any errors.

Next, you will need to perform a data integrity check on the database to make sure there are no data corruptions present. Run the command as highlighted below and analyze the results.

In this case, the check detected 2 allocation errors and 1 consistency error

Server: Msg 8946, Level 16, State 12, Line 2
Table error: Allocation page (1:72864) has invalid PFS_PAGE page header values. Type is 0. Check type, object ID and page ID on the page.
Server: Msg 8921, Level 16, State 1, Line 1
CHECKTABLE terminated. A failure was detected while collecting facts. Possibly tempdb out of space or a system table is inconsistent. Check previous errors.
Server: Msg 8966, Level 16, State 1, Line 1
Could not read and latch page (1:72864) with latch type UP. failed.
Server: Msg 8966, Level 16, State 1, Line 1
Could not read and latch page (1:72864) with latch type UP. failed.
Server: Msg 8998, Level 16, State 1, Line 1
Page errors on the GAM, SGAM, or PFS pages do not allow CHECKALLOC to verify database ID 8 pages from (1:72864) to (1:80879). See other errors for cause.
CHECKDB found 2 allocation errors and 1 consistency errors not associated with any single object.
CHECKDB found 2 allocation errors and 1 consistency errors in database ‘MoreData’

At this point, we are facing database corruption, and our options are to either restore from a good known backup or repair the database either by using SQL native repair commands or third-party tools. If we are using a backup, it is highly recommended to perform a RESTORE VERIFYONLY on the backup file to know if the backup is in a consistent state.

If the restore does not come out clean, then we are running out of options and would need to start looking into repairing the database. We can attempt to repair the database by using the DBCC CHECKDB with REPAIR OPTION. This method is not guaranteed and there is a high risk of data loss during the repair that cannot be measured or accessed during the process.

Conclusion

So, there you have it! If you have a good disaster recovery plan setup, then you should have no problems when your production database or any other database gets corrupted. Now let’s say you find yourself in a situation where a proper DR plan was not established and do not have any backups to restore. You can consider utilizing the minimal repair level reported by the DBCC CHECKDB when you run the integrity check on the suspect database.

Remember that the repair feature of SQL Server is not robust and not a guaranteed solution. For a faster, more versatile repair that would bring your SQL corrupt database back into a working start with minimal data loss, look no further than Stellar Database repair tool. It repairs the database faster by using a more sophisticated repair algorithm. It even can recover deleted data in your database. Click on link to learn more.

Comments(2)
  1. shirley Rice August 26, 2019
    • Eric Simson August 28, 2019

Leave a Reply

Your email address will not be published. Required fields are marked *

Time limit is exhausted. Please reload CAPTCHA.