We're reformulating database backup routines. Oracle RMAN on 9i is being used on 9i databases while the older ones still use OS-based scripts.
Since we're considering as new hardware AIX 5L running on a SAN with Flashcopy feature, a few questions:
1) OS-based scripts should be migrated to a new routine using Flashcopy *even* for the 9i databases (RMAN on db's older than 9i is out of question)?
2) Does flashcopy features on backup and recovery override RMAN ? Is there any point if we continue with RMAN?
From my point of view, RMAN incremental backups become less important when we consider that complexity of backup routines are greater than Flashcopy's. However, the ability to optimize backupsets and manage redundancy on the database level are to be considered too.
Can anyone point something about an environment running both RMAN and Flashcopy? Is it worth trying? Any insights?
An ounce of action is worth a ton of theory.
—Friedrich Engels
Well, with flashcopy our backups should be something like "split mirror, backup mirror, leave production alone". Simple like that, no recovery catalog, incremental levels etc. However, backups should be almost always full backups.
With RMAN, we can use incremental backups, compress backupsets, perform block-level recovery etc. But since backups would be done directly on production, backup time would probably be greater than Flashcopy's one.
If RMAN+Flashcopy is possible, we'd get RMAN benefits without affecting production directly. But I didn't understand yet how RMAN would access the mirror volumes as if they were a database itself.
Any misconception of mine?
An ounce of action is worth a ton of theory.
—Friedrich Engels
Well, I thought of two backup strategies like that:
Strategy #1
- Flashcopy database to a backup disk (full); after that, production remains with normal activity
- Configure a clone database on another server, accessing flashcopy backup as its datafiles. Register that "clone" database on RMAN
- Backup the clone database with RMAN directly to tape. Here, we choose full/incremental backups as appropriate. Full export the export database as appropriate.
In case of disaster, we would:
- Restore/recover from RMAN to backup disk;
- Mirror backup disk over production disk;
Strategy #2
- Flashcopy database to a backup disk (full/incremental as appropriate);
- TAR the contents to tape;
In case of disaster, we would:
- Restore the tape contents to disk;
- Apply archivelogs as needed;
#2 seems more simple, but it relies only on hardware and doesn't involve RMAN. #1 takes advantage of RMAN features, but it's more complex and falls on extra licensing (it's almost like Data Guard).
Anyway, we'll be probably working on RAC, which makes the issue more challenging
An ounce of action is worth a ton of theory.
—Friedrich Engels
Please note that neither flashcopy nor EMC's BCV will gurantee that the DB will be recovered all the time.
On one site where I worked, BCV always failed on Thursday early morning. The reason: Heavy batch jobs were scheduled to run during the BCV time.
Basically they are designed to mirror disk volumes at the hardware level. So, a reporting db can be configured on the BCVed disks in no time.
Reply With Quote
Bookmarks