Re: Help with hot backups

From: Howard J. Rogers <hjr_at_dizwell.com>
Date: Tue, 18 May 2004 08:04:25 +1000
Message-ID: <40a936db$0$8984$afc38c87@news.optusnet.com.au>

Sybrand Bakker wrote:

> On Mon, 17 May 2004 13:46:53 -0400, "Chuck Lucas"
> <chuck.lucas_at_mspbNOSPAM.gov> wrote:
> 
> 

>>I've been charged with taking hot backups of our database. It's Oracle
>>8.1.7 on Solaris 8 (sparc).
>>
>>I've come up with a RMAN script, but I'm not sure where to tell Oracle to
>>"archive log current". Below is the current script.
>>
>>run {
>> allocate channel tape1 type 'sbt_tape';
>> backup
>> format '%d_%u_%s_%p_%t'
>> (database);
>> sql 'alter system archive log current';
>> backup
>> format '%d_%u_%s_%p_%t'
>> (archivelog all delete input);
>> release channel tape1;
>> }
>>
>>After reading the documentation, it stated placing the "archive log current"
>>after the database backup, to ensure the "backup information" is included in
>>the redo (archive) logs. But, I'm thinking placing it there, won't give
>>enough time for the archive process to archive the log before RMAN actually
>>starts working on the archive logs. I thought about moving the "archive log
>>current" statement to BEFORE the database backup (which should give it
>>enough time to archive), but then I'm afraid I won't get everything in the
>>current redo log. Or maybe I should put the statement in BOTH places, to
>>make sure I get everything?
>>
>>Really appreciate any assistance anyone could offer on this.
>>
>>Much thanx,
>>Chuck

> 
> 
> You don't have multiple channels allocated so your backup operations
> will be executed serially and synchronously. So actually you won't
> have 'alter system archivelog' and backup in parallel.
> This makes a alter system archivelog before the database backup
> redundant.

Even with multiple channels, RMAN processes each job contained within a script serially.

If your script says

allocate channel [6 times]
backup database;
archive log current;
backup archivelog;
copy datafile 1;

...then 6 channels will all simultaneously do the backup (subject to other settings of course); and when that has finished, 1 will initiate the log switch; and when that has finished, all 6 start backing up the archives; and when that's finished 1 will copy data file 1.

It's why, for example, if you said

allocate channel 1
allocate channel 2
allocate channel 3

copy datafile 1;
copy datafile 2;
copy datafile 3;

...then only channel 1 performs any work, because there are three separate jobs to be performed, one at a time. Therefore only 1 channel is ever in use. Parallelising copies would require:

allocate channel 1
allocate channel 2
allocate channel 3
copy datafile 1, datafile 2,datafile 3;

One copy job, three channels to do the work simultaneously.

In other words, it's how you present the jobs to the channels that governs simultaneity. Separate jobs are always done serially.

Meaning that he will *never* have the alter system and the backup in parallel, no matter how many channels he throws at the problem (they are separate commands, must therefore be separate jobs, and will always therefore be performed serially).

Regards
HJR Received on Mon May 17 2004 - 17:04:25 CDT