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. EC2 でデータベースを NOMOUNT 状態で起動する

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 セッションには、次のような詳細な進行状況情報が表示されます。

   • チャネル割り当て

   • データファイルのコピーの進行状況

   • 推定完了時間

   • 処理されたバイト数

   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: full datafile restore」など)

   • 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. スタンバイコントロールファイルとデータベースを復元する

Data Guard 設定のステップ:

1. 両方のインスタンスで Oracle リスナーを設定する

2. 両方のインスタンスで tnsnames.ora を設定する

3. 両方のインスタンスで Oracle Data Guard ブローカーを起動する (オプションですが推奨)

4. Oracle Data Guard 設定を有効にする

5. EC2 スタンバイインスタンスで fal_server と fal_client を設定する

6. 両方のインスタンスでスタンバイ REDO ログファイルを設定する

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 パスに変換する: /rdsdbdata/ を /u01/app/oracle/ に置き換える

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;

   モニタリングすべき主要なメトリクス:

   • トランスポート遅延: REDO がプライマリで生成されてスタンバイで受信されるまでの時間差

   • 適用遅延: REDO が生成されてスタンバイ時に適用されるまでの時間差

   • 適用レート: REDO が適用されているレート (MB/秒)

   • 受信済み REDO: スタンバイによって受信した REDO の合計

   • 適用済み REDO: スタンバイによって適用された REDO の合計

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. マルチテナントの REDO 適用レートをモニタリングします。

   マルチテナントデータベースの場合、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. スタンバイ REDO ログをモニタリングします。

   -- 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 の iptables を確認します。

   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. スタンバイが MOUNT モードであることを確認します。

   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. REDO 適用の並列処理を増やすことを検討してください (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 コンソールまたは 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 ボリュームの種類:

   ボリュームタイプ	ユースケース	パフォーマンス	Cost
   gp3	汎用、ほとんどのワークロード	最大 16,000 IOPS、1,000 MB/秒	低
   io2 Block Express	ミッションクリティカル、高性能	最大 256,000 IOPS、4,000 MB/秒	高
   Io1	高性能データベース	最大 64,000 IOPS、1,000 MB/秒	やや高い
   gp2	レガシーの汎用	最大 16,000 IOPS	低

   ストレージレイアウトの推奨事項:

   # 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. ロールバックプランを確立する。

   常にロールバック戦略を用意しておきます。

   • 検証期間中 (1～2 週間を推奨) に RDS Custom インスタンスを実行し続ける

   • ソースとターゲットの両方の定期的なバックアップを維持する

   • 接続文字列の変更を含むロールバック手順を文書化する

   • 非本番環境でロールバックプロセスをテストする

   • ロールバック基準を定義する (パフォーマンスの低下、データの不整合、アプリケーションエラー)

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 秒あたりの論理読み取り数

   • 1 秒あたりの REDO サイズ

   • 1 秒あたりのユーザー呼び出し数

   • 実行あたりの解析時間

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 のカスタムメトリクス:

      Oracle メトリクスを CloudWatch に発行するスクリプトを作成します。

      #!/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 インスタンスを廃止する