auditing 50 columns using oracle trigger

Question

I need to create a trigger in oracle 11g for auditing a table .

I have a table with 50 columns that need to be audited

Answer 1

Your immediate problem with the else always being called is because you're using your index variable r directly, rather than looking up the relevant column name:

for r in v_tab_col_nt.first..v_tab_col_nt.last
loop
    if updating(v_tab_col_nt(r)) then
        insert into data_table values(1,'i am updating '||v_tab_col_nt(r));
    else
        insert into data_table values(2,'i am inserting '||v_tab_col_nt(r));
    end if;
end loop;

You're also only showing an id column in your table creation, so when r is 2, it will always say it's inserting name, never updating. More importantly, if you did have a name column and were only updating that for a given id, this code would show the id as inserting when it hadn't changed. You need to split the insert/update into separate blocks:

if updating then
    for r in v_tab_col_nt.first..v_tab_col_nt.last loop
        if updating(v_tab_col_nt(r)) then
            insert into data_table values(1,'i am updating '||v_tab_col_nt(r));
        end if;
    end loop;
else /* inserting */
    for r in v_tab_col_nt.first..v_tab_col_nt.last loop
        insert into data_table values(2,'i am inserting '||v_tab_col_nt(r));
    end loop;
end if;

This will still say it's inserting name even if the column doesn't exist, but I assume that's a mistake, and I guess you'd be trying to populate the list of names from user_tab_columns anyway if you really want to try to make it dynamic.

---

I agree with (at least some of) the others that you'd probably be better off with an audit table that takes a copy of the whole row, rather than individual columns. Your objection seems to be the complication of individually listing which columns changed. You could still get this information, with a bit of work, by unpivoting the audit table when you need column-by-column data. For example:

create table temp12(id number, col1 number, col2 number, col3 number);
create table temp12_audit(id number, col1 number, col2 number, col3 number,
    action char(1), when timestamp);

create or replace trigger temp12_trig
before update or insert on temp12
for each row
declare
    l_action char(1);
begin
    if inserting then
        l_action := 'I';
    else
        l_action := 'U';
    end if;

    insert into temp12_audit(id, col1, col2, col3, action, when)
    values (:new.id, :new.col1, :new.col2, :new.col3, l_action, systimestamp);
end;
/

insert into temp12(id, col1, col2, col3) values (123, 1, 2, 3);
insert into temp12(id, col1, col2, col3) values (456, 4, 5, 6);
update temp12 set col1 = 9, col2 = 8 where id = 123;
update temp12 set col1 = 7, col3 = 9 where id = 456;
update temp12 set col3 = 7 where id = 123;

select * from temp12_audit order by when;

        ID       COL1       COL2       COL3 A WHEN
---------- ---------- ---------- ---------- - -------------------------
       123          1          2          3 I 29/06/2012 15:07:47.349
       456          4          5          6 I 29/06/2012 15:07:47.357
       123          9          8          3 U 29/06/2012 15:07:47.366
       456          7          5          9 U 29/06/2012 15:07:47.369
       123          9          8          7 U 29/06/2012 15:07:47.371

So you have one audit row for each action taken, two inserts and three updates. But you want to see separate data for each column that changed.

select distinct id, when,
    case
        when action = 'I' then 'Record inserted'
        when prev_value is null and value is not null
            then col || ' set to ' || value
        when prev_value is not null and value is null
            then col || ' set to null'
        else col || ' changed from ' || prev_value || ' to ' || value
    end as change
from (
    select *
    from (
        select id,
            col1, lag(col1) over (partition by id order by when) as prev_col1,
            col2, lag(col2) over (partition by id order by when) as prev_col2,
            col3, lag(col3) over (partition by id order by when) as prev_col3,
            action, when
        from temp12_audit
    )
    unpivot ((value, prev_value) for col in (
        (col1, prev_col1) as 'col1',
        (col2, prev_col2) as 'col2',
        (col3, prev_col3) as 'col3')
    )
)
where value != prev_value
    or (value is null and prev_value is not null)
    or (value is not null and prev_value is null)
order by when, id;

        ID WHEN                      CHANGE
---------- ------------------------- -------------------------
       123 29/06/2012 15:07:47.349   Record inserted
       456 29/06/2012 15:07:47.357   Record inserted
       123 29/06/2012 15:07:47.366   col1 changed from 1 to 9
       123 29/06/2012 15:07:47.366   col2 changed from 2 to 8
       456 29/06/2012 15:07:47.369   col1 changed from 4 to 7
       456 29/06/2012 15:07:47.369   col3 changed from 6 to 9
       123 29/06/2012 15:07:47.371   col3 changed from 3 to 7

