按计划备份和截断事务日志的最佳方法

Question

我不是 DBA，但事情就是这样，我必须戴上 DBA 的帽子，并在我的 SQL Server 实例上设置维护计划。

因此，有一段时间我一直让我的 SSIS 通宵进程运行执行 SQL 任务来执行备份 - 基本上运行master.dbo.xp_create_subdir以确保目标文件夹存在，然后BACKUP DATABASE [DbName] TO DISK = 'G:\Backups\DbName\DbName.bak' WITH INIT.

每当该任务失败时，其余的过程将中止，我会收到通知，第二天早上来时注意到事务日志的驱动器已满，因此我会手动截断它们并继续。 .. 直到故事重演并且事务日志再次超过可用磁盘空间。

“手动截断”脚本如下所示：

use Staging;
alter database Staging set recovery simple
alter database Staging set recovery full
dbcc shrinkfile ('Staging_log', 0, truncateonly);
go

所以我越来越厌倦了，我决定尝试正确地做事情，并按照这里的步骤创建一个实际的维护计划：

问题是，我以前从未这样做过，所以我有几个问题：

• 像这样备份事务日志会自动截断它们，还是我需要做其他事情？
• 可以同时运行数据和事务日志备份吗？如果没有，那么这样做的正确方法是什么？
• 备份文件正在被另一个进程在一夜之间提取，该进程获取服务器上的所有文件并将它们存储在其他地方 - 在 2 天后使备份集过期是个好主意吗？我需要让它们过期吗？
• 清理任务分别删除 .bak 和 .trn 子文件夹下的“旧”.bak 和 .trn 文件G:\Backups。那有意义吗？
• 在 SSIS 中执行此操作是否会更好，因此如果/当备份失败时我可以使 ETL 失败？或者我的 ETL 过程应该关心吗？

抱歉，如果一篇文章的问题太多，如果需要，我会编辑并提出多个问题 - 我认为它们都是紧密相关的。

Answer 1

SSIS 只在一夜之间进行写入，白天全部读取 - 我只需要每天恢复。

您应该根据您的业务需求选择您的恢复模式：

• 有多少数据业务可以在松散的同时存活下来？

根据上述答案，您应该谨慎选择数据库恢复模式。

简单来说（不讨论批量日志恢复模型），

• 完整恢复模型允许进行允许时间点恢复的日志备份。
  • 当您进行事务日志备份时可能会发生日志截断，即日志文件空间将在每次日志备份后重新使用并且不会膨胀！
• 简单恢复模式只允许您进行完整备份。时间点恢复是不可能的。
  • 日志截断只会发生在检查点（手动或自动）发生时，即由于您定期进行完整备份，您不必担心事务日志，因为 CHECKPOINT 将负责重用日志文件的非活动部分。

请记住，日志截断并不是事务日志文件大小的物理减小。这意味着事务日志文件的非活动部分被标记为可重用。

因此，您应该正确调整事务日志文件（和数据文件）的大小。增长日志文件将启动自动增长事件（如果您的数据库设置为自动增长作为最后的手段）。检查我的答案 -自动增长 - 使用百分比？

我强烈建议您放弃维护计划并实施 [智能维护解决方案 - 即简单、灵活并遵循最佳实践] - 5。- Ola 的备份解决方案（以及索引维护解决方案）。

让我们解决您的问题：

像这样备份事务日志会自动截断它们，还是我需要做其他事情？

请不要附加备份或将它们设置为过期。他们制造了一个大混乱。使用INIT并使用日期时间戳进行单独的日志备份。易于维护。为此，请使用 Ola 的备份解决方案。该解决方案也可以灵活地删除旧备份。

可以同时运行数据和事务日志备份吗？如果没有，那么这样做的正确方法是什么？

完整备份对 T-log 备份没有影响。完整备份仅包含足够的事务日志，以便在进行还原时，数据库可以在事务上与完整备份的数据读取部分完成时保持一致。检查 -完整备份包含多少事务日志？

此外，完整备份期间的日志备份不会截断事务日志。完整备份完成后的（几个）日志备份将截断日志。

备份文件正在被另一个进程在一夜之间提取，该进程获取服务器上的所有文件并将它们存储在其他地方 - 在 2 天后使备份集过期是个好主意吗？我需要让它们过期吗？

清理任务分别删除 G:\Backups 子文件夹下的“旧”.bak 和 .trn 文件。那有意义吗？在 SSIS 中执行此操作是否会更好，因此如果/当备份失败时我可以使 ETL 失败？或者我的 ETL 过程应该关心吗？

对于以上两者，请使用 Ola 的备份维护解决方案。它将负责删除旧文件。