Зменшення файлу журналу дійсно має бути зарезервоване для сценаріїв, коли він зіткнувся з несподіваним зростанням, який ви не очікуєте, що це повториться. Якщо файл журналу знову зросте до того ж розміру, тимчасовим зменшенням його не дуже багато. Тепер, залежно від цілей відновлення вашої бази даних, це ті дії, які ви повинні вжити.
Спочатку візьміть повну резервну копію
Ніколи не вносити жодних змін у вашу базу даних, не гарантуючи, що ви можете відновити її, якщо щось піде не так.
Якщо ви переймаєтесь тимчасовим відновленням
(І під час відновлення, я маю на увазі, що ви дбаєте про можливість відновити все, крім повного або диференціального резервного копіювання.)
Імовірно, ваша база даних знаходиться в 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 Мб - навіть якщо ви часто створюєте резервну копію журналу, він все одно повинен вміщувати суму будь-яких одночасних транзакцій, які можуть статися. Події автоматичного зростання файлів журналу дорогі, оскільки SQL Server має нульові файли (на відміну від файлів даних, коли миттєва ініціалізація файлів увімкнена), і трансакціям користувача доводиться чекати, поки це станеться. Ви хочете зробити цю процедуру рости-скорочуватися-зростати-скорочуватися якомога менше, і ви, звичайно, не хочете, щоб ваші користувачі платили за це.
Зауважте, що вам може знадобитися зробити резервну копію журналу двічі, перш ніж можлива стискання (дякую Роберту).
Отже, вам потрібно придумати практичний розмір для вашого журнального файлу. Ніхто тут не може сказати вам, що це, не знаючи більше про вашу систему, але якщо ви часто скорочуєте файл журналу, і він знову зростає, хороший водяний знак, напевно, на 10-50% вище, ніж найбільший . Скажімо, що доходить до 200 МБ, і ви хочете, щоб усі наступні події автоматичного зростання становили 50 Мб, тоді ви можете налаштувати розмір файлу журналу таким чином:
USE [master];
GO
ALTER DATABASE Test1
MODIFY FILE
(NAME = yourdb_log, SIZE = 200MB, FILEGROWTH = 50MB);
GO
Зауважте, що якщо файл журналу наразі> 200 Мб, вам може знадобитися запустити цей перший:
USE yourdb;
GO
DBCC SHRINKFILE(yourdb_log, 200);
GO
Якщо ви не переймаєтесь тимчасовим відновленням
Якщо це тестова база даних, і ви не переймаєтесь тимчасовим відновленням, вам слід переконатися, що ваша база даних перебуває в SIMPLEрежимі відновлення.
ALTER DATABASE testdb SET RECOVERY SIMPLE;
Якщо перевести базу даних у SIMPLEрежим відновлення, переконайтесь, що SQL Server повторно використовує частини файлу журналу (фактично припиняючи неактивні транзакції), а не зростаючи, щоб вести облік усіх транзакцій (як, наприклад, FULLвідновлення, поки ви не створюєте резервну копію журналу). CHECKPOINTподії допоможуть контролювати журнал і переконайтеся, що його не потрібно рости, якщо ви не генеруєте багато активності t-log між CHECKPOINTs.
Далі слід переконатися, що цей приріст журналу був справді обумовлений ненормальною подією (скажімо, щорічною весняною чисткою чи перебудовою ваших найбільших показників), а не завдяки звичайному, щоденному використанню. Якщо ви зменшите файл журналу до смішно невеликого розміру, а 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 Мб . Це виглядає заманливо, тому що, ей, SQL Server дозволить мені це робити за певними сценаріями, і переглядати весь простір, який він звільняє! Якщо ваша база даних не буде прочитана тільки (і це, ви повинні позначити її як таку, використовуючи ALTER DATABASE), це абсолютно просто призведе до багатьох непотрібних подій зростання, оскільки журнал повинен вміщувати поточні транзакції незалежно від моделі відновлення. Який сенс звільнити цей простір тимчасово, лише щоб SQL Server міг повернути його повільно і болісно?
Створіть другий файл журналу . Це забезпечить тимчасове полегшення для накопичувача, який заповнив ваш диск, але це як намагання виправити проколоте легенею за допомогою смуги. Ви повинні мати справу з проблемним файлом журналу безпосередньо, а не просто додавати ще одну потенційну проблему. Окрім перенаправлення деякої активності журналу транзакцій на інший диск, другий файл журналу дійсно нічого не робить для вас (на відміну від другого файлу даних), оскільки одночасно можна використовувати лише один із файлів. Пол Рандал також пояснює, чому кілька файлів журналів можуть вас кусати пізніше .
Будьте ініціативними
Замість того, щоб скоротити ваш журнальний файл до деякої невеликої кількості і не дозволяти йому постійно автоматично рости з невеликою швидкістю самостійно, встановіть його на досить розумний розмір (той, який вмістить суму вашого найбільшого набору одночасних транзакцій) і встановіть розумне автоматичне зростання встановлення як резервний, так що не потрібно збільшуватись у кілька разів, щоб задовольнити окремі транзакції, і таким чином буде відносно рідко колись доводиться рости протягом звичайних бізнес-операцій.
Найгірші можливі налаштування тут - 1 Мб зростання або 10% зростання. Досить смішно, це типові налаштування для SQL Server (на які я скаржився і просив зміни безрезультатно ) - 1 Мб для файлів даних і 10% для файлів журналів. Перший у цей день і вік набагато малий, а останній щоразу призводить до більш тривалих подій (скажімо, ваш журнальний файл - 500 МБ, перший зростання - 50 МБ, наступний - 55 МБ, наступний - 60,5 МБ і т. д. і т. д. - і на повільному вводу / виводу, повірте, ви дійсно помітите цю криву).
Подальше читання
Будь ласка, не зупиняйтесь тут; хоча велика частина порад щодо скорочення файлів журналів по суті є поганою і навіть потенційно згубною, є деякі люди, які більше дбають про цілісність даних, ніж звільнення місця на диску.
Повідомлення в блозі, яке я писав у 2009 році, коли побачив декілька публікацій "ось як зменшити файл журналу", з’являються .
Запис у блозі Брент Озар написав чотири роки тому, вказуючи на декілька ресурсів, у відповідь на статтю журналу SQL Server, яка не повинна була публікуватися .
Повідомлення в блозі Пола Рандала, в якому пояснюється, чому важливо обслуговування t-log і чому також не слід зменшувати файли даних .
У Майка Уолша є чудова відповідь, яка охоплює також деякі з цих аспектів, включаючи причини, через які ви не зможете негайно зменшити файл журналу .
