Oracle SE2 im Cluster – Es geht auch ohne RAC!

By | 12. Mai 2019

Die Nutzung der kostenfreien RAC-Option in der Standard Edition war in den Datenbankversion 11g -18c eine schöne und preiswerte Möglichkeit seine Datenbanken gegen einen Serverausfall zu schützen. Da diese Option in dem 19c Release der Oracle Standard Edition 2 (SE2) nicht mehr verfügbar ist, werden viele Anwender nach einer Alternative suchen. Nicht jeder ist bereit auf die teurere Enterprise Edition umzusteigen und zusätzlich noch die RAC-Option zu lizenzieren.

Oracle Cluster

Vor ein paar Jahren habe ich in meinem Blog das HA-Konzept „Oracle Single Instance Failover Cluster Extended Distance“ vorgestellt (nachzuesen hier).
Mit dem jüngsten Wegfall der RAC-Option SE2 ist dieses Verfahren nun aktueller den je und möglicherweise ein guter Ersatz, wenn man einige Einschränkungen in Kauf nimmt.

Grund genug also eine aktuelles Update meines Blogartikels abzuliefern, um einmal die Implementierung mit der aktuellen Grid Infrastruktur 19c zu zeigen.

Bei einem Single Instance Failover Cluster wird eine Datenbank nicht als RAC-Datenbank, mit je einer Instanz pro Knoten (aktiv-aktiv), sondern als Single-Instance-Datenbank auf einem der beiden Server betrieben (aktiv-passiv). Kernstück ist nach wie vor die Oracle Clusterware, die dafür sorgt, dass eine von einem Serverausfall betroffene Datenbank auf dem überlebenden Server gestartet wird. Die Datenbank wird dabei nicht als Oracle Datenbank-Ressource, wie sonst bei RAC üblich, sondern als selbstdefinierte Cluster-Ressource in der Clusterware angelegt. Die von der Clusterware durchzuführenden Start- und Stopp-Aktionen werden über ein selbst zu erstellendes Action-Script gesteuert, welches von der Clusterware aufgerufen wird.

Single Instance Failover Cluster

Insbesondere beim Betrieb von mehreren Datenbanken, ergibt diese Lösung Sinn, da man die Datenbanken dann auf beiden Server verteilen kann und somit die vorhandenen Ressourcen des zweiten Servers nicht brach liegen.

Architekturbedingt gibt es natürlich einige Vor- und Nachteile, die man bewerten sollte, wenn man den Betrieb eines Oracle Single Instance Failover Clusters plant.

Nachteile gegenüber RAC:

  • Aufbau und Betrieb erfordert mehr Know-How.
  • Keine Skalierung der Last auf mehrere Knoten möglich.
  • Ein Failover einer Datenbankinstanz ist nicht unterbrechungsfrei. Kurzer Ausfall des Datenbankservices notwendig.
  • Keine Online-Verschiebung einer Datenbankinstanz möglich
  • Keine Failover-Integration im Enterprise Manager vorhanden.
  • Oracle Homes müssen auf jedem Server separat gepatched werden.

Vorteile gegenüber eines RAC:

  • Für alle Editionen einsetzbar!
  • Bei SE2: 2-Socket Server verwendbar (statt nur 1-Socket Server).
  • Kein breitbandiger Interconnect notwendig, da kein Cache Fusion genutzt wird.

Wie man eine Datenbank als Single Instance Datenbank in einem Failover Cluster erstellt und was dabei zu beachten ist, möchte ich nachfolgend  anhand eines Installationsbeispiels auf zwei Linux Servern zeigen. Bei der Erläuterung konzentriere ich mich in erster Linie auf den Teil, der von einer RAC-Installation und -konfiguration abweicht. Eine Beschreibung der Installation der Grid Infrastruktir (Clusterware + ASM) ist nicht Bestandteil.

In meinem Beispiel wurde die Grid Infrastruktur 19c  bereits installiert und die beiden Linux Server wurden entsprechend dem Oracle Installation Guide für das Setup der Datenbanksoftware und der Grid Infrastruktursoftware vorbereitet. Die Installation der Grid Infrastruktur unterscheidet sich hier nicht zu einer herkömmlichen RAC-Installation. Abweichend davon muss allerdings die Oracle Datenbanksoftware für eine Single Instance Datenbankinstallation auf beiden Servern mit dem Oracle Installer installiert werden.

