Site Logo

IzzySoft


› › RManFramework
{itemlist}
 

RMAN Framework - Schneller Start für Einsteiger

Oracles "Recovery Manager" – kurz RMAN genannt – ist als mächtiges Kommandozeilen-Tool für Backup und Restore von Oracle Datenbanken bekannt. Doch wie das mit so mächtigen Kommandozeilen-Programmen üblich ist, halten es viele für einfach zu kompliziert – und trauen sich nicht ran. Es stimmt schon: Man kann mit RMan sehr komplexe (und komplizierte) Dinge tun. Aber wer sagt denn, dass wir das müssen? Dieser Artikel soll zeigen, dass es auch recht einfach geht – oder man es sich einfach machen kann, wenn man über ein passendes FrontEnd verfügt.

Worum es in diesem Artikel geht

Zwar wird das RMan Framework – welches Bestandteil des DBAHelper Paketes ist – mit einer Dokumentation ausgeliefert; doch ist jene in erster Linie als Referenz gedacht, und enhält nicht zu viele Beispiele. Erst recht nicht enthalten ist etwas wie ein kleiner Workshop, der die Dinge etwas mehr im Detail, an Beispielen und mit Screenshots, erklärt – und genau das wollen wir hier tun.

Wie üblich findet das Ganze wieder auf einem Linux-Server statt – schließlich basieren die Skripte alle auf der Bash. Daher tut es natürlich auch ein beliebiges anderes Unix (Solaris, AIX, …), sofern dort die Bash und Oracle verfügbar sind (wir haben die Skripte unter RHEL 4 / CentOS 4.6 getestet). Gedacht ist das Ganze ferner für Oracle Datenbanken in Version 10g oder höher. Und: Ja, die Flash Recovery Area muss für die Datenbank in diesem Workshop eingerichtet worden sein.

Worum es in diesem Artikel NICHT geht

Hm, diesen Absatz sollte ich mir vielleicht einmal sparen: Das Übliche kommt diesmal noch etwas härter. Nicht nur gehen wir nicht auf Windoze-typische Eigenheiten ein – wir müssen es diesmal sogar ganz außen vor lassen, da die hier verwendeten Skripte unter Windows einfach nicht laufen. Mit Cygwin würde das vielleicht gehen – aber wer hat Oracle unter Cygwin installiert?

Inhalt

Die Komponenten

Was ist RMAN?

RMan ist der Oracle Recovery Manager. Doch wo es etwas zu Recovern (wiederherzustellen) gibt, muss es zunächst gesichert worden sein – auch das gehört zu den Aufgaben von RMan. Es handelt sich hier um ein recht mächtiges Werkzeug, dessen detaillierte Diskussion hier den Rahmen sprengen würde – daher verweise ich für selbige erst einmal auf den Artikel über Database Backup and Recovery Basics auf Oracles Website, der eigentlich alle Details behandeln sollte.

Hier also nur ein kurzer Abriss: Mit RMan lassen sich Oracle Datenbanken auf lokale Festplatten (z.B. in die Flash Recovery Area, wie wir das hier tun werden), auf Band oder sonstwohin sichern, wobei für den Zugriff auf Backup-Medien Storage Manager genutzt werden können. Natürlich lässt sich RMan dann auch zur Wiederherstellung nutzen: Sei es die komplette Datenbank, ein Tablespace, eine einzelne Datei oder auch nur einzelne Datenblöcke. Ebenfalls lässt sich die Konsistenz/Validität von Backups überprüfen (tun wir hier auch). Und mehr.

Was ist DBAHelper?

DBAHelper ist eine Sammlung von kleinen (und großen) Helferlein für den "täglichen Bedarf" eines Oracle DBAs – angefangen bei kleinen Skripten, um "lazy Sessions" oder benutztes Undo anzuzeigen, über Skripte zum automatischen Verschieben von Objekten zwischen Tablespaces oder Kompilieren aller/invalider Indexes – bis hin zu komplexeren Dingen wie dem RMan Framework. DBAHelper steht unter der GNU Public License (GPL), und ist daher frei verfügbar.

Was bietet das RMan Framework?

