Site Logo

IzzySoft


› › StandbyDB
{itemlist}
 

Erstellen einer Standby Datenbank mit RMAN unter Oracle 10g

Das Online-Manual zum Erstellen einer Standby-Datenbank mittels RMAN auf den Oracle-Seiten kann einen ziemlich verwirren: Man muss ständig zwischen den Artikeln hin und her, sowie vor und zurück springen, wobei man sehr leicht den Überblick verliert. Hinzu kommen Dinge wie "folgen Sie den unter x beschriebenen Schritten, außer y und machen Sie nicht z". Wow.

Worum es in diesem Artikel geht

Obiger Absatz beschreibt den Hintergrund zur Entstehung dieses Artikels. Er soll so einfach wie möglich durch die nötigen Schritte zur Erstellung einer Standby Datenbank führen – in einer Art, die Verwirrung möglichst vermeidet. Das Ganze spielt in einer Oracle 10g Umgebung unter Linux/Unix, und wir wollen RMAN dabei verwenden.

Worum es in diesem Artikel NICHT geht

Wie oben bereits erwähnt, befinden wir uns in einer *nix Umgebung – auf andere Betriebssystem-Spezifika wird nicht eingegangen (keine Angst – BS-spezifische Punkte sind wirklich rar hier). Auch wird nicht auf Oracle-Versionen eingegangen, die größer oder kleiner als 10g sind.

Inhalt

Voraussetzungen

Hardware und Software

Da es in diesem Artikel nicht um die Installation von Oracle geht, wollen wir hier auch nicht zu sehr ins Detail gehen – sondern die Spezifika für diesen Artikel beleuchten. Was wir brauchen sind:

Vorbereitung

Vorbereitung der init.ora für die Standby Datenbank

Was zu tun ist

Als Grundlage dient hier die init.ora der (bereits laufenden) Master-Datenbank. Die zur Erstellung derselben verwendete Datei findet sich unter $ORACLE_HOME/dbs/init<SID>.ora. Sofern in der Datenbank bereits Änderungen (ALTER SYSTEM SET...SCOPE=<spfile|both>) durchgeführt wurden, sollten diese spätestens jetzt in der init.ora nachgezogen werden. Wer sich nicht sicher ist, macht sich ein Backup der init<SID>.ora und führt dann in SQLPlus den Befehl CREATE PFILE FROM SPFILE; aus, um die Einstellungen zu vergleichen.

Jetzt müssen folgende Einstellungen ergänzt bzw. angepasst werden:

LOG_ARCHIVE_DEST_1='SERVICE=<master-tns-alias> VALID_FOR=(ALL_LOGFILES,PRIMARY_ROLE)
STANDBY_FILE_MANAGEMENT=AUTO
STANDBY_ARCHIVE_DEST='LOCATION=USE_DB_RECOVERY_FILE_DEST'
DB_UNIQUE_NAME=<unique name for the standby DB>
FAL_SERVER=<master-tns-alias>
FAL_CLIENT=<standby-tns-alias>
REMOTE_LOGIN_PASSWORD_FILE=EXCLUSIVE

<master-tns-alias> und <standby-tns-alias> sind die Namen, die später in der tnsnames.ora für die jeweiligen Datenbanken konfiguriert werden.

Mit Ausnahme des DB_UNIQUE_NAME, der im Nachhinein nicht mehr modifizierbar ist, werden wir diese Änderungen später auch auf die Master Datenbank anwenden, wobei wir hier die Werte für FAL_SERVER und FAL_CLIENT untereinander vertauschen, sowie bei LOG_ARCHIVE_DEST1 den TNS-Alias der Standby Datenbank eintragen.

Was diese Parameter bedeuten

Wen es nicht interessiert, der mag diesen Abschnitt überspringen – man muss es nicht unbedingt wissen, damit es klappt. Wer es jedoch noch nicht weiß, dem sei die Lektüre empfohlen – man sollte schon wissen, was man tut ;)

Die Oracle Passwort-Datei

Wer noch keine Passwort-Datei verwendet, sollte sie spätestens jetzt erstellen – sonst gibt es keinen Remote-Login als SYSDBA (was für die Standby Voraussetzung ist). Wichtig ist hier:

Ist die erste oder zweite Bedingung nicht erfüllt, wird die Passwort-Datei überhaupt nicht gefunden (und daher auch nicht verwendet). Die dritte Bedingung ist für den Betrieb der Standby Datenbank wichtig.

Konfiguration des Listeners

Jetzt gilt es, auf beiden Maschinen den Listener zu konfigurieren. Hierzu brauchen wir eindeutige Namen (Aliase) für beide Instanzen, die aber auf beiden Maschinen identisch sein müssen (d. h. master-tns-alias verweist immer auf die Master, usw.).

Fangen wir also mit der tnsnames.ora an. Diese findet sich gewöhnlich im Verzeichnis $ORACLE_HOME/network/admin. Hier fügen wir zwei neue Einträge hinzu – für jede Datenbank einen:

<master-tns-alias> = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP) (Host = <DNS-Name/IP des Master Servers>) (Port = 1521))
                         (CONNECT_DATA = (SID = <ORACLE_SID>) ))
