Amazon Web Services ブログ

AWS DMS が Amazon RDS for Oracle および Oracle スタンバイ向けの Binary Reader をソースとするサポートを開始

 

Amazon RDS for Oracle および Oracle Active Data Guard スタンバイ向けの Binary Reader を、AWS Database Migration Service (AWS DMS) での移行のソースとしてサポートすることをお知らせします。

AWS DMS は、データベースを AWS に迅速かつ比較的安全に移行するのに役立ちます。AWS 内でデータを移行するのにも役立ちます。Oracle、Microsoft SQL Server、PostgreSQL など、最も広く使用されている商用データベースとオープンソースデータベースの間でデータを移行できます。このサービスでは、Oracle から Oracle のような同種移行をサポートします。また、Oracle から Amazon Aurora MySQL、Oracle から Amazon RDS for MySQL など、異なるデータベースプラットフォーム間の異種移行もサポートします。

今回のブログ記事では、Amazon RDS for Oracle で Binary Reader を備えた AWS DMS を使用する方法の概要をご紹介します。Oracle Active Data Guard スタンバイを移行のソースとして使用する場合にも、同じ手順が適用されます。

背景

AWS DMS は異種移行向けに設計されていますが、同種移行もサポートします。この設計ではレプリケーションのために、アーカイブ、REDO、トランザクション、バイナリー、オペレーションログにアクセスしてソースインスタンスの進行中の変更をキャプチャする必要があります。

Oracle をソースとして使用する場合、進行中の変更をレプリケートするために、AWS DMS ではログを読み取る 2 つの方法を提供しています。それが Oracle LogMiner と Binary Reader です。

AWS DMS ではデフォルトで、変更データキャプチャ (CDC) 向けの Oracle LogMiner を使用します。また、Oracle Binary Reader を使用することもできます。Binary Reader は LogMiner をバイパスし、ログを直接読み取ります。AWS DMS で LogMiner ではなく Binary Reader を使用する際の利点として、以下のことが挙げられます。

  • 変更量の多い移行の場合、LogMiner は、Oracle ソースデータベースをホストするコンピュータの I/O または CPU に影響を与える可能性があります。複数のタスクを同じソースからレプリケートする場合、Oracle LogMiner を使用すると効率が低下します。この効率の低下は、LogMiner がデータベースを使用して REDO ログにアクセスし、それにより追加のデータベースリソースを消費するために発生します。Binary Reader では、 I/O または CPU に影響を与える可能性が低くなります。
  • 大量の変更を含む移行では、Oracle LogMiner を使用するより Binary Reader を使用する方が、CDC のパフォーマンスは通常ははるかに高くなります。大量の変更については以下のように定義します。
    • REDO ログの変更量が 30 GB/時間を超える。
    • 変更量が 10 GB/時間から 30 GB/時間の間であり、変更をできるだけ速く処理 (ターゲットにレプリケート) する必要がある。
  • Binary Reader では、Oracle バージョン 12c で LOBS 向けの CDC をサポートしますが、LogMiner ではサポートしません。
  • Binary Reader は、Oracle transparent data encryption (TDE) を使用する Oracle ソースで使用できます。
  • Binary Reader では、全ロードと継続的レプリケーション用に以下の HCC 圧縮タイプをサポートします。
    • QUERY HIGH
    • ARCHIVE HIGH
    • ARCHIVE LOW
  • Binary Reader は、全ロード移行の場合にのみ、QUERY LOW の圧縮タイプをサポートします。
  • Binary Reader は、Basic および OLTP 圧縮もサポートします。
  • Binary Reader は、Oracle PDB データベースからの移行をサポートします。LogMiner ではサポートしません。

Binary Reader は LogMiner と比較してパフォーマンスがかなり高く、Oracle サーバーの負荷を軽減します。

AWS DMS は、ソースデータベースの [ALL_DIRECTORIES] テーブルにサーバーレベルのディレクトリを作成して、Binary Reader を使用します。このテーブルには、REDO ログのあるエントリと、アーカイブログが生成され格納されているエントリの 2 つのエントリが確認できます。ほとんどの場合、アーカイブログのロケーションは、[USE_DB_RECOVERY_FILE_DEST] で示すディレクトリのロケーションです。

RDS for Oracle を AWS DMS の CDC 向け Binary Reader で ソースとして使用する

以下では、AWS DMS の CDC に Binary Reader を使用する場合のソースとしての RDS for Oracle の前提条件と設定の手順をご覧ください。

前提条件

  1. Binary Reader の設定にはマスターユーザーを使用し、DMS での移行にも同じマスターユーザーを使用してください。
  2. トランザクションログへのアクセスは、RDS for Oracle バージョン 11.2.0.4.v11 以降および 12.1.0.2.v7 以降でサポートされています。

