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

1. 테스트 개요


2번 노드에서 레코드 1건 (마스터 노드: 3번)을 변경합니다. 그런 후에 해당 블록 내의 각기 다른 레코드를 1번 노드 및 3번 노드에서 변경합니다. 이를 통해, 변경 중인 블록을 변경할 때 발생하는 gc cr block busy, gc cr block 2-way, gc cr block 3-way, gc current block 2-way, gc current block 3-way 대기이벤트의 동작원리를 파악하도록 합니다.

2. 2번 노드에서 1건 UPDATE


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

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

24-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_update1 

WAIT #140225505525552: nam='gc cr grant 2-way' ela= 1818 p1=6 p2=228 p3=1 obj#=93973 tim=394675630649
WAIT #140225505525552: nam='db file sequential read' ela= 2100 file#=6 block#=228 blocks=1 obj#=93973 tim=394675632854
WAIT #140225505525552: nam='gc current grant 2-way' ela= 3294 p1=6 p2=228 p3=33619969 obj#=93973 tim=394675636305
WAIT #140225505525552: nam='db file sequential read' ela= 3964 file#=5 block#=240 blocks=1 obj#=0 tim=394675640394
WAIT #140225505525552: nam='db file sequential read' ela= 1170 file#=5 block#=245 blocks=1 obj#=0 tim=394675641954

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

SYS@OOW2:2> alter system dump datafile 5 block 245;
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 00007F79DD4C9118      1 CR     00                        0 0000000074726000
     00007F79DD4C9298      1 XCUR   00000000753FD2B0          2 0000000074AE8000

     X$KJBL           X$KJBL X$KJBL    X$KJBL     X$BH               X$BH X$BH
INST LOCKP             OWNER GRANT     LOCKST     LE_ADDR           CLASS STATE
---- ---------------- ------ --------- ---------- ---------------- ------ ------
OOW2 00000000753FD338      1 KJUSEREX  GRANTED    00000000753FD2B0      1 XCUR
OOW3 00000000696DCCA8      1 KJUSEREX  GRANTED

 

3. 1번 노드에서 동일 블록 내의 다른 레코드 업데이트


1번 노드에서 동을 블록 내의 다른 레코드를 변경하면 2번 노드의 XCUR 버퍼는 PI 버퍼로 변경되고 1번 노드에 XCUR 버퍼가 적재됩니다. (그림-2 참조)

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

24-2

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

-- 해당 블록에 대한 변경 작업을 수행해야하므로 CURRENT 버퍼를 전송 받아야합니다.
-- 해당 블록의 마스터 노드는 3번 노드이고 현재 2번 노드에 존재하므로
-- 'gc cuurent block 3-way' 대기이벤트가 1회 발생합니다. 

-- 또한, 변경 작업을 위한 언두 블록을 할당 받기 위해 'db file sequential read' 대기이벤트가 2회 발생합니다.

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

WAIT #139902824629120: nam='gc cr block busy' ela= 10832 p1=6 p2=228 p3=1 obj#=93973 tim=334535308571
WAIT #139902824629120: nam='gc current block 3-way' ela= 4535 p1=6 p2=228 p3=33554433 obj#=93973 tim=334535313580
WAIT #139902824629120: nam='db file sequential read' ela= 3131 file#=4 block#=176 blocks=1 obj#=0 tim=334535317648
WAIT #139902824629120: nam='db file sequential read' ela= 2645 file#=4 block#=1738 blocks=1 obj#=0 tim=334535320442

WAIT #139902827416192: nam='gc cr block busy' ela= 5942 p1=6 p2=228 p3=1 obj#=93973 tim=421043266066
WAIT #139902827416192: nam='gc current block 3-way' ela= 3107 p1=6 p2=228 p3=33554433 obj#=93973 tim=421043269474
WAIT #140357041043368: nam='db file sequential read' ela= 3131 file#=4 block#=240 blocks=1 obj#=0 tim=421043270380
WAIT #139902827416192: nam='db file sequential read' ela= 3960 file#=4 block#=697 blocks=1 obj#=0 tim=421043274340

