Remote Listener für Oracle Standard Edition 2 Datenbanken - ein erster Überblick, Einrichtung inklusive

Auch für kleine und mittlere Unternehmen, die mit Standard Edition 2 Datenbanken von Oracle arbeiten, sind hochverfügbare Systeme häufig ein "Must Have". Die Datenbanken werden dann mit zusätzlicher Software über zwei Server abgesichert. Der bekannteste Anbieter ist sicherlich dbvisit mit ihrem Produkt "dbvisit Standby", aber auch Robotron besitzt eine eigene Alternative namens robotron*Standby.
Alle Anbieter verfahren hierbei mehr oder weniger gleich: Auf einer zweiten Umgebung wird eine Datenbank dauerhaft aus den archivierten Redo Logs recovered und somit auf einem aktuellen Stand gehalten. 

Die Applikationen bzw. Benutzer verbinden sich (inzwischen mit den pluggable) Datenbanken über einen TNSNames.ora-Eintrag, JDBC connect oder easy connect. Dabei wechselt bei einem Umschalten der Host und der Listener für die Verbindungen. Der Applikations-Datenbankservice (warum es diesen geben sollte, findet man hier) bleibt vom Namen her gleich und ist auch nur dort verfügbar, wo die primäre Datenbank läuft und read/write geöffnet ist, trotzdem gibt es einige Dinge zu beachten.

Typischerweise sehen Verbindungseinträge für solche hochverfügbaren Datenbanken dann wie folgt im TNSNames.ora aus (analog in JDBC oder mit easyconnect):

application_service_name_ha= 

 (DESCRIPTION= 
   (ADDRESS_LIST= 
     (LOAD_BALANCE=off)
     (FAILOVER=on)
        (ADDRESS=(host = proddbhost)(protocol = tcp)(port = 1521))
        (ADDRESS=(host = standbydbhost)(protocol = tcp)(port = 1521))
   )
  (CONNECT_DATA=
   (SERVICE_NAME=application_service_name.domain)
  )
 )

Da die Default-Werte nicht ausreichend sind, werden oftmals für das Failover noch weitere Parameter angegeben, z.B. TRANSPORT_CONNECT_TIMEOUT, CONNECT_TIMEOUT, RETRY_DELAY oder RETRY_COUNT.  Die Probleme, die daraus folgen, sind aber immer gleich: Man muss die Datenbank-Hosts im Connect String beide hinterlegen und das connection failover auf die andere Maschine dauert dann auch immer einen Moment, da zuerst ein Verbindungsversuch auf dem einen und dann auf dem zweiten Node durchgeführt wird. Verschärft wird diese Dauer noch durch mögliche Retry-Einstellungen.
Wer JDBC oder easyconnect Syntax benutzt, hat mit diesen komplizierten Connection Strings sowieso seine liebe Mühe. Es gibt auch einige Applikationen, in den solche Connection Strings aufgrund der Länge des Strings nicht erfasst werden können. Kunden, die Enterprise Edition Lizenzen mit Data Guard benutzen, sind an dieser Stelle über den Connection Manager (CMAN) mit einem Tool versorgt, dass eine Proxy-Funktion übernehmen kann.  Da der Connection Manager aber nur Teil der Enterprise Edition Datenbanklizenz ist, müssen sich Standard Edition 2 Kunden anderweitig behelfen. 

Eine mögliche sinnvolle Lösung sind nun die so genannten Remote Listener. Diese werden häufig auf Systemen installiert, die "sowieso" laufen müssen, damit eine Applikation funktioniert. Typischerweise sind das die Applikationsserver, Druckerserver o.ä., die für die Enduser bekannt sind und ohne die eine Applikation nicht und nur bedingt verfügbar ist. Grundsätzlich bietet sich aber jeder Server an, der selbst hochverfügbar ist.

Um einen Remote Listener nutzen zu können, wird ein Full Oracle Database Client auf diesem Server benötigt, ein Instant Client funktioniert dafür NICHT. Heruntergeladen kann der Client z.B. über https://edelivery.oracle.com/osdc/faces/SoftwareDelivery. Da die Listener mehrere Oracle-Versionen abwärtskompatibel sind, kann hier auf theoretisch auf die höchste Version zugegriffen werden. Im Normalfall wünschen die Kunden aber das gleiche Release zu verwenden, das auch für die Datenbank verwendet wird.

Für den Download kann das entsprechende Betriebssystem ausgewählt werden. Da Applikations- oder Druckerserver häufig MS Windows Umgebungen sind, wird hier im Blog auch MS Windows verwendet.

