Gc cr/current grant 2-way

EXEM Knowledge Base

Jump to: navigation, 찾기

목차

[편집] Basic Info

프리 블록에 대한 권한을 부여 받는 경우 오라클 10g에서는 gc current grant 2-way 이벤트를 대기한 것으로 관찰되지만, 오라클 9i에서는 global cache open x 이벤트를 대기한 것으로 관찰된다. gc cr/current grant 2-way 이벤트는 gc cr/current request 이벤트에 대한 Fixed-up 이벤트로, 블록을 요청한 프로세스가 마스터 노드로부터 블록을 읽을 권한을 부여 받았음을(Grant) 의미한다. gc cr/current request 이벤트가 gc cr/current grant 2-way 이벤트로 바뀌는(fixed up되는) 흐름은 다음과 같다.

  • 요청 노드의 유저 프로세스가 특정 데이터 블록을 읽고자 한다.
  • 유저 프로세스는 해당 데이터 블록의 적절한 버전이 로컬 버퍼 캐시에 없는 것을 확인하고, 마스터 노드의 LMS 프로세스에 블록 전송을 요청한다. 유저 프로세스는 응답을 받을 때까지 gc c/current request 이벤트를 대기한다.
  • 마스터 노드의 LMS 프로세스는 GRD를 참조하여, 클러스터의 어떤 노드도 해당 블록 이미지를 로컬 캐시에 가지고 있지 않다는 것을 확인하고, 요청 노드에 블록을 직접 읽을 권한을 부여한다.
  • 유저 프로세스는 블록을 읽을 권한을 부여 받은 후, gc cr/current request 이벤트를 Fixed-up 이벤트인 gc cr/current grant 2-way 이벤트로 변경한다. 권한을 부여 받은 후에는 일반적으로 싱글 블록 I/O를 통해 해당 블록을 디스크에서 직접 읽어 들이며, db file sequential read 이벤트에 대한 대기가 뒤따른다. 만일 로컬 캐시에 BL 락을 업그레이드(S->X) 혹은 다운그레이드(X->S) 가능한 버전의 블록이 있다면 해당 블록에 대해 락 변환을 수행한 후 사용한다.

간단한 테스트를 통해 gc cr grant 2-way 이벤트와 db file sequential read 이벤트의 관계를 확인할 수 있다.

-- 마스터 노드가 노드 2인 rac_test 테이블. 노드 1과 노드2의 버퍼 캐시를 플러시해서, 클러스터 내의 어떤 노드도 해당 테이블 블록 이미지를 갖지 않도록 한다.
SQL#1> ALTER SYSTEM FLUSH BUFFER_CACHE;
SQL#2> ALTER SYSTEM FLUSH BUFFER_CACHE;

-- 노드 1에서 두 번에 거쳐 rac_test 테이블에 대해 일관된 읽기 모드의 블록 요청을 수행한다. Full Table Scan을 통해 멀티 블록 I/O 요청이 이루어진다는 사실을 기억하자.
SQL#1> SELECT * FROM rac_test;
SQL#1> /
이 두 번의 쿼리를 SQL Trace를 통해 추적한 결과는 다음과 같다.

-- 1번째 요청. 최초의 요청에서는 gc cr grant 2-way 이벤트와 db file sequential read 이벤트에 대한 대기가 순차적으로 발생한다. 이 두개의 대기 이벤트는 세그먼트 헤더 블록에 대한 읽기 요청이다. 데이터 블록들에 대해서는 멀티 블록 I/O가 발생하며, 이 경우 gc cr multi block request 대기와 db file scattered read 이벤트 대기가 반복적으로 발생한다.
select * from rac_test
WAIT #2: nam='SQL*Net message to client' ela= 2 p1=16508 p2=1 p3=0
WAIT #2: nam='gc cr grant 2-way' ela= 5327 p1=14 p2=10270 p3=4
WAIT #2: nam='db file sequential read' ela= 178217 p1=14 p2=10270 p3=1
WAIT #2: nam='gc cr grant 2-way' ela= 2634 p1=14 p2=10249 p3=8
WAIT #2: nam='db file sequential read' ela= 28691 p1=14 p2=10249 p3=1
WAIT #2: nam='gc cr grant 2-way' ela= 4457 p1=14 p2=10269 p3=9
WAIT #2: nam='db file sequential read' ela= 33336 p1=14 p2=10269 p3=1
WAIT #2: nam='gc cr multi block request' ela= 1881 p1=14 p2=10312 p3=1
WAIT #2: nam='gc cr multi block request' ela= 4 p1=14 p2=10312 p3=1
…
(오라클 10g R1에서는 한번의 멀티 블록 I/O에서 요청하는 블록수만큼 gc cr multi block request 대기가 반복적으로 발생하지만, 오라클 10g R2에서는 한번의 멀티 블록 I/O 요청에 대해 gc cr multi block request 대기는 한번만 발생한다. 이는 멀티 블록 I/O 처리 메커니즘이 개선되었다는 것을 의미한다)
WAIT #2: nam='db file scattered read' ela= 117417 p1=14 p2=10297 p3=16

