SQLTeam.com | Weblogs | Forums

SQL Server 2008 R2



I am using SQL Server 2008 R2
Everything was running fine until it recently stopped running for no real apparent reason. The error message occurs: Sql Server Detected A Logical Consistency-Based I/O Error: Incorrect Checksum. (Microsoft SQL Server, Error:824)
Is there something a way to fix SQL Server?

  1. There should be more details in the SQL Server error log.
  2. You need to run DBCC CHECKDB on the db in question.
  3. You may have to risk loss of data in order to repair the db; SQL will "tell" you whether you or not. If the damaged data is in nonclustered indexes, you can safely drop and recreate the index(es).


Restore from backup.

If your database is FULL Recovery Model then make a TAIL Log Backup first.

Make a trial restore to a different server. If you are using FULL and have all the Log backups since the last Full backup then the chances are high that you will have zero data loss. If this has been going on for a while then you may have to go back to an earlier FULL backup (and restore many more Log backup files!)

Either way, find what caused the problem first (duff memory or disk controller) and get that fixed - otherwise its just going to happen again.

Suggest you post whatever messages you get from DBCC CHECKDB so folk here can make suggestions.



SQL logical consistency based i/o error means that the page has been read successfully from the disk, but there is a problem with the page. You might also face ‘fatal error’ in the SQL Server error log or the Windows application event log.
This error come as the Windows API call successfully, but the data transferred during that have logical consistency errors. You may have a look here to solve this issue: http://sqltechtips.blogspot.in/2015/11/troubleshooting-error-824.html

Hope this works for you.


Below links with information that may help you resolve this issue:


That's the solution to someone else's, similar, problem - I think it would be better to try to solve this user's problem directly. For example, in the linked thread that user has, as pretty much the first step, used a command to repair the data - with probable data loss - which is definitely worth avoiding, at least initially.

I take the view with data corruption like this that if it is mission critical the O/P will be back with a progress report straight away ... that hasn't happened in this thread so its either been solved somehow, or is not mission critical, or other help elsewhere is proving more useful that ours :slight_smile: