Tuning Oracle8 on LINUX

1.최적화의 중요성 (The Importance of Tuning)

Oracle8은 상당히 최적화되어 있는 소프트웨어 제품이다. 종종 튜닝을 통해 시스템 퍼포먼스를 최적화 하고 자료 병목현상을 막아야 한다. 비록 이 장에서는 단일 프로세서 (single-processor) 시스템을 기준으로 기술되어 있지만, 오라클의 병렬 옵션을 이용하는 시스템에 관한 대부분의 퍼포먼스 튜닝 팁도 여기서 제공된다.

2. 시스템을 튜닝하기 전에 (Before Tuning the System)

시스템을 튜닝하기 전에, 다음장의 "LINUX Tools"에 기술된 리눅스 툴의 정상적인 동작법을 익혀 두어야 한다.

See Also:

Oracle8 병렬 서버 개념과 관리 (Oracle8 Parallel Server Concepts and Administration).
Oracle8 Tuning.

3. LINUX Tools

리눅스는 데어터베이스 접근의 퍼포먼스를 관찰하고 요구되는 데어터베이스를 결정하는 등의 퍼포먼스 모니터링 툴을 제공한다.

oracle process들의 통게를 제공할 뿐만아니라, 이들은 CPU 이용률, 인터럽트, 스와핑, 페이징, 그리고 전체 시스템을 위한 context switching 등에 대한 통계도 제공한다.

See Also:

리눅스 톨들은 운영체계 문서에 기술되어 있다.

4. vmstat

vmstat 유틸리티는 리눅스 상에서 process, virtual memory, disk, paging, CPU 활동도 등을 알려준다. 다음 문장은 시스템 활동도에 대한 요약을 5초 간격으로 8번 보여 준다:

% vmstat -n 5 8


vmstat 명령의 예제 출격이 다음 Figure 3-1에 보여주고 있다.

w column (procs 아래의)은 swap out(디스크로 쓰여진) 되어져 나간 프로세스의 수를 의미한다. 만약 값이 0이 아니라면, 스와핑이 일어 났다는 것을 의미하여 여러분의 시스템은 메모리 부족이 있다는 것을 의미한다. si와 so columns은 각각 초당 swap-ins과 swap-outs의 수를 표시한다. Swap-outs은 거의 항상 0일 것이다.

Figure 3-1 Output from the vmstat -n command
procs                  memory    swap        io    system        cpu
r b w  swpd  free  buff cache  si  so  bi  bo  in  cs  us  sy  id
0 0 0 16124  964  524 29904  2  14  13  21  208    3  9  4  87
1 0 0 16124  648  524 30140  0  0    1    0  806 1763  5  8  87
1 0 0 16124  608  524 29904  0  0    0    0  856 1894  5  7  87
0 0 0 16124  612  524 29624  0  0    0    5  734 1586  5  8  88
2 0 0 16124  1656  520 28296  0  0  221    0  687 1395  14  10  77
0 0 0 16124  840  520 29060  0  0  38    0  621 1287  3  4  93
0 0 0 16124  856  520 29196  0  0    0    0  647 1395  4  6  91
1 0 0 16124  708  520 29288  0  0    1    0  618 1287  3  4  93


free
free utility는 스왑 공간 이용률에 관해 알려준다. 스왑공간이 모자랄 경우 시스템이 중단되던지 응답시간이 느려지게 된다.

SQL Scripts
utlbstat 와 utlestat SQL Scripts
utlbstat 와 utlestat SQL scripts는 오라클 데이터베이스 퍼포먼스와, Shared Global Area (SGA) 자료구조를 모니터 하는데 이용되는 프로그램이다. 이 스크립트에 관한 정보는 Oracle8 Server Tuning를 참조하기 바란다. 리눅스상에서, 이 스크립트는 $ORACLE_HOME/rdbms/admin/에 위치해 있다.

4. 메모리 관리 튜닝하기 (Tuning Memory Management)

얼마나 많은 메모리 공간이 필요한지 결정하기 위해서 스와핑과 페이징 공간을 튜닝하는 것으로 메모리 튜닝과정을 시작한다.

오라클 buffer manager는 좀더 자주 접근하는 자료가 좀더 오랫동안 캐시 되어 있도록 되어 있다. Buffer manager와 buffer cache를 모니터링 하는 것은 오라클 퍼포먼스에 상당한 영향을 미친다. 여러분들의 시스템에서 적절한 오라클 버퍼 사이즈는 전반적인 시스템의 부하와 다른 응용프로그램들에 대한 오라클의 상대적인 우선순위의 정도에 달려 있다.

