使用巨大的日志文件进行完全恢复答案

【问题标题】：full recovery with huge log file使用巨大的日志文件进行完全恢复
【发布时间】：2023-03-10 03:07:01
【问题描述】：

在具有完整模型备份的 sql server 数据库中，每 15 分钟备份一次 tran 日志，但是，日志文件仍然很大。我怀疑我应该对目标恢复时间参数（实际上是 60 秒）采取行动……

[ 最近我找到了一种缩小它的方法：

执行以下任务后缩小数据库：

/* 对数据库执行完整备份。

将数据库的备份方法更改为“简单”

打开查询窗口，输入“checkpoint”并执行

再次备份数据库

执行数据库的最终完整备份。 */

【问题讨论】：

日志文件本身是否很大但很少使用 - EXEC SQLPERF(LogSpace) - 即使在日志备份后，日志本身也会保持一定大小，但那里可能有很多空白空间。您可以尝试缩小日志（如果有可用空间），但请注意，它可能会再次增长，直到下一次日志备份并且您回到原点。小心任何收缩（甚至不要考虑自动收缩！）
以下是结果：日志大小 (MB) 11799,99 已用日志空间 (%) 29,30282 状态 0
我已经尝试了很多 BCC SHRINKFILE (databasename, 5000) WITH NO_INFOMSGS 和类似的命令，但没有结果
define "no result" - 它似乎挂了很长时间？如果日志经常被使用，这可能是很正常的 - 如果是这样，将数字提高到 10000 或更高，并分阶段进行或在安静时期进行。也就是说，最后，日志需要在某个时候变得那么大，它可能会在未来某个时候再次到达那里。
"no result" == 日志文件大小没有显着变化，tks 我会在安静的时段（晚上）尝试

【解决方案1】：

事务日志备份不会收缩文件。如果它们增长，备份后空间将被标记为可用并重复使用，但文件大小不会减少。但是，如果您尝试缩小它而它没有缩小，那么日志可能仍在使用中。是否还有其他使用事务日志的东西，它可以防止 if 被截断？检查此命令的结果：

SELECT log_reuse_wait_desc FROM sys.databases where name = N'<database_name>';

它显示除 NOTHING 或 LOG_BACKUP 以外的任何内容，您无法缩小它，因为其他东西正在使用它。

【讨论】：

有时是 LOG_BACKUP，但大多数时候什么都没有
LOG_BACKUP 是当有记录的操作未备份时，在日志备份完成后没有什么是正确的。这些都是正常的。你有没有试过缩小你的日志？
使用数据库名称对我来说看起来不正确。它应该是日志文件的逻辑文件名。通常是“databasename_log”。尝试执行 DBCC SHRINKFILE (N'MyDatabase_Log' , 5000) 代替。或者使用 SSMS 中的 UI。
然后您的日志大小没有减少？这很奇怪！这个查询的结果是什么？ SELECT total_log_size_in_bytes, used_log_space_in_bytes FROM sys.dm_db_log_space_usage;
让我们continue this discussion in chat。