Oracle Datenbank Sicherungen
auf Basis von NetApp Filern mit Snapshots, SnapMirror, SnapVault
und NetWorker NDMP Sicherungen
Uwe W. Schäfer
Schäfer & Tobies Software u. Consulting GmbH Stand: 01. Dez. 2011
Version 1 RC
Beschreibung des Verfahrens
NetApp bietet auf seinen Storage-Systemen die Möglichkeit in Sekundenbruchteilen einen Snapshot des gesamten Volumes zu erzeugen, hierbei ist die Größe des Volumes (Filesysteme) nahezu beliebig.
Dieser Snapshot bietet anschließend eine Readonly-Kopie des gesamten Volumes und kann im folgenden auf ein weiteres Storagesystem gespiegelt oder mit dem NDMP Protokoll direkt von dem Storagesystem konsistent gesichert werden.
Das hier beschriebene Tool bietet beide Möglichkeiten der Weiterverarbeitung.Vorteile gegenüber herkömmlichen Datenbanksicherungsmethoden
Aus Sicht der Datenbank ist die Online-Sicherung beendet, wenn der NetApp Snapshot generiert wurde. Das bedeutet die eigentliche Datensicherung ist in Sekunden beendet. Selbst die anschließend mögliche Bandsicherung wird vom Storagesystem bzw. von einem weiteren Nearstore-System ausgeführt, die Datenbankmaschine wird folglich durch die Bandsicherung nicht belastet. Dieses Verfahren wird auch als "Serverless Backup" bezeichnet.
Der Zyklus der Sicherungen kann durch dieses Verfahren von einem Tag (eine Sicherung pro Tag=) auf einige Stunden (mehrere Sicherungen pro Tag) verkürzt werden, ohne dass hierdurch die Geschwindigkeit und die Verfügbarkeit der Datenbank merklich beeinträchtigt wird. Der Vorteil eines kürzeren Zyklus (z.B. Sicherung alle 4 Stunden) besteht in erheblich kürzeren Recoveryzeiten bei Datenbankfehlern, da nur die zwischen den Zyklen anfallenden Redologs eingespielt werden müssen.
Schnelles Recover: Ein Recover der Oracle Datenbank kann auf den existierenden Snapshots aufsetzen. Hierbei ist das Wiederherstellen eines gesicherten Datenbankstandes in wenigen Sekunden möglich. Man spart das gesamte Einlesen einer Bandsicherung.
Einfache und schnelle Duplizierung von Datenbanken. Auf Basis der NetApp Kommandos kann man die gesicherten Datenbankstände auch zum Duplizieren einer Produktionsdatenbank in eine Testdatenbank verwenden. Auch dieses Verfahren wird hierdurch erheblich beschleunigt. Selbst eine Halbautomatisierung von solchen Duplikaten wird hierdurch leicht möglich.
Besonderheiten bei der Sicherung von SAP/R3 Datenbanken
Für die Sicherung von SAP/R3 Datenbanken gibt es im Gegensatz zur nativen Oracle Sicherung die Möglichkeit die Datenbank auch "OFFLINE" zu sichern. Hierbei wird, vor der Erzeugung des Snapshot das definierbare Skript "stopsap" und nach dem erfolgten Snapshot das Skript "startsap", mit einem definierten Benutzer (SAP_USER) gestartet (siehe Konfiguration).
Zusätzlich zu den oben erwähnten Skripten, gibt es zusätzlich die Möglichkeit, mit Hilfe von 4 definierbaren Variablen beliebige Skripte vor und nach dem Stoppen bzw. vor und nach dem Starten der SAP Umgebung auszuführen (siehe Konfiguration).
Besonderheiten bei der Sicherung von Oracle-RAC Datenbanken
Wenn eine RAC Datenbank (Konfigurationsparameter RAC=1) gesichert wird, so wird mit Hilfe des Oracle Kommandos "srvctl" überprüft, welche Instanzen der DB zurzeit online sind. Sollte die Instanz auf der die Sicherung definiert wurde nicht online sein, so wird versucht, die Sicherung von einer anderen Instanz durchzuführen. In keinem Fall wird eine Instanz oder die gesamte Datenbank gestartet oder heruntergefahren!
Voraussetzungen
Die zu sichernden Oracle Datenbanken müssen folgende Voraussetzungen erfüllen, um mit Hilfe von NetApp Snapshots und NetWorker NDMP gesichert werden zu können:
Oracle DB
- Tablespacedateien
Alle Datenbankdateien müssen auf einem NFS gemounteten NetApp Volume liegen.- Onlinelogs
Die Onlinelogdateien der Datenbank dürfen nicht zusammen mit einer Tablespacedatei auf einem Volume liegen.
- Archivelogs
Das Archivelog Verzeichnis darf nicht zusammen mit einer Tablespacedatei auf einem Volume liegen.- Login als Root User
Es muß sichergestellt sein, daß der Benutzer root sich ohne Paßwort an der Datenbank anmelden kann, wenn er die gid der UNIX-Gruppe der Datenbank besitzt.
Ein einfacher Test läßt sich durch folgende Umgebung und Kommandos durchführen:# export ORACLE_SID=JOY
# export ORACLE_HOME=/oracle/JOY/920_64
# newgrp dba
# export LD_LIBRARY_PATH=$ORACLE_HOME/lib
# $ORACLE_HOME/bin/sqlplus "/ as sysdba"SQL*Plus: Release 9.2.0.6.0 - Production on Tue Apr 3 09:29:26 2007
Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.
Connected to:
Oracle9i Enterprise Edition Release 9.2.0.6.0 - 64bit Production
With the Partitioning and OLAP options
JServer Release 9.2.0.6.0 - ProductionSQL>
- RAC Sicherung
Bei einer RAC Sicherung wird lediglich eine Instanz der Datenbank im NetWorker konfiguriert. Der Benutzer "root" dieser Instanz muss die Erlaubnis besitzen, Kommandos mit Hilfe einer SSH-Verbindung auf allen anderen Instanzen der Datenbank starten zu können. Zusätzlich muss für jede Instanz die NetApp API Erlaubnis definiert sein (s.u.).Filer
Der NetApp Filer muss folgende Voraussetzungen erfüllen:
Lizenzen
Für die verschiedenen Methoden werden NetApp Lizenzen benötigt:
| SNAP Restore: | wird für das schnelle Wiederherstellen einer Datenbank benötigt. Diese Lizenz wird auf dem DB-Storage Filer benötigt. |
| SNAP Mirror | Spiegeln der Datenbank auf einen Nearstore Filer; Diese Lizenz wird auf dem Storage Filer und dem Spiegel Filer Nearstore benötigt. |
| SNAP Vault Primary | Sichern der Datenbank auf einen Nearstore Filer. Diese Lizenz wird nur auf dem DB-Storage Filer benötigt. |
| SNAP Vault Secondary | Diese Lizenz wird nur auf dem Nearstore Filer benötigt. |
| Flex Clone | Diese Lizenz wird für das komfortable Duplizieren von Datenbanken benötigt. (Zurzeit noch nicht implementiert) |
Snapmirror KonfigurationWenn die Datenbank für Sicherungszwecke gespiegelt werden soll, muss die SnapMirror Verbindung in der snapmirror.conf Datei konfiguriert sein. Da das Tool den Namen der Snapshots und deren Verwendung selbst bestimmen möchte wird hier ein Qtree SnapMirror Konfiguration verlangt. Die Konfiguration sollte auch keine automatische Synchronisation des Spiegels verwenden. Da diese ja immer inkonsistent wäre.
Beispiel: (eine Zeile)
nstore1:/vol/sapjoydb/- nstore2:/vol/sm_sapjoydb_sm/JOY - - - - -
Ebenso muss die Initialisierung der Mirror Beziehung bereits durchgeführt worden sein.
ssh nstore2 snapmirror initialize nstore2:/vol/sm_sapjoydb_sm/JOY
SnapVault KonfigurationWenn die Datenbank mit dem NetApp SnapVault Verfahren gespiegelt werden soll, muss die SnapVault Beziehung zwischen dem Primary und dem Secondary bereits konfiguriert sein.
API Erlaubnis für die DB-Maschine
Das Tool verwendet für die Kommunikation die NetApp eigene API Schnittstelle. Hierfür werden jedoch zwangsläufig definierte Rechte verlangt:
options httpd.admin.hostsequiv.enable on
User root des DB-Rechners muss RSH-Berechtigung haben:
Eintrag in der /etc/hosts.equiv
Der Rechner muss Erlaubnis haben http zu verwenden. Hierzu ist u.U. ein Eintrag in der Option "trusted host" notwendig!
Ein einfacher Test dieser Voraussetzung läßt sich mit folgender Umgebung und Kommando erzielen:
# export LIB_PERL=/nsr/SAPbackup/lib/perl
# $LIB_PERL/vol_options.pl <filer> <vol>Erfolgloser Versuch:
# $LIB_PERL/vol_options.pl nstore2 sapjoydb
volume-options-list-info failed: Zapi::parse_xml - Expected <netapp> element, but got HTMLErfolgreicher Versuch:
# $LIB_PERL/vol_options.pl nstore2 sapjoydb
snapmirrored=off
root=false
resyncsnaptime=60
raidtype=raid_dp.....
Bei einer RAC Datenbank muss die API-Erlaubnis für jede Instanz konfiguriert werden.
NetWorker
Für den Start der Sicherung werden einige NetWorker Ressourcen benötigt.
Client Definitionen
Für jede Datenbank werden ein oder mehrere NetWorker Client Konfigurationen benötigt.Die Idee ist, dass ein Client für die ausschließliche Snapshot Sicherung definiert werden kann und ein zweiter Client die Bandsicherung initiiert. Welche Sicherung gewünscht wird steuert der angegebene SaveSet.
Group Definitionen
Für jeden Client wird eine eigene Gruppe benötigt. Eine Gruppe startet u.U. mehrmals am Tag, die andere lediglich einmal und sichert dann die DB auf Tape.Schedule Definitionen
Da es sich nicht um "normale" NetWorker Sicherungen handelt benötigen wir immer den Level Full.Konfiguration
Tool Konfiguration
Für die nativen Oracle-Datenbanken gibt es wegen der unterschiedlichen Installationsvarianten und der Ausprägung 'RAC' zusätzliche und zum Teil andere Parameter als bei den SAP/R3 Installationen. Daher folgen 3 Tabellen, in denen einmal die allgemeingültigen Parameter und anschließend die jeweils spezifischen Parameter erklärt werden.
Allgemeingültige Parameter
|
Parameter
|
Erklärung
|
| ORACLE_HOME=/oracle/JOY/920_64 | Wird zur Kommunikation mit der DB benötigt; Unterhalb von HOME muss das Verzeichnis lib liegen. |
| DB_INFO="IDES ERP ECC 5.0" | Bezeichnung des SAP Systems |
| DB_TYPE="Training System" | Type des SAP Systems; z.B. Produktiv | Training |
| NR_SNAPSHOTS=5 | Anzahl der Snapshots, die auf dem Primär Storage-System gespeichert werden sollen |
| NR_MIRROR_SNAPSHOTS=5 | Anzahl der Snapshots, die auf dem Nearstore Storage-System gespeichert werden sollen; Wenn SnapMirror verwendet werden soll |
| NSR_SERVER=<server> | |
| NSR_POOL=I2KPDB_21DAYS | NetWorker Pool, in dem die Sicherung gespeichert werden soll |
| # NSR_DSA_SAVE= | zukünftige Alternative wenn die Daten nicht am Filer lokal gesichert werden können (noch nicht implementiert) |
| SNAPM_DEST_FILER=nstore2 | Name des NetApp Filers auf den die DB gespiegelt werden soll. Die SnapMirror Beziehung muss allerdings bereits aufgebaut worden sein. (Der Parameter darf leer sein, wenn keine SnapMirror Beziehung gewünscht wird) |
| SNAPM_QTREE_NAME=/vol/sappa3sgn/- |
Wenn die SnapMirror Beziehung nicht dem Standard entspricht, kann mit Hilfe dieser Variable eine Vorgabe für die SnapMirror Source vorgegeben werden. Der Standard heißt:
|
| # SNAPV_DEST_FILER=nstore1 | Name des Nearstore Filers auf den SnapVault durchgeführt werden soll. Die SnapVault Beziehung muss allerdings bereits aufgebaut worden sein. (Der Parameter darf leer sein, wenn keine SnapVault Beziehung gewünscht wird) |
| SNAPV_QTREE_NAME= |
Wenn die SnapMirror Beziehung nicht dem Standard entspricht, kann mit Hilfe dieser Variable eine Vorgabe für die SnapMirror Source vorgegeben werden. Der Standard entspricht dem SnapMirror Standard (siehe SNAPM_QTREE_NAME) |
| SNAPV_BASE_FILER | Bei V-Filern geht zurzeit kein "snapvault-get-status". Wird in dem Fall der Parameter SNAPV_BASE_FILER definiert, so werden die SnapVault Aufrufe mit dem angegebenen Base-Filer durchgeführt |
| SNAPV_COMMUNICATION_FILER | Wir haben mit VFilern zurzeit das Problem, dass nicht alle API Funktionen vorhanden sind (s.o.). Bei DMZ Maschinen kommen wir aber auch nicht an den BASE_FILER, daher kommunizieren wir hier nur mit dem Destination Filer SNAPV_COMMUNICATION_FILER. Das sollte ein physikalischer Filer sein zudem bereits eine Snap-Beziehung für den DB-Bereich existiert. |
| DMZ_DELAYED_SAVE | Die Sicherung bei VFiler in einer DMZ geht zurzeit noch nicht :-( (s.o.). Aus dem Grunde wird der Protokoll Bereich auf einen physikalichen Filer gespiegelt. Von Hier aus kann dann der Mirror/Vault gesichert werden. Die Initierung wird durch den Parameter DMZ_DELAYED_SAVE ausgelöst. Die eigentliche Sicherung muß über einen extra Client einer Backup Maschine erfolgen (s.u.). |
| ONLY_SNAP_RETENTION_DAYS=6 | Aufbewahrungszeit der Snapshots auf dem primär System; (Der Parameter darf leer sein) |
| SNAP_MIRROR_RETENTION_DAYS=7 | Aufbewahrungszeit des Snapshots auf dem Mirror Volume; (Der Parameter darf leer sein) |
| SNAP_VAULT_RETENTION_DAYS= | Aufbewahrungszeit des Snapshots auf dem Vault Volume; (Der Parameter darf leer sein) |
| NSR_NDMP_RETENTION_DAYS=21 | Aufbewahrungszeit der NDMP Sicherungen auf den NetWorker Bändern; (Der Parameter darf leer sein) |
| RETENTION_DAYS=10 | Default Aufbewahrungszeit. Dieser Wert wird immer dann herangezogen wenn einer der oben angegebenen Retention Werte nicht gesetzt ist. |
| PRE_STOP_CMD | Kommando das vor dem Herunterfahren der SAP Instanz gestartet werden soll. Der Kommandostring kann als Platzhalter die Zeichenfolge "%s" enthalten. Diese Paramter werden vor dem Kommdoaufruf mit den zugehörigen PRE_STOP_ARGS Werten gesetzt |
| PRE_STOP_ARGS | Argumente für das PRE_STOP_CMD. Wenn mehrere Argumente gebraucht werden sind diese durch ein "," voneinander zu trennen. Es können auch mehr Argumente als benötigt angegeben werden. In dem Fall wird das PRE_STOP_CMD mehrmals mit den einzelnen Argumenten aufgerufen. |
| POST_STOP_CMD | Kommando das nach dem herunterfahren der SAP Instanz gestartet werden soll. Der Kommandostring kann als Platzhalter die Zeichenfolge "%s" enthalten. Diese Paramter werden vor dem Kommdoaufruf mit den zugehörigen POST_STOP_ARGS Werten gesetzt |
| POST_STOP_ARGS | Argumente für das POST_STOP_CMD. Wenn mehrere Argumente gebraucht werden sind diese durch ein "," voneinander zu trennen. Es können auch mehr Argumente als benötigt angegeben werden. In dem Fall wird das POST_STOP_CMD mehrmals mit den einzelnen Argumenten aufgerufen. |
| PRE_START_CMD | Kommando das nach dem herunterfahren der SAP Instanz gestartet werden soll. Der Kommandostring kann als Platzhalter die Zeichenfolge "%s" enthalten. Diese Paramter werden vor dem Kommdoaufruf mit den zugehörigen PRE_START_ARGS Werten gesetzt |
| PRE_START_ARGS | Argumente für das PRE_START_CMD. Wenn mehrere Argumente gebraucht werden sind diese durch ein "," voneinander zu trennen. Es können auch mehr Argumente als benötigt angegeben werden. In dem Fall wird das PRE_START_CMD mehrmals mit den einzelnen Argumenten aufgerufen. |
| POST_START_CMD | Kommando das nach dem herunterfahren der SAP Instanz gestartet werden soll. Der Kommandostring kann als Platzhalter die Zeichenfolge "%s" enthalten. Diese Paramter werden vor dem Kommdoaufruf mit den zugehörigen POST_START_ARGS Werten gesetzt. |
| POST_START_ARGS | Argumente für das POST_START_CMD. Wenn mehrere Argumente gebraucht werden sind diese durch ein "," voneinander zu trennen. Es können auch mehr Argumente als benötigt angegeben werden. In dem Fall wird das POST_START_CMD mehrmals mit den einzelnen Argumenten aufgerufen. |
| SAVEPROT_COUNT=100 |
Anzahl von zu haltenden Protokollen (s.u.). |
SAP/R3 spezifische Parameter
/nsr/SAPbackup/config/<ORACLE_SID>
Für jede zu sichernde Datenbank wird im Verzeichnis /nsr/SAPbackup/config eine Datei mit dem Namen der ORACLE_SID benötigt.
|
Parameter
|
Erklärung
|
| ORACLE_SID=JOY | Oracle Datenbank ID |
| SAP_USER=joyadm | Benutzerid des SAP Users; wird benötigt um Offline Sicherungen durchzuführen |
Native Oracle spezifische Parameter
/nsr/SAPbackup/ora_config/<ORACLE_SID>
Für jede zu sichernde Datenbank wird im Verzeichnis /nsr/SAPbackup/ora_config eine Datei mit dem Namen der ORACLE_DB benötigt.
|
Parameter
|
Erklärung
|
| RAC=[0 | 1] | Handelt es sich um eine Oracle RAC DB. In dem Fall muss der Parameter ORACLE_DB statt dem Parameter ORACLE_SID gesetzt werden. |
| ORACLE_DB=LB10 | Name der Oracle Datenbank bei RAC Installationen. Die jeweilige ORACLE_SID wird vom Tool selbst ermittelt. |
| ORACLE_SID= | Oracle Datenbank ID. Wird nur bei nicht RAC Datenbanken benötigt. |
| ORA_NLS10 | Oracle spezifischer I18N Parameter. Wird bei manchen Installationen benötigt. |
| SAP=0 | zwingend erforderlicher Parameter bei nicht SAP DBs |
NetWorker Konfiguration
Für jede gewünschte Sicherungsart müssen im NetWorker ein bzw. mehrere Ressourcen konfiguriert werden
Client Resource
Neben den bekannten Attributen wie Name; Browse- und Retention Policy sind folgende Attribute besonders zu betrachten:
Group Resource
Für jeden BACKUP_TYPE und u.U. für die beiden Typen ONLINE und Offline Sicherung muss eine eigene NetWorker Gruppe definiert werden!
Hierbei empfiehlt sich für den Typ ONLY_SNAP bzw. SNAP_MIRROR das Attribut Intervall zu ändern, wenn mehr als eine Sicherung pro Tag gewünscht wird!
ACHTUNG in dem Fall muss auch das Attribut "force incrementell" auf "No" gesetzt werden!
DMZ DB Sicherungen
Bei einer DB in einer DMZ ist der Zugriff auf das Volume /vol/nsrapp nicht möglich. Daher muss die DB-Maschine eine Kopie des Volumes auf einem Qtree des zugehörigen V-Filers mit dem benötigten Inhalt (Programme und Protokollbereich) des SAPbackup Verzeichnisses erhalten. Eine Spiegelung der Daten geht zurzeit nur mit SnapVault gegen einen physikalischen Filer, da das V-Filer API noch keine Funktion für "snapvault" enthält. Hierfür wird der Parameter SNAPV_COMMUNICATION_FILER benötigt.
NDMP Sicherungen der DB gehen ebenfalls nicht direkt von der DB- Maschine der DMZ, da die Dreiecksbeziehung NetWorker-Server, NetWorker-Client (DB Masch.) und Filer nicht funktionieren kann. Der NetWorker Server benötigt einen NSRMMD Prozess auf dem Server für den V-Filer. Der NetWorker-Server kann den V-Filer der DMZ aber nicht erreichen :-(. Das ganze geht aber auch nicht vom Base-Filer, weil die DMZ Maschine ja nicht mit der IP des Filers aus dem nicht DMZ Bereich reden kann.
Soll die DB dennoch auf Band gesichert werden, werden einige zusätzliche Konfigurationen benötigt:
- Der SAPbackup Qtree des V-Filers muss auf das Volume /nsr/nsrapp gemirrored werden.
- Für die DB muss ein Client und eine Gruppe mit dem SaveSet ....<DB>_NDMP_LATER eingerichtet werden.
- Für den Sicherungsserver muss ein Client mit dem SaveSet ...<DB>_NDMP_DELAYED eingerichtet werden.
- In der Konfiguration muss der Parameter DMZ_DELAYED_SAVE eingetragen werden.
Folgende symbolische Links werden aus dem gespiegelten Qtree in das /vol/nsrapp Verzeichnis benötigt:
ln -s /nsr/NSRAPP/dmzfiler/ORAsaveprot/DBDMZ /nsr/NSRAPP/SAPbackup/ORAsaveprot/DBDMZ
ln -s /nsr/NSRAPP/dmzfiler/ora_config/DBDMZ /nsr/NSRAPP/SAPbackup/ora_config/DBDMZ
dmzfil7 ist hierbei der Mirror Qtree und REPDMZ der Name der DB (Oracle SID).
Für die WWW Überwachung der Sicherung wird folgender zusätzlicher Link auf der "Fromage" benötigt
ln -s /nsr/NSRAPP/dmzfiler /nsr/DMZten/dmzfiler
Überwachung:
Für die Überwachung der DMZ DB-Sicherungen gibt es auf der WWW Seite "http://webserver/ora/" am Ende einen eigenen Bereich für die DMZ Datenbanken.
Protokollierung
Jede Sicherung wird in einem eigenen Verzeichnis protokolliert. Die Verzeichnisse werden für SAP/R3 DBs unterhalb des Verzeichnisses "/nsr/SAPsaveprot/<ORACLE_SID>" und für "native Oracle DBs" unterhalb des Verzeichnisses "/nsr/ORAsaveprot/<ORACLE_SB>", mit dem Zeitstempel des Sicherungsstarts angelegt.
Der Zeitstempel hat das Format: YYYYMMDD_HHMM
Die Anzahl der hier aufbewahrten Verzeichnisse richtet sich nach dem Konfigurationsparameter SAVE_PROT_COUNT.
Am Ende einer erfolgreichen Sicherung der DB wird das entstandene Verzeichnis mit dem NetWorker Save Kommando gesichert.
Beispiel:
/nsr/SAPsaveprot/JOY/20070319_0800
Unterhalb dieses Verzeichnisses existieren 3 Unterverzeichnisse:
CONTROL
Hier werden zwei Kopien der ControlDateien der DB in Binarie und in ASCII Form hinterlegt.
control_bin.ctl
control.trclogs
Hier wird in der Datei SAP_save.dbg der Verlauf des Sicherungsvorgangs protokolliert.
other_ora_files
Hier werden zurzeit folgende Oracledateien während der Sicherung hinkopiert:
Alertfile der DB: alert_<ORACLE_SID>.log
Initfile der DB: init<ORACLE_SID>.ora
pfile.bck
spfile.bck
Bei SAP/R3 DBs zusätzlich: SAP init File: init<ORACLE_SID>.sap
Überwachung
Für eine leichte Kontrolle und einen Überblick der Sicherungen zu erhalten, wurde ein eigener WWW-Server aufgesetzt, der die Überwachung der Datenbanksicherungen auf mehreren WWW-Seiten ermöglicht.
Der WWW-Server hat das Konfigurationsvolume der nstore1 sowie den Spiegel der Site2-Konfiguration gemountet. Die Konfiguration der Site2 wird für diesen Zweck, mittels SnapMirror vom nafiler6 auf nstore1:/vol/nsrapp/site2 gespiegelt.
Unter folgenden URLs findet man die Protokollierung, sowie Konfigurationsmöglichkeiten für die einzelnen DBs.
| SAP / R3 Zentrale |
http://webserver/sap |
| SAP / R3 Site2 |
http://webserver/sap2 |
| Oracle DBs | http://webserver/ora |
Auf diesen WWW-Seiten erhält man als erstes einen Überblick über die zuletzt gelaufenen Sicherungen aller definierten Datenbanken. Hierbei werden für die 4 Sicherungsarten "Snapshot", "Snapmirror", "SnapVault" und "NDMP" jeweils die letzten Sicherungszeiten ausgegeben. Wenn die Sicherung erfolgreich war wird die Sicherungszeit grün hinterlegt bei einer fehlerhaften Sicherung ist die Darstellung rot hinterlegt. Der WWW-Link hinter dem Namen der Datenbankinstanz (Oracle-SID) führt zu einer weiteren WWW-Seite auf der alle noch verfügbaren Sicherungen der jeweiligen DB aufgelistet werden. Hier werden zusätzlich zum Sicherungsstart die Endzeiten der jeweiligen Sicherungsstufen angezeigt. Jede Zeitangabe verweist hierbei auf das zugehörige Protokoll.
Die genaue Erklärung der WWW-Seiten ist auf den jeweiligen Seiten selbst (unten rechts) hinterlegt. (noch nicht implementiert)
Recover
Datenbank-Recovery aus Sicht des Anwenders
Hintergrundwissen
Eine Oracle Datenbank kann nur dann durch ein Datenbank-Recovery wieder hergestellt werden, wenn
- regelmäßig Sicherungen der Datenbank gemacht,
- die Änderungen an der Datenbank, die sogenannten archived redo logs, gesichert wurden und
- die Vorgehensweise und das Recovery-Kommando mit seinen Optionen bekannt ist, d.h die Dokumentation rechtzeitig (und nicht erst im Ernstfall) gelesen wurde.
Sicherungen
Die Sicherungen der Datenbank-Dateien werden durch Snapshots auf dem Primären-NetApp Filer gemacht. Bestimmte Snapshots werden zur Verlängerung der Aufbewahrungszeit mit SnapVault auf den Sekundären-Filer gesichert. (Mit dem NDMP- Protokoll kann, sowohl vom Primären-, als auch vom Sekundären-Filer, mit NetWorker auf Band gesichert werden.)
Die archived redo logs (Log-Dateien mit den Änderungen an der Datenbank) werden periodisch
- entweder durch NSR-AMON mit dem NetWorker save Kommando gesichert
- oder mit log_save durch verschieben vom Archivierungs-Verzeichnis in das log_save Ziel-Verzeichnis mit ndmpcopy und ggf. von dort mit dem NetWorker save Kommando gesichert.
Datenbank-Recovery-Szenarien
Im wesentlichen gibt es 2 Szenarien, die ein Datenbank-Recovery erfordern:
-
Ein Benutzer der Datenbank hat einen Fehler gemacht und die Datenbank muss auf einen früheren Zustand (Zeitpunkt) zurück gesetzt werden.
Man spricht hier von Until-Time-Recovery.
Zur Korrektur wird zuerst eine Sicherung, die vor dem Zeitpunkt gemacht wurde, eingespielt. Danach wird die Datenbank mit den aufgezeichneten Änderungen bis zu diesem Zeitpunkt durch Oracle wieder hin gefahren. -
Die Datenbank ist korrupt oder bleibt stehen, weil in Software oder Hardware des Rechners ein Fehler aufgetreten ist oder versehentlich eine wichtige Oracle-Datei gelöscht wurde. Die Datenbank kann meist komplett wieder hergestellt werden.
Man spricht hier von Complete-Recovery.
Zur Korrektur wird der Fehler in der Datenbank gesucht. Je nach Problem werden entweder Oracle-Dateien wieder hergestellt, und/oder der letzte Snapshot eingespielt. Danach wird die Datenbank mit den aufgezeichneten Änderungen bis zum aktuellen Zeitpunkt durch Oracle wieder hin gefahren.
Was zu tun ist, sollte immer von einem Oracle Datenbank Administrator festgelegt werden, da es auch Fehlersituation (stehende Datenbank) gibt, die durch Anweisungen an Oracle korrigiert werden können.
Recovery-Ablauf
Beide Datenbank-Recovery-Szenarien werden, gesteuert durch den Benutzer, mit dem Kommando recover.py durchgeführt. Den Ablauf des Kommandos kann man in mehrere Schritte unterteilen:
-
Auftrag definieren: Im Dialog werden die Bezeichnung der Datenbank, der Modus des Recovery (Until-Time oder Complete) und die zu verwendende Sicherung bestimmt. Eventuell unterstützt durch Optionen der Kommandozeile.
-
Stoppen von (Applikation und) Oracle – erst ab hier erfolgt der Zugriff auf die Datenbank.
-
Erster Blick auf die Datenbank: Bei Complete-Recovery - was fehlt, oder ist defekt.
-
Daten-Dateien wieder herstellen durch einspielen eines Snapshots von einem der Filer oder vom Band.
-
Wiederherstellen der Datenbank durch Oracle recover database, mit einspielen der Änderungen in den archived redo logs.
-
Starten von Oracle (und Applikation).
Nach der Definition des Auftrags, kann recover.py das Datenbank-Recovery (eigentlich) automatisch durchführen.
Recovery Beschreibung
Im folgenden wird ein Until-Time- und ein Complete-Recovery detailliert beschrieben. Dazu gehören die Ausgaben des Kommandos und die notwendigen Eingaben der Anwenders.
Voraussetzung
Vor dem Starten eines Recovery muss
-
die Applikation (SAP) gestoppt werden und
-
die Hochverfügbarkeit, falls vorhanden, eingefroren (freeze) werden.
Until-Time-Recovery
Das Beispiel zeigt ein Until-Time-Recovery der Datenbank NA102 bis zum Zeitpunkt: am 07.09.2011 um 09:12:00 Uhr.
Links steht die Ausgabe des Kommandos, mit den Eingaben des Anwenders in Fett. Eingerückt sind Erläuterungen zum Ablauf.
# ./recover.py
1. Schritt: Auftrag definieren:
Local ORACLE_SIDs:
1 NA102
2 DB102
ORACLE_SID or Quit [nr|q] > 1
Die ORACLE_SID der Datenbank, die bearbeitet wird. Ist nur eine Datenbank auf dem Rechner, dann wird diese (ohne Auswahl) bearbeitet.
Bei der Auswahl ist immer ein Quit [q] mit dabei, damit jederzeit abgebrochen werden kann.
Type of Recovery:
c – Complete
t – Until-Time
q – quit
Recovery type > t
Recover until time (Oracle format YYYY-MM-DD:HH24:MI:SS) > 2011-09-07:09:12:00
Until-Time-Recovery benötigt noch die Angabe des Zeitpunktes in Oracle-Notation: das Format ist YYYY-MM-DD:HH24:MI:SS
mit YYYY das Jahr, MM der Monat, DD der Tag im Monat, HH24 die Stunde (24), MI die Minute und SS die Sekunde.
Start NA102 recovery UNTIL-TIME 2011-09-07:09:12:00
Options: using backup controlfile
Options: beschreibt die gewählten und voreingestellten Optionen. Weiter unten werden weitere Optionen und Parameter (Konfigurations-Datei) vorgestellt.
Debug directory /nsr/SAPbackup/SAPrecoverprot/NA102/20110907_1012
Available Backups:
SNAPSHOT 20110907_0851
Please choose: Snapshot [s], Quit [q] > s
Bei Until-Time-Recovery wird die nächste, vor dem Zeitpunkt liegende, Sicherung gezeigt. Solange Snapshots vorliegen, wird ein Snapshot angeboten. Erst dann wird, falls vorhanden, auf SnapVault- oder NDMP Band-Sicherungen zurückgegriffen. Je weiter man in der Zeit zurückgehen muss, desto wahrscheinlicher wird die Verwendung von SnapVault- oder NDMP-Sicherungen. Entsprechend ist dann die Laufzeit des Recovery.
Using SNAPSHOT backup of 220110907_0851
Initial phase done - well then?
Continue or Quit [<return>|q] > ↵
Analoge Zeilenpaare „... done – well then?“ und „Continue or Quit ...“ sind nach fast jedem Schritt des Ablaufs eingebaut. Sie ermöglichen die Kontrolle der Debug-Dateien, können aber durch den Parameter RECOVERY_TEST_STOP der Konfigurations-Datei /nsr/SAPbackup/[ora_]config/<ORACLE_SID> aus- oder eingeschaltet werden.
2. Schritt Stoppen von (Applikation und) Oracle:
Der Zustand der Datenbank (hochgefahren oder gestoppt) ist beliebig.
Oracle shutdown abort done
3. Schritt: Erster Blick auf die Datenbank:
Check current state of database
Online redo log 1: /oracle/oradata/NA102/online/redo01.log [1, 305, 758883868]
Online redo log 2: /oracle/oradata/NA102/online/redo02.log [1, 304, 758883868]
Online redo log 3: /oracle/oradata/NA102/online/redo03.log [1, 303, 758883868]
Orafile /home/oracle/10.2.0/dbs/initNA102.ora ok
Orafile /home/oracle/10.2.0/dbs/orapwNA102 ok
Oracle spfile </home/oracle/10.2.0/dbs/spfileNA102.ora> ok
ora_startup: nomount done
ora_shutdown: shutdown done
ora_startup: mount done
ora_shutdown: shutdown done
Save control file </oracle/oradata/NA102/temp/control01.ctl> to </nsr/SAPbackup/SAPrecoverprot/NA102/20110907_1012/other_ora_files/copy_of_cf>
Mount sim801-3:/vol/nsr_disk_backup/NA102 to /data/oradata/NA102/arch done
Werden archived redo logs vom log_save Ziel-Verzeichnis benötigt, dann wird jetzt diese montiert. Es sind dann 2 NFS-Datei-Systeme unter dem Archivierungs-Verzeichnis montiert: das eigentliche Archivierungs-Verzeichnis und darüber das log_save Ziel-Verzeichnis.
NetWorker determination of saved archived redo logs
WARNING: /oracle/oradata/NA102/arch/1_296_758883868.dbf NOT in NetWorker Index!
Einschub: Archived redo logs, die weder im Archivierungs-Verzeichnis noch im log_save Ziel-Verzeichnis sind und die zwischen der verwendeten Sicherung und dem Ziel erzeugt wurden, werden mit NetWorker (nsrinfo und mminfo) gesucht und später mit NetWorker recover wieder eingespielt. Dieser Vorgang wird nicht weiter beschrieben.
First look to database done - well then?
Continue or Quit [<return>|q] > ↵
4. Schritt: Daten-Dateien wieder herstellen – hier mit Snapshot.
Restore SNAPSHOT
SNAPSHOT done
Restore done - well then?
Continue or Quit [<return>|q] > ↵
5. Schritt: Wiederherstellen der Datenbank:
Copy control file /nsr/SAPbackup/SAPsaveprot/NA102/20110907_0851/CONTROL/control_bin.ctl.gz
Copy /nsr/SAPbackup/SAPsaveprot/NA102/20110907_0851/CONTROL/control_bin.ctl.gz to /oracle/oradata/NA102/temp/control01.ctl
Copy /oracle/oradata/NA102/temp/control01.ctl to /oracle/oradata/NA102/online/control02.ctl
Copy /oracle/oradata/NA102/temp/control01.ctl to /oracle/oradata/NA102/cntrl/control03.ctl
ora_startup: mount done
alter database recover automatic database until time '2011-09-07:09:12:00' using backup controlfile
Oracle-Error-Code: 279
Oracle-Error-Message: <ORA-00279: change 1396904 generated at 09/07/2011 08:55:07 needed for thread 1
ORA-00289: suggestion : /home/oracle/oradata/NA102/arch/1_300_758883868.dbf
ORA-00280: change 1396904 for thread 1 is in sequence #300
ORA-00278: log file '/home/oracle/oradata/NA102/arch/1_300_758883868.dbf' no longer needed for this recovery
ORA-00308: cannot open archived log '/home/oracle/oradata/NA102/arch/1_300_758883868.dbf'
ORA-27037: unable to obtain file status
Linux Error: 2: No such file or directory
Additional information: 3
>
Umount /data/oradata/NA102/arch done
Die (längliche) Fehlermeldung von Oracle zu dem fehlenden archived redo log. Sequence 300 ist nicht mehr auf dem log_save Ziel-Verzeichnis, sondern im eigentlicher Archivierungs-Verzeichnis. Durch umount des log_save Ziel-Verzeichnises wird auf das eigentliche Archivierungs-Verzeichnis gewechselt. Damit kann Oracle recover automatisch weiterlaufen.
alter database recover automatic database until time '2011-09-07:09:12:00' using backup controlfile
recover database done
6. Schritt: Starten von Oracle (und Applikation):
alter database open resetlogs
alter database open done
#
Weitere Optionen
Daneben gibt es noch weitere Optionen, die den Ablauf von recover.py bestimmen und die nicht abgefragt werden:
-
--controlfile [save_bcf|copy_cf]: (Nur Until-Time-Recovery)
Achtung : diese Option überschreibt den Konfigurations-Parameter RECOVER_UT_CONTROLFILE.
Dabei steht save_bcf für das backup controlfile to 'file' der verwendeten Sicherung und copy_cf für die Kopie eines der existierenden Controlfiles.
Falls noch ein Controlfile existiert und das Recovery nahe an den Stopp-Zeitpunkt der Datenbank geht, verwendet man am besten copy_cf.
Bei Recovery mit Sicherungen, die länger zurück liegen, verwendet man save_bcf, speziell wenn zwischenzeitlich die Datenbank erweitert wurde. -
--open_readonly: (Nur Until-Time-Recovery)
Hier wird die Datenbank nach dem Oracle recover database nur zum Lesen geöffnet. Man kann dann verifizieren, ob das Ergebnis des Recovery korrekt ist und, falls es das ist, die Datenbank für die Benutzung durch alle zugelassenen Benutzer wieder starten (und ggf. die Applikation dazu). -
--use_mirror: NSR-AMON NetWorker group Auswahl.
Werden die archived redo logs mit NSR-AMON doppelt gesichert, dann wird mit dieser Option der NetWorker recover mit ssid der 2. NetWorker group durchgeführt. Die Voreinstellung ist die 1. NetWorker group.
Für den Tester gibt es noch eine weitere Option:
-
--select_all:
Normalerweise wird nur die Sicherung zur Auswahl gestellt, die am schnellsten wieder ein spielbar ist. Mit --select_all werden, falls sie existieren, jeweils die aktuellste Snapshot-, SnapVault- und NDMP-Sicherung zur Auswahl gestellt.
Usage Meldung
Durch Angabe der Option -? erhält man die Meldung des Kommandos recover.py mit kurzen Beschreibung:
# ./recover.py -?
['recover.py', '-?']
USAGE: recover.py [-c | -t <ora_time>] [secondary options] [<ORACLE_SID>]
where -c Complete Recovery
-t <ora_time> Until-Time-Recovery
<ora_time> format YYYY-MM-DD:HH24:MI:SS
<ORACLE_SID> SAP/Oracle database in process
Secondary options:
Until-Time-Recovery:
--controlfile [copy_cf | save_bcf]
Use either a copy of the existing control file
or the "backup controlfile" created during backup.
This option overwrites the configuration parameter
RECOVER_UT_CONTROLFILE.
--open_readonly Verify option: open database read only.
--use_mirror NSR-AMON: use 2nd backup (group) to recover needed
archvied redo logs.
--select_all Test option: show backup select list with each
available backup type (Snapshot, SnapVault, NDMP).
#
Complete-Recovery
Das Beispiel zeigt ein Complete-Recovery der Datenbank NA102:
Links steht die Ausgabe des Kommandos, mit den Eingaben des Anwenders in Fett. Eingerückt sind Erläuterungen zum Ablauf.
# ./recover.py NA102
1. Schritt: Auftrag definieren:
Type of Recovery:
c – Complete
t – Until-Time
q – quit
Recovery type > c
Start NA102 recovery COMPLETE
Debug directory /nsr/SAPbackup/SAPrecoverprot/NA102/20110907_0927
Available Backups:
SNAPSHOT 20110907_0851
Please choose: Snapshot [s], Quit [q] > s
Bei Complete-Recovery wird die letzte Sicherung gezeigt. Normalerweise ist das ein Snapshot.
Using SNAPSHOT backup of 20110907_0851
Initial phase done - well then?
Continue or Quit [<return>|q] > ↵
Wie bei Until-Time-Recovery: Analoge Zeilenpaare „... done – well then?“ und „Continue or Quit ...“ sind nach fast jedem Schritt des Ablaufs eingebaut. Sie ermöglichen die Kontrolle der Debug-Dateien, können aber durch den Parameter RECOVERY_TEST_STOP der Konfigurations-Datei /nsr/SAPbackup/config/<ORACLE_SID> aus- oder eingeschaltet werden.
2. Schritt: Stoppen von (Applikation und) Oracle:
Der Zustand der Datenbank (hochgefahren oder gestoppt) ist beliebig.
Oracle is down already
3. Schritt: Erster Blick auf die Datenbank:
Check current state of database
Online redo log 1: /oracle/oradata/NA102/online/redo01.log [1, 302, 758883868]
Online redo log 2: /oracle/oradata/NA102/online/redo02.log [1, 304, 758883868]
Online redo log 3: /oracle/oradata/NA102/online/redo03.log [1, 303, 758883868]
Orafile /home/oracle/10.2.0/dbs/initNA102.ora ok
Orafile /home/oracle/10.2.0/dbs/orapwNA102 ok
Oracle spfile </home/oracle/10.2.0/dbs/spfileNA102.ora> ok
ora_startup: nomount done
ora_shutdown: shutdown done
Corrupt control file /oracle/oradata/NA102/ctrl/control03.ctl
Dieses Controlfile ist korrupt und wird im Folgenden ersetzt.
ora_shutdown: shutdown done
ora_startup: mount done
ora_shutdown: shutdown done
ora_startup: mount done
num <4> name </oracle/oradata/NA102/data/users01.dbf> error <FILE NOT FOUND>
Diese Datendatei fehlt und wird durch das Einspielen des Snapshots wieder hergestellt. Wie das geschieht wird im Folgenden definiert:
Complete restore of defect datafile(s) – options:
(1) Restore only filer volumes with defect datafile(s).
This task uses "snap restore volume" and is named "Needed_Filer_Vols"
(2) Restore all filer volumes.
This task uses "snap restore volume" and is named "All_Filer_Vols"
(3) Restore only single defect datafile(s).
This task uses "snap restore file" and is named "Restore_File".
This may be a time-consuming operation!
Please choose: 1, 2, 3, Quit [q] > 2
Complete: Do snap restore of/with "All_Filer_Vols"
ora_shutdown: shutdown done
Save control file </oracle/oradata/NA102/cntrl/control03.ctl> to </nsr/SAPbackup/SAPrecoverprot/NA102/20110907_0927/other_ora_files/copy_of_cf>
Mount sim801-3:/vol/nsr_disk_backup/NA102 to /data/oradata/NA102/arch done
Werden archived redo logs vom log_save Ziel-Verzeichnis benötigt, dann wird jetzt diese montiert. Es sind dann 2 Datei-Systeme unter dem Archivierungs-Verzeichnis montiert: das eigentliche Archivierungs-Verzeichnis und darüber das log_save Ziel-Verzeichnis.
First look to database done - well then?
Continue or Quit [<return>|q] > ↵
4. Schritt: Daten-Dateien wieder herstellen – hier mit Snapshot.
Restore SNAPSHOT
SNAPSHOT done
Restore done - well then?
Continue or Quit [<return>|q] > ↵
5. Schritt: Wiederherstellen der Datenbank:
Copy control file /nsr/SAPbackup/SAPrecoverprot/NA102/20110907_0927/other_ora_files/copy_of_cf
Copy /... to /oracle/oradata/NA102/temp/control01.ctl
Copy /... to /oracle/oradata/NA102/online/control02.ctl
Copy /... to /oracle/oradata/NA102/cntrl/control03.ctl
ora_startup: mount done
alter database recover automatic datafile '/oracle/oradata/NA102/data/users01.dbf', '/oracle/oradata/NA102/data/undotbs01.dbf'
Oracle-Error-Code: 279
Oracle-Error-Message: <ORA-00279: change 1396904 generated at 09/07/2011 08:55:07 needed for thread 1
ORA-00289: suggestion : /oracle/oradata/NA102/arch/1_300_758883868.dbf
ORA-00280: change 1396904 for thread 1 is in sequence #300
ORA-00278: log file '/home/oracle/oradata/NA102/arch/1_300_758883868.dbf' no longer needed for this recovery
ORA-00308: cannot open archived log '/oracle/oradata/NA102/arch/1_300_758883868.dbf'
ORA-27037: unable to obtain file status
Linux Error: 2: No such file or directory
Additional information: 3
>
Umount /data/oradata/NA102/arch done
Die (längliche) Fehlermeldung von Oracle zu dem fehlenden archived redo log. Hier ist der automatische Wechsel vom log_save Ziel-Verzeichnis zum eigentlicher Archivierungs-Verzeichnis notwendig, damit Oracle recover automatisch weiterlaufen kann.
alter database recover automatic datafile '/oracle/oradata/NA102/data/users01.dbf', '/oracle/oradata/NA102/data/undotbs01.dbf'
recover database done
6. Schritt: Starten von Oracle (und Applikation):
alter database open
alter database open done
Fehlersituationen
-
Tritt ein ernsthaftes Problem auf, dann bricht das Kommando mit einer Fehlermeldung ab. Ernsthafte Problemen sind z.B. Oracle Fehler, die nicht automatisch behoben werden können.
-
Die Suche nach archived redo logs wird mit Networker nsrinfo durchgeführt. Ist die NetWorker browse time kleiner als die retention time, dann kann im NetWorker Index nichts mehr zu finden sein, während es in der Media-Datenbank noch eine ssid mit der/den benötigten Datei(en) gibt.
Wenn dieses Problem auftritt, dann wird/werden die Datei-Name(n) am Bildschirm angezeigt – siehe Complete-Recovery – und auf eine Eingabe gewartet:-
Nach erfolgreicher Suche die fehlenden archived redo logs mit NetWorker recover … -S <ssid> einspielen und mit <RETURN> fortfahren.
Wie bei Complete-Recovery Beispiel gezeigt. -
Nach erfolgloser Suche entweder ein Recovery bis zum letzten vorhanden archived redo log durchführen (Abbruch und Neustart von recover.py)
-
oder das laufende Recovery abbrechen und nach einer anderen Lösung suchen.
-
Hinweis: Es könnte aber auch sein, dass die archived redo logs verschoben oder verändert (gzip) wurden.
Beseitigung von Problemsituationen
1. Startproblem wegen gesetzter Lock-Datei(en)
Nach einem Programm-Fehler oder nach Abbruch des Programms können Reste, wie Lock-Dateien, übrig bleiben. Nicht löschen, wenn noch ein Recovery läuft.
Debug directory /nsr/SAPbackup/SAPrecoverprot/RJS/20110222_1749
Unable to acquire lock - type COMPLETE
13078 Recovery type COMPLETE
Lock file: /nsr/SAPbackup/SAPaction/NA102/action.lock
#
Entfernung durch Aufruf des Programms zombies.py:
# ./zombies.py
ORACLE_SID = NA102 / no-op = False
Unlink /nsr/SAPbackup/SAPaction/NA102/action.lock
File /nsr/SAPbackup/SAParchlogs/NA102/arch_logs.lock not found
Unlink /home/oracle/oradata/NA102/arch/log_save.disable
Und Neu-Start von recover.py.
2. Filer Problem
Fehlt auf einem der Filer (Primär oder Sekundär) ein Zugriffsrecht oder eine Lizenz, dann kann das wie folgt aussehen:
...
Restore SNAP_VAULT
User ndmp does not have capability to invoke API snapvault-primary-initiate-restore-transfer. (Err Nr. 13003 – EAPIPRIVILEGE)
Traceback (most recent call last):
...
Das Beispiel sagt, dass auf dem Primären-Filer die Zugriffrechte für das Wiederherstellen vom Sekundären-Filer (SnapVault) fehlen. Die Rechte für den Benutzer müssen erweitert werden. Analoges gilt für eine fehlende Lizenz, hier enthält der obige Text EAPILICENSE.
