Verander schema's 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 LOCK ESCALATIONMoet niet worden gebruikt als schemawijzigingsreplicatie is ingeschakeld en een topologie SQL Server 2005 (9.x) of SQL Server Compact 3.5 Subscribers bevat.

  • ALTER VIEW

  • ALTER PROCEDURE

  • ALTER FUNCTION

  • ALTER TRIGGER

    ALTER TRIGGER kan alleen worden gebruikt voor data manipulation language (DML) triggers omdat data definition language (DDL) triggers niet kunnen worden gerepliceerd.

Belangrijk

Je moet schemawijzigingen aanbrengen in tabellen door gebruik te maken van Transact-SQL of SQL Server Management Objects (SMO). Wanneer je schemawijzigingen aanbrengt in SQL Server Management Studio, probeert Management Studio de tabel te verwijderen en opnieuw te creëren. Je kunt gepubliceerde objecten niet verwijderen, dus de schemawijziging faalt.

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 die eerder vermeld) aan eerder gepubliceerde objecten automatisch doorgegeven bij 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 eerder genoemde 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. Bijvoorbeeld, ALTER TABLE staat niet toe dat je primaire-sleutelkolommen wijzigt.

  • Datatype-mapping vindt alleen plaats voor de initiële snapshot. Schemawijzigingen worden niet gekoppeld aan eerdere versies van datatypes. Als je bijvoorbeeld SQL Server 2012 (11.x) gebruiktALTER TABLE ADD datetime2 column, vertaalt het datatype zich niet naar nvarchar voor SQL Server 2005 (9.x) abonnees. In sommige gevallen worden schemawijzigingen geblokkeerd op de Publisher.

  • Als je een publicatie zo instelt dat schemawijzigingen kunnen worden verspreid, verspreidt deze schemawijzigingen ongeacht hoe je de bijbehorende schema-optie voor een artikel in de publicatie instelt. 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. Om dit gedrag te voorkomen, schakel de propagatie van schemawijzigingen uit voordat je het ALTER TABLE commando geeft.

  • Maak schemawijzigingen alleen bij de Publisher, niet bij Subscribers (inclusief het herpubliceren van Subscribers). Samenvoegreplicatie voorkomt schemawijzigingen bij de abonnee. Transactionele replicatie voorkomt de veranderingen niet, maar de veranderingen kunnen wel leiden tot mislukking van replicatie.

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

  • Als de schemawijziging verwijst naar objecten of beperkingen die op de Publisher bestaan maar niet op de Subscriber, slaagt de schemawijziging bij de Publisher maar faalt bij de Subscriber.

  • Alle objecten op de Subscriber waar je naar verwijst bij het toevoegen van een vreemde sleutel moeten dezelfde naam en eigenaar hebben als het bijbehorende object op de Publisher.

  • Expliciet toevoegen, verwijderen of aanpassen van indexen wordt niet gerepliceerd. Je moet elke wijziging met een expliciete index voor elke replicaset afzonderlijk uitvoeren. Indexen die impliciet zijn gemaakt voor beperkingen (zoals een primaire-sleutelbeperking) worden ondersteund.

  • Het wijzigen of verwijderen van identiteitskolommen die replicatie beheert, 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 kunnen resulteren in verschillend data bij de Publisher en de abonnee (dit wordt non-convergentie genoemd). 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.

  • Noem beperkingen expliciet. Als je een constraint niet expliciet benoemt, genereert SQL Server een naam voor de constraint, en deze namen verschillen op de Publisher en elke abonnee. Dit verschil kan problemen veroorzaken tijdens het dupliceren van schemawijzigingen. Als je bijvoorbeeld een kolom bij de Publisher laat vallen en een afhankelijke constraint wordt verwijderd, probeert replicatie de constraint bij de Subscriber te verwijderen. De drop bij de abonnee faalt omdat de naam van de beperking 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 je een tabel publiceert voor replicatie, kun je een kolom in die tabel niet aanpassen naar een datatype XML als je al een publicatiesnapshot hebt gegenereerd. Om de kolom te wijzigen, moet je eerst replicatie verwijderen.

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

  • Gebruik het niet SET CONTEXT_INFO om de context van transacties te wijzigen waarbij schemawijzigingen worden uitgevoerd tegen gepubliceerde objecten.

