AWS Database Migration Service
ユーザーガイド (Version API Version 2016-01-01)

AWS DMS のソースとして Oracle データベースを使用する

AWS DMS を使用して、1 つ以上の Oracle データベースからデータを移行できます。Oracle データベースをソースとして使用すると、AWS DMS によりサポートされているいずれかのターゲットにデータを移行できます。

自己管理型の Oracle データベースの場合、AWS DMS ではバージョン 10.2 以降、11g、12.2 以前のすべての Oracle データベースエディションがソースの自己管理型データベースとしてサポートされています。Amazon RDS により提供される Amazon が管理する Oracle データベースの場合、AWS DMS はバージョン 11g (バージョン 11.2.0.3.v1 以降) および 12.2 以前のすべての Oracle データベースエディションをサポートしています。

SSL を使用して、Oracle エンドポイントとレプリケーションインスタンスとの接続を暗号化できます。Oracle エンドポイントで SSL を使用する方法の詳細については、「AWS Database Migration Service で SSL を使用する」を参照してください。

AWS DMS のソースとして Oracle データベースを設定するステップは次のとおりです。

  1. CDC のみのタスクまたは全ロードと CDC のタスクを作成する場合、Oracle LogMiner または Oracle Binary Reader を選択してデータ変更をキャプチャする必要があります。LogMiner または Binary Reader を選択すると、それ以降のアクセス許可と設定タスクのいくつかが決定されます。LogMiner と Binary Reader の比較については、次のセッションを参照してください。

  2. AWS DMS の適切なアクセス許可を持つ Oracle ユーザーを作成します。全ロードのみのタスクを作成する場合、これ以上設定は必要ありません。

  3. 選択した設定に準拠する DMS エンドポイントを作成します。

Oracle データベースと AWS DMS の使用の詳細については、以下のセクションを参照してください。

変更データキャプチャ (CDC) での Oracle LogMiner または Oracle Binary Reader の使用

Oracle には、変更処理を行う際に REDO ログを読み取るための方法として Oracle LogMiner と Oracle Binary Reader の 2 つが用意されています。Oracle LogMiner には、Oracle のオンラインおよびアーカイブ REDO ログファイルへの SQL インターフェイスが用意されています。Binary Reader は raw REDO ログファイルを直接読み取って解析する AWS DMS 機能です。

デフォルトでは、AWS DMS は変更データキャプチャ (CDC) に Oracle LogMiner を使用します。AWS DMS で LogMiner を使用することのメリットは次のとおりです。

  • LogMiner では、暗号化オプションや圧縮オプションなど、ほとんどの Oracle オプションがサポートされています。Binary Reader では、すべての Oracle オプションがサポートされているわけではありません (特に暗号化と圧縮のオプション)。

  • LogMiner には、特に Oracle Binary Reader の直接アクセスセットアップと比較したり、REDO ログが Automatic Storage Management (ASM) 上にある場合と比較して、シンプルな設定になっています。

  • LogMiner は、Oracle Transparent Data Encryption (TDE) を含むほとんどの Oracle 暗号化オプションを完全にサポートします。

  • LogMiner は、全ロードおよび継続的レプリケーション (CDC) の両方に対して次の HCC 圧縮タイプをサポートします。

    • QUERY HIGH

    • ARCHIVE HIGH

    • ARCHIVE LOW

    • QUERY LOW

    Binary Reader は、継続的 (CDC) レプリケーションではなく、全ロードレプリケーションでのみ QUERY LOW 圧縮をサポートします。

  • LogMiner は、AWS DMS により使用されるテーブルクラスターをサポートします。Binary Reader はサポートされません。

AWS DMS で LogMiner の代わりに Binary Reader を使用することのメリットは次のとおりです。

  • 大量の変更を含む移行の場合、LogMiner は Oracle ソースデータベースをホストするコンピュータの I/O や CPU にある程度の影響を及ぼすことがあります。Binary Reader では、アーカイブログがレプリケーションインスタンスにコピーされてそこでデータマイニングが行われるため、I/O や CPU に影響を与える可能性は高くありません。

  • 大量の変更を含む移行の場合、Oracle LogMiner を使用するより Binary Reader を使用した方が CDC のパフォーマンスが通常はかなり高くなります。

  • Binary Reader では、Oracle バージョン 12c における LOB の CDC がサポートされています。LogMiner ではサポートされていません。

  • Binary Reader は、全ロードおよび継続的レプリケーション (CDC) の両方に対して次の HCC 圧縮タイプをサポートします。

    • QUERY HIGH

    • ARCHIVE HIGH

    • ARCHIVE LOW

      QUERY LOW 圧縮タイプは、全ロードの移行のみでサポートされています。

