2012-10-19 217 views
2

我剛剛從4.0升級到CRM 2011,我在應用程序日誌中看到很多錯誤,我認爲是由於電子郵件路由器。錯誤文本是「查詢執行時間30.0秒超過了10秒的閾值」。CRM 2011 EmailHashBase

下面是它的執行查詢:

WITH Candidates 
     (
      ActivityId 
     ) AS 
     (SELECT ActivityId 
     FROM  EmailHashBase WITH (NOLOCK) 
     WHERE ActivityId IN 
       (SELECT ActivityId 
       FROM  EmailHashBase WITH (NOLOCK) 
       WHERE HashType = 0 
        AND Hash IN (111682,1892164739,45,1824023892,54,3805,125879) 
       GROUP BY ActivityId 
       HAVING COUNT(ActivityId) >= 7 
       ) 
      AND HashType = 1 
      AND Hash IN (969105075,1418975348,547970098,1044570065,-1578559672,1137188287,-1492206818,1365121987,1893861533,-1313312639,-1829169632,-1685403462,-518982188,1123523219,284291011,-981044541,1790111815,-808308608,-599769785,971845046) 
     GROUP BY ActivityId 
     HAVING COUNT(ActivityId) >= 2 
     ) 
SELECT TOP 1 a.ActivityId 
FROM  ActivityPointerBase AS a WITH (NOLOCK) 
WHERE a.ActivityId IN 
      (SELECT ActivityId 
      FROM Candidates AS c 
      WHERE(
        (SELECT COUNT(*) 
          FROM EmailHashBase AS h 
          WHERE h.ActivityId = c.ActivityId 
           AND h.HashType = 0 
        ) 
        <= 7 
       ) 
      ) 
ORDER BY a.ModifiedOn DESC 

運行此查詢直接對數據庫需要長達一分鐘。我使用「Set Statistics IO ON」運行它,並得到如下結果:

Table 'Worktable'. Scan count 0, logical reads 0, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0. 
Table 'EmailHashBase'. Scan count 17696074, logical reads 53155625, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0. 
Table 'ActivityPointerBase'. Scan count 1, logical reads 5060, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0. 

SQL Server Execution Times: 
CPU time = 36567 ms, elapsed time = 36562 ms. 

顯然,EmailHashBase存在問題。我在哈希列上添加了一個非聚簇索引並重建了這些索引,但我仍然獲得了高掃描和邏輯讀取計數。

我無法更改查詢。

關於我能做些什麼來解決這個問題的任何建議?

+0

您可以在數據庫引擎優化顧問中運行此查詢並查看它的建議? –

+0

我通過調整顧問運行它,並沒有收到任何建議和估計的0%改善。 – chandley

+0

查詢是CRM正在執行還是已實施的自定義過程的一部分? –

回答

0

原因是數據庫優化顧問創建了一個索引,導致延遲。刪除索引已解決該問題。