My Books

My Slides

rss 아이콘 이미지

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 대기이벤트의 동작원리를 파악하도록 합니다.



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


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


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


-- 해당 블록은 로컬 및 리모트 캐시에 존재하지 않으므로 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_update1 

WAIT #140225505518032: nam='gc cr grant 2-way' ela= 1694 p1=6 p2=228 p3=1 obj#=93973 tim=310683117658
WAIT #140225505518032: nam='db file sequential read' ela= 1004 file#=6 block#=228 blocks=1 obj#=93973 tim=310683118769
WAIT #140225505518032: nam='gc current grant 2-way' ela= 1585 p1=6 p2=228 p3=33619969 obj#=93973 tim=310683120612
WAIT #140225505518032: nam='db file sequential read' ela= 4967 file#=5 block#=208 blocks=1 obj#=0 tim=310683125736
WAIT #140225505518032: nam='db file sequential read' ela= 4138 file#=5 block#=3097 blocks=1 obj#=0 tim=310683130557

WAIT #140225502776168: nam='log file sync' ela= 3259 buffer#=3054 sync scn=12152221 p3=0 obj#=0 tim=310702054641

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

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

-- 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 00007F79DD4D06B0      1 CR     00                        0 0000000073540000
     00007F79DD4D0830      1 XCUR   00000000753FD2B0          2 0000000073A8E000

     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 00000000696D69C0      1 KJUSEREX  GRANTED



3. 1번 노드에서 동일 블록 내의 다른 레코드 UPDATE 및 COMMIT 수행


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


그림-2. 1번 노드에서 동일 블록 내의 다른 레코드 UPDATE 및 COMMIT 수행후의 변경 내용


-- 2번 노드로부터 CR 버퍼와 CURRENT 버퍼를 각각 1개씩 전송 받습니다. 해당 블록의 마스터 노드는 3번이므로 
-- 'gc cr block 3-way'와 'gc current block 3-way' 대기이벤트가 1회씩 발생합니다.

-- 그리고, 트랜잭션 수행을 위한 언두 헤더 블록과 언두 블록을 메모리로 적재하는 과정에서
-- 'db file sequential read' 대기이벤트가 2회 발생합니다.

-- 마지막으로 커밋 수행에 따른 'log file sync' 대기이벤트가 1회 발생합니다. 
  
SCOTT@OOW1:1> @set_trace_on 10046 8
SCOTT@OOW1:1> @one_row_update2 

WAIT #139902827416192: nam='gc cr block 3-way' ela= 2424 p1=6 p2=228 p3=1 obj#=93973 tim=337578449818
WAIT #139902827416192: nam='gc current block 3-way' ela= 2505 p1=6 p2=228 p3=33554433 obj#=93973 tim=337578453388
WAIT #139902827416192: nam='db file sequential read' ela= 1202 file#=4 block#=192 blocks=1 obj#=0 tim=337578455469
WAIT #139902827416192: nam='db file sequential read' ela= 1351 file#=4 block#=1474 blocks=1 obj#=0 tim=337578457287

WAIT #139902827440960: nam='log file sync' ela= 2514 buffer#=6901 sync scn=12156733 p3=0 obj#=0 tim=337578468566


-- 2번 노드의 LMS가 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 3-way                  1
                        gc current block 3-way             1						
               [STAT]   gc cr blocks received              1
                        gc current blocks received         1
                        physical reads                     2
                        session logical reads              5						
      2 [LMS]  [STAT]   gc cr blocks served                1
                        gc current blocks served           1
                        session logical reads              1

-- 2번 노드의 버퍼 상태가 XCUR에서 PI로 변경되었습니다.
-- 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 00007F8072042788      1 CR     00                        0 00000000751CC000
     00007F8072042908      1 XCUR   0000000073BE8BA8          1 0000000074910000

OOW2 00007F79DD4D06B0      1 CR     00                        0 0000000073540000
     00007F79DD4D0830      1 PI     00000000753FD2B0          2 0000000073A8E000

     X$KJBL           X$KJBL X$KJBL    X$KJBL     X$BH               X$BH X$BH
INST LOCKP             OWNER GRANT     LOCKST     LE_ADDR           CLASS STATE
---- ---------------- ------ --------- ---------- ---------------- ------ ------
OOW1 0000000073BE8C30      0 KJUSEREX  GRANTED    0000000073BE8BA8      1 XCUR
OOW2 00000000753FD338      1 KJUSERNL  GRANTED    00000000753FD2B0      1 PI
OOW3 00000000696D69C0      1 KJUSERNL  GRANTED
OOW3 0000000069728E78      0 KJUSEREX  GRANTED



4. 3번 노드에서 동일 블록 내의 다른 레코드 UPDATE 및 COMMIT 수행


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


그림-3. 3번 노드에서 동일 블록 내의 다른 레코드 UPDATE 및 COMMIT 수행후의 변경 내용


-- 1번 노드로부터 CR 버퍼와 CURRENT 버퍼를 각각 1개씩 전송 받습니다. 해당 블록의 마스터 노드는 3번이므로 
-- 'gc cr block 2-way'와 'gc current block 2-way' 대기이벤트가 1회씩 발생합니다.

