Ich habe kürzlich an einem Thread in der OTN-Community teilgenommen, in dem jemand Fragen zum Downgrade nach einem Datenbank-Upgrade gestellt hat. Eine der Antworten fragte, wie viele Leute tatsächlich Datenbank-Downgrades praktizieren. Ich habe diese Umfrage erstellt, um das herauszufinden.
Ich war überrascht, einen Beitrag zu diesem Thread zu finden, in dem es hieß:
Nun, dieses Poster hat es nicht ausdrücklich gesagt, aber es war fast so, als würde diese Person sagen, dass das Üben von Herabstufungen Zeitverschwendung sei, weil sie es nie brauchen würden. Ich gebe dem Poster den Vorteil des Zweifels und dass dieser Oracle-Mitarbeiter dies nicht wirklich gesagt hat. Ich versuche nicht, auf dieser Person herumzuhacken. Ich lasse diesen Thread mir die Möglichkeit geben, das Thema aus einer allgemeineren Sichtweise zu diskutieren. (Aktualisierung: der Poster, der mich dazu aufgefordert hat, diesen Blogeintrag zu schreiben, ist in der Zeit, in der ich dies geschrieben habe, auf den Thread zurückgekommen und hat gesagt:"wollte nicht andeuten, dass wir Herabstufungen nicht "testen" sollten." )
Bereits im Juli habe ich einen Blogbeitrag über The Data Guardian geschrieben. In diesem Blogbeitrag sagte ich:
Der DBA muss die Daten schützen. Das ist Aufgabe Nr. 1. Job Nr. 2 ist für den DBA, einen effizienten und zeitnahen Zugriff auf die Daten bereitzustellen. Was nützen die Daten, wenn die Personen, die darauf zugreifen müssen, keinen Zugriff auf die Daten haben? Wenn diese Personen bei der Interaktion mit den Daten eine schlechte Leistung erbringen, haben sie möglicherweise genauso gut keinen Zugriff.
Als DBA müssen wir das Risikomanagement durchführen. Wir müssen bestimmen, welche Risiken Realität werden könnten. Die Aufgabe der DBAs besteht darin, diese Risiken zu messen und zwei Aktionspläne festzulegen. Welche Schritte können unternommen werden, um zu vermeiden, dass dieses Risiko Realität wird, und welche Schritte muss ich unternehmen, um das Problem zu lösen, wenn dieses Risiko Realität wird?
Selbst ein Junior-Level-DBA wird die Bedeutung von Backups verstehen. Backups sind eine Risikomanagementstrategie. Bei Datenverlust können wir die Daten aus dem Backup wiederherstellen. Und selbst ein Junior-Level-DBA weiß, wie wichtig es ist, aus dem Backup wiederherstellen zu können.
In diesem OTN-Thread habe ich Folgendes geschrieben:
Für mich ist das eine Art Murphy’s Law. Ich habe in der Vergangenheit ähnliche Dinge gesagt. Die Idee (und das ist der springende Punkt dieses Blogeintrags) ist, dass ich, wenn ich keine angemessenen Schritte zum Risikomanagement ergreife, die Götter nur bitte, dieses Risiko in die Realität umzusetzen. Wenn ich mich weigere, meinen Rückspiegel einzustellen und ihn zu benutzen, wenn ich mein Fahrzeug zurücksetze, dann ist das der Tag, an dem ich in etwas zurückfahre. Wenn ich mich weigere, meine Schnürsenkel zu binden, dann ist das der Tag, an dem ich auf einen trete und stolpere. An dem Tag, an dem ich mich weigere, eine Schutzbrille zu tragen, wenn ich ein Elektrowerkzeug benutze, bekomme ich etwas in mein Auge. Der Tag, an dem ich zum Strand gehe und mich weigere, Sonnencreme aufzutragen, ist der Tag, an dem ich mit einem Sonnenbrand nach Hause komme. Du verstehst schon.
Einige Leser denken vielleicht, dass ich verrückt bin und dass das Universum diesen Masterplan nicht hat, um es mit mir zu vermasseln, nur weil ich selbstgefällig bin. Und ich würde zustimmen. Ich sage es also anders:Wenn ich nicht vorhabe, das Risiko zu mindern, dann habe ich nichts getan, um zu verhindern, dass es Realität wird. Die Chancen, dass es Wirklichkeit wird, verringern sich nicht wegen meiner Untätigkeit.
Das Risikomanagement besteht aus zwei Hauptkomponenten. 1) Bestimmung der Wahrscheinlichkeit, dass dieses Risikoelement eintritt, und 2) Bestimmung der Auswirkung, wenn dieses Risiko eintritt. Die Elemente mit der höchsten Wahrscheinlichkeit des Auftretens werden zuerst gemildert. Das ist einfach und etwas, das viele, die am Risikomanagement arbeiten, oft tun. Sie fügen die Risikopositionen in eine Tabelle ein und geben einen Wert für die Wahrscheinlichkeit des Eintretens dieses Risikos ein. Wenn sie fertig sind, sortieren sie nach der Wahrscheinlichkeitsspalte und beginnen von oben nach unten mit der Risikominderung. Viele Risikomanagementstrategien ziehen irgendwo in der Mitte der Liste eine Linie und entscheiden, dass jedes Risikoelement unterhalb dieser Linie eine zu geringe Wahrscheinlichkeit hat, dass wir uns um dieses Risikoelement keine Sorgen machen. Wir können nicht alle möglichen Risiken im Universum mindern. Es fehlt einfach die Zeit, um alles zu verarbeiten. Also müssen wir irgendwo die Grenze ziehen.
Einer der Fehler, die ich ständig sehe, ist, dass das Risikomanagement nicht viel Zeit damit verbringt, sich auf die Auswirkungen zu konzentrieren dass dieses Risiko Realität wird. Die Tabelle muss eine ähnliche Spalte enthalten, die eine Bewertung der Auswirkungen auf das Geschäft für diesen Risikoposten enthält. Der Risikomanager muss die Tabelle auch nach dieser Spalte sortieren. Alle Elemente, die eine große Auswirkung haben, müssen Maßnahmen zur Risikominderung haben, selbst wenn das Element eine geringe Wahrscheinlichkeit hat, dass es eintritt! Leider versäumen zu viele in der Risikomanagementbranche diesen Schritt der Bewertung der Risikoauswirkungen. Auch hier wird, wenn die Tabelle nach Auswirkung auf das Geschäft sortiert wird, irgendwo eine Grenze gezogen.
Man kann feststellen, dass Risikoartikel mit einer HOHEN Wahrscheinlichkeit vorliegen eine NIEDRIGE oder sogar SEHR NIEDRIGE Auswirkung haben zum Geschäft. Ich mag Risikomanagement-Tabellen mit einer dritten Spalte, die „Wahrscheinlichkeit x Auswirkung“ enthält. Diese Spalte hilft, die Beziehung zwischen den beiden Risikokomponenten zu verstehen.
Kehren wir zu der Frage zum Datenbank-Upgrade zurück, die diesen Blog-Beitrag ausgelöst hat. Ich denke, dass jeder, der diesen Blog-Artikel liest, zustimmen sollte, dass das Upgraden einer Oracle-Datenbank ein riskantes Unterfangen ist. Es gibt so viele verschiedene Dinge, die bei einem Oracle-Datenbank-Upgrade schief gehen können. Die Wahrscheinlichkeit eines Upgrade-Fehlers ist HOCH. Zu den Elementen zur Risikominderung gehören häufig, ohne darauf beschränkt zu sein, das Üben des Upgrades an Klonen der Produktion und das Sichern der Datenbank, bevor der Upgrade-Prozess beginnt. Warum tun wir das? Nun, die Auswirkung zum Geschäft ist SEHR HOCH. Wenn wir beim Upgrade unserer Produktionsdatenbank scheitern, haben unsere Geschäftsbenutzer keinen Zugriff auf die Daten. Wir sind kein sehr guter Datenwächter, wenn wir diesen Fehler nicht überwinden können. Wenn wir das Upgrade in Nicht-Produktionsumgebungen ausreichend üben, können wir die Wahrscheinlichkeit des Risikoelements auf MITTEL reduzieren. Aber aller Wahrscheinlichkeit nach können wir diese spezifische Risikowahrscheinlichkeit nicht auf NIEDRIG reduzieren. Deshalb erstellen wir das Backup, bevor das Upgrade beginnt. Sollten immer noch Probleme auftreten, obwohl wir unser Bestes getan haben, verringern Sie die Wahrscheinlichkeit dieses Risikoelements, die Auswirkung zum Geschäft ist immer noch SEHR HOCH. Die Risikobeseitigungsstrategie des Datenbankadministrators besteht also darin, sich Notizen darüber zu machen, wo und was dazu geführt hat, dass das Upgrade fehlgeschlagen ist, und aus der Sicherung wiederherzustellen. Die Datenbank läuft und wir haben die Auswirkung beseitigt zum Geschäft. Der DBA kehrt dann zum Reißbrett zurück, um zu bestimmen, wie der Fehler behoben werden kann. Der DBA versucht, die Wahrscheinlichkeit zu reduzieren dass dieses Problem erneut auftritt, wenn sie zu einem späteren Zeitpunkt zurückkehren, um den Upgrade-Vorgang erneut durchzuführen.
Gehen wir also zurück zu dem Kommentar im OTN-Thread, wo anscheinend gesagt wurde, dass das Üben von Datenbank-Downgrades die Zeit nicht wert ist. Ich bin nicht einverstanden. Und meine Meinungsverschiedenheit hat alles mit der Auswirkung zu tun zum Geschäft. Ich stimme dem Kommentar des Posters in seiner Antwort zu.
Dem stimme ich zu 100% zu. Warum machen wir diese „gründliche Prüfung“? Es ist alles wegen der Risikominderung. Wir versuchen, die Wahrscheinlichkeit zu reduzieren dass das Upgrade zu Leistungseinbußen oder zum Abbruch der Anwendungsfunktionalität führt. Aber selbst wie dieses Poster sagte:„Es wird immer Probleme geben, die nach dem Upgrade in der Produktion auftauchen, weil es unmöglich ist, 100 % Ihrer Anwendung zu testen.“ Auch hier stimme ich zu 100% dem zu, was dieser Poster hier sagt. Aber was ist mit den Auswirkungen zum Geschäft? Dazu komme ich gleich, aber zuerst muss ich in diesem nächsten Absatz ein wenig abschweifen…
Ich habe kürzlich ein wichtiges Produktionssystem von Version 11.2.0.4 auf Version 12.1.0.2 aktualisiert. Wo ich arbeite, haben wir mehr Anwendungstests, als ich jemals in meinen anderen Jobs gesehen habe. Wir haben ein vollständiges QA-Team, das Tests für uns durchführt. Wir haben sogar ein Team, das für unsere automatisierten Testbemühungen verantwortlich ist. Wir haben automatisierte Roboter, die unseren Anwendungscode jede Nacht ausführen. Darüber hinaus haben wir eine weitere automatisierte Routine, die immer dann, wenn Benutzer Codeänderungen an Test oder Prod übertragen, eine schnelle Untersuchung kritischer Codepfade durchführt. Ich habe Entwicklungsumgebungen (mehr als 15 davon) auf 12.1.0.2 aktualisiert und dann einen Monat gewartet. Ich habe dann Test aktualisiert und 3 Wochen gewartet, bevor ich die Produktion aktualisiert habe. Vor dem Upgrade der Produktion wurden Probleme gefunden und behoben. Aber selbst nach all dem hatte ich große Probleme, als die Produktion aktualisiert wurde. Sie können meine Blog-Beiträge von Mitte Oktober bis Mitte Dezember besuchen, um einige dieser Probleme zu sehen. Ich war kurz davor, diese Datenbank herunterzustufen, aber ich habe es stattdessen geschafft, die Probleme zu lösen. Nun zurück zu dem Punkt, den ich gemacht habe…
Nach Abschluss des Upgrades wird die Datenbank für den Geschäftsbetrieb geöffnet. Anwendungsbenutzer dürfen die Anwendung jetzt verwenden. Was passiert an dieser Stelle in der Datenbank? Transaktionen! Und Transaktionen bedeuten Datenänderungen. Zu dem Zeitpunkt, an dem der DBA die Datenbank nach Abschluss eines Upgrades für geschäftliche Zwecke öffnet, treten Datenänderungen auf. Nach all dem ist das der springende Punkt der Datenbank, nicht wahr? Erfassen Sie Datenänderungen und stellen Sie die Daten den Endbenutzern der Anwendung zur Verfügung.
Was passiert also, wenn Sie mit meinem Datenbank-Upgrade in dem Boot sitzen, das ich letzten Herbst war? Ich habe Dinge getroffen, die wir in der Nichtproduktion nicht gesehen haben, selbst nach all unseren Tests. Die Auswirkung zum Geschäft war HOCH. Ich muss in der Lage sein, diese Auswirkungen auf das Geschäft zu reduzieren. Ich hatte drei Optionen. 1) Beheben Sie die Probleme nacheinander. 2) Wiederherstellung von der Sicherung, die ich vor dem Upgrade erstellt habe, damit ich die Datenbank wieder auf die alte Version bringen kann. 3) Führen Sie ein Downgrade der Datenbank durch und kehren Sie zum Zeichenbrett zurück. Ich habe mich für die erste Möglichkeit entschieden. wie ich es während meiner Karriere immer getan habe. Was aber, wenn das nicht ausreicht? Es kann einige Zeit dauern, die Probleme zu lösen. Einige Unternehmen können sich diese Art von Zeit mit diesen negativen Auswirkungen einfach nicht leisten zum Geschäft. Wie viele Websites wurden aufgegeben, weil die Leistung schlecht war oder Dinge nicht richtig funktionierten? Und für die große Mehrheit der Produktionsdatenbanken da draußen hat Option 2 sehr schreckliche Auswirkungen zum Geschäft! Sie verlieren Transaktionen, nachdem das Upgrade abgeschlossen wurde! Der DBA kann nach dem Upgrade kein Rollforward durchführen, während die Datenbank auf der alten Version bleibt, sodass Daten verloren gehen und dies für viele Produktionsdatenbanken nicht akzeptabel ist. Das Unternehmen kann sich möglicherweise eine Stunde Datenverlust leisten, aber wie viele Personen würden diese Aktion innerhalb einer Stunde nach dem Upgrade auslösen? Aller Wahrscheinlichkeit nach würde diese Aktion Tage nach dem Upgrade und den Auswirkungen durchgeführt werden für das Unternehmen für diese Art von Datenverlust ist weit über SEHR HOCH. Somit bleibt Option 3 die Option mit den geringsten Auswirkungen an das Unternehmen, um zu helfen, alle Auswirkungen zu lösen, die das Unternehmen nach dem Upgrade erfährt.
Sie können wahrscheinlich aus diesem letzten Absatz entnehmen, dass es meiner Meinung nach wichtig ist, dass der Oracle-DBA weiß, wie er seine Datenbank nach Abschluss eines Upgrades herunterstufen kann. Ich gebe zu, dass die Wahrscheinlichkeit des DBA, der ein Downgrade durchführen muss, ist SEHR NIEDRIG. Aber die Auswirkung Eine Nichtherabstufung kann für das Unternehmen katastrophal sein. (Da sind diese beiden Wörter wieder). Denn die Wahrscheinlichkeit niedrig ist, übe ich nicht oft Downgrades, aber weil die Auswirkung nicht in der Lage zu sein, herunterzustufen, ist sehr hoch, ich übe sie ab und zu.
Abschließend werde ich noch einmal auf diese Sache mit Murphy’s Law zurückkommen. Das Universum hat sich nicht gegen mich verschworen, aber als Datenwächter muss ich gute Prinzipien des Risikomanagements anwenden. Das bedeutet, die Wahrscheinlichkeit und die Auswirkungen von Risikopositionen zu bewerten, die durch meine Änderung entstehen. Während das Universum und die Götter Murphys Gesetz oder seine Cousins möglicherweise nicht in Gang setzen, tue ich mir keinen Gefallen, indem ich Risikogegenstände mindere. Ich reduziere die Wahrscheinlichkeit kein bisschen.
