Sql-server – dbcc checktable will write in the dbcc page (x,9,3) for the field dbi_dbccLastKnownGood

Realizing this situation is long over I'm still going to put in my 2 cents for anyone else finding themselves in a similar situation.

1. You have a fair amount of corruption in that table. Run a DBCC CHECKDB on the database ASAP.
2. I hope you have a good & recent backup. That's going to be your best bet for recovery.

3. If you don't have a recent backup then you have a number of lesser possibilities.

   • Use the dreaded repair_allow_data_loss. This is your LAST option for a reason. It can and probably will cause you to lose some data. And by some it could be one column of one row all the way up to .. well .. all of it. And you won't have any idea how much was lost.
   • Create a new database with the same structures and use something like SSIS to copy the data across. Still probably going to lose data here.

Regardless, if you have the time I would look over the answers given in Steve Stedman's Database Corruption Challenge. He posted corrupt databases and various people posted their solutions to fixing them. These solutions range from the normal (as above) to some interesting and unusual solutions. One or more of them may work for you and let you salvage your database without data loss.

Also, and this is important too, if you have a corrupted database it's probably corrupt for a reason. Check your IO substructure etc to make sure there isn't a problem there. And also check the other databases on that instance with CHECKDB to make sure you don't have additional problems.

Last but not least. You should be running regular backups, testing them, and running regular CHECKDBs on all databases for situations exactly like this. The sooner you understand you have a problem the better chance of fixing it without loss. Not to mention having good, recoverable backups just in case.

Are these additional checks necessary/important? (Indexed views are probably a bit more concerning to me, I don't think we are using Service Broker or FILESTREAM yet.)

You can run DBCC CHECKTABLE WITH EXTENDED_LOGICAL_CHECKS directly on the indexed views. Checking indexed views can be problematic in certain circumstances, so be prepared to investigate any false positives that result. (Paul Randal also mentions in the comments to the referenced article that false negatives are also possible, but I have no direct experience of that.)

If so, are there ways to perform these additional checks separately?

There's no support for running the Service Broker or FILESTREAM checks separately, no.

CHECKALLOC and CHECKCATALOG seem to run very quickly, even on large dbs. Any reason not to run these every day?

Not that I am aware of.

---

You might also consider running DBCC CHECKCONSTRAINTS. This check is not included in DBCC CHECKDB, regardless of any options you may specify. You may also want to think about occasionally running CHECKDB, as and when circumstances permit.