Re: Question on RAC user-managed recovery

  • From: Harish Kalra <harish.kumar.kalra@xxxxxxxxx>
  • To: Amir.Hameed@xxxxxxxxx
  • Date: Thu, 19 Jan 2006 12:40:56 +0530

Hi Amir,

Inline with Jonathan reply, As per my understnading, Oracle uses Lampport
scheme for SCN implimentation, which has some limitations also. Like if you
have two instance  rac1 and rac2 and both instances are in synch with SCN
100.

Now assume two transactions T1 on rac1 and T2 on rac2.
T2 starts later than commit of T1 and less than the time delay defined by
max_commit_propagation_Delay, in this case T2 may not see changes made by T1
and will increase local SCN (which was 100 on rac2) and assign 101 to
transaction T2. T1 will also have 101 SCN in this case.


So it depends upon setting of max_commit_propagation_delay also. Generally
this is set to 7 seconds and resynchronization of instances for SCN happens
as follows:

Iff max_commit_propagation_delay is less than 1 second then log writer send
message to each instance to update SCN after writing to redo log.
If max_commit_poragation_delay is set to default then oracle will resynch on
every three seconds using piggybacking.

Thanks
-Hairsh Kalra






On 1/13/06, Hameed, Amir <Amir.Hameed@xxxxxxxxx> wrote:
>
> Folks,
> I am running some time-based database instance recovery tests in the lab
> on a three-node RAC environment. The following command was issued from one
> RAC instance while the others were down. I am trying to understand the way
> the change number (change 7286467501233) is being displayed on the first
> line of each of the first three threads below. Why is this number common
> here? After that, this number is distinct in each subsequent archived log
> file. I would appreciate if someone can explain/clarify it for me.
>
> Thank you
> Amir
>
> SQL> recover database until time '2006-01-12:15:20:00' using backup
> controlfile
> ORA-00279: change 7286467501233 generated at 01/11/2006 14:38:59 needed
> for thread 1
> ORA-00289: suggestion : /u107/oradata/archives/e52rac/log_1_778.dbf
> ORA-00280: change 7286467501233 for thread 1 is in sequence #778
>
> Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
>
> ORA-00279: change 7286467501233 generated at 01/11/2006 14:38:35 needed
> for thread 2
> ORA-00289: suggestion : /u107/oradata/archives/e52rac/log_2_463.dbf
> ORA-00280: change 7286467501233 for thread 2 is in sequence #463
>
> Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
>
> ORA-00279: change 7286467501233 generated at 01/11/2006 14:38:37 needed
> for thread 3
> ORA-00289: suggestion : /u107/oradata/archives/e52rac/log_3_408.dbf
> ORA-00280: change 7286467501233 for thread 3 is in sequence #408
>
> Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
>
> Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
>
> ORA-00279: change 7286467508134 generated at 01/11/2006 14:43:27 needed
> for thread 2
> ORA-00289: suggestion : /u107/oradata/archives/e52rac/log_2_464.dbf
> ORA-00280: change 7286467508134 for thread 2 is in sequence #464
> ORA-00278: log file '/u107/oradata/archives/e52rac/log_2_463.dbf' no
> longer needed for this recovery
> ..
> ..
>

Other related posts: