SQL Server Replikering: Komplett guide för DBA [2026]

SQL Server Replikering är en uppsättning tekniker för att kopiera och distribuera data och databasobjekt från en databas till en annan, och sedan synkronisera mellan databaser för att upprätthålla konsekvens. Den här funktionen gör att du kan skapa och underhålla flera kopior av dina data på olika servrar och platser, vilket säkerställer datatillgänglighet och tillförlitlighet.

1.2 Syfte och fördelar med replikering

SQL Server replikering tillgodoser flera kritiska affärsbehov och ger betydande fördelar för databashantering och datadistribution:

Datadistribution över olika platser: Replikering gör det möjligt att dela data mellan regionala kontor eller globala platser, vilket förbättrar den operativa effektiviteten genom att säkerställa lokal åtkomst till nödvändig data. Detta minskar nätverkslatensen och ger bättre prestanda för geografiskt distribuerade användare.
Hög tillgänglighet och katastrofåterställning: Genom att underhålla repliker av kritisk data över flera servrar ger replikering redundans som skyddar mot hårdvarufel och katastrofer. Vid primärserverfel kan replikerade kopior fungera som reservkällor, vilket minimerar driftstopp och dataförlust.
Lastbalansering och skalbarhet: Replikering distribuerar läsoperationer över flera servrar, vilket förhindrar att en enskild server blir en flaskhals. Denna metod förbättrar systemprestanda och gör att din infrastruktur kan skalas horisontellt i takt med att data och användarnas krav växer.
Realtidsrapportering och analys: Att avlasta rapporterings- och analysfrågor till replikerade servrar minskar belastningen på produktionsdatabaser. Användare kan köra komplexa analytiska frågor mot data i nära realtid utan att påverka operativa system, vilket säkerställer både prestanda och dataaktualitet.
Dataintegration och konsolidering: Replikering underlättar sammanslagning av data från olika källor till en enda konsoliderad vy. Detta är särskilt värdefullt för organisationer med flera filialer som behöver aggregera data på huvudkontoret, eller för att skapa centraliserade datalager från distribuerade operativa system.

2. SQL Server Replikeringsarkitektur och komponenter

SQL Server Replikeringsarkitekturen består av flera sammankopplade komponenter som arbetar tillsammans för att distribuera och synkronisera data över din databasinfrastruktur. Det här avsnittet utforskar kärnkomponenterna, inklusive utgivare, distributörer, prenumeranter, publikationer, artiklar, prenumerationer och de agenter som koordinerar dataflödet mellan dem:

Utgivare: En förläggare är en SQL Server exempel att hosten eller flera databaser som innehåller data som ska replikeras. Den fungerar som den auktoritativa källan i replikeringstopologin.
Distributör: En distributör är en SQL Server instans som hanterar dataflödet mellan utgivare och prenumeranter. Distributörsinstansen hosts distributionsdatabasen, som lagrar replikeringsmetadata och transaktioner.
Abonnent: En prenumerant är en SQL Server instans som tar emot och lagrar replikerad data från utgivare. En enskild prenumerantinstans kan host flera prenumerantdatabaser, som var och en tar emot data från olika publikationer.
Publicerad: En publikation definierar vilka data som ska replikeras och hur de ska distribueras till prenumeranter. Den grupperar relaterade artiklar och fastställer den replikeringsmetod som gäller för alla ingående objekt.
Artikel: En artikel är den grundläggande byggstenen för replikering och representerar ett enskilt databasobjekt som kommer att distribueras till prenumeranter.
Prenumeration: En prenumeration upprättar relationen mellan en publikation och en prenumerant och definierar hur och när data levereras till måldatabasen.
ombud: Agenter är specialiserade processer som utför det faktiska arbetet med att flytta och synkronisera data mellan replikeringskomponenter.

3. Typer av SQL Server replikation

SQL Server erbjuder flera replikeringstyper, var och en utformad för specifika datadistributionsscenarier och affärskrav. Att förstå egenskaperna, fördelarna och begränsningarna för varje typ är avgörande för att välja rätt metod för din miljö.

3.1 Replikering av ögonblicksbilder

Snapshot-replikering tar en ögonblicksbild av data som ska publiceras vid en specifik tidpunkt och distribuerar sedan den exakta och kompletta kopian till prenumeranterna. Den övervakar inte efterföljande ändringar förrän nästa ögonblicksbild genereras. Snapshot-replikering är den enklaste formen av replikering, vilket gör den lämplig för scenarier där data ändras sällan eller där det är acceptabelt att ha något föråldrad data.