충분한 스왑 공간을 할당하라
스와핑은 리눅스에서 상당한 overhead의 원인이 되기 때문에 최소화 시켜야 한다. 스와핑을 점검하기 위하여 다음 유틸리티들을 이용한다.
free 또는 vmstat -n

만약 여러분들의 시스템이 스와핑이 일어나고 메모리를 유지할 필요가 있다면:

불필요한 시스템 데몬 프로세스 응용프로세스 등을 실행시키지 마라.
어느정도 빈 메모리를 확보하기 위하여 데이터베이스 버퍼 크기를 줄여라.
리눅스 파일 버퍼의 수를 줄여라. 특히 raw 장치를 이용하고 있다면.
스왑공간을 추가하는 것은 구현된 리눅스에 따라 조금씩 다르다. 리눅스상에서 얼마나 많은 스왑 공간이 현재 남아 있는지를 결정하려면 free 유틸리티를 이용한다. 보다 자세한 정보는 리눅스 문서를 참조하기 바란다.

스왑공간의 크기는 여러분들의 RAM 메모리의 2-4배로 시작하라. CASE, 오라클 응용 프로그램 또는 오라클 오피스를 이용하려면 좀더 많은 공간을 필요로 한다. 스왑공간의 사용을 모니터 하다가 필요하다면 스왑공간을 증가시키도록 한다.

Control Paging
프로그램이 실행하기 위해서 전체 프로그램이 모두 다 메모리에 상주하지는 않기 때문에, 페이징(Paging)은 스와핑만큼 심각한 문제로 나타나지는 않는다. 약간의 page-outs은 여러분들의 시스템 퍼포먼스에 유의하게 영향을 미치지는 않는다.

과다한 페이징을 발견하기 위해서, 반응속도가 빠를때 measurements를 실행시켜 두었다가 반응속도가 느려 졌을 때와 비교하도록 한다.

페이징을 모니터하기 위해서 vmstat 또는 free를 이용하도록 하라. vmstat 출력 중 다음 컬럼은 중요하다:

vflt/s는 page fault가 나타난 주소변환의 수를 가르킨다. Address translation faults는 프로세스가 참조하고자 하는 주소페이지가 메모리 내에 있지 않을 때 발생한다.
rclm/s는 page-out activity에 의해 free list에 추가되고 개정된 유효한 페이지를 말한다. 이 값은 대체로 0이 된다.
만약 여러분들의 시스템이 너무 많은 page-out activity를 보이면, 다음과 같은 해결법을 생각해 보라:

메모리를 증설하라.
일부 작업을 다른 시스템으로 이동하라.
여러분들의 커널을 메모리를 적게 사용하도록 설정하라.
SGA를 단일 공유메모리 세그먼트내에 유지하라.
비록 퍼포먼스상의 이득은 미미하지만, 충분한 공유메모리를 확보하도록 설정하지 않고서는 데이터베이스를 시작할 수 없다.

여러분들은 리눅스 커널의 공유메모리를 증가시키도록 다시 재설정할 필요가 있다. 공유메모리를 위한 리눅스 커널 인자는 SHMMAX, SHMMNI, 그리고 SHMSEG이다. SGA가 단일 공유메모리 세그먼트내에 상주하도록 하려면 SHMAX를 4294967295 (4 GB)로 설정해야 한다.

SGA의 크기는 다음과 같은 단계를 거쳐서 측정할수 있다:

DB_BLOCK_BUFFERS 과 DB_BLOCK_SIZE를 곱하라.
Step 1의 결과를 SORT_AREA_SIZE에 더하라.
Step 2의 결과를 SHARED_POOL_SIZE에 더하라.
Step 3의 결과를 LOG_BUFFER에 더하라.
공유메모리의 상태를 모니터링하기 위하여 리눅스 유틸리티인 ipcs를 이용할 수도 있다.

참조 :

Oracle8 Installation Guide for LINUX의 chapter 2에 있는 "오라클을 위한 리눅스 커널의 설정".

 
5. 디스크 입출력 튜닝하기 (Tuning Disk I/O)

I/O 병목현상은 가장 쉽게 찾을수 있는 실행상의 문제점이다. 균형잡힌 I/O는 결국 전체 모든 이용가능한 디스크상에서 디스크 접근 시간을 줄이는 것이다. 작은 데이터베이스와 병렬 질의 옵션을 사용하지 않는 곳에서는, 데이타 파일이 다를 경우 테이블스페이스가 이용가능한 디스크 공간내에 분산되어 있는지 확인하도록 한다.

쓰기 대역폭을 넓히기 위해 데이터베이스 Writer를 튜닝하라.
오라클은 database writer (DBWR)가 병목현상을 가지지 않도록 해법을 요구한다:

비동기 입출력(asynchronous I/O)을 이용하라.
I/O slaves를 이용하라.
비동기적 입출력 (Asynchronous I/O)
비동기 입출력 (Asynchronous I/O)은 프로세스들이 쓰기를 하고 난후 기다리지 않고 바로 다음 작업으로 진행하도록 해준다. 그렇기 때문에 시스템 퍼포먼스를 높이고 idle time을 줄일수 있게 해 준다. Solaris는 저수준 (raw) 또는 파일 시스템 (filesystem) 데이터 파일 둘다에 대한 비동기 입출력을 지원해 준다.

I/O Slaves
I/O Slaves는 기능이 입출력만을 수행하는 아주 특이화 되어 있는 프로세스이다. Oracle8에서는 처음 등장하는 것이며, 다중 DBWRs (다른 프로세스들 뿐만 아니라)를 대치할수 있다. (사실 multiple DBWRs의 일반적인 형태이며, 다른 프로세스에 의해서 이용될 수도 있다) 그리고 비동기 입출력이 이용할수 있든지 없든지간에 작동한다. I/O Slaves는 그들이 운영하는 중에 조절을 허용하는 초기화 인자를 제공한다. 그들은 Table 3-1에 기술되어 있다.

Table 3-1 I/O Slaves를 위한 초기화 인자
Parameter  Range of Values  Default Value 
DISK_ASYNCH_IO

  TRUE/FALSE

  TRUE

 
TAPE_ASYNCH_IO

  TRUE/FALSE

  TRUE

 
BACKUP_DISK_IO_SLAVES

  TRUE/FALSE

  FALSE

 
BACKUP_TAPE_IO_SLAVES

  TRUE/FALSE

  FALSE

 
DBWR_IO_SLAVES

  0 - 999

  0

 
LGWR_IO_SLAVES

  0 - 999

  0

 
ARCH_IO_SLAVES

  0 - 999

  0

 
DB_WRITER_PROCESSES

  1-10

  1

 

비동기 입출력이 필요하지 않든지 또는 불가능할 경우가 있다. Table 3-1에 있는 처음 두개의 인자, DISK_ASYNCH_IO 와 TAPE_ASYNCH_IO은 디스크와 테이프 디바이스에 대해서 비동기 입출력을 허용할 것인지를 설정하는 것이다. 각각의 프로세스 형에 따라 I/O Slaves의 수는 기본적으로 0으로 설정되기 때문에 특별히 설정을 하지 않으면 I/O Slaves를 이용하지 않는 것으로 간주한다.

DBWR_IO_SLAVES는 ASYNC I/O (즉 DISK_ASYNCH_IO 또는 TAPE_ASYNCH_IO)가 비활성화 되어 있는 경우에만 0보다 큰 값으로 설정된다. 그렇지 않을 경우 DBWR에 병목현상이 나타나게 될 것이다. 이와 같은 경우 리눅스에서 DBWR_IO_SLAVES의 적절한 값은 4 정도가 된다. LGWR_IO_SLAVES가 설정된 경우 9 slaves 이상 설정할 것을 권하지 않는다.

DB_WRITER_PROCESSES는 DB_WRITER인자를 대치한 것이다. 그리고 하나의 인스턴스에 대하여 데이터베이스 writer process의 초기 갯수를 명시하도록 한다. 만약 여러분들이 DBWR_IO_SLAVES를 이용한다면, DB_WRITER_PROCESSES가 어떻게 설정되던지 간에 단지 하나의 데이터베이스 writer process가 이용될 것이다.

6. Monitoring Disk Performance

디스크 퍼포먼스를 모니터 하기 위하여, vmstat.를 이용하라.

디스크 퍼포먼스를 위해 눈여겨 봐야 할 vmstat 컬럼은, 블럭 입출력(blocked I/O)을 위해 CPU가 대기하는 시간의 퍼센티지를 나타내는 %wio이다.

주요 인디케이터는 (Key indicators):

bread, bwrit, pread 와 pwrit의 합계는 디스크 입출력 서브시스템(disk I/O subsystem)의 상태를 가르킨다. 이 합계가 더 클 수록, 디스크 입출력 병목현상의 가능성은 더 커진다. 물리적으로 디스크의 갯수가 많을 수록, 더 큰 역치값(threshold number)을 가지게 될 것이다. 적당한 값은 두개의 드라이브에 대해서는 40을 넘지 않도록 하고, 4개 내지 8개의 드라이브일때는 기본값이 60을 넘지 않도록 해준다.
%rcache는 90보다 크야 하며, %wcache는 60 보다 크야 한다 그렇지 않을 경우 시스템의 디스크 입출력은 한계점에 온 것이다.
만약 %wio는 지속적으로 20이상라면 시스템의 디스크 입출력은 한계점에 온것이다.
디스크 퍼포먼스 문제점 (Disk Performance Issues)
오라클 블럭 사이즈는 macht disk block size (?)이던지 또는 multiple of disk block size 일 것이다.

만약 가능하다면, 데이터베이스 파일로 이용하기 전에 파일시스템 점검을 하라. 그러고 나서 깨끗하고 절편난 부분이 없다는 것을 확인하고 나서 새로운 파일 시스템을 만들어라. 분산 디스크 입출력에서 데이터 베이스 파일과 분리된 로그 파일을 만들고 그리고 될수 있는 한 고르게 입출력이 일어나도록 분배해야 한다.


7. CPU 이용률의 튜닝 (Tuning CPU Usage)

모든 오라클 사용자/프로세스 들을 같은 우선순위에 유지하라.
오라클은 모든 사용자들과 백그라운드 프로세스들이 같은 우선순위에서 동작하도록 설계되어 있다. 우선 순위를 변경할 경우 내용과 반응시간에 원치않는 효과를 초래할 수도 있다.

예를 들면, 만약 log writer process (LGWR)에 낮은 우선순위를 부여할 경우, 이 프로세스는 충분한 횟수만큼 동작하지 못하고 LGWR은 병목현상을 일으키게 된다. 다른 한편, 만약 LGWR이 높은 우선순위를 부여받게 되면, 사용자 프로세스들은 느린 반응시간에 시달리게 될 것이다.

다중 프로세서 시스템에서 프로세스의 결합과 친화력 이용하기
(Use Processor Affinity/Binding on Multi-Processor Systems)
Multi-processor 환경에서는, 만약 여러분들의 시스템에서 이용가능하다면 프로세스의 affinity/binding을 이용하도록 하라. 프로세스 바인딩은 사용자 프로세스(process)가 한 CPU에서 다른 곳으로 이동해 가는 것을 방지한다. 이리하여 CPU cache를 더옥 더 효율적으로 이용할수 있도록 해준다. 서버 shadow process들은 항상 활성화 되어 있으며 CPU 사이를 뜨 돌아 다니기 때문에 bind를 이용할 수 있다. 어떤 플랫폼에서는 process binding을 자동으로 실행해 주기도 한다.

대형 Exports/Imports 와 SQL*Loader 작업을 위해 Single-Task Linking을 이용하기
(Use Single-Task Linking for Large Exports/Imports and SQL*Loader Jobs)
만약 여러분들이 사용자와 Oracle8사이에 대형의 자료를 전달할 필요성이 있을 경우 (예를 들면, export/import)를 이용할 때), single-task architecture를 이용할 경우 아주 효율적이다. Import (impst), export (expst), 그리고 SQL*Loader (sqlldrst) 실행파일을 single task로 만들기 위해서는 ins_rdbms.mk makefile을 이용하도록 하라. 이것은 $ORACLE_HOME/rdbms/lib directory에서 찾을 수 있다.

다음 예제는 impst, expst 그리고 sqlldrst 실행파일을 만든다:

% cd $ORACLE_HOME/rdbms/lib
% make -f ins_rdbms.mk expst impst sqlldrst




----------------------------------------------------------------------
----------
주의:

Oracle 실행파일을 single-task로 연결하면 사용자 프로세스가 바로 전체 SGA로 접근할 수 있어야 한다. 게다가, single-task 실행은 oracle 실행 text가 frontend와 backend 사이에서 더 이상 공유되지 않기 때문에 보다 많은 메모리를 요구한다.

 
----------------------------------------------------------------------
----------


8. 오라클 자원 경쟁의 튜닝 (Tuning Oracle Resource Contention)

리눅스 커널 인자의 튜닝 (Tune LINUX Kernel Parameters)
여러분들은 될 수 있는 한 리눅스 커널을 작게 유지 함으로서 퍼포먼스를 향상시킬수 있다. 리눅스 커널을 일반적으로 물리적 메모리를 미리 할당한다. 그리고 나서 oracle과 같은 다른 프로세스들이 메모리 사용을 제한하게 된다.

