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.
# Arbeiten mit der PostgreSQL-Selbstbereinigung in Amazon Aurora 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 Aurora 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 Aurora PostgreSQL optimieren können.
**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 Aurora 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 Aurora 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 Aurora PostgreSQL eine Methode bereit, mit der die Selbstbereinigungsparameter automatisch angepasst werden. Die *adaptive Selbstbereinigung* ist ein Feature für Aurora 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 Aurora 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 Aurora 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.