SQL Server Replikering: Komplet guide til DBA [2026]

SQL Server Replikering er et sæt teknologier til kopiering og distribution af data og databaseobjekter fra én database til en anden, og derefter synkronisering mellem databaser for at opretholde konsistens. Denne funktion giver dig mulighed for at oprette og vedligeholde flere kopier af dine data på tværs af forskellige servere og placeringer, hvilket sikrer datatilgængelighed og pålidelighed.

1.2 Formål og fordele ved replikering

SQL Server replikering opfylder flere kritiske forretningsbehov og giver betydelige fordele for databasestyring og datadistribution:

Datafordeling på tværs af lokationer: Replikering gør det muligt at dele data på tværs af regionale kontorer eller globale lokationer, hvilket forbedrer den operationelle effektivitet ved at sikre lokal adgang til nødvendige data. Dette reducerer netværkslatens og giver bedre ydeevne for geografisk distribuerede brugere.
High Availability og katastrofeberedskab: Ved at vedligeholde replikaer af kritiske data på tværs af flere servere, giver replikering redundans, der beskytter mod hardwarefejl og katastrofer. I tilfælde af primær serverfejl kan replikerede kopier fungere som reservekilder, hvilket minimerer nedetid og datatab.
Load Balancing og skalerbarhed: Replikering distribuerer læseoperationer på tværs af flere servere, hvilket forhindrer, at en enkelt server bliver en flaskehals. Denne tilgang forbedrer systemets ydeevne og giver din infrastruktur mulighed for at skalere horisontalt, efterhånden som data og brugerkrav vokser.
Realtidsrapportering og analyse: Flytning af rapporterings- og analyseforespørgsler til replikerede servere reducerer belastningen på produktionsdatabaser. Brugere kan køre komplekse analytiske forespørgsler mod næsten realtidsdata uden at påvirke driftssystemerne, hvilket sikrer både ydeevne og dataaktualitet.
Dataintegration og konsolidering: Replikering muliggør sammenlægning af data fra forskellige kilder til én samlet visning. Dette er især værdifuldt for organisationer med flere filialer, der har brug for at aggregere data på hovedkontoret, eller for at oprette centraliserede datalagre fra distribuerede driftssystemer.

2. SQL Server Replikeringsarkitektur og komponenter

SQL Server Replikationsarkitekturen består af flere sammenkoblede komponenter, der arbejder sammen om at distribuere og synkronisere data på tværs af din databaseinfrastruktur. Dette afsnit udforsker kernekomponenterne, herunder udgivere, distributører, abonnenter, publikationer, artikler, abonnementer og de agenter, der koordinerer dataflowet mellem dem:

Udgiver: En udgiver er en SQL Server eksempel at hosten eller flere databaser, der indeholder data, der skal replikeres. Den fungerer som den autoritative kilde i replikationstopologien.
Distributør: En distributør er en SQL Server instans, der administrerer datastrømmen mellem udgivere og abonnenter. Distributørinstansen hosts distributionsdatabasen, som lagrer replikeringsmetadata og -transaktioner.
abonnent: En abonnent er en SQL Server instans, der modtager og lagrer replikerede data fra udgivere. En enkelt abonnentinstans kan host flere abonnentdatabaser, der hver modtager data fra forskellige publikationer.
Udgivet: En publikation definerer, hvilke data der skal replikeres, og hvordan de skal distribueres til abonnenter. Den grupperer relaterede artikler og fastlægger den replikeringsmetodik, der gælder for alle indeholdte objekter.
Artikel: En artikel er den grundlæggende byggesten i replikering og repræsenterer et individuelt databaseobjekt, der distribueres til abonnenter.
Abonnement: Et abonnement etablerer forholdet mellem en publikation og en abonnent og definerer, hvordan og hvornår data leveres til destinationsdatabasen.
befuldmægtigede: Agenter er specialiserede processer, der udfører det faktiske arbejde med at flytte og synkronisere data mellem replikationskomponenter.

3. Typer af SQL Server Replication

SQL Server tilbyder adskillige replikeringstyper, der hver især er designet til specifikke datadistributionsscenarier og forretningskrav. Det er vigtigt at forstå hver types egenskaber, fordele og begrænsninger for at vælge den rigtige tilgang til dit miljø.

3.1 Replikering af snapshot

Snapshot-replikering tager et snapshot af de data, der skal offentliggøres på et bestemt tidspunkt, og distribuerer derefter den nøjagtige komplette kopi til abonnenterne. Den overvåger ikke efterfølgende ændringer, før det næste snapshot genereres. Snapshot-replikering er den enkleste form for replikering, hvilket gør den velegnet til scenarier, hvor data ændres sjældent, eller hvor det er acceptabelt at have let forældede data.

Almindelige anvendelsesscenarier omfatter distribution af referencedata som prislister eller valutakurser, der opdateres periodisk, levering af indledende datasæt til datalagre og scenarier, hvor en komplet dataopdatering er at foretrække frem for at spore individuelle ændringer. For eksempel kan en virksomhed bruge snapshot-replikering til at distribuere opdaterede produktkataloger til filialer én gang dagligt.

De vigtigste fordele ved snapshot-replikering er dens enkelhed, lave vedligeholdelseskrav og evnen til at replikere data uden primære nøgler. Det har dog betydelige ulemper, herunder stor indflydelse, når snapshots genereres på grund af tabellåse, høj latenstid mellem opdateringer og ineffektivitet for store datasæt eller ofte skiftende data. Eventuelle ændringer foretaget hos abonnenter er ...ost når det næste snapshot anvendes.

3.2 Transaktionel replikering

Transaktionsreplikering leverer ændringer fra udgiveren til abonnenterne i næsten realtid ved at replikere individuelle transaktioner, når de forekommer. Det starter med et indledende øjebliksbillede for at etablere baseline, overvåger derefter løbende transaktionsloggen for ændringer i udgivne artikler og leverer dem trinvist til abonnenterne.

Transaktionsreplikering er ideel til server-til-server-scenarier, der kræver høj kapacitet og lav latenstid. Almindelige anvendelsesscenarier omfatter forbedring af skalerbarhed og tilgængelighed ved at flytte læseoperationer til abonnentservere, understøtte datalagring og rapportering med næsten realtidsdata, integrere data fra flere steder på en central placering og flytte batchbehandling til dedikerede servere. For eksempel kan en e-handelsplatform bruge transaktionsreplikering til at vedligeholde synkroniserede lagerdata på tværs af regionale databaser.

Fordelene ved transaktionel replikering omfatter datalevering med lav latenstid, høj kapacitet for store transaktionsvolumener og muligheden for at foretage ikke-replikerede ændringer hos abonnenter. Ulemperne omfatter større kompleksitet sammenlignet med snapshot-replikering, kravet om primære nøgler på replikerede tabeller og potentialet for, at replikeringen afbrydes, hvis der opstår konflikter, såsom overtrædelser af primære nøgler hos abonnenter.

3.3 Fletningsreplikering

Merge-replikering er specifikt designet til miljøer, hvor abonnenter skal arbejde offline eller med periodisk forbindelse, og derefter synkronisere ændringer, når der er en tilgængelig forbindelse. Denne replikeringstype gør det muligt at ændre data hos både udgiver og abonnenter uafhængigt af hinanden, spore ændringer ved hjælp af udløsere og metatatabeller og automatisk flette ændringer under synkronisering.

Mergereplikering er designet til mobile applikationer og distribuerede servermiljøer, hvor der forekommer autonome ændringer. Anvendelseseksempler omfatter salgsautomatisering, hvor mobile brugere arbejder offline og synkroniserer senere, salgssystemer, der fungerer uafhængigt og konsoliderer data med jævne mellemrum, og distribuerede applikationer, hvor flere lokationer skal opdatere delte data. For eksempel kan en detailkæde bruge mergereplikering, så hver butik kan administrere lokal lagerbeholdning, mens den synkroniseres med det centrale lagersystem.

Fordelene ved mergereplikering omfatter understøttelse af autonome abonnenter, der kan foretage ændringer, tolerance over for intermitterende netværksforbindelse og fleksibel konfliktløsning. Ulemperne omfatter større kompleksitet i opsætning og vedligeholdelse, ydeevneoverhead fra sporing af metadata og triggere, tilføjelse af uniqueidentifier-kolonner til tabeller og potentiale for konflikter, der kræver administration og løsning.

3.4 Peer-to-peer-replikering

Peer-to-peer-replikering er bygget på transaktionel replikering og gør det muligt for flere serverinstanser (tre eller flere noder) at fungere som ligeværdige peers, hvor hver node fungerer som både udgiver og abonnent samtidigt. I denne topologi opretholder alle noder identiske kopier af data og kan håndtere både læse- og skriveoperationer, hvilket giver et ægte distribueret multimaster-miljø.

