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

我不是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文件G:\Backups。那有意义吗？
• 最好在SSIS中执行此操作，以便在备份失败时/我可以在ETL中失败吗？还是我的ETL流程应该在乎？

抱歉，如果一个帖子中有太多问题，如果需要，我将编辑并询问多个问题-我认为它们都是紧密相关的。

SSIS仅在夜间进行写入，而白天则是所有读取-我只需要每日恢复。

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

• 多少数据业务可以松散并同时生存？

根据以上答案，您应该仔细选择数据库恢复模型。

简单来说（不讨论批量记录的恢复模型），

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

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

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

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

让我们解决您的问题：

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

请不要追加备份或将其设置为过期。他们造成了很大的混乱。使用INIT带有日期时间戳的单独日志备份。易于维护。为此，请使用Ola的备份解决方案。该解决方案还可以灵活删除旧备份。

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

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

同样，在完全备份期间的日志备份不会截断事务日志。完整备份完成后，将执行一个（或多个）日志备份，以截断日志。

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

清理任务分别删除G：\ Backups子文件夹下的“ .bak”和“ .trn”旧文件。那有意义吗？最好在SSIS中执行此操作，以便在备份失败时/我可以在ETL中失败吗？还是我的ETL流程应该在乎？

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