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.
”
https://connect.microsoft.com/SQLServer/feedback/details/350596/
Adding when DBCC CHECKDB last ran to the SYS.DATABASES catalog view
Description
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),
ParentObject VARCHAR(255),
[Object] VARCHAR(255),
Field VARCHAR(255),
[Value] VARCHAR(255)
)
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
DROPTABLE #temp
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.
thanks
Sunil”
Conclusion:
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.)