-- 2번째 요청. 글로벌 캐시 동기화 작업이 발생하지 않는다. 1번째 요청을 통해 데이터 블록들에 대해 BL 락을 이미 공유 모드로 획득했기 때문이다.
select * from rac_test
WAIT #2: nam='SQL*Net message from client' ela= 225 p1=16581 p2=1 p3=0
WAIT #2: nam='SQL*Net message to client' ela= 2 p1=16232 p2=1 p3=0
WAIT #2: nam='SQL*Net message from client' ela= 777 p1=16502 p2=1 p3=0

블록을 읽을 권한을 부여하는 과정은 2-way 통신만으로 이루어지기 때문에 gc cr/current grant 3-way와 같은 대기 이벤트는 존재하지 않는다는 점에 주의하자.

[편집] Grant와 디스크 I/O, 락 변환과의 관계

한가지 주의할 점은 gc cr/current grant 2-way 이벤트가 항상 디스크 I/O로 이어지지는 않는다는 점이다. 만일 락 모드 변환이 가능한 버전의 블록이 있다면 해당 블록을 재활용하며, 이 경우에는 디스크 I/O가 발생하지 않는다. 이 원리는 gc cr/current grant busy 이벤트에서 동일하게 적용된다. 이런 면에서, “Grant”라는 용어는 특정 블록을 디스크에서 읽을 권한만을 지칭하는 것이 아니라, BL 락 모드 변환 권한까지 같이 지칭하는 것으로 이해할 수 있다. 락 모드 변환은 권한 없음, 널 모드, 공유 모드, 독점 모드 간에 이루어지게 된다. 락 모드 변환은 gc cr/current grant … 류의 이벤트뿐만 아니라 gc cr/current block … 류의 이벤트에서도 발생한다는 사실에 유의하자. 가령 현재 널 모드의 블록을 가진 요청 노드가 현재 모드의 블록 이미지를 전송(gc current block 2/3-way 이벤트)받은 경우 내부적으로 널 모드의 BL 락을 독점 모드로 업그레이드하는 작업이 수행된다. 오라클 9i RAC에서는 이러한 변환에 대해 개별적인 대기 이벤트 명을 사용하기도 한다. 가령 널 모드의 락을 공유 모드로 변환하고자 하는 프로세스는 global cache null to s 이벤트를 대기한다. 하지만 오라클 10g RAC에서는 항상 gc cr/current request 이벤트만을 사용하며, Fixed-up 이벤트를 이용해서 동일한 레벨의 정보를 제공한다.

[편집] gc current grant 2-way이벤트와 HWM이동과의 관계

gc current grant 2-way 이벤트에 대한 대기와 enq: HW – contention 이벤트에 대한 대기가 같이 관찰되는 경우가 있다. 이런 경우 gc current grant 2-way 대기이벤트는 HWM(High Water Mark)의 이동과 관련이 있다. 세그먼트에 새로운 데이터를 추가(Insert)하는 과정에서 프리 블록이 소진되면, 오라클은 HWM을 이동해서 가용한 블록들을 추가로 할당한다. 새로 추가된 블록들에 대해 Insert 작업을 수행하려면 BL 락을 독점 모드로 획득해야 한다. BL 락을 획득하고자 하는 요청 노드의 프로세스는 마스터 노드에게 해당 블록에 대한 권한을 요청한 후 gc current request 이벤트를 대기한다. 마스터 노드는 해당 블록을 점유한 노드가 없다는 것을 확인한 후, 권한을 부여하는 메시지를 보낸다. 응답을 받은 요청 노드는 gc current request 이벤트를 gc current grant 2-way 이벤트로 변경한다. 세그먼트 공간 관리 기법으로 ASSM을 사용하는 경우(오라클 10g R2부터는 기본값)에는 각 노드가 가능한 자신만의 프리 블록을 사용하게끔 보장된다. 따라서 노드 A가 할당 받은 프리 블록을 노드 B가 사용할 확률이 대단히 낮다. 따라서 HWM 이동에 의해 할당된 프리 블록을 획득하는 과정에서 대부분 gc current grant 2-way 이벤트를 대기한 것으로 관찰된다. 하지만, 프리 블록에 대한 요구가 매우 많은 경우에는 다른 노드에게 할당된 프리 블록을 훔쳐올 수 있다. 이것을 흔히 BMB Stealing(Bitmap Block Stealing)이라고 부른다. BMB Stealing이 발생할 경우에는 프리 블록을 다른 노드로부터 전송 받아야 하므로 gc current block 2/3-way 이벤트를 대기한 것으로 관찰될 수도 있다. ASSM이 아닌 FLM(Free List Management. 수동 모드의 프리 블록 관리 기법)을 사용하는 경우에는 FREELIST GROUPS 속성과 FREELISTS 속성을 적절하게 부여함으로써 ASSM과 같은 효과를 얻을 수 있다.

[편집] Parameter & Wait Time

[편집] Wait Parameters

gc cr grant 2-way 이벤트와 같은 Fixed-up 이벤트는 P1, P2, P3 값이 별도로 부여되지 않으며, Placeholder 이벤트(여기서는 gc cr request 이벤트)와 동일한 값을 가지는 것으로 해석하면 된다.

[편집] Wait Time

[편집] Check Point & Solution

gc cr/current request#Check Point & Solution을 참조한다.

[편집] Event Tip

[편집] FLM

FLM을 참조한다.

[편집] ASSM

ASSM를 참조한다.

[편집] Analysis Case