Re: aud$ purge script

From: Tim Gorman <tim_at_evdbt.com>
Date: Sun, 11 Aug 2013 07:36:55 -0600
Message-ID: <52079377.10700_at_evdbt.com>



I would say that the fastest DELETE is a DROP PARTITION, as happens within AWR. STATSPACK used to have a purge routine that was all DELETE, and it could get to be such a pig that people wouldn't run it. Nowadays, nobody notices when AWR purges data -- and that says it all, right there.

My impression is that the present AUD$ audit trail is a relic of Oracle6 (or earlier) which is (hopefully) slated for a move out of SYSTEM to SYSAUX and into 12c Information Lifecycle Management (ILM), perhaps as soon as 12cR2. If this isn't in the works, then we need to encourage Oracle to do so. How hard could it be?

A big problem with 12c ILM is (as was pointed out by Abdul Ebadi at this week's DB12c TechDay in Denver last Friday), there is no DROP functionality embedded into Automatic Data Optimization (ADO) and ILM. Hopefully, *that* (along with the above-mentioned move of AUD$ to SYSAUX and range-partitioning and ADO) is coming with 12cR2? Or even as a 12cR1 patch? Pretty please?

On 8/9/2013 3:21 PM, Iggy Fernandez wrote:
> >From the documentation on DBMS_AUDIT_MGMT:
>
> The DB_DELETE_BATCH_SIZE property enables you to control the number of audit records that are deleted in one batch. Setting a large value for this parameter requires increased allocation for the undo log space.
>
> Tim Gorman might say that the fastest DELETE is DROP TABLE or TRUNCATE TABLE.
>
> Iggy
>
>
>> http://www.oradba.ch/2011/02/manage-audit-trails-with-dbms_audit_mgmt/
>
>>> http://www.pythian.com/news/1106/oracle-11g-audit-enabled-by-default-but-what-about-purging/
>>> It creates a procedure and a scheduled job to purge the audit log. It even
>
>>> I have a task to purge aud$ table and it need to done in automated way
>>> on every month. Please help on sharing the purge script to schedule in db
>>> scheduler --
> http://www.freelists.org/webpage/oracle-l
>
>
>
>

--
http://www.freelists.org/webpage/oracle-l
Received on Sun Aug 11 2013 - 15:36:55 CEST

Original text of this message