Oracle SYS.AUD мониторинг $/dba_audit_session - оптимизировать производительность SQL

Question

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

SELECT COUNT (OS_USERNAME) 
FROM DBA_AUDIT_SESSION 
WHERE USERNAME IN ('USER1','USER2','USER3') 
AND TIMESTAMP>=SYSDATE - 10/(24*60) 
AND RETURNCODE !='0' 

К сожалению, производительность этого SQL довольно беден так как он TABLE ACCESS FULL на sys.aud $. Я попытался сузить его с помощью:

SELECT COUNT (sessionid) 
FROM sys.aud$ 
WHERE userid   IN ('USER1','USER2','USER3') 
AND ntimestamp# >=SYSDATE - 10/(24*60) 
AND RETURNCODE !='0' 
and action# between 100 and 102; 

И это еще хуже. Возможно ли вообще оптимизировать этот запрос, заставляя оракул использовать индексы здесь? Я был бы признателен за любую помощь. & советов.

Answer 1

SYS.AUD $ не имеет индексов по умолчанию, но их можно создать на ntimestamp#.

Но будьте осторожны. Поддержка документа «эффект создания индекса в таблице SYS.AUD $ (Doc ID 1329731,1)» включает в себя следующее предупреждение:

Создание дополнительных индексов объектов SYS включая таблицу AUD $ в не поддерживается.

Обычно это будет конец разговора, и вы хотите попробовать другой подход. Но в этом случае есть несколько причин, почему стоит сделать это:

1. В документе далее говорится, что индекс может быть полезен и сначала проверить его.
2. Это просто индекс. Схема SYS является специальной, но мы все еще просто говорим об индексе на таблице. Это может замедлить работу или, возможно, вызвать ошибки пространства, как и любой индекс. Но я сомневаюсь, что есть шанс, что он может сделать что-то сумасшедшее, чтобы вызвать ошибки в ошибках.
3. Общепринято изменить табличное пространство контрольного журнала, чтобы таблица не была священна.
4. Я видел индексы на нем раньше. 2 из 400 баз данных, которыми я управляю, имеют индекс в столбцах SESSIONID,SES$TID (хотя я не знаю почему). Эти индексы были в течение многих лет, прошли обновление и исправления, и, насколько мне известно, не вызвали проблем.

Создание «неподдерживаемого» индекса может быть хорошим вариантом для вас, если вы готовы его протестировать и принять небольшой риск.

Answer 2

Оптимизатор Oracle 10g будет выбирать наилучший план для вашего запроса, если вы напишете правильные соединения. Не знаете, сколько recocds существует в вашем DBA_AUDIT_SESSION, но вы всегда можете использовать подсказки PARALLEL, чтобы немного ускорить выполнение.

SELECT /*+Parallel*/ COUNT (OS_USERNAME) 
--select COUNT (OS_USERNAME) 
FROM DBA_AUDIT_SESSION 
WHERE USERNAME IN ('USER1','USER2','USER3') 
AND TIMESTAMP>=SYSDATE - 10/(24*60) 
AND RETURNCODE !='0' 

Стоимость запроса сокращается до 3, чем раньше.

Answer 3

NumRows: 8080019

Так что это довольно большой из-за правил компании. К сожалению, использование /*+Parallel*/ здесь заставляет работать дольше, поэтому производительность еще хуже.

Любые другие предложения?