Versions-Upgrade / Patch-Rollback

Symptom

Probleme nach einem Upgrade/Patch: Performance-Regression, Inkompatibilität mit der Anwendung oder die Datenbank öffnet nicht.

1. Erst innehalten: Hast du einen Rückfallplan?

Hast du VOR dem Produktions-Upgrade kein Vollbackup + (wenn möglich) keinen Storage-Snapshot erstellt, ist Fix-Forward der sicherste Weg. In den meisten Datenbanken bedeutet ein Rollback die Wiederherstellung aus dem Backup. Dieser Schritt hätte eigentlich VOR dem Upgrade geplant sein sollen.

2. Das Problem einordnen

Handelt es sich um eine Planregression des Optimizers (Abfragen wurden langsamer), eine Inkompatibilität von Anwendung/Treiber oder ein Problem beim Öffnen/Korruption? Der Lösungsweg unterscheidet sich danach stark.

3. Rollback-Weg je Datenbank

Oracle: Patch-Rollback mit datapatch oder Flashback Database (wenn du einen Guaranteed Restore Point angelegt hast). PostgreSQL: Rollback nach pg_upgrade = alte Binaries + Backup des alten Datenverzeichnisses. MySQL: Ein In-Place-DOWNGRADE wird generell NICHT UNTERSTÜTZT – aus dem Backup wiederherstellen. SQL Server: Es gibt kein Downgrade – aus dem Backup vor dem Upgrade wiederherstellen. In jedem Fall gilt: Snapshot/Backup ist deine Versicherung.

4. Bei Planregression: ohne Rollback beheben

Meist muss nicht die ganze Version zurückgerollt werden; geändert haben sich nur die Pläne.

Oracle

ALTER SYSTEM SET optimizer_features_enable='19.1.0';  -- pin to the old behavior
-- or lock in the good plan with a SQL Plan Baseline

PostgreSQL

ANALYZE;  -- fresh statistics first
-- if needed, temporarily: steer the plan with settings such as SET enable_nestloop=off;

5. Dauerhaft: beim nächsten Mal

Teste das Upgrade zuerst in Staging mit realer Workload, wende Canary-/Rolling-Upgrades an, erstelle einen Guaranteed Restore Point / Snapshot und dokumentiere das Rückfallverfahren.