Це, здається, є поширеним питанням на більшості форумів та в усьому Інтернеті, його тут задають у багатьох форматах, які зазвичай звучать так:

У SQL Server -

• З яких причин журнал транзакцій настільки великий?
• Чому мій файл журналу такий великий?
• Які існують способи запобігти виникненню цієї проблеми?
• Що робити, коли я приходжу себе вслід за основною причиною і хочу розмістити свій файл журналу транзакцій до здорового розміру?

Коротший відповідь:

Ви, мабуть, або маєте тривалу операцію (підтримка індексу? Велика партія видалення або оновлення?), Або ви перебуваєте в режимі відновлення за замовчуванням (докладніше нижче про те, що розуміється за замовчуванням), Fullі ви не взяли резервну копію журналу (або не приймає їх досить часто).

Якщо мова йде про модель відновлення, то простою відповіддю може стати перехід у Simpleрежим відновлення, якщо вам не потрібне відновлення часу та регулярне резервне копіювання журналу. Однак багато людей роблять це своєю відповіддю, не розуміючи моделей відновлення. Читайте далі, щоб зрозуміти, чому це важливо, а потім вирішіть, що робити. Ви також можете просто почати робити резервні копії журналу та залишатись у Fullвідновлення.

Можуть бути й інші причини, але вони є найпоширенішими. Ця відповідь починає занурюватися в найпоширеніші дві причини і дає вам деяку довідкову інформацію про те, чому і як слід стояти з цих причин, а також вивчає деякі інші причини.

Більш довгий відповідь: Які сценарії можуть спричинити зростання журналу? Причин багато, але зазвичай ці причини мають дві наступні схеми: Існує непорозуміння щодо моделей відновлення або є тривалі транзакції. Детальніше читайте далі.

Основна причина 1/2: Нерозуміння моделей відновлення

( Перебуваючи в режимі повного відновлення та не беручи резервні копії журналу - це найпоширеніша причина - переважна більшість тих, хто відчуває цю проблему. )

Хоча ця відповідь не є глибоким зануренням у моделі відновлення SQL Server, тема відновлення має вирішальне значення для цієї проблеми.

У SQL Server є три моделі відновлення :

• Full,
• Bulk-Logged і
• Simple.

Bulk-LoggedЗараз ми будемо ігнорувати, начебто скажемо, що це гібридна модель, і більшість людей, які перебувають у цій моделі, знаходяться з причиною і розуміють моделі відновлення.

Два ми піклуємося про і їх сплутаність є причиною більшості випадків , коли люди , які мають цю проблему є Simpleі Full.

Антракт: відновлення в цілому

Перш ніж ми поговоримо про моделі відновлення: поговоримо про відновлення загалом. Якщо ви хочете ще глибше зайнятися цією темою, просто прочитайте блог Пола Рандала та стільки публікацій на ньому, скільки вам потрібно. Щодо цього питання:

1. Відновлення
   після збоїв / перезапуску Однією з цілей файлу журналу транзакцій є відновлення аварії / перезавантаження . Для прокатки вперед та відкочування роботи, яка була виконана (відкат вперед / повтор) перед збоєм або перезапуск, і робота, яка була розпочата, але не закінчена після аварії або перезавантаження (відкат назад / скасування). Завдання журналу транзакцій полягає в тому, щоб перевірити, що транзакція розпочалася, але ніколи не закінчилася (відкат або збої / перезавантаження відбулися до здійснення транзакції). У цій ситуації завдання журналу сказати "Ей, це справді ніколи не закінчилось, давайте повернемо його назад" під час відновлення. Завдання журналу також полягає в тому, щоб побачити, що ви щось закінчили, і що ваша клієнтська програма сказала, що вона закінчена (навіть якщо вона ще не затверділа у вашому файлі даних) і сказати"Гей .. це справді сталося, давайте прокрутимо його вперед, давайте зробимо так, як програми думають, що це було" після перезавантаження. Зараз є більше, але це головна мета.

