SQL Server Tømmerforsendelse: Komplet guide til DBA [2026]

1. Introduktion til SQL Server Log Forsendelse

1.1 Hvad er SQL Server Forsendelse af træstammer?

SQL Server Log Shipping er en automatiseret løsning til gendannelse efter katastrofer, der vedligeholder varme standby-kopier af dine produktionsdatabaser. Teknologien overfører transaktionslogbackups fra en primær database på en primær serverinstans til en eller flere sekundære databaser på separate sekundære serverinstanser, hvilket sikrer, at dine sekundære databaser forbliver synkroniserede med den primære database og giver beskyttelse mod datatab og serverfejl.

1.2 Formål og fordele ved tømmertransport

Logforsendelse tjener flere kritiske formål i databaseadministration:

• Dens primære rolle er disaster recovery og fungerer som et pålideligt failover-mål, når din primære server bliver utilgængelig på grund af hardwarefejl, softwarekorruption eller katastrofale hændelser, der påvirker dit datacenter.
• Det er også en omkostningseffektiv løsning med høj tilgængelighedI modsætning til funktioner i virksomhedsklassen, der kræver dyre licenser, fungerer logforsendelse med SQL Server Standardudgaven, hvilket gør den tilgængelig for organisationer med budgetbegrænsninger.
• Sekundære databaser i standbytilstand tilbyder yderligere værdi ud over disaster recovery. Databaseadministratorer kan bruge dem til skrivebeskyttet rapportering og dermed aflaste forespørgselsbelastninger fra produktionsserveren.
• Funktionen til forsinket gendannelse beskytter mod utilsigtede dataændringer. Ved at konfigurere en gendannelsesforsinkelse opretter du et tidsvindue til at gendanne fra brugerfejl, før destruktive ændringer når din sekundære database.

2. SQL Server Komponenter og arbejdsgang til logforsendelse

Forsendelse af tømmerstokke består af følgende komponenter:

• Primær server og primær database: Den primære server repræsenterer din produktion SQL Server instans, der kører den primære database.
• Backupdeling: Den mellemliggende placering til at gemme og overføre transaktionslogbackups fra den primære server til de sekundære servere.
• Sekundære servere og sekundære databaser: De sekundære servere er vært for de varme standby-kopier af din primære database.
• Overvågningsserver (valgfrit): Denne server sporer historik og status for alle sikkerhedskopierings-, kopierings- og gendannelseshandlinger på tværs af hele din logforsendelsestopologi.
• Agentjob: Inklusive backup-, kopierings-, gendannelses- og alarmjob, der automatiserer hele logforsendelsesprocessen.

Automatiseringsarbejdsgangen er:

1. Sikkerhedskopieringsjobbet kører på den primære server og opretter transaktionslogbackups af den primære database på sikkerhedskopieringsdelingen.
2. Kopijobbet kører på hver sekundær server og overfører logbackupfiler fra backupdelingen til den/de sekundære server(e).
3. Gendannelsesjobbet kører på hver sekundær server og anvender kopierede transaktionslogbackups på den sekundære database.
4. Alarmjobbet kører på overvågningsserveren og kontrollerer, om sikkerhedskopierings- og gendannelseshandlinger er fuldført inden for acceptable tidsrammer.

3. Forudsætninger og krav

3.1 SQL Server Versionskrav

Forsendelse af træstammer har været tilgængelig siden SQL Server 2000 og forbliver understøttet i alle efterfølgende versioner fra SQL Server 2005 til 2025. Denne langvarige støtte demonstrerer teknologiens stabilitet og fortsatte relevans.

3.2 SQL Server Udgavekrav

Logforsendelse fungerer med Standard-, Workgroup-, Enterprise- og Developer-udgaverne af SQL ServerDenne brede udgaveunderstøttelse gør logforsendelse tilgængelig for organisationer uden Enterprise Edition-licenser, i modsætning til funktioner som f.eks. Altid på tilgængelighedsgrupper der kræver Enterprise- eller Evaluation-udgaver.

