oracle real application testing solution test oracle db before moving production
우리는의 마지막 부분에 왔습니다 일련의 Oracle Database Testing.
지금까지 우리는 Oracle 데이터베이스 테스트 방법. 이 초점을 계속하여 Oracle Real Application Testing과 관련하여 더 자세히 살펴 보겠습니다.
오늘은 테스트 환경 자체의 시스템 변경을 프로덕션에 도입하기 전에 평가하는 효과적인 변경 보증 시스템 인 Oracle Real Application Testing에 대해 알아 보겠습니다.
이것은 실제 프로덕션 환경의 DB 워크로드를 캡처하고이를 대체하는 오라클의 선도적 인 솔루션입니다. 환경 .
수많은 경우에 언급했듯이 우리는 항상 가능한 모든 차원에서 데이터베이스를 테스트하여 불안정성을 근절하고 프로덕션 인스턴스에서 예기치 않은 문제가 발생하지 않도록해야합니다.
우리는 분류 할 수 있습니다 Oracle Real Application Testing 두 개의 넓은 섹션으로 :
- SQL 성능 분석기
- 데이터베이스 재생
더 진행하기 전에 SQL Performance Analyzer 및 Database Replay에는 추가 라이선스가 필요합니다. 즉, 추가 비용과 Enterprise Edition 옵션으로 사용할 수 있습니다.
학습 내용 :
SQL 성능 분석기
SQL 성능 분석기 및 데이터베이스 재생에 액세스하는 데 사용되는 GUI는 아래와 같은 Enterprise Manager입니다.
SQL 성능 분석기에 액세스하려면 'SQL 성능 분석기'링크를 클릭하십시오.
(확대하려면 이미지를 클릭하십시오)
SQL 성능 분석기를 사용하면 SQL 실행 및 성능에 영향을 미칠 수있는 시스템 변경의 성능 영향을 측정 할 수 있습니다.
다음과 같은 경우에 매우 유용합니다.
- 데이터베이스 업그레이드, 패치
- 운영 체제에 대한 구성 변경 – 소프트웨어 또는 하드웨어
- Oracle Optimizer 통계 변경
- 사용자 / 스키마 변경
항상 테스트 또는 테스트에서 SQL 성능 분석을 실행하는 것이 좋습니다. UAT (사용자 응용 프로그램 테스트) 프로덕션 시스템이 아니라 시스템입니다. 성능 측면에서 변경의 영향을 테스트하는 동안 프로덕션 인스턴스에서 실행중인 사용자에게 실수로 영향을 미칠 수 있기 때문입니다. 또한 테스트에서 실행하면 현재 프로덕션에서 실행중인 프로세스를 변경하지 않습니다.
에 SQL 성능 분석기 워크 플로의 기본 개요는 다음과 같습니다.
SQL 성능 분석에는 다음 단계가 포함됩니다.
1 단계)SQL 워크로드 캡처
분석하려는 프로덕션 인스턴스에서 SQL 워크로드의 일부가 될 SQL 문을 결정합니다. 이 워크로드는 프로덕션에있을 수있는 워크로드를 이상적으로 나타내야합니다.
SQL Tuning Set에서 이러한 문을 캡처하고이 SQL Tuning Set을 SQL 성능 분석기에 제공합니다.
분석기는 시스템에서 많은 리소스를 사용하므로 항상 테스트 또는 UAT 시스템에서 실행하는 것이 좋습니다. 테스트 시스템에서 실행하려면 프로덕션에서 이미 생성 한 SQL Tuning 세트를 테스트 시스템으로 내 보내야합니다.
2 단계)SQL 성능 분석기 작업 생성
Analyzer를 실행하려면 먼저 SQL 성능 분석기 작업을 만들어야합니다. 이 작업은 SQL 성능 분석기가 실행하는 분석에 대한 모든 데이터를 통합하는 저장소 일뿐입니다. 앞서 언급했듯이 SQL Tuning Set는 분석기에 자극제로 공급됩니다.
pdf 파일을 편집 할 수있는 프로그램
3 단계)변경 전 SQL 성능 평가판
SQL 성능 분석기 작업과 SQL 튜닝 집합을 만든 후 테스트 시스템에 인프라를 구축해야합니다.
시스템을 사용하여 테스트하려는 경우 유사한 환경을 복제 할 수 있도록 하드웨어, 소프트웨어 및 스토리지 측면에서 프로덕션 시스템과 매우 유사한 지 확인해야합니다.
테스트 시스템이 적절하게 구성되면 SQL 성능 분석기를 사용하여 데이터의 변경 전 버전을 구축 할 수 있습니다.
이는 Enterprise Manager 또는 API (내장 프로 시저)를 사용하여 수행 할 수 있습니다.
4 단계)변경 후 SQL 성능 평가판
변경 후 시험은 시스템을 일부 변경 한 후 테스트 시스템에서 수행됩니다.
이 작업이 완료되면 두 개의 SQL 시도, 즉 비교를위한 변경 전 시도와 변경 후 시도가 있습니다.
변경 전 SQL 성능 평가판과 유사하게 Enterprise Manager 또는 API (내장 프로 시저)를 사용하여 변경 후 SQL 성능 평가판을 만들 수 있습니다.
5 단계)보고서 생성
변경 전 및 변경 후 시도를 실행 한 후 SQL 성능 분석기를 사용하여 비교 분석을 실행하여 수집 된 성능 데이터를 비교할 수 있습니다.
이 비교 작업이 완료되면 테스트하려는 워크로드의 일부인 SQL 문의 성능을 식별하는 보고서를 생성 할 수 있습니다.
보고서를 검토하여 SQL의 성능을 판단하고 결론을 내릴 수 있습니다.
문을 작성한 다음 프로덕션에 시스템 변경 사항을 배포합니다.
마찬가지로 다양한 시스템 변경으로 다양한 워크로드를 테스트하고 프로덕션에서 구현하기 전에 각 워크로드를 테스트 할 수 있습니다.
위에 설명 된 워크 플로는 아래와 같이 그래픽으로 나타낼 수 있습니다.
데이터베이스 재생
Enterprise Manager를 통해 도구를 실행하려면 다음과 같이하십시오.
(확대하려면 이미지를 클릭하십시오)
Database Replay를 사용하면 기본적으로 테스트 시스템에 프로덕션 환경을 복제하여 시스템 변경 사항을 사실적으로 테스트 할 수 있습니다. 프로덕션 시스템에서 원하는 워크로드를 캡처하고 SQL 실행, 트랜잭션, 추출 및 프로 시저와 같은 원래 워크로드의 정확한 리소스 특성을 사용하여 테스트 시스템에서 재생함으로써이를 수행합니다.
이는 제품 버그, 부적절한 결과 또는 성능 회귀와 같은 원치 않는 결과를 포함하여 모든 변경의 가능한 모든 영향을 고려하기 위해 수행됩니다.
생성 된 광범위한 분석 및보고는 또한 발생한 잘못된 상황 및 성능 차이와 같은 잠재적 인 문제를 식별하는 데 도움이됩니다.
결과적으로 조직은 변화를 처리 할 때 안심하고 시스템 변경의 전반적인 성공을 평가하는 데 유리할 수 있습니다. 이렇게하면 프로덕션 변경 사항을 구현할 때 위험을 크게 줄일 수 있습니다. 변화는 불가피하며,이 변화의 모든 측면을 모든 각도에서 테스트하는 것은 생산을보다 견고하고 견고하게 만들 것입니다.
Database replay의 기본 워크 플로우는 다음과 같습니다.
Database Replay에서 지원하는 변경 사항은 다음과 같습니다.
- Oracle 데이터베이스 업그레이드, 소프트웨어 패치
- 사용자 / 스키마, 데이터베이스 인스턴스 매개 변수 (예 : 메모리, I / O)
- RAC (Real Application Cluster) 노드에 대한 하드웨어 / 소프트웨어 변경
- 운영 체제 변경, 운영 체제 패치
- CPU, 메모리, 스토리지
Database Replay를 사용하면 실제 프로덕션 시스템이 전자에 노출되기 전에 실제 프로덕션 시스템의 실제 부하를 재생하여 시스템에 대한 가능한 변경 사항의 다양한 효과를 테스트 할 수 있습니다. 생산에 대한 워크로드는 정량적으로 고정 된 기간 동안 모니터링, 분석 및 기록됩니다. 이 데이터는 시간이 지남에 따라 기록되며 테스트 시스템에서 워크로드를 재생하는 데 사용됩니다.
이를 수행하면 프로덕션에 부정적인 영향을 미칠 수있는 변경 사항을 구현하기 전에 워크로드의 영향을 성공적으로 테스트 할 수 있습니다.
워크 플로우는 다음과 같습니다.
1 단계) 워크로드 캡처
클라이언트의 모든 요청을 파일 시스템 (스토리지)의 '파일 캡처'라는 파일에 기록합니다. 이러한 파일에는 SQL, 바인드, 프로 시저 및 트랜잭션 정보와 같은 클라이언트 요청과 관련된 모든 중요한 정보가 포함되어 있습니다. 그런 다음 다른 시스템에서 재생하려는 경우 이러한 파일을 모든 시스템으로 내보낼 수 있습니다.
2 단계)워크로드 전처리
'파일 캡처'에서 정보를 캡처 한 후이를 사전 처리해야합니다. 이 단계에서는 워크로드 재생에 필요한 모든 데이터에 대한 설명을 제공하는 메타 데이터를 생성합니다.
이 단계는 시스템에서 엄청난 양의 리소스를 사용하기 때문에로드를 재생할 수있는 프로덕션과 별도로 다른 시스템에서 실행하는 것이 좋습니다. 테스트 할 다른 시스템이없고 프로덕션에서 실행하려는 경우 프로덕션에서 실행되는 사용자와 프로세스가 영향을받지 않도록 사용량이 많지 않은 시간에 실행해야합니다.
3 단계)워크로드 재생
이제 테스트 시스템에서 재생할 수 있습니다. 이때 모든 프로세스가이 전환을 거치면서 데이터를 축적하는 캡처 단계에서 처음 캡처 된 모든 트랜잭션, 컨텍스트, 프로 시저 및 SQL을 재생합니다.
4 단계)보고서 생성
성능 분석기와 마찬가지로 보고서를 생성하고 확인하여 실행 한 각 테스트를 비교할 수도 있습니다.
결론적으로 Database Replay를 테스트하는 동안 몇 가지 빠른 팁을 제공합니다.
- 가능한 한 동일한 테스트 시스템을 사용하십시오.
- 한 번에 하나씩 변경 사항을 테스트하여 그 영향을 이해합니다.
- 기본 재생 옵션으로 시작한 다음 요구 사항에 따라 필요한 경우 변경하십시오.
- 두 번째 재생을 수행하기 전에 모든 테스트 측면을 이해해야합니다.
- 테스트 결과를 저장하고 필요한 변경 / 테스트 작업을 문서화하십시오.
- 테스트 실행 중에 다른 워크로드 또는 사용자가 시스템을 사용하고 있지 않은지 확인하십시오.
결론:
Oracle Database 및 Application Testing의 다양한 측면과 다양한 방법을 사용하여 항상 가능한 한 자주 철저하게 테스트하십시오. 변경 사항을 배포하거나 프로덕션에 새 매개 변수를 도입하기 전에 애플리케이션과 사용자 환경을 이해해야합니다.
추천 도서
- 최고의 소프트웨어 테스트 도구 2021 (QA 테스트 자동화 도구)
- 데스크톱, 클라이언트 서버 테스트 및 웹 테스트의 차이점
- Oracle 데이터베이스를 테스트하는 방법
- 웹 애플리케이션 보안 테스트 가이드
- 응용 프로그램 테스트 – 소프트웨어 테스트의 기초로!
- 장치에 애플리케이션 설치 및 Eclipse에서 테스트 시작
- 시험 입문서 eBook 다운로드
- 파괴 테스트 및 비파괴 테스트 자습서