요약 사전 조건 및 제한 사항 아키텍처 도구 모범 사례 에픽 관련 리소스

AWR 보고서를 사용하여 오라클 데이터베이스의 Amazon RDS 엔진 크기를 추정합니다.

작성자: Abhishek Verma(AWS), Eduardo Valentim(AWS)

환경: 프로덕션	소스: Oracle 데이터베이스	대상: Amazon RDS 또는 Amazon Aurora
R 유형: 리아키텍트	워크로드: Oracle	기술: 데이터베이스, 마이그레이션
AWS 서비스: Amazon RDS, Amazon Aurora

요약

Oracle 데이터베이스를 Amazon RDS (Amazon RDS) 또는 Amazon Aurora로 마이그레이션할 때는 대상 데이터베이스의 CPU, 메모리 및 디스크 I/O를 계산하는 것이 핵심 요구 사항입니다. Oracle AWR (자동 워크로드 리포지토리) 보고서를 분석하여 대상 데이터베이스의 필요한 용량을 추정할 수 있습니다. 이 패턴은 AWR 보고서를 사용하여 이러한 값을 추정하는 방법을 설명합니다.

원본 오라클 데이터베이스는 온프레미스이거나 Amazon Elastic Compute Cloud (Amazon EC2) 인스턴스에 호스팅될 수 있으며, 또는 오라클용 Amazon RDS DB 인스턴스일 수도 있습니다. 대상 데이터베이스는 모든 Amazon RDS 또는 Aurora 데이터베이스가 될 수 있습니다.

참고: 대상 데이터베이스 엔진이 Oracle인 경우 예상 용량이 더 정확합니다. 다른 Amazon RDS 데이터베이스의 경우 데이터베이스 아키텍처의 차이로 인해 엔진 크기가 달라질 수 있습니다.

Oracle 데이터베이스를 마이그레이션하기 전에 성능 테스트를 실행하는 것이 좋습니다.

사전 조건 및 제한 사항

사전 조건

AWR 보고서를 다운로드하려면 오라클 데이터베이스 엔터프라이즈 에디션 라이센스와 오라클 진단 팩 라이센스가 필요합니다.

제품 버전

버전 11g (버전 11.2.0.3.v1 이상) 및 최대 12.2 및 18c,19c에 대한 모든 오라클 데이터베이스 에디션
이 패턴은 오라클 엔지니어드 시스템 또는 오라클 클라우드 인프라 (OCI) 에는 적용되지 않습니다.

아키텍처

소스 기술 스택

다음 중 하나입니다.

온프레미스 Oracle 데이터베이스
EC2 인스턴스의 Oracle 데이터베이스
Amazon RDS for Oracle DB 인스턴스

대상 기술 스택

모든 아마존 RDS 또는 아마존 Aurora 데이터베이스

대상 아키텍처

전체 마이그레이션 프로세스에 대한 자세한 내용은 AWS DMS 및 AWS SCT를 사용하여 Oracle 데이터베이스를 Aurora PostgreSQL로 마이그레이션하는 패턴을 참조하십시오.

자동화 및 규모 조정

마이그레이션할 Oracle 데이터베이스가 여러 개 있고 추가 성능 지표를 사용하려는 경우, Oracle 성능 지표를 기반으로 규모에 맞게 Amazon RDS 인스턴스 크기를 적절하게 조정하는 블로그 게시물에 설명된 단계에 따라 프로세스를 자동화할 수 있습니다.

도구

Oracle 자동 워크로드 리포지토리 (AWR) 는 Oracle 데이터베이스에 구축되는 리포지토리입니다. 시스템 활동 및 워크로드 데이터를 주기적으로 수집 및 저장한 다음 ADDM (자동 데이터베이스 진단 모니터) 에서 이를 분석합니다. AWR은 시스템 성능 데이터의 스냅샷을 주기적으로 (기본적으로 60분마다) 만들고 정보를 저장합니다 (기본적으로 최대 8일). AWR 보기와 보고서를 사용하여 이 데이터를 분석할 수 있습니다.

모범 사례

