Warum wird durch den Amazon Redshift VACUUM-Vorgang kein Speicherplatz zurückgewonnen?

Lesedauer: 4 Minute
0

Ich führe einen VACUUM FULL- oder VACUUM DELETE ONLY-Vorgang für eine Amazon Redshift-Tabelle aus, die Zeilen enthält, die zum Löschen markiert sind. Der Vorgang scheint erfolgreich abgeschlossen zu sein. Warum gibt es keinen zurückgewonnenen Speicherplatz?

Kurzbeschreibung

Speicherplatz wird möglicherweise nicht zurückgewonnen, wenn Transaktionen mit langer Laufzeit aktiv bleiben. Wenn Zeilen gelöscht werden, wird eine versteckte Metadaten-Identitätsspalte, DELETE\ _XID, mit der Transaktions-ID markiert, mit der die Zeile gelöscht wurde. Wenn es eine aktive, lang andauernde Transaktion gibt, die vor dem Löschen begonnen hat, kann VACUUM die Zeilen nicht bereinigen. Das bedeutet, dass Festplattenspeicher nicht zurückgewonnen werden kann. Weitere Informationen zur Spalte DELETE\ _XID finden Sie unter Optimieren des Speichers für schmale Tabellen.

Lösung

1.    Führen Sie die folgende Abfrage aus, um im Cluster nach Transaktionen mit langer Laufzeit zu suchen:

rsdb=# select *,datediff(s,txn_start,getdate())/86400||' days '||datediff(s,txn_start,getdate())%86400/3600||' hrs '||datediff(s,txn_start,getdate())%3600/60||' mins '||datediff(s,txn_start,getdate())%60||' secs' duration from svv_transactions where lockable_object_type='transactionid' and  pid<>pg_backend_pid() order by 3;

Die folgende Ausgabe zeigt, dass xid 50341 19 Minuten und 37 Sekunden lang aktiv war:

txn_owner  | txn_db |  xid  |  pid  |         txn_start          |   lock_mode   | lockable_object_type | relation | granted |           duration
-----------+--------+-------+-------+----------------------------+---------------+----------------------+----------+---------+------------------------------
 superuser | rsdb   | 50341 | 21612 | 2019-08-19 20:20:33.147622 | ExclusiveLock | transactionid        |          | t       | 0 days 0 hrs 19 mins 37 secs
(1 row)

2.    Führen Sie die folgende Abfrage aus, um zu bestätigen, ob Zeilen aus der Amazon Redshift-Tabelle gelöscht wurden:

select a.query, a.xid, trim(c.name) tablename, b.deleted_rows, a.starttime, a.endtime
from stl_query a
join (select query, tbl, sum(rows) deleted_rows from stl_delete group by 1,2) b
on a.query = b.query
join (select id, name from stv_tbl_perm group by 1,2) c
on c.id = b.tbl
where a.xid in (select distinct xid from stl_commit_stats)
and trim(c.name) = 'tablename'
order by a.starttime;

Die folgende Ausgabe zeigt, dass die zum Löschen von Zeilen markierte Transaktion (xid 50350) nach der lang andauernden Transaktion (xid 50341) gestartet wurde:

query  |  xid  | tablename | deleted_rows |         starttime          |          endtime
-------+-------+-----------+--------------+----------------------------+----------------------------
 18026 | 50350 | test      |            5 | 2019-08-19 20:20:48.137594 | 2019-08-19 20:20:50.125609
(1 rows)

Damit VACUUM DELETE diese gelöschten Zeilen zurückfordern kann, wählen Sie eine der folgenden Optionen und führen Sie dann den VACUUM-Vorgang erneut aus:

  • Warten Sie, bis die lang andauernde Transaktion abgeschlossen ist.
  • Verwenden Sie die Anweisung PG\ _TERMINATE\ _BACKEND, um die Sitzung zu beenden, die die Transaktion mit langer Laufzeit enthält.

Untersuchen der Transaktionen mit langer Laufzeit

Fragen Sie die SVL\ _STATEMENTTEXT-Ansicht ab, um die Aktivität in einer Transaktion mit langer Laufzeit zu überprüfen:

rsdb=# select pid, xid, trim(label), starttime, endtime, trim(text) from svl_statementtext where xid = 50341 order by starttime , sequence;

Hier ist ein Beispiel für eine Ausgabe:

pid  |  xid  |  btrim  |         starttime          |          endtime           |          btrim
-------+-------+---------+----------------------------+----------------------------+--------------------------
 21612 | 50341 | default | 2019-08-19 20:20:31.733843 | 2019-08-19 20:20:31.733844 | begin;
 21612 | 50341 | default | 2019-08-19 20:20:33.146937 | 2019-08-19 20:20:35.020556 | select * from sometable;
(2 rows)

Fragen Sie die STV_INFLIGHT-Ansicht ab, um zu überprüfen, ob in der Transaktion Abfragen ausgeführt werden:

rsdb=# select query, xid, pid, starttime, trim(text) from stv_inflight where xid = 50341;

Hier ist ein Beispiel für eine Ausgabe:

query | xid | pid | starttime | btrim
-------+-----+-----+-----------+-------
(0 rows)

Häufige Probleme, die Transaktionen mit langer Laufzeit führen

Das folgende Verhalten kann zu Transaktionen mit langer Laufzeit führen:

  • Ein Benutzer startet eine implizite Transaktion von einem Client aus, auf dem die automatische Übertragung deaktiviert ist. Die Transaktion bleibt aktiv, bis der Benutzer die Transaktion explizit mit dem Befehl COMMIT oder ROLLBACK schließt oder bis die Sitzung beendet wird.
  • Ein Benutzer startet eine Transaktion explizit mit BEGIN, schließt die Transaktion jedoch niemals mit den Befehlen COMMIT oder ROLLBACK.

Verwandte Informationen

Bereinigen von Tabellen

Verwalten der Bereinigungszeiten

AWS OFFICIAL
AWS OFFICIALAktualisiert vor 2 Jahren