1 リカバリ・アプライアンスのスタート・ガイド

この章では、一般にリカバリ・アプライアンスと呼ばれるZero Data Loss Recovery Applianceの概要と、リカバリ・アプライアンスを使用したデータ保護に必要な概要手順について説明します。

この章の内容は次のとおりです。

リカバリ・アプライアンスの概要

リカバリ・アプライアンスは、企業内のすべてのOracle Databaseを保護するために設計されたクラウド規模のエンジニアド・システムです。拡張可能なアーキテクチャで構築され、Recovery Manager (RMAN)に統合されており、耐障害性と拡張性に非常に優れたハードウェアを使用して、一元化された永久的増分バックアップ計画を多数のデータベースに提供します。

リカバリ・アプライアンスを使用することで、高度なデータ保護と可用性を企業内で実現できます。リアルタイムREDOトランスポートでは、直近の1秒にも満たない期間に至るまでデータを保護できるので、企業全体にわたってリカバリ・ポイント目標が大幅に短縮されます。バックアップおよびリストア処理がリカバリ・アプライアンスにオフロードされることにより、本番データベースのリソースが解放され、それぞれのパフォーマンスが向上します。

バックアップは中央のディスク・プールに格納されて管理されます。初期全体バックアップを作成し、その後で増分バックアップを継続的に作成することにより、本番データベースを十分に保護します。アプライアンスが増分バックアップを受信すると、それぞれに索引を付けて格納します。リカバリ・アプライアンスは仮想完全バックアップ(ある特定の時点での完全なデータベース・イメージ)を提供し、リカバリ・ウィンドウ内の指定時点にデータベースをリカバリします。仮想完全バックアップは、リカバリ・アプライアンスで受信した増分バックアップごとに自動的に作成されます。仮想バックアップを使用すると、ユーザーのリカバリ・ウィンドウ内のあるPoint-in-Timeに全体バックアップをすばやく再構築できます。

リカバリ・アプライアンスのメタデータ・データベースでは、リカバリ・アプライアンスに格納されているすべてのバックアップのメタデータを管理し、リカバリ・アプライアンス・カタログを保持します。

関連項目:

リカバリ・アプライアンスのアーキテクチャおよび機能の詳細は、『Zero Data Loss Recovery Appliance管理者ガイド』を参照してください。

保護されたデータベースの概要

リカバリ・アプライアンスでバックアップが管理されているクライアント・データベースは、保護されたデータベースと呼ばれます。保護されたデータベースはそれぞれ特定のリカバリ・アプライアンスを一元化されたバックアップとリカバリの保存先として使用します。保護されたデータベースでは、RMANコマンドを使用してバックアップおよびリカバリ操作を実行します。それには、Oracle提供のSBTライブラリであるZero Data Loss Recovery Applianceバックアップ・モジュール(リカバリ・アプライアンス・バックアップ・モジュール)をインストールして、RMANが保護されたデータベースのバックアップをネットワーク経由でリカバリ・アプライアンスに転送できるようにする必要があります。

この項には次のトピックが含まれます:

保護されたデータベースとリカバリ・アプライアンスのアーキテクチャ

図1-1に、リカバリ・アプライアンス環境を示します。永久的増分バックアップ計画を使用して、複数の保護されたデータベースがリカバリ・アプライアンスにバックアップされます。また、リアルタイムREDOデータをリカバリ・アプライアンスに転送するよう、保護されたデータベースを構成することもできます。リカバリ・アプライアンス環境に含めることができる保護されたデータベースは、Oracle Database 10g、Oracle Database 11gおよびOracle Database 12cです。保護されたデータベースがリカバリ・アプライアンスにアクセスしてバックアップを格納できるようにするには、データベースを構成する必要があります。

図1-1 リカバリ・アプライアンスのアーキテクチャと保護されたデータベース

図1-1の説明が続きます
「図1-1 リカバリ・アプライアンスのアーキテクチャと保護されたデータベース」の説明

リカバリ・アプライアンスでは、複数の保護されたデータベースから増分バックアップとREDOデータを受信します。Oracleブロック・レベルでバックアップを継続的に検証するので、データのリカバリ可能性が保証されます。バックアップは圧縮して記憶域の使用率を最適化してからデルタ・ストアに格納されます。デルタ・ストアとは、保護されたデータベースのバックアップ・データの格納に使用するリカバリ・アプライアンスの全記憶域の合計です。すべてのデータ・ファイルとアーカイブREDOログのバックアップがデルタ・ストアに格納されます。リカバリ・アプライアンスでは、保護されたデータベースの仮想完全バックアップ(ある特定の時点での完全なデータベース・イメージ)を作成します。

