TM
2010.12.27 03:43

Database Replay

조회 수 9503 추천 수 0 댓글 0

Database Replay

Oracle Database 11g에 새로 추가된 혁신적인 기능 Database Replay는 전체 데이터베이스 워크로드를 캡처하고 나중에 "재생"할 수 있게 합니다.

Download Oracle Database 11g 다운로드

데이터베이스에 변경 작업을 수행할 때 여러분이 가장 우려하는 것은 무엇입니까? 변경 작업이라고 한다면 초기화 매개변수나 데이터베이스 속성을 수정하는 사소한 작업일 수도 있고 패치 셋을 적용하는 것과 같은 중요한 작업일 수도 있습니다. 그리고 또 Oracle Database 11g로의 업그레이드 작업이 있습니다.

필자에게 있어 가장 우려되는 것은 바로 변경으로 인해 무엇인가가 "망가져" 버릴 수 있다는 위험입니다. 아주 사소한 변경 작업이라 하더라도 도미노 효과로 인해 가시적인 피해를 낳을 수도 있습니다.

이러한 위험을 최소화하기 위해, 대부분의 IT 조직은 운영 환경과 유사한 통제된 환경에서, 운영 시스템과 유사한 워크로드를 적용하고 그 영향을 평가하고 있습니다. 기술적인 관점에서 볼 때 운영 시스템을 그대로 복제하는 것은 어려운 일이 아닙니다. 하지만 워크로드를 복제하는 것은 전혀 다른 이야기입니다. 말로는 쉽지만 실제로 실행하는 것은 무척 어렵습니다.

대부분의 IT 조직은 써드 파티 로드 생성 툴을 이용하여 실제 사용자 작업에 대한 시뮬레이션을 수행하는 방법을 선택합니다. 이러한 방법이 유용한 경우도 물론 있지만, 시뮬레이션 결과가 운영 데이터베이스의 워크로드를 정확하게 반영할 수는 없습니다. 이러한 툴들은 미리 작성해 둔 쿼리를 매개변수를 바꾸어 가면서 반복적으로 실행하는 기능만을 제공합니다. 따라서 툴에 쿼리를 입력하고 무작위로 사용할 매개변수를 설정하는 작업은 사용자의 몫입니다. 이러한 시뮬레이션 환경은 운영 시스템의 실제 워크로드를 반영하기보다는 운영 워크로드의 아주 작은 일부분을 반복 실행합니다. 결국 테스트되는 애플리케이션 코드는 전체의 1 퍼센트 정도에 불과할 수 있습니다. 설상 가상으로, 운영 워크로드에서 사용되는 쿼리를 툴에 입력하는 작업은 사용자가 도맡아야 합니다. 이 작업은 소규모 애플리케이션의 경우 수 주에서 수 개월, 그리고 복잡한 애플리케이션이라면 1 년까지도 걸릴 수 있습니다.

실행되는 모든 데이터베이스 작업을 데이터베이스 내부에 저장하고, 원래 발생했던 것과 동일한 순서대로 다시 재생할 수 있다면 훨씬 좋지 않을까요?

Enter Database Replay

Oracle Database 11g가 여러분들의 소원을 들어 드립니다. 새로운 Database Replay는 마치 데이터베이스를 위한 DVD 레코더처럼 동작합니다. Database Replay는 SQL 레벨 하단에서 발생하는 모든 데이터베이스 액티비티를 바이너리 포맷에 저장하고 동일한 데이터베이스 또는 다른 데이터베이스에서 재생할 수 있게 합니다. 또 캡처 프로세스에 특정 유형의 액티비티를 포함시키거나 제외시키는 것도 가능합니다.

Database Replay는 오라클이 Oracle Database 11g에서 "Real Application Testing" 옵션이라고 명명한 기능의 절반 부분을 차지합니다. 다른 절반은 SQL Performance Analyzer가 담당하고 있습니다. 이 두 가지 툴의 기본적인 차이점은 그 적용 범위에 있습니다. Database Replay가 데이터베이스의 모든 액티비티를 캡처하고 재생하는 반면, SQL Performance Analyzer는 개별 SQL 구문을 캡처하고 재생합니다. (Database Replay에서는 캡처된 개별 SQL 구문에 접근할 수 없습니다. SQL Performance Analyzer에서는 가능합니다.) SQL Performance Analyzer는 애플리케이션이 실행한 SQL 구문의 성능 영향을 평가합니다. 그러므로 SQL 튜닝 과정에서 매우 유용하게 활용될 수 있습니다. (SQL Performance Analyzer에 대해서는 본 시리즈의 다른 연재를 통해 설명할 예정입니다.)

