Oracle-L: RE: IMPORT sloooowwww

From: Cary Millsap <cary.millsap_at_hotsos.com>
Date: Fri, 30 Aug 2002 08:33:28 -0800
Message-ID: <F001.004C428F.20020830083328@fatcity.com>

I like the way you found the root cause. If I may paraphrase, you asked the database how it was spending its time, and the answer guided the remainder of your performance improvement project. I contrast this method with the traditional approach, which is to try to guess at a root cause from the domain of literally thousands of possible root causes.

Cary Millsap
Hotsos Enterprises, Ltd.
http://www.hotsos.com

Upcoming events:
- Hotsos Clinic <http://www.hotsos.com/training/clinic> , Oct 1-3 San Francisco, Oct 15-17 Dallas, Dec 9-11 Honolulu - 2003 Hotsos Symposium <http://www.hotsos.com/events/symposium> on OracleR System Performance, Feb 9-12 Dallas - Next event: Miracle Database Forum <http://www.miracleas.dk> , Sep 20-22 Middlefart Denmark

-----Original Message-----
Sent: Friday, August 30, 2002 10:04 AM
To: Multiple recipients of list ORACLE-L

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: Cary Millsap
INET: cary.millsap_at_hotsos.com

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