实验第29步： 然后，再在实例1上执行： selectcount(*) from t04209_uname; selectsum(uvalue) from t04209_uname; selectavg(uvalue) from t04209_uname; selectmax(uvalue) from t04209_uname; selectmin(uvalue) from t04209_uname; 多做一些组函数查询，以进一步增大BL的open计数。 在任一个实例上执行： select* from x$OBJECT_AFFINITY_STATISTICS where object=52533;
稍等片刻...... 在任一个实例上执行: select* from v$gcspfmaster_info where object_id=52533;
select drms from X$KJDRMAFNSTATS;
DRM为2+1=3,验证了此刻发生了自动Remaster（第1次Remaster）。 再验证： 进入实例1的/u01/app/oracle/admin/RDBA/bdump: 执行：grep-r"pkey 52533"./ 输出： ./rdba1_lmd0_7002.trc:Transfer pkey 52533 to node 0 ./rdba1_lmd0_7002.trc:Begin DRM(5) - transfer pkey 52533 to 0 oscan 0.0 进入实例2的/u01/app/oracle/admin/RDBA/bdump: 执行：grep-r"pkey 52533"./ 输出： ./rdba2_lms0_7034.trc: GCS CLIENT 0x233f71b0,2 sq[(nil),(nil)] resp[(nil),0x185.40000] pkey 52533 ./rdba2_lms0_7034.trc:pkey 52533 ./rdba2_lms0_7034.trc: GCS CLIENT 0x233f71b0,2 sq[(nil),(nil)] resp[(nil),0x185.40000] pkey 52533 ./rdba2_lms0_7034.trc:pkey 52533 ./rdba2_lmd0_7032.trc:Rcvd DRM(5) Transfer pkey 52533 to 0 oscan 1.1 以上日志都证明发生了对象52533的所有块的remaster，对象52533的所有块的master 实例现在都是实例1。也就是说：如果发生自动Remaster（Object Affinity and Dynamic Remastering引起）或手工Remaster（oradebug命令），整个对象将作为master单元而不进行多个实例分布式地分段master：即不管表多大，它的数据块都由同一个实例master。 在任一个实例上执行: select*from myviewwhere"MASTER_Instance"=2 ; 没有输出，这就对了，因为都被实例1master了。 |
||||||||||||||||||||||||||||||
下面我们继续实验： 实验第30步： 回到实例2依次执行: selectcount(*) from t04209_uname; selectsum(uvalue) from t04209_uname; selectavg(uvalue) from t04209_uname; selectmax(uvalue) from t04209_uname; selectmin(uvalue) from t04209_uname; 还可以多做一些组函数查询，以进一步增大BL的open计数。 |
||||||||||||||||||||||||||||||
实验第31步： 在任一个实例上执行: select* from v$gcspfmaster_info where object_id=52533;
select drms from X$KJDRMAFNSTATS;
DRM为3+1=4,验证了此刻又发生了一次自动Remaster（第2次Remaster）。 再验证： 进入实例1的/u01/app/oracle/admin/RDBA/bdump: 执行：grep-r"pkey 52533"./ 输出： ./rdba1_lmd0_7002.trc:Transfer pkey 52533 to node 0 ./rdba1_lmd0_7002.trc:Begin DRM(5) - transfer pkey 52533 to 0 oscan 0.0 ./rdba1_lmd0_7002.trc:Rcvd DRM(6) Transfer pkey 52533 from 0 to 1 oscan 0.0 进入实例2的/u01/app/oracle/admin/RDBA/bdump: 执行：grep-r"pkey 52533"./ 输出： ./rdba2_lms0_7034.trc: GCS CLIENT 0x233f71b0,2 sq[(nil),(nil)] resp[(nil),0x185.40000] pkey 52533 ./rdba2_lms0_7034.trc:pkey 52533 ./rdba2_lms0_7034.trc: GCS CLIENT 0x233f71b0,2 sq[(nil),(nil)] resp[(nil),0x185.40000] pkey 52533 ./rdba2_lms0_7034.trc:pkey 52533 ./rdba2_lmd0_7032.trc:Rcvd DRM(5) Transfer pkey 52533 to 0 oscan 1.1 ./rdba2_lmd0_7032.trc:Transfer pkey 52533 to node 1 ./rdba2_lmd0_7032.trc:Begin DRM(6) - transfer pkey 52533 to 1 oscan 0.0 以上日志都证明发生了对象52533的所有块的remaster，对象52533的所有块的master 实例现在都是实例2。也就是说：如果发生自动Remaster（Object Affinity and Dynamic Remastering引起）或手工Remaster（oradebug命令），整个对象将作为master单元而不进行多个实例分布式地分段master：即不管表多大，它的数据块都由同一个实例master。 select*from myviewwhere"MASTER_Instance"=1 ; 没有输出。这就对了，因为都被实例2master了。 |
||||||||||||||||||||||||||||||
下面接着研究手工remaster： 实验第32步： 在实例1上: [oracle@node1 ~]$ sqlplus /nolog SQL*Plus: Release 10.2.0.1.0 - Production on Mon Jan 13 16:18:27 2014 Copyright (c) 1982, 2005, Oracle.All rights reserved. SQL> conn/ as sysdba Connected. SQL> oradebug setmypid; Statement processed. SQL> oradebug lkdebug -a hashcount Statement processed. SQL> oradebug lkdebug -k Statement processed. SQL> oradebug lkdebug -m pkey 52533 Statement processed. SQL> oradebug lkdebug -k Statement processed. SQL> oradebug tracefile_name; /u01/app/oracle/admin/RDBA/udump/rdba1_ora_18378.trc 以上操作的目的是手工强迫使实例1重新夺回对象52533所有的块的mastership。 |
||||||||||||||||||||||||||||||
实验第33步： 下面来验证： 节选实例1上的/u01/app/oracle/admin/RDBA/udump/rdba1_ora_18378.trc： /u01/app/oracle/admin/RDBA/udump/rdba1_ora_18378.trc Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Production With the Partitioning, Real Application Clusters, OLAP and Data Mining options ORACLE_HOME = /u01/app/oracle/product/10.2.0/db_1 System name:Linux Node name:node1.example.com Release:2.6.18-164.el5xen Version:#1 SMP Tue Aug 18 16:06:30 EDT 2009 Machine: i686 Instance name: RDBA1 Redo thread mounted by this instance: 1 Oracle process number: 25 Unix process pid: 18378, p_w_picpath: [email protected] (TNS V1-V3) *** 2014-01-13 16:22:07.764 *** SERVICE NAME:(SYS$USERS) 2014-01-13 16:22:07.763 *** SESSION ID:(125.1496) 2014-01-13 16:22:07.763 ***************************************************************** GLOBAL ENQUEUE SERVICE DEBUG INFORMATION ---------------------------------------- Resource hash bucketcount 04 11 24 311 46 56 61 73 84 …… 20392 20402 20416 20425 20432 20449 20452 20462 20473 Total resource count in hash buckets: 8213 ***************** End of lkdebug output ************************* *** 2014-01-13 16:26:26.465 ***************************************************************** GLOBAL ENQUEUE SERVICE DEBUG INFORMATION ---------------------------------------- node# 0, #nodes 2, state 4, msgver 4, rcvver 0 validver 4 valid_domain 1 sync acks 0x000000000000000000000000000000000 Resource freelist #0 len 28410 lwm 2893 add 241108 rem 212698 Resource freelist #1 len 28471 lwm 3306 add 241942 rem 213471 LMS0: Hash buckets log2(11) Bucket# 0 #res 0 Bucket# 1 #res 0 Bucket# 2 #res 0 Bucket# 3 #res 0 Bucket# 4 #res 0 Bucket# 5 #res 0 Bucket# 6 #res 0 Bucket# 7 #res 0 …… atch buckets log2(6) GCS shadow freelist #0 len 29067 lwm 7451 add 88332 rem 59265 GCS shadow freelist #1 len 29097 lwm 7257 add 88862 rem 59765 files in affinity vector: * >> PT table contents ---: pt table bucket = 1 pkey 4294950913, stat 0, masters[32767, 0->0], reminc 2, RM# 1 flg 0x0 pt table bucket = 2 pkey 4294950914, stat 0, masters[32767, 0->0], reminc 2, RM# 1 flg 0x0 pt table bucket = 3 pkey 4294950915, stat 0, masters[32767, 0->0], reminc 2, RM# 1 flg 0x0 pkey 52533, stat 0, masters[0, 1->1], reminc 4, RM# 6 flg 0x0←手工 remaster之前， oradebug lkdebug –k的输出，代表master实例是2（[0, 1->1]中的1->1表示实例2），上一任 master是实例1（[0, 1->1]中的0表示上一任master实例1） * kjilpkey = 0 ***************** End of lkdebug output ************************* *** 2014-01-13 16:27:14.981 ***************************************************************** GLOBAL ENQUEUE SERVICE DEBUG INFORMATION ---------------------------------------- ***************** End of lkdebug output ************************* Latch buckets log2(6) GCS shadow freelist #0 len 7487 lwm 7451 add 88336 rem 80849 GCS shadow freelist #1 len 7569 lwm 7257 add 88863 rem 81294 files in affinity vector: * >> PT table contents ---: pkey 4294950932, stat 0, masters[32767, 1->1], reminc 4, RM# 4 flg 0x0 pt table bucket = 3381 pkey 52533, stat 0, masters[1, 0->0], reminc 4, RM# 7 flg 0x0←手工 remaster之后， oradebug lkdebug –k的输出，代表master实例是1（[1, 0->0]中的0->0表示实例1），上一任 master是实例1（[1, 0->0]中的1表示上一任master实例2） * kjilpkey = 1 ***************** End of lkdebug output ************************* trace文件已经说明：实例1重新夺回了对象52533所有的块的mastership。 select*from myviewwhere"MASTER_Instance"=2 ; 无输出。这就对了，因为都被实例1master了。 select* from v$gcspfmaster_info where object_id=52533;
select drms from X$KJDRMAFNSTATS;
DRM为4+1=5，验证了此刻又发生了一次Remaster（第3次Remaster）。 再验证： 进入实例1的/u01/app/oracle/admin/RDBA/bdump: 执行：grep-r"pkey 52533"./ 输出： ./rdba1_lmd0_7002.trc:Transfer pkey 52533 to node 0 ./rdba1_lmd0_7002.trc:Begin DRM(5) - transfer pkey 52533 to 0 oscan 0.0 ./rdba1_lmd0_7002.trc:Rcvd DRM(6) Transfer pkey 52533 from 0 to 1 oscan 0.0 ./rdba1_lmd0_7002.trc:Transfer pkey 52533 to node 0 ./rdba1_lmd0_7002.trc:Begin DRM(7) - transfer pkey 52533 to 0 oscan 0.0 进入实例2的/u01/app/oracle/admin/RDBA/bdump: 执行：grep-r"pkey 52533"./ 输出： ./rdba2_lms0_7034.trc: GCS CLIENT 0x233f71b0,2 sq[(nil),(nil)] resp[(nil),0x185.40000] pkey 52533 ./rdba2_lms0_7034.trc:pkey 52533 ./rdba2_lms0_7034.trc: GCS CLIENT 0x233f71b0,2 sq[(nil),(nil)] resp[(nil),0x185.40000] pkey 52533 ./rdba2_lms0_7034.trc:pkey 52533 ./rdba2_lmd0_7032.trc:Rcvd DRM(5) Transfer pkey 52533 to 0 oscan 1.1 ./rdba2_lmd0_7032.trc:Transfer pkey 52533 to node 1 ./rdba2_lmd0_7032.trc:Begin DRM(6) - transfer pkey 52533 to 1 oscan 0.0 ./rdba2_lmd0_7032.trc:Rcvd DRM(7) Transfer pkey 52533 from 1 to 0 oscan 0.0 |
表6：自动remaster（ObjectAffinity and Dynamic Remastering引起）和手工改变Master实例的oradebug命令
6．实例恢复过程中的Remaster（Dynamic Reconfiguration）
图5描述了实例1发生故障，实例2恢复的情况：
图5：RAC实例恢复过程
实验第34步： 在实例1上杀死ora_smon进程： [oracle@node1 bdump]$ ps aux | grep ora_smon oracle70570.03.5 808624 96816 ?Ss10:510:01 ora_smon_RDBA1 oracle165570.00.03932716 pts/0S+17:170:00 grep ora_smon [oracle@node1 bdump]$ kill -9 7057 之后不久实例1得到恢复，重新启动： selectcount(*)from myviewwhere"MASTER_Instance"=1;
selectcount(*)from myviewwhere"MASTER_Instance"=2;
显然Oracle采用了“ lazy remastering”算法，实例1在恢复后仅仅重新remaster了原来的一部分资源。原因是实例2在为实例1做交叉恢复时所 Master到的资源就由实例2Master保管了。 此时select* from v$gcspfmaster_info where object_id=52533; 无输出。 select drms from X$KJDRMAFNSTATS;
DRM为5+3=5，验证了此刻又发生了三次lazy remaster。 |
||||||||||||
实验第34步： 进一步：把实例1所在的操作系统关闭。 稍等片刻…… selectcount(*)from myviewwhere"MASTER_Instance"=1;
稍等片刻…… selectcount(*)from myviewwhere"MASTER_Instance"=1;
selectcount(*)from myviewwhere"MASTER_Instance"=2;
全部由实例2接管了。 |
表7：实例恢复过程中的remaster（DynamicReconfiguration）
总结
在RAC的体系结构中,全局资源目录（Global ResourceDirectory简称GRD）是Oracle RAC数据库中最重要的内存结构。对于一个数据块而言，管理该数据块的状态和属主信息以及数据块内部和数据块自身的锁信息的实例只有一个。这个实例就被称作为该数据块（或更准确地说：资源）的Master实例。从10g以后版本开始，数据块的状态和属主等信息被存储成每128个块的信息一个master单元，即128个数据块的状态和属主等信息构成一个“gcs mastership bucket”。但是要说明以下：一个“gcs mastership bucket”不一定要存满128个块的状态和属主等信息。这样就能理解：超过128个块的表的数据块可以被多个实例分布式地分段master。如果发生自动Remaster（ObjectAffinity and Dynamic Remastering引起）或手工Remaster（oradebug命令），整个对象将作为master单元而不进行多个实例分布式地分段master：即不管表多大，它的数据块都由同一个实例master。另外，任何时候undo段整段必需由同一个实例master。