RDS Custom for Oracle 지원 종료

1. EC2 인스턴스 시작 및 구성

   다음 사항을 고려하여 EC2 인스턴스를 시작하세요.

   • 인스턴스 유형: 워크로드의 리소스 요구 사항을 충족하는 EC2 인스턴스 유형을 선택합니다. RDS Custom 인스턴스와 동일한 인스턴스 클래스를 사용하는 것이 좋습니다. 메모리, CPU 및 네트워크 대역폭 요구 사항을 고려합니다.

   • 운영 체제: Oracle Linux 또는 Red Hat Enterprise Linux(RDS Custom OS 버전과 일치하거나 호환)

   • Oracle 소프트웨어: Oracle Database 소프트웨어(주요 버전, 마이너 버전, 릴리스 업데이트, 이상적으로는 RDS Custom과 동일한 일회성 패치)를 설치합니다. Oracle 소프트웨어가 /u01/app/oracle/ 또는 원하는 위치에 설치되어 있는지 확인합니다.

   • 스토리지: 워크로드 요구 사항에 맞게 적절한 크기와 IOPS로 Amazon EBS 볼륨을 구성합니다. 비용 효율적인 성능을 위해 gp3 볼륨을 사용하거나 고성능 워크로드를 위해 io2 Block Express를 사용하는 것이 좋습니다.

2. 스토리지 아키텍처 구성

   1. 파일 시스템 스토리지(대부분의 시나리오에서 권장됨)

      • Oracle 데이터 파일에 표준 파일 시스템 디렉터리 사용

      • 관리가 더 간단하고 대부분의 워크로드에 적합

      • 이 지침에서는 파일 시스템 스토리지 예제를 사용합니다.

   2. Oracle Automatic Storage Management(ASM)

      • 워크로드에 ASM이 필요한 경우 EC2 인스턴스에 독립 실행형 ASM을 설치하고 구성합니다.

      • ASM 디스크 그룹(예: +DATA, +FRA)을 사용하도록 init 파일의 모든 경로 파라미터를 적절히 조정합니다.

      • 마이그레이션 프로세스는 경로 조정과 함께 ASM과 유사합니다.

3. 파일 전송 메커니즘 설정

   RDS Custom 인스턴스와 EC2 인스턴스 간에 파일을 전송하는 메커니즘을 생성합니다. 여러 가지 옵션이 있습니다.

   1. 옵션 A: Amazon S3(대부분의 시나리오에서 권장됨)

      • Amazon S3 버킷을 만들거나 기존 버킷 사용

      • 두 인스턴스 모두에 AWS CLI 설치 및 구성

      • 지침은 AWS CLI 시작하기를 참고하세요.

   2. 옵션 B: 직접 SCP/SFTP

      • 인스턴스 간에 SSH 포트가 열려 있는 경우 파일을 직접 전송할 수 있습니다.

      • 파라미터 파일 및 암호 파일과 같은 작은 파일에 적합

   3. 옵션 C: Amazon EFS

      • 두 인스턴스에 Amazon EFS가 이미 탑재되어 있는 경우 공유 파일 시스템으로 사용할 수 있습니다.

      • 기존 EFS 인프라가 있는 환경에 적합

      이 지침에서는 Amazon S3를 예제로 사용하지만 선택한 메서드에 맞게 명령을 조정할 수 있습니다.

4. 네트워크 연결 구성

   RDS Custom 인스턴스와 EC2 인스턴스 간의 네트워크 연결을 확인합니다.

   • 동일한 VPC: 보안 그룹은 Oracle 리스너 포트(기본값 1521 또는 사용자 지정 포트)에서 양방향 트래픽을 허용해야 합니다.

   • 다른 VPC(동일 계정): VPC 피어링 설정 및 라우팅 테이블 및 보안 그룹 구성

   • 다른 계정: 계정 간에 VPC 피어링을 설정하거나 AWS Transit Gateway 사용

   • 연결 확인: ping 및 telnet을 사용하여 데이터베이스 포트에서 연결 테스트

5. EC2에서 디렉터리 구조 생성

   디렉터리 구조는 데이터베이스 아키텍처에 따라 달라집니다.

   예비 CDB의 경우:

   # Non-CDB directories
   mkdir -p /u01/app/oracle/oradata/ORCL/controlfile/
   mkdir -p /u01/app/oracle/oradata/ORCL/datafile
   mkdir -p /u01/app/oracle/oradata/ORCL/onlinelog
   mkdir -p /u01/app/oracle/oradata/ORCL/arch
   mkdir -p /u01/app/oracle/admin/ORCL/adump
   mkdir -p /u01/app/oracle/backup
   # Set ownership
   chown -R oracle:oinstall /u01/app/oracle/oradata/ORCL
   chown -R oracle:oinstall /u01/app/oracle/admin/ORCL
   chown -R oracle:oinstall /u01/app/oracle/backup

   예멀티테넌트(PDB가 있는 CDB)의 경우

   # CDB directories
   mkdir -p /u01/app/oracle/oradata/ORCL/controlfile/
   mkdir -p /u01/app/oracle/oradata/ORCL/cdb/datafile
   mkdir -p /u01/app/oracle/oradata/ORCL/pdbseed/datafile
   mkdir -p /u01/app/oracle/oradata/ORCL/onlinelog
   mkdir -p /u01/app/oracle/oradata/ORCL/arch
   mkdir -p /u01/app/oracle/admin/ORCL/adump
   mkdir -p /u01/app/oracle/backup
   # PDB directories (RDS Custom uses OMF with GUID-based paths)
   # Create a generic pdb directory - migration will create subdirectories as needed
   mkdir -p /u01/app/oracle/oradata/ORCL/pdb/datafile
   # Set ownership
   chown -R oracle:oinstall /u01/app/oracle/oradata/ORCL
   chown -R oracle:oinstall /u01/app/oracle/admin/ORCL
   chown -R oracle:oinstall /u01/app/oracle/backup

   참고

   RDS Custom for Oracle은 GUID 기반 하위 디렉터리(예: /rdsdbdata/db/pdb/RDSCDB_A/{GUID}/datafile/)가 있는 PDB 데이터 파일에 Oracle Managed Files(OMF)를 사용합니다. 마이그레이션 프로세스는 대상에 필요한 하위 디렉터리 구조를 자동으로 생성합니다. 상위 디렉터리만 생성하면 됩니다.

   스토리지 전략: /u01/app/oracle/backup에 별도의 EBS 볼륨을 사용하여 마이그레이션이 완료된 후 쉽게 분리하고 제거하여 스토리지 비용을 절감하는 것이 좋습니다.