リカバリ・アプライアンスのメタデータ・データベースは、リカバリ・アプライアンスの内部で実行されるOracleデータベースです。そこには構成データ(定義、保護ポリシーの定義、クライアント・データベースの定義など)が格納されます。また、メタデータ・データベースにはバックアップのメタデータやリカバリ・アプライアンス・カタログも格納されます。

リカバリ・アプライアンスにはOracle Secure Backup (リカバリ・アプライアンスのテープ管理コンポーネント)が事前インストールされており、それを使用してバックアップを接続されたテープ・ライブラリにアーカイブします。

Oracle Enterprise Manager Cloud Control (Cloud Control)は、統合されたバックアップ管理インタフェースをバックアップのライフサイクル全体にわたって提供します。Cloud Controlは、保護されたデーベースのバックアップ、リカバリおよびレポートに使用できます。

障害時リカバリ計画の一環として、リカバリ・アプライアンスでは保護されたデータベースのバックアップを別のリカバリ・アプライアンスにレプリケートできます。レプリケーションを構成すると、アップストリーム・リカバリ・アプライアンスと呼ばれるリカバリ・アプライアンスからダウンストリーム・リカバリ・アプライアンスと呼ばれる別のリカバリ・アプライアンスにバックアップが転送されます。リカバリ・アプライアンスでは様々なレプリケーション・テクノロジをサポートしています。

関連項目:

リカバリ・アプライアンスを使用して保護されたデータベースをバックアップするメリット

  • バックアップが本番サーバーに与える影響の最小化

    • バックアップ・ウィンドウの最小化

      リカバリ・アプライアンスでは、バックアップ・ウィンドウを短縮し、複数の保護されたデータベースのバックアップに単一のリポジトリを提供することにより、企業全体のデータベースのデータ保護を簡素化します。リカバリ・アプライアンスでは永久的増分バックアップ計画を使用し、保護されたデータベースごとにレベル0のバックアップが1回のみ作成されます。以降、保護されたデータベースはレベル1の増分バックアップをリカバリ・アプライアンスに送信します。

    • 本番サーバーからのバックアップ処理のオフロード

      ほとんどのバックアップ処理(バックアップの検証やバックアップのメンテナンス操作など)はリカバリ・アプライアンスにオフロードされます。バックアップ処理に使用するリソースが解放されるので、本番システムのパフォーマンスが向上します。

  • データ損失の防止

    • REDOデータのリカバリ・アプライアンスへの非同期トランスポート

      リアルタイムREDOトランスポートを使用すると、保護されたデータベースではデータベース障害から1秒に満たない時点にデータをリカバリできます。REDOデータが生成されたら、それを保護されたデータベースのメモリーからリカバリ・アプライアンスに直接書き込むことにより、連続する増分アーカイブ・ログのバックアップ間でデータ損失の危険にさらされる期間を最小限に抑えます。リアルタイムREDOトランスポートをサポートしているOracle Databaseのリリースの詳細は、『Zero Data Loss Recovery Appliance管理者ガイド』を参照してください。

    • データ破損の予防

      リカバリ・アプライアンスに作成されたバックアップを継続的に検証して、データベースのバックアップの整合性が維持されることを保証します。リカバリ・アプライアンスでは、Oracle RMANのブロック・チェック、自動ストレージ管理(ASM)およびExadataのデータ・チェックを使用して、ハードウェア・チェックサムに大きく依存しているサード・パーティ製ソリューションよりも遥かに優れた最高の保護機能をOracleデータベースに提供します。

  • Oracle高可用性テクノロジとの統合

    リカバリ・アプライアンスは、Recovery Manager (RMAN)、Oracle Real Application Clusters (Oracle RAC)、Oracle Data Guard、Oracle Secure BackupなどのOracle高可用性テクノロジと統合されています。保護されたデータベースのバックアップとリカバリにはRMANコマンドを使用できます(ただし、「RMANコマンドの相違点」に記載の例外があります)。

  • リストアおよびリカバリ時間の短縮

    リカバリ・アプライアンスではオンデマンドで作成される仮想完全バックアップを使用して、リストアおよびリカバリ時間を短縮します。仮想完全バックアップは、ある特定の時点での完全なデータベース・イメージです。リカバリ・アプライアンスでは、保護されたデータベースからの増分バックアップに索引を付けることにより、仮想完全バックアップを効率的に管理します。

  • 記憶域要件の最適化

    すべての保護されたデータベースにバックアップ記憶域を分散する必要はなくなりました。リカバリ・アプライアンスでは、共有ディスクのバックアップ・プールを使用して、複数の保護されたデータベースのバックアップを格納します。

    バックアップをリカバリ・アプライアンスに移行しても、保護されたデータベース上にローカルの高速リカバリ領域を引き続き構成して、制御ファイル、オンラインREDOログ・ファイル、アーカイブREDOログおよびフラッシュバック・ログを格納する必要があります。ただし、高速リカバリ領域にはバックアップを格納する必要がないので、サイズを大幅に縮小することができます。

保護されたデータベースの管理者のタスク

Oracle Databaseの従来のデプロイメントでDBAまたはDBAのチームが担当することになるのは、データベース管理とバックアップやリカバリ・アクティビティの計画および実行です。記憶域要件やデータベースのバックアップは記憶域管理者が管理します。リカバリ・アプライアンスでは、バックアップの記憶域と管理を一元化することで、保護されたデータベースからリカバリ・アプライアンスを経てテープへという企業規模のバックアップ・ライフサイクルがエンド・ツー・エンドでDBAに完全に可視化されます。

保護されたデータベースの管理者は、次のタスクを実行します。

  • 保護されたデータベースのバックアップおよびリストア計画の策定

    計画の策定段階では、保護されたデータベースの許容可能なリカバリ・ウィンドウ目標と保存ポリシーの決定、保護されたデータベースのバックアップを格納するために必要な記憶域領域の見積り、リカバリ・アプライアンスへのバックアップの送信方法の決定などについて検討する必要があります。

    保護されたデータベースのバックアップをリカバリ・アプライアンスに初めて移行する際は、リカバリ・アプライアンスへの移行計画を設計する必要があります。

  • 保護されたデータベースからリカバリ・アプライアンスへのアクセスの構成

    保護されたデータベースのデータ保護にリカバリ・アプライアンスを使用する前に、保護されたデータベースの要件に合せてバックアップおよびリカバリ設定を構成する必要があります。

  • バックアップおよびリカバリ操作の実行

    保護されたデータベースのバックアップ操作を実行するには、バックアップ・ジョブを使用します。バックアップ・ジョブは、即時実行することも、後で実行するようにスケジュールすることもできます。リカバリ操作は通常、メディアまたはデータ損失のインシデントに対応して即時実行されます。

保護されたデータベースに必要なユーザーおよび権限の概要

リカバリ・アプライアンスへのバックアップ操作では、保護されたデータベース上で稼働しているRMANクライアントとリカバリ・アプライアンス上で稼働しているシステム・ソフトウェアとの連携が必要になります。この項では、リカバリ・アプライアンスのバックアップ操作に必要なユーザーと権限について説明します。

保護されたデータベースの管理者

保護されたデータベースの管理者とは、保護されたデータベースに対してSYSDBAまたはSYSBACKUP権限を持つユーザーです。このユーザーは、リカバリ・アプライアンスに接続して保護されたデータベースのバックアップ、リストアおよびリカバリ操作を実行します。

Oracle Database 12cでは、RMANのバックアップおよびリカバリ操作はすべてSYSBACKUPまたはSYSDBA権限で実行できます。Oracle Database 12cより前のリリースのOracle DatabaseでRMANバックアップおよびリカバリ操作を実行するには、保護されたデータベースの管理者にSYSDBA権限が必要です。

リカバリ・アプライアンスとの認証を行ってバックアップおよびリカバリ操作を実行するには、保護されたデータベースの管理者がリカバリ・アプライアンス・ユーザーに関連付けられている必要があります。

リカバリ・アプライアンス・ユーザー

リカバリ・アプライアンス・ユーザーとは、リカバリ・アプライアンス管理者がリカバリ・アプライアンスのメタデータ・データベース内に作成したデータベース・ユーザー・アカウントです。このアカウントは、リカバリ・アプライアンスに登録された1つ以上の保護されたデータベースとの間でバックアップを送受信したり、これらの保護されたデータベースに関するリカバリ・アプライアンス・カタログのメタデータを操作したりするのに必要な権限を有しています。これは、保護されたデータベースからリカバリ・アプライアンスにREDOデータを送信するために使用するアカウントでもあります。

