Apress.Expert.Oracle.Database.Architecture.9i.and.10g.Programming.Techniques.and.Solutions.Sep.2005

278
CHAPTER 8 ■ TRANSACTIONS
A question that application developers often pose to me is, “How can I audit every
attempt to modify secure information and record the values they were trying to modify?”
They want to not only prevent the attempted modification from taking place, but also create a
permanent record of the attempt. Before the advent of autonomous transactions, many developers
tried (and failed) to do this using standard triggers without an autonomous transaction.
The trigger would detect the UPDATE and, upon discovering a user modifying data she should
not, it would create an audit record and fail the UPDATE. Unfortunately, when the trigger
failed the UPDATE, it also rolled back the audit record—it was an all-or-nothing failure. With
autonomous transactions, it is now possible to securely capture the audit of an attempted
operation as well as roll back that operation. In the process, we can inform the end user that
she has attempted to modify data that she does not have permission to modify and that a
record of the attempt has been made.
It is interesting to note that the native Oracle AUDIT command provided the ability to capture
unsuccessful attempts to modify information, using autonomous transactions, for many
years. The exposure of this feature to Oracle developers allows us to create our own, more customized
auditing.
Here is a small example. Let’s place an autonomous transaction trigger on a table that
captures an audit trail, detailing who tried to update the table and when that person tried to
do it, along with a descriptive message of which data the person tried to modify. The logic
behind this trigger will be that it will prevent any attempt to update the record of an employee
who does not (directly or indirectly) report to you.
First, we make a copy of the EMP table from the SCOTT schema to use as our example table:
ops$tkyte@ORA10G> create table emp
2 as
3 select * from scott.emp;
Table created.
ops$tkyte@ORA10G> grant all on emp to scott;
Grant succeeded.
We also create an AUDIT_TAB table in which to store the audit information. Note that we’re
using the DEFAULT attribute of the columns to have the currently logged in username and the
current date/time logged into our audit trail as well:
ops$tkyte@ORA10G> create table audit_tab
2 ( username varchar2(30) default user,
3 timestamp date default sysdate,
4 msg varchar2(4000)
5 )
6 /
Table created.
Next, we create an EMP_AUDIT trigger to audit UPDATE activity on the EMP table:
ops$tkyte@ORA10G> create or replace trigger EMP_AUDIT
2 before update on emp
3 for each row
4 declare