Есть средних размеров база на SQL Server (чуть больше 3TB), для которой время от времени нужно сделать хитрое действие:
1) Сделать копию базы
2) Обработать копию скриптом (при этом база портится)
3) fun&profit...
Из-за размеров базы это происходит не быстро, хотелось бы в идеале постоянно держать копию базы, при необходимости её обрабатывать и откатывать результаты изменений скрипта без повторной синхронизации.
Пока наиболее перспективным вариантом выглядит запуск Log Shipping'а на отдельный сервер. Когда возникает необходимость — делаем шаги 2-3 на этой реплике, а затем запускается полная ресинхронизация.
Вопрос: может есть способ, который позволит избежать полного копирования базы после выполнения действий 2-3? Требование — всё должно происходить не на основном сервере, ибо любой сбой == секир башка...
PS. Возможно я плохо понимаю log shipping, но вроде он работает только пока база находится в recovery, а следовательно если нужно работать с базой то log shipping прерывается.
Здравствуйте, Somescout, Вы писали:
S>Из-за размеров базы это происходит не быстро, хотелось бы в идеале постоянно держать копию базы, при необходимости её обрабатывать и откатывать результаты изменений скрипта без повторной синхронизации.
Скрипт затрагивает все таблицы базы? Если только небольшую часть, то может целесообразнее
просто в портящуюся БД заливать новые данные, портить всё как надо, получать fun&profit, потом откатывать
(например при помощи снэпшота)? И так по кругу при необходимости.
Здравствуйте, _ABC_, Вы писали:
_AB>Здравствуйте, Somescout, Вы писали:
S>>Из-за размеров базы это происходит не быстро, хотелось бы в идеале постоянно держать копию базы, при необходимости её обрабатывать и откатывать результаты изменений скрипта без повторной синхронизации. _AB>Скрипт затрагивает все таблицы базы? Если только небольшую часть, то может целесообразнее _AB>просто в портящуюся БД заливать новые данные, портить всё как надо, получать fun&profit, потом откатывать _AB>(например при помощи снэпшота)? И так по кругу при необходимости.
Таблиц много, данные обновляются по множеству из них (заранее неизвестному).
Возможно ли при помощи снапшота или каким-либо другим образом возобновить логшиппинг? т.е. делается снапшот, затем проводится работа, снапшот откатывается и возобновляется логшиппинг.
Есть ещё репликация, но для неё рекомендуют регулярно делать полную синхронизацию.
Здравствуйте, Somescout, Вы писали:
S>Таблиц много, данные обновляются по множеству из них (заранее неизвестному). S>Есть ещё репликация, но для неё рекомендуют регулярно делать полную синхронизацию.
По существующей постановке задачи, я бы смотрел в сторону периодической подгрузки данных в отчетную
БД и их модифицикации там по необходимости.
S>Возможно ли при помощи снапшота или каким-либо другим образом возобновить логшиппинг? т.е. делается снапшот, затем проводится работа, снапшот откатывается и возобновляется логшиппинг.
Нет. Лог шиппинг по своей сути — это банальное восстановление цепочки логов.
Перевод БД в режим, позволяющий менять данные, автоматически эту цепочку разрушает.
Всё что остается — это полное восстановление из бэкапа и повторный накат всей цепочки логов.
Здравствуйте, _ABC_, Вы писали:
_AB>Здравствуйте, Somescout, Вы писали:
S>>Таблиц много, данные обновляются по множеству из них (заранее неизвестному). S>>Есть ещё репликация, но для неё рекомендуют регулярно делать полную синхронизацию. _AB>По существующей постановке задачи, я бы смотрел в сторону периодической подгрузки данных в отчетную _AB>БД и их модифицикации там по необходимости.
А как можно на уровне sql синхронизировать таблицы? т.е. определить минимально необходимый объём данных, которые нужно скопировать в таблицу чтобы привести её к исходной? (Если исходить из того, что я не знаю какие именно таблицы менялись и время должно быть меньше, чем развёртывание бэкапа)
(возможно с помощью стороннего софта)
Либо синхронизация баз с помощью сторонних решений.
_AB>Нет. Лог шиппинг по своей сути — это банальное восстановление цепочки логов. _AB>Перевод БД в режим, позволяющий менять данные, автоматически эту цепочку разрушает. _AB>Всё что остается — это полное восстановление из бэкапа и повторный накат всей цепочки логов.
Понятно.
Здравствуйте, Somescout, Вы писали:
S>А как можно на уровне sql синхронизировать таблицы? т.е. определить минимально необходимый объём данных, которые нужно скопировать в таблицу чтобы привести её к исходной? (Если исходить из того, что я не знаю какие именно таблицы менялись и время должно быть меньше, чем развёртывание бэкапа) S>(возможно с помощью стороннего софта)
Это зависит от самих данных.
Как вариант — иметь для каждой таблицы колонку-флаг, хранящий статус записи (синхронизирована/нуждается в синхронизации) или хранить время последнего изменения
и загружать всё измененное после определенной точки во времени.
Думаю, что кто-то может предложить и более удачные варианты.
S>Либо синхронизация баз с помощью сторонних решений.
Тоже можно. Всяких утилит по сравнению и синхронизации данных более чем достаточно,
но тут я ничего посоветовать не могу, т.к. для подобных целей я ими не пользовался.
S>Понятно.
Увы, простого решения в данном случае нет.
А что если так:
1 — делаем репликацию. Т.е. имеем всегда online актуальную копию БД на другом сервере, на котором её (БД) можно портить.
2 — перед тем как начать портить реплицируемую БД делаем следующее:
2а — останавливаем репликацию
2б — делаем снэпшот реплицируемой БД
3 — портим реплицируемую БД, fun&profit, etc.
4 — после окончания порчи:
4а — ресторим реплицируемую БД из снэпшота (это не должно занять много времени и зависит только от кол-ва измененных данных во время порчи)
4б — восстанавливаем репликацию
Там выше писали, что с репликацией якобы есть проблемы. Ну не знаю, не знаю, у нас на прод-серверах работает без проблем, технология стара как мир и лично по моим ощущениям, самая надежная. Не думаю, что с неким кастомным решением синхронизации данных будет меньше проблем, полагаю раз в 10-100 больше.
Я сам делать так, как я написал выше, не пробовал, так что критика приветствуется.
