# Aurora PostgreSQL 函数参考
下面，您可以找到适用于运行 Aurora PostgreSQL 兼容版数据库引擎的 Aurora 数据库集群的 Aurora PostgreSQL 函数的列表。这些 Aurora PostgreSQL 函数是标准 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\$1wait](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 兼容版集群的数据库实例名称。
此函数从 Aurora 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 数据库集群上的写入数据库实例。
为 Aurora PostgreSQL 数据库集群启用 CCM，方法是在集群的自定义数据库集群参数组中，将 `apg_ccm_enabled` 设置为 1。要了解如何操作，请参阅[配置集群缓存管理](AuroraPostgreSQL.cluster-cache-mgmt.md#AuroraPostgreSQL.cluster-cache-mgmt.Configure)。
当集群具有如下配置的 Aurora 读取器实例时，集群缓存管理在 Aurora PostgreSQL 数据库集群上处于活动状态：
+ Aurora 读取器实例使用与集群的写入器实例相同的数据库实例类类型和大小。
+ Aurora 读取器实例配置为集群的 Tier-0。如果集群有多个读取器，则这是唯一的 Tier-0 读取器。
将多个读取器设置为 Tier-0 将会禁用 CCM。CCM 禁用时，调用此函数将返回以下错误消息：
```
ERROR: Cluster Cache Manager is disabled
```
您也可以使用 PostgreSQL pg\$1buffercache 扩展来分析缓冲区缓存。有关更多信息，请参阅 PostgreSQL 文档中的 [pg\$1buffercache](https://www.postgresql.org/docs/current/pgbuffercache.html)。
有关更多信息，请参阅 [Aurora PostgreSQL 集群缓存管理简介](https://aws.amazon.com/blogs/database/introduction-to-aurora-postgresql-cluster-cache-management/)。
## 示例
以下示例显示了调用 `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` – 数据库实例在生成热备用信息时使用的纪元。*热备用服务器*是在主数据库处于恢复或备用模式时支持连接和查询的数据库实例。热备用服务器信息包括纪元（时间点）和有关用作热备用服务器的数据库实例的其他详细信息。有关更多信息，请参阅 PostgreSQL 文档中的[热备用](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 Global Database 概览](aurora-global-database.md#aurora-global-database-overview)。
要开始使用 Aurora 全局数据库，请参阅 [开始使用 Amazon Aurora Global Database](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 滞后是最近的用户事务在存储在 Aurora 全局数据库的主数据库集群上之后，执行 COMMIT 操作以便存储在辅助数据库集群上所需的时间。值为 -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` – 辅助数据库集群在生成热备用信息时使用的纪元。*热备用服务器*是在主数据库处于恢复或备用模式时支持连接和查询的数据库实例。热备用服务器信息包括纪元（时间点）和有关用作热备用服务器的数据库实例的其他详细信息。有关更多信息，请参阅 PostgreSQL 文档中的[热备用](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 Global Database 概览](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` – 数据库实例在生成热备用信息时使用的纪元。
+ `replica_lag_in_msec` – 读取器实例滞后于写入器实例的时间（以毫秒为单位）。
+ `log_stream_speed_in_kib_per_second` – 日志流吞吐量（以每秒千字节为单位）。
+ `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` – 包含创建实例时指定的实例名称。在某些情况下，例如对于主（写入器）实例，通常会通过在为 Aurora PostgreSQL 数据库集群创建的名称后面附加 *-instance-1* 来为您创建名称。
+ `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` 指标。有关将 CloudWatch 指标用于 Aurora 的信息，请参阅[使用 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\$1wait
显示特定后端进程等待活动的统计数据。
## 语法
```
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
```
此示例显示了所有活动会话的当前和前三（3）个累积等待类型和等待事件（`pg_stat_activity state <> 'idle'`），不包括当前会话（`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` 是一个统计视图，显示有关优化型读取缓存写入的信息。
## 语法
```
aurora_stat_bgwriter()
```
## 参数
无
## 返回类型
包含所有 `pg_stat_bgwriter` 列和以下附加列的 SETOF 记录。有关 `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()
```
## 参数
无
## 返回类型
包含所有 `pg_stat_database` 列和以下附加列的 SETOF 记录。有关 `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` 函数仅适用于 Aurora PostgreSQL 版本 3.1，与 PostgreSQL 引擎 11.6 及更高版本兼容。
在具有大量数据库的 Aurora PostgreSQL 集群上使用此函数，以确定哪些数据库具有更多或更慢的 DML 活动，或两者兼有。
`aurora_stat_dml_activity` 函数返回运行操作的次数以及选择、插入、更新和删除操作的累积延迟（以微秒为单位）。该报告仅包括成功的 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
重置逻辑 wal 缓存的计数器。
## 语法
重置特定插槽
```
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 boolean*
## 返回类型
包含所有 `pg_stat_statements` 列和以下附加列的 SETOF 记录。有关 `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` – 在对此语句的所有调用的执行期间，出现的最大峰值内存值，以字节为单位。
**注意**
仅当设置 `pg_stat_statements.track_planning` 为开启时，`total_plan_peakmen`、`min_plan_peakmem` 和 `max_plan_peakmem` 才会受到监控。
## 使用说明
要使用 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 兼容版数据库引擎的版本。版本号以字符串形式返回，格式为 *major*.*minor*.*patch*。有关 Aurora PostgreSQL 版本号的更多信息，请参阅[Aurora 版本号](AuroraPostgreSQL.Updates.md#AuroraPostgreSQL.Updates.Versions.AuroraNumber)。
您可以通过设置 Aurora PostgreSQL 数据库集群的维护时段来选择何时应用次要版本升级。要了解如何操作，请参阅[维护Amazon Aurora 数据库集群](USER_UpgradeDBInstance.Maintenance.md)。
从发布的 Aurora 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\$1time – 以毫秒为单位的等待时间
+ ms\$1per\$1wait – 按等待次数计算的平均毫秒数
+ waits\$1per\$1xact – 按一个事务数计算的平均等待次数
+ ms\$1per\$1xact – 按事务数计算的平均毫秒数
## 使用说明
此函数从与 PostgreSQL 9.6.6 及更高版本兼容的 Aurora PostgreSQL 版本 1.1 开始提供。
要使用此函数，您首先需要创建 Aurora PostgreSQL `aurora_stat_utils` 扩展，如下所示：
```
=> CREATE extension aurora_stat_utils;
CREATE EXTENSION
```
有关可用的 urora 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
```