Kolommen toevoegen

  • Om een nieuwe kolom aan een tabel toe te voegen en die kolom op te nemen in een bestaande publicatie, voert u ALTER TABLE <Table> ADD <Column> uit. De kolom wordt standaard gerepliceerd naar alle abonnees. De kolom moet waarden toestaan NULL of een standaardbeperking bevatten. Voor meer informatie over het toevoegen van kolommen, zie de sectie "Merge Replication" in dit artikel.

  • Om een nieuwe kolom aan een tabel toe te voegen en die kolom niet op te nemen in een bestaande publicatie, schakel je de replicatie van schemawijzigingen uit en voer ALTER TABLE <Table> ADD <Column>je vervolgens 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. Deze actie vereist dat abonnementen opnieuw worden geïntialiseerd.

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

Vallende kolommen

  • Om een kolom uit een bestaande publicatie te verwijderen en de kolom uit de tabel bij de Uitgever te verwijderen, voert u ALTER TABLE <Table> 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. Deze actie vereist het genereren van een nieuwe snapshot.

  • Je kunt de kolom niet gebruiken om de filterclausules van een artikel van welke publicatie dan ook in de database te plaatsen.

  • Wanneer je een kolom uit een gepubliceerd artikel verwijdert, overweeg dan eventuele beperkingen, indexen of eigenschappen van de kolom die de database kunnen beïnvloeden. Voorbeeld:

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

    • Je kunt de rowguid kolom niet verwijderen uit artikelen in merge publications, of de mstran_repl_version kolom uit artikelen in transactionele publicaties die het bijwerken van abonnementen ondersteunen, omdat replicatie ze gebruikt.

    • Indexwijzigingen worden niet doorgegeven aan abonnees. Als u op de Publisher een kolom verwijdert en daardoor een afhankelijke index wordt verwijderd, wordt het verwijderen van de index 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.

    • Noem beperkingen expliciet zodat je ze kunt laten vallen. Voor meer informatie, zie de sectie "Algemene Overwegingen" eerder in dit artikel.

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. Maak deze wijzigingen op de Publisher door sp_repladdcolumn (Transact-SQL) en sp_repldropcolumn (Transact-SQL) te gebruiken in plaats van ALTER TABLE DDL-syntaxis.

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

  • Schemawijzigingen worden niet doorgegeven door niet-SQL Server Publishers.

  • Je kunt geïndexeerde weergaven die als tabellen zijn gerepliceerd niet wijzigen. Je kunt geïndexeerde weergaven aanpassen die als geïndexeerde weergaven worden gerepliceerd, maar als je ze verandert, worden ze gewone weergaven in plaats van geïndexeerde weergaven.

  • Als de publicatie abonnementen met directe updates of met updates in de wachtrij ondersteunt, breng het systeem dan tot stilstand voordat je schemawijzigingen aanbrengt: stop alle activiteit op de gepubliceerde tabel op de uitgever en de abonnees, en laat alle in behandeling zijnde gegevenswijzigingen doorvoeren naar alle knooppunten. Nadat de schemawijzigingen naar alle knooppunten zijn doorgegeven, kan de activiteit op de gepubliceerde tabellen worden hervat.

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

  • Het toevoegen van een tijdstempelkolom aan een tabel en het toewijzen van de tijdstempel aan binary(8) zorgt ervoor dat het artikel opnieuw wordt geinitialiseerd voor alle actieve abonnementen.

Replicatie samenvoegen

  • Hoe merge-replicatie schemawijzigingen afhandelt, hangt af van het publicatiecompatibiliteitsniveau en of de snapshot is ingesteld op native modus (standaard) of tekenmodus:

    • Om schemawijzigingen te repliceren, stel je het publicatiecompatibiliteitsniveau in op minstens 90RTM. Als abonnees eerdere versies van SQL Server gebruiken of het compatibiliteitsniveau lager is dan 90RTM, gebruik dan sp_repladdcolumn (Transact-SQL) en sp_repldropcolumn (Transact-SQL) om kolommen toe te voegen en te verwijderen. 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.

Verwante inhoud

  • Laatst bijgewerkt om