Geändertes Programmverhalten in der SQL Server-Replikation
In diesem Thema werden Änderungen im Verhalten der SQL Server-Replikation beschrieben. Verhaltensänderungen wirken sich darauf aus, wie Features in SQL Server 2008 im Vergleich zu früheren Versionen von SQL Server funktionieren oder zusammenspielen.
Geändertes Programmverhalten in SQL Server 2005
In diesem Abschnitt werden Änderungen im Programmverhalten von Replikationsfeatures in SQL Server 2005 beschrieben.
Verändertes Programmverhalten mit Auswirkungen auf alle Replikationstypen
Die folgenden Änderungen betreffen alle Replikationstypen.
Feature |
Beschreibung |
|---|---|
Sicherheitsmodell des Replikations-Agents |
In früheren Versionen von SQL Server wurden Agents standardmäßig im Kontext des SQL Server-Agent-Dienstkontos ausgeführt. SQL Server ermöglicht jetzt eine differenzierte Steuerung der Konten, in deren Kontext die Replikations-Agents ausgeführt und die integrierten Microsoft Windows-Verbindungen mit Datenbanken und anderen Ressourcen hergestellt werden, wobei für jeden Agent ein eigenes Konto angegeben werden kann. Weitere Informationen finden Sie unter Sicherheit und Schutz (Replikation) und unter Sicherheitsmodell des Replikations-Agents. Informationen dazu, wie sich diese Änderung auf Aktualisierungen auswirkt, finden Sie im Abschnitt "Das neue Sicherheitsmodell des Replikations-Agents" unter Überlegungen zum Aktualisieren replizierter Datenbanken sowie im Thema Wichtige Änderungen in der SQL Server-Replikation. |
Synchronisierungsverwaltung von Windows |
In den SQL Server-Versionen vor SQL Server 2005 war das Synchronisieren von Abonnements mit dem Synchronisierungs-Manager (= Synchronisierungsverwaltung) standardmäßig möglich. In SQL Server 2005 müssen Sie diese Option explizit aktivieren, wenn Sie die Synchronisierungsverwaltung verwenden möchten. Weitere Informationen finden Sie unter Vorgehensweise: Synchronisieren eines Abonnements mithilfe der Synchronisierungsverwaltung von Windows (Synchronisierungsverwaltung von Windows). |
Replikationskonflikt-Viewer (Replication Conflict Viewer) |
Bei SQL Server 2000 ist der Replikationskonflikt-Viewer zum Verteilen enthalten. Bei SQL Server 2005 ist der Viewer nicht gesondert enthalten. Zum Einbinden des Replikationskonflikt-Viewers in eine Anwendung müssen Sie Microsoft .NET Framework 2.0 auf dem Computer installieren, auf dem die Anwendung bereitgestellt wird, und eine Reihe von Dateien auf den Computer kopieren. Weitere Informationen finden Sie unter "Weitere Probleme beim Replikationsupdate" in der Hilfe zum Updateratgeber. Weitere Informationen zum Updateratgeber finden Sie unter Verwenden des Updateratgebers zur Vorbereitung auf Aktualisierungen. |
Änderungen bei Schemaoptionen |
Über Schemaoptionen können Sie angeben, wie den Tabellen zugeordnete Attribute und Objekte, wie z. B. Indizes und Einschränkungen, repliziert werden. In SQL Server 2005 wurde das Verhalten einiger Schemaoptionen geändert. Weitere Informationen dazu finden Sie im nächsten Abschnitt dieses Themas. |
Verhaltensänderungen von Schemaoptionen
In der folgenden Tabelle sind Änderungen bei Schemaoptionen in SQL Server 2005 zusammengefasst.
.gif "Hinweis") Hinweis |
|---|
Wenn die Schemaoption 0x8000 in SQL Server 2000 festgelegt war, wird sie beim Update auf SQL Server 2005 deaktiviert. Für die Schemaoptionen 0x10 oder 0x40 wird durch die Replikation in SQL Server 2005 möglicherweise eine größere Anzahl von Indizes erstellt als in SQL Server 2000. |
Option |
Verhalten bei Festlegung in SQL Server 2000 |
Verhalten bei Festlegung in SQL Server 2005 |
|---|---|---|
0x80 |
Erstellt eine Einschränkung oder einen Index. Ist die Option 0x8000 ebenfalls aktiviert, wird der Primärschlüssel als Einschränkung mit einem Index erstellt. Ist die Option 0x8000 nicht aktiviert, wird nur der Index für die Primärschlüsselspalte erstellt. |
Erstellt eine Primärschlüsseleinschränkung auf dem Abonnenten. Alle Indizes bezüglich der Einschränkung werden ebenfalls repliziert, auch wenn die Optionen 0x10 und 0x40 nicht aktiviert sind (diese Optionen steuern die Indexerstellung in anderen Fällen). |
0x4000 |
Erstellt eine Einschränkung oder einen Index. Ist die Option 0x8000 ebenfalls aktiviert, wird die UNIQUE-Einschränkung als Einschränkung mit einem Index erstellt. Ist die Option 0x8000 nicht aktiviert, wird nur der Index für die Spalte erstellt. |
Erstellt UNIQUE-Einschränkungen auf dem Abonnenten. Alle Indizes bezüglich der Einschränkung werden ebenfalls repliziert, auch wenn die Optionen 0x10 und 0x40 nicht aktiviert sind (diese Optionen steuern die Indexerstellung in anderen Fällen). |
0x8000 |
Erstellt Primärschlüsseleinschränkungen und UNIQUE-Einschränkungen, wenn die Optionen 0x80 oder 0x4000 ebenfalls angegeben sind. Ist keine dieser Optionen angegeben, hat die Option 0x8000 keine Auswirkungen. |
Die Option hat keine Auswirkungen. |
Verändertes Programmverhalten bei der Transaktionsreplikation
Die folgenden Änderungen betreffen die Transaktionsreplikation.
Feature |
Beschreibung |
|---|---|
Besitz von Abonnentenobjekten |
Wenn Sie zum Erstellen einer Veröffentlichung den Assistenten für neue Veröffentlichung von SQL Server 2005 verwenden, wird als Besitzer von auf dem Abonnenten erstellten Objekten standardmäßig der Wert für den Besitzer der zugehörigen Objekte auf dem Verleger verwendet. In früheren Versionen wurde der Besitzer während der Erstellung des Objekts auf dem Abonnenten nicht angegeben. Als Wert wurde standardmäßig der mit dem Verteilungs-Agent-Konto, das zum Herstellen der Verbindung mit dem Abonnenten verwendet wird, verknüpfte Besitzer angenommen. Für die gespeicherte Prozedur sp_addarticle (Transact-SQL) hat sich dieses Verhalten nicht geändert. |
Sicherheitsmodus für aktualisierbare Abonnements |
Der @security_mode-Parameter von sp_link_publication steuert, wie die Trigger für das sofortige Aktualisieren von Abonnements Aufrufe auf dem Verleger ausführen. In SQL Server 2005 gibt es für diesen Parameter folgende Optionen:
In früheren Versionen von SQL Server wurde mit der Option 0 statt eines Verbindungsservers ein dynamischer Remoteprozeduraufruf (Remote Procedure Call, RPC) vom Abonnenten an den Verleger angegeben. |
Verändertes Programmverhalten bei der Mergereplikation
Die folgenden Änderungen betreffen die Mergereplikation.
Feature |
Beschreibung |
|---|---|
Veröffentlichungskompatibilitätsgrad |
In früheren Versionen von SQL Server wurde der Kompatibilitätsgrad automatisch erhöht, wenn Sie ein Feature aktivierten, das einen höheren Grad erforderte. In SQL Server 2005 müssen Sie den Kompatibilitätsgrad manuell auf 90RTM festlegen, bevor Sie eine Funktionalität aktivieren, die diesen Kompatibilitätsgrad erfordert. Weitere Informationen zum Kompatibilitätsgrad bei Mergeveröffentlichungen finden Sie im entsprechenden Abschnitt im Thema Verwenden mehrerer Versionen von SQL Server in einer Replikationstopologie. |
Kompensierende Aktionen |
In früheren Versionen von SQL Server wurden kompensierende Aktionen ausgeführt, falls während der Synchronisierung Fehler (z. B. Einschränkungsverletzungen) festgestellt wurden. In bestimmten Fällen ist dieses Verhalten erwünscht, in anderen kann es jedoch problematisch sein. Ein falsch konfigurierter Abonnent, der einen Fehler generiert, kann beispielsweise Änderungen verursachen, die auf dem Verleger und allen anderen Abonnenten rückgängig gemacht werden müssen. In SQL Server 2005 steuert der @compensate_for_errors-Parameter von sp_addmergearticle, ob kompensierende Aktionen ausgeführt werden. Ist der Parameter auf False (Standardwert) festgelegt, sind die kompensierenden Aktionen deaktiviert. Fehler werden jedoch dennoch protokolliert, und nachfolgende Zusammenführungen versuchen weiterhin, die Änderungen anzuwenden. Zwar sind die Daten in den betroffenen Zeilen nicht mehr konvergent, doch können Sie nach Behebung des Fehlers die Änderung anwenden und die Konvergenz der Daten ist wieder gewährleistet. Ist der Parameter auf True festgelegt, führt eine Änderung, die während der Synchronisierung nicht auf einen Knoten angewendet werden kann, zu kompensierenden Aktionen, die die Änderung auf allen anderen Knoten rückgängig machen. Hinweis
Wenn die Quelltabelle für einen Artikel bereits in einer anderen Veröffentlichung veröffentlicht wurde, muss der Wert von @compensate_for_errors für beide Artikel identisch sein. Bei Pullabonnements auf Abonnenten mit SQL Server 2000, Version 8.00.858 und früher (einschließlich Service Pack 3), werden kompensierende Aktionen auch dann ausgeführt, wenn @compensate_for_errors auf False festgelegt ist.
|
Konflikttabellen |
In früheren Versionen von SQL Server erstellte eine Mergereplikation eine einzelne Konflikttabelle für jeden Tabellenartikel in einer Veröffentlichung (mit einem Namen im Format conflict_<ArticleName>). In SQL Server 2005 sind die Informationen in zwei Tabellen enthalten: in der MSmerge_conflicts_info-Tabelle und in einer Tabelle mit dem Namensformat MSmerge_conflict_<PublicationName>_<ArticleName>. |
Beibehaltungsbasiertes Metadatencleanup |
SQL Server 2005 verwendet das in SQL Server 2000 Service Pack 1 eingeführte beibehaltungsbasierte Metadatencleanup. Metadaten werden in regelmäßigen Abständen aus den folgenden Systemtabellen gelöscht:
|
Parameter @keep_partition_changes |
Der @keep_partition_changes-Parameter wurde in früheren Versionen von SQL Server standardmäßig auf False festgelegt, da er dazu führt, dass mehr Daten auf dem Verleger gespeichert werden. Er ist jetzt auf True festgelegt, wenn der Veröffentlichungskompatibilitätsgrad 90RTM, oder höher ist und der @use_partition_groups-Parameter auf False festgelegt ist. Weitere Informationen zu diesen Optionen finden Sie unter Parametrisierte Zeilenfilter. |