31 ユーザー管理のリカバリの実行: 高度な例

Recovery Managerを必要としないユーザー管理のバックアップおよびリカバリ計画を使用する場合は、いくつかの一般的なメディア障害のシナリオからリカバリできます。

この章では、複数の一般的なメディア障害の例について説明します。ユーザー管理のバックアップおよびリカバリ計画(Recovery Managerを必要としない計画)を使用した場合に、各障害からリカバリする方法について説明します。

注意:

マルチテナント・コンテナ・データベースは、Oracle Database 20cにおいてサポートされている唯一のアーキテクチャです。ドキュメントの改訂中は、従来の用語が残っている可能性があります。ほとんどの場合、「データベース」と「非CDB」は、コンテキストに応じて、CDBまたはPDBを意味します。アップグレードなど、一部のコンテキストでは、「非CDB」は以前のリリースの非CDBを意味します。

31.1 現行の制御ファイルのサブセットが消失した場合の対応

永続的なメディア障害によってデータベースの1つ以上の制御ファイルが破損したが、メディア障害によって消失していない現行の制御ファイルが1つ以上ある場合は、次の手順でデータベースをリカバリします。

この項では、次の項目について説明します。

• 多重制御ファイルのデフォルトの場所へのコピー

• 多重制御ファイルのデフォルト以外の場所へのコピー

31.1.1 多重制御ファイルのデフォルトの場所へのコピー

消失した制御ファイルを含むディスクおよびファイル・システムが影響を受けていない場合は、影響を受けていない制御ファイルを、欠落した制御ファイルの場所にコピーできます。この場合は、CONTROL_FILES初期化パラメータを編集する必要はありません。

多重制御ファイルをコピーして破損した制御ファイルを置き換える手順

1. インスタンスが実行されている場合は、停止します。

   SQL> SHUTDOWN ABORT
   

2. メディア障害の原因であるハードウェアの問題を解決します。ハードウェアの問題をすぐに解決できない場合は、「多重制御ファイルのデフォルト以外の場所へのコピー」の説明に従って、破損した制御ファイルを代替のストレージ・デバイスにリストアしてデータベースのリカバリを続行します。
3. データベースの現行の制御ファイルの多重コピーから、影響を受けていないものを選択して、破損した制御ファイルを上書きします。たとえば、bad_cf.fをgood_cf.fで置き換えるには、次のように入力します。

   % cp /oracle/good_cf.f /oracle/dbs/bad_cf.f
   

4. 新しいインスタンスを起動し、データベースをマウントしてオープンします。たとえば、次のように入力します。

   SQL> STARTUP

31.1.2 多重制御ファイルのデフォルト以外の場所へのコピー

消失した制御ファイルを含むディスクおよびファイル・システムが影響を受けている場合は、正常な制御ファイルを、欠落した制御ファイルの場所に単純にコピーできません。この場合は、CONTROL_FILES初期化パラメータを変更して、欠落した制御ファイルの新しい場所を示す必要があります。

デフォルト以外の場所に制御ファイルをリストアする手順

1. インスタンスが実行されている場合は、停止します。

   SQL> SHUTDOWN ABORT
   

2. メディア障害の原因であるハードウェアの問題を解決できない場合は、影響を受けていない制御ファイルを代替の場所にコピーします。

   たとえば、正常なcontrol01.dbfを新しいディスクの場所にコピーするには、次のコマンドを発行します。

   % cp /disk1/oradata/trgt/control01.dbf /new_disk/control01.dbf
   

3. CONTROL_FILESパラメータですべての制御ファイルの現在の場所が反映され、リストアされていないすべての制御ファイルが除外されるように、データベースのパラメータ・ファイルを編集します。

   初期化パラメータ・ファイルの設定が次のようになっているとします。

   CONTROL_FILES='/disk1/oradata/trgt/control01.dbf','/bad_disk/control02.dbf'
   

   次のようにCONTROL_FILES初期化パラメータを編集します。

   CONTROL_FILES='/disk1/oradata/trgt/control01.dbf','/new_disk/control02.dbf'
   

4. 新しいインスタンスを起動し、データベースをマウントしてオープンします。次に例を示します。

   SQL> STARTUP

31.2 現行の制御ファイルがすべて消失した場合のリカバリ

永続的なメディア障害によってデータベースのすべての制御ファイルが破損したが、制御ファイルのバックアップがある場合は、次の手順を実行して、バックアップ制御ファイルをリストアします。制御ファイルにアクセスできない場合、インスタンスは起動できますが、データベースをマウントできません。制御ファイルを使用できないときにデータベースをマウントしようとすると、次のエラー・メッセージが表示されます。

ORA-00205: error in identifying control file, check alert log for more info 

注意:

トレース・ファイルおよびアラート・ログの場所を特定する最も簡単な方法は、SQL問合せSELECT NAME, VALUE FROM V$DIAG_INFOを実行する方法です。

制御ファイルを再度アクセス可能にするまでは、データベースをマウントしてオープンすることはできません。バックアップ制御ファイルをリストアする場合は、RESETLOGSオプションを使用してデータベースをオープンする必要があります。

表31-1に示すように、制御ファイルのリストアの手順は、オンラインREDOログを利用できるかどうかによって異なります。

表31-1 制御ファイルが消失した場合のシナリオ

オンライン・ログのステータス	データファイルのステータス	リストア手順
使用可能	現行	リカバリに必要なREDOがオンライン・ログに含まれている場合には、バックアップ制御ファイルをリストアし、リカバリ時にログを適用します。データベースをオープンするためには、変更を含むオンライン・ログのファイル名を指定する必要があります。リカバリ後に、RESETLOGSオプションを使用してデータベースをオープンします。 注意: 制御ファイルを再作成するときに、オンラインREDOログにアクセスできる場合は、リカバリ後にOPEN RESETLOGSオプションを使用する必要はありません。
使用不可	現行	リカバリに必要なREDOがオンライン・ログに含まれている場合は、制御ファイルを再作成します。オンラインREDOログにはアクセスできないため、RESETLOGSでオープンします。
使用可能	バックアップ	バックアップ制御ファイルをリストアし、完全リカバリを実行し、RESETLOGSオプションを使用してデータベースをオープンします。
使用不可	バックアップ	バックアップ制御ファイルをリストアし、不完全リカバリを実行し、RESETLOGSでオープンします。

この項では、次の項目について説明します。

• デフォルトの場所でのバックアップ制御ファイルを使用したリカバリ

• デフォルト以外の場所でのバックアップ制御ファイルを使用したリカバリ

• バックアップ制御ファイルを使用したデータファイルの追加を伴うリカバリ

• バックアップ制御ファイルを使用した読取り専用表領域のリカバリ

31.2.1 デフォルトの場所でのバックアップ制御ファイルを使用したリカバリ

可能であれば、元の場所に制御ファイルをリストアします。この方法では、初期化パラメータ・ファイルで制御ファイルの新しい場所を指定する必要はありません。

デフォルトの場所にバックアップ制御ファイルをリストアする手順

1. インスタンスが実行されている場合は、停止します。

   SQL> SHUTDOWN ABORT
   

2. メディア障害の原因であるハードウェアの問題を解決します。
3. サーバー・パラメータ・ファイルまたは初期化パラメータ・ファイルのCONTROL_FILESパラメータで指定したすべての場所にバックアップ制御ファイルをリストアします。たとえば、サーバー・パラメータ・ファイルに示される制御ファイルの場所が/disk1/oradata/trgt/control01.dbfおよび/disk2/oradata/trgt/control02.dbfの場合は、オペレーティング・システム・ユーティリティを使用して、これらの場所にバックアップ制御ファイルをリストアします。

   % cp /backup/control01.dbf /disk1/oradata/trgt/control01.dbf
   % cp /backup/control02.dbf /disk2/oradata/trgt/control02.dbf
   

4. 新しいインスタンスを起動し、データベースをマウントします。たとえば、次のように入力します。

   SQL> STARTUP MOUNT 
   

5. USING BACKUP CONTROLFILE句を指定してRECOVERコマンドを実行し、リカバリを開始します。不完全リカバリを実行する場合は、UNTIL CANCELを指定します。たとえば、次のように入力します。

   SQL> RECOVER DATABASE USING BACKUP CONTROLFILE UNTIL CANCEL
   

6. プロンプトで指示されたアーカイブ・ログを適用します。必要なアーカイブ・ログがないことを告げる別のメッセージが表示された場合には、必要なREDOレコードがオンラインREDOログに入っていることが考えられます。インスタンスで障害が発生したときに、アーカイブされていない変更がオンライン・ログに入っていた場合には、このような状況が発生することがあります。

   たとえば、次のメッセージが表示されたとします。

   ORA-00279: change 55636 generated at 11/08/2002 16:59:47 needed for thread 1
   ORA-00289: suggestion : /oracle/work/arc_dest/arcr_1_111.arc
   ORA-00280: change 55636 for thread 1 is in sequence #111
   Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
   

   オンラインREDOログの名前を指定し、[Enter]を押します(正しいログが見つかるまで何度か繰り返すことになる場合があります)。

   ORACLE_HOME/oradata/redo01.dbf
   Log applied.
   Media recovery complete.
   

   オンライン・ログにアクセスできない場合は、オンライン・ログを適用せずにリカバリを取り消すことができます。すべてのデータファイルが現行のものである場合に、リカバリに必要なREDOがオンライン・ログの中に含まれているときには、オンライン・ログを適用せずにデータベースをオープンすることはできません。オンライン・ログにアクセスできない場合は、「制御ファイルの再作成」に示す手順を実行して、制御ファイルを再作成する必要があります。

7. リカバリが終了した後、RESETLOGSオプションを指定してデータベースをオープンします。

   SQL> ALTER DATABASE OPEN RESETLOGS;

31.2.2 デフォルト以外の場所でのバックアップ制御ファイルを使用したリカバリ

メディアの損傷が重大なため、元の場所に制御ファイルをリストアできない場合は、サーバー・パラメータ・ファイルで制御ファイルの新しい場所を指定する必要があります。CONTROL_FILES初期化パラメータで指定されたすべての場所に有効な制御ファイルが存在する必要があります。存在しない場合は、データベースをマウントできません。

デフォルト以外の場所に制御ファイルをリストアする手順

1. インスタンスが実行されている場合は、停止します。

   SQL> SHUTDOWN ABORT
   

2. メディア障害の原因であるハードウェアの問題を解決します。
3. CONTROL_FILES初期化パラメータで指定されたすべての場所を編集して、制御ファイルの新しい場所を反映します。たとえば、サーバー・パラメータ・ファイルに制御ファイルの場所が次のように表示され、いずれのディスクにもアクセスできないとします。

   CONTROL_FILES='/disk1/oradata/trgt/control01.dbf',
                 '/disk2/oradata/trgt/control02.dbf'
   

   次の例のように初期化パラメータ・ファイルを編集して、アクセス可能な場所を指定できます。

   CONTROL_FILES='/disk3/cf/control01.dbf','/disk4/cf/control02.dbf'

4. サーバー・パラメータ・ファイルまたは初期化パラメータ・ファイルのCONTROL_FILESパラメータで指定したすべての場所にバックアップ制御ファイルをリストアします。たとえば、サーバー・パラメータ・ファイルに示される制御ファイルの場所が/disk1/oradata/trgt/control01.dbfおよび/disk2/oradata/trgt/control02.dbfの場合は、オペレーティング・システム・ユーティリティを使用して、これらの場所にバックアップ制御ファイルをリストアします。

   % cp /backup/control01.dbf /disk1/oradata/trgt/control01.dbf
   % cp /backup/control02.dbf /disk2/oradata/trgt/control02.dbf
   

5. 新しいインスタンスを起動し、データベースをマウントします。たとえば、次のように入力します。

   SQL> STARTUP MOUNT 
   

6. USING BACKUP CONTROLFILE句を指定してRECOVERコマンドを実行し、リカバリを開始します。不完全リカバリを実行する場合は、UNTIL CANCELを指定します。たとえば、次のように入力します。

   SQL> RECOVER DATABASE USING BACKUP CONTROLFILE UNTIL CANCEL
   

