Дополню вас: «запустил восстановление из копии» — здесь нет восстановления БД из копии.
Не нужно копию БД «разматывать», выделять для неё место снова и снова для следующих проектных команд.
БД общая и на всех одна. Целостный, непротиворечивый и независимый доступ к ней со стороны разных команд разрабов делает движок Actifio.
В результате «бешеная» экономия железа, человеко-часов и нервов ;)
В общем-то, как часто вы будете делать инкременты, зависит от вас. Вы можете выставить произвольный график и делать их реже (раз в неделю, например).
Инкременты позволяют создавать виртуальны БД (VDB) на основе более свежих данных из продуктивной БД.
Многое также зависит от объема изменений в БД, а вот здесь у всех всё по-разному ;)
Да-да, спасибо что напомнили — в подобных решениях такая возможность также имеется (без flashback).
Выглядит как инструмент самоуправления, который можно отдать разрабам и тестерам.
Т.е. допустим они запустили в своей VDB какие-то скрипты, что-то поменяли в данных, словом работали.
Результат не понравился. Благодаря этому инструменту самоуправления сами разрабам и тестеры могут через свой, очень простой GUI инструмент оперативно «откатиться» на состояние до начала работы скрипта.
И начать всё сначала ;)
Нет, эта штука скорее не про репликацию (как у GG), но про бэкап+быстрый одновременный доступ к одной на всех физической БД.
В основе лежат стандартные API (для СУБД Oracle – это RMAN) + проприетарная файловая система вендора, на которой и лежит БД, которую все одновременно юзают через движок Actifio.
В этом решении подход на первое однократное полное копирование+инкременты day-by-day.
Разработчики, получив свою VDB вчера, вполне могут продолжать работать на ней сколь угодно долго, не докатывая новые данные. Чаще всего разрабам/тестерам супер свежая БД и не нужна.
И в общем-то ничто не мешает вам из полученной большой VDB «нарезать» мини БД для разработчиков, ручками ;)
Но есть и другие решения, которые заточены именно под создание сабсетов тестовых данных из большой продуктивной БД.
вы пишете о размерах в терабайты, и времени предоставления порядка 30 минут. При этом время копирования данных сюда входит? И эти 30 минут независимо от размера?
30 минут независимо от размера, конечно. Первичное копирование данных и докат инкрементов — это отдельные процессы. А создание виртуальной БД (VDB) — это и занимает до 30 минут, размер БД не важен. Потому что сама БД не создается, вы просто подсоединяетесь к БД, к датафайлам.
а если вас на промышленную базу просто не пустят в течение рабочего дня, а только ночью — все равно 30 минут?
Да, все равно 30 минут, потому что вы можете создать VDB из тех данных, которые вы уже скопировали.
а если база содержит персональные данные, или там PCI DSS, то программистам в контур разработки нельзя отдавать ее вместе с данными, а чувствительные данные нужно либо вычистить, либо захешировать, причем процесс этот нетривиальный, потому что иногда хочется сохранить связность, даже по тем данным, которые захешировали. И все равно 30 минут? Или такие процессы просто не предусмотрены?
Отличный вопрос. В этом случае необходимо использовать внешнюю систему маскирования. То есть создаете VDB, далее маскируете её решением и вновь создаете VDB из этой замаскированной БД, в нужном вам количестве.
а если речь не о единицах терабайт, а скажем о сотнях?
До какого размера вы масштабировали — вот эти 20 терабайт это уже много, или еще нормально?
20 TB – абсолютно нормально. С большим объемом вы будете иметь дело только один раз – когда делаете initial sync, т.е. первое большое копирование. Далее – только инкременты. Из всего этого скопированного вы и создаете VDB для ваших разрабов/тестировщиков.
Не нужно копию БД «разматывать», выделять для неё место снова и снова для следующих проектных команд.
БД общая и на всех одна. Целостный, непротиворечивый и независимый доступ к ней со стороны разных команд разрабов делает движок Actifio.
В результате «бешеная» экономия железа, человеко-часов и нервов ;)
Инкременты позволяют создавать виртуальны БД (VDB) на основе более свежих данных из продуктивной БД.
Многое также зависит от объема изменений в БД, а вот здесь у всех всё по-разному ;)
Выглядит как инструмент самоуправления, который можно отдать разрабам и тестерам.
Т.е. допустим они запустили в своей VDB какие-то скрипты, что-то поменяли в данных, словом работали.
Результат не понравился. Благодаря этому инструменту самоуправления сами разрабам и тестеры могут через свой, очень простой GUI инструмент оперативно «откатиться» на состояние до начала работы скрипта.
И начать всё сначала ;)
В основе лежат стандартные API (для СУБД Oracle – это RMAN) + проприетарная файловая система вендора, на которой и лежит БД, которую все одновременно юзают через движок Actifio.
В этом решении подход на первое однократное полное копирование+инкременты day-by-day.
Разработчики, получив свою VDB вчера, вполне могут продолжать работать на ней сколь угодно долго, не докатывая новые данные. Чаще всего разрабам/тестерам супер свежая БД и не нужна.
И в общем-то ничто не мешает вам из полученной большой VDB «нарезать» мини БД для разработчиков, ручками ;)
Но есть и другие решения, которые заточены именно под создание сабсетов тестовых данных из большой продуктивной БД.
30 минут независимо от размера, конечно. Первичное копирование данных и докат инкрементов — это отдельные процессы. А создание виртуальной БД (VDB) — это и занимает до 30 минут, размер БД не важен. Потому что сама БД не создается, вы просто подсоединяетесь к БД, к датафайлам.
Да, все равно 30 минут, потому что вы можете создать VDB из тех данных, которые вы уже скопировали.
Отличный вопрос. В этом случае необходимо использовать внешнюю систему маскирования. То есть создаете VDB, далее маскируете её решением и вновь создаете VDB из этой замаскированной БД, в нужном вам количестве.
20 TB – абсолютно нормально. С большим объемом вы будете иметь дело только один раз – когда делаете initial sync, т.е. первое большое копирование. Далее – только инкременты. Из всего этого скопированного вы и создаете VDB для ваших разрабов/тестировщиков.