Re: imp commit=n and rbs

"Niall Litchfield" <n-litchfield_at_audit-commission.gov.uk> wrote in message news:<3eae4f5f$0$29716$ed9e5944_at_reading.news.pipex.net>...
> "Joel Garry" <joel-garry_at_home.com> wrote in message
> news:91884734.0304281606.182d772b_at_posting.google.com...
> > Well maybe, but more than 5 times the table size? I'm tellin' ya, my
> > "something weird this way comes" light is flashing brightly.
>
> IIRC Imp also does an analyze which may/will generate undo. On the other
> hand (and I guess block dumps are probably the way to answer definitively)
> more than 5 times the size and '5 indexes' seem suspiciously close to me. If
> I produce an indexfile from an import and parse out only the create
> statements I get

I grabbed a 100M from the beginning and end of the RBS data file (which of course are not the beginning and end of the segment, I believe from "tablespace map" the first thing in the file was the second extent, and the end is just something random from near the beginning, the 8th or ninth or something) in case I ever get a chance to od. I did cat it to my screen, which made for some interesting ascii graphics that appeared to scroll up and down like wagon wheels go backwards and forwards in the movies (and incidently to verify there is the character data there). Initial and next for this RBS are 2048K btw.

>
> CREATE INDEX <OWNER>.<NAME> ON <TABLE_NAME>(<COLUMN_LIST>) .... LOGGING; for
> each index. Now I believe that you always get UNDO generated when you make a
> block modification and so as well as the rowids (and column values) that
> Norman talks about you will I imagine get UNDO for the block changes to the
> base tables block headers. This looks like quite a good argument for
> producing the indexfile as I said above and modifying LOGGING; to NOLOGGING;

Well, of course, I'm not trying to figure out how to make it work, using the right commit does that, I'm just trying to figure out why it is so way out of line. I will definitely be looking for block header undo if I ever get the chance to put more time into this. And trying it without some of the indices might give a good enough answer!

>
> I'll pass on the opportunity to comment on COMPRESS=Y just this once :)

You guys are just too nice! :)

jg

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