авторЕсть ли способ позволить тестировщикам портить эту БД без предварительной
необходимости резервировать ее по 3+ часа и восстанавливать в последствии, если
что-то пойдет не так?
авторБД - Oracle 12c EE, non-CDB.
авторНо тестировщики не хотят по очереди.
Им хочется, что бы каждому по своей "песочнице".
Варианты есть. Только это будет, в любом случае, DIY-велосипед.
Тут уже предлагали oracle clonedb.
В принципе, под размеры вашей бд - технология может дать работающее, до некоторых пор, решение.
Потребует, только, image-copy бэкапа исходной бд и, м.б. есть резон разворачивать клон бд в фс поддерживающей сжатие, что нибудь типа gzip1
Ещё можете упереться в необходимость постоянной доступности и актуальности Image-copy бэкапа, из которого клон(ы) лепятся - тестовые бд.
Тут: зависит от того какие требования у вас к строительству тестовых бд.
Если, например, будет обстановка с требованиями по провижененигу песочниц такая то запросы, на пеочницы, появляются типа такие - "вот прям щаз нада, и шобы - актуальна всё".
Ну тогда, лепить такую тестовую бд из бэкапа который, например, по регламенту b&r раз в неделю по выходным готовится - не подойдёт.
CloneDB, если правильно помню, можно догонять инкрементами/арх-логами, но это - очень так себе вариант, в смысле потребления дисковой ёмкости, по тестовую бд и времени её лепления.
Т.е. надо будет, в таком случае, связываться с чем то вроде обновляемого инкрементами image-copу бэкапа исходной бд.
По рабоче-крестьянски можно сделать так, концептуальная план-схема:
1) На стороне площадки, на которой лепите тестовые базы, соорудить себе физическую standby-бд, от исходной базы.
Пусть она, эта standby-бд постоянно актуализируется.
Слепить её можно и нужно, опять же, в чём нибудь что даёт более гуманное потребление дисковой ёмкости, т.е. какая то фс поддерживающая сжатие. Под виндами - не знаю что. По линуксами, ну ZoL - вполне себе, для тестовой среды, вариант. btrfs, не знаю, допилили/не допилили, емнип былотам сжатие.
2) физическая standby-бд вам провайдит актуальную, побитовую копию продакт-бд. Ну и дальше - что позволит баланс ресурсов/требований к строительству тестовых бд.
Например, если у вас 12сEE и ресурсы площадки позволяют, и, к примеру, тот же ZoL (или какой то его функциональный аналог) можете
2.1) поднять, отдельно, контейнерную бд.
2.2) по требованию слепить тестовую бд - останавливаете актуализацию standby-бд.
Лепите снапшот-фс для фс-а в котором живёт физ. компонента опорной standby-бд.
Это быстро и минимально по дисковой ёмкости.
К этому снапшоту лепите клон-фс. Может быть с компрессией какой то, если требования к продуктивности позволяют.
2.3) Подсовываете нужный конфиг субд, такой чтобы на контрольники ссылался во внось слепленных фс-ах. Запускаетесь с ним, оно запуститься до маунта и будет работать с датафайлами вот в новых фс-ах.
Ну переименовываем бд, меняем dbid и вот - получили отдельную тестовую базу, актуальную, за минимум времени.
2.4) запустить опорную standby-бд - её никто и никак не трогал, когнфликта по имени бд - не будет. Запустить процесс её актуализации.
2.5) рихтовка вновь полученной бд, для перевода ея из статуса побитовой кальки исходной бд, в статус тествой бд. Ну там спойлинг табличных данных (если надо), и т.п. и т.д.
Вот, всё вполне себе быстро и спортивно.
Это по теме - скоростного и дешёвого лепления тестовых бд.
По второй части вопроса: про быстрый откат тестовой бд к исходному (до тестов) состоянию.
Ну тут всё зависит от возможностей и потребностей.
Если, например, баз тестовых у вас немного (ну к примеру 2-3-4-5 шутк, такого порядка) и ресурсы серверной площадки под тестовые базы - позволяют наплодить/запустить на ней несколько экземпляров/баз - ну тогда, для того чтобы сделать откат после теста можно воспользоваться функционалом ZoL - снапшоты.
Если баз данных тестовых надо лепить много больше, ну тогда, держать стандалонами, тестовые бд, на тестовой площадке - будет дорого, по кол-ву памяти для них для всех.
И, тогда, как вариант и потому что у вас 12с - pdb.
Т.е. поставить, на эту серверную площадку контейнерную бд.
И, план выше - расширить: после получения новой тестовой бд - заводить её, как плагабле-базу, в эту контейнерную бд.
Откат и тут можно сделать, тоже, концептуальная план-схема:
1) Остановка плагабле-бд. Создание снапшота для фс, в котором живут датафайлы данной pdb; Запоминаетм сцн соответствующий моменту создания снапшота. Открываем пдб
2) тесты разработчиков в этой пдб.
3) Откат:
3.1) Остановка данной пдб, анплаг и дроп, с опцией "keep datafiles"; При анплаге - варится дескрайб-файл, он будет нужен позже.
3.2) роллбак фс-а, в котором живут датафайлы данной pdb, к снапшоту созданному перед тестами разработчиков.
3.3) реплейсить, в дескрайб файле, сцн-ы, в метаданных для датафайлов. Тут уже плохо помню, fcpsb чего то там, атрибут xml-я.
Смысл в том чтобы задать, в метаданных desc-файла, сцн-значение соответствующее времени создания снапшота, к которому сейчас откат делался.
3.4) создать пдб, с данным дескрайб-файлом, с опцией nocopy - файлы уже есть. открыть эту пдб
это, как бы, не готовый рецепт, конечно.
смотреть надо - насколько подходит/не подходит к вашим условиям/требованиям.
Например если у вас разработчики нагрузочным тестированием занимаются, не функциональным: ну, вот это вот всё что я тут выше живописал - вряд ли.
В тему:
