[관리][튜닝] Onnoff 사이트 Oracle tunning 분석 보고

현 시점에서 onnoff 오라클 성능 체크 결과 롤백 세그먼트 부분과 로그 버퍼 영역에서의  처리 문제로 지속적인 wait 현상으로 인해 접속이 끊어지는 상황 이 자주 일어났습니다 .  2000년 10월 27일 오전 9시30분 에 오라클 튜닝에 들어가기 전에  오라클 체크 상황입니다.

1. 오라클 공유 메모리

Total System Global Area                        146128272 bytes

Fixed Size                                          64912 bytes

Variable Size                                   129114112 bytes

Database Buffers                                 16777216 bytes

Redo Buffers                                       172032 bytes

2. 데이타 버퍼 캐쉬영역

NAME                                                             VALUE

—————————————————————- ———-

db block gets                                                        975551

consistent gets                                                    35976174

physical reads                                                       749147

hit ration = 98 % 입니다.

70% 가 가장 최적이며 70%보다 낮으면 데이타 버퍼 메모리가 너무 많이 활당 되어져서 메모리 낭비이고 70% 보다 많을시는 활당된 메모리가 부족 하시다고 보시면 됩니다.

3. 라이브러리 튜닝

PINS       RELOADS

———- ———-

   1062459      10474

ratio = 0.9

ratio 값이 1 이 넣을때 라이브러리 캐쉬가 부족한거 보시면 됩니다.

4. 딕션어리 캐쉬 영역

GETS       GETMISSES

———- ———-

    780512        213

ratio = 4.8 %

ratio 값이 10% 이상이면 딕션어리 캐쉬가 부족하시다 보시면 됩니다.

5. 롤백 세그먼트

NAME                           GETS                       WAITS

————-  —————– ———-

SYSTEM                           27540                       0

ONNOFF_ROLL               619840                  1285

현재 onnoff 계정으로 수행되는 모든 작업은 ONNOFF_ROLL 이라는 롤백세크먼트 하나로 처리 되며 앞의 gets 값이 요청받은 작업량이고 뒤에 waits 값이 처리가 안되고 대기중이 작업량입니다.

waites 값이 많을수록 처리 속도가 계속 지연되고 접속이 중단되는 원인 의 하나 입니다.

6. 로그 버퍼 캐쉬

NAME                                                             VALUE

———————————- ———-

redo log space requests                                                  250

redo log space requests 값이 0 이상이 나올경우 로그 버퍼 캐쉬가 부족 하다고 보시면 됩니다.  현재의 onnoff 경우 로그 버퍼 캐쉬가 넉넉히 잡혀 있다고 하더라도 물리적인 redo log file 이 상당히 부족하기 때문에 적용이 되고 있지 않습니다.  로그 파일의 문제는 오라클 수행처리 속도에 지대한 영향을 미치는 부분으로 자리잡고 있습니다.

7. 디스크 경합

SVRMGR>  select d.name, f.phyrds, f.phywrts

     2>  from v$datafile d, v$filestat f

     3>  where d.file# = f.file#;

NAME                                                                             PHYRDS     PHYWRTS

——————————————————————————– ———- ———-

/home/oracle/product/8.1.5//oradata/onnoffdb/system01.dbf                            231761       5345

/home/oracle/product/8.1.5//oradata/onnoffdb/oemrep01.dbf                                29         27

/home/oracle/product/8.1.5//oradata/onnoffdb/rbs01.dbf                                   29         27

/home/oracle/product/8.1.5//oradata/onnoffdb/temp01.dbf                                  99        623

/home/oracle/product/8.1.5//oradata/onnoffdb/users01.dbf                                 29         27

/home/oracle/product/8.1.5//oradata/onnoffdb/indx01.dbf                                  29         27

/home/oracle/product/8.1.5//oradata/onnoffdb/drsys01.dbf                                 29         27

