实验第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;



ADDR

INDX

INST_ID

OBJECT

NODE

OPENS

1

B7EAB520

1

2↖INST_ID为2代表Mater实例为实例2,还没发生Remaster事件

52533

1实例1有大量的BL Open计数

42317

稍等片刻......

在任一个实例上执行:

select* from v$gcspfmaster_info where object_id=52533;



FILE_ID

OBJECT_ID

CURRENT_MASTER

PREVIOUS_MASTER

REMASTER_CNT

1

0

52533

0代表master实例是1

32767代表之前没发生过remaster

0

select drms from X$KJDRMAFNSTATS;



DRMS

1

3

DRM2+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;



FILE_ID

OBJECT_ID

CURRENT_MASTER

PREVIOUS_MASTER

REMASTER_CNT

1

0

52533

1代表master实例是2

0代表上一任master是实例1

0


select drms from X$KJDRMAFNSTATS;



DRMS

1

4


DRM3+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, image:  oracle@node1.example.com (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;



FILE_ID

OBJECT_ID

CURRENT_MASTER

PREVIOUS_MASTER

REMASTER_CNT

1

0

52533

0代表master实例是1

1代表上一任master是实例2

0

select drms from X$KJDRMAFNSTATS;



DRMS

1

5


DRM4+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恢复的情况:


wKioL1LV9jnD6LZXAAJnt0BiPG0656.jpg


图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;



COUNT(*)

1

21011

selectcount(*)from myviewwhere"MASTER_Instance"=2;



COUNT(*)

1

20981

显然Oracle采用了“ lazy remastering”算法,实例1在恢复后仅仅重新remaster了原来的一部分资源。原因是实例2在为实例1做交叉恢复时所  Master到的资源就由实例2Master保管了。


此时select*  from v$gcspfmaster_info where object_id=52533;

无输出。


select drms from X$KJDRMAFNSTATS;



DRMS

1

8


DRM5+3=5,验证了此刻又发生了三次lazy  remaster



实验第34步:

进一步:把实例1所在的操作系统关闭。

稍等片刻……

selectcount(*)from myviewwhere"MASTER_Instance"=1;



COUNT(*)

1

11009


稍等片刻……

selectcount(*)from myviewwhere"MASTER_Instance"=1;



COUNT(*)

1

0

selectcount(*)from myviewwhere"MASTER_Instance"=2;



COUNT(*)

1

41789

全部由实例2接管了。


表7:实例恢复过程中的remasterDynamicReconfiguration


总结

在RAC的体系结构中,全局资源目录(Global ResourceDirectory简称GRD)是Oracle RAC数据库中最重要的内存结构。对于一个数据块而言,管理该数据块的状态和属主信息以及数据块内部和数据块自身的锁信息的实例只有一个。这个实例就被称作为该数据块(或更准确地说:资源)的Master实例。从10g以后版本开始,数据块的状态和属主等信息被存储成每128个块的信息一个master单元,即128个数据块的状态和属主等信息构成一个“gcs mastership bucket”。但是要说明以下:一个“gcs mastership bucket”不一定要存满128个块的状态和属主等信息。这样就能理解:超过128个块的表的数据块可以被多个实例分布式地分段master。如果发生自动RemasterObjectAffinity and Dynamic Remastering引起)或手工Remasteroradebug命令),整个对象将作为master单元而不进行多个实例分布式地分段master:即不管表多大,它的数据块都由同一个实例master。另外,任何时候undo段整段必需由同一个实例master