[캐시 퓨전 #1] SELECT 시에 발생하는 gc cr grant 2-way 대기이벤트에 대한 이해

이번 시간에 살펴볼 내용은 캐시 퓨전 시에 발생하는 클러스터 관련 대기이벤트들 및 이와 연관된 성능 지표들의 변경사항, 그리고 버퍼 캐시 내의 버퍼 상태 및 GRD의 변경 사항들입니다. 테스트를 위해 10046 트레이스, V$SESSTAT, X$BH, X$KJBL Fixed 테이블을 이용했습니다. 연재 순서는 다음과 같습니다.

테스트 환경 : Oracle 12.1.0.2 (64bits) 3 노드 RAC

1. 테스트 개요


2번 노드에서 레코드 1건 (마스터노드: 3번)을 조회한 후에 1번 및 3번 노드에서 동일 레코드를 각각 조회합니다. 테스트의 편의성을 위해 인덱스를 생성하지 않고 해당 레코드의 ROWID를 이용해서 조회하며, 조회 시에 발생하는 대기이벤트와 성능지표를 살펴보고 버퍼 캐시 및 GRD의 변경 내용을 확인합니다.

2. 초기 환경 SETUP


-- 테스트 테이블 생성 및 데이터 입력
 
SCOTT@OOW1:1> drop table t1 purge;
SCOTT@OOW1:1> create table t1 (c1 number, c2 number);
SCOTT@OOW1:1> insert into t1 select level, level from dual connect by level<=10000;
SCOTT@OOW1:1> commit;
SCOTT@OOW1:1> exec dbms_stats.gather_table_stats(user,'T1');
 
--C1=1에 대한 블록 마스터 노드가 OOW3 (KJBRMASTER=2)임을 확인
 
SCOTT@OOW1:1> @fnd_blk_master T1 1
 
        C1     OBJ_NO    FILE_NO     BLK_NO
---------- ---------- ---------- ----------
         1      93823          6        228
 
       X$BH X$KJBR                                                       X$KJBR
INST  CLASS NAME                           KJBLNAME2       KJBRGRANT     MASTER
---- ------ ------------------------------ --------------- --------- ----------
OOW3      1 [0xe4][0x6],[BL][ext 0x0,0x0]  228,6,BL        KJUSEREX           2
 
-- 모든 노드에서 buffer cache flush 수행 
 
SYS@OOW1:1> alter system flush buffer_cache;
SYS@OOW2:2> alter system flush buffer_cache;
SYS@OOW3:3> alter system flush buffer_cache;


3. 2번 노드에서 1건 조회


2번 노드에서 1건을 조회하면 해당 블록에 대한 SCUR 버퍼가 버퍼 캐시에 적재됩니다. (그림-1 참조) 이때 발생하는 변경 사항은 아래의 테스트 결과 중간중간에 주석으로 설명해 두었습니다.

그림-1. 2번 노드에서 1건 조회 후의 버퍼 캐시 변경 내용

21-1

-- 해당 블록은 로컬 및 리모트 버퍼 캐시에 존재하지 않으므로 3번 노드의 LMS로부터 블록 액세스 권한을 부여 받습니다. 
-- 이로 인해 'gc cr grant 2-way' 대기이벤트가 1회 발생합니다. 
-- 그런 후에, 싱글 블록 IO를 이용해서 해당 블록(File#=6, Block#=228)을 메모리로 적재합니다. 
-- 이때 'db file sequential read' 대기이벤트가 1회 발생합니다.
  
SCOTT@OOW2:2> @set_trace_on 10046 8
SCOTT@OOW2:2> @one_row_select 
 
WAIT #140225505500112: nam='gc cr grant 2-way' ela= 1991 p1=6 p2=228 p3=1 obj#=93696 tim=282496042645
WAIT #140225505500112: nam='db file sequential read' ela= 4141 file#=6 block#=228 blocks=1 obj#=93696 tim=282496046954
 
-- 10046 트레이스에서 확인한 것과 동일한 대기이벤트 정보를 확인할 수 있습니다. 
-- 더불어 DISK IO 1회, 메모리 IO 1회가 발생한 것을 알 수 있습니다.
 
SYS@OOW1:1> @init_temp_sesstat 91 65 43
SYS@OOW1:1> @get_temp_sesstat  91 65 43
 
INST_ID SERVER FLAG     NAME                           VALUE
------- ------ -------- ------------------------------ -----
      2 [FG]   [EVENT]  db file sequential read            1
                        gc cr grant 2-way                  1
               [STAT]   physical reads                     1
                        session logical reads              1
 
-- 2번 노드에 SCUR 버퍼가 1개 적재되었습니다. 
-- 그리고 2번 노드의 GRD에 GCS 클라이언트 (락 엘리먼트 존재)가 1개 생성되고 
-- 마스터 노드인 3번 노드에 GCS SHADOW가 1개 생성되었습니다. 
                 
SYS@OOW1:1> @fnd_gcs_detail2 6 228
 
                        X$BH X$BH   X$BH                   X$BH
INST ADDR              CLASS STATE  LE_ADDR                 TCH BA
---- ---------------- ------ ------ ---------------- ---------- ----------------
OOW2 00007F79DD4F7A60      1 SCUR   00000000733E2EB0          1 00000000738EC000
 
     X$KJBL           X$KJBL X$KJBL    X$KJBL     X$BH               X$BH X$BH
INST LOCKP             OWNER GRANT     LOCKST     LE_ADDR           CLASS STATE
---- ---------------- ------ --------- ---------- ---------------- ------ ------
OOW2 00000000733E2F38      1 KJUSERPR  GRANTED    00000000733E2EB0      1 SCUR
OOW3 00000000696EB438      1 KJUSERPR  GRANTED


4. 2번 노드에서 1번 더 조회


2번 노드에서 동일한 레코드를 1번 더 조회할 경우에는 로컬 캐시에서 해당 블록을 읽게 됩니다. 따라서 클러스터 및 IO 관련 대기이벤트 및 GRD 내의 변경은 발생하지 않습니다. 로컬 캐시에서 원하는 블록을 읽었으므로 메모리 IO가 1회 증가하고 해당 버퍼의 TCH가 2로 증가하는 정도의 변경만 발생합니다.

-- 클러스터 및 IO 관련 대기이벤트는 발생하지 않습니다.
 
SCOTT@OOW2:2> @set_trace_on 10046 8
SCOTT@OOW2:2> @one_row_select 
 
-- 해당 버퍼에 대한 메모리 IO가 1회 발생합니다. 
 
SYS@OOW1:1> @init_temp_sesstat 91 65 43
SYS@OOW1:1> @get_temp_sesstat  91 65 43
 
INST_ID SERVER FLAG     NAME                           VALUE
------- ------ -------- ------------------------------ -----
      2 [FG]   [STAT]   session logical reads              1
 
-- 해당 버퍼에 대한 액세스로 인해 TCH가 2로 증가합니다.
       
SYS@OOW1:1> @fnd_gcs_detail 6 228
 
                        X$BH X$BH   X$BH                   X$BH
INST ADDR              CLASS STATE  LE_ADDR                 TCH BA
---- ---------------- ------ ------ ---------------- ---------- ----------------
OOW2 00007F79DD4FAC58      1 SCUR   00000000733E2EB0          2 0000000073922000
 
     X$KJBL           X$KJBL X$KJBL    X$KJBL     X$BH               X$BH X$BH
INST LOCKP             OWNER GRANT     LOCKST     LE_ADDR           CLASS STATE
---- ---------------- ------ --------- ---------- ---------------- ------ ------
OOW2 00000000733E2F38      1 KJUSERPR  GRANTED    00000000733E2EB0      1 SCUR
OOW3 00000000696D44B8      1 KJUSERPR  GRANTED


5. 1번 노드에서 조회


1번 노드에서 동일한 레코드를 조회하면 해당 블록에 대한 SCUR 버퍼가 버퍼 캐시에 적재됩니다. (그림-2 참조) 캐시 퓨전을 설명한 문서들을 보면 이러한 경우에는 해당 블록은 캐시 퓨전을 통해서 리모트 캐시(2번 노드)에서 전송 받고, 이로 인해 ‘gc current block 2/3 way’ 대기이벤트가 발생하는 것으로 되어있습니다만, 테스트 결과는 조금 다릅니다. 이러한 차이는 테스트 환경 (버전 또는 buffer cache flush 여부 등)의 차이라고 보여집니다.

그림-2. 1번 노드에서 1건 조회 후의 버퍼 캐시 변경 내용

21-2

-- 2번 노드와 동일한 결과를 나타냅니다. 
 
SCOTT@OOW1:1> @set_trace_on 10046 8
SCOTT@OOW1:1> @one_row_select 
 
WAIT #139902827437888: nam='gc cr grant 2-way' ela= 4187 p1=6 p2=228 p3=1 obj#=93696 tim=309078519225
WAIT #139902827437888: nam='db file sequential read' ela= 6589 file#=6 block#=228 blocks=1 obj#=93696 tim=309078528563
 
-- V$SESSTAT 뷰의 변경 사항 (참고만 하세요) 
 
SYS@OOW1:1> @init_temp_sesstat 91 65 43
SYS@OOW1:1> @get_temp_sesstat  91 65 43
 
INST_ID SERVER FLAG     NAME                           VALUE
------- ------ -------- ------------------------------ -----
      1 [FG]   [EVENT]  db file sequential read            1
                        gc cr grant 2-way                  1
               [STAT]   physical reads                     1
                        session logical reads              1
 
-- 1번 노드에 SCUR 버퍼가 1개 적재되었습니다. 
-- 그리고 2번 노드의 GRD에 GCS 클라이언트가 1개 생성되고, 
-- 마스터 노드인 3번 노드에 GCS SHADOW가 1개 생성되었습니다.
                         
SYS@OOW1:1> @fnd_gcs_detail2 6 228
 
                        X$BH X$BH   X$BH                   X$BH
INST ADDR              CLASS STATE  LE_ADDR                 TCH BA
---- ---------------- ------ ------ ---------------- ---------- ----------------
OOW1 00007F80726712D0      1 SCUR   00000000747F19D8          1 00000000750EE000
OOW2 00007F79E2242F58      1 SCUR   00000000733E2EB0          0 0000000074940000
 
     X$KJBL           X$KJBL X$KJBL    X$KJBL     X$BH               X$BH X$BH
INST LOCKP             OWNER GRANT     LOCKST     LE_ADDR           CLASS STATE
---- ---------------- ------ --------- ---------- ---------------- ------ ------
OOW1 00000000747F1A60      0 KJUSERPR  GRANTED    00000000747F19D8      1 SCUR
OOW2 00000000733E2F38      1 KJUSERPR  GRANTED    00000000733E2EB0      1 SCUR
OOW3 00000000697216F0      1 KJUSERPR  GRANTED
OOW3 00000000696CDD20      0 KJUSERPR  GRANTED


6. 3번 노드에서 조회


3번 노드에서 동일한 레코드를 조회하면 해당 블록에 대한 SCUR 버퍼가 버퍼 캐시에 적재됩니다. (그림-3 참조)

그림-3. 3번 노드에서 1건 조회 후의 버퍼 캐시 변경 내용

21-3

-- 3번 노드가 마스터 노드이므로 GRANT 수행 없이 싱글 블록 IO를 이용해서 버퍼에 적재합니다.
-- 따라서 'gc cr grant 2-way' 대기 없이 'db file sequential' 대기이벤트만 1회 발생합니다.
 
SCOTT@OOW3:3> @set_trace_on 10046 8
SCOTT@OOW3:3> @one_row_select 
 
WAIT #140357040867896: nam='db file sequential read' ela= 4382 file#=6 block#=228 blocks=1 obj#=93696 tim=282758433936
 
-- V$SESSTAT 뷰의 변경 사항 (참고만 하세요) 
 
SYS@OOW1:1> @init_temp_sesstat 91 65 43
SYS@OOW1:1> @get_temp_sesstat  91 65 43
 
INST_ID SERVER FLAG     NAME                           VALUE
------- ------ -------- ------------------------------ -----
      3 [FG]   [EVENT]  db file sequential read            1
               [STAT]   physical reads                     1
                        session logical reads              1                        
 
-- 3번 노드에 SCUR 버퍼가 1개 적재되었습니다. 
-- 3번 노드가 마스터 노드이므로 GCS SHADOW는 생성되지 않고 GCS 클라이언트만 1개 생성되었습니다. 
                         
SYS@OOW1:1> @fnd_gcs_detail2 6 228
 
                        X$BH X$BH   X$BH                   X$BH
INST ADDR              CLASS STATE  LE_ADDR                 TCH BA
---- ---------------- ------ ------ ---------------- ---------- ----------------
OOW1 00007F8072671870      1 SCUR   00000000747F19D8          1 0000000075744000
OOW2 00007F79DD4C9298      1 SCUR   00000000733E2EB0          1 0000000073418000
OOW3 00007FBB31F831B0      1 SCUR   00000000757DC498          1 0000000072E32000
 
     X$KJBL           X$KJBL X$KJBL    X$KJBL     X$BH               X$BH X$BH
INST LOCKP             OWNER GRANT     LOCKST     LE_ADDR           CLASS STATE
---- ---------------- ------ --------- ---------- ---------------- ------ ------
OOW1 00000000747F1A60      0 KJUSERPR  GRANTED    00000000747F19D8      1 SCUR
OOW2 00000000733E2F38      1 KJUSERPR  GRANTED    00000000733E2EB0      1 SCUR
OOW3 0000000069715DC8      1 KJUSERPR  GRANTED
OOW3 00000000697273C0      0 KJUSERPR  GRANTED
OOW3 00000000757DC520      2 KJUSERPR  GRANTED    00000000757DC498      1 SCUR



다음: [캐시 퓨전 #2] 변경중인 블록 SELECT 시에 발생하는 gc cr block busy 대기이벤트 및 _db_block_max_cr_dba 파라미터에 대한 이해

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s