The five audit records have turned into seven updates; the three update statements show the five columns modified. If you'll be using this a lot, you might consider making that into a view.

So lets break that down just a little bit. The core is this inner select, which uses lag() to get the previous value of the row, from the previous audit record for that id:

        select id,
            col1, lag(col1) over (partition by id order by when) as prev_col1,
            col2, lag(col2) over (partition by id order by when) as prev_col2,
            col3, lag(col3) over (partition by id order by when) as prev_col3,
            action, when
        from temp12_audit

That gives us a temporary view which has all the audit tables columns plus the lag column which is then used for the unpivot() operation, which you can use as you've tagged the question as 11g:

    select *
    from (
        ...
    )
    unpivot ((value, prev_value) for col in (
        (col1, prev_col1) as 'col1',
        (col2, prev_col2) as 'col2',
        (col3, prev_col3) as 'col3')
    )

Now we have a temporary view which has id, action, when, col, value, prev_value columns; in this case as I only have three columns, that has three times the number of rows in the audit table. Finally the outer select filters that view to only include the rows where the value has changed, i.e. where value != prev_value (allowing for nulls).

select
    ...
from (
    ...
)
where value != prev_value
    or (value is null and prev_value is not null)
    or (value is not null and prev_value is null)

I'm using case to just print something, but of course you can do whatever you want with the data. The distinct is needed because the insert entries in the audit table are also converted to three rows in the unpivoted view, and I'm showing the same text for all three from my first case clause.

Answer 2

Why not make life easier and insert the entire row when any data in any column is updated. So any update (or delete typically) on the main table has the original row copied to the audit table first. So your audit table will have same layout as the main table, but with an extra few tracking fields, something like:

create or replace trigger my_tab_tr
before update or delete
on my_tab
referencing new as new and old as old
for each row
declare
  l_type varchar2(3);
begin
  if (updating) then
    l_type = 'UPD';
  else
    l_type = 'DEL';
  end if;

insert into my_tab_audit(
 col1,
 col2,
 audit_type,
 audit_date) 
values (
 :old.col1,
 :old.col2,
 l_type,
 sysdate
);
end;

Add additional columns as you like to the audit table, this is just a typical example

Answer 3

A very unorthodox solution: (only if you have access to system tables, at least the SELECT privilege)

1. You know your table's NAME. Identify the ID of the owner of the table. Look it up in SYS.USER$ by the user's (=owner's) name.

2. Look up your table's object-ID (= OBJ#) in SYS.OBJ$ by OWNER# (= owner's ID) and NAME (=table's name).

3. Look up the columns that compose the table in SYS.COL$ by OBJ#. You will find all the columns, their IDs (COL#) and names (NAME).

4. Write an UPDATE trigger with a cursor that moves on the set of those columns. You will have to write the nucleus of the loop only once.

5. and end of it: I don't provide code, because the details may differ from Oracle version to Oracle version.

This is real dynamic SQL programming. I happened to use it even on fairly large enterprise systems (the team leaders did not know about it) and it worked. It is fast and reliable. Drawbacks: {privileges; transportability; bad consideration from responsible people}.

Answer 4

the way i like to do it:

1. create an audit table that is parallel to your existing original table.
2. add a timestamp and user columns to this audit table.
3. whenever the original table is inserted or updated, then just insert into the audit table.
4. the audi table should have a trigger to set the timestamp and user values - all other values come in as the new values.

then you can query at any time who did what, and when.

Answer 5

The only way I've seen field-by-field audits done is to check each of the fields :OLD and :NEW values against each other and write the appropriate records to the audit table. You can semi-automate this by having a subroutine in the trigger to which you pass the appropriate values, but one way or another I believe you're going to have to write code for each individual field. Unless someone else has a brilliant way to do this with some sort of reflective API of which I'm not aware (and "what I'm not aware of" is applicable to more stuff each day, or so it seems :-).

The choice of whether to audit individual fields or to audit the entire row (which I usually call "history" tables) depends on how you intend to use the data. In this case, where individual fields changes need to be reported, I agree that a field-by-field audit seems to be a better fit. In other cases (for example, where a data extract must be reproducible for any given date) a row-by-row audit or "history table" approach is a better fit.

Irregardless of the the audit level (field-by-field or row-by-row), the comparison logic needs to be carefully written to handle the NULL/NOT NULL cases, so that you don't get bitten by comparing :OLD.FIELD1 = :NEW.FIELD1 where one of the values (or both) is NULL, and end up not taking the appropriate action because NULL is not equal to anything, even itself. Don't ask me how I know... :-)

Just out of curiosity, what will be put in for OLD_VALUE and NEW_VALUE in the single row which will be created when an INSERT occurs?

Share and enjoy.