7. プロンプトで指示されたアーカイブ・ログを適用します。必要なアーカイブ・ログがないことを告げる別のメッセージが表示された場合には、必要なREDOレコードがオンラインREDOログに入っていることが考えられます。インスタンスで障害が発生したときに、アーカイブされていない変更がオンライン・ログに入っていた場合には、このような状況が発生することがあります。

   たとえば、次のメッセージが表示されたとします。

   ORA-00279: change 55636 generated at 11/08/2002 16:59:47 needed for thread 1
   ORA-00289: suggestion : /oracle/work/arc_dest/arcr_1_111.arc
   ORA-00280: change 55636 for thread 1 is in sequence #111
   Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
   

   オンラインREDOログの名前を指定し、[Enter]を押します(正しいログが見つかるまで何度か繰り返すことになる場合があります)。

   ORACLE_HOME/oradata/redo01.dbf
   Log applied.
   Media recovery complete.
   

   オンライン・ログにアクセスできない場合は、オンライン・ログを適用せずにリカバリを取り消すことができます。すべてのデータファイルが現行のものである場合に、リカバリに必要なREDOがオンライン・ログの中に含まれているときには、オンライン・ログを適用せずにデータベースをオープンすることはできません。オンライン・ログにアクセスできない場合は、「制御ファイルの再作成」に示す手順を実行して、制御ファイルを再作成する必要があります。

8. リカバリが終了した後、RESETLOGSオプションを指定してデータベースをオープンします。

   SQL> ALTER DATABASE OPEN RESETLOGS;

31.2.3 バックアップ制御ファイルを使用したデータファイルの追加を伴うリカバリ

バックアップ制御ファイルを使用したデータベースのリカバリが、CREATE TABLESPACEまたはALTER TABLESPACE ADD DATAFILE操作を伴ってロールフォワードされる場合は、追加されたファイルにREDOレコードを適用するときにリカバリが停止し、ユーザーによるファイル名の確認が行われます。

たとえば、次の操作を順に行うとします。

1. データベースをバックアップします。

2. /disk1/oradata/trgt/test01.dbfおよび/disk1/oradata/trgt/test02.dbfというデータファイルを含む表領域を作成します。

3. バックアップ制御ファイルをリストアし、CREATE TABLESPACE操作を伴うメディア・リカバリを実行します。

CREATE TABLESPACEのREDOデータの適用時に、次のエラーが表示される場合があります。

ORA-00283: recovery session canceled due to errors 
ORA-01244: unnamed datafile(s) added to control file by media recovery
ORA-01110: data file 11: '/disk1/oradata/trgt/test02.dbf'
ORA-01110: data file 10: '/disk1/oradata/trgt/test01.dbf'

ADD DATAFILE操作を伴うリカバリを実行する手順

1. V$DATAFILEを問い合せて、追加されたファイルを表示します。たとえば、次のように入力します。

   SELECT FILE#,NAME 
   FROM V$DATAFILE;
   
   FILE#           NAME
   --------------- ----------------------
   1               /disk1/oradata/trgt/system01.dbf
   .
   .
   .
   10               /disk1/oradata/trgt/UNNAMED00001
   11               /disk1/oradata/trgt/UNNAMED00002
   

2. 名前のないファイルが複数存在する場合は、次のいずれかの方法を使用して、どの名前なしファイルがどのデータファイルに対応するかを確認します。

   • alert_SID.logを参照し、名前のない各ファイルの元のファイルの場所に関するメッセージを確認します。

   • エラー・メッセージおよびV$DATAFILEから、名前のない各ファイルの元のファイルの場所を導出します。名前のないファイルは、エラー・メッセージの中の同じファイル番号のファイルに対応します。

3. ALTER DATABASE RENAME FILE文を発行して、データファイル名を変更します。たとえば、次のように入力します。

   ALTER DATABASE RENAME FILE '/db/UNNAMED00001' TO
                              '/disk1/oradata/trgt/test01.dbf';
   ALTER DATABASE RENAME FILE '/db/UNNAMED00002' TO
                              '/disk1/oradata/trgt/test02.dbf';
   

4. リカバリ文を発行してリカバリを続行します。次に例を示します。

   RECOVER AUTOMATIC DATABASE USING BACKUP CONTROLFILE UNTIL CANCEL

31.2.4 バックアップ制御ファイルを使用した読取り専用表領域のリカバリ

読取り専用メディアまたは低速のメディア上に読取り専用表領域がある場合は、USING BACKUP CONTROLFILEオプションを指定してリカバリを実行すると、エラーが発生したり、パフォーマンスが低下することがあります。この状況は、制御ファイルがバックアップされたときに表領域が読取り/書込みであったことをバックアップ制御ファイルが示している場合に発生します。この場合、メディア・リカバリでファイルへの書込みが試行されることがあります。読取り専用メディアの場合には、ファイルへの書込みができないことを告げるエラー・メッセージが発行されます。テープでバックアップされる階層ストレージ・システムなど、低速メディアの場合には、パフォーマンスが低下することがあります。

これらの問題を回避するには、バックアップではなく、現行の制御ファイルを使用して、データベースのリカバリを行います。バックアップ制御ファイルを使用する必要がある場合には、読取り専用表領域がメディア障害の影響を受けていなければ、この問題を回避できます。バックアップ制御ファイルを使用する場合には、読取り専用または低速メディアのリカバリに次の代替方法を使用できます。

• バックアップ制御ファイルを使用してリカバリを実行する前に、読取り専用表領域のデータファイルをオフライン化し、メディア・リカバリ後に、ファイルをオンライン化します。

• リカバリには正しいバージョンの制御ファイルを使用します。リカバリの完了時に表領域が読取り専用になる場合は、表領域が読取り専用であった時点の制御ファイルのバックアップを使用する必要があります。同様に、リカバリ後に表領域が読取り/書込みになる場合には、表領域が読取り/書込みであった時点の制御ファイルを使用する必要があります。

31.3 制御ファイルの再作成

永続的なメディア障害によってすべての制御ファイルが消失した場合は、すべてのオンラインREDOログ・メンバーが影響を受けていなければ、新しい制御ファイルを作成した後でデータベースをリカバリできます。リカバリ後にRESETLOGSオプションを指定してデータベースをオープンする必要はありません。

制御ファイルのバックアップの有無および作成日時に応じて、CREATE CONTROLFILE文のテキストを生成する際に表31-2に示すオプションを使用できます。データベースに対する変更はalert_SID.logに記録されるため、どのオプションを選択するかを決定する際は、このログを確認してください。

表31-2 制御ファイルの作成のオプション

状況	対応
データベースの最後の構造変更の後でALTER DATABASE BACKUP CONTROLFILE TO TRACE NORESETLOGSを実行し、SQLコマンド・トレース出力を保存してある場合	トレース出力のCREATE CONTROLFILE文をそのまま使用します。
データベースの構造変更を行う前に、最後のALTER DATABASE BACKUP CONTROLFILE TO TRACEを実行した場合	ALTER DATABASE BACKUP CONTROLFILE TO TRACEの出力を編集して、変更を反映します。たとえば、最近データベースにデータファイルを追加した場合には、このデータファイルをCREATE CONTROLFILE文のDATAFILE句に追加します。
ALTER DATABASE BACKUP CONTROLFILE TO filename文を使用して制御ファイルをバックアップした場合(TO TRACEオプションを使用しなかった場合)	制御ファイルのコピーを使用してSQL出力を取得します。一時的なデータベース・インスタンスを作成し、バックアップ制御ファイルをマウントして、ALTER DATABASE BACKUP CONTROLFILE TO TRACE NORESETLOGSを実行します。制御ファイルのコピーが最新の構造変更の前の日付になっている場合は、トレース・オプションを編集して変更を反映します。
TO TRACE形式でもTO filename形式でも制御ファイルのバックアップがない場合	CREATE CONTROLFILE文を手動で実行します(『Oracle Database SQL言語リファレンス』を参照)。

注意:

デフォルトのUS7ASCII以外のキャラクタ・セットを使用している場合には、CREATE CONTROLFILE文の引数としてキャラクタ・セットを指定する必要があります。データベース・キャラクタ・セットは、起動時にアラート・ログに書き込まれます。また、キャラクタ・セット情報はBACKUP CONTROLFILE TO TRACEの出力にも記録されます。

制御ファイルを作成し、データベースをリカバリするには、次の手順を実行します。

1. データベースをNOMOUNTモードで起動します。たとえば、次のように入力します。

   STARTUP NOMOUNT
   

2. NORESETLOGSオプションを指定して、CREATE CONTROLFILE文で制御ファイルを作成します(オプションについては表31-2を参照)。次の例では、キャラクタ・セットがデフォルトのUS7ASCIIであるとします。

   CREATE CONTROLFILE REUSE DATABASE SALES NORESETLOGS ARCHIVELOG
        MAXLOGFILES 32
        MAXLOGMEMBERS 2
        MAXDATAFILES 32
        MAXINSTANCES 16
        MAXLOGHISTORY 1600
   LOGFILE
        GROUP 1 (
          '/diska/prod/sales/db/log1t1.dbf',
          '/diskb/prod/sales/db/log1t2.dbf'
        )  SIZE 100K,
        GROUP 2 (
          '/diska/prod/sales/db/log2t1.dbf',
          '/diskb/prod/sales/db/log2t2.dbf'
        )  SIZE 100K
   DATAFILE
        '/diska/prod/sales/db/database1.dbf',
        '/diskb/prod/sales/db/filea.dbf';
   

   制御ファイルを作成した後、インスタンスでデータベースがマウントされます。

3. データベースを通常どおりに(USING BACKUP CONTROLFILE句を指定せずに)リカバリします。

   RECOVER DATABASE
   

4. リカバリが終了した後、データベースをオープンします(RESETLOGSオプションは必要ありません)。

   ALTER DATABASE OPEN;
   

5. すぐに制御ファイルをバックアップします。次のSQL文は、/backup/control01.dbfにデータベースの制御ファイルをバックアップします。

   ALTER DATABASE BACKUP CONTROLFILE TO '/backup/control01.dbf' REUSE;

マルチテナント・コンテナ・データベースに制御ファイルを作成するには、次の手順を実行します。

1. マルチテナント・コンテナ・データベース(CDB)がいずれのインスタンスでもマウントされていないことを確認します。
2. SQL*Plusを開きます。
3. SYSDBA権限を持つユーザーとしてrootに接続します。
4. 制御ファイルの作成およびデータベースのリカバリについては、前述の手順に従います。

関連項目:

「制御ファイルのトレース・ファイルへのバックアップ」および「バックアップが利用できない場合のデータファイルの再作成」を参照してください。

31.3.1 作成された制御ファイルを使用したRESETLOGSを伴うリカバリ

次の条件を満たす場合は、OPEN RESETLOGS操作を使用してバックアップをリカバリできます。

• 過去のインカネーションを検出する現行の制御ファイル、バックアップ制御ファイルまたは作成された制御ファイルがある

• すべてのアーカイブREDOログが使用可能である

制御ファイルを再作成する必要がある場合は、ALTER DATABASE BACKUP CONTROLFILE TO TRACEを使用してトレース・ファイルを生成すると、そのファイルにインカネーションの完全な履歴を再構築するために必要なコマンドが含まれます。V$DATABASE_INCARNATIONビューには制御ファイルのRESETLOGSの履歴が表示され、V$LOG_HISTORYビューにはアーカイブ・ログの履歴が表示されます。

インカネーションの履歴は、再作成された制御ファイルでは不完全な場合があります。たとえば、リカバリに必要なアーカイブ・ログが欠落している場合があります。この場合は、ALTER DATABASE REGISTER LOGFILE文を使用して、インカネーションの記録を明示的に作成できます。

次の例では、リカバリに必要だが再作成された制御ファイルには記録されていない4つのログを登録して、データベースをリカバリします。

ALTER DATABASE REGISTER LOGFILE '/disk1/oradata/trgt/arch/arcr_1_1_42343523.arc';
ALTER DATABASE REGISTER LOGFILE '/disk1/oradata/trgt/arch/arcr_1_1_34546466.arc';
ALTER DATABASE REGISTER LOGFILE '/disk1/oradata/trgt/arch/arcr_1_1_23435466.arc';
ALTER DATABASE REGISTER LOGFILE '/disk1/oradata/trgt/arch/arcr_1_1_12343533.arc';
RECOVER AUTOMATIC DATABASE;

31.3.2 再作成された制御ファイルを使用した読取り専用ファイルのリカバリ

リカバリに現行の制御ファイルまたはバックアップ制御ファイルを使用できない場合は、CREATE CONTROLFILE文を実行できます。読取り専用ファイルのリカバリがスキップされるように、CREATE CONTROLFILE文に読取り専用ファイルをリストしないでください。リストアされた読取り専用データファイルのバックアップが、ファイルが読取り/書込みであった時点のものでないかぎり、読取り専用データファイルのリカバリは必要ありません。

