sql-server – 在SAN情形中对SQL索引举办碎片清算是否有任何甜头

我们的SQL处事器位于SAN上.它包括很多OLT??P数据库,个中一些包括多个包括高出1m记录的表.

我们每周运行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)什么是得当您情形的最佳办理方案.

假如索引维护很繁琐,可以思量不那么起劲地举办,而且/可能在一周内分摊本钱(即天天一次运行轻度维护,而不是每周一次的大量维护).

您还可以打开SortInTempdb选项,以隐藏地减罕用户数据库中产生的日记记录量.

（编辑：湖南网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!