Chr*_*ich 15 sql-server backup best-practices ola-hallengren
我们碰巧使用的是 SQL Server 2012 标准版。我还碰巧使用了 Ola Hallengren 的脚本来提供一个简单、更灵活的框架来进行备份和维护。
这个问题不是关于 Ola 的脚本，而是关于最佳实践。我意识到最终的答案是“这取决于贵公司的要求”。但我正在尝试就如何最好地满足我对公司要求的理解寻求社区的建议。
我希望每 15 分钟设置一次事务日志备份。这样我们希望丢失不超过 15 分钟的数据。我应该设置一项使用 ALL_DATABASES 的作业吗？还是为每个数据库设置一项工作并并行启动它们更好？我问，因为根据我如何看待 Ola 的脚本功能，我有一种感觉，即备份是串行启动的。串行的缺点是每个连续的备份都等待另一个完成。这可能会增加备份之间的时间量（即大于 15 分钟）。另外，我担心一个备份的失败会阻止其他备份的发生，我不希望出现这种情况。我希望其他人继续备份。
那么，Ola 的脚本是串行执行的，而且故障也会停止连续备份吗？
每个数据库都有一份工作是不是更好？还是做所有事情的单一工作？我倾向于单独的工作，但我希望了解 SQL Server DBA 通常倾向于做什么。
我应该设置一项使用 ALL_DATABASES 的作业吗？还是为每个数据库设置一项工作并并行启动它们更好？
我建议设置一项可以备份事务日志（串行）的作业。这也将确保备份不会大量使用 I/O，因为您一次为一个数据库运行备份。
并行运行可能存在哪些缺点
假设您有 50 个数据库，并且您安排了所有数据库的事务日志备份，并且它们都开始并行运行，这肯定会使用大量 I/O。如果它正在备份文件的磁盘碰巧有其他数据文件，您会看到速度很慢。当请求大量 I/O 的糟糕查询与备份作业一起运行时，我看到备份变得缓慢。
再次假设您有 50 个数据库，在 SQL Server 代理中管理 50 个作业会不会很困难，如果您有 100-200 个数据库会是什么情况，当您打开 SQL Server 代理并看到很多作业时，我不会喜欢它，保持简单。我相信你也会遇到同样的情况。
串行的缺点是每个连续的备份都等待另一个完成。这可能会增加备份之间的时间量（即大于 15 分钟）。
事务日志备份大多很小，如果您有一个繁忙的数据库产生大量日志记录，您可能需要更改备份频率。大多数情况下，当频率为 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 实例使用
配置错误
电源（检测）失败
操作系统崩溃
除非同时满足上述条件，否则其中大部分不会影响一个而不是其他。
| 归档时间： |
|
| 查看次数： |
750 次 |
| 最近记录： |