it-swarm-ru.tech

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

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

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

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

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

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

38
Dave

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

Единственное исключение из этого правила - разрыв цепочки резервных копий журналов (например, переход к модели восстановления 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/]

35
Paul Randal

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

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

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

5
SqlACID

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

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

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

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

3
Brent Ozar

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

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

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

3
Jeremy Lowell

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

2
Steve Jones

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

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

2
ErikE

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

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

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

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

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

2
Tim Ford