1.DATABASE REPLAY

• 변경에 따른 위험요소 최소화 방안 Real Application Testing의 첫번째 옵션
• 한 시스템에서 데이터베이스 Workload를 캡처하고 나중에 다른 시스템에서 Replay 할 수 있도록 지원
• 캡처 된 Workload Replay는 서로 다른 두 시스템을 비교하는데 유용
  (init 파라미터 수정, 데이터베이스 속성 변경, 패치셋 적용, 업그레이등...)

Database Replay 동작 원리

• SQL 레벨 하단에서 발생한느 모든 데이터베이스 액티비티를 바니어리 포멧에 저장하고 동일한 데이터베이스 또는 다른 데이터베이스에서 재생
• 캡처 프로세스에 특정 유형의 엑티비티를 포함시키거나 제외시키는 것도 가능

1. 사용자가 데이터베이스의 액티비티를 기록하는 캡처 프로세스를 시작
2. 프로세스가 /capture directory/라는 이름의 디렉토리에 "캡처 파일(capture file)"이라 불리는 특수한 파일을 생성하고 이곳에 데이터베이스 액티비티를 기록.
3. 사용자는 일정 시간이 지난 뒤 캡처 프로세스를 중단하고, 캡처 파일을 테스트 시스템의 /replay directory/ 디렉토리로 이동.
4. 사용자가 재생 프로세스를 시작하고 여러 개의 재생 클라이언트(replay client)가 캡처 파일에 대한 재생 작업을 실행.
5. 캡처 파일이 테스트 데이터베이스에 적용.

Database Replay 사용시 장점

• 다른 써드 파티 툴들은 사용자가 직접 입력한 몇가지 구문들의 조합을 실행하는데 그침.
• 사용자에게 SQL 구문의 입력을 요구하지 않는다.
• SQL 하부의 모든 액티비티가 캡처되므로, 성능 문제의 근본 원인이 될 수 있는 몇 가지 중요한 작업을 테스트 과정에서 누락할 위험이 없다.
• 사용자, 프로그램, 또는 일정기간을 기준으로 선택적인 캡처를 수행할 수 있으므로 전체 데이터베이스 워크로드가 아닌, 문제가 되는 워크로드만을 따로 추출하여 재생 가능.
  • 월말 계산 프로그램에서 성능 문제가 발생한 경우 파라미터 변경이 성능개선을 할 수 있을거라 생각하고 두 환경에서의 비교 가능
  • 10g R2에서 11g로 Upgrade 테스트를 할 때, 10gR2에서 정상적으로 수행되던 Transaction들을 11g에서도 동일하게 적용해 보고 문제점들을 미리 체크해 볼 수 있다.

=========================================================================================

What is Real Application Testing?

• RAT는 Replay와 SPA 2가지로 구성됨.
• 실제 운영 데이터베이스의 부하를 테스트 환경에서 재생
  • Database Replay
    • 운영서버에 가해지는 부하를 그대로 Capture한 파일을 가지고 테스트 수행가능
    • 운영시스템의 모든 사용자 SQL문장과 이들간의 Concurrency 및 Dependency를 포함
    • 테스트장비에서 별도의 Application없이 그대로 재생 가능
    • 녹화기능 : 10.2.0.4이상 , 재생기능 : 11g이상
  • SQL Performance Analyzer
    • Database Replay가 운영 시스템에서 실제로 수행되었던 부하 전체를 capture하여 재생하는 반면, SQL Performance Analyzer는 분석하고자 하는 특정 SQL 문장들을 대상으로 분석 수행
    • SQL집합을 사용자가 선별하여 생성가능
    • Parameter변경 등에 대한 영향도를 동일시스템에서 Simulation가능

h2.Real Application Testing

• 운영 환경에서의 부하 녹화(Workload Capture)
  • 실제 부하와 관련된 모든 정보에 대한 녹화 파일 생성
    • 실제 SQL 및 타이밍, concurrency 정보들
  • 녹화 파일을 테스트 시스템으로 이동
  • 원하는 시간 및 기간 동안만 수행 가능