通常、次のいずれかの状況に該当しない限り、Oracle データベースの移行には Oracle LogMiner を使用します。

  • ソース Oracle データベースで複数の移行タスクを実行する必要がある。

  • ソース Oracle データベース上の変更の量または REDO ログの量が多い。

  • Oracle 12.2 以降のソースエンドポイントから LOB を移行する。

  • ワークロードには、LOB 列のみを更新する UPDATE ステートメントが含まれています。この場合、Binary Reader を使用します。これらの UPDATE ステートメントは、Oracle LogMiner でサポートされていません。

  • ソースが Oracle バージョン 11 であり、XMLTYPE および LOB 列で UPDATE ステートメントを実行しています。この場合、Binary Reader を使用する必要があります。これらのステートメントは、Oracle LogMiner でサポートされていません。

  • Oracle 12c から LOB 列を移行しています。Oracle 12c で LogMiner は LOB 列をサポートしていないため、この場合には Binary Reader を使用します。

Oracle ソースデータベースでの変更データキャプチャ (CDC) の設定

全ロードおよび変更データキャプチャ (CDC) または CDC のみのソースエンドポイントとして Oracle を使用する場合は、追加の接続属性を設定する必要があります。この属性は、LogMiner と Binary Reader のどちらを使用してトランザクションログにアクセスするかを指定します。ソースエンドポイントを作成するときに追加の接続属性を指定します。接続属性の設定が複数ある場合は、空白を追加せずにそれぞれをセミコロンで区切ります。

デフォルトでは LogMiner が使用されるため、その使用を明示的に指定する必要はありません。Binary Reader がトランザクションログにアクセスできるようにするには、以下の追加の接続属性を加えます。

useLogMinerReader=N;useBfile=Y;

Oracle ソースデータベースが Oracle 自動ストレージ管理 (ASM) を使用している場合、追加の接続属性に ASM ユーザー名と ASM サーバーアドレスを含める必要があります。ソースエンドポイントを作成する場合、パスワードフィールドには両方のパスワード、ソースユーザーパスワード、および ASM パスワードが必要です。

たとえば、次の追加の接続属性形式は、Oracle ASM を使用するサーバーにアクセスするために使用されます。

useLogMinerReader=N;asm_user=<asm_username>;asm_server=<first_RAC_server_ip_address>:<port_number>/+ASM

Oracle ソースデータベースが Oracle ASM を使用している場合、ソースエンドポイントパスワードフィールドに、Oracle ユーザーパスワードと ASM パスワードをカンマで区切って含める必要があります。たとえば、以下はパスワードフィールドで機能します。

<oracle_user_password>,<asm_user_password>

Oracle ソースデータベースとしての CDC の制限

Oracle データベースを AWS DMS 変更データキャプチャのソースとして使用する場合は、以下の制限が適用されます。

  • AWS DMS では、テーブルメタデータや OBJECT_ID 値の変更など Oracle DBMS_REDEFINITION パッケージにより生じた変更がキャプチャされません。

  • AWS DMS では、BFILE を使用する際、オーバーフローセグメントがあるインデックスで整理されるテーブルは、CDC モードでサポートされません。たとえば、LogMiner を使用しないで REDO ログにアクセスする場合などです。

AWS DMS のソースとして自己管理型 Oracle データベースを使用する

自己管理型データベースは、自分で構成および制御するデータベースで、ローカルのオンプレミスデータベースインスタンスまたは Amazon EC2 上のデータベースのどちらかです。AWS DMS で自己管理型 Oracle データベースを使用する場合にセットアップする必要がある権限と設定を以下に示します。

AWS DMS の自己管理型 Oracle ソースで必要なユーザーアカウント権限

Oracle データベースを AWS DMS タスクでソースとして使用するには、AWS DMS Oracle データベース定義で指定されたユーザーに Oracle データベースにおける次の権限が付与されている必要があります。権限を付与する場合、オブジェクトのシノニムではなく、オブジェクトの実際の名前を使用します。たとえば、V_$OBJECT を下線を含めて使用し、下線のない V$OBJECT は使用しません。

GRANT SELECT ANY TRANSACTION to <dms_user> GRANT SELECT on V_$ARCHIVED_LOG to <dms_user> GRANT SELECT on V_$LOG to <dms_user> GRANT SELECT on V_$LOGFILE to <dms_user> GRANT SELECT on V_$DATABASE to <dms_user> GRANT SELECT on V_$THREAD to <dms_user> GRANT SELECT on V_$PARAMETER to <dms_user> GRANT SELECT on V_$NLS_PARAMETERS to <dms_user> GRANT SELECT on V_$TIMEZONE_NAMES to <dms_user> GRANT SELECT on V_$TRANSACTION to <dms_user> GRANT SELECT on ALL_INDEXES to <dms_user> GRANT SELECT on ALL_OBJECTS to <dms_user> GRANT SELECT on DBA_OBJECTS to <dms_user> (required if the Oracle version is earlier than 11.2.0.3) GRANT SELECT on ALL_TABLES to <dms_user> GRANT SELECT on ALL_USERS to <dms_user> GRANT SELECT on ALL_CATALOG to <dms_user> GRANT SELECT on ALL_CONSTRAINTS to <dms_user> GRANT SELECT on ALL_CONS_COLUMNS to <dms_user> GRANT SELECT on ALL_TAB_COLS to <dms_user> GRANT SELECT on ALL_IND_COLUMNS to <dms_user> GRANT SELECT on ALL_LOG_GROUPS to <dms_user> GRANT SELECT on SYS.DBA_REGISTRY to <dms_user> GRANT SELECT on SYS.OBJ$ to <dms_user> GRANT SELECT on DBA_TABLESPACES to <dms_user> GRANT SELECT on ALL_TAB_PARTITIONS to <dms_user> GRANT SELECT on ALL_ENCRYPTED_COLUMNS to <dms_user> GRANT SELECT on V_$LOGMNR_LOGS to <dms_user> GRANT SELECT on V_$LOGMNR_CONTENTS to <dms_user>

