我今天从我的托pipe服务提供商（他们创build了它）收到一个支持票据，说我的SQL事务日志已经填满了，他们已经截断了它，缩小了它并将其重置为完全恢复模式。
我很困惑，为什么他们让交易日志填满网站翻倒的地步，需要人工干预。 我问他们是否备份了数据库，他们回答说（英文稍微有点乱）
我们每天备份，并保持备份一个星期。 事务日志必须被保留，因为我们不知道你做了什么事务，它可能包含重要的信息。 备份本身已被截断日志。
最后一句话感到困惑。 这似乎意味着他们没有备份日志，如果他们每天都在运行一个完整的备份，那么我认为是可以的，但是如果是这样的话，为什么事务日志不会每天被截断呢？
我试图礼貌地build议，他们可能应该截断日志，但我不知道他们正确理解日志如何工作。 我可以拿着自己的SQL Server，但我不是一个专家，我不能确定自己打电话给他们。 此外，我不知道他们正在使用什么备份软件或如何configuration。
那么，他们有理由永不截断日志？ 有什么情况可以帮助吗？ 他们似乎有一个系统，他们在日志满了时得到一个警报，然后进入并手动运行一个truncate脚本。 它的工作原理但不雅观，意味着我的网站每隔几个星期就会崩溃，直到他们发现问题并修复它，此时他们删除了之前告诉我需要保留的日志。 Arghghghgh！
你会怎么做，SQL Server专家哦？
他们似乎有一个系统，他们在日志满了时得到一个警报，然后进入并手动运行一个truncate脚本。 它的工作原理但不雅观，意味着我的网站每隔几个星期就会崩溃，直到他们发现问题并修复它，此时他们删除了之前告诉我需要保留的日志。
是的，那不好。
假设你的数据库正在完全恢复（因为正如Chris McKeown指出的那样，如果它很简单，它会自动截断），下面是发生的事情：
当您/他们运行完整备份时，它将包含当时的数据库当前状态。 它不会截断日志 。
当您/他们运行日志备份时，它会备份事务，并假设已经发生检查点，会截短（而不是收缩）日志，为更多的事务腾出空间。 因此，事务日志应该find一个或多或less稳定的大小，并停留在那里，禁止奇怪的行为或日志不足以备份。
他们说：
我们每天备份，并保持备份一个星期。 事务日志必须被保留，因为我们不知道你做了什么事务，它可能包含重要的信息。 备份本身已被截断日志。
嗯。 是啊。 我不是充满信心的。
我会要求他们澄清他们每天运行的备份types：他们是否正在运行完整备份，差异备份或日志备份。 如果他们正在运行夜间日志，并且从未完全运行，那么上周他们已经打破了恢复链，并且在失败的情况下永远无法恢复。 正如Chris McKeown所指出的，他们还通过截断日志来打破恢复链。
根据所提供的信息，我不能肯定地说，但肯定听起来他们根本没有运行日志备份。 如果是这样的话，那么每晚的备份都不会为您削减，并且需要更频繁地备份日志。
我也不知道SQL恢复的服务水平协议与您的托pipe合同有什么不同，但是您可能希望重新审视一下这些信息是否符合规定。
如果数据库正在使用FULL恢复模式并且事务日志不断增长，这意味着它们确实没有进行常规的事务日志备份。
这是一个问题吗？ 这取决于您的ISP在发生灾难时对您的可恢复性的期望。 如果他们说，他们可以恢复到完全备份之间的时间点，那么他们目前正在撒谎。 手动截断日志将会破坏日志备份链，并且无法实现时间点恢复。
如果他们只保证最后一次完全备份的可恢复性，那么他们应该切换到SIMPLE恢复模式，然后日志会自动截断。
最后一句话感到困惑。 这似乎意味着他们没有备份日志，
那没问题。 当您进行完整备份时截断日志是标准的，因为那时您有备份数据的时间。
基本上他们依靠每日完整的备份和当地的tx日志 – 在这种情况下，它根本不够大。 然后，他们应该扩大日志（并为此付钱）或者定期（15分钟，每小时）logging备份。
如果他们在完整备份后不截断日志，他们是 – “不聪明”。 完全备份后没有理由保留完整日志。 但事实并非如此 – 正如他们所说：“备份本身已被截断”。
发生了什么事情是，你用了一天的日志空间比分配的空间更多。 可能你超出了低使用率的设置。