Logo Oracle Deutschland   Application Express Community
APEX und Hochverfügbarkeit: Ein Beispiel mit Oracle Data Guard
Erscheinungsmonat APEX-Version Datenbankversion Cloud oder on Premise
Januar 2016 4.0 ab 11.2 on Premise und Cloud

Wir bedanken uns für wertvollen Input zu diesem Community Tipp bei

Je mehr APEX für unternehmenskritische Anwendungen eingesetzt wird, desto wichtiger wird die Verfügbarkeit der APEX-Installation. Da APEX in der Oracle-Datenbank läuft, können alle Hochverfügbarkeitstechnologien derselben genutzt werden. So lässt sich APEX fast ohne Veränderung in einer RAC-Datenbank betreiben (Real Application Clusters). Auch die Verwendung einer Standby-Datenbank mit Oracle Data Guard für ein APEX-System ist völlig unproblematisch. Letztere soll als Beispiel für diesen Tipp dienen, analog dazu lässt sich aber auch die Kombination von RAC und Data Guard implementieren.

Standby-Datenbank mit Oracle Data Guard: Was ist das?

Eine Standby-Datenbank soll zur Verfügung stehen, wenn die primäre Datenbank komplett ausfällt (oder Teile davon nicht zur Verfügung stehen) und diese im gegebenen Zeitfenster auch nicht durch Einspielen eines Backups wiederhergestellt werden kann. Hier wird oft von Disaster Recovery gesprochen - ein solches "Disaster" wäre beispielsweise die Zerstörung des Rechenzentrums, in dem der Datenbankserver steht. Aber auch für Umgebungen mit hohem Anspruch an die Verfügbarkeit kann ein solcher Ansatz interessant sein, um die Zeit, die zur Wiederherstellung der Datenbank aus einem Backup erforderlich ist, zu überbrücken. Es wird einfach auf die Standby-Datenbank umgeschaltet und der Betrieb läuft weiter.

Standby-Datenbanken mit Oracle Data Guard: Schematische Darstellung

Abbildung 1: Standby-Datenbanken mit Oracle Data Guard: Schematische Darstellung

Abbildung 1 zeigt das Konzept von Oracle Data Guard. Die primäre APEX-Datenbank arbeitet normal - und wie bei jeder Datenbank werden alle Transaktionen in den Online-Redolog-Dateien aufgezeichnet. Oracle Data Guard kopiert die Inhalte der Redologs nun über das Netzwerk zur Standby-Datenbank (diese kann sich im gleichen, aber durchaus auch ein einem anderen, entfernten Rechenzentrum befinden). Die Standby-Datenbank läuft nicht im Normalbetrieb, vielmehr befindet sie sich in "permanentem Recovery"; die einzelnen Redolog Einträge der der Primärseite werden dort, unmittelbar nachdem diese übermittelt wurdden, auf die Standby-Seite "angewendet". Die Standby-Datenbank wird also ständig auf den aktuellen Stand der Primärdatenbank gebracht.

Fällt die Primärdatenbank aus, so wird das permanente Recovery der Standby-Datenbank beendet und diese normal geöffnet (Failover) - die Applikationen können weiterarbeiten. Genauso kann aber auch geplant umgeschaltet werden, wenn am Primärrechner Wartungsarbeiten durchzuführen sind (Switchover).

Oracle Data Guard und APEX

Abbildung 2 zeigt, wie ein mit Oracle Data Guard abgesichertes APEX-System aussehen kann. Auf der rechten Seite befinden sich Primär- und Standby-Datenbank. Die Standby-Datenbank wird anhand der Redologs aktuell gehalten. Für APEX bedeutet das, dass nicht nur alle Änderungen in den Anwendungsdaten auf der Standby-Seite gesichert werden, auch der APEX-Session State, der bekanntlich in normalen Datenbanktabellen gehalten wird, wird so auf die Standby-Seite übertragen.

Oracle Data Guard und APEX

Abbildung 2: Oracle Data Guard und APEX

Wie immer, ist der APEX-Datenbank ein Webserver vorgeschaltet. Anstelle der älteren Varianten Oracle HTTP Server mit mod_plsql und Database Embedded Gateway ist für ein hochverfügbares System der Einsatz von Oracle Rest Data Services (ORDS), auch bekannt als APEX Listener, sehr zu empfehlen. Dieser Tipp geht im folgenden von einer ORDS-Installation aus.

