Намаляването на регистрационния файл наистина трябва да бъде запазено за сценарии, при които той срещна неочакван растеж, който не очаквате да се случи отново. Ако регистрационният файл отново нарасне до същия размер, не се постига много чрез временното му свиване. Сега, в зависимост от целите за възстановяване на вашата база данни, това са действията, които трябва да предприемете.
Първо, направете пълен архив
Никога не правете промени във вашата база данни, без да сте сигурни, че можете да я възстановите, ако нещо се обърка.
Ако ви е грижа за възстановяването в даден момент
(И под възстановяване в даден момент имам предвид, че ви е грижа за възможността да възстановите до нещо различно от пълно или диференциално архивиране.)
Вероятно вашата база данни е в FULL режим на възстановяване. Ако не, тогава се уверете, че е:
ALTER DATABASE testdb SET RECOVERY FULL;
Дори ако правите редовни пълни архиви, регистрационният файл ще нараства и расте, докато не извършите регистрационен файл резервно копие - това е за ваша защита, а не за излишно изяждане на вашето дисково пространство. Трябва да извършвате тези архивни копия на регистрационни файлове доста често, според вашите цели за възстановяване. Например, ако имате бизнес правило, което гласи, че можете да си позволите да загубите не повече от 15 минути данни в случай на бедствие, трябва да имате работа, която архивира дневника на всеки 15 минути. Ето скрипт, който ще генерира имена на файлове с времеви печат въз основа на текущото време (но можете да направите това и с планове за поддръжка и т.н., просто не избирайте нито една от опциите за свиване в плановете за поддръжка, те са ужасни).
DECLARE @path NVARCHAR(255) = N'\\backup_share\log\testdb_'
+ CONVERT(CHAR(8), GETDATE(), 112) + '_'
+ REPLACE(CONVERT(CHAR(8), GETDATE(), 108),':','')
+ '.trn';
BACKUP LOG foo TO DISK = @path WITH INIT, COMPRESSION;
Обърнете внимание, че \\backup_share\ трябва да е на различна машина, която представлява различно основно устройство за съхранение. Архивирането им на една и съща машина (или на друга машина, която използва същите подлежащи дискове, или различна VM, която е на същия физически хост) всъщност не ви помага, тъй като ако машината се взриви, вие сте загубили вашата база данни и неговите резервни копия. В зависимост от вашата мрежова инфраструктура може да има повече смисъл да архивирате локално и след това да ги прехвърлите на друго място зад кулисите; и в двата случая искате да ги извадите от основната машина за база данни възможно най-бързо.
Сега, след като стартирате редовно архивиране на регистрационни файлове, би трябвало да е разумно да свиете лог файла до нещо по-разумно от това, което е раздуван досега. Това не означава изпълняване на SHRINKFILE отново и отново, докато регистрационният файл стане 1 MB - дори ако архивирате дневника често, той все още трябва да побере сумата от всички едновременни транзакции, които могат да възникнат. Събитията за автоматично нарастване на регистрационните файлове са скъпи, тъй като SQL Server трябва да нулира файловете (за разлика от файловете с данни, когато е активирана незабавна инициализация на файл), а потребителските транзакции трябва да изчакат, докато това се случи. Искате да правите тази рутина за растеж-свиване-растване-свиване възможно най-малко и със сигурност не искате да карате потребителите си да плащат за това.
Имайте предвид, че може да се наложи да архивирате дневника два пъти, преди да е възможно свиване (благодаря Робърт).
Така че трябва да измислите практичен размер за вашия регистрационен файл. Никой тук не може да ви каже какво е това, без да знаете много повече за вашата система, но ако често сте свивали регистрационния файл и той отново нараства, добрият воден знак вероятно е 10-50% по-висок от най-големия, който е бил . Да приемем, че това е 200 MB и искате всички последващи събития за автоматично нарастване да бъдат 50 MB, тогава можете да регулирате размера на регистрационния файл по следния начин:
USE [master];
GO
ALTER DATABASE Test1
MODIFY FILE
(NAME = yourdb_log, SIZE = 200MB, FILEGROWTH = 50MB);
GO
Имайте предвид, че ако регистрационният файл в момента е> 200 MB, може да се наложи първо да стартирате това:
USE yourdb;
GO
DBCC SHRINKFILE(yourdb_log, 200);
GO
Ако не ви е грижа за възстановяването в даден момент
Ако това е тестова база данни и не ви пука за възстановяване в момента, тогава трябва да се уверите, че вашата база данни е в SIMPLE режим на възстановяване.
ALTER DATABASE testdb SET RECOVERY SIMPLE;
Поставяне на базата данни в SIMPLE режимът за възстановяване ще гарантира, че SQL Server използва повторно части от регистрационния файл (по същество постепенно премахва неактивните транзакции), вместо да нараства, за да поддържа запис на всички транзакции (като FULL възстановяването става, докато не архивирате дневника). CHECKPOINT събития ще ви помогнат да контролирате регистрационния файл и ще се уверите, че няма нужда да се увеличава, освен ако не генерирате много t-log активност между CHECKPOINT с.
След това трябва да се уверите, че този ръст на регистрационните файлове наистина се дължи на необичайно събитие (да речем, годишно пролетно почистване или възстановяване на най-големите ви индекси), а не на нормална ежедневна употреба. Ако свиете регистрационния файл до абсурдно малък размер и SQL Server просто трябва да го увеличи отново, за да побере нормалната ви дейност, какво спечелихте? Успяхте ли да използвате това дисково пространство, което освободихте само временно? Ако имате нужда от незабавна корекция, тогава можете да изпълните следното:
USE yourdb;
GO
CHECKPOINT;
GO
CHECKPOINT; -- run twice to ensure file wrap-around
GO
DBCC SHRINKFILE(yourdb_log, 200); -- unit is set in MBs
GO
В противен случай задайте подходящ размер и темп на растеж. Съгласно примера в случая за възстановяване в момента, можете да използвате същия код и логика, за да определите какъв размер на файла е подходящ и да зададете разумни параметри за автоматично нарастване.
Някои неща, които не искате да правите
-
Архивирайте регистрационния файл с
TRUNCATE_ONLYопция и след товаSHRINKFILE. От една страна, товаTRUNCATE_ONLYопцията е отхвърлена и вече не е налична в текущите версии на SQL Server. Второ, ако сте вFULLмодел за възстановяване, това ще унищожи веригата ви от регистрационни файлове и ще изисква нов, пълен архив. -
Отделете базата данни, изтрийте регистрационния файл и го прикачете отново . Не мога да подчертая колко опасно може да бъде това. Вашата база данни може да не се върне, може да се появи като подозрителна, може да се наложи да се върнете към резервно копие (ако имате такъв) и т.н. и т.н.
-
Използвайте опцията „свиване на база данни“ .
DBCC SHRINKDATABASEи опцията за план за поддръжка, за да направите същото, са лоши идеи, особено ако наистина трябва само да разрешите проблем с регистрационния файл. Насочете файла, който искате да коригирате, и го коригирайте независимо, като използватеDBCC SHRINKFILEилиALTER DATABASE ... MODIFY FILE(примери по-горе). -
Намалете регистрационния файл до 1 MB . Това изглежда примамливо, защото, хей, SQL Server ще ми позволи да го направя в определени сценарии и ще погледна цялото пространство, което освобождава! Освен ако вашата база данни не е само за четене (а е, трябва да я маркирате като такава с помощта на
ALTER DATABASE), това абсолютно просто ще доведе до много ненужни събития за растеж, тъй като дневникът трябва да побере текущите транзакции, независимо от модела за възстановяване. Какъв е смисълът да се освободи това пространство временно, само за да може SQL Server да го върне бавно и болезнено? -
Създайте втори регистрационен файл . Това ще осигури временно облекчение за устройството, което е запълнило вашия диск, но това е като да се опитвате да поправите пробит бял дроб с лейкопласт. Трябва да се справите директно с проблемния регистрационен файл, вместо просто да добавяте друг потенциален проблем. Освен пренасочването на някаква дейност в регистъра на транзакциите към друго устройство, вторият регистрационен файл наистина не прави нищо за вас (за разлика от втория файл с данни), тъй като само един от файловете може да се използва в даден момент. Пол Рандал също обяснява защо множество регистрационни файлове могат да ви ухапят по-късно.
Бъдете проактивни
Вместо да свивате регистрационния си файл до малко количество и да го оставяте постоянно да нараства автоматично с малка скорост самостоятелно, задайте го на някакъв разумно голям размер (който ще побере сумата от най-големия ви набор от едновременни транзакции) и задайте разумно автоматично нарастване задаване като резервен вариант, така че да не се налага да нараства многократно, за да удовлетвори единични транзакции, и така че ще бъде сравнително рядко някога да се налага да нараства по време на нормални бизнес операции.
Най-лошите възможни настройки тук са ръст от 1 MB или ръст от 10%. Колкото и да е смешно, това са настройките по подразбиране за SQL Server (от които се оплаках и поисках промени без резултат) - 1 MB за файлове с данни и 10% за регистрационни файлове. Първият е твърде малък в днешно време, а вторият води до по-дълги и по-дълги събития всеки път (да речем, вашият регистрационен файл е 500 MB, първият растеж е 50 MB, следващият растеж е 55 MB, следващият растеж е 60,5 MB и т.н. и т.н. - и при бавен I/O, повярвайте ми, наистина ще забележите тази крива).
Допълнително четене
Моля, не спирайте до тук; докато голяма част от съветите, които виждате там за свиване на регистрационните файлове, са по своята същност лоши и дори потенциално катастрофални, има някои хора, които се интересуват повече от целостта на данните, отколкото да освобождават дисково пространство.
Публикация в блог, която написах през 2009 г., когато видях, че се появяват няколко публикации „ето как да свиете регистрационния файл“.
Публикация в блог, написана от Брент Озар преди четири години, посочвайки множество ресурси, в отговор на статия от SQL Server Magazine, която не са публикувани.
Публикация в блог от Пол Рандъл, обясняваща защо поддръжката на t-log е важна и защо не трябва да свивате и файловете си с данни.
Майк Уолш има страхотен отговор, който обхваща и някои от тези аспекти, включително причините, поради които може да не сте в състояние незабавно да свиете регистрационния си файл.
