Как уменьшить размер резервной копии журнала транзакций после полного резервного копирования?

У меня есть три плана обслуживания, настроенные для запуска на экземпляре Sql Server 2005:

• Еженедельная оптимизация базы данных с последующим полным резервным копированием
• Ежедневное дифференциальное резервное копирование
• Почасовые резервные копии журнала транзакций

Почасовые резервные копии журналов обычно составляют от нескольких сотен килобайт до 10 МБ в зависимости от уровня активности, ежедневные различия обычно увеличиваются до 250 МБ к концу недели, а еженедельное резервное копирование составляет около 3,5 ГБ.

У меня проблема в том, что оптимизация перед полной резервной копией, по-видимому, приводит к тому, что следующая резервная копия журнала транзакций увеличивается в 2 раза по сравнению с полной резервной копией, в данном случае 8 ГБ, прежде чем вернуться в нормальное состояние.

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

Здесь есть несколько интересных предложений, которые, похоже, показывают непонимание того, как работают резервные копии журналов. Резервная копия журнала содержит ВСЕ журналы транзакций, созданные с момента создания предыдущей резервной копии журнала, независимо от того, какие временные или полные резервные копии были сделаны в промежуточный период. Остановка резервного копирования журнала или переход к ежедневному полному резервному копированию не повлияет на размеры резервного копирования журнала. Единственное, что влияет на журнал транзакций, - это резервное копирование журнала после запуска цепочки резервного копирования журнала.

Единственное исключение из этого правила - разрыв цепочки резервных копий журналов (например, переход к модели восстановления SIMPLE, возврат из снимка базы данных, усечение журнала с использованием BACKUP LOG WITH NO_LOG / TRUNCATE_ONLY), и в этом случае первое резервное копирование журнала будет содержать весь журнал транзакций с момента последнего полного резервного копирования - который перезапускает цепочку резервного копирования журнала; или если цепочка резервного копирования журнала не была запущена - при первом переключении в ПОЛНОЕ, вы работаете в своего рода псевдо-ПРОСТОЙ модели восстановления до тех пор, пока не будет выполнено первое полное резервное копирование.

Чтобы ответить на ваш первоначальный вопрос, не вдаваясь в ПРОСТУЮ модель восстановления, вам придется взять на себя резервное копирование всего журнала транзакций. В зависимости от действий, которые вы предпринимаете, вы можете делать более частые резервные копии журналов, чтобы уменьшить их размер, или делать более целевую базу данных.

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

Если у вас нет других действий в базе данных во время обслуживания, вы можете сделать следующее:

• убедитесь, что активность пользователя остановлена
• сделать окончательное резервное копирование журнала (это позволяет восстановить до момента начала обслуживания)
  • переключиться на ПРОСТУЮ модель восстановления
  • выполнить обслуживание - журнал будет обрезаться на каждой контрольной точке
  • переключиться на полную модель восстановления и сделать полную резервную копию
  • продолжить как обычно

Надеюсь, это поможет - с нетерпением жду дополнительной информации.

Благодарность

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

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

Я предполагаю, что вы используете план обслуживания для оптимизации, вы можете изменить его на использование сценария, который выполняет дефрагментацию индекса только тогда, когда достигнут определенный уровень фрагментации, и вы вряд ли пострадаете от какого-либо снижения производительности. Это будет генерировать гораздо меньшие журналы.

Я бы пропустил ежедневные различия в пользу ежедневных полных резервных копий.

Ваш последний вопрос был: «Кроме BACKUP LOG WITH TRUNCATE_ONLY, есть ли способ уменьшить размер этой резервной копии журнала или вообще предотвратить запись оптимизаций в журнал транзакций, так как они будут полностью учтены резервное копирование они предшествуют?

Нет, но вот обходной путь. Если вы знаете, что единственными действиями в этой базе данных в то время будут задания обслуживания индекса, то вы можете остановить резервное копирование журнала транзакций до начала обслуживания индекса. Например, на некоторых моих серверах в субботу вечером графики работы выглядят так:

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

Это означает, что у меня нет возможности восстановления на определенный момент времени с 9:45 до 23:30, но выигрыш - более высокая производительность.

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

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

Но если все, что вас волнует, это размер вашего t-журнала еженедельно, разделите его на день или час на час и выполняйте промежуточные резервные копии t-log.

Вы также можете воспользоваться сторонним инструментом (Litespeed от Quest, SQL Backup от Red Gate, Hyperbac), чтобы уменьшить размеры резервных копий и журналов. Они могут быстро окупить себя за счет экономии на ленте.

Вероятно, можно предположить, что ваши «оптимизации» включают перестройку индекса. Только выполнение этих задач на еженедельной основе может быть приемлемо для базы данных, которая не встречает большого количества обновлений и вставок, однако, если ваши данные очень изменчивы, вы можете сделать пару вещей:

1. Перестройте или реорганизуйте свои индексы по ночам, если позволяет расписание и если влияние приемлемо. При выполнении этих задач обслуживания ночных индексов нацеливайтесь только на те индексы, которые фрагментированы, скажем, 30% для перестроений и в диапазоне 15-30% для перегруппировок.

2. Эти задачи являются зарегистрированными транзакциями, поэтому, если вы обеспокоены ростом журнала, я бы рекомендовал то, что рекомендовал Пол. Окончательное резервное копирование журнала транзакций перед обслуживанием индекса, переключение на Простое восстановление, затем процесс обслуживания, а затем переключение обратно на Полное восстановление с последующим полным резервным копированием данных.

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

Что касается сценариев, которые выполняют обслуживание индекса по усмотрению, смотрите онлайн: их там масса. Эндрю Келли опубликовал приличный журнал в журнале SQL около года назад. В SQLServerPedia есть несколько сценариев от Мишель Аффорд, а в последнем выпуске журнала SQL (я полагаю, в июле 2009 года) также есть полная статья на эту тему. Смысл в том, чтобы найти тот, который хорошо вам подходит, и сделать его своим с минимальными настройками.

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

Можете ли вы сделать более целенаправленную оптимизацию базы данных, чтобы было создано меньше транзакций (кто-то упомянул об этом, но я не уверен, что последствия были прописаны). Например, терпеть определенную фрагментацию или потратить впустую некоторое время. Если 40% ваших таблиц фрагментированы только на 5%, не трогайте их, чтобы сэкономить немного активности.