Re: Hot Backups
Date: 1995/04/19
Message-ID: <3n2v8v$ljj$1_at_sydney.DIALix.oz.au>#1/1
Don Vick (dvick_at_lanier.com) wrote:
: In article <3mvatq$bmt_at_ionews.ionet.net>,
: Laurel McGilvery <lmcgilvi_at_ionet.net> wrote:
: >We are currently backing up a 30 gig database to optical disk drives
: >using a combination of hot and cold backups. Has anyone out there run
: >hot backups backing up more than one tablespace at a time? I know the
: >book recommends against it. Just curious what would happen. I don't
: >propose testing it on a production system. Our main issue is the backup
: >software is NOT as flexible as one would like. Unfortunately, I have to
: >use it to access the optical drives.
: >
: We are wrestling with similar backup needs, and have been frustrated by the
: capabilities of the backup software. If I understand this correctly, the
: problem with doing hot backups on multiple tablespaces is redo log
: limitations. When a tablespace is in backup status, Oracle saves all
: update activity in the redo logs and catches up the data files after the
: backup is done. Redo logs cannot be archived if they contain active data,
: so you run the risk of running out of online redo logs and stalling your
: system (i.e., blocking udpates). (I may have some details wrong here, but
: that is the general idea. :-)
: Scheduling the backups during light activity may avoid this problem, but if
: your shop is like ours, finding a period of light activity long enough for
: a backup is quite a challenge. We are leaning toward a "one tablespace at
: a time" strategy, even though disk performance characteristics suggest that
: "one disk at a time" is faster overall.
: --------------------------------------------------------
: Donald E. Vick (dvick_at_lanier.com, dvick_at_crl.com)
: Voice: (404) 493-2194 Fax: (404) 493-2399
I have been running a production online backup set of scripts for a 25Gb
6.0.36 base for the past year or so. They work like this:
Query the data dictionary for datafiles and archivelog mode. Assign datafiles (based on size) to four worker scripts, appending approp. dd commands and device pointers. Alter all tablespaces begin backup Concurrently (useing & and wait) run the four worker scripts Alter all tablespaces end backup
This is an extremely simple psuedo code of our procedure. During this overnight run we generally process between 1.5Gb and 2.5Gb of archived redo log and have found very little performance degredation (much less than the published 10%) for the process. The only bogey man is if instance failure occurs during the process. Then instead of an easy warm boot you have to recover from backup start, which with 1 or so Gb of redo to apply is a bit time consuming.
-- --------------------------------------------------------------------------------| Michael Guthrie | Phone (Mob) 015 277 359 | Email guts_at_sydney.dialix.oz.au | IDSolutions | (02) 484 6769 | --------------------------------------------------------------------------------Received on Wed Apr 19 1995 - 00:00:00 CEST