Wie behebe ich Probleme mit VACUUM in Amazon Redshift?

Kurzbeschreibung

VACUUM ist ein ressourcenintensiver Vorgang, der sich verlangsamen kann, weil Folgendes auftritt:

• Ein hoher Prozentsatz unsortierter Daten
• Eine große Tabelle mit zu vielen Spalten
• Die Verwendung eines verschachtelten Sortierschlüssels
• Unregelmäßige oder seltene Verwendung von VACUUM
• Gleichzeitige Tabellen, Cluster-Abfragen, Data Definition Language (DDL)-Anweisungen oder ETL-Aufträge (Extrahieren, Transformieren, Laden)

Verwende die Abfrage svv_vacuum_progress, um den Status und die Details deines VACUUM-Vorgangs zu überprüfen.

Lösung

Fehlerbehebung bei der VACUUM-Leistung

Hinweis: Das Folgende gilt für bereitgestellte Amazon Redshift-Cluster. Die folgenden Systemtabellen und Abfragen funktionieren auf Amazon Redshift Serverless nicht.

Um zu überprüfen, ob der VACUUM-Vorgang ausgeführt wird, führe die folgende SVV_VACUUM_PROGRESS-Abfrage aus:

dev=# SELECT * FROM svv_vacuum_progress;
table_name |          status                 | time_remaining_estimate
-----------+---------------------------------+-------------------------
data8     |  Vacuum: initialize merge data8 | 4m 55s
(1 row)

Die Abfrage SVV_VACUUM_PROGRESS enthält auch den Namen der Tabelle, den Status des VACUUM-Vorgangs und die geschätzte verbleibende Zeit bis zum Abschluss. Wenn VACUUM nicht ausgeführt wird, zeigt die Abfrage SVV_VACUUM_PROGRESS den Status des zuletzt ausgeführten VACUUM-Vorgangs an. Die Abfrage SVV_VACUUM_PROGRESS gibt nur eine Zeile mit Ergebnissen zurück.

Um die Details der Tabelle zu überprüfen, für die VACUUM ausgeführt wird, führe die folgende Abfrage aus:

SELECT schema, table_id, "table", diststyle, sortkey1, sortkey_num, unsorted, tbl_rows, estimated_visible_rows, stats_off  
FROM svv_table_info  
WHERE "table" IN ('data8');

Hinweis: Ersetze table durch deinen Tabellennamen und data8 durch deinen Schemanamen.

Beispielausgabe:

Schema     | table_id | table | diststyle | sortkey1 | sortkey_num | unsorted | tbl_rows  | est_visible_rows | stats_off  
------------+----------+-------+-----------+----------+-------------+----------+-----------+------------------+-----------
testschema | 977719   | data8 | EVEN      | order_id |  2          |    25.00 | 755171520 | 566378624        | 100.00

In der vorherigen Ausgabe zeigt die Spalte sortkey1 den Hauptsortierschlüssel an.

Wenn die Spalte sortkey1 INTERLEAVED anzeigt, verfügt die Tabelle über einen verschachtelten Sortierschlüssel.

Die Spalte sortkey_num zeigt die Anzahl der Spalten im Sortierschlüssel an.

Die Spalte „unsorted“ (nicht sortiert) zeigt den Prozentsatz der Zeilen an, die sortiert werden müssen.

Die Spalte tbl_rows zeigt die Gesamtzahl der Zeilen an, einschließlich der gelöschten und aktualisierten Zeilen.

estimated_visible_rows ist die Anzahl der Zeilen abzüglich der gelöschten Zeilen.

Nach einem vollständigen VACUUM (Löschen und Sortieren) ähneln sich die Werte für tbl_rows und estimated_visible_rows, und der Wert für „unsorted“ (nicht sortiert) erreicht 0.

Hinweis: Die Daten in der Tabelle werden in Echtzeit aktualisiert. Um den Fortschritt von VACUUM zu überprüfen, führe die Abfrage weiterhin aus. Die unsortierten Zeilen nehmen mit fortschreitendem VACUUM schrittweise ab. Um zu überprüfen, ob du einen hohen Prozentsatz nicht sortierter Daten hast, prüfe die VACUUM-Informationen für eine bestimmte Tabelle.