Bemærk: Express Edition understøtter ikke forsendelse af logfiler.

3.3 Krav til databasegendannelsesmodel

Logforsendelse kræver, at den primære database bruger en fuld gendannelsesmodel eller en masselogget gendannelsesmodel. En simpel gendannelsesmodel understøttes ikke, fordi SQL Server afkorter transaktionslogfiler automatisk, hvilket afbryder den kontinuerlige logkæde, der er nødvendig for logforsendelse.

For yderligere oplysninger om genopretningsmodeller, se vores omfattende guide om SQL Server backup.

4. Konfiguration af logforsendelse ved hjælp af SSMS

4.1 Opret mappe til deling af sikkerhedskopier

Før du konfigurerer logforsendelse, skal du forberede den delte mappe til sikkerhedskopiering, hvor sikkerhedskopier af transaktionslogge skal gemmes og overføres.

1. Opret en mappe på den primære server eller en dedikeret filserver (f.eks. C:\Sikkerhedskopiering)
2. Højreklik på mappen og vælg Ejendomme
3. Klik på knappen Deling fanen
4. Klik Avanceret deling
5. Check (Skak) Del denne mappe
6. Klik Tilladelser og bevilling Fuld kontrol tilladelse til SQL Server servicekonto NT-tjeneste\MSSQLSERVER.
7. Klik OK at ansøge.
8. Dokumentér netværksstien (UNC) (f.eks. \\SERVERNAVN\Backup)

4.2 Aktivér og konfigurer logforsendelse

1. Højreklik på den primære database, og vælg Ejendomme.
2. I Databaseegenskaber Vælg dialogboksen Transaktionslog Forsendelse side i venstre panel.
3. Check (Skak) Aktivér dette som en primær database i en logforsendelseskonfiguration for at aktivere forsendelse af tømmerstokke.
4. Derefter kan du konfigurere backupindstillingerne, den sekundære server og overvågningsserveren på denne egenskabsside. Vi vil introducere dem i de følgende underafsnit.
   
   

4.2.1 Konfigurer sikkerhedskopieringsindstillinger

1. Klik på knappen Sikkerhedskopieringsindstillinger .
   
2. I Indstillinger for sikkerhedskopiering af transaktionslog dialog under Netværkssti til backupmappen feltet, indtast UNC-stien (f.eks. \\SERVERNAVN\Backup)
3. Hvis backupmappen findes på den primære server, skal du indtaste den lokale sti (f.eks. C:\Sikkerhedskopiering)
4. Konfigurer andre indstillinger, f.eks. opbevaringsperiode for sikkerhedskopiering, alarmtærskel, sikkerhedskopieringsjob og komprimering.
5. Klik OK for at bekræfte indstillingerne og lukke dialogboksen.
   

4.2.2 Konfigurer sekundær serverinstans og database

1. Klik Tilføj under Sekundære serverinstanser og databaser
2. I Indstillinger for sekundære databaser dialog, klik Tilslut for at oprette forbindelse til den sekundære serverinstans.
3. I Sekundær database i en rullemenu skal du vælge en eksisterende database eller skrive et nyt databasenavn
4. I Initialisering af sekundær database fanebladet, vælg Ja, generer en fuld sikkerhedskopi af den primære database og gendan den i den sekundære database (og opret den sekundære database, hvis den ikke findes)
   
5. Klik på knappen Kopier filer fanen
6. I Destinationsmappe til kopierede filer (Denne mappe er normalt placeret på den sekundære server), indtast den lokale sti til destinationsmappen på den sekundære server.
7. Sørg for, at mappen findes, og at SQL Server servicekontoen har skrivetilladelser
   
8. Klik OK for at bekræfte indstillingerne og lukke dialogboksen.

4.2.3 Konfigurer overvågningsserver

