Brent Ozar is hosting TSQL2sDay #86 this month and in response to Brent Ozar’s Call for Important Connect Items I wanted to highlight this one about adding the date of the last known good DBCC CHECKDB to SYS.DATABASES. This one seems like a no-brainer to me. When you NEED this information, you don’t want to have to go hunting for it, and ever Microsoft agreed:
“Posted by Sunil [MSFT] on 8/20/2008 at 11:05 AM
This issue has been approved/fixed and should be available in a future release of SQL Server. Thanks for providing us your feedback to SQL Server.
Adding when DBCC CHECKDB last ran to the SYS.DATABASES catalog view
Currently it is not easy to determine when DBCC CHECKDB last ran successfully on a database. Of if you like when it last ran and the state value of that execution in the case of a failure. (The state values that are discussed in BOL at http://msdn.microsoft.com/en-us/library/ms176064.aspx)
Sure the information is written to the error log.
You can also examine the dbi_dbccLastKnownGood value in page 9 of the database.
But it should be easier to get this critical information.
The Good News:
The good news is that someone
Sankar Reddy figured out an easy way how to do it and posted their query in the comments on the Connect Item:
CREATE TABLE #temp
( Id INTIDENTITY(1,1),
INSERT INTO #temp
EXECUTE SP_MSFOREACHDB‘DBCC DBINFO ( ”?”) WITH TABLERESULTS’;
;WITH CHECKDB1 AS
SELECT [Value], ROW_NUMBER() OVER (ORDER BY ID) AS rn1 FROM #temp WHERE Field IN(‘dbi_dbname’))
,CHECKDB2 AS (SELECT [Value], ROW_NUMBER() OVER (ORDER BY ID) AS rn2 FROM #temp WHERE Field IN (‘dbi_dbccLastKnownGood’))
SELECT CHECKDB1.Value AS DatabaseName
, CHECKDB2.Value AS LastRanDBCCCHECKDB
FROM CHECKDB1 JOIN CHECKDB2
ON rn1 = rn2
The Bad News:
Unfortunately, since someone had come up with a work-around, an engineer at Microsoft thought that was good enough and decided not to give customers easy access to critical information.
“Sankar: sorry for the late response. While the suggestion is useful, but there is a work-around like the one you had suggested, For this reason, we don’t plan to fix it. I am closing this.
This item is not “Fixed”, at best it’s “Patched” thanks to a work-around someone offered up, but as Shane points out in the comments below, this work-around doesn’t even work for the largest customers. It’s pretty obvious what needs to be done here, this item need to be re-opened and the column needs to be added to SYS.DATABASES.
Additionally, in the future, if you have a work-around for a Connect item that has been approved to be fixed, go ahead and blog about it & tweet about it, share it all over the place, but whatever you do, please don’t mention it on the Connect item itself!
(For the record: It pains me to have added that last sentence. I know the SQL engineers at Microsoft work hard to bring us great things, but the comments on this Connect item left me no other reasonable expectation of the potential outcome.)
It’s not a great workaround though if you split out your DBCC CHECKDB into the separate checks to deal with very large databases and time constraints (CHECKALLOC, CHECKCATALOG, etc).
If you do that, based on Arun’s blog post here (https://blobeater.blog/2017/01/03/checking-dbcc-checkdb/) then that DBCC INFO value doesn’t get updated.
So I would say that it’s not even a complete workaround and I’ve voted 🙂
Thanks for the comment. You make a really great point and I didn’t realize that the solution wouldn’t work for everyone. I will update the post with that!