[캐시 퓨전 #3] 커밋된 블록 SELECT 시에 발생하는 gc cr/current block 2-way, 3-way 대기이벤트 및 _fairness_threshold 파라미터에 대한 이해

1. 테스트 개요


2번 노드에서 레코드 1건 (마스터 노드: 3번)을 변경한 후에 커밋을 수행합니다. 그런 후에 동일 레코드를 1번 및 3번 노드에서 반복적으로 조회합니다. 이를 통해, 커밋된 블록을 조회할 떄 발생하는 gc cr block 2-way, gc cr block 3-way, gc current block 2-way, gc current block 3-way 대기이벤트 및 _fairness_threshold 파라미터의 동작원리를 파악하도록 합니다.

2. 2번 노드에서 1건 UPDATE 및 COMMIT 수행


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

그림-1. 2번 노드에서 1건 UPDATE 및 COMMIT 수행 후의 변경 내용

23-1

-- 해당 블록은 로컬 및 리모트 캐시에 존재하지 않으므로 3번 노드의 LMS로부터 블록 액세스 권한을 부여 받습니다.
-- 이로 인해 'gc cr grant 2-way' 대기이벤트가 1회 발생합니다. 

-- 그런 후에, 싱글 블록 IO를 이용해서 해당 블록(File#=6, Block#=228)을 메모리로 적재합니다.
-- 이때 'db file sequential read' 대기이벤트가 1회 발생합니다.

-- 해당 블록을 적재한 후에는 해당 블록을 변경하기 위한 CURRENT 권하는 부여 받아야합니다.
-- 이로 인해 'gc current grant 2-way' 대기이벤트가 1회 발생합니다.

-- 또한, 변경 작업을 위한 언두 블록을 할당 받기 위해 'db file sequential read' 대기이벤트가 2회 발생합니다.
-- 블록 덤프를 수행해보면 각각 언두 헤더 블록과 언두 블록임을 알 수 있습니다. 

-- 마지막으로 커밋 수행에 따른 'log file sync' 대기이벤트가 1회 발생합니다. 

SCOTT@OOW2:2> @set_trace_on 10046 8
SCOTT@OOW2:2> @one_row_update
SCOTT@OOW2:2> commit; 

WAIT #140225502726824: nam='gc cr grant 2-way' ela= 2572 p1=6 p2=228 p3=1 obj#=93823 tim=291817361860
WAIT #140225502726824: nam='db file sequential read' ela= 5763 file#=6 block#=228 blocks=1 obj#=93823 tim=291817368044
WAIT #140225502726824: nam='gc current grant 2-way' ela= 4572 p1=6 p2=228 p3=33619969 obj#=93823 tim=291817374295
WAIT #140225502726824: nam='db file sequential read' ela= 1795 file#=5 block#=160 blocks=1 obj#=0 tim=291817376480
WAIT #140225502726824: nam='db file sequential read' ela= 2058 file#=5 block#=8099 blocks=1 obj#=0 tim=291817379029
WAIT #140225505518032: nam='log file sync' ela= 2549 buffer#=631 sync scn=12103377 p3=0 obj#=0 tim=291881847246

SYS@OOW2:2> alter system dump datafile 5 block 160;
frmt: 0x02 chkval: 0xbae3 type: 0x26=KTU SMU HEADER BLOCK

SYS@OOW2:2> alter system dump datafile 5 block 8099;
frmt: 0x02 chkval: 0xfdae type: 0x02=KTU UNDO BLOCK  '

-- 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
------- ------ -------- ------------------------------ -----
      2 [FG]   [EVENT]  db file sequential read            3
                        gc cr grant 2-way                  1
                        gc current grant 2-way             1
               [STAT]   physical reads                     3
                        session logical reads              8

-- 2번 노드에 XCUR 버퍼 1개와 CR 버퍼 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 00007F79DD6859A8      1 CR     00                        0 0000000073474000
     00007F79DD685B28      1 XCUR   00000000737F7900          2 0000000074AFC000

     X$KJBL           X$KJBL X$KJBL    X$KJBL     X$BH               X$BH X$BH
INST LOCKP             OWNER GRANT     LOCKST     LE_ADDR           CLASS STATE
---- ---------------- ------ --------- ---------- ---------------- ------ ------
OOW2 00000000737F7988      1 KJUSEREX  GRANTED    00000000737F7900      1 XCUR
OOW3 0000000069716EA8      1 KJUSEREX  GRANTED

 

3. 1번 노드에서 해당 레코드 조회 (1회 수행)


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

그림-2. 1번 노드에서 해당 레코드 1회 조회한 후의 버퍼 캐시 변경 내용

23-2

-- 해당 블록의 마스터 노드는 3번 노드이고 현재 2번 노드에 존재합니다.
-- 따라서 'gc cr block 3-way' 대기이벤트가 1회 발생합니다. 

SCOTT@OOW1:1> @set_trace_on 10046 8
SCOTT@OOW1:1> @one_row_select 

WAIT #139902907847544: nam='gc cr block 3-way' ela= 3504 p1=6 p2=228 p3=1 obj#=93823 tim=318327265441

-- 1번 노드의 Foreground 프로세스는 CR 버퍼를 1개 전송 받았음을 알 수 있습니다.
-- 2번 노드의 LMS는 CR 버퍼를 1번 노드로 전송한 것을 알 수 있습니다.
-- 이때, 연재#2의 경우와 달리 LMS는 CR 버퍼를 생성하지 않습니다. 

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]  gc cr block 3-way                  1
               [STAT]   gc cr blocks received              1
                        session logical reads              1
      2 [LMS]  [STAT]   gc cr blocks served                1
                        session logical reads              1

-- 1번 노드에 CR 버퍼가 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 00007F8072A9E478      1 CR     00                        1 00000000738D0000

OOW2 00007F79E2243540      1 CR     00                        0 000000007490C000
     00007F79E22436C0      1 XCUR   00000000737F7900          2 000000007396E000

     X$KJBL           X$KJBL X$KJBL    X$KJBL     X$BH               X$BH X$BH
INST LOCKP             OWNER GRANT     LOCKST     LE_ADDR           CLASS STATE
---- ---------------- ------ --------- ---------- ---------------- ------ ------
OOW2 00000000737F7988      1 KJUSEREX  GRANTED    00000000737F7900      1 XCUR
OOW3 000000006971F698      1 KJUSEREX  GRANTED

 

4. 1번 노드에서 해당 레코드 조회 (2회 수행)


1번 노드에서 동일한 레코드를 한번 더 조회하면 1번 노드의 버퍼 캐시에는 CR 버퍼가 1개 적재됩니다. 그리고 2번 노드의 버퍼 상태가 XCUR에서 SCUR로 변경됩니다. (그림-3 참조) 2번 노드의 버퍼 상태가 SCUR로 변경되는 것은 _fairness_threshold 파라미터와 관련이 있습니다. 해당 파라미터의 설정 값은 버전에 따라 다르고 제 환경에서는 2입니다. 따라서 변경이 끝난 XCUR 버퍼를 2번 액세스하면 버퍼의 상태가 SCUR로 변경됩니다.

그림-3. 1번 노드에서 해당 레코드 2회 조회한 후의 버퍼 캐시 변경 내용

23-3

-- 1회 조회 시와 동일하게 'gc cr block 3-way' 대기이벤트가 1회 발생합니다.

SCOTT@OOW1:1> @set_trace_on 10046 8
SCOTT@OOW1:1> @one_row_select 

WAIT #139902907847544: nam='gc cr block 3-way' ela= 3470 p1=6 p2=228 p3=1 obj#=93823 tim=319239338492

-- 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
------- ------ -------- ------------------------------ -----
      1 [FG]   [EVENT]  gc cr block 3-way                  1
               [STAT]   gc cr blocks received              1
                        session logical reads              1
      2 [LMS]  [STAT]   gc cr blocks served                1
                        session logical reads              1

-- 1번 노드에 CR 버퍼 1개가 적재되었습니다.
-- 그리고 2번 노드의 버퍼 상태가 XCUR에 SCUR로 변경되었습니다. 

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 00007F8072A485F8      1 CR     00                        1 00000000738D0000
     00007F8072A48778      1 CR     00                        1 000000007382C000

OOW2 00007F79E22436C0      1 CR     00                        0 000000007490C000
     00007F79E2243840      1 SCUR   00000000737F7900          2 000000007396E000

     X$KJBL           X$KJBL X$KJBL    X$KJBL     X$BH               X$BH X$BH
INST LOCKP             OWNER GRANT     LOCKST     LE_ADDR           CLASS STATE
---- ---------------- ------ --------- ---------- ---------------- ------ ------
OOW2 00000000737F7988      1 KJUSERPR  GRANTED    00000000737F7900      1 SCUR
OOW3 000000006971F698      1 KJUSERPR  GRANTED

 

5. 1번 노드에서 해당 레코드 조회 (3회 수행)


1번 노드에서 동일한 레코드를 한번 더 조회하면 1번 노드의 버퍼 캐시에는 SCUR 버퍼가 1개 적재됩니다. (그림-4 참조)

그림-4. 1번 노드에서 해당 레코드 3회 조회한 후의 버퍼 캐시 변경 내용

23-4

-- SCUR 버퍼가 적재되므로 'gc cr block 3-way'가 아닌 'gc current block 3-way' 대기이벤트가 1회 발생합니다. 

SCOTT@OOW1:1> @set_trace_on 10046 8
SCOTT@OOW1:1> @one_row_select 

WAIT #139902907847544: nam='gc current block 3-way' ela= 3935 p1=6 p2=228 p3=1 obj#=93823 tim=319277179034

-- 1번 노드의 Foreground 프로세스는 CURRENT 버퍼를 1개 전송 받았음을 알 수 있습니다.
-- 2번 노드의 LMS는 CURRENT 버퍼를 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
------- ------ -------- ------------------------------ -----
      1 [FG]   [EVENT]  gc current block 3-way             1
               [STAT]   gc current blocks received         1
                        session logical reads              1
      2 [LMS]  [STAT]   gc current blocks served           1

-- 1번 노드에 SCUR 버퍼 1개가 적재되었습니다.
-- 그리고 1번 노드의 GRD에 GCS 클라이언트가 1개 생성되고,
-- 마스터 노드인 3번 노드의 GRD에 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 00007F807277ED78      1 CR     00                        1 00000000738D0000
     00007F807277EEF8      1 CR     00                        1 000000007382C000
     00007F807277F078      1 SCUR   00000000743ECD48          1 0000000073C74000

OOW2 00007F79E22436C0      1 CR     00                        0 000000007490C000
     00007F79E2243840      1 SCUR   00000000737F7900          2 000000007396E000

     X$KJBL           X$KJBL X$KJBL    X$KJBL     X$BH               X$BH X$BH
INST LOCKP             OWNER GRANT     LOCKST     LE_ADDR           CLASS STATE
---- ---------------- ------ --------- ---------- ---------------- ------ ------
OOW1 00000000743ECDD0      0 KJUSERPR  GRANTED    00000000743ECD48      1 SCUR
OOW2 00000000737F7988      1 KJUSERPR  GRANTED    00000000737F7900      1 SCUR
OOW3 0000000069722410      0 KJUSERPR  GRANTED
OOW3 000000006971F698      1 KJUSERPR  GRANTED

 

6. 1번 노드에서 해당 레코드 조회 (4회 수행)


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

-- 클러스터 및 IO 관련 대기이벤트는 발생하지 않습니다.

SCOTT@OOW1:1> @set_trace_on 10046 8
SCOTT@OOW1:1> @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
------- ------ -------- ------------------------------ -----
      1 [FG]   [STAT]   session logical reads              1

-- SCUR 버퍼에 대한 액세스로 인해 TCH가 2로 증가합니다.

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 00007F807277ED78      1 CR     00                        1 00000000738D0000
     00007F807277EEF8      1 CR     00                        1 000000007382C000
     00007F807277F078      1 SCUR   00000000743ECD48          2 0000000073C74000

OOW2 00007F79E22436C0      1 CR     00                        0 000000007490C000
     00007F79E2243840      1 SCUR   00000000737F7900          2 000000007396E000

     X$KJBL           X$KJBL X$KJBL    X$KJBL     X$BH               X$BH X$BH
INST LOCKP             OWNER GRANT     LOCKST     LE_ADDR           CLASS STATE
---- ---------------- ------ --------- ---------- ---------------- ------ ------
OOW1 00000000743ECDD0      0 KJUSERPR  GRANTED    00000000743ECD48      1 SCUR
OOW2 00000000737F7988      1 KJUSERPR  GRANTED    00000000737F7900      1 SCUR
OOW3 0000000069722410      0 KJUSERPR  GRANTED
OOW3 000000006971F698      1 KJUSERPR  GRANTED

 

7. 3번 노드에서 해당 레코드 1회 조회


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

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

23-5

-- 3번 노드가 마스터 노드이고 CUURENT 블록을 전송 받으므로
-- 'gc current block 2-way' 대기이벤트가 1회 발생합니다.

SCOTT@OOW3:3> @set_trace_on 10046 8
SCOTT@OOW3:3> @one_row_select 

WAIT #140357041936560: nam='gc current block 2-way' ela= 3478 p1=6 p2=228 p3=1 obj#=93973 tim=384133917366

-- 2번 노드의 LMS는 CURRENT 버퍼를 3번 노드로 전송한 것을 알 수 있습니다.
-- 3번 노드의 Foreground 프로세스는 CURRENT 버퍼를 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 [LMS]  [STAT]   gc current blocks served           1
      3 [FG]   [EVENT]  gc current block 2-way             1
               [STAT]   gc current blocks received         1
                        session logical reads              1

-- 3번 노드에 SCUR 버퍼 1개가 적재되었습니다.
-- 그리고 3번 노드의 GRD에 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 00007F8072A48030      1 CR     00                        1 0000000074090000
     00007F8072A481B0      1 CR     00                        1 0000000074AEE000
     00007F8072A48330      1 SCUR   0000000074BE0868          2 0000000074752000

OOW2 00007F79DD4C9BE0      1 CR     00                        0 0000000073D54000
     00007F79DD4C9D60      1 SCUR   00000000737F7900          2 0000000072E8E000

OOW3 00007FBB31F8A7D8      1 SCUR   00000000743E5B88          1 0000000073E70000

     X$KJBL           X$KJBL X$KJBL    X$KJBL     X$BH               X$BH X$BH
INST LOCKP             OWNER GRANT     LOCKST     LE_ADDR           CLASS STATE
---- ---------------- ------ --------- ---------- ---------------- ------ ------
OOW1 0000000074BE08F0      0 KJUSERPR  GRANTED    0000000074BE0868      1 SCUR
OOW2 00000000737F7988      1 KJUSERPR  GRANTED    00000000737F7900      1 SCUR
OOW3 00000000696D0390      0 KJUSERPR  GRANTED
OOW3 000000006972A570      1 KJUSERPR  GRANTED
OOW3 00000000743E5C10      2 KJUSERPR  GRANTED    00000000743E5B88      1 SCUR

 

8. 3번 노드에서 해당 레코드 조회 2회 조회


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

-- 클러스터 및 IO 관련 대기이벤트는 발생하지 않습니다.

SCOTT@OOW3:3> @set_trace_on 10046 8
SCOTT@OOW3:3> @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
------- ------ -------- ------------------------------ -----
      3 [FG]   [STAT]   session logical reads              1

-- SCUR 버퍼에 대한 액세스로 인해 TCH가 2로 증가합니다.

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 00007F807277E4E8      1 CR     00                        1 0000000074090000
     00007F807277E668      1 CR     00                        1 0000000074AEE000
     00007F807277E7E8      1 SCUR   0000000074BE0868          2 0000000074752000

OOW2 00007F79DD4C9BE0      1 CR     00                        0 0000000073D54000
     00007F79DD4C9D60      1 SCUR   00000000737F7900          2 0000000072E8E000

OOW3 00007FBB31F8AAD8      1 SCUR   00000000743E5B88          2 0000000073E70000

     X$KJBL           X$KJBL X$KJBL    X$KJBL     X$BH               X$BH X$BH
INST LOCKP             OWNER GRANT     LOCKST     LE_ADDR           CLASS STATE
---- ---------------- ------ --------- ---------- ---------------- ------ ------
OOW1 0000000074BE08F0      0 KJUSERPR  GRANTED    0000000074BE0868      1 SCUR
OOW2 00000000737F7988      1 KJUSERPR  GRANTED    00000000737F7900      1 SCUR
OOW3 00000000696D0390      0 KJUSERPR  GRANTED
OOW3 000000006972A570      1 KJUSERPR  GRANTED
OOW3 00000000743E5C10      2 KJUSERPR  GRANTED    00000000743E5B88      1 SCUR

 

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

다음: [캐시 퓨전 #4] 변경된 블록 UPDATE 시에 발생하는 gc cr block busy, gc cr/current block 2-way, 3way 대기이벤트에 대한 이해

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