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.
# Zurückgewinnen von Speicherplatz durch Bereinigung
PostgreSQL Multiversion Concurrency Control (MVCC) trägt zur Wahrung der Datenintegrität bei, indem es eine interne Kopie aktualisierter oder gelöschter Zeilen speichert, bis eine Transaktion entweder festgeschrieben oder zurückgesetzt wird. Diese Kopien, auch *Tupel* genannt, können zu einer Überlastung der Tabelle führen, wenn sie nicht regelmäßig bereinigt werden. PostgreSQL-Instances ordnen Transaktionen nach ihren Transaktions-IDs, und PostgreSQL verwendet MVCC, das auf Transaktions-IDs basiert, um die Sichtbarkeit von Tupeln zu kontrollieren und die Transaktionsisolierung zu gewährleisten. Jede Transaktion erstellt einen Daten-Snapshot, und jedes Tupel hat eine Version. Sowohl der Snapshot als auch die Version basieren auf der Transaktions-ID.
Um Daten zu bereinigen, führt das Dienstprogramm `VACUUM` vier wichtige Funktionen in PostgreSQL aus:
+ `VACUUM` – Entfernt abgelaufene Zeilenversionen, wodurch Speicherplatz für die Wiederverwendung verfügbar wird.
+ `VACUUM FULL` – Ermöglicht eine vollständige Defragmentierung, indem veraltete Versionen entfernt und die Tabellen komprimiert werden, wodurch die Größe reduziert und die Effizienz gesteigert wird.
+ `VACUUM FREEZE` – Schützt vor Wraparound-Problemen bei Transaktions-IDs, indem ältere Zeilenversionen als gesperrt markiert werden.
+ `VACUUM ANALYZE` – Entfernt veraltete Zeilenversionen und aktualisiert die Abfrageplanungsstatistiken der Datenbank. Es ist eine Kombination aus `VACUUM`- und `ANALYZE`-Funktionen. Weitere Informationen zur Funktionsweise von `ANALYZE` in Aurora PostgreSQL Limitless Database finden Sie unter [ANALYZE](limitless-reference.DML-limitations.md#limitless-reference.DML-limitations.ANALYZE).
Wie bei MVCC basiert die Bereinigung in Aurora PostgreSQL auf der Transaktions-ID. Wenn zu Beginn der Bereinigung eine Transaktion läuft, werden Zeilen, die für diese Transaktion noch sichtbar sind, nicht entfernt.
Weitere Informationen zum Dienstprogramm `VACUUM` finden Sie unter [VACUUM](https://www.postgresql.org/docs/current/sql-vacuum.html) in der PostgreSQL-Dokumentation. Weitere Informationen zur Unterstützung von `VACUUM` in Aurora PostgreSQL Limitless Database finden Sie unter [VACUUM](limitless-reference.DML-limitations.md#limitless-reference.DML-limitations.VACUUM).
**Topics**
+ [AUTOVACUUM](#limitless-autovacuum)
+ [Time-based Staubsaugen in der Aurora PostgreSQL Limitless Database](#limitless-vacuum.time-based)
+ [Verwenden von Datenbankstatistiken für die Bereinigung](#limitless-vacuum.stats)
+ [Unterschiede im Bereinigungsverhalten zwischen Aurora PostgreSQL und Aurora PostgreSQL Limitless Database](#limitless-vacuum-limitations)
## AUTOVACUUM
Aurora PostgreSQL verwendet die Dienstprogramme `VACUUM` und `AUTOVACUUM`, um nicht benötigte Tupel zu entfernen. Der zugrundeliegende Mechanismus für `AUTOVACUUM` und manuelles `VACUUM` ist derselbe, der einzige Unterschied besteht in der Automatisierung.
`AUTOVACUUM` in Aurora PostgreSQL und Aurora PostgreSQL Limitless Database ist eine Kombination der Dienstprogramme `VACUUM` und `ANALYZE`. `AUTOVACUUM` legt gemäß einer vordefinierten Regel fest, welche Datenbanken und Tabellen bereinigt werden sollen, z. B. anhand des Prozentsatzes inaktiver Tupel und der Anzahl der Einfügungen.
`AUTOVACUUM` wird beispielsweise regelmäßig aktiviert, um eine Bereinigung durchzuführen. Das Intervall wird durch den Parameter `autovacuum_naptime` gesteuert. Der Standardwert beträgt 1 Minute. Die Standardwerte für die Konfigurationsparameter `AUTOVACUUM` und `VACUUM` sind für Aurora PostgreSQL Limitless Database dieselben wie für Aurora PostgreSQL.
Wenn der Daemon für `AUTOVACUUM` aktiviert ist, gibt er automatisch `ANALYZE`-Befehle aus, wenn sich der Inhalt einer Tabelle ausreichend geändert hat. In Aurora PostgreSQL Limitless Database gibt `AUTOVACUUM` `ANALYZE` auf Routern und auf Shards aus.
Weitere Informationen zum Daemon für `AUTOVACUUM` und zu den mit `AUTOVACUUM` verbundenen Tabellenspeicherparametern finden Sie unter [Der Bereinigungsdaemon](https://www.postgresql.org/docs/current/routine-vacuuming.html#AUTOVACUUM ) und die [Speicherparameter](https://www.postgresql.org/docs/current/runtime-config-autovacuum.html) in der PostgreSQL-Dokumentation.
## Time-based Staubsaugen in der Aurora PostgreSQL Limitless Database
Aurora PostgreSQL Limitless Database ist ein verteiltes System, was bedeutet, dass mehrere Instances an einer Transaktion beteiligt sein können. Daher gilt die auf der Transaktions-ID basierende Transparenz nicht. Stattdessen verwendet Aurora PostgreSQL Limitless Database *zeitbasierte* Sichtbarkeit, da Transaktions-IDs nicht Instance-übergreifend „vereinheitlicht“ werden, die Zeit hingegen schon. Jeder Transaktions-Snapshot und jede Tupel-Version folgen der Zeit und nicht der Transaktions-ID. Genauer gesagt hat ein Transaktions-Snapshot eine Snapshot-Startzeit, und ein Tupel hat eine Erstellungszeit (bei einem `INSERT`- oder `UPDATE`-Vorgang) und eine Löschzeit (bei einem `DELETE`-Vorgang).
Um die Datenkonsistenz zwischen den Instances in der DB-Shard-Gruppe aufrechtzuerhalten, muss Aurora PostgreSQL Limitless Database sicherstellen, dass beim Bereinigen keine Tupel entfernt werden, die für aktive Transaktionen in der DB-Shard-Gruppe noch sichtbar sind. Daher ist die Bereinigung in Aurora PostgreSQL Limitless Database auch zeitbasiert. Andere Aspekte von `VACUUM` bleiben gleich, einschließlich der Tatsache, dass ein Benutzer Zugriff auf diese Tabelle haben muss, um `VACUUM` auf einer bestimmten Tabelle auszuführen.
**Anmerkung**
Es wird dringend davon abgeraten, Transaktionen für längere Zeit offen zu lassen.
Time-based Das Staubsaugen verbraucht mehr Speicher als das auf Transaktions-IDs basierende Staubsaugen.
Das folgende Beispiel veranschaulicht die Funktionsweise von zeitbasierter Bereinigung.
1. Eine Kundentabelle ist auf vier Shards verteilt.
1. Transaktion 1 beginnt mit einem wiederholbaren Lesevorgang und zielt nur auf einen Shard (Shard 1) ab. Diese Transaktion bleibt offen.
Transaktion 1 ist älter als jede andere Transaktion, die danach gestartet wurde.
1. Transaktion 2 beginnt später, löscht alle Tupel aus einer Tabelle und wird anschließend festgeschrieben.
1. Wenn `AUTOVACUUM` oder manuelles `VACUUM` versucht, inaktive Tupel zu bereinigen (die aufgrund von Transaktion 2 inaktiv sind), wird nichts entfernt.
Dies gilt nicht nur für Shard 1, sondern auch für die Shards 2 bis 4, da Transaktion 1 möglicherweise immer noch auf diese Tupel zugreifen muss. Sie sind aufgrund von MVCC immer noch für Transaktion 1 sichtbar.
Der letzte Schritt wird durch Synchronisierung erreicht, sodass alle Shards über Transaktion 1 informiert sind, auch wenn Transaktion 1 nicht alle Shards betrifft.
## Verwenden von Datenbankstatistiken für die Bereinigung
Um Informationen über Tupel zu erhalten, die Sie möglicherweise bereinigen müssen, verwenden Sie die Ansicht [limitless\_stat\_all\_tables](limitless-monitoring-views.md#limitless_stat_all_tables), die ähnlich wie [pg\_stat\_all\_tables](https://www.postgresql.org/docs/current/monitoring-stats.html#MONITORING-PG-STAT-ALL-TABLES-VIEW) funktioniert. Im folgenden Beispiel wird die Ansicht abgefragt.
```
SELECT * FROM rds_aurora.limitless_stat_all_tables WHERE relname LIKE '%customer%';
```
Entsprechend verwenden Sie für Datenbankstatistiken [limitless\_stat\_database](limitless-monitoring-views.md#limitless_stat_database) anstelle von [pg\_stat\_database](https://www.postgresql.org/docs/current/monitoring-stats.html#MONITORING-PG-STAT-DATABASE-VIEW) und [limitless\_stat\_activity](limitless-monitoring-views.md#limitless_stat_activity) anstelle von [pg\_stat\_activity](https://www.postgresql.org/docs/current/monitoring-stats.html#MONITORING-PG-STAT-ACTIVITY-VIEW).
Um die Festplattennutzung zu überprüfen, verwenden Sie die Funktion [limitless\_stat\_relation\_sizes](limitless-monitoring-functions.md#limitless_stat_relation_sizes), die ähnlich wie [pg\_relation\_size](https://www.postgresql.org/docs/current/functions-admin.html#FUNCTIONS-ADMIN-DBOBJECT) funktioniert. Im folgenden Beispiel wird die Funktion abgefragt.
```
SELECT * FROM rds_aurora.limitless_stat_relation_sizes('public','customer');
```
Um den Fortschritt eines `VACUUM`-Vorgangs in der Aurora PostgreSQL Limitless Database zu verfolgen, verwenden Sie die Ansicht [limitless\_stat\_progress\_vacuum](limitless-monitoring-views.md#limitless_stat_progress_vacuum) anstelle von [pg\_stat\_progress\_vacuum](https://www.postgresql.org/docs/15/progress-reporting.html#VACUUM-PROGRESS-REPORTING). Im folgenden Beispiel wird die Ansicht abgefragt.
```
SELECT * FROM rds_aurora.limitless_stat_progress_vacuum;
```
Weitere Informationen erhalten Sie unter [Ansichten für Aurora PostgreSQL Limitless Database](limitless-monitoring-views.md) und [Funktionen für Aurora PostgreSQL Limitless Database](limitless-monitoring-functions.md).
## Unterschiede im Bereinigungsverhalten zwischen Aurora PostgreSQL und Aurora PostgreSQL Limitless Database
Einige weitere Unterschiede zwischen Aurora PostgreSQL und Aurora PostgreSQL Limitless Database in Bezug auf die Funktionsweise der Bereinigung sind die folgenden:
+ Aurora PostgreSQL führt `VACUUM`-Vorgänge mit Transaktions-IDs bis zur ältesten laufenden Transaktion durch. Wenn in der Datenbank keine laufende Transaktion vorhanden ist, führt `VACUUM` den Vorgang bis zur letzten Transaktion ausgeführt.
+ Aurora PostgreSQL Limitless Database synchronisiert den ältesten Zeit-Snapshot alle 10 Sekunden. Daher wird `VACUUM` den Vorgang möglicherweise nicht für Transaktionen durch, die innerhalb der letzten 10 Sekunden ausgeführt wurden.
Weitere Informationen zur Unterstützung für `VACUUM` in Aurora PostgreSQL Limitless Database finden Sie unter [VACUUM](limitless-reference.DML-limitations.md#limitless-reference.DML-limitations.VACUUM) in der [Referenz zu Aurora PostgreSQL Limitless DatabaseReferenz zu Limitless Database](limitless-reference.md).