数据库完整性检查

为了主动发现数据库侧页损坏，保证数据库逻辑和物理完整性，计划每周六上午6点，针对生产主库上的全部系统和用户数据库执行DBCC CHECKDB，将结果记录到表中。

如下为理论依据：

SQL Server数据库能够检测出页损坏，此时，具体的表现形式可能为下述三种错误的一种：

• 823错误，也就是所谓的硬IO错误，能够理解为SQL Server但愿读取页，而Windows告诉SQL Server，没法读取到该页。

• 824错误，也就是所谓的软IO错误，能够理解为SQL Server已经读取到该页，但经过计算CheckSum等值发现不匹配，所以SQL Server认为该页已经被损坏。

• 825错误，也就是所谓Retry错误。

SQL Server发现错误的方法有两种，分别为在读取页时和在备份时（本质上也是读取页）。但若是咱们但愿对于数据一致性的检查更加的全面，那咱们应该按期使用CheckDB来检查数据的一致性，而不至于在生产时间数据被读取时才能发现错误。

CheckDB命令在企业版中会使用多线程来进行，会对整个数据库进行一致性检查，在该过程当中，使用了内建数据库快照的方式进行，所以不会形成阻塞，但CheckDB会消耗大量的CPU、内存和IO。所以CheckDB要选择在维护窗口时间或是系统闲时进行。

实际上，CheckDB是一套命令的汇总，经过执行下列操做检查指定数据库中全部对象的逻辑和物理完整性：

• 初次检查系统表

• 分配单元检查（DBCC CHECKALLOC）

• 完整检查系统表

• 对全部表进行一致性逻辑检查（DBCC CHECKTABLE）

• 元数据检查（DBCC CHECKCATALOG）

• SSB检查

• 索引视图、XML索引等检查

微软最佳实践建议

“建议您使用 PHYSICAL_ONLY 选项，以即可以频繁检查生产系统。 使用 PHYSICAL_ONLY 能够极大地缩短对大型数据库运行 DBCC CHECKDB 的运行时间。 同时建议您按期运行没有选项的 DBCC CHECKDB。 应当以什么频率执行这些运行任务将取决于各个企业及其生产环境。

”引用自：

https://docs.microsoft.com/zh-cn/sql/t-sql/database-console-commands/dbcc-checkdb-transact-sql

成熟的方案

能够使用 https://ola.hallengren.com/

实现备份、完整性检查、索引和统计信息维护整套方案。