RMan Framework: Menüs Das RMan Framework bietet einfachen Zugriff auf grundlegende Funktionen von RMan, zusammen mit einer einfachen grafischen Oberfläche für interaktive Benutzung, sowie der Möglichkeit von Automatisierung. Für die interaktive Benutzung, sind die Menüs nach Einsatzbereichen strukturiert (siehe nebenstehenden Screenshot) - sodass die Übersicht nicht aufgrund zu vieler Einträge verloren geht.

Das RMan Framework ist "Out-of-the-Box" lauffähig und ermöglicht auch einem absoluten Anfänger, sofort mit Backups und Wiederherstellung arbeiten zu können - ohne großartige Einarbeitung in die Materie (und vor allem die Syntax von RMan). Das reicht sogar bis zur Erstellung einer Standby-Datenbank. All dies wird auch im Artikel besprochen.

Installation

Voraussetzungen

Üblicherweise gibt es immer ein paar Voraussetzungen, die zu erfüllen sind – das gilt auch hier. Das Offensichtliche zuerst: Es macht wohl kaum Sinn, DBAHelper einzusetzen, wenn man keine Oracle Datenbank hat. Hier brauchen wir gar eine Oracle 10g Datenbank (oder eine höhere Version), da unser RMan Framework auf einige Funktionen aufsetzt, die erst ab 10g verfügbar sind. Wir arbeiten auf dem Datenbank-Rechner, der uns eine Bash (Bourne Again Shell) zur Verfügung stellen muss. Natürlich müssen auch das rman und sqlplus "Executable" hier verfügbar sein – was bei einem Oracle Datenbankserver in der Regel der Fall ist.

Desweiteren muss in der Datenbank die Flash Recovery Area für Backups konfiguriert sein – dies geschieht mit den init.ora Parametern db_recovery_file_dest und db_recovery_file_dest_size, bzw. den entsprechenden ALTER SYSTEM … SCOPE=both; Befehlen im Falle der Verwendung eines SPFiles (Server Parameter Files).

Installation

Abhängig vom Download-Typ, kann DBAHelper (oder auch das RMan Framework allein) auf verschiedene Weise installiert werden:

Wie schon geschrieben, sollte alles "Out-of-the-Box" ohne weitere Konfiguration laufen. Dennoch lässt sich das Ganze an die eingenen Bedürfnisse anpassen, wie wir gleich sehen werden.

Konfiguration

Prinzipiell gibt es zwei Konfigurationsdateien für das RMan Framework: Eine für das "Look-and-Feel" sowie Verhalten von rman.sh (also die "Benutzerschnittstelle"), die andere für die Datenbank-Konfiguration (Backup Policy usw.). Auf beide soll im Folgenden eingegangen werden:

Aussehen und Verhalten

Die hierfür zuständige Konfigurationsdatei heißt rmanrc, und findet sich im Hauptverzeichnis des RMan Frameworks (rman/ im Distributions- Archive – bzw. /usr/local/share/dbahelper/rman nach einer Installation aus dem RPM/DEB Package). Die verwendeten Schlüsselwörter werden in der im Paket enhaltenen Dokumentation im Einzelnen erklärt, daher beschränken wir uns hier auf das Wichtigste:

Das LOGDIR sollte auf ein existierendes Verzeichnis zeigen – dort wird rman.sh die Log-Dateien für alle rman Aktionen ablegen. Damit ist es auch im Nachhinein möglich, alle Läufe nachzuvollziehen. Jeder neue Aufruf wird seine eigene Log-Datei im Format rman_<Aktion>_yyyymmdd_hhmiss anlegen. Wird also z.B. am 11. Juni 2008 um 10:27:03 Uhr rman.sh backup_daily aufgerufen, erzeugt dies eine Log-Datei mit dem Namen rman_backup_daily_20080611_102703 in dem mit LOGDIR festgelegten Verzeichnis. Dass jemand in der gleichen Sekunde die gleiche Aktion doppelt ausführt, ist eher unwahrscheinlich ;)