6. 소스 데이터베이스 구성 확인

1. RDS Custom 데이터베이스 호스트에 rdsdb 사용자로 로그인하고 환경을 설정합니다.

   예

   # For non-CDB
   export ORACLE_HOME=/rdsdbbin/oracle.19.custom.r1.EE.1
   export ORACLE_SID=ORCL
   export PATH=$ORACLE_HOME/bin:$PATH
   
   # For multitenant CDB
   export ORACLE_HOME=/rdsdbbin/oracle.19.custom.r1.EE-CDB.1
   export ORACLE_SID=RDSCDB
   export PATH=$ORACLE_HOME/bin:$PATH

2. 데이터베이스에 연결하고 아키텍처를 확인합니다.

   예

   sqlplus / as sysdba
   SQL> SELECT name, cdb, open_mode, log_mode FROM v$database;

   예비CDB의 경우 예상 출력

   NAME CDB OPEN_MODE                 LOG_MODE
   --------- --- -------------------- ------------
   ORCL NO  READ  WRITE               ARCHIVELOG

   예멀티테넌트(CDB)의 경우 예상 출력:

   NAME    CDB  OPEN_MODE             LOG_MODE
   --------- --- -------------------- ------------
   RDSCDB    YES READ WRITE           ARCHIVELOG

3. 멀티테넌트 CDB가 있는 경우 모든 PDB 및 해당 상태:

   예

   SQL> SELECT con_id, name, open_mode, restricted FROM v$pdbs;

   예상 출력(ORCLDB라는 PDB가 1개인 예):

   예

   CON_ID     NAME                           OPEN_MODE  RES
   ---------- ------------------------------ ---------- ---
   2          PDB$SEED                       READ ONLY  NO
   3          ORCLDB                         READ WRITE NO

4. 총 데이터베이스 크기 확인:

   예비 CDB의 경우:

   SQL> SELECT SUM(bytes)/1024/1024/1024 AS total_size_gb FROM dba_data_files;

   예멀티테넌트의 경우:

   -- Total CDB size (all containers)
   SQL> SELECT SUM(bytes)/1024/1024/1024 AS total_size_gb FROM cdb_data_files;
   -- Size per PDB
   SQL> SELECT p.name AS pdb_name,
         ROUND(SUM(d.bytes)/1024/1024/1024, 2) AS size_gb
   FROM v$pdbs p
   JOIN cdb_data_files d ON p.con_id = d.con_id
   GROUP BY p.name, p.con_id
   ORDER BY p.con_id;

일반적인 타임라인

1. 복제 단계(소스는 온라인 상태로 유지): 데이터베이스 크기에 따라 30분~몇 시간

2. 검증 단계(소스는 온라인 상태로 유지): 필요에 따라 몇 시간에서 며칠까지

3. 컷오버 단계(짧은 가동 중지 시간): 애플리케이션을 EC2로 리디렉션하는 데 몇 분

RDS Custom DB 인스턴스(소스) 단계:

1. Amazon RDS Custom 자동화 일시 중지

2. 데이터베이스 아키텍처 확인(비 CDB 또는 PDB가 있는 CDB)

3. 소스 데이터베이스에서 암호 파일 및 파라미터 파일 생성

4. 암호 파일과 파라미터 파일을 대상 EC2 인스턴스에 복사합니다.

5. 소스 데이터베이스가 아카이브 로그 모드에서 실행 중인지 확인

6. RDS Custom DB 서버에서 tnsnames.ora 구성

EC2 DB 인스턴스(대상) 단계:

1. EC2용 파라미터 파일 편집(아키텍처별)

2. EC2에서 tnsnames.ora 구성

3. EC2 인스턴스에 대한 환경 구성

4. EC2에서 Oracle Listener 구성

5. NOMOUNT 상태에서 EC2에서 데이터베이스 시작

RMAN 복제 단계:

1. RMAN 활성 중복 수행

2. 데이터베이스(및 멀티테넌트용 PDB) 열기

3. PDB 자동 열기 구성(멀티테넌트만 해당)

4. RDS Custom 특정 사용자 및 객체 제거

5. SPFILE 생성 및 자동 시작 구성

6. 소스에서 Amazon RDS Custom 자동화 재개(활성 상태로 유지되는 경우)

1. 데이터베이스 이름 업데이트: 멀티테넌트의 경우 RDSCDB의 모든 발생을 ORCL로 변경합니다.

2. RDS Custom 경로를 EC2 경로로 변환: /rdsdbdata/를 /u01/app/oracle/로 바꾸기

3. RDS Custom 관련 파라미터 제거

   • dg_broker_config_file1 및 dg_broker_config_file2(있는 경우 - 복제본이 있음을 나타냄)

   • standby_file_management(있는 경우)

   • spfile(나중에 새 SPFILE 생성)

   • 대기 대상을 가리키는 모든 log_archive_dest 파라미터(로컬 아카이브에만 log_archive_dest_1 유지)

4. 파일 이름 변환 파라미터 추가(아래 참조)

5. EC2 인스턴스 크기에 따라 메모리 파라미터 조정(선택 사항이지만 권장됨)

