Nehmen Sie Schemaänderungen in Publikationsdatenbanken vor

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 SET LOCK ESCALATIONsollte nicht verwendet werden, wenn die Schema-Change-Replikation aktiviert ist und eine Topologie SQL Server 2005 (9.x) oder SQL Server Compact 3.5 Subscribers umfasst.

  • ALTER VIEW

  • ALTER PROCEDURE

  • ALTER FUNCTION

  • ALTER TRIGGER

    ALTER TRIGGER können nur für Data Manipulation Language (DML)-Trigger verwendet werden, da Data Definition Language (DDL)-Trigger nicht repliziert werden können.

Wichtig

Sie müssen Schemaänderungen an Tabellen vornehmen, indem Sie Transact-SQL oder SQL Server Management Objects (SMO) verwenden. Wenn Sie Schemaänderungen in SQL Server Management Studio vornehmen, versucht Management Studio, die Tabelle zu entfernen und neu zu erstellen. Du kannst veröffentlichte Objekte nicht entfernen, daher schlägt die Schemaänderung fehl.

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änderung weitergegeben, wenn eine neue Momentaufnahme auf den Abonnenten angewendet wird. Außerdem wird bei der Momentaufnahmereplikation eine neue Kopie des Schemas bei jeder Synchronisierung an den Abonnenten gesendet. Daher werden alle Schemaänderungen (nicht nur die zuvor aufgeführten) an zuvor veröffentlichten Objekten automatisch mit jeder Synchronisation 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 zuvor 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. Zum Beispiel erlaubt ALTER TABLE nicht, Primärschlüsselspalten zu ändern.

  • Datentyp-Mapping erfolgt nur für den initialen Snapshot. Schemaänderungen passen nicht zu früheren Versionen von Datentypen. Wenn du zum Beispiel in SQL Server 2012 (11.x) verwendestALTER TABLE ADD datetime2 column, wird der Datentyp für SQL Server 2005 (9.x) Abonnenten nicht zu nvarchar übersetzt. In einigen Fällen werden Schemaänderungen auf dem Publisher blockiert.

  • Wenn Sie eine Publikation so einstellen, dass sie die Weitergabe von Schemaänderungen erlaubt, verbreitet sie Schemaänderungen, unabhängig davon, wie Sie die zugehörige Schema-Option für einen Artikel in der Publikation einstellen. 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 dieses Verhalten zu verhindern, deaktivieren Sie die Weitergabe von Schemaänderungen, bevor Sie den ALTER TABLE Befehl ausgeben.

  • Schemaänderungen nur beim Publisher vornehmen, nicht bei Subscribers (einschließlich der Neuveröffentlichung von Subscribers). Die Mergereplikation verhindert Schemaänderungen auf dem Abonnenten. Transaktionale Replikation verhindert die Änderungen nicht, aber die Änderungen können dazu führen, dass die Replikation fehlschlägt.

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

  • Wenn die Schemaänderung auf Objekte oder Einschränkungen verweist, die zwar im Publisher existieren, aber nicht beim Subscriber, gelingt die Schemaänderung beim Publisher, scheitert jedoch beim Subscriber.

  • Alle Objekte im Subscriber, auf die Sie beim Hinzufügen eines Fremdschlüssels verweisen, müssen denselben Namen und Besitzer haben wie das entsprechende Objekt im Publisher.

  • Das explizite Hinzufügen, Entfernen oder Verändern von Indizes wird nicht repliziert. Du musst jede Änderung, die einen expliziten Index umfasst, für jeden Replikatsatz einzeln ausführen. Implizit für Einschränkungen erstellte Indizes (wie z. B. Primärschlüsseleinschränkungen) werden unterstützt.

  • Das Ändern oder Entfernen von von der Replikation verwalteten IDENTITY-Spalten wird nicht unterstützt. Weitere Informationen zur automatischen Verwaltung von Identitätsspalten finden Sie unter Replizieren von Identitätsspalten.

  • Schemaänderungen, die nichtdeterministische Funktionen enthalten, werden nicht unterstützt, da sie dazu führen können, dass sich Daten im Publisher und Subscriber unterscheiden (als Nicht-Konvergenz bezeichnet). 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.

  • Benennen Sie explizit Beschränkungen. Wenn du eine Einschränkung nicht explizit benennen, generiert SQL Server einen Namen für die Einschränkung, und diese Namen unterscheiden sich beim Publisher und jedem Abonnenten. Dieser Unterschied kann bei der Replikation von Schemaänderungen Probleme verursachen. Wenn Sie beispielsweise auf dem Publisher eine Spalte löschen und dabei eine abhängige Einschränkung gelöscht wird, versucht die Replikation, die Einschränkung auf dem Subscriber zu löschen. Der Drop beim Subscriber scheitert, weil der Name der Einschränkung anders ist. 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 du eine Tabelle zur Replikation publizierst, kannst du eine Spalte in dieser Tabelle nicht in einen Datentyp XML umwandeln, wenn du bereits einen Publikationssnapshot erstellt hast. Um die Spalte zu verändern, muss man zuerst die Replikation entfernen.

  • Read uncommitted ist keine unterstützte Isolationsstufe, wenn DDL für eine veröffentlichte Tabelle ausgeführt wird.

  • Verwenden SET CONTEXT_INFO Sie nicht, um den Kontext von Transaktionen zu verändern, bei denen Schemaänderungen an veröffentlichten Objekten durchgeführt werden.

