Schemawijzigingen aanbrengen in publicatiedatabases

Van toepassing op:SQL ServerAzure SQL Managed Instance

Replicatie ondersteunt een breed scala aan schemawijzigingen voor gepubliceerde objecten. Wanneer u een van de volgende schemawijzigingen aanbrengt op het juiste gepubliceerde object in Microsoft SQL Server Publisher, wordt deze wijziging standaard doorgegeven aan alle SQL Server-abonnees:

  • ALTER TABLE

  • ALTER TABLE SET Vergrendelingsescalatie mag niet worden gebruikt als replicatie van schemawijzigingen is ingeschakeld en de topologie SQL Server 2005 (9.x)- of SQL Server Compact 3.5-abonnees bevat.

  • ALTER VIEW

  • ALTER PROCEDURE

  • ALTER FUNCTION

  • ALTER TRIGGER

    ALTER TRIGGER kan alleen worden gebruikt voor triggers voor gegevensmanipulatietaal [DML], omdat triggers voor gegevensdefinitietaal [DDL] niet kunnen worden gerepliceerd.

Belangrijk

Schemawijzigingen in tabellen moeten worden aangebracht met behulp van Transact-SQL of SQL Server Management Objects (SMO). Wanneer schemawijzigingen worden aangebracht in SQL Server Management Studio, probeert Management Studio de tabel te verwijderen en opnieuw te maken. U kunt gepubliceerde objecten niet verwijderen, waardoor de schemawijziging mislukt.

Voor transactionele replicatie en samenvoegingsreplicatie worden schemawijzigingen stapsgewijs doorgegeven wanneer de Distribution Agent of Merge Agent wordt uitgevoerd. Voor replicatie van momentopnamen worden schemawijzigingen doorgegeven wanneer een nieuwe momentopname wordt toegepast op de abonnee. Bij momentopnamereplicatie wordt telkens wanneer de synchronisatie plaatsvindt een nieuwe kopie van het schema naar de abonnee verzonden. Daarom worden alle schemawijzigingen (niet alleen de hierboven genoemde) naar eerder gepubliceerde objecten automatisch doorgegeven met elke synchronisatie.

Zie Artikelen toevoegen aan en verwijderen uit bestaande publicaties voor meer informatie over het toevoegen en verwijderen van artikelen uit publicaties.

Schemawijzigingen repliceren

De bovenstaande schemawijzigingen worden standaard gerepliceerd. Zie Schemawijzigingen repliceren voor informatie over het uitschakelen van de replicatie van schemawijzigingen.

Overwegingen voor schemawijzigingen

Houd rekening met de volgende overwegingen bij het repliceren van schemawijzigingen.

