Zero Data Loss für Oracle SE2: Wie klein muss die Datenlücke wirklich sein?

Frauke Jerabeck: „Häufig dann, wenn Unternehmen ihr Notfallkonzept überprüfen, ihre Infrastruktur modernisieren oder eine bestehende Standby-Lösung neu bewerten. Viele wissen zwar, wie schnell ihre Datenbank nach einem Ausfall wieder verfügbar sein soll. Weniger klar ist oft, auf welchem Datenstand sie dann weiterarbeiten können. 

Spannend wird es, sobald wir die technische Zeitangabe in den Geschäftsprozess übersetzen: Was fehlt möglicherweise, wenn fünf Minuten Daten nicht auf dem Standby-System angekommen sind? Sind das drei interne Änderungen oder 1.500 Bestellungen, Zahlungen oder Produktionsmeldungen? Erst dann wird aus dem RPO eine konkrete wirtschaftliche Frage. 

Besonders sensibel sind Prozesse mit vielen Transaktionen oder Daten, die sich nur schwer rekonstruieren lassen – beispielsweise im Handel, in der Produktion, bei Finanzdienstleistungen oder im Gesundheitswesen. Entscheidend ist aber weniger die Branche als die Frage, welche Folgen fehlende Daten für den jeweiligen Prozess haben.“

Andreas Ströbel: „Nehmen wir als vereinfachtes Beispiel eine Anwendung, die durchschnittlich 300 Transaktionen pro Minute verarbeitet. Bei einem RPO von fünf Minuten könnten theoretisch bis zu 1.500 Transaktionen in der wiederhergestellten Datenbank fehlen. Bei einem RPO von unter einer Sekunde läge dieses Fenster rechnerisch bei weniger als fünf Transaktionen. 

Aber die reine Anzahl erzählt nur einen Teil der Geschichte. Nach dem Ausfall muss das Unternehmen zunächst herausfinden, welche Vorgänge fehlen. Danach müssen die Daten mit Vorsystemen, Schnittstellen oder Papierbelegen abgeglichen und gegebenenfalls manuell nacherfasst werden. Je nach Prozess kann dieser fachliche Abgleich deutlich länger dauern als die technische Wiederherstellung der Datenbank. 

Deshalb sollte man nicht nur fragen: „Wie viel Datenverlust können wir tolerieren?“ Ebenso wichtig ist: „Wie sicher und mit welchem Aufwand können wir die fehlenden Daten rekonstruieren?““

Frauke Jerabeck: „Außerdem stellt sich die Frage, wie sicher und schnell der Geschäftsbetrieb wieder aufgenommen werden kann. Das Thema Business Continuity Management (BCM) wird für Unternehmen und Organisationen immer wichtiger. Zero Data Loss kann hier ein wichtiger Baustein sein.“

Andreas Ströbel: „Das Recovery Point Objective, kurz RPO, beschreibt die mögliche Datenlücke: Auf welchen Zeitpunkt können wir die Daten nach einem Ausfall wiederherstellen? Ein RPO von fünf Minuten bedeutet, dass im ungünstigsten Fall die Änderungen der letzten fünf Minuten fehlen können. 

Das Recovery Time Objective, kurz RTO, beschreibt dagegen die Zeit bis zur Wiederaufnahme des Betriebs. Dazu gehören beispielsweise das Aktivieren der Standby-Datenbank, das Umschalten der Anwendungen und technische Prüfungen. 

Dbvisit Zero Data Loss setzt in erster Linie beim RPO an. Die Lösung verkleinert also das potenzielle Datenverlustfenster, macht die Datenbank aber nicht automatisch ohne Unterbrechung verfügbar. 

In der Praxis gibt es noch eine dritte, wichtige Perspektive: Wann vertraut der Fachbereich dem wiederhergestellten Datenbestand wieder? Dbvisit bezeichnet das als „Time to Trusted Business“. Wenn deutlich weniger Daten fehlen, sinkt häufig auch der Aufwand für Prüfung, Abgleich und Rekonstruktion. Dadurch kann der Geschäftsbetrieb schneller wieder auf einer verlässlichen Datenbasis arbeiten.“

Andreas Ströbel: „Im Grunde mussten Unternehmen zwischen verschiedenen Kompromissen wählen. Sie konnten das bestehende Datenverlustfenster akzeptieren und organisatorische Verfahren für die Rekonstruktion vorbereiten. Alternativ kamen individuell entwickelte Lösungen oder eine Replikation auf Storage-Ebene infrage. Solche Ansätze müssen aber sehr genau darauf geprüft werden, ob sie im Ernstfall einen konsistenten und tatsächlich wiederherstellbaren Datenstand liefern. 

