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