リカバリ・アプライアンスのメタデータ・データベースには、複数のリカバリ・アプライアンス・ユーザー・アカウントが含まれています。リカバリ・アプライアンスの各ユーザーは仮想プライベート・カタログを所有し、リカバリ・アプライアンス・カタログ内のアクセスを許可されているデータベースに関する行にのみアクセスして変更することができます。リカバリ・アプライアンス・ユーザーの認証資格証明は、保護されたデータベースのホスト上のOracleウォレットに安全に格納されています。保護されたデータベースの管理者は、カタログ・ロールを使用してリカバリ・アプライアンス・ユーザーに接続します。

関連項目:

リカバリ・アプライアンスの各種ユーザー・アカウントの詳細は、『Zero Data Loss Recovery Appliance管理者ガイド』を参照してください

保護ポリシーの概要

リカバリ・アプライアンスでは保護ポリシーを使用して、保護されたデータベースのバックアップの管理を簡素化します。保護ポリシーとは、1つ以上の保護されたデータベースのリカバリ目標と記憶域領域の要件を定義する属性のコレクションです。リカバリ・アプライアンスには、様々なリカバリ目標を定義する複数の保護ポリシーが含まれています。保護ポリシーは保護されたデータベースごとに1つのみ割り当てられ、これにより各保護されたデータベースのバックアップ・データをリカバリ・アプライアンスで格納および管理する方針が決まります。

保護ポリシーは、その保護ポリシーに関連付けられている保護されたデータベースごとに、次の属性を定義します。

  • 保護されたデータベースのバックアップを格納するリカバリ・アプライアンスの記憶域の場所

  • ディスク・バックアップのリカバリ・ウィンドウ目標

  • (オプション)このポリシーで保護されるバックアップを削除対象に含める前に、テープにレプリケートまたは書き込む必要があるかどうか

  • (オプション)テープ・バックアップのリカバリ・ウィンドウ

  • (オプション)バックアップのポーリング・ポリシー

保護ポリシーを使用すると、保護されたデータベースをリカバリ・サービス層でグループ化できます。たとえば、第1層のデータベースではバックアップをディスクに14日間、テープに30日間保持する必要があるとします。その場合は、このようなリカバリ・ウィンドウ目標を定義する保護ポリシーを作成してから、第1層の保護されたデータベースすべてに割り当てます。

関連項目:

保護ポリシーの作成および管理の詳細は、『Zero Data Loss Recovery Appliance管理者ガイド』を参照してください。

保護されたデータベースのバックアップをリカバリ・アプライアンスへ送信する方法の概要

保護されたデータベースのバックアップをリカバリ・アプライアンスに格納するには、次のいずれかの方法を使用できます。

  • 保護されたデータベースがリカバリ・アプライアンスにバックアップを直接送信

    保護されたデータベースの管理者がリカバリ・アプライアンスとの認証と接続を行い、保護されたデータベースをリカバリ・アプライアンスにバックアップします。バックアップをネットワーク経由でリカバリ・アプライアンスに送信するには、リカバリ・アプライアンス・バックアップ・モジュールを使用します。保護されたデータベースをリカバリ・アプライアンスにバックアップするには、永久的増分バックアップ計画を使用します。必要に応じてリアルタイムREDOトランスポートを構成し、REDOデータをリカバリ・アプライアンスに直接転送できます。

    保護されたデータベースのバックアップをリカバリ・アプライアンスに送信する前に、保護されたデータベースをリカバリ・アプライアンスに登録して設定を構成する必要があります。

  • リカバリ・アプライアンスが保護されたデータベースのバックアップを共有場所から自動的に取得

    保護されたデータベースは、リカバリ・アプライアンスと直接やり取りするかわりに、構成済の共有記憶域の場所にバックアップを書き込みます。リカバリ・アプライアンスは、バックアップのポーリングを使用して共有記憶域の場所を定期的にチェックし、この場所に格納された新規バックアップを取得します。

バックアップのポーリングの概要

バックアップのポーリングを使用すると、リカバリ・アプライアンスは事前定義済の共有ディスク・ディレクトリ(バックアップのポーリング位置と呼ばれる)を定期的にポーリングして、この位置にある保護されたデータベースの新規バックアップを取得できます。保護されたデータベースの管理者は、バックアップの送信に際してリカバリ・アプライアンスとやり取りすることはありません。かわりに、バックアップのポーリング位置にバックアップを配置し、リカバリ・アプライアンスがこれらのバックアップを定期的にチェックして取得します。

バックアップのポーリング位置には、レベル0、レベル1およびアーカイブREDOログのバックアップ・セットを格納できます。リカバリ・アプライアンスへはネットワーク・ファイル・システム(NFS)経由でアクセスできます。

