Somehow the auditing of select statements was enabled in our oracle database. We have several data processing apps that are generating upwards of 15 GB per day in the audit trail. Now we cannot turn it off because it seems that the noaudit command needs to match the original audit command, which of course no one knows. Does anyone know how to undo this? Can we turn off all auditing and then turn on the usual assortment of audit actions (alter, create, drop, etc.)? We have ran all kinds of noaduit permutations: “noaudit select table by USER;” and “noaudit select any table;” and yet it still posts select statements to the audit trail.


All enabled audit rules can be found in the below views:

Standard audit + FGA:

select * from dba_stmt_audit_opts;
select * from dba_priv_audit_opts;
select * from dba_obj_audit_opts;
select * from dba_audit_policies;

Unified audit (12c and above):

select * from audit_unified_enabled_policies;

Unified audit policy details:

select * from audit_unified_policies;

With the above, you can find whatever audit was enabled, and disable/modify as needed.

  • Thank you for getting back with a concise list of leads to follow up on. I looked thru each one and have not found any reference to there being auditing on select statements, and plus all the views seem to be consistent with each other. However, I am still seeing in the "dba_audit_trail" a steady posting of select statements. It is really mind boggling. Could there be something more complicated going on? Could the users have their own auditing settings that may not appear in SYS? – Stretching Lion Oct 8 '20 at 14:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.