SEP Live Recovery für SAP/R3 mit SAPDB/MaxDB

Lösung für den Aufbau der SAP/R3 Schattendatenbank

Für die Beschleunigung eines im Desaster Fall nötigen Recoveries bietet sich der Aufbau einer Schattendatenbank an, die bereits im Normalbetrieb mit Daten der Originaldatenbank befüllt wird. Bei geeigneter Ablage der aktiven LOG-Volumes können auch diese im Desasterfall beim Recovery verwendet werden. Damit kommt es zum kleinstmöglichen Datenverlust, d.h. im Idealfall zu keinem Datenverlust.
Zusätzlich kann mit Hilfe einer Schattendatenbank ein Fehler in der Datenhaltung, z.B. gelöschte Datenbestände, durch Recovery bis zeitlich vor der fatalen Aktion, weitgehend abgefangen werden.

Die Schattendatenbank erhält durch Log – Recovery mit zeitlicher Verzögerung den selben Datenbestand wie die Originaldatenbank. Im Desasterfall ist dann lediglich der seit der Verzögerung entstandene Datenbestand zusätzlich einzuspielen und die Datenbank in den Online Zustand zu fahren.

Zum Aufbau der SAP/R3 mit SAPDB/MaxDB Schattendatenbank ist zunächst ein dem Original Server in Datenvolumen und SAP/R3 mit SAPDB/MaxDB weitgehend identischer Server aufzubauen.
Zusätzlich sollten die LOG-Volumes des Original SAP/R3 Servers auf einem externen Plattenbereich, der auch im Zugriff des Schattenservers ist, - idealerweise ein duplizierter Datenbestand in getrennten Brandabschnitten, z.B. mit HSC Controller, oder Cluster-Controller – befinden, dann kann die Schattendatenbank auch diese Daten, der letzten Transaktionen, für den Recovery verwenden.

Aufbau der SAP/R3 Schattendatenbank

Die Datenbank wird mit den vorgegebenen Installationsmitteln aufgebaut. Bei Benutzung des DBMWizard ist im letzten Menupunkt „Restore“ anzugeben. Die Schritte „Activate ServerDB“ und „Load Systemtables“ müssen nicht ausgeführt werden.
Für den Aufbau der Schattendatenbank ist zunächst ein FULL-Backup der Original DB nötig. Dieser wird in die Schatten DB übernommen.
Die Schatten DB darf nach dem Einspielen keinesfalls in den Online Modus gebracht werden, da dann eigene LOG Dateien angelegt werden und die logische Kette der
LOG-Dateien der Original DB unterbrochen wird.
Es bietet sich an, diesen Full Backup mit einem SEP sesam Server oder einem vergleichbaren Produkt zu erstellen, der dann diesen Full Backup auch in die Schatten DB einspielt.

Abgleich der Schattendatenbank

Zum Abgleich der Daten wird am SAP/R3 Server von SEP Live Recovery ein AUTO LOG Backup initiiert.
Die dabei erzeugten Dateien werden über remote Zugriff bereits am Schattensystem abgelegt. D.h. Die Dateinamen enthalten auch den Servernamen des Schattensystems und werden dort angelegt.

Am Schattensystem werden diese Dateien durch SEP Live Recovery wahrgenommen und automatisch in die Schatten DB übernommen. Dabei kann vom Anwender der gewünschte zeitliche Versatz, z.B. 1 Stunde konfiguriert werden.
Damit befindet sich die Schattendatenbank immer im selben Datenzustand wie die Original DB allerdings mit dem entsprechenden zeitlichen Versatz.

Desaster Recovery der Schattendatenbank

Im Desaster Fall werden mit Hilfe von SEP Live Recovery die gewünschten noch nicht übernommenen LOG-Dateien eingespielt.
Zur Auswahl stehen
1. Einspielen aller fehlenden LOG-Dateien + LOG-Volumes (sofern zugreifbar)
2. Einspielen bis zu einer vorgegeben LOG-Datei
3. Einspielen mit dbmcli „UNTIL“ Option.

SEP LiveRecovery führt die Aktionen entsprechend aus und setzt, sofern keine Fehler aufgetreten sind, die Datenbank Online.

Für die Verwendung der LOG-Volumes wird der Recovery in 3 Phasen durchgeführt:
1. Einspielen der noch fehlenden LOG-Dateien.
2. Ggf. Übernahme der LOG-Volumes
3. Online setzen der Datenbank: (db_warm)

Der Anwender kann im Problemfall manuell eingreifen und den Recovery mit dbmcli Mitteln händisch ausführen. Die Verwendung von SEP Live Recovery im Desaster Fall ist wahlfrei.

Benutzung der Schattendatenbank