Mit den TEMPTS_* Keywords legen wir die Spezifikationen für den temporären Tablespace der Datenbank fest – genauer gesagt: Die Default-Spezifikationen. Da dieser Tablespace in keinem Backup vorkommt (wozu auch – sind ja keine bleibenden Daten drin, der Verlust tut also nicht weh), kann er auch aus keinem solchen wiederhergestellt werden. Trotzdem gibt es freilich bei seinem Fehlen einen Haufen Ärger - daher lässt er sich mit rman.sh restore_temp interaktiv wieder erstellen. Diese Default-Werte werden dann vorgeschlagen, können aber verändert werden.

Die Einstellungen von USEDIALOG und TIMEOUT betreffen lediglich die (G)UI: Ist das Paket/Programm dialog installiert, kann rman.sh auf eine wesentlich ansprechendere Bedienoberfläche zurückgreifen. Mit USEDIALOG=1 wird diese aktiviert (bzw. mit USEDIALOG=0 deaktiviert). Wird dialog nicht gefunden, verhält sich rman.sh als wäre es abgeschaltet – und ignoriert die "1". Diese Einstellung lässt sich allerdings auch an der Kommandozeile mit der Option --[no]dialog modifizieren.

Das TIMEOUT (in Sekunden) legt fest, nach welcher Zeit Textboxen, die auf eine Eingabe warten, geschlossen werden – falls der Benutzer eingeschlafen ist. Die voreingestellten 3600 Sekunden entsprechen also 1 Stunde.

Bleiben die TMPFILE und SPOOLFILE Einstellungen: Hier ist lediglich wichtig, dass sie auf eine nicht existierende Datei in einem existierenden Verzeichnis verweisen. Beide Dateien sind nur temporärer Natur; daher sollte es dem Anwender recht egal sein, wo sie sind – sie werden zur Laufzeit erzeugt und wieder gelöscht.

DB Konfiguration

Grundlegende Konfiguration

Jetzt kommen wir zu den wirklich wichtigen Einstellungen: Denen, die die Datenbank(en) betreffen. Diese finden in der rman.conf Datei statt, die sich im gleichen Verzeichnis wie soeben beschriebene rmanrc befindet. Die Konfigurationsdatei aus dem Distributionsarchiv ist natürlich vollkommen OK und einsatzfähig (vorausgesetzt, die FRA wurde wie eingangs beschrieben konfiguriert) – aber die eigenen Ansprüche sind vielleicht doch andere, sodass der eine oder andere diese Einstellungen anpassen möchte. Daher werden die Voreinstellungen (und mögliche Anpassungen) nun besprochen. Allerdings mehr oder weniger grundlegend – es gibt weit mehr Möglichkeiten, für die ich jedoch wieder auf die Oracle Backup Dokumentation verweisen möchte.

Kommen wir zunächst zur Retention Policy. Das RMan Framework benutzt hier ein Recovery Window – d. h. das Backup ist derart konfiguriert, dass eine Wiederherstellung zu jedem beliebigen Zeitpunkt innerhalb des so definierten "Fensters" möglich sein sollte. Realisiert wird dies, indem eine initiale Kopie der Datendateien entsprechend dem Zeitfenster aus incrementellen Backups ständig gepflegt wird. Bei einem Zeitfenster von 7 Tagen werden diese Dateien also bei jedem Lauf auf den Stand von vor 7 Tagen aktualisiert. Für die Wiederherstellung stehen somit 7 Tage alte Datendateien, eine Reihe von inkrementellen Backups sowie die archivierten Redo-Logs zur Verfügung – womit man zu jedem beliebigen Zeitpunkt innerhalb dieser 7 Tage wiederherstellen kann.

Natürlich verbraucht dieses Vorgehen einiges an Plattenplatz. Daher kann man das Fenster bei Bedarf natürlich kleiner wählen. Aber obwohl RMan selbst auch andere Policies (z. B. Redundanz) kennt, verwendet das RMan Framework ausschließlich das Recovery Window – alles andere wird (noch) nicht unterstützt. Allerdings entspricht "Redundanz 1" bei einem täglichen Backup etwa einem Recovery Window von einem Tag, sodass sich ein wenig tricksen lässt.

Das control file autobackup sollte auf "ON" belassen werden – damit RMan bei jedem Lauf ein Backup der Kontrolldateien anlegt. In diesen ist u. a. unsere Backup-Information gespeichert – zumindest wenn wir keine Katalog-Datenbank benutzen (was die Defaulteinstellung ist).

