Vornehmen von Schemaänderungen in Publikationsdatenbanken

Die Replikation unterstützt eine vielzahl von Schemaänderungen an veröffentlichten Objekten. Wenn Sie eine der folgenden Schemaänderungen für das entsprechende veröffentlichte Objekt in einem Microsoft SQL Server Publisher vornehmen, wird diese Änderung standardmäßig an alle SQL Server-Abonnenten weitergegeben:

• ALTER TABLE

• ALTER TABLE SET LOCK ESCALATION sollte nicht verwendet werden, wenn die Schemaänderungsreplikation aktiviert ist und eine Topologie SQL Server 2005- oder SQL Server Compact 3.5-Abonnenten.ALTER VIEW enthält

• ALTER PROCEDURE

• ALTER-FUNKTION

• ALTER TRIGGER

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

Bei der Transaktionsreplikation und der Zusammenführungsreplikation werden Schemaänderungen inkrementell weitergegeben, wenn der Verteilungs-Agent oder Seriendruck-Agent ausgeführt wird. Bei der Momentaufnahmereplikation werden Schemaänderungen weitergegeben, wenn beim Abonnenten eine neue Momentaufnahme angewendet wird. Bei der Momentaufnahmereplikation wird bei jeder Synchronisierung eine neue Kopie des Schemas an den Abonnenten gesendet. Daher werden alle Schemaänderungen (nicht nur die oben aufgeführten) an zuvor veröffentlichte Objekte automatisch mit jeder Synchronisierung verteilt.

Informationen zum Hinzufügen und Entfernen von Artikeln aus Publikationen finden Sie unter Hinzufügen von Artikeln zu und Ablegen von Artikeln aus vorhandenen Publikationen.

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 Replizieren von Schemaänderungen.

Überlegungen zu Schemaänderungen

Beachten Sie beim Replizieren von Schemaänderungen die folgenden Überlegungen.

Allgemeine Überlegungen

• Schemaänderungen unterliegen jeglichen Einschränkungen, die von Transact-SQL auferlegt werden. Beispielsweise lässt ALTER TABLE nicht zu, dass Sie Primärschlüsselspalten ÄNDERN können.

• Die Datentypzuordnung wird nur für die anfängliche Momentaufnahme ausgeführt. Schemaänderungen werden nicht früheren Versionen von Datentypen zugeordnet. Wenn die Anweisung ALTER TABLE ADD datetime2 column beispielsweise in SQL Server 2012 verwendet wird, wird der Datentyp nicht für SQL Server 2005-Abonnenten übersetzt nvarchar . In einigen Fällen werden Schemaänderungen für Publisher blockiert.

• Wenn eine Publikation so festgelegt ist, dass die Verteilung von Schemaänderungen zulässig ist, werden Schemaänderungen unabhängig davon weitergegeben, wie die zugehörige Schemaoption für einen Artikel in der Publikation festgelegt wird. Wenn Sie z. B. keine Fremdschlüsseleinschränkungen für einen Tabellenartikel replizieren, aber dann einen ALTER TABLE-Befehl ausstellen, der der Tabelle im Publisher einen Fremdschlüssel hinzufügt, wird der Fremdschlüssel der Tabelle am Abonnenten hinzugefügt. Um dies zu verhindern, deaktivieren Sie die Verteilung von Schemaänderungen, bevor Sie den BEFEHL ALTER TABLE ausgeben.

• Schemaänderungen sollten nur bei Publisher vorgenommen werden, nicht bei Abonnenten (einschließlich erneuter Veröffentlichung von Abonnenten). Die Seriendruckreplikation verhindert Schemaänderungen am Abonnenten. Die Transaktionsreplikation verhindert nicht die Änderungen, aber die Änderungen können dazu führen, dass die Replikation fehlschlägt.

• Änderungen, die an einen erneuten Veröffentlichungsabonnent weitergegeben werden, werden standardmäßig an seine Abonnenten weitergegeben.

• Wenn das Schema Objekte oder Einschränkungen ändert, die im Publisher vorhanden sind, aber nicht für den Abonnenten, wird die Schemaänderung im Publisher erfolgreich ausgeführt, schlägt jedoch für den Abonnenten fehl.

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

• Das explizite Hinzufügen, Ablegen oder Ändern von Indizes wird nicht unterstützt. Indizes, die implizit für Einschränkungen (z. B. eine Primärschlüsseleinschränkung) erstellt wurden, werden unterstützt.

• Das Ändern oder Ablegen 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 enthalten, werden nicht unterstützt, da sie dazu führen können, dass Daten bei Publisher und Abonnenten unterschiedlich sind (als Nichtkonvergenz bezeichnet). Wenn Sie beispielsweise den folgenden Befehl in Publisher ausgeben: ALTER TABLE SalesOrderDetail ADD OrderDate DATETIME DEFAULT GETDATE()die Werte unterscheiden sich, wenn der Befehl in den Abonnenten repliziert und ausgeführt wird. Weitere Informationen zu nicht deterministischen Funktionen finden Sie unter Deterministische und nichtdeterministische Funktionen.

