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.
# Häufige DBA-Aufgaben für Amazon RDS für PostgreSQL
Datenbankadministratoren (DBAs) führen bei der Verwaltung einer Amazon RDS for PostgreSQL PostgreSQL-DB-Instance eine Vielzahl von Aufgaben aus. Wenn Sie als DBA bereits mit PostgreSQL vertraut sind, müssen Sie sich einige wichtige Unterschiede zwischen dem Ausführen von PostgreSQL auf Ihrer Hardware und RDS für PostgreSQL beachten. Da es sich beispielsweise um einen verwalteten Service handelt, lässt Amazon RDS keinen Shell-Zugriff auf Ihre DB-Instances zu. Das bedeutet, dass Sie keinen direkten Zugriff auf `pg_hba.conf` und andere Konfigurationsdateien haben. Bei RDS für PostgreSQL werden Änderungen, die normalerweise an der PostgreSQL-Konfigurationsdatei einer lokalen Instance vorgenommen werden, an einer benutzerdefinierten DB-Parametergruppe vorgenommen, die der DB-Instance von RDS für PostgreSQL zugeordnet ist. Weitere Informationen finden Sie unter [Parametergruppen für Amazon RDS](USER_WorkingWithParamGroups.md).
Darüber hinaus können Sie nicht auf die gleiche Weise auf Protokolldateien zugreifen wie mit einer lokalen PostgreSQL-Instance. Weitere Informationen zur Protokollierung finden Sie unter [ RDS für PostgreSQL-Datenbankprotokolldateien](USER_LogAccess.Concepts.PostgreSQL.md).
Sie haben beispielsweise auch keinen Zugriff auf das `superuser`-Konto von PostgreSQL. Bei RDS für PostgreSQL ist die `rds_superuser`-Rolle diejenige mit den meisten Berechtigungen und wird `postgres` zum Zeitpunkt der Einrichtung gewährt. Unabhängig davon, ob Sie mit der On-Premises-Verwendung von PostgreSQL vertraut sind oder Neueinsteiger bei RDS für PostgreSQL sind, empfehlen wir Ihnen, sich mit der `rds_superuser`-Rolle und dem Umgang mit Rollen, Benutzern, Gruppen und Berechtigungen vertraut zu machen. Weitere Informationen finden Sie unter [Grundlegendes zu PostgreSQL-Rollen und -Berechtigungen](Appendix.PostgreSQL.CommonDBATasks.Roles.md).
Im Folgenden sind einige häufige DBA-Aufgaben für RDS für PostgreSQL aufgeführt.
**Topics**
+ [Kollationen, die in unterstützt werden](PostgreSQL-Collations.md)
+ [Grundlegendes zu PostgreSQL-Rollen und -Berechtigungen](Appendix.PostgreSQL.CommonDBATasks.Roles.md)
+ [Behandeln von inaktiven Verbindungen in PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.DeadConnectionHandling.md)
+ [Arbeiten mit der PostgreSQL-Selbstbereinigung in Amazon RDS für PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.md)
+ [Verwaltung hoher Objektzahlen in Amazon RDS for PostgreSQL Aurora PostgreSQL](PostgreSQL.HighObjectCount.md)
+ [](Appendix.PostgreSQL.CommonDBATasks.TOAST_OID.md)
+ [Arbeiten mit Protokollierungsmechanismen, die von RDS für PostgreSQL unterstützt werden](#Appendix.PostgreSQL.CommonDBATasks.Auditing)
+ [Verwalten temporärer Dateien mit PostgreSQL](PostgreSQL.ManagingTempFiles.md)
+ [Verwenden von pgBadger für die Protokollanalyse mit PostgreSQL](#Appendix.PostgreSQL.CommonDBATasks.Badger)
+ [PGSnapper Für die Überwachung von PostgreSQL verwenden](#Appendix.PostgreSQL.CommonDBATasks.Snapper)
+ [](PostgreSQL.CustomCasts.md)
+ [Bewährte Methoden für parallele Abfragen in](PostgreSQL.ParallelQueries.md)
+ [Arbeiten mit Parametern auf der DB-Instance von RDS for PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Parameters.md)
# Kollationen, die in unterstützt werden
Sortierungen sind eine Reihe von Regeln, die bestimmen, wie in der Datenbank gespeicherte Zeichenfolgen sortiert und verglichen werden. Sortierungen spielen eine grundlegende Rolle im Computersystem und sind Teil des Betriebssystems. Sortierungen ändern sich im Laufe der Zeit, wenn neue Zeichen zu Sprachen hinzugefügt werden oder wenn sich die Sortierregeln ändern.
Sortierungsbibliotheken definieren spezifische Regeln und Algorithmen für eine Sortierung. Die beliebtesten Sortierungsbibliotheken, die in PostgreSQL verwendet werden, sind GNU C (glibc) und Internationalization Components for Unicode (ICU). Standardmäßig verwendet RDS für PostgreSQL die Glibc-Sortierung, die Unicode-Zeichensortierreihenfolgen für Multibyte-Zeichensequenzen enthält.
Wenn Sie eine neue DB-Instance in RDS für PostgreSQL erstellen, wird das Betriebssystem auf die verfügbare Sortierung überprüft. Die PostgreSQL-Parameter des `CREATE DATABASE`-Befehls `LC_COLLATE` und `LC_CTYPE` werden verwendet, um eine Sortierung anzugeben, die in dieser Datenbank als Standardsortierung gilt. Alternativ können Sie auch den Parameter `LOCALE` in `CREATE DATABASE` verwenden, um diese Parameter festzulegen. Dieser bestimmt die Standardsortierung für Zeichenfolgen in der Datenbank und die Regeln für die Klassifizierung von Zeichen als Buchstaben, Zahlen oder Symbole. Sie können auch eine Sortierung auswählen, die für eine Spalte, einen Index oder eine Abfrage verwendet werden soll.
RDS für PostgreSQL benötigt für die Sortierungsunterstützung die Glibc-Bibliothek im Betriebssystem. Die Instance von RDS für PostgreSQL wird regelmäßig mit den neuesten Versionen des Betriebssystems aktualisiert. Diese Updates umfassen manchmal eine neuere Version der Glibc-Bibliothek. In seltenen Fällen ändern neuere Versionen von Glibc die Sortierreihenfolge oder Sortierung einiger Zeichen, was dazu führen kann, dass die Daten anders sortiert werden oder ungültige Indexeinträge entstehen. Wenn Sie während eines Updates bei der Sortierung Probleme mit der Sortierreihenfolge feststellen, müssen Sie möglicherweise die Indizes neu erstellen.
Damit mögliche Auswirkungen der Glibc-Updates reduziert werden, enthält RDS für PostgreSQL jetzt eine unabhängige Standard-Sortierungsbibliothek. Diese Sortierungsbibliothek ist in RDS für PostgreSQL 14.6, 13.9, 12.13, 11.18, 10.23 und neueren Nebenversionen verfügbar. Sie ist mit Glibc 2.26-59.amzn2 kompatibel und bietet eine stabile Sortierreihenfolge, um falsche Abfrageergebnisse zu verhindern.
# Grundlegendes zu PostgreSQL-Rollen und -Berechtigungen
Wenn Sie mit dem eine for PostgreSQL-DB-Instance erstellen AWS-Managementkonsole, wird gleichzeitig ein Administratorkonto erstellt. Der Name lautet standardmäßig `postgres`, wie im folgenden Screenshot gezeigt:
![\[Die Standardanmelde-Identität für Anmeldeinformationen auf der Seite Create database (Datenbank erstellen) lautet postgres.\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/UserGuide/images/default-login-identity-apg-rpg.png)
Sie können einen anderen Namen auswählen, anstatt den Standard (`postgres`) beizubehalten. In diesem Fall muss der von Ihnen gewählte Name mit einem Buchstaben beginnen und zwischen 1 und 16 alphanumerische Zeichen umfassen. Der Einfachheit halber verwenden wir für das Hauptbenutzerkonto den Standardwert (`postgres`) in diesem Handbuch.
Wenn Sie den `create-db-instance` AWS CLI anstelle von verwenden, erstellen Sie den Namen AWS-Managementkonsole, indem Sie ihn zusammen mit dem `master-username` Parameter im Befehl übergeben. Weitere Informationen finden Sie unter [Erstellen einer Amazon-RDS-DB-Instance](USER_CreateDBInstance.md).
Unabhängig davon AWS-Managementkonsole, ob Sie die AWS CLI, oder die Amazon RDS-API verwenden und ob Sie den `postgres` Standardnamen verwenden oder einen anderen Namen wählen, ist dieses erste Datenbankbenutzerkonto Mitglied der `rds_superuser` Gruppe und verfügt über `rds_superuser` Berechtigungen.
**Topics**
+ [Die Rolle „rds\$1superuser“ verstehen](Appendix.PostgreSQL.CommonDBATasks.Roles.rds_superuser.md)
+ [Steuern des Benutzerzugriffs auf die PostgreSQL−Datenbank](Appendix.PostgreSQL.CommonDBATasks.Access.md)
+ [Delegieren und Steuern der Benutzerpasswortverwaltung](Appendix.PostgreSQL.CommonDBATasks.RestrictPasswordMgmt.md)
+ [Verwenden von SCRAM für die PostgreSQL-Passwortverschlüsselung](PostgreSQL_Password_Encryption_configuration.md)
# Die Rolle „rds\$1superuser“ verstehen
In PostgreSQL kann eine *Rolle* einen Benutzer, eine Gruppe oder einen Satz bestimmter Berechtigungen definieren, die einer Gruppe oder einem Benutzer für verschiedene Objekte in der Datenbank gewährt werden. PostgreSQL-Befehle für `CREATE USER` und `CREATE GROUP` wurden durch den allgemeineren Befehl `CREATE ROLE` mit bestimmten Eigenschaften zur Unterscheidung von Datenbankbenutzern ersetzt. Einen Datenbankbenutzer kann man sich als Rolle mit der LOGIN-Berechtigung vorstellen.
**Anmerkung**
Die Befehle `CREATE USER` und `CREATE GROUP` können weiterhin verwendet werden. Weitere Informationen dazu finden Sie im Abschnitt [Datenbankrollen](https://www.postgresql.org/docs/current/user-manag.html) der PostgreSQL-Dokumentation.
Der `postgres`-Benutzer ist der Datenbankbenutzer mit den meisten Berechtigungen auf Ihrer RDS-for-PostgreSQL-DB-Instance. Er verfügt über die Eigenschaften, die durch die folgende `CREATE ROLE`-Anweisung definiert sind.
```
CREATE ROLE postgres WITH LOGIN NOSUPERUSER INHERIT CREATEDB CREATEROLE NOREPLICATION VALID UNTIL 'infinity'
```
Die Eigenschaften `NOSUPERUSER`, `NOREPLICATION`, `INHERIT` und `VALID UNTIL 'infinity'` sind die Standardoptionen für CREATE ROLE, sofern nicht anders angegeben.
Standardmäßig verfügt `postgres` über Berechtigungen, die der `rds_superuser`-Rolle gewährt wurden, und über Berechtigungen zum Erstellen von Rollen und Datenbanken. Die `rds_superuser`-Rolle erlaubt dem `postgres`-Benutzer, folgende Aktionen auszuführen:
+ Erweiterungen für die Verwendung mit Amazon RDS hinzufügen. Weitere Informationen finden Sie unter [Arbeiten mit PostgreSQL-Funktionen, die von Amazon RDS für PostgreSQL unterstützt werden](PostgreSQL.Concepts.General.FeatureSupport.md)
+ Rollen für Benutzer erstellen und Benutzern Berechtigungen gewähren. Weitere Informationen dazu finden Sie im Abschnitt [CREATE ROLE](https://www.postgresql.org/docs/current/sql-createrole.html) und [GRANT](https://www.postgresql.org/docs/14/sql-grant.html) der PostgreSQL-Dokumentation.
+ Datenbanken erstellen. Weitere Informationen finden Sie im Abschnitt [CREATE DATABASE](https://www.postgresql.org/docs/14/sql-createdatabase.html) der PostgreSQL-Dokumentation.
+ Gewähren Sie `rds_superuser`-Berechtigungen anderen Benutzerrollen, die nicht über diese Berechtigungen verfügen, und widerrufen Sie diese Berechtigungen bei Bedarf. Es wird empfohlen, diese Rolle nur denjenigen Benutzern zu gewähren, die Superuser-Aufgaben ausführen. Mit anderen Worten, Sie können diese Rolle Datenbankadministratoren (DBAs) oder Systemadministratoren zuweisen.
+ Die `rds_replication`-Rolle Datenbankbenutzern gewähren (oder entziehen), die nicht über die `rds_superuser`-Rolle verfügen.
+ Die `rds_password`-Rolle Datenbankbenutzern gewähren (oder entziehen), die nicht über die `rds_superuser`-Rolle verfügen.
+ Statusinformationen über alle Datenbankverbindungen über die Ansicht `pg_stat_activity` abrufen. Bei Bedarf kann `rds_superuser` alle Verbindungen mit `pg_terminate_backend` oder `pg_cancel_backend` stoppen.
In der `CREATE ROLE postgres...`-Anweisung können Sie sehen, dass die `postgres`-Benutzerrolle PostgreSQL ausdrücklich `superuser`-Berechtigungen verweigert. RDS für PostgreSQL ist ein verwalteter Service, sodass Sie nicht auf das Host-Betriebssystem zugreifen können und keine Verbindung mit dem `superuser`-PostgreSQL-Konto herstellen können. Viele der Aufgaben, die `superuser`-Zugriff auf einem eigenständigem PostgreSQL erfordern, werden von Amazon RDS automatisch verwaltet.
Weitere Informationen zum Gewähren von Berechtigungen finden Sie unter [GRANT](http://www.postgresql.org/docs/current/sql-grant.html) in der PostgreSQL-Dokumentation.
Die `rds_superuser`-Rolle ist eine von mehreren *vordefinierten* Rollen in einem . DB-Instance von RDS für PostgreSQL
**Anmerkung**
In PostgreSQL 13 und früheren Versionen werden *vordefinierte Rollen* als *Standardrollen* bezeichnet.
In der folgenden Liste finden Sie einige der anderen vordefinierten Rollen, die automatisch für einen neuen erstellt werden. DB-Instance von RDS für PostgreSQL Vordefinierte Rollen und ihre Berechtigungen können nicht geändert werden. Sie können Berechtigungen für diese vordefinierten Rollen nicht löschen, umbenennen oder ändern. Jeder entsprechende Versuch führt zu einem Fehler.
+ **rds\$1passwort** – Eine Rolle, die Passwörter ändern und Passwortbeschränkungen für Datenbankbenutzer einrichten kann. Die `rds_superuser`-Rolle erhält diese Rolle standardmäßig und kann die Rolle Datenbankbenutzern gewähren. Weitere Informationen finden Sie unter [Steuern des Benutzerzugriffs auf die PostgreSQL−DatenbankSteuern des Benutzerzugriffs auf PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Access.md).
+ In Versionen von RDS für PostgreSQL, die höher sind als 14, kann die `rds_password`-Rolle Passwörter ändern und Passwortbeschränkungen für Datenbankbenutzer und Benutzer mit der `rds_superuser`-Rolle einrichten. Ab Version 14 und höher von RDS für PostgreSQL kann die `rds_password`-Rolle Passwörter ändern und Passwortbeschränkungen nur für Datenbankbenutzer einrichten. Nur Benutzer mit der `rds_superuser`-Rolle können diese Aktionen für andere Benutzer mit der `rds_superuser`-Rolle ausführen.
+ **rdsadmin** – Eine Rolle, die erstellt wurde, um viele der Verwaltungsaufgaben zu erledigen, die der Administrator mit `superuser`-Berechtigungen für eine eigenständige PostgreSQL-Datenbank ausführt. Diese Rolle wird intern von RDS für PostgreSQL für viele Verwaltungsaufgaben verwendet.
+ **rdstopmgr** – Eine Rolle, die intern von Amazon RDS zur Unterstützung von Multi-AZ-Bereitstellungen verwendet wird.
+ **rds\$1reserved** – Dies ist eine Rolle, die intern von Amazon RDS verwendet wird, um Datenbankverbindungen zu reservieren.
# Anzeigen von Rollen und deren Berechtigungen
Sie können vordefinierte Rollen und deren Berechtigungen in Ihrer DB-Instance von RDS für PostgreSQL je nach PostgreSQL-Version mit unterschiedlichen Befehlen anzeigen. Wenn Sie alle vordefinierten Rollen anzeigen möchten, können Sie eine Verbindung zu Ihrer DB-Instance von RDS für PostgreSQL herstellen und die folgenden Befehle mit `psql` ausführen.
**Für `psql` 15 und frühere Versionen**
Stellen Sie eine Verbindung zu Ihrer DB-Instance von RDS für PostgreSQL her und verwenden Sie den `\du`-Befehl in psql:
```
postgres=> \du
List of roles
Role name | Attributes | Member of
-----------------+------------------------------------------------------------+------------------------------------------------------
postgres | Create role, Create DB +| {rds_superuser}
| Password valid until infinity |
rds_ad | Cannot login | {}
rds_iam | Cannot login | {}
rds_password | Cannot login | {}
rds_replication | Cannot login | {}
rds_superuser | Cannot login | {pg_monitor,pg_signal_backend,rds_password,rds_replication}
rdsadmin | Superuser, Create role, Create DB, Replication, Bypass RLS+| {}
| Password valid until infinity |
```
**Für `psql` 16 und höhere Versionen**
```
postgres=> \drg+
List of role grants
Role name | Member of | Options | Grantor
---------------+-----------------------------+---------------------+----------
postgres | rds_superuser | INHERIT, SET | rdsadmin
rds_superuser | pg_checkpoint | ADMIN, INHERIT, SET | rdsadmin
rds_superuser | pg_monitor | ADMIN, INHERIT, SET | rdsadmin
rds_superuser | pg_signal_backend | ADMIN, INHERIT, SET | rdsadmin
rds_superuser | pg_use_reserved_connections | ADMIN, INHERIT, SET | rdsadmin
rds_superuser | rds_password | ADMIN, INHERIT, SET | rdsadmin
rds_superuser | rds_replication | ADMIN, INHERIT, SET | rdsadmin
```
Wenn Sie die Rollenmitgliedschaft ohne Versionsabhängigkeit überprüfen möchten, können Sie die folgende SQL-Abfrage verwenden:
```
SELECT m.rolname AS "Role name", r.rolname AS "Member of"
FROM pg_catalog.pg_roles m
JOIN pg_catalog.pg_auth_members pam ON (pam.member = m.oid)
LEFT JOIN pg_catalog.pg_roles r ON (pam.roleid = r.oid)
LEFT JOIN pg_catalog.pg_roles g ON (pam.grantor = g.oid)
WHERE m.rolname !~ '^pg_'
ORDER BY 1, 2;
```
In der Ausgabe sehen Sie, dass `rds_superuser` keine Datenbankbenutzerrolle ist (sie kann sich nicht anmelden), aber über die Berechtigungen vieler anderer Rollen verfügt. Sie können auch sehen, dass dieser Datenbankbenutzer `postgres` Mitglied der `rds_superuser`-Rolle ist. Wie bereits erwähnt, ist `postgres` der Standardwert auf der Seite **Create database** (Datenbank erstellen) der Amazon-RDS-Konsole. Wenn Sie einen anderen Namen gewählt haben, wird dieser Name stattdessen in der Rollenliste angezeigt.
# Steuern des Benutzerzugriffs auf die PostgreSQL−Datenbank
Neue Datenbanken in PostgreSQL werden immer mit Standardberechtigungen im `public`-Schema der Datenbank erstellt, mit dem alle Datenbankbenutzer und -rollen Objekte erstellen können. Diese Berechtigungen ermöglichen es Datenbankbenutzern, eine Verbindung mit der Datenbank herzustellen und während der Verbindung temporäre Tabellen zu erstellen.
Es wird empfohlen, diese `public`-Standardberechtigungen zu widerrufen, um den Benutzerzugriff auf die Datenbank-Instances, die Sie auf Ihrer DB-Instance von RDS for PostgreSQL erstellen, besser kontrollieren können. Danach erteilen Sie Datenbankbenutzern auf einer detaillierteren Basis spezifische Berechtigungen, wie im Folgenden gezeigt.
**So richten Sie Rollen und Berechtigungen für eine neue Datenbank-Instance ein**
Angenommen, Sie richten eine Datenbank für eine neu erstellte DB-Instance von RDS for PostgreSQL ein, die von mehreren Forschenden verwendet wird, die alle Lese-/Schreibzugriff auf die Datenbank benötigen.
1. Verwenden Sie `psql` (oder pgAdmin) zum Herstellen einer Verbindung mit Ihrer DB-Instance von RDS for PostgreSQL:
```
psql --host=your-db-instance.666666666666.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password
```
Geben Sie bei der Aufforderung Ihr Passwort ein. Der `psql`-Client verbindet und zeigt die standardmäßige administrative Verbindungsdatenbank `postgres=>` als Eingabeaufforderung an.
1. Gehen Sie wie folgt vor, um zu verhindern, dass Datenbankbenutzer Objekte im `public`-Schema erstellen:
```
postgres=> REVOKE CREATE ON SCHEMA public FROM PUBLIC;
REVOKE
```
1. Als Nächstes erstellen Sie eine neue Datenbank-Instance:
```
postgres=> CREATE DATABASE lab_db;
CREATE DATABASE
```
1. Widerrufen Sie alle Berechtigungen aus dem `PUBLIC`-Schema in dieser neuen Datenbank.
```
postgres=> REVOKE ALL ON DATABASE lab_db FROM public;
REVOKE
```
1. Erstellen Sie eine Rolle für Datenbankbenutzer.
```
postgres=> CREATE ROLE lab_tech;
CREATE ROLE
```
1. Geben Sie Datenbankbenutzern mit dieser Rolle die Möglichkeit, eine Verbindung mit der Datenbank herzustellen.
```
postgres=> GRANT CONNECT ON DATABASE lab_db TO lab_tech;
GRANT
```
1. Gewähren Sie allen Benutzern mit der `lab_tech`-Rolle alle Berechtigungen für diese Datenbank.
```
postgres=> GRANT ALL PRIVILEGES ON DATABASE lab_db TO lab_tech;
GRANT
```
1. Erstellen Sie Datenbankbenutzer wie folgt:
```
postgres=> CREATE ROLE lab_user1 LOGIN PASSWORD 'change_me';
CREATE ROLE
postgres=> CREATE ROLE lab_user2 LOGIN PASSWORD 'change_me';
CREATE ROLE
```
1. Gewähren Sie diesen beiden Benutzern die Berechtigungen, die mit der lab\$1tech-Rolle verknüpft sind:
```
postgres=> GRANT lab_tech TO lab_user1;
GRANT ROLE
postgres=> GRANT lab_tech TO lab_user2;
GRANT ROLE
```
An dieser Stelle können `lab_user1` und `lab_user2` eine Verbindung mit der `lab_db`-Datenbank herstellen. Dieses Beispiel folgt nicht den bewährten Methoden für den Unternehmensgebrauch, darunter das Erstellen mehrerer Datenbank-Instances, verschiedener Schemas und das Erteilen eingeschränkter Berechtigungen. Umfassende Informationen und zusätzliche Szenarien finden Sie unter [Verwalten von PostgreSQL-Benutzern und -Rollen](https://aws.amazon.com/blogs//database/managing-postgresql-users-and-roles/).
Weitere Informationen zu Berechtigungen in PostgreSQL-Datenbanken finden Sie unter dem Befehl [GRANT](https://www.postgresql.org/docs/current/static/sql-grant.html) in der PostgreSQL-Dokumentation.
# Delegieren und Steuern der Benutzerpasswortverwaltung
Als DBA sollten Sie ggf. die Verwaltung von Benutzerpasswörtern delegieren. Oder Sie möchten verhindern, dass Datenbankbenutzer ihre Passwörter ändern oder Passwortbeschränkungen wie die Lebensdauer des Passworts neu konfigurieren. Um sicherzustellen, dass nur die von Ihnen ausgewählten Datenbankbenutzer Passworteinstellungen ändern können, können Sie die Funktion zur eingeschränkten Passwortverwaltung aktivieren. Wenn Sie diese Funktion aktivieren, können nur die Datenbankbenutzer, denen die `rds_password`-Rolle gewährt wurde, Passwörter verwalten.
**Anmerkung**
Um die eingeschränkte Passwortverwaltung nutzen zu können, muss Ihre DB-Instance für RDS for PostgreSQL PostgreSQL 10.6 oder höher ausführen.
Standardmäßig lautet diese Funktion `off`, wie im Folgenden gezeigt:
```
postgres=> SHOW rds.restrict_password_commands;
rds.restrict_password_commands
--------------------------------
off
(1 row)
```
Zum Aktivieren dieser Funktion verwenden Sie eine benutzerdefinierte Parametergruppe und ändern die Einstellung für `rds.restrict_password_commands` in 1. Stellen Sie sicher, dass Sie Ihre DB-Instance von RDS for PostgreSQL neu starten, damit die Einstellung wirksam wird.
Wenn diese Funktion aktiv ist, werden für die folgenden SQL-Befehle `rds_password`-Berechtigungen benötigt:
```
CREATE ROLE myrole WITH PASSWORD 'mypassword';
CREATE ROLE myrole WITH PASSWORD 'mypassword' VALID UNTIL '2023-01-01';
ALTER ROLE myrole WITH PASSWORD 'mypassword' VALID UNTIL '2023-01-01';
ALTER ROLE myrole WITH PASSWORD 'mypassword';
ALTER ROLE myrole VALID UNTIL '2023-01-01';
ALTER ROLE myrole RENAME TO myrole2;
```
Das Umbenennen einer Rolle (`ALTER ROLE myrole RENAME TO newname`) ist ebenfalls eingeschränkt, wenn das Passwort den MD5 Hash-Algorithmus verwendet.
Wenn diese Funktion aktiv ist, generiert jeder Versuch, einen dieser SQL-Befehle ohne die `rds_password`-Rollenberechtigungen auszuführen, den folgenden Fehler:
```
ERROR: must be a member of rds_password to alter passwords
```
Wir empfehlen, dass Sie die `rds_password`-Berechtigung nur wenigen Rollen zuweisen, die Sie ausschließlich für die Passwortverwaltung verwenden. Wenn Sie `rds_password`-Berechtigungen für Datenbankbenutzer erteilen, die keine `rds_superuser`-Berechtigungen haben, müssen Sie ihnen auch das `CREATEROLE`-Attribut erteilen.
Stellen Sie sicher, dass Sie die Passwortanforderungen wie Ablaufdatum und erforderliche Komplexität auf Kundenseite überprüfen. Wenn Sie Ihr eigenes clientseitiges Dienstprogramm für passwortbezogene Änderungen verwenden, muss das Dienstprogramm Mitglied von `rds_password` sein und über `CREATE ROLE`-Berechtigungen verfügen.
# Verwenden von SCRAM für die PostgreSQL-Passwortverschlüsselung
Der *Salted Challenge Response Authentication Mechanism (SCRAM)* ist eine Alternative zum standardmäßigen Message Digest (MD5) -Algorithmus von PostgreSQL zur Verschlüsselung von Passwörtern. Der SCRAM-Authentifizierungsmechanismus gilt als sicherer als. MD5 Weitere Informationen zu diesen beiden verschiedenen Ansätzen zur Sicherung von Passwörtern finden Sie unter [Passwortauthentifizierung](https://www.postgresql.org/docs/14/auth-password.html) in der PostgreSQL-Dokumentation.
Wir empfehlen, SCRAM statt MD5 als Kennwortverschlüsselungsschema für Ihren zu verwenden. DB-Instance von RDS für PostgreSQL Es ist ein kryptografischer Challenge-Response-Mechanismus, der den scram–sha-256-Algorithmus zur Passwortauthentifizierung und -verschlüsselung nutzt.
Möglicherweise müssen Sie Bibliotheken aktualisieren, damit Ihre Clientanwendungen SCRAM unterstützen können. JDBC-Versionen vor 42.2.0 unterstützen SCRAM beispielsweise nicht. Weitere Informationen finden Sie unter [PostgreSQL-JDBC-Treiber](https://jdbc.postgresql.org/changelogs/2018-01-17-42.2.0-release/) in der Dokumentation zu PostgreSQL-JDBC-Treibern. Für eine Liste anderer PostgreSQL-Treiber und SCRAM-Unterstützung siehe die [Treiberliste](https://wiki.postgresql.org/wiki/List_of_drivers) in der PostgreSQL-Dokumentation.
RDS für PostgreSQL 13.1 und höhere Versionen unterstützen scram-sha-256. Mit diesen Versionen können Sie Ihre DB-Instance auch so konfigurieren, dass SCRAM erforderlich ist, wie in den folgenden Verfahren beschrieben.
## Einrichtung des RDS für die PostgreSQL-DB-Instance, die SCRAM benötigt
können Sie verlangen, dass der DB-Instance von RDS für PostgreSQL nur Passwörter akzeptiert, die den scram-sha-256-Algorithmus verwenden.
**Wichtig**
Wenn Sie bei vorhandenen RDS-Proxys mit PostgreSQL-Datenbanken die Datenbankauthentifizierung so ändern, dass nur `SCRAM` verwendet wird, ist der Proxy für bis zu 60 Sekunden nicht verfügbar. Um das Problem zu vermeiden, führen Sie einen der folgenden Schritte aus:
Stellen Sie sicher, dass die Datenbank sowohl die `SCRAM`- als auch die `MD5`-Authentifizierung zulässt.
Wenn Sie nur die `SCRAM`-Authentifizierung verwenden möchten, erstellen Sie einen neuen Proxy, migrieren Sie Ihren Anwendungsdatenverkehr auf den neuen Proxy und löschen Sie dann den zuvor mit der Datenbank verknüpften Proxy.
Bevor Sie Änderungen an Ihrem System vornehmen, vergewissern Sie sich, dass Sie den folgenden Prozess komplett verstehen:
+ Sammeln Sie Informationen über alle Rollen und Passwortverschlüsselung für alle Datenbankbenutzer.
+ Überprüfen Sie die Parametereinstellungen für Ihren DB-Instance von RDS für PostgreSQL für die Parameter, die die Passwortverschlüsselung steuern.
+ Wenn Ihr DB-Instance von RDS für PostgreSQL eine Standardparametergruppe verwendet, müssen Sie eine benutzerdefinierte DB-Parametergruppe erstellen und sie auf Ihren DB-Instance von RDS für PostgreSQL anwenden, damit Sie bei Bedarf Parameter ändern können. Wenn Ihr DB-Instance von RDS für PostgreSQL eine benutzerdefinierte Parametergruppe verwendet, können Sie die erforderlichen Parameter bei Bedarf später im Prozess ändern.
+ Ändern Sie den Parameter `password_encryption` in `scram-sha-256`.
+ Informieren Sie alle Datenbankbenutzer, dass sie ihre Passwörter aktualisieren müssen. Wiederholen Sie diesen Schritt für Ihr `postgres`-Konto. Die neuen Passwörter werden mit dem scram-sha-256-Algorithmus verschlüsselt und gespeichert.
+ Stellen Sie sicher, dass alle Passwörter mit diesem Verschlüsselungstyp verschlüsselt sind.
+ Wenn alle Passwörter scram-sha-256 verwenden, können Sie den `rds.accepted_password_auth_method`-Parameter von `md5+scram` in `scram-sha-256` ändern.
**Warnung**
Nachdem Sie `rds.accepted_password_auth_method` nur in scram-sha-256 geändert haben, können Benutzer (Rollen) mit `md5`-verschlüsselten Passwörtern keine Verbindung herstellen.
### Machen Sie sich bereit, SCRAM für Ihren ) zu benötigen
Bevor Sie Änderungen an Ihrem DB-Instance von RDS für PostgreSQL, vornehmen, überprüfen Sie alle vorhandenen Datenbankbenutzerkonten. Überprüfen Sie auch die Art der Verschlüsselung, die für Passwörter verwendet wird. Sie können für diese Aufgaben die `rds_tools`-Erweiterung verwenden. Weitere Informationen darüber, welche PostgreSQL-Versionen `rds_tools` unterstützen, finden Sie unter [Erweiterungsversionen für Amazon RDS für PostgreSQL](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-extensions.html).
**So erhalten Sie eine Liste der Datenbankbenutzer (Rollen) und Passwortverschlüsselungsmethoden**
1. Verwenden Sie `psql` zum Herstellen einer Verbindung mit Ihrer DB-Instance von RDS für PostgreSQL, wie im Folgenden gezeigt.
```
psql --host=db-name.111122223333.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password
```
1. Installieren Sie die `rds_tools`-Erweiterung.
```
postgres=> CREATE EXTENSION rds_tools;
CREATE EXTENSION
```
1. Rufen Sie eine Auflistung der Rollen und Verschlüsselungsmethoden ab.
```
postgres=> SELECT * FROM
rds_tools.role_password_encryption_type();
```
Die Ausgabe entspricht weitgehend der folgenden.
```
rolname | encryption_type
----------------------+-----------------
pg_monitor |
pg_read_all_settings |
pg_read_all_stats |
pg_stat_scan_tables |
pg_signal_backend |
lab_tester | md5
user_465 | md5
postgres | md5
(8 rows)
```
### Erstellen einer benutzerdefinierten DB-Parametergruppe
**Anmerkung**
Wenn Ihre DB-Instance von RDS für PostgreSQL bereits eine benutzerdefinierte Parametergruppe verwendet, müssen Sie keine neue erstellen.
Eine Übersicht über Parametergruppen für Amazon RDS finden Sie unter [Arbeiten mit Parametern auf der DB-Instance von RDS for PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Parameters.md).
Der für Passwörter verwendete Passwortverschlüsselungstyp wird in einem Parameter, `password_encryption`, festgelegt. Die Verschlüsselung, die der DB-Instance von RDS für PostgreSQL zulässt, wird in einem anderen Parameter, `rds.accepted_password_auth_method`, festgelegt. Wenn Sie den Standardwert eines dieser Parameter ändern, müssen Sie eine benutzerdefinierte DB-Parametergruppe erstellen und auf Ihre Instance anwenden.
Sie können auch die AWS-Managementkonsole oder die RDS-API verwenden, um eine benutzerdefinierte zu erstellen. Weitere Informationen finden Sie unter
Sie können jetzt die benutzerdefinierte Parametergruppe Ihrer DB-Instance zuordnen.
**Um eine benutzerdefinierte zu erstellen, DB-Parametergruppe**
1. Verwenden Sie den CLI-Befehl `[create-db-parameter-group](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-parameter-group.html) ` zum Erstellen der benutzerdefinierten DB-Parametergruppe. In diesem Beispiel wird `postgres13` als Quelle für diese benutzerdefinierte Parametergruppe verwendet.
Für Linux, macOS oder Unix:
```
aws rds create-db-parameter-group --db-parameter-group-name 'docs-lab-scram-passwords' \
--db-parameter-group-family postgres13 --description 'Custom parameter group for SCRAM'
```
Für Windows:
```
aws rds create-db-parameter-group --db-parameter-group-name "docs-lab-scram-passwords" ^
--db-parameter-group-family postgres13 --description "Custom DB parameter group for SCRAM"
```
1. Verwenden Sie den CLI-Befehl `[modify-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html)` zum Anwenden dieser benutzerdefinierten Parametergruppe auf Ihren DB-Cluster von RDS für PostgreSQL.
Für Linux, macOS oder Unix:
```
aws rds modify-db-instance --db-instance-identifier 'your-instance-name' \
--db-parameter-group-name "docs-lab-scram-passwords
```
Für Windows:
```
aws rds modify-db-instance --db-instance-identifier "your-instance-name" ^
--db-parameter-group-name "docs-lab-scram-passwords
```
Zum erneuten Synchronisieren Ihrer DB-Instance von RDS für PostgreSQL mit Ihrer benutzerdefinierten DB-Parametergruppe müssen Sie die primäre und alle anderen Instances des Clusters neu starten. Planen Sie dies während Ihres regulären Wartungsfensters, um die Auswirkungen auf Ihre Benutzer zu minimieren.
### Konfigurieren der Passwortverschlüsselung für die Verwendung von SCRAM
Der Passwortverschlüsselungsmechanismus, der von einer DB-Instance von RDS für PostgreSQL verwendet wird, ist in der DB-Parametergruppe auf den Parameter `password_encryption` festgelegt. Zulässige Werte sind keine Angabe, `md5` oder `scram-sha-256`. Der Standardwert hängt von der Version von RDS für PostgreSQL wie folgt ab:
+ RDS für PostgreSQL 14 und höher – Der Standardwert ist `scram-sha-256`.
+ RDS für PostgreSQL 13 – Der Standardwert ist `md5`.
Mit einer benutzerdefinierten DB-Parametergruppe, die Ihrer DB-Instance von RDS für PostgreSQL angefügt ist, können Sie die Werte für den Passwortverschlüsselungsparameter ändern.
![\[Im Folgenden zeigt die RDS-Konsole die Standardwerte für die password_encryption-Parameter für RDS für PostgreSQL.\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/UserGuide/images/rpg-pwd-encryption-md5-scram-1.png)
**So ändern Sie die Passwortverschlüsselungseinstellung in scram-sha-256**
+ Ändern Sie den Wert der Passwortverschlüsselung in scram-sha-256, wie nachfolgend gezeigt. Die Änderung kann sofort angewendet werden, da der Parameter dynamisch ist. Daher ist kein Neustart erforderlich, damit die Änderung wirksam wird.
Für Linux, macOS oder Unix:
```
aws rds modify-db-parameter-group --db-parameter-group-name \
'docs-lab-scram-passwords' --parameters 'ParameterName=password_encryption,ParameterValue=scram-sha-256,ApplyMethod=immediate'
```
Für Windows:
```
aws rds modify-db-parameter-group --db-parameter-group-name ^
"docs-lab-scram-passwords" --parameters "ParameterName=password_encryption,ParameterValue=scram-sha-256,ApplyMethod=immediate"
```
### Migrieren von Passwörtern für Benutzerrollen zu SCRAM
Sie können Passwörter für Benutzerrollen wie folgt zu SCRAM migrieren.
**Um Datenbankbenutzer- (Rollen-) Passwörter von MD5 zu SCRAM zu migrieren**
1. Melden Sie sich als Administratorbenutzer an (Standardbenutzer `postgres`), wie nachfolgend gezeigt.
```
psql --host=db-name.111122223333.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password
```
1. Überprüfen Sie die Einstellung des `password_encryption`-Parameters auf der DB-Instance von RDS für PostgreSQL mithilfe des folgenden Befehls.
```
postgres=> SHOW password_encryption;
password_encryption
---------------------
md5
(1 row)
```
1. Ändern Sie den Wert dieses Parameters in scram-sha-256. Weitere Informationen finden Sie unter [Konfigurieren der Passwortverschlüsselung für die Verwendung von SCRAM](#PostgreSQL_Password_Encryption_configuration.configure-password-encryption).
1. Überprüfen Sie den Wert erneut, um sicherzustellen, dass er jetzt auf `scram-sha-256` festgelegt ist. Gehen Sie dazu wie folgt vor.
```
postgres=> SHOW password_encryption;
password_encryption
---------------------
scram-sha-256
(1 row)
```
1. Bitten Sie alle Datenbankbenutzer, ihre Passwörter zu ändern. Stellen Sie sicher, dass Sie auch Ihr eigenes Passwort für das `postgres`-Konto ändern (der Datenbankbenutzer mit `rds_superuser`-Berechtigungen).
```
labdb=> ALTER ROLE postgres WITH LOGIN PASSWORD 'change_me';
ALTER ROLE
```
1. Wiederholen Sie den Vorgang für alle Datenbanken auf dem DB-Instance von RDS für PostgreSQL
### Ändern des Parameters, um SCRAM zu erfordern
Dies ist der letzte Schritt in diesem Prozess. Nachdem Sie die Änderung im folgenden Verfahren vorgenommen haben, können sich Benutzerkonten (Rollen), die nach wie vor die `md5`-Verschlüsselung für Passwörter verwenden, nicht beim anmelden. DB-Instance von RDS für PostgreSQL
Die `rds.accepted_password_auth_method` gibt die Verschlüsselungsmethode an, die die DB-Instance von RDS für PostgreSQL als Benutzerpasswort beim Anmeldevorgang akzeptiert. Der Standardwert ist `md5+scram`, was bedeutet, dass eine der beiden Methoden akzeptiert wird. Im folgenden Bild finden Sie die Standardeinstellung für diesen Parameter.
![\[Die RDS-Konsole, die die Standardwerte und die zulässigen Werte für den rds.accepted_password_auth_method-Parameter zeigt.\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/UserGuide/images/pwd-encryption-md5-scram-2.png)
Die zulässigen Werte für diesen Parameter sind `md5+scram` oder nur `scram`. Durch Ändern dieses Parameterwerts in `scram` wird er erforderlich.
**So ändern Sie den Parameterwert, sodass eine SCRAM-Authentifizierung für Passwörter erforderlich ist**
1. Stellen Sie sicher, dass alle Datenbank-Benutzerpasswörter für alle Datenbanken auf Ihrer DB-Instance von RDS für PostgreSQL `scram-sha-256` für die Passwortverschlüsselung verwenden. Fragen Sie hierzu `rds_tools` für die Rolle (Benutzer) und den Verschlüsselungstyp wie folgt ab.
```
postgres=> SELECT * FROM rds_tools.role_password_encryption_type();
rolname | encryption_type
----------------------+-----------------
pg_monitor |
pg_read_all_settings |
pg_read_all_stats |
pg_stat_scan_tables |
pg_signal_backend |
lab_tester | scram-sha-256
user_465 | scram-sha-256
postgres | scram-sha-256
( rows)
```
1. Wiederholen Sie die Abfrage auf allen DB-Instances Ihres DB-Instance von RDS für PostgreSQL
Wenn alle Passwörter scram-sha-256 verwenden, können Sie fortfahren.
1. Ändern Sie den Wert der akzeptierten Passwortauthentifizierung in scram-sha-256 wie folgt.
Für Linux, macOS oder Unix:
```
aws rds modify-db-parameter-group --db-parameter-group-name 'docs-lab-scram-passwords' \
--parameters 'ParameterName=rds.accepted_password_auth_method,ParameterValue=scram,ApplyMethod=immediate'
```
Für Windows:
```
aws rds modify-db-parameter-group --db-parameter-group-name "docs-lab-scram-passwords" ^
--parameters "ParameterName=rds.accepted_password_auth_method,ParameterValue=scram,ApplyMethod=immediate"
```
# Behandeln von inaktiven Verbindungen in PostgreSQL
Inaktive Verbindungen treten auf, wenn eine Datenbanksitzung auf dem Server aktiv bleibt, obwohl die Client-Anwendung abgebrochen oder auf ungewöhnliche Weise beendet wurde. Eine solche Situation entsteht in der Regel, wenn Client-Prozesse abstürzen oder unerwartet beendet werden, ohne dass ihre Datenbankverbindungen ordnungsgemäß geschlossen oder laufende Anfragen abgebrochen werden.
PostgreSQL identifiziert und bereinigt inaktive Verbindungen, wenn Serverprozesse inaktiv sind oder versuchen, Daten an Clients zu senden. Die Erkennung ist jedoch schwierig bei Sitzungen, die im Leerlauf sind, auf Eingaben vom Client warten oder Abfragen aktiv ausführen. Um diese Szenarien zu handhaben, stellt PostgreSQL die Parameter `tcp_keepalives_*`, `tcp_user_timeout` und `client_connection_check_interval` bereit.
**Topics**
+ [Grundlagen zu TCP-Keepalive](#Appendix.PostgreSQL.CommonDBATasks.DeadConnectionHandling.Understanding)
+ [Wichtige TCP-Keepalive-Parameter in RDS für PostgreSQL](#Appendix.PostgreSQL.CommonDBATasks.DeadConnectionHandling.Parameters)
+ [Anwendungsfälle für TCP-Keepalive-Einstellungen](#Appendix.PostgreSQL.CommonDBATasks.DeadConnectionHandling.UseCases)
+ [Best Practices](#Appendix.PostgreSQL.CommonDBATasks.DeadConnectionHandling.BestPractices)
## Grundlagen zu TCP-Keepalive
TCP-Keepalive ist ein Mechanismus auf Protokollebene, der dabei hilft, die Verbindungsintegrität aufrechtzuerhalten und zu überprüfen. Jede TCP-Verbindung verwaltet Einstellungen auf Kernelebene, die das Keepalive-Verhalten steuern. Wenn der Keepalive-Timer abläuft, führt das System folgenden Aktionen durch:
+ Es sendet ein Testpaket ohne Daten und mit gesetztem ACK-Flag.
+ Erwartet eine Antwort vom Remote-Endpunkt gemäß den TCP/IP Spezifikationen.
+ Es verwaltet den Verbindungsstatus auf der Grundlage der Antwort oder des Fehlens einer Antwort.
## Wichtige TCP-Keepalive-Parameter in RDS für PostgreSQL
| Parameter | Description | Standardwerte |
| --- |--- |--- |
| tcp\$1keepalives\$1idle | Gibt die Anzahl der Sekunden der Inaktivität an, bevor eine Keepalive-Nachricht gesendet wird. | 300 |
| tcp\$1keepalives\$1interval | Gibt die Anzahl der Sekunden zwischen erneuten Übertragungen unbestätigter Keepalive-Nachrichten an. | 30 |
| tcp\$1keepalives\$1count | Höchstzahl verloren gegangener Keepalive-Nachrichten, bevor die Verbindung für unterbrochen erklärt wird | 2 |
| tcp\$1user\$1timeout | Gibt an, wie lange (in Millisekunden) unbestätigte Daten verbleiben können, bevor die Verbindung gewaltsam geschlossen wird. | 0 |
| client\$1connection\$1check\$1interval | Legt das Intervall (in Millisekunden) für die Überprüfung des Client-Verbindungsstatus bei Abfragen mit langer Laufzeit fest. Dadurch wird eine schnellere Erkennung geschlossener Verbindungen gewährleistet. | 0 |
## Anwendungsfälle für TCP-Keepalive-Einstellungen
### Aufrechterhalten von Sitzungen im Leerlauf
So verhindern Sie, dass inaktive Verbindungen aufgrund von Inaktivität durch Firewalls oder Router beendet werden:
+ Konfigurieren Sie `tcp_keepalives_idle`, um Keepalive-Pakete in regelmäßigen Abständen zu senden.
### Erkennen von inaktiven Verbindungen
Gehen Sie wie folgt vor, um inaktive Verbindungen umgehend zu erkennen:
+ Passen Sie `tcp_keepalives_idle`, `tcp_keepalives_interval` und `tcp_keepalives_count` an. Mit den Standardeinstellungen von Aurora PostgreSQL dauert es beispielsweise etwa 1 Minute (2 Proben × 30 Sekunden), um eine interaktive Verbindung zu erkennen. Eine Senkung dieser Werte kann die Erkennung beschleunigen.
+ Verwenden Sie `tcp_user_timeout`, um die maximale Wartezeit für eine Bestätigung festzulegen.
TCP-Keepalive-Einstellungen helfen dem Kernel, inaktive Verbindungen zu erkennen, aber PostgreSQL reagiert möglicherweise erst, wenn der Socket verwendet wird. Wenn in einer Sitzung eine lange Abfrage ausgeführt wird, werden inaktive Verbindungen möglicherweise erst nach Abschluss der Abfrage erkannt. In PostgreSQL 14 und höheren Versionen kann `client_connection_check_interval` die Erkennung inaktiver Verbindungen beschleunigen, indem der Socket während der Abfrageausführung regelmäßig abgefragt wird.
## Best Practices
+ **Angemessene Keepalive-Intervalle festlegen:** Optimieren Sie `tcp_user_timeout`, `tcp_keepalives_idle`, `tcp_keepalives_count` und `tcp_keepalives_interval`, um für ein ausgewogenes Verhältnis zwischen Erkennungsgeschwindigkeit und Ressourcennutzung zu sorgen.
+ **Für Ihre Umgebung optimieren**. Richten Sie Einstellungen am Netzwerkverhalten, an Firewall-Richtlinien und an Sitzungsanforderungen aus.
+ **PostgreSQL-Funktionen nutzen:** Verwenden Sie `client_connection_check_interval` in PostgreSQL 14 und höheren Versionen für effiziente Verbindungsprüfungen.
# Arbeiten mit der PostgreSQL-Selbstbereinigung in Amazon RDS für PostgreSQL
Wir empfehlen ausdrücklich die Selbstbereinigungsfunktion zu verwenden, um die Integrität Ihrer PostgreSQL-DB-Instance zu wahren. Die Selbstbereinigung automatisiert den Start der Befehle VACUUM und ANALYZE. Sie prüft auf Tabellen mit einer großen Zahl von eingefügten, aktualisierten oder gelöschten Tupeln. Nach dieser Prüfung wird Speicher durch Entfernen von überflüssigen Daten oder Tupeln aus der PostgreSQL-Datenbank freigegeben.
Standardmäßig ist die Selbstbereinigungsfunktion auf den DB-Instances von RDS für PostgreSQL aktiviert, die Sie mit einer der standardmäßigen PostgreSQL-DB-Parametergruppen erstellen. Andere Konfigurationsparameter, die mit der Selbstbereinigungsfunktion verknüpft sind, sind ebenfalls standardmäßig festgelegt. Da diese Standardwerte generisch sind, können Sie davon profitieren, einige der mit der Selbstbereinigungsfunktion verbundenen Parameter für Ihre spezifische Workload zu optimieren.
Im Folgenden finden Sie weitere Informationen zur Selbstbereinigung und wie Sie einige ihrer Parameter auf Ihrer DB-Instance von RDS für PostgreSQL optimieren können. Allgemeine Informationen finden Sie unter [Bewährte Methoden für die Arbeit mit PostgreSQL](CHAP_BestPractices.md#CHAP_BestPractices.PostgreSQL).
**Topics**
+ [Zuweisen von Arbeitsspeicher für die Selbstbereinigung](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum.WorkMemory)
+ [Verringern der Wahrscheinlichkeit von Transaktions-ID-Wraparounds](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum.AdaptiveAutoVacuuming)
+ [Ermittlung, ob die Tabellen in Ihrer Datenbank bereinigt werden müssen](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.NeedVacuuming.md)
+ [Ermittlung, für welche Tabellen derzeit eine Selbstbereinigung nötig ist](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.EligibleTables.md)
+ [Ermittlung, ob die Selbstbereinigung derzeit ausgeführt wird und wie lange sie dauert](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.AutovacuumRunning.md)
+ [Ausführen einer manuellen Bereinigungseinfrierung](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.VacuumFreeze.md)
+ [Neuindizierung einer Tabelle während der Ausführung einer Selbstbereinigung](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.Reindexing.md)
+ [Verwalten der automatischen Bereinigung mit großen Indizes](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.LargeIndexes.md)
+ [Weitere Parameter, die sich auf die Selbstbereinigung auswirken](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.OtherParms.md)
+ [Festlegen von Selbstbereinigungsparametern auf Tabellenebene](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.TableParameters.md)
+ [Protokollieren von Selbstbereinigung- und Bereinigungsaktivitäten](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.Logging.md)
+ [Verstehen des Verhaltens der Selbstbereinigung bei ungültigen Datenbanken](appendix.postgresql.commondbatasks.autovacuumbehavior.md)
+ [Identifizieren und Beheben von Problemen mit Blockern aggressiver Bereinigungen in RDS für PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.md)
## Zuweisen von Arbeitsspeicher für die Selbstbereinigung
Einer der wichtigsten Parameter, der sich auf die Leistung der Selbstbereinigung auswirkt, ist der Parameter [https://www.postgresql.org/docs/current/runtime-config-resource.html#GUC-AUTOVACUUM-WORK-MEM](https://www.postgresql.org/docs/current/runtime-config-resource.html#GUC-AUTOVACUUM-WORK-MEM). In RDS für PostgreSQL, Versionen 14 und früher, ist der `autovacuum_work_mem`-Parameter auf -1 gesetzt und zeigt somit an, dass stattdessen die `maintenance_work_mem`-Einstellung verwendet wird. Für alle anderen Versionen `autovacuum_work_mem` wird durch GREATEST (\$1DBInstanceClassMemory/32768\$1, 65536) bestimmt.
Bei manuellen Vakuumvorgängen wird immer die `maintenance_work_mem` Einstellung verwendet, wobei die Standardeinstellung GREATEST (\$1DBInstanceClassMemory/63963136 \$11024\$1, 65536) ist. Sie kann auch auf Sitzungsebene mithilfe des Befehls für gezieltere manuelle Operationen angepasst werden. `SET` `VACUUM`
`autovacuum_work_mem` bestimmt den Speicher der automatischen Bereinigung zum Speichern von IDs toter Tupeln (`pg_stat_all_tables.n_dead_tup`) für Bereinigungsindizes.
Beachten Sie Folgendes, wenn Sie Berechnungen durchführen, um den Wert des `autovacuum_work_mem`-Parameters bestimmen:
+ Wenn Sie den Wert des Parameters zu niedrig einstellen, muss die Tabelle während des Bereinigungsvorgangs möglicherweise mehrmals gescannt werden, damit der Vorgang abgeschlossen werden kann. Solche wiederholten Scans können negative Auswirkungen auf die Leistung haben. Bei größeren Instances kann das Festlegen von `maintenance_work_mem` oder `autovacuum_work_mem` auf mindestens 1 GB die Leistung bei der Bereinigung von Tabellen mit einer hohen Anzahl von toten Tupeln verbessern. In den PostgreSQL-Versionen 16 und früher ist die Speichernutzung für die Bereinigung jedoch auf 1 GB begrenzt, was ausreicht, um ungefähr 179 Millionen tote Tupel in einem einzigen Durchgang zu verarbeiten. Wenn eine Tabelle mehr tote Tupel enthält, sind mehrere Bereinigungsdurchläufe durch die Indizes der Tabelle erforderlich, was den Zeitaufwand erheblich erhöht. Ab PostgreSQL-Version 17 gibt es kein Limit von 1 GB mehr und die Selbstbereinigung kann mithilfe von Radixbäumen mehr als 179 Millionen Tupel verarbeiten.
Ein Tupel-Bezeichner hat eine Größe von 6 Bytes. Um den Speicherbedarf für das Bereinigen eines Tabellenindex zu schätzen, fragen Sie `pg_stat_all_tables.n_dead_tup` ab, um die Anzahl der toten Tupel zu ermitteln. Multiplizieren Sie diese Zahl dann mit 6, um den Speicherbedarf zu bestimmen, der für das Bereinigen des Index in einem einzigen Durchgang erforderlich ist. Sie können die folgende Abfrage verwenden:
```
SELECT
relname AS table_name,
n_dead_tup,
pg_size_pretty(n_dead_tup * 6) AS estimated_memory
FROM
pg_stat_all_tables
WHERE
relname = 'name_of_the_table';
```
+ Der Parameter `autovacuum_work_mem` funktioniert in Verbindung mit dem Parameter `autovacuum_max_workers`. Jeder Worker aus `autovacuum_max_workers` kann den von Ihnen zugeteilten Arbeitsspeicher nutzen. Wenn Sie viele kleine Tabellen haben, müssen Sie mehr `autovacuum_max_workers` und weniger `autovacuum_work_mem` zuteilen. Wenn Sie große Tabellen haben (größer als 100 GB), sollten Sie mehr Arbeitsspeicher und weniger Worker-Prozesse zuteilen. Sie müssen genügend Arbeitsspeicher zuweisen, um den Vorgang für Ihre größte Tabelle erfolgreich ausführen zu können. Daher muss die Kombination aus Worker-Prozessen und Arbeitsspeicher dem gesamten Arbeitsspeicher entsprechen, den Sie zuteilen möchten.
## Verringern der Wahrscheinlichkeit von Transaktions-ID-Wraparounds
In einigen Fällen sind Parametergruppen-Einstellungen, die sich auf die Selbstbereinigung beziehen, möglicherweise nicht aggressiv genug, um Transaktions-ID-Wraparounds zu verhindern. Um dieses Problem anzugehen, stellt RDS für PostgreSQL eine Methode bereit, mit der die Selbstbereinigungsparameter automatisch angepasst werden. Die *adaptive Selbstbereinigung* ist ein Feature für RDS für PostgreSQL . In der PostgreSQL-Dokumentation finden Sie eine sehr detaillierte Beschreibung von [Transaktions-ID-Wraparounds](https://www.postgresql.org/docs/current/static/routine-vacuuming.html#VACUUM-FOR-WRAPAROUND).
Die adaptive Selbstbereinigung ist standardmäßig für Instances von RDS für PostgreSQL aktiviert, wobei der dynamische Parameter `rds.adaptive_autovacuum` auf ON gesetzt ist. Wir raten dringend dazu, diese Option aktiviert zu lassen. Um die adaptive Optimierung der Selbstbereinigungsparameter zu deaktivieren, stellen Sie den Parameter `rds.adaptive_autovacuum` jedoch auf 0 oder OFF ein.
Transaktions-ID-Wraparounds können selbst dann noch auftreten, wenn Amazon RDS Amazon RDS die Selbstbereinigungsparameter optimiert. Wir empfehlen Ihnen, einen CloudWatch Amazon-Alarm für den Transaktions-ID-Wraparound zu implementieren. Weitere Informationen finden Sie im Datenbank-Blog im Beitrag [Implementieren eines Frühwarnsystems für Transaktions-ID-Wraparound in RDS for PostgreSQL](https://aws.amazon.com/blogs/database/implement-an-early-warning-system-for-transaction-id-wraparound-in-amazon-rds-for-postgresql/). AWS
Wenn die adaptive Abstimmung der Autovakuum-Parameter aktiviert ist, beginnt Amazon RDS mit der Anpassung der Autovakuum-Parameter, wenn die CloudWatch Metrik den Wert des `autovacuum_freeze_max_age` Parameters oder 500.000.000 `MaximumUsedTransactionIDs` erreicht, je nachdem, welcher Wert größer ist.
Amazon RDS fährt mit dem Anpassen der Parameter für die Selbstbereinigung fort, wenn eine Tabelle weiterhin zu Transaktions-ID-Wraparounds tendiert. Jede dieser Anpassungen stellt weitere Ressourcen für die Selbstbereinigung bereit, um Wraparounds zu vermeiden. Amazon RDS aktualisiert die folgenden Parameter, die sich auf die Selbstbereinigung beziehen:
+ [autovacuum\$1vacuum\$1cost\$1delay](https://www.postgresql.org/docs/current/static/runtime-config-autovacuum.html#GUC-AUTOVACUUM-VACUUM-COST-DELAY)
+ [ autovacuum\$1vacuum\$1cost\$1limit](https://www.postgresql.org/docs/current/static/runtime-config-autovacuum.html#GUC-AUTOVACUUM-VACUUM-COST-LIMIT)
+ [https://www.postgresql.org/docs/current/runtime-config-resource.html#GUC-AUTOVACUUM-WORK-MEM](https://www.postgresql.org/docs/current/runtime-config-resource.html#GUC-AUTOVACUUM-WORK-MEM)
+ [autovacuum\$1naptime](https://www.postgresql.org/docs/current/runtime-config-autovacuum.html#GUC-AUTOVACUUM-NAPTIME)
RDS ändert diese Parameter nur, wenn der neue Wert die Selbstbereinigung aggressiver macht. Die Parameter werden im Arbeitsspeicher auf der DB-Instance geändert. Die Werte in der Parametergruppe werden nicht geändert. Um die aktuellen Arbeitsspeichereinstellungen anzuzeigen, verwenden Sie den PostgreSQL-SQL-Befehl [SHOW](https://www.postgresql.org/docs/current/sql-show.html).
Wenn Amazon RDS einen dieser Selbstbereinigungsparameter ändert, wird ein Ereignis für die betroffene DB-Instance erzeugt. Dieses Ereignis ist auf der AWS-Managementkonsole und über die Amazon RDS-API sichtbar. Wenn die `MaximumUsedTransactionIDs` CloudWatch Metrik wieder unter den Schwellenwert fällt, setzt Amazon RDS die Autovakuum-bezogenen Parameter im Speicher auf die in der Parametergruppe angegebenen Werte zurück. Es generiert dann ein anderes Ereignis, das dieser Änderung entspricht.
# Ermittlung, ob die Tabellen in Ihrer Datenbank bereinigt werden müssen
Sie können die folgende Abfrage verwenden, um die Anzahl der nicht eingefrorenen Transaktionen in einer Datenbank anzuzeigen. Die `datfrozenxid` Spalte einer `pg_database` Datenbankzeile ist eine Untergrenze der normalen Transaktion, die in dieser Datenbank IDs erscheint. Diese Spalte ist der Mindestwert der `relfrozenxid`-Werte pro Tabelle in der Datenbank.
```
SELECT datname, age(datfrozenxid) FROM pg_database ORDER BY age(datfrozenxid) desc limit 20;
```
Beispielsweise könnten die Ergebnisse der Ausführung der oben gezeigten Abfrage wie folgt aussehen.
```
datname | age
mydb | 1771757888
template0 | 1721757888
template1 | 1721757888
rdsadmin | 1694008527
postgres | 1693881061
(5 rows)
```
Wenn das Alter einer Datenbank 2 Milliarden Transaktionen erreicht IDs, erfolgt ein Transaktions-ID (XID) -Wraparound, und die Datenbank wird schreibgeschützt. Sie können diese Abfrage verwenden, um eine Metrik zu erstellen und einige Male am Tag auszuführen. Standardmäßig ist die Selbstbereinigung so festgelegt, dass das Alter der Transaktionen 200 000 000 nicht überschreitet 200,000,000 ([https://www.postgresql.org/docs/current/static/runtime-config-autovacuum.html#GUC-AUTOVACUUM-FREEZE-MAX-AGE](https://www.postgresql.org/docs/current/static/runtime-config-autovacuum.html#GUC-AUTOVACUUM-FREEZE-MAX-AGE)).
Eine Überwachungsstrategie kann beispielsweise wie folgt aussehen:
+ Stellen Sie den `autovacuum_freeze_max_age`-Wert auf 200 Millionen Transaktionen ein.
+ Wenn eine Tabelle 500 Millionen nicht eingefrorener Transaktionen erreicht, wird ein Alarm mit niedrigem Schweregrad ausgelöst. Dies ist kein unangemessener Wert. Er könnte jedoch zu erkennen geben, dass die Selbstbereinigung nicht Schritt hält.
+ Wenn eine Tabelle 1 Milliarde nicht bereinigter Transaktionen aufweist, sollte dies als ein Alarm behandelt werden, für den Maßnahmen zu ergreifen sind. Im Allgemeinen sollte aus Leistungsgründen das Alter möglichst nahe zu `autovacuum_freeze_max_age` liegen. Wir empfehlen, dass Sie eine Untersuchung unter Beachtung der folgenden Empfehlungen durchführen.
+ Wenn eine Tabelle 1,5 Milliarden nicht bereinigter Transaktionen erreicht, wird ein Alarm mit hohem Schweregrad ausgelöst. Je nachdem, wie schnell Ihre Datenbank die Transaktion verwendet, kann dieser Alarm darauf hinweisen IDs, dass dem System die Zeit für die Ausführung des Autovakuums knapp wird. In diesem Fall empfehlen wir, eine unmittelbare Lösung in Betracht zu ziehen.
Wenn eine Tabelle diese Schwellenwerte konstant überschreitet, ändern Sie die Selbstbereinigungsparameter weiter. Standardmäßig ist die manuelle Verwendung von VACUUM (für den kostenbasierte Verzögerungen deaktiviert sind) aggressiver als die Standardselbstbereinigung. Der Befehl hat jedoch insgesamt auch größere Auswirkungen auf das System.
Wir empfehlen Folgendes:
+ Aktivieren Sie einen Überwachungsmechanismus, damit Sie über das Alter der ältesten Transaktionen informiert sind.
Informationen zum Erstellen eines Prozesses, der Sie vor Transaktions-ID-Wraparound warnt, finden Sie im AWS Datenbank-Blogbeitrag [Implementieren Sie ein Frühwarnsystem für Transaktions-ID-Wraparound in Amazon](https://aws.amazon.com/blogs/database/implement-an-early-warning-system-for-transaction-id-wraparound-in-amazon-rds-for-postgresql/) RDS for PostgreSQL.
+ Führen Sie für häufiger verwendete Tabellen zusätzlich zur Selbstbereinigung während Wartungsfenstern regelmäßig eine manuelle Bereinigungseinfrierung aus. Informationen zur Ausführung manueller Bereinigungseinfrierungen finden Sie unter [Ausführen einer manuellen Bereinigungseinfrierung](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.VacuumFreeze.md).
# Ermittlung, für welche Tabellen derzeit eine Selbstbereinigung nötig ist
Häufig benötigen eine oder zwei Tabellen eine Bereinigung. Tabellen, deren `relfrozenxid`-Wert größer als die Anzahl von Transaktionen in `autovacuum_freeze_max_age` ist, sind stets Ziel der Selbstbereinigung. Wenn andernfalls die Anzahl der Tupeln, die seit dem letzten VACUUM-Befehl veraltet sind, den Bereinigungsschwellenwert überschreitet, wird die Tabelle bereinigt.
Der [Selbstbereinigungsschwellenwert](https://www.postgresql.org/docs/current/static/routine-vacuuming.html#AUTOVACUUM) ist definiert als:
```
Vacuum-threshold = vacuum-base-threshold + vacuum-scale-factor * number-of-tuples
```
wobei `vacuum base threshold` `autovacuum_vacuum_threshold` ist, `vacuum scale factor` `autovacuum_vacuum_scale_factor` ist und `number of tuples` `pg_class.reltuples` ist.
Führen Sie während der Herstellung der Verbindung mit Ihrer Datenbank die folgende Abfrage aus, um eine Liste der Tabellen anzuzeigen, für die Selbstbereinigungsfunktion eine Bereinigung als notwendig betrachtet.
```
WITH vbt AS (SELECT setting AS autovacuum_vacuum_threshold FROM
pg_settings WHERE name = 'autovacuum_vacuum_threshold'),
vsf AS (SELECT setting AS autovacuum_vacuum_scale_factor FROM
pg_settings WHERE name = 'autovacuum_vacuum_scale_factor'),
fma AS (SELECT setting AS autovacuum_freeze_max_age FROM pg_settings WHERE name = 'autovacuum_freeze_max_age'),
sto AS (select opt_oid, split_part(setting, '=', 1) as param,
split_part(setting, '=', 2) as value from (select oid opt_oid, unnest(reloptions) setting from pg_class) opt)
SELECT '"'||ns.nspname||'"."'||c.relname||'"' as relation,
pg_size_pretty(pg_table_size(c.oid)) as table_size,
age(relfrozenxid) as xid_age,
coalesce(cfma.value::float, autovacuum_freeze_max_age::float) autovacuum_freeze_max_age,
(coalesce(cvbt.value::float, autovacuum_vacuum_threshold::float) +
coalesce(cvsf.value::float,autovacuum_vacuum_scale_factor::float) * c.reltuples)
AS autovacuum_vacuum_tuples, n_dead_tup as dead_tuples FROM
pg_class c join pg_namespace ns on ns.oid = c.relnamespace
join pg_stat_all_tables stat on stat.relid = c.oid join vbt on (1=1) join vsf on (1=1) join fma on (1=1)
left join sto cvbt on cvbt.param = 'autovacuum_vacuum_threshold' and c.oid = cvbt.opt_oid
left join sto cvsf on cvsf.param = 'autovacuum_vacuum_scale_factor' and c.oid = cvsf.opt_oid
left join sto cfma on cfma.param = 'autovacuum_freeze_max_age' and c.oid = cfma.opt_oid
WHERE c.relkind = 'r' and nspname <> 'pg_catalog'
AND (age(relfrozenxid) >= coalesce(cfma.value::float, autovacuum_freeze_max_age::float)
OR coalesce(cvbt.value::float, autovacuum_vacuum_threshold::float) +
coalesce(cvsf.value::float,autovacuum_vacuum_scale_factor::float) *
c.reltuples <= n_dead_tup)
ORDER BY age(relfrozenxid) DESC LIMIT 50;
```
# Ermittlung, ob die Selbstbereinigung derzeit ausgeführt wird und wie lange sie dauert
Wenn Sie eine Tabelle manuell bereinigen müssen, müssen Sie ermitteln, ob zurzeit eine Selbstbereinigung ausgeführt wird. Wenn dies der Fall ist, müssen Sie die Parameter anpassen, damit sie effizienter ausgeführt wird, oder die Selbstbereinigung temporär beenden, damit Sie den Befehl VACUUM manuell ausführen können.
Verwenden Sie die folgende Abfrage, um zu ermitteln, ob die Selbstbereinigung ausgeführt wird, wie lange diese bereits dauert und ob diese auf eine andere Sitzung wartet.
```
SELECT datname, usename, pid, state, wait_event, current_timestamp - xact_start AS xact_runtime, query
FROM pg_stat_activity
WHERE upper(query) LIKE '%VACUUM%'
ORDER BY xact_start;
```
Nach dem Ausführen der Abfrage wird Ihnen eine Ausgabe ähnlich der folgenden angezeigt.
```
datname | usename | pid | state | wait_event | xact_runtime | query
--------+----------+-------+--------+------------+-------------------------+--------------------------------------------------------------------------------------------------------
mydb | rdsadmin | 16473 | active | | 33 days 16:32:11.600656 | autovacuum: VACUUM ANALYZE public.mytable1 (to prevent wraparound)
mydb | rdsadmin | 22553 | active | | 14 days 09:15:34.073141 | autovacuum: VACUUM ANALYZE public.mytable2 (to prevent wraparound)
mydb | rdsadmin | 41909 | active | | 3 days 02:43:54.203349 | autovacuum: VACUUM ANALYZE public.mytable3
mydb | rdsadmin | 618 | active | | 00:00:00 | SELECT datname, usename, pid, state, wait_event, current_timestamp - xact_start AS xact_runtime, query+
| | | | | | FROM pg_stat_activity +
| | | | | | WHERE query like '%VACUUM%' +
| | | | | | ORDER BY xact_start; +
```
Verschiedene Probleme können dazu führen, dass eine Selbstbereinigungssitzung über eine lange Zeit (mehrere Tage) ausgeführt wird. Das häufigste Problem besteht jedoch darin, dass der Wert Ihres Parameters [https://www.postgresql.org/docs/current/static/runtime-config-resource.html#GUC-MAINTENANCE-WORK-MEM](https://www.postgresql.org/docs/current/static/runtime-config-resource.html#GUC-MAINTENANCE-WORK-MEM) im Verhältnis zur Größe der Tabelle oder zur Häufigkeit der Aktualisierungen zu niedrig festgelegt wurde.
Es wird empfohlen, dass Sie die folgende Formel verwenden, um den Wert des Parameters `maintenance_work_mem` festzulegen.
```
GREATEST({DBInstanceClassMemory/63963136*1024},65536)
```
Selbstbereinigungssitzungen, die nur kurze Zeit ausgeführt werden, können ebenfalls auf Probleme hinweisen:
+ Es kann bedeuten, dass es für Ihren Workload nicht genügend `autovacuum_max_workers` gibt. In diesem Fall müssen Sie die Anzahl der Worker angeben.
+ Es kann bedeuten, dass es eine Indexbeschädigung gibt (die Selbstbereinigung stürzt ab und startet bei derselben Relation neu, es gibt jedoch keine Fortschritte). Führen Sie in diesem Fall ein manuelles `vacuum freeze verbose table` aus, um die genaue Ursache zu sehen.
# Ausführen einer manuellen Bereinigungseinfrierung
Möglicherweise möchten Sie eine manuelle Bereinigung für eine Tabelle ausführen, für die bereits ein Bereinigungsvorgang ausgeführt wird. Dies ist nützlich, wenn Sie eine Tabelle mit einem Alter identifiziert haben, das 2 Milliarden Transaktionen (oder einen Wert oberhalb eines von Ihnen beobachteten Schwellenwerts) erreicht.
Die folgenden Schritte sind Richtlinien mit mehreren Variationen des Prozesses. Angenommen, Sie stellen während der Überprüfung fest, dass der Wert für den Parameter [https://www.postgresql.org/docs/current/static/runtime-config-resource.html#GUC-MAINTENANCE-WORK-MEM](https://www.postgresql.org/docs/current/static/runtime-config-resource.html#GUC-MAINTENANCE-WORK-MEM) zu niedrig festgelegt wurde. Sie müssen sofort Maßnahmen für eine Tabelle einleiten. Sie möchten zum aktuellen Zeitpunkt jedoch keinen Bounce für die Instance auslösen. Ermitteln Sie mittels der Abfragen in vorherigen Abschnitten die Tabelle, die das Problem darstellt, und identifizieren Sie eine über einen langen Zeitraum ausgeführte Selbstbereinigungssitzung. Sie müssen die Einstellung für den Parameter `maintenance_work_mem` ändern. Sie müssen jedoch auch sofortige Maßnahmen einleiten und die betreffende Tabelle bereinigen. Das folgende Verfahren zeigt, was Sie in dieser Situation unternehmen.
**So führen Sie manuell eine Bereinigungseinfrierung aus**
1. Öffnen Sie zwei Sitzungen für die Datenbank, die Tabelle enthält, die Sie bereinigen möchten. Verwenden Sie für die zweite Sitzung „screen“ oder ein anderes Hilfsprogramm, das die Sitzung beibehält, wenn die Verbindung verloren geht.
1. Rufen Sie in der ersten Sitzung die Prozess-ID (PID) der Selbstbereinigungssitzung ab, die für die Tabelle ausgeführt wird.
Führen Sie die folgende Abfrage aus, um die PID der Selbstbereinigungssitzung abzurufen.
```
SELECT datname, usename, pid, current_timestamp - xact_start
AS xact_runtime, query
FROM pg_stat_activity WHERE upper(query) LIKE '%VACUUM%' ORDER BY
xact_start;
```
1. Berechnen Sie in der zweiten Sitzung die Menge des Arbeitsspeichers, den Sie für diese Operation benötigen. In diesem Beispiel ermitteln Sie, dass für diese Operation bis zu 2 GB Arbeitsspeicher verwendet werden können. Daher wird für die aktuelle Sitzung [https://www.postgresql.org/docs/current/static/runtime-config-resource.html#GUC-MAINTENANCE-WORK-MEM](https://www.postgresql.org/docs/current/static/runtime-config-resource.html#GUC-MAINTENANCE-WORK-MEM) auf 2 GB festgelegt.
```
SET maintenance_work_mem='2 GB';
SET
```
1. Geben Sie in der zweiten Sitzung einen `vacuum freeze verbose`-Befehl für die Tabelle aus. Die Verbose-Einstellung ist nützlich, da Sie Aktivität sehen können, auch wenn in PostgreSQL hierfür zurzeit kein Fortschrittsbericht verfügbar ist.
```
\timing on
Timing is on.
vacuum freeze verbose pgbench_branches;
```
```
INFO: vacuuming "public.pgbench_branches"
INFO: index "pgbench_branches_pkey" now contains 50 row versions in 2 pages
DETAIL: 0 index row versions were removed.
0 index pages have been deleted, 0 are currently reusable.
CPU 0.00s/0.00u sec elapsed 0.00 sec.
INFO: index "pgbench_branches_test_index" now contains 50 row versions in 2 pages
DETAIL: 0 index row versions were removed.
0 index pages have been deleted, 0 are currently reusable.
CPU 0.00s/0.00u sec elapsed 0.00 sec.
INFO: "pgbench_branches": found 0 removable, 50 nonremovable row versions
in 43 out of 43 pages
DETAIL: 0 dead row versions cannot be removed yet.
There were 9347 unused item pointers.
0 pages are entirely empty.
CPU 0.00s/0.00u sec elapsed 0.00 sec.
VACUUM
Time: 2.765 ms
```
1. Wenn die Selbstbereinigung die Bereinigungssitzung blockiert hat, wird Ihnen in der ersten Sitzung in `pg_stat_activity` angezeigt, dass das Warten für Ihre Bereinigungssitzung `T` ist. Beenden Sie in diesem Fall den Selbstbereinigungsvorgang wie folgt.
```
SELECT pg_terminate_backend('the_pid');
```
**Anmerkung**
Einige niedrigere Versionen von Amazon RDS können einen Selbstbereinigungsvorgang mit dem vorherigen Befehl nicht beenden und schlagen mit dem folgenden Fehler fehl:`ERROR: 42501: must be a superuser to terminate superuser process LOCATION: pg_terminate_backend, signalfuncs.c:227`.
An diesem Punkt beginnt Ihre Sitzung. Die Selbstbereinigung wird sofort neu gestartet, da diese Tabelle in der Liste der Aufgaben wahrscheinlich ganz oben steht.
1. Initiieren Sie Ihren `vacuum freeze verbose`-Befehl in der zweiten Sitzung und beenden Sie dann den Selbstbereinigungsvorgang in der ersten Sitzung.
# Neuindizierung einer Tabelle während der Ausführung einer Selbstbereinigung
Wenn ein Index beschädigt wurde, verarbeitet die Selbstbereinigung die Tabelle weiter und schlägt fehl. Wenn Sie in dieser Situation eine manuelle Bereinigung versuchen, werden Sie eine Fehlermeldung ähnlich der folgenden erhalten.
```
postgres=> vacuum freeze pgbench_branches;
ERROR: index "pgbench_branches_test_index" contains unexpected
zero page at block 30521
HINT: Please REINDEX it.
```
Wenn der Index beschädigt ist und eine Selbstbereinigung für die Tabelle versucht wird, konkurrieren Sie mit einer Selbstbereinigungssitzung, die bereits ausgeführt wird. Wenn Sie einen [REINDEX](https://www.postgresql.org/docs/current/static/sql-reindex.html)-Befehl ausgeben, wird eine exklusive Sperre für die Tabelle ausgeführt. Schreiboperationen werden blockiert. Gleiches gilt für Lesevorgänge, die diesen spezifischen Index verwenden.
**So führen Sie eine Neuindizierung für eine Tabelle aus, wenn eine Selbstbereinigung für die Tabelle ausgeführt wird**
1. Öffnen Sie zwei Sitzungen für die Datenbank, die Tabelle enthält, die Sie bereinigen möchten. Verwenden Sie für die zweite Sitzung „screen“ oder ein anderes Hilfsprogramm, das die Sitzung beibehält, wenn die Verbindung verloren geht.
1. Rufen Sie in der ersten Sitzung die PID der Selbstbereinigungssitzung ab, die für die Tabelle ausgeführt wird.
Führen Sie die folgende Abfrage aus, um die PID der Selbstbereinigungssitzung abzurufen.
```
SELECT datname, usename, pid, current_timestamp - xact_start
AS xact_runtime, query
FROM pg_stat_activity WHERE upper(query) like '%VACUUM%' ORDER BY
xact_start;
```
1. Führen Sie in der zweiten Sitzung den Neuindizierungsbefehl aus.
```
\timing on
Timing is on.
reindex index pgbench_branches_test_index;
REINDEX
Time: 9.966 ms
```
1. Wenn die Selbstbereinigung den Prozess blockiert hat, wird Ihnen in der ersten Sitzung in `pg_stat_activity` angezeigt, dass das Warten für Ihre Bereinigungssitzung "T" ist. In diesem Fall beenden Sie den Selbstbereinigungsprozess.
```
SELECT pg_terminate_backend('the_pid');
```
An diesem Punkt beginnt Ihre Sitzung. Es ist wichtig, zu beachten, dass die Selbstbereinigung sofort neu gestartet wird, da diese Tabelle in der Liste der Aufgaben wahrscheinlich ganz oben steht.
1. Initiieren Sie Ihren Befehl in der zweiten Sitzung und beenden Sie dann den Selbstbereinigungsvorgang in der ersten Sitzung.
# Verwalten der automatischen Bereinigung mit großen Indizes
Im Rahmen ihrer Funktion führt die *automatische Bereinigung* mehrere [Bereinigungsphasen](https://www.postgresql.org/docs/current/progress-reporting.html#VACUUM-PHASES) aus, während sie für eine Tabelle ausgeführt wird. Bevor die Tabelle bereinigt wird, werden zunächst alle Indizes bereinigt. Wenn mehrere große Indizes entfernt werden, benötigt diese Phase einen großen Zeit- und Ressourcenaufwand. Es hat sich daher bewährt, die Anzahl der Indizes in einer Tabelle zu kontrollieren und ungenutzte Indizes zu entfernen.
Überprüfen Sie für diesen Vorgang zunächst die Gesamtindexgröße. Stellen Sie dann fest, ob es möglicherweise unbenutzte Indizes gibt, die entfernt werden können, wie in den folgenden Beispielen dargestellt.
**So überprüfen Sie die Größe der Tabelle und ihrer Indizes**
```
postgres=> select pg_size_pretty(pg_relation_size('pgbench_accounts'));
pg_size_pretty
6404 MB
(1 row)
```
```
postgres=> select pg_size_pretty(pg_indexes_size('pgbench_accounts'));
pg_size_pretty
11 GB
(1 row)
```
In diesem Beispiel ist die Größe der Indizes größer als die Tabelle. Dieser Unterschied kann zu Leistungsproblemen führen, da die Indizes überlastet oder ungenutzt sind, was sich sowohl auf die automatische Bereinigung als auch auf Insert-Operationen auswirkt.
**So prüfen Sie, ob ungenutzte Indizes vorhanden sind**
Mithilfe der Ansicht [https://www.postgresql.org/docs/current/monitoring-stats.html#MONITORING-PG-STAT-ALL-INDEXES-VIEW](https://www.postgresql.org/docs/current/monitoring-stats.html#MONITORING-PG-STAT-ALL-INDEXES-VIEW) können Sie überprüfen, wie oft ein Index für die Spalte `idx_scan` verwendet wird. Im folgenden Beispiel haben die ungenutzten Indizes den `idx_scan`-Wert `0`.
```
postgres=> select * from pg_stat_user_indexes where relname = 'pgbench_accounts' order by idx_scan desc;
relid | indexrelid | schemaname | relname | indexrelname | idx_scan | idx_tup_read | idx_tup_fetch
-------+------------+------------+------------------+-----------------------+----------+--------------+---------------
16433 | 16454 | public | pgbench_accounts | index_f | 6 | 6 | 0
16433 | 16450 | public | pgbench_accounts | index_b | 3 | 199999 | 0
16433 | 16447 | public | pgbench_accounts | pgbench_accounts_pkey | 0 | 0 | 0
16433 | 16452 | public | pgbench_accounts | index_d | 0 | 0 | 0
16433 | 16453 | public | pgbench_accounts | index_e | 0 | 0 | 0
16433 | 16451 | public | pgbench_accounts | index_c | 0 | 0 | 0
16433 | 16449 | public | pgbench_accounts | index_a | 0 | 0 | 0
(7 rows)
```
```
postgres=> select schemaname, relname, indexrelname, idx_scan from pg_stat_user_indexes where relname = 'pgbench_accounts' order by idx_scan desc;
schemaname | relname | indexrelname | idx_scan
------------+------------------+-----------------------+----------
public | pgbench_accounts | index_f | 6
public | pgbench_accounts | index_b | 3
public | pgbench_accounts | pgbench_accounts_pkey | 0
public | pgbench_accounts | index_d | 0
public | pgbench_accounts | index_e | 0
public | pgbench_accounts | index_c | 0
public | pgbench_accounts | index_a | 0
(7 rows)
```
**Anmerkung**
Diese Statistiken sind ab dem Zeitpunkt, an dem die Statistiken zurückgesetzt werden, inkrementell. Angenommen, Sie haben einen Index, der nur am Ende eines Geschäftsquartals oder nur für einen bestimmten Bericht verwendet wird. Es ist möglich, dass dieser Index seit dem Zurücksetzen der Statistiken nicht mehr verwendet wurde. Weitere Informationen finden Sie unter [Statistikfunktionen](https://www.postgresql.org/docs/current/monitoring-stats.html#MONITORING-STATS-FUNCTIONS). Indizes, die verwendet werden, um Eindeutigkeit zu erzwingen, werden nicht gescannt und sollten nicht als ungenutzte Indizes identifiziert werden. Um die ungenutzten Indizes zu identifizieren, sollten Sie über fundierte Kenntnisse der Anwendung und ihrer Abfragen verfügen.
Um zu überprüfen, wann die Statistiken für eine Datenbank zuletzt zurückgesetzt wurden, verwenden Sie [ 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).
```
postgres=> select datname, stats_reset from pg_stat_database where datname = 'postgres';
datname | stats_reset
----------+-------------------------------
postgres | 2022-11-17 08:58:11.427224+00
(1 row)
```
## Möglichst schnelles Bereinigen einer Tabelle
**RDS für PostgreSQL 12 und höher**
Wenn Sie zu viele Indizes in einer großen Tabelle haben, nähert sich Ihre DB-Instance möglicherweise dem Transaktions-ID-Wraparound (XID), also dem Zeitpunkt, an dem der XID-Zähler auf Null zurückgeht. Wenn diese Option nicht aktiviert ist, kann diese Situation zu Datenverlust führen. Sie können die Tabelle jedoch schnell bereinigen, ohne die Indizes zu bereinigen. In RDS für PostgreSQL 12 und höher können Sie VACUUM mit der Klausel [https://www.postgresql.org/docs/current/sql-vacuum.html](https://www.postgresql.org/docs/current/sql-vacuum.html) verwenden.
```
postgres=> VACUUM (INDEX_CLEANUP FALSE, VERBOSE TRUE) pgbench_accounts;
INFO: vacuuming "public.pgbench_accounts"
INFO: table "pgbench_accounts": found 0 removable, 8 nonremovable row versions in 1 out of 819673 pages
DETAIL: 0 dead row versions cannot be removed yet, oldest xmin: 7517
Skipped 0 pages due to buffer pins, 0 frozen pages.
CPU: user: 0.01 s, system: 0.00 s, elapsed: 0.01 s.
```
Wenn eine automatische Bereinigungssitzung bereits läuft, müssen Sie sie beenden, um mit dem manuellen VACUUM-Vorgang zu beginnen. Informationen zur Ausführung manueller Bereinigungseinfrierungen finden Sie unter [Ausführen einer manuellen Bereinigungseinfrierung](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.VacuumFreeze.md).
**Anmerkung**
Wenn Sie die Indexbereinigung regelmäßig überspringen, führt dies zu einer Überlastung der des Indizes, was die Leistung degradiert. Der Index behält tote Zeilen und die Tabelle behält tote Zeilenzeiger bei. Daher wird `pg_stat_all_tables.n_dead_tup` erhöht, bis die Selbstbereinigung oder einen manuellen VACUUM-Vorgang mit Indexbereinigung ausgeführt wird. Verwenden Sie dieses Verfahren am besten nur, um einen Transaktions-ID-Wraparound zu verhindern.
**RDS für PostgreSQL 11 und niedriger**
In RDS für PostgreSQL 11 und niedrigeren Versionen besteht die einzige Möglichkeit, den Bereinigungsvorgang schneller abzuschließen, darin, die Anzahl der Indizes in einer Tabelle zu reduzieren. Das Löschen eines Index kann sich auf Abfragepläne auswirken. Wir empfehlen, zuerst unbenutzte Indizes zu löschen und dann die Indizes löschen, wenn der XID-Wraparound kurz bevorsteht. Nach Abschluss des Bereinigungsvorgangs können Sie diese Indizes neu erstellen.
# Weitere Parameter, die sich auf die Selbstbereinigung auswirken
Die folgende Abfrage zeigt die Werte einiger Parameter an, die sich direkt auf die Selbstbereinigung und ihr Verhalten auswirken. Die [Selbstbereinigungsparameter](https://www.postgresql.org/docs/current/static/runtime-config-autovacuum.html) werden in der PostgreSQL-Dokumentation vollständig beschrieben.
```
SELECT name, setting, unit, short_desc
FROM pg_settings
WHERE name IN (
'autovacuum_max_workers',
'autovacuum_analyze_scale_factor',
'autovacuum_naptime',
'autovacuum_analyze_threshold',
'autovacuum_analyze_scale_factor',
'autovacuum_vacuum_threshold',
'autovacuum_vacuum_scale_factor',
'autovacuum_vacuum_threshold',
'autovacuum_vacuum_cost_delay',
'autovacuum_vacuum_cost_limit',
'vacuum_cost_limit',
'autovacuum_freeze_max_age',
'maintenance_work_mem',
'vacuum_freeze_min_age');
```
All diese Parameter wirken sich auf die Selbstbereinigung aus. Die wichtigsten unter ihnen sind jedoch:
+ [maintenance\$1work\$1mem](https://www.postgresql.org/docs/current/static/runtime-config-resource.html#GUC-MAINTENANCE_WORK_MEM)
+ [autovacuum\$1freeze\$1max\$1age](https://www.postgresql.org/docs/current/static/runtime-config-autovacuum.html#GUC-AUTOVACUUM-FREEZE-MAX-AGE)
+ [autovacuum\$1max\$1workers](https://www.postgresql.org/docs/current/static/runtime-config-autovacuum.html#GUC-AUTOVACUUM-MAX-WORKERS)
+ [autovacuum\$1vacuum\$1cost\$1delay](https://www.postgresql.org/docs/current/static/runtime-config-autovacuum.html#GUC-AUTOVACUUM-VACUUM-COST-DELAY)
+ [ autovacuum\$1vacuum\$1cost\$1limit](https://www.postgresql.org/docs/current/static/runtime-config-autovacuum.html#GUC-AUTOVACUUM-VACUUM-COST-LIMIT)
# Festlegen von Selbstbereinigungsparametern auf Tabellenebene
Sie können [Speicherparameter](https://www.postgresql.org/docs/current/static/sql-createtable.html#SQL-CREATETABLE-STORAGE-PARAMETERS), die sich auf die der Selbstbereinigung beziehen, auf Tabellenebene festlegen. Dies kann im Vergleich zur Änderung des Verhaltens der gesamten Datenbank ein bevorzugtes Verfahren sein. Im Fall großer Tabellen müssen möglicherweise aggressive Einstellungen festgelegt werden, und Sie möchten vielleicht nicht, dass sich die Selbstbereinigung für alle Tabellen auf diese Weise verhält.
Die folgende Abfrage zeigt, für welche Tabellen zurzeit Optionen auf Tabellenebene festgelegt wurden.
```
SELECT relname, reloptions
FROM pg_class
WHERE reloptions IS NOT null;
```
Ein Beispiel, in dem dies nützlich sein kann, sind Tabellen, die sehr viel größer als Ihre restlichen Tabellen sind. Angenommen, es gibt eine Tabelle mit 300 GB und 30 weitere Tabellen mit weniger als 1 GB. In diesem Fall würde es sich anbieten, einige spezifische Parameter nur für die große Tabelle festzulegen, um nicht das Verhalten des gesamten Systems zu ändern.
```
ALTER TABLE mytable set (autovacuum_vacuum_cost_delay=0);
```
Hierdurch wird die kostenbasierte Selbstbereinigungsverzögerung für diese Tabelle auf Kosten einer größeren Ressourcennutzung in Ihrem System deaktiviert. Normalerweise pausiert die Selbstbereinigung für `autovacuum_vacuum_cost_delay` jedes Mal, wenn `autovacuum_cost_limit` erreicht wird. Weitere Details finden Sie in der PostgreSQL-Dokumentation zum Thema [kostenbasierte Bereinigung](https://www.postgresql.org/docs/current/static/runtime-config-resource.html#RUNTIME-CONFIG-RESOURCE-VACUUM-COST).
# Protokollieren von Selbstbereinigung- und Bereinigungsaktivitäten
Informationen über Bereinigungsaktivitäten werden basierend auf der im`rds.force_autovacuum_logging_level`-Parameter angegebenen Ebene an das `postgresql.log` gesendet. Im Folgenden sind die für diesen Parameter zulässigen Werte und die PostgreSQL-Versionen aufgeführt, für die dieser Wert die Standardeinstellung ist:
+ `disabled` (PostgreSQL 10, PostgreSQL 9.6)
+ `debug5`, `debug4`, `debug3`, `debug2`, `debug1`
+ `info` (PostgreSQL 12, PostgreSQL 11)
+ `notice`
+ `warning` (PostgreSQL 13 und höher)
+ `error`, Protokoll, `fatal`, `panic`
Das `rds.force_autovacuum_logging_level` arbeitet mit dem `log_autovacuum_min_duration`-Parameter. Der Wert des `log_autovacuum_min_duration`-Parameters ist der Schwellenwert (in Millisekunden), über dem Selbstbereinigung-Aktionen protokolliert werden. Eine Einstellung von `-1` protokolliert nichts, während eine Einstellung von 0 alle Aktionen protokolliert. Wie bei `rds.force_autovacuum_logging_level`, Standardwerte für `log_autovacuum_min_duration` sind versionsabhängig wie folgt:
+ `10000 ms` – PostgreSQL 14, PostgreSQL 13, PostgreSQL 12 und PostgreSQL 11
+ `(empty)` – Kein Standardwert für PostgreSQL 10 und PostgreSQL 9.6
Wir empfehlen Ihnen, `rds.force_autovacuum_logging_level` auf `WARNING` einzustellen. Wir empfehlen auch, dass Sie `log_autovacuum_min_duration` auf einen Wert von 1000 bis 5000 einstellen. Eine Einstellung von 5000 Protokollaktivitäten, die länger als 5000 Millisekunden dauern. Jede andere Einstellung als –1 protokolliert auch Meldungen, wenn die Selbstbereinigungsaktion aufgrund einer widersprüchlichen Sperre oder gleichzeitig verworfener Beziehungen übersprungen wird. Weitere Informationen finden Sie unter [Selbstbereinigung](https://www.postgresql.org/docs/current/runtime-config-autovacuum.html) in der PostgreSQL-Dokumentation.
Um Probleme zu beheben, können Sie die `rds.force_autovacuum_logging_level`-Parameter in eine der Debugebenen ändern, von `debug1` bis zu `debug5` für die ausführlichsten Informationen. Wir empfehlen, die Debug-Einstellungen für kurze Zeiträume und nur zur Fehlerbehebung zu verwenden. Weitere Informationen finden Sie unter [Zeitpunkt des Protokollierens](https://www.postgresql.org/docs/current/static/runtime-config-logging.html#RUNTIME-CONFIG-LOGGING-WHEN) in der PostgreSQL-Dokumentation.
**Anmerkung**
PostgreSQL ermöglicht es dem Konto `rds_superuser`, Autovakuum-Sitzungen in `pg_stat_activity` anzuzeigen. Sie können beispielsweise eine Selbstbereinigungssitzung identifizieren und beenden, die die Ausführung eines Befehls blockiert oder langsamer als ein manuell ausgegebener Bereinigungsbefehl ausgeführt wird.
# Verstehen des Verhaltens der Selbstbereinigung bei ungültigen Datenbanken
Ein neuer `-2`-Wert wird in die `datconnlimit`-Spalte im `pg_database`-Katalog eingeführt, um Datenbanken, die während des DROP DATABASE-Vorgangs unterbrochen wurden, als ungültig zu kennzeichnen.
Dieser neue Wert ist in den folgenden Versionen von RDS für PostgreSQL verfügbar:
+ 15.4 und alle höheren Versionen
+ 14.9 und höhere Versionen
+ 13.12 und höhere Versionen
+ 12.16 und höhere Versionen
+ 11.21 und höhere Versionen
Ungültige Datenbanken haben keinen Einfluss auf die Möglichkeit der Selbstbereinigung, die Funktionalität für gültige Datenbanken einzufrieren. Die Selbstbereinigung ignoriert ungültige Datenbanken. Folglich funktionieren reguläre Selbstbereinigungsfunktionen weiterhin ordnungsgemäß und werden effizient für alle gültigen Datenbanken in Ihrer PostgreSQL-Umgebung ausgeführt.
**Topics**
+ [Überwachen der Transaktions-ID](#appendix.postgresql.commondbatasks.autovacuum.monitorxid)
+ [Anpassen der Überwachungsanfrage](#appendix.postgresql.commondbatasks.autovacuum.monitoradjust)
+ [Beheben des Problems mit ungültigen Datenbanken](#appendix.postgresql.commondbatasks.autovacuum.connissue)
## Überwachen der Transaktions-ID
Die `age(datfrozenxid)`-Funktion wird häufig verwendet, um das Alter der Transaktions-ID (XID) von Datenbanken zwecks Verhinderung eines Transaktions-ID-Wrapraround zu überwachen.
Da ungültige Datenbanken von der Selbstbereinigung ausgenommen sind, kann ihr Transaktions-ID-(XID)-Zähler den Maximalwert von `2 billion` erreichen, auf `- 2 billion` zurückgehen und diesen Zyklus auf unbestimmte Zeit fortsetzen. Eine typische Abfrage zur Überwachung des Transaktions-ID-Wraparound könnte wie folgt aussehen:
```
SELECT max(age(datfrozenxid)) FROM pg_database;
```
Mit der Einführung des Werts -2 für `datconnlimit` können ungültige Datenbanken jedoch die Ergebnisse dieser Abfrage verfälschen. Da diese Datenbanken nicht gültig sind und nicht Teil regelmäßiger Wartungsprüfungen sein sollten, können sie zu einem falsch-positiven Ergebnis führen, sodass Sie glauben, dass der `age(datfrozenxid)`-Wert höher ist, als er tatsächlich ist.
## Anpassen der Überwachungsanfrage
Um eine genaue Überwachung zu gewährleisten, sollten Sie Ihre Überwachungsabfrage so anpassen, dass ungültige Datenbanken ausgeschlossen werden. Folgen Sie dieser empfohlenen Abfrage:
```
SELECT
max(age(datfrozenxid))
FROM
pg_database
WHERE
datconnlimit <> -2;
```
Diese Abfrage stellt sicher, dass nur gültige Datenbanken bei der `age(datfrozenxid)`-Berechnung berücksichtigt werden, sodass das Alter der Transaktions-ID in Ihrer gesamten PostgreSQL-Umgebung genau wiedergegeben wird.
## Beheben des Problems mit ungültigen Datenbanken
Wenn Sie versuchen, eine Verbindung zu einer ungültigen Datenbank herzustellen, wird möglicherweise eine Fehlermeldung ähnlich der folgenden angezeigt:
```
postgres=> \c db1
connection to server at "mydb.xxxxxxxxxx.us-west-2.rds.amazonaws.com" (xx.xx.xx.xxx), port xxxx failed: FATAL: cannot connect to invalid database "db1"
HINT: Use DROP DATABASE to drop invalid databases.
Previous connection kept
```
Wenn darüber hinaus der `log_min_messages`-Parameter auf `DEBUG2` oder höher gesetzt ist, fallen Ihnen möglicherweise die folgenden Protokolleinträge auf, die darauf hinweisen, dass der Selbstbereinigungsprozess die ungültige Datenbank überspringt:
```
2024-07-30 05:59:00 UTC::@:[32000]:DEBUG: autovacuum: skipping invalid database "db6"
2024-07-30 05:59:00 UTC::@:[32000]:DEBUG: autovacuum: skipping invalid database "db1"
```
Um dieses Problem zu beheben, befolgen Sie den `HINT`, der während des Verbindungsversuchs ausgegeben wurde. Stellen Sie mit Ihrem RDS-Master-Konto oder einem Datenbankkonto mit der `rds_superuser`-Rolle eine Verbindung zu einer gültigen Datenbank her und verwerfen Sie ungültige Datenbanken.
```
SELECT
'DROP DATABASE ' || quote_ident(datname) || ';'
FROM
pg_database
WHERE
datconnlimit = -2 \gexec
```
# Identifizieren und Beheben von Problemen mit Blockern aggressiver Bereinigungen in RDS für PostgreSQL
In PostgreSQL ist die Bereinigung von entscheidender Bedeutung zur Sicherstellung der Integrität der Datenbank, da durch diese Speicherplatz zurückgewonnen wird und Probleme mit [Transaktions-ID-Wraparounds](https://www.postgresql.org/docs/current/routine-vacuuming.html#VACUUM-FOR-WRAPAROUND) vermieden werden. Manchmal wird eine reibungslose Bereinigung jedoch verhindert, was zu Leistungseinbußen, einem aufgeblähten Speicher und sogar zu einer Beeinträchtigung der Verfügbarkeit Ihrer DB-Instance durch einen Transaktions-ID-Wraparound führen kann. Daher ist die Identifizierung und Lösung dieser Probleme für eine optimale Datenbankleistung und -verfügbarkeit unerlässlich. Lesen Sie [Understanding autovacuum in Amazon RDS für PostgreSQL environments](https://aws.amazon.com/blogs/database/understanding-autovacuum-in-amazon-rds-for-postgresql-environments/), um mehr über die Selbstbereinigung zu erfahren.
Die `postgres_get_av_diag()`-Funktion hilft bei der Identifizierung von Problemen, die den aggressiven Bereinigungsprozess entweder verhindern oder verzögern. Es werden Vorschläge bereitgestellt, die Befehle zur Behebung des Problems beinhalten können, wenn es identifiziert werden kann, oder Anleitungen für weitere Diagnosen, wenn das Problem nicht identifiziert werden kann. Aggressive Vakuumblocker werden gemeldet, wenn das Alter den [adaptiven Autovakuum-Schwellenwert](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.md#Appendix.PostgreSQL.CommonDBATasks.Autovacuum.AdaptiveAutoVacuuming) von 500 Millionen Transaktionen von RDS überschreitet. IDs
**Wie alt ist die Transaktions-ID?**
Die `age()` Transaktionsfunktion IDs berechnet die Anzahl der Transaktionen, die seit der ältesten nicht eingefrorenen Transaktions-ID für eine Datenbank (`pg_database.datfrozenxid`) oder Tabelle () stattgefunden haben. `pg_class.relfrozenxid` Dieser Wert gibt die Datenbankaktivität seit dem letzten aggressiven Bereinigungsvorgang an und zeigt den wahrscheinlichen Workload für bevorstehende VACUUM-Prozesse auf.
**Was ist eine aggressive Bereinigung?**
Eine aggressive VACUUM-Operation führt einen umfassenden Scan aller Seiten innerhalb einer Tabelle durch, einschließlich der Seiten, die normalerweise während der regulären Tabelle übersprungen werden. VACUUMs Dieser gründliche Scan zielt darauf ab, Transaktionen, die IDs sich ihrem Höchstalter nähern, „einzufrieren“ und so eine Situation, die als [Transaktions-ID-Wraparound](https://www.postgresql.org/docs/current/routine-vacuuming.html#VACUUM-FOR-WRAPAROUND) bezeichnet wird, effektiv zu verhindern.
Damit `postgres_get_av_diag()` Blocker meldet, muss der Blocker mindestens 500 Millionen Transaktionen alt sein.
**Topics**
+ [Installieren von Überwachungs- und Diagnosetools für die Selbstbereinigung in RDS für PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Installation.md)
+ [Funktionen von postgres\$1get\$1av\$1diag() in RDS für PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Functions.md)
+ [Beseitigen von identifizierbaren Bereinigungsblockern in RDS für PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Resolving_Identifiableblockers.md)
+ [Beheben von nicht identifizierbaren Bereinigungsblockern in RDS für PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Unidentifiable_blockers.md)
+ [Beheben von Leistungsproblemen bei der Bereinigung in RDS für PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Resolving_Performance.md)
+ [Erläuterung der HINWEIS-Meldungen in RDS für PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.NOTICE.md)
# Installieren von Überwachungs- und Diagnosetools für die Selbstbereinigung in RDS für PostgreSQL
Die `postgres_get_av_diag()`-Funktion ist derzeit in den folgenden Versionen von RDS für PostgreSQL verfügbar:
+ 17.2 und höhere 17-Versionen
+ 16.7 und höher 16 Versionen
+ 15.11 und höhere 15-Versionen
+ 14.16 und höhere 14-Versionen
+ 13.19 und höhere 13-Versionen
Um `postgres_get_av_diag()` zu verwenden, erstellen Sie die `rds_tools`-Erweiterung.
```
postgres=> CREATE EXTENSION rds_tools ;
CREATE EXTENSION
```
Stellen Sie sicher, dass die Erweiterung installiert ist.
```
postgres=> \dx rds_tools
List of installed extensions
Name | Version | Schema | Description
----------+---------+-----------+----------------------------------------------------------
rds_tools | 1.8 | rds_tools | miscellaneous administrative functions for RDS PostgreSQL
1 row
```
Stellen Sie sicher, dass die Funktion erstellt ist.
```
postgres=> SELECT
proname function_name,
pronamespace::regnamespace function_schema,
proowner::regrole function_owner
FROM
pg_proc
WHERE
proname = 'postgres_get_av_diag';
function_name | function_schema | function_owner
----------------------+-----------------+----------------
postgres_get_av_diag | rds_tools | rds_superuser
(1 row)
```
# Funktionen von postgres\$1get\$1av\$1diag() in RDS für PostgreSQL
The `postgres_get_av_diag()`-Funktion ruft Diagnoseinformationen über Selbstbereinigungsprozesse ab, die in einer Datenbank von RDS für PostgreSQL blockiert sind oder zeitlich verzögert erfolgen. Die Abfrage muss in der Datenbank mit der ältesten Transaktions-ID ausgeführt werden, damit genaue Ergebnisse geliefert werden. Weitere Informationen zur Verwendung der Datenbank mit der ältesten Transaktions-ID finden Sie unter [Keine Verbindung zur Datenbank mit dem Alter der ältesten Transaktions-ID](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.NOTICE.md)
```
SELECT
blocker,
DATABASE,
blocker_identifier,
wait_event,
TO_CHAR(autovacuum_lagging_by, 'FM9,999,999,999') AS autovacuum_lagging_by,
suggestion,
suggested_action
FROM (
SELECT
*
FROM
rds_tools.postgres_get_av_diag ()
ORDER BY
autovacuum_lagging_by DESC) q;
```
Die `postgres_get_av_diag()`-Funktion gibt eine Tabelle mit folgenden Informationen zurück:
**blocker**
Gibt die Kategorie der Datenbankaktivität an, die die Selbstbereinigung blockiert
+ [Aktive Anweisung](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Resolving_Identifiableblockers.md#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Active_statement)
+ [Leerlauf in Transaktion](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Resolving_Identifiableblockers.md#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Idle_in_transaction)
+ [Vorbereitete Transaktion](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Resolving_Identifiableblockers.md#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Prepared_transaction)
+ [Logischer Replikations-Slot](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Resolving_Identifiableblockers.md#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Logical_replication_slot)
+ [Lesereplikat mit physischen Replikations-Slots](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Resolving_Identifiableblockers.md#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Read_replicas)
+ [Lesereplikat mit Streaming-Replikation](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Resolving_Identifiableblockers.md#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Read_replicas)
+ [Temporäre Tabellen](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Resolving_Identifiableblockers.md#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Temporary_tables)
**Datenbank**
Gibt den Namen der Datenbank an, sofern zutreffend und unterstützt. Dies ist die Datenbank, in der die Aktivität ausgeführt wird und die Selbstbereinigung blockiert oder blockieren wird. Dies ist die Datenbank, zu der Sie eine Verbindung herstellen und für die Sie Maßnahmen ergreifen müssen.
**blocker\$1identifier**
Gibt die ID der Aktivität an, die den Selbstbereinigungsprozess blockiert oder blockieren wird. Bei der ID kann es sich um eine Prozess-ID in Kombination mit einer SQL-Anweisung, einer vorbereiteten Transaktion, einer IP-Adresse einem Lesereplikat und dem Namen des logischen oder physischen Replikationsslots handeln.
**wait\$1event**
Gibt das [Warteereignis](PostgreSQL.Tuning.md) der blockierenden Sitzung an und gilt für die folgenden Blocker:
+ Aktive Anweisung
+ Leerlauf in Transaktion
**autovacum\$1lagging\$1by**
Gibt pro Kategorie die Anzahl der Transaktionen an, bei denen die Selbstbereinigungsfunktion hinsichtlich der Backlog-Arbeiten im Rückstand ist
**-Vorschlag**
Gibt Vorschläge zur Behebung des Blocker-Problems an. Diese Anleitungen enthalten gegebenenfalls den Namen der Datenbank, in der die Aktivität vorhanden ist, gegebenenfalls die Prozess-ID (PID) der Sitzung und die auszuführende Aktion.
**suggested\$1action**
Schlägt die Aktion vor, die ergriffen werden muss, um das Blocker-Problem zu beheben
# Beseitigen von identifizierbaren Bereinigungsblockern in RDS für PostgreSQL
Der Selbstbereinigungsprozess führt aggressive Bereinigungen durch und senkt das Alter der Transaktions-IDs auf einen Wert unterhalb des Schwellenwerts, der durch den `autovacuum_freeze_max_age`-Parameter Ihrer RDS-Instance angegeben ist. Sie können dieses Alter mit der `MaximumUsedTransactionIDs`-Metrik von Amazon CloudWatch nachverfolgen.
Zum Ermitteln der Einstellung von `autovacuum_freeze_max_age` (der Standardwert ist 200 Millionen Transaktions-IDs) für Ihre Amazon-RDS-Instance eignet sich folgende Abfrage:
```
SELECT
TO_CHAR(setting::bigint, 'FM9,999,999,999') autovacuum_freeze_max_age
FROM
pg_settings
WHERE
name = 'autovacuum_freeze_max_age';
```
Beachten Sie, dass `postgres_get_av_diag()` nur dann nach Blockern aggressiver Bereinigungen sucht, wenn das Alter den Schwellenwert für die [adaptive Selbstbereinigung](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.md#Appendix.PostgreSQL.CommonDBATasks.Autovacuum.AdaptiveAutoVacuuming) von Amazon RDS von 500 Millionen Transaktions-IDs überschreitet. Damit `postgres_get_av_diag()` Blocker erkennt, muss der Blocker mindestens 500 Millionen Transaktionen alt sein.
Die `postgres_get_av_diag()`-Funktion identifiziert die folgenden Arten von Blockern:
**Topics**
+ [Aktive Anweisung](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Active_statement)
+ [Leerlauf in Transaktion](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Idle_in_transaction)
+ [Vorbereitete Transaktion](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Prepared_transaction)
+ [Logischer Replikations-Slot](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Logical_replication_slot)
+ [Read Replicas](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Read_replicas)
+ [Temporäre Tabellen](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Temporary_tables)
## Aktive Anweisung
In PostgreSQL ist eine aktive Anweisung eine SQL-Anweisung, die aktuell von der Datenbank ausgeführt wird. Dazu gehören Abfragen, Transaktionen sowie laufende Operationen. Bei der Überwachung mit `pg_stat_activity` wird in der Statusspalte angegeben, dass der Prozess mit der entsprechenden PID aktiv ist.
Die `postgres_get_av_diag()`-Funktion liefert eine Ausgabe ähnlich der folgenden, wenn sie eine Anweisung identifiziert, die inaktiv ist.
```
blocker | Active statement
database | my_database
blocker_identifier | SELECT pg_sleep(20000);
wait_event | Timeout:PgSleep
autovacuum_lagging_by | 568,600,871
suggestion | Connect to database "my_database", review carefully and you may consider terminating the process using suggested_action. For more information, see Working with PostgreSQL autovacuum in the Amazon RDS User Guide.
suggested_action | {"SELECT pg_terminate_backend (29621);"}
```
**Vorgeschlagene Aktion**
Gemäß der Empfehlung in der `suggestion`-Spalte kann der Benutzer eine Verbindung zu der Datenbank herstellen, in der sich die aktive Anweisung befindet. Wie in der `suggested_action`-Spalte angegeben, ist es ratsam, die Option zum Beenden der Sitzung sorgfältig zu prüfen. Wenn die Beendigung sicher ist, können Sie die Sitzung mit der `pg_terminate_backend()`-Funktion beenden. Diese Aktion kann von einem Administrator (z. B. dem RDS-Master-Konto) oder einem Benutzer mit der erforderlichen `pg_terminate_backend()`-Berechtigung durchgeführt werden.
**Warnung**
Eine beendete Sitzung macht die von ihr vorgenommenen Änderungen rückgängig (`ROLLBACK`). Abhängig von Ihren Anforderungen kann es jedoch sein, dass Sie die Anweisung erneut ausführen möchten. Sie sollten dies jedoch erst tun, wenn der Selbstbereinigungsprozess die aggressive Bereinigung abgeschlossen hat.
## Leerlauf in Transaktion
Eine „idle in transaction“-Anweisung bezieht sich auf jede Sitzung mit einer offenen, expliziten Transaktion (z. B. durch Ausgabe einer `BEGIN`-Anweisung), in der einige Arbeiten ausgeführt wurden und die nun darauf wartet, dass der Client entweder weitere Aufgaben übergibt oder das Ende der Transaktion durch Ausgabe von `COMMIT`, `ROLLBACK` oder `END` signalisiert (was zu einem impliziten `COMMIT` führen würde).
Die `postgres_get_av_diag()`-Funktion liefert eine Ausgabe ähnlich der folgenden, wenn sie eine `idle in transaction`-Anweisung als Blocker identifiziert.
```
blocker | idle in transaction
database | my_database
blocker_identifier | INSERT INTO tt SELECT * FROM tt;
wait_event | Client:ClientRead
autovacuum_lagging_by | 1,237,201,759
suggestion | Connect to database "my_database", review carefully and you may consider terminating the process using suggested_action. For more information, see Working with PostgreSQL autovacuum in the Amazon RDS User Guide.
suggested_action | {"SELECT pg_terminate_backend (28438);"}
```
**Vorgeschlagene Aktion**
Wie in der `suggestion`-Spalte angegeben, können Sie eine Verbindung zu der Datenbank mit der „idle in transaction“-Sitzung herstellen und die Sitzung mit der `pg_terminate_backend()`-Funktion beenden. Der Benutzer kann Ihr Admin-Benutzer (RDS-Master-Konto) oder ein Benutzer mit der `pg_terminate_backend()`-Berechtigung sein.
**Warnung**
Eine beendete Sitzung macht die von ihr vorgenommenen Änderungen rückgängig (`ROLLBACK`). Abhängig von Ihren Anforderungen kann es jedoch sein, dass Sie die Anweisung erneut ausführen möchten. Sie sollten dies jedoch erst tun, wenn der Selbstbereinigungsprozess die aggressive Bereinigung abgeschlossen hat.
## Vorbereitete Transaktion
PostgreSQL ermöglicht Transaktionen, die Teil einer zweiphasigen Commit-Strategie sind, auch bekannt als [vorbereitete Transaktionen](https://www.postgresql.org/docs/current/sql-prepare-transaction.html). Diese werden aktiviert, indem der `max_prepared_transactions`-Parameter auf einen Wert ungleich Null gesetzt wird. Vorbereitete Transaktionen sollen sicherstellen, dass eine Transaktion dauerhaft ist und auch nach Datenbankabstürzen, Neustarts oder Verbindungsabbrüchen des Clients verfügbar bleibt. Genau wie reguläre Transaktionen erhalten sie eine Transaktions-ID und können die Selbstbereinigung beeinflussen. Wenn sie im Zustand „vorbereitet“ verbleiben, kann die Selbstbereinigungsfunktion keine Einfrierungen durchführen und es kann zu einem Transaktions-ID-Wraparound kommen.
Wenn Transaktionen auf unbestimmte Zeit in diesem Zustand verbleiben, ohne dass dieser von einem Transaktionsmanager aufgehoben wird, werden sie zu verwaisten vorbereiteten Transaktionen. Die einzige Möglichkeit, dieses Problem zu beheben, besteht darin, die Transaktion mit den Befehlen `COMMIT PREPARED` oder `ROLLBACK PREPARED` festzuschreiben bzw. rückgängig zu machen.
**Anmerkung**
Beachten Sie, dass ein Backup, das während einer vorbereiteten Transaktion erstellt wurde, diese Transaktion auch nach der Wiederherstellung noch enthält. Sehen Sie sich die folgenden Informationen genauer an, um mehr über das Finden und Beenden solcher Transaktionen zu erfahren.
Die `postgres_get_av_diag()`-Funktion liefert die folgende Ausgabe, wenn sie eine vorbereitete Transaktion als Blocker identifiziert.
```
blocker | Prepared transaction
database | my_database
blocker_identifier | myptx
wait_event | Not applicable
autovacuum_lagging_by | 1,805,802,632
suggestion | Connect to database "my_database" and consider either COMMIT or ROLLBACK the prepared transaction using suggested_action. For more information, see Working with PostgreSQL autovacuum in the Amazon RDS User Guide.
suggested_action | {"COMMIT PREPARED 'myptx';",[OR],"ROLLBACK PREPARED 'myptx';"}
```
**Vorgeschlagene Aktion**
Stellen Sie, wie in der Vorschlagsspalte angegeben, eine Verbindung zu der Datenbank her, auf der sich die vorbereitete Transaktion befindet. Prüfen Sie basierend auf der `suggested_action`-Spalte sorgfältig, ob Sie entweder `COMMIT` oder ausführen `ROLLBACK` möchten und welche Aktion dann angemessen ist.
Zur allgemeinen Überwachung vorbereiteter Transaktionen bietet PostgreSQL eine Katalogansicht mit der Bezeichnung `pg_prepared_xacts`. Sie können die folgende Abfrage verwenden, um vorbereitete Transaktionen zu finden.
```
SELECT
gid,
prepared,
owner,
database,
transaction AS oldest_xmin
FROM
pg_prepared_xacts
ORDER BY
age(transaction) DESC;
```
## Logischer Replikations-Slot
Zweck eines Replikations-Slots ist es, nicht genutzte Änderungen so lange aufzubewahren, bis sie auf einen Zielserver repliziert wurden. Weitere Informationen finden Sie in der PostgreSQL-Dokumentation unter [Logische Replikation](https://www.postgresql.org/docs/current/logical-replication.html).
Es gibt zwei Arten von logischen Replikations-Slots.
**Inaktive logische Replikations-Slots**
Wenn die Replikation beendet wird, können nicht genutzte Transaktionsprotokolle nicht entfernt werden und der Replikations-Slot wird inaktiv. Obwohl ein inaktiver logischer Replikations-Slot derzeit nicht von einem Subscriber verwendet wird, verbleibt er auf dem Server, was zur Aufbewahrung von WAL-Dateien führt und verhindert, dass alte Transaktionsprotokolle entfernt werden. Dies kann die Festplattennutzung erhöhen und insbesondere verhindern, dass der Selbstbereinigungsprozess interne Katalogtabellen bereinigt, da das System verhindern muss, dass LSN-Informationen überschrieben werden. Wird dieses Problem nicht behoben, kann das zu einem Aufblähen des Katalogs, zu Leistungseinbußen und zu einem erhöhten Risiko für eine Wraparound-Bereinigung führen, was wiederum Transaktionsausfallzeiten nach sich ziehen kann.
**Aktive, aber langsame logische Replikations-Slots**
Manchmal verzögert sich das Entfernen toter Katalog-Tupel aufgrund von Leistungseinbußen bei der logischen Replikation. Diese Verzögerung bei der Replikation verlangsamt die Aktualisierung von `catalog_xmin`und kann zu einem aufgeblähten Katalog und einer Wraparound-Bereinigung führen.
Die `postgres_get_av_diag()`-Funktion liefert eine Ausgabe ähnlich der folgenden, wenn sie einen logischen Replikations-Slot als Blocker identifiziert.
```
blocker | Logical replication slot
database | my_database
blocker_identifier | slot1
wait_event | Not applicable
autovacuum_lagging_by | 1,940,103,068
suggestion | Ensure replication is active and resolve any lag for the slot if active. If inactive, consider dropping it using the command in suggested_action. For more information, see Working with PostgreSQL autovacuum in the Amazon RDS User Guide.
suggested_action | {"SELECT pg_drop_replication_slot('slot1') FROM pg_replication_slots WHERE active = 'f';"}
```
**Vorgeschlagene Aktion**
Überprüfen Sie zur Behebung des Problems die Replikationskonfiguration auf Probleme mit dem Zielschema oder Daten, die den Anwendungsprozess möglicherweise beenden. Die häufigsten Gründe sind die folgenden:
+ fehlende Spalten
+ inkompatibler Datentyp
+ nicht übereinstimmende Daten
+ fehlende Tabelle
Wenn das Problem mit Infrastrukturproblemen zusammenhängt:
+ Netzwerkprobleme – [Wie behebe ich Probleme mit einer Amazon-RDS-Datenbank, die sich in einem inkompatiblen Netzwerkstatus befindet?](https://repost.aws/knowledge-center/rds-incompatible-network)
+ Die Datenbank oder DB-Instance ist aus folgenden Gründen nicht verfügbar:
+ Die Replikat-Instance hat keinen Speicherplatz mehr – Sehen Sie unter [Wie behebe ich Probleme, die auftreten, wenn den Amazon-RDS-DB-Instances der Speicherplatz ausgeht?](https://repost.aws/knowledge-center/rds-out-of-storage) nach, um mehr über das Hinzufügen von Speicherplatz zu erfahren.
+ Incompatible-parameters – Sehen Sie unter [Wie behebe ich Fehler bei einer Amazon-RDS-DB-Instance, die im Status „incompatible-parameters“ feststeckt?](https://repost.aws/knowledge-center/rds-incompatible-parameters) nach, um mehr über die Behebung des Problems zu erfahren.
Wenn sich Ihre Instance außerhalb des AWS-Netzwerks oder auf AWS-EC2 befindet, wenden Sie sich an Ihren Administrator, um zu erfahren, wie Sie die Verfügbarkeits- oder Infrastrukturprobleme lösen können.
**Löschen des inaktiven Slots**
**Warnung**
Achtung: Vergewissern Sie sich vor dem Löschen eines Replikations-Slots, dass dieser keine laufende Replikation aufweist, inaktiv ist und sich im Zustand „nicht wiederherstellbar“ befindet. Das vorzeitige Löschen eines Slots kann zu Replikationsunterbrechungen oder Datenverlust führen.
Nachdem Sie sich vergewissert haben, dass der Replikations-Slot nicht mehr benötigt wird, löschen Sie diesen, damit die Selbstbereinigung fortgesetzt werden kann. Die `active = 'f'`-Bedingung sorgt dafür, dass nur ein inaktiver Slot gelöscht wird.
```
SELECT pg_drop_replication_slot('slot1') WHERE active ='f'
```
## Read Replicas
Wenn die `hot_standby_feedback`-Einstellung für [Lesereplikate von Amazon RDS](USER_PostgreSQL.Replication.ReadReplicas.md) aktiviert ist, verhindert sie, dass der Selbstbereinigungsprozess auf der primären Datenbank tote Zeilen entfernt, die möglicherweise noch von Abfragen benötigt werden, die auf dem Lesereplikat ausgeführt werden. Dies hat Auswirkungen auf alle Arten von physischen Lesereplikaten, einschließlich solcher, die mit oder ohne Replikations-Slots verwaltet werden. Dieses Verhalten ist notwendig, da Abfragen, die auf dem Standby-Replikat ausgeführt werden, erfordern, dass diese Zeilen auf der primären Datenbank verfügbar bleiben, um [Abfragekonflikte](https://www.postgresql.org/docs/current/hot-standby.html#HOT-STANDBY-CONFLICT) und -abbrüche zu vermeiden.
**Lesereplikat mit physischen Replikations-Slots**
Lesereplikate mit physischen Replikations-Slots verbessern die Zuverlässigkeit und Stabilität der Replikation in RDS für PostgreSQL erheblich. Diese Slots stellen sicher, dass die primäre Datenbank wichtige Write-Ahead-Protokolldateien aufbewahrt, bis das Replikat diese verarbeitet, sodass die Datenkonsistenz auch bei Netzwerkunterbrechungen gewahrt bleibt.
Ab Version 14 von RDS für PostgreSQL verwenden alle Replikate Replikations-Slots. In früheren Versionen wurden Replikations-Slots nur von regionsübergreifenden Replikaten verwendet.
Die `postgres_get_av_diag()`-Funktion liefert eine Ausgabe ähnlich der folgenden, wenn sie ein Lesereplikat mit einem physischen Replikations-Slot als Blocker identifiziert.
```
blocker | Read replica with physical replication slot
database |
blocker_identifier | rds_us_west_2_db_xxxxxxxxxxxxxxxxxxxxx
wait_event | Not applicable
autovacuum_lagging_by | 554,080,689
suggestion | Run the following query on the replica "rds_us_west_2_db_xxxxxxxxxxxxxxxxxxxx" to find the long running query:
| SELECT * FROM pg_catalog.pg_stat_activity WHERE backend_xmin::text::bigint = 757989377;
| Review carefully and you may consdier terminating the query on read replica using suggested_action. For more information, see Working with PostgreSQL autovacuum in the Amazon RDS User Guide. + |
suggested_action | {"SELECT pg_terminate_backend(pid) FROM pg_catalog.pg_stat_activity WHERE backend_xmin::text::bigint = 757989377;"," +
| [OR] +
| ","Disable hot_standby_feedback"," +
| [OR] +
| ","Delete the read replica if not needed"}
```
**Lesereplikat mit Streaming-Replikation**
Amazon RDS ermöglicht die Einrichtung von Lesereplikaten ohne physischen Replikations-Slot in älteren Versionen bis Version 13. Dieser Ansatz reduziert den Overhead, da die primäre Datenbank WAL-Dateien aggressiver recyceln kann. Dies ist in Umgebungen mit begrenztem Speicherplatz von Vorteil. Zudem kann ein gelegentlicher ReplicaLag toleriert werden. Ohne Slot muss das Standby-Replikat jedoch synchron bleiben, um zu verhindern, dass WAL-Dateien fehlen. Amazon RDS verwendet archivierte WAL-Dateien, damit das Replikat gegebenenfalls einen Rückstand aufholen kann. Dieser Vorgang ist jedoch möglicherweise langsam und erfordert eine sorgfältige Überwachung.
Die `postgres_get_av_diag()`-Funktion liefert eine Ausgabe ähnlich der folgenden, wenn sie ein Streaming-Lesereplikat als Blocker identifiziert.
```
blocker | Read replica with streaming replication slot
database | Not applicable
blocker_identifier | xx.x.x.xxx/xx
wait_event | Not applicable
autovacuum_lagging_by | 610,146,760
suggestion | Run the following query on the replica "xx.x.x.xxx" to find the long running query: +
| SELECT * FROM pg_catalog.pg_stat_activity WHERE backend_xmin::text::bigint = 348319343; +
| Review carefully and you may consdier terminating the query on read replica using suggested_action. For more information, see Working with PostgreSQL autovacuum in the Amazon RDS User Guide. +
|
suggested_action | {"SELECT pg_terminate_backend(pid) FROM pg_catalog.pg_stat_activity WHERE backend_xmin::text::bigint = 348319343;"," +
| [OR] +
| ","Disable hot_standby_feedback"," +
| [OR] +
| ","Delete the read replica if not needed"}
```
**Vorgeschlagene Aktion**
Wie in der `suggested_action`-Spalte empfohlen, sollten Sie diese Optionen sorgfältig prüfen, um die Blockierung des Selbstbereinigungsprozesses aufzuheben.
+ **Abfrage beenden** – Gemäß der Empfehlung in der Vorschlagspalte können Sie eine Verbindung zum Lesereplikat herstellen. Laut der suggested\$1action-Spalte empfiehlt es sich jedoch, die Option zum Beenden der Sitzung sorgfältig zu prüfen. Wenn die Beendigung als sicher erachtet wird, können Sie die Sitzung mit der `pg_terminate_backend()`-Funktion beenden. Diese Aktion kann von einem Administrator (z. B. dem RDS-Master-Konto) oder einem Benutzer mit der erforderlichen pg\$1terminate\$1backend()-Berechtigung durchgeführt werden.
Sie können den folgenden SQL-Befehl auf dem Lesereplikat ausführen, um die Abfrage zu beenden, die verhindert, dass der Bereinigungsprozess auf der primären Datenbank alte Zeilen löscht. Der Wert von `backend_xmin` wird in der Ausgabe der Funktion gemeldet:
```
SELECT
pg_terminate_backend(pid)
FROM
pg_catalog.pg_stat_activity
WHERE
backend_xmin::text::bigint = backend_xmin;
```
+ **Hot-Standby-Feedback deaktivieren** – Erwägen Sie, den `hot_standby_feedback`-Parameter zu deaktivieren, wenn er zu erheblichen Verzögerungen bei der Bereinigung führt.
Der `hot_standby_feedback`-Parameter ermöglicht einem Lesereplikat, die primäre Datenbank über seine Abfrageaktivität zu informieren. Dadurch wird verhindert, dass diese Tabellen entfernt, die auf dem Standby-Replikat verwendet werden. Dadurch wird zwar die Stabilität der Abfrage auf diesem gewährleistet, die Bereinigung auf der primären Datenbank kann sich jedoch erheblich verzögern. Wenn Sie diese Funktion deaktivieren, kann die Bereinigung auf der primären Datenbank fortgesetzt werden, ohne dass darauf gewartet werden muss, dass das Standby-Replikat aufholt. Dies kann jedoch zu Abfrageabbrüchen oder -fehlern auf dem Standby-Replikat führen, wenn versucht wird, auf Zeilen zuzugreifen, die auf der primären Datenbank bereinigt wurden.
+ **Nicht benötigtes Lesereplikat löschen** – Wenn das Lesereplikat nicht mehr benötigt wird, können Sie es löschen. Dadurch entfällt der damit verbundene Replikations-Overhead und ermöglicht das Recyclen von Transaktionsprotokollen auf der primären Datenbank, ohne vom Replikat zurückgehalten zu werden.
## Temporäre Tabellen
[Temporäre Tabellen](https://www.postgresql.org/docs/current/sql-createtable.html), die mit dem `TEMPORARY`-Schlüsselwort erstellt wurden, befinden sich im temporären Schema, z. B. in pg\$1temp\$1xxx, und sind nur für die Sitzung zugänglich, in der sie erstellt wurden. Temporäre Tabellen werden gelöscht, wenn die Sitzung endet. Diese Tabellen sind jedoch für den Selbstbereinigungsprozess von PostgreSQL unsichtbar und müssen manuell von der Sitzung bereinigt werden, von der sie erstellt wurden. Der Versuch, die temporäre Tabelle von einer anderen Sitzung aus bereinigen zu lassen, hat keine Wirkung.
In seltenen Fällen kann es eine temporäre Tabelle geben, die keiner aktiven Sitzung angehört. Wenn die innehabende Sitzung aufgrund eines fatalen Absturzes, eines Netzwerkproblems oder eines ähnlichen Ereignisses unerwartet beendet wird, wird die temporäre Tabelle möglicherweise nicht bereinigt, sodass sie als „verwaiste“ Tabelle zurückbleibt. Wenn der Selbstbereinigungsprozess von PostgreSQL eine solche verwaiste temporäre Tabelle entdeckt, protokolliert er die folgende Meldung:
```
LOG: autovacuum: found orphan temp table \"%s\".\"%s\" in database \"%s\"
```
Die `postgres_get_av_diag()`-Funktion liefert eine Ausgabe ähnlich der folgenden, wenn sie eine temporäre Tabelle als Blocker identifiziert. Damit die Funktion die Ausgabe in Bezug auf temporäre Tabellen korrekt anzeigt, muss sie auf der Datenbank ausgeführt werden, auf der diese Tabellen vorhanden sind.
```
blocker | Temporary table
database | my_database
blocker_identifier | pg_temp_14.ttemp
wait_event | Not applicable
autovacuum_lagging_by | 1,805,802,632
suggestion | Connect to database "my_database". Review carefully, you may consider dropping temporary table using command in suggested_action. For more information, see Working with PostgreSQL autovacuum in the Amazon RDS User Guide.
suggested_action | {"DROP TABLE ttemp;"}
```
**Vorgeschlagene Aktion**
Folgen Sie den Anleitungen aus der `suggestion`-Spalte der Ausgabe, um die temporäre Tabelle zu identifizieren und zu entfernen, die die Ausführung des Selbstbereinigungsprozesses verhindert. Verwenden Sie den folgenden Befehl, um die temporäre Tabelle zu löschen, die von `postgres_get_av_diag()` gemeldet wurde. Ersetzen Sie den Tabellennamen auf der Grundlage der von der `postgres_get_av_diag()`-Funktion gelieferten Ausgabe.
```
DROP TABLE my_temp_schema.my_temp_table;
```
Mit der folgenden Abfrage können temporäre Tabellen identifiziert werden:
```
SELECT
oid,
relname,
relnamespace::regnamespace,
age(relfrozenxid)
FROM
pg_class
WHERE
relpersistence = 't'
ORDER BY
age(relfrozenxid) DESC;
```
# Beheben von nicht identifizierbaren Bereinigungsblockern in RDS für PostgreSQL
In diesem Abschnitt werden weitere Gründe für ein Verhindern des Fortschritts bei der Bereinigung untersucht. Diese Probleme können derzeit nicht direkt mit der `postgres_get_av_diag()`-Funktion identifiziert werden.
**Topics**
+ [Ungültige Seiten](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Invalid_pages)
+ [Index-Inkonsistenz](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Index_inconsistency)
+ [Außergewöhnlich hohe Transaktionsrate](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.High_transaction_rate)
## Ungültige Seiten
Ein Fehler aufgrund einer ungültigen Seite tritt auf, wenn PostgreSQL beim Zugriff auf diese Seite eine Nichtübereinstimmung bei der Prüfsumme dieser Seite feststellt. Der Inhalt ist nicht lesbar, wodurch verhindert wird, dass der Selbstbereinigungsprozess Tupel einfrieren kann. Dadurch wird der Bereinigungsprozess effektiv gestoppt. Der folgende Fehler wird im Protokoll von PostgreSQL erfasst:
```
WARNING: page verification failed, calculated checksum YYYYY but expected XXXX
ERROR: invalid page in block ZZZZZ of relation base/XXXXX/XXXXX
CONTEXT: automatic vacuum of table myschema.mytable
```
**Ermitteln des Objekttyps**
```
ERROR: invalid page in block 4305910 of relation base/16403/186752608
WARNING: page verification failed, calculated checksum 50065 but expected 60033
```
Aus der Fehlermeldung geht hervor, dass der `base/16403/186752608`-Pfad die folgenden Informationen bereitstellt:
+ „base“ ist der Verzeichnisname unter dem PostgreSQL-Datenverzeichnis.
+ „16403“ ist die Datenbank-OID, die Sie im `pg_database`-Systemkatalog nachschlagen können.
+ „186752608“ steht für `relfilenode` und kann verwendet werden, um das Schema und den Objektnamen im `pg_class`-Systemkatalog nachzuschlagen.
Indem Sie die Ausgabe der folgenden Abfrage in der betroffenen Datenbank überprüfen, können Sie den Objekttyp ermitteln. Die folgende Abfrage ruft Objektinformationen für diese OID ab: 186752608. Ersetzen Sie die OID durch die OID, die für den aufgetretenen Fehler relevant ist.
```
SELECT
relname AS object_name,
relkind AS object_type,
nspname AS schema_name
FROM
pg_class c
JOIN pg_namespace n ON c.relnamespace = n.oid
WHERE
c.oid = 186752608;
```
Weitere Informationen finden Sie in der PostgreSQL-Dokumentation [https://www.postgresql.org/docs/current/catalog-pg-class.html](https://www.postgresql.org/docs/current/catalog-pg-class.html) für alle unterstützten Objekttypen, die in der `relkind`-Spalte in `pg_class` aufgeführt sind.
**Empfehlungen**
Die effektivste Lösung für dieses Problem hängt von der Konfiguration Ihrer spezifischen Amazon-RDS-Instance und der Art der Daten ab, die von der inkonsistenten Seite betroffen sind.
**Wenn der Objekttyp ein Index ist:**
Es wird empfohlen, den Index neu zu erstellen.
+ **Verwenden der `CONCURRENTLY`-Option** – Vor PostgreSQL-Version 12 erforderte die Neuerstellung eines Index eine exklusive Tabellensperre, die den Zugriff auf die Tabelle einschränkte. In PostgreSQL-Version 12 und höheren Versionen ermöglicht die `CONCURRENTLY`-Option das Sperren auf Zeilenebene, wodurch die Verfügbarkeit der Tabelle erheblich verbessert wird. Dies ist der Befehl:
```
REINDEX INDEX ix_name CONCURRENTLY;
```
`CONCURRENTLY` ist zwar weniger störend, kann aber bei stark frequentierten Tabellen langsamer sein. Erwägen Sie, den Index nach Möglichkeit in Zeiten mit geringem Datenverkehr zu erstellen.
Weitere Informationen finden Sie in der PostgreSQL-Dokumentation zu [REINDEX](https://www.postgresql.org/docs/current/sql-reindex.html).
+ **Verwenden der `INDEX_CLEANUP FALSE`-Option** – Wenn die Indizes groß sind und vermutlich viel Zeit für die Fertigstellung benötigen, können Sie die Blockierung der Selbstbereinigung aufheben, indem Sie einen manuellen `VACUUM FREEZE`-Vorgang ausführen und dabei Indizes ausschließen. Diese Funktionalität ist in PostgreSQL-Version 12 und höheren Versionen verfügbar.
Durch das Umgehen von Indizes können Sie den Bereinigungsprozess des inkonsistenten Index überspringen und das Wraparound-Problem abmildern. Das zugrundeliegende Problem mit der ungültigen Seite wird dadurch jedoch nicht gelöst. Um das Problem mit der ungültigen Seite vollständig zu beheben, müssen Sie den Index dennoch neu erstellen.
**Wenn es sich bei dem Objekttyp um eine materialisierte Ansicht handelt:**
Wenn in einer materialisierten Ansicht ein Fehler aufgrund einer ungültigen Seite auftritt, melden Sie sich bei der betroffenen Datenbank an und aktualisieren Sie sie, um das Problem der ungültige Seite zu beheben:
Aktualisieren Sie die materialisierte Ansicht:
```
REFRESH MATERIALIZED VIEW schema_name.materialized_view_name;
```
Wenn die Aktualisierung fehlschlägt, versuchen Sie eine Neuerstellung:
```
DROP MATERIALIZED VIEW schema_name.materialized_view_name;
CREATE MATERIALIZED VIEW schema_name.materialized_view_name AS query;
```
Durch das Aktualisieren oder Neuerstellen der materialisierten Ansicht wird sie wiederhergestellt, ohne dass sich dies auf die zugrunde liegenden Tabellendaten auswirkt.
**Für alle anderen Objekttypen:**
Für alle anderen Objekttypen wenden Sie sich an den AWS Support.
## Index-Inkonsistenz
Ein logisch inkonsistenter Index kann verhindern, dass der Selbstbereinigungsprozess voranschreitet. Die folgenden oder ähnliche Fehler werden entweder während der Bereinigungsphase des Index oder beim Zugriff auf den Index durch SQL-Anweisungen protokolliert.
```
ERROR: right sibling's left-link doesn't match:block 5 links to 10 instead of expected 2 in index ix_name
```
```
ERROR: failed to re-find parent key in index "XXXXXXXXXX" for deletion target page XXX
CONTEXT: while vacuuming index index_name of relation schema.table
```
**Empfehlungen**
Erstellen Sie den Index neu oder überspringen Sie Indizes mittels `INDEX_CLEANUP` bei einem manuellen `VACUUM FREEZE`. Informationen zur Neuerstellung des Index finden Sie unter [Wenn der Objekttyp ein Index ist](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Invalid_pages).
+ **Verwenden der CONCURRENTLY-Option** – Vor PostgreSQL-Version 12 erforderte die Neuerstellung eines Index eine exklusive Tabellensperre, die den Zugriff auf die Tabelle einschränkte. In PostgreSQL-Version 12 und höheren Versionen ermöglicht die CONCURRENTLY-Option das Sperren auf Zeilenebene, wodurch die Verfügbarkeit der Tabelle erheblich verbessert wird. Dies ist der Befehl:
```
REINDEX INDEX ix_name CONCURRENTLY;
```
CONCURRENTLY ist zwar weniger störend, kann aber bei stark frequentierten Tabellen langsamer sein. Erwägen Sie, den Index nach Möglichkeit in Zeiten mit geringem Datenverkehr zu erstellen. Weitere Informationen finden Sie unter [REINDEX](https://www.postgresql.org/docs/current/sql-reindex.html) in der *PostgreSQL*-Dokumentation.
+ **Verwenden der INDEX\$1CLEANUP FALSE-Option** – Wenn die Indizes groß sind und vermutlich viel Zeit für die Fertigstellung benötigen, können Sie die Blockierung der Selbstbereinigung aufheben, indem Sie einen manuellen VACUUM-FREEZE-Vorgang ausführen und dabei Indizes ausschließen. Diese Funktionalität ist in PostgreSQL-Version 12 und höheren Versionen verfügbar.
Durch das Umgehen von Indizes können Sie den Bereinigungsprozess des inkonsistenten Index überspringen und das Wraparound-Problem abmildern. Das zugrundeliegende Problem mit der ungültigen Seite wird dadurch jedoch nicht gelöst. Um das Problem mit der ungültigen Seite vollständig zu beheben, müssen Sie den Index dennoch neu erstellen.
## Außergewöhnlich hohe Transaktionsrate
In PostgreSQL können hohe Transaktionsraten die Leistung der Selbstbereinigung erheblich beeinträchtigen, was zu einer langsameren Bereinigung toter Tupel und einem erhöhten Risiko für einen Transaktions-ID-Wraparound führt. Sie können die Transaktionsrate überwachen, indem Sie die Differenz hinsichtlich `max(age(datfrozenxid))` zwischen zwei Zeiträumen, typischerweise pro Sekunde, messen. Darüber hinaus können Sie die folgenden Zählermetriken von RDS Performance Insights verwenden, um die Transaktionsrate (die Summe aus xact\$1commit und xact\$1rollback) zu messen, die die Gesamtzahl der Transaktionen darstellt.
| Zähler | Typ | Einheit | Metrik |
| --- | --- | --- | --- |
| xact\$1commit | Transaktionen | Commits pro Sekunde | db.Transactions.xact\$1commit |
| xact\$1rollback | Transaktionen | Rollbacks pro Sekunde | db.Transactions.xact\$1rollback |
Ein schneller Anstieg deutet auf eine hohe Transaktionslast hin, die den Selbstbereinigungsvorgang überlasten und zu Aufblähungen, Sperrkonflikten und potenziellen Leistungsproblemen führen kann. Dies kann sich auf unterschiedliche Art und Weise negativ auf den Selbstbereinigungsprozess auswirken:
+ **Tabellenaktivität:** Bei der spezifischen Tabelle, die bereinigt wird, kann es zu einem hohen Transaktionsvolumen kommen, was möglicherweise Verzögerungen nach sich zieht.
+ **Systemressourcen:** Das gesamte System ist möglicherweise überlastet, sodass der Selbstbereinigungsprozess möglicherweise nur schwer auf die erforderlichen Ressourcen zugreifen kann, die für eine effiziente Durchführung erforderlich sind.
Ziehen Sie die folgenden Strategien in Betracht, damit der Selbstbereinigungsprozess effektiver verlaufen und seine Aufgaben ohne große Verzögerungen erfüllen kann.
1. Reduzieren Sie nach Möglichkeit die Transaktionsrate. Erwägen Sie, ähnliche Transaktionen nach Möglichkeit zu Stapeln zusammenzufassen oder zu gruppieren.
1. Nehmen Sie häufig aktualisierte Tabellen ins Visier und verlegen Sie deren manuelle nächtliche, wöchentlich oder zweiwöchentliche `VACUUM FREEZE`-Operationen auf Zeiträume außerhalb der Spitzenzeiten.
1. Erwägen Sie, Ihre Instance-Klasse hochzuskalieren, um mehr Systemressourcen für das hohe Transaktionsvolumen und die Selbstbereinigung zur Verfügung zu haben.
# Beheben von Leistungsproblemen bei der Bereinigung in RDS für PostgreSQL
In diesem Abschnitt werden Faktoren erörtert, die häufig zu einer schlechteren Bereinigungsleistung führen. Zudem wird beschrieben, wie diese Probleme behoben werden können.
**Topics**
+ [Bereinigen großer Indizes](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Large_indexes)
+ [Zu viele Tabellen oder Datenbanken zum Bereinigen](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Multiple_tables)
+ [Es läuft eine aggressive Bereinigung (um ein Wraparound zu verhindern)](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Aggressive_vacuum)
## Bereinigen großer Indizes
Der VACUUM-Prozess durchläuft aufeinanderfolgende Phasen: Initialisierung, Heap-Scanning, Index- und Heap-Bereinigung, Indexsäuberung, Heap-Kürzung und abschließende Bereinigung. Während des Heap-Scans bereinigt der Prozess Seiten, defragmentiert sie und friert sie ein. Nach Abschluss des Heap-Scans bereinigt VACUUM Indizes, gibt leere Seiten an das Betriebssystem zurück und führt abschließende Aufgaben wie das Bereinigen der freien Speicherzuweisung und das Aktualisieren von Statistiken durch.
Das Bereinigen von Indizes kann mehrere Durchläufe erfordern, wenn `maintenance_work_mem` (oder `autovacuum_work_mem`) nicht ausreicht, um den Index zu verarbeiten. In PostgreSQL 16 und früheren Versionen bedingte ein Speicherlimit von 1 GB für das Speichern toter Tupel-IDs häufig mehrere Durchläufe großer Indizes. PostgreSQL 17 führt `TidStore` ein, sodass kein Array mit einer einzelnen Zuweisung verwendet, sondern Speicher dynamisch zugewiesen wird. Dadurch wird die Beschränkung auf 1 GB aufgehoben, der Arbeitsspeicher effizienter genutzt und der Bedarf an mehreren Index-Scans pro Index reduziert.
Große Indizes können in PostgreSQL 17 immer noch mehrere Durchläufe erfordern, wenn der verfügbare Speicher nicht die gesamte Indexverarbeitung auf einmal bewältigen kann. In der Regel enthalten größere Indizes mehr tote Tupel, für die mehrere Durchläufe erforderlich sind.
**Erkennen langsamer Bereinigungsvorgänge**
Die `postgres_get_av_diag()`-Funktion erkennt, wenn Bereinigungsvorgänge aufgrund unzureichenden Speichers langsam ausgeführt werden. Weitere Informationen zu dieser Funktionen finden Sie unter [Installieren von Überwachungs- und Diagnosetools für die Selbstbereinigung in RDS für PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Installation.md).
Die `postgres_get_av_diag()`-Funktion gibt die folgenden Hinweise aus, wenn der verfügbare Speicher nicht ausreicht, um die Indexbereinigung in einem einzigen Durchgang abzuschließen.
**`rds_tools` 1.8**
```
NOTICE: Your database is currently running aggressive vacuum to prevent wraparound and it might be slow.
```
```
NOTICE: The current setting of autovacuum_work_mem is "XXX" and might not be sufficient. Consider increasing the setting, and if necessary, scaling up the Amazon RDS instance class for more memory.
Additionally, review the possibility of manual vacuum with exclusion of indexes using (VACUUM (INDEX_CLEANUP FALSE, VERBOSE TRUE) table_name;).
```
**`rds_tools` 1.9**
```
NOTICE: Your database is currently running aggressive vacuum to prevent wraparound and it might be slow.
```
```
NOTICE: The current setting of autovacuum_work_mem is XX might not be sufficient. Consider increasing the setting to XXX, and if necessary, scaling up the RDS instance class for more
memory. The suggested value is an estimate based on the current number of dead tuples for the table being vacuumed, which might not fully reflect the latest state. Additionally, review the possibility of manual
vacuum with exclusion of indexes using (VACUUM (INDEX_CLEANUP FALSE, VERBOSE TRUE) table_name;). For more information, see
[Working with PostgreSQL autovacuum in the Amazon Amazon RDS User Guide](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.Autovacuum.html)
.
```
**Anmerkung**
Die `postgres_get_av_diag()`-Funktion stützt sich auf `pg_stat_all_tables.n_dead_tup`, um die Menge an Speicher zu schätzen, der für die Indexbereinigung benötigt wird.
Wenn die `postgres_get_av_diag()`-Funktion einen langsamen Bereinigungsvorgang feststellt, für den mehrere Index-Scans erforderlich sind, weil `autovacuum_work_mem` nicht ausreicht, wird folgende Meldung generiert:
```
NOTICE: Your vacuum is performing multiple index scans due to insufficient autovacuum_work_mem:XXX for index vacuuming.
For more information, see [Working with PostgreSQL autovacuum in the Amazon Amazon RDS User Guide](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.Autovacuum.html).
```
**Empfehlungen**
Sie können die folgenden Abhilfemaßnahmen mittels manuellem `VACUUM FREEZE` anwenden, um das Einfrieren der Tabelle zu beschleunigen.
**Erhöhen des Speichers für die Bereinigung**
Wie von der `postgres_get_av_diag()`-Funktion vorgeschlagen ist es ratsam, den `autovacuum_work_mem`-Parameter zu erhöhen, um möglichen Speicherbeschränkungen auf Instance-Ebene zu begegnen. Zwar ist `autovacuum_work_mem` ein dynamischer Parameter, dennoch muss beachtet werden, dass der Daemon für die Selbstbereinigung seine Worker neu starten muss, damit die neuen Speichereinstellungen wirksam werden. So können Sie dies erreichen:
1. Bestätigen Sie, dass die neue Einstellung festgelegt wurde.
1. Beenden Sie die Prozesse, die derzeit die Selbstbereinigung durchführen.
Dieser Ansatz stellt sicher, dass die angepasste Speicherzuweisung auf neue Selbstbereinigungsvorgänge angewendet wird.
Um unmittelbarere Ergebnisse zu erzielen, sollten Sie erwägen, manuell eine `VACUUM FREEZE`-Operation mit einer höheren `maintenance_work_mem`-Einstellung innerhalb Ihrer Sitzung durchzuführen:
```
SET maintenance_work_mem TO '1GB';
VACUUM FREEZE VERBOSE table_name;
```
Wenn Sie Amazon RDS verwenden und feststellen, dass Sie zusätzlichen Speicher benötigen, um höhere Werte für `maintenance_work_mem` oder `autovacuum_work_mem` unterstützen zu können, sollten Sie ein Upgrade auf eine Instance-Klasse mit mehr Speicher in Betracht ziehen. Dadurch können die erforderlichen Ressourcen bereitgestellt werden, um sowohl die manuellen als auch die automatischen Bereinigungsvorgänge zu verbessern, was insgesamt zu einer verbesserten Bereinigungs- und Datenbankleistung führt.
**Deaktivieren von INDEX\$1CLEANUP**
Ein manuelles `VACUUM` in PostgreSQL-Version 12 und höher ermöglicht das Überspringen der Indexbereinigungsphase, während die Notfall-Selbstbereinigung in PostgreSQL-Version 14 und höher dies automatisch auf der Grundlage des Parameters [https://www.postgresql.org/docs/current/runtime-config-client.html#GUC-VACUUM-FAILSAFE-AGE](https://www.postgresql.org/docs/current/runtime-config-client.html#GUC-VACUUM-FAILSAFE-AGE) erledigt.
**Warnung**
Das Überspringen der Indexbereinigung kann zu einer Aufblähung des Index führen und sich negativ auf die Abfrageleistung auswirken. Um dem entgegenzuwirken, sollten Sie erwägen, die betroffenen Indizes während eines Wartungsfensters neu zu indizieren oder zu bereinigen.
Weitere Anleitungen zum Umgang mit großen Indizes finden Sie in der Dokumentation zu [Verwalten der automatischen Bereinigung mit großen Indizes](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.LargeIndexes.md).
**Parallele Indexbereinigung**
Ab PostgreSQL 13 können Indizes standardmäßig mit manuellem `VACUUM` parallel bereinigt und gesäubert werden, wobei jedem Index ein Bereinigungs-Worker zugewiesen wird. Damit PostgreSQL jedoch feststellen kann, ob ein Bereinigungsvorgang für eine parallele Ausführung infrage kommt, müssen bestimmte Kriterien erfüllt sein:
+ Es müssen mindestens zwei Indizes vorhanden sein.
+ Der `max_parallel_maintenance_workers`-Parameter sollte auf mindestens 2 gesetzt werden.
+ Die Indexgröße muss den `min_parallel_index_scan_size`-Grenzwert überschreiten, der standardmäßig 512 KB beträgt.
Sie können die `max_parallel_maintenance_workers`-Einstellung auf der Grundlage der Anzahl der auf Ihrer Amazon-RDS-Instance verfügbaren vCPUs und der Anzahl der Indizes in der Tabelle anpassen, um die Bearbeitungszeit für das Bereinigen zu optimieren.
Weitere Informationen finden Sie unter [Parallele Selbstbereinigung in Amazon RDS für PostgreSQL und Amazon Aurora PostgreSQL](https://aws.amazon.com/blogs/database/parallel-vacuuming-in-amazon-rds-for-postgresql-and-amazon-aurora-postgresql/).
## Zu viele Tabellen oder Datenbanken zum Bereinigen
Wie in der PostgreSQL-Dokumentation [Der Selbstbereinigungsdaemon](https://www.postgresql.org/docs/current/routine-vacuuming.html#AUTOVACUUM') angegeben, durchläuft der Bereinigungsdaemon mehrere Prozesse. Dazu gehört auch ein persistenter Launcher für die Selbstbereinigung, der für das Starten von Selbstbereinigungs-Worker-Prozessen für jede Datenbank innerhalb des Systems verantwortlich ist. Der Launcher plant, dass diese Worker ungefähr alle `autovacuum_naptime` Sekunden pro Datenbank initiiert werden.
Bei „N“ Datenbanken startet ungefähr alle [`autovacuum_naptime`/N Sekunden] ein neuer Worker. Die Gesamtzahl der gleichzeitigen Worker ist jedoch durch die `autovacuum_max_workers`-Einstellung begrenzt. Wenn die Anzahl der Datenbanken oder Tabellen, die bereinigt werden müssen, diesen Grenzwert überschreitet, wird die nächste Datenbank oder Tabelle verarbeitet, sobald ein Worker verfügbar ist.
Wenn viele große Tabellen oder Datenbanken gleichzeitig bereinigt werden müssen, kann es sein, dass alle verfügbaren Bereinigungs-Worker für einen längeren Zeitraum ausgelastet sind, was die Wartung anderer Tabellen und Datenbanken verzögert. In Umgebungen mit hohen Transaktionsraten kann dieser Engpass schnell eskalieren und möglicherweise zu komplexeren Bereinigungsproblemen innerhalb Ihrer Amazon-RDS-Instance führen.
Wenn `postgres_get_av_diag()` eine große Anzahl von Tabellen oder Datenbanken erkennt, wird folgende Empfehlung bereitgestellt:
```
NOTICE: Your database is currently running aggressive vacuum to prevent wraparound and it might be slow.
```
```
NOTICE: The current setting of autovacuum_max_workers:3 might not be sufficient. Consider increasing the setting and, if necessary, consider scaling up the Amazon RDS instance class for more workers.
```
**Empfehlungen**
**Erhöhen von autovacuum\$1max\$1workers**
Um das Bereinigen zu beschleunigen, empfehlen wir, den `autovacuum_max_workers`-Parameter so anzupassen, dass mehr gleichzeitige Worker möglich sind. Wenn weiterhin Leistungsengpässe bestehen, sollten Sie erwägen, Ihre Amazon-RDS-Instance auf eine Klasse mit mehr vCPUs zu skalieren, wodurch die Möglichkeiten der Parallelverarbeitung weiter optimiert werden können.
## Es läuft eine aggressive Bereinigung (um ein Wraparound zu verhindern)
Das Alter der Datenbank (MaximumUsedTransactionIDs) in PostgreSQL nimmt nur ab, wenn erfolgreich eine aggressive Bereinigung (zur Wraparound-Verhinderung) durchgeführt wird. Bis diese Bereinigung beendet ist, wird das Alter je nach Transaktionsrate weiter zunehmen.
Die `postgres_get_av_diag()`-Funktion generiert folgenden `NOTICE`, wenn sie eine aggressive Bereinigung erkennt. Sie löst diese Ausgabe jedoch erst aus, wenn die Bereinigung mindestens zwei Minuten lang aktiv war.
```
NOTICE: Your database is currently running aggressive vacuum to prevent wraparound, monitor autovacuum performance.
```
Weitere Informationen zu aggressivem Bereinigungen finden Sie unter [Wenn bereits eine aggressive Bereinigung läuft](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.NOTICE.md).
Mit der folgenden Abfrage können Sie überprüfen, ob eine aggressive Bereinigung läuft:
```
SELECT
a.xact_start AS start_time,
v.datname "database",
a.query,
a.wait_event,
v.pid,
v.phase,
v.relid::regclass,
pg_size_pretty(pg_relation_size(v.relid)) AS heap_size,
(
SELECT
string_agg(pg_size_pretty(pg_relation_size(i.indexrelid)) || ':' || i.indexrelid::regclass || chr(10), ', ')
FROM
pg_index i
WHERE
i.indrelid = v.relid
) AS index_sizes,
trunc(v.heap_blks_scanned * 100 / NULLIF(v.heap_blks_total, 0)) AS step1_scan_pct,
v.index_vacuum_count || '/' || (
SELECT
count(*)
FROM
pg_index i
WHERE
i.indrelid = v.relid
) AS step2_vacuum_indexes,
trunc(v.heap_blks_vacuumed * 100 / NULLIF(v.heap_blks_total, 0)) AS step3_vacuum_pct,
age(CURRENT_TIMESTAMP, a.xact_start) AS total_time_spent_sofar
FROM
pg_stat_activity a
INNER JOIN pg_stat_progress_vacuum v ON v.pid = a.pid;
```
Sie können anhand der Abfragespalte in der Ausgabe feststellen, ob es sich um eine aggressive Bereinigung (zur Wraparound-Verhinderung) handelt. Der Ausdruck „zur Wraparound-Verhinderung“ weist darauf hin, dass es sich um eine aggressive Bereinigung handelt.
```
query | autovacuum: VACUUM public.t3 (to prevent wraparound)
```
Angenommen, Sie haben einen Blocker mit einem Transaktionsalter von 1 Milliarde und eine Tabelle, die eine aggressive Bereinigung erfordert, um einen Wraparound im gleichen Transaktionsalter zu verhindern. Darüber hinaus gibt es einen weiteren Blocker mit einem Transaktionsalter von 750 Millionen. Nach der Aufhebung des Blockers mit einem Transaktionsalter von 1 Milliarde wird das Transaktionsalter nicht sofort auf 750 Millionen sinken. Es wird so lange hoch bleiben, bis die Tabelle, für die die aggressive Bereinigung erforderlich ist, oder eine andere Transaktion mit einem Alter von über 750 Millionen abgeschlossen ist. Während dieses Zeitraums wird das Transaktionsalter Ihres PostgreSQL-Clusters weiter steigen. Sobald der Bereinigungsvorgang abgeschlossen ist, wird das Transaktionsalter auf 750 Millionen sinken, aber es wird wieder steigen, bis das weitere Bereinigen abgeschlossen ist. Dieser Zyklus wird so lange fortgesetzt, wie diese Bedingungen bestehen, bis das Transaktionsalter schließlich auf das für Ihre Amazon-RDS-Instance konfigurierte Niveau fällt, das durch `autovacuum_freeze_max_age` angegeben ist.
# Erläuterung der HINWEIS-Meldungen in RDS für PostgreSQL
Die `postgres_get_av_diag()`-Funktion stellt die folgenden HINWEIS-Meldungen bereit:
**Wenn für das Alter der Überwachungsschwellenwert noch nicht erreicht ist**
Die Überwachungsschwellenwert für `postgres_get_av_diag()` zur Identifizierung von Blockern liegt standardmäßig bei 500 Millionen Transaktionen. Wenn `postgres_get_av_diag()` den folgenden HINWEIS generiert, bedeutet dies, dass das Transaktionsalter diesen Schwellenwert noch nicht erreicht hat.
```
NOTICE: postgres_get_av_diag() checks for blockers that prevent aggressive vacuums only, it does so only after exceeding dvb_threshold which is 500,000,000 and age of this PostgreSQL cluster is currently at 2.
```
**Keine Verbindung zur Datenbank mit dem Alter der ältesten Transaktions-ID**
Die `postgres_get_av_diag()`-Funktion liefert die genaueste Ausgabe, wenn sie mit der Datenbank mit dem Alter der ältesten Transaktions-ID verbunden ist. Die Datenbank mit dem ältesten von `postgres_get_av_diag()` gemeldeten Transaktions-ID-Alter unterscheidet sich in Ihrem Fall von „my\$1database“. Wenn Sie nicht mit der richtigen Datenbank verbunden sind, wird der folgende HINWEIS generiert:
```
NOTICE: You are not connected to the database with the age of oldest transaction ID. Connect to my_database database and run postgres_get_av_diag() for accurate reporting.
```
Aus folgenden Gründen ist es wichtig, eine Verbindung zur Datenbank mit dem ältesten Transaktionsalter herzustellen:
+ **Identifizierung temporärer Tabellenblocker:** Da die Metadaten für temporäre Tabellen für jede Datenbank spezifisch sind, befinden sie sich normalerweise in der Datenbank, in der sie erstellt wurden. Wenn jedoch eine temporäre Tabelle der primäre Blocker ist und sich in der Datenbank mit der ältesten Transaktion befindet, könnte dies zu falschen Annahmen führen. Durch die Verbindung mit der richtigen Datenbank wird die genaue Identifizierung des Blockers für temporäre Tabellen gewährleistet.
+ **Diagnose langsamer Bereinigungen:** Die Index-Metadaten und die Informationen zur Anzahl der Tabellen sind datenbankspezifisch und für die Diagnose von Problemen im Zusammenhang mit langsamen Bereinigungen erforderlich.
**Die Datenbank mit der ältesten Transaktion nach Alter befindet sich in einer rdsadmin- oder template0-Datenbank**
In bestimmten Fällen kann die `rdsadmin`- oder die `template0`-Datenbank als die Datenbank mit dem ältesten Transaktions-ID-Alter identifiziert werden. In diesem Fall gibt `postgres_get_av_diag()` folgenden HINWEIS aus:
```
NOTICE: The database with the age of oldest transaction ID is rdsadmin or template0, reach out to support if the reported blocker is in rdsadmin or template0.
```
Stellen Sie sicher, dass der aufgelistete Blocker nicht aus einer dieser beiden Datenbanken stammt. Wenn gemeldet wird, dass der Blocker in `rdsadmin` oder `template0` vorhanden ist, wenden Sie sich an den Support, da Benutzer nicht auf diese Datenbanken zugreifen können und ein Eingreifen erforderlich ist.
Es ist sehr unwahrscheinlich, dass die `rdsadmin`-Datenbank oder die `template0`-Datenbank einen primären Blocker enthält.
**Wenn bereits eine aggressive Bereinigung läuft**
Die `postgres_get_av_diag()`-Funktion ist so konzipiert, dass sie es meldet, wenn ein aggressiver Bereinigungsprozess läuft, löst diese Ausgabe jedoch erst aus, wenn die Bereinigungsfunktion seit mindestens 1 Minute aktiv ist. Diese absichtliche Verzögerung trägt dazu bei, die Wahrscheinlichkeit falsch-positiver Ergebnisse zu verringern. Durch das Warten stellt die Funktion sicher, dass nur effektive, signifikante Bereinigungen gemeldet werden, was zu einer genaueren und zuverlässigeren Überwachung der Bereinigungsaktivität führt.
Die `postgres_get_av_diag()`-Funktion generiert den folgenden HINWEIS, wenn sie feststellt, dass eine oder mehrere aggressive Bereinigungen laufen.
```
NOTICE: Your database is currently running aggressive vacuum to prevent wraparound, monitor autovacuum performance.
```
Wie im HINWEIS angegeben sollten Sie die Leistung der Bereinigung weiterhin überwachen. Mehr über aggressive Bereinigungen erfahren Sie unter [Es läuft eine aggressive Bereinigung (um ein Wraparound zu verhindern)](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Resolving_Performance.md#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Aggressive_vacuum)
**Wenn die Selbstbereinigung deaktiviert ist**
Die `postgres_get_av_diag()`-Funktion generiert den folgenden HINWEIS, wenn die Selbstbereinigung auf Ihrer Datenbank-Instance deaktiviert ist:
```
NOTICE: Autovacuum is OFF, we strongly recommend to enable it, no restart is necessary.
```
Die Selbstbereinigung ist eine wichtige Funktion Ihrer Instance von RDS für PostgreSQL, die einen reibungslosen Datenbankbetrieb gewährleistet. Sie entfernt automatisch alte Zeilenversionen, fordert Speicherplatz zurück, verhindert ein Aufblähen von Tabellen und trägt so dazu bei, dass Tabellen und Indizes zwecks optimaler Leistung effizient bleiben. Darüber hinaus schützt sie vor einem Transaktions-ID-Wraparound, wodurch Transaktionen auf Ihrer Amazon-RDS-Instance gestoppt werden können. Die Deaktivierung der Selbstbereinigung kann zu langfristigen Einbußen bei der Datenbankleistung und -stabilität führen. Wir empfehlen Ihnen, sie ständig aktiviert zu lassen. Weitere Informationen finden Sie unter [Grundlegendes zur Selbstbereinigung in RDS für PostgreSQL-Umgebungen](https://aws.amazon.com/blogs/database/understanding-autovacuum-in-amazon-rds-for-postgresql-environments/).
Durch das Deaktivieren der Selbstbereinigung werden aggressive Bereinigungen nicht gestoppt. Diese treten weiterhin auf, sobald Ihre Tabellen den `autovacuum_freeze_max_age`-Schwellenwert erreichen.
**Die Anzahl der verbleibenden Transaktionen ist äußerst gering**
Die `postgres_get_av_diag()`-Funktion generiert den folgenden HINWEIS, wenn eine Wraparound-Bereinigung unmittelbar bevorsteht. Dieser HINWEIS wird ausgegeben, wenn Ihre Amazon-RDS-Instance 100 Millionen Transaktionen davon entfernt ist, neue Transaktionen möglicherweise abzulehnen.
```
WARNING: Number of transactions remaining is critically low, resolve issues with autovacuum or perform manual VACUUM FREEZE before your instance stops accepting transactions.
```
Ihr sofortiges Handeln ist erforderlich, um Ausfallzeiten der Datenbank zu vermeiden. Sie sollten Ihre Bereinigungsvorgänge genau überwachen und erwägen, manuell einen `VACUUM FREEZE`-Vorgang in der betroffenen Datenbank zu initiieren, um Transaktionsfehler zu vermeiden.
# Verwaltung hoher Objektzahlen in Amazon RDS for PostgreSQL Aurora PostgreSQL
PostgreSQL-Einschränkungen sind zwar theoretisch, aber extrem hohe Objektzahlen in einer Datenbank haben spürbare Auswirkungen auf die Leistung verschiedener Operationen. Diese Dokumentation behandelt mehrere gängige Objekttypen, die bei einer hohen Gesamtzahl zu mehreren möglichen Auswirkungen führen können.
Die folgende Tabelle enthält eine Zusammenfassung der Objekttypen und ihrer möglichen Auswirkungen:
**Objekttypen und mögliche Auswirkungen**
| Art des Objekts | Autovakuum | Logische Replikation | Upgrade einer Hauptversion | pg\$1dump//pg\$1restore | Allgemeine Leistung | Neustart der Instanz |
| --- | --- | --- | --- | --- | --- | --- |
| [Beziehungen](#PostgreSQL.HighObjectCount.Relations) | x | | x | x | x | |
| [Temporäre Tabellen](#PostgreSQL.HighObjectCount.TempTables) | x | | | | x | |
| [Nicht protokollierte Tabellen](#PostgreSQL.HighObjectCount.UnloggedTables) | | x | | | | x |
| [Partitionen](#PostgreSQL.HighObjectCount.Partitions) | | | | | x | |
| [Temporäre Dateien](#PostgreSQL.HighObjectCount.TempFiles) | | | | | x | |
| [Sequenzen](#PostgreSQL.HighObjectCount.Sequences) | | x | | | | |
| [Große Objekte](#PostgreSQL.HighObjectCount.LargeObjects) | | x | x | | | |
## Relationen
Es gibt kein bestimmtes festes Limit für die Anzahl der Tabellen in einer PostgreSQL-Datenbank. Die theoretische Grenze ist extrem hoch, aber es gibt noch andere praktische Grenzen, die beim Datenbankentwurf berücksichtigt werden müssen.
**Auswirkung: Autovacuum gerät ins Hintertreffen**
Autovacuum kann Schwierigkeiten haben, mit dem Wachstum der Transaktions-IDs Schritt zu halten, oder es kann sein, dass die Tabelle aufgrund des Mangels an Mitarbeitern im Verhältnis zum Arbeitsaufwand überfüllt wird.
**Empfohlene Maßnahme:** Es gibt mehrere Faktoren, um Autovacuum so einzustellen, dass es mit einer bestimmten Anzahl von Tabellen und einer bestimmten Arbeitslast Schritt hält. Vorschläge [zur Festlegung geeigneter Autovacuum-Einstellungen finden Sie unter Bewährte Methoden für die Arbeit mit PostgreSQL-Autovacuum](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.Autovacuum.html) .
**Auswirkung: Upgrade der Hauptversion//pg\$1dump und Wiederherstellung**
Amazon RDS verwendet während der Ausführung von pg\$1upgrade die Option „--link“, um zu vermeiden, dass Kopien von Datendateien erstellt werden müssen. Die Schema-Metadaten müssen dennoch in der neuen Version der Datenbank wiederhergestellt werden. Selbst bei parallelem pg\$1restore erhöht dies die Ausfallzeit, wenn es eine beträchtliche Anzahl von Beziehungen gibt.
**Auswirkung: Allgemeiner Leistungsabfall**
Allgemeine Leistungseinbußen aufgrund der Kataloggröße. Jede Tabelle und die zugehörigen Spalten werden zu `pg_depend` Tabellen hinzugefügt`pg_attribute`, `pg_class` die häufig bei normalen Datenbankoperationen verwendet werden. Es wird kein bestimmtes Warteereignis sichtbar sein, aber die Effizienz des gemeinsamen Puffers wird beeinträchtigt.
**Empfohlene Maßnahme:** Überprüfen Sie regelmäßig, ob Table Bloat für diese speziellen Tabellen verfügbar ist, und führen Sie gelegentlich eine `VACUUM FULL` Überprüfung dieser spezifischen Tabellen durch. Beachten Sie, dass `VACUUM FULL` für Katalogtabellen eine `ACCESS EXCLUSIVE` Sperre erforderlich ist, was bedeutet, dass keine anderen Abfragen auf sie zugreifen können, bis der Vorgang abgeschlossen ist.
**Auswirkung: Erschöpfung des Dateideskriptors**
Fehler: „Keine Dateideskriptoren mehr vorhanden: Zu viele offene Dateien im System; freigeben und erneut versuchen“. Der PostgreSQL-Parameter `max_files_per_process` bestimmt, wie viele Dateien jeder Prozess öffnen kann. Wenn es eine große Anzahl von Verbindungen gibt, die eine große Anzahl von Tabellen verbinden, ist es möglich, dieses Limit zu erreichen.
**Empfohlene Maßnahme:**
+ Wenn Sie den Wert des Parameters verringern, `max_files_per_process` kann dieser Fehler möglicherweise behoben werden. Jeder Prozess und Unterprozess (z. B. parallel Abfrage) kann diese Anzahl von Dateien öffnen, und wenn die Abfragen mehrere Tabellen verbinden, kann dieses Limit ausgeschöpft sein.
+ Reduzieren Sie die Gesamtzahl der Verbindungen und verwenden Sie einen Verbindungspooler wie [Amazon RDS Proxy](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/rds-proxy.html), oder andere Lösungen wie PgBouncer. Weitere Informationen finden Sie [PgBouncer auf der Website](https://www.pgbouncer.org/).
**Auswirkung: Inode-Erschöpfung**
Fehler: „Auf dem Gerät ist kein Speicherplatz mehr vorhanden“. Wenn dies beobachtet wird, wenn viel freier Speicherplatz vorhanden ist, liegt dies daran, dass die Inodes knapp werden. [Amazon RDS Enhanced Monitoring](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Monitoring.OS.html) bietet Einblick in die verwendeten Inodes und die maximale Anzahl, die für Ihren Host verfügbar ist.
**[Ungefährer Schwellenwert: Millionen](#PostgreSQL.HighObjectCount.Note)**
## Temporäre Tabellen
Die Verwendung temporärer Tabellen ist nützlich für Testdaten oder Zwischenergebnisse und ist ein gängiges Muster, das in vielen Datenbank-Engines zu finden ist. Die Auswirkungen der starken Nutzung von PostgreSQL müssen verstanden werden, um einige der Fallstricke zu vermeiden. Bei jedem Erstellen und Löschen temporärer Tabellen werden den Systemkatalogtabellen Zeilen hinzugefügt, was zu allgemeinen Leistungsproblemen führt, wenn sie aufgebläht werden.
**Auswirkung: Autovacuum gerät ins Hintertreffen**
Temporäre Tabellen werden nicht automatisch gelöscht, sondern speichern Transaktionen IDs , solange sie existieren. Wenn sie nicht entfernt werden, kann es zu einem Wraparound kommen.
**Empfohlene Maßnahme:** Temporäre Tabellen bleiben für die Dauer der Sitzung bestehen, in der sie erstellt wurden, oder können manuell gelöscht werden. Eine bewährte Methode zur Vermeidung lang andauernder Transaktionen mit temporären Tabellen verhindert, dass diese Tabellen zum Anstieg der maximal genutzten Transaktions-IDs beitragen.
**Auswirkung: Allgemeiner Leistungsabfall**
Allgemeine Leistungseinbußen aufgrund der Kataloggröße. Wenn Sitzungen kontinuierlich temporäre Tabellen erstellen und löschen, werden `pg_depend` Tabellen hinzugefügt`pg_attribute`, `pg_class` die häufig bei normalen Datenbankoperationen verwendet werden. Es wird kein bestimmtes Warteereignis sichtbar sein, aber die Effizienz des gemeinsamen Puffers wird beeinträchtigt.
**Empfohlene Maßnahme:**
+ Überprüfen Sie regelmäßig, ob Table Bloat für diese speziellen Tabellen verfügbar ist, und führen Sie gelegentlich eine `VACUUM FULL` Prüfung für diese spezifischen Tabellen durch. Beachten Sie, dass `VACUUM FULL` für Katalogtabellen eine `ACCESS EXCLUSIVE` Sperre erforderlich ist, was bedeutet, dass keine anderen Abfragen auf sie zugreifen können, bis der Vorgang abgeschlossen ist.
+ Wenn temporäre Tabellen stark genutzt werden, wird vor einem Upgrade einer Hauptversion dringend empfohlen, eine `VACUUM FULL` dieser speziellen Katalogtabellen zu verwenden, um Ausfallzeiten zu reduzieren.
**Allgemeine bewährte Methoden:**
+ Reduzieren Sie die Verwendung temporärer Tabellen, indem Sie allgemeine Tabellenausdrücke verwenden, um Zwischenergebnisse zu erzielen. Diese können manchmal die erforderlichen Abfragen verkomplizieren, verhindern jedoch die oben aufgeführten Auswirkungen.
+ Verwenden Sie temporäre Tabellen erneut, indem Sie den `TRUNCATE` Befehl verwenden, um den Inhalt zu löschen, anstatt drop/create Schritte auszuführen. Dadurch wird auch das Problem des durch temporäre Tabellen verursachten Wachstums der Transaktions-IDs behoben.
**Ungefährer Schwellenwert:** [Zehntausende](#PostgreSQL.HighObjectCount.Note)
## Nicht protokollierte Tabellen
Nicht protokollierte Tabellen können Leistungssteigerungen bieten, da sie keine WAL-Informationen generieren. Sie müssen vorsichtig verwendet werden, da sie bei der Wiederherstellung nach einem Datenbankabsturz keine Beständigkeit bieten, da sie gekürzt werden. Dies ist eine teure Operation in PostgreSQL, da jede nicht protokollierte Tabelle seriell gekürzt wird. Dieser Vorgang ist zwar bei einer geringen Anzahl nicht protokollierter Tabellen schnell, kann aber bei Tausenden von Tabellen zu erheblichen Verzögerungen beim Start führen.
**Auswirkung: Logische Replikation**
Nicht protokollierte Tabellen sind im Allgemeinen nicht in der logischen Replikation enthalten, einschließlich [Blue/Green-Bereitstellungen ](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/blue-green-deployments.html), da die logische Replikation zur Erfassung und Übertragung von Änderungen auf der WAL basiert.
**Auswirkung: Verlängerte Ausfallzeit während der Wiederherstellung**
Bei jedem Datenbankstatus, der eine Wiederherstellung nach einem Datenbankabsturz beinhaltet, wie z. B. Multi-AZ-Neustart mit Failover, Amazon point-in-time RDS-Wiederherstellung und Amazon RDS-Hauptversions-Upgrade, erfolgt der serialisierte Vorgang, bei dem die nicht protokollierten Tabellen gekürzt werden. Dies kann zu wesentlich höheren Ausfallzeiten als erwartet führen.
**Empfohlene Maßnahme:**
+ Beschränken Sie die Verwendung nicht protokollierter Tabellen auf Daten, deren Verlust bei der Wiederherstellung nach einem Datenbankabsturz akzeptabel ist.
+ Reduzieren Sie die Verwendung von Tabellen, die nicht protokolliert wurden, da das derzeitige Verhalten der seriellen Kürzung dazu führen kann, dass der Start einer Datenbank viel Zeit in Anspruch nimmt.
**Allgemeine bewährte Methoden:**
+ Nicht protokollierte Tabellen sind nicht absturzsicher. Das Initiieren einer point-in-time Wiederherstellung, die eine Wiederherstellung nach einem Absturz beinhaltet, nimmt in PostgreSQL viel Zeit in Anspruch, da es sich um einen seriellen Prozess handelt, bei dem jede Tabelle gekürzt wird.
**[Ungefährer](#PostgreSQL.HighObjectCount.Note)** Schwellenwert: Tausende
## Partitionen
Durch Partitionierung kann die Abfrageleistung erhöht und eine logische Organisation der Daten ermöglicht werden. Im Idealfall ist die Partitionierung so organisiert, dass das Bereinigen von Partitionen bei der Planung und Ausführung von Abfragen verwendet werden kann. Die Verwendung zu vieler Partitionen kann sich negativ auf die Abfrageleistung und die Datenbankwartung auswirken. Die Wahl, wie eine Tabelle partitioniert werden soll, sollte sorgfältig getroffen werden, da die Leistung der Abfrageplanung und -ausführung durch einen schlechten Entwurf negativ beeinflusst werden kann. Einzelheiten zur Partitionierung finden Sie in der [PostgreSQL-Dokumentation](https://www.postgresql.org/docs/current/ddl-partitioning.html).
**Auswirkung: Allgemeiner Leistungsabfall**
Manchmal nimmt der Zeitaufwand für die Planung zu und die Erläuterung der Pläne für Ihre Abfragen wird komplizierter, sodass es schwierig wird, Optimierungsmöglichkeiten zu identifizieren. Bei PostgreSQL-Versionen vor 18 können viele Partitionen mit hoher Arbeitslast zu `LWLock:LockManager` Wartezeiten führen.
**Empfohlene Maßnahme:** Legen Sie eine Mindestanzahl von Partitionen fest, die es Ihnen ermöglicht, sowohl die Organisation Ihrer Daten abzuschließen als auch gleichzeitig eine performante Abfrageausführung zu gewährleisten.
**Auswirkung: Komplexität der Wartung**
Eine sehr hohe Anzahl von Partitionen führt zu Wartungsschwierigkeiten wie der Erstellung und Entfernung vor der Erstellung und Entfernung. Autovacuum behandelt Partitionen wie normale Relationen und muss regelmäßige Säuberungen durchführen, weshalb genügend Mitarbeiter erforderlich sind, um die Aufgabe zu erledigen.
**Empfohlene Maßnahme:**
+ Stellen Sie sicher, dass Sie Partitionen vorab erstellen, damit die Arbeitslast nicht blockiert wird, wenn eine neue Partition benötigt wird (z. B. monatliche Partitionen) und alte Partitionen gelöscht werden.
+ Stellen Sie sicher, dass Sie über genügend Autovacuum-Mitarbeiter verfügen, um die normale Säuberung und Wartung aller Partitionen durchzuführen.
**Ungefährer Schwellenwert**[: Hunderte](#PostgreSQL.HighObjectCount.Note)
## Temporäre Dateien
Im Gegensatz zu den oben genannten temporären Tabellen werden temporäre Dateien von PostgreSQL erstellt, wenn eine komplexe Abfrage mehrere Sortier- oder Hashoperationen gleichzeitig ausführt, wobei jede Operation Instanzspeicher verwendet, um Ergebnisse bis zu dem `work_mem` im Parameter angegebenen Wert zu speichern. Wenn der Instance-Speicher nicht ausreicht, werden temporäre Dateien erstellt, um die Ergebnisse zu speichern. Weitere Informationen zu [temporären Dateien](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/PostgreSQL.ManagingTempFiles.html) finden Sie unter . Wenn Ihr Workload eine große Anzahl dieser Dateien generiert, kann dies verschiedene Auswirkungen haben.
**Auswirkung: Erschöpfung des Dateideskriptors**
Fehler: „Keine Dateideskriptoren mehr vorhanden: Zu viele offene Dateien im System; freigeben und erneut versuchen“. Der PostgreSQL-Parameter `max_files_per_process` bestimmt, wie viele Dateien jeder Prozess öffnen kann. Wenn es eine große Anzahl von Verbindungen gibt, die eine große Anzahl von Tabellen verbinden, ist es möglich, dieses Limit zu erreichen.
**Empfohlene Maßnahme:**
+ Wenn Sie den Wert des Parameters verringern, `max_files_per_process` kann dieser Fehler möglicherweise behoben werden. Jeder Prozess und Unterprozess (z. B. parallel Abfrage) kann diese Anzahl von Dateien öffnen, und wenn die Abfragen mehrere Tabellen verbinden, kann dieses Limit ausgeschöpft sein.
+ Reduzieren Sie die Gesamtzahl der Verbindungen und verwenden Sie einen Verbindungspooler wie [Amazon RDS Proxy](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/rds-proxy.html) oder andere Lösungen wie PgBouncer. Weitere Informationen finden Sie [PgBouncer auf der Website](https://www.pgbouncer.org/).
**Auswirkung: Inode-Erschöpfung**
Fehler: „Auf dem Gerät ist kein Speicherplatz mehr vorhanden“. Wenn dies beobachtet wird, wenn viel freier Speicherplatz vorhanden ist, liegt dies daran, dass die Inodes knapp werden. [Amazon RDS Enhanced Monitoring](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Monitoring.OS.html) bietet Einblick in die verwendeten Inodes und die maximale Anzahl, die für Ihren Host verfügbar ist.
**Allgemeine bewährte Methoden:**
+ Überwachen Sie die Nutzung Ihrer temporären Dateien mit [Performance Insights ](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PerfInsights.html).
+ Optimieren Sie Abfragen, die umfangreiche temporäre Dateien generieren, um festzustellen, ob es möglich ist, die Gesamtzahl der temporären Dateien zu reduzieren.
**[Ungefährer Schwellenwert: Tausende](#PostgreSQL.HighObjectCount.Note)**
## Sequenzen
Sequenzen sind das zugrunde liegende Objekt, das für die automatische Inkrementierung von Spalten in PostgreSQL verwendet wird. Sie bieten Einzigartigkeit und einen Schlüssel für die Daten. Diese können für einzelne Tabellen verwendet werden, ohne dass dies im normalen Betrieb Auswirkungen hat, mit einer Ausnahme der logischen Replikation.
In PostgreSQL repliziert die logische Replikation derzeit den aktuellen Wert einer Sequenz auf keinen Abonnenten. Weitere Informationen finden Sie auf der [Seite Einschränkungen in der PostgreSQL-Dokumentation](https://www.postgresql.org/docs/current/logical-replication-restrictions.html).
**Auswirkung: Verlängerte Switchover-Zeit**
Wenn Sie [Amazon RDS Blue/Green Deployments ](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/blue-green-deployments.html) für jede Art von Konfigurationsänderung oder Upgrade verwenden möchten, ist es wichtig, die Auswirkungen einer hohen Anzahl von Sequenzen auf den Switchover zu verstehen. In einer der letzten Phasen eines Switchovers wird der aktuelle Wert der Sequenzen synchronisiert, und wenn es mehrere Tausend gibt, verlängert sich dadurch die Gesamtswitchover-Zeit.
**Empfohlene Maßnahme:** Wenn Ihre Datenbank-Arbeitslast die Verwendung einer gemeinsamen UUID anstelle eines sequence-per-table Ansatzes zulassen würde, würde dies den Synchronisationsschritt während eines Switchovers reduzieren.
**Ungefährer Schwellenwert**[: Tausende](#PostgreSQL.HighObjectCount.Note)
## Große Objekte
Große Objekte werden in einer einzigen Systemtabelle namens pg\$1largeobject gespeichert. Jedes große Objekt hat auch einen Eintrag in der Systemtabelle pg\$1largeobject\$1metadata. Diese Objekte werden ganz anders erstellt, geändert und bereinigt als Standardbeziehungen. Große Objekte werden nicht mit Autovakuumverfahren behandelt und müssen in regelmäßigen Abständen mit einem separaten Verfahren, dem sogenannten Vacuumlo, gereinigt werden. Beispiele zur Verwaltung großer Objekte finden Sie unter Verwaltung großer Objekte mit dem Modul lo.
**Auswirkung: Logische Replikation**
Große Objekte werden derzeit während der logischen Replikation nicht in PostgreSQL repliziert. Weitere Informationen finden Sie auf der [Seite Einschränkungen in der PostgreSQL-Dokumentation](https://www.postgresql.org/docs/current/logical-replication-restrictions.html). In einer [https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/blue-green-deployments.html](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/blue-green-deployments.html) bedeutet dies, dass große Objekte in der blauen Umgebung nicht in die grüne Umgebung repliziert werden.
**Auswirkung: Upgrade der Hauptversion**
Bei einem Upgrade kann der Arbeitsspeicher knapp werden und es kann fehlschlagen, wenn Millionen großer Objekte vorhanden sind und die Instanz diese während eines Upgrades nicht verarbeiten kann. Der Upgrade-Prozess für die PostgreSQL-Hauptversion besteht aus zwei großen Phasen: dem Dumping des Schemas über pg\$1dump und dem Wiederherstellen über pg\$1restore. Wenn Ihre Datenbank Millionen großer Objekte enthält, müssen Sie sicherstellen, dass Ihre Instanz über ausreichend Speicher verfügt, um pg\$1dump und pg\$1restore während eines Upgrades zu verarbeiten, und sie auf einen größeren Instanztyp skalieren.
**Allgemeine bewährte Methoden:**
+ Verwenden Sie regelmäßig das Programm vacuumlo, um eventuell verwaiste große Objekte zu entfernen.
+ Erwägen Sie, den BYTEA-Datentyp zum Speichern Ihrer großen Objekte in der Datenbank zu verwenden.
**Ungefährer Schwellenwert**[: Millionen](#PostgreSQL.HighObjectCount.Note)
## Ungefähre Schwellenwerte
Die in diesem Thema genannten ungefähren Schwellenwerte werden nur verwendet, um abzuschätzen, wie weit eine bestimmte Ressource skaliert werden kann. Sie stellen den allgemeinen Bereich dar, in dem die beschriebenen Auswirkungen wahrscheinlicher werden. Das tatsächliche Verhalten hängt jedoch von Ihrer spezifischen Arbeitslast, Instanzgröße und Konfiguration ab. Auch wenn es möglich sein kann, diese Schätzungen zu übertreffen, müssen Sorgfalt und Wartung eingehalten werden, um die aufgeführten Auswirkungen zu vermeiden.
#
TOAST (The Oversized-Attribute Storage Technique) ist eine PostgreSQL-Funktion, die für die Verarbeitung großer Datenwerte entwickelt wurde, die die typische Datenbankblockgröße von 8 KB überschreiten. PostgreSQL erlaubt nicht, dass sich physische Zeilen über mehrere Blöcke erstrecken. Die Blockgröße dient als Obergrenze für die Zeilengröße. TOAST überwindet diese Einschränkung, indem große Feldwerte in kleinere Blöcke aufgeteilt werden. Es speichert sie separat in einer speziellen TOAST-Tabelle, die mit der Haupttabelle verknüpft ist. Weitere Informationen finden Sie in der Dokumentation zum [PostgreSQL TOAST-Speichermechanismus und](https://www.postgresql.org/docs/current/storage-toast.html) zur Implementierung.
**Topics**
+ [TOAST-Operationen verstehen](#Appendix.PostgreSQL.CommonDBATasks.TOAST_OID.HowWorks)
+ [Identifizierung von Leistungsherausforderungen](#Appendix.PostgreSQL.CommonDBATasks.TOAST_OID.PerformanceChallenges)
+ [Empfehlungen](#Appendix.PostgreSQL.CommonDBATasks.TOAST_OID.Recommendations)
+ [Überwachen](#Appendix.PostgreSQL.CommonDBATasks.TOAST_OID.Monitoring)
## TOAST-Operationen verstehen
TOAST führt eine Komprimierung durch und speichert große Feldwerte außerhalb der Zeile. TOAST weist jedem Block übergroßer Daten, die in der TOAST-Tabelle gespeichert sind, eine eindeutige OID (Object Identifier) zu. Die Haupttabelle speichert die TOAST-Wert-ID und die Beziehungs-ID auf der Seite, um auf die entsprechende Zeile in der TOAST-Tabelle zu verweisen. Dadurch kann PostgreSQL diese TOAST-Chunks effizient lokalisieren und verwalten. Wenn die TOAST-Tabelle jedoch wächst, besteht die Gefahr, dass das System die verfügbaren OIDs Ressourcen ausschöpft, was sowohl zu Leistungseinbußen als auch zu potenziellen Ausfallzeiten aufgrund der OID-Erschöpfung führt.
### Objektkennungen in TOAST
Ein Object Identifier (OID) ist ein systemweiter eindeutiger Identifier, der von PostgreSQL verwendet wird, um Datenbankobjekte wie Tabellen, Indizes und Funktionen zu referenzieren. Diese Identifikatoren spielen eine wichtige Rolle bei den internen Vorgängen von PostgreSQL und ermöglichen es der Datenbank, Objekte effizient zu lokalisieren und zu verwalten.
Für Tabellen mit Datensätzen, die für das Toasten in Frage kommen, weist PostgreSQL jedem übergroßen Datenblock, der in der zugehörigen TOAST-Tabelle gespeichert ist, eine eindeutige Identifizierung OIDs zu. Das System verknüpft jeden Chunk mit einem`chunk_id`, was PostgreSQL hilft, diese Chunks effizient in der TOAST-Tabelle zu organisieren und zu lokalisieren.
## Identifizierung von Leistungsherausforderungen
Das OID-Management von PostgreSQL stützt sich auf einen globalen 32-Bit-Zähler, sodass es nach der Generierung von 4 Milliarden eindeutigen Werten einen Umbruch durchführt. Der Datenbank-Cluster teilt sich diesen Zähler, aber die OID-Zuweisung umfasst bei TOAST-Vorgängen zwei Schritte:
+ **Globaler Zähler für die Zuweisung** — Der globale Zähler weist dem gesamten Cluster eine neue OID zu.
+ **Lokale Suche nach Konflikten** — Die TOAST-Tabelle stellt sicher, dass die neue OID nicht mit der in dieser bestimmten Tabelle OIDs bereits verwendeten OID in Konflikt steht.
Leistungseinbußen können auftreten, wenn:
+ Die TOAST-Tabelle weist eine hohe Fragmentierung oder eine hohe OID-Auslastung auf, was zu Verzögerungen bei der Zuweisung der OID führt.
+ OIDs In Umgebungen mit hoher Datenfluktuation oder großen Tabellen, in denen TOAST häufig verwendet wird, werden vom System häufig Zuweisungen vorgenommen und wiederverwendet.
Weitere Informationen finden Sie in der Dokumentation zur [PostgreSQL-TOAST-Tabellengröße und zur OID-Zuweisung](https://wiki.postgresql.org/wiki/TOAST#Total_table_size_limit):
Ein globaler Zähler generiert die Werte OIDs und schließt sie etwa alle 4 Milliarden ab, sodass das System von Zeit zu Zeit erneut einen bereits verwendeten Wert generiert. PostgreSQL erkennt das und versucht es erneut mit der nächsten OID. Ein langsames INSERT kann auftreten, wenn es eine sehr lange Reihe von verwendeten OID-Werten ohne Lücken in der TOAST-Tabelle gibt. Diese Probleme werden immer ausgeprägter, je größer der OID-Speicherplatz ist, was zu langsameren Einfügungen und Aktualisierungen führt.
### Identifizierung des Problems
+ Einfache `INSERT` Aussagen dauern auf inkonsistente und zufällige Weise deutlich länger als gewöhnlich.
+ Verzögerungen treten nur bei `INSERT` und bei `UPDATE` Anweisungen auf, die TOAST-Operationen beinhalten.
+ Die folgenden Protokolleinträge erscheinen in PostgreSQL-Protokollen, wenn das System Schwierigkeiten hat, verfügbare OIDs TOAST-Tabellen zu finden:
```
LOG: still searching for an unused OID in relation "pg_toast_20815"
DETAIL: OID candidates have been checked 1000000 times, but no unused OID has been found yet.
```
+ Performance Insights weist auf eine hohe Anzahl von durchschnittlichen aktiven Sitzungen (AAS) hin, die mit Ereignissen verknüpft sind `LWLock:buffer_io` und `LWLock:OidGenLock` warten.
Sie können die folgende SQL-Abfrage ausführen, um lang andauernde INSERT-Transaktionen mit Warteereignissen zu identifizieren:
```
SELECT
datname AS database_name,
usename AS database_user,
pid,
now() - pg_stat_activity.xact_start AS transaction_duration,
concat(wait_event_type, ':', wait_event) AS wait_event,
substr(query, 1, 30) AS TRANSACTION,
state
FROM
pg_stat_activity
WHERE (now() - pg_stat_activity.xact_start) > INTERVAL '60 seconds'
AND state IN ('active', 'idle in transaction', 'idle in transaction (aborted)', 'fastpath function call', 'disabled')
AND pid <> pg_backend_pid()
AND lower(query) LIKE '%insert%'
ORDER BY
transaction_duration DESC;
```
Beispiel für Abfrageergebnisse, die INSERT-Operationen mit längeren Wartezeiten anzeigen:
```
database_name | database_user | pid | transaction_duration | wait_event | transaction | state
---------------+-----------------+-------+----------------------+---------------------+--------------------------------+--------
postgres | db_admin_user| 70965 | 00:10:19.484061 | LWLock:buffer_io | INSERT INTO "products" (......... | active
postgres | db_admin_user| 69878 | 00:06:14.976037 | LWLock:buffer_io | INSERT INTO "products" (......... | active
postgres | db_admin_user| 68937 | 00:05:13.942847 | : | INSERT INTO "products" (......... | active
```
### Das Problem isolieren
+ **Test small insert — Fügt** einen Datensatz ein, der kleiner als der `toast_tuple_target` Schwellenwert ist. Denken Sie daran, dass die Komprimierung vor der TOAST-Speicherung angewendet wird. Wenn dies ohne Leistungsprobleme funktioniert, hängt das Problem mit TOAST-Vorgängen zusammen.
+ **Neue Tabelle testen** — Erstellen Sie eine neue Tabelle mit derselben Struktur und fügen Sie einen Datensatz ein, der größer als `toast_tuple_target` ist. Wenn das ohne Probleme funktioniert, ist das Problem auf die OID-Zuordnung der Originaltabelle beschränkt.
## Empfehlungen
Die folgenden Lösungsansätze können dabei helfen, Probleme mit TOAST-OID-Konflikten zu lösen.
+ **Datenbereinigung und Archivierung** — Überprüfen und löschen Sie alle veralteten oder unnötigen Daten, um sie OIDs für die future Verwendung freizugeben, oder archivieren Sie sie. Erwägen Sie die folgenden Einschränkungen:
+ Eingeschränkte Skalierbarkeit, da eine future Bereinigung möglicherweise nicht immer möglich ist.
+ Möglicher lang andauernder VACUUM-Vorgang, um die resultierenden toten Tupel zu entfernen.
+ In **eine neue Tabelle schreiben** — Erstellen Sie eine neue Tabelle für future Einfügungen und verwenden Sie eine `UNION ALL` Ansicht, um alte und neue Daten für Abfragen zu kombinieren. In dieser Ansicht werden die kombinierten Daten aus alten und neuen Tabellen dargestellt, sodass Abfragen auf sie als eine einzige Tabelle zugreifen können. Erwägen Sie die folgenden Einschränkungen:
+ Aktualisierungen der alten Tabelle können immer noch zu einer Überlastung der OID führen.
+ **Partition oder Shard** — Partitionieren Sie die Tabellen- oder Shard-Daten, um die Skalierbarkeit und Leistung zu verbessern. Erwägen Sie die folgenden Einschränkungen:
+ Höhere Komplexität bei der Abfragelogik und Wartung, potenzielle Notwendigkeit von Anwendungsänderungen, um partitionierte Daten korrekt verarbeiten zu können.
## Überwachen
### Verwendung von Systemtabellen
Sie können die Systemtabellen von PostgreSQL verwenden, um das Wachstum der OID-Nutzung zu überwachen.
**Warnung**
Je nach Anzahl der Einträge OIDs in der TOAST-Tabelle kann es einige Zeit dauern, bis der Vorgang abgeschlossen ist. Wir empfehlen, die Überwachung außerhalb der Geschäftszeiten einzuplanen, um die Auswirkungen zu minimieren.
Der folgende anonyme Block zählt die Anzahl der in jeder TOAST-Tabelle OIDs verwendeten Zeichen und zeigt die Informationen zur übergeordneten Tabelle an:
```
DO $$
DECLARE
r record;
o bigint;
parent_table text;
parent_schema text;
BEGIN
SET LOCAL client_min_messages TO notice;
FOR r IN
SELECT
c.oid,
c.oid::regclass AS toast_table
FROM
pg_class c
WHERE
c.relkind = 't'
AND c.relowner != 10 LOOP
-- Fetch the number of distinct used OIDs (chunk IDs) from the TOAST table
EXECUTE 'SELECT COUNT(DISTINCT chunk_id) FROM ' || r.toast_table INTO o;
-- If there are used OIDs, find the associated parent table and its schema
IF o <> 0 THEN
SELECT
n.nspname,
c.relname INTO parent_schema,
parent_table
FROM
pg_class c
JOIN pg_namespace n ON c.relnamespace = n.oid
WHERE
c.reltoastrelid = r.oid;
-- Raise a concise NOTICE message
RAISE NOTICE 'Parent schema: % | Parent table: % | Toast table: % | Number of used OIDs: %', parent_schema, parent_table, r.toast_table, TO_CHAR(o, 'FM9,999,999,999,999');
END IF;
END LOOP;
END
$$;
```
Beispielausgabe mit OID-Nutzungsstatistiken nach TOAST-Tabelle:
```
NOTICE: Parent schema: public | Parent table: my_table | Toast table: pg_toast.pg_toast_16559 | Number of used OIDs: 45,623,317
NOTICE: Parent schema: public | Parent table: my_table1 | Toast table: pg_toast.pg_toast_45639925 | Number of used OIDs: 10,000
NOTICE: Parent schema: public | Parent table: my_table2 | Toast table: pg_toast.pg_toast_45649931 | Number of used OIDs: 1,000,000
DO
```
Der folgende anonyme Block ruft die maximal zugewiesene OID für jede nicht leere TOAST-Tabelle ab:
```
DO $$
DECLARE
r record;
o bigint;
parent_table text;
parent_schema text;
BEGIN
SET LOCAL client_min_messages TO notice;
FOR r IN
SELECT
c.oid,
c.oid::regclass AS toast_table
FROM
pg_class c
WHERE
c.relkind = 't'
AND c.relowner != 10 LOOP
-- Fetch the max(chunk_id) from the TOAST table
EXECUTE 'SELECT max(chunk_id) FROM ' || r.toast_table INTO o;
-- If there's at least one TOASTed chunk, find the associated parent table and its schema
IF o IS NOT NULL THEN
SELECT
n.nspname,
c.relname INTO parent_schema,
parent_table
FROM
pg_class c
JOIN pg_namespace n ON c.relnamespace = n.oid
WHERE
c.reltoastrelid = r.oid;
-- Raise a concise NOTICE message
RAISE NOTICE 'Parent schema: % | Parent table: % | Toast table: % | Max chunk_id: %', parent_schema, parent_table, r.toast_table, TO_CHAR(o, 'FM9,999,999,999,999');
END IF;
END LOOP;
END
$$;
```
Beispielausgabe, die den maximalen Teil für TOAST-Tabellen IDs anzeigt:
```
NOTICE: Parent schema: public | Parent table: my_table | Toast table: pg_toast.pg_toast_16559 | Max chunk_id: 45,639,907
NOTICE: Parent schema: public | Parent table: my_table1 | Toast table: pg_toast.pg_toast_45639925 | Max chunk_id: 45,649,929
NOTICE: Parent schema: public | Parent table: my_table2 | Toast table: pg_toast.pg_toast_45649931 | Max chunk_id: 46,649,935
DO
```
### Verwendung von Performance-Insights
Die Warteereignisse `LWLock:buffer_io` `LWLock:OidGenLock` werden in Performance Insights bei Vorgängen angezeigt, für die neue Objektkennungen () OIDs zugewiesen werden müssen. High Average Active Sessions (AAS) für diese Ereignisse deuten in der Regel auf Konflikte bei der OID-Zuweisung und der Ressourcenverwaltung hin. Dies ist besonders häufig in Umgebungen mit hoher Datenfluktuation, umfangreicher Datennutzung oder häufiger Objekterstellung der Fall.
#### LWLockDies ist besonders häufig in Umgebungen mit hoher Datenfluktuation, umfangreicher Datennutzung oder häufiger Objekterstellung der Fall. ----sep----:buffer\$1io
`LWLock:buffer_io`ist ein Wartungsereignis, das auftritt, wenn eine PostgreSQL-Sitzung auf den Abschluss von I/O Vorgängen in einem gemeinsam genutzten Puffer wartet. Dies passiert normalerweise, wenn die Datenbank Daten von der Festplatte in den Speicher liest oder geänderte Seiten vom Speicher auf die Festplatte schreibt. Das `BufferIO` Wait-Ereignis gewährleistet Konsistenz, indem es verhindert, dass mehrere Prozesse während laufender I/O Operationen auf denselben Puffer zugreifen oder ihn ändern. Ein häufiges Auftreten dieses Warteereignisses kann auf Festplattenengpässe oder übermäßige I/O Aktivität bei der Datenbank-Arbeitslast hinweisen.
Während TOAST-Vorgängen:
+ PostgreSQL weist OIDs große Objekte zu und stellt deren Einzigartigkeit sicher, indem es den Index der TOAST-Tabelle scannt.
+ Große TOAST-Indizes erfordern möglicherweise den Zugriff auf mehrere Seiten, um die Eindeutigkeit der OID zu überprüfen. Dies führt zu mehr Festplatten-E/A, insbesondere wenn der Pufferpool nicht alle erforderlichen Seiten zwischenspeichern kann.
Die Größe des Indexes wirkt sich direkt auf die Anzahl der Pufferseiten aus, auf die während dieser Operationen zugegriffen werden muss. Selbst wenn der Index nicht aufgebläht ist, kann seine bloße Größe die Puffer-I/O erhöhen, insbesondere in Umgebungen mit hoher Parallelität oder hoher Kundenabwanderung. [Weitere Informationen finden Sie unter: Anleitung zur Fehlerbehebung bei BufferiO-WarteereignissenLWLock.](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/apg-waits.lwlockbufferio.html)
#### LWLock:OidGenLock
`OidGenLock`ist ein Wartungsereignis, das auftritt, wenn eine PostgreSQL-Sitzung darauf wartet, einen neuen Objektbezeichner (OID) zuzuweisen. Diese Sperre stellt sicher, dass OIDs sie sequentiell und sicher generiert werden, sodass jeweils nur ein Prozess generiert OIDs werden kann.
Während TOAST-Vorgängen:
+ **OID-Zuweisung für Chunks in der TOAST-Tabelle** — PostgreSQL weist Chunks in TOAST-Tabellen OIDs zu, wenn große Datensätze verwaltet werden. Jede OID muss eindeutig sein, um Konflikte im Systemkatalog zu vermeiden.
+ **Hohe Parallelität** — Da der Zugriff auf den OID-Generator sequentiell erfolgt, kann es zu Konflikten kommen, wenn mehrere Sitzungen gleichzeitig Objekte erstellen OIDs, die dies erfordern. `OidGenLock` Dies erhöht die Wahrscheinlichkeit, dass Sitzungen auf den Abschluss der OID-Zuweisung warten.
+ **Abhängigkeit vom Systemkatalogzugriff** — Für die Zuweisung OIDs sind Aktualisierungen der gemeinsam genutzten Systemkatalogtabellen wie `pg_class` und `pg_type` erforderlich. Wenn diese Tabellen stark beansprucht werden (aufgrund häufiger DDL-Operationen), kann sich der Sperrkonflikt für erhöhen. `OidGenLock`
+ **Hohe Nachfrage nach OID-Zuweisungen** — TOAST-Arbeitslasten mit großen Datensätzen erfordern eine konstante OID-Zuweisung, was zu mehr Konflikten führt.
Zusätzliche Faktoren, die den OID-Konflikt erhöhen:
+ **Häufige Objekterstellung** — Workloads, bei denen häufig Objekte erstellt und gelöscht werden, wie z. B. temporäre Tabellen, verstärken den Konflikt auf dem globalen OID-Zähler.
+ **Globales Sperren von Leistungsindikatoren** — Auf den globalen OID-Zähler wird seriell zugegriffen, um die Eindeutigkeit sicherzustellen, wodurch in Umgebungen mit hoher Parallelität ein einziger Streitpunkt entsteht.
## Arbeiten mit Protokollierungsmechanismen, die von RDS für PostgreSQL unterstützt werden
Es gibt mehrere Parameter, Erweiterungen und andere konfigurierbare Elemente, die Sie festlegen können, um Aktivitäten zu protokollieren, die auf Ihrer PostgreSQL-DB-Instance auftreten. Diese umfassen u. a. folgende:
+ Der Parameter `log_statement` kann verwendet werden, um in Ihrer PostgreSQL-Datenbank Benutzeraktivitäten zu protokollieren. Weitere Informationen über RDS für PostgreSQL-Protokollierung und zur Überwachung der Protokolle finden Sie unter [ RDS für PostgreSQL-Datenbankprotokolldateien](USER_LogAccess.Concepts.PostgreSQL.md).
+ Der Parameter `rds.force_admin_logging_level` protokolliert Aktionen durch den internen Amazon-RDS-Benutzer (rdsadmin) in den Datenbanken in der DB-Instance. Die Ausgabe wird in das PostgreSQL-Fehlerprotokoll geschrieben. Zulässige Werte sind `disabled`, `debug5`, `debug4`, `debug3`, `debug2`, `debug1`, `info`, `notice`, `warning`, `error`, Protokoll, `fatal` und `panic`. Der Standardwert ist `disabled`.
+ Der `rds.force_autovacuum_logging_level`-Parameter kann festgelegt werden, um verschiedene Selbstbereinigungsoperationen im PostgreSQL-Fehlerprotokoll zu erfassen. Weitere Informationen finden Sie unter [Protokollieren von Selbstbereinigung- und Bereinigungsaktivitäten](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.Logging.md).
+ Die PostgreSQL Audit (pgAudit)-Erweiterung kann installiert und konfiguriert werden, um Aktivitäten auf Sitzungsebene oder auf Objektebene zu erfassen. Weitere Informationen finden Sie unter [Verwenden von pgAudit zur Protokollierung der Datenbankaktivität](Appendix.PostgreSQL.CommonDBATasks.pgaudit.md).
+ Die `log_fdw`-Erweiterung ermöglicht es Ihnen, über SQL auf das Datenbank-Engine-Protokoll zuzugreifen. Weitere Informationen finden Sie unter [Verwenden der Erweiterung log\$1fdw für den Zugriff auf das DB-Protokoll mithilfe von SQL](CHAP_PostgreSQL.Extensions.log_fdw.md).
+ Die `pg_stat_statements`-Bibliothek ist als Standardwert für den `shared_preload_libraries`-Parameter in RDS für PostgreSQL Version 10 und höher angegeben. Mit dieser Bibliothek können Sie laufende Abfragen analysieren. Stellen Sie sicher, dass `pg_stat_statements` in Ihrer DB-Parametergruppe festgelegt ist. Weitere Informationen zur Überwachung Ihrer DB-Instance von RDS for PostgreSQL unter Verwendung der Informationen, die diese Bibliothek bereitstellt, finden Sie unter [SQL-Statistiken für RDS PostgreSQL](USER_PerfInsights.UsingDashboard.AnalyzeDBLoad.AdditionalMetrics.PostgreSQL.md).
+ Der `log_hostname`-Parameter erfasst den Hostnamen jeder Client-Verbindung im Protokoll. Für RDS für PostgreSQL Version 12 und höhere Versionen ist dieser Parameter standardmäßig auf `off` festgelegt. Wenn Sie ihn aktivieren, achten Sie darauf, die Verbindungszeiten der Sitzung zu überwachen. Wenn diese Option aktiviert ist, verwendet der Dienst die Reverse-Lookup-Anfrage des Domain Name Systems (DNS), um den Hostnamen des Clients, der die Verbindung herstellt, abzurufen und dem PostgreSQL-Protokoll hinzuzufügen. Dies hat spürbare Auswirkungen während der Sitzungsverbindung. Wir empfehlen, diesen Parameter nur für Fehlerbehebungszwecke zu aktivieren.
Im Allgemeinen ist der Zweck der Protokollierung, dass der DBA die Leistung überwachen, optimieren und Fehler beheben kann. Viele der Protokolle werden automatisch auf Amazon CloudWatch oder Performance Insights hochgeladen. Hier werden sie sortiert und gruppiert, um vollständige Metriken für die DB-Instance bereitzustellen. Weitere Informationen zur Amazon-RDS-Überwachung und -Metriken finden Sie unter [Überwachen von Metriken in einer Amazon-RDS-Instance](CHAP_Monitoring.md).
# Verwalten temporärer Dateien mit PostgreSQL
In PostgreSQL kann eine komplexe Abfrage möglicherweise mehrere Sortier- und Hash-Vorgänge gleichzeitig durchführen, wobei jeder Vorgang Instance-Speicher verwendet, um Ergebnisse bis zu dem im [https://www.postgresql.org/docs/current/runtime-config-resource.html#GUC-WORK-MEM](https://www.postgresql.org/docs/current/runtime-config-resource.html#GUC-WORK-MEM) angegebenen Wert zu speichern. Wenn der Instance-Speicher nicht ausreicht, werden temporäre Dateien erstellt, um die Ergebnisse zu speichern. Diese werden auf die Festplatte geschrieben, um die Abfrageausführung abzuschließen. Später werden diese Dateien automatisch entfernt, nachdem die Abfrage abgeschlossen ist. In RDS für PostgreSQL werden diese Dateien in Amazon EBS auf dem Datenvolume gespeichert. Weitere Informationen finden Sie unter [Amazon-RDS-DB-Instance Speicher](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Storage.html). Sie können die in veröffentlichte `FreeStorageSpace` Metrik überwachen CloudWatch , um sicherzustellen, dass Ihre DB-Instance über ausreichend freien Speicherplatz verfügt. Weitere Informationen finden Sie unter [https://repost.aws/knowledge-center/storage-full-rds-cloudwatch-alarm](https://repost.aws/knowledge-center/storage-full-rds-cloudwatch-alarm).
Wir empfehlen die Verwendung von Instances für Amazon-RDS-optimierte Lesevorgänge für Workloads mit mehreren gleichzeitigen Abfragen, die mehr temporäre Dateien nutzen. Diese verwenden lokalen, auf Non-Volatile Memory Express (NVMe) basierenden Solid-State-Drive-Speicher (SSD) auf Blockebene, um die temporären Dateien zu platzieren. Weitere Informationen finden Sie unter [Verbesserung der Abfrageleistung für RDS für PostgreSQL mit Amazon-RDS-optimierten Lesevorgängen](USER_PostgreSQL.optimizedreads.md).
Sie können die folgenden Parameter und Funktionen verwenden, um die temporären Dateien in Ihrer Instance zu verwalten.
+ **[https://www.postgresql.org/docs/current/runtime-config-resource.html#RUNTIME-CONFIG-RESOURCE-DISK](https://www.postgresql.org/docs/current/runtime-config-resource.html#RUNTIME-CONFIG-RESOURCE-DISK)** – Dieser Parameter bricht jede Abfrage ab, die die Größe von temp\$1files in KB überschreitet. Dieses Limit verhindert, dass Abfragen endlos ausgeführt werden und Speicherplatz mit temporären Dateien belegen. Sie können den Wert anhand der Ergebnisse des Parameters `log_temp_files` schätzen. Es hat sich bewährt, das Workload-Verhalten zu untersuchen und das Limit der Schätzung entsprechend festzulegen. Das folgende Beispiel zeigt, wie eine Abfrage abgebrochen wird, wenn sie das Limit überschreitet.
```
postgres=>select * from pgbench_accounts, pg_class, big_table;
```
```
ERROR: temporary file size exceeds temp_file_limit (64kB)
```
+ **[https://www.postgresql.org/docs/current/runtime-config-logging.html#GUC-LOG-TEMP-FILES](https://www.postgresql.org/docs/current/runtime-config-logging.html#GUC-LOG-TEMP-FILES)** – Dieser Parameter sendet Nachrichten an die Datei postgresql.log, wenn die temporären Dateien einer Sitzung entfernt werden. Dieser Parameter erstellt Protokolle, nachdem eine Abfrage erfolgreich abgeschlossen wurde. Daher ist er bei der Fehlerbehebung aktiver, lang andauernder Abfragen möglicherweise nicht hilfreich.
Das folgende Beispiel zeigt, dass nach erfolgreichem Abschluss der Abfrage die Einträge in der Datei postgresql.log protokolliert werden, während die temporären Dateien bereinigt werden.
```
2023-02-06 23:48:35 UTC:205.251.233.182(12456):adminuser@postgres:[31236]:LOG: temporary file: path "base/pgsql_tmp/pgsql_tmp31236.5", size 140353536
2023-02-06 23:48:35 UTC:205.251.233.182(12456):adminuser@postgres:[31236]:STATEMENT: select a.aid from pgbench_accounts a, pgbench_accounts b where a.bid=b.bid order by a.bid limit 10;
2023-02-06 23:48:35 UTC:205.251.233.182(12456):adminuser@postgres:[31236]:LOG: temporary file: path "base/pgsql_tmp/pgsql_tmp31236.4", size 180428800
2023-02-06 23:48:35 UTC:205.251.233.182(12456):adminuser@postgres:[31236]:STATEMENT: select a.aid from pgbench_accounts a, pgbench_accounts b where a.bid=b.bid order by a.bid limit 10;
```
+ **[https://www.postgresql.org/docs/current/functions-admin.html#FUNCTIONS-ADMIN-GENFILE](https://www.postgresql.org/docs/current/functions-admin.html#FUNCTIONS-ADMIN-GENFILE)** – Diese Funktion, die von RDS für PostgreSQL 13 und höher verfügbar ist, bietet Einblick in die aktuelle Nutzung temporärer Dateien. Die abgeschlossene Abfrage erscheint nicht in den Ergebnissen der Funktion. Im folgenden Beispiel können Sie sich die Ergebnisse dieser Funktion ansehen.
```
postgres=>select * from pg_ls_tmpdir();
```
```
name | size | modification
-----------------+------------+------------------------
pgsql_tmp8355.1 | 1072250880 | 2023-02-06 22:54:56+00
pgsql_tmp8351.0 | 1072250880 | 2023-02-06 22:54:43+00
pgsql_tmp8327.0 | 1072250880 | 2023-02-06 22:54:56+00
pgsql_tmp8351.1 | 703168512 | 2023-02-06 22:54:56+00
pgsql_tmp8355.0 | 1072250880 | 2023-02-06 22:54:00+00
pgsql_tmp8328.1 | 835031040 | 2023-02-06 22:54:56+00
pgsql_tmp8328.0 | 1072250880 | 2023-02-06 22:54:40+00
(7 rows)
```
```
postgres=>select query from pg_stat_activity where pid = 8355;
query
----------------------------------------------------------------------------------------
select a.aid from pgbench_accounts a, pgbench_accounts b where a.bid=b.bid order by a.bid
(1 row)
```
Der Dateiname enthält die Verarbeitungs-ID (PID) der Sitzung, die die temporäre Datei generiert hat. Eine komplexere Abfrage, wie im folgenden Beispiel, führt eine Summenberechnung der temporären Dateien für jede PID durch.
```
postgres=>select replace(left(name, strpos(name, '.')-1),'pgsql_tmp','') as pid, count(*), sum(size) from pg_ls_tmpdir() group by pid;
```
```
pid | count | sum
------+-------------------
8355 | 2 | 2144501760
8351 | 2 | 2090770432
8327 | 1 | 1072250880
8328 | 2 | 2144501760
(4 rows)
```
+ **`[ pg\$1stat\$1statements](https://www.postgresql.org/docs/current/pgstatstatements.html)`** – Wenn Sie den Parameter pg\$1stat\$1statements aktivieren, können Sie die durchschnittliche Nutzung temporärer Dateien pro Aufruf einsehen. Sie können die query\$1id der Abfrage identifizieren und verwenden, um die Nutzung temporärer Dateien zu untersuchen, wie im folgenden Beispiel gezeigt.
```
postgres=>select queryid from pg_stat_statements where query like 'select a.aid from pgbench%';
```
```
queryid
----------------------
-7170349228837045701
(1 row)
```
```
postgres=>select queryid, substr(query,1,25), calls, temp_blks_read/calls temp_blks_read_per_call, temp_blks_written/calls temp_blks_written_per_call from pg_stat_statements where queryid = -7170349228837045701;
```
```
queryid | substr | calls | temp_blks_read_per_call | temp_blks_written_per_call
----------------------+---------------------------+-------+-------------------------+----------------------------
-7170349228837045701 | select a.aid from pgbench | 50 | 239226 | 388678
(1 row)
```
+ **`[Performance Insights](https://aws.amazon.com/rds/performance-insights/)`** – Im Performance-Insights-Dashboard können Sie die Nutzung temporärer Dateien einsehen, indem Sie die Metriken **temp\$1bytes** und **temp\$1files** aktivieren. Anschließend können Sie den Durchschnitt dieser beiden Metriken sehen und feststellen, wie sie dem Abfrage-Workload entsprechen. In der Ansicht in Performance Insights werden nicht speziell die Abfragen angezeigt, die die temporären Dateien generieren. Wenn Sie jedoch Performance Insights mit der für `pg_ls_tmpdir` angezeigten Abfrage kombinieren, können Sie Fehler in Ihrem Abfrage-Workload beheben, analysieren und die Änderungen ermitteln.
Weitere Informationen zur Analyse von Metriken und Abfragen mit Performance Insights finden Sie unter [Analyse der Metriken mit dem Performance-Insights-Dashboard](USER_PerfInsights.UsingDashboard.md).
Ein Beispiel für die Anzeige der Nutzung temporärer Dateien mit Performance Insights finden Sie unter [Anzeigen der Nutzung temporärer Dateien mit Performance Insights](PostgreSQL.ManagingTempFiles.Example.md).
# Anzeigen der Nutzung temporärer Dateien mit Performance Insights
Sie können Performance Insights verwenden, um die Nutzung temporärer Dateien anzuzeigen, indem Sie die Metriken **temp\$1bytes** und **temp\$1files** aktivieren. Die Ansicht in Performance Insights zeigt nicht die spezifischen Abfragen an, die temporäre Dateien generieren. Wenn Sie jedoch Performance Insights mit der für `pg_ls_tmpdir` angezeigten Abfrage kombinieren, können Sie Fehler beheben, analysieren und die Änderungen in Ihrem Abfrage-Workload ermitteln.
1. Wählen Sie im Performance-Insights-Dashboard **Metriken verwalten** aus.
1. Wählen Sie **Datenbankmetriken** und die Metriken **temp\$1bytes** und **temp\$1files** aus, wie im folgenden Screenshot gezeigt.
![\[Im Diagramm dargestellte Metriken.\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/UserGuide/images/rpg_mantempfiles_metrics.png)
1. Wählen Sie auf der Registerkarte **Top SQL** das Symbol **Einstellungen** aus.
1. Schalten Sie im Fenster **Einstellungen** die folgenden Statistiken ein, damit sie auf der Registerkarte **Top SQL** angezeigt werden, und wählen Sie **Weiter** aus.
+ Temporäre Schreibvorgänge pro Sekunde
+ Temporäre Lesevorgänge pro Sekunde
+ Temporäre Massenschreibvorgänge/Aufruf
+ Temporäre Massenlesevorgänge/Aufruf
1. Die temporäre Datei wird aufgegliedert, wenn sie mit der für `pg_ls_tmpdir` gezeigten Abfrage kombiniert wird, wie im folgenden Beispiel gezeigt.
![\[Abfrage, die die Nutzung temporärer Dateien anzeigt.\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/UserGuide/images/rpg_mantempfiles_query.png)
Die `IO:BufFileRead`- und `IO:BufFileWrite`-Ereignisse treten auf, wenn die häufigsten Abfragen in Ihrem Workload häufig temporäre Dateien erstellen. Mit Performance Insights können Sie die häufigsten Abfragen identifizieren, die auf `IO:BufFileRead` und `IO:BufFileWrite` warten, indem Sie die Abschnitte Durchschnittliche aktive Vorträge (AAS) in Datenbanklast und Top SQL überprüfen.
![\[IO: BufFileRead und IO: BufFileWrite in der Grafik.\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/UserGuide/images/perfinsights_IOBufFile.png)
Weitere Informationen zur Analyse von Top-Abfragen und Last nach Warteereignis mit Performance Insights finden Sie unter [Überblick über die Registerkarte „Top SQL“](USER_PerfInsights.UsingDashboard.AnalyzeDBLoad.AdditionalMetrics.md#USER_PerfInsights.UsingDashboard.Components.AvgActiveSessions.TopLoadItemsTable.TopSQL). Sie sollten die Abfragen identifizieren und optimieren, die zu einer erhöhten Nutzung temporärer Dateien und damit verbundenen Warteereignissen führen. Weitere Informationen zu diesen Warteereignissen und deren Behebung finden Sie unter [IO: BufFileRead und IO: BufFileWrite](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/wait-event.iobuffile.html) .
**Anmerkung**
Der Parameter [https://www.postgresql.org/docs/current/runtime-config-resource.html#GUC-WORK-MEM](https://www.postgresql.org/docs/current/runtime-config-resource.html#GUC-WORK-MEM) steuert, wann der Sortiervorgang nicht mehr genügend Speicherplatz hat und die Ergebnisse in temporäre Dateien geschrieben werden. Wir empfehlen, die Einstellung dieses Parameters nicht höher als auf den Standardwert festzulegen, da dadurch jede Datenbanksitzung mehr Speicher belegen würde. Außerdem kann eine einzelne Sitzung, die komplexe Verknüpfungen und Sortierungen durchführt, parallele Operationen ausführen, bei denen jeder Vorgang Speicherplatz belegt.
Wenn Sie einen umfangreichen Bericht mit mehreren Verknüpfungen und Sortierungen haben, empfiehlt es sich, diesen Parameter mit dem Befehl `SET work_mem` auf Sitzungsebene festzulegen. Dann wird die Änderung nur auf die aktuelle Sitzung angewendet und der Wert nicht global geändert.
## Verwenden von pgBadger für die Protokollanalyse mit PostgreSQL
Sie können einen Protokollanalysierer wie [pgBadger](http://dalibo.github.io/pgbadger/) verwenden, um PostgreSQL-Protokolle zu analysieren. Die pgBadger-Dokumentation besagt, dass das Muster %l (Die Protokollzeile für die Sitzung oder den Prozess) ein Teil des Präfixes sein muss. Wenn Sie jedoch das aktuelle RDS `log_line_prefix` als Parameter für pgBadger angeben, wird dennoch ein Bericht erstellt.
Beispielsweise formatiert der folgende Befehl eine Amazon-RDS-for-PostgreSQL-Protokolldatei mit dem Datum 2014-02-04 korrekt unter Verwendung von pgBadger.
```
./pgbadger -f stderr -p '%t:%r:%u@%d:[%p]:' postgresql.log.2014-02-04-00
```
## PGSnapper Für die Überwachung von PostgreSQL verwenden
Sie können PGSnapper es als Unterstützung bei der regelmäßigen Erfassung leistungsbezogener Statistiken und Metriken von Amazon RDS for PostgreSQL verwenden. Weitere Informationen finden Sie unter [Überwachen der Leistung von Amazon RDS for PostgreSQL mithilfe](https://aws.amazon.com/blogs/database/monitor-amazon-rds-for-postgresql-and-amazon-aurora-postgresql-performance-using-pgsnapper/) von. PGSnapper
#
**Typumwandlung** in PostgreSQL ist der Prozess der Konvertierung eines Werts von einem Datentyp in einen anderen. PostgreSQL bietet integrierte Umwandlungen für viele gängige Konvertierungen, aber Sie können auch benutzerdefinierte Umwandlungen erstellen, um zu definieren, wie sich bestimmte Typkonvertierungen verhalten sollen.
Eine Umwandlung gibt an, wie eine Konvertierung von einem Datentyp in einen anderen durchgeführt wird. Zum Beispiel die Konvertierung von Text in `'123'` eine Ganzzahl `123` oder einer Zahl `45.67` in Text`'45.67'`.
Umfassende Informationen zu PostgreSQL-Casting-Konzepten und -Syntax finden Sie in der [PostgreSQL](https://www.postgresql.org/docs/current/sql-createcast.html) CREATE CAST-Dokumentation.
Ab den Versionen 13.23, 14.20, 15.15, 16.11, 17.7 und 18.1, können Sie die Erweiterung rds\$1casts verwenden, um zusätzliche Umwandlungen für integrierte Typen zu installieren und gleichzeitig Ihre eigenen Umwandlungen für benutzerdefinierte Typen zu erstellen.
**Topics**
+ [Installation und Verwendung der Erweiterung rds\$1casts](#PostgreSQL.CustomCasts.Installing)
+ [Unterstützte Casts](#PostgreSQL.CustomCasts.Supported)
+ [Umwandlungen erstellen oder löschen](#PostgreSQL.CustomCasts.Creating)
+ [Erstellen von benutzerdefinierten Besetzungen mit der richtigen Kontextstrategie](#PostgreSQL.CustomCasts.BestPractices)
## Installation und Verwendung der Erweiterung rds\$1casts
Um die `rds_casts` Erweiterung zu erstellen, stellen Sie eine Verbindung zur (Ihre RDS for PostgreSQL-DB-Instance) her `rds_superuser` und führen Sie den folgenden Befehl aus:
```
CREATE EXTENSION IF NOT EXISTS rds_casts;
```
## Unterstützte Casts
Erstellen Sie die Erweiterung in jeder Datenbank, in der Sie benutzerdefinierte Casts verwenden möchten. Verwenden Sie nach dem Erstellen der Erweiterung den folgenden Befehl, um alle verfügbaren Casts anzuzeigen:
```
SELECT * FROM rds_casts.list_supported_casts();
```
Diese Funktion listet die verfügbaren Cast-Kombinationen auf (Quelltyp, Zieltyp, Zwangskontext und Cast-Funktion). Zum Beispiel, wenn Sie to `numeric` als Besetzung erstellen `text` möchten. `implicit` Sie können die folgende Abfrage verwenden, um herauszufinden, ob die Besetzung zum Erstellen verfügbar ist:
```
SELECT * FROM rds_casts.list_supported_casts()
WHERE source_type = 'text' AND target_type = 'numeric';
id | source_type | target_type | qualified_function | coercion_context
----+-------------+-------------+--------------------------------------+------------------
10 | text | numeric | rds_casts.rds_text_to_numeric_custom | implicit
11 | text | numeric | rds_casts.rds_text_to_numeric_custom | assignment
13 | text | numeric | rds_casts.rds_text_to_numeric_custom | explicit
20 | text | numeric | rds_casts.rds_text_to_numeric_inout | implicit
21 | text | numeric | rds_casts.rds_text_to_numeric_inout | assignment
23 | text | numeric | rds_casts.rds_text_to_numeric_inout | explicit
```
Die Erweiterung rds\$1casts bietet zwei Arten von Konvertierungsfunktionen für jede Besetzung:
+ *\$1inout-Funktionen* — Verwenden Sie den I/O Standard-Konvertierungsmechanismus von PostgreSQL, der sich genauso verhält wie Casts, die mit der INOUT-Methode erstellt wurden
+ *\$1benutzerdefinierte Funktionen* — Stellen eine erweiterte Konvertierungslogik bereit, die Sonderfälle behandelt, z. B. die Konvertierung leerer Zeichenketten in NULL-Werte, um Konvertierungsfehler zu vermeiden
Die `inout` Funktionen replizieren das native Casting-Verhalten von PostgreSQL, während `custom` Funktionen diese Funktionalität erweitern, indem sie Szenarien behandeln, die mit Standard-INOUT-Umwandlungen nicht berücksichtigt werden können, wie z. B. die Konvertierung leerer Zeichenketten in ganze Zahlen.
## Umwandlungen erstellen oder löschen
Sie können unterstützte Besetzungen mit zwei Methoden erstellen und löschen:
### Erstellung von Darstellern
**Methode 1: Verwenden des nativen CREATE CAST-Befehls**
```
CREATE CAST (text AS numeric)
WITH FUNCTION rds_casts.rds_text_to_numeric_custom
AS IMPLICIT;
```
**Methode 2: Verwendung der Funktion rds\$1casts.create\$1cast**
```
SELECT rds_casts.create_cast(10);
```
Die `create_cast` Funktion verwendet die ID aus der Ausgabe. `list_supported_casts()` Diese Methode ist einfacher und stellt sicher, dass Sie die richtige Kombination aus Funktion und Kontext verwenden. Es ist garantiert, dass diese ID in verschiedenen Postgres-Versionen gleich bleibt.
Um zu überprüfen, ob der Cast erfolgreich erstellt wurde, fragen Sie den pg\$1cast-Systemkatalog ab:
```
SELECT oid, castsource::regtype, casttarget::regtype, castfunc::regproc, castcontext, castmethod
FROM pg_cast
WHERE castsource = 'text'::regtype AND casttarget = 'numeric'::regtype;
oid | castsource | casttarget | castfunc | castcontext | castmethod
--------+------------+------------+--------------------------------------+-------------+------------
356372 | text | numeric | rds_casts.rds_text_to_numeric_custom | i | f
```
Die `castcontext` Spalte zeigt: `e` für EXPLICIT, für ASSIGNMENT oder `a` `i` für IMPLICIT.
### Besetzungen löschen
**Methode 1: Verwenden des Befehls DROP CAST**
```
DROP CAST IF EXISTS (text AS numeric);
```
**Methode 2: Verwendung der Funktion rds\$1casts.drop\$1cast**
```
SELECT rds_casts.drop_cast(10);
```
Die `drop_cast` Funktion verwendet dieselbe ID, die bei der Erstellung der Besetzung verwendet wurde. Diese Methode stellt sicher, dass Sie genau die Besetzung löschen, die mit der entsprechenden ID erstellt wurde.
## Erstellen von benutzerdefinierten Besetzungen mit der richtigen Kontextstrategie
Beim Erstellen mehrerer Umwandlungen für Integer-Typen können Operator-Mehrdeutigkeitsfehler auftreten, wenn alle Umwandlungen als IMPLIZIT erstellt werden. Das folgende Beispiel veranschaulicht dieses Problem, indem zwei implizite Umwandlungen von Text in unterschiedliche Ganzzahlbreiten erstellt werden:
```
-- Creating multiple IMPLICIT casts causes ambiguity
postgres=> CREATE CAST (text AS int4) WITH FUNCTION rds_casts.rds_text_to_int4_custom(text) AS IMPLICIT;
CREATE CAST
postgres=> CREATE CAST (text AS int8) WITH FUNCTION rds_casts.rds_text_to_int8_custom(text) AS IMPLICIT;
CREATE CAST
postgres=> CREATE TABLE test_cast(col int);
CREATE TABLE
postgres=> INSERT INTO test_cast VALUES ('123'::text);
INSERT 0 1
postgres=> SELECT * FROM test_cast WHERE col='123'::text;
ERROR: operator is not unique: integer = text
LINE 1: SELECT * FROM test_cast WHERE col='123'::text;
^
HINT: Could not choose a best candidate operator. You might need to add explicit type casts.
```
Der Fehler tritt auf, weil PostgreSQL nicht bestimmen kann, welche implizite Umwandlung beim Vergleich einer Integer-Spalte mit einem Textwert verwendet werden soll. Sowohl die implizite Umwandlung von int4 als auch die implizite Umwandlung von int8 sind gültige Kandidaten, was zu Mehrdeutigkeiten führt.
Um diese Mehrdeutigkeit der Operatoren zu vermeiden, verwenden Sie den ASSIGNMENT-Kontext für kleinere Ganzzahlbreiten und den IMPLIZITEN Kontext für größere Ganzzahlbreiten:
```
-- Use ASSIGNMENT for smaller integer widths
CREATE CAST (text AS int2)
WITH FUNCTION rds_casts.rds_text_to_int2_custom(text)
AS ASSIGNMENT;
CREATE CAST (text AS int4)
WITH FUNCTION rds_casts.rds_text_to_int4_custom(text)
AS ASSIGNMENT;
-- Use IMPLICIT for larger integer widths
CREATE CAST (text AS int8)
WITH FUNCTION rds_casts.rds_text_to_int8_custom(text)
AS IMPLICIT;
postgres=> INSERT INTO test_cast VALUES ('123'::text);
INSERT 0 1
postgres=> SELECT * FROM test_cast WHERE col='123'::text;
col
-----
123
(1 row)
```
Bei dieser Strategie ist nur die int8-Umwandlung implizit, sodass PostgreSQL eindeutig bestimmen kann, welche Umwandlung verwendet werden soll.
# Bewährte Methoden für parallele Abfragen in
Die parallele Abfrageausführung ist eine Funktion in PostgreSQL, mit der eine einzelne SQL-Abfrage in kleinere Aufgaben aufgeteilt werden kann, die gleichzeitig von mehreren Hintergrund-Worker-Prozessen verarbeitet werden. Anstatt eine Abfrage vollständig in einem einzigen Backend-Prozess auszuführen, kann PostgreSQL Teile der Abfrage, wie Scans, Joins, Aggregationen oder Sortierungen, auf mehrere CPU-Kerne verteilen. Der *Leader-Prozess* koordiniert diese Ausführung und sammelt die Ergebnisse der *parallel Mitarbeiter*.
Für die meisten Produktionsworkloads, insbesondere OLTP-Systeme mit hoher Parallelität, empfehlen wir jedoch, die automatische parallel Abfrageausführung zu deaktivieren. Parallelität kann zwar Abfragen großer Datenmengen bei Analyse- oder Berichtsworkloads beschleunigen, birgt jedoch erhebliche Risiken, die in geschäftigen Produktionsumgebungen häufig die Vorteile überwiegen.
Die parallele Ausführung bringt auch einen erheblichen Mehraufwand mit sich. Jeder parallel Worker ist ein vollständiger PostgreSQL-Backend-Prozess, der Prozessforking (Kopieren von Speicherstrukturen und Initialisieren des Prozessstatus) und Authentifizierung (Nutzung von Verbindungssteckplätzen von Ihrem Limit) erfordert. `max_connections` Jeder Worker verbraucht außerdem seinen eigenen Speicher, auch `work_mem` für Sortier- und Hashing-Operationen. Bei mehreren Workern pro Abfrage vervielfacht sich die Speicherbelegung schnell (z. B. 4 Worker × 64 MB = 256 MB pro Abfrage). `work_mem` Aus diesem Grund können parallel Abfragen erheblich mehr Systemressourcen verbrauchen als Abfragen mit einem einzigen Prozess. Wenn sie nicht richtig eingestellt sind, können sie zu CPU-Sättigung (mehrere Worker überfordern die verfügbare Verarbeitungskapazität), verstärktem Kontextwechsel (das Betriebssystem wechselt häufig zwischen zahlreichen Worker-Prozessen, was den Overhead erhöht und den Durchsatz reduziert) oder zu Verbindungsausfällen führen (da jeder parallel Worker einen Verbindungssteckplatz beansprucht, verwendet eine einzelne Abfrage mit 4 Workern insgesamt 5 Verbindungen, 1 Leader und 4 Worker, was Ihren Verbindungspool bei hoher Parallelität schnell erschöpfen kann, wodurch neue Clientverbindungen verhindert und Anwendungsausfälle verursacht werden). Diese Probleme sind besonders schwerwiegend bei Workloads mit hoher Parallelität, bei denen mehrere Abfragen versuchen können, gleichzeitig ausgeführt zu werden.
PostgreSQL entscheidet auf der Grundlage von Kostenschätzungen, ob Parallelität verwendet werden soll. In einigen Fällen kann der Planer automatisch zu einem Parallelplan wechseln, wenn dieser günstiger erscheint, auch wenn er in der Praxis nicht ideal ist. Dies kann der Fall sein, wenn Indexstatistiken veraltet sind oder wenn durch Aufblähung sequentielle Scans attraktiver erscheinen als Indexsuchen. Aufgrund dieses Verhaltens können automatische parallel Pläne manchmal zu Regressionen bei der Abfrageleistung oder Systemstabilität führen.
Um den größtmöglichen Nutzen aus parallel Abfragen in zu ziehen, ist es wichtig, sie auf der Grundlage Ihrer Arbeitslast zu testen und zu optimieren, die Auswirkungen auf das System zu überwachen und die automatische parallel Planauswahl zugunsten der Steuerung auf Abfrageebene zu deaktivieren.
## Konfigurationsparameter
PostgreSQL verwendet mehrere Parameter, um das Verhalten und die Verfügbarkeit parallel Abfragen zu steuern. Diese zu verstehen und zu optimieren, ist entscheidend, um eine vorhersehbare Leistung zu erzielen:
| Parameter | Description | Standard |
| --- | --- | --- |
| max\$1parallel\$1workers | Maximale Anzahl von Hintergrund-Worker-Prozessen, die insgesamt ausgeführt werden können | AM GRÖSSTEN (\$1 DBInstance VCPU/2,8) |
| max\$1parallel\$1workers\$1per\$1gather | Maximale Anzahl von Workern pro Abfrageplanknoten (z. B. pro) Gather | 2 |
| parallel\$1setup\$1cost | Zusätzliche Planerkosten für die Initiierung einer parallel Abfrageinfrastruktur | 1000 |
| parallel\$1tuple\$1cost | Kosten pro im Parallelmodus verarbeitetem Tupel (wirkt sich auf die Entscheidung des Planers aus) | 0.1 |
| force\$1parallel\$1mode | Zwingt den Planer, parallel Pläne zu testen (off,on,regress) | off |
### Wichtige Überlegungen
+ `max_parallel_workers`kontrolliert den gesamten Pool parallel Mitarbeiter. Wenn der Wert zu niedrig ist, können einige Abfragen auf die serielle Ausführung zurückgreifen.
+ `max_parallel_workers_per_gather`wirkt sich darauf aus, wie viele Worker eine einzelne Abfrage verwenden kann. Ein höherer Wert erhöht die Parallelität, erhöht aber auch die Ressourcennutzung.
+ `parallel_setup_cost`und `parallel_tuple_cost` wirken sich auf das Kostenmodell des Planers aus. Eine Senkung dieser Werte kann die Wahrscheinlichkeit erhöhen, dass parallel Pläne gewählt werden.
+ `force_parallel_mode`ist für Tests nützlich, sollte aber nicht in der Produktion verwendet werden, sofern dies nicht erforderlich ist.
**Anmerkung**
Der Standardwert des `max_parallel_workers` Parameters wird anhand der Instanzgröße anhand der Formel dynamisch berechnet`GREATEST($DBInstanceVCPU/2, 8)`. Das heißt, wenn Sie Ihre auf eine größere Rechengröße mit mehr v skalierenCPUs, wird die maximale Anzahl verfügbarer parallel Worker automatisch erhöht. Infolgedessen können Abfragen, die zuvor seriell oder mit eingeschränkter Parallelität ausgeführt wurden, nach einem Scale-up-Vorgang plötzlich mehr parallel Worker verwenden, was möglicherweise zu einem unerwarteten Anstieg der Verbindungs-, CPU- und Speicherauslastung führen kann. Es ist wichtig, das Verhalten parallel Abfragen nach jedem Rechenskalierungsereignis zu überwachen und `max_parallel_workers_per_gather` gegebenenfalls anzupassen, um eine vorhersehbare Ressourcennutzung aufrechtzuerhalten.
## Identifizieren Sie die Nutzung paralleler Abfragen
Abfragen können zu parallel Plänen wechseln, die auf Datenverteilung oder Statistiken basieren. Beispiel:
```
SELECT count(*) FROM customers WHERE last_login < now() - interval '6 months';
```
Diese Abfrage verwendet möglicherweise einen Index für aktuelle Daten, wechselt jedoch zu einem parallel sequentiellen Scan für historische Daten.
Sie können Ausführungspläne für Abfragen protokollieren, indem Sie das `auto_explain` Modul laden. Weitere Informationen finden Sie im AWS Knowledge Center unter [Ausführungspläne von Abfragen protokollieren](https://aws.amazon.com/premiumsupport/knowledge-center/rds-postgresql-tune-query-performance/#).
Sie können [CloudWatch Database Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Database-Insights-Database-Instance-Dashboard.html) auf Warteereignisse im Zusammenhang mit parallelen Abfragen überwachen. Weitere Informationen zu Warteereignissen im Zusammenhang mit Parallel Query finden Sie unter [IPC:Parallele](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/apg-ipc-parallel.html) Warteereignisse
Ab PostgreSQL Version 18 können Sie parallel Worker-Aktivitäten mithilfe neuer Spalten in [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)und überwachen: [https://www.postgresql.org/docs/current/pgstatstatements.html](https://www.postgresql.org/docs/current/pgstatstatements.html)
+ `parallel_workers_to_launch`: Anzahl der parallel arbeitenden Mitarbeiter, deren Einführung geplant ist
+ `parallel_workers_launched`: Anzahl der tatsächlich eingeführten Parallelarbeiter
Diese Kennzahlen helfen dabei, Diskrepanzen zwischen der geplanten und der tatsächlichen Parallelität zu erkennen, die auf Ressourcenbeschränkungen oder Konfigurationsprobleme hinweisen können. Verwenden Sie die folgenden Abfragen, um die parallel Ausführung zu überwachen:
Für Parallel-Worker-Metriken auf Datenbankebene:
```
SELECT datname, parallel_workers_to_launch, parallel_workers_launched
FROM pg_stat_database
WHERE datname = current_database();
```
Für Parallel-Worker-Metriken auf Abfrageebene
```
SELECT query, parallel_workers_to_launch, parallel_workers_launched
FROM pg_stat_statements
ORDER BY parallel_workers_launched;
```
## Wie kontrolliert man Parallelität
Es gibt mehrere Möglichkeiten, die Abfrageparallelität zu kontrollieren, die jeweils für unterschiedliche Szenarien und Anforderungen konzipiert sind.
Um die automatische Parallelität global zu deaktivieren, und legen [Sie Folgendes fest](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_WorkingWithParamGroups.Modifying.html):
```
max_parallel_workers_per_gather = 0;
```
Für persistente, benutzerspezifische Einstellungen bietet der Befehl ALTER ROLE eine Möglichkeit, Parameter festzulegen, die für alle future Sitzungen eines bestimmten Benutzers gelten.
Beispiel:
`ALTER ROLE username SET max_parallel_workers_per_gather = 4;`stellt sicher, dass jedes Mal, wenn dieser Benutzer eine Verbindung zur Datenbank herstellt, seine Sitzungen bei Bedarf diese Parallel-Worker-Einstellung verwenden.
Die Steuerung auf Sitzungsebene kann mit dem Befehl SET erreicht werden, der die Parameter für die Dauer der aktuellen Datenbanksitzung ändert. Dies ist besonders nützlich, wenn Sie Einstellungen vorübergehend anpassen müssen, ohne dass dies Auswirkungen auf andere Benutzer oder future Sitzungen hat. Einmal festgelegt, bleiben diese Parameter gültig, bis sie explizit zurückgesetzt werden oder bis die Sitzung beendet wird. Die Befehle sind einfach:
```
SET max_parallel_workers_per_gather = 4;
-- Run your queries
RESET max_parallel_workers_per_gather;
```
Für eine noch detailliertere Steuerung können Sie mit SET LOCAL die Parameter für eine einzelne Transaktion ändern. Dies ist ideal, wenn Sie die Einstellungen für einen bestimmten Satz von Abfragen innerhalb einer Transaktion anpassen müssen. Danach werden die Einstellungen automatisch auf ihre vorherigen Werte zurückgesetzt. Dieser Ansatz trägt dazu bei, unbeabsichtigte Auswirkungen auf andere Vorgänge innerhalb derselben Sitzung zu verhindern.
## Diagnostizieren des Verhaltens paralleler Abfragen
Wird verwendet`EXPLAIN (ANALYZE, VERBOSE)`, um zu überprüfen, ob eine Abfrage parallel ausgeführt wurde:
+ Suchen Sie nach Knoten wie `Gather``Gather Merge`, oder`Parallel Seq Scan`.
+ Vergleichen Sie Pläne mit und ohne Parallelität.
So deaktivieren Sie die Parallelität vorübergehend zum Vergleich:
```
SET max_parallel_workers_per_gather = 0;
EXPLAIN ANALYZE ;
RESET max_parallel_workers_per_gather;
```
# Arbeiten mit Parametern auf der DB-Instance von RDS for PostgreSQL
In einigen Fällen können Sie eine DB-Instance für RDS for PostgreSQL erstellen, ohne eine benutzerdefinierte Parametergruppe anzugeben. In diesem Fall wird Ihre DB-Instance mit der Standardparametergruppe für die von Ihnen gewählte Version von PostgreSQL erstellt. Angenommen, Sie erstellen eine DB-Instance für RDS for PostgreSQL mit PostgreSQL 13.3. In diesem Fall wird die DB-Instance unter Verwendung der Werte in der Parametergruppe für PostgreSQL-13-Versionen, `default.postgres13`, erstellt.
Sie können auch eine eigene benutzerdefinierte DB-Parametergruppe erstellen. Sie müssen dies tun, wenn Sie die Einstellungen der Standardwerte für die DB-Instance von RDS for PostgreSQL ändern möchten. Um zu erfahren wie dies geht, vgl. [Parametergruppen für Amazon RDS](USER_WorkingWithParamGroups.md).
Sie können die Einstellungen auf der DB-Instance von RDS for PostgreSQL auf verschiedene Arten verfolgen. Sie können die AWS-Managementkonsole AWS CLI, oder die Amazon RDS-API verwenden. Sie können die Werte auch aus der PostgreSQL `pg_settings`-Tabelle Ihrer Instance abfragen, wie im Folgenden dargestellt.
```
SELECT name, setting, boot_val, reset_val, unit
FROM pg_settings
ORDER BY name;
```
Weitere Informationen zu von dieser Abfrage zurückgegebenen Werten finden Sie unter [https://www.postgresql.org/docs/current/view-pg-settings.html](https://www.postgresql.org/docs/current/view-pg-settings.html) in der PostgreSQL-Dokumentation.
Seien Sie besonders vorsichtig, wenn Sie die Einstellungen für `max_connections` und `shared_buffers` auf Ihrer DB-Instance von RDS für PostgreSQL ändern. Nehmen Sie zum Beispiel an, dass Sie die Einstellungen für `max_connections` oder `shared_buffers` ändern und Werte verwenden, die für den tatsächlichen Workload zu hoch sind. In diesem Fall wird die DB-Instance von RDS for PostgreSQL nicht gestartet. In diesem Fall wird Ihnen in `postgres.log` ein Fehler ähnlich dem folgenden angezeigt:
```
2018-09-18 21:13:15 UTC::@:[8097]:FATAL: could not map anonymous shared memory: Cannot allocate memory
2018-09-18 21:13:15 UTC::@:[8097]:HINT: This error usually means that PostgreSQL's request for a shared memory segment
exceeded available memory or swap space. To reduce the request size (currently 3514134274048 bytes), reduce
PostgreSQL's shared memory usage, perhaps by reducing shared_buffers or max_connections.
```
Sie können jedoch keine Werte der Einstellungen ändern, die in Standard-RDS-for-PostgreSQL-DB-Parametergruppen enthalten sind. Um die Einstellungen für Parameter zu ändern, erstellen Sie zuerst eine benutzerdefinierte DB-Parametergruppe. Ändern Sie dann die Einstellungen in dieser benutzerdefinierten Gruppe und wenden Sie dann die benutzerdefinierte Parametergruppe auf die DB-Instance von RDS for PostgreSQL an. Weitere Informationen hierzu finden Sie unter [Parametergruppen für Amazon RDS](USER_WorkingWithParamGroups.md).
Für PostgreSQL-DB-Parameter gibt es zwei Arten von Parametern.
+ **Statische Parameter** – Statische Parameter erfordern den Neustart der DB-Instance von RDS für PostgreSQL nach einer Änderung, damit der neue Wert angewendet wird.
+ **Dynamische Parameter** – Dynamische Parameter erfordern keinen Neustart, nachdem ihre Einstellungen geändert wurden.
**Anmerkung**
Wenn Ihre DB-Instance von RDS für PostgreSQL Ihre eigene benutzerdefinierte DB-Parametergruppe verwendet, können Sie die Werte dynamischer Parameter auf der laufenden DB-Instance ändern. Sie können dies tun, indem Sie die AWS-Managementkonsole AWS CLI, oder die Amazon RDS-API verwenden.
Wenn Sie die nötigen Berechtigungen dafür besitzen, können Sie Parameterwerte auch ändern, indem Sie die Befehle `ALTER DATABASE`, `ALTER ROLE` und `SET` verwenden.
## DB-Instance-Parameterliste von RDS für PostgreSQL
In der folgenden Tabelle sind einige (nicht alle) Parameter aufgeführt, die in einer DB-Instance von RDS für PostgreSQL verfügbar sind. Um alle verfügbaren Parameter anzuzeigen, verwenden Sie den [describe-db-parameters](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-parameters.html) AWS CLI Befehl. Wenn Sie beispielsweise die Liste aller Parameter abrufen möchten, die in der Standardparametergruppe für Version 13 von RDS für PostgreSQL verfügbar sind, führen Sie den folgenden Befehl aus.
```
aws rds describe-db-parameters --db-parameter-group-name default.postgres13
```
Sie können auch die Konsole verwenden. Wählen Sie **Parameter groups** (Parametergruppen) aus dem Amazon-RDS-Menü und dann die Parametergruppe aus den in Ihrer AWS-Region verfügbaren Gruppen aus.
| Parametername | Apply\$1Type | Beschreibung |
| --- | --- | --- |
| `application_name` | Dynamisch | Legt den Namen der Anwendung fest, der in Statistiken und Protokollen verwendet werden soll. |
| `archive_command` | Dynamisch | Legt den Shell-Befehl fest, der zum Archivieren einer WAL-Datei aufgerufen wird. |
| `array_nulls` | Dynamisch | Ermöglicht die Eingabe von NULL-Elementen in Arrays. |
| `authentication_timeout` | Dynamisch | Legt die Zeit fest, die maximal zulässig ist, um die Client-Authentifizierung durchzuführen. |
| `autovacuum` | Dynamisch | Startet den Untervorgang der Selbstbereinigung. |
| `autovacuum_analyze_scale_factor` | Dynamisch | Anzahl von Tupel-Einfügungen, -Aktualisierungen oder -Löschungen vor der Analyse als Bruchteil von Reltupeln. |
| `autovacuum_analyze_threshold` | Dynamisch | Mindestanzahl von Tupel-Einfügungen, -Aktualisierungen oder -Löschungen vor der Analyse. |
| `autovacuum_freeze_max_age` | Statisch | Alter, bei dem eine Selbstbereinigung für eine Tabelle ausgeführt werden soll, um einen Transaktions-ID-Wraparound zu verhindern. |
| `autovacuum_naptime` | Dynamisch | Inaktivitätszeit zwischen Selbstbereinigungen. |
| `autovacuum_max_workers` | Statisch | Legt die maximale Anzahl gleichzeitig ausgeführter Worker-Vorgänge für die Selbstbereinigung fest. |
| `autovacuum_vacuum_cost_delay` | Dynamisch | Bereinigungskostenverzögerung (in Millisekunden) für die Selbstbereinigung. |
| `autovacuum_vacuum_cost_limit` | Dynamisch | Bereinigungskostenbetrag für die Selbstbereinigung, der vor der Inaktivität verfügbar ist. |
| `autovacuum_vacuum_scale_factor` | Dynamisch | Anzahl von Tupel-Aktualisierungen oder -Löschungen vor der Bereinigung als Bruchteil von Reltupeln. |
| `autovacuum_vacuum_threshold` | Dynamisch | Mindestanzahl von Tupel-Aktualisierungen oder -Löschungen vor der Bereinigung. |
| `backslash_quote` | Dynamisch | Legt fest, ob in Zeichenfolgeliteralen ein Backslash (\$1) zulässig ist. |
| `bgwriter_delay` | Dynamisch | Inaktivitätszeit des Hintergrundschreibers zwischen Runden. |
| `bgwriter_lru_maxpages` | Dynamisch | Maximale Anzahl von LRU-Seiten eines Hintergrundschreibers, für die pro Runde ein Flush ausgeführt werden kann. |
| `bgwriter_lru_multiplier` | Dynamisch | Mehrfaches der durchschnittlichen Puffernutzung, die pro Runde freigegeben werden soll. |
| `bytea_output` | Dynamisch | Legt das Ausgabeformat für Bytes fest. |
| `check_function_bodies` | Dynamisch | Überprüft die Funktionstexte während CREATE FUNCTION. |
| `checkpoint_completion_target` | Dynamisch | Zeit für den Flush ungültiger Puffer während des Prüfpunkts als Bruchteil des Prüfpunktintervalls. |
| `checkpoint_segments` | Dynamisch | Legt die maximale Entfernung in Protokollsegmenten zwischen automatischen Write-Ahead Log (WAL)-Prüfpunkten fest. |
| `checkpoint_timeout` | Dynamisch | Legt die maximale Zeit zwischen automatischen WAL-Prüfpunkten fest. |
| `checkpoint_warning` | Dynamisch | Ermöglicht Warnungen, wenn Prüfpunktsegmente häufiger als hierdurch angegeben gefüllt werden. |
| `client_connection_check_interval` | Dynamisch | Legt das Zeitintervall zwischen Prüfungen auf Verbindungsabbrüche während der Ausführung von Abfragen fest. |
| `client_encoding` | Dynamisch | Legt die Zeichensatzkodierung des Client fest. |
| `client_min_messages` | Dynamisch | Legt die Nachrichtenebenen fest, die an den Client gesendet werden. |
| `commit_delay` | Dynamisch | Legt die Verzögerung (in Mikrosekunden) zwischen dem Transaktions-Commit und dem Flush von WAL zum Datenträger fest. |
| `commit_siblings` | Dynamisch | Legt die Mindestzahl gleichzeitiger offener Transaktionen fest, bevor eine Commit-Verzögerung ausgeführt wird. |
| `constraint_exclusion` | Dynamisch | Ermöglicht dem Planer die Verwendung von Einschränkungen, um Abfragen zu optimieren. |
| `cpu_index_tuple_cost` | Dynamisch | Legt die Schätzung des Planers für die Kosten der Verarbeitung der einzelnen Indexeinträge während einer Indexprüfung fest. |
| `cpu_operator_cost` | Dynamisch | Legt die Schätzung des Planers für die Kosten der Verarbeitung der einzelnen Operator- oder Funktionsaufrufe fest. |
| `cpu_tuple_cost` | Dynamisch | Legt die Schätzung des Planers für die Kosten der Verarbeitung der einzelnen Tupeln (Zeilen) fest. |
| `cursor_tuple_fraction` | Dynamisch | Legt die Schätzung des Planers für den Bruchteil der Zeilen eines Cursors fest, die abgerufen werden. |
| `datestyle` | Dynamisch | Legt das Anzeigeformat für Datum- und Uhrzeitwerte fest. |
| `deadlock_timeout` | Dynamisch | Legt die Zeit fest, die während einer Sperre gewartet wird, bevor auf einen Deadlock geprüft wird. |
| `debug_pretty_print` | Dynamisch | Erstellt Einschübe für Analyse- und Planstrukturanzeigen. |
| `debug_print_parse` | Dynamisch | Protokolliert die Analysestruktur der einzelnen Abfragen. |
| `debug_print_plan` | Dynamisch | Protokolliert den Ausführungsplan der einzelnen Abfragen. |
| `debug_print_rewritten` | Dynamisch | Protokolliert die neu geschriebene Analysestruktur der einzelnen Abfragen. |
| `default_statistics_target` | Dynamisch | Legt das Standardstatistikziel fest. |
| `default_tablespace` | Dynamisch | Legt den Standardtabellenraum fest, in dem Tabellen und Indexe erstellt werden. |
| `default_transaction_deferrable` | Dynamisch | Legt den Standardaufschiebbarkeitsstatus neuer Transaktionen fest. |
| `default_transaction_isolation` | Dynamisch | Legt die Transaktionsisolierungsstufe jeder neuen Transaktion fest. |
| `default_transaction_read_only` | Dynamisch | Legt den Standardschreibschutzstatus neuer Transaktionen fest. |
| `default_with_oids` | Dynamisch | Erstellt standardmäßig neue Tabellen mit object IDs (OIDs). |
| `effective_cache_size` | Dynamisch | Legt die Annahme des Planers hinsichtlich der Größe des Datenträger-Caches fest. |
| `effective_io_concurrency` | Dynamisch | Die Anzahl der gleichzeitigen Anfragen, die durch das Datenträgersubsystem effizient bearbeitet werden können. |
| `enable_bitmapscan` | Dynamisch | Ermöglicht die Verwendung von Bitmap-Prüfungsplänen durch den Planer. |
| `enable_hashagg` | Dynamisch | Ermöglicht die Verwendung von Hash-Aggregationsplänen durch den Planer. |
| `enable_hashjoin` | Dynamisch | Ermöglicht die Verwendung von Hash-Join-Plänen durch den Planer. |
| `enable_indexscan` | Dynamisch | Ermöglicht die Verwendung von Indexprüfungsplänen durch den Planer. |
| `enable_material` | Dynamisch | Ermöglicht die Verwendung von Materialisierung durch den Planer. |
| `enable_mergejoin` | Dynamisch | Ermöglicht die Verwendung von Zusammenführungs-Join-Plänen durch den Planer. |
| `enable_nestloop` | Dynamisch | Ermöglicht die Verwendung von Join-Plänen mit verschachtelten Schleifen durch den Planer. |
| `enable_seqscan` | Dynamisch | Ermöglicht die Verwendung von sequenziellen Prüfungsplänen durch den Planer. |
| `enable_sort` | Dynamisch | Ermöglicht die Verwendung von expliziten Sortierschritten durch den Planer. |
| `enable_tidscan` | Dynamisch | Ermöglicht die Verwendung von TID-Prüfungsplänen durch den Planer. |
| `escape_string_warning` | Dynamisch | Gibt Warnungen zu Escape-Notierungen mit Backslash (\$1) in gewöhnlichen Zeichenfolgeliteralen aus. |
| `extra_float_digits` | Dynamisch | Legt die Anzahl der Stellen fest, die für Gleitkommawerte angezeigt werden. |
| `from_collapse_limit` | Dynamisch | Legt die Größe der FROM-Liste fest, jenseits der Unterabfragen nicht ausgeblendet werden. |
| `fsync` | Dynamisch | Erzwingt die Synchronisierung von Aktualisierungen zum Datenträger. |
| `full_page_writes` | Dynamisch | Schreibt bei der ersten Änderung nach einem Prüfpunkt vollständige Seiten zu WAL. |
| `geqo` | Dynamisch | Ermöglicht die genetische Abfrageoptimierung. |
| `geqo_effort` | Dynamisch | GEQO: Der Aufwand, der verwendet wird, um den Standard für andere GEQO-Parameter festzulegen. |
| `geqo_generations` | Dynamisch | GEQO: Die Zahl der Iterationen des Algorithmus. |
| `geqo_pool_size` | Dynamisch | GEQO: Die Anzahl der Personen in der Population. |
| `geqo_seed` | Dynamisch | GEQO: Der Seed für die zufällige Pfadauswahl. |
| `geqo_selection_bias` | Dynamisch | GEQO: Selektiver Druck innerhalb der Population. |
| `geqo_threshold` | Dynamisch | Legt den Schwellenwert für FROM-Elemente fest, jenseits derer GEQO verwendet wird. |
| `gin_fuzzy_search_limit` | Dynamisch | Legt das maximal zulässige Ergebnis für die exakte Suche durch GIN fest. |
| `hot_standby_feedback` | Dynamisch | Legt fest, ob ein Hot Standby Rückmeldungen an den primären oder Upstream Standby sendet. |
| `intervalstyle` | Dynamisch | Legt das Anzeigeformat für Intervallwerte fest. |
| `join_collapse_limit` | Dynamisch | Legt die Größe der FROM-Liste fest, jenseits der JOIN-Konstrukte nicht auf eine Ebene gebracht werden. |
| `lc_messages` | Dynamisch | Legt die Sprache fest, in der Nachrichten angezeigt werden. |
| `lc_monetary` | Dynamisch | Legt das Gebietsschema für die Formatierung von monetären Beträgen fest. |
| `lc_numeric` | Dynamisch | Legt das Gebietsschema für die Formatierung von Zahlen fest. |
| `lc_time` | Dynamisch | Legt das Gebietsschema für die Formatierung von Datum- und Uhrzeitwerten fest. |
| `log_autovacuum_min_duration` | Dynamisch | Legt die Mindestausführungszeit fest, ab der Aktionen für die Selbstbereinigung protokolliert werden. |
| `log_checkpoints` | Dynamisch | Protokolliert jeden Prüfpunkt. |
| `log_connections` | Dynamisch | Protokolliert jede erfolgreiche Verbindung. |
| `log_disconnections` | Dynamisch | Protokolliert das Ende einer Sitzung einschließlich der Dauer. |
| `log_duration` | Dynamisch | Protokolliert die Dauer jeder abgeschlossenen SQL-Anweisung. |
| `log_error_verbosity` | Dynamisch | Legt die Ausführlichkeit protokollierter Nachrichten fest. |
| `log_executor_stats` | Dynamisch | Schreibt die Leistungsstatistik des Executors in das Serverprotokoll. |
| `log_filename` | Dynamisch | Legt das Dateinamenmuster für Protokolldateien fest. |
| `log_file_mode` | Dynamisch | Legt Dateiberechtigungen für Protokolldateien fest. Der Standardwert ist 0644. |
| `log_hostname` | Dynamisch | Protokolliert den Hostnamen in den Verbindungsprotokollen. Ab PostgreSQL 12 und späteren Versionen ist dieser Parameter standardmäßig „off“. Wenn diese Option aktiviert ist, verwendet die Verbindung DNS-Reverse-Lookup, um den Hostnamen abzurufen, der in den Verbindungsprotokollen erfasst wird. Wenn Sie diesen Parameter aktivieren, sollten Sie überwachen, welche Auswirkungen er auf die Zeit hat, die für den Verbindungsaufbau benötigt wird. |
| `log_line_prefix ` | Dynamisch | Steuert Informationen, die jeder Protokollzeile vorangestellt sind. |
| `log_lock_waits` | Dynamisch | Protokolliert lange Sperrenwartezeiten. |
| `log_min_duration_statement` | Dynamisch | Legt die Mindestausführungszeit fest, ab der Anweisungen protokolliert werden. |
| `log_min_error_statement` | Dynamisch | Veranlasst, dass alle Anweisungen, die einen Fehler auf oder jenseits dieser Stufe generieren, protokolliert werden. |
| `log_min_messages` | Dynamisch | Legt die Nachrichtenebenen fest, die protokolliert werden. |
| `log_parser_stats` | Dynamisch | Schreibt die Leistungsstatistik des Parsers in das Serverprotokoll. |
| `log_planner_stats` | Dynamisch | Schreibt die Leistungsstatistik des Planers in das Serverprotokoll. |
| `log_rotation_age` | Dynamisch | Die automatische Protokolldateirotation wird nach N Minuten ausgeführt. |
| `log_rotation_size` | Dynamisch | Die automatische Protokolldateirotation wird nach N Kilobytes ausgeführt. |
| `log_statement` | Dynamisch | Legt den Typ der protokollierten Anweisungen fest. |
| `log_statement_stats` | Dynamisch | Schreibt kumulative Leistungsstatistiken in das Serverprotokoll. |
| `log_temp_files` | Dynamisch | Protokolliert die Verwendung temporärer Dateien, die größer als diese Zahl von Kilobytes sind. |
| `log_timezone` | Dynamisch | Legt die Zeitzone fest, die in Protokollmeldungen verwendet werden soll. |
| `log_truncate_on_rotation` | Dynamisch | Kürzt vorhandene Protokolldateien mit demselben Namen während der Protokollrotation. |
| `logging_collector` | Statisch | Startet einen Unterprozess, um die and/or CSVLogs der STDERR-Ausgabe in Protokolldateien zu erfassen. |
| `maintenance_work_mem` | Dynamisch | Legt den maximalen Arbeitsspeicher fest, der für Wartungsoperationen verwendet werden darf. |
| `max_connections` | Statisch | Legt die maximale Anzahl gleichzeitiger Verbindungen fest. |
| `max_files_per_process` | Statisch | Legt die maximale Anzahl gleichzeitig geöffneter Dateien für die einzelnen Serverprozesse fest. |
| `max_locks_per_transaction` | Statisch | Legt die maximale Anzahl von Sperren pro Transaktion fest. |
| `max_pred_locks_per_transaction` | Statisch | Legt die maximale Anzahl von Prädikatssperren pro Transaktion fest. |
| `max_prepared_transactions` | Statisch | Legt die maximale Anzahl gleichzeitig vorbereiteter Transaktionen fest. |
| `max_stack_depth` | Dynamisch | Legt die maximale Stack-Tiefe in Kilobytes fest. |
| `max_standby_archive_delay` | Dynamisch | Legt die maximale Verzögerung fest, bevor Abfragen storniert werden, wenn ein Hot-Standby-Server archivierte WAL-Daten verarbeitet. |
| `max_standby_streaming_delay` | Dynamisch | Legt die maximale Verzögerung fest, bevor Abfragen storniert werden, wenn ein Hot-Standby-Server gestreamte WAL-Daten verarbeitet. |
| max\$1wal\$1size | Dynamisch | Legt die WAL-Größe (MB) fest, die den Prüfpunkt auslöst. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.Parameters.html) Verwenden Sie den folgenden Befehl auf der DB-Instance von RDS für PostgreSQL, um den aktuellen Wert zu sehen. SHOW max_wal_size;
|
| min\$1wal\$1size | Dynamisch | Legt die Mindestgröße fest, auf die das WAL verkleinert werden soll. Für PostgreSQL-Version 9.6 und früher liegt min\$1wal\$1size in Einheiten von 16 MB vor. Für PostgreSQ-Version 10 und höher liegt min\$1wal\$1size in Einheiten von 1 MB vor. |
| `quote_all_identifiers` | Dynamisch | Fügt beim Generieren von SQL-Fragmenten allen Bezeichnern Anführungszeichen (") hinzu. |
| `random_page_cost` | Dynamisch | Legt die Schätzung des Planers für die Kosten einer nicht sequenziell abgerufenen Datenträgerseite fest. Dieser Parameter hat keinen Wert, es sei denn, die Abfrageplanverwaltung (QPM) ist aktiviert. Wenn QPM aktiviert ist, lautet der Standardwert für diesen Parameter 4. |
| rds.adaptive\$1autovacuum | Dynamisch | Optimiert die Selbstbereinigungsparameter automatisch, wenn die Transaktions-ID-Schwellenwerte überschritten werden. |
| rds.force\$1ssl | Dynamisch | Erfordert die Verwendung von SSL-Verbindungen. Der Standardwert ist für RDS für PostgreSQL Version 15 auf 1 (ein) festgelegt. Bei allen anderen Hauptversionen von RDS für PostgreSQL bis 14 ist der Standardwert auf 0 (aus) festgelegt. |
| `rds.local_volume_spill_enabled` | Statisch | Ermöglicht das Schreiben logischer Spill-Dateien auf das lokale Volume. |
| `rds.log_retention_period` | Dynamisch | Legt die Protokollaufbewahrung so fest, dass Amazon RDS PostgreSQL-Protokolle löscht, die älter als n Minuten sind. |
| rds.rds\$1superuser\$1reserved\$1connections | Statisch | Legt die Anzahl der Verbindungs-Slots fest, die für rds\$1superusers reserviert sind. Dieser Parameter ist nur für Version 15 und niedriger verfügbar. Weitere Informationen finden Sie in der PostgreSQL-Dokumentation unter [reserved\$1connections](https://www.postgresql.org/docs/current/runtime-config-connection.html#GUC-RESERVED-CONNECTIONS). |
| `rds.replica_identity_full` | Dynamisch | Wenn Sie diesen Parameter auf `on` festlegen, überschreibt er die Einstellung der Replikatidentität für alle Datenbanktabellen auf `FULL`. Das bedeutet, dass alle Spaltenwerte unabhängig von Ihren `REPLICA IDENTITY FULL`-Einstellungen in das Write-Ahead-Protokoll (WAL) geschrieben werden. Das Aktivieren dieses Parameters kann die IOPS Ihrer Datenbank-Instance aufgrund der zusätzlichen WAL-Protokollierung erhöhen. |
| rds.restrict\$1password\$1commands | Statisch | Schränkt ein, wer Passwörter für Benutzer mit der Rolle rds\$1password verwalten darf. Setzen Sie diesen Parameter auf 1, um die Passwortbeschränkung zu aktivieren. Der Standardwert ist 0. |
| `search_path` | Dynamisch | Legt die Schemasuchreihenfolge für Namen fest, die nicht schemaqualifiziert sind. |
| `seq_page_cost` | Dynamisch | Legt die Schätzung des Planers für die Kosten einer sequenziell abgerufenen Datenträgerseite fest. |
| `session_replication_role` | Dynamisch | Legt das Sitzungsverhalten für Auslöser und Neuschreibungsregeln fest. |
| `shared_buffers` | Statisch | Legt die maximale Anzahl freigegebener Arbeitsspeicherpuffer fest, die vom Server verwendet werden. |
| `shared_preload_libraries ` | Statisch | Listet die freigegebenen Bibliotheken auf, die in die DB-Instance von RDS für PostgreSQL vorab geladen werden sollen. Zu den unterstützten Werten gehören: auto\$1explain, orafce, pgaudit, pglogical, pg\$1bigm, pg\$1cron, pg\$1hint\$1plan, pg\$1prewarm, pg\$1similarity, pg\$1stat\$1statements, pg\$1tle, pg\$1transport, plprofiler und plrust. |
| `ssl` | Dynamisch | Ermöglicht SSL-Verbindungen. |
| `sql_inheritance` | Dynamisch | Veranlasst den standardmäßigen Einschluss von Untertabellen in verschiedene Befehle. |
| `ssl_renegotiation_limit` | Dynamisch | Legt die Menge des Datenverkehrs fest, der gesendet und empfangen werden soll, bevor die Verschlüsselungsschlüssel neu verhandelt werden. |
| `standard_conforming_strings` | Dynamisch | Veranlasst Zeichenfolgen „...“, Backslashes als Zeichen zu behandeln. |
| `statement_timeout` | Dynamisch | Legt die maximal zulässige Dauer von Anweisungen fest. |
| `synchronize_seqscans` | Dynamisch | Ermöglicht synchronisierte sequenzielle Prüfungen. |
| `synchronous_commit` | Dynamisch | Legt die Synchronisierungsstufe aktueller Transaktionen fest. |
| `tcp_keepalives_count` | Dynamisch | Maximale Anzahl von TCP-Keepalive-Neuübertragungen. |
| `tcp_keepalives_idle` | Dynamisch | Zeit zwischen der Ausgabe von TCP-Keepalives. |
| `tcp_keepalives_interval` | Dynamisch | Zeit zwischen der Ausgabe von TCP-Keepalive-Neuübertragungen. |
| `temp_buffers` | Dynamisch | Legt die maximale Anzahl der temporären Puffer fest, die von den einzelnen Sitzungen verwendet werden. |
| temp\$1file\$1limit | Dynamisch | Legt die maximale Größe in KB fest, temporären Dateien maximal annehmen können. |
| `temp_tablespaces` | Dynamisch | Legt die Tabellenräume fest, die für temporäre Tabellen und Sortierdateien verwendet werden sollen. |
| `timezone` | Dynamisch | Legt die Zeitzone für die Anzeige und Interpretation von Zeitstempeln fest. Die Internet Assigned Numbers Authority (IANA) veröffentlicht mehrmals im Jahr neue Zeitzonen unter [https://www.iana.org/time-zones](https://www.iana.org/time-zones). Jedes Mal, wenn RDS eine neue Wartungsnebenversion von PostgreSQL veröffentlicht, wird diese mit den neuesten Zeitzonendaten zum Zeitpunkt der Veröffentlichung ausgeliefert. Wenn Sie die neuesten Versionen von RDS für PostgreSQL verwenden, verfügen Sie über aktuelle Zeitzonendaten von RDS. Wenn Sie sichergehen möchten, dass Ihre DB-Instance über aktuelle Zeitzonendaten verfügt, empfehlen wir ein Upgrade auf eine höhere DB-Engine-Version. Sie können die Zeitzonen-Tabellen in PostgreSQL-DB-Instances nicht ändern. Die Zeitzonendaten laufender DB-Instances werden von RDS nicht geändert oder zurückgesetzt. Neue Zeitzonendaten werden nur installiert, wenn Sie ein Upgrade der Datenbank-Engine-Version durchführen. |
| `track_activities` | Dynamisch | Sammelt Informationen zu Befehlen, die ausgeführt werden. |
| `track_activity_query_size` | Statisch | Legt die für pg\$1stat\$1activity.current\$1query reservierte Größe in Bytes fest. |
| `track_counts` | Dynamisch | Sammelt Statistiken zur Datenbankaktivität. |
| `track_functions` | Dynamisch | Sammelt Statistiken auf Funktionsebene zur Datenbankaktivität. |
| `track_io_timing` | Dynamisch | Sammelt Zeitstatistiken zur Datenbankaktivität. I/O |
| `transaction_deferrable` | Dynamisch | Gibt an, ob eine schreibgeschützte serialisierbare Transaktion aufgeschoben werden kann, bis sie ohne mögliche Serialisierungsfehler gestartet werden kann. |
| `transaction_isolation` | Dynamisch | Legt die Isolierungsstufe aktueller Transaktionen fest. |
| `transaction_read_only` | Dynamisch | Legt den Schreibschutzstatus aktueller Transaktionen fest. |
| `transform_null_equals` | Dynamisch | Behandelt expr=NULL als expr IS NULL. |
| `update_process_title` | Dynamisch | Aktualisiert den Titel des Vorgangs, um den aktiven SQL-Befehl anzuzeigen. |
| `vacuum_cost_delay` | Dynamisch | Bereinigungskostenverzögerung (in Millisekunden). |
| `vacuum_cost_limit` | Dynamisch | Bereinigungskostenbetrag, der vor der Inaktivität verfügbar ist. |
| `vacuum_cost_page_dirty` | Dynamisch | Bereinigungskosten für eine Seite, die durch eine Bereinigung ungültig wurde. |
| `vacuum_cost_page_hit` | Dynamisch | Bereinigungskosten für eine Seite, die im Puffer-Cache gefunden wurde. |
| `vacuum_cost_page_miss` | Dynamisch | Bereinigungskosten für eine Seite, die nicht im Puffer-Cache gefunden wurde. |
| `vacuum_defer_cleanup_age` | Dynamisch | Anzahl der Transaktionen, um die Bereinigung und Hot Cleanup aufgeschoben werden sollen, wenn vorhanden. |
| `vacuum_freeze_min_age` | Dynamisch | Mindestalter, bei dem die Bereinigung eine Tabellenzeile eingefroren werden sollte. |
| `vacuum_freeze_table_age` | Dynamisch | Alter, bei dem die Bereinigung eine Tabelle vollständig scannen sollte, um Tupel einzufrieren. |
| `wal_buffers` | Statisch | Legt die Anzahl von Datenträgerseitenpuffern im freigegebenen Arbeitsspeicher für WAL fest. |
| `wal_writer_delay` | Dynamisch | Inaktivitätszeit des WAL-Schreibers zwischen WAL-Flushes. |
| `work_mem` | Dynamisch | Legt den maximalen Arbeitsspeicher fest, der für Abfrage-Workspaces verwendet werden darf. |
| `xmlbinary` | Dynamisch | Legt die Kodierung von Binärwerten in XML fest. |
| `xmloption` | Dynamisch | Legt fest, ob XML-Daten in impliziten Parsing- und Serialisierungsoperationen als Dokumente oder Inhaltsfragmente betrachtet werden sollen. |
Amazon RDS verwendet die PostgreSQL-Standardeinheiten für alle Parameter. Die folgende Tabelle zeigt die PostgreSQL-Standardeinheit für die einzelnen Parameter.
| Parametername | Einheit |
| --- | --- |
| `archive_timeout` | S |
| `authentication_timeout` | S |
| `autovacuum_naptime` | S |
| `autovacuum_vacuum_cost_delay` | ms |
| `bgwriter_delay` | ms |
| `checkpoint_timeout` | S |
| `checkpoint_warning` | S |
| `deadlock_timeout` | ms |
| `effective_cache_size` | 8 KB |
| `lock_timeout` | ms |
| `log_autovacuum_min_duration` | ms |
| `log_min_duration_statement` | ms |
| `log_rotation_age` | Minuten |
| `log_rotation_size` | KB |
| `log_temp_files` | KB |
| `maintenance_work_mem` | KB |
| `max_stack_depth` | KB |
| `max_standby_archive_delay` | ms |
| `max_standby_streaming_delay` | ms |
| `post_auth_delay` | S |
| `pre_auth_delay` | S |
| `segment_size` | 8 KB |
| `shared_buffers` | 8 KB |
| `statement_timeout` | ms |
| `ssl_renegotiation_limit` | KB |
| `tcp_keepalives_idle` | S |
| `tcp_keepalives_interval` | S |
| `temp_file_limit` | KB |
| `work_mem` | KB |
| `temp_buffers` | 8 KB |
| `vacuum_cost_delay` | ms |
| `wal_buffers` | 8 KB |
| `wal_receiver_timeout` | ms |
| `wal_segment_size` | B |
| `wal_sender_timeout` | ms |
| `wal_writer_delay` | ms |
| `wal_receiver_status_interval` | S |