-- 1번 노드의 Foreground 프로세스는 CR 버퍼와 CURRENT 버퍼를 각각 1개씩 전송 받았음을 알 수 있습니다.
-- 2번 노드의 LMS는 CR 버퍼를 1개 생성했고, XCUR 버퍼를 PI 버퍼로 변경하기 위해
-- 'gc cr blocks flushed'를 1회 수행했습니다.
-- 또한, CR 버퍼와 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]  db file sequential read            2
                        gc cr block busy                   1
                        gc current block 3-way             1
               [STAT]   gc cr blocks received              1
                        gc current blocks received         1
                        physical reads                     2
                        session logical reads              4
      2 [LMS]  [STAT]   CR blocks created                  1
                        gc cr blocks flushed               1
                        gc cr blocks served                1
                        gc current blocks served           1
                        session logical reads              3

-- 2번 노드의 버퍼 상태가 XCUR에서 PI로 변경되었고, CR 버퍼가 1개 적재되었습니다.
-- 1번 노드에 XCUR 및 CR 버퍼가 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 00007F80728C2FD0      1 CR     00                        0 000000007518A000
     00007F80728C3150      1 XCUR   00000000757E5958          1 00000000742A6000

OOW2 00007F79DD4FCB10      1 CR     00                        0 00000000749A0000
     00007F79DD4FCC90      1 PI     00000000753FD2B0          2 00000000745C0000
     00007F79DD4FCE10      1 CR     00                        0 000000007451A000

     X$KJBL           X$KJBL X$KJBL    X$KJBL     X$BH               X$BH X$BH
INST LOCKP             OWNER GRANT     LOCKST     LE_ADDR           CLASS STATE
---- ---------------- ------ --------- ---------- ---------------- ------ ------
OOW1 00000000757E59E0      0 KJUSEREX  GRANTED    00000000757E5958      1 XCUR
OOW2 00000000753FD338      1 KJUSERNL  GRANTED    00000000753FD2B0      1 PI
OOW3 00000000696F1F18      0 KJUSEREX  GRANTED
OOW3 00000000696E4610      1 KJUSERNL  GRANTED

 

4. 3번 노드에서 동일 블록 내의 다른 레코드 업데이트


3번 노드에서 동일 블록 내의 다른 레코드를 변경하면 1번 노드의 XCUR 버퍼는 PI 버퍼로 변경되고 3번 노드에 XCUR 버퍼가 적재됩니다. (그림-3 참조) 이점은 2번 노드에서의 변경과 동일합니다. 하지만 한번 PI 버퍼가 생성된 이후에는 gc cr buffer busy 대기가 아닌 gc cr block 2-way 대기이벤트가 발생합니다. 이것은 이전 시점에 2번 노드의 LMS가 수행한 gc cr blocks flushed의 영향으로 파악됩니다. 그리고 1번, 2번 노드에서 수행한 트랜잭션과 관련된 언두 헤더 블록 및 언두 블록을 전송 받기 위해서 gc cr block 2-way 대기이벤트가 총 4회 발생했습니다.

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

24-3

-- 해당 블록 (p1=6 p2=228)에 대한 CR 버퍼와 CURRENT 버퍼를 전송 받는 과정에서
-- 'gc cr block 2-way'와 'gc current block 2-way' 대기이벤트가 각각 1회 발생합니다.

-- 1번 노드에서 수행한 트랜잭션과 관련된 언두 헤더 블록 (p1=4 p2=240)
-- 및 언두 블록 (p1=4 p2=697)에 대한 CR 버퍼를 전송 받는 과정에서
-- 'gc cr block 2-way' 대기이벤트가 2회 발생합니다.

