SQL Server 活動監視器：資料庫管理員完整指南 [2026]

活動監視器與第三方工具： 像 SolarWinds Database Performance Analyzer 這樣的商業監控解決方案提供歷史追蹤、警報和進階分析功能，而 Activity Monitor 則缺乏這些功能。但是，Activity Monitor 不需要額外的配置。ost 或安裝。

1.4 資料庫管理員的主要收益

活動監視器具有多項優勢，使其成為必不可少的資料庫管理員工具：

攝氏度ost: 作為內建的 SQL Server 使用 Management Studio 功能，無需支付許可費或進行部署。
實時監控： 即時查看目前伺服器活動，刷新間隔可配置，從 1 秒到 1 小時不等。
綜合行動： 右鍵單擊進程可終止會話、查看查詢詳細資料或啟動 SQL Server 分析器追蹤——全部來自工具內部。
多重視角： 透過五個專門的窗格從不同角度查看伺服器運行狀況，每個窗格都專注於效能的特定方面。
快速故障排除： 識別 most 常見效能問題可在幾分鐘內解決，加快平均問題解決速度。
進入門檻低： 無需任何高級知識即可開始有效使用該工具，但深入了解 SQL Server 專業知識有助於解讀。

2. 獲得 Started 與活動監視器

要有效利用活動監視器，您需要了解啟動工具的前提條件、所需權限和各種方法。

2.1 先決條件和系統要求

要使用 SQL Server 活動監視器，你需要 SQL Server SSMS（管理工作室）安裝在您的本機電腦或跳轉伺服器上。活動監視器工具已進行了重大重新設計。 SQL Server 2008 年，因此本指南中的資訊適用於 SQL Server 2008 及更高版本。

您必須具備網路連線。 SQL Server 您要監控的實例。對於雲端平台ost要存取資料庫，通常需要 VPN 連線或正確配置的防火牆規則。

活動監視器適用於所有版本 SQL Server包括 Express、Standard 和 Enterprise 版本。該工具本身在客戶端電腦上的 SSMS 中運行，因此伺服器資源僅受其執行的監控查詢的影響。

2.2 必要權限

正確的權限對於活動監視器的正常運作至關重要。如果沒有對應的權限，您可能會看到空白顯示或收到存取被拒絕的錯誤提示。

2.2.1 查看伺服器狀態權限

这 查看伺服器狀態 使用活動監視器的首要條件是擁有相應的權限。此伺服器級權限可讓您查看所有活動進程及其相關指標。

若要授予此權限，伺服器管理員可以執行下列命令：

GRANT VIEW SERVER STATE TO [YourLoginName];

如果沒有 VIEW SERVER STATE 指令，活動監視器可能會打開，但其任何窗格中都不會顯示任何資料。

2.2.2 資料庫級權限

要查看「資料檔案 I/O」窗格中的信息，您需要額外的權限。具體來說，您必須擁有以下組合之一：

創建數據庫 許可，或
修改任何資料庫 許可，或
查看任何定義 允許

這些權限必須與以下條件結合使用： 查看伺服器狀態 實現完整的活動監視器功能。

2.2.3 權限故障排除

如果「活動監視器」開啟但未顯示任何數據，則可能是權限問題。ost 常見原因。請檢查您的登入帳戶是否擁有伺服器層級的「查看伺服器狀態」權限。您可以透過執行以下命令來驗證您的權限：

SELECT * FROM fn_my_permissions(NULL, 'SERVER');

請在 permission_name 欄位中尋找「VIEW SERVER STATE」權限。如果該權限缺失，請聯絡資料庫管理員授予其權限。

2.3 如何在 SSMS 中開啟活動監視器

SQL Server Management Studio 提供了四種不同的啟動活動監視器的方法，您可以根據自己的工作流程偏好靈活選擇。

2.3.1 方法 1：從工具列

開啟「活動監視器」最快捷的方法是使用工具列圖示：

連接到您的 SQL Server 實例 SQL Server 管理工作室。
在標準工具列中找到「活動監視器」圖示（它類似於帶有綠色播放按鈕的長條圖）。
點擊圖示啟動活動監視器。

當您已經在 SSMS 中工作並且需要快速檢查伺服器活動時，此方法是最快的。

2.3.2 方法二：從物件資源管理器

您也可以直接從物件資源管理器啟動活動監視器：

在物件資源管理器中，找到 SQL Server 您要監控的實例。
右鍵單擊實例名稱。
選擇 活動監視器 從上下文菜單。

當連接到多個伺服器時，這種方法很有用，因為它能確保您監控的是正確的實例。

2.3.3 方法 3：使用鍵盤快速鍵

對於以鍵盤操作為主的使用者而言， SQL Server Management Studio 提供了一個專用快捷方式：

確保 SSMS 是活動窗口，並且您已連接到實例。
媒體中心 按Ctrl + 其他 + A.
將開啟物件資源管理器中目前選定實例的活動監視器。

請注意，「活動監視器」將連接到您在物件資源管理器中選擇的任何伺服器實例，因此請確保在使用此捷徑之前已選擇正確的實例。

2.3.4 方法 4：從選項選單（S）tartup 配置）

如果您經常使用活動監視器，您可以將 SSMS 設定為在每次啟動它時自動啟動。tar申請表：

In SQL Server 管理工作室，導航至工具 -> 選項.
在「選項」對話方塊中，展開環境，然後選擇 Star管.
繼承施羅斯家族先行者與原創者的血統，我們是唯一持續進展的分支 在 star管 下拉列表，選擇 開啟物件資源管理器和活動監視器.
選擇 OK.

下次啟動 SSMS 並連接到伺服器時，活動監視器將與物件資源管理器一起自動開啟。

3. 了解活動監視器窗格

活動監視器將資訊組織成五個可展開的窗格，每個窗格都提供伺服器活動的不同視角。了解每個窗格顯示的內容對於有效排查故障至關重要。

3.1 概覽窗格

概覽窗格顯示四個即時圖表，讓您快速了解您的健康狀況。 SQL Server 例如，這些圖表會以可設定的時間間隔更新，幫助您一目了然地辨識異常模式。

3.1.1% 處理器時間

此圖顯示了處理器執行非空閒執行緒所花費的時間百分比。 SQL Server 跨所有 CPU 的實例。該值表示 SQL Server指的是處理器利用率，而不是整個伺服器的 CPU 使用率。

如果處理器時間持續接近或達到 100%，則表示伺服器受 CPU 限制。這可能表示查詢效率低、缺乏索引或硬體容量不足。使用「最近的高成本查詢」窗格來確定哪些查詢消耗了過多的 CPU 資源。ost 中央處理器。

3.1.2 等待任務

此指標顯示等待資源釋放才能繼續執行的任務數量。任務可能等待 CPU、I/O、記憶體或鎖。

持續存在大量等待任務顯示資源爭用。「資源等待」窗格提供了有關導致等待的資源類型的更多詳細資訊。

3.1.3 資料庫 I/O (MB/s)

此圖顯示了記憶體和磁碟之間的資料傳輸速率。它綜合考慮了讀取和寫入操作，單位為兆位元組每秒。

資料庫 I/O 峰值可能表示查詢正在執行大型表掃描、日誌記錄活動過多或正在執行檢查點操作。「資料檔案 I/O」窗格會依資料庫和檔案細分 I/O 活動。

3.1.4 每秒批量請求數

此指標代表了以下數量： SQL Server 實例每秒接收的批次。一個批次可以是單一語句，也可以是同時提交的多個語句。

該值可反映伺服器的整體活動情況。正常工作時間內批量請求突然下降可能表示應用程式連線有問題或使用者體驗出現問題。

3.1.5 設定刷新間隔

您可以自訂活動監視器更新資料的頻率：

在概覽窗格中任意位置按一下滑鼠右鍵。
選擇 刷新間隔.
從預定義值中選擇一個時間間隔：1 秒、5 秒、10 秒（預設）、30 秒、1 分鐘或 1 小時。

將刷新間隔設定為低於 10 秒會增加伺服器的監控開銷。對於高負載的生產系統，建議使用 30 秒或更長的間隔，以最大程度地減少影響。

3.2 進程窗格

「進程」窗格顯示有關目前正在執行的會話的資訊。 SQL Server 例如，此窗格對於識別誰在執行什麼操作以及發現阻塞性問題至關重要。

3.2.1 理解過程訊息

「進程」窗格中的每一行代表伺服器上的一個活動會話。此窗格顯示來自所有資料庫和所有使用者的會話，讓您可以全面了解伺服器活動。

顯示的資訊包括登入名稱、應用程式名稱、host名稱、正在存取的資料庫和目前命令。這有助於您將資料庫活動與特定使用者或應用程式關聯起來。

3.2.2 主要列說明

了解關鍵列有助於您有效解讀過程資訊：

會話 ID： 每個連線都有一個唯一的識別碼。系統進程使用否定會話 ID。
用戶進程： 指示這是使用者會話（是）還是系統進程（否）。
登錄： 这 SQL Server 登入名稱或與會話關聯的 Windows 帳戶。
數據庫： 目前會話的資料庫上下文。
任務狀態： 顯示會話目前狀態（運行中、已暫停、已休眠等）。
命令： 正在執行的命令類型（SELECT、INSERT、UPDATE 等）。
應用： 建立連接的應用程式名稱。
等待時間： 會話等待資源的時間（以毫秒為單位）。
等待類型： 會話正在等待的特定資源類型。
CPU 時間： 此會話自連線以來消耗的總 CPU 時間。
記憶體使用： 目前分配給會話的記憶體量（以 KB 為單位）。

3.2.3 過濾和排序過程

「進程」窗格包含強大的篩選功能，可協助您專注於相關會話：

點擊任意列標題中的下拉箭頭。
篩選器顯示該列的可用值，包括全部, 空白以及 非空白.
選擇特定值，篩選顯示內容，僅顯示這些會話。

例如，您可以進行篩選 任務狀態 僅顯示正在運行的會話，或進行篩選 數據庫 查看針對特定資料庫的活動。

您也可以透過點擊列標題來按列排序。單擊一次按升序排列，單擊兩次按降序排列。

3.2.4 辨識阻塞和被阻塞的會話

「進程」窗格可協助您識別阻塞情況，即一個會話阻止其他會話繼續進行：

被屏蔽： 顯示阻塞目前會話的會話 ID。如果此欄位包含值，則表示該會話正在等待另一個會話持有的鎖定。
頭部阻擋器： 如果此會話阻塞了其他會話但本身未被阻塞，則顯示「1」。這是阻塞鏈的根本原因。

要調查阻塞問題，首先要確定阻塞頭（阻塞頭列中標記為「1」的會話），然後檢查它正在做什麼，並決定是讓它完成還是終止它。

3.2.5 進程操作（終止、詳細資料、追蹤）

活動監視器可讓您對單一會話執行操作：

在「進程」窗格中右鍵單擊任意會話。
你會看到以下幾個選項：
- 詳情： 顯示此會話執行的最後一個命令。
- 終止進程： 終止會話（請謹慎使用）。
- 追蹤過程 SQL Server 分析器： 推出 SQL Server 輪廓並自動篩選，僅顯示本次會話的活動。

「詳細資訊」選項會顯示命令文本，但請注意，這只是… 最後命令已執行—它可能已停止運行。當您需要查看會話正在執行的完整命令序列時，「追蹤」選項特別有用。

3.3 資源等待窗格

「資源等待」窗格匯總了等待統計訊息，顯示會話正在等待哪些類型的資源。ost 經常需要這樣做。這些資訊對於診斷效能瓶頸至關重要。

3.3.1 理解等待統計數據

當 SQL Server 如果無法立即授予資源請求（例如鎖定、CPU 時間或記憶體），請求任務將進入等待狀態。等待統計資料會追蹤這些等待時間，幫助您了解伺服器在哪些方面花費了時間等待而不是執行任務。

「資源等待」窗格從系統動態管理檢視（例如 sys.dm_os_wait_stats 和 sys.dm_exec_requests）收集資料。在每個刷新間隔，它都會計算當前快照與上一個快照之間的差異，從而顯示每個等待類型的累積速率。

3.3.2 等待類別

活動監視器將數百種不同的等待類型歸納為更廣泛的類別，以簡化解釋：

中央處理器： 等待 CPU 時間可用的任務。
緩衝鎖存器： 等待短期同步對象，以保護對記憶體中資料頁的存取。此類別包括頁面閂鎖等待 (PAGELATCH_*)。
鎖定： 會話持有其他會話需要的鎖而導致的等待。
內存： 等待排序和哈希等操作所需的記憶體授權。
網路 I/O： 等待向客戶端發送資料或從客戶端接收資料。
SQL CLR： 與公共語言運行時執行相關的等待。

這種分組方式雖然簡化了視圖，但也掩蓋了一些重要的細節。例如，「緩衝區閂鎖」可能會將 PAGELATCH_SH、PAGELATCH_UP 和 PAGELATCH_EX 等待事件歸為一類，而這些事件對效能的影響各不相同。

3.3.3 解讀等待時間與等待任務

「資源等待」窗格顯示每個等待類別的兩個關鍵指標：

累計等待時間（毫秒）： 此等待類別在目前刷新間隔內累積的總毫秒數。
等待任務： 目前該類別中等待資源的任務數量。

等待時間值尤其值得關注。如果刷新間隔為 10 秒，且某個類別的等待時間為 20,000 毫秒，則表示存在多個並發等待（20,000 毫秒 / 10,000 毫秒 = 該間隔內 2 個並發等待的平均值）。

3.3.4 識別效能瓶頸

使用「資源等待」窗格來確定伺服器將資源消耗在哪裡。ost 等待時間：

展開「資源等待」窗格。
觀察等待時間最長的等待類別。
排序 累計等待時間 查看哪些資源是 most 受到限制。

高緩衝區閂鎖等待通常表示記憶體中存在資料頁爭用，這可能暗示存在 I/O 瓶頸或 tempdb 爭用。高鎖等待指向阻塞問題。高記憶體等待表示查詢操作的記憶體授權不足。

3.4 資料檔 I/O 面板

資料檔案 I/O 窗格顯示伺服器上每個資料庫檔案的磁碟活動，可協助您識別 I/O 瓶頸並了解磁碟使用率模式。

3.4.1 理解 I/O 指標

「資料檔案 I/O」窗格顯示每個資料庫檔案的多個指標：

數據庫： 資料庫名稱。
文件類型： 可以是資料（包括表和索引）或日誌（交易日誌）。
邏輯名稱： 邏輯檔名，定義於 SQL Server.
MB/秒讀取： 從該檔案讀取資料的速率。
MB/秒寫入速度： 寫入此檔案的資料速率。
反應時間（毫秒）： 此檔案的 I/O 操作平均回應時間。

這些指標與概覽窗格的刷新間隔相同，讓您可以即時了解磁碟活動。

3.4.2 辨識 I/O 瓶頸

注意以下這些可能表明 I/O 效能問題的模式：

反應速度快： 回應時間持續高於 15-20 毫秒錶示磁碟子系統運作緩慢。反應時間高於 50 毫秒則表示有嚴重的 I/O 瓶頸。
不平衡負載： 如果某個資料檔案的 I/O 速率明顯高於同一資料庫中的其他文件，則可以透過新增其他檔案來分散負載，從而獲得更好的效果。
Tempdb 活動太多： tempdb 檔案上的高 I/O 率通常表示查詢會產生大型中間結果集或使用效率低下的執行計劃。

3.4.3 資料庫文件分析

使用「資料檔案 I/O」窗格可以了解資料庫如何使用磁碟資源：

展開「資料檔案 I/O」窗格。
排序 MB/秒讀取 or MB/秒寫入 識別 most 活動文件。
注意任何活動量持續很高或回應時間過長的文件。
將此資訊與「最近的高成本查詢」窗格進行交叉比對，以確定哪些查詢導致了 I/O 負載。

3.5 近期高成本查詢窗格

「最近的高成本查詢」窗格通常是 most 這是一個非常有用的面板，可用於排查應用程式效能問題。它會顯示消耗大量伺服器資源的查詢，幫助您發現最佳化機會。

3.5.1 理解查詢指標

活動監視器會顯示每個高成本查詢的多個指標：

執行次數/分鐘： 過去一分鐘內查詢執行了幾次？
CPU（毫秒/秒）： 此查詢每秒消耗的 CPU 時間。
物理讀取次數/秒： 此查詢每秒物理磁碟讀取次數。
邏輯寫入/秒： 每秒邏輯寫入次數（到緩衝區快取）。
邏輯讀取/秒： 每秒邏輯讀取次數（從緩衝區快取讀取）。
平均持續時間（毫秒）： 此查詢的平均執行時間。
計劃數量： 此查詢的快取執行計劃數量。

這些指標不僅能幫助你了解哪些查詢成本高，而且 為什麼 它們價格昂貴，而且運作頻率也不高。

3.5.2 排序選項

您可以按不同指標對「最近的高成本查詢」窗格進行排序，以查找不同類型的問題：

點擊任意列標題即可按該指標排序。
常見的分類策略包括：
- 按CPU使用率排序： 尋找使用 m 的查詢ost 處理器時間。
- 依執行次數/分鐘排序： 找出運行頻率過高的查詢。
- 依實體書閱讀量排序： 尋找導致 m 的查詢ost 磁碟 I/O。
- 依平均時長排序： 尋找長時間運行的查詢。

在排查效能問題時，請嘗試按多個列排序，以獲得不同的視角。 CPU 使用率適中但每分鐘執行次數極高的查詢可能才是真正的問題。

3.5.3 檢視查詢文本

若要查看開銷較大的查詢背後的實際 SQL 語句：

在「最近的高成本查詢」窗格中，以滑鼠右鍵按一下查詢行。
選擇 編輯查詢文本.
此時會開啟一個新的查詢窗口，顯示完整的 SQL 語句。

這樣一來，您可以檢查查詢邏輯並找出潛在的最佳化機會。然後，您可以複製查詢文字以測試修改後的版本。

3.5.4 分析執行計劃

執行計劃會告訴你如何 SQL Server 執行查詢，揭示缺少索引或不合適的連接類型等效率低下的問題：

在「最近的高成本查詢」窗格中，以滑鼠右鍵按一下查詢行。
選擇 展示執行計劃.
SQL Server Management Studio 會以圖形方式顯示查詢的執行流程。

尋找消耗查詢資源比例較大的操作ost此外，也會發出關於統計資訊或索引缺失以及意外表掃描操作的警告。這些警告通常表明優化工作的重點應該放在哪裡。

3.5.5 識別問題查詢

在「最近高成本查詢」窗格中留意以下模式：

過度處決： 每分鐘執行數千次的查詢可能表示存在 N+1 查詢問題，即應用程式程式碼在循環中呼叫資料庫。
高強度體力閱讀： 物理讀取頻率高的查詢頻繁地存取磁碟，這表示缺少索引或查詢編寫不佳。
高CPU佔用率但低持續時間： 許多快速查詢累積起來會消耗大量 CPU 資源，其對伺服器效能的影響與少數慢速查詢一樣大。
多個計劃數量： 執行計劃過多的查詢可能會出現參數嗅探問題，或者非參數化查詢會導致計劃快取膨脹。

4. 使用活動監視器進行效能故障排除

當您有系統地使用「活動監視器」來診斷和解決效能問題時，它的優勢才能真正體現出來。本節將介紹常見的故障排除場景以及對應的解決方法。

4.1 診斷過多的查詢執行

m之一ost 常見的效能問題是查詢執行頻率遠高於必要頻率，這通常是由於應用程式設計問題造成的。

4.1.1 識別重複查詢

若要找出執行頻率過高的查詢：

打開活動監視器並展開 近期昂貴的查詢 窗格。
排序 執行次數/分鐘 （每分鐘執行次數）。
尋找執行次數異常高的查詢。
右鍵單擊可疑查詢並選擇 編輯查詢文本 檢查 SQL 語句。

例如，如果您看到一個簡單的 SELECT 語句每分鐘執行 37,000 次，請質疑應用程式是否真的需要如此頻繁地呼叫此查詢。ost 每分鐘執行數千次的查詢需要進行調查。

4.1.2 根本原因分析

過多的查詢執行通常源自於以下問題：

N+1 查詢問題： 應用程式程式碼首先檢索項目列表，然後對每個項目執行單獨的查詢以取得相關資料。這將建立 N 個額外的查詢，其中 N 為項目數量。
緩存缺失： 該應用程式查詢資料庫以獲取資料。 rar直接更改而不是快取到應用程式記憶體中。
輪詢循環： 程式碼反覆查詢資料庫以檢查狀態變化，而不是使用變更通知或訊息佇列。
ORM效率低： 當開發人員不了解他們的程式碼如何轉換為 SQL 時，Entity Framework 和類似工具有時會產生效率低下的查詢模式。

要確定根本原因，請將查詢追溯到應用程式程式碼。請注意… 應用類型 以及登入查詢執行時，「進程」窗格中將顯示列。您也可以右鍵單擊進程並選擇。 追蹤過程 SQL Server 輪廓 查看呼叫模式。

4.1.3 解決方案和最佳實踐

一旦發現查詢執行次數過多，請考慮以下解決方案：

批量處理： 修改應用程式程式碼，使用連接或 IN 子句在單一查詢中檢索多個項目，而不是在循環中執行單獨的查詢。
結果快取： 將應用程式記憶體中經常存取、不經常變更的資料快取起來，並設定適當的過期時間。
載入中: 設定 ORM 使用預先載入策略，以更少、更有效率的查詢取得相關資料。
查詢參數化： 確保查詢使用參數而不是連線值，這樣可以提高計劃快取的重複使用率並減少編譯開銷。

4.2 調查阻塞問題

當一個會話持有大量鎖定，導致其他會話無法繼續執行操作時，就會發生阻塞。這會導致應用程式響應速度變慢，用戶體驗不佳。

4.2.1 識別阻塞鏈

檢測和分析阻塞：

打開活動監視器並展開流程窗格。
尋找包含價值觀的會話。 被阻止 列——這些正在等待其他會話持有的鎖定。
尋找包含“1”的會話 頭部阻擋器 列——這些是造成鏈條阻塞的根本原因。
注意 會話ID 頭部阻擋器。
右鍵單擊頭部阻擋器會話並選擇信息查看它正在執行什麼命令。

理解阻塞鏈至關重要。你需要調查的是阻塞鏈的來源會話，而不是下游被阻塞的會話。

4.2.2 了解鎖的類型

这 等待類型 「進程」窗格中的欄位指示被阻塞的會話正在等待哪種類型的鎖定：

LCK_M_X： 獨佔鎖等待，通常由 UPDATE、DELETE 或 INSERT 操作引起。
LCK_M_S： 共享鎖定等待，通常是 SELECT 語句等待獨佔鎖定釋放。
LCK_M_U： 更新鎖等待，一種在更新過程中使用的中間鎖定類型。
LCK_M_IX： 意圖獨佔鎖等待，表示頁級或行級鎖爭用。

这 等待資源 該列顯示哪個資料庫物件被鎖定，幫助您了解哪個表或索引捲入了爭用。

4.2.3 解決阻塞問題

一旦你確定了阻塞會話及其正在執行的操作，你就有以下幾個選項：

等待完成： 如果頭部阻塞程序正在執行一個即將完成的合法查詢，最好讓它自然完成。
終止會話： 如果頭部阻塞程式卡住或正在執行應該取消的查詢：
- 在「進程」窗格中以滑鼠右鍵按一下會話。
- 選擇 終止進程.
- 在對話框中確認操作。
最佳化查詢： 如果阻塞重複出現於相同的查詢中，則最佳化這些查詢以減少其鎖定持續時間。
調整隔離等級： 考慮使用 READ COMMITTED SNAPSHOT ISOLATION 來減少讀取密集型工作負載中的阻斷。
指數調整： 新增索引可以加快查詢速度，減少查詢持有鎖定的時間。

4.3 分析高 CPU 使用率

當「概覽」窗格顯示處理器時間持續達到或接近 100% 時，您需要確定哪些查詢導致了這種情況，並確定是否可以對它們進行最佳化。

4.3.1 辨識 CPU 密集型查詢

尋找佔用過多 CPU 資源的查詢：

打開 近期昂貴的查詢 窗格。
排序 CPU（毫秒/秒） 以顯示使用 m 的查詢ost CPU 時間。
查看清單中的熱門搜尋字詞。
右鍵單擊高 CPU 查詢並選擇 編輯查詢文本 檢視 SQL 語句。
選擇 展示執行計劃 了解查詢是如何執行的。

不僅要注意單一查詢的 CPU 使用率，還要注意… 執行次數/分鐘 列。一個每次執行僅消耗少量 CPU 資源，但每分鐘執行數千次的查詢，可能會成為 CPU 消耗大戶。

4.3.2 查詢最佳化技術

降低CPU佔用率的常用方法包括：

新增缺少的索引： 索引尋找比表格掃描佔用更少的 CPU 資源。請檢查執行計劃中是否有缺失的索引建議。
重寫低效率查詢： 以基於集合的操作取代遊標，消除 WHERE 子句中不必要的函數，並刪除冗餘的連接。
更新統計數據： 過時的統計數據會導致 SQL Server 選擇效率低下的執行計劃。對受影響的表執行 UPDATE STATISTICS 語句。
減少數據量： 更早加入 WHERE 子句來篩選數據，使用 TOP 或 OFFSET/FETCH 進行分頁，避免使用 SELECT *。
修復參數嗅探問題： 當參數嗅探導致問題時，請使用 OPTION (RECOMPILE)、查詢提示或計畫指南。

4.4 內存問題調查

記憶體壓力會導致查詢溢出到磁碟，從而顯著降低效能。活動監視器可協助您識別記憶體密集型操作。

4.4.1 理解記憶體指標

这 記憶體使用 「進程」窗格中的欄位顯示分配給每個會話的記憶體（以千位元組為單位）。單一會話記憶體使用量過高通常表示：

大型排序或哈希操作無法放入初始分配的記憶體中
查詢檢索到大量結果集
過度並行化會導致執行計劃操作符出現大量副本。
CLR 預存程序或函數中的記憶體洩漏

「資源等待」窗格可能會顯示記憶體等待，因為查詢無法獲得足夠的記憶體授權，必須等待記憶體可用。

4.4.2 識別記憶體密集型查詢

尋找導致記憶體壓力的查詢：

在流程窗格，按以下方式排序 記憶體使用 查看消耗 m 的會話ost 記憶。
右鍵單擊記憶體使用率高的會話並選擇信息查看他們的查詢。
在 近期昂貴的查詢 在窗格中尋找查詢，尋找高 邏輯讀取 or 邏輯寫作因為這通常與記憶體使用情況相關。
檢查使用記憶體授權的排序和哈希匹配運算子的執行計劃。

執行計劃中出現「記憶體授權」警告或溢出警告的查詢表示存在記憶體壓力問題。

4.5 檢測應用程式效能問題

當使用者報告應用程式回應時間緩慢時，活動監視器可協助您確定資料庫是否為瓶頸。

4.5.1 將活動監視器與應用程式問題關聯起來

為了調查應用程式運行緩慢的原因：

記錄使用者報告問題的確切時間和受影響的應用程式。
開啟活動監視器並檢查 Overview 當時資源峰值情況的面板。
在流程窗格，以下列方式篩選 應用類型 僅顯示來自受影響應用程式的連線。
尋找高 等待時間 這些值表示資料庫延遲。
Check the 近期昂貴的查詢 用於顯示來自消耗大量資源的應用程式的查詢的窗格。

如果資料庫沒有顯示任何異常活動，而使用者卻遇到速度緩慢的問題，那麼問題很可能出在應用程式程式碼、網路延遲或用戶端效能上。

4.5.2 辨識低效率的應用模式

活動監視器揭示了應用程式設計中的幾種反模式：

聊天類別應用程式： 大量小型查詢而非更少但更有效率的查詢。在最近的高成本查詢中，連線數高且包含大量簡單查詢，以此來識別此類問題。
N+1 查詢： 一個查詢之後，緊接著又有 N 個查詢用於取得相關資料。表面上看，這是一個簡單的查詢，但每分鐘的執行次數卻極高。
大型結果集： 應用程式檢索的資料量遠遠超過所需。請找高 邏輯讀取 結合簡單的 SELECT * 查詢。
超時次數不足： 未設定命令逾時的應用程式可能會無限期地保持連線開啟狀態，在「進程」窗格中顯示為長時間運行的會話。

5. 其他方法：透過 T-SQL 取得活動監視器數據

雖然活動監視器提供了方便的圖形介面，但有時您需要以程式方式檢索等效資訊或建立自訂監視解決方案。

5.1 使用動態管理視圖 (DMV)

SQL Server 透過動態管理視圖公開活動訊息，活動監視器在後台查詢這些視圖。

5.1.1 活動監控的關鍵驅動因素

併購ost 用於複製活動監視器功能的重要動態管理視圖 (DMV) 包括：

sys.dm_exec_requests： 顯示目前正在執行的請求的 CPU、I/O 和等待資訊。
sys.dm_exec_sessions： 包含會話級訊息，例如登入名稱、host 姓名和程序名稱。
sys.dm_os_wait_stats： 提供整個實例的累計等待統計資料。
sys.dm_exec_query_stats： 包含快取查詢的總計效能統計資訊。
sys.dm_io_virtual_file_stats： 傳回資料檔案和日誌檔案的 I/O 統計資料。
sys.dm_exec_sql_text: 檢索給定 sql_handle 或 plan_handle 的 SQL 文字。
sys.dm_exec_query_plan： 傳回快取查詢的執行計劃。

5.1.2 流程資訊查詢範例

若要重複「流程」窗格的功能，您可以查詢：

SELECT 
    s.session_id AS [Session ID],
    CASE WHEN s.is_user_process = 1 THEN 'Yes' ELSE 'No' END AS [User Process],
    s.login_name AS [Login],
    ISNULL(CAST(r.blocking_session_id AS VARCHAR), '') AS [Blocked By],
    CASE 
        WHEN r2.session_id IS NOT NULL 
        AND (r.blocking_session_id = 0 OR r.session_id IS NULL) 
        THEN '1' 
        ELSE '' 
    END AS [Head Blocker],
    ISNULL(DB_NAME(r.database_id), '') AS [Database],
    ISNULL(t.task_state, '') AS [Task State],
    ISNULL(r.command, '') AS [Command],
    r.cpu_time AS [CPU Time],
    r.total_elapsed_time AS [Elapsed Time],
    r.wait_time AS [Wait Time],
    r.wait_type AS [Wait Type],
    s.memory_usage * 8 AS [Memory Use (KB)],
    s.host_name AS [Host Name],
    s.program_name AS [Application]
FROM sys.dm_exec_sessions s
LEFT JOIN sys.dm_exec_requests r ON s.session_id = r.session_id
LEFT JOIN sys.dm_exec_requests r2 ON r.session_id = r2.blocking_session_id
LEFT JOIN sys.dm_os_tasks t ON r.session_id = t.session_id
WHERE s.session_id != @@SPID
ORDER BY s.session_id;

5.1.3 等待統計資料的範例查詢

若要查看類似「資源等待」窗格的等待統計資料：

SELECT TOP 10
    wait_type AS [Wait Type],
    wait_time_ms / 1000.0 AS [Wait Time (sec)],
    waiting_tasks_count AS [Waiting Tasks],
    wait_time_ms / NULLIF(waiting_tasks_count, 0) AS [Avg Wait Time (ms)]
FROM sys.dm_os_wait_stats
WHERE wait_type NOT LIKE '%SLEEP%'
    AND wait_type NOT LIKE '%IDLE%'
    AND wait_type NOT LIKE '%QUEUE%'
ORDER BY wait_time_ms DESC;

5.2 使用 sp_WhoIsActive

sp_WhoIsActive 是一個強大的社群創建的儲存過程，它在單一結果集中提供比活動監視器更詳細的資訊。

5.2.1 安裝 sp_WhoIsActive

安裝 sp_WhoIsActive：

從下載最新版本 http://whoisactive.com.
下載的檔案是一個包含過程定義的 SQL 腳本。
開啟腳本 SQL Server 管理工作室。
連接到您的 SQL Server 實例。
執行腳本以在主資料庫中建立該過程。
授予相應使用者執行權限。

因為 sp_WhoIsActive 安裝在 master 分支上，所以可以從任何資料庫上下文中存取它。

5.2.2 基本用法範例

使用 sp_WhoIsActive 最簡單的方法是：

EXEC sp_WhoIsActive;

這將傳回一個結果集，顯示所有活動會話及其查詢、等待類型、阻塞資訊和資源使用情況。

取 10 秒鐘的樣本，顯示該時段的活動情況：

EXEC sp_WhoIsActive @delta_interval = 10;

這會計算 CPU 和讀取次數等指標的變化量，顯示這 10 秒內發生了什麼事。

5.2.3 高階參數

sp_WhoIsActive 支援眾多可自訂參數：

@篩選： 將結果篩選到特定會話、資料庫或登入名稱。
@filter_type: 指定篩選器適用的物件（會話、資料庫、登入等）。
@get_plans： 將執行計劃包含在結果中（設定為 1）。
@get_locks： 顯示詳細的鎖定資訊（設定為 1）。
@get_transaction_info: 顯示交易詳情（設定為 1）。
@sort_order: 依不同指標（CPU、讀取次數、持續時間等）對結果進行排序。
@destination_table： 將結果插入表格以進行歷史記錄追蹤。

範例顯示按 CPU 排序的計劃：

EXEC sp_WhoIsActive 
    @get_plans = 1,
    @sort_order = '[CPU] DESC';

5.3 使用系統預存程序

SQL Server 包括用於監控活動的傳統儲存過程，儘管它們提供的資訊比 DMV 或活動監視器少。

5.3.1 sp_who 和 sp_who2

sp_who 過程顯示基本會話資訊：

EXEC sp_who;

sp_who2 程式提供了更詳細的資訊：

EXEC sp_who2;

兩種方法都會顯示會話 ID、登入名稱、CPU 時間和阻塞資訊。但是，它們缺乏透過動態管理視圖 (DMV) 或活動監視器獲得的豐富詳細資訊。ost 當您需要快速獲取最少資訊時，此方法非常實用。

5.3.2 其他有用的系統程序

其他系統監控程序包括：

sp_lock： 顯示鎖定訊息（已棄用；請改用 sys.dm_tran_locks）。
sp_monitor： 顯示有關統計數據 SQL Server 活動。
sp_help： 顯示物件定義和元資料。
DBCC SQLPERF： 顯示交易日誌空間使用情況和等待統計資料。

5.4 建立自訂監控腳本

對於需要超出活動監視器提供的功能的特定監視的環境，您可以使用 DMV 建立自訂解決方案。

5.4.1 完整的活動監視器等效腳本

這裡有一個完整的腳本，可以重現 most 活動監視器功能：

-- Processes Information
SELECT 
    s.session_id AS [Session ID],
    CONVERT(CHAR(1), s.is_user_process) AS [User Process],
    s.login_name AS [Login],
    ISNULL(CONVERT(VARCHAR, w.blocking_session_id), '') AS [Blocked By],
    CASE 
        WHEN r2.session_id IS NOT NULL 
        AND (r.blocking_session_id = 0 OR r.session_id IS NULL) 
        THEN '1' 
        ELSE '' 
    END AS [Head Blocker],
    ISNULL(DB_NAME(r.database_id), N'') AS [Database],
    ISNULL(t.task_state, N'') AS [Task State],
    ISNULL(r.command, N'') AS [Command],
    SUBSTRING(st.text, (r.statement_start_offset/2) + 1,
        ((CASE r.statement_end_offset 
            WHEN -1 THEN DATALENGTH(st.text)
            ELSE r.statement_end_offset 
        END - r.statement_start_offset) / 2) + 1) AS [Statement],
    st.text AS [Command Text],
    r.cpu_time AS [CPU Time (ms)],
    r.total_elapsed_time / 1000 AS [Elapsed Time (sec)],
    r.wait_time AS [Wait Time (ms)],
    r.wait_type AS [Wait Type],
    r.wait_resource AS [Wait Resource],
    s.memory_usage * 8 AS [Memory Use (KB)],
    s.host_name AS [Host Name],
    c.client_net_address AS [Net Address],
    s.program_name AS [Application]
FROM sys.dm_exec_sessions s
LEFT JOIN sys.dm_exec_requests r ON s.session_id = r.session_id
LEFT JOIN sys.dm_exec_requests w ON r.session_id = w.blocking_session_id
LEFT JOIN sys.dm_exec_requests r2 ON r.session_id = r2.blocking_session_id
LEFT JOIN sys.dm_os_tasks t ON r.session_id = t.session_id 
    AND r.request_id = t.request_id
LEFT JOIN sys.dm_exec_connections c ON s.session_id = c.session_id
OUTER APPLY sys.dm_exec_sql_text(r.sql_handle) st
WHERE s.session_id != @@SPID
ORDER BY s.session_id;

-- Recent Expensive Queries
SELECT TOP 20
    qs.execution_count / 
        DATEDIFF(MINUTE, qs.creation_time, GETDATE()) AS [Executions/min],
    qs.total_worker_time / 1000 AS [CPU Time (ms)],
    qs.total_physical_reads AS [Physical Reads],
    qs.total_logical_writes AS [Logical Writes],
    qs.total_logical_reads AS [Logical Reads],
    qs.total_elapsed_time / qs.execution_count / 1000 AS [Avg Duration (ms)],
    SUBSTRING(st.text, (qs.statement_start_offset/2) + 1,
        ((CASE qs.statement_end_offset 
            WHEN -1 THEN DATALENGTH(st.text)
            ELSE qs.statement_end_offset 
        END - qs.statement_start_offset) / 2) + 1) AS [Query Text]
FROM sys.dm_exec_query_stats qs
CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) st
WHERE qs.execution_count > 0
ORDER BY qs.total_worker_time DESC;

5.4.2 使用 SQL Agent 作業實現自動化監控

您可以使用以下方式安排自訂監控腳本 SQL Server 代理人：

建立表格以儲存監控結果。
修改監控腳本，將結果插入此表。
In SQL Server 管理工作室，擴展 SQL Server 經紀人 在物件資源管理器中。
右鍵單擊工作並選擇 新工作.
配置作業以定期執行監控腳本。
根據收集的數據設定警報或報告。

這種方法能夠進行歷史追蹤和趨勢分析，而活動監視器則無法提供這些功能。

6. 活動監測器的限制和注意事項

雖然活動監視器很有價值，但了解其限制有助於您正確使用它，並在必要時使用其他工具進行補充。

6.1 了解活動監視器的開銷

活動監視器並非免費——它會消耗伺服器資源來收集和顯示資訊。了解這種開銷有助於您合理使用它。

6.1.1 對伺服器資源的影響

活動監視器每次刷新時都會對系統動態管理視圖 (DMV) 執行查詢。這些查詢會消耗 CPU 資源、產生邏輯讀取操作，並且可能會短暫持有系統表的鎖。在繁忙的伺服器上，這種開銷會影響效能。

「進程」和「最近耗時查詢」窗格的開銷尤其大，因為它們必須掃描可能非常大的動態管理視圖 (DMV) 和快取表。在快取了數千個查詢計畫的伺服器上，刷新「最近耗時查詢」可能需要幾秒鐘的時間。

微軟的文檔警告說，低於 10 秒的刷新間隔會明顯影響伺服器效能，尤其是在負載已經很高的系統上。

6.1.2 刷新間隔最佳實踐

選擇適合你實際狀況的刷新間隔：

1-5秒： 僅用於在負載較低的伺服器上立即排查關鍵問題。請勿按此時間間隔運行活動監視器。
10 秒（預設值）： 對 m 來說合理ost 故障排除場景和一般監控。
30-60秒： 對於高負載生產伺服器或需要長時間監控的情況，這是更好的選擇。
僅可手動刷新： 適用於需要偶爾檢查當前狀態而無需持續輪詢的情況。

調查結束後務必關閉活動監視器。不要讓它持續運行，尤其是不要讓不同使用者的多個實例同時運行。

6.2 等待類型分組問題

活動監視器對等待進行分類的方法雖然簡化了視圖，但可能會掩蓋重要的診斷資訊。ostic 資訊。

6.2.1 活動監視器群組等待方式

SQL Server 活動監視器追蹤數百種不同的等待類型，每一種都指示特定的資源或條件。活動監視器將這些等待類型歸類為「緩衝區閂鎖」、「鎖定」和「記憶體」等大類。

例如，「緩衝區閂鎖」類別包括 PAGELATCH_SH、PAGELATCH_UP、PAGELATCH_EX 以及其他幾種特定的等待類型。雖然它們都與頁面訪問相關，但其原因和解決方法各不相同。

微軟沒有明確說明哪些等待類型對應哪些類別，因此很難理解你實際看到的內容。

6.2.2 缺失的等待類型

活動監視器不會顯示所有等待類型。ost 值得注意的是，它通常會忽略 CXPACKET 等待，而 CXPACKET 等待表示並行查詢正在執行。 CXPACKET 等待很常見，通常不會造成問題，但了解它們的存在有助於您理解工作負載的特徵。

當活動監視器顯示「緩衝區閂鎖」是您的首要等待進程，但其他工具顯示 CXPACKET 占主導地位時，這種差異源自於活動監視器的過濾和分組邏輯。

6.2.3 為什麼特定的等待類型很重要

了解具體的等待類型對於故障排除至關重要：

頁面鎖定_EX： 這通常表示 tempdb 分配頁存在爭用。解決方法是新增更多 tempdb 資料檔。
頁面鎖定_SH： 這可能表示使用者表中存在熱點頁面。解決方案涉及分區或索引重組。
頁面鎖定向上： 更新過程中常見現象。可能表示運作正常，而非出現問題。

活動監視器將所有這些問題歸類到「緩衝區閂鎖」下，這使得診斷更加困難。而 sp_WhoIsActive 和 DMV 查詢等工具則會顯示特定的等待類型。

6.3 數據準確性和及時性

活動監視器提供近乎即時的視圖，但「近乎」是關鍵所在。了解其資料收集方法有助於您正確解讀結果。

6.3.1 快照監控與連續監控

活動監視器會顯示每次刷新間隔時拍攝的快照。快照之間發生的事件不會被捕獲。例如，如果一個查詢運行了 2 秒，而您每 10 秒刷新一次，那麼您可能只會看到一次，也可能一次也看不到，具體取決於時間。

這意味著活動監視器擅長發現持續性問題（阻塞持續數分鐘、CPU 使用率持續偏高），但可能會錯過瞬態問題（短暫的死鎖、偶爾的查詢峰值）。

6.3.2 匯總和抽樣

「最近高成本查詢」窗格顯示自查詢計劃進入快取以來匯總的資料。如果兩個參數值不同的相同查詢共用同一個計劃，則會顯示為一行。這種匯總方式可能會掩蓋特定參數組合的問題（參數嗅探問題）。

「資源等待」窗格透過比較快照來計算速率。如果快照之間等待統計資訊重置（rare 但有可能），計算出的比率可能不正確。

6.4 何時不應使用活動監視器

活動監視器並非適用於所有監視場景。請了解何時應選擇其他更合適的工具。

6.4.1 歷史分析要求

活動監視器僅顯示目前或最近的活動，不儲存歷史資料。如果您需要分析數天或數週的趨勢、將目前效能與基準進行比較，或產生效能模式報告，則活動監視器無法滿足您的需求。

對於歷史分析，請使用 SQL Server內建效能儀表板，擴充事件（附檔案） tar取得或第三方監控解決方案。

6.4.2 詳細等待統計需求

當您需要精確的等待類型資訊以進行進階調優時，活動監視器的分組和篩選功能不足以滿足需求。請直接使用 DMV 查詢或 sp_WhoIsActive 函數。

若要進行全面的等待統計分析，請直接查詢 sys.dm_os_wait_stats 並手動篩選掉良性等待。

6.4.3 生產伺服器注意事項

在高負載的生產伺服器上，活動監視器的開銷可能會造成問題。多個資料庫管理員不應該在同一台伺服器上同時執行活動監視器。

對於生產監控，可以考慮使用輕量級替代方案，例如將計劃的 DMV 快照儲存在監控資料庫中，或使用唯讀路由來監控 Always On 配置中的輔助副本。

7. 使用活動監視器的最佳實踐

遵循最佳實務可確保您從活動監視器中獲得最大價值，同時最大限度地減少對伺服器的負面影響。

7.1 何時使用活動監視器

活動監視器在特定場景下表現出色。當它的優勢符合您的需求時，請使用它。

7.1.1 即時效能問題

當使用者遇到問題且您需要立即診斷問題時，「活動監視器」是理想之選。即時視圖可協助您了解目前發生的情況。

當您接到「應用程式運行緩慢」的提示時，首先應該做的就是打開「活動監視器」。您可以快速確定資料庫是繁忙、阻塞還是處於空閒狀態。

7.1.2 應用程式運行緩慢調查

當某個應用程式無回應時，「活動監視器」可協助您確定是否是資料庫問題導致的。按應用程式名稱篩選「進程」窗格，即可僅查看該應用程式的資料庫活動。

如果使用者回報問題時應用程式沒有顯示任何資料庫活動，則問題出在堆疊的其他位置。如果您發現大量阻塞或開銷較大的查詢，那麼您就找到了問題所在。

7.1.3 快速健康檢查

活動監視器提供了一個出色的儀錶板，方便在日常管理期間快速進行健康檢查。打開它，瀏覽概覽圖表，確認一切正常。

這種簡單的檢查只需幾秒鐘，就能在問題變得嚴重之前發現它們。把它納入你的日常習慣吧。

7.2 最佳配置設定

正確配置活動監視器可以提高其可用性並降低資源佔用。

7.2.1 建議刷新間隔

根據您的需求選擇合適的刷新間隔：

主動故障排除： 10 秒的反應時間既能保證良好的反應速度，又能提供合理的開銷。
擴展監測： 30-60 秒可減少較長觀察期內對伺服器的影響。
關鍵問題診斷： 5 秒可以提供很高的精確度，尤其是在每一秒都至關重要的時候，但盡量縮短使用時間。
定期健康檢查： 當您不觀看影片時，請手動刷新（每隔 1 小時刷新一次）。

使用完畢後，請務必關閉活動監視器。如果設定過長的運作間隔後忘記關閉，會浪費伺服器資源。

7.2.2 過濾策略

使用篩選器來專注於相關資訊並降低認知負荷：

以以下方式篩選流程 數據庫 僅查看針對特定資料庫的活動。
搜尋範圍登入追蹤特定用戶的活動。
搜尋範圍 任務狀態 = 正在執行以隱藏空閒會話。
搜尋範圍 應用類型 將流量與特定程式隔離。
僅顯示非空白項 被阻止 僅顯示阻塞情況。

7.2.3 列選擇與排序

制定一套系統化的方法來審查活動監測數據：

Star概述： 檢查圖表是否有明顯的尖峰或異常。
檢查進程是否有阻塞： 按會話 ID 排序，然後尋找「被阻止者」值。
審查資源等待狀況： 依累計等待時間排序，找出資源瓶頸。
分析高成本查詢： 依不同指標（CPU、執行次數、讀取次數）排序，以找出不同類型的問題。
使用 I/O 面板進行驗證： 確認 I/O 密集型查詢是否與高磁碟活動相關。

7.3 與其他工具的集成

活動監視器最好作為更廣泛的工具包的一部分使用，而不是作為獨立解決方案。

7.3.1 與…一起使用 SQL Server 輪廓

活動監測器和 SQL Server 分析器可以很好地互補。當您在活動監視器中發現問題會話時，請右鍵單擊它並選擇 追蹤過程 SQL Server 輪廓.

這將啟動效能分析器，並預先配置篩選器，僅捕獲該會話的活動。您可以看到執行語句的完整序列、計時資訊和錯誤訊息—這些詳細資訊是活動監視器所不提供的。

要了解更多有關 SQL Server 分析器功能和進階追蹤技術，請參閱我們的全面 SQL Server Profiler 指南.

7.3.2 補充擴展事件

擴展事件提供低開銷、詳細的監控，可以捕捉活動監視器遺漏的資訊。建立擴展事件會話可以追蹤特定事件，例如死鎖、長時間運行的查詢或過多的重新編譯。

使用「活動監視器」進行即時調查，「擴展事件」進行持續監視和歷史分析。這兩個工具滿足不同的需求。

要了解更多有關 SQL Server 擴展事件功能和進階監控技術，請參閱我們的全面 SQL Server 擴充活動指南.

7.3.3 第三方監控解決方案

SolarWinds Database Performance Analyzer、Redgate SQL Monitor 和 Quest Spotlight 等商業工具提供了 Activity Monitor 所缺乏的功能：警報、歷史趨勢分析、容量規劃和自動診斷。ostICS。

這些工具是對活動監視器的有益補充，而非替代。即使有了更進階的監控工具，活動監視器仍然可用於快速檢查和調查。

7.4 要避免的常見錯誤

了解活動監視器常見的錯誤用法有助於您更有效地使用它。

7.4.1 保持活動監視器持續運作

併購ost 常見的錯誤是打開活動監視器並讓它無限期地運行。這會浪費伺服器資源，而且由於您沒有主動監控，因此幾乎沒有任何價值。

不使用活動監視器時，請將其關閉。如果需要持續監控，請實施具有定時資料收集功能的正規監控方案。

7.4.2 過度依賴活動監測器

活動監視器提供了一種伺服器健康狀況的視角，但不要完全依賴它。應結合使用 Windows 效能監視器來獲取作業系統層級的指標，使用擴展事件監視器來獲取詳細的追蹤信息，並使用執行計劃分析來進行查詢最佳化。

活動監視器可以幫助您發現問題，但解決這些問題通常需要其他工具和更深入的分析。

進一步了解 SQL Server 我們效能監控器中的完整指南.

7.4.3 忽略歷史趨勢

活動監視器顯示目前狀態，但效能問題通常只有隨著時間的推移才能顯現出規律。實施歷史資料收集，以便將當前指標與基準進行比較，從而識別趨勢。

如果沒有歷史背景，你可能不會意識到，如今「正常」的 CPU 使用率比上個月的基準值高出 30%，這表明 CPU 使用率正在逐漸下降。

8. 活動監視器問題排查

活動監視器本身有時也會出現問題。了解如何排查這些問題可以避免不必要的麻煩。

8.1 活動監視器無法開啟或不顯示任何數據

當「活動監視器」開啟但顯示空白窗格或根本無法開啟時，可能有多種因素導致此問題。

8.1.1 權限問題

併購ost 活動監視器問題的常見原因是權限不足。要驗證並解決此問題：

檢查您的伺服器級權限：

SELECT * FROM fn_my_permissions(NULL, 'SERVER')
WHERE permission_name = 'VIEW SERVER STATE';

如果沒有傳回任何行，則表示您沒有查看伺服器狀態的權限。

請伺服器管理員授予此權限：

USE master;
GRANT VIEW SERVER STATE TO [YourLogin];

授予權限後，關閉並重新開啟活動監視器。

8.1.2 版本相容性問題

使用舊版本 SQL Server 管理工作室連接到較新的 SQL Server 版本問題可能會導致活動監視器故障。該工具可能無法識別新的等待類型或系統視圖列。

請務必使用與您的系統版本相同或更新的 SSMS 版本。 SQL Server 版本。微軟提供最新版本的 SSMS，可從單獨的免費下載清單中取得。 SQL Server 本身。

8.1.3 防火牆和網路問題

活動監視器需要連接到… SQL Server 實例運行在標準連接埠（預設為 1433）上。如果可以透過物件資源管理器連接，但活動監視器連線失敗，則可能是防火牆規則阻止了特定連接。

確認您的客戶可以聯絡到 SQL Server 請確保機器已連接到所有必要的連接埠。請檢查 Windows 防火牆以及用戶端和伺服器之間的任何網路防火牆。

8.2 活動監視器永久暫停

這是一個常見問題，尤其是在 SQL Server 2019 年，活動監視器開啟時處於暫停狀態，拒絕恢復。

8.2.1 理解暫停狀態

當活動監視器暫停時，所有窗格都會顯示「已暫停」狀態，且復原按鈕可能無法使用。這會導致您無法查看任何伺服器活動。

暫停狀態通常是由於權限問題、遠端連線限製或 SSMS 版本錯誤造成的，而不是有意暫停操作。

8.2.2 常見原因

活動監視器可能會因以下原因進入永久暫停狀態：

最近新增的新窗格缺少「檢視伺服器狀態」權限 SQL Server 版本
遠端連線已停用 SQL Server 例
特定係統查詢的身份驗證失敗
特定 SSMS 版本（特別是 18.0 至 18.3 版本）中存在錯誤。
客戶端和伺服器之間的連線問題

8.2.3 解決步驟

要解決活動監視器暫停狀態問題：

更新 SSMS： 下載並安裝最新版本 SQL Server 從微軟官網下載的 Management Studio 版本。後續版本修復了許多暫停狀態的錯誤。
驗證權限： 請確保您擁有查看伺服器狀態和查看任何定義的權限。
檢查遠端連線： 驗證 SQL Server 實例允許遠端連線：
```
EXEC sp_configure 'remote access';
```
如果該值為 0，請管理員啟用它。
住宅tart SSMS： 有時只需關閉所有視窗和資源即可。tar婷 SQL Server Management Studio 解決了這個問題。
使用 Windows 驗證連線： 如果使用 SQL 驗證，請嘗試改用 Windows 驗證，因為它有時可以繞過與驗證相關的暫停問題。

8.3 使用活動監視器時的效能問題

如果活動監視器本身運作緩慢或導致伺服器效能下降，則需要進行調整。

8.3.1 降低監控開銷

為了最大限度地減少活動監視器的影響：

將刷新間隔增加到 30 秒或 1 分鐘。
按一下折疊按鈕，關閉目前不使用的窗格。
當窗格折疊時，活動監視器不會查詢其中的資料。
避免同時執行多個活動監視器執行個體。
在不主動調查問題時，請完全關閉活動監視器。

8.3.2 其他輕量級監測方法

如果活動監視器對您的環境來說資源消耗過大，請考慮其他替代方案：

直接查詢車輛管理部門： 編寫特定的 T-SQL 查詢，僅檢索所需資訊。
使用 sp_WhoIsActive： 此預存程序經過高度最佳化，通常比活動監視器開銷更低。
實施抽樣： 定期安排 SQL Agent 作業，以擷取 DMV 資料的快照，並將結果儲存在表格中以供後續分析。
監控輔助副本： In 始終在線可用性組對可讀的輔助磁碟而不是主磁碟運行活動監視器。

8.4 資訊不準確或缺失

有時活動監視器顯示的資訊似乎不正確或不完整。

8.4.1 與車管所核實數據

當活動監視器結果可疑時，請直接查詢底層動態管理檢視 (DMV) 進行驗證。例如，如果「進程」窗格顯示沒有阻塞，但使用者報告有阻塞，請查詢：

SELECT 
    blocking_session_id,
    session_id,
    wait_type,
    wait_time,
    wait_resource
FROM sys.dm_exec_requests
WHERE blocking_session_id != 0;

如果此查詢顯示活動監視器遺漏的阻斷，則表示有顯示問題。

8.4.2 瞭解資料刷新時序

請記住，「活動監視器」顯示的是快照。如果查詢的執行計劃未從快取中移除，則在兩次刷新間隔之間執行的查詢不會出現在「最近的高成本查詢」清單中。

同樣，「資源等待」窗格中的等待統計資料反映了自上次快照以來的累積情況。快速變化的工作負載每次刷新都可能顯示不同的模式。

9. 高階活動監測技術

經驗豐富的資料庫管理員會以複雜的方式使用活動監視器來提取最大的診斷資訊。ostic 值。

9.1 結合多個面板進行根本原因分析

當您將多個窗格中的資訊關聯起來，以了解複雜的效能問題時，活動監視器的真正威力就顯現出來了。

9.1.1 將等待與進程關聯起來

當「資源等待」窗格顯示某個類別的等待時間過長時，請使用「進程」窗格來確定哪些會話正在經歷這些等待：

請注意累計等待時間較長的等待類別（例如，「鎖定」）。
切換到「進程」窗格。
排序 等待類型 根據目前等待時間分組進行會話。
尋找顯示問題類別中等待類型的會話。
對於這些會話，請檢查 等待資源 列用於查看涉及哪些資料庫物件。
右鍵單擊並選擇信息查看查詢文字。

這種關聯性有助於你將問題從「我們有鎖等待」轉變為「這個特定的查詢正在等待此表上的鎖」。

9.1.2 將高成本查詢與 I/O 問題關聯起來

當「資料檔案 I/O」窗格顯示特定資料庫的磁碟活動較高時：

注意哪些資料庫檔案的讀取或寫入速率較高（MB/秒）。
切換到最近的高成本查詢。
排序 物理讀取/秒 識別大量從磁碟讀取資料的查詢。
篩選或直觀地識別針對資料庫執行的高 I/O 查詢。
檢查這些查詢的執行計劃，是否存在表格掃描或缺少索引導致過多的 I/O。

這種多窗格分析將症狀（磁碟 I/O 過高）與原因（特定的低效率查詢）聯繫起來。

9.2 使用活動監視器進行容量規劃

雖然活動監視器不會儲存歷史數據，但您可以策略性地利用它進行容量規劃觀察。

9.2.1 辨識高峰使用模式

在一天中的不同時間段監控伺服器活動，以識別使用模式：

在已知的業務高峰時段開啟活動監控。
請注意處理器時間百分比圖表的峰值。
記錄最大等待任務數。
觀察尖峰時段的每秒批次請求數。
在「進程」窗格中記錄最繁忙的資料庫。
為了進行比較，請在非尖峰時段重複上述步驟。

如果尖峰時段處理器使用率持續超過 80%，則表示 CPU 容量已接近極限。同樣，等待次數的增加也顯示資源爭用日益嚴重。

9.2.2 資源趨勢分析

雖然「活動監視器」顯示的是當前狀態，但您也可以透過記錄一段時間內的關鍵指標來快速查看趨勢：

每天在同一時間截取概覽窗格的螢幕截圖
記錄每個圖表中的峰值
透過每週對比來識別成長趨勢
注意觀察平均處理器時間或 I/O 速率是否逐漸增加。

此手動趨勢分析是對更複雜的監控解決方案的補充，有助於證明容量擴展的合理性。

9.3 記錄績效基準

建立基準效能指標有助於您識別效能何時下降。

9.3.1 採集基線指標

在已知表現良好的時期，記錄活動監視器指標：

在正常業務運作期間（非高峰期或非高峰期）開啟活動監視器。
記錄概覽窗格值：
- 典型處理器時間百分比範圍
- 平均等待任務數
- 正常資料庫 I/O 速率
- 典型批量請求/秒
注意「資源等待」窗格類別，其中顯示了 most 等待時間。
通常在「進程」窗格中記錄活動進程的數量。
記錄近期高成本查詢的代表性查詢執行指標。

請儲存此基線文檔，以便將來在調查效能問題時參考。

9.3.2 當前性能與基準性能比較

當出現效能問題時，請將目前活動監視器讀數與您記錄的基線進行比較：

處理器時間是否顯著高於基準值？重點關注 CPU 密集型查詢。
等待任務的數量是否達到基準水準的 2-3 倍？調查資源等待狀況。
I/O 是否顯著升高？請檢查「資料檔案 I/O」窗格以及開銷較大的查詢。
高峰時段批次請求是否低於基線水平？請檢查是否有阻塞或連線問題。

透過對比，您可以確定發生了哪些變化，並有針對性地集中精力進行故障排除。

9.4 建立自訂監控工作流程

針對常見調查場景制定係統化的工作流程，以確保進行徹底、可重複的分析。

9.4.1 逐步調查過程

當使用者報告效能問題時，請遵循一致的工作流程：

快速健康檢查： 開啟活動監視器，掃描概覽窗格圖表，尋找明顯的異常。
檢查是否有阻塞： 展開「進程」窗格，在「封鎖依據」欄位中篩選非空白項。
識別資源爭用： 查看按等待時間排序的「資源等待」窗格。
尋找高成本查詢： 檢查最近的高成本查詢，按 CPU 使用時間排序，然後按執行次數排序，最後按讀取次數排序。
關聯 I/O 模式： 將昂貴的查詢與資料檔案 I/O 窗格活動進行交叉引用。
文件調查結果： 截取螢幕截圖並記錄相關的會話 ID、等待類型和查詢詳情。
深潛： 使用 Profiler 追蹤、執行計劃分析和 DMV 查詢對已識別的問題進行詳細調查。

9.4.2 升級標準

制定判斷何時該升級問題、何時該繼續調查的標準：

立即上報： 阻塞鏈持續時間超過 5 分鐘，處理器使用率超過 2 分鐘，關鍵系統處理顯示 SUSPENDED 狀態。
透過分析升級問題： 重複出現代價高昂的查詢，佔用 CPU 超過 50%，I/O 回應時間持續過高（超過 50 毫秒），記憶體授權重複失敗。
進一步調查： 時間rary 等待在幾分鐘內解決，查詢計劃不理想但效能可接受，輕微阻塞持續時間<30 秒。

10. 不同環境下的活動監測 SQL Server 版本

活動監視器已經發展演變 SQL Server 版本不斷更新，每次發布都會帶來改進，偶爾也會出現一些新問題。

10.1 活動監視器 SQL Server 2008 及更高版本

SQL Server 2008 年推出的現代活動監測器設計至今仍基本保持不變。

10.1.1 新增功能 SQL Server 2008

这 SQL Server 2008 年活動監測器重新設計後，帶來了顯著的改善：

概覽窗格中的圖形化儀表板，包含即時圖表
可展開/折疊的窗格介面取代了舊的僅網格視圖
「最近高成本查詢」窗格顯示總計查詢效能數據
用於監控每個檔案磁碟活動的資料檔案 I/O 面板
增強型資源等待窗格，具有等待分類功能
右鍵點選上下文功能表可執行諸如終止會話和啟動分析器之類的進程操作。
可設定的刷新間隔，範圍從 1 秒到 1 小時

這些變更將活動監視器從一個簡單的進程清單轉變為全面的監控儀表板。

10.1.2 變更 SQL Server 2005

SQL Server 2005 年的活動監視器功能有限得多：

透過物件資源管理器中的「管理」資料夾訪問，而不是透過工具列存取。
單網格顯示包含基本資訊的流程列表
沒有圖形圖表或多窗格
無需昂貴的查詢或 I/O 監控
有限的等待統計信息

2008 年的重新設計是徹底的重新構想，而不是漸進式的改進。

10.2 活動監視器 SQL Server 2014/2016

SQL Server 2014 年和 2016 年對活動監視器的底層資料收集進行了逐步改進，但視覺上的變化不大。

10.2.1 改進和增強

這些版本的主要改進包括：

監控擁有數千個快取方案的伺服器時效能更佳
「進程」窗格中增強的篩選功能
提高了等待統計資訊匯總的準確性
更好地處理大型結果集的列排序和篩選
更有效率的 DMV 查詢可減少監控開銷

核心介面保持一致 SQL Server 2008 年，保持管理員的熟悉度。

10.3 活動監視器 SQL Server 2019/2022

最近 SQL Server 版本更新延續了 Activity Monitor 的發展，重點在於效能和穩定性。

10.3.1 最新特性與功能

SQL Server 2019 年和 2022 年活動監測器包括：

支援這些版本中引入的新等待類型
使用 WPF 技術提升 SSMS 的渲染效能
更好地處理大量活躍會話
增強與雲端 SQL 平台的兼容性
更準確的 CPU 和 I/O 指標

10.3.2 近期版本的已知問題

SQL Server 2019 年引入了多個活動監視器漏洞：

永久暫停狀態： 活動監視器經常進入暫停狀態且無法恢復，尤其是在 SSMS 18.0-18.3 版本中。此問題已在更高版本的 SSMS 中修復。
遠端連線失敗： 某些配置會阻止在遠端執行個體上開啟活動監視器。解決方法包括啟用特定的追蹤標誌或使用較新版本的 SSMS。
權限問題： 新的系統視圖需要額外的權限，但文件中沒有明確說明，即使使用 VIEW SERVER STATE 也會導致顯示空白。

使用 SSMS 時，請務必使用最新版本。 SQL Server 2019 年和 2022 年，以避免這些問題。

11. 實際應用案例和範例

實際案例示範如何在常見的故障排除場景中有效地應用活動監視器。

11.1 案例研究：診斷運行緩慢的 Web 應用程式

開發團隊報告稱，他們的 Web 應用程式運行速度變得非常慢，頁面載入時間從正常的 2-3 秒增加到 20-30 秒，令人無法接受。

11.1.1 初步調查概覽窗格

開啟「活動監視器」並查看「概覽」窗格：

處理器時間百分比圖表顯示 CPU 使用率為 85-95%，明顯高於正常的 30-40% 的基準。
等待任務的數量在 10-20 個任務之間波動，而正常基線為 0-3 個任務。
資料庫 I/O 活動適中，約 50 MB/s。
每秒批次請求數低於預期，為每秒 100 個，而正常情況下工作時間內每秒請求數為 300-400 個。

這種模式顯示CPU瓶頸導致資源爭用，進而造成吞吐量下降。伺服器雖然高負荷運轉，但處理的請求數量卻不多。

11.1.2 識別問題查詢

展開「最近執行次數較多的查詢」窗格，並依每分鐘執行次數排序：

排名最高的查詢每分鐘執行 15,000 次。
右鍵單擊並選擇 編輯查詢文本 檢查查詢。
此查詢是一個簡單的 SELECT 語句，用於檢索單一使用者記錄： SELECT * FROM Users WHERE UserId = @UserId.
對於正常的應用程式使用情況，此查詢不應該每分鐘執行 15,000 次。

右鍵單擊查詢並選擇 展示執行計劃此計劃顯示對 Users 表進行表掃描，並警告 UserId 列缺少索引。

在「進程」窗格中按應用程式篩選，僅顯示 Web 應用程式的連線。多個會話顯示相同的查詢重複運行。

11.1.3 解析度和驗證

問題源自於兩個面向：查詢執行次數過多和缺少索引。解決方法：

建立缺少的索引：

CREATE NONCLUSTERED INDEX IX_Users_UserId 
ON Users (UserId);

聯繫開發團隊 關於執行次數過多的問題。調查顯示應用程式程式碼中存在 N+1 查詢問題，其中循環會檢索清單中每個項目的使用者詳細資訊。
修改應用程式 使用 IN 子句或表值參數將使用者查找批次合併到單一查詢。
驗證修復是否成功 部署後透過監控活動監視器發現，CPU 使用率降至 35-40%，每分鐘執行次數降至 200-300 次，應用程式回應時間恢復正常。

11.2 案例研究：解決阻塞問題

使用者反映訂單錄入系統會週期性地卡頓 30-60 秒，然後恢復正常運作。

11.2.1 檢測阻塞鏈

在這些凍結事件發生期間開啟活動監視器，並展開「進程」窗格：

排序 會話ID 查看所有已安排的會議。
多個會話顯示數值。 被阻止 列，全部指向會話 ID 73。
第 73 場顯示“1” 頭部阻擋器 專欄證實這是根本原因。
这 等待類型 對於阻塞的會話，顯示 LCK_M_X，表示它們正在等待獨佔鎖。
这 等待資源 此列顯示阻塞發生在訂單表中。

11.2.2 分析原因

右鍵單擊會話 73 並選擇信息查看命令：

UPDATE Orders 
SET Status = 'Processing', 
    LastModified = GETDATE()
