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: 23. März 2009

Version 0.9.9

1. Beschreibung des Verfahrens

   1. Vorteile gegenüber herkömmlichen Datenbanksicherungsmethoden
   2. Besonderheiten bei der Sicherung von SAP/R3 Datenbanken
   3. Besonderheiten bei der Sicherung von Oracle-RAC Datenbanken

2. Voraussetzungen

3. Konfiguration

   1. Tool Konfiguration
   2. NetWorker Konfiguration
   3. DMZ_NDMP Sicherungen

4. Protokollierung

5. Überwachung

6. Recover

1. Beschreibung des Verfahren

   1. Vorteile gegenüber herkömmlichen Datenbanksicherungsmethoden

      1. 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.
      2. Der Zyklus der Sicherungen kann durch dieses Verfahren von einer Sicherung pro Tag auf 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.
      3. 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.
      4. 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.

    

   2. 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).

   3. Besonderheiten bei der Sicherung von Oracle-RAC Datenbanken

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) so gut wie beliebig. Dieser Snapshot bietet anschließend eine Readonly-Kopie des gesamten Volumes. Diese Kopie kann im folgenden auf ein weiteres Storagesystem gespiegelt werden, oder mit dem NDMP Protokoll direkt von dem Storagesystem konsistent gesichert werden. Das hier beschriebene Tool bietet beide Möglichkeiten der Weiterverarbeitung.

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!

2. 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:

   1. Oracle DB

      1. Tablespacedateien

         Alle Datenbankdateien müssen auf einem NFS gemounteten NetApp Volume liegen.

      2. Onlinelogs

         Die Onlinelogdateien der Datenbank dürfen nicht auf demselben Volume liegen wie eine Taplespacedatei.

      3. Archivelogs

         Das Archivelog Verzeichnis darf nicht auf dem selben Volume liegen wie eine Tablespacedatei.

      4. 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 - Production

         SQL>

      5. 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.).

   2. Filer

      Der NetApp Filer muss folgende Voraussetzungen erfüllen:

      1. 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)

      2. Snapmirror Konfiguration

         Wenn 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:

         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

      3. SnapVault Konfiguration

         Wenn die Datenbank mit dem NetApp SnapVault Verfahren gespiegelt werden soll, muss die SnapVault Beziehung zwischen dem Primary und dem Secondary bereits konfiguriert sein.

      4. 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 HTML

         Erfolgreicher 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.

   3. NetWorker

      Für den Start der Sicherung werden einige NetWorker Ressourcen benötigt.

      1. Client Definitionen

         Für jede Datenbank werden ein oder mehrere NetWorker Client Konfigurationen benötigt.

         Die Idee ist, das 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.

      2. Group Definitionen

         Für jeden Client wird eine eigene Gruppe benötigt. Die eine Gruppe startet u.U. mehrmals am Tag, die andere lediglich einmal und sichert dann die DB auf Tape.

      3. Schedule Definitionen

         Da es sich nicht um "normale" NetWorker Sicherungen handelt benötigen wir immer den Level Full.

