Re: RMAN: RESTORE DATABASE VALIDATE question

From: Subodh Deshpande <deshpande.subodh_at_gmail.com>
Date: Wed, 11 Apr 2012 11:47:04 +0530
Message-ID: <CAJsOtB6DiEFYkKNJMbqakZOao=KnGMv4pawTH4DrgieAMV6DwA_at_mail.gmail.com>



Hello Anthony,
I was in your place..I would not have raised any object for such script for test database and for production there are some concerns..

I am confused..if following is your backup-recovery script..then it is not correct..
backup script should be separate and recovery script should be separate..and keep log of both..with proper naming convention.. validate is used to check the block corruption etc..it slows the process.. while taking backup you used validate that does not mean recovery will be smooth..
if you are very often receiving backup-recovery related or corruption related issues..then better to use validate clause..

and everyday, if this script is getting fired on same database..for what reason..(test database from backup recovery perspective can be exception but the generic test or development database can not become exception for such scripts)
I mean you are backing up the database everyday ..(must do it..) and also recovering the same database..on same host..why...

backup pieces should be and can be tested on other databases too..it is not necessary(or the only truth) that they can only be tested on the same database..your backup automatically get tested in the event of crash recovery..for the rest of the you can test your backup and restore only performing recovery other host..

basically recovering backup piece on other database/host is one of the wise method of finding lacuna in backup and recovery policy !

It is recommended to have separate backup scripts depending upon the purpose and need.
backup script for current control file with pfile/spfile backup script for database backup and archive logs plus current control file, with levels
backup script for archive backups
maintenance backup script should be separate..

you can keep separate scripts or parametrise within single script..

it is good to have crosscheck backup and expires absolutes with noprompt, every day but this is fancy statement unless you know retention period..other rman parameters used for backup and recovery..

what is your policy if backup or restore fails..it is good to have standby, rac database, of they also should be supported with backup and restore policy but standby and rac gives more option from availability, performance perspective..

thanks and take care..subodh

On 4 April 2012 00:53, Anthony Ballo <anthony.ballo_at_onecall.com> wrote:

> Looking for general advice here and to clear up any misconceptions I have.
> I am looking at RMAN scripts currently running in both Prod/Test
> environments and I have a question about RESTORE DATABASE VALIDATE
> statements being used in our daily FULL backup scripts. For example (see
> #8) below:
>
> RMAN> connect target *
> 2> run{
> 3> allocate channel d1 type disk;
> 4> sql 'ALTER SYSTEM archive log current';
> 5> backup as copy database format '+DG1';
> 6> sql 'ALTER SYSTEM archive log current';
> 7> release channel d1;}
> 8> restore database validate;
> 9> crosscheck copy;
> 10> crosscheck archivelog all;
> 11> delete noprompt obsolete;
> 12> list copy;
> 13> exit;
>
>
>
> From my understanding, RESTORE DATABASE VALIDATE only validates Datafiles
> for RESTORE - not Archivelogs needed for a complete RECOVER. Also from
> what I recall from OU Admin Class, one would run this command prior to an
> actual restore and probably not daily. Plus, to accomplish what I think
> the prior DBA intended (test a RECOVER), you would also issue a "RESTORE
> ARCHIVELOG ALL VALIDATE" statement immediately after.
>
> What is the general consensus here?
>
>
>
> Thanks,
>
>
> Anthony
>
> Environment Info: 10.2/RAC(2-node)/ASM/No Catalog/OEL5
>
> --
> http://www.freelists.org/webpage/oracle-l
>
>
>

-- 
=============================================
Love me or Hate me both are in my Favour.
Love me, I am in your Heart. Hate me, I am in your Mind.
=============================================


--
http://www.freelists.org/webpage/oracle-l
Received on Wed Apr 11 2012 - 01:17:04 CDT

Original text of this message