What is auditing in Oracle?
In the world of database administration, if security is the lock on the door, auditing is the security camera. It doesn't stop someone from entering, but it records exactly who came in, what they touched, and when they left.
Oracle Auditing is the built-in framework that tracks user activity and database changes. It provides the "paper trail" necessary for security, troubleshooting, and regulatory compliance (like SOC2, HIPAA, or GDPR).
Without auditing, a database is a "black box." If a critical table disappears or a salary is changed, you might know what happened, but you won't know who did it.
Accountability: Linking actions to specific users.
Deterrence: Users are less likely to peek at sensitive data if they know they are being watched.
Forensics: Investigating a breach after it occurs.
Compliance: Proving to auditors that your security controls are actually working.
In older versions of Oracle, audit logs were scattered across different tables and OS files. In 2026, the standard is Unified Auditing.
The Single Source: All audit records (from RMAN, Data Pump, SQL statements, and Virtual Private Database) are stored in a single, read-only table in the AUDSYS schema.
Performance: It is significantly faster than "Traditional Auditing" because it uses a queued, asynchronous write process that doesn't slow down the user's transaction.
The View: You view all activity through a single window: UNIFIED_AUDIT_TRAIL.
You can be as broad or as specific as you like:
| Audit Type | Description |
| Mandatory Auditing | Oracle always logs certain actions (like startup, shutdown, and SYSDBA logins). You can't turn this off. |
| Standard Auditing | Tracks SQL statements like SELECT, INSERT, or DROP TABLE. |
| Fine-Grained Auditing (FGA) | The "Smart" audit. It only logs an event if a specific condition is met (e.g., "Audit if someone selects from the SALARY column where the value is > $200,000"). |
| Object Auditing | Tracks actions on a specific table, view, or procedure. |
In 2026, you manage auditing through Policies. You create a policy, and then you enable it for specific users or the whole database.
-- 1. Create a policy to track sensitive changes
CREATE AUDIT POLICY hr_security_policy
ACTIONS DELETE ON hr.employees, UPDATE ON hr.employees, DROP TABLE;
-- 2. Enable the policy
AUDIT POLICY hr_security_policy;
-- 3. Enable it only for a specific high-risk user
AUDIT POLICY hr_security_policy BY jsmith;
The biggest mistake a DBA can make is turning on auditing and forgetting about it. Audit logs grow—fast.
If the SYSAUX tablespace (where the audit trail lives) fills up, your database might stop accepting new connections. You must implement a Purge Strategy. Oracle provides the DBMS_AUDIT_MGMT package specifically to automate the cleaning of old audit records after they have been archived to a long-term storage system.
Don't Audit Everything: Auditing every SELECT on a busy system will crush your performance and fill your disks in hours.
Audit the Admins: Always audit GRANT, REVOKE, and ALTER SYSTEM commands.
Use Fine-Grained Auditing (FGA): Use FGA to watch sensitive data (the "content") rather than just the "actions."
Protect the Logs: Ensure your audit trail is "read-only" so that a rogue admin can't delete the evidence of their own crimes.
Auditing isn't about "spying" on employees; it’s about integrity. In an era where data is a company's most valuable asset, knowing the history of that data is just as important as the data itself.