Just to add my $0.02....

I was working on a large ODS project where we had to process 8+ million
records each night into an Oracle 8i database sitting on a RAID-5 disk
array. 

At the start of the processing we trucated the table. We used parallel
direct-path SQL*Loader (12 instances). We had SQL*loader
SKIP_INDEX_MAINTENANCE. After the loads were complete, we rebuild the
indexes (3 of them) in parallel (DEGREE 8). The while process took under 10
minutes and was I/O bound the whole time.

Kevin Toepke

-------------------------
The information in this electronic mail message is Cendant Confidential
and may be legally privileged. It is intended solely for the
addressee(s). Access to this Internet electronic mail message by anyone
else is unauthorized. If you are not the intended recipient, any
disclosure, copying, distribution or action taken or omitted to be taken
in reliance on it is prohibited and may be unlawful.
-------------------------
The sender believes that this E-mail and any attachments were free of
any virus, worm, Trojan horse, and/or malicious code when sent. This
message and its attachments could have been infected during
transmission. By reading the message and opening any attachments, the
recipient accepts full responsibility for taking protective and remedial
action about viruses and other defects. Cendant Corporation is not
liable for any loss or damage arising in any way from this message or
its attachments.
-------------------------


-----Original Message-----
Sent: Tuesday, March 27, 2001 8:01 AM
To: Multiple recipients of list ORACLE-L


Usually one drop indexes before massive inserts. Mostly in data loads in DW
- if using direct path in SQL*Loader is not an option. It should be decided
on the basis if saved time on inserts > then time to rebuild an indexes.
Also you cannot drop indexes if system should be available during inserts.
(PK, Unique, FK constraints, performance).

Oracle does not rebuild indexes during inserts - please RTFM. Index
organized tables are not good candidates for tables with a lot of DML -
performance issues.

Alex Hillman
<<snip, snip. Ouch!! That hurt. Now, quit that! Ouch!!! I said stop that!>>
-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.com
-- 
Author: Toepke, Kevin M
  INET: [EMAIL PROTECTED]

Fat City Network Services    -- (858) 538-5051  FAX: (858) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).

Reply via email to