为了提高 SQL Server 备份的性能，我们备份到多个备份文件。
- 在大多数关于此主题的博客文章中，他们都说要使用多个备份文件，但是，是否存在这样的情况：您可以拥有太多文件，而不是提高性能，而是由于大量线程等待而导致性能变差？
- 是否有基于服务器内核数量等方面的一般性建议？更具体地说，我们的一台服务器显示
BACKUPIO并BACKUPBUFFER作为前 2 名违规者等待统计数据。
我们正在使用 10 个备份文件备份一个大数据库（几个 TB），但我注意到服务器只有 4 个内核和 32 GB 的 RAM。我已将备份文件的数量更改为使用 4 个备份文件。我将在下周的下一个备份周期中查看它的进展情况，但与此同时，我试图根据服务器规格找到有关使用多少备份文件的任何建议。
一般不会，不会。这是一种可以提供帮助的特殊用途技术。
为什么这会导致吞吐量损失？线程通常是充足的资源。在某些配置中会出现问题，在这些配置中，您会消耗数百个线程和数千个线程。
如果备份操作受 CPU 限制，那将是有意义的。可能是这样。只要它是 IO 绑定的，它就无法帮助以任何设置为目标的核心数量。
这指向 IO 绑定备份过程。根据我的经验，这比 CPU 有界性更常见。
备份的大小对吞吐量的考虑没有影响。吞吐量是每单位时间的性能。
仅存在等待线程通常不会影响服务器上的其他线程和操作。等待线程什么也不做。
这是没有根据的，因为备份是 IO 绑定的。以核心数为目标不是一个好的目标。
如果您添加 128 个 CPU 内核，您的备份不会快一秒。
您可能提高了性能，但只是意外。
使用多少个备份文件受很多因素的影响。找到合适数字的一种简单方法是简单地测试不同的值，包括 1（常见系统最可能的值）。
让我们先解决你的问题......
备份线程的数量取决于用于数据库文件的逻辑卷的数量，以及备份设备的数量。SQL Server 一次备份操作最多支持 64 个备份设备。
因此，当您对备份进行条带化时，您正在增加吞吐量。这是一个很好的举措。
来自备份优化白皮书 的平衡文件和磁盘以获得良好备份性能的示例（注意：它是一个 word 文档）。
需要考虑的事情：
BUFFERCOUNT（I/O 缓冲区总数）和MAXTRANSFERSIZE（sql server 和备份媒体之间的最大字节传输单位）备份参数以及跟踪标志 3605 和 3213。友好建议
由于您正在运行一个大数据库（几个 TB），4 核和 32 GB RAM 听起来很低。提升你的硬件。
参考 ：