All we need is an easy explanation of the problem, so here it is.
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.
How to solve :
I know you bored from this bug, So we are here to help you! Take a deep breath and look at the explanation of your problem. We have many solutions to this problem, But we recommend you to use the first method because it is tested & true method that will 100% work for you.
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:
- Standard auditing
- Fine-Grained Auditing (FGA)
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:
BEGIN DBMS_FGA.ADD_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); END; /
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
Note: Use and implement method 1 because this method fully tested our system.
Thank you 🙂