Peer-to-peer-replikering er velegnet til applikationer, der kræver udskalering af læseoperationer og høj tilgængelighed. Anvendelsesscenarier omfatter webapplikationer, der distribuerer katalogforespørgsler på tværs af flere noder, samtidig med at dataene opretholdes ensartede, scenarier, der kræver vedligeholdelse eller opgraderinger uden nedetid ved at tage noder offline individuelt, og globale applikationer med datacentre i forskellige regioner. For eksempel kan en verdensomspændende softwaresupportorganisation bruge peer-to-peer-replikering på tværs af kontorer i forskellige tidszoner, så hver lokation har lokal adgang til aktuelle data.

Fordelene ved peer-to-peer-replikering omfatter forbedret læseydelse gennem skalering, højere tilgængelighed med flere aktive noder og næsten realtidsdatakonsistens. Ulemperne omfatter kravet om Enterprise Edition, kompleksiteten i håndteringen af topologier med flere noder, behovet for identiske skemaer og data på tværs af alle noder og potentiale for konflikter, når skriveoperationer ikke er korrekt partitioneret.

3.5 Tovejsreplikering

Tovejsreplikering er en specifik transaktionel replikeringstopologi, der er designet specifikt til miljøer med to servere, hvor begge servere skal udveksle ændringer med hinanden. Hver server udgiver data og abonnerer på de samme data fra den anden server, hvilket skaber et simpelt tovejssynkroniseringsflow. Mens peer-to-peer-replikering også kan understøtte to noder, giver tovejsreplikering forbedret ydeevne til dette specifikke scenarie.

Tovejsreplikering er passende til scenarier, der kræver to aktive servere med synkroniserede data, såsom aktiv-aktive konfigurationer til høj tilgængelighed eller geografisk distribuerede applikationer, hvor hvert websted har brug for lokal skriveadgang. Topologien kræver omhyggeligt applikationsdesign for at partitionere dataopdateringer og forhindre konflikter.

Fordelene omfatter optimeret ydeevne til scenarier med to servere, enklere konfiguration sammenlignet med peer-to-peer-replikering, næsten realtidssynkronisering og lavere overhead end merge-replikering. Ulemperne omfatter begrænsningen til præcis to servere, manglen på indbygget konfliktløsning, der kræver omhyggeligt applikationsdesign, og behovet for korrekte partitioneringsstrategier for at forhindre konflikter.

3.6 Opdaterbare abonnementer

Opdaterbare abonnementer udvider transaktionel replikering for at give abonnenter mulighed for lejlighedsvis at foretage ændringer i replikerede data, som derefter overføres til udgiveren og til andre abonnenter. I modsætning til mergereplikering eller peer-to-peer-topologier designet til hyppige tovejsopdateringer, er opdaterbare abonnementer beregnet til scenarier, hvor den primære datastrøm er ensrettet (fra udgiver til abonnenter), men abonnenter lejlighedsvis skal foretage rettelser eller opdateringer.

Opdaterbare abonnementer er passende til scenarier, hvor most Opdateringer forekommer hos udgiveren, men lejlighedsvise opdateringer hos abonnenter er nødvendige, såsom feltkontorer, der primært læser data, men har brug for at foretage lokale rettelser eller opdateringer. Topologien kræver omhyggelig planlægning for at minimere konflikter og sikre datakonsistens.

De vigtigste fordele inkluderer muligheden for begrænsede skriveoperationer hos abonnenter, samtidig med at transaktionsreplikeringens ydeevneegenskaber opretholdes. Ulemperne inkluderer øget kompleksitet, potentiale for konflikter, der kræver løsning, ydeevneoverhead fra den tofasede commit-protokol i øjeblikkelig opdateringstilstand og kravet om, at alle replikerede tabeller skal have primære nøgler.

3.7 Sammenligning af forskellige typer replikationer