대상 데이터베이스의 리소스 요구 사항을 계산하려면 단일 AWR 보고서, 다중 AWR 보고서 또는 동적 AWR 보기를 사용할 수 있습니다. 최대 부하 기간에 여러 AWR 보고서를 사용하여 이러한 최대 부하를 처리하는 데 필요한 리소스를 추정하는 것이 좋습니다. 또한 동적 보기는 리소스 요구 사항을 더 정확하게 계산하는 데 도움이 되는 더 많은 데이터 포인트를 제공합니다.
마이그레이션하려는 데이터베이스에 대해서만 IOPS를 추정해야 하며 디스크를 사용하는 다른 데이터베이스 및 프로세스에 대해서는 IOPS를 추정하지 않아야 합니다.
데이터베이스에서 사용 중인 I/O의 양을 계산하려면 AWR 보고서의 Load Profile 섹션에 있는 정보를 사용하지 마십시오. 사용 가능한 경우 I/O 프로필 섹션을 대신 사용하거나, 인스턴스 활동 통계 섹션으로 건너뛰고 물리적 읽기 및 쓰기 작업의 총 값을 살펴보세요.
CPU 사용률을 추정할 때는 운영 체제 (OS) 통계 대신 데이터베이스 측정치 방법을 사용하는 것이 좋습니다. 데이터베이스에서만 사용하는 CPU를 기반으로 하기 때문입니다. (OS 통계에는 다른 프로세스의 CPU 사용량도 포함됩니다.) 또한 마이그레이션 후 성능을 개선하려면 ADDM 보고서에서 CPU 관련 권장 사항을 확인해야 합니다.
적절한 인스턴스 유형을 결정할 때는 특정 인스턴스 크기에 대한 I/O 처리량 제한, 즉 Amazon Elastic Block Store (Amazon Elastic Block Store) 처리량 및 네트워크 처리량을 고려하십시오.
마이그레이션하기 전에 성능 테스트를 실행하여 엔진 크기를 확인하십시오.

에픽

작업	설명	필요한 기술
AWR 보고서를 활성화합니다.	보고서를 활성화하려면 Oracle 설명서의 지침을 따르십시오.	DBA
보존 기간을 확인하세요.	AWR 보고서의 보존 기간을 확인하려면 다음 쿼리를 사용하십시오. `SQL> SELECT snap_interval,retention FROM dba_hist_wr_control;`	DBA
스냅샷을 생성하십시오.	AWR 스냅샷 간격이 최대 워크로드의 스파이크를 캡처할 만큼 세분화되지 않은 경우 AWR 보고서를 수동으로 생성할 수 있습니다. 수동 AWR 스냅샷을 생성하려면 다음 쿼리를 사용하십시오. `SQL> EXEC dbms_workload_repository.create_snapshot;`	DBA
최근 스냅샷을 확인하세요.	최근 AWR 스냅샷을 확인하려면 다음 쿼리를 사용하십시오. `SQL> SELECT snap_id, to_char(begin_interval_time,'dd/MON/yy hh24:mi') Begin_Interval, to_char(end_interval_time,'dd/MON/yy hh24:mi') End_Interval FROM dba_hist_snapshot ORDER BY 1;`	DBA

작업 설명 필요한 기술

방법을 선택합니다.

IOPS는 스토리지 디바이스의 초당 입력 및 출력 작업에 대한 표준 측정값이며, 읽기 및 쓰기 작업을 모두 포함합니다.

온프레미스 데이터베이스를 AWS로 마이그레이션하는 경우 데이터베이스에서 사용하는 최대 디스크 I/O를 결정해야 합니다. 다음 방법을 사용하여 대상 데이터베이스의 디스크 I/O를 추정할 수 있습니다.

AWR 보고서의 로드 프로필 섹션
AWR 보고서의 인스턴스 활동 통계 섹션 (Oracle Database 12c 이상의 경우 이 섹션 사용)
AWR 보고서의 I/O 프로파일 섹션 (12c 이전의 Oracle 데이터베이스 버전인 경우 이 섹션 사용)
AWR 보기

다음 단계는 이 네 가지 방법을 설명합니다.

DBA

옵션 1: 로드 프로필 사용.

다음 표는 AWR 보고서의 로드 프로필 섹션의 예를 보여줍니다.

중요: 더 정확한 정보를 얻으려면 로드 프로필 대신 옵션 2 (I/O 프로필) 또는 옵션 3 (인스턴스 작업 통계) 을 사용하는 것이 좋습니다.

	초당	거래당	경영진당	통화당
