dev*_*ter 16 index sql-server database-recommendation sql-server-2008-r2 san
我们的 SQL 服务器位于 SAN 上。它包含数十个 OLTP 数据库，其中一些数据库包含多个包含超过 100 万条记录的表。
我们每周都在运行Ola Hallengren 的索引维护脚本，每次运行几个小时。根据碎片阈值，脚本将重新组织或重新索引索引。我们观察到在重新索引期间，日志文件变得很大，这导致日志传送期间带宽消耗过多。
然后是Brent Ozar 的一篇文章，他说不要担心 SQL 索引：
您的硬盘驱动器与同时发出驱动器请求的其他服务器共享，因此驱动器总是会到处跳跃以获取数据。对索引进行碎片整理只是毫无意义的繁忙工作。
谷歌搜索这个问题会导致不同的意见，大多数支持似乎太简短或太弱的论点。我们的暂定计划是在我们的维护脚本中调整碎片阈值，以便它比重新索引更频繁地重新组织。
最终判决是什么？考虑到与运行每周维护作业相关的负担，是否值得对 SAN 上的 SQL 索引进行碎片整理？
Jon*_*gel 10
碎片整理策略有助于提高磁盘的扫描速度。
各种各样的意见是因为一个环境的理想碎片整理策略应该取决于许多不同的因素。还有多个潜在的碎片层在起作用。
说您的数据库存储在 SAN 上是不够的。例如：
数据库文件是存储在不同的物理 RAID 组还是同一个 RAID 组？在同一设备上还有哪些其他进程处于活动状态？你的备份文件也在那里吗？您可能需要向您的 SAN 管理员询问此信息，因为它并不总是透明的。
数据库的访问模式是什么？OLTP 通常是随机访问，但有时一个应用程序是 table-scan-happy 并且你不能改变它的行为（ISV 应用程序）。应用程序是主要读取、主要写入还是介于两者之间？
在恢复/故障转移期间是否存在性能 SLA？
Brent 的帖子假设有一个巨大的存储池，并且所有东西都共享它。这意味着物理磁盘很少空闲，因此大多数访问是随机的。如果这是你的情况，那么建议适用，我在很大程度上同意它。虽然这种类型的策略更容易管理，但不一定 (a) 您的环境中有什么，或 (b) 什么是最适合您的环境的解决方案。
如果索引维护很繁重，请考虑不那么积极地进行，和/或在一周内分摊成本（即，每天运行一次轻度维护，而不是每周一次进行大量维护）。
您还可以打开该SortInTempdb选项以潜在地减少发生在用户数据库中的日志记录量。