リカバリ・アプライアンスに作成されたバックアップのポーリング・ポリシーでは、バックアップのポーリング位置へのパスと、リカバリ・アプライアンスがこの位置をポーリングする頻度を定義します。ポーリング・ポリシーは保護ポリシーを介して保護されたデータベースに関連付けられます。

関連項目:

保護されたデータベースのメタデータの格納に関する概要

リカバリ・アプライアンスのメタデータ・データベース(リカバリ・アプライアンスに常駐)では、リカバリ・アプライアンスに登録されているすべての保護されたデータベースのバックアップ・メタデータを管理し、リカバリ・アプライアンス・カタログも保持します。リカバリ・アプライアンスにバックアップを格納する保護されたデータベースはすべてリカバリ・アプライアンス・カタログを使用する必要があります。ただし、リカバリ・アプライアンスをバックアップ・リポジトリとして使用しなくても、リカバリ・アプライアンス・カタログを保護されたデータベースで使用できます。保護されたデータベースの管理者がリカバリ・アプライアンス・カタログに接続する際は、バックアップおよびリカバリ操作で使用するリカバリ・アプライアンス・ユーザーと同じユーザーを使用します。

保護されたデータベースは、リカバリ・アプライアンスに登録した後でリカバリ・アプライアンス・カタログに登録する必要があります。保護されたデータベースを登録すると、保護されたデータベースのバックアップ・メタデータがリカバリ・アプライアンス・カタログに格納されます。保護されたデータベースのRMANリカバリ・カタログに現在格納されている既存のバックアップ・メタデータは、リカバリ・アプライアンス・カタログにインポートする必要があります。

関連項目:

保護されたデータベースのバックアップおよびリカバリの概念

リカバリ・アプライアンスにバックアップを格納する保護されたデータベースにはそれぞれ、一意のグローバル・データベース名(DB_UNIQUE_NAME)が必要です。このグローバル・データベース名を使用して、バックアップが属する保護されたデータベースを識別します。保護されたデータベースのバックアップは、保護されたデータベースに関連付けられている保護ポリシーで指定される記憶域の場所に書き込まれます。

この項には次のトピックが含まれます:

RMAN SBTチャネルおよび保護されたデータベースについて

保護されたデータベースのバックアップおよびリカバリ操作を実行するには、保護されたデータベースのOracleホームにインストールされているRecovery Applianceバックアップ・モジュールに対応する1つ以上のRMAN SBTチャネルを使用する必要があります。このバックアップ・モジュールは、リカバリ・アプライアンスとの間でバックアップ・データをやり取りする共有ライブラリです。

保護されたデータベースは、ネットワークを介して共有ディスクに送信されます。単一のRMANチャネルを使用する場合、ネットワークの待機時間が発生する可能性があるため、最適なパフォーマンスが得られない場合があります。バックアップ・クライアントごとに2から4のRMANチャネルを使用することをお薦めします。

リカバリ・アプライアンス・バックアップ・モジュールに対応するSBTチャネルを構成するか、バックアップまたはリカバリ操作ごとにRMAN SBTチャネルを明示的に割り当てることができます。

保護されたデータベースのリカバリ・アプライアンスへのバックアップについて

保護されたデータベースをリカバリ・アプライアンスにバックアップするには、RMAN BACKUPコマンドを使用します。保護されたデータベースをリカバリ・アプライアンスに初めてバックアップする際は、データベース全体のレベル0の初期バックアップを作成して、リポジトリをシードする必要があります。保護されたデータベースでリカバリ・アプライアンスに存在する最も古いバックアップよりも前の時点にPoint-in-Timeリカバリを実行する場合にも、レベル0の増分バックアップを作成する必要があります。

レベル0の初回バックアップ後の定期的なバックアップ・スケジュールでは、保護されたデータベース、spfile、制御ファイルおよびアーカイブREDOログ・ファイルのレベル1の累積増分バックアップを定期的に作成します。アーカイブ・ログにはデータベース内で発生した変更の記録がすべて保持されるため、これらの重要なファイルはデータ・ファイルよりも頻繁にバックアップする必要があります。アーカイブREDOログを頻繁にバックアップすることにより、保護されたデータベースが消失してバックアップをリカバリする必要がある場合のデータ損失の危険性が低減します。

リカバリ・アプライアンスに直接バックアップするか、最初にローカルの高速リカバリ領域またはディスク・ディレクトリにバックアップ・セットを作成してから、BACKUP BACKUPSETコマンドを使用してそれをリカバリ・アプライアンスにコピーすることができます。

