31 ユーザー管理のリカバリの実行: 高度な例
Recovery Managerを必要としないユーザー管理のバックアップおよびリカバリ計画を使用する場合は、いくつかの一般的なメディア障害のシナリオからリカバリできます。
この章では、複数の一般的なメディア障害の例について説明します。ユーザー管理のバックアップおよびリカバリ計画(Recovery Managerを必要としない計画)を使用した場合に、各障害からリカバリする方法について説明します。
注意:
マルチテナント・コンテナ・データベースは、Oracle Database 20cにおいてサポートされている唯一のアーキテクチャです。ドキュメントの改訂中は、従来の用語が残っている可能性があります。ほとんどの場合、「データベース」と「非CDB」は、コンテキストに応じて、CDBまたはPDBを意味します。アップグレードなど、一部のコンテキストでは、「非CDB」は以前のリリースの非CDBを意味します。
31.1 現行の制御ファイルのサブセットが消失した場合の対応
永続的なメディア障害によってデータベースの1つ以上の制御ファイルが破損したが、メディア障害によって消失していない現行の制御ファイルが1つ以上ある場合は、次の手順でデータベースをリカバリします。
この項では、次の項目について説明します。
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がオンライン・ログに含まれている場合には、バックアップ制御ファイルをリストアし、リカバリ時にログを適用します。データベースをオープンするためには、変更を含むオンライン・ログのファイル名を指定する必要があります。リカバリ後に、 注意: 制御ファイルを再作成するときに、オンラインREDOログにアクセスできる場合は、リカバリ後に |
使用不可 |
現行 |
リカバリに必要なREDOがオンライン・ログに含まれている場合は、制御ファイルを再作成します。オンラインREDOログにはアクセスできないため、 |
使用可能 |
バックアップ |
バックアップ制御ファイルをリストアし、完全リカバリを実行し、 |
使用不可 |
バックアップ |
バックアップ制御ファイルをリストアし、不完全リカバリを実行し、 |
この項では、次の項目について説明します。
31.2.1 デフォルトの場所でのバックアップ制御ファイルを使用したリカバリ
可能であれば、元の場所に制御ファイルをリストアします。この方法では、初期化パラメータ・ファイルで制御ファイルの新しい場所を指定する必要はありません。
デフォルトの場所にバックアップ制御ファイルをリストアする手順
31.2.2 デフォルト以外の場所でのバックアップ制御ファイルを使用したリカバリ
メディアの損傷が重大なため、元の場所に制御ファイルをリストアできない場合は、サーバー・パラメータ・ファイルで制御ファイルの新しい場所を指定する必要があります。CONTROL_FILES
初期化パラメータで指定されたすべての場所に有効な制御ファイルが存在する必要があります。存在しない場合は、データベースをマウントできません。
デフォルト以外の場所に制御ファイルをリストアする手順
31.2.3 バックアップ制御ファイルを使用したデータファイルの追加を伴うリカバリ
バックアップ制御ファイルを使用したデータベースのリカバリが、CREATE
TABLESPACE
またはALTER
TABLESPACE
ADD
DATAFILE
操作を伴ってロールフォワードされる場合は、追加されたファイルにREDOレコードを適用するときにリカバリが停止し、ユーザーによるファイル名の確認が行われます。
たとえば、次の操作を順に行うとします。
-
データベースをバックアップします。
-
/disk1/oradata/trgt/test01.dbf
および/disk1/oradata/trgt/test02.dbf
というデータファイルを含む表領域を作成します。
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操作を伴うリカバリを実行する手順
31.2.4 バックアップ制御ファイルを使用した読取り専用表領域のリカバリ
読取り専用メディアまたは低速のメディア上に読取り専用表領域がある場合は、USING
BACKUP
CONTROLFILE
オプションを指定してリカバリを実行すると、エラーが発生したり、パフォーマンスが低下することがあります。この状況は、制御ファイルがバックアップされたときに表領域が読取り/書込みであったことをバックアップ制御ファイルが示している場合に発生します。この場合、メディア・リカバリでファイルへの書込みが試行されることがあります。読取り専用メディアの場合には、ファイルへの書込みができないことを告げるエラー・メッセージが発行されます。テープでバックアップされる階層ストレージ・システムなど、低速メディアの場合には、パフォーマンスが低下することがあります。
これらの問題を回避するには、バックアップではなく、現行の制御ファイルを使用して、データベースのリカバリを行います。バックアップ制御ファイルを使用する必要がある場合には、読取り専用表領域がメディア障害の影響を受けていなければ、この問題を回避できます。バックアップ制御ファイルを使用する場合には、読取り専用または低速メディアのリカバリに次の代替方法を使用できます。
-
バックアップ制御ファイルを使用してリカバリを実行する前に、読取り専用表領域のデータファイルをオフライン化し、メディア・リカバリ後に、ファイルをオンライン化します。
-
リカバリには正しいバージョンの制御ファイルを使用します。リカバリの完了時に表領域が読取り専用になる場合は、表領域が読取り専用であった時点の制御ファイルのバックアップを使用する必要があります。同様に、リカバリ後に表領域が読取り/書込みになる場合には、表領域が読取り/書込みであった時点の制御ファイルを使用する必要があります。
31.3 制御ファイルの再作成
永続的なメディア障害によってすべての制御ファイルが消失した場合は、すべてのオンラインREDOログ・メンバーが影響を受けていなければ、新しい制御ファイルを作成した後でデータベースをリカバリできます。リカバリ後にRESETLOGS
オプションを指定してデータベースをオープンする必要はありません。
制御ファイルのバックアップの有無および作成日時に応じて、CREATE
CONTROLFILE
文のテキストを生成する際に表31-2に示すオプションを使用できます。データベースに対する変更はalert_SID.logに記録されるため、どのオプションを選択するかを決定する際は、このログを確認してください。
表31-2 制御ファイルの作成のオプション
状況 | 対応 |
---|---|
データベースの最後の構造変更の後で |
トレース出力の |
データベースの構造変更を行う前に、最後の |
|
|
制御ファイルのコピーを使用してSQL出力を取得します。一時的なデータベース・インスタンスを作成し、バックアップ制御ファイルをマウントして、 |
|
|
注意:
デフォルトのUS7ASCII以外のキャラクタ・セットを使用している場合には、CREATE
CONTROLFILE
文の引数としてキャラクタ・セットを指定する必要があります。データベース・キャラクタ・セットは、起動時にアラート・ログに書き込まれます。また、キャラクタ・セット情報はBACKUP
CONTROLFILE
TO
TRACE
の出力にも記録されます。
制御ファイルを作成し、データベースをリカバリするには、次の手順を実行します。
-
データベースを
NOMOUNT
モードで起動します。たとえば、次のように入力します。STARTUP NOMOUNT
-
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';
制御ファイルを作成した後、インスタンスでデータベースがマウントされます。
-
データベースを通常どおりに(
USING
BACKUP
CONTROLFILE
句を指定せずに)リカバリします。RECOVER DATABASE
-
リカバリが終了した後、データベースをオープンします(
RESETLOGS
オプションは必要ありません)。ALTER DATABASE OPEN;
-
すぐに制御ファイルをバックアップします。次のSQL文は、
/backup/control01.dbf
にデータベースの制御ファイルをバックアップします。ALTER DATABASE BACKUP CONTROLFILE TO '/backup/control01.dbf' REUSE;
マルチテナント・コンテナ・データベースに制御ファイルを作成するには、次の手順を実行します。
- マルチテナント・コンテナ・データベース(CDB)がいずれのインスタンスでもマウントされていないことを確認します。
- SQL*Plusを開きます。
SYSDBA
権限を持つユーザーとしてrootに接続します。- 制御ファイルの作成およびデータベースのリカバリについては、前述の手順に従います。
関連項目:
「制御ファイルのトレース・ファイルへのバックアップ」および「バックアップが利用できない場合のデータファイルの再作成」を参照してください。
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
文に含まれていないが、データ・ディクショナリに存在する各ファイルについては、制御ファイル内にエントリが作成されます。これらのファイルには、MISSING
nnnnn
という名前が付けられます。この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を使用できないためです。
リカバリのためにデータファイルを再作成する手順
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管理者ガイド』を参照してください。
トランスポータブル表領域は、通常の表領域と同じように、リカバリ可能です。ただし、通常の表領域はバックアップなしにリカバリできますが、トランスポートされた表領域のリカバリには、トランスポートされたデータファイルの一貫性が保持されているバージョンが必要です。
トランスポータブル表領域をリカバリする手順
CREATE
TABLESPACE
操作を伴うリカバリの場合と同じように、トランスポータブル表領域の操作を伴うリカバリでもエラーORA-01244
が表示される場合があります。この場合は、「バックアップ制御ファイルを使用したデータファイルの追加を伴うリカバリ」の手順を使用して、名前のないファイルを正しい場所の名前に変更してください。
31.7 オンラインREDOログ・ファイルが消失した後のリカバリ
データベースのオンラインREDOログがメディア障害の影響を受けたときの正しいリカバリ手順は、特定の考慮事項によって異なります。
次の考慮事項があります。
-
オンラインREDOログの構成: ミラー化されているかいないか
-
メディア障害のタイプ: 一時的か永続的か
-
メディア障害の影響を受けたオンラインREDOログ・ファイルのタイプ: 現行、アクティブ、アーカイブされていない、または非アクティブ
次の表に、オンラインREDOログをリカバリする場合に重要になるV$LOG
のステータス情報を示します。
表31-3 V$LOGのSTATUS列
ステータス | 説明 |
---|---|
|
このオンラインREDOログは書き込まれたことがありません。 |
|
このオンラインREDOログはアクティブです。インスタンス・リカバリに必要です。また、現在書込みが行われているログです。REDOログはオープンまたはクローズです。 |
|
このオンラインREDOログはアクティブです。インスタンス・リカバリに必要です。ただし、現在書込みが行われているログではありません。ブロック・リカバリに使用されている可能性があります。また、アーカイブされる場合とされない場合があります。 |
|
このログは、 |
|
現在のログはクローズ・スレッドの消去中です。新規ログ・ヘッダーの書込みでのI/Oエラーなどの障害がスイッチで発生した場合、ログはこのステータスのままになります。 |
|
このログはインスタンス・リカバリに必要とされなくなりました。メディア・リカバリで使用される場合があります。アーカイブされる場合とされない場合があります。 |
31.7.1 多重オンラインREDOログ・グループの一部のメンバーが消失した後のリカバリ
多重オンラインREDOログ・グループのメンバーが消失したら、リカバリを実行できます。次の条件が満たされている場合、データベースは通常どおりに機能し続けます。
データベースのオンラインREDOログが多重化されている場合は、各オンラインREDOログ・グループの1つ以上のメンバーがメディア障害の影響を受けていなければ、データベースは通常どおりに機能し続けることができます。ただし、データベースのログ・ライターのトレース・ファイルおよびalert_
SID
.log
にエラー・メッセージが書き込まれます。
次のいずれかのアクションを実行して、多重オンラインREDOログ・グループのメンバー消失の問題を解決できます。
-
ハードウェアの問題が一時的な場合は、問題を解決します。ログ・ライター・プロセスは、問題が発生しなかった場合と同様に、以前は使用不可であったオンラインREDOログ・ファイルにアクセスします。
-
ハードウェアの問題が永続的な場合には、次の手順に従って、破損したメンバーを削除し、新しいメンバーを追加します。
注意:
新しく追加されたメンバーは、ログ・グループが再利用されるまでは、冗長性を提供しません。
31.7.2 オンラインREDOログ・グループのすべてのメンバーが消失した後のリカバリ
オンラインREDOログ・グループのすべてのメンバーがメディア障害によって破損した場合には、障害の影響を受けたオンラインREDOログ・グループのタイプと、データベースのアーカイブ・モードによって、想定されるシナリオが異なります。
破損したオンラインREDOログ・グループが現行のアクティブなものである場合は、このオンラインREDOログ・グループがクラッシュ・リカバリで必要になります。非アクティブなものである場合は、クラッシュ・リカバリで必要とされません。表31-4に、様々なリカバリ・シナリオの概要を示します。
表31-4 オンラインREDOログ・グループが消失した後のリカバリ
グループの状態 . . | 対応 | 対応 |
---|---|---|
非アクティブ |
クラッシュ・リカバリで必要ありません |
アーカイブされたグループまたはアーカイブされていないグループを消去します。 |
アクティブ |
クラッシュ・リカバリで必要です |
チェックポイントを発行してログを消去します。実行できない場合は、フラッシュバック・データベースを使用するか、またはバックアップをリストアし、使用可能な最新のREDOログの時点まで、不完全リカバリを実行する必要があります。 |
現行 |
現在書込みが行われているREDOログです |
ログを消去します。消去できない場合は、フラッシュバック・データベースを使用するか、またはバックアップをリストアし、使用可能な最新のREDOログの時点まで、不完全リカバリを実行する必要があります。 |
破損したグループがアクティブか非アクティブかを確認します。
31.7.2.1 非アクティブのオンラインREDOログ・グループの消失
INACTIVE
ステータスのオンラインREDOログ・グループのすべてのメンバーが破損した場合は、その非アクティブREDOログ・グループを破損させたメディアの問題を解決できるかどうかによって、手順が異なります。障害が一時的な場合は、問題を解決します。ログ・ライターは、必要な場合にREDOログ・グループを再利用できます。障害が永続的な場合は、破損した非アクティブのオンラインREDOログ・グループは最終的に、データベースの通常の実行を停止させます。この項の説明に従ってALTER DATABASE CLEAR LOGFILE
文を発行し、破損したグループを手動で再初期化します。
31.7.2.1.1 非アクティブのアーカイブREDOの消去
データベースをオープンまたはクローズした状態で、非アクティブのREDOログ・グループを消去できます。手順は、破損したグループがアーカイブされているかどうかで異なります。
アーカイブされている、非アクティブのオンラインREDOログ・グループを消去する手順
31.7.2.1.2 非アクティブのアーカイブされていないREDOの消去
アーカイブされていないREDOログを消去することによって、アーカイブせずに、ログを再利用できます。ログの中の最初の変更の前にファイルがオフライン化されておらず、ログの中の最後の変更前にバックアップが開始されている場合は、このアクションによってバックアップは使用できなくなります。このため、バックアップのリカバリのために消去されたログ・ファイルが必要となった場合は、このバックアップはリカバリできません。アーカイブされていないREDOログを消去すると、ログの欠落のため、バックアップからの完全リカバリを実行できなくなります。
アーカイブされていない、非アクティブのオンラインREDOログ・グループを消去する手順
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.8 フラッシュバック機能を使用しない、削除された表のリカバリ
データベースから誤って表を削除することは少なくありません。一般に、最も高速で簡単な解決方法は、フラッシュバック・ドロップ機能を使用して、表の削除を無効にする方法です。フラッシュバック表を使用できない場合(フラッシュバック・ドロップが無効になっている場合や表がPURGE
オプションで削除された場合など)は、この項の手順を実行できます。
この項では、フラッシュバック・データベース機能が無効であるためにFLASHBACK
DATABASE
コマンドは使用できないことを想定しています。ただし、データベースの物理バックアップは存在します。可能であれば、ユーザー・エラーが発生したデータベースをオンラインのまま保ち、使用できるようにします。
注意:
強力な権限を適切なユーザーのみに付与することによって、リカバリを必要とするユーザー・エラーを減らすことができます。
誤って削除された表をリカバリする手順
関連項目:
Oracle Data Pumpの詳細は、『Oracle Databaseユーティリティ』を参照してください。
31.9 SQL*Plusでのデータベースの削除
データベース(データベースを構成するデータベース・ファイル)をオペレーティング・システムから削除する必要がある場合があります。たとえば、テスト・データベースを作成した後に、そのデータベースを使用しなくなった場合などがこれに当たります。SQL文DROP
DATABASE
を実行すると、データベースを削除できます。
関連項目:
同等の機能を持つRMANコマンドDROP
DATABASE
の使用方法については、「データベースの削除」を参照してください。
SQL*Plusでデータベースを削除する手順