Wiederveröffentlichen von Daten

Aktualisiert: 12. Dezember 2006

In einem Wiederveröffentlichungsmodell sendet der Verleger Daten an einen Abonnenten, der diese wiederum für eine beliebige Anzahl von Abonnenten erneut veröffentlicht. Dies ist hilfreich, wenn ein Verleger Daten an Abonnenten über eine langsame oder teure Kommunikationsverbindung senden muss. Falls es eine Reihe von Abonnenten am äußersten Ende dieser Verbindung gibt, kann das Verwenden eines Neuverlegers einen Großteil der Verteilungslast auf diese Seite der Verbindung auslagern.

Das Wiederveröffentlichen von Daten umfasst die folgenden Schritte:

1. Erstellen einer Publikation auf dem Verleger.
2. Erstellen eines Abonnements für die Publikation für den Wiederveröffentlichungsabonnenten.
3. Initialisieren des Abonnements. Das Abonnement muss initialisiert werden, bevor die Publikation auf dem Wiederveröffentlichungsabonnenten erstellt wird, sonst schlägt die Replikation fehl.
4. Erstellen einer Publikation in der Abonnementdatenbank auf dem Wiederveröffentlichungsabonnenten.
5. Erstellen von Abonnements für die Publikation auf dem Wiederveröffentlichungsabonnenten für die andern Abonnenten.
6. Initialisieren der Abonnements.

Hinweis:
Wenn Sie die Mergereplikation in einer Wiederveröffentlichungstopologie verwenden, müssen alle Wiederveröffentlichungsabonnenten Serverabonnements verwenden. Weitere Informationen zu Abonnementtypen finden Sie unter Abonnieren von Publikationen.

In der folgenden Abbildung fungieren sowohl der Verleger als auch der Neuverleger als ihre eigenen lokalen Verteiler. Falls beide zum Verwenden eines Remoteverteilers eingerichtet würden, müssten sich alle Verteiler auf derselben Seite der langsamen oder teuren Kommunikationsverbindung wie ihr Verleger befinden. Verleger müssen mit Remoteverteilern über zuverlässige, sehr schnelle Kommunikationsverbindungen verbunden sein.

Jeder Server kann als Verleger und als Abonnent fungieren. In der folgenden Abbildung ist beispielsweise eine Veröffentlichung einer Tabelle in London dargestellt, die an vier unterschiedliche Städte in den USA verteilt werden muss: Chicago, New York, San Diego und Seattle. Der Server in New York wird ausgewählt, die aus London stammende veröffentlichte Tabelle zu abonnieren, da der Standort in New York die folgenden Bedingungen erfüllt:

• Die Netzwerkverbindung zurück nach London ist relativ zuverlässig.
• Die Kosten für die Kommunikation zwischen London und New York sind akzeptabel.
• Es gibt gute Netzwerk-Kommunikationsverbindungen von New York zu allen anderen Abonnentenstandorten in den USA.
  

Die Replikation unterstützt die folgenden Wiederveröffentlichungsszenarien:

1Sie sollten die @published_in_tran_pub-Eigenschaft für die Mergepublikation festlegen. Standardmäßig wird bei der Transaktionsreplikation erwartet, dass Tabellen auf dem Abonnenten als schreibgeschützt behandelt werden. Wenn bei der Mergereplikation Datenänderungen an einer Tabelle in einem Transaktionsabonnement vorgenommen werden, kann eine Nichtkonvergenz von Daten auftreten. Es empfiehlt sich, solche Tabellen in der Mergepublikation als nur downloadbar anzugeben, um dieses Risiko zu vermeiden. Auf diese Weise kann verhindert werden, dass an der Tabelle vorgenommene Datenänderungen von einem Mergeabonnenten geuploadet werden. Weitere Informationen finden Sie unter Optimieren der Leistung der Mergereplikation durch nur downloadbare Artikel.

Siehe auch

Konzepte

Konfigurieren der Verteilung
Veröffentlichen von Daten und Datenbankobjekten
Abonnieren von Publikationen
Initialisieren eines Abonnements
Synchronisieren von Daten

Hilfe und Informationen

Informationsquellen für SQL Server 2005

Änderungsverlauf