| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Usenet -> c.d.o.server -> Re: exp and archive available.... recover table
DA Morgan <damorgan_at_psoug.org> wrote:
> 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?
Actually, about 18hrs is good enough right now.
> 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.
Well, that tool, rman, doesn't even let me specify the names of the file that it should create - please see thread <news:1240493.UQgxmLvFx2_at_kn.gn.rtr.message-center.info>. Granted, I might have done something wrong. No, it's not "might", it's rather pretty sure that I did something wrong. No doubt. How would I do it right?
>>> 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
Okay.
> Grants on objects owned by the SYS schema are never exported.
Fine.
> 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.
No problem.
> 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.
I do a FULL exp.
> 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.
Again, I'm doing FULL exports.
> The export of table partitions is not supported when the NETWORK_LINK
> parameter is used.
We don't have partitions.
> The export of tables that include wildcards in the table name is not
> supported if the table has partitions.
Doesn't exist here.
> I would think a desire to perfect your skills
> and be a professional would have led you to make other choices.
I am currently educating myself in the use of RMAN. Up to now, we shut down the database at night and made a cold copy of the datafiles. That was good enough up to now.
You know, as I said, it's really a matter of size. If you're talking about multi TB databases which have to be up 24×7 and have to be there like 99.999%, then yes, by all means, EXP is most certainly absolutely *not* the way to go.
But there are also less demanding requirements.
Best regards,
Alexander Skwar Received on Wed Jul 11 2007 - 09:12:56 CDT
 |
 |