# GC EVENT
l 대기 이벤트들을 class로 묶어 놓은 리스트 확인방법
SQL#1> select distinct wait_class from v$event_name; WAIT_CLASS ---------------------------------------------------------------- Concurrency System I/O User I/O Administrative Other Configuration Scheduler Cluster -> RAC 관련 대기이벤트들의 클리스 Application Idle Network Commit |
n buffer busy wait 대기 이벤트가 어느 클래스인지 확인
SQL#1> select name, wait_class from v$event_name where name='buffer busy waits'; NAME WAIT_CLASS -------------------------------------------- buffer busy waits Concurrency |
- GC(global cache) : 내 노드에 데이터가 없기 때문에 다른 node에서 데이터를 요청하고 있다고 생각하면 된다
- current(update) : update를 위해 대기한다는 의미
- cr(select) : select를 위해 대기한다는 의미
- block 2-way : 2개의 노드간의 데이터 전송이 이루어졌다는 것을 알 수 있다
조회 : select * from v$session_event;
n gc 관련 이벤트 확인
# 1번노드 SQL#1> exec dbms_workload_repository.create_snapshot; SQL#1> @exec - buffer busy waits 발생
# 2번노드 SQL#2> @exec - buffer busy waits 발생
SQL#1> exec dbms_workload_repository.create_snapshot; SQL#1> @?/rdbms/admin/awrrpt.sql
|
l GC 이벤트 발생 원인 해결방법
l reverse index
- 인덱스의 key 컬럼을 뒤집어서 정렬하는 인덱스
SQL> connect scott/tiger SQL> create index emp_ename on emp(ename); SQL> select /*+ index_asc(emp emp_ename) */ ename from emp where ename > ' '; ENAME ---------- ADAMS ALLEN BLAKE CLARK FORD JAMES JONES KING MARTIN MILLER SCOTT SMITH TURNER WARD
SQL> drop index emp_ename; SQL> create index emp_ename on emp(ename) reverse; SQL> select /*+ index_asc(emp emp_ename) */ ename from emp where ename > ' '; ENAME ---------- WARD FORD BLAKE KING SMITH CLARK ALLEN MARTIN MILLER TURNER JAMES JONES ADAMS SCOTT - reverse는 맨 끝자리의 알파벳 순서로 정렬 - reverse를 쓰면 좋은 점은 만약에 A로 시작하는 사원이름들이 한블럭에 있는데 많은 사용자가 A로 시작하는 사원만 업데이를 한다면 gc 이벤트가 발생한다 - 이것을 방지하기 위해서 여러 block에 퍼뜨려서 저장할 필요가 있는데 이럴 때 reverse를 사용한다
|
n index script 생성
- DBA >> describe db object 메뉴 선택
|
n gc current request 대기 이벤트 테스트(ADDM report)
# 1번노드 SQL#1> exec dbms_workload_repository.create_snapshot; SQL#1> @exec
SQL#1> exec dbms_workload_repository.create_snapshot; SQL#1> @?/rdbms/admin/addmrpt.sql
- ORANGE를 통해서 index script 추출 : 아래의 인덱스 부분만 가져와서 reverse로 만들면 index 관련 이벤트를 줄일 수 있다
- 스크립트에서 추출한 index를 reverse 옵션을 붙여서 재생성
|
n gc buffer busy wait 이벤트 테스트 및 해결(ADDM ,ASH, AWR report)
- buffer busy wait 는 특정 이벤트에 update가 몰려서 생기는 이벤트이다
- AWR report는 1시간에 한번씩 snapshot을 찍지만 ASH report는 1초에 한번씩 수집한다
>> gc buffer busy 이벤트를 일으키고 ash 결과 레포트를 확인
SQL#1> exec dbms_workload_repository.create_snapshot; SQL#1> @exec
SQL#1> exec dbms_workload_repository.create_snapshot;
- top session 을 확인해보면 이벤트를 발생시키는 sid와 serial 번호를 확인할 수 있다
- 이벤트를 일으키는 DB의 파일의 위치를 확인할 수 있다
>> ash report로 원인을 알아냈으니 addm report를 떠서 해결방법을 알아본다
SQL#1> @?/rdbms/admin/addmrpt.sql
>> addm report에서 pctfree 의 공간을 늘리라는 내용이 있었으므로 다음과 같이 공간을 늘리고 awr compare report를 생성한다
SQL> alter table OWI.T_GC_BUFFER_BUSY pctfree 60; SQL> alter tablespace TBS_GC_BUFFER_BUSY add datafile size 50m;
- 비교 레포트를 생성한 결과 위처럼 gc buffer busy 시간과 waits가 줄어든 것을 확인할 수 있다
|
l RAC 관련 대기 이벤트
- Placeholders while waiting : 대기하는 동안 나타나는 대기 이벤트
- Precise events after waiting : 대기한 후에 그 동안 어떤 이유로 대기했는지 이유를 알려 주는 대기 이벤트
- 대기 이벤트 원인 분석은 ADDM을 통해 할 수 있다
l gc current 2-way block
- gc current block update 관련 이벤트라는 것을 알 수 있다
- 2-way : 2노드간 발생한 이벤트라는 것을 알 수 있다
- 내가 update를 하려고 하는데 update 하려고 하는 데이터 블록이 상대편 노드에서 이미 update가 이루어져 redo logfile에 내려쓰는 작업이 있어서 결과를 늦게 본 것이라고 생각할 수 있다
- redo logfile이 구성된 스토리지를 write가 빠른 스토리지로 구성하면 해결 된다
l 3-way block request
- 3-way : 3노드간에 데이터 요청과 전송이 있었다는 것을 판단할 수 있다
- gc current : update를 하려다가 대기한 것을 알 수 있다
l 2-way grant
- grant : 내가 찾길 원하는 데이터가 어떤 노드에도 없기 때문에 발생했다는 것을 알 수 있고 직접 읽기 위해 권한을 부여하는 과정에서 대기한 것을 알 수 있다
'빅데이터과정 > RAC' 카테고리의 다른 글
| #46_140818_RAC_TAF (0) | 2014.08.18 |
|---|---|
| #46_140818_RAC_GLOBAL ENQUEUE WAITS (0) | 2014.08.18 |
| #45_140814_RAC_CACHE FUSION (0) | 2014.08.14 |
| #44_140813_RAC_TUNING (0) | 2014.08.13 |
| #44_140813_RAC_DATAFILE 복구 (0) | 2014.08.13 |