uDPM을 이용한 튜닝

일반적으로 시스템 및 데이터베이스 성능 튜닝을 실시하기에 앞서 시스템과 데이터베이스의 자원 이용 현황 등을 파악해야 한다. 여기에서는 최적의 오라클 튜닝을 수행하기 위하여 uDPM(Unicenter Database Performance Management)을 이용해 자원이용 등의 통계치를 얻는 방법을 중심으로 설명을 하고자 한다. (시스템 및 데이터베이스 튜닝을 위한 측정도구인 uDPM(Unicenter Database Performance Management)을 이용해 성능 모니터링 및 튜닝을 수행하기 위한 보다 자세한 정보는 uDPM Reference Guide, Oracle Documentation, Unix Guide 참조
오라클 튜닝을 수행하기 위해서는 튜닝 순서가 매우 중요하다. 일반적으로 좋은 시스템 및 데이터베이스 성능은 우수한 애플리케이션 설계와 SQL 문장 작성에서부터 시작된다고 해도 과언이 아니다. 다음은 주요 튜닝을 위한 순서이다.
1) 애플리케이션 설계(Application Design)
2) 데이터 접근경로(Data Access Path)
3) 메모리 할당(Memory Allocation)
4) 디스크 IO 튜닝(Tuning Disk I/O), 공간 이용 및 단편화
(Space Utilization and Fragmentation)
5) 자원 충돌 튜닝(Tuning Resource Contention)
각 단계별 튜닝 결정은 다음 스텝에 직접적인 영향을 미친다. 예를 들면 스텝 2)에서 SQL 문장을 재작성한다면, 이러한 SQL 문장은 스텝 3)에서의 파싱과 캐싱에 많은 영향을 미치게 된다.
uDPM은 이러한 튜닝에 필요한 상세한 성능 메트릭스를 실시간과 히스토리컬(누적 데이터) 데이터로 제공한다.(문제가 있는 SQL 문장을 분리시키기거나, 또는 Exclusive Lock을 찾아내거나 대형 테이블 스캔으로 많은 자원을 점유하는 것에 경보를 보내거나 Cache Hitratio가 낮거나 테이블 스페이스에 단편화(Fragmentation)가 많이 발생하는 등의 정보 제공)

uDPM을 이용하여 네 가지 항목을 튜닝할 수 있다.
- 적절한 크기의 SGA(Properly Sized SGA)
- 프리 스페이스 관리(Free Space Management)
- 단편화 관리(Fragmentation Management)
- 자원 충돌(Resource Contention).

1) 적절한 크기의 SGA(Properly sized SGA)
오라클에서 SGA는 다음의 메모리 영역을 포함한다.
- Shared Buffer Pool
- Buffer Cache
- Redo Log Buffer
데이터 딕셔너리에서 캐시미스(Cache miss) 또는 라이브러리 캐시(library cache) 미스는 버퍼 캐시에서의 미스보다 더 많은 자원이 소요된다. 이는 공유 풀(Shared Pool)에 먼저 충분한 메모리를 할당하기 때문이다.
오라클은 라이브러리 캐시 데이터보다 더 오랫동안 메모리내의 딕셔너리 데이터를 점유한다. 따라서 공유 풀을 튜닝한 후에 남아있는 사용가능한 메모리를 버퍼 캐시에 할당하도록 해야 한다. Library Cache Monitoring
라이브러리 캐시 모니터링에서 두 가지 주요 메트릭스는 PINS와 RELOADS라고 할 수 있다. PINS는 SQL 문장, PL/SQL 블록과 오브젝트 정의(Definitions)가 실행(Execution)을 위해 액세스하는 횟수를 지칭하며, RELOADS는 오라클이 SQL 문장을 재파싱하거나 오브젝트 정의를 리로드하는 원인(즉, CPU나 I/O 자원 소비의 원인이 됨)이 되는 라이브러리 캐시 미스의 횟수를 일컫는다.
총 RELOADS는 0에 가까워야 한다. 만약 RELOADA와 PINS의 비율이 1% 이상이면 오라클은 init.ora 파라미터인 SHARED_POOL_SIZE를 증가하여 공유 풀을 늘리도록 권고한다. uDPM은 v$librarycache 테이블로부터 PINS과 RELOAD의 현황을 모니터링 하기 위하여 다음 두 가지 스캔타입(Scan Type)을 제공한다.
- Libpins : Library cache pin requests per second
- Libreloads : Library cache reloads per second
이러한 두 가지 스캔타입은 손쉽게 모니터링 하기 위하여 하나의 바 그래프 내에 1차와 2차 스캔으로 그룹화하여 나타낼 수 있다. 각 스캔타입은 실시간 뿐만 아니라 히스토리컬하게 보여주기 위하여 Strip Chart로 나타낼 수도 있다.
아래의 추가적인 메트릭스는 또한 라이브러리 캐시의 성능을 나타내기 위한 모니터링 항목이다.
- Libgethitratio : Library cache request hit ratio
- Libgethits : Library cache request hits per second
- Libgets : Library cache requests per second
- Libinval : Library cache invalidation? per second
- Libpinhitratio : Library cache pin hit ratio
- Libpinhits : Library cache pin hit requests per second