<standby-tns-alias> = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP) (Host = <DNS-Name/IP des Standby Servers>) (Port = 1521))
                         (CONNECT_DATA = (SID = <ORACLE_SID>) ))

Jetzt folgt die listener.ora aus dem gleichen Verzeichnis. Hier müssen wir die lokale Instanz im Block SID_LIST_LISTENER hinzufügen (sollte der Listener nicht, wie per Default, LISTENER heißen, bitte den entsprechenden anderen Block auswählen):

(SID_DESC = (SID_NAME = <ORACLE_SID>) (ORACLE_HOME = /local/oracle/ora102))

Wie bereits erwähnt, sollten diese Einträge auf beiden Rechnern identisch sein. Sind die Änderungen durchgeführt, gilt es den Listener (neu) zu starten:

oracle$ lsnrctl stop
oracle$ lsnrctl start

Überprüfen des Datenbank-Status

Bevor wir nun endgültig loslegen können, müssen wir sicherstellen, dass die beiden Datenbanken im richtigen Modus laufen. Mit SQL*Plus verbinden wir uns als SYSDBA, und setzen den Befehl SELECT status FROM v$instance ab. Auf unserer Master-Datenbank sollte das Ergebnis OPEN oder zumindest MOUNTED heißen, auf der Standby NOMOUNT. Ist dies nicht der Fall, kommt als nächstes ein startup auf der Master-Datenbank, bzw. ein startup nomount auf der Standby.

Ebenfalls prüfen müssen wir, ob eine Anmeldung über das Netz funktioniert. Also noch ein sqlplus sys/passwort@master-tns-alias AS SYSDBA vom Standby-Rechner, und sqlplus sys/passwort@standby-tns-alias AS SYSDBA von der Standby-Maschine. Funktioniert soweit alles, geht es mit dem nächsten Schritt weiter.

Backups

Unsere letzten Voraussetzungen sind ein vollständiges Backup sowie eine Kopie des Controlfiles für die Standby Datenbank, beides mit RMAN erstellt. Ist dies noch nicht geschehen, tun wir das hier:

oracle$ rman target /
rman> BACKUP CURRENT CONTROLFILE FOR STANDBY;
rman> BACKUP DATABASE;

Diese Befehle sind natürlich auf dem Master-Rechner abzusetzen. Für mehr Details zu den RMAN Kommandos verweise ich an dieser Stelle auf die RMAN Dokumentation, sofern dies jemand verfeinern will.

Abschließend müssen wir die erstellten Backups noch auf den Standby Server kopieren, damit RMAN sie dort auch findet (bei Einsatz eines Media-Managers ist dies u.U. nicht nötig). Am einfachsten geschieht dies, indem wir uns auf dem Standby-Rechner als Benutzer oracle anmelden, in das Verzeichnis der Recovery-Area wechseln, und uns die Dateien mit RSync holen:

rsync -Pae master:/path/to/recovery/area/ .

Damit sind die Vorbereitungen abgeschlossen, und wir können die Standby Datenbank erstellen.

Erstellung der Standby Datenbank

Jetzt kommt RMAN zum Einsatz, um uns die restliche Arbeit abzunehmen:

oracle$ rman target / auxiliary sys/password@standby-tns-alias
DUPLICATE TARGET DATABASE FOR STANDBY NOFILENAMECHECK;

Zurücklehnen und abwarten – sobald dieser Befehl abgearbeitet ist, haben wir unsere Standby Datenbank erstellt, und sie ist auch bereits gemountet.

Nacharbeiten und Anmerkungen

Nacharbeiten

Bezüglich der Standby Logs, hier ein kurzer Auszug aus einem Metalink Artikel:

"Standby redo logs are necessary for the higher protection levels such as Guaranteed, Instant, and Rapid. In these protection modes LGWR from the Primary host writes transactions directly to the standby redo logs. This enables no data loss solutions and reduces the amount of data loss in the event of failure. Standby redo logs are not necessary if you are using the delayed protection mode."

Anders ausgedrückt: Wir brauchen sie hier nicht, da wir im "deferred" Modus arbeiten: Die Redo-Information wird erst dann zur Standby Datenbank übertragen, wenn sie auf der primären Datenbank archiviert worden ist. Anders sieht das Ganze aus, wenn eine "Echtzeit-Übertragung" gewünscht wird (die Standby Datenbank also das Redo sofort bei Erzeugung bekommen und verarbeiten soll) – hier brauchen wir die Standby Logs. Sie sollten dann allerdings auf beiden Datenbanken – also auch auf der primären – angelegt werden. Auch wenn die primäre Instanz keine Standby Logs verwendet: Nach einem SwitchOver/FailOver wird sie schließlich zur Standby, und sollte darauf vorbereitet sein.

Bei der Einrichtung von Standby-Logs gibt es noch einiges mehr zu beachten, was aber diesen Artikel sprengt. Daher verweise ich hier nur noch kurz auf den entsprechenden Befehl zur Erstellung (ALTER DATABASE ADD STANDBY LOGFILE), sowie das Metalink Dokument 180031.1.