RMAN 활성 복제 프로세스에는 여러 단계가 포함됩니다.

1. 소스 및 대상 데이터베이스에 연결

2. 대상의 메모리에서 SPFILE 생성

3. 제어 파일을 대상으로 복원

4. 대상 데이터베이스 탑재

5. 네트워크를 통해 소스에서 대상으로 모든 데이터 파일 복사(소스는 온라인 상태로 유지)

6. 대상 데이터베이스 복구

7. RESETLOGS를 사용하여 대상 데이터베이스 열기

1. RMAN 출력 모니터링:

   RMAN 세션에는 다음을 포함한 세부 진행 상황 정보가 표시됩니다.

   • 채널 할당

   • Datafile 복사 진행 상황

   • 예상 완료 시간

   • 처리된 바이트

   channel ORA_AUX_DISK_1: starting datafile copy
   input datafile file number=00001 name=/rdsdbdata/db/ORCL_A/datafile/system01.dbf
   output file name=/u01/app/oracle/oradata/ORCL/datafile/system01.dbf tag=TAG20260303T120000
   channel ORA_AUX_DISK_1: datafile copy complete, elapsed time: 00:05:23
   channel ORA_AUX_DISK_1: starting datafile copy
   input datafile file number=00003 name=/rdsdbdata/db/ORCL_A/datafile/sysaux01.dbf
   output file name=/u01/app/oracle/oradata/ORCL/datafile/sysaux01.dbf tag=TAG20260303T120000

   예출력 예시:

   channel ORA_AUX_DISK_1: starting datafile copy
   input datafile file number=00001 name=/rdsdbdata/db/ORCL_A/datafile/system01.dbf
   output file name=/u01/app/oracle/oradata/ORCL/datafile/system01.dbf tag=TAG20260303T120000
   channel ORA_AUX_DISK_1: datafile copy complete, elapsed time: 00:05:23
   channel ORA_AUX_DISK_1: starting datafile copy
   input datafile file number=00003 name=/rdsdbdata/db/ORCL_A/datafile/sysaux01.dbf
   output file name=/u01/app/oracle/oradata/ORCL/datafile/sysaux01.dbf tag=TAG20260303T120000

2. 장기 실행 작업 모니터링:

   예대상 EC2 인스턴스의 별도 SQL*Plus 세션에서:

   SQL> SELECT sid, serial#, opname, sofar, totalwork,
          ROUND(sofar/totalwork*100,2) pct_complete,
          time_remaining, elapsed_seconds
   FROM v$session_longops
   WHERE totalwork > 0 AND sofar <> totalwork
   ORDER BY start_time;

   이 쿼리는 다음을 보여줍니다.

   • opname: 작업 이름(예: ‘RMAN: 전체 데이터 파일 복원’)

   • sofar: 지금까지 처리된 블록

   • totalwork: 처리할 총 블록 수

   • pct_complete: 완료율

   • time_remaining: 남은 예상 초

   • elapsed_seconds: 지금까지 경과된 시간

3. RMAN 채널 모니터링:

   예

   SQL> SELECT sid, serial#, context, sofar, totalwork,
          ROUND(sofar/totalwork*100,2) pct_complete
          FROM v$session_longops
   WHERE opname LIKE 'RMAN%'
          AND totalwork > 0
          AND sofar <> totalwork;

4. 알림 로그 확인:

   예대상 EC2 인스턴스에서 오류 또는 경고가 있는지 알림 로그를 모니터링합니다.

   tail -f $ORACLE_BASE/diag/rdbms/orcl/ORCL/trace/alert_ORCL.log

   RMAN 복제 중 일반적인 문제:

   • 네트워크 제한 시간

     RMAN-03009: failure of duplicate command on ORA_AUX_DISK_1 channel
     ORA-03135: connection lost contact

     해결 방법: 두 인스턴스 모두에서 sqlnet.ora의 네트워크 제한 시간 값을 늘립니다.

     SQLNET.RECV_TIMEOUT=600
     SQLNET.SEND_TIMEOUT=600

   • 대상에 공간 부족

     RMAN-03009: failure of duplicate command
     ORA-19504: failed to create file "/u01/app/oracle/oradata/ORCL/datafile/users01.dbf"
     ORA-27040: file create error, unable to create file
     Linux-x86_64 Error: 28: No space left on device

     솔루션: 사용 가능한 공간을 확인하고 EBS 볼륨 용량을 더 추가합니다.

     df -h /u01/app/oracle/oradata

   • 파라미터 파일 오류

     RMAN-05021: this configuration cannot be used
     RMAN-06004: ORACLE error from auxiliary database: ORA-01261: Parameter db_create_file_dest destination string cannot be translated

     해결 방법: 파라미터 파일의 모든 디렉터리가 존재하고 적절한 권한이 있는지 확인합니다.

   • 암호 파일 불일치

     RMAN-00571: ===========================================================
     RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
     RMAN-00571: ===========================================================
     RMAN-03002: failure of duplicate command at 03/03/2026 12:00:00
     RMAN-06136: ORACLE error from auxiliary database: ORA-01017: invalid username/password; logon denied

     해결 방법: 대상의 암호 파일이 소스와 일치하고 올바른 이름(orapwORCL)이 있는지 확인합니다.

RDS Custom DB 인스턴스(기본) 단계:

1. Amazon RDS Custom 자동화 일시 중지

2. 데이터베이스 아키텍처 확인(비 CDB 또는 PDB가 있는 CDB)

3. 기본 데이터베이스가 아카이브 로그 모드에서 실행 중이고 FORCE_LOGGING이 활성화되어 있는지 확인합니다.

4. 암호 파일 만들기

5. 기본 데이터베이스의 RMAN 온라인 백업 수행(또는 활성 중복 사용)

6. 소스 데이터베이스에서 파라미터 파일 생성

7. 백업 세트, 파라미터 파일 및 암호 파일을 대상 EC2 인스턴스에 복사합니다.

EC2 DB 인스턴스(대기) 단계:

1. 소스에서 EC2 인스턴스로 모든 파일 복사

2. EC2 인스턴스에 암호 파일 복사

3. EC2용 파라미터 파일 편집(아키텍처별)

4. 파라미터 파일에서 서버 파라미터 파일 생성

5. 대기 제어 파일 및 데이터베이스 복원

데이터 보호 구성 단계:

1. 두 인스턴스 모두에서 Oracle 리스너 구성

2. 두 인스턴스 모두에서 tnsnames.ora 구성

3. 두 인스턴스 모두에서 Oracle Data Guard 브로커 시작(선택 사항이지만 권장됨)

4. Oracle Data Guard 구성 활성화

5. EC2 대기 인스턴스에서 fal_server 및 fal_client 구성

6. 두 인스턴스 모두에서 대기 재실행 로그 파일 구성

7. 대기 인스턴스 복구

8. 수동 전환 실시

9. 데이터베이스(및 멀티테넌트용 PDB) 열기

10. PDB 자동 열기 구성(멀티테넌트만 해당)

11. RDS Custom 특정 사용자 및 객체 제거

12. SPFILE 생성 및 자동 시작 구성

1. 데이터베이스 이름 업데이트: 멀티테넌트의 경우 RDSCDB의 모든 발생을 ORCL로 변경합니다.

2. db_unique_name: ORCL_A(또는 RDSCDB_A)에서 ORCL_B로

3. RDS Custom 경로를 EC2 경로로 변환: /u01/app/oracle/을 /rdsdbdata/로 바꾸기

4. RDS Custom 관련 파라미터 제거

   • dg_broker_config_file1 및 dg_broker_config_file2(있는 경우)

   • standby_file_management(있는 경우)

   • spfile(나중에 새 SPFILE 생성)

   • 대기 대상을 가리키는 모든 log_archive_dest 파라미터

5. EC2 인스턴스 크기에 따라 메모리 파라미터 조정(선택 사항이지만 권장됨)

1. Data Guard 통계 모니터링:

   -- Comprehensive Data Guard statistics
   SQL> SELECT name, value, unit, time_computed, datum_time
   FROM v$dataguard_stats
   ORDER BY name;

   모니터링할 주요 지표:

   • 전송 지연: 기본에서 다시 실행이 생성된 시점과 대기 상태에서 수신된 시점 간의 시간 차이

   • 지연 적용: 다시 실행이 생성되고 대기 상태에서 적용된 시점 간의 시간 차이

   • 적용 속도: 다시 실행이 적용되는 속도(MB/초)

   • 다시 실행 수신됨: 대기에서 수신한 총 다시 실행 수

   • 다시 실행 적용됨: 대기에 의해 적용된 총 다시 실행

2. 아카이브 로그 전송 모니터링:

   기본(RDS Custom)에서:

   -- Check archive log generation rate
   SQL> SELECT TO_CHAR(first_time, 'YYYY-MM-DD HH24') AS hour,
          COUNT(*) AS log_count,
          ROUND(SUM(blocks * block_size)/1024/1024/1024, 2) AS size_gb
   FROM v$archived_log
   WHERE first_time > SYSDATE - 1
   GROUP BY TO_CHAR(first_time, 'YYYY-MM-DD HH24')
   ORDER BY hour;
   
   -- Check archive log destination status
   SQL> SELECT dest_id, status, error, destination
   FROM v$archive_dest
   WHERE status != 'INACTIVE';

   대기(EC2)에서:

   -- Check archive log apply status
   SQL> SELECT sequence#, first_time, next_time, applied
   FROM v$archived_log
   WHERE applied = 'NO'
   ORDER BY sequence#;
   
   -- Check archive log gap
   SQL> SELECT thread#, low_sequence#, high_sequence#
   FROM v$archive_gap;

3. 관리형 복구 프로세스 모니터링:

   -- Check if managed recovery is running
   SQL> SELECT process, status, thread#, sequence#, block#, blocks
   FROM v$managed_standby
   WHERE process LIKE 'MRP%' OR process LIKE 'RFS%';
   
   -- Check recovery progress
   SQL> SELECT process, status, sequence#,
          TO_CHAR(timestamp, 'YYYY-MM-DD HH24:MI:SS') AS timestamp
   FROM v$managed_standby
   ORDER BY process;

4. 멀티테넌트에 대한 다시 실행 적용률 모니터링:

   멀티테넌트 데이터베이스의 경우 PDB당 적용률을 모니터링합니다.

   -- Check redo apply rate per container
   SQL> SELECT con_id, name,
          ROUND(SUM(value)/1024/1024, 2) AS redo_applied_mb
   FROM v$con_sysstat cs, v$containers c
   WHERE cs.con_id = c.con_id
     AND cs.name = 'redo size'
   GROUP BY con_id, name
   ORDER BY con_id;

5. 대기 재실행 로그 모니터링:

   -- Check standby redo log status
   SQL> SELECT group#, thread#, sequence#, bytes/1024/1024 AS size_mb, status
   FROM v$standby_log
   ORDER BY group#;
   
   -- Check if standby redo logs are being used
   SQL> SELECT group#, thread#, sequence#, status, archived
   FROM v$standby_log
   WHERE status = 'ACTIVE';

6. 동기화 완료 추정:

   적용률을 기준으로 남은 시간을 계산합니다.

   -- Calculate estimated time to catch up
   SQL> SELECT
          ROUND((SELECT value FROM v$dataguard_stats WHERE name = 'apply lag')/60, 2) AS lag_minutes,
          ROUND((SELECT value FROM v$dataguard_stats WHERE name = 'apply rate')/1024, 2) AS apply_rate_mbps,
          ROUND(
            (SELECT value FROM v$dataguard_stats WHERE name = 'apply lag') /
            NULLIF((SELECT value FROM v$dataguard_stats WHERE name = 'apply rate'), 0) / 60,
            2
          ) AS estimated_catchup_minutes
   FROM dual;

