RE: IMPORT sloooowwww

[Cary Millsap]

Title: RE: IMPORT sloooowwww

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, Oct 1–3 San Francisco, Oct 15–17 Dallas, Dec 9–11 Honolulu - 2003 Hotsos Symposium on Oracle® System Performance, Feb 9–12 Dallas - Next event: Miracle Database Forum, Sep 20–22 Middlefart Denmark -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Casey Dyke Sent: Friday, August 30, 2002 10:04 AM To: Multiple recipients of list ORACLE-L Subject: RE: IMPORT sloooowwww   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----- From: Ball, Terry [mailto:[EMAIL PROTECTED]] Sent: Thursday, August 29, 2002 5:23 PM To: Multiple recipients of list ORACLE-L Subject: IMPORT sloooowwww   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:   1)  Simple import.   2)  Import with indexes=n   3)  Import with table and constraints (but not indexes) pre-created and indexes=n ignore=y   4)  All of the above with the buffer set to 8M  (This actually slows the import down, taking 5+ minutes per table).   5)  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: [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).