Re: Auditing

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 <wbfergus@xxxxxxxxx> 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
> <kutrovsky.oracle@xxxxxxxxx> 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 - www.pythian.com
> > I blog at http://www.pythian.com/blogs/
> --
> http://www.freelists.org/webpage/oracle-l
>
>
>


-- 
Andrew W. Kerber

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

Other related posts: