it-swarm.com.de

VACUUM gibt Speicherplatz an das Betriebssystem zurück

VACUUM gibt normalerweise keinen Speicherplatz an das Betriebssystem zurück, außer in einigen besonderen Fällen.
Aus den Dokumenten:

Die Standardform von VACUUM entfernt tote Zeilenversionen in Tabellen und Indizes und markiert den für die zukünftige Wiederverwendung verfügbaren Speicherplatz. Der Speicherplatz wird jedoch nicht an das Betriebssystem zurückgegeben, außer in dem speziellen Fall, in dem eine oder mehrere Seiten am Ende einer Tabelle vollständig frei werden und eine exklusive Tabellensperre leicht erhalten werden kann. Im Gegensatz dazu komprimiert VACUUM FULL Tabellen aktiv, indem eine vollständig neue Version der Tabellendatei ohne Totraum geschrieben wird. Dies minimiert die Größe der Tabelle, kann jedoch lange dauern. Außerdem wird zusätzlicher Speicherplatz für die neue Kopie der Tabelle benötigt, bis der Vorgang abgeschlossen ist.

Die Frage ist: Wie kann diese Datenbank angeben, wann one or more pages at the end of a table become entirely free Erreicht wird? Dies kann über VACUUM FULL Durchgeführt werden, aber ich habe nicht genügend Speicherplatz, um es zu implementieren. Gibt es also noch andere Möglichkeiten?

Verwenden Sie VACUUM FULL , um Speicherplatz an das Betriebssystem zurückzugeben. Ich nehme an, Sie führen VACUUM FULL ANALYZE Aus. Ich zitiere das Handbuch :

FULL

Wählt "volles" Vakuum aus, das mehr Speicherplatz beanspruchen kann , aber viel länger dauert und ausschließlich den Tisch sperrt. Diese Methode erfordert auch zusätzlichen Speicherplatz, da eine neue Kopie der Tabelle geschrieben wird und die alte Kopie erst freigegeben wird, wenn der Vorgang abgeschlossen ist. Normalerweise sollte dies nur verwendet werden, wenn eine erhebliche Menge an Speicherplatz aus der Tabelle zurückgefordert werden muss.

Meine kühne Betonung.

CLUSTER erreicht dies auch als Sicherheitseffekt.

Plain VACUUM erreicht Ihr Ziel normalerweise nicht ( "eine oder mehrere Seiten am Ende einer Tabelle völlig frei"). Es ordnet keine Zeilen neu an und entfernt leere Seiten nur dann vom physischen Ende der Datei, wenn sich die Gelegenheit ergibt - wie in Ihrem Zitat aus dem Handbuch angegeben.

Sie können leere Seiten am Ende der physischen Datei erhalten, wenn Sie INSERT einen Stapel von Zeilen und DELETE sie, bevor andere Tupel angehängt werden. Oder es kann zufällig passieren, wenn genügend Zeilen gelöscht werden.

Es gibt auch spezielle Einstellungen, die möglicherweise verhindern, dass VACUUM FULL Speicherplatz zurückgewinnt. Sehen:

Bereiten Sie leere Seiten am Ende einer Tabelle zum Testen vor

Die Systemspalte ctid repräsentiert die physische Position einer Zeile. Sie müssen diese Spalte verstehen:

Wir können damit arbeiten und eine Tabelle vorbereiten, indem wir alle Zeilen von der letzten Seite löschen:

DELETE FROM tbl t
USING (
   SELECT (split_part(ctid::text, ',', 1) || ',0)')::tid     AS min_tid
        , (split_part(ctid::text, ',', 1) || ',65535)')::tid AS max_tid
   FROM   tbl
   ORDER  BY ctid DESC
   LIMIT  1
   ) d
WHERE t.ctid BETWEEN d.min_tid AND d.max_tid;

Jetzt ist die letzte Seite leer. Dies ignoriert gleichzeitige Schreibvorgänge. Entweder sind Sie der einzige, der in diese Tabelle schreibt, oder Sie müssen eine Schreibsperre verwenden, um Interferenzen zu vermeiden.

Die Abfrage ist optimiert, um qualifizierende Zeilen schnell zu identifizieren. Die zweite Zahl eines tid ist der Tupelindex, der als vorzeichenloses int2 Gespeichert wird, und 65535 Ist das Maximum für diesen Typ (2^16 - 1) sichere Obergrenze.

SQL Fiddle (Wiederverwendung einer einfachen Tabelle aus einem anderen Fall.)

Werkzeuge zum Messen der Zeilen-/Tabellengröße:

Festplatte voll

Für jeden dieser Vorgänge benötigen Sie Spielraum auf der Festplatte. Es gibt auch das Community-Tool pg_repack als Ersatz für VACUUM FULL/CLUSTER. Es vermeidet exklusive Sperren, benötigt aber auch freien Speicherplatz. Das Handbuch :

Benötigt freien Speicherplatz, der doppelt so groß ist wie die Zieltabelle (n) und Indizes.

Als letzten Ausweg können Sie einen Speicherauszugs-/Wiederherstellungszyklus ausführen. Dadurch wird auch jegliches Aufblähen aus Tabellen und Indizes entfernt. Eng verwandte Frage:

Die Antwort dort ist ziemlich radikal. Wenn Ihre Situation dies zulässt (keine Fremdschlüssel oder andere Referenzen, die das Löschen von Zeilen verhindern) und kein gleichzeitiger Zugriff auf die Tabelle), können Sie einfach:

Speichern Sie die Tabelle auf der Festplatte, die von einem Remotecomputer mit viel Speicherplatz verbunden ist. ) (-a Für --data-only):

Dump-Tabellendaten von der Remote-Shell:

pg_dump -h <Host_name> -p <port> -t mytbl -a mydb > db_mytbl.sql

In einer pg-Sitzung TRUNCATE die Tabelle:

-- drop all indexes and constraints here for best performance
TRUNCATE mytbl;

Stellen Sie von der Remote-Shell aus dieselbe Tabelle wieder her:

psql -h <Host_name> -p <port> mydb -f db_mytbl.sql
-- recreate all indexes and constraints here

Es ist jetzt frei von toten Reihen oder Aufblähungen.

Aber vielleicht können Sie das einfacher haben?

  • Können Sie genügend Speicherplatz auf der Festplatte schaffen, indem Sie nicht verwandte Dateien löschen (verschieben)?

  • Können Sie VACUUM FULL Zuerst nacheinander kleinere Tabellen erstellen, um genügend Speicherplatz freizugeben?

  • Können Sie REINDEX TABLE oder REINDEX INDEX Ausführen, um Speicherplatz aus aufgeblähten Indizes freizugeben?

Was auch immer Sie tun, seien Sie nicht unbesonnen . Sichern Sie im Zweifelsfall zuerst alles an einem sicheren Ort.

33