Уже некоторое время висит пара (тройка) вопросов, положительных ответов на которые сходу не нашёл:
1) Можно ли скриптом создать Maintenance Plan (в частности для бэкапа)?
1.а) Или можно ли создать Maintenance Plan сразу для множества серверов через GUI.
2) Можно ли накатить на существующую базу transaction log (пример использования: восстановлена виртуалка с базой данных, хотелось бы без полного переразворачивания базы накатить произошедшие изменения).
3) Посоветуйте софт для управления большим числом баз MSSQL (интересует прежде всего управление бэкапами — отслеживание состояния, настройка), очень желательно лицензирование не по хостам MSSQL, иначе цена выйдет неприятная.
4) Сейчас бэкап серверов у нас делает так: на всех серверах есть Maintenance Plan который бэкапит все базы на выделенную шару, с ограниченными правами доступа. Проблема в том, что для развёртывания базы на тестовую виртуалку (обычно каждый раз новую) требуется добавить права для учётки этой виртуалки для каталога. Это слегка неудобно. Может кто-то сталкивался с такой проблемой и реализовал какой-то другой вариант выдачи доступа (желательно без изменения учётки под которой работает MSSQLSERVER на доменную — этот вариант уже обдуман, хотелось бы другие услышать).
5) Восстановление отдельной таблицы из бэкапа — есть софт кроме RedGate и Apex? (Их цены заставляют сильно задуматься настолько ли оно нам надо...)
Здравствуйте, Somescout, Вы писали:
S>Уже некоторое время висит пара (тройка) вопросов, положительных ответов на которые сходу не нашёл: S>1) Можно ли скриптом создать Maintenance Plan (в частности для бэкапа)?
Скриптом можно сделать задание (Job), которое будет запускаться по расписанию и выполнять бэкап БД. Планы обслуживания, в отличие от заданий, более сложны в реализации и представляют собой SSIS пакет. Его можно обнаружить если подключиться к SSIS экземпляру.
S>1.а) Или можно ли создать Maintenance Plan сразу для множества серверов через GUI.
Как раз для вашей задачи, а именно управление планами обслуживания и заданиями в много серверной среде было реализовано мультисерверное администрирование. Когда задания и планы, созданные на master сервере могут выполняться на подчиненных серверах. Смотрите Multi-Server Administration, например статья с картинками SQL Server Multi Server Administration
S>2) Можно ли накатить на существующую базу transaction log (пример использования: восстановлена виртуалка с базой данных, хотелось бы без полного переразворачивания базы накатить произошедшие изменения).
Для восстановления журнала транзакций необходимо, чтобы БД находилась в режиме восстановления, т.е. была готова принять журнал транзакций, а это значит что как минимум нужно восстановить полный бэкап. Просто взять БД, находящуюся в оперативном режиме и накатить на нее журнал транзакций у вас не получится.
Здравствуйте, Olaf, Вы писали:
S>>1) Можно ли скриптом создать Maintenance Plan (в частности для бэкапа)? O>Скриптом можно сделать задание (Job), которое будет запускаться по расписанию и выполнять бэкап БД. Планы обслуживания, в отличие от заданий, более сложны в реализации и представляют собой SSIS пакет. Его можно обнаружить если подключиться к SSIS экземпляру.
Я в курсе, вопрос был "можно ли создать их скриптом (и как это сделать)"
S>>1.а) Или можно ли создать Maintenance Plan сразу для множества серверов через GUI. O>Как раз для вашей задачи, а именно управление планами обслуживания и заданиями в много серверной среде было реализовано мультисерверное администрирование. Когда задания и планы, созданные на master сервере могут выполняться на подчиненных серверах. Смотрите Multi-Server Administration, например статья с картинками SQL Server Multi Server Administration
Правильно я понимаю что управление заданиями осуществляется через мастер-сервер и если, например, не будет связи то и задания не выполнятся?
S>>2) Можно ли накатить на существующую базу transaction log (пример использования: восстановлена виртуалка с базой данных, хотелось бы без полного переразворачивания базы накатить произошедшие изменения). O>Для восстановления журнала транзакций необходимо, чтобы БД находилась в режиме восстановления, т.е. была готова принять журнал транзакций, а это значит что как минимум нужно восстановить полный бэкап. Просто взять БД, находящуюся в оперативном режиме и накатить на нее журнал транзакций у вас не получится.
Я в курсе насчёт режима восстановления, интересно было можно ли с помощью стандартных или сторонних средств перевести рабочую базу в такой режим (или как вариант распарсить логи транзакций и внести изменения в базу из них). Просто при mirroring'е одна из баз всегда находится в режиме восстановления, и при failover'е происходит переключение базы из рабочего режима в режим восстановления на одной ноде (и в рабочий режим на другой).
Попробовал — как-то не очень: монтирование мелкой базы (10ГБ) прошло в целом нормально, хоть и не быстро, а вот основная база (~700ГБ бэкап) — по сети монтируется уже час, и прогресса пока не видно. Учитывая что восстановление из бэкапа занимает часа 4, как-то так себе.
Здравствуйте, Somescout, Вы писали:
S>Правильно я понимаю что управление заданиями осуществляется через мастер-сервер и если, например, не будет связи то и задания не выполнятся?
Задания и планы после создания на главном сервере, распространяются по целевым серверам, т.е. физически на них создаются. Если связь оборвалась между серверами, максимум на что это повлияет, так на создание новых объектов, обновление существующих и обратную связь с целевых серверов, т.е. передачу данных об исполнении обратно на главный сервер. Но сами планы и задания будут выполняться в отсутствии соединения между серверами.
Здравствуйте, wildwind, Вы писали:
S>>Интересный вариант, особенно учитывая что часто требуется влезть в бэкап недельной давности.
W>Откуда возникают такие задачи, если не секрет? На прикладном уровне нет средств для копирования данных из одной базы в другую?
В текущей базе что-то сломали — нужно получить данные из таблицы недельной давности, бэкап при этом весит 600ГБ. Если бы можно было восстановить только одну таблицу, это было бы сильно удобнее чем разворачивать всю базу целиком.
Здравствуйте, Somescout, Вы писали:
S>В текущей базе что-то сломали — нужно получить данные из таблицы недельной давности, бэкап при этом весит 600ГБ. Если бы можно было восстановить только одну таблицу, это было бы сильно удобнее чем разворачивать всю базу целиком.
Но если такая необходимость возникает часто, если это часть процесса, значит с процессом что-то не так.
Здравствуйте, wildwind, Вы писали:
W>Но если такая необходимость возникает часто, если это часть процесса, значит с процессом что-то не так.
Часто — это не значит "на регулярной основе". Это просто значит часто, несколько раз в год, например. Может возникнуть ошибка в приложении, может злой умысел, может сбой репликации, может косяк разработчиков, может просто желание посмотреть что менялось в таблице. Во всех этих случаях разворачивается бэкап соответствующей базы данных.
Вариант с монтированием бэкапов был бы идеальным решением, если бы не был настолько тормозным.
