Oracle Database 10gにおけるOracle Data GuardでのRecovery Managerの使用

Oracle Database 10g における Oracle Data

Guard での Recovery Manager の使用

オラクル・ホワイト・ペーパー

Oracle Database 10g における Oracle Data

Guard での Recovery Manager の使用

概要 ... 3

はじめに ... 4

セットアップの前提条件 ... 5

構成設定と注意事項 ... 7

Oracleデータベースの推奨構成 ... 7

RMANの推奨設定... 9

バックアップ手順 ... 10

ケース 1: ディスクをテープ・バックアップのキャッシュとして使用す

る... 11

プライマリ・データベース・バックアップ手順... 11

スタンバイ・データベース・バックアップ手順... 11

ケース 2: テープにバックアップを直接書き込む ... 13

プライマリ・データベース・バックアップ手順... 13

スタンバイ・データベース・バックアップ手順... 13

アーカイブ・ログ管理 ... 14

リカバリ手順 ... 14

スタンバイ・データベース上での消失データファイルのリカバリ ... 14

プライマリ・データベース上での消失データファイルのリカバリ ... 15

スタンバイ・データベース上での消失制御ファイルのリカバリ ... 16

プライマリ・データベース上での消失制御ファイルのリカバリ ... 17

1. スタンバイ・データベースへのフェイルオーバー... 17

2. 新しい制御ファイルの作成 ... 18

3. バックアップ制御ファイルを使用したリカバリ... 18

消失したオンライン・ログのリカバリ ... 19

データベースのブロック・メディア・リカバリ ... 19

データベースの不完全リカバリ ... 20

スイッチオーバー/フェイルオーバー後の手順や構成の変更点... 20

アーカイブ・ログ・バックアップの注意事項 ... 20

RMANによるスタンバイ・データベースのインスタンス化 ... 21

RMANによりスタンバイ・データベースをインスタンス化する代替方

法... 22

結論 ... 23

参照資料 ... 24

付録 ... 25

発信元ホストで取ったバックアップが使用できない場合 ... 25

アーカイブ・ログ・リポジトリとして構成されたスタンバイ・データ

ベース... 26

スタンバイ・データベース・ファイル名がプライマリ・データベース

と異なる場合... 26

Oracle Database 10g における Oracle Data

Guard での Recovery Manager の使用

概要

高可用性の全般的な方針には、十分な裏付けのある実証済システムおよびソフト ウェア・リカバリ計画が不可欠です。Oracle Data Guard の使用により、Oracle DBA はストレージ・サブシステムの故障、サイト全体の障害、災害などの場合でも連 続稼働を提供します。Data Guard は、管理、監視、自動化のためのソフトウェア・ インフラストラクチャで、1 つ以上のスタンバイ・データベースを作成、メンテ ナンスおよび監視して、企業データを故障、災害、エラー、破損などから保護し ます。

同様に、DBA は、Oracle Recovery Manager（RMAN）を使用して、制御ファイル、 データファイル、アーカイブ・ログ・ファイルをディスクやテープにバックアッ プする一方、ファイル・システムやメディアが消失した場合、これらのファイル を効率的にリカバリできます。RMAN は、データベース・バックアップおよびリ カバリを行う Oracle のユーティリティです。本番データベースへの影響を最小限 に抑えながら、すべてのデータをバックアップし、個々のファイルでもデータベー ス全体でも、その消失を迅速にリカバリします。Oracle Database 10g では、RMAN は Data Guard 構成に対して次のような新機能を提供します。

• フラッシュ・リカバリ領域。バックアップやアーカイブ・ログなどのデー タベース・リカバリ関係のファイルを編成および管理する単一のファイ ル・システム、または Automatic Storage Management（ASM）ディスク・ グループ。 • スタンバイ・データベース・サーバー固有の永続構成。チャネル、デバ イス、バックアップ最適化、制御ファイル自動バックアップ設定などを 含みます。 • プライマリおよびスタンバイ・データベース・サーバー固有の構成。リ モート・スタンバイ宛先に適用されたアーカイブ・ログを自動削除でき ます。アーカイブ・ログの自動削除。新しいファイルに対してフラッ シュ・リカバリ領域でスペースが必要な場合に実行されます。 このホワイト・ペーパーでは、Oracle Database 10g 環境で Data Guard が管理する

フィジカル・スタンバイ・データベースをセットアップおよびバックアップする

RMAN 手順を概説します。プライマリ・データベースのリカバリには、フィジカ

ル・スタンバイ・データベースからのバックアップのみが使用可能です。 概説する手順は次のとおりです。

• プライマリ・データベースまたはスタンバイ・データベースのリカバリ に使用できるスタンバイ・データベースで、データベース・バックアッ プを作成 • スタンバイ・データベースで作成されたバックアップを使用して、プラ イマリ・データベースまたはスタンバイ・データベースでデータファイ ルをリカバリ

このホワイト・ペーパーでは、Data Guard 構成でバックアップを管理する RMAN 手順に関心のある DBA、IT、システム管理者を対象としています。Data Guard お よび RMAN の概念と手順を理解していることを前提とします。

注意: Oracle9i Database構成でのRMAN手順については、『Using Recovery Manager (RMAN) with Oracle Data Guard in Oracle9i[1]』を参照してください。

はじめに

Data Guard は、Oracle データベースが身近にあっても遠く離れていても、障害時 リカバリ・ソリューションの管理を可能にし、自動化します。Data Guard は、本

番データベース（プライマリ・データベースとも呼ばれる）と、本番データベー

スのトランザクション一貫性コピーである 1 つ以上のスタンバイ・データベース

で構成されます。プライマリ・データベースでトランザクションが発生すると、 REDO データが生成され、ローカル REDO ログに書き込まれます。Data Guard は、 この REDO データをスタンバイ・サイトに自動的に転送し、スタンバイ・データ ベースに適用してプライマリ・データベースと同期させます。 RMAN は、Oracle データベースと統合されたツールで、高いパフォーマンスと管 理性を備えたバックアップおよびリカバリの需要に応えます。RMAN は、サーバー と緊密に連動するように設計されており、バックアップとリストアの実行中にブ ロック・レベルの破損を検出します。RMAN は、ファイル多重化と圧縮により、 バックアップ中のパフォーマンスと領域消費量を最適化します。また、付属の Media Management Library（MML）API により最新のバックアップ・ソフトウェア・ システムでも動作します。

RMAN は、オンライン・バックアップ、増分バックアップ、ブロック・メディア・ リカバリ、バックアップ管理タスクの自動化、サード・パーティ・メディア管理 システムの Data Guard 構成への統合など、豊富な機能を備えています。RMAN と Data Guard は、統合された Oracle 高可用性テクノロジ群の一部として、RMAN バッ クアップをフィジカル・スタンバイ・データベースにシームレスにオフロードで きるため、障害時リカバリ投資の価値が一層高まります。バックアップは、通常 の Data Guard 処理に影響を与えません。スタンバイ・データベースがリカバリ・ モードまたは読取り専用モードのときにバックアップすることができます。バッ クアップは、プライマリ・データベース・サーバーまたはスタンバイ・データベー ス・サーバーのリカバリにも使用できます。