1. Check (Skak) Brug en overvågningsserverinstans
   
   
2. Klik Indstillinger
3. Klik Tilslut for at oprette forbindelse til overvågningsserverinstansen
4. sæt Slet historik efter at angive opbevaringsperioden i timer
5. Klik OK for at bekræfte indstillingerne og lukke dialogboksen.
   
   

4.2.4 Gennemgang og fuldførelse af konfiguration

1. Gennemgå alle indstillinger på Transaktionslog Forsendelse side
2. Bekræft backupindstillinger, konfigurationer af sekundære servere og overvågningsindstillinger
3. Klik OK at anvende konfigurationen
4. Guiden opretter alle nødvendige job på primære, sekundære og monitorservere
5. Klik Luk når konfigurationen er færdig

5. Fordele og ulemper ved tømmertransport

5.1 fordele ved SQL Server Log Forsendelse

• Omkostningseffektiv løsning: Fungerer med SQL Server Standard Edition, hvilket eliminerer dyre licenskrav til Enterprise Edition. Dette gør pålidelig katastrofegendannelse tilgængelig for organisationer med begrænsede budgetter.
• Enkel at konfigurere og vedligeholde: Konfigurationsguiden guider administratorer gennem opsætningen med klare muligheder. De fleste databaser kan konfigureres inden for 15-30 minutter uden specialiseret træning.
• Understøttelse af flere sekundære servere: Understøtter adskillige sekundære servere uden arkitektoniske begrænsninger. Implementer én sekundær server til lokal disaster recovery, en anden eksternt og en tredje til rapportering.
• Minimal påvirkning af primær server: Fungerer asynkront, hvilket eliminerer synkroniseringsoverhead på den primære server. Transaktionscommittider forbliver uændrede.
• Bruger eksisterende sikkerhedskopier af transaktionslogfiler: Sikkerhedskopier af logforsendelse er standardtransaktionslogbackups, der kan bruges til gendannelse på et bestemt tidspunkt uafhængigt af logforsendelse.
• Forsinket gendannelsesmulighed: Funktionen til forsinkelse af gendannelse beskytter mod utilsigtede dataændringer, som ikke er tilgængelig i løsninger til replikering i realtid.
• Ingen delt lagerplads kræves: Bruger uafhængig lagring på hver server, hvilket eliminerer krav til delt lagring og tilhørende omkostninger.
• Support på tværs af platforme: Fungerer identisk på både Windows og Linux SQL Server indsættelser.
• Fungerer på tværs af domæner: Kræver ikke domænetillidsrelationer eller Active Directory-integration.

5.2 Ulemper og begrænsninger ved tømmertransport

• Ingen automatisk failover: Den primære begrænsning er kravet om manuel failover. Administratorer skal udføre flere trin, før tjenesten genoptages.
• Datasynkroniseringsforsinkelse: Sekundære databaser halter altid bagefter primære databaser med hensyn til hyppigheden af ​​sikkerhedskopiering og gendannelse.
• Kun konfiguration på databaseniveau: Konfigurerer på databaseniveau i stedet for instansniveau. Beskyttelse af 50 databaser kræver 50 separate konfigurationer.
• Manuelle ændringer af forbindelsesstrenge: Applikationer skal opdatere forbindelsesstrenge, så de peger på den sekundære server efter failover.
• Sekundære databaseafbrydelser: Sekundære databaser i standbytilstand afbryder brugernes forbindelse under gendannelseshandlinger.
• Separat databasehåndtering: Hver databasekonfiguration skal administreres individuelt uden koordinerede administrationsfunktioner.

6. Bedste praksis og brugsscenarier

6.1 Hvornår skal man bruge tømmerforsendelse

