Datenbank-Wartung, die nie geliefert wurde

Eine ERP-Produktivdatenbank wuchs jahrelang unkontrolliert. Statt einer jährlichen Handbereinigung gibt es jetzt ein vollständiges, sicheres Wartungsverfahren.

Ausgangslage

Log-, Fehler- und EDI-Tabellen des ERP-Systems wurden nie systematisch bereinigt. Einmal im Jahr lief eine manuelle Bereinigung über einen Report, der nur einen Teil der relevanten Tabellen erfasste. Die Folge: Die Produktivdatenbank wuchs auf 1,5 TB, das komprimierte Backup auf rund 500 GB – mit entsprechend langen Sicherungs- und Wiederherstellungszeiten.

Lösung

Ich habe eine eigene Wartungsprozedur in T-SQL gebaut, die alle relevanten Bereiche über sämtliche Mandanten hinweg abdeckt:

• Umfang: 14 Fehler- und Log-Tabellen, EDI-Verarbeitungsqueues, EDI-Dokumente samt Zeilen und Anhängen, Änderungs- und Job-Queue-Protokolle.
• Batch-Deletes: Löschen in Paketen, damit Transaktionslog und Sperren auch bei sehr grossen Tabellen im Rahmen bleiben.
• Protokoll: Jeder Lauf schreibt Lauf-ID, Schritt, Zeilenzahl und Zeitstempel – nachvollziehbar und auswertbar.
• Echter Trockenlauf: Ein @DryRun-Modus zeigt vorab, was gelöscht würde, ohne etwas zu verändern.

Der Fehler im Detail

Beim Bau fiel eine trügerische Stelle auf: IF @DryRun = 0 BEGIN TRAN; schützte nur die Zeile mit BEGIN TRAN – nicht die nachfolgenden DELETE- und UPDATE-Anweisungen. Ein als Simulation gedachter Testlauf hätte also produktiv gelöscht. Jede datenverändernde Anweisung ist jetzt ausdrücklich in einen eigenen IF @DryRun = 0 BEGIN … END-Block geklammert; der Trockenlauf zählt stattdessen mit COUNT(*).

Ergebnis

Die Datenbank schrumpfte von 1,5 TB auf 650 GB, das komprimierte Backup von rund 500 auf 130 GB. Aus einer jährlichen Handarbeit wurde ein regelmässiger, protokollierter Job mit sicherem Vorschaumodus – vollständig dokumentiert und auf weitere Systeme übertragbar.