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