Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Mailing Lists -> Oracle-L -> Re: Data auditing: triggers vs application code

Re: Data auditing: triggers vs application code

From: Sandeep Dubey <dubey.sandeep_at_gmail.com>
Date: Wed, 21 Sep 2005 16:36:44 -0400
Message-ID: <bf2f74740509211336354f9f58@mail.gmail.com>


Igor- Application will be based on J2EE. Delete to a live table and insert to audit table will be part of one single transaction one thread. I don't think it will be an extra trip. Moreover the point being putforward is we will deploy multiple application servers (10s or more) to do scaling.

Here back in past the trigger got somehow disabled - packaged called from trigger was invalidated, later fixed the packge but could not check the triggers. Application ran fine without complaining only later to found no audit records. I think that mindset of application architect is pushing against going with triggers. It's not though easy to disable the part og Java code that does the audit -you need to actually go and remove the code portion.
 Stephane - Thanks for your comments
 Thanks, Sandeep
 On 9/21/05, Igor Neyman <ineyman_at_perceptron.com> wrote:
>
> Regarding your 2nd point:
> In high transaction environment making extra trip from application to
> database to log data in adit table will cause more overhead than using
> trigger to populate audit table.
> Now, if you are afraid that someone could disable auditing triggers,
> aren't you afraid that someone could disable "auditing part" of application?
> Igor Neyman
>
> ------------------------------
> *From:* oracle-l-bounce_at_freelists.org [mailto:
> oracle-l-bounce_at_freelists.org] *On Behalf Of *Sandeep Dubey
> *Sent:* Wednesday, September 21, 2005 3:52 PM
> *To:* oracle-l
> *Subject:* Data auditing: triggers vs application code
>
> Hi,
> I need to keep track of history of data change in the live tables. Two
> methods are being compared.
> 1. Create triggers on the live table. For each insert/update/delete
> insert a row in the audit table.
> 2. Let the application take care of inserting the data in the audit table
> itself.
> The cons against using triggers in the order of severity are:
> 1. If somehow the triggers are disabled in production, the application
> goes through without noticing it and no audit data will be captured.
> 2. In a high transaction environment triggers have overhead.
> As a database person, I am inclined to use triggers. But I fail to
> guarantee that trigger will never get disabled. If it is disabled somehow
> application SHOULD stop. (It is impractical to check the status of all
> underlying triggers before each transaction).
> I would like to hear how you guys handle data auditing in your system.
> Thanks
> Sandeep
>

--
http://www.freelists.org/webpage/oracle-l
Received on Wed Sep 21 2005 - 15:38:56 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US