Replikeringstype	Opdateringstid	Antal udgivere	Lederskab	Brug Scenarier
Snapshot	Tidspunkt	1	One Direction (Udgiver → Abonnenter)	Sjældent skiftende referencedata (prislister, valutakurser)
transaktionsbeslutning	Tæt på realtid	1	One Direction (Udgiver → Abonnenter)	Scenarier med høj kapacitet (e-handelslager, datalagring, rapportering)
Flet	Periodisk (når tilsluttet)	1	Tovejs (Udgiver ↔ Abonnenter)	Mobilapplikationer, offlinemedarbejdere (automatisering af salgsstyrken, felttjenester)
Peer-to-Peer	Tæt på realtid	Flere (3 eller flere)	Tovejs (alle noder)	Globale implementeringer af flere datacentre (verdensomspændende kontorer med lokal læse- og skriveadgang)
Tovejs	Tæt på realtid	2	Tovejs (begge servere)	To-aktive datacentre-konfigurationer (høj tilgængelighed på to lokationer)
Opdaterbare abonnementer	Tæt på realtid	1	Primært én retning (lejlighedsvise omvendte opdateringer)	Filialer, der primært læser, men lejlighedsvis opdaterer (lokale rettelser)

4. Opsætning SQL Server Replication

4.1 Forudsætninger og krav

4.1.1 Softwarekrav

SQL Server replikering kræver kompatibel SQL Server versioner på tværs af alle deltagere i topologien. Distributørversionen skal være lig med eller højere end udgiverversionen, og abonnenten kan være inden for to versioner af udgiveren. For eksempel en SQL Server 2016-udgiver kan replikere til SQL Server Abonnenter fra 2012, 2014, 2016, 2017 eller 2019.

4.1.2 Tilladelseskrav

Konfiguration af replikering kræver specifikke tilladelser på hvert niveau. Medlemmer af den faste serverrolle sysadmin kan udføre alle replikeringskonfigurationsopgaver. For mere detaljerede tilladelser skal brugerne være medlemmer af databaserollen db_owner for udgiver- og abonnentdatabaser.

4.2 Trin 1: Konfigurer distribution

Konfiguration af distribution er det første trin i opsætningen SQL Server replikering.

Sådan konfigurerer du distribution ved hjælp af SQL Server Management Studio:

Opret forbindelse til SQL Server eksempel i SQL Server ManagementStudio.
I Objektstifinder skal du højreklikke på Replication mappe og vælg Konfigurer distribution.
I guiden Konfigurer distribution skal du klikke på Næste på velkomstsiden.
På Distributør skal du vælge en af følgende muligheder baseret på dine topologikrav:
- Lokal distributørVælg “Servernavn vil fungere som sin egen distributør; SQL Server "vil oprette en distributionsdatabase og -log", hvis du vil have udgiveren og distributøren til at køre på den samme instans (den aktuelle instans). Denne konfiguration er enklere at konfigurere og egnet til mindre miljøer, eller når netværkslatenstid mellem udgiver og distributør ville forårsage problemer.
- FjerndistributørVælg "Brug følgende server som distributør", og klik på Tilføj at angive en fjerndistributørserver, hvis du vil flytte distributionsbehandlingen til en separat instans. Denne konfiguration forbedrer ydeevnen, når replikeringsvolumenerne er store, ved at fordele arbejdsbyrden på tværs af flere servere. Du skal angive navnet på den eksterne distributør og angive en adgangskode, som udgiveren skal bruge til at oprette forbindelse til distributøren.
Klik Næste for at angive placeringen af snapshot-mappen. Brug en UNC-sti (f.eks. \\servernavn\share\mappe) i stedet for en lokal sti for at sikre tilgængelighed på tværs af netværket.
På Distributionsdatabase siden, accepter standardnavnet for distributionsdatabasen (typisk "distribution") eller angiv et brugerdefineret navn, og konfigurer derefter placeringer af data og logfiler.
På Udgivere På siden skal du kontrollere, at den aktuelle server er aktiveret som udgiver. Hvis du konfigurerer den aktuelle server som distributør, kan du tilføje yderligere udgivere, der skal bruge denne distributør.
Gennemgå guidens handlinger, og klik på Finish at konfigurere distributionen.

4.3 Trin 2: Opret publikation

Efter konfiguration af distribution er næste trin at oprette en publikation, der definerer, hvilke dataobjekter der skal replikeres til abonnenter.

Sådan opretter du en publikation ved hjælp af SQL Server Management Studio:

I Objektstifinder skal du udvide Replication mappe.
Højreklik Lokale publikationer og vælg Ny publikation.
Guiden til nye publikationertarts; klik Næste på velkomstsiden.
Vælg den database, du vil publicere, fra Publikationsdatabase side. Dette aktiverer automatisk publicering på den valgte database.
På Publikationstype side, vælg replikeringstypen: Snapshot-publikation, Transaktionel publikation, Peer-to-Peer-publikation eller Flet publikation.
På Artikler side, udvid tabeller node og vælg tabeller, der skal inkluderes som artikler.
Udvid eventuelt Lagrede procedurer, Viewseller andre objekttyper for at inkludere yderligere artikler.
Klik Artikelegenskaber for at konfigurere filtrering eller andre artikelspecifikke indstillinger.
På Filtrer tabelrækker side, tilføj rækkefiltre om nødvendigt.
På Snapshot-agent side, vælg hvornår snapshottet skal oprettes: med det samme, på et bestemt tidspunkt eller efter en tidsplan.
På Agentsikkerhed På siden skal du angiv sikkerhedskonteksten for Snapshot Agent.
På Guidens handlinger side, vælg Opret publikationen.
Angiv et publikationsnavn, og klik på Finish.

4.4 Trin 3: Opret abonnement

Efter oprettelse af en publikation er næste trin at oprette abonnementer, der forbinder publikationen til abonnentdatabaser.

Abonnementer kan være push-abonnementer (administreres af distributøren) eller pull-abonnementer (administreres af abonnenten). De vigtigste forskelle er, hvor du opretter abonnementet, og hvilken agentplacering du vælger, hvilket bestemmer abonnementets handling (push eller pull).

Til push-abonnement (administreret af distributøren):

På forlægger server, udvid Replication -> Lokale publikationer.
Højreklik på publikationen, og vælg Nye abonnementer.

Til Pull-abonnement (administreret af abonnenten):

På abonnent server, udvid Replication, Højreklik Lokale abonnementer, og vælg Nye abonnementer.
På Offentliggørelse side, skal du klikke på Finde SQL Server Forlægger og oprette forbindelse til udgiverens server.

Fælles guidetrin for begge abonnementstyper:

I guiden Nyt abonnement skal du klikke på Næste på velkomstsiden.
Vælg publikationen, og klik på Næste.
På Distributionsagentens placering side, vælg agentens placering:
- Push-abonnementVælg "Kør alle agenter hos distributøren" – distributøren vil sende ændringer til abonnenter.
- Træk abonnementVælg "Kør hver agent hos dens abonnent" – hver abonnent vil hente ændringer fra distributøren.
På Abonnenter side, vælg eksisterende abonnentservere eller klik på Tilføj Subscriber at tilføje nye.
For hver abonnent skal du vælge destinationsdatabasen eller oprette en ny database. Bemærk: Abonnementsdatabasen skal være forskellig fra udgiverdatabasen, selvom den samme bruges SQL Server instans.
På Distributionsagentsikkerhed Klik på knappen Egenskaber for hvert abonnement på siden for at konfigurere sikkerhedskonteksten.
På Synkroniseringsplan skal du vælge kontinuerlig synkronisering eller planlagt synkronisering.
På Initialiser abonnementer side, vælg Straks at initialisere under guideafslutning eller Ved første synkronisering.
Gennemgå guidens handlinger og klik på Finish.

5. Overvågning og styring SQL Server Replication

5.1 Overvågning af replikering med Replication Monitor

Sådan starter du Replikeringsovervågning:

In SQL Server Management Studio, udvid Replication i Objekt Explorer.
Højreklik Replication og vælg Start replikeringsovervågning.
Hvis der ikke er registreret nogen udgivere, skal du klikke på Tilføj udgiver i venstre rude.
Vælg Tilføj SQL Server Forlægger og oprette forbindelse til udgiverens server.
Udgiveren vises i venstre rude med udvidelige noder til publikationer og abonnementer.

5.2 Ydelsesovervågning

5.2.1 Overvågningsforsinkelse

Replikeringsforsinkelse er tidsforsinkelsen mellem en ændring, der sker hos udgiveren, og den ændring, der anvendes hos abonnenten. Overvåg latenstid for at sikre, at dataaktualitet opfylder forretningskravene.

Brug Replikeringsovervågning til at se latenstidsmålinger på fanen Alle abonnementer. Kolonnen Latens viser gennemsnitlig latenstid i sekunder. Til transaktionel replikering giver sporingstokens præcise latenstidsmålinger ved at indsætte markørtransaktioner, der spores gennem replikeringspipelinen.

Sådan bruger du tracer-tokens:

Vælg en transaktionel publikation i Replikeringsovervågning.
Klik på knappen Sporingspoletter fane.
Klik Indsæt sporingselement at indsprøjte en markørtransaktion.
Overvåg tokenet, mens det bevæger sig fra udgiver til distributør til abonnent.
Se den tid, det tager for hvert segment at identificere flaskehalse.