• Lavbudget katastrofeberedskab: Udmærker sig som en omkostningseffektiv løsning til disaster recovery for organisationer, der ikke kan retfærdiggøre licensomkostningerne til Enterprise Edition.
• Moderate RPO/RTO-krav: Applikationer, der tolererer 15-30 minutters datatab og 30-60 minutters nedetid, stemmer perfekt overens med dens muligheder.
• Skrivebeskyttet rapporteringsserver: Opret skrivebeskyttede kopier til rapportering af arbejdsbelastninger, der tolererer periodiske afbrydelser.
• Standardudgavemiljøer: Organisationer standardiseret på SQL Server Standardudgaven mangler adgang til Always On Availability Groups, hvilket gør logforsendelse til den bedste tilgængelige løsning.
• Servermigreringsprojekter: Letter servermigreringer ved at opretholde synkroniserede kopier i overgangsperioder.
• Krav til forsinkede data: Konfigurer gendannelsesforsinkelser for at vedligeholde databaser på faste punkter i fortiden af ​​hensyn til overholdelse af regler eller revision.

6.2 Hvornår skal tømmerforsendelse IKKE anvendes

• Krav til næsten nul nedetid: Applikationer med RTO-krav på under 15 minutter kan ikke være afhængige af manuel failover.
• Automatisk failover nødvendig: Upassende, når forretningskrav kræver automatisk failover uden administratorindgriben.
• Realtidssynkronisering kræves: Applikationer, der kræver data i realtid eller næsten realtid på sekundære servere, kan ikke acceptere den iboende forsinkelse i logforsendelse.
• Minimal tolerance over for datatab: Organisationer med RPO målt i sekunder eller som kræver nul datatab har brug for synkrone løsninger.

6.3 Bedste praksis

• Optimering af backupfrekvens: Afbalancer backupfrekvensen med systemoverhead og gendannelsesmål. Start med intervaller på 15 minutter, og juster dem baseret på de faktiske behov.
• Overvejelser vedrørende netværkssti: Brug UNC-stier i stedet for tilknyttede drev til backupplaceringer. Placer backupdelinger på en pålidelig netværksinfrastruktur.
• Opsætning af overvågning og alarmering: Konfigurer advarsler for fejl i sikkerhedskopiering, kopiering og gendannelse af job umiddelbart efter fuldførelse af opsætningen af ​​logforsendelse.
• Regelmæssig testplan: Planlæg kvartalsvise eller halvårlige failover-tests for at validere procedurer og opretholde administratorberedskab.
• Vedligeholdelse af dokumentation: Vedligehold detaljerede runbooks, der dokumenterer konfigurationsdetaljer, failover-procedurer og fejlfindingstrin.
• Sikkerhedsovervejelser: Brug dedikerede servicekonti med minimale nødvendige tilladelser. Begræns netværksdelingstilladelser på passende vis.
• Diskpladshåndtering: Overvåg diskpladsen på backup-placeringer løbende. Konfigurer advarsler, når pladsen falder til under 20 %.
• Konfiguration af opbevaringspolitik: Indstil opbevaringsperioder for sikkerhedskopier, der er længere end din maksimalt acceptable synkroniseringsforsinkelse.
• Gendannelsesforsinkelse for beskyttelse: Konfigurer gendannelsesforsinkelser, når beskyttelse mod utilsigtede ændringer berettiger øget synkroniseringsforsinkelse.

7. Fejlfinding af almindelige problemer

7.1 Fejl i sikkerhedskopieringsjob

• Utilstrækkelig diskplads: Tjek jobhistorikken for fejl i diskpladsen. Bekræft tilgængelig plads og ledig plads ved at slette gamle sikkerhedskopier eller aktivere komprimering.
• Tilladelsesproblemer: Bekræft SQL Server Tjenestekontoen har fuld kontroltilladelse på både den lokale mappe og netværksdelingen.
• Databasen er ikke i fuld gendannelse: Skift tilbage til fuld gendannelsesmodel, og tag en fuld sikkerhedskopi for at genstarte transaktionslogkæden.

7.2 Fejl i kopieringsjob

• Netværkssti utilgængelig: Test forbindelsen fra den sekundære server ved at kortlægge netværksstien manuelt.
• Godkendelsesproblemer: Konfigurer eksplicitte legitimationsoplysninger for adgang til netværksdeling, hvis servere er i forskellige domæner.
• Problemer med fillåsning: Udeluk backupmappen fra antivirus-scanning i realtid for at forhindre fillåsning.

