バックアップ/リカバリ アプライアンス上の Oracle 用 Backup and DR サービス

Oracle データベースは、ミッション クリティカルなアプリケーションをサポートする一般的なエンタープライズ クラスのデータベースです。このページでは、Oracle データベース環境向けの Backup and DR サービスについて説明します。関連するアーキテクチャは、アプリケーション整合性のある永久増分バックアップを Google Cloud提供し、マルチテラバイトの Oracle データベースのインスタント リカバリーとクローン作成も可能です。

仕組み

以降のセクションでは、データ キャプチャとデータ復旧のプロセスについて説明します。

データ キャプチャ

  1. Backup and DR エージェントは Oracle サーバーにデプロイされます。

  2. データベース サーバーにステージング ディスクをマウントします。

  3. RMAN 増分 API を呼び出して、変更されたブロックをコピーします。

  4. RMAN 増分マージを呼び出して、新しい仮想完全バックアップを作成します。

  5. データベース サーバーからステージング ディスクをマウント解除します。

  6. Backup and DR が内部スナップショットを取得します。特定時点の合成完全バックアップの準備が完了しました。

データ復旧

Backup and DR は、ISCSI または NFS 経由で書き換え可能なステージング ディスクを即時にマウントし、データベースをオンラインにします。

Oracle バックアップ API

Backup and DR は、次の Oracle API を使用します。

  • RMAN イメージコピー: データファイルの物理構造がすでに存在しているため、データファイルのイメージコピーを高速に復元できます。 RMAN ディレクティブ BACKUP AS COPY により、データベース全体のすべてのデータファイルのイメージコピーが作成され、データファイル形式が保持されます。

  • ASM と CRS API: ASM バックアップ ディスク グループは、ASM と CRS API を使用して管理されます。

  • RMAN アーカイブログ バックアップ API: 生成されたアーカイブログはステージング ディスクにバックアップされ、本番環境のアーカイブの場所からパージされます。

Backup and DR サービスを他のバックアップ プロダクトで使用する場合の競合を最小限に抑える

Backup and DR サービスは、本番環境データベースからデータをキャプチャするレガシー プロダクトと共存できます。次のベスト プラクティスは、エクスペリエンスの向上に役立ちます。

Oracle データベースのバックアップ スケジュール

ベスト プラクティス レガシー バックアップ ソフトウェアが完了する時間に Backup and DR サービス データベース バックアップ ジョブが開始されるようにスケジュールします。 Backup and DR サービス データベース バックアップ ジョブが正常に完了した直後に、レガシー バックアップ ソフトウェアが実行されるようにスケジュールしないでください。
理由 レガシー バックアップ ジョブと Backup and DR サービス データベース バックアップ ジョブが同時に実行されると、データベース サーバーのパフォーマンスに深刻な影響が生じ、不安定になったり、停止したりする可能性があります。また、 Oracle の場合、一方または両方のソリューションで無効なバックアップが発生する可能性があります。

Oracle アーカイブログの管理

Oracle は、データベース バックアップ中に生成されたアーカイブログを使用して、そのバックアップの整合性と復元可能性を確保します。そのため、データベース バックアップ ジョブ中にアーカイブログがパージされると、そのバックアップ コピーは復元できません。

要件 ログを管理（キャプチャや切り捨て / パージ）できるシステムは 1 つだけです。レガシー バックアップ ソフトウェアまたは Backup and DR サービスのいずれかです。
ベスト プラクティス Backup and DR ジョブの実行中に Oracle アーカイブログがパージされないようにします。 また、レガシー バックアップ RMAN ジョブの実行中に Backup and DR サービスがアーカイブログをパージしないようにします。
レガシー ソフトウェアがアーカイブログを管理している場合は、アーカイブログ パージ ジョブを Backup and DR バックアップ ジョブの開始時にレガシー バックアップ ソフトウェアで無効にし、終了時にパージ ジョブを再開するか、パージする前にアーカイブログを 24 時間以上保持します。
理由 データベース バックアップ ジョブ中にアーカイブログがパージされると、そのデータベース バックアップは復元できなくなる可能性があります。

RMAN メタデータがレガシー バックアップと競合し、Backup and DR サービス バックアップが古くなる