5.2.2 Overvågningsgennemstrømning

Gennemløbshastighed måler mængden af data, der replikeres over tid, typisk udtrykt som transaktioner pr. sekund eller kommandoer pr. sekund. Overvåg gennemløbshastigheden for at sikre, at replikeringen kan holde trit med udgiveraktiviteten.

Selvom Replication Monitor viser grundlæggende synkroniseringsstatus, er leveringshastighed og detaljerede gennemløbsmålinger ikke synlige i den grafiske brugergrænseflade. Brug T-SQL-forespørgsler mod distributionsdatabasen til at overvåge gennemløbet:

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 = Igangværende, 3 = Lykkes, 4 = Inaktiv, 5 = Forsøg igen, 6 = Mislykkes. Sammenlign leveringsraten med udgiverens transaktionsrater for at identificere situationer, hvor replikeringen halter bagefter. Ydelsestællere i Windows Performance Monitor Angiv yderligere gennemløbsmålinger for hver replikationsagent.

5.2.3 Identificér flaskehalse

Replikeringsflaskehalse kan opstå flere steder i topologien. Hos udgiveren kan for lang genereringstid af snapshots eller forsinkelser i Log Reader Agent være tegn på ressourcebegrænsninger. Overvåg CPU, hukommelse og disk I/O på udgiveren under replikeringsaktiviteter.

Hos distributøren skal du kontrollere for akkumulerende transaktioner i distributionsdatabasen. Et stort antal ikke-distribuerede kommandoer indikerer, at distributøren ikke kan følge med leveringen. Overvåg distributørens serverressourcer, og overvej at bruge en dedikeret fjerndistributør til scenarier med stor volumen.

Hos abonnenten kan langsom implementering af ændringer skyldes utilstrækkelige ressourcer, manglende indeks eller begrænsninger, der forsinker indsættelseshandlinger. Overvåg abonnentens ressourceudnyttelse og forespørgselsydelse, når Distribution Agent kører. Begrænsninger i netværksbåndbredde mellem komponenter forårsager også flaskehalse, især for store datamængder.

5.3 Administration af replikeringsagenter

5.3.1 Start og Stop Agenter

Til stareller stop en replikeringsagent:

In SQL Server Management Studio, udvid SQL Server Agent -> Karriere.
Find replikeringsagentjobbet (navne inkluderer typisk publikations- og abonnentoplysninger).
Højreklik på jobbet, og vælg Start Job or Stop job.

5.3.2 Konfigurer agentprofiler

Agentprofiler indeholder parametersæt, der styrer agentens adfærd. SQL Server leverer standardprofiler, der er optimeret til almindelige scenarier, og du kan oprette brugerdefinerede profiler til specifikke behov.

Sådan ændrer du agentprofiler:

I Objekt Explorer skal du udvide Replication.
Højreklik Replication og vælg Distributørens egenskaber.
Klik på knappen Profilstandarder .
Vælg en agenttype (Snapshot, Loglæser, Distribution eller Flet) fra rullemenuen.
Vælg en profil og klik på Ejendomme for at se parameterværdier.
Klik Ny profil at oprette en brugerdefineret profil baseret på en eksisterende.
Rediger parametrene efter behov, og klik på OK.

Anvend en profil på en agent ved at redigere abonnementsegenskaberne og vælge den ønskede profil i rullemenuen Agentprofil.

5.3.3 Agentparametre og -indstillinger

Agentparametre finjusterer ydeevne og adfærd. Nøgleparametre for Distribution Agent inkluderer CommitBatchSize (antal transaktioner anvendt pr. commit), CommitBatchThreshold (antal kommandoer før commit), SubscriptionStreams (parallelle forbindelser for hurtigere levering) og QueryTimeout (timeout for kommandoer).

For Log Reader Agent omfatter vigtige parametre ReadBatchSize (transaktioner læst pr. scanning), ReadBatchThreshold (kommandoer før levering) og PollingInterval (forsinkelse mellem logscanninger). Juster disse parametre baseret på transaktionsvolumen og latenstidskrav.

5.4 Overvejelser ved sikkerhedskopiering og gendannelse

Sikkerhedskopiering af databaser involveret i replikering kræver særlige overvejelser. For udgiverdatabasen er regelmæssige komplette sikkerhedskopier og transaktionslogbackups afgørende. Marker databasebackupen til replikeringsunderstøttelse ved at bruge indstillingen MED REPLIKERING, når du sikkerhedskopierer databaser i transaktionel replikering. Sikkerhedskopier distributionsdatabasen regelmæssigt for at beskytte replikeringskonfigurationen.

