The limited update activity in the dbccdb tables should make corruption less frequent. Two signs of corruption in dbccdb are:
Failure of dbcc checkstorage during the initialization phase, as it evaluates the work that needs to be performed, or during the completion phase, when it records its results
Loss of information about faults resulting from corruption in the recorded faults, found by dbcc checkstorage
A severe corruption in dbccdb may cause dbcc checkstorage to fail. For dbcc checkstorage to locate severe corruptions in dbccdb, you can create an alternate database, dbccalt, which you use only for checking dbccdb. Create dbccalt using the same process that you used to create dbccdb as described in “Preparing to use dbcc checkstorage”.
If no free devices are available for dbccalt, you can use any device that is not used by the master database or dbccdb.
dbcc checkstorage and the dbcc system procedures function the same with dbccalt as they do with dbccdb. When the target database is dbccdb, dbcc checkstorage uses dbccalt, if it exists. If dbccalt does not exist, dbccdb can be checked using itself as the management database. If the target database is dbccdb and dbccalt exists, the results of dbcc checkstoragez operations on dbccdb are stored in dbccalt. If dbccalt does not exist, the results are stored in dbccdb itself.
Alternatively, dbcc checkalloc and dbcc checktable can be used to check dbccdb.
If dbccdb becomes corrupted, you can drop it and re-create it or load an older version from a backup. If you drop it, some of its diagnostic history is lost.
