DBCC CHECKDB and tempdb

As we know, dbcc checkdb is one of the very important tools to detect and possibly repair corruption of the database. However as I discussed earlier, from 2005 onwards, dbcc checkdb depends on database snapshot (Please refer to http://blog.consultdba.com/2010/04/impact-of-executing-dbcc-checkdb-on.html if you are interested) instead of actual database. So the million dollar question is what happens when (if at all we need to do this) we run checkdb on tempdb and if at all we need to run checkdb on tempdb?

If you execute dbcc checkdb on tempdb, you actually get an error first which is followed by other printed statements and final result. Let us see an example from a SQL 2005 server:

dbcc checkdb (tempdb)

Output (This output is trimmed as all unneeded printed  messages are removed in the section highlighted in yellow):

DBCC results for 'tempdb'.

DBCC CHECKDB will not check SQL Server catalog or Service Broker consistency because a database snapshot could not be created or because WITH TABLOCK was specified.

DBCC results for 'sys.sysrowsetcolumns'.

There are 544 rows in 5 pages for object "sys.sysrowsetcolumns".

.

.

. – Other printed statements

.

.

CHECKDB found 0 allocation errors and 0 consistency errors in database 'tempdb'.

DBCC execution completed. If DBCC printed error messages, contact your system administrator.

This error is thrown because of the behavior of Tempdb with ability to recover the database on restart. You cannot create a database snapshot on the Tempdb database and hence checkdb throws this error. Under the hood, checkdb also can not execute CHECKCATALOG or service broaker check too. If you execute DBCC CHECKCATALOG independently on tempdb, you get below message:

DBCC CHECKCATALOG (tempDB)

Output:

The check statement was aborted. DBCC CHECKCATALOG cannot be run on TEMPDB.

DBCC execution completed. If DBCC printed error messages, contact your system administrator.

So to conclude, you really do not need to execute checkdb on tempdb. If in an unlikely situation you face corruption with tempdb, a restart of SQL Service will fix this issue as a new tempdb will be created. However it is strongly advised to know the root cause of corruption before it amplifies to a major issue.