Fjern Unødvendige SQL Server-Transaksjonsloggfiler

Av: Sergey Gigoyan | Oppdatert: 2015-11-18 / Kommentarer (9) / Relatert: Mer > Databaseadministrasjon

Problem

SQL Server tillater å bruke mer enn en transaksjonsloggfil, men spørsmålet oppstår om det er nødvendigog hva er fordelen med å ha flere transaksjonsloggfiler. Det er en misforståelse blant noen utviklere som har fleretransaksjonsloggfiler kan øke ytelsen fordi SQL Server kan bruke dem parallelt. SQL Server brukerbare en transaksjonsloggfil for øyeblikket, og det er ingen parallellitet i dette tilfellet. Noen ganger kan mer enn en loggfil væretrenger med det formål å feilsøke. Så normalt er det ikke nødvendig å ha mer enn en loggfil.La oss vurdere en sak, når vår database har mer enn en loggfil, og vi bør beholde bare en.Dette tipset tar sikte på å beskrive hvordan du fjerner unødvendige loggfiler riktig og beholder bare en.

Løsning

før du begynner å illustrere hvordan du fjerner unødvendige loggfiler, la oss kort beskrive HVORDAN SQL Server fungerermed loggfiler: NÅR databasen har mer enn en loggfil, FORTSETTER SQL Server å skrive til den første til den er full,og bytter deretter til den andre og så videre. NÅR den siste loggfilen blir full SQL Server returnerer tilbake til den første og syklusen fortsetter.Som vi nevnte, kan det imidlertid være nødvendig med mer enn en loggfil. For eksempel når disken, hvor loggfilen er plassertblir full og vi må opprette den andre loggfilen på et annet sted, men etter feilsøking av problemet,bør vi slette den andre loggfilen, fordi det ikke er bruk for å ha mer enn en loggfil.La oss nå anta at vi har en database med to loggfiler, og vår oppgave er å fjerne den andre.Følgende skript oppretter TestDB-databasen med to loggfiler og Testtabelltabell. For å kjøre det selv, må du erstatte»D:\SQL Data» med en eksisterende mappebane.

USE GOCREATE DATABASE ON PRIMARY ( NAME = N'TestDB', FILENAME = N'D:\SQL DATA\TestDB.mdf' , SIZE = 4096KB , MAXSIZE = UNLIMITED, FILEGROWTH = 1024KB ) LOG ON ( NAME = N'TestDB_log1', FILENAME = N'D:\SQL DATA\TestDB_log1.ldf' , SIZE = 1024KB , MAXSIZE = 2048GB , FILEGROWTH = 10%), ( NAME = N'TestDB_log2', FILENAME = N'D:\SQL DATA\TestDB_log2.ldf' , SIZE = 1024KB , MAXSIZE = 2048GB , FILEGROWTH = 10%)GOUSE TestDBGOCREATE TABLE TestTable(ID INT IDENTITY(1,1),Value BIGINT)--Change recovery model for TestDB to FULL (if your model database is in FULL recovery model, TestDB has been already created in this mode)ALTER DATABASE TestDB SET RECOVERY FULL 

La Oss nå forstå transaksjonsloggens fysiske struktur: Internt transaksjonsloggfil består avvirtuelle Loggfiler (VLF), som er styringsenheten i transaksjonsloggfilen. Det betyr at når databasemotoren vokser eller krymper loggfilen, gjør den det med komplette VLFs(for eksempel kan den ikke krympe halvparten AV VLF). Størrelsen på virtuelle loggfiler i tillegg tilderes nummer i den fysiske loggfilen er ikke løst og styres dynamisk av databasemotoren. For å overvåketransaksjonsloggfilen interntvi bruker kommandoen «DBCC LOGINFO», som gir informasjon om virtuelle loggfiler. I skriptet nedenfor brukte vi denne kommandoen for vår database:

--Getting log files infoDBCC LOGINFO('TestDB')

Og resultatet er følgende:

FileID er loggfil Ider for vår database. Status indikerer ER VLF gjenbrukbare ellerikke (mulige verdier: 0-ja, 2-nei). Som vi kan se er DET bare EN VLF medstatus=2. Nå når vi vil sette inn data I Testtabellen og overvåke hvordan loggfiler vokser:

USE TestDBGO--Checking log information before insertionSELECT file_id, name, type_desc, physical_name, size, max_sizeFROM sys.database_files--Inserting data into TestTable;WITH ValueTable AS(SELECT 1 nUNION ALL SELECT n+ 1FROM ValueTableWHERE n 

med dette eksemplet kan vi se at begge loggfilene vokste og nå Er Det VLFs Med «Status=2» i den andre loggfilen (FileID=3) også:

Nå må Vi fjerne TestDB_log2.ldf-fil. Merk at vi bare kan fjerne de sekundære loggfilene. Fjerningden primære loggfilen er ikke tillatt AV SQL Server.Hver database har bare en primær loggfil og den første loggfilen som er opprettet inthe database creation script regnes som den primære.Hvis vi prøver å fjerne den andre loggfilen:

USE masterGO--Remove TestDB_log2 fileALTER DATABASE TestDB REMOVE FILE TestDB_log2

Vi vil motta følgende melding:

vi kan bare fjerne transaksjonsloggfilen når den er tom, derfor må vi først tømme it.To gjør det, bør vi sikkerhetskopiere transaksjonsloggen. Siden vår» TestDB » – database ernyopprettet og det er ingen fulle sikkerhetskopier, trenger viå utstede en full database backup For TestDB-databasen, hvoretter vi kanutstede en transaksjonslogg backup:

--Full backupBACKUP DATABASE TestDB TO DISK =N'D:\SQL DATA\TestDB.bak'--Transaction log backupBACKUP LOG TestDB TO DISK =N'D:\SQL DATA\TestDB.trn'

transaksjonsloggen backup avkorter loggfilen (det er noen unntak, som er utenfor omfanget av thistip). Logg avkorting sletter inaktive virtuelle loggfiler frastarten av den logiske loggen og frigjør plass i loggfilen. Avkorting reduserer imidlertid ikke størrelsen på en fysisk loggfil. Det frigjør bare plass i den, som kan gjenbrukes. La oss kjøre» DBCC LOGINFO » igjen:

Som vi kan se er det ingen virtuelle loggfiler i » TestDB_log2.ldf » fil Med Status=2 og nå vår loggfil er tom og klar for fjerning:

--Remove TestDB_log2 fileALTER DATABASE TestDB REMOVE FILE TestDB_log2

fjerningen er vellykket.

men Når vi sjekker logginformasjonen igjen, ser vi at den logiske loggfilen fortsatt eksisterer:

--Checking log informationSELECT file_id, name, type_desc, physical_name, size, max_sizeFROM sys.database_files

hvis vi gjør en annen logg backup, vil filen bli slettet:

--Transaction log backupBACKUP LOG TestDB TO DISK =N'D:\SQL DATA\TestDB.trn'--Checking log informationSELECT file_id, name, type_desc, physical_name, size, max_sizeFROM sys.database_files

Neste Trinn

• Husk dette tipset for å bestemme bruk av transaksjonslogg og hvordan du fjerner en ikke-nødvendig loggfil.
• Sjekk ut disse ressursene:
  • Databaseadministrasjon / Transaksjonslogg
  • https://technet.microsoft.com/en-us/library/ms191433(v = sql.105).aspx
  • https://technet.microsoft.com/en-us/library/ms179355(v = sql.105).aspx
  • https://technet.microsoft.com/en-us/library/ms345414(v = sql.105).aspx

Om forfatteren

Sergey Gigoyan Er en database profesjonell med mer enn 10 års erfaring, med fokus på database design, utvikling, ytelse tuning, optimalisering, høy tilgjengelighet, BI og DW design.
Se alle mine tips

Artikkelen Sist Oppdatert: 2015-11-18