Slip uønskede (sekundære) servertransaktionslogfiler

denne artikel undersøger brugen af flere Servertransaktionslogfiler og processen med at fjerne den sekundære transaktionslogfil.

introduktion

som standard indeholder en SERVERDATABASE en primær datafil og transaktionslogfil. Det er en god praksis at konfigurere flere datafiler og opdele data på tværs af flere datafiler. Vi kan have disse datafiler i separate lagerdrev for at have flere io. Det hjælper datastyring, forbedrer ydeevnen, planlægger backup-tilgange i henhold til filgrupper.

vi kan også have flere transaktionslogfiler til en database.

vi bruger flere transaktionslogfiler i rækkefølge. Antag, at vi har to transaktionslogfiler. Vi bruger en logfil ad gangen, og når den er fuld, bruger vi en anden logfil. Da ikke bruger det parallelt, får vi ikke nogen ydelsesfordel ved det. Ideelt set bør vi kun have en transaktionslogfil pr.

lad os antage, at vi har en produktionsdatabase, og vi modtager en kritisk advarsel om, at disken løber tør for plads. Efter undersøgelse har vi fundet ud af, at dette drev har en transaktionslogfil. På grund af aktive transaktioner er denne servertransaktionslogfil fuld. Vi har forsøgt at krympe logfilen, men det virkede ikke. Vi sikkerhedskopierer også transaktionsloggen, men på grund af aktive transaktioner kunne den ikke frigive den nødvendige plads. Tilføjelse af en anden transaktionslogfil på en separat disk med ledig plads løser dette problem.

da vi bruger seriel tilstand til at skrive data i en transaktionslogfil, skal vi fjerne den ekstra logfil senere. Lad os undersøge processen med at fjerne en ekstra logfil.

Opret en database med flere transaktionslogfiler

Opret forbindelse til en instance I Server Management Studio. Højreklik på Databaseknuden i Objektudforskningsruden, og klik på kommandoen Ny Database:

det åbner vinduet Ny database. Angiv et databasenavn, og tilføj en anden transaktionslogfil. Til testformål har vi deaktiveret automatisk vækst af transaktionslogfiler. Den oprindelige størrelse af transaktionslogfilen er 8 MB:

når alt er indstillet, skal du klikke på knappen OK for at oprette en database i et standardmappe for data/logfiler. Oprette en tabel og indsætte data i:

se status for den virtuelle logfil i transaktionslogfiler

i artiklen, arkitekturen for transaktionslogfiler for servere, undersøgte vi det interne i transaktionslogfilen. Hver transaktionslogfil består af flere virtuelle logfiler. En transaktionslogfil er en kombination af flere virtuelle logfiler (VLF). Følgende skærmbillede viser logfilens fysiske og logiske arkitektur:

en database med minimum VLF baseret på den oprindelige logstørrelse og automatisk vækstfil (baseret på automatisk vækstkonfiguration). I det følgende billede får vi et glimt af logfilen for servertransaktion:

i tilfælde af en enkelt transaktionslogfil bruger vi en cirkulær virtuel logfilsti. Vi kan kontrollere antallet af virtuelle logfiler og deres status ved hjælp af følgende:

1. DBCC LOGINFO(‘Database’) – det er en gammel erklæring og fungerer med alle serverversioner
2. dynamisk styringsvisning sys.dm_db_log_info (DBID). Den er tilgængelig fra Server 2016 SP2 eller nyere

enhver af kommandoerne kan bruges til VLF-kontrollen. Til denne artikel bruger vi dynamisk styringsvisning (DMV):

i ovenstående skærmbillede har vi bekræftet, at vores eksempeldatabase indeholder to transaktionslogfiler (file_id 2 og file_id 3).

• File_id 2 har aktiv VLF (vlf_active=1 og vlf_status=2)
• File_id 3 har ingen aktiv VLF (vlf_active=0 og vlf_status=2)

lad os indsætte et par flere poster i tabellen, så aktiv VLF ændres:

overvågningen af transaktionslogrummet og VLF-status udføres med DMV (sys.dm_db_log_space_usage):

• VLF status

  1 2	vælg DB_name() som Databasenavn,File_ID som transaktion_log_file_id, vlf_active , vlf_status fra sys. dm_db_log_info(Db_id(‘MultileLogFiles’));

• brug af transaktionslog (brugt og ledig plads)

  1 2 3 4 5

  vælg total_log_størrelses_in_bytes*1.0/1024/1024 total_log_størrelses_in_mb, used_log_space_in_bytes*1.0/1024/1024 used_log_space_in_MB, (total_log_størrelses_in_bytes-used_log_space_in_bytes)*1.0/1024/1024 AS free_log_space_in_MB fra sys. dm_db_log_space_usage;

vi får følgende output af ovenstående forespørgsler:

