> ## Content Index
> Fetch the complete content index at: https://blog.dl-cons.de/llms.txt
> Use this file to discover other available public pages before exploring further.

# Dbvisit StandbyMPs Großer Schritt - die Zero Data Loss Option
- URL: https://blog.dl-cons.de/dbvisit-standbymps-grosser-schritt-die-zero-data-loss-option/
- Published: 2026-09-15T09:44:11.000Z
- Updated: 2026-09-15T09:44:11.000Z
- Description: Die Oracle Database Standard Edition 2 (SE2) hat im Gegensatz zur Enterprise Edition (EE) keine eingebaute Funktion für Standby-Datenbanken. Diese Lücke schließt seit vielen Jahren das Produkt Dbvisit Standby bzw. StandbyMP.
- Author: Dierk Lenz
- Tags: Oracle, SE2, Dbvisit StandbyMP, Zero Data Loss

Der Verlust von wenigen Minuten an Transaktionsdaten ist für viele Datenbanken ein recht großes Problem, wenn z.B. in der Teileproduktion die Daten in der Datenbank nicht mehr zu den Teilen auf dem Produktionsband passen. Oft heißt das: Bänder leer räumen und neu anfangen. Oder bei einer Kundendatenbank: Dutzende Kunden anrufen und den Verlust der Bestellung o.ä. besprechen. Mit der Zero Data Loss Option (ZDL) hat Dbvisit StandbyMP beim Wiederherstellungszeitpunkt im Desaster Recovery-Fall (DR) einen großen Schritt gemacht. 

## Das Archivelog-Problem beim Standardverfahren

Dbvisit StandbyMP ist eine externe Software, die für Oracle SE2 Datenbanken ein DR ermöglicht. Hierzu werden traditionell die Offline Redologs - im Oracle-Jargon: Archivelogs - genutzt. (Anmerkung: Das **MP** in StandbyMP steht für MultiPlatform, d.h. es gibt auch Standby-Datenbanken für SQL Server und PostgreSQL. Das ist aber hier nicht das Thema.)

Es liegt in der Natur der Sache, dass eine Archivelog-Datei erst nach deren Fertigstellung im Rahmen eines Log Switch übertragen wird. Die Transaktionsinformationen innerhalb der aktiven Redolog-Datei müssen daher auf den nächsten Log Switch warten. Es werden also regelmäßig Log Switches ausgelöst, um letztendlich die Standby-Datenbank nicht allzu weit hinter die Primärdatenbank zurückfallen zu lassen. Dabei sollte man nicht zu kurz mit den Log Switch-Intervallen werden, da dies gerade in Umgebungen mit großer Transaktionslast zu Performance-Problemen führen kann.

Als guter Kompromiss hat sich eine Log Switch-Frequenz von zehn Minuten herausgestellt. Daraus ergibt sich, dass bei einem Desaster-Fall im schlimmsten Fall eben diese zehn Minuten nicht in der bereitgestellten DR-Datenbank vorhanden sind.

## Die Zero Data Loss Option

Die neue, zusätzlich zu erwerbende, ZDL Option sorgt nun neben der weiterhin stattfindenden StandbyMP-Archivelog-Funktionalität dafür, dass aus den Online Redologs neue Einträge sofort gelesen und in eine Kopie auf der Standby-Seite geschrieben werden. Damit werden die Redolog-Einträge nahezu verzögerungsfrei für ein eventuell notwendiges DR zur Verfügung gestellt. (Hierzu sei angemerkt, dass der Name *Near Zero Data Loss* etwas korrekter wäre.)

Für die neue Funktionalität nutzt die Software viele der bereits vorhandenen Komponenten, z.B. zur Netzwerkübertragung.

ZDL kann in der Administrationsoberfläche oder aus der Kommandozeile heraus aktiviert werden. Dort wird dann auch der aktuelle Zustand inklusive der *Data Loss Exposure* angezeigt, z.B. mit 1sec oder 2sec. Die Einfachheit der Konfiguration ist ein großer Vorteil der Lösung: Je einfacher die Konfiguration, desto weniger Fehler können hierbei gemacht werden.

## Pros und Contras

Zunächst einmal ist es ein Riesenschritt für SE2-Datenbanken und StandbyMP: Die Möglichkeit, einen Failover (fast) ohne Datenverlust durchführen zu können, ist definitiv ein Meilenstein und ein riesiges Pro!

Für Unternehmen, bei denen der Verlust von einigen Minuten an Transaktionen keine Bauchschmerzen bereitet, ist es jedoch auch gut, nach wie vor mit StandbyMP in der Standardkonfiguration fahren zu können.

Einige Punkte sollten aber auf jeden Fall erwähnt werden, um ein objektives Gesamtbild zu erhalten:

1. Dadurch, dass die Standardfunktionalität von StandbyMP unverändert weiter läuft, werden die Redolog-Informationen doppelt an den Standby-Server übertragen. In den meisten Umgebungen sollte das kein Problem darstellen. Bei hoher Transaktionslast könnte es aber zu Problemen kommen.
2. Aktuell muss für das Auslesen der Redologs mindestens ein Member pro Gruppe in einem Dateisystem liegen. Das ist insbesondere für Datenbanken mit Oracle ASM als Basis zunächst nicht gegeben und nur begrenzt machbar. Hiervon sind z.B. die sogenannten DB Systems auf Oracle Database Appliances betroffen.

Bei bestehenden Konfigurationen, die das Intervall für Log Switches nach unten ausgereizt haben und eine große Transaktionslast haben, kann sich ZDL positiv auf die Gesamt-Performance auswirken. Durch die parallel laufende Übertragung der Redolog-Informationen mit ZDL kann das Log Switch-Intervall großzügig hochgesetzt werden. Dadurch wird die IO-Last für den DB Writer reduziert.

## Fazit

Dbvisit StandbyMP ist mit der ZDL Option ein großer Schritt gelungen. Unternehmen mit hohen RPO-Anforderungen (Recovery Point Objective) können nun Dbvisit StandbyMP mit ZDL nutzen ohne Gefahr zu laufen, durch extrem kurze Log Switch-Intervalle in Performance-Probleme zu geraten.

Wenn Sie hierzu Fragen haben oder mehr erfahren möchten, kontaktieren Sie mich gerne.