-- 그리고, 트랜잭션 수행을 위한 언두 헤더 블록과 언두 블록을 메모리로 적재하는 과정에서
-- 'db file sequential read' 대기이벤트가 2회 발생합니다.

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

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

WAIT #140357041043368: nam='gc cr block 2-way' ela= 2111 p1=6 p2=228 p3=1 obj#=93973 tim=311326241579
WAIT #140357041043368: nam='gc current block 2-way' ela= 2687 p1=6 p2=228 p3=33554433 obj#=93973 tim=311326245126
WAIT #140357041043368: nam='db file sequential read' ela= 2116 file#=2 block#=160 blocks=1 obj#=0 tim=311326247918
WAIT #140357041043368: nam='db file sequential read' ela= 4200 file#=2 block#=2335 blocks=1 obj#=0 tim=311326252599

WAIT #140357041184600: nam='log file sync' ela= 3590 buffer#=5594 sync scn=12156920 p3=0 obj#=0 tim=311326263131

-- 1번 노드의 LMS가 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 [LMS]  [STAT]   gc cr blocks served                1
                        gc current blocks served           1
                        session logical reads              1						
      3 [FG]   [EVENT]  db file sequential read            2
                        gc cr block 2-way                  1
                        gc current block 2-way             1						
               [STAT]   gc cr blocks received              1
                        gc current blocks received         1
                        physical reads                     2
                        session logical reads              5

-- 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 00007F80728C39A0      1 CR     00                        0 00000000751CC000
     00007F80728C3B20      1 PI     0000000073BE8BA8          1 0000000074910000

OOW2 00007F79DD4D06B0      1 CR     00                        0 0000000073540000
     00007F79DD4D0830      1 PI     00000000753FD2B0          2 0000000073A8E000

OOW3 00007FBB2D2152B8      1 CR     00                        0 0000000074962000
     00007FBB2D215438      1 XCUR   00000000757E6AD8          1 00000000745BE000


     X$KJBL           X$KJBL X$KJBL    X$KJBL     X$BH               X$BH X$BH
INST LOCKP             OWNER GRANT     LOCKST     LE_ADDR           CLASS STATE
---- ---------------- ------ --------- ---------- ---------------- ------ ------
OOW1 0000000073BE8C30      0 KJUSERNL  GRANTED    0000000073BE8BA8      1 PI
OOW2 00000000753FD338      1 KJUSERNL  GRANTED    00000000753FD2B0      1 PI
OOW3 0000000069728E78      0 KJUSERNL  GRANTED
OOW3 00000000696D69C0      1 KJUSERNL  GRANTED
OOW3 00000000757E6B60      2 KJUSEREX  GRANTED    00000000757E6AD8      1 XCUR


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


연재를 마무리하며


5개의 연재를 통해서 캐시 퓨전의 기본 원리에 대해서 살펴보았습니다. 다음 시간에는 경합에 의해 발생하는 buffer busy와 관련된 사항에 대해서 설명할 예정입니다.

저작자 표시 비영리 변경 금지
신고
크리에이티브 커먼즈 라이선스
Creative Commons License

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건 변경 후의 버퍼 캐시 변경 내용


-- 해당 블록은 로컬 및 리모트 캐시에 존재하지 않으므로 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건 변경 후의 버퍼 캐시 변경 내용


-- 해당 블록은 현재 변경 전 (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건 변경 후의 버퍼 캐시 변경 내용


-- 해당 블록 (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 대기이벤트에 대한 이해

저작자 표시 비영리 변경 금지
신고
크리에이티브 커먼즈 라이선스
Creative Commons License

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 수행 후의 변경 내용


-- 해당 블록은 로컬 및 리모트 캐시에 존재하지 않으므로 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회 조회한 후의 버퍼 캐시 변경 내용


-- 해당 블록의 마스터 노드는 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회 조회한 후의 버퍼 캐시 변경 내용


-- 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회 조회한 후의 버퍼 캐시 변경 내용


-- 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건 조회 후의 버퍼 캐시 변경 내용


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



7. 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 대기이벤트에 대한 이해

저작자 표시 비영리 변경 금지
신고
크리에이티브 커먼즈 라이선스
Creative Commons License

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건 변경 후의 버퍼 캐시 변경 내용


-- 해당 블록은 로컬 및 리모트 캐시에 존재하지 않으므로 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건 조회 후의 버퍼 캐시 변경 내용


-- 해당 블록은 현재 변경 전 (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번 조회 후의 버퍼 캐시 변경 내용



-- 해당 블록은 현재 변경 전 (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 파라미터에 대한 이해



 

저작자 표시 비영리 변경 금지
신고
크리에이티브 커먼즈 라이선스
Creative Commons License

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


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


테스트 환경 : 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건 조회 후의 버퍼 캐시 변경 내용


-- 해당 블록은 로컬 및 리모트 버퍼 캐시에 존재하지 않으므로 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건 조회 후의 버퍼 캐시 변경 내용


-- 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건 조회 후의 버퍼 캐시 변경 내용


-- 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 파라미터에 대한 이해

저작자 표시 비영리 변경 금지
신고
크리에이티브 커먼즈 라이선스
Creative Commons License


 

티스토리 툴바