by-nc-sa     개발자, DBA가 함께 만들어가는 구루비 지식창고!

테스트환경을 구축하라




  • 테스트 환경 구축의 필요성
    (1)애플리케이션의 성능을 평가한다. 요청된 부하(사용자 수)르 수용할 수 있는지를 테스트하고,
    요구된 응답 시간 내에 부하를 처리할 수 있는지르 테스트한다. 후자가 보다 중요하다.
    (2)수정된 부분이 실제로 동작하는지,
    특히 시스템의 나머지 부분과 연동하여 동작하는지와 이들이 개선보다는 개악되지 않았는지를 확인한다.
    (3)개발 환경에서 작업한 업그레이드 스크립트가 올바르게 동작하는지를 확인한다.
    실제로 최종 릴리스를 이용하여 프로덕션을 업그레이드할 수 있는지를 확인한다.
    (4)패치 업그레이드, 주요 버전 릴리스, 운영체제 패치 등과 같은 주요 작업이 시스템을 망가뜨리지 않도록 확인한다.
  • 가장 바람직한 테스트 시스템은 대상 시스템과 동일해야 한다.
  • 테스트 시스템을 개발하면서 염두에 두어야 할 사항
    (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여 개의 다른 프로그램과 동시에 실행해야 한다면
    테스트 시스템에서도 이와 같은 상황을 고려하여야 한다.
  • 테스트 환경은 철저히 실제 환경을 반영하여야 한다.

문서에 대하여

문서정보

Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.