gc cr/current block busy

• gc cr/current block busy 이벤트는 gc cr/current request 이벤트에 대해 Fixed-up 이벤트.
• 홀더 노드로부터 블록 이미지를 전송 받는 과정에서 경합으로 인해 지연이 발생했다는 것을 의미.
  • 요청 노드의 유저 프로세스가 특정 데이터 블록을 읽고자 한다.
  • 유저 프로세스는 해당 데이터 블록의 적절한 버전이 로컬 버퍼 캐시에 없는 것을 확인하고,
    마스터 노드의 LMS 프로세스에 블록 전송을 요청.(응답을 받을 때까지 gc cr/current request 이벤트 대기)
  • 마스터 노드(즉, 홀더 노드)의 LMS 프로세스는 요청된 블록에 대해 BL락을 공유모드로 획득 할 수 있어야 한다.
    만일 필요한 모드의 락을 획득하는 과정에서 지연이 발생하면 요청 노드에 블록을 전송하되,
    블록을 읽어 들이는 과정에서 경합(Contention)이 발생했음을 같이 알린다.
  • 유저 프로세스는 블록을 전송 받은 후 응답 메시지로부터 경합이 발생했음을 확인하고,
    gc cr/current request 이벤트를 Fixed-up 이벤트인 gc cr/current block busy 이벤트로 변경.

• 홀더 노드의 LMS 프로세스가 블록을 전송하는 과정에서 경합에 의한 지연이 발생하는 이유
  • 요청된 블록이 로컬 프로세스에 의해 현재 사용 중인 경우.
    (Update 문에 의해 변경 중이거나, Select 문에 의해 디스크에서 버퍼 캐시로 적재되고 있는 경우.)
  • 리두 플러시(Flush) 과정이 발생하는 경우.
    홀더 노드의 로컬 프로세스에 의해 변경된 후 아직 Commit이 이루어지지 않은 블록을 요청 노드로 전송하려면, 블록의 변경 내용을 리두 로그에 기록해야 한다.
    이 과정에서 지연이 발생하면 홀더 노드에서는 gcs log flush sync 이벤트 대기 시간이 높거나, gc cr block flush time 이나 gc current block flush time 통계 값이 높게 나온다.
    {info}
    LMS 프로세스가 블록 전송을 위해 더티 블록에 대한 변경 내역을 로그 파일에 기록하는 경우에는 log file sync 이벤트가 아닌 gcs log flush sync 이벤트를 대기하는 것으로 관찰.
    {info}

• gc cr block busy 이벤트에 대한 대기를 해소하기 위한 방법
  • LGWR 프로세스의 성능을 극대화. (디바이스 최적화, CPU 우선순위 높임)
  • SQL 튜닝을 통해 읽기 작업과 변경 작업이 동일 블록을 액세스하는 경우의 수를 줄인다.
  • 버퍼 캐시 튜닝을 통해 메모리로 읽어 들인 블록이 캐시에서 밀려나는 경우의 수를 줄인다.
  • 블록 분산 기법(파티셔닝, 리버스 키 인덱스, 시퀀스 캐시 크기)을 이용해 핫블록이 발생할 확률을 줄인다.
• gc cr block busy 이벤트 대기는 블록 경합에 의해 발생하기 때문에, 인터커넥트 성능과는 무관.
  (블록을 전송하는 과정에서 지연이 발생하는 것이 아니라, 홀더 노드가 블록 전송을 준비하는 과정에서 지연이 발생한는 것)

• 테스트

-- 노드 2가 마스터 노드인 rac_test
-- 노드 2에서 rac_test 테이블에 대해 Update 수행 후 Commit을 수행하지 않음
SQL#2> UPDATE rac_test SET id = 3;

-- 노드 1에서 rac_test 테이블을 Select, 노드 2에 의해 변경된 블록을 읽어 들인다.
SQL#1> SELECT * FROM rac_test;
SQL#1> /
... 같은 쿼리 여러 번 수행

• 홀더 노드에서의 리두 플러시에 의해 지연이 발생하고, 요청 노드는 gc cr block busy 이벤트를 대기. (p.110 참조)

요청 모드와 busy 이벤트

• 요청 노드의 CR 모드 요청에 대해 홀더 노드가 아직 Commit이 이루어 지지 않은 현재 블록을 전송하는 경우에는 반드시 CR블록(변경 이전 이미지)를 전송해야 한다.
• 홀더 노드의 버퍼 캐시에 CR 이미지가 존재하지 않는 경우 오라클은 불완전한 이미지의 CR 블록을 요청 노드로 전송.
• 불완전한 CR 블록을 전송 받은 요청 노드가 스스로 완전한 이미지의 CR블록을 생성.(Light Weight Rule(경량화 법칙))
• V$CR_BLOCK_SERVER 뷰를 조회하면 전체 읽기 일관된 읽기 작업 중 Light Weight Rule이 몇 번이나 적용되었는지 확인할 수 있다.
  • SELECT cr_requests, light_works FROM v$cr_block_server;
• Commit이 이루어지지 않은 더티 블록에 대한 CR 모드 요청에 대해서는 주로 gc cr block 2/3-way류의 이벤트를,
  이 과정에서 리두 플러시 과정에서의 지연이 발생하면 gc cr block busy 이벤트를 Fixed-up 이벤트로 사용.
• Commit이 이루어진 더티 블록에 대해 Current 모드의 요청이 발생하면, 즉각 락 다운그레이드 발생.
• 이 경우 요청 노드는 일반적으로 gc current block 2/3-way 이벤트를,
  만일 홀더 노드의 리두 플러시 과정에서 지연이 발생하면 gc current block busy 이벤트를 Fixed-up 이벤트로 사용.

문서에 대하여

• 최초작성자 : 김종원
• 최초작성일 : 2011년 03월 25일
• 이 문서는 오라클클럽 코어 오라클 데이터베이스 스터디 모임에서 작성하였습니다.
• {*}이 문서의 내용은 (주)엑셈에서 출간한 'RAC Advanced OWI, Internals and Performance in Oracle 10g'를 참고하였습니다.*