SQL Server Tømmertransport: Komplett guide for DBA [2026]

SQL Server Log Shipping er en automatisert løsning for gjenoppretting etter katastrofer som opprettholder varme reservekopier av produksjonsdatabasene dine. Teknologien overfører sikkerhetskopier av transaksjonslogger fra en primærdatabase på en primær serverinstans til én eller flere sekundære databaser på separate sekundære serverinstanser, noe som sikrer at sekundærdatabasene dine forblir synkroniserte med primærdatabasen, og gir beskyttelse mot datatap og serverfeil.

1.2 Formål og fordeler med tømmertransport

Loggforsendelse tjener flere kritiske formål i databaseadministrasjon:

Dens primære rolle er katastrofegjenoppretting, og gir et pålitelig failover-mål når primærserveren din blir utilgjengelig på grunn av maskinvarefeil, programvarefeil eller katastrofale hendelser som påvirker datasenteret ditt.
Det er også en kostnadseffektiv løsning med høy tilgjengelighetI motsetning til funksjoner i bedriftsklassen som krever dyr lisens, fungerer loggforsendelse med SQL Server Standardutgaven, noe som gjør den tilgjengelig for organisasjoner med budsjettbegrensninger.
Sekundære databaser i standby-modus tilbyr tilleggsverdi utover katastrofegjenoppretting. Databaseadministratorer kan bruke dem til skrivebeskyttet rapportering, og dermed avlaste spørrearbeidsbelastninger fra produksjonsserveren.
Funksjonen for forsinket gjenoppretting gir beskyttelse mot utilsiktede dataendringer. Ved å konfigurere en gjenopprettingsforsinkelse oppretter du et tidsvindu for å gjenopprette etter brukerfeil før destruktive endringer når den sekundære databasen.

2. SQL Server Komponenter og arbeidsflyt for loggforsendelse

Tømmertransport består av følgende komponenter:

Primærserver og primærdatabase: Primærserveren representerer produksjonen din SQL Server instans som kjører den primære databasen.
Sikkerhetskopieringsdeling: Den mellomliggende plasseringen for å lagre og overføre sikkerhetskopier av transaksjonsloggen fra primærserveren til sekundærserverne.
Sekundærservere og sekundærdatabaser: De sekundære serverne er vert for varme reservekopier av primærdatabasen din.
Overvåkingsserver (valgfritt): Denne serveren sporer historikk og status for alle sikkerhetskopierings-, kopierings- og gjenopprettingsoperasjoner på tvers av hele loggforsendelsestopologien.
Agentjobber: Inkluderer sikkerhetskopiering, kopiering, gjenoppretting og varslingsjobber, og automatiserer hele loggforsendelsesprosessen.

Automatiseringsarbeidsflyten er:

Sikkerhetskopieringsjobben kjører på den primære serveren og oppretter transaksjonsloggsikkerhetskopier av den primære databasen på den delte sikkerhetskopieringsressursen.
Kopieringsjobben kjører på hver sekundære server og overfører loggbackupfiler fra backup-ressursen til den/de sekundære serveren(e).
Gjenopprettingsjobben kjører på hver sekundære server og bruker kopierte sikkerhetskopier av transaksjonslogger på den sekundære databasen.
Varslingsjobben kjører på overvåkingsserveren og kontrollerer om sikkerhetskopierings- og gjenopprettingsoperasjonene er fullført innen akseptable tidsrammer.

3. Forutsetninger og krav

3.1 SQL Server Versjonskrav

Tømmerfrakt har vært tilgjengelig siden SQL Server 2000 og støttes fortsatt i alle senere versjoner fra SQL Server 2005 til 2025. Denne langvarige støtten demonstrerer teknologiens stabilitet og fortsatte relevans.

3.2 SQL Server Utgavekrav

Loggforsendelse fungerer med Standard-, Workgroup-, Enterprise- og Developer-utgavene av SQL ServerDenne brede utgavestøtten gjør loggforsendelse tilgjengelig for organisasjoner uten Enterprise Edition-lisenser, i motsetning til funksjoner som Alltid på tilgjengelighetsgrupper som krever Enterprise- eller Evaluation-utgaver.

Merk: Express Edition støtter ikke loggforsendelse.

3.3 Krav til databasegjenopprettingsmodell