• på venstre side ser vi, at når den primære logfil (file_id 2) bliver fuld, flytter den til den næste logfil (file_id 3). På dette tidspunkt har vi aktiv VLF i både primære og sekundære logfiler. I en database med en fuld gendannelsesmodel har vi brug for en transaktionslog backup, så den markerer VLF som inaktiv
• højre side output (ved hjælp af DMV) viser transaktionslogfilen brugt plads 8.51 MB. Som du husker, har vi indstillet 8 MB størrelse for hver transaktionslogfil, og vi har deaktiveret log auto-vækst. Når den primære logfil er fuld (ved 8 MB), skifter vi til den sekundære transaktionslogfil

fjern den sekundære transaktionslogfil

for at fjerne den sekundære transaktionslogfil (file id 3) bruger vi den redigerede Alter-databaseerklæring.

vi tilføjer klausulen fjern fil og specificerer den fil, vi vil fjerne:

udførelse af denne erklæring vil resultere i følgende fejlmeddelelse:

Bemærk: den aktive transaktionslogfil kan ikke fjernes.

tidligere så vi, at når den primære logfil bliver fuld, bruger vi den sekundære logfil. Vi skal gøre en sekundær transaktionslog tom, så vi kan fjerne den.

i databasen med fuld gendannelsesmodel bruger vi sikkerhedskopier af transaktionslog, så serveren kan afkorte logfilerne. Vi har muligvis brug for flere log-sikkerhedskopier til dette afhængigt af transaktionslogstørrelse, aktiv VLF og aktiv transaktion.

lad os udføre en fuld database og transaktionslog backup:

• fuld database backup

  1	backup Database MultipleLogFiles til disk=’C:\Temp\MultipleLogFiles.bak’

• backup af transaktionslog

  1	backup log MultipleLogFiles til disk=’C:\Temp\MultipleLogFiles_log.trn’

når sikkerhedskopien er afsluttet, skal du kontrollere VLF-status. Den aktive VLF skal være i den første logfil(primær), så vi kan fjerne den sekundære logfil. Vi har bekræftet, at kun den primære logfil (file_id 2) er aktiv (VLF Status 2):

nu skal den sekundære transaktionslogfil fjernes uden problemer. Lad os udføre den redigerede Alter-databaseerklæring igen. Den sekundære transaktionslogfil fjernes:

når den sekundære transaktionslogfil er fjernet, skal du kontrollere den ved hjælp af GUI såvel som T-kvm med systemvisning sys.databasefil:

den fjernede sekundære transaktionslogfil er stadig til stede i henhold til følgende skærmbillede:

højreklik nu på databasen og se eksisterende filer. Vi ser også den fjernede transaktionslogfil i GUI. Men hvorfor?

lad os udføre den redigerede Alter-databaseerklæring igen og se, om igen fjerner transaktionslogfilen.

vi fik beskeden om, at vi ikke kunne finde den angivne logfil:

fjerner transaktionslogfilen efter en efterfølgende logbackup. Lad os tage en anden log backup og kontrollere, at transaktionslogfilen stadig eksisterer:

Bekræft transaktionslogfilen i både GUI-og T-kvm-metoder. Vi ser, at den fjernede transaktionslogfil ikke vises nu.

konklusion

i denne artikel undersøgte vi brugen af den sekundære SERVERTRANSAKTIONSLOG og processen med at fjerne den. Du bør undgå at bruge flere transaktionslogfiler, især i produktionsdatabasen. Du bør tage en database backup før planlægning enhver aktivitet og gøre det i ikke-Produktivitet Timer.

• forfatter
• Seneste indlæg

som MCSA-certificeret og Microsoft-certificeret træner i Gurgaon, Indien, med 13 års erfaring, Rajendra arbejder for en række store virksomheder med fokus på præstationsoptimering, overvågning, høj tilgængelighed, og katastrofegendannelsesstrategier og implementering. Han er forfatter til hundredvis af autoritative artikler på og relaterede teknologier, der er blevet set af over 10m læsere til dato.
han er skaberen af en af de største gratis online samlinger af artikler om et enkelt emne, med sin 50-delt serie på server altid på tilgængelighed grupper. Baseret på hans bidrag til SERVERFÆLLESSKABET er han blevet anerkendt med forskellige priser, herunder den prestigefyldte “årets bedste forfatter” kontinuerligt i 2020 og 2021 på .
Raj er altid interesseret i nye udfordringer, så hvis du har brug for rådgivning om ethvert emne, der er omfattet af hans skrifter, kan han nås på [email protected]
se alle indlæg af Rajendra Gupta

Seneste indlæg af Rajendra Gupta (se alle)

• brug ARM-skabeloner til at implementere vores containerinstanser med vores serverlinjebilleder – 21. December 2021
• Fjernskrivebordsadgang til vores RDS – Server med vores brugerdefinerede RDS – 14. December 2021
• Gem vores serverfiler i vedvarende lagerplads til vores Containerinstanser – December 10, 2021