Eine weitere Möglichkeit ist der Wechsel auf die Oracle Enterprise Edition und der Einsatz von Oracle Data Guard. Das kann technisch sinnvoll sein, bringt aber deutlich höhere Lizenzkosten mit sich, je nach Konfiguration ggf. um Faktoren höher. Vor allem dann, wenn ein Unternehmen die zusätzlichen Funktionen der Enterprise Edition ansonsten nicht benötigt, ist dieser Schritt wirtschaftlich genau zu betrachten. 

Mit Dbvisit ZDL gibt es nun eine weitere Option: Oracle SE2 beibehalten und trotzdem ein RPO unter einer Sekunde anstreben. “

Andreas Ströbel: „Die klassische Replikation mit Dbvisit StandbyMP überträgt abgeschlossene Archive Logs auf das Standby-System. Zwischen zwei Übertragungen kann jedoch eine zeitliche Lücke entstehen. ZDL ergänzt diesen bewährten Weg um eine zweite Replikationsschicht. Die Lösung überwacht die aktiven Online Redo Logs der Primärdatenbank und überträgt neu entstehende Änderungen kontinuierlich zum Standby-System. Bei einer Aktivierung können diese zusätzlich übertragenen Redo-Daten genutzt werden, um die letzte Lücke zu verkleinern. Wichtig ist: ZDL ersetzt die Archive-Log-Replikation nicht. Beide Wege laufen parallel. Wird der zusätzliche Redo-Datenstrom unterbrochen, bleibt die klassische Archive-Log-Replikation als Basis bestehen.“

Andreas Ströbel: „Bei einem ungeplanten Ausfall können wir keine mathematisch exakten null Sekunden garantieren. ZDL arbeitet asynchron. Zum Zeitpunkt eines Ausfalls können sich noch Änderungen im Arbeitsspeicher oder auf dem Übertragungsweg befinden. 

In einer geeigneten und entsprechend geprüften Umgebung ist ZDL auf ein RPO bis unter einer Sekunde ausgelegt. Das ist ein erheblicher Unterschied zu einem Datenverlustfenster von mehreren Minuten, aber eben keine Garantie für absolut null Datenverlust in jedem denkbaren Szenario. Wir sprechen daher als tatsächlich eigentlich von „Near Zero Data Loss“. 

Anders sieht es bei einem geplanten Graceful Switchover aus. Dabei kann StandbyMP die Rollen von Primär- und Standby-Datenbank kontrolliert und ohne Datenverlust wechseln.“

Andreas Ströbel: „Entscheidend ist das Zusammenspiel aus Datenbanklast, Storage und Netzwerk. Wir betrachten unter anderem das Redo-Aufkommen, die Performance der Online Redo Logs, die verfügbare Bandbreite sowie Latenz und Stabilität der Verbindung zwischen Primär- und Standby-System. 

Besonders wichtig sind Spitzenlasten. Eine Umgebung kann im normalen Tagesbetrieb unauffällig sein und während eines Batchlaufs, eines Backups oder zum Monatsabschluss deutlich mehr Redo erzeugen. Deshalb genügt es nicht, Durchschnittswerte zu betrachten. 

Dbvisit empfiehlt leistungsfähigen SSD- oder NVMe-Speicher für die Redo Logs und nennt als Orientierung eine Netzwerkantwortzeit von etwa 50 Millisekunden oder weniger. Ob das Ziel von unter einer Sekunde tatsächlich erreicht wird, sollte jedoch unter repräsentativer Last geprüft werden. Ein Proof of Concept ist deshalb ein wichtiger Teil der Bewertung.“

Frauke Jerabeck: „ZDL ist besonders interessant für Unternehmen, bei denen bereits wenige Minuten Datenverlust spürbare Folgen haben. Das können fehlende Aufträge, Zahlungen, Lagerbewegungen, Produktionsmeldungen oder fachlich relevante Statusänderungen sein. Auch regulatorische Anforderungen oder ein sehr aufwendiger Datenabgleich können für ein kleineres RPO sprechen. 

Nicht jede Datenbank braucht allerdings ein RPO unter einer Sekunde. Bei wenig kritischen Systemen, geringen Transaktionszahlen oder Daten, die sich einfach erneut erzeugen lassen, kann die klassische Archive Log Replikation vollkommen ausreichen. 

Wir betrachten deshalb nicht nur, was technisch möglich ist. Entscheidend ist, welcher Schutzbedarf für den Geschäftsprozess angemessen und wirtschaftlich sinnvoll ist.“

Frauke Jerabeck: „Es ist beides. Ein kleineres Datenverlustfenster reduziert zunächst das operative Risiko. Nach einem Ausfall fehlen potenziell weniger Vorgänge, der Abstimmungsaufwand sinkt und die Verantwortlichen gewinnen schneller wieder Vertrauen in den Datenbestand. 

