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.
# 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.