How dbcc checkverify works

checkverify reads the recorded faults from dbcc_faults and resolves each soft fault through a procedure similar to that used by the checkstorage operation.

Notecheckverify locks the table against concurrent updates, which ensures that the soft faults are reclassified correctly. checkverify does not find errors that have occurred since the last run of checkstorage.

checkverify records information in the dbcc_operation_log and dbcc_operation_results tables the same way that checkstorage does. The recorded value of opid is the same as the opid of the last checkstorage operation. checkverify updates the status column in the dbcc_faults table and inserts a row in the dbcc_fault_params table for the faults it processes.

checkverify does not use the scan or text workspaces.

Each fault found by checkstorage is verified by checkverify as one of the following:

A fault that is assigned code 100011 (text pointer fault) by checkstorage is verified as hard if the text column has a hard fault. If it does not, it is reclassified as soft.

A fault that is assigned code 100016 (page allocated but not linked) by checkstorage is verified as hard if the same fault appears in two successive checkstorage operations. Otherwise, it is reclassified as soft.

When a fault that is assigned code 100035 (spacebits mismatch) by checkstorage is verified as hard, you can repair it by using dbcc checktable.

When checkverify confirms hard faults in your database, follow the appropriate procedures to correct the faults.

checkverify classifies the following fault codes as soft faults: