資料庫負載 - Amazon Relational Database Service
作用中的工作階段平均作用中工作階段平均作用中執行數維度

本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

資料庫負載

資料庫負載 (DB 載入) 會測量資料庫中工作階段活動的層級。 DBLoad是「Performance Insights 見」中的關鍵指標，而 Performance Insights 每秒都會收集資料庫負載。

作用中的工作階段

資料庫工作階段代表應用程式與關聯式資料庫的對話。作用中工作階段是已提交工作給資料庫引擎且正在等待回應的連線。

工作階段在執行CPU或等待資源變為可用，以便它可以繼續時，會處於作用中狀態。例如，作用中的工作階段可能會等待頁面 (或區塊) 讀入記憶體，然後在從網頁讀取資料CPU時耗用。

平均作用中工作階段

平均作用中工作階段 (AAS) 是「Performance Insights」中DBLoad度量的單位。它會測量資料庫上同時處於作用中狀態的工作階段數目。

每一秒，績效詳情都會取樣同時執行查詢的工作階段數目。針對每個作用中的工作階段，績效詳情會收集下列資料：

  • SQL聲明

  • 工作階段狀態 (執行中CPU或等待中)

  • 主機

  • 使用者執行 SQL

Performance Insights 透AAS過將工作階段總數除以特定時段的範例數來計算。例如，下表顯示執行查詢的 5 個連續範例，間隔至少為 1 秒。

樣本 執行查詢的工作階段數目 AAS 算式
1 2 2 工作階段總數 2 / 1 個樣本
2 0 1 工作階段總數 2 / 2 個樣本
3 4 2 工作階段總數 6 / 3 個樣本
4 0 1.5 工作階段總數 6 / 4 個樣本
5 4 2 工作階段總數 10 / 5 個樣本

在上述範例中，時間間隔的資料庫負載為 2 AAS。此測量表示在採集 5 個樣本的間隔期間內，於任何特定時間平均有 2 個工作階段處於作用中。

平均作用中執行數

平均作用中執行次數 (AAE) 每秒與。AAS若要計算AAE，Performance Insights 會將查詢的總執行時間除以時間間隔。下表顯示前面資料表中相同查詢的AAE計算方式。

經過時間 (秒) 總執行時間 (秒) AAE 計算
60 120 2 120 執行秒 / 60 秒經過
120 120 1 120 執行秒 / 120 秒經過
180 380 2.11 380 執行秒/180 秒經過
240 380 1.58 380 執行秒/240 秒經過
300 600 2 600 執行秒 / 300 秒經過

在大多數情況下AAS，AAE查詢的和大致相同。不過，由於計算的輸入是不同的資料來源，所以計算通常會略有不同。

維度

db.load 指標與其他時間序列指標不同，因為您可以將它分為名為維度的子元件。您可以將維度視為 DBLoad 指標不同特性的「配量依據」類別。

診斷效能問題時，下列維度通常最實用：

如需 Amazon RDS 引擎維度的完整清單，請參閱資料庫負載依維度配量。

等待事件

wait 事件會導致SQL陳述式等待特定事件發生，然後才能繼續執行。等待事件指出工作在何處受阻，是資料庫負載的重要維度或類別。

每個使用中的工作階段都在執行CPU或等待中。例如，CPU當工作階段搜尋記憶體以尋找緩衝區、執行計算或執行程序程式碼時，會耗用這些工作階段。當工作階段不耗用時CPU，它們可能正在等待記憶體緩衝區變為可用、要讀取的資料檔案或要寫入的記錄檔。階段作業等待資源的時間越長，在CPU.

調校資料庫時，您通常會嘗試查明工作階段正在等待的資源。例如，兩個或三個等待事件可能佔資料庫負載的 90%。此量值表示作用中工作階段平均花最多時間等待少量資源。如果您可以找出這些等待的原因，就可以嘗試解決方案。

等待事件依據資料庫引擎而有所差異：

注意

對於 Oracle，後台進程有時可以在沒有關聯SQL語句的情況下工作。在這些情況下，「績效詳情」會報告背景程序的類型，後面加上冒號，還有與該背景程序相關聯的等待類別。背景程序的類型包括 LGWR、ARC0、PMON 等。

例如，封存工具正在執行輸入/輸出時，績效詳情報告與 ARC1:System I/O 相當類似。有時候也會遺失背景程序類型，所以績效詳情只會報告等待類別，例如 :System I/O。

頂部 SQL

等待事件顯示瓶頸時，頂端SQL會顯示哪些查詢對資料庫負載的貢獻最大。例如，許多查詢目前可能正在資料庫上執行，但單一查詢可能會耗用 99% 的資料庫負載。在此情況下，高負載可能表示查詢發生問題。

根據預設，Performance Insights 主控台會顯示對資料庫負載有貢獻的常用SQL查詢。主控台也會顯示每個陳述式的相關統計資料。若要診斷特定陳述式的效能問題，您可以檢查其執行計劃。

計畫

執行計畫簡稱為計畫，是存取資料的一連串步驟。例如，聯結資料表 t1 和 t2 的計畫，可能會循環 t1 中的所有資料列，並將每一列與 t2 中的某列做比較。在關聯式資料庫中，最佳化工具是內建程式碼，可決定SQL查詢最有效率的計畫。

對於資料庫執行個體，Performance Insights 會自動收集執行計劃 若要診斷SQL效能問題，請檢查擷取的計劃是否有高資源SQL查詢。這些計劃顯示了數據庫如何解析和運行查詢。

若要瞭解如何使用計劃分析資料庫負載，請參閱：

計畫擷取

Performance Insights 每五分鐘就會識別最耗用資源的查詢，並擷取其計劃。因此您不需要手動收集和管理大量的計畫。相反地，您可以使用 SQL [頂端] 索引標籤來專注於最有問題的查詢的計劃。

注意

若查詢的文字超過可收集的查詢文字上限，績效詳情就不會擷取其計畫。如需詳細資訊，請參閱存取 Performance Insights 儀表板中的更多SQL文字。

執行計畫的保留期間與所有 Performance Insights 資料的保留期間相同。免費方案中的保留設定為 Default (7 days) (預設值 (7 天))。若要更長時間保留績效資料，請指定 1 - 24 個月。如需保留期間的詳細資訊，請參閱 Performance Insights 的定價和資料保留。

摘要查詢

SQL[頂端] 索引標籤預設會顯示摘要查詢。摘要查詢本身沒有計畫，但使用文字值的所有查詢都具有計畫。例如，摘要查詢可能包含文字 WHERE `email`=?。摘要可能包含兩個查詢，其中一個具有文字 WHERE email=user1@example.com，另一個含有 WHERE email=user2@example.com。這些文字查詢全都可能包含多個計畫。

當您選取摘要查詢時，主控台會顯示所選摘要之子陳述式的所有計劃。因此，您不需要查看所有的子陳述式來尋找計畫。您可能會看到前 10 個子陳述式清單中沒有顯示的計畫。主控台顯示已收集計畫的所有子查之計畫，無論這些查詢是否排入前 10 名。