Die Oracle System Change Number

Transkript

1 März 2012 Seite 1 von 5 Die Oracle System Change Number die Mayas und die Arche Noah Fakt ist, dass der Maya-Kalender am 21. Dezember 2012 endet. Dass die Welt an diesem Tag untergeht, glauben die wenigsten von uns. Und doch ergeben sich Parallelen zum kürzlich aufgetauchten Problem mit der System Change Number (SCN) der Oracle-Datenbank. Die SCN ist eine fortlaufende Nummer, die den eindeutigen Zustand einer Oracle-Datenbank repräsentiert. Sie wird zum Beispiel beim Abschluss einer jeden Transaktion, aber nicht nur da, hochgezählt. Die SCN also ist so etwas wie die innere Uhr der Oracle-Datenbank. Das Hardlimit wird durch eine 48-Bit-Zahl repräsentiert und stellt aktuell kein Problem dar. Zusätzlich gibt es ein Softlimit, das als Schutzmechanismus implementiert wurde. Und genau dieses Softlimit ist das Problem. Die Datenbank stürzt mit dem folgenden Fehler ab: ORA-00600: internal error code, arguments: [2252], [3338], [ ], [3338], [ ], [ ], [ ], [ ], [ ], [ ], [ ], [ ]... Instance terminated by DBW1, pid = Wird das Softlimit erreicht, dann stürzt die Oracle-Datenbank ab. Wir konnten die Situation im Laboratorium nachvollziehen. Der Bereich zwischen der aktuellen SCN und dem Softlimit wird als SCN Headroom bezeichnet. Es ist also der Sicherheitspuffer für das Wachstum der SCN. Das Fatale an der Situation ist, dass der SCN Headroom standardmäßig nicht überwacht wird und der Absturz der Datenbank völlig unerwartet kommen kann. Im Vergleich zum Maya-Kalender ergibt sich also eine umgekehrte Situation. Während wir das Ende des Maya-Kalenders kennen und wissen, dass die Welt an diesem Tag nicht untergehen wird, kennen wir das Ende des SCN Headrooms nicht, wissen aber, dass die Datenbank mit Sicherheit abstürzen wird. Das sind Szenarien, die jedem Verantwortlichen Kopfzerbrechen bereiten und unruhige Zeiten versprechen. Was ist zu tun, wie sollte man sich vorbereiten?

2 März 2012 Seite 2 von 5 Technische Details Was empfiehlt Oracle in dieser Situation? Zunächst ein paar technische Details: Das SCN Softlimit berechnet sich aus einer Vergrößerung pro Sekunde um den Wert seit dem Das Softlimit wächst also im Sekundentakt, aber für manche Datenbanken offensichtlich nicht mehr schnell genug. Obwohl dieser Wert wahrscheinlich für einen Großteil aller Datenbanken immer noch ausreichend sein sollte, gilt es jedoch, das individuelle Risiko umgehend herauszufinden, um eventuell Gegenmaßnahmen treffen zu können. Das Problem ist bei Oracle bereits bekannt. Der Oracle- Support unterstützt viele Kunden direkt. Oracle empfiehlt daneben die Überwachung des SCN Headrooms sowie das Einspielen des Security-Patches PSU Januar 2012 (auch als quartalsweiser Security-Patch bekannt). Für die Überwachung des Headrooms hat Oracle ein Skript namens scnhealthcheck.sql zur Verfügung gestellt. Als Ergebnis gibt es drei Kategorien A, B und C mit einer Bandbreite von Alles in Ordnung bis Oracle-Support sofort kontaktieren. Beim Einsatz des Skriptes ist zu beachten: Es liefert ein Ergebnis basierend auf dem aktuellen Wert der SCN und des Softlimits, berücksichtigt aber in keiner Weise das bisherige Wachstum der SCN. Ein verbessertes Skript finden Sie weiter unten. Erreichen des Softlimits Dafür kann es folgende Ursachen geben: Software-Fehler führen dazu, dass es zu einem größeren Verbrauch der aktuellen SCN kommen kann. Ein bekannter Bug wird von den Befehlen ALTER DATABASE BEGIN BACKUP und ALTER DATABASE END BACKUP verursacht. Sind zwei oder mehrere Datenbanken über einen Datenbank-Link miteinander verbunden, dann synchronisiert sich bei Benutzung die aktuelle SCN auf den höchsten Wert über alle Datenbanken. Leistungsfähige Hardware und transaktionsintensive Datenbanken haben dazu geführt, dass das lineare Wachstum des Softlimits um pro Sekunde um ein Vielfaches überschritten werden kann.

