我今天从我的托管服务提供商（他们创建的）收到一张支持票，说我的 SQL 事务日志已满，他们已截断它、缩小它并将其重置为完整恢复模型。
我很困惑，为什么他们让事务日志填满到网站崩溃并需要人工干预的地步。我问他们是否备份了数据库，他们回答道（用有点蹩脚的英语）
我们每天都会备份，并将备份保留一周。必须保留交易日志，因为我们不知道您进行了什么交易，而它可能包含重要信息。备份本身会截断日志。
最后一句话让我很困惑。这似乎暗示他们没有备份日志，如果他们每天都运行完整备份，我想这是可以的，但如果是这样的话，为什么事务日志没有每天都被截断呢？
我试图礼貌地建议他们可能应该截断日志，但我不确定他们是否正确理解日志的工作原理。我可以自己处理 SQL Server，但我不是专家，我没有足够的信心来指责他们。另外，我不知道他们使用的是什么备份软件，也不知道它是如何配置的。
那么，他们从不截断日志是否合理？在什么情况下这样做会有帮助？他们似乎有一个系统，当日志已满时他们会收到警报，然后他们会进入并手动运行截断脚本。这个系统可以工作，但不够优雅，这意味着我的网站每隔几周就会崩溃一次，直到他们注意到问题并修复它，此时他们会删除他们之前告诉我需要保留的日志。啊啊啊啊！
噢，SQL Server 专家，您会怎么做？
答案1
他们似乎有一个系统，当日志已满时他们会收到警报，然后他们进入并手动运行截断脚本。这个系统可以工作，但不够优雅，这意味着我的网站每隔几周就会崩溃，直到他们注意到问题并修复它，此时他们会删除他们之前告诉我需要保留的日志。
是的，这样不太好。
假设您的数据库处于完全恢复状态（因为，正如 Chris McKeown 指出的那样，如果它很简单，它就会自动截断），会发生以下情况：
当您/他们运行完整备份时，它包括当时数据库的当前状态。 确实如此不是截断日志。
当您/他们运行日志备份时，它会备份事务，并假设检查点已发生，截断（而不是缩小）日志，为更多事务腾出空间。因此，除非出现异常行为或您的日志备份不够频繁，否则事务日志应该会找到或多或少稳定的大小并保持在那里。
他们说：
我们每天都会备份，并将备份保留一周。必须保留交易日志，因为我们不知道您进行了什么交易，而它可能包含重要信息。备份本身会截断日志。
嗯。是的。我对此没有信心。
我会要求他们澄清他们每天运行的是哪种备份：是运行完整备份、差异备份还是日志备份。如果他们运行夜间日志备份，而从不运行完整备份，那么，通过丢弃上周的数据，他们已经破坏了恢复链，并且在发生故障时永远无法恢复。正如 Chris McKeown 指出的那样，他们还通过截断日志破坏了恢复链。
根据提供的信息，我无法肯定地说，但听起来他们根本没有运行日志备份。如果他们运行日志备份，那么夜间备份对你来说就没用了，日志需要更频繁地备份。
我也不清楚您的托管合同中的 SQL 恢复服务水平协议是什么，但您可能需要根据此信息重新审视该协议是否符合要求。
答案2
如果数据库使用完整恢复模型并且事务日志不断增长，则意味着他们确实没有进行定期的事务日志备份。
这是个问题吗？这取决于您的 ISP 对灾难发生时的可恢复性有何期望。如果他们说他们可以恢复到完整备份之间的某个时间点，那么他们现在就是在撒谎。手动截断日志将破坏日志备份链，并使时间点恢复变得不可能。
如果他们仅保证可恢复到上次完整备份，那么他们应该切换到简单恢复模式，然后日志将被自动截断。
答案3
最后一句话让我困惑。这似乎暗示他们没有备份日志，
没关系。进行完整备份时，标准做法是截断日志，因为这样您就有了当时的数据备份。
基本上，他们目前依赖于每日完整备份和本地 tx 日志 - 在这种情况下，这根本不够大。然后他们应该扩展日志（您需要为此付费）或改为定期（15 分钟、每小时）进行日志备份。
如果他们在完整备份后不截断日志，他们就是“不聪明”。没有理由在进行完整备份后保留完整日志。但事实并非如此 - 正如他们所说：“备份本身已经截断了日志”。
实际情况是，您使用的日志空间比他们分配的空间要多。很可能您的容量已经超出了他们的低使用率设置。