11g リリース1（11.1）
E05700-03
 目次 |
 索引 |
| Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド 11g リリース1（11.1） E05700-03 |
|
この章では、Recovery Manager操作に関してレポートする方法について説明します。この章の内容は、次のとおりです。
この項では、Recovery Managerレポートの目的および基本的な概念について説明します。
バックアップおよびリカバリ計画の一部として、バックアップした内容を示すレポートを定期的に実行する必要があります。また、バックアップが必要なデータファイルまたは最近バックアップされていないファイルを確認しておく必要もあります。また、問題発生時にRecovery Managerでリストアする必要があるバックアップをプレビューすることもできます。
バックアップおよびリカバリのもう1つ重要な側面は、領域の使用状況の監視です。ディスクにバックアップする場合は、そのディスクが一杯になる可能性があるため、パフォーマンス上の問題が発生したり、データベースが停止することもあります。Recovery Managerを使用すると、バックアップが不要なバックアップで、削除可能かどうかを確認できます。
また、Recovery Managerジョブについての履歴情報を取得する必要がある場合もあります。たとえば、発行されたバックアップ・ジョブの数、各バックアップ・ジョブのステータス（失敗したか完了したかなど）、ジョブの開始日時と終了日時、および実行されたバックアップのタイプについて確認する必要がある場合があります。
Recovery Managerは、操作の実行対象となる各ターゲット・データベースの制御ファイルに、そのメタデータのRecovery Managerリポジトリを常に格納します。たとえば、Recovery Managerを使用して、prod1およびprod2データベースをバックアップするとします。Recovery Managerは、prod1のバックアップ用メタデータをprod1の制御ファイルに、prod2のバックアップ用メタデータをprod2の制御ファイルに格納します。
必要に応じて、リカバリ・カタログとともにRecovery Managerを使用できます。この場合、Recovery Managerは、別のリカバリ・カタログ・データベース内の一連の表に、追加のメタデータ・リポジトリを保持します。たとえば、prod3にリカバリ・カタログを作成するとします。このリカバリ・カタログには、複数のターゲット・データベースを登録できます。たとえば、prod1およびprod2をprod3に格納されているリカバリ・カタログに登録すると、Recovery Managerは、prod1およびprod2のバックアップに関するメタデータをリカバリ・カタログ・スキーマに格納します。
次に示す様々な方法で、Recovery Managerリポジトリからメタデータにアクセスできます。
LISTおよびREPORTコマンドでは、使用可能なバックアップと、データベースをリストアおよびリカバリするためにそれをどのように使用できるかという詳細な情報が提供されます。LISTコマンドについては「バックアップおよびリカバリ関連オブジェクトの表示」、REPORTについては「バックアップおよびデータベース・スキーマに関するレポート」を参照してください。
V$ビューによって、各ターゲット・データベースの制御ファイル内にあるRecovery Managerリポジトリ・レコードに直接アクセスできます。V$DATAFILE_HEADER、V$PROCESS、V$SESSIONなどの一部のV$ビューには、リカバリ・カタログ・ビューにはない情報が含まれています。V$ビューの詳細は、『Oracle Databaseリファレンス』を参照してください。
RC_ビューによって、リカバリ・カタログに格納されているRecovery Managerリポジトリ・データに直接アクセスできます。RC_ビューは、V$ビューとほぼ対応しています。RC_ビューについては、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。
RESTORE ... PREVIEWおよびRESTORE ... VALIDATE HEADERコマンドでは、指定した時間までRecovery Managerでリストア可能なバックアップが表示されます。RESTORE ... PREVIEWは、メタデータは問い合せますが、実際にバックアップ・ファイルは読み取りません。RESTORE ... VALIDATE HEADERコマンドでも同じ操作が実行されますが、リストアおよびリカバリに必要なファイルの表示の他に、ディスク上またはメディア管理カタログ内のファイルがRecovery Managerリポジトリのメタデータに対応しているかどうかを確認するためにバックアップ・ファイル・ヘッダーが検証されます。これらのコマンドについては、「リストア操作で使用されるバックアップのプレビュー」を参照してください。
第11章「Recovery Managerバックアップおよびリポジトリ・レコードのメンテナンス」で説明されているように、Recovery Managerリポジトリがディスクおよびテープ上の実情を反映していない場合があります。たとえば、ユーザーがオペレーティング・システムのユーティリティを使用してバックアップを削除した場合、そのバックアップは、Recovery Managerリポジトリでは誤って使用可能と表示されます。
CHANGE、CROSSCHECK、DELETEなどのコマンドを使用すると、使用可能なバックアップの実際の状態を反映してRecovery Managerリポジトリを更新できます。そうしない場合、コマンドおよびビューの出力が誤って表示され、データベースをリストアおよびリカバリするためのバックアップをRecovery Managerで検出できない可能性があります。
|
参照:
|
「Data Guard環境でのRecovery Managerによるファイル管理」で説明されているように、すべてのバックアップがそのバックアップを作成したプライマリ・データベースまたはスタンバイ・データベースに関連付けられています。たとえば、standby1のDB_UNIQUE_NAMEを使用してデータベースをバックアップすると、standby1データベースがこのバックアップに関連付けられます。
Data Guard環境では、Data Guardを使用しない場合と同様に、LIST、REPORTおよびSHOWコマンドを使用できます。FOR DB_UNIQUE_NAME句を指定してこれらのコマンドを実行すると、指定したデータベースに関連付けられているバックアップを表示できます。たとえば、次のコマンドでは、sfstandbyにのみ関連付けられているアーカイブREDOログが表示されます。
LIST ARCHIVELOG ALL FOR DB_UNIQUE_NAME sfstandby;
Data Guard環境でFOR DB_UNIQUE_NAME句を指定せずにLIST、REPORTおよびSHOWコマンドを使用すると、Recovery Managerによって、ターゲット・データベースでアクセス可能なファイルが表示されます。Recovery Managerでバックアップにアクセス可能であるとみなされる場合については、「Data Guard環境でのバックアップの関連付け」を参照してください。
Data Guard環境では、Recovery Managerをリカバリ・カタログとともに使用する必要があります。Recovery Managerでは、すべてのバックアップおよびリカバリ・ファイルのメタデータがリカバリ・カタログのData Guard環境に格納されます。Recovery Managerのレポート・コマンドの実行時に、マウントまたはオープンされているデータベースにRecovery ManagerをTARGETとして接続するか、またはSET DBIDコマンドを使用してデータベースを識別することができます。
LISTコマンドは、Recovery Managerリポジトリの情報を使用して、バックアップやバックアップとリカバリに関連するその他のオブジェクトのリストを表示します。この項の内容は、次のとおりです。
LISTコマンドの主な目的は、バックアップおよびコピーを表示することです。たとえば、次の内容を表示できます。
LISTコマンドの主な目的は、バックアップおよびコピーを表示することです。Recovery Managerでは、バックアップおよびコピーのみでなく、他のタイプのデータも表示できます。次の表に、表示できる有効なオブジェクトをいくつか示します。
| リストの内容 | コマンド | 説明 |
|---|---|---|
|
バックアップ・セットおよびプロキシ・コピー |
|
データベース、表領域、データファイル、アーカイブREDOログ、制御ファイルまたはサーバー・パラメータ・ファイルのすべてのバックアップ・セット、コピーおよびプロキシ・コピーを表示できます。 |
|
イメージ・コピー |
|
データファイル・コピーおよびアーカイブREDOログ・ファイルを表示できます。デフォルトでは、 |
|
アーカイブREDOログ・ファイル |
|
アーカイブREDOログ・ファイルを表示できます。 |
|
データベース・インカネーション |
|
データベースのすべてのインカネーションを表示できます。 |
|
Data Guard環境のデータベース |
|
Data Guard環境のデータベースは、その |
|
Data Guard環境のプライマリ・データベースまたはスタンバイ・データベースのバックアップおよびコピー |
|
Data Guard環境内の指定したデータベースまたはすべてのデータベースのすべてのバックアップおよびコピーを表示できます。
Recovery Managerでは、指定した |
|
リストア・ポイント |
|
Recovery Managerリポジトリで認識されるリストア・ポイントを表示できます。 |
|
ストアド・スクリプトの名前 |
|
|
|
データ・リカバリ・アドバイザとともに使用する場合の障害 |
|
障害とは、修復オプションにマッピングされている永続的なデータの破損のことです。 |
LISTコマンドでは、出力の表示方法を制御できる多くのオプションがサポートされています。次の表に、最も一般的なLISTのオプションを示します。
| LISTのオプション | 説明 |
|---|---|
|
|
Recovery Managerリポジトリに記録されているバックアップまたはコピーで、最後にクロスチェックを実行したときに、ディスクまたはテープ上の予測した位置に存在しなかったものを表示します。このようなバックアップは、Recovery Managerの外部で削除された可能性があります。 |
|
|
各データファイル、アーカイブREDOログ・ファイル、制御ファイルおよびサーバー・パラメータ・ファイルのバックアップを表示します。各行にファイルのバックアップの説明が示されます。 |
|
|
各バックアップの1行のサマリーを表示します。 |
前述の表に、すべてのLISTオブジェクトおよびオプションが示されているわけではありません。たとえば、時間、パス名、デバイス・タイプ、タグまたはリカバリ可能性で制限されたバックアップを表示できます。
listObjListまたはrecordSpec句（『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照）を使用して、必要なオブジェクトを指定します。オブジェクトを指定しないと、Recovery Managerは、すべてのデータベース・ファイルとアーカイブREDOログ・ファイルのコピーを表示します。
デフォルトでは、Recovery Managerは、各バックアップまたはプロキシ・コピーを連続して表示した後、そのバックアップに含まれているファイルを識別します。また、ファイルごとにバックアップを表示することもできます。
デフォルトでは、Recovery Managerは冗長モードで表示を行います。つまり、様々な情報を複数行にわたって表示します。冗長モードによる出力が多すぎる場合は、サマリー・モードでバックアップを表示することもできます。
SUMMARYオプションを指定してLISTコマンドを実行します。次のコマンドを実行すると、すべてのRecovery Managerバックアップのサマリーが出力されます。
LIST BACKUP SUMMARY;
出力例を次に示します。
List of Backups =============== Key TY LV S Device Type Completion Time #Pieces #Copies Compressed Tag ------- -- -- - ----------- --------------- ------- ------- ---------- --- 1 B A A SBT_TAPE 21-OCT-07 1 1 NO TAG20071021T094505 2 B F A SBT_TAPE 21-OCT-07 1 1 NO TAG20071021T094513 3 B A A SBT_TAPE 21-OCT-07 1 1 NO TAG20071021T094624 4 B F A SBT_TAPE 21-OCT-07 1 1 NO TAG20071021T094639 5 B F A DISK 04-NOV-07 1 1 YES TAG20071104T195949
SUMMARYオプションを指定せずにLISTコマンドを実行します。次のコマンドを実行すると、デフォルトの詳細な出力でRecovery Managerバックアップおよびコピーが表示されます。
LIST BACKUP; LIST COPY;
LIST BACKUPおよびLIST COPYの出力例を次に示します。
List of Backup Sets =================== BS Key Size Device Type Elapsed Time Completion Time ------- ---------- ----------- ------------ --------------- 7 136M DISK 00:00:20 04-NOV-06 BP Key: 7 Status: AVAILABLE Compressed: NO Tag: TAG20071104T200759 Piece Name: /d2/RDBMS/backupset/2007_11_04/o1_mf_annnn_TAG20071104T200759_ ztjxx3k8_.bkp List of Archived Logs in backup set 7 Thrd Seq Low SCN Low Time Next SCN Next Time ---- ------- ---------- --------- ---------- --------- 1 1 173832 21-OCT-06 174750 21-OCT-06 1 2 174750 21-OCT-06 174755 21-OCT-06 1 3 174755 21-OCT-06 174758 21-OCT-06 BS Key Type LV Size Device Type Elapsed Time Completion Time ------- ---- -- ---------- ----------- ------------ --------------- 8 Full 2M DISK 00:00:01 04-NOV-06 BP Key: 8 Status: AVAILABLE Compressed: NO Tag: TAG20071104T200829 Piece Name: /disk1/oracle/dbs/c-774627068-20071104-01 Controlfile Included: Ckp SCN: 631510 Ckp time: 04-NOV-06 SPFILE Included: Modification time: 21-OCT-06 List of Datafile Copies ======================= Key File S Completion Time Ckp SCN Ckp Time ------- ---- - --------------- ---------- --------------- 1 7 A 11-OCT-06 360072 11-OCT-06 Name: /work/orcva/RDBMS/datafile/o1_mf_tbs_2_2lv7bf82_.dbf Tag: DF7COPY 2 8 A 11-OCT-06 360244 11-OCT-06 Name: /work/orcva/RDBMS/datafile/o1_mf_tbs_2_2lv7qmcj_.dbf Tag: TAG20071011T184835 List of Control File Copies =========================== Key S Completion Time Ckp SCN Ckp Time ------- - --------------- ---------- --------------- 3 A 11-OCT-06 360380 11-OCT-06 Name: /d2/RDBMS/controlfile/o1_mf_TAG20071011T185335_2lv80zqd_.ctl Tag: TAG20071011T185335 List of Archived Log Copies for database with db_unique_name RDBMS ===================================================================== Key Thrd Seq S Low Time ------- ---- ------- - --------- 1 1 1 A 11-OCT-06 Name: /work/arc_dest/arcr_1_1_603561743.arc 2 1 2 A 11-OCT-06 Name: /work/arc_dest/arcr_1_2_603561743.arc 3 1 3 A 11-OCT-06 Name: /work/arc_dest/arcr_1_3_603561743.arc
BY FILEオプションとともに指定してLISTを実行します。たとえば、次のように入力します。
LIST BACKUP BY FILE;
出力例を次に示します。
List of Datafile Backups ======================== File Key TY LV S Ckp SCN Ckp Time #Pieces #Copies Compressed Tag ---- ------- - -- - ---------- --------- ------- ------- ---------- --- 1 5 B F A 631092 04-NOV-06 1 1 YES TAG20071104T195949 2 B F A 175337 21-OCT-06 1 1 NO TAG20071021T094513 2 5 B F A 631092 04-NOV-06 1 1 YES TAG20071104T195949 2 B F A 175337 21-OCT-06 1 1 NO TAG20071021T094513 ... some rows omitted List of Archived Log Backups ============================ Thrd Seq Low SCN Low Time BS Key S #Pieces #Copies Compressed Tag ---- ------- ---------- --------- ------- - ------- ------- ---------- --- 1 1 173832 21-OCT-06 7 A 1 1 NO TAG20071104T200759 1 A 1 1 NO TAG20071021T094505 1 2 174750 21-OCT-06 7 A 1 1 NO TAG20071104T200759 1 A 1 1 NO TAG20071021T094505 ... some rows omitted 1 38 575472 03-NOV-06 7 A 1 1 NO TAG20071104T200759 1 39 617944 04-NOV-06 7 A 1 1 NO TAG20071104T200759 List of Controlfile Backups =========================== CF Ckp SCN Ckp Time BS Key S #Pieces #Copies Compressed Tag ---------- --------- ------- - ------- ------- ---------- --- 631510 04-NOV-06 8 A 1 1 NO TAG20071104T200829 631205 04-NOV-06 6 A 1 1 NO TAG20071104T200432 List of SPFILE Backups ====================== Modification Time BS Key S #Pieces #Copies Compressed Tag ----------------- ------- - ------- ------- ---------- --- 21-OCT-06 8 A 1 1 NO TAG20071104T200829 21-OCT-06 6 A 1 1 NO TAG20071104T200432
様々な条件を指定して、LIST出力を制限できます。
listObjListまたはrecordSpec句を指定して、LIST COPYまたはLIST BACKUPを実行します。たとえば、次のいずれかのコマンドを実行します。
# lists backups of all files in database LIST BACKUP OF DATABASE; # lists copy of specified datafile LIST COPY OF DATAFILE 'ora_home/oradata/trgt/system01.dbf'; # lists specified backup set LIST BACKUPSET 213; # lists datafile copy LIST DATAFILECOPY '/tmp/tools01.dbf';
maintQualifierまたはRECOVERABLE句を指定して、検索を制限することもできます。たとえば、次のいずれかのコマンドを実行します。
# specify a backup set by tag LIST BACKUPSET TAG 'weekly_full_db_backup'; # specify a backup or copy by device type LIST COPY OF DATAFILE 'ora_home/oradata/trgt/system01.dbf' DEVICE TYPE sbt; # specify a backup by directory or path LIST BACKUP LIKE '/tmp/%'; # specify a backup or copy by a range of completion dates LIST COPY OF DATAFILE 2 COMPLETED BETWEEN '10-DEC-2002' AND '17-DEC-2002'; # specify logs backed up at least twice to tape LIST ARCHIVELOG ALL BACKED UP 2 TIMES TO DEVICE TYPE sbt;
出力は、LISTコマンドに指定したオプションによって異なります。たとえば、次のコマンドでは、データファイル1のコピーが表示されます。
RMAN> LIST BACKUP OF DATAFILE 1; List of Backup Sets =================== BS Key Type LV Size Device Type Elapsed Time Completion Time ------- ---- -- ---------- ----------- ------------ --------------- 2 Full 230M SBT_TAPE 00:00:49 21-OCT-06 BP Key: 2 Status: AVAILABLE Compressed: NO Tag: TAG20071021T094513 Handle: 02f4eatc_1_1 Media: /smrdir List of Datafiles in backup set 2 File LV Type Ckp SCN Ckp Time Name ---- -- ---- ---------- --------- ---- 1 Full 175337 21-OCT-06 /oracle/dbs/tbs_01.f BS Key Type LV Size Device Type Elapsed Time Completion Time ------- ---- -- ---------- ----------- ------------ --------------- 5 Full 233M DISK 00:04:30 04-NOV-06 BP Key: 5 Status: AVAILABLE Compressed: NO Tag: TAG20071104T195949 Piece Name: /disk1/2007_11_04/o1_mf_nnndf_TAG20071104T195949_ztjxfvgz_.bkp List of Datafiles in backup set 5 File LV Type Ckp SCN Ckp Time Name ---- -- ---- ---------- --------- ---- 1 Full 631092 04-NOV-06 /oracle/dbs/tbs_01.f
データベースに対してOPEN RESETLOGS操作を実行するたびに、新しいデータベース・インカネーションが作成されます。データベース・インカネーションと、それによってデータベース・リカバリが受ける影響については、「データベース・インカネーション」を参照してください。
増分バックアップの実行時、Recovery Managerは、前回のインカネーションまたは現行のインカネーションからのバックアップを、後続の増分バックアップの基礎として使用できます。リストアおよびリカバリの実行時、すべてのアーカイブ・ログが使用可能なかぎり、Recovery Managerは、現行のインカネーションからのバックアップを使用するのと同様に、リストアまたはリカバリ操作で前回のインカネーションからのバックアップを使用できます。
LIST INCARNATIONコマンドを実行します。
LIST INCARNATION;
リカバリ・カタログを使用している場合、および同じカタログに複数のターゲット・データベースを登録している場合は、OF DATABASEオプションを使用して、それらを区別することができます。
LIST INCARNATION OF DATABASE prod3;
LIST出力の様々な列ヘッダーについては、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。出力例は次のとおりです。
RMAN> LIST INCARNATION OF DATABASE; List of Database Incarnations DB Key Inc Key DB Name DB ID STATUS Reset SCN Reset Time ------- ------- -------- ---------------- ------ ---------- ---------- 1 1 RDBMS 774627068 PARENT 1 21-OCT-06 2 2 RDBMS 774627068 CURRENT 173832 21-OCT-06
この出力例では、RESETLOGSが、SCN 164378でデータベースtrgtに対して実行され、新しいインカネーションが作成されたことが示されています。インカネーションは、インカネーション・キー（Inc Key列）で区別されます。
LISTコマンドを使用して、特定のリストア・ポイント、またはRecovery Managerリポジトリで認識されるすべてのリストア・ポイントを表示できます。このコマンドの例を次に示します。
LIST RESTORE POINT restore_point_name; LIST RESTORE POINT ALL;
Recovery Managerは、リストア・ポイントのSCNおよび時刻、リストア・ポイントのタイプおよびリストア・ポイントの名前を表示します。出力例を次に示します。
RMAN> LIST RESTORE POINT ALL; using target database control file instead of recovery catalog SCN RSP Time Type Time Name ---------------- --------- ---------- --------- ---- 341859 28-JUL-06 28-JUL-06 NORMAL_RS 343690 28-JUL-06 GUARANTEED 28-JUL-06 GUARANTEED_RS
また、次のようにV$RESTORE_POINTビューを問い合せて、現在定義されているリストア・ポイントのリストを表示することもできます。
SELECT NAME, SCN, TIME, DATABASE_INCARNATION#, GUARANTEE_FLASHBACK_DATABASE,STORAGE_SIZE FROM V$RESTORE_POINT;
各リストア・ポイントの名前、リストア・ポイントが作成されたSCN、実時間およびデータベース・インカネーション番号、各リストア・ポイントが保証付きリストア・ポイントであるかどうか、およびそのリストア・ポイントに対するフラッシュバック・データベース操作に必要なデータに使用されているリカバリ領域の量を表示できます。
また、次の問合せを使用して、保証付きリストア・ポイントのみを表示することもできます。
SELECT NAME, SCN, TIME, DATABASE_INCARNATION#, GUARANTEE_FLASHBACK_DATABASE, STORAGE_SIZE FROM V$RESTORE_POINT WHERE GUARANTEE_FLASHBACK_DATABASE='YES';
通常のリストア・ポイントの場合、STORAGE_SIZEが0（ゼロ）になります。保証付きリストア・ポイントの場合、STORAGE_SIZEは、フラッシュ・リカバリ領域のディスク領域の容量を示します。この領域は、そのリストア・ポイントに対するFLASHBACK DATABASEを保証するために必要なログの保持に使用されます。
Recovery ManagerのREPORTコマンドを使用すると、使用可能なバックアップおよびデータベースが分析されます。この項の内容は、次のとおりです。
REPORTコマンドを使用すると、次の重要な質問に回答することができます。
レポートを使用すると、バックアップおよびリカバリ計画が実際にデータベースのリカバリ可能性の要件を満たしていることを確認できます。データベースがリカバリ可能であるかどうかを判断するために使用するREPORTには、主に次の2つの形式があります。
REPORT NEED BACKUP構成済の保存方針または指定した保存方針を満たすためにバックアップする必要があるデータベース・ファイルがレポートされます。
REPORT UNRECOVERABLEダイレクト・パス・インサートなどのNOLOGGING操作の影響を受けているためバックアップを必要とするデータベース・ファイルがレポートされます。
Recovery Managerリポジトリには、REPORTコマンドを使用してアクセスできる他の情報が含まれています。REPORTオプションの概要は、表10-3を参照してください。
REPORT NEED BACKUPコマンドを使用して、特定の保存方針に基づくバックアップが必要なデータベース・ファイルを判断します。
引数を指定せずにREPORT NEED BACKUPを実行すると、現行の保存方針でバックアップが必要なオブジェクトがレポートされます。REDUNDANCYが1に設定されている構成済の保存方針の出力は、次の例のようになります。
RMAN> REPORT NEED BACKUP; RMAN retention policy will be applied to the command RMAN retention policy is set to redundancy 1 Report of files with less than 1 redundant backups File #bkps Name ---- ----- ----------------------------------------------------- 2 0 /oracle/oradata/trgt/undotbs01.dbf
次のいずれかの形式のコマンドを使用して、REPORT NEED BACKUPに様々な条件を指定できます。
REPORT NEED BACKUP RECOVERY WINDOW OF n DAYSバックアップがリカバリ期間ベースの保存方針を満たす必要があるオブジェクトが表示されます。
REPORT NEED BACKUP REDUNDANCY nバックアップが冗長性ベースの保存方針を満たす必要があるオブジェクトが表示されます。
REPORT NEED BACKUP DAYS nリカバリ用にn日分より多いアーカイブREDOログを必要とするファイルが表示されます。
REPORT NEED BACKUP INCREMENTAL nリカバリ用にn個より多い増分バックアップの適用を必要とするファイルが表示されます。
REPORT NEED BACKUPを使用して、データベース全体の確認、指定された表領域のスキップ、または様々な保存方針に対する特定の表領域またはデータファイルのみの確認を行うことができます。次に例を示します。
REPORT NEED BACKUP RECOVERY WINDOW OF 2 DAYS DATABASE SKIP TABLESPACE TBS_2; REPORT NEED BACKUP REDUNDANCY 2 DATAFILE 1; REPORT NEED BACKUP TABLESPACE TBS_3; # uses configured retention policy REPORT NEED BACKUP INCREMENTAL 2; # checks entire database
REPORT NEED BACKUPでテストするバックアップをディスクベースまたはテープベースのバックアップのみに制限できます。次に例を示します。
REPORT NEED BACKUP RECOVERY WINDOW OF 2 DAYS DATABASE DEVICE TYPE sbt; REPORT NEED BACKUP DEVICE TYPE DISK; REPORT NEED BACKUP TABLESPACE TBS_3 DEVICE TYPE sbt;
ダイレクト・ロード・インサートなどのリカバリ不能な操作によってデータファイルが変更されている場合、リカバリ不能な操作ではREDOが生成されないため、通常のメディア・リカバリを使用してファイルをリカバリすることはできません。このような操作の後に影響を受けるデータファイルの全体バックアップまたは増分バックアップのいずれかを実行して、リカバリ不能な操作の影響を受けるデータ・ブロックをRecovery Managerを使用してリカバリできるようにする必要があります。
REPORT UNRECOVERABLEコマンドを実行します。出力例を次に示します。
RMAN> REPORT UNRECOVERABLE; Report of files that need backup due to unrecoverable operations File Type of Backup Required Name ---- ----------------------- ----------------------------------- 1 full /oracle/oradata/trgt/system01.dbf
OBSOLETEキーワードを指定すると、不要な（指定した保存方針を満たす必要がない）バックアップ・セット、バックアップ・ピースおよびデータファイルのコピーをレポートできます。
CROSSCHECKコマンドを実行して、ディスク上のバックアップのステータスと比較してリポジトリのバックアップのステータスを更新します。最も簡単な方法としては、次のいずれかのコマンドを使用して、ディスクまたはテープ（あるいはその両方）上のすべてのバックアップをクロスチェックすることができます。
CROSSCHECK BACKUP DEVICE TYPE DISK; CROSSCHECK BACKUP DEVICE TYPE sbt; CROSSCHECK BACKUP; # crosshecks all backups on all devices
実際に使用可能なバックアップ・セットが含まれるようにRecovery Managerリポジトリを更新する方法の詳細は、第11章「Recovery Managerバックアップおよびリポジトリ・レコードのメンテナンス」を参照してください。
REPORT OBSOLETEを実行して、リカバリの必要がなくなったために不要となったバックアップを識別します。他のオプションを指定せずにREPORT OBSOLETEを実行すると、現行の保存方針で不要とみなされるバックアップが表示されます。次に例を示します。
RMAN> REPORT OBSOLETE; Datafile Copy 44 08-FEB-06 /backup/ora_df549738566_s70_s1 Datafile Copy 45 08-FEB-06 /backup/ora_df549738567_s71_s1 Datafile Copy 46 08-FEB-06 /backup/ora_df549738568_s72_s1 Backup Set 26 08-FEB-06 Backup Piece 26 08-FEB-06 /backup/ora_df549738682_s76_s1 . . .
RECOVERY WINDOWおよびREDUNDANCYオプションを指定してREPORT OBSOLETEを使用することによって、様々なリカバリ期間ベースまたは冗長性ベースの保存方針に基づいて不要とみなされるバックアップを確認できます。次に例を示します。
REPORT OBSOLETE RECOVERY WINDOW OF 3 DAYS; REPORT OBSOLETE REDUNDANCY 1;
|
参照:
|
REPORT SCHEMAコマンドを実行すると、データベース・ファイル、表領域などに関する情報が表示されます。REPORT SCHEMAの出力については、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。
FOR DB_UNIQUE_NAMEをREPORT SCHEMAとともに指定しない場合、リカバリ・カタログ接続は任意ですが、ターゲット・データベース接続は必須です。Data Guard環境では、REPORT SCHEMA FOR DB_UNIQUE_NAMEを指定して環境内のデータベースのスキーマをレポートできます。この場合、Recovery Managerをターゲット・データベースに接続する必要はありません。かわりに、Recovery Managerをリカバリ・カタログに接続し、DBIDを設定できます。
REPORT SCHEMAにFOR DB_UNIQUE_NAME句を指定する場合は、データベースDBIDを設定します。たとえば、次のコマンドを入力します。
RMAN> SET DBID 28014364;
REPORT SCHEMAコマンドを実行します。
RMAN> REPORT SCHEMA; Report of database schema for database with db_unique_name DGRDBMS List of Permanent Datafiles =========================== File Size(MB) Tablespace RB segs Datafile Name ---- -------- -------------------- ------- ------------------------ 1 450 SYSTEM YES /disk1/oracle/dbs/t_db1.f 2 141 SYSAUX NO /disk1/oracle/dbs/t_ax1.f 3 50 UD1 YES /disk1/oracle/dbs/t_undo1.f 4 50 TBS_11 NO /disk1/oracle/dbs/tbs_111.f 5 50 TBS_11 NO /disk1/oracle/dbs/tbs_112.f List of Temporary Files ======================= File Size(MB) Tablespace Maxsize(MB) Tempfile Name ---- -------- -------------------- ----------- -------------------- 1 40 TEMP 32767 /disk1/oracle/dbs/t_tmp1.f
リカバリ・カタログを使用すると、atClauseを使用して、過去の時刻、SCNまたはログ順序番号を指定できます。次に例を示します。
RMAN> REPORT SCHEMA AT TIME 'SYSDATE-14'; # schema 14 days ago RMAN> REPORT SCHEMA AT SCN 1000; # schema at scn 1000 RMAN> REPORT SCHEMA AT SEQUENCE 100 THREAD 1; # schema at sequence 100 RMAN> REPORT SCHEMA FOR DB_UNIQUE_NAME standby1; # schema for database standby1
LISTおよびREPORTコマンドでは表示できない情報がV$ビューに表示される場合があります。この項では、V$ビューが特に役立つ場合について説明します。
Recovery Managerジョブは、Recovery Managerセッション内で実行されるコマンドのセットです。したがって、1つのRecovery Managerジョブに複数のコマンドを含めることができます。たとえば、2つの別々のコマンドBACKUPおよびRECOVER COPYを、1つのセッションで実行できます。Recovery Managerバックアップ・ジョブは、1つのRecovery Managerジョブで実行されるBACKUPコマンドのセットです。たとえば、同じRecovery Managerジョブで実行されるBACKUP DATABASEおよびBACKUP ARCHIVELOG ALLコマンドで、1つのRecovery Managerバックアップ・ジョブが構成されます。
V$RMAN_BACKUP_JOB_DETAILSとV$RMAN_BACKUP_SUBJOB_DETAILSの各ビューおよびこれらに対応するリカバリ・カタログのバージョンによって、Recovery Managerバックアップ・ジョブの詳細が提供されます。たとえば、これらのビューには、バックアップにかかった時間、発行されたバックアップ・ジョブの数、各バックアップ・ジョブのステータス（失敗したか完了したかなど）、ジョブの開始日時と終了日時、および実行されたバックアップのタイプが表示されます。SESSION_KEY列は、バックアップ・ジョブが発生したRecovery Managerセッションの一意のキーです。
多くの場合、Recovery Managerによるバックアップでは、書込みを読取りほど行いません。Recovery Manager圧縮のため、OUTPUT_BYTES_PER_SEC列をバックアップ速度の測定には使用できません。バックアップ速度の測定に適した列はINPUT_BYTES_PER_SECです。読取りデータと書込みデータの比率はCOMPRESSION_RATIO列に示されます。
V$RMAN_BACKUP_JOB_DETAILSビューを問い合せます。次の問合せによって、バックアップ・ジョブの履歴が、Recovery Managerセッションの主キーであるセッション・キーの順序で表示されます。
COL STATUS FORMAT a9 COL hrs FORMAT 999.99 SELECT SESSION_KEY, INPUT_TYPE, STATUS, TO_CHAR(START_TIME,'mm/dd/yy hh24:mi') start_time, TO_CHAR(END_TIME,'mm/dd/yy hh24:mi') end_time, ELAPSED_SECONDS/3600 hrs FROM V$RMAN_BACKUP_JOB_DETAILS ORDER BY SESSION_KEY;
次に、バックアップ・ジョブの履歴の出力例を示します。
SESSION_KEY INPUT_TYPE STATUS START_TIME END_TIME HRS ----------- ------------- --------- -------------- -------------- ------- 9 DATAFILE FULL COMPLETED 04/18/07 18:14 04/18/07 18:15 .02 16 DB FULL COMPLETED 04/18/07 18:20 04/18/07 18:22 .03 113 ARCHIVELOG COMPLETED 04/23/07 16:04 04/23/07 16:05 .01
V$RMAN_BACKUP_JOB_DETAILSビューを問い合せます。次の問合せによって、バックアップ・ジョブの速度が、Recovery Managerセッションの主キーであるセッション・キーの順序で表示されます。列in_secおよびout_secに、1秒当たりのデータの入力と出力が表示されます。
COL in_sec FORMAT a10 COL out_sec FORMAT a10 COL TIME_TAKEN_DISPLAY FORMAT a10 SELECT SESSION_KEY, OPTIMIZED, COMPRESSION_RATIO, INPUT_BYTES_PER_SEC_DISPLAY in_sec, OUTPUT_BYTES_PER_SEC_DISPLAY out_sec, TIME_TAKEN_DISPLAY FROM V$RMAN_BACKUP_JOB_DETAILS ORDER BY SESSION_KEY;
次に、バックアップ・ジョブの速度の出力例を示します。
SESSION_KEY OPT COMPRESSION_RATIO IN_SEC OUT_SEC TIME_TAKEN ----------- --- ----------------- ---------- ---------- ---------- 9 NO 1 8.24M 8.24M 00:01:14 16 NO 1.32732239 6.77M 5.10M 00:01:45 113 NO 1 2.99M 2.99M 00:00:44
V$RMAN_BACKUP_JOB_DETAILSビューを問い合せます。BACKUP DATABASEを実行すると、V$RMAN_BACKUP_JOB_DETAILS.OUTPUT_BYTESによって、バックアップ中のデータベースのバックアップ・ジョブによって書き込まれるバックアップ・セットの合計サイズが表示されます。登録されているすべてのデータベースのバックアップ・セットのサイズを表示するには、RC_RMAN_BACKUP_JOB_DETAILSを問い合せます。
次の問合せによって、バックアップ・ジョブのサイズが、Recovery Managerセッションの主キーであるセッション・キーの順序で表示されます。列in_secおよびout_secに、1秒当たりのデータの入力と出力が表示されます。
COL in_size FORMAT a10 COL out_size FORMAT a10 SELECT SESSION_KEY, INPUT_TYPE, COMPRESSION_RATIO, INPUT_BYTES_DISPLAY in_size, OUTPUT_BYTES_DISPLAY out_size FROM V$RMAN_BACKUP_JOB_DETAILS ORDER BY SESSION_KEY;
次に、バックアップ・ジョブのサイズの出力例を示します。
SESSION_KEY INPUT_TYPE COMPRESSION_RATIO IN_SIZE OUT_SIZE ----------- ------------- ----------------- ---------- ---------- 10 DATAFILE FULL 1 602.50M 602.58M 17 DB FULL 1.13736669 634.80M 558.13M
V$BACKUP_PIECEおよびRC_BACKUP_PIECEのENCRYPTED列は、バックアップ・ピースが暗号化されているか（YES）、暗号化されていないか（NO）を示します。たとえば、SQL*Plusで次の問合せを実行すると、暗号化されているバックアップ・ピースを確認できます。
COL BS_REC FORMAT 99999 COL BP_REC FORMAT 99999 COL MB FORMAT 9999999 COL ENCRYPTED FORMAT A7 COL TAG FORMAT A25 SELECT S.RECID AS "BS_REC", P.RECID AS "BP_REC", P.ENCRYPTED, P.TAG, P.HANDLE AS "MEDIA_HANDLE" FROM V$BACKUP_PIECE P, V$BACKUP_SET S WHERE P.SET_STAMP = S.SET_STAMP AND P.SET_COUNT = S.SET_COUNT;
次に、バックアップが暗号化されていることを示す出力例を示します。
BS_REC BP_REC ENCRYPT TAG ------ ------ ------- ------------------------- MEDIA_HANDLE -------------------------------------------------------------------------------- 1 1 YES TAG20070711T140124 /disk1/c-39525561-20070711-00 2 2 YES TAG20070711T140128 /disk1/c-39525561-20070711-01 3 3 YES TAG20070711T140130 /disk1/c-39525561-20070711-02
LIST、REPORTおよびSHOWコマンドを使用すると、制御ファイルおよびリカバリ・カタログ内のデータに簡単にアクセスできます。また、リカバリ・カタログ・ビューから有効な情報を取得できる場合もあります。リカバリ・カタログ・ビューとは、リカバリ・カタログ・スキーマ内に存在するRC_接頭辞が付いたビューのことです。
Recovery Managerは、ターゲット・データベースの制御ファイルからバックアップおよびリカバリのメタデータを取得し、リカバリ・カタログの表に格納します。リカバリ・カタログ・ビューは、これらの表から導出されます。リカバリ・カタログ・ビューは、ユーザーによる問合せに対して正規化または最適化されていません。
通常、リカバリ・カタログ・ビューは、Recovery Managerのレポート・コマンドほど簡単に使用できません。たとえば、Recovery Managerを起動してターゲット・データベースに接続した場合、LIST、REPORTおよびSHOWコマンドを発行するのみでこのターゲット・データベースの情報を取得できます。同じリカバリ・カタログに10個の異なるターゲット・データベースを登録している場合、カタログ・ビューの問合せによって、10個すべてのデータベースのすべてのインカネーションのメタデータが表示されます。多くの場合、ビュー間で複雑な選択および結合を実行して、データベース・インカネーションに関する使用可能な情報を抽出する必要があります。
ほとんどのカタログ・ビューには、対応するV$がデータベース内に存在します。たとえば、RC_BACKUP_PIECEはV$BACKUP_PIECEに対応しています。リカバリ・カタログ・ビューと対応するV$ビューとの主な違いとしては、各リカバリ・カタログ・ビューにはリカバリ・カタログに登録されているすべてのターゲット・データベースに関するメタデータが含まれていることがあげられます。V$には、ビュー自体の情報のみが含まれています。
ほとんどのリカバリ・カタログ・ビューには、列DB_KEYおよびDBINC_KEYが含まれています。リカバリ・カタログに登録されている各データベースは、主キー（DB_KEY列値）またはDBID（32ビットの一意のデータベース識別子）のいずれかによって一意に識別できます。データベースの各インカネーションは、DBINC_KEY列によって一意に識別されます。
DB_KEYおよびDBINC_KEYを使用すると、ターゲット・データベースの特定のインカネーションのレコードを取得できます。その後、他のほとんどのカタログ・ビューとの結合を実行して、このインカネーションに属するレコードを分離できます。
カタログ・ビューとV$ビューとの主な違いとしては、バックアップ・ファイルおよびリカバリ・ファイルに使用される一意の識別子の形式が異なることがあげられます。たとえば、V$ARCHIVED_LOGなどの多くのV$ビューでは、RECID列およびSTAMP列によって連結主キーが構成されます。対応するリカバリ・カタログ・ビューでは、導出された値が主キーとして使用され、この値は単一の列に格納されます。たとえば、RC_ARCHIVED_LOGの主キーはAL_KEY列です。AL_KEYの列値は、LISTコマンドの出力に表示される主キーです。
Data Guard環境でリカバリ・カタログを問い合せる場合は、特別な考慮事項が適用されます。Data Guard環境では、複数のデータベースで同じDBIDが共有されます。複数のビューに、（レコードが含まれているデータベース・インカネーションのDB_UNIQUE_NAMEを示す）DB_UNIQUE_NAME列が含まれています。Data Guard環境のすべてのデータベースで同じDBIDが共有されますが、DB_UNIQUE_NAMEの値は異なります。
データベース名がカタログで認識されない場合は、リカバリ・カタログに登録されているOracle9i データベースの場合と同様に、DB_UNIQUE_NAMEの値はnullになります。また、データベースをOracle Database 11g にアップグレードしたにもかかわらず、リカバリ・カタログのスキーマとすべてのファイルのデータベース名が一致していない場合も、列値はnullになります。
リカバリ・カタログ・ビューでは、プライマリ・データベースとスタンバイ・データベースは同じDB_KEYを共有します。ただし、Data Guard環境のすべてのデータベースに、一意のRC_SITE.SITE_KEY値があります。たとえば、プライマリ・データベースprodおよびスタンバイ・データベースstandby1の両方に値が1のDB_KEYがある場合がありますが、prodのSITE_KEYは3で、standby1のSITE_KEYは30です。
一部のリカバリ・カタログ・ビューには、DB_UNIQUE_NAME列はありませんが、SITE_KEY列はあります。SITE_KEY列を使用してRC_SITE.SITE_KEYと結合し、ファイルに関連付けられているデータベースのDB_UNIQUE_NAMEを決定できます。「Data Guard環境でのRecovery Managerによるファイル管理」で説明されているように、Data Guard環境では、すべてのファイルがそのファイルを作成したプライマリ・データベースまたはスタンバイ・データベースに関連付けられています。
DB_KEY値は、登録されているデータベースの主キーであり、リカバリ・カタログでのみ使用されます。DB_KEYを取得する最も簡単な方法は、ターゲット・データベースのDBIDを使用する方法です。このDBIDは、Recovery ManagerをTARGETとしてデータベースに接続するたびに表示されます。DBIDによって、Recovery Managerのリカバリ・カタログ内に登録されているデータベースが識別されます。
リカバリ・カタログに登録されているいずれかのデータベースに関する情報を取得するとします。
DBIDは、Recovery Managerをデータベースに接続したときに表示される出力を参照するか、V$RMAN_OUTPUTを問い合せるか、またはV$DATABASEビューを問い合せることによって取得できます。次の例では、SQL*Plusを目的のデータベースに接続してDBIDを問い合せます。
SQL> CONNECT / AS SYSDBA SQL> SELECT DBID 2 FROM V$DATABASE; DBID --------- 598368217
その後、次の問合せを実行して、データベースのDB_KEYを取得することができます。ここで、dbid_of_targetは、手順1で取得したDBIDです。
SELECT DB_KEY FROM RC_DATABASE WHERE DBID = dbid_of_target;
ターゲット・データベースの現行のインカネーションに関する情報を取得するには、ターゲット・データベースのDB_KEY値を指定し、RC_DATABASE_INCARNATIONとの結合を実行します。WHERE条件を使用して、CURRENT_INCARNATION列値がYESである条件を指定します。たとえば、DB_KEY値を1に指定して、ターゲット・データベースの現行のインカネーションに設定されたバックアップ・セットに関する情報を取得するには、次の問合せを実行します。
SELECT BS_KEY, BACKUP_TYPE, COMPLETION_TIME FROM RC_DATABASE_INCARNATION i, RC_BACKUP_SET b WHERE i.DB_KEY = 1 AND i.DB_KEY = b.DB_KEY AND i.CURRENT_INCARNATION = 'YES';
|
参照:
|
ビューRC_BACKUP_FILESに対しては、リカバリ・カタログに登録されているデータベースのすべてのバックアップに関する情報を問い合せることができます。ただし、RC_BACKUP_FILESを問い合せる前に、DBMS_RCVMAN.SETDATABASEをコールする必要があります。次の例に示すように、リカバリ・カタログに登録されているいずれかのデータベースのDBIDを指定します。
SQL> CALL DBMS_RCVMAN.SETDATABASE(null,null,null,2283997583);
4番目のパラメータは、リカバリ・カタログに登録されているデータベースのDBIDにする必要があります。その他のパラメータは、すべてNULLにする必要があります。
|
参照:
|
|
 Copyright © 2003, 2008, Oracle Corporation. All Rights Reserved. |
|