Zur Aktivierung der Schatten DB als aktive DB sollte ggf. ein Tausch der Namen (und IP-Adressen) der Systeme durchgeführt werden. Damit übernimmt das Schatten-System komplett die Rolle des Originalsystems. Das Originalsystem kann dann als Schattensystem aufgebaut werden. Man spart sich hierbei den nochmaligen Datenrecovery auf dem Originalsystem.
Dies setzt natürlich voraus, dass beide Systeme in etwa leistungsgleich sind.

Voraussetzung für die Verwendung von SEP Live Recovery

Für die Verwendung muss das Schattensystem weitgehend, d.h. in Datenvolumen, zumindest der Größe der zu erwartenden Datenmenge, und HW dem Originalsystem gleichen.
Außerdem muss der für die Ablage der Log-Dateien nötige Zugriff vom Original auf das Schattensystem ermöglicht sein.
Optional sollten die LOG-Volumes auch am Schattensystem synchron vorliegen (Controller Cluster mit kreuz weisem Zugriff auf LOG-Volumes).

Implementierung SEP Live Recovery

Grundsätzlich handelt es sich hier um einen Datenabgleich zweier Systeme. Die Datenübernahme bedarf großer Sorgfalt, so müssen z. B. Kontrollen bzgl. erfolgter Datenübernahmen durchgeführt werden. D.h. idealer Weise hat SEP Live Recovery auch Zugriff auf das Originalsystem. Dies wird mit Hilfe der dbmcli remote – Funktionalität ermöglicht. D.h. dbmcli kann auf dem Schattensystem aufgerufen werden und kommuniziert mit dem Originalsystem. Damit ist eine Kontrolle der LOG Aktivitäten möglich.
Zu Klären ist die Verwendung von Triggern für LOG-Aktivitäten. Ansonsten wird SEP Live Recovery durch regelmäßige Kontrollen – Polling - die Datenübernahme kontrollieren.
Für den Recovery sind unterschiedliche Fehlerfälle zu berücksichtigen. Auf jeden Fall wird im Fehlerfall das System nicht in den ONLINE Zustand gesetzt, damit manuelle Eingriffe möglich bleiben.

Risikoabschätzung

Aufgrund der sorgfältigen Vorgehensweise beim Datenabgleich sind, sofern die Voraussetzungen (siehe oben) erfüllt sind keine besonderen Risiken vorhanden.
Risiken sind:
1. Erzeugung der LOG-Dateien scheitert
2. Datenabgleich (Normalbetrieb) scheitert
3. Desaster-Recovery scheitert

Gegenmaßnahmen sind:
1. Die Erzeugung der Log-Dateien wird von SEP Live Recovery kontrolliert, ggf. werden entsprechende Warnungen/Alarme ausgelöst.
2. Im Normalbetrieb wird auch die Datenübernahme kontrolliert und entsprechende Reaktionen eingeleitet.
3. Im Recovery Fall sind lediglich die vom Originalsystem noch nicht übernommenen LOG-Dateien, u.U. LOG-Volumes einzuspielen. Probleme sind nur bei echtem Datenverlust, d.h. LOG-Dateien/Volumes beschädigt, etc. zu erwarten. Auf jeden Fall befindet sich die Datenbank zumindest in dem Zustand gemäß dem vom Benutzer eingestellten zeitlichen Versatz und kann manuell weiterbearbeitet werden.

Mit Hilfe von SEP sesam kann der mögliche Verlust von LOG-Dateien zusätzlich minimiert werden.

Synergie SEP sesam und SEP Live Recovery

Durch die gemeinsame Benutzung von SEP sesam mit SEP Live Recovery kann sowohl der Aufbau der Schatten DB und der Abgleich dieser kontrolliert als auch die zugrundeliegenden Daten zusätzlich geeignet gesichert werden.
D.h. im Bedarfsfall können diese Daten auf dem Original oder dem Schattensystem jederzeit eingespielt und verwendet werden.
Außerdem kann die Durchführung von SEP Live Recovery kontrolliert und entsprechende Events, z.B. ein SEP sesam Alarm angestoßen werden.

Synergie von SEP Live Recovery und SEP sesam

SEP Live Recovery für SAPDB/MaxDB ist ein speziell für den Aufbau und den Desaster Recovery von SAP/R3 mit SAPDB/MaxDB Datenbanken zu entwickelndes Produkt.
Die Verwendung gemeinsam mit SEP sesam Datensicherungsprodukten aber auch mit Datensicherungsprodukten von anderen Herstellern ergänzen die netzwerkweite Datenverfügbarkeit des Anwenders.

Namen von Firmen, Produkten und Dienstleistungen können Marken oder eingetragenen Marken der jeweiligen Inhaber sein.

© all content copyright by SEP AG 2003-2009