av: Sergey Gigoyan | uppdaterad: 2015-11-18 | kommentarer (9) | relaterat: mer > databasadministration
Problem
SQL Server tillåter att använda mer än en transaktionsloggfil, men frågan uppstår om det är nödvändigtoch vad är fördelen med att ha flera transaktionsloggfiler. Det finns en missuppfattning bland vissa utvecklare som har fleratransaction loggfiler kan öka prestanda eftersom SQL Server kan använda dem parallellt. SQL Server använderbara en transaktionsloggfil för tillfället och det finns ingen parallellitet i det här fallet. Ibland kan mer än en loggfil varabehövs för felsökning. Så normalt är det inte nödvändigt att ha mer än en loggfil.Låt oss betrakta ett fall, när vår databas har mer än en loggfil och vi bör behålla endast en.Detta tips syftar till att beskriva hur man tar bort onödiga loggfiler korrekt och behåller bara en.
lösning
innan vi börjar illustrera hur man tar bort onödiga loggfiler, låt oss kort beskriva hur SQL Server fungerarmed loggfiler: när databasen har mer än en loggfil fortsätter SQL Server att skriva till den första tills den är full, växlar sedan till den andra och så vidare. Efter den sista loggfilen blir full SQL Server återgår tillbaka till den första och cykeln fortsätter.Men som vi nämnde kan ibland mer än en loggfil krävas. Till exempel när skivan, där loggfilen är belägenblir full och vi måste skapa den andra loggfilen på en annan plats, men efter felsökning av problemet bör vi ta bort den andra loggfilen,eftersom det inte går att ha mer än en loggfil.Låt oss nu anta att vi har en databas med två loggfiler, och vår uppgift är att ta bort den andra.Följande skript skapar TestDB databas med två loggfiler och TestTable tabell. För att köra det själv måste du byta ut”D:\SQL Data” med en befintlig mappväg.
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
låt oss nu förstå transaktionsloggens fysiska struktur: internt transaktionsloggfil består avvirtuella loggfiler (VLF), som är hanteringsenheten i transaktionsloggfilen. Det betyder att när databasmotorn växer eller krymper loggfilen gör den det med kompletta VLF: er (till exempel kan den inte krympa hälften av VLF). Storleken på virtuella loggfiler såväl som deras nummer i den fysiska loggfilen är inte fast och hanteras dynamiskt av databasmotorn. Att övervakatransaktionsloggfilen interntvi använder kommandot ”DBCC LOGINFO”, som ger information om virtuella loggfiler. I skriptet nedan använde vi detta kommando för vår databas:
--Getting log files infoDBCC LOGINFO('TestDB')
och resultatet är följande:
FileID är loggfil ID för vår databas. Status indikerar är VLF återanvändbara ornot (möjliga värden: 0 – ja, 2-Nej). Som vi kan se finns det bara en VLF medstatus=2. Nu när vi ska infoga data i Testtabellen och övervaka hur loggfiler växer:
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 det här exemplet kan vi se att båda loggfilerna växte och nu finns det VLF med ”Status = 2” i den andra loggfilen (FileID=3) också:
nu måste vi ta bort TestDB_log2.ldf-fil. Observera att vi bara kan ta bort de sekundära loggfilerna. Borttagningden primära loggfilen är inte tillåten av SQL Server.Varje databas har bara en primär loggfil och den första loggfilen som skapas i databasskapningsskriptet anses vara den primära.Om vi försöker ta bort den andra loggfilen:
USE masterGO--Remove TestDB_log2 fileALTER DATABASE TestDB REMOVE FILE TestDB_log2
vi kommer att få följande meddelande:
vi kan bara ta bort transaktionsloggfilen när den är tom, därför måste vi först tömma it.To gör det, vi bör säkerhetskopiera transaktionsloggen. Eftersom vår” TestDB ” – databas ärnyskapad och det finns inga fullständiga säkerhetskopior, behöver viatt utfärda en fullständig databasbackup för TestDB-databasen, varefter vi kanutfärda en transaktionsloggbackup:
--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 trunkerar loggfilen (det finns några undantag, som är utanför ramen för thistip). Loggavkortning tar bort inaktiva virtuella loggfiler frånstarten av den logiska loggen och släpper ut utrymme i loggfilen. Trunkering minskar dock inte storleken på en fysisk loggfil. Det frigör bara utrymme i det, vilket kan återanvändas. Låt oss köra ”DBCC LOGINFO” igen:
som vi kan se finns det inga virtuella loggfiler i ”TestDB_log2.ldf ” – fil med Status = 2 och nu är vår loggfil Tom och redo för borttagning:
--Remove TestDB_log2 fileALTER DATABASE TestDB REMOVE FILE TestDB_log2
avlägsnandet är framgångsrikt.
men när vi kontrollerar logga informationen igen ser vi att den logiska loggfilen fortfarande finns:
--Checking log informationSELECT file_id, name, type_desc, physical_name, size, max_sizeFROM sys.database_files
om vi gör en annan loggbackup kommer filen att raderas:
--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ästa steg
- håll detta tips i åtanke att bestämma transaktionslogg användning och hur man tar bort anunneeded loggfil.
- kolla in dessa resurser:
- databasadministration / transaktionslogg
- 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 författaren
Sergey Gigoyan är en databas professionell med mer än 10 års erfarenhet, med fokus på databasdesign, utveckling, prestanda tuning, optimering, hög tillgänglighet, BI och DW design.Visa alla mina tips
artikeln Senast uppdaterad: 2015-11-18