Datenbankreplikation (Teil 2)

Im ersten Teil wurden die Grundlagen der asynchronen Replikation vorgestellt. Heute ist das Thema die Generierung der Replikationssätze in der Originaldatenbank.

Die zur Replikation notwendigen Änderungsdaten werden bei Update-Ereignissen der Datenbank gewonnen, in denen modifizierte Datensegmente aus dem Cache in die Datenbank geschrieben werden. Im Normalfall werden diese Segmente auch in die Transaktionslogs (.tl1, .tl2, .tl3) geschrieben.
Bei eingeschaltetem Replikationsmodus werden die Updatedaten zusätzlich in die aktive Replikationsdatei geschrieben, deren Name sich aus Datenbankname, Datenbank-Seriennummer und Replikations-Seriennummer zusammensetzt. Hat die Datenbank bespielsweise den Namen "crm.ca1" und die Seriennummer 2384, so lautet die erste aktive Replikationsdatei auf "crm_002384_000001.$$$".
Über eine Datenbankeinstellung wird die maximale Zeitspanne festgelegt, nach der die aktive Replikationsdatei geschlossen wird und eine neue Datei angelegt wird. Der Zeitraum darf im Bereich von 5 Minuten bis zu 4 Stunden liegen. Nach Ablauf der Zeit wird die aktive Datei geschlosen, danach auf "crm_002384_000001.tlg" umbenannt und anschließend eine neuer Replikationssatz unter "crm_002384_000002.$$$" geöffnet. Alle .tlg-Files sind somit abgeschlossene Replikationssätze und können sofort weiterverarbeitet werden.

Für die Replikationssätze muss ein eigenes Zielverzeichnis angegeben werden, das bevorzugt auf einem anderen Datenträger als die Datenbank liegt. Im Gegensatz zu den Transaktionslogs, die im Zyklus immer wieder überschrieben werden, bleiben die Replikationsdateien erhalten. Daher muss im Zielverzeichnis für eine ausreichende Menge an freiem Speicherplatz gesorgt sein.

Im nächsten Teil kommen wir zur Konsolidierung und Übertragung der Replikationssätze. Wie immer freue ich mich über Ihre Fragen und Kommentare.