Wenn man sich nun nochmals vor Augen hält, dass APEX komplett in der Datenbank abläuft, so wird auch klar, dass die Anwendung im Failover-Fall komplett von der Standby-Seite übernommen wird. Allerdings muss der APEX-Webserver ebenfalls berücksichtigt werden, denn die Browser-Anfragen müssen nach dem Failover an die Standby-Seite weitergeleitet werden; Switchover oder Failover der Datenbank haben also eine Auswirkung auf den APEX-Webserver.

Vorraussetzungen: Oracle Data Guard Setup

Eine wichtige Grundlage für die Hochverfügbarkeits-Konfiguration von Verbindungen zu einer RAC oder Data Guard Datenbank sind ein eigener Datenbank Service, Oracle Notification Server (ONS) und das damit verbundene Fast Application Notification (FAN).

Ein eigens für ORDS angelegter Datenbankservice ist deshalb wünschenswert, weil dieser Service immer nur in der aktiven, primären Datenbank gestartet wird. Im Fehlerfall wird dieser automatisch auf der Primärdatenbank beendet und auf der Standby-Seite gestartet. So verbindet sich ORDS immer zur richtigen Datenbank. Mehr Informationen zu Datenbank Services enthalten die Community Tipps Services in der Datenbank und Datenbank Services für "RAC" und "Single Instance" mit DBMS_SERVICE.

Fast Application Notification sorgt dafür, dass Connection Pools, wie der in ORDS, von den Änderungen in der Data Guard Infrastruktur zeitnah informiert werden. So können die Verbindungen zur "alten" Datenbank geschlossen und neue auf die (nun aktivierte) Standby Datenbank aufgebaut werden.Nähere Informationen dazu sind im Whitepaper Oracle Notification Client and FAN zu finden. Diese Benachrichtigungen erfolgen mit einen einfachen Publish/Subscribe Mechanismus. Die Applikation (bzw. ORDS) abonniert dabei Nachrichten vom Oracle Notification Server, kurz ONS.

Der Oracle Notification Server wird nur mit der Oracle Grid Infrasturktur Software mitgeliefert. Besteht die Umgebung aus RAC Datenbanken, so ist der ONS bereits konfiguriert und verfügbar. Reine Data Guard Umgebungen brauchen hier zumindest eine Installation von Oracle Restart, damit ONS zur Verfügung steht.

Im RAC-Cluster wird ONS automatisch gestartet - man muss nichts tun. Verwendet man dagegen Oracle Restart, so muss ONS initial wie folgt gestartet werden. 

$ srvctl enable ons
$ srvctl start ons
$ crsctl stat res -t
--------------------------------------------------------------------------------
Name              Target  State        Server                   State details
--------------------------------------------------------------------------------
ora.DATA.dg       ONLINE  ONLINE       sccloud004               STABLE
ora.LISTENER.lsnr ONLINE  ONLINE       sccloud004               STABLE
ora.asm           ONLINE  ONLINE       sccloud004               Started,STABLE
ora.ons           ONLINE  ONLINE       sccloud004               STABLE

Nach dieser einmaligen Einrichtung wird ONS künftig automatisch nach Systemstart zur Verfügung stehen. Der TCP/IP-Port, über den ONS seine Informationen sendet (und auf den sich die Clients verbinden), kann mit onsctl debug angezeigt werden. Auf diesen Port muss ORDS durch das Netzwerk zugreifen können; ggfs. muss eine Firewall angepasst werden. 

$ORACLE_HOME/bin/onsctl debug

:
======== ONS ========
           IP ADDRESS                   PORT    TIME   SEQUENCE  FLAGS
--------------------------------------- ----- -------- -------- --------
                         10.165.244.153  6200 56733840 00000012 00000008

:

Nun werden eigene Datenbank Services für APEX und ORDS angelegt. Das erfolgt zuerst auf der Primär- und dann auf der Standby Seite. Für ORDS genügt ein ganz einfacher Service ohne jegliche Erweiterung wie TAF, AQ, HA oder ähnliches. Wichtig ist aber, dass auf der Serverseite jeweils das srvctl Werkzeug aus dem ORACLE_HOME-Verzeichnis der Datenbank verwendet wird:

Zur Verbindung auf den neuen Service braucht es den richtigen Connection String. Sie können den folgenden auch zunächst mit SQL*Plus testen. 

(DESCRIPTION =
  (CONNECT_TIMEOUT = 4)(RETRY_COUNT = 20)
    (ADDRESS_LIST =
      (ADDRESS = (PROTOCOL = TCP)(HOST = primary-host)(PORT = 1521)))
    (ADDRESS_LIST =
      (ADDRESS = (PROTOCOL = TCP)(HOST = standby-host)(PORT = 1521)))      
    (CONNECT_DATA = (SERVICE_NAME = apexdb))
)

Den Parametern CONNECT_TIMEOUT und RETRY_COUNT kommt eine wichtige Bedeutung zu: Diese steuern das Verhalten, wenn der Primärserver nicht verfügbar ist. Dann würde der Client (oder ORDS) dann auf den normalen TCP/IP Timeout warten, was oft zu lange ist. Mit obigen Parametern wird der Verbindungsversuch nach 4 Sekunden abbrechen und dann wird ein neuer Versuch, zum Standby-Server, gestartet. Insgesammt finden 20 Versuche zum Aufbau einer Verbindung statt - danach wird erst ein Fehler ausgelöst.

ORDS für Oracle Notification Server patchen

Im folgenden wird beschrieben, wie ORDS so eingerichtet wird, dass es beide Seiten der Data Guard-Umgebung kennt - die Primär- und die Standby-Seite. Außerdem muss ORDS als "Benachrichtigungs-Client" die Nachrichten des ONS-Servers abonnieren. Je nachdem, welche ORDS-Version Sie nutzen, müssen Sie aber noch einen "Patch" einspielen.

Testen Sie, nachdem Sie ORDS ausgepackt haben, das Java Archiv wie folgt: 

$ jar -tf ords.war | grep ons.jar
WEB-INF/lib/ons.jar
$

Wenn die die obige grüne Ausgabe von WEB-INF/lib/ons.jar sehen, ist alles in Ordnung und Sie können im nächsten Abschnitt weitermachen. Wenn nicht, fehlt die ONS-Client-Funktionalität, die sich aber recht einfach hinzufügen lässt. Die nötige Java-Bibliothek ons.jar ist glücklicherweise im ORACLE_HOME-Verzeichnis des Datenbankservers vorhanden - sie finden Sie im Verzeichnis $ORACLE_HOME/opmn/lib/. Achten Sie aber darauf, dass diese ons.jar zur ORDS-Version passt. Wenn Sie ORDS 3.0.2 verwenden, benötigen Sie die ons.jar aus einer 12.1.0.2-Datenbank. Wenn Sie sich hier nicht sicher sind, öffnen Sie einen Service Request über MyOracle Support.

Kopieren Sie diese Datei zunächst ins gleiche Verzeichnis wie ords.war und fügen Sie sie mit dem folgenden Kommando hinzu. 

$ java -jar ords.war plugin ons.jar
INFO: The plugin jar named: /home/oracle/ords-apx-dg/ons.jar was added to or updated in /.../ords.war
$

Nun ist alles bereit und Sie können mit dem Einrichten von ORDS beginnen.

Oracle Data Guard und APEX: Setup

ORDS kann zwar auch im Standalone-Modus gestartet werden, für produktive Systeme wird das aber nicht von Oracle unterstützt - das Deployment in einen Application Server ist also nötig. Oracle unterstützt seine eigenen Java-Server Oracle Weblogic und Oracle Glassfish, zusätzlich aber auch die Open Source Variante Tomcat. Zur Installation empfiehlt sich das Durcharbeiten des ORDS Installation Guide, dort sind alle nötigen Schritte genau erläutert. Für die einzelnen Java-Container sind jeweils einzelne Kapitel enthalten.

Nach erfolgreicher Installation von ORDS befindet sich die Konfiguration der Datenbankverbindung in einer Datei (defaults.xml) im ORDS-Konfigurationsverzeichnis - wo dieses liegt, wurde beim Deployment von ORDS in den Application Server festgelegt. Der folgende Aufruf zeigt das ORDS Konfigurationsverzeichnis in der Konsole an. 

$ java -jar ords.war configdir
Dez 17, 2015 1:38:41 PM oracle.dbtools.cmdline.ModifyConfigDir execute
INFO: The config.dir value is /home/oracle/ordsconf

$

Das Konfigurationsverzeichnis hat folgende Struktur: 

+ords/
  |
  +-defaults.xml
  +-url-mapping.xml
  |
  +conf/
    |      
    +-apex.xml
    +-apex_al.xml
    +-apex_rt.xml
    |
    ...
    +-(db-name).xml
    +-(db-name)_al.xml
    +-(db-name)_rt.xml

Die Datei defaults.xml im Unterverzeichnis ords enthält alle globalen Einstellungen; was dort konfiguriert ist, gilt für alle Datenbankverbindungen, die ORDS verwaltet (ein ORDS kann auch den Zugang zu mehreren APEX-Instanzen bereitstellen).

Das Unterverzeichnis conf enthält dann Dateien mit Einstellungen für einzelne APEX-Instanzen. Die Angaben zur ersten konfigurierten APEX-Instanz sind in der Datei apex.xml enthalten; wenn weitere Datenbanken eingerichtet werden, findet sich eine XML-Datei für jede Datenbank. Die Dateien mit den Endungen _al und _rt sind nur dann vorhanden, wenn REST-Webservices für die APEX-Instanz aktiviert wurden. Wenn der ORDS nur für eine einzige APEX-Instanz arbeitet, so sind dort nur die apex*.xml Dateien vorhanden.

Die Konfigurationsdateien enthalten Daten in folgendem Format - der Auszug ist aus der Datei defaults.xml - die Verbindungspezifischen Dateien enthalten (logischerweise) weniger Einstellungen. 

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE properties SYSTEM "http://java.sun.com/dtd/properties.dtd">
<properties>
<comment>Saved on Thu Sep 10 14:10:16 CEST 2015</comment>
  <entry key="cache.caching">false</entry>
  :
  <entry key="db.hostname">primary-host</entry>
  <entry key="db.port">1521</entry>
  <entry key="db.servicename">apexdb</entry>
  <entry key="debug.debugger">false</entry>
  <entry key="debug.printDebugToScreen">true</entry>
  :
  <entry key="security.maxEntries">2000</entry>
</properties>

Nun geht es daran, die Data Guard Infrastruktur in der ORDS-Konfiguration bekannt zu machen. Die Datenbankverbindung, mit der ORDS arbeitet, ist eine JDBC-Verbindung. JDBC ist grundsätzlich in der Lage, mit hochverfügbaren Umgebungen zu arbeiten.

Wie man sehen kann, sind in der Datei defaults.xml drei Einstellungen enthalten, die sich auf die Datenbankverbindung beziehen: db.hostname, db.port und db.servicename. Damit kann aber keine Standby-Datenbank angesprochen werden - das muss also geändert werden. Löschen Sie diese drei Zeilen oder kommentieren Sie mit <!-- und --> aus. und nehmen Sie die folgenden drei Parameter hinzu: db.connectionType, db.customURL, jdbc.enableONS und jdbc.ONSConfig. 

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE properties SYSTEM "http://java.sun.com/dtd/properties.dtd">
<properties>
<comment>Saved on Thu Sep 10 14:10:16 CEST 2015</comment>
  :
  <entry key="db.connectionType">customurl</entry>
  <entry key="db.customURL">jdbc:oracle:thin:@{TNS Connection-String}</entry>
  <entry key="jdbc.enableONS">true</entry>
  <entry key="jdbc.ONSConfig">{ONS Nodes}</entry>
  
</properties>

In der Datei defaults.xml sieht das dann wie folgt aus: 

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE properties SYSTEM "http://java.sun.com/dtd/properties.dtd">
<properties>
<comment>Saved on Thu Sep 10 14:10:16 CEST 2015</comment>
  :
  <entry key="db.connectionType">customurl</entry>
  <entry key="db.customURL">jdbc:oracle:thin:@(DESCRIPTION=(CONNECT_TIMEOUT=4)(RETRY_COUNT=20)(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST = primary-host)(PORT=1521)))(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=standby-host)(PORT=1521)))(CONNECT_DATA=(SERVICE_NAME=apexdb)))</entry>
  <entry key="jdbc.enableONS">true</entry>
  <entry key="jdbc.ONSConfig">nodes=primary-host:6200,standby-host:6200</entry>
 
  :
</properties>

Und damit sind Sie fertig. Starten Sie ORDS und prüfen Sie die APEX-Verbindung. Wenn nun das Failover auf die Standby-Seite erfolgt, wird ORDS seine Datenbankverbindungen selbstständig und ohne weiteres Zutun wechseln. Da der APEX-Session State komplett in der Datenbank (in Tabellen) gehalten wird, werden auch APEX-Sitzungen 1:1 übernommen.

Wenn Sie den Setup testen möchten, machen Sie das am besten gemeinsam mit dem Datenbankadministrator. Hier sei nur erwähnt, dass das Data Guard Kommandozeilenwerkzeug DGMGRL das Switchover-Kommando anbietet, das wie folgt verwendet wird. 

DGMGRL> CONNECT SYS/{password}@{primary-database}
DGMGRL> show configuration verbose

DGMGRL> SWITCHOVER TO {standby database name};

Nähere Informationen finden sich in der Dokumentation: Overview of Switchover and Failover.

Zurück zur Community-Seite