Algemene overwegingen

  • Schemawijzigingen zijn onderhevig aan eventuele beperkingen die worden opgelegd door Transact-SQL. ALTER TABLE staat u bijvoorbeeld niet toe primaire-sleutelkolommen te wijzigen.

  • Toewijzing van gegevenstypen wordt alleen uitgevoerd voor de eerste momentopname. Schemawijzigingen worden niet gekoppeld aan eerdere versies van datatypen. Als de instructie ALTER TABLE ADD datetime2 column bijvoorbeeld wordt gebruikt in SQL Server 2012 (11.x), wordt het gegevenstype niet vertaald naar nvarchar voor SQL Server 2005 -abonnees (9.x). In sommige gevallen worden schemawijzigingen geblokkeerd op de Publisher.

  • Als een publicatie is ingesteld om schemawijzigingen door te geven, worden schemawijzigingen doorgegeven, ongeacht de manier waarop de gerelateerde schemaoptie is ingesteld voor een artikel in de publicatie. Als u bijvoorbeeld geen beperkingen voor refererende sleutels voor een tabelartikel wilt repliceren, maar vervolgens een ALTER TABLE opdracht geeft waarmee een refererende sleutel wordt toegevoegd aan de tabel in de Publisher, wordt de refererende sleutel toegevoegd aan de tabel bij de abonnee. U kunt dit voorkomen door de doorgifte van schemawijzigingen uit te schakelen voordat u de ALTER TABLE opdracht uitgeeft.

  • Schemawijzigingen moeten alleen worden aangebracht op het Publisher, niet bij abonnees (inclusief het opnieuw publiceren van abonnees). Samenvoegreplicatie voorkomt schemawijzigingen bij de abonnee. Transactionele replicatie voorkomt de wijzigingen niet, maar de wijzigingen kunnen ertoe leiden dat replicatie mislukt.

  • Wijzigingen die worden doorgegeven aan een opnieuw publicerende abonnee, worden standaard doorgegeven aan de abonnees.

  • Als de schemawijziging verwijst naar objecten of beperkingen die aanwezig zijn op de Publisher, maar niet op de abonnee, slaagt de schemawijziging op de Publisher, maar mislukt de abonnee.

  • Alle objecten bij de Abonnee waarnaar wordt verwezen wanneer een externe sleutel wordt toegevoegd, moeten dezelfde naam en eigenaar hebben als het overeenkomstige object bij de Uitgever.

  • Expliciet toevoegen, verwijderen of wijzigen van indexen wordt niet gerepliceerd en eventuele wijzigingen met betrekking tot een expliciete index moeten afzonderlijk worden uitgevoerd op elke replicaset. Indexen die impliciet zijn gemaakt voor beperkingen (zoals een primaire-sleutelbeperking) worden ondersteund.

  • Het wijzigen of verwijderen van identiteitskolommen die worden beheerd door replicatie, wordt niet ondersteund. Zie Identiteitskolommen repliceren voor meer informatie over het automatisch beheer van identiteitskolommen.

  • Schemawijzigingen die niet-deterministische functies bevatten, worden niet ondersteund, omdat ze ertoe kunnen leiden dat gegevens op de Publisher en Abonnee verschillend zijn (aangeduid als niet-convergentie). Als u bijvoorbeeld de volgende opdracht op de Publisher geeft, ALTER TABLE SalesOrderDetail ADD OrderDate DATETIME DEFAULT GETDATE()zijn de waarden anders wanneer de opdracht wordt gerepliceerd naar de abonnee en uitgevoerd. Zie Deterministische en niet-deterministische functies voor meer informatie over niet-deterministische functies.

  • Het wordt aanbevolen dat beperkingen expliciet worden benoemd. Als een beperking niet expliciet een naam heeft, genereert SQL Server een naam voor de beperking en zijn deze namen verschillend op de Publisher en elke abonnee. Dit kan problemen veroorzaken tijdens de replicatie van schemawijzigingen. Als u bijvoorbeeld een kolom neerzet op de Publisher en een afhankelijke beperking wordt verwijderd, probeert replicatie de beperking bij de abonnee te verwijderen. Het verwijderen bij de Abonnee zal mislukken omdat de naam van de constraint anders is. Als de synchronisatie mislukt vanwege een probleem met de naamgeving van een constraint, verwijdert u de constraint handmatig bij de Subscriber en start u de Merge Agent opnieuw.

  • Als een tabel wordt gepubliceerd voor replicatie, is het niet mogelijk om een kolom in die tabel te wijzigen in een gegevenstype XML als er al een momentopname van een publicatie is gegenereerd om de kolom te wijzigen, moet u eerst replicatie verwijderen.

  • 'Read uncommitted' is geen ondersteund isolatieniveau bij het uitvoeren van DDL op een gepubliceerde tabel.

  • SET CONTEXT_INFO mag niet worden gebruikt om de context van transacties te wijzigen waarbij schemawijzigingen worden uitgevoerd op gepubliceerde objecten.