Wichtig ist: Es handelt sich hierbei bei den Downloads immer um das Base Release, darauf wird explizit auch hingewiesen: "This is the base release of Oracle Database 19c. After installing this software, download and install the latest Release Update (RU) to get the most current security and functionality. For the latest RU, go to My Oracle Support Doc ID 2118136.2 on support.oracle.com." Auch wenn das Patchen sinnvoll wäre: In diesem Post wird das Base Release zum Zeigen der Funktionaliät verwendet. 
Nach dem Download muss der Client auf dem Server als Administrator installiert werden - es benötigt Registry Einträge und es werden Dienste erstellt. Wichtig ist dabei, dass nur verwendete Komponenten ausgewählt werden können. Beim Installation Type wird deshalb "Custom" verwendet.

Vermutlich werden die meisten als Oracle Home User dann "Use Windows Built-in Account" auswählen. Die Software Location orientiert sich entweder am Oracle Standard oder es bietet sich an, ein Applikationsserver-Verzeichnis zu verwenden.

Nun kommt der entscheidende Teil: Die Auswahl der Softwarekomponenten. Es reicht aus, den "Oracle Net Listener" auszuwählen - abhängige Komponenten werden automatisch installiert.
Oftmals ist aber auf dem Applikationsserver ein SQL*Plus, SQL Developer oder ODBC-Treiber für Installation oder Update der Applikation notwendig, so dass dieses ebenfalls hier ausgewählt werden kann. Übrigens sollte sich nicht darüber gewundert werden, dass manche Komponenten, bei denen man vermuten würde, sie sind gar nicht abhängige Komponenten, trotzdem installiert werden. So ist z.B. (zumindest unter MS Windows, aber vermutlich auch bei anderen Betriebssystemen) SQL*Plus immer mitinstalliert, auch wenn es nicht ausgewählt wurde.

Ist alles ausgewählt, kann die Installation gestartet werden. 

Nach der Installation sind in MS Windows sofort folgende Dienste zu sehen:

Da nur der Listener benötigt wird, können die anderen Oracle-Dienste, die angelegt wurden, disabled oder auf manual Startup Type geändert werden. Der Listener läuft zwar nun in der Default-Konfiguration, unterstützt aber bisher keine Dienste und es kann sich auch keine Datenbank mit einem Dienst/Service registrieren. 

Damit sich eine Datenbank am Listener nun registrieren kann, muss die Listener.ora Datei angepasst werden. Diese befindet sich wie immer unter ORACLE_HOME\network\admin.
Grundsätzlich ist das weniger sicher, d.h. üblicherweise wird aus Security-Gründen die Listener-Zeile mit EXTPROC1521 entfernt. 
Nun werden zwei Parameter hinzugefügt, wobei das "LISTENER" in den Parametern für den Namen des Listeners steht (dieser kann natürlich auch anders heissen):

• VALID_NODE_CHECKING_REGISTRATION_LISTENER = ON 
• REGISTRATION_INVITED_NODES_LISTENER = (<IP-Addresses>,<HostNames>,<IP-WITH-WILDCARDS>)

Typischerweise würde also eine 2-Node-Umgebung für Hochverfügbarkeit auch beide Nodes beinhalten und die listener.ora auf dem Applikationsserver appserver1.localdomain könnte wie folgt aussehen:

# listener.ora Network Configuration File: C:\app\oracle\product\19.0.0\client_1\NETWORK\ADMIN\listener.ora
# Generated by Oracle configuration tools.

LISTENER =
  (DESCRIPTION_LIST =
    (DESCRIPTION =
      (ADDRESS = (PROTOCOL = TCP)(HOST = appserver1.localdomain)(PORT = 1521))
    )
  )
VALID_NODE_CHECKING_REGISTRATION_LISTENER = ON
REGISTRATION_INVITED_NODES_LISTENER = (server1.localdomain,server2.localdomain, 10.72.*.*)

Die IP-Wildcard-Angabe würde somit auch allen Datenbanken, die sich aus einem (zweiten) Netzwerk mit dem IP-Adressbereich 10.72.*.* registrieren würden, den Zugriff erlauben. Dies ist natürlich aus sicherheitstechnischer Sicht (least privileges) nicht wirklich sinnvoll. Besser wäre auch hier eine Angabe der richtigen DNS oder der IP-Adressen (übrigens auch IP V6), sonst wird womöglich wieder ein unnötiges Scheunentor geöffnet. Wichtig ist, dass der Remote Listener neu geladen werden muss, damit die neue Konfiguration wirksam wird (lsnrctl reload listener oder über Dienste restart). Ist dieses vorbereitet, kann nachfolgend auf der Datenbankseite der Eintrag für den Remote Listener gesetzt werden. Dieser folgt der TNSNames Logik. 
Deshalb würde der Remote-Listener-Eintrag in unserem Root Container in obigem Beispiel wie folgt lauten:

alter system set remote_listener='(ADDRESS = (PROTOCOL=TCP)(HOST=appserver1.localdomain)(PORT=1521))' scope=both;

Das nächste Bild zeigt den Status der erfolgreich registrierten Services der Datenbank am Remote Listener (der Hostname wurde aus Sicherheitsgründen unkenntlich gemacht).