[PostNAS Suite] DB schrumpfen

[Jäger, Frank (KRZ)]

Moin!
Ein temporärer Engpass beim Plattenplatz des Datenbankservers ließ mich heute darüber nachdenken, was ich mal löschen könnte, um etwas Platz zu schaffen.

Neben den OSM-Daten von NRW, die beim Import mit "imposm" den Engpass verursachten, nehmen die 18 ALKIS-Datenbanken den meisten Platz in Anspruch.
Sie sind bzw. waren zwischen 500 MB und 2400 MB groß und umfassen jeweils ein Gemeinde- oder Stadtgebiet. Die einzelnen Datenbanken werden monatlich aktualisiert. Die Laufzeiten liegen von 4 bis 33 Monate.


1.
Um die nicht benötigten historischen Objekte los zu werden, habe ich eine in der Datenbank definierte Function verwendet:

SQL:>  SELECT alkis_delete_all_endet();

Löscht aus allen Tabellen die Objekte, die ein "endet"-Datum haben. 

2.
Die Tabelle "delete" wird vom Konverter mit den Inhalten der Delete-, Replace- und Update-Anweisungen gefüllt.
Beim SQL-Insert in "delete" kümmert sich dann der genannte Trigger darum, die Objekt-Tabellen fortzuführen. Danach könnten die Einträge in "delete" evtl. noch zur Fehleranalyse verwendet werden. Aber kein mir bekanntes Anwendungsprogramm verwendet diese Daten. Also weg damit:

SQL:>  TRUNCATE delete;
oder 
SQL:>  DELETE FROM delete;

macht die Tabelle leer.

3.
Die Relationen zwischen Objekten werden seit einiger Zeit über Spalten in den Objekt-Tabellen verlinkt.
Alte Versionen verwendeten dazu früher die Verbindungstabelle "alkis_beziehungen". Derzeit wird diese Tabelle immer noch vom Konverter gefüllt.
Da alle hier eingesetzte Programme und Views umgestellt sind, brauche ich das nicht mehr.

SQL:>  TRUNCATE alkis_beziehungen;
oder
SQL:>  DELETE FROM alkis_beziehungen;

Schafft auch hier Ordnung.
Vielleicht sollte man diese Tabelle mal aus dem Konverter entfernen?

4.
Um die gelöschten Inhalte für das System als Plattenplatz verfügbar zu machen, ist ein VACCUM notwendig. Verwendet man ein vorsichtiges 

SQL:>  VACUUM analyse;

Bringt das enttäuschende 2% Verkleinerung der Datenbank. Traut man sich aber ein

SQL:>  VACUUM full;

Dann liegt die Ersparnis meist bei über 60% !!   (Bei den oben beschriebenen Datenbanken)
Vorsicht: Das "VACUUM full" läuft länger und sperrt während der Aktion die Datenbank.

Ich habe dann Gegenproben gemacht und ein "VACUUM full;" auf einer postNAS-DB angewendet OHNE vorher die Lösch-Schritte 1 bis 3 auszuführen.
Der Effekt ist fast genau so groß. Das Löschen (1 bis 3) steigert den Effekt nur um wenige Prozent.


Fazit: 

"VACCUM full" verkleinert eine fortgeführte postNAS-Datenbank auf etwa die Hälfte.
Löschen nicht benötigter Tabellen-Inhalte steigert das noch um einige Prozent.

Man hat der Datenbank nun aber die Reserve-Bereiche genommen. Ich hoffe das ist nicht kontraproduktiv bei nachfolgenden Fortführungen.


Die Größe der DB kann man sehen im pgAdmin / Datenbanken / Statistik,
oder mit
SQL:>  SELECT pg_database_size('alkisdb');


Hintergrund zu Schritt 1.

Früher habe ich den Trigger "delete" verwendet. Mit Umstellung auf den norGIS-ALKIS-Importer wird nun der Trigger-Typ "hist" verwendet obwohl ich für historische Objekte eigentlich gar keine Verwendung habe. 
In allen Programme werden inzwischen konsequent die historischen Objekte rausgefiltert, so dass es dafür egal ist, ob mit delete-Trigger oder hist-Trigger gearbeitet wird.

Der delete-Trigger löscht ein historisch gewordenes Objekt aus der Objekt-Tabellen, der hist-Trigger setzt dem Objekt ein endet-Datum.
Der "delete"-Trigger wurde in der letzten Zeit nicht mehr gewartet. Eventuell muss der mal entsorgt werden?


Mit freundlichen Grüßen
Frank Jäger

Kommunales Rechenzentrum
Minden-Ravensberg/Lippe
Tel.: 05261 / 252 - 185
mailto:f.jaeger at krz.de
http://www.krz.de/

-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : smime.p7s
Dateityp    : application/pkcs7-signature
Dateigröße  : 4264 bytes
Beschreibung: nicht verfügbar
URL         : <http://lists.osgeo.org/pipermail/nas/attachments/20160713/da58f6a9/attachment.bin>