본 한국어 번역은 사용자 편의를 위해 제공되는 기계 번역입니다. 영어 버전과 한국어 버전이 서로 어긋나는 경우에는 언제나 영어 버전이 우선합니다.

Oracle 데이터베이스 성능 최적화 및 벤치마킹 절차

03/13/2024 기여자

PDF

데이터베이스 스토리지 성능을 정확히 테스트한다는 것은 매우 복잡한 일입니다. 이 작업을 수행하려면 다음 문제에 대한 이해가 필요합니다.

IOPS 및 처리량
포그라운드와 백그라운드 I/O 작업 간의 차이
지연 시간이 데이터베이스에 미치는 영향
스토리지 성능에도 영향을 주는 수많은 OS 및 네트워크 설정

비스토리지 데이터베이스도 고려해야 합니다. 스토리지 성능이 더 이상 성능을 제한하는 요인이 아니기 때문에 스토리지 성능 최적화가 유용한 이점을 전혀 제공하지 않는 경우도 있습니다.

이제 데이터베이스 고객의 대다수가 All-Flash 어레이를 선택하며 이 어레이에는 추가 고려사항이 수반됩니다. 예를 들어, 2노드 AFF A900 시스템에서 성능 테스트를 생각해 봅시다.

80/20 읽기/쓰기 비율로 2개의 A900 노드는 지연 시간이 150µs 표시를 넘어가기도 전에 1M 이상의 랜덤 데이터베이스 IOPS를 제공할 수 있습니다. 이는 대부분의 데이터베이스에서 현재 요구되는 성능 수준을 훨씬 뛰어넘는 것이라 어느 정도로 개선될지를 예측하기 어렵습니다. 스토리지는 병목 현상에서 제외될 것입니다
네트워크 대역폭은 성능 한계의 공통된 원인으로 부상하고 있습니다. 예를 들어, 회전식 디스크 솔루션은 I/O 지연 시간이 매우 길기 때문에 종종 데이터베이스 성능의 병목 현상을 발생시킵니다. All-Flash 어레이를 통해 지연 시간 한계를 제거하고 나면 이번에는 네트워크가 장애물이 되는 경우가 많습니다. 이는 진정한 네트워크 연결의 시각화가 어려운 가상화 환경과 블레이드 시스템에서 특히 두드러지며 대역폭 한계로 인해 스토리지 시스템 자체를 최대한 활용할 수 없는 경우 성능 테스트가 복잡해질 수 있습니다.
All-Flash 어레이의 지연 시간이 대폭 개선되었기 때문에 All-Flash 어레이의 성능을 회전식 디스크가 포함된 어레이와 비교하는 것은 일반적으로 불가능합니다. 테스트 결과는 대체로 중요하지 않습니다.
데이터베이스는 스토리지 I/O에 의한 제약이 없기 때문에 최고의 IOPS 성능을 All-Flash 어레이와 비교하는 테스트는 대부분 유용하지 않습니다 한 어레이는 500K 랜덤 IOPS를 유지할 수 있고 다른 어레이는 300K를 유지할 수 있다고 가정해 봅시다. 이 차이는 데이터베이스가 실제로 99%의 시간을 CPU 처리에 사용하는 경우 아무런 상관이 없습니다. 워크로드는 스토리지 어레이의 전체 용량을 활용하지 않습니다. 이와 반대로, 최고 IOPS 용량은 스토리지 어레이가 최고 성능으로 로드될 것으로 예상되는 통합 플랫폼에서 매우 중요할 것입니다.
어떤 스토리지 테스트에서든 지연 시간과 IOPS를 항상 고려하십시오. 시중의 많은 스토리지 어레이가 IOPS 레벨이 매우 높다는 주장을 펼치지만 지연 시간 때문에 이들 IOPS는 그러한 레벨에서 쓸모가 없습니다. All-Flash 어레이의 일반적인 타겟은 1ms 표시입니다. 더 나은 테스트 방식은 가능한 최대의 IOPS를 측정하는 것이 아니라 평균 지연 시간이 1ms를 넘기 전에 스토리지 어레이가 유지할 수 있도록 할 IOPS를 결정하는 것입니다.

Oracle Automatic Workload Repository 및 벤치마킹

Oracle 성능 비교를 위한 이상적인 표준은 Oracle AWR(Automatic Workload Repository) 보고서입니다.

