Dieses INFO-Posting ist ein ernst gemeintes Oxymoron.... auch wenn "leeres
volles" Replikat so ironisch klingt wie jedes andere Oxymoron. Das Prinzip sieht
folgendermaßen aus:
1) Nehmen Sie Ihre Datenbank (noch unrepliziert) und entfernen Sie alle Daten (nur die Struktur bleibt komplett erhalten). Heben Sie die Daten in einer getrennten Datei auf, damit Sie sie später wieder hinzufügen können.
2) Machen Sie die DB replizierbar und erstellen Sie ein Replikat davon. Dieses Replikat ist dann ein volles Replikat, dass leer ist, weil ohne Daten.
3) Füllen Sie Ihren DM mit Daten auf und erstellen Sie weitere Replikate davon.
4) Wenn Sie das "volle leere" (engl. "empty full" = EF) Replikat synchronisieren, dann machen Sie die Synchronisierung immer vom EF-Replikat in Richtung eines anderen Voll- oder Teilreplikats. Damit ist sicher, dass es keine Daten enthält, aber stets das aktuelle Schema besitzt.
5) Stellen Sie sicher, dass das EF-Replikat von keinem Synchronizer gemanagt wird (weil geplante Synchronisierungen in nur eine Richtung nicht möglich sind und weil auch wegen anderer Verwendungsmöglichkeiten von EF-Replikaten ein Management nicht sinnvoll ist).
Nun, wozu taugen also EF-Replikate?
1) Die Inspiration dazu kam ursprünglich aus einem Kommentar von Alden Streeter in der Newsgroup microsoft.public.access.replication in dem es darum ging, dass es keine Möglichkeit gab, zwei Teilreplikate clientseitig miteinander zu synchronisieren... daher gab es bei Teilreplikaten keine "Backup per Replikat"-Funktionalität. Das geht aber mit einer Kopie eines EF-Replikates auf der lokalen Maschine (eine einfache Dateikopie ist hier sicher, weil es keine Daten enthält und daher kein Risiko besteht, Fehler zu erzeugen; Sie können auch ein neues Replikat vom EF-Replikat erzeugen und es mit MoveReplica auf der lokalen Maschine platzieren. Sogar über eine 28.8-Verbindung lässt sich ein leeres Replikat recht schnell kopieren). Danach können Sie eine vollständige Synchronisierung in beide Richtungen zwischen dem Teilreplikat und dem EF-Replikat durchführen. Wenn Sie immer nur mit einem Teilreplikat Ihres Hubs synchronisieren -- NIE mit dem Vollreplikat -- ist sicher gestellt, dass Ihr ehemaliges EF-Replikat jetzt ein Vollreplikat ist, das aber ein de facto Teilreplikat ist (engl. de facto partial = DFP), weil es immer nur jene Daten beinhalten kann, die sich im Teilreplikat befinden. Damit haben Sie ein Backup! Zudem eine einfache Möglichkeit ein neues Teilreplikat zu erstellen, wenn Sie eines benötigen! Solange Sie niemals eine Synchronisierung in beide Richtungen mit dem Hub durchführen oder mit irgendeinem anderen Vollreplikat, das alle Daten enthält, kann Ihnen dieses DFP in vielfacher Hinsicht gute Dienste leisten.
2) Ein häufiges Problem für Leute, die keine Replikatfarmen auf Ihren Servern erstellen, ist, dass der Synchronizer aus verschiedenen Gründen als ungültig markiert wird und dann keine Synchronisierungen mehr gelingen bis eine direkte Synchronisierung oder ein anderes drastisches Mittel angewandt wird. Das Wissen darüber, dass eine Replikatfarm in Hinkunft das Problem lösen kann, hilft Ihnen noch nicht viel weiter, denn zuerst müssen Sie mal eine Möglichkeit finden, den entfernten Replikaten beizubringen, dass der Synchronizer tatsächlich passende Partner hat. Aber jetzt können Sie ja EF-Replikate verwenden, um sie zu aktualisieren! Fügen Sie einfach die Vollreplikate zur Liste derer hinzu, die vom Synchronizer gemanagt werden sollen, stellen Sie sicher, dass jedes dieser Replikate mit jedem anderen synchronisiert wird, dann machen Sie eine EINWEG-SYNCHRONISIERUNG (wichtig!) von Ihrem EF-Replikat zu einem dieser Replikate. JETZT können Sie das EF-Replikat mit MoveReplica zur entfernten Maschine schicken (sollte recht schnell gehen, weil es ja keine Daten enthält!) und wenn es erst mal auf der lokalen Maschine ist, machen Sie eine Einweg-Synchronisierung vom EF-Replikat zum Replikat auf der entfernten Maschine; dann schicken Sie es mit MoveReplica zurück zum Server. Damit haben Sie ein Update der entfernten Replikate durchgeführt mit der ganzen Info, was alles vom Synchronizer gemanagt wird etc. und ermöglichen dadurch, dass die Synchronisierungen wieder funktionieren!
WARNUNG:
Versuchen Sie nicht ein FE-Replikat zu erstellen, indem Sie ein Vollreplikat nehmen und alle Daten daraus löschen! Wenn Sie das tun, sorgen Sie dafür, dass bei der nächsten Synchronisierung mit den Vollreplikaten alle Daten gelöscht werden! Diese Arbeit MUSS also gemacht werden bevor Sie die Datenbank replizieren. Die einzige andere Möglichkeit ist, ein RFE zu erstellen (s. Glossar unten).
GLOSSAR:
FE-Replikat: Ein volles leeres ("Full Empty")-Replikat, d.h. ein Vollreplikat, das nicht gemanagt wird und keine (oder fast keine) Daten enthält. Eine Dateikopie ist kein Problem, weil es keine Datenoperationen gab und deshalb keine Datenfehler oder -konflikte entstehen können. Es sollten damit nur Synchronisierungen in Richtung der Vollreplikate durchgeführt werden.
RFE-Replikat: Ein retroaktives volles leeres ("Retroactive Full Empty") Replikat. Wenn möglich, schnappen Sie sich ein Exemplar des Access/Office/VB Advisor vom August 1997 (oder einen Nachdruck bei http://www.advisor.com) und suchen Sie den Artikel von Peter Miller und Mary Chipman mit dem Titel "Effective OLTP/OLAP Balancing Thru Creative Replication." Dieser Artikel beschreibt, wie Sie die Tombstone-Datensätze löschen können, damit es möglich wird, ein Vollreplikat zu erstellen, alle Daten zu löschen und dann die Tombstones. Auf diese Art gehen keine Daten in anderen Replikaten verloren -- der perfekte Weg, um ein RFE zu erstellen! Danach haben Sie alle Features eines FE-Replikats.
DFP-Replikat: Ein de facto Teilreplikat ("De Facto Partial"), d.h. ein Vollreplikat, das nicht gemanagt wird und immer nur mit einem Teilreplikat synchronisiert wird. Daher hat es, obwohl es alle Fähigkeiten eines Vollreplikates besitzt (neue Replikate erzeugen, Synchronisierungen durchführen etc.), nur die Daten des Teilreplikates, mit dem es synchrosiert wird. Das macht es zu einem de facto Teilreplikat in Hinsicht auf die Daten, die es enthält... und es ist ideal dazu geeignet, Backups von Teilreplikaten zu erstellen sowie bei Bedarf ein korruptes Teilreplikat zu ersetzen.
Also verwenden Sie diese neuen, der Verwaltung dienenden, Replikattypen am besten noch heute!