Loggforsendelse krever at primærdatabasen bruker en fullstendig gjenopprettingsmodell eller en gjenopprettingsmodell for masselogging. En enkel gjenopprettingsmodell støttes ikke fordi SQL Server avkorter transaksjonslogger automatisk, og bryter den kontinuerlige loggkjeden som er nødvendig for loggforsendelse.

For mer informasjon om gjenopprettingsmodeller, se vår omfattende veiledning om SQL Server backup.

4. Konfigurering av loggforsendelse ved hjelp av SSMS

4.1 Opprett mappe for sikkerhetskopiering

Før du konfigurerer loggforsendelse, må du klargjøre den delte mappen for sikkerhetskopier der sikkerhetskopier av transaksjonslogger skal lagres og overføres.

På primærserveren eller en dedikert filserver, opprett en mappe (f.eks. C:\Sikkerhetskopiering)
Høyreklikk mappen og velg Eiendommer
Klikk på Deling tab
Klikk Avansert deling
Trykk her Del denne mappen
Klikk Tillatelser og bevilgning Full kontroll tillatelse til SQL Server tjenestekonto NT-tjeneste\MSSQLSERVER.
Klikk OK å søke.
Dokumenter nettverksstien (UNC) (f.eks. \\SERVERNAVN\Sikkerhetskopiering)

4.2 Aktiver og konfigurer loggforsendelse

Høyreklikk på den primære databasen og velg Eiendommer.
på Databaseegenskaper velger du Transaksjonslogg Frakt siden i venstre panel.
Trykk her Aktiver dette som en primær database i en konfigurasjon for loggforsendelse for å aktivere loggforsendelse.
Deretter kan du konfigurere sikkerhetskopieringsinnstillingene, den sekundære serveren og overvåkingsserveren på denne egenskapssiden. Vi vil introdusere dem i de følgende underavsnittene.

4.2.1 Konfigurer sikkerhetskopieringsinnstillinger

Klikk på Sikkerhetskopieringsinnstillinger knapp
på Innstillinger for sikkerhetskopiering av transaksjonslogg dialog, under Nettverkssti til sikkerhetskopimappen I feltet skriver du inn UNC-banen (f.eks. \\SERVERNAVN\Sikkerhetskopiering)
Hvis sikkerhetskopimappen ligger på hovedserveren, angi den lokale banen (f.eks. C:\Sikkerhetskopiering)
Konfigurer andre innstillinger, for eksempel oppbevaringsperiode for sikkerhetskopiering, varslingsterskel, sikkerhetskopieringsjobb og komprimering.
Klikk OK for å bekrefte innstillingene og lukke dialogboksen.

4.2.2 Konfigurer sekundær serverinstans og database

Klikk Legg til etter Sekundære serverforekomster og databaser
på Innstillinger for sekundære databaser dialog, klikk Koble for å koble til den sekundære serverinstansen.
på Sekundærdatabase rullegardinmeny, velg en eksisterende database eller skriv inn et nytt databasenavn
på Initialiserer sekundærdatabase kategorien, velg Ja, generer en fullstendig sikkerhetskopi av primærdatabasen og gjenopprett den i sekundærdatabasen (og opprett sekundærdatabasen hvis den ikke finnes)
Klikk på Kopier filer tab
på Målmappe for kopierte filer (denne mappen ligger vanligvis på den sekundære serveren), angi den lokale banen til målmappen på den sekundære serveren.
Sørg for at mappen finnes og at SQL Server tjenestekontoen har skriverettigheter
Klikk OK for å bekrefte innstillingene og lukke dialogboksen.

4.2.3 Konfigurer overvåkingsserver

Trykk her Bruk en overvåkingsserverforekomst
Klikk innstillinger
Klikk Koble for å koble til overvåkingsserverforekomsten
Sett Slett historikk etter å angi oppbevaringsperiode i timer
Klikk OK for å bekrefte innstillingene og lukke dialogboksen.

4.2.4 Gjennomgang og fullføring av konfigurasjon

Gjennomgå alle innstillingene på Transaksjonslogg Frakt side
Bekreft sikkerhetskopieringsinnstillinger, konfigurasjoner for sekundære servere og overvåkingsinnstillinger
Klikk OK å bruke konfigurasjonen
Veiviseren oppretter alle nødvendige jobber på primære, sekundære og overvåkingsservere
Klikk Lukke når konfigurasjonen er fullført

