Як найкраще підтримувати розміри файлів журналу SQL

Я дещо новий DBA, і я керую екземпляром SQL Server 2012, який має неабияку активність. Я працюю в режимі повного відновлення, тому що нам потрібен момент відновлення.

Зараз я беру повне резервне копіювання баз даних і журналів щодня о 5 ранку. Деякі файли журналів мають розмір до 300 Гб, і навіть після створення резервної копії вони не зменшуються в розмірі. Я можу змусити їх зменшити розмір, запустивши щось подібне до:

BACKUP LOG db1 TO DISK = '\\server\share\db1_log1.trn';
DBCC ShrinkFile([db1_log], 0);

BACKUP LOG db1 TO DISK = '\\server\share\db1_log2.trn';
DBCC ShrinkFile([db1_log], 0);

BACKUP LOG db1 TO DISK = '\\server\share\db1_log3.trn';
DBCC ShrinkFile([db1_log], 0);

Коли я перевіряю LSN-файли резервних файлів, я бачу щось подібне:

RESTORE headeronly FROM DISK = N'\\server\share\db1_log1.trn'
FirstLSN:  15781000014686200001
SecondLSN: 15802000000665000001

RESTORE headeronly FROM DISK = N'\\server\share\db1_log2.trn'
FirstLSN:  15802000000665000001
SecondLSN: 15805000000004100001

RESTORE headeronly FROM DISK = N'\\server\share\db1_log3.trn'
FirstLSN:  15805000000004100001
SecondLSN: 15808000000004200001

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

Запитання:

1. Чому файл журналу не скорочується після резервного копіювання? Це тому, що є незареєстровані транзакції?
2. Спочатку я думав, що я повинен скорочувати файли журналів після кожного резервного копіювання о 5:00. Прочитавши, як це погано для продуктивності, тепер я вважаю, що мені потрібно регулярно робити резервні копії журналу кожні пару годин протягом дня. Це правильно?
3. Моє звичайне повне резервне копіювання бази даних / журналів відбувається щодня о 5:00 ранку і іноді займає 3 години. Якщо я запланую резервування резервних копій журналу щогодини, що буде, коли резервна копія журналу зіткнеться із резервною копією о 5:00?

1. Чому файл журналу не скорочується після резервного копіювання? Це тому, що є незареєстровані транзакції?

Фактичний файл журналу NTFS не «зменшується» від резервного копіювання журналу транзакцій, проте VLF (віртуальні файли журналу) у журналі транзакцій позначені для повторного використання (тому що вони тепер резервні копії та зберігаються на носіях), що дозволяє обгортати трапляється використання журналу транзакцій. Якщо ви не створюєте резервну копію журналу транзакцій або недостатньо часто, то не буде доступних VLF, і це призведе до зростання журналу транзакцій (за умови встановлення автоматичного зростання) для розміщення додаткових записів журналу транзакцій.

2. Спочатку я думав, що я повинен скорочувати файли журналів після кожного резервного копіювання 5:00 ранку. Прочитавши, як це погано для продуктивності, тепер я вважаю, що мені потрібно регулярно робити резервні копії журналу кожні пару годин протягом дня. Це правильно?

Звичайне та заплановане зменшення файлів - це не дуже гарна ідея. Тільки тоді, коли вам потрібно зайняти необхідний простір, ви повинні врахувати DBCC SHINKFILE. Крім того, коли ви постійно робите журнал транзакцій, ви можете заважати іншим речам, таким як відновлення бази даних. Занадто багато VLF-файлів у журналі транзакцій (поширена проблема, коли журнал транзакцій вирощується лише невеликим приростом сховища), час на відновлення бази даних може бути більшим, ніж бажано.

3. Моє звичайне повне резервне копіювання бази даних / журналів відбувається щодня о 5:00 ранку, а іноді займає 3 години. Якщо я запланую резервування резервних копій журналу щогодини, що буде, коли резервна копія журналу зіткнеться із резервною копією о 5:00?

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

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

Документація TechNet про усічення журналу транзакцій

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

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

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

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

1. створити резервну копію поточного файлу журналу.

2. Встановіть вашу базу даних для простого відновлення

   • Becasue у повному відновленні -> Файл журналу не видаляє здійснену транзакцію, він лише переупорядкує ваші дані -> Файл Shink не сильно впливає -> і навпаки для простого відновлення.

3. Збільшити файл журналу до 1 Мб або менше (це залежить від вас)

4. Поверніть базу даних до повного відновлення.

Сподіваюся, це допоможе

Фонг Тран