h2.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';
각각 컬럼은 다음의 값을 의미한다.

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

[표2-1] Block Class 표

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

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



h3.2.1 비효율적인 SQL 문장으로 인한 과다한 블록 요청
gc cr/current request 대기의 주범으로 비효율적인 SQL 문장을 튜닝하지 않은 채로 다른 방법의 튜닝은 의미가 없다. 또한, 이러한 것은 SQL만 튜닝한 튜닝하면 된다.
h4.2.1.1 RAC에서의 튜닝 포인트
RAC에서 쿼리 수행시 다음과 같은 점을 확인하도록 하자.
Parallel Execution
RAC에서는 병렬 실행이 여러 노드간에 분배된다. 이러한 대량 작업을 여러 노드에서 분산해서 수행하는 것은 클러스터의 장점을 극대화 한것이지만, 작업 시 작업의 결과가 인터커넥트를 통해 전송하는 과정에서 인터커넥트 리소스 부족으로 OLTP 쿼리에 영향을 줄 수 있음{}을 알아야 한다.
다음의 파라메터를 활용하면 리소스 사용량을 조절하여 좀 더 잘 되게 할 수 있다.

• INSTANCE_GROUPS
• PARALLEL_INSTANCE_GROUP

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

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

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

• 세그먼트 파티셔닝 사용 ex> 해시 파티셔닝이 대표적임
• 작은 크기의 블록 사용
• 높은 값의 PCTFREE 속성 사용
• 세그먼트 데이터 재생성. 삭제 후 재 삽입이나 테이블 재생성 등
  관찰되는 이벤트
  Fixed-up 이벤트로 gc cr/current block busy 이벤트가 관찰된다. gc buffer busy 이벤트도 발생한다.

h3.2.4 느린 인터커넥트
발생 이유
발생 이유는 다음과 같다.

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

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

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

h3.2.5 비효율적인 네트워크 설정
먼저 설치시 적절한 네트워크 설정을 하도록 해야 한다.
h4.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
h4.2.5.2 Jumbo Frame
Network Interface Card 설정 시 1500 byte 이상의 frame 크기를 사용하는 것을 말하며 이것을 MTU 즉 Maximum Transmission Unit{}이라고 한다.
일반적으로 1500byte의 MTU로 문제가 없지만 혹시 문제가 된다면 더 큰 크기의 MTU를 사용하는 것도 좋다.
하지만, Jumbo Frame을 사용하려면 OS, NIC, 스위치등 관련된 모든 소프트웨어와 하드웨어가 이를 지원해야 한다.

현재 사용중인 MTU의 크기는 다음의 tool을 통해 확인이 가능하다.

• netstat
• ifconfig
  h4.2.5.3 문제 해결 방법
  Network 문제를 해결하기 위해 여기서 제시한 방법은 다음과 같다.
• UDP 버퍼의 크기를 2M까지 늘리면서 문제가 해결되는지 확인 한다.
• 물리적인 네트워크 설정에 문제가 없는지 확인한다.
• Jumbo Frame을 사용한다.

h3.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{}로 설정하는 것이 좋다. 이것도 클로벌 캐시 동기화 작업에서 제외된다.
충분한 크기의 버퍼 캐시 크기
충분한 크기의 캐시 사이즈를 설정하는 것이 중요하다.