운영체제 튜닝을 책임지는 사람인 시스템 관리자는 데이터베이스 관리자가 갖고 있는 걱정과 비슷한 튜닝 걱정을 갖고 있습니다. 그러나 시스템 관리자는 또한 비오라클 애플리케이션이 어떻게 성능에 영향을 미치는가에 대해서도 걱정을 합니다. 튜닝을 할 때, 시스템 관리자가 고려하는 사항은 다음과 같습니다:

• CPU 사용
  
• 메모리 사용
  
• I/O 레벨
  
• 네트워크 트래픽

CPU 구성
단일 CPU컴퓨터 이외에도, 다른 2가지 CPU 구성 방법이 있습니다.

• SMP: Symmetrical Multi-Processor(대칭 멀티프로세서) 또는 강결합(tightly-coupled) 프로세서.
  이 구성 방법에서는, 여러 CPU가 단일 메모리 공간을 공유하고, 이 단일 메모리 공간에서 CPU 들은 I/O 장치를 공유합니다.
  
  오라클은 여러 백그라운드 프로세스와 서버 프로세스를 사용하기 때문에, SMP 구성에서 복수  CPU를 효과적으로 사용할 수 있습니다. 이 구성 방법에서, 병렬 질의 또한 멀티 프로세서를 이용할 수 있습니다.
• MPP: Massively Parallel Processor(대량 병렬 프로세서) 또는 약결합(loosely-coupled) 프로세서.
  이 구성 방법에서는, 여러 CPU 단위가 있으며, 각 CPU 단위는 고유 메모리 공간을 갖고 있습니다. 이때, 각 CPU 단위는 하나의 SMP일 수 있습니다. I/O 장치는 단일 CPU에 의해 소유되거나 여러 CPU들에 의해 공유될 수 있습니다.
  
  메모리 공간이 여럿이기 때문에, 각 메모리 공간에서 오라클 인스턴스를 실행시키는 것이  가능합니다. 모든 인스턴스가 동일한 데이터베이스에 액세스하게 하기 위해서는 Oracle  Parallel Server 옵션을 설치해야 합니다. 이 옵션이 없을 경우에, 각 인스턴스는 고유 데이터베이스를 갖고, 구성은 분산 데이터베이스와 비슷합니다.

이 두 가지 구성 방법 모두에서, 운영체제나 하드웨어, 또는 운영체제와 하드웨어 모두는 메모리나  I/O 장치 사용을 위해 발생하는 CPU 경합을 관리합니다.

Guidelines
CPU 사용도를 튜닝할 때, 시스템 관리자가 주로 걱정하는 사항은 다음과 같습니다:

• CPU 자원이 충분한가?  시스템 관리자는 CPU를 너무 많이 사용하지 않도록 해야 합니다. 일반적인 규칙으로서, CPU가 시간의 90% 정도 사용되었다면, 이미 한계용량에 이른  것입니다.
  
  
• 운영체제 처리와 애플리케이션 처리 간의 비율이 적합한가?  운영체제 처리에는  애플리케이션에 대해 운영체제가 처리하는 작업이 포함됩니다. 예를 들면 다음과 같습니다:
  
  -  장치를 읽고 쓰기, 프로세스간에 메시지 전송, scheduling 프로세스
  
  목표는 운영체제 작업 수행에 CPU 시간의 25?40% 이상을 초과하지 않고, CPU 시간의 나머지   60-70%를 애플리케이션 실행에 사용하는 것입니다. 운영체제 작업 수행에 시간을 적사용할수록, 성능은 더 좋아집니다. 운영체제 모드에 너무 많은 시간을 사용한다면, 다음과  같은 근본적인 문제를 발생시킬 수 있습니다:
  
  -  스와핑과/또는 페이징을 유발시키는 메모리 부족, 또는
  
  -  너무 많은 운영체제 호출을 일으키는 잘못된 애플리케이션 설계
  
  
• 또한, 멀티프로세서 시스템에 대해, 시스템 관리자는 특히 특정 CPU사용이 높을 경우, 모든 CPU 간에 CPU 로드가 균형이 잡혀 있는지 확인해야 할 필요가 있습니다.

이것이 일반적인 Guidelines입니다. 실제 숫자는 하드웨어 플랫폼과 운영체제에 따라 다를 것입니다. 추가 정보를 위해서는 사용중인 하드웨어와 운영체제 튜닝 안내서를 참조하십시오.