• 테스트 환경에서의 부하 재생(Workload Replay)
  • 테스트 시스템에 준비된 변경 사항 반영
  • 녹화된 실제 부하 파일을 재생
  • Commit되는 타이밍 및 순서의 보장
• 분석 및 보고
  • 예기치 못한 오류들
  • 데이터 불일치
  • 성능상의 문제점 등

Step 1

• Workload Capture
  • 모든 외부 클라이언트 요청이 바이너리 파일 내 캡쳐됨
  • 시스템 환경이나 내부 작업은 제외됨
  • 최소의 오버헤드
    • 가능한 한 function call을 최소화
    • Buffered I/O
  • 클라이언트 프로토콜 독립적임
  • 9.2.0.8에서 캡쳐하고 11.1이상에서 재현
  • 관심있는 시간대의 로드를 캡쳐 - 피크타임, 월말 작업등.

• Workload Capture on RAC
  • 공유 및 로컬 파일시스템 지원
  • 운영 시스템과 테스트 시스템의 노드 수가 다를 수 있음
  • 공유 파일 시스템 권장
    • 모든 노드에 대해서 공유된 하나의 디렉토리 사용
    • 모든 부하를 캡쳐
  • 로컬 파일 시스템
    • 각 노드는 각각의 캡쳐 디렉토리 사용
    • 모든 노드에 대해 디렉토리 이름과 경로가 동일해야 함
    • 재현을 위해 모든 캡쳐된 부하파일은 하나의 디렉토리 내에 통합되어야 함.

• Capture Options
  • 캡쳐 대상을 커스터마이즈하기 위해 부하를 필터링할 수 있음.
    • Inclusion Filters : 어떤 세션이 캡쳐되어야 하는지 지정
    • Exclusion Filters : 어떤 세션이 캡쳐되지 말아야 하는지 지정
    • Filter Attributes : 아래의 세션 속성이 필터링하는데 사용됨
      • User
      • Program
      • Module
      • Action
      • Service
      • Session ID
  • 온디맨드, 혹은 스케쥴된 일정으로 캡쳐작업을 수행할 수 있음

Step 2

• Process Workload File
  • 테스트 시스템 셋업
    • 어플리케이션 데이터가 운영 데이터베이스에서 캡쳐 시작 전과 동일해야 함
    • 테스트 시스템 생성시 RMAN, Snapshot Standby, imp/exp, Data Pump 등을 이용
    • 변경 작업 수행 : DB, OS 업그레이드, 스토리지 변경, 플랫폼 마이그레이션
  • 재현 가능한 포맷으로 캡쳐된 데이터를 변환
  • 한번 변환되면 여러 번 재현될 수 있음
  • RAC의 경우 캡쳐된 파일 모두를 하나의 디렉토리로 옮김

Step 3

• Replay Workload
  • 타이밍, 동시성 및 캡쳐한 시스템에 대한 dependency 정보 등을 보존하여 부하 재생
  • Replay Client는 부하를 재생하고 재생 시스템에 요청을 보내는 프로그램
  • Replay Client는 캡쳐된 call들을 OCI call로 변환하고 Database로 보냄
  • 높은 동시성의 부하에 대해서는 여러 개의 Replay Client를 사용

