Go to the FreeLists Home Page Home Signup Help Login
 



[oracle-l] || [Date Prev] [05-2004 Date Index] [Date Next] || [Thread Prev] [05-2004 Thread Index] [Thread Next]

Re: Data load ideas

  • From: "Ryan" <ryan.gaffuri@xxxxxxx>
  • To: <oracle-l@xxxxxxxxxxxxx>
  • Date: Sat, 1 May 2004 13:23:46 -0400
Foreign keys can lead to tremendous slow downs when bulk loading data. I had
to array insert 7 million records into a parent table 2 weeks ago, it took
less than an hour. To then do the same array insert into the child table
took 8 hours.

----- Original Message ----- 
From: "Tim Gorman" <tim@xxxxxxxxxxxxx>
To: <oracle-l@xxxxxxxxxxxxx>
Sent: Saturday, May 01, 2004 1:17 PM
Subject: Re: Data load ideas


> Todd,
>
> I'm not arguing against the index-supports for PKs or FKs.  Indexes and
> constraints are two different animals.  I'm merely arguing against the use
> of RI constraints (over the top of the indexes) in a database that is not
> the source-of-record.  Note that it is the constraints, not the indexes,
> that cause problems cited in this thread and in Jonathan Lewis's post on
> EXCHANGE PARTITION on dbazine.com.
>
> The disadvantages of RI constraints in a DW are obvious -- the original
post
> in this thread is one example.  Any mechanism geared for transactions and
> transactional processing (such as RI constraints or triggers) is bound to
> cause difficulties in the bulk-load operations commonly to large DWs.

----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to:  oracle-l-request@xxxxxxxxxxxxx
put 'unsubscribe' in the subject line.
--
Archives are at http://www.freelists.org/archives/oracle-l/
FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------




[ Home | Signup | Help | Login | Archives | Lists ]

All trademarks and copyrights within the FreeLists archives are owned by their respective owners.
Everything else ©2007 Avenir Technologies, LLC.