適切なバックアップ計画では、作成済のバックアップが実際にリストアでき、正常に使用できることを保証する必要があります。リカバリ・アプライアンスでは、受信したバックアップを格納する前にOracleブロックの妥当性を検証するため、RESTORE VALIDATEコマンドを定期的なフル・リストアおよびリカバリ・テストに含める必要はありません。仮想バックアップも、リカバリ・アプライアンスで実行中のバックグランド・タスクによりアプライアンス内で定期的に検証されます。

バックアップ暗号化とリカバリ・アプライアンスについて

保護されたデータベースでバックアップ暗号化を使用するように構成できます。リカバリ・アプライアンスへのRMANバックアップ操作時にバックアップが暗号化されていると、そのバックアップはリカバリ・アプライアンスでも暗号化されたままの状態です。このバックアップを後でテープにコピーすると、それにも暗号化された形式が維持されます。リカバリ・アプライアンスへのバックアップを実行する際は、RMANバックアップ暗号化を使用しないことをお薦めします。暗号化されたバックアップはリカバリ・アプライアンスで収集されないので、仮想完全バックアップの作成に使用したり、永久的増分バックアップ計画に含めることはできません。

リカバリ・アプライアンスからテープにコピーされるバックアップを暗号化するには、テープ・ドライブ上でハードウェアベースの暗号化を使用するか、Oracle Secure Backupを使用できます。

関連項目:

ハードウェアベースの暗号化の詳細は、『Oracle Secure Backup管理者ガイド』を参照してください。

リカバリ・アプライアンスを使用した保護されたデータベースのリストアおよびリカバリについて

リカバリ・アプライアンスに格納済のバックアップを使用して保護されたデータベースをリストアする場合、該当する仮想バックアップから全体バックアップが作成されます。リカバリで指定されたPoint-in-Timeに基づいて、使用できる最適な仮想完全バックアップを特定するには、リカバリ・アプライアンス・カタログを使用します。リカバリ・アプライアンスがリストア・リクエストを受信すると、適切な仮想バックアップから物理バックアップ・セットを作成して、事前に割り当てられているSBTチャネル経由で保護されたデータベースにこれらのバックアップ・セットを送信します。保護されたデータベースでは、RMANが受信したバックアップ・セットを検証し、これを使用してリストア操作を実行します。RMAN RESTOREコマンドを実行すると、リカバリ・アプライアンスを使用して保護されたデータベースをリストアできます。

RMAN RECOVERコマンドを使用する場合は、リカバリ・アプライアンス・カタログを使用して、リストアされたデータ・ファイルを指定の時点にリカバリするために必要になる適切なアーカイブ・ログのバックアップを特定します。レベル1の増分バックアップを頻繁に作成することで、障害発生時に適用する必要のあるアーカイブREDOログの数を削減でき、これによりリカバリ時間が短縮されます。リカバリ・アプライアンスは要求されたバックアップを保護されたデータベースに送信し、保護されたデータベースはそのバックアップを使用して一貫性維持点までリカバリしてからオープンされます。保護されたデータベースにリアルタイムREDOトランスポートが構成されている場合は、最新のアーカイブREDOログを使用できるので、1秒に満たない期間のデータ損失を伴うだけでデータベースを完全にリカバリできます。

リカバリ・アプライアンスの永久的増分バックアップ計画について

リカバリ・アプライアンスでは様々な種類のRMANバックアップ計画をサポートできますが、保護されたデータベースのバックアップには永久的増分バックアップ計画の使用を強くお薦めします。この計画では、レベル0の初期増分バックアップを基礎とし、その後でレベル1の累積増分バックアップとアーカイブREDOログのバックアップを継続的に作成します。初期全体バックアップ以外に全体バックアップを定期的に作成する必要はありません。これにより、従来のバックアップ・ウィンドウが不要になり、保護されたデータベースのパフォーマンスが向上します。

リカバリ・アプライアンスでは保護されたデータベースごとに、最新の仮想完全バックアップ(リカバリ・カタログにはレベル0として記録)に対するデータ・ファイル・ブロックの変更のみで構成されるスケジュールされたレベル1の増分バックアップを定期的に受信します。レベル1のバックアップを検証して破損データ・ブロックが存在しないことを確認し、特殊なブロック・レベル・アルゴリズムを使用して圧縮してからリカバリ・アプライアンスの記憶域プールに書き込みます。仮想完全バックアップは受信した増分バックアップに基づいて作成されます。保護されたデータベースをリカバリする必要がある場合、リカバリ・アプライアンスでは仮想完全バックアップとアーカイブ・ログ・バックアップを使用します(両方を組み合せて使用すると、指定されたリカバリ時間までのすべてのデータベース変更を再作成できます)。