• Replay Option
  • Synchronized Replay (Default)
    • 동기화된 모드로 부하가 재현됨
    • 운영 부하와 동일한 동시성과 타이밍으로 재현
    • 트랜잭션 커밋 순서가 보장
    • 최소한의 데이터 불일치
  • Synchronization controls
    • 비동기 모드로 재현될 수 있음
    • 부하/스트레스 테스팅에 유용
    • 데이터 불일치도가 높음
    • 동기화 관리를 위한 파라메터
      • SYNCHRONIZATION (TRUE)
        Workload Replay 중 동기화 사용여부를 결정.
        TRUE로 설정하면 Replay 중 캡처된 Workload의 COMMIT 순서가 유지되며 종속 COMMIT 작업이 모두 완료된 후에만 모든 Replay 작업이 실행.
      • THINK_TIME_SCALE (100(100%))
        동일한 세션의 연속되는 두 사용자 호출 간의 경과 시간을 조정하며 % 값으로 표시.
        0으로 설정하면 Replay 중 최대한 빨리 데이터베이스에 사용자 호출이 전송된다.
      • ONNECT_TIME_SCALE (100(100%))
        Workload 캡처가 시작된 시간부터 세션이 지정된 값에 종속된 시간까지의 경과 시간을 조정하며 % 값으로 표시
      • THINK_TIME_AUTO_CORRECT (TRUE)
        Workload Replay가 Workload 캡처보다 느리게 진행되는 경우 유휴 시간을 줄여준다.
        TRUE로 설정하면 Replay중 사용자 호출 시간이 켭처 중보다 오래 걸리는 경우 시스템에서 호출간 유휴 시간을 수정.(think_time_scale 파라미터에 기반)
      • query workload (READ ONLY workload) : SCALE_UP_MULTIPLIER
        • SQL> exec dbms_workload_replay.prepare_replay(scale_up_multiplier=>4);
  • Connection Remapping
    • 캡쳐시의 Connection String은 테스트 시스템에서의 재현시 다시 매핑되어야 함
    • Examples
      • One-to-One : Allows simple instance-to-instance remapping
      • Many-to-One : Maps several connectiion strings to a service in the test system(e.g., load balancing listener)
  • Replay Client의 개수
    • 사용자가 정의 가능
    • Calibration mode로 실행하면 특정 부하를 재생하기 위해 필요한 replay client의 수를 추천
    • Replay client는 다중 부하 세션을 유지할 수 있는 멀티스레드 클라이언트임

Analysis & Reporting

• 재생된 내용에 대한 포괄적인 분석용 보고서 제공
• Error Divergence : For each call error divergence is reported
  • New : 캡쳐시에는 발생하지 않은 재현이 발생한 에러
  • Not Found : 캡쳐시에는 밸생했으나 재현시에는 발생하지 않는 에러
  • Mutated : 재현 시 캡쳐시에 발생한 에러와 다른 에러가 발생한 경우
• Data Divergence
  • Replay : 매 호출마다 리턴되는 행 수가 비교되고 불일치가 리포트된다
  • User : 어플리케이션 레벨의 검증 스크립트
• Performance Reporting
  • Capture and Replay Report : 고수준의 성능 정보를 제공
  • ADDM Report : in-depth 성능 분석을 제공
  • AWR, ASH Report : 비교 분석

SYSDATE 변경

• • SQL에 sysdate가 capture시와 replay가 서로 다른 경우 SQL결과값에 divergency가 발생됨.
    • 원인 : DB Replay시 SQL문장안의 sysdate가 capture시의 time이 아닌 replay시의 time으로 계산됨.
    • 해결 : System time을 과거로 변경

Database Replay 활용

• Database Upgrade
• Database Parameter Changes
• Patch Apply
• Migration to RAC from Single
• Error Debugging
• Object Changes / Schema Changes
• O/S & Platform Changes

Real Application Testing 제외대상

• Driect path load of external files
• Shared Server requests
• Streams
• Advanced Replication Streams
• Non PL/SQL AQ
• Flashback queries
• OCI based object navigations
• Non SQL based object acces
• Distributed transactions
• Remote describe/commit operations

Database Replay Summary Report

Summary

• 실세계 시스템에 대한 변경 작업을 정확하게 검증
  • 낮은 리스크로 실제 전체 부하에 대한 테스트 결과를 얻음
  • 테스트 사이클을 월 단위에서 일단위로 단축
  • 테스트를 위한 미들 티어나 어플리케이션 구축을 할 필요가 없음
  • 변경으로 인해 성능이 저하된 경우를 선별함으로써 Diagnostics and Tuning Pack의 활용도와 효과를 최대화 할 수 있음.
• Database Replay를 통해
  • 경쟁력 강화
  • 이윤 극대화
  • 규제 준수