整理索引臃肿日志文件
我很难将索引“优化”为日志记录最少的操作。在执行索引维护之前，数据库恢复模型将从完全日志转换为大容量日志。根据碎片百分比，每个索引都是重建或重组(或不采取任何操作)的接收者。索引维护完成后，恢复模型恢复为满。
一个数据库给我带来了一些痛苦。数据文件的容量约为64 The (包括任何空闲空间)。碎片整理操作将日志文件膨胀到38 it，直到它填充了逻辑驱动器。然后，17级警报开始滚动。
我试着在测试环境中复制这个。多次尝试使用不同的恢复模型、索引REORG重建、不同的事务隔离级别、对vs OFF的读取提交快照、不同的索引碎片级别等。然而，没有其他测试变体。这是令人沮丧的，因为我无法复制在生产中发生的事情。
我遗漏了什么？如何在不增加日志文件的情况下优化索引？
更新09/23/2015
不出所料，Ola Hallengren的名字在我发帖后不久就出现了。虽然我不使用他的脚本，但我对它们有点熟悉。对于那些感兴趣的人来说，有一个很棒的PASS会话视频--Ola是主持人。在48分钟标记附近，一位听众问了一个类似我的问题。
回答 2
Database Administration用户
发布于 2015-08-26 16:25:22
您可以在REORG过程中清除日志，因为它不是作为单个事务完成的。日志膨胀取决于索引碎片级别和完成的工作量。
同样，REORG是在所有恢复模型上完全记录的操作。https://technet.microsoft.com/en-us/library/ms191484(v=sql.105).aspx
Database Administration用户
发布于 2015-08-29 04:22:27
参考Aaron Bertrand提供的链接。有一组有限的操作是最少记录的，但是不包括reorg/reorg，也就是碎片整理。如果您希望最小化这种影响，就必须执行Cibi提到的增量重操作，或者只分配所需的空间，如果这种情况需要定期发生。
我以前必须在生产中使用增量reorg (start reorg，stop，backup，start reorg，stop，backup日志，rinse/repeat)。现在可能是检查是否需要所有给您带来悲伤的索引的好时机。Glenn的诊断查询可以帮助您找到未使用的索引，这些索引被不必要地更新(读为分段)。您还可以尝试Kendra的服务提供商_闪动指数，它为您提供了大量关于索引的详细信息。
https://dba.stackexchange.com/questions/112268
复制相似问题
腾讯云开发者