감시
CPU 사용도에 대한 운영체제 감시 내용에는 CPU가 활동중인 시간에 대한 퍼센트와 운영체제 대 사용자 작업에 사용된 시간이 포함됩니다. 프로세스 모니터는 프로세스 상태 및 I/O 수에 대한 통계, 운영체제 호출, 페이지/스왑 비율을 나타냅니다.

프로세스와 쓰레드
대부분의 운영체제에서, 각 오라클 프로세스는 또한 운영체제 프로세스이기도 합니다. 그러나, Windows NT와 같은 일부 운영체제 하에서, 모든 오라클 백그라운드 프로세스와 서버 프로세스는 단일 운영체제 프로세스로서 실행됩니다.

각 오라클 프로세스는 운영체제 프로세스 내의 쓰레드입니다. 쓰레드는 동일한 프로세스에서 다른 쓰레드와는 독립되어 실행될 수 있는 일련의 명령어입니다. 이러한 구성으로 오라클 프로세스 간에 이루어지는 SGA 액세스와 통신을 보다 효율적으로 만들 수 있습니다.

시스템은 가장 최근에 사용된 페이지를 실제 메모리에 보관하려고 하려는 것과 동일한 기법을 사용하여 메모리를 관리합니다. 메모리 자원이 불충분할 경우, 너무 많은 페이징이나 스와핑이 발생하게 됩니다. 이러한 증상은 메모리와 디스크 간에 블록 이동을 유발하기 때문에 종종 “쓰래싱(thrashing)”이라 불립니다.

페이징은 프로세스가 더 이상 실제 메모리에 존재하는게 아니라 가상 메모리에 존재하는 메모리의 페이지(블록)를 필요로 할 때 발생합니다.  블록은 디스크로부터 읽혀져야(페이지되어야) 하며 대체되는 메모리에 있는 블록은 또한 디스크에 쓰여질 필요가 있을 것입니다.

스와핑(swapping)은 전체 프로세스의 메모리 공간이 메모리에서 제거되는 것을 제외하고는 페이징과 유사합니다. 한번에 너무 많은 프로세스가 실행되면, 스와핑은 받아들이기 힘든 레벨까지 증가할 것입니다.

스와핑과 페이징 모두 메모리 블록을 디스크에 일시적으로 보관하기 위하여 충분한 디스크 공간을 필요로 합니다. 이들 파일은 I/O에 집중적이기 때문에, I/O의 균형을 잡을 때 고려될 필요가 있습니다. 스와핑은 모든 운영체제에 의해 이루어 지는 것은 아닙니다. NT는 페이징만 사용하고 스와핑은 사용하지 않습니다. 

DB 튜닝이 페이징에 영향을 미친다
SGA를 튜닝하는 것 이외에도, DBA가 할 수 있는 것(페이징/스와핑 성능에 영향을 미치는 것)들이 있습니다:

• DBA는 init.ora 파라미터 PRE_PAGE_SGA를 TRUE로 설정하여 데이터베이스의 초기 성능을 향상시킬 수 있습니다. 이것으로 오라클은 모든 SGA 페이지에 액세스하고 인스턴스 시작 동안 이들 페이지를 메모리로 가져올 수 있습니다. 그 결과, 인스턴스 시작 시간이 증가하지만, 그 후 곧 발생할 페이지 장애의 수를 감소시킬 수 있습니다. 페이지 장애의 감소로 인스턴스는  빨리 최대 성능을 발휘할 수 있습니다.
  
  
• 일부 운영체제에서, DBA는 SGA를 실제 메모리에 잠글(lock) 수 있기 때문에 SGA는 디스크로   결코 페이지되지 않습니다. 일반적으로, 전체 SGA가 실제 메모리에서 유지될 경우, 오라클의  수행 능력은 향상됩니다.

이 두 가지 기법 모두 다른 영역에서 성능을 저하시키지 않으면서, 모든 SGA 페이지를 보유하는데 충분한 메모리를 갖고 있는 시스템에서만 사용되어야 합니다.

메모리 사용 감시
실제 메모리 및 가상 메모리 사용도와 페이징 및 스와핑은 일반적으로 프로세스에 대해 또는 전체 운영체제에 대해 감시될 수 있습니다. 허용되는 페이징과 스와핑의 수는 운영체제에 따라 다릅니다. 일부 운영체제는 다른 운영체제보다 높은 수를 허용합니다.  

I/O튜닝
시스템 관리자는 전체 디스크와 디스크 컨트롤러에 대한 로드의 균형을 잡아 디스크 I/O 성능을 향상시킵니다.

