Oracle AI Database 23.26.2では、単一のData Guard Brokerコマンドでスタンバイ・プラガブル・データベース（PDB）とそのredoログを立ち上げることができ、これまで災害復旧（DR）のセットアップを遅らせていた「手動でのファイルコピー」というルーチンを排除できます。

なぜこれが重要なのか

物理スタンバイPDBの作成には、一連の手動操作が必要でした。すべてのデータファイルをスタンバイ・コンテナにコピーし、明示的なALTERコマンドを使用してスタンバイredoログ（SRL）を構築し、構成全体を再確認するという作業です。各ステップには、タイポ、ファイルの漏れ、またはロググループの不一致といったリスクが伴い、それらはリカバリテストの遅延や、最悪の場合、フェイルオーバーの失敗を招く可能性があります。プロセスを自動化することで、これらのリスクを軽減し、DBAがより高度なタスクに集中できるようになります。

これまでのスタンバイPDBの構築方法

マルチテナント・アーキテクチャでは、プライマリCDB（コンテナ・データベース）が1つ以上のPDBをホストします。PDBを保護するために、管理者は以下の作業を行う必要がありました。

  • プライマリからスタンバイ・ホストへ、各データファイルを特定してコピーする。
  • プライマリのredoログのレイアウトを反映したSRLを手動で作成する。
  • RMANのリストアまたはduplicateコマンドを実行して、スタンバイを同期させる。
  • スタンバイがswitchoverを受け入れられることを確認するために、一連の検証ステップを実行する。

このワークフローは、特に大規模なPDBの場合、数時間に及ぶことがあり、わずかなミスがスタンバイを使い物にならなくさせる可能性もありました。

23.26.2アップデートの内容

最新のOracle AI Databaseリリースでは、必要なステップがData Guard Brokerに組み込まれています。単一の ADD PLUGGABLE DATABASE ステートメントを発行するだけで、ブローカーは以下の処理を行います。

  1. 新しいスタンバイPDBをプライマリに登録する。
  2. 裏側で必要なデータファイルをコピーする（RMANのリストアや手動のファイルコピーは不要）。
  3. 適切なスタンバイredoログを生成し、スタンバイCDBに自動的に追加する。
  4. PDBをREAD ONLYモードのままにし、物理スタンバイのswitchoverができる状態にする。

テストで使用されたコマンドは以下の通りです：

DGMGRL> ADD PLUGGABLE DATABASE 'amol' AT cdb2
       SOURCE IS 'amol' AT cdb1
       PDBFILENAMECONVERT IS "'/CDB1/','/CDB2/'";

実環境でのテスト

著者は、cdb1上のプライマリPDBをミラーリングするセカンダリCDB（cdb2）上に、AMOLという名前のスタンバイPDBを作成しました。ブローカーは操作を即座に完了しました。RMANのリストアは実行されず、OSログに手動のファイルコピーも現れず、ALTER DATABASE ステートメントを使用することなく、スタンバイredoログ・グループがカタログに表示されました。

PDBを開くとREAD ONLYに切り替わり、物理スタンバイの状態であることが確認できました。データファイルを素早くチェックしたところ、スタンバイ側にプロビジョニングされていることが証明されました。Redo applyはすでに実行されており、ブローカーは構成がswitchoverの準備ができていることを報告しました。

DBAへの影響

自動化により、ヒューマンエラーの可能性が減少し、計画から本番スタンバイまでの時間が大幅に短縮されます。チームは、スタンバイPDBを数時間ではなく数分でプロビジョニングできるようになり、これは新しいサービスを頻繁に立ち上げる環境において特に価値があります。

トレードオフとして、Data Guard Brokerの内部ロジックへの依存度が高まります。きめ細かな制御を維持したり、カスタム監視ツールと統合したりするために、各ステップを自身でスクリプト化することを好むDBAもいます。マルチネットワーク、異種ストレージ、または非標準のredoレイアウトといった複雑なセットアップでは、管理者は依然として、ブローカーのデフォルト設定が自社のポリシーに沿っているかを確認する必要があるかもしれません。

今後の注目点

Oracleはこの自動化のさらなる拡張を発表していませんが、この動きは、将来のリリースでマルチテナントのDRワークフローのより多くの部分がブローカーに組み込まれる可能性を示唆しています。以下の点に注目してください：

  • 追加のスタンバイタイプ（例：ロジカル・スタンバイPDB）のサポート。
  • 監査目的でブローカーの決定内容を明らかにする、拡張されたロギング。
  • 以前は手動のRMANステップに依存していたサードパーティ製バックアップツールとの互換性チェック。

組織で高可用性構成でOracle AI Databaseを運用している場合は、非本番環境のCDBで新しいコマンドをテストすることが、影響を評価する最も早い方法です。

まとめ: Oracle AI Database 23.26.2は、多段階でエラーが発生しやすいスタンバイPDBのセットアップを単一のコマンド操作へと変え、マルチテナント環境に対して、より迅速で信頼性の高い災害復旧を実現します。