• Es wird empfohlen, Einschränkungen explizit benannt zu werden. Wenn eine Einschränkung nicht explizit benannt ist, generiert SQL Server einen Namen für die Einschränkung, und diese Namen unterscheiden sich in Publisher und jedem Abonnenten. Dies kann während der Replikation von Schemaänderungen zu Problemen führen. Wenn Sie beispielsweise eine Spalte im Publisher löschen und eine abhängige Einschränkung entfernt wird, versucht die Replikation, die Einschränkung beim Abonnenten zu löschen. Die Übertragung beim Abonnenten schlägt fehl, da der Name der Einschränkung abweicht. Wenn die Synchronisierung aufgrund eines Einschränkungsbenennungsproblems fehlschlägt, entfernen Sie die Einschränkung beim Abonnenten manuell, und führen Sie dann den Zusammenführungs-Agent erneut aus.

• Wenn eine Tabelle für die Replikation veröffentlicht wird, kann eine Spalte in dieser Tabelle nicht in einen XML-Datentyp geändert werden, wenn bereits eine Publikationsmomentaufnahme generiert wurde. Um die Spalte zu ändern, müssen Sie zuerst die Replikation entfernen.

• "Nicht auskommentiert lesen" ist keine unterstützte Isolationsstufe, wenn DDL für eine veröffentlichte Tabelle ausgeführt wird.

• 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. Standardmäßig wird die Spalte dann auf alle Abonnenten repliziert. Die Spalte muss NULL-Werte zulassen oder eine Standardeinschränkung enthalten. Weitere Informationen zum Hinzufügen von Spalten finden Sie im Abschnitt "Zusammenführungsreplikation" in diesem Thema.

• Um einer Tabelle eine neue Spalte hinzuzufügen und diese Spalte nicht in eine vorhandene Publikation einzuschließen, deaktivieren Sie die Replikation von Schemaänderungen, und führen Sie dann ALTER TABLE Table <> ADD <Column> aus.

• Um eine vorhandene Spalte in eine vorhandene Publikation einzuschließen, verwenden Sie sp_articlecolumn (Transact-SQL), sp_mergearticlecolumn (Transact-SQL) oder das Dialogfeld " Publikationseigenschaften - <Publikation> ".

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

• Das Hinzufügen einer Identitätsspalte zu einer veröffentlichten Tabelle wird nicht empfohlen, da dies zu Konvergenzproblemen führen kann, wenn die Spalte an den Abonnenten repliziert wird. Die Werte in der Identitätsspalte in Publisher hängen von der Reihenfolge ab, in der die Zeilen für die betroffene Tabelle physisch gespeichert werden. Die Zeilen können beim Abonnenten unterschiedlich gespeichert werden; daher kann der Wert für die Identitätsspalte für dieselben Zeilen unterschiedlich sein.

Entfernen von Spalten

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

• Verwenden Sie sp_articlecolumn (Transact-SQL), sp_mergearticlecolumn (Transact-SQL) oder das Dialogfeld "Publikationseigenschaften - <Publikation> ", um eine Spalte aus einer vorhandenen Publikation abzulegen, aber die Spalte in der Tabelle im Publisher beizubehalten.

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

• Die Spalte, die verworfen werden soll, kann in den Filterklauseln eines Artikels einer beliebigen Publikation in der Datenbank nicht verwendet werden.

• Berücksichtigen Sie beim Ablegen einer Spalte aus einem veröffentlichten Artikel alle Einschränkungen, Indizes oder Eigenschaften der Spalte, die sich auf die Datenbank auswirken könnten. Beispiel:

  • Spalten, die in einem Primärschlüssel verwendet werden, können nicht aus Artikeln in transaktionalen Publikationen gelöscht werden, da sie von der Replikation verwendet werden.

  • Sie können die Spalte rowguid nicht aus Artikeln in Zusammenführungsveröffentlichungen oder die Spalte mstran_repl_version aus Artikeln in Transaktionsveröffentlichungen entfernen, die das Aktualisieren von Abonnements unterstützen, da sie von der Replikation verwendet werden.

  • Indexänderungen werden nicht an Abonnenten weitergegeben: Wenn Sie eine Spalte im Publisher ablegen und ein abhängiger Index gelöscht wird, wird der Indexablage nicht repliziert. Sie sollten den Index beim Abonnenten ablegen, bevor Sie die Spalte im Publisher ablegen, damit die Spaltenablage erfolgreich ausgeführt wird, wenn sie vom Herausgeber in den Abonnenten repliziert wird. Wenn die Synchronisierung aufgrund eines Indexes am Abonnenten fehlschlägt, legen Sie den Index manuell ab, und führen Sie dann den Seriendruck-Agent erneut aus.

  • Einschränkungen sollten explizit benannt werden, um ein Entfernen zu ermöglichen. Weitere Informationen finden Sie weiter oben in diesem Thema im Abschnitt "Allgemeine Überlegungen".