Anmerkungen

RMAN Framework

Das RMAN Framework aus dem DBAHelper Paket kann die Erstellung einer Standby-Datenbank (und mehr) erleichtern und automatisieren. Kurz gesagt, kümmert sich dieses Framework um

Generelle Anmerkungen

Auf der Standby-Datenbank kann Oracles DBConsole nicht genutzt werden: Diese erstellt ihr Repository nämlich generell in der lokalen Datenbank – was bei einer Standby-Datenbank nicht möglich ist (read-only). Es gibt wohl auch keine Möglichkeit, die DBConsole hierfür auf eine andere Datenbank umzubiegen. Wer also ein solches Interface für die Verwaltung verwenden möchte, der muss auf Grid Control zurückgreifen – Stoff genug für einen anderen Artikel.

Weiterführende Informationen

SwitchOver / FailOver

SwitchOver oder FailOver?

Zwar haben beide Varianten gemeinsam, dass anschließend die ehemalige Standby-Datenbank zur Master geworden ist – dennoch gibt es jedoch Unterschiede, die es zu beherzigen gilt. So gibt es nach einem FailOver kein Standby-System mehr, und die (ehemalige) primäre Datenbank kann auch nicht mehr in eine Standby-Datenbank umgewandelt werden; es bleibt also nur noch die Möglichkeit, eine neue Standby-Datenbank zu erstellen. Bei einem SwitchOver hingegen tauschen beide einfach die Rollen, und es muss keine neue Standby-Datenbank mehr erstellt werden.

Ein DBA sollte es sich also gut überlegen, ob er ein FailOver initialisieren will. Auch wenn die Optionen fast offensichtlich sind, hier ein paar Entscheidungshilfen:

  1. Beide Datenbanken sind sowohl physisch als auch logisch in einwandfreiem Zustand, und auch für alle Applikationen erreichbar. Dennoch soll (z.B. aufgrund von Server-Wartungsarbeiten, Kernel-Updates o.ä.) das Standby System für die Applikationen geöffnet werden: SwitchOver
  2. Wie 1., jedoch ist die primäre Datenbank für die Applikationen nicht erreichbar (z.B. Netzwerk-Probleme): SwitchOver (dies setzt allerdings voraus, dass die primäre Instanz noch mit der Standby-Datenbank kommunizieren kann)
  3. Die primäre Instanz ist tot und nicht mehr zu erreichen: Hier haben wir wohl keine Wahl – FailOver

Oder anders ausgedrückt: Solange die Möglichkeit zu einem SwitchOver besteht, sollte kein FailOver ausgeführt werden.

SwitchOver

Kommen wir also zum SwitchOver. Die Durchführung ist nicht so schwer – die Reihenfolge der Operationen ist jedoch wichtig:

-- Sicherstellen, dass keiner mehr auf die Datenbank zugreift
sqlplus@master> SHUTDOWN IMMEDIATE
sqlplus@master> STARTUP [RESTRICT]

-- Vorbereiten für Rollenwechsel
sqlplus@master> ALTER DATABASE COMMIT TO SWITCHOVER TO STANDBY WITH SESSION SHUTDOWN;
sqlplus@standby> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY;

-- Rollenwechsel
sqlplus@master> SHUTDOWN IMMEDIATE
sqlplus@master> STARTUP MOUNT
sqlplus@master> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT;
sqlplus@standby> ALTER DATABASE OPEN

Jetzt haben die beiden Datenbanken ihre Rollen getauscht. Bitte beachten: "@master" meint hier immer die alte Primary, "@standby" die alte Standby – auch nach dem Rollentausch!

FailOver

Zuerst noch einmal zum mitmeißeln: Ein FailOver sollte nur durchgeführt werden, wenn ein SwitchOver nicht in Frage kommt! Also geht man **nur im Notfall* wie folgt vor:

sqlplus@standby> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH;
sqlplus@standby> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY;

Vergleich

Vergleichen wir nun beide Vorgehensweisen, so wird schnell klar, warum es nach einem FailOver keine Möglichkeit mehr gibt, die alte primäre Instanz zur neuen Standby-Datenbank zu machen: Sie hat nämlich auch noch RedoLogs generiert, nachdem wir die alte Standby geöffnet haben. Und letztere hat auch bereits Redo erstellt – die beiden sind also komplett "out-of-sync", und eine Synchronisation ist nicht mehr möglich. Beim SwitchOver haben wir dies vermieden: Wir haben im ersten Schritt unterbunden, dass die (alte) primäre Instanz weiteres Redo generiert – indem wir sie zur Standby gemacht haben. Für kurze Zeit hatten wir also zwei Standby-Datenbanken, und keine primäre. Während das neue Standby-System (zunächst freilich vergeblich) auf Redo-Informationen von einer (noch) nicht existenten primären Instanz wartete, konnte die (alte) Standby-Datenbank noch die restlichen Informationen verarbeiten – womit beide Datenbanken auf exakt dem selben Stand waren. In dem Augenblick, wo wir hier das alte Standby-System zum Primärsystem machten, wartete das neue Standby-System bereits darauf.

2020-11-18