RAC共享online redo log和archived log的官方说明

理解redo共享了和redo单个sequence里面的scn不连续，就会明白为什么RAC到RAC的恢复或RAC到单机的恢复，一般都是recover到某个thread的某个scn或sequnce就可以了


All online redo logs must be accessible for instance recovery. Therefore, Oracle recommends that you mirror your online redo logs.
所有在线重做日志必须可访问，例如恢复。 因此，Oracle建议您镜像您的在线重做日志。

When one instance performs recovery for another instance, the surviving instance reads online redo logs generated by the failed instance and uses that information to ensure that committed transactions are recorded in the database. Thus, data from committed transactions is not lost. 
当一个实例为另一个实例执行恢复时，幸存的实例会读取失败实例生成的联机重做日志，并使用该信息确保已提交的事务记录在数据库中。 因此，提交的事务的数据不会丢失。


1、正常运行时，每个实例写各自thread的online redo，但能够读取其他实例thread的online redo
2、所以redo放在共享存储上，使得redo对所有RAC节点可见，这样才能进行实例接管



However, during recovery, only one node applies the archived logs. Therefore, the node that is performing the recovery must be able to access all of the archived logs that are needed for the recovery operation. 
但是，在恢复期间，只有一个节点应用归档日志。 因此，正在执行恢复的节点必须能够访问恢复操作所需的所有归档日志。

For example, if node1 archives a log to /oracle/arc_dest/log_1_100_23452345.arc, then node2 can back up this archived redo log only if it can read /oracle/arc_dest/log_1_100_23452345.arc on its own file system.
例如，如果node1将日志归档到/oracle/arc_dest/log_1_100_23452345.arc，则node2可以备份这个归档文件的前提就是node2可以在自己文件系统中读取/oracle/arc_dest/log_1_100_23452345.arc。



如下理解了RAC里面每个sequence里面redo的scn并不是连续的。例如35129里面scn范围为10228512840941-10228512976004，34892里面的scn起点为10228512928135，刚好在10228512840941-10228512976004之间。
SQL> select group#,thread#,sequence#,status,first_change#,next_change# from gv$log where inst_id=1 order by 5;

    GROUP#    THREAD#  SEQUENCE# STATUS              FIRST_CHANGE#         NEXT_CHANGE#
---------- ---------- ---------- ---------------- ---------------- --------------------
         5          2      35129 ACTIVE             10228512840941       10228512976004
         2          1      34892 ACTIVE             10228512928135       10228513074747
         6          2      35130 ACTIVE             10228512976004       10228513148004
         3          1      34893 ACTIVE             10228513074747       10228513214381
         4          2      35131 CURRENT            10228513148004      281474976710655
         1          1      34894 CURRENT            10228513214381      281474976710655


SQL> select inst_id,group#,thread#,sequence#,status,first_change#,next_change# from gv$log order by 6;

   INST_ID     GROUP#    THREAD#  SEQUENCE# STATUS              FIRST_CHANGE#         NEXT_CHANGE#
---------- ---------- ---------- ---------- ---------------- ---------------- --------------------
         1          5          2      35129 ACTIVE             10228512840941       10228512976004
         2          5          2      35129 ACTIVE             10228512840941       10228512976004
         2          2          1      34892 ACTIVE             10228512928135       10228513074747
         1          2          1      34892 ACTIVE             10228512928135       10228513074747
         2          6          2      35130 ACTIVE             10228512976004       10228513148004
         1          6          2      35130 ACTIVE             10228512976004       10228513148004
         2          3          1      34893 ACTIVE             10228513074747       10228513214381
         1          3          1      34893 ACTIVE             10228513074747       10228513214381
         1          4          2      35131 CURRENT            10228513148004      281474976710655
         2          4          2      35131 CURRENT            10228513148004      281474976710655
         1          1          1      34894 CURRENT            10228513214381      281474976710655
         2          1          1      34894 CURRENT            10228513214381      281474976710655

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/30126024/viewspace-2143868/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/30126024/viewspace-2143868/