小编W3t*_*r3y的帖子

Microsoft SQL Server 2008 Enterprise 上的碎片索引是否会导致 RESOURCE_SEMAPHORE_QUERY_COMPILER 等待？

由于 RESOURCE_SEMAPHORE_QUERY_COMPILER 等待，我们的一个应用程序在过去两周内出现了停机。我们通过重建索引来“修复”它们；这只是在黑暗中的一个镜头。

应用程序供应商已经“深入研究”并“找到了根本原因”，他们声称这是索引碎片，他们的建议是实施我们已经实施的解决方法：每周重建索引（在发布时就已就位）和每晚重组（新）。

我担心的是应用程序供应商只是拿走了我们的工作并声称它是他们自己的。当我们最初偶然发现此修复程序时，我们认为它是一种不太可能导致问题的临时解决方法（很难反对重建/重组索引）。这个问题是在我们最大的用户繁忙时间之后开始的，所以使用率和索引碎片下降了。我们刚刚清除了大量数据，因此碎片百分比会变得更容易（当我们遇到信号量问题时达到峰值约 22%），但百分比仍然显着下降。

我担心的是，我们正在对这种情况进行创可贴，我们再次遇到问题只是时间问题。如果查询需要很长时间，我可以理解，但对我来说，编译查询时出现内存问题似乎很奇怪。

随机位信息：

• 两台应用服务器，并发用户约 130
• 专用数据库服务器
  • Microsoft SQL Server 2008 企业版
  • 2 x 至强 E5-2650 @ 2.3 GHz
  • 64 GB 内存（不知道详情）
  • 千兆以太网 x 3
• 数据库的数据文件是 199GB
• 根据 sp_spaceused
  • database_size 为 37831736 KB
  • index_size 为 54547920 KB
• 日志和数据文件是一个专用驱动器；两个驱动器都在 iSCSI SAN 上并且是 RAID10
• 数据库中没有分区

如果我遗漏了一些重要的事情，我深表歉意；让我知道，我会尝试添加它。

编辑：

当我们每天重新组织时，我们正在重新编译统计信息，很明显，当我们重建索引时会完成，所以我将花一些时间研究我们的查询计划。我真的很感谢指导。