継続的なレプリケーション (CDC) を使用する場合は、以下の追加のアクセス権限が必要です。

  • AWS DMS で CDC を使用して 11g と 12c 両方の Oracle LogMiner REDO ログに追加する場合は、以下のアクセス権限が必要です。

    Grant EXECUTE ON dbms_logmnr TO <dms_user>;
  • AWS DMS で CDC を使用して 12c のみの Oracle LogMiner REDO ログに追加する場合は、以下のアクセス権限が必要です。

    Grant LOGMINING TO <dms_user>;

以下に示す追加機能を使用する場合は、特定の追加のアクセス許可が必要です。

  • ビューが公開されている場合、ALL_VIEWS での SELECT を <dms_user> に付与します。

  • レプリケーションタスクでパターンを使用してテーブル名とマッチングする場合、SELECT ANY TABLE を付与します。

  • レプリケーションタスクでテーブルリストを指定した場合、リスト内の各テーブルでの SELECT を付与します。

  • サプリメンタルロギングを追加する場合、ALTER ANY TABLE を付与します。

  • サプリメンタルロギングを追加し、特定のテーブルリストを使用する場合、リスト内のテーブルごとに ALTER を付与します。

  • Oracle RAC から移行する場合、gv_$ や v_$ といったプレフィックスを持つマテリアライズドビューに対する SELECT アクセス権限を付与します。

AWS DMS の自己管理型 Oracle ソースを設定する

自己管理型 Oracle データベースを AWS DMS のソースとして使用する前に、いくつかのタスクを実行する必要があります。

  • Oracle アカウントアクセスを提供する – AWS DMS の Oracle ユーザーアカウントを指定します。ユーザーアカウントには、前のセクションで指定されているように、Oracle データベースでの読み取り/書き込み権限が必要です。

  • ARCHIVELOG モードがオンであることを確認する – Oracle は、ARCHIVELOG モードと NOARCHIVELOG モードの 2 つのモードで実行できます。AWS DMS で Oracle を使用する場合は、ソースデータベースが ARCHIVELOG モードになっている必要があります。

  • サプリメンタルロギングのセットアップ – CDC タスクまたは全ロードと CDC タスクでソースを使用する予定の場合、サプリメンタルロギングをセットアップしてレプリケーションの変更をキャプチャする必要があります。

Oracle のサプリメンタルロギング作成を有効にするには、2 つのステップがあります。まず、データベースレベルのサプリメンタルロギングを有効にする必要があります。これにより、クラスター化されたテーブルやインデックスで整理されたテーブルなど、さまざまなテーブル構造をサポートするのに必要な最小限の情報が LogMiner に確保されます。次に、移行するテーブルごとにテーブルレベルのサプリメンタルロギングを有効にする必要があります。

データベースレベルのサプリメンタルロギングを有効にするには

  1. 次のクエリを実行し、データベースレベルでのサプリメンタルロギングがすでに有効になっているかどうかを調べます。返される結果は、GE to 9.0.0 です。

    SELECT name, value, description FROM v$parameter WHERE name = 'compatible';
  2. 次のクエリを実行します。返される結果は、YES または IMPLICIT です。

    SELECT supplemental_log_data_min FROM v$database;
  3. 次のクエリを実行し、データベースレベルのサプリメンタルロギングを有効にします。

    ALTER DATABASE ADD SUPPLEMENTAL LOG DATA;

テーブルレベルのサプリメンタルロギング作成を有効にするには、2 つの方法があります。最初の方法では、データベースユーザーアカウントが移行するすべてのテーブルで ALTER TABLE 権限を持っている場合、以下で説明するように追加の接続パラメータ addSupplementalLogging を使用できます。もう 1 つの方法では、移行時に各テーブルに以下のステップを使用できます。

テーブルレベルのサプリメンタルロギングを有効にするには

  1. テーブルにプライマリキーがある場合、次のコマンドを実行してテーブルに PRIMARY KEY サプリメンタルロギングを追加します。

    ALTER TABLE <table_name> ADD SUPPLEMENTAL LOG DATA (PRIMARY KEY) COLUMNS;
  2. プライマリキーが存在せず、テーブルに一意のインデックスが複数存在する場合、AWS DMS はインデックス名をアルファベット順に並べたときの最初の一意のインデックスを使用します。

    前述のように、そのインデックスの列にサプリメンタルロググループを作成します。

  3. プライマリキーも一意のインデックスも存在しない場合、サプリメンタルロギングをすべての列に追加する必要があります。次のクエリを実行し、サプリメンタルロギングをすべての列に追加します。

    ALTER TABLE <table_name> ADD SUPPLEMENTAL LOG DATA (ALL) COLUMNS;

