This content has been marked as final. Show 5 replies
Did you test
- - - - - - - - - - - - - - - - - - - - -
Kamran Agayev A. (10g OCP)
As a TRUNCATE statement deletes rows from a table, triggers associated with the table are not fired. Also, a TRUNCATE statement does not generate any audit information corresponding to DELETE statements if auditing is enabled. Instead, a single audit record is generated for the TRUNCATE statement being issued.
you can take a look at this..
refer to section called : Setting Auditing Options
as kamran pointed...
have u treid audit truncate;
take a look at this blog...
There is certainly a lot of bad information floating around on this topic.
"Audit table" will audit create table, drop table and truncate table - which is absolutely true. It is the ONLY way to reliably audit truncate table operations.
Object auditing on a specific table (e.g. audit all on scott.mytab) never creates an audit record for truncation.
You can audit "DROP ANY TABLE" which will create an audit record ONLY when someone with the DROP ANY TABLE system privilege attempts to truncate a table in another schema.
Contrary to what some "experts" (including at least one ACE) think, "audit truncate table" is NOT valid syntax.
"Audit truncate" does not return an error, but (as far as I can tell and I've actually tested it on 220.127.116.11, 10.2.0.1, 10.2.0.5 and 18.104.22.168) it does nothing. It creates no record in DBA_STMT_AUDIT_OPTS or DBA_PRIV_AUDIT_OPTS and it never produces a record in the audit trail. It is a half-baked auditing option that does not actually work - so, "audit truncate" should return an error!
Please don't revive 4 year old threads. Let them rest in peace.
It's good that you want to contribute to the forums but your contributions will be more useful if you respond to current unanswered threads.