Re: 8.1.7.4 + 2 patches hangs on imp, strange waits

From: Joel Garry <joel-garry_at_home.com>
Date: 16 Jul 2003 11:29:11 -0700
Message-ID: <91884734.0307161029.6f751680@posting.google.com>

"Anurag Varma" <avdbi_at_hotmail.com> wrote in message news:<TRJQa.4230$lb7.4184_at_news02.roc.ny>...

> "Joel Garry" <joel-garry_at_home.com> wrote in message news:91884734.0307140928.7351091e_at_posting.google.com...

> > "Anurag Varma" <avarmadba.skipthis_at_yahoo.com> wrote in message news:<HmWPa.2247$3G5.61_at_nwrdny03.gnilink.net>...
> > > "Joel Garry" <joel-garry_at_home.com> wrote in message
> > > news:91884734.0307111033.469d6c41_at_posting.google.com...
> > > Those waits are common. Most are idle waits. If you open a sql*plus session
> > > you will see sql*net message from client. The waits don't seem to be
> > > pointing to
> > > any obvious problem.
> >
> > Yeah, my brain was in exp land when I looked at that, had to slap my
> > forehead after posting. Always a risk in using fake addresses with
> > google posting, no easy cancel. :-)
> >
> > >
> > > Try this:
> > > Run a trace on the session doing the import (using oradebug or
> > > dbms_system.set_sql_session_in_trace).
> > > If using oradebug try event 10046 level 12. See what kind of waits that
> > > session is seeing in real time.
> >
> > Will try. I'm really starting to think those patches didn't fix what
> > 8.1.7.4 broke, though.
> >
> > >
> > > and since you have set commit = y ... check on that table: are rows
> > > increasing in that table? or is the session
> > > just hung? You can also check v$transaction (used_ublk) for more clues.
> >
> > I've tried several things, the table always gets stuck with 2168324
> > rows imported. I tried importing just that table (from the next
> > nights export) into an instance running 8.1.7.2, imported 2981011 rows
> > just fine. Now I'm trying just that table from the file being used on
> > 8.1.7.4 to see if it hangs, I expect it to... it did.
> >

> ---snip---
> 
> hmm looks like you are hitting a bug or something is not right after applying those patches.
> I could guess all I like .. but I suppose you are better off opening a TAR on this.
> 
> Let us know if you find out the cause.

Got a tar open, worked through all the "novice" stuff ( http://metalink.oracle.com/metalink/plsql/ml2_documents.showNOT?p_id=139975.1&p_showHeader=1&p_showHelp=1#3803 ) , now it looks like one of two things:

Corrupt dmp file (what are the odds of that happening on my first test? :-)

2G boundary issue. Exporting the table by itself gets a 1.7G file, imports just fine. Support person mentioned there are ocassional reports of tables spanning a 2G boundary having problems, but it is not consistent, otherwise of course everyone would complain and it would be fixed. He mentioned in the old days people would put in dummy tables so real tables wouldn't span (I never did that, but I always piped into compress anyways - why would imp see a difference between a large file and a pipe?)... he also mentioned 2G is the supported limit for exp/imp - even in 9! Recommended FILESIZE.

So I'm off to try last nights export, and maybe poke about in the file to see if that table does indeed span a 2G boundary (I expect it does). I'll also try a SHOW=Y (which I shoulda done before, when I had scripted compressed exports that was part of the script). In between doing actual productive work, of course :-)

--
@home.com is bogus.
http://www.signonsandiego.com/news/uniontrib/wed/business/news_1b16intel.html

Received on Wed Jul 16 2003 - 13:29:11 CDT