none
Эффективная процедура бэкапа RRS feed

  • Вопрос

  • Добрый день!

    Хотелось бы задать вопрос специалистам по MS SQL.

    Есть большая база данных размером ~250-300Гб, которая будет продолжать увеличиваться. Модель восстановления у базы Full. Бэкап происходит ежедневно в 2 шага, сначала базы следующей командой:

    BACKUP DATABASE db_name TO  DISK = N'd:\db_name.bak' WITH  INIT , NAME = N'db_name backup',  NOSKIP , NOFORMAT

    потом урезается лог транзакций: BACKUP LOG db_name WITH TRUNCATE_ONLY.

    Процедура восстановления не предусматривает промежуточных бэкапов по всоей архитектуре.

    Вопрос в следующем, правильно ли использование таких команд? Возможно лучше все таки бэкапить и лог?

     

     

     

Ответы

  • У вас максимальная потеря данных так будет сутки. И восстановление быстрое и простое.

    Лог бекапят, если нужно восставливать потерю на срок меньше суток. Или есть места для бекапа не хватает, но тогда  можно смотреть в сторону  "разностного резервного копирования" Smile  Differential, короче.

     

    А неправильно у вас то, что вы искуственное с помощью log truncate реализуете модель восстановления simple Smile 

    5 июня 2007 г. 11:13
  • Можно транкейтить журнал не после, а до полной копии. Тогда потенциально у Вас будет возможность восстановиться на заданный момент времени... Точность восстановление - это бизнес-правило, можно переключиться на простую модель, если точнее не требуется. Однако, если восстановление изменений потребует от вас какой-то работы, Вы можете облегчить себе жизнь, наладив периодическое копирование журнала. К тому же, правилам свойственно становиться строже Wink
    5 июня 2007 г. 13:41
  • 1)

    Усечение журнала в простой модели восстановления.
    При использовании простой модели восстановления усечение журналов выполняется автоматически.

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

    2)Усечение не уменьшает размер файла физического журнала. Для уменьшения физического размера файла журнала необходимо его сжатие

    3)Когда журнал сжимается?

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

    • при выполнении операции автосжатия;
    • при выполнении инструкции DBCC SHRINKFILE для файла журнала;
    • при выполнении инструкции DBCC SHRINKDATABASE

    Мне видится, что если модель стоит simple recovery, то усечение будет автоматическим, но чтобы освободилось место, нужно или делать shrinkdatabase, или ждать события autoshrink (по дефолту включено). Но в общем-то в итоге лог будет обрезаться автоматически.

     

    Если стоит full recovery, то при отсутствии бекапа логов и без использования backup log with truncate only файл будет расти бесконечно, а при использовании with truncate only будет усекаться, а дальше опять или shrinkdatabase или autoshrink.

     

    Только я смысла не вижу, если лог не бекапиться, держать модель full recovery. Лишние телодвижения с backuplog truncate only, которое к тому же выполняется только раз в день, а в simple mode урезание и autoshrink в теории может выполняться и чаще (а может и реже, не нашел я условий периодичности для их запуска).

    Я где-то ошибаюсь?

  • При полной копии из журнала ничего не исчезает (как это происходит при копировании журнала), ничего в нём не усекается и не сжимается.

    Кроме того, не стоит забывать, что использование полной модели резервирование может снижать производительность операций до 10%, т.ч. если не отписывать в копию логи это не только не логично, но и не практично...

    О том, при каких условиях происходит усечение журнала в простой модели, написано тут: http://msdn2.microsoft.com/ru-ru/library/98a80238-7409-4708-8a7d-5defd9957185(SQL.90).aspx

  • Примеры инструкций резервного копирования можно найти тут: http://msdn2.microsoft.com/ru-ru/library/89a4658a-62f1-4289-8982-f072229720a1(SQL.90).aspx

    Подумайте хорошенько, прежде чем шринковать всю базу... если вам нужно уменьшить размер файла журнала, уменьшайте только его (DBCC SHRINKFILE ещё никто не отменял). Шринкование файлов данных - это ЗЛО!

    9 июня 2007 г. 10:59

