我有一个在 SQL Server 2000 上运行的 SAP ECC 实例。数据库设置为完整恢复模式，但事务日志备份绝不完成（不是我的选择）。相反，每天都会保存完整备份。
这当然意味着事务日志文件不断增长。为了控制其大小，每月一次对事务日志进行截断， 进而压缩与dbcc shrinkfile（再次强调，这不是我的选择）。
您很容易猜到，这种方法效果不佳，因为有时日志文件增长得太快，填满了其分区，导致数据库挂起。我被要求改善这种情况。
如果由我选择的话，我会每天多次进行事务日志备份，但实际负责人并不希望这样做。
第二个显而易见的选择是更频繁地运行截断和收缩作业。但据我所知，这不是一个好选择。我读到的一件事这里最让我担心的是：
通过在（时间）截断日志，您就完全使日志的一致性无效，并且无法恢复过去（上次完整备份的时间）的任何数据。
这是真的吗？这是否意味着现在使用的日志文件完全没用？如果我现在开始定期备份它，它是否可用于时间点恢复？日志备份是否一致？我最好使用简单恢复模型吗？
谢谢。
答案1
这基本是正确的，如果您截断日志，那么您之后尝试进行的任何日志备份都是完全无用的（我不知道 SQL Server 是否会让您在此之后进行日志备份 - 很可能不会，只是因为它毫无用处）。您必须进行另一次完整或差异备份以重新启动日志链，此时您可以再次开始进行日志备份。
即使您从未备份过日志，它仍然很有用。如果托管数据文件的卷死机，您可以对（可能相当大的）日志执行日志尾部备份，并在使用 NORECOVERY 恢复完整备份后使用该备份，这样数据丢失很少或没有。但是，如果托管日志文件的卷死机，没有日志备份，您基本上就完蛋了。
鉴于您指定的限制（即没有定期日志备份），我将继续使用您当前的方法，但确保在截断后立即执行完整备份。这仍然是一种糟糕的操作方式，但它比使用简单恢复或更频繁的日志截断而没有事后完整备份更安全。
但是如果你能说服负责人，即使每天一次的日志备份也会有很大的改进。也许可以安排在完整备份之前立即进行。
答案2
最好使用简单恢复模型。未备份的日志文件无论如何都是无用的。只有备份才可以恢复。那么，如果您不备份，日志有什么用呢？
谁说不应该从事 IT 行业，但这不是你的原则。一旦发生什么事情，你的公司就完了。