Kommentar
Åtkomst till den här sidan kräver auktorisering. Du kan prova att logga in eller ändra kataloger.
Åtkomst till den här sidan kräver auktorisering. Du kan prova att ändra kataloger.
gäller för:SQL Server
Azure SQL Managed Instance
Replikering stöder en mängd olika schemaändringar för publicerade objekt. När du gör någon av följande schemaändringar för lämpligt publicerat objekt i en Microsoft SQL Server Publisher sprids ändringen som standard till alla SQL Server-prenumeranter:
ALTER TABLE
ALTER TABLE SET LOCK ESCALATIONbör inte användas om schemabytesreplikering är aktiverad och en topologi inkluderar SQL Server 2005 (9.x) eller SQL Server Compact 3.5 Subscribers.ALTER VIEW
ALTER PROCEDURE
ALTER FUNCTION
ALTER TRIGGER
ALTER TRIGGERkan endast användas för data manipulation language (DML)-triggers eftersom data definition language (DDL)-triggers inte kan replikeras.
Important
Du måste göra schemaändringar i tabeller genom att använda Transact-SQL eller SQL Server Management Objects (SMO). När du gör schemaändringar i SQL Server Management Studio försöker Management Studio ta bort och återskapa tabellen. Du kan inte ta bort publicerade objekt, så schemaändringen misslyckas.
För transaktionsreplikering och sammanslagningsreplikering sprids schemaändringar stegvis när Distribution Agent eller Merge Agent körs. För replikering av ögonblicksbilder sprids schemaändringar när en ny ögonblicksbild tillämpas på prenumeranten. I replikering av ögonblicksbilder skickas en ny kopia av schemat till prenumeranten varje gång synkroniseringen sker. Därför sprids alla schemaändringar (inte bara de som nämnts tidigare) till tidigare publicerade objekt automatiskt med varje synkronisering.
Information om hur du lägger till och tar bort artiklar från publikationer finns i Lägga till artiklar i och ta bort artiklar från befintliga publikationer.
Replikera schemaändringar
De schemaändringar som nämndes tidigare replikeras som standard. Information om hur du inaktiverar replikering av schemaändringar finns i Replikera schemaändringar.
Överväganden för schemaändringar
Tänk på följande när du replikerar schemaändringar.
Allmänna överväganden
Schemaändringar omfattas av eventuella begränsningar som införts av Transact-SQL. Till exempel
ALTER TABLEtillåter den dig inte att ändra primärnyckelkolumner.Datatypmappning sker endast för den initiala snapshoten. Schemaändringar mappas inte till tidigare versioner av datatyper. Till exempel, om du använder
ALTER TABLE ADD datetime2 columni SQL Server 2012 (11.x), översätts inte datatypen till nvarchar för SQL Server 2005 (9.x) prenumeranter. I vissa fall blockeras schemaändringar på Publisher.Om du sätter en publikation så att den tillåter spridning av schemaändringar, sprider den schemaändringar oavsett hur du ställer in det relaterade schemaalternativet för en artikel i publikationen. Om du till exempel väljer att inte replikera begränsningar för sekundärnyckel för en tabellartikel, men sedan utfärdar ett
ALTER TABLEkommando som lägger till en sekundärnyckel i tabellen vid Publisher, läggs sekundärnyckeln till i tabellen i Prenumeranten. För att förhindra detta beteende, inaktivera spridningen av schemaändringar innan kommandot utfärdasALTER TABLE.Gör schemaändringar endast hos Publisher, inte hos Subscribers (inklusive återpublicering av Subscribers). Sammanslagningsreplikering förhindrar schemaändringar hos Prenumeranten. Transaktionell replikering förhindrar inte förändringarna, men förändringarna kan göra att replikeringen misslyckas.
Ändringar som sprids till en återpublicerande prenumerant sprids som standard till prenumeranterna.
Om schemaändringen refererar till objekt eller begränsningar som finns på Publisher men inte på Subscriber, lyckas schemaändringen på Publisher men misslyckas på Subscriber.
Alla objekt på Subscriber som du refererar till när du lägger till en främmande nyckel måste ha samma namn och ägare som motsvarande objekt på Publisher.
Att uttryckligen lägga till, ta bort eller ändra index replikeras inte. Du behöver köra varje ändring som involverar ett explicit index på varje replikaset individuellt. Index som skapats implicit för begränsningar (till exempel en primärnyckelbegränsning) stöds.
Att ändra eller ta bort identitetskolumner som replikering hanterar stöds inte. Mer information om automatisk hantering av identitetskolumner finns i Replikera identitetskolumner.
Schemaändringar som inkluderar icke-deterministiska funktioner stöds inte eftersom de kan resultera i att data hos Publisher och Subscriber skiljer sig åt (kallat icke-konvergens). Om du till exempel utfärdar följande kommando i Publisher:
ALTER TABLE SalesOrderDetail ADD OrderDate DATETIME DEFAULT GETDATE()skiljer sig värdena när kommandot replikeras till prenumeranten och körs. Mer information om nondeterministiska funktioner finns i Deterministiska och nondeterministiska funktioner.Ange begränsningar uttryckligen. Om du inte uttryckligen namnger en begränsning genererar SQL Server ett namn för begränsningen, och dessa namn skiljer sig åt på Publisher och varje prenumerant. Denna skillnad kan orsaka problem vid replikering av schemaändringar. Till exempel, om du släpper en kolumn hos Publisher och en beroende begränsning tas bort, försöker replikering ta bort begränsningen hos Subscriber. Borttagningen hos prenumeranten misslyckas eftersom namnet på villkoret är annorlunda. Om synkroniseringen misslyckas på grund av ett problem med namngivning av begränsningar släpper du villkoret manuellt hos Prenumeranten och kör sedan Merge Agent igen.
Om du publicerar en tabell för replikering kan du inte ändra en kolumn i den tabellen till en datatyp av XML om du redan har genererat en publikationssnapshot. För att ändra kolumnen måste du först ta bort replikering.
Read uncommitted är inte en stödd isoleringsnivå när man gör DDL på en publicerad tabell.
Använd inte SET CONTEXT_INFO för att ändra kontexten för transaktioner där schemaändringar utförs mot publicerade objekt.
Lägga till kolumner
För att lägga till en ny kolumn i en tabell och inkludera den kolumnen i en befintlig publikation, exekverar
ALTER TABLE <Table> ADD <Column>. Som standard replikeras kolumnen till alla prenumeranter. Kolumnen måste tillåtaNULLvärden eller innehålla en standardbegränsning. För mer information om hur man lägger till kolumner, se avsnittet "Merge Replication" i denna artikel.För att lägga till en ny kolumn i en tabell och inte inkludera den kolumnen i en befintlig publikation, inaktivera replikering av schemaändringar och sedan köra
ALTER TABLE <Table> ADD <Column>.Om du vill inkludera en befintlig kolumn i en befintlig publikation använder du sp_articlecolumn (Transact-SQL), sp_mergearticlecolumn (Transact-SQL), eller dialogrutan Publikationsegenskaper – <Publikation> .
Mer information finns i Definiera och ändra ett kolumnfilter. Denna åtgärd kräver att prenumerationer initieras om.
Att lägga till en identitetskolumn i en publicerad tabell stöds inte, eftersom det kan leda till icke-konvergens när kolumnen replikeras till prenumeranten. Värdena i identitetskolumnen i Publisher beror på i vilken ordning raderna för den berörda tabellen lagras fysiskt. Raderna kan lagras på olika sätt i Prenumeranten. Därför kan värdet för identitetskolumnen vara annorlunda för samma rader.
Ta bort kolumner
För att ta bort en kolumn från en befintlig publikation och ta bort kolumnen från tabellen hos Publisher, kör
ALTER TABLE <Table> DROP <Column>. Som standard tas kolumnen sedan bort från tabellen på alla prenumeranter.Om du vill släppa en kolumn från en befintlig publikation men behålla kolumnen i tabellen i Publisher använder du dialogrutan sp_articlecolumn (Transact-SQL), sp_mergearticlecolumn (Transact-SQL)eller dialogrutan Publikationsegenskaper – <publikation>.
Mer information finns i Definiera och ändra ett kolumnfilter. Denna åtgärd kräver att man genererar en ny snapshot.
Du kan inte använda kolumnen för att lägga in filterklausuler i någon artikel eller någon publikation i databasen.
När du tar bort en kolumn från en publicerad artikel, överväg eventuella begränsningar, index eller egenskaper hos kolumnen som kan påverka databasen. Ett exempel:
Du kan inte ta bort kolumner som används i en primärnyckel från artiklar i transaktionspublikationer, eftersom replikation använder dem.
Du kan inte ta bort kolumnen
rowguidfrån artiklar i sammanslagna publikationer eller kolumnenmstran_repl_versionfrån artiklar i transaktionspublikationer som stödjer uppdatering av prenumerationer, eftersom replikering använder dem.Indexändringar sprids inte till prenumeranter. Om du lägger in en kolumn i Publisher och ett beroende index tas bort, replikeras inte indexnedgången. Du bör ta bort indexet hos prenumeranten innan du tar bort kolumnen på utgivaren, så att borttagningen av kolumnen lyckas när den replikeras från utgivaren till prenumeranten. Om synkroniseringen misslyckas på grund av ett index i Prenumeranten släpper du indexet manuellt och kör sedan Merge Agent igen.
Namnge begränsningar uttryckligen så att du kan ta bort dem. För mer information, se avsnittet "Allmänna överväganden" tidigare i denna artikel.
Transaktionsreplikering
Schemaändringar sprids till prenumeranter som kör tidigare versioner av SQL Server, men DDL-instruktionen bör endast innehålla syntax som stöds av versionen hos Prenumeranten.
Om prenumeranten återpublicerar data är de enda schemaändringar som stöds att lägga till och ta bort en kolumn. Gör dessa ändringar på Publisher genom att använda sp_repladdcolumn (Transact-SQL) ochsp_repldropcolumn (Transact-SQL) istället för
ALTER TABLEDDL-syntax.Schemaändringar replikeras inte till icke-SQL Server-prenumeranter.
Schemaändringar sprids inte från icke-SQL Server Publishers.
Du kan inte ändra indexerade vyer som replikeras som tabeller. Du kan ändra indexerade vyer som replikeras som indexerade vyer, men att ändra dem gör att de blir vanliga vyer istället för indexerade vyer.
Om publikationen stöder prenumerationer med omedelbar uppdatering eller köad uppdatering ska systemet sättas i viloläge innan schemaändringar görs: stoppa all aktivitet på den publicerade tabellen på utgivaren och prenumeranterna, och överför alla väntande dataändringar till alla noder. Efter att schemaändringarna sprids till alla noder kan aktiviteten återupptas på de publicerade tabellerna.
Om publikationen är i en peer-to-peer-topologi, sätt systemet i viloläge innan du gör schemaändringar. Mer information finns i Quiesce a Replication Topology (Replication Transact-SQL Programming).
Att lägga till en tidsstämpelkolumn i en tabell och mappa tidsstämpeln till
binary(8)gör att artikeln initialiseras om för alla aktiva prenumerationer.
Slå samman replikering
Hur sammanslagningsreplikering hanterar schemaändringar beror på publiceringskompatibilitetsnivån och om ögonblicksbildsläget är inställt på nativt läge (standard) eller teckenläge:
För att replikera schemaändringar, sätt publiceringskompatibilitetsnivån till minst 90RTM. Om prenumeranter använder tidigare versioner av SQL Server eller om kompatibilitetsnivån är under 90RTM, använd sp_repladdcolumn (Transact-SQL) och sp_repldropcolumn (Transact-SQL) för att lägga till och ta bort kolumner. Dessa procedurer är dock inaktuella.
Om du försöker lägga till en kolumn i en befintlig artikel med en datatyp som introducerades i SQL Server 2008 (10.0.x) har SQL Server följande beteende:
100RTM, intern ögonblicksbild 100RTM, ögonblicksbild av tecken Alla andra kompatibilitetsnivåer hierarchyid Tillåt ändring Blockera ändring Blockera ändring geografi och geometri Tillåt ändring Tillåt ändring* Blockera ändring Filestream Tillåt ändring Blockera ändring Blockera ändring datum, tid, datetime2 och datetimeoffset Tillåt ändring Tillåt ändring* Blockera ändring *SQL Server Compact-prenumerationer konverterar dessa datatyper på prenumeranten.
Om ett fel uppstår när du tillämpar en schemaändring (till exempel ett fel som uppstår vid tillägg av en sekundärnyckel som refererar till en tabell som inte är tillgänglig hos prenumeranten), misslyckas synkroniseringen och prenumerationen måste initieras om.
Om en schemaändring görs i en kolumn som ingår i ett kopplingsfilter eller ett parameteriserat filter måste du initiera om alla prenumerationer och återskapa ögonblicksbilden.
Sammanslagningsreplikering innehåller lagrade procedurer för att hoppa över schemaändringar under felsökningen. Mer information finns i sp_markpendingschemachange (Transact-SQL) och sp_enumeratependingschemachanges (Transact-SQL).