Kolommen toevoegen

  • Als u een nieuwe kolom wilt toevoegen aan een tabel en die kolom wilt opnemen in een bestaande publicatie, voert u ALTER TABLE<De kolom Tabel> TOEVOEGEN uit<>. De kolom wordt standaard gerepliceerd naar alle abonnees. De kolom moet NULL-waarden toestaan of een standaardbeperking bevatten. Zie de sectie 'Replicatie samenvoegen' in dit onderwerp voor meer informatie over het toevoegen van kolommen.

  • Als u een nieuwe kolom wilt toevoegen aan een tabel en deze kolom niet wilt opnemen in een bestaande publicatie, schakelt u de replicatie van schemawijzigingen uit en voert u vervolgens Tabel TOEVOEGEN-kolomALTER TABLE< uit><.>

  • Als u een bestaande kolom in een bestaande publicatie wilt opnemen, gebruikt u sp_articlecolumn (Transact-SQL), sp_mergearticlecolumn (Transact-SQL)of het dialoogvenster Publicatie-eigenschappen - <Publicatie> .

    Zie Een kolomfilter definiëren en wijzigen voor meer informatie. Hiervoor moeten abonnementen opnieuw worden geïnitialiseerd.

  • Het toevoegen van een identiteitskolom aan een gepubliceerde tabel wordt niet ondersteund, omdat dit kan leiden tot niet-convergentie wanneer de kolom wordt gerepliceerd naar de abonnee. De waarden in de identiteitskolom van Publisher zijn afhankelijk van de volgorde waarin de rijen voor de betrokken tabel fysiek worden opgeslagen. De rijen kunnen anders worden opgeslagen bij de abonnee; daarom kan de waarde voor de identiteitskolom verschillen voor dezelfde rijen.

Kolommen verwijderen

  • Als u een kolom uit een bestaande publicatie wilt verwijderen en de kolom uit de tabel in de Publisher wilt verwijderen, voert u ALTER TABLE<Tabel> DROP <Column> uit. De kolom wordt standaard verwijderd uit de tabel bij alle abonnees.

  • Als u een kolom uit een bestaande publicatie wilt verwijderen, maar de kolom in de tabel in de Publisher wilt behouden, gebruikt u sp_articlecolumn (Transact-SQL), sp_mergearticlecolumn (Transact-SQL) of het dialoogvenster Publicatie-eigenschappen - <Publicatie>.

    Zie Een kolomfilter definiëren en wijzigen voor meer informatie. Hiervoor moet een nieuwe momentopname worden gegenereerd.

  • De kolom die moet worden verwijderd, kan niet worden gebruikt in de filterclausules van een artikel van een publicatie in de database.

  • Houd bij het verwijderen van een kolom uit een gepubliceerd artikel rekening met beperkingen, indexen of eigenschappen van de kolom die van invloed kunnen zijn op de database. Voorbeeld:

    • U kunt kolommen die worden gebruikt in een primaire sleutel niet verwijderen uit artikelen in transactionele publicaties, omdat ze worden gebruikt door replicatie.

    • U kunt de kolom rowguid niet verwijderen uit artikelen in samenvoegpublicaties of de kolom mstran_repl_version uit artikelen in transactionele publicaties die ondersteuning bieden voor het bijwerken van abonnementen, omdat ze worden gebruikt door replicatie.

    • Indexwijzigingen worden niet doorgegeven aan abonnees: als u een kolom neerzet op de Publisher en een afhankelijke index wordt verwijderd, wordt de indexuitval niet gerepliceerd. U moet de index op de Subscriber verwijderen voordat u de kolom op de Publisher verwijdert, zodat het verwijderen van de kolom slaagt wanneer dit van de Publisher naar de Subscriber wordt gerepliceerd. Als de synchronisatie mislukt vanwege een index bij de abonnee, zet u de index handmatig neer en voert u de Merge Agent opnieuw uit.

    • Constraints moeten expliciet worden benoemd om ze te kunnen verwijderen. Zie de sectie Algemene overwegingen eerder in dit onderwerp voor meer informatie.