Når du gendanner en udgiverdatabase til den samme server med samme navn, skal du bruge indstillingen WITH KEEP_REPLICATION til at bevare replikeringstilstanden. Denne indstilling sikrer, at transaktioner, der endnu ikke er behandlet af Log Reader Agent, forbliver markeret til replikering, så replikeringen kan fortsætte automatisk uden at geninitialisere abonnementer.

I katastrofeberedskabsscenarier, hvor sikkerhedskopier ikke er tilgængelige, er beskadigede, eller databasefilerne er beskadigede, kan specialiserede gendannelsesværktøjer være nødvendige. DataNumen SQL Recovery kan udtrække data fra beskadigede eller utilgængelige MDF- og NDF-filer og dermed give en sidste udvej, når standardgendannelsesprocedurer mislykkes.

For flere detaljer om SQL Server sikkerhedskopiering, se vores omfattende vejledning.

6. Ofte stillede spørgsmål (FAQ)

Q: Hvad er forskellen mellem snapshot og transaktionel replikering?

A: Snapshot-replikering tager en komplet kopi af dataene på et bestemt tidspunkt og anvender den på abonnenten, hvilket er egnet til sjældent ændrede data. Transaktionel replikeringtarts med et indledende øjebliksbillede og replikerer derefter kontinuerligt individuelle transaktioner, når de forekommer, hvilket giver synkronisering i næsten realtid for ofte skiftende data.

Q: Kan jeg replikere mellem forskellige SQL Server versioner?

A: Ja, SQL Server replikering understøtter versionskompatibilitet inden for et begrænset område. Distributørversionen skal være lig med eller højere end udgiverversionen, og abonnenten kan være inden for to versioner af udgiveren. Hvis udgiveren f.eks. er SQL Server 2016 kan abonnenten være SQL Server 2012, 2014, 2016, 2017 eller 2019.

Q: Hvordan håndterer jeg konflikter i mergereplikering?

A: Mergereplikering tilbyder indbyggede mekanismer til konfliktdetektion og -løsning. Du kan konfigurere konfliktløsere på artikelniveau ved at vælge mellem indbyggede konfliktløsere eller implementere brugerdefinerede konfliktløsere. Konflikter løses typisk ved hjælp af prioritetsbaserede eller tidsstempelbaserede metoder med mulighed for at logge konflikter til manuel gennemgang.

Q: Hvad er replikeringens indvirkning på ydeevnen?

A: Replikering påvirker ydeevnen på flere måder: udgiveren oplever overhead fra sporing af ændringer og generering af snapshots, distributøren bruger ressourcer til at gemme og videresende transaktioner, og netværksbåndbredde forbruges under dataoverførsel. Påvirkningen varierer afhængigt af replikeringstypen, hvor snapshot-replikering forårsager periodiske bursts med stor effekt, og transaktionel replikering opretholder en mere ensartet, men kontinuerlig belastning.

Q: Hvordan sikrer jeg min replikeringstopologi?

A: Sikr din replikeringstopologi ved at implementere flere bedste fremgangsmåder: brug Windows-godkendelse eller stærke SQL Server godkendelse, krypter forbindelser ved hjælp af TLS, og sikr snapshot-mappen med passende NTFS tilladelser, konfigurere publikationsadgangslisten (PAL) til at kontrollere adgang, bruge separate servicekonti med minimale nødvendige tilladelser for hver replikeringsagent og regelmæssigt revidere sikkerhedsindstillinger for replikering.

Q: Kan jeg replikere til Azure SQL Database?

A: Ja, du kan replikere til Azure SQL Database ved hjælp af transaktionel replikering med en lokal database. SQL Server eller Azure SQL Managed Instance som udgiver og distributør. Azure SQL Database kan fungere som abonnent, men ikke som udgiver eller distributør. Merge-replikering og peer-to-peer-replikering understøttes ikke med Azure SQL Database.

Q: Hvordan overvåger jeg replikeringsforsinkelse?

A: Overvåg replikeringsforsinkelse ved hjælp af Replikeringsovervågning i SQL Server Management Studio, som viser latenstidsmålinger for hvert abonnement. Du kan også forespørge distributionsdatabasetabeller som MSdistribution_history og MSrepl_commands, bruge performancetællere specifikke for replikeringsagenter eller oprette advarsler baseret på latenstidsgrænser for proaktivt at registrere og håndtere synkroniseringsforsinkelser.