デフォルトでは、Backup and DR サービスのアプリケーションの詳細と設定のパラメータ DO NOT UNCATALOG は [No] に設定されています。Backup and DR データファイル バックアップは、バックアップの開始時にカタログ化され、ジョブの終了時にカタログから削除されます。これを [Yes] に設定すると、各バックアップ ジョブの後に RMAN データファイル バックアップがカタログ化されたままになるため、データファイル数の多いデータベースのバックアップ時間を最適化できます。ただし、他のバックアップ プロダクトと競合します。

要件 Backup and DR アプリケーションの詳細と設定のパラメータ Do not uncatalog を [No] に設定します。
ベスト プラクティス Backup and DR サービス データベース バックアップは永久増分方式です。これは 、RMAN 増分マージ API で RMAN イメージコピーを使用することで実現されます。 最初の RMAN バックアップは、Backup and DR バックアップ ディスク上のデータベース データファイルの完全なイメージコピーで、バックアップ ディスクの内部スナップショットが含まれています。 以降の RMAN 増分バックアップは、Backup and DR バックアップ ディスクで RMAN 増分 マージを使用して実行され、スナップショットの前に増分変更で最後の完全バックアップが更新されます。ただし、サードパーティの データベース バックアップまたはバックアップのクロスチェックが Backup and DR データベース バックアップの後に実行されると、 Backup and DR バックアップのすべてのバックアップ データファイルが RMAN メタデータで古いものとしてマークされます。 Backup and DR アプリケーションの詳細と設定のパラメータ Do not uncatalog を [Yes] に設定すると、次のエラーが発生します: Failed to catalog image copies from staging device バックアップが失敗します。他のレガシー バックアップ プロダクトと共存するには、Do not uncatalog を [No] に設定したままにします。
理由 デフォルトでは、パラメータ Do not uncatalog> in Backup and DR application details & settings is set to No. Setting this to Yes interferes with other backup products.

Oracle データベースのブロック変更トラッキング（BCT）

Oracle ブロック変更トラッキングを使用すると、変更されたブロックを特定することで、データベースのバックアップを高速化できます。バックアップ オペレーションには、変更されたブロックのみが含まれます。

  • Backup and DR サービスの永久増分方式は、BCT が有効または無効になっているデータベースをサポートしています。BCT が有効になっていない場合、増分バックアップの時間が長くなります。

  • 変更ブロックのトラッキングは、データベース レベルで有効になります。

  • Oracle は、各データファイルの変更されたブロックをトラッキング ファイルに記録します。これは、データベース領域に保存される小さなバイナリ ファイルです。

  • BCT が有効になっている場合、RMAN は BCT ファイルを使用して、増分バックアップの変更されたブロックを取得します。

  • データベースで変更ブロックのトラッキングが有効になっていない場合、RMAN は増分バックアップ中にデータベース内のすべてのデータファイルの各ブロックをスキャンします。

Backup and DR 整合性グループで Oracle データベースを保護する

ほとんどの構成では、整合性グループに 1 つの Oracle データベース アプリケーションと、Oracle サーバーの任意の数のファイル システム アプリケーションを含めることができます。整合性グループは、テスト開発やその他のビジネス アジリティのユースケースで Oracle データベースを使用する場合におすすめです。

TDE を使用する Oracle データベース

Backup and DR サービスは、さまざまな構成の Oracle データベースに対して、さまざまなキャプチャ方法とプレゼンテーション方法をサポートしています。これには、透過的データ暗号化（TDE）が構成された Oracle データベースのバックアップ、復元、Application Aware マウント オペレーションが含まれます。

TDE を使用する Oracle データベースの場合、ソース バックアップ ホストのウォレット ファイルは、Application Aware マウントのターゲット ホストで使用可能にする必要があります。これは、いくつかの方法で実現できます。

  • ウォレット ファイルをバックアップ ソース サーバーからターゲット マウント サーバーにコピーし、Oracle がアクセスできるように構成します。
  • Oracle ウォレット ファイルがネットワーク上の共有デバイスに保存されている場合は、Appaware マウント ターゲットの Oracle インスタンスがアクセスできるように構成する必要があります。

  • Oracle 構成ファイルの場所の詳細設定を設定して、Backup and DR サービス バックアップ中に Oracle ウォレット ファイルがキャプチャされた場合は、次の手順でウォレット ファイルを取得できます。

    1. データベースをターゲット ホストに標準マウント します。
    2. ウォレット ファイルを標準データベース マウントからターゲット ホストにコピーし、Oracle が使用するように構成します。
    3. データベースをマウント解除します ターゲット ホストから。
    4. データベースの Application Aware マウント をターゲット ホストに対して実行します。

