11g リリース1（11.1）
E05700-03
 目次 |
 索引 |
| Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド 11g リリース1（11.1） E05700-03 |
|
この章は、このマニュアルの各章の詳細を最初に読まずに、Recovery Managerをすぐに使用し始める必要がある新しいユーザーを対象としています。この章では、Recovery Managerの最も重要な概念とタスクについてできるかぎり簡潔に説明しますが、この章を他のバックアップおよびリカバリのドキュメント・セットのかわりにすることはできません。
この章の内容は、次のとおりです。
Recovery Manager（RMAN）とは、データベースでバックアップおよびリカバリ・タスクを実行し、バックアップ計画の管理を自動化するOracle Databaseクライアントのことです。Recovery Managerによって、データベースのバックアップ、リストアおよびリカバリが大幅に簡単になります。
Recovery Manager環境は、データのバックアップに使用されるユーティリティとデータベースで構成されます。Recovery Managerの環境には、最低限次のコンポーネントが含まれている必要があります。
Recovery ManagerがTARGETキーワードで接続されているOracle Database。ターゲット・データベースは、Recovery Managerがバックアップおよびリカバリ操作を実行するデータベースです。Recovery Managerは、常にデータベースの操作に関するメタデータをデータベースの制御ファイルに保持します。Recovery Managerのメタデータは、Recovery Managerリポジトリと呼ばれます。
コマンドを解釈し、それらのコマンドを実行するようにサーバー・セッションに指示し、そのアクティビティをターゲット・データベースの制御ファイルに記録するOracle Database実行可能ファイル。このRecovery Manager実行可能ファイルは、データベースとともに自動的にインストールされ、通常、他のデータベース実行可能ファイルと同じディレクトリに配置されます。たとえば、Linuxの場合、Recovery Managerクライアントは$ORACLE_HOME/binに配置されています。
一部の環境では、次のオプションのコンポーネントが使用されます。
バックアップおよびリカバリに関連するファイルをデータベースで格納および管理できるディスクの場所。フラッシュ・リカバリ領域の場所およびサイズは、DB_RECOVERY_FILE_DESTおよびDB_RECOVERY_FILE_DEST_SIZE初期化パラメータを使用して設定します。
Recovery Managerがテープ・ライブラリなどのシーケンシャル・メディア・デバイスとインタフェースを取るために必要なアプリケーション。メディア・マネージャは、バックアップおよびリカバリ中にこれらのデバイスを制御し、メディアのロード、ラベル付けおよびアンロードを管理します。メディア管理デバイスはSBT（テープへのシステム・バックアップ）デバイスと呼ばれる場合があります。
1つ以上のターゲット・データベースに対するRecovery Managerアクティビティを記録するために使用する個別のデータベース・スキーマ。リカバリ・カタログは、制御ファイルが消失した場合にRecovery Managerリポジトリ・メタデータを保持することで、制御ファイル消失後のリストアおよびリカバリを簡単に実行できるようにします。データベースは制御ファイル内の古いレコードを上書きする場合がありますが、Recovery Managerはユーザーが削除しないかぎり、カタログ内にレコードを永久に保持します。
この章では、リカバリ・カタログまたはメディア・マネージャを使用しない最も基本的な構成でRecovery Managerを使用する方法について説明します。
Recovery Managerクライアントは、オペレーティング・システムのコマンド・プロンプトでrmanコマンドを発行して起動します。Recovery Managerを起動すると、次の例に示すようなコマンド・プロンプトが表示されます。
% rman RMAN>
Recovery Managerによるデータベースへの接続は、SQL*Plusによるデータベースへの接続と同じ方法で指定および認証します。Recovery Managerによるターゲット・データベースまたは補助データベースへの接続にはSYSDBA権限が必要である点のみが異なります。AS SYSDBAキーワードは、暗黙的に指定され、明示的には指定できません。SQL*Plusを使用する場合のデータベース接続オプションについては、『Oracle Database管理者ガイド』を参照してください。
データベースには、コマンドライン・オプションまたはCONNECT TARGETコマンドを使用して接続できます。次の例では、Recovery Managerを起動し、Oracle Netを介してターゲット・データベースに接続します（AS SYSDBAは暗黙的に指定されるため、指定されていないことに注意してください）。Recovery Managerによってパスワードの入力を求められます。
% rman RMAN> CONNECT TARGET SYS@prod target database Password: password connected to target database: PROD (DBID=39525561)
次の例では、Recovery Managerを起動してから、オペレーティング・システム認証を使用してターゲット・データベースに接続します。
% rman RMAN> CONNECT TARGET / connected to target database: PROD (DBID=39525561)
Recovery Managerクライアントを終了するには、Recovery ManagerプロンプトでEXITと入力します。
RMAN> EXIT
RMAN [ TARGET connectStringSpec | { CATALOG connectStringSpec } | LOG ['] filename ['] [ APPEND ] . . . ]... connectStringSpec::= ['] [userid] [/ [password]] [@net_service_name] [']
次の例では、/tmp/msglog.logにあるテキスト・ファイルにRecovery Managerセッションの出力を追加します。
% rman TARGET / LOG /tmp/msglog.log APPEND
Recovery Managerのバックアップおよびリカバリ環境は、ターゲット・データベースごとに事前構成されます。この構成は、Recovery Managerを終了して再起動した場合でも永続し、このターゲット・データベースで行うその後のすべての操作に適用されます。
Recovery Managerの構成済の設定では、バックアップ・デバイスを指定し、バックアップ・デバイスへの接続（チャネルと呼ばれる）、バックアップ計画に影響する方針などを構成できます。ほとんどの場合は、デフォルトの構成で十分です。
SHOW ALLコマンドを実行します。たとえば、Recovery Managerプロンプトでコマンドを次のように入力します。
RMAN> SHOW ALL;
出力には、この構成を再作成するためのCONFIGUREコマンドが表示されます。
|
参照:
Recovery Manager環境の構成方法については、第5章「Recovery Manager環境の構成」および第6章「Recovery Manager環境の構成: 高度なトピック」を参照してください。 |
ファイルをバックアップするには、BACKUPコマンドを使用します。Recovery Managerは、要求されたバックアップのタイプ用に構成されているデフォルトのデバイスにデータをバックアップします。デフォルトでは、Recovery Managerはディスクにバックアップを作成します。フラッシュ・リカバリ領域が有効になっていて、FORMATパラメータ（表2-1を参照）を指定していない場合、Recovery Managerは、リカバリ領域にバックアップを作成し、自動的に一意の名前を指定します。
デフォルトでは、Recovery Managerはイメージ・コピーではなくバックアップ・セットを作成します。バックアップ・セットは、1つ以上のバックアップ・ピースで構成されています。バックアップ・ピースとは、Recovery Managerのみがアクセス可能な形式で書き込まれた物理ファイルのことです。多重バックアップ・セットには、複数の入力ファイルからのブロックが含まれています。Recovery Managerは、バックアップ・セットをディスクまたはテープに書き込むことができます。
BACKUP AS COPYを指定すると、Recovery Managerは各ファイルをイメージ・コピーとしてコピーします。イメージ・コピーは、ディスクに作成されたデータベース・ファイルのビットごとのコピーです。イメージ・コピーは、LinuxのcpやWindowsのCOPYなどのオペレーティング・システム・コマンドで作成したコピーと同じですが、Recovery Managerのリポジトリに記録されるため、Recovery Managerで使用できます。Recovery Managerを使用すると、データベースがオープンしている間にイメージ・コピーを作成できます。
|
参照:
|
データベースは、ARCHIVELOGモードで稼働している場合、オープン状態でバックアップできます。このバックアップは、データベースを一貫性のある状態にするためにリカバリ時にREDOが必要となるため、非一貫性バックアップと呼ばれます。オープン状態のデータベースのバックアップは、バックアップのリカバリに必要なアーカイブREDOログが存在するかぎり、データ保護の手段として一貫性バックアップと同様に効率的です。
BACKUP DATABASEコマンドを実行します。たとえば、Recovery Managerプロンプトで次のコマンドを入力して、データベースおよびすべてのアーカイブREDOログ・ファイルをデフォルトのバックアップ・デバイスにバックアップします。
RMAN> BACKUP DATABASE PLUS ARCHIVELOG;
データベースがNOARCHIVELOGモードで稼働している場合、有効なデータベースのバックアップは一貫性バックアップのみです。バックアップに一貫性を持たせるには、データベースを一貫性のある状態で停止させた後でマウントする必要があります。バックアップをリストアした後で、リカバリを実行する必要はありません。
たとえば、バックアップのためにデータベースを一貫性のある状態にするには、次のコマンドを入力します。
RMAN> SHUTDOWN IMMEDIATE; RMAN> STARTUP FORCE DBA; RMAN> SHUTDOWN IMMEDIATE; RMAN> STARTUP MOUNT;
BACKUP DATABASEコマンドを実行します。たとえば、Recovery Managerプロンプトで次のコマンドを入力して、データベースをデフォルトのバックアップ・デバイスにバックアップします。
RMAN> BACKUP DATABASE;
次のコマンドは、データベース内のすべてデータファイルのイメージ・コピー・バックアップを作成します。
RMAN> BACKUP AS COPY DATABASE;
データベースをオープンするには、次のコマンドを入力します。
RMAN> ALTER DATABASE OPEN;
BACKUPコマンドには、バックアップの出力を制御する多くのオプション、パラメータおよび句が含まれています。次の表に、一般的なバックアップ・オプションの一部を示します。
| オプション | 説明 | 例 |
|---|---|---|
|
|
バックアップ・ピースおよびコピー用の位置と名前を指定します。一意のファイル名を生成するには、置換変数を使用する必要があります。
最も一般的な置換変数は、一意の名前を生成する |
BACKUP |
|
|
バックアップ用のラベルとしてユーザー定義文字列を指定します。タグを指定しない場合、Recovery Managerは、日付と時刻を含むデフォルト・タグを割り当てます。Recovery Managerリポジトリでは、タグは常に大文字で格納されることに注意してください。 |
BACKUP |
BACKUP INCREMENTALを指定すると、Recovery Managerはデータベースの増分バックアップを作成します。増分バックアップでは、前回の増分バックアップ後に行われたデータベースへのブロックレベルの変更が取得されます。通常、増分バックアップは、データベースの全体バックアップより小さく、高速です。増分バックアップを使用したリカバリは、REDOログのみを使用したバックアップより高速です。
増分バックアップ方針の開始点は、レベル0の増分バックアップ（データベースのすべてのブロックのバックアップ）です。レベル0の増分バックアップの内容は全体バックアップと同じです。ただし、レベル0のバックアップは、全体バックアップと異なり、増分バックアップ計画の一部とみなされます。
レベル1の増分バックアップには、前回の増分バックアップ後に変更されたブロックのみが格納されます。レベル1のバックアップの実行時に現行または親のデータベース・インカネーションにレベル0のバックアップが存在しない場合は、Recovery Managerによってレベル0のバックアップが自動的に作成されます。
レベル1のバックアップは、累積増分バックアップ（最新のレベル0のバックアップ後に変更されたブロックをすべて含む）または差分増分バックアップ（最新の増分バックアップ後に変更されたブロックのみを含む）のいずれかにできます。増分バックアップは、デフォルトでは差分バックアップです。
増分バックアップからのリストア時には、レベル0のバックアップが開始点として使用され、その後、変更をREDOから1つずつ再適用することを回避できるレベル1のバックアップに基づいて、変更されたブロックが更新されます。増分バックアップを使用したリカバリでは、ユーザーがその他の作業を行う必要はありません。増分バックアップが使用可能な場合、Recovery Managerはリカバリ時に増分バックアップを使用します。
BACKUP INCREMENTALコマンドを実行します。次の例では、増分バックアップ計画の基礎となるレベル0の増分バックアップを作成します。
BACKUP INCREMENTAL LEVEL 0 DATABASE;
次の例では、レベル1の累積増分バックアップを作成します。
BACKUP INCREMENTAL LEVEL 1 CUMULATIVE DATABASE;
次の例では、レベル1の差分増分バックアップを作成します。
BACKUP INCREMENTAL LEVEL 1 DATABASE;
Recovery Managerの増分更新バックアップ機能は、効率的な増分バックアップ・ルーチンです。レベル1のバックアップからの変更によって、イメージ・コピーのレベル0の増分バックアップがロールフォワードされます。このため、この変更には、レベル1の増分バックアップが作成されたSCNの時点でのすべての変更が含まれます。レベル1の増分バックアップからのすべての変更はすでに適用されているため、更新されたレベル0の増分バックアップのリカバリが高速になります。
BACKUP FOR RECOVER OF COPYコマンドを指定すると、データベースの指定したデータファイル・コピー（レベル0の増分バックアップ）のSCN以降のすべての変更が増分バックアップに含まれるようになります。次の表に、増分更新バックアップ計画の実装のために、FOR RECOVER OF COPYで使用するオプションを示します。
| BACKUPオプション | 説明 | 例 |
|---|---|---|
|
|
|
BACKUP INCREMENTAL LEVEL 1 |
|
|
増分バックアップの基礎として使用するデータファイル・コピーを識別します。 |
BACKUP INCREMENTAL LEVEL 1 |
RECOVER COPYおよびBACKUP INCREMENTALコマンドを実行します。増分更新バックアップに基づく計画を実装するには、次のスクリプトを定期的に実行する必要があります。
RECOVER COPY OF DATABASE WITH TAG 'incr_update'; BACKUP INCREMENTAL LEVEL 1 FOR RECOVER OF COPY WITH TAG 'incr_update' DATABASE;
VALIDATEコマンドを使用すると、すべてのデータベース・ファイルが適切な場所に存在しており、物理的に破損していないかどうかを確認できます。CHECK LOGICALオプションを指定すると、論理ブロックの破損も確認できます。
VALIDATEコマンドを実行します。たとえば、すべてのデータベース・ファイルおよびアーカイブREDOログ・ファイルの物理的および論理的な破損を検証するには、次のコマンドを入力します。
BACKUP VALIDATE CHECK LOGICAL DATABASE ARCHIVELOG ALL;
次の例に示すように、VALIDATEコマンドを使用すると、個々のデータ・ブロックを検証することができます。
VALIDATE DATAFILE 4 BLOCK 10 TO 13;
次の例に示すように、バックアップ・セットを検証することもできます。
VALIDATE BACKUPSET 3;
バックアップ・セットの指定には、LIST BACKUPコマンドの出力に表示されるプライマリ・キーを使用します。
Recovery Managerでは、週次バックアップなどの繰り返し行うタスクを管理するためのコマンド・ファイルを使用できます。コマンド・ファイルとは、Recovery Managerプロンプトで入力するRecovery Managerコマンドと同じコマンドが含まれているクライアント側のテキスト・ファイルのことです。任意のファイル拡張子を指定できます。RUNコマンドを使用すると、スクリプト内の処理のフローをある程度制御できます。
たとえば、次の内容でコマンド・ファイルを作成します。
# my_command_file.txt CONNECT TARGET / BACKUP DATABASE PLUS ARCHIVELOG; LIST BACKUP; EXIT;
@コマンドを実行することによってコマンド・ファイルの内容を実行します。
% rman RMAN> @/my_dir/my_command_file.txt# runs specified command file
次に示すように、実行するコマンド・ファイルを使用してRecovery Managerを起動することもできます。
% rman @/my_dir/my_command_file.txt
|
参照:
コマンド・ファイルの詳細は「Recovery Managerでのコマンド・ファイルの使用」、コマンド・ファイルで置換変数を使用して実行時にパラメータを渡す方法は「コマンド・ファイルでの置換変数の使用」を参照してください。 |
Recovery ManagerのLISTおよびREPORTコマンドは、Recovery Managerのリポジトリに基づいて、バックアップ・アクティビティに関するレポートを生成します。SHOW ALLコマンドを使用すると、Recovery Managerの現行の構成が表示されます。
リポジトリに含まれているバックアップおよびデータファイル・コピーに関する情報を表示するには、LIST BACKUPおよびLIST COPYコマンドを実行します。バックアップに対しては、次の表に示すオプションを使用して、LISTの出力形式を制御できます。
バックアップおよびコピーの両方に、次の追加オプションがあります。
| オプション | 例 | 説明 |
|---|---|---|
|
|
|
Recovery Managerリポジトリに記録されているが、前回の |
|
|
|
Recovery Managerリポジトリのステータスが |
LISTコマンドを実行します。次の例に示すように、特定のオブジェクトを表示できます。
LIST BACKUP OF DATABASE; LIST COPY OF DATAFILE 1, 2; LIST BACKUP OF ARCHIVELOG FROM SEQUENCE 10; LIST BACKUPSET OF DATAFILE 1;
REPORTコマンドは、LISTより複雑な分析を実行します。次の表に、主なオプションを示します。
| オプション | 例 | 説明 |
|---|---|---|
|
|
|
現行の保存方針に従ってバックアップする必要があるファイルを表示します。オプションの |
|
|
|
構成済のバックアップの保存方針に従って不要となっているバックアップを表示します。オプションの |
|
|
|
現在の時刻（デフォルト）または別の時刻のデータベース内の表領域およびデータファイルを報告します。 |
|
|
|
データファイルの前回のバックアップ以降に、データファイル内のオブジェクトに対してリカバリ不能な操作が実行されているすべてのデータファイルを表示します。 |
REPORTコマンドを実行します。次の例では、現在構成されているバックアップ保存方針に従って不要となったバックアップをレポートします。
REPORT OBSOLETE;
次の例では、データベースのデータファイルおよび一時ファイルをレポートします。
REPORT SCHEMA;
Recovery Managerリポジトリ・メタデータは、ターゲット・データベースの制御ファイルに常に格納されます。このメタデータは、バックアップの管理時にRecovery Managerのメンテナンス・コマンドで使用されます。
CROSSCHECKコマンドは、Recovery Managerバックアップおよびコピーの論理レコードをストレージ・メディアのファイルと同期化します。バックアップがディスク上に存在する場合は、CROSSCHECKによって、そのファイルのヘッダーが有効かどうかが判別されます。バックアップがテープ上に存在する場合は、Recovery Managerによって、バックアップ・ピースの名前と場所の問合せがRecovery Managerリポジトリに対して実行されます。この場合、バックアップおよびコピーは、クロスチェックしてから削除することをお薦めします。
CROSSCHECKコマンドを実行します。
CROSSCHECK BACKUP; CROSSCHECK COPY;
DELETEコマンドは、ディスクおよびテープからRecovery Managerのバックアップおよびコピーを削除し、制御ファイル・リポジトリ内のファイルのステータスをDELETEDに更新し、リカバリ・カタログからレコードを削除します（カタログを使用している場合）。Recovery Managerを対話形式で実行し、NOPROMPTオプションを指定しなかった場合は、DELETEによってファイルのリストが表示され、リスト内のファイルを削除する前に確認を求められます。
Recovery Managerリポジトリに記録されているバックアップおよびデータファイルのコピーのうち不要なものが削除されるため、DELETE OBSOLETEコマンドは特に役に立ちます。DELETEコマンドでオプションを使用すると、不要なものを指定したり、構成済のバックアップの保存方針を使用することができます。
データベースに関する問題を診断して修復する最も簡単な方法は、データ・リカバリ・アドバイザを使用する方法です。このOracle Databaseツールによって、永続的なデータの障害を診断し、ユーザーに修復オプションを提示して、修復を自動的に実行するインフラストラクチャが提供されます。
障害とは、状態モニターによって検出される永続的なデータの破損のことです。例としては、物理的および論理的なデータ・ブロックの破損やデータファイルの欠落などがあります。各障害には、障害優先順位および障害ステータスがあります。優先順位は、CRITICAL、HIGHまたはLOWのいずれかになります。ステータスは、OPENまたはCLOSEDのいずれかになります。
LIST FAILUREコマンドを実行すると、すべての既知の障害を表示できます。障害が存在する場合は、同じセッションでADVISE FAILUREコマンドを実行し、手動および自動の修復オプションを決定します。次に、これらの2つのコマンドの例を示します（出力例も示します）。
RMAN> LIST FAILURE;
List of Database Failures
=========================
Failure ID Priority Status Time Detected Summary
---------- -------- --------- ------------- -------
142 HIGH OPEN 23-APR-07 One or more non-system datafiles are missing
101 HIGH OPEN 23-APR-07 Datafile 1: '/disk1/oradata/prod/system01.dbf'
contains one or more corrupt blocks
RMAN> ADVISE FAILURE;
List of Database Failures
=========================
Failure ID Priority Status Time Detected Summary
---------- -------- --------- ------------- -------
142 HIGH OPEN 23-APR-07 One or more non-system datafiles are missing
101 HIGH OPEN 23-APR-07 Datafile 1: '/disk1/oradata/prod/system01.dbf'
contains one or more corrupt blocks
analyzing automatic repair options; this may take some time
using channel ORA_DISK_1
analyzing automatic repair options complete
Mandatory Manual Actions
========================
no manual actions available
Optional Manual Actions
=======================
1. If file /disk1/oradata/prod/users01.dbf was unintentionally renamed or moved, restore it
Automated Repair Options
========================
Option Repair Description
------ ------------------
1 Restore and recover datafile 28; Perform block media recovery of
block 56416 in file 1
Strategy: The repair includes complete media recovery with no data loss
Repair script: /disk1/oracle/log/diag/rdbms/prod/prod/hm/reco_660500184.hm
ADVISE FAILUREの出力には、手動および自動の両方の修復オプションが示されています。まず、手動での問題の解決を試行します。問題を手動で解決できない場合は、自動修復に関するセクションを参照してください。
自動修復オプションには、1つ以上の障害に関するサーバー管理の修復が記載されています。修復は、可能な場合は統合されているため、1回の修復で複数の障害を解決できます。修復オプションには、実行する修復およびその修復の実行によってデータが失われるかどうかが示されます。
例2-1の出力には、Recovery Managerコマンドが含まれている修復スクリプトのファイル名が示されています。データ・リカバリ・アドバイザを使用して障害を自動的に修復しない場合は、このスクリプトをリカバリ計画の基礎として使用します。
Recovery ManagerセッションでLIST FAILUREおよびADVISE FAILUREを実行した後、REPAIR FAILUREを実行して修復オプションを実行できます。他のコマンド・オプションを指定せずにREPAIR FAILUREを実行すると、Recovery Managerは、現在のセッションで最新のADVISE FAILUREコマンドの最初の修復オプションを使用します。最新のADVISE FAILUREコマンドで取得した修復オプション番号を指定することもできます。例2-2に、例2-1で検出された障害の修復方法を示します。
RMAN> REPAIR FAILURE;
デフォルトでは、REPAIR FAILUREの実行を開始する前に確認を求められます。修復を実行した後、データ・リカバリ・アドバイザは、障害が修復されている可能性に関してすべての既存の障害を再評価します。データ・リカバリ・アドバイザは、障害が存在しているかどうかを常に確認し、修復されている障害を自動的にクローズします。エラーのため修復を完了できなかった場合は、そのエラーが原因で新しい評価が実行され、既存の障害および修復が再評価されます。
Oracle Flashback Databaseを使用すると、データベース全体を過去の時点に巻き戻すことができます。メディア・リカバリとは異なり、データファイルをリストアしてデータベースを過去の状態に戻す必要はありません。
Recovery ManagerのFLASHBACK DATABASEコマンドを使用するには、フラッシュバック・ログが生成されるように、データベースを事前に構成しておく必要があります。この構成タスクの詳細は、「Oracle Flashback Databaseおよびリストア・ポイントの構成」を参照してください。フラッシュバック・データベースによって、コマンドの実行時に存在しているデータファイルに対する変更が巻き戻されます。このコマンドを使用してメディア障害またはデータファイルの欠落を修復することはできません。
FLASHBACK DATABASEを発行する場合は、データベースがマウントされている必要があります。以前に作成したリストア・ポイントがフラッシュバック・データベース・ウィンドウ内にある場合は、そのリストア・ポイントにフラッシュバックできます。
次のコマンドを実行して、データベースを停止してからマウントします。
SHUTDOWN IMMEDIATE; STARTUP MOUNT;
FLASHBACK DATABASEコマンドを実行します。次の例は、このコマンドの様々な形式を示しています。
FLASHBACK DATABASE TO SCN 861150; FLASHBACK DATABASE TO RESTORE POINT BEFORE_CHANGES; FLASHBACK DATABASE TO TIME "TO_DATE('06/20/07','MM/DD/YY')";
次のように入力して、データベースを読取り専用でオープンします。
SQL "ALTER DATABASE OPEN READ ONLY";
SHUTDOWN IMMEDIATE; STARTUP MOUNT; ALTER DATABASE OPEN RESETLOGS;
物理データベース・ファイルをRecovery Managerでリストアおよびリカバリするには、RESTOREおよびRECOVERコマンドを使用します。データファイルのリストアでは、リカバリ操作に必要なバックアップからデータファイルを取得します。メディア・リカバリは、リストアしたデータファイルにREDOログおよび増分バックアップに含まれている変更を適用して、データファイルを目的のSCNまたは目標時点の状態にします。
メディア障害によってデータベース・ファイルが破損したため、データベースをリカバリする必要がある場合は、必要なバックアップがあることを最初に確認する必要があります。RESTORE ... PREVIEWコマンドを使用すると、指定した時点にリストアするためにRecovery Managerで使用可能なバックアップをレポートすることはできますが、リストアすることはできません。Recovery Managerは、メタデータは問い合せますが、実際にバックアップ・ファイルは読み取りません。このコマンドは、データベースをオープンしているときにも実行できます。
RMAN> REPORT SCHEMA;
PREVIEWオプションを指定してRESTORE DATABASEコマンドを実行します。次のコマンドでは、バックアップのメタデータが冗長モードで表示されないようにSUMMARYを指定します（出力例も示します）。
RMAN> RESTORE DATABASE PREVIEW SUMMARY; Starting restore at 21-MAY-07 allocated channel: ORA_DISK_1 channel ORA_DISK_1: SID=80 device type=DISK List of Backups =============== Key TY LV S Device Type Completion Time #Pieces #Copies Compressed Tag ------- -- -- - ----------- --------------- ------- ------- ---------- --- 11 B F A DISK 18-MAY-07 1 2 NO TAG20070518T181114 13 B F A DISK 18-MAY-07 1 2 NO TAG20070518T181114 using channel ORA_DISK_1 List of Archived Log Copies for database with db_unique_name PROD ===================================================================== Key Thrd Seq S Low Time ------- ---- ------- - --------- 47 1 18 A 18-MAY-07 Name: /disk1/oracle/dbs/db1r_60ffa882_1_18_0622902157.arc Media recovery start SCN is 586534 Recovery must be done beyond SCN 587194 to clear datafile fuzziness validation succeeded for backup piece Finished restore at 21-MAY-07
データベース全体をリカバリするには、RESTORE DATABASEおよびRECOVER DATABASEコマンドを使用します。必要なすべてのファイルのバックアップを事前に作成しておく必要があります。このシナリオでは、すべてのデータファイルを元の場所にリストアできることを想定しています。元の場所にアクセスできない場合は、「デフォルト以外の場所へのデータファイルのリストア」の説明に従ってSET NEWNAMEコマンドを使用します。
次の例では、（起動されている場合は）データベース・インスタンスを終了し、データベースをマウントします。
RMAN> STARTUP FORCE MOUNT;
次の例では、事前構成されたディスク・チャネルを使用して、データベースをリストアします。
RMAN> RESTORE DATABASE;
RMAN> RECOVER DATABASE;
RMAN> ALTER DATABASE OPEN;
データベースがオープンされている場合は、個々の表領域に対してRESTORE TABLESPACEおよびRECOVER TABLESPACEコマンドを使用します。この場合、リカバリが必要な表領域をオフラインにしてリストアし、表領域をリカバリしてからオンラインに戻す必要があります。
データファイルを新しい場所にリストアできない場合は、Recovery ManagerのSET NEWNAMEコマンドをRUNコマンド内で使用して、新しいファイル名を指定します。その後、SQL文のALTER DATABASE RENAME FILEと同等のSWITCH DATAFILE ALLコマンドを使用して制御ファイルを更新し、RUNコマンドでSET NEWNAMEが発行されたすべてのデータファイルの新しい名前を反映します。
ユーザー管理のメディア・リカバリとは異なり、オンラインの表領域をバックアップ・モードする必要はありません。ユーザー管理ツールとは異なり、Recovery Managerでは、データ・ブロックの形式が認識されるため、追加のロギングまたはバックアップが必要ありません。
users表領域をオフラインにするには、次のように入力します。
RMAN> SQL 'ALTER TABLESPACE users OFFLINE';
Recovery Managerプロンプトで次のRUNコマンドを実行すると、users表領域にデータファイルの新しい名前が設定されます。
RUN { SET NEWNAME FOR DATAFILE '/disk1/oradata/prod/users01.dbf' TO '/disk2/users01.dbf'; RESTORE TABLESPACE users; SWITCH DATAFILE ALL; # update control file with new filenames RECOVER TABLESPACE users; }
RMAN> SQL 'ALTER TABLESPACE users ONLINE';
データファイル・レベルのリカバリには、RESTORE DATAFILEおよびRECOVER DATAFILEを使用することもできます。
Recovery Managerは、破損した個々のデータファイル・ブロックをリカバリできます。Recovery Managerがバックアップ用のファイルの完全なスキャンを実行する場合、破損したすべてのブロックがV$DATABASE_BLOCK_CORRUPTIONに表示されます。通常、破損は、アラート・ログ、トレース・ファイルまたはSQL問合せの結果に記録されます。
トレース・ファイルおよびアラート・ログを検索する最も簡単な方法は、SQL*Plusをターゲット・データベースに接続し、次の問合せを実行する方法です。
SQL> SELECT NAME, VALUE 2 FROM V$DIAG_INFO;
RECOVERコマンドを実行してブロックを修復します。次のRecovery Managerコマンドによって、破損したすべてのブロックがリカバリされます。
RMAN> RECOVER CORRUPTION LIST;
次の例に示すように、個々のブロックをリカバリすることもできます。
RMAN> RECOVER DATAFILE 1 BLOCK 233, 235 DATAFILE 2 BLOCK 100 TO 200;
|
 Copyright © 2003, 2008, Oracle Corporation. All Rights Reserved. |
|