Re: Importing database with LONG colum

You might, depending upon the number of indexes being processed, wish to split the import into two stages; do an import INDEXES=N, then do an import INDEXFILE=filename. This produces an executable file to build the indexes. Run this against the DB after the import.

This can reduce the overall import process significantly, because and import FULL=Y will build the tables and indexes and then load the data. This causes the index to be populated as the data loads. As the index grows in size, it dynamically balances (b-tree indexes) this causes large I/O which has nothing to do with the data load.

Obviously, there are reasons for your dumping the export directly to tape. However, if you can you should dump to tape first, even running through compression first would be quicker than to tape (depending upon the o/s).

best of luck

Nick

Thor Morten Kopaas wrote in message ...
>Hei,
>
>We have a Oracle 7.3.3 database running on Solaris 2.51. The size of the
>database is about 10Gb. Many of the tables in the database have long
>columns.
>Every night we take an export of the database on to tape which takes about
9
>hours.
>Because of a disk-failure we needed to import the whole database using
>Oracle import utility reading the data from tape. But, the import process
>takes a very very long time (three days) and I was wondering if any of you
>have any ideas on why that could be.
>I have been monitoring the importing process periodically and I notice that
>tables containing columns of the type LONG is very very slow to be imported
>while tables without LONG columns are loaded at a satisfactory speed. I
>have hear roumers that Oracle's utilities does not handle the LONG type
very
>well, but I do not have any reliable source on that.
>
>Is it normal that an export process taking 9 hours should take 3 days to
>import?
>
>The parameter file I am using look like:
>
>FILE=/dev/rmt/0n
>LOG=do_imp.log
>FULL=Y
>COMMIT=Y
>BUFFER=40000000
>
>Would the time it takes to import the data be much shorter if I used
>COMMIT=N instead?
>
>
>Comments?
>
>Thanks,
>
>Thor Morten Kopaas
>
>
Received on Sat Apr 17 1999 - 19:13:10 CDT