場合によっては、ターゲットテーブルのプライマリキーまたは一意のインデックスは、ソーステーブルのプライマリキーまたは一意のインデックスと異なります。その場合、ターゲットテーブルのプライマリキーまたは一意のインデックスを構成するソーステーブル列でサプリメンタルロギングを追加します。ターゲットテーブルのプライマリキーを変更する場合、選択されたインデックスの列にサプリメンタルロギングを追加します。元のプライマリーキーの列や一意のインデックスにはこれを追加しないでください。

フィルタがテーブルに定義されている場合など、必要に応じて追加のロギングを追加します。テーブルに一意のインデックスやプライマリキーがある場合、フィルタに関係する列がプライマリキーまたは一意のインデックスの列とは異なるときは、その各列にサプリメンタルロギングを追加します。ただし、ALL COLUMNS サプリメンタルロギングがテーブルに追加されている場合、追加のロギングを追加する必要はありません。

ALTER TABLE <table_name> ADD SUPPLEMENTAL LOG GROUP <group_name> (<column_list>) ALWAYS;

Amazon が管理する Oracle データベースを AWS DMS のソースとして使用する

Amazon が管理するデータベースは、Amazon RDS、Amazon Aurora、Amazon Simple Storage Service (Amazon S3) などの Amazon のサービス上にあるデータベースです。AWS DMS で Amazon が管理する Oracle データベースを使用するときにセットアップする必要がある権限と設定を以下に示します。

AWS DMS の Amazon が管理する Oracle ソースで必要なユーザーアカウント権限

Amazon RDS で Oracle データベースにおける権限を付与するには、ストアドプロシージャ rdsadmin.rdsadmin_util.grant_sys_object を使用します。詳細については、「SYS オブジェクトへの SELECT または EXECUTE 権限の付与」を参照してください。

AWS DMS ユーザーアカウントに、Oracle ソースエンドポイントにアクセスするための以下の権限を付与します。

GRANT SELECT ANY TABLE to <dms_user>; GRANT SELECT on ALL_VIEWS to <dms_user>; GRANT SELECT ANY TRANSACTION to <dms_user>; GRANT SELECT on DBA_TABLESPACES to <dms_user>; GRANT SELECT on ALL_TAB_PARTITIONS to <dms_user>; GRANT SELECT on ALL_INDEXES to <dms_user>; GRANT SELECT on ALL_OBJECTS to <dms_user>; GRANT SELECT on ALL_TABLES to <dms_user>; GRANT SELECT on ALL_USERS to <dms_user>; GRANT SELECT on ALL_CATALOG to <dms_user>; GRANT SELECT on ALL_CONSTRAINTS to <dms_user>; GRANT SELECT on ALL_CONS_COLUMNS to <dms_user>; GRANT SELECT on ALL_TAB_COLS to <dms_user>; GRANT SELECT on ALL_IND_COLUMNS to <dms_user>; GRANT SELECT on ALL_LOG_GROUPS to <dms_user>; GRANT LOGMINING TO <dms_user>;

さらに、次を実行します。

exec rdsadmin.rdsadmin_util.grant_sys_object('V_$ARCHIVED_LOG','<dms_user>','SELECT'); exec rdsadmin.rdsadmin_util.grant_sys_object('V_$LOG','<dms_user>','SELECT'); exec rdsadmin.rdsadmin_util.grant_sys_object('V_$LOGFILE','<dms_user>','SELECT'); exec rdsadmin.rdsadmin_util.grant_sys_object('V_$DATABASE','<dms_user>','SELECT'); exec rdsadmin.rdsadmin_util.grant_sys_object('V_$THREAD','<dms_user>','SELECT'); exec rdsadmin.rdsadmin_util.grant_sys_object('V_$PARAMETER','<dms_user>','SELECT'); exec rdsadmin.rdsadmin_util.grant_sys_object('V_$NLS_PARAMETERS','<dms_user>','SELECT'); exec rdsadmin.rdsadmin_util.grant_sys_object('V_$TIMEZONE_NAMES','<dms_user>','SELECT'); exec rdsadmin.rdsadmin_util.grant_sys_object('V_$TRANSACTION','<dms_user>','SELECT'); exec rdsadmin.rdsadmin_util.grant_sys_object('DBA_REGISTRY','<dms_user>','SELECT'); exec rdsadmin.rdsadmin_util.grant_sys_object('OBJ$','<dms_user>','SELECT'); exec rdsadmin.rdsadmin_util.grant_sys_object('ALL_ENCRYPTED_COLUMNS','<dms_user>','SELECT'); exec rdsadmin.rdsadmin_util.grant_sys_object('V_$LOGMNR_LOGS','<dms_user>','SELECT'); exec rdsadmin.rdsadmin_util.grant_sys_object('V_$LOGMNR_CONTENTS','<dms_user>','SELECT'); exec rdsadmin.rdsadmin_util.grant_sys_object('DBMS_LOGMNR','<dms_user>','EXECUTE');

AWS DMS の Amazon が管理する Oracle ソースを設定する