3. Konfiguration

   1. Tool Konfiguration

      Für die nativen Oracle-Datenbanken gibt es wegen der unterschiedlichen Installationsvarianten und die 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 spezifischen Parameter erklärt werden.

      1. 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: Die Source liegt in einem Qtree und dieser Qtree, oder das darüber liegende Volume ist der Mountpoint der DB.
         # 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 in 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.)

          

      2. 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

       

      3. 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

       

   2. NetWorker Konfiguration

      Für jede gewünschte Sicherungsart müssen im NetWorker ein bzw. mehrere Ressourcen konfiguriert werden

      1. Client Resource

         Neben den bekannten Attributen wie Name; Browse- und Retention Policy sind folgende Attribute besonders zu betrachten:

         Attribut	Wert		Beschreibung
         Backup Command	bei SAP/R3 DBs	nsr_sapbackup_cmd	Statt dem NetWorker Save Kommando soll dieses Script die Sicherung der SAP Datenbank starten
         	bei nativen Oracle DBs	nsr_oracle_cmd	- " -
         Save Set	<ORACLE_SID>:<BACKUP_TYPE>[:( ONLINE | OFFLINE ) ]		Der SaveSet besteht aus 2 oder 3 Feldern die durch das syntaktische Element ':' voneinander getrennt werden. Das erste Feld gibt die ORACLE_SID wieder und führt so zur der korrekten Konfigurationsdatei. Das zweite Feld BACKUP_TYPE bestimmt die Art der Filer und NetWorker Sicherung; Das dritte Feld definiert den Type der Oracle-Sicherung. Der Default ist eine Online-Sicherung.
         	BACKUP_TYPE		Bei alle Sicherungstypen wird nach der erfolgreichen Erzeugung des Snapshots das Oracle Controlfile und sonstige Oracle Dateien in das Protokollverzeichnis kopiert und nach dem Abschluß aller sonstigen Tätigkeiten auf Band gesichert!
         		ONLY_SNAP	Nur Snapshot Sicherung der DB
         		NDMP_BACKUP	Erzeugung einer Snapshot-Sicherung mit anschließendem Backup dieses Snapshots mit NetWorker und dem NDMP Protokoll. Die eigentliche Sicherung wird vom primär Storage durchgeführt und belastet somit u.U. die I/O des Storage Systems. Die Datenbankmaschine wird durch die Bandsicherung nicht belastet!
         		SNAP_MIRROR	Erstellung einer Snapshot Sicherung mit anschließendem aufsetzen der SnapMirror Synchronisation.
         		SNAP_MIRROR_NDMP	wie oben, aber nach dem erfolgreichen Spiegeln wird am Nearstore Filer (sekundär Storage) eine NDMP Sicherung der Datenbank durchgeführt.
         		SNAP_VAULT	Sicherung des Qtrees mit SnapVault
         		SNAP_VAULT_NDMP	Sicherung des Qtrees mit SnapVault und anschließender NDMP Sicherung
         		SNAP_MIRROR_NDMP_LATER	Erstellung einer Snapshot Sicherung mit anschließendem aufsetzen der SnapMirror Synchronisation. Für eine evtl. spätere NDMP Sicherung wird eine entsprechende Datei erzeugt.
         		SNAP_VAULT_NDMP_LATER	Sicherung des Qtrees mit SnapVault. Für eine evtl. spätere NDMP Sicherung wird eine entsprechende Datei erzeugt.
         		NDMP_LATER	Snapshot Sicherung der DB. Für eine evtl. spätere NDMP Sicherung wird eine entsprechende Datei erzeugt.
         		NDMP_DELAYED	NDMP Sicherung eines vorherigen NDMP_LATER, SNAP_MIRROR_NDMP_LATER oder SNAP_VAULT_NDMP_LATER. Dieser SaveSet kann aber auch verwendet werden, wenn eine andere NDMP Sicherung fehlerhaft beendet wurde. Denn auch im Fehlerfall wird die benötigte NDMP_LATER Datei für die Sicherung generiert.
         Schedule	ALWAYS_FULL		Die Datenbank und alle zugehörigen Dateien sollen immer mit dem Level Full gesichert werden
         Group			Sicherungsgruppe für diese Art der Sicherung

       

      2. 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!

   3. 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 Spiegleung 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

  dmzfiler ist hierbei der Mirror Qtree und DBDMZ der Name der DB (Oracle SID).

• Für die WWW Überwachung der Sicherung wird folgender zusätzlicher Link auf dem "webserver" 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.

4. 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.trc

   • logs

     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

5. Ü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 singapurer Konfiguration gemountet. Die Konfiguration aus Singapur wird für diesen Zweck, mittels SnapMirror vom nafiler6 auf nstore1:/vol/nsrapp/sgp gespiegelt.

   Unter folgenden URLs findet man die Protokollierung, sowie Konfigurationsmöglichkeiten für die einzelnen DBs.

   SAP / R3 Zentrale	http://webserver/sap
   SAP / R3 Site1	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)

