我最近接受了SQL Server 2005到2014之间的一些SQL服务器的数据库管理，其中许多数据库都处于完全恢复模式，但是没有好的持续备份维护计划。永远安装。
在我看来，以前的DBA只会在失控并填满硬盘时处理事务日志文件。所以我想改变这个并一劳永逸地解决问题。我一直在做一些阅读，并认为我对需要做的事情有一个很好的理解，所以我想验证我的理解，并提出一些问题来澄清我仍然不知道的一些问题。完全搞定。
因此，根据我对日期的理解，我需要创建一个以完全备份开始的维护计划。我仍然需要与管理层讨论，以找出RTO，可接受的数据丢失等内容，所以让我们假设我们将在周日进行完全备份。
接下来我将添加到此维护计划每晚的差异备份...所以周一到周六。我意识到这也可以是完全备份或更频繁地运行差异，但这也只是为了确保我能够正确理解事物。
现在至于事务日志备份。我得到了我需要支持这些并截断日志文件，以防止它不断增长和失控。我不知道是否有任何具体的建议来支持这种情况，但我已经看到了15分钟的建议。我想这会更多地落在可接受的数据丢失窗口之下。这是对的吗？
所以我发现的另一件事是，当您使用截断备份事务日志文件时，如果日志文件已经失控，那么它不会缩小文件。我还读到，缩小这些文件是不合适的，至少定期是这样，因为一旦缩小它，它就需要再次增长，这将导致碎片和性能问题。
现在因为我目前处于文件已经失控的情况，我假设我实际上应该一次收缩日志文件但我的维护已经到位。这个假设是否正确？
此外，一旦我收缩事务日志文件一次，是否有任何维护任务我应该运行以避免由于缩小日志文件而导致性能问题？
我想知道的另一个问题是关于时间点恢复。所以，让我们说我在凌晨5点进行完整备份，并且每隔15分钟我也会进行一次事务日志备份。我收到警报，在上午6:18发生了一些问题（让我们说一个表被删除了）。所以我知道我可以通过在5:00 AM发生的完全备份恢复，并将其保留在NO RECOVERY模式并从早上5:15恢复到所有的事务日志备份，但是这里是我所做的事情。我感兴趣...因为我的数据库处于完全恢复模式，是否有可能以某种方式使用我现有的事务日志文件（而不是备份）在表之前的6:15和6:17之间前滚所有事务删除吗？如果是这样你会怎么做？我想这显然不适用于您使用事务日志文件丢失硬盘驱动器，或者您的服务器爆炸......但在我所概述的情况下它是否能够实现？
由于
答案 0 :(得分：1)
我建议大家停止工作后进行完整备份，例如： G。晚上10点（如果是这种情况），不是在人们开始工作前不久的早晨。只是为了给它足够的时间来运行。
就个人而言，如果数据库不是太大而不能保存14天的备份，我更喜欢每日完整备份而不是增量备份。依靠较少的文件我感觉更好。如果数据库和完整备份太大，增量备份可能是更好的选择。
正如您所说：您在白天创建的事务日志备份数量取决于可接受的数据丢失窗口。在环境中＆gt; 5个人在系统上工作（就像直觉一样）我会将它们配置为运行15分钟，在非常大的系统上可能更多。
在第一个事务日志备份之后，您可能希望收缩LOG文件。
我认为在日志缩小后没有必要进行任何优化。
据我所知，在06:15和06:17之间无法恢复交易。
激活事务日志备份时，请记住第一个事务日志备份将非常大（大约是当前大型日志的大小）。确保在磁盘上有足够的空间，直到缩小日志文件并删除第一个事务日志（通常在维护计划中自动完成，例如14天后。）。