Як зменшити розмір резервного копіювання журналу транзакцій після повної резервної копії?

У мене є три плани технічного обслуговування для роботи на екземплярі Sql Server 2005:

• Щотижневі оптимізації бази даних з подальшим повним резервним копією
• Щоденне диференціальне резервне копіювання
• Щогодини резервного копіювання журналу транзакцій

Погодинна резервна копія журналу зазвичай становить від декількох сотень Кб і 10 Мб залежно від рівня активності, щоденні диференціали зазвичай зростають до приблизно 250 Мбіт до кінця тижня, а тижневе резервне копіювання - близько 3,5 Гбіт.

Проблема, яку я маю, полягає в тому, що оптимізації перед повною резервною копією, здається, спричиняють зростання наступної резервної копії журналу транзакцій в розмірі понад 2 рази в розмірі повної резервної копії, в даному випадку 8Gb, перед тим, як повернутися до нормального.

Крім того BACKUP LOG <DatabaseName> WITH TRUNCATE_ONLY, чи є якийсь спосіб зменшити розмір резервної копії цього журналу або взагалі не допустити, щоб оптимізація була записана в журнал транзакцій, оскільки, безумовно, вони будуть враховані в повній резервній копії, якій вони передують?

Тут є кілька цікавих пропозицій, які, схоже, показують непорозуміння щодо роботи резервних копій журналу. Резервне копіювання журналу містить ВСІ журнали транзакцій, згенеровані з попереднього резервного копіювання журналу, незалежно від того, які повні або диференціальні резервні копії приймаються у проміжку. Припинення резервного копіювання журналу або перехід до щоденних повних резервних копій не матиме впливу на розміри резервного копіювання журналу. Єдине, що впливає на журнал транзакцій, - це резервне копіювання журналу, після запуску ланцюга резервного копіювання журналу.

Єдиним винятком із цього правила є те, якщо ланцюг резервного копіювання журналу був розірваний (наприклад, перейшовши на SIMPLE модель відновлення, повернувшись із знімка бази даних, обрізавши журнал за допомогою BACKUP LOG WITH NO_LOG / TRUNCATE_ONLY), у цьому випадку перша резервна копія журналу міститиме весь журнал транзакцій з останнього повного резервного копіювання - який перезапускає ланцюг резервного копіювання журналу; або якщо ланцюг резервного копіювання журналу не був запущений - коли ви вперше переходите на FULL, ви працюєте у певній моделі відновлення псевдо-ПРОСТО до початку першої повної резервної копії.

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

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

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

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

Сподіваюсь, це допомагає - з нетерпінням чекаю на додаткову інформацію.

Спасибі

[Редагувати: після усієї дискусії про те, чи може повна резервна копія змінити розмір наступної резервної копії журналу (вона не може), я зібрав вичерпну публікацію в блозі з фоновим матеріалом та сценарієм, який це підтверджує. Перевірте це на веб-сторінці https://www.sqlskills.com/blogs/paul/misconceptions-around-the-log-and-log-backups-how-to-convince-yourself/]

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

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

Я б пропустив щоденні диференціали на користь щоденних повних резервних копій BTW.

Ваше останнє питання: "Окрім BACKUP LOG WITH TRUNCATE_ONLY, чи є якийсь спосіб зменшити розмір резервної копії цього журналу або взагалі не допустити, щоб оптимізація була записана в журнал транзакцій, оскільки, безумовно, вони будуть враховані в повному обсязі резервне копіювання їм передує? "

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

• 21:30 - працює резервне копіювання журналу транзакцій.
• 21:45 - резервне копіювання журналу транзакцій працює в останній раз. Розклад зупиняється о 9:59.
• 22:00 - розпочинається робота з технічного обслуговування індексів, а вбудовані зупинки закінчуються до 11:30.
• 23:30 - повна робота із резервного копіювання починається і закінчується за 30 хвилин.
• 00:00 - резервні копії журналу транзакцій починаються знову кожні 15 хвилин.

Це означає, що я не маю можливості відновити час у часі між 9:45 та 23:30, але окупність - це швидша ефективність.

Проста відповідь: Змініть свою щотижневу оптимізацію, щоб вона працювала більш врівноважено щоночі. тобто таблиці повторного індексу ae в ніч на неділю, f - l в ніч на понеділок і т. д ... знайдіть хороший баланс, ваш журнал буде в середньому приблизно 1/6 розміру. Звичайно, це найкраще працює, якщо ви не використовуєте роботу з обслуговування вбудованого індексу ssis.

Мінус цього, і це важливо залежно від навантаження, яке відчуває ваш db, - це те, що він спричиняє загрозу з оптимізатором та повторним використанням планів запитів.

Але якщо все, що вам цікаво, - це розмір вашого t-журналу щотижня, розділіть його на день або на годину до години та запустіть резервні копії t-log між ними.

Для зменшення розмірів резервних копій та журналів ви можете також переглянути інструмент сторонніх виробників (Litespeed від Quest, резервне копіювання SQL від Red Gate, Hyperbac). Вони можуть швидко оплатити себе заощадженнями стрічки.

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

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

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

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

Щодо сценаріїв, які виконують дискреційне обслуговування індексу, дивіться в Інтернеті: там є тонна. Ендрю Келлі близько року тому опублікував гідний журнал SQL. У SQLServerPedia є кілька сценаріїв від Мішель Уффорд, а останній випуск журналу SQL (липень 2009 року, я вважаю) має також повну статтю про цю тему. Сенс полягає в тому, щоб знайти той, який добре підходить для вас, і зробіть його власним з мінімальними налаштуваннями.

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

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