기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
동종 데이터베이스 마이그레이션 고려 사항
이 섹션에서는 동종 마이그레이션의 주요 모범 사례를 설명합니다. 온프레미스에서 Exadata에서 Oracle용 Amazon RDS 또는 Amazon EC2의 Oracle로 데이터베이스를 마이그레이션할 때는 다음 하위 섹션에서 설명하는 지침을 고려하십시오.
암호화(Encryption)
데이터 보안은 최우선 과제입니다. AWS AWS 고객의 기밀성, 무결성 및 가용성을 보호하기 위해 엄격한 계약, 기술 및 조직 조치를 구현했습니다. 데이터베이스의 경우 개인 정보와 민감한 데이터를 보호하므로 암호화가 매우 중요합니다. Amazon EC2 기반 Oracle 및 Oracle용 Amazon RDS는 미사용 데이터에 대해 두 가지 암호화 방법을 지원합니다.
-
AWS Key Management Service (AWS KMS) Amazon EBS 볼륨을 암호화합니다.
-
Oracle 고급 보안 옵션 투명 데이터 암호화 (TDE)
는 데이터 파일에 저장된 민감한 정보를 암호화합니다. Oracle TDE에는 오라클 라이선스가 필요합니다.
두 옵션 모두 Oracle 데이터베이스와 모든 데이터베이스 백업의 사용자 데이터를 암호화합니다. 또한 암호화는 애플리케이션에서 실행되는 DML 명령문에 영향을 주지 않습니다.
전송 중인 데이터의 경우 Amazon EC2의 오라클과 Oracle용 Amazon RDS는 오라클 네이티브 네트워크 암호화 (NNE) 를 지원합니다. NNE 지원에 대한 자세한 내용은 Amazon RDS 설명서를 참조하십시오.
데이터 파티셔닝
Oracle 파티셔닝을 사용하면 테이블 또는 인덱스와 같은 데이터베이스의 단일 논리적 객체가 더 작은 물리적 데이터베이스 객체로 분할되므로 관리 용이성, 성능 및 가용성이 향상됩니다. Oracle 파티셔닝에는 Oracle 라이선스가 필요합니다.
데이터베이스 워크로드가 큰 경우 테이블 파티셔닝을 고려해 보세요. 파티션 프루닝을 사용하면 Oracle Database Optimizer가 SQL 문을 FROM
분석하고 WHERE
절하여 파티션 액세스 목록을 작성할 때 불필요한 파티션을 제거할 수 있습니다. Oracle 데이터베이스는 SQL 문과 관련된 파티션에서만 작업을 수행하므로 일반적으로 성능이 향상됩니다.
파티셔닝은 가용성을 높이는 데도 도움이 됩니다. 파티션이 오프라인 상태가 되고 SQL 문에서 작업을 완료하는 데 오프라인 파티션이 필요하지 않은 경우 SQL 문은 정상적으로 실행됩니다. 그러나 파티셔닝되지 않은 Oracle Database 테이블에서 데이터 블록이 손실되면 복원 작업이 완료될 때까지 전체 테이블을 사용할 수 없습니다.
데이터 압축
데이터 압축을 위해 Oracle은 HCC와 고급 압축을 모두 제공합니다. 고급 압축은 관계형 데이터 (테이블), 비정형 데이터 (파일), 인덱스, Data Guard 리두 데이터, 네트워크 데이터, RMAN 백업 및 기타 유형의 데이터에 대한 데이터베이스 스토리지 공간을 줄임으로써 성능을 향상시키고 스토리지 비용을 절감합니다. 또한 고급 압축은 메모리 및 네트워크 대역폭을 비롯한 데이터베이스 인프라 구성 요소의 성능을 향상시킬 수 있습니다.
Oracle 설명서에
ILM 전략
정보 수명 주기 관리 (ILM) 는 데이터베이스의 정보를 사용 빈도에 따라 관리하는 데 도움이 되는 프로세스, 정책 및 구성 요소를 제공합니다. Exadata에서 Oracle AWS on으로 마이그레이션할 때는 데이터를 마이그레이션하기 전 또는 이후에 데이터를 제거할 수 있는지 여부를 결정해야 합니다. AWS AWS에서는 규칙을 적용하여 특정 기간 동안만 데이터를 유지할 수 있습니다. Oracle 파티셔닝 및 Oracle 고급 압축을 구현하여 데이터 라이프사이클 정책을 설정할 수 있습니다. 이렇게 하면 비즈니스 지원에 필요한 데이터만 유지하면서 성능을 개선할 수 있습니다.
예를 들어 몇 테비바이트의 압축되지 않은 데이터를 사용하는 테이블이 있다고 가정해 보겠습니다. 현재 12년의 데이터가 있고 데이터를 14년 동안 보관해야 합니다. 전체 쿼리의 약 90% 가 2년 미만의 데이터에 액세스합니다. 일반적으로 데이터 사용량을 월별, 분기별, 연도별로 비교합니다. 30개월 후에는 데이터를 업데이트할 수 없지만 최대 12년이 지난 과거 데이터에 액세스해야 하는 경우가 있습니다. 이 경우 다음과 같은 ILM 정책을 고려할 수 있습니다.
-
고급 압축을 구현하십시오. 고급 압축과 함께 Oracle 히트맵과 자동 데이터 최적화 (ADO) 를 활용하십시오.
-
날짜 열에 간격 파티셔닝을 설정합니다.
-
14년이 넘은 파티션을 월 단위로 삭제하는 함수를 사용하세요.
-
읽기 전용 테이블스페이스를 사용하여 30개월 이상 지난 데이터를 보관하세요. 읽기 전용 테이블스페이스의 주된 목적은 데이터베이스의 대용량의 정적 부분을 백업하고 복구할 필요가 없도록 하는 것입니다 (Amazon EC2에서 Oracle RMAN과 Oracle을 함께 사용하는 경우). 읽기 전용 테이블스페이스는 사용자가 수정할 수 없도록 기록 데이터를 보호하는 방법도 제공합니다. 테이블스페이스를 읽기 전용으로 설정하면 사용자의 업데이트 권한 수준과 상관없이 테이블스페이스의 모든 테이블을 업데이트할 수 없습니다.
사용자는 종종 활성 데이터, 자주 액세스하지 않는 데이터 및 아카이브 데이터를 단일 Oracle 데이터베이스에 저장합니다. Oracle 데이터베이스를 마이그레이션하는 동안 자주 액세스하지 않는 데이터 AWS, 과거 감사 데이터 및 아카이브 데이터를 Amazon S3 또는 Amazon
OEM 통합
Oracle 워크로드를 로 마이그레이션할 AWS때는 Oracle 엔터프라이즈 매니저 (OEM) 클라우드 제어를 기반으로 AWS구현하는 것이 좋습니다. OEM은 Oracle 환경 관리를 위한 단일 인터페이스를 제공하는 오라클의 관리 플랫폼입니다.
아마존 EC2 기반 오라클과 오라클용 아마존 RDS는 OEM 환경의 타겟이 될 수 있습니다. Amazon EC2 기반 오라클은 오라클 온프레미스와 동일한 프로세스를 따라 OEM과 통합합니다. Oracle용 Amazon RDS에서 OEM을 활성화하려면:
-
AWS Management Console 로그인하고 https://console.aws.amazon.com/rds/
에서 Amazon RDS 콘솔을 엽니다. -
탐색 창에서 옵션 그룹을 선택합니다.
-
새
OEM_AGENT
옵션 그룹 또는 기존 옵션 그룹에 옵션을 추가합니다. -
OEM 관리 서버 호스트 이름, 포트, OEM 에이전트 등록 암호를 비롯한 OEM 구성 정보를 추가합니다.
Oracle용 Amazon RDS와 Amazon EC2의 오라클은 온프레미스에서 실행되는 OEM 환경의 대상이 될 수도 있습니다. 하지만 이를 위해서는 방화벽을 통해 모든 OEM 포트에 액세스할 수 있어야 합니다.
아마존 CloudWatch 통합
Amazon은 로그, 지표 및 이벤트의 형태로 모니터링 및 운영 데이터를 CloudWatch 수집합니다. 온프레미스와 온프레미스에서 AWS 실행되는 AWS 리소스, 애플리케이션 및 서비스를 통합적으로 볼 수 있는 자동화된 대시보드를 사용하여 데이터를 시각화합니다. Amazon EC2에서 호스팅되는 오라클 데이터베이스와 Oracle용 Amazon RDS에서 사용할 수 있습니다. CloudWatch
CloudWatch Amazon Simple Notification Service (Amazon SNS) 가 통합되어 모든 활성 Amazon SNS 알림에 대한 지표를 수집, 확인 및 분석할 수 있습니다. 예를 들어, Oracle Database 경고 로그의 특정 Oracle 오류 메시지와 같은 특정 작업이 발생할 경우 이메일 알림 또는 SMS를 보내도록 경보를 설정할 수 있습니다.
Amazon EC2에서 CloudWatch Oracle과 함께 Amazon SNS를 사용하려면 Oracle 경고 로그, 감사 로그, 추적 로그, OEM 로그 및 리스너 로그를 푸시할 CloudWatch 에이전트를 설치해야 합니다. CloudWatch Amazon RDS for Oracle을 배포하는 경우 이러한 로그를 전송할 CloudWatch 수 있도록 Oracle 인스턴스를 수정해야 합니다. CloudWatch 통합에 대한 자세한 내용은 Amazon SNS 설명서에서 Amazon SNS 주제 모니터링을 참조하십시오. CloudWatch
또한 Amazon RDS for Oracle에는 CPU 사용률, 데이터베이스 연결 수, 사용 가능한 메모리, 여유 스토리지 공간, 스토리지 IOPS, 디스크 처리량, 복제 지연 등 수십 가지 이벤트에 대한 경보가 CloudWatch 내장되어 있습니다.
온프레미스에서 Exadata로 마이그레이션하는 대부분의 사용자는 OEM을 AWS 계속 사용하고 AWS의 Oracle CloudWatch 데이터베이스와도 통합합니다.
데이터베이스 옵티마이저 통계
Oracle Database 최적기 통계는 데이터베이스와 해당 테이블, 열, 인덱스 및 시스템에 대한 정보를 제공합니다. 최적기는 이 정보를 사용하여 쿼리의 테이블, 파티션 또는 인덱스에서 검색되는 행 및 바이트 수를 추정하고, 액세스 비용을 추정하고, 비용이 가장 낮은 SQL 실행 계획을 선택합니다.
Oracle RMAN을 통해 Exadata 온 프레미스 데이터베이스를 Amazon EC2에 복원하는 경우 오라클은 Exadata 환경을 반영하는 통계를 자동으로 제공합니다. Exadata 데이터베이스를 Amazon EC2에 복원하거나 Amazon RDS for Oracle에서 초기 로드가 완료되는 즉시 통계를 수집하는 것이 가장 좋습니다. 이 작업은 Oracle DBMS_STATS 패키지를 실행하여 수행할 수 있습니다.
AWR 설정
오라클 자동 워크로드 리포지토리 (AWR) 는 오라클 데이터베이스의 성능 관련 통계를 저장합니다. 기본적으로 Oracle 데이터베이스는 1시간에 한 번씩 스냅샷을 생성하고 이 스냅샷을 8일 동안 보존합니다. 스냅샷을 수동으로 생성 또는 삭제하고 스냅샷 설정을 수정할 수 있습니다.
프로덕션 Oracle 데이터베이스의 경우 AWR 보존 기간을 60일 또는 90일로 늘리고 AWR 간격을 15분 또는 30분으로 줄여야 합니다. 이러한 설정은 month-over-month 비교를 지원하며 AWR 데이터를 볼 때 더 세분화된 정보를 제공합니다. 이러한 변경은 비교적 작은 데이터베이스 공간 (기가바이트로 측정) 을 소비하며 추가 기록의 이점을 제공합니다. AWR 보존 기간을 60일로 설정하고 AWR 간격을 15분으로 설정하려면 다음 명령을 실행합니다 (매개변수 값은 분 단위).
BEGIN
DBMS_WORKLOAD_REPOSITORY.modify_snapshot_settings
(interval => 15,
retention => 86400
);
END;
/
Oracle RMAN 또는 Oracle Data Guard를 사용하여 Exadata 온 프레미스 데이터베이스를 Amazon EC2의 오라클로 마이그레이션하는 경우, 데이터베이스가 Exadata에서 실행되는 동안 캡처된 AWR 스냅샷을 삭제해야 합니다. 이렇게 하려면 의 절차를 사용하십시오. DBMS_WORKLOAD_REPOSITORY.DROP_SNAPSHOT_RANGE
AWS
오라클 RAC 고려 사항
Exadata는 기본적으로 Oracle Real Application Clusters (RAC) 를 사용합니다. 이 RAC (Real Application Clusters) 를 사용하면 여러 서버에서 단일 Oracle 데이터베이스를 실행하여 가용성을 극대화하고 수평적 확장이 가능합니다. Oracle RAC는 공유 스토리지를 사용합니다. 가장 작은 Exadata 오퍼링에는 Oracle RAC를 사용하여 구성된 두 개의 노드가 포함됩니다.
RPO 요구 사항이 0이고 RTO 요구 사항이 2분 이하인 경우 다중 AZ를 사용하여 Amazon RDS for Oracle을 구현할 수 있습니다. 이 구성은 99.95% 의 월간 가동 시간을 제공하며, 이는 Oracle RAC를 사용하는 관리형 Oracle 데이터베이스를 비롯한 업계의 모든 관리형 Oracle 클라우드 데이터베이스와 같거나 그보다 나은 수준입니다.
또한 Amazon EC2의 Oracle을 사용하면 Oracle MAA (최대 가용성 아키텍처) 의 여러 구성 요소를 사용하여 고가용성
또한 Oracle RAC를 구축할 수 있는 다양한 대안도 있습니다. AWS의 RAC 옵션에 AWS대해 자세히 알아보려면 AWS 계정 팀에 문의하는 것이 좋습니다.
동종 마이그레이션을 위한 추가 모범 사례
개발자는 Exadata를 구현할 때 SQL 튜닝 기법과 모범 사례를 무시하는 경우가 많습니다. Exadata는 많은 설계 문제를 숨기므로 SQL 문은 허용 가능한 경과 시간 내에 완료되기 때문에 실행 계획이나 리소스 사용량을 평가하지 않고도 프로덕션 환경에 배포될 수 있습니다. Exadata 온프레미스 데이터베이스를 Oracle on으로 마이그레이션할 때는 다음과 같은 추가 방법을 따르십시오. AWS
-
최신 Oracle 릴리스 업데이트 (RU) 또는 릴리스 업데이트 수정 버전 (RUR) 을 적용합니다.
-
COMPATIBLE
초기화 매개변수에 세 가지 수준 (예: 19.0.0) 만 포함되어 있는지 확인하십시오. 로 마이그레이션한 후 업그레이드를 수행하는 경우 업그레이드 프로세스 중에 이 매개 변수를 수정해야 AWS합니다. -
I/O를 최소화하려면 시퀀스 번호를 캐싱하는 것이 좋습니다. 기본값은 20입니다. 시퀀스 번호의 캐싱이 충분하지 않으면 경합이 발생할 수 있으며, 이는 DML의 서비스 시간 증가로 나타납니다.
-
시퀀스를 사용하는 경우 소스 데이터베이스 (Exadata 온프레미스) 와 비교하여 시퀀스 값의 유효성을 검사하여 시퀀스 불일치를 방지하십시오.
-
응용 프로그램 계층에 연결 풀링이 구현되지 않았거나 응용 프로그램 계층 수로 인해 데이터베이스 연결 수가 매우 많은 경우 Oracle Database 상주 연결 풀링
(DRCP) 구현을 고려해 보십시오. 이 기능은 데이터베이스 서버의 메모리 및 컴퓨팅 리소스를 효율적으로 처리합니다. -
사용을 고려해 보세요 HugePages. 오라클은 HugePages Linux용 표준을 사용할 것을 권장합니다. HugePages활성화하면 운영 체제가 기본값 (보통 4KB) 보다 큰 메모리 페이지를 지원할 수 있습니다. 매우 큰 페이지 크기를 사용하면 페이지 테이블 항목에 액세스하는 데 필요한 시스템 리소스의 양을 줄여 시스템 성능을 향상시킬 수 있습니다.
-
의 오라클 데이터베이스에 데이터베이스 링크가 있는 경우
OPEN_LINKS
및OPEN_LINKS_PER_INSTANCE
초기화 매개변수가 기본값으로 설정되어 있지 않은지 확인하십시오 (4). AWS 이 값이 너무 낮으면 데이터베이스 링크가 있는 SQL 문이 최대값에 도달했을 때 대기열에 들어가기 시작하여 성능에 부정적인 영향을 줍니다. -
초기 데이터 로드는 네트워크를 통해 전송되지 않을 수 있습니다. 예를 들어, 이론적으로 1Gbps 링크를 통해 100TiB를 전송하려면 중단 없이 최소 9일이 걸립니다. AWS Snow Family
디바이스를 사용하여 데이터베이스를 마이그레이션하는 것이 더 나은 방법입니다. AWS -
Exadata와 관련된 숨겨진 매개 변수를 모두 제거합니다 (Oracle MOS Note 1274318.1 참조). 이러한 숨겨진 Exadata 초기화 매개변수는 활성화해서는 안 됩니다. AWS이로 인해 불안정, 성능 문제, 손상 및 충돌이 발생할 수 있습니다.
-
데이터를 Oracle로 마이그레이션한 후에는
SYSTEM
유효하지 않은 객체SYS
및 유효하지 않은 객체를 모두 해결해 보십시오. AWS -
자주 액세스하는 정적 테이블을 Oracle 시스템 글로벌 영역 (SGA) 에 캐싱하는 것을 고려해 보십시오.
-
더 큰 Oracle SGA 구성을 갖춘 메모리 최적화 인스턴스를 선택하여 추가 I/O 실행 문제를 완화하십시오. AWS대상 인스턴스에서 부하를 테스트하는 동안 Oracle SGA 권고 보고서를 사용하여 최적의 Oracle SGA 구성을 찾을 수 있습니다.
-
여러 개의 전체 테이블 스캔을 처리하는 테이블에 인덱스를 생성합니다.
V$SEGMENT_STATISTICS
뷰에는 후보 세그먼트가 나열됩니다. -
리소스를 많이 사용하는 상위 쿼리를 식별하고 이를 최적화하여 더 나은 실행 계획을 세우세요. Oracle 튜닝 팩에 따라 라이센스가 부여된 Oracle SQL 튜닝 어드바이저는 자동 SQL 튜닝에 유용할 수 있습니다. 쿼리를 다시 작성하거나 복잡한 쿼리를 더 작은 청크로 나누어야 하는 경우도 있습니다.
-
읽기 전용 워크로드를 처리하기 위해 Oracle Active Data Guard와 같은 Amazon ElastiCache
및 Oracle RDS용 Amazon RDS 읽기 전용 복제본과 같은 캐싱 솔루션을 구현하는 것을 고려해 보십시오. -
개발자에게 쿼리 최적화 기술을 교육하고 프로덕션에 배포하기 전에 쿼리를 평가하는 표준 운영 절차를 구축하십시오.
-
데이터베이스 개체 수가 Exadata 온-프레미스 데이터베이스의 경우와 동일한지 확인하십시오. AWS 테이블, 인덱스, 프로시저, 트리거, 함수, 패키지, 제약 조건 및 기타 객체를 검하십시오.
-
가능하면 애플리케이션 수정을 고려하세요. (패키지된 ISV 애플리케이션처럼 애플리케이션을 수정할 수 없는 경우도 있습니다.) 불필요한 호출을 피하고 필요한 호출 빈도를 줄이십시오. SQL 문으로 검색되는 데이터 볼륨을 최소화하십시오. 커밋 빈도가 비즈니스 로직에 적합하지만 과도하지 않은지 확인하세요. 애플리케이션 수준 캐싱의 사용을 개선해 보세요.
-
데이터베이스는 사설 가상 사설 클라우드 (VPC) 에 있어야 합니다. AWS인바운드 및 아웃바운드 트래픽에 대한 네트워크 액세스를 최소 권한 모델로 제한하십시오. 보안 그룹 소스는 AWS 계정의 보안 그룹, 접두사 목록 또는 특정 IP 주소 집합 (x.x.x.x/32 형식 사용) 을 참조해야 합니다. 보안 그룹 소스는 CIDR을 사용해서는 안 되며 보안 그룹은 공용 인터넷 (0.0.0.0/0) 에서 액세스할 수 없어야 합니다.