/home/oracle/onnoff_01.dbf                                                            32825       4519

/home/oracle/product/8.1.5/oradata/datafile1.dbf                                         29         27

오라클 데이터 파일의 위치 역시 한 파티션에 집중되어져 있기 때문에 I/O 장치에 경합이 생길 가능성이 있지만 현시점에서의 상항으로 보아 시스템에서 허용하는데 제한치에서 여 유가 있어 보입니다. 하지만 앞으로 생성시킬 데이터 파일은 물리적으로 다른 하드디스크나 다른 파티션으로 위치를 정하셔야 할것입니다.

9. 데이터 파일의 용량 체크

FILE_NAME                                                                        BYTES

——————————————————————————– ———-

/home/oracle/product/8.1.5//oradata/onnoffdb/system01.dbf                         277872640

/home/oracle/product/8.1.5//oradata/onnoffdb/oemrep01.dbf                           5242880

/home/oracle/product/8.1.5//oradata/onnoffdb/rbs01.dbf                             31913984

/home/oracle/product/8.1.5//oradata/onnoffdb/temp01.dbf                            26214400

/home/oracle/product/8.1.5//oradata/onnoffdb/users01.dbf                           31457280

/home/oracle/product/8.1.5//oradata/onnoffdb/indx01.dbf                            15728640

/home/oracle/product/8.1.5//oradata/onnoffdb/drsys01.dbf                           83886080

/home/oracle/onnoff_01.dbf                                                        104857600

/home/oracle/product/8.1.5/oradata/datafile1.dbf                                   52428800

정상적인 오라클 운영상 롤백세그먼트 데이터 파일 (rbs01.dbf) 과 임시 데이타 파일(temp01.dbf) 의 크기는 각각 300M~500M 정도 필요합니다. 현 시점에서 rbs 는 30M , temp 는 25M 정도로 활당 되어져 있습니다. 시스템 운영시 여러가지 문제의 원인이 됩니다.

10. 리두 로그 파일의 상태

MEMBER                                   GROUP#     STATUS           BYTES

———————————————————————————————-

/home/oracle/product/8.1.5//oradata/onnoffdb/redo01.log      1 CURRENT             1024000

/home/oracle/product/8.1.5//oradata/onnoffdb/redo02.log      2 INACTIVE            1024000

정상적인 오라클 운영상 리두로그 파일은 3개~5개 정도가 필요하며 로그 파일의 크기 역시 2M ~5M 정도 되어야 무난한 처리를 할수 있습니다. 현 시스템에서는 1M 짜리 로그파일이 2개가 있는데 그중 하나만 동작중입니다.

이역시 문제의 원인이 됩니다.

다음과 같은 체크 결과 가 나왔습니다.  

튜닝후 결과 값입니다. 참고 하시길..

1. 데이타 버퍼 캐쉬 영역

hit ratio = 68%

2. 라이브러리 캐쉬

ratio = 0.6

3. 딕션어리 캐쉬

ratio = 4.5

4. 로그 버퍼

redo log space requests = 0

5. 롤백 세그먼트

NAME                                 GETS       WAITS

—————————— ———- ———-

SYSTEM                                 52          0

R01                                     8          0

R02                                     8          0

R03                                     6          0

R04                                     6          0

ONNOFF_ROLL                            12          0

R05                                     6          0

R06                                     6          0

R07                                     6          0

R08                                     6          0

R09                                     6          0

R10                                     6          0

튜닝 작업으로 인해 위와 같은 결과를 구할수 있었습니다.

튜닝 작업은 고정된 시스템 환경에서  항상 변화가 일어나는 프로그램을

제대로 돌아가게 하기 위해 시스템과 프로그램의 설정을 변경하여 완충지점

을 찾는 거라고 보시면 될것입니다. 지속적인 시스템 모니터링과 프로그램

의 성능치를 파악하여 문제가 일어나기 전에 대비해야 합니다.

그럼…