Amazon が管理する Oracle データベースを AWS DMS のソースとして使用する前に、いくつかのタスクを実行する必要があります。

  • Oracle アカウントアクセスを提供 – AWS DMS の Oracle ユーザーアカウントを指定します。ユーザーアカウントには、前のセクションで指定されているように、Oracle データベースでの読み取り/書き込み権限が必要です。

  • Amazon RDS データベースのバックアップ保持期間を 1 日以上に設定 – バックアップ保持期間を設定すると、データベースが ARCHIVELOG モードで実行されます。バックアップ保持期間の設定の詳細については、『 Amazon RDS ユーザーガイド』の「バックアップの使用」を参照してください。

  • アーカイブ保持の設定 – 以下を実行し、Oracle データベースインスタンスのアーカイブされた REDO ログを保持します。このコマンドを実行すると、AWS DMS が LogMiner を使用してログ情報を取得できるようになります。移行期間中、アーカイブされた REDO ログのための十分なストレージがあることを確認します。

    次の例では、ログは 24 時間保持されます。

    exec rdsadmin.rdsadmin_util.set_configuration('archivelog retention hours',24);
  • サプリメンタルロギングのセットアップ – CDC タスクまたは全ロードと CDC タスクでソースを使用する予定の場合、サプリメンタルロギングをセットアップしてレプリケーションの変更をキャプチャします。

    Oracle のサプリメンタルロギング作成を有効にするには、2 つのステップがあります。まず、データベースレベルのサプリメンタルロギングを有効にする必要があります。これにより、クラスター化されたテーブルやインデックスで整理されたテーブルなど、さまざまなテーブル構造をサポートするのに必要な最小限の情報が LogMiner に確保されます。次に、移行するテーブルごとにテーブルレベルのサプリメンタルロギングを有効にする必要があります。

    データベースレベルのサプリメンタルロギングを有効にするには

    • 次のクエリを実行し、データベースレベルのサプリメンタルロギングを有効にします。

      exec rdsadmin.rdsadmin_util.alter_supplemental_logging('ADD');

    テーブルレベルのサプリメンタルロギングを有効にするには

    • 次のコマンドを実行し、プライマリキーを持つテーブルの PRIMARY KEY ロギングを有効にします。

      exec rdsadmin.rdsadmin_util.alter_supplemental_logging('ADD','PRIMARY KEY');

    プライマリキーを持たないテーブルの場合、次のコマンドを使用してサプリメンタルロギングを追加します。

    alter table <table_name> add supplemental log data (ALL) columns;

    プライマリキーのないテーブルを作成する場合、create ステートメントにサプリメンタルロギング句を含めるか、テーブルを変更してサプリメンタルロギングを追加する必要があります。次のコマンドは、テーブルを作成し、サプリメンタルロギングを追加します。

    create table <table_name> (<column_list>, supplemental log data (ALL) columns);

    テーブルを作成し、後でプライマリキーを追加した場合、テーブルにサプリメンタルロギングを追加する必要があります。次のコマンドを使用してテーブルにサプリメンタルロギングを追加します。

    alter table <table_name> add supplemental log data (PRIMARY KEY) columns;

AWS DMS における Amazon RDS for Oracle ソースの変更データキャプチャ (CDC) を設定する

AWS DMS を設定して、CDC のソースとして Amazon RDS for Oracle インスタンスを使用することができます。Amazon RDS for Oracle ソースで Oracle Binary Reader を使用します (Oracle バージョン 11.2.0.4.v11 以降、および 12.1.0.2.v7 以降)。

Amazon RDS for Oracle ソースエンドポイントを作成する場合は、次の追加の接続属性を含めます。

useLogminerReader=N;useBfile=Y;accessAlternateDirectly=false; useAlternateFolderForOnline=true;oraclePathPrefix=/rdsdbdata/db/ORCL_A/; usePathPrefix=/rdsdbdata/log/;replacePathPrefix=true

注記

複数の属性設定には、セミコロン区切り文字の後に空白を含めないこともできます。

Oracle を AWS DMS のソースとして使用する場合の制限

