Sql-Server

SQL 性能問題 - 先正確配置伺服器還是逐個解決問題?

  • November 29, 2016

這適用於 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 語句跟踪日誌,以便您可以將它們與程式碼中的呼叫堆棧相關聯
  • 查看應用程序設置中的已知問題(編號規則、數據庫日誌等)

一旦您的設置可以正常工作並且某些程序仍然很慢,請使用Trace Parser對在此過程中執行的每段程式碼和查詢進行準確的計時。這應該可以幫助您解決或至少解釋為什麼剩餘過程很慢。

引用自:https://dba.stackexchange.com/questions/141247