-- 2번 노드에서 수행한 트랜잭션과 관련된 언두 헤더 블록 (p1=5 p2=240)
-- 및 언두 블록 (p1=5 p2=235)에 대한 CR 버퍼를 전송받는 과정에서
-- 'gc cr block 2-way' 대기이벤트가 2회 발생합니다.

-- 해당 트랜잭션 수행을 위한 언두 헤더 블록과 언두 블록을 할당 받는 과정에서
-- 'db file sequential read' 대기이벤트가 2회 발생합니다. 

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

WAIT #140357041043368: nam='gc cr block 2-way' ela= 2455 p1=6 p2=228 p3=1 obj#=93973 tim=394694643881

WAIT #140357041043368: nam='gc cr block 2-way' ela= 811 p1=4 p2=240 p3=31 obj#=0 tim=394694645290
WAIT #140357041043368: nam='gc cr block 2-way' ela= 1073 p1=5 p2=240 p3=51 obj#=0 tim=394694647769
WAIT #140357041043368: nam='gc cr block 2-way' ela= 3229 p1=4 p2=697 p3=32 obj#=0 tim=394694651686
WAIT #140357041043368: nam='gc cr block 2-way' ela= 1424 p1=5 p2=245 p3=52 obj#=0 tim=394694654291

WAIT #140357041043368: nam='gc current block 2-way' ela= 1088 p1=6 p2=228 p3=33554433 obj#=93973 tim=394694655965

WAIT #140357041043368: nam='db file sequential read' ela= 6037 file#=2 block#=128 blocks=1 obj#=0 tim=394694662551
WAIT #140357041043368: nam='db file sequential read' ela= 1904 file#=2 block#=2540 blocks=1 obj#=0 tim=394694665150

-- 1번 노드의 LMS가 3개의 CR 버퍼와 1개의 CURRENT 버퍼를 전송했습니다.
-- 2번 노드의 LMS가 2개의 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 [LMS]  [STAT]   gc cr blocks served                3
                        gc current blocks served           1
                        session logical reads              3
      2 [LMS]  [STAT]   gc cr blocks served                2
                        session logical reads              2
      3 [FG]   [EVENT]  db file sequential read            2
                        gc cr block 2-way                  5
                        gc current block 2-way             1
               [STAT]   gc cr blocks received              5
                        gc current blocks received         1
                        physical reads                     2
                        session logical reads             10

-- 1번 노드의 버퍼 상태가 XCUR에서 PI로 변경되었습니다.
-- 3번 노드에 XCUR 및 CR 버퍼가 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 00007F80724285B0      1 CR     00                        0 000000007518A000
     00007F8072428730      1 PI     00000000757E5958          1 00000000742A6000

OOW2 00007F79DD4D15F0      1 CR     00                        0 00000000749A0000
     00007F79DD4D1770      1 PI     00000000753FD2B0          2 00000000745C0000
     00007F79DD4D18F0      1 CR     00                        0 000000007451A000

OOW3 00007FBB2D4168B0      1 CR     00                        0 00000000752A6000
     00007FBB2D416A30      1 XCUR   00000000757E6AD8          1 000000007494E000

     X$KJBL           X$KJBL X$KJBL    X$KJBL     X$BH               X$BH X$BH
INST LOCKP             OWNER GRANT     LOCKST     LE_ADDR           CLASS STATE
---- ---------------- ------ --------- ---------- ---------------- ------ ------
OOW1 00000000757E59E0      0 KJUSERNL  GRANTED    00000000757E5958      1 PI
OOW2 00000000753FD338      1 KJUSERNL  GRANTED    00000000753FD2B0      1 PI
OOW3 00000000696E4610      1 KJUSERNL  GRANTED
OOW3 00000000696F1F18      0 KJUSERNL  GRANTED
OOW3 00000000757E6B60      2 KJUSEREX  GRANTED    00000000757E6AD8      1 XCUR

 

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

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