Oracle пользователь падение проверка

Question

DB: Oracle11gR2

ОС: Linux

Я хочу отказаться от пользователя USER1 Oracle, которая уже заблокирована в течение нескольких недель.

Я могу запустить "drop user USER1 cascade;", чтобы удалить пользователя, но перед удалением хочу подтвердить, что никто не использует или не использует объекты после того, как пользователь был заблокирован.

1. Как проверить в Oracle, что никто не имеет доступа или не имеет доступа к объектам USER1 в прошлом месяце или около того?
2. Есть ли доступ к запросу/представлению db, который мы можем использовать, чтобы убедиться, что безопасно запускать команду DROP?

Благодаря

Answer 1

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

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

• Вы можете запросить v$segment_statistics присоединился к v$statname, чтобы посмотреть на различных статистических данных о сегментах таблицы. Например, «db block gets» и «consistent gets» покажет вам, сколько раз какой-то процесс выполнял текущее или последовательное чтение в блоке в таблице. Но он не скажет вам, что читали: фоновая работа, которая собирает статистику, например, может читать данные из таблицы. Эти таблицы должны накапливать данные с момента последнего перезапуска базы данных, который может быть значительно длиннее или короче, чем интересующий вас период времени. Вы можете получить list of the available statistics в документации Oracle, чтобы точно настроить именно то, что вы хотите найти.
• Вы можете запросить dba_hist_seg_stat, а не v$segment_statistics. Это вырвет статистику по периоду времени, чтобы она рассказывала вам о том, когда происходит чтение и запись. Но он не скажет вам, кто их сделал. Это также требует, чтобы у вас была лицензия на использование AWR (иначе запрос таблицы может нарушить вашу лицензию и создать проблему, если вы когда-либо проверялись).
• Вы можете посмотреть dba_dependencies, чтобы узнать, зависят ли объекты от объектов, принадлежащих данному пользователю. Но это будет работать только для сохраненных объектов (просмотров, процедур и т. Д.). Он не будет захватывать информацию о операторах SQL, которые отправляются из приложений или специальных запросов, выпущенных пользователями.

Если вы не хотите, чтобы включить аудит и ждать соответствующий период, вы можете быть лучше служили отменив льготы на user1 объектов от того, что роли/пользователи имеют их, а не сбросив объекты сразу. Таким образом, если что-то взрывается из-за отсутствия привилегий, относительно легко восстановить привилегию, не возвращая объект (ы) из резервной копии. Вы также можете создать триггер по ошибке, разрешенной с разрешения, которая сообщила вам, откуда пришел запрос.