1. 시간대 버전을 확인합니다.

   SELECT * FROM v$timezone_file;
   SELECT PROPERTY_NAME, PROPERTY_VALUE
   FROM database_properties
   WHERE PROPERTY_NAME LIKE '%DST%';

2. 해결 방법으로 $ORACLE_HOME에서 사용할 수 있는 것과 일치하도록 시간대 파일 환경 변수를 설정합니다.

   ls $ORACLE_HOME/oracore/zoneinfo/timezlrg_*.dat
   export ORA_TZFILE=$ORACLE_HOME/oracore/zoneinfo/timezone_40.dat

   설치에서 사용할 수 있는 버전과 일치하도록 번호를 조정합니다.

3. 드롭을 다시 시도합니다.

   sqlplus / as sysdba
   SQL> DROP USER RDSADMIN CASCADE;

1. 소스와 대상 모두에서 정확한 RU 버전을 확인합니다.

   -- On both source and target
   SQL> SELECT * FROM v$version;
   
   SQL> SELECT patch_id, patch_uid, version, action, status, description
   FROM dba_registry_sqlpatch
   ORDER BY action_time DESC;

2. $ORACLE_HOME 패치 수준을 확인합니다.

   # On both instances
   $ORACLE_HOME/OPatch/opatch lsinventory

3. 버전이 일치하지 않는 경우 필요에 따라 패치를 적용하거나 롤백하여 마이그레이션하기 전에 정렬합니다.

4. 일치하지 않는 RU를 진행해야 하는 경우 마이그레이션 후 datapatch를 실행합니다.

   cd $ORACLE_HOME/OPatch
   ./datapatch -verbose

5. 잘못된 객체가 있는지 확인하고 다시 컴파일합니다.

   SQL> @?/rdbms/admin/utlrp.sql
   
   SQL> SELECT owner, object_type, COUNT(*)
   FROM dba_objects
   WHERE status = 'INVALID'
   GROUP BY owner, object_type;

1. 보안 그룹이 포트를 양방향으로 허용하는지 확인

2. EC2에서 iptable을 확인합니다.

   sudo iptables -L INPUT -n -v

3. 필요한 경우 규칙을 추가합니다.

   # Insert rule before the REJECT rule (typically position 5)
   sudo iptables -I INPUT 5 -p tcp --dport 1521 -j ACCEPT
   
   # For enhanced security, allow only from specific source IPs
   sudo iptables -I INPUT 5 -p tcp -s <RDS_Custom_IP> --dport 1521 -j ACCEPT
   
   # Save rules permanently
   sudo service iptables save

4. 연결 테스트:

   telnet <EC2_instance_IP> 1521
   tnsping DB_SOURCE
   tnsping DB_TARGET

1. 누락된 데이터 파일을 확인합니다.

   SQL> SELECT name, status FROM v$datafile WHERE status != 'ONLINE';

2. 파일이 잘못된 디렉터리에 배치된 경우 제어 파일에서 파일 이름을 바꿉니다.

   SQL> ALTER DATABASE RENAME FILE '/wrong/path/datafile.dbf' TO '/correct/path/datafile.dbf';

3. 이를 방지하려면 파라미터 파일을 구성하기 전에 항상 SELECT con_id, name FROM v$datafile ORDER BY con_id;를 사용하여 소스 데이터 파일 경로를 확인합니다.

1. 강제 서비스 등록:

   SQL> ALTER SYSTEM REGISTER;

2. 서비스가 여전히 표시되지 않으면 local_listener 파라미터를 확인합니다.

   SQL> SHOW PARAMETER local_listener;

   올바른 리스너 주소를 가리키는지 확인합니다. 필요한 경우 업데이트합니다.

   SQL> ALTER SYSTEM SET local_listener='(ADDRESS=(PROTOCOL=TCP)(HOST=<EC2_instance_IP>)(PORT=1521))';
   SQL> ALTER SYSTEM REGISTER;

3. 다음을 사용하여 확인합니다.

   lsnrctl services

1. 대기 모드가 마운트 모드인지 확인합니다.

   SQL> SELECT status FROM v$instance;

2. 대기 상태에서 fal_server 및 fal_client가 올바르게 설정되었는지 확인합니다.

   SQL> SHOW PARAMETER fal_server
   SQL> SHOW PARAMETER fal_client

3. 네트워크 연결 확인:

   tnsping ORCL_A # or RDSCDB_A for multitenant

4. 대기를 가리키는 기본 지점의 log_archive_dest_2 파라미터를 확인합니다(브로커 없이 수동으로 구성된 경우).

1. 적용률을 확인합니다.

   SQL> SELECT name, value, unit FROM v$dataguard_stats WHERE name IN ('apply rate', 'apply lag');

2. 다시 실행 적용을 위해 병렬 처리를 늘리는 것이 좋습니다(Active Data Guard 라이선스 필요).

   SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
   SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE PARALLEL 4 DISCONNECT FROM SESSION;

3. 대기 인스턴스에 리소스 제약 조건(CPU, I/O)이 없는지 확인합니다.

1. 오래된 아카이브 로그 항목을 교차 확인하고 정리합니다.

   RMAN> CROSSCHECK ARCHIVELOG ALL;
   RMAN> DELETE NOPROMPT EXPIRED ARCHIVELOG ALL;

2. 아카이브 로그 백업만 다시 실행합니다.

   RMAN> RUN {
   SQL 'ALTER SYSTEM ARCHIVE LOG CURRENT';
   BACKUP AS COMPRESSED BACKUPSET
   FILESPERSET 50
   FORMAT '/rdsdbdata/backup/arch_%U'
   ARCHIVELOG ALL;
   }