クライアント _{クライアント} プライマリ・ サイト スタンバイ・_サイト データ変換 Data Guard ブローカ プライマリ・ データベース スタンバイ・ データベース RMAN バックアップ RMAN バックアップ RMAN バックアップ カタログ・ サーバー テープ フラッシュ・ リカバリ領域 RMAN カタログ・ バックアップ フラッシュ・ リカバリ領域

図 1: Data Guard と RMAN の構成

Data Guard と RMAN は、いずれも Oracle データベース・アーキテクチャを念頭に 置いて設計されました。この 2 つが一緒になって、非常に信頼性が高く緊密に統 合されたソリューションを提供し、ミッション・クリティカルなアプリケーショ ンをサポートする高レベルの Oracle データベース可用性を達成します。Data Guard と RMAN は、いずれも Oracle Database Enterprise Edition の機能を完全にサポート します（RMAN は Oracle Database Standard Edition でも提供されています）。 後述のセクションでは、次について説明します。

• RMAN と Data Guard の構成設定

• プライマリおよびスタンバイをディスクとテープにバックアップする手 順 • プライマリとスタンバイでのリカバリ・シナリオ • スタンバイ・データベースの RMAN ベースのインストール

セットアップの前提条件

このセットアップの前提条件は次のとおりです。 • スタンバイ・データベースはフィジカル・スタンバイ・データベースで あり、スタンバイ・データベースでのみバックアップが実行されます。 プライマリ・データベースとスタンバイ・データベースの両方でバック アップを行う場合、手順の変更については「付録」を参照してください。

• プライマリ・データベースとスタンバイ・データベースのディレクトリ 構造は同じです。 そのため、使用しているホストに関係なく、RMAN バックアップとリカ バリの処理が簡素化されます。 • あるデータベース・サーバーで取られたバックアップを他のデータベー ス・サーバーにリストアするためには、RMAN リカバリ・カタログが必 要です。プライマリ・データベースはスタンバイ・データベースで行わ れたバックアップに関する情報を持っていないため、RMAN リポジトリ として制御ファイルを使用するだけでは不十分です。 RMAN リカバリ・カタログは、バックアップ履歴や他のリカバリ関係の メタデータを一元管理します。リカバリ・カタログはデータベース内に 構成され、バックアップ・メタデータをメンテナンスします。リカバリ・ カタログには制御ファイルの領域制限がないため、バックアップに関す る大量の履歴データを保管できます。 Data Guard 構成では、カタログ・サーバーをプライマリ・サイトやスタン バイ・サイトから物理的に独立させ、いずれかのサイトで障害が発生し た場合でも最新のバックアップのリカバリに影響が及ばないようにする ことをお薦めします。

• 構成におけるすべてのデータベースで、Oracle Database 10g Release 1 を使 用します。

• プライマリ・データベースはOracle Managed Files（OMF）を使用しませ ん。OMFを使用すると、スタンバイ・データベース・ファイル名がプラ イマリでのファイル名と異なることがあります。そのリストア手順の変 更については、「付録」を参照してください。 • サード・パーティ・メディア管理ソフトウェアでは、RMAN がテープに バックアップを作成するように構成されます。 注意: 「付録」では、次の 3 つの代替構成における変更点を説明しています。 „ 発信元ホストからバックアップにアクセスできないために、バックアッ プがプライマリおよびスタンバイ両方のデータベース・サイトで作成さ れる場合 „ スタンバイ・データベースがアーカイブ・ログ・リポジトリとして構成 される場合 „ スタンバイ・データベース・ファイル名がプライマリでのファイル名と 異なる場合

構成設定と注意事項

Data Guard 構成では、データファイルとアーカイブ・ログをバックアップするプ ロセスをスタンバイ・システムにオフロードし、本番システムに対するバックアッ プ処理の影響を最小限にできます。これらのバックアップは、プライマリ・デー タベースまたはスタンバイ・データベースのリカバリに使用できます。 RMAN と Oracle データベースに対して次の設定をすると、バックアップとリカバ リの処理が簡単になります。これらの設定は、データファイルとアーカイブ・ロ グのバックアップをスタンバイ・データベース・サーバーの 1 つで行うことを前 提としています。

Oracle データベースの推奨構成

プライマリ・データベースおよびスタンバイ・データベースでは、次のようにし ます。 • フラッシュ・リカバリ領域を構成します。 フラッシュ・リカバリ領域は、ファイル・システム上の単一のストレー ジ場所または Automatic Storage Management（ASM）ディスク・グループ であり、リカバリに必要なすべてのファイルが置かれます。これらのファ イルには、制御ファイル、アーカイブ・ログ、オンライン･ログ・コピー、 フラッシュバック・ログ、RMAN バックアップが含まれます。新しいバッ クアップとアーカイブ・ログがフラッシュ・リカバリ領域で作成される とき、古いファイル（保存期間を経過したもの、または第 3 のストレー ジにバックアップされたもの）は自動的に削除され、新しいファイルに 対してスペースが割かれます。また、フラッシュ・リカバリ領域のスペー ス消費量が事前定義された限界に近づいた場合、DBA にアラートを発行 する通知機能をセットアップできるため、DBA はリカバリ領域スペース 制限の増加、ディスク・ハードウェアの増設、保存期間の短縮などの対 応策を取ることができます。 次の init.ora パラメータを設定して、フラッシュ・リカバリ領域を構 成します。

DB_RECOVERY_FILE_DEST = <mount point or ASM Disk Group> DB_RECOVERY_FILE_DEST_SIZE = <disk space quota>

• システム・パラメータ・ファイル（SPFILE）を使用して、Data Guard 構 成で任意のデータベースを使用できるようにします。これにより、別の データベースで取ったバックアップから SPFILE をリストアできます。 • プライマリ・データベースおよびスタンバイ・データベースでFlashback Databaseを有効にします。Flashback Databaseが有効の場合、Oracleはフラッ シュ・リカバリ領域でフラッシュバック・ログを管理します。このログ の使用により、完全なリストアを実行しなくても、データベースを過去 のある時点まで「巻戻し」できます。詳細は、『Oracle Database バック アップおよびリカバリ・アドバンスト・ユーザーズ・ガイド』の「Oracle

Flashback Database: Point-in-Time リカバリの代替方法[2]」を参照してくだ

RMAN の推奨設定

次の CONFIGURE コマンドは、プライマリ・データベースとリカバリ・カタログ の接続後に発行する必要があります。

° CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF <n> DAYS このコマンドは、プライマリ・データベース制御ファイルを更新後、た だちにカタログに記録されます。カタログに接続されると、スタンバイ・ データベースはこの保存期間ポリシーを使用します。スタンバイ制御 ファイルには一部のプライマリ制御ファイルのレコードを含むため、こ のコマンドは必ずプライマリ・データベースでのみ実行します。スタン バイ・データベース上のすべてのバックアップ・ファイルとアーカイブ・ ログは、少なくとも<n>日間保存されます。フラッシュ・リカバリ領域は、 新しいファイル用のスペースを再生するため、期限切れのファイルや テープにバックアップしたファイルを必要に応じて自動的に削除します。 ° CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON

STANDBY この構成をプライマリ・データベースで設定することにより、プライマ リ・データベース上にあり、リモート・スタンバイ宛先に適用されたアー カイブ・ログを自動削除できます。この構成はデフォルトで、1 つ以上の リモート宛先の設定が必須です。 注意: スタンバイ宛先に到達できない場合、必須スタンバイ宛先がプライ マリ・データベースに影響することがあります。必須スタンバイ宛先を 使用せずにこの機能を有効にするには、Metalink Note 331924.1（RMAN backups in Max Performance/Max Availability Data Guard Environment）を参 照してください。

° CONFIGURE CONTROLFILE AUTOBACKUP ON

制御ファイルとSPFILEの自動バックアップを有効にします。 ° CONFIGURE CHANNEL DEVICE TYPE SBT PARMS ‘<channel

parameters>’

メディア管理ソフトウェアに必要なチャネル・パラメータをセットアッ プします。

バックアップが行われるスタンバイ・データベース・サーバーとリカバリ・カタ ログに接続後、次のコマンドを発行する必要があります。

° CONFIGURE CONTROLFILE AUTOBACKUP ON

制御ファイルとSPFILEの自動バックアップを有効にします。バックアッ プはフラッシュ・リカバリ領域に書き込まれます。

° CONFIGURE BACKUP OPTIMIZATION ON

保存期間内の有効なバックアップが存在するデータベース・ファイルに ついては、バックアップをスキップします。

° CONFIGURE CHANNEL DEVICE TYPE SBT PARMS ‘<channel parameters>’

メディア管理ソフトウェアに必要なチャネル・パラメータをセットアッ プします。

° CONFIGURE ARCHIVELOG DELETION POLICY TO NONE

新しいバックアップまたはアーカイブ・ログに対して追加スペースが必 要な場合、スタンバイ・データベース（バックアップが取られるデータ ベース）上にあり、保存期間の過ぎたアーカイブ・ログまたはテープに バックアップされたアーカイブ・ログの自動削除を有効にします。 その他のスタンバイ・データベース・サーバーとリカバリ・カタログに接続後、 次のコマンドを発行する必要があります。

° CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON STANDBY この構成を他の各スタンバイ・データベース（バックアップを取らない データベース）で設定することにより、このスタンバイ・データベース 上にあり、他のすべてのリモート・スタンバイ宛先に適用されたアーカ イブ・ログの自動削除が有効になります。この構成はデフォルトで、1つ 以上のリモート宛先の設定が必須です。新しいファイルのためにフラッ シュ・リカバリ領域でスペース再生が必要な場合、アーカイブ・ログが 削除されます。 注意: スタンバイ宛先に到達できない場合、必須スタンバイ宛先がプライ マリ・データベースに影響することがあります。必須スタンバイ宛先を 使用せずにこの機能を有効にするには、Metalink Note 331924.1（RMAN backups in Max Performance/Max Availability Data Guard Environment）を参 照してください。 スイッチオーバーまたはフェイルオーバーが発生した場合、データベース・ロー ルが変わるため、適切なCONFIGUREコマンドを新しいプライマリ・データベー スおよびスタンバイ・データベースで再実行する必要があります。その他の変更 については、「スイッチオーバー/フェイルオーバー後の手順や構成の変更点」を 参照してください。

バックアップ手順

このセクションでは、Data Guard 構成で Oracle データベースをバックアップする RMAN スクリプトと手順を詳しく説明します。

オラクル社のMaximum Availability Architecture（MAA）ベスト・プラクティスで は、二重停止の場合のMTTR（平均リカバリ時間）を減少させ、スイッチオーバー /フェイルオーバー後の新サイトでの作業を避けるため、プライマリ・データベー スとスタンバイ・データベースの両方でバックアップを取ることをお薦めしてい ます。その場合の一般的手順の変更については、「付録」を参照してください。

ケース 1: ディスクをテープ・バックアップのキャッシュとして使用

する

このシナリオでは、スタンバイ・データベースのフラッシュ・リカバリ領域をテー プ・バックアップのためのディスク・キャッシュとして使用します。ディスクは、 テープが提供する長期のアーカイブ・ストレージとともに、バックアップのため のプライマリ・ストレージとして使用されます。完全バックアップは毎週、増分 バックアップは毎日実行されます。

プライマリ・データベース・バックアップ手順

プライマリ・データベース制御ファイルと SPFILE の自動バックアップは、（ター ゲット・データベースとしてプライマリ・データベース）とリカバリ・カタログ に接続後、次の RMAN コマンドを使用してテープにバックアップする必要があり ます。

BACKUP DEVICE TYPE SBT BACKUPSET ALL;

このコマンドの実行時、既存のディスク・バックアップは（バックアップ計画か ら）テープに置かれます。 このバックアップの実行頻度はリカバリ期間により決まります。リカバリ時には、 古いバックアップ制御ファイルより新しいバックアップ制御ファイルの方が、最 新状態に保つために必要な REDO 適用回数が少ないため、所要時間も短くなりま す。プライマリ・データベース制御ファイルは、少なくとも週に 1 回テープにバッ クアップすることをお薦めします。

スタンバイ・データベース・バックアップ手順

日次バックアップ・スクリプト お薦めするバックアップ方針は「Oracle 推奨方針」で、増分的に更新されるバッ クアップの利点を活用します。この機能により、データファイルのイメージ・コ ピーを最新の増分バックアップを使用してロール・フォワードできるため、常に データファイルの最新のイメージ・コピーが提供されます。RMAN は、結果のイ メージ・コピーを、その SCN で取得された完全イメージ・コピーを使用している かのようにメディア・リカバリに使用します。これにより、データベースの完全 イメージ・コピーを毎日実行するオーバーヘッドを回避できます。このイメージ・ コピーは最新のブロック変更で更新され、必要最小限の REDO ログでデータベー スを最新状態に戻せるため、リカバリ時間も短縮されます。 「Oracle 推奨方針」では、完全データベース・バックアップは初日のみ実行され、 2 日目は増分バックアップが行われます。アーカイブされた REDO ログを使用し て、任意の日の任意の時点にデータベースをリカバリできます。3 日目以降は、 前日の増分バックアップがデータファイル・コピーとマージされ、最新の増分バッ クアップが取られるため、過去の任意の時点に高速でリカバリでき、また REDO ログを使用して当日の任意の時点にデータベースをリカバリできます。 （ターゲット・データベースとして）スタンバイ・データベースとリカバリ・カタ ログに接続後、次のコマンドを実行できます。