Vanliga användningsområden inkluderar distribution av referensdata som prislistor eller växelkurser som uppdateras regelbundet, tillhandahållande av initiala datamängder för datalager och scenarier där en fullständig datauppdatering är att föredra framför att spåra enskilda ändringar. Till exempel kan ett företag använda ögonblicksbildsreplikering för att distribuera uppdaterade produktkataloger till filialkontor en gång dagligen.

De främsta fördelarna med snapshot-replikering är dess enkelhet, låga underhållskrav och möjligheten att replikera data utan primärnycklar. Det har dock betydande nackdelar, inklusive hög påverkan när snapshots genereras på grund av tabelllås, hög latens mellan uppdateringar och ineffektivitet för stora datamängder eller data som ofta ändras. Alla ändringar som görs hos prenumeranter är lästa.ost när nästa ögonblicksbild tillämpas.

3.2 Transaktionell replikering

Transaktionsreplikering levererar ändringar från utgivaren till prenumeranter i nästan realtid genom att replikera enskilda transaktioner allt eftersom de inträffar. Den börjar med en initial ögonblicksbild för att fastställa baslinjen, övervakar sedan kontinuerligt transaktionsloggen för ändringar i publicerade artiklar och levererar dem stegvis till prenumeranter.

Transaktionsreplikering är idealisk för server-till-server-scenarier som kräver hög dataflödeshastighet och låg latens. Vanliga användningsområden inkluderar förbättrad skalbarhet och tillgänglighet genom att avlasta läsoperationer till prenumerantservrar, stödja datalagring och rapportering med data i nära realtid, integrera data från flera platser till en central plats och avlasta batchbehandling till dedikerade servrar. Till exempel kan en e-handelsplattform använda transaktionsreplikering för att underhålla synkroniserade lagerdata över regionala databaser.

Fördelarna med transaktionell replikering inkluderar dataleverans med låg latens, hög dataflödeshastighet för stora transaktionsvolymer och möjligheten att göra icke-replikerade modifieringar hos prenumeranter. Nackdelarna inkluderar större komplexitet jämfört med snapshot-replikering, kravet på primärnycklar på replikerade tabeller och risken för att replikeringen bryts om konflikter uppstår, såsom primärnycklar som överträds hos prenumeranter.

3.3 Sammanfoga replikering

Sammanfogningsreplikering är specifikt utformad för miljöer där prenumeranter behöver arbeta offline eller med intermittent anslutning, och sedan synkronisera ändringar när anslutningen är tillgänglig. Denna replikeringstyp gör att data kan ändras oberoende av varandra hos både utgivare och prenumeranter, spåra ändringar med hjälp av utlösare och metadatatabeller, och automatiskt sammanfoga ändringar under synkronisering.

Sammanslagningsreplikering är utformad för mobila applikationer och distribuerade servermiljöer där autonoma förändringar sker. Användningsfall inkluderar säljautomation där mobila användare arbetar offline och synkroniserar senare, kassasystem som fungerar oberoende och konsoliderar data regelbundet, och distribuerade applikationer där flera platser behöver uppdatera delade data. Till exempel kan en detaljhandelskedja använda sammanslagningsreplikering så att varje butik kan hantera lokalt lager samtidigt som den synkroniserar med det centrala lagersystemet.

Fördelarna med sammanslagningsreplikering inkluderar stöd för autonoma prenumeranter som kan göra ändringar, tolerans för intermittent nätverksanslutning och flexibel konfliktlösning. Nackdelarna inkluderar större komplexitet i installation och underhåll, prestandakostnader från spårning av metadata och utlösare, tillägg av unika identifierarkolumner i tabeller och risk för konflikter som kräver hantering och lösning.

3.4 Peer-to-peer-replikering

Peer-to-peer-replikering bygger på transaktionell replikering och gör det möjligt för flera serverinstanser (tre eller fler noder) att fungera som likabehandlingspartners, där varje nod fungerar som både utgivare och prenumerant samtidigt. I denna topologi har alla noder identiska kopior av data och kan hantera både läs- och skrivoperationer, vilket ger en verkligt distribuerad multimaster-miljö.

