10gリリース2（10.2）
B19193-02
 目次 |
 索引 |
| Oracle Database バックアップおよびリカバリ基礎 10gリリース2（10.2） B19193-02 |
|
この章では、Recovery Managerリポジトリの管理方法およびフラッシュ・リカバリ領域に関連する管理作業について説明します。
この章では、次の項目について説明します。
正式なRecovery Managerリポジトリは、常にデータベースの制御ファイルに格納されます。Recovery Managerリポジトリのデータは、制御ファイルに格納される情報の補助として、またより長期間のバックアップ履歴を提供するために、1つ以上のリカバリ・カタログ・データベースに格納することもできます。
Recovery Managerはリカバリ・カタログを使用しなくても動作するように設計されていますが、リカバリ・カタログを使用しない場合は、いくつかの追加の管理作業を実行する必要があります。
リカバリ・カタログを使用しない場合は、制御ファイルがRecovery Managerリポジトリに対する唯一のストレージとなるため、制御ファイルを保護することは非常に重要です。多重化機能またはオペレーティング・システムのミラー化機能を使用して代替の制御ファイルを保存し、制御ファイルを頻繁にバックアップします。
制御ファイルが確実に保護されるように、CONTROLFILE AUTOBACKUPをONに設定します。
制御ファイルの自動バックアップを使用できる場合、Recovery ManagerはSPFILEとバックアップ制御ファイルをリストアし、データベースをマウントできます。制御ファイルをマウントした後、残りのデータベースをリストアできます。
自動バックアップから制御ファイルをリストアした場合、CONFIGUREコマンドで行った永続的な設定は、制御ファイルの自動バックアップ時の値に戻ります。制御ファイルをリストアした後で、SHOW ALLコマンドを使用して設定を再確認する必要があります。
|
参照:
|
リカバリ・カタログを使用しない場合、制御ファイルは、Recovery Managerバックアップの唯一の情報源となります。バックアップを行うとき、Oracleはこれらのバックアップを制御ファイルに記録します。Recovery Managerリポジトリのデータを保持する際に制御ファイルが無制限に大きくならないように、指定したしきい値よりも古いレコードは再利用可能になります。
CONTROL_FILE_RECORD_KEEP_TIME初期化パラメータは、レコードが上書き可能になるまでの最小日数を決定します。
CONTROL_FILE_RECORD_KEEP_TIME = integer
たとえば、パラメータ値が14の場合、14日以上経過したレコードは再利用の候補となります。上書きされたレコードの情報は失われます。再利用可能な最も古いレコードが、最初に使用されます。
新しいRecovery Managerリポジトリ・レコードを制御ファイルに追加する必要があるにもかかわらず、しきい値よりも古いレコードが存在しない場合、Oracleは制御ファイルのサイズを拡大します。根本的なオペレーティング・システムの問題によって（ディスクの領域不足など）制御ファイルを拡大できない場合、Oracleは制御ファイル内の最も古いレコードを上書きし、この処理をアラート・ログに記録します。
CONTROL_FILE_RECORD_KEEP_TIMEのデフォルト値は7日間です。リカバリ・カタログを使用しない場合は、CONTROL_FILE_RECORD_KEEP_TIME値を、保持する必要のある最も古いファイルよりも少し長く設定します。たとえば、データベース全体を１週間に1回バックアップする場合は、すべてのバックアップを7日間以上保持する必要があります。CONTROL_FILE_RECORD_KEEP_TIMEの値を、10や14などに設定します。
次の場合について考えてみます。
CONTROL_FILE_RECORD_KEEP_TIMEの設定は14です。
データ・ファイルのバックアップを作成します。制御ファイルはオペレーティング・システムの制限を超えるファイル・サイズには拡大できないため、制御ファイル内のレコードの上書きが開始されます。最も古いレコードから上書きされます。alert.logに、上書きされる各レコードのエントリが次のように記録されます。
kccwnc: following control file record written over: RECID #72 Recno 72 Record timestamp 07/28/00 22:15:21 Thread=1 Seq#=3460 Backup set key: stamp=372031415, count=17 Low scn: 0x0000.3af33f36 07/27/00 21:00:08 Next scn: 0x0000.3af3871b 07/27/00 23:23:54 Resetlogs scn and time scn: 0x0000.00000001 08/05/99 10:46:44 Block count=102400 Blocksize=512
このような状況を回避するための最も確実な方法は、リカバリ・カタログを使用することです。リカバリ・カタログを使用できない場合は、次の方法を使用して、制御ファイル・レコードの上書きに関する問題を回避できます。
alert.logを監視して、Oracleが制御ファイル・レコードを上書きしていないことを確認します。フラッシュ・リカバリ領域で作成されたファイルに関する情報を含む制御ファイル・レコードを再利用する際（レコードがCONTROL_FILE_RECORD_KEEP_TIMEより古いため）、ファイルが削除対象の場合は、データベースでフラッシュ・リカバリ領域からファイルの削除が試行されます。そうでない場合、このファイルのレコードを含む制御ファイル・セクションのサイズがデータベースによって拡張され、アラート・ログに次のようなメッセージで拡張したことが記録されます。
kccwnc: trying to expand control file section nnnn for Oracle Managed Files
nnnnは制御ファイル・レコード・タイプの番号です。
制御ファイルがホストのオペレーティング・システムでサポートされている最大サイズである場合、制御ファイルは拡張することができません。このような場合、この警告がアラート・ログに表示されます。
WARNING: Oracle Managed File filename is unknown to control file. This is the result of limitation in control file size that could not keep all recovery area files.
これは、制御ファイルで、構成済の保存方針を満たすために必要なすべてのフラッシュ・リカバリ領域ファイルのレコードを保持できないことを意味します。
次の方法で、この問題を解決または軽減できます。
DB_BLOCK_SIZEを変更した後、制御ファイルを再作成する必要があります。
BACKUP RECOVERY AREAコマンドを使用すると、フラッシュ・リカバリ領域内のファイルをメディア・マネージャに明示的にバックアップできます。
リカバリ・カタログまたは制御ファイルのバックアップに関するデータがディスクまたはメディア管理カタログの該当するデータと同期されていることを確認するには、クロスチェックを実行します。CROSSCHECKコマンドは、リカバリ・カタログまたは制御ファイルに記録されているファイルでのみ動作します。
この項では次の項目を取り上げます。
クロスチェックは、リポジトリ・レコードが物理的な状態と一致しないバックアップに関する、Recovery Managerリポジトリの期限切れの情報を更新します。たとえば、ユーザーがオペレーティング・システムのコマンドを使用してディスク上からアーカイブ・ログを削除すると、リポジトリは、実際には削除されている場合でもログがディスク上に存在することを示します。
バックアップがディスク上に存在する場合、CROSSCHECKコマンドはファイルのヘッダーが有効であるかどうかを確認します。バックアップがテープ上に存在する場合、コマンドは単にバックアップが存在することを確認します。バックアップの状態の可能な値は、AVAILABLE、UNAVAILABLEおよびEXPIREDです。
Recovery ManagerのLISTコマンドを使用するか、V$BACKUP_FILESやリカバリ・カタログの様々なビュー（RC_DATAFILE_COPY、RC_ARCHIVED_LOGなど）を問い合せると、バックアップの状態を表示できます。クロスチェックを実行するとRecovery Managerリポジトリが更新されるため、これらのすべての方法では正確な情報が提供されます。Recovery Managerリポジトリ内の各バックアップは、バックアップとして使用できなくなると、Recovery ManagerによってEXPIREDとしてマーク付けされます。EXPIREDのマークが付いていたバックアップが使用可能になった場合、Recovery ManagerによってAVAILABLEのマークが付けられます。
|
参照:
|
ターゲット・データベースとリカバリ・カタログ（使用している場合）に接続してから、必要に応じてCROSSCHECKコマンドを実行し、Recovery Managerが認識するバックアップの状態と可用性を検査します。
テープまたはその他のメディア・マネージャ用にチャネルを構成している場合は、CROSSCHECK BACKUPを使用して、すべてのメディアに格納されているすべてのバックアップをクロスチェックできます。次に例を示します。
CROSSCHECK BACKUP;
テープ・バックアップ用にチャネルを構成していない場合は、CROSSCHECKを実行する前に、RUNブロックにメンテナンス・チャネルを割り当てることができます。次に例を示します。
RUN { ALLOCATE CHANNEL FOR MAINTENANCE DEVICE TYPE sbt; CROSSCHECK BACKUP; }
次に、ディスクのイメージ・コピーのみをクロスチェックする方法の例を示します。
CROSSCHECK COPY; # crosschecks only disk copies of # database files
次に、バックアップ・セットのみをクロスチェックする方法の例を示します。
CROSSCHECK BACKUPSET; # crosschecks backupsets on disk and SBT
LISTコマンドを使用してバックアップをレポートしてから、CROSSCHECKコマンドを使用してLIST出力に示された特定のバックアップが存在することを確認できます。DELETE EXPIREDコマンドは、クロスチェックの失敗の原因となるバックアップのリポジトリ・レコードを削除します。
指定したバックアップをクロスチェックする方法
LISTコマンドを発行して、確認する必要のあるバックアップを特定します。次に例を示します。
LIST BACKUP; # lists all backup sets, proxy copies, and image copies
CROSSCHECK BACKUP; # checks backup sets, proxy copies, and image copies CROSSCHECK COPY OF DATABASE; CROSSCHECK BACKUPSET 1338, 1339, 1340; CROSSCHECK BACKUPPIECE TAG = 'nightly_backup'; CROSSCHECK CONTROLFILECOPY '/tmp/control01.ctl'; CROSSCHECK DATAFILECOPY 113, 114, 115; CROSSCHECK PROXY 789;
CROSSCHECKコマンドのオプションを使用すると、特定のデータベース、表領域、データ・ファイル、制御フィルまたはアーカイブREDOログのバックアップのみを確認できます。次に例を示します。
CROSSCHECK BACKUP OF DATAFILE "?/oradata/trgt/system01.dbf" COMPLETED AFTER 'SYSDATE-14'; CROSSCHECK BACKUP OF ARCHIVELOG ALL SPFILE;
次のコマンドを使用すると、アーカイブREDOログおよびSPFILEのバックアップを確認できます。
CROSSCHECK BACKUP OF ARCHIVELOG ALL SPFILE;
COMPLETED AFTER句をCROSSCHECKコマンドに追加すると、確認対象のバックアップを、指定した時点以降に作成されたものに制限できます。たとえば、次のコマンドでは、先週作成されたデータ・ファイルのバックアップが確認されます。
CROSSCHECK BACKUP OF DATAFILE 4 COMPLETED AFTER 'SYSDATE-14';
Recovery Managerを使用して、Recovery Managerで作成したバックアップを削除できます。Recovery Managerを使用してバックアップを削除すると、指定したバックアップが削除されるとともに、その削除を反映するためにRecovery Managerリポジトリが更新されます。
この項では次の項目を取り上げます。
一般的には、保持する必要のないバックアップを削除するには、DELETEコマンドを使用します。DELETEは、バックアップ・メディアから物理的なファイルを削除し、（Recovery Managerがリカバリ・カタログに接続されている場合は）リカバリ・カタログからバックアップのレコードを削除して、制御ファイル内のこれらのバックアップのレコードをDELETED状態に更新します。
DELETEコマンドでは、次のような様々なタイプのバックアップの削除がサポートされています。
DELETE BACKUP（バックアップ・セット、プロキシ・コピーおよびイメージ・コピーを削除）、DELETE COPY（イメージ・コピーのみを削除）、DELETE ARCHIVELOGなどで、次の例に示されています。
DELETEコマンドでは、削除するバックアップを指定するための様々なオプションがサポートされています。これらのオプションの詳細は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。次の例には、DELETEコマンドを使用して削除するバックアップおよびアーカイブREDOログを指定する様々な一般的な方法を示します。
LIST出力の主キーを使用してバックアップを削除します。
DELETE BACKUPPIECE 101;
DELETE CONTROLFILECOPY '/tmp/control01.ctl';
DELETE NOPROMPT ARCHIVELOG UNTIL SEQUENCE = 300;
DELETE BACKUP TAG='before_upgrade';
DELETE BACKUP OF TABLESPACE users DEVICE TYPE sbt; # delete only from tape DELETE COPY OF CONTROLFILE LIKE '/tmp/%'; #
DELETE BACKUP;
DELETE ARCHIVELOG ALL BACKED UP 3 TIMES TO sbt;
対話形式でRecovery Managerを実行すると、ファイルを削除する前に確認が求められます。DELETEコマンドのいずれの形式でも、NOPROMPT キーワードを使用することによって、これらの確認をしないようにできます。
DELETE NOPROMPT ARCHIVELOG ALL;
CROSSCHECKを使用してリポジトリに記録されたバックアップがディスクまたはテープにまだ存在するかどうかを確認したときに、Recovery Managerがそのバックアップの場所を確認できない場合、Recovery ManagerはRecovery Managerリポジトリ内のそのバックアップのレコードをEXPIRED状態に更新します。その後、DELETE EXPIREDコマンドを使用して、Recovery Managerリポジトリから期限切れのバックアップのレコードを削除できます。期限切れのファイルがまだ存在する場合、DELETE EXPIREDコマンドはエラーを戻して終了します。
期限切れのリポジトリ・レコードを削除する方法
CROSSCHECKコマンドを発行します。次に例を示します。
CROSSCHECK BACKUP; # checks backup sets and copies on configured channels
DELETE EXPIRED BACKUP;
Recovery Managerリポジトリが示すオブジェクトの状態が、メディアのオブジェクトの実際の状態と異なる場合があります。たとえば、実際にはバックアップ・セットがディスクまたはテープに存在しない（または、メディア・マネージャにおけるテープやその他のバックアップ・メディアの内容のカタログから消失している）場合でも、Recovery Managerリポジトリはそのバックアップ・セットがAVAILABLEであると示します。オブジェクトを削除しようとすると、次のような警告が表示されます。
RMAN-06207: WARNING: 1 objects could not be deleted for DISK channel(s) due RMAN-06208: to mismatched status. Use CROSSCHECK command to fix status List of Mismatched objects ========================== Object Type Filename/Handle --------------- --------------------------------------------------- Backup Piece 0id270ud_1_1
オプションのFORCEキーワードを指定してDELETEコマンドを使用すると、Recovery Managerは指定されたバックアップを削除しますが、バックアップがディスクまたはテープから消失している場合に発生するエラーなど、すべてのI/Oエラーを無視します。この後で、Recovery Managerがファイルを削除できたかどうか、またはファイルがすでに消失していたかどうかに関係なく、Recovery Managerリポジトリを更新して、バックアップが削除された事実を反映します。次に例を示します。
DELETE FORCE NOPROMPT BACKUPSET TAG 'weekly_bkup';
Recovery ManagerのDELETEコマンドでは、OBSOLETEオプションがサポートされ、これによって、不要になったバックアップ、つまり指定したリカバリ可能性の要件を満たす必要がなくなったバックアップが削除されます。構成済のデフォルトの保存方針、またはDELETE OBSOLETEコマンドにオプションとして指定した他の保存方針に従って、不要とされるファイルを削除できます。DELETEコマンドの他の形式と同様に、削除されたファイルはバックアップ・メディアおよびリカバリ・カタログから削除され、制御ファイル内でDELETEDとしてマーク付けされます。
引数を付けずにDELETE OBSOLETEコマンドを指定した場合、Recovery Managerは現在構成されている保存方針によって不要と定義されるすべてのバックアップを削除します。次に例を示します。
DELETE OBSOLETE;
また、REDUNDANCY句またはRECOVERY WINDOW句をDELETEで使用すると、構成済のデフォルトのかわりに特定の保存方針で不要となるバックアップを削除できます。
DELETE OBSOLETE REDUNDANCY = 3; DELETE OBSOLETE RECOVERY WINDOW OF 7 DAYS;
DELETE OBSOLETEを実行する際、一部のバックアップに設定されたKEEP UNTIL期間を超えた場合でも、指定された保存方針を満たすために必要なバックアップは削除されません。
バックアップが保存方針を満たす必要がある場合、KEEP UNTIL句の設定にかかわらず、Recovery Managerはそのバックアップを不要とみなしません。KEEP UNTILの設定によって、バックアップが保存方針で要求される期間より長く保持されることはありますが、それより早く不要になることはありません。
KEEP UNTILの期間にかかわらず、バックアップが保存方針を満たす必要がある場合は、そのバックアップは不要にはなりません。リカバリ期間ベースの保存方針では、KEEP UNTILに指定した期間を超えても、バックアップがリカバリ期間を満たす必要がある場合はそのバックアップは保持されます。冗長性ベースの保存方針では、KEEP UNTILに指定した期間を超えても、バックアップが冗長性要件を満たす必要がある場合はそのバックアップは保持されます。
この項では次の項目を取り上げます。
CROSSCHECKまたはDELETEコマンドを発行する前に、複数のチャネルを構成するか、手動で割り当てます。Recovery Managerは、バックアップの作成に使用されたチャネルと同じデバイス・タイプのすべてのチャネルのバックアップを検索します。マルチチャネル機能の用途は主に、単一のコマンドで、ディスク上とテープ上の両方のバックアップをクロスチェックおよび削除することです。
複数のチャネルを構成するか手動で割り当てて、CROSSCHECKまたはDELETEコマンドを実行すると、Recovery Managerによって、適切なデバイス・タイプを持つすべてのチャネルでクロスチェックまたは削除が実行されます。
たとえば、チャネルを構成するのではなく、手動でチャネルを割り当てることを想定します。メディア・マネージャは構成されていますが、テープへはバックアップされていません。次のように、ディスクにデータベースのバックアップを1つだけ作成しました。
RUN { ALLOCATE CHANNEL ch1 DEVICE TYPE DISK CONNECT 'SYS/sys_pwd@node2'; BACKUP DATABASE; }
Recovery Managerプロンプトで、次の一連のコマンドを発行したとします。
ALLOCATE CHANNEL FOR MAINTENANCE DEVICE TYPE DISK CONNECT 'SYS/oracle@node1'; AlLOCATE CHANNEL FOR MAINTENANCE DEVICE TYPE DISK CONNECT 'SYS/oracle@node2'; ALLOCATE CHANNEL FOR MAINTENANCE DEVICE TYPE sbt; CROSSCHECK BACKUP OF DATABASE;
Recovery Managerリポジトリには、ディスクへのデータベースのバックアップのレコードがあるため、2つのディスク・チャネルでアクセス可能なバックアップをクロスチェックします（また、2つ目のチャネルでバックアップを検出します）。Recovery Managerリポジトリには、sbtバックアップのレコードがないため、CROSSCHECKコマンドは、割り当てられたSBTチャネルにアクセスしません。
ディスクおよびテープ用に複数のチャネルを構成している場合、Recovery Managerはすべての構成済チャネルを使用し、両方のバックアップ先で同時にクロスチェックを行います。
たとえば、sbtチャネルが次のように構成されているとします。
CONFIGURE DEVICE TYPE sbt PARALLELISM 1; CONFIGURE DEFAULT DEVICE TYPE sbt;
この場合、次のコマンドを実行してDISKおよびsbtの両方でクロスチェックを実行できます。
CROSSCHECK BACKUP OF DATABASE;
Recovery Managerは、sbtチャネルおよび事前構成されたDISKチャネルの両方を使用してクロスチェックを実行します。出力例は次のとおりです。
allocated channel: ORA_SBT_TAPE_1 channel ORA_SBT_TAPE_1: sid=12 devtype=SBT_TAPE channel ORA_SBT_TAPE_1: WARNING: Oracle Test Disk API using channel ORA_DISK_1 crosschecked backup piece: found to be 'AVAILABLE' backup piece handle=/oracle/dbs/16c5esv4_1_1 recid=36 stamp=408384484 crosschecked backup piece: found to be 'AVAILABLE' backup piece handle=/oracle/dbs/c-674966176-20000915-01 recid=37 stamp=408384496 crosschecked backup piece: found to be 'AVAILABLE' backup piece handle=12c5erb2_1_1 recid=32 stamp=408382820 crosschecked backup piece: found to be 'AVAILABLE' backup piece handle=13c5erba_1_1 recid=33 stamp=408382829 crosschecked backup piece: found to be 'AVAILABLE' backup piece handle=14c5erce_1_1 recid=34 stamp=408382863 crosschecked backup piece: found to be 'AVAILABLE' backup piece handle=c-674966176-20000915-00 recid=35 stamp=408382869
自動sbtチャネルが構成されていない場合、次の例のように、ディスクおよびテープのメンテナンス・チャネルを手動で割り当てることもできます。
RUN { ALLOCATE CHANNEL FOR MAINTENANCE DEVICE TYPE sbt; CROSSCHECK BACKUP OF DATABASE; }
Recovery Managerは事前構成されたディスク・チャネルを使用するため、ディスク・チャネルを手動で割り当てる必要はありません。
複数ノードでクロスチェックを実行する場合（また一般的にRecovery Managerを操作する場合）、バックアップがどのノードで作成されたかにかかわらず、すべてのバックアップがすべてのノードからアクセス可能になるようにクラスタを構成します。このようにクラスタを構成すると、リストアおよびクロスチェック操作中に、クラスタ内の任意のノードでチャネルを割り当てることができます。
すべてのバックアップが各ノードからアクセス可能になるようにクラスタを構成できない場合は、リストアおよびクロスチェック操作中にCONNECTオプションを指定してCONFIGURE CHANNELコマンドを実行することによって複数のノードにチャネルを割り当て、すべてのバックアップが最低でも1つのノードからアクセス可能になるようにする必要があります。クロスチェック中にいくつかのバックアップにアクセスできない場合（それらのバックアップにアクセス可能なノードにチャネルがまったく構成されていないため）、それらのバックアップは、クロスチェック後にRecovery Managerリポジトリ内でEXPIREDとマークされます。
たとえば、Oracle Real Application Cluster（RAC）構成でCONFIGURE CHANNEL...CONNECT...を使用できます。この構成では、テープ・バックアップがクラスタ内の様々なノードで作成され、各バックアップがそれが作成されたノードでのみそれらのバックアップにアクセスできます。
次の例では、RACクラスタに2つのノードが含まれ、各クラスタには、クロスチェックのためにいくつかのバックアップにアクセスするためのチャネルが1つ必要であると想定しています。次のようにチャネルを構成します。
CONFIGURE DEVICE TYPE DISK PARALLELISM 2; CONFIGURE CHANNEL 1 DEVICE TYPE DISK CONNECT 'SYS/oracle@node_1'; CONFIGURE CHANNEL 2 DEVICE TYPE DISK CONNECT 'SYS/oracle@node_2';
次に、次のコマンドを実行してクラスタ・ノードをクロスチェックします。
CROSSCHECK BACKUP;
割り当てられたすべてのチャネルで削除を実行することもできます。次の例では、sbtチャネルを構成します。
CONFIGURE DEVICE TYPE sbt PARALLELISM 1; CONFIGURE DEFAULT DEVICE TYPE TO sbt;
次に、コマンドを実行して、ディスクおよびテープのすべてのバックアップ・セットを削除します。
DELETE BACKUPSET;
Recovery Managerは、構成されたsbtチャネルおよび事前構成されたDISKチャネルの両方を使用して削除を実行します。次の出力例では、Recovery Managerは、ファイルを削除する前に確認を求めるプロンプトを表示します。
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 ------- ------- --- --- ----------- ----------- ---------- 388 387 1 1 AVAILABLE SBT_TAPE 12c5erb2_1_1 397 396 1 1 UNAVAILABLE SBT_TAPE 13c5erba_1_1 424 423 1 1 AVAILABLE SBT_TAPE 14c5erce_1_1 428 427 1 1 AVAILABLE SBT_TAPE c-674966176-20000915-00 433 432 1 1 AVAILABLE DISK /oracle/dbs/16c5esv4_1_1 437 436 1 1 AVAILABLE DISK /oracle/dbs/c-674966176-20000915-01 Do you really want to delete the above objects (enter YES or NO)? y deleted backup piece backup piece handle=/oracle/dbs/16c5esv4_1_1 recid=36 stamp=408384484 deleted backup piece backup piece handle=/oracle/dbs/c-674966176-20000915-01 recid=37 stamp=408384496 deleted backup piece backup piece handle=12c5erb2_1_1 recid=32 stamp=408382820 deleted backup piece backup piece handle=13c5erba_1_1 recid=33 stamp=408382829 deleted backup piece backup piece handle=14c5erce_1_1 recid=34 stamp=408382863 deleted backup piece backup piece handle=c-674966176-20000915-00 recid=35 stamp=408382869
次の例では、DISKおよびsbtのメンテナンス・チャネルを手動で割り当てて、ディスクおよびテープの両方から特定のバックアップ・セットを削除します。
RUN { ALLOCATE CHANNEL FOR MAINTENANCE DEVICE TYPE DISK; ALLOCATE CHANNEL FOR MAINTENANCE DEVICE TYPE sbt; DELETE BACKUPSET 1,2,3,4,5; }
Recovery Managerはチャネル上の特定のバックアップ・セットを検索して、検出されたバックアップ・セットを削除します。チャネル上でバックアップが検出されない場合、Recovery Managerは制御ファイルにあるそのオブジェクトに削除されたことを示すマークを付けて、リカバリ・カタログ・レコードを削除します（リカバリ・カタログを使用している場合）。
次のコマンドを実行すると、割り当てられたすべてのメンテナンス・チャネルを解放できます。
RELEASE CHANNEL;
オペレーティング・システムからデータベースを削除する必要がある場合があります。たとえば、テスト・データベースを作成した後、そのテスト・データベースは必要なくなります。このような場合、Recovery ManagerでDROP DATABASEコマンドを使用するか、またはSQL*PlusでDROP DATABASE文を使用します。
DROP DATABASEでは、マウントされたターゲット・データベースにRecovery Managerが接続されている必要があります。リカバリ・カタログへの接続は必要ありません。Recovery Managerをリカバリ・カタログに接続した状態でオプションINCLUDE COPIES AND BACKUPSを指定すると、Recovery Managerはデータベースも登録解除します。
データベースを削除する方法
rman TARGET / CATALOG rman/rman@catdb
RMAN> CATALOG START WITH '+disk1'; # all files from flash recovery area # (stored on ASM disk) RMAN> CATALOG START WITH '/arch_dest2'; # all files from second arch dest
RMAN> DELETE BACKUPSET; # deletes all backups RMAN> DELETE COPY; # delete all image copies (including archived logs)
DROP DATABASE; # delete all database files and unregister the database
この項では次の項目を取り上げます。
バックアップが検出されない場合、またはサイト外に移された場合は、CHANGE ... UNAVAILABLEコマンドを実行します。Recovery Managerは、RESTOREまたはRECOVERコマンドでは、UNAVAILABLEのマークの付いたファイルを使用しません。 ファイルが後で検出された場合、またはメイン・サイトに戻された場合は、CHANGE ... AVAILABLEを発行して再度使用可能であることを示すマークを付けます。
フラッシュ・リカバリ領域内のファイルをUNAVAILABLEにマークすることはできません。
リポジトリのファイルの状態にUNAVAILABLEまたはAVAILABLEのマークを付ける方法
LISTコマンドを発行して、Recovery Managerバックアップの可用性の状態を確認します。次に例を示します。
LIST BACKUP;
UNAVAILABLEまたはAVAILABLEキーワードを指定してCHANGEを実行し、Recovery Managerリポジトリの状態を更新します。次に例を示します。
CHANGE DATAFILECOPY '/tmp/control01.ctl' UNAVAILABLE; CHANGE COPY OF ARCHIVELOG SEQUENCE BETWEEN 1000 AND 1012 UNAVAILABLE; CHANGE BACKUPSET 12 UNAVAILABLE; CHANGE BACKUP OF SPFILE TAG "TAG20020208T154556" UNAVAILABLE; CHANGE DATAFILECOPY '/tmp/system01.dbf' AVAILABLE; CHANGE BACKUPSET 12 AVAILABLE; CHANGE BACKUP OF SPFILE TAG "TAG20020208T154556" AVAILABLE;
BACKUP ... KEEPコマンドを使用すると、構成済みの保存方針とは異なる期間、バックアップを保持できます。ただし、バックアップは完全に有効で、他のRecovery Managerバックアップと同様にリストアできます。このタイプのバックアップは長期バックアップと呼ばれます。
不完全リカバリ用にアーカイブ・ログを保存する場合は、KEEP ... LOGSを指定し、保存しない場合はKEEP ... NOLOGSを指定します。NOLOGSは、非一貫性バックアップでは無効です。
既存のバックアップのKEEP状態を変更するには、CHANGEコマンドを使用します。たとえば、長期バックアップを保持する必要のない場合にこのコマンドを使用します。 BACKUP ... KEEPで使用できるオプションを、CHANGE ... KEEPでも使用できます。
フラッシュ・リカバリ領域に格納されているファイルにはKEEP属性を設定できないことに注意してください。
バックアップのKEEP状態を変更する方法
CHANGE ... KEEPを発行して保存方針とは異なる保存期間を定義するか、CHANGE ... NOKEEPを発行して保存方針をこのファイルに適用します。
次の例では、保存方針に基づいてバックアップ・セットに不要のマークが付けられます。
CHANGE BACKUPSET 231 NOKEEP;
次の例では、データ・ファイルのコピーを保存方針から180日（6か月）の間除外します。
CHANGE DATAFILECOPY '/tmp/system01.dbf' KEEP UNTIL 'SYSDATE+180';
Recovery Manager以外の方法を使用して作成されたファイルおよびバックアップ・ピースのコピーと同様に、リポジトリに記録されていないアーカイブ・ログが存在することをRecovery Managerに認識させることができます。この項では次の項目を取り上げます。
ターゲット・データベースの制御ファイルは、ターゲット・データベースによって生成されたすべてのアーカイブ・ログのレコードと、すべてのRecovery Managerバックアップを保持します。CATALOGコマンドを実行すると、Recovery Managerに認識させたいファイルのレコードが存在しない場合に、メタデータをリポジトリに追加できます。
次の場合に、Recovery ManagerのCATALOGコマンドを実行します。
UNIXのcpコマンドを使用したデータ・ファイルのコピーなど、ユーザー管理コピーを作成するときには必ずカタログに追加してください。 ユーザー管理コピーを作成する場合、ALTER TABLESPACE ... BEGIN/END BACKUP文を使用してオンライン表領域のデータ・ファイルのコピーを作成できます。Recovery Managerはこのようなデータ・ファイルのコピーを作成しませんが、CATALOGコマンドを使用してデータ・ファイルのコピーをリカバリ・カタログに追加し、Recovery Managerに認識させることができます。
ユーザー管理コピーをカタログに追加する場合は、次のものが必要です。
たとえば、ミラー化されたディスク・ドライブ上にデータ・ファイルを格納する場合、ミラー化を解除することによって、ユーザー管理コピーを作成できます。この場合、ミラー化を解除した後にCATALOGコマンドを使用してユーザー管理コピーが存在することをRecovery Managerに通知します。 再度ミラー化する前に、CHANGE ... UNCATALOGコマンドを実行してファイルのコピーが存在しないことをRecovery Managerに通知します。
CATALOGコマンドを使用して、ユーザー管理コピーに関する情報をRecovery Managerリポジトリに伝播します。ファイルがカタログに追加されたら、LISTを実行するかV$BACKUP_FILESを問い合せて確認します。
データ・ファイルのユーザー管理コピーを作成してカタログに追加する方法
ALTER TABLESPACE BEGIN/END BACKUPを実行する必要があります。この例では、オンライン・データ・ファイルをバックアップします。
SQL> ALTER TABLESPACE users BEGIN BACKUP; % cp $ORACLE_HOME/oradata/trgt/users01.dbf /tmp/users01.dbf; SQL> ALTER TABLESPACE users END BACKUP;
CATALOGコマンドを実行します。次に例を示します。
CATALOG DATAFILECOPY '/tmp/users01.dbf';
接続したターゲット・データベース以外のデータベースからのデータ・ファイルのコピーをカタログに追加しようとすると、次のようなエラーが表示されます。
RMAN-00571: =========================================================== RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS =============== RMAN-00571: =========================================================== RMAN-03009: failure of catalog command on default channel at 08/29/2001 14:44:34 ORA-19563: datafile copy header validation failed for file /tmp/tools01.dbf
ディスク上のバックアップ・ピースをカタログに追加できます。この方式は、オペレーティング・システムのユーティリティを使用して、ある場所から同じホストの別の場所へ、またはあるホストから別のホストへバックアップ・ピースをコピーする場合に有効です。以前のインカネーションのデータベースからバックアップ・ピースのカタログを追加することもできます。Recovery Managerは、後続のリストアおよびリカバリ操作時にバックアップ・ピースを使用できるかどうかを決定できます。
バックアップ・ピースをカタログに追加する方法
CATALOG BACKUPPIECE '/disk2/09dtq55d_1_2', '/disk2/0bdtqdou_1_1';
バックアップ・ピースをカタログに追加した後、V$BACKUP_PIECE、V$BACKUP_SET、V$BACKUP_DATAFILE、V$BACKUP_REDOLOGおよびV$BACKUP_SPFILEを問い合せることによってメタデータを表示できます。
V$ビューを問い合せて、変更を確認できます。次に例を示します。
SELECT HANDLE FROM V$BACKUP_PIECE;
自動ストレージ管理（ASM）、Oracle Managed Filesのフレームワークまたはフラッシュ・リカバリ領域を使用する場合は、ディスクの管理システムには認識されているが、Recovery Managerリポジトリには表示されていないファイルを再度カタログに追加する必要があります。この状況は、メディア障害、ソフトウェアの不具合またはユーザー・エラーのためにファイル名を追跡するメカニズムが失敗したときに発生する場合があります。
CATALOG START WITHコマンドを使用すると、ASMディスク・グループ、Oracle Managed Filesまたは従来のファイル・システム・ディレクトリにあるすべてのファイルを検索して、Recovery Managerリポジトリに記録されていないファイルを調べることができます。このコマンドでファイルをカタログに追加できる場合、ファイルはカタログに追加されます。このコマンドでファイルをカタログに追加できない場合は、スキップしたファイルに最も近い内容が推測されます。
ディスクの場所にあるすべてのファイルをカタログへ追加する手順
Recovery Managerをターゲット・データベースに接続してから、カタログに追加するファイルのディスクの場所を指定します。次に例を示します。
RMAN> CATALOG START WITH '+disk'; # catalog all files from an ASM disk group RMAN> CATALOG START WITH '/fs1/datafiles/'; # catalog all files in directory
CATALOG RECOVERY AREAコマンドを実行すると、フラッシュ・リカバリ領域のすべてのファイルがカタログに追加されます。この操作中、Recovery Managerリポジトリにリストされないリカバリ領域内のすべてのファイルは、Recovery Managerリポジトリに追加されます。次に例を示します。
CATALOG RECOVERY AREA;
この項では次の項目を取り上げます。
CHANGE ... UNCATALOGコマンドを実行すると、Recovery Managerリポジトリのレコードに次の処理を実行します。
Recovery Managerは、指定した物理ファイルは変更しません。ファイルのリポジトリ・レコードのみを変更します。
このコマンドは、Recovery Manager以外の方法でバックアップを削除した場合に使用できます。 たとえば、オペレーティング・システムのユーティリティを使用してアーカイブREDOログを削除した場合、CHANGE ARCHIVELOG ... UNCATALOGを発行することによってリポジトリからこのログのレコードを削除します。
オペレーティング・システムのユーティリティを使用して削除したファイルのカタログ・レコードを削除するには、CHANGE ... UNCATALOGコマンドを実行します。
オペレーティング・システムのユーティリティを使用して削除したバックアップのカタログ・レコードを削除する方法
CHANGE ... UNCATALOGを実行します。次の例では、制御ファイルおよびデータ・ファイル1のディスク・コピーへのリポジトリの参照を削除します。
CHANGE CONTROLFILECOPY '/tmp/control01.ctl' UNCATALOG; CHANGE DATAFILECOPY '/tmp/system01.dbf' UNCATALOG;
RC_DATAFILE_COPY、RC_CONTROLFILE_COPYなど）を参照して、指定したレコードが削除されたことを確認します。たとえば、次の問合せによって、コピー4833のレコードが削除されたことを確認します。
SELECT CDF_KEY, STATUS FROM RC_DATAFILE_COPY WHERE CDF_KEY = 4833; CDF_KEY STATUS ---------- ------ 0 rows selected.
フラッシュ・リカバリ領域は自己管理されていますが、DBAの介入が必要な場合があります。
削除対象のファイルがない場合にフラッシュ・リカバリ領域が一杯になるという状態を解決するいくつかの方法があります。
DB_RECOVERY_FILE_DEST_SIZEを増加して、新しい領域に反映します。
BACKUP RECOVERY AREAコマンドがあります。バックアップをフラッシュ・リカバリ領域からテープに転送した後、Recovery ManagerのDELETEコマンドの形式を使用し、フラッシュ・リカバリ領域からファイルを削除することで、フラッシュ・リカバリ領域全体の状態を解決できます。
DELETEコマンドを使用して、フラッシュ・リカバリ領域から不要なファイルを削除します。（ホスト・オペレーティング・システムのコマンドを使用してファイルを削除しても、データベースでは、削除した結果できる空き領域が認識されないことに注意してください。Recovery ManagerのCROSSCHECKコマンドを使用して、フラッシュ・リカバリ領域の内容を再確認し、期限切れのファイルを特定した後、DELETE EXPIREDコマンドを使用して、Recovery Managerリポジトリから欠落しているファイルを削除できます）。
また、バックアップ保存方針の変更について考慮する必要があります。Data Guardを使用している場合は、アーカイブ・ログの削除方針の変更についても考慮する必要があります。
|
参照:
保存方針の決定方法については第4章「Recovery Managerを使用したデータベースのバックアップ」、Data Guard使用時のアーカイブ・ログの削除方針については『Oracle Data Guard概要および管理』を参照してください。 |
データベースのフラッシュ・リカバリ領域を新しい位置に移動する必要がある場合は、次の手順に従います。
DB_RECOVERY_FILE_DEST初期化パラメータを変更します。次に例を示します。
ALTER SYSTEM SET DB_RECOVERY_FILE_DEST='+disk1' SCOPE=BOTH SID='*';
このパラメータを変更すると、新しいフラッシュ・リカバリ領域のすべてのファイルは新しい位置に作成されます。
実際に現行の永続ファイル、一時ファイルまたはフラッシュバック・ログを新しいフラッシュ・リカバリ領域に移動する必要がある場合は、『Oracle Databaseバックアップおよびリカバリ・アドバンスト・ユーザーズ・ガイド』を参照してください。そのマニュアルでは、Recovery Managerを使用して、ASMディスク・グループとの間でデータ・ファイルを移動する処理について説明しています。この処理は、フラッシュ・リカバリ領域との間でファイルを移動する際にも有効です。
フラッシュ・リカバリ領域の以前の場所に残っている永続ファイルは、削除対象とみなされて削除されます。
通常、フラッシュ・リカバリ領域は自己管理されていますが、フラッシュ・リカバリ領域でファイルを作成中にインスタンスがクラッシュすると、フラッシュ・リカバリ領域にファイルが残される場合があります。このような場合、アラート・ログに次のようなメッセージが表示されます。
ORA-19816: WARNING: Files may exist in location that are not known to database.
locationはフラッシュ・リカバリ領域の位置です。
この場合、Recovery ManagerコマンドCATALOG RECOVERY AREAを使用して、該当するファイルをRecovery Managerリポジトリに存在するように再度カタログに追加する必要があります。問題のファイルのファイル・ヘッダーが破損している場合は、オペレーティング・システム・レベルのユーティリティを使用して、手動でファイルを削除する必要があります。
|
 Copyright © 2006 Oracle Corporation. All Rights Reserved. |
|