Все ответы

  • У вас максимальная потеря данных так будет сутки. И восстановление быстрое и простое.

    Лог бекапят, если нужно восставливать потерю на срок меньше суток. Или есть места для бекапа не хватает, но тогда  можно смотреть в сторону  "разностного резервного копирования" Smile  Differential, короче.

     

    А неправильно у вас то, что вы искуственное с помощью log truncate реализуете модель восстановления simple Smile 

    5 июня 2007 г. 11:13
  • Да, именно. Но, как я уже писал для восстановления базы достаточно и одного бэкапа в сутки.

    Вопрос скорее - что в этом случае делать с логом, потому как урезать его таким образом нет смысла Smile

    5 июня 2007 г. 11:34
  • Поставить simple recovery mode, будет сам обрезаться после full бекапа.
    5 июня 2007 г. 13:30
  •  Данила Полевщиков написано:
    Поставить simple recovery mode, будет сам обрезаться после full бекапа.

     

    Не вводите людей в заблуждение!

    5 июня 2007 г. 13:34
  • Можно транкейтить журнал не после, а до полной копии. Тогда потенциально у Вас будет возможность восстановиться на заданный момент времени... Точность восстановление - это бизнес-правило, можно переключиться на простую модель, если точнее не требуется. Однако, если восстановление изменений потребует от вас какой-то работы, Вы можете облегчить себе жизнь, наладив периодическое копирование журнала. К тому же, правилам свойственно становиться строже Wink
    5 июня 2007 г. 13:41
  • 1)

    Усечение журнала в простой модели восстановления.
    При использовании простой модели восстановления усечение журналов выполняется автоматически.

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

    2)Усечение не уменьшает размер файла физического журнала. Для уменьшения физического размера файла журнала необходимо его сжатие

    3)Когда журнал сжимается?

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

    • при выполнении операции автосжатия;
    • при выполнении инструкции DBCC SHRINKFILE для файла журнала;
    • при выполнении инструкции DBCC SHRINKDATABASE

    Мне видится, что если модель стоит simple recovery, то усечение будет автоматическим, но чтобы освободилось место, нужно или делать shrinkdatabase, или ждать события autoshrink (по дефолту включено). Но в общем-то в итоге лог будет обрезаться автоматически.

     

    Если стоит full recovery, то при отсутствии бекапа логов и без использования backup log with truncate only файл будет расти бесконечно, а при использовании with truncate only будет усекаться, а дальше опять или shrinkdatabase или autoshrink.

     

    Только я смысла не вижу, если лог не бекапиться, держать модель full recovery. Лишние телодвижения с backuplog truncate only, которое к тому же выполняется только раз в день, а в simple mode урезание и autoshrink в теории может выполняться и чаще (а может и реже, не нашел я условий периодичности для их запуска).

    Я где-то ошибаюсь?

  • При полной копии из журнала ничего не исчезает (как это происходит при копировании журнала), ничего в нём не усекается и не сжимается.

    Кроме того, не стоит забывать, что использование полной модели резервирование может снижать производительность операций до 10%, т.ч. если не отписывать в копию логи это не только не логично, но и не практично...

    О том, при каких условиях происходит усечение журнала в простой модели, написано тут: http://msdn2.microsoft.com/ru-ru/library/98a80238-7409-4708-8a7d-5defd9957185(SQL.90).aspx

  • Тогда вопрос будет таким:

    Каким образом(командами) лучше проводить бэкап, если база бэкапится 1 раз в день (процедура как я описывал раньше)

    В случае сбоя нужно:

    1. остановить импорт данных в базу
      2. восстановиться из бэкапа
      3. разобраться в какой момент сломались
      4. вернуть логи из помойки в повторную обработку
      5. обработать их
      6. обработать то, что накопилось за это время

     

    4,5 и 6 относится к внешним данным, которые заносятся в базу.

     

    7 июня 2007 г. 12:54
  • Конечно же хотелось бы, чтобы процедура восстановления проходила как можно быстрее и проще. Smile

    +

    Если simple recovery model подразумевает, что не будет никакой возможности восстановить изменения, сделанные в базе после предыдущего резервного копирования. Выполняются только полные резервные копирования.

     Единственная выгода от этой модели, это то, что transaction log не переполняется транзакциями, регистрируемыми в журнале между полными резервными копированиями. Всякий раз, когда база данных исполняет checkpoint, свободное место в журнале регистрации транзакций высвобождается. Кроме того, разрешены не регистрируемые операции, такие, как массовое копирование.

     

    Может быть действительно стоит перейти на эту модель и оставить только одну команду для бэкапа BACKUP DATABASE name TO DISK...?

    7 июня 2007 г. 12:55
  • Я бы так и сделал Smile Но помните, что есть разница между log truncate, которой освобождает логический лог, и shrink database, после чего файл лога уменьшается физически. В теории, shrink выполняется автоматически, если в свойствах базы стоит  auto shrink=true.

    но лучше сразу после бекапа делать

    dbcc shrinkdatabase (name, 0, truncateonly)
    go

     


     

    7 июня 2007 г. 13:28
  • Тоесть переводим базу в simple recovery model.

    Потом бэкапим

    BACKUP DATABASE [db_name] TO  DISK = N'c:\dbname.bak' WITH  INIT , NAME = N'db_name',  NOSKIP ,  NOFORMAT

    и следующиv шагом

    dbcc shrinkdatabase (db_name, 0, truncateonly)
    go

          ??
  • Примеры инструкций резервного копирования можно найти тут: http://msdn2.microsoft.com/ru-ru/library/89a4658a-62f1-4289-8982-f072229720a1(SQL.90).aspx

    Подумайте хорошенько, прежде чем шринковать всю базу... если вам нужно уменьшить размер файла журнала, уменьшайте только его (DBCC SHRINKFILE ещё никто не отменял). Шринкование файлов данных - это ЗЛО!

    9 июня 2007 г. 10:59
  • Спасибо!
    14 июня 2007 г. 7:32