Re: imp commit=n and rbs

Norman Dunbar <Norman.Dunbar_at_lfs.co.uk> wrote in message news:<E2F6A70FE45242488C865C3BC1245DA7039B1A8F_at_lnewton.leeds.lfs.co.uk>...
> Hi Joel,
>
> on import you'll have lots of new rows being inserted - so lots of 18
> byte rowids end up in the rbs in case of a rollback.

2.1 million rows * 18 = ?G?

> Plus you need details for changes to sys.fet$ and sys.uet$ which also
> change as extents are used and no longer free.

compress=Y on export, table in single extent truncated, ignore=y. Due to previous performance issues, this table is explicitly as defragmented and contiguous as possible. (That affected about 5%-20%, depending on how measured, of the performance issues, BTW. Irrelevant here, except as to extent management in RBS. Yes, I know _all about_ compress=Y, and it is appropriate for the situation.).

> Plus you have index creation details to rollback.

Well maybe, but more than 5 times the table size? I'm tellin' ya, my "something weird this way comes" light is flashing brightly.

> Plus any details of autoextending files.

Don't do that.

> Constraints being created.

Hmmmm... need to check that, since this is a summary file, I don't think that should be at issue, but it is possible the 4GL that dinked with it may have done something overly-friendly... but still, more than 5* the table size?

Thanks!

jg

--
@home.com is bogus.
"Keep on Truckin'."  -  One of the more notorious copyright thefts.