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 Postgre SQL Unbegrenzte Datenbankfunktionen
Die folgende Tabelle zeigt die neuen Funktionen für Aurora Postgre SQL Limitless Database.
Anmerkung
Die in dieser Tabelle aufgeführten Funktionen befinden sich im rds_aurora Schema. Wenn Sie eine Limitless Database-Funktion verwenden, stellen Sie sicher, dass Sie den vollqualifizierten Objektnamen angeben:rds_aurora. .object_name
| Aurora Postgre SQL Limitless Datenbankfunktion | Entsprechende Aurora Postgre-Funktion SQL |
|---|---|
| limitless_backend_dsid | pg_backend_pid |
| limitless_cancel_session | pg_cancel_backend |
| limitless_stat_clear_snapshot | pg_stat_clear_snapshot |
| grenzenlose_stat_database_size | pg_database_size |
| limitless_stat_get_snapshot_timestamp | pg_stat_get_snapshot_timestamp |
| grenzenlose_stat_prepared_xacts | pg_prepared_xacts |
| grenzenlose_stat_relation_sizes | pg_indexes_size, pg_relation_size, pg_table_size, pg_total_relation_size |
| limitless_stat_reset | pg_stat_reset |
| limitless_statements_reset | pg_stat_statements_reset |
| limitless_stat_system_waits | aurora_stat_system_waits |
| limitless_terminate_session | pg_terminate_backend |
| limitless_wait_report | aurora_wait_report |
Die folgenden Beispiele enthalten Einzelheiten zu den Funktionen der Aurora Postgre SQL Limitless Database. Weitere Informationen zu Postgre-Funktionen finden Sie unter SQL Funktionen und Operatoren
- limitless_backend_dsid
-
Die
limitless_backend_dsidFunktion gibt die verteilte Sitzungs-ID für die aktuelle Sitzung zurück. Eine verteilte Sitzung wird auf einem Router in einer DB-Shard-Gruppe ausgeführt und umfasst Backend-Prozesse auf einem oder mehreren Shards in der DB-Shard-Gruppe.Das folgende Beispiel zeigt, wie die Funktion verwendet wird.
limitless_backend_dsidSELECT rds_aurora.limitless_backend_dsid(); limitless_backend_dsid ------------------------ 8CACD7B04D0FC2A5 (1 row) - limitless_cancel_session
-
Die
limitless_cancel_sessionFunktion funktioniert ähnlich wie, versucht aberpg_cancel_backend, alle Backend-Prozesse im Zusammenhang mit der angegebenen verteilten Sitzungs-ID abzubrechen, indem sie ein (Unterbrechungssignal) sendet.SIGINTDer Eingabeparameter ist der folgende:
-
distributed_session_id(Text) — Die ID der verteilten Sitzung, die abgebrochen werden soll.
Die Ausgabeparameter sind die folgenden:
-
subcluster_id(Text) — Die ID des Subclusters, zu dem dieser Prozess gehört. -
pid(text) — Die Backend-Prozess-ID. -
success(boolean) — Ob die Stornierung erfolgreich war.
Das folgende Beispiel zeigt, wie die Funktion verwendet wird
limitless_cancel_session.SELECT * FROM rds_aurora.limitless_cancel_session('940CD5C81E3C796B'); subcluster_id | pid | success ---------------+-------+--------- 1 | 26920 | t (1 row) -
- limitless_stat_clear_snapshot
-
Die
limitless_stat_clear_snapshotFunktion verwirft den aktuellen Statistik-Snapshot oder die zwischengespeicherten Informationen auf allen Knoten.Das folgende Beispiel zeigt, wie die Funktion verwendet wird
limitless_stat_clear_snapshot.SELECT rds_aurora.limitless_stat_clear_snapshot(); - limitless_stat_database_size
-
Die
limitless_stat_database_sizeFunktion gibt die Größen einer Datenbank in der DB-Shard-Gruppe zurück.Der Eingabeparameter ist der folgende:
-
dbname(Name) — Die Datenbank, für die die Größen abgerufen werden sollen.
Die Ausgabeparameter sind die folgenden:
-
subcluster_id(Text) — Die ID des Subclusters, zu dem dieser Prozess gehört. -
subcluster_type(text) — Der Typ des Subclusters, zu dem dieser Prozess gehört:routeroder.shard -
db_size— Die Größe der Datenbank in diesem Subcluster in Byte.
Das folgende Beispiel zeigt, wie die
limitless_stat_database_sizeFunktion verwendet wird.SELECT * FROM rds_aurora.limitless_stat_database_size('postgres_limitless'); subcluster_id | subcluster_type | db_size ---------------+-----------------+---------- 1 | router | 8895919 2 | router | 8904111 3 | shard | 21929391 4 | shard | 21913007 5 | shard | 21831087 (5 rows) -
- limitless_stat_get_snapshot_timestamp
-
Die
limitless_stat_get_snapshot_timestampFunktion gibt den Zeitstempel des aktuellen Statistik-Snapshots zurück, oder wenn kein Statistik-Snapshot erstellt wurde.NULLEin Snapshot wird erstellt, wenn in einer Transaktion zum ersten Mal auf kumulative Statistiken zugegriffen wird, sofern dieser Wert auf gesetztstats_fetch_consistencyist.snapshotGibt eine konsolidierte Ansicht der Snapshot-Zeitstempel von allen Knoten zurück. Diesubcluster_typeSpaltensubcluster_idund zeigen, von welchem Knoten die Daten stammen.Das folgende Beispiel zeigt, wie die
limitless_stat_get_snapshot_timestampFunktion verwendet wird.SELECT * FROM rds_aurora.limitless_stat_get_snapshot_timestamp(); subcluster_id | subcluster_type | snapshot_timestamp ---------------+-----------------+-------------------- 1 | router | 2 | router | 3 | shard | 4 | shard | 5 | shard | (5 rows) - limitless_stat_prepared_xacts
-
Die
limitless_stat_prepared_xactsFunktion gibt Informationen über Transaktionen auf allen Knoten zurück, die derzeit für ein zweiphasiges Commit vorbereitet sind. Weitere Informationen finden Sie unter pg_prepared_xactsin der Postgre-Dokumentation. SQL Das folgende Beispiel zeigt, wie die Funktion verwendet wird.
limitless_stat_prepared_xactspostgres_limitless=> SELECT * FROM rds_aurora.limitless_stat_prepared_xacts; subcluster_id | subcluster_type | transaction_id | gid | prepared | owner_id | database_id ---------------+-----------------+----------------+------------------------------+-------------------------------+------------+-------------------- 8 | shard | 5815978 | 7_4599899_postgres_limitless | 2024-09-03 15:51:17.659603+00 | auroraperf | postgres_limitless 12 | shard | 4599138 | 7_4599899_postgres_limitless | 2024-09-03 15:51:17.659637+00 | auroraperf | postgres_limitless (2 rows) - limitless_stat_relation_sizes
-
Die
limitless_stat_relation_sizesFunktion gibt die verschiedenen Größen einer Tabelle in der DB-Shard-Gruppe zurück.Die Eingabeparameter sind die folgenden:
-
relnspname(Name) — Der Name des Schemas, das die Tabelle enthält. -
relname(Name) — Der Name der Tabelle.
Die Ausgabeparameter sind die folgenden:
-
subcluster_id(Text) — Die ID des Subclusters, zu dem dieser Prozess gehört. -
subcluster_type(text) — Der Typ des Subclusters, zu dem dieser Prozess gehört:routeroder.shard -
main_size— Die Größe des Haupt-Datenzweigs in diesem Knoten in Byte. -
fsm_size— Die Größe der Freiraumkarte für die Tabelle in diesem Knoten in Byte. -
vm_size— Die Größe der Sichtbarkeitskarte für die Tabelle in diesem Knoten in Byte. -
init_size— Die Größe der Initialisierung der Tabelle in diesem Knoten in Byte. -
toast_size— Die Größe der Toast-Tabelle in Byte, die der Tabelle in diesem Fork zugeordnet ist. -
index_size— Die Größe aller Indizes für die Tabelle in diesem Knoten in Byte. -
total_size— Die Größe aller Tabellensegmente in diesem Knoten in Byte.
Das folgende Beispiel zeigt, wie die
limitless_stat_relation_sizesFunktion verwendet wird (einige Spalten werden weggelassen).SELECT * FROM rds_aurora.limitless_stat_relation_sizes('public','customers'); subcluster_id | subcluster_type | main_size | fsm_size | vm_size | toast_size | table_size | total_size ---------------+-----------------+-----------+----------+---------+------------+------------+------------ 1 | router | 0 | 0 | 0 | 0 | 0 | 0 2 | router | 0 | 0 | 0 | 0 | 0 | 0 3 | shard | 4169728 | 4177920 | 1392640 | 1392640 | 11132928 | 11132928 4 | shard | 4169728 | 4177920 | 1392640 | 1392640 | 11132928 | 11132928 5 | shard | 3981312 | 4227072 | 1409024 | 1409024 | 11026432 | 11026432 (5 rows) -
- limitless_stat_reset
-
Die
limitless_stat_resetFunktion setzt alle Statistikzähler für die aktuelle Datenbank auf Null (0) zurück. Wenn diese Option aktivierttrack_functionsist,limitless_stat_databasezeigt diestats_resetSpalte in an, wann die Statistiken für die Datenbank zuletzt zurückgesetzt wurden.limitless_stat_resetKann standardmäßig nur von einem Superuser ausgeführt werden. Anderen Benutzern kann die Berechtigung erteilt werden, indem sie dieseEXECUTEBerechtigung verwenden.Das folgende Beispiel zeigt, wie die
limitless_stat_resetFunktion verwendet wird.SELECT tup_inserted, tup_deleted FROM pg_stat_database WHERE datname = 'postgres_limitless'; tup_inserted | tup_deleted --------------+------------- 896 | 0 (1 row) SELECT rds_aurora.limitless_stat_reset(); limitless_stat_reset --------------------- (1 row) SELECT tup_inserted, tup_deleted FROM pg_stat_database WHERE datname = 'postgres_limitless'; tup_inserted | tup_deleted -------------+------------- 0 | 0 (1 row) - limitless_stat_statements_reset
-
Die
limitless_stat_statements_resetFunktion verwirft Statistiken, die bisher gesammelt wurden, indem sie den angegebenen,, und Parameternlimitless_stat_statementsentsprechen.usernamedbnamedistributed_query_idqueryidWenn keiner der Parameter angegeben ist, wird für jeden Parameter der Standardwert""oder0(ungültig) verwendet, und die Statistiken, die mit anderen Parametern übereinstimmen, werden zurückgesetzt. Wenn kein Parameter angegeben ist oder alle angegebenen Parameter""oder0(ungültig) sind, verwirft die Funktion alle Statistiken. Wenn alle Statistiken in derlimitless_stat_statementsAnsicht verworfen werden, setzt die Funktion auch die Statistiken in der Ansicht zurück.limitless_stat_statements_infoDie Eingabeparameter sind die folgenden:
-
username(Name) — Der Benutzer, der die Anweisung abgefragt hat. -
dbname(Name) — Die Datenbank, in der die Abfrage ausgeführt wurde. -
distributed_query_id(bigint) — Die Abfrage-ID der übergeordneten Abfrage vom Koordinatorknoten. Diese Spalte gibt an,NULLob es sich um die übergeordnete Abfrage handelt. Der Koordinatorknoten gibt die ID der verteilten Abfrage an die teilnehmenden Knoten weiter. Für die Teilnehmerknoten sind die Werte für die ID der verteilten Abfrage und die Abfrage-ID also unterschiedlich. -
queryid(bigint) — Die Abfrage-ID der Anweisung.
Das folgende Beispiel zeigt, wie die
limitless_stat_statements_resetFunktion verwendet wird, um alle vonlimitless_stat_statementsgesammelten Statistiken zurückzusetzen.SELECT rds_aurora.limitless_stat_statements_reset(); -
- limitless_stat_system_waits
-
Die
limitless_stat_system_waitsFunktion gibt eine konsolidierte Ansicht der Warteereignisdaten von allen Knoten zurückaurora_stat_system_waits, in der systemweite Warteaktivitäten in einer Instanz gemeldet werden. Diesubcluster_typeSpaltensubcluster_idund zeigen, von welchem Knoten die Daten stammen.Das folgende Beispiel zeigt, wie die
limitless_stat_system_waitsFunktion verwendet wird.postgres_limitless=> SELECT * FROM rds_aurora.limitless_stat_system_waits() lssw, pg_catalog.aurora_stat_wait_event() aswe WHERE lssw.event_id=aswe.event_id and aswe.event_name='LimitlessTaskScheduler'; subcluster_id | subcluster_type | type_id | event_id | waits | wait_time | event_name ---------------+-----------------+---------+-----------+--------+--------------+------------------------ 1 | router | 12 | 201326607 | 677068 | 616942216307 | LimitlessTaskScheduler 2 | router | 12 | 201326607 | 678586 | 616939897111 | LimitlessTaskScheduler 3 | shard | 12 | 201326607 | 756640 | 616965545172 | LimitlessTaskScheduler 4 | shard | 12 | 201326607 | 755184 | 616958057620 | LimitlessTaskScheduler 5 | shard | 12 | 201326607 | 757522 | 616963183539 | LimitlessTaskScheduler (5 rows) - limitless_terminate_session
-
Die
limitless_terminate_sessionFunktion funktioniert ähnlich wie, versucht aberpg_terminate_backend, alle Backend-Prozesse, die sich auf die angegebene verteilte Sitzungs-ID beziehen, durch Senden eines (Endsignals) zu beenden.SIGTERMDer Eingabeparameter ist der folgende:
-
distributed_session_id(Text) — Die ID der verteilten Sitzung, die beendet werden soll.
Die Ausgabeparameter sind die folgenden:
-
subcluster_id(Text) — Die ID des Subclusters, zu dem dieser Prozess gehört. -
pid(text) — Die Backend-Prozess-ID. -
success(boolean) — Ob der Prozess erfolgreich beendet wurde.
Das folgende Beispiel zeigt, wie die Funktion verwendet wird
limitless_terminate_session.SELECT * FROM rds_aurora.limitless_terminate_session('940CD5C81E3C796B'); subcluster_id | pid | success ---------------+-------+--------- 1 | 26920 | t (1 row) -
- limitless_wait_report
-
Die
limitless_wait_reportFunktion gibt die Aktivität des Warteereignisses über einen bestimmten Zeitraum von allen Knoten zurück. Diesubcluster_typeSpaltensubcluster_idund zeigen, von welchem Knoten die Daten stammen.Die Ausgabeparameter sind die folgenden:
-
subcluster_id(Text) — Die ID des Subclusters, zu dem dieser Prozess gehört. -
subcluster_type(text) — Der Typ des Subclusters, zu dem dieser Prozess gehört:routeroder.shard
Die restlichen Spalten sind dieselben wie in
aurora_wait_report.Das folgende Beispiel zeigt, wie die
limitless_wait_reportFunktion verwendet wird.postgres_limitless=> select * from rds_aurora.limitless_wait_report(); subcluster_id | subcluster_type | type_name | event_name | waits | wait_time | ms_per_wait | waits_per_xact | ms_per_xact ---------------+-----------------+-----------+------------+-------+-----------+-------------+--------------- +------------- 1 | router | Client | ClientRead | 57 | 741550.14 | 13009.652 | 0.19 | 2505.237 5 | shard | Client | ClientRead | 54 | 738897.68 | 13683.290 | 0.18 | 2496.276 4 | shard | Client | ClientRead | 54 | 738859.53 | 13682.584 | 0.18 | 2496.147 2 | router | Client | ClientRead | 53 | 719223.64 | 13570.257 | 0.18 | 2429.810 3 | shard | Client | ClientRead | 54 | 461720.40 | 8550.378 | 0.18 | 1559.86 -