Ein Datenbank-Release muss nicht immer bedeuten, dass alle Sessions gleichzeitig auf neue PL/SQL-Pakete wechseln. Mit Edition-Based Redefinition (EBR) können mehrere Versionen editionierbarer Objekte wie Packages, Funktionen, Views und Synonyme parallel existieren. Eine Session arbeitet jeweils in einer Edition. So lassen sich neue Datenbanklogik bereitstellen und testen, bevor neue Anwendungssessions darauf umgestellt werden.
Releases als kontrollierten Editionswechsel planen
Ein typischer Rollout beginnt mit einer Kind-Edition für die neue Version. Deployment-Skripte wechseln explizit in diese Edition und erstellen dort die geänderten PL/SQL-Objekte. Danach werden Status und Abhängigkeiten geprüft. Die Edition der aktuellen Session lässt sich kontrollieren mit:
SELECT SYS_CONTEXT('USERENV', 'CURRENT_EDITION_NAME')
FROM dual;Die Anwendung kann anschließend neue Sessions gezielt mit der Ziel-Edition verbinden, während bestehende Sessions zunächst in ihrer bisherigen Edition weiterlaufen. Der Wechsel muss zur Pool- und Deployment-Strategie passen: Ein Prozess, der nur den Datenbank-Default ändert, ersetzt nicht automatisch die Edition bereits verbundener Sessions.
Code-Versionierung ist keine Tabellen-Versionierung
Tabellen, Indizes und Sequenzen sind nicht editionierbar. Werden nur Package-Implementierungen geändert, ist EBR oft vergleichsweise geradlinig. Ändert sich zusätzlich das Datenmodell, braucht es ein kompatibles Übergangsmuster: typischerweise additive Spaltenänderungen und Editioning Views als Schnittstelle zwischen altem und neuem Code. Wenn beide Versionen während des Übergangs weiter schreiben, können Forward- und Reverse-Crossedition-Trigger Änderungen zwischen den alten und neuen Spaltenformen synchronisieren.
Solche Trigger sind Übergangswerkzeuge, keine dauerhafte Architektur. Nach dem Wechsel aller schreibenden Sessions und einer geprüften Datenmigration müssen sie wieder entfernt werden. Spalten, die nur die alte Version benötigt, sollten erst nach dem Auslaufen der alten Edition gelöscht werden.
Prüfen, umschalten, aufräumen
- Vorab feststellen, welche Schemas editionsfähig sein müssen und welche Objekte tatsächlich geändert werden.
- Kind-Edition erstellen und Deployment-Skripte mit explizitem Editionskontext ausführen.
- Objektstatus, Tests und Datenkompatibilität in der neuen Edition prüfen.
- Neue Anwendungssessions gezielt auf die Edition routen und alte Sessions auslaufen lassen.
- Nach erfolgreicher Umschaltung temporäre Trigger und alte Objekte geplant bereinigen.
EBR beseitigt nicht jede Downtime-Ursache und macht riskante Tabellenänderungen nicht automatisch sicher. Der Gewinn entsteht durch kompatible Releases, sorgfältige Sessions-Steuerung und einen getesteten Rückweg, bevor alte Objekte entfernt werden.
Fazit
EBR ist besonders interessant für Anwendungen mit viel PL/SQL, bei denen mehrere Code-Versionen zeitweise parallel laufen sollen. Editionen trennen die Code-Stände; editioning views und Crossedition-Trigger helfen beim kontrollierten Übergang von Tabellenstrukturen. Ein klarer Session-Wechsel- und Cleanup-Plan gehört von Beginn an dazu.
Weiterführend: Oracles Dokumentation zu Edition-Based Redefinition und zur CREATE EDITION-Anweisung.