この章では、複数の一般的なメディア障害の例について説明します。ユーザー管理のバックアップおよびリカバリ計画(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
注意: トレース・ファイルおよびアラート・ログの場所を特定する最も簡単な方法は、SQL問合せSELECT NAME, VALUE FROM V$DIAG_INFO を実行する方法です。 |
制御ファイルを再度アクセス可能にするまでは、データベースをマウントしてオープンすることはできません。バックアップ制御ファイルをリストアする場合は、RESETLOGS
オプションを使用してデータベースをオープンする必要があります。
表30-1に示すように、制御ファイルのリストアの手順は、オンラインREDOログを利用できるかどうかによって異なります。
表30-1 制御ファイルが消失した場合のシナリオ
オンライン・ログのステータス | データファイルのステータス | リストア手順 |
---|---|---|
使用可能 |
現行 |
リカバリに必要なREDOがオンライン・ログに含まれている場合には、バックアップ制御ファイルをリストアし、リカバリ時にログを適用します。データベースをオープンするためには、変更を含むオンライン・ログのファイル名を指定する必要があります。リカバリ後に、 注意: 制御ファイルを再作成するときに、オンラインREDOログにアクセスできる場合は、リカバリ後に |
使用不可 |
現行 |
リカバリに必要なREDOがオンライン・ログに含まれている場合は、制御ファイルを再作成します。オンライン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
プロンプトで指示されたアーカイブ・ログを適用します。必要なアーカイブ・ログがないことを告げる別のメッセージが表示された場合には、必要な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がオンライン・ログの中に含まれているときには、オンライン・ログを適用せずにデータベースをオープンすることはできません。オンライン・ログにアクセスできない場合は、「制御ファイルの再作成」に示す手順を実行して、制御ファイルを再作成する必要があります。
リカバリが終了した後、RESETLOGS
オプションを指定してデータベースをオープンします。
SQL> ALTER DATABASE OPEN RESETLOGS;
メディアの損傷が重大なため、元の場所に制御ファイルをリストアできない場合は、サーバー・パラメータ・ファイルで制御ファイルの新しい場所を指定する必要があります。CONTROL_FILES
初期化パラメータで指定されたすべての場所に有効な制御ファイルが存在する必要があります。存在しない場合は、データベースをマウントできません。
デフォルト以外の場所に制御ファイルをリストアする手順
「デフォルトの場所でのバックアップ制御ファイルを使用したリカバリ」の手順に従いますが、手順2の後に、次の手順を追加します。
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
の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操作を伴うリカバリを実行する手順
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
名前のないファイルが複数存在する場合は、次のいずれかの方法を使用して、どの名前なしファイルがどのデータファイルに対応するかを確認します。
alert_
SID
.log
を参照し、名前のない各ファイルの元のファイルの場所に関するメッセージを確認します。
エラー・メッセージおよびV$DATAFILE
から、名前のない各ファイルの元のファイルの場所を導出します。名前のないファイルは、エラー・メッセージの中の同じファイル番号のファイルに対応します。
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
文のテキストを生成する際に表30-2
に示すオプションを使用できます。データベースに対する変更はalert_SID.logに記録されるため、どのオプションを選択するかを決定する際は、このログを確認してください。
表30-2 制御ファイルの作成のオプション
状況 . . | 説明 . . |
---|---|
データベースの最後の構造変更の後で |
トレース出力の |
データベースの構造変更を行う前に、最後の |
|
|
制御ファイルのコピーを使用してSQL出力を取得します。一時的なデータベース・インスタンスを作成し、バックアップ制御ファイルをマウントして、 |
|
|
注意: デフォルトのUS7ASCII以外のキャラクタ・セットを使用している場合には、CREATE CONTROLFILE 文の引数としてキャラクタ・セットを指定する必要があります。データベース・キャラクタ・セットは、起動時にアラート・ログに書き込まれます。また、キャラクタ・セット情報はBACKUP CONTROLFILE TO TRACE の出力にも記録されます。 |
データベースをNOMOUNT
モードで起動します。たとえば、次のように入力します。
STARTUP NOMOUNT
NORESETLOGS
オプションを指定して、CREATE
CONTROLFILE
文で制御ファイルを作成します(オプションについては表30-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;
次の条件を満たす場合は、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;
リカバリに現行の制御ファイルまたはバックアップ制御ファイルを使用できない場合は、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
文から除外し、データベースをオープンした後で追加する必要があります。
データファイルが破損し、ファイルのバックアップが利用できない場合でも、次の条件を満たしていれば、データファイルをリカバリできます。
元のデータファイルの作成後に書き込まれたすべてのアーカイブ・ログ・ファイルを利用できる
制御ファイルに破損したファイルの名前が含まれている(制御ファイルは現行か、破損したデータファイルがデータベースに追加された後で作成されたバックアップである)
注意: ALTER DATABASE 文のCREATE DATAFILE 句を使用してSYSTEM 表領域のデータファイルを再作成することはできません。これは、必要なREDOを使用できないためです。 |
リカバリのためにデータファイルを再作成する手順
新しい空のデータファイルを作成して、対応するバックアップのない、破損したデータファイルと置き換えます。たとえば、データファイル/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 を使用して作成された表または索引の破損が許容できない場合は、リカバリ不能な表または索引を作成した後で、バックアップを作成します。 |
メディア・リカバリを実行する場合、表または索引の一部が通常どおりに作成され、その他がNOLOGGING
オプションを使用して作成されているときは、RECOVER
操作を行うと、NOLOGGING
オブジェクトに論理的に破損しているというマークが付けられます。リカバリ不能なオブジェクトにアクセスを試みると、ORA-01578
エラー・メッセージが戻されます。NOLOGGING
オブジェクトを削除し、必要に応じて再作成します。
NOLOGGING
オプションを使用して表を作成し、その表の索引をLOGGING
オプションを使用して作成できるため、メディア・リカバリの実行後、索引には論理的に破損しているというマークが付けられません。ただし、表はリカバリ不能であるため(リカバリ後に破損しているというマークが付けられます)、索引は破損ブロックをポイントします。索引を削除し、必要に応じて表および索引を再作成する必要があります。
関連項目: データベースへのNOLOGGINGの影響の詳細は、『Oracle Data Guard概要および管理』 を参照してください。 |
Oracle Databaseのトランスポータブル表領域機能を使用すると、ユーザーは表領域のセットを1つのデータベースから別のデータベースにトランスポートできます。表領域をデータベースにトランスポートすることは、ロードされたデータを使用して表領域を作成することに似ています。この機能を使用することには、次の理由でメリットがあります。
データファイルのコピーとメタデータの統合のみが行われるため、データ・ポンプ・エクスポートまたはSQL*Loaderユーティリティを使用した場合より高速です。
索引データを移動できるため、索引を再作成する必要がありません。
関連項目: トランスポータブル表領域機能の使用方法の詳細は、『Oracle Database管理者ガイド』を参照してください。 |
トランスポータブル表領域は、通常の表領域と同じように、リカバリ可能です。ただし、通常の表領域はバックアップなしにリカバリできますが、トランスポートされた表領域のリカバリには、トランスポートされたデータファイルの一貫性が保持されているバージョンが必要です。
トランスポータブル表領域をリカバリする手順
データベースがオープンしている場合は、トランスポートされた表領域をオフライン化します。たとえば、users
表領域をリカバリする場合は、次の文を発行します。
ALTER TABLESPACE users OFFLINE IMMEDIATE;
オペレーティング・システム・ユーティリティを使用して、トランスポートされたデータファイルのバックアップをリストアします。このバックアップは、トランスポートされたデータファイルの最初のバージョンでも、表領域がトランスポートされた後で作成されたバックアップでもかまいません。たとえば、次のように入力します。
% cp /backup/users.dbf $ORACLE_HOME/oradata/trgt/users01.dbf
表領域を通常どおりにリカバリします。たとえば、次のように入力します。
RECOVER TABLESPACE users
CREATE
TABLESPACE
操作を伴うリカバリの場合と同じように、トランスポータブル表領域の操作を伴うリカバリでもエラーORA-01244
が表示される場合があります。この場合は、「バックアップ制御ファイルを使用したデータファイルの追加を伴うリカバリ」の手順を使用して、名前のないファイルを正しい場所の名前に変更してください。
データベースのオンラインREDOログがメディア障害の影響を受けたときの正しいリカバリ手順は、次の考慮事項によって異なります。
オンラインREDOログの構成: ミラー化されているかいないか
メディア障害のタイプ: 一時的か永続的か
メディア障害の影響を受けたオンラインREDOログ・ファイルのタイプ: 現行、アクティブ、アーカイブされていない、または非アクティブ
表30-3に、オンラインREDOログをリカバリする場合に重要になるV$LOG
のステータス情報を示します。
表30-3 V$LOGのSTATUS列
ステータス | 説明 |
---|---|
|
このオンラインREDOログは書き込まれたことがありません。 |
|
このオンラインREDOログはアクティブです。インスタンス・リカバリに必要です。また、現在書込みが行われているログです。REDOログはオープンまたはクローズです。 |
|
このオンラインREDOログはアクティブです。インスタンス・リカバリに必要です。ただし、現在書込みが行われているログではありません。ブロック・リカバリに使用されている可能性があります。また、アーカイブされる場合とされない場合があります。 |
|
このログは、 |
|
現在のログはクローズ・スレッドの消去中です。新しいログ・ヘッダーへの書込み時のI/Oエラーなど、なんらかのスイッチの障害が発生した場合には、ログがこのステータスのままになることがあります。 |
|
このログはインスタンス・リカバリに必要とされなくなりました。メディア・リカバリで使用される場合があります。アーカイブされる場合とされない場合があります。 |
多重オンラインREDOログ・グループのメンバーが消失したら、リカバリを実行できます。次の条件が満たされている場合、データベースは通常どおりに機能し続けます。
データベースのオンラインREDOログが多重化されている場合は、各オンラインREDOログ・グループの1つ以上のメンバーがメディア障害の影響を受けていなければ、データベースは通常どおりに機能し続けることができます。ただし、データベースのログ・ライターのトレース・ファイルおよびalert_
SID
.log
にエラー・メッセージが書き込まれます。
次のいずれかのアクションを実行して、多重オンラインREDOログ・グループのメンバー消失の問題を解決できます。
ハードウェアの問題が一時的な場合は、問題を解決します。ログ・ライター・プロセスは、問題が発生しなかった場合と同様に、以前は使用不可であったオンラインREDOログ・ファイルにアクセスします。
ハードウェアの問題が永続的な場合には、次の手順に従って、破損したメンバーを削除し、新しいメンバーを追加します。
注意: 新しく追加されたメンバーは、ログ・グループが再利用されるまでは、冗長性を提供しません。 |
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ログ・グループがクラッシュ・リカバリで必要になります。非アクティブなものである場合は、クラッシュ・リカバリで必要とされません。表30-4に、様々なリカバリ・シナリオの概要を示します。
表30-4 オンライン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
次のいずれかの処理を実行します。
影響を受けたグループが非アクティブな場合には、「非アクティブのオンラインREDOログ・グループの消失」の手順に従ってください。
影響を受けたグループがアクティブな場合(前述の例のような場合)には、「アクティブなオンラインREDOログ・グループの消失」の手順に従ってください。
INACTIVE
ステータスのオンラインREDOログ・グループのすべてのメンバーが破損した場合は、その非アクティブREDOログ・グループを破損させたメディアの問題を解決できるかどうかによって、手順が異なります。障害が一時的な場合は、問題を解決します。ログ・ライターは、必要な場合にREDOログ・グループを再利用できます。障害が永続的な場合は、破損した非アクティブのオンラインREDOログ・グループは最終的に、データベースの通常の実行を停止させます。この項の説明に従ってALTER DATABASE CLEAR LOGFILE
文を発行し、破損したグループを手動で再初期化します。
データベースをオープンまたはクローズした状態で、非アクティブのREDOログ・グループを消去できます。手順は、破損したグループがアーカイブされているかどうかで異なります。
アーカイブされている、非アクティブのオンラインREDOログ・グループを消去する手順
データベースが停止している場合は、新しいインスタンスを起動してデータベースをマウントします。
STARTUP MOUNT
破損したログ・グループを再初期化します。たとえば、REDOログ・グループ2
を消去するには、次の文を発行します。
ALTER DATABASE CLEAR LOGFILE GROUP 2;
アーカイブされていないREDOログを消去することによって、アーカイブせずに、ログを再利用できます。ログの中の最初の変更の前にファイルがオフライン化されておらず、ログの中の最後の変更前にバックアップが開始されている場合は、このアクションによってバックアップは使用できなくなります。このため、バックアップのリカバリのために消去されたログ・ファイルが必要となった場合は、このバックアップはリカバリできません。アーカイブされていないREDOログを消去すると、ログの欠落のため、バックアップからの完全リカバリを実行できなくなります。
アーカイブされていない、非アクティブのオンラインREDOログ・グループを消去する手順
データベースが停止している場合は、新しいインスタンスを起動してデータベースをマウントします。
SQL> STARTUP MOUNT
UNARCHIVED
キーワードを使用してログを消去します。
たとえば、ログ・グループ2
を消去するには、次のSQL文を発行します。
SQL> ALTER DATABASE CLEAR UNARCHIVED LOGFILE GROUP 2;
消去されたログを使用してオンライン化する必要があるオフライン・データファイルが存在する場合は、UNRECOVERABLE
DATAFILE
キーワードが必要です。データファイルをオンライン化するために必要なREDOログが消去され、そのコピーもないため、そのデータファイルを削除する必要があります。たとえば、次のように入力します。
SQL> ALTER DATABASE CLEAR UNARCHIVED LOGFILE 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
文が失敗することがあります。
現在構成されているREDOログのファイル名を基にREDOログ・ファイルを再作成し、REDOログ・ファイルを代替メディアへ再配置する
現在構成されているログ・ファイル名が(メディア障害などによって)無効または使用できなくなったため、その名前を再利用してREDOログ・ファイルを再作成する
これらの場合には、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
です。
NOARCHIVELOGモードでアクティブなオンライン・ログ・グループが消失した場合にリカバリを実行する手順
一貫性のあるデータベース全体(データファイルおよび制御ファイル)のバックアップからデータベースをリストアします。たとえば、次のように入力します。
% cp /disk2/backup/*.dbf $ORACLE_HOME/oradata/trgt/
データベースをマウントします。
STARTUP MOUNT
オンラインREDOログはバックアップされないため、データファイルおよび制御ファイルとともにリストアすることはできません。データベースでオンラインREDOログをリセットできるように、まず不完全リカバリを行う必要があります。
RECOVER DATABASE UNTIL CANCEL CANCEL
RESETLOGS
オプションを使用してデータベースをオープンします。
ALTER DATABASE OPEN RESETLOGS;
一貫性のある状態でデータベースを停止します。たとえば、次のように入力します。
SHUTDOWN IMMEDIATE
データベース全体のバックアップを実行します。
メディア障害が一時的な場合は、必要に応じてデータベースがグループを再利用できるように、問題を解決します。メディア障害が一時的なものでない場合には、次の手順を使用します。
この例では、データベースのアーカイブ・モードはARCHIVELOG
です。
ARCHIVELOGモードでアクティブなオンラインREDOログ・グループが消失した場合にリカバリを実行する手順
不完全メディア・リカバリを開始して、破損したログの前のログまでリカバリします。
消失した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";
RESETLOGS
オプションを使用してデータベースをオープンします。
ALTER DATABASE OPEN RESETLOGS;
注意: 不完全リカバリのエンドポイントから現在までの間に実行されたすべての更新を、再度実行する必要があります。 |
データベースから誤って表を削除することは少なくありません。一般に、最も高速で簡単な解決方法は、フラッシュバック・ドロップ機能を使用して、表の削除を無効にする方法です。フラッシュバック表を使用できない場合(フラッシュバック・ドロップが無効になっている場合や表がPURGE
オプションで削除された場合など)は、この項の手順を実行できます。
この項では、フラッシュバック・データベース機能が無効であるためにFLASHBACK
DATABASE
コマンドは使用できないことを想定しています。ただし、データベースの物理バックアップは存在します。可能であれば、ユーザー・エラーが発生したデータベースをオンラインのまま保ち、使用できるようにします。
注意: 強力な権限を適切なユーザーのみに付与することによって、リカバリを必要とするユーザー・エラーを減らすことができます。 |
この手順の後の手順でエラーが発生した場合に備えて、既存のデータベースのすべてのデータファイルをバックアップします。
データベースの部分バックアップを代替の場所にリストアします。最低限、次のものをリストアします。
SYSTEM
表領域およびSYSAUX
表領域
UNDOセグメントまたはロールバック・セグメントを含む表領域
取得するデータが含まれている自己完結型の表領域
リストアされたバックアップ制御ファイルを使用して、表が削除された直前まで、このバックアップの不完全リカバリを実行します。
データ・ポンプ・エクスポートを使用して、データベースの一時的にリストアされたバージョンから、消失したデータをエクスポートします。この例では、誤って削除された表がエクスポートされます。
注意: システム監査オプションがエクスポートされます。 |
データ・ポンプ・インポート・ユーティリティを使用して、本番データベースにデータをインポートします。
領域の節約のためにデータベースの一時コピーのファイルを削除します。
関連項目: Oracle Data Pumpの詳細は、『Oracle Databaseユーティリティ』を参照してください。 |
データベース(データベースを構成するデータベース・ファイル)をオペレーティング・システムから削除する必要がある場合があります。たとえば、テスト・データベースを作成した後に、そのデータベースを使用しなくなった場合などがこれに当たります。SQL文DROP
DATABASE
を実行すると、データベースを削除できます。
SQL*Plusでデータベースを削除する手順
管理者権限を使用してターゲット・データベースに接続した後、データベースがマウントされているか、または制限モードでユーザーが接続していない状態でオープンしていることを確認します。
たとえば、次のコマンドを入力します。
SQL> STARTUP RESTRICT FORCE MOUNT
データファイルおよび制御ファイルを、オペレーティング・システムから削除します。サーバー・パラメータ・ファイル(SPFILE)を使用している場合は、それも削除されます。
たとえば、次のコマンドを入力します。
SQL> DROP DATABASE; # deletes all database files, both ASM and non-ASM
データベースがRAWディスクに配置されている場合、このコマンドではRAWディスクの実際の特殊ファイルを削除できません。
オペレーティング・システム・ユーティリティを使用して、データベースに関連するすべてのバックアップおよびアーカイブ・ログを削除します。
たとえば、LinuxおよびUnixでは、次のコマンドを入力します。
% rm /backup/* /disk1/oradata/trgt/arch/*