1. 최종 백업: 보관 목적으로 RDS Custom 인스턴스의 최종 백업 가져오기

   # Create final snapshot
   aws rds create-db-snapshot \
     --db-instance-identifier my-custom-instance \
     --db-snapshot-identifier my-custom-instance-final-snapshot \
     --region us-east-1

2. 마이그레이션 문서화: 새 EC2 구성으로 런북 및 설명서 업데이트

3. RDS Custom 인스턴스 삭제: AWS Console 또는 CLI를 사용하여 인스턴스 삭제

   # Delete RDS Custom instance without final snapshot (if already created above)
   aws rds delete-db-instance \
     --db-instance-identifier my-custom-instance \
     --skip-final-snapshot \
     --region us-east-1
   
   # Or create a final snapshot before deletion
   aws rds delete-db-instance \
     --db-instance-identifier my-custom-instance \
     --final-db-snapshot-identifier my-custom-instance-final-snapshot \
     --region us-east-1

4. 리소스 정리: 더 이상 필요하지 않은 경우 연결된 스냅샷, 파라미터 그룹 및 옵션 그룹 제거

5. 설명서 업데이트: 모든 운영 설명서가 새로운 EC2 기반 아키텍처를 반영하는지 확인

1. 철저한 평가를 수행합니다.

   마이그레이션을 시작하기 전에 환경에 대한 포괄적인 평가를 수행합니다.

   • 데이터베이스 인벤토리: 모든 데이터베이스, 크기, 아키텍처(비CDB 대 멀티테넌트) 및 종속성 문서화

   • 애플리케이션 종속성: 데이터베이스에 연결하는 모든 애플리케이션과 해당 연결 방법 식별

   • 성능 기준: 마이그레이션 후 비교를 위한 성능 지표(CPU, 메모리, I/O, 네트워크) 캡처

   • 백업 및 복구 요구 사항: RPO(복구 시점 목표) 및 RTO(복구 시간 목표) 문서화

   • 규정 준수 요구 사항: 마이그레이션에 영향을 미칠 수 있는 규제 또는 규정 준수 요구 사항 식별

2. 적절한 EC2 인스턴스 유형 선택:

   워크로드 특성에 따라 EC2 인스턴스 유형을 선택합니다.

   워크로드 유형	권장 인스턴스 패밀리	주요 특징
   범용 OLTP	M6i, M6a, M7i	균형 잡힌 컴퓨팅, 메모리 및 네트워크
   메모리 집약적	R6i, R6a, R7i, X2idn	높은 메모리 대 CPU 비율
   컴퓨팅 집약적	C6i, C6a, C7i	높은 CPU 성능
   I/O 집약적	I4i, Im4gn	높은 로컬 NVMe SSD 스토리지
   혼합 워크로드	M5, M5a, M5n	비용 효율적인 균형 성능

   인스턴스 크기 조정 지침:

   • RDS Custom 인스턴스와 동일한 인스턴스 클래스로 시작

   • 테스트 마이그레이션 중 리소스 사용률 모니터링

   • 권장 사항에 AWS Compute Optimizer 사용 고려

   • 성장 및 최대 부하를 위한 20~30%의 헤드룸 계획

3. 스토리지 아키텍처 설계:

   EBS 볼륨 유형:

   볼륨 유형	사용 사례	성능:	비용
   gp3	범용, 대부분의 워크로드	최대 16,000IOPS, 1,000MB/s	낮음
   io2 Block Express	미션 크리티컬, 고성능	최대 256,000IOPS, 4,000MB/s	높음
   Io1	고성능 데이터베이스	최대 64,000IOPS, 1,000MB/s	중간-높음
   gp2	레거시 범용	최대 16,000IOPS	낮음

   스토리지 레이아웃 권장 사항:

   # Recommended layout for production databases
         /u01/app/oracle          # Oracle software (50-100 GB, gp3)
         /u01/app/oracle/oradata  # Data files (sized for database, gp3 or io2)
         /u01/app/oracle/arch     # Archive logs (separate volume, gp3)
         /u01/app/oracle/backup   # Backups (separate volume, gp3, can be detached post-migration)

   별도 볼륨의 이점:

   • 독립 IOPS 할당

   • 더 쉬운 용량 관리

   • 간소화된 백업 및 스냅샷 전략

   • 성능 격리 개선

4. 롤백 계획 수립:

   항상 롤백 전략 수립:

   • 검증 기간 동안 RDS Custom 인스턴스 실행 유지(1~2주 권장)

   • 소스 및 대상 모두에 대한 정기적인 백업 유지

   • 연결 문자열 변경을 포함한 문서 롤백 절차

   • 비프로덕션 환경에서 롤백 프로세스 테스트

   • 롤백 기준 정의(성능 저하, 데이터 불일치, 애플리케이션 오류)

1. 마이그레이션 타이밍:

   최적의 기간을 선택합니다.

   • 트래픽이 적은 기간: 주말, 공휴일 또는 사용량이 적은 시간

   • 유지 관리 기간: 가능하면 예약된 유지 관리에 맞게 조정

   • 월말/분기말은 피함: 이러한 기간은 일반적으로 트랜잭션 볼륨이 많음

   • 시간대 고려: 글로벌 애플리케이션의 경우 리전 간 영향을 최소화하는 시간을 선택

2. 통신 계획:

   명확한 통신 설정:

   • 이해관계자 알림: 모든 이해관계자에게 최소 2주 전에 알림

   • 애플리케이션 팀: 연결 문자열 업데이트를 위해 애플리케이션 팀과 조정

   • 상태 업데이트: 마이그레이션 중에 정기적인 업데이트 제공

   • 에스컬레이션 경로: 문제에 대한 명확한 에스컬레이션 절차 정의

   • 마이그레이션 후 커뮤니케이션: 성공적인 완료 및 후속 조치 확인

