Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
# Aurora-PostgreSQL-Funktionsreferenz
Nachfolgend finden Sie eine Liste der Aurora PostgreSQL-Funktionen, die für Ihre Aurora-DB-Cluster verfügbar sind, welche die Aurora PostgreSQL-kompatible Edition-DB-Engine ausführen. Diese Aurora PostgreSQL-Funktionen sind zusätzlich zu den Standard-PostgreSQL-Funktionen. Weitere Informationen zu PostgreSQL-Standardfunktionen finden Sie unter [PostgreSQL – Funktionen und Operatoren](https://www.postgresql.org/docs/current/functions.html).
## -Übersicht
Sie können die folgenden Funktionen für Amazon-RDS-DB-Instances verwenden, auf denen Aurora PostgreSQL ausgeführt wird:
+ [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
Meldet den Namen der DB-Instance, mit der Sie verbunden sind.
## Syntax
```
aurora_db_instance_identifier()
```
## Argumente
Keine
## Rückgabetyp
VARCHAR-Zeichenfolge
## Nutzungshinweise
Diese Funktion zeigt den Namen der DB-Instance des Aurora-PostgreSQL-kompatiblen Edition-Clusters für Ihre Datenbank-Client- oder Anwendungsverbindung an.
Diese Funktion ist ab der Veröffentlichung der PostgreSQL-Versionen 13.7, 12.11, 11.16 und 10.21 und für alle späteren Versionen verfügbar.
## Beispiele
Im folgenden Beispiel sehen Sie die Ergebnisse vom Aufruf der Funktion `aurora_db_instance_identifier`.
```
=> SELECT aurora_db_instance_identifier();
aurora_db_instance_identifier
-------------------------------
test-my-instance-name
```
Sie können die Ergebnisse dieser Funktion mit der `aurora_replica_status`-Funktion verbinden, um Details über die DB-Instance für Ihre Verbindung abzurufen. Die [aurora\$1replica\$1status](aurora_replica_status.md) allein zeigt Ihnen nicht, welche DB-Instance Sie verwenden. Im folgenden Beispiel wird gezeigt, wie Sie dies tun.
```
=> 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
Zeigt den Status des Cluster-Cache-Managers an.
## Syntax
```
aurora_ccm_status()
```
## Argumente
Keine.
## Rückgabetyp
SETOF-Datensatz mit den folgenden Spalten:
+ `buffers_sent_last_minute` – Die Anzahl der Puffer, die in der letzten Minute an den designierten Reader gesendet wurden.
+ `buffers_found_last_minute` – Die Anzahl der Puffer, auf die in der letzten Minute häufig zugegriffen wurde.
+ `buffers_sent_last_scan` – Die Anzahl der Puffer, die während des letzten vollständigen Scanvorgangs des Puffercaches an den designierten Reader gesendet wurden.
+ `buffers_found_last_scan` – Die Anzahl der Puffer, auf die während des letzten vollständigen Scanvorgangs des Puffercaches häufig zugegriffen wurde. Puffer, die bereits im Cache des designierten Readers abgelegt wurden, werden nicht gesendet.
+ `buffers_sent_current_scan` – Die Anzahl der Puffer, die während des aktuellen Scanvorgangs gesendet wurden.
+ `buffers_found_current_scan` – Die Anzahl der häufig aufgerufenen Puffer, die im aktuellen Scan identifiziert wurden.
+ `current_scan_progress` – Die Anzahl der Puffer, die während des aktuellen Scanvorgangs aufgerufen wurden.
## Nutzungshinweise
Sie können diese Funktion verwenden, um die Funktion zur Cluster-Cache-Verwaltung (CCM) zu überprüfen und zu überwachen. Diese Funktion ist nur verfügbar, wenn CCM auf Ihrem Aurora-PostgreSQL-DB-Cluster aktiv ist. Zum Verwenden dieser Funktion stellen Sie eine Verbindung mit der Write-DB-Instance Ihres Aurora-PostgreSQL-DB-Clusters her.
Sie aktivieren CCM für einen Aurora-PostgreSQL-DB-Cluster, indem Sie den Wert `apg_ccm_enabled` in der benutzerdefinierten DB-Cluster-Parametergruppe des Clusters auf 1 festlegen. Um zu erfahren wie dies geht, vgl. [Konfigurieren der Cluster-Cache-Verwaltung](AuroraPostgreSQL.cluster-cache-mgmt.md#AuroraPostgreSQL.cluster-cache-mgmt.Configure).
Die Cluster-Cache-Verwaltung ist auf einem Aurora-PostgreSQL-DB-Cluster aktiv, wenn der Cluster über eine Aurora-Reader-Instance verfügt, die wie folgt konfiguriert ist:
+ Die Aurora-Reader-Instance verwendet den gleichen Typ und die gleiche Größe der DB-Instance-Klasse wie die Writer-Instance des Clusters.
+ Die Aurora-Reader-Instance ist für den Cluster als Tier-0 konfiguriert. Wenn der Cluster über mehr als einen Reader verfügt, ist dies der einzige Tier-0-Reader.
Wenn Sie mehr als einen Reader auf Tier-0 einstellen, wird CCM deaktiviert. Wenn CCM deaktiviert ist, wird beim Aufruf dieser Funktion die folgende Fehlermeldung zurückgegeben:
```
ERROR: Cluster Cache Manager is disabled
```
Sie können auch die PostgreSQL-Erweiterung pg\$1buffercache verwenden, um den Puffercache zu analysieren. Weitere Informationen finden Sie unter [pg\$1buffercache](https://www.postgresql.org/docs/current/pgbuffercache.html) in der PostgreSQL-Dokumentation.
Weitere Informationen finden Sie unter [Einführung in die Aurora-PostgreSQL-Cluster-Cache-Verwaltung](https://aws.amazon.com/blogs/database/introduction-to-aurora-postgresql-cluster-cache-management/).
## Beispiele
Im folgenden Beispiel sehen Sie die Ergebnisse vom Aufruf der Funktion `aurora_ccm_status`. Dieses erste Beispiel zeigt CCM-Statistiken.
```
=> 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
```
Für ausführlichere Details können Sie die erweiterte Anzeige verwenden, wie im Folgenden gezeigt:
```
\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
```
Dieses Beispiel zeigt, wie die aktive Rate und der aktive Prozentsatz überprüft werden.
```
=> 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
Zeigt den Status aller Aurora-Instances an, einschließlich Replikaten in einem globalen Aurora-DB-Cluster.
## Syntax
```
aurora_global_db_instance_status()
```
## Argumente
Keine
## Rückgabetyp
SETOF-Datensatz mit den folgenden Spalten:
+ `server_id` – Die ID der DB-Instance.
+ `session_id` – Eindeutiger Bezeichner für die aktuelle Sitzung. Der Wert `MASTER_SESSION_ID` bezeichnet die (primäre) Writer-DB-Instance.
+ `aws_region` – Die AWS-Region, in der diese globale DB-Instance ausgeführt wird. Eine Liste der Regionen finden Sie unter [Verfügbarkeit in Regionen](Concepts.RegionsAndAvailabilityZones.md#Aurora.Overview.Availability).
+ `durable_lsn` – Die Log-Sequenznummer (LSN), die dauerhaft gespeichert wurde. Eine Log-Sequenznummer (LSN) ist eine eindeutige fortlaufende Nummer, die einen Datensatz im Datenbank-Transaktionsprotokoll identifiziert. LSNs werden so angeordnet, dass eine größere LSN eine spätere Transaktion darstellt.
+ `highest_lsn_rcvd` – Die höchste LSN, die die DB-Instance von der Writer-DB-Instance empfangen hat.
+ `feedback_epoch` – Die Epoche, die die DB-Instance beim Erzeugen der Hot-Standby-Informationen verwendet. Ein *Hot Standby* ist eine DB-Instance, die Verbindungen und Abfragen unterstützt, während sich die primäre DB im Wiederherstellungs- oder Standby-Modus befindet. Die Hot-Standby-Informationen umfassen die Epoche (bestimmter Zeitpunkt) und andere Details über die DB-Instance, die als Hot-Standby verwendet wird. Weitere Informationen finden Sie in der PostgreSQL-Dokumentation zu [Hot Standby](https://www.postgresql.org/docs/current/hot-standby.html).
+ `feedback_xmin` – Die minimale (älteste) aktive Transaktions-ID, die von der DB-Instance verwendet wird.
+ `oldest_read_view_lsn` – Die älteste LSN, die von der DB-Instance zum Lesen aus dem Speicher verwendet wird.
+ `visibility_lag_in_msec` – Gibt an (in Millisekunden), wie weit die DB-Instance hinter der Writer-DB-Instance zurückgeblieben ist.
## Nutzungshinweise
Diese Funktion gibt Aufschluss über Replikationsstatistiken für einen Aurora-DB-Cluster. Für jede Aurora-PostgreSQL-DB-Instance im Cluster zeigt die Funktion eine Datenreihe an, die regionsübergreifende Replikate in einer globalen Datenbankkonfiguration enthält.
Sie können diese Funktion von jeder Instance in einem Aurora-PostgreSQL-DB-Cluster oder einer globalen Aurora-PostgreSQL-Datenbank ausführen. Die Funktion gibt Details zur Verzögerung für alle Replikat-Instances zurück.
Weitere Informationen über die Überwachung der Verzögerung mithilfe dieser Funktion (`aurora_global_db_instance_status`) oder mit `aurora_global_db_status` finden Sie unter [Überwachen von Aurora-PostgreSQL-basierten globalen Datenbanken](aurora-global-database-monitoring.md#aurora-global-database-monitoring.postgres).
Informationen über globale Aurora-Datenbanken finden Sie unter [Übersicht über Amazon Aurora Global Database](aurora-global-database.md#aurora-global-database-overview).
Informationen zu den ersten Schritten mit globalen Aurora-Datenbanken finden Sie unter [Erste Schritte mit Amazon Aurora Global Database](aurora-global-database-getting-started.md) oder [Häufig gestellte Fragen zu Amazon Aurora](https://aws.amazon.com/rds/aurora/faqs/).
## Beispiele
Dieses Beispiel zeigt regionsübergreifende Instance-Statistiken.
```
=> 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
```
Dieses Beispiel veranschaulicht, wie die globale Replikatverzögerung in Millisekunden überprüft wird.
```
=> 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
```
Dieses Beispiel zeigt, wie die minimale, maximale und durchschnittliche Verzögerung je AWS-Region im Hinblick auf die globale Datenbankkonfiguration überprüft wird.
```
=> 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
Zeigt Informationen über verschiedene Aspekte der globalen Aurora-Datenbankverzögerung an, insbesondere die Verzögerung des zugrunde liegenden Aurora-Speichers (sogenannte Haltbarkeitsverzögerung) und die Verzögerung zwischen dem Recovery Point Objective (RPO).
## Syntax
```
aurora_global_db_status()
```
## Argumente
Keine.
## Rückgabetyp
SETOF-Datensatz mit den folgenden Spalten:
+ `aws_region` – Die AWS-Region, in der sich dieser DB-Cluster befindet. Eine vollständige Auflistung von AWS-Regionen nach Engine finden Sie unter [ Regionen und Availability Zones](Concepts.RegionsAndAvailabilityZones.md).
+ `highest_lsn_written` – Die höchste Log-Sequenznummer (LSN), die derzeit auf diesem DB-Cluster vorhanden ist. Eine Log-Sequenznummer (LSN) ist eine eindeutige fortlaufende Nummer, die einen Datensatz im Datenbank-Transaktionsprotokoll identifiziert. LSNs werden so angeordnet, dass eine größere LSN eine spätere Transaktion darstellt.
+ `durability_lag_in_msec` – Die Differenz zwischen den Zeitstempelwerten der `highest_lsn_written` auf einem sekundären DB-Cluster und der `highest_lsn_written` auf dem primären DB-Cluster. Der Wert -1 identifiziert den primären DB-Cluster der globalen Aurora-Datenbank.
+ `rpo_lag_in_msec` – Die RPO-Verzögerung (Recovery Point Objective). Die RPO-Verzögerung ist die Zeit, die benötigt wird, bis die letzte Benutzertransaktion COMMIT auf einem sekundären DB-Cluster gespeichert wird, nachdem sie auf dem primären DB-Cluster einer globalen Aurora-Datenbank abgelegt wurde. Der Wert -1 bezeichnet den primären DB-Cluster (die Verzögerung ist daher nicht relevant).
Einfach ausgedrückt berechnet diese Metrik das Recovery Point Objective für jeden Aurora-PostgreSQL-DB-Cluster in der globalen Aurora-Datenbank, d. h., wie viele Daten bei einem Ausfall verloren gehen könnten. Wie die Verzögerung wird auch RPO zeitlich gemessen.
+ `last_lag_calculation_time` – Der Zeitstempel, der angibt, wann die Werte für `durability_lag_in_msec` und `rpo_lag_in_msec` zuletzt berechnet wurden. Ein Zeitwert wie `1970-01-01 00:00:00+00` bedeutet, dass dies der primäre DB-Cluster ist.
+ `feedback_epoch` – Die Epoche, die der sekundäre DB-Cluster beim Erzeugen von Hot-Standby-Informationen verwendet. Ein *Hot Standby* ist eine DB-Instance, die Verbindungen und Abfragen unterstützt, während sich die primäre DB im Wiederherstellungs- oder Standby-Modus befindet. Die Hot-Standby-Informationen umfassen die Epoche (bestimmter Zeitpunkt) und andere Details über die DB-Instance, die als Hot-Standby verwendet wird. Weitere Informationen finden Sie in der PostgreSQL-Dokumentation zu [Hot Standby](https://www.postgresql.org/docs/current/hot-standby.html).
+ `feedback_xmin` – Die minimale (älteste) aktive Transaktions-ID, die von einem sekundären DB-Cluster verwendet wird.
## Nutzungshinweise
Alle derzeit verfügbaren Aurora-PostgreSQL-Versionen unterstützen diese Funktion. Diese Funktion zeigt Replikationsstatistiken für eine globale Aurora-Datenbank. Sie zeigt eine Zeile für jeden DB-Cluster in einer globalen Aurora-PostgreSQL-Datenbank. Sie können diese Funktion von jeder Instance in Ihrer globalen Aurora-PostgreSQL-Datenbank ausführen.
Informationen zur Auswertung der Replikationsverzögerung der globalen Aurora-Datenbank, die die sichtbare Datenverzögerung darstellt, finden Sie unter [aurora\$1global\$1db\$1instance\$1status](aurora_global_db_instance_status.md).
Weitere Informationen über die Verwendung von `aurora_global_db_status` und `aurora_global_db_instance_status` zur Überwachung der globalen Aurora-Datenbankverzögerung finden Sie unter [Überwachen von Aurora-PostgreSQL-basierten globalen Datenbanken](aurora-global-database-monitoring.md#aurora-global-database-monitoring.postgres). Informationen über globale Aurora-Datenbanken finden Sie unter [Übersicht über Amazon Aurora Global Database](aurora-global-database.md#aurora-global-database-overview).
## Beispiele
Dieses Beispiel zeigt, wie regionsübergreifende Speicherstatistiken angezeigt werden.
```
=> 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
Listet alle verfügbaren integrierten Aurora-PostgreSQL-Funktionen mit kurzen Beschreibungen und Funktionsdetails auf.
## Syntax
```
aurora_list_builtins()
```
## Argumente
Keine
## Rückgabetyp
SETOF-Datensatz
## Beispiele
Im folgenden Beispiel sehen Sie Ergebnisse vom Aufruf der Funktion `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
Zeigt den Status aller Aurora-PostgreSQL-Reader-Knoten an.
## Syntax
```
aurora_replica_status()
```
## Argumente
Keine
## Rückgabetyp
SETOF-Datensatz mit den folgenden Spalten:
+ `server_id` – Die DB-Instance-ID (Kennung).
+ `session_id` – Eine eindeutige ID für die aktuelle Sitzung, die wie folgt für die primäre Instance und Reader-Instances zurückgegeben wird:
+ Für die primäre Instance ist `session_id` immer ``MASTER_SESSION_ID’`.
+ Für Reader-Instances ist `session_id` immer die `UUID` (Universally Unique Identifier, eindeutige Kennung) der Reader-Instance.
+ `durable_lsn` – Die Log-Sequenznummer (LSN), die im Speicher abgelegt wurde.
+ Für das primäre Volume die dauerhafte LSN des primären Volumes (VDL), die derzeit in Kraft ist.
+ Für alle sekundären Volumes die VDL des primären Volumes, auf das das sekundäre Volume erfolgreich angewendet wurde.
**Anmerkung**
Eine Log-Sequenznummer (LSN) ist eine eindeutige fortlaufende Nummer, die einen Datensatz im Datenbank-Transaktionsprotokoll identifiziert. LSNs werden so angeordnet, dass eine größere LSN eine Transaktion darstellt, die später in der Sequenz auftritt.
+ `highest_lsn_rcvd` – Die höchste (neueste) LSN, die die DB-Instance von der Writer-DB-Instance empfangen hat.
+ `current_read_lsn` – Die LSN des letzten Snapshots, die auf alle Reader angewendet wurde.
+ `cur_replay_latency_in_usec` – Die Anzahl der Mikrosekunden, die voraussichtlich benötigt werden, um das Protokoll auf der sekundären Instance wiederzugeben.
+ `active_txns` – Die Anzahl der derzeit aktiven Transaktionen.
+ `is_current` – Nicht verwendet.
+ `last_transport_error` – Fehlercode für die letzte Replikation.
+ `last_error_timestamp` – Zeitstempel des letzten Replikationsfehlers.
+ `last_update_timestamp` – Zeitstempel der letzten Aktualisierung auf den Replikatstatus. Ab Aurora PostgreSQL 13.9 ist der `last_update_timestamp`-Wert für die DB-Instance, mit der Sie verbunden sind, auf `NULL` festgelegt.
+ `feedback_xmin` – Der Hot Standby feedback\$1xmin des Replikats. Die minimale (älteste) aktive Transaktions-ID, die von der DB-Instance verwendet wird.
+ `feedback_epoch` – Die Epoche, die die DB-Instance beim Erzeugen der Hot-Standby-Informationen verwendet.
+ `replica_lag_in_msec` – Zeit, die die Leser-Instance in Millisekunden hinter der Schreiber-Instance zurückbleibt
+ `log_stream_speed_in_kib_per_second` – Der Durchsatz des Protokollstreams in Kilobyte pro Sekunde.
+ `log_buffer_sequence_number` – Die Sequenznummer des Protokollpuffers.
+ `oldest_read_view_trx_id` – Nicht verwendet.
+ `oldest_read_view_lsn` – Die älteste LSN, die von der DB-Instance zum Lesen aus dem Speicher verwendet wird.
+ `pending_read_ios` – Die ausstehenden Seiten-Lesevorgänge, die noch im Replikat anstehen.
+ `read_ios` – Die Gesamtzahl der Lesevorgänge auf dem Replikat.
+ `iops` – Nicht verwendet.
+ `cpu` – CPU-Auslastung des Aurora-Speicher-Daemon für jeden Knoten im Cluster. Weitere Informationen zur CPU-Auslastung durch die Instance finden Sie unter [Metriken auf Instance-Ebene für Amazon Aurora](Aurora.AuroraMonitoring.Metrics.md#Aurora.AuroraMySQL.Monitoring.Metrics.instances).
## Nutzungshinweise
Alle derzeit verfügbaren Aurora-PostgreSQL-Versionen unterstützen diese Funktion. Die Funktion `aurora_replica_status` gibt Werte aus dem Replikatstatus-Manager eines Aurora-PostgreSQL-DB-Clusters zurück. Sie können diese Funktion verwenden, um Informationen über den Status der Replikation auf Ihrem Aurora-PostgreSQL-DB-Cluster zu erhalten, einschließlich Metriken für alle DB-Instances in Ihrem Aurora-DB-Cluster. Sie können z. B. Folgendes tun:
+ **Informationen über die Art der Instance (Writer, Reader) im Aurora-PostgreSQL-DB-Cluster abrufen** – Diese Informationen erhalten Sie, indem Sie sich die Werte der folgenden Spalten ansehen:
+ `server_id` – Enthält den Namen der Instance, die Sie beim Erstellen der Instance festgelegt haben. In einigen Fällen, z. B. für die primäre (Writer-)Instance, wird der Name normalerweise durch Anhängen von *-instance-1* an den Namen, den Sie für Ihren Aurora-PostgreSQL-DB-Cluster festlegen, für Sie erstellt.
+ `session_id` – Das Feld `session_id` gibt an, ob es sich bei der Instance um einen Reader oder einen Writer handelt. Für eine Writer-Instance ist `session_id` immer auf `"MASTER_SESSION_ID"` festgelegt. Für eine Reader-Instance ist `session_id` auf die `UUID` des spezifischen Readers festgelegt.
+ **Häufige Replikationsprobleme wie Replikatverzögerung, diagnostizieren** – Replikatverzögerung ist die Zeit in Millisekunden, die der Seiten-Cache einer Reader-Instance hinter dem Cache der Writer-Instance zurückbleibt. Diese Verzögerung tritt auf, weil Aurora-Cluster eine asynchrone Replikation verwenden, wie unter [Replikation mit Amazon Aurora](Aurora.Replication.md)beschrieben. Diese ist in der Spalte `replica_lag_in_msec` in den von dieser Funktion zurückgegebenen Ergebnissen zu sehen. Verzögerungen können auch auftreten, wenn eine Abfrage aufgrund von Konflikten mit der Wiederherstellung auf einem Standby-Server abgebrochen wird. Unter `pg_stat_database_conflicts()` können Sie nachsehen, ob ein solcher Konflikt die Replikatverzögerung verursacht (oder nicht). Weitere Informationen finden Sie unter [Die Statistikerfassung](https://www.postgresql.org/docs/current/monitoring-stats.html#MONITORING-PG-STAT-DATABASE-CONFLICTS-VIEW) in der *PostgreSQL-Dokumentation*. Weitere Informationen zu Hochverfügbarkeit und Replikation finden Sie unter [Häufig gestellte Fragen zu Amazon Aurora](https://aws.amazon.com/rds/aurora/faqs/#High_Availability_and_Replication).
Amazon CloudWatch speichert `replica_lag_in_msec`-Ergebnisse im Laufe der Zeit als `AuroraReplicaLag`-Metrik. Weitere Informationen zur Verwendung der CloudWatch-Metriken für Aurora finden Sie unter [Überwachung von Amazon Aurora Aurora-Metriken mit Amazon CloudWatch](monitoring-cloudwatch.md).
Weitere Informationen zur Fehlerbehebung bei Aurora-Lesereplikaten und Neustarts finden Sie unter [Warum ist mein Amazon-Aurora-Lesereplikat in den Rückstand geraten und wurde neu gestartet?](https://aws.amazon.com/premiumsupport/knowledge-center/aurora-read-replica-restart/) im [AWS Support Center](https://console.aws.amazon.com/support/home#/).
## Beispiele
Im folgenden Beispiel wird veranschaulicht, wie Sie den Replikationsstatus aller Instances in einem Aurora-PostgreSQL-DB-Cluster abrufen:
```
=> SELECT *
FROM aurora_replica_status();
```
Das folgende Beispiel zeigt die Writer-Instance im Aurora-PostgreSQL-DB-Cluster `docs-lab-apg-main`:
```
=> 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
```
Im folgenden Beispiel werden alle Reader-Instances in einem Cluster aufgeführt:
```
=> 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)
```
Im folgenden Beispiel werden alle Instances aufgeführt und es wird angegeben, wie weit jede Instance hinter dem Writer zurückbleibt und wie lange seit dem letzten Update:
```
=> 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
Gibt eine Zeile pro Serverprozess zurück, in der Informationen zur aktuellen Aktivität dieses Prozesses angezeigt werden
## Syntax
```
aurora_stat_activity();
```
## Argumente
Keine
## Rückgabetyp
Gibt eine Zeile pro Serverprozess zurück. Zusätzlich zu den `pg_stat_activity`-Spalten wird das folgende Feld hinzugefügt:
+ planid – Plan-ID
## Nutzungshinweise
Eine zusätzliche Ansicht zu `pg_stat_activity` mit denselben Spalten sowie einer zusätzlichen `plan_id`-Spalte, die den aktuellen Abfrageausführungsplan darstellt
`aurora_compute_plan_id` muss aktiviert sein, damit die Ansicht eine plan\$1id zurückgibt.
Diese Funktion ist in den Aurora-PostgreSQL-Versionen 14.10, 15.5 und für alle späteren Versionen verfügbar.
## Beispiele
Die folgende Beispielabfrage aggregiert die Hauptlast nach query\$1id und 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)
```
Wenn sich der für query\$1id verwendete Plan ändert, wird von aurora\$1stat\$1activity eine neue plan\$1id gemeldet.
```
count | query_id | plan_id
-------+----------------------+-------------
10 | -5471422286312252535 | 1602979607
1 | -6907107586630739258 | -1809935983
1 | -2446282393000597155 | -207532066
(3 rows)
```
# aurora\$1stat\$1backend\$1waits
Zeigt Statistiken für die Warteaktivität für einen bestimmten Backend-Prozess an.
## Syntax
```
aurora_stat_backend_waits(pid)
```
## Argumente
`pid` – Die ID für den Backend-Prozess. Sie können Prozess-IDs in der Ansicht `pg_stat_activity` abrufen.
## Rückgabetyp
SETOF-Datensatz mit den folgenden Spalten:
+ `type_id` – Eine Zahl, die die Art des Warteereignisses angibt, wie `1` für eine einfache Sperre (`LWLock`), `3` für eine Sperre oder `6` für eine Clientsitzung, um nur einige Beispiele zu nennen. Diese Werte werden aussagekräftig, wenn Sie die Ergebnisse dieser Funktion mit Spalten der Funktion `aurora_stat_wait_type` verbinden, wie in [Beispiele](#aurora_stat_backend_waits-examples) gezeigt.
+ `event_id` – Eine ID-Nummer für das Warteereignis. Verbinden Sie diesen Wert mit den Spalten von `aurora_stat_wait_event`, um aussagekräftige Ereignisnamen zu erhalten.
+ `waits` – Die Anzahl der Warteereignisse, die für die angegebene Prozess-ID aufgelaufen sind.
+ `wait_time` – Wartezeit in Millisekunden.
## Nutzungshinweise
Sie können diese Funktion verwenden, um bestimmte Backend-Warteereignisse (Sitzung) zu analysieren, die seit dem Öffnen einer Verbindung aufgetreten sind. Aussagekräftigere Informationen über Warteereignisnamen und -typen erhalten Sie, wenn Sie diese Funktion mit `aurora_stat_wait_type` und `aurora_stat_wait_event` kombinieren, indem Sie JOIN verwenden, wie in den Beispielen gezeigt.
## Beispiele
Dieses Beispiel zeigt alle Warteereignisse, Typen und Ereignisnamen für die Backend-Prozess-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
```
Dieses Beispiel zeigt aktuelle und kumulative Wartetypen und -ereignisse für alle aktiven Sitzungen (`pg_stat_activity state <> 'idle'`) (aber ohne die aktuelle Sitzung, die die Funktion aufruft (`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
```
Dieses Beispiel zeigt aktuelle und die drei wichtigsten (3) kumulativen Wartetypen und Warteereignisse für alle aktiven Sitzungen (`pg_stat_activity state <> 'idle'`) ohne die aktuelle Sitzung (`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` ist eine Statistikanzeige mit Informationen über Cache-Schreibvorgänge für optimierte Lesevorgänge.
## Syntax
```
aurora_stat_bgwriter()
```
## Argumente
Keine
## Rückgabetyp
SETOF-Datensatz mit allen Spalten von `pg_stat_bgwriter` und den folgenden zusätzlichen Spalten. Weitere Informationen zu den Spalten von `pg_stat_bgwriter` finden Sie unter [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).
Sie können die Statistiken für diese Funktion mit `pg_stat_reset_shared("bgwriter")` zurücksetzen.
+ `orcache_blks_written` – Gesamtzahl der geschriebenen Cache-Datenblöcke für optimierte Lesevorgänge.
+ `orcache_blk_write_time` – Wenn `track_io_timing` aktiviert ist, wird die Gesamtzeit, die für das Schreiben von Cache-Datendateiblöcken für optimierte Lesevorgänge aufgewendet wurde, in Millisekunden aufgezeichnet. Weitere Informationen finden Sie unter [track\$1io\$1timing](https://www.postgresql.org/docs/current/runtime-config-statistics.html#GUC-TRACK-IO-TIMING).
## Nutzungshinweise
Diese Funktion steht in folgenden Aurora-PostgreSQL-Versionen zur Verfügung:
+ 15.4 und höhere 15-Versionen
+ 14.9 und höhere 14-Versionen
## Beispiele
```
=> select * from aurora_stat_bgwriter();
-[ RECORD 1 ]-----------------+-----------
orcache_blks_written | 246522
orcache_blk_write_time | 339276.404
```
# aurora\$1stat\$1database
Enthält alle Spalten von pg\$1stat\$1database und fügt am Ende neue Spalten hinzu.
## Syntax
```
aurora_stat_database()
```
## Argumente
Keine
## Rückgabetyp
SETOF-Datensatz mit allen Spalten von `pg_stat_database` und den folgenden zusätzlichen Spalten. Weitere Informationen zu den Spalten von `pg_stat_database` finden Sie unter [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`: Gesamtzahl der gemeinsam genutzten Blöcke, die aus dem Aurora-Speicher in dieser Datenbank gelesen wurden.
+ `orcache_blks_hit`: Gesamtzahl der Treffer im Cache für optimierte Lesevorgänge in dieser Datenbank.
+ `local_blks_read`: Gesamtzahl der in dieser Datenbank gelesenen lokalen Blöcke.
+ `storage_blk_read_time`: Wenn `track_io_timing` aktiviert ist, wird die Gesamtzeit für das Lesen von Datendateiblöcken aus dem Aurora-Speicher in Millisekunden aufgezeichnet. Andernfalls beträgt der Wert Null. Weitere Informationen finden Sie unter [track\$1io\$1timing](https://www.postgresql.org/docs/current/runtime-config-statistics.html#GUC-TRACK-IO-TIMING).
+ `local_blk_read_time`: Wenn `track_io_timing` aktiviert ist, wird die Gesamtzeit für das Lesen von lokalen Datendateiblöcken in Millisekunden aufgezeichnet. Andernfalls beträgt der Wert Null. Weitere Informationen finden Sie unter [track\$1io\$1timing](https://www.postgresql.org/docs/current/runtime-config-statistics.html#GUC-TRACK-IO-TIMING).
+ `orcache_blk_read_time`: Wenn `track_io_timing` aktiviert ist, wird die Gesamtzeit für das Lesen von Datendateiblöcken aus dem Cache für optimierte Lesevorgänge in Millisekunden aufgezeichnet. Andernfalls beträgt der Wert Null. Weitere Informationen finden Sie unter [track\$1io\$1timing](https://www.postgresql.org/docs/current/runtime-config-statistics.html#GUC-TRACK-IO-TIMING).
**Anmerkung**
Der Wert von `blks_read` ist die Summe von `storage_blks_read`, `orcache_blks_hit` und `local_blks_read`.
Der Wert von `blk_read_time` ist die Summe von `storage_blk_read_time`, `orcache_blk_read_time` und `local_blk_read_time`.
## Nutzungshinweise
Diese Funktion steht in folgenden Aurora-PostgreSQL-Versionen zur Verfügung:
+ 15.4 und höhere 15-Versionen
+ 14.9 und höhere 14-Versionen
## Beispiele
Das folgende Beispiel zeigt, wie alle Spalten von `pg_stat_database` enthalten sind und am Ende 6 neue Spalten angefügt werden:
```
=> 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
Meldet kumulative Aktivitäten für jeden Data-Manipulation-Language-Vorgangstyp (DML) in einer Datenbank in einem Aurora-PostgreSQL-Cluster.
## Syntax
```
aurora_stat_dml_activity(database_oid)
```
## Argumente
*database\$1oid*
Die Objekt-ID (OID) der Datenbank im Aurora-PostgreSQL-Cluster.
## Rückgabetyp
SETOF-Datensatz
## Nutzungshinweise
Die Funktion `aurora_stat_dml_activity` ist nur mit Version 3.1 von Aurora PostgreSQL verfügbar, die mit der PostgreSQL-Engine 11.6 und höher kompatibel ist.
Verwenden Sie diese Funktion in Aurora-PostgreSQL-Clustern mit einer großen Anzahl von Datenbanken, um zu ermitteln, welche Datenbanken mehr oder langsamere DML-Aktivitäten oder beides haben.
Die Funktion `aurora_stat_dml_activity` gibt die Anzahl der Ausführungen und die kumulative Latenz in Mikrosekunden für SELECT-, INSERT-, UPDATE- und DELETE-Operationen zurück. Der Bericht enthält nur erfolgreiche DML-Operationen.
Mit der PostgreSQL-Statistikzugriffsfunktion `pg_stat_reset` können Sie diese Statistik zurücksetzen. Mit der Funktion `pg_stat_get_db_stat_reset_time` können Sie überprüfen, wann diese Statistik zuletzt zurückgesetzt wurde. Weitere Informationen zu PostgreSQL-Statistikzugriffsfunktionen finden Sie unter [Die Statistikerfassung](https://www.postgresql.org/docs/9.1/monitoring-stats.html) in der PostgreSQL-Dokumentation.
## Beispiele
Im folgenden Beispiel wird gezeigt, wie Sie DML-Aktivitätsstatistiken für die verbundene Datenbank melden.
```
––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
```
Im folgenden Beispiel sehen Sie DML-Aktivitätsstatistiken für alle Datenbanken im Aurora-PostgreSQL-Cluster. Dieser Cluster hat zwei Datenbanken, `postgres` und `mydb`. Die durch Komma getrennte Liste entspricht den Feldern `select_count`, `select_latency_microsecs`, `insert_count`, `insert_latency_microsecs`, `update_count`, `update_latency_microsecs`, `delete_count` und `delete_latency_microsecs`.
Aurora PostgreSQL erstellt und verwendet eine Systemdatenbank namens `rdsadmin`, um administrative Vorgänge wie Backups, Wiederherstellungen, Zustandsprüfungen, Replikationen usw. zu unterstützen. Diese DML-Operationen haben keine Auswirkungen auf Ihren Aurora-PostgreSQL-Cluster.
```
=> 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)
```
Das folgende Beispiel zeigt DML-Aktivitätsstatistiken für alle Datenbanken, die aus Gründen der Lesbarkeit in Spalten angeordnet sind.
```
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
```
Das folgende Beispiel zeigt die durchschnittliche kumulative Latenz (kumulative Latenz geteilt durch die Anzahl) jeder DML-Operation für die Datenbank mit der OID `16401`.
```
=> 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
Ruft die kumulative Commit-Latenz in Mikrosekunden für Aurora-PostgreSQL-Datenbanken ab. Die *Commit-Latenz* wird als Zeit zwischen dem Senden einer Commit-Anforderung und dem Empfang der Commit-Bestätigung gemessen.
## Syntax
```
aurora_stat_get_db_commit_latency(database_oid)
```
## Argumente
*database\$1oid*
Die Objekt-ID (OID) der Aurora-PostgreSQL-Datenbank.
## Rückgabetyp
SETOF-Datensatz
## Nutzungshinweise
Amazon CloudWatch verwendet diese Funktion, um die durchschnittliche Commit-Latenz zu berechnen. Weitere Informationen zu Amazon-CloudWatch-Metriken und zur Behebung einer hohen Commit-Latenz finden Sie unter [Anzeigen von Metriken in der Amazon-RDS-Konsole](USER_Monitoring.md) und [Making better decisions about Amazon RDS with Amazon CloudWatch metrics](https://aws.amazon.com/blogs/database/making-better-decisions-about-amazon-rds-with-amazon-cloudwatch-metrics/).
Mit der PostgreSQL-Statistikzugriffsfunktion `pg_stat_reset` können Sie diese Statistik zurücksetzen. Mit der Funktion `pg_stat_get_db_stat_reset_time` können Sie überprüfen, wann diese Statistik zuletzt zurückgesetzt wurde. Weitere Informationen zu PostgreSQL-Statistikzugriffsfunktionen finden Sie unter [Die Statistikerfassung](https://www.postgresql.org/docs/9.1/monitoring-stats.html) in der PostgreSQL-Dokumentation.
## Beispiele
Im folgenden Beispiel wird die kumulative Commit-Latenz für jede Datenbank im Cluster `pg_database` abgerufen.
```
=> 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
```
Im folgenden Beispiel wird die kumulative Commit-Latenz für die aktuell verbundene Datenbank abgerufen. Vor dem Aufruf der Funktion `aurora_stat_get_db_commit_latency` wird im Beispiel zuerst `\gset` verwendet, um eine Variable für das Argument `oid` zu definieren und ihren Wert aus der verbundenen Datenbank zu beziehen.
```
––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
```
Im folgenden Beispiel wird die kumulative Commit-Latenz für die `mydb`-Datenbank im Cluster `pg_database` abgerufen. Dann wird diese Statistik mit der Funktion `pg_stat_reset` zurückgesetzt und die Ergebnisse werden angezeigt. Abschließend wird die Funktion `pg_stat_get_db_stat_reset_time` ausgeführt, um zu überprüfen, wann diese Statistik zuletzt zurückgesetzt wurde.
```
=> 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
Zeigt die Cache-Auslastung für das logische Write-Ahead-Protokoll (WAL) pro Slot an.
## Syntax
```
SELECT * FROM aurora_stat_logical_wal_cache()
```
## Argumente
Keine
## Rückgabetyp
SETOF-Datensatz mit den folgenden Spalten:
+ `name` – Der Name der Replikationsgruppe.
+ `active_pid` – Die ID des Walsender-Prozesses.
+ `cache_hit` – Die Gesamtzahl der WAL-Cache-Treffer seit dem letzten Reset.
+ `cache_miss` – Die Gesamtzahl der WAL-Cache-Fehler seit dem letzten Reset.
+ `blks_read` – Die Gesamtzahl der Wal-Cache-Leseanfragen.
+ `hit_rate` – Die WAL-Cache-Trefferrate (cache\$1hit/blks\$1read).
+ `last_reset_timestamp` – Das letzte Mal, dass der Zähler zurückgesetzt wurde.
## Nutzungshinweise
Diese Funktion steht in folgenden Aurora-PostgreSQL-Versionen zur Verfügung:
+ 15.2 und alle höheren Versionen
+ 14.7 und höhere Versionen
+ 13.8 und höhere Versionen
+ 12.12 und höhere Versionen
+ 11.17 und höhere Versionen
## Beispiele
Das folgende Beispiel zeigt zwei Replikations-Slots mit nur einer aktiven `aurora_stat_logical_wal_cache`-Funktion.
```
=> 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
Meldet die Speicherkontextnutzung für jeden PostgreSQL-Prozess.
## Syntax
```
aurora_stat_memctx_usage()
```
## Argumente
Keine
## Rückgabetyp
SETOF-Datensatz mit den folgenden Spalten:
+ `pid` – die ID des Prozesses.
+ `name` – der Name des Speicherkontexts.
+ `allocated` – Die Anzahl der Byte, die der Speicherkontext aus dem zugrunde liegenden Speichersubsystem abgerufen hat.
+ `used` – Die Anzahl der an Clients des Speicherkontextes übergebenen Byte.
+ `instances` – Die Anzahl der derzeit existierenden Kontexte dieses Typs.
## Nutzungshinweise
Diese Funktion zeigt die Speicherkontextnutzung für jeden PostgreSQL-Prozess an. Einige Prozesse sind mit `anonymous` beschriftet. Die Prozesse werden nicht offengelegt, da sie eingeschränkte Schlüsselwörter enthalten.
Diese Funktion steht ab den folgenden Aurora-PostgreSQL-Versionen zur Verfügung:
+ 15.3 und höhere 15-Versionen
+ 14.8 und höhere 14-Versionen
+ 13.11 und höhere 13-Versionen
+ 12.15 und höhere 12-Versionen
+ 11.20 und höhere 11-Versionen
## Beispiele
Im folgenden Beispiel sehen Sie die Ergebnisse vom Aufruf der Funktion `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)
```
Einige eingeschränkte Schlüsselwörter werden ausgeblendet und die Ausgabe sieht wie folgt aus:
```
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
Diese Funktion zeigt mehrstufige Cache-Statistiken an.
## Syntax
```
aurora_stat_optimized_reads_cache()
```
## Argumente
Keine
## Rückgabetyp
SETOF-Datensatz mit den folgenden Spalten:
+ `total_size` – Gesamtgröße des Cache für optimierte Lesevorgänge
+ `used_size` – Verwendete Seitengröße im Cache für optimierte Lesevorgänge
## Nutzungshinweise
Diese Funktion steht in folgenden Aurora-PostgreSQL-Versionen zur Verfügung:
+ 15.4 und höhere 15-Versionen
+ 14.9 und höhere 14-Versionen
## Beispiele
Das folgende Beispiel zeigt die Ausgabe für eine r6gd.8xlarge-Instance:
```
=> 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
Gibt eine Zeile für jeden nachverfolgten Ausführungsplan zurück
## Syntax
```
aurora_stat_plans(
showtext
)
```
## Argumente
+ showtext – Zeigt den Abfrage- und Plantext an. Gültige Werte sind NULL, true oder false. Bei true werden Abfrage- und Plantext angezeigt.
## Rückgabetyp
Gibt für jeden nachverfolgten Plan eine Zeile zurück, die alle Spalten von `aurora_stat_statements` und die folgenden zusätzlichen Spalten enthält
+ planid – Plan-ID
+ explain\$1plan – Erklärt den Plantext
+ plan\$1type:
+ `no plan` – Kein Plan wurde erfasst
+ `estimate` – Plan mit geschätzten Kosten erfasst
+ `actual` – Plan mit EXPLAIN ANALYZE erfasst
+ plan\$1captured\$1time – Zeit der letzten Planerfassung
## Nutzungshinweise
`aurora_compute_plan_id` muss aktiviert sein und `pg_stat_statements` muss sich in `shared_preload_libraries` befinden, damit die Pläne nachverfolgt werden können.
Die Anzahl der verfügbaren Pläne wird durch den im Parameter `pg_stat_statements.max` festgelegten Wert gesteuert. Wenn `aurora_compute_plan_id` aktiviert ist, können Sie die Pläne bis zu diesem angegebenen Wert in `aurora_stat_plans` nachverfolgen.
Diese Funktion ist in den Aurora-PostgreSQL-Versionen 14.10, 15.5 und für alle späteren Versionen verfügbar.
## Beispiele
Im folgenden Beispiel werden die beiden Pläne zur Abfrage-ID -5471422286312252535 erfasst und die Statistik der Anweisungen wird über die planid nachverfolgt.
```
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
Setzt den Zähler für den logischen WAL-Cache zurück.
## Syntax
So setzen Sie einen bestimmten Slot zurück
```
SELECT * FROM aurora_stat_reset_wal_cache('slot_name')
```
So setzen Sie alle Slots zurück
```
SELECT * FROM aurora_stat_reset_wal_cache(NULL)
```
## Argumente
`NULL` oder `slot_name`
## Rückgabetyp
Statusmeldung, Textzeichenfolge
+ Setzen Sie den logischen WAL-Cache-Zähler zurück – Erfolgsmeldung. Dieser Text wird zurückgegeben, wenn die Funktion erfolgreich ist.
+ Der Replikations-Slot wurde nicht gefunden. Bitte versuchen Sie es noch einmal. – Fehlernachricht Dieser Text wird zurückgegeben, wenn die Funktion nicht erfolgreich ist.
## Nutzungshinweise
Diese Funktion steht für die folgenden Versionen zur Verfügung.
+ Aurora PostgreSQL 14.5 und höher
+ Aurora PostgreSQL 13.8 und höhere Versionen
+ Aurora PostgreSQL 12.12 und höhere Versionen
+ Aurora PostgreSQL 11.17 und höhere Versionen
## Beispiele
Im folgenden Beispiel wird die `aurora_stat_reset_wal_cache`-Funktion verwendet, um einen Slot namens `test_results` zurückzusetzen. Anschließend wird versucht, einen Slot zurückzusetzen, der nicht existiert.
```
=> 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
Meldet die Ressourcennutzung in Echtzeit, bestehend aus Backend-Ressourcenmetriken und CPU-Auslastung für alle Backend-Prozesse von Aurora PostgreSQL
## Syntax
```
aurora_stat_resource_usage()
```
## Argumente
Keine
## Rückgabetyp
SETOF-Datensatz mit Spalten:
+ pid – Prozess-ID
+ allocated\$1memory – Vom Prozess zugewiesener Gesamtspeicher in Byte
+ used\$1memory – Tatsächlich vom Prozess genutzter Speicher in Byte
+ cpu\$1usage\$1percent – Prozentsatz der CPU-Auslastung des Prozesses
## Nutzungshinweise
Diese Funktion zeigt die Backend-Ressourcennutzung für jeden Backend-Prozess von Aurora PostgreSQL an.
Diese Funktion steht ab den folgenden Aurora-PostgreSQL-Versionen zur Verfügung:
+ Aurora PostgreSQL 17.5 und höhere Versionen von 17
+ Aurora PostgreSQL 16.9 und höhere Versionen von 16
+ Aurora PostgreSQL 15.13 und höhere Versionen von 15
+ Aurora PostgreSQL 14.18 und höhere Versionen von 14
+ Aurora PostgreSQL 13.21 und höhere Versionen von 13
## Beispiele
Im folgenden Beispiel wird die Ausgabe der Funktion `aurora_stat_resource_usage` gezeigt.
```
=> 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
Zeigt alle Spalten von `pg_stat_statements` an und fügt am Ende weitere Spalten hinzu.
## Syntax
```
aurora_stat_statements(showtext boolean)
```
## Argumente
*showtext boolean*
## Rückgabetyp
SETOF-Datensatz mit allen Spalten von `pg_stat_statements` und den folgenden zusätzlichen Spalten. Weitere Informationen zu den Spalten von `pg_stat_statements` finden Sie unter [https://www.postgresql.org/docs/current/pgstatstatements.html](https://www.postgresql.org/docs/current/pgstatstatements.html).
Sie können die Statistiken für diese Funktion mit `pg_stat_statements_reset()` zurücksetzen.
+ `storage_blks_read`: Gesamtzahl der gemeinsam genutzten Blöcke, die von dieser Anweisung aus dem Aurora-Speicher gelesen wurden.
+ `orcache_blks_hit`: Gesamtzahl der mit dieser Anweisung erzielten Treffer im Cache für optimierte Lesevorgänge.
+ `storage_blk_read_time` – Wenn `track_io_timing` aktiviert ist, wird die Gesamtzeit in Millisekunden aufgezeichnet, die die Anweisung für das Lesen von gemeinsam genutzten Blöcken aus dem Aurora-Speicher benötigt hat. Andernfalls beträgt der Wert Null. Weitere Informationen finden Sie unter [track\$1io\$1timing](https://www.postgresql.org/docs/current/runtime-config-statistics.html#GUC-TRACK-IO-TIMING).
+ `local_blk_read_time` – Wenn `track_io_timing` aktiviert ist, wird die Gesamtzeit in Millisekunden aufgezeichnet, die die Anweisung für das Lesen von lokalen Blöcken benötigt hat. Andernfalls beträgt der Wert Null. Weitere Informationen finden Sie unter [track\$1io\$1timing](https://www.postgresql.org/docs/current/runtime-config-statistics.html#GUC-TRACK-IO-TIMING).
+ `orcache_blk_read_time` – Wenn `track_io_timing` aktiviert ist, wird die Gesamtzeit in Millisekunden aufgezeichnet, die die Anweisung für das Lesen von gemeinsam genutzten Blöcken aus dem Cache für optimierte Lesevorgänge benötigt hat. Andernfalls beträgt der Wert Null. Weitere Informationen finden Sie unter [track\$1io\$1timing](https://www.postgresql.org/docs/current/runtime-config-statistics.html#GUC-TRACK-IO-TIMING).
+ `total_plan_peakmem` – Gesamtsumme der Werte zur maximalen Speichernutzung während der Planungsphase für alle Aufrufe dieser Anweisung. Um die durchschnittliche maximale Speichernutzung während der Planung für die Anweisung zu ermitteln, teilen Sie diesen Wert durch die Anzahl der Aufrufe.
+ `min_plan_peakmem` – Kleinster Wert der maximalen Speichernutzung während der Planung über alle Aufrufe dieser Anweisung hinweg
+ `max_plan_peakmem` – Größter Wert der maximalen Speichernutzung während der Planung über alle Aufrufe dieser Anweisung hinweg
+ `total_exec_peakmem` – Gesamtsumme der Werte zur maximalen Speichernutzung während der Ausführungsphase für alle Aufrufe dieser Anweisung. Um die durchschnittliche maximale Speichernutzung während der Ausführung für die Anweisung zu ermitteln, teilen Sie diesen Wert durch die Anzahl der Aufrufe.
+ `min_exec_peakmem` – Kleinster Wert der maximalen Speichernutzung in Byte während der Ausführung über alle Aufrufe dieser Anweisung hinweg
+ `max_exec_peakmem` – Größter Wert der maximalen Speichernutzung in Byte während der Ausführung über alle Aufrufe dieser Anweisung hinweg
**Anmerkung**
`total_plan_peakmen`, `min_plan_peakmem` und `max_plan_peakmem` werden nur überwacht, wenn die Einstellung `pg_stat_statements.track_planning` aktiviert ist.
## Nutzungshinweise
Zur Verwendung der Funktion aurora\$1stat\$1statements() müssen Sie die Erweiterung `pg_stat_statements` in den Parameter `shared_preload_libraries` aufnehmen.
Diese Funktion steht in folgenden Aurora-PostgreSQL-Versionen zur Verfügung:
+ 15.4 und höhere 15-Versionen
+ 14.9 und höhere 14-Versionen
Die Spalten zur maximalen Speichernutzung sind in den folgenden Versionen verfügbar:
+ 16.3 und höhere Versionen
+ 15.7 und höhere Versionen
+ 14.12 und höhere Versionen
## Beispiele
Das folgende Beispiel zeigt, wie alle Spalten von pg\$1stat\$1statements enthalten sind und am Ende 11 neue Spalten angefügt werden:
```
=> 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
Meldet Warteereignisinformationen für die Aurora-PostgreSQL-DB-Instance.
## Syntax
```
aurora_stat_system_waits()
```
## Argumente
Keine
## Rückgabetyp
SETOF-Datensatz
## Nutzungshinweise
Diese Funktion gibt die kumulative Anzahl der Wartezeiten und die kumulative Wartezeit für jedes Warteereignis zurück, das von der DB-Instance generiert wird, mit der Sie derzeit verbunden sind.
Der zurückgegebene Datensatz enthält die folgenden Felder:
+ `type_id` – die ID des Warteereignistyps.
+ `event_id` – die ID des Warteereignisses.
+ `waits` – die Häufigkeit, mit der das Warteereignis aufgetreten ist.
+ `wait_time` – die Gesamtzeit in Mikrosekunden, die auf dieses Ereignis gewartet wurde.
Die von dieser Funktion zurückgegebenen Statistiken werden zurückgesetzt, wenn eine DB-Instance neu gestartet wird.
## Beispiele
Im folgenden Beispiel sehen Sie Ergebnisse vom Aufruf der Funktion `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
```
Im folgenden Beispiel wird gezeigt, wie Sie diese Funktion mit `aurora_stat_wait_event` und `aurora_stat_wait_type` ausführen können, um besser lesbare Ergebnisse zu erzeugen.
```
=> 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
Listet alle unterstützten Warteereignisse für Aurora PostgreSQL auf. Informationen zu Aurora PostgreSQL-Warteereignissen finden Sie unter [Amazon-Aurora-PostgreSQL-Warteereignisse](AuroraPostgreSQL.Reference.Waitevents.md).
## Syntax
```
aurora_stat_wait_event()
```
## Argumente
Keine
## Rückgabetyp
SETOF-Datensatz mit den folgenden Spalten:
+ type\$1id – die ID des Warteereignistyps.
+ event\$1id – die ID des Warteereignisses.
+ type\$1name – Name des Wartetyps
+ event\$1name – Name des Warteereignisses
## Nutzungshinweise
Kombinieren Sie diese Funktion mit anderen Funktionen wie `aurora_stat_wait_type` und `aurora_stat_system_waits`, um Ereignisnamen mit Ereignistypen anstelle von IDs anzuzeigen. Namen von Warteereignissen, die von dieser Funktion zurückgegeben werden, sind die gleichen Namen, die von der Funktion `aurora_wait_report` zurückgegeben werden.
## Beispiele
Im folgenden Beispiel sehen Sie Ergebnisse vom Aufruf der Funktion `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
```
Im folgenden Beispiel werden `aurora_stat_wait_type` und `aurora_stat_wait_event` zusammengeführt, um aus Gründen der Lesbarkeit Typnamen und Ereignisnamen zurückzugeben.
```
=> 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
Listet alle unterstützten Wartetypen für Aurora PostgreSQL auf.
## Syntax
```
aurora_stat_wait_type()
```
## Argumente
Keine
## Rückgabetyp
SETOF-Datensatz mit den folgenden Spalten:
+ type\$1id – die ID des Warteereignistyps.
+ type\$1name – name des Wartetyps.
## Nutzungshinweise
Kombinieren Sie diese Funktion mit anderen Funktionen wie `aurora_stat_wait_event` und `aurora_stat_system_waits`, um Warteereignisnamen mit Warteereignistypen anstelle von IDs anzuzeigen. Namen von Wartetypen, die von dieser Funktion zurückgegeben werden, sind die gleichen Namen, die von der Funktion `aurora_wait_report` zurückgegeben werden.
## Beispiele
Im folgenden Beispiel sehen Sie Ergebnisse vom Aufruf der Funktion `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
Gibt den Zeichenfolgewert der Versionsnummer der PostgreSQL-kompatiblen Edition von Amazon Aurora zurück.
## Syntax
```
aurora_version()
```
## Argumente
Keine
## Rückgabetyp
CHAR- oder VARCHAR-Zeichenfolge
## Nutzungshinweise
Diese Funktion zeigt die Version der Datenbank-Engine der PostgreSQL-kompatiblen Edition von Amazon Aurora an. Die Versionsnummer wird als Zeichenfolge zurückgegeben im Format *major*.*minor*.*patch*. Weitere Informationen zu den Aurora-PostgreSQL-Versionsnummern erhalten Sie unter [Aurora-Versionsnummer](AuroraPostgreSQL.Updates.md#AuroraPostgreSQL.Updates.Versions.AuroraNumber).
Sie können auswählen, wann Upgrades von Nebenversionen angewendet werden sollen, indem Sie das Wartungsfenster für Ihren Aurora-PostgreSQL-DB-Cluster festlegen. Um zu erfahren wie, siehe [Warten eines Amazon Aurora-DB-Clusters](USER_UpgradeDBInstance.Maintenance.md).
Ab der Veröffentlichung der PostgreSQL-Versionen 13.3, 12.8, 11.13 und 10.18 und für alle späteren Versionen sind die Aurora-Versionsnummern genauer auf die PostgreSQL-Versionsnummern abgestimmt. Weitere Informationen zu allen Aurora-PostgreSQL-Versionen finden Sie unter [Updates für Amazon Aurora PostgreSQL](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html) in den *Versionshinweisen für Aurora PostgreSQL*.
## Beispiele
Das folgende Beispiel zeigt die Ergebnisse des Aufrufs der `aurora_version`-Funktion auf einem Aurora-PostgreSQL-DB-Cluster, der [PostgreSQL 12.7, Aurora-PostgreSQL- Version 4.2](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#AuroraPostgreSQL.Updates.20180305.42) ausführt und dann die gleiche Funktion auf einem Cluster mit [Aurora-PostgreSQL-Version 13.3](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#AuroraPostgreSQL.Updates.20180305.133X) ausführt.
```
=> SELECT * FROM aurora_version();
aurora_version
----------------
4.2.2
SELECT * FROM aurora_version();
aurora_version
----------------
13.3.0
```
Dieses Beispiel zeigt, wie Sie die Funktion mit verschiedenen Optionen verwenden, um mehr über die Aurora-PostgreSQL-Version zu erfahren. Dieses Beispiel verwendet eine Aurora-Versionsnummer, die sich von der PostgreSQL-Versionsnummer unterscheidet.
```
=> 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)
```
In diesem nächsten Beispiel wird die Funktion mit den gleichen Optionen wie im vorherigen Beispiel verwendet. Dieses Beispiel hat keine Aurora-Versionsnummer, die sich von der PostgreSQL-Versionsnummer unterscheidet.
```
=> 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
Gibt die Log-Sequenznummer (LSN) zurück, die zur Identifizierung des Anfangs eines Datensatzes im Logical Write-Ahead Log (WAL)-Stream des Aurora-Cluster-Volumes verwendet wird.
## Syntax
```
aurora_volume_logical_start_lsn()
```
## Argumente
Keine
## Rückgabetyp
`pg_lsn`
## Nutzungshinweise
Diese Funktion identifiziert den Anfang des Datensatzes im logischen WAL-Stream für ein bestimmtes Aurora-Cluster-Volume. Sie können diese Funktion verwenden, während Sie ein Hauptversions-Upgrade durchführen, indem Sie logische Replikation und schnelles Klonen von Aurora verwenden, um zu ermitteln, an welcher LSN ein Snapshot oder ein Datenbankklon erstellt wird. Anschließend können Sie die logische Replikation verwenden, um die neueren Daten, die nach dem LSN aufgezeichnet wurden, kontinuierlich zu streamen und die Änderungen vom Publisher zum Subscriber zu synchronisieren.
Weitere Informationen zur Verwendung der logischen Replikation für ein Hauptversions-Upgrade finden Sie unter [Verwenden der logischen Replikation, um ein Hauptversions-Upgrade für Aurora PostgreSQL durchzuführen](AuroraPostgreSQL.MajorVersionUpgrade.md).
Diese Funktion steht für die folgenden Versionen von Aurora PostgreSQL zur Verfügung:
+ 15.2 und höhere 15-Versionen
+ 14.3 und höhere 14-Versionen
+ 13.6 und höhere 13-Versionen
+ 12.10 und höhere 12-Versionen
+ 11.15 und höhere 11-Versionen
+ 10.20 und höhere 10-Versionen
## Beispiele
Sie können die Log-Sequenznummer (LSN) mithilfe der folgenden Abfrage abrufen:
```
postgres=> SELECT aurora_volume_logical_start_lsn();
aurora_volume_logical_start_lsn
---------------
0/402E2F0
(1 row)
```
# aurora\$1wait\$1report
Diese Funktion zeigt die Aktivität „Warteereignis“ über einen bestimmten Zeitraum an.
## Syntax
```
aurora_wait_report([time])
```
## Argumente
*Zeit (optional) *
Die Zeit in Sekunden. Der Standardwert beträgt 10 Sekunden.
## Rückgabetyp
SETOF-Datensatz mit den folgenden Spalten:
+ type\$1name – Name des Wartetyps
+ event\$1name – Name des Warteereignisses
+ wait – Anzahl der Warteereignisse
+ wait\$1time – Wartezeit in Millisekunden
+ ms\$1per\$1wait – durchschnittliche Millisekunden pro Anzahl eines Warteereignisses
+ waits\$1per\$1xact – durchschnittliche Warteereignisse pro Anzahl einer Transaktion
+ ms\$1per\$1xact – durchschnittliche Millisekunden nach Anzahl der Transaktionen
## Nutzungshinweise
Diese Funktion ist ab Aurora-PostgreSQL-Release 1.1 verfügbar, die mit PostgreSQL 9.6.6 und höheren Versionen kompatibel ist.
Wenn Sie diese Funktion nutzen möchten, müssen Sie zuerst die Aurora-PostgreSQL-Erweiterung `aurora_stat_utils` wie folgt erstellen:
```
=> CREATE extension aurora_stat_utils;
CREATE EXTENSION
```
Weitere Informationen zu verfügbaren Aurora-PostgreSQL-Erweiterungsversionen finden Sie unter [Erweiterungsversionen für Amazon Aurora PostgreSQL](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Extensions.html) in den *Versionshinweisen für Aurora PostgreSQL*.
Diese Funktion berechnet die Warteereignisse auf Instance-Ebene, indem zwei Snapshots von Statistikdaten aus der Funktion aurora\$1stat\$1system\$1waits() und den Postgre-SQL-Statistikansichten pg\$1stat\$1database verglichen werden.
Weitere Informationen über `aurora_stat_system_waits()` und `pg_stat_database` finden Sie unter [Die Statistikerfassung](https://www.postgresql.org/docs/current/monitoring-stats.html#PG-STAT-DATABASE-VIEW) in der *PostgreSQL-Dokumentation*.
Wenn diese Funktion ausgeführt wird, erstellt sie einen ersten Snapshot, wartet die angegebene Anzahl von Sekunden und erstellt dann einen zweiten Snapshot. Die Funktion vergleicht die beiden Snapshots und gibt den Unterschied zurück. Dieser Unterschied stellt die Aktivität der Instance für dieses Zeitintervall dar.
In der Writer-Instance zeigt die Funktion auch die Anzahl der Transaktionen, für die ein Commit ausgeführt wurde, und TPS (Transaktionen pro Sekunde) an. Diese Funktion gibt Informationen auf Instance-Ebene zurück und enthält alle Datenbanken in der Instance.
## Beispiele
Dieses Beispiel zeigt, wie die Erweiterung aurora\$1stat\$1utils erstellt wird, um die Funktion aurora\$1wait\$1report verwenden zu können.
```
=> CREATE extension aurora_stat_utils;
CREATE EXTENSION
```
Dieses Beispiel zeigt, wie der Wartebericht 10 Sekunden lang überprüft wird.
```
=> 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
```
Dieses Beispiel zeigt, wie der Wartebericht 60 Sekunden lang überprüft wird.
```
=> 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
```