7.3 Gendannelse af fejl i job

• Manglende backupfiler: Bekræft, at filerne findes i destinationsmappen, og tjek kopieringsjobhistorikken.
• Fejl ved gendannelsessekvens: Identificer manglende sikkerhedskopier af transaktionslogge, og gendan dem i rækkefølge for at reparere logkæden.
• Database i forkert tilstand: Genstart logforsendelsen ved at gendanne en fuld sikkerhedskopi med NORECOVERY, hvis nogen har gendannet databasen.
• Korruption af databasefiler: Hvis gendannelsesfejl fortsætter på trods af korrekt rækkefølge og konfiguration, kan selve databasefilerne være beskadiget. I sådanne tilfælde skal du muligvis bruge en specialiseret SQL-gendannelsesværktøj at udtrække data fra de beskadigede .MDF- og .NDF-filer, før du forsøger at geninitialisere logforsendelsen.

7.4 Problemer med synkroniseringsforsinkelse

• Begrænsninger for netværksbåndbredde: Aktivér komprimering af backup for at reducere filstørrelser og båndbreddekrav.
• Høj transaktionsvolumen: Overvej at øge hyppigheden af ​​backup for at oprette mindre og mere håndterbare backupfiler.
• Utilstrækkelig gendannelsesfrekvens: Øg hyppigheden af ​​gendannelsesjob for at tilnærme sikkerhedskopieringsfrekvensen og minimere forsinkelse.

7.5 Problemer med overvågningsserverforbindelse (SQL 2025)

• OLE DB-udbyderfejl: SQL Server 2025's obligatoriske standardkryptering er i konflikt med ældre instanser, der mangler korrekt krypteringskonfiguration.
• Krypteringskonfigurationsfejl: Bekræft konfigurationen af ​​den tilknyttede server på overvågningsserveren, og kontroller krypteringsindstillingerne.
• Løsninger til omgåelse: Slip og genskab logforsendelse ved hjælp af TLS 1.3-parametre, eller opgrader alle instanser til SQL Server 2025.

7.6 SQL Server Problemer med agentservice

• Tjenesten er ikke startet: Kontroller status for agenttjenesten, og konfigurer den til at starte automatisk.
• Jobplan deaktiveret: Bekræft status for jobplanlægning, og aktiver deaktiverede planer.
• Fejl i jobtrin: Gennemgå jobhistorikken for at identificere fejlende trin og specifikke fejlmeddelelser.

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

Q: Kan jeg bruge logforsendelse med Express Edition?

A: Nej, SQL Server Express Edition understøtter ikke logforsendelse, da den mangler SQL Server Agent.

Q: Hvor ofte skal jeg planlægge sikkerhedskopiering af logfiler?

A: Standardintervaller på 15 minutter giver en rimelig balance. Juster baseret på dit mål for restitutionspunktet.

Q: Kan sekundære databaser bruges til rapportering?

A: Ja, sekundære databaser konfigureret i standbytilstand tillader skrivebeskyttet adgang mellem gendannelseshandlinger.

Q: Hvad sker der, hvis den primære server fejler?

A: Udfør manuel failover for at bringe en sekundær database online. Datatab er lig med synkroniseringsforsinkelsen på fejltidspunktet.

Q: Kan jeg have flere sekundære servere?

A: Ja, logforsendelse understøtter et ubegrænset antal sekundære servere med uafhængige konfigurationer.

Q: Hvordan beregner jeg synkroniseringsforsinkelse?

A: Sammenlign det senest gendannede tidsstempel for transaktionsloggen med det aktuelle tidspunkt ved hjælp af overvågningstabellerne for logforsendelse.

Q: Kan logforsendelse fungere på tværs af forskellige domæner?

A: Ja, det fungerer på tværs af forskellige domæner eller i arbejdsgruppemiljøer uden at kræve tillidsforhold.

