我们恰好在使用 SQL Server 2012 标准版。我也碰巧使用 Ola Hallengren 的脚本来提供一个简单、更灵活的框架来进行备份和维护。
这个问题与其说是关于 Ola 的脚本，不如说是关于最佳实践。我意识到最终的答案是“这取决于贵公司的要求”。但我正在努力征求社区的建议，以了解如何最好地满足我对公司要求的理解。
我希望每 15 分钟设置一次事务日志备份。这样我们希望丢失不超过 15 分钟的数据。我应该设置一个使用 ALL_DATABASES 的作业吗？还是为每个数据库设置一个作业并并行启动它们更好？我问，因为根据我对 Ola 脚本运行情况的看法，我感觉备份是连续启动的。串行的缺点是每个连续的备份都要等到另一个备份完成。这可能会增加备份之间的时间量（即大于 15 分钟）。另外，我担心的是一个备份失败会阻止其他备份发生，我不希望出现这种情况。我希望其他人继续支持。
那么，Ola 的脚本是串行执行的，并且失败会停止连续备份，这是真的吗？
每个数据库都有一份工作更好吗？还是一项工作就可以完成所有工作？我倾向于独立的工作，但我希望了解 SQL Server DBA 通常倾向于做什么。
我建议设置一个备份事务日志的作业（串行）。这也将确保备份不会大量使用 I/O，因为您一次运行一个数据库的备份。
并行运行可能有什么缺点
假设您有 50 个数据库，并且您安排了所有数据库的事务日志备份，并且它们都开始并行运行，这肯定会使用大量 I/O。如果它正在备份文件的磁盘恰好有其他数据文件，您会发现速度很慢。当请求大量 I/O 的糟糕查询与备份作业一起运行时，我已经看到备份变慢了。
再次假设您有 50 个数据库，在 SQL Server 代理中管理 50 个作业会不会很困难，如果您有 100-200 个数据库，我只是不喜欢它，当您打开 SQL Server 代理并看到很多作业时，保持简单。我相信你也会遇到同样的情况。
事务日志备份大多很小，如果您有一个繁忙的数据库产生大量日志记录，您可能需要更改备份频率。大多数情况下，我看到事务日志备份在频率为 15 分钟时完成得很好。我认为你不应该关心这个问题。
我会说别担心。事务日志备份不会失败，除非你犯了一些错误。错误可以是
运行该作业的所有者已从 AD 中删除
有人改变了数据库的恢复模式。
磁盘空间不足
除了上述之外，我还没有看到事务日志备份失败的任何原因。它非常坚固，您可以信赖它。
通常，始终串行运行 T-log 备份；我的许多实例都有几十个数据库，其中有几个非常活跃，事务日志备份总共只需要几秒钟；特别忙的时候最多半分钟左右。
如果满足以下所有条件，则仅并行运行备份确实是有益的：
您的数据库和日志文件都在唯一的独立轴上（或以任意组合在固态磁盘上）
每个数据库的备份目标位于不同的轴上。
您没有在 SQL Server 实例和媒体之间使用共享的 SAN HBA 或 iSCSI 或其他带宽。
即读取数据库 A 和写入备份 A 的 IOPS不要使用与读取数据库 B 和写入备份 B 相同的磁盘。
如果所有这些都是真的，那么某种程度的并行性可能会减少总日历时间。如果所有这些都不是真的，您很可能会导致一组或多组磁盘发生抖动，并且您的并行备份实际上将比串行备份花费更多的日历时间，但也可能导致操作系统文件系统或存储级别碎片化，因为您正在同时编写备份 A 和备份 B！
不要担心一个备份失败而其余备份成功 - 如果任何一个失败，您无论如何都需要检查所有内容，我唯一看到备份失败的原因是：
磁盘故障
Hyperbac/Litespeed/第三方压缩软件故障（如果你有SQL和故障磁盘之间的软件）
加密产品故障（如果您在 SQL 和故障磁盘之间有软件）
网络故障（如果数据库文件，或者更可能是备份文件，在网络上）
权限
最常见于全新安装
或全新的备份位置
更改 SQL Server 服务用户（这是正常备份需要权限的用户）
锁定 SQL Server 服务用户，因为它被不止一个 SQL Server 实例使用
配置错误
电源（检测）失败
操作系统崩溃
除非同时满足上述条件，否则其中大部分不会影响一个而不影响其他。
补充一下，Ola 设计了他的脚本，如果一个数据库备份由于某种原因失败，将尝试下一个。如前所述，您可以设置警报以通知您作业失败，因为备份作业仍然会失败，即使所有用户数据库中只有一个数据库备份失败 - 假设您正在备份所有数据库（一个所有人的工作）。