Vornehmen von Schemaänderungen in Veröffentlichungsdatenbanken

Gilt für:SQL ServerAzure SQL Managed Instance

Die Replikation unterstützt eine breite Palette von Schemaänderungen an veröffentlichten Objekten. Wenn Sie eine der folgenden Schemaänderungen am entsprechenden veröffentlichten Objekt auf einem Microsoft SQL Server-Verleger vornehmen, wird diese Änderung standardmäßig an alle SQL Server-Abonnenten weitergegeben:

• ALTER TABLE

• ALTER TABLE SETLOCK ESCALATION sollte nicht verwendet werden, wenn die Schemaänderungsreplikation aktiviert ist und eine Topologie SQL Server 2005 (9.x) oder SQL Server Compact 3.5-Abonnenten umfasst.

• ALTER VIEW

• ALTER PROCEDURE

• ALTER FUNCTION

• ALTER TRIGGER

  ALTER TRIGGER kann nur für Datenmanipulationssprache [DML]-Trigger verwendet werden, da Datendefinitionssprache [DDL]-Trigger nicht repliziert werden können.

Bei der Transaktions- und der Mergereplikation werden Schemaänderungen inkrementell weitergegeben, sobald der Verteilungs-Agent oder der Merge-Agent ausgeführt wird. Bei der Momentaufnahmereplikation werden Schemaänderungen übertragen, wenn beim Abonnenten eine neue Momentaufnahme angewendet wird. Außerdem wird bei der Momentaufnahmereplikation eine neue Kopie des Schemas bei jeder Synchronisierung an den Abonnenten gesendet. Deshalb werden alle Schemaänderungen (nicht nur die oben aufgeführten) an bereits veröffentlichten Objekten automatisch bei jeder Synchronisierung weitergegeben.

Informationen zu Überlegungen zum Hinzufügen und Löschen von Artikeln aus Veröffentlichungen finden Sie unter Hinzufügen und Löschen von Artikeln aus vorhandenen Veröffentlichungen.

So replizieren Sie Schemaänderungen

Die oben aufgeführten Schemaänderungen werden standardmäßig repliziert. Informationen zum Deaktivieren der Replikation von Schemaänderungen finden Sie unter Replicate Schema Changes.

Überlegungen zu Schemaänderungen

Beachten Sie beim Replizieren von Schemaänderungen Folgendes:

Allgemeine Überlegungen

• Schemaänderungen unterliegen den Einschränkungen von Transact-SQL. Beispielsweise erlaubt ALTER TABLE nicht, Primärschlüsselspalten zu ALTERn.

• Die Zuordnung der Datentypen wird nur für den initialen Snapshot ausgeführt. Schemaänderungen werden nicht vorherigen Versionen von Datentypen zugeordnet. Wenn beispielsweise in SQL Server 2012 (11.x) die Anweisung ALTER TABLE ADD datetime2 column verwendet wird, wird der Datentyp für Abonnenten von SQL Server 2005 (9.x) nicht in nvarchar übersetzt. In einigen Fällen werden Schemaänderungen auf dem Publisher 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. Wenn Sie z. B. auswählen, keine Fremdschlüsselbeschränkungen für einen Tabellenartikel zu replizieren, dann aber einen ALTER TABLE-Befehl ausführen, mit dem der Tabelle beim Publisher ein Fremdschlüssel hinzugefügt wird, wird der Fremdschlüssel auch der Tabelle beim Subscriber hinzugefügt. Um dies zu verhindern, deaktivieren Sie die Verteilung von Schemaänderungen, bevor Sie den ALTER TABLE Befehl ausgeben.

• Schemaänderungen sollten nur beim Publisher und nicht bei den Abonnenten (einschließlich neu veröffentlichender Abonnenten) vorgenommen 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 denselben Besitzer haben wie die entsprechenden Objekte auf dem Veröffentlicher.

