none
Когда лучше делать BACKUP LOG db_name WITH TRUNCATE_ONLY для очитски лога? RRS feed

  • Вопрос

  • модель востановления базы - полная
    база 4,5Гб
    лог увеличивается в день на 10-12ГБ (не знаю как так может работать приложение 1С...)

    Нужно автоматически настроить очищение лог (можно без усечения, все равно быстро растет), на данный момент настроено следующее:
    1) полный бэкап 1 раз в месяц
    2) дифференцированный бэкап в воскресенье
    3) бэкап лога один раз каждый день без truncate:
    BACKUP LOG [db_name] TO  DISK = N'Path\DBLOGN' WITH NOFORMAT, NOINIT,  NAME = N'db_name-Transaction Log  Backup', SKIP, NOREWIND, NOUNLOAD,  STATS = 10, CHECKSUM
    4) периодически задается новое имя для бэкап лога

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

    предполагаю добавить BACKUP LOG db_name WITH TRUNCATE_ONLY сразу перед дифференцированным бэкапом, при этом я так понимаю востанавливаемость базы на момент времени будет в пределах недели (без поднятия логов из бэкапа), плюс если поднимать лог из бэкап'ов то на период хранимых файлов бэкапа логов, я правильно понял относительно степени востанавливаемости базы?


    Есть какие-нибудь замечания по поводу политики бэкапирования, может есть у кого нить идеи более эффективного бэкапирования для моего случая?
    15 июня 2009 г. 7:00

Ответы

  • Илгиз, можно у вас спросить. Чтобы не заводить новый тред.

    Как настроить резервное копирование в SQL2005 Std (x64, SP2) службы работают под учеткой доменного юзера? Чего я хотел - базы лежат на RAID0 Работает годами без проблем. Тем не менее все понимают насколько это риск. Хочу - быстрое (менее 30 минут) восстановление. Минимальную потерю данных - скажем копирование логов каждый час. Может делать Full Backup ежечасно?

    К сожалению на все времени не хватает. Адмнистрирование BD MSSQL для меня сводиться к бекапу и обслуживанию

    «Обновление статистик». "Дефрагментация индексов" "Реиндексация таблиц базы данных" - все описано в 1С в статье "Регламентные операции на уровне СУБД для MS SQL Server

     Проблема такая: я создал 2 Плана: Backup и LogBackup Модель Full. Backup: в 22 часа происходил полный бекап базы. в 12 - разностный. База маленькая - логи (history) показывают, что бекап 1 базы происходит за минуту (3 базы - 4Gb, 3Gb и 1Gb ). LogBackup   настроен на  бекап логов каждый час. В Истории же LogBackup вот что: Ошибки с 22 до 12 каждый час. а с 13 до 22 все хорошо! каждый час успешный бэкап логов транзакций.

    Читал тут http://msdn.microsoft.com/ru-ru/library/89a4658a-62f1-4289-8982-f072229720a1(SQL.90).aspx Не понял. Зато много полезного тут:http://social.technet.microsoft.com/Forums/ru-RU/sqlru/thread/7871c1a9-dcdf-473f-b281-54ceb9da9033

    Сюда пришел, так как случай заставил меня: готовлюсь к виртуализайии моего MS SQL Server Переименовал машину. Теперь конечно MP не работают - в свойствах каждого таска поле Connection - серое и не изменяется, а отредактировать Local connection - тоже невозможно. Чё делать то... Вот и подумал - разобраться с новыми MP

     

     

    Можно предложить Вам такую схему резервного копирования, принимая во внимание малый размер баз данных и требование глубины восстановления данных:
    - модель восстановления баз данных - полная
    - полный бэкап баз данных один раз ежедневно ночью (возможно еще один раз днем, в обед), срок хранения - 1 месяц (настройте соответствующую задачу по очистке старых файлов бэкапов)
    - бэкап журналов транзакций ежечасно ежедневно, срок хранения 1 месяц (хотя я бы усомнился в этой цифре. По мне так максимум неделя хранения для логов вполне сойдет. Врядли потребуется восстановление недельной давности на какую то точку времени кроме полного бэкапа. Но если уж это жесткое требование.. - запасайтесь дисковым пространством, и раза в 3-4 большим, чем требуется для одного полного цикла бэкапов)
    (настройте соответствующую задачу по очистке старых файлов бэкапов)

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

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

    Удачи.
    ---
    З.Ы.: И никаких BACKUP LOG db_name WITH TRUNCATE_ONLY. После этой команды нужно выполнить Полный бэкап базы, чтобы последующие бэкапы журналов транзакций проходили корректно.


    MCITP
    • Предложено в качестве ответа AlexLAV 18 июля 2010 г. 13:23
    • Помечено в качестве ответа Daniil KhabarovModerator 20 июля 2010 г. 6:53
    29 июня 2010 г. 18:34

