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對在此過程中執行的每段程式碼和查詢進行準確的計時。這應該可以幫助您解決或至少解釋為什麼剩餘過程很慢。

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