2. Точка відновлення часу
   Інша мета файлу журналу транзакцій - це можливість надати нам можливість відновитись до певного моменту завдяки «ой» у базі даних або гарантувати точку відновлення у разі відмови обладнання. із залученням даних та / або файлів журналу бази даних. Якщо цей журнал транзакцій містить записи трансакцій, розпочатих і закінчених для відновлення, SQL Server може і робить цю інформацію, щоб отримати базу даних, де вона була до того, як сталася проблема. Але це не завжди доступний варіант для нас. Для цього нам потрібно мати нашу базу даних у правильній моделі відновлення , і ми повинні робити резервні копії журналу .

Моделі відновлення

Для моделей відновлення:

• Проста модель відновлення
  Отже, з наведеним вище вступом найпростіше говорити про Simple Recoveryмодель спочатку. У цій моделі ви говорите на SQL Server: "Я добре з вами, використовуючи файл журналу транзакцій для аварійного завершення та відновлення відновлення ..." (у вас дійсно немає вибору. Знайдіть властивості ACID, і це має мати сенс швидко.) "... але як тільки вам це більше не знадобиться для цієї мети відновлення / перезавантаження, продовжуйте і повторно використовуйте файл журналу."

  SQL Server прослуховує цей запит у простому відновленні, і він зберігає лише інформацію, необхідну для відновлення / відновлення відновлення. Після того, як SQL Server впевнений, що він може відновитись, оскільки дані загартовані у файл даних (більш-менш), загартовані дані більше не потрібні в журналі та позначаються для усікання - це означає, що він повторно використовується.

• Модель повного відновлення
  З Full Recovery, ви говорите SQL Server, що ви хочете мати можливість відновитись до певного моменту, доки ваш файл журналу буде доступний або до певного моменту часу, який охоплюється резервною копією журналу. У цьому випадку, коли SQL Server досягне того пункту, коли було б безпечно усікати файл журналу у Простій моделі відновлення, він цього не зробить. Натомість це дозволяє файлу журналу продовжувати зростати, і дозволить йому продовжувати зростати, поки ви не візьмете резервну копію журналу (або не вистачає місця на диску файлу журналу) за звичайних обставин.

Перехід від простого до повного має Gotcha.

Тут є правила та винятки. Нижче ми поговоримо про довгострокові операції.

Але одне застереження, яке слід пам’ятати для режиму повного відновлення, це таке: якщо ви просто переходите в Full Recoveryрежим, але ніколи не приймаєте початкове повне резервне копіювання, SQL Server не буде задовольняти ваш запит бути в Full Recoveryмоделі. Ваш журнал транзакцій буде продовжувати працювати так, як він є, Simpleпоки ви не перейдете на модель повного відновлення І не приймете першу Full Backup.

Повна модель відновлення без резервного копіювання журналу погана.

Отже, це найпоширеніша причина неконтрольованого росту журналів? Відповідь: Перебуваючи в режимі повного відновлення без резервного копіювання журналу.

Це відбувається все час для людей.

Чому це така поширена помилка?

Чому це відбувається постійно? Оскільки кожна нова база даних отримує початкові налаштування моделі відновлення, переглядаючи базу даних моделі.

Початкові налаштування моделі відновлення моделі завжди Full Recovery Model- до тих пір, поки хтось цього не змінить. Тож можна сказати, що "модель відновлення за замовчуванням" є Full. Багато людей цього не знають, і їх бази даних працюють Full Recovery Modelбез резервного копіювання журналу, а тому файл журналу транзакцій набагато більший, ніж потрібно. Ось чому важливо змінити типові налаштування, коли вони не працюють для вашої організації та її потреб)

Повна модель відновлення з занадто малою кількістю резервних копій журналу погана.

Ви також можете потрапити в цю проблему, не роблячи резервні копії журналів досить часто.
Щоденне резервне копіювання журналу може здатися прекрасним, для його відновлення потрібні менші команди відновлення, але маючи на увазі обговорення вище, цей файл журналу буде продовжувати рости та рости, поки ви не зробите резервні копії журналу.

Як дізнатися, яка частота резервного копіювання журналу мені потрібна?

Потрібно врахувати частоту резервного копіювання журналу, враховуючи дві речі:

1. Потреби у відновленні - сподіваємось, це буде першим. Якщо диск, у якому розміщено ваш журнал транзакцій, виходить поганим або ви отримаєте серйозну пошкодження, що впливає на резервну копію журналу, скільки даних можна втратити? Якщо це число не більше 10-15 хвилин, тоді потрібно робити кодування журналу кожні 10-15 хвилин, закінчуючи обговорення.
2. Зростання журналу - якщо вашій організації нормально втрачати більше даних через можливість легко відтворити в цей день, можливо, вам доведеться робити резервну копію журналу набагато рідше, ніж 15 хвилин. Можливо, ваша організація прекрасна кожні 4 години. Але ви повинні подивитися, скільки транзакцій ви генеруєте за 4 години. Чи дозволить журналу продовжувати зростати протягом цих чотирьох годин зробити занадто великим файл журналу? Чи це означатиме, що резервне копіювання журналу займе занадто довго?

Основна причина 2/2: тривалі операції

( "Моя модель відновлення нормальна! Журнал все ще зростає! )

Це також може бути причиною неконтрольованого та нестримного росту журналів. Незалежно від моделі відновлення, але вона часто виникає як "Але я в простій моделі відновлення - чому мій журнал все ще зростає ?!"

Причина тут проста: якщо SQL використовує цей журнал транзакцій для цілей відновлення, як я описав вище, то він повинен повернутися до початку транзакції.

Якщо у вас є транзакція, яка займає тривалий час або вносить багато змін, журнал не може скоротити контрольну точку для будь-яких змін, які все ще є у відкритих транзакціях або які почалися з моменту початку цієї транзакції.

Це означає, що велике видалення, видалення мільйонів рядків в одному операторі видалення - це одна транзакція, і журнал не може робити жодного обрізання, поки все це видалення не буде виконано. У Full Recovery Modelцьому видаленні записується в журнал, і це може бути багато записів журналу. Те ж саме і з роботою з оптимізації індексів під час вікон технічного обслуговування. Це також означає, що погане управління транзакціями, а також не нагляд за закритими відкритими транзакціями, можуть дійсно нашкодити вам та вашому файлу журналу.

Що я можу зробити щодо цих тривалих операцій?

Ви можете зберегти себе тут:

• Належне розмір файлу журналу для врахування найгіршого сценарію - наприклад, обслуговування або відомих великих операцій. І коли ви росте файл журналу, вам слід звернутися до цього керівництва (і двох посилань, на які вона вас надсилає) Кімберлі Тріпп. Правильний розмір тут дуже критичний.
• Спостереження за використанням транзакцій. Не запускайте трансакцію на своєму сервері додатків і не починайте тривалих розмов із SQL сервером і ризикуйте занадто довго залишати один відкритим.
• Перегляд мається на увазі транзакцій у ваших операторах DML. Наприклад: UPDATE TableName Set Col1 = 'New Value'це транзакція. Я не ставив BEGIN TRANтуди і не потрібно, це все одно одна транзакція, яка автоматично автоматично вчиняється після завершення. Тож якщо ви робите операції з великою кількістю рядків, розгляньте можливість складання цих операцій у більш керовані шматки та надання часу журналу для відновлення. Або розглянути правильний розмір, щоб впоратися з цим. Або, можливо, вивчіть зміни моделей відновлення під час вікна масового завантаження.

Чи застосовуються ці дві причини для доставки журналів?

Коротка відповідь: так. Більш довга відповідь нижче.

Питання: "Я використовую доставку журналів, тому резервні копії журналів автоматизовані ... Чому я все ще спостерігаю зростання журналу транзакцій?"

Відповідь: читайте далі.

Що таке доставка журналів?

Доставка журналів - це саме те, що звучить - ви доставляєте резервні копії журналу транзакцій на інший сервер для цілей DR. Існує деяка ініціалізація, але після цього процес є досить простим:

• Завдання для резервного копіювання журналу на одному сервері,
• завдання скопіювати резервну копію цього журналу та
• завдання відновити його без відновлення ( NORECOVERYабо на STANDBY) на сервері призначення.

Є також деякі завдання для моніторингу та оповіщення, якщо все не піде так, як ви планували.

У деяких випадках ви можете зробити відновлення доставки журналу лише раз на день або кожен третій день або раз на тиждень. Це добре. Але якщо ви внесете цю зміну у всі завдання (включаючи резервне копіювання журналу та завдання копіювання), це означає, що ви весь цей час чекаєте, щоб зробити резервну копію журналу. Це означає, що у вас буде великий ріст журналу - оскільки ви перебуваєте в повному режимі відновлення без резервного копіювання журналу - і це, ймовірно, також означає великий файл журналу, який потрібно копіювати поперек. Вам слід лише змінити графік завдання відновлення та дозволити частіші резервні копії та копії журналу, інакше ви постраждаєте від першого питання, описаного в цій відповіді.

Загальне усунення несправностей за допомогою кодів статусу

Існують і інші причини, крім цих двох, але вони є найпоширенішими. Незалежно від причини: є спосіб проаналізувати свою причину цього незрозумілого зростання колоди / відсутності вкорочення та побачити, що вони є.

Запитуючи подання sys.databasesкаталогу, ви можете побачити інформацію, яка описує причину, за якою ваш файл журналу може чекати під час скорочення / повторного використання.

Існує стовпець, що викликається log_reuse_waitідентифікатором пошуку коду причини, і log_reuse_wait_descстовпець з описом причини очікування. З онлайн-статті, в якій посилаються книги, є більшість причин (ті, які ви, швидше за все, бачите, і ті, з яких ми можемо пояснити причини. Зниклі з них відсутні або використовуються, або для внутрішнього користування) з кількома примітками про очікування в курсивом :

• 0 = Нічого
  Як це звучить .. Не слід чекати

• 1 = Контрольна точка
  Очікування появи пункту пропуску. Це має статися, і вам слід добре, але є деякі випадки, щоб шукати тут відповіді чи зміни.

• 2 = Резервне копіювання журналу
  Ви очікуєте резервного копіювання журналу. Або у вас їх заплановано, і це станеться незабаром, або у вас є перша описана тут проблема, і тепер ви знаєте, як її виправити

• 3 = Активне резервне копіювання або відновлення
  На базі даних виконується операція резервного копіювання або відновлення

• 4 = Активна транзакція
  Існує активна транзакція, яку потрібно виконати (в будь-якому випадку - ROLLBACKабо COMMIT), перш ніж журнал може бути створений резервним копієм. Це друга причина, описана у цій відповіді.

• 5 = Дзеркальне відображення бази даних
  Або дзеркало затримується, або затримується певна затримка у високоефективній дзеркальній ситуації, або дзеркальне відображення призупинено з якихось причин

• 6 = Реплікація
  Можуть виникнути проблеми з реплікацією, які спричинили б це - як агент зчитування журналів журналів не працює, а база даних думає, що це позначено для реплікації, якої більше немає, та інші інші причини. Ви також можете побачити цю причину, і це цілком нормально, тому що ви дивитесь в потрібний час так само, як транзакції споживаються зчитувачем журналів

• 7 = Створення знімка бази даних
  Ви створюєте знімок бази даних, це ви побачите, якщо ви дивитесь лише в потрібний момент, коли створюється знімок

• 8 = Сканування журналу.
  Мені ще не вдається зіткнутися з проблемою, з якою ця робота працює вічно. Якщо ви виглядаєте досить довго і досить часто, ви можете бачити це, але це не повинно бути причиною надмірного зростання журналу транзакцій, як я бачив.

• 9 = Вторинна репліка AlwaysOn груп доступності застосовує записи журналу транзакцій цієї бази даних до відповідної вторинної бази даних. Про найясніший опис поки що ..

Оскільки я не дуже задоволений жодною з відповідей на стек-переповнення , включаючи найбільш голосову пропозицію, і оскільки є кілька речей, які я хотів би вирішити, що відповідь Майка не відповідає, я подумав, що надам мій внесок і тут. Я також розмістив там копію цієї відповіді.

Зменшення файлу журналу дійсно має бути зарезервоване для сценаріїв, коли він стикався з несподіваним зростанням, який ви не очікуєте, що це повториться Якщо файл журналу знову зросте до того ж розміру, тимчасовим зменшенням його не дуже багато. Тепер, залежно від цілей відновлення вашої бази даних, це ті дії, які слід вжити.

Спочатку візьміть повну резервну копію

Ніколи не вносьте жодних змін у свою базу даних, не гарантуючи, що ви можете відновити її, якщо щось піде не так.

Якщо ви переймаєтесь тимчасовим відновленням

(І під час відновлення я маю на увазі, що ви дбаєте про можливість відновити все, крім повного або диференціального резервного копіювання.)

Імовірно, ваша база даних знаходиться в FULLрежимі відновлення. Якщо ні, то переконайтесь, що це:

ALTER DATABASE yourdb SET RECOVERY FULL;

Навіть якщо ви робите регулярні повні резервні копії, файл журналу буде рости і рости, поки ви не зробите резервну копію журналу - це для вашої захисту, щоб не зайве їсти на своєму диску. Ви повинні виконувати ці резервні копії журналу досить часто, відповідно до цілей відновлення. Наприклад, якщо у вас є ділове правило, яке стверджує, що ви можете дозволити собі втратити не менше 15 хвилин даних у випадку катастрофи, у вас має бути робота, яка робить резервне копіювання журналу кожні 15 хвилин. Ось сценарій, який генеруватиме назви файлів із часовим позначенням, залежно від поточного часу (але ви також можете це зробити з планами технічного обслуговування тощо. Просто не вибирайте жодного зі скорочень у планах технічного обслуговування, вони жахливі).

DECLARE @path NVARCHAR(255) = N'\\backup_share\log\yourdb_' 
  + 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 yourdb 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
-- 200 MB
DBCC SHRINKFILE(yourdb_log, 200);
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 році, коли побачив декілька публікацій "ось як зменшити файл журналу", з’являються .

• Запис у блозі Brent Ozar написав чотири роки тому, вказуючи на кілька ресурсів, у відповідь на статтю журналу SQL Server, яка не повинна була публікуватися .

• Повідомлення в блозі Пола Рандала, в якому роз'яснюється, чому важливо обслуговування t-log і чому також не слід зменшувати файли даних .

• Майк Уолш має чудову відповідь вище, звичайно, також висвітлює деякі з цих аспектів, включаючи причини, через які ви не зможете негайно зменшити файл журналу .

Ви також можете бачити вміст файлу журналу. Для цього можна використовувати незадокументований fn_dblogабо зчитувач журналу транзакцій, наприклад ApexSQL Log .

Вона не показує індекс реорганізації, але він показує все DML і DDL різні події: ALTER, CREATE, DROP, тригер включення / вимикання, даруй / скасувати дозволи, об'єкт перейменування.

Відмова від відповідальності: Я працюю в ApexSQL як інженер підтримки

Це найчастіше зустрічається питання майже для всіх DBA, де журнали ростуть і заповнюють диск.

• З яких причин журнал транзакцій стає таким великим?

1. Тривала активна транзакція
2. Операції з високим протоколом журналу, такі як перебудова індексу, переорганізація, масове вставлення, видалення тощо.
3. Будь-який HA, як Replication, Mirroring, налаштований таким чином, що містить журнал і не дозволяє йому звільняти простір журналу

• Чому мій файл журналу такий великий?

Перевірте, чи log_reuse_wait_desстовпчик c в sys.databasesтаблиці знає, що утримує журнали від обрізки:

select name, log_reuse_wait_desc 
from sys.databases

• Які способи запобігти виникненню цієї проблеми?

Резервні копії журналу допоможуть вам контролювати ріст журналу, якщо не буде щось, що затримує журнали від повторного використання.

• Що мені робити, коли я переходжу на слід із основної причини і хочу привести файл журналу транзакцій до здорового розміру?

Якщо ви виявили, що насправді викликає це, то спробуйте виправити це відповідно, як пояснено нижче на сторінці.

https://www.brentozar.com/archive/2016/03/my-favorite-system-column-log_reuse_wait_desc/

Заплановані належні резервні копії журналу - це найкращий спосіб вирішити ріст журналу, якщо не виникає незвична ситуація.