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


 

티스토리 툴바