전통적으로, NBUF, NFILE, 그리고 NOFILES 와 같은 커널 인자들이 커널 크기를 맞추기 위하여 사용되었다. 그러나 리눅스에서는 이들 인자를 실행시에 동적으로 조절하도록 되어 있으며, 심지어 리눅스 설정파일에도 존재한다.

메모리에 사상되어진 video driver, network driver, disk driver를 보자. 이들은 종종 설치되지 않아도 된다. 그럴 경우 다른 프로세스들에게 보다 많은 메모리를 할당할 수 있다.


----------------------------------------------------------------------
----------
경고:

여러분들의 리눅스 커널 복사본 backup을 만들어라. 보다 자세한 것은 여러분들의 하드웨어 판매처의 문서를 참조하라.

 
----------------------------------------------------------------------
----------





블럭 크기와 파일 크기의 튜닝 (Tuning Block Size and File Size)


----------------------------------------------------------------------
----------
경고:

블럭 크기를 변경하기 위해선, 새로운 데이터베이스를 만들어야 한다. 가장 효율적인 설정을 결정하기 위하여, 여러분들의 데이터를 새로운 데이터베이스를 전송함으로서 새로운 블럭 크기를 가지고 실험해 봐야 한다.

 
----------------------------------------------------------------------
----------





오라클 블럭 크기의 명시 (Specifying Oracle Block Size)
리눅스상에서, 기본적인 오라클 블럭 사이즈는 2 KB이며 최대 블럭 크기는 16 KB이다.

여러분들은 실제적인 블럭 크기를 2KB에서 시작하여 2의 배수로 16KB까지 설정가능하다.

기본적으로 주어진 값은 일반적으로 적절한 블럭 크기다. 그러나 응용프로그램에 따라 달라질 수 있다. 다른 오라클 블럭 사이즈를 가진 데이터베이스를 생성하기 위해서 다음 줄을 initsid.ora file에 추가하라:

db_block_size=new_block_size

9. 리눅스 버퍼 캐시 사이즈 튜닝 (Tuning the LINUX Buffer Cache Size)

Raw device의 이점을 최대한 살리기 위해서, Oracle8 buffer 캐쉬의 크기를 조절하라. 만약 메모리가 제한된다면 리눅스 버퍼 캐시의 크기를 조절하라.

리눅스 버퍼 캐시는 운영체계에 의해서 제공된다. 이것은 자료가 메모리에서 디스크로 전송될 때 또는 그 역 동작시 메모리 내에 data block을 유지한다.

Oracle8 buffer cache는 오라클 데이터베이스 버퍼를 저장하는 메모리 내에 있다. Oracle8이 raw device를 이용하기 때문에, 리눅스 버퍼 캐시를 이용할 필요가 없다.

Raw device로 옮길 때 Oracle8 buffer cache의 크기가 증가한다. 만약 시스템의 메모리 총량이 제한되어 있으면, 리눅스 버퍼 캐시 크기를 적절하게 줄여 준다.

리눅스 명령어 vmstat는 버퍼 캐시의 증감 결정에 도움을 준다.

10. 캐시 크기의 조절 (Adjusting Cache Size)

캐시 hit ratio가 증가 하는 한 계속 캐시 사이즈를 증가 시킨다.
만약 swapping/paging activity가 높아 지면 캐시 크기를 감소시킨다.
Trace 그리고 Alert 파일 이용하기 (Using Trace and Alert Files)
이번 장에서는 운영문제를 해결하고 진단하기 위해서 생성하는 trace (또는 dump)와 alert 파일에 대해서 기술하고자 한다.

Trace File Names
The format of a trace file name is processname_sid_pid.trc, 여기서:


Table 3-2 Format Key to Process Name
processname

  이것은 trace 파일의 Oracle8의 어느 프로세스로 부터 왔는지를 가르키는 세글자 또는 네글자의 프로세스 이름을 보여준다. (예를 들면, PMON, DBWR, ORA, or RECO)

 
sid

  인스턴스 시스템 확인자이다.

 
pid

  LINUX 프로세스 ID 번호

 
.trc

  모든 trace 파일 이름에 붙을 확장자

 



샘플 트래이스 파일 이름은 lgwr_TEST_1237.trc 이다.

Alert Files
alert_sid.log file은 데이터베이스와 연관이 있으며, initsid.ora에 있는 BACKGROUND_DUMP_DEST 파라메터에 명시된 디렉토리에 위치해 있다. 기본값은 $ORACLE_HOME/rdbms/log이다.