авторЕсть ли способ позволить тестировщикам портить эту БД без предварительной
необходимости резервировать ее по 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 - файлы уже есть. открыть эту пдб

это, как бы, не готовый рецепт, конечно.
смотреть надо - насколько подходит/не подходит к вашим условиям/требованиям.
Например если у вас разработчики нагрузочным тестированием занимаются, не функциональным: ну, вот это вот всё что я тут выше живописал - вряд ли.

В тему:

авторНо, суровые админы ОС не допустят экспериментов с файловыми
системами хоста
Так а это, тут какой хост то имеется в виду? Есть хост с продовой базой: ну, тогда серверисты - верно будут проявлять суровость, скорее всего.
Отдельную площадку надо строить, для лепления тестовых баз, по любой технологии, что CloneDB, что standby+zfs рельсы и там "вот это вот всё".

По вашей постановке вопроса - явно что не одной группе разрабтки песочница нужна и не одну песочницу надо.
Обговаривайте с лидами групп разработки, с руководством разработки/поддержки инфосисем, вашего предприятия вопрос строительства тестовой среды.
При правильной препарации-подачи расклада: они если чухнут что светит технология по которой тестовые бд, им, будут провайдится проще, быстрее - разработка встанет на вашу сторону.
Серверисты, если они чухнут что вы, вашей технологией, сможете лепить тестовые бд не создавая им работы много (ну, можно например сравнить с вариантом лепления N-виртуалок) - тоже могут встать на вашу строну.
Ну и вам тоже: все эти варианты, что CloneDB, что standby+zfs рельсы - они вполне себе 1) скриптуются 2) подводятся под какой нибудь дженкинс, чтобы вообще сдать основные операции ведения тестовых бд на самих разработчиков.
Пусть сами, когда надо, обновляют, пересоздают, откатывают свои тестовые бд, по кнопочке в www ui

Как обычно всё: таксть политесу и дипломатии на 80% дба-работы на 20%, ёмаё.