Re: Backup setup sane?

From: Robert Klemme <>
Date: Fri, 16 Oct 2009 21:21:28 +0200
Message-ID: <>

On 10/16/2009 06:36 PM, joel garry wrote:
> On Oct 16, 7:39 am, Robert Klemme <> wrote:
>> On 16 Okt., 15:35, hpuxrac <> wrote:> On Oct 16, 4:39 am, Robert Klemme <> wrote:
>> ...
>>> I really prefer to do any DELETing in separate scripts under separate
>>> schedules.
>> Is this because of load or safety (i.e. to have some time between the
>> backup and the deletion to inspect backup and prevent deletion from
>> running backup had issues)?  From the documentation it seems RMAN
>> would not delete archive logs for example if the backup failed.

> I do my regular backups with RMAN as an EM job, and I must say, it
> took some trial and error to get the configuration right for the
> autodeletion, it seemed too aggressive until I figured what was going
> on. When EM failed, as it is wont to do, I was so glad I had kept my
> earlier RMAN scripts with shell drivers. John's look better, thanks
> for sharing John.

It seems EM in itself is a quite complex thing so for something as important as backup and recover it is probably not a bad idea to rely on simple, rock solid tools like sh and crond for the job where it is easy to see how they work.

>>>  I also prefer to handle archivelogs separate from database
>>> backups.
>> Why is that?

> For me, it is because the volume can change so much from day-to-day
> ops to special circumstances. Right now I'm working on some major
> archiving, which will spew so much I'm considering going noarchivelog
> for the duration.
> Also, standby databases have their own requirements for log handling,
> and this can impact how you handle normal backups.

Good point.

>>> This is what one of my backup scripts looks like:
>>> rman << EOF
>>> connect target
>>> run {
>>> allocate channel d1 type disk format '/u03prod/disk/rman_prod_%M_%D_%Y_
>>> %U.bkp';
>>> backup validate check logical database;
>>> backup incremental level 1
>>> for recover of copy
>>> with tag 'disk_incremental'
>>> database;
>>> recover copy of database with tag 'disk_incremental';
>>> restore database validate;
>>> release channel d1;}
>>> exit;
>>> EOF
>> Thanks!
>>> I am not a big fan of the autobackup of the controlfile and spfile and
>>> followup an rman backup with manual steps to get both of those
>>> available "where I can control them" instead of rman.
>> Again, why is that?  I mean, you can configure the location where RMAN
>> places control files.

> They are so critical to making a restore do the right thing one wants
> to be able to control all circumstances, especially if Oracle does
> something unexpected. I'm still bewildered by disappearing backup
> controlfiles, to the point I just added a separate line in my command
> file to copy it elsewhere (this is an alternative user managed backup
> that does a alter database backup controlfile to..., not RMAN). They
> are explicitly not going to the flash area. It's there when I copy
> it, but not later. This really bothers me. Nothing else disappears
> like this. It must be something I've done...


>>> sqlplus / as sysdba << EOF1
>>> create pfile='/home/oracle/prod_pfile.ora' from spfile;
>>> create pfile='/u03prod/disk/prod_pfile_`date +"%m_%d_%Y"`_`date
>>> +"%T"`.ora' from
>>>  spfile;
>>> alter database backup controlfile to trace as '/u03prod/disk/
>>> prod_controlfile_tr
>>> ace_backup_`date +"%m_%d_%Y"`_`date +"%T"`.ora';
>>> exit;
>>> EOF1
>> Other than the noted points are there any things I missed or issues
>> (like flooding a file system with things that are not automatically
>> purged) I created with my setup?

> That's why we test, and test some more, and watch it carefully in
> production :-)

I certainly will. Can't wait until in two weeks first backups are deleted.



remember.guy do |as, often| as.you_can - without end
Received on Fri Oct 16 2009 - 14:21:28 CDT

Original text of this message