AWR 보고서에는 여러 유형이 있습니다. 스토리지 관점에서, 를 실행하여 생성된 보고서 awrrpt.sql 명령은 특정 데이터베이스 인스턴스를 대상으로 하고 지연 시간을 기반으로 스토리지 I/O 이벤트를 분석하는 상세한 히스토그램이 포함되어 있기 때문에 가장 종합적이고 유용합니다.

2개의 성능 어레이를 비교할 때 가장 이상적인 방식은 각 어레이에서 같은 워크로드를 실행하여 워크로드를 정확히 타겟으로 하는 AWR 보고서를 생성하는 것입니다. 장시간 실행되는 워크로드의 경우, 시작 시간과 종료 시간을 아우르는 경과 시간을 토대로 단일 AWR 보고서를 사용할 수 있으며 여러 보고서로 AWR 데이터를 분석하는 것이 더 좋습니다. 예를 들어, 일괄 작업이 자정부터 오전 6시까지 실행된 경우 자정부터 오전 1시, 오전 1시부터 오전 2시 등등 일련의 1시간 간격 AWR 보고서를 생성하십시오.

다른 경우에는 매우 짧은 쿼리를 최적화해야 합니다. 최고의 옵션은 쿼리가 시작될 때 생성된 AWR 스냅샷과 쿼리가 끝날 때 생성된 두 번째 AWR 스냅샷에 기반을 두고 AWR 보고서를 생성하는 것입니다. 그렇지 않으면, 분석 중인 쿼리의 활동을 명료하지 않게 만드는 백그라운드 활동을 최소화하기 위해 데이터베이스 서버가 정지되어야 합니다.

AWR 보고서를 생성할 수 없는 경우 Oracle Statspack 보고서가 좋은 대안이 될 수 있는데 여기에는 AWR 보고서와 같은 I/O 통계 대부분이 포함되어 있습니다.

Oracle AWR과 문제 해결

AWR 보고서는 성능 문제 분석을 위한 가장 중요한 툴이기도 합니다.

벤치마킹과 마찬가지로 성능 문제 해결을 위해서는 특정 워크로드를 정확하게 측정해야 합니다. NetApp 지원 센터에 성능 문제를 보고할 때 또는 NetApp이나 파트너 어카운트 팀과 협력하여 새로운 솔루션을 사용할 때는 가능하면 AWR 데이터를 제공하십시오.

AWR 데이터를 제공할 때는 다음 요구사항을 고려하십시오.

를 실행합니다 awrrpt.sql 명령을 사용하여 보고서를 생성합니다. 출력은 텍스트 또는 HTML 형식으로 가능합니다.
Oracle RAC(Real Application Cluster)를 사용하는 경우 클러스터의 각 인스턴스에 대해 AWR 보고서를 생성합니다.
문제가 존재했던 특정 시간을 타겟으로 합니다. AWR 보고서에서 허용되는 최대 경과 시간은 일반적으로 1시간입니다. 수 시간 동안 문제가 지속되거나 일괄 작업 같이 시간이 많이 걸리는 작업인 경우, 분석할 기간 전체를 포괄하는 1시간 간격 AWR 보고서를 여러 개 제공합니다.
가능한 경우 AWR 스냅샷 간격을 15분으로 조정합니다. 이 설정을 통해 더 상세한 분석을 수행할 수 있으며 또한 의 추가 실행도 필요합니다 awrrpt.sql 각 15분 간격에 대한 보고서를 제공합니다.
매우 짧은 실행 쿼리가 문제인 경우, 작업이 시작될 때 생성된 AWR 스냅샷과 작업이 종료될 때 생성된 두 번째 AWR 스냅샷에 기반을 두고 AWR 보고서를 제공합니다. 그렇지 않으면, 분석 중인 작업의 활동을 명료하지 않게 만드는 백그라운드 활동을 최소화하기 위해 데이터베이스 서버가 정지되어야 합니다.
특정 시간에 성능 문제가 보고되었지만 그 외 시간에는 성능 문제가 없는 경우 비교를 위해 우수한 성능을 입증하는 추가 AWR 데이터를 제공합니다.

CALIBRATE_IO 를 선택합니다

를 클릭합니다 calibrate_io 명령은 스토리지 시스템의 테스트, 비교 또는 벤치마크에 사용할 수 없습니다. Oracle 설명서에 명시된 것처럼 이 절차는 스토리지의 I/O 기능을 보정합니다.

