OpenShift Virtualization의 단일 인스턴스 Oracle Database

이 문서에서는 Red Hat OpenShift Virtualization에서의 단일 인스턴스 Oracle Database 19c 실행을 지원하기 위해 Red Hat이 엔지니어링에 기울이는 노력에 관해 자세히 소개합니다. 이 문서에서는 통합 표준 아키텍처, 기능, 성능, 확장성, 실시간 마이그레이션을 포괄하는 검증 결과와 함께 GitHub에서 호스팅되는 테스트 아티팩트에 대한 링크를 제공합니다.

데모를 통해 OpenShift Virtualization이 Oracle 데이터베이스와 같이 까다로운 프로덕션 워크로드를 위한 강력한 성능을 제공하여 어떻게 성능 저하 없이 실행 가능한 가상화 대안을 제공하는지 살펴봅니다. 특히 OpenShift Virtualization에서 단일 인스턴스 Oracle Database를 평가하고 도입하는 일을 담당하는 기술 리더, 아키텍트, 엔지니어링 팀, 프로젝트 관리자를 대상으로 합니다.

아키텍처 설계 원칙은 컴퓨팅, 네트워크, 스토리지를 위한 리소스 할당, 파티셔닝, 추상화 계층 최적화에 중점을 둡니다. TPC-C 벤치마크와 HammerDB를 사용한 성능 테스트 결과, Oracle Database가 Red Hat OpenShift Data Foundation을 능가하는 로컬 NVMe 스토리지를 갖춘 OpenShift Virtualization에서 성공적으로 실행할 수 있음이 입증되었습니다. 또한 이 문서에서는 인프라와 Oracle에 관한 인사이트를 얻기 위해 Prometheus와 Grafana를 사용하는 관측성과 모니터링에 대해서도 중점적으로 다룹니다.

배경

많은 고객이 성능 저하 없는 가상화 대안을 찾고 있습니다. OpenShift Virtualization은 엔터프라이즈 데이터베이스를 포함하여 까다로운 프로덕션 워크로드를 위한 강력한 성능을 제공합니다.

기존의 소프트웨어 아키텍처에서 가장 일반적인 구성 요소 중 하나는 Oracle Database입니다. OpenShift Virtualization에서 Oracle Database를 평가하고 도입하는 데 관심이 있는 고객을 돕기 위해, Red Hat은 전담 엔지니어링 리소스를 통해 OpenShift Virtualization에서 Oracle Database를 운영하는 데 최적화된 경험을 제공합니다.

이 문서에서는 독자가 Red Hat OpenShift Container Platform에 대한 이해를 갖추고 있다고 가정합니다. Oracle Database의 일반적인 아키텍처나 성능 튜닝에 대해서는 논의하지 않습니다. 대신 Oracle Database가 최상의 성능을 달성할 수 있도록 OpenShift Virtualization을 설정하고 구성하는 아키텍처 옵션에 대해 설명합니다.

이 블로그 포스트는 OpenShift Virtualization에서 Oracle 단일 인스턴스 데이터베이스의 도입을 평가, 검증, 결정하는 일을 담당하는 다음 전문가를 대상으로 합니다.

• 기술 리더(예: 부사장, CTO): 하이브리드 또는 온프레미스 클라우드에서 Oracle 데이터베이스 워크로드를 실행하는 일상적인 운영의 ROI(투자수익률)와 TCO(총소유비용)를 최적화할 책임이 있는 이해관계자입니다.
• 아키텍트: 고객 아키텍트는 표준 아키텍처와 테스트 결과를 검토하여 OpenShift Virtualization이 조직에서 Oracle Database 워크로드를 호스팅하는 데 사용 가능한 플랫폼인지 평가할 수 있습니다. 이 문서는 아키텍처 요구 사항을 제공하고 아키텍트가 독립적인 검증을 실행할 수 있도록 지원합니다.
• 엔지니어링 팀: 엔지니어링 팀은 GitHub에서 사용할 수 있는 재사용 가능한 아티팩트와 함께 이 평가 중에 Red Hat이 사용한 성능 테스트를 활용하여 테스트 설정과 자동화를 가속화하고 검증 프로세스를 간소화할 수 있습니다.
• 프로젝트 관리자: 프로젝트 관리자는 표준 아키텍처를 사용하여 영향을 받는 구성 요소와 담당 팀을 파악할 수 있습니다. 표준화된 테스트를 사용할 수 있습니다. 

OpenShift Virtualization 아키텍처 개요

OpenShift Virtualization은 Red Hat이 오픈소스 KubeVirt 프로젝트를 구현한 것입니다. 이는 표준 OpenShift 플랫폼을 기반으로 구축됩니다. 가상 머신(Virtual Machine, VM)은 컨테이너화된 포드 내에서 실행되며, OpenShift Container Platform은 다른 포드를 관리하는 것과 동일하게 VM을 관리합니다. VM 인스턴스는 일반 컨테이너 애플리케이션처럼 보안, 네트워크, 스토리지 등의 동일한 플랫폼 서비스에 액세스할 수 있습니다. 유일한 차이점은 컨테이너 내에서 실행되는 일반 워크로드 애플리케이션과 달리 VM은 포드 수준에서 직접 관리된다는 것입니다.

아키텍처 구성 요소:

• 커널 기반 가상 머신(Kernel-based Virtual Machine, KVM): OpenShift의 VM 하이퍼바이저는 Linux 커널의 일부입니다.
• 가상 머신 인스턴스(Virtual Machine Instance, VMI): VMI로 표시되는 각 VM은 KVM을 사용하여 QEMU에서 생성되어 하드웨어를 에뮬레이션하고, QEMU는 사용자 공간 수준의 격리를 제공합니다.
• KubeVirt: VM을 쿠버네티스 리소스로 관리하여 VM이 포드처럼 보이도록 하는 쿠버네티스 애드온입니다.
  • virt-operator: KubeVirt 구성 요소 설치 및 업데이트를 관리합니다.
  • virt-controller: VM 라이프사이클 관리를 처리합니다(예: 장애 시 재시작, 확장).
  • virt-handler: KVM/QEMU를 사용하여 호스트에서 VM을 관리하는 KubeVirt 지원 노드의 데몬입니다.
  • virt-launcher: VM 포드당 하나이며, 포드 내부의 QEMU/KVM 가상 머신 프로세스를 관리하는 오케스트레이터 역할을 합니다.
  • 사용자 정의 리소스(Custom Resource, CR): VM 정의, VM 인스턴스 실행, 예약/정책을 나타냅니다.
• 포드 래퍼: QEMU 프로세스의 래퍼 역할을 합니다. VMI는 포드 내에서 가상화된 게스트 OS로 실행됩니다.
• 스토리지: OpenShift Virtualization은 OpenShift Data Foundation, Portworx와 같은 다양한 쿠버네티스 네이티브 옵션과 iSCSI, 파이버 채널(Fibre Channel, FC) SAN 스토리지 등과 같은 더 전통적인 엔터프라이즈 솔루션을 포함하여 다양한 스토리지 솔루션을 지원합니다. 오픈소스 Ceph 프로젝트를 기반으로 구축된 쿠버네티스 네이티브 스토리지 솔루션인 OpenShift Data Foundation은 쿠버네티스 환경에 최적화된 추상화 계층을 갖춘 확장 가능한 이중 스토리지를 제공합니다. 또한 OpenShift Data Foundation은 Persistent Volume 및 Persistent Volume Claim의 동적 프로비저닝을 지원하여 스토리지 관리를 간소화합니다.

이 Oracle Database 검증 프로젝트에 대해서는 다양한 스토리지 대안이 고려됩니다. 그러나 이 문서의 범위 내에서는 쿠버네티스와의 원활한 통합으로 인해 OpenShift Data Foundation을 중점적으로 다룹니다. Oracle Database 워크로드를 배포할 때는 성능 요구 사항과 운영 요구 사항을 가장 잘 충족하는지 여부를 평가하여 스토리지 솔루션을 선택하는 것이 중요합니다.

네트워크: VM은 Multus(CNI 메타 플러그인) 또는 SR-IOV(단일 루트 I/O 가상화)를 통해 네트워크에 액세스합니다. 여기서 Multus는 포드 수준에서 정의됩니다.

Oracle Database 설계 원칙

Oracle Database가 가상화된 운영 체제에서 실행되는 경우 VM은 데이터베이스가 적절한 시스템 리소스를 수신하여 효율적으로 운영되고 복원력을 유지할 수 있도록 해야 합니다. 실제 환경에서 인프라 리소스는 제한적이므로 리소스 할당의 균형을 유지하고 여러 워크로드의 다양한 요구 사항을 수용할 수 있도록 인프라 아키텍처를 신중하게 설계해야 합니다.

인프라 수준에서 Oracle Database 성능을 향상하는 일반적인 아키텍처 접근 방식에는 다음과 같은 원칙이 포함됩니다.

• 리소스 위치: 컴퓨팅, 스토리지, 네트워크 측면에서 충분한 리소스를 할당하여 병목 현상을 제거합니다.
• 리소스 파티셔닝: 리소스가 제한된 경우 리소스 요구 사항을 파티셔닝하고 특정 요구 사항을 충족하는 맞춤형 솔루션을 구현합니다.
• 추상화 계층 최적화: 불필요하거나 가치가 낮은 추상화 계층을 사용하지 않도록 하여 성능 향상을 위한 유연성을 확보합니다.

Oracle Database는 다음 세 가지 주요 유형의 시스템 리소스에 크게 의존합니다.

• 컴퓨팅: 여기에는 vCPU, IOThread, 메모리, 노드 간 확장 기능이 포함됩니다.
• 네트워크: Oracle Database는 I/O 성능에 매우 민감합니다. 클라이언트 액세스와 스토리지 액세스는 각각 별도의 처리량과 대기 시간 요구 사항을 갖고 있습니다. 따라서 Oracle Database 아키텍처는 다양한 유형의 트래픽에 대해 별도의 네트워크를 사용하는 경우가 많습니다.
• 스토리지: Redo 로그, 데이터베이스 테이블, 백업은 각기 다른 읽기/쓰기 성능 요구 사항을 갖고 있습니다. 최적의 I/O 성능을 보장하기 위해 가능한 경우 항상 별도의 물리적 스토리지에 배치해야 합니다.

OpenShift Virtualization은 시스템 리소스 파티셔닝 요구 사항에 따라 다양한 리소스 할당 접근 방식을 지원하는 데 필요한 기능과 유연성을 제공합니다.

표준 아키텍처

이 섹션에서는 OpenShift Virtualization 기반 Oracle Database 설계의 아키텍처 고려 사항과 솔루션 옵션에 대해 설명합니다.

컴퓨팅

Oracle Database에 충분한 컴퓨팅 리소스가 있는지 확인하고 OpenShift Virtualization 플랫폼이 다음에 대한 직접적인 제어 권한을 제공하는지 확인합니다.

• 리소스 수직 확장을 위한 vCPU 및 RAM 할당 구성
• 수평 확장을 위한 OpenShift Virtualization 클러스터 확장성
• VM IO 스레드 수 할당을 제어하여 포드 수준 I/O 장애물 제거
• Oracle Database 워크로드를 호스팅하는 가상 머신에 리소스를 과도하게 할당하여 시스템의 물리적 리소스보다 더 많은 가상화된 CPU 또는 메모리를 할당하지 않도록 합니다.

네트워크

Oracle Database 트래픽은 네트워크 대기 시간, 처리량, 신뢰성 측면에서 각기 다른 성능 요구 사항을 갖고 있습니다. OpenShift Container Platform 포드 Multus는 네트워크 트래픽을 파티셔닝하고 여러 네트워크 프로토콜을 조정하는 기능입니다. 다음 사항을 고려하세요.

• OpenShift SDN, 스토리지, 가상 머신에 대한 다양한 네트워크 경로를 구현합니다.
• Oracle RAC 데이터베이스 설치의 경우 RAC 인스턴스 간 상호 연결 통신과 '퍼블릭' 네트워크 통신을 위해 네트워크 트래픽을 추가로 분리합니다.
• 대기 시간과 처리량에 민감한 미션 크리티컬 워크로드의 경우 가상 네트워크 인터페이스에 SR-IOV를 활용하여 VM에서 기반 물리 리소스로의 직접 경로를 생성하는 것이 좋습니다.

스토리지

앞서 언급했듯이 OpenShift Virtualization은 OpenShift Data Foundation 및 Portworx와 같은 쿠버네티스 네이티브 옵션에서 iSCSI 및 파이버 채널(FC) SAN과 같은 기존 엔터프라이즈 시스템에 이르기까지 광범위한 스토리지 솔루션을 지원합니다. 이러한 유연성 덕분에 사용자는 성능과 운영 요구 사항에 가장 적합한 스토리지를 선택할 수 있습니다.

적절한 스토리지 옵션을 선택하는 데 있어 보편적인 규칙은 없지만 다음 원칙을 지침으로 삼을 수 있습니다.

