Dynamics CRM Audit Performance Troubleshooting

• 2020 年 7 月 13 日
• 筆記
• Dynamics CRM

記一次Dynamics CRM Audit 查詢失敗的問題。

客戶環境現象：由於業務邏輯需要使用RetrieveAuditDetailRequest API查詢相關Record的詳細更改信息。但查詢過程中偶爾會出現失敗的情況，出錯原因提示是

System.TimeoutException: ‘The request channel timed out while waiting for a reply after 00:01:59.9929956. Increase the timeout value passed to the call to Request or increase the SendTimeout value on the Binding. The time allotted to this operation may have been a portion of a longer timeout.’

很明顯，超時了。

那麼為什麼會出現超時呢？

第一感覺：會不會是因為Audit表被佔用了，導致長時間等待出現超時的呢？但經過通過sp_who2排查後發現並沒有block的sql。

那會不是是因為網絡原因導致的呢？隨後使用內網在頁面上打開Record的Audit時同樣失敗，排除。

看一下Audit數據量有多少吧？一看，好傢夥，一千多萬的數據量，10多個分區表。那會不會是因為索引重建失敗導致查詢過慢而失敗的呢？

因為Dynamics CRM默認每天都會使用Microsoft Dynamics CRM Asynchronous Processing Service (maintenance) service 執行一次p_ReindexAll的操作。

執行時間同樣默認一個表會限制在2min內，詳細信息見//soluciones-microsoft.blogspot.com/2018/07/how-to-improve-microsoft-dynamics-365.html。

於是看一下job執行的記錄，發現根本沒有。怎麼可能，繼續看Config DB中是不是有人動過執行maintenance的schedule，

Select NextRunTime,RecurrenceStartTime,*
from MSCRM_CONFIG.dbo.ScaleGroupOrganizationMaintenanceJobs
where OperationType = 30

果真，已經被更新為不執行maintenance job了。

陷入僵局…

誒，看一下RetrieveAuditDetailRequest內部都會幹些什麼吧。於是本地環境使用Sql Server Profile抓了下Sql語句，嘿嘿，這貨竟然會這樣實現：

1、通過Audit Id將AuditBase表中的數據查詢出來。

2、通過Audit 中的Object Id將Record數據查出來。

3、通過Audit 中的ChangeData將所有ChangeData中的Id每一個組成一條sql查詢出來。

重點在#3，我們一個ChangeData中的Id足足有幾萬條誒。終於找到具體原因了，大量的sql語句導致查詢時間過長而timeout。

介於時間以及整體的穩定性考慮，暫時將連接Dynamics的OrganizationServiceProxy中的Timeout Property設置為30分鐘解決。

但是這麼做並不能治本，因為頁面上的Audit依然會有問題，這該如何解決？客戶數據是萬萬不能刪除的。如果有大神知道，麻煩評論區告知，感激~~