Remote Listener für Oracle Standard Edition 2 Datenbanken - Vererbung beim Clonen von PDBs
Dieser Beitrag ist der dritte Teil unserer Reihe „Remote Listener für Oracle Standard Edition 2 Datenbanken“. In den ersten beiden Teilen wurde die Standardkonfiguration und die Hochverfügbarkeit näher beleuchtet. Es empfiehlt sich, diese Beiträge vorab zu lesen, da im Folgenden auf Inhalte und Konzepte daraus Bezug genommen wird.
Eine häufig gestellte Frage lautet: Was passiert mit dem Remote Listener, wenn eine pluggable Datenbank (PDB) aus einem Root-Container (CDB$ROOT) in einen anderen Root-Container geklont wird – beispielsweise von einem Produktionssystem auf eine Testdatenbank? Es könnte ziemlich problematisch sein, wenn sich die geklonte PDB am Remote Listener registriert und sich die Anwendung dadurch mit der Produktions-PDB und der Test-PDB verbindet.
Werfen wir einen genaueren Blick auf dieses Szenario: Am einfachsten ist es, eine PDB in eine CDB zu clonen, die auf einem Server läuft, der NICHT in der listener.ora-Liste der eingeladenen Knoten (REGISTRATION_INVITED_NODES_LISTENER) enthalten ist. Damit können sich weder die CDB noch die PDB am Remote Listener registrieren.
In der Praxis sieht es jedoch oft anders aus:
Gerade in Standby- oder Standard Edition High Availability (SEHA)-Umgebungen teilen sich produktive und Testdatenbanken aus Ressourcengründen häufig denselben Knoten. Es ist deshalb keine gute Idee, sich allein auf diese Listener-Einschränkung zu verlassen.
Klären wir also die Frage, was passiert mit dem REMOTE_LISTENER Parameter, wird er mit einer PDB-Kopie vererbt?
Schaut man sich den Parameter für den Remote-Listener pro Container an, so sieht man, dass die Remote-Listener-Einträge von einer PDB genau so angezeigt werden wie im Root-Container (hier wurde der Hostname des Remote-Listeners „maskiert“, ist aber identisch). Der folgende Screenshot zeigt die Parameter für Container ID 3 (die Applikations-PDB) und für Container ID 1 (den Root Container).
Was passiert, wenn diese PDB nun über einen Datenbank-Link in eine neue, leere Testdatenbank geklont wird? Die neue Test-CDB (Hier im Beispiel NRLORCL, was für No-Remote-Listener-ORCL steht, die ORCL ist die Datenbank mit Remote Listener Konfiguration) läuft parallel zur Standby-Datenbank auf demselben Server (zweiter Knoten). Das ist, wie bereits geschrieben, für viele Kunden die Standard-Konfiguration. Auf der Test-CDB befinden sich keine PDBs.
Ausserdem gibt es keinen REMOTE_LISTENER Eintrag auf der neuen NRLORCL Datenbank.
Keine Überraschung also, dass es keine applikationsspezifischen Services auf der neuen Datenbank gibt.
Zeit also, die pluggable Database aus der ORCL Datenbank in die Testdatenbank NRLORCL zu clonen (das Einrichten des Clone Benutzers und des darauf angelegten Datenbanklinks wird hier nicht weiter erläutert).
Solange die PDB nach dem Clonen geschlossen (mount-Status) bleibt, gibt es noch keine weiteren Services. Wenn die PDB das erste mal geöffnet wird, werden deren Services erstellt und können in der View cdb_services auch gefunden werden.
Der manuell für die Hochverfügbarkeit angelegte Service “JSO_APP_SERVICE” ist mit der PDB geclont und beim Öffnen der PDB auch angelegt worden. Doch läuft dieser auch (ist dieser aktiv)? Ja, wie eine Abfrage der v$active_services zeigt - denn nach dem Anlegen und Starten des Services wurde der Status mit “alter pluggable database <…> save state” festgeschrieben. Das möchte man auch erreichen, damit die Hochverfügbarkeit bei SEHA oder Standby-Datenbanken gewährleistet bleibt.
Was wäre, wenn der Parameter REMOTE_LISTENER nun zusammen mit der PDB geklont würde? Dann existieren zwei offene Datenbanken (JSOTESTPDB und JSOCLONETESTPDB), auf die die Applikation über den JSO_APP_SERVICE connected? Also auf die PDB in der Produktion und die geklonte Test-PDB?
Aber Oracle sei Dank, es ist nichts Schlimmes passiert. Der remote_listener Parameter wird nicht mit der PDB geklont und läuft somit auch nicht auf der neuen Test CDB.
Da die NRLORCL (Test-CDB) als Root-Container auch keinen Remote-Listener-Eintrag für den Remote-Listener-Host besitzt, wirkt sich ein laufender JSO_APP_SERVICE nur (aber schlimm genug!!) lokal aus. D.h., sollte die PDB JSOTESTPDB dann als Primary auf dem Standby-Knoten (das ist das gleiche System, auf dem die PDB JSOCLONEDTESTPDB in der NRLORCL läuft) betrieben werden, hätte der LOCAL LISTENER den JSO_APP_SERVICE-Dienst auf diesem Knoten zweimal registriert! Einmal für die offene primäre PDB und einmal für die geklonte PDB auf der Testdatenbank - etwas, das unbedingt vermieden werden muss! Noch schlimmer wäre, wenn die NRLORCL dieselben Remote-Listener-Parameter wie die ORCL-Datenbank besitzt (weil sie z.B. mit RMAN aus dieser geclont wurde), denn dann würde der Remote-Listener-Parameter der NRLORCL verwendet werden und die geklonte Test-PDB würde sich auch am Remote Listener registrieren. Das bedeutet, dass der Dienst auch auf dem Remote-Listener zweimal aktiv wäre - einmal für die Kombination aus primärer und Standby-Datenbank und einmal für die Testdatenbank. Für die Anwendung käme es damit zu einem heillosen Durcheinander!
Wichtige Lektion!
Alle Anwendungsdatenbankdienste werden mit einem PDB-Klon auf den neuen Server bzw. in die neue CDB verschoben. Ein SERVICE_NAME_CONVERT ist bei einem Remote-PDB-Klon mit eigenen Diensten unbedingt notwendig, da sich sonst das Original UND der Klon beim Remote-Listener anmelden, wenn ein entsprechender Remote-Listener-Parameter für die CDB gesetzt ist. Dies würde dazu führen, dass Verbindungen mal zu einer DB und mal zu der anderen aufgebaut werden. Da es beim Local-Listener keinen Eintrag benötigt, wenn der Standardport 1521 verwendet wird, kann ein vergessenes SERVICE_NAME_CONVERT auch hier zu grösseren Problemen führen. Ein Datenbankservice darf (von speziellen, gewünschten Konstellationen wie z.B. einem Real Application Cluster One Node mal abgesehen) niemals auf dem gleichen Knoten laufen. Das gilt unabhängig von einer Remote Listener Konfiguration.
Lediglich ein komplett eigenständiger Server, der nicht in der Listener.ora “invited” wurde, würde vor einem Durcheinander dieser Art schützen können, da die Services lediglich lokal und einmalig auf diesem Knoten laufen.
Kommentare
Keine Kommentare