1. RECOVER COPY OF DATABASE WITH TAG ‘OSS’; 前日に取られたレベル 1 の増分を適用することにより、データベースの レベル 0 コピーをロール・フォワードします。次のスクリプト例では、 前日のレベル 1 の増分に OSS というタグを付けました。この増分は、手 順 2 で BACKUP コマンドにより生成されます。 スクリプトを最初に実行する日には、レベル 1 の増分がないため、ロー ル・フォワードはありません。手順 2 でレベル 0 の増分が作成されます。 2 日目もレベル 0 の増分のみであるため、ロール・フォワードはありませ ん。OSS というタグを付けたレベル 1 の増分が手順 2 で作成されます。 3 日目以降は、前日に作成された OSS というタグの付いたレベル 1 の増 分を使用して、ロール・フォワードされます。

2. BACKUP DEVICE TYPE DISK INCREMENTAL LEVEL 1 FOR RECOVER OF COPY WITH TAG ‘OSS’ DATABASE;

レベル 1 の新しい増分を作成します。スクリプトを最初に実行する日は、 レベル 0 の増分です。2 日目以降はレベル 1 の増分になります。

3. BACKUP ARCHIVELOG ALL NOT BACKED UP TO SBT; BACKUP BACKUPSET ALL;

このスクリプトを最初に実行する日は、このコマンドの実行時に既存の ディスク・バックアップが（バックアップ計画から）テープに置かれま す。 翌日からは、リカバリ領域のアーカイブ・ログと増分バックアップがテー プにバックアップされます。 完全なコマンド・シーケンスは次のとおりです。

RECOVER COPY OF DATABASE WITH TAG ‘OSS’;

BACKUP DEVICE TYPE DISK INCREMENTAL LEVEL 1 FOR RECOVER OF COPY WITH TAG ‘OSS’ DATABASE;

BACKUP ARCHIVELOG ALL NOT BACKED UP TO SBT; BACKUP BACKUPSET ALL;

制御ファイル自動バックアップが有効なため、バックアップ処理の最後にスタン バイ制御ファイルが自動的にバックアップされます。

週次バックアップ・スクリプト

ディスク上のすべてのリカバリ領域ファイルは、次のコマンドにより週に 1 回 テープにバックアップされます。

これにより、ディスク上のすべての最新の増分バックアップ、イメージ・コピー・ バックアップおよびアーカイブ・ログ・バックアップがテープにバックアップさ れます。

ケース 2: テープにバックアップを直接書き込む

（ターゲット・データベースとして）スタンバイ・データベース・サーバーとリカ バリ・カタログに接続後、次の RMAN コマンドによりデフォルト・デバイス・タ イプをテープに設定します。

CONFIGURE DEFAULT DEVICE TYPE TO SBT;

このシナリオでは、スタンバイ・データベースで、完全バックアップは毎週、増 分バックアップは毎日実行されます。

プライマリ・データベース・バックアップ手順

（ターゲット・データベースとして）プライマリ・データベースとリカバリ・カタ ログに接続後、次の RMAN コマンドを使用して、制御ファイルと SPFILE 自動バッ クアップをテープにバックアップします。

BACKUP BACKUPSET ALL;

このバックアップの頻度は、制御ファイル・バックアップが実行される頻度、古 いバックアップ制御ファイルの使用が必要な場合に REDO が失われる危険性など のリカバリ要件によって決まります。プライマリ・データベース制御ファイルは、 少なくとも週に 1 回テープにバックアップすることをお薦めします。

スタンバイ・データベース・バックアップ手順

日次バックアップ・スクリプト （ターゲット・データベースとして）スタンバイ・データベースとリカバリ・カタ ログに接続後、次のコマンドを実行します。 • すべてのアーカイブ・ログを含めて、データベースのレベル 1 の増分バッ クアップを作成します。これを最初に実行する日にはレベル 0 のバック アップがないため、レベル 0 バックアップが作成されます。

BACKUP AS BACKUPSET INCREMENTAL LEVEL 1 DATABASE PLUS ARCHIVELOG;

制御ファイル自動バックアップが有効であるため、バックアップ処理の最後にス タンバイ制御ファイルが自動的にバックアップされます。

週次バックアップ・スクリプト

（ターゲット・データベースとして）週に 1 回、スタンバイ・データベースとリカ バリ・カタログに接続後、次の RMAN コマンドを実行します。

• すべてのアーカイブ・ログを含め、レベル 0 のデータベース・バックアッ プを作成します。

BACKUP AS BACKUPSET INCREMENTAL LEVEL 0 DATABASE PLUS ARCHIVELOG;

アーカイブ・ログ管理

いずれのスタンバイ・サーバーでも自動アーカイブ・ログ削除が構成されていな い場合（または NONE に設定されている場合）、BACKED UP <n> TIMES TO DEVICE TYPE SBT オプションを付けた RMAN DELETE コマンドを使用すること により、少なくとも<n>個のコピーがテープにバックアップされたアーカイブ・ロ グを明示的に削除できます。BACKED UP オプションを使用すると、アーカイブ・ ログの削除前にバックアップが存在することを確実にします。 新しいファイルのためにフラッシュ・リカバリ領域のディスク領域がさらに必要 な場合、フラッシュ・リカバリ領域は保存期間の過ぎたアーカイブ・ログ、また はテープにバックアップされたアーカイブ・ログを自動的に削除します。DELETE コマンドは、追加スペースをただちに再生することが必要な場合に便利です。 たとえば、次に示すコマンドは、7 日以上前に生成されたアーカイブ・ログと、 少なくとも 2 個のバックアップ・コピーがテープにあるアーカイブ・ログをすべ て削除します。

DELETE ARCHIVELOG ALL BACKED UP 2 TIMES TO SBT COMPLETED BEFORE ‘SYSDATE-7’;

リカバリ手順

次のリカバリ・スクリプトでは、プライマリ・ホストとスタンバイ・ホストが同 一のディレクトリ・パス名を持つものとします。パス名が異なる場合、必要な構 文については、「スタンバイ・データベース・ファイル名がプライマリ・データ ベースと異なる場合」を参照してください。

スタンバイ・データベース上での消失したデータファイルのリカバリ

管理されたリカバリ・プロセス（MRP: managed recovery process）は、アーカイブ REDO ログからの情報をスタンバイ・データベースに適用します。Real Time Apply が有効な場合、MRP はスタンバイ REDO ログから直接適用します。スタンバイ・ データベースでデータファイルをリストアおよびリカバリする場合、MRP を行う ディスク上でアーカイブ・ログを使用できることが重要です。スタンバイ・デー タベースとリカバリ・カタログ・データベースの両方に接続する必要があります。 スタンバイ・データベース・データファイルのリカバリには、次の手順が必要で

1. MRP を停止します。

2. スタンバイ・データベースの現在の SCN を調べます。