6. Recover

   1. Wiederherstellen einer defekten oder gelöschten Datenbankdatei

      Beispiel:

      Die Datei /oracle/ORADB/sapdata1/system_1/system.data1 wurde zerstört. Es gibt 2 Möglichkeiten diesen Fehler zu beheben:

      1. Man könnte die Datei aus dem letzten Snapshot kopieren,
      2. Man führt einen SnapRestore für die verlorene Datei durch.

      Bei einer großen Datei empfiehlt sich der zweite Weg, da bei einem kopieren die Daten zum einen über das Ethernet gesendet werden müssen und zum zweiten der Platz der Datebankdatei komplett im Snapshot-Bereich angelegt wird. Das im folgenden beschriebene Verfahren verwendet daher den SnapRestore Meschanismus.

      1. Alle Sicherungen ausschalten

          

         • Archivelog Daemon

           Auf dem Sicherungsserver als Benutzer root:

           # /etc/init.d/logSave stop

         • Savegrps im NetWorker

           Alle Sicherungsgruppen der DB im NetWorker deaktivieren

      2. snaprestore file

         Auf dem Filer auf dem die Datenbank-Dateien gemountet wurden als Admin-Benutzer :

         nafiler3> snaprestore -s <snapshot> -f /vol/saporadb/oradb/ORADB/sapdata1/system_1/system.data1

         Durch diesen Befehl wird die Datei aus dem angegebenen Snapshot in das aktuelle Filesystem wiederhergstellt. Andere Dateien werden durch den Befehl nicht beeinflusst. Eine kleine Herausforderung ist die Ermittlung des absoluten Dateinamens auf dem Filer Volume. Hierzu empfehlen sich die Kommandos "/bin/pwd" , sowie ein "df -h ." im Datenbankverzeichnis. Mit Hilfe der Ausgabe dieser beiden Kommandos läßt sich der korrekte Pfad leicht ermitteln.

      3. recover database

         Nachdem die defekte Datei wiederhergestellt ist, muß der Oracle-Tablespace recovert werden. Hierzu sollte das Oracle Kommando "sqlplus" als Oracle-Benutzer mit der Option "/ as sysdba" gestartet werden. Nach einem "startup mount" kann der Restore durch die Eingabe des Kommandos "recover database;" gestartet werden. Oracle verlangt nun das bei der Snapshot-Sicherung generierte Archivelog und so viele weitere Logs, bis der Tablespace auf dem aktuellen Stand der Datenbank ist. In den meisten Fällen dürften die Archivelogs von dem Archivierungsdämon des Sicherungsservers bereits aus dem Archivierungsverzeichnis entfernt worden sein. In diesem Falle sollte zunächst kontrolliert werden, ob das von Oracle angeforderte Log noch auf dem Backup2Disk Bereich des Archivelogdämons zu finden ist. Ist dies der Fall, so kann man bei Punkt V. fortfahren, sollte das benötigte Logfile bereits gelöscht worden sein, so muss ein NetWorker Recover der Logdateien vorgeschaltet werden (siehe. Punkt IV).

      4. NetWorker Recover von Archivelogs

         Der Archivelogdämon sichert die Logdateien auf dem Sicherungsserver. Dort ist auch das zugehörige Backup2Disk Verzeichnis gemountet. Es empfiehlt sich für einen Recover auf diese Maschine als Benutzer "root" anzumelden und dort den Recover durchzuführen. Auf dem Sicherungsserver wechselt man in das zugehörige Backup2Disk-Verzeichnis und startet dann den Recover mit den unten aufgeführten Optionen.

         # cd /nstore1/oralogsb2d/ORADB
         # recover -s <server> -c <client>
         recover> add
         recover> recover

         Nach dem erfolgreichen Wiederherstellen der Archivelogdateien müssen diese nur noch an der Datenbankmaschine gemountet werden (siehe Pkt. V.) und der Oracle-Restore kann beginnen.

      5. Archivelog Area dem Sicherungsserver auf DB Maschine unter /mnt mounten

         Im Archivelogverzeichnis der DB liegen u:U. noch benötigte Logs, die noch nicht auf den Backup2Disk Bereich verschoben wurden. Daher müssen wir dieses Verzeichnis vor evtl. Löschungen schützen. Auf der anderen Seite macht es keinen Sinn, die gesicherten und evtl. Recoverten Logdateien auf die Datenbankmaschine zu kopieren. Da sich diese auf einem NetApp Filer befinden reicht es aus, den zugehörigen NetApp-Share an der Datenbankmaschine zu mounten und das Archivelogverzeichnis auf den zugehörigen Mountpoint zu linken.

         Hier eine kurze Anleitung der nötigen Schritte:

         1. u.U. Backup2Disk Verzeichnis für die DB Maschine zum mounten freigeben

         2. das Backup2Disk Logverzeichnis mounten
         3. das gemountete Verezeichnis als Oracle-Archivelog Verzeichnis einbinden

          

         Beispiel: Die Datenbankmaschine bwp soll die Freigabe f[r das Backup2Disk Volume erhalten:

         • auf dem NetApp Filer nstore1

         nstore1> exportfs -io rw=<server>:saporadb,root=<server>:saporadb /vol/oralogsb2d/oralogsb2d

         • auf dem DB-Rechner das Verzeichnis mounten

         server:~ # mount /vol/oralogsb2d/oralogsb2d /mnt
         server:~ # cd /oracle/ORADB
         server:~ # mv oraarch oraarch.b
         server:~ # ln -s /mnt/ORADB oraarch

   2. Recover bei logischen Fehler oder defekten Datenbanken

      Sollte die Datebank korrupte oder inkonsistente Daten enthalten und deshalb ein Restore until Time notwendig sein, so empfiehlt sich das folgende Vorgehen:

      1. Alle Sicherungen ausschalten

         1. Archivelog Daemon
         2. Savegrps im NetWorker

      2. Einen Snapshot des Volume aktivieren

         Auf dem NetApp Filer der das Datenbankvolume hostet muss das Komando " snap restore Volume " für das betreffende Volume durchgeführt werden. Hierbei kann der betreffenden Filer und das zugehörige Volume am einfachsten dadurch emittelt werden, dass man auf der DB-Maschine in ein Datenverzeichnis der DB wechselt und dort das Kommando "df -h ." absetzt. Der erste Parameter der Ausgabe enthält sowohl den Filer-Namen als auch das betreffende Volume.

         Beispiel:

         Auf der Datenbankmaschine der DB JOY:

         sapjoydb:~ # cd /oracle/JOY/sapdata1/
         sapjoydb:/oracle/JOY/sapdata1 # df -h .
         Filesystem Size Used Avail Use% Mounted on
         123.12.123.1:/vol/sapjoydb 190G 143G 48G 76% /filer2

         Auf dem NetAppFiler

         nstore1> snap list sapjoydb
         Volume sapjoydb
         working...

         %/used %/total date name
         ---------- ---------- ------------ --------
         0% ( 0%) 0% ( 0%) May 10 16:36 JOY_online_SNAP_MIRROR.070510_1636 (snapmirror)
         0% ( 0%) 0% ( 0%) May 10 16:32 JOY_online_SNAP_MIRROR.070510_1632
         0% ( 0%) 0% ( 0%) May 10 16:17 JOY_online_SNAP_MIRROR.070510_1617
         0% ( 0%) 0% ( 0%) May 10 16:15 JOY_online_ONLY_SNAP.070510_1615
         1% ( 0%) 0% ( 0%) May 10 14:45 JOY_online_ONLY_SNAP.070510_1445
         1% ( 0%) 1% ( 0%) May 09 11:57 JOY_online_ONLY_SNAP.070509_1156
         1% ( 0%) 1% ( 0%) May 09 08:59 JOY_online_SNAP_MIRROR.070509_0859
         1% ( 0%) 1% ( 0%) May 09 08:12 JOY_online_ONLY_SNAP.070509_0812
         1% ( 0%) 1% ( 0%) May 08 19:17 JOY_online_ONLY_SNAP.070508_1917
         1% ( 0%) 1% ( 0%) May 08 19:06 JOY_online_ONLY_SNAP.070508_1906
         1% ( 0%) 1% ( 0%) May 08 16:24 JOY_online_SNAP_MIRROR_NDMP.070508_1624

         
         Wenn möglich sollte bei der Auswahl des Snapshots der jüngste Snapshot des Datenbank Volumes verwendet werden, damit die evtl. vorhandene SnapMirror Beziehung erhalten bleibt.

         nstore1> snap restore -s JOY_online_SNAP_MIRROR.070510_1636 sapjoydb

         Nachdem der gewünschte Snapshot zum aktuellen Filesystemstand zurückgesetzt wurde kann einer normaler Datenbank Recover durchgeführt werden. Hierbei gilt die selbe Vorgehensweise wie oben beschrieben.

         1. recover database
         2. u.U. Recover Archivelogs
         3. Archivelog Area des Sicherungsservers auf DB Maschine unter /mnt mounten

   3. K-Fall Recover Szenarien

      In Problemfällen in denen das Original-Netapp-Volume defekt oder nicht erreichbar sein sollte, kann die Datenbank auch mit dem evtl. vorhandenen SnapMirror-Spiegel der Datensicherung wieder aufgebaut werden.

      Zu diesem Zweck muß zunächst eine passende Datenbankumgebung auf dem Datenbankrechner aufgebaut werden (der Aufbau der Oracle und SAP Umgebung ist nicht Thema dieser Doku). Hiernach sollte die DB nach folgendem Schema wiederherzustellen sein:

      1. Alle Sicherungen ausschalten
         • Archivelog Daemon
         • Savegrps im NetWorker
      2. SnapMirror Beziehung aufbrechen

      Hierzu muss auf dem NetApp-Spiegel Rechner die SnapMirror Beziehung zwischen Source und Destination aufgebrochen werden

      snapmirror quiesce
      snapmirror break

      3. exportfs für das SnapMirror Volume einrichten
      4. Mount des SM Volumes
      5. recover database
      6. Recover der Archivelogs
      7. Archivelog Area des Sicherungsservers auf DB Maschine unter /mnt mounten