Beispiel-Cluster:

Server 1: ora-c-srv1.example.de
Server 2: ora-c-srv2.example.de
VIP Server 1:  ora-c-srv1-vip.example.de
VIP Server 2:  ora-c-srv2-vip.example.de
SCAN-Name:  ora-c-scan.example.de
Datenbankname:  MYDB
Owner Grid Software:  grid
GRID_HOME:  /u01/app/19/grid
Owner Datenbank Software: oracle
ORACLE_HOME:/u01/app/oracle/product/19/dbhome_1

1. Datenbanksoftware 19c auf dem 1. Server installieren

Beim Setup der Datenbanksoftware ist zu beachten, dass „Set Up Software Only“ und „Single Instance Database Installation“ ausgewählt wird.

Installation Datenbanksoftware 19c

Installation Datenbanksoftware 19c

2. Datenbanksoftware 19c auf dem 2. Server installieren

Analog zur ersten Installation die Oracle Software ebenfalls auf dem 2. Server installieren.

3. Non-RAC Datenbank erstellen

Die Datenbank wird auf dem 1. Server mit dem Database Creation Assistant (dbca) erstellt. Hierbei muss „Advanced Installation“ ausgewählt werden, um im darauffolgenden Schritt den Datenbank-Typ „Oracle Single Instance database“ wählen zu können.

Erstellung Datenbank 19cErstellung Datenbank 19c

Die nachfolgenden Konfigurationseinstellungen der Datenbank erfolgen individuell nach eigenem Bedarf.

Die Datenbank wird als Ergebnis des Installationsprozesses in der Clusterware als „Oracle Restart“-Ressource angelegt. Diese Art von Datenbank-Ressource ist jedoch auf den Server beschränkt auf dem sie angelegt wurde und kann aus diesem Grund nicht für ein Failover verwendet werden!  Im nachfolgenden Teil wird diese entfernt und stattdessen eine eigene Cluster-Ressource erstellt, die auf beiden Cluster-Knoten lauffähig ist.

4. Datei /etc/oratab kopieren

Die Datei /etc/oratab muss nach dem Anlegen der Datenbank auf den zweiten Server kopiert werden, damit auf beiden Servern ein entsprechender Eintrag für die Datenbank vorhanden ist.

/etc/oratab

MYDB:/u01/app/oracle/product/19/dbhome_1:N

5. ASM-Alias für Spfile anlegen

Ich verwende in meinem Beispiel Oracle ASM als Shared Storage. Das Server Parameter File (Spfile) liegt in dem Fall in einer ASM Diskgroup. Der  angelegten „Oracle Restart“-Datenbank fehlt jedoch ein Alias für das Spfile. Durch die Verwendung eines Aliases wird die Verwaltung jedoch insgesamt einfacher, da dann mit einem sprechenderem Namen (spfile<sid>.ora) gearbeitet werden kann.

Umgebungsvariablen setzen:

export ORACLE_SID=MYDB
export ORACLE_HOME=/u01/app/oracle/product/19/dbhome_1
export PATH=$ORACLE_HOME/bin:$PATH

Ermittlung des aktuellen Pfad des Server Parameter Files:

sqlplus / as sysdba
SQL> select value from v$parameter where name = 'spfile':
VALUE
----------------------------------------------------------
+DATA/MYDB/PARAMETERFILE/spfile.276.1007733169

Anlegen eines Aliases für das Spfile mit Hilfe des zuvor ermittelten Pfades:

SQL> alter diskgroup DATA add alias '+DATA/MYDB/spfileMYDB.ora' for '+DATA/MYDB/PARAMETERFILE/spfile.276.1007733169';

6. Referenzierendes Parameterfile anlegen

Auf beiden Servern muss ein Parameterfile in Textform angelegt werden, welches auf den zuvor angelegten Spfile-Alias verweist, damit die Datenbank in die Lage versetzt wird, auf beiden Severn starten zu können.

/u01/app/oracle/product/19/dbhome_1/dbs/initMYDB.ora

SPFILE='+DATA/MYDB/spfileMYDB.ora'

7. REMOTE-Listener Parameter setzen

Normalerweise sollte der Parameter REMOTE_LISTENER, welcher auf den SCAN referenziert, bereits gesetzt sein.

