日本語PDF

12 RMANバックアップおよびリポジトリ・レコードのメンテナンス

この章では、RMANのリポジトリ・レコードおよびRMANのバックアップとコピーの管理方法について説明します。また、高速リカバリ領域に関連するメンテナンス・タスクについても説明します。この章のトピックは、次のとおりです:

関連項目:

リカバリ・カタログに固有のRMANのメンテナンスの問題は、「リカバリ・カタログの管理」を参照してください。

12.1 RMANバックアップおよびリポジトリのメンテナンスの概要

この項では、RMANリポジトリのメンテナンスの目的および基本的な概念について説明します。

12.1.1 バックアップおよびリポジトリのメンテナンスの目的

メンテナンス計画では、高速リカバリ領域、バックアップの保存方針およびアーカイブREDOログの削除方針を構成することをお薦めします。

この場合、バックアップおよびアーカイブREDOログは、必要に応じてデータベースによって自動的にメンテナンスおよび削除されます。ただし、データベース・バックアップおよびアーカイブREDOログを手動でメンテナンスする必要がある場合もあります。

RMANバックアップを管理する場合は、次の関連タスクを実行します。

  • ディスクまたはテープに格納されているデータベース・バックアップの管理

  • RMANリポジトリ内のバックアップのレコードの管理

RMANのメンテナンスでの重要なタスクに、不要となったバックアップの削除があります。高速リカバリ領域を構成すると、この領域内の不要なファイルはデータベースによって自動的に削除されます。その場合も、テープからバックアップおよびコピーを削除する場合があります。データベース全体を削除する必要がある場合もあります。RMANコマンドを使用すると、これらのタスクを実行できます。

高速リカバリ領域には、不定期のメンテナンスが必要な場合があります。たとえば、高速リカバリ領域が一杯になった場合、領域を追加できます。また、リカバリ領域の場所を変更する必要がある場合もあります。

ディスクおよびテープ上のファイルの実際の状態がRMANリポジトリに反映されない場合があります。たとえば、ユーザーがオペレーティング・システムのユーティリティを使用して、バックアップをディスクから削除する場合があります。この場合、RMANリポジトリには、実際には存在しないファイルが存在しているように表示されます。RMANバックアップが格納されているテープが破損した場合も、同様の状況が発生します。RMANメンテナンス・コマンドを使用すると、リポジトリを正しい情報で更新できます。

12.1.2 バックアップおよびリポジトリのメンテナンスの基本的な概念

RMANには、RMANバックアップおよびリポジトリ・レコードのメンテナンスのために複数のコマンドが用意されています。

RMANのメンテナンス・コマンドを次に示します。

  • CATALOGコマンドを使用すると、RMANリポジトリに現在記録されていないRMANバックアップおよびユーザー管理のバックアップに関するレコードを追加したり、記録されているバックアップのレコードを削除できます。

  • CHANGEコマンドを使用すると、RMANリポジトリのレコードのステータスを更新できます。

  • CROSSCHECKコマンドを使用すると、論理バックアップ・レコードをバックアップ・ストレージ内のファイルの物理的な状態と同期化できます。

  • DELETEコマンドを使用すると、オペレーティング・システムからバックアップを削除できます。

12.1.2.1 メンテナンス・コマンドおよびRMANリポジトリ・メタデータについて

RMANは、操作の実行対象となる各ターゲット・データベースの制御ファイルに、そのメタデータを常に格納します。ターゲット・データベースをリカバリ・カタログに登録すると、RMANは、このターゲット・データベースのメタデータをリカバリ・カタログに格納します。

RMANのすべてのメンテナンス・コマンドは、リカバリ・カタログを使用しているかどうかに関係なく動作します。

12.1.2.2 Data Guard環境でのメンテナンス・コマンドについて

Data Guard環境では、バックアップまたはコピーを作成するデータベースはファイルに関連付けられています。たとえば、RMANがターゲット・データベースstandby1に接続し、このデータベースをバックアップする場合、このバックアップはstandby1に関連付けられます。

「Data Guard環境でのRMANによるファイル管理について」で指定されている基準に従ってRMANからバックアップにアクセスできる場合、プライマリ・データベースまたはスタンバイ・データベースへの接続時に、バックアップに対してCHANGEDELETECROSSCHECKなどのRMANメンテナンス・コマンドを使用できます。

12.1.2.2.1 Data Guard環境でのクロスチェックについて

クロスチェックする場合、RMANは、ファイルに関連付けられているデータベースへの接続時にのみ、ファイルのステータスをAVAILABLEからEXPIREDに更新できます。

このため、RMANでクロスチェックしてもファイルが検出されず、RMANがTARGETとして接続されていないデータベースにファイルが関連付けられている場合は、そのファイルに関連付けられているターゲット・データベースへの接続時に、RMANによってクロスチェックの実行が求められます。RMANは、CROSSCHECKまたはCHANGE ... AVAILABLEコマンドの実行時にクロスチェックを行います。

12.1.2.2.2 Data Guard環境での削除について

RMANは、データベースへの接続時にファイルを削除できます。ファイルに関連付けられているデータベースにRMANがTARGETとして接続されておらず、RMANでファイルを正常に削除できない場合は、RMANによって、ファイルに関連付けられているデータベースにTARGETとして接続するように求められます。このため、ファイルのメタデータを削除するには、DELETE ... FORCEを使用する必要があります。

12.1.2.2.3 Data Guard環境でのRMANメタデータへの更新について

メンテナンス・コマンドでRMANのメタデータのみを変更した場合は、RMANをTARGETとしてData Guard環境のデータベースに接続できます。

メタデータのみを変更するコマンドは、次のとおりです。

  • CHANGE ... UNAVAILABLEまたはCHANGE ... UNCATALOG

  • CHANGE ... KEEPまたはCHANGE ... NOKEEP

  • CHANGE ... RESET DB_UNIQUE_NAME

デフォルトでは、CHANGEコマンドを使用すると、「Data Guard環境でのバックアップのアクセシビリティについて」で指定されている規則に従ってアクセス可能なファイルに対してのみ操作が行われます。ただし、FOR DB_UNIQUE_NAMEオプションを使用すると、ターゲット・データベース以外のデータベースに関連付けられているファイルのステータスを変更できます。

12.1.2.2.4 データベースに関連付けられていないファイルについて

CHANGE ... RESET DB_UNIQUE_NAMEを明示的に使用して別のデータベースに関連付けないかぎり、バックアップはそのデータベースに関連付けられたままです。

特定のファイルでDB_UNIQUE_NAMEが認識されない場合があります。たとえば、データベース名がカタログで認識されない場合は、リカバリ・カタログに登録されているOracle9iデータベースの場合と同様に、DB_UNIQUE_NAMEの値はnullになります。また、データベースを現行のバージョンにアップグレードしたにもかかわらず、リカバリ・カタログ・スキーマとすべてのファイルのDB_UNIQUE_NAME値が一致していないため、行のDB_UNIQUE_NAMEnullになる場合もあります。デフォルトでは、SITE_KEYnullのファイルは、RMANがTARGETとして接続されているデータベースに関連付けられます。

12.2 制御ファイルのリポジトリのメンテナンス

RMANは、リカバリ・カタログを使用しなくても動作するように設計されています。ただし、リカバリ・カタログを使用しないことを選択すると、各ターゲット・データベースの制御ファイルは、RMANメタデータ用の排他的なリポジトリになります。

制御ファイルへの情報の格納方法を理解し、バックアップおよびリカバリ計画によって制御ファイルが保護されるようにする必要があります。

12.2.1 制御ファイル・レコード

制御ファイルには、循環再利用レコードおよび非循環再利用レコードの2つのタイプのレコードが含まれています。

循環再利用レコードには、必要に応じて上書き可能な、重要度が低い情報が含まれます。これらのレコードには、データベースによって持続的に生成される情報が含まれます。使用可能なレコード・スロットがすべて使用されると、データベースは、制御ファイルを拡張して新規レコード用の領域を作成するか、または最も古いレコードを上書きします。CONTROL_FILE_RECORD_KEEP_TIME初期化パラメータには、レコードを再利用するまでの最小経過時間を日数で指定します。

非循環再利用レコードには、頻繁には変更されず、上書きできない重要な情報が含まれます。非循環再利用レコードに含まれる情報は、データファイル、オンラインREDOログ・ファイル、REDOスレッドなどです。

ターゲット・データベースのバックアップを作成すると、データベースによってそれらのバックアップが制御ファイルに記録されます。新しいレコードを追加したことによって制御ファイルが過度に大きくならないように、指定したしきい値より古いレコードは再利用可能になります。CONTROL_FILE_RECORD_KEEP_TIME初期化パラメータは、レコードが上書き可能になるまでの最小経過時間を日数で決定します。

CONTROL_FILE_RECORD_KEEP_TIME = integer

たとえば、パラメータ値が14の場合、14日以上経過したレコードは再利用の候補となります。上書きされたレコードの情報は失われます。再利用可能な最も古いレコードが最初に使用されます。

ノート:

レコードが上書きされると、メタデータに関連付けられたバックアップ・ピースが孤立し、RMANによって管理されなくなります。

データベースでは、新しいRMANリポジトリ・レコードを制御ファイルに追加する必要があるにもかかわらず、しきい値より古いレコードが存在しない場合、制御ファイル・サイズの拡大が試行されます。基礎となるオペレーティング・システムで(ディスクが一杯などの状況によって)制御ファイルを拡大できない場合は、データベースによって制御ファイル内の最も古いレコードが上書きされます。

上書きは、自動診断リポジトリ内のアラート・ログに記録されます。上書きされる各レコードに対するエントリが、アラート・ログに次のように記録されます。

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
12.2.1.1 高速リカバリ領域および制御ファイル・レコードについて

高速リカバリ領域に作成されたファイルに関する情報を含む制御ファイルのレコードが再利用される際、そのファイルが削除対象である場合は、データベースによって高速リカバリ領域からのそのファイルの削除が試行されます。削除対象でない場合は、このファイルのレコードを含む制御ファイルのセクションのサイズが拡大されます。

この拡大に関して、アラート・ログに次の例のようなメッセージが記録されます。ここで、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. 

前述のメッセージは、構成されている保存方針を満たすために必要なすべての高速リカバリ領域ファイルのレコードを、制御ファイルで保持できないことを示しています。次の項では、この状況に対応する方法について説明します。

関連トピック

12.2.2 制御ファイル・レコードの消失の防止

制御ファイル・レコードの上書きによってRMANメタデータが消失することを防止するには、リカバリ・カタログを使用する方法が最適です。

リカバリ・カタログを使用できない場合は、次の方法を使用できます。

  • CONTROL_FILE_RECORD_KEEP_TIMEの値を、保持する必要がある最も古いファイルの期間より少し長く設定します。たとえば、データベース全体を1週間に1回バックアップする場合は、すべてのバックアップを7日間以上保持する必要があります。CONTROL_FILE_RECORD_KEEP_TIMEの値を1014などに設定します。CONTROL_FILE_RECORD_KEEP_TIMEのデフォルト値は7日間です。

    注意:

    リカバリ・カタログの使用にかかわらず、CONTROL_FILE_RECORD_KEEP_TIMEが0に設定されている場合はRMANを使用しないでください。そうすると、バックアップ・レコードが失われる場合があります。

  • 制御ファイルは、拡大できるようにRAWデバイスではなくファイル・システムに格納します。

  • アラート・ログを監視して、Oracle Databaseによって制御ファイル・レコードが上書きされないようにします。アラート・ログは、自動診断リポジトリ(ADR).内にあります

高速リカバリ領域を使用する場合は、次のガイドラインに従って、バックアップ保存方針を満たすために必要なすべての高速リカバリ領域ファイルのレコードを制御ファイルで保持できなくなるような状況を回避します。

  • 制御ファイルのブロック・サイズが最大に達している場合は、より大きなブロック・サイズ(可能な場合32KB)を使用します。

    これを実現するには、SYSTEM表領域のブロック・サイズを制御ファイルのブロック・サイズ以上に設定し、DB_BLOCK_SIZEの変更後に制御ファイルを再作成する必要があります。高速リカバリ領域内のファイルはカタログに再度追加されますが、テープに格納されているファイルのレコードは失われます。

  • 高速リカバリ領域内のファイルをテープなどの3次ストレージ・デバイスにバックアップして、削除対象にします。

    たとえば、BACKUP RECOVERY AREAを使用すると、高速リカバリ領域内のファイルを明示的にメディア・マネージャにバックアップできます。

  • バックアップの保存方針によってバックアップおよびアーカイブ・ログがビジネス要件より長く保持されている場合は、その保存方針をより短いリカバリ期間またはより低い冗長性のレベルに変更して、高速リカバリ領域内のより多くのファイルを削除対象にすることができます。

12.2.3 制御ファイルの保護

リカバリ・カタログを使用してRMANメタデータを格納していない場合は、各ターゲット・データベースの制御ファイルを保護することがさらに重要となります。

次の計画を使用すると、制御ファイルを保護することができます。

制御ファイルを保護するには:

  1. 多重化またはオペレーティング・システムのミラー化によって、制御ファイルの冗長コピーを作成します。

    これによって、制御ファイルのサブセットが消失した場合に、ユーザーが制御ファイルをバックアップからリストアする必要がなくなります。2つ以上の多重制御ファイルまたはミラー化制御ファイルを別々のディスクで使用することをお薦めします。

  2. 制御ファイルの自動バックアップ機能を構成します。

    この場合、特定のRMANコマンドを実行すると、制御ファイルが自動的にバックアップされます。制御ファイルの自動バックアップを使用できる場合、RMANは、サーバー・パラメータ・ファイルおよびバックアップ制御ファイルをリストアしてデータベースをマウントできます。制御ファイルをマウントした後、データベースの残りの部分をリストアできます。

  3. データベースのDBIDのレコードを保持します。

    制御ファイルが消失した場合は、DBIDを使用してデータベースをリカバリできます。

12.3 高速リカバリ領域のメンテナンス

高速リカバリ領域は多くの場合自動管理されますが、データベース管理の介入が必要になることもあります。

12.3.1 高速リカバリ領域の規則の削除

RMANでは特定の規則を使用して、高速リカバリ領域からファイルを削除できるタイミングを決定します。

次の規則によって、ファイルがリカバリ領域からの削除対象となるタイミングが制御されます。

  • 永続的なファイルは削除の対象となりません。

  • 保存方針に従って不要になったファイルは削除対象となります。

  • テープにコピーされた一時ファイルは削除対象となります。

  • アーカイブREDOログは、ログのすべてのコンシューマが要件を満たすまで削除対象となりません。

    ログのコンシューマには、RMAN、スタンバイ・データベース、フラッシュバック・データベース機能などがあります。

  • ロジカル・スタンバイ・データベースでLogMinerセッションによってマイニングされた外部のアーカイブ・ログは削除対象になります。外部のアーカイブREDOログは現在のデータベースとは異なるデータベースから生成されるため、そのDBIDは現在のアーカイブREDOログのDBIDとは異なっています。

高速リカバリ領域からのファイルの削除を制御する安全で確実な方法は、保存方針およびアーカイブ・ログの削除方針を構成する方法です。テープに移動したファイルがディスクに保存される可能性を高くするには、高速リカバリ領域の割当て制限を大きくします。

12.3.2 高速リカバリ領域の領域使用状況の監視

V$RECOVERY_FILE_DESTビューおよびV$RECOVERY_AREA_USAGEビューを使用すると、高速リカバリ領域に十分な領域が割り当てられているかどうかを確認できます。

V$RECOVERY_FILE_DESTビューを問い合せて、高速リカバリ領域の現在の位置、ディスク割当て制限、使用領域、ファイル削除による再利用可能な領域、およびファイルの合計数を確認します。領域に関する列はバイト単位で示されます。異なるタイプのファイルで使用されている合計ディスク割当て制限の割合を確認するには、V$RECOVERY_AREA_USAGEビューを問い合せます。また、不要なファイル、冗長なファイルまたはテープにバックアップされているファイルを削除することによって、各タイプのファイル用に再利用できる領域の量を判断することもできます。

保証付きリストア・ポイントがデータベースに定義されている場合は、保証を満たすために必要なファイル用に高速リカバリ領域で使用される領域の量を監視する必要があります。保証付きリストア・ポイントを表示する問合せ(V$RESTORE_POINTビューを使用したリストア・ポイントの表示を参照)を使用し、STORAGE_SIZE列を参照して、各保証付きリストア・ポイントに関連するファイルに必要な領域を決定します。

例12-1 高速リカバリ領域の領域消費量

次の例は、場所、ディスク割当て制限、領域使用状況、ファイル数など、高速リカバリ領域に関する詳細を表示します。

SELECT * FROM V$RECOVERY_FILE_DEST;

NAME          SPACE_LIMIT SPACE_USED SPACE_RECLAIMABLE NUMBER_OF_FILES  CON_ID
------------  ----------- ---------- ----------------- ---------------  ------
/mydisk/rcva   5368709120 109240320             256000              28       0

例12-2 ファイルのタイプに基づいた高速リカバリ領域の領域使用状況

次の例は、ファイルのタイプごとに、使用領域の割合、再利用可能な領域の割合、および高速リカバリ領域内のファイル数を表示します。

SELECT * FROM V$RECOVERY_AREA_USAGE;

FILE_TYPE    PERCENT_SPACE_USED PERCENT_SPACE_RECLAIMABLE NUMBER_OF_FILES  CON_ID
------------ ------------------ ------------------------- ---------------  ------
CONTROLFILE                   0                         0               0       0
ONLINELOG                     2                         0              22       0
ARCHIVELOG                 4.05                      2.01              31       0
BACKUPPIECE                3.94                      3.86               8       0
IMAGECOPY                 15.64                     10.43              66       0
FLASHBACKLOG                .08                         0               1       0

