SQL: Do I Still Need to Run DBCC CHECKDB?

SQL: Do I Still Need to Run DBCC CHECKDB?

In short: YES

(In contradiction to Betteridge’s Law of Headlines)

Every now and then, customers ask me if they really need to run DBCC CHECKDB. There was even a question that came up about this on a private mailing list full of people who really should already understand why. There is no mystery here.

DBCC CHECKDB checks the database for physical readability (are the pages intact and can they be read from the I/O system). This makes people wonder that if the I/O subsystem is already doing this, why does SQL Server need to do this?

Importantly, DBCC CHECKDB checks for logical consistency as well.

That’s incredibly important.

SQL Server is a fabulous database but it has no way of coping with internal structures that are messed up. For example, links on pages to other pages, but now pointing to the wrong pages.

Fortunately, because SQL Server is such a good database, having to deal with logical corruption caused by the database engine messing up is a truly rare event. That could happen though if there was a serious bug in SQL Server.

But even if SQL Server is perfect, it could be led astray. A good example would be a multi-path I/O system. Imagine this scenario:

  • The database has two paths to the I/O subsystem (multi-path I/O)
  • It writes a page out one path
  • It reads the same page from the other path
  • The I/O subsystem returns an older version of the page from its cache, not the one that was just written

That sort of thing could easily lead to internal corruption of the database. So could issues with your memory subsystem.

Fortunately, the SQL Server team again have your back. It is designed to help to detect some of these issues too. It probably can’t fix them but it might help to find them. For example, in the multi-path I/O problem mentioned above, SQL Server keeps a list of checksums of recently-written pages. If it reads one of those pages and it gets a page with a valid checksum but a different checksum to the one that it recently wrote, it lets you know that something went very wrong.

Even cleverness like this though isn’t going to help if the culprit is the storage subsystem having a cache bug, and so on, and so on.

Finally, DBCC CHECKDB is so important because it lets you find issues quickly. Otherwise, the logical problem would get much, much worse and be difficult, if not impossible to correct. You don’t want to be the DBA who has a large number of backups but every one of them has the same corrupted data.

2018-01-22