设为首页收藏本站

Botang唐波's Oracle Station

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

2014-7-15 16:51| 发布者: admin| 查看: 2105| 评论: 0

摘要: 本文探索Oracle RAC数据库的内部原理。探索Oracle RAC数据库的调优源头,弄清“Master实例”、“Owner实例”、“Past Image”和“Current Image”的概念。


5自动RemasterObject Affinity and Dynamic Remastering引起)手工Remasteroradebug命令)


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



NAME

VALUE

1

_gc_affinity_time

1010秒查看一下是否要做Remastering(不是分钟)

2

_gc_affinity_limit

50要发生Remastering的实例必须比环境中其它所有实例访问某一个对象的总和还要多50BL计数

3

_gc_affinity_minimum

2400每分钟最少要有的dynamic affinity活动个数,才会发Remastering


下面我们来做自动remasterObject Affinity and Dynamic Remastering引起)的实验。

实验第27步:

在任一个实例上执行:

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



COUNT(*)

1

138


在任一个实例上执行:

select * from x$OBJECT_AFFINITY_STATISTICS where object = 52533;

无输出,这是正常的。 x$OBJECT_AFFINITY_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;

多做一些组函数查询,以进一步增大BLopen计数。

在任一个实例上执行:

select * from x$OBJECT_AFFINITY_STATISTICS where object = 52533;



ADDR

INDX

INST_ID

OBJECT

NODE

OPENS

1

B7EAB520

1

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

52533

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

42317

稍等片刻......

在任一个实例上执行:

select * from v$gcspfmaster_info where data_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(第1Remaster

再验证:

进入实例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。也就是说:如果发生自动RemasterObject Affinity and Dynamic Remastering引起)或手工Remasteroradebug命令),整个对象将作为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;

还可以多做一些组函数查询,以进一步增大BLopen计数。


实验第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(第2Remaster

再验证:

进入实例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。也就是说:如果发生自动RemasterObject Affinity and Dynamic Remastering引起)或手工Remasteroradebug命令),整个对象将作为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;



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(第3Remaster

再验证:

进入实例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:自动remasterObject Affinity and Dynamic Remastering引起)手工改变Master实例的oradebug命令


6实例恢复过程中的RemasterDynamic Reconfiguration

    5描述了实例1发生故障,实例2恢复的情况:



5RAC实例恢复过程


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



COUNT(*)

1

21011

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


实验第34步:

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

稍等片刻……

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



COUNT(*)

1

11009


稍等片刻……

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



COUNT(*)

1

0

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



COUNT(*)

1

41789

全部由实例2接管了。


7:实例恢复过程中的remasterDynamic Reconfiguration



总结

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






1

鲜花

握手

雷人

路过

鸡蛋

刚表态过的朋友 (1 人)

相关阅读

QQ|手机版|Botang唐波's Oracle Station    

GMT+8, 2017-6-16 16:37 , Processed in 0.114097 second(s), 22 queries .

返回顶部