完全备份后的事务日志备份太大了
完全备份后的事务日志备份太大了
提问于 2020-10-11 22:33:19
我们目前的生产数据库每天早上7点执行完全备份。事务日志备份每15分钟进行一次(24/7)。
- 数据库版本: Microsoft 2014-12.0.4100.1 (X64)
- .mdf文件大小: 3.9GB
- .ldf文件大小: 6.5GB
- 恢复模式:完全
- 上午7时的完整备份大小: 3.8GB
事务日志文件(.trn)通常低于50 is，但在完全备份(上午7时)之后，下一个事务日志大约为1500 is。这对我来说是个问题，因为事务日志文件正在通过网络传输，并且恢复时间的原因。
这是完整备份的脚本：
BACKUP DATABASE [DB_PROD] TO
DISK = N'F:\SQL\DB_PROD_backup_2020_10_12_114830_1849966.bak'
WITH NOFORMAT, NOINIT, NAME = N'DB_PROD_backup_2020_10_12_114830_1849966',
SKIP, REWIND, NOUNLOAD, STATS = 10在完全备份之前有一个重新组织索引步骤。命令如下：
ALTER INDEX [UC_LCRecipe_Name]
ON [dbo].[LCRecipe]
REORGANIZE WITH ( LOB_COMPACTION = ON )回答 2
Database Administration用户
发布于 2020-10-12 01:13:27
我的理解是，完全备份不会截断事务日志--只有事务日志备份才会截断事务日志(例如，完全备份完全独立于事务日志)。
然而，我的猜测是，重新组织所有索引会进行大量的数据处理--很可能这些索引会进入事务日志并导致您的问题。
您可以通过禁用或延迟某一天重新组织索引来测试这一点，并查看事务日志发生了什么。
Database Administration用户
发布于 2020-10-12 09:39:53
您是否度量过未将索引碎片整理的性能损失？这是一个很大的机会，你做所有这些工作而没有什么收获。例如，参见http://sqlblog.karaszi.com/fragmentation-the-final-installment/。
不要把碎片整理和获取新的统计数据混淆起来。如果您看到从碎片整理工作中获得的性能提升，可能是因为REBUILD为您提供了新的高质量的统计数据。
如果你真的需要破碎机，第一步就是只整理真正的碎片。这里有很多关于这方面的文章，并且在社区中已经很好地建立起来了，所以我想您已经有了这方面的内容。
此外，使用BULK_LOGGED恢复模型可能是一种选择，但请确保您熟悉它和(稍微(?))在此模式下运行会增加风险。
页面原文内容由Database Administration提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接：
https://dba.stackexchange.com/questions/276877
复制相关文章
相似问题
腾讯云开发者
