RE: RE: Data load options

2001-07-26 Thread Deshpande, Kirti

>> Must be the narcotics.
Lack of .. or..  
a tad too darn much ? 

;-)

- Kirti 

> -Original Message-
> From: Koivu, Lisa [SMTP:[EMAIL PROTECTED]]
> Sent: Thursday, July 26, 2001 10:47 AM
> To:   Multiple recipients of list ORACLE-L
> Subject:      RE: RE: Data load options
> 
> Oh yes.  You are right.  It loads full blocks above the HWM.  Forgot to
> mention that... thanks for pointing out that VERY important bit of info.
> Must be the narcotics.
> 
> Lisa 
> 
> -Original Message- 
> From:   [EMAIL PROTECTED] [SMTP:[EMAIL PROTECTED]] 
> Sent:   Wednesday, July 25, 2001 11:03 AM 
> To: Multiple recipients of list ORACLE-L 
> Subject:Re:RE: Data load options 
> 
> Lisa, 
> 
> SQL*Loader in direct path can cause you storage problems since it
> always 
> appends to the table(s) ignoring blocks on the free block list.  I found
> that 
> out after a developer was using it for our data warehouse.  At the end of
> a year 
> he had burned almost 100GB of disk & it kept increasing even though he was
> 
> trying to keep only a rolling 180 window.  On a hunch we exported the
> data, 
> truncated the table & imported the data back in.  The amount of tablespace
> being 
> used dropped 50%. 
> 
> Dick Goulet 
> 
-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.com
-- 
Author: Deshpande, Kirti
  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).



RE: RE: Data load options

2001-07-26 Thread Rachel Carmichael

Okay Lisa,

WHY were you on painkillers?

Rachel


>From: "Koivu, Lisa" <[EMAIL PROTECTED]>
>Reply-To: [EMAIL PROTECTED]
>To: Multiple recipients of list ORACLE-L <[EMAIL PROTECTED]>
>Subject: RE: RE: Data load options
>Date: Thu, 26 Jul 2001 07:47:06 -0800
>
>Oh yes.  You are right.  It loads full blocks above the HWM.  Forgot to
>mention that... thanks for pointing out that VERY important bit of info.
>Must be the narcotics.
>
>Lisa
>
> > -Original Message-
> > From:   [EMAIL PROTECTED] [SMTP:[EMAIL PROTECTED]]
> > Sent:   Wednesday, July 25, 2001 11:03 AM
> > To: Multiple recipients of list ORACLE-L
> > Subject:Re:RE: Data load options
> >
> > Lisa,
> >
> > SQL*Loader in direct path can cause you storage problems since it
> > always
> > appends to the table(s) ignoring blocks on the free block list.  I found
> > that
> > out after a developer was using it for our data warehouse.  At the end 
>of
> > a year
> > he had burned almost 100GB of disk & it kept increasing even though he 
>was
> > trying to keep only a rolling 180 window.  On a hunch we exported the
> > data,
> > truncated the table & imported the data back in.  The amount of 
>tablespace
> > being
> > used dropped 50%.
> >
> > Dick Goulet
> >
> > Reply Separator
> > Author: "Koivu; Lisa" <[EMAIL PROTECTED]>
> > Date:   7/25/2001 6:26 AM
> >
> > Hi Sean,
> >
> > Others have given you different options.  Here's some considerations:
> >
> > 1.  SQL Script.
> > *   Can be SLOW
> > *   May require intermittent commits in your script
> > *   Manual and error prone
> > *   Must go through SQL engine
> >
> > 2.  SQL Loader
> > *   Can be very fast (direct - bypassing SQL engine).
> > *   Direct path load will invalidate indexes.
> > *   You can keep track of rejected records easily (.bad file)
> > *   Dependent upon your file format being EXACT, no errors.
> >
> > 3.  Import
> > *   Requires minimal manual fiddling
> > *   Can be very slow - I once imported 150GB and it took ~3 days
> > *   Does not seamlessly handle all object types (INtermedia (domain)
> > indexes is one example)
> > *   Restarting an import will take a lot longer.  If your import
> > fails,
> > be sure and truncate/drop all tables before starting again.
> > *   Have the option of not including indexes (INDEXES=N)
> > *   Can also reset your storage parms prior to import (export with
> > data=n, edit file [SSSHHH] and enter new storage parms / import, export
> > with
> > data=y, import data with IGNORE=Y)
> >
> > I'm sure others will have additional considerations to share.  My choice
> > has
> > always been exp/imp.
> >
> > Lisa Koivu
> > The Vicodin-enhanced DBA
> > Ft. Lauderdale, FL, USA
> >
> > > -Original Message-
> > > From: O'Neill, Sean [SMTP:[EMAIL PROTECTED]]
> > > Sent: Wednesday, July 25, 2001 6:16 AM
> > > To:   Multiple recipients of list ORACLE-L
> > > Subject:  Data load options
> > >
> > > I'm trying to compile a list of options for loading data into an 
>Oracle
> > > database on NT platform.  What I've come up with so far is:
> > > [1] SQL script that performs inserts, updates.
> > > [2] SQL Loader utility
> > > [3] Import utility
> > >
> > > Are there others?
> > > Anyone care to share experience based opinions on pros and cons of the
> > > methods?
> > >
> > >
> > > Sean :)
> > >
> > > Rookie Data Base Administrator
> > > [0%] OCP Oracle8i DBA
> > > [0%] OCP Oracle9i DBA
> > >  
> > > Organon (Ireland) Ltd.
> > > E-mail: [EMAIL PROTECTED]   [subscribed: Digest Mode]
> > >
> > > Visit: http://groups.yahoo.com/group/Oracle-OCP-DBA
> > >
> > > "Nobody loves me but my mother... and she could be jivin' too."  - BB
> > King
> > >
> > > --
> > > Please see the official ORACLE-L FAQ: http://www.orafaq.com
> > > --
> > > Author: O'Neill, Sean
> > >   INET: [EMAIL PROTECTED]
> > >
> > > Fat City Network Services-- (858) 538-5051  FAX: (858) 538-5051
> > > San Diego, California-- Public Internet access / Mailing List