Oracle データベースを AWS DMS のソースとして使用する場合は、以下の制限が適用されます。

  • Oracle LogMiner と一緒に使用する場合、AWS DMS では、Oracle の透過的なデータ暗号化 (TDE) テーブルスペース暗号化と AWS Key Management Service (AWS KMS) 暗号化がサポートされます。他の暗号化形式はどれもサポートされていません。

  • LOB のあるテーブルで CDC を使用するにはプライマリキーが必要です。

  • AWS DMS では、Oracle バージョン 11 以降の rename table <table name> to <new table name> 構文がサポートされています。

  • 明示的な CHAR セマンティクスを使用して作成された Oracle ソースデータベース列は、BYTE セマンティクスを使用してターゲット Oracle データベースに転送されます。移行前に、ターゲット Oracle データベースでこのタイプの列を含むテーブルを作成します。

  • AWS DMS では、ADD、DROP、EXCHANGE、TRUNCATE のようなデータ定義言語 (DDL) オペレーションなど、パーティションまたはサブパーティションオペレーションの結果生じたデータの変更がレプリケートされません。このような変更をレプリケートするには、レプリケートするテーブルを再ロードします。AWS DMS は、その後のデータ変更を新たに追加されたパーティションにレプリケートします。テーブルを再ロードする必要はありません。ただし、パーティション内の古いデータレコードで UPDATE オペレーションを実行すると失敗し、0 rows affected 警告が生成されます。

  • DDL ステートメント ALTER TABLE ADD <column> <data_type> DEFAULT <> は、デフォルト値をターゲットにレプリケートしません。ターゲットの新しい列は NULL に設定されます。新しい列で NULL が許容される場合、Oracle は DDL 自体を記録する前にすべてのテーブル行を更新します。その結果、AWS DMS ではカウンターへの変更がキャプチャされますが、ターゲットは更新されません。新しい列は NULL に設定されるため、ターゲットテーブルにプライマリキーまたは一意のインデックスがない場合、その後の更新により 0 rows affected 警告が生成されます。

  • CREATE TABLE AS ステートメントの結果生じたデータ変更はサポートされていません。ただし、新しいテーブルがターゲットで作成されます。

  • サイズ制限のある LOB モードが有効な場合、AWS DMS では Oracle ソース上の空の LOB をターゲットの NULL 値としてレプリケートします。

  • AWS DMS によって CDC が開始されると、タイムスタンプが Oracle システム変更番号 (SCN) にマッピングされます。Oracle ではデフォルトで、タイムスタンプと SCN のマッピングは 5 日間、保持されます。指定したタイムスタンプが古すぎる (保持期間が 5 日間より長い) 場合、Oracle ではエラーが生成されます。詳細については、Oracle のドキュメントを参照してください。

  • AWS DMS では、ASM プロキシを使用した Oracle ソースへの接続がサポートされていません。

  • AWS DMS では仮想列がサポートされていません。

  • マルチテナント環境で、AWS DMS はコンテナ (CDB) 内のプラグイン可能なデータベース (PDB) に接続できます。この設定では、変更データキャプチャ (CDC) に Binary Reader を使用する必要があります。PDB では LogMiner はサポートされていません。

AWS DMS のソースとして Oracle を使用する場合の追加の接続属性

追加の接続属性を使用して Oracle ソースを設定できます。これらの設定は、ソースエンドポイントを作成するときに指定します。接続属性の設定が複数ある場合は、空白を追加せずにそれぞれをセミコロンで区切ります。

次の表に、AWS DMS のソースとして Oracle データベースを設定するために使用できる追加の接続属性を示します。

名前 説明

addSupplementalLogging

Oracle データベースにテーブルレベルのサプリメンタルロギングをセットアップするには、この属性を設定します。この属性により、移行タスクで選択されたすべてのテーブルで PRIMARY KEY サプリメンタルロギングが有効になります。

デフォルト値: N

有効な値: Y/N

例: addSupplementalLogging=Y;

注記

このオプションを使用する場合でも、前述のようにデータベースレベルサプリメンタルロギングを有効にする必要があります。

additionalArchivedLogDestId

この属性を、プライマリ/スタンバイセットアップで archivedLogDestId と同時に設定します。この属性はフェイルオーバーの場合に役立ちます。この場合、AWS DMS は変更を読み取るためにアーカイブ REDO ログを取得する取得元を知る必要があります。前のプライマリインスタンスがフェイルオーバー後にスタンバイインスタンスになったためにこの必要性が生じます。

useLogminerReader

LogMiner ユーティリティを使用して変更データをキャプチャするには、この属性を Y に設定します (デフォルト)。AWS DMS をバイナリファイルとして REDO ログにアクセスできるようにする場合は、このオプションを N に設定します。このオプションに設定すると、useBfile=Y という設定も追加されます。詳細については、「変更データキャプチャ (CDC) での Oracle LogMiner または Oracle Binary Reader の使用」を参照してください。

デフォルト値: Y

有効な値: Y/N

例: useLogminerReader=N;useBfile=Y;

Oracle ソースデータベースが Oracle 自動ストレージ管理 (ASM) を使用している場合、追加の接続パラメータに ASM ユーザー名と ASM サーバーアドレスを含める必要があります。パスワードフィールドには両方のパスワード、ソースユーザーパスワード、および ASM パスワードも必要です (互いにカンマで区切ります)。

例: useLogminerReader=N;asm_user=<asm_username>;asm_server=<first_RAC_server_ip_address>:<port_number>/+ASM;

useBfile Binary Reader ユーティリティを使用して変更データをキャプチャするには、この属性を Y に設定します。この属性を Y に設定するため、useLogminerReader を N に設定します。また、Amazon RDS for Oracle で Binary Reader をソースとして使用するには、追加の属性を設定します。詳細については、「変更データキャプチャ (CDC) での Oracle LogMiner または Oracle Binary Reader の使用」を参照してください。

デフォルト値: N

有効な値: Y/N

例: useLogminerReader=N;useBfile=Y;

