我有一个在SQL Server 2000上运行的SAP ECC实例。数据库设置为完全恢复模式，但事务日志备份永远不会完成（不是我的select）。 相反，每天都会保存完整的备份。
这当然意味着事务日志文件不断增长。 要控制它的大小，在一个月内事务日志将被截断 ，然后用dbcc shrinkfile进行收缩 （再次，不是我的select）。
正如你可以很容易地猜到的，这不太好，因为有时日志文件增长太快，填满它的分区，数据库挂起。 我被要求改善这种情况。
如果select是我的，我会每天做多次事务日志备份，但实际负责人不需要这样做。
第二个明显的select是更频繁地运行truncate＆shrink作业。 但是根据我的理解，这不是一个好的select。 我在这里读到的一件事最让我担心：
通过在（时间）截断日志，你完全失去了你的日志的一致性，没有办法恢复过去的任何数据（上次完整备份的时间）。
这是真的？ 这是否意味着现在使用的日志文件是完全无用的？ 如果我现在开始经常备份它，它可以用于时间点恢复吗？ 日志备份是否一致？ 我最好使用简单的恢复模式？
谢谢。
如果你截断日志，那么大部分情况都是正确的，那么你之后尝试做的任何日志备份都是无用的（我不知道SQL Server甚至会让你做日志备份 – 这可能不会，简单地说因为这将是无用的）。 您必须进行另一次完整备份或差异备份才能重新启动日志链，此时您可以再次开始进行日志备份。
即使你从不备份日志，它仍然可以certificate是有用的。 如果托pipe数据文件的卷死了，您可以对（假设相当大的）日志执行日志尾部备份，并在使用NORECOVERY恢复完整备份后使用该备份，并且很less或没有数据丢失。 但是，如果承载日志文件的卷死了，则大多数情况下没有日志备份。
考虑到你指定的约束（即没有定期的日志备份），我会继续你目前的做法，但要确保在截断后立即执行完整备份。 这仍然是一个糟糕的操作方式，但是比以前使用简单恢复或更频繁的日志截断更安全，而没有完整的备份。
但是如果你能说服负责人，即使每天一次的日志备份也是一个巨大的改进。 也许安排它在完全备份之前立即发生。
你最好使用简单的恢复模式。 无论如何，没有备份的日志文件都不是有用的。 只有备份可以恢复。 所以，如果你不支持，日志是好的吗？
谁试过这个不应该在IT工作，但这不是你的pribme。 什么东西出现，你的公司就是历史。