3. 검증 체크포인트:

   각 단계에서 검증을 구현합니다.

   마이그레이션 전 검증:

   -- Capture object counts
   SQL> SELECT object_type, COUNT(*) FROM dba_objects GROUP BY object_type ORDER BY object_type;
   
   -- Capture tablespace usage
   SQL> SELECT tablespace_name, ROUND(SUM(bytes)/1024/1024/1024, 2) AS size_gb
   FROM dba_data_files GROUP BY tablespace_name;
   
   -- Capture user counts
   SQL> SELECT COUNT(*) FROM dba_users;
   
   -- For multitenant, capture PDB information
   SQL> SELECT con_id, name, open_mode FROM v$pdbs;

   마이그레이션 후 검증:

   -- Verify object counts match
   SQL> SELECT object_type, COUNT(*) FROM dba_objects GROUP BY object_type ORDER BY object_type;
   
   -- Verify no invalid objects
   SQL> SELECT owner, object_type, object_name FROM dba_objects WHERE status = 'INVALID';
   
   -- Verify tablespace usage
   SQL> SELECT tablespace_name, ROUND(SUM(bytes)/1024/1024/1024, 2) AS size_gb
   FROM dba_data_files GROUP BY tablespace_name;
   
   -- Verify database size matches
   SQL> SELECT SUM(bytes)/1024/1024/1024 AS total_size_gb FROM dba_data_files;
   
   -- For multitenant, verify all PDBs are open
   SQL> SELECT con_id, name, open_mode FROM v$pdbs;

4. 성능 검증:

   마이그레이션 전후의 성능 지표를 비교합니다.

   -- Capture AWR snapshots before migration (on RDS Custom)
   SQL> EXEC DBMS_WORKLOAD_REPOSITORY.CREATE_SNAPSHOT;
   
   -- After migration (on EC2), compare metrics
   SQL> SELECT snap_id, begin_interval_time, end_interval_time
   FROM dba_hist_snapshot
   ORDER BY snap_id DESC
   FETCH FIRST 10 ROWS ONLY;
   
   -- Generate AWR report for comparison
   SQL> @?/rdbms/admin/awrrpt.sql

   비교할 주요 지표:

   • 평균 활성 세션

   • 트랜잭션당 DB 시간

   • 초당 물리적 읽기 수

   • 초당 논리적 읽기 수

   • 초당 다시 실행 크기

   • 초당 사용자 직접 호출

   • 실행당 구문 분석 시간

1. 마이그레이션 후 데이터베이스 성능을 최적화합니다.

   1. 데이터베이스 성능 튜닝:

      통계 수집:

      -- Gather dictionary statistics
      SQL> EXEC DBMS_STATS.GATHER_DICTIONARY_STATS;
      
      -- Gather fixed object statistics
      SQL> EXEC DBMS_STATS.GATHER_FIXED_OBJECTS_STATS;
      
      -- Gather schema statistics
      SQL> EXEC DBMS_STATS.GATHER_SCHEMA_STATS('SCHEMA_NAME', cascade=>TRUE);
      
      -- For multitenant, gather statistics for each PDB
      SQL> ALTER SESSION SET CONTAINER = PDB_NAME;
      SQL> EXEC DBMS_STATS.GATHER_DATABASE_STATS(cascade=>TRUE);

      메모리 파라미터 최적화:

      -- Enable Automatic Memory Management (if not already enabled)
      SQL> ALTER SYSTEM SET MEMORY_TARGET = 24G SCOPE=SPFILE;
      SQL> ALTER SYSTEM SET MEMORY_MAX_TARGET = 28G SCOPE=SPFILE;
      SQL> SHUTDOWN IMMEDIATE;
      SQL> STARTUP;
      
      -- Or use Automatic Shared Memory Management
      SQL> ALTER SYSTEM SET SGA_TARGET = 16G SCOPE=SPFILE;
      SQL> ALTER SYSTEM SET PGA_AGGREGATE_TARGET = 8G SCOPE=SPFILE;

      결과 캐시 구성:

      -- Enable result cache for frequently accessed queries
      SQL> ALTER SYSTEM SET RESULT_CACHE_MAX_SIZE = 1G;
      SQL> ALTER SYSTEM SET RESULT_CACHE_MODE = MANUAL;

   2. 스토리지 최적화:

      압축 활성화:

      -- For tables with infrequent updates
      ALTER TABLE large_table MOVE COMPRESS FOR OLTP;
      
      -- For archive/historical data
      ALTER TABLE archive_table MOVE COMPRESS FOR ARCHIVE HIGH;
      
      -- Rebuild indexes after compression
      ALTER INDEX index_name REBUILD ONLINE;

      파티셔닝 구현:

      -- For large tables, consider partitioning
      -- Example: Range partitioning by date
      CREATE TABLE sales_partitioned (
          sale_id NUMBER,
          sale_date DATE,
          amount NUMBER
      )
      PARTITION BY RANGE (sale_date) (
          PARTITION sales_2024 VALUES LESS THAN (TO_DATE('2025-01-01', 'YYYY-MM-DD')),
          PARTITION sales_2025 VALUES LESS THAN (TO_DATE('2026-01-01', 'YYYY-MM-DD')),
          PARTITION sales_2026 VALUES LESS THAN (MAXVALUE)
      );

   3. 모니터링 및 알림 구현:

      CloudWatch 사용자 지정 지표:

      스크립트를 생성하여 CloudWatch에 Oracle 지표를 게시합니다.

      #!/bin/bash
      # publish_oracle_metrics.sh
      
      INSTANCE_ID=$(ec2-metadata --instance-id | cut -d " " -f 2)
      REGION=$(ec2-metadata --availability-zone | cut -d " " -f 2 | sed 's/[a-z]$//')
      
      # Get tablespace usage
      TABLESPACE_USAGE=$(sqlplus -s / as sysdba << EOF
      SET PAGESIZE 0 FEEDBACK OFF VERIFY OFF HEADING OFF ECHO OFF
      SELECT ROUND(MAX(percent_used), 2)
      FROM (
           SELECT tablespace_name,
                  ROUND((used_space/tablespace_size)*100, 2) AS percent_used
           FROM dba_tablespace_usage_metrics
      );
      EXIT;
      EOF
      )
      
      # Publish to CloudWatch
      aws cloudwatch put-metric-data \
        --region $REGION \
        --namespace "Oracle/Database" \
        --metric-name "TablespaceUsage" \
        --value $TABLESPACE_USAGE \
        --unit Percent \
        --dimensions InstanceId=$INSTANCE_ID,Database=ORCL
      # Add more metrics as needed (sessions, wait events, etc.)

      CloudWatch 경보를 설정합니다.

      # Create alarm for high tablespace usage
      aws cloudwatch put-metric-alarm \
        --alarm-name oracle-high-tablespace-usage \
        --alarm-description "Alert when tablespace usage exceeds 85%" \
        --metric-name TablespaceUsage \
        --namespace Oracle/Database \
        --statistic Maximum \
        --period 300 \
        --evaluation-periods 2 \
        --threshold 85 \
        --comparison-operator GreaterThanThreshold \
        --alarm-actions arn:aws:sns:region:account-id:topic-name

   4. 보안 하드닝:

      데이터베이스 보안:

      -- Enforce password complexity
      ALTER PROFILE DEFAULT LIMIT
          PASSWORD_LIFE_TIME 90
          PASSWORD_GRACE_TIME 7
          PASSWORD_REUSE_TIME 365
          PASSWORD_REUSE_MAX 5
          FAILED_LOGIN_ATTEMPTS 5
          PASSWORD_LOCK_TIME 1;
      
      -- Enable audit
      ALTER SYSTEM SET AUDIT_TRAIL = DB, EXTENDED SCOPE=SPFILE;
      SHUTDOWN IMMEDIATE;
      STARTUP;
      
      -- Audit critical operations
      AUDIT ALL ON SYS.AUD$ BY ACCESS;
      AUDIT CREATE USER BY ACCESS;
      AUDIT DROP USER BY ACCESS;
      AUDIT ALTER USER BY ACCESS;
      AUDIT CREATE SESSION BY ACCESS WHENEVER NOT SUCCESSFUL;

      네트워크 보안:

      # Restrict SSH access
      sudo vi /etc/ssh/sshd_config
      # Set: PermitRootLogin no
      # Set: PasswordAuthentication no
      
      # Configure firewall
      sudo firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="10.0.0.0/8" port port="1521" protocol="tcp" accept'
      sudo firewall-cmd --reload
      
      # Enable Oracle Native Network Encryption
      # Edit sqlnet.ora
      SQLNET.ENCRYPTION_SERVER = REQUIRED
      SQLNET.ENCRYPTION_TYPES_SERVER = (AES256, AES192, AES128)
      SQLNET.CRYPTO_CHECKSUM_SERVER = REQUIRED
      SQLNET.CRYPTO_CHECKSUM_TYPES_SERVER = (SHA256, SHA384, SHA512)

