

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

# 資料庫負載
<a name="USER_PerfInsights.Overview.ActiveSessions"></a>

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

**Topics**
+ [作用中的工作階段](#USER_PerfInsights.Overview.ActiveSessions.active-sessions)
+ [平均作用中工作階段](#USER_PerfInsights.Overview.ActiveSessions.AAS)
+ [平均作用中執行數](#USER_PerfInsights.Overview.ActiveSessions.AAE)
+ [維度](#USER_PerfInsights.Overview.ActiveSessions.dimensions)

## 作用中的工作階段
<a name="USER_PerfInsights.Overview.ActiveSessions.active-sessions"></a>

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

工作階段處於作用中是指工作階段正在 CPU 上執行，或等待資源變成可用以繼續執行。例如，作用中工作階段可能等待分頁 (或區塊) 讀入記憶體中，然後從分頁讀取資料時耗用 CPU。

## 平均作用中工作階段
<a name="USER_PerfInsights.Overview.ActiveSessions.AAS"></a>

*平均作用中工作階段 (AAS)* 是 `DBLoad` 績效詳情的單位。它會測量資料庫上同時處於作用中狀態的工作階段數目。

每一秒，績效詳情都會取樣同時執行查詢的工作階段數目。針對每個作用中的工作階段，績效詳情會收集下列資料：
+ SQL 陳述式
+ 工作階段狀態 (正在 CPU 上執行或等待中)
+ 主機
+ 執行 SQL 的使用者

績效詳情會計算 AAS，方法是將工作階段總數除以特定時段的樣本數。例如，下表顯示執行查詢的 5 個連續範例，間隔至少為 1 秒。

[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/AmazonRDS/latest/UserGuide/USER_PerfInsights.Overview.ActiveSessions.html)

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

## 平均作用中執行數
<a name="USER_PerfInsights.Overview.ActiveSessions.AAE"></a>

每秒平均作用中執行數 (AAE) 與 AAS 相關。若要計算 AAE，績效詳情會將查詢的總執行時間除以時間間隔。下表顯示上表中同一個查詢的 AAE 計算。

[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/AmazonRDS/latest/UserGuide/USER_PerfInsights.Overview.ActiveSessions.html)

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

## 維度
<a name="USER_PerfInsights.Overview.ActiveSessions.dimensions"></a>

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

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

**Topics**
+ [等待事件](#USER_PerfInsights.Overview.ActiveSessions.waits)
+ [最高 SQL](#USER_PerfInsights.Overview.ActiveSessions.top-sql)
+ [計畫](#USER_PerfInsights.Overview.ActiveSessions.plans)

如需 Amazon RDS 引擎的維度完整清單，請參閱 [資料庫負載依維度配量](USER_PerfInsights.UsingDashboard.Components.md#USER_PerfInsights.UsingDashboard.Components.AvgActiveSessions.dims)。

### 等待事件
<a name="USER_PerfInsights.Overview.ActiveSessions.waits"></a>

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

每個使用中的工作階段都在 CPU 上執行或等待中。例如，工作階段在記憶體中搜尋緩衝區、執行計算或執行程序程式碼時會耗用 CPU。當工作階段不耗用 CPU 時，可能是在等待記憶體緩衝區變成可用、要讀取的資料檔或要寫入的記錄檔。工作階段等待資源越久，在 CPU 上執行的時間就越短。

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

等待事件依據資料庫引擎而有所差異：
+ 如需關於所有 MariaDB 和 MySQL 等待事件的資訊，請參閱 MySQL 文件中的[等待事件摘要表格](https://dev.mysql.com/doc/refman/8.0/en/performance-schema-wait-summary-tables.html)。
+ 如需關於所有 PostgreSQL 等待事件的資訊，請參閱 PostgreSQL 文件中的[統計數字收集器 > 等待事件表](https://www.postgresql.org/docs/current/monitoring-stats.html#WAIT-EVENT-TABLE)。
+ 如需關於所有 Oracle 等待事件的資訊，請參閱 Oracle 文件中的[等待事件說明](https://docs.oracle.com/database/121/REFRN/GUID-2FDDFAA4-24D0-4B80-A157-A907AF5C68E2.htm#REFRN-GUID-2FDDFAA4-24D0-4B80-A157-A907AF5C68E2)。
+ 如需所有 SQL Server 等待事件的相關資訊，請參閱 SQL 文件中的[等待類別](https://docs.microsoft.com/en-us/sql/relational-databases/system-dynamic-management-views/sys-dm-os-wait-stats-transact-sql?view=sql-server-2017#WaitTypes)。

**注意**  
對於 Oracle，背景程序有時不需要相關的 SQL 陳述式即可發揮作用。在這些情況下，「績效詳情」會報告背景程序的類型，後面加上冒號，還有與該背景程序相關聯的等待類別。背景程序的類型包括 `LGWR`、`ARC0`、`PMON` 等。  
例如，封存工具正在執行輸入/輸出時，績效詳情報告與 `ARC1:System I/O` 相當類似。有時候也會遺失背景程序類型，所以績效詳情只會報告等待類別，例如 `:System I/O`。

### 最高 SQL
<a name="USER_PerfInsights.Overview.ActiveSessions.top-sql"></a>

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

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

### 計畫
<a name="USER_PerfInsights.Overview.ActiveSessions.plans"></a>

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

針對資料庫執行個體，Performance Insights 會自動收集執行計畫。若要診斷 SQL 效能問題，請檢查擷取的計畫是否有耗用大量資源的 SQL 查詢。這些計畫顯示資料庫如何剖析和執行查詢。

若要了解如何使用計畫分析資料庫負載，請參閱：
+ Oracle: [使用 Amazon RDS 的 Performance Insights 儀表板來分析 Oracle 執行計畫](USER_PerfInsights.UsingDashboard.AccessPlans.md)
+ SQL Server：[使用 Amazon RDS 的 Performance Insights 儀表板來分析 SQL Server 執行計畫](USER_PerfInsights.UsingDashboard.AccessPlansSqlServer.md)

#### 計畫擷取
<a name="USER_PerfInsights.Overview.ActiveSessions.plans.capture"></a>

Performance Insights 每隔五分鐘會識別資源最密集的查詢並擷取其計畫。因此您不需要手動收集和管理大量的計畫。而是可以使用 **Top SQL** (最高 SQL) 索引標籤，將重點放在問題最大的查詢的計畫上。

**注意**  
若查詢的文字超過可收集的查詢文字上限，績效詳情就不會擷取其計畫。如需詳細資訊，請參閱 [在績效詳情儀表板中存取更多 SQL 文字](USER_PerfInsights.UsingDashboard.SQLTextSize.md)。

執行計畫的保留期間與所有 Performance Insights 資料的保留期間相同。保留設定為**預設值 (7 天)**。若要更長時間保留績效資料，請指定 1 - 24 個月。如需保留期間的詳細資訊，請參閱 [Performance Insights 的定價和資料保留](USER_PerfInsights.Overview.cost.md)。

#### 摘要查詢
<a name="USER_PerfInsights.Overview.ActiveSessions.plans.digest"></a>

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

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