WHERE OrderId IN (SELECT OrderId FROM #TempOrders);

此更新是每小時執行一次的批次作業的一部分。正在檢查登入此列確認會話屬於批次服務帳戶。

該查詢在處理數千個訂單時，會佔用 Orders 表的鎖。 等待時間 阻塞會話數穩定增加，證實了長時間運行的操作是問題所在。

11.2.3 實施修復

短期解決方案：

文件會話 73 的詳細信息，包括查詢文字和持續時間。
由於這是合法的批量處理，請允許更新自然完成。
完成後，確認阻塞的會話已清除，操作恢復正常。

已實施的長期解決方案：

重新排程批次作業 在非尖峰時段（凌晨 2 點至 4 點，而不是在營業時間內）運行。
修改批次 以每次 100 筆記錄的小批量方式更新訂單，並在批次之間釋放鎖定。
新增索引 在 OrderId 欄位上進行更新，以加快更新操作。
考慮快照隔離 減少讀取操作的阻塞影響。

11.3 案例研究：識別過多的查詢執行

資料庫監控顯示，過去一個月 CPU 使用率逐漸增加，但應用程式程式碼沒有明顯變化。

11.3.1 發現異常執行計數

開啟「活動監視器」並查看「最近的高成本查詢」窗格：

排序 執行次數/分鐘 去看most 經常執行的查詢。
排名最高的查詢每分鐘執行 37,000 次——遠高於其他任何查詢。
右鍵單擊並選擇 編輯查詢文本.

此查詢檢索產品類別資訊：

SELECT CategoryId, CategoryName 
FROM ProductCategories 
WHERE CategoryId = @CategoryId;

這個簡單的查詢應該速度很快且可以緩存，但它每分鐘卻執行數萬次。

11.3.2 追溯到應用程式程式碼

在「進程」窗格中，找到執行此查詢的會話：

注意 應用類型 此欄位顯示「產品目錄服務」。
右鍵單擊其中一個會話並選擇 追蹤過程 SQL Server 輪廓.
SQL Profiler 顯示該查詢會以不同的 CategoryId 值快速連續地重複執行。
請聯絡負責 ProductCatalogService 的開發團隊進行程式碼審查。

程式碼審查揭示了問題所在：最近的一次更改會檢索帶有類別的產品清單。對於結果集中的每個產品（通常超過 1,000 個），程式碼都會單獨呼叫資料庫來取得類別資訊——這是一個典型的 N+1 查詢問題。

11.3.3 優化應用程式

實施適當的修復措施：

修改應用程式查詢 使用 JOIN 語句，在一次資料庫呼叫中檢索產品及其類別：

SELECT p.ProductId, p.ProductName, c.CategoryId, c.CategoryName
FROM Products p
INNER JOIN ProductCategories c ON p.CategoryId = c.CategoryId
WHERE p.Active = 1;

部署更新後的程式碼 並監控活動監視器。
驗證修復是否成功： 類別查詢的每分鐘執行次數從 37,000 次下降到 100 次以下，整體 CPU 使用率下降了 40%。
記錄吸取的教訓 並與開發團隊分享，以防止將來程式碼變更中出現類似問題。

12. 檢測潛在的資料庫損壞

雖然活動監視器並非專門設計用於檢測資料庫損壞，但其顯示中的某些模式可能表明存在潛在的損壞問題，需要進一步調查。

12.1 潛在資料庫損壞的症狀

如果資料庫損壞且正在被訪問，您可能偶爾會看到以下情況：

1. 在「進程」窗格中：

會話卡在 SUSPENDED 狀態，並出現異常等待類型
顯示錯誤狀態的行程
查詢反覆失敗

2. 在「資源等待」窗格中：

異常的 I/O 相關等待類型可能表示磁碟有問題（儘管這更有可能表明硬體問題而不是邏輯損壞）。

3. 近期高價查詢：

如果查詢重複嘗試讀取損壞的頁面，則會導致物理讀取次數異常高。

12.2 使用 DBCC CHECKDB 進行進一步檢查

當活動監視器顯示提示可能存在資料損壞的症狀時，應立即執行 DBCC CHECKDB 指令來驗證資料庫完整性。此指令會掃描所有資料庫頁，驗證校驗和，並檢查邏輯一致性錯誤。

要了解有關如何使用 DBCC CHECKDB 檢查和修復資料庫損壞的更多信息，請參閱我們的 DBCC CHECKDB 綜合指南.

12.3 使用專業工具進行維修

如果 DBCC CHECKDB 確認資料庫已損壞，您可以選擇以下幾種修復方法：

首選方法是從已知有效的備份中復原。參見我們關於如何備份和恢復的全面指南 SQL Server 數據庫.
對於輕微的資料庫損壞，使用帶有 REPAIR_REBUILD 的 DBCC CHECKDB 命令可以解決問題。
對於沒有近期備份的關鍵資料庫，專業備份方案至關重要。 SQL恢復軟體服務通常可以恢復內建修復選項無法恢復的資料。

13. 結論

SQL Server 活動監視器對於資料庫管理員來說是一個非常寶貴的工具，它可以立即提供有關伺服器效能的見解，並幫助快速有效地診斷問題。

13.1 總結

在本指南中，我們探討了「活動監視器」如何幫助您了解和檢查問題。 SQL Server 性能：

活動監視器透過有條理的圖形介面，提供對進程、等待、查詢和 I/O 的即時可見性。
五個窗格——概覽、進程、資源等待、資料檔案 I/O 和最近的高成本查詢——分別提供了伺服器活動的獨特視角。
透過有系統地進行活動監視器調查，可以解決諸如查詢執行過多、阻塞鍊和 CPU 使用率過高等常見故障排除問題。
雖然功能強大，但活動監視器也存在一些局限性，例如缺乏歷史資料、等待類型分組以及影響其應用範圍的監視開銷。cab能力。
透過 DMV 查詢、sp_WhoIsActive、擴展事件以及可能的第三方工具來補充活動監視器，可以建立全面的監視策略。
遵循最佳刷新間隔實踐，在不使用時關閉活動監視器，並將多個窗格合併以進行關聯，可以最大限度地發揮其價值，同時最大限度地減少其影響。

13.2 活動監視器作為工具包的一部分

活動監視器應作為效能調查的首選工具，而非唯一工具。它的優點在於能夠在故障排除過程中提供即時可見性，幫助您快速確定資料庫是否是瓶頸所在，並識別哪些特定方面需要深入調查。

您可以將「活動監視器」比作汽車的儀錶板—它會立即告訴您哪裡出了問題，並幫助您確定大致的故障區域。就像汽車儀錶板不會告訴您引擎故障指示燈亮起的具體原因一樣，「活動監視器」會指出問題所在，但並不總是能揭示問題的根本原因。要進行更深入的分析，則需要其他工具和專業知識。

將活動監視器整合到包含執行計劃分析、等待統計追蹤、歷史監控解決方案和效能最佳實踐的更廣泛工具包中。將其與適當的索引策略、查詢最佳化技術和容量規劃結合使用。

13.3 繼續你的學習之旅

掌握活動監視器只是成為高效率資料庫管理員的第一步。繼續提升您的技能，方法如下：

學習解讀執行計劃並識別低效操作
理解 SQL Server 等待統計數據及其影響
研究指標設計與優化技術
探索 SQL Server的架構及其查詢處理方式
實踐系統性的故障排除方法
利用擴展事件進行詳細追蹤的建置經驗
了解事務隔離等級及其對效能的影響

使用活動監視器進行的每一次效能調查都能讓你學到一些關於如何運作的新知識。 SQL Server 了解資料庫的工作原理以及應用程式如何與資料庫互動。記錄你的發現，與同事分享知識，並建立一個庫。rar針對常見問題的多種解決方案。

13.4 其他資源

利用以下寶貴資源拓展您的知識：

開啟活動監視器 SQL Server 管理工作室（SSMS） : 官方 SQL Server 關於如何開啟活動監視器的文檔 SQL Server 管理工作室（SSMS）。
活動監視器 ：官方的 SQL Server 關於如何使用活動監視器的文件。

14. 常見問題 (FAQ)

問：什麼是 SQL Server 活動監視器？

A: SQL Server 活動監視器是內建工具。 SQL Server 管理工作室，用於顯示有關在系統上運行的進程的即時信息 SQL Server 實例及其對伺服器資源的影響。它提供了一個圖形化儀表板，包含五個窗格，分別顯示伺服器活動的不同方面，包括處理器使用率、等待任務、I/O 速率、活動會話和高成本查詢。

Q：如何在SSMS中開啟活動監視器？

答：您可以透過四種方法開啟活動監視器：（1）點選 SSMS 工具列中的活動監視器圖示；（2）右鍵點選您的… SQL Server 在物件資源管理器中選擇實例名稱並選擇 活動監視器（3）按壓 按Ctrl + 其他 + A或 (4) 設定 SSMS 透過以下方式自動啟動它工具 -> 選項 -> 環境 -> Star管.

Q：使用活動監視器需要哪些權限？

A：你需要 查看伺服器狀態 允許查看 most 活動監視器資訊。對於「資料檔案 I/O」窗格，您還需要以下資訊之一 創建數據庫, 修改任何資料庫，或者 查看任何定義 權限。如果沒有這些權限，活動監視器可能可以打開，但會顯示空白窗格。

Q：為什麼我的活動監視器暫停或無法運作？

答：活動監視器暫停通常是因為權限問題、SSMS 版本過舊或遠端連線被停用造成的。解決方法：(1) 更新至最新 SSMS 版本；(2) 確認您擁有「檢視伺服器狀態」權限；(3) 檢查遠端連線是否已啟用。 SQL Server 例如，（4）資源tart SSMS，以及（5）如果適用，請嘗試使用 Windows 驗證而不是 SQL 驗證進行連接cab它們。

Q：活動監視器和 sp_WhoIsActive 有什麼不同？

答：活動監視器是 SSMS 內建的圖形化工具，提供用於不同監視方面的有序窗格。 sp_WhoIsActive 是一個由社區創建的免費存儲過程，它在單個結果集中返回詳細的會話信息，並提供比活動監視器更具體的等待類型、阻塞詳細信息和自定義選項。活動監視器更適合直觀地查看，而 sp_WhoIsActive 則擅長腳本監控並提供更詳細的資訊。

Q：活動監視器是否會影響伺服器效能？

答：是的，活動監視器會產生可衡量的開銷，因為它會在每次刷新間隔查詢系統動態管理視圖 (DMV)。刷新頻率越低，影響越大——微軟警告說，低於 10 秒的刷新間隔可能會影響伺服器效能。不使用活動監視器時，請務必將其關閉；對於高負載的生產伺服器，建議將刷新間隔設定為 30-60 秒。

Q：我可以使用 T-SQL 取得活動監視器資料嗎？

答：是的，活動監視器會查詢系統動態管理視圖，例如 sys.dm_exec_requests、sys.dm_exec_sessions、sys.dm_os_wait_stats 和 sys.dm_exec_query_stats。您可以使用 T-SQL 直接查詢這些 DMV，以程式設計方式擷取等效信息，從而實現自訂監視腳本和自動化資料收集。

Q：預設刷新間隔是多少？

答：預設刷新間隔為 10 秒。您可以透過在「概覽」窗格中的任意位置按一下滑鼠右鍵，然後選擇「變更刷新間隔」來變更此設定。 刷新間隔使用者可以從預設選項中選擇：1 秒、5 秒、10 秒、30 秒、1 分鐘或 1 小時。較低的間隔時間可以提供更即時的視圖，但會增加監控開銷。

Q：如何在 SSMS 中自動開啟活動監視器tar嘟嘟？

A：透過 SSMS 選項配置自動啟動：導覽至工具 -> 選項 -> 環境 -> Star管，然後選擇 開啟物件資源管理器和活動監視器 來自 在 star管 下拉式選單。每次在 SSMS 中連接到伺服器時，活動監視器都會自動開啟。

Q：活動監測器的限制是什麼？

答：主要限制包括：(1) 不具備歷史資料儲存或趨勢分析功能；(2) 等待類型被歸類，而非具體顯示；(3) 某些等待類型（例如 CXPACKET）可能不會顯示；(4) 時間點等待類型被歸類，而非具體顯示；(3) 某些等待類型（例如 CXPACKET）可能不會顯示；(4) 時間點主動監控可能遺漏瞬態問題；(5) 監控開銷可能會影響繁忙的伺服器；(6) 缺乏快照的自動監控可能遺漏瞬態問題；(5) 監控開銷可能會影響繁忙的伺服器；(6) 缺乏快照的自動監控可能遺漏瞬態問題；(5) 監控開銷可能會影響繁忙的伺服器；(6) 缺乏快照資料可能會遺漏的瞬態問題； SQL Server 例如，對於這些需求，可以使用擴展事件、資料收集集或第三方監控工具來補充活動監視器。

關於作者

元盛是一位資深資料庫管理員 (DBA)，擁有超過 10 年的 SQL Server 環境和企業資料庫管理。他成功解決了金融服務、醫療保健和製造業等行業的數百個資料庫恢復場景。

袁專長於 SQL Server 資料庫復原高可用性解決方案以及性能優化。他擁有豐富的實務經驗，包括管理數TB資料庫、實施Always On可用性群組，以及為關鍵業務系統開發自動化備份和復原策略。

透過他的技術專長和實踐方法，袁致力於創建全面的指南，幫助資料庫管理員和 IT 專業人員解決複雜的 SQL Server 高效應對挑戰。他始終掌握最新 SQL Server 版本和微軟不斷發展的資料庫技術，定期測試恢復場景以確保他的建議反映現實世界的最佳實踐。

有關於的問題 SQL Server 恢復或需要額外的資料庫故障排除指導？袁歡迎回饋和建議用於改進這些技術資源。