12.3.3 高速リカバリ領域でのフラッシュバック・ログの領域の管理

高速リカバリ領域のフラッシュバック・ログは、フラッシュバック保存目標を設定するか、または保証付きリストア・ポイントを使用する以外に直接管理することはできません。

ただし、フラッシュバック・ログの保存に使用できる領域を最大化するために、高速リカバリ領域を全体として管理することはできます。これによって、フラッシュバック目標を達成する可能性が高くなります。

フラッシュバック・ログ用の領域を確保するには、BACKUP RECOVERY AREABACKUP BACKUPSETなどのコマンドを使用して、高速リカバリ領域の他の内容をテープにバックアップします。Oracle Databaseでは、不要になったファイルが高速リカバリ領域から自動的に削除されます。バックアップをテープにオフロードしても、バックアップ保存方針およびフラッシュバック保存目標を満たす十分な領域が作成されない場合は、高速リカバリ領域により多くの領域を割り当てます。

Oracle Databaseリリース19c以降では、高速リカバリ領域内の領域の管理が簡略化されています。Oracle Databaseは、高速リカバリ領域内のフラッシュバック・ログを監視し、保存期間を超えるフラッシュバック・ログを自動的に削除します。保存目標が削減されると、保存期間を超えるフラッシュバック・ログが即座に削除されます。

フラッシュバック・ログが自動的に削除されるようにするには、COMPATIBLE初期化パラメータを19.0.0以上に設定する必要があります。

突然のワークロードの急増によって大量のフラッシュバック・ログが作成される場合、ワークロードが数日間監視されてから、保存期間を超えるフラッシュバック・ログが削除されます。これにより、別のピーク・ワークロードが直後に発生した場合に、フラッシュバック・ログの再作成のオーバーヘッドを回避できます。

ノート:

フラッシュバック・ログはバックアップできません。このため、高速リカバリ領域の内容をテープにバックアップする場合、BACKUP RECOVERY AREA操作を使用してもフラッシュバック・ログは含まれません。

12.3.4 高速リカバリ領域が一杯になった場合の対応

RMANの保存方針によって高速リカバリ領域のディスク割当て制限より大きいバックアップのセットを保存する必要がある場合、またはこの保存方針がNONEに設定されている場合、高速リカバリ領域は再利用可能な領域がなくなるまで完全に一杯になることがあります。

再利用可能な領域が15%未満になると警告アラートが発行され、再利用可能な領域が3%未満になるとクリティカル・アラートが発行されます。この状況をDBAに警告するために、アラート・ログおよびDBA_OUTSTANDING_ALERTS表(Enterprise Managerで使用)にエントリが追加されます。ただし、高速リカバリ領域内の領域は、再利用可能な領域がなくなるまでデータベースによって継続して消費されます。

リカバリ領域が完全に一杯になると、次のエラーが表示されます。ここで、nnnnnは必要なバイト数、mmmmmはディスク割当て制限です。

ORA-19809: limit exceeded for recovery files
ORA-19804: cannot reclaim nnnnn bytes disk space from mmmmm limit

削除対象のファイルがない場合に高速リカバリ領域が一杯になった状態を解消する方法として、次のいくつかの方法があります。

  • 使用可能なディスク領域を追加し、DB_RECOVERY_FILE_DEST_SIZEを増加して、追加した領域を反映させます。

  • 高速リカバリ領域からテープなどの3次ストレージ・デバイスにバックアップを移動します。

    リカバリ領域のすべてのファイルを一度にテープにバックアップする簡単な方法の1つに、BACKUP RECOVERY AREAコマンドがあります。バックアップをリカバリ領域からテープに転送した後、高速リカバリ領域からファイルを削除できます。フラッシュバック・ログは、リカバリ領域外にはバックアップできないため、BACKUP RECOVERY AREAではバックアップされません。

  • オペレーティング・システム・ユーティリティを使用して削除されたファイルに対しては、DELETEを実行します。

    ホスト・オペレーティング・システムのコマンドを使用してファイルを削除した場合、その結果できる空き領域はデータベースでは認識されません。RMANのCROSSCHECKコマンドを実行して、高速リカバリ領域の内容を再確認し、期限切れのファイルを特定した後、DELETE EXPIREDコマンドを使用して、RMANリポジトリからすべての期限切れのバックアップを削除することができます。

  • 保証付きリストア・ポイントが必要であることを確認します。必要ない場合はそれらを削除します。

    保証付きリストア・ポイントで必要ないフラッシュバック・ログは、高速リカバリ領域内の他のファイルの領域を確保するために自動的に削除されます。保証付きリストア・ポイントを使用すると、リストア・ポイントSCNまでフラッシュバック・データベースを実行するために必要なフラッシュバック・ログを強制的に保存できます。

  • バックアップ保存方針を確認します。Data Guardを使用している場合は、アーカイブREDOログの削除方針も確認します。

12.3.5 新しい場所への高速リカバリ領域の変更

ALTER SYSTEMコマンドを使用して、高速リカバリ領域の場所を変更します。

データベースの高速リカバリ領域を新しい場所に移動する必要がある場合は、次の手順を実行します。

  1. ターゲット・データベースでSQL*Plusを起動し、DB_RECOVERY_FILE_DEST初期化パラメータを変更します。たとえば、次のコマンドを入力し、移動先をASMディスク・グループdisk1に設定します。
    ALTER SYSTEM SET DB_RECOVERY_FILE_DEST='+disk1' SCOPE=BOTH SID='*';
    

    このパラメータを変更すると、すべての新しい高速リカバリ領域ファイルが新しい場所に作成されます。

  2. 古いフラッシュ・リカバリの場所にある永続的なファイル、フラッシュバック・ログおよび一時的なファイルをそのままにするか、または移動します。

    既存のファイルをフラッシュ・リカバリに残した場合、古い高速リカバリ領域の一時的なファイルは、削除対象となったときに削除されます。

    古いファイルを新しい高速リカバリ領域に移動する必要がある場合は、Oracle Automatic Storage Management管理者ガイドを参照してください。ファイルを高速リカバリ領域に移動したり、高速リカバリ領域から移動する場合は、RMANを使用してデータベース・ファイルをASMディスク・グループに移動したり、ASMディスク・グループから移動するときと同じ手順を使用できます。

12.3.6 高速リカバリ領域の無効化

ALTER SYSTEMコマンドを使用して、高速リカバリ領域を無効にすることができます。

高速リカバリ領域を無効にする前に、すべての保証付きリストア・ポイントを削除してから、フラッシュバック・データベースを無効にする必要があります。

次に、DB_RECOVERY_FILE_DEST初期化パラメータをNULL文字列に設定して、高速リカバリ領域を無効にすることができます。たとえば、次のSQL文を使用して、実行中のデータベースのパラメータを変更します。

ALTER SYSTEM SET DB_RECOVERY_FILE_DEST='' SCOPE=BOTH SID='*';

これで、データベースは以前のDB_RECOVERY_FILE_DESTの位置に格納されているファイルに高速リカバリ領域の領域管理機能を提供しなくなります。ただし、これらのファイルは、RMANリポジトリで認識され、バックアップおよびリストア・アクティビティで使用できます。

12.3.7 ファイル作成時のインスタンスのクラッシュへの対応

通常、高速リカバリ領域は自動管理されます。ただし、高速リカバリ領域内のファイルの作成中にインスタンスがクラッシュした場合、そのファイルが高速リカバリ領域内に残存することがあります。

この状況が発生した場合は、アラート・ログに次のエラーが含まれます。ここで、locationは、高速リカバリ領域の場所です。

ORA-19816: WARNING: Files may exist in location that are not known to database.

このような場合は、RMANコマンドCATALOG RECOVERY AREAを使用して、このようなファイルをカタログに再度追加します。問題のファイルのヘッダーが破損している場合は、オペレーティング・システム・ユーティリティを使用してファイルを手動で削除します。

12.4 RMANリポジトリの更新

リポジトリとリポジトリによって記録されるファイル間の相違は、テープまたはディスクの障害、ユーザー管理のコピー、RMAN関連ファイルの削除などのいくつかの原因によって発生する可能性があります。

この項では、RMANリポジトリが、ディスクおよびテープに格納されているRMAN関連ファイルの実情を正確に反映していることを確認する方法について説明します。

12.4.1 RMANリポジトリのクロスチェック

リカバリ・カタログまたは制御ファイルのバックアップに関するデータがディスクまたはメディア管理カタログの該当するデータと同期されていることを確認するには、クロスチェックを実行します。CROSSCHECKコマンドでは、RMANリポジトリに現在記録されているファイルのみが処理されます。

高速リカバリ領域、バックアップの保存方針およびアーカイブREDOログの削除方針を使用する場合は、クロスチェックを頻繁に実行する必要はありません。RMAN以外の方法でファイルを削除する場合は、クロスチェックを定期的に実行して、リポジトリ・データが最新の状態で保持されるようにする必要があります。

