Vornehmen von Schemaänderungen in Veröffentlichungsdatenbanken

• Schemaänderungen unterliegen den Einschränkungen von Transact-SQL. Beispielsweise können Sie mit ALTER TABLE keine Primärschlüsselspalten ändern.

• Datentypzuordnung wird nur für die Anfangsmomentaufnahme ausgeführt. Schemaänderungen werden nicht vorherigen Versionen von Datentypen zugeordnet. Beispiel: Wenn die ALTER TABLE ADD datetime2 column-Anweisung in SQL Server 2008 verwendet wird, wird der Datentyp nicht für SQL Server 2005-Abonnenten in nvarchar umgewandelt. In einigen Fällen werden Schemaänderungen auf dem Verleger blockiert.

• Wenn für eine Veröffentlichung die Weitergabe von Schemaänderungen festgelegt ist, werden die Schemaänderungen unabhängig davon weitergegeben, wie die verbundene Schemaoption für einen Artikel in der Veröffentlichung festgelegt ist. Beispiel: Sie entscheiden sich, FOREIGN KEY-Einschränkungen für einen Tabellenartikel nicht zu replizieren, geben dann jedoch einen ALTER TABLE-Befehl aus, mit dem der Tabelle auf dem Verleger ein Fremdschlüssel hinzugefügt wird. In diesem Fall wird der Fremdschlüssel der Tabelle auf dem Abonnenten hinzugefügt. Um das zu verhindern, deaktivieren Sie die Weitergabe von Schemaänderungen, bevor Sie den ALTER TABLE-Befehl ausgeben.

• Schemaänderungen sollten nur auf dem Verleger und nicht auf den Abonnenten (einschließlich Wiederveröffentlichungsabonnenten) ausgegeben werden. Die Mergereplikation verhindert Schemaänderungen auf dem Abonnenten. Die Transaktionsreplikation verhindert die Änderungen zwar nicht, es können jedoch Fehler bei der Replikation auftreten.

• An einen Wiederveröffentlichungsabonnenten weitergegebene Änderungen werden standardmäßig an dessen Abonnenten weitergegeben.

• Verweist die Schemaänderung auf Objekte oder Einschränkungen, die auf dem Verleger, aber nicht auf dem Abonnenten vorhanden sind, ist die Schemaänderung auf dem Verleger erfolgreich, schlägt jedoch auf dem Abonnenten fehl.

• Alle Objekte auf dem Abonnenten, auf die beim Hinzufügen eines Fremdschlüssels verwiesen wird, müssen denselben Namen und Besitzer aufweisen wie das entsprechende Objekt auf dem Verleger.

• Ein explizites Hinzufügen, Löschen oder Ändern von Indizes wird nicht unterstützt. Implizit für Einschränkungen erstellte Indizes (wie z. B. Primärschlüsseleinschränkungen) werden unterstützt.

• Das Ändern oder Löschen von Identitätsspalten, die von der Replikation verwaltet werden, wird nicht unterstützt. Weitere Informationen zur automatischen Verwaltung von Identitätsspalten finden Sie unter Replizieren von Identitätsspalten.

• Schemaänderungen, die nicht deterministische Funktionen einschließen, werden nicht unterstützt, da daraus unterschiedliche Daten auf dem Verleger und dem Abonnenten resultieren können (eine so genannte mangelnde Konvergenz). Wenn Sie beispielsweise folgenden Befehl auf dem Verleger ausgeben: ALTER TABLE SalesOrderDetail ADD OrderDate DATETIME DEFAULT GETDATE(), und der Befehl wird auf den Abonnenten repliziert und ausgeführt, dann unterscheiden sich die Werte. Weitere Informationen zu nicht deterministischen Funktionen finden Sie unter Deterministische und nicht deterministische Funktionen.

• Es wird empfohlen, Einschränkungen explizit zu benennen. Wenn eine Einschränkung nicht explizit benannt wird, generiert SQL Server einen Namen für die Einschränkung, und diese Namen sind auf dem Verleger und jedem Abonnenten unterschiedlich. Dies kann bei der Replikation von Schemaänderungen zu Problemen führen. Wenn Sie z. B. auf dem Verleger eine Spalte löschen und eine abhängige Einschränkung ebenfalls gelöscht wird, wird bei der Replikation versucht, die Einschränkung auf dem Abonnenten zu löschen. Der Löschvorgang auf dem Abonnenten erzeugt jedoch einen Fehler, da die Einschränkung einen anderen Namen hat. Löschen Sie die Einschränkung manuell auf dem Abonnenten, und führen Sie den Merge-Agent anschließend erneut aus, wenn die Synchronisierung aufgrund eines Problems mit dem Einschränkungsnamen einen Fehler erzeugt.

• Wenn eine Tabelle für die Replikation veröffentlicht wird, ist es nicht möglich, eine Spalte in dieser Tabelle in den Datentyp XML zu ändern, wenn bereits eine Veröffentlichungsmomentaufnahme generiert wurde. Um die Spalte zu ändern, müssen Sie die Replikation zuerst entfernen. Weitere Informationen finden Sie unter Entfernen der Replikation.

• Read Committed ist keine unterstützte Isolationsstufe, wenn Sie die DDL-Anweisung für eine veröffentlichte Tabelle ausführen.