Q: Hvad sker der, når en abonnent er offline?

A: Når en abonnent er offline, afhænger adfærden af replikeringstypen. Ved transaktionel replikering akkumuleres transaktioner i distributionsdatabasen, indtil abonnenten er online igen, hvorefter synkroniseringen genoptages. Ved flettereplikering spores ændringer på begge sider og flettes sammen, når forbindelsen genoprettes. Indstillingen for opbevaringsperiode bestemmer, hvor længe data opbevares, før de skal geninitialiseres.

Q: Hvordan tilføjer jeg nye artikler til en eksisterende publikation?

A: For at tilføje nye artikler til en eksisterende publikation skal du bruge SQL Server Management Studio til at ændre publikationsegenskaberne og vælge yderligere objekter, eller brug den lagrede procedure sp_addarticle. Når du har tilføjet artikler, skal du generere et nyt snapshot og geninitialisere alle abonnementer for at sikre, at abonnenterne modtager de nye artikler. Nogle ændringer kan kræve geninitialisering af abonnementet afhængigt af publikationsindstillingerne.

Q: Hvordan fjerner jeg replikering fra en database?

A: Fjern replikering fra en database ved først at slette alle abonnementer ved hjælp af sp_dropsubscription, derefter slette publikationen med sp_droppublication og til sidst deaktivere publicering på databasen ved hjælp af sp_replicationdboption. Hvis serveren er en distributør, skal du deaktivere distribution ved hjælp af sp_dropdistributor. Sikkerhedskopier altid databaser, før du fjerner replikeringskonfigurationen.

Q: Hvad er forskellen mellem SQL Server Replikering og AlwaysOn-tilgængelighedsgrupper?

A: Replikering er en datadistributions- og integrationsløsning, der fungerer på objektniveau, mens Altid på tilgængelighedsgrupper er en løsning med høj tilgængelighed og katastrofegendannelse, der fungerer på databaseniveau.

7. konklusion

SQL Server Replikering giver et robust rammeværk til distribution og synkronisering af data på tværs af flere databaser og lokationer. Teknologien understøtter forskellige scenarier gennem forskellige replikeringstyper.

Valg af den rigtige replikeringsstrategi afhænger af dine specifikke krav. Overvej hyppigheden af dataændringer, latenstidskrav, om abonnenter skal foretage opdateringer, netværkskarakteristika og abonnenters behov for autonomi. Snapshot-replikering fungerer bedst til sjældent skiftende referencedata, hvor latenstid ikke er kritisk. Transaktionel replikering er egnet til scenarier med stor volumen, der kræver lav latenstid og primært envejsdatastrøm.

Vælg merge-replikering, når abonnenter har brug for autonom drift med offlinefunktioner og tovejssynkronisering. Implementer peer-to-peer-replikering til load balancing-læseoperationer på tværs af flere aktive noder med næsten realtidskonsistens. Overvej hybride tilgange, der kombinerer flere replikeringstyper til komplekse scenarier med forskellige krav.

Referencer

Om forfatteren

Yuan Sheng er en senior databaseadministrator (DBA) med over 10 års erfaring inden for SQL Server miljøer og virksomhedsdatabaseadministration. Han har med succes løst hundredvis af databasegendannelsesscenarier på tværs af finansielle tjenester, sundhedsvæsenet og produktionsorganisationer.

Yuan har specialiseret sig i SQL Server databasegendannelse, løsninger til høj tilgængelighed og ydeevneoptimering. Hans omfattende praktiske erfaring omfatter administration af databaser på flere terabyte, implementering af Always On Availability Groups og udvikling af automatiserede backup- og gendannelsesstrategier til missionskritiske forretningssystemer.

Gennem sin tekniske ekspertise og praktiske tilgang fokuserer Yuan på at skabe omfattende vejledninger, der hjælper databaseadministratorer og IT-professionelle med at løse komplekse SQL Server udfordringer effektivt. Han holder sig opdateret med det nyeste SQL Server udgivelser og Microsofts udviklende databaseteknologier, og tester regelmæssigt gendannelsesscenarier for at sikre, at hans anbefalinger afspejler bedste praksis i den virkelige verden.

Har spørgsmål vedr SQL Server gendannelse eller brug for yderligere vejledning i fejlfinding af databaser? Yuan er velkommen feedback og forslag for at forbedre disse tekniske ressourcer.