Summary: In this blog, we are going to discuss SQL Database Cyclic Redundancy Check (CRC) error. Also, we will discuss the possible reasons behind the error, and scenarios in which you can encounter the CRC error. Plus, we will look at a few solutions to fix SQL CRC error. You may also try Stellar Repair for MS SQL software to repair and restore your SQL database in a few simple steps, without having to spend several hundreds of man-hours and IT resources.
SQL Server operations are highly dependent on the disk subsystem. It is without a doubt a key component to SQL Server performance and availability as storage. Sometimes, an issue with the I/O subsystem can lead to Cyclic Redundancy Check (CRC) error. The error message reads as:
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’.
You may encounter CRC data error in SQL database when performing any of these actions:
- Backup and restoring of the database
- Querying the database
- Starting SQL Server
Before we jump into identifying the root cause for this error and find its solution, let us first understand what does cyclic redundancy check means.
What is CRC?
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.
What Causes Cyclic Redundancy Check Error in SQL Database?
SQL cyclic redundancy check error may occur due to any of these reasons:
- 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 error and must be addressed immediately to avoid potential data loss or even total system failure.
Occurrences of SQL CRC Error
Following are two scenarios in which you may encounter the CRC error:
Scenario 1: You may get the error when backing up a database. When you encounter the error during a backup, you can revisit the SQL Server error logs to get more details on the error.
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)
Scenario 2: The next scenario is when you are querying the SQL database and it stops abruptly with the data check error. When querying the database, you will receive CRC error on SQL Server Management Studio (SSMS) error pane. The error message reads as:
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 SQL CRC Error?
Follow the steps in the sequence given below to resolve the error:
Step 1: Since the root cause behind the CRC error is an I/O subsystem issue, it is important to fix the underlying storage issues. That, in turn, would most likely fix the cyclic redundancy check error in SQL.
Run the CHKDSK utility 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:
Step 2: A complete disk defragmentation is recommended after the “chkdsk” is completed with a successful repair of any errors.
Step 3: Perform a data integrity check on the SQL database to make sure that data is not corrupt. Run the command as highlighted below and analyze the results:
DBCC CHECKDB (MoreData) WITH NO_INFOMSGS, ALL_ERRORMSGS
Running the above command, detected 2 allocation errors and 1 consistency error as shown below:
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’
Step 4: At this point, we are facing database corruption, and our options are to either restore the most recent backup or repair the database either by using SQL native repair commands or third-party tools. Now let’s look at both these options:
Restore database from Clean Backup
When trying to restore the db from backup, it is highly recommended to perform a RESTORE VERIFYONLY on the backup file to know if the backup is in a consistent state.
RESTORE VERIFYONLY FROM DISK = C:\BackupFile\MoreData.BAK GO
Repair the Corrupt SQL database
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 SQL database by using the DBCC CHECKDB with REPAIR OPTION.
For detailed information on DBCC CHECKDB, read this: How to Repair SQL Database using DBCC CHECKDB Command
Try repairing the db with DBCC CHECKDB ‘Repair_Allow_Data_Loss’ option by running the following code:
USE master;
ALTER DATABASE [CorruptDB] SET SINGLE_USER WITH ROLLBACK IMMEDIATE;
GO
DBCC CHECKDB ('CorruptDB', REPAIR_ALLOW_DATA_LOSS) WITH NO_INFOMSGS;
GO
ALTER DATABASE [CorruptDB] SET MULTI_USER;
GO
What If DBCC CHECKDB Fails to Repair SQL Database?
Repairing the database using the DBCC CHECKDB with ‘Repair_Allow_Data_Loss’ involves data loss risk during the repair process. It may also not deliver expected results. Use Stellar Database repair tool to fix a corrupt SQL database. The tool serves as the best Alternative of DBCC CHECKDB Repair Allow Data Loss that helps repair a SQL database from all types of common SQL database corruption errors. It repairs corrupt MDF and NDF files and restores all the database objects. Also, it helps restore the database back to its original state without any risk of data loss.
Essentially, the software helps repair corrupt SQL Server database (.mdf and .ndf) files, while maintaining the original structure and integrity of database objects.
Conclusion
So, there you have it! If you have a good disaster recovery plan set up, then you should have no problems when your production database or any other database gets corrupted due to SQL Database Cyclic Redundancy Check (CRC) error. Now let’s say you find yourself in a situation where a proper DR plan was not established and you 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 Repair for MS SQL software. It repairs the database faster by using a more sophisticated repair algorithm. It can even recover deleted data in your database.
