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. # Manuelles Absaugen und Analysieren von Tabellen Wenn Ihre Datenbank durch den Autovacuum-Prozess gelöscht wird, empfiehlt es sich, zu vermeiden, dass die gesamte Datenbank zu häufig manuell gelöscht wird. Ein manuelles Löschen kann zu unnötigen I/O Lasten oder CPU-Spitzen führen und eventuell auch keine toten Tupel entfernen. Führen Sie ein manuelles Absaugen nur dann table-by-table aus, wenn es wirklich notwendig ist, z. B. wenn das Verhältnis von lebenden zu toten Tupeln gering ist oder wenn zwischen den Autovakuumvorgängen große Lücken bestehen. Darüber hinaus sollten Sie bei minimaler Benutzeraktivität manuelles Staubsaugen ausführen. Autovacuum hält auch die Statistiken einer Tabelle auf dem neuesten Stand. Wenn Sie den `ANALYZE` Befehl manuell ausführen, werden diese Statistiken neu erstellt, anstatt sie zu aktualisieren. Das Neuerstellen von Statistiken, wenn sie bereits durch den regulären Autovacuum-Prozess aktualisiert wurden, kann zu einer Auslastung der Systemressourcen führen. In den folgenden Szenarien wird empfohlen, die Befehle [VACUUM](https://www.postgresql.org/docs/current/sql-vacuum.html) und [ANALYZE](https://www.postgresql.org/docs/current/sql-analyze.html) manuell auszuführen: + Zu schlechten Spitzenzeiten an stark frequentierten Tischen, wenn das automatische Absaugen möglicherweise nicht ausreicht. + Unmittelbar nach dem Massenladen von Daten in die Zieltabelle. In diesem Fall werden die Statistiken bei `ANALYZE` manueller Ausführung vollständig neu erstellt. Dies ist eine bessere Option, als auf den Beginn der automatischen Bereinigung zu warten. + Um temporäre Tabellen zu vakuieren (Autovacuum kann nicht auf diese zugreifen). Um die I/O Auswirkungen der Ausführung der `ANALYZE` Befehle `VACUUM` und auf die gleichzeitige Datenbankaktivität zu verringern, können Sie den `vacuum_cost_delay` Parameter verwenden. In vielen Situationen müssen Wartungsbefehle wie `VACUUM` und `ANALYZE` nicht schnell abgeschlossen werden. Diese Befehle sollten jedoch die Fähigkeit des Systems, andere Datenbankoperationen auszuführen, nicht beeinträchtigen. Um dies zu verhindern, können Sie mithilfe des `vacuum_cost_delay` Parameters kostenabhängige Vakuumverzögerungen aktivieren. Dieser Parameter ist standardmäßig für manuell ausgegebene `VACUUM` Befehle deaktiviert. Um ihn zu aktivieren, setzen Sie ihn auf einen Wert ungleich Null. ## Paralleles Ausführen von Saug- und Säuberungsvorgängen Die `VACUUM` Befehlsoption [PARALLEL](https://www.postgresql.org/docs/current/sql-vacuum.html) verwendet parallele Worker für die Phasen Indexsaugung und Indexbereinigung und ist standardmäßig deaktiviert. Die Anzahl der parallelen Worker (der Grad der Parallelität) wird durch die Anzahl der Indizes in der Tabelle bestimmt und kann vom Benutzer angegeben werden. Wenn Sie parallel `VACUUM` Operationen ohne ein Integer-Argument ausführen, wird der Grad der Parallelität anhand der Anzahl der Indizes in der Tabelle berechnet. Die folgenden Parameter helfen Ihnen bei der Konfiguration von parallelem Vacuuming in Amazon RDS for PostgreSQL und Aurora PostgreSQL-kompatibel: + [max\$1worker\$1processes legt](https://www.postgresql.org/docs/current/runtime-config-resource.html) die maximale Anzahl gleichzeitiger Worker-Prozesse fest. + [min\$1parallel\$1index\$1scan\$1size](https://www.postgresql.org/docs/current/runtime-config-query.html) legt die Mindestmenge an Indexdaten fest, die gescannt werden müssen, damit ein parallel Scan berücksichtigt wird. + [max\$1parallel\$1maintenance\$1workers](https://www.postgresql.org/docs/current/runtime-config-resource.html) legt die maximale Anzahl parallel Worker fest, die mit einem einzigen Utility-Befehl gestartet werden können. **Anmerkung** Die `PARALLEL` Option wird nur für Vakuumzwecke verwendet. Sie hat keinen Einfluss auf den Befehl. `ANALYZE` Das folgende Beispiel veranschaulicht das Datenbankverhalten, wenn Sie manuell `VACUUM` und in `ANALYZE` einer Datenbank verwenden. Hier ist eine Beispieltabelle, in der Autovacuum deaktiviert wurde (nur zur Veranschaulichung; die Deaktivierung des Autovakuums wird nicht empfohlen): ``` create table t1 ( a int, b int, c int ); alter table t1 set (autovacuum_enabled=false); ``` ``` apgl=> \d+ t1 Table "public.t1" Column | Type | Collation | Nullable | Default | Storage | Stats target | Description --------+---------+-----------+----------+---------+---------+--------------+------------- a | integer | | | | plain | | b | integer | | | | plain | | c | integer | | | | plain | | Access method: heap Options: autovacuum_enabled=false ``` Fügen Sie der Tabelle t1 1 Million Zeilen hinzu: ``` apgl=> select count(*) from t1; count 1000000 (1 row) ``` Statistik der Tabelle t1: ``` select * from pg_stat_all_tables where relname='t1'; -[ RECORD 1 ]-------+-------- relid | 914744 schemaname | public relname | t1 seq_scan | 0 seq_tup_read | 0 idx_scan | idx_tup_fetch | n_tup_ins | 1000000 n_tup_upd | 0 n_tup_del | 0 n_tup_hot_upd | 0 n_live_tup | 1000000 n_dead_tup | 0 n_mod_since_analyze | 1000000 last_vacuum | last_autovacuum | last_analyze | last_autoanalyze | vacuum_count | 0 autovacuum_count | 0 analyze_count | 0 autoanalyze_count | 0 ``` Fügen Sie einen Index hinzu: ``` create index i2 on t1 (b,a); ``` Führen Sie den `EXPLAIN` Befehl aus (Plan 1): ``` Bitmap Heap Scan on t1 (cost=10521.17..14072.67 rows=5000 width=4) Recheck Cond: (a = 5) → Bitmap Index Scan on i2 (cost=0.00..10519.92 rows=5000 width=0) Index Cond: (a = 5) (4 rows) ``` Führen Sie den `EXPLAIN ANALYZE` Befehl aus (Plan 2): ``` explain (analyze,buffers,costs off) select a from t1 where b = 5; QUERY PLAN Bitmap Heap Scan on t1 (actual time=0.023..0.024 rows=1 loops=1) Recheck Cond: (b = 5) Heap Blocks: exact=1 Buffers: shared hit=4 → Bitmap Index Scan on i2 (actual time=0.016..0.016 rows=1 loops=1) Index Cond: (b = 5) Buffers: shared hit=3 Planning Time: 0.054 ms Execution Time: 0.076 ms (9 rows) ``` Die `EXPLAIN ANALYZE ` Befehle `EXPLAIN ` und zeigen unterschiedliche Pläne an, da Autovacuum für die Tabelle deaktiviert war und der `ANALYZE` Befehl nicht manuell ausgeführt wurde. Lassen Sie uns nun einen Wert in der Tabelle aktualisieren und den Plan neu generieren: `EXPLAIN ANALYZE` ``` update t1 set a=8 where b=5; explain (analyze,buffers,costs off) select a from t1 where b = 5; ``` Der `EXPLAIN ANALYZE` Befehl (Plan 3) zeigt jetzt an: ``` apgl=> explain (analyze,buffers,costs off) select a from t1 where b = 5; QUERY PLAN Bitmap Heap Scan on t1 (actual time=0.075..0.076 rows=1 loops=1) Recheck Cond: (b = 5) Heap Blocks: exact=1 Buffers: shared hit=5 → Bitmap Index Scan on i2 (actual time=0.017..0.017 rows=2 loops=1) Index Cond: (b = 5) Buffers: shared hit=3 Planning Time: 0.053 ms Execution Time: 0.125 ms ``` Wenn Sie die Kosten zwischen Plan 2 und Plan 3 vergleichen, werden Sie die Unterschiede in der Planungs- und Ausführungszeit feststellen, da wir noch keine Statistiken gesammelt haben. Lassen Sie uns nun ein Handbuch `ANALYZE` für die Tabelle ausführen, dann die Statistiken überprüfen und den Plan neu generieren: ``` apgl=> analyze t1 apgl→ ; ANALYZE Time: 212.223 ms apgl=> select * from pg_stat_all_tables where relname='t1'; -[ RECORD 1 ]-------+------------------------------ relid | 914744 schemaname | public relname | t1 seq_scan | 3 seq_tup_read | 1000000 idx_scan | 3 idx_tup_fetch | 3 n_tup_ins | 1000000 n_tup_upd | 1 n_tup_del | 0 n_tup_hot_upd | 0 n_live_tup | 1000000 n_dead_tup | 1 n_mod_since_analyze | 0 last_vacuum | last_autovacuum | last_analyze | 2023-04-15 11:39:02.075089+00 last_autoanalyze | vacuum_count | 0 autovacuum_count | 0 analyze_count | 1 autoanalyze_count | 0 Time: 148.347 ms ``` Führen Sie den `EXPLAIN ANALYZE` Befehl aus (Plan 4): ``` apgl=> explain (analyze,buffers,costs off) select a from t1 where b = 5; QUERY PLAN Index Only Scan using i2 on t1 (actual time=0.022..0.023 rows=1 loops=1) Index Cond: (b = 5) Heap Fetches: 1 Buffers: shared hit=4 Planning Time: 0.056 ms Execution Time: 0.068 ms (6 rows) Time: 138.462 ms ``` Wenn Sie alle Planergebnisse vergleichen, nachdem Sie die Tabelle manuell analysiert und Statistiken gesammelt haben, werden Sie feststellen, dass Plan 4 des Optimierers besser ist als die anderen und auch die Ausführungszeit der Abfrage verkürzt. Dieses Beispiel zeigt, wie wichtig es ist, Wartungsaktivitäten in der Datenbank auszuführen. ## Eine ganze Tabelle mit VACUUM FULL neu schreiben Wenn `VACUUM ` Sie den Befehl mit dem `FULL` Parameter ausführen, wird der gesamte Inhalt einer Tabelle in eine neue Festplattendatei ohne zusätzlichen Speicherplatz umgeschrieben und ungenutzter Speicherplatz an das Betriebssystem zurückgegeben. Dieser Vorgang ist viel langsamer und erfordert eine `ACCESS EXCLUSIVE` Sperre für jede Tabelle. Außerdem benötigt er zusätzlichen Speicherplatz, da er eine neue Kopie der Tabelle schreibt und die alte Kopie erst freigibt, wenn der Vorgang abgeschlossen ist. `VACUUM FULL`kann in den folgenden Fällen nützlich sein:**** + Wenn Sie eine beträchtliche Menge an Speicherplatz aus den Tabellen zurückgewinnen möchten. + Wenn Sie in Tabellen, bei denen es sich nicht um Primärschlüsseltabellen handelt, aufgeblähten Speicherplatz zurückgewinnen möchten. Wir empfehlen die Verwendung, `VACUUM FULL` wenn Sie Tabellen haben, die keine Primärschlüsseltabellen haben, wenn Ihre Datenbank Ausfallzeiten tolerieren kann. Da mehr Sperren `VACUUM FULL` erforderlich sind als bei anderen Vorgängen, ist die Ausführung in wichtigen Datenbanken teurer. Um diese Methode zu ersetzen, können Sie die `pg_repack ` Erweiterung verwenden, die im [nächsten Abschnitt](pg-repack.md) beschrieben wird. Diese Option ähnelt der Option, erfordert `VACUUM FULL` jedoch nur minimale Sperren und wird sowohl von Amazon RDS for PostgreSQL als auch von Aurora PostgreSQL-Compatible unterstützt.