Re: Backup setup sane?
From: Robert Klemme <shortcutter_at_googlemail.com>
Date: Fri, 16 Oct 2009 21:21:28 +0200
Message-ID: <7jrvdpF36hesnU1_at_mid.individual.net>
On 10/16/2009 06:36 PM, joel garry wrote:
> On Oct 16, 7:39 am, Robert Klemme <shortcut..._at_googlemail.com> wrote:
>
> 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.
>
> 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.
>
> 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...
>
> That's why we test, and test some more, and watch it carefully in
> production :-)
Date: Fri, 16 Oct 2009 21:21:28 +0200
Message-ID: <7jrvdpF36hesnU1_at_mid.individual.net>
On 10/16/2009 06:36 PM, joel garry wrote:
> On Oct 16, 7:39 am, Robert Klemme <shortcut..._at_googlemail.com> wrote:
>> On 16 Okt., 15:35, hpuxrac <johnbhur..._at_sbcglobal.net> wrote:> On Oct 16, 4:39 am, Robert Klemme <shortcut..._at_googlemail.com> 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.
Cheers
robert
-- remember.guy do |as, often| as.you_can - without end http://blog.rubybestpractices.com/Received on Fri Oct 16 2009 - 14:21:28 CDT