設定

  1. マスターユーザーとして RDS for Oracle にサインインする。
  2. RDS ユーザーガイドに記載されている以下のストアドプロシージャを実行して、サーバーレベルのディレクトリを作成します。
    exec rdsadmin.rdsadmin_master_util.create_archivelog_dir;
    exec rdsadmin.rdsadmin_master_util.create_onlinelog_dir;

    これを行うと、以下のパスを持つディレクトリが作成されます。

  3. 以下のクエリを使用して、REDO ログおよびアーカイブログのロケーションを決定します。
    REDO ログ
    SELECT * FROM V$LOGFILE;
    
    アーカイブログ
    SELECT * FROM V$ARCHIVED_LOG;

    REDO ログが格納されているパスは、次のようになります。

    アーカイブログが格納されているパスは、次のようになります。

    上記のパスは基本的に、RDS for Oracle インスタンスの作成時に作られたデータベース名とシンボリックリンクです。例を以下に示します。

    REDO ログ: /rdsdbdata/db/{$DATABASE_NAME}_A/onlinelog
    
    アーカイブログ: /rdsdbdata/db/{$DATABASE_NAME}_A/arch

    上記のスクリーンショットでは、データベース名は ORCL です。

  4. Oracle ソースエンドポイントを作成します。エンドポイントを作成する際は、追加の接続属性フィールドに次のように入力します。
    useLogminerReader=N;useBfile=Y;accessAlternateDirectly=false
    ;useAlternateFolderForOnline=true;oraclePathPrefix=/rdsdbdata/db/ORCL_A/
    ;usePathPrefix=/rdsdbdata/log/;replacePathPrefix=true

    上記では、ORCL を RDS for Oracle のデータベース名に置き換えています。

  5. 完了したら、 [接続テスト] を作成して接続が確立されたことを確認します。

AWS DMS の CDC 向け Binary Reader で Oracle スタンバイをソースとして使用する

以下では、AWS DMS の CDS に Binary Reader を使用する場合のソースとしての Oracle スタンバイの前提条件と設定の手順をご覧ください。

前提条件

  1. Oracle ユーザーには、[CREATE ANY DIRECTORIES] のシステム権限が必要です。
  2. AWS DMS では現在、Oracle Active Data Guard スタンバイのみの使用をサポートしています。

設定

  1. [CREATE ANY DIRECTORIES] のシステム権限を持つユーザーが、スタンバイインスタンスのプライマリサーバーにログインします。
  2. 以下のクエリを使用して、REDO ログおよびアーカイブログのロケーションを決定します。
    REDO ログ
    SELECT * FROM V$LOGFILE;
    
    アーカイブログ
    SELECT * FROM V$ARCHIVED_LOG;
  3. 上記のアウトプットに基づき、以下のコマンドを使用してディレクトリを作成します。
    CREATE OR REPLACE DIRECTORY "DMS_MIGRATION_REDO" AS '<<REDO_LOG_LOCATION>>'
    
    CREATE OR REPLACE DIRECTORY "DMS_MIGRATION_ARCHIVE" AS '<<ARCHIVE_LOG_LOCATION>>'
  4. サーバーレベルのディレクトリが作成されたら、[ALL_DIRECTORIES] テーブルをクエリして、それが正しいことを確認します。
  5. 確認できたら、プライマリサーバーのアーカイブログスイッチを実行します。これにより、[ALL_DIRECTORIES] への変更もスタンバイに受け渡されます。
  6. スタンバイのこのテーブルをクエリして、変更が適用されたことを確認します。
  7. AWS DMS マネジメントコンソールまたは AWS CLI を使用して Oracle スタンバイのソースエンドポイントを作成します。エンドポイントを作成する際は、追加の接続属性を次のように指定します。
    useLogminerReader=N;useBfile=Y;archivedLogDestId=1;additionalArchivedLogDestId=2
  8. 完了したら、 [接続テスト] を作成して接続が確立されたことを確認します。

この設定が完了すると、ターゲットエンドポイントと移行タスクを作成して、RDS for Oracle ソースインスタンスからサポートされるいずれかのターゲットに移行できます。Oracle から PostgreSQL への移行を紹介するステップバイステップの例については、AWS DMS ステップバイステップの移行ガイドOracle Database から PostgreSQL に移行するを参照してください。

注意: DMS では、REDO ログではなくアーカイブログから移行するかどうかを指定できます。詳細については、AWS DMS ユーザーガイド追加の接続属性セクションを参照してください。

結論

今回のリリースにより、RDS for Oracle からデータを継続的にストリームすることが可能になりました。また、プライマルサーバーをオーバーロードさせることなく、AWS DMS がサポートするすべてのターゲットのソースとして Oracle スタンバイを使用できます。この新しいソースサポートにより、データを新しい方法でレプリケートし、さらなる処理のために複数のロケーションでデータを利用でます。

ご質問またはご提案については、以下にコメントを残してください。

移行がうまくいきますように!


著者について

Abhinav Singh はアマゾン ウェブ サービスの Database Migration Service のデータベースエンジニアです。 AWS の顧客と協力してデータベースプロジェクトに関する助言や技術支援を行い、AWS を使用する場面でソリューションの価値を向上させる手助けをしています。