Exadata에서 마이그레이션 도구로의 전환 도구 AWS - AWS 권장 가이드
AWS DMS 마이그레이션Oracle GoldenGate 마이그레이션오라클 데이터 펌프 마이그레이션오라클 RMAN 마이그레이션오라클 데이터 가드 마이그레이션

기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

Exadata에서 마이그레이션 도구로의 전환 도구 AWS

Exadata에는 15개 이상의 마이그레이션 접근 방식이 있습니다 AWS . 다음 표는 가장 일반적으로 사용되는 도구를 보여줍니다. 이 테이블에는 Oracle 일반 익스포트/임포트, Oracle SQL*Loader, Oracle SQL 개발자 데이터베이스 사본, Oracle SQL*Developer 익스포트/임포트 마법사, Oracle 전송 가능한 테이블스페이스, CTAS (테이블 생성) 를 사용하는 오라클 데이터베이스 링크, Oracle 외부 테이블 또는 ETL (추출, 변환 및 로드) 솔루션이 포함되지 않습니다.

마이그레이션 접근 방식

마이그레이션 전략 지원

물리적 또는 논리적

변경 데이터 캡처 (CDC) 지원

다음을 위한 네트워킹이 필요합니다. AWS

AWS DMS

모두

논리적

예

예

오라클 GoldenGate

모두

논리적

예

예

Oracle Data Pump

리호스팅, 리플랫폼

논리적

아니요

아니요

오라클 복구 관리자 (RMAN)

리호스팅

물리적

아니요

Amazon S3에 대한 오라클 보안 백업을 사용하는 RMAN DUPLICATE 경우

Oracle Data Guard

리호스팅

물리적

예

예

오라클 데이터 가드와 오라클 리커버리 매니저 (RMAN) 는 Exadata 데이터베이스를 Amazon EC2로 마이그레이션하기 위한 훌륭한 옵션입니다. 하지만 Oracle용 Amazon RDS는 이러한 도구 중 어느 것도 지원하지 않습니다.

논리적 대기 또는 물리적 대기 방법을 사용하여 Oracle Data Guard를 구현할 수 있습니다. 논리적 대기 데이터베이스는 대기 데이터베이스에 DML (데이터 조작 언어) 문을 적용하여 데이터를 동기화된 상태로 유지합니다. 논리적 대기 데이터베이스는 일반적으로 기본 데이터베이스에서 보고를 오프로드하는 데 사용됩니다. 이 섹션의 모든 Oracle Data Guard 참조는 물리적 대기에 직접 적용됩니다. 물리적 대기 데이터베이스는 블록 수준에서 기본 데이터베이스와 정확히 일치합니다.

AWS DMS 마이그레이션

AWS Database Migration Service (AWS DMS) 는 논리적 복제 솔루션입니다. 오라클 온프레미스 데이터베이스를 의 오라클 데이터베이스로 마이그레이션하는 것과 같은 동종 마이그레이션뿐만 아니라 오라클에서 Microsoft SQL Server로 AWS, 오라클에서 Amazon Aurora PostgreSQL과 호환되는 에디션으로 서로 다른 데이터베이스 플랫폼 간의 이기종 마이그레이션도 지원합니다. AWS DMS 광범위한 소스 및 대상을 지원합니다. 지원되는 AWS DMS 대상은 아마존 심플 스토리지 서비스 (아마존 S3), 아마존다이나모DB, 아마존 레드시프트, 아마존 키네시스 데이터 스트림, 아마존 DocumentDB, 레디스 등입니다.

Exadata 워크로드를 Oracle용 Amazon RDS 또는 Amazon EC2의 오라클 데이터베이스로 마이그레이션하는 데 사용할 AWS DMS 수 있습니다. AWS DMS Exadata의 초기 로드와 변경 데이터 캡처 (CDC) 업데이트를 처리합니다. Exadata는 마이그레이션 프로세스 중에도 완벽하게 작동합니다. CDC를 사용하면 대상 데이터베이스가 Exadata와 지속적으로 동기화되므로 편리한 시간에 애플리케이션 컷오버를 수행할 수 있습니다.

