Das System der garantierten Nachrichtenzustellung stellt Folgendes sicher:
Alle replizierten Vorgänge werden in der korrekten Reihenfolge übernommen. Siehe Sicherstellen, dass die replizierten Vorgänge in der korrekten Reihenfolge übernommen werden.
Keine replizierten Vorgänge werden übersehen. Siehe Verlorene oder beschädigte Nachrichten erneut senden.
Kein replizierter Vorgang wird zweimal angewendet. Siehe Sicherstellen, dass Nachrichten nur einmal angewendet werden.
Das System der garantierten Nachrichtenzustellung verwendet die folgenden Informationen:
Die Statusinformationen, die in der SYSREMOTEUSER-Systemtabelle verwaltet werden Diese Tabelle enthält eine Zeile für jeden Subskribenten mit Statusinformationen über Nachrichten, die an diesen Subskribenten versendet und von ihm empfangen werden. Zum Beispiel:
In der konsolidierten Datenbank enthält die SYSREMOTEUSER-Systemtabelle eine Zeile für jeden entfernten Benutzer.
In den jeweiligen entfernten Datenbanken enthält die SYSREMOTEUSER-Systemtabelle eine einzelne Zeile mit Informationen über die konsolidierte Datenbank.
Die SYSREMOTEUSER-Systemtabelle wird durch den SQL Remote-Nachrichtenagenten (dbremote) verwaltet.
In der Subskribenten-Datenbank sendet der SQL Remote-Nachrichtenagent (dbremote) eine Bestätigung an die Publikationseigentümer-Datenbank, um sicherzustellen, dass die SYSREMOTEUSER-Systemtabelle an jedem Ende der Subskription korrekt verwaltet ist.
Siehe ISYSREMOTEUSER-Systemtabelle.
Die Informationen im Header der Nachrichten Der SQL Remote-Nachrichtenagent (dbremote) liest die Header-Daten in den Nachrichten und verwendet diese Informationen, um die SYSREMOTEUSER-Systemtabelle zu aktualisieren. Eine Nachricht enthält die folgenden Daten in ihrem Header:
Den resend_count-Wert Ein Zähler, der die Häufigkeit protokolliert, mit der die Empfängerdatenbank Nachrichten verloren hat.
Im folgenden Beispiel ist der resend_count-Wert 1.
Current message's header: (1-0000942712-0001119170-0) |
Das Transaktionslog-Offset der letzten COMMIT-Anweisung in der vorherigen Nachricht. Im folgenden Beispiel ist das Transaktionslog-Offset der letzten Festschreibung in der vorherigen Nachricht 0000942712.
Previous message's header:(0-0000923357-0000942712-0) Current message's header: (0-0000942712-0001119170-0) |
Transaktionslog-Offset der letzten COMMIT-Anweisung in der aktuellen Nachricht Im folgenden Beispiel ist die letzte Festschreibung in der aktuellen Nachricht 0001119170:
Current message's header: (0-0000942712-0001119170-0) |
Wenn eine Transaktion mehrere Nachrichten umfasst, können beide Transaktionslog-Offsets identisch sein, bis die letzte Nachricht ein COMMIT enthält.
Im folgenden Beispiel tritt das COMMIT erst bei der vierten Nachricht auf:
(0-0000942712-0000942712-0) (0-0000942712-0000942712-1) (0-0000942712-0000942712-2) (0-0000942712-0001119170-3) |
Eine Sequenznummer Wenn eine Transaktion mehrere Nachrichten umfasst, wird diese Sequenznummer verwendet, um die Nachrichten korrekt zu sortieren.
Eine Sequenznummer von null kann folgendes angeben:
Die Nachricht ist nicht Teil einer mehrteiligen Nachricht, wenn die Transaktionslog-Offsets verschieden sind.
Im folgenden Beispiel sind die Nachrichten nicht Teil einer mehrteiligen Nachricht:
(0-0000923200-0000923357-0)
(0-0000923357-0000942712-0)
|
Die Nachricht ist die erste einer mehrteiligen Nachricht, wenn die Transaktionslog-Offsets gleich sind.
Im folgenden Beispiel ist die erste Nachricht ein Teil einer mehrteiligen Nachricht:
(0-0000942712-0000942712-0) (0-0000942712-0000942712-1) (0-0000942712-0000942712-2) (0-0000942712-0001119170-3) |
Sicherstellen, dass die replizierten Vorgänge in der korrekten Reihenfolge übernommen werden
Verlorene oder beschädigte Nachrichten erneut senden
Sicherstellen, dass Nachrichten nur einmal angewendet werden
 |
Kommentieren Sie diese Seite in DocCommentXchange.
|
Copyright © 2010, iAnywhere Solutions, Inc. - SQL Anywhere 12.0.0 |