제목없음

튜닝 수행자
Oracle8 시스템에 관여하는 모든 사람(시스템 제작자, 설계자, 개발자, 데이터베이스 관리자)은 작업을 수행하는 데 있어 성능 및 튜닝에 관하여 생각해야 합니다.
문제가 발생할 경우, 처음으로 문제 해결을 시도해야 하는 사람은 일반적으로 DBA입니다.

튜닝 이유
최상의 튜닝 방법은 시스템과 애플리케이션을 신중하게 설계하는 것이며, 애플리케이션 튜닝을 통하여 대부분의 성능을 향상시킬 수 있습니다.
다음과 같은 경우에는 성능 문제가 발생할 소지가 적습니다:
      -  하드웨어가 사용자의 요구사항을 처리 할 수 있는 경우
      -  Oracle8 데이터베이스가 신중하게 설계된 경우
      -  애플리케이션 개발자가 SQL 프로그램을 효율적으로 작성한 경우
초기에 잘못된 결정을 하였거나 현재 사용자가 시스템으로부터 이전에 했던 것 보다 훨씬 많은 것을 기대할 경우, 성능 향상을 심각하게 고려해야 할 필요가 있을 것입니다. 튜닝 프로세스 처리를 연기하면 할수록, 시간 및 자원 비용이 증가하게 될 것입니다.

튜닝의 양
목적을 달성해야 하겠다는 분명한 생각을 갖고 튜닝을 시작해야 합니다. 가능하면 정확하게 현실적인 수치로 나타내야 합니다. 예를 들어:
- 하루에 10,000 건의 주문 처리
- 월말 야간에 250,000개의 계산서 청구 문 작성
본 과정에서, Oracle8 튜닝 목적이 종종 설명되고 있지만, 결국에 이들 목적은 사용자에게 이익을 줄 수 있어야 합니다. 사용자가 구형 PC로 느린 네트워크 상에서 데이터에 액세스한다면, 데이터 버퍼 캐쉬 사용을 향상시키는 것은 의의가 없습니다. 따라서, 튜닝 노력은 효과가 없게 될 것입니다.
튜닝은 반복적인 과정으로, 한번 하고 잊어 버리는 활동이 아닙니다.

Oracle8 데이터베이스 환경을 튜닝할 때, DBA는 측정가능한 튜닝 목표를 설정해야 합니다. 이러한 목표를 설정하지 않고는 충분한 튜닝 수행 시기를 결정하기가 어려울 것입니다.

응답시간은 사용자가 요청 한 후 데이터(예를 들어, 질의의 결과)를 받는데 소요되는 시간이나, 테이블을 갱신하거나 보고서를 생성하는데 소요되는 시간을 말합니다.

데이터베이스 가용성 또한 튜닝 목표의 좋은 측정기준입니다. 가용성은 백업 및 복구로 인하여 영향을 받거나 파라미터를 튜닝하기 위한 인스턴스의 종료 및 시작으로부터 영향을 받을 수 있습니다.

데이터베이스 적중 퍼센트는 시간의 경과에 따른 성능 증가나 감소를 결정하는데 좋은 기준선을 제공합니다.

또한, 과도한 페이징 및 스와핑(swapping)이 데이터베이스와 운영체제 성능에 영향을 미칠 수 있기 때문에, 메모리 이용도 효과적인 측정기준이 됩니다. 메모리 이용 또한 데이터베이스 적중 퍼센트에 영향을 미칠 수 있습니다.

Oracle8 서버 튜닝의 주요 목표는 다음을 확실하게 하는 것입니다:
      -  SQL 문이 가능한 한 최소의 오라클 블록을 액세스
      -  블록이 필요한 경우, 블록을 메모리에 캐쉬
      -  사용자들이 동일한 코드 공유
      -  코드가 필요한 경우, 코드를 메모리에 캐쉬
      -  읽기와 쓰기를 꼭 해야 하는 곳에서, 가능한 한 신속하게 수행
      -  사용자는 다른 사용자가 보유한 자원을 결코 기다리지 않음
      -  백업 및 기타 필요한 정리작업이 가능한 신속하게 수행되어야 함

튜닝 구현을 위한 권장 순서는 다음과 같습니다:

1   설계(너무 늦지 않은 경우)
2   애플리케이션
3   메모리
4   입력/출력(I/O)
5   경합(Contention)
6   운영체제

목표를 달성하지 못했다면 위의 프로세스를 반복하십시오.

이러한 구조를 사용하는 이유는 초기에 성능을 향상시키면 나중에 문제들을 처리하는 시간과 노력을 줄일 수 있기 때문입니다.

예를 들어, 애플리케이션이 많은 전체 테이블 스캔을 사용하고 있다면, 과도한 I/O를 발생시킬 것입니다. 그러나, 질의를 재작성할 수 있어 4,000 개의 블록이 아니라 단지 4개의 블록만 액세스 할 수 있다면, 버퍼 캐쉬의 크기를 재조정하거나 디스크 파일을 재분배할 필요가 없습니다.

처음 두 단계는 일반적으로 시스템 제작자와 애플리케이션 개발자의 책임이지만, DBA 또한 애플리케이션 튜닝에 관여할 수 있습니다.

SQL문을 재작성해서 4,000개의 블록을 방문하는 대신 4개의 블록을 방문하도록 할 수 있다고 하더라도 버퍼 캐쉬의 크기를 조정하거나 디스크의 파일 I/O를 분산시키는 것 보다 효율적일 수는 없다.
A. TRUE
B. FALSE
답
X 정답:B
다음 명령어의 수행에 의해 생성된 통계정보를 확인할 수 있는 자료사전은(2가지)?
ANALYZE TABLE table_name COMPUTE STATISTICS;
A. INDEX_HISTOGRAM
B. INDEX_STATS
C. DBA_IND_COLUMNS
D. DBA_INDEXES
E. DBA_TAB_COLUMNS
답
X 정답:DE
다음 중 성능 문제 발생 가능성의 최소화와 가장 관계가 적은 것은?
A. 하드웨어가 사용자의 요구를 수용하기에 충분하다.
B. 데이터베이스가 신중히 설계되어 있다.
C. 개발자가 SQL문을 효율적으로 작성하였다.
D. 튜닝 작업 시 계량화된 목표를 설정한다.
답
X 정답:D
다음 중 튜닝 목표와 관계가 없는 것은?
A. 메모리에 블록을 cache시킨다.
B. 백업 방법은 성능과 별로 관계가 없다.
C. SQL문을 공유한다.
D. 자원을 기다리지 않도록 한다.
답
X 정답:B
다음 중 튜닝 절차로서 가장 적절한 것은?
A. 설계 → 응용 프로그램 → 메모리 → 입출력 → 자원의 경합
B. 메모리 → 입출력 → 자원의 경합 → 설계 → 응용 프로그램
C. 자원의 경합 → 설계 → 응용 프로그램 → 메모리 → 입출력
D. 자원의 경합 → 입출력 → 메모리 → 응용 프로그램 → 설계
답
O
다음의 X$ 테이블에 관한 설명 중 맞지 않은 것은(두 가지)?
A. 소유자는 SYS이다.
B. 일반 사용자가 읽으려면 SELECT ANY TABLE 권한이 있어야 한다.
C. 시스템 테이블스페이스에 저장된다.
D. 동적이고 지속적으로 변경된다.
E. 시간 관련 정보는 파라미터 timed_statistics = TRUE 일 때 생성된다.
답
X 정답:BC