Transaktionsreplikation

• Schemaänderungen werden an Abonnenten weitergegeben, die frühere Versionen von SQL Server ausführen, aber die DDL-Anweisung sollte nur syntax enthalten, die von der Version am Abonnenten unterstützt wird.

  Wenn der Abonnent Daten erneut veröffentlicht, sind die einzigen unterstützten Schemaänderungen das Hinzufügen und Entfernen 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 nicht an Empfänger ohne SQL Server repliziert.

• Schemaänderungen werden nicht von Nicht-SQL Server-Herausgebern weitergegeben.

• Indizierte Ansichten, die als Tabellen repliziert werden, können nicht geändert werden. Indizierte Ansichten, die als indizierte Ansichten repliziert werden, können geändert werden, aber durch das Ändern dieser Ansichten werden sie zu regulären Ansichten und nicht zu indizierten Ansichten.

• Wenn die Publikation sofortige Aktualisierungs- oder Abonnements mit Warteschlangenaktualisierung unterstützt, muss das System ruhiggestellt werden, bevor Schemaänderungen vorgenommen werden: Alle Aktivitäten in der veröffentlichten Tabelle müssen beim Publisher und den Subscriber angehalten werden, und ausstehende Datenänderungen müssen an alle Knoten weitergegeben werden. Nachdem die Schemaänderungen an alle Knoten weitergegeben wurden, kann die Aktivität in den veröffentlichten Tabellen fortgesetzt werden.

• Wenn sich die Publikation in einer Peer-to-Peer-Topologie befindet, muss das System still gestellt werden, 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 Zeitstempelspalte zu einer Tabelle und das Zuordnen des Zeitstempels zu binary(8) bewirkt, dass der Artikel für alle aktiven Abonnements neu initialisiert wird.

Mergereplikation

• Die Verarbeitung von Schemaänderungen bei der Zusammenführungsreplikation hängt von der Kompatibilitätsebene der Publikation und davon ab, ob der Schnappschuss im nativen Modus (Standard) oder Zeichenmodus festgelegt ist.

  • Um Schemaänderungen zu replizieren, muss die Kompatibilitätsebene der Publikation mindestens 90RTM sein. Wenn Abonnenten frühere Versionen von SQL Server ausführen oder die Kompatibilitätsebene kleiner als 90RTM ist, können Sie sp_repladdcolumn (Transact-SQL) und sp_repldropcolumn (Transact-SQL) zum Hinzufügen und Ablegen von Spalten verwenden. Diese Verfahren sind jedoch veraltet.

  • Wenn Sie versuchen, einem vorhandenen Artikel eine Spalte mit einem Datentyp hinzuzufügen, der in SQL Server 2008 eingeführt wurde, weist SQL Server das folgende Verhalten auf:

    	100RTM, systemeigene Momentaufnahme	100RTM, Charakter-Snapshot	Alle anderen Kompatibilitätsstufen
    hierarchyid	Änderung zulassen	Blockänderung	Blockänderung
    geography und geometry	Änderung zulassen	Änderung1 zulassen	Blockänderung
    filestream	Änderung zulassen	Blockänderung	Änderung blockieren
    date, time, datetime2und datetimeoffset	Änderung zulassen	Änderung1 zulassen	Blockänderung

    ¹ SQL Server Compact-Abonnenten konvertieren diese Datentypen beim Abonnenten.

• Wenn beim Anwenden einer Schemaänderung ein Fehler auftritt (z. B. ein Fehler beim Hinzufügen eines Fremdschlüssels, der auf eine Tabelle verweist, die beim Abonnenten nicht verfügbar ist), schlägt die Synchronisierung fehl, und das Abonnement muss erneut initialisiert werden.

• Wenn für eine Spalte, die an einem Verknüpfungsfilter oder parametrisierten Filter beteiligt ist, eine Schemaänderung vorgenommen wird, müssen Sie alle Abonnements neu initialisieren und die Momentaufnahme neu generieren.

• Die Zusammenführungsreplikation stellt gespeicherte Prozeduren bereit, um Schemaänderungen während der Problembehandlung zu überspringen. Weitere Informationen finden Sie unter sp_markpendingschemachange (Transact-SQL) und sp_enumeratependingschemachanges (Transact-SQL).

Siehe auch

ALTER TABLE (Transact-SQL)
ALTER VIEW (Transact-SQL)
ALTER PROCEDURE (Transact-SQL)
FUNKTION ÄNDERN (Transact-SQL)
ALTER TRIGGER (Transact-SQL)
Veröffentlichen von Daten- und Datenbankobjekten
Neuerieren von benutzerdefinierten Transaktionsprozeduren, um Schemaänderungen widerzuspiegeln