续【博客文章2015】Oracle11gR2 RAC数据库中的Master实例、Owner实例、Past Image和Current Image的概念

实验第26步：

在任一个实例上执行：

select x.ksppinm name, y.ksppstvl value

from sys.x$ksppi x, sys.x$ksppcv y

where x.indx = y.indx

and substr(x.ksppinm, 0, 1) = '_'

and x.ksppinm like '_gc_policy%';

下面我们来做自动remaster（Object Affinity and Dynamic Remastering引起）的实验。

实验第27步：

在任一个实例上执行：

select count(*) from myview where "OWNER_Instance" <> "MASTER_Instance";

在任一个实例上执行：

select * from x$OBJECT_POLICY_STATISTICS where object = 52533;

无输出，这是正常的。 x$OBJECT_POLICY_STATISTICS统计信息会定时清空。

实验第28步：

在实例1上：连续做以下两条语句，直到t04209_uname表中有51200000行记录为止。

insert /*+ append */

into t04209_uname

select * from t04209_uname;

commit;

实验第29步：

然后，再在实例1上执行：

select count(*) from t04209_uname;

select sum(uvalue) from t04209_uname;

select avg(uvalue) from t04209_uname;

select max(uvalue) from t04209_uname;

select min(uvalue) from t04209_uname;

多做一些组函数查询，以进一步增大BL的open计数。

在任一个实例上执行：

select * from x$OBJECT_POLICY_STATISTICS where object = 52533;

稍等片刻......

在任一个实例上执行:

select * from v$gcspfmaster_info where data_object_id = 52533;

select drms from X$KJDRMAFNSTATS;

DRM为2+1=3,验证了此刻发生了自动Remaster（第1次Remaster）。

再验证：

进入实例1的/u01/app/oracle/diag/rdbms/RDBA/RDBA1/trace:

执行：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/diag/rdbms/RDBA/RDBA2/trace:

执行：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 myview where "MASTER_Instance" = 2;

没有输出，这就对了，因为都被实例1master了。

下面我们继续实验：

实验第30步：

回到实例2依次执行:

select count(*) from t04209_uname;

select sum(uvalue) from t04209_uname;

select avg(uvalue) from t04209_uname;

select max(uvalue) from t04209_uname;

select min(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 myview where "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 bucket count

0 4

1 1

2 4

3 11

4 6

5 6

6 1

7 3

8 4

……

2039 2

2040 2

2041 6

2042 5

2043 2

2044 9

2045 2

2046 2

2047 3

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 myview where "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

实验第34步：

在实例1上杀死ora_smon进程：

[oracle@node1 bdump]$ ps aux | grep ora_smon

oracle 7057 0.0 3.5 808624 96816 ? Ss 10:51 0:01 ora_smon_RDBA1

oracle 16557 0.0 0.0 3932 716 pts/0 S+ 17:17 0:00 grep ora_smon

[oracle@node1 bdump]$ kill -9 7057

之后不久实例1得到恢复，重新启动：

select count(*) from myview where "MASTER_Instance" = 1;

select count(*) from myview where "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=8，验证了此刻又发生了三次lazy remaster。

实验第34步：

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

稍等片刻……

select count(*) from myview where "MASTER_Instance" = 1;

稍等片刻……

select count(*) from myview where "MASTER_Instance" = 1;

select count(*) from myview where "MASTER_Instance" = 2;

全部由实例2接管了。