Oracle предоставляет концессию и побочные эффекты

Question

Работая каждый день с большой производственной базой данных Oracle (10 г), мы заметили, что такие операции, как

• предоставление пользователю прав на чтение таблицы
• создание триггера на столе

заблокируйте эту таблицу и лишите законной силы все настаивающие на ней курсоры.

Это имеет огромные последствия, если таблица большая (> 20 миллионов строк) и над ней работает много пользователей.

У меня такой вопрос: почему Oracle блокирует таблицу (в конце концов, мы не меняем ее структуру, а просто даем пользователю разрешение на ее чтение) и почему ей необходимо аннулировать курсоры?

Есть ли способ сделать такие действия "более мягкими"?

Заранее спасибо.

Альтернативный вопрос : есть ли способ узнать, сколько курсоров открыто на конкретной таблице, чтобы свести к минимуму влияние недействительности на этот объект?

Answer 1

Устранение недействительности на основе грантов:

Создайте роли xxx_READONLY, где xxx - это какое-то подходящее значение, и предоставьте выборочному доступу ко всем соответствующим таблицам роль и добавьте рольпользователям, когда они им нужны.

Устранение блокировок DDL на основе создания триггера:

В прошлый раз, когда я действительно проверял, триггер был интерпретированным кодом, тогда как процедуры и пакеты былискомпилированный код.Поэтому выполнение сложной логики в триггерах, как правило, не одобряется.Можно вызывать процедуру или метод пакета в триггерах, и инкапсуляция вашей логики триггера в процедуру / пакет может ослабить или устранить блокировки DDL для базовых таблиц.

Answer 2

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

Answer 3

Не могу помочь с первым вопросом, но для альтернативы я нашел пару полезных команд здесь и здесь

Answer 4

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

Трудно понять причину, по которой предоставление привилегий на чтение может иметь аналогичные требования, возможно, просто побочный эффект от реализации.Ответ MJB кажется достойным способом справиться с этим (и во многих случаях это хорошая практика, так как упрощает администрирование прав доступа).

Answer 5

1) Мой вопрос о предоставлении доступа на чтение к таблице: почему вы предоставляете чтение непосредственно к таблице, а не создаете роль, предоставляете чтение на эту роль таблице, а затем предоставляете (или удаляете) роль пользователям ? Это устранит проблему с таблицей блокировок на грантах.

2) Oracle заблокирует таблицу при создании триггера, потому что триггер может изменить таблицу при установке. Все DDL заблокируют таблицу, создав транзакцию, чтобы точно знать, когда она может задействовать триггер (или другие изменения). Я подозреваю, что это также верно для грантов.

Если вы постоянно добавляете / удаляете триггеры из таблицы, я бы удалил код, который вы меняете, из триггера и поместил его в отдельную процедуру PL / SQL. Затем обновите процедуру по мере необходимости. Это приведет к тому, что триггер станет недействительным (и потребует перекомпиляции), что делается автоматически.

Я уверен, что есть способ выяснить, какие курсоры открываются для данной таблицы, используя представления v $ в словаре данных Oracle.

Answer 6

Групповая вещь из MJB была бы лучшим решением проблемы гранта, и для проблем «триггера» я бы рекомендовал разделить бизнес-логику так, чтобы она выполняла все, что мог бы сделать волшебный «триггер», особенно на 20. mil + таблица строк.