事务日志备份是串行还是并行？

15

我们碰巧正在使用SQL Server 2012 Standard Edition。我也碰巧使用Ola Hallengren的脚本来提供简单，灵活的框架来进行备份和维护。

这个问题不是关于Ola的脚本，而是关于最佳实践。我意识到最终的答案是“这取决于您公司的要求”。但是，我试图就如何最好地满足我对公司要求的理解，征询社区的建议。

我希望每15分钟设置一次事务日志备份。这样，我们希望丢失的数据不会超过15分钟。我应该设置一项使用ALL_DATABASES的作业吗？还是为每个数据库设置一项工作并并行启动它们？我问，因为我有一种基于Ola脚本运行方式的感觉，即备份是以串行方式启动的。串行的缺点是每个连续的备份要等到另一个完成为止。这可能会增加备份之间的时间量（即，大于15分钟）。另外，我担心的是，一个备份失败会阻止其他备份的发生，我不希望这样。我希望其他人继续备份。

那么Ola的脚本是串行执行的，还是失败会停止连续的备份，这是真的吗？

每个数据库都有一份工作更好吗？或仅完成一项工作？我倾向于单独的工作，但是我希望了解SQL Server DBA通常会做什么。

— 克里斯·奥尔德里奇
source

1

我倾向于每个数据库一个工作，因为这样更易于管理，但后来我成了“控制狂”，或者有人告诉我……也许您有一个数据库可以承受15分钟的数据丢失，但是另一个只有5分钟的时间，仅供初学者使用。

— Max Vernon

1

最糟糕的情况（除非备份文件损坏）是服务器在运行tlog作业的中间崩溃。这样您就可以还原到以前的日志备份。如果是串行的，则备份的第一个数据库将丢失15分钟的数据，每个后续日志备份将丢失15分钟-每个先前备份数据丢失的总时间。分离作业将使您每个数据库具有不同的RPO（即某些数据库可以丢失1小时数据）

— Bob Klimes

@MaxVernon-也许。但是一些基于意见的问题是有效的。我试图提出有意义的问题，而不只是发动火焰战争。另外，在我所有的工作中，我倾向于当偶然/初级DBA。首先是DB2，现在是SQL Server。所以我没有上级可以学习。我唯一的资源是社区。所以我认为这样的问题是公平的。它使我自己和其他偶然/初级的人可以从中学到东西。

— 克里斯·阿尔德里奇

也许每10分钟进行一次日志备份，以使实际延迟不超过15分钟？

— usr

6

我应该设置一项使用ALL_DATABASES的作业吗？还是为每个数据库设置一项工作并并行启动它们？

我建议设置一个作业来备份事务日志（串行）。这还将确保备份不会大量使用I / O，因为您一次正在运行一个数据库的备份。

并行运行可能有哪些弊端

假设您有50个数据库，并且计划所有数据库的事务日志备份，并且它们都开始并行运行，那么这肯定会利用大量I / O。而且，如果要备份文件的磁盘上还有其他数据文件，您会发现速度很慢。我已经看到当请求大量I / O的不良查询与备份作业一起运行时，备份速度会变慢。
再次假设您有50个数据库，那么在SQL Server代理中管理50个作业将不难，如果您有100-200个数据库，那将是什么情况，当您打开SQL Server代理并看到大量工作时，我只是不喜欢它，保持简单。我相信您也会遇到同样的情况。

串行的缺点是每个连续的备份要等到另一个完成为止。这可能会增加备份之间的时间量（即，大于15分钟）。

事务日志备份通常很小，如果您有一个繁忙的数据库来生成大量日志记录，则可能需要更改备份频率。通常，当频率为15分钟时，我已经看到事务日志备份可以正常完成。我认为您不必担心。

再加上我担心的是，一个备份失败会阻止其他备份的发生，而我不希望这样

我会说就是不用担心。除非您犯了一些错误，否则事务日志备份不会失败。错误可能是

从AD中删除了运行作业的所有者
有人更改了数据库的恢复模型。
磁盘空间不足

除上述以外，我还没有看到任何导致事务日志备份失败的原因。您可以依靠它非常强大。

— 香基
source

6

通常，始终以串行方式运行T-log备份；我的许多实例有几十个数据库，而几个实例非常活跃，事务日志备份总共只需要几秒钟。尤其是忙碌时，最多半分钟左右。

如果满足以下所有条件，则仅并行运行备份确实会有所帮助：

您的数据库和日志文件都位于唯一的独立主轴上（或以任何组合的形式位于固态磁盘上）
- 对于仅T日志备份，仅日志文件将需要满足此要求。
每个数据库的备份目标位于不同的轴上。
您没有在SQL Server实例和介质之间使用共享的SAN HBA或iSCSI或其他带宽。
例如，读取数据库A和写入备份A的IOPS 请勿使用与读取数据库B和写入备份B相同的磁盘。

如果所有这些都成立，那么某种程度的并行性可能会减少总的日历时间。如果所有这些都不成立，则很可能会导致一组或多组磁盘发生故障，并且并行备份实际上将比串行备份花费更多的日历时间，而且还可能导致操作系统文件系统或存储级别碎片化，因为您正在同时编写备份A和备份B！

不必担心一个备份失败而其余备份都会成功-如果有任何失败，则无论如何都需要检查所有内容，而我看到备份失败的唯一原因是：

磁盘故障
Hyperbac / Litespeed /第三方压缩软件故障（如果在SQL和磁盘之间存在软件故障）
- 作为警告，该故障可能采取从未完成的备份作业的形式，因此对发送警报的“运行时间超出预期的作业”进行一些检查非常有价值。
加密产品故障（如果您在SQL和发生故障的磁盘之间安装了软件）
网络故障（如果数据库文件或更可能是备份文件在网络上）
权限
- 最常见于全新安装
- 或全新的备份位置
- 更改SQL Server服务用户（这是正常备份所需要的权限）
- 锁定SQL Server服务用户，因为它被多个SQL Server实例使用
配置错误
电源（检测）失败
操作系统崩溃

除非还满足上述条件，否则大多数不会影响一个，而不会影响其他。

— 反弱密码
source

2

只是添加一下，Ola设计了他的脚本，其中如果一个数据库备份由于某种原因而无法备份，则尝试下一个。如前所述，您可以设置一个警报来通知您作业失败，因为即使所有用户数据库中只有一个数据库备份失败，备份作业仍然会失败-假设您正在备份所有数据库（一个所有人的工作）。

— rvsc48
source