개념적으로 보았을 때, Database Replay는 아래와 같은 순서에 의해 동작합니다.

Figure 1
  1. 사용자가 데이터베이스의 액티비티를 기록하는 캡처 프로세스를 시작합니다.
  2. 프로세스가 /capture directory/라는 이름의 디렉토리에 "캡처 파일(capture file)"이라 불리는 특수한 파일을 생성하고 이곳에 데이터베이스 액티비티를 기록합니다.
  3. 사용자는 일정 시간이 지난 뒤 캡처 프로세스를 중단하고, 캡처 파일을 테스트 시스템의 /replay directory/ 디렉토리로 이동합니다.
  4. 사용자가 재생 프로세스를 시작하고 여러 개의 재생 클라이언트(replay client)가 캡처 파일에 대한 재생 작업을 실행합니다.
  5. 캡처 파일이 테스트 데이터베이스에 적용됩니다.
  6. 그렇다면 Database Replay는 다른 써드 파티 툴과 어떤 점에서 다른 걸까요? 다른 툴들은 사용자가 직접 입력한 몇 가지 구문들의 조합을 실행하는데 그칩니다. 반면, Database Replay는 사용자에게 SQL 구문의 입력을 요구하지 않습니다. 또 SQL 하부의 모든 액티비티가 캡처되므로, 성능 문제의 근본 원인이 될 수 있는 몇 가지 중요한 작업을 테스트 과정에서 누락하거나 할 위험이 없습니다. 그 뿐 만이 아닙니다. 사용자, 프로그램, 또는 일정 기간을 기준으로 선택적인 캡처를 수행할 수 있으므로 전체 데이터베이스의 워크로드가 아닌, 문제가 되는 워크로드만을 따로 추출하여 재생하는 것이 가능합니다.

    한 예로 월말 이자 계산 프로그램에서 성능 문제가 발생한 경우를 가정해 봅시다. 관리자는 매개변수를 변경하면 성능이 개선될 수 있을 것이라고 생각합니다. 관리자는 월말 결산 프로그램이 실행되는 기간 동안의 워크로드만을 캡처하고, 테스트 시스템의 매개변수를 변경한 뒤 테스트 시스템에서 캡처 파일을 재생하기만 하면 됩니다. 성능이 만일 개선되었다면, 문제는 해결된 셈입니다. 문제가 개선되지 않았다고요? 어차피 테스트 시스템이니 상관 없습니다. 운영 데이터베이스에는 아무런 피해를 입히지 않았으니까요.

    필자의 견해로는, 이 기능 하나만으로도 Oracle Database 11g로 업그레이드할 이유가 충분하다고 봅니다. 이제 그 동작 원리에 대해 설명할 차례입니다.

    캡처

    가장 먼저 수행할 작업은 데이터베이스에서 워크로드를 캡처하는 것입니다. 모든 작업은 커맨드 라인 또는 Oracle Enterprise Manager Database Control을 통해 실행될 수 있습니다. 하지만 여기에서는 후자의 방법을 사용하기로 합니다.

    1. 캡처된 워크로드는 (마치 "캠코더"에 든 "테이프"처럼) 시스템 상에 파일 형태로 저장됩니다. 디렉토리는 비어 있는 상태이어야 합니다. 이제 첫 번째로 디렉토리를 생성해 봅시다. 아래와 같이 "/home/oracle/dbcapture"라는 이름의 디렉토리를 생성합니다.
        $ cd /home/oracle
        $ mkdir dbcapture
      
    2. 데이터베이스에서 이 디렉토리를 위한 디렉토리 오브젝트를 생성합니다:
      SQL> create directory dbcapture as '/home/oracle/dbcapture';
      
      Directory created.
      
    3. 이제 캡처 작업을 시작할 준비가 끝났습니다. 실제 환경을 테스트하기 위해, 대량의 INSERT 구문을 생성하는 스크립트를 생성한 뒤 TRAN라는 이름의 테이블에 INSERT 작업을 실행합니다.

      INSERT 구문 생성을 위한 PL/SQL 코드가 아래와 같습니다. 아래 코드는 1,000 개의 INSERT 구문을 생성하여 실행하고 있습니다. (동일한 구문을 1,000 번 반복 실행하는 것이 아니라 1,000 개의 서로 다른 INSERT 구문이 생성되고 있음을 참고하십시오.)

      declare
        l_stmt varchar2(2000);
      begin
        for ctr in 1..1000 loop
           l_stmt := 'insert into trans values ('||
              trans_id_seq.nextval||','||
              ''''||dbms_random.string('U',20)||''','||
              'sysdate - '||
              round(dbms_random.value(1,365))||','||
              round(dbms_random.value(1,99999999),2)||','||
              round(dbms_random.value(1,99))||')';
           dbms_output.put_line(l_stmt);
           execute immediate l_stmt;
           commit;
        end loop;
      end;
      
      새로운 파일에 위 코드를 입력합니다. (아직은 실행하지 마십시오.) 파일 이름을 add_trans.sql로 명명합니다.

    4. 실제 환경에서라면 재생 작업은 다른 데이터베이스에서 실행하는 경우가 많을 것입니다. 하지만 여기에서는 데이터베이스를 플래시백 처리한 뒤, 같은 데이터베이스에서 액티비티를 재생하는 방법을 사용하기로 합니다. 아래와 같이 GOLD라는 이름의 Restore Point를 생성합니다.
      SQL> create restore point gold;
      
      (1 단계에서 4 단계까지는 학습을 위해 편의상 넣은 과정입니다. 디렉토리 오브젝트를 생성하는 부분을 제외한다면, 같은 작업을 실제 운영 환경에서 실행할 필요는 없습니다.)

      이제 캡처 작업을 시작할 준비가 끝났습니다. Oracle Enterprise Manager Database Control의 메인 Database Replay 페이지로 이동합니다. 홈 페이지에서 Software and Support 페이지(아래 그림의 "1"로 표시된 부분)로 이동합니다.

      Figure 2

    5. Database Replay("2"로 표시된 부분)를 클릭하여 Database Replay 페이지(아래 참고)를 실행합니다.

      Figure 3

    6. 왼쪽 창에 일련의 액티비티가 표시되는 것을 볼 수 있습니다. 첫 번째 액티비티 (Step 1: Capture Workload) 를 선택하기 위해 액티비티 옆에 있는 Go to Task 아이콘을 누릅니다.

    7. 다음 화면에서 3 가지 가정 사항이 제시됩니다. 캡처 프로세스를 시작하기 전에 이 세 가지 가정을 주의 깊게 검토하고 확인해야 합니다:

      • 캡처된 워크로드를 재생할 시스템이 워크로드 캡처가 시작되기 직전의 SCN으로 복구되어 있는지 확인합니다.
      • 캡처된 워크로드를 저장할 만큼 충분한 디스크 공간이 있는지 확인합니다.
      • 워크로드 캡처가 시작하기 전에 데이터베이스를 재시작할 준비가 되었는지 확인합니다.

      • 모든 체크박스를 클릭하여 승인합니다.

      • Next를 클릭합니다.

      • 다음 화면에는 두 가지 다른 액션 아이템이 표시됩니다. 스크린 상단에 위치한 두 개의 라디오 버튼은 캡처 프로세스를 시작하기 전에 데이터베이스를 재시작할 것인지 선택하기 위해 사용합니다.

        캡처 프로세스를 시작하면, 프로세스 시작 전에 실행 중이던 트랜잭션의 일부는 캡처 파일에 저장되고 또 나머지 일부는 저장되지 않을 수 있습니다. 데이터베이스를 재시작하면 이러한 실행 중인(in-flight) 트랜잭션의 문제를 방지할 수 있습니다. 또 공유 풀에 저장된 SQL 구문이 일부는 캐시되어 있거나 핀(pin) 처리 되어 있을 수 있습니다. 이러한 문제도 캡처 워크로드에 영향을 미칠 수 있습니다. 데이터베이스를 재시작하면 이러한 "잡음"을 제거하는 것이 가능합니다. 또, 데이터베이스를 재시작함으로써 깔끔한 상태의 백업본을 테스트 시스템에 복구할 수 있는 기회를 얻을 수 있습니다. 또 테스트 시스템과 운영 시스템이 동일한 SCN 번호로 재생 작업을 시작함을 보장할 수 있습니다.

        이러한 이유, 특히 처음 언급한 이유 때문에 오라클은 캡처 작업을 시작하기 전에 데이터베이스를 재시작할 것을 권고하고 있습니다. (인터페이스에서는 데이터베이스 재시작 옵션이 디폴트로 선택되어 있습니다.) 하지만 꼭 그럴 필요는 없습니다. 재시작을 원하지 않는다면 다른 라디오 버튼을 누릅니다.

      • 스크린의 하단에는 아래와 유사한 내용이 표시될 것입니다.

        Figure 4


        이제 캡처 작업을 진행하는 동안 캡처 프로세스에서 사용할 필터를 기록할 차례입니다. 디폴트 상태에서는 두 가지 필터가 제공됩니다. 하나는 Oracle Management Server로부터 전달되는 모든 액티비티를 제외하도록, 또 하나는 Oracle Management Agent로부터 전달되는 모든 액티비티를 제외하도록 설정되어 있습니다.

        여기에 다른 필터를 추가할 수도 있습니다. 예를 들어, 모든 perl 프로그램을 제외하도록 필터를 추가하려면 Add Another Row 를 클릭하고 "Filter Name", "Value" 필드에 각각 "perl", "%perl%"을 입력합니다. 그리고 디폴트 매개변수에 있는 작은 실수를 수정합니다. Oracle Management Agent 필터의 값은 "emagent%"가 아닌 "%emagent%"가 되어야 합니다.

        또는 모든 SYS 사용자의 액티비티를 제외하기를 원할 수도 있습니다. 이 경우, Session Attribute 드롭다운 메뉴에서 USER를 선택하고 "Value" 컬럼에 "SYS"를 입력합니다.

      • Next를 클릭합니다. 이번에는 아래와 같은 화면이 표시됩니다:

        Figure 5

      • 화면의 드롭다운 메뉴에서 캡처 파일을 저장할 디렉토리 이름을 선택합니다. 여기에서는 DBCAPTURE 디렉토리를 사용하기로 합니다. 앞 단계에서 이 디렉토리를 미리 생성하지 않았다면 Create Directory Object를 눌러 디렉토리를 생성해 주어야 합니다. Next를 클릭합니다.
      • 다음 화면의 Job Details 메뉴를 통해 작업 실행 시점 등을 설정합니다. Immediate 라디오 버튼을 눌러 캡처 프로세스가 바로 시작될 수 있도록 합니다.

      • OS 유저네임, SYS 패스워드 등의 세부 정보를 입력한 뒤 Next를 클릭합니다.

      • "Step 5 of 5"로 표시되는 다음 화면에서는 작업명, 예외 필터 등 사용자가 설정한 내용을 요약하여 보여 줍니다. 아무 문제가 없다면 Submit을 클릭합니다. 문제가 있는 경우에는 다시 뒤로 돌아가 설정을 변경합니다.

      • Submit을 누르면 워크로드 캡처 작업이 바로 시작됩니다. 아래와 같은 확인 스크린이 표시되는 것을 볼 수 있습니다.

        Figure 6


        여기서 Status가 "In Progress"로 표시됨에 주목하십시오.
      • 이제 워크로드의 캡처가 시작되었으므로, SQL*Plus 프롬프트에서 시뮬레이션 워크로드를 실행합니다. 물론 실제 시스템 환경이라면 시뮬레이션을 실행할 필요가 없을 것입니다. 그저 캡처를 실행해 놓고 워크로드가 저장되기를 기다리기만 하면 됩니다.
        SQL> connect scott/tiger
        SQL> @add_trans
        
        위 명령을 실행하면 1,000 개의 구문이 TRANS 테이블에 INSERT 처리됩니다.

      • 워크로드 실행을 완료했다면Stop Capture를 클릭합니다.

      • 이것으로 /home/oracle/dbcapture 디렉토리의 파일에 워크로드를 성공적으로 캡처하였습니다.
      • 워크로드의 사전 처리

        이제는 캡처된 워크로드를 재생(replay)해 볼 차례입니다. 실제 환경에서는 워크로드를 별도의 테스트 시스템에서 재생해야 할 것입니다. 따라서 /home/oracle/dbcapture 디렉토리의 파일을 다른 호스트로 복사해야 합니다. 파일을 복사하기 전에 복사 대상 디렉토리가 비어 있는지 미리 확인합니다. 본 문서에서는 편의상 동일한 데이터베이스 내에서 워크로드를 재생하기로 합니다.

        동일한 데이터베이스에서 워크로드를 재생해야 하는 경우는 흔치 않지만 있을 수 있습니다. 한 예로, 메인 시스템에서 워크로드를 재생하고, 테스트가 완료되면 처음 시작한 시점으로 플래시백 처리하고자 할 수 있을 것입니다. 또 유지보수 작업이 허용된 시간 동안 운영 데이터베이스 상에서 매개변수의 변경으로 인한 영향을 테스트해 보는 것도 가능합니다.

        워크로드를 재생하기 전에 사전 처리(pre-process) 작업이 필요합니다. 사전 처리 작업을 통해 캡처된 파일을 재생 가능한 상태로 만들 수 있습니다.

        1. 메인 Database Replay 페이지를 엽니다.
        2. Step 2: Preprocess Workload를 선택합니다.
        3. 3. 드롭다운 목록에서 디렉토리 오브젝트를 선택합니다. 캡처된 워크로드가 표시될 것입니다. 여기에서는 DBCAPTURE 파일을 확인할 수 있습니다. 디렉토리 오브젝트를 생성하지 않았다면, 버튼을 눌러 디렉토리를 생성할 수 있습니다.
        4. Preprocess Workload를 클릭합니다.
        5. 다음 페이지에서는 작업 이름을 정하고 호스트 유저네임, 패스워드 등의 정보를 입력합니다. 특별한 작업 이름을 원하지 않는 이상 디폴트 값을 승인합니다. 작업을 바로 실행하도록 선택합니다. 호스트 유저네임과 패스워드는 미리 입력되어 있을 것입니다. 입력되어 있지 않다면 적절한 값을 입력하고 Submit을 클릭합니다.
        6. 다음 페이지에서 요약 정보와 작업 상태를 확인할 수 있는 링크가 표시됩니다. 링크를 클릭합니다.
        7. 작업 상태가 "Succeeded"로 바뀔 때까지 스크린을 계속 리프레시합니다.
        8. 이제 워크로드의 사전 처리가 완료되어 재생이 가능한 상태가 되었습니다.

          재생

          워크로드를 캡처하고 사전 처리를 완료했다면, 이제 테스트 데이터베이스에서 재생해 볼 수 있습니다. 본 예제에서는 동일한 데이터베이스에서 워크로드의 사전 처리 작업을 수행하고 워크로드를 재생하기로 합니다. 이를 위해 데이터베이스를 처음 시작한 시점으로 되돌려 놓아야 합니다. 이를 위해, 캡처 프로세스 과정에서 생성한 GOLD Restore Point로 플래시백 처리합니다.

          SQL> shutdown immediate;
          ... database shuts down ...
          SQL> startup mount
          ... instance starts and mounts the database ...
          SQL> flashback database to restore point gold;
          ... database will be flashed back ...
          SQL> alter database open resetlogs;
          ... database is opened ...
          
          이제 워크로드 캡처 작업을 실행하기 이전의 상태로 돌아왔습니다. 아래 설명을 따라 워크로드를 재생합니다.
          1. Database 홈 페이지의 "Capturing" 섹션에 있는 메인 Database Replay 화면으로 이동합니다.

          2. 메뉴에서Step 3: Replay Workload를 선택합니다. 메인 Replay 화면이 표시됩니다.

          3. 화면에서 디렉토리 선택을 위한 드롭다운 메뉴를 볼 수 있습니다. 재생할 파일이 위치한 디렉토리를 선택합니다. 여기서 선택하는 디렉토리는 실제 UNIX 디렉토리가 아니라 디렉토리 오브젝트입니다. 앞에서 생성한 DBCAPTURE 디렉토리 오브젝트를 선택합니다. 아직도 디렉토리 오브젝트를 생성하지 않았다면, Create Directory 를 눌러 디렉토리 오브젝트를 생성할 수 있습니다.

          4. 우측 상단의 Setup Replay 를 누릅니다.

          5. 다음 화면에서 앞으로 진행될 작업에 대한 설명이 표시됩니다. 표시되는 각 정보에 대한 설명이 아래와 같습니다.

            • Restore Database—실제 운영 환경에서라면, 앞에서 캡처한 워크로드를 테스트 시스템에서 재생하게 될 것입니다. 테스트 시스템은 어떻게 구성해야 할까요? 아마도 운영 데이터베이스를 테스트 시스템에 복구하는 방법이 사용될 것입니다. 운영 데이터베이스가 셧다운 되지 않은 상태에서 복구가 진행되었다면 테스트 시스템에 아직 복구가 완료되지 않은 상태로 남아 있을 것입니다. 이런 경우라면 캡처 과정에서 확인한 SCN 넘버까지 복구 작업이 수행되었는지 확인합니다.

              본 예제에서는 플래시백 기능을 이용하여 해당 SCN 넘버로 데이터베이스를 복구하였습니다. 그러니 아무 문제 될 것이 없습니다.

            • Perform System Changes—우리가 워크로드를 재생하려는 가장 기본적인 이유가 바로 이것입니다. 즉, 매개변수 변경, 설정 변경과 같은 시스템 변경을 테스트하는 것이 우리의 목적입니다. 물론 변경 작업은 워크로드 재생을 시작하기 전에 수행해야 합니다.

            • Resolve References to External Systems—운영 데이터베이스의 디렉토리 오브젝트가 /home/appman/myfiles로 지정되어 있는데 이 디렉토리가 테스트 시스템에 존재하지 않는다고 가정해 봅시다. 파일을 재생하면, 해당 디렉토리에 대한 참조가 실패할 것입니다. 마찬가지로, 테스트 시스템에 소스 시스템의 DB 링크가 존재하지 않는다면 마찬가지로 실패하게 됩니다. 따라서 모든 외부 시스템에 대한 참조 정보를 테스트 환경에 맞게 변경해 주어야 합니다. 다음 화면에서 변경 작업을 수행할 수 있습니다.

            • Set Up Replay Clients—Replay Client의 셋업 방법은 아래에서 설명하겠습니다.

            • Continue를 누르면 아래와 같은 화면이 표시됩니다:


              Figure 7


              페이지에 표시된 링크를 클릭하여 올바르게 참조되지 않은 매개변수들을 변경할 수 있습니다. 링크 중 하나를 클릭하면 Database Replay 페이지를 벗어나게 됨을 주의하시기 바랍니다. 따라서 SQL*Plus에서 개별적으로 수정해 주는 것이 더 편리할 수 있습니다 Continue를 클릭합니다.

            • Replay Name 을 입력하거나 디폴트 값을 승인합니다.

            • 다음 화면에서 DB 링크, 디렉토리의 참조가 잘못된 경우 발생할 수 있는 몇 가지 문제를 확인할 수 있습니다.


              Figure 8


              필요하다면 스크린의 오른쪽에서 재생할 시스템에 대해 변경 작업을 수행할 수 있습니다. 본 예제에서는 동일한 데이터베이스에서 워크로드를 재생하므로 이 작업은 불필요합니다.

            • Next를 클릭합니다. 아래와 같은 화면이 표시됩니다:

              Figure 9


              위 화면은 replay 프로세스가 Replay Client를 대기 중임을 표시하고 있습니다. Replay Client는 Database Control 화면 바깥에서 실행됩니다. 이 클라이언트 프로그램은 캡처된 워크로드를 읽어 들이고 재생하는 작업을 수행합니다. 프로그램의 이름은 wrc입니다(UNIX, Windows 시스템 모두 동일합니다). Replay Client를 실행하려면 UNIX 프롬프트로 이동하여 아래와 같이 실행합니다:
              $ wrc userid=system password=* replaydir=/home/oracle/dbcapture
              
              위에서 SYSTEM 계정의 정확한 패스워드를 입력해 주어야 합니다. 캡처된 파일을 다른 위치에 저장했다면 디렉토리 네임을 변경해 줍니다. 아래와 같은 메시지가 표시될 것입니다:
              Workload Replay Client: Release 11.1.0.4.0 - Beta on Wed Jun 6 01:47:53 2007
               
              Copyright (c) 1982, 2006, Oracle.  All rights reserved.
               
              Wait for the replay to start (01:47:53)
              
              현재 Replay Client는 Replay Governor(Database Control)이 시작 명령을 내리기를 기다리고 있습니다. 워크로드의 병렬 처리를 위해 더 많은 클라이언트를 실행할 수도 있습니다.

            • Database Control 스크린으로 이동합니다. 화면에 Replay Client가 연결되었다는 메시지가 새로 표시되고 있음을 확인할 수 있습니다. 연결된 호스트 테임과 OS 프로세스 ID 등이 표시되고 있습니다:

              Figure 10

            • Next 를 클릭하고 다시 Submit 을 눌러 재생 프로세스를 시작합니다. 지금 UNIX 세션으로 돌아가면, "Replay started (01:49:56)"라는 메시지가 추가된 것을 확인할 수 있습니다. 진행 상태 막대를 통해 데이터가 얼마나 처리되었는지 표시됩니다..

            • 어느 정도 시간이 지나면 UNIX 세션에 "Replay finished (01:50:35)"라고 표시될 것입니다. 이때 Database Control 스크린으로 돌아가면 아래와 같은 화면을 확인할 수 있습니다.

              Figure 11

            • 재생 작업의 상세한 상태 정보가 표시되고 있습니다. 왼쪽 상단의 "Status"는 이제 "Completed"라고 표시되고 있습니다.
            • 이제 실행 결과를 분석할 차례입니다. 스크린의 하단에는 "Comparison"이라는 제목 하에 성능 지표들이 비교되고 있습니다. 예제에서는 재생 작업이 41초 만에 완료되었으며, 이는 캡처 프로세스에 걸린 시간인 2 분 14 초의 30.6%에 불과합니다. 이것을 좋은 소식으로 볼 수 있을까요? 변경 사항이 그 효과를 본 것일까요?

              꼭 그렇지 많은 않습니다. 다음 성능 지표, Database Time을 보십시오. 양쪽 모두 똑같이 2 초로 표시되고 있습니다. 결국 변경 작업이 성능에 큰 변화를 주지는 못한 것으로 결론 내릴 수 있을 것입니다.

            • 하지만 이것이 전부는 아닙니다. 좀 더 상세한 분석을 원한다면 캡처, 재생 시간 동안의 Automatic Workload Repository(AWR) 스냅샷을 열고 latch contention, lock, redo generation, consistent get 등의 다른 성능 지표들을 비교해 볼 수 있습니다. .
            • 활용 사례

              데이터베이스 매개변수의 변경—다음과 같은 시나리오를 생각해 봅시다. DBA가 db_file_multiblock_read_count 매개변수를 16에서 256으로 변경하면 좋을지 고민 중입니다. 글쎄, 256도 좋아 보이지만 128로 하면 어떨까요? 아니면 64나 32는 어떨까요? 선택의 폭은 제한되어 있지만 그 영향은 엄청날 수 있습니다. 이 값을 변경하면 옵티마이저의 동작 방식에 지대한 영향을 미치게 됩니다. 최적의 매개변수 값을 어떻게 결정하면 좋을까요?

              이러한 경우 Database Replay가 매우 유용하게 활용될 수 있습니다. 운영 시스템의 워크로드를 캡처하고 다른 테스트 시스템으로 캡처된 워크로드를 이동합니다. 그리고 db_file_multiblock_read_count를 32로 변경한 다음 워크로드를 재생합니다. 다시 데이터베이스를 원 상태로 플래시백 처리하고 매개변수 값을 64로 설정하여 동일한 워크로드를 재생합니다. 모든 가능한 매개변수 값에 대해 플래시백, 값 설정, 워크로드 재생의 사이클을 반복할 수 있습니다. 재생 작업을 실행할 때마다 재생 이전/이후의 AWR 스냅샷을 캡처하여 그 결과를 비교합니다. 그리고 최상의 결과를 보여주는 매개변수 값을 선택하면 됩니다. Database Replay가 없었다면, 이런 방식으로 매개변수 값을 결정하는 것은 불가능했을 것입니다.

              OS 업그레이드—OS를 업그레이드하거나 I/O 문제를 해결하기 위해 간단한 패치를 적용하는 경우를 생각해 봅시다. 업그레이드 작업으로 인해 다른 문제가 생기지 않을 것이라는 걸 어떻게 보장할 수 있을까요? 간단합니다. 워크로드를 캡처하고 패치가 적용된 테스트 시스템에서 재생해 보면 됩니다. 이 테크닉은 커널 매개변수의 변경 시에도 동일하게 적용될 수 있습니다.

              패치의 적용—새로운 버그를 발견하고, 이 버그를 해결하기 위한 패치를 찾았다고 합시다. 하지만 패치 작업이 시스템에 어떤 영향을 미칠지 확신할 수는 없습니다. 이런 경우에도 Database Replay가 해답이 될 수 있습니다.

              디버깅—어떤 환경에든 사용자가 기대하지 않는 결과를 내는 골치 아픈 프로그램이 하나쯤은 있기 마련입니다. Database Replay를 이용하면 정말 쉽게 디버깅을 진행할 수 있습니다. 프로그램을 실행한 워크로드를 캡처하여 새로운 시스템으로 이동한 다음, 디버깅을 통해 프로그램 로직을 변경하고 워크로드를 재생합니다. 이제 결과를 분석해서 제시하면 여러분들은 영웅으로 떠받들어질 것입니다! 하지만 처음에 성공하지 못했다고 낙담하지는 마십시오. 해결책을 찾을 때까지 프로세스를 반복하면 됩니다.

              오브젝트의 변경—인덱스를 추가하거나 인덱스를 B-트리에서 비트맵으로 변경하는 경우를 생각해 봅시다. INSERT 구문의 성능에 어떤 영향을 미칠까요? 추측으로 문제를 해결하려고 할 필요가 없습니다. 워크로드를 캡처하고 테스트 시스템에서 재생해 보면 됩니다.

              데이터베이스 업그레이드—데이터베이스 업그레이드는 변경 보장(change assurance)의 "성배"라고도 할 수 있습니다. 또 이제 우리 모두가 Oracle Database 11g로 업그레이드할 시점이 다가왔습니다. 여기서 백만 불짜리 질문을 던져 볼 수 있습니다. 애플리케이션이 이전과 마찬가지로 동작할까요? 아니면 개선되는 부분이 있을까요? Oracle Database 10g의 워크로드를 캡처하고 Oracle Database 11g 환경에서 재생해 보면 그 해답을 얻을 수 있습니다. 새로운 버전에서 가상의 트랜잭션을 테스트하는 대신, 실제로 사용자들이 애플리케이션을 통해 실행한 SQL 구문을 직접 테스트해 볼 수 있는 것입니다. 예상과 다른 부분이 있다면 시스템 튜닝을 수행하면서 만족할 때까지 테스트를 반복해 봅니다.

              (참고: 현재 Oracle Database 11g는 베타 버전으로 제공되며, 아직 Oracle Database 10g의 워크로드 캡처를 지원하지 않고 있습니다. 하지만 Oracle Database 11g의 정식 버전에서는 이 기능이 제공될 예정입니다.)

              플랫폼 변경—데이터베이스 플랫폼을 Solaris에서 HP-UX로 변경하는 경우를 가정해 봅시다. HP-UX의 파일 시스템은 async I/O를 지원하지 않습니다. 동일한 성능을 얻을 수 있을까요? 굳이 추측할 이유가 있나요? Solaris에서 워크로드를 캡처해서 HP-UX에서 재생해 보면 됩니다.

              Oracle Real Application Clusters(RAC) 구성으로의 전환—많은 IT 관리자들이 고민하는 문제입니다. 데이터베이스를 단일 인스턴스 환경에서 RAC 환경으로 전환하고자 합니다. 애플리케이션이 이전과 마찬가지로 동작할까요? 분명하게 확인하려면 실제 워크로드를 캡처해서 RAC 데이터베이스에서 재생해 보는 수 밖에 없습니다.

              결론

              변화에는 항상 고통이 따릅니다. 하지만 고통을 견딜만한 수준으로 만들 수는 있습니다. 새로운 Database Replay 툴을 이용하여 엔드 유저들이 실제로 시스템에서 실행한 액티비티를 캡처하고 테스트 시스템에서 재생하여, 단 몇 번의 마우스 클릭과 키보드 입력만으로 변경 사항의 영향을 정확하게 평가할 수 있습니다. 애플리케이션의 성능뿐 아니라 기능까지도 테스트할 수 있다는 사실을 잊지 마시기 바랍니다.


              Arup Nanda Arup Nanda (arup@proligence.com))는 Starwood Hotel and Resorts의 데이터베이스 시스템 매니저로 10 년이 넘는 기간 동안 오라클 DBA로 활동해 왔으며 2003년 오라클 매거진에 의해 "올해의 DBA"로 선정되었습니다. Arup은 오라클 관련 이벤트 및 저널의 발표자, 기고자로서 적극적으로 활동하고 있으며 뉴욕 오라클 사용자 그룹 실행 위원회 회원이자 Oracle ACE입니다. 그는 또 < Oracle Privacy Security Auditing> 의 공저자이기도 합니다. 출처: 오라클
               


        List of Articles
        번호 분류 제목 글쓴이 날짜 조회 수
        공지 Q&A Oracle관련 게시물만 Sean 2014.04.09 84902
        140 TM 엔지니어필수품 file perfstat 2011.03.03 14115
        139 TM RAC10g R2 patch(10.2.0.1->10.2.0.5) file 윤현 2011.03.02 10715
        138 TM oracle client 와 database 간 상호 호환성(version) 1 담벼락 2011.01.24 23201
        137 TM Automatic Storage Management file 담벼락 2010.12.31 10629
        136 TM 10g Transportable Tablespace 에 대한 세미나 자료 입니다 file 송기성 2010.12.29 9204
        135 TM Replication 세미나 자료 file 고구마 2010.12.29 11200
        134 TM SystemState 세미나자료 file 고구마 2010.12.29 11009
        » TM Database Replay 담벼락 2010.12.27 9503
        132 TM ORA-1578 조치를 위한 event 10231 1 이성철 2010.12.22 8449
        131 TM (10g) 자동 통계정보 수집(AUTOMATIC OPTIMIZER STATISTICS COLLECTION) 담벼락 2010.12.16 16383
        130 TM 오라클 디렉토리 변경 송기성 2010.12.16 24978
        129 TM UPDATABLE SNAPSHOT 구축하기 고구마 2010.08.23 15507
        128 TM replication table 다른 tablespace 로 옮기기 고구마 2010.08.23 13822
        127 TM Flashback Query 승현짱 2010.05.30 8675
        126 TM analyze connection failover options 유주환 2010.05.19 8864
        125 TM 어플리케이션 페일오버와 로드밸런싱 유주환 2010.05.19 8843
        124 TM fine-grained_auditing 1 유주환 2010.05.19 8594
        123 TM library_cache_lock,_library_cache-orapybubu 유주환 2010.05.19 8871
        122 TM fga와_vpd를_이용한_오라클_데이터베이스_보안_관련_문제와_답변 유주환 2010.05.19 10405
        121 TM 과도한 CPU 및 UNDO REDO 많이 사용하는 세션 찾기 1 고구마 2010.05.19 23731
        Board Pagination Prev 1 2 3 4 5 6 7 8 Next
        / 8