このページは Cloud Translation API によって翻訳されました。

Oracle のバックアップと DR サービス

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

仕組み

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

データキャプチャ

Backup and DR エージェントが Oracle サーバーにデプロイされている。
データベースサーバーにステージングディスクをマウントします。
RMAN 増分 API を呼び出して、変更されたブロックをコピーします。
RMAN 増分マージを呼び出して、新しい仮想フルを作成します。
データベースサーバーからステージングディスクのマウントを解除します。
バックアップと DR が内部スナップショットを取得します。特定時点の合成フルが準備完了です。

データ復旧

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

Oracle バックアップ API

バックアップと DR では、次の Oracle API が使用されます。

RMAN イメージコピー: データファイルの物理構造がすでに存在しているため、データファイルのイメージコピーを高速に復元できます。RMAN ディレクティブ BACKUP AS COPY により、データベース全体のすべてのデータファイルのイメージコピーが作成され、データファイル形式が保持されます。
ASM と CRS API: ASM バックアップディスクグループは、ASM と CRS API を使用して管理されます。
RMAN アーカイブログバックアップ API: 生成されたアーカイブログはステージングディスクにバックアップされ、本番環境のアーカイブの場所からパージされます。

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

バックアップと DR サービスは、本番環境データベースからデータをキャプチャする従来のプロダクトと共存できます。以下のベストプラクティスは、エクスペリエンスの向上に役立ちます。

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

ベストプラクティス

以前のバックアップソフトウェアが完了する時間に開始するように、バックアップと DR サービスのデータベースバックアップジョブをスケジュールします。バックアップと DR サービスのデータベースバックアップジョブが正常に完了した直後に、以前のバックアップソフトウェアを実行するようにスケジュールしないでください。

理由

従来のバックアップジョブとバックアップと DR サービスのデータベースバックアップジョブが同時に実行されると、データベースサーバーのパフォーマンスに重大な影響を与え、不安定になり、停止する可能性があります。また、Oracle の場合、1 つまたは両方のソリューションのバックアップイメージが無効になる可能性があります。

Oracle アーカイブログの管理

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

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

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

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

要件	[Backup and DR application details & settings] パラメータ `Do not uncatalog` を [No] に設定します。
ベストプラクティス	Backup and DR サービスのデータベースバックアップは永続増分方式です。これは、RMAN 増分マージ API で RMAN イメージコピーを使用することによって実現されます。最初の RMAN バックアップは、バックアップディスクの内部スナップショットを含む、Backup and DR バックアップディスク上のデータベースデータファイルの完全なイメージコピーです。その後の RMAN 増分バックアップは、バックアップと DR バックアップディスクで RMAN 増分マージとともに実行され、スナップショット前の増分変更で最後の完全バックアップが更新されます。ただし、サードパーティデータベースバックアップまたはバックアップのクロスチェックがバックアップと DR データベースバックアップの後に実行された場合、バックアップと DR バックアップのすべてのバックアップデータファイルは、RMAN メタデータで無効とマークされます。バックアップと DR アプリケーションの詳細と設定パラメータ `Do not uncatalog` が [はい] に設定されていると、次のエラーが発生します。ステージングデバイスからイメージコピーのカタログを作成できませんでした。バックアップは失敗します。他のレガシーバックアッププロダクトと共存するには、`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 ブロック変更のトラッキングでは、変更されたブロックを特定することで、高速なデータベースバックアップを実現できます。バックアップオペレーションには、変更されたブロックのみが含まれます。

バックアップと DR サービスの永久増分方式は、BCT が有効または無効で実行されているデータベースをサポートしています。BCT が有効になっていない場合、増分バックアップ時間は長くなります。
変更ブロックトラッキングがデータベースレベルで有効になっている。
Oracle は、各データファイル内の変更されたブロックを、データベース領域に保存される小さなバイナリファイルであるトラッキングファイルに記録します。
BCT が有効になっている場合、RMAN は BCT ファイルを使用して、増分バックアップの変更ブロックを取得します。
データベースの変更ブロックトラッキングが有効になっていない場合、RMAN は増分バックアップ中にデータベース内のすべてのデータファイルのデータファイル内の各ブロックをスキャンします。

バックアップと DR の整合性グループ内の Oracle データベースを保護する

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

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

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

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

ウォレットファイルは、バックアップソースサーバーから移行先のマウントサーバーにコピーし、Oracle がアクセスするように構成できます。
Oracle ウォレットファイルがネットワーク上の中央の共有デバイスに保存されている場合は、Appaware マウントターゲット Oracle インスタンスがファイルにアクセスするように構成する必要があります。
Oracle 構成ファイルの場所の詳細設定を設定することで、Backup and DR Service のバックアップ中に Oracle ウォレットファイルがキャプチャされた場合は、次の手順でウォレットファイルを取得できます。
1. データベースをターゲットホストに標準マウントします。
2. ウォレットファイルを標準データベースマウントからターゲットホストにコピーし、それらを使用するように Oracle を構成します。
3. ターゲットホストからデータベースをマウント解除します。
4. ターゲットホストへのデータベースのApplication Aware マウントを実行します。

Oracle Exadata Database または Oracle ExaCC を使用したバックアップと DR

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

バックアップ/リカバリアプライアンスは、ネットワーク（データパス内ではない）の iSCSI または Oracle dNFS 経由で接続されています。
RMAN バックアップは、RMAN を使用して、バックアップと DR によってファイルシステムまたは ASM ディスクグループとして提示されたコピーデータストアに直接書き込みます。
データキャプチャ形式: [ASM ディスクグループ]（iSCSI のみ）または [ファイルシステム]（dNFS または iSCSI）の下。
バックアップと DR の永久増分バックアップは、RMAN 増分更新バックアップを使用して、イメージコピーバックアップをロールフォワードします。

Exadata データと ExaCC のバックアップと DR キャプチャ

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

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

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

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

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

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

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

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

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

バックアップと DR エージェントは、バックアップと 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 サーバーの再起動後に、バックアップと DR で保護された ASM ディスクグループをオンラインに戻す

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

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

次のステップ

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