3 März 2012 Seite 3 von 5 Mit Hilfe von Patchen versucht Oracle dem Problem kurzfristig Herr zu werden. Es werden bekannte Bugs, die einen extremen Verbrauch der SCN verursachen, beseitigt. Offene Fragen Aus unserer Sicht stellen diese Maßnahmen keine vollständige Lösung des Problems dar und lassen noch folgende Fragen offen: Wurden wirkliche alle Fehler, die einen extremen Verbrauch der SCN verursachen, durch Einspielen der Patches gefixt? Wie lässt sich der SCN Headroom überwachen, um noch genügend Zeit für Gegenmaßnahmen zu haben? Was ist mit älteren Versionen, für die keine Patches zur Verfügung stehen? Welche Maßnahmen sollten sofort ergriffen werden? Hier kommt die Arche Noah ins Spiel. Um eine wirkliche Kontrolle über das potentielle Problem zu erlangen, empfehlen wir eine Reihe von Sofortmaßnahmen. Empfohlene Sofortmaßnahmen Obwohl es aktuell keinen Grund zur Panik gibt, sollten Sie Ihre Arche dennoch vor einer möglichen Flutwelle fertigstellen. Das Wichtigste ist, einen Überblick zu erlangen, welchen aktuellen SCN-Stand alle Ihre Datenbanken im Moment haben. Dadurch finden Sie heraus, welche Datenbanken gefährdet sind. Erstellen Sie eine Liste nach Versionen, da die Lösungen für ältere Versionen aufwendig oder nicht möglich sein können. Erstellen Sie einen Patchplan für das Einspielen des Patches PSU Januar 2012 und einen Upgradeplan für die Versionen, für die kein Patch zur Verfügung steht. Überwachen Sie permanent den SCN Headroom für alle Datenbanken. Neben der Größe des Headrooms sollte das Wachstum der aktuellen SCN berücksichtigt werden. Überprüfen und reduzieren Sie Datenbank-Links, da sich das Problem über Datenbank-Links ausweitet. Durch Angleichung an die höchste SCN kann auch ein Verbrauch von mehreren Milliarden, zum Teil Billionen, auftreten. Identifizieren Sie den SCN-Verbrauch Ihrer Datenbanken durch Blick in die Vergangenheit (z. B. v$log_history). Denken Sie auch an die Zukunft: Das Wachstum kann mit der Verarbeitungsgeschwindigkeit der Systeme steigen.

4 März 2012 Seite 4 von 5 Mit den folgenden SQL-Skripten erlangen Sie erste Informationen zur SCN-Situation in Ihren Datenbanken: Abfrage der aktuellen SCN sowie des Softlimits: SQL> COL current_scn FORMAT SQL> COL softlimit FORMAT SQL> SELECT 2 dbms_flashback.get_system_change_number current_scn, 3 (( 4 ((to_number(to_char(sysdate,'yyyy'))-1988)*12*31*24*60*60) + 5 ((to_number(to_char(sysdate,'mm'))-1)*31*24*60*60) + 6 (((to_number(to_char(sysdate,'dd'))-1))*24*60*60) + 7 (to_number(to_char(sysdate,'hh24'))*60*60) + 8 (to_number(to_char(sysdate,'mi'))*60) + 9 (to_number(to_char(sysdate,'ss'))) 10 ) * (16*1024)) softlimit 11 FROM v$instance; CURRENT_SCN SOFTLIMIT Überwachung der SCN-Verbrauchsrate und Feststellen von ungewöhnlichem Wachstum: WITH t1 AS( SELECT time_dp, 24*60*60*(time_dp - lag(time_dp) OVER (order by time_dp)) timediff, scn - lag(scn) OVER(order by time_dp) scndiff FROM smon_scn_time ) SELECT time_dp, timediff, scndiff, trunc(scndiff/timediff) rate_per_sec FROM t1 ORDER by 1; TIME_DP TIMEDIFF SCNDIFF RATE_PER_SEC :52: :02: ,4336E+13 2,3159E :07: :16: :21: :26: Instance terminated by DBW1, pid = 15437

5 März 2012 Seite 5 von 5 Und wenn es doch passiert? Wie bereits erwähnt, haben wir die Situation des Erreichens des SCN Softlimits im Normalbetrieb in einem Feldversuch nachgestellt. Es erfolgt ein Crash der Instanz mit dem Fehler ORA- 600 [2252]. Danach kann die Instanz wieder gestartet werden, da sich das Softlimit inzwischen vergrößert hat. Es wird ein Crash Recovery durchgeführt und die Datenbank sollte sich wieder in einem konsistenten Zustand befinden (Hierfür können wir keine Gewähr bieten). Es gibt kein Verfahren, um die aktuelle SCN in einer Datenbank zu verkleinern. Eine Möglichkeit ist der Aufbau einer neuen Datenbank mit anschließender Datenübernahme mittels Export aus der bestehenden und Import in die neue Datenbank, ein meist sehr zeitraubendes Verfahren mit langer Unterbrechung der Produktion. Es schadet also nicht, auf eine solche Situation vorbereitet zu sein. Haben Sie weitere Fragen? Wir beraten Sie gerne: [email protected] Impressum Datum: März 2012 Version: 2 Autor: avato Kontakt: [email protected] avato consulting