Führe die folgende Abfrage aus, um die VACUUM-Informationen für eine Tabelle zu überprüfen.

SELECT table_id, status, rows, sortedrows, blocks, eventtime
FROM stl_vacuum
WHERE table_id=977719
ORDER BY eventtime DESC LIMIT 20;

Hinweis: Ersetze 97771 durch die Tabellen-ID aus der vorherigen Abfrage.

Beispielausgabe:

table_id |             status             |    rows    | sortedrows | blocks |         eventtime
         ----------+--------------------------------+------------+------------+--------+----------------------------
  977719 | [VacuumBG] Finished            |  566378640 |          0 |  23618 | 2020-05-27 06:55:33.232536
  977719 | [VacuumBG] Started Delete Only | 1132757280 |  566378640 |  47164 | 2020-05-27 06:55:18.906008
  977719 | Finished                       |  566378640 |  566378640 |  23654 | 2020-05-27 06:46:04.086842
  977719 | Started                        | 1132757280 |  566378640 |  45642 | 2020-05-27 06:28:17.128345
(4 rows)

Im vorherigen Beispiel listet die Ausgabe in sortierter Reihenfolge zuerst die neuesten und dann die älteren Ereignisse auf:

Das letzte VACUUM war ein automatisches VACUUM DELETE, das am 27.05.2020 um 06:55:18.906008 UTC gestartet und in wenigen Sekunden abgeschlossen wurde.

Dieses VACUUM gab den Speicherplatz frei, der von gelöschten Zeilen belegt wurde. Du kannst die Änderungen an der Anzahl der Blöcke vergleichen, die die Tabelle seit Beginn und Abschluss von VACUUM belegt hat.

Hinweis: Amazon Redshift führt im Hintergrund automatisch VACUUM SORT- und VACUUM DELETE-Vorgänge für Tabellen aus. Diese Hintergrund-VACUUMs werden in Zeiten geringerer Auslastung ausgeführt und in Zeiten hoher Auslastung angehalten. Dieses automatische VACUUM reduziert die Notwendigkeit, den Befehl VACUUM auszuführen.

Die Spalte sortedrows zeigt die Anzahl der sortierten Zeilen in der Tabelle an. Beim letzten VACUUM wurde keine Sortierung durchgeführt, da es sich um einen automatischen VACUUM DELETE-Vorgang handelte. Da die aktiven Zeilen nicht sortiert wurden, weist die zum Löschen markierte Zeile dieselbe Anzahl sortierter Zeilen auf wie beim Start von VACUUM. Nach Abschluss von VACUUM DELETE siehst du 0 sortierte Zeilen.

Das erste VACUUM, das am 27.05.2020 um 06:28:17.128345 UTC gestartet wurde, zeigt ein vollständiges VACUUM an. Der Prozess hat den Speicherplatz von gelöschten Zeilen freigegeben und Zeilen nach etwa 18 Minuten sortiert. Nach Abschluss des VACUUM-Vorgangs zeigt die Ausgabe die gleichen Werte für die Spalten rows und sortedrows an, da VACUUM die Zeilen erfolgreich sortiert hat.

Überwache bei einem bereits ausgeführten VACUUM weiterhin dessen Leistung und integriere bewährte Methoden.

Fehlerbehebung bei VACUUM-Fehlern

Hinweis: Wenn du beim Ausführen von Befehlen der AWS Command Line Interface (AWS CLI) Fehler erhältst, lies Beheben von Fehlern für den AWS CLI. Stelle außerdem sicher, dass du die neueste Version der AWS CLI verwendest.

Um herauszufinden, warum eine VACUUM-Abfrage fehlgeschlagen ist, verwende entweder SYS_QUERY_HISTORY oder STL_QUERY, um nach Fehlermeldungen zu suchen. Wenn du STL_QUERY verwendest, musst du die Fehlerdetails aus STL_ERROR abrufen. Da STL_ERROR keine Spalte für die Abfrage-ID hat, suche das PID-Feld in STL_QUERY. Verwende dieses Feld dann in der STL_ERROR-Abfrage.