데이터베이스 서버와 같이 I/O에 집중되는 시스템은 수는 적지만 크기는 큰 디스크 보다는 수는 많지만 크기는 작은 디스크를 사용할 경우 수행능력이 더 뛰어납니다. 더 많은 디스크를 사용할 때가 디스크 병목현상이 일어날 확률이 적습니다.  병렬 질의 작업 또한 여러 디스크 드라이브에 I/O 워크로드를 분배하기 때문에 이점이 있습니다.

원시 장치(Raw Devices)
원시 장치는 파일이나 디렉토리 구조가 없는 디스크 또는 디스크 파티션을 말합니다. 이들은 운영체제 파일보다 관리하기 어렵지만, 원시 장치의 읽기 및 쓰기가 운영체제 캐쉬를 사용하지 않기 때문에 성능면에서 여러 이점이 있습니다.

감시
I/O 성능 통계에는 일반적으로 읽기 및 쓰기 횟수, 초당 읽기 및 쓰기, I/O 요청 큐 길이가 포함되어 있습니다. 허용되는 로드는 장치와 컨트롤러에 따라 다릅니다. 

전체 시스템 튜닝
튜닝이 잘된 시스템을 갖기 위해서는, 운영체제, 데이터베이스, 애플리케이션 모두를 튜닝해야 합니다. 운영체제나 데이터베이스는 잘못 작성된 애플리케이션 때문에 잘못 수행될 수 있습니다.

예를 들어, 애플리케이션은 전체 테이블 스캔을 많이 수행합니다. 전체 테이블 스캔은 시스템 I/O를 증가시켜 데이터베이스 버퍼 캐쉬 통계에 부정적인 영향을 미칩니다. 개발자는 인덱스를 추가하여 애플리케이션을 튜닝합니다. 전체 테이블 스캔을 줄이면 데이터베이스를 더 효과적으로 사용하고 운영체제 I/O 횟수를 감소시킬 수 있습니다.

오라클 통계를 사용한 운영체제 튜닝
시스템 관리자는 데이터베이스 관리자가 제공하는 정보를 사용하여 운영체제를 튜닝할 수 있습니다.. 예를 들어, V$FILESTAT의 I/O 통계는 I/O의 균형을 잡기 위하여 이동시킬 데이터 파일을 결정하는데 사용될 수 있습니다.

초기화 파라미터는 성능에 간접적으로 영향을 미친다
튜닝에 직접 영향을 미치는 init.ora 파라미터 이외에도 성능에 간접적으로 부정적인 영향을 미치는 파라미터들이 있습니다. 예를 들어, DB_BLOCK_CHECKSUM이나 LOG_BLOCK_CHECKSUM을 TRUE로 설정할 경우, 체크섬(checksum) 계산은 CPU에 집중된 작업이기 때문에 CPU 성능에 부정적인 영향을 미칩니다.

하드웨어 요구 감소  
시스템 설계자는 다음을 통해 서버 하드웨어 요구를 감소시킬 수 있습니다:

• 한가한 시간대로 로드를 재분배
  
• 애플리케이션 분할(partitioning)을 통해 다른 하드웨어 계층으로 오프로드 작업

하드웨어 자원의 규모 조절
하드웨어 자원이 최대 용량에 이르렀을 때, 병목현상이 발생할 수 있습니다. 일부 경우에, 시스템은 새로운 하드웨어를 추가한 후 튜닝을 필요로 합니다. 예를 들어, 디스크 드라이브가 추가되었을 때, I/O는 재분배되어야 합니다. 그러나, 튜닝이 항상 필요한 것은 아닙니다. 예를 들어, 새로운 CPU가 SMP 프로세서에 추가되었을 때, 시스템은 즉시 추가 CPU 자원을 사용할 수 있습니다. 튜닝이 요구되지 않더라도, 시스템은 여전히 재튜닝할 필요가 있을 것입니다. DBA는 추가 프로세서를 사용해서 추가 CPU를 사용하기 위하여 병렬 질의 프로세스를 튜닝하기를 원할 것입니다.

기타 참조

• 튜닝에 관한 추가 정보에 대해서는 오라클의 특정 플랫폼 문서, 운영체제 문서, 오라클 터치포인트 클래스를 참조하십시오. UNIX에 대해서는 Oracle7 UNIX Perfoamance Tuning Tips 설명서를 참조하십시오.
   
• RAID 기법에 관해서는 UNIX touchpoint 과정이나 Appendix D를 참고하십시오.