Autonomous AI Database上のOracle Data Transformsのディザスタ・リカバリ (2026/09/01)
Autonomous AI Database上のOracle Data Transformsのディザスタ・リカバリ (2026/09/01)
投稿者：Ashish Jain | Senior Principal Product Manager, Autonomous Database
データ統合は、多くの場合、ビジネスにとって重要なプロセスを支えるものです。Oracle Data Transformsをホストするデータベースが利用不能になった場合、チームは変換設計を復旧し、別のリージョンから作業を再開するための、実績のある方法を必要とします。
Oracle Data TransformsはAutonomous AI Databaseに組み込まれています。これにより、Autonomous Data Guardで既に利用可能な災害復旧機能を活用できます。このブログでは、計画されたリージョン間切り替えの手順を説明し、スタンバイが新しいプライマリになったときに、元のプライマリで作成されたData Transformsアーティファクトが利用可能であることを示します。
| このブログで紹介する内容は以下のとおりです。計画された切り替えにより、このテストで使用されたデータ変換プロジェクト、データロード設計、およびジョブ情報は維持されました。ただし、本番環境での処理を再開する前に、接続とネットワークパスの検証が必要です。 |
災害復旧が重要な理由
Data Transforms環境には、単なるジョブのセット以上のものが含まれています。プロジェクト、データロード、データフロー、ワークフロー、接続、変数、スケジュール、ジョブ履歴などが含まれます。これらの成果物は、データパイプラインの構築と運用に必要な作業を表しています。復旧計画は、こうした投資を保護し、地域的な障害発生後にサービスを再開するための明確な道筋をチームに示すものでなければなりません。
データベースの役割移行は、そのプロセスの一部にすぎません。完全な復旧プロセスには、新しいリージョンでのデータ変換へのアクセス、正常な接続、到達可能なソースシステムとターゲットシステム、およびスケジュールされたワークロードの制御された再起動も含まれます。
Data TransformsがAutonomous Database DRをどのように利用するか
Autonomous Data Guardは、Autonomous AI Databaseのピアを維持します。計画的な切り替え時には、ピアがプライマリとなり、以前のプライマリはスタンバイとなります。Data Transforms機能はAutonomous AI Databaseに組み込まれているため、データベースに保存されているリポジトリアーティファクトは、新しいプライマリ上のData Transforms機能から利用できるようになります。
この例では、米国西部（フェニックス）にある Autonomous AI Database Serverless プライマリと、米国東部（アッシュバーン）にあるリージョン間 Autonomous Data Guard ピアを使用します。
前提条件
開始する前に、以下の点を確認してください。
- Autonomous AI Databaseのサーバーレスインスタンスが利用可能であり、プライマリデータベースでData Transformsが有効になっています。
- テナントは対象リージョンに加入しており、ピアデータベースに必要なサービス制限が十分に確保されています。
- ピアを追加して切り替えを実行するために必要なIAM権限をお持ちです。
- プライベートネットワークを使用する場合、対象リージョンには必要なVCN、サブネット、プライベートエンドポイント、DNS、セキュリティルール、および許可リストが揃っている必要があります。
- 切り替え後に確認する必要のあるData Transformsの成果物と接続を特定しました。
- データベースの役割を変更する前に、メンテナンス期間を設け、スケジュールや上流のトリガーを一時停止する計画を立ててください。
1. プライマリデータベースのData Transformsを確認する
まず、アクティブなプライマリデータベースから始め、切り替え後に想定されるオブジェクトを記録します。この例では、プライマリデータ変換環境に、データロードプロジェクト、データロード設計、および完了したジョブエントリが含まれています。
図1. 元のプライマリデータベースに対するDataLoadプロジェクト。
図2．元のプライマリデータベースにおけるデータロード設計。
図3．元のプライマリデータベース上で完了したデータロードジョブ。
2. リージョン間ピアデータベースを追加する
OCIコンソールでAutonomous AI Databaseを開き、「災害復旧」タブを選択して、「ピアデータベースの追加」をクリックします。
対象リージョンとコンパートメントを選択し、災害復旧タイプとしてAutonomous Data Guardを選択します。この例では、リモートリージョンとして米国東部（アッシュバーン）を使用します。プライマリがプライベートエンドポイントを使用している場合は、新しいデータベースに必要なピアリージョン間のネットワーク情報を構成します。
図4. ピアを追加する際に、リモートリージョンとAutonomous Data Guardを選択します。
3. ピアデータベースを確認する
作業リクエストを監視し、ピアデータベースがスタンバイロールとスタンバイ状態を報告するまで待機してください。ピアの作成または更新中は、切り替えを開始しないでください。
図5. クロスリージョンピアは準備完了となり、スタンバイ状態を報告します。
4. 計画された切り替えを実行する
リージョンをまたぐAutonomous Data Guardピアの場合、リモートリージョンのスタンバイデータベースからスイッチオーバーを開始します。開始する前に、Data Transformsスケジュールと、新しい処理を開始する可能性のある外部トリガーを一時停止してください。
- OCIコンソールのリージョンを米国東部（アッシュバーン）に変更し、スタンバイデータベースを開きます。
- データベースにスタンバイロールが表示されていること、およびピア関係が正常であることを確認してください。
- 「役割アクション」または「その他のアクション」メニューから「切り替え」を選択します。
- 確認ダイアログにピアデータベース名を入力し、リクエストを送信してください。
- Ashburnデータベースがプライマリになり、以前のPhoenixプライマリがスタンバイになるまで、災害復旧タブを監視してください。
図6. クロスリージョンスタンバイデータベースからスイッチオーバーを選択します。
図7．役割の移行を開始する前に、データベース名を確認してください。
5. 新しいプライマリでData Transformsを開く
クロスリージョンピアがスタンバイロールの状態にある間は、Data Transformsに接続できません。ロールの移行が完了したら、Ashburnで新しいプライマリデータベースを開きます。ツール構成を選択し、Data Transformsを見つけて、そのデータベースに表示されているURLを使用します。クロスリージョンAutonomous Databaseツールはリージョン固有のURLを使用するため、以前のプライマリのURLを新しいプライマリのアクセスポイントとして使用しないでください。
図8. 新しいプライマリのツール設定ページからのオープンデータ変換。
6. Data Transforms成果物を検証する
新しいプライマリでData Transformsにサインインし、切り替え前に取得したインベントリと環境を比較してください。このテストでは、スタンバイがプライマリになった後も、Ashburnで同じデータロードプロジェクト、データロード設計、およびジョブ情報が利用可能でした。
図9．DataLoadプロジェクトは新しいプライマリで利用可能です。
図10．新しいプライマリ側でも同じデータロード設計が利用可能です。
図11. 関連する仕事の情報は、新しいプライマリで確認できます。
| 結果。このテストでは、この例で使用されているデータ変換リポジトリの成果物が、リージョン間切り替え後も利用可能であることが示されました。ただし、これはすべての接続や外部依存関係が検証なしで準備完了となることを意味するものではありません。 |
切り替え後の接続に関する考慮事項
成果物の可用性と接続準備状況は、異なるチェック項目です。本番ワークロードを再起動する前に、以下の接続タイプを確認してください。
同じAutonomous AI Databaseへの接続
データ更新機能は、同じ Autonomous AI Databaseを明示的に参照している接続を、プライマリロールを持つデータベースを使用するように変換します。これは、ウォレットベースの接続と JDBC URL を含む接続の両方に適用されます。ウォレットをダウンロードするか、新しいプライマリから接続文字列を取得し、接続を更新してテストしてください。
デフォルトのAutonomous AI Database接続
データ変換用に作成されたデフォルトのAutonomous AI Database接続は、役割の移行後もそのまま維持されます。今回のテストでは、変更は必要ありませんでした。実行前に検証してください。ただし、設計上必要な場合を除き、手動で作成したリージョン接続に置き換えないでください。
他の情報源やターゲットとのつながり
新しいリージョンから外部ソースまたはターゲットへのすべての接続を検証します。ネットワーク経路、DNS、プライベートエンドポイント、ファイアウォール、許可リスト、証明書、認証情報、およびサービスの可用性を確認します。新しいプライマリがリモートシステムに到達できない場合でも、接続オブジェクトが存在する可能性があります。
本番を再開する前に
スケジュールを有効にする前に、小規模で管理されたテストを実施してください。
- 重要な接続をそれぞれ開き、接続テストを実行してください。
- 必要なスキーマとデータエンティティが利用可能であることを確認してください。
- 結果が既知の、冪等なデータロードまたはデータフローを実行します。
- ジョブログを確認し、行数または業務管理合計を検証してください。
- スケジュールの状態、タイムゾーン、所有者、および次回の実行時刻を確認してください。
- トリガーとスケジュールを制御された順序で再開し、最初の本番実行を監視します。
まとめ
Autonomous Data Guardは、Data TransformsリポジトリがAutonomous AI Databaseに格納されるため、Data Transformsに強力な災害復旧基盤を提供します。このチュートリアルでは、スタンバイがプライマリになった後、テスト済みのData Transformsプロジェクト、データロード設計、およびジョブ情報が新しいリージョンで利用可能になったという主要な結果を示しています。
本番環境における災害復旧計画では、次のステップに進む必要があります。新しいプライマリにデータ変換URLを使用し、同じターゲットデータベースを明示的に指す接続を更新し、デフォルトのデータベース接続はそのまま維持し、外部ソースとターゲットを検証し、スケジュールを再開する前に制御されたエンドツーエンドテストを実行します。これにより、アーティファクトの可用性が実用的な復旧プロセスへと変わります。
もっと詳しく知る
- リージョン間スタンバイを備えた Autonomous Data Guard について— リージョン間動作、データ変換 URL、ウォレット、接続文字列、およびネットワークに関する考慮事項。
- リージョン間スタンバイ データベースを追加する— 前提条件と、ピアを追加するための OCI コンソールの手順。
- 切り替えを実行する— 計画された地域間役割移行手順。
- Oracle Data Transforms の利用開始— Data Transforms へのアクセスとセットアップに関するガイダンス。
コメント
コメントを投稿