dbcc checkverify examines the results of the most recent checkstorage operation (by reading dbcc_faults) and reclassifies each soft fault as either a hard fault or an insignificant fault. checkverify acts as a second filter to remove spurious faults from the checkstorage results.
checkverify reports only the suspect faults, and resolves their issues or reports them as soft faults or as harmless using a procedure similar to the procedure used by the checkstorage operation. checkverify does not read hard faults because they already classified as hard by 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.
dbcc checkstorage(victimdb) Checking victimdb: Logical pagesize is 2048 bytes DBCC CHECKSTORAGE for database 'victimdb' sequence 1 completed at Jun 20 2013 1:32PM. 2 faults and 3 suspect conditions were located. 0 checks were aborted. You should investigate the recorded faults, and plan a course of action that will correct them. Suspect conditions are to be treated as faults if the same suspect condition persists in subsequent CHECKSTORAGE operations, or if they are also detected by other DBCC functions.
dbcc checkstorage(victimdb) Verifying faults for 'victimdb'. DBCC CHECKVERIFY for database 'victimdb' sequence 1 completed at Jun 20 2013 1:33PM. 3 suspect conditions considered, 3 identified as faults, 0 identified as harmless, and 0 could not be checked. 0 objects could not be checked.
The 3 suspect conditions considered listed in the output are the same 3 reported by checkstorage above. checkverify only verifies them, it does not fix them. If the faults were soft faults, they would not need fixing. However, all 3 suspect faults are identified as hard. The total number of hard faults is 5: 2 found in checkstorage + 3 that were upgraded from soft faults by checkverify
sp_dbcc_faultreport "short", "victimdb" Database Name : victimdb Table Name Index PartitionId Fault Type Page Number ------------ ------- ----------------- ------------------------- ----- ALLOCATION 0 99 100030 (page format error) 768 foo 0 624002223 100017 (OAM ring error) 864 foo 0 624002223 100022 (chain start error) 865 foo 0 624002223 100031 (page not allocated) 864 foo 0 624002223 100031 (page not allocated) 865
A hard fault classified as such by checkstorage.
A soft fault reclassified as hard by checkverify because concurrent activity was ruled out as the cause.
A soft fault confirmed to be soft by checkverify. Some soft faults that appear when there is no concurrent activity in the database do not represent a significant hazard and are not reclassified as hard. A soft fault is not reclassified if it is informational only and not a corruption.
A soft fault reclassified as insignificant because it can be attributed to concurrent activity or because subsequent activity masked the original inconsistency.
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.
100020 – check aborted.
100025 – row count fault.
100028 – page allocation off current segment.