Oracle FAQ | Your Portal to the Oracle Knowledge Grid |
Home -> Community -> Usenet -> c.d.o.tools -> Re: exp file format / functionality blues
Sybrand Bakker <postbus_at_sybrandb.demon.nl> wrote:
> > I think I tried this and it doesn't work. The problem is that the dump
> > file contains explicit specifications of the target tablespace (i.e.
> > statements of the form CREATE TABLE (...) TABLESPACE "OLD_TBLSPC").
> > Thus, if the receiving user doesn't have privilege / quotas on the
> > old tablespace any longer, the import fails.
>
> Did you follow my advice to the letter including make sure the default
> tablespace of that user is the new tablespace.
> If it still didn't work, that's very strange, because it worked for me many
> times.
Well -- I haven't tried it again, but it seems to me that this is exactly what I was doing: Using the userid "development", I tried to import a dump which was created by user "production". Both users have different default tablespaces, and permissions on one tablespace each.
The import worked only when I pre-created the tables, with the usual flood of warnings.
> > I strongly disagree. A DBA is a person who knows what she/he is
> > doing,
>
> Sorry to disagree with that. You can have an OCP certificate and still don't
> know what you are doing. One of my major functions at my current employer is
> to clean the mess of my colleague DBAs made and left behind at customers.
> Needless to say that is very frustrating.
You are right, of course, in stating that having a certificate and / or being employed as a DBA doesn't automatically mean that you know what you're doing. What I meant to say was that for me, the administrator of a database is like the superuser of a Unix system: The sytem should support him/her in performing all operations that are technically possible.
While this does not mean that everyone with root access to a Unix system or with DBA privileges on an Oracle instance is automatically competent to use the tools at their disposal, there's no alternative from simply trusting them and assuming that they are. If they're not, big problems may result (as you describe).
However, using formats that are not properly editable is not a suitable method for preventing people from messing things up. It just makes it difficult to perform well-defined, reasonable operations. If detection of manipulation was desired, it would be adequate to include an MD5 checksum (or something alike) in the dump file, and to have ``imp'' refuse to accept manipulated files unless forced to do so by commandline parameter.
Finally, I'm not sure whether the dump file format was designed to include binary stuff in order to make it harder to edit dump files. If that was really intended, compressing and encrypting the file would be the method of choice. From looking at the dump file format, it seems to me that numerical types and some other stuff are written out in binary representations just because it might work faster that way (and probably it's convenient for the programmer too).
> and the database software should support him/her in getting
> > that done. While it may well be that exp / imp are the wrong tools for
> > doing what I want to do, but there is no reason to assert that
> > modifying a database structure is dangerous to any database.
>
> I didn't say that. I said (I will rephrase) 'An export is a logical unity,
> you shouldn't edit it, because this will create significant problems'
Ok -- as I understand this, this means that export and import are not the right tools for obtaining an external representation of a database's contents which would be suitable for being imported into a new database in which the structure is already present. The question remains: What are the right tools for this purpose?
Greetinx, Jan
-- +- Jan T. Kim -------------------------------------------------------+ | email: kim_at_mpiz-koeln.mpg.de | | WWW: http://www.mpiz-koeln.mpg.de/~kim/ | *-----=< hierarchical systems are for files, not for humans >=-----*Received on Mon Jul 03 2000 - 00:00:00 CDT