Oracle 10g RAC中的DRM

原文链接：http://www.banping.com/2009/08/26/rac_drm/

 

在RAC环境中，Oracle使用GRD（Global Resource Service）来记录各个RAC节点的资源信息，具体通过GCS（Global Cache Service）和GES（Global Enqueue Service）这两个服务进行管理。

由于在RAC中每个节点都有自己的SGA和buffer cache，为了保证Cache资源的一致性和提高性能，GCS和GES会指定RAC中的一个instance来管理Cache，这个节点这时就是Resource Master。

在10g以前，Cache资源是不能在各个节点间移动的，除非重启或者某节点因为其他异常被RAC驱逐等情况。而10g的DRM就解决了这个问题，它可以保证cache能够被remaster到频繁访问这部分数据的节点上，从而提高RAC的性能。DRM的全称是Dynamic Resource Mastering，metalink上的Doc ID:  390483.1文档详细介绍了DRM的信息。

DRM的过程是十分迅速的，一般不会影响到RAC系统的应用。但是也存在一定的BUG，在10.2.0.3的版本之前可能出现Libary cache lock而导致实例挂起，这时可以考虑停用DRM，修改两个隐含参数即可：

_gc_affinity_time=0
_gc_undo_affinity=FALSE

metalink上Doc ID:  467777.1具体描述了这个truncate语句引发的案例。

remaster的过程中，lmd进程会在trace文件中如下日志信息：

*** 2009-06-24 08:29:48.257
* kjdrchkdrm: found an RM request in the request queue
  Transfer pkey 56500 to node 0
*** 2009-06-24 08:29:48.337
Begin DRM(2343) - transfer pkey 56500 to 0 oscan 0.0
*** 2009-06-24 08:29:48.338
Begin DRM(2343) - transfer pkey 56524 to 0 oscan 0.0
 ftd received from node 1 (26/0.31.0)
 all ftds received
 syncr inc 26 lvl 8873 from 1 rcvd (my inc,lvl: 26, 8872) (26/0.31.0)
 ftd received from node 1 (26/0.34.0)
 all ftds received

我碰到的一个类似的案例，在alert日志里记录的告警信息如下：

GES: Potential blocker (pid=385334) on resource LB-975F92C3-87052713;
enqueue info in file /u01/admin/erpdb/bdump/erpdb1_lmd0_635140.trc and DIAG trace file

检查DIAG trace file可以发现385334号进程的信息：

Dumping diagnostic information for ospid 385334:
OS pid = 385334
loadavg : 3.20 3.08 2.98

last wait for 'latch: row cache objects' blocking sess=0x0 seq=63971 wait_time=2351 seconds since wait started=940
                address=700000579b64ca0, number=c7, tries=0
    Dumping Session Wait History
     for 'latch: row cache objects' count=1 wait_time=2351
                address=700000579b64ca0, number=c7, tries=0
     for 'latch: row cache objects' count=1 wait_time=25630
                address=700000579b64ca0, number=c7, tries=0
     for 'latch: row cache objects' count=1 wait_time=22914
                address=700000579b64ca0, number=c7, tries=0
     for 'latch: row cache objects' count=1 wait_time=231800
                address=700000579b64ca0, number=c7, tries=2
     for 'latch: row cache objects' count=1 wait_time=292984
                address=700000579b64ca0, number=c7, tries=1
     for 'latch: row cache objects' count=1 wait_time=293009
                address=700000579b64ca0, number=c7, tries=0

但这里的等待是不是DRM引发的还不好确定，能确定的就是Library cache的使用是有问题的，经过调整参数后，错误尚未重现。