ORACLE8 OPS TUNING

Question

제품 : ORACLE SERVER
작성날짜 : 2004-08-13
ORACLE8 OPS TUNING
====================
PURPOSE
이 자료는 OPS 환경에서의 db tuning에 대한 설명자료입니다.
SCOPE
Standard Edition 에서는 Real Application Clusters 기능이 10g(10.1.0) 이상 부터 지원이 됩니다.
Explanation
OPS 튜닝에 있어 단일 인스턴스에서의 튜닝 요소(buffer cache, shared pool,
disk 등)들은 여전히 중요한 의미를 가지고 있지만, OPS 환경에서의 추가적인
튜닝 요소들에 대한 이해 역시 필요하다.
튜닝 파라미터에 대한 적절한 튜닝으로 시스템 성능 개선을 얻을 수 있지만,
LM lock contention에 대한 부정확한 분석 등으로 야기된 문제를 해결해 주지는
못한다.
OPS에서의 tuning 은 shared resource 간의 contention의 최소화로 maximum
performance를 내는 것이 중요하다.
1. contention bottlenecks
1) data block : pinging, false pinging
만일 multiple instance가 동시에 같은 data block을 update할 경우 instance
간에 이 block의 pinging이 발생할 것이다. pcm lock이 관장하는 block이
많다면 false pinging발생이 증가 할 것이다.
<참고> Pinging : 한 instance가 다른 instance가 필요로 하는 data block을 수
정하였다면 다른 instance가 이 block을 읽기 전에 disk에 write해야
하는데 이러한 동작을 pinging이라 한다.
False pinging : 서로 다른 인스턴스에서 서로 다른 블럭들에 대한 요
청을 하는데, 이것이 동일한 PCM lock에 의해 처리될 때 발생한다.
이와 같은 pinging은 PCM lock의 처리 단위를 줄임으로써 발생하지
않을 수도 있기 때문에 불필요한 ping이라고 할 수 있다.
2) rollback segment : read consistency
만일 한 instance에서 DML transaction이 rollback 정보를 만들었고 다른
instance에서 read consistency를 위해 이 rollback 정보가 필요하다면
rollback segment block에 contention이 있을 것이다.
3) segment header : freelist contention
multiple transaction이 동시에 object(table,index,cluster)에 insert 시
segment의 header에 즉 freelist에 contention이 발생할 것이다. instance가
segment header에 pinging이 발생할 것이다.
4) device contention
multiple instance가 동시에 같은 disk에 write 시 contention이 발생할 것이
다.
2. Lock Conversion 진단
Lock이 upgrade/downgrade 되는 lock conversion 작업에 대해 V$LOCK_ACTIVITY,
V$SYSSTAT의 정보를 조회함으로써 lock contention 문제를 진단할 수 있다.
Lock convert 작업이 얼마만큼 자주 일어나는지를 판단하기 위해서는 데이터 블럭을
읽거나 수정하는 transaction에서 얼마만큼의 lock convert 작업이 필요한지를
계산해야 한다.
이것을 lock hit ratio로 수치화 할 수 있는데, 계산 방법은 전체 데이터 블럭에
대한 access 중, lock convert 작업이 필요하지 않은 데이터 블럭에 대한 비율을
구하면 된다.
Lock hit ratio = (consistent_gets - global_lock_converts(async)) / consistent_gets
이 값은 다음 sql 문장을 수행시켜 구해낼 수 있다.
SELECT      (b1.value - b2.value) / b1.value ops_ratio
FROM      V$SYSSTAT b1, V$SYSSTAT b2
WHERE      b1.name = `consistent gets'
AND      b2.name = `global lock converts (async)';
이 값이 95% 미만으로 나오면 노드를 추가하여 얻을 수 있는 성능 향상을 충분히
활용하지 못하는 상태이다.
3. View를 통한 parallel server의 모니터/ 튜닝
1) V$LOCK_ACTIVITY에 대한 분석
분산 lock에 대해서는 다음과 같은 절차를 따라 모니터와 튜닝 작업을 한다.
(가) 각각의 인스턴스들에 대해 다음 query를 연속적으로 시행한다.
SELECT * FROM V$LOCK_ACTIVITY;
(나) 만약 어느 한 인스턴스라도 lock conversion이 급격하게 증가를 한다면, 다음
SQL 문장을 실행시켜 가장 많이 발생하는 lock conversion의 종류를 찾아낸다.
SELECT * FROM V$LOCK_ACTIVITY;
가장 많이 발생하는 lock conversion이 X 에서 낮은 단계 (예: X -> S, X -> Null,
X -> SSX, S -> N)로 변환되는 것이라면, 이것은 buffer cache의 블럭 (ping이
되는 블럭)에 대한 인스턴스들의 contention을 의미하며, 인스턴스가 다른 인스턴스의
요청에 의해 lock 을 release하는 상황이다. 이 때 해당 인스턴스에서 conversion
횟수가 급격하게 증가하는지 여부를 모니터해야 한다.
(다) 각각의 인스턴스에서 V$LOCK_ACTIVITY를 조회해서 어느 인스턴스에서 가장 많이 NULL -> S, S -> S,
S-> X 변환이 많이 일어나는지를 조사한다. 이와 같은 변환이 가장 많이 일어나는 인스턴스는, 다른 인스턴스에
의해 이미 lock이 걸린 데이터를 가장 많이 요청(ping)하는 인스턴스이다.
만약 ping이 주로 두개의 인스턴스간에 발생한다면 두 노드에서 실행되는 application을 한 노드에서 실행
되도록 조정하는 것을 고려해야 한다. ((사) 참조) 만약 ping이 여러 노드간에 골고루 일어난다면 PCM lock
할당 및 애플리케이션에 대한 튜닝 작업이 필요하다. ((아) 참조)
(라) V$PING을 조회하여 어느 블럭들이 가장 ping이 되는지를 조사한다.
SELECT * FROM V$PING;
가장 많이 ping이 발생하는 목록만을 추려서 조회해 보고 싶으면 다음과 같이 조건을 추가할 수 있다.
SELECT * FROM V$PING
WHERE FORCED_READS > 10 OR FORCED_WRITES > 10;
SELECT NAME, KIND, STATUS, SUM(FORCED_READS),
SUM(FORCED_WRITES)
FROM V$PING
GROUP BY NAME, KIND, STATUS ORDER BY SUM(FORCED_READS);
(V$BH를 조회하는 것이 V$PING이나 V$CACHE를 조회하는 것 보다 빠르게 실행된다. V$BH를 실행해서 블럭
number나 file number등을 조회한 후, OBJ$와 join을 해서 object의 이름을 찾아낼
수 있다.
SELECT      O.NAME, BH.* FROM
FROM           V$BH BH, OBJ$ O
WHERE     O.OBJ# = BH.OBJD
AND          (BH.FORCE_READS > 10 OR BH.FORCED_WRITES > 10);
(마) ping이 가장 많이 발생하는 블럭에 대해, GC_FILES_TO_LOCKS에 지정된 데이터파일의 FILE#와 비교해서
PCM lock이 여러 블럭에 대해 lock을 거는지 알아낸다. 만약 그렇다면 lock이 여러 파일의 블럭들에 대해
lock을 거는지를 조사한다.
(바) 하나의 PCM lock이 여러 블럭을 대해 lock을 건다면, 다른 인스턴스에서 이미 lock이 걸린 블럭, 또는
해당 블럭은 아니더라도 하나의 PCM lock에 의해 lock이 걸린 블럭을 요청하고 있는지를 조사해야 한다.
(사) 만약 해당 블럭이 다른 인스턴스에서 나타나지 않는다면, 이것은 불필요한 contention (false pinging)이
발생하는 것을 뜻한다. 만약 다른 인스턴스에서 해당 블럭은 아니지만, 같은 PCM lock에 의해 관리되는
블럭을 요청한다면, 같은 PCM lock이 요청되기 때문이다. 하나 혹은 그 상의 데이터파일에서 불필요한
contention을 최소화 시키기 위해서는 GC_FILES_TO_LOCKS 파라미터 값을 늘려 좀더 많은 PCM lock을
할당함으로써 PCM lock당 처리되는 블럭의 갯수를 줄여야 한다.
(아) 여러 인스턴스의 buffer cache에서 동일한 블럭이 여러차례 나타난다면 이것은 인스턴스 들이 동일한
데이터에 대해 contention 발생에 대한 결과이다. 여러 instnace에서 동일한 블럭에 대한 변경이 필요할
때, 그 데이터를 처리하는 애플리케이션을 한쪽 노드에서 실행시켜 성능 향상을 기할 수 있다. 그리고
여러 인스턴스들이 동일한 블럭 내의 다른 row에 있는 자료를 변경하려는 경우에는 테이블을 FREELISTGROUPS
storage 옵션을 사용하여 재 생성한 후, 특정 인스턴스에 extent를 할당한 후 적절한 extent에서 선택적
으로 update가 일어날 수 있도록 조치하는 것이 좋다. 작은 테이블에 대해서는 PCTFREE, PCTUSED 값을
사용하여 한개의 블럭이 한개의 row만을 포함하도록 조절하여 성능 향상을 기할 수 있다.
만약 row에 대한 contention이 고유한 숫자를 생성하기 위한 것이라면 애플리케이션에서 SEQUENCE를 사용
하도록 조정하여 contention을 줄이도록 해야 한다. (데이터 블럭이나 다른 고유 자원에 대한 contention은
반드시 성능에 심각한 영향을 미치는 것은 아니다.
만약 애플리케이션의 response time이 문제가 될 정도가 아니고, 시스템 사용이 크게 늘어날 상황이 아니라면
parallel server에 대한 튜닝을 하지 않아도 될 상황일 수도 있다.)
2) Ping을 진단하기 위한 V$PING 조회
(가) V$PING을 조회하여 lock conversion에 대한 종합 통계를 조회한다.
SQL> SELECT NAME, FILE#, CLASS#, MAX(XNC) FROM V$PING
GROUP BY NAME, FILE#, CLASS#
ORDER BY NAME, FILE#, CLASS#;
NAME      FILE#      CLASS#     MAX(XNC)
DEPT      8      1      492
DEPT      8      4           10
EMP      8      1      3197
EMP      8      4      29
(나) File# 8 의 블럭에 대해 PCM lock의 빈도를 조사하기 위해 V$PING을 다시한번 조회한다.
SQL> SELECT * FROM V$PING WHERE FILE# = 8;
SQL> SELECT * FROM V$PING WHERE FILE# = 8;
FILE# BLOCK#      STAT      XNC      CLASS# NAME KIND
8 98 XCUR      450 1 EMP      TABLE
8      764 SCUR 59 1 DEPT TABLE
(다) 98번 블럭에 속하는 EMP table의 row들을 구한다. BLOCK# 값을 16진수 값으로 바꾸고 ROWID 값과 비교한다.(98은 16진수로 62임)
SQL> SELECT ROWID, EMPNO, ENAME FROM EMP
WHERE chartorowid(rowid) like '00000062%';
ROWID      EMPNO      ENAME
00000062.0000.0008      12340           JONES
00000062.0000.0008      6491           CLARK
3) V$CLASS_PING, V$FILE_PING, V$BH에 대한 조회
contention을 가장 많이 유발시키는 요인을 파일별로 혹은 블럭 class별로 구분할 수 있다.
- V$CLASS_PING
(가) 어떤 class의 블럭이 (예 rollback segment) 가장 많이 ping이 되는지를 조
사하는데 유용하다.
(나) lock conversion type별로 (예 Null -> Shared), 혹은 conversion에 의해 발생
한 physical I/O의 read와 write별로 세분해서 조회할 수 있게 한다.
(다) 인스턴스 기동 후부터 지금까지의 누적 수치를 나타낸다.
(라) Contention을 분산하기 위해서는 다른 종류의 블럭 class들을 서로 다른
파일에 위치시키는 것이 좋다. 예를 들어 rollback segment와 데이터파일
을 서로 다른 파일에 두는 등의 작업을 할 수 있다.
- V$FILE_PING
(가)가장 많이 ping이 되는 파일이 어느 파일인지를 구분할 수 있게 해 준다.
(나) 인스턴스 시작후 누적된 통계 값이다.
(다) Contention을 분산시키기 위해서는 가장많이 ping이 되는 파일에 들어
있는 object들을 다른 파일로 옮기는 것을 고려해 볼 수 있다. 만약 특
정 table에서 ping이 많이 발생한다면 table에 대한 partition을 고려하거
나 partigion을 다른 파일로 옮기는 등의 작업을 할 수 있다.
- V$BH
(가) 주어진 시점에서 buffer cache에 대한 snapshot 역할을 한다. 주기적으로
V$BH를 조회해서 변동의 추이를 조사해야 한다.
(나) 통계값은 인스턴스 시작 이후로의 누적 수치가 아니라 한 시점에서의
통계값이다. 시스템 운영 시간동안 주기적으로 점검해서 ping에 대한 정
보를 수집하고, ping과 관련된 buffer cache내의 object를 밝혀내고, ping
에 의해 야기되는 forced read/write I/O를 조사할 수 있다.
(다) V$BH는 object id컬럼이 있어, OBJ$와 join을 해서 object 이름을 구할
수 있다.
( Global dynamic performance view (GV$)에는 V$CLASS_PING, V$FILE_PING, V$BH에 대응하는 GV$CLASS_PING, GV$FILE_PING, GV$BH가 있다.)
4) V$WAITSTAT을 이용한 contention 모니터
rollback segment나 free list등 블럭 contention에 관한 통계 정보를 구하는데 사용할 수 있다.
- Free List의 블럭에 대한 contention 모니터
Free list에 대한 contention문제에 대해서는 다음과 같은 단계를 거쳐 조치한다.
(가) Free list의 free 블럭에 대한 wait 횟수 조회
SQL>      SELECT CLASS, COUNT FROM V$WAITSTAT
2      WHERE CLASS = 'free list';
CLASS      COUNT
free list 12
(나) 일정 기간동안의 free list에 대한 전체 request 횟수(SUM) 조회
SQL>      SELECT SUM(VALUE) FROM V$SYSSTAT
2      WHERE name IN ('db block gets', 'consistent gets');
SUM (VALUE)
12050211
(다) Free 블럭에 대한 wait (COUNT)가 전체 request에 대한 합(SUM)의 1%가 넘는다면 contention을 줄이기 위해
free list를 추가해 주는 것을 고려해야 한다.
Table에free list를 추가하기 위해서는 FREELISTS storage 파라미터 값을 늘려 테이블을 재 생성해야 한다.
이때 FREELISTS 값을 사용자들이 동시에 insert 하는 값에 맞춰 주어야 한다.
SQL> CREATE TABLE new_emp
2 STORAGE (FREELISTS 5)
3 AS SELECT * FROM emp;
Table created.
SQL> DROP TABLE emp;
Table dropped.
SQL> RENAME new_emp TO emp;
Table renamed.
- Rollback Segment에 대한 contention 모니터
Rollback segment에 대한 contention 문제는 다음과 같은 단계를 통해 조치한다.
(가) V$WAITSTAT으로 rollback segment에 대한 contention 조사
SQL> SELECT CLASS, COUNT
2 FROM V$WAITSTAT
3 WHERE CLASS IN ('system undo header', 'system undo block','undo header','undo block');
CLASS COUNT
system undo header 12
system undo block 11
undo header      28
undo block      6
(나) 일정기간동안 rollback segmet에 대한 총계(SUM)를 구한다.
SQL> SELECT SUM(VALUE) FROM V$SYSSTAT
2 WHERE name IN ('db block gets', 'consistent gets');
SUM (VALUE)
12050211
(다) Rollback segment에 대한 전체 request에 대해 wait된 횟수 (COUNT)가 1%가 넘는다면 CREATE ROLLBACK
SEGMENT 명령으로 rollback segment를 추가해 준다.
5) V$FILESTAT, V$DATAFILE을 이용한 I/O에 대한 조회.
V$FILESTAT과 V$DATAFILE은 시스템 내에 I/O가 많이 발생하는지를 판단할 수 있는 통계 정보를 제공한다.
(가) 각각의 데이터파일에 대한 read/write 횟수를 데이터베이스 파일명과 함께 조회하기 위해서는 다음과
같이 한다.
SQL> SELECT NAME, PHYRDS, PHYWRTS
2 FROM V$DATAFILE df, V$FILESTAT fs
3 WHERE df.file# = fs.file#;
NAME      PHYRDS          PHYWRTS
/test71/ora_system.dbs      7679      2735
/test71/ora_system1.dbs      32      546
(나) 데이터베이스 파일이 아닌 다른 파일에 대한 read/write를 모니터 하기 위해서는 iostat과 같은 O/S
유틸리티를 활용한다.
(다) Disk에 I/O가 너무 많이 발생하여, disk를 추가 한 후 overload를 줄여야 할 경우, V$FILESTAT를 활용하여
통계정보를 분석하여야 한다. Disk I/O에 대한 contention을 최소화 시키기 위해서는 다음과 같은 조치가 취해 질 수 있다.
a. 데이터파일과 리두로그 파일을 서로 다른 디스크로 나누어 위치시킨다.
b. 테이블의 데이터가 여러 디스크에 나누어 들어가도록 한다.
c. 테이블과 인덱스를 서로 다른 디스크로 나눈다.
d. Oracle 서버와 무관한 disk I/O를 줄인다.
(라) V$DATAFILE 정보를 활용하여 데이터파일들이 disk I/O에 대한 contention을 줄이기 위해 서로 다른
디스크에 나누어 들어가야 하는 지를 판단한다. 자주 사용되는 데이터파일들을 서로 다른 disk에 나누어
두면 데이터를 access할 때 적은 contention이 발생한다.
( Disk I/O 한계치를 찾아보기 위해서는 hardware 문서를 참조할 것. 만약 disk contention의 한계치에서 문제가 발생한다.
예를 들어 초당 40회 이상의 I/O가 발생한다면 대부분의 VMS나 Unix 시스템에서
처리해 주기 어려운 수치이다.)
Reference Ducumment
Oracle8 ops manual.

Answer 1

Dear Mr.Sanju,
There are 6 bstat/estat outputs. Which ones do I post?
Or if you can gimme ur email, I shall send all of them to you....
Dear MR.SJH,
Coelescing tablespaces is something that I will do...but there are too many schemas...so how do I identify the important ones...Any pointers please.....
Regards,
Sriraman