• Das explizite Hinzufügen, Löschen oder Ändern von Indizes wird nicht repliziert, und jede Änderung mit einem expliziten Index muss für jede Replikatgruppe einzeln ausgeführt werden. 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 Deterministic and Nondeterministic Functions.

• 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 davon abhängige Einschränkung ebenfalls gelöscht wird, versucht die Replikation, die Einschränkung auf dem Abonnenten zu löschen. Der Löschvorgang beim Abonnenten schlägt fehl, weil der Constraint einen anderen Namen hat. Wenn die Synchronisierung aufgrund eines Problems mit der Benennung eines Constraints fehlschlägt, löschen Sie das Constraint manuell auf dem Abonnenten, und führen Sie dann den Merge-Agent erneut aus.

• 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.

• READ UNCOMMITTED ist keine unterstützte Isolationsstufe, wenn Sie DDL auf einer veröffentlichten Tabelle ausführen.

• SET CONTEXT_INFO sollte nicht verwendet werden, um den Kontext von Transaktionen zu ändern, bei denen Schemaänderungen für veröffentlichte Objekte ausgeführt werden.

Hinzufügen von Spalten

• Um einer Tabelle eine neue Spalte hinzuzufügen und diese Spalte in eine vorhandene Publikation einzuschließen, führen Sie ALTER TABLE<"Table> ADD <Column"> aus. Die Spalte wird dann standardmäßig auf alle Abonnenten repliziert. Die Spalte muss NULL-Werte zulassen oder eine Standardeinschränkung einschließen. Weitere Informationen zum Hinzufügen von Spalten finden Sie im Abschnitt „Merge-Replikation“ in diesem Thema.

• Wenn Sie einer Tabelle eine neue Spalte hinzufügen und diese Spalte nicht in eine vorhandene Publikation einschließen möchten, deaktivieren Sie die Replikation von Schemaänderungen, und führen Sie dann "Table ADD Column"ALTER TABLE< aus><.>

• Verwenden Sie sp_articlecolumn (Transact-SQL), sp_mergearticlecolumn (Transact-SQL) oder das Dialogfeld Veröffentlichungseigenschaften – <Veröffentlichung>, um eine vorhandene Spalte in eine vorhandene Veröffentlichung einzuschließen.

  Weitere Informationen finden Sie unter Definieren und Ändern eines Spaltenfilters. Dies erfordert, dass Sie Abonnements erneut initialisieren.

• Das Hinzufügen einer Identitätsspalte zu einer veröffentlichten Tabelle wird nicht unterstützt, da ein solcher Vorgang zu Nichtkonvergenz führen kann, wenn die Spalte auf den Abonnenten repliziert wird. Die Werte in der IDENTITY-Spalte beim Publisher hängen von der Reihenfolge ab, in der die Zeilen der betroffenen Tabelle physisch gespeichert werden. Es ist möglich, dass die Zeilen auf dem Abonnenten anders gespeichert sind, sodass der Wert für die Identitätsspalte für dieselben Zeilen unterschiedlich sein kann.

Löschen von Spalten

• Um eine Spalte aus einer vorhandenen Publikation zu löschen und die Spalte aus der Tabelle beim Publisher zu löschen, führen Sie ALTER TABLE<Table> DROP <Column> aus. Standardmäßig wird die Spalte dann bei allen Abonnenten aus der Tabelle gelöscht.

• Verwenden Sie sp_articlecolumn (Transact-SQL), sp_mergearticlecolumn (Transact-SQL) oder das Dialogfeld Veröffentlichungseigenschaften – <Veröffentlichung>, um eine Spalte aus einer vorhandenen Veröffentlichung zu löschen, die Spalte jedoch in der Tabelle auf dem Verleger beizubehalten.

  Weitere Informationen finden Sie unter Definieren und Ändern eines Spaltenfilters. Dies erfordert, dass Sie eine neue Momentaufnahme generieren.

• Die zu löschende Spalte darf nicht in den Filterklauseln eines Artikels einer Veröffentlichung in der Datenbank verwendet werden.

