In der Datenbankadministration von Db2 Tabellen und auch in der Anwendungsentwicklung wird immer häufiger die Anforderung gestellt, dass sehr große Datenbanken (> 10 Mio Rows) aus historisch gewachsenen row-basierten Tabellen zu löschen sind.
Lösungsansätze und Optimierungen
Herausforderung beim Löschen großer Db2 Tabellen
In der Regel sind solche historisch gewachsenen row-basierten Tabellen normale Db2 Tabellen ohne irgendwelche oder mit nicht zur Löschung passenden Partitionierungstechniken. D.h. die zu löschende Datenmenge muss mit DELETE-Statements gelöscht und im Transaktionslog protokolliert werden. Ein einzelnes DELETE-Statement zum Löschen der Rows endet nicht selten im SQL Error SQL0964C „The transaction log for the database is full“.
Natürlich könnte man die Tabelle in eine neue Tabelle mit LOAD FROM CURSOR umladen und nur die nicht zu löschenden Zeilen laden. Das bedeutet aber nach dem LOAD eine Downtime, um die bisherige mit der neuen Tabelle zu synchronisieren (bis auf die zu löschenden Zeilen) und auf den bisherigen Tabellennamen umzubenennen.
Bisheriger Ansatz mit Commit-Zählung
Es gab bereits einen Ansatz, solche Löschungen mit einer Db2 Stored Procedure umzusetzen (Quelle).
Diese Stored Procedure arbeitet mit dem Syntax-Element FETCH FIRST x ROWS ONLY beim SELECT-Statement, das für den DELETE verwendet wird:
Nach jedem dieser DELETE-Statements wird ein Commit abgesetzt, und in einer While-Schleife wird so lange iteriert, bis keine Zeilen mehr zu löschen sind.
Das funktioniert technisch. Wenn aber kein korrekter Index für den DELETE auf der Tabelle existiert, erfolgt der Zugriff über TBSCANs anstatt IXSCANs. Das bedeutet, dass jede DELETE-Iteration alle Zeilen in der Tabelle erneut lesen muss – auch jene, die nicht gelöscht werden sollen. Das kann die Laufzeit erheblich erhöhen.
Optimierte Lösung mit positioned DELETE
Eine bessere Technik ist, einen Cursor für die zu löschenden Zeilen zu erzeugen und diese dann mit positioned DELETEs zu löschen.
Ein positioned DELETE löscht die Zeile, auf der der SELECT-Cursor gerade steht:
Sobald beispielsweise x = 1000 oder x = 10000 Zeilen gelöscht wurden, wird ein Commit abgesetzt und die nächsten Zeilen werden gelöscht.
Mit dieser Technik wird nur ein einziger TBSCAN durchgeführt – der des SELECTs im definierten CURSOR. Sobald das Tabellenende erreicht ist, sind alle zu löschenden Zeilen entfernt, und die Stored Procedure liefert RC=0 zurück.
Die Laufzeit konnte in Tests mit positioned DELETEs um Faktoren reduziert werden.
Aufrufsyntax
Die von mir entwickelte Db2 Stored Procedure wird mit folgender Syntax aufgerufen:
Beispiele:
1. Ohne Ausgabe eines Resultsets mit Löschmetriken
2. Mit Ausgabe eines Resultsets mit Löschmetriken
Fazit
Das effiziente Löschen großer Datenmengen in Db2 erfordert eine durchdachte Vorgehensweise, um Laufzeiten und Log-Belastung zu minimieren. Während herkömmliche DELETE-Strategien schnell an technische Grenzen stoßen, bietet die Nutzung einer Stored Procedure mit positioned DELETEs eine deutlich performantere und stabile Lösung. Durch kontrollierte Commits und gezielte Cursorsteuerung lassen sich selbst umfangreiche Löschvorgänge zuverlässig und ohne Systemüberlastung durchführen.
Bei Interesse können Sie sich hier kostenfrei die SQL Definition der Db2 Stored Procedure mit dem File TOOLS.MASSDEL downloaden.
Wenn Sie überlegen, ähnliche Optimierungen in Ihrer Db2 Umgebung einzuführen, stehe ich Ihnen gerne für ein persönliches Gespräch zu Ihrem Projekt zur Verfügung.
Kontaktieren Sie mich gerne !
Ihr Gerhard Paulus
Senior Consulting