SQL> SELECT MAX(NEXT_CHANGE#)+1 UNTIL_SCN FROM V$LOG_HISTORY WHERE RESETLOGS_CHANGE# = (SELECT RESETLOGS_CHANGE# FROM V$DATABASE);

UNTIL_SCN --- --- 967786 3. RMAN を使用してデータファイルをリストアします。 RESTORE DATAFILE <n,m...>; #、ここで、n, m はデータファイルの番 号または名前 4. スタンバイ・データベースの現在の SCN まで、RMAN を使用してデータ ファイルをリカバリします。アーカイブ・ログがディスクにない場合、 RMAN はバックアップから自動的にアーカイブ・ログをリストアしてリ ストア・データファイルに適用します。

RECOVER DATABASE UNTIL SCN 967786;

5. MRP を再起動します。

プライマリ・データベース上での消失したデータファイルのリカバリ

プライマリ・データベースのデータファイルをリストアおよびリカバリするには、 次の RMAN コマンドを実行します。（ターゲット・データベースとして）プライ マリ・データベースｘとリカバリ・カタログに接続する必要があります。これら のスクリプトでは、リカバリされるデータファイルがオフラインであると仮定し ています。 RESTORE DATAFILE <n,m...>; #、ここで、n, m はデータファイルの番号ま たは名前 RECOVER DATAFILE <n,m...>;

プライマリ・データベースで表領域をリストアおよびリカバリするには、次の RMAN コマンドを実行します。ターゲット・データベースとして）プライマリ・ データベース（とリカバリ・カタログに接続する必要があります。

RESTORE TABLESPACE <tbs_name1, tbs_name2, ...> RECOVER TABLESPACE <tbs_name1, tbs_name2, ...>

スタンバイ・データベース上での消失した制御ファイルのリカバリ

1 つの制御ファイルが消失した場合

Oracle では、スタンバイ制御ファイルを多重化することができます。スタンバイ 制御ファイルが多重化されているか確認するには、次の SQL を使用して CONTROL_FILES 初期化パラメータをチェックします。

SHOW PARAMETER CONTROL_FILES

NAME TYPE VALUE --- --- --- control_files string <cfilepath1>,<cfilepath2>

多重化されたスタンバイ制御ファイルの 1 つが消失した場合、またはアクセス不 能な場合、Oracle はそのインスタンスを停止し、次のメッセージをアラート・ロ グに書き込みます。

ORA-00210: cannot open the specified controlfile ORA-00202: controlfile: '/../oracle/dbs/scf3_2.f' ORA-27041: unable to open file

1 つの制御ファイルの消失をリカバリするには、次のようにします。

• 他の制御ファイルの 1 つを、破損または消失した位置のディレクトリ （CONTROL_FILES 初期化パラメータにより指定される）にコピーします。 • 使用可能な制御ファイルのみを使用するようにCONTROL_FILES初期化

パラメータを編集し、スタンバイ・データベースを再起動します。詳細

は、『Oracle Data Guard概要および管理』でスタンバイ・データベースの

再起動手順[3]を参照してください。 すべてのスタンバイ・データベース制御ファイルが消失した場合 すべてのスタンバイ制御ファイルが消失した場合、RMAN を使用してスタンバ イ・サーバーで取られたバックアップ制御ファイルをリストアします。 1. （ターゲット・データベースとして）スタンバイ・データベースとリカバリ・ カタログに接続します。

2. バックアップ制御ファイルをリストアします。

RESTORE STANDBY CONTROLFILE;

3. 最後のアーカイブ・ログ・バックアップ以降に生成されたすべてのアーカイ ブ・ログは、「アーカイブ・ログ・バックアップの注意事項」で説明するよ うに、手動でカタログ化することが必要です。 スタンバイ・サーバーのバックアップ制御ファイルを使用できない場合、プライ マリ・データベースから新しい制御ファイルを作成する必要があります。 その手順は次のとおりです。 1. プライマリ・データベースから新しいスタンバイ制御ファイルを作成します。 2. SPFILE に指定されているように、スタンバイ・データベースの多重化された すべての位置に新しい制御ファイルをコピーし、スタンバイ・データベース をマウントします。 3. MRP を再起動します。 4. RMAN で（ターゲット・データベースとして）スタンバイ・データベースと リカバリ・カタログに接続します。 5. 最後のアーカイブ・ログ・バックアップ以降に生成されたすべてのアーカイ ブ・ログを、「アーカイブ・ログ・バックアップの注意事項」で説明するよ うに、手動でカタログ化します。

プライマリ・データベース上での消失した制御ファイルのリカバリ

Oracleでは、プライマリ・データベース上の制御ファイルを多重化できます。プラ イマリ・データベースで制御ファイルの 1 つを更新できない場合、そのプライマ リ・データベース・インスタンスは自動的に停止されます。「スタンバイ・デー タベースでの消失した制御ファイルのリカバリ」で説明した手順と同様、制御ファ イルの正常なコピーを壊れたコピー上にコピーすることで、リストアやリカバリ を行わずにインスタンスを再起動できます。 すべての制御ファイルが消失した場合 プライマリですべての制御ファイルが消失した場合、許容可能な停止時間に応じ て、次の 3 つの選択肢があります。

1. スタンバイ・データベースへのフェイルオーバー

この選択肢は停止時間が最小です。古いプライマリ・データベースが無傷で残っ ている場合、「フェイルオーバーSCN」、すなわち古いスタンバイ・データベー スが新しいプライマリ・データベースになる SCN に簡単にフラッシュバックがで きます。フェイルオーバーSCN は、次の SQL コマンドを使用して調べることがで きます。

SELECT TO_CHAR(STANDBY_BECAME_PRIMARY_SCN) FROM V$DATABASE;

フラッシュバックが完了すると、新しいスタンバイ・データベースは、新しいプ ライマリ・データベースから自動的にREDOを取り戻します。フラッシュバック

の手順[4]は『Oracle Data Guard概要および管理』を参照してください。

古いプライマリ・データベースに問題がある、またはリカバリできない場合、新 しいプライマリ・データベースのバックアップから再作成し、新しいスタンバイ・ データベースとして戻す必要があります。新しいスタンバイ・データベースを再

作成する手順[5]は、『Oracle Data Guard概要および管理』を参照してください。

その他の詳細は、『Oracle Data Guard概要および管理』のフィジカル・スタンバイ・

データベース・フェイルオーバーの手順[6]を参照してください。

2. 新しい制御ファイルの作成

この選択肢は、フェイルオーバーと比較して停止時間が長くなります。新しい制 御ファイルは、NORESETLOGS オプションを使用して作成でき、その後にメディ ア・リカバリを実行します。次の SQL をスタンバイ・データベース・インスタン スで実行することにより、トレース・ファイルを生成できます。

ALTER DATABASE BACKUP CONTROLFILE TO TRACE NORESETLOGS;

結果のトレース・ファイルには、NOMOUNT 状態のプライマリ・データベースで 制御ファイルの再作成に使用できる SQL スクリプトが入ります。 再作成された制御ファイルでは、制御ファイル作成時より前に生成されたアーカ イブ・ログに関する情報がすべて失われます。アーカイブ・ログ・バックアップ をプライマリ・データベースで実行する場合、最後のアーカイブ・ログ・バック アップ以降に生成されたすべてのアーカイブ・ログを、「アーカイブ・ログ・バッ クアップの注意事項」で説明するように再カタログする必要があります。

3. バックアップ制御ファイルを使用したリカバリ

前述の手順で制御ファイルを作成できない場合、プライマリ・データベースから バックアップ制御ファイルを使用して完全リカバリを実行し、RESETLOGS を指 定してオープンします。 制御ファイルをリカバリし、プライマリ・データベースを使用できるようにする には、（ターゲット・データベースとして）NOMOUNT のプライマリ・データベー スとリカバリ・カタログに接続後、次の RMAN コマンドを使用します。 RESTORE CONTROLFILE; ALTER DATABASE MOUNT; RECOVER DATABASE;

前述の RESETLOGS オプションにより作成された新しい REDO ブランチからの アーカイブ・ログをスタンバイ・データベースが受け取ると、スタンバイ・デー タベースは自動的にその新しい REDO ブランチを登録し、MRP を終了します。ス タンバイ・データベース・サーバーで MRP を再起動すると、スタンバイ・データ ベースは自動的に新しい REDO ブランチを追跡します。

Oracle Database 10g で導入された RESETLOGS 機能による新しいリカバリにより、 管理者は、前の REDO ブランチで取ったバックアップからプライマリ・データベー スとスタンバイ・データベースをリカバリできます（インカネーション）。した がって、RESETLOGS 処理後にデータベースの完全バックアップを行う必要はあ りません。 これは最も時間のかかる選択肢ですが、フェイルオーバーまたはスタンバイから 制御ファイルを再作成できない場合に残された唯一の手段です。

消失したオンライン・ログのリカバリ

オンライン・ログ・グループのすべてのメンバーが消失すると、Oracleはそのイン スタンスを終了します。ログ・ファイル・グループのいずれかのメンバーに書き 込みができない場合、そのメンバーはアクセス可能になるまで使用されません。 オンライン・ログ・グループの一部または全部が消失した場合のリカバリ手順[7] は、『Oracle高可用性アーキテクチャおよびベスト・プラクティス』を参照してく ださい。

データベースのブロック・メディア・リカバリ

プライマリまたはスタンバイのデータベースでブロック破損が発生した場合、ブ ロック・メディア・リカバリ（BMR）を使用して、不良ブロックを迅速に修復で きます。このタイプのリカバリは、広範囲のデータファイル破損ではなく、少数 のブロックが破損または消失した場合に最も有効です。バックアップまたはリス トア処理されたすべてのブロックで、物理的破損がチェックされ、オプションで 論理的破損もチェックされます。RMAN VALIDATE コマンドも、ブロック破損の チェックに使用できます。 BMR は、識別済の破損ブロックを最新のバックアップから有効なブロックに置き 換えることで機能し、影響を受けたブロックに対してのみ必要なアーカイブ・ロ グを使用してメディア・リカバリを実行します。BMR がプライマリ・データベー スまたはスタンバイ・データベースのどちらで実行されても、すべてのバックアッ プとアーカイブ・ログにアクセスできることが必要です。 プライマリ・データベースでは、データベースがオンラインで動作している状態 で BMR を実行できます。 スタンバイ・データベースでは、BMR の使用前に MRP を停止し、処理後に再起 動する必要があります。 ブロック・メディア・リカバリの実行方法の詳細は、『バックアップおよびリカ バリ・アドバンスト・ユーザーズ・ガイド』を参照してください。

データベースの不完全リカバリ

ポイント・イン・タイム・リカバリは、通常、プライマリ・データベースが論理 的に破損した場合（ユーザーまたはアプリケーションにより）、あるいは表領域 またはデータファイルがデータベースから誤って削除された場合に行われます。 これらのエラーからリカバリするオプションを実行しやすい順に示します。 • 論理的破損がスタンバイ・データベースに伝播していない場合、プライ マリ・データベースを論理的破損前の状態にフラッシュバックし、プラ イマリ・データベースで RESETLOGS をオープンし、スタンバイ・デー タベースで REDO 適用を再起動します。プライマリ・データベースでフ ラッシュバックが構成されていない場合は、スタンバイ・データベース でポイント・イン・タイム・リカバリを実行して論理的破損前の状態に 戻し、フェイルオーバーを実行して、スタンバイ・データベースを新し いプライマリ・データベースとして起動します。旧プライマリ・サイト で新しいスタンバイ・データベースの再作成が必要です。 • 論理的破損がスタンバイ・データベースに伝播している場合、プライマ リ・データベースとスタンバイ・データベースを論理的破損前の状態に フラッシュバックし、プライマリ・データベースで RESETLOGS をオー プンして、スタンバイ・データベースで適用を再起動します。1 つのスタ ンバイ・データベース・サーバーでのみフラッシュバックが構成されて いる場合、そのサーバーでフラッシュバックを実行して論理的破損前の 状態に戻し、スタンバイ・データベースを新しいプライマリ・データベー スとして起動します。他のすべてのスタンバイ・データベースを、新し い REDO ブランチを追跡する新しいスタンバイ・データベースとして再 作成する必要があります。

これらの手順[8]は、『Oracle Data Guard概要および管理』で詳しく説明していま

す。

スイッチオーバー/フェイルオーバー後の手順や構成の変更点

スイッチオーバーまたはフェイルオーバーが発生した場合、データベース・ロー ルが変わるため、RMAN構成設定も変更する必要があります。新しいプライマリ・ データベース、バックアップが行われる新しいスタンバイ・データベースおよび 他のスタンバイ・データベースについて、適切な構成の設定は「RMANの推奨構 成」を参照してください。

アーカイブ・ログ・バックアップの注意事項

スタンバイ・データベースで、最後のアーカイブ・ログ・バックアップ後に受け 取ったアーカイブ・ログを RMAN に明示的に知らせる必要がある、すなわち再カ タログが必要な場合、2 つのケースがあります。これは、次の場合に発生します。

• プライマリ制御ファイルまたはスタンバイ制御ファイルが再作成された • スイッチオーバーまたはフェイルオーバーの処理後にデータベース・

ロールがスタンバイまたはプライマリに変わった

たとえば、スイッチオーバーまたはフェイルオーバーでは、新しいプライマリ・ データベースに接続し、次の RMAN コマンドを実行します。

CATALOG ARCHIVELOG ‘<archived log filename 1>’, ’<archived log filename 2>’, etc. ;

‘<Archived log filename 1>’, etc は、最後のアーカイブ・ログ・バックアップ後に生 成されたアーカイブ・ログを参照します。たとえば、通常のバックアップ・ジョ ブを毎日午前 10 時に開始して午前 11 時に終了する場合、午前 11 時からスイッチ オーバーの時点までに生成されたすべてのアーカイブ・ログをカタログ化する必 要があります。これらのアーカイブ・ログは、次回の通常バックアップ・ジョブ の際にバックアップされます。 注意: スタンバイ・インスタンスが受け取ったアーカイブ・ログのみをスタンバ イ・サイトでバックアップできます。スタンバイのインスタンス化前に作成され たアーカイブ・ログは、プライマリ・データベースでバックアップする必要があ ります。

RMAN によるスタンバイ・データベースのインスタンス化

次の手順で、RMAN を使用してスタンバイ・データベースをインスタンス化する 典型的な方法を概説します。RMAN の DUPLICATE コマンドは、バックアップ・ セットからデータファイルをリストアし、データベースを現在または UNTIL に指 定された時刻/SCN にリカバリします（増分バックアップおよびアーカイブ・ロ グ・バックアップを適用）。この手順は、Data Guard 構成をセットアップする、 メディア障害後または災害後にスタンバイ・データベースをリカバリする、また はフェイルオーバー処理後に旧プライマリ・データベースを新しいスタンバイ・ データベースとして再インスタンス化するなどの場合に使用できます。 1. スタンバイ・サーバーに Oracle データベースをインストールします。 2. スタンバイ・データベース用の初期化パラメータ・ファイルを作成します。

SPFILE は、RMAN RESTORE SPFILE コマンドを使用してバックアップから リストアできます。

3. SPFILE を使用して、NOMOUNT でスタンバイ・インスタンスを開始します。 4. スタンバイ・データベース・ホストへの接続に必要な Oracle Net セットアッ

5. 次の RMAN コマンドを実行することにより、制御ファイルのバックアップを 生成します。（ターゲットとして）プリイマリ・データベースとリカバリ・ カタログに接続することが必要です。

BACKUP CURRENT CONTROLFILE FOR STANDBY;

6. 制御ファイル・バックアップおよびデータファイルとアーカイブ・ログの既 存のバックアップを使用して、新しいスタンバイ・データベースをインスタ ンス化します。 RMAN がプライマリ・データベース、カタログ・データベースおよびスタン バイ・データベース・インスタンスに接続されていることを確認してくださ い。AUXILIARY キーワードを使用し、NOMOUNT 状態でスタンバイ・イン スタンスに接続します。

> RMAN TARGET <primary_db> CATALOG <catalog_db> AUXILIARY <new_standby_db>

次の RMAN コマンドを実行し、現在の時刻/SCN で新しいスタンバイ・デー タベースを作成します。

DUPLICATE TARGET DATABASE FOR STANDBY;

RMAN によりスタンバイ・データベースをインスタンス化する代替方

法

前述の手順は自動的にスタンバイ・データベースを作成するため、スタンバイ・ サイトですべてのバックアップ・セットが使用可能な場合に正しく機能します。 ファイルのサイズ上の理由から（テラバイト規模のデータベースなど）、すべて のバックアップ・セットをネットワークを介してスタンバイ・サイトに転送する ことが事実上不可能な場合、次の手順でもスタンバイ・データベースをインスタ ンス化できます。このシナリオでは、完全バックアップはテープでスタンバイ・ サイトに送付されますが、増分バックアップはネットワークを介して送信されま す。 1. スタンバイ・サーバーに Oracle データベースをインストールします。 2. インスタンス・パラメータ・ファイル（SPFILE）をスタンバイ・サーバーに コピーし、その SPFILE を使用して NOMOUNT でスタンバイ・データベース・ インスタンスを開始します。 3. プライマリ・データベースからスタンバイ制御ファイルを作成し、それをス タンバイ・データベース・サーバーにコピーし、スタンバイ・データベース をマウントします。 4. 完全バックアップをプライマリ・サイトからスタンバイ・サイトにテープで 送付します。

5. 完全バックアップのテープの送付中やスタンバイ・サーバーへのリストア中 も、プライマリ・データベースで増分バックアップおよびアーカイブ・ログ・ バックアップを継続的に取り、毎日ネットワークを介して送信できます（FTP など）。 6. スタンバイ・サーバーでテープにアクセス可能になれば、完全バックアップ からのデータファイルをリストアできます。リカバリ・カタログと（ターゲッ ト・データベースとして）スタンバイ・データベースに接続後、データファ イルをリストアします。 RESTORE DATAFILE <n,m>; 7. すべてのデータファイルがリストアされ、すべてのアーカイブ・ログ・バッ クアップがスタンバイ・サイトにある場合、アーカイブ・ログと増分バック アップを適用します。 RECOVER DATABASE; 8. アーカイブ・ログの一部がスタンバイ・サイトになくても増分バックアップ がある場合は、増分バックアップのみを適用できます。

RECOVER DATABASE NOREDO;

9. MRPを再起動します。FAL_SERVERパラメータとFAL_CLIENTパラメータが すでにセットアップ済の場合、消失したアーカイブ・ログが自動的にフェッ チされ、スタンバイ・データベースに適用されます。そうでない場合、消失 したアーカイブ・ログを手動でスタンバイ・データベースにコピーし、「アー カイブ・ログ・バックアップの注意事項」で説明したように再カタログして から適用する必要があります。

結論

Oracle Data Guard は、拡張管理機能や監視機能などにより、Oracle データ資産を 障害から非常に幅広く保護します。データベースにインストールされる設定不要 のバックアップおよびリカバリ・ツールである Oracle Recovery Manager（RMAN） と併用することで、プライマリまたはスタンバイ・データベース・サイトでメディ ア消失が発生しても Oracle データベースを完全にリカバリできます。スタンバ イ・データベースの作成と再インスタンス化も、RMAN を使用して実行できます。 これらの手順をリカバリ計画に組み入れ、徹底的に検証することにより、Data Guard 構成におけるメディア・リカバリ停止に対して効率的で広範なテクニック を獲得することができます。

参照資料

1. Using Recovery Manager (RMAN) with Oracle Data Guard in Oracle9i（英語）

http://www.oracle.com/technology/deploy/availability/pdf/RMAN_DataGuard_9iR2 _wp.pdf

2. Oracle Flashback Database: Point-in-Time リカバリの代替方法、『Oracle Database バックアップおよびリカバリ・アドバンスト・ユーザーズ・ガイド』： http://otndnld.oracle.co.jp/document/products/oracle10g/101/doc_v12/nav/portal_4.h tm

3. フィジカル・スタンバイ・データベースの起動と停止、『Oracle Data Guard 概要および管理』: http://otndnld.oracle.co.jp/document/products/oracle10g/101/doc_v12/nav/portal_4.h tm 4. フェイルオーバー後のフラッシュバック・データベースの使用、『Oracle Data Guard 概要および管理』: http://otndnld.oracle.co.jp/document/products/oracle10g/101/doc_v12/nav/portal_4.h tm

5. フィジカル・スタンバイ・データベースの作成、『Oracle Data Guard 概要およ び管理』: http://otndnld.oracle.co.jp/document/products/oracle10g/101/doc_v12/nav/portal_4.h tm 6. フィジカル・スタンバイ・データベースが関与するフェイルオーバー、『Oracle Data Guard 概要および管理』: http://otndnld.oracle.co.jp/document/products/oracle10g/101/doc_v12/nav/portal_4.h tm 7. 実行するリカバリ処置の決定、『Oracle 高可用性アーキテクチャおよびベス ト・プラクティス』 http://otndnld.oracle.co.jp/document/products/oracle10g/101/doc_v12/nav/portal_4.h tm

8. OPEN RESETLOGS 文を使用したリカバリ、『Oracle Data Guard 概要および管 理』:

http://otndnld.oracle.co.jp/document/products/oracle10g/101/doc_v12/nav/portal_4.h tm

付録

発信元ホストで取ったバックアップが使用できない場合

環境によっては、地理的位置、ファイアウォールなどの要因により、プライマリ・ データベース・サイトとスタンバイ・データベース・サイト間でバックアップを 共有できないことがあります。このような場合、このホワイト・ペーパーで説明 したバックアップ手順およびリカバリ手順で RMAN TAG 機能を使用する必要が あります。また、プライマリ・データベースとスタンバイ・データベースの完全 バックアップが必要です。 次の点を変更することにより、このホワイト・ペーパーで説明した一般的方針を 使用できます。 • RMAN により作成されたバックアップ・ファイルにローカル・システム 名の入ったタグを付け、リストア時にはそのタグを使用して、RMAN が リモート・ホストで取ったバックアップを選択しないように制限します。 BACKUP コマンドではバックアップの作成に TAG ‘<server name>’オプ ションを、RESTORE コマンドでは FROM TAG ‘<server name>’オプショ ンを、RECOVER コマンドでは FROM TAG ‘<server name> ARCHIVELOG TAG ‘<server name>’オプションを、それぞれ使用する必要があります。 • スタンバイ・データベースの再インスタンス化では、TAG 構文が必要で す。スタンバイ・データベースを再インスタンス化する手順は次のとお りです。 1. スタンバイが動作していた同じパラメータ・ファイルを使用して、 NOMOUNT 状態でスタンバイ・インスタンスを開始します。SPFILE から PFILE の現在のコピーを取得するには、次の SQL を使用できま す。

CREATE PFILE=’<filename>’ FROM SPFILE;

2. 次の SQL を使用して、プライマリ・インスタンスでスタンバイ制御 ファイルを作成します。

ALTER DATABASE CREATE STANDBY CONTROLFILE AS ‘<file name>’;

3. 新しい制御ファイルを使用して、スタンバイ・インスタンスをマウン トします。

4. 次の RMAN コマンドを実行して、データベース・ファイルをリスト アおよびリカバリします。

RESTORE DATABASE FROM TAG ‘<server name used in BACKUP command>’;

RECOVER DATABASE FROM TAG ‘<server name used in BACKUP command>’ ARCHIVELOG TAG ‘<server name used in BACKUP command>’; 5. MRP を再起動します。

アーカイブ・ログ・リポジトリとして構成されたスタンバイ・データ

ベース

スタンバイ・データベースは、アーカイブ・ログのためのリモート・バックアッ プとして機能するアーカイブ・ログ・リポジトリとして構成できます。リポジト リにはデータファイルがありません。リポジトリは、消失したアーカイブ・ログ を取り出すために他のスタンバイ・データベースが使用できます。この構成の詳

細は、『Oracle Data Guard概要および管理』を参照してください。

「バックアップ手順」のセクションに示したスクリプトは、アーカイブ・ログ・リ ポジトリのバックアップにも使用できます。ただし、データファイルがないため、 データファイルをバックアップするRMANコマンドは省略してください。また、 MRPは実行されません。

スタンバイ・データベース・ファイル名がプライマリ・データベース

と異なる場合

このセクションでは、プライマリ・データベースとスタンバイ・データベースで ファイル名が異なる場合に、そのいずれかをリストアおよびリカバリする方法を 説明します。RMAN がリカバリ・カタログにデータベースを登録する場合、RMAN は制御ファイルから分かるデータファイル名を記録します。Data Guard 構成で RMAN を使用している場合、データファイル名はプライマリ・データベース制御 ファイルに基づいてリカバリ・カタログに記録されます。 この動作のため、RESTORE コマンドと RECOVER コマンドは、このホワイト・ ペーパーで前述したものとは少し異なります。たとえば、プライマリ・データベー ス・バックアップからスタンバイ・データベースをリストアする場合、スタンバ イ・データベースの実際のデータファイル名は V$DATAFILE ビューから取得でき、 すべてのデータファイルについて、次のように SET NEWNAME オプションで名 前を指定する必要があります。

RUN {

SET NEWNAME FOR DATAFILE 1 TO ‘<existing file location for file#1 from V$DATAFILE>’;

SET NEWNAME FOR DATAFILE 2 TO ‘<existing file location for file#2 from V$DATAFILE>’;

… …

SET NEWNAME FOR DATAFILE n TO ‘<existing file location for file#n from V$DATAFILE>’;

RESTORE {DATAFILE <n,m,…> | TABLESPACE <tbs_name_1, 2, …| DATABASE};

SWITCH DATAFILE ALL;

RECOVER DATABASE {NOREDO}; }

同様に、RMAN DUPLICATE の実行前にも、SET NEWNAME を使用してスタンバ イ・データベース作成中に新しいファイル名を指定する必要があります。

Oracle Database 10g における Oracle Data Guard での Recovery Manager の使用 2005 年 9 月

著者: Anand Beldalker, Timothy Chien

寄稿者: Steven Wertheimer, Antonio Romero, Ashish Ray, Lawrence To, Douglas Utzig, Tammy Bednar, Joe Meeks, Larry Carpenter

Oracle Corporation World Headquarters 500 Oracle Parkway Redwood Shores, CA 94065 U.S.A. 海外からのお問合せ窓口: 電話: +1.650.506.7000 ファックス: +1.650.506.7200 www.oracle.com Copyright © 2005, Oracle. 無断転載を禁ず。 この文書はあくまで参考資料であり、掲載されている情報は予告なしに変更されることがあります。 オラクル社は、本ドキュメントの無謬性を保証しません。また、本ドキュメントは、法律で明示的または暗黙的に記載 されているかどうかに関係なく、商品性または特定の目的に対する適合性に関する暗黙の保証や条件を含む一切の保証 または条件に制約されません。オラクル社は、本書の内容に関していかなる保証もいたしません。また、本書により、 契約上の直接的および間接的義務も発生しません。本書は、事前の書面による承諾を得ることなく、電子的または物理 的に、いかなる形式や方法によっても再生または伝送することはできません。

Oracle、JD Edwards、PeopleSoft は、Oracle Corporation および関連会社の登録商標です。他の製品名は、それぞれの 所有者の商標です。