为BACKUP命令设置BUFFERCOUNT，BLOCKSIZE和MAXTRANSFERSIZE

我找了实际指导的设定值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并从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，但是block size参数指定不兼容的覆盖值512。使用兼容的块大小重新发出该语句。

• BUFFERCOUNT：

  • 默认值^[2]，[8]：

    SQL Server 2005及更高版本：
    （NumberofBackupDevices * [mystery_multiplier]）+ NumberofBackupDevices +（2 * NumberofVolumesInvolved）

  • [mystery_multiplier]：此值存在一些不一致之处。我已经看到它以3种形式表示：

    • 3 ^[2]
    • GetSuggestedIoDepth ^[8]
    • GetSuggestedIoDepth + 1 ^[8]

    
    显示要乘数的测试3是在SQL Server 2005 SP2上完成的^[9]。

    我在SQL Server 2008 R2和2012上的测试以及有关SQL Server 2014的用户评论^[8]显示乘数为4。根据给定的报告值GetSuggestedIoDepth（直接在下面），含义是：

    • GetSuggestedIoDepth现在4，或
    • 乘数现在 GetSuggestedIoDepth + 1
  • GetSuggestedIoDepth3磁盘设备的退货^[9]
  • 没有硬性设置的最大值，但是考虑到所需的内存=（BUFFERCOUNT* MAXTRANSFERSIZE），实际的最大值似乎是： BUFFERCOUNT <= (available_memory / MAXTRANSFERSIZE)
• MAXTRANSFERSIZE：
  • 可能的值是65536字节（64 KB）的倍数，最大为4194304字节（4 MB）。^[1]
  • 默认值：如果设备处于读取模式（还原），或者这是台式机或Express Edition，请使用64K，否则请使用1 MB。^[9]
• 一般/杂项：
  • 可以使用的最大大小为（缓冲池的到物理内存/ 16）。从GlobalMemoryStatusEx（ullTotalPhys）API调用返回。^[9]
  • 跟踪标志3213在执行备份/还原操作时输出备份/还原配置参数，并将3605输出转储到ERRORLOG文件中：DBCC TRACEON (3213, 3605, -1);
  • 您可以使用DISK = N'NUL:'（与/dev/nullUNIX中的DOS / Windows等效，在UNIX中是DOS / Windows ）来更轻松地测试某些指标（但由于跳过了编写I / O，因此无法很好地了解总处理时间）

资源资源

1. MSDN页面的T-SQL BACKUP命令
2. KB904804：备份SQL Server 2000中的数据库时，您会遇到性能下降
3. 提高SQL Server备份性能的选项
4. 备份还原
5. 优化SQL Server备份和还原
6. 优化备份性能
7. 如何使用压缩和固态磁盘提高SQL数据库完全备份的速度
8. 不正确的BufferCount数据传输选项可能导致OOM状态
9. 工作原理：SQL Server备份和还原如何选择传输大小
10. 工作原理：SQL Server备份缓冲区交换（VDI焦点）
11. SQL Backup调整大型数据库
12. 用于备份缓冲区的SQL Server内存
13. 案例研究：通过网络快速可靠地备份和还原VLDB（.docx文件）
14. 建议使用多少备份设备来提高备份性能？

我测试了：

--DBCC TRACEON (3213, 3605, -1);

BACKUP DATABASE [Test] TO
      DISK =  'NUL:'
     --,DISK = 'NUL:'
     -- DISK =  'BackupTest1.bak'
     -- ,DISK =  'BackupTest2.bak'
WITH
    STATS = 5,
    FORMAT,
    CHECKSUM,
    NO_COMPRESSION,
    COPY_ONLY
    --,BUFFERCOUNT = 40
    --,MAXTRANSFERSIZE = 4194304--2097152,
    --,BLOCKSIZE = 16384 

--DBCC TRACEOFF (3213, 3605, -1);

更新

看来我有时忘记添加一些我在回答问题时总是要求别人提供的信息;-)。我确实在上面提供了一些有关当前情况的信息，但我可以提供更多详细信息：

我正在为提供24/7 / 365.25 SaaS应用程序的客户端工作。因此，用户随时随地都可以使用，但实际上，这些用户全都位于美国（目前），并且通常主要在“标准”小时内工作：太平洋时间上午7点（美国东部时间上午10点）至太平洋时间下午7点（即东部标准时间晚上10点），但每周7天，而不仅仅是星期一至星期五，尽管周末的工作量有所减轻。