accessAlternateDirectly Amazon RDS for Oracle をソースとして Binary Reader で変更データをキャプチャするには、この属性を false に設定します。この設定は、DMS インスタンスに対して、指定されたパスプレフィックス置換を使用してファイルへの直接アクセスで REDO ログにアクセスしないように指示します。詳細については、「 AWS DMS における Amazon RDS for Oracle ソースの変更データキャプチャ (CDC) を設定する 」を参照してください。

デフォルト値: true

有効な値: true/false

例: useLogminerReader=N;useBfile=Y;accessAlternateDirectly=false;

useAlternateFolderForOnline Amazon RDS for Oracle をソースとして Binary Reader で変更データをキャプチャするには、この属性を true に設定します。この設定は、DMS インスタンスに対して、指定されたプレフィックス置換を使用してすべてのオンライン REDO ログにアクセスするように指示します。詳細については、「 AWS DMS における Amazon RDS for Oracle ソースの変更データキャプチャ (CDC) を設定する 」を参照してください。

デフォルト値: false

有効な値: true/false

例: useLogminerReader=N;useBfile=Y;accessAlternateDirectly=false; useAlternateFolderForOnline=true;

oraclePathPrefix Amazon RDS for Oracle をソースとして Binary Reader で変更データをキャプチャするには、この文字列属性を必要な値に設定します。この値は、REDO ログにアクセスするために使用されるデフォルトの Oracle ルートを指定します。詳細については、「 AWS DMS における Amazon RDS for Oracle ソースの変更データキャプチャ (CDC) を設定する 」を参照してください。

デフォルト値: なし

有効な値: /rdsdbdata/db/ORCL_A/

例: useLogminerReader=N;useBfile=Y;accessAlternateDirectly=false; useAlternateFolderForOnline=true;oraclePathPrefix=/rdsdbdata/db/ORCL_A/;

usePathPrefix Amazon RDS for Oracle をソースとして Binary Reader で変更データをキャプチャするには、この文字列属性を必要な値に設定します。この値は、デフォルトの Oracle ルートを置換して REDO ログにアクセスするために使用されるパスプレフィックスを指定します。詳細については、「 AWS DMS における Amazon RDS for Oracle ソースの変更データキャプチャ (CDC) を設定する 」を参照してください。

デフォルト値: なし

有効な値: /rdsdbdata/log/

例: useLogminerReader=N;useBfile=Y;accessAlternateDirectly=false; useAlternateFolderForOnline=true;oraclePathPrefix=/rdsdbdata/db/ORCL_A/; usePathPrefix=/rdsdbdata/log/;

replacePathPrefix Amazon RDS for Oracle をソースとして Binary Reader で変更データをキャプチャするには、この属性を true に設定します。この設定は、DMS インスタンスに対して、デフォルトの Oracle ルートを usePathPrefix の設定に置換して REDO ログにアクセスするように指示します。詳細については、「 AWS DMS における Amazon RDS for Oracle ソースの変更データキャプチャ (CDC) を設定する 」を参照してください。

デフォルト値: false

有効な値: true/false

例: useLogminerReader=N;useBfile=Y;accessAlternateDirectly=false; useAlternateFolderForOnline=true;oraclePathPrefix=/rdsdbdata/db/ORCL_A/; usePathPrefix=/rdsdbdata/log/;replacePathPrefix=true;

retryInterval

システムがクエリを再送するまで待機する時間の秒数を指定します。

デフォルト値: 5

有効な値: 1 以降の数値

例: retryInterval=6;

archivedLogDestId

アーカイブされた REDO ログの宛先を指定します。値は、$archived_log テーブル内の DEST_ID 値と同じにする必要があります。ログの宛先を (DEST_ID) を複数使用する場合、アーカイブされた REDO ログの場所の識別子を使用することをお勧めします。これにより、最初から適切なログにアクセスされるため、パフォーマンスが向上します。

デフォルト値: 0

有効な値: 数値

例: archivedLogDestId=1;

archivedLogsOnly

このフィールドが Y に設定されている場合、AWS DMS はアーカイブされた REDO ログにのみアクセスします。アーカイブされた REDO ログが Oracle ASM のみに保存されている場合、AWS DMS ユーザーアカウントに ASM 権限を付与する必要があります。

デフォルト値: N

有効な値: Y/N

例: archivedLogsOnly=Y;

numberDataTypeScale

数値のスケールを指定します。最大 38 のスケールを選択するか、FLOAT を選択できます。デフォルトでは、NUMBER データ型が精度 38、スケール 10 に変換されます。

デフォルト値: 10

有効な値: -1〜38 (FLOAT の場合は -1)

例: numberDataTypeScale=12

afterConnectScript

AWS DMS がエンドポイントに接続した直後に実行するスクリプトを指定します。

有効な値: セミコロンで区切った任意の SQL ステートメント。すべての SQL ステートメントがサポートされているわけではありません。

例: afterConnectScript=ALTER SESSION SET CURRENT_SCHEMA = system;

failTasksOnLobTruncation

true に設定されると、LOB 列の実際のサイズが指定された LobMaxSize よりも大きい場合、この属性によりタスクは失敗します。

タスクが制限付き LOB モードに設定され、このオプションが true に設定されている場合、LOB データを切り捨てるのではなくタスクが失敗します。

