gc buffer busy

gc buffer busy

RAC 환경에서 딜레이가 발생하는 경우 gc buffer busy에 관련된 wait event들을 확인해봐야 합니다.

AWR에서도 쉽게 확인을 할 수 있습니다.

RAC 환경에서 gc 붙는다는 것은 싱글 인스턴스에서 발생하는 이벤트들의 글로벌 버전이라고 보시면 쉽습니다.

gc buffer busy는 로컬 프로세스가 읽고자 하는 블록이 현재 리모트 노드의 요청에 의해 사용 중임을 의미합니다.

Placeholder/Fixed-up 분류를 따르지 않는 독립 이벤트입니다.

buffer busy가 발생하는 경우는 아래와 같습니다.

• 같은 인스턴스의 다른 프로세스가 해당 블록을 변경 중일 때는 변경이 완료될 때까지 buffer busy wait 이벤트를 대기.
• 같은 인스턴스의 다른 프로세스가 해당 블록을 디스크에서 읽어 들이는 중일때는 I/O 작업이 완료될 때까지 read by other session 이벤트를 대기.
• I/O 작업을 수행하는 프로세스는 db file sequential read 이벤트나 db file scattered read 이벤트를 대기.
• 같은 인스턴스의 다른 프로세스가 해당 블록을 다른 인스턴스로부터 전송 받고 있는 중이라면 전송이 끝날 때까지 gc buffer busy 이벤트 대기.
• 다른 인스턴스의 요청에 의해 해당 블록이 전송 중이라면, 전송이 끝나고 사용이 완료될 때까지 gc buffer busy 이벤트를 대기.

gc buffer busy와 gc current request 이벤트의 P1, P2, P3 값의 의미를 조회해보면 아래와 같은 내용을 알 수 있습니다.

SQL> begin                                                       
  2    print_table('select name, parameter1, parameter2, parameter3       
  3             from v$event_name                                            
  4             where name in (''gc buffer busy'', ''gc current request'')');
  5  end;                                                                 
  6  /                                                                    
NAME                          : gc buffer busy                            
PARAMETER1                    : file#                                     
PARAMETER2                    : block#                                    
PARAMETER3                    : id#                                       
-----------------                                                         
NAME                          : gc current request                        
PARAMETER1                    : file#                                     
PARAMETER2                    : block#                                    
PARAMETER3                    : id#                                       
-----------------

본적인 발생 원인은 buffer busy wait 이벤트와 동일하며 해결책도 동일합니다.

• 핫 블록이 가장 일반적인 원인. 핫 블록을 분산시킴으로 문제 해결.
• 세그먼트 레벨의 파티셔닝, 우편향 인덱스 현상 해소, 시퀀스 캐시 크기의 증가, PCTFREE 증가등.
• FLM을 사용하는 경우에는 세그먼트 헤더 블록이 버퍼 경합의 원인이 되므로 FREELIST GROUPS 속성을 노드 수와 동일하게 설정.
• SQL 튜닝을 통해 불필요하게 많은 블록이 교환되는 것을 방지.
• 동일한 세그먼트에 대한 대량의 DML 작업이 여러 노드에서 동시 다발적으로 발생하면 어플리케이션 실행을 적절히 분배.