11g リリース1（11.1）
E05700-03
 目次 |
 索引 |
| Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド 11g リリース1（11.1） E05700-03 |
|
この章では、Recovery Managerのリポジトリ・レコードおよびRecovery Managerのバックアップとコピーの管理方法について説明します。また、フラッシュ・リカバリ領域に関連するメンテナンス・タスクについても説明します。この章の内容は、次のとおりです。
この項では、Recovery Managerリポジトリのメンテナンスの目的および基本的な概念について説明します。
メンテナンス計画では、フラッシュ・リカバリ領域、バックアップの保存方針およびアーカイブREDOログの削除方針を構成することをお薦めします。この場合、バックアップおよびアーカイブREDOログは、必要に応じてデータベースによって自動的にメンテナンスおよび削除されます。ただし、データベース・バックアップおよびアーカイブREDOログを手動でメンテナンスする必要がある場合もあります。
Recovery Managerバックアップを管理する場合は、次の関連タスクを実行します。
Recovery Managerのメンテナンスでの重要なタスクに、不要となったバックアップの削除があります。フラッシュ・リカバリ領域を構成すると、この領域内の不要なファイルはデータベースによって自動的に削除されます。ただし、この場合も、バックアップおよびコピーをテープから削除する必要があることがあります。データベース全体を削除する必要がある場合もあります。Recovery Managerコマンドを使用すると、これらのタスクを実行できます。
フラッシュ・リカバリ領域には、不定期のメンテナンスが必要な場合があります。たとえば、フラッシュ・リカバリ領域が一杯になり、フラッシュ・リカバリ領域に領域を追加する必要がある場合があります。また、リカバリ領域の場所を変更する必要がある場合もあります。
ディスクおよびテープ上のファイルの実際の状態がRecovery Managerリポジトリに反映されない場合があります。たとえば、ユーザーがオペレーティング・システムのユーティリティを使用して、バックアップをディスクから削除する場合があります。この場合、Recovery Managerリポジトリには、実際には存在しないファイルが存在しているように表示されます。Recovery Managerバックアップが格納されているテープが破損した場合も、同様の状況が発生します。Recovery Managerのメンテナンス・コマンドを使用すると、リポジトリを正しい情報で更新できます。
Recovery Managerのメンテナンス・コマンドの概要を次に示します。
CATALOGコマンドを使用すると、Recovery Managerリポジトリに現在記録されていないRecovery Managerバックアップおよびユーザー管理のバックアップに関するレコードを追加したり、記録されているバックアップのレコードを削除することができます。
CHANGEコマンドを使用すると、Recovery Managerリポジトリのレコードのステータスを更新できます。
CROSSCHECKコマンドを使用すると、論理バックアップ・レコードをバックアップ・ストレージ内のファイルの物理的な状態と同期化できます。
DELETEコマンドを使用すると、オペレーティング・システムからバックアップを削除できます。
Recovery Managerは、操作の実行対象となる各ターゲット・データベースの制御ファイルに、そのメタデータを常に格納します。ターゲット・データベースをリカバリ・カタログに登録すると、Recovery Managerは、このターゲット・データベースのメタデータをリカバリ・カタログに格納します。Recovery Managerのすべてのメンテナンス・コマンドは、リカバリ・カタログを使用しているかどうかに関係なく動作します。
「Data Guard環境でのRecovery Managerによるファイル管理」で説明されているように、Data Guard環境では、バックアップまたはコピーを作成するデータベースはファイルに関連付けられています。たとえば、Recovery Managerがターゲット・データベースstandby1に接続し、このデータベースをバックアップする場合、このバックアップはstandby1に関連付けられます。
「Data Guard環境でのRecovery Managerによるファイル管理」で指定されている基準に従ってRecovery Managerからバックアップにアクセスできるかぎり、プライマリ・データベースまたはスタンバイ・データベースへの接続時に、バックアップに対してCHANGE、DELETEおよびCROSSCHECKなどのRecovery Managerメンテナンス・コマンドを使用できます。
クロスチェックする場合、Recovery Managerは、ファイルに関連付けられているデータベースへの接続時にのみ、ファイルのステータスをAVAILABLEからEXPIREDに更新できます。このため、Recovery Managerでクロスチェックしてもファイルが検出されず、Recovery ManagerがTARGETとして接続されていないデータベースにファイルが関連付けられている場合は、そのファイルに関連付けられているターゲット・データベースへの接続時に、Recovery Managerによってクロスチェックの実行が求められます。Recovery Managerは、CROSSCHECKまたはCHANGE ... AVAILABLEコマンドの実行時にクロスチェックを行うことに注意してください。
Recovery Managerは、データベースへの接続時にファイルを削除できます。ファイルに関連付けられているデータベースにRecovery ManagerがTARGETとして接続されておらず、Recovery Managerでファイルを正常に削除できない場合は、Recovery Managerによって、ファイルに関連付けられているデータベースにTARGETとして接続するように求められます。このため、ファイルのメタデータを削除するには、DELETE ... FORCEを使用する必要があります。
メンテナンス・コマンドでRecovery Managerのメタデータのみを変更した場合は、Recovery ManagerをTARGETとしてData Guard環境のデータベースに接続できます。メタデータのみを変更するコマンドは、次のとおりです。
CHANGE ... UNAVAILABLEまたはCHANGE ... UNCATALOG
CHANGE ... KEEPまたはCHANGE ... NOKEEP
CHANGE ... RESET DB_UNIQUE_NAME
デフォルトでは、CHANGEコマンドを使用すると、「Data Guard環境でのバックアップのアクセシビリティについて」で指定されている規則に従ってアクセス可能なファイルに対してのみ操作が行われます。ただし、FOR DB_UNIQUE_NAMEオプションを使用すると、ターゲット・データベース以外のデータベースに関連付けられているファイルのステータスを変更できます。
特定のファイルでDB_UNIQUE_NAMEが認識されない場合があります。たとえば、データベース名がカタログで認識されない場合は、リカバリ・カタログに登録されているOracle9i データベースの場合と同様に、DB_UNIQUE_NAMEの値はnullになります。また、データベースを現行のバージョンにアップグレードしたにもかかわらず、リカバリ・カタログ・スキーマとすべてのファイルのDB_UNIQUE_NAME値が一致していないため、行のDB_UNIQUE_NAMEがnullになる場合もあります。デフォルトでは、Recovery Managerは、TARGETとして接続されているデータベースにSITE_KEYがnullのファイルを関連付けます。CHANGE ... RESET DB_UNIQUE_NAMEを明示的に使用して別のデータベースに関連付けないかぎり、バックアップはそのデータベースに関連付けられたままです。
Recovery Managerは、リカバリ・カタログを使用しなくても動作するように設計されています。ただし、リカバリ・カタログを使用しないことを選択すると、各ターゲット・データベースの制御ファイルは、Recovery Managerメタデータ用の排他的なリポジトリになります。制御ファイルへの情報の格納方法を理解し、バックアップおよびリカバリ計画によって制御ファイルが保護されるようにする必要があります。
制御ファイルには、循環再利用レコードおよび非循環再利用レコードの2つのタイプのレコードが含まれています。
循環再利用レコードには、必要に応じて上書き可能な、重要度が低い情報が含まれます。これらのレコードには、データベースによって持続的に生成される情報が含まれます。使用可能なレコード・スロットがすべて使用されると、データベースは、制御ファイルを拡張して新規レコード用の領域を作成するか、または最も古いレコードを上書きします。CONTROL_FILE_RECORD_KEEP_TIME初期化パラメータには、レコードを再利用するまでの最短保管日数を指定します。
非循環再利用レコードには、頻繁には変更されず、上書きできない重要な情報が含まれます。非循環再利用レコードに含まれる情報は、データファイル、オンラインREDOログ・ファイル、REDOスレッドなどです。
ターゲット・データベースのバックアップを作成すると、データベースによってそれらのバックアップが制御ファイルに記録されます。新しいレコードを追加したことによって制御ファイルが過度に大きくならないように、指定したしきい値より古いレコードは再利用可能になります。CONTROL_FILE_RECORD_KEEP_TIME初期化パラメータは、レコードが上書き可能になるまでの最小日数を決定します。
CONTROL_FILE_RECORD_KEEP_TIME = integer
たとえば、パラメータ値が14の場合、14日以上経過したレコードは再利用の候補となります。上書きされたレコードの情報は失われます。再利用可能な最も古いレコードが最初に使用されます。
データベースでは、新しいRecovery Managerリポジトリ・レコードを制御ファイルに追加する必要があるにもかかわらず、しきい値より古いレコードが存在しない場合、制御ファイル・サイズの拡大が試行されます。基礎となるオペレーティング・システムで（ディスクが一杯などの状況によって）制御ファイルを拡大できない場合は、データベースによって制御ファイル内の最も古いレコードが上書きされます。
上書きは、自動診断リポジトリ内のアラート・ログに記録されます。上書きされる各レコードに対するエントリが、アラート・ログに次のように記録されます。
kccwnc: following control file record written over: RECID #72 Recno 72 Record timestamp 07/28/06 22:15:21 Thread=1 Seq#=3460 Backup set key: stamp=372031415, count=17 Low scn: 0x0000.3af33f36 07/27/06 21:00:08 Next scn: 0x0000.3af3871b 07/27/06 23:23:54 Resetlogs scn and time scn: 0x0000.00000001
フラッシュ・リカバリ領域に作成されたファイルに関する情報を含む制御ファイルのレコードが再利用される際、そのファイルが削除対象である場合は、データベースによってフラッシュ・リカバリ領域からのそのファイルの削除が試行されます。削除対象でない場合は、このファイルのレコードを含む制御ファイルのセクションのサイズが拡大されます。この拡大に関して、アラート・ログに次の例のようなメッセージが記録されます。ここで、nnnnは、制御ファイル・レコードのタイプの番号です。
kccwnc: trying to expand control file section nnnn for Oracle Managed Files
制御ファイルがホスト・オペレーティング・システムでサポートされている最大サイズに達している場合、制御ファイルを拡大することはできません。このような場合は、次の警告がアラート・ログに表示されます。
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.
前述のメッセージは、構成されている保存方針を満たすために必要なすべてのフラッシュ・リカバリ領域ファイルのレコードを制御ファイルで保持できないことを示しています。次の項では、この状況に対応する方法について説明します。
制御ファイル・レコードの上書きによってRecovery Managerメタデータが消失することを防止するには、リカバリ・カタログを使用する方法が最適です。リカバリ・カタログを使用できない場合は、次の方法を使用できます。
CONTROL_FILE_RECORD_KEEP_TIMEの値を、保持する必要がある最も古いファイルの期間より少し長く設定します。たとえば、データベース全体を1週間に1回バックアップする場合は、すべてのバックアップを7日間以上保持する必要があります。CONTROL_FILE_RECORD_KEEP_TIMEの値を10や14などに設定します。CONTROL_FILE_RECORD_KEEP_TIMEのデフォルト値は7日間です。
フラッシュ・リカバリ領域を使用する場合は、次のガイドラインに従って、バックアップ保存方針を満たすために必要なすべてのフラッシュ・リカバリ領域ファイルのレコードを制御ファイルで保持できなくなるような状況を回避します。
これを実現するには、SYSTEM表領域のブロック・サイズを制御ファイルのブロック・サイズ以上に設定し、DB_BLOCK_SIZEの変更後に制御ファイルを再作成する必要があります。フラッシュ・リカバリ領域内のファイルはカタログに再度追加されますが、テープに格納されているファイルのレコードは失われることに注意してください。
たとえば、BACKUP RECOVERY AREAを使用すると、フラッシュ・リカバリ領域内のファイルを明示的にメディア・マネージャにバックアップできます。
リカバリ・カタログを使用してRecovery Managerメタデータを格納していない場合は、各ターゲット・データベースの制御ファイルを保護することがさらに重要となります。次の計画を使用すると、制御ファイルを保護することができます。
これによって、制御ファイルのサブセットが消失した場合に、ユーザーが制御ファイルをバックアップからリストアする必要がなくなります。2つ以上の多重制御ファイルまたはミラー化制御ファイルを別々のディスクで使用することをお薦めします。
この場合、特定のRecovery Managerコマンドを実行すると、制御ファイルが自動的にバックアップされます。制御ファィルの自動バックアップを使用できるかぎり、Recovery Managerは、サーバー・パラメータ・ファイルおよびバックアップ制御ファイルをリストアしてデータベースをマウントできます。制御ファイルをマウントした後、データベースの残りの部分をリストアできます。
制御ファイルが失われると、データベースのリカバリにDBIDが必要になる場合があります。
|
参照:
|
フラッシュ・リカバリ領域は多くの場合自動管理されますが、DBAの介入が必要になることもあります。
フラッシュ・リカバリ領域の内容および永続的なファイルと一時的なファイルの違いについては、「フラッシュ・リカバリ領域の概要」を参照してください。この章を読む前に、これらの項を参照してください。次の規則によって、ファイルがリカバリ領域からの削除対象となるタイミングが制御されます。
保存方針の構成方法については、「バックアップの保存方針の構成」を参照してください。
ログが削除対象となるタイミングを決定するアーカイブREDOログの削除方針の構成方法については、「アーカイブREDOログの削除方針の構成」を参照してください。ログのコンシューマには、Recovery Manager、スタンバイ・データベース、Oracle Streamsデータベースおよびフラッシュバック・データベース機能などがあります。Data Guard環境でのアーカイブREDOログ管理については、『Oracle Data Guard概要および管理』を参照してください。
フラッシュ・リカバリ領域からのファイルの削除を制御する安全で確実な方法は、保存方針（「バックアップの保存方針の構成」を参照）およびアーカイブ・ログの削除方針（「アーカイブREDOログの削除方針の構成」を参照）を構成する方法です。テープに移動したファイルがディスクに保存される可能性を高くするには、フラッシュ・リカバリ領域の割当て制限を大きくします。
V$RECOVERY_FILE_DESTビューおよびV$FLASH_RECOVERY_AREA_USAGEビューを使用すると、フラッシュ・リカバリ領域に十分な領域が割り当てられているかどうかを確認できます。V$RECOVERY_FILE_DESTビューを問い合せて、フラッシュ・リカバリ領域の現在の位置、ディスク割当て制限、使用領域、ファイル削除による再利用可能な領域、およびファイルの合計数を確認します。たとえば、例11-1に示す問合せを入力します（出力例も示します）。SPACE列はバイト単位で指定することに注意してください。
SELECT * FROM V$RECOVERY_FILE_DEST; NAME SPACE_LIMIT SPACE_USED SPACE_RECLAIMABLE NUMBER_OF_FILES -------------- ----------- ---------- ----------------- --------------- /mydisk/rcva 5368709120 109240320 256000 28
異なるタイプのファイルで使用されている合計ディスク割当て制限の割合を確認するには、V$FLASH_RECOVERY_AREA_USAGEビューを問い合せます。また、不要なファイル、冗長なファイルまたはすでにテープにバックアップされているファイルを削除することによって、各タイプのファイル用に再利用できる領域の量を判断することもできます。たとえば、次の問合せを入力します（出力例も示します）。
SELECT * FROM V$FLASH_RECOVERY_AREA_USAGE; FILE_TYPE PERCENT_SPACE_USED PERCENT_SPACE_RECLAIMABLE NUMBER_OF_FILES ------------ ------------------ ------------------------- --------------- CONTROLFILE 0 0 0 ONLINELOG 2 0 22 ARCHIVELOG 4.05 2.01 31 BACKUPPIECE 3.94 3.86 8 IMAGECOPY 15.64 10.43 66 FLASHBACKLOG .08 0 1
保証付きリストア・ポイントがデータベースに定義されている場合は、保証を満たすために必要なファイル用にフラッシュ・リカバリ領域で使用される領域の量を監視する必要があります。保証付きリストア・ポイントを表示する問合せ（「リストア・ポイントの表示」を参照）を使用し、STORAGE_SIZE列を参照して、各保証付きリストア・ポイントに関連するファイルに必要な領域を決定します。
フラッシュバック・ログの削除規則については、「Oracle Flashback Databaseおよびリストア・ポイントの構成」を参照してください。フラッシュ・リカバリ領域のフラッシュバック・ログは、フラッシュバックの保存ターゲットを設定するか、または保証付きリストア・ポイントを使用する以外に直接管理することはできません。ただし、フラッシュバック・ログの保存に使用できる領域を最大化するために、フラッシュ・リカバリ領域を全体として管理することはできます。これによって、フラッシュバック目標を達成する可能性が高くなります。
フラッシュバック・ログ用の領域を確保するには、BACKUP RECOVERY AREA、BACKUP BACKUPSETなどのコマンドを使用して、フラッシュバック・リカバリ領域の他の内容をテープにバックアップします。Oracle Databaseでは、不要になったファイルがフラッシュ・リカバリ領域から自動的に削除されます。バックアップをテープにオフロードしても、バックアップ保存方針およびフラッシュバック保存目標を満たす十分な領域が作成されない場合は、フラッシュ・リカバリ領域により多くの領域を割り当てます。
Recovery Managerの保存方針によってフラッシュバック・リカバリ領域のディスク割当て制限より大きいバックアップのセットを保存する必要がある場合、またはこの保存方針がNONEに設定されている場合、フラッシュ・リカバリ領域は再利用可能な領域がなくなるまで完全に一杯になることがあります。
再利用可能な領域が15%未満になると警告アラートが発行され、再利用可能な領域が3%未満になるとクリティカル・アラートが発行されます。この状況をDBAに警告するために、アラート・ログおよびDBA_OUTSTANDING_ALERTS表（Enterprise Managerで使用）にエントリが追加されます。ただし、フラッシュ・リカバリ領域内の領域は、再利用可能な領域がなくなるまでデータベースによって継続して消費されます。
リカバリ領域が完全に一杯になると、次のエラーを受信します。ここで、nnnnnは必要なバイト数、mmmmはディスク割当て制限です。
ORA-19809: limit exceeded for recovery files ORA-19804: cannot reclaim nnnnn bytes disk space from mmmmm limit
削除対象のファイルがない場合にフラッシュ・リカバリ領域が一杯になった状態を解消する方法として、次のいくつかの方法があります。
DB_RECOVERY_FILE_DEST_SIZEを増加して、追加した領域を反映させます。
リカバリ領域のすべてのファイルを一度にテープにバックアップする簡単な方法の1つに、BACKUP RECOVERY AREAコマンドがあります。バックアップをリカバリ領域からテープに転送した後、フラッシュ・リカバリ領域からファイルを削除できます（「Recovery ManagerバックアップおよびアーカイブREDOログの削除」を参照）。フラッシュバック・ログは、リカバリ領域外にはバックアップできないため、BACKUP RECOVERY AREAではバックアップされないことに注意してください。
DELETEを実行します。ホスト・オペレーティング・システムのコマンドを使用してファイルを削除した場合、その結果できる空き領域はデータベースでは認識されません。Recovery ManagerのCROSSCHECKコマンドを実行して、フラッシュ・リカバリ領域の内容を再確認し、期限切れのファイルを特定した後、DELETE EXPIREDコマンドを使用して、Recovery Managerリポジトリからすべての期限切れのバックアップを削除することができます。
保証付きリストア・ポイントで必要ないフラッシュバック・ログは、フラッシュ・リカバリ領域内の他のファイルの領域を確保するために自動的に削除されます。保証付きリストア・ポイントを使用すると、リストア・ポイントSCNまでフラッシュバック・データベースを実行するために必要なフラッシュバック・ログを強制的に保存できます。
保存方針の決定については第8章「データベースのバックアップ」、Data Guard使用時のアーカイブ・ログの削除方針については『Oracle Data Guard概要および管理』を参照してください。
参照:
既存のリストア・ポイントが不要であること確認した場合、または既存のリストア・ポイントの名前を使用して新しいリストア・ポイントを作成する必要がある場合は、SQL文DROP RESTORE POINTを使用して、リストア・ポイントを削除できます。たとえば、次のように入力します。
DROP RESTORE POINT before_app_upgrade;
通常のリストア・ポイントおよび保証付きリストア・ポイントの両方の削除に、同じ文を使用します。
通常のリストア・ポイントは、明示的に削除しなくても、最終的には制御ファイルからエージ・アウトされます。制御ファイル内のリストア・ポイントは、次の規則に基づいて保存されます。
CONTROL_FILE_RECORD_KEEP_TIMEの値よりも新しいリストア・ポイントは、定義されているリストア・ポイント数に関係なく、いずれも保持されます。
前述の条件のいずれかを満たさない通常のリストア・ポイントは、制御ファイルからエージ・アウトされる場合があります。保証付きリストア・ポイントが、制御ファイルからエージ・アウトされることはありません。これらは、明示的に削除されるまで保存されます。
データベースのフラッシュ・リカバリ領域を新しい場所に移動する必要がある場合は、次の手順を実行します。
DB_RECOVERY_FILE_DEST初期化パラメータを変更します。たとえば、次のコマンドを入力し、移動先をASMディスク・グループdisk1に設定します。
ALTER SYSTEM SET DB_RECOVERY_FILE_DEST='+disk1' SCOPE=BOTH SID='*';
このパラメータを変更すると、すべての新しいフラッシュ・リカバリ領域ファイルが新しい場所に作成されます。
既存のファイルをフラッシュ・リカバリに残した場合、古いフラッシュ・リカバリ領域の一時的なファイルは、削除対象となったときに削除されます。
古いファイルを新しいフラッシュ・リカバリ領域に移動する必要がある場合は、第26章「ASMでのデータの移行の実行」を参照してください。ファイルをフラッシュ・リカバリ領域に移動したり、フラッシュ・リカバリ領域から移動する場合は、Recovery Managerを使用してデータベース・ファイルをASMディスク・グループに移動したり、ASMディスク・グループから移動するときと同じ手順を使用できます。
フラッシュ・リカバリ領域を無効にする前に、すべての保証付きリストア・ポイントを削除してから、フラッシュバック・データベースを無効にする必要があります。これらの前提条件が満たされたら、DB_RECOVERY_FILE_DEST初期化パラメータをNULL文字列に設定することによって、フラッシュ・リカバリ領域を無効にできます。たとえば、次のSQL文を使用して、実行中のデータベースのパラメータを変更します。
ALTER SYSTEM SET DB_RECOVERY_FILE_DEST='' SCOPE=BOTH SID='*';
これで、データベースは以前のDB_RECOVERY_FILE_DESTの位置に格納されているファイルにフラッシュ・リカバリ領域の領域管理機能を提供しなくなります。ただし、これらのファイルは、Recovery Managerリポジトリで認識され、バックアップおよびリストア・アクティビティで使用できます。
通常、フラッシュ・リカバリ領域は自動管理されます。ただし、フラッシュ・リカバリ領域内のファイルの作成中にインスタンスがクラッシュした場合、そのファイルがフラッシュ・リカバリ領域内に残存することがあります。この状況が発生した場合は、アラート・ログに次のエラーが表示されます。ここで、locationは、フラッシュ・リカバリ領域の場所です。
ORA-19816: WARNING: Files may exist in location that are not known to database.
このような場合は、Recovery ManagerコマンドCATALOG RECOVERY AREAを使用して、このようなファイルをカタログに再度追加します。問題のファイルのヘッダーが破損している場合は、オペレーティング・システム・ユーティリティを使用してファイルを手動で削除します。
自動ワークロード・リポジトリ（AWR）では、データベースの問題検出および自己チューニングのためにパフォーマンス統計の収集、処理および保持を行うことによって、データベースの統計収集が自動化されています。システムにおけるフラッシュバック・データベースのワークロードの監視を行う場合、そのデータ分析方法は複数あります。たとえば、フラッシュバック・データベースを有効にする前と後で、AWRレポートを比較できます。また、AWRスナップショットを参照して、フラッシュバック・ロギングによって発生するシステムの使用状況を明確にすることもできます。たとえば、flashback buf free by RVWRが最上位の待機イベントとして表示されている場合は、Oracle Databaseではフラッシュバック・ログへの迅速な書込みを行うことができないことを示しています。このような場合は、「最適なフラッシュバック・データベースのパフォーマンスのための環境の構成」で説明したいずれかの方法で、フラッシュ・リカバリ領域に使用されているファイル・システムおよび記憶域をチューニングすることをお薦めします。
V$FLASHBACK_DATABASE_STATビューには、データベースによって記録されたフラッシュバック・データのバイト数が表示されます。ビューの各行には、（通常は1時間にわたって）累積された統計が表示されます。FLASHBACK_DATAおよびREDO_DATA列には、一定期間中に書き込まれたフラッシュバック・データおよびREDOデータのバイト数がそれぞれ示されます。DB_DATA列には、読取りおよび書込みが行われたデータ・ブロックのバイト数が示されます。FLASHBACK_DATAおよびREDO_DATAは順次書込みに対応し、DB_DATAはランダム読取りおよび書込みに対応することに注意してください。
順次I/OとランダムI/Oの違いのため、I/Oオーバーヘッドは、フラッシュバック・ログに対して発行されたI/O操作の数によってより明確に示されます。表11-1に示すV$SYSSTAT統計は、様々な目的のためにインスタンスによって発行されたI/O操作の数を示しています。
フラッシュバックが有効になっている場合、または保証付きリストア・ポイントが存在する場合は、バックグラウンド・プロセスRVWRによって、フラッシュバック・リカバリ領域内のフラッシュバック・データベース・ログにフラッシュバック・データが書き込まれます。RVWRでI/Oエラーが発生した場合は、次の動作が予測されます。
SHUTDOWN ABORTまたはALTER DATABASE FLASHBACK OFFを発行します。
この項では、Recovery Managerリポジトリが、ディスクおよびテープに格納されているRecovery Manager関連ファイルの実情を正確に反映していることを確認する方法について説明します。リポジトリとリポジトリによって記録されるファイル間の相違は、テープまたはディスクの障害、ユーザー管理のコピー、Recovery Manager関連ファイルの削除などのいくつかの原因によって発生する可能性があります。
この項の内容は、次のとおりです。
リカバリ・カタログまたは制御ファイルのバックアップに関するデータがディスクまたはメディア管理カタログの該当するデータと同期されていることを確認するには、クロスチェックを実行します。CROSSCHECKコマンドでは、Recovery Managerリポジトリに現在記録されているファイルのみが処理されます。
フラッシュ・リカバリ領域、バックアップの保存方針およびアーカイブREDOログの削除方針を使用する場合は、クロスチェックを頻繁に実行する必要はありません。Recovery Manager以外の方法でファイルを削除する場合は、クロスチェックを定期的に実行して、リポジトリ・データが最新の状態で保持されるようにする必要があります。
クロスチェックは、リポジトリ・レコードが物理的な状態と一致しないバックアップに関する、Recovery Managerリポジトリの期限切れの情報を更新します。たとえば、ユーザーがオペレーティング・システム・コマンドを使用してアーカイブ・ログをディスクから削除すると、ログが実際にはディスク上に存在していない場合でも、リポジトリではディスク上に存在しているように示されます。
図11-1に、メディア・マネージャのクロスチェックを示します。Recovery Managerは、Recovery Managerリポジトリに対して、チェックする4つのバックアップ・セットの名前と場所を問い合せます。Recovery Managerは、この情報をターゲット・データベース・サーバーに送信します。ターゲット・データベース・サーバーは、メディア管理ソフトウェアにバックアップについて問い合せます。メディア管理ソフトウェアは、メディア・カタログを確認して、バックアップ・セット3が欠落していることをサーバーにレポートします。Recovery Managerは、リポジトリでバックアップ・セット3のステータスをEXPIREDに更新します。DELETE EXPIREDを実行すると、バックアップ・セット3のレコードは削除されます。
クロスチェックは、次の処理を行うため有効です。
クロスチェック機能を使用すると、ディスクまたはテープ上のバックアップのステータスを確認できます。バックアップがディスク上に存在する場合、CROSSCHECKによって、そのファイルのヘッダーが有効かどうかが確認されます。バックアップがテープ上に存在する場合、このコマンドによって、バックアップがメディア管理ソフトウェアのカタログに存在するかどうかが確認されます。
バックアップ・ピースおよびイメージ・コピーのステータスは、AVAILABLE、EXPIREDまたはUNAVAILABLEとなります。Recovery ManagerのLISTコマンドを実行するか、V$BACKUP_FILES、またはRC_DATAFILE_COPYやRC_ARCHIVED_LOGなどのリカバリ・カタログ・ビューを問い合せると、バックアップのステータスを表示できます。クロスチェックによってRecovery Managerリポジトリが更新されるため、これらのすべての方法で正確な情報が提供されます。Recovery Managerは、Recovery Manager内のバックアップが使用できなくなると、そのバックアップのステータスをEXPIREDに更新します。新しいクロスチェックによって期限切れのバックアップが再度使用可能であると判断された場合、Recovery ManagerはそのステータスをAVAILABLEに更新します。
DELETE EXPIREDコマンドを発行すると、期限切れのすべてのバックアップを削除できます。Recovery Managerは、期限切れのファイルのレコードをリポジトリから削除します。なんらかの理由でファイルがまだメディア上に存在している場合、Recovery Managerは警告を発行して、削除できない不一致のオブジェクトのリストを表示します。
ターゲット・データベースとリカバリ・カタログ（使用している場合）に接続してから、必要に応じてCROSSCHECKコマンドを実行し、Recovery Managerが認識するバックアップの状態と可用性を検証します。
CROSSCHECKまたはDELETEコマンドを発行する前に、複数のチャネルを構成するか、手動で割り当てます。Recovery Managerは、バックアップの作成に使用したチャネルと同じデバイスのタイプを持つすべてのチャネルの各バックアップを検索します。マルチチャネル機能は、1つのコマンドでディスクおよびテープの両方のクロスチェックまたはバックアップの削除を実行する場合に主に使用されます。たとえば、SBTチャネルが次のように構成されているとします。
CONFIGURE DEVICE TYPE sbt PARALLELISM 1; CONFIGURE DEFAULT DEVICE TYPE sbt;
この場合は、次のコマンドを実行して、ディスクおよびSBTの両方をクロスチェックできます。
CROSSCHECK BACKUP; CROSSCHECK COPY;
Recovery Managerは、SBTチャネルおよび事前構成済のディスク・チャネルの両方を使用してクロスチェックを実行します。出力例を次に示します。
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 . . .
自動SBTチャネルを構成していない場合は、次の例に示すように、ディスクおよびテープにメンテナンス・チャネルを手動で割り当てることもできます。
RUN { ALLOCATE CHANNEL FOR MAINTENANCE DEVICE TYPE sbt; CROSSCHECK BACKUP; CROSSCHECK COPY; }
Recovery Managerは事前構成済のディスク・チャネルを使用するため、ディスク・チャネルを手動で割り当てる必要はありません。
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 BACKUP OF ARCHIVELOG ALL SPFILE; CROSSCHECK BACKUP OF DATAFILE "?/oradata/trgt/system01.dbf" COMPLETED AFTER 'SYSDATE-14'; CROSSCHECK CONTROLFILECOPY '/tmp/control01.ctl'; CROSSCHECK DATAFILECOPY 113, 114, 115; CROSSCHECK PROXY 789;
この項では、バックアップおよびコピーのリポジトリ・レコードの変更方法について説明します。バックアップが一時的に使用可能または使用不可になった場合、バックアップ・ステータスを変更する必要があることがあります。たとえば、マウントされているディスクのメンテナンスを行う場合は、ディスク上のバックアップのレコードのステータスをUNAVAILABLEに更新できます。
バックアップが検出されない場合、またはサイト外に移された場合は、CHANGE ... UNAVAILABLEコマンドを実行します。Recovery Managerは、ステータスがUNAVAILABLEのファイルはRESTOREまたはRECOVERコマンドでは使用しません。ファイルが後で検出された場合またはメイン・サイトに戻された場合は、CHANGE ... AVAILABLEを発行してステータスを再度更新できます。フラッシュ・リカバリ領域内のファイルをUNAVAILABLEにマークすることはできません。
LISTコマンドを発行して、Recovery Managerバックアップの可用性の状態を確認します。たとえば、次のコマンドを発行してすべてのバックアップを表示します。
LIST BACKUP;
UNAVAILABLEまたはAVAILABLEキーワードを指定してCHANGEを実行し、Recovery Managerリポジトリの状態を更新します。次の例は、CHANGEコマンドの形式を示しています。
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;
「長期格納用のデータベース・バックアップの作成」で説明されているように、保存方針から除外するバックアップを指定できます。この方法は、ビジネス要件に準拠するためにバックアップをアーカイブする場合に有効です。ただし、アーカイブ・バックアップは完全に有効なバックアップであり、他のRecovery Managerバックアップと同様にリストアできます。
CHANGEコマンドを使用すると、既存のバックアップのKEEPステータスを変更できます。たとえば、長期バックアップを保持しないようにすることができます。BACKUP ... KEEPで使用できるオプションをCHANGE ... KEEPでも使用できます。
フラッシュ・リカバリ領域に格納されているバックアップ・セットまたはファイルにはKEEP属性を設定できないことに注意してください。
LISTコマンドを発行してバックアップを表示します。たとえば、次のコマンドを発行してすべてのバックアップを表示します。
LIST BACKUP;
CHANGE ...KEEPを発行してこのバックアップに別の保存期間を定義するか、またはCHANGE ...NOKEEPを発行して保存方針をこのファイルに適用します。次の例では、バックアップ・セットがバックアップの保存方針に従うことができます。
CHANGE BACKUPSET 231 NOKEEP;
次の例では、データファイルのコピーを保存方針から180日間除外するようにマークします。
CHANGE DATAFILECOPY '/tmp/system01.dbf' KEEP UNTIL 'SYSDATE+180';
CATALOGコマンドを使用すると、リポジトリに記録されていないアーカイブ・ログ、またはRecovery Manager以外の方法を使用して作成されたデータベース・ファイルのコピーの存在をRecovery Managerに認識させることができます。この項の内容は、次のとおりです。
ターゲット・データベースの制御ファイルには、ターゲット・データベースによって生成されたすべてのアーカイブREDOログおよびすべての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*PlusコマンドHOSTを使用して、オンラインのデータファイルをバックアップします。
SQL> ALTER TABLESPACE users BEGIN BACKUP; SQL> host cp $ORACLE_HOME/oradata/trgt/users01.dbf /tmp/users01.dbf; SQL> ALTER TABLESPACE users END BACKUP;
CATALOGコマンドを実行します。たとえば、ユーザー管理のデータファイル・コピーをカタログに追加するには、次のコマンドを実行します。
CATALOG DATAFILECOPY '/tmp/users01.dbf';
接続したターゲット・データベース以外のデータベースからデータファイル・コピーをカタログに追加しようとすると、Recovery Managerは次のようなエラーを発行します。
RMAN-00571: =========================================================== RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS =============== RMAN-00571: =========================================================== RMAN-03009: failure of catalog command on default channel at 08/29/2007 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';
LISTコマンドを実行するか、またはV$ビューを問い合せて変更を確認します。ビューには、V$BACKUP_PIECE、V$BACKUP_SET、V$BACKUP_DATAFILE、V$BACKUP_REDOLOGおよびV$BACKUP_SPFILEがあります。次の問合せは、バックアップ・ピース名を示しています。
SELECT HANDLE FROM V$BACKUP_PIECE;
自動ストレージ管理（ASM）、Oracle Managed Filesフレームワークまたはフラッシュ・リカバリ領域を使用する場合は、ディスク管理システムによって認識されており、Recovery Managerのリポジトリには表示されていないファイルをカタログに再度追加する必要があることがあります。この状況は、メディア障害、ソフトウェアの不具合またはユーザー・エラーが原因でファイル名を追跡するメカニズムで障害が発生した場合に発生する可能性があります。
CATALOG START WITHコマンドを使用すると、ASMディスク・グループ、Oracle Managed Filesまたは従来のファイル・システム・ディレクトリにあるすべてのファイルを検索して、Recovery Managerリポジトリに記録されていないファイルを調べることができます。このコマンドによってファイルをカタログに追加できる場合は、ファイルがカタログに追加されます。追加できない場合は、スキップされたファイルの内容が可能なかぎり推測されます。
CATALOG RECOVERY AREAコマンドを使用すると、リカバリ領域内のすべてのファイルをカタログに追加できます。通常、このコマンドを手動で実行する必要はありません。このコマンドは、制御ファイルをリストアまたは作成する場合などに必要に応じてRecovery Managerが自動的に実行するためです。このコマンドは、オペレーティング・システム・ユーティリティを使用してファイルをフラッシュ・リカバリ領域にコピーする場合に実行できます。
CATALOGコマンドを実行します。たとえば、次のコマンドを入力します。
CATALOG START WITH '+disk'; # catalog all files from an ASM disk group CATALOG START WITH '/fs1/datafiles/'; # catalog all files in directory
CATALOG RECOVERY AREAコマンドを使用すると、リカバリ領域内のすべてのファイルをカタログに追加できます。この操作で、Recovery Managerリポジトリに表示されていないリカバリ領域内のすべてのファイルが追加されます。たとえば、次のように入力します。
CATALOG RECOVERY AREA;
LISTコマンドを実行し、ファイルがカタログに追加されていることを確認します。
この項では、ファイルのレコードをRecovery Managerのリポジトリから削除する方法について説明します。
CHANGE ... UNCATALOGコマンドを実行すると、Recovery Managerリポジトリのレコードに次の処理を実行します。
Recovery Managerは、指定した物理ファイルは変更しません。これらのファイルのリポジトリ・レコードのみを変更します。
このコマンドは、Recovery Manager以外の方法を使用してバックアップを削除した場合に使用できます。たとえば、オペレーティング・システムのユーティリティを使用してアーカイブREDOログを削除した場合、CHANGE ARCHIVELOG ... UNCATALOGを発行することによってリポジトリからこのログのレコードを削除します。
ユーザーがオペレーティング・システム・ユーティリティを使用してバックアップまたはアーカイブREDOログを削除している場合もあります。CROSSCHECKを実行しないかぎり、この削除はRecovery Managerでは認識されません。CHANGE ... UNCATALOGコマンドを使用すると、存在しないファイルを反映してRecovery Managerリポジトリを更新できます。
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.
Recovery ManagerのDELETEコマンドを使用すると、アーカイブREDOログおよびRecovery Managerバックアップを削除できます。ディスク上のバックアップの場合、バックアップを削除すると、バックアップ・ファィルがディスクから物理的に削除されます。SBTデバイス上のバックアップの場合、Recovery ManagerのDELETEコマンドを使用すると、テープ上のバックアップ・ピースまたはプロキシ・コピーを削除するようにメディア・マネージャに指示が行われます。いずれの場合も、削除を反映してRecovery Managerのリポジトリが更新されます。
Recovery Managerの各バックアップによって、対応するレコードがRecovery Managerリポジトリに作成されます。このレコードは、制御ファイルに格納されます。リカバリ・カタログを使用する場合、リカバリ・カタログを制御ファイルと再同期化すると、レコードはリカバリ・カタログにも格納されます。たとえば、完全なデータベース・バックアップ・セットを生成する場合は、このバックアップ・セットのレコードをV$BACKUP_SETに表示できます。リカバリ・カタログを使用している場合は、RC_BACKUP_SETカタログ・ビューでレコードにアクセスすることもできます。
V$制御ファイル・ビューとリカバリ・カタログ表では、情報を格納する方法が異なります。この違いが、Recovery Managerによるリポジトリ・レコードの処理方法に影響します。リカバリ・カタログのRecovery Managerリポジトリは、実際のデータベース表に格納されますが、制御ファイルのRecovery Managerリポジトリは、制御ファイルの内部構造に格納されます。
Recovery Managerコマンドを使用してバックアップまたはアーカイブREDOログ・ファイルを削除する場合、Recovery Managerは次の処理を実行します。
DELETEDに更新します。
制御ファイルのデータは内部構造に格納されているため、Recovery Managerは、制御ファイルからレコードを削除できず、レコードのステータスをDELETEDに更新するのみです。ただし、カタログ表は通常のデータベース表であるため、表から行が削除される場合と同様に、カタログ表から行が削除されます。
表11-2に、バックアップを削除するRecovery Managerコマンドの機能を示します。
オブジェクトのRecovery Managerリポジトリ・レコードが、そのオブジェクトの物理ステータスを反映していない場合があります。たとえば、ディスクにアーカイブREDOログをバックアップした後で、オペレーティング・システム・ユーティリティを使用してそのオブジェクトを削除したとします。最初にCROSSCHECKを実行せずにDELETEを実行すると、リポジトリにログがAVAILABLEと誤って表示されます。Recovery Managerリポジトリと物理メディアの間で不一致が発生した場合のDELETEの動作の詳細は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。
Recovery Managerを対話形式で実行すると、ファイルを削除する前に確認を求められます。DELETEコマンドのいずれの形式でも、NOPROMPTキーワードを使用することによって、これらの確認をしないようにできます。
DELETE NOPROMPT ARCHIVELOG ALL;
「バックアップおよびリポジトリのメンテナンスの基本的な概念」で説明されているように、メンテナンス計画では、フラッシュ・リカバリ領域、バックアップの保存方針およびアーカイブREDOログの削除方針を構成することをお薦めします。デフォルトでは、削除方針はNONEに構成されています。つまり、ログは、ディスクまたはテープに1回以上バックアップされた場合、またはバックアップ保存方針に従って不要になった場合に削除対象となります。
表11-2に示されているように、アーカイブREDOログは、データベースによって自動的に削除されるか、またはユーザーが実行したRecovery Managerコマンドによって削除されます。リカバリ領域内のログは、データベースによってできるかぎり保存され、ディスク領域が必要になると対象となるログが削除されます。対象となるログは、BACKUP ... DELETE INPUTまたはDELETE ARCHIVELOGを使用して、リカバリ領域の内部または外部のすべての場所から削除できます。FORCEが指定されていない場合、これらのコマンドはアーカイブ・ログの削除方針に従います。FORCEが指定されている場合、これらのコマンドはアーカイブ・ログの削除方針を無視します。
|
参照:
|
状況によっては、データベースに関連付けられているすべてのバックアップ・セット、プロキシ・コピーおよびイメージ・コピーを削除する必要がある場合があります。たとえば、データベースが不要になったため、関連するすべてのファイルをシステムから削除する場合などです。イメージ・コピーは、BACKUP AS COPYで生成されるファイル、データベースによってアーカイブされるログまたはCATALOGコマンドでカタログに追加されるファイルであることに注意してください。
表11-2に示されているように、Recovery Managerは、構成されているすべてのチャネルを使用して削除を実行します。チャネルがすでに構成されている場合、メンテナンス・チャネルを手動で割り当てる必要はありません。
CROSSCHECK BACKUP; CROSSCHECK COPY;
たとえば、次のコマンドを入力し、プロンプトが表示されたらYESと入力します。
DELETE BACKUP; DELETE COPY;
ディスクおよびテープのチャネルが構成されている場合、Recovery Managerは、構成されているSBTチャネルおよび事前構成されているディスク・チャネルの両方を削除時に使用します。Recovery Managerは、ファイルを削除する前に確認を求めるプロンプトを表示します。
DELETEおよびBACKUP ... DELETEコマンドのいずれを使用しても、特定のバックアップおよびコピーを削除できます。BACKUP ... DELETEコマンドを実行すると、ファイルはまず通常はテープにバックアップされ、その後入力ファイルが削除されます。
DELETEコマンドでは、削除するオブジェクトを識別するための様々なオプションがサポートされています。これらのオプションの詳細は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。Recovery Managerは、アーカイブREDOログを削除する場合、構成済の設定を使用して、ログを削除できるかどうかを判断します（「アーカイブREDOログの削除方針の構成」を参照）。
表11-2に示されているように、Recovery Managerは、構成されているすべてのチャネルを使用して削除を実行します。チャネルがすでに構成されている場合、メンテナンス・チャネルを手動で割り当てる必要はありません。
次の例は、DELETEコマンドを使用して削除するバックアップおよびアーカイブ・ログを指定する一般的な方法を示しています。
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 ARCHIVELOG ALL BACKED UP 3 TIMES TO sbt;
BACKUP ... DELETEを使用すると、アーカイブREDOログ、データファイルのコピー、またはバックアップ・セットをバックアップし、バックアップに成功した後で入力ファイルを削除できます。DELETE INPUTオプションを指定すると、入力ファイルに対してDELETEコマンドを発行した場合と同じ処理が実行されます。「アーカイブREDOログの削除方針の構成」で説明されているように、Recovery Managerは、アーカイブREDOログを削除する場合、構成済の設定を使用して、ログを削除できるかどうかを判断します。DELETE ALL INPUT句のALLオプションは、アーカイブREDOログにのみ適用されます。BACKUP ... DELETE ALL INPUTを実行すると、BACKUPコマンドの選択基準を満たすアーカイブREDOログまたはデータファイルのすべてのコピーが削除されます。
CROSSCHECKを実行し、Recovery Managerがファイルの場所を特定できない場合、Recovery ManagerリポジトリのレコードはEXPIREDステータスに更新されます。その後、DELETE EXPIREDコマンドを使用して、Recovery Managerリポジトリから期限切れのバックアップおよびコピーのレコードを削除できます。
EXPIREDとマークされたファイルが実際に存在する場合は、DELETE EXPIREDコマンドによって警告が発行されます。まれに、ファイルが存在する場合でも、リポジトリによってファイルがEXPIREDとマークされる場合があります。たとえば、ファイルが含まれているディレクトリがクロスチェック中に破損し、その後、修復された場合や、メディア・マネージャが適切に構成されておらず、実際には存在するバックアップが存在しないとレポートされる場合などです。
CROSSCHECKコマンドを発行します。たとえば、次のように入力します。
CROSSCHECK BACKUP;
DELETE EXPIRED BACKUP;
Recovery ManagerのDELETEコマンドでは、OBSOLETEオプションがサポートされています。このオプションによって、指定されているリカバリ可能性の要件を満たす必要がなくなったバックアップが削除されます。構成済のデフォルトの保存方針、またはDELETE OBSOLETEコマンドにオプションとして指定した他の保存方針に従って、不要とされるファイルを削除できます。DELETEコマンドの他の形式と同様に、削除されたファイルはバックアップ・メディアおよびリカバリ・カタログから削除され、制御ファイル内でDELETEDとしてマーク付けされます。
引数を使用せずにDELETE OBSOLETEコマンドを指定すると、Recovery Managerは、構成されている保存方針で定義されているすべての不要なバックアップを削除します。たとえば、次のように入力します。
DELETE OBSOLETE;
アーカイブ・バックアップに対してKEEP UNTIL TIMEに指定した期限が切れていないかぎり、バックアップは不要とはみなされません。ただし、KEEP UNTILに指定した期限が切れるとすぐに、構成されているバックアップの保存方針に関係なく、バックアップはすぐにOBSOLETEとみなされます。このため、KEEPに指定した期限が切れた場合、DELETE OBSOLETEを使用すると、BACKUP ... KEEP UNTIL TIMEで作成されたすべてのバックアップが削除されます。
データベースをオペレーティング・システムから削除する必要がある場合があります。このような場合は、Recovery ManagerでDROP DATABASEコマンドを使用できます。Recovery Managerは、ターゲット・データベースに属しているすべてのデータファイル、オンラインREDOログおよび制御ファイルを削除します。
DROP DATABASEでは、マウントされたターゲット・データベースにRecovery Managerが接続されている必要があります。リカバリ・カタログに接続している必要はありません。Recovery Managerをリカバリ・カタログに接続した状態でオプションINCLUDE COPIES AND BACKUPSを指定すると、Recovery Managerはデータベースも登録解除します。
CATALOG START WITH '+disk1'; # all files from recovery area on ASM disk CATALOG START WITH '/arch_dest2'; # all files from second archiving location
DELETE BACKUPSET; # deletes all backups DELETE COPY; # delete all image copies (including archived logs)
次のコマンドを実行すると、データベースが削除され、リカバリ・カタログ（使用している場合）から自動的に登録解除されます。Recovery Managerによって構成を求められます。
DROP DATABASE;
|
参照:
|
|
 Copyright © 2003, 2008, Oracle Corporation. All Rights Reserved. |
|