技术开发 频道

Oracle RAC学习笔记:基本概念及入门

    12、RAC和Instance/crash recovery

    1)当一个Instance失败,当该失败被其他Instance检测到,第二个Instance将会执行下面的恢复操作:

    ①在恢复的第一阶段,GES重新灌入队列

    ②GCS也重新灌入其资源。GCS进程只重新灌入那些失去其控制的资源。在这期间,所有的GCS资源请求和写请求都临时被挂起。然而,事务可以继续修改data blocks,只要这些事务已经获得了必要的资源。

    ③当队列被重新配置后,一个活动的Instance可以获得占有该Instance恢复队列。因此,当GCS资源被重新灌入的同时,SMON确定需要被恢复的blocks的集合。这个集合被称作恢复集。因为,使用cache 融合算法,一个Instance传送这些blocks的内容到请求的Instance,而不需要将这些blocks写入磁盘。这些blocks在磁盘上的版本可能不包含其他Instance进程的data的修改操作的blocks。这意味着SMON需要合并所有失败的Instance的redo logs来确定恢复集。这是因为一个失败的线程可能导致一个在redo 中的hole(洞)需要用指定的block填补。所以失败的Instance的redo 线程不能被连续的应用。同时,活动的Instances的redo 线程不需恢复,因为SMON可以使用过去和当前的通信缓冲的镜像。

    ④用于恢复的缓冲空间被分配,并且那些之前读取redo logs被辨识的资源被声明为恢复资源。这避免了其他Instance访问这些资源。

    ⑤所有在随后的恢复操作中需要的资源被获得,并且GRD当前是不冻结的。任何不需恢复的data block现在可以被访问。所以当前系统时部分可用的。此时,假设有过去或当前的blocks镜像需要被恢复,而其在cluster Database中的其他caches中,对于这些特殊的blocks,最近的镜像是开始恢复点。如果对于要恢复的block,过去镜像和当前镜像缓冲都不在活动的Instance的caches中,则SMON将写入一个log,表明合并失败。SMON会对第三步中辨识的每个block进行恢复和写入,在恢复之后会马上释放资源,从而使更多的资源在恢复时可以被使用。

    当所有的block被恢复,占用的恢复资源被释放,则系统再次可用。

    note:在恢复中,log合并的开支和失败的Instances的数目是成比例的,并且与每个Instance的redo logs的大小有关。

    2)Instance recovery和Database availability

    上图显示了在进行Instance恢复时,每一步执行时数据库的可用程度:

    A.  RAC运行在多节点上

    B.  有节点失败被检测到

    C.  GRD的队列部分被重新设置;资源管理被重新分配到活动的nodes。此操作的执行比较快

    D.  GRD的缓冲部分被重新设置,SMON读取失败Instance的redo logs辨识那些需要恢复的blocks的集合

    E.  SMON向GRD发起请求,获得所有在需要恢复的blocks集合中的Database blocks。当请求结束,所有的其他的blocks都可被访问了

    F.  Oracle执行滚动的向前恢复。失败线程的redo logs被应用到Database,并且那些被完全恢复的blocks将马上可以被访问

    G.  Oracle执行滚回恢复。对于尚未提交的事务,undo blocks被应用到Database中

    H.  Instance的恢复完成,所有的data可以被访问

    13、有效的内部节点行级锁

    Oracle支持有效的行级锁。这些行级锁主要是在DML操作时被创建,例如UPDATE。这些锁被持有,直到事务被提交或回滚。任何请求同行的lock的进程都将被挂起。

    cache融合算法的块传输独立于这些user可见的行级锁。GCS对blocks的传输是一个底层的操作,无需当代行级锁被释放就开始进行。blocks可能被从一个Instance传输到其他其他Instances,同时该blocks可能被加锁。

    GCS提供对data blocks的访问,允许多个事务的并发进行。

    14、RAC的额外的内存需求

    RAC特有的内存多数是在SGA创建时从shared pool中分配的。因为blocks可能跨越Instances被缓冲,必须要求更大的缓冲区。因此,当将single Instance的Database迁移到RAC中时,保持每个Instance的请求工作量都能通single-instance时的情况,则需要对运行RAC的Instance增大10%的buffer cache和15%的shared pool。这些值只是基于RAC大小的经验,一个初始的尝试值。一般会大于此值。

    如果正在使用推荐的自动内存管理特性,可以通过修改SGA_TARGET初始参数来设置。但考虑到同样数量的user访问被分散到多个nodes中,每个Instance的内存需求可以被降低。

    实际资源的使用可以通过查询每个Instance中的GCS和GES实体中的视图V$RESOURCE_LIMIT视图CURRENT_UTILIZATION和MAX_UTILIZATION字段,具体语句为:

    SELECT resource_name, current_utilization, max_utilization FROM v$resource_limit WHERE resource_name like ‘g%s_%’;



 

0
相关文章