W3t*_*r3y 5 performance index sql-server-2008
Microsoft SQL Server 2008 Enterprise 上的碎片索引是否会导致 RESOURCE_SEMAPHORE_QUERY_COMPILER 等待?
由于 RESOURCE_SEMAPHORE_QUERY_COMPILER 等待,我们的一个应用程序在过去两周内出现了停机。我们通过重建索引来“修复”它们;这只是在黑暗中的一个镜头。
应用程序供应商已经“深入研究”并“找到了根本原因”,他们声称这是索引碎片,他们的建议是实施我们已经实施的解决方法:每周重建索引(在发布时就已就位)和每晚重组(新)。
我担心的是应用程序供应商只是拿走了我们的工作并声称它是他们自己的。当我们最初偶然发现此修复程序时,我们认为它是一种不太可能导致问题的临时解决方法(很难反对重建/重组索引)。这个问题是在我们最大的用户繁忙时间之后开始的,所以使用率和索引碎片下降了。我们刚刚清除了大量数据,因此碎片百分比会变得更容易(当我们遇到信号量问题时达到峰值约 22%),但百分比仍然显着下降。
我担心的是,我们正在对这种情况进行创可贴,我们再次遇到问题只是时间问题。如果查询需要很长时间,我可以理解,但对我来说,编译查询时出现内存问题似乎很奇怪。
随机位信息:
如果我遗漏了一些重要的事情,我深表歉意;让我知道,我会尝试添加它。
编辑:
当我们每天重新组织时,我们正在重新编译统计信息,很明显,当我们重建索引时会完成,所以我将花一些时间研究我们的查询计划。我真的很感谢指导。
Microsoft SQL Server 2008 Enterprise 上的碎片索引是否会导致 RESOURCE_SEMAPHORE_QUERY_COMPILER 等待?
不。至少不是直接的,甚至间接的不是碎片,但可能是过时的统计数据(重建索引也可以修复)。阅读SQL Server 2012 中的计划缓存和重新编译,尽管是 2012 年,其中很多内容仍然适用于 2008 年。问题是你的计划没有被重用,并且你会遭受大量的重新编译。阅读白皮书,它有大量资源并解释了很多。
归档时间: |
|
查看次数: |
619 次 |
最近记录: |