DB 시간 (초):	26.6	0.2	0.00	0.02
데이터베이스 CPU:	18.0	0.1	0.00	0.01
백그라운드 CPU:	0.2	0.0	0.00	0.00
다시 실행 크기 (바이트):	2,458,539.9	17,097.5
논리적 읽기 (블록):	3,371,931.5	23,449.6
블록 변경사항:	21,643.5	150.5
물리적 읽기 (블록):	13,575.1	94.4
물리적 쓰기 (블록):	3,467.3	24.1
입출력 요청 읽기:	3,586.8	24.9
입출력 요청 작성:	574.7	4.0
읽기 입출력 (MB):	106.1	0.7
쓰기 입출력 (메가바이트):	27.1	0.2
메신저 스캔 행:	0.0	0.0
세션 논리적 읽기 IM:
사용자 통화:	1,245.7	8.7
파싱 (SQL):	4,626.2	32.2
하드 파싱 (SQL):	8.9	0.1
SQL 작업 영역 (MB):	824.9	5.7
로그온:	1.7	0.0
실행 횟수 (SQL):	136,656.5	950.4
롤백:	22.9	0.2
트랜잭션:	143.8

이 정보를 기반으로 IOPS와 처리량을 다음과 같이 계산할 수 있습니다.

IOPS = 읽기 I/O 요청: + 쓰기 I/O 요청 = 3,586.8 + 574.7 = 4134.5

처리량 = 물리적 읽기 (블록) + 물리적 쓰기 (블록) = 13,575.1 + 3,467.3 = 17,042.4

Oracle의 블록 크기는 8KB이므로 총 처리량을 다음과 같이 계산할 수 있습니다.

총 처리량 (MB) 은 17042.4 * 8 * 1024/1024/1024 = 133.2MB입니다.

경고: 로드 프로필을 사용하여 인스턴스 크기를 추정하지 마십시오. 인스턴스 활동 통계 또는 I/O 프로필만큼 정확하지는 않습니다.

DBA

옵션 2: 인스턴스 활동 통계 사용.

12c 이전의 Oracle 데이터베이스 버전을 사용하는 경우 AWR 보고서의 인스턴스 활동 통계 섹션을 사용하여 IOPS 및 처리량을 추정할 수 있습니다. 다음 표에서는 이 섹션의 예제를 보여줍니다.

통계	합계	초당	트랜스당
물리적 읽기, 총 I/O 요청 수	2,547,333,217	3,610.28	25.11
물리적 읽기 총 바이트 수	80,776,296,124,928	114,482,426.26	796,149.98
물리적 쓰기 총 IO 요청 수	534,198,208	757.11	5.27
물리적 쓰기 총 바이트 수	25,517,678,849,024	36,165,631.84	251,508.18

이 정보를 기반으로 총 IOPS와 처리량을 다음과 같이 계산할 수 있습니다.

총 IOPS = 3,610.28 + 757.11 = 4367

총 Mbps = 114,482,426.26 + 36,165,631.84 = 150648058.1 / 1024 / 1024 = 143Mbps

DBA

옵션 3: I/O 프로필을 사용합니다.

Oracle Database 12c의 AWR 보고서에는 모든 정보를 단일 테이블에 표시하고 데이터베이스 성능에 대한 보다 정확한 데이터를 제공하는 I/O 프로필 섹션이 포함되어 있습니다. 다음 표에서는 이 섹션의 예제를 보여줍니다.

	초당 읽기+쓰기	초당 읽기	초당 쓰기
총 요청 수:	4,367.4	3,610.3	757.1
데이터베이스 요청:	4,161.5	3,586.8	574.7
최적화된 요청:	0.0	0.0	0.0
다시 실행 요청:	179.3	2.8	176.6
합계(MB):	143.7	109.2	34.5
데이터베이스(MB):	133.1	106.1	27.1
최적화된 합계(MB):	0.0	0.0	0.0
다시 실행(MB):	7.6	2.7	4.9
데이터베이스(블록):	17,042.4	13,575.1	3,467.3
버퍼 캐시를 통해(블록):	5,898.5	5,360.9	537.6
다이렉트(블록):	11,143.9	8,214.2	2,929.7

이 표는 처리량 및 총 IOPS에 대한 다음 값을 제공합니다.

처리량 = 143MBPS(합계로 표시된 다섯 번째 행, 두 번째 열부터)

IOPS = 4,367.4(총 요청 수로 표시된 첫 번째 행, 두 번째 열부터)

DBA

옵션 4: AWR 보기를 사용합니다.

AWR 보기를 사용하여 동일한 IOPS 및 처리량 정보를 볼 수 있습니다. 이 정보를 확인하려면 다음 쿼리를 사용합니다.


break on report
 compute sum of Value on report
 select METRIC_NAME,avg(AVERAGE) as "Value"
 from dba_hist_sysmetric_summary
 where METRIC_NAME in ('Physical Read Total IO Requests Per Sec','Physical Write Total IO Requests Per Sec')
 group by metric_name;

DBA

작업 설명 필요한 기술

방법을 선택합니다.

다음 세 가지 방법으로 대상 데이터베이스에 필요한 CPU를 추정할 수 있습니다.

프로세서의 실제 사용 가능한 코어 사용
OS 통계를 기반으로 활용된 코어 사용
데이터베이스 통계를 기반으로 활용된 코어 사용

코어를 사용하는 경우 OS 통계 대신 데이터베이스 지표 방법을 사용하는 것이 좋습니다. 마이그레이션하려는 데이터베이스에서만 사용하는 CPU를 기반으로 하기 때문입니다. (OS 통계에는 다른 프로세스의 CPU 사용량도 포함됩니다.) 또한 마이그레이션 후 성능을 개선하려면 ADDM 보고서에서 CPU 관련 권장 사항을 확인해야 합니다.

CPU 생성량을 기반으로 요구 사항을 추정할 수도 있습니다. 여러 세대의 CPU를 사용하는 경우 최적의 워크로드 성능을 위한 vCPU 수 설명 백서의 지침에 따라 대상 데이터베이스의 필요한 CPU를 추정할 수 있습니다.

DBA

옵션 1: 사용 가능한 코어를 기준으로 요구 사항을 추정합니다.

AWR 보고서:

CPU는 논리적 및 가상 CPU를 의미합니다.
코어는 물리적 CPU 칩셋의 프로세서 수입니다.
소켓은 칩을 보드에 연결하는 물리적 장치입니다. 멀티 코어 프로세서에는 여러 개의 CPU 코어가 포함된 소켓이 있습니다.

다음 두 가지 방법으로 사용 가능한 코어를 추정할 수 있습니다.

OS 명령 사용
AWR 보고서 사용

OS 명령을 사용하여 사용 가능한 코어를 추정하려면

다음 명령을 사용하여 프로세서의 코어 수를 계산합니다.


$ cat /proc/cpuinfo |grep "cpu cores"|uniq
cpu cores    : 4
cat /proc/cpuinfo | egrep "core id|physical id" | tr -d "\n" | sed s/physical/\\nphysical/g | grep -v ^$ | sort | uniq | wc -l

다음 명령을 사용하여 프로세서의 소켓 수를 계산합니다.


grep "physical id" /proc/cpuinfo | sort -u
  physical id     : 0
  physical id     : 1

참고: nmon, sar와 같은 OS 명령을 사용하여 CPU 사용률을 추출하는 것은 권장하지 않습니다. 이러한 계산에는 다른 프로세스의 CPU 사용률이 포함되며 데이터베이스에서 사용하는 실제 CPU가 반영되지 않을 수 있기 때문입니다.

AWR 보고서를 사용하여 사용 가능한 코어를 추정하려면

또한 AWR 보고서의 첫 번째 섹션에서 CPU 사용률을 도출할 수 있습니다. 다음은 보고서에서 발췌한 내용입니다.

DB 이름	DB Id		인스턴스		인스턴스 번호		시작 시간		릴리스		RAC
XXXX	<DB_ID>		XXXX		1		05-Sep-20 23:09		12.1.0.2.0		아니요
호스트 이름		플랫폼		CPU		코어		소켓		메모리(GB)
<host_name>		Linux x86 64비트		80		80		2		441.78

이 예제에서 CPU 개수는 80이며, 이는 논리적(가상) CPU임을 나타냅니다. 또한 이 구성에는 소켓 2개, 각 소켓에 물리적 프로세서 1개(물리적 프로세서 총 2개)가 있고 각 물리적 프로세서 또는 소켓에는 40개의 코어가 있다는 것도 알 수 있습니다.

DBA

옵션 2: OS 통계를 사용하여 CPU 사용률을 추정합니다.

OS CPU 사용량 통계는 OS에서 직접 확인(sar 또는 다른 호스트 OS 유틸리티 사용)하거나 AWR 보고서의 운영 체제 통계 섹션에서 IDLE/(IDLE+BUSY) 값을 검토하여 확인할 수 있습니다. v$osstat에서 직접 CPU 사용 시간(초)을 확인할 수 있습니다. AWR 및 Statspack 보고서는 운영 체제 통계 섹션에서도 이 데이터를 표시합니다.

