Re: To do or not to do (export)?

  • From: Guillermo Alan Bort <cicciuxdba@xxxxxxxxx>
  • To: David Ballester <ballester.david@xxxxxxxxx>
  • Date: Wed, 7 Oct 2009 07:10:13 -0300

Yes, you are correct and this is the point that has been made, however, from
an application point of view, in that case I would not be able to guarantee
consitency...

If I have an export from last sunday, and it's wednesday, I would still go
for wither a full DB restore or a db duplication en export/import of the
whole schema, not just the table.

But that's just my point of view...

cheers.
Alan Bort
Oracle Certified Professional


On Wed, Oct 7, 2009 at 6:19 AM, David Ballester
<ballester.david@xxxxxxxxx>wrote:

>
>
> 2009/10/7 Guillermo Alan Bort <cicciuxdba@xxxxxxxxx>
>
> Hi listers,
>>
>>    As usual we are having discussions regarding backups... this time it's
>> exports. Should we take exports of databases? Assuming we have a valid and
>> reliable tape backup structure (TSM with TDPO or NBU with Oracle Integration
>> Agent) daily incr/diff backups and weekly full backups. Hourly archivelog
>> backups. Is there any benefit to export that is not covered by this backup?
>>
>> Thanks in advance!
>>
>> cheer.
>> Alan Bort
>> Oracle Certified Professional
>>
>
>
> Hi Alan:
>
> Like a lot of things in this life, depends ;)
>
> Having your backup infrastructure and policies is ok but, for example:
>
> If you need to import data from a logical failure ( an admin/user
> droping/deleting a table for example ) you will need to clone de database
> using the last backup, apply archives until the instant before the drop -if
> needed-, open database, extract data ( export, select spool... ), import
> into the production database, clean the 'cloned' environment.
>
> Depending on what type of data you loose, you will give no service in this
> period. If you can import directly from a daily/weekly export, you avoid the
> time of cloning and recovering, but may be you need to apply archives.. who
> knows, your question has no direct answer ;)
>
>
> D.
>
>

Other related posts: