DataGuard Physical Standby and Incremental Restore

From: Nabil Jamaleddin <nmjamaleddin_at_multiservice.com>
Date: Mon, 14 Apr 2014 15:48:23 -0500
Message-ID: <283101cf5822$e1225650$a36702f0$_at_multiservice.com>


 

I have a PSB physical standby database. I made a copy of this database on Friday. Today I took an incremental backup of the PSB and applied it to the copy on Monday.  

The command I used for the back goes like:  

--Done this on the Physical Standby

backup current controlfile for standby format '/u01/acfsmounts/workload/refresh/stndby_use.ctrl';

backup as compressed backupset incremental from scn 18647449933 database format '/u01/acfsmounts/workload/refresh/Inc_%U';    

I then applied the incremental backup to the copy like this:  

--ran this command on the copy database

recover database noredo;    

After this all my datafiles were up to date;  

Select unique checkpoint_change# cc from v$datafile_header order by 1;

18722154712  

But the control file was still at the old scn:  

select name,checkpoint_change# cc from v$datafile;

18647449933    

To get the controlfile and datafiles to the same SCN I had to use the backup of the controlfile from above.  

I would think the recover database noredo would have rolled the controlfile forward with the datafiles. Why did this not happen? Is there a way to apply an incremental backup to a standby database and keep the original controlfiles meaning not restoring the controlfile from the backup set.    

And I would like to have my physical standby database feed logs to another physical standby database. Is this possible?    

It archive logs would flow look like this:  

Prod à Physcial Standby à physical Standby    

Thanks                       

--



This email is intended solely for the use of the addressee and may contain information that is confidential, proprietary, or both. If you receive this email in error please immediately notify the sender and delete the email.

--

http://www.freelists.org/webpage/oracle-l Received on Mon Apr 14 2014 - 22:48:23 CEST

Original text of this message