制御ファイルを作成し、データベースのマウントおよびオープンを試行すると、制御ファイルにリストされたファイルに対してデータ・ディクショナリのチェックが実行されます。 CREATE CONTROLFILE文に含まれていないが、データ・ディクショナリに存在する各ファイルについては、制御ファイル内にエントリが作成されます。これらのファイルには、MISSINGnnnnnという名前が付けられます。このnnnnnは、0(ゼロ)から開始される5桁の数字です。

データベースをオープンした後、名前の前にMISSINGという接頭辞があるすべてのファイルについて、ALTER DATABASE RENAME FILE文を実行して、読取り専用ファイルの名前を正しいファイル名に変更します。

制御ファイルの再作成が必要となる状況に備えるための操作

データベースをマウントまたはオープンしているときに次の文を実行し、CREATE CONTROLFILE構文を取得します。

ALTER DATABASE BACKUP CONTROLFILE TO TRACE;

このSQL文によって、トレース・ファイルが作成されます。トレース・ファイルは、ユーザーが編集し、制御ファイルを再作成するためのスクリプトとして使用できます。RESETLOGSまたはNORESETLOGS(デフォルト)キーワードを指定して、CREATE CONTROLFILE ... RESETLOGSまたはCREATE CONTROLFILE ... NORESETLOGS対応のスクリプトを生成できます。

CREATE CONTROLFILE文の読取り専用ファイルに関連するすべての制限は、データベースをオープンした後で表領域をオンライン化する必要があることを除き、NORMALモードでオフライン化された表領域にも該当します。一時ファイルはCREATE CONTROLFILE文から除外し、データベースをオープンした後で追加します。

関連項目:

制御ファイルのトレース・バックアップの作成方法については、「制御ファイルのトレース・ファイルへのバックアップ」を参照してください。

31.4 バックアップが利用できない場合のデータファイルの再作成

データファイルが破損し、ファイルのバックアップが利用できない場合でも、次の条件を満たしていれば、データファイルをリカバリできます。

• 元のデータファイルの作成後に書き込まれたすべてのアーカイブ・ログ・ファイルを利用できる

• 制御ファイルに破損したファイルの名前が含まれている(制御ファイルは現行か、破損したデータファイルがデータベースに追加された後で作成されたバックアップである)

  注意:

  ALTER DATABASE文のCREATE DATAFILE句を使用してSYSTEM表領域のデータファイルを再作成することはできません。これは、必要なREDOを使用できないためです。

リカバリのためにデータファイルを再作成する手順

1. 空のデータファイルを作成して、対応するバックアップのない、破損したデータファイルと置き換えます。たとえば、データファイル/disk1/oradata/trgt/users01.dbfが破損し、このファイルのバックアップがないとします。次の文は、元のデータファイル(同じサイズ)をdisk2上に再作成します。

   ALTER DATABASE CREATE DATAFILE '/disk1/oradata/trgt/users01.dbf' AS
                                  '/disk2/users01.dbf';
   

   この文は、消失したファイルと同じサイズの、空のファイルを作成します。制御ファイルおよびデータ・ディクショナリ内の情報が検索され、サイズ情報が取得されます。古いデータファイルは新しいデータファイルとして名前を変更されます。

2. 空のデータファイルに対してメディア・リカバリを実行します。たとえば、次のように入力します。

   RECOVER DATAFILE '/disk2/users01.dbf'
   

3. リカバリ時には、元のデータファイルが作成された後に書き込まれたすべてのアーカイブ・ログを、消失したデータファイルと置き換えた新しい空のファイルに適用する必要があります。

31.5 NOLOGGING表および索引のリカバリ

表および索引はCREATE TABLE AS SELECT文で作成できます。また、NOLOGGINGオプションを使用して作成するように指定することもできます。表または索引をNOLOGGINGとして作成した場合、操作のREDOログ・レコードは生成されません。このため、ARCHIVELOGモードで実行する場合でも、NOLOGGINGを使用して作成されたオブジェクトのリカバリを行うことはできません。

注意:

NOLOGGINGを使用して作成された表または索引の破損が許容できない場合は、リカバリ不能な表または索引を作成した後で、バックアップを作成します。

メディア・リカバリを実行する場合、表または索引の一部が通常どおりに作成され、その他がNOLOGGINGオプションを使用して作成されているときは、RECOVER操作を行うと、NOLOGGINGオブジェクトに論理的に破損しているというマークが付けられます。リカバリ不能なオブジェクトにアクセスを試みると、ORA-01578エラー・メッセージが戻されます。NOLOGGINGオブジェクトを削除し、必要に応じて再作成します。

NOLOGGINGオプションを使用して表を作成し、その表の索引をLOGGINGオプションを使用して作成できるため、メディア・リカバリの実行後、索引には論理的に破損しているというマークが付けられません。ただし、表はリカバリ不能であるため(リカバリ後に破損しているというマークが付けられます)、索引は破損ブロックをポイントします。索引を削除し、必要に応じて表および索引を再作成する必要があります。

関連項目:

データベースへのNOLOGGINGの影響の詳細は、『Oracle Data Guard概要および管理』を参照してください。

31.6 トランスポータブル表領域のリカバリ

Oracle Databaseのトランスポータブル表領域機能を使用すると、ユーザーは表領域のセットを1つのデータベースから別のデータベースにトランスポートできます。表領域をデータベースにトランスポートすることは、ロードされたデータを使用して表領域を作成することに似ています。この機能を使用することには、次の理由でメリットがあります。

• データファイルのコピーとメタデータの統合のみが行われるため、データ・ポンプ・エクスポートまたはSQL*Loaderユーティリティを使用した場合より高速です。

• 索引データを移動できるため、索引を再作成する必要がありません。

関連項目:

トランスポータブル表領域機能の使用方法の詳細は、『Oracle Database管理者ガイド』を参照してください。

トランスポータブル表領域は、通常の表領域と同じように、リカバリ可能です。ただし、通常の表領域はバックアップなしにリカバリできますが、トランスポートされた表領域のリカバリには、トランスポートされたデータファイルの一貫性が保持されているバージョンが必要です。

トランスポータブル表領域をリカバリする手順

1. データベースがオープンしている場合は、トランスポートされた表領域をオフライン化します。たとえば、users表領域をリカバリする場合は、次の文を発行します。

   ALTER TABLESPACE users OFFLINE IMMEDIATE;
   