Oracle RMAN, Oracle Data Guard 및 Oracle Data Pump와 같은 기본 Oracle 도구는 보다 유연하며 데이터를 더 빠르게 로드할 수 있습니다. AWS DMS대규모 (다중 TIB) Exadata 데이터베이스를 마이그레이션하는 경우 초기 데이터 로드 대신 이러한 네이티브 Oracle 유틸리티를 선택하는 것이 좋습니다. AWS DMS

Oracle Data Pump는 테이블 간 및 분할 영역간 병렬화를 수행하여 다중, 병렬 또는 직접 경로 스트림으로 테이블을 로드 및 언로드할 수 있는 다중 작업자 프로세스를 지원합니다. 덤프 파일 읽기 및 쓰기를 포함하여 Data Pump의 모든 가져오기 및 내보내기 처리는 서버에서 처리되며 클라이언트는 관여하지 않습니다. 데이터 펌프 덤프 파일 저장소 형식은 직접 경로 API의 내부 스트림 형식입니다. 이 형식은 테이블스페이스 내의 Oracle Database 데이터 파일에 저장되는 형식과 매우 유사합니다. 따라서 Data Pump는 명령문 바인드 변수로의 클라이언트 측 변환을 수행할 필요가 없습니다. INSERT 또한 Data Pump는 기존 SQL보다 빠른 데이터 액세스 방법, 직접 경로 및 외부 테이블을 지원합니다. 직접 경로 API는 가장 빠른 단일 스트림 성능을 제공합니다. 외부 테이블 기능은 Oracle 데이터베이스의 병렬 쿼리 및 병렬 DML 기능을 효율적으로 사용합니다. Exadata에서 Amazon RDS for Oracle로 마이그레이션할 때 가동 중지 시간이 짧아야 하는 경우 일반적인 Exadata 마이그레이션 접근 방식은 초기 로드에 데이터 펌프를 사용한 다음 CDC용 Oracle을 AWS DMS 사용하는 것입니다. GoldenGate

Exadata를 소스로 사용할 때는 제한이 있습니다. AWS DMS이에 대한 자세한 내용은 AWS DMS 설명서를 참조하십시오. 또한 에는 소스 (Exadata 온프레미스) 및 대상 (Oracle 데이터베이스 AWS) 에 대한 AWS DMS네트워크 연결이 필요합니다.

를 초기 AWS DMS 로드에 사용하는 경우 다음 모범 사례를 고려하십시오.

  • 일반적으로 대규모 AWS DMS 복제 인스턴스를 선택하면 성능을 개선할 수 있습니다. 대형 테이블을 로드하는 데 시간이 더 오래 걸리며 이러한 테이블의 트랜잭션은 테이블이 로드될 때까지 캐시되어야 합니다. 테이블이 로드되면 이러한 캐시된 트랜잭션이 적용되고 더 이상 디스크에 보관되지 않습니다. 예를 들어 로드에 5시간이 걸리고 매시간 6GiB의 트랜잭션이 생성되는 경우 캐시된 트랜잭션에 30GiB의 디스크 공간을 할당해야 합니다. 초기 로드가 완료되면 CDC를 시작하기 전에 더 작은 인스턴스를 사용하도록 AWS DMS 복제 인스턴스를 수정할 수 있습니다.

  • 대규모 (멀티-TIB) Exadata 마이그레이션의 경우 Oracle 대신 AWS DMS 바이너리 리더를 사용하는 것이 좋습니다 LogMiner (기본값). 바이너리 리더는 여러 데이터베이스 쿼리를 요구하지 않고 로그를 직접 마이닝하기 때문에 I/O 또는 CPU에 영향을 줄 위험이 적습니다. 하지만 변경 내용이 많고 Oracle LogMiner ASM을 사용하는 경우에는 Oracle이 더 좋습니다. Binary Reader를 사용하여 리두 로그에 액세스하려면 소스 엔드포인트에 대해 다음과 같은 추가 연결 속성을 추가하십시오.

    useLogMinerReader=N;useBfile=Y

    전체 비교는 설명서의 CDC용 Oracle LogMiner 또는 AWS DMS 바이너리 리더 사용을 참조하십시오. AWS DMS

  • Amazon RDS for Oracle용 백업을 비활성화하거나 Amazon EC2에서 Oracle로 NOARCHIVELOG 마이그레이션하는 경우 보관 모드를 변경하십시오. CDC 단계 이전 또는 초기 데이터 로드 이후에 백업을 활성화하십시오.

  • 켜져 AWS있는 모든 대기 데이터베이스를 비활성화합니다. 여기에는 Oracle 다중 AZ용 Amazon RDS와 읽기 전용 복제본이 포함됩니다. Amazon EC2에서 오라클로 마이그레이션하는 경우 오라클 데이터 가드 또는 오라클 액티브 데이터 가드 스탠바이도 포함됩니다.

  • 대상 데이터베이스에 처음 로드하기 전에 기본 키 인덱스, 보조 인덱스, 참조 무결성 제약 조건 및 DML (데이터 조작 언어) 트리거를 삭제하십시오. CDC 단계를 시작하기 전에 이러한 개체를 활성화하십시오.

  • 대형 테이블의 경우 행 필터링, 키 또는 파티션 키를 사용하여 단일 테이블을 여러 AWS DMS 작업으로 나누는 것을 고려해 보세요. 예를 들어 데이터베이스의 기본 키 ID가 1~8,000,000인 경우 행 필터링을 사용하여 각 작업에 대해 백만 개의 레코드를 마이그레이션하여 8개의 작업을 생성하십시오. AWS DMS 날짜 열에도 이 기법을 사용할 수 있습니다.

  • AWS DMS 마이그레이션을 여러 AWS DMS 작업으로 나눕니다. 작업 내에서 트랜잭션 일관성이 유지되므로 별도의 작업에 있는 테이블이 공통 트랜잭션에 참여해서는 안 됩니다.

  • 기본적으로 한 번에 8개의 테이블을 AWS DMS 로드합니다. 성능 향상을 위해 대규모 복제 서버를 사용하는 경우 이 값을 늘릴 수 있습니다.

  • 기본적으로 트랜잭션 모드에서 변경을 AWS DMS 처리하므로 트랜잭션 무결성이 유지됩니다. 일괄 최적화된 적용 옵션으로 변경하면 성능이 향상될 수 있습니다. 초기 로드 중에는 이러한 제약을 끄고 CDC 프로세스에서는 다시 켜는 것이 좋습니다.

  • AWS DMS 복제 인스턴스와 Oracle 데이터베이스가 서로 다른 VPC (가상 사설 클라우드) 에 AWS 있는 경우 VPC 피어링을 사용하는 것이 좋습니다.

  • AWS DMS 마이그레이션 작업을 생성하거나 수정할 때 Amazon CloudWatch logs를 활성화하십시오. 이 파라미터는 작업을 생성할 때 작업 설정 섹션에서 사용할 수 있습니다. AWS DMS 이 매개 변수를 활성화하면 마이그레이션 프로세스 중에 작업 상태, 완료율, 경과 시간, 테이블 통계 등의 정보가 캡처됩니다. 자세한 내용은 CloudWatch AWS DMS 설명서에서 Amazon을 사용한 복제 작업 모니터링을 참조하십시오.

추가 모범 사례는 AWS DMS 설명서의 Oracle 데이터베이스를 원본으로 사용 AWS DMS 및 모범 사례를 참조하십시오 AWS Database Migration Service.

Oracle GoldenGate 마이그레이션

GoldenGate Oracle은 논리적 복제 솔루션입니다. 이 도구를 사용하여 한 데이터베이스에서 다른 데이터베이스로 데이터를 복제, 필터링 및 변환할 수 있습니다. 커밋된 트랜잭션을 여러 이기종 시스템으로 이동하고 Oracle 데이터베이스의 데이터를 다른 동종 데이터베이스 및 지원되는 이기종 데이터베이스로 복제할 수 있습니다. Oracle은 의 여러 가지 장점과 한계를 공유합니다. GoldenGate AWS DMS

