完整恢复模型和事务日志

anu*_*anu 4 sql-server transaction-log

由于新的业务需求,我将把 5TB 数据库从简单恢复模式更改为完整恢复模式。该数据库自 5 年来一直采用简单恢复模式。

我的问题是一旦我更改恢复模式,将进行完整备份。但如何确保数据库的日志不会增长。因为预计备份完成时间约为5小时。我正在考虑创建一个作业并安排它,以便日志备份在 5 小时后开始。这是一个好方法吗?请指教。我想确保在刚刚更改为完整恢复模式的数据库的完整备份完成之前,日志不应增长。

谢谢

J.D*_*.D. 5

当数据库处于完全恢复模式时,事务日志会继续填满,并且一旦事务日志文件已满,只要磁盘上有可用空间供文件增长,事务日志就会增长。如果没有足够的空间供文件增长,那么当您尝试运行事务性查询(无论是隐式还是显式事务性查询)(这将是大多数查询)时,您将在 SQL 实例中收到错误。

当您进行事务日志备份时,SQL Server 将事务日志文件的已消耗空间标记为可重用。这将允许日志文件的字节被覆盖而不是不断地附加,并且将有助于最大限度地减少日志文件的增长。

这与您的完整备份及其完成时间无关。现在,您将在 SQL Server 事件日志或作业历史记录日志中看到事务备份运行时的错误,直到第一个完整备份完成为止。这是因为如果没有之前的完整备份且属于同一备份链的一部分,则无法还原这些事务日志备份。但是,一旦完整备份完成,任何后续事务日志备份都将可用,并且该错误将自动消失。

鉴于上述情况,大多数人安排他们的事务日志备份以他们需要的时间点恢复粒度级别的频率运行。大多数情况下,该频率介于每 1 分钟或每 1 小时之间。我个人每 5 分钟运行一次,因为它为我提供了更好的时间点恢复(数据丢失的机会更少)并导致备份文件更小,因此它们可以更快地完成备份过程(通常在一秒钟内)。它还可以更快地释放日志文件以覆盖那些日志,从而帮助维护日志文件而不会使其失控。

长话短说,我的建议是安排事务日志备份以时间点恢复所需的粒度频率运行。您安排它们运行的​​频率越高,日志文件失控的可能性就越小。

但请注意,没有完美的解决方案。即使非常大的显式事务也会导致日志文件增长,无论您备份的频率如何。这通常不是常态,如果是,那么日志文件增长到的大小就是应该保留的适当大小。