5. Fordeler og ulemper med tømmertransport

5.1 Fordeler med SQL Server Loggforsendelse

Kostnadseffektiv løsning: Fungerer med SQL Server Standardutgaven eliminerer dyre lisenskrav for Enterprise Edition. Dette gjør pålitelig katastrofegjenoppretting tilgjengelig for organisasjoner med begrensede budsjetter.
Enkel å konfigurere og vedlikeholde: Konfigurasjonsveiviseren veileder administratorer gjennom oppsettet med tydelige alternativer. De fleste databaser kan konfigureres innen 15–30 minutter uten spesialisert opplæring.
Støtte for flere sekundære servere: Støtt en rekke sekundære servere uten arkitektoniske begrensninger. Implementer én sekundær server for lokal katastrofegjenoppretting, en annen eksternt og en tredje for rapportering.
Minimal innvirkning på primærserver: Fungerer asynkront, noe som eliminerer synkroniseringsoverhead på primærserveren. Transaksjonstiden forblir upåvirket.
Bruker eksisterende sikkerhetskopier av transaksjonslogger: Sikkerhetskopier av loggforsendelser er standard sikkerhetskopier av transaksjonslogger, som kan brukes til gjenoppretting på bestemte tidspunkter uavhengig av loggforsendelser.
Forsinket gjenopprettingsalternativ: Funksjonen for gjenopprettingsforsinkelse beskytter mot utilsiktede dataendringer, som ikke er tilgjengelig i løsninger for replikering i sanntid.
Ingen delt lagring kreves: Bruker uavhengig lagring på hver server, noe som eliminerer krav til delt lagring og tilhørende kostnader.
Støtte på tvers av plattformer: Fungerer identisk på både Windows og Linux SQL Server distribusjoner.
Fungerer på tvers av domener: Krever ikke domenetillitsforhold eller Active Directory-integrasjon.

5.2 Ulemper og begrensninger ved tømmertransport

Ingen automatisk failover: Den primære begrensningen er kravet om manuell failover. Administratorer må utføre flere trinn før tjenesten gjenopptas.
Datasynkroniseringsforsinkelse: Sekundære databaser henger alltid etter primære databaser når det gjelder sikkerhetskopierings- og gjenopprettingsfrekvens.
Kun konfigurasjon på databasenivå: Konfigurerer på databasenivå i stedet for instansnivå. Å beskytte 50 databaser krever 50 separate konfigurasjoner.
Manuelle endringer i tilkoblingsstrengen: Applikasjoner må oppdatere tilkoblingsstrenger slik at de peker til den sekundære serveren etter failover.
Avbrudd i sekundære databaser: Sekundære databaser i standby-modus kobler fra brukere under gjenopprettingsoperasjoner.
Separat databasehåndtering: Hver databasekonfigurasjon må administreres individuelt uten koordinerte administrasjonsfunksjoner.

6. Beste praksis og brukstilfeller

6.1 Når skal man bruke tømmertransport

Lavbudsjetts katastrofegjenoppretting: Utmerker seg som en kostnadseffektiv løsning for gjenoppretting etter katastrofer for organisasjoner som ikke kan rettferdiggjøre lisenskostnadene for Enterprise Edition.
Moderate RPO/RTO-krav: Applikasjoner som tolererer 15–30 minutter med datatap og 30–60 minutter med nedetid, samsvarer perfekt med dens funksjoner.
Skrivebeskyttet rapporteringsserver: Opprett skrivebeskyttede kopier for rapportering av arbeidsbelastninger som tolererer periodiske frakoblinger.
Standardutgavemiljøer: Organisasjoner standardisert på SQL Server Standardutgaven mangler tilgang til tilgjengelighetsgrupper for alltid på, noe som gjør loggforsendelse til det beste tilgjengelige alternativet.
Servermigreringsprosjekter: Forenkler servermigreringer ved å opprettholde synkroniserte kopier i overgangsperioder.
Krav til forsinkede data: Konfigurer gjenopprettingsforsinkelser for å opprettholde databaser på faste punkter i fortiden for samsvars- eller revisjonsformål.

6.2 Når man IKKE skal bruke tømmertransport

