권장 사항 리호스팅

데이터베이스 할당 공간이 384TiB를 초과합니다. 여기에는 데이터베이스 파일, 다시 실행 로그, TEMP 스페이스, UNDO 스페이스, 플래시백 복구 영역 공간 및 데이터 스테이징 영역이 포함되지만 이에 국한되지 않습니다. Amazon EBS io2 Block Express 볼륨은 단일 EC2 인스턴스에서 최대 1.536 PiB를 지원할 수 있습니다.

밀리초 미만의 범위에서 스토리지 지연 시간이 필요합니다.

Amazon EBS gp3 볼륨의 99.9% 내구성에 비해 999% 내구성을 제공하도록 설계된 데이터베이스가 필요합니다.

단일 EC2 인스턴스에 1백만 IOPS 이상을 제공하려면 가상 스토리지 어레이가 필요합니다.

Exadata 스마트 플래시 캐시 및 Exadata 스마트 플래시 로깅은 Exadata 온프레미스 시스템에서 매우 높습니다. Exadata 스마트 플래시 캐시의 I/O 지연 시간은 일반적으로 읽기 작업의 경우 400마이크로초 미만입니다. Amazon EBS io2 Block Express의 I/O 지연 시간은 일반적으로 400~600마이크로초입니다.

Oracle ASM 필터 드라이버(ASMFD)를 사용하여 ASM을 구현합니다.

디스크 그룹의 모든 Oracle ASM 디스크의 스토리지 성능과 가용성 특성이 유사한지 확인합니다. 플래시 메모리 및 하드 디스크 드라이브(HDD)와 같은 혼합 속도 드라이브가 있는 스토리지 구성에서 I/O 성능은 가장 느린 속도 드라이브에 의해 제한됩니다.

균형을 유지하기 위해 디스크 그룹의 Oracle ASM 디스크의 용량이 동일한지 확인합니다.

Oracle ASM은 데이터를 선택한 ASM 디스크 세트에 무작위로 배포합니다. 시스템의 스토리지를 구성할 때 시스템의 초기 용량을 고려하고 향후 성장을 계획합니다. Oracle ASM은 성장 수용 작업을 간소화합니다. 앞서 언급했듯이 Amazon EC2 Nitro System 인스턴스는 최대 28개의 볼륨을 지원합니다. DATA ASM 디스크 그룹에 96TiB가 필요한 경우 16개의 6TiB Amazon EBS io2 Block Express 볼륨보다 24TiB Amazon EBS io2 Block Express 볼륨 4개를 선택하는 것이 좋습니다.

두 ASM 디스크 그룹에서 최소 두 개의 제어 파일을 설정합니다.

EC2 인스턴스 종료 보호를 활성화합니다. 이렇게 하면 사용자가 인스턴스를 종료하기 전에 보호를 비활성화하도록 요구하여 EC2 인스턴스가 실수로 종료되는 것을 방지할 수 있습니다.

EC2 인스턴스를 호스팅하는 하드웨어가 손상된 경우 문제를 해결하는 Amazon EC2 자동 복구 기능을 활성화합니다. EC2 이 기능은 서로 다른 기본 하드웨어에서 인스턴스를 복구하고 수동 개입의 필요성을 줄입니다.

Amazon EC2는 최대 24TiB의 메모리가 있는 인스턴스를 제공합니다. 이러한 인스턴스는 매우 큰 Oracle SGAs 지원하므로 다중 TiB Oracle SGAs를 사용하는 경우 가장 먼저 선택해야 합니다. 그러나 많은 EC2 인스턴스와 Amazon RDS for Oracle 인스턴스는 로컬 인스턴스 스토리지도 지원합니다. NVMe SSD 인스턴스 스토리지와 함께 Amazon EC2 또는 Amazon RDS for Oracle 인스턴스를 사용하는 경우 임시 스토리지를 사용하여 Oracle SGA 데이터베이스 블록 버퍼를 확장할 수 있습니다. https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Oracle.advanced-features.instance-store.html 이 접근 방식을 사용하면 인스턴스 스토리지를 사용하여 객체를 캐싱할 수 있으며 읽기 작업에 평균 I/O 지연 시간이 100마이크로초입니다. 스마트 플래시 캐시 및/ 레벨 2 플래시 캐시는 인스턴스 스토리지를 사용하고 Oracle Linux 운영 체제가 필요한 인스턴스에서만 작동합니다. OLTP 및 데이터 웨어하우스 환경은이 기술의 이점을 누릴 수 있습니다. 스마트 플래시 캐시를 사용하려면 Oracle 초기화 파라미터 DB_FLASH_CACHE_FILE 및 DB_FLASH_CACHE_SIZE를 설정합니다.

Oracle Linux를 인스턴스의 운영 체제로 사용합니다. Oracle Linux가 옵션이 아닌 경우 Red Hat Enterprise Linux(RHEL)를 고려하세요. Oracle이 ARM 프로세서용으로 컴파일된 Oracle Database 바이너리를 릴리스하지 않았기 때문에 Graviton 프로세서를 기반으로 하는 EC2 인스턴스는 Oracle 데이터베이스를 지원하지 않습니다. 또한 Amazon Linux는 Oracle 데이터베이스에서 지원되지 않습니다.

Oracle 소프트웨어의 최신 릴리스를 사용하여 Oracle Grid Infrastructure를 설치합니다. 이전 버전의 Oracle Database를 사용하여 Oracle Grid Infrastructure의 최신 릴리스를 배포할 수 있습니다. 예를 들어 Oracle Grid Infrastructure 21c는 Oracle Database 19c를 지원합니다.