• Beim Löschen einer Spalte aus einem veröffentlichten Artikel sollten Sie alle Einschränkungen, Indizes oder Eigenschaften der Spalte berücksichtigen, die sich auf die Datenbank auswirken können. Zum Beispiel:

  • Sie können keine Spalten, die in einem Primärschlüssel verwendet werden, aus Artikeln in Transaktionsveröffentlichungen löschen, da sie für die Replikation verwendet werden.

  • Sie können die rowguid-Spalte nicht aus Artikeln in Mergeveröffentlichungen oder die mstran_repl_version-Spalte aus Artikeln in Transaktionsveröffentlichungen löschen, die das Aktualisieren von Abonnements unterstützen, da diese Spalten von der Replikation verwendet werden.

  • Indexänderungen werden nicht an die Abonnenten weitergegeben: Wenn Sie beim Publisher eine Spalte löschen und dadurch ein abhängiger Index ebenfalls gelöscht wird, wird die Löschung des Indexes nicht repliziert. Sie sollten den Index beim Abonnenten löschen, bevor Sie die Spalte beim Verleger löschen, damit das Löschen der Spalte erfolgreich ist, wenn diese Änderung vom Verleger an den Abonnenten repliziert wird. Wenn die Synchronisierung aufgrund eines Indexes beim Abonnenten fehlschlägt, löschen Sie den Index manuell, und führen Sie dann den Merge-Agent erneut aus.

  • Constraints sollten explizit benannt werden, damit sie gelöscht werden können. Weitere Informationen finden Sie im Abschnitt "Allgemeine Überlegungen" weiter oben in diesem Thema.

Transaktionsreplikation

• 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. Diese Änderungen sollten auf dem Publisher mithilfe von sp_repladdcolumn (Transact-SQL) und sp_repldropcolumn (Transact-SQL) anstelle der ALTER TABLE DDL-Syntax vorgenommen werden.

• Schemaänderungen werden auf Nicht-SQL-Server-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 Abonnements mit sofortiger Aktualisierung oder Warteschlangenaktualisierungsabonnements unterstützt, muss das System vor dem Vornehmen von Schemaänderungen stillgesetzt werden: Sämtliche Aktivitäten für die veröffentlichte Tabelle müssen beim Publisher und bei den Abonnenten beendet werden, 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.

• Befindet sich die Veröffentlichung in einer Peer-zu-Peer-Topologie, muss das System in einen inaktiven Status versetzt werden, bevor Schemaänderungen vorgenommen werden. Weitere Informationen finden Sie unter Versetzen einer Replikationstopologie in einen inaktiven Status (Replikationsprogrammierung mit Transact-SQL).

• 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.

Mergereplikation

• Wie die Mergereplikation Schemaänderungen behandelt, wird durch den Kompatibilitätsgrad der Veröffentlichung bestimmt und dadurch, ob der Snapshot auf den nativen Modus (Standard) oder den Zeichenmodus festgelegt 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 und 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 (10.0.x) eingeführt wurde, verhält sich SQL Server wie folgt:

    	100RTM, systemeigene Momentaufnahme	100RTM, Zeichenaufnahme	Alle übrigen Kompatibilitätsgrade
    hierarchyid	Änderung zulassen	Änderung blockieren	Änderung blockieren
    geography und geometry	Änderung zulassen	Änderung zulassen*	Änderung blockieren
    Filestream	Änderung zulassen	Änderung blockieren	Änderung blockieren
    date, time, datetime2und datetimeoffset	Änderung zulassen	Änderung zulassen*	Änderung blockieren

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

• 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).

Zugehöriger Inhalt

• ALTER TABLE (Transact-SQL)
• ALTER VIEW (Transact-SQL)
• ALTER PROCEDURE (Transact-SQL)
• ALTER FUNCTION (Transact-SQL)
• ALTER TRIGGER (Transact-SQL)
• Veröffentlichen von Daten und Datenbankobjekten
• Benutzerdefinierte Transaktionsprozeduren neu generieren, um Schemaänderungen zu berücksichtigen