Eli*_*gne 13 sql-server backup logs sql-server-2012
我有点像一个新的 DBA,我正在管理一个具有大量活动的 SQL Server 2012 实例。我在完全恢复模式下运行,因为我们需要时间点恢复。
现在,我每天凌晨 5 点对数据库和日志进行完整备份。一些日志文件已经膨胀到 300gb,即使在进行备份后,它们的大小也不会减小。我可以通过运行类似于以下内容的内容来减小它们的大小:
BACKUP LOG db1 TO DISK = '\\server\share\db1_log1.trn';
DBCC ShrinkFile([db1_log], 0);
BACKUP LOG db1 TO DISK = '\\server\share\db1_log2.trn';
DBCC ShrinkFile([db1_log], 0);
BACKUP LOG db1 TO DISK = '\\server\share\db1_log3.trn';
DBCC ShrinkFile([db1_log], 0);
Run Code Online (Sandbox Code Playgroud)
当我检查备份文件的 LSN 时,我看到如下内容:
RESTORE headeronly FROM DISK = N'\\server\share\db1_log1.trn'
FirstLSN: 15781000014686200001
SecondLSN: 15802000000665000001
RESTORE headeronly FROM DISK = N'\\server\share\db1_log2.trn'
FirstLSN: 15802000000665000001
SecondLSN: 15805000000004100001
RESTORE headeronly FROM DISK = N'\\server\share\db1_log3.trn'
FirstLSN: 15805000000004100001
SecondLSN: 15808000000004200001
Run Code Online (Sandbox Code Playgroud)
我不相信我通过缩小日志文件来破坏我的日志链。读到这里,我确实相信我正在损害我的性能,因为那些缩小的日志文件必须重新增长自己。
问题:
Tho*_*ger 10
- 为什么备份后日志文件没有缩小?是因为有未提交的事务吗?
实际的 NTFS 日志文件不会从事务日志备份中“缩小”,但事务日志中的 VLF(虚拟日志文件)被标记为可重用(因为它们现在已备份并保存在介质上)允许环绕事务日志使用发生。如果您没有备份事务日志,或者备份的频率不够高,那么将没有可用的 VLF,这将导致事务日志增长(假设设置了自动增长)以容纳额外的事务日志条目。
2.起初我想我应该在每 5:00 AM 备份后缩小日志文件。在阅读了这对性能的影响之后,我现在相信我需要在白天每隔几个小时进行一次定期的日志备份。那是对的吗?
常规和预定的文件收缩不是一个好主意。只有当您需要回收急需的空间时,才应考虑使用DBCC SHINKFILE
. 此外,当您不断增加事务日志时,您可能会阻碍其他事情,例如数据库的恢复。如果事务日志中的 VLF 过多(当事务日志仅以很小的存储增量增长时,这是一个常见问题),恢复数据库的时间可能比预期的要长。
3.我对数据库/日志的正常完整备份发生在每天凌晨 5:00,有时需要 3 个小时。如果我将日志备份安排为每小时进行一次,那么当日志备份与凌晨 5:00 的备份发生冲突时会发生什么?
什么都不会发生,那是完全合法的操作。请参阅下面来自MSDN 的图表。有黑点的地方,不能同时进行这两种操作。如您所见,允许同时进行数据库备份和事务日志。
这里的要点是您应该更频繁地备份您的事务日志。NTFS 文件增长并不是您因不更频繁地备份事务日志而可能遇到的唯一问题。如果您遇到存储故障并且事务日志丢失,则只能恢复到上次事务日志备份的时间点。如果事务日志丢失,您将无法备份日志的尾部并恢复到故障的时间点。在您的情况下,您可能会丢失 24 小时的数据。但是,如果您每隔 30 分钟备份一次事务日志,那么您的最大数据丢失时间将是 30 分钟。在这种情况下,如果您的事务日志消失了,并且您拥有完整备份和完整的日志链,您可以恢复到上次日志备份。