Sql-Server
SQL 性能問題 - 先正確配置伺服器還是逐個解決問題?
這適用於 SQL Server 2012。
我正在對 Dynamics AX 環境中的整體性能緩慢進行故障排除。一切都很慢 - 應用程序本身、報告、臨時等。馬上,我可以看到沒有配置 SQL Server 的最佳實踐 - MAXDOP、tempdb、特定於 Dynamics 的跟踪標誌和索引/碎片維護。我很確定存在效率低下的查詢、缺失或非最佳索引等。
我花了一點時間查看等待統計資訊,但現在我想知道是否應該首先應用所有推薦的最佳實踐(DynamicsAX 的行業標準最佳實踐),然後解決慢的問題,或者深入研究每個問題一個,並在它出現時解決它?我知道有些人會說,在您確定需要翻轉開關之前不要開始翻轉開關。
您將如何處理這種情況?
關於這一點有幾件事要說,Dynamics AX 性能不一定總是由 SQL Server 緩慢引起的,尤其是當您說“一切都很慢”時。
在 Dynamics AX 中遇到性能問題時,我傾向於使用以下方法:
首先查看所有相關伺服器上的資源(cpu 壓力、記憶體壓力、頁面預期壽命……)
- 每個 AOS、Client 和 Citrix 至少需要 4 個核心
- AX 對 CPU 延遲非常敏感,請確保您的 CPU 在 BIOS 中設置為高性能。如果你說一切都很慢,即使是簡單的形式,我的直覺也表明情況並非如此。
- 不僅在 SQL Server 上,而且在所有涉及的組件上執行標準檢查,例如磁碟延遲等。
然後根據最佳實踐驗證所有 SQL Server 設置是否正確
- 正確的跟踪標誌
- 正確的索引/統計維護
- 最大DOP
- 最大記憶體設置
- …
如果根據最佳實踐設置了所有相關的數據庫屬性,請查看它們
- 自動更新統計
通過檢查缺失的索引和緩慢的查詢來檢查數據庫設計
- 使用已知的 DMV 查詢(我傾向於喜歡Glenn Berry 腳本)
- 使用DynamicsPerf記錄 dmv 數據如果您聯繫支持人員,這將是他們讓您安裝的第一個工具
- 將慢速查詢記錄到SQL 語句跟踪日誌,以便您可以將它們與程式碼中的呼叫堆棧相關聯
查看應用程序設置中的已知問題(編號規則、數據庫日誌等)
- 查看Premier Field Engineers發現的 10 大問題
一旦您的設置可以正常工作並且某些程序仍然很慢,請使用Trace Parser對在此過程中執行的每段程式碼和查詢進行準確的計時。這應該可以幫助您解決或至少解釋為什麼剩餘過程很慢。