11g リリース1（11.1）
E05700-03
 目次 |
 索引 |
| Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド 11g リリース1（11.1） E05700-03 |
|
この章では、複数の一般的なメディア障害の例について説明します。ユーザー管理のバックアップおよびリカバリ計画（Recovery Managerを必要としない計画）を使用した場合に、各障害からリカバリする方法について説明します。この章の内容は、次のとおりです。
永続的なメディア障害によってデータベースの1つ以上の制御ファイルが破損したが、メディア障害によって消失していない現行の制御ファイルが1つ以上ある場合は、次の手順でデータベースをリカバリします。
消失した制御ファイルを含むディスクおよびファイル・システムが影響を受けていない場合は、影響を受けていない制御ファイルのいずれかを、欠落した制御ファイルの場所にコピーできます。この場合は、CONTROL_FILES初期化パラメータを編集する必要はありません。
SQL> SHUTDOWN ABORT
bad_cf.fをgood_cf.fで置き換えるには、次のように入力します。
% cp /oracle/good_cf.f /oracle/dbs/bad_cf.f
SQL> STARTUP
消失した制御ファイルを含むディスクおよびファイル・システムが影響を受けている場合は、正常な制御ファイルのいずれかを、欠落した制御ファイルの場所に単純にコピーできません。この場合は、CONTROL_FILES初期化パラメータを変更して、欠落した制御ファイルの新しい場所を示す必要があります。
SQL> SHUTDOWN ABORT
たとえば、正常なcontrol01.dbfを新しいディスクの場所にコピーするには、次のコマンドを発行します。
% cp /disk1/oradata/trgt/control01.dbf /new_disk/control01.dbf
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'
SQL> STARTUP
永続的なメディア障害によってデータベースのすべての制御ファイルが破損したが、制御ファイルのバックアップがある場合は、次の手順を実行して、バックアップ制御ファイルをリストアします。制御ファイルにアクセスできない場合、インスタンスは起動できますが、データベースをマウントできません。制御ファイルを使用できないときにデータベースをマウントしようとすると、次のエラー・メッセージが表示されます。
ORA-00205: error in identifying control file, check alert log for more info
制御ファイルを再度アクセス可能にするまでは、データベースをマウントしてオープンすることはできません。バックアップ制御ファイルをリストアする場合は、RESETLOGSオプションでオープンする必要があります。
表29-1に示すように、制御ファイルのリストアの手順は、オンラインREDOログを利用できるかどうかによって異なります。
可能であれば、元の場所に制御ファイルをリストアします。この方法では、初期化パラメータ・ファイルで制御ファイルの新しい場所を指定する必要はありません。
SQL> SHUTDOWN ABORT
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
SQL> STARTUP MOUNT
USING BACKUP CONTROLFILE句を指定してRECOVERコマンドを実行し、リカバリを開始します。不完全リカバリを実行する場合は、UNTIL CANCELを指定します。たとえば、次のように入力します。
SQL> RECOVER DATABASE USING BACKUP CONTROLFILE UNTIL CANCEL
たとえば、次のメッセージが表示されたとします。
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がオンライン・ログの中に含まれているときには、オンライン・ログを適用せずにデータベースをオープンすることはできません。オンライン・ログにアクセスできない場合は、「制御ファイルの再作成」に示す手順を実行して、制御ファイルを再作成する必要があります。
RESETLOGSオプションを指定してデータベースをオープンします。
SQL> ALTER DATABASE OPEN RESETLOGS;
メディアの損傷が重大なため、元の場所に制御ファイルをリストアできない場合は、サーバー・パラメータ・ファイルで制御ファイルの新しい場所を指定する必要があります。CONTROL_FILES初期化パラメータで指定されたすべての場所に有効な制御ファイルが存在する必要があります。存在しない場合は、データベースをマウントできません。
CONTROL_FILES初期化パラメータで指定されたすべての場所を編集して、制御ファイルの新しい場所を反映します。たとえば、サーバー・パラメータ・ファイルに制御ファイルの場所が次のように表示され、いずれのディスクにもアクセスできないとします。
CONTROL_FILES='/disk1/oradata/trgt/control01.dbf', '/disk2/oradata/trgt/control02.dbf'
次の例のように初期化パラメータ・ファイルを編集して、アクセス可能な場所を指定できます。
CONTROL_FILES='/disk3/cf/control01.dbf','/disk4/cf/control02.dbf'
バックアップ制御ファイルを使用したデータベースのリカバリが、CREATE TABLESPACEまたはALTER TABLESPACE ADD DATAFILE操作を伴ってロールフォワードされる場合は、追加されたファイルにREDOレコードを適用するときにリカバリが停止し、ユーザーによるファイル名の確認が行われます。
たとえば、次の操作を順に行うとします。
/disk1/oradata/trgt/test01.dbfおよび/disk1/oradata/trgt/test02.dbfというデータファイルを含む新しい表領域を作成します。
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'
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
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';
RECOVER AUTOMATIC DATABASE USING BACKUP CONTROLFILE UNTIL CANCEL
読取り専用メディアまたは低速のメディア上に読取り専用表領域がある場合は、USING BACKUP CONTROLFILEオプションを指定してリカバリを実行すると、エラーが発生したり、パフォーマンスが低下することがあります。この状況は、制御ファイルがバックアップされたときに表領域が読取り/書込みであったことをバックアップ制御ファイルが示している場合に発生します。この場合、メディア・リカバリでファイルへの書込みが試行されることがあります。読取り専用メディアの場合には、ファイルへの書込みができないことを告げるエラー・メッセージが発行されます。テープでバックアップされる階層ストレージ・システムなど、低速メディアの場合には、パフォーマンスが低下することがあります。
これらの問題を回避するには、バックアップではなく、現行の制御ファイルを使用して、データベースのリカバリを行います。バックアップ制御ファイルを使用する必要がある場合には、読取り専用表領域がメディア障害の影響を受けていなければ、この問題を回避できます。バックアップ制御ファイルを使用する場合には、読取り専用または低速メディアのリカバリに次の代替方法を使用できます。
永続的なメディア障害によってすべての制御ファイルが消失した場合は、すべてのオンラインREDOログ・メンバーが影響を受けていなければ、新しい制御ファイルを作成した後でデータベースをリカバリできます。リカバリ後にRESETLOGSオプションを指定してデータベースをオープンする必要はありません。
制御ファイルのバックアップの有無および作成日時に応じて、CREATE CONTROLFILE文のテキストを生成する際に次の表に示すオプションを使用できます。データベースに対する変更はalert_SID.logに記録されるため、どのオプションを選択するかを決定する際は、このログを確認してください。
NOMOUNTモードで起動します。たとえば、次のように入力します。
STARTUP NOMOUNT
NORESETLOGSオプションを指定して、CREATE CONTROLFILE文で制御ファイルを作成します（オプションについては表29-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';
制御ファイルを作成した後、インスタンスでデータベースがマウントされます。
USING BACKUP CONTROLFILE句を指定せずに）リカバリします。
RECOVER DATABASE
RESETLOGSオプションは必要ありません）。
ALTER DATABASE OPEN;
/backup/control01.dbfにデータベースの制御ファイルをバックアップします。
ALTER DATABASE BACKUP CONTROLFILE TO '/backup/control01.dbf' REUSE;
次の条件を満たす場合は、OPEN RESETLOGS操作を使用してバックアップをリカバリできます。
制御ファイルを再作成する必要がある場合は、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;
リカバリに現行の制御ファイルまたはバックアップ制御ファイルを使用できない場合は、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文から除外し、データベースをオープンした後で追加する必要があります。
データファイルが破損し、ファイルのバックアップが利用できない場合でも、次の条件を満たしていれば、データファイルをリカバリできます。
/disk1/oradata/trgt/users01.dbfが破損し、このファイルのバックアップがないとします。次の文は、元のデータファイル（同じサイズ）をdisk2上に再作成します。
ALTER DATABASE CREATE DATAFILE '/disk1/oradata/trgt/users01.dbf' AS '/disk2/users01.dbf';
この文は、消失したファイルと同じサイズの、空のファイルを作成します。制御ファイルおよびデータ・ディクショナリ内の情報が検索され、サイズ情報が取得されます。古いデータファイルは新しいデータファイルとして名前を変更されます。
RECOVER DATAFILE '/disk2/users01.dbf'
表および索引はCREATE TABLE AS SELECT文で作成できます。また、NOLOGGINGオプションを使用して作成するように指定することもできます。表または索引をNOLOGGINGとして作成した場合、操作のREDOログ・レコードは生成されません。このため、ARCHIVELOGモードで実行している場合でも、NOLOGGINGを使用して作成されたオブジェクトのリカバリを行うことはできません。
メディア・リカバリを実行する場合、表または索引の一部が通常どおりに作成され、その他がNOLOGGINGオプションを使用して作成されているときは、RECOVER操作を行うと、NOLOGGINGオブジェクトに論理的に破損しているというマークが付けられます。リカバリ不能なオブジェクトにアクセスを試みると、ORA-01578エラー・メッセージが戻されます。NOLOGGINGオブジェクトを削除し、必要に応じて再作成します。
NOLOGGINGオプションを使用して表を作成し、その表の索引をLOGGINGオプションを使用して作成できるため、メディア・リカバリの実行後、索引には論理的に破損しているというマークが付けられません。ただし、表はリカバリ不能であるため（リカバリ後に破損しているというマークが付けられます）、索引は破損ブロックをポイントします。索引を削除し、必要に応じて表および索引を再作成する必要があります。
Oracle Databaseのトランスポータブル表領域機能を使用すると、ユーザーは表領域のセットを1つのデータベースから別のデータベースに転送できます。表領域をデータベースに転送することは、あらかじめロードされたデータを使用して表領域を作成することに似ています。この機能を使用することには、次の理由でメリットがあります。
トランスポータブル表領域は、通常の表領域と同じように、リカバリ可能です。ただし、通常の表領域はバックアップなしにリカバリできますが、転送された表領域のリカバリには、転送されたデータファイルの一貫性が保持されているバージョンが必要です。
users表領域のリカバリの場合には、次のコマンドを発行します。
ALTER TABLESPACE users OFFLINE IMMEDIATE;
% cp /backup/users.dbf $ORACLE_HOME/oradata/trgt/users01.dbf
RECOVER TABLESPACE users
CREATE TABLESPACE操作を伴うリカバリの場合と同じように、トランスポータブル表領域の操作を伴うリカバリでもエラーORA-01244が表示される場合があります。この場合は、「バックアップ制御ファイルを使用したデータファイルの追加を伴うリカバリ」の手順を使用して、名前のないファイルを正しい場所の名前に変更してください。
データベースのオンラインREDOログがメディア障害の影響を受けたときの正しいリカバリ手順は、次の考慮事項によって異なります。
表29-3に、オンラインREDOログをリカバリする場合に重要な、V$LOGのステータス情報を示します。
データベースのオンラインREDOログが多重化されている場合は、各オンラインREDOログ・グループの1つ以上のメンバーがメディア障害の影響を受けていなければ、データベースは通常どおりに機能し続けることができます。ただし、データベースのログ・ライターのトレース・ファイルおよびalert_SID.logにエラー・メッセージが書き込まれます。
次のいずれかのアクションを実行して、問題を解決します。
V$LOGFILEで破損したメンバーのファイル名を検索します。ファイルにアクセスできない場合、ステータスはINVALIDになります。
SELECT GROUP#, STATUS, MEMBER FROM V$LOGFILE WHERE STATUS='INVALID'; GROUP# STATUS MEMBER ------- ----------- --------------------- 0002 INVALID /disk1/oradata/trgt/redo02.log
redo02.logをグループ2から削除するには、次のコマンドを発行します。
ALTER DATABASE DROP LOGFILE MEMBER '/disk1/oradata/trgt/redo02.log';
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;
オンラインREDOログ・グループのすべてのメンバーがメディア障害によって破損した場合には、障害の影響を受けたオンラインREDOログ・グループのタイプと、データベースのアーカイブ・モードによって、想定されるシナリオが異なります。
破損したオンラインREDOログ・グループが現行のアクティブなものである場合は、このオンラインREDOログ・グループがクラッシュ・リカバリで必要になります。非アクティブなものである場合は、クラッシュ・リカバリで必要とされません。
まず、破損したグループがアクティブか非アクティブかを確認します。
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
たとえば、次の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
INACTIVEステータスのオンラインREDOログ・グループのすべてのメンバーが破損した場合は、その非アクティブREDOログ・グループを破損させたメディアの問題を解決できるかどうかによって、手順が異なります。障害が一時的な場合は、問題を解決します。ログ・ライターは、必要な場合にREDOログ・グループを再利用できます。障害が永続的な場合は、破損した非アクティブのオンラインREDOログ・グループは最終的に、データベースの通常の実行を停止させます。この項の説明に従ってALTER DATABASE CLEAR LOGFILE文を発行し、破損したグループを手動で再初期化します。
データベースをオープンまたはクローズした状態で、非アクティブのREDOログ・グループを消去できます。手順は、破損したグループがアーカイブされているかどうかで異なります。
STARTUP MOUNT
2を消去するには、次の文を発行します。
ALTER DATABASE CLEAR LOGFILE GROUP 2;
アーカイブされていないREDOログを消去することによって、アーカイブせずに、ログを再利用できます。ログの中の最初の変更の前にファイルがオフライン化されておらず、ログの中の最後の変更前にバックアップが開始されている場合は、このアクションによってバックアップは使用できなくなります。このため、バックアップのリカバリのために消去されたログ・ファイルが必要となった場合は、このバックアップはリカバリできません。また、ログの欠落のため、バックアップからの完全リカバリも実行できません。
SQL> STARTUP MOUNT
UNARCHIVEDキーワードを使用してログを消去します。たとえば、ログ・グループ2を消去するには、次のSQL文を発行します。
SQL> ALTER DATABASE CLEAR LOGFILE UNARCHIVED GROUP 2;
消去されたログを使用してオンライン化する必要があるオフライン・データファイルが存在する場合は、UNRECOVERABLE DATAFILEキーワードが必要です。オンライン化するために必要なREDOが消去され、コピーもないため、そのデータファイルと、その表領域全体は削除する必要があります。たとえば、次のように入力します。
SQL> ALTER DATABASE CLEAR LOGFILE UNARCHIVED GROUP 2 UNRECOVERABLE DATAFILE;
% cp /disk1/oracle/dbs/*.dbf /disk2/backup
ALTER DATABASE文を使用して、データベースの制御ファイルをバックアップします。たとえば、次のように入力します。
SQL> ALTER DATABASE BACKUP CONTROLFILE TO '/oracle/dbs/cf_backup.f';
次の操作を実行できない場合、メディア障害によるI/Oエラーによって、ALTER DATABASE CLEAR LOGFILE文が失敗することがあります。
これらの場合には、ALTER DATABASE CLEAR LOGFILE文は（I/Oエラーを受け取る前に）、ログが消去され、アーカイブが必要なかったことを、制御ファイルに正しく通知します。CLEAR LOGFILE文が新しいREDOログ・ファイルを作成して0（ゼロ）を書き込もうとした段階でI/Oエラーが発生します。この事実はV$LOG.CLEARING_CURRENTに反映されます。
データベースがまだ実行中であり、消失したアクティブなREDOログが現行ログでない場合は、ALTER SYSTEM CHECKPOINT文を発行します。この文が正常に実行されると、アクティブなREDOログがアクティブでなくなるため、「非アクティブのオンラインREDOログ・グループの消失」の手順を実行できます。正常に実行されなかったか、またはデータベースが停止した場合は、アーカイブ・モードに応じて、この項のいずれかの手順を実行します。
現行ログとは、LGWRによって現在書込みが行われているログです。LGWRのI/Oが失敗すると、LGWRは終了し、インスタンスがクラッシュします。この場合には、バックアップをリストアし、不完全リカバリを実行し、RESETLOGSオプションを指定してデータベースをオープンする必要があります。
この例では、データベースのアーカイブ・モードはNOARCHIVELOGです。
% cp /disk2/backup/*.dbf $ORACLE_HOME/oradata/trgt/
STARTUP MOUNT
RECOVER DATABASE UNTIL CANCEL CANCEL
RESETLOGSオプションを使用してデータベースをオープンします。
ALTER DATABASE OPEN RESETLOGS;
SHUTDOWN IMMEDIATE
メディア障害が一時的な場合は、必要に応じてデータベースがグループを再利用できるように、問題を解決します。メディア障害が一時的なものでない場合には、次の手順を使用します。
この例では、データベースのアーカイブ・モードはARCHIVELOGです。
ALTER DATABASE RENAME FILE "/disk1/oradata/trgt/redo01.log" TO "/tmp/redo01.log"; ALTER DATABASE RENAME FILE "/disk1/oradata/trgt/redo01.log" TO "/tmp/redo02.log";
RESETLOGSオプションを使用してデータベースをオープンします。
ALTER DATABASE OPEN RESETLOGS;
オンラインREDOログの複数のグループが消失した場合には、リカバリの最も困難なログのリカバリ方法を使用します。リカバリが困難な順に示します。
データベースから誤って表を削除することは少なくありません。一般に、最も高速で簡単な解決方法は、フラッシュバック・ドロップ機能を使用して、表の削除を無効にする方法です。フラッシュバック表を使用できない場合（フラッシュバック・ドロップが無効になっている場合や表がPURGEオプションで削除された場合など）は、この項の手順を実行できます。
この項では、フラッシュバック・データベース機能が無効であるためにFLASHBACK DATABASEは使用できないことを想定しています。ただし、データベースの物理バックアップは存在します。可能であれば、ユーザー・エラーが発生したデータベースをオンラインのまま保ち、使用できるようにします。
データベース（データベースを構成するデータベース・ファイル）をオペレーティング・システムから削除する必要がある場合があります。たとえば、テスト・データベースを作成した後に、そのデータベースを使用しなくなった場合などがこれに当たります。SQL文DROP DATABASEを実行すると、データベースを削除できます。
たとえば、次のコマンドを入力します。
SQL> STARTUP RESTRICT FORCE MOUNT
たとえば、次のコマンドを入力します。
SQL> DROP DATABASE; # deletes all database files, both ASM and non-ASM
データベースがRAWディスクに配置されている場合、このコマンドではRAWディスクの実際の特殊ファイルを削除できません。
たとえば、次のコマンドを入力します。
% rm /backup/* /disk1/oradata/trgt/arch/*
|
 Copyright © 2003, 2008, Oracle Corporation. All Rights Reserved. |
|