Oracle RMAN 또는 Oracle Data Guard를 사용하여 이전 버전의 Oracle Database on Exadata에서 마이그레이션하는 경우 마이그레이션 후 데이터베이스 릴리스를 최신 버전으로 업그레이드하는 것이 좋습니다. Oracle Data Pump를 사용하는 경우 마이그레이션 AWS 전에에 최신 Oracle Database 릴리스를 설치합니다.

Oracle 플래시 복구 영역(FRA)을 사용하면 RMAN 백업을 사용하지 않고도 데이터베이스를 빠르게 복원할 수 있습니다. 가능하면 FRA를 최소 1일로 설정합니다. Oracle 초기화 파라미터 DB_RECOVERY_FILE_DEST_SIZE, DB_RECOVERY_FILE_DEST및를 설정해야 합니다DB_FLASHBACK_RETENTION_TARGET(분 단위의 시간 표시).

여러 데이터베이스 워크로드를 단일 EC2 인스턴스로 마이그레이션하는 경우 Oracle Database Resource Manager를 구현하여 데이터베이스 리소스 할당을 관리하는 것이 좋습니다.

독립 실행형 SPFILE 대신 Oracle을 구현합니다PFILE. SPFILE는 인스턴스를 다시 시작할 필요 없이 동적 수정을 허용하는 이진 파일입니다. 가 사용 중인 경우 STARTUP 명령을 사용할 PFILE 때 SPFILE를 지정하지 마십시오.

SGA 메모리 관리를 간소화하는 Oracle Automatic Shared Memory Manager(ASMM)를 활성화합니다. Oracle Database는 가장 효과적인 메모리 사용률을 보장하기 위해 SGA 구성 요소 간에 메모리를 자동으로 분산합니다.

데이터베이스 라이터 프로세스(DBWR)에서 Oracle db 파일 병렬 쓰기 대기 이벤트가 발생할 수 있습니다. 이 대기 시간은 DBWR이 I/O 완료를 기다리는 시간을 나타냅니다. 이 문제를 해결하려면 비동기 I/O가 활성화되었는지 확인하고(Oracle 초기화 파라미터 DISK_ASYNCH_IO), EBS 볼륨의 IOPS를 늘리고, 데이터베이스 버퍼 캐시가 스래싱을 방지할 수 있을 만큼 충분히 큰지 확인합니다.

EC2 인스턴스에 대해 주기적으로(최소 2주마다) 스캔을 실행하고 규정 준수를 확인합니다. 이 스캔에 Amazon Inspector를 사용할 수 있습니다. Amazon Inspector는 배포된 애플리케이션의 보안 및 규정 준수를 개선하는 데 도움이 되는 자동화된 보안 평가 서비스입니다 AWS. 애플리케이션의 노출, 취약성 및 모범 사례와의 편차를 자동으로 평가합니다. 평가를 수행한 후 심각도 수준에 따라 우선 순위가 지정된 보안 조사 결과의 세부 목록을 생성합니다. 이러한 결과를 직접 검토하거나 Amazon Inspector 콘솔 또는 API를 통해 사용할 수 있는 세부 평가 보고서에서 검토할 수 있습니다.

에 대한 Amazon CloudWatch 경보를 설정합니다AWS CloudTrail. 예를 들어 보안 그룹에서 구성 변경이 발생하면 CloudWatch 경보를 활성화해야 합니다. 이렇게 하면 누군가 EC2 인스턴스에 액세스하려고 할 때 운영 팀에 알립니다.

조직에 0 또는 0에 가까운 복구 시점 목표(RPO)가 필요한 경우 최대 가용성 모드에서 Oracle Data Guard 또는 Oracle Active Data Guard를 사용합니다. 대기 데이터베이스는 기본 데이터베이스와 다른 가용 영역에 있어야 합니다. 최대 보호 및 최대 가용성 모드는 데이터 손실 없이 설계된 자동 장애 조치 환경을 제공합니다. 최대 성능 모드는 FastStartFailoverLagLimit 구성 속성에 지정된 데이터 양(초)을 초과하여 손실되지 않도록 설계된 자동 장애 조치 환경을 제공합니다. 또한 Oracle Data Guard 또는 Oracle Active Data Guard를 사용하여 Data Guard 브로커를 구현하는 것이 좋습니다. Data Guard 브로커는 Data Guard의 구성 및 모니터링 작업을 자동화합니다. Active Data Guard에는 Oracle 라이선스가 필요합니다.

Oracle Active Data Guard 자동 블록 미디어 복구를 사용하는 것이 좋습니다. 기본 데이터베이스에 액세스할 때 손상된 데이터 블록이 발생하면 블록은 물리적 대기 데이터베이스에서 해당 블록의 손상되지 않은 복사본으로 자동으로 대체됩니다. 그러나이 기능을 사용하려면 Active Data Guard가 최대 가용성 모드에서 실행되고 Oracle 초기화 파라미터가 SYNC 다시 실행 전송 모드로 LOG_ARCHIVE_DEST_n 설정되어 있어야 합니다. 최대 성능 모드는이 기능을 지원하지 않습니다.

조직에 리전 간 재해 복구가 필요한 경우 Oracle Far Sync를 구현하는 것이 좋습니다. Far Sync에는 Oracle Active Data Guard 라이선스가 필요합니다.

Oracle Secure Backup(OSB)을 사용하여 Oracle RMAN을 사용하여 데이터베이스를 Amazon S3에 백업합니다. OSB에는 Oracle 라이선스가 필요합니다. OSB 요금은 사용 중인 Oracle RMAN 채널 수를 기준으로 합니다. AWS Storage Gateway를 사용하여 데이터베이스를 Amazon S3에 직접 백업할 수도 있습니다. Amazon S3의 백업에 수명 주기 정책을 적용하여 아카이브를 위해 이전 백업을 Amazon Glacier로 이동할 수 있습니다.