Re: Using export as a backup strategy

Thomas Richards wrote:
>
> Oracle 8i 8.1.5 on NT.
>
> I have a database for which a day's data loss is an acceptable risk.
> From reading the Oracle Backup and Recovery guide, I get the
> impression that export is recommended as a supplement to a backup
> strategy rather than a backup strategy in itself.
>
> Please can someone explain why export only can't be used in a scenario
> where a day's data loss is acceptable and there is a period of no user
> activity when a consistent export can be achieved?
>
> If I lose a disk, can I not create an empty database and load the
> previous night's backup?
>
> Is there any advantage to doing physical backups that I have
> overlooked? For example, if I do export only should I be doing control
> file backups as well?
>
> Any thoughts on this much appreciated
>
> Thanks
> Tom

Basically it comes down to the following: what is your required RECOVERY strategy (or at least needs)?

A lot of the strategy I've seen is designed to minimize the time to recovery, maximize the "accuracy" of recovery, and to minimize the missing/lost/stale data. Ability to do partial recovery, data restore, and so on also factors into the discussion and these tend to be tricky with export/import.

However, it's quite silly to design or use a backup strategy that doesn't meet the recovery needs.

A lot of organizations and thinkers make the assumption that the data being 'very current' is important enough that recovery based on the last available logical snapshot is insufficient. They also find the time/effort/cost required to create an empty database during crisis to house that snapshot is very high. If these costs are too high, or recovery of a logical snapshot is not sufficient, then export/import IS insufficient by itself.

Some 'professionals' disdain the idea of export/import alone, partly out of habit (done it for years), partly out of simplicity (already set up the template/process), and partly out of experience (our recovery needs are x/y/z).

However, you mention 'control file backups' and that implies you have not fully defined your recovery needs. (For example: a control file backup will be totally useless in the empty database scenario).

Think it through: If you are convinced that you have the time, the energy, the process in place or at least documented, to recreate an empty database of appropriate size and then do an import, and you are happy with the resulting data being only as recent as your last snapshot (export), then go for it. Based on the very high level parameters you mention, and export/import should be sufficient (for a while).

A couple of reminders, whatever the mechanism for backup: test the recovery procedure, and ; make sure the backup is consistent (eg: do "shutdowns", "suspends" or whatever is relevant).

Just My Opinion
/Hans Received on Thu Jan 08 2004 - 14:00:47 CST