두 도구 모두 논리적 복제 기능을 제공합니다. 그러나 AWS DMS Oracle은 설치 및 구성이 필요 없는 관리형 서비스이지만 Oracle은 설치하고 GoldenGate 구성해야 합니다. 온프레미스 또는 온프레미스에서 설정할 수 AWS있습니다. 고가용성 구성을 사용하여 Exadata에서 Exadata로 데이터를 마이그레이션하여 GoldenGate Oracle을 AWS설치할 수 있습니다. AWS Oracle을 온프레미스 Exadata 또는 Amazon EC2의 Oracle 데이터베이스 노드에 GoldenGate 직접 설치하지 마십시오. 데이터베이스 노드는 데이터베이스 워크로드 처리 전용으로 사용해야 합니다.

AWS DMS Oracle과 GoldenGate Oracle의 또 다른 주요 차이점은 요금입니다. AWS DMS 복제 인스턴스 사용 및 로그 스토리지에 대한 요금. 모든 데이터 AWS DMS 전송은 무료이며, 동일한 가용 영역에 있는 Amazon RDS와 Amazon EC2 인스턴스 간의 AWS DMS 데이터 전송도 무료입니다. Oracle은 원본 및 대상 데이터베이스의 모든 코어에 대해 Oracle GoldenGate 라이선스를 GoldenGate 요구합니다. GoldenGate 오라클을 사용하여 Exadata 워크로드를 Oracle용 Amazon RDS 또는 Amazon EC2의 Oracle로 마이그레이션하여 초기 로드와 Exadata에서 CDC를 수행할 수 있습니다. 이 프로세스를 통해 Exadata는 마이그레이션 프로세스 중에 완벽하게 운영될 수 있습니다.

Amazon EC2에서 대규모 (멀티-TIB) Exadata 데이터베이스를 Oracle로 마이그레이션하려면 다음과 같은 이유로 오라클 대신 Oracle RMAN, Oracle Data Guard 또는 Oracle Data Pump를 사용하는 것이 좋습니다. GoldenGate

  • 오라클에서는 Exadata와 GoldenGate Exadata 간의 네트워크 연결이 필요합니다. AWS

  • GoldenGate Oracle은 초기 데이터 로드 시 다른 Oracle 마이그레이션 도구만큼 성능이 떨어집니다. 예를 들어 대규모 Exadata 데이터베이스를 Amazon RDS for Oracle로 마이그레이션하려면 Oracle Data Pump를 대신 사용하는 것이 좋습니다. Oracle Data Pump가 Oracle보다 유연하고 데이터를 더 빠르게 로드할 수 있기 때문입니다. GoldenGate

Exadata에서 Amazon RDS로 마이그레이션할 때 가동 중지 시간이 짧아야 하는 경우 일반적인 마이그레이션 접근 방식은 초기 로드에는 Oracle Data Pump를 사용하고 Oracle이나 CDC에는 GoldenGate AWS DMS Oracle을 사용하는 것입니다. GoldenGate 오라클의 장점은 CDC뿐만 아니라 초기 로드도 처리할 수 있다는 것입니다. CDC를 사용하면 대상 데이터베이스가 Exadata와 지속적으로 동기화된 상태로 유지되므로 편리한 시간에 전환할 수 있습니다.

Exadata를 Oracle의 소스로 사용할 때는 제한이 있습니다. GoldenGate 이에 대한 자세한 내용은 GoldenGate 설명서의 지원 내용 이해를 참조하십시오.

초기 GoldenGate 로드에 Oracle을 사용하는 경우 다음 모범 사례를 고려하십시오.

  • 통합 캡처 모드에서 추출을 사용하여 LogMiner 서버와의 통합을 활용하십시오. 통합 캡처를 사용하면 클래식 모드의 추출보다 더 많은 데이터 유형을 원활하게 추출할 수 있습니다. 이러한 추가 데이터 유형에는 기본 압축, 온라인 트랜잭션 처리 (OLTP), Exadata 하이브리드 컬럼 압축 (HCC) 을 비롯한 압축된 데이터가 포함됩니다. Oracle ASM에 저장된 로그 파일을 읽기 위한 추출에는 추가 구성이 필요하지 않습니다.

  • 통합 복제를 사용하십시오. 이 옵션은 데이터베이스 적용 프로세스를 사용합니다. 참조 무결성을 유지하고 DDL 작업을 자동으로 적용합니다. 통합 Replicat은 또한 현재 워크로드 및 데이터베이스 성능에 따라 자동으로 증가 또는 감소하는 자동 병렬 처리 기능을 제공합니다.

  • Replicat BATCHSQL 파라미터 파일에서 설정합니다. 기본적으로 통합 복제본은 각 트랜잭션 내의 동일한 객체를 대상으로 동일한 유형의 DML 문을 재정렬하고 그룹화하려고 합니다. 배치를 사용하면 DML 문의 CPU 및 실행 시간을 줄일 수 있습니다.

  • end-to-end 복제 지연 보기를 제공하도록 GoldenGate 하트비트 테이블을 구성합니다. 이렇게 하면 GG_LAG 데이터베이스 보기를 통해 end-to-end 복제 지연 시간을 확인할 수 있습니다.

  • Oracle용 Amazon RDS 백업을 비활성화하거나 보관 모드를 Amazon EC2에서 NOARCHIVELOG Oracle을 사용하는 경우로 변경하십시오. CDC 단계 이전 또는 초기 데이터 로드 이후에 백업을 활성화하십시오.

  • AWS의 모든 대기 데이터베이스를 비활성화합니다. 여기에는 Oracle 다중 AZ용 Amazon RDS와 읽기 전용 복제본이 포함됩니다. Amazon EC2에서 오라클로 마이그레이션하는 경우 오라클 데이터 가드 또는 오라클 액티브 데이터 가드 스탠바이도 포함됩니다.

  • 대상 데이터베이스에 처음 로드하기 전에 기본 키 인덱스, 보조 인덱스, 참조 무결성 제약 조건 및 DML (데이터 조작 언어) 트리거를 삭제하십시오. CDC 단계를 시작하기 전에 이러한 개체를 활성화하십시오.

  • Oracle GoldenGate 복제 인스턴스와 Oracle 데이터베이스가 서로 다른 VPC (가상 사설 클라우드) 에 AWS 있는 경우 VPC 피어링을 사용하는 것이 좋습니다.

오라클 데이터 펌프 마이그레이션

Oracle Data Pump를 사용하여 한 Oracle 데이터베이스에서 다른 Oracle 데이터베이스로 데이터를 이동할 수 있습니다. Data Pump는 Oracle Database의 이전 릴리스 (버전 10.1까지) 를 지원하고 형식, 데이터베이스 아키텍처 및 버전이 다른 플랫폼을 지원하는 등 다양한 이점을 제공합니다. 전체 데이터베이스를 내보내거나 특정 스키마, 테이블스페이스 또는 테이블만 내보내도록 선택할 수 있습니다.

병렬성, 압축 및 암호화 수준을 제어하고 포함하거나 제외할 객체 및 객체 유형을 지정할 수 있습니다. 또한 데이터 펌프는 중간 저장소 없이 데이터베이스 링크를 사용하여 데이터를 전송할 수 있는 네트워크 모드를 지원합니다.

Data Pump API는 Oracle 데이터베이스 간에 데이터와 메타데이터를 빠르고 안정적으로 이동할 수 있는 방법을 제공합니다. 데이터 펌프 내보내기 및 데이터 펌프 가져오기 유틸리티는 데이터 펌프 API를 기반으로 합니다. 오라클용 Amazon RDS 인스턴스는 보안 셸 (SSH) 프로토콜을 통해 액세스할 수 없으므로 데이터 펌프를 사용하여 Exadata에서 Amazon RDS for Oracle로 마이그레이션하는 경우 데이터 펌프 API가 데이터를 가져올 수 있는 유일한 방법입니다. 데이터 펌프 명령줄 인터페이스 (CLI) 는 Amazon RDS for Oracle로 마이그레이션하기 위한 옵션이 아닙니다.

초기 로드에 Data Pump를 사용하는 경우 다음 모범 사례를 고려하십시오.

  • 데이터를 가져오려면 먼저 테이블 스페이스를 생성해야 합니다.

  • 존재하지 않는 사용자 계정으로 데이터를 가져오려면 사용자 계정을 만들고 필요한 권한과 역할을 부여하세요.

  • Amazon EC2에서 Oracle로 마이그레이션하는 경우, Oracle 백업용 Amazon RDS를 끄거나 보관 모드를 로 변경하십시오. NOARCHIVELOG CDC 단계를 시작하기 전 또는 초기 데이터 로드 후에 백업을 활성화하십시오.

  • 모든 대기 데이터베이스를 끕니다. AWS여기에는 Oracle 다중 AZ용 Amazon RDS와 읽기 전용 복제본이 포함됩니다. Amazon EC2에서 오라클로 마이그레이션하는 경우 오라클 데이터 가드 또는 오라클 액티브 데이터 가드 스탠바이도 포함됩니다.

  • 대상 데이터베이스에 처음 로드하기 전에 기본 키 인덱스, 보조 인덱스, 참조 무결성 제약 조건 및 DML 트리거를 삭제하십시오. CDC 단계를 시작하기 전에 이러한 개체를 활성화하십시오.

  • 특정 스키마와 객체를 가져오려면 스키마 또는 테이블 모드에서 가져오기를 수행하십시오.

  • 가져오는 스키마를 응용 프로그램에 필요한 스키마로 제한하십시오.

  • 압축 및 다중 스레드를 사용하여 데이터를 병렬로 로드 및 언로드합니다.

  • Amazon S3의 파일은 5TiB 이하여야 합니다. PARALLEL옵션을 사용하여 데이터 펌프 덤프 파일을 여러 개 생성하면 이러한 제한을 피할 수 있습니다.

  • 데이터 펌프를 내보낸 후 CDC를 수행하려는 경우 데이터 펌프와 함께 Oracle SCN (시스템 변경 번호) 을 사용하십시오.

  • Amazon RDS for Oracle에 데이터를 로드하려면 다음 작업을 수행하십시오.

    1. Amazon RDS가 S3 버킷에 액세스할 수 있도록 허용하는 AWS Identity and Access Management (IAM) 정책을 생성합니다.

    2. IAM 역할을 생성하고 정책을 연결합니다.

    3. IAM 역할을 오라클용 Amazon RDS 인스턴스와 연결합니다.

    4. Amazon S3 통합을 위한 오라클용 Amazon RDS 옵션 그룹을 구성하고 이를 오라클용 Amazon RDS 인스턴스에 추가합니다.

    자세한 내용은 Amazon RDS 설명서의 Amazon S3 통합을 참조하십시오.

오라클 RMAN 마이그레이션

오라클 복구 관리자 (RMAN) 는 오라클 데이터베이스를 백업하고 복구하기 위한 도구입니다. 또한 온프레미스 및 온프레미스와 클라우드 데이터베이스 간의 데이터베이스 마이그레이션을 용이하게 하는 데에도 사용됩니다.

Oracle RMAN은 물리적 마이그레이션 접근 방식을 제공합니다. 이러한 이유로 재호스팅 (Amazon EC2로의 마이그레이션) 은 지원하지만 Amazon RDS for Oracle에서 Oracle 데이터베이스를 리플랫폼하는 데에는 사용할 수 없습니다. 마이그레이션 다운타임 허용 한도는 Oracle RMAN 증분 백업을 백업하고 복원할 수 있을 만큼 커야 합니다.

Amazon S3로 마이그레이션

Exadata 데이터베이스를 Amazon S3에 백업하려면 다음 옵션을 사용할 수 있습니다.

  • Oracle 보안 백업 (OSB) 클라우드 모듈을 사용하여 Exadata 데이터베이스를 Amazon S3에 직접 백업할 수 있습니다.

  • Oracle RMAN 백업 세트를 Exadata RMAN 백업 위치에서 Amazon S3로 복사합니다.

  • Oracle ZFS 스토리지 어플라이언스를 사용하십시오. Oracle ZFS 스토리지 어플라이언스에 저장된 Oracle RMAN 백업 세트는 Oracle ZFS 스토리지 어플라이언스 S3 오브젝트 API 서비스를 사용하여 Amazon S3로 직접 전송할 수 있습니다.

  • Oracle RMAN 백업을 Exadata 스토리지 서버, 오라클 무손실 복구 어플라이언스 및 테이프 라이브러리에 직접 저장합니다. 그런 다음 이러한 스토리지 플랫폼 중 하나에 있는 RMAN 백업 세트를 Amazon S3로 전송할 수 있습니다.

Amazon EC2로 마이그레이션

또한 RMAN을 사용하여 백업 세트를 만들지 않고도 Amazon EC2의 Oracle 데이터베이스에 Exadata 데이터베이스를 직접 백업할 수 있습니다. 이렇게 하려면 Oracle RMAN DUPLICATE 명령을 사용하여 백업 및 복원을 수행하십시오. 그러나 대규모 (멀티-TIB) Exadata 마이그레이션에는 Oracle RMAN을 사용하지 DUPLICATE 않는 것이 좋습니다.

RMAN 설정은 일반적으로 백업 크기, Exadata CPU, 압축, 병렬 처리 또는 RMAN 채널 수와 같은 요소를 기반으로 구성됩니다. RMAN과 함께 오라클 서비스 버스 (OSB) 및 압축 (낮음, 중간, 높음) 을 사용하려면 오라클 고급 압축 옵션 (ACO) 라이선스가 필요합니다. 또한 OSB에는 OSB와 함께 사용하려는 RMAN 채널 수를 기반으로 하는 Oracle 라이센스가 필요합니다.

RMAN을 사용하여 Exadata를 Amazon EC2의 Oracle로 마이그레이션하려는 경우 다음 모범 사례를 고려하십시오.

참고

이 섹션에 제공된 명령은 Amazon EC2 기반 Oracle 인스턴스에서 실행해야 합니다.

  • Amazon EC2에서 다른 Oracle ASM 디스크 그룹 이름을 사용하려면 RMAN 복원 프로세스와 함께 set newname 명령을 실행하십시오.

    set newname for datafile 1 to '+<disk_group>'; set newname for datafile 2 to '+<disk_group>';

  • 온라인 리두 로그가 다른 위치에 있는 경우 리두 로그 파일의 이름을 변경하십시오. AWS

    alter database rename file '/<old_path>/redo01.log' to '+<disk_group>';
alter database rename file '/<old_path>/redo02.log' to '+<disk_group>';

  • 데이터베이스를 성공적으로 연 후: AWS

    • 다른 인스턴스의 리두 스레드에 대한 리두 로그 그룹을 제거합니다.

      alter database disable thread 2;
alter database drop logfile group 4;
alter database clear unarchived logfile group 4;

    • 다른 인스턴스의 실행 취소 테이블스페이스를 제거합니다.

      drop tablespace UNDOTBS2 including contents and datafiles;

    • 테이블스페이스가 하나만 존재하는지 확인하십시오. TEMP 불필요한 TEMP 테이블스페이스를 제거하고 기존 TEMP 테이블스페이스가 예상 데이터베이스 워크로드를 처리할 수 있을 만큼 충분히 큰지 확인합니다.

HCC 고려 사항

Exadata에서 하이브리드 컬럼 압축 (HCC) 을 사용하는 경우 HCC가 있는 모든 테이블을 Oracle ACO로 변환하거나 비활성화해야 합니다. AWS그렇지 않으면 Amazon EC2에서 Oracle 데이터베이스에 액세스할 때 SQL 문이 실패합니다. Oracle ACO에는 오라클 라이선스가 필요합니다.

일반적으로 사용자는 온프레미스 Exadata 프로덕션 데이터베이스에서 HCC를 제거할 수 없습니다. 데이터베이스를 로 마이그레이션할 때 HCC를 제거할 수 있습니다. AWS데이터베이스를 마이그레이션한 후 테이블 또는 파티션에서 HCC가 활성화되었는지 확인하려면 다음 SQL 문을 실행하십시오. AWS

select TABLE_NAME, COMPRESSION, COMPRESS_FOR
from DBA_TABLES
where OWNER like 'SCHEMA_NAME';

select TABLE_NAME, PARTITION_NAME, COMPRESSION, COMPRESS_FOR
from DBA_TAB_PARTITIONS
where TABLE_OWNER = 'SCHEMA_NAME';

compression열 값이 로 ENABLED 설정되고 compress_for 열에 다음 값 중 하나가 있는 경우 HCC가 활성화됩니다.

  • QUERY LOW

  • QUERY HIGH

  • ARCHIVE LOW

  • ARCHIVE HIGH

  • QUERY LOW ROW LEVEL LOCKING

  • QUERY HIGH ROW LEVEL LOCKING

  • ARCHIVE LOW ROW LEVEL LOCKING

  • ARCHIVE HIGH ROW LEVEL LOCKING

  • NO ROW LEVEL LOCKING

테이블 또는 파티션에서 HCC를 끄려면 다음 SQL 문을 실행합니다.

alter table table_name nocompress;
alter table table_name modify partition partition_name nocompress;

Oracle ACO를 AWS활성화하려면 오라클 설명서의 지침을 따르십시오.

오라클 데이터 가드 마이그레이션

Oracle Data Guard를 사용하면 고가용성 및 재해 복구를 위해 하나 이상의 대기 데이터베이스를 생성하고 관리할 수 있습니다. Data Guard는 대기 데이터베이스를 기본 (일반적으로 프로덕션) 데이터베이스의 복사본으로 유지 관리합니다. 프로덕션 데이터베이스에 계획된 또는 예상치 못한 가용성 문제가 발생하는 경우 Data Guard는 역할을 전환하여 가동 중지 시간을 최소화하고 애플리케이션 연속성을 보장할 수 있습니다.

논리적 대기 방식과 물리적 대기 방법을 모두 사용하여 Data Guard를 구현할 수 있습니다. 이 가이드에서는 기본 데이터베이스와 정확히 일치하는 물리적 대기 데이터베이스를 사용하고 있다고 가정합니다.

Data Guard는 물리적 예비 데이터베이스를 생성하기 위해 Amazon EC2의 Exadata에서 Oracle 데이터베이스로의 마이그레이션을 지원합니다. Oracle 데이터 펌프 또는 GoldenGate Oracle과 AWS DMS같은 논리적인 마이그레이션 접근 방식이 필요한 Amazon RDS for Oracle로 마이그레이션하는 데는 사용할 수 없습니다.

Data Guard는 Oracle과 같은 CDC 메커니즘에 비해 전체 Exadata 데이터베이스를 마이그레이션하는 더 간단하고 빠른 접근 방식입니다. AWS DMS GoldenGate 일반적으로 다운타임 요구 사항이 최소인 경우 (예: 전환할 시간만 있는 경우) 에 이 방법을 사용하는 것이 좋습니다.

동기 또는 비동기 전송으로 Data Guard를 구성할 수 있습니다. 일반적으로 Oracle 고객은 왕복 네트워크 지연 시간이 5ms 미만일 때 동기 전송을 통해 더 큰 성공을 거둘 수 있습니다. 비동기 전송의 경우 오라클은 30ms 미만의 왕복 네트워크 지연 시간을 권장합니다.

일반적으로 프로덕션 Exadata 온프레미스 데이터베이스에는 Data Guard 스탠바이가 이미 존재합니다. Amazon EC2의 Oracle은 일반적으로 프로덕션 Exadata 온프레미스 데이터베이스를 위한 추가 대기 데이터베이스 역할을 합니다. Oracle RMAN을 사용하여 데이터 가드 대기 데이터베이스를 생성하는 것이 좋습니다. AWS

Data Guard 성능에 영향을 미치는 변수는 많습니다. Data Guard 복제가 워크로드에 미치는 영향에 대해 결론을 내리기 전에 테스트를 수행하는 것이 좋습니다.

사용되는 메커니즘이 다르기 때문에 Data Guard 복제의 경우 지연 시간 (핑 모니터를 통해 측정) 은 중요하지 않습니다. Oracle oratcptest 유틸리티는 네트워크 리소스를 평가하는 데 도움이 됩니다. 내 오라클 지원 (MOS) 노트 2064368.1 (오라클 계정 필요) 에서 oratcptest를 JAR 형식으로 다운로드할 수 있습니다. MOS 노트에는 이 유틸리티에 대한 자세한 내용도 나와 있습니다.