Re: exp and archive available.... recover table

From: DA Morgan <damorgan_at_psoug.org>
Date: Wed, 11 Jul 2007 07:01:54 -0700
Message-ID: <1184162513.414584@bubbleator.drizzle.com>

Alexander Skwar wrote:
> DA Morgan <damorgan_at_psoug.org> wrote:
>

>> The purpose of a backup is to handle issues such as lost or corrupt
>> control files, log files, system datafiles, etc. An export will do
>> none of these: Ever.

>
> True. I'd of course also backup control files seperately.
>

>> Nor will an export ever be used to perform a 
>> single block restoration on an open database with connected users.

>
> But what, if you don't need this?

How do you know?

It seems to me that what you consider a database is an entity that is very small, has very few transactions, has very few users, uses no technology or technique more recent than version 7.3.4, and has management that considers availability of more than 10 hours a day a luxury.

And all for the sake of laziness or stubbornness: I can't tell which. There is a tool that is faster, easier, better in every respect, and more importantly SAFER, and you want to argue with me about it. Amazing.

>> BTW: The reason I wanted you to come out here is that I have a 7TB
>> SAN. I wanted to watch you export 6.5TB of data <g> and our restaurants
>> and weather are better this time of year.

>
> It also depends on the size of your databases. If you've got to deal
> with 7TB, then an EXP is obviously not the tool of choice. But if your
> database is by far not so large, then an EXP might be doable. For example,
> an EXP dump for my databases is no larger than 1 GB. That's tiny.
>
> Alexander Skwar

Yet again:

The following system schemas are not exported as part of a Full export because the metadata they contain is exported as part of other objects in the dump file set: SYS, ORDSYS, EXFSYS, MDSYS, DMSYS, CTXSYS, ORDPLUGINS, LBACSYS, XDB, SI_INFORMTN_SCHEMA, DIP, DBSNMP, and WMSYS.

Grants on objects owned by the SYS schema are never exported.

Cross-schema references are not exported. For example, a trigger defined on a table within one of the specified schemas, but that resides in a schema not explicitly specified, is not exported.

Types used by the table are not exported in table mode. This means that if you subsequently import the dump file and the TYPE does not already exist in the destination database, the table creation will fail.

The use of synonyms as values for the TABLES parameter is not supported. For example, if the regions table in the hr schema had a synonym of regn, it would not be valid to use TABLES=regn. An error would be returned.

The export of table partitions is not supported when the NETWORK_LINK parameter is used.

The export of tables that include wildcards in the table name is not supported if the table has partitions.

If you want to handicap yourself and your employer by doing it the 7.3.4 way that is apparently your choice. But I would never refer to what you are doing as a backup and one day, unfortunately, your employer may find out that for the same money they pay you they could have had someone that did it the right way. I would think a desire to perfect your skills and be a professional would have led you to make other choices.

-- 
Daniel A. Morgan
University of Washington
damorgan_at_x.washington.edu (replace x with u to respond)
Puget Sound Oracle Users Group
www.psoug.org

Received on Wed Jul 11 2007 - 09:01:54 CDT