本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# Aurora PostgreSQL 函數參考
您可以在下文找到 Aurora PostgreSQL 函數的清單，這些函數適用於執行 Aurora PostgreSQL 相容版本資料庫引擎的 Aurora 資料庫叢集。除了標準 PostgreSQL 函數之外，還有這些 Aurora PostgreSQL 函數。如需標準 PostgreSQL 函數的詳細資訊，請參閱 [PostgreSQL–函數和運算子](https://www.postgresql.org/docs/current/functions.html)。
## 概觀
您可對執行 Aurora PostgreSQL 的 Amazon RDS 資料庫執行個體使用下列函數：
+ [aurora\$1db\$1instance\$1identifier](aurora_db_instance_identifier.md)
+ [aurora\$1ccm\$1status](aurora_ccm_status.md)
+ [aurora\$1global\$1db\$1instance\$1status](aurora_global_db_instance_status.md)
+ [aurora\$1global\$1db\$1status](aurora_global_db_status.md)
+ [aurora\$1list\$1builtins](aurora_list_builtins.md)
+ [aurora\$1replica\$1status](aurora_replica_status.md)
+ [aurora\$1stat\$1activity](aurora_stat_activity.md)
+ [aurora\$1stat\$1backend\$1waits](aurora_stat_backend_waits.md)
+ [aurora\$1stat\$1bgwriter](aurora_stat_bgwriter.md)
+ [aurora\$1stat\$1database](aurora_stat_database.md)
+ [aurora\$1stat\$1dml\$1activity](aurora_stat_dml_activity.md)
+ [aurora\$1stat\$1get\$1db\$1commit\$1latency](aurora_stat_get_db_commit_latency.md)
+ [aurora\$1stat\$1logical\$1wal\$1cache](aurora_stat_logical_wal_cache.md)
+ [aurora\$1stat\$1memctx\$1usage](aurora_stat_memctx_usage.md)
+ [aurora\$1stat\$1optimized\$1reads\$1cache](aurora_stat_optimized_reads_cache.md)
+ [aurora\$1stat\$1plans](aurora_stat_plans.md)
+ [aurora\$1stat\$1reset\$1wal\$1cache](aurora_stat_reset_wal_cache.md)
+ [aurora\$1stat\$1statements](aurora_stat_statements.md)
+ [aurora\$1stat\$1system\$1waits](aurora_stat_system_waits.md)
+ [aurora\$1stat\$1wait\$1event](aurora_stat_wait_event.md)
+ [aurora\$1stat\$1wait\$1type](aurora_stat_wait_type.md)
+ [aurora\$1version](aurora_version.md)
+ [aurora\$1volume\$1logical\$1start\$1lsn](aurora_volume_logical_start_lsn.md)
+ [aurora\$1wait\$1report](aurora_wait_report.md)
# aurora\$1db\$1instance\$1identifier
報告您所連線的資料庫執行個體名稱。
## 語法
```
aurora_db_instance_identifier()
```
## 引數
無
## 傳回類型
VARCHAR 字串
## 使用須知
此函數會顯示 Aurora PostgreSQL 相容版叢集的資料庫執行個體名稱，適用於您的資料庫用戶端或應用程式連線。
此函數從 PostgreSQL 版本 13.7、12.11、11.16、10.21 及所有其他更新的版本開始提供。
## 範例
下列範例顯示呼叫 `aurora_db_instance_identifier` 函數的結果。
```
=> SELECT aurora_db_instance_identifier();
aurora_db_instance_identifier
-------------------------------
test-my-instance-name
```
您可以將此函數的結果與 `aurora_replica_status` 函數聯結，以取得連線資料庫執行個體的詳細資訊。只有 [aurora\$1replica\$1status](aurora_replica_status.md) 並不能提供向您顯示您正在使用的資料庫執行個體。下列範例會顯示作法。
```
=> SELECT *
FROM aurora_replica_status() rt,
aurora_db_instance_identifier() di
WHERE rt.server_id = di;
-[ RECORD 1 ]----------------------+-----------------------
server_id | test-my-instance-name
session_id | MASTER_SESSION_ID
durable_lsn | 88492069
highest_lsn_rcvd |
current_read_lsn |
cur_replay_latency_in_usec |
active_txns |
is_current | t
last_transport_error | 0
last_error_timestamp |
last_update_timestamp | 2022-06-03 11:18:25+00
feedback_xmin |
feedback_epoch |
replica_lag_in_msec |
log_stream_speed_in_kib_per_second | 0
log_buffer_sequence_number | 0
oldest_read_view_trx_id |
oldest_read_view_lsn |
pending_read_ios | 819
```
# aurora\$1ccm\$1status
顯示叢集快取管理員的狀態。
## 語法
```
aurora_ccm_status()
```
## 引數
無。
## 傳回類型
SETOF 記錄，包含下列欄：
+ `buffers_sent_last_minute` – 過去一分鐘內傳送至指定讀取器的緩衝區數量。
+ `buffers_found_last_minute` – 過去一分鐘內識別出頻繁存取緩衝區的數量。
+ `buffers_sent_last_scan` – 於緩衝區快取的最後一次完整掃描期間傳送至指定讀取器的緩衝區數量。
+ `buffers_found_last_scan` – 於緩衝區快取的最後一次完整掃描期間傳送的頻繁存取緩衝區數量。已在指定讀取器上快取的緩衝區未傳送。
+ `buffers_sent_current_scan` – 於目前掃描期間傳送的緩衝區數量。
+ `buffers_found_current_scan` – 於目前掃描中識別之頻繁存取緩衝區的數量。
+ `current_scan_progress` – 於目前掃描期間至現在為止所造訪的緩衝區數量。
## 使用須知
您可使用此功能來檢查和監控叢集快取管理 (CCM) 功能。此函數僅適用於 CCM 在 Aurora PostgreSQL 資料庫叢集上為作用中時。如要使用此函數，請連線至 Aurora PostgreSQL 資料庫叢集上的寫入資料庫執行個體。
您可於叢集的自訂資料庫叢集參數群組中將 `apg_ccm_enabled` 設定為 1，為 Aurora PostgreSQL 資料庫叢集開啟 CCM。如要瞭解如何作業，請參閱[設定叢集快取管理](AuroraPostgreSQL.cluster-cache-mgmt.md#AuroraPostgreSQL.cluster-cache-mgmt.Configure)。
當叢集具有 Aurora 讀取器執行個體設定如下時，叢集快取管理在 Aurora PostgreSQL 資料庫叢集為作用中狀態：
+ Aurora 讀取器執行個體會使用與叢集寫入器執行個體相同的資料庫執行個體類別類型和大小。
+ Aurora 讀取器執行個體會設定為叢集的第 0 層。若叢集具有多個讀取器，則此為其唯一的第 0 層讀取器。
將多個讀取器設定為第 0 層將會停用 CCM。停用 CCM 時，呼叫此函數會回傳下列錯誤訊息：
```
ERROR: Cluster Cache Manager is disabled
```
您還可使用 PostgreSQL Pg\$1Buffercache 擴充功能來分析緩衝區快取。如需詳細資訊，請參閱 PostgreSQL 文件中的 [pg\$1buffercache](https://www.postgresql.org/docs/current/pgbuffercache.html)。
如需詳細資訊，請參閱 [Introduction to Aurora PostgreSQL cluster cache management](https://aws.amazon.com/blogs/database/introduction-to-aurora-postgresql-cluster-cache-management/) (Aurora PostgreSQL 叢集快取管理簡介)。
## 範例
下列範例顯示呼叫 `aurora_ccm_status` 函數的結果。第一個範例顯示 CCM 統計資料。
```
=> SELECT * FROM aurora_ccm_status();
buffers_sent_last_minute | buffers_found_last_minute | buffers_sent_last_scan | buffers_found_last_scan | buffers_sent_current_scan | buffers_found_current_scan | current_scan_progress
--------------------------+---------------------------+------------------------+-------------------------+---------------------------+----------------------------+-----------------------
2242000 | 2242003 | 17920442 | 17923410 | 14098000 | 14100964 | 15877443
```
如需更多完整的詳細資訊，您可使用展開顯示，如下所示：
```
\x
Expanded display is on.
SELECT * FROM aurora_ccm_status();
[ RECORD 1 ]-----------------------+---------
buffers_sent_last_minute | 2242000
buffers_found_last_minute | 2242003
buffers_sent_last_scan | 17920442
buffers_found_last_scan | 17923410
buffers_sent_current_scan | 14098000
buffers_found_current_scan | 14100964
current_scan_progress | 15877443
```
此範例說明如何檢查暖率和暖百分比。
```
=> SELECT buffers_sent_last_minute * 8/60 AS warm_rate_kbps,
100 * (1.0-buffers_sent_last_scan/buffers_found_last_scan) AS warm_percent
FROM aurora_ccm_status ();
warm_rate_kbps | warm_percent
----------------+--------------
16523 | 100.0
```
# aurora\$1global\$1db\$1instance\$1status
顯示所有 Aurora 執行個體的狀態，包括 Aurora 全域資料庫叢集中的複本。
## 語法
```
aurora_global_db_instance_status()
```
## 引數
無
## 傳回類型
SETOF 記錄，包含下列欄：
+ `server_id` – 資料庫執行個體的識別符。
+ `session_id` – 目前工作階段的唯一識別符。`MASTER_SESSION_ID` 值可識別寫入器 (主) 資料庫執行個體。
+ `aws_region` – 此全域資料庫執行個體執行所在的 AWS 區域。如需區域清單，請參閱 [區域可用性](Concepts.RegionsAndAvailabilityZones.md#Aurora.Overview.Availability)。
+ `durable_lsn` – 可長期儲存的日誌序號 (LSN)。記錄序號 (LSN) 是一組獨特的序號，可用來識別資料庫交易日誌中的記錄。系統會排序 LSN，而 LSN 越大，就表示交易發生時間越後面。
+ `highest_lsn_rcvd` – 資料庫執行個體從寫入器資料庫執行個體接收的最高 LSN。
+ `feedback_epoch` – 資料庫執行個體產生熱待命資訊時所使用的 epoch。*熱待命*是主資料庫處於復原或待命模式時支援連線和查詢的資料庫執行個體。熱待命資訊包括 epoch (時間點) 及有關用來作為熱待命資料庫執行個體的其他詳細資料。如需詳細資訊，請參閱 PostgreSQL 文件中的 [Hot standby (熱待命)](https://www.postgresql.org/docs/current/hot-standby.html)。
+ `feedback_xmin` – 資料庫執行個體所使用的最小 (最舊) 作用中交易 ID。
+ `oldest_read_view_lsn` – 資料庫執行個體從儲存體中讀取資料時所使用的最舊 LSN。
+ `visibility_lag_in_msec` – 此資料庫執行個體落後於寫入器資料庫執行個體的時間 (以毫秒為單位)。
## 使用須知
此函數會顯示 Aurora 資料庫叢集的複寫統計資料。對於叢集中的每個 Aurora PostgreSQL 資料庫執行個體，此函數會顯示一列資料，其中包括全域資料庫組態中的任何跨區域複本。
您可從 Aurora PostgreSQL 資料庫叢集或 Aurora PostgreSQL 全域資料庫中的任何執行個體執行此函數。該函數會回傳所有複本執行個體的延遲相關詳細資料。
若要進一步了解使用此函數 (`aurora_global_db_instance_status`) 或使用 `aurora_global_db_status` 監控延遲的相關資訊，請參閱 [監控 Aurora PostgreSQL 型全球資料庫](aurora-global-database-monitoring.md#aurora-global-database-monitoring.postgres)。
如需更多 Aurora 全域資料庫的詳細資訊，請參閱 [Amazon Aurora 全球資料庫的概觀](aurora-global-database.md#aurora-global-database-overview)。
若要開始使用 Aurora 全域資料庫，請參閱 [Amazon Aurora 全球資料庫入門](aurora-global-database-getting-started.md)，或請參閱 [Amazon Aurora 常見問答集](https://aws.amazon.com/rds/aurora/faqs/)。
## 範例
此範例示範跨區域執行個體統計資料。
```
=> SELECT *
FROM aurora_global_db_instance_status();
server_id | session_id | aws_region | durable_lsn | highest_lsn_rcvd | feedback_epoch | feedback_xmin | oldest_read_view_lsn | visibility_lag_in_msec
------------------------------------------+--------------------------------------+--------------+-------------+------------------+----------------+---------------+----------------------+------------------------
db-119-001-instance-01 | MASTER_SESSION_ID | eu-west-1 | 2534560273 | [NULL] | [NULL] | [NULL] | [NULL] | [NULL]
db-119-001-instance-02 | 4ecff34d-d57c-409c-ba28-278b31d6fc40 | eu-west-1 | 2534560266 | 2534560273 | 0 | 19669196 | 2534560266 | 6
db-119-001-instance-03 | 3e8a20fc-be86-43d5-95e5-bdf19d27ad6b | eu-west-1 | 2534560266 | 2534560273 | 0 | 19669196 | 2534560266 | 6
db-119-001-instance-04 | fc1b0023-e8b4-4361-bede-2a7e926cead6 | eu-west-1 | 2534560266 | 2534560273 | 0 | 19669196 | 2534560254 | 23
db-119-001-instance-05 | 30319b74-3f08-4e13-9728-e02aa1aa8649 | eu-west-1 | 2534560266 | 2534560273 | 0 | 19669196 | 2534560254 | 23
db-119-001-global-instance-1 | a331ffbb-d982-49ba-8973-527c96329c60 | eu-central-1 | 2534560254 | 2534560266 | 0 | 19669196 | 2534560247 | 996
db-119-001-global-instance-1 | e0955367-7082-43c4-b4db-70674064a9da | eu-west-2 | 2534560254 | 2534560266 | 0 | 19669196 | 2534560247 | 14
db-119-001-global-instance-1-eu-west-2a | 1248dc12-d3a4-46f5-a9e2-85850491a897 | eu-west-2 | 2534560254 | 2534560266 | 0 | 19669196 | 2534560247 | 0
```
此範例示範如何檢查全域複本延遲 (以毫秒為單位)。
```
=> SELECT CASE
WHEN 'MASTER_SESSION_ID' = session_id THEN 'Primary'
ELSE 'Secondary'
END AS global_role,
aws_region,
server_id,
visibility_lag_in_msec
FROM aurora_global_db_instance_status()
ORDER BY 1, 2, 3;
global_role | aws_region | server_id | visibility_lag_in_msec
-------------+--------------+-----------------------------------------+------------------------
Primary | eu-west-1 | db-119-001-instance-01 | [NULL]
Secondary | eu-central-1 | db-119-001-global-instance-1 | 13
Secondary | eu-west-1 | db-119-001-instance-02 | 10
Secondary | eu-west-1 | db-119-001-instance-03 | 9
Secondary | eu-west-1 | db-119-001-instance-04 | 2
Secondary | eu-west-1 | db-119-001-instance-05 | 18
Secondary | eu-west-2 | db-119-001-global-instance-1 | 14
Secondary | eu-west-2 | db-119-001-global-instance-1-eu-west-2a | 13
```
此範例示範如何從全域資料庫組態檢查每個 AWS 區域 的最小、最大，及平均延遲。
```
=> SELECT 'Secondary' global_role,
aws_region,
min(visibility_lag_in_msec) min_lag_in_msec,
max(visibility_lag_in_msec) max_lag_in_msec,
round(avg(visibility_lag_in_msec),0) avg_lag_in_msec
FROM aurora_global_db_instance_status()
WHERE aws_region NOT IN (SELECT aws_region
FROM aurora_global_db_instance_status()
WHERE session_id='MASTER_SESSION_ID')
GROUP BY aws_region
UNION ALL
SELECT 'Primary' global_role,
aws_region,
NULL,
NULL,
NULL
FROM aurora_global_db_instance_status()
WHERE session_id='MASTER_SESSION_ID'
ORDER BY 1, 5;
global_role | aws_region | min_lag_in_msec | max_lag_in_msec | avg_lag_in_msec
------------+--------------+-----------------+-----------------+-----------------
Primary | eu-west-1 | [NULL] | [NULL] | [NULL]
Secondary | eu-central-1 | 133 | 133 | 133
Secondary | eu-west-2 | 0 | 495 | 248
```
# aurora\$1global\$1db\$1status
顯示有關 Aurora 全域資料庫延遲各方面的資訊，特別是基礎 Aurora 儲存的延遲 (稱為持久性延遲) 及復原點目標 (RPO) 之間的延遲。
## 語法
```
aurora_global_db_status()
```
## 引數
無。
## 傳回類型
SETOF 記錄，包含下列欄：
+ `aws_region` – 此資料庫叢集所在的 AWS 區域。如需依引擎列出的 AWS 區域 完整清單，請參閱 [區域和可用區域](Concepts.RegionsAndAvailabilityZones.md)。
+ `highest_lsn_written` – 目前存在於此資料庫叢集上的最高日誌序號 (LSN)。記錄序號 (LSN) 是一組獨特的序號，可用來識別資料庫交易日誌中的記錄。系統會排序 LSN，而 LSN 越大，就表示交易發生時間越後面。
+ `durability_lag_in_msec` – 次要資料庫叢集上的 `highest_lsn_written` 與主資料庫叢集上的 `highest_lsn_written` 之間的時間戳記值差異。值 -1 識別 Aurora 全域資料庫的主要資料庫叢集。
+ `rpo_lag_in_msec` – 復原點目標 (RPO) 延遲。RPO 延遲是指最近使用者交易 COMMIT 在儲存於 Aurora 全域資料庫的主資料庫叢集之後，將其儲存於次要資料庫叢集上所需的時間。值 -1 表示主要資料庫叢集 (因此沒有延遲的問題)。
簡言之，此指標會計算 Aurora 全域資料庫中每個 Aurora PostgreSQL 資料庫叢集的復原點目標，亦即，若有中斷發生，可能會遺失的資料量。與延遲一樣，RPO 是以時間來衡量。
+ `last_lag_calculation_time` – 指出上次為 `durability_lag_in_msec` 和 `rpo_lag_in_msec` 計算值的時間戳記。例如 `1970-01-01 00:00:00+00` 之類的時間值表示此為主要資料庫叢集。
+ `feedback_epoch` – 次要資料庫叢集產生熱待命資訊時所使用的 epoch。*熱待命*是主資料庫為復原或待命模式時支援連線和查詢的資料庫執行個體。熱待命資訊包括 epoch (時間點) 及有關用來作為熱待命資料庫執行個體的其他詳細資料。如需詳細資訊，請參閱 PostgreSQL 文件中的 [Hot standby (熱待命)](https://www.postgresql.org/docs/current/hot-standby.html)。
+ `feedback_xmin` – 次要資料庫叢集所使用的最小 (最舊) 作用中交易 ID。
## 使用須知
所有目前可用的 Aurora PostgreSQL 版本都支援此功能。此函數會顯示 Aurora 全域資料庫的複寫統計資料。Aurora PostgreSQL 全域資料庫中每個資料庫叢集會各自顯示為一列。您可從 Aurora PostgreSQL 全域資料庫中的任何執行個體執行此函數。
如要評估 Aurora 全域資料庫複製延遲 (此為可見的資料延遲)，請參閱 [aurora\$1global\$1db\$1instance\$1status](aurora_global_db_instance_status.md)。
若要進一步了解使用 `aurora_global_db_status` 和 `aurora_global_db_instance_status` 來監控 Aurora 全域資料庫延遲，請參閱 [監控 Aurora PostgreSQL 型全球資料庫](aurora-global-database-monitoring.md#aurora-global-database-monitoring.postgres)。如需更多 Aurora 全域資料庫的詳細資訊，請參閱 [Amazon Aurora 全球資料庫的概觀](aurora-global-database.md#aurora-global-database-overview)。
## 範例
此範例示範如何顯示跨區域儲存統計資料。
```
=> SELECT CASE
WHEN '-1' = durability_lag_in_msec THEN 'Primary'
ELSE 'Secondary'
END AS global_role,
*
FROM aurora_global_db_status();
global_role | aws_region | highest_lsn_written | durability_lag_in_msec | rpo_lag_in_msec | last_lag_calculation_time | feedback_epoch | feedback_xmin
-------------+------------+---------------------+------------------------+-----------------+----------------------------+----------------+---------------
Primary | eu-west-1 | 131031557 | -1 | -1 | 1970-01-01 00:00:00+00 | 0 | 0
Secondary | eu-west-2 | 131031554 | 410 | 0 | 2021-06-01 18:59:36.124+00 | 0 | 12640
Secondary | eu-west-3 | 131031554 | 410 | 0 | 2021-06-01 18:59:36.124+00 | 0 | 12640
```
# aurora\$1list\$1builtins
列出所有可用的 Aurora PostgreSQL 內建函數，以及簡要說明和函數詳細資訊。
## 語法
```
aurora_list_builtins()
```
## 引數
無
## 傳回類型
SETOF 記錄
## 範例
下列範例會顯示呼叫 `aurora_list_builtins` 函數的結果。
```
=> SELECT *
FROM aurora_list_builtins();
Name | Result data type | Argument data types | Type | Volatility | Parallel | Security | Description
-----------------------------------+------------------+----------------------------------------------------------+------+------------+------------+----------+---------------------------------------------------------------------
aurora_version | text | | func | stable | safe | invoker | Amazon Aurora PostgreSQL-Compatible Edition version string
aurora_stat_wait_type | SETOF record | OUT type_id smallint, OUT type_name text | func | volatile | restricted | invoker | Lists all supported wait types
aurora_stat_wait_event | SETOF record | OUT type_id smallint, OUT event_id integer, OUT event_na.| func | volatile | restricted | invoker | Lists all supported wait events
| |.me text | | | | |
aurora_list_builtins | SETOF record | OUT "Name" text, OUT "Result data type" text, OUT "Argum.| func | stable | safe | invoker | Lists all Aurora built-in functions
| |.ent data types" text, OUT "Type" text, OUT "Volatility" .| | | | |
| |.text, OUT "Parallel" text, OUT "Security" text, OUT "Des.| | | | |
| |.cription" text | | | | |
.
.
.
aurora_stat_file | SETOF record | OUT filename text, OUT allocated_bytes bigint, OUT used_.| func | stable | safe | invoker | Lists all files present in Aurora storage
| |.bytes bigint | | | | |
aurora_stat_get_db_commit_latency | bigint | oid | func | stable | restricted | invoker | Per DB commit latency in microsecs
```
# aurora\$1replica\$1status
顯示所有 Aurora PostgreSQL 讀取器節點的狀態。
## 語法
```
aurora_replica_status()
```
## 引數
無
## 傳回類型
SETOF 記錄，包含下列欄：
+ `server_id` – 資料庫執行個體 ID (識別符)。
+ `session_id` – 目前工作階段的唯一識別符，如下所示，為主要執行個體和讀取器執行個體傳回：
+ 若為主要執行個體，`session_id` 一律為 ``MASTER_SESSION_ID’`。
+ 若為讀取器執行個體，`session_id` 一律為讀取器執行個體的 `UUID` (通用唯一識別符)。
+ `durable_lsn` – 已儲存於儲存體中的日誌序號 (LSN)。
+ 若為主磁碟區，目前作用中的主磁碟區耐用性 LSN (VDL)。
+ 若為任何次要磁碟區，次要已成功套用至之主要的 VDL。
**注意**
記錄序號 (LSN) 是一組獨特的序號，可用來識別資料庫交易日誌中的記錄。LSN 依順序排列，LSN 越大，就表示交易發生時間越後面。
+ `highest_lsn_rcvd` – 資料庫執行個體從寫入器資料庫執行個體接收的最高 (最新) LSN。
+ `current_read_lsn` – 套用至所有讀取器之最新快照的 LSN。
+ `cur_replay_latency_in_usec` – 預期在次要設備上重播日誌所需的微秒數。
+ `active_txns` – 目前作用中交易的數目。
+ `is_current` – 未使用。
+ `last_transport_error` – 上次複寫錯誤代碼。
+ `last_error_timestamp` – 上次複寫錯誤的時間戳記。
+ `last_update_timestamp` – 上次更新複本狀態的時間戳記。從 Aurora PostgreSQL 13.9 開始，您連線的資料庫執行個體的 `last_update_timestamp` 值會設定為 `NULL`。
+ `feedback_xmin` – 複本的熱待命 feedback\$1xmin。資料庫執行個體所使用的最小 (最舊) 作用中交易 ID。
+ `feedback_epoch` – 資料庫執行個體產生熱待命資訊時所使用的 epoch。
+ `replica_lag_in_msec`：讀取器執行個體延遲於執行個體的時間 (以毫秒為單位)。
+ `log_stream_speed_in_kib_per_second` – 日誌串流輸送量 (以 KB/秒為單位)。
+ `log_buffer_sequence_number` – 日誌緩衝區序列號。
+ `oldest_read_view_trx_id` – 未使用。
+ `oldest_read_view_lsn` – 資料庫執行個體從儲存體中讀取資料時所使用的最舊 LSN。
+ `pending_read_ios` – 複本上仍處於待命狀態的未完成頁面讀取。
+ `read_ios` – 複本上的頁面讀取總數。
+ `iops` – 未使用。
+ `cpu`：叢集中每個節點的 Aurora 儲存常駐程式 CPU 用量。如需有關執行個體 CPU 用量的資訊，請參閱 [Amazon Aurora 的執行個體層級指標](Aurora.AuroraMonitoring.Metrics.md#Aurora.AuroraMySQL.Monitoring.Metrics.instances)。
## 使用須知
所有目前可用的 Aurora PostgreSQL 版本都支援此功能。`aurora_replica_status` 函數會從 Aurora PostgreSQL 資料庫叢集的複本狀態管理器傳回值。您可使用此函數以獲取有關 Aurora PostgreSQL 資料庫叢集上複寫狀態的資訊，包括 Aurora 資料庫叢集中所有資料庫執行個體的指標。例如，您可以執行下列動作：
+ **取得有關 Aurora PostgreSQL 資料庫叢集中執行個體類型 (寫入器、讀取器) 的資訊** – 您可檢查下列欄的值以取得此資訊：
+ `server_id` – 包含您在建立執行個體時指定的執行個體名稱。在某些情況下，例如對於主 (寫入器) 執行個體，該名稱通常是將 *-instance-1* 附加至您為 Aurora PostgreSQL 資料庫叢集建立的名稱來建立的。
+ `session_id` – `session_id` 欄位指出執行個體是讀取器還是寫入器。若為寫入器執行個體，`session_id` 一律設定為 `"MASTER_SESSION_ID"`。若為讀取器執行個體，`session_id` 設定為特定讀取器的 `UUID`。
+ **診斷常見複寫問題，如複本延遲** - 複本延遲是讀取器執行個體頁面快取落後於寫入器執行個體頁面快取的時間 (以毫秒為單位)。出現此延遲的原因是 Aurora 叢集使用非同步複寫，如 [以 Amazon Aurora 進行複寫](Aurora.Replication.md) 所述。其顯示於此函數傳回結果中的 `replica_lag_in_msec` 欄中。由於與備用伺服器上的復原衝突而取消查詢時，也可能會發生延遲。您可檢查 `pg_stat_database_conflicts()`，以驗證此類衝突是否造成複本延遲。如需相關資訊，請參閱 *PostgreSQL 文件*中的[統計數字收集器](https://www.postgresql.org/docs/current/monitoring-stats.html#MONITORING-PG-STAT-DATABASE-CONFLICTS-VIEW)。如要進一步了解有關高可用性和複寫的資訊，請參 [Amazon Aurora 常見問答集](https://aws.amazon.com/rds/aurora/faqs/#High_Availability_and_Replication)。
Amazon CloudWatch 隨時間將 `replica_lag_in_msec` 結果儲存為 `AuroraReplicaLag` 指標。如需使用 Aurora 的 CloudWatch 指標相關資訊，請參閱 [使用 Amazon CloudWatch 監控 Amazon Aurora 指標](monitoring-cloudwatch.md)。
若要進一步了解 Aurora 僅供讀取複本和重新啟動的疑難排解相關資訊，請參閱 [AWS 支援 中心](https://console.aws.amazon.com/support/home#/)中的[為什麼我的 Amazon Aurora 僅供讀取複本落後且重新啟動？](https://aws.amazon.com/premiumsupport/knowledge-center/aurora-read-replica-restart/)。
## 範例
下列範例顯示如何獲取 Aurora PostgreSQL 資料庫叢集中所有執行個體的複寫狀態：
```
=> SELECT *
FROM aurora_replica_status();
```
下列範例顯示 `docs-lab-apg-main` Aurora PostgreSQL 資料庫叢集中的寫入器執行個體：
```
=> SELECT server_id,
CASE
WHEN 'MASTER_SESSION_ID' = session_id THEN 'writer'
ELSE 'reader'
END AS instance_role
FROM aurora_replica_status()
WHERE session_id = 'MASTER_SESSION_ID';
server_id | instance_role
------------------------+---------------
db-119-001-instance-01 | writer
```
下列範例會列出叢集中的所有讀取器執行個體：
```
=> SELECT server_id,
CASE
WHEN 'MASTER_SESSION_ID' = session_id THEN 'writer'
ELSE 'reader'
END AS instance_role
FROM aurora_replica_status()
WHERE session_id <> 'MASTER_SESSION_ID';
server_id | instance_role
------------------------+---------------
db-119-001-instance-02 | reader
db-119-001-instance-03 | reader
db-119-001-instance-04 | reader
db-119-001-instance-05 | reader
(4 rows)
```
下列範例列出了所有執行個體、每個執行個體落後於寫入器的延遲距離，及自上次更新以來的時間：
```
=> SELECT server_id,
CASE
WHEN 'MASTER_SESSION_ID' = session_id THEN 'writer'
ELSE 'reader'
END AS instance_role,
replica_lag_in_msec AS replica_lag_ms,
round(extract (epoch FROM (SELECT age(clock_timestamp(), last_update_timestamp))) * 1000) AS last_update_age_ms
FROM aurora_replica_status()
ORDER BY replica_lag_in_msec NULLS FIRST;
server_id | instance_role | replica_lag_ms | last_update_age_ms
------------------------+---------------+----------------+--------------------
db-124-001-instance-03 | writer | [NULL] | 1756
db-124-001-instance-01 | reader | 13 | 1756
db-124-001-instance-02 | reader | 13 | 1756
(3 rows)
```
# aurora\$1stat\$1activity
傳回每個伺服器程序的一列，顯示該程序目前活動相關的資訊。
## 語法
```
aurora_stat_activity();
```
## 引數
無
## 傳回類型
每個伺服器程序傳回一列。除了 `pg_stat_activity` 欄之外，還會新增下列欄位：
+ planid：計劃識別符
## 使用須知
`pg_stat_activity` 用來傳回相同欄的補充檢視，其中包含附加 `plan_id` 欄，此欄會顯示目前的查詢執行計劃。
必須啟用 `aurora_compute_plan_id`，檢視才能傳回 plan\$1id。
您可從 Aurora PostgreSQL 版本 14.10、15.5 及所有其他更新的版本使用此函數。
## 範例
以下查詢範例會依 query\$1id 和 plan\$1id 彙總最高負載。
```
db1=# select count(*), query_id, plan_id
db1-# from aurora_stat_activity() where state = 'active'
db1-# and pid <> pg_backend_pid()
db1-# group by query_id, plan_id
db1-# order by 1 desc;
count | query_id | plan_id
-------+----------------------+-------------
11 | -5471422286312252535 | -2054628807
3 | -6907107586630739258 | -815866029
1 | 5213711845501580017 | 300482084
(3 rows)
```
如果用於 query\$1id 的計劃有所變更，則 aurora\$1stat\$1activity 將報告新的 plan\$1id。
```
count | query_id | plan_id
-------+----------------------+-------------
10 | -5471422286312252535 | 1602979607
1 | -6907107586630739258 | -1809935983
1 | -2446282393000597155 | -207532066
(3 rows)
```
# aurora\$1stat\$1backend\$1waits
顯示特定後端程序的等待活動統計資料。
## 語法
```
aurora_stat_backend_waits(pid)
```
## 引數
`pid` – 後端程序的 ID。您可使用 `pg_stat_activity` 檢視取得程序 ID。
## 傳回類型
SETOF 記錄，包含下列欄：
+ `type_id` – 表示等待事件類型的數字，例如，`1` 表示輕量型鎖定 (`LWLock`)，`3` 表示鎖定，或 `6` 表示用戶端工作階段。當您將此函數的結果與 `aurora_stat_wait_type` 函數的欄聯結時，這些值會變得有意義，如 [範例](#aurora_stat_backend_waits-examples) 中所示。
+ `event_id` – 等待事件的識別號碼。將此值與 `aurora_stat_wait_event` 中的欄聯結，以取得有意義的事件名稱。
+ `waits` – 指定程序 ID 的累積等待數目。
+ `wait_time` – 等待時間 (以毫秒為單位)。
## 使用須知
您可使用此函數分析自連線開啟後發生的特定後端 (工作階段) 等待事件。如要取得有關等待事件名稱和類型更有意義的資訊，您可以使用範例中所示的 JOIN，結合此函數 `aurora_stat_wait_type` 和 `aurora_stat_wait_event`。
## 範例
此範例會示範後端程序 ID 3027 的所有等待、類型和事件名稱。
```
=> SELECT type_name, event_name, waits, wait_time
FROM aurora_stat_backend_waits(3027)
NATURAL JOIN aurora_stat_wait_type()
NATURAL JOIN aurora_stat_wait_event();
type_name | event_name | waits | wait_time
-----------+------------------------+-------+------------
LWLock | ProcArrayLock | 3 | 27
LWLock | wal_insert | 423 | 16336
LWLock | buffer_content | 11840 | 1033634
LWLock | lock_manager | 23821 | 5664506
Lock | tuple | 10258 | 152280165
Lock | transactionid | 78340 | 1239808783
Client | ClientRead | 34072 | 17616684
IO | ControlFileSyncUpdate | 2 | 0
IO | ControlFileWriteUpdate | 4 | 32
IO | RelationMapRead | 2 | 795
IO | WALWrite | 36666 | 98623
IO | XactSync | 4867 | 7331963
```
此範例會示範所有作用中工作階段 (`pg_stat_activity state <> 'idle'`) 目前及累積等待類型和等待事件 (但並無叫用函數 (`pid <> pg_backend_pid()`) 的目前工作階段。
```
=> SELECT a.pid,
a.usename,
a.app_name,
a.current_wait_type,
a.current_wait_event,
a.current_state,
wt.type_name AS wait_type,
we.event_name AS wait_event,
a.waits,
a.wait_time
FROM (SELECT pid,
usename,
left(application_name,16) AS app_name,
coalesce(wait_event_type,'CPU') AS current_wait_type,
coalesce(wait_event,'CPU') AS current_wait_event,
state AS current_state,
(aurora_stat_backend_waits(pid)).*
FROM pg_stat_activity
WHERE pid <> pg_backend_pid()
AND state <> 'idle') a
NATURAL JOIN aurora_stat_wait_type() wt
NATURAL JOIN aurora_stat_wait_event() we;
pid | usename | app_name | current_wait_type | current_wait_event | current_state | wait_type | wait_event | waits | wait_time
-------+----------+----------+-------------------+--------------------+---------------+-----------+------------------------+-------+-----------
30099 | postgres | pgbench | Lock | transactionid | active | LWLock | wal_insert | 1937 | 29975
30099 | postgres | pgbench | Lock | transactionid | active | LWLock | buffer_content | 22903 | 760498
30099 | postgres | pgbench | Lock | transactionid | active | LWLock | lock_manager | 10012 | 223207
30099 | postgres | pgbench | Lock | transactionid | active | Lock | tuple | 20315 | 63081529
.
.
.
30099 | postgres | pgbench | Lock | transactionid | active | IO | WALWrite | 93293 | 237440
30099 | postgres | pgbench | Lock | transactionid | active | IO | XactSync | 13010 | 19525143
30100 | postgres | pgbench | Lock | transactionid | active | LWLock | ProcArrayLock | 6 | 53
30100 | postgres | pgbench | Lock | transactionid | active | LWLock | wal_insert | 1913 | 25450
30100 | postgres | pgbench | Lock | transactionid | active | LWLock | buffer_content | 22874 | 778005
.
.
.
30109 | postgres | pgbench | IO | XactSync | active | LWLock | ProcArrayLock | 3 | 71
30109 | postgres | pgbench | IO | XactSync | active | LWLock | wal_insert | 1940 | 27741
30109 | postgres | pgbench | IO | XactSync | active | LWLock | buffer_content | 22962 | 776352
30109 | postgres | pgbench | IO | XactSync | active | LWLock | lock_manager | 9879 | 218826
30109 | postgres | pgbench | IO | XactSync | active | Lock | tuple | 20401 | 63581306
30109 | postgres | pgbench | IO | XactSync | active | Lock | transactionid | 50769 | 211645008
30109 | postgres | pgbench | IO | XactSync | active | Client | ClientRead | 89901 | 44192439
```
此範例會示範所有作用中工作階段 (`pg_stat_activity state <> 'idle'`) 目前及前三 (3) 個累積等待類型和等待事件，目前工作階段 (`pid <>pg_backend_pid()`) 除外。
```
=> SELECT top3.*
FROM (SELECT a.pid,
a.usename,
a.app_name,
a.current_wait_type,
a.current_wait_event,
a.current_state,
wt.type_name AS wait_type,
we.event_name AS wait_event,
a.waits,
a.wait_time,
RANK() OVER (PARTITION BY pid ORDER BY a.wait_time DESC)
FROM (SELECT pid,
usename,
left(application_name,16) AS app_name,
coalesce(wait_event_type,'CPU') AS current_wait_type,
coalesce(wait_event,'CPU') AS current_wait_event,
state AS current_state,
(aurora_stat_backend_waits(pid)).*
FROM pg_stat_activity
WHERE pid <> pg_backend_pid()
AND state <> 'idle') a
NATURAL JOIN aurora_stat_wait_type() wt
NATURAL JOIN aurora_stat_wait_event() we) top3
WHERE RANK <=3;
pid | usename | app_name | current_wait_type | current_wait_event | current_state | wait_type | wait_event | waits | wait_time | rank
-------+----------+----------+-------------------+--------------------+---------------+-----------+-----------------+---------+------------+------
20567 | postgres | psql | CPU | CPU | active | LWLock | wal_insert | 25000 | 67512003 | 1
20567 | postgres | psql | CPU | CPU | active | IO | WALWrite | 3071758 | 1016961 | 2
20567 | postgres | psql | CPU | CPU | active | IO | BufFileWrite | 20750 | 184559 | 3
27743 | postgres | pgbench | Lock | transactionid | active | Lock | transactionid | 237350 | 1265580011 | 1
27743 | postgres | pgbench | Lock | transactionid | active | Lock | tuple | 93641 | 341472318 | 2
27743 | postgres | pgbench | Lock | transactionid | active | Client | ClientRead | 417556 | 204796837 | 3
.
.
.
27745 | postgres | pgbench | IO | XactSync | active | Lock | transactionid | 238068 | 1265816822 | 1
27745 | postgres | pgbench | IO | XactSync | active | Lock | tuple | 93210 | 338312247 | 2
27745 | postgres | pgbench | IO | XactSync | active | Client | ClientRead | 419157 | 207836533 | 3
27746 | postgres | pgbench | Lock | transactionid | active | Lock | transactionid | 237621 | 1264528811 | 1
27746 | postgres | pgbench | Lock | transactionid | active | Lock | tuple | 93563 | 339799310 | 2
27746 | postgres | pgbench | Lock | transactionid | active | Client | ClientRead | 417304 | 208372727 | 3
```
# aurora\$1stat\$1bgwriter
`aurora_stat_bgwriter` 是顯示有關 Optimized Reads 快取寫入資訊的統計資料檢視
## 語法
```
aurora_stat_bgwriter()
```
## 引數
無
## 傳回類型
SETOF 記錄包含所有 `pg_stat_bgwriter` 欄和以下附加欄。如需 `pg_stat_bgwriter` 欄的詳細資訊，請參閱 [https://www.postgresql.org/docs/current/monitoring-stats.html#MONITORING-PG-STAT-BGWRITER-VIEW](https://www.postgresql.org/docs/current/monitoring-stats.html#MONITORING-PG-STAT-BGWRITER-VIEW)。
您可以使用 `pg_stat_reset_shared("bgwriter")` 重設此函數的統計資料。
+ `orcache_blks_written` - 寫入的最佳化讀取快取資料區塊總數。
+ `orcache_blk_write_time` - 如果啟用 `track_io_timing`，它會追蹤寫入最佳化讀取快取資料檔案區塊所花費的總時間，以毫秒為單位。如需詳細資訊，請參閱 [track\$1io\$1timing](https://www.postgresql.org/docs/current/runtime-config-statistics.html#GUC-TRACK-IO-TIMING)。
## 使用須知
此函數適用於下列 Aurora PostgreSQL 版本：
+ 15.4 版和更新的 15 版本
+ 14.9 版和更新的 14 版本
## 範例
```
=> select * from aurora_stat_bgwriter();
-[ RECORD 1 ]-----------------+-----------
orcache_blks_written | 246522
orcache_blk_write_time | 339276.404
```
# aurora\$1stat\$1database
它攜帶 pg\$1stat\$1database 的所有欄，並在結尾加上新欄。
## 語法
```
aurora_stat_database()
```
## 引數
無
## 傳回類型
SETOF 記錄包含所有 `pg_stat_database` 欄和以下附加欄。如需 `pg_stat_database` 欄的詳細資訊，請參閱 [https://www.postgresql.org/docs/current/monitoring-stats.html#MONITORING-PG-STAT-DATABASE-VIEW](https://www.postgresql.org/docs/current/monitoring-stats.html#MONITORING-PG-STAT-DATABASE-VIEW)。
+ `storage_blks_read` - 從此資料庫中 Aurora 儲存體讀取的共用區塊總數。
+ `orcache_blks_hit` - 此資料庫中最佳化讀取快取命中的總數。
+ `local_blks_read` - 在此資料庫中讀取的本機區塊總數。
+ `storage_blk_read_time` - 如果啟用 `track_io_timing`，它會追蹤從 Aurora 儲存讀取資料檔案區塊所花費的總時間 (以毫秒為單位)，否則值為零。如需詳細資訊，請參閱 [track\$1io\$1timing](https://www.postgresql.org/docs/current/runtime-config-statistics.html#GUC-TRACK-IO-TIMING)。
+ `local_blk_read_time` - 如果啟用 `track_io_timing`，它會追蹤讀取本機資料檔案區塊所花費的總時間 (以毫秒為單位)，否則值為零。如需詳細資訊，請參閱 [track\$1io\$1timing](https://www.postgresql.org/docs/current/runtime-config-statistics.html#GUC-TRACK-IO-TIMING)。
+ `orcache_blk_read_time` - 如果啟用 `track_io_timing`，它會追蹤從最佳化讀取快取中讀取資料檔案區塊所花費的總時間 (以毫秒為單位)，否則值為零。如需詳細資訊，請參閱 [track\$1io\$1timing](https://www.postgresql.org/docs/current/runtime-config-statistics.html#GUC-TRACK-IO-TIMING)。
**注意**
`blks_read` 的值是 `storage_blks_read`、`orcache_blks_hit` 和 `local_blks_read` 的總和。
`blk_read_time` 的值是 `storage_blk_read_time`、`orcache_blk_read_time` 和 `local_blk_read_time` 的總和。
## 使用須知
此函數適用於下列 Aurora PostgreSQL 版本：
+ 15.4 版和更新的 15 版本
+ 14.9 版和更新的 14 版本
## 範例
以下範例顯示它如何攜帶所有 `pg_stat_database` 欄並在結尾附加 6 個新欄：
```
=> select * from aurora_stat_database() where datid=14717;
-[ RECORD 1 ]------------+------------------------------
datid | 14717
datname | postgres
numbackends | 1
xact_commit | 223
xact_rollback | 4
blks_read | 1059
blks_hit | 11456
tup_returned | 27746
tup_fetched | 5220
tup_inserted | 165
tup_updated | 42
tup_deleted | 91
conflicts | 0
temp_files | 0
temp_bytes | 0
deadlocks | 0
checksum_failures |
checksum_last_failure |
blk_read_time | 3358.689
blk_write_time | 0
session_time | 1076007.997
active_time | 3684.371
idle_in_transaction_time | 0
sessions | 10
sessions_abandoned | 0
sessions_fatal | 0
sessions_killed | 0
stats_reset | 2023-01-12 20:15:17.370601+00
orcache_blks_hit | 425
orcache_blk_read_time | 89.934
storage_blks_read | 623
storage_blk_read_time | 3254.914
local_blks_read | 0
local_blk_read_time | 0
```
# aurora\$1stat\$1dml\$1activity
報告 Aurora PostgreSQL 叢集中資料庫上每種資料處理語言 (DML) 作業類型的累積活動。
## 語法
```
aurora_stat_dml_activity(database_oid)
```
## 引數
*database\$1oid*
Aurora PostgreSQL 叢集中資料庫的物件 ID (OID)。
## 傳回類型
SETOF 記錄
## 使用須知
`aurora_stat_dml_activity` 函數僅適用於與 PostgreSQL 引擎 11.6 及更新版本相容的 Aurora PostgreSQL 3.1 版。
在具有大量資料庫的 Aurora PostgreSQL 叢集上使用此函數，來識別哪些資料庫具有較多或較慢的 DML 活動，或兩者兼具。
`aurora_stat_dml_activity` 函數傳回的作業執行的次數，及 SELECT、INSERT、UPDATE 和 DELETE 作業的累積延遲 (以微秒為單位)。該報告僅包含成功的 DML 作業。
您可使用 PostgreSQL 統計數字存取函數 `pg_stat_reset` 來重置此統計數字。您可使用 `pg_stat_get_db_stat_reset_time` 函數，檢查上次重設此統計數字的時間。如需有關 PostgreSQL 統計數字存取函數的詳細資訊，請參閱 PostgreSQL 文件中的[統計數字收集器](https://www.postgresql.org/docs/9.1/monitoring-stats.html)。
## 範例
下列範例顯示如何報告已連線資料庫的 DML 活動統計數字。
```
––Define the oid variable from connected database by using \gset
=> SELECT oid,
datname
FROM pg_database
WHERE datname=(select current_database()) \gset
=> SELECT *
FROM aurora_stat_dml_activity(:oid);
select_count | select_latency_microsecs | insert_count | insert_latency_microsecs | update_count | update_latency_microsecs | delete_count | delete_latency_microsecs
--------------+--------------------------+--------------+--------------------------+--------------+--------------------------+--------------+--------------------------
178957 | 66684115 | 171065 | 28876649 | 519538 | 1454579206167 | 1 | 53027
–– Showing the same results with expanded display on
=> SELECT *
FROM aurora_stat_dml_activity(:oid);
-[ RECORD 1 ]------------+--------------
select_count | 178957
select_latency_microsecs | 66684115
insert_count | 171065
insert_latency_microsecs | 28876649
update_count | 519538
update_latency_microsecs | 1454579206167
delete_count | 1
delete_latency_microsecs | 53027
```
下列範例顯示 Aurora PostgreSQL 叢集中所有資料庫的 DML 活動統計數字。此叢集有兩個資料庫：`postgres` 和 `mydb`。以逗號分隔的清單會與 `select_count`、`select_latency_microsecs`、`insert_count`、`insert_latency_microsecs`、`update_count`、`update_latency_microsecs`、`delete_count` 和 `delete_latency_microsecs` 欄位相對應。
Aurora PostgreSQL 建立並使用一個名為 `rdsadmin` 的系統資料庫來支援管理作業，例如備份、還原、運作狀態檢查、複寫等等。這些 DML 作業對您的 Aurora PostgreSQL 叢集並無任何影響。
```
=> SELECT oid,
datname,
aurora_stat_dml_activity(oid)
FROM pg_database;
oid | datname | aurora_stat_dml_activity
-------+----------------+-----------------------------------------------------------------
14006 | template0 | (,,,,,,,)
16384 | rdsadmin | (2346623,1211703821,4297518,817184554,0,0,0,0)
1 | template1 | (,,,,,,,)
14007 | postgres | (178961,66716329,171065,28876649,519538,1454579206167,1,53027)
16401 | mydb | (200246,64302436,200036,107101855,600000,83659417514,0,0)
```
下列範例顯示所有資料庫的 DML 活動統計數字以資料欄進行編排，提高可讀性。
```
SELECT db.datname,
BTRIM(SPLIT_PART(db.asdmla::TEXT, ',', 1), '()') AS select_count,
BTRIM(SPLIT_PART(db.asdmla::TEXT, ',', 2), '()') AS select_latency_microsecs,
BTRIM(SPLIT_PART(db.asdmla::TEXT, ',', 3), '()') AS insert_count,
BTRIM(SPLIT_PART(db.asdmla::TEXT, ',', 4), '()') AS insert_latency_microsecs,
BTRIM(SPLIT_PART(db.asdmla::TEXT, ',', 5), '()') AS update_count,
BTRIM(SPLIT_PART(db.asdmla::TEXT, ',', 6), '()') AS update_latency_microsecs,
BTRIM(SPLIT_PART(db.asdmla::TEXT, ',', 7), '()') AS delete_count,
BTRIM(SPLIT_PART(db.asdmla::TEXT, ',', 8), '()') AS delete_latency_microsecs
FROM (SELECT datname,
aurora_stat_dml_activity(oid) AS asdmla
FROM pg_database
) AS db;
datname | select_count | select_latency_microsecs | insert_count | insert_latency_microsecs | update_count | update_latency_microsecs | delete_count | delete_latency_microsecs
----------------+--------------+--------------------------+--------------+--------------------------+--------------+--------------------------+--------------+--------------------------
template0 | | | | | | | |
rdsadmin | 4206523 | 2478812333 | 7009414 | 1338482258 | 0 | 0 | 0 | 0
template1 | | | | | | | |
fault_test | 66 | 452099 | 0 | 0 | 0 | 0 | 0 | 0
db_access_test | 1 | 5982 | 0 | 0 | 0 | 0 | 0 | 0
postgres | 42035 | 95179203 | 5752 | 2678832898 | 21157 | 441883182488 | 2 | 1520
mydb | 71 | 453514 | 0 | 0 | 1 | 190 | 1 | 152
```
下列範例顯示了資料庫 (具 OID `16401`) 之每個 DML 作業的平均累積延遲 (累積延遲除以計數)。
```
=> SELECT select_count,
select_latency_microsecs,
select_latency_microsecs/NULLIF(select_count,0) select_latency_per_exec,
insert_count,
insert_latency_microsecs,
insert_latency_microsecs/NULLIF(insert_count,0) insert_latency_per_exec,
update_count,
update_latency_microsecs,
update_latency_microsecs/NULLIF(update_count,0) update_latency_per_exec,
delete_count,
delete_latency_microsecs,
delete_latency_microsecs/NULLIF(delete_count,0) delete_latency_per_exec
FROM aurora_stat_dml_activity(16401);
-[ RECORD 1 ]------------+-------------
select_count | 451312
select_latency_microsecs | 80205857
select_latency_per_exec | 177
insert_count | 451001
insert_latency_microsecs | 123667646
insert_latency_per_exec | 274
update_count | 1353067
update_latency_microsecs | 200900695615
update_latency_per_exec | 148478
delete_count | 12
delete_latency_microsecs | 448
delete_latency_per_exec | 37
```
# aurora\$1stat\$1get\$1db\$1commit\$1latency
取得 Aurora PostgreSQL 資料庫的累積遞交延遲 (以微秒為單位)。*遞交延遲*是指用戶端提交一個遞交請求和其收到遞交確認之間的時間。
## 語法
```
aurora_stat_get_db_commit_latency(database_oid)
```
## 引數
*database\$1oid*
Aurora PostgreSQL 資料庫的物件 ID (OID)。
## 傳回類型
SETOF 記錄
## 使用須知
Amazon CloudWatch 使用此函數來計算平均遞交延遲。如需有關 Amazon CloudWatch 指標及如何對高遞交延遲進行疑難排解的詳細資訊，請參閱 [在 Amazon RDS 主控台中檢視指標](USER_Monitoring.md) 和 [利用 Amazon CloudWatch 指標對 Amazon RDS 做出更好的決策](https://aws.amazon.com/blogs/database/making-better-decisions-about-amazon-rds-with-amazon-cloudwatch-metrics/)。
您可使用 PostgreSQL 統計數字存取函數 `pg_stat_reset` 來重置此統計數字。您可使用 `pg_stat_get_db_stat_reset_time` 函數，檢查上次重設此統計數字的時間。如需有關 PostgreSQL 統計數字存取函數的詳細資訊，請參閱 PostgreSQL 文件中的[統計數字收集器](https://www.postgresql.org/docs/9.1/monitoring-stats.html)。
## 範例
下列範例會取得 `pg_database` 叢集中每個資料庫的累積遞交延遲。
```
=> SELECT oid,
datname,
aurora_stat_get_db_commit_latency(oid)
FROM pg_database;
oid | datname | aurora_stat_get_db_commit_latency
-------+----------------+-----------------------------------
14006 | template0 | 0
16384 | rdsadmin | 654387789
1 | template1 | 0
16401 | mydb | 229556
69768 | postgres | 22011
```
下列範例會取得目前已連線資料庫的累積遞交延遲。呼叫 `aurora_stat_get_db_commit_latency` 函數之前，該範例會先使用 `\gset` 來定義 `oid` 引數的變數，並從已連線的資料庫設定其值。
```
––Get the oid value from the connected database before calling aurora_stat_get_db_commit_latency
=> SELECT oid
FROM pg_database
WHERE datname=(SELECT current_database()) \gset
=> SELECT *
FROM aurora_stat_get_db_commit_latency(:oid);
aurora_stat_get_db_commit_latency
-----------------------------------
1424279160
```
下列範例會取得 `pg_database` 叢集中 `mydb` 資料庫的累積遞交延遲。接著，其會使用 `pg_stat_reset` 函數來重設此統計數字並顯示結果。最後，其可使用 `pg_stat_get_db_stat_reset_time` 函數來檢查上次重設此統計數字的時間。
```
=> SELECT oid,
datname,
aurora_stat_get_db_commit_latency(oid)
FROM pg_database
WHERE datname = 'mydb';
oid | datname | aurora_stat_get_db_commit_latency
-------+-----------+-----------------------------------
16427 | mydb | 3320370
=> SELECT pg_stat_reset();
pg_stat_reset
---------------
=> SELECT oid,
datname,
aurora_stat_get_db_commit_latency(oid)
FROM pg_database
WHERE datname = 'mydb';
oid | datname | aurora_stat_get_db_commit_latency
-------+-----------+-----------------------------------
16427 | mydb | 6
=> SELECT *
FROM pg_stat_get_db_stat_reset_time(16427);
pg_stat_get_db_stat_reset_time
--------------------------------
2021-04-29 21:36:15.707399+00
```
# aurora\$1stat\$1logical\$1wal\$1cache
顯示每個插槽的邏輯預寫日誌 (WAL) 快取使用量。
## 語法
```
SELECT * FROM aurora_stat_logical_wal_cache()
```
## 引數
無
## 傳回類型
SETOF 記錄，包含下列欄：
+ `name` - 複寫槽的名稱。
+ `active_pid` – walsender 程序的 ID。
+ `cache_hit` – 自上次重設以來的 WAL 快存命中總數。
+ `cache_miss` – 自上次重設以來的 WAL 快存未命中總數。
+ `blks_read` – WAL 快取讀取請求的總數。
+ `hit_rate` – WAL 快取命中率 (cache\$1hit / blks\$1read)。
+ `last_reset_timestamp` – 上次重設計數器的時間。
## 使用須知
此函數適用於下列 Aurora PostgreSQL 版本。
+ 15.2 版和所有更新版本
+ 14.7 及更新版本
+ 13.8 和更新版本
+ 12.12 和更新版本
+ 11.17 和更新版本
## 範例
下列範例顯示了兩個只有一個作用中 `aurora_stat_logical_wal_cache` 函數的複寫槽。
```
=> SELECT *
FROM aurora_stat_logical_wal_cache();
name | active_pid | cache_hit | cache_miss | blks_read | hit_rate | last_reset_timestamp
------------+------------+-----------+------------+-----------+----------+-------------------------------
test_slot1 | 79183 | 24 | 0 | 24 | 100.00% | 2022-08-05 17:39:56.830635+00
test_slot2 | | 1 | 0 | 1 | 100.00% | 2022-08-05 17:34:04.036795+00
(2 rows)
```
# aurora\$1stat\$1memctx\$1usage
報告每個 PostgreSQL 程序的記憶體內容使用情況。
## 語法
```
aurora_stat_memctx_usage()
```
## 引數
無
## 傳回類型
SETOF 記錄，包含下列欄：
+ `pid` – 程序的 ID。
+ `name` – 記憶體內容的名稱。
+ `allocated` – 記憶體內容從基礎記憶體子系統取得的位元組數量。
+ `used` – 提交至記憶體內容用戶端的位元組數量。
+ `instances` – 此類型現有內容目前的計數。
## 使用須知
此函數顯示每個 PostgreSQL 程序的記憶體內容使用情況。有些處理程序會標示 `anonymous`。程序不會公開，因為它們包含受限制的關鍵字。
此函數從下列 Aurora PostgreSQL 版本開始適用：
+ 15.3 版和更新的 15 版本
+ 14.8 版和更新的 14 版本
+ 13.11 版和更新的 13 版本
+ 12.15 版和更新的 12 版
+ 11.20 版和更新的 11 版本
## 範例
下列範例顯示呼叫 `aurora_stat_memctx_usage` 函數的結果。
```
=> SELECT *
FROM aurora_stat_memctx_usage();
pid| name | allocated | used | instances
-------+---------------------------------+-----------+---------+-----------
123864 | Miscellaneous | 19520 | 15064 | 3
123864 | Aurora File Context | 8192 | 616 | 1
123864 | Aurora WAL Context | 8192 | 296 | 1
123864 | CacheMemoryContext | 524288 | 422600 | 1
123864 | Catalog tuple context | 16384 | 13736 | 1
123864 | ExecutorState | 32832 | 28304 | 1
123864 | ExprContext | 8192 | 1720 | 1
123864 | GWAL record construction | 1024 | 832 | 1
123864 | MdSmgr | 8192 | 296 | 1
123864 | MessageContext | 532480 | 353832 | 1
123864 | PortalHeapMemory | 1024 | 488 | 1
123864 | PortalMemory | 8192 | 576 | 1
123864 | printtup | 8192 | 296 | 1
123864 | RelCache hash table entries | 8192 | 8152 | 1
123864 | RowDescriptionContext | 8192 | 1344 | 1
123864 | smgr relation context | 8192 | 296 | 1
123864 | Table function arguments | 8192 | 352 | 1
123864 | TopTransactionContext | 8192 | 632 | 1
123864 | TransactionAbortContext | 32768 | 296 | 1
123864 | WAL record construction | 50216 | 43904 | 1
123864 | hash table | 65536 | 52744 | 6
123864 | Relation metadata | 191488 | 124240 | 87
104992 | Miscellaneous | 9280 | 7728 | 3
104992 | Aurora File Context | 8192 | 376 | 1
104992 | Aurora WAL Context | 8192 | 296 | 1
104992 ||Autovacuum Launcher | 8192 | 296 | 1
104992 | Autovacuum database list | 16384 | 744 | 2
104992 | CacheMemoryContext | 262144 | 140288 | 1
104992 | Catalog tuple context | 8192 | 296 | 1
104992 | GWAL record construction | 1024 | 832 | 1
104992 | MdSmgr | 8192 | 296 | 1
104992 | PortalMemory | 8192 | 296 | 1
104992 | RelCache hash table entries | 8192 | 296 | 1
104992 | smgr relation context | 8192 | 296 | 1
104992 | Autovacuum start worker (tmp) | 8192 | 296 | 1
104992 | TopTransactionContext | 16384 | 592 | 2
104992 | TransactionAbortContext | 32768 | 296 | 1
104992 | WAL record construction | 50216 | 43904 | 1
104992 | hash table | 49152 | 34024 | 4
(39 rows)
```
將隱藏一些受限制的關鍵字，輸出結果如下所示：
```
postgres=>SELECT *
FROM aurora_stat_memctx_usage();
pid| name | allocated | used | instances
-------+---------------------------------+-----------+---------+-----------
5482 | anonymous | 8192 | 456 | 1
5482 | anonymous | 8192 | 296 | 1
```
# aurora\$1stat\$1optimized\$1reads\$1cache
此函數顯示階層式快取統計資料。
## 語法
```
aurora_stat_optimized_reads_cache()
```
## 引數
無
## 傳回類型
SETOF 記錄，包含下列欄：
+ `total_size` - 總最佳化讀取快取大小。
+ `used_size` - 在最佳化讀取快取中使用的頁面大小。
## 使用須知
此函數適用於下列 Aurora PostgreSQL 版本：
+ 15.4 版和更新的 15 版本
+ 14.9 版和更新的 14 版本
## 範例
下列範例會在 r6gd.8xlarge 執行個體中顯示輸出：
```
=> select pg_size_pretty(total_size) as total_size, pg_size_pretty(used_size)
as used_size from aurora_stat_optimized_reads_cache();
total_size | used_size
-----------+-----------
1054 GB | 975 GB
```
# aurora\$1stat\$1plans
傳回每個追蹤執行計劃的列。
## 語法
```
aurora_stat_plans(
showtext
)
```
## 引數
+ showtext：顯示查詢和計劃文字。有效值為 NULL、true 或 false。True 會顯示查詢和計劃文字。
## 傳回類型
傳回每個追蹤計劃的列，其中包含來自 `aurora_stat_statements` 的所有欄和下列額外欄。
+ planid：計劃識別符
+ explain\$1plan：解釋計劃文字
+ plan\$1type：
+ `no plan`：未擷取任何計劃
+ `estimate`：以預估成本擷取的計劃
+ `actual`：使用 EXPLAIN ANALYZE 擷取的計劃
+ plan\$1captured\$1time：計劃的前次擷取時間
## 使用須知
必須啟用 `aurora_compute_plan_id`，且 `pg_stat_statements` 必須位於 `shared_preload_libraries`，才能追蹤計劃。
可用的計劃數量由 `pg_stat_statements.max` 參數中設定的值所控制。啟用 `aurora_compute_plan_id` 時，您可以在 `aurora_stat_plans` 中追蹤高達此指定值的計劃。
您可從 Aurora PostgreSQL 版本 14.10、15.5 及所有其他更新的版本使用此函數。
## 範例
在下面的範例中，會擷取查詢識別符 -5471422286312252535 的兩個計劃，以及由 planid 追蹤陳述式統計資料。
```
db1=# select calls, total_exec_time, planid, plan_captured_time, explain_plan
db1-# from aurora_stat_plans(true)
db1-# where queryid = '-5471422286312252535'
calls | total_exec_time | planid | plan_captured_time | explain_plan
---------+--------------------+-------------+-------------------------------+------------------------------------------------------------------
1532632 | 3209846.097107853 | 1602979607 | 2023-10-31 03:27:16.925497+00 | Update on pgbench_branches +
| | | | -> Bitmap Heap Scan on pgbench_branches +
| | | | Recheck Cond: (bid = 76) +
| | | | -> Bitmap Index Scan on pgbench_branches_pkey +
| | | | Index Cond: (bid = 76)
61365 | 124078.18012200127 | -2054628807 | 2023-10-31 03:20:09.85429+00 | Update on pgbench_branches +
| | | | -> Index Scan using pgbench_branches_pkey on pgbench_branches+
| | | | Index Cond: (bid = 17)
```
# aurora\$1stat\$1reset\$1wal\$1cache
Resets the counter for logical wal cache.
## 語法
重設特定槽
```
SELECT * FROM aurora_stat_reset_wal_cache('slot_name')
```
重設所有槽
```
SELECT * FROM aurora_stat_reset_wal_cache(NULL)
```
## 引數
`NULL` 或 `slot_name`
## 傳回類型
狀態訊息，文字字串
+ 重設邏輯 WAL 快取計數器 – 成功訊息。此文字會在函數成功時傳回。
+ 找不到複寫槽。請再試一次。- 失敗訊息。此文字會在函數未成功時傳回。
## 使用須知
此函數適用於下列版本：
+ Aurora PostgreSQL 14.5 及更高版本
+ Aurora PostgreSQL 13.8 版及更高版本
+ Aurora PostgreSQL 12.12 版和更高版本
+ Aurora PostgreSQL 11.17 版及更高版本
## 範例
下列範例會使用 `aurora_stat_reset_wal_cache` 函數來重設名為 `test_results` 的槽，然後嘗試重設不存在的槽。
```
=> SELECT *
FROM aurora_stat_reset_wal_cache('test_slot');
aurora_stat_reset_wal_cache
--------------------------------------
Reset the logical wal cache counter.
(1 row)
=> SELECT *
FROM aurora_stat_reset_wal_cache('slot-not-exist');
aurora_stat_reset_wal_cache
-----------------------------------------------
Replication slot not found. Please try again.
(1 row)
```
# aurora\$1stat\$1resource\$1usage
報告即時資源使用率，其中包含所有 Aurora PostgreSQL 後端程序的後端資源指標和 cpu 用量。
## 語法
```
aurora_stat_resource_usage()
```
## 引數
無
## 傳回類型
SETOF 記錄與欄：
+ pid：程序識別符
+ allocated\$1memory：依程序分配的記憶體總計 (以位元組為單位)
+ used\$1memory：依程序實際使用的記憶體 (以位元組為單位)
+ cpu\$1usage\$1percent：程序的 CPU 用量百分比
## 使用須知
此函數會顯示每個 Aurora PostgreSQL 後端程序的後端資源用量。
此函數從下列 Aurora PostgreSQL 版本開始適用：
+ Aurora PostgreSQL 17.5 和更新的 17 版本
+ Aurora PostgreSQL 16.9 和更新的 16 版本
+ Aurora PostgreSQL 15.13 和更新的 15 版本
+ Aurora PostgreSQL 14.18 和更新的 14 版本
+ Aurora PostgreSQL 13.21 和更新的 13 版本
## 範例
下列範例示範 `aurora_stat_resource_usage` 函數的輸出。
```
=> select * from aurora_stat_resource_usage();
pid | allocated_memory | used_memory | cpu_usage_percent
------+------------------+-------------+-----------------------
666 | 1074032 | 333544 | 0.00729274882897963
667 | 787312 | 287360 | 0.0029263928146372746
668 | 3076776 | 1563488 | 0.006013116835953961
684 | 803744 | 307480 | 0.002226855426881142
2401 | 1232992 | 943144 | 0
647 | 8000 | 944 | 0.48853387812429855
659 | 319344 | 243000 | 0.0004135602076683591
663 | 262000 | 185736 | 0.008181301476644002
664 | 9024 | 1216 | 0.10992313082653653
(9 rows)
```
# aurora\$1stat\$1statements
顯示所有 `pg_stat_statements` 欄，並在結尾附加更多欄。
## 語法
```
aurora_stat_statements(showtext boolean)
```
## 引數
*showtext 布林值*
## 傳回類型
SETOF 記錄包含所有 `pg_stat_statements` 欄和以下附加欄。如需 `pg_stat_statements` 欄的詳細資訊，請參閱 [https://www.postgresql.org/docs/current/pgstatstatements.html](https://www.postgresql.org/docs/current/pgstatstatements.html)。
您可以使用 `pg_stat_statements_reset()` 重設此函數的統計資料。
+ `storage_blks_read` - 此陳述式從 Aurora 儲存中讀取的共用區塊總數。
+ `orcache_blks_hit` - 此陳述式最佳化讀取快取命中的總數。
+ `storage_blk_read_time`：如果啟用 `track_io_timing`，其會追蹤陳述式從 Aurora 儲存中讀取共用區塊所花費的時間總計 (以毫秒為單位)，否則值為零。如需詳細資訊，請參閱 [track\$1io\$1timing](https://www.postgresql.org/docs/current/runtime-config-statistics.html#GUC-TRACK-IO-TIMING)。
+ `local_blk_read_time`：如果啟用 `track_io_timing`，其會追蹤陳述式讀取本機區塊所花費的時間總計 (以毫秒為單位)，否則值為零。如需詳細資訊，請參閱 [track\$1io\$1timing](https://www.postgresql.org/docs/current/runtime-config-statistics.html#GUC-TRACK-IO-TIMING)。
+ `orcache_blk_read_time`：如果啟用 `track_io_timing`，其會追蹤陳述式從最佳化讀取快取中讀取共用區塊所花費的時間總計 (以毫秒為單位)，否則值為零。如需詳細資訊，請參閱 [track\$1io\$1timing](https://www.postgresql.org/docs/current/runtime-config-statistics.html#GUC-TRACK-IO-TIMING)。
+ `total_plan_peakmem`：此陳述式的所有呼叫在規劃階段期間尖峰記憶體值的總和。若要查看陳述式規劃期間的平均尖峰記憶體，請將此值除以呼叫次數。
+ `min_plan_peakmem`：此陳述式的所有呼叫在規劃期間觀察到的最小尖峰記憶體值。
+ `max_plan_peakmem`：此陳述式的所有呼叫在規劃期間的最大尖峰記憶體值。
+ `total_exec_peakmem`：此陳述式的所有呼叫在執行階段期間的尖峰記憶體值總和。若要查看陳述式執行期間的平均尖峰記憶體，請將此值除以呼叫次數。
+ `min_exec_peakmem`：此陳述式的所有呼叫在執行期間觀察的最小尖峰記憶體值 (以位元組為單位)。
+ `max_exec_peakmem`：此陳述式的所有呼叫在執行期間觀察的最大尖峰記憶體值 (以位元組為單位)。
**注意**
`total_plan_peakmen`、`min_plan_peakmem` 和 `max_plan_peakmem` 只會在 `pg_stat_statements.track_planning` 設定開啟時受到監控。
## 使用須知
若要使用 aurora\$1stat\$1statements() 函數，您必須在 `shared_preload_libraries` 參數中包含 `pg_stat_statements` 延伸模組。
此函數適用於下列 Aurora PostgreSQL 版本：
+ 15.4 版和更新的 15 版本
+ 14.9 版和更新的 14 版本
顯示尖峰記憶體的欄可從下列版本取得：
+ 16.3 及更新版本
+ 15.7 及更新版本
+ 14.12 及更新版本
## 範例
下列範例示範其如何攜帶所有 pg\$1stat\$1statements 欄，並在結尾附加 11 個新欄：
```
=> select * from aurora_stat_statements(true) where query like 'with window_max%';
-[ RECORD 1 ]----------+------------------------------------------------------------------------------------------------
userid | 16409
dbid | 5
toplevel | t
queryid | -8347523682669847482
query | with window_max as (select custid, max(scratch) over (order by scratch rows between $1 preceding
and $2 following) wmax from ts) select sum(wmax), max(custid) from window_max
plans | 0
total_plan_time | 0
min_plan_time | 0
max_plan_time | 0
mean_plan_time | 0
stddev_plan_time | 0
calls | 4
total_exec_time | 254.105121
min_exec_time | 57.503164000000005
max_exec_time | 68.687418
mean_exec_time | 63.52628025
stddev_exec_time | 5.150765359979643
rows | 4
shared_blks_hit | 200192
shared_blks_read | 0
shared_blks_dirtied | 0
shared_blks_written | 0
local_blks_hit | 0
local_blks_read | 0
local_blks_dirtied | 0
local_blks_written | 0
temp_blks_read | 0
temp_blks_written | 0
blk_read_time | 0
blk_write_time | 0
temp_blk_read_time | 0
temp_blk_write_time | 0
wal_records | 0
wal_fpi | 0
wal_bytes | 0
jit_functions | 0
jit_generation_time | 0
jit_inlining_count | 0
jit_inlining_time | 0
jit_optimization_count | 0
jit_optimization_time | 0
jit_emission_count | 0
jit_emission_time | 0
storage_blks_read | 0
orcache_blks_hit | 0
storage_blk_read_time | 0
local_blk_read_time | 0
orcache_blk_read_time | 0
total_plan_peakmem | 0
min_plan_peakmem | 0
max_plan_peakmem | 0
total_exec_peakmem | 6356224
min_exec_peakmem | 1589056
max_exec_peakmem | 1589056
```
# aurora\$1stat\$1system\$1waits
報告 Aurora PostgreSQL 資料庫執行個體的等待事件資訊。
## 語法
```
aurora_stat_system_waits()
```
## 引數
無
## 傳回類型
SETOF 記錄
## 使用須知
此函數會傳回您目前連線的資料庫執行個體所產生之每個等待事件的累積等待次數和累積等待時間。
傳回的記錄集包含下列欄位：
+ `type_id` - 等待事件類型的 ID。
+ `event_id` - 等待事件的 ID。
+ `waits` - 等待事件發生的次數。
+ `wait_time` - 等待此事件所花費的總時間 (以微秒為單位)。
此函數傳回的統計數字會在資料庫執行個體重新啟動時進行重設。
## 範例
下列範例會顯示呼叫 `aurora_stat_system_waits` 函數的結果。
```
=> SELECT *
FROM aurora_stat_system_waits();
type_id | event_id | waits | wait_time
---------+-----------+-----------+--------------
1 | 16777219 | 11 | 12864
1 | 16777220 | 501 | 174473
1 | 16777270 | 53171 | 23641847
1 | 16777271 | 23 | 319668
1 | 16777274 | 60 | 12759
.
.
.
10 | 167772231 | 204596 | 790945212
10 | 167772232 | 2 | 47729
10 | 167772234 | 1 | 888
10 | 167772235 | 2 | 64
```
下列範例顯示如何將此函數與 `aurora_stat_wait_event` 和 `aurora_stat_wait_type` 一起使用，以產生更具可讀性的結果。
```
=> SELECT type_name,
event_name,
waits,
wait_time
FROM aurora_stat_system_waits()
NATURAL JOIN aurora_stat_wait_event()
NATURAL JOIN aurora_stat_wait_type();
type_name | event_name | waits | wait_time
-----------+------------------------+----------+--------------
LWLock | XidGenLock | 11 | 12864
LWLock | ProcArrayLock | 501 | 174473
LWLock | buffer_content | 53171 | 23641847
LWLock | rdsutils | 2 | 12764
Lock | tuple | 75686 | 2033956052
Lock | transactionid | 1765147 | 47267583409
Activity | AutoVacuumMain | 136868 | 56305604538
Activity | BgWriterHibernate | 7486 | 55266949471
Activity | BgWriterMain | 7487 | 1508909964
.
.
.
IO | SLRURead | 3 | 11756
IO | WALWrite | 52544463 | 388850428
IO | XactSync | 187073 | 597041642
IO | ClogRead | 2 | 47729
IO | OutboundCtrlRead | 1 | 888
IO | OutboundCtrlWrite | 2 | 64
```
# aurora\$1stat\$1wait\$1event
列出 Aurora PostgreSQL 的所有支援等待事件。如需 Aurora PostgreSQL 等待事件的相關資訊，請參閱 [Amazon Aurora PostgreSQL 等待事件](AuroraPostgreSQL.Reference.Waitevents.md)。
## 語法
```
aurora_stat_wait_event()
```
## 引數
無
## 傳回類型
SETOF 記錄，包含下列欄：
+ type\$1id - 等待事件類型的 ID。
+ event\$1id - 等待事件的 ID。
+ type\$1name – 等待類型名稱
+ event\$1name – 等待事件名稱
## 使用須知
如要查看具事件類型而非 ID 的事件名稱，請將此函數與其他函數 (例如 `aurora_stat_wait_type` 和 `aurora_stat_system_waits`) 一起搭配使用。此函數所傳回的等待事件名稱與 `aurora_wait_report` 函數傳回的等待事件名稱相同。
## 範例
下列範例會顯示呼叫 `aurora_stat_wait_event` 函數的結果。
```
=> SELECT *
FROM aurora_stat_wait_event();
type_id | event_id | event_name
---------+-----------+-------------------------------------------
1 | 16777216 |
1 | 16777217 | ShmemIndexLock
1 | 16777218 | OidGenLock
1 | 16777219 | XidGenLock
.
.
.
9 | 150994945 | PgSleep
9 | 150994946 | RecoveryApplyDelay
10 | 167772160 | BufFileRead
10 | 167772161 | BufFileWrite
10 | 167772162 | ControlFileRead
.
.
.
10 | 167772226 | WALInitWrite
10 | 167772227 | WALRead
10 | 167772228 | WALSync
10 | 167772229 | WALSyncMethodAssign
10 | 167772230 | WALWrite
10 | 167772231 | XactSync
.
.
.
11 | 184549377 | LsnAllocate
```
下列範例連線 `aurora_stat_wait_type` 和 `aurora_stat_wait_event` 以傳回類型名稱和事件名稱，可提高可讀性。
```
=> SELECT *
FROM aurora_stat_wait_type() t
JOIN aurora_stat_wait_event() e
ON t.type_id = e.type_id;
type_id | type_name | type_id | event_id | event_name
---------+-----------+---------+-----------+-------------------------------------------
1 | LWLock | 1 | 16777216 |
1 | LWLock | 1 | 16777217 | ShmemIndexLock
1 | LWLock | 1 | 16777218 | OidGenLock
1 | LWLock | 1 | 16777219 | XidGenLock
1 | LWLock | 1 | 16777220 | ProcArrayLock
.
.
.
3 | Lock | 3 | 50331648 | relation
3 | Lock | 3 | 50331649 | extend
3 | Lock | 3 | 50331650 | page
3 | Lock | 3 | 50331651 | tuple
.
.
.
10 | IO | 10 | 167772214 | TimelineHistorySync
10 | IO | 10 | 167772215 | TimelineHistoryWrite
10 | IO | 10 | 167772216 | TwophaseFileRead
10 | IO | 10 | 167772217 | TwophaseFileSync
.
.
.
11 | LSN | 11 | 184549376 | LsnDurable
```
# aurora\$1stat\$1wait\$1type
列出 Aurora PostgreSQL 的所有支援等待類型。
## 語法
```
aurora_stat_wait_type()
```
## 引數
無
## 傳回類型
SETOF 記錄，包含下列欄：
+ type\$1id - 等待事件類型的 ID。
+ type\$1name – 等待類型名稱。
## 使用須知
如要查看具等待事件類型而非 ID 的等待事件名稱，請將此函數與其他函數 (例如 `aurora_stat_wait_event` 和 `aurora_stat_system_waits`) 一起搭配使用。此函數所傳回的等待類型名稱與 `aurora_wait_report` 函數傳回的等待類型名稱相同。
## 範例
下列範例會顯示呼叫 `aurora_stat_wait_type` 函數的結果。
```
=> SELECT *
FROM aurora_stat_wait_type();
type_id | type_name
---------+-----------
1 | LWLock
3 | Lock
4 | BufferPin
5 | Activity
6 | Client
7 | Extension
8 | IPC
9 | Timeout
10 | IO
11 | LSN
```
# aurora\$1version
傳回 Amazon Aurora PostgreSQL 相容版本號的字串值。
## 語法
```
aurora_version()
```
## 引數
無
## 傳回類型
CHAR 或 VARCHAR 字串
## 使用須知
此函數顯示 Amazon Aurora PostgreSQL 相容版本資料庫引擎的版本。版本號會以字串傳回，格式為*主要*.*次要*.*修補程式*。如需 Aurora PostgreSQL 版本號的詳細資訊，請參閱 [Aurora 版本編號](AuroraPostgreSQL.Updates.md#AuroraPostgreSQL.Updates.Versions.AuroraNumber)。
您可設定 Aurora PostgreSQL 資料庫叢集的維護時段，來選擇套用次要版本升級的時間。如要瞭解如何作業，請參閱[維持 為 Amazon Aurora 資料庫叢集](USER_UpgradeDBInstance.Maintenance.md)。
從發行 PostgreSQL 版本 13.3、12.8、11.13、10.18 及所有其他更新的版本開始，Aurora 版本編號會接著 PostgreSQL 版本編號。如需有關所有 Aurora PostgreSQL 版本的詳細資訊，請參閱 *Aurora PostgreSQL 版本備註*中的 [Amazon Aurora PostgreSQL 更新](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html)。
## 範例
下列範例顯示在執行 [PostgreSQL 12.7、Aurora PostgreSQL 版本 4.2](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#AuroraPostgreSQL.Updates.20180305.42) 的 Aurora PostgreSQL 資料庫叢集上呼叫 `aurora_version` 函數，然後在執行 [Aurora PostgreSQL 版本 13.3](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#AuroraPostgreSQL.Updates.20180305.133X) 的叢集上執行相同函數的結果。
```
=> SELECT * FROM aurora_version();
aurora_version
----------------
4.2.2
SELECT * FROM aurora_version();
aurora_version
----------------
13.3.0
```
此範例說明如何將函數與各種選項結合使用，以取得有關 Aurora PostgreSQL 版本的更多詳細資料。此範例具有與 PostgreSQL 版本編號不同的 Aurora 版本編號。
```
=> SHOW SERVER_VERSION;
server_version
----------------
12.7
(1 row)
=> SELECT * FROM aurora_version();
aurora_version
----------------
4.2.2
(1 row)
=> SELECT current_setting('server_version') AS "PostgreSQL Compatiblility";
PostgreSQL Compatiblility
---------------------------
12.7
(1 row)
=> SELECT version() AS "PostgreSQL Compatiblility Full String";
PostgreSQL Compatiblility Full String
-------------------------------------------------------------------------------------------------------------
PostgreSQL 12.7 on aarch64-unknown-linux-gnu, compiled by aarch64-unknown-linux-gnu-gcc (GCC) 7.4.0, 64-bit
(1 row)
=> SELECT 'Aurora: '
|| aurora_version()
|| ' Compatible with PostgreSQL: '
|| current_setting('server_version') AS "Instance Version";
Instance Version
------------------------------------------------
Aurora: 4.2.2 Compatible with PostgreSQL: 12.7
(1 row)
```
下一個範例會使用前面範例中具相同選項的函數。此範例並無與 PostgreSQL 版本編號不同的 Aurora 版本編號。
```
=> SHOW SERVER_VERSION;
server_version
----------------
13.3
=> SELECT * FROM aurora_version();
aurora_version
----------------
13.3.0
=> SELECT current_setting('server_version') AS "PostgreSQL Compatiblility";
PostgreSQL Compatiblility
---------------------------
13.3
=> SELECT version() AS "PostgreSQL Compatiblility Full String";
PostgreSQL Compatiblility Full String
-------------------------------------------------------------------------------------------------
PostgreSQL 13.3 on x86_64-pc-linux-gnu, compiled by x86_64-pc-linux-gnu-gcc (GCC) 7.4.0, 64-bit
=> SELECT 'Aurora: '
|| aurora_version()
|| ' Compatible with PostgreSQL: '
|| current_setting('server_version') AS "Instance Version";
Instance Version
-------------------------------------------------------
Aurora: 13.3.0 Compatible with PostgreSQL: 13.3
```
# aurora\$1volume\$1logical\$1start\$1lsn
傳回記錄序號 (LSN)，用於識別 Aurora 叢集磁碟區邏輯預寫日誌 (WAL) 串流中的記錄開頭。
## 語法
```
aurora_volume_logical_start_lsn()
```
## 引數
無
## 傳回類型
`pg_lsn`
## 使用須知
此函數可識別指定 Aurora 叢集磁碟區邏輯 WAL 串流中的記錄開頭。在使用邏輯複寫和 Aurora 快速複製執行主要版本升級時，您可以用此功能判斷擷取快照或資料庫複製的 LSN。然後，對於在 LSN 之後記錄的較新資料，您可以使用邏輯複寫持續進行串流，並將發布者的變更同步至訂閱用戶。
如需使用邏輯複寫進行主要版本升級的詳細資訊，請參閱 [使用邏輯複寫來執行 Aurora PostgreSQL 的主要版本升級](AuroraPostgreSQL.MajorVersionUpgrade.md)。
此函數適用於下列版本的 Aurora PostgreSQL：
+ 15.2 版和更新的 15 版本
+ 14.3 版和更新的 14 版
+ 13.6 版及更新的第 13 版本
+ 12.10 版和更新的第 12 版本
+ 11.15 和更新的第 11 版本
+ 10.20 和更新的第 10 版本
## 範例
您可以使用下列查詢取得日誌序號 (LSN)：
```
postgres=> SELECT aurora_volume_logical_start_lsn();
aurora_volume_logical_start_lsn
---------------
0/402E2F0
(1 row)
```
# aurora\$1wait\$1report
此函數顯示一段時間內的等待事件活動。
## 語法
```
aurora_wait_report([time])
```
## 引數
*時間 (選用)*
時間 (以秒為單位)。預設為 10 秒。
## 傳回類型
SETOF 記錄，包含下列欄：
+ type\$1name – 等待類型名稱
+ event\$1name – 等待事件名稱
+ wait – 等待次數
+ wait\$1time – 等待時間 (以毫秒為單位)
+ ms\$1per\$1wait – 等待次數的平均毫秒數
+ waits\$1per\$1xact – 按一筆交易次數計算的平均等待時間
+ ms\$1per\$1xact – 交易次數的平均毫秒數
## 使用須知
此函數從 Aurora PostgreSQL 1.1 版開始使用，並與 PostgreSQL 9.6.6 和更高版本相容。
如要使用此函數，你需要先建立 Aurora PostgreSQL `aurora_stat_utils` 擴充功能，如下所示：
```
=> CREATE extension aurora_stat_utils;
CREATE EXTENSION
```
如需可用 Aurora PostgreSQL 擴充功能版本的詳細資訊，請參閱 *Aurora PostgreSQL 版本備註*中的 [Amazon Aurora PostgreSQL 的擴充功能版本](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Extensions.html)。
此函數透過比較來自 aurora\$1stat\$1system\$1waits() 函數和 pg\$1stat\$1database PostgreSQL 統計數字檢視中的兩個統計資料快照來計算執行個體層級的等待事件。
如需更多 `aurora_stat_system_waits()` 和 `pg_stat_database` 的相關資訊，請參閱 *PostgreSQL 文件*中的[統計數字收集器](https://www.postgresql.org/docs/current/monitoring-stats.html#PG-STAT-DATABASE-VIEW)。
執行時，此函數會拍攝初始快照，等待指定的秒數，然後拍攝第二個快照。函數比較兩個快照並傳回差異。此差異表示執行個體在該時間間隔內的活動。
在寫入器執行個體上，函數還會顯示已提交的交易和 TPS (每秒交易數) 的數量。此函數傳回執行個體層級的資訊，並包括執行個體上的所有資料庫。
## 範例
此範例說明如何建立 aurora\$1stat\$1utils 延伸模組，以使用 aurora\$1wait\$1report 函數。
```
=> CREATE extension aurora_stat_utils;
CREATE EXTENSION
```
此範例說明如何檢查等待報告 10 秒。
```
=> SELECT *
FROM aurora_wait_report();
NOTICE: committed 34 transactions in 10 seconds (tps 3)
type_name | event_name | waits | wait_time | ms_per_wait | waits_per_xact | ms_per_xact
-----------+-------------------+-------+-----------+-------------+----------------+-------------
Client | ClientRead | 26 | 30003.00 | 1153.961 | 0.76 | 882.441
Activity | WalWriterMain | 50 | 10051.32 | 201.026 | 1.47 | 295.627
Timeout | PgSleep | 1 | 10049.52 | 10049.516 | 0.03 | 295.574
Activity | BgWriterHibernate | 1 | 10048.15 | 10048.153 | 0.03 | 295.534
Activity | AutoVacuumMain | 18 | 9941.66 | 552.314 | 0.53 | 292.402
Activity | BgWriterMain | 1 | 201.09 | 201.085 | 0.03 | 5.914
IO | XactSync | 15 | 25.34 | 1.690 | 0.44 | 0.745
IO | RelationMapRead | 12 | 0.54 | 0.045 | 0.35 | 0.016
IO | WALWrite | 84 | 0.21 | 0.002 | 2.47 | 0.006
IO | DataFileExtend | 1 | 0.02 | 0.018 | 0.03 | 0.001
```
此範例說明如何檢查等待報告 60 秒。
```
=> SELECT *
FROM aurora_wait_report(60);
NOTICE: committed 1544 transactions in 60 seconds (tps 25)
type_name | event_name | waits | wait_time | ms_per_wait | waits_per_xact | ms_per_xact
-----------+------------------------+---------+-----------+-------------+----------------+-------------
Lock | transactionid | 6422 | 477000.53 | 74.276 | 4.16 | 308.938
Client | ClientRead | 8265 | 270752.99 | 32.759 | 5.35 | 175.358
Activity | CheckpointerMain | 1 | 60100.25 | 60100.246 | 0.00 | 38.925
Timeout | PgSleep | 1 | 60098.49 | 60098.493 | 0.00 | 38.924
Activity | WalWriterMain | 296 | 60010.99 | 202.740 | 0.19 | 38.867
Activity | AutoVacuumMain | 107 | 59827.84 | 559.139 | 0.07 | 38.749
Activity | BgWriterMain | 290 | 58821.83 | 202.834 | 0.19 | 38.097
IO | XactSync | 1295 | 55220.13 | 42.641 | 0.84 | 35.764
IO | WALWrite | 6602259 | 47810.94 | 0.007 | 4276.07 | 30.966
Lock | tuple | 473 | 29880.67 | 63.173 | 0.31 | 19.353
LWLock | buffer_mapping | 142 | 3540.13 | 24.930 | 0.09 | 2.293
Activity | BgWriterHibernate | 290 | 1124.15 | 3.876 | 0.19 | 0.728
IO | BufFileRead | 7615 | 618.45 | 0.081 | 4.93 | 0.401
LWLock | buffer_content | 73 | 345.93 | 4.739 | 0.05 | 0.224
LWLock | lock_manager | 62 | 191.44 | 3.088 | 0.04 | 0.124
IO | RelationMapRead | 72 | 5.16 | 0.072 | 0.05 | 0.003
LWLock | ProcArrayLock | 1 | 2.01 | 2.008 | 0.00 | 0.001
IO | ControlFileWriteUpdate | 2 | 0.03 | 0.013 | 0.00 | 0.000
IO | DataFileExtend | 1 | 0.02 | 0.018 | 0.00 | 0.000
IO | ControlFileSyncUpdate | 1 | 0.00 | 0.000 | 0.00 | 0.000
```