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

1. 테스트 개요


2번 노드에서 레코드 1건 (마스터 노드: 3번)을 변경한 후에 1번 및 3번 노드에서 동일 레코드를 각각 7번 조회합니다. 이를 통해 변경 중인 블록을 조회할 때 발생하는 대기이벤트와 성능 지표를 살펴보고 버퍼 캐시 및 GRD의 변경 내용을 확인합니다. 그리고 _db_block_max_cr_dba 파라미터의 동작원리 또한 파악하도록 합니다.

2. 2번 노드에서 1건 UPDATE


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

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

22-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회 발생합니다.
-- 블록 덤프를 수행해보면 각각 언두 헤더 블록과 언두 블록임을 알 수 있습니다. 

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

WAIT #140225505518032: nam='gc cr grant 2-way' ela= 1913 p1=6 p2=228 p3=1 obj#=93823 tim=294714258816
WAIT #140225505518032: nam='db file sequential read' ela= 1918 file#=6 block#=228 blocks=1 obj#=93823 tim=294714261240
WAIT #140225505518032: nam='gc current grant 2-way' ela= 2213 p1=6 p2=228 p3=33619969 obj#=93823 tim=294714263898
WAIT #140225505518032: nam='db file sequential read' ela= 2029 file#=5 block#=144 blocks=1 obj#=0 tim=294714268613
WAIT #140225505518032: nam='db file sequential read' ela= 1150 file#=5 block#=1796 blocks=1 obj#=0 tim=294714270377

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

SYS@OOW2:2> alter system dump datafile 5 block 1796;
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              4

-- 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 00007F79DD4C4F08      1 CR     00                        0 00000000734C2000
     00007F79DD4C5088      1 XCUR   00000000733E2EB0          2 000000007513A000

     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 KJUSEREX  GRANTED    00000000733E2EB0      1 XCUR
OOW3 00000000696D70C8      1 KJUSEREX  GRANTED

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


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

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

22-2

-- 해당 블록은 현재 변경 전 (COMMIT 전이므로 'busy'상태)입니다.
-- 따라서 'gc cr block busy' 대기이벤트가 1회 발생합니다. 

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

WAIT #139902907847544: nam='gc cr block busy' ela= 18363 p1=6 p2=228 p3=1 obj#=93823 tim=311836140232

SYS@OOW1:1> @init_temp_sesstat 91 65 43
SYS@OOW1:1> @get_temp_sesstat  91 65 43

-- 1번 노드의 Foreground 프로세스는 CR 버퍼를 1개 전송 받았음을 알 수 있습니다.
-- 2번 노드의 LMS는 CR 버퍼를 1개 생성한 후에 1번 노드로 해당 버퍼를 전송한 것을 알 수 있습니다. 

INST_ID SERVER FLAG     NAME                           VALUE
------- ------ -------- ------------------------------ -----
      1 [FG]   [EVENT]  gc cr block busy                   1
               [STAT]   gc cr blocks received              1
                        session logical reads              1
      2 [LMS]  [STAT]   CR blocks created                  1
                        gc cr blocks flushed               1
                        gc cr blocks served                1
                        session logical reads              3

-- 1번 노드와 2번 노드에 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 00007F8072037AC8      1 CR     00                        1 0000000074298000

OOW2 00007F79DD69C000      1 CR     00                        0 00000000734C2000
     00007F79DD69C180      1 XCUR   00000000733E2EB0          2 000000007513A000
     00007F79DD69C300      1 CR     00                        0 000000007545E000

     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 KJUSEREX  GRANTED    00000000733E2EB0      1 XCUR
OOW3 00000000696D70C8      1 KJUSEREX  GRANTED

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


해당 레코드를 6회 반복해서 조회하면 1, 2번 모두 6개의 CR 버퍼가 적재됩니다. (그림-3 참조) 즉, ‘busy’한 블록을 반복적으로 조회하면 조회할 때마다 CR 버퍼가 적재되고, 최대 값은 _db_block_max_cr_dba 파라미터에 의해 결정됩니다. 해당 파라미터의 기본 설정 값은 6이므로 최대 6개의 CR 버퍼가 적재된 것을 알 수 있습니다.

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

22-3

-- 해당 블록은 현재 변경 전 (COMMIT 전이므로 'busy'상태)입니다.
-- 따라서 'gc cr block busy' 대기이벤트가 1회 발생합니다. 

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