Peer-to-peer-replikering är lämplig för applikationer som kräver utskalning av läsoperationer och hög tillgänglighet. Användningsfall inkluderar webbapplikationer som distribuerar katalogfrågor över flera noder samtidigt som de upprätthåller konsekventa data, scenarier som kräver underhåll eller uppgraderingar utan driftstopp genom att noder tas offline individuellt, och globala applikationer med datacenter i olika regioner. Till exempel kan en global programvarusupportorganisation använda peer-to-peer-replikering över kontor i olika tidszoner så att varje plats har lokal åtkomst till aktuell data.

Fördelarna med peer-to-peer-replikering inkluderar förbättrad läsprestanda genom utskalning, högre tillgänglighet med flera aktiva noder och datakonsistens i nära realtid. Nackdelarna inkluderar kravet på Enterprise Edition, komplexiteten i att hantera topologier med flera noder, behovet av identiska scheman och data över alla noder och risken för konflikter när skrivåtgärder inte är korrekt partitionerade.

3.5 Dubbelriktad replikering

Dubbelriktad replikering är en specifik transaktionell replikeringstopologi som är utformad specifikt för tvåservermiljöer där båda servrarna behöver utbyta ändringar med varandra. Varje server publicerar data och prenumererar på samma data från den andra servern, vilket skapar ett enkelt tvåvägssynkroniseringsflöde. Även om peer-to-peer-replikering också kan stödja två noder, ger dubbelriktad replikering förbättrad prestanda för just detta scenario.

Dubbelriktad replikering är lämplig för scenarier som kräver två aktiva servrar med synkroniserade data, till exempel aktiv-aktiv-konfigurationer för hög tillgänglighet eller geografiskt distribuerade applikationer där varje plats behöver lokal skrivåtkomst. Topologin kräver noggrann applikationsdesign för att partitionera datauppdateringar och förhindra konflikter.

Fördelarna inkluderar optimerad prestanda för scenarier med två servrar, enklare konfiguration jämfört med peer-to-peer-replikering, synkronisering i nära realtid och lägre omkostnader än sammanslagningsreplikering. Nackdelarna inkluderar begränsningen till exakt två servrar, avsaknaden av inbyggd konfliktlösning som kräver noggrann applikationsdesign och behovet av lämpliga partitioneringsstrategier för att förhindra konflikter.

3.6 Uppdaterbara prenumerationer

Uppdaterbara prenumerationer utökar transaktionell replikering så att prenumeranter kan göra tillfälliga ändringar i replikerad data som sedan sprids tillbaka till utgivaren och till andra prenumeranter. Till skillnad från sammanslagningsreplikering eller peer-to-peer-topologier som är utformade för frekventa dubbelriktade uppdateringar, är uppdateringsbara prenumerationer avsedda för scenarier där det primära dataflödet är enkelriktat (utgivare till prenumeranter) men prenumeranter ibland behöver göra korrigeringar eller uppdateringar.

Uppdaterbara prenumerationer är lämpliga för scenarier där most Uppdateringar sker hos utgivaren, men enstaka uppdateringar hos prenumeranter är nödvändiga, till exempel fältkontor som primärt läser data men behöver göra lokala korrigeringar eller uppdateringar. Topologin kräver noggrann planering för att minimera konflikter och säkerställa datakonsekvens.

De främsta fördelarna inkluderar att tillåta begränsade skrivoperationer hos prenumeranter samtidigt som transaktionell replikering bibehåller prestandaegenskaperna. Nackdelar inkluderar ökad komplexitet, risk för konflikter som kräver lösning, prestandaöverbelastning från tvåfas-commit-protokollet i omedelbart uppdateringsläge och kravet att alla replikerade tabeller har primärnycklar.

3.7 Jämförelse av olika typer av replikationer

Replikeringstyp	Uppdaterings tid	Antal utgivare	Riktning	Använd scenarier
Snapshot	Tidpunkt	1	One Direction (Utgivare → Prenumeranter)	Referensdata som sällan ändras (prislistor, växelkurser)
transaktions~~POS=TRUNC	Nära realtid	1	One Direction (Utgivare → Prenumeranter)	Scenarier med hög genomströmning (e-handelsinventering, datalager, rapportering)
Sammanfoga	Periodisk (när den är ansluten)	1	Dubbelriktad (Utgivare ↔ Prenumeranter)	Mobila applikationer, offline-arbetare (automatisering av säljkåren, fälttjänster)
Peer-to-Peer	Nära realtid	Flera (3 eller fler)	Dubbelriktad (alla noder)	Globala implementeringar av flera datacenter (kontor över hela världen med lokal läs- och skrivåtkomst)
Dubbelriktad	Nära realtid	2	Dubbelriktad (båda servrarna)	Två aktiva datacenterkonfigurationer (hög tillgänglighet på två platser)
Uppdaterbara prenumerationer	Nära realtid	1	Främst i en riktning (engångsvis omvända uppdateringar)	Filialkontor som huvudsakligen läser men ibland uppdaterar (lokala korrigeringar)