デフォルト値: false

有効な値: ブール値

例: failTasksOnLobTruncation=true;

readTableSpaceName

true に設定すると、この属性はテーブルスペースのレプリケーションをサポートします。

デフォルト値: false

有効な値: ブール値

例: readTableSpaceName=true;

standbyDelayTime

この属性を使用して、スタンバイ同期の遅延時間を分単位で指定します。

AWS DMS バージョン 2.3.0 以降では、継続的な変更をレプリケートするためのソースとして Active Data Guard スタンバイインスタンスを使用する Oracle CDC タスクを作成することができます。これにより、運用中のアクティブなデータベースに接続する必要がなくなります。

デフォルト値: 0

有効な値: 数値

例: standbyDelayTime=1;

Oracle のソースデータ型

AWS DMS の Oracle エンドポイントでは、Oracle のほとんどのデータ型がサポートされています。次の表に、AWS DMS を使用する場合にサポートされる Oracle のソースデータ型と、AWS DMS のデータ型へのデフォルトマッピングを示します。

ターゲットにマッピングされるデータ型を表示する方法については、使用しているターゲットエンドポイントのセクションを参照してください。

AWS DMS のデータ型の詳細については、「AWS Database Migration Service のデータ型」を参照してください。

Oracle のデータ型

AWS DMS データ型

BINARY_FLOAT

REAL4

BINARY_DOUBLE

REAL8

BINARY

BYTES

FLOAT (P)

精度が 24 以下の場合、REAL4 を使用します。

精度が 24 より高い場合、REAL8 を使用します。

NUMBER (P,S)

スケールが 0 未満の場合、REAL8 を使用します。

Oracle のソースデータベース設定の「Expose number as」プロパティに従った NUMBER。

スケールが 0 の場合

  • 精度が 0 の場合、REAL8 を使用します。

  • 精度が 2 以上の場合、INT1 を使用します。

  • 精度が 2 より大きく 4 以下の場合、INT2 を使用します。

  • 精度が 4 より大きく 9 以下の場合、INT4 を使用します。

  • 精度が 9 より大きい場合、NUMERIC を使用します。

  • 精度がスケール以上の場合、NUMERIC を使用します。

他のいずれの場合も、REAL8 を使用します。

DATE

DATETIME

INTERVAL_YEAR TO MONTH

STRING (間隔 year_to_month を指定)

INTERVAL_DAY TO SECOND

STRING (間隔 day_to_second を指定)

TIME

DATETIME

TIMESTAMP

DATETIME

TIMESTAMP WITH TIME ZONE

STRING (timestamp_with_timezone を指定)

TIMESTAMP WITH LOCAL TIME ZONE

STRING (timestamp_with_local_ timezone を指定)

CHAR

STRING

VARCHAR2

STRING

NCHAR

WSTRING

NVARCHAR2

WSTRING

RAW

BYTES

REAL

REAL8

BLOB

BLOB

AWS DMS でこのデータ型を使用する場合は、特定のタスク用に BLOB データ型の使用を有効にする必要があります。AWS DMS では、プライマリキーを含むテーブルでのみ BLOB データ型がサポートされます。

CLOB

CLOB

AWS DMS でこのデータ型を使用する場合は、特定のタスク用に CLOB データ型の使用を有効にする必要があります。変更データキャプチャ (CDC) の実行中、AWS DMS ではプライマリキーを含むテーブルでのみ CLOB データ型がサポートされます。

NCLOB

NCLOB

AWS DMS でこのデータ型を使用する場合は、特定のタスク用に NCLOB データ型の使用を有効にする必要があります。CDC の実行中、AWS DMS ではプライマリキーを含むテーブルでのみ NCLOB データ型がサポートされます。

LONG

CLOB

LONG データ型は、最適化バッチ適用モード (TurboStream CDC モード) ではサポートされません。AWS DMS でこのデータ型を使用する場合は、特定のタスク用に LOB の使用を有効にする必要があります。CDC の実行中、AWS DMS ではプライマリキーを持つテーブルでのみ LOB データ型がサポートされます。

LONG RAW

BLOB

LONG RAW データ型は、最適化バッチ適用モード (TurboStream CDC モード) ではサポートされません。AWS DMS でこのデータ型を使用する場合は、特定のタスク用に LOB の使用を有効にする必要があります。CDC の実行中、AWS DMS ではプライマリキーを持つテーブルでのみ LOB データ型がサポートされます。

XMLTYPE

CLOB

XMLTYPE データ型のサポートには、(Oracle Instant Client ではなく) フル Oracle クライアントが必要です。ターゲット列が CLOB の場合、フル LOB モードと制限付き LOB モードの両方がサポートされます (ターゲットによって異なります)。

以下のデータ型の列とともにソースとして使用されている Oracle テーブルはサポートされておらず、レプリケートすることができません。これらのデータ型の列をレプリケートすると NULL 列が発生します。

  • BFILE

  • ROWID

  • REF

  • UROWID

  • NESTED TABLE

  • ユーザー定義のデータ型

  • ANYDATA

注記

仮想列はサポートされていません。