Re: [RMAN]

Christian GILBERT <externe.gilbert_at_francetelecom.com> wrote in message news:<1104_1025010242_at_10.193.118.17>...
> Hi !
>
> A little thing I am wondering about :
>
> Is there an interest in using incremental backups to minimize the backup time of a database ?
> I have a 650 Gb DB that can be backed up in a 12 hour window the saturday, but the backup
> window drops at 5 hours during the week. The full backup takes 9 hours.
>
> The Oracle documentation says that as an RMAN incremental backup needs to read all the
> blocks, in order to see which ones were modified, it's running time might be almost the same
> as a full backup.
>
> Does someone have an experience about it ?

Hmmm - to a ChemE - it sounds like you have a large tank to drain. CivE's use gravity - ChemE's use pumps.
Hardware may be the solution.

Can we change the nature of the backup strategy?

• Is there any chance that you can alter some of the tablespaces to READ ONLY? (reduce backup frquency + volume of read only data)
• Do you have tablespaces that only contain indexes which could be re-created? (and could be excluded from the nightly backup)
• Do you have tablespaces that contain data that can be easily re-loaded (quickly, like sqlloader direct)?
• have you benchmarked the amount of time required to apply a day's worth of archived redo (assuming all data loaded aws LOGGING) - so that you might not have to backup each tablespace's datafiles each night? (tradeoff recovery time vs. daily backup volume, amount of arch redo kept online)

The fastest method of backup would likely be splitting mirrored sets. The next fastest method of backup would likely be checkpointing in a 3rd party storage management product (e.g. NetApp - block based changes journaled).
The next fastest method would be for a disk to disk copy - hot backup.

If you have a sufficiently large number of spindles (& controllers) on the source and destination volumes - you could increase your throughput, hence accomodate the window. A 8 disk raid 0 array configured as RAID 0 across 2 Ultra 160/m channels should handle at least 160 MB/sec sustained throughput - probably more. If you parallelize (sp?) the backup - split the job into mod(# of destination controllers+volume pairs) - you could reduce it further. Multiple mount points on a SAN may be just the ticket (dedicated access during the backup window would be most helpful).

Basically, if you can saturate a 100 MB/sec channel with the hot backup, the hot backup should occur in 2 hours, well within the backup window.
More channels, shorter backup window.
What you do with 650 GB of data as a daily volume is another matter entirely.

Vendors do sell products that stripe the backup set across tape drives - but I still like the idea of dumping the backup set off to a staging area to insulate the backup job from media problems.

hth.

Paul Received on Tue Jun 25 2002 - 23:03:44 CDT