by-nc-sa     개발자, DBA가 함께 만들어가는 구루비 지식창고!

gc cr_current block busy




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 이벤트로 변경.
"경합(Contention)과 혼잡(Congestion)"
  1. 오라클은 경합(Contention)과 혼잡(Congestion) 이라는 두 가지 사유에 의해 글로벌 캐시 동기화 과정에서의 지연 현상이 발생하는 것으로 정의.
  2. 경합이 지연의 발생 사유인 경우에는 "Busy"라는 용어를 사용
  3. 혼잡이 발생 사유인 경우에는 "Congested"라는 용어를 사용
  • 홀더 노드의 LMS 프로세스가 블록을 전송하는 과정에서 경합에 의한 지연이 발생하는 이유
    • 요청된 블록이 로컬 프로세스에 의해 현재 사용 중인 경우.
      (Update 문에 의해 변경 중이거나, Select 문에 의해 디스크에서 버퍼 캐시로 적재되고 있는 경우.)
    • 리두 플러시(Flush) 과정이 발생하는 경우.
      홀더 노드의 로컬 프로세스에 의해 변경된 후 아직 Commit이 이루어지지 않은 블록을 요청 노드로 전송하려면, 블록의 변경 내용을 리두 로그에 기록해야 한다.
      이 과정에서 지연이 발생하면 홀더 노드에서는 gcs log flush sync 이벤트 대기 시간이 높거나, gc cr block flush time 이나 gc current block flush time 통계 값이 높게 나온다.

      LMS 프로세스가 블록 전송을 위해 더티 블록에 대한 변경 내역을 로그 파일에 기록하는 경우에는 log file sync 이벤트가 아닌 gcs log flush sync 이벤트를 대기하는 것으로 관찰.

  • 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'를 참고하였습니다.

문서정보

Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.