Q: Hvad er forskellen mellem Ingen gendannelse og Standby-tilstand?

A: Ingen gendannelsestilstand holder databasen utilgængelig. Standbytilstand tillader skrivebeskyttede forespørgsler mellem gendannelser.

Q: Kan jeg midlertidigt sætte logforsendelse på pause?

A: Ja, deaktiver sikkerhedskopierings-, kopierings- og gendannelsesjob for at sætte synkroniseringen på pause, mens konfigurationen bevares.

Q: Hvordan fjerner jeg konfigurationen for logforsendelse?

A: I Transaktionslog Forsendelse ejendomsside:

1. Fravælg Aktivér dette som en primær database i en logforsendelseskonfiguration
2. Klik OK for at fjerne konfigurationen og slette job.

Q: Kan jeg skifte den sekundære database til læse-skrive-tilstand?

A: Ja, udfør RESTORE DATABASE WITH RECOVERY, men dette afbryder logforsendelseskæden.

Q: Hvad er den maksimale forsinkelse, jeg kan konfigurere for gendannelse?

A: Der findes ingen fast grænse. Konfigurer forsinkelser fra minutter til dage baseret på dine beskyttelseskrav.

Q: Hvordan påvirker logforsendelse backupstrategien?

A: Den opretter sikkerhedskopier af transaktionslogge, der kan bruges til både logforsendelse og gendannelse på et givet tidspunkt.

Q: Kan jeg bruge logforsendelse til servermigrering?

A: Ja, konfigurer logforsendelse til den nye server, synkroniser, og udfør derefter planlagt failover af den gamle server under vedligeholdelse.

Q: Hvilke overvågningsværktøjer fungerer med logforsendelse?

A: SQL Server Management Studio inkluderer indbyggede rapporter. Tredjepartsværktøjer som SQL Monitor og SolarWinds giver forbedret overvågning.

9. Konklusion og anbefalinger

9.1 Sammenfatning af nøglepunkter

SQL Server Log Shipping giver pålidelig og omkostningseffektiv katastrofegendannelse gennem automatiserede sikkerhedskopierings- og gendannelsesoperationer for transaktionslogfiler. Teknologien fungerer med Standard Edition, kræver minimal infrastruktur og understøtter flere sekundære servere.

Logforsendelse er fremragende til moderate gendannelsesmål, hvor manuel failover er acceptabel. Nøglebegrænsninger omfatter krav om manuel failover, synkroniseringsforsinkelse og konfigurationsomfang på databaseniveau.

Teknologien integreres godt med eksisterende backupstrategier, understøtter skrivebeskyttet rapportering via standbytilstand og giver beskyttelse mod forsinket gendannelse mod utilsigtede ændringer.

9.2 Sådan træffer du det rigtige valg for dit miljø

Evaluer logforsendelse i forhold til dine specifikke krav før implementering. Overvej mål for gendannelsespunkt, mål for gendannelsestid, budgetbegrænsninger og tolerance for operationel kompleksitet.

Organisationer, der bruger SQL Server Standardudgaven med moderate gendannelseskrav bør kraftigt overveje logforsendelse. Virksomheder med strenge RTO'er på under 15 minutter bør evaluere Always On Availability Groups.

Overvej hybride tilgange, der kombinerer tømmertransport med andre teknologier for omkostningsoptimering, samtidig med at forskellige krav opfyldes.

9.3 Næste trin og yderligere ressourcer

Start med pilotimplementeringer i mindre skala for at få erfaring. Udvikl omfattende dokumentation, herunder konfigurationsdetaljer, failover-procedurer og fejlfindingsvejledninger.

Planlæg regelmæssige failover-tests for at validere procedurer og opretholde administratorberedskab. Hold dig opdateret. SQL Server opdateringer og forbedringer.

Referencer

• Microsofts officielle dokument: Om forsendelse af træstammer (SQL Server)
• Microsofts officielle dokument: Konfigurer logforsendelse (SQL Server)

---

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.