4. Inställning SQL Server replikation

4.1 Förutsättningar och krav

4.1.1 Programvarukrav

SQL Server replikering kräver kompatibel SQL Server versioner över alla deltagare i topologin. Distributörsversionen måste vara lika med eller högre än utgivarens version, och prenumeranten kan befinna sig inom två versioner av utgivaren. Till exempel, en SQL Server 2016-utgivaren kan replikera till SQL Server 2012, 2014, 2016, 2017 eller 2019 prenumeranter.

4.1.2 Tillståndskrav

Konfigurering av replikering kräver specifika behörigheter på varje nivå. Medlemmar i den fasta serverrollen sysadmin kan utföra alla konfigurationsuppgifter för replikering. För mer detaljerade behörigheter måste användare vara medlemmar i databasrollen db_owner för utgivares- och prenumerantdatabaser.

4.2 Steg 1: Konfigurera distribution

Att konfigurera distribution är det första steget i installationen SQL Server replikering.

För att konfigurera distribution med hjälp av SQL Server Management Studio:

Anslut till SQL Server exempel i SQL Server ManagementStudio.
I Objektutforskaren högerklickar du på replikation mapp och välj Konfigurera distribution.
I guiden Konfigurera distribution klickar du på Nästa på välkomstsidan.
På Distributör sidan, välj ett av följande alternativ baserat på dina topologikrav:
- Lokal distributörVälj “Servernamn kommer att fungera som sin egen distributör; SQL Server "kommer att skapa en distributionsdatabas och logg" om du vill att utgivaren och distributören ska köras på samma instans (den aktuella instansen). Den här konfigurationen är enklare att konfigurera och lämplig för mindre miljöer eller när nätverkslatens mellan utgivare och distributör skulle orsaka problem.
- FjärrdistributörVälj "Använd följande server som distributör" och klicka på Lägg till för att ange en fjärrdistributörsserver om du vill avlasta distributionsbearbetningen till en separat instans. Den här konfigurationen förbättrar prestandan när replikeringsvolymerna är höga genom att fördela arbetsbelastningen över flera servrar. Du måste ange fjärrdistributörens namn och ange ett lösenord som utgivaren ska använda för att ansluta till distributören.
Klicka Nästa för att ange platsen för ögonblicksbildsmappen. Använd en UNC-sökväg (t.ex. \\servernamn\resurs\mapp) snarare än en lokal sökväg för att säkerställa åtkomst över hela nätverket.
På Distributionsdatabas sidan, acceptera standardnamnet för distributionsdatabasen (vanligtvis ”distribution”) eller ange ett anpassat namn och konfigurera sedan platser för data och loggfiler.
På Utgivare Kontrollera att den aktuella servern är aktiverad som utgivare. Om du konfigurerar den aktuella servern som distributör kan du lägga till ytterligare utgivare som kommer att använda den här distributören.
Granska guidens åtgärder och klicka på Finish för att konfigurera distributionen.

4.3 Steg 2: Skapa publikation

Efter att distributionen har konfigurerats är nästa steg att skapa en publikation som definierar vilka dataobjekt som ska replikeras till prenumeranter.

Att skapa en publikation med hjälp av SQL Server Management Studio:

I Objektutforskaren, expandera replikation mapp.
Högerklicka Lokala publikationer och välj Ny publikation.
Guiden för nya publikationertarts; klicka Nästa på välkomstsidan.
Välj den databas du vill publicera från Publikationsdatabas sida. Detta aktiverar automatiskt publicering på den valda databasen.
På Publikationstyp sidan, välj replikeringstyp: Snapshot publicering, Transaktionell publicering, Peer-to-Peer-publikation, eller Slå samman publikation.
På Artiklar sida, expandera Bord nod och välj tabeller som ska inkluderas som artiklar.
Utöka valfritt Lagrada procedurer, Visningar, eller andra objekttyper för att inkludera ytterligare artiklar.
Klicka Artikelegenskaper för att konfigurera filtrering eller andra artikelspecifika inställningar.
På Filtrera tabellrader sida, lägg till radfilter om det behövs.
På Snapshot-agent sidan, välj när du vill skapa ögonblicksbilden: omedelbart, vid en specifik tidpunkt eller enligt ett schema.
På Agentsäkerhet På sidan anger du säkerhetskontexten för Snapshot Agent.
På Guidens åtgärder sida, välj Skapa publikationen.
Ange ett publikationsnamn och klicka på Finish.