Krav til nesten null nedetid: Applikasjoner med RTO-krav på under 15 minutter kan ikke stole på manuell failover.
Automatisk failover nødvendig: Upassende når forretningskrav krever automatisk failover uten administratorinngripen.
Sanntidssynkronisering kreves: Applikasjoner som krever sanntids- eller nær-sanntidsdata på sekundære servere kan ikke godta den iboende forsinkelsen i loggforsendelser.
Minimal toleranse for datatap: Organisasjoner med RPO målt i sekunder eller som krever null datatap trenger synkrone løsninger.

6.3 Beste praksis

Optimalisering av sikkerhetskopieringsfrekvens: Balanser sikkerhetskopieringsfrekvensen mot systemoverhead og gjenopprettingsmål. Start med 15-minutters intervaller og juster basert på faktiske behov.
Hensyn knyttet til nettverksbanen: Bruk UNC-stier i stedet for tilordnede stasjoner for sikkerhetskopieringssteder. Plasser sikkerhetskopieringsdelinger på pålitelig nettverksinfrastruktur.
Oppsett for overvåking og varsling: Konfigurer varsler for feil i sikkerhetskopiering, kopiering og gjenoppretting umiddelbart etter at oppsettet av loggforsendelse er fullført.
Regelmessig testplan: Planlegg kvartalsvise eller halvårlige failover-tester for å validere prosedyrer og opprettholde administratorberedskap.
Vedlikehold av dokumentasjon: Vedlikehold detaljerte runbooks som dokumenterer konfigurasjonsdetaljer, failover-prosedyrer og feilsøkingstrinn.
Sikkerhetshensyn: Bruk dedikerte tjenestekontoer med minimale nødvendige tillatelser. Begrens tillatelser for nettverksdeling på riktig måte.
Diskplassbehandling: Overvåk diskplassen på sikkerhetskopieringssteder kontinuerlig. Konfigurer varsler når plassen faller under 20 %.
Konfigurasjon av oppbevaringspolicy: Angi oppbevaringsperioder for sikkerhetskopier som er lengre enn den maksimale akseptable synkroniseringsforsinkelsen.
Gjenopprettingsforsinkelse for beskyttelse: Konfigurer gjenopprettingsforsinkelser når beskyttelse mot utilsiktede endringer rettferdiggjør økt synkroniseringsforsinkelse.

7. Feilsøking av vanlige problemer

7.1 Sikkerhetskopieringsjobber mislykkes

Utilstrekkelig diskplass: Sjekk jobbhistorikken for diskplassfeil. Bekreft tilgjengelig plass og ledig plass ved å slette gamle sikkerhetskopier eller aktivere komprimering.
Tillatelsesproblemer: Bekreft SQL Server Tjenestekontoen har full kontroll-tillatelse på både den lokale mappen og nettverksressursen.
Databasen er ikke i full gjenoppretting: Bytt tilbake til full gjenopprettingsmodell og ta en fullstendig sikkerhetskopi for å starte transaksjonsloggkjeden på nytt.

7.2 Kopieringsjobber mislykkes

Nettverkssti utilgjengelig: Test tilkoblingen fra den sekundære serveren ved å tilordne nettverksbanen manuelt.
Autentiseringsproblemer: Konfigurer eksplisitt legitimasjon for tilgang til nettverksdeling hvis serverne er i forskjellige domener.
Problemer med fillåsing: Ekskluder sikkerhetskopimappen fra antivirus-sanntidsskanning for å forhindre fillåsing.

7.3 Gjenopprettingsfeil i jobber

Manglende sikkerhetskopifiler: Bekreft at det finnes filer i målmappen og sjekk kopieringshistorikken.
Feil ved gjenopprettingssekvens: Identifiser manglende sikkerhetskopier av transaksjonslogger og gjenopprett dem i rekkefølge for å reparere loggkjeden.
Databasen er i feil tilstand: Reinitialiser loggforsendelsen ved å gjenopprette en fullstendig sikkerhetskopi med NORECOVERY hvis noen har gjenopprettet databasen.
Korrupsjon av databasefiler: Hvis gjenopprettingsfeilene vedvarer til tross for riktig rekkefølge og konfigurasjon, kan selve databasefilene være ødelagt. I slike tilfeller må du kanskje bruke en spesialisert sql-gjenopprettingsverktøy for å trekke ut data fra de skadede .MDF- og .NDF-filene før du prøver å initialisere loggforsendelsen på nytt.

7.4 Problemer med synkroniseringsforsinkelse