Hinzufügen von Spalten

Löschen von Spalten

• Schemaänderungen werden zwar an Abonnenten weitergegeben, auf denen frühere Versionen von SQL Server ausgeführt werden, die DDL-Anweisung sollte jedoch nur Syntax einschließen, die von der Version auf dem Abonnenten unterstützt wird.

  Wenn der Abonnent Daten erneut veröffentlicht, bestehen die einzigen Schemaänderungen im Hinzufügen und Löschen einer Spalte. Nehmen Sie diese Änderungen auf dem Verleger mithilfe von sp_repladdcolumn (Transact-SQL) und sp_repldropcolumn (Transact-SQL) vor und nicht mit der DLL-Syntax ALTER TABLE.

• Schemaänderungen werden auf Nicht-SQL-Abonnenten nicht repliziert.

• Von Nicht-SQL Server-Verlegern werden keine Schemaänderungen weitergegeben.

• Sie können indizierte Sichten, die als Tabellen repliziert werden, nicht ändern. Indizierte Sichten, die als indizierte Sichten repliziert werden, können geändert werden. Durch die Änderung sind sie jedoch keine indizierten Sichten mehr, sondern werden zu herkömmlichen Sichten.

• Wenn die Veröffentlichung mit sofort aktualisierbaren Abonnements oder mit Abonnements mit verzögertem Aktualisieren über eine Warteschlange unterstützt, muss das System in einen inaktiven Status versetzt werden, bevor Schemaänderungen vorgenommen werden: jede Aktivität an der veröffentlichten Tabelle muss auf dem Verleger und den Abonnenten angehalten und ausstehende Datenänderungen müssen an alle Knoten weitergegeben werden. Nach der Weitergabe der Schemaänderungen an alle Knoten können die Aktivitäten an den veröffentlichten Tabellen fortgesetzt werden.

• In früheren Versionen von SQL Server mussten Veröffentlichungen in Peer-zu-Peer-Topologien vor dem Vornehmen von Schemaänderungen in einen inaktiven Status versetzt werden. Ab SQL Server 2008 ist es nicht mehr notwendig, die Veröffentlichung in einen inaktiven Status zu versetzen, außer wie in diesem Abschnitt an anderer Stelle beschrieben.

• Wenn Sie einer Tabelle eine timestamp-Spalte hinzufügen und diese wird einer binary(8)-Spalte zugeordnet, dann wird der Artikel für alle aktiven Abonnements erneut initialisiert.

• Wie Mergereplikation Schemaänderungen behandeln, hängt ab vom Veröffentlichungskompatibilitätsgrad, und ob die Momentaufnahme auf systemeigenen Modus (Standard) oder auf Zeichenmodus eingestellt ist:

  • Zum Replizieren von Schemaänderungen muss die Veröffentlichung mindestens einen Kompatibilitätsgrad von 90RTM aufweisen. Wenn Abonnenten frühere Versionen von SQL Server ausführen oder der Kompatibilitätsgrad niedriger als 90RTM ist, können Sie sp_repladdcolumn (Transact-SQL) und sp_repldropcolumn (Transact-SQL) zum Hinzufügen bzw. Löschen von Spalten verwenden. Allerdings sind diese Prozeduren veraltet.

  • Wenn Sie versuchen, zu einem Artikel eine Spalte mit einem Datentyp hinzuzufügen, der in SQL Server 2008 eingeführt wurde, verhält sich SQL Server wie folgt:

    	100RTM, systemeigene Momentaufnahme	100RTM, Momentaufnahme im Zeichenmodus	Alle übrigen Kompatibilitätsgrade
    hierarchyid	Änderung zulassen	Änderung blockieren	Änderung blockieren
    geography und geometry	Änderung zulassen	Änderung zulassen1	Änderung blockieren
    filestream	Änderung zulassen	Änderung blockieren	Änderung blockieren
    date, time, datetime2 und datetimeoffset	Änderung zulassen	Änderung zulassen1	Änderung blockieren

    1 Abonnenten von SQL Server Compact konvertieren diese Datentypen beim Abonnenten.

  Weitere Informationen zur Veröffentlichungskompatibilität finden Sie im Abschnitt „Kompatibilitätsgrad von Mergeveröffentlichungen“ im Thema Verwenden mehrerer Versionen von SQL Server in einer Replikationstopologie.

• Falls beim Anwenden einer Schemaänderung ein Fehler auftritt, schlägt die Synchronisierung fehl, und das Abonnement muss erneut initialisiert werden. (Ein Fehler kann z. B. auftreten, wenn ein hinzugefügter Fremdschlüssel auf eine Tabelle verweist, die auf dem Abonnenten nicht verfügbar ist.)

• Wird eine Schemaänderung an einer Spalte vorgenommen, die von einem Joinfilter oder parametrisierten Filter betroffen ist, müssen Sie alle Abonnements erneut initialisieren und die Momentaufnahme neu generieren.

• Die Mergereplikation stellt gespeicherte Prozeduren bereit, mit denen Schemaänderungen bei der Problembehandlung ausgelassen werden können. Weitere Informationen finden Sie unter sp_markpendingschemachange (Transact-SQL) und sp_enumeratependingschemachanges (Transact-SQL).