4.4 Steg 3: Skapa prenumeration

Efter att du har skapat en publikation är nästa steg att skapa prenumerationer som kopplar publikationen till prenumerantdatabaser.

Prenumerationer kan vara push-prenumerationer (hanteras av distributören) eller pull-prenumerationer (hanteras av prenumeranten). De viktigaste skillnaderna är var du skapar prenumerationen och vilken agentplats du väljer, vilket avgör prenumerationens åtgärd (push eller pull).

För push-prenumeration (hanteras av distributören):

På utgivare server, expandera replikation -> Lokala publikationer.
Högerklicka på publikationen och välj Nya prenumerationer.

För pull-prenumeration (hanteras av prenumeranten):

På abonnent server, expandera replikation, Högerklicka Lokala prenumerationer, och välj Nya prenumerationer.
På Offentliggörande sida, klicka Hitta SQL Server Publisher och anslut till utgivarens server.

Vanliga guidesteg för båda prenumerationstyperna:

I guiden Ny prenumeration klickar du på Nästa på välkomstsidan.
Välj publikationen och klicka på Nästa.
På Distributionsagentens plats sidan, välj agentens plats:
- Push-prenumerationVälj ”Kör alla agenter hos distributören” – distributören skickar ändringarna till prenumeranterna.
- Hämta prenumerationVälj ”Kör varje agent hos dess prenumerant” – varje prenumerant hämtar ändringar från distributören.
På abonnenter sidan, välj befintliga prenumerantservrar eller klicka på Lägg Subscriber att lägga till nya.
För varje prenumerant väljer du måldatabasen eller skapar en ny databas. Obs: Prenumerationsdatabasen måste vara en annan än utgivardatabasen, även om samma databas används. SQL Server exempel.
På Distributionsagentens säkerhet Klicka på egenskapsknappen för varje prenumeration på sidan för att konfigurera säkerhetskontexten.
På Synkroniseringsschema sidan, välj kontinuerlig synkronisering eller schemalagd synkronisering.
På Initiera prenumerationer sida, välj Omedelbart att initiera under guidens slutförande eller Vid första synkroniseringen.
Granska guidens åtgärder och klicka Finish.

5. Övervakning och hantering SQL Server replikation

5.1 Övervaka replikering med Replication Monitor

Så här startar du Replikeringsövervakaren:

In SQL Server Management Studio, expandera replikation i Objektutforskaren.
Högerklicka replikation och välj Starta replikeringsövervakaren.
Om inga utgivare är registrerade klickar du på Lägg till utgivare i den vänstra rutan.
Välja Lägg till SQL Server Publisher och anslut till utgivarens server.
Utgivaren visas i den vänstra rutan med expanderbara noder för publikationer och prenumerationer.

5.2 Prestandaövervakning

5.2.1 Övervakningslatens

Replikeringsfördröjning är tidsfördröjningen mellan en ändring som sker hos utgivaren och att ändringen tillämpas hos prenumeranten. Övervaka fördröjningen för att säkerställa att dataaktualitet uppfyller affärskraven.

Använd Replikeringsövervakaren för att visa latensmätvärden på fliken Alla prenumerationer. Kolumnen Latens visar genomsnittlig latens i sekunder. För transaktionell replikering tillhandahåller spårningstoken exakta latensmätningar genom att infoga markörtransaktioner som spåras genom replikeringspipelinen.

Så här använder du spårningstokens:

I Replikeringsövervakaren väljer du en transaktionell publikation.
Klicka på Spårmarkörer fliken.
Klicka Infoga spårningsmedel att injicera en markörtransaktion.
Övervaka token när den färdas från utgivare till distributör till prenumerant.
Visa den tid det tar för varje segment att identifiera flaskhalsar.

5.2.2 Övervakningsdataflöde

Dataflödet mäter volymen data som replikeras över tid, vanligtvis uttryckt som transaktioner per sekund eller kommandon per sekund. Övervaka dataflödet för att säkerställa att replikeringen kan hålla jämna steg med utgivarens aktivitet.

Medan Replication Monitor visar grundläggande synkroniseringsstatus, syns inte leveranshastighet och detaljerade dataflödesmätvärden i det grafiska gränssnittet. Använd T-SQL-frågor mot distributionsdatabasen för att övervaka dataflödet:

USE distribution
GO

-- Direct join to avoid subquery
SELECT TOP 20
    h.time AS [Time],
    a.name AS [Agent Name],
    h.runstatus AS [Status],
    h.delivered_transactions AS [Delivered Transactions],
    h.delivered_commands AS [Delivered Commands],
    h.delivery_rate AS [Delivery Rate (commands/sec)],
    h.delivery_latency AS [Delivery Latency (ms)],
    h.comments AS [Comments]
FROM MSdistribution_history h
JOIN MSdistribution_agents a ON h.agent_id = a.id
WHERE a.name LIKE '%MyPublication2%'
AND h.runstatus IN (2, 3, 4, 6)
ORDER BY h.time DESC
GO

Statuskoder: 1 = Start, 2 = Pågår, 3 = Lyckades, 4 = Inaktiv, 5 = Försök igen, 6 = Misslyckas. Jämför leveranshastigheten med utgivarens transaktionshastigheter för att identifiera situationer där replikeringen halkar efter. Prestandaräknare i Windows Performance Monitor tillhandahålla ytterligare dataflödesmått för varje replikeringsagent.

5.2.3 Identifiera flaskhalsar

Flaskhalsar vid replikering kan uppstå på flera punkter i topologin. Hos utgivaren kan för lång genereringstid för ögonblicksbilder eller fördröjningar i Log Reader Agent tyda på resursbegränsningar. Övervaka CPU, minne och disk-I/O på utgivaren under replikeringsaktiviteter.

Kontrollera om det finns ackumulerade transaktioner i distributionsdatabasen hos distributören. Ett stort antal odistribuerade kommandon indikerar att distributören inte kan hålla jämna steg med leveransen. Övervaka distributörens serverresurser och överväg att använda en dedikerad fjärrdistributör för scenarier med hög volym.

Hos prenumeranten kan långsam tillämpning av ändringar bero på otillräckliga resurser, saknade index eller begränsningar som saktar ner infogningsåtgärder. Övervaka prenumerantens resursutnyttjande och frågeprestanda när Distribution Agent körs. Bandbreddsbegränsningar i nätverket mellan komponenter orsakar också flaskhalsar, särskilt för stora datavolymer.

5.3 Hantera replikeringsagenter

5.3.1 Start och stoppagenter

Till stareller stoppa en replikeringsagent:

In SQL Server Management Studio, expandera SQL Server Recensioner -> Lediga jobb.
Leta reda på replikeringsagentjobbet (namnen inkluderar vanligtvis publikations- och prenumerantinformation).
Högerklicka på jobbet och välj Start-jobb or Stoppa jobbet.

5.3.2 Konfigurera agentprofiler

Agentprofiler innehåller parameteruppsättningar som styr agentens beteende. SQL Server tillhandahåller standardprofiler som är optimerade för vanliga scenarier, och du kan skapa anpassade profiler för specifika behov.

Så här ändrar du agentprofiler:

I Objektutforskaren, expandera replikation.
Högerklicka replikation och välj Distributörsegenskaper.
Klicka på Profilstandarder knapp.
Välj en agenttyp (Ögonblicksbild, Loggläsare, Distribution eller Sammanfogning) från rullgardinsmenyn.
Välj en profil och klicka Våra Bostäder för att visa parametervärden.
Klicka Ny profil för att skapa en anpassad profil baserad på en befintlig.
Ändra parametrar efter behov och klicka på OK.

Tillämpa en profil på en agent genom att redigera prenumerationsegenskaperna och välja önskad profil i rullgardinsmenyn Agentprofil.

5.3.3 Agentparametrar och inställningar

Agentparametrar finjusterar prestanda och beteende. Viktiga parametrar för Distribution Agent inkluderar CommitBatchSize (antal transaktioner som tillämpas per commit), CommitBatchThreshold (antal kommandon före commit), SubscriptionStreams (parallella anslutningar för snabbare leverans) och QueryTimeout (timeout för kommandon).

För Log Reader Agent inkluderar viktiga parametrar ReadBatchSize (transaktioner som läses per skanning), ReadBatchThreshold (kommandon före leverans) och PollingInterval (fördröjning mellan loggskanningar). Justera dessa parametrar baserat på transaktionsvolym och latenskrav.

5.4 Att tänka på vid säkerhetskopiering och återställning

