Всем доброго времени суток, уважаемые гуру.

Сабж. На днях случайно обнаружил что на одной из подконтрольных мне баз слишком сильно вырос датафайл для SYSAUX. Почти 30гб, при лимите в 32гб. Немного погуглив, разобрался что основное место заняла таблица UNIFIED_AUDIT_TRAIL.

Нашел несколько способов ее очистки, по сути все сводится к использованию DBMS_AUDIT_MGMT.CLEAN_AUDIT_TRAIL, у которого есть 2 опции

use_last_arch_timestamp => FALSE (я так понимаю в данном случае выполнится truncate и операция очистки пройдет довольно быстро)

или

use_last_arch_timestamp => TRUE (в этом случае необходимо будет сделать timestamp до которого хочу очистить записи, но как я понимаю вместо truncate будет delete и это может занять приличное время, учитывая что таблица 29гб. )

Вопрос: безопасно ли использовать подобный скрипт не используя timestamp на боевой базе в онлайне? не может ли это повлиять на rman-овские бекапы или еще на что либо?

BEGIN
DBMS_AUDIT_MGMT.CLEAN_AUDIT_TRAIL(
audit_trail_type => DBMS_AUDIT_MGMT.AUDIT_TRAIL_UNIFIED,
use_last_arch_timestamp => FALSE);
END;
/

Может ли быть связанно ухудшение производительности expdp\impdp с тем что данная таблица размерами вышла из-под контроля?

Спасибо заранее за ответы!
PS с ораклом работаю совсем недавно.

Ivan K,
спасибо большое за ответ!

пожалуй выполню именно это

BEGIN
DBMS_AUDIT_MGMT.CLEAN_AUDIT_TRAIL(
audit_trail_type => DBMS_AUDIT_MGMT.AUDIT_TRAIL_UNIFIED,
use_last_arch_timestamp => FALSE);
END;
/

судя по всему, данный пакет с опцией use_last_arch_timestamp => FALSE делает примерно тоже что вы и написали.
"TRUNCATE TABLE аудита (AUD$)"

и насколько я понял, опасаться за undo в этом случае не стоит.

после того как очистка произойдет, нужно будет сконфигурировать какой то джоб для дальнейшей очистки, или выключить самые назойливые аудит полиси, по типу ORA_LOGON_FAILURES;

Поправьте меня если я не прав.

Ivan K,

скрин приаттачил.

Попробовал потестить очистку аудита на одной из баз

BEGIN
DBMS_AUDIT_MGMT.CLEAN_AUDIT_TRAIL(
audit_trail_type => DBMS_AUDIT_MGMT.AUDIT_TRAIL_UNIFIED,
use_last_arch_timestamp => FALSE);
END;
/

Вычистило...

SQL> select count(*) from unified_audit_trail;

COUNT(*)
----------
1

select unified_audit_policies,action_name,count(*) from unified_audit_trail group by unified_audit_policies,action_name;

UNIFIED_AUDIT_POLICIES
ACTION_NAME COUNT(*)
---------------------------------------------------------------- ----------

EXECUTE 1

НО (!)

SQL> select occupant_desc, space_usage_kbytes
from v$sysaux_occupants
where space_usage_kbytes > 0
order by space_usage_kbytes desc;

OCCUPANT_DESC SPACE_USAGE_KBYTES
---------------------------------------------------------------- ------------------
AUDSYS schema objects 3994880
Server Manageability - Optimizer Statistics History 131008
Server Manageability - Automatic Workload Repository 100224
XDB 68864
Oracle Spatial 65984
Server Manageability - Other Components 55168
Unified Job Scheduler 27200
Oracle Multimedia ORDDATA Components 16896
LogMiner 14208
Server Manageability - Advisor Framework 8960
Oracle Text 8704

как было занято AUDSYS schema objects 3994880 так и осталось, ничего не изменилось в этом плане, т.е. место не высвободилось. Не совсем понимаю почему если честно...