12.4.1.1 RMANのクロスチェックについて

クロスチェックは、リポジトリ・レコードが物理的な状態と一致しないバックアップに関する、RMANリポジトリの期限切れの情報を更新します。たとえば、ユーザーがオペレーティング・システム・コマンドを使用してアーカイブ・ログをディスクから削除すると、ログが実際にはディスク上に存在していない場合でも、リポジトリではディスク上に存在しているように示されます。

図12-1に、メディア・マネージャのクロスチェックを示します。RMANは、RMANリポジトリに対して、チェックする4つのバックアップ・セットの名前と場所を問い合せます。RMANは、この情報をターゲット・データベース・サーバーに送信します。ターゲット・データベース・サーバーは、メディア管理ソフトウェアにバックアップについて問い合せます。メディア管理ソフトウェアは、メディア・カタログを確認して、バックアップ・セット3が欠落していることをサーバーにレポートします。RMANは、リポジトリでバックアップ・セット3のステータスをEXPIREDに更新します。DELETE EXPIREDを実行すると、バックアップ・セット3のレコードは削除されます。

図12-1 メディア・マネージャのクロスチェック

図12-1の説明が続きます
「図12-1 メディア・マネージャのクロスチェック」の説明

クロスチェックは、次の処理を行うため有効です。

  • ディスクまたはテープから消失したバックアップや、破損したバックアップに関する以前の情報を更新できます。

  • オペレーティング・システム・コマンドを使用してアーカイブREDOログまたはその他のファイルを削除した場合に、リポジトリを更新できます。

クロスチェック機能を使用すると、ディスクまたはテープ上のバックアップのステータスを確認できます。バックアップがディスク上に存在する場合、CROSSCHECKによって、そのファイルのヘッダーが有効かどうかが確認されます。バックアップがテープ上に存在する場合、このコマンドによって、バックアップがメディア管理ソフトウェアのカタログに存在するかどうかが確認されます。

バックアップ・ピースおよびイメージ・コピーのステータスは、AVAILABLEEXPIREDまたはUNAVAILABLEとなります。RMANのLISTコマンドを実行するか、V$BACKUP_FILES、またはRC_DATAFILE_COPYRC_ARCHIVED_LOGなどのリカバリ・カタログ・ビューを問い合せると、バックアップのステータスを表示できます。クロスチェックによってRMANリポジトリが更新されるため、これらのすべての方法で正確な情報が提供されます。RMANは、RMANリポジトリ内のバックアップが使用できなくなると、そのバックアップのステータスをEXPIREDに更新します。新しいクロスチェックによって期限切れのバックアップが再度使用可能であると判断された場合、RMANはそのステータスをAVAILABLEに更新します。

ノート:

CROSSCHECKコマンドでは、オペレーティング・システム・ファイルまたはリポジトリ・レコードは削除されません。これらを削除するには、DELETEコマンドを使用する必要があります。

DELETE EXPIREDコマンドを発行すると、期限切れのすべてのバックアップを削除できます。RMANは、期限切れのファイルのレコードをリポジトリから削除します。なんらかの理由でファイルがまだメディア上に存在している場合、RMANは警告を発行して、削除できない不一致のオブジェクトのリストを表示します。

12.4.1.2 すべてのバックアップおよびコピーのクロスチェック

ターゲット・データベースとリカバリ・カタログ(使用している場合)に接続してから、必要に応じてCROSSCHECKコマンドを実行し、RMANが認識するバックアップの状態と可用性を検証します。

CROSSCHECKまたはDELETEコマンドを発行する前に、複数のチャネルを構成するか、手動で割り当てます。RMANは、バックアップの作成に使用したチャネルと同じデバイスのタイプを持つすべてのチャネルの各バックアップを検索します。マルチチャネル機能は、1つのコマンドでディスクおよびテープの両方のクロスチェックまたはバックアップの削除を実行する場合に主に使用されます。たとえば、SBTチャネルが次のように構成されているとします。

CONFIGURE DEVICE TYPE sbt PARALLELISM 1;
CONFIGURE DEFAULT DEVICE TYPE sbt;

この場合は、次のコマンドを実行して、ディスクおよびSBTの両方をクロスチェックできます。

CROSSCHECK BACKUP;
CROSSCHECK COPY;

RMANは、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チャネルを構成していない場合は、ディスクおよびテープにメンテナンス・チャネルを手動で割り当てることができます。

ALLOCATE CHANNEL FOR MAINTENANCE DEVICE TYPE sbt;
CROSSCHECK BACKUP;
CROSSCHECK COPY;

RMANは事前構成済のディスク・チャネルを使用するため、ディスク・チャネルを手動で割り当てる必要はありません。

12.4.1.3 特定のバックアップ・セットおよびコピーのクロスチェック

LISTコマンドを使用してバックアップをレポートしてから、CROSSCHECKコマンドを使用してLIST出力に示された特定のバックアップが存在することを確認できます。

DELETE EXPIREDコマンドは、クロスチェックの失敗の原因となるバックアップのリポジトリ・レコードを削除します。

指定したバックアップをクロスチェックするには:

  1. RMANを起動し、ターゲット・データベースおよびリカバリ・カタログ(使用している場合)に接続します。

  2. 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 BACKUPSET DEVICE TYPE disk BACKED UP 3 TIMES TO sbt;
    CROSSCHECK BACKUP OF DATABASE BACKED UP 2 TIMES TO sbt;
    CROSSCHECK CONTROLFILECOPY '/tmp/control01.ctl';
    CROSSCHECK DATAFILECOPY 113, 114, 115;
    CROSSCHECK PROXY 789;
12.4.1.4 プリプラグイン・バックアップのクロスチェック

CROSSCHECKコマンドを使用して、RMANで認識されるプリプラグイン・バックアップおよびプリプラグイン・アーカイブREDOログ・ファイルの状態と可用性を確認します。

ソースCDBで作成されたプリプラグイン・バックアップおよびプリプラグイン・アーカイブREDOログ・ファイルが、ターゲット・データベースからアクセス可能であることを確認します。

プリプラグイン・バックアップをクロスチェックするには:
  1. RMANを開始し、SYSDBAまたはSYSBACKUP権限を持つ共通ユーザーとしてターゲット・データベースのrootに接続します。リカバリ・カタログが使用されている場合は、リカバリ・カタログに接続します。
  2. ターゲットCDBが読取り/書込みモードでオープンされていることを確認します。

    次のコマンドでは、データベースのオープン・モードが表示されます。

    SELECT OPEN_MODE FROM V$DATABASE;
  3. プリプラグイン・コンテナを、プリプラグイン・バックアップをクロスチェックする必要があるPDBに設定します。

    次の例では、プリプラグイン・コンテナをPDB my_pdbに設定します。

    SET PREPLUGIN CONTAINER=my_pdb;
  4. CROSSCHECKコマンドを実行して、プリプラグイン・バックアップの状態と可用性を確認します。

    次のコマンドでは、PDB my_pdbのバックアップをクロスチェックします。

    CROSSCHECK PREPLUGIN BACKUP OF PLUGGABLE DATABASE my_pdb;

12.4.2 バックアップおよびコピーのリポジトリ・ステータスの変更

RMANには、バックアップおよびコピーのリポジトリ・ステータスを変更するための複数の方法が用意されています。

次のいずれかのタスクを実行して、バックアップおよびコピーのリポジトリ・ステータスを変更します。

  • バックアップを使用可能または使用不可にする

    バックアップが一時的に使用可能または使用不可になった場合、バックアップ・ステータスを変更できます。たとえば、マウントされているディスクのメンテナンスを行う場合は、ディスク上のバックアップのレコードのステータスをUNAVAILABLEに更新できます。

  • 保存方針からのバックアップの追加または除外

    KEEP句を使用して構成済の保存方針からバックアップを除外することによって、アーカイブ・バックアップを作成できます。アーカイブ・バックアップのステータスを変更し、その後、構成済の保存方針に追加することもできます。

12.4.2.1 AVAILABLEまたはUNAVAILABLEへのバックアップのステータスの更新

バックアップが検出されない場合、またはオフサイトに移された場合は、CHANGE...UNAVAILABLEコマンドを実行します。

RMANは、ステータスがUNAVAILABLEのファイルはRESTOREまたはRECOVERコマンドでは使用しません。ファイルが後で検出された場合またはメイン・サイトに戻された場合は、CHANGE...AVAILABLEを発行してステータスを再度更新できます。高速リカバリ領域内のファイルをUNAVAILABLEにマークすることはできません。

リポジトリ内のファイルのステータスをUNAVAILABLEまたはAVAILABLEに更新するには:

  1. LISTコマンドを発行して、RMANバックアップの可用性の状態を確認します。たとえば、次のコマンドを発行してすべてのバックアップを表示します。
    LIST BACKUP;
    
  2. UNAVAILABLEまたはAVAILABLEキーワードを指定してCHANGEを実行し、RMANリポジトリの状態を更新します。

    次の例は、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 "TAG20120208T154556" UNAVAILABLE;
    CHANGE DATAFILECOPY '/tmp/system01.dbf' AVAILABLE;
    CHANGE BACKUPSET 12 AVAILABLE;
    CHANGE BACKUP OF SPFILE TAG "TAG20120208T154556" AVAILABLE;
