We recent found some record in a table of an oracle database has been updated to another value.and it has been cause very important mistake.

we want to find out who and when has done this?

could someone give some tips?

thanks in advanced.

1 Answer 1


If you didn't enable auditing in your database, you usually cannot spot who and when queried and/or modified the database, at least as easily as with auditing enabled.

You can use various types of auditing for these tasks:

  1. Standard auditing
  2. Fine-Grained Auditing (FGA)
  3. Triggers

With standard auditing, you can audit object and system privileges, such as SELECT * FROM HR.EMLOYEES and CREATE ROLE. Audit records can be written in database (the default) or in the files outside the database. You enable auditing with AUDIT statement, for example, AUDIT SELECT ON HR.EMPLOYEES, and disable it with NOAUDIT statement, for example, NOAUDIT CREATE ROLE. Standard auditing allows you to capture the user name which invokes the statement, the timestamp, the text of the executed SQL, and bind variables. The standard auditing records can be queried from the DBA_AUDIT_TRAIL view if auditing is configured to store them in database (which is default).

With FGA, you can audit specific columns and rows of the table based on audit condition, you can audit actions in specific time intervals (say, from 5 PM to 8 AM), you can even audit actions from specific IP addresses. You implement FGA with DBMS_FGA PL/SQL package. For example, you can audit queries and updates on the column SALARY of the table HR.EMPLOYEES with this FGA policy:

   object_schema      => 'HR',
   object_name        => 'EMPLOYEES',
   policy_name        => 'chk_hr_employees_salary',
   audit_column       => 'SALARY', 
   enable             =>  TRUE,
   statement_types    => 'SELECT, UPDATE',
   audit_trail        =>  DBMS_FGA.DB);

The FGA audit records can then be queried from the DBA_FGA_AUDIT_TRAIL view if policy is configured to store them in database (audit_trail parameter in the code above).

With triggers, you can capture the previous and new values for the interesting tables. However auditing implemented with triggers is superseded by FGA. The audit records are inserted in the tables specifically created by you. As far as table auditing is concerned, you can use BEFORE STATEMENT and AFTER STATEMENT triggers to audit statements executing on the tables, or BEFORE ROW and AFTER ROW to audit the previous and new values for the columns.

The other facility I would give a shot is LogMiner. It allows you to analyze the online and archived redo logs and reconstruct the exact DML and DDL that were executed in the database. In Database Control (the web interface to control the database), take to the Availability tab, then click View and Manage Transactions). Here, you can specify the time range and objects you're interested in, and LogMiner will provide you the transactions list based on the parameters you specified. If you cannot determine the actual user, I would try to correlate the time of transaction with AUDIT SESSION records which are usually collected as part of mandatory auditing and can be retrieved from DBA_AUDIT_TRAIL view.

  • 1
    Grate answer by @Yasir. two comments if you may 1) LogMiner is preferably used to investigate past actions if you didn't have any other measures active at the time (like AUDIT) - meaning, don't rely on it as your primary tool. 2) best practices say - avoid triggers.
    – haki
    Apr 19, 2013 at 8:21
  • Thanks. Yep, I guess that's why I described both triggers and LogMiner in the end because these are the last resort ;-) Apr 19, 2013 at 9:00
  • Oops, I actually meant Default Auditing, not Mandatory Auditing. Apr 20, 2013 at 7:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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