Die anderen Einstellungen betreffen die Geräte, auf die das Backup erfolgen soll (in unserem Falle nutzen wir die FRA, daher ist hier alles für "Disk", also Festplatte, konfiguriert). Für erweiterte Einstellungen sei hier auf die RMan Dokumentation verwiesen.

Datenbank-spezifische Konfiguration

Wer mehrere Datenbanken auf einem Host laufen hat, deren Backup-Konfiguration nicht identisch ist, der benötigt mehrere Kopien der rman.conf Datei. Klar kann man diese beliebig benennen, und rman.sh mit dem Parameter -c <configfile> übergeben – schöner wäre es jedoch, wenn rman.sh automatisch die richtige Datei wählen würde. Das klappt auch, wenn sie den richtigen Namen hat: eine mit rman_$ORACLE_SID.conf benannte Datei wird automatisch für die Datenbank mit der entsprechenden ORACLE_SID verwendet (für eine Datenbank mit der SID "orcl" muss die Datei also rman_orcl.conf heißen). Wird keine passende Datei gefunden, greift rman.sh auf den Default, rman.conf, zurück.

Diese Datenbank-spezifischen Konfigurationsdateien sind auch sehr nützlich, wenn mehrere Datenbanken in einem Lauf abgehandelt werden sollen – z. B. bei der Erstellung von Backups mit rman.sh backup_daily --all. Die Option --all bewirkt hier, dass rman.sh nach allen Dateien sucht, die der Syntax rman_$ORACLE_SID.conf entsprechen - und alle zugehörigen Datenbanken abarbeitet. Sind die Einstellungen hier identisch, kann man auch einfach einen Symbolischen Link (anstelle einer Kopie) verwenden.

Interactive Nutzung

Syntax

Wird rman.sh ohne Parameter aufgerufen, zeigt es lediglich einen Hilfe-Bildschirm zu seiner Benutzung an (und beendet sich sogleich wieder). Dies ist also die einfachste Möglichkeit, sich einen schnellen Überblick zu verschaffen.

Wird lediglich die auszuführende Aktion als Parameter angegeben, startet rman.sh im interaktiven Modus – der Benutzer wird also durch die nötigen Schritte geführt. Im Folgenden dazu einige Beispiele.

Erster Start

Bei seinem ersten Start zeigt rman.sh zunächst seinen "Disclaimer" an. Dabei handelt es sich nicht um einen "Nag Screen" (er wird kein weiteres Mal angezeigt): Es soll lediglich auf mögliche Gefahren hingewiesen werden. Es handelt sich hier um "freie Software"; im Sinne von "frei verfügbar", "frei von Kosten" – aber auch "frei jeglicher Garantie". Keine Software ist völlig frei von Fehlern, auch wenn sich der Programmierer noch so müht. Es soll also hier nur nochmals darauf hingewiesen werden, dass die Benutzung stets "auf eigene Gefahr" geschieht.

Dryrun

Screenshotrman.sh DryRun Wer sich durch diesen Disclaimer verunsichert sieht, sucht nach einer etwas weniger gefährlichen Methode der Erprobung – und findet sie im "Trockenlauf": Ist die Option --dryrun spezifiziert, sollten keine Veränderungen durchgeführt werden. Stattdessen zeigt rman.sh an, was es ohne diese Option tun würde (einige nur-lesende Dinge werden allerdings trotzdem ausgeführt). Diese Option ist auch zum Lernen nützlich, da man die Kommandos und auch die ausgeführten RMan/SQL*Plus Skripte angezeigt bekommt – wie es nebenstehender Screenshot auch zeigt.

Natürlich werden auch beim Trockenlauf interaktive Fragen gestellt – halt alles, was im normalen Ablauf stattfindet. Schließlich werden die so abgefragten Informationen für die entsprechende Aktion benötigt – also für die sonst ausgeführten, hier jedoch nur dargestellten Kommandos.

Backup

Das einfachste Beispiel ist der Backup Befehl:

rman.sh backup_daily

Hier werden keine weiteren Informationen vom Benutzer erfragt – alles nötige kann der Konfiguration in der rman.conf entnommen werden. Daher kann man sich nach dem Aufruf einfach zurücklehnen und zuschauen.

