테스트 환경 구축의 필요성

• 애플리케이션의 성능을 평가한다. 요청된 부하(사용자 수)르 수용할 수 있는지를 테스트하고, 요구된 응답 시간 내에 부하를 처리할 수 있는지르 테스트한다. 후자가 보다 중요하다.
• 수정된 부분이 실제로 동작하는지, 특히 시스템의 나머지 부분과 연동하여 동작하는지와 이들이 개선보다는 개악되지 않았는지를 확인한다.
• 개발 환경에서 작업한 업그레이드 스크립트가 올바르게 동작하는지를 확인한다. 실제로 최종 릴리스를 이용하여 프로덕션을 업그레이드할 수 있는지를 확인한다.
• 패치 업그레이드, 주요 버전 릴리스, 운영체제 패치 등과 같은 주요 작업이 시스템을 망가뜨리지 않도록 확인한다.

가장 바람직한 테스트 시스템은 대상 시스템과 동일해야 한다.

테스트 시스템을 개발하면서 염두에 두어야 할 사항

• (1)실제 시스템의 데이터를 대표할 수 있는 데이터를 사용한다.
• (2)한 명 이상이 테스트한다.
• (3)테스트 환경은 가능한 한 대상 시스템이 운영될 실제 환경과 유사하여야 한다.

5.1 대표 데이터로 테스트하라

• 1,000개의 행을 갖고 있는 테스트 시스템에서 훌륭하게 수행되는 쿼리라 하더라도 100만 개의 행을 갖고 있는 프로덕션에서 실행된다면 악몽으로 변할 수 있다.

5.1.1 데이터 서브세팅의 사용을 고려해 보자

• 반드시 프로덕션(운영) 데이터의 100%를 테스트 시스템에 적재할 필요는 없다.
• 온라인 트랜잭션 처리(OLTP) 시스템이 파티셔닝을 이용하고 있고, 모든 쿼리가 파티션 제거를 이용하도록 조치되었다면, 각 테이블의 한두 파티션만을 적재하여 테스트할 수 있다.

5.1.2 최적화기가 시간에 따라 쿼리 계획을 바꿀 수 있다는 사실을 알아야 한다

• 대표 데이터를 사용한다고 반드시 프로덕션과 테스트 시스템의 쿼리 실행 계획이 동일하지는 않다.
• 실행 환경에 따라 쿼리 실행 계획이 달라질 수 있다.
• db_file_multiblock_read_count, db_block_size, OBJECT_ID 값이 요청된 범위 내에 있는 데이터베이스 객체의 수와 같은 개별 설정 내용에 따라 결정된다(6장 참조) 또한 사용된 범위의 값에 따라서도 다른 실행 계획이 수립된다.

(1)실습 준비

-- 물리적인 순서 없이 적재된 테이블
create table clustered ( x int, data char(255) );

insert /*+ append */ into clustered (x, data )
  select rownum
        ,dbms_random.random
    from all_objects;

alter table clustered
  add constraint clustered_pk primary key (x);

analyze table clustered compute statistics;

-- 물리적인 순서(기본 키)로 적재된 테이블
create table non_clustered ( x int, data char(255) );

insert /*+ append */ into non_clustered (x, data)
  select x
        ,data
    from clustered
   order by data;

alter table non_clustered
  add constraint non_clustered_pk primary key (x);

analyze table non_clustered compute statistics;

select index_name
      ,clustering_factor
  from user_indexes
 where index_name like '%CLUSTERED_PK';

show parameter optimizer_index

create role plustrace;
grant select on v_$sesstat to plustrace;
grant select on v_$statname to plustrace;
grant select on v_$session to plustrace;
grant plustrace to dba with admin option;
set echo off
grant plustrace to sys;
@C:\oracle\ora92\rdbms\admin\utlxplan.sql
set timing on
set autotrace traceonly explain

(2) 실습1(db_file_multiblock_read_count = 4)

show parameter db_file_multi

select *
  from clustered
where x between 50 and 2500;

(3)실습2(db_file_multiblock_read_count = 128)

alter session set db_file_multiblock_read_count = 128;

show parameter db_file_multi

select *
  from clustered
where x between 50 and 2500;

(4)실습3(db_file_multiblock_read_count = 4,조회 범위 조정)

alter session set db_file_multiblock_read_count = 4;
select *
  from clustered
where x between 50 and 10000;

• (5) 소규모 데이터베이스를 대상으로 튜닝하면서 테이블 전체 스캔을 피하기 위하여 강제로 인덱스르 사용하도록 했다면 프로덕션 시스템의 성능이 심각하게 저하되었을 것이다.

5.2 단일 사용자 환경에서 테스트하지 말라

• "실제 상황"에서와 같이 많은 세션이 동시에 데이터를 액세스하는, 어느 정도 부하가 있는 환경에서 애플리케이션을 테스트할 필요가 있다.

5.3 먼지가 없는 연구실에서 테스트하지 말라

• 애플리케이션을 실제 시스템에서 실행할 때에 50여 개의 다른 프로그램과 동시에 실행해야 한다면 테스트 시스템에서도 이와 같은 상황을 고려하여야 한다.
• 테스트 환경은 철저히 실제 환경을 반영하여야 한다.