동일한 상자에 여러 데이터베이스가 있는 경우 BUSY_TIME의 v$osstat 값은 모두 동일합니다.

통계	값	종료 값
FREE_MEMORY_BYTES	6,810,677,248	12,280,799,232
INACTIVE_MEMORY_BYTES	175,627,333,632	160,380,653,568
SWAP_FREE_BYTES	17,145,614,336	17,145,872,384
BUSY_TIME	1,305,569,937
IDLE_TIME	4,312,718,839
IOWAIT_TIME	53,417,174
NICE_TIME	29,815
SYS_TIME	148,567,570
USER_TIME	1,146,918,783
LOAD	25	29
VM_IN_BYTES	593,920
VM_OUT_BYTES	327,680
PHYSICAL_MEMORY_BYTES	474,362,417,152
NUM_CPUS	80
NUM_CPU_CORES	80
NUM_CPU_SOCKETS	2
GLOBAL_RECEIVE_SIZE_MAX	4,194,304
GLOBAL_SEND_SIZE_MAX	2,097,152
TCP_RECEIVE_SIZE_DEFAULT	87,380
TCP_RECEIVE_SIZE_MAX	6,291,456
TCP_RECEIVE_SIZE_MIN	4,096
TCP_SEND_SIZE_DEFAULT	16,384
TCP_SEND_SIZE_MAX	4,194,304
TCP_SEND_SIZE_MIN	4,096

시스템에 다른 주요 CPU 소비자가 없는 경우 다음 공식을 사용하여 CPU 사용률을 계산하세요.

사용률 = 바쁜 시간 / 총 시간

바쁜 시간 =요구 사항 = v$osstat.BUSY_TIME

C = 총 시간(Busy + Idle)

C = 용량 = v$ostat.BUSY_TIME + v$ostat.IDLE_TIME

사용률 = BUSY_TIME / (BUSY_TIME + IDLE_TIME)

= -1,305,569,937 / (1,305,569,937 + 4,312,718,839 )

= 23% 사용

DBA

옵션 3: 데이터베이스 메트릭을 사용하여 CPU 사용률을 추정합니다.

시스템에서 여러 데이터베이스가 실행 중인 경우 보고서 시작 부분에 나타나는 데이터베이스 지표를 사용할 수 있습니다.

	스냅 ID	스냅 시간	세션	커서/세션
시작 스냅:	184662	28-Sep-20 09:00:42	1226	35.8
종료 스냅:	185446	06-Oct-20 13:00:20	1876	41.1
경과:		11,759.64(분)
DB 시간:		312,625.40(분)

CPU 사용률 지표는 다음 공식을 사용하세요.

데이터베이스 CPU 사용량(사용 가능한 CPU 성능의 비율(%)) = CPU 시간 / NUM_CPUS / 경과 시=간

여기서 CPU 사용량은 CPU 시간으로 설명되며 CPU를 기다리는 시간이 아니라 CPU에 소요된 시간을 나타냅니다. 이 계산 결과는 다음과 같습니다.

= 312,625.40 / 11,759.64/80 = CPU의 33% 사용 중

코어 수(33%) * 80 = 26.4코어

총 코어 수 = 26.4 * (120%) = 31.68코어

이 두 값 중 더 큰 값을 사용하여 Amazon RDS 또는 Aurora DB 인스턴스의 CPU 사용률을 계산할 수 있습니다.

참고: IBM AIX에서는 계산된 사용률이 운영 체제 또는 데이터베이스의 값과 일치하지 않습니다. 이러한 값은 다른 운영 체제에서는 일치합니다.

DBA

작업

설명

필요한 기술

메모리 통계를 사용하여 메모리 요구 사항을 추정합니다.

AWR 보고서를 사용하여 원본 데이터베이스의 메모리를 계산하고 대상 데이터베이스와 일치시킬 수 있습니다. 또한 기존 데이터베이스의 성능을 확인하고 메모리 요구 사항을 줄여 비용을 절감하거나 요구 사항을 높여 성능을 향상시켜야 합니다. 이를 위해서는 AWR 응답 시간과 애플리케이션의 서비스 수준에 관한 계약(SLA)에 대한 상세한 분석이 필요합니다. Oracle 시스템 글로벌 영역(SGA)와 프로그램 글로벌 영역(PGA) 사용량의 합계를 Oracle에 대한 예상 메모리 사용률로 사용합니다. 대상 메모리의 크기 요구 사항을 결정하려면 OS에 20%를 추가합니다. Oracle RAC의 경우 공통 블록에 저장되므로 모든 RAC 노드의 예상 메모리 사용률 합계를 사용하고 총 메모리를 줄이세요.