Все ответы

  • Вы не указали версию SQL Server.
    Например в SQL Server 2008 параметры BACKUP LOG WITH NO_LOG и WITH TRUNCATE_ONLY больше не поддерживаются.

    Если вы сделаете BACKUP LOG db_name WITH TRUNCATE_ONLY, то журнал транзакций будет очищен без бэкапа, цепочка бэкапов журнала транзакций прервется и после этого вам придется сделать FULL BACKUP чтобы возобновить проведение BACKUP LOG.

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

    Если вы хотите уменьшить размер файла журнала транзакций, то непосредственно после BACKUP LOG выполните усечение файла журнала транзакций:
    USE [model]
    GO
    DBCC SHRINKFILE (N'modellog' , 1024)
    GO
    , где model - имя базы данных, modellog - имя файла журнала транзакций, 1024 - целевой размер файла журнала транзакций в МБ.


    MCITP: Database Administrator
    15 июня 2009 г. 8:11
  • Отвечая на вопрос "Когда лучше делать BACKUP LOG db_name WITH TRUNCATE_ONLY для очитски лога?" могу сказать следующее:
    - если вы пользуетесь опцией WITH TRUNCATE_ONLY на регулярной основе на рабочей базе, то задумайтесь, нужна ли вам модель восстановления FULL ? Может проще будет использовать SIMPLE ?
    - WITH TRUNCATE_ONLY скорее всего нужно использовать для решения\устранения\выхода из сложившейся проблемы с переполнением диска, нехваткой места, тестированием, переносом базы и т.п., с последующим восстановлением нормальной схемы резервного копирования.
    MCITP: Database Administrator
    15 июня 2009 г. 8:21
  • Илгиз, можно у вас спросить. Чтобы не заводить новый тред.

    Как настроить резервное копирование в SQL2005 Std (x64, SP2) службы работают под учеткой доменного юзера? Чего я хотел - базы лежат на RAID0 Работает годами без проблем. Тем не менее все понимают насколько это риск. Хочу - быстрое (менее 30 минут) восстановление. Минимальную потерю данных - скажем копирование логов каждый час. Может делать Full Backup ежечасно?

    К сожалению на все времени не хватает. Адмнистрирование BD MSSQL для меня сводиться к бекапу и обслуживанию

    «Обновление статистик». "Дефрагментация индексов" "Реиндексация таблиц базы данных" - все описано в 1С в статье "Регламентные операции на уровне СУБД для MS SQL Server

     Проблема такая: я создал 2 Плана: Backup и LogBackup Модель Full. Backup: в 22 часа происходил полный бекап базы. в 12 - разностный. База маленькая - логи (history) показывают, что бекап 1 базы происходит за минуту (3 базы - 4Gb, 3Gb и 1Gb ). LogBackup   настроен на  бекап логов каждый час. В Истории же LogBackup вот что: Ошибки с 22 до 12 каждый час. а с 13 до 22 все хорошо! каждый час успешный бэкап логов транзакций.

    Читал тут http://msdn.microsoft.com/ru-ru/library/89a4658a-62f1-4289-8982-f072229720a1(SQL.90).aspx Не понял. Зато много полезного тут:http://social.technet.microsoft.com/Forums/ru-RU/sqlru/thread/7871c1a9-dcdf-473f-b281-54ceb9da9033

    Сюда пришел, так как случай заставил меня: готовлюсь к виртуализайии моего MS SQL Server Переименовал машину. Теперь конечно MP не работают - в свойствах каждого таска поле Connection - серое и не изменяется, а отредактировать Local connection - тоже невозможно. Чё делать то... Вот и подумал - разобраться с новыми MP

     

     

    22 июня 2010 г. 12:39
  • А ошибка какая возникает в период с 22 до 12? Номер и текст ошибки можете привести из того же history?

    P.S. А вообще, т.к. база у вас маленькая, я бы вам рекомендовал исключить разностное резервное копирование в 12 часов и оставить только полное каждый вечер и резервное копирование логов каждый час (если вас устраивает возможная потеря данных в 1 час). А востановить за 30 минут эти базы полюбому успеете, главное регулярно проводить тестовые восстановления имитируя экстренный случай. :) Главное хранить полную резервную копию на начало месяца и всю цепоку бэкапов логов после этой полной резервной копии.

    И придется запастись большими дисками, т.к. за месяц у вас будет накапливаться больше 300 Гб резерных копий журналов транзауций + я бы рекомендовал вам симметрично бэкапить их сразу на 2 разных диска. На случай если один диск с резервными копими откажет.

    29 июня 2010 г. 15:28
  • На ответ Илгиза про опцию WITH TRUNCATE_ONLY могу дополнить только, что в SQL Server 2008 единственным вариантом экстренного сжатия лога на переполненном диске будет перевод базы в режим восстановления simple и dbcc shrinkfile для журнала транзакций или бэкап лога и опять же dbcc shrinkfile.
    29 июня 2010 г. 15:32
  • Илгиз, можно у вас спросить. Чтобы не заводить новый тред.

    Как настроить резервное копирование в SQL2005 Std (x64, SP2) службы работают под учеткой доменного юзера? Чего я хотел - базы лежат на RAID0 Работает годами без проблем. Тем не менее все понимают насколько это риск. Хочу - быстрое (менее 30 минут) восстановление. Минимальную потерю данных - скажем копирование логов каждый час. Может делать Full Backup ежечасно?

    К сожалению на все времени не хватает. Адмнистрирование BD MSSQL для меня сводиться к бекапу и обслуживанию

    «Обновление статистик». "Дефрагментация индексов" "Реиндексация таблиц базы данных" - все описано в 1С в статье "Регламентные операции на уровне СУБД для MS SQL Server

     Проблема такая: я создал 2 Плана: Backup и LogBackup Модель Full. Backup: в 22 часа происходил полный бекап базы. в 12 - разностный. База маленькая - логи (history) показывают, что бекап 1 базы происходит за минуту (3 базы - 4Gb, 3Gb и 1Gb ). LogBackup   настроен на  бекап логов каждый час. В Истории же LogBackup вот что: Ошибки с 22 до 12 каждый час. а с 13 до 22 все хорошо! каждый час успешный бэкап логов транзакций.

    Читал тут http://msdn.microsoft.com/ru-ru/library/89a4658a-62f1-4289-8982-f072229720a1(SQL.90).aspx Не понял. Зато много полезного тут:http://social.technet.microsoft.com/Forums/ru-RU/sqlru/thread/7871c1a9-dcdf-473f-b281-54ceb9da9033

    Сюда пришел, так как случай заставил меня: готовлюсь к виртуализайии моего MS SQL Server Переименовал машину. Теперь конечно MP не работают - в свойствах каждого таска поле Connection - серое и не изменяется, а отредактировать Local connection - тоже невозможно. Чё делать то... Вот и подумал - разобраться с новыми MP

     

     

    Можно предложить Вам такую схему резервного копирования, принимая во внимание малый размер баз данных и требование глубины восстановления данных:
    - модель восстановления баз данных - полная
    - полный бэкап баз данных один раз ежедневно ночью (возможно еще один раз днем, в обед), срок хранения - 1 месяц (настройте соответствующую задачу по очистке старых файлов бэкапов)
    - бэкап журналов транзакций ежечасно ежедневно, срок хранения 1 месяц (хотя я бы усомнился в этой цифре. По мне так максимум неделя хранения для логов вполне сойдет. Врядли потребуется восстановление недельной давности на какую то точку времени кроме полного бэкапа. Но если уж это жесткое требование.. - запасайтесь дисковым пространством, и раза в 3-4 большим, чем требуется для одного полного цикла бэкапов)
    (настройте соответствующую задачу по очистке старых файлов бэкапов)

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

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

    Удачи.
    ---
    З.Ы.: И никаких BACKUP LOG db_name WITH TRUNCATE_ONLY. После этой команды нужно выполнить Полный бэкап базы, чтобы последующие бэкапы журналов транзакций проходили корректно.


    MCITP
    • Предложено в качестве ответа AlexLAV 18 июля 2010 г. 13:23
    • Помечено в качестве ответа Daniil KhabarovModerator 20 июля 2010 г. 6:53
    29 июня 2010 г. 18:34
  • Спасибо! В ближайшее время обязательно попробую сделать как вы советуете!

     Уже переехал на Hyper-V собственно по-причине великой занятости и не заходил. Создал новые MP но еще не такие как мне нужно и не такие как вы говорите и что самое ужасное - еще не настолько все отладил чтобы провести "стендовые испытания на 30-минутное восстановление после аварии" как правильно написал Sergei Olonstev "востановить за 30 минут эти базы полюбому успеете, главное регулярно проводить тестовые восстановления имитируя экстренный случай. :) "

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

    Кстати, я писал, что мне нужно было переименовать машину, на которой стоял единственный экземпляр MS SQL 2005, также писал, что после этого старые MP удалить никак не получалось. Пришлось делать как пишут в KB - переименовывать сервер обратно в старое имя, тогда только смог удалить Планы обслуживания. Потом переименовал как мне надо и создал необходимые планы - Full BackUp ночью по сети на другой сервер. Проверил, в смысле восстанавливал бызы - все в порядке. Само восстановление из FB занимает буквально 3 минуты. разуемеется сделал MP как советует 1С - ибо без них, без пересроения индекса и т.д. АдинЭска тормазит очень сильно у нас. Сильно - это когда человек выбирает в карточке колонку цен, возможно 2-ух секундное зависание. Если делать же регламентные операции, как рекомендует 1С, то никаких проблем нет.

    18 июля 2010 г. 13:38