Spalten hinzufügen

  • Um eine neue Spalte zu einer Tabelle hinzuzufügen und diese Spalte in eine bestehende Publikation aufzunehmen, führe ALTER TABLE <Table> ADD <Column>. Die Spalte wird dann standardmäßig auf alle Abonnenten repliziert. Die Spalte muss NULL-Werte zulassen oder eine Standardwertbeschränkung aufweisen. Weitere Informationen zum Hinzufügen von Spalten finden Sie im Abschnitt "Merge Replication" in diesem Artikel.

  • Um einer Tabelle eine neue Spalte hinzuzufügen und diese Spalte nicht in eine vorhandene Veröffentlichung aufzunehmen, deaktivieren Sie die Replikation von Schemaänderungen und führen Sie dann ALTER TABLE <Table> ADD <Column> 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. Diese Maßnahme erfordert, dass Abonnements neu gestartet werden.

  • Das Hinzufügen einer Identitätsspalte zu einer veröffentlichten Tabelle wird nicht unterstützt, da dies zu einer 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.

Spalten löschen

  • Um eine Spalte aus einer vorhandenen Publikation zu entfernen 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. Diese Aktion erfordert die Erstellung eines neuen Schnappschusses.

  • Du kannst die Spalte nicht verwenden, um die Filterklauseln eines beliebigen Artikels irgendeiner Publikation in der Datenbank einzufügen.

  • Wenn Sie eine Spalte aus einem veröffentlichten Artikel entfernen, berücksichtigen Sie alle Einschränkungen, Indizes oder Eigenschaften der Spalte, die die Datenbank beeinflussen könnten. Zum Beispiel:

    • Sie können keine Spalten, die in einem Primärschlüssel verwendet werden, aus Artikeln in Transaktionspublikationen löschen, da die Replikation diese verwendet.

    • Man kann die Spalte rowguid aus Artikeln in Merge-Publikationen oder die Spalte mstran_repl_version aus Artikeln in transaktionalen Publikationen, die das Aktualisieren von Abonnements unterstützen, nicht entfernen, weil Replikation sie verwendet.

    • Indexänderungen werden nicht an Abonnenten weitergegeben. Wenn du beim Publisher eine Spalte löschst und dadurch ein abhängiger Index gelöscht wird, wird das Löschen 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.

    • Benennen Sie Einschränkungen explizit, damit Sie sie fallen lassen können. Weitere Informationen finden Sie im Abschnitt "Allgemeine Überlegungen" früher in diesem Artikel.

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. Nehmen Sie diese Änderungen am Publisher vor, indem Sie sp_repladdcolumn (Transact-SQL) und sp_repldropcolumn (Transact-SQL)ALTER TABLE anstelle von DDL-Syntax verwenden.

  • Schemaänderungen werden nicht an Abonnenten ohne SQL Server repliziert.

  • Schemaänderungen werden nicht von Nicht-SQL Server Publishern verbreitet.

  • Man kann indexierte Ansichten, die als Tabellen repliziert werden, nicht verändern. Man kann indexierte Ansichten ändern, die als indexierte Ansichten repliziert werden, aber wenn sie geändert werden, werden sie zu regulären Ansichten statt zu indexierten Ansichten.

  • Wenn die Veröffentlichung Abonnements für unmittelbare Aktualisierungen oder Aktualisierungen in der Warteschlange unterstützt, versetzen Sie das System vor dem Vornehmen von Schemaänderungen in einen Ruhezustand: Stoppen Sie alle Aktivitäten auf der veröffentlichten Tabelle beim Publisher und bei den Abonnenten, und übertragen Sie ausstehende Datenänderungen an alle Knoten. Nachdem die Schemaänderungen auf alle Knoten ausgebreitet sind, kann die Aktivität an den veröffentlichten Tabellen wieder aufgenommen werden.

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

  • Das Hinzufügen einer Zeitstempel-Spalte zu einer Tabelle und die Zuordnung des Zeitstempels zu binary(8) führen dazu, dass der Artikel für alle aktiven Abonnements erneut initialisiert wird.

Mergereplikation

  • Wie Merge-Replikation Schemaänderungen handhabt, hängt vom Publikationskompatibilitätsniveau ab und davon, ob der Snapshot auf nativen Modus (Standard) oder Zeichenmodus gesetzt ist:

    • Um Schemaänderungen zu replizieren, stellen Sie die Veröffentlichungskompatibilität auf mindestens 90RTM ein. Wenn Abonnenten frühere Versionen von SQL Server verwenden oder der Kompatibilitätsgrad unter 90RTM liegt, verwenden Sie sp_repladdcolumn (Transact-SQL) und sp_repldropcolumn (Transact-SQL), um Spalten hinzuzufügen und zu entfernen. 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

  • Last updated on