Säkerhetskopiering av databaser som ingår i replikering kräver särskilda överväganden. För publiceringsdatabasen är regelbundna fullständiga säkerhetskopior och säkerhetskopior av transaktionsloggar avgörande. Markera säkerhetskopian för replikeringsstöd genom att använda alternativet MED REPLIKERING när du säkerhetskopierar databaser i transaktionell replikering. Säkerhetskopiera distributionsdatabasen regelbundet för att skydda replikeringskonfigurationen.

När du återställer en utgivardatabas till samma server med samma namn, använd alternativet WITH KEEP_REPLICATION för att bevara replikeringstillståndet. Det här alternativet säkerställer att transaktioner som ännu inte bearbetats av loggläsaragenten förblir markerade för replikering, vilket gör att replikeringen kan fortsätta automatiskt utan att prenumerationer måste ominitieras.

I katastrofåterställningsscenarier där säkerhetskopior inte är tillgängliga, är skadade eller databasfilerna är skadade kan specialiserade återställningsverktyg vara nödvändiga. DataNumen SQL Recovery kan extrahera data från skadade eller oåtkomliga MDF- och NDF-filer, vilket ger en sista utväg när standardåterställningsprocedurer misslyckas.

För mer information om SQL Server säkerhetskopiering, se vår omfattande guide.

6. Vanliga frågor (FAQ)

F: Vad är skillnaden mellan ögonblicksbild och transaktionell replikering?

A: Snapshot-replikering tar en komplett kopia av data vid en specifik tidpunkt och tillämpar den på prenumeranten, lämplig för sällan ändrade data. Transaktionsreplikeringtarts med en initial ögonblicksbild och replikerar sedan kontinuerligt enskilda transaktioner allt eftersom de inträffar, vilket ger synkronisering i nära realtid för ofta föränderliga data.

F: Kan jag replikera mellan olika SQL Server versioner?

A: Ja, SQL Server replikering stöder versionskompatibilitet inom ett begränsat intervall. Distributörens version måste vara lika med eller högre än utgivarens version, och prenumeranten kan befinna sig inom två versioner av utgivaren. Till exempel, om utgivaren är SQL Server 2016 kan prenumeranten vara SQL Server 2012, 2014, 2016, 2017 eller 2019.

F: Hur hanterar jag konflikter i sammanslagningsreplikering?

A: Sammanfogningsreplikering erbjuder inbyggda mekanismer för konfliktdetektering och konfliktlösning. Du kan konfigurera konfliktlösare på artikelnivå, välja mellan inbyggda lösare eller implementera anpassade konfliktlösare. Konflikter löses vanligtvis med hjälp av prioritetsbaserade eller tidsstämpelbaserade metoder, med möjlighet att logga konflikter för manuell granskning.

F: Vilka är prestandapåverkan av replikering?

A: Replikering påverkar prestandan på flera sätt: utgivaren upplever belastning från att spåra ändringar och generera ögonblicksbilder, distributören använder resurser för att lagra och vidarebefordra transaktioner, och nätverksbandbredd förbrukas under dataöverföring. Effekten varierar beroende på replikeringstyp, där ögonblicksbildsreplikering orsakar periodiska högpresterande bursts och transaktionsreplikering upprätthåller en mer konsekvent men kontinuerlig belastning.

F: Hur säkrar jag min replikeringstopologi?

A: Säkra din replikeringstopologi genom att implementera flera bästa metoder: använd Windows-autentisering eller stark SQL Server autentisering, kryptera anslutningar med TLS, säkra ögonblicksbildsmappen med lämpliga NTFS behörigheter, konfigurera publikationsåtkomstlistan (PAL) för att kontrollera åtkomst, använda separata tjänstkonton med minimala behörigheter som krävs för varje replikeringsagent och regelbundet granska säkerhetsinställningar för replikering.

F: Kan jag replikera till Azure SQL Database?

A: Ja, du kan replikera till Azure SQL Database med hjälp av transaktionell replikering med en lokal databas. SQL Server eller Azure SQL Managed Instance som utgivare och distributör. Azure SQL Database kan fungera som prenumerant men inte som utgivare eller distributör. Sammanfogningsreplikering och peer-to-peer-replikering stöds inte med Azure SQL Database.

F: Hur övervakar jag replikeringsfördröjning?

