GES/GCS 리소스 확인

SQL> select resource_name, current_utilization, max_utilization
  from v$resource_limit
 where resource_name like '%g_s%'
 order by resource_name;

RESOURCE_NAME     CURRENT_UTILIZATION MAX_UTILIZATION
----------------- ------------------- ---------------
gcs_resources                    6615            6615
gcs_shadow                       9716            9716
ges_cache_ress                   1218            1364
ges_locks                        4911            5071
ges_ress                         7772            7872

SQL> select *
  from v$sgastat
 where name like '%gcs%'
    or name like '%ges%'
 order by name;

POOL         NAME                                 BYTES
------------ -------------------------- ---------------
shared pool  gcs resource                       4927120
shared pool  gcs shadows                        3630512
shared pool  ges resource                       2602392
shared pool  ges enqueues                       5171824

-- v$resource_limit 는 ges_locks 를, v$sgastat 는 ges enqueues 를 보여줌, GCS 에 대한 enqueue(lock) 정보는 없음
-- 캐시 처리 빈도수가 훨씬 많고, 전송되는 패킷의 크기도 훨씬 크기 때문에, 캐시 처리와 일반적인 enqueue 처리를 분리 함 : global cache resources 를 위한 분리 구조 (gcs RESOURCE, gcs SHADOWS)
-- 오라클은 리소스를 제어(mastering)하기 위한 권한을 모든 인스턴스에게 동등하게 공유 하나, master 를 제외한 인스턴스는 master 리소스로 부터 중요한 정보의 일부를 포함하는 shadow 리소스를 유지.

리소스 조회 데모

-- WRH$_LATCH (OBJ_ID:6334,0x18be) 의 TM 리소스 조회
select *
  from gv$dlm_ress
 where resource_name like '%0x18be%TM%';

select *
  from gv$ges_enqueue
 where resource_name1 like '%0x18be%TM%';

-- 세 개의 모든 노드에서 관련된 이름의 리소스가 존재, enqueue 의 할당(gv$ges_enqueue)는 노드 1에서만 보여짐
-- INST_ID = 1 : TM 리소스의 마스터 노드, 두개의 인스턴스(OWNER_NODE IN (1, 2))가 리소스를 사용 (OWER_NODE 는 0 부터 시작)
-- GRANT_LEVEL, REQUEST_LEVEL : KJUSERCW(concurrent write), v$lock 에서 보여지는 row-exclusive 와 같음
INST_ID				: 1
HANDLE				: 000000008D2537C0
GRANT_LEVEL			: KJUSERCW
REQUEST_LEVEL			: KJUSERCW
RESOURCE_NAME1			: [0x18be][0x0],[TM][ext 0x0,0x0
RESOURCE_NAME2			: 6334,0,TM
STATE				: GRANTED
OWNER_NODE			: 2
--------------
INST_ID				: 1
HANDLE				: 000000008D256E60
GRANT_LEVEL			: KJUSERCW
REQUEST_LEVEL			: KJUSERCW
RESOURCE_NAME1			: [0x18be][0x0],[TM][ext 0x0,0x0
RESOURCE_NAME2			: 6334,0,TM
STATE				: GRANTED
OWNER_NODE			: 1
--------------

-- 리소스 유형이 다르면 약간은 다르게 동작할 수 있음 (특히 버퍼캐시, 아래 예는 히스토그램과 관련된 딕셔너리 캐시 유형)
-- GRANT_LEVEL : KJUSERPR (protected read, v$lock 의 모드 4), INST_ID = 2 가 이 리소스의 마스터, INST_ID IN (1, 3) 은 SHADOW
SELECT INST_ID, OWNER_NODE, GRANT_LEVEL, RESOURCE_NAME1
  FROM GV$GES_ENQUEUE
 WHERE RESOURCE_NAME1 LIKE '%[0xf13e8525][0xa660035f],[QQ]%'
 ORDER BY INST_ID, OWNER_NODE;

  INST_ID OWNER_NODE GRANT_LEV RESOURCE_NAME1
--------- ---------- --------- -------------------------
        1          0 KJUSERPR  [0xf13e8525][0xa660035f],[QQ][
        2          0 KJUSERPR  [0xf13e8525][0xa660035f],[QQ][
                   1 KJUSERPR  [0xf13e8525][0xa660035f],[QQ][
                   2 KJUSERPR  [0xf13e8525][0xa660035f],[QQ][
        3          2 KJUSERPR  [0xf13e8525][0xa660035f],[QQ][

3노드 클러스터에 대한 master 와 shadow 의 관계

리소스 유형 별 정보

-- 3 노드 클러스터의 한 노드에서 인스턴스가 기동된 후 몇 분 후에 수행
SQL> select -- resource
       substr(resource_name, instr(resource_name, ',')+2, 2), count(*)
  from v$dlm_ress
 group by substr(resource_name, instr(resource_name, ',')+2, 2)
 order by count(*);

SUBSTR(R COUNT(*)
-------- --------
...
TM            558
QC           1061	-- dictionary cache, segments
BL           2802
QQ           3899	-- dictionary cache, histograms
QI           3959	-- dictionary cache, objects

SQL> select -- enqueues
       substr(resource_name2, -2), grant_level, request_level, count(*)
  from v$ges_enqueue
 group by substr(resource_name2, -2), grant_level, request_level
 order by count(*);

 SUBSTR(R GRANT_LEV REQUEST_L   COUNT(*)
 -------- --------- --------- ----------
 ...
 QC       KJUSERPR  KJUSERPR       1060
 BL       KJUSEREX  KJUSERNL       2552
 BL       KJUSERPR  KJUSERNL       3891
 QI       KJUSERPR  KJUSERPR       4888
 QQ       KJUSERPR  KJUSERPR       6140

-- 다수의 파티션을 가진 파티션 테이블이 존재하고 히스토그램이 많은 경우 딕셔너리 캐시를 의미하는 Qx 리소스가 많아짐
-- 블록을 관리하는 BL 유형이 Qx 유형 보다 적으나 데이터베이스가 운영 되면서 증가 하게 됨

-- BL 리소스는 하나의 블록을 관리 (예외: GLOBAL TEMPORARY TABLE, READ-ONLY TABLESPACE)
-- 블록이 인스턴스 중 하나의 버퍼캐시에 적재되면 관련된 BL 리소스가 존재 하게 됨
-- 이론상 마스터 BL 리소스 수 = 전 시스템의 버퍼 수, 실제로 마스터 BL 리소스 수 < 전 시스템의 버퍼 수 (하나의 블록에 대한 여러 개의 복사본을 가지고 있으므로)

4노드 클러스터 내의 3-way 블록 전송 / 처리순서

4노드 클러스터 내의 3-way 블록 전송 / 처리결과

2-WAY / 3-WAY 동작 테스트

Event					 Waits	Time_outs		 Csec		Avg Csec	 Max Csec
-----					 -----	---------		 ----		--------		-----
gc cr block 2-way			98			0			4			.043			0
gc current block 2-way			98			0			4			.044			0

gc cr block 2-way			49			0			2			.036			2
gc cr block 3-way			47			0			3			.063			0
gc current block 2-way			48			0			2			.033			0
gc current block 3-way			46			0			2			.053			0

gc cr block 2-way			50			0			2			.049			0
gc cr block 3-way			47			0			3			.064			1
gc current block 2-way			50			0			2			.035			0
gc current block 3-way			46			0			2			.051			5

블록들의 상태 확인

SQL> select state, count(*) from x$bh group by state;

-- 가장 흔히 볼 수 있는 상태는 0-free, 1-XCUR, 2-SCUR, 3-CR, 8-PI 임