Re: sqlldr very very slow
From: DA Morgan <damorgan_at_x.washington.edu>
Date: Fri, 28 Jan 2005 16:26:35 -0800
Message-ID: <1106958243.648237_at_yasure>
>
>
> That's was the first thought which came to my mind when i read your
> reply. In that case, disabling triggers couse a big trouble to
> database/application.
>
> By 'disable triggers' i expected a trigger filling history of that
> table, containg way more records than 300M, what could slow down
> insertions.
Date: Fri, 28 Jan 2005 16:26:35 -0800
Message-ID: <1106958243.648237_at_yasure>
Noel wrote:
> Użytkownik DA Morgan napisał:
>
>> Noel wrote: >> >> Suppose the trigger is used to load another table that is essential for >> the proper functioning, and thus the testing, of the application. What >> then? I hope you see the source of my concern.
>
>
> That's was the first thought which came to my mind when i read your
> reply. In that case, disabling triggers couse a big trouble to
> database/application.
>
> By 'disable triggers' i expected a trigger filling history of that
> table, containg way more records than 300M, what could slow down
> insertions.
Some triggers are used for implementing an audit function. Thus a report based on the audit table might indicate a problem and cause the software to fail. I put together a Sarbanes-Oxley complaince piece for a company last year that, had someone disabled a trigger, would have been reason for dismissal. And yes it would have audited who did it too.
But many triggers are used to perform processing and have nothing to do with auditing of value changes. In those situations the errors could be catestrophic to the app.
-- Daniel A. Morgan University of Washington damorgan_at_x.washington.edu (replace 'x' with 'u' to respond)Received on Sat Jan 29 2005 - 01:26:35 CET