ヘッダーをスキップ
Oracle® Databaseバックアップおよびリカバリ・リファレンス
11gリリース2(11.2)
B56270-05
  目次へ移動
目次
索引へ移動
索引

前
 
次
 

CHANGE

用途

CHANGEコマンドを使用すると、次のタスクを実行できます。

  • RMANリポジトリに記録されているバックアップおよびコピーの可用性ステータスを更新します。

  • 自動診断リポジトリに記録されている障害について、その優先順位を変更したり障害をクローズします。

  • リカバリ・カタログに記録されている、ターゲット・データベースのDB_UNIQUE_NAMEを更新します。

  • Data Guard環境にあるデータベースのバックアップを同じ環境内の別のデータベースに関連付けます。


関連項目:

バックアップまたはコピーの可用性ステータスの変更については、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

前提条件

RMANはTARGETとしてデータベース・インスタンスに接続され、そのインスタンスが起動されている必要があります。

使用上の注意

バックアップの関連付けとアクセス可能性の違いについては、「Data Guard環境でのRMANのバックアップ」を参照してください。Data Guard環境では、バックアップまたはコピーを作成するデータベースはファイルに関連付けられます。Data Guard環境のどのデータベースに接続されていても、バックアップに接続可能であれば、CHANGEDELETECROSSCHECKなどのメンテナンス・コマンドをバックアップに使用できます。通常、RMANでは、データベース上で作成されたテープ・バックアップはその環境のすべてのデータベースにアクセス可能であるとみなされますが、ディスク・バックアップは作成元のデータベースのみにアクセス可能であるとみなされます。

たとえば、RMANをスタンバイ・データベースstandby1TARGETとして接続し、そのデータベースをテープとディスクにバックアップするとします。テープ・ドライブが使用できなくなった場合は、Data Guard環境のプライマリ・データベースまたはスタンバイ・データベースにRMANをTARGETとして接続して、テープ・バックアップのステータスをUNAVAILABLEに変更できます。テープ・ドライブが修復された後は、RMANをTARGETとしてデータベースに接続して、テープ・バックアップのステータスをAVAILABLEに戻すことができます。ただし、オペレーティング・システムのユーティリティによって、ディスク・バックアップが誤って削除された場合、RMANはstandby1TARGETとして接続されているときにのみ、ディスク・バックアップのステータスを変更できます。

セマンティクス

change

この句を使用すると、RMANリポジトリのレコードのステータスを変更できます。ステータスを変更するRMANリポジトリ・レコードの主キーを取得するには、LISTコマンドを実行するか、リカバリ・カタログ・ビューに問合せを行います。

構文要素 説明
maintSpec
CHANGEを実行するファイルを指定します。

関連項目: この句のオプションについては、maintSpecを参照してください。

forDbUniqueNameOption
Data Guard環境において、指定したDB_UNIQUE_NAMEにのみ関連付けられたオブジェクトのメタデータを変更します。

関連項目: この句のオプションについては、forDbUniqueNameOptionを参照してください。

AVAILABLE リポジトリ内でバックアップまたはコピーのステータスをAVAILABLEに変更します。RMANによってファイルが検索され、存在しているかどうかが確認されます。

この機能は、使用不可のファイルが再度使用できるようになった場合に有効です。また、このオプションを使用して、以前のインカネーションのバックアップおよびコピーのリポジトリ・ステータスを変更することもできます。

これは、手動または自動のメンテナンス・チャネルを必要とする唯一のCHANGEオプションです。ただし、ディスク専用(つまり、ARCHIVELOGDATAFILECOPYまたはCONTROLFILECOPY)のファイルにCHANGE ... AVAILABLEを使用する場合、メンテナンス・チャネルは不要です。CHANGE ... AVAILABLEをディスク専用でないファイルに使用する場合に、自動チャネル用に構成されていないデバイス・タイプでオブジェクトを作成しているときは、これらのチャネルに対して手動メンテナンス・コマンドを発行します。たとえば、sbtチャネルでバックアップを作成したが、自動的に構成されているのがDISKチャネルのみであれば、バックアップに対してCHANGE ... AVAILABLE操作を行う前に、sbtチャネルを手動で割り当てる必要があります。

Data Guard環境のファイルに対してCHANGE ... AVAILABLEを実行すると、RMANは、ファイルのステータスをAVAILABLEに更新する前にクロスチェックの実行を試みます。ファイルにアクセスできない場合は、ファイルに関連付けられたデータベースにTARGETとして接続してから、同じ操作を実行するように求めるプロンプトが表示されます。ファイルがアクセス可能な場合は、要求に応じてステータスが更新されます。

注意: バックアップのステータスは、LIST出力またはリカバリ・カタログ・ビューで確認できます。

注意: CHANGE ... AVAILABLEは、LogMinerセッション中にロジカル・スタンバイ・データベースによって受け取られる外部アーカイブREDOログ・ファイルに対しては無効です。通常のアーカイブREDOログ・ファイルとは異なり、外部アーカイブREDOログ・ファイルには別のDBIDが使用されています。

keepOption
バックアップまたはコピーのステータスを、構成済の保存方針に基づいて変更します。たとえば、CHANGE ... NOKEEPを指定すると、バックアップのKEEP属性が削除され、そのバックアップはバックアップ保存方針の対象になります。

KEEP FOREVER句を指定するには、リカバリ・カタログを使用する必要があります(例2-37を参照)。RESTORE POINTオプションは、CHANGEでは有効ではありません。高速リカバリ領域に格納されているファイルのCHANGE ... UNAVAILABLEまたはKEEP属性は使用できません。

関連項目: keepOptionを参照してください。

resetDbUniqueNameOption
maintSpecのファイルをData Guard環境の別のデータベースに関連付けます。

関連項目: resetDbUniqueNameOptionを参照してください。

UNAVAILABLE リポジトリ内でバックアップまたはコピーのステータスをUNAVAILABLEに変更します(例2-35を参照)。ステータスは、LIST出力またはリカバリ・カタログ・ビューで確認できます。

このオプションは、ファイルが見つからない場合や、別のサイトに移された場合に有効です。RMANでは、UNAVAILABLEマークを付けたファイルは、RESTOREまたはRECOVERコマンドでは使用されません。後でそのファイルが見つかるか、メイン・サイトに戻った場合は、AVAILABLEオプションを使用して、このステータスを更新します。UNAVAILABLEオプションは、特定のバックアップまたはコピーをリストア対象にせず、削除もしない場合や、以前のインカネーションのバックアップおよびコピーのリポジトリ・ステータスを変更する場合などにも有効です。

高速リカバリ領域のファイルでは、CHANGE ... UNAVAILABLEは無効です。このコマンドは、LogMinerセッション中にロジカル・スタンバイ・データベースで受け取られる外部アーカイブREDOログ・ファイルに対しても無効です。通常のアーカイブREDOログ・ファイルとは異なり、外部アーカイブREDOログ・ファイルには別のDBIDが使用されています。

注意: Data Guard環境のファイルに対してCHANGE ... UNAVAILABLEを実行すると、RMANは、ファイルのステータスをUNAVAILABLEに更新する前にクロスチェックの実行を試みます。ファイルが物理的に存在しているかどうかに関係なく、ステータスは要求に応じて更新されます。

UNCATALOG リカバリ・カタログからデータファイルのコピー、バックアップ・ピースまたはアーカイブREDOログの参照を削除し、ターゲット制御ファイル内のレコードをステータスDELETEDに更新します(例2-36を参照)。CHANGE ... UNCATALOGコマンドでは、物理バックアップおよびコピーは処理されません。ファイルがDELETEコマンド以外の手段で削除されたときは、このコマンドを使用してRMANに通知します。

Data Guard環境のファイルに対してCHANGE ... UNCATALOGを実行すると、リカバリ・カタログからそのファイルのメタデータが削除されるまで、ファイルのクロスチェックは試行されません。ファイルが物理的に存在しているかどうかに関係なく、メタデータは要求に応じて削除されます。

