Коллеги, привет.

Кратко: насколько потенциально опасно делать DB-LINK на другую схему в ту же базу?
Грант не помогает :(

Детально:
Находимся в схеме-1 (C1). Есть вторая схема (C2), где надо вызвать функцию F (сторонний вендор, куча кода). Эта функция использует вызов функции sys_context(). Контекст же устанавливается триггером на LOGON.
Если коннектимся на схему S2: триггер отрабатывает, у функции один результат.
Если коннектимся на схему S1: права вызова через грант, триггер не отрабатывает, у функции другой результат.
Получается запустить, если сделать DB-LINK в пределах одной базы со схемы-1 на схему-2.
Насколько это опасно? Ну вдруг оракл не рекомендует такой финт. Вроде бы тесты работают.

Ну или вдруг подскажете решение проще?
Спасибо.

shurka22,
Сам себе отвечу: есть решение без ДБ-линка, если на схеме-1 повторить логику триггера схемы-2 ON LOGON. Надо разбираться в логике этого кода, он местами завязан на USER. В общем затея возможная, но не самая простая.

A Kно в вашем случае, насколько я правильно вас понял, нужно создавать хранимки с invoker_rights_clause.
Вы про authid current_user? Кажется, что мне это не поможет.

У меня случай такой: процедура в схеме-2 отрабатывает корректно при следующих условиях:
1) сработал триггер ON LOGON, который устанавливает переменные контекста
2) запрос "SELECT USER FROM DUAL" - возвращает значение "схема-2". На это завязана как минимум раздача неких прикладных прав.

При вызове через DB-link оба условия выполняются.

При вызове через гранты:
1) триггер мы можем щёлкнуть вручную
2) но подменить USER - мне представляется проблематичным. Или как-то можно?

ElicСогласовать со "сторонним вендором" не хакерский, а легальный способ взаимодействия - не судьба?
Видимо да, не судьба.
Руководство настаивает на анализе кода стороннего вендора, и написании аналога кода, чтобы делать то же самое, но со схемы-1.
Аргументы: нецелевое использование ДБ-линка. Используем не так, как задумал оракл. Уж лучше вообще отказаться от решения задачи, чем через такой дб-линк. Петлю из двух дб-линков (на вторую базу, и потом назад) - тоже отвергли.
Сейчас задача решена через джоб: на схеме-1 создаём задание для джоба. На схеме-2 время от времени запускается джоб, который исполняет это задание. Криво, долго, не синхронно, но работает.

я бы переформулировал задачу так:

Как из схемы-1 (user-1) вызвать процедуру П() на схеме-2 (user-2), чтобы эта процедура выполнилась, как будто мы зашли в оракл и выполнили её от имени user-2?

А именно:
1) щёлкнулись все триггеры, которые щёлкаются при логине user-2. Это ON LOGON, может быть что-то ещё есть.
2) "select user from dual" говорил бы именно user-2, а не user-1 (user-1 он скажет, если мы просто дадим грант, и позовём из схемы-1).
3) что-то ещё?

Viewer https://oracle-base.com/articles/misc/proxy-users-and-connect-through#proxy-user-and-connect-through
?
Как я понимаю, вы предлагаете user-1 сделать прокси-пользователем для user-2. Так? То есть залить все объекты схемы-1 в схему-2.
Это можно сделать и без прокси-пользователя. Но крайне нежелательно, а скорее - невозможно. Обе схемы очень большие, старые, давно работают.

ElicНе так, как задумал вендор . Голь на выдумки хитра?
Ну вдруг есть более изящное решение? ДБ-линк на ту же БД - он мне и самому не сильно нравится. Просто я не вижу решения дешевле.

Viewershurka22Как я понимаю, вы предлагаете ... залить все объекты схемы-1 в схему-2
Это ваши домыслы...
Вы же хотели:
shurka221) щёлкнулись все триггеры, которые щёлкаются при логине user-2
2) "select user from dual" говорил бы именно user-2, а не user-1
Всё верно. Видимо я вас не понял.

Давайте по шагам:
Схема-1/user-1, схема-2/user-2 - остаются без изменений.
Создаём user-3, который прокси-пользователь для user-2.
То есть логинимся как user-3, но получаем все права, как user-2.
Как я понимаю, схемой для user-3 будет схема-2. Да пусть даже и схема-3 - это не важно.

А дальше-то что?

Когда я из под пользователя user-1 пойду вызывать процедуру схема2.П() (по любой цепочке, через схему-3, или напрямую), то "select user from dual" у меня всё равно будет user-1, а не user-2. То есть процедура П() отработает неверно.

Staxshurka22,
общаться между сессиями (user1/user2) можно через dbms_pipe

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

ElicЕщё раз. Не "ломайте" вендора. Лучше договоритесь с ним.
Вендор уже "поломан" :)
Часть логики вендора уже переписана (до меня).
Видимо, придётся и тут грызть гранит.

Staxshurka22,
с помощью джоба как узнаете результат?

Как узнаЁм сейчас?
Никак не узнаём - в этом-то и беда, асинхрон у нас. Ну то есть узнаём, но позже. Это и есть главная проблема.

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

Staxpipe не панацея, а как один из вариантов
user1 может через pipe общатся с user2,
не только просить запуск процедуры но и как дела, чем занят, настроение и тд
Спросить-то можно, ответ в синхронном режиме никак не получить.

Viewer

Спасибо, теперь понял. Видимо всё равно не годится.
Мы не просто вызываем функцию схема2.П() из схемы-1, а из процедур/функций схемы-1. Все обработчики коннектятся на схему-1 и работают с объектами схемы-1. И вот одна из функций схемы-1 (пусть схема1.Ф1()) хочет вызвать процедуру схема2.П(), причём вызвать так, как будто бы схема2.П() исполнялась бы из под пользователя user2. Вызвать, и сразу (в синхронном режиме) получить результат работы - от ответа будет зависеть дальнейшая логика функции схема1.Ф1().

Staxразработать протокол диалога user1 i user2
Всё так.
Сейчас всю эту задачу может решить ДБ-линк. Получится куда как проще, дешевле и надёжнее. И время отклика будет на порядки быстрее.
Я и спросил: нет ли более изящного решения, чем ДБ-линк?