Re: Help needed with Import/Export

Norman,

Thanks for your helpful tip regarding the compress option. Luckily I ended up not having to do the import after all. No activity had been done in the database since our tape backup, so we restored our system from that. Voila! as if the problem never occurred except for a little glitch involving a corrupted rollback segment. Dropped the other rollback segments, dropped the rollback tablespace because the corrupted rollback segment couldn't drop, then recreated the segments.  Then recreated the tablespace/datafile with the 'reuse' option.

Oh and yes, we've just started working on a migration to 8.1.7 - also not in support, I believe. Still, should be better than where we are.  I'm sure that I will be hanging out here alot :P

Regards,
Kathi Manley
Controller/DBA

Norman Dunbar <Norman.Dunbar_at_lfs.co.uk> wrote in message news:<E2F6A70FE45242488C865C3BC1245DA703FCB8B9_at_lnewton.leeds.lfs.co.uk>...
> Morning Kathi,
>
> you asked for flames, here's one :
>
> <BEGIN FLAME>
> Never ever ever export with that bl**dy compress=y option.
> <END FLAME>
>
> There, I've made my point I think !
>
> Compress=y says to exp, "count up all the extents for this table and
> make the initila size equal to this sum. Then make the next size equal
> to some large proportion of this sum, write this script into the dump
> file so that imp can create the table on the fly during import - if
> required".
>
> Trust me, one day you are going to have to import back into an empty
> schema, and you might/will find that suddenly, you cannot import because
> a table is looking for a contigious bit of free space which it huge, and
> you don't have one.
>
> Been there, wore the T shirt, never want to do it again !
>
>
> Ok, as for your import, the tables still have the constraints in placem
> and the import is importing tables in alphabetical order, so some child
> tables are being imported before their parent so you get constraint
> errors. You can drop the tables first (cascade constraints) which will
> drop the tables, indexes and constraints, and have the import recreate
> them - which is not a problem, unless you have compress=y, in which
> case, look out for problems !
>
> Having it this way should make the import quicker (unless you have large
> numbers of extents to recreate) because the indexes are not being
> updated and constraints are not being checked for each and every row
> being imported.
>
> Cheers,
> Norm. (Founder member of the Campaign to Remove Compress from Exp
> Society - CRCES) :o)
>
> PS. Did I mention that 734 is unsupported ?
> PPS. I've *still* got one 734 database here myself :o)
>
> -------------------------------------
> Norman Dunbar
> Database/Unix administrator
> Lynx Financial Systems Ltd.
> mailto:Norman.Dunbar_at_LFS.co.uk
> Tel: 0113 289 6265
> Fax: 0113 289 3146
> URL: http://www.Lynx-FS.com
> -------------------------------------
>
>
> -----Original Message-----
> From: katelynal_at_hotmail.com (Kathi) [mailto:katelynal_at_hotmail.com]
> Posted At: Saturday, August 02, 2003 3:40 AM
> Posted To: server
> Conversation: Help needed with Import/Export
> Subject: Help needed with Import/Export
>
>
> I have a question which I am sure is fairly simple, but beyond my
> grasp at the moment. Our billing software is running on Oracle 7.3.4,
> HP Tru64 Unix 4.0G. Before the monthly billing run is started, an
> export is done with the following command -
>
> imp user/password buffer=209715200 grants=n compress=y
> file=/data4/dumps/backup080103.dmp log=/data4/dumps/restore080103.log
>
> Due to operator error, the run was started without all of the data
> loaded that needed to be billed. I want to do an import to put the
> database back to the place it was this morning. Other than attempting
> to perform the import, there has been no activity in the database.
>
> I used the following command
>
> imp user/password buffer=209715200 file=/data4/dumps/backup080103.dmp
> grants=n log=/data4/dumps/restore080103.log ignore=y full=y
>
> which results in constraint errors.
>
> All of the info I have seen on this group didn't address this kind of
> case where I just want to populate the tables with the old data. (I
> know this is oversimplifying.)
>
> Any help would be greatly appreciated. Feel free to flame away due to
> our ancient database version - I'm trying to get our management to
> understand the ramifications.
>
> Thanks,
> Kathi Manley
> Controller/DBA
Received on Mon Aug 04 2003 - 11:06:26 CDT