꿈꾸는 개발자, DBA 커뮤니티 구루비

h2.3. gc cr/ current block 2-way
gc cr/current block 2-way 이벤트는 gc cr/current request에 대한 Fixed-up 이벤트로 블록을 요청한 프로세스가 Master Node로부터 직접 블록 이미지를 전송 받았다는 것을 의미한다.

h3.3.1 전체 이벤트 발생 프로세스
전체 이벤트 발생 프로세스는 다음과 같다.

[그림 3-1] gc cr/current block 2-way

0. 요청 노드의 유저 프로세스가 특정 데이터 블록을 CR모드 또는 Current 모드로 읽겠다고 요청한다.
1. 유저 프로세스는 해당 데이터 블록의 적절한 버전이 로컬 버퍼 캐시에 없는 것을 확인하고, 마스터 노드의 LMS 프로세스에 블록 전송을 요청한다.
---> gc cr/current request 발생
2. Master Node의 LMS 프로세스가 자신의 로컬 버퍼 캐시에 요청 받은 블록 이미지가 존재하는 것을 확인하고
3. 인터 커넥트를 통해 해당 블록의 이미지를 전송한다. 블록 요청 종류에 따라 다음과 같은 통계값이 증가한다.

4. GRD 변경 후
5. 유저 프로세스는 블록 이미지를 전송 받는다.
---> gc cr/current block 2-way 로 변경

블록 요청 종류에 따라 다음과 같은 통계값이 증가한다.

참고

gc cr block 2-way 이벤트와 같은 Fixed-up 이벤트는 Placeholder 이벤트와 동일한 값을 가진것으로 해석하면 된다.

h3.3.2 gc cr/current block 2-way 이벤트와 글로벌 캐시 동기화
RAC 시스템{}에서
CR 모드로 읽을 수 있는 버전의 블록 = Shared Mode로 BL 락을 획득한 블록

Current 모드로 읽을 수 있는 버전의 블록 = Exclusive Mode로 BL락을 획득한 블록

h4.3.2.1 로컬 캐쉬에서 CR 블록 읽기
RAC를 위한 최고의 튜닝 방법은 글로벌 캐시 동기화 작업을 수행하지 않고{}, SQL 문장 튜닝과 효율적인 버퍼캐시 사용을 통해,
일단 로컬 캐시로 읽어 들인 블록들을 최대한 재활용 하는 것이다.

로컬 캐쉬에서 블록을 바로 읽기
글로벌 캐시 동기화 작업 없이 로컬 버퍼 캐시에서 바로 블록을 읽기 위해서는 로컬에 CR모드로 읽을 수 있는 버전의 블록이 존재해야 하며 이것은 곧 공유 모드로 BL락을 획득한 블록을 가지고 있어야 한다는 것이다.

로컬 캐쉬에서 블록 읽기 = CR 모드로 읽을 수 있는 버전의 블록 = 공유 모드(Shared Mode)로 BL 락을 획득한 블록

참고

Current 모드 블록을 읽는 경우에도 위와 같은 룰이 적용되어, 로컬에 Exclusive Mode로 BL락을 획득한 블록이 있을 경우{}에 글로벌 캐시 동기화 작업을 수행하지 않고 바로 로컬 캐쉬의 블록을 사용한다.

h4.3.2.2 Shared Mode로 BL락을 획득해야 하는 경우
요청 노드의 유저 프로세스가 CR 모드의 블록 전송을 요청한 후에 데이터 블록에 대해 Shared Mode로 BL 락을 획득하는 경우는 다음과 같다.

전체 클러스터에서 최초로 블록을 읽어 들이는 경우
Holder Node가 Shared Mode로 읽어 들인 블록을 전송 받는 경우
Holder Node가 Exclusive Mode로 읽어 들인 블록을 전송 받되, 이 블록이 _FAIRNESS_THRESHOLD 파라메터 값(default 값:4)을 최과하여 전송된 경우

3.2.3 _FAIRNESS_THRESHOLD

_FAIRNESS_THRESHOLD 임계치를 초과하여 락 다운 그레이드가 발생한 경우 V$CR_BLOCK_SERVER를 통해 확인할 수 있다.

SQL> SELECT cr_requests, fairness_down_converts FROM V$CR_BLOCK_SERVER;

cr_requests : CR block 전체 요청 횟수
fairness_down_converts : 락 다운 그레이드 발생 횟수

위의 수치를 %로 바꿔 보면 다음과 같다.

fairness_down_converts/cr_requests * 100

위 수치가 25% 이상 인 경우 _FAIRNESS_THRESHOLD 수치를 1 또는 2로 낮추는 것을 고려하는 것이 좋다.

수치가 높다는 것은 거꾸로 CR 블록 요청에 대한 추가적인 블록 전송이 많이 발생한다는 것을 의미함
락 다운그레이드가 빨리 이루어지도록 하여 추가적인 블록 전송이 없게 하는 것이 성능 개선에 도움이 될 수 있다.

h4.3.2.4 Exclusive Mode로 BL락을 획득해야 하는 경우
요청 노드의 유저 프로세스가 Current Mode의 블록 전송을 요청한 후에 데이터 블록에 대해 Exclusive Mode로 BL락을 획득하는 경우는 다음과 같다.

전체 클러스터에서 최초로 블록을 읽어 들이는 경우
Holder Node가 Shared Mode로 읽어 들인 Current 블록을 전송 받는 경우
Holder Node가 Exclusive Mode로 읽어 들인 Current 블록을 전송 받은 경우

h4.3.2.4 Fusion Write
Exclusive Mode의 Current 블록을 Current 모드로 전송하는 경우 항상 PI 블록이 생성되고, 클러스터 내에 여러 개의 PI블록이 생성될 수 있다. 이와 같은 경우에 클러스터 전체 레벨의 current 블록 만이 디스크에 기록되는 메커니즘이 보장되어야 하는데, 이것을 Fusion Write라고 한다.

[그림 3-2] Fusion Write 메커니즘

Checkpoint 발생
Master Node에 클러스터 전체 레벨에서 current 블록을 기록할 것을 요청하고,
Master Node는 GRD를 통해 Holder Node에 디스크 기록을 요청하고
디스크 기록이 성공하면
다른 모든 인스턴스에서 PI 블록을 버퍼 캐시에서 해제하도록 한다.

Fusion Write 작업 확인
V$SYSSTAT 을 통해 DBWR 프로세스의 디스크 기록 작업중 Fusion Write가 얼마나 많은 비중을 차지하는지 확인 할 수 있다.

SQL> SELECT name, value FROM v$sysstat WHERE name like '%DBWR%';
NAME VALUE

---
DBWR checkpoint buffers written 28039411
....
DBWR fusion writes 8524130

h3.3.3 일관된 읽기 모드 요청에 대해 현재 모드의 블록을 전송하는 경우
Holder Node가 Current 블록을 로컬 캐쉬에 가지고 있는 경우 다른 노드들이 _FAIRNESS_TRHESHOLD 파라미터값(4)을 초과하여 CR모드로 블록을 요청한 경우
---> CR Mode가 아닌 Current Mode의 블록 이미지를 전송 받는다.

요청 노드 Event : gc current block 2-way/3-way

통계값은 다음과 같이 증가한다.

h3.3.4 현재 모드의 블록 요청에 대해 일관된 읽기 모드의 블록을 전송하는 경우
DML 수행 후 장시간 커밋을 하지 않은 상태에서 Current 블록을 요청 하는 경우 다음의 그림처럼 작업이 진행되어야 한다.

[그림 3-3] 커밋 전 블록 전송

특정 노드의 장시간의 트랜잭션을 수행하는 도중에 다른 노드에서 DML을 수행하게 되면 언두 정보 참조{}를 위해 추가적인 블록 전송이 이루어 진다는 사실을 알아야 한다.
---> gc cr block 2/3-way 대기

h3.3.5 2-way와 3-way의 차이점
2-way와 3-way는 다음과 같다.

2-way : 2개의 노드에서 통신 하는 것을 말함.
3-way : 3개의 노드에서 통신 하는 것을 말함.
gc cr/current block 3-way 가 발생함.

3-way 통신이 지나치게 많다는 것은 마스터 노드가 잘못 할당되어있다는 것을 의미할 수도 있으므로 마스터 노드가 잘못 할당된건 아닌지 의심해 봐야 한다.
---> Oracle 10g R2 부터는 세그먼트 레벨의 다이나믹 리마스터링이 지원됨
---> 불필요한 인터커넥트 통신이 자연스럽게 줄어든다.

gc cr_current block 2-way (by joanney) [2011.03.24]

3.2.3 _FAIRNESS_THRESHOLD