注意: バックアップ制御ファイルから再同期化するか、またはリカバリ・カタログをアップグレードすると、以前CHANGE ... UNCATALOGでRMANリポジトリから削除されたレコードがリカバリ・カタログに再表示される場合があります。


DEVICE TYPE
deviceSpecifier
指定したデバイス・タイプにのみCHANGEを実行します(deviceSpecifierを参照)。このオプションが有効になるのは、構成済の自動チャネルがあり、チャネルを手動で割り当てていない場合のみです。たとえば、CHANGE UNCATALOG ... DEVICE TYPE DISKを実行すると、RMANではディスク上のファイルのみがカタログから削除されます。
changeFailure
データ・リカバリ・アドバイザによって記録された障害の変更内容を指定します。

DB_UNIQUE_NAME
FROM db_unique_name
TO db_unique_name
リカバリ・カタログ内のメタデータを更新して、Data Guard環境でデータベースに新しいDB_UNIQUE_NAMEを反映します。最初の値には、リカバリ・カタログに現在記録されている、データベースの古いDB_UNIQUE_NAMEを指定します。2番目の値には、新しいDB_UNIQUE_NAMEを指定します。

RMANは、リカバリ・カタログおよびマウント済のターゲット・データベースに接続している必要があります。ターゲット・データベースでは、FROM db_unique_nameパラメータにDB_UNIQUE_NAMEを指定できません。指定すると、RMANによってエラーが発行されます。

通常、このコマンドを使用するのは、データベースのDB_UNIQUE_NAME初期化パラメータを変更した後で、リカバリ・カタログのメタデータを更新する必要があるときです。一般に、このコマンドは、名前を変更したデータベースに対して他のRMAN操作を行う前に実行してください。LIST DB_UNIQUE_NAMEを実行した後にCHANGE DB_UNIQUE_NAMEを実行することをお薦めします。

スタンバイ・データベースのDB_UNIQUE_NAME初期化パラメータを、standby_oldからstandby_newに変更したとします。通常、CHANGE DB_UNIQUE_NAMEは場合に実行します。

  • LIST DB_UNIQUE_NAMEコマンドで、DB_UNIQUE_NAMEの古い値は表示されるが、新しい値が表示されない(例2-40を参照)。

  • LIST DB_UNIQUE_NAMEコマンドで、DB_UNIQUE_NAMEの古い値新しい値の両方が表示される。RMANをTARGETとして、DB_UNIQUE_NAMEが認識されていないデータベースに接続すると、そのインスタンスは暗黙的に新しいデータベースとして登録されます。そのため、LIST DB_UNIQUE_NAMEコマンドを実行すると、DB_UNIQUE_NAME初期化パラメータが変更されたデータベースに対して、古い名前と新しい名前(この例ではstandby_oldstandby_new)が表示されることになります。

古い名前のみが表示される場合は、CHANGE DB_UNIQUE_NAME FROM standby_old TO standby_newを実行して、リカバリ・カタログのDB_UNIQUE_NAMEstandby_oldstandby_newに変更します。

古い名前と新しい名前の両方が表示される場合は、CHANGE DB_UNIQUE_NAME FROM standby_old TO standby_newを実行すると、RMANによって次のコマンドが自動的に実行されます。

  1. CHANGE ARCHIVELOG ALL FOR DB_UNIQUE_NAME standby_old RESET DB_UNIQUE_NAME

  2. CHANGE BACKUP FOR DB_UNIQUE_NAME standby_old RESET DB_UNIQUE_NAME

  3. UNREGISTER DB_UNIQUE_NAME standby_old

このように、FROM句に指定されたDB_UNIQUE_NAMEのすべてのバックアップの関連付けが、TO句に指定されたDB_UNIQUE_NAMEに変更されます。


resetDbUniqueNameOption

この句を使用すると、Data Guard環境の1つのデータベースで作成されたバックアップを、同じ環境の別のデータベースに関連付けることができます。次の表では、RESET DB_UNIQUE_NAMEで各種オプションを指定したときのRMANの動作について説明します。

表2-2 RESET DB_UNIQUE_NAMEのオプション

TO db_unique_name FOR DB_UNIQUE_NAME RMANの動作