アーカイブREDOログは全体バックアップと増分バックアップの両方に含める必要があります。アーカイブREDOログ・ファイルのバックアップを頻繁に取得して、レベル1の増分バックアップに含めることをお薦めします。保護されたデータベースでリアルタイムREDOトランスポートを使用する構成になっている場合は、アーカイブREDOログをバックアップする必要はありません。

RMANの増分更新バックアップ計画とリカバリ・アプライアンスの永久的増分バックアップ計画との相違点

従来のRMANセットアップで使用されている増分計画とリカバリ・アプライアンスで使用される永久的増分バックアップ計画には、次に示す重要な相違点があります。

  • RMAN増分更新バックアップ計画では初期イメージ・コピーの後に、レベル1の増分バックアップを継続的に使用します。このレベル1の増分バックアップをイメージ・コピーにマージすることにより、イメージ・コピーが更新されます。

    次に、RMAN増分更新バックアップ計画の実装に使用するスクリプトの例を示します。

    run
    {
        RECOVER COPY OF DATABASE
           WITH TAG 'incr_update';
        BACKUP
           INCREMENTAL LEVEL 1
           FOR RECOVER OF COPY WITH TAG 'incr_update'
        DATABASE;
    }
    
  • リカバリ・アプライアンスの永久的増分バックアップ計画では、レベル0の増分バックアップが1回のみ必要になります。以降、レベル1の増分バックアップがリカバリ・アプライアンスに作成され格納されます。このレベル0の初期バックアップと後続のレベル1のバックアップからブロックを参照して、仮想完全バックアップが作成されます。

    次に、リカバリ・アプライアンスの永久的増分バックアップ計画を実装するスクリプトの例を示します。

    BACKUP CUMULATIVE INCREMENTAL LEVEL 1
         DEVICE TYPE sbt FORMAT '%d_%U' TAG '%TAG'
         DATABASE;
    BACKUP DEVICE TYPE sbt FORMAT '%d_%U' TAG '%TAG'
         ARCHIVELOG ALL NOT BACKED UP;
    

リアルタイムREDOトランスポートについて

REDOデータにはデータベースに加えられたすべての変更の記録が格納されるので、データ障害が発生した場合のデータ損失を最小限に抑える上で欠かせません。リアルタイムREDOトランスポートを使用すると、連続するアーカイブREDOログのバックアップ間でデータ損失の危険にさらされる期間が大幅に短くなります。リアルタイムREDOトランスポートが構成されると、アーカイブREDOログのバックアップはデータベース管理者に対して透過的になります。1つ以上の保護されたデータベースから受信したREDOストリームは、リカバリ・アプライアンス上のREDOステージング領域に格納されます。保護されたデータベースは、アプライアンスが受信した直近の変更までデータをリカバリできます。

関連項目:

リアルタイムREDOトランスポートがサポートされているOracle Databaseのリリースの詳細は、『Zero Data Loss Recovery Appliance管理者ガイド』を参照してください。

リアルタイムREDOトランスポートの機能方法

リアルタイムREDOトランスポートを有効にすると、リカバリ・アプライアンスは非同期REDOトランスポート・サービスのリモート宛先になります(Oracle Data Guard環境のスタンバイ・データベースと類似)。保護されたデータベースでREDOデータが生成されると、そのデータはリカバリ・アプライアンスへ非同期に書き込まれます。REDOデータは、ディスクI/Oを伴わずにメモリーからリカバリ・アプライアンスに直接転送されるので、本番データベース・サーバーへの負荷が最小限に抑えられます。ログ・スイッチが発生してREDOストリームを受信するたびに、圧縮済のアーカイブ・ログ・バックアップが保護されたデータベースの記憶域の場所に作成されます。リカバリ・アプライアンスによって生成されたアーカイブ・ログ・バックアップは、リカバリ・アプライアンス・カタログに通常のバックアップとして記録され、RMAN RECOVERコマンドを使用してリストアしデータ・ファイルに適用できます。

関連項目:

非同期REDOトランスポート・サービスの詳細は、『Oracle Data Guard概要および管理』を参照

保護されたデータベースがクラッシュすると、クラッシュ時まで最新であったREDOログ・グループから受信したREDOデータが、「不完全な」アーカイブREDOログとしてリカバリ・アプライアンスにバックアップされます。保護されたデータベースが再オープンすると、保護されたデータベースのクラッシュ・リカバリによって、クラッシュ時に最新であったREDOログ・グループが終了し、その完全なREDOログがData Guardの自動ギャップ・フェッチ機能を使用してリカバリ・アプライアンスに再送されます。この「完全な」アーカイブREDOログが、前にバックアップされた「不完全な」アーカイブREDOログにかわって今後のリストア/リカバリ操作で使用されます。

