DB Reorganisation

Die meisten Tabelen einer DB haben einen dynamischen bzw. sich ständig ändernden Inhalt. Um das Wachsen der Tabellen durch die nicht mehr benötigten Altlasten zu verhindern, sollen die Tabelle in regelmäßigen Abständen (Wartungszeiträume) aufgeräumt werden.

Dafür ein zusätzliches indexiertes Feld pro DB-Tabelle hinzuzufügen, z.B. namens "todelete" vom Typ "Datum" oder "Zeitstempel". Anwendungen, die auf die Daten zugreifen, sollen Datensätze, die irgendwann nicht mehr benötigt werden, durch das Eintragen des Löschdatums in das Feld "todelete" zum zukünftigen Löschen markieren. Falls das Verfallsdatum gleich beim Anlegen/Updaten des Satzes bekannt ist, ist es sinnvoll, das Feld "todelete" mitzufüllen. (Zwei zusätzliche Felder "toview" und "tohide" könnten auch den Zeitraum aufzeigen, in dem der Satz z.B. via API sichtbar sein sollte.)

Außerdem, ein spezielles Programm (z.B. Prüfprogramm genannt) soll in regelmäßigen Abständen alle Tabellen durchgehen und den Inhalt nach bestimmten Kriterien auf Aktualität auswerten. Damit sollen Datensätze aufgespürt werden, die durch Anwendungen nicht zum Löschen markiert werden konnten (egal aus welchem Grund).

Ein zweites Programm (z.B. Löschprogramm genannt) soll in regelmäßigen Abständen alle Tabellen durchgehen und alle Sätze, die das Datum im "todelete" kleiner als aktuelles Datum haben, löschen oder in einer anderen DB archivieren.

Die Nutzung eines solchen Verfahrens hat folgende Vor- und Nachteile:

Vorteile:

• Daten müssen nicht sofort gelöscht werden. Sie können noch für die Recherchezwecke hilfreich sein. Die API kann aber diese anhand des Löschdatums ausfiltern.
• Durch das Setzen des Löschvermerks durch das zuständige Programm werden sequentielle Scans durch das Löschprogramm und somit das Locken des großen Teilen jeweiliger Tabellen vermieden. Es wird immer nur ein einziger Satz gelockt und nur wenige LogigLog's verbraucht. Auch die Gefahr eines DeadLocks tendiert dabei zu 0.
• Es können leicht Lücken in der Reorganisation festgestellt werden. (Sätze, die nicht meht vorhanden sein sollten, haben aber NULL im "todelete".)
• Durch den Index auf das Feld "todelete" werden die zu löschende Sätze sehr schnell in einem Rutsch gelöscht, ohne dabei einen sequentiellen Scan zu produzieren. Da die zu löschende Sätze durch die API ausgefiltert werden, kommt das Löschprogramm den anderen Anwendungen nicht in die Quere - keine DeadLock-Gefahr.

Nachteile:

• Jeder zu löschende Satz muß zwangsläufig doppelt angefaßt werden: einmal beim Setzen des Löschvermerks und einmal beim physischen Löschen. Als Teillösung könnte man bei dem Prüfprogramm einen force-Modus vorsehen, bei dem Sätze mit bereits abgelaufenem Löschdatum sofort gelöscht werden, ohne erst das Löschdatum zu setzen.

Stand: 15.09.2009 - In Arbeit
— : Jürgen Kreick

EOF