Локшин Марк 18-я весна по-моему логично: нет никакой разницы у вас нет прав на таблицу или таблица не существует - доступ к ней одинаково невозможен.
Права - они относятся к пользователю, а таблица - к схеме данных. Схема данных - она общая, а права индивидуальны для каждого пользователя. Изменение схемы данных редкое событие в рабочей базе, а вот добавление/изменение прав пользователя - может быть весьма часто. Что с того, что у кого-то нет прав на этот запрос. Может он его и никогда исполнять не будет? Может у него и прав на этот запрос вообще никогда не было. Согласно этой логике его вообще в кэш помещать нельзя. Кэш - он же общий.
И такое видение имеет право на существование.
Только не надо забывать что кеширование - это оптимизация использования ресурсов.
Тогда если у юзера забирают права, значит он скорее всего этот запрос никогда уже не выполнит, поэтому лучше освободить кеш для других запросов.

А касательно частоты изменения прав, я не могу согласиться. На мой взгляд в достаточно большом приложении структура схемы изменяется не менее часто чем права. Ну или по крайней мере так же редко :)

tru552 18-весна

Проверил приведенный запрос на 10.2.0.1 Enterprise Edition. Действительно, запрос исчезает. Более того, он исчезает даже при выполнении команды GRANT на этот объект (что из приведенной логики уж никак следовать не должно). Кроме того, если пользователю 1 и 2 выдать права на этот объект, выполнить запрос по пользователем 1, а отнять права у пользователя 2 - тоже исчезает. Поскольку в Oracle 9.2.0.8 это не так, т.е. там этот запрос остается, то у меня такое впечатление, что это баг (хотя прямых доказательств пока не нашел)


Скорее всего при повторном назначении права происходит неявный отбор предыдущего назначенного этого же права. Тогда все сходится.


1. Тогда если у юзера забирают права, значит он скорее всего этот запрос никогда уже не выполнит, поэтому лучше освободить кеш для других запросов
Да, но этот запрос вполне может выполнить другой пользователь (особенно, если этот запрос выдается из общего приложения). Если бы кэширование осуществлялось "по-пользовательно", то запросы бы располагались в PGA (памяти процесса), а не в SGA, которая доступна ВСЕМ процессам

Возможно те кто делал эту зависимость в Оракле посчитали (как и я считаю), что операция revoke настолько редка, что можно пренебречь очисткой кеша.


2. А касательно частоты изменения прав, я не могу согласиться. На мой взгляд в достаточно большом приложении структура схемы изменяется не менее часто чем права.
Это если база девелоперская. На продакшн базе структура, как правило, достаточно статична, чего нельзя сказать о составе пользователей
Я имел в виду, что большое приложение часто патчится, в т.ч. и структура БД.

PS.
Anatoly Moskovsky==18-весна

tru55Сорри, еще раз проделал эксперимент - при REVOKE роли запрос виден в v$sql, при этом в колонке INVALIDATIONS - 0

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

Локшин Марк Anatoly MoskovskyВедь если используется роль, то вероятность, что объект будет использован многими пользователями намного больше, чем при прямом назначении права.
(1)Извините, но это какой-то бред, на уровне "операция сложения менее вероятна операции вычитания". Кэш он на то и кэш. Неиспользуемые объекты из него вытесняются по мере заполнения. (2)И почему если одному пользователю дали права, то второму также дать не могут - совершенно не логично.
1. Не извиняем :)
"вытесняются по мере заполнения" это всего лишь один из способов использования кеша.
Есть как минимум еще два подхода - фоновая очистка кеша от редкоиспользуемых объектов и немедленная (по некому событию) очистка кеша от таких объектов.
Это может иметь смысл когда вероятность сценария "объект есть в кеше но невалиден -> удаление объекта из кеша" больше чем вероятность "объект есть в кеше и валиден" и при этом операция проверки валидности занимает ощутимое время (а с проверкой прав так оно и есть). Поэтому такую операцию лучше перенести на некритичные по времени события (например на отбор прав)
2.
Нелогично потому, что Вы рассматриваете систему в которой всего два пользователя.
А обсуждаемые эффекты сказываются на системах с большим кол-вом пользователей.
А там никто не назначает права напрямую, а только через роли. Или по крайней мере, IMHO, так считают разработчики Оракла :)
Таким образом использование ролей косвенно свидетельствует о масштабах БД и поэтому там используются другие подходы по управлению кешем.