Google は AI 技術を使用して、コンテンツをご希望の言語に翻訳しています。AI 翻訳には誤りが含まれる場合があります。

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

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

仕組み

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

データキャプチャ

Backup and DR エージェントは Oracle サーバーにデプロイされています。
ステージングディスクをデータベースサーバーにマウントします。
RMAN 増分 API を呼び出して、変更されたブロックをコピーします。
RMAN 増分マージを呼び出して、新しい仮想フルを作成します。
データベースサーバーからステージングディスクのマウントを解除します。
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 の場合は、1 つまたは両方のソリューションで無効なバックアップが発生する可能性があります。

Oracle アーカイブログの管理

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

要件	ログを管理（キャプチャや切り捨て / パージ）できるシステムは、以前のバックアップソフトウェアか Backup and DR のいずれか 1 つだけです。
ベストプラクティス	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 データファイルのバックアップは、バックアップの開始時にカタログ化され、ジョブの終了時にカタログ化解除されます。これを [はい] に設定すると、各バックアップジョブの後に RMAN データファイルバックアップカタログが保持されるため、データファイルが多数あるデータベースのバックアップ時間が最適化されます。ただし、他のバックアッププロダクトと競合します。

要件	Backup and DR アプリケーションの詳細と設定パラメータ `Do not uncatalog` を [No] に設定します。
ベストプラクティス	Backup and DR のデータベースバックアップは永久増分方式です。これは、RMAN 増分マージ API で RMAN イメージコピーを使用することで実現されます。最初の RMAN バックアップは、Backup and DR のバックアップディスク上のデータベースデータファイルの完全なイメージコピーであり、バックアップディスクの内部スナップショットを含みます。後続の RMAN 増分バックアップは、Backup and DR バックアップディスクで RMAN 増分マージを実行し、スナップショットの前に増分変更で最後のフルバックアップを更新します。ただし、バックアップと DR のデータベースバックアップの後に、サードパーティのデータベースバックアップまたはバックアップのクロスチェックが実行されると、バックアップと 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 データベースのバックアップ、復元、アプリケーション認識マウントオペレーションが含まれます。

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 ディスクグループ]（iSCSI のみ）または [ファイルシステム]（dNFS または iSCSI）。
Backup and DR の永久増分方式バックアップでは、RMAN の増分更新バックアップを使用して、イメージコピーバックアップをロールフォワードします。

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

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

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

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

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

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

論理ディスクを iSCSI ターゲットとして Exadata サーバーにマッピングして公開します。
Backup and DR のディスクパスを ASM ディスク文字列に追加します。
ASM ディスク文字列がパラメータファイルに追加され、CRS プロファイルに存在しないことを確認します。
Backup and DR ディスクを使用して、外部冗長性として ASM ディスクグループを作成します。
- RMAN を使用して、バックアップ/リカバリアプライアンスによって ASM ディスクグループまたはファイルシステムとして提示されたコピーデータストアに直接書き込む RMAN バックアップ。
- RMAN の増分更新バックアップと、イメージコピーバックアップのロールフォワードを使用した永久増分方式バックアップ。

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 共有のファイルシステムにデータベースをバックアップします。

注: dNFS はファイルシステムでのバックアップのみをサポートします。ASM Switch & Rebalance はサポートしていません。

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

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

ターゲットデータベースサーバーがバックアップされ、ASM と RAC システムも稼働していることを確認します。
Backup and DR エージェントを再起動します（root から）。
ASM 環境を設定します。
ASM sqlplus にログインして、ディスクグループのステータスを確認します。
```
select name, state from v$asm_diskgroup where name = '<dg name>';)
```
マウントされていない場合は、ディスクグループをマウントします。alter diskgroup <dg name> mount;
Oracle OS にログインしてデータベース環境を設定し、データベースを起動します。

次のステップ

Oracle データベースのバックアップの前提条件をご覧ください。