2. オペレーティング・システム・ユーティリティを使用して、トランスポートされたデータファイルのバックアップをリストアします。このバックアップは、トランスポートされたデータファイルの最初のバージョンでも、表領域がトランスポートされた後で作成されたバックアップでもかまいません。たとえば、次のように入力します。

   % cp /backup/users.dbf $ORACLE_HOME/oradata/trgt/users01.dbf
   

3. 表領域を通常どおりにリカバリします。たとえば、次のように入力します。

   RECOVER TABLESPACE users
   

CREATE TABLESPACE操作を伴うリカバリの場合と同じように、トランスポータブル表領域の操作を伴うリカバリでもエラーORA-01244が表示される場合があります。この場合は、「バックアップ制御ファイルを使用したデータファイルの追加を伴うリカバリ」の手順を使用して、名前のないファイルを正しい場所の名前に変更してください。

31.7 オンラインREDOログ・ファイルが消失した後のリカバリ

データベースのオンラインREDOログがメディア障害の影響を受けたときの正しいリカバリ手順は、特定の考慮事項によって異なります。

次の考慮事項があります。

• オンラインREDOログの構成: ミラー化されているかいないか

• メディア障害のタイプ: 一時的か永続的か

• メディア障害の影響を受けたオンラインREDOログ・ファイルのタイプ: 現行、アクティブ、アーカイブされていない、または非アクティブ

次の表に、オンラインREDOログをリカバリする場合に重要になるV$LOGのステータス情報を示します。

表31-3 V$LOGのSTATUS列

ステータス	説明
UNUSED	このオンラインREDOログは書き込まれたことがありません。
CURRENT	このオンラインREDOログはアクティブです。インスタンス・リカバリに必要です。また、現在書込みが行われているログです。REDOログはオープンまたはクローズです。
ACTIVE	このオンラインREDOログはアクティブです。インスタンス・リカバリに必要です。ただし、現在書込みが行われているログではありません。ブロック・リカバリに使用されている可能性があります。また、アーカイブされる場合とされない場合があります。
CLEARING	このログは、ALTER DATABASE CLEAR LOGFILE文の後で、空のログとして、再作成中です。ログが消去されると、ステータスはUNUSEDに変更されます。
CLEARING_CURRENT	現在のログはクローズ・スレッドの消去中です。新規ログ・ヘッダーの書込みでのI/Oエラーなどの障害がスイッチで発生した場合、ログはこのステータスのままになります。
INACTIVE	このログはインスタンス・リカバリに必要とされなくなりました。メディア・リカバリで使用される場合があります。アーカイブされる場合とされない場合があります。

31.7.1 多重オンラインREDOログ・グループの一部のメンバーが消失した後のリカバリ

多重オンラインREDOログ・グループのメンバーが消失したら、リカバリを実行できます。次の条件が満たされている場合、データベースは通常どおりに機能し続けます。

データベースのオンラインREDOログが多重化されている場合は、各オンラインREDOログ・グループの1つ以上のメンバーがメディア障害の影響を受けていなければ、データベースは通常どおりに機能し続けることができます。ただし、データベースのログ・ライターのトレース・ファイルおよびalert_SID.logにエラー・メッセージが書き込まれます。

次のいずれかのアクションを実行して、多重オンラインREDOログ・グループのメンバー消失の問題を解決できます。

• ハードウェアの問題が一時的な場合は、問題を解決します。ログ・ライター・プロセスは、問題が発生しなかった場合と同様に、以前は使用不可であったオンラインREDOログ・ファイルにアクセスします。

• ハードウェアの問題が永続的な場合には、次の手順に従って、破損したメンバーを削除し、新しいメンバーを追加します。

  注意:

  新しく追加されたメンバーは、ログ・グループが再利用されるまでは、冗長性を提供しません。

1. V$LOGFILEで破損したメンバーのファイル名を検索します。ファイルにアクセスできない場合、ステータスはINVALIDになります。

   SELECT GROUP#, STATUS, MEMBER 
   FROM V$LOGFILE
   WHERE STATUS='INVALID';
   
   GROUP#    STATUS       MEMBER
   -------   -----------  ---------------------
   0002      INVALID      /disk1/oradata/trgt/redo02.log
   

2. 破損したメンバーを削除します。たとえば、メンバーredo02.logをグループ2から削除するには、次の文を発行します。

   ALTER DATABASE DROP LOGFILE MEMBER '/disk1/oradata/trgt/redo02.log';
   

3. グループに新しいメンバーを追加します。たとえば、redo02.logをグループ2に追加するには、次の文を発行します。

   ALTER DATABASE ADD LOGFILE MEMBER '/disk1/oradata/trgt/redo02b.log' 
     TO GROUP 2;
   

   追加するファイルがすでに存在している場合には、グループの他のメンバーと同じサイズである必要があります。また、REUSEオプションを指定する必要があります。次に例を示します。

   ALTER DATABASE ADD LOGFILE MEMBER '/disk1/oradata/trgt/redo02b.log'
     REUSE TO GROUP 2;

31.7.2 オンラインREDOログ・グループのすべてのメンバーが消失した後のリカバリ

オンラインREDOログ・グループのすべてのメンバーがメディア障害によって破損した場合には、障害の影響を受けたオンラインREDOログ・グループのタイプと、データベースのアーカイブ・モードによって、想定されるシナリオが異なります。

破損したオンラインREDOログ・グループが現行のアクティブなものである場合は、このオンラインREDOログ・グループがクラッシュ・リカバリで必要になります。非アクティブなものである場合は、クラッシュ・リカバリで必要とされません。表31-4に、様々なリカバリ・シナリオの概要を示します。

表31-4 オンラインREDOログ・グループが消失した後のリカバリ

グループの状態 . .	対応	対応
非アクティブ	クラッシュ・リカバリで必要ありません	アーカイブされたグループまたはアーカイブされていないグループを消去します。
アクティブ	クラッシュ・リカバリで必要です	チェックポイントを発行してログを消去します。実行できない場合は、フラッシュバック・データベースを使用するか、またはバックアップをリストアし、使用可能な最新のREDOログの時点まで、不完全リカバリを実行する必要があります。
現行	現在書込みが行われているREDOログです	ログを消去します。消去できない場合は、フラッシュバック・データベースを使用するか、またはバックアップをリストアし、使用可能な最新のREDOログの時点まで、不完全リカバリを実行する必要があります。

破損したグループがアクティブか非アクティブかを確認します。