Gleichzeitig geht es um Wirtschaftlichkeit. Wenn Unternehmen für ein sehr niedriges RPO nicht allein deshalb auf die Oracle Enterprise Edition wechseln müssen, können erhebliche Lizenzkostenunterschiede entstehen. Hinzu kommen mögliche Einsparungen beim Prüfen und Rekonstruieren fehlender Daten. 

Wir betrachten deshalb drei Größen gemeinsam: das Risiko eines Datenverlusts, die möglichen Folgekosten eines Ausfalls und die Kosten der technischen Absicherung. Erst daraus ergibt sich eine belastbare Entscheidung.“

Andreas Ströbel: „Wie groß der Unterschied ist, hängt stark von der konkreten Umgebung und den zugrunde gelegten Lizenzregeln ab. Die Beispielrechnung in den Unterlagen von Dbvisit stellt für eine übliche Konfiguration eine Ersparnis von ca. 75 % dar. Das kann passen, aber auch deutlich höher ausfallen. 

Für einen seriösen Vergleich müssen wir unter anderem Hardware, Core-Faktor, Anzahl und Nutzung der Primär- und Standby-Systeme, Oracle Verträge, Rabatte, Supportkosten und den Betrachtungszeitraum einbeziehen. Außerdem kann die Enterprise Edition aufgrund anderer benötigter Funktionen unabhängig vom RPO die richtige Wahl sein.“

Andreas Ströbel: „Ein guter Ausgangspunkt ist zunächst die technische Datenlücke. Dafür genügt eine einfache Modellrechnung: 

Transaktionen pro Minute × RPO in Minuten = potenziell betroffene Transaktionen 

Bei 300 Transaktionen pro Minute und einem RPO von fünf Minuten wären das bis zu 1.500 Transaktionen. Verteilen sich diese Transaktionen gleichmäßig, entsprechen 300 Transaktionen pro Minute fünf Transaktionen pro Sekunde. Bei einem RPO von unter einer Sekunde läge das theoretisch betroffene Fenster damit bei weniger als fünf Transaktionen. 

Im zweiten Schritt betrachten wir den wirtschaftlichen Effekt. Dafür müssen Unternehmen abschätzen, wie lange es dauert, fehlende Vorgänge zu identifizieren, zu prüfen und wiederherzustellen. Vereinfacht lässt sich rechnen: 

Prüf- und Rekonstruktionsaufwand × interner Kostensatz + Kosten der Betriebsunterbrechung + mögliche Folgekosten 

Dabei geht es nicht darum, einen scheinbar exakten Betrag zu produzieren. Die Rechnung soll sichtbar machen, ob die Kosten der Datenlücke in einem sinnvollen Verhältnis zu den Kosten einer besseren Absicherung stehen.“

Andreas Ströbel: „Am Anfang steht nicht das Produkt, sondern der Geschäftsprozess. Wir klären zunächst, welche Datenbank abgesichert werden soll, wie kritisch die dort verarbeiteten Vorgänge und Daten sind, und welches RPO tatsächlich benötigt wird. 

Danach analysieren wir die technische Umgebung. Dazu gehören Datenbankversion und Konfiguration, Transaktions- und Redo-Aufkommen, Storage-Performance, Netzwerkverbindung sowie die ggf. bestehende StandbyMP-Architektur. Parallel betrachten wir die Lizenzsituation und vergleichen mögliche Alternativen. 

Wenn die grundsätzlichen Voraussetzungen stimmen, empfehlen wir einen Proof of Concept unter möglichst realistischer Last. Dabei prüfen wir nicht nur das erreichbare RPO, sondern auch Aktivierung, Failover, Wiederanlauf und die betrieblichen Abläufe. Auf dieser Grundlage lässt sich entscheiden, ob ZDL technisch und wirtschaftlich zur Umgebung passt. Anschließend unterstützen wir je nach Bedarf bei Konzeption, Lizenzbetrachtung, Installation, Tests, Einführung und Betrieb.“

Frauke Jerabeck: „Nicht: „Können wir mit fünf Minuten Datenverlust leben?“ Sondern: „Wissen wir, was uns diese fünf Minuten für uns wirklich bedeuten?“ Denn erst wenn ein Unternehmen die Datenlücke in konkrete Geschäftsvorgänge, Arbeitsaufwand und Risiken übersetzt, kann es fundiert entscheiden, welches RPO angemessen ist. Genau dabei unterstützen wir: Wir verbinden die technische Analyse mit der wirtschaftlichen Perspektive und prüfen, ob Dbvisit Zero Data Loss zur Oracle Umgebung passt.“