Re: rman block recovery

From: joel garry <joel-garry_at_home.com>
Date: Thu, 12 Apr 2012 09:13:19 -0700 (PDT)
Message-ID: <b4bbd82f-5580-40c6-802f-25d69d9391cf_at_vy9g2000pbc.googlegroups.com>



On Apr 11, 7:05 pm, zigzag..._at_yahoo.com wrote:
> On Wednesday, April 11, 2012 11:44:13 AM UTC-4, zigz..._at_yahoo.com wrote:
> > I have a database which has database block corruption. I had a successful rman backup of Sunday.
> > Monday and Tuesday rman backup failed saying
> > ORA-19566: exceeded limit of 0 corrupt blocks for file F:\EM…….
>
> > Then I modified rman script to skip  up to 5 corrupt blocks..
> > set maxcorrupt for datafile 'F:\......' to 5;
>
> > Now my rman backup is successful on Wednesday…
>
> > Now, I want to repair blocks using rman’s block recover command:
> > recover datafile 19 block  321, 322, 385, 513, 577 restore
> > My questions are:
> > a. Will rman automatically start with Sunday’s successful back and then apply archived logs.. or
> > Will it start with Wednesday’s backups and then it won’t be able to recover corrupted blocks…
> > b. How to force rman block recover to start from Sunday’s backup … (Do I have to mark Wedensday's backup as invalid in rman catalog ...
>
> I wonder when block recovery is done will Oracle stop as soon as block is "recoverd" or will it keep applying changes from  archived logs to that block until it runs out of archive logs. If a point in time recovery is applied, then that block can be incosistent with all other blocks because of incomplete recovery ...

Look again at the link I posted, restrictions, you can't do PITR with block recovery. But the example shows you can limit the time of the backup restored _from_. An interesting distinction, eh? It would be inconsistent, but I'm presuming the inability to write to it once corrupt would prevent the inconsistency, because the final redo stream vector would be the last good one. There should be some testing done around this, presumptions aren't so good, and something is bothering me about the redo getting ahead of the data file, especially if the corruption is not detected until backup time.

jg

--
_at_home.com is bogus.
http://www.utsandiego.com/news/2012/apr/11/developer-bank-apps-fight-usaa-patent-infringement/
Received on Thu Apr 12 2012 - 11:13:19 CDT

Original text of this message