Sollte diese nicht der Fall sein, so muss man dies nachholen:

SQL> alter system set remote_listener='ora-c-scan.example.de:1521' scope=both;

8. LOCAL-Listener Parameter löschen

Die Registrierung des Datenbank-Services an den lokalen Listener muss erst beim Start der Datenbank, in Abhängigkeit vom Server auf dem die Datenbank gestartet wird, erfolgen. Aus diesem Grund sollte man sicherstellen, dass der Parameter LOCAL_LISTENER nicht gesetzt ist und diesen ggf. löschen.

SQL> alter system reset local_listener scope=spfile;

9. Datenbank stoppen

SQL> shutdown immediate
SQL> exit

10. Datenbank-Ressource löschen

Mit folgendem Befehl wird die „Oracle Restart“-Ressource für die Datenbank aus der Clusterware entfernt.

srvctl remove database -d MYDB

11. Action-Script erstellen

Damit die Clusterware in der Lage ist die Datenbank zu starten, zu stoppen und den Status zu ermitteln, kann man ihr unter anderem ein sogenanntes Action-Script bereitstellen, welches diese Aufgaben übernimmt und welches von der Clusterware aufgerufen wird. Das Action-Script muss die Funktionsblöcke „start“, „stop“, „clean“ und „check“ enthalten und diese den Rückgabewert 0 oder 1 liefern.

Wichtig: Das Script muss auf beiden Server im gleichen Pfad verfügbar sein.

Erstellung eines Verzeichnisses auf beiden Servern als User oracle:

mkdir -p /u01/app/oracle/action_scripts

Anlegen des Action-Scripts auf beiden Servern als User oracle:

/u01/app/oracle/action_scripts/action_mydb.sh

Beispiel eines einfachen Action-Scripts:

#!/bin/sh
###################################################################################
# Purpose: Oracle Clusterware Action Script Database MYDB
# Script: /u01/app/oracle/action_scripts/action_mydb.sh
# Logfile: $ORACLE_BASE/diag/crs/<server>/crs/trace/crsd_scriptagent_oracle.trc
###################################################################################

export ORACLE_SID=MYDB
export ORACLE_HOME=/u01/app/oracle/product/19/dbhome_1
export PATH=$ORACLE_HOME/bin:$ORACLE_HOME/OPatch:$PATH
export GRID_HOME=/u01/app/19/grid

case $1 in
'start')
echo "STARTUP DATATABASE $ORACLE_SID"
NODE_NAME=$(${GRID_HOME}/bin/olsnodes -l)
$ORACLE_HOME/bin/sqlplus -s / as sysdba << EOF
startup
alter system set local_listener='(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=${NODE_NAME}-vip.example.de)(PORT=1521))))' scope=memory;
EOF
exit 0
;;

'stop')
echo "SHUTDOWN DATABASE $ORACLE_SID"
$ORACLE_HOME/bin/sqlplus -s / as sysdba << EOF
shutdown immediate
EOF
exit 0
;;

'clean')
echo "SHUTDOWN ABORT DATATABASE $ORACLE_SID"
$ORACLE_HOME/bin/sqlplus -s / as sysdba << EOF
shutdown abort
EOF
exit 0
;;

'check')
echo "CHECK STATUS DATABASE $ORACLE_SID"
NUM=`ps -ef | grep -i pmon_${ORACLE_SID} | grep -v grep | wc -l`
if [ $NUM = 0 ]; then
exit 1
else
exit 0
fi
;;
esac

 

Der Funktionsblock „start“ muss neben dem Start der Datenbank auch das Setzen des Parameters LOCAL_LISTENER auf die VIP-Adresse des Servers beinhalten auf dem sie gestartet wird. Dies dient zur dynamischen Registrierung des Datenbank-Services an dem lokalen Listener.

Status- und Fehlermeldungen werden vom Scriptagent der Clusterware in der folgenden Tracedatei protokolliert.

$ORACLE_BASE/diag/crs/<server-name>/crs/trace/crsd_scriptagent_oracle.trc

Die Erteilung der notwendigen Ausführungsberechtigung darf natürlich auch nicht vergessen werden:

chmod ug+x /u01/app/oracle/action_scripts/action_mydb.sh

Action-Script-Beispiele für andere Anwendungen gibt es in der Online Dokumentation: Examples of Action Scripts for Third-party Applications

