SQL 本机备份 MIRROR TO 性能

Question

我们将在明年第 1 季度迁移到 SQL Server 2014 昂贵版。现在我们使用的是 SQL Server 2005 标准版，因此我们无法访问MIRROR TO用于备份的非常棒的选项（我们使用 Ola Hallengren 的脚本）。

现在，我们正在使用 robocopy 将文件复制到网络共享，以防万一我们存储在本地的备份损坏、丢失或决定休个长假。我的问题是，当我们使用该MIRROR TO选项时，与仅使用 robocopy、xcopy 或 Powershell 解决方案相比，它是否会更多/更少地占用资源？当我们MIRROR TO在 SQL Server 中使用时到底发生了什么？如果可能的话，寻找一些“具体细节”的答案。

Answer 1

我在这里猜测是根据我的实施方式MIRROR TO：

如果您使用MIRROR TO. 这意味着他们读取的每个块都被写入两次。数据流有一个分支。

他们当然不会做的是将数据写入一次，然后再将其复制过来。这将 a) 导致对数据进行额外的读取传递，并且 b) 还会打开一个数据损坏窗口，而只有一个备份副本存在。从实现者的角度来看，分叉流的工作量更少，而且结果更好。这就是为什么我认为他们正在这样做。

这意味着MIRROR TO与备份成功后复制数据文件相比，它占用的资源更少。它还具有较小的数据损坏空间。数据损坏很少见，但却是一个实际问题。内存、磁盘和网络都可能有未检测到的位翻转。（是的，TCP 并不能 100% 防止这种情况发生。）

鉴于企业版将提供给您这一事实，建议：使用MIRROR TO. 它导致更少的资源使用和更少的（未检测到的）备份损坏的可能性。它还可以自动执行手动操作时可能出错的内容。SQL Server 的测试肯定比大多数内部脚本开发要好。不使用它的唯一原因是如果您的备份过程无法轻松修改以使用它。

补充一点：如果无法写入镜像，则备份将失败。这可能是一个缺点（您可能超出了您的 RPO 目标）。这可能是一个好处，因为更容易检测到错误。

正如 Paul White 在评论中提到的：如果备份目的地之一很慢（或所有数据都流经同一个饱和的网络链接），备份可能需要比以前更长的时间。在网络链接饱和的情况下，在目标服务器上本地复制备份文件可能会更快。

可以测试这个理论：使用 MIRROR TO 将数据库备份到具有相同性能特征的两个 IO 设备。如果我是对的，您应该只观察到微小的减速，因为写入是流式和并行的。

我自己执行了这个基准测试。从 SSD（非常快）备份到两个（几乎）相同的磁驱动器。使用数据压缩（但 CPU 未达到极限）。

• 镜子：1:37。
• 没有镜子：1:10 驱动 1。
• 没有镜子：1:14开车2。

这种放缓（1:37 对 1:14）完全在我的理论的容许范围内。似乎有一些开销，但肯定没有单独的镜像/复制阶段。使用 Process Explorer，我观察到以 MB/秒为单位测量的 IO。这是相当稳定的。这也暗示没有单独的阶段。写入似乎与两个驱动器并行。