Що таке віртуальний файл журналу?
SQL Server розділяє файл журналу транзакцій для кожної бази даних на менші шматки, які називаються "віртуальні файли журналу" (або короткі VLF). Їх основна функція - це маркери усікання при резервній копії журналу, тобто SQL Server очищатиме (і маркує, доступні для повторного використання) VLF, які повністю порожні. MSDN має твір про журнал транзакцій - фізична архітектура .
Що визначає кількість УПЛ?
Щоразу, коли файл журналу зростає (за допомогою автоматичного зростання чи ручного зростання), новий розділ файлу журналу поділяється на ряд VLF, суто виходячи з розміру нового розділу (існуючий журнал транзакцій залишається в спокої). Отже, невеликі налаштування автоматичного зростання (тобто 10-відсотковий авторост, який за замовчуванням) призведе до створення великої кількості VLF.
Які наслідки має велика кількість VLF?
Основним питанням, що викликає велику кількість причин VLF, є:
- Повільне відновлення (відновлення - це фаза під час відновлення бази даних, коли завершені транзакції записуються на сторінки даних, а неповні транзакції повертаються назад).
- Повільна продуктивність зчитування журналу журналу в налаштуваннях дзеркального відображення бази даних.
- Повільна продуктивність під час створення знімків із бази даних (зауважте, що це включає також певні функції,
DBCCоскільки вони використовують знімки бази даних у фоновому режимі для полегшення перевірки узгодженості без блокування).
Як я можу дізнатися, скільки VLF має моя база даних?
DBCC LOGINFOповерне 1 рядок для кожного VLF в журналі транзакцій вашої бази даних. У цьому питанні є кілька корисних сценаріїв для його застосування у всіх базах даних на сервері.
Скільки VLF - це занадто багато?
Це заклик вирок, який ви повинні зробити самі. Моє особисте правило полягає в тому, що молодше 50 років не варто возитися, а понад 100 (або близько того), і я виправляю параметри автоматичного зростання і роблю міркування, щоб (у наступному вікні технічного обслуговування) скорочуватись і переробити журнал (як показано нижче) .
Довідка! У мене є одинадцять мільярдів VLF, і відновлення моєї бази даних займає весь день!
Короткий контур (з блогу Кімберлі Трипп ):
- Переконайтеся, що у вас є єдине активне з'єднання в базі даних (так, робіть це під час вікна обслуговування)
- Резервне копіювання журналу транзакцій на диск (за допомогою
BACKUP LOG)
- Запуск
DBCC SHRINKFILEз TRUNCATEONLYстиснути файл журналу до найменшого можливого розміру.
- Запустіть,
ALTER DATABASE [...] MODIFY FILE [...] SIZE=newsizeщоб змінити розмір резервного копіювання журналу транзакцій за один крок **.
** Примітка. Якщо у вас дуже великий файл журналу (десятки ГБ або більше), ви можете захотіти змінити розмір в кілька етапів, щоб отримати відповідну кількість VLF-файлів відповідного розміру, щоб уникнути надмірно "кумедних" резервних копій журналу. Оскільки VLF - це одиниця скорочення, вони також визначають розміри резервного копіювання журналу, як це детально описано в блозі Кіма .