• 운영 유연성(프로비저닝 용이성, 플랫폼과의 통합)에 대한 요구 사항과 성능(IO 대기 시간, 처리량) 요구 사항 간 균형을 유지합니다.
• Oracle RAC 데이터베이스에 필요할 수 있는 다중 쓰기 옵션(두 개 이상의 VM 간 공유를 볼륨)을 지원합니다.

하드웨어 구성

초기 성능 테스트의 설계 범위는 현재 사용 가능한 하드웨어 리소스 세트로 이루어졌습니다. 

클러스터 사양:

• Dell R660 서버 4개
  • 128 CPU 스레드(Intel Xeon Gold 6430 소켓 2개)
  • 256GB 메모리
  • 1TB 루트 디스크
  • 1.5TB NVME 드라이브 4개
  • 25Gbps Broadcom NIC 4개
  • 25Gbps Intel 810 NIC 2개

OpenShift Virtualization 구성

OpenShift Virtualization 및 OpenShift Data Foundation 스토리지의 기본 구성은 합리적인 성능을 제공하지만, 데이터베이스에 일반적인 IO 집약적인 워크로드에 맞게 테스트 플랫폼을 최적화하기 위해 구성이 추가로 변경되었습니다.

• 성능 프로필을 사용하도록 OpenShift Data Foundation을 구성했습니다.
• OpenShift Data Foundation 스토리지 트래픽을 일반 소프트웨어 정의 네트워크(OpenShift Container Platform SDN) 트래픽에서 분리하도록 OpenShift Data Foundation 및 OpenShift Virtualization을 구성했습니다. (8장: 네트워크 요구 사항 | 배포 계획 | Red Hat OpenShift Data Foundation | 4.18)
• 별도의 물리적 네트워크 인터페이스를 사용하여 OpenShift Data Foundation 스토리지 및 OpenShift Container Platform SDN에서 가상 머신(Oracle Database 및 HammerDB 테스트 장치)에 대한 트래픽을 분리했습니다. 대기 시간을 줄이고 처리량을 높이기 위해 단일 루트 I/O 가상화(Single Root I/O Virtualization, SR-IOV)를 사용하여 영향을 받는 가상 머신에 네트워크 인터페이스를 도입했습니다(그림 2).

클러스터 사양:

• OpenShift 버전: 4.18.9
• OpenShift Virtualization: OperatorHub를 통해 지원
• 노드
  • 하이브리드(컨트롤 플레인/작업자/스토리지) 노드 3개
  • 작업자 노드 1개
• 네트워킹(Oracle Database VM 전용):
  • OpenShift SDN, OpenShift Data Foundation 스토리지 클라이언트, OpenShift Data Foundation 스토리지 복제 트래픽을 분리하기 위해 파티셔닝된 4개의 Broadcom 25Gbps NIC를 사용하는 LACP 본드
  • SR-IOV를 사용하여 가상 머신에 제공되도록 구성된 두 개의 서로 다른 서브넷(퍼블릭 및 프라이빗)이 있는 가상 머신 트래픽용 Intel x810 25GB NIC 2개
• 스토리지(Oracle Database VM에만 해당): 성능 프로필로 구성되고 별도의 스토리지 네트워크를 사용하는 OpenShift Data Foundation 스토리지(1.5TB NVMe 드라이브 4개 지원)

Oracle Database 구성

Oracle Database를 호스팅하는 가상 머신은 리소스의 과다 할당을 방지하고 다양한 하드웨어 옵션에 대한 테스트 결과를 비교하기 위해 적절한 크기로 조정됩니다. Oracle Database는 TPC-C(Transaction Processing Performance Council Benchmark C) 테스트 전용으로 튜닝되지 않았으며 모범 사례를 기반으로 한 몇 가지 일반적인 튜닝 변경 사항을 제외하고 대부분 기본 구성을 사용합니다.

가상 머신의 크기, 벤치마크 테스트 워크로드의 세부 사항, 모니터링 정보를 기반으로 튜닝 매개 변수를 선택했습니다. 테스트 결과를 기준 수치와 비교하여 각 변경의 효과를 평가했습니다. Oracle Database 구성은데이터베이스 성능 튜닝 가이드의 권장 사항에 따라 추가로 최적화할 수 있습니다.

그림 3은 Oracle Database와 HammerDB 클라이언트 액세스가 동일한 네트워크에 있음을 보여줍니다. 가상 머신의 데이터 볼륨은 쓰기 작업을 개선하기 위해 디스크 공간을 사전 할당하도록 구성됩니다. 