Dictionary Cache Monitoring
동적 성능 테이블 v$rowcache는 딕셔너리 캐시의 효율성을 나타내기 위하여 두 가지의 칼럼을 포함하고 있는데 이는 GETS 과 GETMISSES 이다. GETS는 동일한 항목에 대한 정보를 요구하는 총 횟수이며 GETMISSED는 캐시미스의 데이터 요구 횟수를 나타낸다. 빈번하게 딕셔너리 캐시에 액세스하기 위하여 총 GETMISSED와 총 GETS의 비율이 10% 미만이어야 한다. uDPM은 딕셔너리 캐시의 성능을 모니터링 하기 위하여 다음의 스캔타입을 제공한다.
- Dcsize, dcused, dcfree : 각 딕셔너리 캐시의 cache slots,
used slots, free slots 의 수
- Dcgets, dcmisses : 각 딕셔너리 캐시의 GETS와
GETMISSES의 수
- Dchitratio : 각 딕셔너리 캐시의 히트율
스캔타입 degets와 dcmisses는 쉽게 모니터링 하기 위하여 하나의 바 그래프 내에 프라이머리와 세컨더리 스캔으로 그룹화하여 나타낼 수 있으며 각 스캔타입은 실시간 뿐만 아니라 히스토리컬하게 보여주기 위하여 Strip Chart로도 나타낼 수도 있다.
uDPM을 이용하여 hitratio가 95% 이하로 떨어질 때 경보를 발생하기 위하여 dchitratio 상에서 General Limit Alarm(genlimit)을 설정할 수 있다.

Buffer Cache Monitoring
오라클 버퍼캐시는 테이블, 인덱스, 롤백 세그먼트, 클러스터에 대한 데이터 블럭의 복사본을 보유하고 있다. 적당한 크기의 버퍼캐시는 디스크 I/O를 감소시킴으로써 상당한 성능증대를 가져온다. 오라클은 CONSISTENT GETS과 DB BLOCK GETS의 데이터를 수집하며 PHYSICAL READS는 데이터를 디스크로부터 읽어오기 위하여(physical reads) 디스크상의 데이터 파일에 액세스하는 값이다.
버퍼캐시 히트율의 계산 방식은 다음과 같다.

(db block gets + consistent gets) - Physical Reads
Hit Ratio =
db block gets + consistent gets)

만약 히트율이 90% 미만이면 init.ora의 DB_BLOCK _BUFFERS 파라미터를 증가시켜야 한다. uDPM은 각 인스탄스별 버퍼캐시 히트율을 모니터하기 위하여 스캔타입 bchratio를 제공한다. 또한 버퍼캐시 히트율이 지정된 임계치 밑으로 떨어질 때 알람으로 통보하기 위하여 히트래시오(Hitratio) 알람을 이용하여 설정할 수 있다.

REDO log buffering monitoring
리두로그 버퍼는 데이터베이스의 변경된 정보를 보유하고 있는 SGA내의 순환 버퍼이다. REDO LOG SPACE REQUESTS는 리두로그 버퍼내의 공간을 할당받기 위하여 기다리고 있는 유저 프로세스의 횟수를 나타낸다.
이 REDO LOG SPACE REQUESTS는 항상 0에 가까워야 하며, 0이 아닌 값(1이상의 값)은 프로세스가 버퍼내의 공간을 할당받기 위하여 기다리고 있다는 것을 나타낸다. 이럴 경우 init.ora의 LOG_BUFFER 파라미터를 변경하므로써 리두로그 버퍼의 크기를 늘리는 것을 고려해야 한다. uDPM은 statredo 스캔을 이용하여 리두로그를 모니터 할 수 있다.

히트율(hit ratio)을 튜닝할 때는 공유 버퍼 풀(shared buffer pool) 또는 버퍼 캐시(buffer cache)의 크기를 늘리는 것만으로는 현저한 성능 증대를 가져올 수 없음을 기억하라. SGA를 튜닝할 때 프리 메모리를 모니터해야 하는데, 이유는 SGA의 목적이 빠른 액세스를 위하여 데이터를 메모리내에 저장하는 것이기 때문이다. 따라서 SGA는 항상 메인메모리내에 포함되어 있어야 한다. 큰 사이즈의 SGA의 장점은 운영체제 레벨에서의 과도한 스와핑과 페이징의 손실을 줄일 수 있다는 데 있다. SGA의 크기를 정할 때 운영체제 레벨에서의 성능에 영향을 미칠 수 있는 요소를 모니터링할 필요가 있다.(swapping, paging)

출처 : http://www.cai.co.kr/cafocus/v05/technical.asp