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

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

Oracle データベースは、ミッションクリティカルなアプリケーションをサポートする、よく知られたエンタープライズクラスのデータベースです。このページでは、Oracle データベース環境向けの Backup and DR について説明します。関連するアーキテクチャは、アプリケーション整合性のある永久増分方式で Google Cloudにバックアップします。また、マルチ TB の 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 の場合、一方または両方のソリューションで無効なバックアップが作成される可能性があります。

Oracle アーカイブログの管理

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

要件	ログを管理（キャプチャや切り捨て / パージ）できるシステムは、以前のバックアップソフトウェアか、Backup and DR のいずれか 1 つだけです。
ベストプラクティス	バックアップと 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` を [いいえ] に設定します。
ベストプラクティス	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` が [はい] に設定されていると、次のエラーが発生します。ステージングデバイスからイメージコピーをカタログ化できませんでしたバックアップに失敗しました。他のレガシーバックアッププロダクトと共存させるには、`Do not uncatalog` を [いいえ] に設定したままにします。
理由	デフォルトでは、パラメータ `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. データベースのアプリケーション対応マウントをターゲットホストに実行します。

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 ディスクグループまたはファイルシステムにあります。

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

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）は、NAS ストレージデバイス（TCP/IP 経由でアクセス可能）にある NFS ストレージへのアクセスを高速化し、スケーラビリティを向上させる最適化された 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 の切り替えとリバランスはサポートしていません。

ターゲット 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 データベースのバックアップの前提条件を確認する。