Oracle-L: RE: IMPORT sloooowwww

From: Casey Dyke <cdyke_at_corp.home.nl>
Date: Fri, 30 Aug 2002 07:03:31 -0800
Message-ID: <F001.004C40E6.20020830070331@fatcity.com>

i might add my 2c, even though the problem has been resolved. :-)

once upon a time, we had a 2g database that was taking a looooooong time to import. anyone ever heard of remedy?

did everything that has already been mentioned.

tracing revealed log file sync waits ... and lots of em' ... (and a few other log type waits ...)

we had long datatypes ...

we were frustrated ... it's only 2 bloody gig after all ...

got rid of the 2nd member of each log group --> byebye log file parallel write waits ...
i then threw the remaining logs on /tmp. bingo. an import that was looking to take > 24hrs suddenly flew.

this was done in test a number of times before we did it on production. but we did put the logs on /tmp in prod. after the import we very quickly moved them off. :-)

the real issue was a poor io subsystem, but oracle's handling of longs during import did not help. never followed up on the internals of it. a document on metalink purporting to shed light on issues w/importing longs was ... "not available to me" (or something like that).

the moral here is, in _certain_ situations, odd little tricks like that can save the day. it ain't for everyone, but in our particular case, logs in memory allowed us to complete a nasty little rebuild (can you say 150000 extents ...) for a very poorly configured db w/in the allocated time window.

cheers,

casey ...

-----Original Message-----
Sent: Thursday, August 29, 2002 5:23 PM
To: Multiple recipients of list ORACLE-L

Oracle 8.1.7 on Solaris 8

I am testing and upgrade from 7.3.4 to 8.1.7. Because the test server is solaris 8, and I can't find the patches for 7 anymore, I am trying to upgrade via an export and import. Besides, the DB is small - less than 2G. The export was done with compress=n. There are 200+ tables to be imported. It is taking 3+ minutes per table for the import, even on tables that have 0 rows. (Though it does take longer than that for the few tables with over 50K rows).

I have tried:

Simple import.
Import with indexes=n
Import with table and constraints (but not indexes) pre-created and indexes=n ignore=y
All of the above with the buffer set to 8M (This actually slows the import down, taking 5+ minutes per table).
Increasing the sort_area_size for the DB to twice as large as it was and trying the above.

In looking at how long it takes, the table imports in a second or less, but it takes 3 minutes + to start the import of the next table. I'm not sure what it is doing for 3 minutes after the table imports.

Does anyone have any ideas how I can speed this up? 10 hours to import a 2G. DB is extreme and unacceptable.

TIA. Terry

Terry Ball, DBA
Birch Telecom
Work: 816-300-1335
FAX: 816-300-1800
--

Please see the official ORACLE-L FAQ: http://www.orafaq.com
--

Author: Ball, Terry
INET: TBall_at_birch.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 also send the HELP command for other information (like subscribing).

--

Please see the official ORACLE-L FAQ: http://www.orafaq.com
--

Author: Casey Dyke
INET: cdyke_at_corp.home.nl

Fat City Network Services    -- (858) 538-5051  FAX: (858) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists
--------------------------------------------------------------------