Rust(),

Разделить можно на уровне владения объектами.

Создать на каждую из команд свои группы (мы делаем в домене).
Завести N "сервисных" аккаунтов под работу с БД (создание и владение объектами).

Каждой из команд выдать права на переключение в соответствующий сервисный аккаунт:


и обязать при подключении переключаться в этого пользователя (можно делать автоматически по принадлежности к группе в CONNECT процедуре - см. AUTH_LIST_GROUPS_FOR_AUTHID() и SYSTEM_USER special register ).

Выдать также каждому аккаунту права на своё/свои табличные пространства.
На схемы - CREATE IN (остальные права получат по факту владения объектами).

Единственный специализированный владелец для группы объектов - очень упорядочивает maintanance системы.


Останется добавлять/убирать пользователей из групп, что уже задача совсем не DB администратора.

PS Правильно также заставлять разработчиков с самого начала выдавать привилегии доступа для соответствующих аккаунтов приложений, а не делать доступы полностью открытыми (PUBLIC).

Andron,

Если я правильно понял, то есть желание работать с разными наборами данных в одной логической структуре.
Причём не столько разработчикам (которым был бы доступен исходный код), а скорее каким-то операторам/тестерам.

Чисто теоретически это позволит сделать "Row and column access control (RCAC)", представленный в 10-ке.
Но делать это только для того, чтобы развести команды по своим датасетам (к которым ещё придётся придумывать условия на каждую таблицу, чтобы разделить, где чьё) - полнейшее извращение, чреватое труднопредсказуемыми бедами в дальнейшем.

2 разные бд и формализация процесса наката обновлений/изменений структуры (строго на обе БД сразу) - то, что можно предложить в подобной ситуации.
Maintenance же скриптуется и ему всё равно, две базы обслуживать или одну.