小编Elv*_*dov的帖子

• 我们有两个节点 Windows Server 集群，每个节点上安装了 SQL Server（2019 标准版）集群实例
• 有 500 个活动数据库
• 没有配置任何可用性组或任何其他 HA 解决方案
• 所有数据库均处于简单恢复模式
• VLF 数量和尺寸都不是很大
• 两个节点都是虚拟化的 Windows Server 2019，具有 64 GB 内存和 16 核。

修补被动节点并重新启动后，我们尝试故障转移到该节点。但令人惊讶的是，启动 SQL Server 服务大约需要 10 分钟，该服务挂起在更改挂起状态。在不打补丁的常规情况下，大约需要 10 秒。我从微软文档中得知，停机时间取决于故障转移时间和数据库升级脚本执行的总时间：

这一过程导致整个故障转移集群升级期间的停机时间仅限于一次故障转移时间和数据库升级脚本执行时间。

在我看来，这个停机时间似乎很长，只是在寻找以某种方式减少它的方法。如果您有任何建议，我将非常乐意倾听。

我在其中一个数据库上运行 DBCC CHECKDB 时遇到了分配错误。它抛出以下错误：

消息 8947，级别 16，状态 1，第 5 行表错误：对象 ID 1277199566、索引 ID 1、分区 ID 720577176766669456、分配单元 ID 720577087666647328 的多个 IAM 页（类型 LOB 数据）包含间隔。IAM 页面 (1:425664) 和 (1:1422669)。

CHECKDB 在表“schemaName.tableName”（对象 ID 1277199566）中发现 1 个分配错误和 0 个一致性错误。CHECKDB 在数据库“databaseName”中发现 1 个分配错误和 0 个一致性错误。

奇怪的是，当我尝试在该表上运行 DBCC CHECKTABLE 时，它没有显示任何错误。此外，我尝试运行 CHECKTABLE WITH EXTENDED_LOGICAL_CHECKS 选项，但没有出现任何错误。

根据 Microsoft 文档：

要对数据库中的每个表执行 DBCC CHECKTABLE，请使用 DBCC CHECKDB。

对于指定的表，DBCC CHECKTABLE 检查以下内容：

• 索引、行内、LOB 和行溢出数据页正确链接。
• 索引按正确的排序顺序排列。
• 指针是一致的。
• 每页数据合理，包括计算列。
• 页面偏移是合理的。
• 基表中的每一行在每个非聚集索引中都有一个匹配的行，反之亦然。
• 分区表或索引中的每一行都在正确的分区中。
• 使用 FILESTREAM 在文件系统中存储 varbinary(max) 数据时文件系统和表之间的链接级一致性

但正如我所看到的，相反的情况并非如此。我们不能只对一张表运行 CHECKTABLE 并为同一张表获得相同的结果。

在检查特定对象的完整性和一致性方面，是否有人拥有与这两个命令之间的差异相关的信息？

我正在尝试将备份文件拆分为多个文件，以将它们从一个 DC 复制到另一个 DC。找不到有关最大文件数的任何信息。当我尝试将备份文件拆分为多个文件时，可以创建多少个文件？

我目前找到的唯一信息是 Ola 的备份脚本，他在其中提到了 64 个文件： https: //ola.hallengren.com/sql-server-backup.html