Beispiel SYS_QUERY_HISTORY:

SELECT user_id, query_id, transaction_id, session_id,  status, start_time, end_time, execution_time, error_message FROM sys_query_history WHERE query_id IN (<failed queries>)


+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

| user_id | query_id   | transaction_id |  session_id | status | start_time              |     end_time                  |  execution_time |   error_message |   
| 100        | 915082632 | 35599398     | 1096641177 | failed  | 2024-10-06 21:09:30.209587 | 2024-10

Wenn du die execute-Anweisung verwendest, um die VACUUM-Abfrage auszuführen, verwende den AWS CLI-Befehl describe-statement, um Fehlermeldungen zu identifizieren.

Beispiel describe-statement:

aws redshift-data describe-statement --id 7c823348d-be8b-437a-9a0-db8c0ca44f0f
{
    "ClusterIdentifier": "redshift-cluster-1",
    "CreatedAt": "2024-10-07T16:25:27.566000+00:00",
    "Duration": -1,
    "Error": "ERROR: VACUUM cannot run inside a multiple commands statement",
    "HasResultSet": false,
    "Id": "7c823348d-be8b-437a-9a0-db8c0ca44f0f",
    "QueryString": "vacuum full toptem;\nvacuum full tsupport;\nvacuum full supplierxbox;\nvacuum full party;",
    "RedshiftPid": 10723479554,
    "RedshiftQueryId": 42304,
    "ResultRows": -1,
    "ResultSize": -1,
    "Status": "FAILED",
    "UpdatedAt": "2024-10-07T16:25:33.566000+00:00"
}

Wenn der Cluster vollständig im Leerlauf ist, führe ein MANUAL VACUUM für fehlgeschlagene VACUUM-Versuche aus. Weitere Informationen findest du unter Manuelles Absaugen und Analysieren von Tabellen.

Verwenden von VACUUM-Best-Practices

Du kannst die VACUUM-Leistung mit den folgenden bewährten Methoden verbessern.

Da VACUUM ein ressourcenintensiver Vorgang ist, solltest du ihn außerhalb der Spitzenzeiten ausführen.

Verwende wlm_query_slot_count, um das Parallelitätsniveau in einer Warteschlange für einen VACUUM-Vorgang vorübergehend außer Kraft zu setzen.

Führe den VACUUM-Vorgang mit einem Schwellenwertparameter von bis zu 99 % für große Tabellen aus. Bestimme den geeigneten Schwellenwert und die Häufigkeit der Ausführung von VACUUM. Beispielsweise möchtest du VACUUM bei einem Schwellenwert von 100 % ausführen oder deine Daten immer sortiert haben. Verwende den Ansatz, der die Abfrageleistung deines Amazon Redshift-Clusters optimiert.

Führe ein VACUUM FULL oder VACUUM SORT ONLY oft genug aus, damit sich in großen Tabellen keine große unsortierte AWS-Region ansammelt.

Wenn sich in einer großen Tabelle eine große Menge unsortierter Daten befindet, führe eine Deep Copy durch.

Führe den VACUUM-Befehl mit der Option BOOST aus.

Unterteile große Tabellen in Zeitreihentabellen, um die VACUUM-Leistung zu verbessern. In einigen Fällen kannst du bei Verwendung einer Zeitreihentabelle die Notwendigkeit umgehen, VACUUM auszuführen.

Wähle einen Spaltenkomprimierungstyp für große Tabellen. Komprimierte Zeilen verbrauchen beim Sortieren von Daten weniger Speicherplatz.

Verwende nach dem VACUUM-Vorgang den Befehl ANALYZE, um die Statistiken zu aktualisieren. Der Abfrageplaner verwendet diese Werte, um die besten Pläne auszuwählen.

Weitere Informationen

Warum wurde meine Abfrage in Amazon Redshift storniert?

Warum wird meine Amazon Redshift Serverless-Abfrage abgebrochen oder gestoppt?