我们每周运行Ola Hallengren’s index maintenance scripts次,每次运行几个小时.根据碎片阈值,脚本将重新组织或重新索引索引.我们观察到在重建索引期间,日志文件变得很大,这导致在日志传送期间过度消耗带宽.
然后是an article from Brent Ozar in which he says to stop worrying about SQL indexes：
Your hard drives are shared with other servers that are also making drive requests at the same time,so the drives will always be jumping all over the place to get data. Defragging your indexes is just meaningless busy work.
谷歌搜索这个问题导致不同的意见,大多数支持看似太短或弱的论点.我们的初步计划是调整维护脚本中的碎片阈值,以便重新组织它比重新索引更频繁.
最终的判决是什么？考虑到与运行每周维护工作相关的负担,是否值得对SAN上的sql索引进行碎片整理？
解决方法
各种各样的意见是因为环境的理想碎片整理策略应该取决于许多不同的因素.还有multiple potential layers of fragmentation在场.
说你的数据库存储在SAN上是不够的信息.例如：
>数据库文件是存储在单独的物理RAID组还是同一RAID组中？同一设备上还有哪些其他进程处于活动状态？你的备份文件也会在那里结束吗？您可能需要向SAN管理员询问此信息,因为它并不总是透明的.
>数据库的访问模式是什么？ OLTP通常是随机访问,但有时应用程序是表扫描快乐的,您无法更改其行为(ISV应用程序).应用程序是主要的,大多数是写入的,还是介于两者之间的某个位置？
>有performance SLAs in play during a recovery/failover period吗？
布伦特的帖子假设存在一个巨大的存储池,并且一切都共享它.这意味着物理磁盘很少空闲,因此大多数访问都是随机的.如果这是你的情况,那么建议适用,我在很大程度上同意它.虽然这种策略更容易管理,但它不一定是(a)您在环境中拥有的,或者(b)什么是适合您环境的最佳解决方案.
如果索引维护很繁琐,可以考虑不那么积极地进行,并且/或者在一周内分摊成本(即每天一次运行轻度维护,而不是每周一次的大量维护).