它们的设置使得每个客户端都有自己的数据库。这是一个利基行业，因此没有成千上万（或更多）潜在客户。客户端数据库的数量因实例而异，最大的实例拥有206个客户端。最大的DB约为 8 GB，但只有大约30个DB超过1 GB。因此，我并不是专门尝试最大化VLDB的性能。

当我开始使用此客户端时，它们的备份始终是FULL，每天一次，并且没有LOG备份。他们还将MAXTRANSFERSIZE设置为4 MB，将BUFFERCOUNT设置为50。我用稍微定制化的Ola Hallengren的数据库备份脚本替换了该设置。稍微自定义的部分是，它是从多线程工具（我编写并希望很快会开始销售）运行的，该工具在连接到每个实例时可以动态发现数据库，并允许对每个实例进行限制（因此，我目前正在运行并发运行三个实例，但是每个实例的DB依次运行，因为我不确定同时运行它们的后果。

现在，设置是每周进行一次完整备份，然后在另一天进行DIFF备份。每10分钟进行一次LOG备份。我在这里查询的3个选项使用默认值。但是，知道他们过得怎么样集，我想确保我是不是撤销优化（只是因为有在旧系统中的一些重大缺陷，并不意味着一切错了）。当前，对于206个数据库，FULL备份（一周一次）大约需要62分钟，而剩余日期（FULL之后的第一天为7，最后一天的最后一天为20）则需要7至20分钟的DIFF备份。下一个FULL）。那就是按顺序运行它们（单线程）。整个LOG备份过程（所有3个实例上的所有DB）总共每次花费50到90秒（同样，每10分钟）。

我意识到我可以在每个数据库中运行多个文件，但是a）我不确定使用多线程和中小型数据库会有什么改善，并且b）我不想使还原过程复杂化（有多种原因导致首选处理单个文件）。

我也意识到我可以启用压缩功能（我的测试查询有意禁用了压缩功能），我已经向团队推荐了压缩功能，但是我注意到内置的压缩​​功能有点麻烦。旧过程的一部分是将每个文件压缩到RAR中，我进行了自己的测试，发现是的，RAR版本比本地压缩版本小至少 50％。我确实尝试过先使用本机压缩来加快处理速度，然后再使用RAR文件，但是这些文件虽然比仅本机压缩的文件小，但仍然比仅RAR的压缩版本大一点，并且有足够的区别来证明不使用本机压缩。压缩备份的过程是异步的，每隔X分钟运行一次。如果找到.bak或.trn文件，将其压缩。这样，备份过程不会因压缩每个文件而变慢。

您已经解决了许多问题。感谢您的彻底检查！

我注意到了几件事：

• 各种硬件/负载因素如何影响应采取的措施。

您正在运行24x7实例吗？全天候负载是多少？我注意到您已禁用备份压缩；是出于测试目的而设计，还是出于某种原因希望在将其投入生产时将其关闭？如果您有大量的硬件空间（CPU / RAM），并且在最短的时间内完成备份是至关重要的，那么您就需要针对该目标为特定的硬件调整这些参数。如果您想确保OLTP工作负载全天候服务，并且不希望备份影响到这一点，则可能需要反过来调整这些参数。自从您要寻求一般指导以来，您还没有确定设计目标，但是，您如此明智地声明了“取决于”。

• 在任何情况下都不应该覆盖这些值吗？

如果您在不再维护实例后担心后续的可支持性，并且不确定替换功能，则希望保留默认设置。除非您有特殊需要进行调整，否则您可能希望保留默认值。正如他们所说，让熟睡的狗撒谎。

• 是否有一些陷阱可以覆盖所有这些并非立即显而易见的陷阱？占用过多的内存和/或磁盘I / O？还原操作复杂吗？

正如您所参考的文档清楚指出的那样，将这些参数调高太多无疑会对正常运行时间产生负面影响。与所有基于生产的事物一样，您需要在部署它之前对其进行彻底的测试，除非绝对必要，否则请不要进行任何设置。

• 如果我有一台运行着多个SQL Server实例的服务器（一个默认实例和两个命名实例），并且如果我同时运行所有3个实例的备份，那么除了确保集合（BUFFERCOUNT）之外，这还会影响我设置这些值的方式吗？ * MAXTRANSFERSIZE）是否不超过可用RAM？可能的I / O争用？

您将要确保在意外情况下留有足够的RAM。我当然会担心将超过60％或70％的可用内存用于备份操作，除非我100％地确定备份窗口期间什么也不会发生。

我在SQLServerScience.com上写了一篇博客文章，其中包含一些代码，展示了如何进行备份性能测试。

^{这可能不是我写过的最好的答案，但是正如The Great One™曾经说过的那样，“您会错过100％的镜头”}