로컬 스토리지 오퍼레이터를 사용하여 NVMe 스토리지를 추가함으로써 스토리지가 데이터베이스 성능에 미치는 영향을 평가하기 위해 별도의 애드혹 테스트를 수행했습니다.

가상 머신 사양:

• OS: RHEL 8.10
• VM 수: 1
• vCPU: 16
• 메모리: 48GB
• 스토리지: RH ODF의 블록 장치로 250GB(동일한 볼륨에 있는 루트 및 DB 데이터)
• DataVolume: 'preallocation: true'(씩 프로비저닝)를 사용하여 생성됨
• 네트워킹: SR-IOV를 사용하여 퍼블릭 서브넷에 연결됨

Oracle Database 단일 인스턴스 설정:

Oracle Database 버전: 19c Enterprise Edition(릴리스 업데이트 26(버전 19.26) 포함)

• OMF(Oracle Managed Files)를 사용하여 파일 시스템을 데이터 파일(OpenShift Data Foundation 지원 스토리지가 있는 루트 볼륨)의 타겟으로 설정한 데이터베이스
• 향후 버전의 Oracle Database와의 테스트 호환성을 보장하기 위해 데이터베이스는 컨테이너 데이터베이스(CDB) 아키텍처를 사용하여 생성되었습니다.
• 메모리 할당에서는 32GB의 총 메모리를 DB 생성 마법사의 입력으로 사용했습니다(Oracle Database 설치 시 SGA/PGA 분할을 자동으로 평가할 수 있음).
• 추가 튜닝 매개 변수:
  • 데이터 파일 4개를 32GB로 수동 확장
  • REDO 로그 크기가 4GB로 조정됨
  • 4개의 REDO 로그 디스크 그룹
  • FILESYSTEMIO_OPTIONS: SETALL(비동기 IO 및 직접 IO 허용)
  • USE_LARGE_PAGES: AUTO(대규모 SGA 크기의 CPU 사용량 최적화)

참고: NVME 지원 스토리지를 사용한 성능 테스트를 위해 별도의 파일 시스템이 NVME 장치를 사용하여 마운트되고 데이터 파일의 타겟 대상으로 할당되었습니다.

관측성과 모니터링

OpenShift는 인프라 및 애플리케이션 계층 전반에서 모니터링을 통합하는 강력한 통합 관측성 플랫폼을 제공합니다. 기본적으로 메트릭 수집, 로깅, 경고를 지원하며, Oracle Database와 같은 외부 애플리케이션의 관측성 데이터를 포함하도록 확장할 수 있습니다. 이러한 통합 접근 방식은 운영 복잡성을 줄이는 동시에 엔드 투 엔드 가시성을 지원합니다.

OpenShift Virtualization의 관측성은 동일한 플랫폼에 원활하게 통합되므로 가상 머신, 시스템 리소스, 워크로드(즉, 일관된 단일 모니터링 스택 내의 Oracle 데이터베이스)를 모니터링할 수 있습니다.

OpenShift 내에 배포된 Oracle Database Observability Exporter는 Prometheus에 노출되는 Oracle Database 성능 메트릭과 메타데이터를 수집합니다. Grafana는 이러한 메트릭을 시각화하여 실시간 대시보드를 제공하여 Oracle Database 및 VM 계층 전반에서 비정상적인 패턴, 리소스 압력, 성능 문제를 감지합니다.

데이터베이스 수준 분석을 강화하기 위해 성능 테스트 중에 HammerDB를 활용하여 스냅샷을 캡처하고 자동 워크로드 리포지토리(Automatic Workload Repository, AWR) 보고서를 생성할 수 있습니다. 이러한 리포트를 Prometheus 및 Grafana의 메트릭과 결합하면 워크로드 동작과 잠재적인 병목 현상을 더욱 풍부하고 다차원적으로 이해할 수 있습니다.

또한 Oracle Database Enterprise Manager는 Oracle Database에 맞춤화된 상세 진단 및 전문 모니터링 기능을 제공하는 보완 툴 역할을 합니다. 이는 OpenShift의 통합 관측성 플랫폼과 함께 사용되며, 인프라와 Oracle Database에 특화된 운영 인사이트에 대한 포괄적인 적용 범위를 보장합니다.

그림 5는 OpenShift Virtualization 플랫폼에 대한 관측성 및 모니터링 설정의 일부로 배포된 샘플 Grafana 대시보드를 보여줍니다.

그림 6은 OpenShift Virtualization 플랫폼에 배포된 샘플 Oracle Database Grafana 대시보드를 보여줍니다.

시스템 성능 평가