12.4.2.2 アーカイブ・バックアップのステータスの変更

保存方針から除外するバックアップを指定できます。この方法は、ビジネス要件に準拠するためにバックアップをアーカイブする場合に有効です。

ただし、アーカイブ・バックアップは完全に有効なバックアップであり、他のRMANバックアップと同様にリストアできます。

ノート:

制御ファイルにはRMANリポジトリの大規模なデータ・セットを無限に含めることはできないため、KEEP FOREVER句を使用する場合は、リカバリ・カタログを使用する必要があります。

CHANGEコマンドを使用すると、既存のバックアップのKEEPステータスを変更できます。たとえば、長期バックアップを保持しないようにすることができます。BACKUP...KEEPで使用できるオプションをCHANGE...KEEPでも使用できます。

高速リカバリ領域に格納されているバックアップ・セットまたはファイルにはKEEP属性を設定できません。

アーカイブ・バックアップのKEEPステータスを変更するには:

  1. LISTコマンドを発行してバックアップを表示します。たとえば、次のコマンドを発行してすべてのバックアップを表示します。
    LIST BACKUP;
  2. CHANGE...KEEPコマンドを発行して異なる保存期間をこのバックアップに定義するか、またはCHANGE...NOKEEPコマンドを発行して保存方針をこのファイルに適用します。

    次の例では、バックアップ・セットがバックアップの保存方針に従うことができます。

    CHANGE BACKUPSET 231 NOKEEP;
    

    次の例では、データファイルのコピーを保存方針から180日間除外するようにマークします。

    CHANGE DATAFILECOPY '/tmp/system01.dbf' KEEP UNTIL TIME 'SYSDATE+180';
12.4.2.3 削除されたPDBのバックアップのステータス変更

GUIDオプションを指定してCHANGEコマンドを使用して、マルチテナント・コンテナ・データベース(CDB)から削除されたプラガブル・データベース(PDB)に対応するバックアップのステータスを変更します。

PDBの削除後は、そのPDB名を使用して、削除されたPDBに関連付けられているバックアップのステータスを変更できません。かわりに、GUIDを使用して削除されたPDBを識別します。

  1. SYSDBA権限またはSYSBACKUP権限を持つ共通ユーザーとして、rootに接続します。
  2. DBA_PDB_HISTORYビューを問い合せて、削除されたPDBのGUIDを確認します。

    次の例は、test_dbというCDBから削除されたPDBを表示します。

    SELECT pdb_name, pdb_guid FROM dba_pdb_history
    WHERE db_name = 'test_db';
  3. GUID句を指定してCHANGEコマンドを使用して、削除されたPDBに対応するバックアップのステータスを変更します。

    次のコマンドは、GUIDを使用して識別した削除されたPDBに関連付けられているバックアップ・ピースおよびイメージ・コピーの、RMANリポジトリ・レコードを削除します。

    CHANGE BACKUPPIECE GUID 'DFCE8C3A437F214EB4230070EC0D294E' UNCATALOG;
    CHANGE COPY GUID 'DFCE8C3A437F214EB4230070EC0D294E' UNCATALOG;
12.4.2.4 プリプラグイン・バックアップのステータスの変更

CHANGEコマンドを使用して、プリプラグイン・バックアップおよびプリプラグイン・アーカイブREDOログ・ファイルのリポジトリ・ステータスを変更します。

ソースCDBで作成されたプリプラグイン・バックアップおよびアーカイブREDOログ・ファイルが、ターゲット・データベースからアクセス可能であることを確認します。

プリプラグイン・バックアップのステータスを変更するには:

  1. RMANを開始し、SYSDBAまたはSYSBACKUP権限を持つ共通ユーザーとしてrootに接続します。リカバリ・カタログが使用されている場合は、リカバリ・カタログに接続します。
  2. ターゲットCDBが読取り/書込みモードでオープンされていることを確認します。

    次のコマンドでは、データベースのオープン・モードが表示されます。

    SELECT OPEN_MODE FROM V$DATABASE;
  3. 現在のコンテナを、プリプラグイン・バックアップをクロスチェックする必要があるPDBに設定します。

    次の例では、プリプラグイン・コンテナをPDB my_pdbに設定します。

    SET PREPLUGIN CONTAINER=my_pdb;
  4. CHANGEコマンドを実行して、プリプラグイン・アーカイブREDOログ・ファイルの状態と可用性を確認します。

    次のコマンドは、すべてのプリプラグイン・アーカイブREDOログ・ファイルを使用可能にします。

    CHANGE PREPLUGIN BACKUP OF ARCHIVELOG ALL AVAILABLE;

12.4.3 RMANリポジトリへのバックアップ・レコードの追加

CATALOGコマンドを使用すると、リポジトリに記録されていないアーカイブ・ログ、またはRMAN以外の方法を使用して作成されたデータベース・ファイルのコピーの存在をRMANに認識させることができます。

12.4.3.1 カタログ化操作について

ターゲット・データベースの制御ファイルには、ターゲット・データベースによって生成されたすべてのアーカイブREDOログおよびすべてのRMANのバックアップのレコードが保持されます。CATALOGコマンドを実行すると、管理するRMANのファイルのレコードが存在しない場合に、メタデータをリポジトリに追加できます。

次の場合に、RMANのCATALOGコマンドを実行します。

  • オペレーティング・システム・ユーティリティを使用して、データファイル、アーカイブ・ログまたはバックアップ・ピースのコピーを作成した場合。この場合、これらのレコードはリポジトリに含まれません。

  • バックアップ制御ファイルを使用してリカバリを実行し、リカバリ中にアーカイブ先または形式を変更した場合。この場合、リカバリに必要なアーカイブ・ログに関する情報はリポジトリに含まれません。そのため、これらのログをカタログに追加する必要があります。

  • データファイルのコピーをレベル0のバックアップとしてカタログに追加した場合。これによって、増分バックアップ計画の基礎となるデータファイルのコピーを使用して後で増分バックアップを実行できるようになります。

  • 新しいリリースに移行する前に作成したOracle7のデータベース・ファイルのユーザー管理コピー、またはRMANを使用する前に作成したOracle8以上のデータベース・ファイルのユーザー管理コピーをカタログに追加する場合。移行後にデータベースで障害が発生し、移行したデータベースのバックアップを作成していない場合は、これらのデータファイルのコピーを使用してデータベースをリカバリできます。

UNIXのcpコマンドを使用したデータファイルのコピーなど、ユーザー管理コピーを作成するときには必ずカタログに追加してください。ユーザー管理コピーを作成する場合、ALTER TABLESPACE...BEGIN/END BACKUP文を使用してオンライン表領域のデータファイルのコピーを作成できます。RMANはこのようなデータファイルのコピーを作成しませんが、CATALOGコマンドを使用してデータファイルのコピーをリカバリ・カタログに追加し、RMANに認識させることができます。

ユーザー管理コピーをカタログに追加するには、次の条件を満たしている必要があります。

  • ディスク上でアクセス可能であること

  • 単一ファイルの完全なイメージ・コピーであること

  • データファイル、制御ファイル、アーカイブREDOまたはバックアップ・ピースのいずれかのコピーであること

たとえば、ミラー化されたディスク・ドライブにデータファイルを格納する場合は、ミラー化を解除することによってユーザー管理コピーを作成できます。この場合、ミラー化を解除した後にCATALOGコマンドを使用してユーザー管理コピーが存在することをRMANに通知します。再度ミラー化する前に、CHANGE...UNCATALOGコマンドを実行してファイルのコピーが存在しないことをRMANに通知します。

12.4.3.2 カタログへのユーザー管理データファイルのコピーの追加

CATALOGコマンドを使用して、ユーザー管理コピーに関する情報をRMANリポジトリに伝播します。ファイルがカタログに追加されたら、LISTコマンドを実行するか、V$BACKUP_FILESビューを問い合せて、RMANリポジトリに情報が含まれていることを確認します。

データファイルのユーザー管理コピーを作成してカタログに追加するには:

  1. オペレーティング・システム・ユーティリティを使用して、データファイルのコピーを作成します。バックアップ中にデータベースがオープンしており、データファイルがオンラインになっている場合は、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;
    
  2. RMANを起動し、ターゲット・データベースおよびリカバリ・カタログ(使用している場合)に接続します。
  3. CATALOGコマンドを実行します。

    たとえば、ユーザー管理のデータファイル・コピーをカタログに追加するには、次のコマンドを実行します。

    CATALOG DATAFILECOPY '/tmp/users01.dbf';
    

    接続したターゲット・データベース以外のデータベースからデータファイル・コピーをカタログに追加しようとすると、RMANは次のようなエラーを発行します。

    RMAN-00571: ===========================================================
    RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
    RMAN-00571: ===========================================================
    RMAN-03009: failure of catalog command on default channel at 08/29/2013 14:44:34
    ORA-19563: datafile copy header validation failed for file /tmp/tools01.dbf
12.4.3.3 バックアップ・ピースのカタログ化

ディスク上のバックアップ・ピースをカタログに追加できます。この方法は、オペレーティング・システム・ユーティリティを使用して、同じホスト上のある場所から別の場所に、またはあるホストから別のホストにバックアップ・ピースをコピーする場合に有効です。

データベースの以前のインカネーションからバックアップ・ピースのカタログを追加することもできます。RMANは、後続のリストアおよびリカバリ操作中にバックアップ・ピースを使用できるかどうかを決定できます。

バックアップ・ピースをカタログに追加するには:

  1. RMANを起動し、ターゲット・データベースおよびリカバリ・カタログ(使用している場合)に接続します。
  2. バックアップ・ピースのファイル名をカタログに追加します。

    たとえば、次のコマンドを入力します。

    CATALOG BACKUPPIECE '/disk2/09dtq55d_1_2', '/disk2/0bdtqdou_1_1';
    
  3. 必要に応じて、LISTコマンドを実行するか、またはV$ビューを問い合せて変更を確認します。

    ビューには、V$BACKUP_PIECEV$BACKUP_SETV$BACKUP_DATAFILEV$BACKUP_REDOLOGおよびV$BACKUP_SPFILEがあります。次の問合せは、バックアップ・ピース名を示しています。

    SELECT HANDLE 
    FROM   V$BACKUP_PIECE;
12.4.3.4 カタログへのディスクの場所内のすべてのファイルの追加

自動ストレージ管理(ASM)、Oracle Managed Filesフレームワークまたは高速リカバリ領域を使用する場合は、ディスク管理システムによって認識されており、RMANのリポジトリには表示されていないファイルをカタログに再度追加する必要があることがあります。この状況は、メディア障害、ソフトウェアの不具合またはユーザー・エラーが原因でファイル名を追跡するメカニズムで障害が発生した場合に発生する可能性があります。

CATALOG START WITHコマンドを使用すると、ASMディスク・グループ、Oracle Managed Filesまたは従来のファイル・システム・ディレクトリにあるすべてのファイルを検索して、RMANリポジトリに記録されていないファイルを調べることができます。このコマンドによってファイルをカタログに追加できる場合は、ファイルがカタログに追加されます。ファイルをカタログに追加できない場合は、スキップされたファイルの内容が可能なかぎり推測されます。

CATALOG RECOVERY AREAコマンドを使用すると、リカバリ領域内のすべてのファイルをカタログに追加できます。通常、このコマンドを手動で実行する必要はありません。このコマンドは、制御ファイルをリストアまたは作成する場合などに必要に応じてRMANが自動的に実行するためです。このコマンドは、オペレーティング・システム・ユーティリティによってファイルを高速リカバリ領域にコピーする場合に実行できます。

ディスクの場所内のすべてのファイルをカタログに追加するには:

  1. RMANを起動し、ターゲット・データベースおよびリカバリ・カタログ(使用している場合)に接続します。
  2. カタログに追加するファイルのディスクの場所を指定して、CATALOGコマンドを実行します。

    たとえば、次のコマンドを入力します。

    CATALOG START WITH '+disk'; # catalog all files from an ASM disk group
    CATALOG START WITH '/fs1/datafiles/'; # catalog all files in directory

    ノート:

    START WITH句では、ワイルド・カードは正しく使用できません。

    CATALOG RECOVERY AREAコマンドを使用すると、リカバリ領域内のすべてのファイルをカタログに追加できます。この操作で、RMANリポジトリに表示されていないリカバリ領域内のすべてのファイルが追加されます。たとえば:

    CATALOG RECOVERY AREA;
    
  3. LISTコマンドを実行し、ファイルがカタログに追加されていることを確認します。
12.4.3.5 プリプラグイン・アーカイブREDOログのカタログ化

CATALOGコマンドを使用して、プリプラグイン・アーカイブREDOログ・ファイルをRMANリポジトリに追加します。

ソースCDBで作成されたプリプラグイン・アーカイブREDOログ・ファイルが、ターゲット・データベースからアクセス可能であることを確認します。

アーカイブREDOログ・ファイルのプリプラグイン・バックアップをカタログ化するには:

  1. RMANを開始し、SYSDBAまたはSYSBACKUP権限を持つ共通ユーザーとしてターゲット・データベースのrootに接続します。リカバリ・カタログが使用されている場合は、リカバリ・カタログに接続します。
  2. ターゲットCDBが読取り/書込みモードでオープンされていることを確認します。

    次のコマンドでは、データベースのオープン・モードが表示されます。

    SELECT OPEN_MODE FROM V$DATABASE;
  3. 現在のコンテナを、プリプラグイン・バックアップをクロスチェックする必要があるPDBに設定します。

    次の例では、プリプラグイン・コンテナをPDB my_pdbに設定します。

    SET PREPLUGIN CONTAINER=my_pdb;
  4. CATALOGコマンドを実行して、プリプラグイン・アーカイブREDOログ・ファイルをRMANリポジトリ内にカタログ化します。
    次のコマンドは、指定されたプリプラグイン・アーカイブREDOログ・ファイルをカタログ化します。
    CATALOG PREPLUGIN ARCHIVELOG '/disk1/backups/DB18c/backupset/2017_10_09/o1_mf_annnn_MYPDB_MIGR_dxq2r45h_.bkp';

12.4.4 RMANリポジトリからのレコードの削除

RMANリポジトリからファイルのレコードを削除できます。

12.4.4.1 RMANリポジトリでのカタログからの削除操作について

CHANGE...UNCATALOGコマンドを実行して、RMANリポジトリ・レコードに次の処理を行います。

  • 制御ファイル・リポジトリのバックアップ・レコードをDELETED状態に更新します。

  • 特定のバックアップ・レコードをリカバリ・カタログ(使用している場合)から削除します。

RMANは、指定した物理ファイルは変更しません。これらのファイルのリポジトリ・レコードのみを変更します。

このコマンドは、RMAN以外の方法を使用してバックアップを削除した場合に使用できます。たとえば、オペレーティング・システムのユーティリティを使用してアーカイブREDOログを削除した場合、CHANGE ARCHIVELOG ... UNCATALOGコマンドを発行することによってリポジトリからこのログのレコードを削除します。

12.4.4.2 オペレーティング・システム・ユーティリティを使用して削除したファイルのレコードの削除

CHANGE ... UNCATALOGコマンドを使用すると、存在しないファイルを反映してRMANリポジトリを更新できます。

ユーザーがオペレーティング・システム・ユーティリティを使用してバックアップまたはアーカイブREDOログを削除している場合もあります。CROSSCHECKを実行しないかぎり、この削除はRMANでは認識されません。このような場合は、CHANGE..UNCATALOGコマンドを使用できます。

バックアップまたはアーカイブREDOログのカタログ・レコードを削除するには:

  1. オペレーティング・システムのコマンドを使用してオペレーティング・システムから削除したバックアップに対して、CHANGE ... UNCATALOGを実行します。次の例では、制御ファイルおよびデータファイル1のディスク・コピーへのリポジトリの参照を削除します。
    CHANGE CONTROLFILECOPY '/tmp/control01.ctl' UNCATALOG;
    CHANGE DATAFILECOPY '/tmp/system01.dbf' UNCATALOG;
    CHANGE BACKUPSET '/disk1/oradata/backups/db1_full.bkp' UNCATALOG;
    
  2. 任意で、関連するリカバリ・カタログ・ビュー(RC_DATAFILE_COPYRC_CONTROLFILE_COPYなど)を参照して、指定したレコードが削除されたことを確認します。次の問合せでは、コピー4833のレコードが削除されたことを確認しています。
    SELECT CDF_KEY, STATUS 
    FROM RC_DATAFILE_COPY 
    WHERE CDF_KEY = 4833;
    
    CDF_KEY    STATUS
    ---------- ------
    0 rows selected.

12.5 RMANバックアップおよびアーカイブREDOログの削除

RMANのDELETEコマンドを使用すると、アーカイブREDOログおよびRMANバックアップを削除できます。

ディスク上のバックアップの場合、バックアップを削除すると、バックアップ・ファイルがディスクから物理的に削除されます。SBTデバイス上のバックアップの場合、RMANのDELETEコマンドを使用すると、テープ上のバックアップ・ピースまたはプロキシ・コピーを削除するようにメディア・マネージャに指示が行われます。いずれの場合も、削除を反映してRMANのリポジトリが更新されます。

ノート:

CDBでは、SYSDBAまたはSYSBACKUP権限を持つユーザーとしてrootに接続した場合のみ、アーカイブ・ログを削除できます。PDBに接続している場合は、アーカイブREDOログを削除できません。

12.5.1 RMANバックアップの削除の概要

RMANの各バックアップによって、対応するレコードがRMANリポジトリに作成されます。このレコードは、制御ファイルに格納されます。リカバリ・カタログを使用する場合、リカバリ・カタログを制御ファイルと再同期化すると、レコードはリカバリ・カタログにも格納されます。

たとえば、完全なデータベース・バックアップ・セットを生成する場合は、このバックアップ・セットのレコードをV$BACKUP_SETに表示できます。リカバリ・カタログを使用している場合は、RC_BACKUP_SETカタログ・ビューでレコードにアクセスすることもできます。

V$制御ファイル・ビューとリカバリ・カタログ・ビューでは、情報を格納する方法が異なります。この違いが、RMANによるリポジトリ・レコードの処理方法に影響します。リカバリ・カタログのRMANリポジトリは、実際のデータベース表に格納されますが、制御ファイルのRMANリポジトリは、制御ファイルの内部構造に格納されます。

RMANコマンドを使用してバックアップまたはアーカイブREDOログ・ファイルを削除する場合、RMANは次の処理を実行します。

  • オペレーティング・システムから物理ファイルを削除します(ファイルが存在する場合)。

  • 制御ファイル内のファイル・レコードのステータスをDELETEDに更新します。

  • リカバリ・カタログ表からファイル・レコードを削除します(RMANがリカバリ・カタログに接続されている場合)。

制御ファイルのデータは内部構造に格納されているため、RMANは、制御ファイルからレコードを削除できず、レコードのステータスをDELETEDに更新するのみです。ただし、カタログ表は通常のデータベース表であるため、表から行が削除される場合と同様に、カタログ表から行が削除されます。

12.5.1.1 RMANの削除コマンドについて

バックアップおよびバックアップのリカバリ・カタログ・レコードを削除できます。

次の表に、バックアップを削除できるRMANコマンドを示します。

表12-1 RMANの削除コマンド

コマンド 目的

DELETE

バックアップを削除して、制御ファイル・レコードのステータスをDELETEDに更新します。リカバリ・カタログが使用されている場合は、それらのレコードをリカバリ・カタログから削除します。

DELETEによってEXPIREDまたはOBSOLETEのバックアップが削除されるように指定できます。存在しているバックアップにDELETE EXPIREDを実行すると、RMANは警告を発行し、バックアップの削除は行いません。オプションのFORCEキーワードを指定してDELETEコマンドを使用すると、RMANは指定されたバックアップを削除しますが、バックアップがディスクまたはテープから消失している場合に発生するエラーなど、すべてのI/Oエラーを無視します。その後、RMANは、ファイルが削除されたかどうかまたはファイルがすでに欠落していたかどうかに関係なく、バックアップが削除されたという事実を反映してRMANリポジトリを更新します。

RMANは、構成されているすべてのチャネルを使用して削除を実行します。自動チャネル用に構成されていないデバイス上のファイルに対してDELETEを使用する場合は、最初にALLOCATE CHANNEL FOR MAINTENANCEコマンドを使用する必要があります。たとえば、SBTチャネルを使用してバックアップを作成し、ディスク・チャネルのみが構成されている場合は、DELETEに対してSBTチャネルを手動で割り当てる必要があります。ディスクのみのファイルに対してDELETEコマンドを使用する場合は、自動的に割り当てられているメンテナンス・チャネルまたは手動で割り当てられているメンテナンス・チャネルが必要です。

BACKUP...DELETE [ALL] INPUT

アーカイブ・ログ、データファイルのコピー、またはバックアップ・セットをバックアップして、バックアップが正常に完了した後にオペレーティング・システムから入力ファイルを削除します。RMANは、削除された入力ファイルのリポジトリ・レコードも削除して更新します。

ALLを付けずにDELETE INPUTを指定した場合、RMANは、バックアップする特定のファイルのみを削除します。ALL INPUTを指定した場合、RMANは、RMANリポジトリに記録されている、ファイルのすべてのコピーを削除します。

CHANGE...UNCATALOG

指定されたバックアップのリカバリ・カタログ・レコードを削除して、制御ファイル・レコードのステータスをDELETEDに変更します。CHANGE...UNCATALOGコマンドでは、バックアップのRMANリポジトリ・レコードのみが変更され、バックアップは実際には削除されません。

オブジェクトのRMANリポジトリ・レコードが、そのオブジェクトの物理ステータスを反映していない場合があります。たとえば、ディスクにアーカイブREDOログをバックアップした後で、オペレーティング・システム・ユーティリティを使用してそのオブジェクトを削除したとします。最初にCROSSCHECKを実行せずにDELETEを実行すると、リポジトリにログがAVAILABLEと誤って表示されます。

RMANを対話形式で実行すると、ファイルを削除する前に確認を求められます。BACKUPコマンドのいずれの形式でも、NOPROMPTキーワードを使用することによって、これらの確認が行われないようにすることができます。

DELETE NOPROMPT ARCHIVELOG ALL;

関連項目:

RMANリポジトリと物理メディアの間で不一致が発生した場合のDELETEの動作の詳細は、Oracle Databaseバックアップおよびリカバリ・リファレンスを参照してください。

12.5.1.2 アーカイブREDOログの削除について

メンテナンス計画では、高速リカバリ領域、バックアップの保存方針およびアーカイブREDOログの削除方針を構成することをお薦めします。

デフォルトでは、アーカイブREDOログの削除方針はNONEに構成されています。この場合、高速リカバリ領域は、ディスクまたはテープに1回以上バックアップされているとき、またはバックアップ保存方針に従ってログが不要になったときに、ログを削除対象であるとみなします。

アーカイブREDOログは、データベースによって自動的に削除されるか、またはユーザーが実行した、「RMANの削除コマンド」に示されているRMANコマンドによって削除されます。リカバリ領域内のログは、データベースによってできるかぎり保存され、ディスク領域が必要になると対象となるログが削除されます。対象となるログは、BACKUP ... DELETE INPUTまたはDELETE ARCHIVELOGを使用して、リカバリ領域の内部または外部のすべての場所から削除できます。これらのコマンドは両方とも、アーカイブREDOログの削除方針の設定がNONE以外のときは、方針に従います。DELETEコマンドでFORCEオプションを使用すると、アーカイブREDOログの削除方針の設定を無効にできます。

12.5.2 すべてのバックアップおよびコピーの削除

RMANのDELETEコマンドを使用して、バックアップおよびイメージ・コピーを削除します。

状況によっては、データベースに関連付けられているすべてのバックアップ・セット、プロキシ・コピーおよびイメージ・コピーを削除する必要がある場合があります。たとえば、データベースが不要になったため、関連するすべてのファイルをシステムから削除する場合などです。イメージ・コピーは、BACKUP AS COPYコマンドで生成されるファイル、データベースによってアーカイブされるログまたはCATALOGコマンドでカタログに追加されるファイルです。

すべてのバックアップおよびコピーを削除するには:

  1. RMANを起動し、ターゲット・データベースおよびリカバリ・カタログ(使用している場合)に接続します。
  2. 必要に応じて、削除するバックアップが含まれているデバイス用のメンテナンス・チャネルを割り当てます。

    表12-1に示されているように、RMANは、構成されているすべてのチャネルを使用して削除を実行します。チャネルが構成されている場合、メンテナンス・チャネルを手動で割り当てる必要はありません。

  3. バックアップおよびコピーをクロスチェックして、論理レコードが物理メディアと同期化されていることを確認します。
    CROSSCHECK BACKUP;
    CROSSCHECK COPY;
    
  4. バックアップおよびコピーを削除します。

    たとえば、次のコマンドを入力し、プロンプトが表示されたらYESと入力します。

    DELETE BACKUP;
    DELETE COPY;
    

    ディスクおよびテープのチャネルが構成されている場合、RMANは、構成されているSBTチャネルおよび事前構成されているディスク・チャネルの両方を削除時に使用します。RMANは、ファイルを削除する前に確認を求めるプロンプトを表示します。

12.5.3 指定したバックアップおよびコピーの削除

DELETEおよびBACKUP ... DELETEコマンドのいずれを使用しても、特定のバックアップおよびコピーを削除できます。

BACKUP ... DELETEコマンドを実行すると、ファイルはまず通常はテープにバックアップされ、その後入力ファイルが削除されます。

DELETEコマンドでは、削除するオブジェクトを識別するための様々なオプションがサポートされています。アーカイブREDOログを削除する場合、RMANは構成済の設定を使用して、ログを削除できるかどうか判断します。

指定したバックアップおよびコピーを削除するには:

  1. RMANを起動し、ターゲット・データベースおよびリカバリ・カタログ(使用している場合)に接続します。
  2. 必要に応じて、削除するバックアップが含まれているデバイス用のメンテナンス・チャネルを割り当てます。

    RMANは、構成されているすべてのチャネルを使用して削除を実行します。チャネルが構成されている場合、メンテナンス・チャネルを手動で割り当てる必要はありません。

  3. 指定したバックアップおよびコピーを削除します。

    次の例は、DELETEコマンドを使用して削除するバックアップおよびアーカイブ・ログを指定する一般的な方法を示しています。

    • LIST出力の主キーを使用してバックアップを削除します。

      DELETE BACKUPPIECE 101;
      
    • ディスク上のファイル名を指定してバックアップを削除します。

      DELETE CONTROLFILECOPY '/tmp/control01.ctl';
      
    • アーカイブREDOログを削除します。

      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/%';
      
    • テープにバックアップされているかどうかに基づいて、ディスクからアーカイブREDOログを削除します。

      DELETE ARCHIVELOG ALL 
         BACKED UP 3 TIMES TO sbt;
    • テープに2回バックアップされたバックアップ・セットを削除します。

      DELETE BACKUPSET DEVICE TYPE disk BACKED UP 2 TIMES TO sbt;
    • テープに1回バックアップされたターゲット・データベースのバックアップを削除します。

      DELETE BACKUP OF DATABASE DEVICE TYPE disk BACKED UP 1 TIMES TO sbt;
12.5.3.1 BACKUP ... DELETEを使用した指定ファイルの削除

BACKUP ... DELETEを使用すると、アーカイブREDOログ、データファイルのコピー、またはバックアップ・セットをバックアップし、バックアップに成功した後で入力ファイルを削除できます。

DELETE INPUTオプションを指定すると、入力ファイルに対してDELETEコマンドを発行した場合と同じ処理が実行されます。RMANは構成済の設定を使用して、アーカイブREDOログを削除できるかどうか判断します。DELETE ALL INPUT句のALLオプションは、アーカイブREDOログにのみ適用されます。BACKUP ... DELETE ALL INPUTを実行すると、BACKUPコマンドの選択基準を満たすアーカイブREDOログまたはデータファイルのすべてのコピーが削除されます。

12.5.4 期限切れのRMANバックアップおよびコピーの削除

CROSSCHECKを実行し、RMANがファイルの場所を特定できない場合、RMANリポジトリのレコードはEXPIREDステータスに更新されます。その後、DELETE EXPIREDコマンドを使用して、RMANリポジトリから期限切れのバックアップおよびコピーのレコードを削除できます。

EXPIREDとマークされたファイルが実際に存在する場合は、DELETE EXPIREDコマンドによって警告が発行されます。まれに、ファイルが存在する場合でも、リポジトリによってファイルがEXPIREDとマークされる場合があります。たとえば、ファイルが含まれているディレクトリがクロスチェック中に破損し、その後、修復された場合や、メディア・マネージャが適切に構成されておらず、実際には存在するバックアップが存在しないとレポートされる場合などです。

期限切れのリポジトリ・レコードを削除するには:

  1. 最近クロスチェックを実行していない場合は、CROSSCHECKコマンドを発行します。たとえば、次のように入力します。
    CROSSCHECK BACKUP;
    
  2. 期限切れのバックアップを削除します。たとえば、次のように入力します。
    DELETE EXPIRED BACKUP;

12.5.5 保存方針に基づく不要なRMANバックアップの削除

RMANのDELETEコマンドでは、OBSOLETEオプションがサポートされています。このオプションによって、指定されているリカバリ可能性の要件を満たす必要がなくなったバックアップが削除されます。

構成済のデフォルトの保存方針、またはDELETE OBSOLETEコマンドにオプションとして指定した他の保存方針に従って、不要とされるファイルを削除できます。DELETEコマンドの他の形式と同様に、削除されたファイルはバックアップ・メディアおよびリカバリ・カタログから削除され、制御ファイル内でDELETEDとしてマーク付けされます。

引数を使用せずにDELETE OBSOLETEコマンドを指定すると、RMANは、構成されている保存方針で定義されているすべての不要なバックアップを削除します。たとえば:

DELETE OBSOLETE;
12.5.5.1 KEEP UNTIL TIMEに指定した期限が切れた場合のDELETE OBSOLETEの動作

アーカイブ・バックアップに対してKEEP UNTIL TIMEに指定した期限が切れていない場合、バックアップは不要とはみなされません。ただし、KEEP UNTILに指定した期限が切れるとすぐに、構成されているバックアップの保存方針に関係なく、バックアップはすぐに不要とみなされます。このため、KEEPに指定した期限が切れた場合、DELETE OBSOLETEを使用すると、BACKUP ... KEEP UNTIL TIMEで作成されたすべてのバックアップが削除されます。

12.5.6 削除されたPDBのバックアップの削除

GUIDオプションを指定してDELETEコマンドを使用して、マルチテナント・コンテナ・データベース(CDB)から削除されたプラガブル・データベース(PDB)のバックアップを削除します。

DELETE BACKUP ... OF PLUGGABLE DATABASEコマンドは、指定したPDBのバックアップを削除します。ただし、PDBの削除後は指定した名前のPDBが存在しなくなるため、このコマンドは使用できません。そのような場合は、DELETE BACKUP … GUIDコマンドを使用して、削除されたPDBのバックアップを削除します。各PDBにはグローバル一意識別子(GUID)があり、これを使用してPDBを一意に識別できます。削除されたPDBのGUIDは、DBA_PDB_HISTORYビューで使用可能です。

削除されたPDBのバックアップを削除するには:

  1. SYSDBA権限またはSYSBACKUP権限を持つ共通ユーザーとして、rootに接続します。
  2. DBA_PDB_HISTORYビューを問い合せて、削除されたPDBのGUIDを確認します。

    次の例は、prod_dbというCDBから削除されたPDBを表示します。

    SELECT pdb_name, pdb_guid FROM dba_pdb_history
    WHERE db_name = 'prod_db';
  3. GUIDオプションを指定してDELETEコマンドを使用して、削除されたPDBに関連付けられたバックアップまたはコピーを削除します。

    次のコマンドは、指定したGUIDを持つ削除されたPDBのバックアップ・セットおよびイメージ・コピーを削除します。

    DELETE BACKUP GUID '100E64EC12445321C0352900AF0FAC93';
    DELETE COPY GUID '100E64EC12445321C0352900AF0FAC93';

12.5.7 プリプラグイン・バックアップの削除

DELETEコマンドを使用して、プリプラグイン・バックアップおよびプリプラグイン・アーカイブREDOログ・ファイルを削除します。

ソース・データベースで作成されたプリプラグイン・バックアップが、ターゲットCDBからアクセス可能であることを確認します。

プリプラグイン・バックアップを削除するには:

  1. RMANを開始し、SYSDBAまたはSYSBACKUP権限を持つ共通ユーザーとしてターゲットCDBのrootに接続します。リカバリ・カタログが使用されている場合は、リカバリ・カタログに接続します。
  2. ターゲットCDBが読取り/書込みモードでオープンされていることを確認します。

    次のコマンドでは、データベースのオープン・モードが表示されます。

    SELECT OPEN_MODE FROM V$DATABASE;
  3. 現在のコンテナを、プリプラグイン・バックアップをクロスチェックする必要があるPDBに設定します。

    次の例では、プリプラグイン・コンテナをPDB my_pdbに設定します。

    SET PREPLUGIN CONTAINER=my_pdb;
  4. DELETEコマンドを実行して、プリプラグイン・バックアップの状態と可用性を確認します。

    次のコマンドは、PDB my_pdbのプリプラグイン・バックアップを削除します。

    DELETE PREPLUGIN BACKUP OF PLUGGABLE DATABASE my_pdb;

12.6 データベースの削除

オペレーティング・システムからデータベースを削除するには、RMANのDROP DATABASEコマンドを使用できます。RMANは、ターゲット・データベースに属する、サーバー・パラメータ・ファイル、すべてのデータ・ファイル、オンラインREDOログおよび制御ファイルを削除します。

DROP DATABASEでは、マウントされたターゲット・データベースにRMANが接続されている必要があります。リカバリ・カタログに接続している必要はありません。RMANをリカバリ・カタログに接続した状態でオプションINCLUDE COPIES AND BACKUPSを指定すると、RMANはデータベースも登録解除します。

データベースを削除するには:

  1. RMANを起動し、ターゲット・データベースおよびリカバリ・カタログ(使用している場合)に接続します。
  2. データベースに関連付けられているすべてのバックアップをカタログに追加します。たとえば、次のコマンドを実行すると、高速リカバリ領域内のファイルがカタログに追加され、次にセカンダリ・アーカイブ先内のファイルがカタログに追加されます。
    CATALOG START WITH '+disk1';    # all files from recovery area on ASM disk
    CATALOG START WITH '/arch_dest2';  # all files from second archiving location
    
  3. データベースに関連付けられているすべてのバックアップおよびコピーを削除します。たとえば:
    DELETE BACKUPSET; # deletes all backups
    DELETE COPY; # deletes all image copies (including archived logs)
    
  4. データベースをオペレーティング・システムから削除します。

    次のコマンドを実行すると、データベースが削除され、リカバリ・カタログ(使用している場合)から自動的に登録解除されます。RMANによって構成を求められます。

    DROP DATABASE;