Transactionele replicatie

  • Schemawijzigingen worden doorgegeven aan abonnees met eerdere versies van SQL Server, maar de DDL-instructie mag alleen syntaxis bevatten die wordt ondersteund door de versie van de abonnee.

    Als de abonnee gegevens opnieuw publiceert, zijn de enige ondersteunde schemawijzigingen het toevoegen en verwijderen van een kolom. Deze wijzigingen moeten worden aangebracht in de Publisher met behulp van sp_repladdcolumn (Transact-SQL) en sp_repldropcolumn (Transact-SQL) in plaats ALTER TABLE van DDL-syntaxis.

  • Schemawijzigingen worden niet gerepliceerd naar niet-SQL Server abonnees.

  • Schemawijzigingen worden niet doorgegeven vanuit niet-SQL Server Uitgevers.

  • U kunt geïndexeerde weergaven die als tabellen worden gerepliceerd, niet wijzigen. Geïndexeerde weergaven die als geïndexeerde weergaven worden gerepliceerd, kunnen worden gewijzigd, maar als u ze wijzigt, worden ze normale weergaven in plaats van geïndexeerde weergaven.

  • Als de publicatie abonnementen voor onmiddellijk bijwerken of bijwerken in de wachtrij ondersteunt, moet het systeem in een rusttoestand worden gebracht voordat u schemawijzigingen aanbrengt: alle activiteit op de gepubliceerde tabel moet worden gestopt bij de Publisher en de Subscribers, en openstaande gegevenswijzigingen moeten naar alle knooppunten worden doorgegeven. Nadat de schemawijzigingen zijn doorgegeven aan alle knooppunten, kan de activiteit op de gepubliceerde tabellen worden hervat.

  • Als de publicatie zich in een peer-to-peer-topologie bevindt, moet het systeem worden stilgezet voordat u schemawijzigingen aanbrengt. Zie Een replicatietopologie onderbreken (Programmeren van replicatie in Transact-SQL) voor meer informatie.

  • Door een tijdstempelkolom toe te voegen aan een tabel en de tijdstempel toe te voegen aan binary(8), wordt het artikel opnieuw geïnitialiseerd voor alle actieve abonnementen.

Replicatie samenvoegen

  • Hoe samenvoegreplicatie schemawijzigingen verwerkt, wordt bepaald door het compatibiliteitsniveau van de publicatie en of de momentopname is ingesteld op de systeemeigen modus (standaard) of tekenmodus:

    • Als u schemawijzigingen wilt repliceren, moet het compatibiliteitsniveau van de publicatie ten minste 90RTM zijn. Als abonnees eerdere versies van SQL Server uitvoeren of als het compatibiliteitsniveau kleiner is dan 90RTM, kunt u sp_repladdcolumn (Transact-SQL) en sp_repldropcolumn (Transact-SQL) gebruiken om kolommen toe te voegen en neer te zetten. Deze procedures worden echter afgeschaft.

    • Als u probeert een kolom toe te voegen aan een bestaand artikel met een gegevenstype dat is geïntroduceerd in SQL Server 2008 (10.0.x), heeft SQL Server het volgende gedrag:

      100RTM, systeemeigen momentopname 100RTM, momentopname van teken Alle andere compatibiliteitsniveaus
      hierarchyid Wijziging toestaan Wijziging blokkeren Wijziging blokkeren
      geografie en geometrie Wijziging toestaan Wijziging toestaan* Wijziging blokkeren
      Filestream Wijziging toestaan Wijziging blokkeren Wijziging blokkeren
      datum, tijd, datum/tijd2 en datetimeoffset Wijziging toestaan Wijziging toestaan* Wijziging blokkeren

      *SQL Server Compact-abonnees zetten deze gegevenstypen om bij de abonnee.

  • Als er een fout optreedt bij het toepassen van een schemawijziging (zoals een fout als gevolg van het toevoegen van een refererende sleutel die verwijst naar een tabel die niet beschikbaar is bij de abonnee), mislukt de synchronisatie en moet het abonnement opnieuw worden geïnitialiseerd.

  • Als er een schemawijziging wordt aangebracht in een kolom die betrokken is bij een joinfilter of een geparameteriseerd filter, moet u alle abonnementen opnieuw initialiseren en de momentopname opnieuw genereren.

  • Merge-replicatie biedt opgeslagen procedures waarmee schemawijzigingen tijdens probleemoplossing kunnen worden overgeslagen. Zie sp_markpendingschemachange (Transact-SQL) en sp_enumeratependingschemachanges (Transact-SQL) voor meer informatie.