af: Sergey Gigoyan | opdateret: 2015-11-18 | Kommentarer (9) | relateret: mere> databaseadministration
Problem
kvm-Server giver mulighed for at bruge mere end en transaktionslogfil, men spørgsmålet opstår, om det er nødvendigtog hvad er fordelen ved at have flere transaktionslogfiler. Der er en misforståelse blandt nogle udviklere, at have multitransaction logfiler kan øge ydeevnen, fordi
Solution
før du begynder at illustrere, hvordan du fjerner unødvendige logfiler, lad os kort beskrive, hvordan vi arbejder på Serverenmed logfiler: når databasen har mere end en logfil, fortsætter vi med at skrive til den første,indtil den er fuld, skifter derefter til den anden og så videre. Når den sidste logfil bliver fuld, vender serveren tilbage til den første, og cyklussen fortsætter.Som vi nævnte, kan der dog undertiden kræves mere end en logfil. For eksempel når disken, hvor logfilen er placeretbliver fuld, og vi skal oprette den anden logfil på et andet sted,men efter fejlfinding af problemet skal vi slette den anden logfil, fordi der ikke er brug for at have mere end en logfil.Lad os nu antage, at vi har en database med to logfiler, og vores opgave er at fjerne den anden.Følgende script opretter TestDB-databasen med to logfiler og Testtabeltabel. For at køre det selv skal du udskifte”D:\SQL Data” med en eksisterende mappesti.
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
lad os nu forstå transaktionslogens fysiske struktur: internt transaktionslogfil består afvirtuelle logfiler (VLF), som er ledelsesenheden i transaktionslogfilen. Det betyder, at når databasemotoren vokser eller krymper logfilen, gør den det med komplette VLFs (for eksempel kan den ikke krympe halvdelen af VLF). Størrelsen af virtuelle logfiler såvel som deres nummer i den fysiske logfil er ikke fast og styres dynamisk af databasemotoren. At overvågetransaktionslogfilen interntvi bruger kommandoen “DBCC LOGINFO”, som indeholder oplysninger om virtuelle logfiler. I scriptet nedenfor brugte vi denne kommando til vores database:
--Getting log files infoDBCC LOGINFO('TestDB')
og resultatet er følgende:
FileID er logfil-id ‘ er til vores database. Status indikerer er VLF genanvendelig ellernot (mulige værdier: 0 – ja, 2-Nej). Som vi kan se, er der kun en VLF medstatus=2. Nu når vi vil indsætte data i testtabellen og overvåge, hvordan logfiler 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 eksempel kan vi se, at begge logfiler voksede, og nu er der VLFs med “Status=2” i den anden logfil (FileID=3) også:
nu skal vi fjerne TestDB_log2.LDF-fil. Bemærk, at vi kun kan fjerne de sekundære logfiler. Det er ikke tilladt at fjerne den primære logfil.Hver database har kun en primær logfil, og den første logfil, der oprettes idatabaseoprettelsesscriptet, betragtes som det primære.Hvis vi forsøger at fjerne den anden logfil:
USE masterGO--Remove TestDB_log2 fileALTER DATABASE TestDB REMOVE FILE TestDB_log2
vi modtager følgende meddelelse:
vi kan kun fjerne transaktionslogfilen, når den er tom, derfor skal vi først tømme it.To gør det, vi bør sikkerhedskopiere transaktionsloggen. Da vores” TestDB ” – database ernyligt oprettet, og der ikke er fulde sikkerhedskopier, har vi brug forat udstede en fuld databasebackup til TestDB-databasen, hvorefter vi kanudstede en transaktionslog 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'
transaktionsloggen backup afkorter logfilen (der er nogle undtagelser, som er uden for dette anvendelsesområde). Log trunkering sletter inaktive virtuelle logfiler frastart af den logiske log og frigiver plads i logfilen. Trunkering reducerer dog ikke størrelsen på en fysisk logfil. Det frigør kun plads i det, som kan genbruges. Lad os køre” DBCC LOGINFO ” igen:
som vi kan se, er der ingen virtuelle logfiler i “TestDB_log2.ldf ” fil med Status=2 og nu er vores logfil er tom og klar til fjernelse:
--Remove TestDB_log2 fileALTER DATABASE TestDB REMOVE FILE TestDB_log2
fjernelsen er vellykket.
men når vi tjekker log informationen igen, vil vi se, at den logiske logfil stadig eksisterer:
--Checking log informationSELECT file_id, name, type_desc, physical_name, size, max_sizeFROM sys.database_files
hvis vi laver en anden log-sikkerhedskopi, slettes filen:
--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
næste trin
- husk dette tip for at bestemme transaktionslogbrug og hvordan du fjerner en unødvendig logfil.
- tjek disse ressourcer:
- databaseadministration / transaktionslog
- https://technet.microsoft.com/en-us/library/ms191433(v=SL.105).asp
- https://technet.microsoft.com/en-us/library/ms179355(v=SL.105).asp
- https://technet.microsoft.com/en-us/library/ms345414(v=SL.105).asp
om forfatteren
Sergey Gigoyan er en database professionel med mere end 10 års erfaring, med fokus på database design, udvikling, performance tuning, optimering, høj tilgængelighed, BI og DV design.se alle mine tip
artikel sidst opdateret: 2015-11-18