相关疑难解决方法(0)

这个问题在大多数论坛和整个网络中似乎是一个常见问题，这里以多种格式提出，通常听起来像这样：

在 SQL Server 中 -

• 事务日志变得如此之大的一些原因是什么？
• 为什么我的日志文件这么大？
• 有什么方法可以防止这个问题的发生？
• 当我找到根本原因并希望将我的事务日志文件调整到正常大小时，我该怎么办？

我不是 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

Run Code Online (Sandbox Code Playgroud)

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

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

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