Oracle Exadata データベースまたは Oracle ExaCC を使用した Backup and DR

バックアップ/リカバリ アプライアンスは、iSCSI または Oracle dNFS プロトコルを介した Exadata データのキャプチャとプレゼンテーションをサポートしています。

  • バックアップ/リカバリ アプライアンスは、ネットワーク（データパス内ではない）で iSCSI または Oracle dNFS 経由で接続されます。

  • RMAN バックアップは、RMAN を使用して、Backup and DR によってファイル システムまたは ASM ディスク グループとして提示されたコピー データストアに直接書き込みます。

  • データ キャプチャ形式: ASM disk group（iSCSI のみ）または ファイル システム（dNFS または iSCSI）。

  • Backup and DR の永久増分方式バックアップでは、 RMAN incrementally updated backups を使用して、イメージコピー バックアップをロールフォワードします。

Backup and DR による Exadata データと ExaCC のキャプチャ

バックアップ/リカバリ アプライアンスとの通信を容易にし、データベース バックアップ用の RMAN API を呼び出すには、Backup and DR エージェントを Exadata サーバーにインストールする必要があります。

Backup and DR エージェントは、Backup and DR ディスクを iSCSI ターゲットとして Exadata サーバーに公開してマッピングします。データ キャプチャ形式は、[ASM disk group] または [ファイル システム] になります。

ユーザー空間の各 Exadata ホストに Backup and DR エージェントをインストールして、バックアップ/リカバリ アプライアンスとの通信を容易にし、データベース バックアップ用の RMAN API を呼び出します。

ASM ディスク グループのキャプチャ形式

バックアップ中、Backup and DR エージェントは次の処理を行います。

  1. 論理ディスクを iSCSI ターゲットとして Exadata サーバーにマッピングして公開します。

  2. Backup and DR ディスクパスを ASM ディスク文字列に追加します。

  3. ASM ディスク文字列がパラメータ ファイルに追加され、CRS プロファイルに存在しないことを確認します。

  4. Backup and DR ディスクを使用して、外部冗長性として ASM ディスク グループを作成します。

    • RMAN を使用して、バックアップ/リカバリ アプライアンスによって ASM ディスク グループまたはファイル システムとして提示されたコピー データストアに直接書き込む RMAN バックアップ。

    • RMAN incrementally updated backupsを使用して、 イメージコピー バックアップをロールフォワードする永久増分方式バックアップ。

dNFS を使用したファイル システムのキャプチャ形式

Oracle Direct NFS（dNFS）は、最適化された NFS（ネットワーク ファイル システム）クライアントです。これにより、NAS ストレージ デバイス（TCP/IP 経由でアクセス可能）にある NFS ストレージへのアクセスが高速化され、スケーラビリティが向上します。Direct NFS は、ASM と同様にデータベース カーネルに直接組み込まれています。

dNFS プロトコルは、NFS 共有としてファイル システム ベースのバックアップに使用できます。

Backup and DR エージェントは、Backup and DR ディスクを NFS 共有として Exadata サーバーに公開してマッピングします。

Exadata サーバーでの dNFS の前提条件:

  • Exadata サーバーで dNFS を有効にします。

    cd $ORACLE_HOME/rdbms/lib make -f ins_rdbms.mk nfs on

  • データベースを再起動します。

    RMAN API を使用して、バックアップ/リカバリ アプライアンスによって提示された dNFS 共有のファイル システムにデータベースをバックアップします。

ターゲット DB サーバーの再起動後に Backup and DR で保護された ASM ディスク グループをオンラインに戻す

Backup and DR コピーがマウントされているデータベース サーバーを再起動した場合、または再起動/クラッシュ時にデータベースの Backup and DR バックアップが進行中の場合は、次の手順で Backup and DR ディスク グループのマウントを復元します。

  1. ターゲット データベース サーバーがバックアップされ、ASM システムと RAC システムも起動していることを確認します。

  2. Backup and DR エージェントを再起動します（root から）。

  3. ASM 環境を設定します。

  4. ASM sqlplus にログインして、ディスク グループのステータスを確認します。

    select name, state from v$asm_diskgroup where name = '<dg name>';)

  5. マウントされていない場合は、ディスク グループをマウントします: alter diskgroup <dg name> mount;

  6. Oracle OS にログインしてデータベース環境を設定し、データベースを起動します。

次のステップ

Oracle データベースのバックアップの前提条件を確認する。

Backup and DR（Oracle 向け）のその他のドキュメント