DBCC--CHECKDB

DBCC CHECKDB:

1.检查数据库是否有损坏

2.尽可能修复数据库损坏，是数据能重新被访问

 

DBCC CHECKDB执行流程

1.检查关键系统表

2.对数据库运行DBCC CHECKALLOC

3.对数据库中每个表或试图运行DBCC CHECKTABLE

4.对数据库运行DBCC CHECKCATLOG

5.验证数据库中每个索引试图的内容

6.验证数据库中Service Broker数据

 

 

用法：

dbcc CHECKDB 

(

    { 'database_name' | database_id | 0 }

    [ , NOINDEX

    | { REPAIR_ALLOW_DATA_LOSS

    | REPAIR_FAST

    | REPAIR_REBUILD

    } ]

)

    [ WITH

        {

            [ ALL_ERRORMSGS ]

            [ , [ NO_INFOMSGS ] ]

            [ , [ TABLOCK ] ]

            [ , [ ESTIMATEONLY ] ]

            [ , [ PHYSICAL_ONLY ] ]

            [ , [ DATA_PURITY ] ]

            [ , [ EXTENDED_LOGICAL_CHECKS  ] ]

        }

    ]

 

1. REPAIR_ALLOW_DATA_LOSS 会尝试修复报告中所有错误，修复可能会导致数据丢失

2. REPAIR_FAST 保留向后兼容，不推荐使用

3. REPAIR_REBUILD，执行次要快速修复及耗时修复，修复不会导致数据丢失

4. ESTIMATEONLY 预估修复所需要的tempdb空间

5. NO_INFOMSGS 取消显示所有信息性消息。

6. ALL_ERRORMSGS 显示针对每个对象报告的所有错误。如果未指定 ALL_ERRORMSGS，则只为每个对象显示前 200 条错误消息。

7. PHYSICAL_ONLY 将检查限制为页和记录标头的物理结构完整性、B 树的物理结构以及数据库的分配一致性。设计该检查是为了以较小的开销检查数据库的物理一致性，但它还可以检测会危及用户数据安全的残缺页、校验和错误以及常见的硬件故障。

8. TABLOCK 使 DBCC CHECKDB 获取锁，而不使用内部数据库快照。这包括一个短期数据库排他 (X) 锁。TABLOCK 可使 DBCC CHECKDB 在负荷较重的数据库上运行得更快，但 DBCC CHECKDB 运行时会减少数据库上可获得的并发性。

9. EXTENDED_LOGICAL_CHECKS 如果兼容级别为 100 (SQL Server 2008) 或更高，则对索引视图、XML 索引和空间索引（如果存在）执行逻辑一致性检查。

10. DATA_PURITY 使 DBCC CHECKDB 检查数据库中是否存在无效或越界的列值。例如，DBCC CHECKDB 检测日期和时间值大于或小于 datetime 数据类型的可接受范围的列。

 

 

 

DBCC CHECKDB(REPAIR_ALLOW_DATA_LOSS)执行操作：

1.将由于IO或者校验错误而标记为不可访问的页面重新标记为可访问，如同这些错误没有出现过一样，这样用户能够访问这些页面，虽然页面有问题

2.将尝试使用常规基于日志的恢复技术回复数据库

3.如果由于食物日志损坏而导致数据库恢复失败，则将重建事务日志，重建事务日志会导致数据库事务日志不一致

 

在DBCC CHECKDB(REPAIR_ALLOW_DATA_LOSS)建议：

0.建议在CHECKDB之前备份当前日志

1.建议在CHECKDB之后使用DBCC CHECKCONSTRAINTS来检查表约束

 

除DBCC CHECKDB(REPAIR_ALLOW_DATA_LOSS)外的修复方法：

1. 使用备份策略恢复

2. 使用将发生错误的表DROP后重新导入数据

3. 使用SELECT INTO 将数据取走（EMERGENCY模式下）

 

 

 

修复步骤：

1、修改数据库为紧急模式 
 ALTER DATABASE 库名 SET EMERGENCY 
 
2、使数据库变为单用户模式 
 
ALTER DATABASE 库名 SET SINGLE_USER
 
3、修复数据库日志重新生成，此命令检查的分配，结构，逻辑完整性和所有数据库中的对象错误。当您指定“REPAIR_ALLOW_DATA_LOSS”作为DBCC CHECKDB命令参数，该程序将检查和修复报告的错误。但是，这些修复可能会导致一些数据丢失。
DBCC CheckDB (库名 , REPAIR_ALLOW_DATA_LOSS) 
命令执行完成后可能会出现以下警告：
警告: 数据库 '库名' 的日志已重新生成。已失去事务的一致性。RESTORE 链已断开，服务器不再有以前的日志文件的上下文，因此您需要了解它们的内容。应运行 DBCC CHECKDB 验证物理一致性。数据库已置于 dbo-only 模式。在准备使数据库可用时，需要重置数据库选项，并删除所有多余的日志文件。
此时可以不用理会此警告，关闭Microsoft SQL Server Management Studio。
 
4、重新打开Microsoft SQL Server Management Studio，使数据库变回为多用户模式
 
 ALTER DATABASE 库名 SET MULTI_USER 

5 重新启动sqlserver

 

DBCC CHECKDB 在大数据库上的建议

1. DBCC CHECKDB实际是对当前数据库进行快照，在快照上执行检查，因此防止对当前用户执行出现阻塞和并发问题，CHCEKDB可以在多用户模式下执行

 

2. DBCC CHECKDB默认使用多线程并行检查，可以使用SP_CONFIGURE 'max degree of parallelism'来设置最大并行度

 

3. 使用WITH PHYSICAL_ONLY以较小开销检查数据库物理一致性

 

4. 使用WITH NO_INDEX来避免检查索引

 

5. 可以使用

SELECT 

R.session_id,

R.request_id,

R.percent_complete,

R.start_time,

R.estimated_completion_time,

R.status,

R.command

FROM sys.dm_exec_requests R

WHERE command LIKE '%DBCC CHECK%'

来估算出执行DBCC还需要多长时间完成，该值可能不太准

 

6.将CHECKDB拆分成多个步骤完成，CHECKFILEGROUP CHECKALLOC CHECKTABLE 

 

7.在备份机上测试