Re: Very URGENT! Tablespace Extent Problem w/ Import

All I can say is you've been bloody lucky: it's not a text file (and there wouldn't be a log option or an indexfile option if it were).

But clearly, there's a risk I'm just being a bit of an old woman on this one... so I've just tested it. Export database...drop EMP....import EMP... success.

Make one change to the dump file (in this case, change EMP's Initial Extent from 64K to 32K) in notepad, and save. Drop EMP....import EMP.... import bombs out with complaints about the character set used in the dump file.

Er, did I back up the original dump file... did I buggery... I am now EMP-less!! Cheers, Dave! (OK, I admit, it wasn't your fault).

This is boring Windows 2000, and ye veritable notepad, 8.1.6. But I think my point is that (1) this is not recommended by Oracle (2) it's strongly dis-recommended by Oracle (3) it's stuffed up 100% of the times I've ever attempted it (not just this little test) and (4) it's not the kind of thing I'd recommend to newbies or the desperate.

HJR "Dave Haas" <davehaas_at_hotmail.com> wrote in message news:94j0h1$3vf$1_at_news3.cadvision.com...
> Hi Howard.
>
> I have edited MANY dump files with text editors (both Unix & NT) and have
> never had a problem. Granted the 'create table first' solution was
 probably
> better, but for small changes it sometimes seems easier to just edit the
> dump file.
>
> I was also trying to explain the problem a little bit :)
>
> Regards,
>
> Dave Haas
>
>
> "Howard J. Rogers" <howardjr_at_www.com> wrote in message
> news:3a6cfe7c_at_news.iprimus.com.au...
> >
> > "Knut Talman" <knut_at_mytoys.de> wrote in message
> > news:3A6CFAF3.DD57AA42_at_mytoys.de...
> > > > Dave, have you ever edited an expdat.dmp file, and then proceeded to
 import
> > > > successfully? I only ask because the data that is inserted by all
 those
> > > > "insert into" statements is binary encoded, and text-editing the
 dump
 file
> > > > is almost guaranteed to stuff that encoding up (and hence lose your
 data).
> > > >
> > > > The dump file most certainly isn't a text file, and should never be
 treated
> > > > as such. I guess you might get away with it once in a while, but I
 wouldn't
> > > > bet on it as a long-termer.
> > >
> > > If I may answer: I edited the dump files with a hex editor
> > > (khexedit) and wrote it back. I did not change the length of
> > > the file, just replaced the numbers in the STORAGE clause with
> > > my numbers. Until now there is no error from IMPORT (it is
> > > still running).
> > > BTW, my Linux workstation could not edit the file due to a lack
> > > of memory, so I did it on the server.
> > >
> > > Cheers,
> > >
> > > Knut
> >
> > No, that's fair enough... the fact you used a HEX editor is the thing,
> > confirming that the dump file really is a binary encoded file, not a
 text
> > one. I have students open the thing up in vi, trying to change the
> > tablespaces in which tables are stored for example, and then wonder why
 the
> > import spits the dummy -after all, you *can* see most of its contents in
 vi
> > (or notepad, come to that).
> >
> > Fingers crossed, eh?
> >
> > 5am????? Are you mad??!
> >
> > Regards
> > HJR
> >
> >
> >
> >
> >
>
>
Received on Mon Jan 22 2001 - 22:35:14 CST