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

gc cr_current request(1)




2. gc cr/ current request

로컬 캐쉬에 존재하지 않는 데이터 블록을 일고자 하는 경우 작업이 진행되고 응답을 받을 때까지 gc cr request나 gc current request이벤트를 대기한다.
SQL> SELECT name, parameter1, parameter2, parameter3
FROM v$event_name
WHERE name = 'gc cr request';

각각 컬럼은 다음의 값을 의미한다.

참고
여기서 말하는 class는 데이터 블록의 클래스를 의미한다.

데이터 블록 클래스
오라클은 총 18가지 종류의 데이터 블록을 사용하며 다음과 같이 V$WAITSTAT 를 통해 조회가 가능하다.
SQL> SELECT RONUM AS class#, class FROM V$WAITSTAT;

[표2-1] Block Class 표

중요 포인트
이 정보를 볼 때 중요한 것은 어떤 데이터블럭에서 경합 및 대기가 발생했냐는 것이다. 어느 블록인지에 따라 해결 방법이 달라지기 때문이다.

참고
클래스# 15 이상의 데이터 블록은 언두 영역의 블록을 의미하며, 롤백 세그먼트 번호에 의해 결정된다. 클래스#와 롤백 세그먼트 번호(r)의 관계는 다음과 같다.

  • 언두 헤더 블록: class number=2*r + 15
  • 언두 블록: class number = 2*r + 16

SYSTEM 롤백 세그먼트는 r 값이 0이기 때문에 언드 헤더 블록의 class number = 2*0 + 15 = 15가 되며, 언두 블록의 class number = 2*0 + 16 = 16이 된다. 또한, 롤백 세그먼트 번호에 따라 class number 는 {17,18},{19,20},{21,22} ...순으로 증가한다.

db file sequential read와의 비교
gc cr/current request는 db file sequential read와 다음과 같은 유사성을 가진다.

2.1 비효율적인 SQL 문장으로 인한 과다한 블록 요청

gc cr/current request 대기의 주범으로 비효율적인 SQL 문장을 튜닝하지 않은 채로 다른 방법의 튜닝은 의미가 없다. 또한, 이러한 것은 SQL만 튜닝한 튜닝하면 된다.

2.1.1 RAC에서의 튜닝 포인트

RAC에서 쿼리 수행시 다음과 같은 점을 확인하도록 하자.

Parallel Execution
RAC에서는 병렬 실행이 여러 노드간에 분배된다. 이러한 대량 작업을 여러 노드에서 분산해서 수행하는 것은 클러스터의 장점을 극대화 한것이지만, 작업 시 작업의 결과가 인터커넥트를 통해 전송하는 과정에서 인터커넥트 리소스 부족으로 OLTP 쿼리에 영향을 줄 수 있음을 알아야 한다.
다음의 파라메터를 활용하면 리소스 사용량을 조절하여 좀 더 잘 되게 할 수 있다.

  • INSTANCE_GROUPS
  • PARALLEL_INSTANCE_GROUP

참고
RAC에서도 DSS성 쿼리와 OLTP성 쿼리를 같이 사용하는 것은 성능의 문제가 있음을 알아야 한다.

2.2 동시 다발적인 DML 수행

발생 이유
여러 노드에서 동일 세그먼트에 대해 대량의 DML을 동시 다발적으로 수행하면 광범위한 버퍼 락 경합이 발생하고 그 이유로 이벤트가 노출된다.

해결방법
다음의 해결 방법이 있다.

  • 노드 간에 적절히 작업을 분배하여 문제가 발생하지 않도록 한다.
  • 하나의 노드에서만 배치 작업이 진행되도록 하는 것도 방법이 될 수 있다.

2.3 핫 블록

발생 이유
여러 프로세스 또는 여러 인스턴스에 의해 동시 다발적으로 접근 혹은 변경되는 블록이 있는 경우 발생하며 RAC에서 핫블록은 래치나 버퍼 락 경합 뿐 아니라 과도한 인터커넥트 전송을 유발함으로서 RAC 시스템 전체의 성능을 저하시키는 요인이 된다.

해결 방법
다음의 해결 방법이 있다.

  • 세그먼트 파티셔닝 사용 ex> 해시 파티셔닝이 대표적임
  • 작은 크기의 블록 사용
  • 높은 값의 PCTFREE 속성 사용
  • 세그먼트 데이터 재생성. 삭제 후 재 삽입이나 테이블 재생성 등