Begrensninger for nettverksbåndbredde: Aktiver komprimering av sikkerhetskopier for å redusere filstørrelser og båndbreddekrav.
Høyt transaksjonsvolum: Vurder å øke hyppigheten av sikkerhetskopiering for å lage mindre og mer håndterbare sikkerhetskopier.
Utilstrekkelig gjenopprettingsfrekvens: Øk gjenopprettingsfrekvensen for å tilnærmet sikkerhetskopieringsfrekvens og minimere forsinkelser.

7.5 Problemer med tilkobling til overvåkingsserver (SQL 2025)

OLE DB-leverandørfeil: SQL Server Standard obligatorisk kryptering i 2025 er i konflikt med eldre instanser som mangler riktig krypteringskonfigurasjon.
Krypteringskonfigurasjonsavvik: Bekreft konfigurasjonen av den tilkoblede serveren på overvåkingsserveren og sjekk krypteringsinnstillingene.
Løsninger for omgåelse: Slipp og gjenskap loggforsendelse ved hjelp av TLS 1.3-parametere, eller oppgrader alle forekomster til SQL Server 2025.

7.6 SQL Server Problemer med agenttjenesten

Tjenesten er ikke startet: Sjekk statusen for agenttjenesten og konfigurer den til å starte automatisk.
Jobbplan deaktivert: Bekreft status for jobbplan og aktiver deaktiverte planer.
Feil i jobbtrinn: Gjennomgå jobbhistorikken for å identifisere feilende trinn og spesifikke feilmeldinger.

8. Ofte stilte spørsmål (FAQ)

Spørsmål: Kan jeg bruke tømmerforsendelse med Express Edition?

A: Nei, SQL Server Express Edition støtter ikke loggforsendelse da den mangler SQL Server Middel.

Spørsmål: Hvor ofte bør jeg planlegge sikkerhetskopiering av loggfiler?

A: Standardintervaller på 15 minutter gir en rimelig balanse. Juster basert på målet for gjenopprettingspunktet.

Spørsmål: Kan sekundære databaser brukes til rapportering?

A: Ja, sekundære databaser konfigurert i standby-modus tillater skrivebeskyttet tilgang mellom gjenopprettingsoperasjoner.

Q: Hva skjer hvis hovedserveren svikter?

A: Utfør manuell failover for å sette en sekundær database på nett. Datatap tilsvarer synkroniseringsforsinkelsen ved feiltidspunktet.

Q: Kan jeg ha flere sekundære servere?

A: Ja, loggforsendelse støtter et ubegrenset antall sekundære servere med uavhengige konfigurasjoner.

Spørsmål: Hvordan beregner jeg synkroniseringsforsinkelse?

A: Sammenlign tidsstempelet for den siste gjenopprettede transaksjonsloggen med gjeldende tidspunkt ved hjelp av tabeller for overvåking av loggforsendelser.

Spørsmål: Kan loggforsendelse fungere på tvers av forskjellige domener?

A: Ja, det fungerer på tvers av forskjellige domener eller i arbeidsgruppemiljøer uten å kreve tillitsforhold.

Spørsmål: Hva er forskjellen mellom Ingen gjenoppretting og standby-modus?

A: Ingen gjenopprettingsmodus holder databasen utilgjengelig. Standbymodus tillater skrivebeskyttede spørringer mellom gjenopprettinger.

Spørsmål: Kan jeg midlertidig sette loggforsendelsen på pause?

A: Ja, deaktiver sikkerhetskopierings-, kopierings- og gjenopprettingsjobber for å sette synkroniseringen på pause samtidig som konfigurasjonen bevares.

Q: Hvordan fjerner jeg konfigurasjonen for loggforsendelse?

A: I Transaksjonslogg Frakt eiendomsside:

Fjern merkingen Aktiver dette som en primær database i en konfigurasjon for loggforsendelse
Klikk OK for å fjerne konfigurasjonen og slette jobber.

Spørsmål: Kan jeg bytte den sekundære databasen til lese-skrive-modus?

A: Ja, utfør GJENOPPRETT DATABASE MED GJENOPPRETTING, men dette bryter loggforsendelseskjeden.

Spørsmål: Hva er den maksimale forsinkelsen jeg kan konfigurere for gjenoppretting?

A: Det finnes ingen fast grense. Konfigurer forsinkelser fra minutter til dager basert på dine beskyttelseskrav.

