11g リリース1（11.1）
E05703-02
 目次 |
 索引 |
| Oracle Databaseバックアップおよびリカバリ・リファレンス 11g リリース1（11.1） E05703-02 |
|
この章では、Recovery Managerのコマンドをアルファベット順に説明します。Recovery Managerコマンドとコマンドライン・オプションの概要は、「Recovery Managerコマンドの概要」を参照してください。
@コマンドを使用すると、指定したパス名のオペレーティング・システム・ファイルに格納されている一連のRecovery Managerコマンドを実行できます。
コマンド・ファイルには、完全なRecovery Managerコマンドを記述する必要があります。
@コマンドをRUNコマンド内で使用する場合は、@コマンドを独自の行に記述する必要があります（例2-2を参照）。
Recovery Managerは、ファイルの内容が@コマンドの位置に記述されているのと同様に処理します。例2-3に示すように、コマンド・ファイル内に置換変数を指定し、実行時にそのコマンド・ファイルに値を渡すことができます。
次の例では、Recovery Managerコマンド・ファイルを作成し、それをオペレーティング・システムのコマンドラインから実行します。
% echo "BACKUP DATABASE;" > backup_db.rman
% rman TARGET / @backup_db.rman
例2-2 Recovery Managerでのコマンド・ファイルの実行
次の例は、コマンド・ファイルを、Recovery Managerプロンプトから実行する方法とRUNコマンド内から実行する方法を示しています。ユーザー入力のテキストは太字で示しています。
RMAN> @backup_db.rman
RMAN> RUN {
2> @backup_db.rman
3> backup database;
4> **end-of-file**
5> }
例2-3 置換変数の指定
テキスト・エディタを使用して、次の内容のコマンド・ファイルwhole_dbを作成したとします。
# name: whole_db.rman
BACKUP TAG &1 COPIES &2 DATABASE;
EXIT;
次の例では、オペレーティング・システムのプロンプトでRecovery Managerを起動してから、ターゲット・データベースに接続します。次に、@コマンドを実行してコマンド・ファイルに変数を渡し、タグがQ106のデータベース・バックアップを2つ作成します。
% rman TARGET /
RMAN> @/tmp/whole_db.rman Q106 2
@@コマンドを使用すると、指定したファイル名のオペレーティング・システム・ファイルに格納されている一連のRecovery Managerコマンドを実行できます。
@@がコマンド・ファイルに含まれている場合、@@filenameによって、Recovery Managerは、指定したファイル名をコール元のコマンド・ファイルと同じディレクトリ内で検索します。@@コマンドは、コマンド・ファイル内で使用しない場合、@コマンドと同じです。
コマンド・ファイルには、完全なRecovery Managerコマンドを記述する必要があります。
コマンド・ファイルは、Recovery Managerクライアントに対してローカルです。ファイル名の解決は、オペレーティング・システムに依存します。たとえば、UNIXまたはWindowsでの@tmp/cmd1.rmanの場合、tmpが現行のディレクトリのサブディレクトリで、ファイルcmd1.rmanがそのサブディレクトリの中にあることを意味しています。
ここで、@と@@の違いを示します。Recovery Managerを次のように起動するとします。
% rman TARGET / RMAN> @/tmp/cmd1.rman
cmd1.rmanスクリプト内にコマンド@@cmd2.rmanがあるとします。この場合、@@コマンドはRecovery Managerに対して、ディレクトリ/tmpにあるファイルcmd2.rmanを検索するように指示します。
@コマンドの場合と同様に、コマンド・ファイル内に置換変数を指定して、@@の実行時に、そのコマンド・ファイルに値を渡すことができます（例2-4を参照）。
| 構文の要素 | 説明 |
|---|---|
|
|
たとえば、コマンド・ファイルの名前を |
次のオペレーティング・システム・コマンドによって、コマンド・ファイルbackup_logs.rmanおよびbackup_db.rmanが作成されます。
% echo "BACKUP ARCHIVELOG ALL;" > /tmp/bkup_logs.rman
% echo "BACKUP TAG &1 DATABASE;" > /tmp/bkup_db.rman
% echo "@@bkup_logs.rman" >> /tmp/bkup_db.rman
次の例では、コマンドラインからRecovery Managerを起動し、オペレーティング・システム認証を使用してターゲット・データベースに接続します。@コマンドは、bkup_db.rmanを実行しますが、そのファイルには@@bkup_logs.rmanコマンドが記述されています。@@コマンドは、Recovery Managerに対して、bkup_db.rmanが存在するディレクトリと同じディレクトリからbkup_logs.rmanスクリプトを検索するように指示します。この例では、置換変数を使用して、データベース・バックアップのタグWHOLE_DBが指定されていることに注意してください。
% rman TARGET /
RMAN> @/tmp/bkup_db.rman whole_db
ADVISE FAILUREコマンドを使用すると、指定した障害の修復オプションを表示できます。このコマンドは、データ・リカバリ・アドバイザが認識している障害のサマリーを出力し、修復済の障害がオープン状態になっている場合は、暗黙的にクローズします。
このコマンドを使用する場合の推奨手順は、次のようになります。Recovery Managerセッションで、まずLIST FAILUREを実行して障害を表示し、次にADVISE FAILUREを実行して修復オプションを表示し、REPAIR FAILUREを実行して障害を修復してください。
Recovery Managerがターゲット・データベースに接続している必要があります。TARGETとしてデータベースに接続する方法については、CONNECTおよびRMANコマンドを参照してください。
ターゲット・データベースのインスタンスは起動されている必要があります。ターゲット・データベースは、単一インスタンス・データベースである必要があります。また、ロジカル・スタンバイ・データベースは指定できますが、フィジカル・スタンバイ・データベースは指定できません。
現行リリースでは、データ・リカバリ・アドバイザは、単一インスタンス・データベースのみをサポートします。Oracle Real Application Clusters（Oracle RAC）データベースはサポートされていません。
データ・リカバリ・アドバイザは、修復の可能性を検証してから修復方法を提案します。たとえば、データ・リカバリ・アドバイザが、メディア・リカバリに必要なすべてのバックアップとアーカイブREDOログ・ファイルが使用可能かどうかをチェックするとします。ADVISE FAILUREの出力には、データ・リカバリ・アドバイザが特定の障害に対して最適とみなした修復方法が示されます。ADVISE FAILUREコマンドでは、手動と自動の両方の修復オプションを生成できます。
手動修復オプションは、必須または任意のいずれかになります。任意のアクションの方が、自動修復よりも短時間で簡単に障害を修正できることがあります。他にも、自動修復が実現できないため、手動が唯一のオプションになる場合もあります。たとえば、I/O障害は、ほとんどの場合に自動では修復できません。また、オペレーティング・システムやディスク・サブシステムから戻されるデータが不十分なために、障害を診断できない場合もあります。
各自動修復オプションは、単一修復または修復ステップ・セットのいずれかです（コマンド出力の説明については、表2-1「自動修復オプション」を参照）。修復オプションに、複数の修復ステップがあるスクリプトが含まれる場合、ADVISE FAILUREは、修復ステップが正しい順序になるようにスクリプトを生成します。単一修復の場合は、常にCRITICALな障害がまとめて修復されます。CRITICALな障害の修復は必須ですが、CRITICALでない障害を同時に修復することも可能です。CRITICALでない障害は、1つずつ任意の順序で修復することも、まとめて修復することもできます。
Oracle RACデータベースのすべてのインスタンスでデータ障害が発生した場合に、単一インスタンス・モードでデータベースをマウントしてデータ・リカバリ・アドバイザを使用すると、制御ファイル、SYSTEMデータファイルおよびディクショナリの障害を検出して修復できます。また、ヘルス・チェックを開始して、他のデータベース・コンポーネントにデータ障害がないかをテストすることもできます。この方法では、他のクラスタ・インスタンスに対してローカルなデータ障害（アクセス不能なデータファイルなど）は検出されません。
| 構文の要素 | 説明 |
|---|---|
|
|
自動診断リポジトリに記録されている障害のうち、優先順位が
現行のセッションで
注意: 現行のRecovery Managerセッションで、LIST |
|
|
オープン状態のすべての障害をまとめて修復するオプションを表示します。 |
|
|
重大な障害のみを修復するオプションを表示します。 |
|
|
優先順位が |
|
|
優先順位が |
|
|
指定された障害のみを修復するオプションを表示します。 |
|
|
指定された障害をリストから除外します。 |
ADVISE FAILUREの出力には、LIST FAILUREの出力も含まれます（説明は、表2-26「障害のリスト」を参照）。出力例については、例2-5を参照してください。
Recovery Managerは、順序が決まっていないリスト形式で必須および任意の手動によるアクションを提示します。手動オプションが存在する場合は、自動オプションの前に表示されます。表2-1に、自動修復オプションの出力を示します。
| 列 | 指定対象 |
|---|---|
|
|
自動修復オプションの識別子。 |
|
|
REPAIR FAILUREコマンドで障害を修復する方法。 データ・リカバリ・アドバイザで提示される自動修復オプションは、可能な場合には必ずデータ消失のないオプションになります。自動修復オプションは、基本的に次のカテゴリに分類されます。
注意: |
|
|
提案された修復の説明。たとえば、データファイル17のリストアとリカバリが、修復として提案されます。 |
|
|
すべての修復アクションとコメントが記述された編集可能なスクリプトの場所。自動修復を実行しない場合は、このスクリプトの内容を確認して、手動リカバリで使用するように編集できます。 |
この例は、データ・リカバリ・アドバイザで認識されているすべての障害の修復オプションを表示します。この例では、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
ALLOCATE CHANNELコマンドを使用すると、Recovery Managerとデータベース・インスタンスを接続するチャネルを手動で割り当てることができます。ALLOCATE CHANNELは、REPAIR FAILUREブロック内で発行する必要があります。適用されるのは、発行されたブロックのみです。
ターゲット・インスタンスを事前に起動する必要があります。
手動で割り当てたチャネルと、CONFIGUREを指定して自動的に割り当てたチャネルは区別されます。自動チャネルは、手動でチャネルを割り当てていないすべてのRecovery Managerのジョブに適用されます。自動チャネル構成を、RUNコマンド内で手動で割り当てたチャネルでオーバーライドすることはできますが、手動チャネルをALLOCATE CHANNELで指定した後で、BACKUP DEVICE TYPEまたはRESTORE DEVICE TYPEを使用して、自動チャネルを使用することはできません。
割り当てることができるチャネルは最大255で、チャネル当たり最大64ファイルをパラレルに読み取ることができます。ジョブ内の並列度は、割り当てるチャネル数で制御できます。複数チャネルを同時に割り当てると、1つのジョブで複数のバックアップ・セットやディスク・コピーをパラレルに読み書きできます。こうして、各チャネルが別々のバックアップ・セットまたはコピーの操作を行います。
ディスクへのバックアップを行う場合、通常は、出力デバイスごとにチャネルを1つ割り当てます（例2-7を参照）。ただし、Recovery Managerが、ストライプ化されたファイル・システムまたはASMディスク・グループに対して書込みを行う場合は、複数のチャネルを使用することでパフォーマンスを向上できます。テープにバックアップを作成する場合は、一般に、テープ・デバイスの数を多重化されたコピー数で除算した数が、テープ・チャネルの数に等しくなるようにします（例2-8を参照）。
すべてのOracle RACインスタンスのSYSDBAパスワードが同じであるかぎり、 ALLOCATEまたはCONFIGUREコマンドのCONNECTオプションでパスワードを指定する必要はありません。user@database形式の接続文字列を使用すると、Recovery Managerセッションの開始時にTARGET接続で使用されたものと同じパスワードが自動的に使用されます。
（deviceSpecifier::=、allocOperandList::=）
| 構文の要素 | 説明 |
|---|---|
|
|
Recovery Managerと補助データベース・インスタンスとの接続を指定します。
補助インスタンスは、DUPLICATEまたはTRANSPORT TABLESPACEコマンドを実行する場合、およびRECOVER
関連項目: データベースの複製方法は「DUPLICATE」を、複製データベース・インスタンスへの接続方法は |
|
|
Recovery Managerとターゲット・データベース・インスタンスとの接続を指定します。 接続するたびに、ターゲット・インスタンスまたは補助インスタンスでデータベース・サーバー・セッションが開始されます。このセッションで、Recovery Managerバックアップのバックアップ、リストアまたはリカバリが実行されます。共有サーバー・セッションには接続できません。
各チャネルは、一度に1つのバックアップ・セットまたはイメージ・コピーを使用します。Recovery Managerは、ジョブ終了時に自動的にチャネルを解放します。
注意: チャネル名の接頭辞に |
|
|
バックアップ用のストレージ・タイプを指定します。
注意: 関連項目: 「deviceSpecifier」を参照してください。 |
|
割り当てたチャネルの制御オプションを指定します。順次I/Oデバイスのチャネル・パラメータはプラットフォームによって異なることに注意してください（例2-6を参照）。 関連項目: 「allocOperandList」を参照してください。 |
この例では、データベース全体およびアーカイブREDOログのバックアップ用に1つのテープ・チャネルを割り当てます。PARMSパラメータで、wholedb_mfというOracle Secure Backupメディア・ファミリを指定しています。
RUN
{
ALLOCATE CHANNEL c1 DEVICE TYPE sbt
PARMS 'ENV=(OB_MEDIA_FAMILY=wholedb_mf)';
BACKUP DATABASE;
BACKUP ARCHIVELOG ALL NOT BACKED UP;
}
例2-7 複数ディスクへのバックアップの分散
ディスクにバックアップする場合は、複数のディスク・ドライブに分散したバックアップが実行できます。ディスク・ドライブごとにDEVICE TYPE DISKチャネルを1つ割り当て、出力ファイルごとにディスクが異なるようにフォーマット文字列を指定します。
RUN
{
ALLOCATE CHANNEL disk1 DEVICE TYPE DISK FORMAT '/disk1/%U';
ALLOCATE CHANNEL disk2 DEVICE TYPE DISK FORMAT '/disk2/%U';
BACKUP DATABASE PLUS ARCHIVELOG;
}
例2-8 テープへのバックアップの複数コピーの作成
この例では、stape1、stape2、stape3およびstape4の4つのテープ・ドライブを書込みに使用できます。SET BACKUP COPIESコマンドを使用して、Recovery Managerがデータベース・バックアップの同じコピーを2つ作成する必要があることを示します。一般に、テープ・チャネルの数は、多重化されたコピー数でテープ・デバイスの数を除算した数と等しくする必要があるため、2つのチャネルを割り当てます。この場合、BACKUP_TAPE_IO_SLAVES初期化パラメータをTRUEに設定する必要があることに注意してください。
Oracle Secure BackupのOB_DEVICE_nパラメータでは、nにバックアップ・ピースのコピー数を指定します。Recovery Managerは、各バックアップ・ピースのコピー1をstape1とstape2のテープ・ドライブに書き込み、各バックアップ・ピースのコピー2をstape3とstape4のドライブに書き込みます。このようにして、データベース・バックアップの各コピーは、2つのテープ・ドライブ間で分散され、各ドライブ上にデータの一部が格納されます。
RUN
{
ALLOCATE CHANNEL t1 DEVICE TYPE sbt
PARMS 'ENV=(OB_DEVICE_1=stape1,OB_DEVICE_2=stape3)';
ALLOCATE CHANNEL t2 DEVICE TYPE sbt
PARMS 'ENV=(OB_DEVICE_1=stape2,OB_DEVICE_2=stape4)';
SET BACKUP COPIES 2;
BACKUP DATABASE;
}
例2-9 データベース複製用の補助チャネルの割当て
この例では、バックアップから複製データベースが作成されます。複製用に構成されたチャネルでAUXILIARYオプションが指定されていない場合でも、Recovery Managerは、そのチャネルを使用できます。この例では、事前に構成されているSBTチャネルがないため、補助SBTチャネルを手動で割り当てます。
RUN
{
ALLOCATE AUXILIARY CHANNEL c1 DEVICE TYPE sbt;
DUPLICATE TARGET DATABASE
TO dupdb
DB_FILE_NAME_CONVERT '/disk2/dbs/','/disk1/'
SPFILE
PARAMETER_VALUE_CONVERT '/disk2/dbs/',
'/disk1/'
SET LOG_FILE_NAME_CONVERT '/disk2/dbs/',
'/disk1/';
}
ALLOCATE CHANNEL FOR MAINTENANCEコマンドを使用すると、CHANGE、DELETEまたはCROSSCHECKコマンドの発行に備えてチャネルを手動で割り当てることができます。チャネルの割当て解除は、RELEASE CHANNELコマンドで実行できます。
|
注意:
CONFIGUREを使用して、構成内のデバイス・タイプごとにチャネルを1つ以上割り当てる場合は、 |
このコマンドは、RUNブロック内ではなく、Recovery Managerプロンプトでのみ実行できます。ターゲット・インスタンスを事前に起動する必要があります。共有セッションにメンテナンス・チャネルを割り当てることはできません。
メンテナンス・チャネルは、原則としてデバイスごとに1つずつ割り当ててください。手動割当てチャネルと自動チャネルが混在することはありません。一般に、1つのジョブに対して複数のメンテナンス・チャネルを割り当てるのは、次の場合に限定してください。
Recovery Managerではメンテナンス・チャネルのネーミング規則としてORA_MAINT_devicetype_nが使用されます。devicetypeはDISKまたはsbtで、nはチャネル番号です。たとえば、Recovery Managerでは、手動で割り当てた2つのディスク・チャネルに次の名前が使用されます。
ORA_MAINT_DISK_1
ORA_MAINT_DISK_2
（deviceSpecifier::=、allocOperandList::=）
| 構文の要素 | 説明 |
|---|---|
|
|
バックアップ用のストレージ・タイプを指定します。 関連項目: 「deviceSpecifier」を参照してください。 |
|
割り当てたチャネルの制御オプションを指定します。順次I/Oデバイスのチャネル・パラメータはプラットフォームによって異なることに注意してください。 関連項目: 「allocOperandList」を参照してください。 |
すべてのRecovery Managerバックアップを削除して、テープ・セットを再利用する必要があるとします。この例では、ディスク・チャネルのみがデフォルトで構成されています。この例では、SBTチャネルを手動で割り当て、すべてのバックアップをテープから削除した後で、チャネルを解放します。
RMAN> ALLOCATE CHANNEL FOR MAINTENANCE DEVICE TYPE sbt;
allocated channel: ORA_MAINT_SBT_TAPE_1
channel ORA_MAINT_SBT_TAPE_1: SID=135 device type=SBT_TAPE
channel ORA_MAINT_SBT_TAPE_1: Oracle Secure Backup
RMAN> DELETE NOPROMPT BACKUP;
List of Backup Pieces
BP Key BS Key Pc# Cp# Status Device Type Piece Name
------- ------- --- --- ----------- ----------- ----------
9957 9954 1 1 AVAILABLE SBT_TAPE 8oic41ad_1_1
9974 9972 1 1 AVAILABLE SBT_TAPE c-28014364-20070308-17
10024 10021 1 1 AVAILABLE SBT_TAPE 8qic41c3_1_1
10045 10042 1 1 AVAILABLE SBT_TAPE c-28014364-20070308-18
10446 10443 1 1 AVAILABLE SBT_TAPE 8uic47fg_1_1
10487 10482 1 1 AVAILABLE SBT_TAPE 90ic47ih_1_1
10488 10483 1 1 AVAILABLE SBT_TAPE 91ic47j1_1_1
10524 10514 1 1 AVAILABLE SBT_TAPE 92ic47q4_1_1
10540 10538 1 1 AVAILABLE SBT_TAPE c-28014364-20070308-1a
deleted backup piece
backup piece handle=8oic41ad_1_1 RECID=198 STAMP=616695118
deleted backup piece
backup piece handle=c-28014364-20070308-17 RECID=199 STAMP=616695145
deleted backup piece
backup piece handle=8qic41c3_1_1 RECID=200 STAMP=616695171
deleted backup piece
backup piece handle=c-28014364-20070308-18 RECID=201 STAMP=616695188
deleted backup piece
backup piece handle=8uic47fg_1_1 RECID=204 STAMP=616701424
deleted backup piece
backup piece handle=90ic47ih_1_1 RECID=205 STAMP=616701521
deleted backup piece
backup piece handle=91ic47j1_1_1 RECID=206 STAMP=616701538
deleted backup piece
backup piece handle=92ic47q4_1_1 RECID=207 STAMP=616701764
deleted backup piece
backup piece handle=c-28014364-20070308-1a RECID=208 STAMP=616701783
Deleted 11 objects
RMAN> RELEASE CHANNEL;
released channel: ORA_MAINT_SBT_TAPE_1
例2-11 複数のデバイス上のバックアップのクロスチェック
ディスク上とテープ上のアーカイブREDOログをクロスチェックする必要があるとします。また、デフォルトのデバイス・タイプがディスクに設定され、SBTチャネルも構成されていますが、ディスクとテープの両方に別のチャネルを使用する必要があるとします。その場合は、必要に応じた設定でメンテナンス・チャネルを手動で割り当てることができます。
RMAN> SHOW DEFAULT DEVICE TYPE;
RMAN configuration parameters for database with db_unique_name PROD are:
CONFIGURE DEFAULT DEVICE TYPE TO DISK;
RMAN> SHOW CHANNEL;
RMAN configuration parameters for database with db_unique_name PROD are:
CONFIGURE CHANNEL DEVICE TYPE 'SBT_TAPE' PARMS 'SBT_LIBRARY=/usr/local/oracle/backup/lib/libobk.so, ENV=(OB_DEVICE_1=stape1)';
RMAN> ALLOCATE CHANNEL FOR MAINTENANCE DEVICE TYPE sbt PARMS 'SBT_LIBRARY=/usr/local/oracle/backup/lib/libobk.so, ENV=(OB_DEVICE_1=stape2)';
allocated channel: ORA_MAINT_SBT_TAPE_1
channel ORA_MAINT_SBT_TAPE_1: SID=135 device type=SBT_TAPE
channel ORA_MAINT_SBT_TAPE_1: Oracle Secure Backup
RMAN> ALLOCATE CHANNEL FOR MAINTENANCE DEVICE TYPE DISK FORMAT "/disk2/%U";
allocated channel: ORA_MAINT_DISK_2
channel ORA_MAINT_DISK_2: SID=101 device type=DISK
Finished Control File and SPFILE Autobackup at 09-MAR-07
RMAN> CROSSCHECK BACKUP OF ARCHIVELOG ALL;
crosschecked backup piece: found to be 'AVAILABLE'
backup piece handle=/disk2/95ic69jc_1_1 RECID=210 STAMP=616769132
crosschecked backup piece: found to be 'EXPIRED'
backup piece handle=/disk2/96ic69jf_1_1 RECID=211 STAMP=616769135
Crosschecked 2 objects
crosschecked backup piece: found to be 'AVAILABLE'
backup piece handle=/disk2/96ic69jf_1_1 RECID=211 STAMP=616769135
Crosschecked 1 objects
RMAN> RELEASE CHANNEL;
released channel: ORA_MAINT_SBT_TAPE_1
released channel: ORA_MAINT_DISK_2
例2-12 Oracle Real Application Clusters（Oracle RAC）構成でのクロスチェック
Oracle RAC構成内のすべてのノードに、すべてのストレージ・デバイス上のすべてのバックアップに対する同じアクセス権を付与することをお薦めします（ただし、これは必須要件ではありません）。Oracle RAC構成の2つのノードでバックアップのクロスチェックを実行するとします。各ノードには、ディスク・バックアップのサブセットへのアクセス権があります。すべてのバックアップは、クロスチェックで使用される2つのノードのうち少なくとも1つからアクセス可能であるものとします。いずれのノードからもアクセスできない任意のバックアップは、クロスチェック後にEXPIREDとマークされます。
次の例では、Oracle RACインスタンスinst1およびinst2へのチャネル接続を示します。両方のチャネル接続で、Recovery Managerは、ターゲット・データベース接続で入力したユーザー名とパスワードと同じものを使用します。
ALLOCATE CHANNEL FOR MAINTENANCE DEVICE TYPE DISK
CONNECT '@inst1';
ALLOCATE CHANNEL FOR MAINTENANCE DEVICE TYPE DISK
CONNECT '@inst2';
CROSSCHECK BACKUP;
ALTER DATABASEコマンドを使用すると、データベースをマウントまたはオープンできます。
このコマンドは、RUNコマンドのカッコ内またはRecovery Managerプロンプトで実行してください。ターゲット・インスタンスを事前に起動する必要があります。
| 構文の要素 | 説明 |
|---|---|
|
|
データベースをマウントします。オープンはしません。このオプションを指定したコマンドは、SQL文 |
|
|
データベースをオープンします（例2-13を参照）。RECOVER |
|
|
現行のオンラインREDOログ（または、破損が検出された場合はREDO破損前の最後のREDOレコードまで）をアーカイブし、オンラインREDOログの内容を消去してオンラインREDOログをログ順序1にリセットします。Recovery Managerコマンドの
リカバリ・カタログを使用する場合、Recovery Managerは、データベースがオープンされた後でRESET DATABASEを暗黙的に発行し、この新規のインカネーションをカタログ内で現行のインカネーションにします。Recovery Managerコマンドの |
データベースがオープンされており、そのデータベース全体の一貫性バックアップを作成する必要があるとします。この例では、一貫性を保ってデータベースを停止し、データベースをマウントし、一貫性のあるデータベース全体のバックアップを作成してから、データベースをオープンします。
SHUTDOWN IMMEDIATE;
STARTUP MOUNT;
BACKUP DATABASE PLUS ARCHIVELOG;
# Now that the backup is complete, open the database.
ALTER DATABASE OPEN;
例2-14 制御ファイルのリストア後のデータベースのマウント
この例では、制御ファイルのリストアとマウントを行ってから、リカバリを実行します。最後に、オンラインREDOログをリセットします。
STARTUP FORCE NOMOUNT;
RESTORE CONTROLFILE FROM AUTOBACKUP;
ALTER DATABASE MOUNT;
# you must run the RECOVER command after restoring a control file even if no datafiles
# require recovery
RECOVER DEVICE TYPE DISK DATABASE;
ALTER DATABASE OPEN RESETLOGS;
BACKUPコマンドを使用すると、データベース（プライマリまたはスタンバイ）、表領域、データファイル（現行またはコピー）、制御ファイル（現行またはコピー）、サーバー・パラメータ・ファイル、アーカイブREDOログ・ファイルまたはバックアップ・セットのバックアップを作成できます。
Recovery Managerがターゲット・データベースに接続されている必要があります。TARGETとしてデータベースに接続する方法については、CONNECTおよびRMANコマンドを参照してください。
ターゲット・データベースのモードがARCHIVELOGの場合は、データベースが、現行の制御ファイルでマウントされているかまたはオープンされている必要があります。データベースがオープンされているときに作成されたバックアップには、一貫性がありません。一貫性のないバックアップをリストアした後は、データベースに一貫性を持たせるために、REDOログを適用する必要があります。
ターゲット・データベースのモードがNOARCHIVELOGの場合は、バックアップの作成時に一貫性のある停止を行った後で、データベースがマウントされている必要があります。停止の一貫性が保たれるのは、NORMAL、IMMEDIATEまたはTRANSACTIONALオプションを指定して、SHUTDOWNコマンドを正しく実行できた場合のみです。インスタンス障害が発生した場合やSHUTDOWN ABORTを実行した後で、Recovery Managerを使用して、NOARCHIVELOGのデータベースをバックアップすることはできません。
ファイルをバックアップできるのは、有効なメディアに対してのみです。DEVICE TYPE DISKを指定すると、ランダム・アクセス・ディスクにバックアップが作成されます。バックアップは、データファイルを格納できる任意のデバイスに作成できます。文CREATE TABLESPACE tablespace_name DATAFILE 'filename'が正しく動作すれば、'filename'は有効なバックアップ・パス名です。DEVICE TYPE sbtを指定した場合は、メディア・マネージャがサポートするメディアであれば、どのメディアにでもファイルをバックアップできます。
Oracleデータベースのファイルをディスクにバックアップする場合、そのファイルの論理ブロック・サイズは、バックアップ先デバイスの物理ブロック・サイズの偶数倍である必要があります。たとえば、ブロック・サイズが2KBのディスク・デバイスは、論理ブロック・サイズが2KB、4KB、6KBなどのOracleファイルのバックアップ先としてのみ使用できます。実際には、ほとんどのディスク・ドライブの物理ブロック・サイズは512バイトのため、この制限事項がバックアップに影響することはほとんどありません。ただし、BACKUP ... DEVICE TYPE DISKコマンドを使用して、書込み可能CDやDVD、またはより大容量の物理ブロック・サイズを持つその他のデバイスにデータベースをバックアップする場合は、この制限事項を考慮する必要がある場合があります。
指定したデバイス・タイプに自動チャネルが構成されていない場合は、BACKUPを実行するたびにチャネルをデバイスに手動で割り当てる必要があります。手動チャネルを割り当てていない場合、Recovery ManagerではCONFIGUREコマンドで設定されたデフォルトのチャネルが使用されます。Recovery Managerには事前構成済のDISKチャネルがありますが、事前構成済のsbtチャネルはありません。
Recovery Managerでバックアップできるのは、データファイル、制御ファイル、サーバー・パラメータ・ファイル、アーカイブREDOログ・ファイル、およびこれらのファイルのRecovery Managerバックアップのみです。その他のデータベース関連ファイル（ネットワーク構成ファイル、パスワード・ファイル、ブロック・チェンジ・トラッキング・ファイルなど）およびOracleデータベース・ホームの内容は、バックアップできません。また、外部表やBFILEデータ型などのOracleデータベースの一部の機能についても、同様に、前述のファイル以外のファイルにデータが格納されます。Recovery Managerでは、これらのファイルをバックアップできません。
BACKUPコマンドは、Recovery Managerでは独立した複数のバックアップ手順に分けられています。独立した各手順は、特定のデバイスに割り当てられたチャネルで実行できます。割り当てられているチャネルが複数ある場合に、1つのチャネルで障害が発生するか、またはバックアップ手順の実行中に問題が発生すると、Recovery Managerは、別のチャネルで作業の完了を試行します。Recovery Managerは、チャネルでフェイルオーバーが発生すると、V$RMAN_OUTPUT、対話方式セッションまたはログ・ファイルへの出力にメッセージをレポートします。
あるプラットフォームで作成されたRecovery Managerバックアップを、別のプラットフォームにトランスポートすることはできません。
以前のリリースのOracleデータベースで作成されたRecovery Managerバックアップは、データベースの移行またはアップグレードの実行後に使用できます。
データベースのDBIDではなく、DB_NAMEを変更すると、Recovery Managerは以前のDB_NAMEで作成されたデータベースのバックアップをリストア可能とみなします。
Recovery Managerでは、バックアップ・セットに書き込まれるデータを透過的に暗号化し、RESTORE操作で必要な際に復号化できます。暗号化したバックアップをディスク上に作成するには、データベースでAdvanced Security Optionを使用している必要があります。暗号化したバックアップをテープ上に直接作成するには、Recovery Managerで、Oracle Secure BackupのSBTインタフェースを使用する必要がありますが、Advanced Security Optionを使用する必要はありません。Oracle Secure Backup以外のSBTライブラリを使用して暗号化されたRecovery Managerバックアップを作成しようとすると、Recovery ManagerによりORA-19916エラーが発行されます。
Recovery Managerでは、バックアップの暗号化に複数の暗号化アルゴリズムを使用できます（アルゴリズムのリストはV$RMAN_ENCRYPTION_ALGORITHMSにあります）。Recovery Manangerは、次の3つの暗号化モードによるバックアップをサポートしています。
データベース・バックアップの暗号化設定の管理には、CONFIGUREおよびSETコマンドを使用します。詳細は、これらのコマンドのリファレンス・エントリを参照してください。アーカイブ・ログが含まれているバックアップ・セットは、次の条件に該当する場合に暗号化されます。
ENCRYPTION ONが有効になっている。
Data Guard環境でRecovery Managerの操作を行う場合は、リカバリ・カタログが必要です。カタログを使用することにより、すべてのプライマリ・データベースまたはスタンバイ・データベースで、Recovery Managerのすべての操作を透過的に実行できるようになります。この環境では、プライマリ・データベースのバックアップを、任意のスタンバイ・データベースにオフロードできます。Recovery Managerバックアップは、交換可能です。Recovery ManagerをNOCATALOGモードで使用する場合、Recovery Managerは、マウントされている制御ファイル内のメタデータのみを使用します。
Data Guard環境では、バックアップまたはコピーを作成するデータベースはファイルに関連付けられます。たとえば、Recovery ManagerがデータベースprodにTARGETとして接続し、そのデータベースをバックアップする場合、このデータベースのバックアップはprodに関連付けられます。CHANGE ... RESET DB_UNIQUE_NAMEを使用してバックアップを別のデータベースに関連付けないかぎり、バックアップは作成されたデータベースとの関連付けを維持します。
バックアップの関連付けとアクセス可能性は異なります。リカバリ・カタログでは、ディスク・バックアップはデータベースが作成されたData Guard環境のデータベースのみからアクセス可能とみなされますが、あるデータベース上で作成されたテープ・バックアップの場合は、すべてのデータベースからアクセス可能とみなされます。バックアップ・ファイルがどのデータベースにも関連付けられていない場合、リカバリ・カタログ・ビューでは、そのバックアップ・ファイルを示す行のSITE_KEY列にnullが示されます。デフォルトでは、SITE_KEYがnullのファイルは、Recovery ManagerがTARGETとして接続されているデータベースに関連付けられます。
Data Guard環境では、Recovery Managerのコマンドはアクセス可能ないずれのバックアップに対しても操作を実行できます。たとえば、データベースprodとstandby1が異なるホスト上に存在するとします。Recovery Managerが、prod上のデータファイル1を本番ホスト上の/prodhst/disk1/df1.dbfとテープに対してバックアップします。さらに、standby1上のデータファイル1をスタンバイ・ホスト上の/sby1hst/disk2/df1.dbfとテープに対してバックアップします。Recovery ManagerがデータベースprodにTARGETとして接続されている場合は、スタンバイ・ホスト上にある/sby1hst/disk2/df1.dbfのバックアップに対してRecovery Managerの操作は実行できません。ただし、Recovery Managerは、standby1で作成されたテープ・バックアップはリストア可能とみなします。
|
注意: スタンバイ・ホストからプライマリ・ホストへ（またはその逆方向に）バックアップをFTPすると、そのバックアップにCATALOGを実行できます。ファイルは、ターゲット・データベースでカタログ化された後、ターゲット・ベースと関連付けられます。 |
Recovery Managerからバックアップにアクセス可能であるかぎり、プライマリまたはスタンバイ・データベースに接続していれば、Recovery Managerのメンテナンス・コマンド（CHANGE、CROSSCHECK、DELETEなど）をバックアップに使用できます。
（backupOperand::=、backupSpec::=、backupSpecOperand::=）
（deviceSpecifier::=、fileNameConversionSpec::=、formatSpec::=、forRecoveryOfSpec::=、keepOption::=、notBackedUpSpec::=、sizeSpec::=、skipSpec::=）
（archivelogRecordSpecifier::=、completedTimeSpec::=、copyOfSpec::=、datafileCopySpec::=、datafileSpec::=、backupSpecOperand::=）
（formatSpec::=、keepOption::=、notBackedUpSpec::=、sizeSpec::=、skipSpec::=）
この句は、バックアップするオブジェクトと、バックアップの制御オプションを指定します。構文図は、「backup::=」を参照してください。
| 構文の要素 | 説明 |
|---|---|
|
|
|
|
|
|
|
|
アーカイブREDOログもバックアップの対象にします（例2-15を参照）。Recovery Managerによって次の手順が実行されます。
注意:
注意: バックアップの最後にオンラインREDOログがアーカイブされていない場合、そのバックアップに |
|
backupSpec句に影響する様々なオプションとパラメータを指定します。 |
この副次句は、デバイス・タイプ、出力形式などのオプションを指定します。構文図は、「backupOperand::=」を参照してください。
| 構文の要素 | 説明 |
|---|---|
|
作成するバックアップのタイプ（バックアップ・セット（AS BACKUPSET）またはイメージ・コピー（AS COPY）のいずれか）を指定します。 関連項目: 詳細は、「backupTypeSpec」を参照してください。 |
|
|
|
バックアップの作成時に使用するチャネルの名前を指定します。この名前には大/小文字の区別があります。たとえば
例2-23に示すように、 注意: backupSpec句でもこのパラメータを指定できます。 |
|
|
物理的な破損チェックを通過したデータ・ブロックと索引ブロックについて、論理的な破損がないかどうかをテストします（例2-25を参照）。
たとえば、行ピースまたは索引エントリの論理的な破損がないかどうかを調べます。Recovery Managerは論理的な破損を見つけると、アラート・ログとサーバー・セッション・トレース・ファイルにそのブロックのログを書き込みます。SET
デフォルトでは、
|
|
|
Recovery Managerで作成する同一バックアップの数（ 複数のフォーマット文字列を使用して、コピーに異なる名前と場所を指定できます。例2-22に、ディスクの様々な場所に多重化されたバックアップを示します。
Recovery Managerは、バックアップをディスクまたはテープのいずれかに多重化できますが、テープとディスクに同時に多重化することはできません。テープにバックアップを行う場合は、コピー数が使用可能なテープ・デバイスの数を超えないようにします。また、 複数のコマンドを多重化するように指定できます。優先順位は次のとおりで、リストの上位にある設定で下位にある設定がオーバーライドされます。
注意: このオプションは、 注意: フラッシュ・リカバリ領域にファイルを作成する場合、多重化は使用できません。 |
|
|
最新のレベル0バックアップ以降に使用されたデータ・ブロックをコピーします（例2-16を参照）。 注意: このオプションは、AS COPYには適用されません。使用すると、エラー・メッセージが戻されます。 |
|
|
指定したデバイス・タイプ専用の自動チャネルを割り当てます。たとえば、ディスクおよびテープ・チャネルを構成してから、 BACKUP DEVICE TYPE DISK DATABASE;
注意: 関連項目: 「deviceSpecifier」を参照してください。 |
|
|
各バックアップ・セットに、integerで指定する台数以上のディスクからのデータファイルを移入するようにRecovery Managerに指示します。
このパラメータは、データファイルまたは制御ファイルのバックアップ時に、オペレーティング・システムからRecovery Managerにディスク競合情報およびノードのアフィニティ・データを送信可能な場合にのみ有効です。この機能を手動で無効にするには、
たとえば、データファイルが10台のディスクに分散されるとします。データがディスクから毎秒10バイトで送信され、テープ・ドライブでストリームを維持するために毎秒50バイトが必要な場合は、
FILESPERSET integerを設定して、
注意: I/Oは、テープ・ストリームの維持に必要なディスクの最小台数を越えて分散させないでください。必要以上に分散させた場合、パフォーマンスは向上せず、ファイルのリストア時間が増加します。 |
|
バックアップ・コマンドの最長実行時間に関連するオプションを指定します。 関連項目: 「duration」を参照してください。 |
|
|
このオプションは、 関連項目: ファイルの名前変更パターンについては、「fileNameConversionSpec」を参照してください。 |
|
|
|
各出力バックアップ・セットに含める入力ファイルの最大数を指定します。このパラメータは、
各backupSpecのファイルは、1つ以上のバックアップ・セットとしてバックアップされます。各backupSpecのファイル数が、
次の BACKUP AS BACKUPSET (DATAFILE 3, 4, 5, 6, 7) (DATAFILE 8, 9); 最初のコマンドでは、データファイル3、4、5、6および7が1つのバックアップ・セットに入れられ、データファイル8および9がもう1つのバックアップ・セットに入れられます。2番のコマンドでは、すべてのデータファイルが1つのバックアップ・セットに入れられます。3番目のコマンドの場合、省略記号はデータファイル3〜72を表します。この場合は、70のデータファイルをバックアップすることになるため、64ファイルが1つのバックアップ・セットに入れられ、6ファイルがもう1つのバックアップ・セットに入れられます。
デフォルトでは、チャネル・リソースを最適に使用するために、Recovery Managerによって、ファイルがバックアップ・セットに分割されます。バックアップされるファイルの数が、チャネル数で除算されます。その結果が64未満の場合は、その値が 注意: バックアップ・セット内のバックアップ・ピースの数は指定できません。 |
|
|
Recovery Managerにバックアップの最適化を無視させます。つまり、CONFIGURE 注意: backupSpecOperand句でもこのオプションを指定できます。 |
|
|
ターゲット・データベース上のファイルを、補助インスタンス上の指定された場所にコピーします。
|
|
補助インスタンス上の出力イメージのコピーに名前を付けるパターンを指定します。このパスは、補助ホスト上で有効である必要があります。 関連項目: 有効な置換変数については、「formatSpec」を参照してください。 |
|
|
|
補助インスタンスの |
|
|
出力バックアップ・ピースまたはイメージ・コピーに名前を付けるパターンを指定します（例2-17を参照）。AS COPYの場合、指定した形式で設定されたディレクトリが1つ以上存在しないと、Recovery Managerによってエラーが発行されます。
ディスク・バックアップのデフォルトの場所は、フラッシュ・リカバリ領域が有効かどうかと、
Recovery Managerバックアップを、Oracle Managed Files形式の名前でフラッシュ・リカバリ領域に作成するには、
注意: Oracle Managed Filesのファイル名は、バックアップ用の形式として指定できません。たとえば、 バックアップ・ピースにはそれぞれ一意の名前を付ける必要があります。バックアップ・ピースのファイル名の最大長はプラットフォームによって異なります。メディア・マネージャへのバックアップの場合は、サポートされているMedia Management APIのバージョンの制限によっても長さが制限されます。SBT 1.1をサポートしているベンダーは、14文字までのファイル名をサポートしている必要があります。SBT 1.1のベンダーによってはさらに長いファイル名をサポートしている場合もあります。SBT 2.0をサポートしているベンダーは、512文字までのファイル名をサポートする必要があります。SBT 2.0のベンダーによってはさらに長いファイル名をサポートしている場合もあります。
1つのbackupSpecに、同じ
注意: 関連項目: 有効な置換変数については、「formatSpec」を参照してください。 |
|
イメージ・コピーのロールフォワード時に使用する増分バックアップとして作成するバックアップを識別します。 関連項目: 「forRecoveryOfSpec」を参照してください。 |
|
|
|
バックアップに含まれているデータファイルのすべてのブロックのバックアップを作成します。 全体バックアップは、その後の増分バックアップに影響せず、増分バックアップ計画の一部分とはみなされません。ただし、イメージ・コピーの全体バックアップについては、RECOVERコマンドで増分バックアップを適用して、増分更新が可能です。
注意: 未使用ブロックの圧縮（ |
|
|
最後の増分
注意: レベル0の増分バックアップでは、バックアップ対象のデータファイルのすべてのデータ・ブロックがバックアップされます。レベル0の増分バックアップの内容はFULLバックアップと同じですが、全体バックアップとは異なり、増分バックアップ方法の一部分とみなされます。
レベル1のバックアップでは、変更されたブロックのみがバックアップされます。レベル1の増分バックアップは、差分または レベル0の増分バックアップは、バックアップ・セットまたはイメージ・コピーのいずれかにできますが、レベル1の増分バックアップは、バックアップ・セットのみが可能です。 レベル1の増分バックアップを作成しようとすると、データベースでチェックが実行されます。このチェックによって、増分バックアップがその後のRECOVERコマンドで使用できることが確認されます。チェックの内容は、次のとおりです。
注意: 増分バックアップの作成時、Recovery Managerでは、親インカネーションからのバックアップが有効であるとみなされます。たとえば、レベル0バックアップを作成した後、 プライマリ・データベースまたはスタンバイ・データベースでブロック・チェンジ・トラッキングを有効にすると、増分バックアップのパフォーマンスを向上できます。この場合、Recovery Managerでは、変更されたブロックがブロック・チェンジ・トラッキング・ファイルに記録されます。 チェンジ・トラッキング・ファイルは、データファイルの変更をマークするビットマップをバックアップ間で保持します。データベースでは、各バックアップを行う前にビットマップの切替えが行われます。Oracle Databaseでは、最新の8回のバックアップを網羅するブロック・チェンジ・データが保持されるように、チェンジ・トラッキング・ファイルの領域が自動的に管理されます。ビットマップが8個まで作成されると、最新のビットマップが現行の変更を追跡するビットマップによって上書きされます。 |
|
|
最初のレベル0の増分バックアップでは、データファイル全体がスキャンされます。その後の増分バックアップでは、ブロック・チェンジ・トラッキング・ファイルを使用して、最後のバックアップの後に変更されたとマークされているブロックのみがスキャンされます。増分バックアップの最適化は、ブロック・チェンジ・トラッキング・ファイルの最も古いビットマップ以降に作成された親バックアップに基づいてのみ行われます。 増分バックアップを計画するときは、ビットマップの制限が8個であることに注意してください。たとえば、レベル0のデータベース・バックアップを作成した後、差分増分バックアップを7回実行すると、ブロック・チェンジ・トラッキング・ファイルには8個のビットマップが含まれます。次に、累積レベル1の増分バックアップを作成すると、現在の変更を追跡するビットマップによって親（レベル0）のバックアップに対応するビットマップが上書きされるため、Recovery Managerはバックアップを最適化できなくなります。 関連項目: ブロック・チェンジ・トラッキングの詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。 |
|
|
指定したSCN以上のSCNで変更されたすべてのデータファイル・ブロックが含まれている、指定したすべてのデータファイルの増分バックアップを作成します。 このオプションを使用するのは、プライマリ・データベースの変更に基づいてスタンバイ・データベースをリフレッシュするような場合です（例2-24および『Oracle Data Guard概要および管理』のRecovery Managerバックアップに関する章を参照）。このバックアップには、スタンバイ・データベースが作成された時点または最後に同期されたとき以降に変更されたすべてのブロックが含まれます。スタンバイ・データベースでは、NOREDOを指定してRECOVERを使用し、増分バックアップを適用できます。増分バックアップに取得されたすべての変更ブロックが、スタンバイ・データベースに適用され、プライマリ・データベースによって最新の状態になります。
ボリューム・シャドウ・コピー・サービス（VSS）のスナップショットに基づいて増分バックアップを作成していない場合は、
Windows環境では、
注意: 関連項目: VSSを使用してバックアップを作成する方法については、『Oracle Database Platform Guide for Microsoft Windows』を参照してください。 |
|
バックアップが不要とみなされないように、そのバックアップについて構成されている保存方針をオーバーライドします（例2-26を参照）。
注意:
注意: CHANGEを使用すると、
関連項目: |
|
|
|
バックアップ・セットの最大サイズを指定します（例2-17を参照）。すべてのバックアップ・セットは、このサイズに制限されます。
バックアップ・セットは複数のテープにわたって作成可能なため、各データファイルのブロックは複数のテープに書き込まれる場合があります。複数ボリュームのバックアップ・セットの1つのテープにエラーが発生した場合、すべてのテープのデータを失うことになります。バックアップ・セットには、必ず、ファイルの一部ではなく1つのファイル全体が含まれるため、
サイズはバイト単位（デフォルト）、KB単位（
各バックアップ・セット内のデフォルトのファイル数は、FILESPERSETによって決定されます。デフォルトは64です。
注意: このオプションを |
|
指定した数のバックアップがすでに存在している（かつ不要になっていない）かどうか、または指定した日付以降にログがバックアップされているかどうかによって、バックアップするアーカイブREDOログ・ファイルのセットを制限します。 関連項目: 「notBackedUpSpec」を参照してください。 |
|
|
|
チェックサムとは、データ・ブロックの内容によって計算した数字のことです。
注意:
デフォルトでは、
バックアップ・データファイルのリストア時には、
注意: チェックサムのチェックは
関連項目: |
|
|
このパラメータを |
|
|
バックアップを格納するメディア・プールを指定します。 注意: このオプションは、AS COPYでは機能しません。使用すると、エラー・メッセージが戻されます。 |
|
|
プロキシ・コピー機能を使用して、指定したファイルをバックアップします。これによって、メディア管理ソフトウェアはストレージ・デバイスとディスク上のデータファイルとの間のデータ転送を制御できます。メディア・マネージャ（Recovery Managerではなく）がデータ移動の方法と時期を決めます。
注意: 注意: このオプションは、AS COPYでは機能しません。使用すると、エラー・メッセージが戻されます。 |
|
|
プロキシ・コピーを実行できない場合は、従来のバックアップ・セットを作成しないで、データベースからエラー・メッセージを発行します。プロキシ・コピーで障害が発生したときにRecovery Managerで従来型コピーを試行しない場合は、 |
|
|
Recovery Managerで、 |
|
|
データファイルまたはデータファイル・コピーのバックアップ時に作成される各バックアップ・セクションのサイズを指定します。 このパラメータを設定すると、Recovery Managerでマルチセクション・バックアップを作成できます。マルチセクション・バックアップの場合は、ファイル・セクション（ファイル内の連続したブロック範囲）を1つ含むバックアップ・ピースが作成されます。マルチセクション・バックアップのセクションは、すべて同じサイズになります。 ファイル・セクションを使用すると、複数のステップで、1つの大きなデータファイルのバックアップを処理できます。Recovery Managerのチャネルは、各ステップを個々にパラレルで処理することが可能で、各チャネルではマルチセクション・バックアップ・セットの1つのセクションが生成されます。 ファイルのサイズより大きいセクション・サイズを指定すると、そのファイルに対してはマルチセクション・バックアップは使用されません。256より多くのセクションが作成される小さなセクション・サイズを指定すると、Recovery Managerは、セクション・サイズをちょうど256セクションが作成されるような値に増やします。 注意: このパラメータをRecovery Manager構文のどこに指定するかによって、同じバックアップ・ジョブの中でも、ファイルごとに異なるセクション・サイズを指定できます。
注意: |
|
データファイルまたはアーカイブREDOログがアクセス不能、オフラインまたは読取り専用である場合はバックアップから除外します。 関連項目: 詳細は、「skipSpec」を参照してください。 |
|
|
|
バックアップ・セット、プロキシ・コピー、データファイル・コピーまたは制御ファイル・コピーに対してユーザー指定のタグ名を指定します。タグは、
タグ名には、大/小文字の区別はありません。名前は30文字以下にしてください。使用する文字は、ターゲット・ファイル・システムのファイル名に使用できる有効な文字に限定されています。たとえば、ASMが内部的に使用するファイル名では、ハイフン（
一般的に、タグ名は
タグ名を指定しない場合、デフォルトでは、バックアップ用のタグが作成されます（制御ファイルの自動バックアップを除く）。デフォルトのタグは、 backupSpecレベルでもタグを指定できます。どのレベルでタグを指定するかによって、次のようになります。
注意: タグは、バックアップ・セット（AS BACKUPSETの場合）の特定のコピーの各バックアップ・ピースの属性、または各イメージ・コピー（AS COPYの場合）の属性です。たとえば、 |
|
|
指定されたファイルをスキャンして内容を検査し、そのファイルがバックアップ可能かどうか、およびデータ・ブロックが破損していないかどうかをテストします。 出力ファイルは作成されません。このオプションは、バックアップで指定されたデータベース・ファイルに対してVALIDATEコマンドを使用するのと同じです。
SET
注意: バックアップ・セットのバックアップは検証できません。 |
この副次句は、バックアップの対象とする1つ以上のオブジェクトのリストを指定します。backupSpec句ごとに、1つ以上のバックアップ・セット（AS BACKUPSET）またはイメージ・コピー（AS COPY）が生成されます。AS BACKUPSETでは、オブジェクト・リストで指定したか自動的に選択されたデータファイルの数が、各バックアップ・セットでデフォルトの制限の4個のデータファイルまたは16個のアーカイブ・ログを超えている場合は、backupSpec句で複数のバックアップ・セットが作成されます。構文図は、「backupSpec::=」を参照してください。
| 構文の要素 | 説明 |
|---|---|
|
バックアップ対象となるアーカイブREDOログの範囲を指定します。
アーカイブREDOログのバックアップ作成時に、Recovery Managerでアーカイブ・ログのフェイルオーバーを自動的に実行できます。Recovery Managerは、指定されたログ順序番号およびスレッドに対応する1つ以上のアーカイブ・ログが使用可能な場合に、ログのバックアップを作成します。また、Recovery Managerがバックアップ中のコピーに破損ブロックが含まれている場合は、同じアーカイブ・ログの他のコピー内で該当ブロックの正常なコピーが検索されます。このコマンドでバックアップ対象のログが見つからなくても、Recovery Managerはエラーを発行しません。この状況になるのは、前回の
注意: 関連項目: 構文については「archivelogRecordSpecifier」を、ログ・バックアップ・フェイルオーバーと自動的なログ・スイッチについては『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。 |
|
|
|
バックアップ・セットのバックアップを指定します。このパラメータをDEVICE TYPE deviceSpecifier
Recovery Managerでは、バックアップ・セットのバックアップ時に、バックアップ・セット・フェイルオーバーが実行されます。バックアップ対象となるコピーが破損または欠落している場合は、使用可能なバックアップ・コピーがすべて検索されます。この動作は、複数のアーカイブ先に存在しているアーカイブ・ログのバックアップを作成する場合の、Recovery Managerの動作と同じです。 バックアップ・セットのバックアップ時にバックアップの最適化が有効な場合、同じバックアップ・セットが同じデバイス・タイプにすでにバックアップされていると、そのバックアップ・セットのバックアップはスキップされます。
注意:
注意: 暗号化されたバックアップ・セットに対して |
|
|
すべてのバックアップ・セットを指定します。 |
|
関連項目: 「completedTimeSpec」を参照してください。 |
|
|
|
主キーに基づいてバックアップ・セットを指定します。バックアップ・セットの主キーは、LIST |
|
|
バックアップのための制御ファイル・コピーを1つ以上指定します。
制御ファイルのコピーは、 注意: 制御ファイルの自動バックアップは、制御ファイルのコピーではありません。 |
|
|
ファイル名で制御ファイルのコピーを指定します。 |
|
|
制御ファイルのすべてのコピーを指定します。 |
|
|
ファイル名のパターンで制御ファイルのコピーを指定します。パーセント記号（ |
|
データファイルの前回のイメージ・コピーのバックアップを作成します（制御ファイルに対しても行われる場合があります）。 関連項目: 「copyOfSpec」を参照してください。 |
|
|
|
注意: 現行の制御ファイルのバックアップにタグを割り当てることはできません。 |
|
|
データベース内のすべてのデータファイルのバックアップを作成します。バックアップ・セットを生成すると、Recovery Managerにデータファイルおよび制御ファイルのみを含めることができます。アーカイブREDOログを含めることはできません。
backupSpecにデータファイル1が含まれている場合にCONFIGURE CONTROLFILE AUTOBACKUPを
backupSpecにデータファイル1が含まれている場合にCONFIGURE CONTROLFILE AUTOBACKUPを データベースの全体バックアップは、通常、イメージ・コピーまたは圧縮されたバックアップ・セットのいずれかである必要があります。イメージ・コピーは、作成時に発生するCPUのオーバーヘッドが許容範囲内である場合、いくつかの用途（増分更新バックアップ計画での使用など）でバックアップ・セットより高い柔軟性を示します。また、圧縮されたバックアップ・セットによってストレージをより有効に使用できます。
注意: 関連項目: データベースにBIGFILEの表領域が含まれる場合のバックアップ動作については、TABLESPACE tablespace_nameの説明を参照してください。 |
|
1つ以上のデータファイル・イメージ・コピーのファイル名を指定します。 関連項目: 詳細は、「datafileCopySpec」を参照してください。 |
|
|
|
1つ以上のデータファイルのリストを指定します。データファイル1をバックアップするときのRecovery Managerの動作については、 関連項目: 「datafileSpec」を参照してください。 |
|
|
現行および前回のすべてのフラッシュ・リカバリ領域の指定先に作成されたリカバリ・ファイルをバックアップします。バックアップは、SBTに作成する必要があります。 リカバリ・ファイルには、全体および増分のバックアップ・セット、制御ファイルの自動バックアップ、データファイルのコピーおよびアーカイブREDOログが含まれます。アーカイブREDOログ・ファイルが存在しないか破損している場合、Recovery Managerはバックアップに使用できるログの正常なコピーが、リカバリ領域の外にないかどうかを確認します。フラッシュバック・ログ、現行の制御ファイルおよびオンラインREDOログはバックアップされません。
CONFIGURE 注意: フラッシュ・リカバリ領域が現在有効でなくても、以前に有効にされていたことがある場合は、前回のフラッシュ・リカバリ領域の場所に作成されたファイルがバックアップされます。 |
|
|
|
|
|
ディスク上のすべてのリカバリ・ファイルを、フラッシュ・リカバリ領域に格納されているか、ディスク上の別の場所に格納されているかに関係なくバックアップします。バックアップは、SBTに作成する必要があります。 リカバリ・ファイルには、全体および増分のバックアップ・セット、制御ファイルの自動バックアップ、アーカイブREDOログおよびデータファイルのコピーが含まれます。
CONFIGURE |
|
|
サーバー・パラメータ・ファイルをバックアップ・セットに入れるように指定します。サーバー・パラメータ・ファイルのバックアップでは、
Recovery Managerは、ターゲット・データベースで使用中のサーバー・パラメータ・ファイルをバックアップします。サーバー・パラメータ・ファイルは、インスタンスが初期化パラメータ・ファイルによって起動された場合にはバックアップされません。 |
|
|
1つ以上の表領域の名前を指定します。Recovery Managerは、その内部で表領域名をデータファイルのリストに変換してから、表領域を現在構成しているデータファイルをすべてバックアップします。 ローカル管理の一時表領域のバックアップを作成することはできません（ディクショナリ管理表領域のバックアップは作成できます）。 次の条件が満たされる場合は、トランスポート後に読み書き両用に設定されなかったトランスポータブル表領域についてもバックアップを作成できます。 前述の条件のいずれかが満たされない場合、Recovery Managerは、読み書き両用に設定されていないトランスポータブル表領域を自動的にスキップします。条件のいずれかが満たされない場合にトランスポータブル表領域を明示的に指定すると、表領域が存在しないというエラーがRecovery Managerによって発行されます。 注意: ユーザーが表領域の名前を変更すると、その変更がRecovery Managerによって検出され、次回の再同期化時にリカバリ・カタログが更新されます。 |
|
backupSpecの後に続く |
この副次句は、backupSpec句に影響する様々なオプションとパラメータを指定します。また、多くの副次句はbackupOperandでも使用されます。ここでは、backupOperandでは通常共有されないオプションを示します。構文図は、「backupSpecOperand::=」を参照してください。
| 構文の要素 | 説明 |
|---|---|
|
|
バックアップが正常に実行された後で、入力ファイルを削除します。
このオプションを指定できるのは、アーカイブREDOログ、データファイルのコピー（
注意: フラッシュ・リカバリ内のアーカイブREDOログは、可能なかぎり長く保存され、追加のディスク領域が必要になると自動的に削除されます。 |
|
|
タグ名でファイルを指定します（例2-18を参照）。他のいくつかのコマンドとの関係で定義されます。 |
|
|
現行の制御ファイルのスナップショットを作成し、
注意: このオプションは、 |
この副次句は、BACKUPコマンドの出力形式（バックアップ・セットまたはイメージ・コピー）を指定します。構文図は、「backupTypeSpec::=」を参照してください。
| 構文の要素 | 説明 |
|---|---|
|
|
指定されたデバイス上にバックアップ・セットを作成します。これがデフォルトのバックアップ・タイプです。
テープにバックアップする場合およびレベル1の増分バックアップを任意のバックアップ先に作成する場合に使用できるのは、
暗号化されたバックアップを使用している場合は（「バックアップ・セットの暗号化」を参照）、異なる暗号化設定が使用されている表領域からのデータファイルは、同じバックアップ・セットに書き込むことができません。 ブロック・サイズの異なるファイルのバックアップを同じバックアップ・セット内に作成することはできません。Recovery Managerでは、ブロック・サイズの異なる表領域のバックアップを作成できますが、それぞれ異なるサイズのデータファイルが専用バックアップ・セットに入れられます。 Recovery Managerのバックアップ・セットでは、未使用ブロックの圧縮が自動的に使用されます。可能な場合に未使用のデータ・ブロックをスキップすると、Recovery Managerで、データファイルのバックアップにより少ない領域を使用し、より効率的にI/Oを行うことができます。データファイルをバックアップ・セットにバックアップする場合、割り当てられたことがないデータ・ブロックはその対象になりません。次のすべての条件に該当する場合は、現在データが含まれていないデータファイル・ブロックもスキップされます。
各バックアップ・セットには、1つ以上のバックアップ・ピースが含まれます。これは、バックアップ対象のデータを含むRecovery Manager固有の物理ファイルです。
Recovery Managerでは、完全バックアップ・セットのみがRecovery Managerリポジトリに記録されます。部分バックアップ・セットは記録されません。 注意: 1つのバックアップ・セットを複数のチャネルに分散することはできません。また、1つの入力ファイルを複数のバックアップ・セットに分散することもできません。 関連項目: Recovery ManagerでOracle Secure Backupを使用する方法については、『Oracle Secure Backup管理者ガイド』を参照してください。 |
|
|
Recovery Managerは、バックアップ・セットに書き込まれたデータを圧縮するため、バックアップ・セット全体のサイズは小さくなります。バックアップ・セットを作成するすべてのバックアップで、圧縮されたバックアップ・セットを作成できます。圧縮されたバックアップ・セットのリストア方法と圧縮されていないバックアップ・セットのリストア方法に違いはありません。
Recovery Managerは、データをバックアップ・セットに書き込む際にバイナリ圧縮アルゴリズムを適用します。この圧縮方法は、多くのメディア・マネージャ・ベンダーが提供している圧縮方法に類似しています。ローカル接続されたテープ・デバイスにバックアップする場合は、通常、メディア管理ベンダーが提供する圧縮のほうが バックアップ・セットを圧縮する場合、ある程度のCPUオーバーヘッドが発生します。ターゲット・データベースが最大またはそれに近い負荷で実行されていると、このオーバーヘッドが許容できないほど大きくなる場合があります。他のほぼすべての環境では、バックアップ・セットを圧縮すると、CPUのオーバーヘッドに値するだけのディスク領域が確保されます。 |
|
|
（バックアップ・セットではなく）イメージ・コピーを作成します。 イメージ・コピーは、元のファイルのバイト単位の同一コピーです。データファイル、データファイルのコピーおよびアーカイブREDOログ・ファイルのイメージ・コピー・バックアップを作成できます。イメージ・コピー・ファイルは、ディスクにのみ格納できます。増分更新バックアップを使用している場合、レベル0の増分はイメージ・コピー・バックアップである必要があります。
デフォルトでは、 Recovery Managerでは、次の規則に従ってコピーの作成場所を選択します（優先順位の高い順に示しています）。
イメージ・コピー・バックアップの作成およびリストアは、Recovery Managerを使用するか、またはファイルをコピーするためのオペレーティング・システム固有のコマンドを使用して実行できます。Recovery Managerを使用する場合は、コピーがRecovery Managerリポジトリに記録され、リストアおよびリカバリで簡単に使用できます。Recovery Managerを使用しない場合は、CATALOGコマンドでユーザー管理コピーをRecovery Managerリポジトリに追加して、Recovery Managerで使用できるようにする必要があります。
イメージ・コピーのイメージ・コピーは作成できますが、バックアップ・セットのコピーは作成できません。バックアップ・セットのバックアップを作成するには、 |
この副次句は、BACKUPコマンドの出力形式（バックアップ・セットまたはイメージ・コピー）を指定します。構文図は、「copyOfSpec::=」を参照してください。
| 構文の要素 | 説明 |
|---|---|
|
|
データベース内のすべてのデータファイルおよび制御ファイルの前回のイメージ・コピーのバックアップを作成します。 注意: このコマンドの出力は、イメージ・コピーまたはバックアップ・セットにできます。 |
|
|
1つ以上のデータファイルの前回のイメージ・コピーのバックアップを作成します。ファイル番号（
注意: バックアップ対象のイメージ・コピーが1回の 注意: このコマンドの出力は、イメージ・コピーまたはバックアップ・セットにできます。 関連項目: 「datafileSpec」を参照してください。 |
|
|
指定した1つ以上の表領域内のデータファイルの前回のイメージ・コピーのバックアップを作成します。
表領域名（ 注意: このコマンドの出力は、イメージ・コピーまたはバックアップ・セットにできます。 |
この副次句は、データファイルのコピーを指定します。構文図は、「datafileCopySpec::=」を参照してください。
| 構文の要素 | 説明 |
|---|---|
|
|
1つ以上のデータファイル・イメージ・コピーのファイル名を指定します。 |
|
|
データファイルのすべてのイメージ・コピーをバックアップするように指定します。 |
|
|
ファイル名のパターンを指定します。パーセント記号（ |
|
|
データファイルの1つ以上のコピーのリストをタグ名で指定します。このタグの付いたデータファイルのコピーが複数存在している場合、Recovery Managerは個々のデータファイルの最新のデータファイルのみをバックアップします。タグには、大/小文字区別はありません。 |
|
|
バックアップ操作で同一のデータファイルのコピーが組み込まれないようにします（例2-29を参照）。データファイルのコピーが重複している場合は、最新のタイムスタンプを持つファイルが選択されます。 |
この副次句は、データファイルのコピーを指定します。構文図は、「duration::=」を参照してください。
| 構文の要素 | 説明 |
|---|---|
|
|
バックアップ・コマンドの最長実行時間を指定します。指定した実行時間内にバックアップ・コマンドが完了しなかった場合、バックアップは停止します。
|
|
|
ディスク・バックアップでは、
|
|
|
|
この副次句は、バックアップを増分更新バックアップ計画で使用することを指定します。FOR RECOVER OFを指定する際に、INCREMENTAL LEVEL 1を指定する必要があります。構文図は、「forRecoveryOfSpec::=」を参照してください。
| 構文の要素 | 説明 |
|---|---|
|
|
ターゲット・データベースの指定したデータファイル・コピー（レベル0の増分バックアップ）のSCN以降に行われたすべての変更を増分バックアップに含めるように指定します（例2-20を参照）。
データファイルのコピーは、 関連項目: 増分更新バックアップの作成方法は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。 |
|
|
増分バックアップの基礎として使用されるレベル0の増分バックアップのタグを指定します。
|
|
|
出力イメージ・コピーに名前を付けるパターンを指定します。 |
|
|
たとえば、 |
この副次句は、まだバックアップされていないファイルのみをバックアップするように指定します。構文図は、「notBackedUpSpec::=」を参照してください。
| 構文の要素 | 説明 |
|---|---|
|
|
この副次句を使用すると、データベースに新規に追加したデータファイルを簡単にバックアップできます。Recovery Managerは、データファイル・チェックポイントを検査せずに、まだバックアップされていないデータファイルをすべてバックアップすることに注意してください。バックアップ・セットをバックアップするときに、
注意: この句は、バックアップの最適化（CONFIGURE |
|
|
注意: アーカイブREDOログ・ファイルをバックアップ・セットにバックアップしている場合のみ、 ファイルのバックアップ数を判断する場合は、現行のバックアップと同じデバイス・タイプで作成されたバックアップのみが考慮されます。 このオプションは、指定したメディアにアーカイブ・ログをバックアップする場合に便利です。たとえば、各ログの3つ以上のコピーをテープに保存できます。 |
|
|
その日付を過ぎるとRecovery Managerが、バックアップされていないファイルのバックアップを開始する日付を指定します。
このオプションを使用すると、前回失敗したバックアップ中に処理されなかったデータファイルをバックアップできます。たとえば、データベースをバックアップしても、インスタンスの途中で障害が発生する場合があります。その場合は、
ファイルがバックアップされたかどうかを判断するときには、 |
この副次句は、データのサイズを指定します。構文図は、「sizeSpec::=」を参照してください。
| 構文の要素 | 説明 |
|---|---|
|
|
データのサイズをGB単位（G）、KB単位（K）またはMB単位（M）で指定します。 |
この副次句は、スキップするファイルを指定します。構文図は、「skipSpec::=」を参照してください。
| 構文の要素 | 説明 |
|---|---|
|
|
次のキーワードで指定する基準に従って、データファイルまたはアーカイブREDOログをバックアップから除外します。 注意: backupSpec句でもこのオプションを指定できます。 |
|
|
I/Oエラーのために読み取ることができないデータファイルまたはアーカイブREDOログをバックアップに含めないように指定します。 データファイルは、読取りが不可能な場合にのみアクセス不能とみなされます。一部のオフライン・データファイルは、ディスク上に残っているために読取りが可能です。他のデータファイルは削除または移動されたためにアクセス不可となり、読取り不可となります。 |
|
|
オフライン・データファイルをバックアップに含めないように指定します。 |
|
|
読取り専用データファイルをバックアップに含めないように指定します。 |
この例では、オペレーティング・システム・コマンドラインからRecovery Managerクライアントを起動した後、オペレーティング・システム認証を使用してターゲット・データベースに接続します。BACKUPコマンドによって、すべてのデータファイル、現行の制御ファイル、サーバー・パラメータ・ファイルおよびアーカイブREDOログ・ファイル がデフォルトのストレージ・デバイスにバックアップされます。
% rman
RMAN> CONNECT TARGET /
RMAN> BACKUP DATABASE PLUS ARCHIVELOG;
例2-16 累積増分バックアップの実行
この例では、最後に実行されたレベル0の増分バックアップ以降にデータベース上で変更されたすべてのブロックをバックアップします。レベル1バックアップの実行時にレベル0バックアップが存在しない場合は、レベル0バックアップが自動的に作成されます。アクセスできないファイルは、スキップされます。
BACKUP
INCREMENTAL LEVEL 1 CUMULATIVE
SKIP INACCESSIBLE
DATABASE;
例2-17 複数ディスクへのバックアップの分散
この例では、2つの異なるディスクに表領域をバックアップし、Recovery Managerにバックアップのパラレル化を自動的に実行させます。FORMAT文字列の%Uは、出力するイメージ・コピーごとに一意のファイル名を生成する置換変数です。
RUN
{
ALLOCATE CHANNEL dev1 DEVICE TYPE DISK FORMAT '/disk1/%U';
ALLOCATE CHANNEL dev2 DEVICE TYPE DISK FORMAT '/disk2/%U';
BACKUP AS COPY
TABLESPACE SYSTEM, tools, users, undotbs;
}
例2-18 タグによるデータファイル・コピーの指定
この例では、データファイルのイメージ・コピーをテープにバックアップします。このBACKUPコマンドは、LATESTCOPYというタグが付いているすべてのデータファイル・コピーを検出してテープにバックアップし、そのバックアップに置換変数を使用した名前を付けます。変数%fは、絶対ファイル番号を指定します。また、%dは、データベースの名前を指定します。データファイルのコピーをテープ上に作成したら、LATESTCOPYというタグが付いているすべてのイメージ・コピーが削除されます。
BACKUP
DEVICE TYPE sbt
DATAFILECOPY
FROM TAG 'LATESTCOPY'
FORMAT 'Datafile%f_Database%d';
DELETE COPY TAG 'LATESTCOPY';
例2-19 アーカイブREDOログのバックアップと削除
この例では、2つのアーカイブ先（/disk2/PROD/archivelog/および/disk1/arch/）が設定されているとします。このコマンドは、一意の順序番号ごとにアーカイブREDOログを1つバックアップします。たとえば、アーカイブREDOログ1000が両方のディレクトリにある場合、Recovery Managerは、このログの1つのコピーのみをバックアップします。ALLキーワードが指定されたDELETE INPUT句によって、バックアップの終了後に、両方のアーカイブ・ディレクトリからすべてのアーカイブREDOログを削除するように指示しています。
BACKUP DEVICE TYPE sbt
ARCHIVELOG LIKE '/disk%arc%'
DELETE ALL INPUT;
このコマンドでは、次のような出力が表示されます。
Starting backup at 12-MAR-07
allocated channel: ORA_SBT_TAPE_1
channel ORA_SBT_TAPE_1: SID=150 device type=SBT_TAPE
channel ORA_SBT_TAPE_1: Oracle Secure Backup
channel ORA_SBT_TAPE_1: starting archived log backup set
channel ORA_SBT_TAPE_1: specifying archived log(s) in backup set
input archived log thread=1 sequence=4 RECID=4 STAMP=616789551
input archived log thread=1 sequence=5 RECID=5 STAMP=616789551
input archived log thread=1 sequence=6 RECID=6 STAMP=616789554
input archived log thread=1 sequence=7 RECID=7 STAMP=616789731
input archived log thread=1 sequence=8 RECID=8 STAMP=616789825
input archived log thread=1 sequence=9 RECID=10 STAMP=616789901
input archived log thread=1 sequence=10 RECID=12 STAMP=616789985
channel ORA_SBT_TAPE_1: starting piece 1 at 12-MAR-07
channel ORA_SBT_TAPE_1: finished piece 1 at 12-MAR-07
piece handle=0vice0g7_1_1 tag=TAG20070312T105917 comment=API Version 2.0,MMS Version 10.1.0.3
channel ORA_SBT_TAPE_1: backup set complete, elapsed time: 00:00:25
channel ORA_SBT_TAPE_1: deleting archived log(s)
archived log file name=/disk2/PROD/archivelog/2007_03_09/o1_mf_1_4_2z45sgrc_.arc RECID=4 STAMP=616789551
archived log file name=/disk2/PROD/archivelog/2007_03_09/o1_mf_1_5_2z45sgrc_.arc RECID=5 STAMP=616789551
archived log file name=/disk2/PROD/archivelog/2007_03_09/o1_mf_1_6_2z45sl3g_.arc RECID=6 STAMP=616789554
archived log file name=/disk2/PROD/archivelog/2007_03_09/o1_mf_1_7_2z45z2kt_.arc RECID=7 STAMP=616789731
archived log file name=/disk2/PROD/archivelog/2007_03_09/o1_mf_1_8_2z4620sk_.arc RECID=8 STAMP=616789825
archived log file name=/disk1/arch/archiver_1_8_616789153.arc RECID=9 STAMP=616789825
archived log file name=/disk2/PROD/archivelog/2007_03_09/o1_mf_1_9_2z464dhk_.arc RECID=10 STAMP=616789901
archived log file name=/disk1/arch/archiver_1_9_616789153.arc RECID=11 STAMP=616789901
archived log file name=/disk2/PROD/archivelog/2007_03_09/o1_mf_1_10_2z4670gr_.arc RECID=12 STAMP=616789985
archived log file name=/disk1/arch/archiver_1_10_616789153.arc RECID=13 STAMP=616789985
Finished backup at 12-MAR-07
Starting Control File and SPFILE Autobackup at 12-MAR-07
piece handle=c-28643857-20070312-02 comment=API Version 2.0,MMS Version 10.1.0.3
Finished Control File and SPFILE Autobackup at 12-MAR-07
例2-20 増分更新バックアップのスクリプト作成
バックアップを増分更新することによって、データベースのイメージ・コピーの全体バックアップに伴うオーバーヘッドを避けると同時に、データベースのメディア・リカバリに必要な時間を最小限にすることもできます。たとえば、日次バックアップ用のスクリプトを実行する場合に、メディア・リカバリに適用するREDOを1日分より多く持つことはありません。
次のスクリプトを毎日実行するとします。初回実行時には、スクリプトによって、指定したタグを使用してディスク上にデータベースのイメージ・コピーのバックアップが作成されます。2回目の実行では、データベースのレベル1のバックアップが作成されます。以降のすべての実行では、レベル1の増分がデータファイルのコピーに適用され、新しいレベル1のバックアップが作成されます。
RUN
{
RECOVER COPY OF DATABASE
WITH TAG 'incr_update';
BACKUP
INCREMENTAL LEVEL 1
FOR RECOVER OF COPY WITH TAG 'incr_update'
DATABASE;
}
例2-21 テープへのディスクベースのバックアップ・セットのバックアップ
最近のバックアップ・セットをディスク上に保持し、古いバックアップ・セットをテープ上に置くことを目標とします。また、同じバックアップ・セットのコピーを、ディスクとテープに同時に保持することは避けるものとします。この例では、2週間より前に作成されたバックアップ・セットはテープにバックアップされ、そのバックアップ・ピースがディスクから削除されます。
BACKUP
DEVICE TYPE sbt
BACKUPSET
COMPLETED BEFORE 'SYSDATE-14'
DELETE INPUT;
例2-22 データベース・バックアップの多重化
この例では、COPIES integerパラメータを使用して、圧縮されたデータベース・バックアップを2つ（別々のディスクに1つずつ）作成します。出力場所は、FORMATパラメータで指定します。
BACKUP AS COMPRESSED BACKUPSET
DEVICE TYPE DISK
COPIES 2
DATABASE
FORMAT '/disk1/db_%U', '/disk2/db_%U';
例2-23 チャネルでのワークロードの分割方法の指定
この例では、CHANNELパラメータで、どのチャネルでどのファイルをどこにバックアップするかを指定し、バックアップを明示的にパラレル化します。
RUN
{
ALLOCATE CHANNEL ch1 DEVICE TYPE sbt
PARMS 'ENV=(OB_DEVICE_1=stape1)';
ALLOCATE CHANNEL ch2 DEVICE TYPE sbt
PARMS 'ENV=(OB_DEVICE_1=stape2)';
BACKUP
(DATABASE # channel ch1 backs up database to tape drive stape1
CHANNEL ch1)
(ARCHIVELOG ALL
CHANNEL ch2); # channel ch2 backs up archived redo logs to tape drive stape2
}
例2-24 スタンバイ・データベースのリフレッシュ用の増分バックアップの作成
この例では、プライマリ・データベースの増分バックアップを作成し、それを使用して関連付けられたスタンバイ・データベースを更新することを目標とします。Recovery Managerクライアントを起動し、CONNECT TARGETとしてプライマリ・データベースに接続してから、リカバリ・カタログに接続します。BACKUPコマンドでは、スタンバイ・データベースで適用可能なプライマリ・データベースの増分バックアップを作成し、指定したSCN以降の変更を反映して更新します。
RMAN> CONNECT TARGET /
connected to target database: PROD (DBID=39525561)
RMAN> CONNECT CATALOG rman@catdb
recovery catalog database Password: password
connected to recovery catalog database
RMAN> BACKUP DEVICE TYPE DISK
2> INCREMENTAL FROM SCN 404128 DATABASE
3> FORMAT '/disk1/incr_standby_%U';
例2-25 データファイル・バックアップの破損許容度の指定
この例では、データベースに5つのデータファイルが含まれているとします。SET MAXCORRUPTコマンドを使用して、各データファイル内に1つの破損も許容されないことを指定します。BACKUPコマンドでCHECK LOGICALオプションが指定されているため、Recovery Managerは、物理的な破損と論理的な破損の両方をチェックします。
RUN
{
SET MAXCORRUPT FOR DATAFILE 1,2,3,4,5 TO 1;
BACKUP CHECK LOGICAL
DATABASE;
}
例2-26 アーカイブ目的での一貫性バックアップの作成
この例では、keepOptionを使用して、1年間は不要とみなされることがないアーカイブ・バックアップ・セットを作成します。この例では、データベースをバックアップし、REDOを現行のオンライン・ログにアーカイブしてこの新しいバックアップに一貫性があることを保証し、データファイル・バックアップを一貫性がある状態にリストアするために必要なアーカイブ・ログのみをバックアップします。
このBACKUPコマンドでは、リストア・ポイントも作成されます。そのリストア・ポイントは、このバックアップが一貫性を持つSCNに対応します。FORMATパラメータは、複数のバックアップ・セット内に複数のバックアップ・ピースを作成できるように指定する必要があります。
BACKUP DATABASE
FORMAT '/disk1/archival_backups/db_%U.bck'
TAG quarterly
KEEP UNTIL TIME 'SYSDATE + 365'
RESTORE POINT Q1FY06;
例2-27 保存方針からのコピーの除外
次の例では、2つのデータファイルをコピーして、保存方針から永久に除外します。（KEEP FOREVERにはリカバリ・カタログが必要です。）自動バックアップがオフの場合でも、制御ファイルおよびサーバー・パラメータ・ファイルもバックアップされます。
SHUTDOWN IMMEDIATE;
STARTUP MOUNT;
BACKUP
KEEP FOREVER
FORMAT '?/dbs/%U_longterm.cpy'
TAG LONGTERM_BCK
DATAFILE 1 DATAFILE 2;
ALTER DATABASE OPEN;
例2-28 バックアップが必要なファイルのバックアップ
データベースおよびアーカイブ・ログをテープに毎晩バックアップするために、次のコマンドを実行するとします。
BACKUP MAXSETSIZE 500M DATABASE PLUS ARCHIVELOG;
複数のバックアップ・セットが生成されるように、先行するコマンドで各バックアップ・セットのサイズの上限が設定されています。バックアップ処理の途中でメディア管理デバイスに障害が発生し、そのデバイスが再起動されるとします。翌日、バックアップ・セットの半分しか完了していないことに気付きます。その場合は、次のコマンドを夕方に実行できます。
BACKUP NOT BACKED UP SINCE TIME 'SYSDATE-1' MAXSETSIZE 500M DATABASE PLUS ARCHIVELOG;
先行するコマンドによって、過去24時間内にバックアップされていないファイルのみがバックアップされます。指定された時間枠のバックアップが使用可能であるとRecovery Managerが判断すると、次のような出力が表示されます。
skipping datafile 1; already backed up on 18-JAN-07 skipping datafile 2; already backed up on 18-JAN-07 skipping datafile 3; already backed up on 18-JAN-07
BACKUPコマンドのすぐ後にNOT BACKED UP SINCE句を置くと、バックアップするすべてのオブジェクトに影響します。また、その句は、個々のbackupSpec句の後に置くこともできます。その場合は、その句の制限を受けるbackupSpecによって指定されたオブジェクトのバックアップのみが作成されます。
この例では、/disk2/df2.cpyというデータファイル2のデータファイル・コピーを作成します。次に、そのデータファイル・コピーを/disk1および/disk3ディレクトリにバックアップします。最後のBACKUPコマンドで指定されているNODUPLICATESオプションは、データファイル2のコピーを1つのみバックアップする必要があることを示しています。
BACKUP AS COPY
DATAFILE 2
FORMAT '/disk2/df2.cpy' TAG my_tag;
BACKUP AS COPY
DATAFILECOPY '/disk2/df2.cpy'
FORMAT '/disk1/df2.cpy';
BACKUP AS COPY
DATAFILECOPY '/disk1/df2.cpy'
FORMAT '/disk3/df2.cpy';
BACKUP
DEVICE TYPE sbt
DATAFILECOPY ALL NODUPLICATES; # backs up only copy of datafile 2
CATALOGコマンドは、次の目的に使用します。
ターゲット・データベースに接続していて、そのデータベースがマウントまたはオープン状態である必要があります。Recovery Managerがリカバリ・カタログに接続されている場合は、カタログ・データベースをオープンする必要があります。
カタログ化するファイルは、次の条件を満たしている必要があります。
Recovery Managerでは、すべてのユーザー管理バックアップがイメージ・コピーとみなされます。カタログ化中は、ファイルがオペレーティング・システム・ユーティリティにより正常にコピーされたかどうかがRecovery Managerではチェックされず、ヘッダーがチェックされるのみであるため注意してください。
Data Guard環境でRecovery Managerを使用する場合は、リカバリ・カタログが必要です。リカバリ・カタログは、DBIDが同じ（ただし、DB_UNIQUE_NAME値は異なる）すべてのプライマリ・データベースおよびスタンバイ・データベースに対して、統一されたファイルの名前空間をサポートしています。したがって、リカバリ・カタログでは、すべてのプライマリ・データベースまたはスタンバイ・データベースのデータベース・ファイル名が、オンラインREDOログ、スタンバイREDOログ、一時ファイル、アーカイブREDOログ、バックアップ・セットおよびイメージ・コピーが作成された場所とともに追跡されます。
異なるプライマリ・データベースおよびスタンバイ・データベースで作成されたバックアップがRecovery Managerでどのように処理されるかについては、「Data Guard環境でのRecovery Managerのバックアップ」を参照してください。通常、1つのデータベースで作成されたテープ・バックアップはその環境のすべてのデータベースにアクセス可能ですが、ディスク・バックアップは作成元であるデータベースにのみアクセス可能です。
接続されているターゲット・データベースにバックアップからアクセス可能であれば、RESTOREやRECOVERなどのRecovery Managerコマンドは、異なるデータベース間で透過的に動作します。ディスク・バックアップを環境内のホスト間で手動で転送して、そのバックアップをカタログ化することができます。バックアップが共有ディスク上に作成されている場合は、CHANGE RESET DB_UNIQUE_NAMEを使用すると、バックアップを新しいデータベースに関連付けることができます。
| 構文の要素 | 説明 |
|---|---|
|
|
Recovery Managerリポジトリに追加するアーカイブREDOログのファイル名を指定します。 注意: このコマンドは、外部アーカイブREDOログをカタログ化しません。外部アーカイブREDOログは、LogMinerセッション中にロジカル・スタンバイ・データベースで受け取ったREDOログです。通常のアーカイブ・ログとは異なり、外部アーカイブ・ログには別のDBIDが使用されています。 |
|
|
Recovery Managerリポジトリに追加するバックアップ・ピースの名前を指定します（例2-30を参照）。 バックアップ・ピースがディスクに存在している必要があります。Recovery Managerは、バックアップ・ピースのヘッダーを検証した後でカタログ化します。Recovery Managerは、以前のデータベース・インカネーションからのバックアップ・ピースをカタログ化できます。 バックアップ・ピースは、次のような状況の場合にカタログ化します。
バックアップ・ピースのリストを指定すると、一部のバックアップ・ピースの処理で障害が発生した場合でも、Recovery Managerによって、すべてのピースのカタログ化が試行されます。バックアップ・ピースをカタログ化すると、
注意: データベースの |
|
|
Recovery Managerリポジトリに追加する制御ファイルのコピーのファイル名を指定します。指定できる制御ファイル・コピーは、次のいずれかのコマンドで作成される、通常の制御ファイルまたはスタンバイ制御ファイルのコピーです。
注意: プライマリ・データベースの制御ファイルのバックアップは、リストア操作時に自動的にスタンバイ制御ファイルに変換されます。 |
|
|
Recovery Managerリポジトリに追加するデータファイルのコピーのファイル名を指定します（例2-30を参照）。データファイルのコピーを作成するには、Recovery ManagerのBACKUP |
|
|
データファイル・コピーがレベル0の増分バックアップとして記録されるように指定します（ このデータファイルのコピーを基本レベル0のバックアップとして使用して、増分バックアップを実行できます。 |
|
|
データファイルのコピーのタグを指定します。 |
|
|
フラッシュ・リカバリ領域内のすべての有効なバックアップ・セット、データファイルのコピーおよびアーカイブREDOログをカタログ化します（例2-32を参照）。
Recovery Managerは、 注意: フラッシュ・リカバリ領域に外部アーカイブ・ログ（LogMinerセッション中にロジカル・スタンバイ・データベースで受け取る外部アーカイブREDOログ）が存在する場合、このコマンドではそれらの外部アーカイブ・ログもカタログ化されます。 |
|
|
キーワード |
|
|
名前が ディスクの場所にカタログ化できないファイルがある場合は、すべてレポートされます。Recovery Managerがターゲット・データベースに接続している必要があります。
文字列パターンによってファイル名を指定すると、その文字列パターンはファイル名パターンの左側に一致します。たとえば、 注意: 文字列パターンにワイルド・カード文字は使用できません。正確な接頭辞のみを使用してください。 |
|
|
確認のプロンプトを抑止します。デフォルトでは、一致するたびにプロンプトが表示されます。 |
Linuxユーティリティを使用して、users01.dbfデータファイルを/disk2/backup/users01.bakにバックアップするとします。この例では、データファイル・コピーがレベル0の増分バックアップとしてカタログ化されてから、すべてのコピーがリストされます。
CATALOG DATAFILECOPY '/disk2/backup/users01.bak' LEVEL 0;
LIST COPY;
例2-31 ディレクトリ内の複数のコピーのカタログ化
この例では、オペレーティング・システムのユーティリティを使用して/disk2/archlogディレクトリにコピーされたアーカイブREDOログで一杯のディレクトリをカタログ化します。この例では、出力例も示します。
CATALOG START WITH '/disk2/archlog' NOPROMPT;
searching for all files that match the pattern /disk2/archlog
List of Files Unknown to the Database
=====================================
File Name: /disk2/archlog/o1_mf_1_10_24trtc7s_.arc
File Name: /disk2/archlog/o1_mf_1_11_24trtg7s_.arc
File Name: /disk2/archlog/o1_mf_1_12_24trtk84_.arc
File Name: /disk2/archlog/o1_mf_1_13_24trtn85_.arc
File Name: /disk2/archlog/o1_mf_1_14_24trtq84_.arc
File Name: /disk2/archlog/o1_mf_1_15_24trtt84_.arc
File Name: /disk2/archlog/o1_mf_1_16_24trtx84_.arc
File Name: /disk2/archlog/o1_mf_1_17_24trv085_.arc
File Name: /disk2/archlog/o1_mf_1_18_24trv385_.arc
File Name: /disk2/archlog/o1_mf_1_19_24trv685_.arc
cataloging files...
cataloging done
List of Cataloged Files
=======================
File Name: /disk2/archlog/o1_mf_1_10_24trtc7s_.arc
File Name: /disk2/archlog/o1_mf_1_11_24trtg7s_.arc
File Name: /disk2/archlog/o1_mf_1_12_24trtk84_.arc
File Name: /disk2/archlog/o1_mf_1_13_24trtn85_.arc
File Name: /disk2/archlog/o1_mf_1_14_24trtq84_.arc
File Name: /disk2/archlog/o1_mf_1_15_24trtt84_.arc
File Name: /disk2/archlog/o1_mf_1_16_24trtx84_.arc
File Name: /disk2/archlog/o1_mf_1_17_24trv085_.arc
File Name: /disk2/archlog/o1_mf_1_18_24trv385_.arc
File Name: /disk2/archlog/o1_mf_1_19_24trv685_.arc
例2-32 フラッシュ・リカバリ領域内のファイルのカタログ化
この例では、現在有効になっているフラッシュ・リカバリ領域内のすべてのファイルを、ファイルごとにユーザーにプロンプトを表示せずにカタログ化します。出力例に示すとおり、カタログ化するファイルが見つからない場合はメッセージが表示されます。
CATALOG RECOVERY AREA;
searching for all files in the recovery area
no files found to be unknown to the database
例2-33 バックアップ・ピースのカタログ化
オペレーティング・システムのユーティリティを使用して、ある場所のバックアップ・ピースを別の場所にコピーするとします。この例では、新しい場所のバックアップ・ピースがカタログ化されます（例には出力例も含まれます）。
RMAN> CATALOG BACKUPPIECE '/disk1/c-874220581-20061128-01';
using target database control file instead of recovery catalog
cataloged backup piece
backup piece handle=/disk1/c-874220581-20061128-01 RECID=12 STAMP=607695990
CHANGEコマンドを使用すると、次のタスクを実行できます。
DB_UNIQUE_NAMEを更新します。
Recovery ManagerはTARGETとしてデータベース・インスタンスに接続され、そのインスタンスが起動されている必要があります。
バックアップの関連付けとアクセス可能性の違いについては、「Data Guard環境でのRecovery Managerのバックアップ」を参照してください。Data Guard環境では、バックアップまたはコピーを作成するデータベースはファイルに関連付けられます。Data Guard環境のどのデータベースに接続されていても、バックアップに接続可能であれば、CHANGE、DELETE、CROSSCHECKなどのメンテナンス・コマンドをバックアップに使用できます。通常、Recovery Managerでは、データベース上で作成されたテープ・バックアップはその環境のすべてのデータベースにアクセス可能であるとみなされますが、ディスク・バックアップは作成元のデータベースのみにアクセス可能であるとみなされます。
Recovery Managerは、バックアップと関連付けられたデータベースにTARGETとして接続されている場合のみ、バックアップのステータスをAVAILABLEからEXPIREDまたはDELETEDに更新できます。バックアップがターゲット・データベースに関連付けられていないためにRecovery Managerが削除を実行できない場合は、そのバックアップが関連付けられているデータベースで、同じCROSSCHECK操作をそのファイルに実行するように求めるプロンプトが表示されます。このように、Recovery Managerでは、不適切なSBT構成による意図しないステータス変更を防止しています。
たとえば、Recovery Managerをスタンバイ・データベースstandby1にTARGETとして接続し、そのデータベースをテープとディスクにバックアップするとします。テープ・ドライブが使用できなくなった場合は、Data Guard環境のプライマリ・データベースまたはスタンバイ・データベースにRecovery ManagerをTARGETとして接続して、テープ・バックアップのステータスをUNAVAILABLEに変更できます。テープ・ドライブが修復された後は、Recovery ManagerをTARGETとしてデータベースに接続して、テープ・バックアップのステータスをAVAILABLEに戻すことができます。ただし、オペレーティング・システムのユーティリティによって、ディスク・バックアップが誤って削除された場合、Recovery Managerはstandby1にTARGETとして接続されているときにのみ、ディスク・バックアップのステータスを変更できます。
（maintSpec::=、forDbUniqueNameOption::=、keepOption::=、deviceSpecifier::=）
（listObjList::=、archivelogRecordSpecifier::=、maintQualifier::=、recordSpec::=、deviceSpecifier::=）
この句を使用すると、Recovery Managerリポジトリのレコードのステータスを変更できます。ステータスを変更するRecovery Managerリポジトリ・レコードの主キーを取得するには、LISTコマンドを実行するか、リカバリ・カタログ・ビューを検索します。
| 構文の要素 | 説明 |
|---|---|
|
関連項目: この句のオプションについては、「maintSpec」を参照してください。 |
|
|
Data Guard環境において、指定した 関連項目: この句のオプションについては、「forDbUniqueNameOption」を参照してください。 |
|
|
|
リポジトリ内でバックアップまたはコピーのステータスを この機能は、使用不可のファイルが再度使用できるようになった場合に有効です。また、このオプションを使用して、以前のインカネーションのバックアップおよびコピーのリポジトリ・ステータスを変更することもできます。
これは、手動または自動のメンテナンス・チャネルを必要とする唯一の
Data Guard環境のファイルに対して 注意: バックアップのステータスは、LIST出力またはリカバリ・カタログ・ビューで確認できます。
注意: |
|
バックアップまたはコピーのステータスを、構成済の保存方針に基づいて変更します。たとえば、
関連項目: 「keepOption」を参照してください。 |
|
|
maintSpecのファイルをData Guard環境の別のデータベースに関連付けます。
関連項目: |
|
|
|
リポジトリ内でバックアップまたはコピーのステータスを
このオプションは、ファイルが見つからない場合や、別のサイトに移された場合に有効です。Recovery Managerでは、
フラッシュ・リカバリ領域のファイルでは、
注意: Data Guard環境のファイルに対して |
|
|
リカバリ・カタログからデータファイルのコピー、バックアップ・ピースまたはアーカイブREDOログの参照を削除し、ターゲット制御ファイル内のレコードをステータス
Data Guard環境のファイルに対して
注意: バックアップ制御ファイルから再同期化するか、またはリカバリ・カタログをアップグレードすると、 |
|
指定したデバイス・タイプにのみ |
|
|
データ・リカバリ・アドバイザによって記録された障害の変更内容を指定します。 |
|
|
|
リカバリ・カタログ内のメタデータを更新して、Data Guard環境でデータベースに新しい
Recovery Managerは、リカバリ・カタログおよびマウント済のターゲット・データベースに接続している必要があります。ターゲット・データベースでは、
通常、このコマンドを使用するのは、データベースの
スタンバイ・データベースの
古い名前のみが表示される場合は、
古い名前と新しい名前の両方が表示される場合は、
このように、 |
この句を使用すると、Data Guard環境の1つのデータベースで作成されたバックアップを、同じ環境の別のデータベースに関連付けることができます。次の表では、RESET DB_UNIQUE_NAMEで各種オプションを指定したときのRecovery Managerの動作について説明します。
| TO db_unique_name | FOR DB_UNIQUE_NAME | Recovery Managerの動作 |
|---|---|---|
|
実行しない |
実行しない |
Recovery Managerは、maintSpecファイルをターゲット・データベースに関連付けます。また、どのデータベースにも関連付けられていないすべてのバックアップの関連付けも変更します。
通常、Oracle Database 11g のリカバリ・カタログ・スキーマにアップグレードした後で、これらのオプションを指定して |
|
実行する |
実行しない |
Recovery Managerは、maintSpecファイルを |
|
実行しない |
実行する |
Recovery Managerは、その操作を |
|
実行する |
実行する |
Recovery Managerは、その操作を |
| 構文の要素 | 説明 |
|---|---|
|
|
maintSpecのファイルをターゲット・データベースと関連付けます（例2-38を参照）。各種オプションを指定したときのRecovery Managerの動作については、表2-2を参照してください。
データベース間でファイルの関連付けを変更すると、Recovery Managerは、リカバリ・カタログから重複した名前を削除します。たとえば、データファイル・コピー
このコマンドの実行結果は元に戻せないため、 |
|
|
maintSpecのファイルをData Guard環境の指定されたデータベースに関連付けます。 |
この句を使用すると、障害のステータスを変更できます。障害のリストを表示するには、LIST FAILUREコマンドを使用します。
ディスクに領域の問題があるため、バックアップ・セット4を一時的に別の場所に移動したとします。キー4を持つバックアップは、まだ使用可能としてリストされます。
RMAN> LIST BACKUP SUMMARY;
List of Backups
===============
Key TY LV S Device Type Completion Time #Pieces #Copies Compressed Tag
------- -- -- - ----------- --------------- ------- ------- ---------- ---
1 B A A DISK 24-FEB-07 1 1 NO TAG20070427T115348
3 B A A DISK 24-MAR-07 1 1 NO TAG20070427T115452
4 B F A DISK 24-APR-07 1 1 NO TAG20070427T115456
このバックアップは、ディスク領域が空いたときに元の場所に戻す予定なので、カタログから削除しません。したがって、次の手順でバックアップを使用不可能にします（例には出力例も含まれます）。
RMAN> CHANGE BACKUPSET 4 UNAVAILABLE;
changed backup piece unavailable
backup piece handle=/disk2/backup/c-3257893776-20070424-00 RECID=4 STAMP=588858897
Changed 1 objects to UNAVAILABLE status
例2-35 カタログ内のアーカイブREDOログの削除と追加
この例では、すべてのアーカイブREDOログを新しいディレクトリに移動し、カタログから削除した後で、新しい場所でカタログ化します。
HOST '/bin/mv $ORACLE_HOME/dbs/*.arc /disk2/archlog/';
CHANGE ARCHIVELOG ALL UNCATALOG;
CATALOG START WITH '/disk2/archlog' NOPROMPT;
例2-36 アーカイブ・バックアップへのデータベース・バックアップの変更
別のサイトに保存するために、データベース・バックアップをアーカイブ・バックアップに変更することを目標とします。このバックアップには一貫性があるため、リカバリは必要なく、アーカイブREDOログをバックアップとともに保存する必要もありません。この例では、CHANGE ... KEEP FOREVER を使用して、バックアップが不要とみなされることがないように指定します。
RMAN> CONNECT TARGET /
RMAN> CONNECT CATALOG rman@catdb
recovery catalog database Password: password
RMAN> CHANGE BACKUP TAG 'consistent_db_bkup' KEEP FOREVER;
例2-37 障害のステータスの変更
次の例では、LIST FAILUREコマンドによって、データファイルに破損ブロックがあることが示されます。障害の番号は5で、優先順位はHIGHです。この障害の優先順位をLOWに変更することにします。
RMAN> LIST FAILURE;
List of Database Failures
Failure ID Priority Status Time Detected Summary
---------- -------- --------- ------------- -------
5 HIGH OPEN 11-DEC-06 datafile 8 contains corrupt blocks
RMAN> CHANGE FAILURE 5 PRIORITY LOW;
List of Database Failures
Failure ID Priority Status Time Detected Summary
---------- -------- --------- ------------- -------
5 HIGH OPEN 11-DEC-06 datafile 8 contains corrupt blocks
Do you really want to change the above failures (enter YES or NO)? YES
changed 1 failures to LOW priority
例2-38 Data Guard環境での新しいデータベースへのバックアップの関連付け
プライマリ・データベースprodと関連付けられたスタンバイ・データベースが、standby1、standby2およびstandby3であるとします。この例では、Recovery Managerはターゲット・データベースprodおよびリカバリ・カタログに接続されているとします。
環境からstandby1を削除する予定のため、standby1バックアップをプライマリ・データベースに関連付ける必要があります。環境からstandby3も削除する予定のため、standby3バックアップをstandby2に関連付ける必要があります。次のコマンドを実行します。
CHANGE BACKUP FOR DB_UNIQUE_NAME standby1 RESET DB_UNIQUE_NAME;
CHANGE BACKUP FOR DB_UNIQUE_NAME standby3 RESET DB_UNIQUE_NAME TO standby2;
例2-39 リカバリ・カタログのDB_UNIQUE_NAMEの更新
スタンバイ・データベースのDB_UNIQUE_NAME初期化パラメータがdgrdbms4に設定されており、これをsfrdbms4に変更するとします。スタンバイ・インスタンスを停止し、DB_UNIQUE_NAME初期化パラメータをsfrdbms4に変更して、スタンバイ・インスタンスを再起動します。
その後、リカバリ・カタログを更新して、スタンバイ・データベースの変更された一意の名前を反映させるには、次のようにRecovery Managerをプライマリ・データベースとリカバリ・カタログに接続し、CHANGEコマンドを実行します。
CHANGE DB_UNIQUE_NAME FROM dgrdbms4 TO sfrdbms4;
CONFIGUREコマンドを使用すると、特定のデータベースに対するRecovery Managerのバックアップ、リストア、複製およびメンテナンス・ジョブに影響する永続構成を作成または変更できます。構成は、明示的に消去または変更するまで、そのデータベースに対するすべてのRecovery Managerセッションに有効です。SHOWコマンドを使用すると、1つ以上のデータベースの構成を表示できます。
このコマンドは、Recovery Managerプロンプトでのみ実行してください。
FOR DB_UNIQUE_NAME句を指定しない場合は、Recovery Managerをターゲット・データベースに接続する必要があります。ターゲット・データベースはマウントまたはオープン状態である必要があります。
CONFIGUREコマンドは、ターゲット・データベース構成を、常にターゲット・データベースの制御ファイル内に格納します。Recovery Managerをリカバリ・カタログとともに使用すると、登録されているデータベースごとに永続的な構成設定がカタログ内にも保存されます。
Recovery ManagerのCONFIGURE設定には、デフォルト値があります。CLEARオプションを指定してCONFIGUREコマンドを再実行すると、このコマンドのあらゆる設定をデフォルトに戻すことができますが、この方法で個々のパラメータをクリアすることはできません。たとえば、CONFIGURE CHANNEL DEVICE TYPE sbt CLEARは実行できますが、CONFIGURE CHANNEL DEVICE TYPE sbt MAXPIECESIZE 5M CLEARは実行できません。
Data Guard環境でRecovery Managerを使用する場合は、常にリカバリ・カタログを使用することをお薦めします。CONFIGUREコマンドを使用すると、Data Guard環境の個々のプライマリまたはスタンバイ・データベースに対する永続的なRecovery Manager構成（バックアップの保存方針、表領域の除外および補助名の設定は除く）を作成できます。このように、プライマリ・データベースおよびスタンバイ・データベースに、様々なチャネル構成、自動バックアップの場所などを設定できます。
FOR DB_UNIQUE_NAME句を使用すると、Recovery ManagerがTARGETとして接続されていないデータベースを構成できます。CONFIGURE DB_UNIQUE_NAMEを使用すると、新しいフィジカル・スタンバイ・データベースをリカバリ・カタログに認識させて、暗黙的に登録できます。
（datafileSpec::=、backupConf::=、cfauConf::=、deviceConf::=、forDbUniqueNameOption::=）
（deviceSpecifier::=、sizeSpec::=）
（deviceSpecifier::=、formatSpec::=）
（deviceSpecifier::=、allocOperandList::=）
| 構文の要素 | 説明 |
|---|---|
|
|
また、Recovery Managerは
RESYNC CATALOG
注意: ターゲット・データベースが他のスタンバイ・データベースまたはプライマリ・データベースに接続する必要がある場合は、既存のData Guard認証メカニズムを使用して、
例として、最近、Recovery Managerを
注意: |
|
アーカイブREDOログの削除方針を構成します。 |
|
|
|
指定したターゲット・データファイルの補助ファイル名を
TSPITRを実行しているか、DUPLICATEを使用している場合は、
たとえば、TSPITR中に、データファイルがロー・ディスクにあってパフォーマンスの理由で補助データファイルをロー・ディスクにリストアする必要がある場合は、このコマンドを使用します。一般に、TSPITRで
関連項目: Recovery ManagerのTSPITRを実行する方法、およびRecovery Managerを使用してデータベースを複製する方法は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。 |
|
デフォルトのバックアップ・オプション（多重化、最適化、表領域の除外、バックアップ・セットのサイズ、保存方針など）を構成します。 |
|
|
制御ファイルの自動バックアップ設定を構成します。 |
|
|
|
圧縮されたバックアップ・セットの作成時に、Recovery Managerが使用するアルゴリズムを指定します。デフォルトの圧縮アルゴリズムは、
サポートされているアルゴリズムは、
注意: サポートされているアルゴリズムは、 |
|
デバイスのデフォルトのバックアップ設定（デフォルトのバックアップ・デバイス、デバイスのチャネル構成、各デバイスのデフォルトのバックアップ・タイプ、並列度など）を構成します。 |
|
|
|
データベースまたは表領域に透過モードの暗号化設定を指定します。
この構成は、SET 関連項目: 様々なモードのバックアップの暗号化については「バックアップ・セットの暗号化」を、透過的データ暗号化については『Oracle Database Advanced Security管理者ガイド』を参照してください。 |
|
|
バックアップ・セットの書込み時に使用するデフォルトの暗号化アルゴリズムを指定します。 |
|
|
データベース全体に対して透過的暗号化を有効にするかどうかを指定します。オプションは次のとおりです。
注意: パスワードの暗号化を有効にするには、SET |
|
|
1つ以上の表領域に対して透過的暗号化を有効にするかどうかを指定します。表領域に対して構成された設定は、常に、データベース・レベルで設定された構成によってオーバーライドされます。オプションは次のとおりです。
注意: パスワードの暗号化を有効にするには、 |
|
|
スナップショット制御ファイルの名前と場所を
スナップショット制御ファイル名のデフォルト値はプラットフォーム固有であり、Oracleホームに依存します。たとえば、一部のUNIXシステムでは、デフォルトは スナップショット制御ファイルの名前は、そのデータベースにのみ有効なことに注意してください。プライマリ・データベースで、スナップショット制御ファイル名をデフォルト値以外に設定したとします。DUPLICATEを使用してスタンバイ・データベースを作成すると、スタンバイ・データベース上のスナップショット制御ファイルの場所は、デフォルト値に設定されます。必要であれば、スタンバイ・データベース上のスナップショットの場所をデフォルト値以外に設定できます。 関連項目: スナップショット制御ファイルの詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。 |
|
Data Guard環境の
Data Guard環境で操作を実行する場合は、リカバリ・カタログが必要です。Recovery Managerは、マウント済またはオープン状態のデータベース（プライマリとスタンバイのいずれでも可）に
注意: このデータベースに |
この副次句は、アーカイブREDOログの削除方針の永続構成を管理します。
| 構文の要素 | 説明 |
|---|---|
|
|
アーカイブ・ログの削除方針は、ログのすべてのアーカイブ先（フラッシュ・リカバリ領域も含む）に適用されます。この方針は、バックアップ・セット内のアーカイブ・ログには適用されません。
フラッシュ・リカバリ領域内のアーカイブREDOログのみが自動的に削除されます。BACKUP リカバリ領域では、削除可能なログは可能なかぎり長く保持されます。ディスク領域が必要になると、まず最も古いログから削除されます。リカバリ領域のディスク容量が厳しくなると、Oracle Streamsで必要なアーカイブREDOログが削除される場合があります。 注意: この削除方針は、外部アーカイブREDOログには適用されません。外部アーカイブREDOログは、LogMinerセッション中にロジカル・スタンバイ・データベースで受け取ったログです。これらのログは、プライマリ・データベースから転送されていますが、通常のアーカイブ・ログとは異なり、別のDBIDが使用されています。外部アーカイブREDOログは、ロジカル・スタンバイ・データベースでバックアップおよびリストアすることはできません。 |
|
|
次の条件が両方とも満たされている場合に、アーカイブREDOログが削除可能であることを指定します。
どのリモートの宛先が考慮されるかは、次の条件によって異なります。
注意: 関連項目: 詳細は、『Oracle Data Guard概要および管理』を参照してください。 |
|
|
次の条件が両方とも満たされている場合に、アーカイブREDOログが削除可能であることを指定します。
この句を指定して削除方針を構成すると、指定したデバイス・タイプに 関連項目: 「deviceSpecifier」を参照してください。 |
|
|
アーカイブ・ログの削除方針を無効にします。これは、デフォルトの設定です。 アーカイブREDOログは、フラッシュ・リカバリ領域の内側または外側に配置できます。ログは、それがどこに配置されていても、手動コマンドで削除できます。フラッシュ・リカバリ領域内のログのみがデータベースで自動的に削除できます。
削除方針が
たとえば、アーカイブ・ログが、必須であるリモートの宛先に転送済であるとします。このログは、リカバリ期間の保存方針によると不要ですが、まだバックアップされていません。その場合、ログは削除可能です。または、ログが不要になり、SBTにバックアップ済であるとします。ただし、必須であるリモートの宛先には転送されていません。その場合は、ログは削除可能ではありません。
削除方針が |
|
|
次の条件が両方とも満たされている場合に、アーカイブREDOログが削除可能であることを指定します。
どのリモートの宛先が考慮されるかは、次の条件によって異なります。
注意: 関連項目: 詳細は、『Oracle Data Guard概要および管理』を参照してください。 |
この副次句は、BACKUPコマンドに関する永続構成を管理します。構成の1つに、バックアップの最適化があります。バックアップの最適化を有効にした場合、ファイルがデバイス・タイプにバックアップ済であれば、それと同じファイルが同じデバイス・タイプにバックアップされることはありません。
バックアップの最適化を行う場合に、ファイルが同じかどうかおよびファイルがスキップされる可能性があるかどうかを判断する基準を表2-3に示します。また、この表では、バックアップの最適化が有効で、同一ファイルのバックアップをスキップするかどうかを決定する必要がある場合に、Recovery Mangaerによって使用されるアルゴリズムも説明します。Recovery Managerによってバックアップがスキップされない場合は、指定されたそのとおりにバックアップが作成されます。
| 構文の要素 | 説明 |
|---|---|
|
|
指定したデバイス・タイプ上での、
Recovery Managerは、バックアップをディスクまたはテープのいずれかに多重化できますが、テープとディスクに同時に多重化することはできません。テープにバックアップを行う場合は、コピー数が使用可能なテープ・デバイスの数を超えないようにします。また、 制御ファイルの自動バックアップが多重化されることはありません。また、フラッシュ・リカバリ領域では多重化が許可されません。
BACKUPコマンドまたはSET |
|
|
バックアップの最適化を バックアップの最適化が使用可能になるのは、次の条件がすべて満たされている場合です。
最適化によって、ファイルがデバイス・タイプにバックアップ済である場合は、同じファイルが同じデバイス・タイプにバックアップされないようになります。Recovery Managerでは、バックアップ中に、バックアップの最適化によってすべてのファイルがスキップされてもエラーは発行されません。バックアップ保存方針は、バックアップの最適化でどのファイルがスキップされるかに影響することに注意してください。 2つのファイルが同一の場合、その内容が正確に同一である必要があります。ファイルが同一とみなされる条件の詳細は、表2-3を参照してください。バックアップ・ピースをディスク上またはOracle Secure Backupで管理されているメディア上に作成する場合、UNDOデータがアクティブなトランザクションに属していなければ、最適化によって、そのデータはバックアップから除外されます。
注意:
注意: 関連項目: Recovery Managerによってファイルのバックアップをスキップできるかどうかを判断する方法は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。 |
|
|
指定した表領域をBACKUP
デフォルトでは、各表領域は除外されません。つまり、除外機能は無効化されています。除外は個々のデータファイルではなく表領域の属性として格納されるため、将来この表領域に追加されるすべてのファイルに適用されます。表領域を除外した後、その表領域に対して
その場合も、 |
|
|
チャネル上で作成される各バックアップ・セットの最大サイズを指定します。
注意: このオプションは、BACKUP |
|
|
各バックアップ・セットの最大サイズを、 |
|
|
バックアップ・セットのサイズを制限しません。 |
|
|
Recovery Managerで不要マークが付けられた、つまり不要となり削除可能になっているバックアップ・セットおよびコピーについて、現行の永続的な方針を指定します。
時間が経過すると、保存方針で指定された条件に従ってバックアップ・セットとコピーに不要マークが付けられます。リカバリ領域内の不要なバックアップ・セットおよびコピーは、領域が必要になるとRecovery Managerによって自動的に削除されます。リカバリ領域外にある不要なファイルが自動的に削除されることはありません。削除するには、DELETE
バックアップの場合、保存方針の基本単位はバックアップ・セット（バックアップ・ピースではない）またはイメージ・コピーです。たとえば、
注意: |
|
|
保存方針機能を使用禁止にします。Recovery Managerでは、バックアップ・セットおよびコピーは不要とみなされません。 |
|
|
Recovery Managerでデータベースをリカバリ可能な時間枠を指定します。
時間枠は、現在の時刻（
注意: |
|
|
データファイルおよび制御ファイルごとに、
注意: |
この副次句は、制御ファイルの自動バックアップに関する永続構成を作成します。
| 構文の要素 | 説明 |
|---|---|
|
|
注意: リカバリ・カタログを使用せずにRecovery Managerを使用する場合は、制御ファイルの自動バックアップ機能を有効にすることをお薦めします。 |
|
|
次のような状況で、制御ファイルの自動バックアップを実行するように指定します。
リカバリ・カタログを使用せずにRecovery Managerを使用する場合は、制御ファイルの自動バックアップを行うことをお薦めします。 バックアップ・ジョブまたはコピー・ジョブで割り当てた最初のチャネルによって自動バックアップが作成され、独自のバックアップ・セットに格納され、構造の自動バックアップ後にデフォルトのディスク・チャネルによってバックアップが作成されます。Recovery Managerは、制御ファイルとサーバー・パラメータ・ファイルを同じバックアップ・ピースに書き込みます。制御ファイルの自動バックアップが完了すると、データベースによってバックアップ・ピースへのフルパスとデバイス・タイプを含むメッセージがアラート・ログに書き込まれます。
ディスク上の自動バックアップのデフォルトの場所は、フラッシュ・リカバリ領域（構成されている場合）またはプラットフォーム固有の場所（構成されていない場合）です。現行の制御ファイルは、デフォルトのフォーマット%Fを使用して自動的にバックアップされます。
制御ファイルの自動バックアップを多重化する（つまり、自動バックアップを複数の場所に書き込む）ようにRecovery Managerを構成することはできません。制御ファイルのバックアップを複数作成するには、バックアップ・ジョブの最後のコマンドを
注意:
自動バックアップ形式は、 |
|
|
このコマンドが |
|
|
この構成をデフォルト設定の |
|
|
指定したデバイス・タイプへの制御ファイルの自動バックアップについて、デフォルトの場所とファイル名の形式を構成します（例2-45を参照）。
デフォルトのフォーマットは、どのデバイスの場合も%Fです。
フラッシュ・リカバリ領域が有効で、フォーマットがデフォルトの
formatSpecで、自動ストレージ管理ディスク・グループを指定できます。次の例では、ASMディスク・グループのチャネルを構成します。 CONFIGURE CONTROLFILE AUTOBACKUP FOR DEVICE TYPE DISK TO '+dgroup1';
関連項目: |
この副次句は、チャネルおよびデバイスに関する永続構成を作成します。
Recovery Managerは構成済チャネルの名前を決定することに注意してください。Recovery Managerで使用される規則は、ORA_devicetype_nです。devicetypeはDISKまたはsbt_tapeなどのユーザー・デバイスのタイプ、nはチャネル番号です。接頭辞ORA_で始まるチャネル名は、Recovery Manager専用に予約されています。名前がORA_で始まるチャネルを手動で割り当てることはできません。
Recovery Managerでは、最初のDISKチャネルにORA_DISK_1、2番目のチャネルにORA_DISK_2という名前が付けられ、以降も同様に名前が付けられます。sbtチャネルの場合は、最初のチャネルにORA_SBT_TAPE_1、2番目のチャネルにORA_SBT_TAPE_2という名前が付けられ、以降も同様に名前が付けられます。チャネルをパラレル化すると、Recovery Mangaerによってチャネルは常に番号順に割り当てられます。番号は、1から始まり、パラレル化の設定値（CONFIGURE DEVICE TYPE ...PARALLELISM n）で終わります。
特定の構成済チャネルでBACKUPまたはRESTOREジョブを実行するには、システムで生成されたチャネル名を使用します。CONFIGURE CHANNELコマンド（deviceConf句を参照）でチャネル番号を指定すると、システム生成のチャネル名に同じ番号が使用されます。
チャネルの自動割当ては、メンテナンス・コマンドにも適用されます。Recovery Managerで自動メンテナンス・チャネルを割り当てる場合、他の自動割当てチャネルと同じネーミング規則が使用されます。
すべてのOracle RACインスタンスのSYSDBAパスワードが同じであるかぎり、 ALLOCATE CHANNELまたはCONFIGUREコマンドのCONNECTオプションでパスワードを指定する必要はありません。user@database形式の接続文字列を使用すると、Recovery Managerセッションの開始時にTARGET接続で使用されたものと同じパスワードが自動的に使用されます（例2-43を参照）。
| 構文の要素 | 説明 |
|---|---|
|
|
構成または消去する標準または
注意:
汎用チャネルを構成するか、チャネルを番号で指定できます。この場合、
チャネル・オプションは、1つ以上指定する必要があります。たとえば、 指定したデバイス・タイプの汎用チャネルについて、新規コマンドにより、そのデバイス・タイプの以前の設定が消去されます。次のコマンドを実行するとします。 CONFIGURE CHANNEL DEVICE TYPE sbt MAXPIECESIZE 1G;
2番目のコマンドでは、最初のコマンドの 注意: Recovery Managerでは、BACKUPコマンドで同時に複数のデバイス・タイプに対して自動チャネルが割り当てられることはありません。 関連項目: チャネル番号で指定した自動チャネルを構成する方法は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』 を参照してください。 |
|
デフォルト以外の
CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT '+dgroup1'; 関連項目: 「allocOperandList」を参照してください。 |
|
|
|
指定したチャネルを消去します。たとえば、 |
|
|
自動チャネルのデフォルトのデバイス・タイプを指定します。デフォルトのデバイス・タイプは
デフォルトでは、BACKUPコマンドで割り当てることができるのは、デフォルトのデバイス・タイプのチャネルのみです。たとえば、自動チャネルを
RESTOREコマンドでは、デフォルトのデバイス・タイプに関係なく、すべての構成済デバイス・タイプの自動チャネルが割り当てられます。 |
|
|
この
CONFIGURE DEVICE TYPE sbt PARALLELISM 1; 実際には、Recovery Managerでは、このバックアップを次のように実行します。 RUN |
|
|
ディスク・バックアップまたはテープ・バックアップのデフォルトのバックアップ・タイプを構成します。SBTデバイスの場合、
ディスク・バックアップのデフォルトの場所は、フラッシュ・リカバリ領域が構成されている場合はフラッシュ・リカバリ領域です。構成されていない場合は、Recovery Managerによってプラットフォーム固有の場所にバックアップが格納されます。バックアップ・ファイル名のデフォルトの形式は%Uです。 |
|
|
Recovery Managerのジョブに割り当てられるデバイス・タイプに指定された自動チャネルの数を構成します。デフォルトでは、
注意:
ディスク・バックアップの
注意: 手動で番号を取得した
デバイス・タイプの並列度を CONFIGURE DEVICE TYPE sbt PARALLELISM 3; |
この例では、デバイス・タイプDISKおよびsbtのチャネルを構成し、デフォルトのデバイス・タイプをsbtに設定します。また、バックアップの最適化を有効にし、リカバリ期間を2週間に構成します。
CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT '/disk1/backups/%U';
CONFIGURE CHANNEL DEVICE TYPE sbt PARMS 'ENV=(OB_DEVICE_1=tape1)';
CONFIGURE DEFAULT DEVICE TYPE TO sbt;
CONFIGURE BACKUP OPTIMIZATION ON;
CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 14 DAYS;
例2-41 デフォルト・デバイス・タイプのオーバーライド
この例では、データファイルと制御ファイルのDISKバックアップについて多重化を2に構成します（ただし、ディスクへの制御ファイルの自動バックアップは特例で、多重化されません）。次に、sbtをデフォルト・デバイスに構成します。
CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 2;
CONFIGURE CHANNEL DEVICE TYPE sbt PARMS 'ENV=(OB_DEVICE_1=tape1)';
CONFIGURE DEFAULT DEVICE TYPE TO sbt;
最初のBACKUPコマンドは、アーカイブREDOログをデフォルトのsbtチャネルにバックアップします。2番目のBACKUPコマンドは、データベースをディスクの場所にバックアップします。ディスク・バックアップの多重化が有効であるため、各出力バックアップ・セットのコピーが2つ作成されます。
BACKUP ARCHIVELOG ALL;
BACKUP DEVICE TYPE DISK
DATABASE
FORMAT '/disk1/db_backup_%U','/disk2/db_backup_%U';
例2-42 ファイル・システムにまたがる自動チャネルの構成
この例では、2つのファイル・システムにまたがる自動ディスク・チャネルを構成します。
CONFIGURE DEVICE TYPE DISK PARALLELISM 2;
CONFIGURE CHANNEL 1 DEVICE TYPE DISK FORMAT '/disk1/%U';
CONFIGURE CHANNEL 2 DEVICE TYPE DISK FORMAT '/disk2/%U';
PARALLELISMが2に設定されているため、次のコマンドは出力データを2つのファイル・システム間で分割します。
BACKUP DEVICE TYPE DISK
DATABASE PLUS ARCHIVELOG;
次のLISTコマンドは、データファイルのバックアップがどのようにパラレル化されたかを示します。
RMAN> LIST BACKUPSET 2031, 2032;
List of Backup Sets
===================
BS Key Type LV Size Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ ---------------
2031 Full 401.99M DISK 00:00:57 19-JAN-07
BP Key: 2038 Status: AVAILABLE Compressed: NO Tag: TAG20070119T100532
Piece Name: /disk1/24i7ssnc_1_1
List of Datafiles in backup set 2031
File LV Type Ckp SCN Ckp Time Name
---- -- ---- ---------- --------- ----
1 Full 973497 19-JAN-07 /disk3/oracle/dbs/t_db1.f
5 Full 973497 19-JAN-07 /disk3/oracle/dbs/tbs_112.f
BS Key Type LV Size Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ ---------------
2032 Full 133.29M DISK 00:00:57 19-JAN-07
BP Key: 2039 Status: AVAILABLE Compressed: NO Tag: TAG20070119T100532
Piece Name: /disk2/25i7ssnc_1_1
List of Datafiles in backup set 2032
File LV Type Ckp SCN Ckp Time Name
---- -- ---- ---------- --------- ----
2 Full 973501 19-JAN-07 /disk3/oracle/dbs/t_ax1.f
3 Full 973501 19-JAN-07 /disk3/oracle/dbs/t_undo1.f
4 Full 973501 19-JAN-07 /disk3/oracle/dbs/tbs_111.f
例2-43 Oracle Real Application Clusters（Oracle RAC）構成での自動チャネルの構成
この例では、Oracle RACデータベースに2つのノードがあるとします。メディア・マネージャはOracle Secure Backupです。テープ・ドライブtape1はnode1に直接接続され、テープ・ドライブtape2はnode2に直接接続されています。この例では、各クラスタ・ノードに SBT自動チャネルを構成します。
この例では、Oracle RACインスタンスnode1およびnode2へのチャネル接続を示します。両方のチャネル接続で、Recovery Managerは、ターゲット・データベース接続で入力したユーザー名とパスワードと同じものを使用します。
CONFIGURE DEVICE TYPE sbt PARALLELISM 2;
CONFIGURE DEFAULT DEVICE TYPE TO sbt;
CONFIGURE CHANNEL 1 DEVICE TYPE sbt CONNECT '@node1'
PARMS 'ENV=(OB_DEVICE=tape1)';
CONFIGURE CHANNEL 2 DEVICE TYPE sbt CONNECT '@node2'
PARMS 'ENV=(OB_DEVICE=tape2)';
例2-44 補助ファイル名の構成
この例では、CONFIGURE AUXNAMEを使用して、データファイルの新しいファイル名を指定します。DUPLICATEコマンドによって、ディレクトリ構造が異なるリモート・ホストにデータベースが多重化されます。
# set auxiliary names for the datafiles
CONFIGURE AUXNAME FOR DATAFILE 1 TO '/oracle/auxfiles/aux_1.f';
CONFIGURE AUXNAME FOR DATAFILE 2 TO '/oracle/auxfiles/aux_2.f';
CONFIGURE AUXNAME FOR DATAFILE 3 TO '/oracle/auxfiles/aux_3.f';
CONFIGURE AUXNAME FOR DATAFILE 4 TO '/oracle/auxfiles/aux_4.f';
RUN
{
ALLOCATE AUXILIARY CHANNEL dupdb1 TYPE DISK;
DUPLICATE TARGET DATABASE TO dupdb
LOGFILE
GROUP 1 ('?/dbs/dupdb_log_1_1.f',
'?/dbs/dupdb_log_1_2.f') SIZE 4M,
GROUP 2 ('?/dbs/dupdb_log_2_1.f',
'?/dbs/dupdb_log_2_2.f') SIZE 4M REUSE;
}
# Un-specify the auxiliary names for the datafiles so that they are not overwritten
# by mistake:
CONFIGURE AUXNAME FOR DATAFILE 1 CLEAR;
CONFIGURE AUXNAME FOR DATAFILE 2 CLEAR;
CONFIGURE AUXNAME FOR DATAFILE 3 CLEAR;
CONFIGURE AUXNAME FOR DATAFILE 4 CLEAR;
例2-45 制御ファイルの自動バックアップに使用するデフォルトの形式の指定
次の例では、自動バックアップ機能を有効にし、DISKおよびsbtデバイスに対してデフォルトの自動バックアップ形式を構成します。
CONFIGURE CONTROLFILE AUTOBACKUP ON;
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '/disk2/%F';
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE sbt TO 'cf_auto_%F';
例2-46 スタンバイ・データベースの構成の作成
プライマリ・データベースprodが、dgprod3およびdgprod4というDB_UNIQUE_NAME名の2つのスタンバイ・データベースに関連付けられているとします。Recovery Managerを起動し、TARGETとしてprodに接続して、リカバリ・カタログに接続するとします。次のコマンドでは、データベースdgprod3およびdgprod4のデフォルトのデバイス・タイプを構成します。
CONFIGURE DEFAULT DEVICE TYPE TO sbt
FOR DB_UNIQUE_NAME dgprod3;
CONFIGURE DEVICE TYPE sbt PARALLELISM 2
FOR DB_UNIQUE_NAME dgprod3;
CONFIGURE DEFAULT DEVICE TYPE TO DISK
FOR DB_UNIQUE_NAME dgprod4;
この構成で2つのスタンバイ・データベースの制御ファイルが更新されるのは、リカバリ・カタログから制御ファイルへの逆方向の再同期が行われた後のみです。この再同期は、ユーザーがdgprod3およびdgprod4に初めて接続するときに行われます。
次のSHOWコマンドは、dgprod3という一意の名前を持つデータベースのデバイス・タイプの永続構成を表示します。
RMAN> SHOW DEVICE TYPE FOR DB_UNIQUE_NAME dgprod3;
RMAN configuration parameters for database with db_unique_name DGPROD3 are:
CONFIGURE DEVICE TYPE 'SBT_TAPE' PARALLELISM 2 BACKUP TYPE TO BACKUPSET;
CONFIGURE DEVICE TYPE DISK PARALLELISM 1 BACKUP TYPE TO BACKUPSET; # default
次のSHOWコマンドは、リカバリ・カタログが認識しているデータベースで、DBIDが3257174182のすべてのデータベースの永続構成を表示します（DBIDの値は、先行するSET DBIDコマンドで指定されます）。
SHOW ALL FOR DB_UNIQUE_NAME ALL;
例2-47 バックアップの最適化
次の例では、表2-3で示したバックアップの最適化について説明します。バックアップの最適化が無効になっているとします。午前9時に、既存のすべてのアーカイブ・ログの3つのコピーをテープにバックアップします。バックアップをテープに多重化する場合は、BACKUP_TAPE_IO_SLAVES初期化パラメータをtrueにする必要があることに注意してください。
BACKUP DEVICE TYPE sbt COPIES 3 ARCHIVELOG ALL;
午前11時に、バックアップの最適化を有効にします。
CONFIGURE BACKUP OPTIMIZATION ON;
正午に、次のアーカイブREDOログのバックアップを実行します。
BACKUP DEVICE TYPE sbt COPIES 2 ARCHIVELOG ALL;
Starting backup at 19-JAN-07
current log archived
using channel ORA_SBT_TAPE_1
skipping archived log file /d1/db1r_605ab325_1_34_612112605.arc; already backed up 3 time(s)
skipping archived log file /d1/db1r_605ab325_1_35_612112605.arc; already backed up 3 time(s)
skipping archived log file /d1/db1r_605ab325_1_36_612112605.arc; already backed up 3 time(s)
skipping archived log file /d1/db1r_605ab325_1_37_612112605.arc; already backed up 3 time(s)
skipping archived log file /d1/db1r_605ab325_1_38_612112605.arc; already backed up 3 time(s)
skipping archived log file /d1/db1r_605ab325_1_39_612112605.arc; already backed up 3 time(s)
channel ORA_SBT_TAPE_1: starting archived log backup set
channel ORA_SBT_TAPE_1: specifying archived log(s) in backup set
input archived log thread=1 sequence=40 RECID=170 STAMP=612270506
channel ORA_SBT_TAPE_1: starting piece 1 at 19-JAN-07
channel ORA_SBT_TAPE_1: finished piece 1 at 19-JAN-07 with 2 copies and tag TAG20070119T110827
piece handle=2hi7t0db_1_1 comment=API Version 2.0,MMS Version 10.1.0.0
piece handle=2hi7t0db_1_2 comment=API Version 2.0,MMS Version 10.1.0.0
この場合、BACKUP ...COPIESの設定がCONFIGURE ...COPIESの設定をオーバーライドするため、n=2が設定されます。Recovery Managerは、sbtデバイスにログのコピーが2つ以上ある場合にのみ、ログのバックアップをスキップします。午前9時までに生成されたすべてのログについて、各ログの3つのコピーがsbt上に存在するため、Recovery Managerはこれらのログのバックアップをスキップします。ただし、午前9時より後に生成されたすべてのログについては、2つのコピーがバックアップされます。これは、そのログがまだテープにバックアップされていないためです。
CONNECTコマンドを使用すると、Recovery Managerとターゲット・データベース、補助データベースまたはリカバリ・カタログ・データベースとの接続を確立できます。
データベースへのSQL*Plus接続と同様に、データベースへのRecovery Manager接続が指定され、認証されます。唯一異なるのは、ターゲット・データベースまたは補助データベースへのRecovery Manager接続ではSYSDBA権限が必要なことです。AS SYSDBAキーワードは暗黙的に指定されおり、明示的に指定することはできません。SQL*Plus使用時のデータベース接続オプションについては、 『Oracle Database管理者ガイド』を参照してください。
CONNECT TARGET、CONNECT CATALOGおよびCONNECT AUXILIARYコマンドは、そのコマンドで指定するデータベースにRecovery Managerがまだ接続されていない場合にかぎり、Recovery Managerプロンプトからのみ実行できます。別のターゲット、カタログまたは補助データベースに接続するには、新規Recovery Managerセッションを開始する必要があります。
次のすべての条件が満たされている場合、Recovery ManagerセッションはNOCATALOGモードで実行されます。
CATALOGまたはNOCATALOGを指定しなかったこと。
CONNECT CATALOGをまだ実行していないこと。
| 構文の要素 | 説明 |
|---|---|
|
|
Recovery Managerと補助データベース・インスタンスとの接続を確立します。 補助インスタンスは、TRANSPORT TABLESPACEおよびDUPLICATEコマンドで使用されます。また、Recovery ManagerのTSPITR中にも使用されます。 |
|
|
Recovery Managerとリカバリ・カタログ・データベースとの接続を確立します。 リカバリ・カタログが仮想プライベート・カタログ（「CREATE CATALOG」を参照）の場合、このカタログに接続するRecovery Managerクライアントのパッチ・レベルは、10.1.0.6または10.2.0.3である必要があります。Oracle9i のRecovery Managerクライアントは、仮想プライベート・カタログに接続できません。このバージョン制限は、Oracle Database 11g の基本リカバリ・カタログへのRecovery Managerクライアント接続には影響しません。基本カタログに仮想プライベート・カタログのユーザーがいる場合も同様です。
Recovery Managerがすでにデフォルトの 注意: Data Guard環境でRecovery Managerを使用する場合は、リカバリ・カタログを使用する必要があります。 |
|
|
Recovery Managerとターゲット・データベースとの接続を確立します。
注意: Data Guard環境では、Recovery Managerはフィジカル・スタンバイ・データベースに |
|
データベースの接続情報を指定します。 |
この例では、Recovery ManagerをNOCATALOGモードで起動してから、Oracle Netサービス名がprod1のターゲット・データベースに接続します。Recovery Managerによって、SYSパスワードの入力を求めるプロンプトが表示されます。
% rman NOCATALOG
RMAN> CONNECT TARGET SYS@prod1;
target database Password: password
connected to target database: PROD1 (DBID=39525561)
例2-49 デフォルトのNOCATALOGモードでのターゲット・データベースへの接続
この例では、CATALOGまたはNOCATALOGのいずれも指定せずに、Recovery Managerを起動してから、オペレーティング・システム認証を使用してターゲット・データベースに接続します。CONNECT CATALOGコマンドが実行されていないため、BACKUPコマンドを実行すると、Recovery ManagerはデフォルトのNOCATALOGモードになります。
% rman
RMAN> CONNECT TARGET /
RMAN> BACKUP DATABASE;
Recovery Managerセッションのこの時点では、セッションがデフォルトのNOCATALOGモードになっているため、CONNECT CATALOGを実行できません。このセッションでカタログに接続しようとすると、次のエラーが発生します。
RMAN> CONNECT CATALOG rman@catdb
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-06445: cannot connect to recovery catalog after NOCATALOG has been used
例2-50 ターゲット・データベース、リカバリ・カタログ・データベースおよび補助データベースへの接続
この例では、ターゲット・データベースにはオペレーティング・システム認証機能を使用して接続し、リカバリ・カタログおよび補助データベースにはパスワード・ファイルを使用して接続します。Recovery Managerによって、パスワードの入力を求めるプロンプトが表示されます。
% rman
RMAN> CONNECT TARGET;
connected to target database: PROD (DBID=39525561)
RMAN> CONNECT CATALOG rman@catdb;
recovery catalog database Password: password
connected to recovery catalog database
RMAN> CONNECT AUXILIARY SYS@dupdb;
auxiliary database Password: password
connected to auxiliary database: DUPDB (not mounted)
CONVERTコマンドを使用すると、異なるプラットフォーム間でのトランスポートの準備として、表領域、データファイルまたはデータベースをトランスポート先プラットフォームの形式に変換できます。
Oracle Database 10g 以上のリリースでは、次の場合にCONVERT DATAFILEまたはCONVERT TABLESPACEが必要です。
V$TRANSPORTABLE_PLATFORM.ENDIAN_FORMATの値が異なるプラットフォーム間でのデータファイルをトランスポートする場合。
ENDIAN_FORMATが同じどうかにかかわらず、プラットフォーム間でUNDOセグメントを持つ表領域（通常は、SYSTEM表領域とUNDO表領域、およびロールバック・セグメントを持つ表領域）をトランスポートする場合。通常、SYSTEM表領域とUNDO表領域が変換されるのは、データベース全体を変換するときのみです。
CONVERTを使用するのは、ASMに格納されているデータベースに表領域をトランスポートするような場合です。Linuxのcp、WindowsのCOPYなどのオペレーティング・システムのネイティブ・コマンドでは、ASMディスク・グループの読み書きができません。
プラットフォームが、CONVERTコマンドでサポートされている必要があります。サポートされているプラットフォームは、V$TRANSPORTABLE_PLATFORMを問い合せて確認します。プラットフォーム間の表領域トランスポートは、ソースとトランスポート先プラットフォームの両方がこのビューに含まれている場合にのみサポートされます。
ソース・データベースおよびトランスポート先データベースの両方とも、初期化パラメータCOMPATIBLEが10.0以上に設定されて実行されている必要があります。次の互換性の前提条件に注意してください。
COMPATIBLEの設定が11.0.0未満の場合、読取り専用の表領域またはトランスポートされた既存の表領域は、1回以上読み書き両用にされていなければ、別のプラットフォームにトランスポートできません。表領域は、読み書き両用でオープンした後、すぐに読取り専用に戻すことができます。
COMPATIBLEが11.0.0以上の場合、読み書き両用の表領域に関する前述の制限は適用されません。ただし、トランスポートされた既存の表領域の形式はすでに10.0に設定されている必要があります。つまり、それらの表領域は、トランスポートされる前に、表領域のCOMPATIBLEを10.0に設定して読み書き両用にされている必要があります。
CONVERT TABLESPACEは、ソース・データベースにTARGETとして接続し、ソース・プラットフォームで表領域を変換する場合にのみ使用できます。
ソース・データベースはマウントまたはオープン状態である必要があります。変換する表領域は、変換時に読取り専用である必要があります。ソース・データベースで表領域を変換する場合は、トランスポート先データベースの状態は関係ありません。
CONVERT DATAFILEは、トランスポート先データベースにTARGETとして接続し、トランスポート先プラットフォームでデータファイルを変換する場合にのみ使用できます。
CONVERT DATABASE ON DESTINATIONで生成されたCONVERT DATAFILEスクリプトを実行している場合は、NOMOUNTオプションを指定してトランスポート先データベースのインスタンスを起動する必要があります。CONVERT DATABASE ON DESTINATIONで生成されたCONVERT DATAFILEスクリプトを実行していない場合は、トランスポート先データベースを起動、マウントまたはオープンすることができます。
トランスポート先データベースでデータファイルのコピーを変換する場合は、ソース・データベースの状態は関係ありません。ただし、トランスポート先データベースで、CONVERT DATAFILEスクリプトをデータベース変換の一部として実行しており、そのスクリプトが（NFSマウントなどにより）ソース・データベースのデータファイルに直接アクセスしている場合は、ソース・データベースは読取り専用でオープンする必要があります。
トランスポート先のホストで表領域を変換する場合は、CONVERT DATAFILEを使用する必要があります。CONVERT TABLESPACEでは、トランスポート先データベースが変換時にデータファイルを表領域に関連付けることができません。表領域に必要なデータファイルを変換した後は、そのファイルをトランスポート先データベースにトランスポートできます。
CONVERT DATABASEは、ソース・データベースにTARGETとして接続されている場合にのみ使用できます。また、ソース・データベースは読取り専用でオープンされている必要があります。CONVERT DATABASE ON DESTINATIONを実行しても、CONVERT DATABASEの実行時、トランスポート先データベースの状態には関係ありません。
CONVERT DATABASEは、CONVERT TABLESPACEおよびCONVERT DATAFILEと同じメカニズムでデータファイルを変換するため、表領域とデータファイルの使用上の注意と制約事項も適用されます。
CONVERT DATABASEに追加される重要な前提条件として、ソースとターゲットの両方のプラットフォームで、同じエンディアン形式を共有する必要があるということがあります。たとえば、データベースをMicrosoft WindowsからLinux for x86（ともにリトル・エンディアン）にトランスポートしたり、HP-UXからAIX（ともにビッグ・エンディアン）にトランスポートすることはできますが、SolarisからLinux x86へはトランスポートできません。ただし、ターゲット・プラットフォームに新しいデータベースを手動で作成すると、CONVERT TABLESPACEまたはCONVERT DATAFILEを使用して、ソース・データベースの表領域を個々にトランスポートできます。
ソース・プラットフォームとトランスポート先プラットフォームのエンディアン形式は同じでも、トランスポータブル・データベースのデータファイルは、ソース・ホストまたはトランスポート先ホストのいずれかで変換する必要があります。エンディアン形式が同じ場合は変換を行う必要がないプラットフォーム間での表領域のトランスポートとは異なり、データベース全体のトランスポートでは、UNDOセグメント内のブロックなどの特定のタイプのブロックを再フォーマットして、トランスポート先プラットフォームとの互換性を確保する必要があります。
変換処理はインプレースで実行されないため、入力ファイルがCONVERTによって変更されることはありません。かわりに、Recovery Managerによって指定された出力先に変換済ファイルが書き込まれます。
CONVERTでは、エンディアン変換が必要なユーザー・データ型は処理されません。プラットフォーム固有のフォーマットでデータを格納する、基礎となる型に基づいて作成されたデータベースの間でオブジェクトをトランスポートするには、データ・ポンプ・インポートおよびエクスポート・ユーティリティを使用してください。
Oracle Database 10g より前のリリースでは、UTF8などの可変幅キャラクタ・セットで作成されたCLOBは、エンディアンに依存する固定幅フォーマットで格納されていました。CONVERTコマンドでは、これらのCLOBに対する変換は実行されません。かわりに、Recovery Managerによって、各LOB列のエンディアン形式が取得され、ターゲット・データベースに伝播されます。その後、SQLレイヤーでこのデータを読み取ると、いずれかのエンディアン形式に正確に基づいたデータが解析され、表領域が書込み可能な場合はエンディアンに依存しない方法で書き込まれます。Oracle Database 10g 以上のリリースで作成されたCLOBは、プラットフォームに依存しないキャラクタ・セットAL16UTF16で格納されます。
（transportOptionList::=、convertOptionList::=）
（fileNameConversionSpec::=、formatSpec::=）
この句は、変換するオブジェクト（データファイル、表領域またはデータベース）を指定します。
| 構文の要素 | 説明 |
|---|---|
|
|
必要な他のデータベース・ファイルを確実に作成できるように、データファイルをトランスポート先プラットフォームの形式に変換します。
状況に応じて、ソース・プラットフォームまたはトランスポート先プラットフォームのいずれかで
|
|
関連項目: 「transportOptionList」を参照してください。 |
|
|
トランスポート先データベースにトランスポートするデータファイルの名前を指定します（例2-52を参照）。
convertOptionListの
SELECT NAME
|
|
|
別のプラットフォーム上のトランスポート先データベースにトランスポートする予定の、ソース・データベース内の表領域の名前を指定します（例2-51を参照）。 このオプションを指定すると、指定した表領域のデータファイルが、別のトランスポート先プラットフォームのフォーマットで生成されます。変換したファイルは、トランスポート先プラットフォームにトランスポートできます。
変換するデータファイルのトランスポート先プラットフォームを指定するには
注意: ソース・ホスト上の表領域のデータファイルを変換するには、 |
|
|
関連項目: 「convertOptionList」を参照してください。 |
この句は、トランスポートするデータファイル、表領域またはデータベースのオプションを指定します。
この副次句は、変換処理から除外するファイルを指定します。
この副次句は、変換の入出力オプションを指定します。
FORMATまたはfileNameConversionSpec引数を使用して、CONVERTコマンドで生成される出力ファイルの名前を制御できます。いずれも指定しない場合、出力ファイルの場所を管理する規則は、BACKUP AS COPY操作で生成される出力ファイルを管理する規則と同じになります。この規則については、「backupTypeSpec」を参照してください。
| 構文の要素 | 説明 |
|---|---|
|
文字列のペアです。ペアの最初の文字列がいずれかの入力ファイル名に含まれている場合は、含まれている場所に関係なく、常に、同じペアの2番目の文字列と置換されます。必要な数の置換文字列のペアを使用できます。一重引用符または二重引用符を使用できます。 関連項目: ASMおよびOracle Managed Filesに関連する制約事項については、「Oracle Managed Filesでの複製」を参照してください。 |
|
|
|
出力ファイルのネーム・テンプレートを指定します。ここで有効なフォーマット値については、BACKUP
Recovery Managerが
FROM PLATFORMまたはTO PLATFORMを指定せずに、
例2-53で示すとおり、 |
|
|
ソース・プラットフォームの名前を指定します。指定しなかった場合のデフォルトは、Recovery Managerが
指定するプラットフォームは、 SELECT PLATFORM_NAME, ENDIAN_FORMAT |
|
|
この操作で使用するチャネルの数を指定します。指定しない場合は、ディスクに対して割り当てられたチャネルまたは構成されたチャネルによってチャネルの数が決定されます。 |
|
|
トランスポート先プラットフォームの名前を指定します。指定しなかった場合のデフォルトは、Recovery Managerが
指定するプラットフォームは、 SELECT PLATFORM_NAME, ENDIAN_FORMAT |
ソース・データベースprodlinの表領域financeおよびhrを、トランスポート先データベースprodsunのプラットフォーム形式に変換するとします。finance表領域には、データファイル/disk2/orahome/fin/fin01.dbfおよび/disk2/orahome/fin/fin02.dbfが含まれています。hr表領域には、データファイル/disk2/orahome/fin/hr01.dbfおよび/disk2/orahome/fin/hr02.dbfが含まれています。
prodlinデータベースは、Linuxホストlin01上で実行されます。V$DATABASEを問い合せて、プラットフォーム名がLinux IA (32-bit)で、リトル・エンディアン形式が使用されていることを確認します。prodsunデータベースは、Solarisホストsun01上で実行されます。V$TRANSPORTABLE_PLATFORMを問い合せて、SolarisホストのPLATFORM_NAMEがSolaris[tm] OE (64-bit)で、ビッグ・エンディアン形式が使用されていることを確認します。
表領域の変換はソース・ホスト上で実行し、変換したデータファイルはホストlin01の/tmp/transport_to_solaris/に格納するとします。この例は、ソース・データベースのCOMPATIBLEが10.0以上に設定されていることを前提としています。
ソース・ホストlin01で、Recovery Managerクライアントを起動して次のコマンドを実行します。
CONNECT TARGET SYS@prodlin target database Password: password connected to target database: PRODLIN (DBID=39525561) SQL 'ALTER TABLESPACE finance READ ONLY'; SQL 'ALTER TABLESPACE hr READ ONLY'; CONVERT TABLESPACE finance, hr TO PLATFORM 'Solaris[tm] OE (64-bit)' FORMAT '/tmp/transport_to_solaris/%U';
この結果、変換されたデータファイルのセットが、Solaris（64-bit）プラットフォーム用の正しいエンディアン順序のデータとともに/tmp/transport_to_solaris/ディレクトリに出力されます。
ここからは、表領域トランスポートの一般的な手順に従います。構造情報のファイルが未作成の場合はデータ・ポンプ・エクスポート・ユーティリティを使用して作成し、構造情報ファイルおよび/tmp/transport_to_solaris/のデータファイルを、トランスポート先ホストの目的のディレクトリに移動し、データ・ポンプ・インポート・ユーティリティを使用して新しいデータベースに表領域を接続します。
この例では、表領域financeおよびhrをホストsun01のデータベースprodsunからトランスポート先ホストlin01のデータベースprodlin で使用可能な形式に変換します。変換前のデータファイルをトランスポート先ホストlin01のディレクトリ/tmp/transport_from_solaris/に一時的に格納し、CONVERT DATAFILEを使用して変換を実行します。トランスポート先データベースにデータファイルをトランスポートすると、そのファイルは/disk2/orahome/dbsに格納されます。
この例は、表領域トランスポートの準備として次の手順を実行していることを前提としています。
expdat.dmp）を作成していること。
financeおよびhrを読取り専用に設定していること。
expdat.dmpおよびトランスポートする変換前のデータファイルを、トランスポート先ホストlin01の/tmp/transport_from_solarisディレクトリにコピーしていること。データファイルは次のように格納されています。
V$TRANSPORTABLE_PLATFORMを問い合せて、PLATFORM_NAMEがSolaris[tm] OE (64-bit)であることを確認していること。
変換を実行するときは、次の点に注意してください。
FORMAT引数で、変換されたデータファイルの名前および場所を制御します。
FROM引数を使用してソース・プラットフォームを指定する必要があります。指定しない場合、Recovery Managerは、ソース・プラットフォームが、変換が実行されるホストのプラットフォームと同じであると想定します。
Recovery Managerクライアントを起動し、TARGETとしてトランスポート先データベースprodlinに接続します。次のCONVERTコマンドを使用して、トランスポートするデータファイルをトランスポート先ホストの形式に変換し、/disk2/orahome/dbsにその結果を保存します。
CONNECT TARGET SYS@prodlin target database Password: password connected to target database: PRODLIN (DBID=39525561) CONVERT DATAFILE '/tmp/transport_from_solaris/fin/fin01.dbf', '/tmp/transport_from_solaris/fin/fin02.dbf', '/tmp/transport_from_solaris/hr/hr01.dbf', '/tmp/transport_from_solaris/hr/hr02.dbf' DB_FILE_NAME_CONVERT '/tmp/transport_from_solaris/fin','/disk2/orahome/dbs/fin', '/tmp/transport_from_solaris/hr','/disk2/orahome/dbs/hr' FROM PLATFORM 'Solaris[tm] OE (64-bit)';
この結果、次のデータファイルがLinux形式に変換されています。
/disk2/orahome/dbs/fin/fin01.dbf
/disk2/orahome/dbs/fin/fin02.dbf
/disk2/orahome/dbs/hr/hr01.dbf
/disk2/orahome/dbs/hr/hr02.dbf
ここからは、表領域トランスポートの概要の残りの説明に従います。データ・ポンプ・インポート・ユーティリティを使用して、変換済の表領域を新しいデータベースに接続し、可能な場合は、表領域を読み書き両用に設定します。
この例では、通常のストレージからASMにデータファイルをコピーする方法を示します。生成されるファイルは、ターゲット・データベースに属するデータファイル・コピーとはみなされないため、LIST DATAFILECOPYでは表示されないことに注意してください。
ソースおよびトランスポート先のプラットフォームを指定せずに、CONVERT DATAFILEを使用します。出力場所は、ASMディスク・グループ+DATAFILEを次に示すように指定します。
RMAN> CONVERT DATAFILE '/disk1/oracle/dbs/my_tbs_f1.df', '/disk1/oracle/dbs/t_ax1.f'
FORMAT '+DATAFILE';
Starting conversion at 29-MAY-05
using channel ORA_DISK_1
channel ORA_DISK_1: starting datafile conversion
input filename=/disk1/oracle/dbs/t_ax1.f
converted datafile=+DATAFILE/asmv/datafile/sysaux.280.559534477
channel ORA_DISK_1: datafile conversion complete, elapsed time: 00:00:16
channel ORA_DISK_1: starting datafile conversion
input filename=/disk1/oracle/dbs/my_tbs_f1.df
converted datafile=+DATAFILE/asmv/datafile/my_tbs.281.559534493
channel ORA_DISK_1: datafile conversion complete, elapsed time: 00:00:04
Finished conversion at 29-MAY-05
次の例では、表領域のデータファイルを一意に生成されたファイル名でASMストレージから/tmpディレクトリにコピーする方法を示します。
RMAN> CONVERT TABLESPACE tbs_2 FORMAT '/tmp/tbs_2_%U.df';
Starting conversion at 03-JUN-05
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=20 devtype=DISK
channel ORA_DISK_1: starting datafile conversion
input datafile fno=00006 name=+DATAFILE/tbs_21.f
converted datafile=/tmp/tbs_2_data_D-L2_I-2786301554_TS-TBS_2_FNO-6_11gm2fq9.df
channel ORA_DISK_1: datafile conversion complete, elapsed time: 00:00:01
channel ORA_DISK_1: starting datafile conversion
input datafile fno=00007 name=+DATAFILE/tbs_22.f
converted datafile=/tmp/tbs_2_data_D-L2_I-2786301554_TS-TBS_2_FNO-7_12gm2fqa.df
channel ORA_DISK_1: datafile conversion complete, elapsed time: 00:00:01
channel ORA_DISK_1: starting datafile conversion
input datafile fno=00019 name=+DATAFILE/tbs_25.f
converted datafile=/tmp/tbs_2_data_D-L2_I-2786301554_TS-TBS_2_FNO-19_13gm2fqb.df
channel ORA_DISK_1: datafile conversion complete, elapsed time: 00:00:01
channel ORA_DISK_1: starting datafile conversion
input datafile fno=00009 name=+DATAFILE/tbs_23.f
converted datafile=/tmp/tbs_2_data_D-L2_I-2786301554_TS-TBS_2_FNO-9_14gm2fqc.df
channel ORA_DISK_1: datafile conversion complete, elapsed time: 00:00:01
channel ORA_DISK_1: starting datafile conversion
input datafile fno=00010 name=+DATAFILE/tbs_24.f
converted datafile=/tmp/tbs_2_data_D-L2_I-2786301554_TS-TBS_2_FNO-10_15gm2fqd.df
channel ORA_DISK_1: datafile conversion complete, elapsed time: 00:00:01
Finished conversion at 03-JUN-05
例2-54 異なるプラットフォームへのデータベースのトランスポート
CONVERT DATABASEの引数は、データファイルの変換をソース・プラットフォームで実行するか、トランスポート先のプラットフォームで実行するかによって異なります。ソースおよびトランスポート先のプラットフォームでの変換処理の詳細および例は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。データベースの変換は、その説明を最後まで読んでから実行してください。
Linuxホスト上のデータベースprod をWindowsホストにトランスポートするとします。データファイルは、トランスポート先のホストではなく、ソース・ホストで変換することにします。次の例では、Recovery ManagerをLinuxホストのprodデータベースに接続し、CONVERT DATABASE NEW DATABASEを実行してデータファイルを変換し、変換スクリプトを生成します。
CONNECT TARGET SYS@lin01
target database Password: password
connected to target database: PROD (DBID=39525561)
CONVERT DATABASE
NEW DATABASE 'prodwin'
TRANSPORT SCRIPT '/tmp/convertdb/transportscript'
TO PLATFORM 'Microsoft Windows IA (32-bit)'
DB_FILE_NAME_CONVERT '/disk1/oracle/dbs' '/tmp/convertdb';
次の例は部分的に変更し、Linuxホストで実行されているデータベースをWindowsホストにトランスポートしますが、データファイルの変換は、ソース・ホストでなく、トランスポート先のホストで実行します。次の例では、Recovery ManagerをLinuxホストのprodデータベースに接続し、CONVERT DATABASE ON DESTINATION PLATFORMを実行します。
CONNECT TARGET SYS@lin01
target database Password: password
connected to target database: PROD (DBID=39525561)
CONVERT DATABASE
ON DESTINATION PLATFORM
CONVERT SCRIPT '/tmp/convertdb/convertscript.rman'
TRANSPORT SCRIPT '/tmp/convertdb/transportscript.sql'
NEW DATABASE 'prodwin'
FORMAT '/tmp/convertdb/%U';
Linuxデータベース上で実行されるCONVERT DATABASE ON DESTINATION PLATFORMコマンドにより、データファイルをWindows形式に変換するためにWindowsホスト上で実行可能な変換スクリプトが生成されます。また、このCONVERT DATABASEコマンドでは、変換スクリプトも生成されます。
この使用例では、sun01というSolarisホスト上のデータベースprod を、aix01というAIXホストに移動することにします。Solarisデータファイルは、ASMではないファイル・システムに保存されていますが、AIXホストでは、データファイルをASMに保存することにします。
次の例では、sun01に接続し、CONVERT DATABASEを実行して必要なスクリプトを生成します。
CONNECT TARGET SYS@sun01
target database Password: password
connected to target database: PROD (DBID=39525561)
CONVERT DATABASE
ON DESTINATION PLATFORM
CONVERT SCRIPT '/tmp/convert_newdb.rman'
TRANSPORT SCRIPT '/tmp/transport_newdb.sql'
NEW DATABASE 'prodaix'
DB_FILE_NAME_CONVERT '/u01/oradata/DBUA/datafile','+DATA';
変換スクリプトには、次の書式の文が記述されます。ここで、your_source_platformはソース・プラットフォームを表します。
CONVERT DATAFILE '/u01/oradata/DBUA/datafile/o1_mf_system_2lg3905p_.dbf'
FROM PLATFORM 'your_source_platform'
FORMAT '+DATA/o1_mf_system_2lg3905p_.dbf';
変換時の停止時間を短縮するには、ネットワーク経由でデータファイルをコピーしたりバックアップをリストアするのではなく、NFSを使用できます。たとえば、Solarisファイル・システムは、AIXホストに/net/solaris/oradataとしてマウントできます。この場合、変換するソース・データファイルの場所としてNFSマウントのディレクトリを参照するように変換スクリプトを編集することが必要になります。そのとき、コマンドは次のようになります。
CONVERT DATAFILE '/net/solaris/oradata/DBUA/datafile/o1_mf_system_2lg3905p_.dbf'
FROM PLATFORM 'your_source_platform'
FORMAT '+DATA/o1_mf_system_2lg3905p_.dbf';
次に、Recovery Managerをトランスポート先のデータベース・インスタンス（この例では、ホストaix01のインスタンス）に接続し、変換スクリプトを実行して、データファイルを変換します。その後、SQL*Plusを aix01のデータベース・インスタンスに接続し、変換スクリプトを実行してデータベースを作成します。
CREATE CATALOGコマンドを使用すると、リカバリ・カタログを作成できます。
リカバリ・カタログは、基本リカバリ・カタログ（一連のターゲット・データベースのRecovery Managerメタデータを含むデータベース・スキーマ）にすることができます。仮想リカバリ・カタログは、基本カタログのサブセットにユーザーがアクセスするための一連のシノニムとビューです。
|
関連項目:
|
このコマンドは、Recovery Managerプロンプトでのみ実行してください。Recovery ManagerをCATALOGコマンドライン・オプションまたはCONNECT CATALOGコマンドを通じてリカバリ・カタログ・データベースに接続し、カタログ・データベースをオープンする必要があります。ターゲット・データベースへの接続は不要です。
リカバリ・カタログが基本カタログと仮想カタログのいずれの場合でも、リカバリ・カタログの所有者には、RECOVERY_CATALOG_OWNERロールが付与されている必要があります。また、このユーザーには、リカバリ・カタログ表が格納される表領域に対する権限も付与されている必要があります。リカバリ・カタログは、リカバリ・カタログ所有者のデフォルト表領域に作成されます。
仮想リカバリ・カタログを作成している場合は、基本リカバリ・カタログの所有者がGRANTコマンドを使用して、CATALOGまたはREGISTERのいずれかの権限をこのユーザーに付与している必要があります（例2-57を参照）。
Oracle Database 10g リリース以前のRecovery Managerクライアントの場合は、Recovery Managerクライアントが仮想カタログに接続する際の制約について、CONNECT CATALOGの説明を参照してください。
リカバリ・カタログは、通常リカバリ・カタログ専用に作成されたデータベースに作成します。リカバリ・カタログをSYSスキーマに作成することはお薦めしません。
リカバリ・カタログは、1つ作成して、中央管理されているRecovery Managerリポジトリとして、複数のデータベースで使用するようにしてください。そのため、このカタログは、基本リカバリ・カタログと呼ばれます。
基本リカバリ・カタログ所有者は、GRANTやREVOKEを使用して、他のデータベース・ユーザーからのカタログへのアクセスを制限できます。制限を受けるユーザーでも、自分専用のメタデータ（仮想プライベート・カタログと呼ばれます）への完全な読み/書き両用アクセス権を持っています。Recovery Managerメタデータは、仮想プライベート・カタログ所有者のスキーマに格納されます。基本リカバリ・カタログ所有者は、それぞれの仮想カタログ・ユーザーがアクセスできる内容を制御します。
10.2以前のリリースのRecovery Managerで仮想カタログを使用する場合は、追加手順の実行も必要です。仮想プライベート・カタログを使用する前に、リカバリ・カタログ・データベースに仮想カタログ所有者として接続し、次のPL/SQLプロシージャを実行してください（base_catalog_ownerは、基本リカバリ・カタログを所有するデータベース・ユーザーです）。
base_catalog_owner.DBMS_RCVCAT.CREATE_VIRTUAL_CATALOG
SQL*Plusを起動し、管理者権限でリカバリ・カタログcatdbに接続するとします。次のようにCREATE USER文を実行して、パスワードをユーザー指定のパスワードで置き換えます（安全なパスワードの作成の詳細は、『Oracle Databaseセキュリティ・ガイド』を参照）。SQL文では、データベースcatdbにユーザーcatownerが作成され、そのcatownerユーザーにRECOVERY_CATALOG_OWNERロールが付与されます。
SQL> CREATE USER catowner IDENTIFIED BY password
2 DEFAULT TABLESPACE cattbs
3 QUOTA UNLIMITED ON cattbs;
SQL> GRANT recovery_catalog_owner TO catowner;
SQL> EXIT
次に、Recovery Managerを起動し、次のRecovery Managerコマンドを実行して、catownerとしてリカバリ・カタログ・データベースに接続し、リカバリ・カタログを作成します。
RMAN> CONNECT CATALOG catowner@catdb
recovery catalog database Password: password
connected to recovery catalog database
RMAN> CREATE CATALOG;
同じRecovery Managerセッションで、オペレーティング・システム認証を使用してターゲット・データベースに接続し、REGISTER DATABASEコマンドを使用して、カタログにこのデータベースを登録します。
RMAN> CONNECT TARGET /
RMAN> REGISTER DATABASE;
RMAN> EXIT
例2-57 仮想プライベート・カタログの作成
例2-56に示すように、リカバリ・カタログを作成し、データベースが登録してあるとします。ここで、データベース・ユーザーvpc1に仮想プライベート・カタログを作成することにします。SQL*Plusを起動し、管理者権限でリカバリ・カタログ・データベースcatdbに接続します。vpc1ユーザーを作成し、次のようにリカバリ・カタログの所有権を付与して、パスワードをユーザー指定のパスワードで置き換えます（安全なパスワードの作成の詳細は、『Oracle Databaseセキュリティ・ガイド』を参照）。
SQL> CREATE USER vpc1 IDENTIFIED BY password
2 DEFAULT TABLESPACE vpcusers
3 QUOTA UNLIMITED ON vpcusers;
SQL> GRANT recovery_catalog_owner TO vpc1;
SQL> EXIT
次に、Recovery Managerを起動し、カタログ所有者catownerとしてリカバリ・カタログ・データベースに接続します。デフォルトでは、仮想カタログ所有者は基本リカバリ・カタログにアクセスできません。GRANTコマンドを使用して、仮想プライベート・カタログにvpc1へのアクセス権を付与し、（データベースprod2ではなく）データベースprod1に対してRecovery Managerが操作できるようにします。
RMAN> CONNECT CATALOG catowner@catdb
recovery catalog database Password: password
connected to recovery catalog database
RMAN> GRANT CATALOG FOR DATABASE prod1 TO vpc1;
RMAN> EXIT;
この時点で、仮想プライベート・カタログvpc1を使用するバックアップ・オペレータは、仮想カタログの作成準備ができています。次の例では、バックアップ・オペレータがリカバリ・カタログ・データベースにvpc1として接続し、vpc1の仮想プライベート・カタログを作成します。
RMAN> CONNECT CATALOG vpc1@catdb
recovery catalog database Password: password
connected to recovery catalog database
RMAN> CREATE VIRTUAL CATALOG;
RMAN> EXIT;
仮想カタログは最終的にOracle Database 10g ターゲット・データベースで使用する予定なので、このオペレータは、PL/SQLプロシージャCREATE_VIRTUAL_CATALOGを実行してから、仮想カタログを使用する必要があります（「使用上の注意」を参照）。次の例では、バックアップ・オペレータが次のようにリカバリ・カタログ・データベースにvpc1として接続し、PL/SQLプロシージャを実行します。
SQL> CONNECT vpc1@catdb
Enter password: password
Connected.
SQL> BEGIN
2 catowner.DBMS_RCVCAT.CREATE_VIRTUAL_CATALOG;
3 END;
4 /
CREATE SCRIPTコマンドを使用すると、リカバリ・カタログ内にストアド・スクリプトを作成できます。ストアド・スクリプトは、名前が付けられ、後で実行するためにリカバリ・カタログに格納されている一連のRecovery Managerコマンドです。
|
関連項目:
|
CREATE SCRIPTは、Recovery Managerプロンプトでのみ実行できます。Recovery Managerが、ターゲット・データベースとリカバリ・カタログに接続されている必要があります。リカバリ・カタログ・データベースはオープン状態である必要があります。
GLOBALを指定する場合は、その名前のグローバル・スクリプトがリカバリ・カタログ内にまだ存在していないことが必要です。GLOBALを指定しない場合は、同じ名前のローカル・スクリプトが、同じターゲット・データベースに対してまだ存在していないことが必要です。この前提条件が満たされない場合は、エラーRMAN-20401が戻されます。
ストアド・スクリプトには、ローカルとグローバルがあります。ローカル・スクリプトは、現行のターゲット・データベース用にのみ作成されますが、グローバル・スクリプトは、リカバリ・カタログに登録されているすべてのデータベースで使用できます。
グローバル・スクリプトをローカル・スクリプトと同じ名前で、またローカル・スクリプトをグローバル・スクリプトと同じ名前で作成することもできます。
Recovery Manangerでは、ストアド・スクリプトで置換変数を使用できます。&1は最初の値を配置する位置を示し、&2は2番目の値を配置する位置を示します。その後も同様に続きます。特殊文字は、引用符で囲む必要があります。
置換変数の構文は、&integerの後にオプションでピリオドが続きます（&1.3など）。オプションのピリオドは変数の一部であり、値と置換されますので、置換テキストの直後に別の整数を続けることができます。たとえば、置換変数&1.3が含まれているコマンド・ファイルに値mybackupを渡すと、その置換結果はmybackup3になります。mybackup.3という結果を得るには、構文&1..3を使用します。
置換変数を使用するストアド・スクリプトを作成する場合は、作成時に例となる値を指定する必要があります。これらの値は、Recovery Managerの起動時にUSING句で指定するか（「RMAN」を参照）、またはプロンプトが表示されたときに入力します（例2-60を参照）。
（backupCommands::=、maintenanceCommands::=、miscellaneousCommands::=、restoreCommands::=）
| 構文の要素 | 説明 |
|---|---|
|
|
注意: 仮想プライベート・カタログは、グローバル・スクリプトに対して読取り専用のアクセスが可能です。グローバル・スクリプトの作成と更新は、基本リカバリ・カタログへの接続中に行う必要があります。 |
|
|
スクリプトの名前を指定します。スクリプト名に空白または予約語が含まれている場合は、引用符で囲む必要があります。 |
|
|
説明のコメントをリカバリ・カタログ内のストアド・スクリプトと関連付けます。このコメントは、LIST |
|
|
ストアド・スクリプトに含めるコマンドを指定します。 |
|
|
指定したファイルからスクリプトを定義する一連のコマンドを読み取ります。
このファイルは、有効なストアド・スクリプトの本体と同様である必要があります。このファイルの最初の行は、左カッコ（ |
データベースprodをバックアップするローカル・ストアド・スクリプトを作成するとします。Recovery Managerを起動し、TARGETとしてprodに接続して、リカバリ・カタログに接続します。backup_wholeというストアド・スクリプトを作成し、EXECUTE SCRIPTを使用して、次のようにそのスクリプトを実行します。
CREATE SCRIPT backup_whole
COMMENT "backup whole database and archived redo logs"
{
BACKUP
INCREMENTAL LEVEL 0 TAG backup_whole
FORMAT "/disk2/backup/%U"
DATABASE PLUS ARCHIVELOG;
}
RUN { EXECUTE SCRIPT backup_whole; }
例2-59 グローバル・ストアド・スクリプトの作成
この例では、Recovery Managerをターゲット・データベースprodに接続し、カタログ・ユーザーrcoとしてリカバリ・カタログ・データベースcatdbに接続します。この例では、データベースおよびアーカイブREDOログをバックアップするglobal_backup_dbというグローバル・スクリプトを作成します。
RMAN> CONNECT TARGET SYS@prod
target database Password: password
connected to target database: PROD (DBID=39525561)
RMAN> CONNECT CATALOG rco@catdb
recovery catalog database Password: password
connected to recovery catalog database
RMAN> CREATE GLOBAL SCRIPT global_backup_db { BACKUP DATABASE PLUS ARCHIVELOG; }
RMAN> EXIT;
これで、Recovery Managerをprod2などの別のターゲット・データベースに接続し、グローバル・ストアド・スクリプトを実行できます。
RMAN> CONNECT TARGET SYS@prod2
target database Password: password
connected to target database: PROD2 (DBID=36508508)
RMAN> CONNECT CATALOG rco@catdb
recovery catalog database Password: password
connected to recovery catalog database
RMAN> RUN { EXECUTE SCRIPT global_backup_db; }
例2-60 置換変数を使用するストアド・スクリプトの作成
次の例では、Recovery Managerをターゲット・データベースおよびリカバリ・カタログに接続し、CREATE SCRIPTを使用して、3つの置換変数が含まれるバックアップ・スクリプトを作成します。Recovery Managerによって、変数の初期値を入力するプロンプトが表示されます（太字がユーザー入力です）。
RMAN> CONNECT TARGET /
RMAN> CONNECT CATALOG rman@catdb
recovery catalog database Password: password
connected to recovery catalog database
RMAN> CREATE SCRIPT backup_df { BACKUP DATAFILE &1 TAG &2.1 FORMAT '/disk1/&3_%U'; }
Enter value for 1: 1
Enter value for 2: df1_backup
Enter value for 3: df1
starting full resync of recovery catalog
full resync complete
created script backup_df
EXECUTE SCRIPTの実行時に、スクリプトに別の値を渡すことができます。次の例では、値3、test_backupおよびtestをストアド・スクリプトの置換変数に渡しています。
RMAN> RUN { EXECUTE SCRIPT backup_df USING 3 test_backup df3; }
値が置換され、スクリプトは次のように実行されます。
BACKUP DATAFILE 3 TAG test_backup1 FORMAT '/disk1/df3_%U';
CROSSCHECKコマンドを使用すると、実際の物理的なバックアップおよびコピーを、Recovery Managerリポジトリ内の論理レコードと同期させることができます。
Recovery Managerはターゲット・データベース・インスタンスに接続され、そのインスタンスが起動されている必要があります。
ディスクのクロスチェックを行うためのメンテナンス・チャネルは不要です。メディア・マネージャを使用する場合、それに対する自動チャネルが構成されていないときは、ALLOCATE CHANNEL FOR MAINTENANCEを実行してからCROSSCHECKを実行する必要があります。たとえば、SBTデバイスの自動SBTチャネルを構成せずにSBTチャネルでバックアップを作成した場合は、このチャネルを手動で割り当ててからでなければ、CROSSCHECKによるバックアップのチェックは実行できません。さらに、各種メディア・マネージャ・オプション（プール、サーバー、ライブラリなど）でバックアップを実行した場合は、それぞれの組合せに対してメンテナンス・チャネルを割り当てる必要があります。
クロスチェックでは、指定されたすべてのバックアップおよびコピーが検証されます。これは、以前のデータベース・インカネーションで作成されたものも対象となります。
Recovery Managerでは、操作対象のすべてのターゲット・データベースの制御ファイル内にバックアップに関する論理メタデータを常に保持します。Recovery Managerをリカバリ・カタログとともに使用する場合は、リカバリ・カタログに登録されたすべてのデータベースのメタデータも保持されます。
バックアップがディスク上に存在する場合、CROSSCHECKを実行すると、ファイルのヘッダーが有効かどうかを判断できます。バックアップがテープ上に存在する場合は、Recovery Managerが、チェック対象のバックアップ・ピースの名前と場所をRecovery Managerリポジトリに問い合せます。Recovery Managerは、このメタデータをターゲット・データベースのサーバーに送信し、メディア管理ソフトウェアにバックアップの情報を問い合せます。次に、メディア管理ソフトウェアがメディア・カタログをチェックして、バックアップのステータスをサーバーにレポートします。
Recovery Managerリポジトリに記録されているバックアップ・セットおよびコピーのステータスは、LIST、V$ビュー、またはリカバリ・カタログ・ビュー（Recovery Managerをカタログとともに使用する場合）で確認できます。表2-4に、各ステータスの意味を示します。
CROSSCHECKコマンドで処理されるのは、クロスチェックに使用されているチャネルと同じデバイス・タイプで作成されたファイルのみです。CROSSCHECKコマンドは、リポジトリでAVAILABLEまたはEXPIREDのマークが付いているオブジェクトのみをチェックします。この処理は、DISKチャネルの場合はディスク上のファイルを検査し、sbtチャネルの場合はメディア・マネージャに問い合せて行われます。
| ステータス | 説明 |
|---|---|
|
|
オブジェクトがファイル・システム内（
バックアップが |
|
|
オブジェクトはRecovery Managerで使用可能です。バックアップ・セットを |
バックアップの関連付けとアクセス可能性の違いについては、「Data Guard環境でのRecovery Managerのバックアップ」を参照してください。Data Guard環境では、バックアップまたはコピーを作成するデータベースはファイルに関連付けられます。Data Guard環境のどのデータベースに接続されていても、バックアップに接続可能であれば、CHANGE、DELETE、CROSSCHECKなどのメンテナンス・コマンドをバックアップに使用できます。通常、Recovery Managerでは、データベース上で作成されたテープ・バックアップはその環境のすべてのデータベースにアクセス可能であるとみなされますが、ディスク・バックアップは作成元のデータベースのみにアクセス可能であるとみなされます。
Recovery Managerは、バックアップと関連付けられたデータベースにTARGETとして接続されている場合のみ、バックアップのステータスをAVAILABLEからEXPIREDまたはDELETEDに更新できます。バックアップがターゲット・データベースに関連付けられていないためにRecovery Managerが削除を実行できない場合は、そのバックアップが関連付けられているデータベースで、同じCROSSCHECK操作をそのファイルに実行するように求めるプロンプトが表示されます。このように、Recovery Managerでは、不適切なSBT構成による意図しないステータス変更を防止しています。
たとえば、Recovery Managerをスタンバイ・データベースstandby1にTARGETとして接続し、そのデータベースをテープにバックアップするとします。バックアップを手動でテープから削除し、standby2でバックアップのクロスチェックを実行すると、standby1でクロスチェックを実行するように求めるプロンプトが表示されます。バックアップが削除されたことがメディア・マネージャからレポートされた場合は、standby1のクロスチェックにより、テープ・バックアップのステータスがEXPIREDに更新されます。
（listObjList::=、archivelogRecordSpecifier::=、foreignlogRecordSpecifier::=、maintQualifier::=、recordSpec::=、deviceSpecifier::=）
| 構文の要素 | 説明 |
|---|---|
|
バックアップおよびコピーをクロスチェックします。 |
この例では、デフォルトの構成済チャネルがDEVICE TYPE sbtであると仮定して、テープ上とディスク上のすべてのバックアップとコピーのステータスをクロスチェックします（出力の一部を示します）。Recovery Managerではディスク・チャネルが事前に構成されるため、手動で割り当てる必要はありません。
RMAN> CROSSCHECK BACKUP;
allocated channel: ORA_SBT_TAPE_1
channel ORA_SBT_TAPE_1: SID=84 device type=SBT_TAPE
channel ORA_SBT_TAPE_1: Oracle Secure Backup
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=86 device type=DISK
backup piece handle=/disk2/backup/08i9umon_1_1 RECID=7 STAMP=614423319
crosschecked backup piece: found to be 'EXPIRED'
backup piece handle=/disk2/backup/09i9umso_1_1 RECID=8 STAMP=614423448
crosschecked backup piece: found to be 'EXPIRED'
backup piece handle=/disk1/cfauto/c-26213402-20070213-00 RECID=9 STAMP=614423452
crosschecked backup piece: found to be 'AVAILABLE'
backup piece handle=0bi9uo81_1_1 RECID=10 STAMP=614424833
crosschecked backup piece: found to be 'AVAILABLE'
backup piece handle=c-26213402-20070213-01 RECID=11 STAMP=614424851
crosschecked backup piece: found to be 'AVAILABLE'
.
.
.
例2-62 日付範囲内でのクロスチェック
この例では、指定した6週間のバックアップ・セットの状態をメディア・マネージャに問い合せます。Recovery Managerでは、NLS_DATE_FORMATパラメータで指定された日付書式が使用されることに注意してください。この例では、'DD-MON-YY'が使用されています。最初のコマンドは、テープ上のバックアップのみをクロスチェックします。
ALLOCATE CHANNEL FOR MAINTENANCE DEVICE TYPE sbt;
CROSSCHECK BACKUP
COMPLETED BETWEEN '01-JAN-07' AND '14-FEB-07';
RELEASE CHANNEL;
次のコマンドは、ディスクのみをクロスチェックするようにDEVICE TYPE DISKを指定します。
CROSSCHECK BACKUP DEVICE TYPE DISK
COMPLETED BETWEEN '01-JAN-07' AND '14-FEB-07';
SBTがデフォルトのチャネルの場合は、デフォルトのチャネルでCROSSCHECKを実行して、ディスクとSBTバックアップの両方をクロスチェックできます。
CROSSCHECK BACKUP COMPLETED BETWEEN '01-JAN-07' AND '14-FEB-07';
DELETEコマンドを使用すると、次の操作を実行できます。
V$BACKUP_PIECE.STATUSのバックアップ・ピースのレコードに、値Dが表示されます。
RC_BACKUP_PIECEには、削除されたバックアップ・ピースの行が含まれなくなります。Recovery Managerがターゲット・データベースに接続していて、そのデータベースがマウントまたはオープン状態である必要があります。
Recovery Managerは、構成済のすべてのチャネルを使用して削除を実行します。自動チャネルが構成されていないデバイス上のファイルに対してDELETEを使用する場合は、ALLOCATE CHANNEL FOR MAINTENANCEを使用する必要があります。たとえば、SBTチャネルでバックアップを作成したが、構成されているのがディスク・チャネルのみであれば、DELETE用にSBTチャネルを手動で割り当てる必要があります。ディスク専用のファイルに対してDELETEを使用する場合は、自動または手動で割り当てられたメンテナンス・チャネルが必要です。
CROSSCHECKを実行してバックアップおよびコピーのリポジトリでのステータスを更新してから、DELETEを実行して目的のファイルを削除するすることをお薦めします。Recovery Managerを対話方式で実行している場合にDELETEを実行すると、ファイルのリストが表示され、そのリスト内のファイルを削除する前に確認のプロンプトが表示されます。確認すると、Recovery Managerでは削除されるたびに各項目が表示されます。コマンド・ファイルからコマンドを読み取る場合は、Recovery Managerによって確認のプロンプトは表示されません。
Recovery Managerリポジトリに記録されているバックアップおよびコピーのステータスは、LIST、V$ビュー、またはリカバリ・カタログ・ビュー（カタログを使用している場合）で確認できます。バックアップのリポジトリ・レコードに、バックアップの物理的な状態が反映されていないことがあります。たとえば、ディスク・バックアップを、Linuxのrmコマンドで削除する場合です。バックアップ・レコードはrmでは更新できないため、Recovery Managerリポジトリには、ファイルが存在していなくても使用可能と表示されます。
表2-5に、FORCEオプションが指定されていない場合のDELETEの動作を示します。
バックアップの関連付けとアクセス可能性の違いについては、「Data Guard環境でのRecovery Managerのバックアップ」を参照してください。Data Guard環境では、バックアップまたはコピーを作成するデータベースはファイルに関連付けられます。Data Guard環境のどのデータベースに接続されていても、バックアップに接続可能であれば、CHANGE、DELETE、CROSSCHECKなどのメンテナンス・コマンドをバックアップに使用できます。通常、Recovery Managerでは、データベース上で作成されたテープ・バックアップはその環境のすべてのデータベースにアクセス可能であるとみなされますが、ディスク・バックアップは作成元のデータベースのみにアクセス可能であるとみなされます。
削除が正常に行われると、Recovery Managerはそのファイルのメタデータを削除します。ファイルが別のデータベースに関連付けられている場合も同様です。削除が正常に行われず、そのファイルがData Guard環境の別のデータベースに関連付けられている場合は、ファイルに関連付けられたデータベースにTARGETとして接続した状態で、同じDELETEコマンドを実行するように求めるプロンプトが表示されます。ファイルのメタデータを削除するには、DELETE ...FORCEを使用する必要があります。
（maintSpec::=、obsOperandList::=、deviceSpecifier::=）
（listObjList::=、archivelogRecordSpecifier::=、maintQualifier::=、deviceSpecifier::=、recordSpec::=）
| 構文の要素 | 説明 |
|---|---|
|
|
指定したファイルを（メディア上に存在するかどうかに関係なく）削除し、リポジトリ・レコードを削除します（例2-66を参照）。 削除されたオブジェクトに関するI/Oエラーは無視されます。また、CONFIGURE ARCHIVELOG DELETION POLICYの設定も無視されます。ジョブが終了すると、削除されたオブジェクトの数が表示されます。 |
|
|
先にファイル・リストを表示したり確認を求めるプロンプトを表示せずに、指定したファイルを削除します。 |
|
|
リポジトリ内のステータスが
|
|
maintQualifier句で削除ルールを設定できます。たとえば、テープにバックアップされたアーカイブ・ログを削除できます（例2-65を参照）。
注意: 関連項目: 「maintSpec」および「maintQualifier」を参照してください。 |
|
|
Data Guard環境の指定した
注意:
Recovery Managerは、指定した
注意: 関連項目: この句のオプションについては、「forDbUniqueNameOption」を参照してください。 |
|
|
|
Recovery Managerリポジトリに記録されているデータファイルのバックアップとコピーのうち、廃止、つまり不要になったものを削除します（例2-64を参照）。また、不要なアーカイブREDOログおよびログ・バックアップもRecovery Managerによって削除されます。 Recovery Managerでは、データファイルのうち不要になったバックアップとコピーが判別されてから、ログ（およびそのバックアップ）が不要になる時期が判断されます。データファイルの作成は、保存するログの決定時にバックアップとみなされます。
Recovery Managerでは、まずobsOperandListで指定したオプションを使用して、不要になったファイルが判断されます。obsOperandListでオプションを指定しなければ、CONFIGURE
注意:
注意: |
|
関連項目: 「obsOperandList」を参照してください。 |
|
|
削除の対象を、指定したデバイス・タイプで作成された不要なバックアップとコピーのみに制限します。 関連項目: 「deviceSpecifier」を参照してください。 |
この例では、構成済のsbtチャネルを使用して、1か月以上経過している表領域usersの期限切れバックアップの有無についてメディア・マネージャをチェックし、該当するリカバリ・カタログ・レコードを削除します。
CROSSCHECK BACKUPSET OF TABLESPACE users
DEVICE TYPE sbt COMPLETED BEFORE 'SYSDATE-31';
DELETE NOPROMPT EXPIRED BACKUPSET OF TABLESPACE users
DEVICE TYPE sbt COMPLETED BEFORE 'SYSDATE-31';
例2-64 不要なバックアップの削除
この例では、データベースのリカバリに不要になったバックアップとコピーを、先週の任意のSCNまで削除します。また、不要になったアーカイブREDOログも削除されます。
DELETE NOPROMPT OBSOLETE RECOVERY WINDOW OF 7 DAYS;
例2-65 バックアップ済のアーカイブREDOログの削除
Recovery Managerの設定を次のように構成しているとします。
CONFIGURE DEFAULT DEVICE TYPE TO sbt;
CONFIGURE ARCHIVELOG DELETION POLICY TO
BACKED UP 2 TIMES
TO DEVICE TYPE sbt;
次のDELETEコマンドは、構成済の削除方針（ログはテープに2回バックアップする必要がある）を満たす必要がない、ディスク上のすべてのアーカイブREDOログを削除します（次に出力を示します）。
RMAN> DELETE ARCHIVELOG ALL;
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=84 device type=DISK
List of Archived Log Copies for database with db_unique_name PROD
=====================================================================
Key Thrd Seq S Low Time
------- ---- ------- - ---------
107 1 4 A 12-FEB-07
Name: /orcva/PROD/archivelog/2007_02_12/o1_mf_1_4_2x28bpcm_.arc
108 1 5 A 12-FEB-07
Name: /orcva/PROD/archivelog/2007_02_12/o1_mf_1_5_2x28g7s9_.arc
109 1 6 A 12-FEB-07
Name: /orcva/PROD/archivelog/2007_02_13/o1_mf_1_6_2x3bbqym_.arc
157 1 7 A 13-FEB-07
Name: /orcva/PROD/archivelog/2007_02_13/o1_mf_1_7_2x3w2cvs_.arc
164 1 8 A 13-FEB-07
Name: /orcva/PROD/archivelog/2007_02_13/o1_mf_1_8_2x3w40vr_.arc
171 1 9 A 13-FEB-07
Name: /orcva/PROD/archivelog/2007_02_13/o1_mf_1_9_2x3w8pf7_.arc
318 1 10 A 13-FEB-07
Name: /orcva/PROD/archivelog/2007_02_13/o1_mf_1_10_2x3zx6d9_.arc
330 1 11 A 13-FEB-07
Name: /orcva/PROD/archivelog/2007_02_13/o1_mf_1_11_2x403wco_.arc
448 1 12 A 13-FEB-07
Name: /orcva/PROD/archivelog/2007_02_13/o1_mf_1_12_2x40wn6x_.arc
455 1 13 A 13-FEB-07
Name: /orcva/PROD/archivelog/2007_02_13/o1_mf_1_13_2x412s3m_.arc
583 1 14 A 13-FEB-07
Name: /orcva/PROD/archivelog/2007_02_13/o1_mf_1_14_2x428p9d_.ar
638 1 15 A 13-FEB-07
Name: /orcva/PROD/archivelog/2007_02_13/o1_mf_1_15_2x42f0gj_.arc
Do you really want to delete the above objects (enter YES or NO)?
例2-66 バックアップ・セットの強制削除
次の例では、タグweekly_bkupを持つバックアップ・セットのコピーを削除します。
RMAN> DELETE NOPROMPT BACKUPSET TAG weekly_bkup;
リポジトリにはバックアップ・セットがAVAILABLEとして表示されても、オブジェクトは実際にはメディア上で使用できないため、Recovery Managerでは警告が表示されます。
List of Backup Pieces
BP Key BS Key Pc# Cp# Status Device Type Piece Name
------- ------- --- --- ----------- ----------- ----------
809 806 1 1 AVAILABLE SBT_TAPE 0ri9uu08_1_1
RMAN-06207: WARNING: 1 objects could not be deleted for SBT_TAPE channel(s) due
RMAN-06208: to mismatched status. Use CROSSCHECK command to fix status
RMAN-06210: List of Mismatched objects
RMAN-06211: ==========================
RMAN-06212: Object Type Filename/Handle
RMAN-06213: --------------- ---------------------------------------------------
RMAN-06214: Backup Piece 0ri9uu08_1_1
次のコマンドを実行すると、Recovery Managerによってバックアップ・セットが強制的に削除されます（例には出力例も含まれます）。
RMAN> DELETE FORCE NOPROMPT BACKUPSET TAG weekly_bkup;
using channel ORA_SBT_TAPE_1
using channel ORA_DISK_1
List of Backup Pieces
BP Key BS Key Pc# Cp# Status Device Type Piece Name
------- ------- --- --- ----------- ----------- ----------
809 806 1 1 AVAILABLE SBT_TAPE 0ri9uu08_1_1
deleted backup piece
backup piece handle=0ri9uu08_1_1 RECID=26 STAMP=614430728
Deleted 1 objects
DELETE SCRIPTコマンドを使用すると、ローカルまたはグローバルのストアド・スクリプトをリカバリ・カタログから削除できます。
DELETE SCRIPTは、Recovery Managerプロンプトでのみ実行できます。Recovery Managerが、リカバリ・カタログとターゲット・データベースに接続している必要があります。リカバリ・カタログ・データベースはオープン状態である必要があります。
ストアド・スクリプトには、ローカルとグローバルがあります。ローカル・スクリプトは、現行のターゲット・データベース用にのみ作成されますが、グローバル・スクリプトは、リカバリ・カタログに登録されているすべてのデータベースで使用できます。
GLOBALを指定する場合は、その名前のグローバル・スクリプトが、リカバリ・カタログ内にすでに存在している必要があります。存在していない場合は、エラーRMAN-06710が戻されます。GLOBALを指定しなかった場合は、Recovery Managerによって、指定した名前のローカル・ストアド・スクリプトが現行のターゲット・データベースに定義されていないかどうか確認されます。そのようなスクリプトがターゲット・データベースに定義されていなかった場合は、同じ名前のグローバル・ストアド・スクリプトが検索され、存在した場合は削除されます。
| 構文の要素 | 説明 |
|---|---|
|
|
グローバル・スクリプトを削除する場合は、Recovery Managerが仮想プライベート・カタログに接続していないことが必要です。仮想カタログのユーザーは、グローバル・スクリプトを実行できますが、変更することはできません。 関連項目: グローバル・スクリプトとローカル・スクリプトの違いについては、「使用上の注意」を参照してください。 |
|
|
削除するスクリプトの名前を指定します。スクリプト名に空白または予約語が含まれている場合は、引用符で囲む必要があります。 |
この例では、リカバリ・カタログからグローバル・スクリプトbackup_dbを削除します（例には出力例も含まれます）。
RMAN> LIST SCRIPT NAMES;
List of Stored Scripts in Recovery Catalog
Scripts of Target Database PROD
Script Name
Description
-----------------------------------------------------------------------
backup_whole
backup whole database and archived redo logs
Global Scripts
Script Name
Description
-----------------------------------------------------------------------
global_backup_db
back up any database from the recovery catalog, with logs
RMAN> DELETE GLOBAL SCRIPT global_backup_db;
deleted global script: global_backup_db
RMAN> LIST SCRIPT NAMES;
List of Stored Scripts in Recovery Catalog
Scripts of Target Database PROD
Script Name
Description
-----------------------------------------------------------------------
backup_whole
backup whole database and archived redo logs
DROP CATALOGコマンドを使用すると、リカバリ・カタログまたは仮想プライベート・カタログを削除できます。
このコマンドは、Recovery Managerプロンプトでのみ実行してください。
CATALOGコマンドライン・オプションまたはCONNECT CATALOGコマンドを使用して、リカバリ・カタログ・スキーマまたは仮想プライベート・カタログに接続している必要があります。リカバリ・カタログ・データベースはオープンの状態である必要があります。
ターゲット・データベースへの接続は不要です。
DROP CATALOGコマンドを実行すると、この操作を実行することを確認するためにコマンドを再度入力するよう求められます。
基本リカバリ・カタログはCREATE CATALOGで作成されますが、仮想プライベート・カタログはCREATE VIRTUAL CATALOGで作成されます。基本リカバリ・カタログを削除するには、リカバリ・カタログ所有者としてリカバリ・カタログ・データベースに接続し、DROP CATALOGを実行します。
仮想プライベート・カタログを削除するには、その仮想プライベート・カタログに接続しているときにDROP CATALOGコマンドを実行します。仮想プライベート・カタログに接続しているときにDROP CATALOGコマンドを実行しても、基本リカバリ・カタログ自体は削除されません。削除されるのは、基本カタログを参照するシノニムおよびビューのみです。
リリースが10.2以前のRecovery Managerクライアントを使用している場合に仮想カタログを削除するには、別の方法を使用する必要があります。仮想プライベート・カタログを削除する前に、リカバリ・カタログ・データベースに仮想プライベート・カタログの所有者として接続し、次のPL/SQLプロシージャを実行してください（base_catalog_ownerは、基本リカバリ・カタログを所有するデータベース・ユーザーです）。
base_catalog_owner.DBMS_RCVCAT.DROP_VIRTUAL_CATALOG
基本リカバリ・カタログを削除すると、仮想プライベート・カタログは削除していなくても使用できなくなります。ただし、専任データベース・ユーザーが仮想プライベート・カタログを所有している場合は、DROP USER ...CASCADEを実行して、その仮想カタログを削除できます。
データベース・ユーザーvpu1に属する仮想プライベート・カタログを削除するとします。ただし、その基本リカバリ・カタログは削除しません。この例では、リカバリ・カタログ・データベースにvpu1として接続し、このユーザーの仮想プライベート・カタログを削除します。仮想プライベート・カタログを削除しても、その基本リカバリ・カタログは影響を受けません。
RMAN> CONNECT CATALOG vpu1@catdb
recovery catalog database Password: password
connected to recovery catalog database
RMAN> DROP CATALOG;
recovery catalog owner is VPU1
enter DROP CATALOG command again to confirm catalog removal
RMAN> DROP CATALOG;
virtual catalog dropped
DROP DATABASEコマンドを使用すると、ターゲット・データベースを削除できます。Recovery Managerがリカバリ・カタログに接続している場合、そのデータベースの登録も同時に解除できます。Recovery Managerは、ターゲット・データベースに属するすべてのデータファイル、オンラインREDOログおよび制御ファイルを削除します。デフォルトでは、Recovery Managerによって確認のプロンプトが表示されます。
このコマンドは、Recovery Managerプロンプトでのみ実行してください。ターゲット・データベースに接続している必要があります。ターゲット・データベースは、排他的にマウントされ、オープンされていない状態で、RESTRICTモードで起動されている必要があります。
この例では、リカバリ・カタログに登録されているtest1というテスト・データベースを削除します。Recovery Managerクライアントを起動し、TARGETとしてデータベースtest1に接続して、リカバリ・カタログに接続します。その後、次のコマンドを実行して、ターゲット・データベース・ファイルと、データベースに関連付けられているすべてのバックアップ、コピーおよびアーカイブ・ログを削除します。
RMAN> CONNECT TARGET SYS@test1
target database Password: password
connected to target database: TEST1 (DBID=39525561)
RMAN> STARTUP FORCE MOUNT
RMAN> SQL 'ALTER SYSTEM ENABLE RESTRICTED SESSION';
RMAN> DROP DATABASE INCLUDING BACKUPS NOPROMPT;
DUPLICATEコマンドを使用すると、ソース・データベースのコピーを作成できます。Recovery Managerで作成できるのは、次のいずれかのタイプのデータベースです。
Recovery Managerでは、複製処理をオープンまたはマウントされているデータベースから直接実行することも、既存のRecovery Managerバックアップおよびコピーから実行することもできます。
Recovery Managerは、ソース・データベースにTARGETとして接続されている必要があります。ソース・データベースは、コピーされるデータベースです。ソース・データベースはマウントまたはオープン状態である必要があります。スタンバイ・データベースは、ソース・データベースにはできません。
Recovery Managerは、複製データベースのインスタンスにAUXILIARYとして接続されている必要があります。複製データベースのインスタンスは、補助インスタンスと呼ばれます。補助インスタンスは、NOMOUNTオプションで起動されている必要があります。
ソース・データベースと複製データベースのプラットフォームは、同じである必要があります。DUPLICATEの処理では、プラットフォームが同じ32ビット・バージョンと64ビット・バージョンは、同じプラットフォームとみなされます。たとえば、Linux IA (32-bit) LittleとLinux IA (64-bit) Littleは、同じプラットフォームとみなされます。ただし、32ビットと64ビットのプラットフォーム間でデータベースの複製が終了したら、utlirp.sqlスクリプトを実行して、PL/SQLコードを新しい形式に変換する必要があります。このスクリプトは、LinuxおよびUNIXプラットフォームのORACLE_HOME/rdbms/adminにあります。
DUPLICATEコマンドを実行するには、構成済または割当て済の補助チャネルが1つ以上必要です。これらのチャネルは、補助データベース・インスタンスで複製処理を実行します。Recovery Managerは、ソース・データベースにTARGETとして接続されている必要があります。次のような場合、Recovery Managerはソース・データベースのチャネル構成を補助チャネルに使用します。
CONNECT文字列を使用するように自動ターゲット・チャネルを構成した場合は、Recovery Managerが補助インスタンスのチャネルに同じチャネル構成を使用しようとします。かわりに、補助チャネルを手動で割り当てることをお薦めします。
ソース・ホストは、ソース・データベースが格納されているデータベースです。トランスポート先ホストは、複製データベースが作成されるデータベースです。複製データベースをソース・ホストに作成する場合は、DUPLICATEコマンドの実行時に、ソース制御ファイルが使用中であることが原因でエラーが発生しないように、CONTROL_FILES初期化パラメータを適切に設定してください。また、ソース・データベース・ファイルが複製データベース・ファイルで上書きされないように、すべての*_DEST初期化パラメータも適切に設定してください。
COMPATIBLE初期化パラメータが11.0.0以上に設定されている場合、デフォルトでは、トランスポート後に読み書き両用に設定されていなかったトランスポータブル表領域が複製されます。それ以外の場合、Recovery Managerでは、トランスポート後に読み書き両用に設定されていないかぎり、トランスポータブル表領域は複製できません。
列レベルで機能する透過的データ暗号化と表領域暗号化のデータベース暗号化機能のいずれにも、ウォレットが使用されています。次の制限事項に注意してください。
FROM ACTIVE DATABASEを指定せずにDUPLICATEを実行する場合、補助チャネルは1つ以上必要ですが、ソース・データベースに通常のチャネルは必要ありません。
バックアップからデータベースを複製する場合は、複製データベースの作成とリカバリに使用するすべてのバックアップおよびアーカイブREDOログに、トランスポート先ホストのサーバー・セッションからアクセスできる必要があります。トランスポート先ホストとソース・ホストが同じでない場合は、ソース・ホストのディスク上のバックアップを、ソース・データベースでのフルパス名と同じフルパス名で、トランスポート先ホストから使用できるようにする必要があります。
FROM ACTIVE DATABASEを指定してDUPLICATEを実行する場合、1つ以上の通常のターゲット・チャネルおよび1つ以上のAUXILIARYチャネルが必要です。
補助データベース・インスタンスに接続する際は、ネット・サービス名を指定する必要があります。この要件は、補助インスタンスがローカル・ホストに存在する場合にも適用されます。ソース・データベースと補助インスタンスは、同じSYSDBAパスワードを使用する必要があります。したがって、両方のインスタンスにパスワード・ファイルが存在している必要があります。補助インスタンスを起動してソース・データベースから接続できるように、パスワードを1つにしてパスワード・ファイルを作成できます。
パスワード・ファイルに対するDUPLICATEの動作は、複製データベースがスタンバイ・データベースとして動作するかどうかで異なります。作成する複製データベースがスタンバイ・データベースでない場合、デフォルトでは、Recovery Managerはパスワード・ファイルをコピーしません。PASSWORD FILEオプションを使用すると、補助インスタンス上の既存のパスワード・ファイルを上書きするようにRecovery Managerに指定できます。
スタンバイ・データベースを作成すると、デフォルトでは、Recovery Managerがパスワード・ファイルをスタンバイ・ホストにコピーするため、既存のパスワード・ファイルは上書きされます。その場合は、PASSWORD FILE句は必要ありません。
ソース・データベースはマウントまたはオープン状態である必要があります。ソース・データベースがオープン状態の場合は、アーカイブ処理を有効にする必要があります。ソース・データベースがオープンされておらず、それがスタンバイ・データベースでもない場合は、一貫性を保った状態で停止されていたことが必要です。
アクティブなデータベースの複製を実行する場合は、UNTIL句を使用できません。Recovery Managerは、データファイルを一貫性のとれた時点にリカバリできるように、オンライン・データファイルが完全にコピーされた時間を選択します。
アクティブなデータベース複製では、補助サービス名を使用して、ソース・データベースがネットワーク経由でトランスポート先ホストの補助インスタンスにコピーされますが、バックアップベースの複製では、すでに存在するRecovery Managerバックアップおよびコピーが使用されます。表2-6に、ソース・データベースから複製されるファイルを示します。
| ソース・データベースのファイル | アクティブなデータベース | バックアップベース |
|---|---|---|
|
制御ファイル |
|
|
|
データファイル |
ソース・データベースからコピーされます（ |
バックアップからリストアされます（ |
|
一時ファイル |
再作成されます（「一時ファイルの再作成」を参照）。 |
再作成されます（「一時ファイルの再作成」を参照）。 |
|
オンラインREDOログ・ファイル |
再作成されます。 |
再作成されます。 |
|
スタンバイREDOログ・ファイル |
プライマリ・データベース上で |
プライマリ・データベース上で |
|
アーカイブREDOログ・ファイル |
ソース・データベースからコピーされます（ただし、複製に必要な場合のみ）。 |
バックアップまたはカタログ化済のコピーから取得されます（ただし、複製に必要な場合のみ）。 |
|
サーバー・パラメータ・ファイル |
ソース・データベースからコピーされます（「dupOptionList」の |
|
|
フラッシュバック・ログ・ファイル |
再作成されません。 |
再作成されません。 |
|
ブロック・チェンジ・トラッキング・ファイル |
再作成されません。 |
再作成されません。 |
|
パスワード・ファイル |
スタンバイ・データベースの場合はデフォルトでコピーされ、非スタンバイのデータベースでは、 |
再作成されません。 |
|
フラッシュ・リカバリ領域のバックアップおよび他のファイル |
コピーされません。 |
コピーされません。 |
データファイルがオフラインである場合または除外されている場合を除き、複製データベースにはすべてのデータファイルが格納されます。表領域を除外するには、SKIP句を使用するか、またはDUPLICATE ... TABLESPACEを使用して表領域のサブセットのみを含めます。
フラッシュ・リカバリ領域を明示的に定義している場合は、複製データベースまたはスタンバイ・データベース上でこの領域が定義されます。また、ソース・データベース上でフラッシュ・リカバリが定義されており、DUPLICATEコマンドを使用してコピーまたはリストアされたサーバー・パラメータ・ファイルを補助インスタンスで使用しているときは、複製データベースまたはスタンバイ・データベース上でフラッシュ・リカバリが定義されます。
アクティブなデータベース複製を使用する場合は、「dupsbyOptionList」にあるFROM ACTIVE DATABASEの説明を参照してください。使用上の注意は、「dupOptionList」を参照してください。
NOARCHIVELOGモードのデータベースをバックアップベースで複製する場合は、メディア・リカバリにNOREDOオプションが使用されます。したがって、増分バックアップが存在していると、Recovery Managerは、リカバリ時には、その増分バックアップのみをリストアされたファイルに適用します。ARCHIVELOGモードのデータベースをバックアップベースで複製する場合、デフォルトでは、Recovery Managerによってそのコマンドが実行された時点で最後に作成されたアーカイブREDOログまで、またはSET UNTIL句で指定した時点までリカバリされます。
バックアップベースの複製を使用している場合で、ソース・ベータベースと補助インスタンスが別々のホストに存在する場合は、ソース・データベースのバックアップが補助インスタンスから使用できるようにする方法を決定する必要があります。
ターゲット・データベースで、ASMストレージのリカバリ領域が使用されていない場合は、DUPLICATEコマンドを実行する前に、次のいずれかのタスクを実行します。
ソース・データベースでASMストレージのリカバリ領域が使用されている場合は、DUPLICATEコマンドを実行する前に、次のいずれかのタスクを実行します。
TARGETとして接続されている状態で、バックアップに対してCATALOGを実行します。
ソース・データベース・ファイルがOracle Managed Files（OMF）形式の場合は、初期化パラメータのDB_FILE_NAME_CONVERTおよびLOG_FILE_NAME_CONVERT、またはfileNameConversionSpec句を使用して、複製データベースの新しいOMFファイル名を生成することはできません。OMFファイル名は一意であり、Oracleデータベースによって生成されます。
このルールの唯一の例外は、ASMディスク・グループ名のみを変更する場合です。ソース・データファイルおよびオンラインREDOログ・ファイルが、ASMディスク・グループ+SOURCEDSKに格納されているとします。複製データベース・ファイルは、ASMディスク・グループ+DUPDSKに格納することにします。その場合、初期化パラメータを次のように設定できます。
DB_FILE_NAME_CONVERT = ("+SOURCEDSK","+DUPDSK") LOG_FILE_NAME_CONVERT = ("+SOURCEDSK","+DUPDSK")
Recovery Managerは、DB_FILE_NAME_CONVERTまたはLOG_FILE_NAME_CONVERTを使用してディスク・グループ名を変換し、その名前に基づいた有効なファイル名を新しく生成します。
ソース・ファイルがOracle Managed Files形式の場合にデータファイルの名前を付けるオプションとしては、次のサポート・オプションがあります。
NEWNAMEを使用すると、個々のデータファイルの名前を指定できます。
DB_FILE_CREATE_DESTを設定すると、新しいデータベースのすべてのデータファイルをOracle Managed Filesにできます（ただし、SET NEWNAMEが使用されるファイルは除きます）。DB_FILE_CREATE_DESTを設定する場合は、DB_FILE_NAME_CONVERTを設定しないでください。
Oracle Managed Filesから複製されるオンラインREDOログに名前を付けるサポート・オプションには、DB_CREATE_FILE_DEST、DB_RECOVERY_FILE_DESTおよびDB_CREATE_ONLINE_LOG_DEST_nがあります。
Oracle Managed FilesにDUPLICATEを使用する場合は、データベースをプライマリ・データベースとしてオープンするか、読取り専用でオープンするときのいずれかの時点で、Recovery Managerが現行のDB_CREATE_FILE_DESTで一時ファイルを再作成します。Oracle Managed Filesを使用しない場合は、DB_FILE_NAME_CONVERTを使用して、新しいデータベースの一時ファイル名を変換します。スタンバイ・データベースまたは複製データベースを読取り専用または読み書き両用モードでオープンする場合、Oracleでは、必要に応じてDB_FILE_NAME_CONVERTに基づいた変換名で一時ファイルが自動作成されます。一時ファイルごとに異なる名前を指定するには、「SWITCH TEMPFILE」を参照してください。
（dupsbyOptionList::=、dupOptionList::=）
（fileNameConversionSpec::=、setParameter::=）
（deviceSpecifier::=、fileNameConversionSpec::=、logSpec::=、setParameter::=、untilClause::=）
この句を使用すると、データベースまたは表領域を複製できます。構文は、duplicate::=図を参照してください。
| 構文の要素 | 説明 |
|---|---|
|
|
複製対象のデータベースをスタンバイ・データベースとして使用するように指定します（ 例2-75を参照）。
スタンバイ・データベース上のオンラインREDOログのファイル名の変換には、
Recovery Managerをスタンバイ・データベースに接続してから、
注意:
Recovery Managerをスタンバイ・データベースに接続し、そのプライマリ・データベースがすでに登録されているリカバリ・カタログに接続すると、スタンバイ・データベースは、Recovery Managerによって認識され、暗黙的に登録されます。スタンバイ・データベースには、 |
|
スタンバイ・データベースの作成時にのみ適用するオプションを指定します。「dupsbyOptionList」を参照してください。 |
|
|
|
複製データベースの名前を指定します。この複製データベースは、スタンバイ・データベースにできません。
複製データベースがソース・データベースと同じOracleホームにある場合、ソース・データベースと複製データベースに同じデータベース名は使用できません。ただし、複製データベースがソース・データベースとは別のOracleホームにある場合は、そのOracleホームにある他のデータベース名と異なっていれば、同じ名前でも使用できます。複製データベースの管理を容易にするために、ソース・データベースと複製データベースを別の名前にすることをお薦めします。 |
|
スタンバイ・データベースではない複製データベースの作成時にのみ適用するオプションを指定します。「dupOptionList」を参照してください。 |
この副次句は、スタンバイ・データベースの作成時にのみ適用するオプションを指定します。構文は、dupsbyOptionList::=図を参照してください。
| 構文の要素 | 説明 |
|---|---|
|
|
スタンバイ・データベースの作成後に、Recovery Managerがそのスタンバイ・データベースをリカバリするように指定します。untilClauseを指定すると、Recovery Managerは、指定されたSCNまたは時点までリカバリし、データベースをマウント状態のままにします。 Recovery Managerは、メディア・リカバリの完了後にスタンバイ・データベースをマウント状態のままにしますが、スタンバイ・データベースを手動リカバリ・モードおよび管理リカバリ・モードには設定しません。Recovery Managerがスタンバイ・データベースを作成した後、スタンバイ・データベースを手動リカバリ・モードまたは管理リカバリ・モードに設定したり、読取り専用モードでオープンする前に、すべてのギャップ・シーケンスの問題を解決する必要があります。
制御ファイルのチェックポイントSCNは、スタンバイ・サイトから使用できるかRecovery Managerバックアップに含まれるアーカイブREDOログに含める必要があります。たとえば、スタンバイ制御ファイルを作成し、その直後に順序が100の現行ログをアーカイブするとします。この場合、スタンバイ制御ファイルのバックアップはその時点以後にとられるため、少なくともログ順序100までスタンバイ・データベースをリカバリしないと、データベースから |
|
スタンバイ・データベースで元のデータファイル名を新しいデータファイル名に変換する方法を指定します。 関連項目: 「fileNameConversionSpec」を参照してください。 |
|
|
|
スタンバイ・データベースのファイルは、ソース・データベースのバックアップからではなく、ソース・データベースから直接提供されるように指定します（例2-71を参照）。 関連項目: コマンドの前提条件については、「アクティブなデータベースの複製に固有の前提条件」を参照してください。 |
|
|
ソース・データベースのデータファイルが、使用中のスタンバイ・データベース・ファイルと同じ名前を共有しているかどうかを、Recovery Managerでチェックしないようにします。
スタンバイとプライマリのデータファイルおよびオンラインREDOログのファイル名が同じ場合は、
関連項目: 「dupOptionList」にある |
|
|
ソース・データベースのサーバー・パラメータ・ファイルを、スタンバイ・データベースにコピーします。コピー先の場所は、このファイルに対するオペレーティング・システム固有のデフォルトの場所です。
Recovery Managerは、サーバー・パラメータ・ファイルを使用してスタンバイ・データベース作成用の補助インスタンスを起動します。
|
|
指定された初期化パラメータを指定された値に設定します。「setParameter」を参照してください。 |
|
|
最初の文字列に一致するすべての初期化パラメータ値を、2番目の文字列で置換します。
注意: |
この副次句には、複製時の各種機能（ファイルの名前付け、複製のエンド・ポイントの決定など）を制御するオプションが含まれます。構文は、dupOptionList::=図を参照してください。
複製データベースのファイル名がソース・データベースのファイル名と異なる必要がある場合（トランスポート先ホストとソース・ホストが同じである場合など）は、データファイルとオンラインREDOログに新しいファイル名を指定するか、ソース・データベースのファイル名を変換します。複製データベースのオンラインREDOログおよびデータファイルにファイル名を指定しないと、Recovery Managerではソース・データベースのデータファイル名が使用されます。
| 構文の要素 | 説明 |
|---|---|
|
|
指定したデバイス（
このオプションが有効なのは、構成済の自動チャネルがあり、チャネルを手動で割り当てていない場合のみです。たとえば、自動ディスクおよびテープ・チャネルをCONFIGUREして 関連項目: 「deviceSpecifier」を参照してください。 |
|
ソース・データベースのファイル名を複製データベースのファイル名にマップする1つ以上のパターンを指定します（例2-72を参照）。
指定リストのファイルが
注意: SPFILE句を指定した場合に、 関連項目: 「fileNameConversionSpec」を参照してください。 |
|
|
|
複製データベースのファイルは、ソース・データベースのバックアップからではなく、ソース・データベースから直接提供されるように指定します（例2-70を参照）。 関連項目: コマンドの前提条件については、「アクティブなデータベースの複製に固有の前提条件」を参照してください。 |
|
|
スタンバイ・データベースではない複製データベースを作成するときのオンラインREDOログ作成のオプションを指定します（例2-72を参照）。 |
|
|
指定されたインスタンスのオンラインREDOログをReal Applications Cluster（Oracle RAC）データベースに作成します。インスタンス名は、最大80文字の文字列です。
Recovery Managerは、指定されたインスタンスにマップされたスレッドを自動的に使用します。
この句は、 |
|
オンラインREDOログ・ファイルのファイル名およびグループを指定します。 関連項目: 有効なオプションについては、「logSpec」を参照してください。 |
|
|
|
ソース・データベース・ファイルが複製データベース・ファイルと同じ名前を共有するときに、ソース・データベースのデータファイルおよびオンラインREDOログ・ファイルが使用中であるかどうかのチェックを、Recovery Managerでチェックしないようにします（例2-73を参照）。複製操作によって有用なデータが上書きされないかどうかを確認するのは、ユーザーの責任です。
このオプションが必要になるのは、ディスク構成、ディレクトリ構造およびファイル名がソース・データベースのホストと同じであるが、それとは別のホストに複製データベースを作成する場合です。たとえば、 /oracle/dbs/system_prod1.dbf
このデータベースを
ソース・データベースと同じホストにデータベースを複製する場合は、 RMAN-10035: exception raised in RPC: ORA-19504: failed to create file |
|
|
SQL文 |
|
|
補助インスタンスで現在使用されているパスワード・ファイルを、ソース・データベースのパスワード・ファイルで上書きするように指定します（例2-70を参照）。このオプションは、
|
|
|
補助インスタンスで使用するテキストベースの初期化パラメータ・ファイルを指定します（例2-72を参照）。Recovery Managerでは、複製中に補助インスタンスが自動的に停止され、再起動されます。デフォルトの場所にあるサーバー・パラメータ・ファイルを補助インスタンスで使用しない場合は、補助インスタンスの起動時にRecovery Managerで使用するテキストベースの初期化パラメータ・ファイルを指定する必要があります。初期化パラメータ・ファイルは、複製の実行に使用するRecovery Managerクライアントと同じホストに存在する必要があります。
デフォルトの場所にあるサーバー・パラメータ・ファイルを補助インスタンスで使用する場合は、 |
|
|
現行の読取り専用表領域にあるデータファイルを複製データベースから除外します（例2-73を参照）。デフォルトでは、Recovery Managerは現在の読取り専用表領域を複製します。 表領域は現在読み書き両用に設定されていますが、untilClauseを使用して表領域が読取り専用であったSCNにデータベースを複製する場合、Recovery Managerはこの表領域を複製データベースに含めません。過去に読取り専用であった表領域は、オフラインの表領域とみなされるため、複製には含まれません。
注意: スキップした読取り専用表領域のレコードは、 |
|
|
指定した表領域を複製データベースから除外します（例2-72を参照）。
ソース・データベースのバックアップの一部が存在しない場合にそのデータベースを複製するには、
Recovery Managerでは、完全かどうかはチェックされません。たとえば、データ表領域は複製できますが、データの索引を含む表領域や、パーティション表の1パーティションのみを含む表領域は複製できません。 |
|
|
サーバー・パラメータ・ファイルをソース・データベースから複製データベースにコピーします。「dupsbyOptionList」の |
|
指定された初期化パラメータを指定された値に設定します。「setParameter」を参照してください。 |
|
|
最初の文字列に一致するすべての初期化パラメータ値を、2番目の文字列で置換します。「dupsbyOptionList」の |
|
|
|
指定したデータベースに入れる表領域を指定します。複製データベースから除外する表領域を指定する
注意: |
|
|
リストア・ポイントを作成した時点のSCNを上限として、バックアップベースの複製のリストア・ポイントを指定します。指定した値は含まれます。上限値が含まれるため、Recovery Managerは、対応するSCN以前のデータベースの複製に使用できるファイルのみを選択します。
注意: untilClauseに適用される制約と同じものが、 |
|
バックアップベースの複製のPoint-in-Timeリカバリの終了時刻、SCNまたはログ順序番号を設定します。（例2-72を参照）。
関連項目: 「untilClause」を参照してください。 |
この副次句は、サーバー・パラメータ・ファイルの値を指定します。
| 構文の要素 | 説明 |
|---|---|
|
|
指定された初期化パラメータを指定された値に設定します（例2-71を参照）。
この
注意: |
|
|
パラメータ設定のオプションのコメントを指定します。 |
この副次句では、スタンバイ・データベースではない複製データベースを作成するときのオンラインREDOログを指定します。構文図は、logSpec::=図を参照してください。
LOGFILE句を指定しない場合、Recovery ManagerはLOG_FILE_NAME_CONVERTが設定されていれば、それを使用します。LOGFILEもLOG_FILE_NAME_CONVERTも設定しなければ、Recovery Managerは複製データベースのREDOログ・ファイルにソース・データベースのREDOログ・ファイル名を使用します。この場合は、NOFILENAMECHECKオプションを指定する必要があります。
データベースprod1を基にしてテスト・データベースを新しいホストに作成するとします。新しいホストのディレクトリ構造はソース・ホストと同じであるため、複製データベースのファイルには、ソース・データベースのファイルと同じ名前を使用できます。データベースは、Recovery Managerバックアップを使用せずに作成でき、複製中もprod1をオープン状態のままにしておくことができます。
prod1でサーバー・パラメータ・ファイルが使用されている場合は、任意の値に設定されたDB_NAMEパラメータのみを含む初期化パラメータ・ファイルをトランスポート先ホストに作成できます。補助インスタンスを起動する前に、ソース・データベースと同じSYSDBAパスワードを使用するパスワード・ファイルを作成する必要があります。補助インスタンスは、その後で起動します。
デフォルトでは、Recovery Managerはスタンバイ・データベースではない複製データベースを作成するときにパスワード・ファイルを複製しません。PASSWORD FILEオプションを指定すると、Recovery Managerはパスワード・ファイルをトランスポート先ホストにコピーします。ソース・データベースで使用可能なすべてのパスワードを複製データベースに組み込む場合は、PASSWORD FILEオプションを使用します。
補助チャネルを構成する必要はありません。Recovery Managerは、ソース・データベースに構成された通常のチャネルを使用してデータベース・ファイルをコピーします。Recovery Managerを起動し、ソース・データベース・インスタンスおよび補助データベース・インスタンスに次のように接続して、データベースを複製します。
% rman
RMAN> CONNECT TARGET SYS@prod1
target database Password: password
connected to target database: PROD1 (DBID=39525561)
RMAN> CONNECT AUXILIARY SYS@dup1
auxiliary database Password: password
connected to auxiliary database: DUP1 (not mounted)
RMAN> DUPLICATE TARGET DATABASE TO dup1
2> FROM ACTIVE DATABASE
3> PASSWORD FILE
4> SPFILE;
例2-71 アクティブなデータベース複製でのサーバー・パラメータ・ファイルのコピー
データベースprod1を基にしてスタンバイ・データベースを新しいホストに作成するとします。トランスポート先ホストとソース・ホストはディレクトリ構造が異なるため、スタンバイ・データベース・ファイルは、/disk1ではなく/disk2に保存されます。スタンバイ・データベースは、Recovery Managerバックアップを使用せずに作成でき、複製中もprod1をオープン状態のままにしておくことができます。
最初に実行するのは、スタンバイ・データベース用に必要最小限の初期化パラメータ・ファイルを作成することです。次に、スタンバイ・インスタンスを起動します。このパラメータ・ファイルは、必要最小限のものとします。それは、SPFILEオプションを使用すると、サーバー・パラメータ・ファイルが新規ホストにコピーされ、各種パラメータが新しい指定値に設定されるためです。
Recovery Managerクライアントを起動し、CONNECTを実行してTARGETとしてソース・データベースに接続して、補助インスタンスに接続します。補助チャネルを構成する必要はありません。Recovery Managerは、ソース・ホストの通常のチャネルを使用してデータベース・ファイルをコピーします。次のコマンドを入力できます。
DUPLICATE TARGET DATABASE TO dup1
FOR STANDBY
FROM ACTIVE DATABASE
PASSWORD FILE
SPFILE
PARAMETER_VALUE_CONVERT '/disk1', '/disk2'
SET DB_FILE_NAME_CONVERT '/disk1','/disk2'
SET LOG_FILE_NAME_CONVERT '/disk1','/disk2'
SET SGA_MAX_SIZE 200M
SET SGA_TARGET 125M;
例2-72 複製用の新しいファイル名の手動設定
host1上のソース・データベースを、host2上のnewdbに複製するとします。
この使用例では、ソース・データベースでサーバー・パラメータ・ファイルが使用されていません。テキストベースの初期化パラメータ・ファイルをhost2上に作成し、インスタンスを起動します。
host2でDUPLICATEを実行する場合は、PFILEパラメータを使用して、初期化パラメータ・ファイルの場所を指定する必要があります。Recovery Managerクライアントは、複製データベースの初期化パラメータ・ファイルと同じホストで使用する必要があることに注意してください。
表領域のexampleとhistoryは、複製データベースに含めないことにします。したがって、これらの表領域については、DUPLICATE ...SKIP TABLESPACEを指定します。また、複製データベースの状態は、24時間前の本番データベースと同じにします。したがって、DUPLICATE ...UNTIL TIMEを使用します。
この例は、ソース・データベースのデータファイルがhost1のディレクトリ/h1/oracle/dbs/trgtに存在していることを前提としています。データファイルは、ディレクトリ/h2/oracle/oradata/newdbに複製するため、DUPLICATE ...DB_FILE_NAME_CONVERTで複製データファイルの名前を生成するように指定します。複製データベース内のオンラインREDOログ・ファイルの名前は、DUPLICATE ...LOGFILEを使用して指定します。
host2上でRecovery Managerクライアントを起動し、CONNECTを実行してTARGETとしてソース・データベースに接続して、補助インスタンスに接続します。次のRUNコマンドを入力できます。
RUN
{
ALLOCATE AUXILIARY CHANNEL newdb DEVICE TYPE sbt;
DUPLICATE TARGET DATABASE TO newdb
PFILE ?/dbs/initNEWDB.ora
UNTIL TIME 'SYSDATE-1' # specifies incomplete recovery
SKIP TABLESPACE example, history # skip desired tablespaces
DB_FILE_NAME_CONVERT ('/h1/oracle/dbs/trgt/','/h2/oracle/oradata/newdb/')
LOGFILE
GROUP 1 ('?/oradata/newdb/redo01_1.f',
'?/oradata/newdb/redo01_2.f') SIZE 4M,
GROUP 2 ('?/oradata/newdb/redo02_1.f',
'?/oradata/newdb/redo02_2.f') SIZE 4M,
GROUP 3 ('?/oradata/newdb/redo03_1.f',
'?/oradata/newdb/redo03_2.f') SIZE 4M REUSE;
}
例2-73 複製データベースでのソース・データベースのファイル名の使用
Recovery Managerバックアップを使用して、テスト用の複製データベースを作成するとします。条件は、次のとおりです。
Recovery Managerクライアントを起動し、CONNECTを実行してTARGETとしてソース・データベースに接続して、補助インスタンスに接続します。次のコマンドを入力できます。
DUPLICATE TARGET DATABASE TO ndbnewh
LOGFILE
'?/dbs/log_1.f' SIZE 4M,
'?/dbs/log_2.f' SIZE 4M
SKIP READONLY
NOFILENAMECHECK;
例2-74 同じディレクトリ構造を持つスタンバイ・データベースの作成
Recovery Managerバックアップを使用して、ソース・ホストと同じディレクトリ構造を持つリモート・ホストにスタンバイ・データベースを作成するとします。ソース・データベースはprod1と呼ばれ、Data Guard環境のプライマリ・データベースになります。
最初に、Recovery Managerクライアントを起動し、CONNECTを実行してTARGETとしてソース・データベースprod1に接続して、補助インスタンスに接続します。次に、CONFIGUREを実行して、DB_UNIQUE_NAMEがstandby1のスタンバイ・データベースのデフォルトのデバイス・タイプをsbtに構成できます。
CONFIGURE DEFAULT DEVICE TYPE sbt FOR DB_UNIQUE_NAME standby1;
CONFIGURE DEVICE TYPE sbt PARALLELISM 2 FOR DB_UNIQUE_NAME standby1;
スタンバイ・データベースの作成に必要なすべてのバックアップがテープにあるとします。スタンバイ・データベースの初期化パラメータ・ファイルで、DB_UNIQUE_NAMEをstandby1に設定します。
スタンバイ・データベースでは、初期化パラメータ・ファイルのデフォルトの場所が使用されています。スタンバイ・インスタンスNOMOUNTが起動したら、Recovery Managerクライアントを起動し、CONNECTを実行してTARGETとしてソース・データベースに接続して、補助インスタンスとリカバリ・カタログに接続します。次のDUPLICATEコマンドを実行して、NOFILENAMECHECKオプションを指定します（スタンバイとプライマリのデータファイルおよびオンラインREDOログ・ファイルの名前は同じです）。
DUPLICATE TARGET DATABASE FOR STANDBY
NOFILENAMECHECK;
例2-75 OMFおよびASMでのスタンバイ・データベースの作成
Recovery Managerバックアップを使用して、OMFおよびASMを使用するホストにスタンバイ・データベースを作成するとします。ソース・データベースはprod1と呼ばれ、Data Guard環境のプライマリ・データベースになります。
最初に、Recovery Managerクライアントを起動し、CONNECTを実行してTARGETとしてデータベースprod1に接続して、リカバリ・カタログに接続します。次のCONFIGUREコマンドを実行して、DB_UNIQUE_NAMEがstandby1、ネット・サービス名がsby1となるスタンバイ・データベースのデフォルト・デバイス・タイプをsbtに構成します。
CONFIGURE CONNECT IDENTIFIER "sby1" FOR DB_UNIQUE_NAME standby1;
CONFIGURE DEFAULT DEVICE TYPE TO sbt FOR DB_UNIQUE_NAME standby1;
CONFIGURE DEVICE TYPE sbt PARALLELISM 2 FOR DB_UNIQUE_NAME standby1;
スタンバイ・データベースの作成に必要なバックアップは、すべてテープに保存されているとします。データベースstandby1の初期化パラメータ・ファイルで、次のパラメータを設定します。
DB_UNIQUE_NAMEの値をstandby1に設定します。
DB_CREATE_FILE_DESTおよびDB_RECOVERY_FILE_DESTを、スタンバイ・ホスト上の目的のASMディスク・グループに設定します。たとえば、DB_CREATE_FILE_DESTを+DATAFILEに、DB_RECOVERY_FILE_DESTを+FLASH_REC_AREAに設定します。
スタンバイ・インスタンスがNOMOUNTモードであることを確認します。Recovery Managerクライアントを起動し、CONNECTを実行してTARGETとしてデータベースprod1に接続して、AUXILIARYとしてstandby1インスタンスに接続し、リカバリ・カタログに接続します。次のコマンドを入力して、スタンバイ・データベースを作成します。
DUPLICATE TARGET DATABASE FOR STANDBY TO standby1;
リストアされるデータファイルの新しいOMF/ASMデータファイル名は、Recovery Managerで自動的に生成されます。新しいデータベース名とファイル名は、リカバリ・カタログと自動的に再同期されます。
EXECUTE SCRIPTコマンドを使用すると、リカバリ・カタログに格納されているローカルまたはグローバルのRecovery Managerスクリプトを実行できます。
|
関連項目:
|
EXECUTE SCRIPTは、RUNコマンドのカッコ内でのみ使用してください。CATALOGコマンドライン・オプションまたはCONNECT CATALOGコマンドを使用して、Recovery Managerをリカバリ・カタログに接続する必要があります。リカバリ・カタログ・データベースはオープンの状態である必要があります。
RUNブロック内でEXECUTE SCRIPTコマンドを実行すると、Recovery Managerによって、スクリプトの内容がそのRUNブロックのコンテキストに挿入されます。そのため、スクリプト内でチャネルを割り当てている場合は、RUNブロック内でチャネルを割り当てないでください。
GLOBALが指定されている場合は、同じ名前のグローバル・スクリプトがすでにリカバリ・カタログに存在している必要があります。存在していない場合は、エラーRMAN-06004が戻されます。GLOBALを指定しなかった場合は、Recovery Managerによって、現行のターゲット・データベースに対して定義されているローカル・ストアド・スクリプトが検索されます。その名前のローカル・スクリプトが見つからなかった場合は、同じ名前のグローバル・スクリプトが検索され、見つかった場合はそのスクリプトが実行されます。
| 構文の要素 | 説明 |
|---|---|
|
|
ローカル・ストアド・スクリプトのかわりに、グローバル・ストアド・スクリプトを実行するように指定します。 関連項目: グローバル・スクリプトとローカル・スクリプトの違いについては、「使用上の注意」を参照してください。 |
|
|
実行するストアド・スクリプトの名前を指定します。スクリプト名に空白または予約語が含まれている場合は、引用符で囲む必要があります。 |
|
|
ストアド・スクリプト内の置換変数で使用する値を1つ以上指定します（例2-77を参照）。
関連項目: 置換変数を使用するストアド・スクリプトの作成方法については、「CREATE SCRIPT」を参照してください。また、Recovery Managerで置換変数を使用する方法については、 |
この例では、LISTを使用して、リカバリ・カタログに格納されているスクリプトを表示し、PRINT SCRIPTを使用して、例2-59「グローバル・ストアド・スクリプトの作成」で作成されたglobal_backup_dbの内容を表示します。最後に、global_backup_dbを実行して、データベースをバックアップします。
RMAN> LIST SCRIPT NAMES;
List of Stored Scripts in Recovery Catalog
Global Scripts
Script Name
Description
-----------------------------------------------------------------------
global_backup_db
back up any database from the recovery catalog, with logs
RMAN> PRINT SCRIPT global_backup_db;
printing stored global script: global_backup_db
{
BACKUP DATABASE PLUS ARCHIVELOG;
}
RMAN> RUN { EXECUTE GLOBAL SCRIPT global_backup_db; }
executing global script: global_backup_db
Starting backup at 07-JUN-07
current log archived
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=120 device type=DISK
.
.
.
例2-77 置換変数を使用するストアド・スクリプトの作成と実行
Recovery Managerを起動してターゲット・データベースおよびリカバリ・カタログに接続したら、REPLACE SCRIPTを使用して、3つの置換変数が含まれるバックアップ・スクリプトを作成します。Recovery Managerによって、変数の初期値を入力するプロンプトが表示されます（太字がユーザー入力です）。
RMAN> REPLACE SCRIPT backup_df { BACKUP DATAFILE &1 TAG &2.1 FORMAT '/disk1/&3_%U'; }
Enter value for 1: 1
Enter value for 2: df1_backup
Enter value for 3: df1
starting full resync of recovery catalog
full resync complete
created script backup_df
後で、別の値でbackup_df スクリプトを実行できます。次の例では、値3、test_backupおよびtestをストアド・スクリプトの置換変数に渡しています。
RMAN> RUN { EXECUTE SCRIPT backup_df USING 3 test_backup df3; }
値が置換された後、Recovery ManagerによってBACKUPコマンドが次のように実行されます。
BACKUP DATAFILE 3 TAG test_backup1 FORMAT '/disk1/df3_%U';
EXITコマンドを使用すると、Recovery Managerユーティリティを停止できます。このコマンドの機能は、QUITコマンドと同じです。
このコマンドはRecovery Managerプロンプトでのみ実行できます。
この例は、Recovery Managerを終了します。
RMAN> EXIT
FLASHBACK DATABASEコマンドを使用すると、データベースをターゲットの時刻、SCNまたはログ順序番号に戻すことができます。
このコマンドは、その実行時に存在するデータファイルに対してOracle Databaseが加えていた変更をUNDOすることで機能します。フラッシュバックを実行すると、論理的な障害は修正できますが、物理的な障害は修正できません。したがって、このコマンドを使用して、ディスクの障害や誤って削除したデータファイルをリカバリすることはできません。
通常、FLASHBACK DATABASEは、Point-in-Timeリカバリを伴うRESTORE操作よりも非常に短時間で実行できます。これは、指定したフラッシュバック時刻以降にデータベースに対して行われた変更の数によって、FLASHBACK DATABASEの実行に必要な時間が決まるためです。これに対して、リストアされたバックアップに基づく従来のPoint-in-Timeリカバリでは、データベースのサイズによって実行に必要な時間が決まります。
Data Guard環境では、フラッシュバック・データベースの様々な用途が他にもあります。
このコマンドは、Recovery ManagerプロンプトまたはRUNコマンドから実行できます。
Recovery ManagerはTARGETとしてデータベースに接続されている必要があります。また、データベースは、Oracle Database 10g 以降である必要があります。ターゲット・データベースは、現行の制御ファイルを使用してマウント済である必要があります。つまり、バックアップを制御ファイルとすることはできません。また、制御ファイルの再作成もできません。データベースはARCHIVELOGモードで実行されている必要があります。
FLASHBACK DATABASEを使用して、制御ファイルのリストアまたは再作成が行われたときより前に戻すことはできません。データベースの制御ファイルがバックアップからリストアされるか、または再作成されると、既存のすべてのフラッシュバック・ログ情報が破棄されます。
フラッシュ・リカバリ領域は、フラッシュバック・ロギングが有効になるように構成されている必要があります。フラッシュバック・ログは、フラッシュ・リカバリ領域にOracle Managed Filesとして格納され、フラッシュ・リカバリ領域が構成されていない場合は作成されません。SQL文ALTER DATABASE ... FLASHBACK ONを使用して、フラッシュバックのターゲット時刻より前にフラッシュバック・ロギング機能を使用可能にしておく必要があります。フラッシュバック・ロギングが有効になっているかどうかは、V$DATABASE.FLASHBACK_ONを問い合せて確認できます。
データベースには、SQL文ALTER TABLESPACE ... FLASHBACK OFFでフラッシュバック機能が無効にされていたオンライン表領域が含まれていない必要があります。
フラッシュバック・データベースの操作は、データベース全体に適用されます。個々の表領域をフラッシュ・バックすることはできません。フラッシュバック・データベース操作は、RECOVERによって実行される、データベースのPoint-in-Timeリカバリ（DBPITR）に似ていますが、Recovery Managerでは、変更をUNDOして、ターゲットの時刻またはSCNの前の時点に戻すために、フラッシュバック・ログが使用されます。Recovery Managerでは、必要なアーカイブREDOログはバックアップから自動的にリストアされ、一貫性を保すようにデータベースがリカバリされます。一時表領域のデータはフラッシュ・バックされないことに注意してください。
フラッシュバック・データベース操作に使用可能な最も古いSCNは、DB_FLASHBACK_RETENTION_TARGET初期化パラメータの設定と、使用可能なディスク領域の制限の下で実際に保存されているフラッシュバック・ログとによって決まります。V$DATABASE.CURRENT_SCNの現行のデータベースSCNを表示します。
NOLOGGING操作が行われていたターゲット時刻を指定してFLASHBACK DATABASEを使用すると、NOLOGGING操作の影響を受けたデータベース・オブジェクトとデータファイルのブロックが破損している可能性があります。たとえば、NOLOGGINGモードでダイレクト・パスINSERT操作を行い、その操作が4月3日の9:00〜9:15に実行されるとします。後でフラッシュバック・データベースを使用して、その日の09:07に戻す場合、ダイレクト・パスINSERTで更新されたオブジェクトとデータファイルは、フラッシュバック・データベースが終了した後で、破損ブロックが存在するままになる可能性があります。
NOLOGGING操作と重なるターゲット時刻またはSCNを指定してFLASHBACK DATABASE使用することは、可能なかぎり避けてください。また、NOLOGGING操作を実行したら、その直後に、影響を受けたデータファイルの全体バックアップまたは増分バックアップを実行して、操作後の時点へのリカバリが可能になるようにしてください。FLASHBACK DATABASEを使用して、ダイレクト・パスINSERTなどの操作の実行していた時点に戻ることが予想される場合は、その操作をLOGGINGモードで実行することを検討してください。
FLASHBACK DATABASEコマンドを実行しても、すべての必要なファイルおよびリソースがあることが確認されるまで、データベースの変更は開始されません。フラッシュバック・データベース操作は、データファイル、REDOログ・ファイルまたはフラッシュバック・ログの欠落が原因では失敗しません。
データファイルの状態が、現行のSCNとフラッシュバックのターゲットSCNとの間で変化している場合、FLASHBACK DATABASEコマンドの動作は、状態変化の内容によって異なります。詳細は、表2-7を参照してください。
ALTER TABLESPACE ...FLASHBACK OFF文が、複数の表領域に対して実行されていることがあります。FLASHBACK DATABASEの実行時に、表領域をターゲットSCNに戻せるだけのフラッシュバック・データがない場合は、Recovery Managerによってエラーが発行され、データベースは変更されません。FLASHBACK DATABASEが失敗するかまたは中断された場合、データベースは必ずマウントされたままになります。
この使用例では、V$TABLESPACEを問い合せて、フラッシュバック・ロギングが無効になっている表領域を特定します。次の選択肢があります。
ALTER DATABASE DATAFILE ...OFFLINE FOR DROP文を使用して、該当するデータファイルを削除します。これで、RESETLOGSオプションでデータベースをオープンできます。データベースがオープン状態になったら、削除したデータファイルが含まれていた表領域に対してDROP TABLESPACE文を実行します。
FLASHBACK DATABASEの実行後に、データベースが、ターゲット時刻の直前のSCNの状態ではない場合があります。データベースのSCNは、トランザクション以外のイベントによって更新される場合があります。FLASHBACK DATABASE TOのコマンド形式を使用する場合に、ターゲットSCNに対応するトランザクションが存在すると、フラッシュバック後のデータベースは、そのトランザクションまでのすべての変更がデータベースに含まれます。そうでない場合は、使用するコマンド形式がFLASHBACK DATABASE TOとFLASHBACK DATABASE TO BEFOREのどちらであるかには関係なく、そのトランザクションの直前までのすべての変更がデータファイルに含まれます。FLASHBACK DATBASEの処理として、指定したターゲットSCNより後の変更が適用されることはありません。
FLASHBACK DATABASEが終了したら、データベースを読取り専用でオープンし、問合せを実行して、意図した結果が得られていることを確認してください。結果が期待どおりでなかった場合は、RECOVER DATABASEを実行して、フラッシュバック操作を開始した時点の状態にデータベースをリカバリすることができます。それから、FLASHBACK DATABASEを再度実行できます。
フラッシュバックの結果が期待どおりだった場合、OPEN RESETLOGSを実行して、ターゲット時刻より後の変更をすべて破棄できます。そのかわりに、失ったデータをデータ・ポンプでエクスポートし、RECOVER DATABASEを使用してデータベースをフラッシュ操作の前の状態に戻してから、失ったデータをデータ・ポンプで再インポートすることもできます。
| 構文の要素 | 説明 |
|---|---|
|
|
指定したデバイス・タイプ専用の自動チャネルを割り当てます。たとえば、自動ディスクおよびテープ・チャネルを構成して 関連項目: 「deviceSpecifier」を参照してください。 |
|
|
指定したSCNの直前の状態へデータベースを戻します。指定した時点より以前のSCNまでのすべての変更が適用されますが、指定したSCNに対応する変更が存在する場合、その変更は適用されません。デフォルトでは、指定されたSCNで現在のインカネーションまたは祖先のインカネーションが解決されます。デフォルトは、RESET DATABASE
フラッシュバックの可能な最も小さなSCNは、 |
|
|
REDOログ順序番号とスレッドを上限として指定します。Recovery Managerは、指定した順序番号およびスレッド番号のログの最後の変更（は含まない）までの変更を適用します。 |
|
|
データベースの状態を、最後に
注意: |
|
|
指定した時刻より前までのすべての変更を含む状態にデータベースを戻します（指定した時刻の変更は含まれません）。
フラッシュバックが可能な最も古い時刻は、 |
|
|
指定したSCNの時点（を含む）までデータベースを戻します。デフォルトでは、指定されたSCNで現在のインカネーションまたは祖先のインカネーションが解決されます。Recovery ManagerのRESET DATABASEコマンドを使用してリカバリ・ターゲット・インカネーションの設定を行うと、デフォルトをオーバーライドできます。
フラッシュバックの可能な最も小さなSCNは、 |
|
|
REDOログ順序番号とスレッドを上限として指定します。Recovery Managerは、指定した順序番号およびスレッド番号のログの最後の変更（を含む）までの変更を適用します。 |
|
|
指定したリストア・ポイントに対応するSCNまでデータベースを戻します。通常のリストア・ポイントまたは保証付きリストア・ポイントを指定できます。 |
|
|
指定した時刻の状態へデータベースを戻します。現行の形式への時刻の変換には、SQLのすべての
フラッシュバックが可能な最も古い時刻は、 |
2月14日の午後5時に、破損したデータベースを多くの表に挿入したとします。SQL*Plusをデータベースに接続して、フラッシュバック・ウィンドウの最も古いSCNを問い合せます。
SQL> SELECT OLDEST_FLASHBACK_SCN, OLDEST_FLASHBACK_TIME
2 FROM V$FLASHBACK_DATABASE_LOG;
OLDEST_FLASHBACK_SCN OLDEST_FLASHBACK
-------------------- ----------------
411010 2007/02/14 16:49
次に、新しい端末を開いて、Recovery Managerクライアントを起動し、ターゲット・データベースとリカバリ・カタログに接続します。次のようにRecovery Managerコマンドを入力します（例には、FLASHBACK DATABASEの出力例が含まれます）。
RMAN> SHUTDOWN IMMEDIATE
RMAN> STARTUP MOUNT
RMAN> FLASHBACK DATABASE TO SCN 411010;
Starting flashback at 15-FEB-07
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=104 device type=DISK
starting media recovery
media recovery complete, elapsed time: 00:00:07
Finished flashback at 15-FEB-07
RMAN> ALTER DATABASE OPEN RESETLOGS;
例2-80 リストア・ポイントへのFLASHBACK DATABASE
データベースに大量の更新をロードする準備をしているとします。更新を実行する前に、保証付きリストア・ポイントを作成します。
SQL> CREATE RESTORE POINT before_update GUARANTEE FLASHBACK DATABASE;
バルク更新が失敗し、データベースに大量の破損データが残りました。Recovery Managerセッションを起動し、ターゲット・データベースとリカバリ・カタログに接続して、保証付きリストア・ポイントをリストします。
RMAN> LIST RESTORE POINT ALL;
SCN RSP Time Type Time Name
---------------- --------- ---------- --------- ----
412742 GUARANTEED 15-FEB-07 BEFORE_UPDATE
データベースをマウントして、リストア・ポイントにフラッシュバックし（例には出力例も含まれます）、RESETLOGSオプションを使用してデータベースをオープンします。
RMAN> SHUTDOWN IMMEDIATE
RMAN> STARTUP MOUNT
RMAN> FLASHBACK DATABASE TO RESTORE POINT 'BEFORE_UPDATE';
Starting flashback at 15-FEB-07
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=104 device type=DISK
starting media recovery
archived log for thread 1 with sequence 34 is already on disk as file /disk2/oracle/oradata/prod/arch/archive1_34_614598462.dbf
media recovery complete, elapsed time: 00:00:01
Finished flashback at 15-FEB-07
RMAN> ALTER DATABASE OPEN RESETLOGS;
GRANTコマンドを使用すると、仮想プライベート・カタログ・スキーマに対する権限をデータベース・ユーザーに割り当てることができます。デフォルトでは、仮想カタログのユーザーは基本リカバリ・カタログにアクセスできません。
このコマンドは、Recovery Managerプロンプトで実行してください。
CREATE CATALOGを使用して基本リカバリ・カタログが作成されていなければ、GRANTで仮想プライベート・カタログの権限を割り当てることはできません。
基本リカバリ・カタログを作成し、そこにすべてのデータベースのメタデータを格納することをお薦めします。その後に、仮想プライベート・カタログ・スキーマを所有するOracle Databaseユーザーを作成できます。仮想プライベート・カタログのユーザーは、RECOVERY_CATALOG_OWNERロールを付与されている必要があります。
Recovery Managerを基本リカバリ・カタログに接続し、GRANTコマンドを使用して、リカバリ・カタログ権限を仮想カタログの所有者に割り当てます。その後、CREATE VIRTUAL CATALOGを実行して、このユーザーの仮想カタログ・スキーマを作成します。REVOKEを使用すると、カタログ権限を取り消すことができます。
ここで、GRANTの使用方法を説明します。データベースprod1およびprod2が、基本リカバリ・カタログに登録されているとします。基本リカバリ・カタログにSYSとしてログインしている状態で、仮想プライベート・カタログの2人のユーザー（vpc1およびvpc2）を作成します。この両方のユーザーに、データベースprod1に対するCATALOG FOR DATABASEアクセス権を付与します（prod2については付与しません）。
この例では、基本リカバリ・カタログの所有者によって作成されたprod1のバックアップのメタデータには、vpc1とvpc2の両方がアクセスできます。相互に作成したprod1のバックアップのメタデータには、両方のユーザーがアクセスできます。データベースprod2のバックアップ・メタデータには、vpc1とvpc2の両方ともアクセスできません。
REGISTER DATABASEをユーザーに付与すると、このユーザーが登録したすべてのデータベースに対して暗黙的にリカバリのCATALOG FOR DATABASE権限が付与されます。あるユーザー（virtcatなど）のREGISTER DATABASE権限のみに対してREVOKEを実行した場合、virtcatが登録したデータベース（prodなど）のCATALOG FOR DATABASE権限が暗黙的に取り消されることはありません。CATALOG FOR DATABASE権限にはprodの登録権限が含まれているため、virtcatは、prodの登録解除と登録を継続できます。virtcatがprodに対する操作（prodの再登録を含む）を実行できないようにするには、virtcatからREVOKE ALL PRIVILEGESを実行します。
| 構文の要素 | 説明 |
|---|---|
|
|
指定したデータベースのリカバリ・カタログへのアクセス権を指定したユーザーに付与します。 注意: 指定したデータベースで付与されるカタログ操作には、そのデータベースの登録と登録解除が含まれます。 データベースは、データベース名またはDBIDで指定します。名前で指定した場合、その名前のデータベースがカタログに複数登録されていると、Recovery Managerによりエラーが戻されます。その場合は、DBIDでデータベースを指定してください。
リカバリ・カタログに登録済のデータベースへのアクセス権を付与するには、 |
|
|
指定したユーザーに、リカバリ・カタログで現在認識されていないデータベースをREGISTER DATABASEで登録する権限を付与します。
たとえば、ユーザー |
データベース・ユーザーrcoがデータベース catdbに基本リカバリ・カタログを所有しているとします。この基本リカバリ・カタログには、データ・センター内の数多くのデータベースのRecovery Managerメタデータが格納されています。目標は、データ・センターの2人のバックアップ・オペレータのために、仮想プライベート・カタログを作成することです。
SQL*Plusを起動し、SYSとしてcatdbデータベースに接続します。次に、CREATE USER文を使用して、catdb上にbckop2およびbckop3ユーザーを作成します。次のように、リカバリ・カタログの所有権をこれらのユーザーに付与できます。
SQL> GRANT recovery_catalog_owner TO bckop2, bckop3;
SQL> EXIT
次に、Recovery Managerクライアントを起動し、ユーザーrcoとしてリカバリ・カタログ・データベースに接続します。Recovery ManagerのGRANTコマンドを使用して、bckop2に、自分の仮想プライベート・カタログにすべてのデータベースを登録する権限を与えます。ただし、bckop3には、データ・センター内のデータベースのサブセットのみへのアクセス権を与えます。
RMAN> CONNECT CATALOG rco@catdb
recovery catalog database Password: password
connected to recovery catalog database
RMAN> GRANT REGISTER DATABASE TO bckop2;
RMAN> GRANT CATALOG FOR DATABASE prod TO bckop3;
RMAN> GRANT CATALOG FOR DATABASE prodb TO bckop3;
RMAN> EXIT;
新しいRecovery Managerセッションを開始し、bckop2の仮想カタログを作成します（例には、CREATE VIRTUAL CATALOGの出力例も含まれます）。仮想カタログを作成するたびに、Recovery Managerを終了して再起動する必要があります。
RMAN> CONNECT CATALOG bckop2@catdb
recovery catalog database Password: password
connected to recovery catalog database
RMAN> CREATE VIRTUAL CATALOG;
found eligible base catalog owned by RCO
created virtual catalog against base catalog owned by RCO
RMAN> EXIT;
新しいRecovery Managerセッションを開始し、bckop3の仮想カタログを作成します（例には、CREATE VIRTUAL CATALOGの出力例も含まれます）。
RMAN> CONNECT CATALOG bckop3@catdb
recovery catalog database Password: password
connected to recovery catalog database
RMAN> CREATE VIRTUAL CATALOG;
found eligible base catalog owned by RCO
created virtual catalog against base catalog owned by RCO
RMAN> EXIT;
次の例では、バックアップ・オペレータdba1が、catdbのbckop3スキーマにある自分の仮想プライベート・カタログを使用して、ターゲット・データベースのバックアップのメタデータを格納します。
RMAN> CONNECT TARGET /
RMAN> CONNECT CATALOG bckop3@catdb
recovery catalog database Password: password
connected to recovery catalog database
RMAN> BACKUP DATABASE PLUS ARCHIVELOG;
HOSTコマンドを使用すると、Recovery Manager内からオペレーティング・システムのコマンドラインのサブ・シェルを呼び出すことができます。
このコマンドは、RUNコマンドのカッコ内またはRecovery Managerプロンプトで実行してください。
| 構文の要素 | 説明 |
|---|---|
|
|
コマンド・プロンプトを表示し、ユーザーがサブシェルを終了すると、Recovery Managerを再開します（例2-82を参照）。 |
|
|
指定文字列内のコマンドを実行し、Recovery Managerを継続します（例2-83を参照）。 |
この例では、datafile 3のイメージ・コピーを作成し、Linuxのプロンプトに切り替えて、コピーがディレクトリにあるかどうかをチェックしてから、Recovery Managerセッションを再開します（Linuxセッションの出力は太字のインデント付きで表示されています）。
RMAN> BACKUP DATAFILE 3 FORMAT '/disk2/df3.cpy';
Starting backup at 15-FEB-07
using channel ORA_DISK_1
channel ORA_DISK_1: starting full datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
input datafile file number=00003 name=/disk1/oracle/oradata/prod/undotbs01.d bf
channel ORA_DISK_1: starting piece 1 at 15-FEB-07
channel ORA_DISK_1: finished piece 1 at 15-FEB-07
piece handle=/disk2/df3.cpy tag=TAG20070215T111326 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01
Finished backup at 15-FEB-07
RMAN> HOST;
% ls /disk2/df3.copy
/disk2/df3.cpy
% exit
exit
host command complete
RMAN>
例2-83 Recovery Manager内でのオペレーティング・システム・コピーの実行
この例では、データファイルsystem01.dbfのバックアップを作成してから、Linuxのlsコマンドを実行して、/disk2ディレクトリのすべてのファイルを表示します。
BACKUP DATAFILE '?/oradata/prod/system01.dbf'
FORMAT '/disk2/system01.dbf';
HOST 'ls -lt /disk2/*';
IMPORT CATALOGコマンドを使用すると、リカバリ・カタログ・スキーマにあるメタデータを別のカタログ・スキーマにインポートできます。様々なバージョンのカタログ・スキーマを作成し、複数のターゲット・データベースのメタデータを保存する場合は、このコマンドを使用すると、すべてのデータベース用に1つのカタログ・スキーマを保持することができます。
Recovery Managerが、インポート先のリカバリ・カタログ（カタログ・データをインポートする先のカタログ）に接続されている必要があります。このリカバリ・カタログは、仮想プライベート・カタログにはできません。
ターゲット・データベースに接続していなくても、カタログ・スキーマはマージできます。このコマンドは、RUNコマンドのカッコ内またはRecovery Managerプロンプトで実行してください。
ソース・リカバリ・カタログ・スキーマのバージョンは、使用するRecovery Manager実行可能ファイルのバージョンと一致している必要があります。ソース・スキーマのバージョンが低い場合は、カタログ・スキーマを現行バージョンにアップグレードします。ソース・スキーマのバージョンが高い場合は、バージョンの高いRecovery Manager実行可能ファイルで、再度操作を行ってください。
同じ名前のデータベースが、ソース・リカバリ・カタログ・スキーマとインポート先カタログ・スキーマの両方に登録されていないことを確認してください。両方のスキーマに登録されているデータベースがある場合は、UNREGISTERを実行して、そのデータベースのソース・リカバリ・カタログでの登録を解除し、IMPORTコマンドを再実行します。
インポート操作が途中で失敗すると、インポートはロールバックされます。このため、一部のみインポートすることはできません。登録解除の操作は、インポートとは別に行われます。デフォルトでは、インポートが正常に行われると、インポート済のデータベースIDが、ソース・リカバリ・カタログ・スキーマから登録解除されます。
ストアド・スクリプトは、グローバルまたはローカルのいずれかです。スクリプトのインポート時に、インポート先のスキーマにすでにスクリプト名が含まれていることが原因で、グローバル・スクリプトの名前が競合することがあります（ローカル・スクリプトの場合は競合しません）。その場合は、Recovery Managerにより、グローバル・スクリプト名がCOPY OF script_nameに変更されます。たとえば、bp_cmdという名前はCOPY OF bp_cmdに変更されます。
変更後のグローバル・スクリプト名がそれでも一意でない場合は、COPY(2) OF script_nameという名前に変更されます。そのスクリプト名も存在した場合は、スクリプト名がCOPY(3) OF script_nameに変更されます。こうして、スクリプト名が一意になるまで、COPY(n) OFというパターンが継続されます。
| 構文の要素 | 説明 |
|---|---|
|
ソース・リカバリ・カタログの接続文字列を指定します（このカタログは、メタデータがインポートされるカタログです）。 |
|
|
|
ソース・カタログ・スキーマからメタデータをインポートするデータベースのDBIDのリストを指定します（例2-85を参照）。 指定しなかった場合は、Recovery Managerにより、ソース・カタログ・スキーマのすべてのデータベースIDのメタデータがマージされ、インポート先のカタログ・スキーマに入れられます。メタデータがマージされたデータベースが、リカバリ・カタログ・スキーマにすでに登録されていた場合は、エラーが発行されます。 |
|
|
ソース・カタログ・スキーマからメタデータをインポートするデータベースのリストを指定します（例2-85を参照）。 指定しなかった場合は、Recovery Managerにより、ソース・カタログ・スキーマのすべてのデータベースのメタデータがマージされ、インポート先のカタログ・スキーマに入れられます。同じDBIDが両方のリカバリ・カタログに登録されていた場合は、エラーが発行されます。 |
|
|
インポート済のデータベースIDを、ソース・カタログ・スキーマに強制的に保持します。デフォルトでは、インポート済のデータベースIDはソース・リカバリ・カタログ・スキーマから登録解除されます。 |
この例では、ユーザーrcatが所有する10.2のカタログ・スキーマがデータベースinst1に含まれ、ユーザーrcoが所有する11.1のカタログ・スキーマがデータベースcatdbに含まれています。Recovery Managerは、rcatに登録されているすべてのデータベースIDのメタデータを、rcoが所有するリカバリ・カタログにインポートします。rcatに登録されたすべてのターゲット・データベースは登録解除されます。
RMAN> CONNECT CATALOG rco@catdb
recovery catalog database Password: password
connected to recovery catalog database
RMAN> IMPORT CATALOG rcat@prod;
Starting import catalog at 15-FEB-07
source recovery catalog database Password: password
connected to source recovery catalog database
import validation complete
database unregistered from the source recovery catalog
Finished import catalog at 15-FEB-07
例2-85 登録済データベースのサブセットのメタデータのインポート
この例は、例2-84を部分的に変更したものです。リカバリ・カタログ全体をインポートするかわりに、DBIDが1618984270のデータベースのメタデータのみをインポートします。
RMAN> CONNECT CATALOG rco@catdb
recovery catalog database Password: password
connected to recovery catalog database
RMAN> IMPORT CATALOG rcat@inst1 DBID=1618984270;
Starting import catalog at 15-FEB-07
source recovery catalog database Password: password
connected to source recovery catalog database
import validation complete
database unregistered from the source recovery catalog
Finished import catalog at 15-FEB-07
LISTコマンドを使用すると、Recovery Managerリポジトリに記録されているバックアップおよびその他のオブジェクトに関する情報を表示できます。
LISTは、Recovery Managerプロンプトでのみ実行できます。次のいずれかの条件が満たされている必要があります。
LIST FAILUREコマンドを実行していない場合は、ターゲット・データベースがマウントまたはオープン状態である必要があります。Recovery Managerがリカバリ・カタログに接続されていない場合は、ターゲット・データベース・インスタンスが起動されている必要があります。
DBIDが実行されている必要があります。
LIST FAILUREを除くLISTコマンドは、CROSSCHECKおよびDELETEコマンドの実行対象のバックアップおよびコピーを表示します。LIST FAILUREコマンドは、ADVISE FAILUREおよびREPAIR FAILUREコマンドの実行対象となる障害を表示します。
「Data Guard環境でのRecovery Managerのバックアップ」では、Data Guard環境でのRecovery Managerのバックアップ処理方法について説明しています。通常、Recovery Managerでは、環境内の1つのデータベース上で作成されたテープ・バックアップはその環境のすべてのデータベースにアクセス可能であるとみなされますが、ディスク・バックアップは作成元のデータベースのみにアクセス可能であるとみなされます。Data Guard環境では、LISTを実行すると、接続されているターゲット・データベースにアクセス可能なファイルが表示されます。
LISTの出力は、標準出力またはメッセージ・ログのいずれかに対して行われます。同時に両方に出力されることありません。
（listObjectSpec::=、recordSpec::=、maintQualifier::=、forDbUniqueNameOption::=、untilClause::=）
（completedTimeSpec::=、deviceSpecifier::=）
（listObjList::=、listBackupOption::=、archivelogRecordSpecifier::=、foreignlogRecordSpecifier::=）
| 構文の要素 | 説明 |
|---|---|
|
|
リカバリ・カタログに登録されている1つ以上のデータベースの
Recovery Managerは、リカバリ・カタログに接続している必要があります。また、Recovery Managerが、マウントされているかオープンされているターゲット・データベースに接続しているか、またはSET 関連項目: 出力の説明については、表2-27を参照してください。 |
|
|
Recovery Managerリポジトリに登録されているすべてのデータベースの |
|
|
指定された |
|
|
リポジトリ内で
|
|
関連項目: 「listObjectSpec」を参照してください。 |
|
|
関連項目: 「maintQualifier」を参照してください。 |
|
|
関連項目: 「recordSpec」を参照してください。 |
|
|
Data Guard環境の指定した
データベースは
Recovery Managerは、リカバリ・カタログに接続している必要があります。また、Recovery Managerは、マウント済またはオープン状態のターゲット・データベースに接続しているか、SET 関連項目: この句のオプションについては、「forDbUniqueNameOption」を参照してください。 |
|
|
|
データ・リカバリ・アドバイザによって記録された障害をリストします。Recovery Managerが接続しているデータベースは、単一インスタンス・データベースである必要があります。また、フィジカル・スタンバイ・データベース以外である必要があります。 関連項目: 「Oracle RACおよびデータ・リカバリ・アドバイザ」を参照してください。 データ・リカバリ・アドバイザは、データの損失や破損の原因となる幅広い物理的な問題を検出して修復できます。物理的な破損は、通常、I/Oサブシステムのエラーや人為的エラーが原因で発生します。データ・リカバリ・アドバイザは、一部のタイプの論理的な破損については、検出して処理することができません。このタイプの破損については、Oracleサポート・サービスに問い合せる必要があります。 データ・リカバリ・アドバイザでいう障害とは、一連の修復アクションに対応付けられるデータの永続的な破損のことです。データ障害は、各種チェック（データベースまたはその構成要素の状態を評価する診断手順）で検出されます。それぞれのチェックで、1つ以上の障害が診断され、その障害は一連の修復に対応付けられます。
一般的な例としては、
関連項目: |
|
|
ステータスが |
|
|
ステータスが |
|
|
優先順位が |
|
|
優先順位が |
|
|
障害を障害番号で指定します。 |
|
|
クローズされている障害のみをリストします。 |
|
|
指定された障害をリストから除外します。 |
|
|
まとめられた障害を展開してリストします。たとえば、あるファイル内の複数箇所でブロックが破損している場合に |
|
|
関連項目: |
|
|
データベースの名前を指定します。 |
|
関連項目: 「listObjectSpec」を参照してください。 |
|
|
関連項目: 「maintQualifier」を参照してください。 |
|
|
表示するリストを、リポジトリ内のステータスが 関連項目: 「recoverableClause」を参照してください。 |
|
|
関連項目: 「recordSpec」を参照してください。 |
|
|
関連項目: 「untilClause」を参照してください。 |
|
|
|
Recovery Managerリポジトリで認識されているリストア・ポイントを表示します。
関連項目: |
|
|
指定されたリストア・ポイントを表示します。 |
|
|
Recovery Managerリポジトリで認識されているすべてのリストア・ポイントを表示します。 |
|
Data Guard環境の指定した
データベースは Recovery Managerは、リカバリ・カタログに接続している必要があります。また、マウントされているかオープンされているターゲット・データベースに接続していることも必要です。 関連項目: この句のオプションについては、「forDbUniqueNameOption」を参照してください。 |
|
|
|
接続されているリカバリ・カタログのすべてのデータベースに定義されているすべてのグローバル・スクリプトおよびローカル・スクリプトが、コメントとともにリストされます。 リカバリ・カタログに接続している必要がありますが、ターゲット・データベースに接続している必要はありません。 |
|
|
接続されているリカバリ・カタログで定義されているグローバル・スクリプトのみが、コメントとともにリストされます。 リカバリ・カタログに接続している必要がありますが、ターゲット・データベースに接続している必要はありません。 |
|
|
現在のターゲット・データベースで実行できるローカル・スクリプトおよびグローバル・スクリプトがリストされます。 |
この副次句は、リストするオブジェクトのタイプを指定します。
| 構文の要素 | 説明 |
|---|---|
|
|
バックアップ・セット（バックアップ・ピースの詳細も含む）およびプロキシ・コピーに関する情報を表示します。
関連項目: |
|
|
操作するオブジェクトのリストを
注意: 関連項目: 「listObjList」を参照してください。 |
|
バックアップのサマリーまたは詳細情報をリストするかどうかを指定します。 |
|
|
アーカイブREDOログの範囲情報を表示します。 |
|
|
|
データファイルのコピー、アーカイブREDOログおよびアーカイブREDOログのイメージ・コピーに関する情報のみを表示します。デフォルトでは、 |
|
|
操作するオブジェクトのリストを 関連項目: 「listObjList」を参照してください。 |
|
外部アーカイブREDOログの範囲情報を表示します。 |
この副次句は、リカバリ可能なバックアップを指定します。
| 構文の要素 | 説明 |
|---|---|
|
|
表示するリストを、リポジトリ内のステータスが |
|
|
リストア・ポイントを作成した時点のSCNを上限として、リストア・ポイントを指定します。指定した値は含まれます。上限値が含まれるため、Recovery Managerは、リストア・ポイントに対応するSCNまでリカバリできるファイルのみをリストします。 |
|
関連項目: 「untilClause」を参照してください。 |
バックアップのサマリーを出力するか、特定のデータファイルのバックアップをリストするかを指定します。
| 構文の要素 | 説明 |
|---|---|
|
|
各データファイル、アーカイブREDOログ・ファイル、制御ファイルおよびサーバー・パラメータ・ファイルのバックアップをリストします。
関連項目: |
|
|
関連項目: |
出力で表示される情報については、次の表を参照してください。
表2-8 バックアップ・セットのリスト（データファイルのバックアップ・セットの場合）
| 列 | 指定対象 |
|---|---|
|
|
Recovery Managerがリカバリ・カタログに接続している場合、 |
|
|
注意: データファイルのバックアップ・セットにのみ含まれる列。 |
|
|
バックアップのレベル。非増分の場合は 注意: データファイルのバックアップ・セットにのみ含まれる列。 |
|
|
注意: データファイルのバックアップ・セットにのみ含まれる列。 |
|
|
バックアップが行われたデバイスのタイプ（ |
|
|
バックアップの期間。 |
|
|
バックアップ・セットをとった日付と時刻。このフィールドの書式は、 |
|
|
表2-10を参照してください。 |
| 列 | 指定対象 |
|---|---|
|
|
リカバリ・カタログまたはターゲット・データベース制御ファイルにあるバックアップ・ピースの一意の識別子。
Recovery Managerがリカバリ・カタログに接続している場合、
注意: リカバリ・カタログおよび制御ファイルにある |
|
|
バックアップ・ピースの状態。 |
|
|
バックアップ・ピースが圧縮されているかどうか（ |
|
|
バックアップ・セットに適用されるタグ。タグ名には大/小文字区別がなく、すべて大文字で表示されることに注意してください。 |
|
|
バックアップ・ピースのファイル名またはハンドル。バックアップ・ピースがSBTにある場合は、メディアIDが名前とともに表示されます。 |
|
|
サーバー・パラメータ・ファイルがバックアップに含まれます。 |
|
|
注意: この行は、現行の制御ファイルがバックアップに含まれる場合にのみ表示されます。 |
|
|
バックアップ制御ファイルのチェックポイントSCN。指定したSCNより前にREDOレコードに記録されたデータベース変更はすべて、制御ファイルに反映されます。 注意: この行は、現行の制御ファイルがバックアップに含まれる場合にのみ表示されます。 |
|
|
バックアップ制御ファイルのチェックポイントの時刻。指定した時刻より前にREDOレコードに記録されたデータベース変更はすべて、制御ファイルに反映されます。 注意: この行は、現行の制御ファイルがバックアップに含まれる場合にのみ表示されます。 |
| 列 | 指定対象 |
|---|---|
|
|
バックアップされたファイルの数。 |
|
|
バックアップのレベル。非増分の場合は |
|
|
バックアップのタイプ |
|
|
データファイルをバックアップした時点のデータファイルのチェックポイント。このSCNより前のデータベース変更はすべて、ファイルに書き込まれます。指定したSCN以降の変更はファイルに書き込まれません。 |
|
|
データファイルをバックアップした時点のデータファイルのチェックポイント。時刻より前のデータベース変更はすべて、ファイルに書き込まれます。指定した時刻以降の変更はファイルに書き込まれません。 |
|
|
このバックアップ・セットからリストアされており、SET 関連項目: 「SET」を参照してください。 |
| 列 | 指定対象 |
|---|---|
|
|
REDOログのスレッド番号。 |
|
|
アーカイブ・ログのログ順序番号。 |
|
|
アーカイブ・ログ内の最小SCN。 |
|
|
データベースが、この順序番号を持つREDOログに切り替わった時刻。 |
|
|
次のアーカイブ・ログ順序の下位SCN |
|
|
次のアーカイブ・ログ順序の下位の時刻 |
| 列 | 指定対象 |
|---|---|
|
|
リカバリ・カタログまたはターゲット・データベース制御ファイルにあるバックアップ・ピースの一意の識別子。
Recovery Managerがリカバリ・カタログに接続している場合、
注意: リカバリ・カタログおよび制御ファイルにある |
|
|
バックアップ・セット内のバックアップ・ピースの数。 |
|
|
バックアップ・ピースの状態。 |
|
|
バックアップ・ピースのファイル名またはハンドル。バックアップ・ピースがSBTに格納されている場合は、メディアIDも表示されます。 |
| 列 | 指定対象 |
|---|---|
|
|
Recovery Managerがリカバリ・カタログに接続している場合、 |
|
|
コピーされたデータファイルの絶対ファイル番号。 |
|
|
プロキシ・コピーのステータス（ |
|
|
バックアップ・セットをとった日付と時刻。このフィールドの書式は、 |
|
|
プロキシ・コピー制御ファイルのチェックポイントSCN。指定したSCNより前にREDOレコードに記録されたデータベース変更はすべて、制御ファイルに反映されます。 |
|
|
プロキシ・コピー制御ファイルのチェックポイント時刻。指定した時刻より前にREDOレコードに記録されたデータベース変更はすべて、制御ファイルに反映されます。 |
|
|
このバックアップ・セットからリストアされており、 関連項目: SETコマンドを参照してください。 |
|
|
このプロキシ・コピー用のメディア・マネージャのハンドル。オブジェクトがsbtにある場合は、メディアIDも表示されます。 |
|
|
プロキシ・コピーに適用されるタグ。タグ名には大/小文字区別がなく、すべて大文字で表示されることに注意してください。 |
| 列 | 指定対象 |
|---|---|
|
|
Recovery Managerがリカバリ・カタログに接続している場合、 |
|
|
バックアップのタイプ。バックアップ・セット（ |
|
|
増分バックアップの場合は、増分バックアップのレベル（
データファイルの全体バックアップを含むバックアップ・セットの場合は
アーカイブREDOログを含むバックアップ・セットの場合は |
|
|
バックアップの状態。 |
|
|
バックアップが行われたデバイスのタイプ（ |
|
|
バックアップ・セットをとった日付と時刻。このフィールドの書式は、 |
|
|
バックアップ・セット内のバックアップ・ピースの数。 |
|
|
セット内のバックアップ・ピースごとに作成されたコピー数。多重化が実行されていない場合、この数値は |
|
|
バックアップ・セットがRecovery Managerにより圧縮された場合は |
|
|
バックアップ・セットに適用されるタグ。アスタリスク（*）は、バックアップ・ピースのタグが同じバックアップ・セット内で異なることを示します。この状態は、 |
| 列 | 指定対象 |
|---|---|
|
|
リカバリ・カタログまたはターゲット・データベース制御ファイルにあるバックアップ・ピースの一意の識別子。
Recovery Managerがカタログに接続している場合、
注意: リカバリ・カタログおよび制御ファイルにある |
|
|
Recovery Managerがリカバリ・カタログに接続している場合、 |
|
|
バックアップ・セット内のバックアップ・ピースの数。 |
|
|
バックアップ・セット内のこのバックアップ・ピースのコピー数。多重化が実行されていない場合、この数値は |
|
|
バックアップ・ピースの状態。 |
|
|
バックアップが行われたデバイスのタイプ（ |
|
|
バックアップ・ピースのファイル名またはハンドル。ピースがSBTに格納されている場合は、ハンドルおよびメディアIDが表示されます。 |
| 列 | 指定対象 |
|---|---|
|
|
絶対データファイル番号。 |
|
|
Recovery Managerがリカバリ・カタログに接続している場合、 |
|
|
バックアップのタイプ。バックアップ・セット（ |
|
|
バックアップ・レベル。非増分の場合は |
|
|
バックアップの状態。 |
|
|
データファイルをバックアップした時点のデータファイルのチェックポイント。このSCNより前のデータベース変更はすべて、ファイルに書き込まれます。指定したSCN以降の変更はファイルに書き込まれません。 |
|
|
データファイルをバックアップした時点のデータファイルのチェックポイント。時刻より前のデータベース変更はすべて、ファイルに書き込まれます。指定した時刻以降の変更はファイルに書き込まれません。 |
|
|
バックアップ・セット内のバックアップ・ピースの数。 |
|
|
セット内のバックアップ・ピースごとに作成されたコピー数。多重化が実行されていない場合、この数値は |
|
|
バックアップがRecovery Managerにより圧縮された場合は |
|
|
バックアップ・セットに適用されるタグ。アスタリスク（*）は、バックアップ・ピースのタグが同じバックアップ・セット内で異なることを示します。この状態は、 |
| 列 | 指定対象 |
|---|---|
|
|
REDOログのスレッド番号。 |
|
|
アーカイブ・ログのログ順序番号。 |
|
|
アーカイブ・ログ内の最小SCN。 |
|
|
データベースが、この順序番号を持つREDOログに切り替わった時刻。 |
|
|
Recovery Managerがリカバリ・カタログに接続している場合、 |
|
|
バックアップの状態。 |
|
|
バックアップ・セット内のバックアップ・ピースの数。 |
|
|
セット内のバックアップ・ピースごとに作成されたコピー数。多重化が実行されていない場合、この数値は |
|
|
バックアップがRecovery Managerにより圧縮された場合は |
|
|
バックアップ・セットに適用されるタグ。タグ名には大/小文字区別がなく、すべて大文字で表示されることに注意してください。 |
| 列 | 指定対象 |
|---|---|
|
|
制御ファイルのチェックポイントSCN。 |
|
|
アーカイブ・ログのログ順序番号。 |
|
|
Recovery Managerがリカバリ・カタログに接続している場合、 |
|
|
バックアップの状態。 |
|
|
バックアップ・セット内のバックアップ・ピースの数。 |
|
|
セット内のバックアップ・ピースごとに作成されたコピー数。多重化が実行されていない場合、この数値は |
|
|
バックアップがRecovery Managerにより圧縮された場合は |
|
|
バックアップ・セットに適用されるタグ。タグ名には大/小文字区別がなく、すべて大文字で表示されることに注意してください。 |
| 列 | 指定対象 |
|---|---|
|
|
データファイルのコピーを指す一意の識別子。CHANGEコマンドでこの値を使用して、データファイルのコピーの状態を変更します。
Recovery Managerがリカバリ・カタログに接続している場合、
注意: リカバリ・カタログおよび制御ファイルにある |
|
|
コピー元のデータファイルのファイル番号。 |
|
|
コピーの状態。 |
|
|
コピーを取った日付と時刻。このフィールドの書式は、 |
|
|
データファイルのコピーを取った時点のデータファイルのチェックポイント。SCNより前のデータベース変更は、すべてこのデータファイルに書き込まれます。 |
|
|
データファイルのコピーを取った時点のデータファイルのチェックポイント。この時点より前のデータベース変更は、すべてこのデータファイルに書き込まれます。 |
|
|
データファイルのコピーのファイル名。 |
|
|
プロキシ・コピーに適用されるタグ。タグ名には大/小文字区別がなく、すべて大文字で表示されることに注意してください。 |
| 列 | 指定対象 |
|---|---|
|
|
制御ファイルのコピーを指す一意の識別子。CHANGEコマンドでこの値を使用して、コピーの状態を変更します。
Recovery Managerがリカバリ・カタログに接続している場合、
注意: リカバリ・カタログおよび制御ファイルにある |
|
|
コピーの状態。 |
|
|
コピーを取った日付と時刻。このフィールドの書式は、 |
|
|
この制御ファイルのコピーを取った時点の制御ファイルのチェックポイント。 |
|
|
この制御ファイルのコピーを取った時点の制御ファイルのチェックポイント。 |
|
|
制御ファイルのコピーのファイル名。 |
|
|
制御ファイル・コピーに適用されるタグ。タグ名には大/小文字区別がなく、すべて大文字で表示されることに注意してください。 |
| 列 | 指定対象 |
|---|---|
|
|
アーカイブREDOログ・コピーの一意の識別子。CHANGEコマンドでこの値を使用して、コピーの状態を変更します。
Recovery Managerがリカバリ・カタログに接続している場合、
注意: リカバリ・カタログおよび制御ファイルにある |
|
|
REDOログのスレッド番号。 |
|
|
ログ順序番号。 |
|
|
コピーの状態。 |
|
|
データベースが、この順序番号を持つREDOログに切り替わった時刻。 |
|
|
アーカイブREDOログ・コピーのファイル名。 |
| 列 | 指定対象 |
|---|---|
|
|
|
|
|
|
|
|
|
|
|
データベース作成時にデータベースが自動的に生成するデータベース識別番号。 |
|
|
|
|
|
インカネーションが作成されたときのSCN。 |
|
|
インカネーションが作成された時刻。 |
| 列 | 指定対象 |
|---|---|
|
|
ストアド・スクリプトの名前。 |
|
|
スクリプトの作成時に指定したコメント。 |
| 列 | 指定対象 |
|---|---|
|
|
リストア・ポイントのSCN。 |
|
|
|
|
|
保証付きリストア・ポイントの場合は |
|
|
リストア・ポイントが作成された時刻。 |
|
|
リストア・ポイントの名前。 |
| 列 | 指定対象 |
|---|---|
|
|
障害を示す一意の識別子。 |
|
|
障害の優先順位がCRITICALの場合は、データベース全体が使用不可能になるので、すぐに対処する必要があります。通常、CRITICALな障害が発生するとインスタンスが停止し、その後のインスタンスの起動時に障害が診断されます。データベースはCRITICALな障害がすべて修正されるまで使用できません（「ADVISE FAILURE」を参照）。
障害の優先順位が
優先順位が |
|
|
障害の修復ステータス。適切な修復処理が開始されるまで、障害のステータスは |
|
|
障害が診断されたときの日付。 |
|
|
障害の概要。 |
この例では、すべてのバックアップをリストします。出力には、ディスク上の2つのバックアップ・セットが表示されます。1つにはデータファイルが含まれ、もう1つには自動バックアップが含まれます。また、アーカイブREDOログ・ファイルを含む1つのSBTバックアップも表示されます。
RMAN> LIST BACKUP;
List of Backup Sets
===================
BS Key Type LV Size Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ ---------------
200 Full 509.78M DISK 00:01:03 15-FEB-07
BP Key: 202 Status: AVAILABLE Compressed: NO Tag: TAG20070215T171219
Piece Name: /disk2/PROD/backupset/2007_02_15/o1_mf_nnndf_TAG20070215T171219_2xb17nbb_.bkp
List of Datafiles in backup set 200
File LV Type Ckp SCN Ckp Time Name
---- -- ---- ---------- --------- ----
1 Full 421946 15-FEB-07 /disk1/oradata/prod/system01.dbf
2 Full 421946 15-FEB-07 /disk1/oradata/prod/sysaux01.dbf
3 Full 421946 15-FEB-07 /disk1/oradata/prod/undotbs01.dbf
4 Full 421946 15-FEB-07 /disk1/oradata/prod/cwmlite01.dbf
5 Full 421946 15-FEB-07 /disk1/oradata/prod/drsys01.dbf
6 Full 421946 15-FEB-07 /disk1/oradata/prod/example01.dbf
7 Full 421946 15-FEB-07 /disk1/oradata/prod/indx01.dbf
8 Full 421946 15-FEB-07 /disk1/oradata/prod/tools01.dbf
9 Full 421946 15-FEB-07 /disk1/oradata/prod/users01.dbf
BS Key Type LV Size Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ ---------------
201 Full 7.98M DISK 00:00:03 15-FEB-07
BP Key: 203 Status: AVAILABLE Compressed: NO Tag: TAG20070215T171219
Piece Name: /disk2/PROD/backupset/2007_02_15/o1_mf_ncsnf_TAG20070215T171219_2xb19prg_.bkp
SPFILE Included: Modification time: 15-FEB-07
SPFILE db_unique_name: PROD
Control File Included: Ckp SCN: 421968 Ckp time: 15-FEB-07
BS Key Size Device Type Elapsed Time Completion Time
------- ---------- ----------- ------------ ---------------
227 30.50M SBT_TAPE 00:00:11 15-FEB-07
BP Key: 230 Status: AVAILABLE Compressed: NO Tag: TAG20070215T171334
Handle: 0bia4rtv_1_1 Media:
List of Archived Logs in backup set 227
Thrd Seq Low SCN Low Time Next SCN Next Time
---- ------- ---------- --------- ---------- ---------
1 5 389156 15-FEB-07 411006 15-FEB-07
1 6 411006 15-FEB-07 412972 15-FEB-07
1 7 412972 15-FEB-07 417086 15-FEB-07
1 8 417086 15-FEB-07 417114 15-FEB-07
1 9 417114 15-FEB-07 417853 15-FEB-07
1 10 417853 15-FEB-07 421698 15-FEB-07
1 11 421698 15-FEB-07 421988 15-FEB-07
例2-87 バックアップのサマリー・リストの表示
この例では、例2-86でリストされているRecovery Managerのバックアップのサマリーを表示します。
RMAN> LIST BACKUP SUMMARY;
List of Backups
===============
Key TY LV S Device Type Completion Time #Pieces #Copies Compressed Tag
------- -- -- - ----------- --------------- ------- ------- ---------- ---
200 B F A DISK 15-FEB-07 1 1 NO TAG20070215T171219
201 B F A DISK 15-FEB-07 1 1 NO TAG20070215T171219
227 B A A SBT_TAPE 15-FEB-07 1 1 NO TAG20070215T171334
例2-88 ファイルによるバックアップのリスト
この例では、すべてのバックアップをファイル別にグループ化します。データファイルのバックアップのタグ列は、1つのバックアップ・セットにタグの異なるバックアップ・ピースが含まれていることを示しています。アーカイブ・ログ・バックアップのステータス列は、バックアップ・セットが使用できないことを示しています。
RMAN> LIST BACKUP BY FILE;
List of Datafile Backups
========================
File Key TY LV S Ckp SCN Ckp Time #Pieces #Copies Compressed Tag
---- ------- - -- - ---------- --------- ------- ------- ---------- ---
1 329 B F A 454959 16-FEB-07 1 1 NO DF1
2 349 B F A 454997 16-FEB-07 1 1 NO DF2
3 527 B F A 455218 16-FEB-07 1 1 NO FRI_BKP
368 B F A 455022 16-FEB-07 1 1 NO DF3
4 387 B F X 455042 16-FEB-07 1 1 NO DF4
5 407 B F A 455063 16-FEB-07 1 1 NO DF5
6 428 B F A 455083 16-FEB-07 1 2 NO *
7 450 B F X 455103 16-FEB-07 1 1 NO DF7
8 473 B F A 455123 16-FEB-07 1 1 NO DF8
9 497 B F A 455143 16-FEB-07 1 1 NO DF9
List of Archived Log Backups
============================
Thrd Seq Low SCN Low Time BS Key S #Pieces #Copies Compressed Tag
---- ------- ---------- --------- ------- - ------- ------- ---------- ---
1 5 389156 15-FEB-07 227 U 1 1 NO TAG20070215T171334
1 6 411006 15-FEB-07 227 U 1 1 NO TAG20070215T171334
1 7 412972 15-FEB-07 227 U 1 1 NO TAG20070215T171334
1 8 417086 15-FEB-07 227 U 1 1 NO TAG20070215T171334
1 9 417114 15-FEB-07 227 U 1 1 NO TAG20070215T171334
1 10 417853 15-FEB-07 227 U 1 1 NO TAG20070215T171334
1 11 421698 15-FEB-07 227 U 1 1 NO TAG20070215T171334
List of Control File Backups
============================
CF Ckp SCN Ckp Time BS Key S #Pieces #Copies Compressed Tag
---------- --------- ------- - ------- ------- ---------- ---
454974 16-FEB-07 330 A 1 1 NO DF1
421968 15-FEB-07 201 A 1 1 NO TAG20070215T171219
List of SPFILE Backups
======================
Modification Time BS Key S #Pieces #Copies Compressed Tag
----------------- ------- - ------- ------- ---------- ---
15-FEB-07 330 A 1 1 NO DF1
15-FEB-07 201 A 1 1 NO TAG20070215T171219
例2-89 イメージ・コピーのリスト
次の例では、Recovery Managerで認識されるすべてのデータファイル、制御ファイルおよびアーカイブREDOログのコピーのリストを表示します。
RMAN> LIST COPY;
List of Datafile Copies
=======================
Key File S Completion Time Ckp SCN Ckp Time
------- ---- - --------------- ---------- ---------------
618 1 A 16-FEB-07 461057 16-FEB-07
Name: /disk2/PROD/datafile/o1_mf_system_2xdbrg13_.dbf
Tag: TAG20070216T140706
631 2 A 16-FEB-07 461163 16-FEB-07
Name: /disk2/PROD/datafile/o1_mf_sysaux_2xdbzybx_.dbf
Tag: TAG20070216T141109
List of Control File Copies
===========================
Key S Completion Time Ckp SCN Ckp Time
------- - --------------- ---------- ---------------
619 A 16-FEB-07 461133 16-FEB-07
Name: /disk2/PROD/controlfile/o1_mf_TAG20070216T140706_2xdbz5tb_.ctl
Tag: TAG20070216T140706
594 A 16-FEB-07 460650 16-FEB-07
Name: /disk2/PROD/controlfile/o1_mf_TAG20070216T135954_2xdbbz99_.ctl
Tag: TAG20070216T135954
List of Archived Log Copies for database with db_unique_name PROD
=====================================================================
Key Thrd Seq S Low Time
------- ---- ------- - ---------
105 1 5 A 15-FEB-07
Name: /disk1/oradata/prod/arch/archive1_5_614616887.dbf
122 1 6 A 15-FEB-07
Name: /disk1/oradata/prod/arch/archive1_6_614616887.dbf
123 1 7 A 15-FEB-07
Name: /disk1/oradata/prod/arch/archive1_7_614616887.dbf
124 1 8 A 15-FEB-07
Name: /disk1/oradata/prod/arch/archive1_8_614616887.dbf
125 1 9 A 15-FEB-07
Name: /disk1/oradata/prod/arch/archive1_9_614616887.dbf
185 1 10 A 15-FEB-07
Name: /disk1/oradata/prod/arch/archive1_10_614616887.dbf
221 1 11 A 15-FEB-07
Name: /disk1/oradata/prod/arch/archive1_11_614616887.dbf
262 1 12 A 15-FEB-07
Name: /disk1/oradata/prod/arch/archive1_12_614616887.dbf
263 1 13 A 15-FEB-07
Name: /disk1/oradata/prod/arch/archive1_13_614616887.dbf
例2-90 データベース・インカネーションのリスト
この例では、リカバリ・カタログに記録されているすべてのデータベース・インカネーションをリストします。
RMAN> LIST INCARNATION;
List of Database Incarnations
DB Key Inc Key DB Name DB ID STATUS Reset SCN Reset Time
------- ------- -------- ---------------- --- ---------- ----------
78 94 PROD 1619073740 PARENT 1 14-FEB-07
78 79 PROD 1619073740 CURRENT 388003 15-FEB-07
例2-91 障害のリスト
この例では、優先順位に関係なくすべての障害をリストします。ALLを指定しない場合、LIST FAILUREの出力には優先順位がLOWの障害は含まれません。
RMAN> LIST FAILURE ALL;
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
PRINT SCRIPTコマンドを使用すると、ローカルまたはグローバル・ストアド・スクリプトを標準出力またはファイルに出力できます。
PRINT SCRIPTは、Recovery Managerプロンプトでのみ実行できます。Recovery Managerが、ターゲット・データベースとリカバリ・カタログに接続されている必要があります。リカバリ・カタログ・データベースはオープンの状態である必要があります。
指定したスクリプトがローカル・スクリプトである場合は、スクリプトを作成または置換したときに接続していたターゲット・データベースにRecovery Managerを接続する必要があります。
GLOBALを指定しない場合、ローカル・スクリプトまたはグローバル・スクリプトscript_nameが検索され、出力されます。ローカル・スクリプトが検出された場合は、そのスクリプトが出力されます。ローカル・スクリプトが検出されず、グローバル・スクリプトscript_nameが検出された場合は、グローバル・スクリプトが出力されます。
| 構文の要素 | 説明 |
|---|---|
|
|
関連項目: グローバル・スクリプトとローカル・スクリプトの違いについては、「使用上の注意」を参照してください。 |
|
|
出力するスクリプトの名前を指定します。スクリプト名に空白または予約語が含まれている場合は、引用符で囲む必要があります。 |
|
|
出力を標準出力ではなく指定したファイルに送信します。 |
この例では、スクリプトをファイル/tmp/global_backup_db.rmanに出力します。
RMAN> PRINT GLOBAL SCRIPT global_backup_db TO FILE "/tmp/global_backup_db.rman";
例2-93 スクリプトの画面表示
この例では、ストアド・スクリプトを標準出力に出力します（例には出力例も含まれます）。
RMAN> PRINT SCRIPT backup_whole;
printing stored script: backup_whole
{
BACKUP
INCREMENTAL LEVEL 0 TAG backup_whole
FORMAT "/disk2/backup/%U"
DATABASE PLUS ARCHIVELOG;
}
QUITコマンドを使用すると、Recovery Managerユーティリティを停止できます。このコマンドの機能は、EXITコマンドと同じです。
このコマンドはRecovery Managerプロンプトでのみ実行できます。
この例では、Recovery Managerを終了します（例には出力例も含まれます）。
RMAN> QUIT
Recovery Manager complete.
RECOVERコマンドを使用すると、次の個々のタスクのいずれかを実行できます。
リカバリに必要なすべてのREDOまたは増分の変更は、ディスクまたはSBTに存在している必要があります。Recovery Managerでリカバリ中に増分バックアップまたはアーカイブREDOログをリストアする必要がある場合は、構成済の自動チャネルを使用するか、またはそのバックアップを作成したものと同じタイプのチャネルを手動で割り当てる必要があります。
暗号化されている表領域に対してメディア・リカバリを実行する場合は、この表領域のメディア・リカバリを実行するときにOracleウォレットがオープンしている必要があります。暗号化されている表領域については、『Oracle Database管理者ガイド』を参照してください。
RECOVER BLOCKには次の前提条件が適用されます。
ARCHIVELOGモードで実行され、現行の制御ファイルを使用してオープンまたはマウントされている必要があります。
V$DATABASE_BLOCK_CORRUPTIONビューは、ファイルに対して最新のBACKUPまたはBACKUP ...VALIDATEコマンドの実行以降にファイル内で破損としてマークされたブロックを示します。
Recovery Managerでフラッシュバック・ログを検索して破損ブロックの正常なコピーを見つけられるようにする場合は、ターゲット・データベースに対してフラッシュバック・データベースを有効にする必要があります。
デフォルトでは、完全リカバリが実行されます。Point-in-Timeリカバリの場合は、RUNコマンドのRESTOREとRECOVERの両方のコマンドの前にSET UNTILコマンドを入力して、両方のコマンドにUNTILの時刻が適用されるようにすることをお薦めします。データベースのリストア後にSET UNTILを実行すると、ターゲット時刻にデータベースのリカバリを実行できない場合があります。これは、リストア済ファイルのタイムスタンプがターゲット時刻より遅れるためです。不完全リカバリまたはバックアップ制御ファイルを使用したリカバリの後は、RESETLOGSオプションを指定してデータベースをオープンする必要があるので注意してください。
RECOVER BLOCKの場合を除き、Recovery Managerではリカバリに増分バックアップとアーカイブREDOログの両方を使用できます。次の検索順序を使用します。
Recovery ManagerでアーカイブREDOログのリストア先を選択するときは、次の優先順位を使用します。
ARCHIVELOG DESTINATION
LOCATION=USE_DB_RECOVERY_FILE_DESTに設定されているLOG_ARCHIVE_DEST_nパラメータ
LOG_ARCHIVE_DEST_1
Recovery Managerでは、増分バックアップからリストアされなかったデータファイルに増分バックアップを適用できます。増分バックアップのオーバーラップしているレベルが存在する場合は、Recovery Managerによって、最も長い期間をカバーしているレベルが自動的に選択されます。
データファイルのリカバリを行う前に、RESTOREを使用してこれらをリストアする必要があります。リカバリするデータファイルが親インカネーション由来のものである場合、Recovery Managerでは、RESETLOGS操作を介して透過的にリカバリできます。必要に応じて、RECOVERコマンドを使用しても、以前のデータベース・インカネーションからアーカイブ・ログおよび増分バックアップをリストアおよび適用できます。これは、これらのログが以前のリリースのOracleデータベースで生成されている場合も同様です。
OPEN RESETLOGSを使用してリカバリを行う場合は、リカバリに必要なすべてのログが揃っていることを確認します。以前のデータベース・インカネーションでは、バックアップの時点からRESETLOGS SCNより番号が1少ないSCNまでのログが含まれている必要があります。また、このインカネーションの表には、データベース・バックアップの作成時からのRESETLOGS操作の完全な履歴が含まれている必要があります。V$DATABASE_INCARNATIONに完全なメタデータが見つからない場合は、欠落しているインカネーションからアーカイブREDOログにCATALOGを使用して、このメタデータを再作成できます。
|
関連項目:
アーカイブREDOログをリストアするデフォルトの位置については、RESTOREコマンドを参照してください。フラッシュ・リカバリ領域にログをステージングする場合、Recovery Managerは自動的に |
（deviceSpecifier::=、recoverObject::=、recoverOptionList::=）
（recoverObject::=、blockObject::=、recoverOptionList::=）
（dbObject::=、blockObject::=、untilClause::=）
| 構文の要素 | 説明 |
|---|---|
|
|
指定したデバイス・タイプ専用の自動チャネルを割り当てます。たとえば、自動ディスクおよびテープ・チャネルを構成して
注意: チャネルを手動で割り当ててから、 関連項目: 「deviceSpecifier」を参照してください。 |
|
リカバリされるオブジェクトのタイプを指定します。 |
| 構文の要素 | 説明 |
|---|---|
|
リカバリされるオブジェクトのタイプを指定します。 |
|
|
ブロック・メディア・リカバリを使用してリカバリするブロックを指定します。 |
|
|
リカバリ・オプションを指定します。 |
この副次句は、リカバリするファイルを指定します。構文図は、「recoverObject::=」を参照してください。
| 構文の要素 | 説明 |
|---|---|
|
|
ファイルの最近の増分バックアップと同じ時刻またはそれ以前の時刻にロールフォワードするために、増分バックアップを指定したイメージ・コピーに適用します。既存のイメージ・コピーは上書きされ、リカバリ中はファジー状態になります。Recovery Managerでは、イメージ・コピーのリカバリ後に自動バックアップを実行します。
このコマンドを使用すると、データファイル・コピーが更新されますが、このコマンドは、現行のデータファイルのメディア・リカバリではありません。 このコマンドを 次の要件が満たされている必要があります。 操作を適用できる増分バックアップに対象となるコピーが複数ある場合は、Recovery Managerによって、適切なコピーが1つ選択される。 注意: Recovery Managerでは、指定された時刻にリカバリできない場合、エラーではなく警告が発行されます。これは、増分バックアップを使用できないためです。 |
|
|
ロールフォワードするイメージ・コピーを識別するタグ名を指定します。 |
|
|
増分バックアップを指定したデータファイルのイメージ・コピーに適用します（例2-98を参照）。 |
|
関連項目: 「dbObject」を参照してください。 |
|
|
|
メディア・リカバリ開始前に、指定された表領域にあるデータファイルをオフラインにします。これらのファイルは、メディア・リカバリが完了した後もオフラインのままです。 このオプションは、一時データのみが含まれている表領域のリカバリを行わないようにしたり、いくつかの表領域のリカバリを延期する場合に有効です。 |
|
|
注意: 不完全リカバリを実行する場合は、 |
|
|
オフラインにする表領域の名前を指定します。 |
|
|
リストア・ポイントを作成した時点のSCNを上限として、 |
|
1つ以上の表領域で使用する場合、この句は指定された表領域のPoint-in-Timeリカバリ（TSPITR）操作を示します。また、 関連項目: 「untilClause」を参照してください。 |
この副次句は、データベースまたはデータベースのサブセットのいずれのリカバリを行うのかを指定します。構文図は、「dbObject::=」を参照してください。
| 構文の要素 | 説明 |
|---|---|
|
|
データベース全体のリカバリを指定します（例2-97を参照）。データベースはマウントする必要がありますが、オープンはしないでください。
デフォルトでは、 制御ファイルを失った後にリカバリを行う場合は、ディスク上のデータファイルの実際の位置を指すように制御ファイルを自動的に更新します（例2-99を参照）。 注意: Recovery Managerは、データファイルの追加用のREDOを検出すると、追加されるデータファイルを含む表領域がリカバリ中にスキップされないかぎり、新しいデータファイルを自動的に作成します。この自動作成は、バックアップの制御ファイルがリカバリされる前にリストアされ、バックアップの制御ファイルに最近追加されたデータファイルのレコードが存在しない場合に実行されます。 |
|
|
リカバリする1つ以上のデータファイルのリストをファイル名または絶対データファイル番号で指定します。ターゲット・データベースはマウントまたはオープン状態である必要があります。データベースがオープン状態の場合は、リカバリするデータファイルがオフラインである必要があります。 リカバリ・カタログを使用していない場合、ファイル名は制御ファイルに記録されているデータファイルの名前にする必要があります。リカバリ・カタログを使用している場合、制御ファイル内の名前が最近更新されたとしても、データファイルのファイル名はカタログに記録された最新の名前にする必要があります。たとえば、制御ファイルでデータファイルの名前が変更されたが、カタログを再同期化する前にインスタンスで障害が発生したとします。この場合、RECOVERコマンドでは、データファイルの古い名前を指定してください。この名前がカタログに記録されているためです。 注意: データベース全体をある1つの時点にリカバリしたり、表領域をデータベースの残りの表領域とは異なるある時点にリカバリ（TSPITR）することはできますが、個々のデータファイルを異なる時点へ任意にリカバリすることはできません。TSPITRの詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』で説明する手順を参照してください。 関連項目: 「datafileSpec」を参照してください。 |
|
|
リカバリする1つ以上の表領域のリストを指定します（例2-95と例2-96を参照）。ターゲット・データベースはマウントまたはオープン状態である必要があります。データベースがオープン状態の場合は、リカバリする表領域がオフラインである必要があります。 注意: Recovery Managerは、データファイルの追加に対するREDOを検出すると、新しいデータファイルを自動的に作成します。この自動作成は、バックアップの制御ファイルがリカバリされる前にリストアされ、バックアップの制御ファイルに最近追加されたデータファイルのレコードが存在しない場合に実行されます。 |
この副次句は、リカバリを必要とするデータ・ブロックを指定します。構文図は、「blockObject::=」を参照してください。ブロック・メディア・リカバリに固有の前提条件については、「前提条件」を参照してください。
RECOVER CORRUPTION LISTを使用してV$DATABASE_BLOCK_CORRUPTIONビューに示されたすべてのブロックをリカバリするか、またはデータファイル番号とブロック番号または表領域とデータ・ブロック・アクセス（DBA）を指定できます。個々のブロックについて実行できるのは、完全リカバリのみです。
| 構文の要素 | 説明 |
|---|---|
|
|
このビューには、ブロックとセグメント間の関係を検証して検出できても、個々のブロックのチェックでは検出できない破損については記録されません。
注意: ブロックが修復されたことを確定または検出するRecovery Managerコマンドはいずれも、 |
|
|
データファイル内の個々のデータ・ブロックまたはその集合をリカバリします。 ブロック・メディア・リカバリは、データ消失や破損がデータファイル全体ではなく少数のブロックに適用される場合に役立ちます。通常、ブロックの破損はADVISE FAILUREコマンドまたはトレース・ファイル内のエラー・メッセージによってレポートされます。ブロック・レベルのデータ消失の原因は、次のとおりです。
recoverOptionListからオプションを指定しない場合に、データベースでフラッシュバック・データベースが有効化されているときは、 メディア破損マークが付いているブロックには、リカバリが完了するまでアクセスできません。 注意: 個々のブロックについて実行できるのは、完全リカバリのみです。つまり、すべてのREDOをブロックに適用する前に、リカバリを停止することはできません。 関連項目: 「datafileSpec」を参照してください。 |
|
|
破損ブロックを含む表領域の名前または番号、および破損ブロックのデータ・ブロック・アドレス（DBA）を指定します。ブロック・メディア・リカバリの実行対象は、破損ブロックのみです。 注意: データファイルのヘッダー・ブロック（ブロック1）はリカバリできません。 |
この副次句は、各種のリカバリ・オプションを指定します。構文図は、「recoverOptionList::=」を参照してください。
| 構文の要素 | 説明 |
|---|---|
|
|
リカバリ処理中に許容可能な破損ブロックの数を指定できます。REDOログが破損した場合に備えて、このパラメータを設定できます。
試行リカバリでこの句を使用する（ |
|
|
リカバリ中に使用するアーカイブ・ログ・バックアップ用のタグを指定します。タグ名には大/小文字区別がなく、すべて大文字で表示されます。リカバリに必要なすべてのアーカイブREDOログがタグ付きのバックアップに含まれていなければ、Recovery Managerは使用可能なバックアップから必要に応じてログまたは増分バックアップを使用します。 |
|
|
個々のファイルに対して別の位置が明示的に指定されていない場合は、TSPITRの実行中に作成される補助セットのデータファイル、制御ファイルおよびオンラインREDOログの位置を指定します。
TSPITRで 関連項目: 補助セットの宛先の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』 のTSPITRに関する章を参照してください。 |
|
|
物理的な破損チェックを通過したデータ・ブロックと索引ブロックについて、論理的な破損がないかどうかをテストします。たとえば、行ピースまたは索引エントリの破損がないかどうかを調べます。Recovery Managerは論理的な破損を発見すると、
SET
あるファイルで検出された物理的な破損と論理的な破損の合計数が |
|
|
不要になったバックアップまたはコピーからリストアされたアーカイブ・ログを削除します。Recovery Managerは、
注意:アーカイブREDOログをフラッシュ・リカバリ領域にリストアする場合、デフォルトで |
|
|
リストアされたアーカイブREDOログには、 |
|
|
リストアするブロックを見つける場合にフラッシュバック・ログを検索しないように指定します。デフォルトでは、フラッシュバック・データベースが有効である場合に、Recovery Managerでフラッシュバック・ログを検索します。 |
|
|
バックアップ・セットのみをリストアするように指定します。 |
|
|
データファイル・イメージ・コピーのみをリストアするように指定します。 |
|
|
リカバリ中に使用する増分バックアップ用のタグを指定します。リカバリに必要なすべての増分がタグ付きのバックアップに含まれていなければ、Recovery Managerは使用可能なバックアップから必要に応じてログまたは増分バックアップを使用します。タグ名には大/小文字区別がなく、すべて大文字で表示されます。 関連項目: 多重化バックアップ・セットの個別コピーにタグを適用する方法と、バックアップ・タグのデフォルトのファイル名形式については、「BACKUP」を参照してください。 |
|
|
メディア・リカバリをパラレルで実行しないように指定します。 |
|
|
リカバリ中のREDOログの適用を抑止します。増分バックアップのみを適用します。
このオプションは、増分バックアップを使用して
注意:
また、スタンバイ・データベースまたは複製データベースを更新する場合も使用できます。 |
|
|
デフォルトでは、データベースでパラレルのメディア・リカバリを使用して、メディア・リカバリのロールフォワード・フェーズのパフォーマンスを向上させます。パラレル・リカバリのデフォルトの動作をオーバーライドするには、
パラレル・メディア・リカバリでは、データベースは、ロールフォワード時に各種プロセスを様々なデータ・ブロックに割り当てる分業体制をとるため、操作がより効率的に行われます。プロセスの数は 通常、リカバリはデータ・ブロックに対する読取りと書込み時にI/Oバウンドとなります。ブロック・レベルでパラレル化すると、リカバリによりI/O合計が増加する場合に、非同期I/Oでのオペレーティング・システム制限をなくすことなどによって、リカバリのパフォーマンスが改善されます。効率的な非同期I/Oが行われるシステムでは、パラレル・メディア・リカバリを使用してもあまりメリットはありません。
注意:
関連項目: 『Oracle Database SQL言語リファレンス』の |
|
|
各パラレル・スレッドでは、1つまたは2つのパラレル実行サーバーを使用します。通常、並列度は指定する必要がありません。 |
|
|
リカバリから読取り専用ファイルを除外します。 |
|
|
試行リカバリは、標準リカバリの手順で問題が発生した場合に役立ちます。試行リカバリを使用すると、データベースでREDOの適用後を予測し、発生する可能性のある問題を検出できます。試行リカバリでは、標準リカバリと同じ方法でREDOを適用しますが、ディスクへの変更書込みは行わず、試行リカバリの終了時に変更をロールバックします。
注意: 最後の |
|
|
ターゲット時刻にUNDOセグメントを持つ表領域のリストを指定します。 TSPITR中は、Recovery ManagerではTSPITRターゲット時刻にUNDOセグメントがあったのはどの表領域かという情報が必要です。通常、この情報は、リカバリ・カタログを使用している場合はそのリカバリ・カタログにあります。
リカバリ・カタログがないか、リカバリ・カタログ内に情報がない場合、Recovery Managerでは、ターゲット時刻にUNDOセグメントを持つ一連の表領域が現在UNDOセグメントを持つ一連の表領域と同一であるとみなされます。この想定が正しくない場合、TSPITRは失敗してエラーが戻されます。この場合は、 |
|
|
Recovery Managerがリカバリに必要なファイルのリストアに使用できるバックアップをレポートして検証します（リストアは行いません）。
関連項目: |
表領域usersのデータファイルを格納しているディスクが、ハードウェアのエラーが原因で使用できなくなり、数分後に修復されたとします。この例では、表領域usersをオフラインにし、自動チャネルを使用してデータファイルをデフォルト位置にリストアしてリカバリ（テープからリストアされたログを削除）してから、この表領域をオンラインに戻します。
SQL "ALTER TABLESPACE users OFFLINE IMMEDIATE";
RESTORE TABLESPACE users;
RECOVER TABLESPACE users DELETE ARCHIVELOG MAXSIZE 2M;
SQL "ALTER TABLESPACE users ONLINE";
例2-96 リストアしたデータファイルの新しい位置へのリカバリ
この例では、事前構成済のディスク・チャネルを使用し、ディスク上のデータファイルのコピーおよびテープのバックアップを使用するために1つのメディア管理チャネルを手動で割り当て、表領域usersにあるデータファイルの1つを別の位置にリストアします。
RUN
{
ALLOCATE CHANNEL ch1 DEVICE TYPE sbt;
SQL "ALTER TABLESPACE users OFFLINE IMMEDIATE";
SET NEWNAME FOR DATAFILE '/disk1/oradata/prod/users01.dbf'
TO '/disk2/users01.dbf';
RESTORE TABLESPACE users;
SWITCH DATAFILE ALL;
RECOVER TABLESPACE users;
SQL "ALTER TABLESPACE users ONLINE";
}
例2-97 バックアップ制御ファイルとリカバリ・カタログを使用したDBPITRの実行
すべてのデータファイル、制御ファイルおよびアーカイブREDOログ58が、ディスク障害により消失したと仮定します。また、増分バックアップを取っていないと仮定します。使用可能なアーカイブREDOログでデータベースをリカバリする必要があります。表領域toolsは、最後にバックアップが実行される前から読取り専用であったため、リストアする必要はありません。Recovery Managerをターゲット・データベースおよびリカバリ・カタログに接続した後は、次のコマンドを発行します。
STARTUP FORCE NOMOUNT;
RUN
{
SET UNTIL SEQUENCE 40 THREAD 1; # Recover database until log sequence 40
RESTORE CONTROLFILE;
ALTER DATABASE MOUNT;
RESTORE DATABASE SKIP TABLESPACE temp;
RECOVER DATABASE SKIP TABLESPACE temp;
}
ALTER DATABASE OPEN RESETLOGS;
Recovery Managerは、データファイル8（読取り専用表領域のデータファイル）のリストアおよびリカバリを自動的にスキップします。出力例の次の部分がスキップを示します。
using channel ORA_DISK_1
allocated channel: ORA_SBT_TAPE_1
channel ORA_SBT_TAPE_1: SID=104 device type=SBT_TAPE
channel ORA_SBT_TAPE_1: Oracle Secure Backup
skipping datafile 8; already restored to file /disk1/oradata/prod/tools01.dbf
channel ORA_DISK_1: starting datafile backup set restore
.
.
.
Finished restore at 19-FEB-07
Starting recover at 19-FEB-07
using channel ORA_DISK_1
using channel ORA_SBT_TAPE_1
datafile 8 not processed because file is read-only
例2-98 バックアップの増分更新
バックアップを増分更新することによって、データベースのイメージ・コピーの全体バックアップに伴うオーバーヘッドを避けると同時に、データベースのメディア・リカバリに必要な時間を最小限にすることもできます。この例では、先週中の任意のSCNまでリカバリを行うことができますが、1日分より多くのREDOを適用する必要がないようにできます。
次のスクリプトを毎日実行するとします。初回実行時には、スクリプトによって、指定したタグを使用してディスク上にデータベースのイメージ・コピーのバックアップが作成されます。2回目から7回目の実行では、データベースのレベル1のバックアップが作成されます。8回目以降の実行では、レベル1の増分が7日前に作成されたデータファイル・コピーに適用され、前日からの変更を含む新しいレベル1のバックアップが作成されます。
RUN
{
RECOVER COPY OF DATABASE
WITH TAG 'incr_update'
UNTIL TIME 'SYSDATE - 7';
BACKUP
INCREMENTAL LEVEL 1
FOR RECOVER OF COPY WITH TAG 'incr_update'
DATABASE;
}
例2-99 スタンバイ・データベースで制御ファイルを失った場合のリカバリ
スタンバイ・データベースdgprod3の制御ファイルが、メディア障害によって消失したとします。プライマリ・データベースおよびスタンバイ・データベースは、SBTストレージを共有します。プライマリ・データベースの制御ファイルのバックアップはテープ上に存在します。
Recovery Managerクライアントを起動し、TARGETとしてdgprod3に接続して、リカバリ・カタログに接続します。次のRecovery Managerコマンドは、スタンバイ・データベースで使用できる制御ファイルをリストアし、ファイル名をディスク上の既存ファイルに更新して、スタンバイ・データベースのリカバリを行います。
RESTORE CONTROLFILE;
ALTER DATABASE MOUNT;
RECOVER DATABASE;
これで、スタンバイ・データベースへのREDOの適用を開始できます。
増分バックアップを適用することによって、NOARCHIVELOGモードで実行されているデータベースの変更に対して制限付きリカバリを実行できます。NOARCHIVELOGモードで実行されているデータベースのすべてのバックアップと同様、増分バックアップには一貫性が必要です。そのため、データベースがオープンされているときにバックアップすることはできません。
リカバリ・カタログを使用してデータベースprodをNOARCHIVELOGモードで実行するとします。日曜日の午後に、データベースを一貫した状態で停止し、テープにデータベースprodのレベル0のバックアップを作成します。水曜日と金曜日の午前3時に、データベースを一貫した状態で停止し、テープにレベル1の差分増分バックアップを作成します。
土曜日にデータベースでメディア障害が発生し、半分のデータファイルとオンラインREDOログが破損します。オンライン・ログが消失しているため、RECOVERコマンドでNOREDOオプションを指定する必要があります。このオプションを指定しない場合、Recovery Managerは、金曜日の増分バックアップを適用した後でREDOログを検索し、REDOログが検出されない場合にはエラー・メッセージを発行します。
Recovery Managerをprodおよびカタログ・データベースに接続した後、次のようにリカバリを実行します。
STARTUP FORCE NOMOUNT;
RESTORE CONTROLFILE; # restore control file from consistent backup
ALTER DATABASE MOUNT;
RESTORE DATABASE; # restore datafiles from consistent backup
RECOVER DATABASE NOREDO; # specify NOREDO because online redo logs are lost
ALTER DATABASE OPEN RESETLOGS;
リカバリしたデータベースには、金曜日の増分バックアップの時刻までの変更のみ反映されています。アーカイブREDOログが存在しないため、増分バックアップ後の変更をリカバリできません。
この例では、バックアップの妥当性チェックを実行してV$DATABASE_BLOCK_CORRUPTIONビューに移入し、このビューに記録された破損ブロックをリカバリします。両方のコマンドの出力例を示します。
RMAN> VALIDATE DATABASE;
Starting validate at 19-FEB-07
using channel ORA_DISK_1
channel ORA_DISK_1: starting validation of datafile
channel ORA_DISK_1: specifying datafile(s) for validation
.
.
.
List of Datafiles
=================
File Status Marked Corrupt Empty Blocks Blocks Examined High SCN
---- ------ -------------- ------------ --------------- ----------
1 FAILED 0 4070 57600 555975
File Name: /disk1/oradata/prod/system01.dbf
Block Type Blocks Failing Blocks Processed
---------- -------------- ----------------
Data 1 41550
Index 0 7677
Other 0 4303
.
.
.
RMAN> RECOVER CORRUPTION LIST;
Starting recover at 19-FEB-07
using channel ORA_DISK_1
allocated channel: ORA_SBT_TAPE_1
channel ORA_SBT_TAPE_1: SID=104 device type=SBT_TAPE
channel ORA_SBT_TAPE_1: Oracle Secure Backup
searching flashback logs for block images until SCN 547548
finished flashback log search, restored 1 blocks
starting media recovery
media recovery complete, elapsed time: 00:00:03
Finished recover at 19-FEB-07
REGISTER DATABASEコマンドを使用すると、ターゲット・データベースのメタデータをRecovery Managerでメンテナンスできるように、ターゲット・データベースをリカバリ・カタログに登録できます。Recovery Managerによって、ターゲット・データベース自体からターゲット・データベースを登録するために必要なすべての情報が取得されます。
このコマンドは、Recovery Managerプロンプトでのみ実行してください。Recovery Managerは、リカバリ・カタログおよびマウント済またはオープン状態のターゲット・データベースに接続されている必要があります。現在リカバリ・カタログに登録されていないデータベースを登録する必要があります。
登録できるデータベースは、リカバリ・カタログ内で一意のDBIDを持つターゲット・データベースのみです。データベースは、同じ名前でもDBIDの値が異なれば登録できます。ただし、スタンバイ・データベースは登録できません。
Recovery Managerでは、スタンバイ・データベースのプライマリ・データベースがすでにリカバリ・カタログに登録されており、次のいずれかの条件が該当する場合、自動的に新しいスタンバイ・データベースがリカバリ・カタログに登録されます。
DB_UNIQUE_NAMEを持つデータベース・インスタンスに接続されている場合。
DB_UNIQUE_NAMEコマンドを実行する場合。
重複するDBIDが見つかると、REGISTER DATABASEコマンドは失敗します。この状況になるのは、データベースを作成するときに、DUPLICATEコマンドを使用せずに既存のデータベースからファイルをコピーしたときです。この障害が発生した場合は、DBNEWIDユーティリティを使用して、コピーしたデータベースのDBIDを変更してから、REGISTER DATABASEコマンドを再試行できます。
RESETLOGSオプションを指定してデータベースをオープンし、その後にこのデータベースをリカバリ・カタログに登録すると、リカバリ・カタログでは、古いインカネーションのDB_NAMEがUNKNOWNとして記録されます。これは、古いインカネーションが以前に登録されていないためです。これらのレコードは削除しないでください。
この例では、新しいターゲット・データベースをリカバリ・カタログに登録します。例には出力例も含まれます。
RMAN> CONNECT TARGET /
connected to target database: PROD (DBID=1619241818)
RMAN> CONNECT CATALOG rman@catdb
recovery catalog database Password: password
connected to recovery catalog database
RMAN> REGISTER DATABASE;
database registered in recovery catalog
starting full resync of recovery catalog
full resync complete
RELEASE CHANNELコマンドを使用すると、ターゲット・データベース・インスタンスに接続した状態で、通常のチャネルまたはメンテナンス・チャネルを解放できます。通常のチャネルはALLOCATE CHANNELを使用して割り当てられますが、メンテナンス・チャネルはALLOCATE CHANNEL FOR MAINTENANCEで割り当てられます。
通常のチャネルを解放するには、release::=図で示される構文を使用します。この形式のRELEASE CHANNELはRUNコマンド内でのみ実行し、ALLOCATE CHANNEL コマンドで使用した識別子と同じ識別子を付けてチャネル名を指定してください。
メンテナンス・チャネルを解放するには、releaseForMaint::=図で示される構文を使用します。この形式のRELEASE CHANNELは、Recovery Managerプロンプトでのみ実行し、RUNコマンド内で実行できません。
メンテナンス・チャネルは、RUN コマンド内で発行されたALLOCATE CHANNEL およびRELEASE CHANNELコマンドの影響を受けません。
RUN内でRELEASE CHANNELを使用してチャネルを解放するのはオプションです。これは、Recovery ManagerがRUNコマンドの終了時に通常のチャネルをすべて自動的に解放するためです。
| 構文の要素 | 説明 |
|---|---|
|
|
ALLOCATE CHANNEL コマンド内で使用する、大/小文字の区別があるチャネルIDを指定します（例2-103を参照）。 |
この例では、日次バックアップ用のテープ・セットを示すパラメータを使用してch1というSBTチャネルを割り当て、データベースをバックアップしてから、このチャネルを解放します。次に、週次バックアップ用のテープ・セットのパラメータを使用してch1というSBTチャネルを割り当て、別のデータベース・バックアップを作成します。
RUN
{
ALLOCATE CHANNEL ch1 DEVICE TYPE sbt
PARMS='ENV=(OB_MEDIA_FAMILY=daily_bkp)';
BACKUP DATABASE;
RELEASE CHANNEL ch1;
ALLOCATE CHANNEL ch1 DEVICE TYPE sbt
PARMS='ENV=(OB_MEDIA_FAMILY=weekly_bkp)';
BACKUP DATABASE;
}
RUNコマンドの最後にRELEASE CHANNELコマンドは必要ありません。これは、Recovery Managerが自動的にチャネルch1を解放するためです。
この例では、Recovery Managerセッションの出力例が表示されます。SBTメンテナンス・チャネルを割り当てた後に、テープ上のバックアップをクロスチェックし、削除します。SBTチャネルを解放した後、Recovery Managerがデフォルトのディスク・チャネルを使用してデータベースをバックアップします。
RMAN> ALLOCATE CHANNEL FOR MAINTENANCE DEVICE TYPE sbt;
allocated channel: ORA_MAINT_SBT_TAPE_1
channel ORA_MAINT_SBT_TAPE_1: SID=105 device type=SBT_TAPE
channel ORA_MAINT_SBT_TAPE_1: Oracle Secure Backup
RMAN> CROSSCHECK BACKUP;
crosschecked backup piece: found to be 'AVAILABLE'
backup piece handle=1jiah8ln_1_1 RECID=25 STAMP=615031479
crosschecked backup piece: found to be 'AVAILABLE'
backup piece handle=1kiah8pk_1_1 RECID=26 STAMP=615031612
crosschecked backup piece: found to be 'AVAILABLE'
backup piece handle=1niah973_1_1 RECID=28 STAMP=615032036
Crosschecked 3 objects
RMAN> DELETE BACKUP;
List of Backup Pieces
BP Key BS Key Pc# Cp# Status Device Type Piece Name
------- ------- --- --- ----------- ----------- ----------
1333 1331 1 1 AVAILABLE SBT_TAPE 1jiah8ln_1_1
1334 1332 1 1 AVAILABLE SBT_TAPE 1kiah8pk_1_1
1427 1423 1 1 AVAILABLE SBT_TAPE 1niah973_1_1
Do you really want to delete the above objects (enter YES or NO)? YES
deleted backup piece
backup piece handle=1jiah8ln_1_1 RECID=25 STAMP=615031479
deleted backup piece
backup piece handle=1kiah8pk_1_1 RECID=26 STAMP=615031612
deleted backup piece
backup piece handle=1niah973_1_1 RECID=28 STAMP=615032036
Deleted 3 objects
RMAN> RELEASE CHANNEL;
released channel: ORA_MAINT_SBT_TAPE_1
RMAN> BACKUP DATABASE;
Starting backup at 20-FEB-07
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=105 device type=DISK
channel ORA_DISK_1: starting full datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
REPAIR FAILUREコマンドを使用すると、データ・リカバリ・アドバイザで識別されたデータベース障害を修復できます。
ワークフローは、LIST FAILUREを実行して障害を表示し、ADVISE FAILUREで修復オプションを表示して、REPAIR FAILUREで障害を修復することをお薦めします。
ターゲット・データベースのインスタンスは起動されている必要があります。データベースは、単一インスタンス・データベースである必要があります。また、フィジカル・スタンバイ・データベースは指定できません。
最大で1つのRecovery ManagerセッションでREPAIR FAILUREコマンドが実行されていることを確認します。REPAIR FAILURE ...PREVIEWだけは例外で、Recovery Managerの同時セッションで使用できます。
自動修復を実行するには、データ・リカバリ・アドバイザで特定のバックアップおよびアーカイブREDOログが必要になる場合があります。リカバリに必要なファイルが使用できない場合は、リカバリを行うことはできません。
修復は、単一修復で複数の障害が修復できる可能性がある場合に統合されます。REPAIR FAILUREは、現行のセッションでADVISE FAILUREがまだ実行されていない場合にはこのコマンドを暗黙的に実行します。
Recovery Managerは、まだ障害が関連しているかどうかを常に検証し、修復済の障害を自動的にクローズします。また、すでに修復済の障害、およびADVISE FAILUREが実行されて新しい障害が報告がされたために不要となった障害を修復しようとすることはありません。
デフォルトでは、REPAIR FAILUREを使用すると、実行開始前に確認のプロンプトが表示されます。修復を実行した後で、既存の障害もすでに修復されている可能性があるため、Recovery Managerは既存のすべての障害を再評価します。
Oracle RACデータベースのすべてのインスタンスでデータ障害が発生した場合に、単一インスタンス・モードでデータベースをマウントしてデータ・リカバリ・アドバイザを使用すると、制御ファイル、SYSTEMデータファイルおよびディクショナリの障害を検出して修復できます。また、ヘルス・チェックを開始して、他のデータベース・コンポーネントにデータ障害がないかをテストすることもできます。この方法では、他のクラスタ・インスタンスに対してローカルなデータ障害（アクセス不能なデータファイルなど）は検出されません。
| 構文の要素 | 説明 |
|---|---|
|
|
|
|
|
修復オプションは、オプション番号で指定します（障害番号では指定しません）。修復オプション番号はADVISE FAILUREコマンドで取得できます。 |
|
|
コマンド・ファイルの |
|
|
修復は行わず、すべての修復アクションとコメントが記述されたスクリプトを生成します。デフォルトでは、スクリプトは標準出力に表示されます。SPOOLコマンドを使用すると、編集可能なファイルにスクリプトを書き込むことができます（例2-106を参照）。 |
この例では、データ・リカバリ・アドバイザが認識できるすべての障害を修復します。この例では、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 RMAN> REPAIR FAILURE; Strategy: The repair includes complete media recovery with no data loss Repair script: /disk1/oracle/log/diag/rdbms/prod/prod/hm/reco_475549922.hm contents of repair script: # restore and recover datafile sql 'alter database datafile 28 offline'; restore datafile 28; recover datafile 28; sql 'alter database datafile 28 online'; # block media recovery recover datafile 1 block 56416; Do you really want to execute the above repair (enter YES or NO)? YES executing repair script sql statement: alter database datafile 28 offline Starting restore at 23-APR-07 using channel ORA_DISK_1 channel ORA_DISK_1: starting datafile backup set restore channel ORA_DISK_1: specifying datafile(s) to restore from backup set channel ORA_DISK_1: restoring datafile 00028 to /disk1/oradata/prod/users01.dbf channel ORA_DISK_1: reading from backup piece /disk2/PROD/backupset/2007_04_18/o1_mf_nnndf_TAG20070418T182042_32fjzd3z_.bkp channel ORA_DISK_1: piece handle=/disk2/PROD/backupset/2007_04_18/o1_mf_nnndf_TAG20070418T182042_32fjzd3z_.bkp tag=TAG20070418T182042 channel ORA_DISK_1: restored backup piece 1 channel ORA_DISK_1: restore complete, elapsed time: 00:00:03 Finished restore at 23-APR-07 Starting recover at 23-APR-07 using channel ORA_DISK_1 starting media recovery media recovery complete, elapsed time: 00:00:01 Finished recover at 23-APR-07 sql statement: alter database datafile 28 online Starting recover at 23-APR-07 using channel ORA_DISK_1 searching flashback logs for block images until SCN 429690 finished flashback log search, restored 1 blocks starting media recovery media recovery complete, elapsed time: 00:00:03 Finished recover at 23-APR-07 repair failure complete例2-106 修復のプレビュー
次の例では、現行のセッションで最後に実行したADVISE FAILUREコマンドの最初の修復オプションによる修復をプレビューします。この例では、LIST FAILUREおよびADVISE FAILUREの各コマンドの出力例は示されていません。
RMAN> LIST FAILURE;
.
.
.
RMAN> ADVISE FAILURE;
.
.
.
RMAN> REPAIR FAILURE PREVIEW;
Strategy: The repair includes complete media recovery with no data loss
Repair script: /disk1/oracle/log/diag/rdbms/prod/prod/hm/reco_3200987003.hm
contents of repair script:
# block media recovery
recover datafile 1 block 56416;
SPOOLとREPAIR FAILURE ...PREVIEWを併用すると、修復スクリプトをファイルに書き込むことができます。その後に、このスクリプトを編集して手動で実行できます。次の例では、修復プレビューのログを/tmp/repaircmd.datにスプールします。
RMAN> SPOOL LOG TO '/tmp/repaircmd.dat';
RMAN> REPAIR FAILURE PREVIEW;
RMAN> SPOOL LOG OFF;
REPLACE SCRIPTコマンドを使用すると、リカバリ・カタログに格納されている既存のスクリプトを置換できます。既存のスクリプトがない場合は、REPLACE SCRIPTによりスクリプトが作成されます。
REPLACE SCRIPTは、Recovery Managerプロンプトでのみ実行できます。Recovery Managerが、ターゲット・データベースとリカバリ・カタログに接続されている必要があります。リカバリ・カタログ・データベースはオープンの状態である必要があります。
ローカル・スクリプトを置き換える場合は、スクリプトの作成時と同じターゲット・データベースに接続する必要があります。
Recovery Manangerでは、ストアド・スクリプトで置換変数を使用できます。&1は最初の値を配置する位置を示し、&2は2番目の値を配置する位置を示します。その後も同様に続きます。特殊文字は、引用符で囲む必要があります。
置換変数の構文は、&integerの後にオプションでピリオドが続きます（&1.3など）。オプションのピリオドは変数の一部であり、値と置換されますので、置換テキストの直後に別の整数を続けることができます。たとえば、置換変数&1.3が含まれているコマンド・ファイルに値mybackupを渡すと、その置換結果はmybackup3になります。mybackup.3という結果を得るには、構文&1..3を使用します。
置換変数を使用するストアド・スクリプトを作成する場合は、作成時に例となる値を指定する必要があります。これらの値は、Recovery Managerの起動時にUSING句で指定するか（「RMAN」を参照）、またはプロンプトが表示されたときに入力します（例2-60を参照）。
（backupCommands::=、maintenanceCommands::=、miscellaneousCommands::=、restoreCommands::=）
| 構文の要素 | 説明 |
|---|---|
|
|
注意: 仮想プライベート・カタログは、グローバル・スクリプトに対して読取り専用のアクセスが可能です。グローバル・スクリプトの作成と更新は、Recovery Managerが基本リカバリ・カタログに接続している間に行う必要があります。 関連項目: グローバル・スクリプトとローカル・スクリプトの違いについては、「使用上の注意」を参照してください。 |
|
|
置換するローカル・スクリプトまたはグローバル・スクリプトを指定します。 |
|
|
説明のコメントをリカバリ・カタログ内のストアド・スクリプトと関連付けます。コメントは、LIST |
|
|
ストアド・スクリプトに含めるコマンドを指定します。 |
|
|
指定したファイルからスクリプトを定義する一連のコマンドを読み取ります。
このファイルは、有効なストアド・スクリプトの本体と同様である必要があります。このファイルの最初の行は、左カッコ（ |
Recovery Managerクライアントを起動し、TARGETとしてデータベースprodに接続して、リカバリ・カタログに接続します。CREATE SCRIPTを使用して、次のようにbackup_dbという名前のグローバル・スクリプトを作成します。
CREATE GLOBAL SCRIPT backup_db
COMMENT "back up any database from the recovery catalog, with logs"
{
BACKUP DATABASE;
}
次に、LIST SCRIPT NAMESを使用して、リカバリ・カタログで認識されているすべてのスクリプトをリストします。
RMAN> LIST SCRIPT NAMES;
List of Stored Scripts in Recovery Catalog
Global Scripts
Script Name
Description
-----------------------------------------------------------------------
backup_db
back up any database from the recovery catalog, with logs
次に、backup_dbグローバル・スクリプトを編集するために、次のREPLACE SCRIPTコマンドを実行します。
RMAN> REPLACE SCRIPT backup_db { BACKUP DATABASE PLUS ARCHIVELOG; }
replaced script backup_db
GLOBALキーワードを指定していないため、Recovery Managerがbackup_dbという名前のグローバル・スクリプトに加えて、backup_dbという名前のローカル・スクリプトを作成します。LIST SCRIPT NAMESは、リカバリ・カタログに記録されているグローバル・スクリプトとローカル・スクリプトを両方とも示します。
RMAN> LIST SCRIPT NAMES;
List of Stored Scripts in Recovery Catalog
Scripts of Target Database PROD
Script Name
Description
-----------------------------------------------------------------------
backup_db
Global Scripts
Script Name
Description
-----------------------------------------------------------------------
backup_db
back up any database from the recovery catalog, with logs
次に、DELETE SCRIPTを使用してbackup_dbという名前のローカル・スクリプトを削除し、次のようにグローバル・スクリプトを置換します。
RMAN> DELETE SCRIPT backup_db;
deleted script: backup_db
RMAN> REPLACE GLOBAL SCRIPT backup_db { BACKUP DATABASE PLUS ARCHIVELOG; }
replaced global script backup_db
ここでのLIST SCRIPT NAMESコマンドは、カタログにbackup_dbという名前のスクリプトのみが存在していることを示します。
RMAN> LIST SCRIPT NAMES;
List of Stored Scripts in Recovery Catalog
Global Scripts
Script Name
Description
-----------------------------------------------------------------------
backup_db
PRINT SCRIPTコマンドを実行すると、グローバル・スクリプトの変更が確認されます。
RMAN> PRINT GLOBAL SCRIPT backup_db;
printing stored global script: backup_db
{ BACKUP DATABASE PLUS ARCHIVELOG; }
REPORTコマンドを使用すると、Recovery Managerリポジトリの詳細分析を実行できます。Recovery Managerは、レポートを標準出力またはメッセージ・ログ・ファイルに書き出します
このコマンドは、Recovery Managerプロンプトでのみ実行してください。次のいずれかの条件が満たされている必要があります。
DBIDが実行されている必要があります。
（needBackupOption::=、atClause::=、reportObject::=、obsOperandList::=、deviceSpecifier::=）
この句では、レポートのタイプを指定します。
| 構文の要素 | 説明 |
|---|---|
|
関連項目: |
|
|
|
Recovery Managerリポジトリに記録され、不要になったために削除できる全体バックアップ、データファイルのコピーおよびアーカイブREDOログをリストします。出力の説明は、表2-33を参照してください。このコマンドは、次の2つの手順で使用します。
副次句obsOperandListには、Recovery Managerで不要と判断するために使用する条件を記述します。obsOperandListでパラメータを指定しなければ、CONFIGURE
注意: |
|
|
指定時点でのターゲット・データベースのすべてのデータファイル（永続および一時）と表領域の名前をリストします。出力の説明は、表2-28を参照してください。
forDbUniqueNameOptionが指定されていない |
|
データベースは
Recovery Managerは、リカバリ・カタログに接続している必要があります。Recovery Managerがターゲット・データベースに接続され、SET 関連項目: この句のオプションについては、「forDbUniqueNameOption」を参照してください。 |
|
|
SCN、ログ順序番号または時間を指定します。 |
|
|
|
リカバリ不能なすべてのデータファイルをリストします。出力の説明は、表2-34を参照してください。
最後のバックアップ以降に、データファイル内のオブジェクトに対してUNRECOVERABLE操作が実行されていると、そのデータファイルはリカバリ不能とみなされます。リカバリ不能操作では、REDOは生成されません。例は、表データのダイレクト・ロードと
注意: データファイルのバックアップのいずれかが存在しないということのみでは、リカバリ不能とみなされる理由にはなりません。このようなデータファイルは、ファイルの作成時以降のREDOログが存在していれば、 |
|
ストレージ・デバイスのタイプを指定します。Recovery Managerは、レポート用に指定したデバイスに存在しているバックアップとコピーのみを使用可能とみなします。 |
この句は、バックアップの必要なファイルに関してのみレポートを行います。
| 構文の要素 | 説明 |
|---|---|
|
|
新しいバックアップが必要で、指定したreportObjectにあるすべてのデータファイルをリストします。
レポートは、最新のバックアップをリストアすることを前提としています。オプションを指定しなければ、Recovery Managerは現行の保存方針の構成を使用します。保存方針が無効化されている場合（CONFIGURE |
|
|
完全なリカバリのために、指定した日数より多くのアーカイブREDOログ・ファイルを必要とするすべてのデータファイルをリストします。たとえば、 ターゲット・データベースの制御ファイルがマウントされている現行ファイルである場合、Recovery Managerはこのレポートに次のような最適化を行います。 |
|
|
リカバリに必要な増分バックアップのしきい値を指定します（例2-109を参照）。
注意: バックアップが存在しないファイルはこのリストに示されていません。それらのファイルを表示するには、 |
|
|
指定した日数の期間、リカバリ期間ベースの保存方針を満たすための十分なバックアップがないデータファイルをレポートします。つまり、 |
|
|
データファイルをバックアップが必要ない範囲にあるとみなすために必要なバックアップまたはコピーの最小数を指定します。つまり、データファイルのバックアップまたはコピーが |
|
レポートを生成するオブジェクトを指定します。 |
この副次句では、レポートに含めるデータファイルを指定します。レポートには、データベース全体（必要に応じて、特定の表領域をスキップ）または表領域のリスト、データファイルのリストを含めることができます。Recovery Managerには以前のインカネーションからのオブジェクトが含まれます。
| 構文の要素 | 説明 |
|---|---|
|
|
データベースにある全ファイルのバックアップまたはデータファイルのコピーをリストします。
注意: |
|
|
指定したデータファイルをリストします。Recovery Managerは、指定したデータファイルを少なくとも1つ含むバックアップまたはデータファイルのコピーについてレポートを作成します。 |
|
|
指定した表領域にあるデータファイルをリストします。Recovery Managerは、指定した表領域にあるデータファイルを少なくとも1つ含むバックアップまたはデータファイルのコピーについてレポートを作成します。 |
この副次句では、時刻、SCNまたはログ順序番号で特定の時点を指定します。AT 句を使用してREPORT SCHEMA コマンドを発行するときは、リカバリ・カタログに接続している必要があります。
| 構文の要素 | 説明 |
|---|---|
|
|
SCNを指定します。 |
|
|
ログ順序番号を指定します。この整数は、指定したログが最初にオープンされた時刻を示します。 |
|
|
REDO |
|
|
日付を指定します（例2-108を参照）。 |
出力で表示される情報については、次の表を参照してください。
| 列 | 指定対象 |
|---|---|
|
|
n日分より多くのアーカイブREDOログがリカバリ用に必要であるデータファイルの絶対ファイル番号。 |
|
|
リカバリ用に必要なアーカイブREDOデータの日数。 |
|
|
データファイルの名前。 |
| 列 | 指定対象 |
|---|---|
|
|
nより多くの増分が完全リカバリのために必要なデータファイルの絶対ファイル番号。 |
|
|
完全リカバリのために必要な増分バックアップの数。 |
|
|
データファイルの名前。 |
| 列 | 指定対象 |
|---|---|
|
|
n日のリカバリ期間を満たすようにバックアップを行う必要があるデータファイルの絶対ファイル番号。 |
|
|
完全リカバリのために必要な日数。 |
|
|
バックアップが必要なデータファイルの名前。 |
| 列 | 指定対象 |
|---|---|
|
|
冗長度n未満のバックアップしかないデータファイルの絶対データファイル番号。 |
|
|
このファイルに対して存在しているバックアップの数。 |
|
|
ファイルの名前。 |
リカバリ・カタログが必要なこの例では、20分前のすべてのデータファイルの名前と表領域をレポートします。
RMAN> REPORT SCHEMA AT TIME 'sysdate-20/1440';
Report of database schema for database with db_unique_name PROD
List of Permanent Datafiles
===========================
File Size(MB) Tablespace RB segs Datafile Name
---- -------- -------------------- ------- ------------------------
1 450 SYSTEM YES /disk1/oradata/prod/system01.dbf
2 197 SYSAUX YES /disk1/oradata/prod/sysaux01.dbf
3 20 UNDOTBS YES /disk1/oradata/prod/undotbs01.dbf
4 10 CWMLITE YES /disk1/oradata/prod/cwmlite01.dbf
5 10 DRSYS YES /disk1/oradata/prod/drsys01.dbf
6 10 EXAMPLE YES /disk1/oradata/prod/example01.dbf
7 10 INDX YES /disk1/oradata/prod/indx01.dbf
8 10 TOOLS YES /disk1/oradata/prod/tools01.dbf
9 10 USERS YES /disk1/oradata/prod/users01.dbf
List of Temporary Files
=======================
File Size(MB) Tablespace Maxsize(MB) Tempfile Name
---- -------- -------------------- ----------- --------------------
1 40 TEMP 32767 /disk1/oradata/prod/temp01.dbf
例2-109 増分バックアップが必要なデータファイルのレポート
この例では、データベース内のデータファイルのうち、現行の状態にリカバリするために1つ以上の増分バックアップの適用が必要なすべてのデータファイルをレポートします。
RMAN> REPORT NEED BACKUP INCREMENTAL 1;
Report of files that need more than 1 incrementals during recovery
File Incrementals Name
---- ------------ ----------------------------------------------
1 2 /disk1/oradata/prod/system01.dbf
2 2 /disk1/oradata/prod/sysaux01.dbf
3 2 /disk1/oradata/prod/undotbs01.dbf
4 2 /disk1/oradata/prod/cwmlite01.dbf
5 2 /disk1/oradata/prod/drsys01.dbf
6 2 /disk1/oradata/prod/example01.dbf
7 2 /disk1/oradata/prod/indx01.dbf
9 2 /disk1/oradata/prod/users01.dbf
例2-110 不要なバックアップとコピーのレポート
次の例では、現在の保存方針に従って冗長とみなされる不要なバックアップとコピーをレポートします。保存方針は冗長度1に設定されています。
RMAN> REPORT OBSOLETE;
RMAN retention policy will be applied to the command
RMAN retention policy is set to redundancy 1
Report of obsolete backups and copies
Type Key Completion Time Filename/Handle
-------------------- ------ ------------------ --------------------
Archive Log 1022 19-FEB-07 /disk1/prod/arch/archive1_59_614712405.dbf
Archive Log 1023 19-FEB-07 /disk1/prod/arch/archive1_61_614712405.dbf
Archive Log 1024 19-FEB-07 /disk1/prod/arch/archive1_60_614712405.dbf
Archive Log 1025 19-FEB-07 /disk1/prod/arch/archive1_55_614712405.dbf
Backup Set 1032 19-FEB-07
Backup Piece 1050 19-FEB-07
/disk2/PROD/backupset/2007_02_19/o1_mf_nnndf_TAG20070216T173839_2xnpmp0l_.bkp
Datafile Copy 1073 19-FEB-07
/disk2/PROD/datafile/o1_mf_system_2xmz5l5m_.dbf
Backup Set 1035 19-FEB-07
Backup Piece 1053 19-FEB-07
/disk2/PROD/backupset/2007_02_19/o1_mf_nnndf_TAG20070219T111434_2xnpozym_.bkp
Datafile Copy 1074 19-FEB-07
/disk2/PROD/datafile/o1_mf_sysaux_2xmz6zdg_.dbf
Datafile Copy 1075 19-FEB-07
/disk2/PROD/datafile/o1_mf_undotbs_2xmz7rof_.dbf
Datafile Copy 1076 19-FEB-07
/disk2/PROD/datafile/o1_mf_cwmlite_2xmz7vrg_.dbf
Datafile Copy 1077 19-FEB-07 /disk2/PROD/datafile/o1_mf_drsys_2xmz7wyc_.dbf
Datafile Copy 1078 19-FEB-07
/disk2/PROD/datafile/o1_mf_example_2xmz7y5s_.dbf
Datafile Copy 1079 19-FEB-07 /disk2/PROD/datafile/o1_mf_indx_2xmz81jg_.dbf
Datafile Copy 1081 19-FEB-07 /disk2/PROD/datafile/o1_mf_users_2xmz85vo_.dbf
Datafile Copy 1777 20-FEB-07 /disk2/users01.dbf
RESET DATABASE TO INCARNATIONコマンドを使用すると、Recovery Managerリポジトリのターゲット・データベースのインカネーションを以前のデータベース・インカネーションに再設定できます。このコマンドは次のような状況でのみ使用する必要があります。
RESETLOGSタイムスタンプより前のSCNに戻す場合。
RESET DATABASE TO INCARNATIONは、Recovery Managerプロンプトでのみ実行できます。Recovery Managerは、ターゲット・データベースに接続している必要があります。
Recovery ManagerがNOCATALOGモードで実行されている場合は、ターゲット・データベースをマウントする必要があります。マウントされる制御ファイルには、指定したデータベース・インカネーションのレコードが含まれている必要があります。
Recovery ManagerがCATALOGモードで実行されている場合は、ターゲット・データベースのマウントまたはアンマウントが可能です。データベースをマウントする場合は、指定したデータベース・インカネーションのレコードが制御ファイルに含まれている必要があります。
Recovery ManagerをNOCATALOGモードで使用すると、RESET DATABASE TO INCARNATIONコマンドはRecovery Managerセッション全体で永続的になります。
| 構文の要素 | 説明 |
|---|---|
|
|
現行のインカネーションを、データベース・インカネーションの
可能なキー値を取得するには、LIST |
NOCATALOGモードでは、リカバリするインカネーションに関する情報が含まれている制御ファイルをマウントする必要があります。次の使用例では、データベースtrgtの破棄されたインカネーションにデータベースを再設定し、不完全リカバリを実行します。
CONNECT TARGET / NOCATALOG
# step 1: start and mount a control file that knows about the incarnation to which
# you want to return. if the current control file does not know about it, then
# you must restore an older control file
STARTUP NOMOUNT;
RESTORE CONTROLFILE UNTIL TIME 'SYSDATE-250';
ALTER DATABASE MOUNT;
# step 2: obtain the primary key of old incarnation
LIST INCARNATION OF DATABASE trgt;
List of Database Incarnations
DB Key Inc Key DB Name DB ID STATUS Reset SCN Reset Time
------- ------- -------- ------------- ------- ---------- ----------
1 2 TRGT 1334358386 PARENT 154381 OCT 30 2007 16:02:12
1 116 TRGT 1334358386 CURRENT 154877 OCT 30 2007 16:37:39
# step 3: in this example, reset database to incarnation key 2
RESET DATABASE TO INCARNATION 2;
# step 4: restore and recover the database to a point before the RESETLOGS
RESTORE DATABASE UNTIL SCN 154876;
RECOVER DATABASE UNTIL SCN 154876;
# step 5: make this incarnation the current incarnation and then list incarnations:
ALTER DATABASE OPEN RESETLOGS;
LIST INCARNATION OF DATABASE trgt;
List of Database Incarnations
DB Key Inc Key DB Name DB ID STATUS Reset SCN Reset Time
------- ------- -------- ---------------- ------- ---------- ----------
1 2 TRGT 1334358386 PARENT 154381 OCT 30 2007 16:02:12
1 116 TRGT 1334358386 PARENT 154877 OCT 30 2007 16:37:39
1 311 TRGT 1334358386 CURRENT 154877 AUG 13 2007 17:17:03
RESTOREコマンドを使用すると、Recovery Managerバックアップのリストア、検証またはプレビューを実行できます。通常、バックアップのリストアは、メディア障害によって現行のデータファイル、制御ファイルまたはアーカイブREDOログが破損したとき、あるいはPoint-in-Timeリカバリの実行前に行います。
データファイルを現行の位置にリストアするには、リストアする表領域またはデータファイルをオフラインにしてデータベースを起動、マウントまたはオープンする必要があります。
Data Guard環境でRecovery Managerを使用する場合は、Recovery Managerがリカバリ・カタログに接続されている必要があります。
本番データベースの試行リストアを実行する場合は、テスト環境でデータベースのリストアを行う前に、次のいずれかの操作を実行します。
DB_RECOVERY_FILE_DESTを新しい場所に設定します。
DB_UNIQUE_NAMEを本番データベースとは違う名前に設定します。
前述の操作をどちらも実行しないと、Recovery Managerでは、本番データベースをリストアしていると判断し、フラッシュ・リカバリ領域のフラッシュバック・ログを使用不可能とみなして削除します。
RESTOREコマンドは、全体バックアップ、レベル0の増分バックアップまたはイメージ・コピーをリストアします。ファイルのリストア先は、そのファイルのデフォルトの位置または別の位置です。
デフォルトでは、Recovery Managerが読取り専用データファイルをチェックし、それが存在していること、読取り可能であること、および適切なチェックポイントがあることを確認します。これらの条件が満たされない場合、Recovery Managerはファイルをリストアします。すべての条件が満たされている場合、Recovery Managerはファイルをリストアしません。
デフォルトでは、RESTOREは最新のバックアップ・セットまたはファイル・コピーを使用します。つまり、最小のメディア・リカバリで済むファイル・コピーまたはバックアップ・セットを使用します。Recovery Managerは、RESTOREコマンドで割り当てたチャネルと同じタイプのチャネルで作成したバックアップのみをリストアします。たとえば、あるデータファイルのバックアップをDISKチャネルとsbtチャネルに作成し、RESTOREコマンドにはDISKチャネルのみを割り当てた場合、Recovery Managerはsbtのバックアップをリストアしません。チャネルを手動で割り当てない場合、Recovery Managerは、DEVICE TYPE オプションによる制限に従って、必要とする可能性があるすべての自動チャネルを割り当てます。
Oracle RAC構成では、バックアップ、制御ファイルのコピーおよびデータファイルのコピーは、テープ上またはローカル・ファイル・システム上でファイルを読み込めるチャネルから自動的にリストアされます。たとえば、inst1に接続しているch1はテープ・ドライブからログ1000を読み取ることができても、inst2に接続しているチャネルch2がテープ・ドライブから同じログを読み取ることができない場合、ch1がログのリストアをできないため、ch2がこのログをリストアします。チャネルが別のPARMS設定またはCONNECT設定を使用している場合は、自動位置検索が自動的に使用可能になります。
データファイル名がシンボリック・リンクの場合、制御ファイルにはリンク・ファイルのファイル名が格納されますが、Recovery Managerは、リンク・ファイルが指すデータファイルでI/Oを実行します。ただし、リンク・ファイルが消失し、最初にシンボリック・リンクを再作成せずにデータファイルをリストアすると、Recovery Managerは、リンク・ファイルが示す位置ではなく、リンク・ファイルの位置にデータファイルをリストアします。
「バックアップ・セットの暗号化」で説明したとおり、リストア操作中のRecovery Managerによる暗号化されたバックアップ・セットの処理方法は、バックアップが作成された暗号化モードによって異なります。CONFIGUREおよびSETを使用すると、Recovery Managerによるデータベース・バックアップの暗号化設定を管理できます。次のリストアに関する考慮事項に注意してください。
SET DECRYPTIONは必要ありません。
SET DECRYPTIONを使用して指定する必要があります。
SET DECRYPTIONを使用して指定する必要があります。バックアップ・ピース、イメージ・コピーまたはプロキシ・コピーにアクセスできないか、またはブロックが破損している場合、Recovery Managerによってリストア・フェイルオーバーが実行されます。RESTOREコマンドは、バックアップまたはイメージ・コピーの使用可能な別のコピーを同じデバイスと他のデバイスで自動的に検索します。使用可能なコピーが存在しない場合は、Recovery Managerによって以前のバックアップが検索されます。適切なコピーが見つかるまで、使用可能な以前のバックアップの検索は続行されます。Recovery Managerは、必要に応じて、以前のデータベース・インカネーションから適用可能なバックアップを使用します。
リストアしているデータファイルに使用できるバックアップがない場合は、Recovery Managerによって、作成SCNとしてチェックポイントの変更が指定されている空のデータファイルが作成されます。リカバリ時は、データファイルの作成時までさかのぼってすべてのアーカイブREDOログがリストアされます。また、データファイルの履歴内のすべての変更が再適用され、内容が再作成されます。
データファイルをデフォルトの場所にリストアすると、Recovery Managerによって同じファイル名を持つファイルが上書きされます。データファイルが適切な場所にあり、そのヘッダーに必要なデータが含まれている場合、デフォルトでは、Recovery Managerによってそのデータファイルがリストアされません。Recovery Managerでは、データファイル本体の破損ブロックをスキャンしません。
デフォルトのファイル名を使用できないことがRecovery Managerで確認された場合（たとえば、ファイルがOracle管理ファイルであるか、または自動ストレージ管理ディスク・グループに存在する場合）には、Recovery Managerによって同じ場所またはディスク・グループに新しいファイルの作成が試行されます。
ファイルをデフォルト以外の場所にリストアするには、SET NEWNAME コマンドを使用して、リストア対象ファイルの名前を変更してから、SWITCHコマンドでそのファイルを現行のファイルにします（例2-113を参照）。SWITCHコマンドを発行しなければ、Recovery Managerは、リストアされたファイルを有効なコピーとみなし、将来のリストア処理で使用します。表2-35に、SET NEWNAMEおよびSWITCHコマンドと併用したRESTOREの動作について説明します。
一時ファイルがバックアップされず、一時ファイル用のREDOも生成されないため、Recovery Managerでは一時ファイルのリストアまたはリカバリは行われません。Recovery Managerによる一時ファイル名の追跡は、必要に応じて一時ファイルを自動的に再作成するためにのみ実行されています。
制御ファイルのリストア時におけるRecovery Managerの動作は、様々な要素によって決まります。表2-36に、これらの要素を示します。自動バックアップのリストアに必要なコマンドおよびオプションについては、表2-37を参照してください。
| Recovery Managerの接続 | RESTORE CONTROLFILE; | RESTORE CONTROLFILE FROM AUTOBACKUP; | RESTORE CONTROLFILE ... TO 'filename'; | RESTORE CONTROLFILE ... FROM 'media_handle'またはTAG 'user_tag'; |
|---|---|---|---|---|
|
カタログなし、ターゲット・データベースは |
エラー。 |
|
|
最初にSET |
|
カタログなし、ターゲット・データベースはマウント済またはオープン状態 |
エラー。 |
エラー。 |
|
指定したファイルからリストアします。 |
|
カタログあり、ターゲット・データベースは |
|
テスト用のリカバリ・カタログでのみ使用します。 |
|
指定したファイルからリストアします。 |
|
カタログあり、ターゲット・データベースはマウント済またはオープン状態 |
エラー。 |
リカバリ・カタログでは使用しません。 |
|
Recovery Managerによりエラー |
Data Guard環境でRecovery Managerを使用すると、Recovery Managerは、プライマリ制御ファイルからスタンバイ制御ファイルへの変換およびスタンバイ制御ファイルからプライマリ制御ファイルへの変換を透過的に行います。また、RESTOREおよびRECOVERを発行すると、データファイル、オンラインREDOログ、スタンバイREDOログおよび一時ファイルのファイル名を自動的に更新します。「Data Guard環境でのRecovery Managerのバックアップ」で説明するとおり、リカバリ・カタログには、常に各データベースのバックアップ・ファイル名に関する正しい情報が含まれています。
自動バックアップをリストアする場合、使用するコマンドおよびオプションは、自動バックアップのタイプ（制御ファイルまたはサーバー・パラメータ・ファイル）と場所（フラッシュ・リカバリ領域の内部または外部）によって決まります。表2-37に、これらのオプションを示します。
（restoreObject::=、restoreSpecOperand::=、deviceSpecifier::=、untilClause::=）
（archivelogRecordSpecifier::=、datafileSpec::=）
この句を使用すると、リストアするファイルを選択し、リストア操作の動作を制御するパラメータを指定できます。
| 構文の要素 | 説明 |
|---|---|
|
リストアするファイルを指定します。 |
|
|
restoreObject句に対するオプションを指定します。 |
|
|
|
restoreSpecOperand句を参照してください。 |
|
|
物理的な破損チェックを通過したデータ・ブロックと索引ブロックについて、論理的な破損がないかどうかをテストします。たとえば、行ピースまたは索引エントリの破損がないかどうかを調べます。Recovery Managerは論理的な破損を見つけると、アラート・ログとサーバー・セッション・トレース・ファイルにそのブロックのログを書き込みます。
あるファイルで検出された物理的な破損と論理的な破損の合計数がSET
バックアップ・データファイルのリストア時には、
注意: |
|
|
指定したデバイス・タイプ専用の自動チャネルを割り当てます。たとえば、自動ディスクおよびテープ・チャネルを構成して
注意: RUNブロック内でチャネルを手動で割り当ててから、 関連項目: 「deviceSpecifier」を参照してください。 |
|
|
再起動可能なリストア機能をオーバーライドし、リストアが必要かどうかに関係なくすべてのファイルをリストアします。 |
|
|
Recovery Managerがバックアップ・セットからのみリストアを行うように指定します。デフォルトでは、
|
|
|
Recovery Managerがデータファイルのコピーのみをリストアするように指定します。デフォルトでは、 |
|
|
restoreSpecOperand句を参照してください。 |
|
|
Recovery Managerが指定した時刻のリストアおよびリカバリに使用できるバックアップとアーカイブREDOログをレポートします（リストアは行いません）。Recovery Managerではメタデータの問合せを実行しますが、実際のバックアップ・ファイルの読取りは行いません。
いくつかのメディア・マネージャによって、オフサイトのバックアップを示すステータス情報がRecovery Managerに提供されます。オフサイトのバックアップは、安全なストレージ設備などのリモートの場所に格納されるため、メディアを入手しないと使用できません。
オフサイトのバックアップは、バックアップをリストアする前にメディアをストレージから入手する必要があるにもかかわらず、Recovery Managerリポジトリでは 必要なバックアップがオフサイトで格納されているのに、メディア・マネージャでオフサイトのバックアップを使用できない場合は、次のオプションを使用できます。
関連項目: 「LIST」（特に、 |
|
|
指定したリストア操作に必要なバックアップ・メディアをオフサイトのストレージから入手するようにメディア・マネージャに指示します（例2-119を参照）。
注意: このオプションが有効になるのは、メディア・マネージャでこの機能がサポートされている場合のみです。 |
|
|
Recovery Managerによってリストアされるバックアップのサマリーを示します。この出力は、 |
|
|
読取り専用ファイルはリストアしません。 |
|
|
リストア・ポイントを作成した時点のSCNを上限として、リストア・ポイントを指定します。指定した値は含まれます。上限値が含まれるため、Recovery Managerは、リストア・ポイントに対応するSCNまでファイルをリストアできるファイルのみを選択します。 |
|
選択範囲を、指定した時刻、SCNまたはログ順序番号までのPoint-in-Timeリカバリに適したバックアップ・セットまたはファイル・コピーに制限します。
他の基準がない場合、Recovery Managerは、リストアする最新のファイル・コピーまたはバックアップ・セットを選択します。 関連項目: 「untilClause」を参照してください。 |
|
|
|
Recovery Managerで、リストアが必要なバックアップ・セット、データファイルのコピーおよびアーカイブREDOログ・ファイルを決定してから、これらを検証するように指定します（例2-120を参照）。ファイルはリストアされません。 ディスクとテープ両方のファイルについては、Recovery Managerがバックアップ・ピースまたはイメージ・コピー内のすべてのブロックを読み取ります。Recovery Managerは、オフサイト・バックアップも検証します。Recovery Manageでの検証は実際のリストア操作と同じですが、出力ファイルの書き出しは実行しません。
注意:
関連項目: |
|
|
Recovery Managerが指定した時刻のリストアに使用できるバックアップをレポートして検証します（リストアは行いません）。
このオプションを指定すると、Recovery Managerは、PREVIEWオプションを指定して
関連項目: |
この副次句は、リストアされるオブジェクト（制御ファイル、データファイル、アーカイブREDOログまたはサーバー・パラメータ・ファイル）を指定します。Recovery Managerでは、チェンジ・トラッキング・ファイルのバックアップおよびリカバリはサポートされていません。チェンジ・トラッキング・ファイルは、Recovery Managerによってデータベースのリストアおよびリカバリ後に再作成されます。リカバリ後の次回の増分バックアップでは、このチェンジ・トラッキング・ファイルが使用されます。したがって、リストアおよびリカバリによるチェンジ・トラッキングへの影響は、ユーザーからは管理できません。
| 構文の要素 | 説明 |
|---|---|
|
デフォルトのリストアの場所は、
RECOVERコマンドでは必要に応じてアーカイブREDOログが自動的にリストアされるため、手動によるリストアが必要になることはほとんどありません。アーカイブREDOログを手動でリストアする可能性が発生するのは、リカバリ時間を短縮する場合、ログを複数の宛先に書き込む場合、Point-in-Timeリカバリ後にログの内容を分析する場合などです。データベースを停止せずに以前のインカネーションからログをリストアするには、 注意: この操作では、データベースを起動、マウントまたはオープンできます。 関連項目: 「archivelogRecordSpecifier」を参照してください。 |
|
|
|
ターゲット・データベースのロールに応じて、スタンバイ制御ファイルまたはバックアップ制御ファイルをリストアします。
制御ファイルが消失した場合は、制御ファイルをリストアし（表2-36を参照）、リストアした制御ファイルをマウントしてからデータベースをリストアします。リストアした制御ファイルをマウントした後は、常にRECOVERコマンドを実行して、
注意: ターゲット・データベースがマウントされていない状態で、Recovery Managerがリカバリ・カタログに接続していない場合は、
リカバリ・カタログに接続中にバックアップ制御ファイルを使用して |
|
|
|
|
|
オフラインのファイルを除いて、データベースのすべてのデータファイルをリストアします。デフォルトでは、Recovery Managerは読取り専用表領域のデータファイルをリストアします。
BACKUP
注意: オフライン・データファイルをリストアするには、 |
|
|
指定した表領域をリストア操作から除外します。このオプションは、一時データを含む表領域のリストアを回避する場合に有効です。
|
|
|
ファイル名または絶対データファイル番号で指定したデータファイルをリストアします（例2-113を参照）。
注意: リストア・ジョブでは、1つのデータファイルを2回以上指定しないでください。たとえば、次のコマンド例は、データファイル1が明示的に指定されていると同時に、 RESTORE TABLESPACE SYSTEM DATAFILE 1; 関連項目: 「datafileSpec」を参照してください。 |
|
|
Data Guard環境のプライマリ・データベースの制御ファイルをリストアします。
Recovery Managerは、ターゲット・データベースのリカバリ・カタログに認識されている最新のデータベース・ロール（RC_SITE
プライマリ・データベース |
|
|
プライマリ・サーバー・パラメータ・ファイルまたはスタンバイ・サーバー・パラメータ・ファイルをバックアップ元にリストアします。Recovery Managerでは、ターゲット・データベースで使用中のサーバー・パラメータ・ファイルは上書きできません。
デフォルトでは、最新のサーバー・パラメータ・ファイルがリストアされます。
サーバー・パラメータ・ファイルが失われた場合は、Recovery Managerをターゲット・データベース（および使用している場合はリカバリ・カタログ）に接続し、SET
注意: ターゲット・データベースがマウントされていない状態で、Recovery Managerがリカバリ・カタログに接続していない場合は、 |
|
|
プライマリ・サーバー・パラメータ・ファイルまたはスタンバイ・サーバー・パラメータ・ファイルを、 |
|
|
インスタンスが起動されていないときは、ターゲット・データベースの
Data Guard環境では、プライマリ・ホストとスタンバイ・ホストに、関連SBTバックアップおよびディスク・デバイスと通信するための異なるチャネル構成が設定されている場合があります。プライマリ・データベースとスタンバイ・データベースの両方がリカバリ・カタログで認識される場合は、両方のデータベースの構成設定はリカバリ・カタログに記録されています。プライマリ・データベースとスタンバイ・データベースには同じ
注意: 関連項目: Data Guard環境でサーバー・パラメータ・ファイルをリストアする手順の詳細は、『Oracle Data Guard概要および管理』を参照してください。 |
|
|
スタンバイ制御ファイルを指定されたファイル名にリストアします。 |
|
|
スタンバイ・データベースの制御ファイルをリストアします。Recovery Managerは、通常のバックアップ制御ファイルを透過的にリストアし、スタンバイ・データベースに対して使用できるようにします。
Recovery Managerは、ターゲット・データベースのリカバリ・カタログに認識されている最新のデータベース・ロール（RC_SITE
関連項目: 制限事項と使用上の注意は、表2-36を参照してください。
注意: リストアされた制御ファイルのマウント後は常にRECOVERコマンドを実行する必要があります。また、データベースは常に |
|
|
指定した表領域にあるすべてのデータファイルをリストアします（例2-112を参照）。
Recovery Managerは、表領域名をデータファイルのリストに内部的に変換します。表領域名を変更する場合（ 注意: Recovery Managerを使用して、ディクショナリ管理一時表領域はバックアップおよびリストアできますが、ローカル管理一時表領域はバックアップできません。ただし、ローカル管理一時表領域は、データベースのリストア後に自動的に再作成されます。 |
この副次句は、restoreObject句に対するオプションを指定します。これらのパラメータは、RESTOREコマンドのレベルで同じ名前を持つパラメータをオーバーライドします。
| 構文の要素 | 説明 |
|---|---|
|
|
このリストア操作に使用するチャネルの名前を指定します。このチャネル名には大/小文字区別があります。チャネル指定がないと、 |
|
|
制御ファイルの自動バックアップをリストアします（例2-115を参照）。
このオプションは、
Recovery Managerは、現在の日付またはSET 関連項目: 制限事項と使用上の注意は、表2-36を参照してください。 |
|
制御ファイルの自動バックアップの検索を制御するパラメータを指定します。 |
|
|
|
制御ファイルのコピー名、または制御ファイルを含むバックアップ・ピースの名前を指定します。 関連項目: 制限事項と使用上の注意は、表2-36を参照してください。 |
|
|
最新のバックアップまたは使用可能なファイル・コピーに関するデフォルトの選択をオーバーライドします。このタグは、自動選択の対象を、指定したタグで作成されたバックアップ・セットまたはファイル・コピーに制限するために使用します。複数のバックアップ・セットまたはコピーに一致するタグが存在していると、Recovery Managerは最新の内容を選択します。タグ名には、大/小文字区別はありません。 関連項目: 多重化バックアップ・セットの個々のコピーにタグを適用する方法と、タグのデフォルト・ファイル名形式については、「BACKUP」を参照してください。 |
この副次句は、制御ファイルの自動バックアップの検索を制御するパラメータを指定します。
| 構文の要素 | 説明 |
|---|---|
|
|
制御ファイルの自動バックアップの検索で使用する
|
|
|
制御ファイルの自動バックアップの検索を過去の指定した日数内に制限します。 |
|
|
制御ファイルの自動バックアップの検索での最大順序番号を指定します。 |
|
|
自動バックアップを検索するフラッシュ・リカバリ領域へのパスを指定します。 |
|
|
|
|
|
制御ファイルの自動バックアップの検索で使用する
|
|
|
リストア操作のターゲットである、指定したフラッシュ・リカバリ領域内のデータベースの
|
この例では、表領域をオフラインにし、リストアしてからメディア・リカバリを実行します。
SQL "ALTER TABLESPACE users OFFLINE IMMEDIATE";
RESTORE TABLESPACE users;
RECOVER TABLESPACE users;
SQL "ALTER TABLESPACE users ONLINE";
例2-113 リストアされるデータファイルの新しい名前の設定
データファイル9を格納している/disk1にメディア障害が発生したとします。この例では、データファイルに新しい名前を指定し、データファイルをリストアし、新しい名前を使用するように制御ファイルを更新してリカバリした後、オンライン化します。
RUN
{
SQL "ALTER DATABASE DATAFILE 9 OFFLINE";
SET NEWNAME FOR DATAFILE 9 TO '/disk2/users01.dbf';
RESTORE DATAFILE 9;
SWITCH DATAFILE ALL;
RECOVER DATAFILE 9;
SQL "ALTER DATABASE DATAFILE 9 ONLINE";
}
例2-114 リカバリ・カタログ使用時の制御ファイルのリストア
monday_cf_backupというタグが付いている制御ファイルのバックアップをリストアするとします。Recovery Managerクライアントを起動し、ターゲット・データベースおよびリカバリ・カタログ・データベースに接続して、次のコマンドを実行します。
RUN
{ # SET DBID is not necessary when RMAN is connected to a recovery catalog
STARTUP FORCE NOMOUNT;
RESTORE CONTROLFILE FROM TAG 'monday_cf_backup';
ALTER DATABASE MOUNT;
RESTORE DATABASE;
RECOVER DATABASE;
}
ALTER DATABASE OPEN RESETLOGS; # required after recovery with backup control file
Recovery Managerでは、制御ファイルがデフォルト位置にリストアされ、それがすべてのCONTROL_FILESの位置に自動的にレプリケートされます。Recovery Managerは、制御ファイルをマウントし、データベースのリストアとリカバリを行います。Recovery Managerでは、リカバリ・カタログのメタデータに基づいて、リストアしたデータベースの構造が反映されるように制御ファイルが自動的に更新されます。
制御ファイルと一部のデータファイルが消失し、テープからリストアする必要があるとします。この例では、Recovery Managerはリカバリ・カタログを使用しないため、リストアする制御ファイルを特定するにはSET DBIDコマンドが必要です。次に、テープから制御ファイルをリストアし、データベースをマウントしてから、データベースのリストアとリカバリを行います。
CONNECT TARGET /
STARTUP FORCE NOMOUNT;
SET DBID 36508508; # required when restoring control file in NOCATALOG mode
RUN
{
ALLOCATE CHANNEL c1 DEVICE TYPE sbt;
RESTORE CONTROLFILE FROM AUTOBACKUP;
ALTER DATABASE MOUNT;
RESTORE DATABASE;
RECOVER DATABASE;
}
ALTER DATABASE OPEN RESETLOGS;
例2-116 デフォルト以外の位置への制御ファイルの自動バックアップのリストア
この例は、例2-115を部分的に変更したものです。この例では、制御ファイルの自動バックアップはデフォルト以外の場所にあるディスクに格納されています。Recovery Managerは、順序番号20を持つバックアップから始めて、過去5か月にさかのぼって検索します。
CONNECT TARGET /
STARTUP FORCE NOMOUNT
SET DBID 36508508; # required when restoring control file in NOCATALOG mode
RUN
{
SET CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '/disk1/prod_cf_auto_%F';
RESTORE CONTROLFILE TO '/tmp/cf_auto.dbf' FROM AUTOBACKUP
MAXSEQ 20 MAXDAYS 150;
ALTER DATABASE MOUNT;
RESTORE DATABASE;
RECOVER DATABASE;
}
ALTER DATABASE OPEN RESETLOGS;
例2-117 現行の位置へのサーバー・パラメータ・ファイルの自動バックアップのリストア
次の一連のコマンドは、現行のサーバー・パラメータ・ファイルをNOCATALOGモードでリストアしてから、リストアされたサーバー・パラメータ・ファイルを使用してインスタンスを起動します。
CONNECT TARGET /
SET DBID 1620189241; # set dbid to dbid of target database
STARTUP FORCE NOMOUNT; # start instance with dummy SPFILE
RUN
{
ALLOCATE CHANNEL c1 DEVICE TYPE sbt;
RESTORE SPFILE FROM AUTOBACKUP; # FROM AUTOBACKUP needed in NOCATALOG mode
STARTUP FORCE; # startup with restored SPFILE
}
例2-118 バックアップのプレビュー
この例では、RESTORE ... PREVIEWコマンドの結果が表示されます。アーカイブREDOログのリストアに使用するためにRecovery Managerで選択するバックアップ・セットが示されています。
RMAN> RESTORE ARCHIVELOG ALL DEVICE TYPE sbt PREVIEW;
Starting restore at 01-MAR-07
released channel: ORA_SBT_TAPE_1
allocated channel: ORA_SBT_TAPE_1
channel ORA_SBT_TAPE_1: SID=85 device type=SBT_TAPE
channel ORA_SBT_TAPE_1: Oracle Secure Backup
List of Backup Sets
===================
BS Key Size Device Type Elapsed Time Completion Time
------- ---------- ----------- ------------ ---------------
53 1.25M SBT_TAPE 00:00:18 01-MAR-07
BP Key: 53 Status: AVAILABLE Compressed: NO Tag: TAG20070301T150155
Handle: 2aibhej3_1_1 Media: RMAN-DEFAULT-000001
List of Archived Logs in backup set 53
Thrd Seq Low SCN Low Time Next SCN Next Time
---- ------- ---------- --------- ---------- ---------
1 8 526376 01-MAR-07 527059 01-MAR-07
1 9 527059 01-MAR-07 527074 01-MAR-07
1 10 527074 01-MAR-07 527091 01-MAR-07
1 11 527091 01-MAR-07 527568 01-MAR-07
1 12 527568 01-MAR-07 527598 01-MAR-07
validation succeeded for backup piece
Finished restore at 01-MAR-07
例2-119 オフサイト・ストレージからのオフサイト・バックアップの再呼出し
バックアップのオフサイト・ストレージに関する情報をレポートし、オフサイト・バックアップの再呼出しをサポートするメディア・マネージャとともに使用すると、RESTORE ... PREVIEW RECALLは、バックアップからのアーカイブ・ログのリストアに必要なメディアをオフサイト・ストレージから再呼出しすることを要求します。
RMAN> RESTORE ARCHIVELOG ALL PREVIEW RECALL;
Starting restore at 10-JUN-06
using channel ORA_DISK_1
using channel ORA_SBT_TAPE_1
List of Backup Sets
===================
BS Key Size Device Type Elapsed Time Completion Time
------- ---------- ----------- ------------ ---------------
31 12.75M SBT_TAPE 00:00:02 10-JUN-06
BP Key: 33 Status: AVAILABLE Compressed: NO Tag: TAG20050610T152755
Handle: 15gmknbs Media: /v1,15gmknbs
List of Archived Logs in backup set 31
Thrd Seq Low SCN Low Time Next SCN Next Time
---- ------- ---------- --------- ---------- ---------
1 1 221154 06-JUN-06 222548 06-JUN-06
1 2 222548 06-JUN-06 222554 06-JUN-06
1 3 222554 06-JUN-06 222591 06-JUN-06
1 4 222591 06-JUN-06 246629 07-JUN-06
1 5 246629 07-JUN-06 262451 10-JUN-06
BS Key Size Device Type Elapsed Time Completion Time
------- ---------- ----------- ------------ ---------------
32 256.00K SBT_TAPE 00:00:01 10-JUN-06
BP Key: 34 Status: AVAILABLE Compressed: NO Tag: TAG20050610T153105
Handle: 17gmknhp_1_1 Media: /v1,17gmknhp_1_1
List of Archived Logs in backup set 32
Thrd Seq Low SCN Low Time Next SCN Next Time
---- ------- ---------- --------- ---------- ---------
1 6 262451 10-JUN-06 262547 10-JUN-06
1 7 262547 10-JUN-06 262565 10-JUN-06
Initiated recall for the following list of offsite backup files
==========================================================
Handle: 15gmknbs Media: /v1,15gmknbs
Finished restore at 10-JUN-06
例2-120 バックアップのリストアの検証
次の例では、RESTORE... VALIDATEを使用して、データベースのリストアに必要なバックアップがディスクまたはテープに存在し、読取り可能で破損していないことを確認する方法を示します。
RMAN> RESTORE DATABASE VALIDATE;
Starting restore at 01-MAR-07
using channel ORA_DISK_1
allocated channel: ORA_SBT_TAPE_1
channel ORA_SBT_TAPE_1: SID=85 device type=SBT_TAPE
channel ORA_SBT_TAPE_1: Oracle Secure Backup
channel ORA_DISK_1: starting validation of datafile backup set
channel ORA_DISK_1: reading from backup piece /disk2/PROD/backupset/2007_03_01/o1_mf_nnndf_TAG20070301T161038_2ygtvzg0_.bkp
channel ORA_DISK_1: piece handle=/disk2/PROD/backupset/2007_03_01/o1_mf_nnndf_TAG20070301T161038_2ygtvzg0_.bkp tag=TAG20070301T161038
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: validation complete, elapsed time: 00:00:16
Finished restore at 01-MAR-07
RESYNC CATALOGコマンドを使用すると、リカバリ・カタログ・スキーマとターゲット・データベース制御ファイルとのメタデータの完全再同期化を実行できます。また、FROM CONTROLFILECOPY句を使用して、現行の制御ファイルを制御ファイルのコピー内のRecovery Managerメタデータと再同期化することもできます。
通常、次の場合にRESYNC CATALOGを実行します。
ARCHIVELOGモードで実行されている場合。これは、オンラインREDOログ・スイッチが発生するときや、REDOログをアーカイブするときにリカバリ・カタログが自動的に更新されないためです。
TARGETとしてスタンバイ・データベースに接続されている場合。このデータベースで実行されたRecovery Manager操作に関するメタデータを使用してリカバリ・カタログを更新する場合。
TARGETとしてスタンバイ・データベースに接続されている場合。プライマリ・データベースでの物理的な変更に関するメタデータを使用してリカバリ・カタログを更新する場合（例2-123を参照）。
Recovery Managerがマウント済またはオープン状態のデータベースにTARGETとして接続され、またリカバリ・カタログ・データベースにCATALOGとして接続されている必要があります。
完全同期化と部分同期化のどちらでも実行できます。完全再同期化を実行するときに、ターゲット・データベースにマウントされた現行の制御ファイルがある場合（ただし、新しく作成された制御ファイルおよび以前に使用された制御ファイルより古い制御ファイルを除く）、Recovery Managerは物理スキーマについて変更があったすべてのレコード（データファイル、表領域、REDOスレッドおよびオンラインREDOログ）を更新します。データベースがオープン状態の場合、Recovery Managerはロールバック・セグメントについてのデータも取得します。部分再同期化では、Recovery Managerは物理スキーマおよびロールバック・セグメントに関するメタデータの再同期化は行いません。
Recovery Managerコマンドの実行時にターゲット制御ファイルがマウントされており、カタログ・データベースが使用可能である場合、Recovery Managerは必要に応じてコマンドの実行時にリカバリ・カタログを自動的に再同期化します。データベース構造の変更（データベース・ファイルの追加または削除、新規のインカネーションの作成など）後、またはRecovery Managerの永続構成の変更後に完全再同期化を実行します。
Oracle Database 11g 以上では、Data Guard環境で単一のリカバリ・カタログ・スキーマがすべてのデータベースのデータベース・ファイル名を追跡できます。また、このカタログ・スキーマは、すべてのデータベースのオンラインREDOログ、スタンバイREDOログ、一時ファイル、アーカイブREDOログ、バックアップ・セットおよびイメージ・コピーが作成される場所も追跡します。Recovery Managerは、TARGETとしてスタンバイ・データベースに接続されているときに、プライマリ・データベースのスタンバイ制御ファイルに物理スキーマの変更に関する情報が格納されていると、暗黙的に完全再同期化を実行します。
| 構文の要素 | 説明 |
|---|---|
|
|
ターゲット・データベースの現行の制御ファイル（デフォルト）内のRecovery Managerメタデータで、リカバリ・カタログを更新します。
Recovery Managerによって、制御ファイルの読取り一貫性ビューを取得するために、スナップショット制御ファイルが作成され、次に、スナップショットからの新しい情報でリカバリ・カタログが更新されます。
|
|
|
制御ファイルのコピーからのRecovery Managerメタデータで、現行の制御ファイルおよびリカバリ・カタログを更新します（例2-122を参照）。filenameを使用して、再同期化に使用する制御ファイルのコピーの名前を指定します。
注意: 制御ファイルのコピーは、現行のデータベース・インカネーション内に存在しているか、または以前のインカネーション（最新の |
|
|
リカバリ・カタログを、指定した1つ以上のデータベースの制御ファイルのメタデータで再同期化します（例2-124を参照）。
リカバリ・カタログ内のデータベースは、
注意:
指定されたデータベースに対して
例として、最近、Recovery Managerを |
この例では、アーカイブされていないREDOログをすべてアーカイブしてから、ターゲット・データベースの完全再同期化を実行します。
RMAN> CONNECT TARGET /
RMAN> CONNECT CATALOG rman@catdb
recovery catalog database Password: password
connected to recovery catalog database
RMAN> SQL "ALTER SYSTEM ARCHIVE LOG CURRENT";
RMAN> RESYNC CATALOG;
例2-122 制御ファイル・コピーからのリカバリ・カタログの再同期化
Recovery Managerクライアントを起動し、ターゲット・データベースとリカバリ・カタログに接続するとします。次のコマンドでは、ターゲット・データベースを停止してマウントし、バックアップ制御ファイルからのメタデータを使用して現行の制御ファイルのRecovery Managerリポジトリを更新した後、データベースをオープンします。
STARTUP FORCE MOUNT
RESYNC CATALOG FROM CONTROLFILECOPY '/disk1/cfile.dbf';
ALTER DATABASE OPEN;
例2-123 構造を変更後のリカバリ・カタログの再同期化
プライマリ・データベースprodおよびスタンバイ・データベースstandby3を含むData Guard環境があるとします。次のように、SQL*Plusを起動し、データベースprodに接続して、データファイルを表領域usersに追加します。
SQL> ALTER TABLESPACE users ADD DATAFILE ''?/oradata/prod/users03.dbf''
2 SIZE 1M AUTOEXTEND ON
3 NEXT 10K MAXSIZE 10M";
目標は、この変更に関するメタデータを使用してリカバリ・カタログを更新することです。変更が standby3に伝播された後に、Recovery Managerクライアントを起動し、TARGETとしてstandby3に接続し、リカバリ・カタログに接続します。次に、RESYNCコマンドを使用して、カタログをスタンバイ・データベースの制御ファイルと再同期させます。
RMAN> RESYNC CATALOG;
リカバリ・カタログは、データベースprodのusers表領域に追加されたデータファイルに関するメタデータを使用して更新されます。
Data Guard環境に、プライマリ・データベースprodおよびスタンバイ・データベースdgprod3が存在するとします。目標は、dgprod3のRecovery Manager構成を作成することです。
Recovery ManagerをTARGETとしてデータベースprodに接続してから、リカバリ・カタログに接続します。次のように、CONFIGUREを使用して、リカバリ・カタログでdgprod3のRecovery Managerの永続構成を更新します。
CONFIGURE DEFAULT DEVICE TYPE TO sbt FOR DB_UNIQUE_NAME dgprod3;
CONFIGURE DB_UNIQUE_NAME dgprod3 CONNECT IDENTIFIER 'inst3';
dgprod3ではまだバックアップ操作やその他のRecovery Manager操作を実行していないため、dgprod3の制御ファイルおよびdgprod3のリカバリ・カタログ・メタデータは同期化されていません。次のように、同じRecovery Managerセッションで、dgprod3の制御ファイルをリカバリ・カタログと同期させます。
RESYNC CATALOG FROM DB_UNIQUE_NAME dgprod3;
Recovery Managerは、dgprod3でデフォルトのデバイス・タイプをSBTに更新し、dgprod3制御ファイルの名前を使用してリカバリ・カタログを更新します。
REVOKEコマンドを使用すると、GRANTコマンドで付与されたリカバリ・カタログ権限を取り消すことができます。
このコマンドは、RUNコマンドのカッコ内またはRecovery Managerプロンプトで実行してください。
仮想プライベート・カタログ・ユーザーにREGISTER DATABASE権限が付与され、これにより、登録されているすべてのデータベースに対するCATALOG FOR DATABASE権限が暗黙的に付与されたとします。このユーザーは複数のデータベースを登録します。REVOKEを使用してこのユーザーからREGISTER DATABASE権限を取り消しても、このユーザーは引き続き、登録されているデータベースのCATALOG FOR DATABASE権限を保持します。CATALOG権限には、指定したデータベースの登録と登録解除が含まれます。
このユーザーがデータベースのメタデータへのアクセスやデータベースの追加登録を行えないようにするには、このユーザーに対してREVOKE ALL PRIVILEGESを実行します。このユーザーが登録したデータベースのサブセットに対するCATALOG権限を取り消すには、サブセット内の各データベースに対してREVOKE CATALOG FOR DATABASEを実行します。
| 構文の要素 | 説明 |
|---|---|
|
|
指定したデータベースのリカバリ・カタログへのアクセス権を、指定したユーザーから取り消します。 データベースは、データベース名またはDBIDで指定できます。データベース名で指定した場合、その名前のデータベースがリカバリ・カタログに複数登録されていると、Recovery Managerによりエラーが戻されます。その場合は、DBIDでデータベースを指定してください。 |
|
|
指定したユーザーがこのリカバリ・カタログに新規データベースを登録できないようにします（例2-125を参照）。 |
|
|
指定したユーザーからすべての |
|
|
権限を取り消すユーザーの名前を指定します。 |
Recovery Managerをリカバリ・カタログ所有者rcoとして基本リカバリ・カタログに接続するとします。基本カタログ所有者として、次のように、Recovery ManagerのGRANTコマンドを使用して、bckop2に自分の仮想プライベート・カタログにすべてのデータベースを登録する権限を付与するとします。ただし、bckop3には、データ・センター内のデータベースのサブセットのみへのアクセス権を付与します。
RMAN> CONNECT CATALOG rco@catdb
recovery catalog database Password: password
connected to recovery catalog database
RMAN> GRANT REGISTER DATABASE TO bckop2;
RMAN> GRANT CATALOG FOR DATABASE prod TO bckop3;
RMAN> GRANT CATALOG FOR DATABASE prodb TO bckop3;
RMAN> EXIT;
その後、ユーザーbckop2の権限を制限し、このユーザーが新規データベースを登録できないようにします。したがって、rcoとして基本カタログに接続し、REVOKEコマンドを実行します。bckop2は引き続き、自分が登録したデータベースに対するカタログ権限を保持することに注意してください。
RMAN> CONNECT CATALOG rco@catdb
recovery catalog database Password: password
connected to recovery catalog database
RMAN> REVOKE REGISTER DATABASE FROM bckop2;
RMANコマンドを使用すると、オペレーティング・システムのコマンドラインからRecovery Managerを起動できます。
データベースへのSQL*Plus接続と同様に、データベースへのRecovery Manager接続が指定され、認証されます。唯一異なるのは、ターゲット・データベースまたは補助データベースへのRecovery Manager接続ではSYSDBA権限が必要なことです。AS SYSDBAキーワードは暗黙的に指定されおり、明示的に指定することはできません。SQL*Plus使用時のデータベース接続オプションについては、 『Oracle Database管理者ガイド』を参照してください。
RMANコマンドと任意のオプションは、Recovery Managerプロンプトではなく、オペレーティング・システムのコマンドラインで発行する必要があります。
オペレーティング・システムのプロンプトで入力するコマンド名は、オペレーティング・システムによって異なります。たとえば、LinuxシステムおよびUNIXシステムでは、小文字でrmanと入力します。
オペレーティング・システムのコマンドラインでCATALOGまたはNOCATALOGを指定せずにRecovery Managerを起動した場合、CONNECT CATALOGコマンドを実行しないかぎり、Recovery ManagerセッションはNOCATALOGモードになります（例2-126を参照）。リカバリ・カタログを保持する場合は、Recovery Manager操作を実行する前にリカバリ・カタログに接続することをお薦めします。
| 構文の要素 | 説明 |
|---|---|
|
|
新規出力をメッセージ・ログ・ファイルの終わりに追加させます。このパラメータを指定せず、かつメッセージ・ログ・ファイルと同じ名前のファイルがすでにある場合、Recovery Managerはそのファイルを上書きします。 |
|
|
入力されたコマンドに対して構文エラーをチェックするモードでRecover Managerを起動させますが、それ以外の処理は実行しません（例2-129を参照）。引数
Recovery Managerは、構文が正しくないそれぞれのコマンドに対してエラー |
|
|
補助データベースへの接続文字列を指定します。たとえば、 関連項目: 「connectStringSpec」を参照してください。 |
|
|
リカバリ・カタログを格納するデータベースへの接続文字列を指定します。たとえば、 関連項目: 「connectStringSpec」を参照してください。 |
|
|
ファイル内のすべてのRecovery Managerコマンドを解析し、コンパイルしてから、順番に実行します。解析フェーズで構文エラーが発生するか、実行フェーズでランタイム・エラーが発生すると、Recovery Managerは終了します。エラーが見つからなければ、Recovery Managerはジョブの完了後に終了します。 ファイル名の最初の文字がアルファベットの場合は、ファイル名を囲む引用符を省略できます。コマンド・ファイルの内容は、Recovery Managerプロンプトに入力した内容と同じにする必要があります。 注意: コマンド・ファイルをオペレーティング・システムのコマンドラインでオプションとして実行するのではなく、Recovery Managerプロンプトから実行すると、ファイルは1つのジョブとして実行されません。Recovery Managerは各行を順次読み込んで実行し、スクリプトの最終行に達した場合にのみ終了します。 |
|
|
|
|
|
|
|
|
Recovery Managerがその出力を記録するファイルを指定します。Recovery Manager出力とは、処理したコマンドとその結果です。Recovery Managerはプロンプトにコマンド入力を表示しますが、コマンド出力は表示しません。コマンド出力はログ・ファイルに書き出されます。デフォルトでは、Recovery Managerはメッセージ・ログ・ファイルを標準出力に書き出します。
また、Recovery Manager出力は、
注意: Recovery Managerの出力をログ・ファイルと標準出力の両方に送信する最も簡単な方法は、Linuxの % rman | tee rman.log |
|
|
Recovery Managerで、メッセージ番号を出力します。つまり、すべてのコマンドの出力に対して、 |
|
|
リカバリ・カタログなしでRecovery Managerを使用するように指定します。 |
|
|
ベンダー固有のコマンド文字列を割り当てられたチャネルすべてに送信します。 関連項目: この機能のサポートの有無は、メディア管理ソフトウェアのドキュメントおよび「SEND」を参照してください。 |
|
|
Recovery Managerパイプ・インタフェースを起動します。Recovery Managerでは、コマンドの受信用と出力の送信用に1つずつ、2つのパブリック・パイプが使用されます。パイプ名は Recovery Managerはターゲット・データベース内で次のパイプをオープンします。
入力パイプと出力パイプに関するメッセージは、すべて 関連項目: パイプを通じてRecovery Managerにコマンドを渡す方法については、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。 |
|
|
Recovery Managerは、ターゲット・データベースおよびリカバリ・カタログ（ ストアド・スクリプト名が数字またはRecovery Managerの予約語で始まる場合は、そのスクリプト名を一重引用符で囲む必要があります（「Recovery Managerの予約語」を参照）。数字で始まるスクリプト名またはRecovery Managerの予約語と一致するスクリプト名は作成しないようにする必要があります。 関連項目: ストアド・スクリプトの詳細は、「CREATE SCRIPT」を参照してください。 |
|
|
ターゲット・データベースへの接続文字列を指定します。たとえば、 関連項目: 「connectStringSpec」を参照してください。 |
|
|
関連項目: パイプを通じてRecovery Managerにコマンドを渡す方法については、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。 |
|
|
コマンド・ファイルの置換変数で使用する値を1つ以上指定します。SQL*Plusの場合と同じく、
置換変数の構文は、
関連項目: ストアド・スクリプトを実行する場合の |
この例では、オペレーティング・システム・プロンプトでデータベース接続オプションを指定せずにRecovery Managerクライアントを起動します。Recovery Managerプロンプトで、CONNECTコマンドを実行してターゲット・データベースに接続します。CONNECT CATALOGがRecovery Managerプロンプトで実行されなかったため、Recovery Managerはリポジトリ接続を必要とする最初のコマンド（この場合は、BACKUP DATABASEコマンド）の実行時にデフォルトのNOCATALOGモードで接続します。
% rman
RMAN> CONNECT TARGET /
RMAN> BACKUP DATABASE;
例2-127 補助データベース・インスタンスへのRecovery Managerの接続
この例では、ターゲット・データベースprodおよびリカバリ・カタログ・データベースcatdbにはネット・サービス名を使用して接続し、補助データベース・インスタンスにはオペレーティング・システム認証を使用して接続します。
% rman TARGET SYS@prod
Recovery Manager: Release 11.1.0.6.0 - Production
Copyright (c) 1982, 2007, Oracle. All rights reserved.
target database Password: password
connected to target database: PROD (DBID=39525561)
RMAN> CONNECT CATALOG rman@catdb
recovery catalog database Password: password
connected to recovery catalog database
RMAN> CONNECT AUXILIARY /
例2-128 置換変数の指定
データベースをバックアップするLinuxシェル・スクリプトを作成するとします。シェル変数を使用して、実行時にRecovery Managerのバックアップ・スクリプトに引数を渡すことができるようにします。置換変数を使用すると、この問題が解決します。最初に、次のような内容で、whole_db.cmdという名前のコマンド・ファイルを作成します。
cat > /tmp/whole_db.cmd <<EOF
# name: whole_db.cmd
CONNECT TARGET /
BACKUP TAG &1 COPIES &2 DATABASE FORMAT '/disk2/db_%U';
EXIT;
EOF
次に、Linuxシェル・スクリプトを次のように記述します。このスクリプトでは、cshシェル変数をtagnameおよびcopiesに設定します。シェル・スクリプトにより、Recovery Managerが起動され、ターゲット・データベースprod1に接続され、whole_db.cmdが実行されます。USING句は、実行時に変数tagnameおよびcopiesの値をRecovery Managerコマンド・ファイルに渡します。
#!/bin/csh
# name: runbackup.sh
# usage: use the tag name and number of copies as arguments
set tagname = $argv[1]
set copies = $argv[2]
rman @'/tmp/whole_db.cmd' USING $tagname $copies LOG /tmp/runbackup.out
# note that the preceding line is equivalent to:
# rman @'/tmp/whole_db.cmd' $tagname $copies LOG /tmp/runbackup.out
最後に、次のようにLinuxシェルからシェル・スクリプトrunbackup.shを実行し、タグQ106を使用してデータベースのバックアップを2つ作成します。
% runbackup.sh Q106 2
例2-129 コマンド・ファイルの構文のチェック
次のように、コマンド・ファイルbackup_db.cmdを作成するとします。
cat > /tmp/backup_db.cmd <<EOF
CONNECT TARGET /
BACKUP DATABASE;
EXIT;
EOF
次の例では、コマンド・ファイルbackup_db.cmdの内容を構文チェックします（例には出力例も含まれます）。
% rman CHECKSYNTAX @'/tmp/backup_db.cmd'
Recovery Manager: Release 11.1.0.6.0 - Production on Wed Jul 11 17:51:30 2007
Copyright (c) 1982, 2007, Oracle. All rights reserved.
RMAN> CONNECT TARGET *
2> BACKUP DATABASE;
3> EXIT;
The cmdfile has no syntax errors
Recovery Manager complete.
例2-130 ストアド・スクリプトの実行とメッセージ・ログへの出力の追加
この例では、オペレーティング・システム認証を使用してターゲット・データベースに接続した後、ストアド・スクリプトwdbbを実行します。Recovery Managerにより、出力がメッセージ・ログ/tmp/wdbb.logに書き込まれます。
% rman TARGET / SCRIPT wdbb LOG /tmp/wdbb.log
例2-131 Recovery Managerパイプ・インタフェースの起動
この例では、タイムアウト・オプションで90秒を指定して、Recovery Managerパイプnewpipeを起動します。
% rman PIPE newpipe TARGET / TIMEOUT 90
RUNコマンドを使用すると、一連のRecovery Managerコマンドをブロックにグループ化して、順番に実行できます。RUNブロックの閉じカッコを読み取ると、Recovery Managerは、ジョブ・コマンドのリストを1つ以上のジョブ手順にコンパイルした後、すぐにその手順を実行します。
このコマンドは、Recovery Managerプロンプトでのみ実行してください。ジョブ・コマンドのリストの前には開きカッコ（{）、後には閉じカッコ（}）が必要です。
RUNを使用すると、スクリプトでデフォルトの構成をオーバーライドできる有効範囲を作成できます。たとえば、ALLOCATE CHANNELおよびRELEASE CHANNELコマンドを使用して構成済チャネルをオーバーライドしたり、SETコマンドを使用してその他のパラメータをオーバーライドすることができます（例2-132を参照）。RUNブロックにリストされているコマンドの実行後に、RUNブロック内に割り当てられたチャネルが解放され、設定がそれぞれの値に戻されます。
例2-133に示すように、RUNブロック内でEXECUTE SCRIPTコマンドを使用する必要があります。
（backupCommands::=、maintenanceCommands::=、miscellaneousCommands::=、restoreCommands::=）
Recovery Managerプロンプトから実行できるコマンドについての情報は、各コマンドの項目を参照してください。
デバイス構成が次のようになっているとします。
RMAN> SHOW DEVICE TYPE;
RMAN configuration parameters for database with db_unique_name PROD1 are:
CONFIGURE DEVICE TYPE DISK PARALLELISM 1 BACKUP TYPE TO BACKUPSET; # default
CONFIGURE DEVICE TYPE SBT_TAPE PARALLELISM 1 BACKUP TYPE TO BACKUPSET; # default
デフォルト以外のディレクトリにバックアップを作成します。構成を変更するかわりに、次のようにジョブ内でオーバーライドすることもできます。
RUN
{
ALLOCATE CHANNEL c1 DEVICE TYPE DISK FORMAT "/disk2/%U";
BACKUP DATABASE PLUS ARCHIVELOG;
}
例2-133 Recovery Managerスクリプトの実行
CREATE SCRIPTコマンドを使用して、backup_dbという名前のバックアップ・スクリプトを作成するとします。この例では、次のストアド・スクリプトを実行します。
RUN { EXECUTE SCRIPT backup_db; }
SENDコマンドを使用すると、ベンダー固有の文字列を、メディア・マネージャでサポートされている1つ以上のチャネルに送信できます。どのコマンドがサポートされているかは、使用しているメディア管理のドキュメントを参照してください。
DEVICE TYPEまたはCHANNELを指定しないかぎり、Recovery Managerは割り当てられたすべてのチャネルを使用します。
| 構文の要素 | 説明 |
|---|---|
|
|
どのチャネルを使用するかを指定します。 |
|
|
ストレージ・デバイスのタイプを指定し、コマンドを指定したタイプのすべてのチャネルに送信します。 関連項目: 「deviceSpecifier」を参照してください。 |
|
|
関連項目: どのコマンドがサポートされているかは、使用しているメディア管理のドキュメントを参照してください。メディア・マネージャでサポートされているコマンドのみを送信してください。文字列の内容は、データベースでは解釈されず、そのままメディア管理サブシステムに渡されます。 |
|
|
メディア・マネージャと通信するチャネルのパラメータを指定します。 |
この例では、SENDコマンドを使用して、users表領域のOracle Secure Backupへのバックアップに使用するテープ・ドライブを指定します。パラメータOB_DEVICEとテープ・ドライブの名前の間には等号記号は挿入されないことに注意してください。
RUN
{
ALLOCATE CHANNEL c1 DEVICE TYPE sbt;
SEND 'OB_DEVICE stape1';
BACKUP TABLESPACE users;
}
SETコマンドを使用すると、ジョブまたはセッション内のRecovery Managerの動作を制御できます。セッション全体で保持されるオプションを構成するには、CONFIGUREを使用します。
SETコマンドは、Recovery ManagerプロンプトまたはRUNブロック内で使用できます。Recovery Managerプロンプトで使用する場合、SETで行われた変更は、Recovery Managerクライアントを終了するまで保持されます（「setRmanOption」を参照）。RUNブロック内で使用する場合、SETで行われた変更は、RUNブロック、または同じ属性の値を変更する次のSETコマンドが終了するまで保持されます（「setRunOption」を参照）。
（setRmanOption::=、setRunOption::=）
（deviceSpecifier::=、formatSpec::=）
（deviceSpecifier::=、formatSpec::=、datafileSpec::=、tempfileSpec::=、untilClause::=）
（deviceSpecifier::=、formatSpec::=）
この副次句では、RUNブロック外で使用可能なSETオプションを指定します。
| 構文の要素 | 説明 |
|---|---|
|
|
バックアップ・セットの圧縮アルゴリズムを指定します。このコマンドは、現行のRecovery Managerセッションの現行のCONFIGURE
注意: サポートされているアルゴリズムは、 |
|
|
デュアル・モードのバックアップまたはパスワードで暗号化されたバックアップを読み取る際に使用する1つ以上の復号化パスワードを指定します。 パスワードで暗号化されたバックアップでは、正しいパスワードを入力しないとリストアできません。Recovery Managerでは、暗号化されたバックアップ・ピースが読み取られると、そのバックアップ・ピースを複合化するための正しいパスワードが検出されるまでリスト内の各パスワードが試用されます。指定したいずれのキーも有効でない場合は、Recovery Managerによりエラーが発行されます。
注意: 別のパスワードを使用して作成されたバックアップのグループからリストアを行う場合、 関連項目: 「バックアップ・セットの暗号化」を参照してください。 |
|
|
Recovery Managerコマンドをメッセージ・ログに表示するかどうかを制御します。コマンド・ファイルからコマンドを読み込むとき、Recovery Managerはそれらのコマンドを自動的にメッセージ・ログに表示します。標準入力からコマンドを読み取る場合、デフォルトでは、Recovery Managerはそれらのコマンドをメッセージ・ログに表示しません。Recovery Managerでコマンドを表示するには、コマンド・ファイルを実行する前に
このコマンドは、 % rman TARGET / < in_file > out_file
|
|
|
Recovery Managerセッションの実行時に、バックアップ・セットを作成するBACKUPコマンドを適用する暗号化関連オプションを指定します。 関連項目: 「バックアップ・セットの暗号化」を参照してください。 |
|
|
このRecovery Managerセッション実行時に使用するアルゴリズムを指定します。CONFIGURE |
|
|
次の規則に従って、バックアップの暗号化でユーザー指定のパスワードを採用するかどうかを指定します。
安全なパスワードを作成します。詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください。
パスワードは、引用符で囲まない場合、内部で大文字に変換されることに注意してください。したがって、次の句は、すべて 注意: Walletベースの暗号化は、パスワードが含まれないため、パスワード・ベースの暗号化よりも安全です。パスワード・ベースの暗号化は、バックアップをトランスポータブルにする必要があるため、必要な場合のみ使用してください。 関連項目: 様々な暗号化モードの詳細は、「バックアップ・セットの暗号化」を参照してください。 |
|
|
バックアップ・セットを暗号化するかどうかを指定します。
このオプションは、CONFIGURE
|
|
|
すべての表領域の暗号化を制御し、 |
この副次句では、RUNブロック内で使用可能なSETオプションを指定します。
| 構文の要素 | 説明 |
|---|---|
|
|
後続のRESTOREおよびRECOVERコマンドでリストアされるアーカイブREDOログの名前を構成するときに、ターゲット・データベースの
このコマンドを使用すると、データベースのリストア中に、異なる位置にアーカイブ・ログを移動できます。Recovery Managerは新しくリストアされたアーカイブ・ログがどこにあるかを認識しています。アーカイブ・ログが すでにディスクには存在していないアーカイブREDOログのリストアに、このパラメータを使用します。Recovery Managerは、ログをバックアップからリストアする前に、それがディスク上にあるかどうかを必ず最初に調べます。 |
|
|
チャネルが作成する必要がある各バックアップ・ピースのコピー数として
Recovery Managerは、バックアップをディスクまたはテープのいずれかに多重化できますが、テープとディスクに同時に多重化することはできません。テープにバックアップを行う場合は、コピー数が使用可能なテープ・デバイスの数を超えないようにします。また、
バックアップ・ピースの名前は、
注意: 注意: 制御ファイルのディスクへの自動バックアップは特殊ケースであり、多重化されることはありません。Recovery Managerが書き込むコピーは常に1つのみです。 |
|
|
指定したデータファイルまたはデータファイルのグループ内でデータベースが許容する未検出のブロック破損数に制限を設定します。デフォルトは0（ゼロ）で、Recovery Managerが破損ブロックを許容しないことを意味します。
注意: 関連項目: 「datafileSpec」を参照してください。 |
|
|
指定したデータファイルに影響を与える、後続のすべてのRESTOREコマンドまたはSWITCHコマンドについて、デフォルト名を設定します。データファイル・リストア操作の前にこのコマンドを発行しない場合、Recovery Managerはファイルをそのデフォルトの位置にリストアします。
データファイルを新しい位置にリストアすると、SWITCHを実行して制御ファイル内でファイルの名前を
複製データベースやスタンバイ・データベースの作成時、またはRecovery ManagerのTSPITRの実行時には、
注意: 関連項目: 「 datafileSpec」を参照してください。 |
|
|
後続のSWITCHコマンドに新しい一時ファイル名を指定します。このコマンドは指定した一時ファイルを指定した名前に変更します。
複製データベースやスタンバイ・データベースの作成時、またはRecovery ManagerのTSPITRの実行時には、
注意: 関連項目: 「tempfileSpec」を参照してください。 |
|
|
リストアされるデータファイルまたは一時ファイルに対して、ユーザー定義ファイル名または自動ストレージ管理ディスク・グループを指定します。 |
|
|
DUPLICATEコマンドを使用する場合、またはRecovery ManagerのTSPITRを実行する場合は、このオプションを使用できません。 関連項目: Oracle Managed Filesの詳細は、 『Oracle Database管理者ガイド』 を参照してください。 |
|
|
リストア・ポイントを作成した時点のSCNを上限として、後続のRESTOREまたはRECOVERコマンドのリストア・ポイントを指定します。指定した値は含まれます。上限値が含まれるため、Recovery Managerは、リストア・ポイントに対応するSCNまでファイルをリストアまたはリカバリできるファイルのみを選択します。
注意: 定義済のリストア・ポイントは制御ファイルに記録されているため、 |
|
後続のRESTOREまたはRECOVERコマンドで使用する終了時刻、SCNまたはログ順序番号を指定します。 関連項目: 「untilClause」を参照してください。 |
この副次句では、RUNブロックの内部または外部で使用可能なSETオプションを指定します。
| 構文の要素 | 説明 |
|---|---|
|
|
インスタンスの起動に使用するパラメータ・ファイルへのパスを指定します。このパラメータは、自動補助インスタンスでTSPITRをカスタマイズする場合、または、Recovery ManagerでRecovery Manager表領域をクローニングする場合に使用できます。
注意:
関連項目: |
|
|
指定した文字列をすべてのチャネルの
1番目の形式は、Recovery Managerターゲット・データベース接続で使用されます。2番目の形式は、割り当てられたすべてのチャネルについて使用されます。現行のジョブが完了すると、
関連項目: |
|
|
指定したデバイス・タイプの制御ファイルの自動バックアップについて、デフォルトのファイル名形式をオーバーライドします。このコマンドはRUNコマンド内またはRecovery Managerプロンプトで使用できます。優先順位は次のとおりです。 Recovery Managerプロンプトで実行される
新しい
関連項目: |
|
|
DBIDを指定します。データベースの作成時に計算される一意で32ビットの識別番号です。
Recovery Managerは、ターゲット・データベースへの接続時にDBIDを表示します。DBIDを取得するには、
|
この例では、コマンドIDをrmanに設定し、データベースをバックアップして、オンラインREDOログをアーカイブします。コマンドIDを使用すると、WHERE LIKE '%rman%'を指定したV$SESSIONへの問合せで、ジョブのステータス情報がわかります。
RUN
{
ALLOCATE CHANNEL d1 DEVICE TYPE DISK FORMAT '/disk1/%U';
ALLOCATE CHANNEL d2 DEVICE TYPE DISK FORMAT '/disk2/%U';
SET COMMAND ID TO 'rman';
BACKUP INCREMENTAL LEVEL 0 DATABASE;
SQL 'ALTER SYSTEM ARCHIVE LOG CURRENT';
}
例2-136 バックアップ・セットの多重化
現行の多重化構成が次のようになっているとします。
CONFIGURE ARCHIVELOG COPIES FOR DEVICE TYPE sbt TO 3;
CONFIGURE DATAFILE COPIES FOR DEVICE TYPE sbt TO 3;
テープ・ドライブのうち1台が故障し、使用できるテープ・ドライブが2台のみになりました。テープ・バックアップでは、一般に、チャネル数とコピー数を掛けた数が、デバイスの数に等しくなるようにします。次の例では、多重化の永続構成をSET BACKUP COPIESでオーバーライドし、データベース・バックアップの2つのコピーを、機能している2つのテープ・ドライブに書き出します。
RUN
{
ALLOCATE CHANNEL dev1 DEVICE TYPE sbt
PARMS 'ENV=(OB_DEVICE_1=stape1,OB_DEVICE_2=stape2)';
SET BACKUP COPIES 2;
BACKUP DATABASE PLUS ARCHIVELOG;
}
例2-137 リストア中の制御ファイルの自動バックアップ形式の設定
制御ファイルを格納しているディスクに障害が発生したとします。初期化パラメータ・ファイルのCONTROL_FILESパラメータを編集して、新しい場所を示すようにします。
この例では、リカバリ・カタログへのアクセス権はありません。この例では、インスタンスを起動し、DBIDを設定してから、制御ファイルの自動バックアップをリストアします。データベースをマウントした後は、データベースのリカバリを行うことができます。
CONNECT TARGET /
STARTUP FORCE NOMOUNT
SET DBID 28014364;
RUN
{
SET CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '/disk2/cf_%F.bak';
RESTORE CONTROLFILE FROM AUTOBACKUP MAXSEQ 100;
}
ALTER DATABASE MOUNT;
RECOVER DATABASE;
ALTER DATABASE OPEN RESETLOGS;
例2-138 サーバー・パラメータ・ファイルのリストア
データベースのホストでメンテナンスを実行している間にデータベースが停止されたとします。このとき、サーバー・パラメータ・ファイルが誤って削除されました。Recovery Managerクライアントを起動し、TARGETとしてデータベースに接続してから、リカバリ・カタログに接続します。次の例では、テープの自動バックアップからサーバー・パラメータ・ファイルをリストアしてから、インスタンスを再起動します。
SET DBID 3257174182; # set dbid so RMAN can identify the database
STARTUP FORCE NOMOUNT # rman starts database with a dummy server parameter file
RUN
{
ALLOCATE CHANNEL t1 DEVICE TYPE sbt;
RESTORE SPFILE FROM AUTOBACKUP;
}
STARTUP FORCE; # needed so that RMAN restarts database with restored server parameter file
SHOWコマンドを使用すると、1つ以上のデータベースについて、現行のRecovery Manager構成を設定するために使用されたCONFIGUREコマンドを表示できます。Recovery Managerのデフォルト構成には、接尾辞#defaultが付いています。
このコマンドは、Recovery Managerプロンプトでのみ実行してください。次のいずれかの条件が満たされている必要があります。
DBIDが実行されている必要があります。
| 構文の要素 | 説明 |
|---|---|
|
|
ユーザーが入力したすべてのCONFIGUREコマンドとデフォルト構成を表示します。 |
|
|
アーカイブREDOログのバックアップに対して現在構成されている多重化の程度を表示します。 |
|
|
|
|
|
|
|
|
|
|
|
|
|
チャネルのデバイス・タイプを指定します。たとえば、 |
|
|
|
構成済のバックアップ圧縮アルゴリズムを表示します。 |
|
|
|
|
|
構成済デバイスについて、制御ファイルの自動バックアップ・ファイルの形式を表示します。 |
|
|
データファイルの |
|
|
リカバリ・カタログで認識されている |
|
|
構成済のデバイス・タイプと並列度の設定を表示します。 |
|
|
|
|
|
暗号化されたバックアップ・セットに書き込む場合に暗号化で使用されるデフォルトの構成済アルゴリズムを表示します。 |
|
|
データベースの現行の暗号化設定を表示します。 |
|
|
各表領域の現行の暗号化設定を表示します。 |
|
|
除外するように指定した表領域のみを表示します。 |
|
|
|
|
|
現行のターゲット・データベースに関する |
|
|
|
|
リカバリ・カタログ内の一意の名前を持つデータベースの構成を表示します。Recovery Managerがこのデータベースに
データベースの一意の名前は、
Recovery Managerは、リカバリ・カタログに接続している必要があります。Recovery Managerは、マウント済のターゲット・データベースに接続しているか、SET 関連項目: この句のオプションについては、「forDbUniqueNameOption」を参照してください。 |
ターゲット・データベースのRecovery Managerのすべての永続構成を把握する必要があるとします。Recovery Managerクライアントを起動し、ターゲット・データベースおよびリカバリ・カタログに接続して、次のようにSHOWコマンドを実行します（例には出力例も含まれます）。
RMAN> SHOW ALL;
RMAN configuration parameters for database with db_unique_name PROD1 are:
CONFIGURE RETENTION POLICY TO REDUNDANCY 1; # default
CONFIGURE BACKUP OPTIMIZATION OFF; # default
CONFIGURE DEFAULT DEVICE TYPE TO DISK; # default
CONFIGURE CONTROLFILE AUTOBACKUP ON;
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '/disk1/oracle/dbs/%F';
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE SBT_TAPE TO '%F'; # defa ult
CONFIGURE DEVICE TYPE DISK PARALLELISM 1 BACKUP TYPE TO BACKUPSET; # default
CONFIGURE DEVICE TYPE SBT_TAPE PARALLELISM 1 BACKUP TYPE TO BACKUPSET; # default
CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE SBT_TAPE TO 1; # default
CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE SBT_TAPE TO 1; # default
CONFIGURE CHANNEL DEVICE TYPE 'SBT_TAPE'
PARMS "SBT_LIBRARY=/usr/local/oracle/backup/lib/libobk.so";
CONFIGURE MAXSETSIZE TO UNLIMITED; # default
CONFIGURE ENCRYPTION FOR DATABASE ON;
CONFIGURE ENCRYPTION ALGORITHM 'AES128'; # default
CONFIGURE ARCHIVELOG DELETION POLICY TO NONE; # default
CONFIGURE SNAPSHOT CONTROLFILE NAME TO '/disk1/oracle/dbs/cf_snap .f'
SHUTDOWNコマンドを使用すると、Recovery Managerを終了せずに、ターゲット・データベースを停止できます。このコマンドは、SQL*PlusのSHUTDOWN文と同じです。
リカバリ・カタログ・データベースの停止には、Recovery ManagerのSHUTDOWNコマンドは使用できません。リカバリ・カタログ・データベースを停止するには、SQL*Plusセッションを開始してSHUTDOWN文を発行します。
データベースをNOARCHIVELOGモードで操作している場合は、データベースを正しく停止し、バックアップの作成前にSTARTUP MOUNTを発行する必要があります。
この例では、現行のSQLトランザクションが処理されるのを待ってデータベースを停止し、その後でデータベースをマウントします。
SHUTDOWN IMMEDIATE;
STARTUP MOUNT;
例2-141 NOARCHIVELOGモードでのデータベースの停止
この例では、NOARCHIVELOGモードで実行中のデータベースをバックアップします。
STARTUP FORCE DBA;
SHUTDOWN IMMEDIATE;
STARTUP MOUNT;
# executing the preceding commands ensures that database is in proper state
# for NOARCHIVELOG backups
BACKUP DATABASE;
ALTER DATABASE OPEN;
SPOOLコマンドを使用すると、Recovery Managerによる出力の書込み先のログ・ファイルを指定できます。
SPOOLコマンドは、Recovery Managerプロンプトで実行してください。
この例では、デフォルトのデバイス・タイプの構成に関するRecovery Manager出力は標準出力に書き込み、SHOWコマンドの出力はログ・ファイルcurrent_config.logにスプーリングし、データベース全体のバックアップの出力はdb_backup.logにスプーリングします。
CONFIGURE DEFAULT DEVICE TYPE TO sbt;
SPOOL LOG TO '/tmp/current_config.log';
SHOW ALL;
SPOOL LOG OFF;
SPOOL LOG TO '/tmp/db_backup.log';
BACKUP DATABASE;
SPOOL LOG OFF;
SQLコマンドを使用すると、Recovery Manager内からSQL文またはPL/SQLストアド・プロシージャを実行できます。
なし。
| 構文の要素 | 説明 |
|---|---|
|
|
RUNコマンド内でRecovery Managerのコマンドを実行するときに使用するチャネルの名前を指定します。この名前は大/小文字が区別されます。
チャネルは、この |
|
|
SQL文の実行を指定します（例2-143を参照）。
引用符で囲んだ文字列に同じ引用スタイルを使用する場合、引用符で囲んだ文字列に一重引用符を挿入するためには、2組の一重引用符を使用する必要があります。たとえば、Recovery ManagerがSQLに渡す文字列にファイル名がある場合は、ファイル名を2組の一重引用符で囲み、
注意: SQL 'BEGIN rman.rman_purge; END;'; |
この例では、表領域をバックアップしてから、アーカイブされていないオンラインREDOログをすべてアーカイブします。
BACKUP TABLESPACE users;
SQL "ALTER SYSTEM ARCHIVE LOG CURRENT";
例2-144 引用符付き文字列内のファイル名の指定
この例では、二重引用符付き文字列のコンテキスト内で、2組の一重引用符を使用してファイル名を指定します。
SQL "ALTER TABLESPACE users ADD DATAFILE ''/disk1/oradata/users02.dbf''
SIZE 100K AUTOEXTEND ON NEXT 10K MAXSIZE 100K";
STARTUPコマンドを使用すると、Recovery Manager環境内からターゲット・データベースを起動できます。このコマンドは、SQL*PlusのSTARTUPコマンドと同じです。
また、Recovery ManagerのSTARTUPコマンドでは、サーバー・パラメータ・ファイルや初期化パラメータ・ファイルがない場合にも、NOMOUNTモードでインスタンスを起動できます。この機能は、消失したサーバー・パラメータ・ファイルのリストアを必要とする場合に役立ちます。
Recovery Managerがターゲット・データベースに接続している必要があります。このコマンドは、ターゲット・データベースの起動のみに使用できます。
Recovery ManagerのSTARTUPコマンドでは、サーバー・パラメータ・ファイルや初期化パラメータ・ファイルがない場合にも、NOMOUNTモードでインスタンスを起動できます。この機能は、消失したサーバー・パラメータ・ファイルのリストアを必要とする場合に役立ちます（例2-146を参照）。
| 構文の要素 | 説明 |
|---|---|
|
|
|
|
|
アクセスを |
|
|
データベースがオープン状態の場合、 |
|
|
インスタンスを起動してからデータベースをマウントしますが、オープンはしません。 |
|
|
データベースをマウントせずにインスタンスを起動します。パラメータ・ファイルが存在しない場合、Recovery Managerは一時パラメータ・ファイルでインスタンスを起動します。RESTORE |
|
|
ターゲット・データベースで使用するテキスト・ベースの初期化パラメータ・ファイルのファイル名を指定します。 |
この例では、SHUTDOWN ABORTを実行してから、非デフォルトの初期化パラメータ・ファイルの位置を指定し、制限付きアクセスでデータベースをマウントします。
CONNECT TARGET /
STARTUP FORCE MOUNT DBA PFILE=/tmp/initPROD.ora;
例2-146 パラメータ・ファイルを使用しないインスタンスの起動
サーバー・パラメータ・ファイルが誤ってファイル・システムから削除されたとします。次の例では、パラメータ・ファイルを使用せずにインスタンスを起動して、RESTORE SPFILE FROM AUTOBACKUPを実行します。この例では、自動バックアップの場所がフラッシュ・リカバリ領域であるため、SET DBIDは必要ありません。
CONNECT TARGET /
STARTUP FORCE NOMOUNT; # RMAN starts instance with dummy parameter file
RESTORE SPFILE TO '?/dbs/spfileprod.ora'
FROM AUTOBACKUP
RECOVERY AREA '/disk2' DB_NAME='prod';
STARTUP FORCE; # restart instance with restored server parameter file
SWITCHコマンドを使用すると、次の操作のいずれかを実行できます。
NEWNAMEコマンドが発行されたデータファイルおよび一時ファイルのファイル名を更新します。
SWITCHは、SQL文ALTER DATABASE RENAME FILEを使用した場合と同じ結果になります。Recovery Managerリポジトリ内のファイルの名前は更新されますが、データベースは、オペレーティング・システム・レベルでは名前を変更しません。
Recovery Managerがターゲット・データベースに接続している必要があります。表領域、データファイルまたは一時ファイルを切り替えるときは、ファイルがオフライン状態になっている必要があります。データベース全体を切り替えるときは、データベースをオープンしないでください。
SWITCHコマンドによって、データファイルのコピーのRecovery Managerリポジトリ・レコードがリカバリ・カタログから削除され、制御ファイル・レコードの状態がDELETEDに更新されます。
Recovery Managerがリカバリ・カタログに接続されていて、バックアップからリストアされた制御ファイルをデータベースで使用している場合は、SWITCHによって、リカバリ・カタログでは認識されているが、制御ファイルでは不明なデータファイルのレコードで制御ファイルが更新されます。
SWITCH ...TO COPYはRecovery Managerプロンプトでのみ実行できます。TO COPYを指定しないSWITCHは、RUNブロック内でのみ使用できます。
（datafileSpec::=、tempfileSpec::=）
この副次句では、データベース、表領域またはデータファイルのファイル名を、指定したファイルに使用可能な最新のイメージ・コピーに切り替えます。このコマンドを実行することで、バックアップからのデータファイルのリストアを回避できます。SWITCH ...TO COPYはRecovery Managerプロンプトでのみ実行できます。
| 構文の要素 | 説明 |
|---|---|
|
|
データファイルおよび制御ファイルの名前を変更して、これらのファイルのイメージ・コピーのファイル名を使用します。Recovery Managerは、各データベース・ファイルの最新のイメージ・コピーに切り替えられます。 データベースの切替え後、Recovery Managerでは、以前のデータベースがデータファイルのコピーとして認識されます。 |
|
|
指定したデータファイルを最新のイメージ・コピーに切り替えます。 ファイル切替え後は、指定したデータファイルが制御ファイルで現行のファイルとは認識されなくなります。 |
|
|
|
|
|
指定したアクティブなデータベース・ファイルをイメージ・コピーに切り替えます。 |
この副次句では、SET NEWNAMEコマンドが発行されたデータファイルおよび一時ファイルのファイル名を更新します。この句は、 RUNブロック内でのみ実行してください。
| 構文の要素 | 説明 |
|---|---|
|
|
このジョブでSET |
|
|
名前を変更するデータファイルを指定します。ファイルの切替え後、指定したファイルは制御ファイルによって現行とは認識されません。 |
|
|
ファイルの切替えに使用する入力コピー・ファイルを指定します。つまり、名前の変更が必要なデータファイルのコピーを指定します（例2-150を参照）。 |
|
|
このジョブでSET |
|
|
名前を変更する一時ファイルを指定します。 |
|
|
一時ファイルの名前を指定した名前に変更します（例2-149を参照）。ターゲット・データベースはマウントする必要がありますが、オープンはしないでください。 |
ディスクに障害が発生し、users表領域内のすべてのデータファイルにアクセスできなくなったとします。この表領域内のすべてのデータファイルのイメージ・コピーは、フラッシュ・リカバリ領域に存在します。Recovery Managerを起動し、TARGETとしてデータベースに接続した後、SWITCHを実行して制御ファイルが新しいデータファイルを指し示すようにしてから、次のようにRECOVERを実行します。
SQL "ALTER TABLESPACE users OFFLINE IMMEDIATE";
SWITCH TABLESPACE users TO COPY;
RECOVER TABLESPACE users;
SQL "ALTER TABLESPACE users ONLINE";
例2-148 新しい場所へリストアした後のデータファイルのファイル名の切替え
ディスクに障害が発生し、データファイルを新しいディスクの場所へリストアする必要があるとします。Recovery Managerを起動し、TARGETとしてデータベースに接続した後、SET NEWNAMEコマンドを実行してデータファイル名を変更してから、RESTOREを実行して欠落しているデータファイルをリストアします。SWITCHを実行して制御ファイルが新しいデータファイルを指し示すようにしてから、RECOVERを実行します。この例では、ディスクとテープの両方のチャネルを割り当てます。
RUN
{
ALLOCATE CHANNEL dev1 DEVICE TYPE DISK;
ALLOCATE CHANNEL dev2 DEVICE TYPE sbt;
SQL "ALTER TABLESPACE users OFFLINE IMMEDIATE";
SET NEWNAME FOR DATAFILE '/disk1/oradata/prod/users01.dbf'
TO '/disk2/users01.dbf';
RESTORE TABLESPACE users;
SWITCH DATAFILE ALL;
RECOVER TABLESPACE users;
SQL "ALTER TABLESPACE users ONLINE";
}
例2-149 SET NEWNAMEとSWITCH TEMPFILE ALLを使用した一時ファイルの名前の変更
この例では、SET NEWNAMEを使用して複数の一時ファイルの新しい名前を指定し、SWITCH TEMPFILE ALLを使用して一時ファイル名を指定されたファイル名に変更します。データベースはこの手順を開始する際にクローズされた状態である必要があります。データベースがオープンされている場合は一時ファイルが新しい場所に再作成されます。
CONNECT TARGET /
STARTUP FORCE MOUNT
RUN
{
SET NEWNAME FOR TEMPFILE 1 TO '/disk2/temp01.dbf';
SET NEWNAME FOR TEMPFILE 2 TO '/disk2/temp02.dbf';
SET NEWNAME FOR TEMPFILE 3 TO '/disk2/temp03.dbf';
SWITCH TEMPFILE ALL;
RESTORE DATABASE;
RECOVER DATABASE;
ALTER DATABASE OPEN;
}
例2-150 データファイルのコピーへの切替え
次のコマンドは、tools表領域のデータファイルを、/disk2/tools.copyという名前のデータファイル・コピーに切り替えます。
RUN
{
SQL "ALTER TABLESPACE tools OFFLINE IMMEDIATE";
SWITCH DATAFILE '/disk1/oradata/prod/tools01.dbf'
TO DATAFILECOPY '/disk2/tools.copy';
RECOVER TABLESPACE tools;
SQL "ALTER TABLESPACE tools ONLINE";
}
TRANSPORT TABLESPACEコマンドを使用すると、ソース・データベースのライブ・データファイルではなく、Recovery Managerのバックアップからトランスポータブル表領域セットを作成できます。
『Oracle Database管理者ガイド』で説明されているトランスポータブル表領域セットの作成に関する制限事項は、表領域を読取り専用にする要件を除いて、バックアップから表領域をトランスポートする場合に適用されます。
SYSAUX表領域は、リカバリ・セット（トランスポートする表領域のセット）に含めないように注意してください。Recovery Managerは、SYSAUX表領域を補助セット（データファイルと、表領域のトランスポートに必要な他のファイルを含む）に組み込みます。
TRANSPORT TABLESPACEでは、エンディアン形式は変換しません。ターゲット・プラットフォームに別のエンディアン形式が含まれている場合は、TRANSPORT TABLESPACEの実行後に、CONVERTコマンドを使用して、トランスポータブル・セットのデータファイルのエンディアン形式を変換します。
表領域を削除すると、TRANSPORT TABLESPACEのSCNが表を削除したときのSCNより古い場合でも、後でTRANSPORT TABLESPACEを使用してこの表領域をトランスポータブル表領域セットに含めることはできません。表領域名を変更すると、TRANSPORT TABLESPACEを使用して、表領域名を変更した時点よりも前の時点でのトランスポータブル表領域セットは作成できません。
必要なすべての表領域（補助セットの表領域を含む）のバックアップ、およびターゲット時刻までリカバリするために必要なアーカイブREDOログ・ファイルが必要です。
リカバリ・カタログを使用せずに、必要なバックアップに関するメタデータを含む制御ファイル・レコードがデータベースで再使用された場合、バックアップをRecovery Managerで検索できないため、そのコマンドは失敗します。必要なバックアップが使用可能な場合は、CATALOGを使用してそれらをRecovery Managerリポジトリに追加できる場合があります。ただし、制御ファイル・レコードがデータベースですでに上書きされている場合は、他の必要なバックアップのレコードが失われる場合があります。
Recovery Managerではデータ・ポンプ・エクスポート/インポート・ユーティリティが使用されるため、トランスポートする表領域でXMLTypeが使用されている場合、TRANSPORT TABLESPACEは使用できません。この場合は、『Oracle Database管理者ガイド』の手順を使用する必要があります。
エクスポート・ダンプ・ファイルの名前の付いたファイルがすでに表領域のトランスポート先に格納されていると、TRANSPORT TABLESPACEはデータ・ポンプ・エクスポートの呼出し時に失敗します。以前のTRANSPORT TABLESPACEジョブを繰り返す場合は、エクスポート・ダンプ・ファイルを含む以前の出力ファイルを削除してください。
列レベルで機能する透過的データ暗号化と表領域暗号化のデータベース暗号化機能のいずれにも、ウォレットが使用されています。暗号化される表領域または暗号化された列を含む表領域には、次の制限が適用されることに注意してください。
Recovery Managerでは同じノードでのリストアおよびリカバリに使用される自動補助インスタンスがソース・インスタンスとして作成されるため、TRANSPORT TABLESPACEコマンドの操作中にパフォーマンス・オーバーヘッドが発生します。
Recovery Managerがデータベースのバックアップ計画の一部分でない場合は、必要なデータファイル・コピーおよびアーカイブ・ログがディスクで使用可能なかぎり、TRANSPORT TABLESPACEを使用できます。CATALOGコマンドを使用してデータファイル・コピーおよびアーカイブ・ログをRecovery Managerリポジトリに記録します。その後、TRANSPORT TABLESPACEを使用できます。また、TRANSPORT TABLESPACEを使用できるように、Recovery Managerを使用してデータベースをバックアップするオプションもあります。
| 構文の要素 | 説明 |
|---|---|
|
|
必要なすべての表領域（補助セットの表領域を含む）のバックアップ、および |
この副次句では、表領域のトランスポートに影響を与えるオプションのパラメータを指定します。
| 構文の要素 | 説明 |
|---|---|
|
|
SET 関連項目: 補助インスタンス・ファイルの様々なネーミング手法での相互作用の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。 |
|
|
データ・ポンプ・エクスポートの出力が作成されるデータベース・ディレクトリ・オブジェクトを指定します（例2-152を参照）。指定しない場合、Recovery Managerは 関連項目: データ・ポンプ・エクスポートおよびデータベース・ディレクトリ・オブジェクトの詳細は、『Oracle Databaseユーティリティ』を参照してください。 |
|
|
データ・ポンプ・エクスポートのダンプ・ファイルを作成する場所を指定します。指定しない場合、エクスポート・ダンプ・ファイルは、
注意: エクスポート・ダンプ・ファイルの名前の付いたファイルがすでに表領域のトランスポート先に格納されていると、 |
|
|
データ・ポンプ・エクスポートで生成されたログの場所を指定します。省略した場合、エクスポート・ログは、 |
|
|
トランスポート先データベースのトランスポートされた表領域に接続する際に使用する、Recovery Managerで生成されるサンプル入力スクリプトのファイル名を指定します。省略した場合、インポート・スクリプトは |
|
|
表領域のトランスポート操作が完了した後の、トランスポートされた表領域のデータファイルの場所を指定します。 |
|
|
リストア・ポイントを作成した時点のSCNを上限として、表領域のリストアおよびリカバリのリストア・ポイントを指定します。指定した値は含まれます。上限値が含まれるため、Recovery Managerは、リストア・ポイントに対応するSCNまで表領域をリストアまたはリカバリできるファイルのみを選択します。 |
|
過去の時刻、SCNまたはログ順序番号を指定します（例2-151を参照）。指定した場合、Recovery Managerは、エクスポート前に補助インスタンスで表領域をその過去の時点における表領域の内容にリストアおよびリカバリします。 表領域名を変更すると、このコマンドを使用して、表領域名を変更した時点よりも前の時点でのトランスポータブル表領域セットを作成することはできません。Recovery Managerには、前の表領域名に関する情報がありません。
|
この例では、トランスポータブル・セットの表領域はexampleおよびtoolsで、トランスポータブル・セットのファイルは/disk1/transport_destに格納されます。また、トランスポータブル表領域は、15分前の時刻までリカバリされます。
TRANSPORT TABLESPACE example, tools
TABLESPACE DESTINATION '/disk1/transportdest'
AUXILIARY DESTINATION '/disk1/auxdest'
UNTIL TIME 'SYSDATE-15/1440';
次に出力例の一部を示します。
Creating automatic instance, with SID='egnr' initialization parameters used for automatic instance: db_name=PROD compatible=11.0.0 db_block_size=8192 . . . starting up automatic instance PROD . . . executing Memory Script executing command: SET until clause Starting restore at 07-JUN-07 allocated channel: ORA_AUX_DISK_1 channel ORA_AUX_DISK_1: SID=44 device type=DISK channel ORA_AUX_DISK_1: starting datafile backup set restore channel ORA_AUX_DISK_1: restoring control file . . . output file name=/disk1/auxdest/cntrl_tspitr_PROD_egnr.f Finished restore at 07-JUN-07 sql statement: alter database mount clone database sql statement: alter system archive log current sql statement: begin dbms_backup_restore.AutoBackupFlag(FALSE); end; starting full resync of recovery catalog full resync complete . . . executing Memory Script . . . Starting restore at 07-JUN-07 using channel ORA_AUX_DISK_1 channel ORA_AUX_DISK_1: starting datafile backup set restore channel ORA_AUX_DISK_1: specifying datafile(s) to restore from backup set channel ORA_AUX_DISK_1: restoring datafile 00001 to /disk1/auxdest/TSPITR_PROD_EGNR/datafile/o1_mf_system_%u_.dbf datafile 1 switched to datafile copy . . . starting media recovery . . . Finished recover at 07-JUN-07 database opened . . . executing Memory Script . . . sql statement: alter tablespace EXAMPLE read only Removing automatic instance shutting down automatic instance Oracle instance shut down Automatic instance removed auxiliary instance file /disk1/auxdest/cntrl_tspitr_PROD_egnr.f deleted . . .例2-152 カスタマイズされたファイルの場所を指定したTRANSPORT TABLESPACEの使用
この例では、データ・ポンプ関連ファイル（ダンプ・ファイルなど）の場所を制御するオプションの引数の使用方法を示します。DATAPUMP DIRECTORYは、ターゲット・データベースに存在するオブジェクトを参照する必要があります。SQL文のCREATE DIRECTORYを使用すると、ディレクトリ・オブジェクトを作成できます。
TRANSPORT TABLESPACE example
TABLESPACE DESTINATION '/disk1/transportdest'
AUXILIARY DESTINATION '/disk1/auxdest'
DATAPUMP DIRECTORY mypumpdir
DUMP FILE 'mydumpfile.dmp'
IMPORT SCRIPT 'myimportscript.sql'
EXPORT LOG 'myexportlog.log';
UNREGISTERコマンドを使用すると、登録されている1つ以上のデータベースのRecovery Managerのメタデータをリカバリ・カタログから削除できます。
このコマンドは、Recovery Managerプロンプトでのみ実行してください。Recovery Managerは、リカバリ・カタログに接続している必要があります。登録解除するデータベースは、現在リカバリ・カタログに登録されている必要があります。
| 構文の要素 | 説明 |
|---|---|
|
|
登録解除するプライマリ・データベースを指定します。Recovery Managerにより、プライマリ・データベース、およびこれに対応付けられているスタンバイ・データベースが登録解除されます（例2-153を参照）。
|
|
|
このデータベース名は、リカバリ・カタログで一意である必要があります。データベース名が一意であるため、Recovery Managerはターゲット・データベースに接続したり、SET |
|
|
通常は、スタンバイ・データベースの登録解除を行うためにこの句を使用しますが、指定するデータベースはプライマリ・データベースでもスタンバイ・データベースでもかまいません（例2-155を参照）。
この句は、Recovery Managerがマウントまたはオープン状態のターゲット・データベースに接続されている場合、またはSET
データベースのバックアップには、リカバリ・カタログ内のバックアップ・ファイルの名前に対応付けられた |
|
|
注意: 物理バックアップは、 |
|
|
確認のプロンプトを表示せずに、データベースを登録解除します。 |
プライマリ・データベースprodには、対応付けられているスタンバイ・データベースdgprod3およびdgprod4があるとします。この例では、データベース名がリカバリ・カタログ内で一意のターゲット・データベースprodにRecovery Managerを接続し、そのデータベースを登録解除します。Recovery Managerにより、prod、dgprod3およびdgprod4に関するすべてのメタデータがカタログから削除されます。例には出力例も含まれます。
RMAN> CONNECT TARGET /
connected to target database: PROD (DBID=1627709917)
RMAN> CONNECT CATALOG rman@catdb
recovery catalog database Password: password
connected to recovery catalog database
RMAN> UNREGISTER DATABASE NOPROMPT;
database name is "PROD" and DBID is 1627709917
database unregistered from the recovery catalog
RMAN> LIST DB_UNIQUE_NAME ALL;
RMAN>
例2-154 カタログ内で一意でないデータベースの登録解除
リカバリ・カタログに登録されている2つのデータベースの名前がprodであるとします。目標は、DBIDが28014364のprodデータベースを登録解除することです。リカバリ・カタログでprodという名前を持つ複数のデータベースが登録されているため、また、Recovery Managerが28014364データベースにTARGETとして接続されていない（このデータベースがファイル・システムからすでに削除されている）ため、UNREGISTER DATABASEの前にSET DBIDを実行します。この例には、出力例も含まれます。
RMAN> CONNECT CATALOG rman@catdb
recovery catalog database Password: password
connected to recovery catalog database
RMAN> SET DBID 28014364;
executing command: SET DBID
database name is "PROD" and DBID is 28014364
RMAN> UNREGISTER DATABASE;
Do you really want to unregister the database (enter YES or NO)? YES
database unregistered from the recovery catalog
例2-155 スタンバイ・データベースの登録解除
プライマリ・データベースprodには、対応付けられているスタンバイ・データベースdgprod3およびdgprod4があるとします。dgprod4を登録解除しますが、このデータベースで作成されたバックアップのメタデータは削除しません。これらの場アックアップは、その環境の他のデータベースで引き続き使用できるためです。この例では、SET DBIDを使用してスタンバイ・データベースのDBIDを指定してから、登録解除します（例には出力例も含まれます）。
RMAN> CONNECT CATALOG rman@catdb
recovery catalog database Password: password
connected to recovery catalog database
RMAN> SET DBID 1627367554;
executing command: SET DBID
database name is "PROD" and DBID is 1627367554
RMAN> UNREGISTER DB_UNIQUE_NAME dgprod4;
database db_unique_name is "dgprod4", db_name is "PROD" and DBID is 1627367554
Want to unregister the database with target db_unique_name (enter YES or NO)? YES
database with db_unique_name dgprod4 unregistered from the recovery catalog
UPGRADE CATALOGコマンドを使用すると、リカバリ・カタログ・スキーマを、旧バージョンから、Recovery Managerクライアントで必要なバージョンにアップグレードできます。
Recovery Managerがリカバリ・カタログ所有者としてリカバリ・カタログ・データベースに接続していて、リカバリ・カタログ・データベースがオープン状態である必要があります。仮想プライベート・カタログへの接続中は、UPGRADE CATALOGコマンドを使用できません（CREATE CATALOGコマンドを参照）。アップグレードできるのは基本カタログのみです。
リカバリ・カタログが、Recovery Manager実行可能ファイルに必要なバージョンより後のバージョンになっていないことが必要です。後のバージョンの場合は、エラーが発行されます。Recovery Managerは、アップグレード中に生成したエラー・メッセージをメッセージ・ログに表示します。
Oracle Database 10g リリース1のリカバリ・カタログ・スキーマには、CREATE TYPE権限が必要です。10g リリース1より前のリリースでリカバリ・カタログ所有者を作成し、このユーザーにRECOVERY_CATALOG_OWNERロールを付与しているとします。このロールにCREATE TYPE権限が含まれていない場合は、アップグレードを実行する前に、このユーザーに明示的にCREATE TYPEを付与する必要があります。
アップグレードの確認のため、UPGRADE CATALOGコマンドを続けて2回入力する必要があります。
リカバリ・カタログがすでに現行の状態になっていれば、Recovery Managerはコマンドの実行を認めます。その結果、必要に応じてパッケージの再作成ができます。
基本リカバリ・カタログへのアップグレードで既存の仮想プライベート・カタログへの変更が必要な場合は、Recovery Managerが次にその仮想プライベート・カタログに接続したときに、これらの変更が自動的に行われます。
UPGRADE CATALOGコマンドでは、アップグレード用のスクリプトは実行されません。かわりに、Recovery Managerは各種のSQL DDL文をリカバリ・カタログに送信し、新規の表、ビュー、列などでリカバリ・カタログ・スキーマを更新します。
なし。
この例では、Recovery Managerをリカバリ・カタログ・データベースcatdbに接続し、それを新しいバージョンにアップグレードします。
RMAN> CONNECT CATALOG rco@catdb
recovery catalog database Password: password
connected to recovery catalog database
PL/SQL package rman.DBMS_RCVCAT version 10.01.00 in RCVCAT database is too old
RMAN> UPGRADE CATALOG;
recovery catalog owner is RCO
enter UPGRADE CATALOG command again to confirm catalog upgrade
RMAN> UPGRADE CATALOG;
recovery catalog upgraded to version 11.01.00
DBMS_RCVMAN package upgraded to version 11.01.00
DBMS_RCVCAT package upgraded to version 11.01.00
VALIDATEコマンドを使用すると、破損ブロックおよび欠落ファイルをチェックしたり、バックアップ・セットがリストア可能かどうかを判断することができます。
VALIDATEでの検証中に問題が検出されると、Recovery Managerによってその問題が表示され、障害の評価が開始されます。障害が検出されたら、Recovery Managerによってその障害のログが自動診断リポジトリに書き込まれます。LIST FAILUREを使用すると、障害を表示できます。
ターゲット・データベースはマウントまたはオープン状態である必要があります。
VALIDATEコマンドのオプションは、BACKUP VALIDATEコマンドのオプションと同じ意味です。ただし、BACKUP VALIDATEとは異なり、VALIDATEでは個々のバックアップ・セットとデータ・ブロックをチェックできます。
VALIDATEコマンドでは、一度も使用されていないブロックはスキップされます。Recovery Managerではまた、COMPATIBLEパラメータが10.2以上に設定されている場合は、ローカル管理の表領域の（一度も使用されていないブロックではなく）現在使用されていないブロックがスキップされます。
物理的な破損が発生した場合、データベースでブロックが認識されません。論理的な破損が発生した場合は、ブロックの内容に論理的な一貫性がなくなります。デフォルトでは、VALIDATEコマンドを使用すると、物理的な破損のみがチェックされます。CHECK LOGICALを指定すると、論理的な破損もチェックできます。Recovery Managerにより、結果がV$DATABASE_BLOCK_CORRUPTIONビューに移入されます。
ブロック破損はブロック間破損とブロック内破損に分類できます。ブロック内破損では、破損はブロック自体の中で発生し、物理的な破損または論理的な破損のいずれかです。ブロック間破損では、破損はブロック間で発生し、論理的な破損のみです。VALIDATEコマンドでは、ブロック内破損のみがチェックされます。
（validateObject::=、validateOperand::=）
（archivelogRecordSpecifier::=、copyOfSpec::=、blockObject::=、datafileCopySpec::=、datafileSpec::=）
（deviceSpecifier::=、sizeSpec::=、skipSpec::=）
この副次句では、検証するバックアップ・セットを指定します。構文は、「validate::=」を参照してください。
| 構文の要素 | 説明 |
|---|---|
|
関連項目: |
|
|
関連項目: |
|
|
|
現行の制御ファイルのスナップショットを作成し、検証を行います。 |
|
|
アーカイブREDOログも検証の対象にします。Recovery Managerによって次の手順が実行されます。 |
この副次句では、検証するデータベース・ファイルを指定します。構文は、「validateObject::=」を参照してください。
| 構文の要素 | 説明 |
|---|---|
|
アーカイブREDOログの範囲を検証します。 |
|
|
|
バックアップ・セットの主キーを取得するには、LIST文を実行します。あるいは、リカバリ・カタログを使用している場合には、
バックアップ・セットのうち1つ以上のバックアップ・ピースが欠落または破損している疑いがあるときは、
自動チャネルを構成していない場合は、
注意: バックアップ・セットのコピーが複数存在する場合は、Recovery Managerにより最新のコピーのみが検証されます。 |
|
|
制御ファイルのコピーを検証します。次のいずれかの方法で制御ファイルのコピーを指定できます。
制御ファイルのコピーを作成するには、BACKUP |
|
データファイルおよび制御ファイルのイメージ・コピーを検証します。 関連項目: 詳細は、「copyOfSpec」を参照してください。 |
|
|
関連項目: 「blockObject」を参照してください。 |
|
|
|
現行の制御ファイルを検証します。 |
|
|
Recovery Managerによって、すべてのデータファイルおよび制御ファイルを検証します。データベースが現在サーバー・パラメータ・ファイルを使用している場合は、Recovery Managerがサーバー・パラメータ・ファイルを検証します。 注意: オンラインREDOログ・ファイルおよび一時ファイルは検証されません。 |
|
データファイル・コピーの検証時に、Recovery Managerはブロックの破損をチェックしますが、破損が発見されても検証を終了しません。 関連項目: 詳細は、「datafileCopySpec」を参照してください。 |
|
|
|
検証を必要とするブロックを含む1つ以上のデータファイルのリストを指定します。 注意: 検証する場合は、対象となるデータファイルをオフライン化する必要はありません。 関連項目: 「 datafileSpec」を参照してください。 |
|
|
現行および前回のすべてのフラッシュ・リカバリ領域の指定先に作成されたリカバリ・ファイルを検証します。リカバリ・ファイルには、全体増分バックアップ・セット、制御ファイルの自動バックアップ、アーカイブREDOログおよびデータファイルのコピーが含まれます。フラッシュバック・ログ、現行の制御ファイルおよびオンラインREDOログは検証されません。 |
|
|
|
|
|
ディスク上のすべてのリカバリ・ファイルに対して、フラッシュ・リカバリ領域に格納されているか、ディスクの別の場所に格納されているかに関係なく検証を行います。リカバリ・ファイルには、全体および増分のバックアップ・セット、制御ファイルの自動バックアップ、アーカイブREDOログおよびデータファイルのコピーが含まれます。フラッシュバック・ログは検証されません。 |
|
|
データベースで現在使用されているサーバー・パラメータ・ファイルを検証します。Recovery Managerでは、サーバー・パラメータ・ファイルの他のコピーは検証できません。また、インスタンスの起動に初期化パラメータ・ファイルが使用された場合、サーバー・パラメータ・ファイルは検証できません。 |
|
|
指定した表領域を検証します。Recovery Managerは、その内部で表領域名をデータファイルのリストに変換してから、表領域を現在構成しているデータファイルをすべて検証します。Recovery Managerは、指定した表領域の現在メンバーになっているデータファイルをすべて検証します。 |
この副次句では、検証する修飾子を指定します。構文は、「validateOperand::=」を参照してください。
| 構文の要素 | 説明 |
|---|---|
|
|
ファイルで物理的な破損チェックを通過したデータ・ブロックと索引ブロックについて、論理的な破損がないかどうかをテストします。たとえば、行ピースまたは索引エントリの破損がないかどうかを調べます。Recovery Managerは論理的な破損を見つけると、アラート・ログとサーバー・セッション・トレース・ファイルにそのブロックのログを書き込みます。Recovery Managerコマンドは完了し、
注意: |
|
|
指定したデバイス・タイプ専用の自動チャネルを割り当てます。このオプションが有効になるのは、構成済の自動チャネルがあり、チャネルを手動で割り当てていない場合のみです。たとえば、自動ディスクおよびテープ・チャネルを構成して 関連項目: 「deviceSpecifier」を参照してください。 |
|
|
|
|
|
各ファイルを指定のセクション・サイズに分割して、検証をパラレル化します。 このパラメータを指定するのは、複数のチャネルの構成または割当てが行われていて、これらのチャネルで検証のパラレル化を行い、複数のチャネルで1つのデータファイルを検証できるようにする場合のみです。このパラメータは、データファイルの検証時のみ適用されます。 ファイルのサイズより大きなセクション・サイズを指定すると、Recovery Managerはファイルの検証をパラレル化しません。256より多くのセクションが作成される小さなセクション・サイズを指定すると、Recovery Managerは、セクション・サイズをちょうど256セクションが作成されるような値に増やします。
関連項目: マルチセクション・バックアップの作成方法は、「BACKUP |
|
指定したファイルを検証対象から除外します。 |
この副次句では、検証対象から除外するファイルを指定します。
| 列 | 指定対象 |
|---|---|
|
|
ファイルのタイプ。 |
|
|
破損がない場合は |
|
|
破損チェックに失敗するブロック数。これらのブロックで新たに破損が発生しています。 |
|
|
ファイル内の合計ブロック数。 |
| 列 | 指定対象 |
|---|---|
|
|
REDOのスレッド番号。 |
|
|
ログ順序番号。 |
|
|
破損がない場合は |
|
|
破損チェックに失敗するブロック数。これらのブロックで新たに破損が発生しています。 |
|
|
ファイル内の合計ブロック数。 |
|
|
アーカイブREDOログ・ファイルの名前。 |
この例では、使用可能なバックアップ・セットをすべてリストしてから、これらを検証します。出力例に示すとおり、Recovery Managerは、バックアップのリストアが可能であることを確認します。
RMAN> LIST BACKUP SUMMARY; List of Backups =============== Key TY LV S Device Type Completion Time #Pieces #Copies Compressed Tag ------- -- -- - ----------- --------------- ------- ------- ---------- --- 3871 B F A DISK 08-MAR-07 1 1 NO TAG20070308T092426 3890 B F A DISK 08-MAR-07 1 1 NO TAG20070308T092534
RMAN> VALIDATE BACKUPSET 3871, 3890;
Starting validate at 08-MAR-07 using channel ORA_DISK_1 channel ORA_DISK_1: starting validation of datafile backup set channel ORA_DISK_1: reading from backup piece /disk2/PROD/backupset/2007_03_08/o1_mf_nnndf_TAG20070308T092 426_2z0kpc72_.bkp channel ORA_DISK_1: piece handle=/disk2/PROD/backupset/2007_03_08/o1_mf_nnndf_TAG20070308T092426_2z0kpc72_.bkp ta g=TAG20070308T092426 channel ORA_DISK_1: restored backup piece 1 channel ORA_DISK_1: validation complete, elapsed time: 00:00:18 channel ORA_DISK_1: starting validation of datafile backup set channel ORA_DISK_1: reading from backup piece /disk2/PROD/autobackup/2007_03_08/o1_mf_s_616670734_2z0krhjv_.bkp channel ORA_DISK_1: piece handle=/disk2/PROD/autobackup/2007_03_08/o1_mf_s_616670734_2z0krhjv_.bkp tag=TAG20070308T092534 channel ORA_DISK_1: restored backup piece 1 channel ORA_DISK_1: validation complete, elapsed time: 00:00:00 Finished validate at 08-MAR-07例2-158 データベースの検証
この例では、データベースを検証します。出力例も示します。検証では、データファイル1内に破損ブロックが1個検出されました。VALIDATE出力では、指定されたトレース・ファイルで破損の詳細を参照するように示されています。
RMAN> VALIDATE DATABASE; Starting validate at 26-FEB-07 using channel ORA_DISK_1 channel ORA_DISK_1: starting validation of datafile channel ORA_DISK_1: specifying datafile(s) for validation input datafile file number=00001 name=/disk1/oradata/prod/system01.dbf input datafile file number=00002 name=/disk1/oradata/prod/sysaux01.dbf input datafile file number=00003 name=/disk1/oradata/prod/undotbs01.dbf input datafile file number=00004 name=/disk1/oradata/prod/cwmlite01.dbf input datafile file number=00005 name=/disk1/oradata/prod/drsys01.dbf input datafile file number=00006 name=/disk1/oradata/prod/example01.dbf input datafile file number=00007 name=/disk1/oradata/prod/indx01.dbf input datafile file number=00008 name=/disk1/oradata/prod/tools01.dbf input datafile file number=00009 name=/disk1/oradata/prod/users01.dbf channel ORA_DISK_1: validation complete, elapsed time: 00:01:25 List of Datafiles ================= File Status Marked Corrupt Empty Blocks Blocks Examined High SCN ---- ------ -------------- ------------ --------------- ---------- 1 FAILED 0 4140 57600 498288 File Name: /disk1/oradata/prod/system01.dbf Block Type Blocks Failing Blocks Processed ---------- -------------- ---------------- Data 1 41508 Index 0 7653 Other 0 4299 File Status Marked Corrupt Empty Blocks Blocks Examined High SCN ---- ------ -------------- ------------ --------------- ---------- 2 OK 0 8918 20040 498237 File Name: /disk1/oradata/prod/sysaux01.dbf Block Type Blocks Failing Blocks Processed ---------- -------------- ---------------- Data 0 2473 Index 0 2178 Other 0 6471 File Status Marked Corrupt Empty Blocks Blocks Examined High SCN ---- ------ -------------- ------------ --------------- ---------- 3 OK 0 36 2560 498293 File Name: /disk1/oradata/prod/undotbs01.dbf Block Type Blocks Failing Blocks Processed ---------- -------------- ---------------- Data 0 0 Index 0 0 Other 0 2524 File Status Marked Corrupt Empty Blocks Blocks Examined High SCN ---- ------ -------------- ------------ --------------- ---------- 4 OK 0 1 1280 393585 File Name: /disk1/oradata/prod/cwmlite01.dbf Block Type Blocks Failing Blocks Processed ---------- -------------- ---------------- Data 0 0 Index 0 0 Other 0 1279 File Status Marked Corrupt Empty Blocks Blocks Examined High SCN ---- ------ -------------- ------------ --------------- ---------- 5 OK 0 1 1280 393644 File Name: /disk1/oradata/prod/drsys01.dbf Block Type Blocks Failing Blocks Processed ---------- -------------- ---------------- Data 0 0 Index 0 0 Other 0 1279 File Status Marked Corrupt Empty Blocks Blocks Examined High SCN ---- ------ -------------- ------------ --------------- ---------- 6 OK 0 1 1280 393690 File Name: /disk1/oradata/prod/example01.dbf Block Type Blocks Failing Blocks Processed ---------- -------------- ---------------- Data 0 0 Index 0 0 Other 0 1279 File Status Marked Corrupt Empty Blocks Blocks Examined High SCN ---- ------ -------------- ------------ --------------- ---------- 7 OK 0 1 1280 393722 File Name: /disk1/oradata/prod/indx01.dbf Block Type Blocks Failing Blocks Processed ---------- -------------- ---------------- Data 0 0 Index 0 0 Other 0 1279 File Status Marked Corrupt Empty Blocks Blocks Examined High SCN ---- ------ -------------- ------------ --------------- ---------- 8 OK 0 1 1280 393754 File Name: /disk1/oradata/prod/tools01.dbf Block Type Blocks Failing Blocks Processed ---------- -------------- ---------------- Data 0 0 Index 0 0 Other 0 1279 File Status Marked Corrupt Empty Blocks Blocks Examined High SCN ---- ------ -------------- ------------ --------------- ---------- 9 OK 0 1272 1280 393785 File Name: /disk1/oradata/prod/users01.dbf Block Type Blocks Failing Blocks Processed ---------- -------------- ---------------- Data 0 0 Index 0 0 Other 0 8 validate found one or more corrupt blocks See trace file /disk2/oracle/log/diag/rdbms/prod/prod/trace/prod_ora_10609.trc for details channel ORA_DISK_1: starting validation of datafile channel ORA_DISK_1: specifying datafile(s) for validation including current control file for validation including current SPFILE in backup set channel ORA_DISK_1: validation complete, elapsed time: 00:00:01 List of Control File and SPFILE =============================== File Type Status Blocks Failing Blocks Examined ------------ ------ -------------- --------------- SPFILE OK 0 2 Control File OK 0 506 Finished validate at 26-FEB-07
|
 Copyright © 2007 Oracle Corporation. All Rights Reserved. |
|