Як скорочення файлу журналу SQL Server впливає на продуктивність?

У мене база даних SQL Server 2008, яка має файл даних розміром приблизно 2 Гб, але файл журналу перевищує 8 ГБ. У базах даних до 2008 року я міг би використовувати "Журнал резервного копіювання" та TRUNCATE_ONLYпараметр, але це більше не доступно для баз даних 2008 та пізніших.

У мене є сценарій, який обрізає файл журналу:

USE [MyDatabase]
GO
ALTER DATABASE [MyDatabase] SET RECOVERY SIMPLE WITH NO_WAIT
DBCC shrinkfile('MyDatabase_log', 1)
ALTER DATABASE [MyDatabase] SET RECOVERY FULL WITH NO_WAIT
GO

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

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

Я дуже рекомендую прочитати Важливість правильного керування розмірами журналу транзакцій Пол С. Рандал.

Важливістю є те, що є лише два дійсно хороших способи зробити обробку журналу транзакцій :

1. Будьте перейдіть із звичайними резервними копіями файлів LOG, і файл LOG повторно використовуватиме простір після кожної резервної копії LOG і не зростатиме на невизначений час

2. Використовуйте просту модель відновлення, і вам не потрібно піклуватися про розмір файлу LOG, оскільки ви робите регулярні повні резервні копії.

Що стосується усічення та продуктивності файлів LOG, це те, що ви завжди отримуватимете ефективність при збільшенні файлу LOG (цитата з вищезгаданого повідомлення в блозі):

Якщо ви скорочуєте журнал, він знову зростатиме - можливо, спричиняючи фрагментацію VLF, і, безумовно, спричиняє навантаження на роботу призупинення, коли журнал зростає, оскільки журнал не може використовувати миттєву ініціалізацію [...]

Оновлення: Не помиліться усічення файлів LOG для зменшення файлу DATA. Скорочення файлу DATA насправді погано. Див. Чому не слід стискати файли даних для отримання детальної інформації.

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

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

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

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

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