数据库完整性检查
为了主动发现数据库侧页损坏,保证数据库逻辑和物理完整性,计划每周六上午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/
实现备份、完整性检查、索引和统计信息维护整套方案。
免责声明:
① 本站未注明“稿件来源”的信息均来自网络整理。其文字、图片和音视频稿件的所属权归原作者所有。本站收集整理出于非商业性的教育和科研之目的,并不意味着本站赞同其观点或证实其内容的真实性。仅作为临时的测试数据,供内部测试之用。本站并未授权任何人以任何方式主动获取本站任何信息。
② 本站未注明“稿件来源”的临时测试数据将在测试完成后最终做删除处理。有问题或投稿请发送至: 邮箱/279061341@qq.com QQ/279061341