Im folgenden Beispiel wird verdeutlicht, wie sich die Epochennummernmatrizen auf
verschiedenen Sites bei der Replikaterstellung und Synchronisation verändern.
- Bevor die Replikation erstmalig auf "boston_hub" aktiviert wird, ist die
Epochennummernmatrix des Replikats leer:
multitool lsepoch
For VOB replica "/vobs/dev":
Oplog IDs for row "original" (@ minuteman):
original=0
- Wenn der Administrator mit dem Befehl "mkreplica –export" ein neues
Replikat (sanfran_hub) erstellt, enthält die Epochennummernmatrix von "boston_hub"
eine Zeile für "sanfran_hub" (beachten Sie außerdem, dass der Administrator
das Original in "boston_hub" umbenannt hat):
For VOB replica "/vobs/dev":
Oplog IDs for row "boston_hub" (@ minuteman):
sanfran_hub=0
original=1
Oplog IDs for row "sanfran_hub" (@ goldengate):
original=0
sanfran_hub=0
- Nachdem der Administrator des Replikats "sanfran_hub" das Replikaterstellungspaket
importiert hat, sieht die Epochennummernmatrix für "sanfran_hub" wie folgt aus:
multitool lsepoch
For VOB replica "/vobs/dev":
Oplog IDs for row "boston_hub" (@ minuteman):
original=1
sanfran_hub=0
Oplog IDs for row "sanfran_hub" (@ goldengate):
original=1
sanfran_hub=1
- Beginnt nun die Entwicklungsarbeit auf den beiden Replikaten, aktualisiert jedes
Replikat seine eigenen Statuseinträge. Da jedoch zu diesem Zeitpunkt noch keine
Synchronisation erfolgt ist, ändert sich bei keinem der beiden Replikate der geschätzte
Status des jeweils anderen Replikats.
Auf "boston_hub":
multitool lsepoch
For VOB replica "/vobs/dev":
Oplog IDs for row "boston_hub" (@ minuteman):
sanfran_hub=0
original=9
Oplog IDs for row "sanfran_hub" (@ goldengate):
original=0
sanfran_hub=0
Auf "sanfran_hub":
multitool lsepoch
For VOB replica "/vobs/dev":
Oplog IDs for row "boston_hub" (@ minuteman):
original=1
sanfran_hub=0
Oplog IDs for row "sanfran_hub" (@ goldengate):
original=1
sanfran_hub=4
- Der Administrator von "boston_hub" gibt den Befehl "syncreplica –export" ein,
um ein Aktualisierungspaket für "sanfran_hub" zu generieren.
Die Zeile "sanfran_hub"
wird aktualisiert, damit ersichtlich wird, dass alle auf "boston_hub" ausgeführten
Operationen auf das Replikat "sanfran_hub" angewendet werden:
multitool lsepoch
For VOB replica "/vobs/dev":
Oplog IDs for row "boston_hub" (@ minuteman):
sanfran_hub=0
boston_hub=10
Oplog IDs for row "sanfran_hub" (@ goldengate):
boston_hub=10
sanfran_hub=0
- Der Administrator von "sanfran_hub" wendet das Aktualisierungspaket an. Die
Epochennummernmatrix für "sanfran_hub" enthält nun die Änderungen des Replikats
"boston_hub":
multitool lsepoch
For VOB replica "/vobs/dev":
Oplog IDs for row "boston_hub" (@ minuteman):
boston_hub=10
sanfran_hub=0
Oplog IDs for row "sanfran_hub" (@ goldengate):
boston_hub=10
sanfran_hub=4
Beispiel: Synchronisation und die Epochennummernmatrix
Im folgenden Beispiel wird verdeutlicht, wie sich die Epochennummernmatrizen auf
verschiedenen Replikaten bei der Replikaterstellung und Synchronisation verändern.
- Zwischen der Aktivierung und der erstmaligen Replizierung von "boston_hub"
ist die Epochennummernmatrix des Replikats leer:
multiutil lsepoch -clan
telecomm -site boston_hub -family PRODA -user lexadmin -password secret
Multiutil:
Estimates of the epochs from each site replayed at each site ‘boston_hub’
(@host1):
boston_hub: 0
- Nachdem der Administrator des Replikats "sanfran_hub" das Replikaterstellungspaket
importiert hat, sieht die Epochennummernmatrix für "sanfran_hub" wie folgt aus:
multiutil
lsepoch -clan telecomm -site sanfran_hub -family PRODA -user sfadmin -password
secret
Multiutil: Estimates of the epochs from each site replayed
at each site ‘SANFRAN_HUB’ (@host2):
boston_hub: 2
SANFRAN_HUB:0
Anmerkung: Die Schätzung der
eigenen Operationen auf "sanfran_hub" beträgt null. In diesem Beispiel schätzt
"sanfran_hub" außerdem, dass auf "boston_hub" zwei Datenbankoperationen stattgefunden
haben.
Bei diesen Operationen kann es sich um verschiedene Vorgänge wie die Erstellung eines neuen
Datensatzes oder die Erstellung eines Replikats handeln.
- Beginnt nun die Entwicklungsarbeit auf den beiden Replikaten, aktualisiert jedes
Replikat seine eigenen Statuseinträge. Da jedoch zu diesem Zeitpunkt noch keine
Synchronisation erfolgt ist, ändert sich bei keinem der beiden Replikate der geschätzte
Status des jeweils anderen Replikats.
Auf "boston_hub":
multiutil lsepoch -clan telecomm -site
boston_hub -user lexadmin -password secret boston_hub
Multiutil: Estimates
of the epochs from each site replayed at each site ‘boston_hub’ (@host1):
boston_hub:
12
SANFRAN_HUB:0
Auf "sanfran_hub":
multiutil lsepoch
-clan telecomm -site sanfran_hub -user sfadmin -password secret
Multiutil:
Estimates of the epochs from each site replayed at each site ‘SANFRAN_HUB’
(@host2):
boston_hub: 2
SANFRAN_HUB:7
- Der Administrator von "boston_hub" gibt den Befehl "syncreplica -export" ein,
um ein Aktualisierungspaket für "sanfran_hub" zu generieren.
- Auf "boston_hub" wird die Zeile "sanfran_hub" aktualisiert, damit ersichtlich wird,
dass alle auf "boston_hub" ausgeführten Operationen an das Replikat "sanfran_hub"
gesendet wurden:
multiutil lsepoch -clan telecomm -site boston_hub -user lexadmin -password
secret sanfran_hub
Multiutil: Estimates of the epochs from each site
replayed at each site ‘SANFRAN_HUB’ (@host1):
boston_hub: 12
SANFRAN_HUB:0
- Der Administrator von "sanfran_hub" importiert das Aktualisierungspaket. Die
Epochennummernmatrix für "sanfran_hub" enthält nun die Änderungen des Replikats
"boston_hub":
multiutil lsepoch -clan telecomm -site sanfran_hub -user sfadmin
-password secret sanfran_hub
Multiutil: Estimates of the epochs from
each site replayed at each site ‘SANFRAN_HUB’ (@host1):
boston_hub:
12
SANFRAN_HUB:7