Re: Auditing

From: Andrew Kerber <>
Date: Wed, 4 Mar 2009 11:24:30 -0600
Message-ID: <>

Had you considered just turning on the audit_trail to db_extended or some such, along with a trigger or two to apply any additional information you need? I dont think the extended audit trail would actually be lacking much information, as I recall it even contains the undo sql.

On Wed, Mar 4, 2009 at 11:17 AM, Bill Ferguson <> wrote:

> The only other database available is one where they want an exact
> duplicate of this one I have here in Denver (the other is in Reston,
> VA), and we're trying to use Shareplex to accomplish that goal. So any
> changes here are (almost instantly) replicated to the other system,
> and vice versa, so tracking the changes becomes even more problematic,
> as an extra check needs to made to exclude replication changes.
> Each data table already has basic info, update_date, updated_by,
> insert_date, inserted_by. I also have a procedure fired off through a
> trigger, so whenever a change is made, the procedure loops through all
> the tables for that 'master' record and generates a XML-type CLOB
> field of the previous version of all the data before the change. With
> this, it's easy for me design something similar to how Wikipedia
> tracks and displays changes, with the added benefit of seeing
> everything in context, not merely the new and old vlaues of a field.
> --
> -- Bill Ferguson
> On Wed, Mar 4, 2009 at 9:17 AM, Christo Kutrovsky
> <> wrote:
> > What about using Oracle Streams ? Or if not possible use logminer.
> >
> > You would only have to dump some extra info in the transaction to
> > 'bind it' to a specific user.
> >
> > --
> > Christo Kutrovsky
> > Senior DBA
> > The Pythian Group -
> > I blog at
> --

Andrew W. Kerber

'If at first you dont succeed, dont take up skydiving.'

Received on Wed Mar 04 2009 - 11:24:30 CST

Original text of this message