Datenverlust durch Datenbank Services

In einem meiner Projekte hatten wir kürzlich einen GAU: eine Anwendung hatte sich gegen zwei Datenbanken verbunden und somit abwechselnd Änderungen in beiden Datenbank durchführt.
Aber wie kann das sein? Warum gibt es zwei Datenbanken? Warum ist es überhaupt möglich, sich an zwei Datenbanken anzumelden – das geht doch gar nicht!

DOCH ES GEHT!
Hintergrund dieser Geschichte ist folgendes:
Aufgrund einer fehlerhaften Verarbeitung sollte ein älterer Stand einer Pluggable Database geprüft werden. Das ist in dem Projekt auch kein Problem, weil wir NetApp als Storage-Lösung einsetzen und SnapCenter für die Backups. Das schöne an dieser Lösung ist, dass man innerhalb von wenigen Minuten einen Klon jeder beliebigen Datenbankgröße auf jedem beliebigen Zeitpunkt erstellen kann.
In dem Beispiel bedeutet dies, dass ein Kollege einen Klon der produktiven Datenbank auf den Zeitpunkt Freitag 17:00 Uhr erstellt hat. Natürlich auf dem selben Server, weil wir keine Daten über Stages (Test, VPROD, PROD) hinweg verarbeiten dürfen.
Er hat dann die Datenbank, wie gewünscht, zum Lesen und Schreiben geöffnet, um daraus einen Data Pump Export zu erstellen. Wie so oft, ging der erste Export schief (ORA-01555 „Snapshot Too Old“) und man beschloss, am Montag einen weiteren Versuch zu starten.
Aber Keiner hatte mitbekommen, dass ab der Version 12.2 beim Öffnen einer Datenbank (NON-CDB, CDB oder PDB ist egal) automatisch auch alle (!) Services gestartet werden.

Kleine Anmerkung: bei der PDB werden die Services gestartet, die vor dem letzten „SAVE STATE“ angelegt wurden.

Die Services haben sich dann, „works as designed“ beim Listener registriert. Daraus folgt, dass es dadurch Services gab, die sich gegen zwei Instanzen unterschiedlicher (!) Datenbanken angemeldet haben. Sobald jetzt eine Anwendung den Connect zur Datenbank herstellt, wird er einmal zur produktiven Datenbank und einmal zum Klon verbunden.

Der Datenverlust

In diesem Fall fiel der Fehler erst am Dienstag auf, d.h. 5 Tage Datenverlust, weil natürlich die Reihenfolge der Transaktionen nicht wieder hergestellt werden konnte.
In der Vergangenheit hatten wir in dem Projekt schon häufiger Klones erstellt, aber der Fehler war bisher noch nicht aufgefallen, weil bei der Version 12.1 die Services nicht automatisch gestartet werden.

Lösung

Leider gibt es für diesen Fehler keine Lösung. Ein von mir geöffneter SR wurde von Oracle Support geschlossen, weil der Listener Services von mehreren Instanzen akzeptieren soll (Works as designed).

Warnung

Also bitte, äußerste Vorsicht beim Klonen von Datenbanken. Das Problem existiert allerdings generell, wenn man mehr als eine Datenbank auf einem Server bzw. mit nur einem Listener betreibt. Gerade im Bereich Multitenant Database kann es leicht passieren, dass Services doppelt erstellt werden. Innerhalb der selben Datenbank lassen sie sich nicht starten. In unterschiedlichen Datenbanken aber schon. Allerdings ist hier der Unterschied, dass sich der selbe User in beiden Datenbanken mit dem selben Passwort anmelden könnten muss und die Objekte identisch sind (wie eben beim Kloning).

Beispiel:

oracle@server1[MX011]% srvctl add service -db MX01 -pdb jospdb -service jo_demo -preferred MX011 -available MX012
oracle@server1[MX011]% srvctl start service -db MX01 -service jo_demo
oracle@server1[MX011]% srvctl add service -db MX02 -pdb joszweitepdb -service jo_demo -preferred MX021 -available MX022
oracle@server1[MX011]% srvctl start service -db MX02 -pdb joszweitepdb
oracle@server1[MX011]% lsnrctl status |grep -A2 jo_demo
Service "jo_demo" has 2 instance(s).
   Instance "MX011", status READY, has 1 handler(s) for this service…
   Instance "MX021", status READY, has 1 handler(s) for this service…

Von Oracle wüsste ich allerdings gerne, warum es möglich ist, sich mit einem Service an zwei unterschiedlichen Datenbanken anzumelden. Mir erschließt sich dieses „Feature“ nicht.

Vorschlag für’s Klonen

  1. Schalten Sie vor dem Öffnen der Datenbank kurz den Listener aus.
  2. Stoppen Sie nach dem Öffnen der Datenbank die Services.
  3. Starten Sie dann den Listener.

Wie man an dieser Vorgehensweise erkennt, ist es unerlässlich, den Default Service (Name der Datenbank) nicht zu verwenden, weil man den nicht stoppen kann. Also hat der Fehler wenigstens ein Gutes: er gibt ein Beispiel ab, warum man keine Standard Services benutzen soll.

Die beste Methode ist natürlich, den Klon auf einem anderen Server (nicht produktiv) zu erstellen. Aber, wie bereits gesagt: das ist nicht immer erlaubt.

Fazit

Vorsicht beim Klonen von Datenbanken. Das kann böse Folgen haben!

Nachtrag

Vorsicht bei Multitenant Database: Wenn man eine PDB öffnet, wird der Listener automatisch wieder gestartet.

Kommentar verfassen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Nach oben scrollen