RE: RE: Data load options

2001-07-26 Thread Koivu, Lisa
Title: RE: RE: Data load options





Oh yes.  You are right.  It loads full blocks above the HWM.  Forgot to mention that... thanks for pointing out that VERY important bit of info.  Must be the narcotics.

Lisa


-Original Message-
From:   [EMAIL PROTECTED] [SMTP:[EMAIL PROTECTED]]
Sent:   Wednesday, July 25, 2001 11:03 AM
To: Multiple recipients of list ORACLE-L
Subject:    Re:RE: Data load options


Lisa,


    SQL*Loader in direct path can cause you storage problems since it always
appends to the table(s) ignoring blocks on the free block list.  I found that
out after a developer was using it for our data warehouse.  At the end of a year
he had burned almost 100GB of disk & it kept increasing even though he was
trying to keep only a rolling 180 window.  On a hunch we exported the data,
truncated the table & imported the data back in.  The amount of tablespace being
used dropped 50%.


Dick Goulet


Reply Separator
Author: "Koivu; Lisa" <[EMAIL PROTECTED]>
Date:   7/25/2001 6:26 AM


Hi Sean, 


Others have given you different options.  Here's some considerations:


1.  SQL Script. 
*   Can be SLOW 
*   May require intermittent commits in your script
*   Manual and error prone
*   Must go through SQL engine


2.  SQL Loader
*   Can be very fast (direct - bypassing SQL engine). 
*   Direct path load will invalidate indexes. 
*   You can keep track of rejected records easily (.bad file)
*   Dependent upon your file format being EXACT, no errors.


3.  Import
*   Requires minimal manual fiddling
*   Can be very slow - I once imported 150GB and it took ~3 days
*   Does not seamlessly handle all object types (INtermedia (domain)
indexes is one example)
*   Restarting an import will take a lot longer.  If your import fails,
be sure and truncate/drop all tables before starting again. 
*   Have the option of not including indexes (INDEXES=N)
*   Can also reset your storage parms prior to import (export with
data=n, edit file [SSSHHH] and enter new storage parms / import, export with
data=y, import data with IGNORE=Y)


I'm sure others will have additional considerations to share.  My choice has
always been exp/imp. 


Lisa Koivu
The Vicodin-enhanced DBA
Ft. Lauderdale, FL, USA 


> -Original Message-
> From: O'Neill, Sean [SMTP:[EMAIL PROTECTED]]
> Sent: Wednesday, July 25, 2001 6:16 AM
> To:   Multiple recipients of list ORACLE-L
> Subject:  Data load options
> 
> I'm trying to compile a list of options for loading data into an Oracle
> database on NT platform.  What I've come up with so far is:
> [1] SQL script that performs inserts, updates.
> [2] SQL Loader utility
> [3] Import utility
> 
> Are there others?
> Anyone care to share experience based opinions on pros and cons of the
> methods?
> 
> 
> Sean :)
> 
> Rookie Data Base Administrator
> [0%] OCP Oracle8i DBA
> [0%] OCP Oracle9i DBA
>   
> Organon (Ireland) Ltd.
> E-mail: [EMAIL PROTECTED]   [subscribed: Digest Mode]
> 
> Visit: http://groups.yahoo.com/group/Oracle-OCP-DBA
> 
> "Nobody loves me but my mother... and she could be jivin' too."  - BB King
> 
> -- 
> Please see the official ORACLE-L FAQ: http://www.orafaq.com
> -- 
> Author: O'Neill, Sean
>   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).







RE: Data load options




Hi Sean, 



Others have given you different
options.  Here's some considerations:



1.  SQL Script. 


Can be SLOW 
May require intermittent commits
in your script
Manual and error prone
Must go through SQL
engine


2.  SQL Loader


Can be very fast (direct -
bypassing SQL engine). 
Direct path load will invalidate
indexes. 
You can keep track of rejected
records easily (.bad file)
Dependent upon your file format
being EXACT, no errors.


3.  Import


Requires minimal manual
fiddling
Can be very slow - I once imported
150GB and it took ~3 days
Does not seamlessly handle all
object types (INtermedia (domain) indexes is one example)
Restarting an import will take a
lot longer.  If your import fails, be sure and truncate/drop all tables
before starting again. 
Have the option of not including
indexes (INDEXES=