Flashback Database im Deploymentprozess

Flashback Database im Deploymentprozess
Wer kennt das nicht: ein System soll im Zuge eines Softwareupdates aktualisiert
werden, wofür ein fest definiertes Wartungsfenster vorgesehen ist.
Das darf natürlich nur einen möglichst geringen Zeitraum in Anspruch nehmen und sollte in
nutzungsarmen Zeiten - also gerne abends oder nachts - stattfinden.
Unmittelbar vor dem Termin wird nochmal die Vorbereitung hinterfragt:
-
sind Schwierigkeiten zu erwarten?
Ist das Wartungsfenster ausreichend bemessen?
Ist das Backup in Ordnung?
Was ist alles zu berücksichtigen, wenn Nachbessern nicht hilft und ein Rollback erfolgen
muss?
Als verantwortungsvoller und erfahrener Administrator muss selbstverständlich nicht
regelmäßig zum Ausrollen einer Aktualisierung mit Schweißausbrüchen gerechnet werden.
Dennoch: kann ich den Prozess nicht vereinfachen? Muss ich wirklich die Uhr während des
Deployment-Fortschritts im Auge behalten, um einen möglicherweise notwendigen Rollback
mit Rücksicherung und allen anderen nötigen Maßnahmen rechtzeitig zu starten?
Dazu betrachten wir hier ein Feature des Oracle RDBMS, das gerade auch für
solche Situationen geschaffen wurde!
Mitunter fragt man sich oder wird gefragt: wozu müssen wir teure Datenbanken lizenzieren,
wenn es heute doch so viel schöne billigere oder gar kostenlose, möglicherweise auf Open
Source basierende Datenbanksoftware gibt? Ist es überhaupt sinnvoll, die über das Übliche
hinausgehenden Features zu nutzen, wenn wir uns damit von einem bestimmten Hersteller
abhängig machen? Ist die Datenbank nicht ohnehin hinter anderen Software-Schichten wie
BI-Tools oder noch allgemeiner Application Servern "versteckt"?
Eine mögliche Antwort finden wir hier.
Was bisher geschah...
Autor: Jürgen Maihöfner ● endlich OHG ● Flößaustr.24 ● D-90763 Fürth
1/4
Vorab ein wenig Geschichte
Beginnend mit dem Release 9i führte Oracle das erste Feature, gleichsam das Fundament für
Oracle Flashback ein: Flashback Query. Dies ermöglicht Abfrage wie folgende:
select * from some_garbage_data as of timestamp systimestamp interval '10'
minute;
Mit Oracle 10g wurden zahlreiche weitere Ausprägungen wie Flashback Database, Flashback
Drop, Flashback Table und weitere eingeführt. Oracle 11g brachte Flashback Transaction
(liefert Metadaten zu vergangenen Transaktionen inklusive einem "Undo-SQL") sowie
Flashback Data Archive (auch bekannt als Total Recall; versioniert Daten gemäß einer
Aufbewahrungsfrist).
Einige Formen sind für Entwickler besonders interessant; andere für Administratoren. Zur
Verbesserung des Deployment-Prozesses soll hier Flashback Database das Feature unserer
Wahl sein. Da es sich beim Deployment um eine administrative Tätigkeit handelt, ist die
Nutzung auch über eine mögliche Kritik erhaben, die Nutzung würde zu einer Abhängigkeit
von einem Hersteller führen: für die auf der Datenbank aufbauenden Anwendungen ist
Flashback Database "unsichtbar".
...und wie schön es sein könnte!
Ein typisches Deployment wird folgende wesentlichen Schritte umfassen:
-
Stopp der Anwendung
Sicherung des aktuellen Standes
Deployment des neuen Release, meist automatisierte und manuelle Schritte umfassend
Testen
Start und Freigabe des neuen Release
Jedoch im Fehlerfall, der während des Deployments oder während der Tests auftreten kann:
- Nachbesserungsversuche - hierzu im zweiten Teil mehr
- Restore des Systems - mitunter zeitraubend und hektisch. Diesen Punkt wollen wir
verhindern!
Sind die nachfolgend beschriebenen Voraussetzungen erfüllt, ist lediglich
unmittelbar vor dem Deployment ein sogenannter garantierter Restore Point zu
erstellen:
SQL> CREATE RESTORE POINT before_release_goodoldtime GUARANTEE
FLASHBACK DATABASE;
Autor: Jürgen Maihöfner ● endlich OHG ● Flößaustr.24 ● D-90763 Fürth
2/4
Sollte das Deployment nicht wie erwartet fortschreiten und erfolgreich durchgeführt werden
können, die Tests keine Fehlerfreiheit zeigen, oder unmittelbar nach dem Deployment ein
Rollback angezeigt sein: locker bleiben! :-)
Ein denkbares Szenario unter vielen möglichen: eine Tabelle mit vermeintlich unkritischen
Daten wurde im Zuge der Anwendungsaktualisierung gelöscht und neu aufgebaut, der
abschließende fachliche Test stellt aber die Unwiederbringlichkeit tatsächlich unbedingt zu
erhaltender Daten heraus...
Um die Zeit zu einem Punkt zurück zu drehen, als alles noch friedlich war, ist lediglich
folgendes Kommando auszuführen. Selbstredend ist eine Kennung mit administrativen
Berechtigungen zu nutzen. Es kann sowohl in RMAN, als auch im SQL-Tool des Vertrauens
abgesetzt werden:
FLASHBACK DATABASE TO RESTORE POINT 'before_release_goodoldtime';
Zwar ist die konkrete Dauer abhängig vom Umfang der zurück zu nehmenden Änderungen
durch das fehlgeschlagene Deployment. Da das Verfahren mit online verfügbaren
Protokolldateien erfolgt, ist mit einer Fertigstellung des Database Flashback innerhalb einer
Zeitspanne zu rechnen, die mit anderen Methoden nicht zu erreichen sein dürfte. Und das
auf eine derart einfache Weise, bei der auch während etwaiger Hektik kaum etwas falsch
laufen kann! Ein paar Voraussetzungen für Flashback Database, wenn auch in sehr
überschaubarem Umfang, sind zu erfüllen:
- die Datenbank muss im Archivelog-Modus betrieben werden,
- eine Fast Recovery Area muss aktiviert sein,
- es muss ausreichend Speicherplatz verfügbar sein.
Da zusätzliche Logging-Informationen geschrieben und verwaltet werden müssen, die
zusätzlichen Speicherplatz erfordern, sollten vor einer Umsetzung unbedingt einige Tests in
unkritischen Umgebungen erfolgen!
Auch ist das Verfahren mit einigen, aber ebenfalls kleineren Einschränkungen verbunden. Zu
nennen wären beispielsweise
- Flashback Database über eine Zielzeit hinweg, während der Operationen mit NOLOGGING
stattfanden, kann zu Block Corruption führen. An zu vermeidente ETL-Vorgänge wäre hier
zu denken, welche aber während eines Deployments sehr unwahrscheinlich sind,
- Medienfehler zur "falschen" Zeit können ein herkömmliches Restore erforderlich machen.
Details sind in der Dokumentation unter
https://docs.oracle.com/database/121/BRADV/flashdb.htm#BRADV71000 zu finden.
Autor: Jürgen Maihöfner ● endlich OHG ● Flößaustr.24 ● D-90763 Fürth
3/4
Und täglich grüßt...
Nun ist Flashback Database schon mal aktiviert - was lässt sich daraus noch machen?
Wäre es nicht begrüßenswert, wenn der Ausgang des Deployments besser vorhersehbar
wäre?
Klar, durch zwischen den Entwicklungs- und Produktivsystemen geschaltete
Qualitätssicherungs- und Integrationsumgebungen können Fehlschläge nahezu
ausgeschlossen werden.
Soll aber regelmäßig, beispielsweise täglich, ein Integrations- bzw. Deployment-Versuch auf
einer dafür vorgesehenen Umgebung erfolgen, haben die für das Konfigurationsmanagement
Zuständigen mitunter eine anspruchsvolle Aufgabe zu bewältigen.
Muss das Feature Flashback Database nicht einfach gerngehabt werden, wenn es das Leben
derart einfach machen kann:
-
Setzen eines garantierten Restore Point
Versuch des täglichen Deployments in der Integrationsumgebung
Ergebniss überprüfen
Flashback Database zum garantierten Restore Point
War das Deployment erfolgreich? -> Gut!
War es nicht? -> Rückmeldung an den Verursacher zur Behebung. Nichts weiter. Die
Datenbank wurde durch das Flashback Database ohnehin wieder auf den Ursprungszustand
zurückgesetzt!
Fazit
Wird das Feature Flashback Database wie oben beschrieben eingesetzt, können folgende
Vorteile erreicht werden:
- Zeit- und damit Kostenersparnis. Dies relativiert auch die andernfalls womöglich
gelegentlich hinterfragten Lizenzkosten
- bessere Qualität durch einfach ermöglichte fortwährende Integration. "Unfälle" bei
fehlerhaften Versuchen können einfach "repariert" werden
- stabilere Services durch die Möglichkeit, jederzeit zu einem stabilen Zustand zurück
kehren zu können
Autor: Jürgen Maihöfner ● endlich OHG ● Flößaustr.24 ● D-90763 Fürth
4/4