보정은 벤치마킹과 같지 않습니다. 이 명령의 목적은 데이터베이스 작업 보정을 위해 I/O를 발행하고 호스트에 발행된 I/O 레벨을 최적화하여 효율성을 개선하는 것입니다. 에 의해 수행되는 I/O 유형이기 때문입니다 calibrate_io 작동 방식은 실제 데이터베이스 사용자 I/O를 나타내지 않으며, 그 결과는 예측할 수 없으며, 재현이 불가능한 경우도 많습니다.

SLOB2 를 참조하십시오

Oracle 벤치마크인 SLOB2는 데이터베이스 성능을 평가하는 데 있어 선호되는 도구가 되었습니다. Kevin Closson이 개발했으며 에서 다운로드할 수 있습니다 "https://kevinclosson.net/slob/". 설치하고 구성하는 데에는 몇 분 정도가 걸리며 실제 Oracle 데이터베이스를 사용하여 사용자가 정의 가능한 테이블스페이스에 I/O 패턴을 생성합니다. 이 툴은 I/O를 통해 All-Flash 어레이를 포화할 수 있는 소수의 테스트 옵션 중 하나이며 IOPS가 낮지만 지연 시간에 민감한 스토리지 워크로드를 시뮬레이션하기 위해 훨씬 낮은 레벨의 I/O를 생성하는 데 유용합니다.

스윙벤치

Swingbench는 데이터베이스 성능을 테스트하는 데 유용할 수 있지만 스토리지에 중점을 두어 Swingbench를 사용하는 것은 매우 어렵습니다. NetApp이 관찰한 결과, AFF 어레이에 상당한 로드가 될 정도의 I/O가 생성된 Swingbench 테스트는 없었습니다. 드문 경우지만 지연 시간 관점에서 스토리지를 평가하는 데 OET(Order Entry Test)를 사용할 수 있습니다. 이는 데이터베이스에 특정 쿼리의 알려진 지연 시간 종속성이 있는 상황에서 유용할 수 있습니다. All-Flash 어레이의 잠재적 지연 시간을 실현하려면 호스트와 네트워크가 적절히 구성되었는지 주의를 기울여 확인해야 합니다.

HammerDB

HammerDB는 TPC-C 및 TPC-H 벤치마크를 시뮬레이션하는 데이터베이스 테스트 툴입니다. 테스트를 제대로 실행하기 위해 대규모 데이터 세트를 구성하는 데에는 상당한 시간이 걸릴 수 있지만 이는 OLTP와 데이터 웨어하우스 애플리케이션의 성능을 평가하는 데 효과적인 툴이 될 수 있습니다.

오리온

Oracle Orion 툴은 일반적으로 Oracle 9과 함께 사용되었지만 다양한 호스트 운영 체제의 변화에 따른 호환성이 보장되도록 유지보수되지 않았습니다. 이 툴은 운영 체제 및 스토리지 구성의 비호환성 때문에 Oracle 10 또는 Oracle 11에는 거의 사용되지 않습니다.

Oracle은 이 툴을 재작성했고 Oracle 12c에 기본으로 설치했습니다. 이 제품은 개선이 되었고 실제 Oracle 데이터베이스에서와 같은 호출을 다수 사용하지만 Oracle에서와 정확히 같은 코드 경로 또는 I/O 동작을 사용하지는 않습니다. 예를 들어, 대부분의 Oracle I/O는 동시에 수행되는데 이는 I/O 작업이 포그라운드에서 완료되는 경우 I/O가 완료될 때까지 데이터베이스가 멈춘다는 뜻입니다. 랜덤 I/O를 통한 스토리지 시스템의 단순한 서비스 장애는 실제 Oracle I/O의 재현이 아니며 스토리지 어레이를 비교하거나 구성 변화의 영향을 측정하는 직접적인 방법을 제공하지 않습니다.

그렇지만 특정 호스트-네트워크-스토리지 구성의 최대 성능에 관한 일반적인 측정이나 스토리지 시스템 상태를 알아내는 등 몇 가지 Orion 사용 사례가 있습니다. 매개 변수에 IOPS 고려사항, 처리량, 지연 시간을 포함하고 실제 워크로드를 충실히 복제하려 하는 한, 신중한 테스트를 통해 사용 가능한 Orion 테스트를 고안하여 스토리지 어레이를 비교하거나 구성 변경의 영향을 평가할 수 있습니다.