主页 / dba / 问题 / 48365
Accepted
BradC
Asked: 2013-08-20 12:18:10 +0800 CST

将 DBCC CHECKDB 划分为多天

  • 772

我正在为非常大的数据库实施 Paul Randal在几天内手动传播 DBCC CHECKDB 的方法，该数据库基本上包括：

  • 将数据库中的表大致平均划分为 7 个桶
  • 每周运行两次 DBCC CHECKALLOC
  • 每周运行一次 DBCC CHECKCATALOG
  • 一周中的每一天在一个存储桶上运行 DBCC CHECKTABLE

有人用过这种技术吗？有任何现有的脚本吗？

我担心这实际上可能无法涵盖 CHECKDB 所做的一切；CHECKDB 的联机丛书文档说，除了 CHECKALLOC、CHECKCATALOG 和 CHECKTABLE 之外，它还：

  • 验证数据库中每个索引视图的内容。
  • 当使用 FILESTREAM 在文件系统中存储 varbinary(max) 数据时，验证表元数据与文件系统目录和文件之间的链接级别一致性。（仅限 SQL 2008）
  • 验证数据库中的 Service Broker 数据。

所以这是我的问题：

  1. 这些额外的检查是否必要/重要？（索引视图可能对我来说更重要，我认为我们还没有使用 Service Broker 或 FILESTREAM。）

  2. 如果是这样，有没有办法单独执行这些额外的检查？

  3. CHECKALLOC 和 CHECKCATALOG 似乎运行得非常快，即使在大型数据库上也是如此。有什么理由不每天运行这些？

（注意：这将是数百台服务器上数千个现有数据库的标准例程，或者至少是每个超过一定大小的数据库。这意味着重组所有数据库以使用 CHECKFILEGROUP 等选项对我们来说并不实际。）

sql-server dbcc-checkdb

2 个回答

  1. DBCC CHECKDB对于SQL Server 数据库 100% 确保没有损坏至关重要。但是，由于数据库的规模越来越大，当您声称是 24x7 时，很难找到维护窗口。多年来，SQL Server 团队实施了各种机制来检测最常见的损坏形式，尤其是与硬件引起的物理损坏有关。

    SQL Server 2005 及更高版本具有PAGE_VERIFY = CHECKSUM，它可以帮助您主动检测数据库页面中的物理损坏，从而在每个页面写入 I/O 系统时添加校验和，并在从磁盘读取时验证校验和。

    此外，使用 CHECKSUM备份（完整或差异）将保证检测到由硬件引起的任何 I/O 损坏。

    因此，从损坏的硬件方面来看，SQL Server 在检测和报告方面做得很好。（确保设置重要的与腐败相关的警报）。

    话虽如此，仍然是逻辑损坏，涂鸦程序导致的错误- 其中内存页面被 SQL Server 进程内运行的第三方代码或驱动程序或其他在 Windows 内核模式和/或SQL Server中执行的具有足够权限的软件损坏使用上述方法无法检测到错误等，因此CHECKDB出现了。

    DBCC CHECKDB 执行更彻底的检查，包括检查页头是否存在无法通过任何其他方式检测到的可能损坏。

    有任何现有的脚本吗？

    与其重新发明轮子，我强烈建议您看看Ola 的 SQL Server 完整性检查解决方案

    高效运行 DBCC CHECKDB ：

    当您在维护窗口紧张时拥有巨大的数据库或大量数据库来运行 CHECKDB，您只需要发挥创造力。

    参加 SQLSkills 培训后，我在我的环境中实施的是：

    • 优先检查哪些表是至关重要的。
    • 将表分成具有不同优先级的组，然后与运行和运行DBCC CHECKTABLE一起运行DBCC CHECKALLOCDBCC CHECKCATALOG
    • 创建一个工作表，该表将存储具有优先级的表名。只需确保所有高优先级表（非常大）不在一个组中，否则您的 CHECKDB 将根本无法完成。
    • 你甚至可以在你的工作表中有一个超时列，当你的 CHECKDB 通过维护窗口时将被杀死
    • 添加每个表运行所用的时间DBCC CHECKTABLE， DBCC CHECKALLOC以及DBCC CHECKCATALOG。这样您就可以了解运行支票通常需要多长时间。
    • 您甚至可以使用NOINDEX选项运行，因为它不会检查用户表上的非聚集索引，从而加快操作速度。这有一些优势，因为它不像数据损坏那么重要，因为没有数据丢失，您可以在必要时删除并重新创建索引。

    显然，企业版可以利用 DBCC 语句的并行执行，但要注意 MAXDOP 设置，因为它最终可能会占用你所有的 CPU。这可能会受到资源调控器的硬限制。

    注意：如果您有 SPARSE 列，那么您的 CHECKDB 将非常缓慢，如此处所述。

    最后，它如何通过利用所有可用的工具集 + 您对数据库服务器硬件系统的信心以及最重要的是数据的价值来防止数据库损坏。

    一些优秀的参考资料：

    • 7
  2. Best Answer

    这些额外的检查是否必要/重要？（索引视图可能对我来说更重要，我认为我们还没有使用 Service Broker 或 FILESTREAM。）

    您可以DBCC CHECKTABLE WITH EXTENDED_LOGICAL_CHECKS 直接在索引视图上运行。在某些情况下检查索引视图可能会出现问题，因此请准备好调查导致的任何误报。（Paul Randal 在对引用文章的评论中还提到，假阴性也是可能的，但我对此没有直接经验。）

    如果是这样，有没有办法单独执行这些额外的检查？

    不支持FILESTREAM单独运行 Service Broker 或检查，不。

    CHECKALLOC并且CHECKCATALOG似乎运行得非常快，即使在大型数据库上也是如此。有什么理由不每天运行这些？

    不是我知道的。

    你也可以考虑跑步DBCC CHECKCONSTRAINTS。无论您指定任何选项，此检查都不包含在 中。如果情况允许，DBCC CHECKDB您可能还想考虑偶尔跑步。CHECKDB

    • 6

相关问题