12. Cluster Ressource anlegen

Mit dem Oracle Clusterware Control Utility (CRSCTL) der Clusterware muss mit dem User root die Cluster-Ressource für die Datenbank angelegt werden. Beim Erstellen, müssen neben dem eigentlichen Namen der Ressource, auch einige Attribute mitgegeben werden. Dazu gehören der Pfad zum zuvor angelegten Action-Script, Berechtigungsinformationen und weitere notwendige Eigenschaften.

Der Name der Cluster-Ressource kann frei gewählt werden, darf aber nicht mit „ora.“ beginnen, da dieser Prefix reserviert ist. In meinem Beispiel habe ich den Namen der Datenbank genommen und dem ein „db.“ als Prefix vorangestellt (db.mydb).

Anmeldung als root.

 Umgebungsvariablen setzen:

export GRID_HOME=/u01/app/19/grid 
export PATH=$GRID_HOME/bin:$PATH

Die Clusterressource anlegen:

crsctl add resource db.mydb -type cluster_resource \
-attr "ACTION_SCRIPT=/u01/app/oracle/action_scripts/action_mydb.sh,
ACL='owner:oracle:rwx,pgrp:oinstall:r--,other::r--,group:dba:r-x,user:grid:r-x'
CHECK_INTERVAL=60,
RESTART_ATTEMPTS=2,
FAILURE_THRESHOLD=2,
SERVER_POOLS=*,
SCRIPT_TIMEOUT=90,
FAILURE_INTERVAL=60,
UPTIME_THRESHOLD=1h,
HOSTING_MEMBERS=ora-c-srv2,
PLACEMENT=favored,
DESCRIPTION=Oracle Failover Instance"

 

HOSTING_MEMBERS

Das Attribut HOSTING_MEMBERS bestimmt auf welchem der beiden Server die Datenbank standardmäßig läuft. In dem Beispiel wird beim Start der Ressource zunächst versucht die Datenbank auf dem 2. Server (hier ora-c-srv2) zu starten. Gelingt dies nicht, so wird ein Startversuch auf dem 1. Server (hier ora-c-srv1) unternommen. Will man mehrere Datenbankinstanzen auf beide Server verteilen, so kann man über dieses Attribut steuern, welches die reguläre „Heimat“ der einzelnen Datenbankinstanz im Normalbetrieb ist. Leider funktioniert diese Server-Präferenz nur beim manuellen Starten der Ressource mit dem CRSCTL-Befehl. Beim Neustart der Clusterware oder beim Reboot starten die Datenbank-Ressourcen alle auf dem selben Server. Daraus folgt, dass man  durch ein anschließenden Stopp und Start der „fehlgeleiteten“ Ressourcen diese auf ihren bestimmungsmäßtien Server bringen muss.

SCRIPT_TIMEOUT

Das Attribut SCRIPT_TIMEOUT gibt die maximale Zeit in Sekunden an, die eine Aktion (stop,start,check,clean) dauern darf, bevor es zu einer Fehlermeldung kommt. Zusätzlich wird bei der Aktion „stop“ die Aktion „clean“ durchgeführt. Wenn die Datenbank es also nicht schafft innerhalb der angegeben Zeit herunterzufahren, dann wird ein „shutdown abort“ ausgeführt. Ich empfehle hier den Wert auf mindestens 90 Sekunden hochzusetzen, da der Defaultwert von 60 Sekunden oftmals zu gering für einen sauberen Shutdown ist.

Eine Liste der möglichen Attribute und deren genauen Beschreibung, findet man in der Onine Dokumentation: Oracle Clusterware Resource Reference

13. Cluster Ressource mit CRSCTL starten

Die neu angelegte Cluster-Ressource für die Datenbank muss mit dem CRSCTL-Utility gestartet werden. Dies gilt im Übrigen für alle Steuerungs- und Konfigurationsaktivitäten für diese Datenbank. Das CRSCTL-Utility ist ein Kommandozeilen-Tool der Clusterware und befindet sich Home-Verzeichnis der Grid Infrastruktur. Das Server Control Utility (SRVCTL), welches man üblicherweise nutzt, um eine Datenbank in einem Oracle Cluster zu steuern und welches sich im Homverzeichnis der Datenbanksoftware befindet, kann zukünftig nicht genutzt werden!