Ein zusätzlicher möglicher Parameter ist hier --all – um das Backup gleich für alle konfigurierten Datenbanken auf dem Host zu erstellen. Auch in diesem Fall läuft alles automatisch durch, ohne dass Eingaben nötig wären - die notwendigen Daten stehen ja bereits in den rman_$ORACLE_SID.conf Dateien.

Das Backup validieren

ScreenshotBackup validieren Ein Backup zu haben, ist eine gute Sache. Noch besser ist es, wenn man weiß, dass selbiges auch sauber und für eine Wiederherstellung verwendbar ist – und das können wir mittels rman.sh validate feststellen.

Auch hier gibt es – wie schon beim Backup zuvor – keine Fragen zu stellen: Wo die Backups sind, und welche wir haben, ist alles bereits beim Backup selbst in der Kontrolldatei (bzw. in der Katalog-Datenbank) hinterlegt worden. Daher läuft der Prozess auch sofort an – und wir sehen die Resultate schon während er noch läuft: Die Ausgabe wird in einer sogenannten Tailbox dargestellt. Und auch wenn sich diese bereits während der Laufzeit schließen lässt, sollten wir damit bis zu Abschluss warten – wir wollen ja schließlich alle Ergebnisse sehen, oder?

Sollte doch jemand die Tailbox zu früh geschlossen haben (oder ein Telefonat, das Mittagessen oder sonst eine Unterbrechung hat den Timeout ausgelöst, und die Box ist bereits geschlossen, bevor wir wieder hinschauen konnten), gibt es immer noch die Logfiles. Diese liegen da, wo wir sie in der rmanrc konfiguriert haben – und können jederzeit konsultiert werden.

Die Flash Recovery Area aufräumen

ScreenshotAufräumen der FRA Schluss mit der Faulheit – ab jetzt ist wirklich Interaktion gefragt: Die Befehle cleanup_expired und cleanup_obsolete (siehe Screenshot) befreien die FRA von Dateien (und/oder die Kontrolldatei/Katalog-Datenbank von Einträgen), die wir nicht mehr benötigen. Entweder, weil sie über unsere Retention Policy hinausgehen (cleanup_obsolete), oder aus anderen Gründen (wie z. B. Datei nicht mehr vorhanden o. ä., cleanup_expired). Der Benutzer wird nun Schritt für Schritt durch den Prozess geführt, und dabei um Bestätigung ersucht: Sollen die angezeigten Dateien wirklich gelöscht werden? Natürlich wird zunächst ermittelt, welche Dateien betroffen wären – und das Ergebnis zur Entscheidung vorgelegt.

Andererseits lässt sich das Ganze auch ohne Rückfrage automatisch erledigen – aber hier geht es ja um die Interaktive Benutzung. Das Automatische kommt also später ;)

Die Flash Recovery Area verlegen

Irgendwann kommt vielleicht einmal ein Zeitpunkt, der die Verlegung der FRA erforderlich macht: Man hat sich beim Anlegen derselbigen in der erforderlichen Größe verschätzt, und die Platte läuft voll. Oder andere Gründe. Auf jeden Fall muss die FRA aus irgendeinem Grund auf eine andere Platte/Partition verlegt werden – und man fragt sich, wie das wohl am einfachsten zu bewerkstelligen sei.

ScreenshotVerlegen der FRA Der Datenbank mitzuteilen, wo die FRA nun hin soll, ist dabei das kleinste Problem. Aber was soll mit den Dateien am alten Speicherort passieren? Wir können darauf hoffen, dass diese irgendwann "expirieren". Aber aufgrund unserer Retention Policy werden die Datendateien wohl für immer hierbleiben, wenn wir nichts unternehmen. Verschieben wir einfach alles von Hand, findet es RMan beim nächsten Lauf nicht mehr – also was tun?

rman.sh bietet natürlich eine einfache Möglichkeit, sonst würde ich es hier kaum erwähnen. Der "Zauber-Befehl" heißt schlicht rman.sh move_fra, und führt wiederum durch alle nötigen Schritte. Anhand des beiliegenden Screenshots lässt sich auch ersehen, dass ein "Fortschritt" angezeigt wird – der Benutzer also zumindest ansatzweise sieht, wieviel noch zu tun bleibt.

