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.在备份机上测试

 

郑重声明:本站内容如果来自互联网及其他传播媒体,其版权均属原媒体及文章作者所有。转载目的在于传递更多信息及用于网络分享,并不代表本站赞同其观点和对其真实性负责,也不构成任何其他建议。