Amazon Web Services ブログ

異機種間のSAP移行におけるOracle XTTS方式によるダウンタイム削減

Oracle DatabaseでSAPアプリケーションを稼働している組織には、あるオペレーティングシステムから他のオペレーティングシステムに移行するための多くの方法が用意されています。オンプレミスのOracle DatabaseとSAPアプリケーションのAWS移行を検討しているお客様は、”ビッグエンディアン”のプラットフォームでホストされているオンプレミスから”リトルエンディアン”にリプラットフォームしなければならない場合があります。異機種間の移行にあたるため、このタイプの移行には、従来の移行方式 (R3load/Jload)を選択することが多いです。

ソースデータベースのサイズ、ハードウェアとデータ転送速度などの要素によって、ダウンタイムは長くなる可能性があります。差分マージができるオラクルのCross-Platform Transportable Tablespaces (XTTS、クロスプラットフォームトランスポータブル表領域)方式を使うことで、このダウンタイムを数日から数時間に短縮できます。この短いダウンタイムは、ここで述べているようにOracle Golden Gateを使っても実現できますが、このアプローチだとGolden Gateのソフトウェア利用に関する重要なライセンス上の影響を考慮する必要があります。

このブログでは、AWSへの異機種間のSAP移行において、どのようにオラクルのCross-Platform Transportable Tablespaces (XTTS)方式を活用でき、また、どのようにカットオーバー時のダウンタイムを削減できるかを紹介します。

移行概要:

XTTSは“Cross-Platform Transportable Tablespaces”の略で、ターゲットデータベースに復元する前にエンディアン変換を行う必要があります。このアプローチでは、2つの選択肢があります。

  • バックアップセットを使用して、表領域を転送する
  • 非圧縮のデータファイルを直接コピーする

オンプレミスからAWSへの移行のため、”バックアップセットを使用した表領域の転送”が推奨アプローチです。これにより、一般的な圧縮比率は5:1になります。この圧縮されたバックアップセットを作成する追加の手順は、通常、データ転送処理に必要な時間の短縮に繋がります。

Architecture diagram showing steps for migration.

移行前フェーズ:

  1. AWSアカウントを準備し (例えば、AWS Control TowerやAWS Landing Zoneを使用)、AWS Direct ConnectやS2S VPNを介して、オンプレミスとの接続を確立します
  2. 必要なOracle DBバージョンとSAPアプリケーションをターゲットになるAWS上のサーバーにインストールします
  3. オンプレミスでステージング用のサーバーを構築します (ソースがビッグエンディアンのため)。これはソースシステムのコピーであり、ソースシステムと継続的に同期しています。このステージングサーバーは本稼働データベースの移行関連のエクスポート操作の削減に役立ちます。また、複数回にわたるテスト移行の繰り返しによるビジネスの中断を減らすこともできます。これは、Oracle Data Guardで実現できます。通常、SAPを通じて購入したOracle Databaseに含まれるData Guardのライセンスが必要です。次の手順を使用します。
    • 初回のRMANフルデータベースバックアップを実行し、そのバックアップをステージングサーバーにコピーして、Data Guardデータベースを初期化します
    • Data Guardデータベースをログ適用状況のまま維持します
    • Data Guardでは、ソースデータベースでNOLOGGINGをオンにする必要があります。これをしない場合、NOLOGGINGオブジェクトは移行されず、移行後に手動で再作成する必要があります
  4. ターゲットデータベースでエンディアン変換を実行するための変換スクリプトを用意します。オラクルサポートからテンプレートをダウンロードできます
  5. XTTSは、ソースデータベースのSYSTEMとSYSAUX表領域にあるオブジェクトを転送しません。SYSTEMとSYSAUX表領域にあるメタデータは、Data Pumpを使用して転送する必要があります
  6. もし、ユーザーが所有する表がSYSTEMまたはSYSAUX表領域にある場合は、識別したオブジェクトを事前にユーザー表領域に移動して、オブジェクトをXTTSで転送できるようにします。または、Data Pumpを使用してオブジェクトを個別に移動するか、プラットフォーム移行を実施した後に手動で再作成できます

移行フェーズ:

  • カットオーバー前の作業:
  1. Data Guardデータベースを初期化するために、初回のRMANフルデータベースバックアップを (ステージングデータベース上で)実行します
  2. Data Guardデータベースのログ適用状況を維持します
  3. Data Guardデータベースのフルバックアップをサポートされるエンディアン形式に変換します
    BACKUP
    FOR TRANSPORT
    FORMAT ‘<directory path and format for backup>’
    DATABASE;
  4. Amazon S3、Amazon EFS、あるいはAWS DataSyncを使用して、バックアップをAWSに転送します
  5. 次のコマンドを使用して、ターゲット (AWS)上で復元します
    RESTORE
    FROM PLATFORM ‘Solaris Operating System (x86-64)’
    FOREIGN DATABASE TO NEW
    FROM BACKUPSET ‘<Backup file path>’;
  6. 定期的にスケジュール (ソースシステムの変更に応じて、6時間ごと、日次、週次など)された増分バックアップとData Guardデータベースのエンディアン変換を行う自動化スクリプトを有効にし、これらの増分バックアップをターゲットに転送して、ソースとターゲットDBを継続的かつ自動的に同期します
  • カットオーバー作業:
  1. Data Guardでステージングデータベースの表領域を読み取り専用にします
  2. 最後の増分バックアップを作成します
    BACKUP
    FOR TRANSPORT
    FORMAT ‘<directory path and format for backup>’
    DATABASE;
  3. Amazon S3、Amazon EFS、あるいはAWS DataSyncを使用して、バックアップをAWSに転送します
  4. 増分バックアップを変換し、データベースを復元します
    RESTORE
    FROM PLATFORM ‘Solaris Operating System (x86-64)’
    FOREIGN DATABASE TO NEW
    FROM BACKUPSET ‘<Backup file path>’;
  5. 表領域のメタデータをバックアップし、Data Pumpのエクスポートユーティリティ expdp/impdpを使用してターゲットDBを復元します
  6. これで、データベース関連の移行作業は完了です。次の手順は、データベースを起動し、SAP固有の移行後処理を実行します

結論

このブログでは、増分マージができるOracle XTTS方式を使用して異機種間のSAP移行のダウンタイムを削減する方法の概要を紹介しました。カットオーバー中の停止/ダウンタイムは、最後の増分バックアップのサイズ、メタデータの量、データ転送のためのオンプレミスDCとAWS間のネットワーク速度など、様々な要因によって変わります。

紹介したアプローチを使用することで、とあるお客様の重要な16TB規模のSAPワークロードを、オンプレミスのAIX/OracleからAWS上のOEL/Oracleに、24時間のカットオーバーウィンドウで移行することができました。稼働開始の1週間前に、ソースシステムのフルバックアップを使用してターゲットデータベースを復元しておきました。1GbpsのAWS Direct Connectを活用し、日次で増分バックアップをAWSに転送しました。カットオーバー中は、最後の増分バックアップを約8時間で復元しました。これには、ソースシステムの停止、最後の増分バックアップの実行、エンディアンの変換、AWSへのデータ転送、ターゲットデータベースでのDBの復元を含みます。このアプローチで、ビジネス的に新しいシステムに移行するために要求された範囲内で、カットオーバーの作業を実行するための十分な時間を提供できました。

これは複雑なプロセスなため、もしこのアプローチを使用した移行の予定がある場合は、Oracle DBAを参画させてください。ご意見やご質問がありましたら、お気軽にお問い合わせください。フィードバックをお待ちしています。

翻訳はPartner SA 河原が担当しました。原文はこちらです。