RDB incremental v full backups

[Thomas Ritter]

Currently it takes about 8 hours to complete an online RMU full backup of our Production database. The so called online backups are proving to be Operator intensive. Work mix problems with locking particular this RDB latching page problem result in either batch jobs or the backup stalling. We need to improve the backup performance. We have rejected running multithreaded backups, that is writing to two tapes at the same time, because of problem with the way tape labels have to be allocated in advance.

Is anybody running incremental versions of the backup ? That is a full backup on say Sunday and then incremental versions during the week. If you are running backups like this, what is the performance like, what are the risks. Any suggestions ?

Executing RMU for Oracle Rdb V7.1-441 on VMS 7.3-2

[John Gillings]

Thomas,

IMHO Tape technology is past its used by date. Too slow, too expensive and too risky. The problem with an 8 hour backup is in the restoration. Does it represent the beginning of the operation, the end, or something in between? How long would it take to restore?

If you can afford a few seconds down time, use 3 member shadow sets of the drive(s) holding your data bases. At an opportune time, shutdown the application, remove the 3rd member from the shadow set and immediately restart. Just a few seconds downtime. Now add different drives as new 3rd members and let them copy up. Rotate disk drives as required, possibly removing physical drives from shelves for offsite storage (or, copy them to tape at your leisure).

If you ever need to restore you know PRECISELY what the backup contains, and can restore simply by replacing the physical drive and starting your application. Instant recovery.

Compare the cost of the tape cartridges against additional disk drives, then the comparative costs of recovery.

[Thomas Ritter]

John, thanks. Restore time from Production to Test is about 14 hours ! The systems here are at end of life... which could mean lights out anytime from 1 year to 5 years. Previous disk to disk proposal was rejected.

[Malcolm Wade · Accepted solution]

Thomas,

We do it! Similar problem BUT we roll to a disk staging area.

On a Friday night we use:

$ RMU/BACKUP/ONLINE/LOG db_file -
disk_backup_area:db_file.RBF

Then during the rest of the week we use:

$ RMU/BACKUP/ONLINE/LOG /INCREMENTAL -db_file_name -disk_backup_area:db_file.INCR_RBF

Must admit, it's been a long while since I used the restore in anger BUT you must make sure that you restore the FULL backup, then IMMEDIATELY, without messing with the restored DB, apply the last incremental file.

Our DB is about 70GB; but to SAN/EVA disk from an ES47 it only takes about an hour to backup anyway. Just saves on the remaining system backup time which picks up these smaller daily files and rolls them off to tape.

Another thing you can try is increasing your RMS buffers setting. I discovered this 10+ years ago, this is what I use:

$ SET RMS_DEFAULT -/BLOCK=127 /BUFFER_COUNT=255 -
/EXTEND_QUANTITY=10000

I can't recall wether this helps when rolling to tape (extend_quantity is irrelevant) but is certainly helps rolling off to disk. BIG savings.

Make sure you reset the settings afterwards (=0) or let the process finish up.

VMS is V7.3-2, RDB is V7.1-10

Hope this helps?

Malcolm

[Richard J Maher]

Hi Thomas,

You can do parallel backups to disk now, if that gets around any labelling concerns.

This stuff still needs an extra license though doesn't it? Still the fact that Rdb, as a DBMS, actually ships with something as escoteric as a backup utility must've certainly raised eyebrows at Oracle :-) What Zero down-time and no cross-fingers quite-point or redundant shadow-set? Bizare!

Cheers Richard Maher

PS. "Lights out in 1-5 years" yeah right :-) Where have I heard that before?

[Martin Hughes]

Note that RMU/BACKUP has qualifiers for extend and block size.

We also use disk -> disk, at least as a staging area, before writing the RBF files to tape. I sympathise if this option is not available to you.