実行しない

実行しない

RMANは、maintSpecファイルをターゲット・データベースに関連付けます。また、どのデータベースにも関連付けられていないすべてのバックアップの関連付けも変更します。

通常、Oracle Database 11gのリカバリ・カタログ・スキーマにアップグレードした後で、これらのオプションを指定してCHANGEを実行します。これにより、バックアップをターゲット・データベースに関連付けることができます。

実行する

実行しない

RMANは、maintSpecファイルをTO db_unique_nameで示されたデータベースに関連付けます。また、どのデータベースにも関連付けられていないすべてのバックアップの関連付けも変更します。

実行しない

実行する

RMANは、その操作をFOR DB_UNIQUE_NAME句でデータベースに関連付けられているmaintSpecファイルに限定し、それらのファイルをターゲット・データベースに関連付けます。

実行する

実行する

RMANは、その操作をFOR DB_UNIQUE_NAME句でデータベースに関連付けられているmaintSpecファイルに限定し、それらのファイルをTO db_unique_nameで指定されたデータベースに関連付けます。


構文要素 説明
RESET DB_UNIQUE_NAME maintSpecのファイルをターゲット・データベースと関連付けます(例2-39を参照)。各種オプションを指定したときのRMANの動作については、表2-2を参照してください。

データベース間でファイルの関連付けを変更すると、RMANは、リカバリ・カタログから重複した名前を削除します。たとえば、データファイル・コピー/d1/df1.bakの関連付けをデータベースstandby1からデータベースprodに変更すると、リカバリ・カタログが持つこのファイルのレコードは2つではなく、1つのみになります。

このコマンドの実行結果は元に戻せないため、RESET DB_UNIQUE_NAMEオプションを指定する際は注意が必要です。たとえば、データベースstandby1に関連付けられたファイルの関連付けをデータベースprodに変更すると、これらのファイルが以前に関連付けられていたデータベースに関するメタデータの履歴情報はリカバリ・カタログに保持されなくなります。ただし、データベースstandby1の登録を解除して、RMANを再度standby1に接続することは可能です(この場合は、リカバリ・カタログはstandby1制御ファイルのすべてのメタデータで更新されます)。

TO db_unique_name maintSpecのファイルをData Guard環境の指定されたデータベースに関連付けます。

changeFailure

この句を使用すると、障害のステータスを変更できます。障害のリストを表示するには、LIST FAILUREコマンドを使用します。

構文要素 説明
FAILURE 自動診断リポジトリに記録されている障害について、その優先順位を変更したり、障害をクローズすることができます。デフォルトでは、変更を実行する前にRMANによって確認のプロンプトが表示されます。

RMANが接続しているデータベースは、単一インスタンス・データベースである必要があります。また、フィジカル・スタンバイ・データベース以外である必要があります。

   ALL オープン状態の障害のみを変更します。
   CRITICAL CRITICALな障害のみを変更します。
   HIGH 優先順位がHIGHの障害のみを変更します。
   LOW 優先順位がLOWの障害のみを変更します。
failnum 指定した障害のみを変更します。

EXCLUDE FAILURE
failnum
指定した障害を変更しないようにします。

例2-35 UNAVAILABLEステータスへのバックアップの更新

ディスクに領域の問題があるため、バックアップ・セット4を一時的に別の場所に移動したとします。キー4を持つバックアップは、まだ使用可能としてリストされます。

RMAN> LIST BACKUP SUMMARY;

List of Backups
===============
Key     TY LV S Device Type Completion Time #Pieces #Copies Compressed Tag
------- -- -- - ----------- --------------- ------- ------- ---------- ---
1       B  A  A DISK        24-FEB-07       1       1       NO         TAG20070427T115348
3       B  A  A DISK        24-MAR-07       1       1       NO         TAG20070427T115452
4       B  F  A DISK        24-APR-07       1       1       NO         TAG20070427T115456

このバックアップは、より多くのディスク領域が使用可能になったときに元の場所に戻す予定のため、カタログから削除しません。したがって、次の手順でバックアップを使用不可能にします(例には出力例も含まれます)。

RMAN> CHANGE BACKUPSET 4 UNAVAILABLE;
 
changed backup piece unavailable
backup piece handle=/disk2/backup/c-3257893776-20070424-00 RECID=4 STAMP=588858897
Changed 1 objects to UNAVAILABLE status

例2-36 カタログ内のアーカイブREDOログ・ファイルの削除と追加

この例では、すべてのアーカイブREDOログ・ファイルを新しいディレクトリに移動し、カタログから削除した後で、新しい場所でカタログ化します。

RMAN> HOST '/bin/mv $ORACLE_HOME/dbs/*.arc /disk2/archlog/';
RMAN> CHANGE ARCHIVELOG ALL UNCATALOG;
RMAN> CATALOG START WITH '/disk2/archlog' NOPROMPT;

例2-37 アーカイブ・バックアップへのデータベース・バックアップの変更

データベース・バックアップを、オフサイトに保存する予定のアーカイブ・バックアップに変更することが目標であるとします。このバックアップには一貫性があり、リカバリは必要ないため、バックアップとともにアーカイブREDOログ・ファイルを保存する必要はありません。この例では、CHANGE ... KEEP FOREVERコマンドを使用して、バックアップが不要とみなされることがないように指定します。

RMAN> CONNECT TARGET /
RMAN> CONNECT CATALOG rman@catdb

recovery catalog database Password: password

RMAN> CHANGE BACKUP TAG 'consistent_db_bkup' KEEP FOREVER;

例2-38 障害のステータスの変更

次の例では、LIST FAILUREコマンドによって、データファイルに破損ブロックがあることが示されます。障害の番号は5で、優先順位はHIGHです。このデータファイルに含まれているデータは重要ではないため、この障害の優先順位をLOWに変更することにします。

RMAN> LIST FAILURE;

List of Database Failures
Failure ID Priority Status    Time Detected Summary
---------- -------- --------- ------------- -------
5          HIGH     OPEN      11-DEC-06     datafile 8 contains corrupt blocks
 
RMAN> CHANGE FAILURE 5 PRIORITY LOW;
 
List of Database Failures
Failure ID Priority Status    Time Detected Summary
---------- -------- --------- ------------- -------
5          HIGH     OPEN      11-DEC-06     datafile 8 contains corrupt blocks
 
Do you really want to change the above failures (enter YES or NO)? YES
changed 1 failures to LOW priority

例2-39 Data Guard環境での新しいデータベースへのバックアップの関連付け

standby1standby2およびstandby3は、プライマリ・データベースprodに関連付けられているスタンバイ・データベースであるとします。この例では、RMANはターゲット・データベースprodおよびリカバリ・カタログに接続されているとします。

環境からstandby1を削除する予定のため、standby1バックアップをプライマリ・データベースに関連付ける必要があります。環境からstandby3も削除する予定のため、standby3バックアップをstandby2に関連付ける必要があります。次のコマンドを実行します。

CHANGE BACKUP FOR DB_UNIQUE_NAME standby1 RESET DB_UNIQUE_NAME;
CHANGE BACKUP FOR DB_UNIQUE_NAME standby3 RESET DB_UNIQUE_NAME TO standby2;

例2-40 リカバリ・カタログのDB_UNIQUE_NAMEの更新

スタンバイ・データベースのDB_UNIQUE_NAME初期化パラメータがdgrdbms4に設定されており、これをsfrdbms4に変更するとします。スタンバイ・インスタンスを停止し、DB_UNIQUE_NAME初期化パラメータをsfrdbms4に変更して、スタンバイ・インスタンスを再起動します。

その後、リカバリ・カタログを更新して、スタンバイ・データベースの変更された一意の名前を反映させるには、次のようにRMANをプライマリ・データベースとリカバリ・カタログに接続し、CHANGEコマンドを実行します。

RMAN> CONNECT TARGET /
RMAN> CONNECT CATALOG rman@catdb

recovery catalog database Password: password

RMAN> CHANGE DB_UNIQUE_NAME FROM dgrdbms4 TO sfrdbms4;