WAIT #139902907847544: nam='gc cr block busy' ela= 4052 p1=6 p2=228 p3=1 obj#=93823 tim=311885751211

-- 이전과 동일하게 2번 노드의 LMS는 CR 버퍼를 1개 생성한 후 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 busy                   1
               [STAT]   gc cr blocks received              1
                        session logical reads              1
      2 [LMS]  [STAT]   CR blocks created                  1
                        gc cr blocks flushed               1
                        gc cr blocks served                1
                        session logical reads              3

-- 1,2번 노드 각각 6개의 CR 버퍼가 적재되었습니다. 

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 00007F80720374A8      1 CR     00                        1 0000000073D70000
     00007F8072037648      1 CR     00                        1 0000000074034000
     00007F80720377C8      1 CR     00                        1 0000000074274000
     00007F8072037948      1 CR     00                        1 0000000074CD0000
     00007F8072037AC8      1 CR     00                        1 00000000739E8000
     00007F807236C5A0      1 CR     00                        1 0000000074298000

OOW2 00007F79DD69BA00      1 XCUR   00000000733E2EB0          2 000000007513A000
     00007F79DD69BB80      1 CR     00                        0 000000007545E000
     00007F79DD69BD00      1 CR     00                        0 0000000075772000
     00007F79DD69BE80      1 CR     00                        0 0000000072EB4000
     00007F79DD69C000      1 CR     00                        0 0000000075038000
     00007F79DD69C180      1 CR     00                        0 00000000734C2000
     00007F79DD69C300      1 CR     00                        0 0000000073194000

     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 KJUSEREX  GRANTED    00000000733E2EB0      1 XCUR
OOW3 00000000696D70C8      1 KJUSEREX  GRANTED

 

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


그렇다면, 해당 레코드를 7번쨰 조회할 경우에는 어떤 변화가 발생하는지 확인해보겠습니다.

-- 여전히, 'gc cr block busy' 대기이벤트가 발생합니다. 

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

WAIT #139902907847544: nam='gc cr block busy' ela= 7971 p1=6 p2=228 p3=1 obj#=93823 tim=311953030887

-- 여전히, 2번 노드의 LMS는 CR 버퍼를 1개 생성한 후 1번 노드로 전송합니다.
-- 이를 통해, _db_block_max_cr_dba 파라미터는 CR 버퍼의 생성과 관련된 것이 아니라
-- 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 busy                   1
               [STAT]   gc cr blocks received              1
                        session logical reads              1
      2 [LMS]  [STAT]   CR blocks created                  1
                        gc cr blocks flushed               1
                        gc cr blocks served                1
                        session logical reads              3

-- 버퍼 캐시내의 큰 변화는 없습니다. 즉, 여전히 CR 버퍼의 개수는 6개입니다.
-- 다만, 새로운 CR 버퍼가 1개 적재되었고 기존의 CR 버퍼 1개는 aged out 되었음을 알 수 있습니다.            

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 00007F80728A21E8      1 CR     00                        1 0000000074034000
     00007F8072A48158      1 CR     00                        1 0000000074274000
     00007F8072A482F8      1 CR     00                        1 0000000074CD0000
     00007F8072A48478      1 CR     00                        1 00000000739E8000
     00007F8072A485F8      1 CR     00                        1 0000000074298000
     00007F8072A48778      1 CR     00                        1 0000000073D70000

OOW2 00007F79DD4C4788      1 XCUR   00000000733E2EB0          2 000000007513A000
     00007F79DD4C4908      1 CR     00                        0 0000000072EB4000
     00007F79DD4C4A88      1 CR     00                        0 0000000075038000
     00007F79DD4C4C08      1 CR     00                        0 00000000734C2000
     00007F79DD4C4D88      1 CR     00                        0 0000000073194000
     00007F79DD4C4F08      1 CR     00                        0 000000007545E000
     00007F79DD4C5088      1 CR     00                        0 0000000075772000

     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 KJUSEREX  GRANTED    00000000733E2EB0      1 XCUR
OOW3 00000000696D70C8      1 KJUSEREX  GRANTED

3번 노드에서 동일한 테스트를 수행한 결과, GCS SHADOW가 생성되지 않다는 점을 제외하면 1번 노드의 테스트 결과와 동일합니다. 따라서 설명은 생략합니다.

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

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