Die Recovery-Ersatzlösung

Backup- und Recovery-Utilities sind funktionaler Bestandteil jedes Datenbank-Systems. Das Recovery-Utility ist aufgrund der Kenntnis der physischen Strukturen der Datenbank in der Lage, einen gesicherten Datenbestand in minimaler Zeit wieder zurückzuladen. Die gleiche Funktionalität über Programme abzuwicklen zu wollen, die auf der normalen SQL-Schnittstelle aufsetzen, würde um Faktoren länger dauern.

Jeder Mandant stellt einen nur kleinen Ausschnitt der gesamten Datenbasis dar. Daraus ergibt sich die Frage, ob und wie ein einzelner Mandant zurückgesetzt werden kann. Wir haben also nur eine für Mehrmandanten spezifische Recovery-Anforderung im Blick, bei der Daten eines einzelnen Mandanten durch Handling-Fehler (z.B. falsch parametrisierte Batch-Jobs) flächendeckend zerstört wurden. Beim normalen Datenbank-Recovery müssten auch alle anderen (unversehrten) Mandanten auf einen vorzugebenden älteren Stand zurückgesetzt werden. Für diese wiederum kann das Rücksetzen Datenverlust bedeuten, da alle Eingaben, die zeitlich nach dem Rücksetzzeitpunkt liegen, verloren gehen, also wiederholt werden müssen. Dies ist oftmals gar nicht möglich.

Eine Single-Client Recovery (Ersatz-) Lösung ist jedoch auf der Basis der vorhandenen Tools des Mandantentransport möglich - wenngleich dies eine vergleichsweise teuere Lösung im Gegensatz zu Datenbank-Recovery-Utilities bedeutet. Im Recovery-Fall eines Mandanten wird das Backup auf einen separaten Standby-Rechner aufgespielt. Damit ist dort der gewünschte konsistente Stand wiederhergestellt. Für den betroffenen Mandanten werden nun unter korrigierten Rahmenbedingungen die ursprünglichen Änderungsmaßnahmen wiederholt und auf einen aktuellen Stand gebracht. Zum nächstmöglichen Zeitpunkt (in der folgenden Nacht oder Wochenende) wird der aktualisierte Mandant in sein ursprüngliches System zurückgespielt. Bitte lesen sie hierzu auch SAP Hinweis 31496 . Falls erforderlich, muss das Tagesgeschäft solange auf dem Gastrechner abgewickelt werden, bis der Rückransport erfolgen kann, was dann zusätzlichen Aufwand bzgl. Netzanbindung und Komunikationsverbindungen bedeuten kann. Ferner müssen bis zum erfolgten Rücktransport Änderungen an mandantenübergreifenden Objekten parallel in beiden Systemen durchgeführt werden, oder - was anzustreben ist - bis zum Rücktransport zurückgestellt werden.

Wie erwähnt, ist der Preis dieser Notlösung deutlich teurer als ein Datenbank-gestützes Recovery:

• Der Standby-Rechner muss ebenso groß dimensioniert sein wie der Produktiv-Rechner, um das Backup aufnehmen zu können,

• Der abschließende Rücktransport kann nicht mit Datenbank-Utilities durchgeführt werden, sondern via Mandanten-Transport, also einem Programm, das auf der SQL-Schnittstelle aufsetzt. Auch wenn sich der Rücktransport auf mandantenabhängige Tabellen beschränkt ist, wird er erheblich langsamer sein als die Rückladezeit der Datenbank-Utilities.

• Sofern der reparierte Mandant im Recovery-System temporär produktiv genutzt werden muss, sind zusätzlicher Aufwand für die Einrichtung von Netz- und Kommunikatuionsverbindungen sowie ein kurzer Abnahmetest einzukalkulieren.

Andere Recovery-Szenarien, bei denen der gesamte Datenspeicher, die gesamte Anlage oder sogar Gebäude zerstört wurden, betreffen auch in einem Mehrmandanteneinsatz immer alle Mandanten, die dann einen gemeinsamen Recovery-Bedarf haben.

In der folgenden Abbildung ist ein Single-Client Backup-Szenario auf der Grundlage von Mandantenkopie dargestellt.