# RDS Custom for Oracle のサポート終了 **注記** サポート終了通知: AWS は、2027 年 3 月 31 日に、Amazon RDS Custom for Oracle のサポートを終了します。2027 年 3 月 31 日以降、RDS Custom for Oracle コンソールまたは RDS Custom for Oracle リソースにアクセスできなくなります。詳細については、「[RDS Custom for Oracle のサポート終了](#RDS-Custom-for-Oracle-end-of-support)」を参照してください。 ## 概要慎重に検討した後、AWS は Amazon RDS Custom for Oracle サービスを中止することを決定しました。このサービスは、**2027 年 3 月 31 日**をもって廃止されます。この規範的ガイダンスでは、RDS Custom for Oracle から Amazon Elastic Compute Cloud (Amazon EC2) 上のセルフマネージド Oracle データベースへの移行に役立つ詳細な移行戦略を提供します。 ### 主要なタイムライン + **2026 年 3 月 31 日から 2027 年 3 月 31 日**: RDS Custom for Oracle から EC2 での Oracle 実行に移行することをお勧めします。この期間中は、既存の機能とサポートを利用して RDS Custom for Oracle を引き続き使用できます。 + **2027 年 3 月 31 日以降**: RDS Custom for Oracle サービスを使用できなくなります。 ### ターゲットオーディエンスこのガイダンスは、以下の対象者向けです。 + Oracle データベースの移行を担当するデータベース管理者 + 移行戦略を計画するクラウドアーキテクト + データベースインフラストラクチャを管理する DevOps エンジニア + 移行プロセスを監督する IT マネージャー ### 前提条件開始する前に、以下があることを確認してください。 + Oracle 19c Enterprise Edition を実行するアクティブな Amazon RDS Custom for Oracle インスタンス + EC2 インスタンスを作成および管理するための適切な AWS Identity and Access Management (IAM) アクセス許可 + データベースアーキテクチャ (非 CDB または PDB を含むマルチテナント CDB) に関する理解 + ソースインスタンスとターゲットインスタンス間のネットワーク接続計画 + 移行のバックアップと復旧戦略 ## 移行オプション移行プロセスの一環として、ビジネス要件とユースケースに基づいて、次の 2 つの移行オプションから 1 つを選択できます。 ### オプション 1: RMAN アクティブ複製 (オンライン/オフライン移行) **以下に最適:** + 最終的なカットオーバー中に計画的なダウンタイムを許容できるワークロード + 可動部分が少なく移行要件が簡素 + 簡単な 1 回限りの移行が必要なデータベース + カットオーバー前に継続的な同期を必要としないシナリオ **主な特徴** + **ダウンタイム**: 最終カットオーバー中のダウンタイムを最小限に抑えます (データベースは複製中はオンラインのままで、最終カットオーバー時のダウンタイムは短い) + **複雑さ**: データベースを直接複製することで複雑さを軽減します + **所要時間**: 移行時間はデータベースのサイズとネットワーク帯域幅によって異なります + **フォールバック**: 検証が完了するまでソースデータベースを維持する必要があります + **オンライン機能**: ソースデータベースは、複製処理中もオンラインのままでアクセス可能です **移行アプローチ:** RMAN アクティブ複製では、稼働中のソースデータベースからネットワーク経由でデータベースファイルをコピーすることで、ターゲット上にソースデータベースの正確なコピーを作成します。ソースデータベースはオンラインのままで、複製処理中もアプリケーションからアクセスできます。マルチテナントデータベースの場合、RMAN は、`CDB$ROOT`、`PDB$SEED`、およびすべてのプラガブルデータベースを含む CDB 全体を単一のオペレーションで自動的に複製します。アプリケーションを新しい EC2 インスタンスにリダイレクトするために必要なのは、ごく短いカットオーバーウィンドウのみです。 ### オプション 2: Oracle Data Guard (オンライン移行) **以下に最適:** + 最小限のダウンタイムを必要とする本稼働ワークロード + 可用性を維持する必要があるミッションクリティカルなデータベース + カットオーバー前に継続的な同期が必要なシナリオ + 組み込みフォールバック機能を必要とする移行 **主な特徴** + **ダウンタイム**: ダウンタイムはほぼゼロ (スイッチオーバーは数秒から数分) + **複雑さ**: Data Guard 設定による複雑性の増加 + **期間**: 初期セットアップ時間とスイッチオーバーまでの継続的な同期時間 + **フォールバック**: ソースをスタンバイとして保持することでフォールバック機能を組み込み **移行アプローチ:** Oracle Data Guard は、プライマリデータベースから REDO ログを継続的に配布して適用することで、同期されたスタンバイデータベースを維持します。移行を完了する準備ができたら、最小限のダウンタイムで EC2 スタンバイをプライマリに昇格させるスイッチオーバーを実行します。マルチテナントデータベースの場合、Data Guard はすべての PDB を含む CDB 全体を自動的に保護します。 **ディシジョンマトリックス** 次のマトリックスを使用して、適切な移行オプションを選択します。 | **側面** | **RMAN アクティブ複製** | **Oracle Data Guard** | | --- | --- | --- | | **ソースデータベースの可用性** | 複製中はオンライン | プロセス全体を通してオンライン | | **許容できるダウンタイム** | 数分から数時間 (最終カットオーバー) | 数秒から数分 (スイッチオーバー) | | **移行の複雑さ** | Lower | より高い | | **継続的な同期** | いいえ | あり | | **フォールバック機能** | 手動 (ソースを保持) | 組み込み (自動) | | **カットオーバー前のテスト** | 制限あり | 完全なテストが可能 | | **ネットワーク帯域幅要件** | 複製中は高 | 中程度 (連続) | | **次の用途に適しています** | ほとんどの移行、開発/テスト、計画されたカットオーバー | 本番環境、ミッションクリティカル、ほぼゼロのダウンタイム | ### アーキテクチャに関する考慮事項どちらの移行オプションも、2 つの Oracle データベースアーキテクチャをサポートしています。 **非 CDB** マルチテナントアーキテクチャを持たない従来の単一インスタンス Oracle データベース。これらのデータベースは次の特徴を持ちます。 + 単一のデータベースインスタンスを持つ + プラガブルデータベース (PDB) を使用しない + 管理と移行が簡単 + RDS Custom for Oracle では通常 ORCL という名前 **マルチテナント (PDB を含む CDB)** Oracle 12c で導入された複数のプラガブルデータベース (PDB) をホストするコンテナデータベース (CDB)。これらのデータベースは次の特徴を持ちます。 + `CDB$ROOT` および `PDB$SEED` でコンテナデータベース (CDB) を使用する + 1 つ以上のプラガブルデータベース (PDB) ホストする + データベース統合とリソース分離を提供する + RDS Custom for Oracle では通常 RDSCDB という名前 + PDB データファイルには、GUID ベースのサブディレクトリを持つ Oracle Managed Files (OMF) を使用する **マルチテナント移行に関する重要な注意点:** 移行プロセス中にターゲットデータベースの名前が ORCL に変更されます (ソース: RDSCDB → ターゲット: ORCL)。これにより、ターゲット設定が簡素化され、標準的な命名規則に準拠します。 **移行アプローチの主な違い** | **側面** | **非 CDB** | **マルチテナント (PDB を含む CDB)** | | --- | --- | --- | | **移行範囲** | 単一のデータベース | すべての PDB を含む CDB 全体 | | **移行後の状態** | データベースは READ WRITE でオープン | CDB は READ WRITE でオープン、PDB は MOUNTED 状態 | | **PDB 管理** | 該当なし | PDB を開き、自動オープンを設定する必要があります | | **クリーンアップ** | 単一のデータベース | CDB$ROOT (PDB にカスケード)、C\#\# 共通ユーザーを扱う | | **アプリケーション接続** | データベースサービス | PDB サービス (CDB ではない) | | **パラメータファイル** | 標準パラメータ | enable\_pluggable\_database=TRUE が必要 | | **複雑さ** | Lower | 複数のコンテナが原因で高 | ## 両方の移行オプションに共通する前提条件いずれの移行オプションを開始する前に、以下の前提条件のステップを完了してください。 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 を使用することを検討してください。 1. ストレージアーキテクチャを設定する 1. ファイルシステムストレージ (ほとんどのシナリオで推奨) + Oracle データファイルに標準ファイルシステムディレクトリを使用します + 管理が簡単で、ほとんどのワークロードに適しています + このガイダンスでは、ファイルシステムストレージの例を使用します 1. Oracle Automatic Storage Management (ASM) + ワークロードに ASM が必要な場合は、EC2 インスタンスにスタンドアロン ASM をインストールして設定します + ASM ディスクグループ (\+DATA、\+FRA など) を使用するように init ファイル内のすべてのパスパラメータを調整します + 移行プロセスは ASM でも同様ですが、パスを調整します 1. ファイル転送メカニズムを設定する RDS Custom インスタンスと EC2 インスタンス間でファイルを転送するメカニズムを作成します。これには複数のオプションがあります。 1. オプション A: Amazon S3 (ほとんどのシナリオで推奨) + Amazon S3 バケットを作成するか、既存のバケットを使用します + 両方のインスタンスに AWS CLI をインストールして設定します + 手順については、「[AWS CLI の開始方法](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-started.html)」を参照してください。 1. オプション B: SCP/SFTP による直接転送 + インスタンス間で SSH ポートが開いている場合は、ファイルを直接転送できます + パラメータファイルやパスワードファイルなどの小さなファイルに適しています 1. オプション C: Amazon EFS + 両方のインスタンスに Amazon EFS が既にマウントされている場合は、共有ファイルシステムとして使用できます + 既存の EFS インフラストラクチャを持つ環境に適していますこのガイダンスでは、Amazon S3 を例として使用していますが、選択したメソッドに合わせてコマンドを適応させることができます。 1. ネットワーク接続の設定 RDS Custom インスタンスと EC2 インスタンス間のネットワーク接続を確認します。 + **同じ VPC**: セキュリティグループは Oracle リスナーポート (デフォルトは 1521、またはカスタムポート) で双方向トラフィックを許可する必要があります + **異なる VPC (同じアカウント)**: VPC ピアリングを設定し、ルートテーブルとセキュリティグループを設定します + **異なるアカウント**: アカウント間で VPC ピアリングを設定するか、AWS Transit Gateway を使用します + **接続の検証**: ping と telnet を使用してデータベースポートの接続をテストします 1. EC2 でディレクトリ構造を作成するディレクトリ構造は、データベースアーキテクチャによって異なります。 **Example 非 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 ``` **Example マルチテナント (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 ボリュームを使用することを検討してください。これにより、移行が完了したら簡単にデタッチおよび削除し、ストレージコストを削減できます。 1. ソースデータベースの設定を確認します移行を開始する前に、ソースデータベースの設定を確認します。 1. RDS Custom データベースホストに rdsdb ユーザーとしてログインし、環境を設定します。 **Example** ``` # 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 ``` 1. データベースに接続し、アーキテクチャを確認します。 **Example** ``` sqlplus / as sysdba SQL> SELECT name, cdb, open_mode, log_mode FROM v$database; ``` **Example 非 CDB の場合、予想される出力** ``` NAME CDB OPEN_MODE LOG_MODE --------- --- -------------------- ------------ ORCL NO READ WRITE ARCHIVELOG ``` **Example マルチテナント (CDB) の場合、予想される出力。** ``` NAME CDB OPEN_MODE LOG_MODE --------- --- -------------------- ------------ RDSCDB YES READ WRITE ARCHIVELOG ``` 1. **マルチテナント CDB がある場合は**、すべての PDB とそのステータスを一覧表示します。 **Example** ``` SQL> SELECT con_id, name, open_mode, restricted FROM v$pdbs; ``` 予想される出力 (ORCLDB という名前の PDB が 1 つある場合の例)。 **Example** ``` CON_ID NAME OPEN_MODE RES ---------- ------------------------------ ---------- --- 2 PDB$SEED READ ONLY NO 3 ORCLDB READ WRITE NO ``` 1. データベースの合計サイズを確認します。 **Example 非 CDB の場合:** ``` SQL> SELECT SUM(bytes)/1024/1024/1024 AS total_size_gb FROM dba_data_files; ``` **Example マルチテナントの場合。** ``` -- 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: RMAN アクティブ複製を使用した物理移行 **Topics** + [RMAN アクティブ複製を使用するタイミング](#RDS-Custom-for-Oracle-end-of-support-option-1-when-to-use) + [RMAN アクティブ複製の概要](#RDS-Custom-for-Oracle-end-of-support-option-1-overview) + [RMAN アクティブ複製の移行ワークフロー](#RDS-Custom-for-Oracle-end-of-support-option-1-migration-workflow) + [ステップ 1: Amazon RDS Custom オートメーションを一時停止する](#RDS-Custom-for-Oracle-end-of-support-option-1-step-1) + [ステップ 2: パスワードとパラメータファイルを作成する](#RDS-Custom-for-Oracle-end-of-support-option-1-step-2) + [ステップ 3: EC2 を使用してファイルを転送する](#RDS-Custom-for-Oracle-end-of-support-option-1-step-3) + [ステップ 4: EC2 でパラメータファイルを編集する](#RDS-Custom-for-Oracle-end-of-support-option-1-step-4) + [ステップ 5: TNS とリスナーを設定する](#RDS-Custom-for-Oracle-end-of-support-option-1-step-5) + [ステップ 6: EC2 でデータベースを `NOMOUNT` で起動する](#RDS-Custom-for-Oracle-end-of-support-option-1-step-6) + [ステップ 7: RMAN アクティブ複製を実行する](#RDS-Custom-for-Oracle-end-of-support-option-1-step-7) + [ステップ 8: PDB を開く (マルチテナントのみ)](#RDS-Custom-for-Oracle-end-of-support-option-1-step-8) + [ステップ 9: RDS Custom オブジェクトを削除する](#RDS-Custom-for-Oracle-end-of-support-option-1-step-9) + [ステップ 10: 自動起動を設定する](#RDS-Custom-for-Oracle-end-of-support-option-1-step-10) + [ステップ 11: 最終検証](#RDS-Custom-for-Oracle-end-of-support-option-1-step-11) このセクションでは、RMAN アクティブ複製を使用して Oracle データベースを RDS Custom for Oracle から EC2 に移行する詳細な手順について説明します。このメソッドでは、稼働中のデータベースから複製され、移行プロセス中にソースをオンラインに保ち、アクセスできるようにします。 ### RMAN アクティブ複製を使用するタイミング次の場合に RMAN アクティブ複製を選択します。 + 移行中にソースデータベースをオンラインにしてアクセス可能にしたい + 最終的なアプリケーションリダイレクトのために、ごく短いカットオーバーウィンドウを利用できる + 可動部分が少ない簡単な移行プロセスが必要 + データベースサイズとネットワーク帯域幅により、妥当な複製時間を確保できる + カットオーバー前に継続的な同期は必要ない + 本番稼働用データベース、開発用データベース、またはテスト用データベースを移行している ### RMAN アクティブ複製の概要 RMAN アクティブ複製では、ソースデータベースのバックアップや、ソースデータベースをオフラインにする必要はありません。ソースがオンラインのままでアプリケーションにアクセス可能な状態を維持しながら、ネットワーク経由でデータベースファイルをコピーすることで、稼働中のソースデータベースを移行先に複製します。 **主な利点。** + **ソースはオンラインのまま**: アプリケーションは複製中にソースデータベースに引き続きアクセスできます + **バックアップ不要**: 中間バックアップストレージの必要性を排除します + **直接ネットワーク転送**: データベースファイルはソースからターゲットに直接コピーされます + **自動整合性**: RMAN は、複製するデータベースの整合性が保たれるようにします + **単一オペレーション**: マルチテナントの場合、すべての PDB を含む CDB 全体を単一のオペレーションで複製します複製プロセスでは、すべてのデータファイル、コントロールファイル、REDO ログなど、ソースデータベースの正確なコピーがターゲットに作成されます。ソースデータベースは、複製プロセス全体を通してアプリケーションのリクエストを処理し続けます。最後に、アプリケーションをソースからターゲットにリダイレクトするため必要なのは、ごく短いカットオーバーウィンドウのみです。 **一般的なタイムライン** 1. **複製フェーズ** (ソースはオンラインのまま): データベースのサイズに応じて 30 分から数時間 1. **検証フェーズ** (ソースはオンラインのまま): 必要に応じて数時間から数日 1. **カットオーバーフェーズ** (短時間のダウンタイム): アプリケーションを EC2 にリダイレクトするのに数分 ### RMAN アクティブ複製の移行ワークフロー **RDS Custom DB インスタンス (ソース) のステップ。** 1. Amazon RDS Custom オートメーションを一時停止する 1. データベースアーキテクチャを検証する (非 CDB または PDB を含む CDB) 1. ソースデータベースからパスワードファイルとパラメータファイルを作成する 1. パスワードファイルとパラメータファイルをターゲット EC2 インスタンスにコピーする 1. ソースデータベースがアーカイブログモードで実行されていることを確認する 1. RDS Custom DB サーバーで tnsnames.ora を設定する **EC2 DB インスタンス (ターゲット) のステップ。** 1. EC2 のパラメータファイルを編集する (アーキテクチャ固有) 1. EC2 で tnsnames.ora を設定する 1. EC2 インスタンスの環境を設定する 1. EC2 で Oracle Listener を設定する 1. EC2 でデータベースを NOMOUNT 状態で起動する **RMAN 複製のステップ。** 1. RMAN アクティブ複製を実行する 1. データベースを (マルチテナントの場合は PDB も) 開く 1. PDB の自動オープンを設定する (マルチテナントのみ) 1. RDS Custom 固有のユーザーとオブジェクトを削除する 1. SPFILE を作成し、自動起動を設定する 1. ソースで Amazon RDS Custom オートメーションを再開する (アクティブな状態を維持する場合) ### ステップ 1: Amazon RDS Custom オートメーションを一時停止する移行手順を進める前に、RDS Custom インスタンスでオートメーションモードを一時停止して、オートメーションが RMAN アクティビティに干渉しないようにします。--resume-full-automation-mode-minute パラメータ (この例では 240 分 = 4 時間) は、データベースのサイズと予想される複製時間に基づいて調整する必要があります。 **重要**: オートメーションを一時停止しても、データベースの可用性には影響しません。データベースはオンラインのままで、複製処理中もアプリケーションからアクセスできます。 **Example** ``` aws rds modify-db-instance \ --db-instance-identifier my-custom-instance \ --automation-mode all-paused \ --resume-full-automation-mode-minute 240 \ --region us-east-1 --query 'DBInstances[0].AutomationMode' ``` オートメーションステータスを検証します。 **Example** ``` aws ds describe-db-instances \ --db-instance-identifier my-custom-instance \ --region us-east-1 \ --query 'DBInstances[0].AutomationMode' ``` 正常な出力: 「`all-paused`」 ### ステップ 2: パスワードとパラメータファイルを作成する `orapwd` を使用してパスワードファイルを作成します。AWS Secrets Manager から SYS パスワードを取得します (RDS Custom インスタンスの作成時に保存されたもの)。 **Example** ``` # Non-CDB $ORACLE_HOME/bin/orapwd file=/rdsdbdata/config/orapwORCL password={{}} entries=10 # Multitenant $ORACLE_HOME/bin/orapwd file=/rdsdbdata/config/orapwRDSCDB password={{}} entries=10 ``` ソースデータベースからパラメータファイルを作成します。 **Example** ``` sqlplus / as sysdba SQL> CREATE PFILE='/tmp/initORCL.ora' FROM SPFILE; -- Non-CDB SQL> CREATE PFILE='/tmp/initRDSCDB.ora' FROM SPFILE; -- Multitenant ``` 生成されたパラメータファイルには、RDS Custom 固有のパスとパラメータが含まれます。マルチテナントの場合、キーパラメータには以下が含まれます。 + `enable_pluggable_database`=`TRUE` (マルチテナントにとって重要) + `noncdb_compatible`=`TRUE` (下位互換性のため) + `CDB$ROOT`、`PDB$SEED` およびすべての PDB のデータファイルパス + OMF 用の `db_create_file_dest` および `db_create_online_log_dest_1` ### ステップ 3: EC2 を使用してファイルを転送する任意のファイル転送方法を選択します。このガイダンスでは、Amazon S3 を例として使用します。 **Amazon S3 の使用** #### Amazon S3 の使用。 **Example 非 CDB の場合:** ``` # Copy files to Amazon S3 from the RDS Custom instance aws s3 cp /tmp/initORCL.ora s3://{{}}/ aws s3 cp /rdsdbdata/config/orapwORCL s3://{{}}/ # On EC2, download files aws s3 cp s3://{{}}/initORCL.ora $ORACLE_HOME/dbs/ aws s3 cp s3://{{}}/orapwORCL $ORACLE_HOME/dbs/ ``` **Example マルチテナントの場合** ``` # Copy files to Amazon S3 from the RDS Custom instance aws s3 cp /tmp/initRDSCDB.ora s3://{{}}/ aws s3 cp /rdsdbdata/config/orapwRDSCDB s3://{{}}/ # On EC2, download and rename files to use ORCL naming aws s3 cp s3://{{}}/initRDSCDB.ora $ORACLE_HOME/dbs/initORCL.ora aws s3 cp s3://{{}}/orapwRDSCDB $ORACLE_HOME/dbs/orapwORCL ``` EC2 のファイルを検証します。 **Example** ``` ls -l $ORACLE_HOME/dbs/initORCL.ora ls -l $ORACLE_HOME/dbs/orapwORCL ``` ### ステップ 4: EC2 でパラメータファイルを編集する移行を成功させるためには、パラメータファイルを慎重に編集する必要があります。これは、移行プロセスにおける最も重要なステップの 1 つです。 EC2 インスタンスで `$ORACLE_HOME/dbs/initORCL.ora` を編集し、以下の重要な変更を加えます。 1. **データベース名の更新**: マルチテナントの場合は、RDSCDB のすべての出現箇所を ORCL に変更する 1. **RDS Custom パスを EC2 パスに変換する**: /rdsdbdata/ を /u01/app/oracle/ に置き換える 1. **RDS Custom 固有のパラメータを削除する** + `dg_broker_config_file1` および `dg_broker_config_file2` (存在する場合 - レプリカが存在することを示します) + `standby_file_management` (存在する場合) + `spfile` (後で新しい SPFILE を作成します) + スタンバイ送信先を指す `log_archive_dest` パラメータ (ローカルアーカイブの場合は `log_archive_dest_1` のみを保持) 1. **ファイル名変換パラメータを追加する** (以下を参照) 1. EC2 インスタンスのサイズに基づいて**メモリパラメータを調整する** (オプションですが推奨) **ファイル名変換パラメータについて。** `DB_FILE_NAME_CONVERT` および `LOG_FILE_NAME_CONVERT` パラメータは、RMAN 複製に不可欠です。これらは、複製プロセス中にソースファイルパスをターゲットファイルパスにマッピングする方法を RMAN に伝えます。これらのパラメータがないと、RMAN はソースと同じパスにファイルを作成しようとしますが、EC2 では失敗します。 **主な考慮事項:** + 各パラメータは文字列のペアを受け入れます。ソースパスの後にターゲットパスが続きます + 1 つのパラメータで複数のペアを指定できます + マルチテナントの場合、`CDB$ROOT`、`PDB$SEED` およびすべての PDB のパスをマッピングする必要があります + ペアの順序は重要です - RMAN は指定された順序でペアを処理します + パスでは大文字と小文字が区別され、正確に一致する必要があります **パスマッピング:** **非 CDB:** | **RDS Custom パス** | **EC2 パス** | **説明** | | --- | --- | --- | | /rdsdbbin | /u01/app/oracle | Oracle ベース | | /rdsdbdata/db/ORCL\_A/datafile/ | /u01/app/oracle/oradata/ORCL/datafile/ | データファイル | | /rdsdbdata/db/ORCL\_A/controlfile/ | /u01/app/oracle/oradata/ORCL/controlfile/ | コントロールファイル | | /rdsdbdata/db/ORCL\_A/onlinelog/ | /u01/app/oracle/oradata/ORCL/onlinelog/ | オンライン REDO ログ | | /rdsdbdata/db/ORCL\_A/arch/ | /u01/app/oracle/oradata/ORCL/arch/ | ログのアーカイブ | | /rdsdbdata/admin/ORCL/adump | /u01/app/oracle/admin/ORCL/adump | 監査ダンプ | | /rdsdbdata/log | /u01/app/oracle | 診断の送信先 | **マルチテナント** | **RDS Custom パス** | **EC2 パス** | **説明** | | --- | --- | --- | | /rdsdbbin | /u01/app/oracle | Oracle ベース | | /rdsdbdata/db/cdb/RDSCDB/datafile/ | /u01/app/oracle/oradata/ORCL/cdb/datafile/ | CDB ルートデータファイル | | /rdsdbdata/db/cdb/pdbseed/ | /u01/app/oracle/oradata/ORCL/pdbseed/datafile/ | PDB$SEED データファイル | | /rdsdbdata/db/pdb/RDSCDB\_A/ | /u01/app/oracle/oradata/ORCL/pdb/datafile/ | PDB データファイル (GUID 付き OMF) | | /rdsdbdata/db/cdb/RDSCDB\_A/controlfile/ | /u01/app/oracle/oradata/ORCL/controlfile/ | コントロールファイル | | /rdsdbdata/db/cdb/RDSCDB\_A/onlinelog/ | /u01/app/oracle/oradata/ORCL/onlinelog/ | オンライン REDO ログ | | /rdsdbdata/db/cdb/RDSCDB\_A/arch/redolog | /u01/app/oracle/oradata/ORCL/arch/ | ログのアーカイブ | | /rdsdbdata/admin/RDSCDB/adump | /u01/app/oracle/admin/ORCL/adump | 監査ダンプ | | /rdsdbdata/log | /u01/app/oracle | 診断の送信先 | **変換パラメータを追加する。** **Example 非 CDB:** ``` *.DB_FILE_NAME_CONVERT='/rdsdbdata/db/ORCL_A/datafile/','/u01/app/oracle/oradata/ORCL/datafile/' *.LOG_FILE_NAME_CONVERT='/rdsdbdata/db/ORCL_A/onlinelog/','/u01/app/oracle/oradata/ORCL/onlinelog/' ``` **Example **マルチテナント** (CDB ルート、`PDB$SEED`、およびすべての PDB パスのマッピングを含める必要があります)。** ``` *.DB_FILE_NAME_CONVERT='/rdsdbdata/db/cdb/RDSCDB/datafile/','/u01/app/oracle/oradata/ORCL/cdb/datafile/','/rdsdbdata/db/cdb/pdbseed/','/u01/app/oracle/oradata/ORCL/pdbseed/datafile/','/rdsdbdata/db/pdb/RDSCDB_A/','/u01/app/oracle/oradata/ORCL/pdb/datafile/' *.LOG_FILE_NAME_CONVERT='/rdsdbdata/db/cdb/RDSCDB_A/onlinelog/','/u01/app/oracle/oradata/ORCL/onlinelog/' ``` **重要**: マルチテナントの場合は、パラメータファイルに `enable_pluggable_database`=`TRUE` が存在することを確認します。RDS Custom は、GUID ベースのサブディレクトリを持つ PDB データファイルに OMF を使用します。これはパスマッピングによって自動的に処理されます。 **完全なパラメータファイルの例。** **Example 非 CDB パラメータファイルの例 (`initORCL.ora`)。** ``` ORCL.__data_transfer_cache_size=0 ORCL.__db_cache_size=6039797760 ORCL.__inmemory_ext_roarea=0 ORCL.__inmemory_ext_rwarea=0 ORCL.__java_pool_size=0 ORCL.__large_pool_size=33554432 ORCL.__oracle_base='/u01/app/oracle' ORCL.__pga_aggregate_target=4966055936 ORCL.__sga_target=7449083904 ORCL.__shared_io_pool_size=134217728 ORCL.__shared_pool_size=1207959552 ORCL.__streams_pool_size=0 ORCL.__unified_pga_pool_size=0 *.archive_lag_target=300 *.audit_file_dest='/u01/app/oracle/admin/ORCL/adump' *.compatible='19.0.0' *.control_files='/u01/app/oracle/oradata/ORCL/controlfile/control-01.ctl' *.db_block_checking='MEDIUM' *.db_create_file_dest='/u01/app/oracle/oradata/ORCL' *.db_name='ORCL' *.db_recovery_file_dest_size=1073741824 *.db_unique_name='ORCL' *.dbfips_140=FALSE *.diagnostic_dest='/u01/app/oracle' *.filesystemio_options='setall' *.heat_map='OFF' *.job_queue_processes=50 *.local_listener='(address=(protocol=tcp)(host=)(port=1521))' *.log_archive_dest_1='location="/u01/app/oracle/oradata/ORCL/arch", valid_for=(ALL_LOGFILES,ALL_ROLES)' *.log_archive_format='-%s-%t-%r.arc' *.max_string_size='STANDARD' *.memory_max_target=12385852416 *.memory_target=12385852416 *.open_cursors=300 *.pga_aggregate_target=0 *.processes=1673 *.recyclebin='OFF' *.sga_target=0 *.undo_tablespace='UNDO_T1' *.use_large_pages='FALSE' *.DB_FILE_NAME_CONVERT='/rdsdbdata/db/ORCL_A/datafile/','/u01/app/oracle/oradata/ORCL/datafile/' *.LOG_FILE_NAME_CONVERT='/rdsdbdata/db/ORCL_A/onlinelog/','/u01/app/oracle/oradata/ORCL/onlinelog/' ``` **Example マルチテナントパラメータファイルの例 (`initORCL.ora`)。** ``` ORCL.__data_transfer_cache_size=0 ORCL.__db_cache_size=6006243328 ORCL.__inmemory_ext_roarea=0 ORCL.__inmemory_ext_rwarea=0 ORCL.__java_pool_size=0 ORCL.__large_pool_size=33554432 ORCL.__oracle_base='/u01/app/oracle' ORCL.__pga_aggregate_target=4966055936 ORCL.__sga_target=7415529472 ORCL.__shared_io_pool_size=134217728 ORCL.__shared_pool_size=1207959552 ORCL.__streams_pool_size=0 ORCL.__unified_pga_pool_size=0 *.archive_lag_target=300 *.audit_file_dest='/u01/app/oracle/admin/ORCL/adump' *.compatible='19.0.0' *.control_files='/u01/app/oracle/oradata/ORCL/controlfile/control-01.ctl' *.db_block_checking='MEDIUM' *.db_create_file_dest='/u01/app/oracle/oradata/ORCL/pdb/datafile' *.db_create_online_log_dest_1='/u01/app/oracle/oradata/ORCL' *.db_name='ORCL' *.db_recovery_file_dest_size=1073741824 *.db_unique_name='ORCL' *.dbfips_140=FALSE *.diagnostic_dest='/u01/app/oracle' *.enable_pluggable_database=TRUE *.filesystemio_options='setall' *.heat_map='OFF' *.job_queue_processes=50 *.local_listener='(address=(protocol=tcp)(host=)(port=1521))' *.log_archive_dest_1='location="/u01/app/oracle/oradata/ORCL/arch", valid_for=(ALL_LOGFILES,ALL_ROLES)' *.log_archive_format='-%s-%t-%r.arc' *.max_string_size='STANDARD' *.memory_max_target=12361688064 *.memory_target=12361688064 *.noncdb_compatible=TRUE *.open_cursors=300 *.pga_aggregate_target=0 *.processes=1670 *.recyclebin='OFF' *.sga_target=0 *.undo_tablespace='UNDO_T1' *.use_large_pages='FALSE' *.DB_FILE_NAME_CONVERT='/rdsdbdata/db/cdb/RDSCDB/datafile/','/u01/app/oracle/oradata/ORCL/cdb/datafile/','/rdsdbdata/db/cdb/pdbseed/','/u01/app/oracle/oradata/ORCL/pdbseed/datafile/','/rdsdbdata/db/pdb/RDSCDB_A/','/u01/app/oracle/oradata/ORCL/pdb/datafile/' *.LOG_FILE_NAME_CONVERT='/rdsdbdata/db/cdb/RDSCDB_A/onlinelog/','/u01/app/oracle/oradata/ORCL/onlinelog/' ``` **キーパラメータの説明。** + `enable_pluggable_database=TRUE`: マルチテナント CDB に必要です。このパラメータは、プラガブルデータベース機能を有効にします。 + `noncdb_compatible=TRUE`: 下位互換性のために RDS Custom で設定します。要件に基づいて保持または削除できます。 + `db_create_file_dest`: Oracle Managed Files (OMF) のデフォルトの場所を指定します。マルチテナントの場合、これは PDB データファイルディレクトリを指します。 + `db_create_online_log_dest_1`: OMF を使用するときのオンライン REDO ログの場所を指定します。 + `DB_FILE_NAME_CONVERT`: RMAN 複製に不可欠です。ソースデータファイルパスをターゲットパスにマッピングします。 + `LOG_FILE_NAME_CONVERT`: ソース REDO ログパスをターゲットパスにマッピングします。 + `memory_target` および `memory_max_target`: EC2 インスタンスのメモリに基づいてこれらを調整します。表示されている値は例です。 + `processes`: Oracle に接続できるオペレーティングシステムプロセスの最大数。ワークロードに基づいて調整します。 **メモリサイズ設定のガイドライン。** EC2 インスタンスのメモリパラメータを調整する場合。 | **EC2 インスタンスメモリ** | **推奨 memory\_target** | **推奨 memory\_max\_target** | | --- | --- | --- | | 16 GB | 12 GB (12884901888 バイト) | 14 GB (15032385536 バイト) | | 32 GB | 24 GB (25769803776 バイト) | 28 GB (30064771072 バイト) | | 64 GB | 48 GB (51539607552 バイト) | 56 GB (60129542144 バイト) | | 128 GB | 96 GB (103079215104 バイト) | 112 GB (120259084288 バイト) | システムメモリの約 20～25% をオペレーティングシステムやその他のプロセス用に残します。 ### ステップ 5: TNS とリスナーを設定する両方のインスタンスで、`tnsnames.ora` に TNS エントリをに追加します。 **Example 非 CDB:** ``` DB_SOURCE = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = {{}})(PORT = 1521)) (CONNECT_DATA = (SID = ORCL))) DB_TARGET = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = {{}})(PORT = 1521)) (CONNECT_DATA = (SID = ORCL))) ``` **Example マルチテナント。** ``` DB_SOURCE = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = {{}})(PORT = 1521)) (CONNECT_DATA = (SID = RDSCDB))) DB_TARGET = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = {{}})(PORT = 1521)) (CONNECT_DATA = (SID = ORCL))) ``` **Example EC2 でリスナーを設定します (`$ORACLE_HOME/network/admin/listener.ora`)。** ``` LISTENER = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = {{}})(PORT = 1521))) SID_LIST_LISTENER = (SID_LIST = (SID_DESC = (GLOBAL_DBNAME = ORCL) (ORACLE_HOME = /u01/app/oracle/product/19.0.0/dbhome_1) (SID_NAME = ORCL))) ``` **Example リスナーを起動します。** ``` lsnrctl start ``` **注記** RMAN アクティブ複製の場合、TNS エントリは SID (SERVICE\_NAME ではない) を使用してデータベースインスタンスに接続します。マルチテナントの場合、これは CDB に接続され、RMAN はすべての PDB を自動的に複製します。 ### ステップ 6: EC2 でデータベースを `NOMOUNT` で起動する **Example** ``` export ORACLE_SID=ORCL export ORACLE_HOME=/u01/app/oracle/product/19.0.0/dbhome_1 export PATH=$ORACLE_HOME/bin:$PATH sqlplus / as sysdba SQL> STARTUP NOMOUNT PFILE='$ORACLE_HOME/dbs/initORCL.ora'; ``` **Example パラメータを確認する。** ``` SQL> SHOW PARAMETER db_name SQL> SHOW PARAMETER control_files SQL> SHOW PARAMETER enable_pluggable_database -- For multitenant ``` ### ステップ 7: RMAN アクティブ複製を実行する RMAN アクティブ複製は、稼働中のソースからターゲットにデータベースをコピーします。ソースデータベースはオンラインのままで、このプロセス全体を通してアプリケーションからアクセスできます。 RMAN をソースインスタンスとターゲットインスタンスの両方に接続します。 **Example** ``` rman target sys/{{}}@DB_SOURCE auxiliary sys/{{}}@DB_TARGET ``` **Example 非 CDB の場合の予想される出力。** ``` Recovery Manager: Release 19.0.0.0.0 - Production connected to target database: ORCL (DBID=4089929259) connected to auxiliary database: ORCL (not mounted) ``` **Example マルチテナントの予想される出力。** ``` Recovery Manager: Release 19.0.0.0.0 - Production connected to target database: RDSCDB (DBID=4089929259) connected to auxiliary database: ORCL (not mounted) ``` **Example アクティブ複製コマンドを実行します。** ``` RMAN> DUPLICATE DATABASE TO 'ORCL' FROM ACTIVE DATABASE NOFILENAMECHECK; ``` **注記** **ソースはオンラインのまま**: ソースデータベースは、複製している間もアプリケーションリクエストを処理し続けます **非 CDB の場合**: オンラインのままデータベース全体を複製します **マルチテナントの場合**: ソースがオンラインのまま、`CDB$ROOT`、`PDB$SEED`、およびすべての PDB を含む CDB 全体が 1 回のオペレーションで複製されます。 **NOFILENAMECHECK**: ファイル名がソースとターゲットで異なっていても RMAN が続行できるようにします **期間**: データベースのサイズとネットワーク帯域幅によって異なります。100GB のデータベースの場合、30～60 分かかります **ネットワークへの影響:** 複製中はネットワーク帯域幅の使用量が多くなりますが、ソースデータベースには引き続きアクセスできます **RMAN アクティブ複製プロセスには、いくつかのフェーズが含まれます。** 1. ソースおよびターゲットデータベースに接続する 1. ターゲットのメモリから `SPFILE` を作成する 1. コントロールファイルをターゲットに復元する 1. ターゲットデータベースをマウントする 1. ネットワーク経由でソースからターゲットにすべてのデータファイルをコピーする (ソースはオンラインのまま) 1. ターゲットデータベースを復旧する 1. `RESETLOGS` を使用してターゲットデータベースを開く **複製中、ソースデータベースは次の操作を行います。** + `READ WRITE` モードのまま維持される + 接続を引き続き受け入れる + トランザクションを通常どおり処理する + 通常どおり REDO ログを生成する + アプリケーションから完全にアクセスできる **Example 別のセッションで進行状況をモニタリングします。** ``` SQL> SELECT sid, serial#, sofar, totalwork, ROUND(sofar/totalwork*100,2) pct_complete FROM v$session_longops WHERE totalwork > 0 AND sofar <> totalwork; ``` **RMAN 複製時の詳細なモニタリングとトラブルシューティング:** RMAN 複製の実行中に、いくつかの方法を使用して進行状況をモニタリングできます。 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 ``` **Example 出力例:** ``` 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 ``` 1. **長時間実行されるオペレーションをモニタリングします。** **Example ターゲット 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`: これまでに経過した時間 1. **RMAN チャネルをモニタリングします。** **Example** ``` 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; ``` 1. **アラートログを確認します。** **Example ターゲット 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`) であることを確認します。 ### ステップ 8: PDB を開く (マルチテナントのみ) RMAN 複製が完了すると、EC2 の CDB は `READ WRITE` モードで開きますが、すべての PDB は `MOUNTED` 状態になります。これは想定される動作です。手動で開く必要があります。現在の PDB ステータスを確認します。 ``` SQL> SELECT con_id, name, open_mode FROM v$pdbs; ``` 予想される出力 (`ORCLDB` という名前の PDB が 1 つある場合の例)。 ``` CON_ID NAME OPEN_MODE ---------- ------------------------------ ---------- 2 PDB$SEED READ ONLY 3 ORCLDB MOUNTED ``` すべての PDB を開きます。 ``` SQL> ALTER PLUGGABLE DATABASE ALL OPEN; Pluggable database altered. ``` すべての PDB が `READ WRITE` モードでオープンされていることを確認します。 ``` SQL> SELECT con_id, name, open_mode, restricted FROM v$pdbs; ``` 正常な出力: ``` CON_ID NAME OPEN_MODE RES ---------- ------------------------------ ---------- --- 2 PDB$SEED READ ONLY NO 3 ORCLDB READ WRITE NO ``` 状態保存メソッド (Oracle 19c に推奨) を使用して、起動時に自動オープンを設定します。 ``` SQL> ALTER PLUGGABLE DATABASE ALL SAVE STATE; Pluggable database altered. ``` これは、Oracle に対し、PDB の現在のオープン状態を記憶し、CDB の起動時にその状態を復元するように指示します。保存された状態を確認します。 ``` SQL> SELECT con_name, instance_name, state FROM dba_pdb_saved_states; ``` PDB サービスがリスナーに登録されていることを確認します。 ``` lsnrctl services ``` 予想される出力には、CDB と各 PDB のサービスが表示されるはずです。サービスが表示されない場合。 ``` SQL> ALTER SYSTEM REGISTER; ``` 次に、`lsnrctl services` でもう一度確認します。 ### ステップ 9: RDS Custom オブジェクトを削除するこれは EC2 上のセルフマネージドデータベースになったため、RDS Custom 固有のユーザーとオブジェクトを削除する必要があります。クリーンアッププロセスは、非 CDB アーキテクチャとマルチテナントアーキテクチャで異なります。 **重要** RDS 固有のユーザーとテーブルスペースを削除する前に、これらのスキーマの下にアプリケーションオブジェクトが存在しないことを確認します。 ``` SQL> SELECT owner, object_type, COUNT(*) FROM dba_objects WHERE owner IN ('RDSADMIN', 'RDS_DATAGUARD') AND object_name NOT LIKE 'RDS%' AND object_name NOT LIKE 'SYS_%' GROUP BY owner, object_type; ``` アプリケーションオブジェクトが見つかった場合は、先に進む前に適切なアプリケーションスキーマに移行します。 **Example 非 CDB:** ``` SQL> DROP USER RDSADMIN CASCADE; SQL> DROP USER RDS_DATAGUARD CASCADE; SQL> DROP DIRECTORY OPATCH_INST_DIR; SQL> DROP DIRECTORY OPATCH_LOG_DIR; SQL> DROP DIRECTORY OPATCH_SCRIPT_DIR; SQL> DROP TABLESPACE RDSADMIN INCLUDING CONTENTS AND DATAFILES; -- Verify removal SQL> SELECT username FROM dba_users WHERE username LIKE '%RDS%'; ``` 正常な出力: `no rows selected` **マルチテナント:** マルチテナント環境では、RDS Custom はすべての PDB から参照可能な共通ユーザーを `CDB$ROOT` に作成します。`CDB$ROOT` からクリーンアップする必要があります。 ``` -- Connect to CDB$ROOT SQL> SHOW CON_NAME; -- Check for RDS-specific common users (including C## prefixed users) SQL> SELECT username, common, con_id FROM cdb_users WHERE username LIKE '%RDS%' OR username LIKE 'C##RDS%' ORDER BY username; -- Drop non-common users SQL> DROP USER RDSADMIN CASCADE; SQL> DROP USER RDS_DATAGUARD CASCADE; -- If any C## common users exist -- SQL> DROP USER C##RDSADMIN CASCADE ; -- Drop directories and tablespace SQL> DROP DIRECTORY OPATCH_INST_DIR; SQL> DROP DIRECTORY OPATCH_LOG_DIR; SQL> DROP DIRECTORY OPATCH_SCRIPT_DIR; SQL> DROP TABLESPACE RDSADMIN INCLUDING CONTENTS AND DATAFILES; -- Verify removal from CDB$ROOT SQL> SELECT username FROM dba_users WHERE username LIKE '%RDS%'; -- Verify removal from each PDB SQL> ALTER SESSION SET CONTAINER = {{}}; SQL> SELECT username FROM dba_users WHERE username LIKE '%RDS%'; ``` すべてのクエリで予想される出力: `no rows selected` ### ステップ 10: 自動起動を設定する `SPFILE` を作成します。 ``` SQL> CREATE SPFILE FROM PFILE='$ORACLE_HOME/dbs/initORCL.ora'; SQL> SHUTDOWN IMMEDIATE; SQL> STARTUP; ``` マルチテナントの場合、PDB が開いていることを確認します。 ``` SQL> ALTER PLUGGABLE DATABASE ALL OPEN; ``` `/etc/oratab` を編集します。 ``` ORCL:/u01/app/oracle/product/19.0.0/dbhome_1:Y ``` ### ステップ 11: 最終検証 **Example 非 CDB:** ``` SQL> SELECT name, open_mode, log_mode FROM v$database; SQL> SELECT SUM(bytes)/1024/1024/1024 AS size_gb FROM dba_data_files; SQL> SELECT COUNT(*) FROM dba_objects WHERE status = 'INVALID'; ``` **Example マルチテナント:** ``` SQL> SELECT name, open_mode, log_mode, cdb FROM v$database; SQL> SELECT con_id, name, open_mode FROM v$pdbs; SQL> SELECT SUM(bytes)/1024/1024/1024 AS total_size_gb FROM cdb_data_files; SQL> SELECT con_id, COUNT(*) FROM cdb_objects WHERE status = 'INVALID' GROUP BY con_id; ``` ``` Test application connectivity: # Non-CDB sqlplus {{}}/{{}}@{{}}:1521/ORCL # Multitenant (connect to PDB) sqlplus {{}}/{{}}@{{}}:1521/{{}} ``` **ステップ 12: RDS Custom オートメーションを再開する** ``` aws rds modify-db-instance \ --db-instance-identifier my-custom-instance \ --automation-mode full \ --region us-east-1 ``` ## オプション 2: Oracle Data Guard を使用した物理移行このセクションでは、Oracle Data Guard を使用して Oracle データベースを RDS Custom for Oracle から EC2 に移行する詳細な手順について説明します。この方法は、最小限のダウンタイムを必要とする移行に適しています。 ### Oracle Data Guard を使用するタイミング **次の場合に Oracle Data Guard を選択します。** + 最小限のダウンタイム (スイッチオーバーに数秒から数分) が必要 + 本番稼働用データベースまたはミッションクリティカルなデータベースを移行する場合 + カットオーバーの前に継続的な同期が必要 + 組み込みのフォールバック機能が必要 + 移行にコミットする前に、ターゲットデータベースをテストする必要がある ### Oracle Data Guard の概要 Oracle Data Guard は、プライマリデータベースから REDO ログを継続的に配布して適用することで、同期されたスタンバイデータベースを維持します。移行を完了する準備ができたら、最小限のダウンタイム (数秒から数分) で EC2 スタンバイをプライマリに昇格させるスイッチオーバーを実行します。マルチテナントデータベースの場合、Data Guard はすべての PDB を含む CDB 全体を自動的に保護します。任意の PDB によって生成された REDO はスタンバイに配布され、スタンバイの対応する PDB に適用されます。 ### Oracle Data Guard の移行ワークフロー **RDS Custom DB インスタンス (プライマリ) のステップ。** 1. Amazon RDS Custom オートメーションを一時停止する 1. データベースアーキテクチャを検証する (非 CDB または PDB を含む CDB) 1. プライマリデータベースがアーカイブログモードで実行され、`FORCE_LOGGING` が有効になっていることを確認する 1. パスワードファイルを作成する 1. プライマリデータベースの RMAN オンラインバックアップを実行する (またはアクティブ複製を使用する) 1. ソースデータベースからパラメータファイルを作成する 1. バックアップセット、パラメータファイル、パスワードファイルをターゲット EC2 インスタンスにコピーする **EC2 DB インスタンス (スタンバイ) のステップ:** 1. ソースから EC2 インスタンスにすべてのファイルをコピーする 1. パスワードファイルを EC2 インスタンスにコピーする 1. EC2 のパラメータファイルを編集する (アーキテクチャ固有) 1. パラメータファイルからサーバーパラメータファイルを作成する 1. スタンバイコントロールファイルとデータベースを復元する **Data Guard 設定のステップ:** 1. 両方のインスタンスで Oracle リスナーを設定する 1. 両方のインスタンスで tnsnames.ora を設定する 1. 両方のインスタンスで Oracle Data Guard ブローカーを起動する (オプションですが推奨) 1. Oracle Data Guard 設定を有効にする 1. EC2 スタンバイインスタンスで fal\_server と fal\_client を設定する 1. 両方のインスタンスでスタンバイ REDO ログファイルを設定する 1. スタンバイインスタンスを復旧する 1. 手動スイッチオーバーを実行する 1. データベースを (マルチテナントの場合は PDB も) 開く 1. PDB の自動オープンを設定する (マルチテナントのみ) 1. RDS Custom 固有のユーザーとオブジェクトを削除する 1. SPFILE を作成し、自動起動を設定する ### ステップ 1: Amazon RDS Custom オートメーションを一時停止する RDS Custom インスタンスのオートメーションモードを一時停止します。`--resume-full-automation-mode-minute` パラメータは、データベースのサイズと Data Guard の予想セットアップ時間に基づいて調整する必要があります。 ``` aws rds modify-db-instance \ --db-instance-identifier my-custom-instance \ --automation-mode all-paused \ --resume-full-automation-mode-minute 480 \ --region us-east-1 ``` オートメーションステータスを検証します。 ``` aws rds describe-db-instances \ --db-instance-identifier my-custom-instance \ --region us-east-1 \ --query 'DBInstances[0].AutomationMode' ``` 正常な出力: 「`all-paused`」 ### ステップ 2: アーカイブログモードと `FORCE_LOGGING` Oracle Data Guard では、プライマリデータベースがアーカイブログモードで、強制ログが有効になっている必要があります。 ``` sqlplus / as sysdba SQL> SELECT log_mode, force_logging FROM v$database; ``` 正常な出力: ``` LOG_MODE FORCE_LOGGING ------------ ------------- ARCHIVELOG YES ``` 強制ログ記録が有効になっていない場合は、以下を実行します。 ``` SQL> ALTER DATABASE FORCE LOGGING; ``` ### ステップ 3: パスワードとパラメータファイルを作成する `orapwd` を使用してパスワードファイルを作成します。AWS Secrets Manager から SYS パスワードを取得します。 ``` # Non-CDB $ORACLE_HOME/bin/orapwd file=/rdsdbdata/config/orapwORCL password={{}} entries=10 # Multitenant $ORACLE_HOME/bin/orapwd file=/rdsdbdata/config/orapwRDSCDB password={{}} entries=10 ``` ソースデータベースからパラメータファイルを作成します。 ``` sqlplus / as sysdba SQL> CREATE PFILE='/tmp/initORCL.ora' FROM SPFILE; -- Non-CDB SQL> CREATE PFILE='/tmp/initRDSCDB.ora' FROM SPFILE; -- Multitenant ``` ### ステップ 4: RMAN バックアップを実行するか、アクティブ複製を使用するスタンバイデータベースを作成するには、次の 2 つのオプションがあります。 #### オプション A: RMAN オンラインバックアップ (ほとんどのシナリオで推奨) バックアップディレクトリを作成し、データベースをバックアップします。 ``` mkdir -p /rdsdbdata/backup rman target / RMAN> run { backup as compressed backupset filesperset 2 format '/rdsdbdata/backup/db_%U' database; sql 'alter system archive log current'; backup as compressed backupset filesperset 50 format '/rdsdbdata/backup/arch_%U' archivelog all; } RMAN> backup current controlfile for standby format '/rdsdbdata/backup/standby.ctl'; ``` **注記** マルチテナントの場合、データベースキーワードは、すべての PDB を含む CDB 全体を自動的にバックアップします。 #### オプション B: アクティブ複製 (代替方法) バックアップステップをスキップし、RMAN アクティブ複製を使用してスタンバイをネットワーク経由で直接構築します。これにより、バックアップストレージやファイル転送が不要になります。TNS とリスナーを設定した後 (以下を参照)、以下を実行します。 ``` RMAN> DUPLICATE TARGET DATABASE FOR STANDBY FROM ACTIVE DATABASE DORECOVER; ``` このガイダンスでは、オプション A (バックアップベース) に焦点を当てていますが、オプション B も有効な代替手段です。 ### ステップ 5: EC2 を使用してファイルを転送する任意のファイル転送方法を選択します。このガイダンスでは、Amazon S3 を例として使用します。 **Amazon S3 の使用** **Example 非 CDB の場合:** ``` # Copy files to Amazon S3 from the RDS Custom instance aws s3 cp /rdsdbdata/backup s3://{{}}/ --recursive aws s3 cp /tmp/initORCL.ora s3://{{}}/ aws s3 cp /rdsdbdata/config/orapwORCL s3://{{}}/ # On EC2, download files aws s3 cp s3://{{}}/backup /u01/app/oracle/backup/ --recursive aws s3 cp s3://{{}}/initORCL.ora $ORACLE_HOME/dbs/ aws s3 cp s3://{{}}/orapwORCL $ORACLE_HOME/dbs/ ``` **Example マルチテナントの場合:** ``` # Copy files to Amazon S3 from the RDS Custom instance aws s3 cp /rdsdbdata/backup s3://{{}}/ --recursive aws s3 cp /tmp/initRDSCDB.ora s3://{{}}/ aws s3 cp /rdsdbdata/config/orapwRDSCDB s3://{{}}/ # On EC2, download and rename files to use ORCL naming aws s3 cp s3://{{}}/backup /u01/app/oracle/backup/ --recursive aws s3 cp s3://{{}}/initRDSCDB.ora $ORACLE_HOME/dbs/initORCL.ora aws s3 cp s3://{{}}/orapwRDSCDB $ORACLE_HOME/dbs/orapwORCL ``` ### ステップ 6: EC2 でパラメータファイルを編集する EC2 インスタンスで `$ORACLE_HOME/dbs/initORCL.ora` を編集し、以下の重要な変更を加えます。 1. **データベース名の更新**: マルチテナントの場合は、`RDSCDB` のすべての出現箇所を `ORCL` に変更する 1. **db\_unique\_name の変更**: `ORCL_A` (または `RDSCDB_A`) から `ORCL_B` に変更 1. **RDS Custom パスを EC2 パスに変換する**: `/rdsdbdata/` を `/u01/app/oracle/` に置き換える 1. ****RDS Custom 固有のパラメータを削除する**** + `dg_broker_config_file1` および `dg_broker_config_file2` (存在する場合) + `standby_file_management` (存在する場合) + `spfile` (後で新しい `SPFILE` を作成します) + スタンバイ送信先を指す `log_archive_dest` パラメータ 1. EC2 インスタンスのサイズに基づいて**メモリパラメータを調整する** (オプションですが推奨) **パスマッピング:** **非 CDB:** + `/rdsdbdata/db/ORCL_A/datafile/` → `/u01/app/oracle/oradata/ORCL/datafile/` + `/rdsdbdata/db/ORCL_A/controlfile/` → `/u01/app/oracle/oradata/ORCL/controlfile/` + `/rdsdbdata/db/ORCL_A/onlinelog/` → `/u01/app/oracle/oradata/ORCL/onlinelog/` + `/rdsdbdata/admin/ORCL/adump` → `/u01/app/oracle/admin/ORCL/adump` **マルチテナント:** + `/rdsdbdata/db/cdb/RDSCDB/datafile/` → `/u01/app/oracle/oradata/ORCL/cdb/datafile/` + `/rdsdbdata/db/cdb/pdbseed/` → `/u01/app/oracle/oradata/ORCL/pdbseed/datafile/` + `/rdsdbdata/db/pdb/RDSCDB_A/` → `/u01/app/oracle/oradata/ORCL/pdb/datafile/` + `/rdsdbdata/db/cdb/RDSCDB_A/controlfile/` → `/u01/app/oracle/oradata/ORCL/controlfile/` + `/rdsdbdata/admin/RDSCDB/adump` → `/u01/app/oracle/admin/ORCL/adump` **重要**: マルチテナントの場合は、パラメータファイルに `enable_pluggable_database`=`TRUE` が存在することを確認します。 ### ステップ 7: `SPFILE` を作成して、スタンバイデータベースを復元するインスタンスを起動して、SPFILE を作成します。 ``` sqlplus / as sysdba SQL> STARTUP NOMOUNT PFILE='$ORACLE_HOME/dbs/initORCL.ora'; SQL> CREATE SPFILE='/u01/app/oracle/admin/ORCL/pfile/spfileORCL.ora' FROM PFILE='$ORACLE_HOME/dbs/initORCL.ora'; SQL> SHUTDOWN IMMEDIATE; ``` シンボリックリンクを作成します。 ``` ln -sfn /u01/app/oracle/admin/ORCL/pfile/spfileORCL.ora $ORACLE_HOME/dbs/spfileORCL.ora ``` インスタンスを起動して復元します。 ``` SQL> STARTUP NOMOUNT; rman target / ``` バックアップファイルがソースとは異なるパスにある場合は、まずそれらをカタログ化します。 ``` RMAN> catalog start with '/u01/app/oracle/backup/'; ``` スタンバイコントロールファイルを復元してマウントします。 ``` RMAN> restore standby controlfile from '/u01/app/oracle/backup/standby.ctl'; RMAN> alter database mount; ``` データファイルのパスが異なる場合 (ASM の使用など) は、`SET NEWNAME` を使用します。 ``` RMAN> run { set newname for database to '+DATA/%b'; restore database; switch datafile all; } ``` それ以外の場合は、単純に復元します。 ``` RMAN> restore database; ``` データベースを使用可能な最後のシーケンスに復旧します。 ``` RMAN> list backup of archivelog all; RMAN> recover database until sequence ; ``` **注記** マルチテナントの場合、RMAN はすべての PDB を自動的に復元および復旧します。各 PDB を個別に復元する必要はありません。 ### ステップ 8: TNS とリスナーを設定する両方のインスタンスで、`tnsnames.ora` に TNS エントリをに追加します。 **Example 非 CDB:** ``` ORCL_A = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = {{}})(PORT = 1521)) (CONNECT_DATA = (SID = ORCL))) ORCL_B = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = {{}})(PORT = 1521)) (CONNECT_DATA = (SID = ORCL))) ``` **Example マルチテナント:** ``` RDSCDB_A = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = {{}})(PORT = 1521)) (CONNECT_DATA = (SID = RDSCDB))) ORCL_B = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = {{}})(PORT = 1521)) (CONNECT_DATA = (SID = ORCL))) ``` 両方のインスタンスでリスナーを設定します。RDS Custom では、`listener.ora` に追加します。 **Example 非 CDB の場合:** ``` SID_LIST_L_ORCL_DG=(SID_LIST = (SID_DESC = (SID_NAME = ORCL)(GLOBAL_DBNAME = ORCL) (ORACLE_HOME = /rdsdbbin/oracle.19.custom.r1.EE.1))) L_ORCL_DG=(DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(PORT = 1521)(HOST = {{}}))) ``` **Example マルチテナントの場合:** ``` SID_LIST_L_RDSCDB_DG=(SID_LIST = (SID_DESC = (SID_NAME = RDSCDB)(GLOBAL_DBNAME = RDSCDB) (ORACLE_HOME = /rdsdbbin/oracle.19.custom.r1.EE-CDB.1))) L_RDSCDB_DG=(DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(PORT = 1521)(HOST = {{}}))) ``` リスナーを起動します。 ``` $ORACLE_HOME/bin/lsnrctl start L_ORCL_DG # or L_RDSCDB_DG for multitenant ``` EC2 で、`$ORACLE_HOME/network/admin/listener.ora` を作成します。 ``` SID_LIST_L_ORCL_DG=(SID_LIST = (SID_DESC = (SID_NAME = ORCL)(GLOBAL_DBNAME = ORCL) (ORACLE_HOME = /u01/app/oracle/product/19.0.0/dbhome_1))) L_ORCL_DG=(DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(PORT = 1521)(HOST = {{}}))) ``` リスナーを起動します。 ``` $ORACLE_HOME/bin/lsnrctl start L_ORCL_DG ``` **注記** 必要に応じて RDS Custom で既存のリスナーを使用できますが、別の Data Guard リスナーを作成すると、より優れた分離性が得られます。 **重要** `tnsping` または `listener` 接続が失敗する場合、EC2 の `iptables` ルールを確認します。多くの EC2 Linux インスタンスには、ポート 1521 をブロックするデフォルトの `iptables` ルールがあります。ルールを追加します。`sudo iptables -I INPUT 5 -p tcp --dport 1521 -j ACCEPT` ### ステップ 9: Data Guard ブローカーと設定を有効にする両方のインスタンスで、Data Guard ブローカーを有効にします。 ``` sqlplus / as sysdba SQL> ALTER SYSTEM SET dg_broker_start=true; ``` RDS Custom プライマリで、Data Guard ブローカーに接続し、設定を作成します。 ``` dgmgrl / ``` **Example 非 CDB の場合:** ``` DGMGRL> CREATE CONFIGURATION my_dg_config AS PRIMARY DATABASE IS ORCL_A CONNECT IDENTIFIER IS ORCL_A; DGMGRL> ADD DATABASE ORCL_B AS CONNECT IDENTIFIER IS ORCL_B MAINTAINED AS PHYSICAL; ``` **Example マルチテナントの場合:** ``` DGMGRL> CREATE CONFIGURATION my_dg_config AS PRIMARY DATABASE IS RDSCDB_A CONNECT IDENTIFIER IS RDSCDB_A; DGMGRL> ADD DATABASE ORCL_B AS CONNECT IDENTIFIER IS ORCL_B MAINTAINED AS PHYSICAL; ``` 静的接続識別子を設定し、以下を有効にします。 **Example 非 CDB の場合:** ``` DGMGRL> edit database orcl_a set property StaticConnectIdentifier='(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(PORT=1521)(HOST=))(CONNECT_DATA=(SID=ORCL)(SERVER=DEDICATED)))'; DGMGRL> edit database orcl_b set property StaticConnectIdentifier='(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(PORT=1521)(HOST={{}}))(CONNECT_DATA=(SID=ORCL)(SERVER=DEDICATED)))'; DGMGRL> ENABLE CONFIGURATION; ``` **Example マルチテナントの場合:** ``` DGMGRL> edit database rdscdb_a set property StaticConnectIdentifier='(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(PORT=1521)(HOST=))(CONNECT_DATA=(SID=RDSCDB)(SERVER=DEDICATED)))'; DGMGRL> edit database orcl_b set property StaticConnectIdentifier='(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(PORT=1521)(HOST={{}}))(CONNECT_DATA=(SID=ORCL)(SERVER=DEDICATED)))'; DGMGRL> ENABLE CONFIGURATION; ``` **注記** Data Guard ブローカーはオプションですが、管理を容易にするために推奨されます。簡単な移行では、ブローカーなしで Data Guard を手動で設定できます。 **注記** CDB に対して Data Guard を有効にすると、すべての PDB が自動的に保護されます。任意の PDB によって生成された REDO はスタンバイに配布され、スタンバイの対応する PDB に適用されます。 ### ステップ 10: スタンバイ REDO ログを設定し、復旧を開始する EC2 スタンバイインスタンスで、スタンバイ REDO ログファイル (n\+1、n はオンライン REDO ロググループの数) を追加します。 ``` ALTER DATABASE ADD STANDBY LOGFILE ('slog1.rdo') SIZE 128M; ALTER DATABASE ADD STANDBY LOGFILE ('slog2.rdo') SIZE 128M; ALTER DATABASE ADD STANDBY LOGFILE ('slog3.rdo') SIZE 128M; ALTER DATABASE ADD STANDBY LOGFILE ('slog4.rdo') SIZE 128M; ALTER DATABASE ADD STANDBY LOGFILE ('slog5.rdo') SIZE 128M; ``` **注記** マルチテナントの場合、スタンバイ REDO ログは CDB レベルで作成され、すべての PDB で共有されます。スタンバイで FAL パラメータを設定します。 **Example 非 CDB の場合:** ``` SQL> alter system set fal_server = 'ORCL_A'; SQL> alter system set fal_client = 'ORCL_B'; ``` **Example マルチテナントの場合:** ``` SQL> alter system set fal_server = 'RDSCDB_A'; SQL> alter system set fal_client = 'ORCL_B'; ``` マネージドリカバリを開始します。 ``` SQL> recover managed standby database disconnect from session; ``` 適用遅延をモニタリングします。 ``` SQL> SELECT name, value FROM v$dataguard_stats WHERE name = 'apply lag'; ``` **Data Guard 同期の詳細なモニタリングと管理:** Data Guard のモニタリングは、移行を成功させるために不可欠です。包括的なモニタリング手法は次のとおりです。 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 の合計 1. **アーカイブログの配布をモニタリングします。** プライマリ (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; ``` 1. **マネージドリカバリプロセスをモニタリングします。** ``` -- 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; ``` 1. **マルチテナントの 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; ``` 1. **スタンバイ 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'; ``` 1. **同期の完了を見積もりします。** 適用レートに基づいて残り時間を計算します。 ``` -- 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; ``` #### Data Guard の同期に関する一般的な問題: ##### 問題 1: 適用遅延が大きい症状: ``` SQL> SELECT name, value FROM v$dataguard_stats WHERE name = 'apply lag'; NAME VALUE -------------------------------- ----- apply lag +00 01:30:00 ``` 原因と解決策: + **スタンバイ時の CPU/IO が不十分**: EC2 インスタンスタイプをアップグレードするか、EBS IOPS を増やします + **ネットワーク帯域幅の制限**: 拡張ネットワーキングまたはより高い帯域幅のインスタンスタイプを使用します + **トランザクションレートが高い複数の PDB**: REDO 適用並列処理を増やすことを検討します (Active Data Guard ライセンスが必要) ``` -- Increase apply parallelism (requires 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; ``` ##### 問題 2: アーカイブログのギャップ症状: ``` SQL> SELECT * FROM v$archive_gap; THREAD# LOW_SEQUENCE# HIGH_SEQUENCE# ------- ------------- -------------- 1 1234 1240 ``` 解決策: ``` -- FAL (Fetch Archive Log) will automatically fetch missing logs -- Verify FAL parameters are set correctly SQL> SHOW PARAMETER fal_server SQL> SHOW PARAMETER fal_client -- Manually register missing archive logs if needed -- On primary, check if logs still exist SQL> SELECT name FROM v$archived_log WHERE sequence# BETWEEN 1234 AND 1240; -- If logs are missing on primary, you may need to rebuild the standby ``` ##### 問題 3: REDO トランスポートの失敗症状: ``` SQL> SELECT dest_id, status, error FROM v$archive_dest WHERE dest_id = 2; DEST_ID STATUS ERROR ------- --------- ---------------------------------------- 2 ERROR ORA-16191: Primary log shipping client not logged on standby ``` 解決策: ``` -- Check network connectivity -- Verify TNS configuration -- Check listener status on standby -- Restart log transport SQL> ALTER SYSTEM SET log_archive_dest_state_2 = 'DEFER'; SQL> ALTER SYSTEM SET log_archive_dest_state_2 = 'ENABLE'; ``` ##### 問題 4: マネージドリカバリが REDO を適用しない症状: ``` SQL> SELECT process, status FROM v$managed_standby WHERE process = 'MRP0'; PROCESS STATUS --------- ------------ MRP0 WAIT_FOR_LOG ``` 解決策: ``` # Check if archive logs are arriving ls -ltr /u01/app/oracle/oradata/ORCL/arch/ # Check alert log for errors tail -100 $ORACLE_BASE/diag/rdbms/orcl_b/ORCL/trace/alert_ORCL.log # Restart managed recovery sqlplus / as sysdba SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL; SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION; ``` **マルチテナントの場合**、スタンバイの各 PDB のステータスを確認することもできます。 ``` SQL> SELECT con_id, name, open_mode, restricted FROM v$pdbs; ``` 予想される出力 (スタンバイで `MOUNTED` 状態の PDB): ``` CON_ID NAME OPEN_MODE RES ---------- ------------------------------ ---------- --- 2 PDB$SEED MOUNTED 3 ORCLDB MOUNTED ``` **注記** 物理スタンバイでは、PDB はマネージドリカバリ中も `MOUNTED` 状態のままです。 ### ステップ 11: スイッチオーバーを実行するスタンバイが完全に同期され、準備が整ったことを確認したら、スイッチオーバーを実行します。マルチテナントの場合、CDB 全体 (すべての PDB) が RDS Custom プライマリから EC2 スタンバイにスイッチオーバーします。 RDS Custom プライマリインスタンスで、Data Guard ブローカーに接続し、両方のデータベースのスイッチオーバーの準備が整っていることを確認します。 **Example 非 CDB の場合:** ``` DGMGRL> VALIDATE DATABASE ORCL_A; DGMGRL> VALIDATE DATABASE ORCL_B; ``` **Example マルチテナントの場合:** ``` DGMGRL> VALIDATE DATABASE RDSCDB_A; DGMGRL> VALIDATE DATABASE ORCL_B; ``` どちらも `Ready for Switchover: Yes` と表示されるはずです。 RDS Custom プライマリから EC2 スタンバイに切り替えます。 ``` DGMGRL> SWITCHOVER TO ORCL_B; ``` スイッチオーバーが成功したことを確認します。 ``` DGMGRL> SHOW CONFIGURATION VERBOSE; ``` EC2 インスタンス (`ORCL_B`) がプライマリデータベースになり、RDS Custom インスタンスが物理スタンバイになりました。 ### ステップ 12: PDB を開く (マルチテナントのみ) スイッチオーバー後、EC2 の CDB は READ WRITE モードでオープンになりますが、すべての PDB は MOUNTED 状態です。手動で開く必要があります。 EC2 の新しいプライマリに接続します。 ``` sqlplus / as sysdba SQL> SELECT name, open_mode, database_role, cdb FROM v$database; ``` 正常な出力: ``` NAME OPEN_MODE DATABASE_ROLE CDB --------- -------------------- ---------------- --- ORCL READ WRITE PRIMARY YES ``` 現在の PDB ステータスを確認します。 ``` SQL> SELECT con_id, name, open_mode, restricted FROM v$pdbs; ``` 予想される出力 (`MOUNTED` 状態の PBD - `ORCLDB` という名前の PDB が 1 つある例): ``` CON_ID NAME OPEN_MODE RES ---------- ------------------------------ ---------- --- 2 PDB$SEED READ ONLY NO 3 ORCLDB MOUNTED ``` すべての PDB を開きます。 ``` SQL> ALTER PLUGGABLE DATABASE ALL OPEN; ``` プラガブルデータベースが変更されました。すべての PDB が `READ WRITE` モードでオープンされていることを確認します。 ``` SQL> SELECT con_id, name, open_mode, restricted FROM v$pdbs; ``` 正常な出力: ``` CON_ID NAME OPEN_MODE RES ---------- ------------------------------ ---------- --- 2 PDB$SEED READ ONLY NO 3 ORCLDB READ WRITE NO ``` ### ステップ 13: 起動時に PDB を自動オープンするように設定する (マルチテナントのみ) CDB の起動時に PDB の自動オープンを設定するには、状態保存メソッド (Oracle 19c に推奨) を使用します。 ``` SQL> ALTER PLUGGABLE DATABASE ALL SAVE STATE; Pluggable database altered. ``` 保存された状態を確認します。 ``` SQL> SELECT con_name, instance_name, state FROM dba_pdb_saved_states; ``` PDB サービスがリスナーに登録されていることを確認します。 ``` lsnrctl services ``` 予想される出力には、CDB と各 PDB のサービスが表示されるはずです。サービスが表示されない場合: ``` SQL> ALTER SYSTEM REGISTER; ``` 次に、`lsnrctl services` でもう一度確認します。 ### ステップ 14: RDS Custom オブジェクトを削除するこれは EC2 上のセルフマネージドデータベースになったため、RDS Custom 固有のユーザーとオブジェクトを削除する必要があります。クリーンアッププロセスは、非 CDB アーキテクチャとマルチテナントアーキテクチャでわずかに異なります。 **重要** RDS 固有のユーザーとテーブルスペースを削除する前に、これらのスキーマの下にアプリケーションオブジェクトが存在しないことを確認します。 ``` SQL> SELECT owner, object_type, COUNT(*) FROM dba_objects WHERE owner IN ('RDSADMIN', 'RDS_DATAGUARD') AND object_name NOT LIKE 'RDS%' AND object_name NOT LIKE 'SYS_%' GROUP BY owner, object_type; ``` アプリケーションオブジェクトが見つかった場合は、先に進む前に適切なアプリケーションスキーマに移行します。 **非 CDB クリーンアップ:** ``` sqlplus / as sysdba -- Drop RDS-specific users SQL> DROP USER RDSADMIN CASCADE; SQL> DROP USER RDS_DATAGUARD CASCADE; -- Drop RDS-specific directories SQL> DROP DIRECTORY OPATCH_INST_DIR; SQL> DROP DIRECTORY OPATCH_LOG_DIR; SQL> DROP DIRECTORY OPATCH_SCRIPT_DIR; -- Drop the RDSADMIN tablespace SQL> DROP TABLESPACE RDSADMIN INCLUDING CONTENTS AND DATAFILES; -- Verify removal SQL> SELECT username FROM dba_users WHERE username LIKE '%RDS%'; ``` 正常な出力: `no rows selected` **マルチテナントクリーンアップ:** マルチテナント環境では、RDS Custom はすべての PDB から参照可能な共通ユーザーを `CDB$ROOT` に作成します。`CDB$ROOT` からクリーンアップする必要があります。 ``` sqlplus / as sysdba -- Verify you are in CDB$ROOT SQL> SHOW CON_NAME; -- Check for RDS-specific common users (including C## prefixed users) SQL> SELECT username, common, con_id FROM cdb_users WHERE username LIKE 'RDS%' OR username LIKE 'C##RDS%' ORDER BY username; -- Drop non-common users SQL> DROP USER RDSADMIN CASCADE; SQL> DROP USER RDS_DATAGUARD CASCADE; -- If any C## common users exist -- Example (adjust based on your findings): -- SQL> DROP USER C##RDS_DATAGUARD CASCADE; -- Drop RDS-specific directories SQL> DROP DIRECTORY OPATCH_INST_DIR; SQL> DROP DIRECTORY OPATCH_LOG_DIR; SQL> DROP DIRECTORY OPATCH_SCRIPT_DIR; -- Drop the RDSADMIN tablespace SQL> DROP TABLESPACE RDSADMIN INCLUDING CONTENTS AND DATAFILES; -- Verify removal from CDB$ROOT SQL> SELECT username FROM dba_users WHERE username LIKE '%RDS%'; -- Verify removal from each PDB (example with one PDB named ORCLDB) SQL> ALTER SESSION SET CONTAINER = ORCLDB; SQL> SELECT username FROM dba_users WHERE username LIKE '%RDS%'; ``` すべてのクエリで予想される出力: no rows selected ### ステップ 15: 自動起動を設定する `SPFILE` が使用されていることを確認します。 ``` sqlplus / as sysdba SQL> SHOW PARAMETER spfile; ``` `spfile` パスが正しい場合、アクションは必要ありません。正しくない場合は、作成します。 ``` SQL> CREATE SPFILE FROM MEMORY; ``` データベースを再起動します。 ``` SQL> SHUTDOWN IMMEDIATE; SQL> STARTUP; ``` マルチテナントの場合は、すべての PDB を開きます (以前に状態を保存した場合は自動オープンするはずです)。 ``` SQL> SELECT con_id, name, open_mode FROM v$pdbs; ``` PDB が開いていない場合は、手動で開きます。 ``` SQL> ALTER PLUGGABLE DATABASE ALL OPEN; ``` `/etc/oratab` を編集します。 ``` vi /etc/oratab ``` `ORCL` の行を `N` から `Y` に変更します。 ``` ORCL:/u01/app/oracle/product/19.0.0/dbhome_1:Y ``` ### ステップ 16: 最終検証移行されたデータベースに対して包括的な検証を実行します。 **Example 非 CDB の場合:** ``` sqlplus / as sysdba -- Verify database role and status SQL> SELECT name, open_mode, log_mode, database_role FROM v$database; -- Check database size SQL> SELECT SUM(bytes)/1024/1024/1024 AS size_gb FROM dba_data_files; -- Verify all objects are valid SQL> SELECT owner, object_type, COUNT(*) FROM dba_objects WHERE status = 'INVALID' GROUP BY owner, object_type; -- Verify data files SQL> SELECT name, status FROM v$datafile; -- Test application connectivity SQL> SELECT username, machine, program FROM v$session WHERE username IS NOT NULL; ``` **Example マルチテナントの場合:** ``` sqlplus / as sysdba -- Verify CDB status SQL> SELECT name, open_mode, log_mode, cdb, database_role FROM v$database; -- Verify all PDBs are open SQL> SELECT con_id, name, open_mode, restricted FROM v$pdbs; -- Check total CDB size SQL> SELECT SUM(bytes)/1024/1024/1024 AS total_size_gb FROM cdb_data_files; -- Check 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; -- Verify all objects are valid across all PDBs SQL> SELECT con_id, owner, object_type, COUNT(*) FROM cdb_objects WHERE status = 'INVALID' GROUP BY con_id, owner, object_type; -- Verify PDB services are registered SQL> SELECT name FROM v$services ORDER BY name; Test application connectivity: # Non-CDB sqlplus {{}}/{{}}@{{}}:1521/ORCL # Multitenant (connect to PDB) sqlplus {{}}/{{}}@{{:1521/{{}} ``` アプリケーションの接続性をテストします。 ``` # Non-CDB sqlplus {{}}/{{}}@{{}}:1521/ORCL # Multitenant (connect to PDB) sqlplus {{}}/{{}}@{{}}:1521/{{}} ``` ### ステップ 17: バックアップファイルをクリーンアップする検証に成功したら、バックアップファイルを削除し、別の EBS ボリュームを使用している場合はバックアップボリュームをデタッチします。 ``` rm -rf /u01/app/oracle/backup/* ``` バックアップに別の EBS ボリュームを使用する場合: ``` # Unmount the volume sudo umount /u01/app/oracle/backup # Detach and delete the EBS volume from AWS Console or CLI aws ec2 detach-volume --volume-id {{}} aws ec2 delete-volume --volume-id {{}} ``` ### ステップ 18: RDS Custom オートメーションを再開する検証期間中に RDS Custom インスタンスをフォールバックとして実行し続ける場合は、オートメーションを再開します。 ``` aws rds modify-db-instance \ --db-instance-identifier my-custom-instance \ --automation-mode full \ --region us-east-1 ``` ## 一般的な問題のトラブルシューティングこのセクションでは、RMAN 複製アプローチと Oracle Data Guard アプローチの両方で、移行中に発生する可能性がある一般的な問題について説明します。対象となるのは、非 CDB アーキテクチャとマルチテナントアーキテクチャの両方です。 ### ORA-09925: 監査証跡ファイルを作成できません **原因:** `audit_file_dest` パラメータで指定された監査ディレクトリがターゲット EC2 インスタンスに存在しません。 **解決策:** 監査ディレクトリが存在し、適切なアクセス許可があることを確認します。 ``` mkdir -p /u01/app/oracle/admin/ORCL/adump chown -R oracle:oinstall /u01/app/oracle/admin/ORCL chmod -R 755 /u01/app/oracle/admin/ORCL ``` ### ORA-01261: パラメータ `db_create_file_dest` の送信先文字列を変換できません **原因:** `db_create_file_dest` パラメータで指定されたディレクトリがターゲット EC2 インスタンスに存在しません。 **解決策:** 非 CDB の場合: ``` mkdir -p /u01/app/oracle/oradata/ORCL chown -R oracle:oinstall /u01/app/oracle/oradata/ORCL chmod -R 755 /u01/app/oracle/oradata/ORCL ``` マルチテナントの場合: ``` mkdir -p /u01/app/oracle/oradata/ORCL/pdb/datafile chown -R oracle:oinstall /u01/app/oracle/oradata/ORCL chmod -R 755 /u01/app/oracle/oradata/ORCL ``` ### ORA-01804: タイムゾーン情報の初期化に失敗しました RDS ソースのタイムゾーンバージョンが EC2 $ORACLE\_HOME にインストールされているタイムゾーンバージョンよりも高い場合、`RDSADMIN` ユーザーを削除するときにこのエラーが発生する可能性があります。 **解決策:** 1. タイムゾーンのバージョンを確認します。 ``` SELECT * FROM v$timezone_file; SELECT PROPERTY_NAME, PROPERTY_VALUE FROM database_properties WHERE PROPERTY_NAME LIKE '%DST%'; ``` 1. 回避策として、$ORACLE\_HOME で使用できるものと一致するようにタイムゾーンファイル環境変数を設定します。 ``` ls $ORACLE_HOME/oracore/zoneinfo/timezlrg_*.dat export ORA_TZFILE=$ORACLE_HOME/oracore/zoneinfo/timezone_40.dat ``` インストールで使用可能なバージョンと一致するように数値を調整します。 1. 削除を再試行します。 ``` sqlplus / as sysdba SQL> DROP USER RDSADMIN CASCADE; ``` ### RU 間の移行の問題 (異なるリリースアップデート) **原因:** ターゲット EC2 インスタンスの Oracle Release Update (RU) またはワンオフパッチがソース RDS Custom インスタンスとは異なるため、移行中または移行後に互換性エラーが発生します。 **一般的なエラー。** + REDO 適用中の ORA-00600 内部エラー (Data Guard) + ORA-39700 データベースは `UPGRADE` オプション付きで開く必要があります + 移行後のディクショナリの不整合 + `DBA_REGISTRY` または `DBA_OBJECTS` の無効なオブジェクト **解決策:** **ベストプラクティス - RU バージョンとワンオフパッチを正確に一致させます。** 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; ``` 1. $ORACLE\_HOME パッチレベルを確認します。 ``` # On both instances $ORACLE_HOME/OPatch/opatch lsinventory ``` 1. バージョンが一致しない場合は、必要に応じてパッチを適用またはロールバックして移行前に調整します。 1. RU が一致しない状態で進める必要がある場合は、移行後に datapatch を実行します。 ``` cd $ORACLE_HOME/OPatch ./datapatch -verbose ``` 1. 無効なオブジェクトを確認し、再コンパイルします。 ``` SQL> @?/rdbms/admin/utlrp.sql SQL> SELECT owner, object_type, COUNT(*) FROM dba_objects WHERE status = 'INVALID' GROUP BY owner, object_type; ``` ### ネットワーク接続の問題 **原因:** セキュリティグループ、ネットワーク ACL、または `iptables` が Oracle リスナーポートをブロックしている。 **解決策:** 1. セキュリティグループがポートを双方向に許可することを確認します 1. EC2 の iptables を確認します。 ``` sudo iptables -L INPUT -n -v ``` 1. 必要に応じてルールを追加します。 ``` # 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 {{}} --dport 1521 -j ACCEPT # Save rules permanently sudo service iptables save ``` 1. 接続をテストします。 ``` telnet {{}} 1521 tnsping DB_SOURCE tnsping DB_TARGET ``` ### 移行後に PDB が開きません (マルチテナントのみ) **原因:** これは想定される動作です。RMAN 複製または Data Guard スイッチオーバー後、CDB はオープンですが、PDB は `MOUNTED` 状態です。 **解決策:** 手動で開きます。 ``` SQL> ALTER PLUGGABLE DATABASE ALL OPEN; ``` 特定の PDB が開いていない場合は、アラートログにエラーがないか確認します。 ``` tail -100 $ORACLE_BASE/diag/rdbms/orcl/ORCL/trace/alert_ORCL.log ``` 一般的な原因には、データファイルの欠落やパスマッピングの問題などがあります。 ### PDB データファイルが見つからないか、パスが一致しません (マルチテナントのみ) **原因:** 移行において、特に OMF ベースの PDB データファイルについて、すべてのソースパスが正しくマッピングされませんでした。 **解決策:** 1. 欠落しているデータファイルを確認します。 ``` SQL> SELECT name, status FROM v$datafile WHERE status != 'ONLINE'; ``` 1. ファイルが間違ったディレクトリに配置された場合は、コントロールファイル内で名前を変更します。 ``` SQL> ALTER DATABASE RENAME FILE '/wrong/path/datafile.dbf' TO '/correct/path/datafile.dbf'; ``` 1. これを防ぐには、パラメータファイルを設定する前に、必ず `SELECT con_id, name FROM v$datafile ORDER BY con_id;` を使用してソースデータファイルのパスを確認してください。 ### PDB サービスがリスナーに登録されていない (マルチテナントのみ) **原因:** PDB を開いた後、リスナーが PDB サービスを認識しません。 **解決策:** 1. サービス登録を強制します。 ``` SQL> ALTER SYSTEM REGISTER; ``` 1. サービスがまだ表示されない場合は、`local_listener` パラメータを確認します。 ``` SQL> SHOW PARAMETER local_listener; ``` 正しいリスナーアドレスを指していることを確認します。必要に応じて更新します。 ``` SQL> ALTER SYSTEM SET local_listener='(ADDRESS=(PROTOCOL=TCP)(HOST={{}})(PORT=1521))'; SQL> ALTER SYSTEM REGISTER; ``` 1. 以下を使用して検証します。 ``` lsnrctl services ``` ### CDB 再起動後に PDB 自動で開かない (マルチテナントのみ) **原因:** PDB 状態保存が設定されていません。 **解決策:** PDB 状態保存が設定されていることを確認します。 ``` SQL> SELECT con_name, instance_name, state FROM dba_pdb_saved_states; ``` 行が返されない場合は、状態を保存します。 ``` SQL> ALTER PLUGGABLE DATABASE ALL OPEN; SQL> ALTER PLUGGABLE DATABASE ALL SAVE STATE; ``` ### Data Guard REDO トランスポートが機能しない **原因:** ネットワーク接続の問題、誤った TNS 設定、または FAL パラメータが設定されていません。 **解決策:** 1. スタンバイが MOUNT モードであることを確認します。 ``` SQL> SELECT status FROM v$instance; ``` 1. スタンバイで fal\_server と fal\_client が正しく設定されていることを確認します。 ``` SQL> SHOW PARAMETER fal_server SQL> SHOW PARAMETER fal_client ``` 1. ネットワーク接続を検証します。 ``` tnsping ORCL_A # or RDSCDB_A for multitenant ``` 1. プライマリの log\_archive\_dest\_2 パラメータがスタンバイを指していることを確認します (ブローカーを使用せずに手動で設定した場合)。 **Data Guard 適用遅延が複数の PDB で増加します (マルチテナントのみ)** **原因:** 複数の PDB を含む CDB の場合、すべてのコンテナにわたる変更量が多いため、REDO の適用が遅くなる可能性があります。 **解決策:** 1. 適用レートを確認します。 ``` SQL> SELECT name, value, unit FROM v$dataguard_stats WHERE name IN ('apply rate', 'apply lag'); ``` 1. 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; ``` 1. スタンバイインスタンスにリソース制約 (CPU、I/O) がないことを確認します。 **RMAN アーカイブログのバックアップが ORA-19625 で失敗しました** **原因:** RDS Custom オートメーションは古いアーカイブログをディスクから消去しましたが、RMAN のコントロールファイルにはまだそれらのレコードがあります。 **解決策:** 1. 古いアーカイブログエントリをクロスチェックしてクリーンアップします。 ``` RMAN> CROSSCHECK ARCHIVELOG ALL; RMAN> DELETE NOPROMPT EXPIRED ARCHIVELOG ALL; ``` 1. アーカイブログバックアップのみを再実行します。 ``` RMAN> RUN { SQL 'ALTER SYSTEM ARCHIVE LOG CURRENT'; BACKUP AS COMPRESSED BACKUPSET FILESPERSET 50 FORMAT '/rdsdbdata/backup/arch_%U' ARCHIVELOG ALL; } ``` ### マルチテナントで共通ユーザーの削除が失敗する (マルチテナントのみ) **原因:** 共通ユーザー (C\#\# のプレフィックス) は `CONTAINER=ALL` 句を使用して削除する必要があります。 **解決策:** ``` -- For common users SQL> DROP USER C##RDS_DATAGUARD CASCADE CONTAINER=ALL; -- For non-common users in CDB$ROOT SQL> DROP USER RDSADMIN CASCADE; ``` `CDB$ROOT` に接続していることを確認します。 ``` SQL> SHOW CON_NAME; ``` ## 移行後のタスク移行が成功したら、これらの追加タスクを完了して、EC2 上のセルフマネージド Oracle データベースの本番稼働準備が整っていることを確認します。 **アプリケーション接続文字列を更新する** **非 CDB の場合:** + アプリケーションを新しい EC2 インスタンスエンドポイントにポイントする + EC2 インスタンスの IP またはホスト名を使用するように接続文字列を更新する + アプリケーションのすべての機能を徹底的にテストする **マルチテナントの場合:** + アプリケーションを新しい EC2 インスタンス PDB サービス名 (ORCLDB や特定の PDB 名など) にポイントする + アプリケーションが CDB ではなく正しい PDB に接続されていることを確認する + PDB サービス名を使用するように接続文字列を更新する + 各 PDB のすべてのアプリケーション機能をテストする接続文字列の例: ``` # Non-CDB jdbc:oracle:thin:@{{}}:1521/ORCL # Multitenant (connect to PDB) jdbc:oracle:thin:@{{}}:1521/ORCLDB ``` **バックアップ戦略を設定する** セルフマネージドデータベースの包括的なバックアップ戦略を設定します。 **RMAN バックアップ:** + 完全、増分、アーカイブログのバックアップ用に自動 RMAN バックアップスクリプトを設定する + 目標復旧時点 (RPO) に基づいてバックアップ保持ポリシーを設定する + 耐久性とコスト効率のために Amazon S3 にバックアップを保存する + バックアップ復元手順を定期的にテストする **AWS Backup:** + EBS ボリュームスナップショットに [AWS Backup](https://aws.amazon.com/backup/) を使用する + バックアップスケジュールと保持ポリシーを設定する + ディザスタリカバリ用のクロスリージョンバックアップコピーを有効にする **マルチテナントの場合:** + CDB の RMAN バックアップには、すべての PDB が自動的に含まれる + 必要に応じて個々の PDB をバックアップすることもできる + ビジネス要件に基づいて PDB 固有のバックアップスケジュールを検討する RMAN バックアップスクリプトの例: ``` #!/bin/bash export ORACLE_HOME=/u01/app/oracle/product/19.0.0/dbhome_1 export ORACLE_SID=ORCL export PATH=$ORACLE_HOME/bin:$PATH rman target / << EOF run { backup as compressed backupset database plus archivelog; delete noprompt obsolete; } exit; EOF ``` **モニターリングの設定** EC2 でホストされている Oracle データベースの包括的なモニタリングを実装します。 **Amazon CloudWatch** + EC2 インスタンスのヘルス、ディスク使用量、カスタム Oracle メトリクスの CloudWatch メトリクスを設定する + 重要なしきい値の CloudWatch アラームを作成する + データベースアラートログのモニタリングに CloudWatch Logs を使用する **Oracle Enterprise Manager (OEM):** + 可能な場合は、データベースモニタリング用に OEM を設定する + パフォーマンスのモニタリングと診断を設定する + 重要なイベントの自動アラートを設定する **サードパーティー製ツール:** + データベースモニタリングに Datadog、New Relic、Prometheus などのツールを検討する + 既存のモニタリングインフラストラクチャと統合する **モニタリングすべき主要なメトリクス:** + テーブルスペースの使用状況 + アーカイブログスペース + 無効なオブジェクト + セッション数 + 待機イベント + CPU とメモリの使用率 + I/O パフォーマンス **マルチテナントの場合:** + CDB レベルと PDB レベルの両方のメトリクスをモニタリングする + PDB リソースの使用状況とクォータのアラートを設定する + PDB 固有のパフォーマンスメトリクスを追跡する **セキュリティグループとネットワーク ACL を設定する** EC2 インスタンスのセキュリティを確認して強化します。 **セキュリティグループ:** + データベースポートへのアクセスを、承認されたアプリケーションサーバーと踏み台ホストのみに制限する + 移行中に作成された過度に許可されたルールを削除する + セキュリティグループのルールとその目的を文書化する **ネットワーク ACL:** + 追加のセキュリティレイヤー用に VPC ネットワーク ACL を設定する + 多層防御セキュリティ戦略を実装する **SSH アクセス:** + SSH アクセスを特定の IP 範囲に制限するか、AWS Systems Manager Session Manager を使用する + パスワード認証を無効にし、キーベースの認証のみを使用する + 特権アクセスに多要素認証 (MFA) を導入する **暗号化:** + EBS ボリュームの保管時の暗号化を有効にする + Oracle Native Network Encryption または TLS を使用して、データベース接続の転送中の暗号化を有効にする + 暗号化キーを定期的にローテーションする **高可用性を実装する** ワークロードに高可用性が必要な場合は、次の実装を検討してください。 **Oracle Data Guard:** + ディザスタリカバリ用に別の EC2 インスタンスに新しいスタンバイデータベースを設定する + マルチテナントの場合、Data Guard はすべての PDB を含む CDB 全体を保護する + スタンバイは別のアベイラビリティーゾーンまたはリージョンに配置できる + スクリプトまたはサードパーティーツールを使用して、自動フェイルオーバーメカニズムを実装する **AWS マルチ AZ 配置:** + スタンバイインスタンスを異なるアベイラビリティーゾーンにデプロイする + DNS フェイルオーバーに Amazon Route 53 を使用する + フェイルオーバーをサポートするアプリケーションレベルの接続プーリングを実装する **バックアップとリカバリ:** + テスト済みの復元手順を備えた定期的なバックアップを維持する + 目標復旧時間 (RTO) と目標復旧時点 (RPO) を文書化する + ディザスタリカバリドリルを定期的に実行する **徹底的なアプリケーションテストを実行する** RDS Custom インスタンスを廃止する前: **機能テスト:** + すべてのアプリケーション機能が正しく動作することを確認する + データベース依存機能をすべてテストする + データの整合性と一貫性を検証する **パフォーマンステスト:** + パフォーマンスメトリクスを RDS Custom ベースラインと比較する + パフォーマンスのリグレッションを特定して対処する + 必要に応じてクエリとインデックスを最適化する **負荷テスト:** + 予想されるピーク負荷でデータベースをテストする + リソース使用率が許容範囲内に収まっていることを確認する + ボトルネックを特定して対処する **フェイルオーバーテスト (HA が設定されている場合):** + フェイルオーバーシナリオをテストする + アプリケーション再接続ロジックを検証する + 実際の RTO と RPO を測定する **バックアップと復元のテスト:** + バックアップと復元の手順が正しく機能することを確認する + ポイントインタイムリカバリをテストする + バックアップの整合性を検証する **マルチテナントの場合:** + 各 PDB を個別にテストする + PDB の分離とリソース割り当てを検証する + PDB 固有のオペレーションをテストする (クローン、アンプラグ/プラグなど) **RDS Custom インスタンスの廃止** 検証期間 (通常は 1～2 週間) が成功した後: 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 ``` 1. **移行を文書化する**: 新しい EC2 設定でランブックとドキュメントを更新する 1. **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 ``` 1. **リソースのクリーンアップ**: 不要になった関連スナップショット、パラメータグループ、オプショングループを削除する 1. **ドキュメントの更新**: すべての運用ドキュメントに新しい EC2 ベースのアーキテクチャが反映されていることを確認する ## 比較: RMAN アクティブ複製と Oracle Data Guard 次の表は、2 つの移行オプションの主な違いをまとめたものです。 | **側面** | **RMAN アクティブ複製** | **Oracle Data Guard** | | --- | --- | --- | | **ソースデータベースの可用性** | 複製全体のオンライン | プロセス全体を通してオンライン | | **ダウンタイム** | 数分 (最終カットオーバーのみ) | 数秒から数分 (スイッチオーバー) | | **複雑さ** | Lower | より高い | | **移行期間** | 単一複製オペレーション | 初期設定 \+ 連続同期 | | **継続的な同期** | いいえ | あり | | **フォールバック機能** | 手動 (ソースの実行を維持) | 組み込み (自動) | | **カットオーバー前のテスト** | 限定 (複製後のテスト) | 完全なテストが可能 (スタンバイのテストも可能) | | **ネットワーク帯域幅** | 複製中は高 | 中程度 (連続) | | **ソースデータベースへの影響** | 最小 (読み取りオペレーション) | 最小 (REDO 配布) | | **次の用途に適しています** | ほとんどの移行、簡単なカットオーバー | ミッションクリティカルで、ほぼゼロのダウンタイムが必要 | | **非 CDB のサポート** | はい | はい | | **マルチテナントのサポート** | はい (CDB 全体) | はい (CDB 全体) | | **移行後の PDB の状態** | CDB はオープン、PDB は MOUNTED | CDB はオープン、PDB は MOUNTED | | **RMAN が必要** | はい | はい (バックアップベースのアプローチでの初期バックアップの場合) | | **Data Guard が必要** | いいえ | あり | | **必要なスキルレベル** | 中級 | アドバンスト | | **カットオーバープロセス** | アプリケーションを EC2 にリダイレクトする | スイッチオーバーコマンド \+ アプリケーションのリダイレクト | ## 比較: 非 CDB とマルチテナントの移行次の表は、非 CDB データベースとマルチテナントデータベースの移行の主な違いをまとめたものです。 | **側面** | **非 CDB の移行** | **マルチテナント (PDB を含む CDB) の移行** | | --- | --- | --- | | **データベースタイプ** | 単一インスタンスの非 CDB (例: ORCL) | CDB (ソース: RDSCDB、ターゲット: ORCL) に CDB$ROOT \+ PDB$SEED \+ 1 つ以上の PDB が含まれる | | **移行範囲** | 単一のデータベース | CDB 全体 (すべての PDB が自動的に含まれます) | | **RMAN 複製スコープ** | 単一のデータベースを複製 | CDB 全体 (すべてのコンテナ) を複製 | | **Data Guard スコープ** | 単一のデータベースを保護 | CDB 全体を保護 (すべての PDB が自動的に含まれます) | | **パラメータファイル** | 標準 init パラメータ | enable\_pluggable\_database=TRUE を含める必要があります | | **移行後のデータベースの状態** | データベースが READ WRITE モードで開きます | CDB が READ WRITE モードで開きます。PDB は MOUNTED 状態のままです | | **PDB を開く** | 該当なし | ALTER PLUGGABLE DATABASE ALL OPEN を使用して、すべての PDB を手動で開く必要があります | | **起動時の PDB 自動オープン** | 該当なし | PDB の状態保存または起動トリガーを設定する必要があります | | **検証**: | 単一のデータベースチェック | CDB と各 PDB を個別に検証する必要があります | | **RDS 固有のクリーンアップ** | 単一のデータベースからユーザー/オブジェクトを削除する | CDB$ROOT から共通ユーザーを削除 (PDB にカスケード)、C\#\# ユーザーを扱う | | **TNS/リスナー設定** | データベースの単一サービス | CDB サービス \+ 個々の PDB サービスが動的に登録されます | | **アプリケーション接続文字列** | 単一のデータベースへの接続 | 個々の PDB サービス (CDB ではない) に接続 | | **バックアップ戦略** | 単一データベースのバックアップ | CDB 全体 (すべての PDB を含む) または個々の PDB のバックアップ | | **リソース管理** | データベースレベルのリソース管理 | Resource Manager による CDB レベルと PDB レベルのリソース管理 | | **複雑さ** | 複雑性が低い | 複数のコンテナと OMF パスにより複雑性が高い | ## ベストプラクティスとレコメンデーションこのセクションでは、RDS Custom for Oracle から EC2 への移行を成功させるための包括的なベストプラクティスについて説明します。 ### 移行前の計画 1. 徹底的な評価を実施する。移行を開始する前に、環境の包括的な評価を実行します。 + **データベースインベントリ**: すべてのデータベース、そのサイズ、アーキテクチャ (非 CDB とマルチテナント)、依存関係を文書化する + **アプリケーションの依存関係**: データベースに接続するすべてのアプリケーションとその接続方法を特定する + **パフォーマンスベースライン**: 移行後の比較のためにパフォーマンスメトリクス (CPU、メモリ、I/O、ネットワーク) をキャプチャする + **バックアップと復旧の要件**: RPO (目標復旧時点) と RTO (目標復旧時間) を文書化する + **コンプライアンス要件**: 移行に影響する可能性のある規制またはコンプライアンス要件を特定する 1. 適切な EC2 インスタンスタイプを選択する。ワークロードの特性に基づいて EC2 インスタンスタイプを選択します。 [See the AWS documentation website for more details](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/RDS-Custom-for-Oracle-end-of-support.html) **インスタンスのサイズ設定ガイドライン:** + RDS Custom インスタンスと同じインスタンスクラスから開始する + テスト移行中のリソース使用率をモニタリングする + AWS Compute Optimizer のレコメンデーションの活用を検討する + 成長とピーク負荷に備えて 20～30% のヘッドルームを計画する 1. ストレージアーキテクチャを設計する。 **EBS ボリュームの種類:** [See the AWS documentation website for more details](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/RDS-Custom-for-Oracle-end-of-support.html) **ストレージレイアウトの推奨事項:** ``` # 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 割り当て + 容易な容量管理 + バックアップとスナップショットの戦略の簡素化 + パフォーマンスの分離性の向上 1. ロールバックプランを確立する。常にロールバック戦略を用意しておきます。 + 検証期間中 (1～2 週間を推奨) に **RDS Custom インスタンスを実行し続ける** + ソースとターゲットの両方の**定期的なバックアップを維持する** + 接続文字列の変更を含む**ロールバック手順を文書化する** + 非本番環境で**ロールバックプロセスをテストする** + **ロールバック基準を定義する** (パフォーマンスの低下、データの不整合、アプリケーションエラー) ### 移行実行のベストプラクティス 1. **移行のタイミング:** 最適な時間枠を選択する。 + **トラフィックが少ない時間帯**: 週末、祝日、またはオフピーク時間 + **メンテナンスウィンドウ**: 可能であれば、スケジュールされたメンテナンスに合わせる + **月末/四半期末を避ける**: これらの期間は通常、トランザクション量が多いため + **タイムゾーンを検討する**: グローバルアプリケーションの場合は、リージョン間の影響を最小限に抑える時間を選択する 1. **コミュニケーション計画:** 明確なコミュニケーションを確立する。 + **ステークホルダーへの通知**: 少なくとも 2 週間前にすべてのステークホルダーに通知する + **アプリケーションチーム**: 接続文字列の更新についてアプリケーションチームと調整する + **ステータスの更新**: 移行中は定期的に最新情報を提供する + **エスカレーションパス**: 問題の明確なエスカレーション手順を定義する + **移行後のコミュニケーション**: 正常に完了したことと、フォローアップアクションを確認する 1. **検証チェックポイント:** 各段階で検証を実装します。 **移行前の検証:** ``` -- 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; ``` 1. **パフォーマンスの検証:** 移行前と移行後のパフォーマンスメトリクスを比較する。 ``` -- 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; ``` 1. ストレージの最適化: **圧縮を有効にします。** ``` -- 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) ); ``` 1. モニタリングとアラートを実装します。 **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 ``` 1. セキュリティ強化: **データベースセキュリティ ** ``` -- 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. 適切なサイジング:** 移行後、コストをモニタリングして最適化します。 + **AWS Cost Explorer **を使用して EC2 と EBS のコストを分析する + インスタンスタイプのレコメンデーションについて、**AWS Compute Optimizer を有効にする** + **CloudWatch メトリクスを確認**して、十分に活用されていないリソースを特定する + 予測可能なワークロードに対して**リザーブドインスタンス**または Savings Plans を検討する **2. ストレージの最適化:** + S3 バックアップの**ライフサイクルポリシーを実装**する (30 日後に Glacier に移行する) + 定期的に**未使用の EBS スナップショットを削除する** + **gp2 の代わりに gp3 を使用**して、同じパフォーマンスでコストを削減する + 移行の完了後に**バックアップボリュームをデタッチおよび削除する** **3. Automation** + 営業時間外の非本番稼働用データベースの**開始/停止を自動化**する + パッチ管理に **AWS Systems Manager Patch Manager** を使用する + Data Guard を使用している場合、リードレプリカの**自動スケーリングを実装**する ## 結論この規範的ガイダンスでは、Oracle データベースを Amazon RDS Custom for Oracle から Amazon EC2 のセルフマネージド Oracle データベースに移行するための詳細な移行戦略について説明しました。RDS Custom for Oracle サービス廃止が、2027 年 3 月 31 日に有効となるため、移行を事前に計画して実行することが重要です。 **重要なポイント** **移行オプション** + **RMAN アクティブ複製**: ほとんどの移行に最適で、複製時にソースデータベースをオンラインに保ち、アプリケーションのリダイレクトに必要なのはごく短いカットオーバーウィンドウのみです。 + **Oracle Data Guard**: ほぼゼロのダウンタイムを必要とするミッションクリティカルなワークロードに最適で、継続的な同期と組み込みのスイッチオーバー機能を提供します **アーキテクチャのサポート:** + どちらの移行オプションも、非 CDB (従来型の単一インスタンス) アーキテクチャとマルチテナント (PDB を含む CDB) アーキテクチャをサポートしています + マルチテナントの場合、どちらのメソッドもすべての PDB を含む CDB 全体を 1 回のオペレーションで自動的に処理します + PDB は、移行後に手動でのオープンと自動オープン設定が必要です **重要な成功要因:** + ソースとターゲット間の適切なネットワーク設定と接続 + 正確なバージョンの互換性 (メジャーバージョン、マイナーバージョン、リリース更新、およびワンオフパッチ) + データ転送 (RMAN) または REDO 配布 (Data Guard) に適切なネットワーク帯域幅 + RMAN アクティブ複製がソースをオンラインに保つため、必要なのはごく短いカットオーバーのみであることを理解する + ソースを廃止する前に徹底的なテストと検証を行う + バックアップ、モニタリング、セキュリティ設定を含む包括的な移行後タスク **次のステップ:** 1. データベースアーキテクチャを評価する (非 CDB またはマルチテナント) 1. ダウンタイムの許容度と複雑さの要件に基づいて、適切な移行オプションを選択する 1. EC2 インスタンスのセットアップやネットワーク設定など、すべての前提条件となるステップを完了する 1. 選択したオプションの詳細な移行ステップに従う 1. 徹底的な検証とテストを実行する 1. 移行後のタスクを完了して本番環境の準備を整える 1. 検証が成功したら RDS Custom インスタンスを廃止する **その他のリソース**。 + [Amazon RDS Custom for Oracle ユーザーガイド](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/custom.html) + [Oracle Database のドキュメント](https://docs.oracle.com/en/database/) + [Oracle RMAN のドキュメント](https://docs.oracle.com/en/database/oracle/oracle-database/19/bradv/) + [Oracle Data Guard のドキュメント](https://docs.oracle.com/en/database/oracle/oracle-database/19/sbydb/) + [AWS Database Migration Service](https://aws.amazon.com/dms/) + [AWS 規範的ガイダンス](https://aws.amazon.com/prescriptive-guidance/) ** サポート** 移行に関するサポートについては、以下までお問い合わせください。 + AWS マネジメントコンソールから AWS サポートに問い合わせる + データベース固有の質問について、Oracle サポートに問い合わせる ## **ドキュメント情報** **最終更新日:** 2026 年 3 月 **寄稿者:** + Amazon Web Services、データベーススペシャリストソリューションアーキテクト、Sharath Chandra Kampili + Amazon Web Services、データベーススペシャリストソリューションアーキテクト、Ibrahim Emara + Amazon Web Services、データベーススペシャリストソリューションアーキテクト、Vetrivel Subramani