1. 백업 및 복구 전략:

   포괄적인 백업 전략을 구현합니다.

   #!/bin/bash
   # rman_backup.sh - Daily incremental backup script
   
   export ORACLE_HOME=/u01/app/oracle/product/19.0.0/dbhome_1
   export ORACLE_SID=ORCL
   export PATH=$ORACLE_HOME/bin:$PATH
   
   # Backup to local disk
   rman target / << EOF
   RUN {
       ALLOCATE CHANNEL ch1 DEVICE TYPE DISK FORMAT '/u01/app/oracle/backup/inc_%U';
       BACKUP INCREMENTAL LEVEL 1 DATABASE PLUS ARCHIVELOG;
       DELETE NOPROMPT OBSOLETE;
       CROSSCHECK BACKUP;
       DELETE NOPROMPT EXPIRED BACKUP;
   }
   EXIT;
   EOF
   
   # Copy backups to S3
   aws s3 sync /u01/app/oracle/backup/ s3://my-oracle-backups/$(date +%Y%m%d)/ \
       --storage-class STANDARD_IA \
       --exclude "*" \
       --include "inc_*" \
       --include "arch_*"
   
   # Clean up local backups older than 7 days
   find /u01/app/oracle/backup/ -name "inc_*" -mtime +7 -delete
   find /u01/app/oracle/backup/ -name "arch_*" -mtime +7 -delete

   cron을 사용하여 백업 예약:

   # Edit crontab
   crontab -e
   
   # Add backup schedule
   # Full backup on Sunday at 2 AM
   0 2 * * 0 /home/oracle/scripts/rman_full_backup.sh >> /home/oracle/logs/backup_full.log 2>&1
   
   # Incremental backup Monday-Saturday at 2 AM
   0 2 * * 1-6 /home/oracle/scripts/rman_incremental_backup.sh >> /home/oracle/logs/backup_inc.log 2>&1
   
   # Archive log backup every 4 hours
   0 */4 * * * /home/oracle/scripts/rman_archivelog_backup.sh >> /home/oracle/logs/backup_arch.log 2>&1

1. 데이터베이스 아키텍처 평가(비CDB 또는 멀티테넌트)

2. 가동 중지 시간 허용 범위 및 복잡성 요구 사항에 따라 적절한 마이그레이션 옵션 선택

3. EC2 인스턴스 설정 및 네트워크 구성을 포함한 모든 사전 조건 단계 완료

4. 선택한 옵션에 대해 자세한 마이그레이션 단계 따르기

5. 철저한 검증 및 테스트 수행

6. 마이그레이션 후 작업을 완료하여 프로덕션 준비 보장

7. 검증 성공 후 RDS Custom 인스턴스 폐기