Spørsmål: Hvordan påvirker loggforsendelse sikkerhetskopieringsstrategien?

A: Den oppretter sikkerhetskopier av transaksjonslogger som kan brukes både til loggforsendelse og gjenoppretting på bestemte tidspunkter.

Spørsmål: Kan jeg bruke loggforsendelse for servermigrering?

A: Ja, konfigurer loggforsendelse til den nye serveren, synkroniser, og utfør deretter planlagt failover av den gamle serveren under vedlikehold.

Q: Hvilke overvåkingsverktøy fungerer med tømmerforsendelse?

A: SQL Server Management Studio inkluderer innebygde rapporter. Tredjepartsverktøy som SQL Monitor og SolarWinds gir forbedret overvåking.

9. Konklusjon og anbefalinger

9.1 Sammendrag av nøkkelpunkter

SQL Server Loggforsendelse gir pålitelig og kostnadseffektiv katastrofegjenoppretting gjennom automatiserte sikkerhetskopierings- og gjenopprettingsoperasjoner for transaksjonslogger. Teknologien fungerer med Standard Edition, krever minimal infrastruktur og støtter flere sekundære servere.

Loggforsendelse utmerker seg for moderate gjenopprettingsmål der manuell failover er akseptabelt. Viktige begrensninger inkluderer krav om manuell failover, synkroniseringsforsinkelse og konfigurasjonsomfang på databasenivå.

Teknologien integreres godt med eksisterende sikkerhetskopieringsstrategier, støtter skrivebeskyttet rapportering via standby-modus og gir beskyttelse mot forsinket gjenoppretting mot utilsiktede endringer.

9.2 Ta det riktige valget for miljøet ditt

Evaluer loggforsendelsen mot dine spesifikke krav før implementering. Vurder mål for gjenopprettingspunkt, mål for gjenopprettingstid, budsjettbegrensninger og toleranse for driftskompleksitet.

Organisasjoner som bruker SQL Server Standardutgaven med moderate krav til gjenoppretting bør sterkt vurdere loggforsendelse. Bedrifter med strenge RTO-er på under 15 minutter bør evaluere Always On Availability Groups.

Vurder hybride tilnærminger som kombinerer tømmertransport med andre teknologier for kostnadsoptimalisering samtidig som du oppfyller ulike krav.

9.3 Neste trinn og tilleggsressurser

Begynn med småskala pilotimplementeringer for å få erfaring. Utvikle omfattende dokumentasjon, inkludert konfigurasjonsdetaljer, failover-prosedyrer og feilsøkingsveiledninger.

Planlegg regelmessige failover-tester for å validere prosedyrer og opprettholde administratorberedskap. Hold deg oppdatert. SQL Server oppdateringer og forbedringer.

Referanser

Microsofts offisielle dokument: Om frakt av tømmerstokker (SQL Server)
Microsofts offisielle dokument: Konfigurer loggforsendelse (SQL Server)

om forfatteren

Yuan Sheng er en senior databaseadministrator (DBA) med over 10 års erfaring innen SQL Server miljøer og administrasjon av bedriftsdatabaser. Han har løst hundrevis av databasegjenopprettingsscenarier på tvers av finansielle tjenester, helsevesen og produksjonsorganisasjoner.

Yuan spesialiserer seg på SQL Server databasegjenoppretting, løsninger for høy tilgjengelighet og ytelsesoptimalisering. Hans omfattende praktiske erfaring inkluderer administrasjon av databaser på flere terabyte, implementering av Always On Availability Groups og utvikling av automatiserte sikkerhetskopierings- og gjenopprettingsstrategier for forretningskritiske forretningssystemer.

Gjennom sin tekniske ekspertise og praktiske tilnærming fokuserer Yuan på å lage omfattende veiledninger som hjelper databaseadministratorer og IT-fagfolk med å løse komplekse SQL Server utfordringer effektivt. Han holder seg oppdatert på det siste SQL Server utgivelser og Microsofts utviklende databaseteknologier, og tester jevnlig gjenopprettingsscenarioer for å sikre at anbefalingene hans gjenspeiler beste praksis i den virkelige verden.

Har spørsmål vedr SQL Server gjenoppretting eller trenger du ytterligere veiledning for feilsøking av databaser? Yuan ønsker velkommen tilbakemeldinger og forslag for å forbedre disse tekniske ressursene.