AUDIT BY ACCESS records every successful or failed statement on a specified object, privilege, or user.
It writes a row to SYS.AUD$
(Oracle) or your pgaudit log (PostgreSQL) each time the audited action runs. Use it when you need a complete, statement-level trail for compliance or breach forensics.
Oracle: set AUDIT_TRAIL = DB,EXTENDED
and restart. PostgreSQL: install the pgaudit
extension, then ALTER SYSTEM SET pgaudit.log = 'read,write';
followed by a reload.
Oracle: AUDIT SELECT, INSERT, UPDATE, DELETE ON customers BY ACCESS;
logs every DML on customers
. In PostgreSQL, create a role-based policy: SET pgaudit.role = 'app';
so only statements from app
users are captured.
Oracle: AUDIT SESSION WHENEVER NOT SUCCESSFUL;
records failed logons. PostgreSQL: enable parameter log_connections = on
and filter on FATAL
in logs.
Oracle: query SELECT username, obj_name, action_name, timestamp FROM dba_audit_trail;
. PostgreSQL: read $PGDATA/log/*.log
or send logs to logstash
/CloudWatch
.
Audit only what you need, use BY SESSION
when statement-level detail is unnecessary, and archive older audit rows to keep the repository lean.
Minimal overhead when auditing a few tables, but broad auditing can add noticeable I/O. Test in staging before production rollout.
Yes. Use BY user_name
in Oracle or pgaudit.set_role
in PostgreSQL to limit captured statements.
Run NOAUDIT
with the same clauses you used in AUDIT, or reset pgaudit.log
to an empty string.