성능 테스트는 온라인 트랜잭션 처리(Online Transaction Processing. OLTP) 워크로드의 데이터베이스 트랜잭션 처리량과 쿼리 대기 시간을 측정하기 위해 설계되었습니다. 오픈소스 데이터베이스 성능 테스트 소프트웨어인 HammerDB를 사용하여 이전에 언급한 시스템 세부 정보와 함께 단일 인스턴스 Oracle Database에 대한 TPC-C 벤치마크를 사용하여 OLTP 워크로드를 시뮬레이션했습니다. TPC-C 테스트는 빈번한 고객 주문, 결제, 재고 점검, 배치 배송을 포함하여 쓰기 작업 80%와 읽기 작업 20%가 혼합된 실제 주문 관리 시스템을 시뮬레이션합니다. 테스트 실행에는 OpenShift Virtualization 내의 Oracle Database에서 TPC-C 워크로드를 생성하는 HammerDB가 포함됩니다.

테스트 적용 범위 요약

HammerDB 테스트 하네스를 사용하여 스케일-런 프로필을 구성하고 가상 사용자 수를 20명부터 시작해 100명까지 늘리면서 500개의 웨어하우스를 활용해 각 테스트를 20분간 실행하여 유의미한 워크로드를 시뮬레이션했습니다. 실제 프로덕션 시나리오를 반영하고 확장된 트랜잭션 부하에서 시스템의 성능을 평가하기 위해 이 설정을 설계했습니다.

표준 아키텍처 구성을 기반으로 한 테스트 결과는 OpenShift Data Foundation 스토리지가 포함된 단일 인스턴스 Oracle Database에 대해 강력한 NOPM(분당 신규 주문) 및 TPM(분당 트랜잭션) 메트릭을 보여주었습니다. 그러나 로컬 NVMe 스토리지가 포함된 단일 인스턴스 Oracle Database는 OpenShift Data Foundation 환경에 비해 더 나은 성능을 제공했습니다. 평균 대기 시간은 비교적 안정적으로 유지되었지만 때때로 급증하는 모습이 관찰되었습니다.

결론

OpenShift Virtualization은 Oracle Database 19c 워크로드를 배포할 수 있는 실행 가능한 플랫폼입니다. OpenShift Virtualization은 설정이 간편하여 가상 머신 생성을 강력하게 지원합니다. 이러한 요인을 고려할 때 OpenShift Virtualization은 경쟁하는 가상화 기술 오퍼링의 강력한 경쟁자이자 대안이 될 수 있습니다. Oracle Database 19c에 대한 최신 성능 검증은 OpenShift Virtualization 플랫폼에서 엔터프라이즈급 성능을 발휘하는 것을 보여줍니다.

로컬 NVMe 스토리지를 사용한 애드혹 테스트를 통해 고성능 스토리지 옵션의 영향을 평가한 결과, FC SAN과 같은 고성능 스토리지 솔루션으로 업그레이드하면 전반적인 성능이 크게 향상될 수 있다는 높은 가능성이 확인되었습니다.

고성능 워크로드의 경우 다음을 고려하세요.

• Oracle Database용 FC SAN과 같은 고성능 스토리지 옵션 및 성능 최적화를 위한 데이터 파일 및 Redo 로그
• 가상 머신, OpenShift SDN 및 스토리지 네트워크를 위한 네트워크 세그멘테이션(OpenShift Virtualization 노드에서 별도의 물리적 기기 사용 권장)
• SR-IOV(단일 루트 I/O 가상화), Oracle Database 워크로드를 호스팅하는 가상 머신의 가상 네트워크 인터페이스 성능을 최적화하기 위해 하드웨어에서 지원하는 경우
• 워크로드 요구 사항에 따라 Oracle 데이터베이스 설정 USE_LARGE_PAGES를 사용하는 HugePage: 이 구성은 메모리 페이지 크기를 조정하며, 특히 기본 설정보다 큰 SGA로 작업할 때 성능 향상을 위해 권장됩니다.

이 GitHub 리포지토리에서 HammerDB 테스트 스크립트를 찾을 수 있습니다.

oracle-db-appdev-monitoring GitHub 프로젝트는 사용자가 애플리케이션과 데이터베이스 전반에서 성능을 파악하고 문제를 쉽게 진단할 수 있도록 Oracle Database에 대한 관측성을 제공하는 것을 목표로 합니다. 안내서를 읽고 OpenShift 플랫폼에서 프로젝트를 설정하세요.