Синоним Oracle случайно не отображается

вот сложный случай, над которым 5 человек, включая администратора баз данных, боролись в течение нескольких дней ... Я предлагаю пожизненное рассмотрение тому, кто определит основную причину проблемы.

вот:

Клиент Oracle: 10g Сервер Oracle: 11g

У нас есть 2 схемы и 1 пользователь:

SCHEMA1

SCHEMA2

USER

У нас есть 1 таблица 'TOTO', которая определена в SCHEMA1 (SCHEMA1.TOTO). У нас есть частный синоним таблицы 'TOTO', называемый 'TOTO', определенный в SCHEMA2, созданный следующим образом:

CREATE SYNONYM SCHEMA2.TOTO FOR SCHEMA1.TABLE1;

Мы предоставили привилегии SELECT, UPDATE, DELETE, INSERT для «SCHEMA2.TOTO» (так что это синоним) для SCHEMA2 (так что любой сеанс, запущенный из SCHEMA2, имеет доступ к таблице синонимов)

GRANT SELECT, UPDATE, DELETE, INSERT ON SCHEMA2.TOTO TO SCHEMA2;

Наше приложение подключается к БД с USER, затем напрямую переключается на SCHEMA2:

ALTER SESSION SET CURRENT_SCHEMA=SCHEMA2;

Затем, после этого, он пытается выполнить запрос на выборку в таблице синонимов БЕЗ префикса имени синонима SCHEMA1 (это ограничение используемой нами структуры):

SELECT COL FROM TOTO;

В большинстве случаев этот запрос работает успешно, чего мы и ожидали, поскольку мы изменили нашу сессию на SCHEMA2, по умолчанию, где просматриваются объекты.

Но иногда это не удается, с ошибкой ORA-00942: table or view does not exist.

Я настаиваю на том, что между временем, когда оно работает, и временем, когда оно не работает, ничего не изменилось, мы просто перезапустили приложение (которое, конечно, переподключается к БД одинаково при каждом запуске). Мы были исследованы с помощью администратора баз данных, отслеживающего все события в USER, SCHEMA1, SCHEMA2 в надежде найти внешний процесс, изменяющий GRANTS на одном из них, между успехом и неудачей, но ничего не меняется. Тем не менее, в какой-то момент случайным образом мы получаем ошибку ORA-00942, затем мы несколько раз перезапускаем приложение, и оно снова возвращается...

Может у кого-нибудь есть идея или какое-либо предложение/подсказка, которые могли бы помочь нам определить, что нам здесь не хватает?

Большое спасибо за вашу помощь!


person xaxa    schedule 29.11.2012    source источник


Ответы (1)


Грант должен быть отправлен на USER, а не на SCHEMA2:

GRANT SELECT, UPDATE, DELETE, INSERT ON schema1.toto TO userxy;

Это должно решить проблему. Если это не так, можете ли вы опубликовать результат

SELECT * FROM all_objects WHERE object_name='TOTO';
person wolφi    schedule 29.11.2012
comment
Кажется, это решает проблему и дает понять, как это должно быть сделано. Спасибо! Однако мне все еще трудно понять, почему иногда он работает без него ... очевидно, что не должен, поэтому должен быть внешний фактор, который мы не учитываем (вероятно, в инструментах и ​​​​среде, которые мы используем для создания нашей схемы) который возится с ГРАНТАМИ ПОЛЬЗОВАТЕЛЯ. - person xaxa; 30.11.2012
comment
Вы убедились, что GRANTS не меняются, поэтому на ум приходят только три дополнительных подозреваемых: 1) измененный PUBLIC SYNONYM, который обходит разрешение имен, 2) измененная ROLE, такая как DBA или SELECT_CATALOG_ROLE, которая обходит систему предоставления или 3) поменял подключение AS SYSDBA. Однако все три довольно маловероятны. - person wolφi; 30.11.2012