RE: Export of very big table. Solution?

Thanks for the tips,

To be clear; We can use the index-file but it takes too long to import them...

I don't know if there are different disks involved in reading and writing for this site uses a disk array with about 100 disks in 1 pool. divided into several logical disks.

But I'm going to try a set of 7 selects (one for each day) in parallel. There's no index on date, but 1 out of 7 records is the correct date, and with a bit of luck it will only have to read the block ones, for the other queries need the same data?

Partitioning may be another plausable solution too.

Eric Lansu

> -----Original Message-----
> From: Yosi_at_comhill.com [SMTP:Yosi_at_comhill.com]
> Sent: Tuesday, January 09, 2001 5:53 PM
> To: Multiple recipients of list ORACLE-L
> Subject: RE: Export of very big table. Solution?
>
> Eric,
>
> That's big, but not THAT big. Where is your bottleneck? You could
> try to parallelize the operations. Many ways to do that - Partition
> the table and export it in partitions, in parallel. Or select to two
> flat files in parallel.
>
> Make sure you're exporting to a different disk than the data is on.
>
> Are you exporting over a network? Or on the server?
>
> Are you using direct export?
>
> Some suggestions. Hope they help,
>
> Yosi
>
>
> > -----Original Message-----
> > From: eric.lansu_at_dutchtone.nl [mailto:eric.lansu_at_dutchtone.nl]
> > Sent: Tuesday, January 09, 2001 7:21 AM
> > To: Multiple recipients of list ORACLE-L
> > Subject: Export of very big table. Solution?
> >
> >
> > Hello Listers,
> >
> > Some time ago I asked you how to export a very big file. The
> > solution was in
> > piping and UNIX-split.
> > We did this before, but what we didn't do was dd-ing from the
> > pipe to the
> > dump file. We piped it straight in. It looks like this solved
> > our corruption
> > problem on compressed exports files.
> >
> > The problem remains it's very slow. Our exports may be in
> > order now, but
> > there's no way we can use them anymore. Next thing we are
> > investigating is
> > 'select'-ing it to a comma-delimited file, and restore it
> > with SQL*Loader. A
> > regular select is very slow though! It takes 2 1/2 days to
> > unload the tabel
> > (22.500.000 records)
> >
> > Does anyone know a faster way to create a flat-file of a
> > table this size?
> >
> > Eric Lansu
> > --
> > Please see the official ORACLE-L FAQ: http://www.orafaq.com
> > --
> > Author:
> > INET: eric.lansu_at_dutchtone.nl
> >
> > 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: ListGuru_at_fatcity.com (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).
> >
> --
> Please see the official ORACLE-L FAQ: http://www.orafaq.com
> --
> Author:
> INET: Yosi_at_comhill.com
>
> 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: ListGuru_at_fatcity.com (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
Received on Wed Jan 10 2001 - 02:36:50 CST