Zuerst wird sicherheitshalber noch einmal nachgefragt, welche Datenbank wir denn behandeln sollen (falls es davon mehrere auf dem Host gibt, und die ORACLE_SID eventuell nicht richtig gesetzt war). rman.sh schaut dann in selbiger nach, wo sich die FRA derzeit befindet, und lässt sich dies nochmals vom Benutzer bestätigen. In der Regel ist diese Angabe bereits korrekt – aber es könnte ja sein, dass der Benutzer zuvor schon manuell Hand angelegt hat, bevor ihm einfiel, rman.sh dafür zu verwenden. Sodann fragt rman.sh nach dem neuen Speicherort, und teilt der Datenbank mit, diesen zu verwenden. Ist das passiert, werden auch die gesamten Dateien vom alten zum neuen Speicherort verschoben – sofern der Benutzer dies bestätigt hat.

Jetzt bleibt noch, RMan die Änderungen mitzuteilen. Dazu werden die "alten" Dateien mittels Crosscheck "expiriert" und aus dem Katalog gelöscht, und schließlich wird RMan angewiesen, alle Dateien am neuen Speicherort zu katalogisieren. Et voila – alles ist wieder "up-to-date", und der Umzug somit abgeschlossen.

Restore

ScreenshotTablespace Restore Jetzt haben wir Backups erstellt, verifiziert, und sogar aufgeräumt – alles bestens soweit. Jedoch was tun, wenn der unerwünschte Fall eintritt, dass in unserer Datenbank etwas kaputt gegangen ist? Ja, sicher: Wir müssen es wiederherstellen.

Da dieser Fall (glücklicherweise) nicht all zu oft eintritt, haben wir die passenden Befehle häufig nicht im Kopf – aber Zeit ist gerade dann knapp, und langes Nachschlagen unerwünscht. Doch wir haben ja unseren kleinen Helfer, der auch hier (hoffentlich) Bescheid weiß! Bleibt dennoch die Frage: Was ist kaputt, was muss wiederhergestellt werden? Und welcher Befehl bringt rman.sh dazu, genau das zu tun?

In all diesen Fällen führt rman.sh sicher durch den Prozess der Wiederherstellung, fragt uns – sofern nötig - nach ein paar Informationen (wie z. B. welcher Tablespace denn repariert werden soll bei restore_ts, die Details zum TEMP Tablespace bei restore_temp, oder Datei- und Blocknummer im Falle von block_recover), und tut die notwendige Arbeit. In Folge sollte das Problem behoben sein.

Erstellen einer Standby Datenbank

ScreenshotStandby DB erstellen Das beste (und komplexeste) zuletzt: Mit rman.sh lässt sich auch eine Standby Datenbank erstellen, wie es (ohne rman.sh) in diesem Artikel beschrieben ist. Und wie gewohnt, wird der Benutzer hier Schritt für Schritt durch den Prozess geführt.

Im ersten Schritt werden die Voraussetzungen genannt – d. h., was das Skript als bereits gegeben ansieht. Das ist nicht so viel, wie vielleicht befürchtet: Auf dem Standby-Host müssen die nötigen Verzeichnisse bereits angelegt sein, deren Struktur denen auf dem primären Host identisch sein muss. Optional (aber empfohlen) sollte auch eine SSH Verbindung vom primären zum Standby Host möglich sein – andernfalls gibt es ein wenig Handarbeit. Dass auf dem Standby Host bereits die Oracle Binaries installiert sein sollten, versteht sich von selbst. Das war's schon – und wir können loslegen.

Jetzt werden ein paar Spezifikationen für die beiden Datenbanken abgefragt (Hostname, SID, TNS), und rman.sh versucht, diese zu verifizieren (tnsping zum Standby-System, Login zur primären DB, …). Falls nötig, wird (natürlich nach Rückfrage) auch die $ORACLE_HOME/network/admin/tnsnames.ora entsprechend ergänzt. Sieht alles soweit gut aus, werden zwei Kopien der init.ora Datei der primären Datenbank erstellt, und entsprechend modifiziert: eine für die primäre, und eine für die Standby-Datenbank. Der Benutzer bekommt nun noch die Chance, diese zu verifizieren – und dann wird, nach erneuter Rückfrage, die entsprechende init.ora zum Standby-System transferriert.

