Comments 15
Не увидел в тексте: чем же предложенные простыни кода лучше штатных «Maintenance Plans»?
Там всё это же накликивается в GIU за 5 минут, а ещё можно уведомления прикрутить на почту.
Очень похоже
Дискуссии на эту тему были в предыдущей статье... а в целом мне нравится именно такое решение - простое, предсказуемое, легко мониторить и настраивать
Ещё совет, раз уж взялись собирать велосипеды: если меняете глобально параметры сервера из скрипта, делая вещи типа таких:
-- включим xp_cmdshell (нужно для удаления старых бэкапов)
EXEC sp_configure 'show advanced options', 1; EXEC sp_configure 'xp_cmdshell', 1; RECONFIGURE WITH OVERRIDE;Показательно, что при более простой реализации через Планы обслуживания (название намекает, правда?) ничего этого ни пришлось бы делать, как и хардкодить переменные в скрипт. Это и имел в виду: ваше решение ни разу
- Не «более простое»: пользователю сначала нужно ручками «причесать скрипт», а для этого — минимум понять, что там накодировано, и зачем. И так — для каждой бэкапируемой базы. «Из коробки» ваш скрипт не работает;
- Не «более предсказуемое»: мы никогда не узнаем, что «что-то пошло не так», т.к. в скрипте нет никаких логов / алертов. Недоступно «захардкоженное» расположение бэкапа (не работает сеть)? Мимо. Не получилось удалить старую копию (нет прав)? Мимо. Целевой диск бэкапа полон (нет места)? Мимо. Никакой обработки ошибок в скрипте нет. Ну и непредсказуемое изменение глобальных параметров сервера не добавляет предсказуемости;
- Не «легко мониторить»: см. п. 2 выше. В плане мониторинга ваш скрипт сам по себе вообще ничего не может. Ну а внешними средствами его мониторинг ничем не отличается от мониторинга других скриптов и планов бэкапа;
- Не «легко настраивать»: см. п. 1 выше.
- Ну и от меня: не имеет никаких преимуществ перед штатным более простым решением, оправдывающих 4 пункта недостатов.
Вы по сути воспроизвели штатных функционал SQL Server в урезанном и упрощённом виде. Это может быть полезно для личного развития, но выкладывать на всеобщее обозрение — зачем?
А потом приходят админы и дико матерятся, продираясь через заросли подобных скриптов, в поисках причины — почему ничего не работает…
Maintenance Plans не очень удобно поддерживать и тиражировать, когда у вас десятка два серверов и штук двести баз.
... а когда серверов - 200, а баз - 2000 - вообще мрак.
Соглашусь
Maintenance Plans — это решение для простого и быстрого выполнения типовой задачи, которой является бэкап баз данных.
В моём комментарии речь о том, что предлагаемые автором заметки скрипты не дают ничего сверх того, что может предложить штатный функционал. А ручной работы в итоге — больше: поправить каждый скрипт (т.к. в них всё захардкожено), создать джоб, настроить права и расписание… Через Maintenance Plans это делается быстрей и гибче. Кстати планы можно то же создавать скриптом, если мне не изменяет память…
Для массового обслуживание конечно надо применять соответствующие средства — либо какие-то проприетарные продукты, либо самому выстраивать схему. Я например через Powershell это всё делаю, но можно и другие средства юзать.
В целом суть моих постов — что ничего хоть сколько-нибудь нового в заметке нет: подобными скриптами забиты все форумы SQL-щиков, в том числе на русском: за 5 минут можно найти гораздо более универсальные и продвинутые варианты.
Один раз настроил задание агента и залил скриптом на все серверы. Зачем проприетарные продукты, здесь все прозрачно и вы можете под себя подстроить любой момент. Но еще раз повторю, каждому своё. Мне удобно, делюсь со всеми, знаю много людей, кто любит простые и удобные штатные средства
Ну поищите подобные скрипты по забитым форумам, они все либо не полноценны, либо не универсальны
для создания бэкапов "длительного хранения". Создаются с опцией ONLY_COPY и не участвуют в общей цепочке восстановления
Э-э-з, что простите? С какого перепугу Copy_Only предназначен для длительного хранения? Сами же пишете - "он не участвует в цепочке восстановления", т.е. фактически это "неофициальный бэкап". Обычно используется для развертывания базы где то на тестовом контуре, чтоб как раз не очищал транзакции и не висел в цепочке бэкапов. Хотя по правильному и на тестовый контур берется и накатывается обычный, нормальный Full бэкап с определенной периодичностью.
Кавычки видим же? Что в нем не официального? Просто флаг архивации не сбрасывается со страниц. У меня есть требования хранить 5 лет, я и храню таким способом длительные периоды, основной скрип делает ретеншены
Например я так копии "на момент окончания отчетного периода" храню.
Они должны храниться вечно, но при этом не подразумевается, что их когда-то развернут для восстановления оперативной операционной базы. Ну, в случае атомной войны разве что.
Они должны хранится согласно политике компании и да, они не для восстановления оперативной БД
Про политику я в курсе, в разных компаниях она разная, но присутствует.
Мой вопрос был конкретно, с чего взяли что именно COPY_ONLY предназначено для длительного хранения, и чем для этих целеей не подходит обычный фулл бэкап (сакжем на 31 или 01 число)? Пруф есть или просто Вы так считаете? Если последнее, то надо было так и писать что "для своего (фирмы) удобствая создаю для длительного хранения бэкапы COPY_ONLY", а не категоричное утверждение "для создания бэкапов "длительного хранения создаются с опцией ONLY_COPY"
А где категорично то? Я с самого начал пишу, как нравится так и кроите ) only_copy просто не сбрасывает со страниц бд метку... Такая же копия как и все другие, только в цепочке восстановления не фиксируется )
Скрипт архивации баз данных Microsoft SQL Server с полной моделью восстановления