A: Övervaka replikeringsfördröjning med Replikeringsövervakaren i SQL Server Management Studio, som visar latensstatistik för varje prenumeration. Du kan också fråga distributionsdatabastabeller som MSdistribution_history och MSrepl_commands, använda prestandaräknare specifika för replikeringsagenter eller konfigurera aviseringar baserade på latensgränser för att proaktivt upptäcka och åtgärda synkroniseringsförseningar.

F: Vad händer när en prenumerant är offline?

A: När en prenumerant är offline beror beteendet på replikeringstypen. Vid transaktionell replikering ackumuleras transaktioner i distributionsdatabasen tills prenumeranten är online igen, sedan återupptas synkroniseringen. Vid sammanslagningsreplikering spåras ändringar på båda sidor och sammanfogas när anslutningen återställs. Inställningen för kvarhållningsperioden avgör hur länge data sparas innan de måste ominitieras.

F: Hur lägger jag till nya artiklar i en befintlig publikation?

A: För att lägga till nya artiklar i en befintlig publikation, använd SQL Server Management Studio för att ändra publikationsegenskaperna och välja ytterligare objekt, eller använd den lagrade proceduren sp_addarticle. Efter att du har lagt till artiklar, generera en ny ögonblicksbild och ominitiera alla prenumerationer för att säkerställa att prenumeranterna får de nya artiklarna. Vissa ändringar kan kräva ominitiering av prenumerationen beroende på publikationsinställningarna.

F: Hur tar jag bort replikering från en databas?

A: Ta bort replikering från en databas genom att först ta bort alla prenumerationer med hjälp av sp_dropsubscription, sedan ta bort publikationen med sp_droppublication och slutligen inaktivera publicering på databasen med hjälp av sp_replicationdboption. Om servern är en distributör, inaktivera distribution med hjälp av sp_dropdistributor. Säkerhetskopiera alltid databaser innan du tar bort replikeringskonfigurationen.

F: Vad är skillnaden mellan SQL Server Replikering och AlwaysOn-tillgänglighetsgrupper?

A: Replikering är en datadistributions- och integrationslösning som fungerar på objektnivå, medan Alltid på tillgänglighetsgrupper är en lösning med hög tillgänglighet och katastrofåterställning som fungerar på databasnivå.

7. Slutsats

SQL Server Replikering tillhandahåller ett robust ramverk för att distribuera och synkronisera data mellan flera databaser och platser. Tekniken stöder olika scenarier genom olika replikeringstyper.

Att välja rätt replikeringsstrategi beror på dina specifika krav. Tänk på frekvensen av dataändringar, latenskrav, om prenumeranter behöver göra uppdateringar, nätverksegenskaper och prenumeranternas behov av autonomi. Snapshot-replikering fungerar bäst för sällan ändrade referensdata där latens inte är kritisk. Transaktionsreplikering passar scenarier med hög volym som kräver låg latens och främst enkelriktat dataflöde.

Välj sammanslagningsreplikering när prenumeranter behöver autonom drift med offline-funktioner och dubbelriktad synkronisering. Implementera peer-to-peer-replikering för lastbalansering av läsoperationer över flera aktiva noder med nära realtidskonsekvens. Överväg hybridmetoder som kombinerar flera replikeringstyper för komplexa scenarier med olika krav.

Referensprojekt

Om författaren

Yuan Sheng är en senior databasadministratör (DBA) med över 10 års erfarenhet av SQL Server miljöer och hantering av företagsdatabaser. Han har framgångsrikt löst hundratals scenarier för databasåterställning inom finansiella tjänster, hälso- och sjukvård och tillverkningsorganisationer.

Yuan specialiserar sig på SQL Server Databasåterställning, lösningar för hög tillgänglighet och prestandaoptimering. Hans omfattande praktiska erfarenhet inkluderar hantering av databaser på flera terabyte, implementering av Always On Availability Groups och utveckling av automatiserade säkerhetskopierings- och återställningsstrategier för verksamhetskritiska affärssystem.

Genom sin tekniska expertis och praktiska tillvägagångssätt fokuserar Yuan på att skapa omfattande guider som hjälper databasadministratörer och IT-proffs att lösa komplexa problem. SQL Server utmaningar effektivt. Han håller sig uppdaterad med det senaste SQL Server utgåvor och Microsofts ständigt föränderliga databastekniker, och testar regelbundet återställningsscenarier för att säkerställa att hans rekommendationer återspeglar bästa praxis i verkligheten.

Har frågor om SQL Server återställning eller behöver du ytterligare vägledning om felsökning av databasen? Yuan välkomnar feedback och förslag för att förbättra dessa tekniska resurser.