1. V$LOGFILEで消失したREDOログのファイル名を検索し、これに対応するグループ番号を検索します。 たとえば、次のように入力します。

   SELECT GROUP#, STATUS, MEMBER FROM V$LOGFILE;
   
   GROUP#    STATUS       MEMBER
   -------   -----------  ---------------------
   0001                    /oracle/dbs/log1a.f
   0001                    /oracle/dbs/log1b.f
   0002      INVALID       /oracle/dbs/log2a.f
   0002      INVALID       /oracle/dbs/log2b.f
   0003                    /oracle/dbs/log3a.f
   0003                    /oracle/dbs/log3b.f
   

2. どのグループがアクティブかを確認します。

   たとえば、次のSQL問合せを実行します(出力例も示します)。

   SELECT GROUP#, MEMBERS, STATUS, ARCHIVED 
   FROM V$LOG;
   
   GROUP#  MEMBERS           STATUS     ARCHIVED
   ------  -------           ---------  -----------
    0001   2                 INACTIVE   YES
    0002   2                 ACTIVE     NO
    0003   2                 CURRENT    NO
   

3. 次のいずれかのアクションを実行します。

   • 影響を受けたグループが非アクティブな場合には、「非アクティブのオンラインREDOログ・グループの消失」の手順に従ってください。

   • 影響を受けたグループがアクティブな場合(前述の例のような場合)には、「アクティブなオンラインREDOログ・グループの消失」の手順に従ってください。

31.7.2.1 非アクティブのオンラインREDOログ・グループの消失

INACTIVEステータスのオンラインREDOログ・グループのすべてのメンバーが破損した場合は、その非アクティブREDOログ・グループを破損させたメディアの問題を解決できるかどうかによって、手順が異なります。障害が一時的な場合は、問題を解決します。ログ・ライターは、必要な場合にREDOログ・グループを再利用できます。障害が永続的な場合は、破損した非アクティブのオンラインREDOログ・グループは最終的に、データベースの通常の実行を停止させます。この項の説明に従ってALTER DATABASE CLEAR LOGFILE文を発行し、破損したグループを手動で再初期化します。

31.7.2.1.1 非アクティブのアーカイブREDOの消去

データベースをオープンまたはクローズした状態で、非アクティブのREDOログ・グループを消去できます。手順は、破損したグループがアーカイブされているかどうかで異なります。

アーカイブされている、非アクティブのオンラインREDOログ・グループを消去する手順

1. データベースが停止している場合は、新しいインスタンスを起動してデータベースをマウントします。

   STARTUP MOUNT
   

2. 破損したログ・グループを再初期化します。たとえば、REDOログ・グループ2を消去するには、次の文を発行します。

   ALTER DATABASE CLEAR LOGFILE GROUP 2;

31.7.2.1.2 非アクティブのアーカイブされていないREDOの消去

アーカイブされていないREDOログを消去することによって、アーカイブせずに、ログを再利用できます。ログの中の最初の変更の前にファイルがオフライン化されておらず、ログの中の最後の変更前にバックアップが開始されている場合は、このアクションによってバックアップは使用できなくなります。このため、バックアップのリカバリのために消去されたログ・ファイルが必要となった場合は、このバックアップはリカバリできません。アーカイブされていないREDOログを消去すると、ログの欠落のため、バックアップからの完全リカバリを実行できなくなります。

アーカイブされていない、非アクティブのオンラインREDOログ・グループを消去する手順

1. データベースが停止している場合は、新しいインスタンスを起動してデータベースをマウントします。

   SQL> STARTUP MOUNT
   

2. UNARCHIVEDキーワードを使用してログを消去します。

   たとえば、ログ・グループ2を消去するには、次のSQL文を発行します。

   SQL> ALTER DATABASE CLEAR UNARCHIVED LOGFILE GROUP 2;
   

   消去されたログを使用してオンライン化する必要があるオフライン・データファイルが存在する場合は、UNRECOVERABLE DATAFILEキーワードが必要です。データファイルをオンライン化するために必要なREDOログが消去され、そのコピーもないため、そのデータファイルを削除する必要があります。たとえば、次のように入力します。

   SQL> ALTER DATABASE CLEAR UNARCHIVED LOGFILE GROUP 2 UNRECOVERABLE DATAFILE;
   

