相关疑难解决方法(0)

在设置新的 SQL Server 时，我使用以下代码来确定设置的良好起点MAXDOP：

/* 
   This will recommend a MAXDOP setting appropriate for your machine's NUMA memory
   configuration.  You will need to evaluate this setting in a non-production 
   environment before moving it to production.

   MAXDOP can be configured using:  
   EXEC sp_configure 'max degree of parallelism',X;
   RECONFIGURE

   If this instance is hosting a Sharepoint database, you MUST specify MAXDOP=1 
   (URL wrapped for readability)
   http://blogs.msdn.com/b/rcormier/archive/2012/10/25/
   you-shall-configure-your-maxdop-when-using-sharepoint-2013.aspx

   Biztalk (all versions, including 2010): 
   MAXDOP = 1 is only required on the BizTalk …

我们的 SQL 服务器位于 SAN 上。它包含数十个 OLTP 数据库，其中一些数据库包含多个包含超过 100 万条记录的表。

我们每周都在运行Ola Hallengren 的索引维护脚本，每次运行几个小时。根据碎片阈值，脚本将重新组织或重新索引索引。我们观察到在重新索引期间，日志文件变得很大，这导致日志传送期间带宽消耗过多。

然后是Brent Ozar 的一篇文章，他说不要担心 SQL 索引：

您的硬盘驱动器与同时发出驱动器请求的其他服务器共享，因此驱动器总是会到处跳跃以获取数据。对索引进行碎片整理只是毫无意义的繁忙工作。

谷歌搜索这个问题会导致不同的意见，大多数支持似乎太简短或太弱的论点。我们的暂定计划是在我们的维护脚本中调整碎片阈值，以便它比重新索引更频繁地重新组织。

最终判决是什么？考虑到与运行每周维护作业相关的负担，是否值得对 SAN 上的 SQL 索引进行碎片整理？