관찰되는 이벤트
Fixed-up 이벤트로 gc cr/current block busy 이벤트가 관찰된다. gc buffer busy 이벤트도 발생한다.
참고
단일 인스턴스 환경에서의 핫 블록은 latch: cache buffers chains 이벤트나 buffer busy waits 이벤트가 추로 관찰된다.

2.4 느린 인터커넥트

발생 이유
발생 이유는 다음과 같다.

  • 주고 받는 데이터의 절대적인 양이 많은 경우
  • 대역폭이 작은 경우

해결방법
해결 방법은 다음과 같다.

  • SQL 튜닝을 통해 데이터의 양을 줄인다.
  • 대역폭이 넓은 인터커넥트를 사용한다.

2.5 비효율적인 네트워크 설정

먼저 설치시 적절한 네트워크 설정을 하도록 해야 한다.

2.5.1 네트워크 설정 확인 방법 및 관찰 방법

다음과 같이 확인이 가능하다.
SQL> oradebug setmypid
SQL> oradebug ipc
SQL> oradebug tracefile_name
/oracle/ORA19g/admin/LAS10/udump/ora102_ora_7040.trc
SSKGXPT 0xc03f844 flags SSKGXPT_READPENDING info for network 0
socket no 8 IP 192.168.2.202 UDP 41210
sflag SSKGXPT_UP

UDP 버퍼의 크기
네트워크 설정 중 성능과 가장 연관이 깊은 설정으로 권장치는 OS마다 다르지만 일반적으로 256K가 권장치이다. 이정도의 크기로 성능의 보장은 받을 수 있지만, 1M~2M 로 설정하여 사용하기도 한다.

패킷 유실(Packet Loss)
UDP 버퍼 크기가 너무 작은 경우 발생한다.
-> gc cr block lost, gc current block lost 관찰 됨

관찰 방법
다음과 같은 관찰 방법이 있다.

  • netstat i

네트워크 인터페이스 별로 패킷 유실(RX-ERR)을 관찰할 수 있다.
propmt> netstat i

  • netstat su

네트워크 관련 통계치를 통해 패킷 유실을 조회할 수 있다.
prompt> netstat su
Udp:
495820735 packets received
50018 packets to unknown port received
114 packet receive errors
584466009 packet sent

2.5.2 Jumbo Frame

Network Interface Card 설정 시 1500 byte 이상의 frame 크기를 사용하는 것을 말하며 이것을 MTUMaximum Transmission Unit이라고 한다.
일반적으로 1500byte의 MTU로 문제가 없지만 혹시 문제가 된다면 더 큰 크기의 MTU를 사용하는 것도 좋다.
하지만, Jumbo Frame을 사용하려면 OS, NIC, 스위치등 관련된 모든 소프트웨어와 하드웨어가 이를 지원해야 한다.
참고
일반적으로 9000 byte의 MTU를 사용한다.
현재 사용중인 MTU의 크기는 다음의 tool을 통해 확인이 가능하다.

  • netstat
  • ifconfig

2.5.3 문제 해결 방법

Network 문제를 해결하기 위해 여기서 제시한 방법은 다음과 같다.

  • UDP 버퍼의 크기를 2M까지 늘리면서 문제가 해결되는지 확인 한다.
  • 물리적인 네트워크 설정에 문제가 없는지 확인한다.
  • Jumbo Frame을 사용한다.

참고
netstat 의 사용법은 OS마다 다르므로, 사용시에는 해당 OS의 사용법을 확인하여 사용하도록 한다.

2.6 비효율적인 버퍼 캐시 사용

RAC환경에서도 버퍼 캐시를 효율적으로 사용하는 것은 무척 중요하다. 비효율적으로 사용하게 되면 gc cr/current request 이벤트가 불 필요하게 증가하게 된다.
일반적으로 적용 가능한 기법들은 다음과 같다.

다중 버퍼풀의 사용
세그먼트의 용도에 따라 Keep buffer, Default Buffer, Recycle Buffer를 적절히 사용하여 효율적으로 사용한다. (Advanced OWI in Oracle 10g)

전역 임시 테이블의 사용
데이터가 임시로 필요한 경우 가능한 Global Temporary Table을 사용한다. Global Temporary Table은 세션 레벨에서 관리하므로 글로벌 캐시 동기화 작업이 불필요하다.

읽기 전용 테이블 스페이스의 사용
읽기만 하는 테이블스페이스의 경우 read only로 설정하는 것이 좋다. 이것도 클로벌 캐시 동기화 작업에서 제외된다.

충분한 크기의 버퍼 캐시 크기
충분한 크기의 캐시 사이즈를 설정하는 것이 중요하다.

문서정보

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