免費AI編程助手
最有效的數(shù)據(jù)庫管理員不會根據(jù)表面上看起來很明顯的東西做出草率的決定。他們更深入地研究問題，以便在采取行動之前更好地了解根本原因。
這是優(yōu)化 SQL Server 的一種非常重要的方法。以下是我看到的前五個 SQL Server 性能問題，以及為什么永遠不要草率假設(shè)并對所有事情應(yīng)用批判性鏡頭很重要。
1. Tempdb PAGELATCH 爭用
這個日益普遍的問題通常是由于系統(tǒng)大量使用 tempdb 進行某種類型的提取、轉(zhuǎn)換和加載 (ETL) 過程。如果它是一個持續(xù)的“實時”風格的 ETL 過程，這尤其常見。
癥狀可能會有所不同，但有些事情總是相同的：tempdb 中的高 PAGELATCH 等待和使用 tempdb 的進程記錄的性能不佳。我通常會遵循 Performance Advisor 中對 Top SQL 的等待，并查看大量使用 Top SQL 中列出的臨時表的查詢。這些查詢通常以毫秒為單位運行，并且永遠不應(yīng)計入服務(wù)器的“頂級 SQL”。這可能會讓人們覺得這些查詢是問題的很大一部分，但事實并非如此。查詢是真正問題的受害者。
一旦懷疑是這種情況，我通常會跳轉(zhuǎn)到 Performance Advisor 中的“磁盤活動”選項卡以查看 tempdb 的配置方式。大多數(shù)時候我實際上看到的是同樣的事情：一個繁忙的臨時數(shù)據(jù)庫，定義了一個數(shù)據(jù)文件。從這里開始，我通常會建議重新配置 tempdb。
2. 期待自動更新統(tǒng)計信息以保持統(tǒng)計更新
這里的問題是觸發(fā)自動統(tǒng)計更新的閾值在大多數(shù)情況下最終是相同的，即使對于非常大的表也是如此。閾值約為表中行的 20%。在一個非常大的表上，需要大量數(shù)據(jù)更改才能觸發(fā)更新。
之所以列出該列表，是因為數(shù)據(jù)庫管理員似乎真的很驚訝地發(fā)現(xiàn)自動更新并沒有像顧名思義那樣處理事情。然后也有許多 DBA 認為應(yīng)該由他們的維護工作來處理。然后在查看維護后，他們大部分時間都在進行索引重組，這也不會更新統(tǒng)計信息（盡管重建會）。
教訓是密切關(guān)注統(tǒng)計數(shù)據(jù)并確保它們定期更新，尤其是在越來越普遍的大表上。另一種選擇是使用跟蹤標志 2371 來實際更改用于觸發(fā)更新的公式。
3. CXPACKET 等待類型
這是我在大型 SQL Server 系統(tǒng)上看到的一種最常見的等待類型，當有人讓我研究它們的查詢性能時。
可悲的是，我仍然看到很多人做出最初的假設(shè)，即應(yīng)該通過讓查詢或整個 SQL Server 將最大并行度 (MAXDOP) 設(shè)置為 1 來解決問題。 通常，可以通過適當?shù)乃饕齺硖幚韱栴}或統(tǒng)計維護。也可能是為此查詢緩存的計劃不是最佳的，您可以使用 sp_recompile 將其標記為重新編譯，在查詢級別設(shè)置重新編譯，或者只是使用帶有計劃句柄的 DBCC FREEPROCCACHE 驅(qū)逐計劃。最好在決定將 MAXDOP 更改為 1 之前用盡這些選項，因為您可能會在沒有意識到的情況下丟棄大量處理能力。
4. 誤解“超時在...完成之前到期”
這個是巨大的。除了一些非常極端的行為之外，您可能會為 SQL Server 處理兩種基本類型的超時。這些是連接超時和操作（或查詢）超時。在這兩種情況下，這些值都是由連接到 SQL Server 的客戶端設(shè)置的。在服務(wù)器端，有一個遠程查詢超時設(shè)置，但這是非常極端的情況。
操作超時是最常見的，也可能是我遇到的最容易被誤解的情況。原因歸結(jié)為一個簡單的因素：執(zhí)行命令的客戶端設(shè)置了等待命令完成的最長時間。如果在完成之前達到此最大值，則中止命令。從客戶端引發(fā)錯誤。
通常，超時錯誤會引發(fā)恐慌模式，因為錯誤看起來很嚇人。實際情況是，這與在 SQL Server Management Studio 中點擊停止按鈕沒有太大區(qū)別，因為查詢花費的時間太長。它將在錯誤 = 2（中止）的探查器跟蹤中顯示完全相同。
像這樣的超時告訴我們查詢花費的時間比預期的要長。我們應(yīng)該進入“性能調(diào)整”模式而不是“某些東西壞了”模式。來自客戶端的錯誤信息是關(guān)于您可以開始集中調(diào)整工作的位置的好信息。
對于將 RDBMS 用于存儲庫的任何系統(tǒng)來說都是如此。您的數(shù)據(jù)庫時不時地需要一些 TLC。沒有它，您可能確實會遇到客戶的一些超時。我們花費大量時間在查詢發(fā)布之前對其進行性能優(yōu)化，但適當?shù)木S護將確保它們繼續(xù)按預期運行。
5. 內(nèi)存壓力
這是一個很大的問題，因為我經(jīng)常看到它，也因為它經(jīng)常被誤認為磁盤性能不佳。
SQL Server 中有很多緩存，但最著名的是數(shù)據(jù)緩存（又名緩沖池）。描述數(shù)據(jù)緩存最簡單的方式是它是存儲在內(nèi)存中的數(shù)據(jù)，而不是持久化到磁盤。將大量數(shù)據(jù)長期存儲在內(nèi)存中是可取的，因為在內(nèi)存中處理數(shù)據(jù)通常比必須執(zhí)行物理 I/O 快得多。
通常，記憶壓力表現(xiàn)為幾種不同的癥狀。當單獨查看時，其中一些癥狀可能會導致您得出錯誤的、有時代價高昂的結(jié)論。
兩個誤導性癥狀是您可能會開始看到整個磁盤子系統(tǒng)的延遲高于正常延遲，并且您可能會開始看到與磁盤活動相關(guān)的異常高等待。如果您只查看這兩個癥狀，您可能會得出結(jié)論，您需要在您的磁盤系統(tǒng)上工作。
這就是為什么在一個儀表板上顯示所有相關(guān)指標如此重要的原因。您必須著眼于更大的圖景，將與內(nèi)存相關(guān)的數(shù)據(jù)與磁盤活動和等待一起可用，有助于更清晰地了解真正發(fā)生的情況。
通常，我會看到此服務(wù)器的 PLE（頁面預期壽命）相當?shù)?。緩沖區(qū)緩存越大，PLE 的“臨界”閾值就越高。流入和流出緩沖區(qū)的數(shù)據(jù)越多，發(fā)生“流失”時的情況就越糟。另一個考慮因素是非均勻內(nèi)存訪問 (NUMA)。當涉及多個 NUMA 節(jié)點時，計算 PLE 計數(shù)器的方式可能會導致此值非常具有誤導性。
我通常還會看到持續(xù)較高的惰性寫入器活動和 SQL Server 頁面錯誤（SQL Server 進入磁盤）。有時我會看到我所說的緩沖區(qū)撕裂。當數(shù)據(jù)緩沖區(qū)上下波動時會發(fā)生這種情況，經(jīng)常在 Performance Advisor 的歷史圖表上創(chuàng)建鋸齒狀（或撕裂）邊緣。我還可能看到異常大的計劃緩存減少了數(shù)據(jù)緩存的可用內(nèi)存。
所有這些因素共同構(gòu)成了記憶壓力。有多種方法可以處理它們，但重要的是這不是磁盤問題。我不會根據(jù)這種情況打電話給您的存儲區(qū)域網(wǎng)絡(luò)聯(lián)系人并訂購新硬件。一旦控制了內(nèi)存壓力情況，SQL Server 就不需要那么多去磁盤了，一些與磁盤相關(guān)的癥狀可能會完全消失！
結(jié)論
隨著組織面臨新的數(shù)據(jù)庫需求，首要的 SQL Server 性能問題/主題將繼續(xù)發(fā)展。如果從所有這些潛在問題中得出一個主要結(jié)論，那就是始終考慮性能的全貌，因為脫離上下文查看一個因素可能會嚴重限制您對解決方案的選擇。