Wenn man bislang gewohnt war seine Datenbank mit dem angemeldeten Benutzer oracle zu steuern, so möchte man dies sicherlich beibehalten und nicht jedes mal dafür zum User grid oder root wechseln. Dies kann man erreichen, indem man z.B. einfach ein Alias für das CRSCTL im Login-Profil .bash_profile des Users oracle definiert.

echo "alias crsctl=/u01/app/19/grid/bin/crsctl" >> /home/oracle/.bash_profile

Nach Neuanmeldung steht dann dem User oracle das CRSCTL komfortable zur Verfügung.

Starten der Datenbank:

crsctl start resource db.mydb

 


Weitere Steuerungsmöglichkeiten

Stoppen der Datenbank:

crsctl stop resource db.mydb

Starten der Datenbank auf einem bestimmen Server:

crsctl start resource db.mydb -n ora-c-srv1

Verschieben der Datenbank auf den anderen Server:

crsctl relocate resource db.mydb

Anzeige des Status der Datenbank-Ressource:

crsctl status resource db.mydb
NAME=db.mydb
TYPE=cluster_resource
TARGET=ONLINE
STATE=ONLINE on ora-c-srv1

Anzeige aller Attribute der Datenbank-Ressource:

crsctl stat resource db.mydb -f

Ändern des default-Servers der Datenbank auf ora-c-srv2:

crsctl modify resource db.mydb -attr "HOSTING_MEMBERS=ora-c-srv2 ora-c-srv1"

Autostart der Datenbank deaktivieren

crsctl modify resource db.mydb -attr "ENABLED=0"

Autostart der Datenbank aktivieren

crsctl modify resource db.mydb -attr "ENABLED=1"

Lizenzierung

Oracle Custerware 19c

Die Oracle Clusterware ist kostenlos und kann für jede beliebige Anwendung genutzt werden, um diese gegen einen Serverausfall abzusichern – also nicht nur für Oracle Datenbanken. ASM darf für Oracle Datenbanken und zur Verwendung des Oracle ASM Cluster File System (ACFS) ebenfalls genutzt werden.

Support und Patche für die Oracle Clusterware gibt es dagegen nur, wenn auf den Servern ein Oracle Produkt läuft, für das man einen gültigen Supportvertrag hat. Dies kann ein z.B. Oracle Datenbank sein, Oracle Linux (ab Basic Support) oder andere Oracle Software.

Oracle Datenbank 19c

Die Datenbank muss in jedem Fall lizenziert werden. Und in den meisten Fällen müssen beide Server bei der Berechnung der notwendigen Datenbanklizenzen einbezogen werden.

Ausnahme:

  • Die für die Datenbank verwendete Storageeinheit ist nicht gespiegelt (kein Remote-Mirroring).

UND

  • Die Datenbanken laufen im Regelbetrieb nur auf dem 1. Server und diese werden nicht mehr als insgesamt 10-Tage auf den 2. Server betrieben (Failover).

Wenn beide Bedingungen erfüllt sind, braucht der 2. Server nicht lizenziert werden.

Wie aber bereits im oberen Abschnitt erwähnt, finde ich es charmant, beim Betrieb von mehreren Datenbanken, diese auf beide Server zu verteilen, um die Rechnerkapazitäten beider Server nutzen zu können. Dann müssen zwar beide Server in die Kalkulierung der erforderlichen Lizenzen einbezogen werden, man nutzt dann ja aber auch beide. Die Server sollten dann aber auch so ausgelegt sein, dass sie in der Lage sind im Fehlerfall alle Datenbanken gleichzeitig zu betreiben.

Nicht unerwähnt möchte ich lassen, dass jeder der Server entsprechend der Oracle Lizenzbedingungen nicht mehr  als zwei CPU-Sockets haben darf (bei Oracle SE2). Die Anzahl der CPU-Kerne ist dageben beim Einsatz der Standard Edition 2 nicht relevant.

 

Anmerkung Oracle Datenbanken 11.2 im Cluster:

Will man einen Oracle 11.2 Datenbank in einer Grid Infrastruktur größer oder gleich 12.2 betreiben, darf man nich den ASM Filter Driver nutzen, da dieser nicht mit 11.2 kompatibel ist. Stattdessen muss man ASMLib nutzen! (Siehe MOS Note 2341119.1)

 

Referenzen: