相关疑难解决方法(0)

我找了实际指导的设定值BUFFERCOUNT，BLOCKSIZE以及MAXTRANSFERSIZE该的BACKUP命令。我做了一些研究（见下文），我做了一些测试，我完全意识到任何真正有价值的答案都会以“好吧，这取决于……”开头。我对我所做的测试以及我发现的任何资源中显示的测试（见下文）的担忧是，测试是在真空中完成的，很可能是在没有其他负载的系统上完成的。

我很好奇关于这三个基于长期经验的选项的正确指导/最佳实践：数周或数月内的许多数据点。而且我不是在寻找特定值，因为这主要是可用硬件的功能，但我想知道：

• 各种硬件/负载因素如何影响应该做什么。
• 是否存在不应覆盖这些值中的任何一个的情况？
• 是否存在覆盖任何不明显的陷阱？使用了太多内存和/或磁盘 I/O？恢复操作复杂吗？
• 如果我有一台运行多个 SQL Server 实例的服务器（一个默认实例和两个命名实例），并且如果我同时运行所有 3 个实例的备份，这是否会影响我设置这些值的方式，而不是确保集体（BUFFERCOUNT* MAXTRANSFERSIZE) 不超过可用 RAM？可能的 I/O 争用？
• 在同一台服务器上拥有三个实例并再次同时运行所有三个实例的备份的相同场景中，在每个实例中同时运行多个数据库的备份如何影响这些值的设置？这意味着，如果三个实例中的每一个都有 100 个数据库，则每个实例同时运行 2 或 3 个备份，这样就有 6 到 9 个备份同时运行。（在这种情况下，我有许多中小型数据库，而不是一些大型数据库。）

到目前为止我收集到的：

• BLOCKSIZE：

  • 支持的大小为 512、1024、2048、4096、8192、16384、32768 和 65536 (64 KB) 字节。^[1]
  • 磁带设备的默认值为 65536，否则为 512 ^[1]
  • 如果您要进行备份并计划从 CD-ROM 复制和恢复，请指定 BLOCKSIZE=2048 ^[1]
  • 写入单个磁盘时，默认512就可以了；如果使用RAID阵列或SAN，则必须测试以查看默认或65536是否更好。^{[13（第 18 页）]}

  • 如果手动设置，该值需要 >= 用于创建数据文件的块大小，否则您将收到以下错误：

    消息 3272，级别 16，状态 0，第 3 行
    “C:\Program Files\Microsoft SQL Server\MSSQL11.MSSQLSERVER\MSSQL\Backup\BackupTest.bak”设备的硬件扇区大小为 4096，但块大小参数指定不兼容的覆盖值 512。使用兼容的块大小重新发出语句。 …

我正在使用压缩、写入多个文件以及更改BufferCount和MaxTransferSize选项来调整 SQL Server 备份。我有一个 SQL Server 实例，其中包含 4 TB 数据库和几个从几 MB 到 150 GB 的较小数据库。

我的问题是，我是否可以开始使用 150 GB 数据库进行调整，然后将这些设置应用到 4 TB 备份，只需进行最小的更改，或者 4 TB 是否需要从头开始拥有自己的“调整会话”？由于通常需要多次备份尝试才能拨入设置，因此我尝试在可能的情况下快速开始调整 4 TB 数据库。