인스턴스 효율성 백분율 표에서 지표를 확인하세요. 표에서는 다음 용어를 사용합니다.

버퍼 검색% 결과 는 물리적 I/O를 수행하지 않고 버퍼 캐시에서 특정 블록을 발견한 횟수의 백분율입니다. 성능을 높이려면 100%를 목표로 하세요.
버퍼 노웨이트 %는 100%에 가까워야 합니다.
래치 검색 결과 %는 100%에 가까워야 합니다.
% 비구문분석 CPU는 비구문분석 작업에 소요된 CPU 시간의 백분율입니다. 이 값은 100%에 가까워야 합니다.

인스턴스 효율성 백분율(목표 100%)

버퍼 노웨이트 %:	99.99	다시 실행% NoWait :	100.00
버퍼 검색 결과 %:	99.84	인메모리 정렬 %:	100.00
라이브러리 검색 결과 %:	748.77	소프트 구문 분석 %:	99.81
구문 분석을 위한 실행 %:	96.61	래치 검색 결과 %:	100.00
구문 분석 CPU에서 구문 분석 경과 %:	72.73	% 비 구문 분석 CPU:	99.21
플래시 캐시 검색 결과 %:	0.00

이 예시에서는 모든 지표가 괜찮아 보이므로 기존 데이터베이스의 SGA 및 PGA를 용량 계획 요구 사항으로 사용할 수 있습니다.

메모리 통계 섹션을 확인하고 SGA나 PGA를 계산하세요.

시작
종료
호스트 메모리(MB):
452,387.3
452,387.3
SGA 사용량(MB):
220,544.0
220,544.0
PGA 사용량(MB):
36,874.9
45,270.0

사용 중인 총 인스턴스 메모리 = SGA + PGA = 220GB + 45GB = 265GB

버퍼를 20% 추가하세요.

총 인스턴스 메모리 = 1.2 * 265GB = 318GB

SGA와 PGA가 호스트 메모리의 70%를 차지하므로 총 메모리 요구 사항은 다음과 같습니다.

총 호스트 메모리 = 318/0.7 = 464GB

참고: Amazon RDS for Oracle로 마이그레이션하는 경우 PGA와 SGA는 사전 정의된 공식을 기반으로 사전 계산됩니다. 사전 계산된 값이 추정치와 비슷한지 확인하세요.

DBA

작업	설명	필요한 기술
디스크 I/O, CPU 및 메모리 추정치를 기반으로 DB 인스턴스 유형을 결정합니다.	이전 단계의 추정치를 바탕으로 대상 Amazon RDS 또는 Aurora 데이터베이스의 용량은 다음과 같아야 합니다. 68코어 CPU 143MBPS 처리량 4367 IOPS의 디스크 I/O 464GB 메모리 대상 Amazon RDS 또는 Aurora 데이터베이스에서 이러한 값을 32코어 용량, 512GB RAM, 13,600Mbps의 처리량을 갖춘 db.r5.16xlarge 인스턴스 유형에 매핑할 수 있습니다. 자세한 내용은 Oracle 성능 지표를 기반으로 한 규모에 맞는 적절한 크기의 Amazon RDS 인스턴스 AWS 블로그 게시물을 참조하세요.	DBA

작업

설명

필요한 기술

디스크 I/O, CPU 및 메모리 추정치를 기반으로 DB 인스턴스 유형을 결정합니다.

이전 단계의 추정치를 바탕으로 대상 Amazon RDS 또는 Aurora 데이터베이스의 용량은 다음과 같아야 합니다.

68코어 CPU
143MBPS 처리량
4367 IOPS의 디스크 I/O
464GB 메모리

대상 Amazon RDS 또는 Aurora 데이터베이스에서 이러한 값을 32코어 용량, 512GB RAM, 13,600Mbps의 처리량을 갖춘 db.r5.16xlarge 인스턴스 유형에 매핑할 수 있습니다. 자세한 내용은 Oracle 성능 지표를 기반으로 한 규모에 맞는 적절한 크기의 Amazon RDS 인스턴스 AWS 블로그 게시물을 참조하세요.

DBA