3. オペレーティング・システム・ユーティリティを使用して、すぐにすべてのデータファイルをバックアップします。これによって、消去されたログ・グループを使用しなくても完全リカバリを実行できるバックアップを作成します。 たとえば、次のように入力します。

   % cp /disk1/oracle/dbs/*.dbf /disk2/backup
   

4. ALTER DATABASE文を使用して、データベースの制御ファイルをバックアップします。たとえば、次のように入力します。

   SQL> ALTER DATABASE BACKUP CONTROLFILE TO '/oracle/dbs/cf_backup.f';

31.7.2.1.3 CLEAR LOGFILE操作の失敗

次の操作を実行できない場合、メディア障害によるI/Oエラーによって、ALTER DATABASE CLEAR LOGFILE文が失敗することがあります。

• 現在構成されているREDOログのファイル名を基にREDOログ・ファイルを再作成し、REDOログ・ファイルを代替メディアへ再配置する

• 現在構成されているログ・ファイル名が(メディア障害などによって)無効または使用できなくなったため、その名前を再利用してREDOログ・ファイルを再作成する

これらの場合には、ALTER DATABASE CLEAR LOGFILE文は(I/Oエラーを受け取る前に)、ログが消去され、アーカイブが必要ないことを、制御ファイルに正しく通知します。CLEAR LOGFILE文が新しいREDOログ・ファイルを作成して0(ゼロ)を書き込もうとした段階でI/Oエラーが発生します。この事実はV$LOG.CLEARING_CURRENTに反映されます。

31.7.2.2 アクティブなオンラインREDOログ・グループの消失

データベースがまだ実行中であり、消失したアクティブなREDOログが現行ログでない場合は、ALTER SYSTEM CHECKPOINT文を発行します。操作が正常に実行されると、アクティブなREDOログがアクティブでなくなるため、「非アクティブのオンラインREDOログ・グループの消失」の手順を実行できます。操作が正常に実行されなかったか、またはデータベースが停止した場合は、アーカイブ・モードに応じて、この項のいずれかの手順を実行します。

現行ログとは、LGWRによって現在書込みが行われているログです。LGWRのI/O操作が失敗すると、LGWRは終了し、インスタンスで障害が発生します。この場合には、バックアップをリストアし、不完全リカバリを実行し、RESETLOGSオプションを指定してデータベースをオープンする必要があります。

31.7.2.2.1 NOARCHIVELOGモードでのアクティブなログが消失した場合のリカバリ

この例では、データベースのアーカイブ・モードはNOARCHIVELOGです。

NOARCHIVELOGモードでアクティブなオンライン・ログ・グループが消失した場合にリカバリを実行する手順

1. メディア障害が一時的な場合は、必要に応じてデータベースがグループを再利用できるように、問題を解決します。
2. 一貫性のあるデータベース全体(データファイルおよび制御ファイル)のバックアップからデータベースをリストアします。たとえば、次のように入力します。

   % cp /disk2/backup/*.dbf $ORACLE_HOME/oradata/trgt/
   

3. データベースをマウントします。

   STARTUP MOUNT
   

4. オンラインREDOログはバックアップされないため、データファイルおよび制御ファイルとともにリストアすることはできません。データベースでオンラインREDOログをリセットできるように、まず不完全リカバリを行う必要があります。

   RECOVER DATABASE UNTIL CANCEL
   CANCEL
   

5. RESETLOGSオプションを使用してデータベースをオープンします。

   ALTER DATABASE OPEN RESETLOGS;
   

6. 一貫性のある状態でデータベースを停止します。たとえば、次のように入力します。

   SHUTDOWN IMMEDIATE
   

7. データベース全体のバックアップを実行します。

メディア障害が一時的な場合は、必要に応じてデータベースがグループを再利用できるように、問題を解決します。メディア障害が一時的なものでない場合には、次の手順を使用します。

31.7.2.2.2 ARCHIVELOGモードでのアクティブなログが消失した場合のリカバリ

この例では、データベースのアーカイブ・モードはARCHIVELOGです。

ARCHIVELOGモードでアクティブなオンラインREDOログ・グループが消失した場合にリカバリを実行する手順

1. 不完全メディア・リカバリを開始して、破損したログの前のログまでリカバリします。
2. 消失したREDOログの現在の名前を、新しく作成したファイルに使用できることを確認します。使用できない場合は、破損したオンラインREDOログ・グループのメンバーの名前を新しい場所で変更します。たとえば、次のように入力します。

   ALTER DATABASE RENAME FILE "/disk1/oradata/trgt/redo01.log" TO "/tmp/redo01.log";
   ALTER DATABASE RENAME FILE "/disk1/oradata/trgt/redo02.log" TO "/tmp/redo02.log";
   

3. RESETLOGSオプションを使用してデータベースをオープンします。

   ALTER DATABASE OPEN RESETLOGS;

   注意:

   不完全リカバリのエンドポイントから現在までの間に実行されたすべての更新を、再度実行する必要があります。

31.7.2.3 複数のREDOログ・グループの消失

オンラインREDOログの複数のグループが消失した場合には、リカバリの最も困難なログのリカバリ方法を使用します。リカバリが困難な順に示します。

1. 現行のオンラインREDOログ

2. アクティブなオンラインREDOログ

3. アーカイブされていないオンラインREDOログ

4. 非アクティブのオンラインREDOログ

31.8 フラッシュバック機能を使用しない、削除された表のリカバリ

データベースから誤って表を削除することは少なくありません。一般に、最も高速で簡単な解決方法は、フラッシュバック・ドロップ機能を使用して、表の削除を無効にする方法です。フラッシュバック表を使用できない場合(フラッシュバック・ドロップが無効になっている場合や表がPURGEオプションで削除された場合など)は、この項の手順を実行できます。

この項では、フラッシュバック・データベース機能が無効であるためにFLASHBACK DATABASEコマンドは使用できないことを想定しています。ただし、データベースの物理バックアップは存在します。可能であれば、ユーザー・エラーが発生したデータベースをオンラインのまま保ち、使用できるようにします。

注意:

強力な権限を適切なユーザーのみに付与することによって、リカバリを必要とするユーザー・エラーを減らすことができます。

誤って削除された表をリカバリする手順

1. この手順の後のステップでエラーが発生した場合に備えて、既存のデータベースのすべてのデータファイルをバックアップします。
2. データベースの部分バックアップを代替の場所にリストアします。最低限、次のものをリストアします。

   • SYSTEM表領域およびSYSAUX表領域

   • UNDOセグメントまたはロールバック・セグメントを含む表領域

   • 取得するデータが含まれている自己完結型の表領域

3. リストアされたバックアップ制御ファイルを使用して、表が削除された直前まで、このバックアップの不完全リカバリを実行します。
4. データ・ポンプ・エクスポートを使用して、データベースの一時的にリストアされたバージョンから、消失したデータをエクスポートします。この例では、誤って削除された表がエクスポートされます。

   注意:

   システム監査オプションがエクスポートされます。

5. データ・ポンプ・インポート・ユーティリティを使用して、本番データベースにデータをインポートします。
6. 領域の節約のためにデータベースの一時コピーのファイルを削除します。

関連項目:

Oracle Data Pumpの詳細は、『Oracle Databaseユーティリティ』を参照してください。

31.9 SQL*Plusでのデータベースの削除

データベース(データベースを構成するデータベース・ファイル)をオペレーティング・システムから削除する必要がある場合があります。たとえば、テスト・データベースを作成した後に、そのデータベースを使用しなくなった場合などがこれに当たります。SQL文DROP DATABASEを実行すると、データベースを削除できます。

関連項目:

同等の機能を持つRMANコマンドDROP DATABASEの使用方法については、「データベースの削除」を参照してください。

SQL*Plusでデータベースを削除する手順

1. 管理者権限を使用してターゲット・データベースに接続した後、データベースがマウントされているか、または制限モードでユーザーが接続していない状態でオープンしていることを確認します。

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

   SQL> STARTUP RESTRICT FORCE MOUNT
   

2. データファイルおよび制御ファイルを、オペレーティング・システムから削除します。

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

   SQL> DROP DATABASE; # deletes all database files, both ASM and non-ASM
   

   データベースがRAWディスクに配置されている場合、このコマンドではRAWディスクの実際の特殊ファイルを削除できません。

3. オペレーティング・システム・ユーティリティを使用して、データベースに関連するすべてのバックアップおよびアーカイブ・ログを削除します。

   たとえば、LinuxおよびUNIXで次のコマンドを入力します。

   % rm /backup/* /disk1/oradata/trgt/arch/*