3. 이제 캡처 작업을 시작할 준비가 끝났습니다. 실제 환경을 테스트하기 위해, 대량의 INSERT 구문을 생성하는 스크립트를 생성한 뒤 TRAN라는 이름의 테이블에 INSERT 작업을 실행합니다.

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

새로운 파일에 위 코드를 입력합니다. (아직은 실행하지 마십시오.) 파일 이름을 add_trans.sql로 명명합니다.

4. 실제 환경에서라면 재생 작업은 다른 데이터베이스에서 실행하는 경우가 많을 것입니다. 하지만 여기에서는 데이터베이스를 플래시백 처리한 뒤, 같은 데이터베이스에서 액티비티를 재생하는 방법을 사용하기로 합니다. 아래와 같이 GOLD라는 이름의 Restore Point를 생성합니다.

(1 단계에서 4 단계까지는 학습을 위해 편의상 넣은 과정입니다. 디렉토리 오브젝트를 생성하는 부분을 제외한다면, 같은 작업을 실제 운영 환경에서 실행할 필요는 없습니다.)

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

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

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

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

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

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

9. Next를 클릭합니다.

10. 다음 화면에는 두 가지 다른 액션 아이템이 표시됩니다. 스 프로세스를 시작하기 전에 데이터베이스를 재시작할 것인지 선택하기 위해 사용합니다.

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

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

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

이제 캡처 작업을 진행하는 동안 캡처 프로세스에서 사용할 필터를 기록할 차례입니다. 디폴트 상태에서는 두 가지 필터가 제공됩니다. 하나는 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"를 입력합니다.

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

13. 화면의 드롭다운 메뉴에서 캡처 파일을 저장할 디렉토리 이름을 선택합니니다. 앞 단계에서 이 디렉토리를 미리 생성하지 않았다면Create Directory Object를 눌러 디렉토리를 생성해 주어야 합니다.Next를 클릭합니다.

14. 다음 화면의 Job Details 메뉴를 통해 작업 실행 시점 등을 설정합니다.Immediate라디오 버튼을 눌러 캡처 프로세스가 바로 시작될 수 있도록 합니다.

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

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

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

여기서 Status가 "In Progress"로 표시됨에 주목하십시오.

18. 이제 워크로드의 캡처가 시작되었으므로, SQL*Plus 프롬프트에서 시뮬레이션 워크로드를 실행합니다. 물론 실제 시스템 환경이라면 시뮬레이션을 실행할 필요가 없을 것입니다. 그저 캡처를 실행해 놓고 워크로드가 저장되기를 기다리기만 하면 됩니다.

위 명령을 실행하면 1,000 개의 구문이 TRANS 테이블에 INSERT 처리됩니다.

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

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

워크로드의 사전 처리

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

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

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

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

이제 워크로드의 사전 처리가 완료되어 재생이 가능한 상태가 되었습니다.

재생

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

이제 워크로드 캡처 작업을 실행하기 이전의 상태로 돌아왔습니다. 아래 설명을 따라 워크로드를 재생합니다.

1. Database 홈 페이지의 "Capturing" 섹션에 있는 메인 Database Replay 화면으로 이동합니다.

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

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

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

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

• Restore Database- 실제 운영 환경에서라면, 앞에서 캡처한 워크로드를 테스트 시스템에서 재생하게 될 것입니다. 테스영 데이터베이스를 테스트 시스이터베이스가 셧다운 되지 않은 상태에서 복구가 진행되었다면 테스트 시스템에 아직 복구가 완료되지 않은 상태로 남아 있을 것입니다. 이런 경우라면 캡처 과정에서 확인한 SCN 넘버까지 복구 작업이 수행되었는지 확인합니다.
  본 예제에서는 플래시백 기능을 이용하여 해당 SCN 넘버로 데이터베이스를 복구하였습니다. 그러니 아무em Changes - 우리가 워크로드를 재생하려는 가장 기본적인 이유가 바로 이것입니다. 즉, 매개변수 변경, 설정 변경과 같은 시스템 변경을 테스트하는 것이 우리의 목적입니다. 물론 변경 작업은 워크로드 재생을 시작하기 전에 수행해야 합니다.
• Resolve References to External Systems- 운영 데이터베이스의 디렉토리 오브젝트가 /home/appman/myfiles로 지정되어 있는데 이 디렉토리가 테스트 시스템에 존재하지 않는다고 가정해 봅시다. 파일을 재생하면, 해당 디렉토리에 대한 참조가 실패할 것입니다. 마찬가지로, 테스트 시스템에 소스 시스템의 DB 링크가 존재하지 않는다면 마찬가지로 실패하게 됩니다. 따라서 모든 외부 시스템에 대한 참조 정보를 테스트 환경에 맞게 변경해 주어야 합니다. 다음 화면에서 변경 작업을 수행할 수 있습니다.
• Set Up Replay Clients- Replay Client의 셋업 방법은 아래에서 설명하겠습니다.

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

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

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

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

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

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

위 화면은 replay 프로세스가 Replay Client를 대기 중임을 표시하고 있습니다. Replay Client는 Database Control 화면 바깥에서 실행됩니다. 이 클라이언트 프로그램은 캡처된 워크로드를 읽어 들이고 재생하는 작업을 수행합니다. 프로그램의 이름은 wrc입니다(UNIX, Windows 시스템 모두 동일합니다). Replay Client를 실행하려면 UNIX 프롬프트로 이동하여 아래와 같이 실행합니다:

위에서 SYSTEM 계정의 정확한 패스워드를 입력해 주어야 합니다. 캡처된 파일을 다른 위치에 저장했다면 디렉토리 네임을 변경해 줍니다. 아래와 같은 메시지가 표시될 것입니다:

현재 Replay Client는 Replay Governor(Database Control)이 시작 명령을 내리기를 기다리고 있습니다. 워크로드의 병렬 처리를 위해 더 많은 클라이언트를 실행할 수도 있습니다.

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

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

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

13. 재생 작업의 상세한 상태 정보가 표시되고 있습니다. 왼쪽 상단의 "Status"는 이제 "Completed"라고 표시되고 있습니다.

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

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

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

활용 사례

데이터베이스 매개변수의 변경- 다음과 같은 시나리오를 생각해 봅시다. DBA가 db_file_multiblock_read_count 매개변수를 16에, 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 툴을 이용하여 엔드 유저들이 실제로 시스템에서 실행한 액티비티를 캡처하고 테스트 시스템에서 재생하여, 단 몇 번의 마우스 클릭과 키보드 입력만으로 변경 사항의 영향을 정확하게 평가할 수 있습니다. 애플리케이션의 성능뿐 아니라 기능까지도 테스트할 수 있다는 사실을 잊지 마시기 바랍니다.