保護されたデータベースのリカバリ時、保護されたデータベースを完全にリカバリする上で必要と判断された場合は、自動的に不完全なアーカイブ・ログと完全なアーカイブ・ログがリストアされます。

保護されたデータベースのリアルタイムREDOトランスポートの構成について

リアルタイムREDOトランスポートを使用するには、リカバリ・アプライアンスと保護されたデータベースのセットアップが必要です。また、保護されたデータベースからリカバリ・アプライアンスにREDOデータを認証してから送信するために使用するREDOトランスポート・ユーザーが必要です。このユーザーは、保護されたデータベースのバックアップをリカバリ・アプライアンスに送信するために使用するリカバリ・アプライアンス・ユーザーと同じである必要があります。このリカバリ・アプライアンス・ユーザーの資格証明は保護されたデータベース上のOracleウォレットに格納されています。

保護されたデータベース上に、ARCHIVELOGモードを構成し、リカバリ・アプライアンスのサービス名を指す、REDOデータのアーカイブ先を設定します(LOG_ARCHIVE_DEST_nパラメータを使用)。

保護されたデータベースの操作ツール

リカバリ・アプライアンスには、保護されたデータベースのバックアップおよびリカバリ操作を管理するためのインタフェースが複数用意されています。

  • Oracle Enterprise Manager Cloud Control (Cloud Control)

    Cloud Controlは、リカバリ・アプライアンス環境を管理およびモニタリングするためのGUIを備えています。また、保護されたデータベースの構成、バックアップおよびリカバリを行うこともできます。

    Cloud Controlの使用方法の詳細は、Cloud Controlのオンライン・ヘルプを参照してください。

  • RMANクライアント

    リカバリ・アプライアンスはRMANと統合されているので、保護されたデータベースにインストール済のRMANクライアントを使用して、保護されたデータベースの構成、バックアップおよびリカバリを行うことができます。

  • SQL*Plus

    SQL*Plusはコマンドライン・ツールで、これを使用してリカバリ・アプライアンス・カタログの問合せやDBMS_RA PL/SQLパッケージを実行できます。

保護されたデータベース管理タスク・フロー

この項では、リカバリ・アプライアンスを使用して、企業内にある複数の保護されたデータベースのバックアップを格納および管理するための概要タスクについて説明します。これらのタスクはCloud ControlまたはRMANを使用して実行できます。使用する管理インタフェースによっては、一部のタスクの実行手順が少し異なる場合があります。

関連項目:

リカバリ・アプライアンス環境を管理するワークフローの詳細は、『Zero Data Loss Recovery Appliance管理者ガイド』を参照してください。

企業データを保護するためにリカバリ・アプライアンスを設定および使用する場合のタスク・フローは次のとおりです。

  1. 保護されたデータベースのバックアップをリカバリ・アプライアンスに移行するための計画を決定します(「保護されたデータベースの管理者のための移行に関する考慮事項」を参照)。

  2. 保護されたデータベースをリカバリ・アプライアンスに登録します。

    この手順を実行する必要があるのは、リカバリ・アプライアンスを使用するように保護されたデータベースを最初に構成するときのみです。

  3. 保護されたデータベースのバックアップおよびリカバリ設定を構成します。

    これは通常1回かぎりのタスクで、保護されたデータベースをリカバリ・アプライアンスに登録する際に実行します。ただし、バックアップおよびリカバリ設定は後で変更できます。

  4. テスト・バックアップを実行して、保護されたデータベースが正確に構成されていることを確認します。

    テスト・バックアップは、構成設定の初回設定時または設定を後で変更したときに実行することをお薦めします。

  5. 保護されたデータベースをリカバリ・アプライアンスにバックアップします。

    保護されたデータベースのバックアップは指定の時間に実行されるようにスケジュールできます。

  6. テスト・リストアおよびリカバリを実行し、リカバリ・アプライアンスに格納されているバックアップを使用して保護されたデータベースがリカバリ可能であることを確認します。

  7. (メディア障害やデータ破損を原因とする)障害発生時に、リカバリ・アプライアンスに格納されているバックアップを使用して保護されたデータベースをリカバリします。

    障害の種類によって、保護されたデータベース全体または影響を受けたデータベース・ファイルのみをリカバリすることが可能です。