Schritt 3 ist der kürzeste des ganzen Prozesses: Er stellt sicher, dass die primäre Datenbank sich im FORCED LOGGING Modus befindet. Auch wenn sich dieser Schritt überspringen lässt (nur für den Fall, dass er bereits ausgeführt wurde), ist er extrem wichtig: Ohne FORCED LOGGING können per direct write Daten am Logging vorbei manövriert werden – die dann natürlich die Standby-Datenbank nie erreichen. Damit wäre unsere Standby-Datenbank für die Katz – und das wollen wir doch nicht, oder?

Nur zwei Fragen gibt es im vierten Schritt – dennoch kann dieser ein wenig Zeit benötigen: Wir müssen sicherstellen, dass wir über die notwendigen Backups verfügen. Denn diese bilden die Grundlage zum Erstellen der Standby Datenbank. Sicherlich haben wir bereits einige Backups mit rman.sh backup_daily angelegt (und somit den größten Zeitfresser dieses Schrittes eliminiert). Zusätzlich benötigen wir jedoch ein spezielles Backup der Kontrolldatei, welches wir hier erstellen können (und sollten).

ScreenshotDB Status In Schritt Nummer 5 gibt es nur eine einzige Frage – die wir, ein korrektes SSH Setup vorausgesetzt – mit "Ja" beantworten sollten. Womit es dann der Schritt wäre, der die meiste Zeit beanspruchen dürfte: Es werden alle nötigen Dateien vom primären zum Standby-Host transferriert (also Backups, Kontrolldatei und archiviertes Redo). Wer diese Frage mit "Nein" beantwortet, muss dies nun manuell tun (dauert bestimmt genau so lange). Es sei denn, das entsprechende Verzeichnis befindet sich – z. B. Dank NFS - auf beiden Hosts an der gleichen Stelle - dann können wir uns das Kopieren sparen, da die Dateien auf dem Standby Host somit ja auch lokal verfügbar sind. Und nur darauf kommt es hier an.

Wieder schnell gehen sollte Schritt Nummer 6: Bevor wir "Ernst machen" können, sollten wir uns versichern, dass auch die Datenbanken im richtigen Modus laufen. Die primäre Datenbank sollte offen (oder zumindest gemountet) sein, die Standby lediglich gestartet (aber noch nicht gemountet). Ohne ersteres hätten wir in Schritt 4 kaum ein Backup anlegen können – aber die Standby Datenbank haben wir sicher noch nicht gestartet (rman.sh kann dies nach einer Rückfrage für uns erledigen). Der Screenshot zeigt, wie es nun im Idealfall aussieht: Beide Datenbanken befinden sich im korrekten Status, und wir können fortfahren. Lässt sich dieses nicht sicherstellen, bricht das Skript ab – zum Beispiel, wenn sich die Standby-Datenbank bereits im Status "MOUNTED" oder gar "OPEN" befindet: Da wurden dann wohl entweder die falschen Daten eingegeben, oder jemand anderes hat die Standby-Datenbank bereits für uns erstellt …

Alles klar soweit? Dann kommen wir wieder zu unserer Lieblings-Tätigkeit: Zurücklehnen und zuschauen, wie rman.sh die Arbeit für uns erledigt. Treten dabei keine Fehler auf, ist anschließend die Standby Datenbank erstellt und gemounted - und wir müssen lediglich noch das managed recovery starten, sowie die nötigen Änderungen an unserer primären Datenbank durchführen, damit die Standby-DB auch gefüttert wird. Das einfachste ist sicherlich, die derzeitige init.ora durch die neu erstellte zu ersetzen, und die Datenbank durchzustarten. Kommt "durchstarten" (wegen 24/7) gerade nicht in Frage (oder wird ein SPFile verwendet), lassen sich die entsprechenden Veränderungen auch mit ALTER … SCOPE=both; per SQL*Plus durchführen (ohne SPFile entsprechend ohne SCOPE=both).

Gratulation! Jetzt gilt es nur noch, dafür zu sorgen, dass bei einem Rechnerstart die Standby-Datenbank auch wieder das managed recovery aufnimmt. Das tut sie nämlich leider nicht automatisch – also bitte entsprechend in den Startskripten darum kümmern.

Abschluss-Bemerkung

Ich hoffe ich konnte zeigen, dass der Einsatz von RMan nicht zwangsweise kryptisch und kompliziert sein muss. Das RMan Framework sollte speziell Anfängern einen leichten Start geben. Mit der Zeit wächst die Vertrautheit, und man möchte sich vielleicht komplizierteren Dingen zuwenden (die das RMan Framewok nicht abdecken kann) – und entwickelt gar richtig komplizierte Skripte, die weit über das hier beschriebene hinausgehen. Ich würde mich freuen, wenn das RMan Framework hierfür die Grundlagen legen konnte! Wer allerdings das Framework mit eigenen Skripten ergänzt hat, ist herzlich eingeladen, mir diese zu schicken – ich pflege gern das eine oder andere noch mit ein!

Als Nächstes soll gezeigt werden, dass das RMan Framework sich auch für automatisierte Dinge einsetzen lässt – nicht alles erfordert Interaktion, wenn man weiß, was man will …

Nicht-Interaktive Nutzung

Für den "automatischen Modus" seht nur ein Teil der zuvor beschriebenen Befehle zur Verfügung – eigentlich all das, wo man immer nur "Ja" drücken muss (was wir mit der Option --yestoall automatisieren können). Manche Dinge machen hier keinen Sinn, da sie interaktiv Information abfragen müssen (z.B. zur Erstellung der Standby Datenbank). Andere fragen gar nichts, und sind daher prädestiniert für's automatische – z. B. das tägliche Backup.

Für den automatischen Modus müssen wir also einiges erzwingen. Es geht ja nicht nur darum, jede Ja/Nein Frage automatisch mit "Ja" zu beantworten – wir wollen gar nichts mehr gefragt werden, es soll alles automatisch ablaufen. Das Skript soll einfach die Klappe halten, und die Arbeit erledigen. Alles, was wir an Ausgabe brauchen, finden wir ohnehin in der Logdatei – auf dem Bildschirm benötigen wir nichts (sonst schickt uns am Ende Cron jeden Tag ein paar Mails, die wir ohnehin nur löschen). Also packen wir zum --yestoall auch gleich noch dreimal -q: Kein STDOUT von aufgerufenen Programmen, STDERR von jenen ebensowenig und, zu guter Letzt, auch kein Kommentar von rman.sh selbst.

Auf die GUI können wir bei automatischen Läufen gut verzichten – was wir mit den drei -q implizit getan haben: Ab dem zweiten verzichtet rman.sh bereits auf die angenehmere, mit dialog erstellte GUI – und logged mit dem "plain text mode" lediglich noch auf den Bildschirm, was wir mit dem dritten -q auch abgestellt haben. Wer also trotz automatisiertem Lauf noch was auf dem Schirm haben will, gibt nur zweimal -q mit.

Befehle für automatisierte Läufe

Folgende Befehle sind für automatisierte Läufe (z. B. via Cron) sinnvoll:

Dass backup_daily und cleanup_obsolete sinnvolle automatische Wartungsaufgaben sind, liegt auf der Hand. Was aber sollen crosscheck und validate hier? Nun, gerade bei größeren Datenbanken brauchen auch diese Befehle einige Zeit, um vollständig durchzulaufen. Das Zuschauen macht vielleicht zu Anfang noch Spaß – aber irgendwann ist man sicher froh, nur noch schnell einen Blick auf das dabei erzeugte Logfile werfen zu müssen – ohne erst lange darauf zu warten.

Ein automatisches Restore hingegen halte ich nicht nur für wenig nützlich (es sei denn, jemand packt noch ein passendes "destroy" irgendwo in die Crontab), sondern auch wenig sinnvoll – hier muss man ohnehin anschließend sicherstellen, dass auch alles erfolgreich war. Was auch für einge andere Befehle gilt – die daher hier nicht genannt sind.

2020-11-18