Remote Listener für Oracle Standard Edition 2 Datenbanken - Hochverfügbarkeit

Wie bereits im ersten Blog Eintrag zum Thema Remote Listener und Standard Edition 2 Datenbanken beschrieben, ist eines der Ziele beim Remote Listener, eine Vereinfachung bei Verbindungen in Bezug auf Hochverfügbarkeit zu erreichen. 

Kurze Rekapitulation:
Es existiert eine Datenbank (aus Einfachheitsgründen im folgenden ORCL) als Primary-Standby-Kombination auf zwei Nodes (es würde aber auch mit Standard Edition High Availability (SEHA) so funktionieren). Auf einem dritten Host läuft der konfigurierte Remote Listener. Die beiden Datenbanken, sowie die darin enthaltene Pluggable Database (PDB) registrieren ihre Services automatisch am Remote Listener (mögliche Konfiguration siehe Blog Post “Konfiguration”). Die in der ORCL Datenbank befindliche PDB heißt jsotestpdb und besitzt noch keinen eigenen Service für die Applikation. Da die Verwendung eines eigenen Applikationsservices aber grundsätzlich sinnvoll ist, wird ein Service mit dem Namen JSO_APP_SERVICE erstellt. Dieser ermöglicht dann die Verbindung über den Remote Listener für die Applikation, während der Default Service der PDB für Administrationszwecke reserviert bleibt. 

Auf der primären Datenbank (innerhalb der PDB) kann ein solcher Service mit der folgenden Syntax erstellt und gestartet werden:

exec dbms_service.create_service('JSO_APP_SERVICE','JSO_APP_SERVICE');
exec dbms_service.start_service ('JSO_APP_SERVICE');

Da es aus Hochverfügbarkeitsgründen sinnvoll ist, dass bei einem Switchover dieser Service automatisch auch mit gestartet wird, muss nach dem Starten des Applikationsservices entweder ein "SAVE STATE" der PDB durchgeführt werden oder es wird ein Trigger erstellt, der diesen Service beim Öffnen der PDB startet (dritte Möglichkeit wäre ein Service in der Grid Infrastruktur, sofern vorhanden, z.B. bei SEHA). Da Services nur gestartet werden, wenn die PDB auch geöffnet wird, ist sichergestellt, dass auf der Standby-Seite dieser Service niemals gestartet ist.
Die einfachste Methode ist sicher das save state, das mit nur einem Befehl ausgeführt werden kann.

alter pluggable database jsotestpdb save state;

Auf Seiten des Remote Listeners, wurde nun der JSO_APP_SERVICE ebenfalls registriert. Alle Services im Überblick (der Hostname des Remote Listeners wurde aus Diskretionsgründen entfernt):

Wichtig dabei ist, dass beide Root Container (also die primäre und die Standby-Datenbank im Mount Status) am Listener registriert sind (Ausschnitt aus vorherigem Bild mit Markierung). Damit ist sichergestellt, dass auf beiden Nodes die Remote Listener Konfiguration stimmt. 

Ebenfalls hervorgehoben, der Applikationsservice der PDB, der neu angelegt wurde (und derzeit in der ORCL auf dem primären Node 1 aktiv ist - siehe auch View gv$active_services). 

Im TNSNames.ora wird nun ein Eintrag erstellt, der als HOST den Namen des Remote-Listener Hosts trägt und sich an den Applikationsservice verbindet (der Hostname des Remote Listeners wurde aus Diskretionsgründen entfernt). Es müssen also keine zwei Nodes und keine Failover-Syntax eingetragen werden.

Wird nach dem erfolgreichen Connect über den neuen TNSNames-Eintrag der Hostname selektiert, sieht man, dass die aktuelle Session erwartungsgemäß auf dem Wintest-1 Node gelandet ist – denn hier läuft die Primary, während auf dem Wintest-2 Node die Standby Datenbank im Mount Status läuft.

Nun kann der Switchover der Datenbank mittels Bordmitteln der verwendeten Standby-Software (oder einem SEHA switchover) durchgeführt werden. Sobald die PDB auf dem neuen Host geöffnet wurde, kann man sich wieder über den Remote Listener dorthin connecten und den Host abfragen. Aktuell befindet man sich mit dem Service und der PDB aktiv auf dem Node Wintest-2 – und wird auch dahin über den Remote Listener verbunden.