障害ケース一覧
本番機での回復テスト実行の際に、以下の表にある障害ケースを擬似的に起こす。
|
Case
No.
|
障害ケース
|
|
1
|
SYSTEM表領域のデータファイルの消失
|
|
2
|
ロールバックセグメントを持たないSYSTEM表領域以外のデータファイルの消失
|
|
3
|
ロールバックセグメントを持つSYSTEM表領域以外のデータファイルの消失
|
|
4
|
未アーカイブオンラインREDOログファイルの消失
|
|
5
|
バックアップされた制御ファイルを使用した回復処理
|
|
6
|
REDOログ・ファイルの回復処理
|
ただし上表の障害ケースは、一般的に（比較的現実にあるいは頻繁に）起こりうるケースのみ列挙している。
特殊な状況での回復手順（例えばデータベースのRESETLOGSオプション付き起動をはさんでのリカバリー等）は対象にしていない。
なお、この手順書の障害ケースがすべてを網羅しているわけではなく、また実際の障害発生時にはこれらの障害ケースが複合的に発生する可能性が高い。
評価機上で定期的に、バックアップ＆リカバリーのテストを実施することを強く推奨する。
また、本手順書に従い回復処理を実行したとしても、すべての障害に対応できるとは限らない。ORACLEの障害は様々なパターンがあるので、やはり定期的にテストを実行し慣れておくことが必要である。
想定障害ケースとそのリカバリー手順について
このレポートには、障害事例として挙げた数パターンと同様の（あるいは近い）状況を引き起こし、リカバリー手順を実際に行ってみた結果が記載されている。
各ケースごとに、「説明」「障害状況」「解決方法」「評価」のセクションが設けられている。
テスト環境で使用するインスタンス名は、inst1とする。
レポート内のORACLEリカバリーイメージ中の文字化けについて
原因は不明だが、通常通り一度のCONNECTによりコマンドを発行すると、ORACLEからのその戻りメッセージが以下のように文字化け（“?????”部分）を起こす。
SQL>
recover
database until cancel;
ORA-00279:
?? 59877344(04/04/2001
10:21:10???)????????
1??????
ORA-00289:
????????????: /vol1/database/orcl/arch01/arch_1_15.log
ORA-00280:
?? 59877344(???? 1)????? 15???????
ログの指定:
{<RET>=suggested | filename | AUTO | CANCEL}
cancel
ORA-01547:
??: RECOVER????????OPEN RESETLOGS???????????????
ORA-01194:
???? 1??????????????????????????
ORA-01110:
???????? 1 : /vol1/database/orcl/system/inst1_sys.dbf
ORA-01112:
??????????????????????
この文字化けを解消するための方法として、再度CONNECTしなおすと正常に日本語が表示されるようになるようである。
SQL>
recover
database until cancel; ← 同セッション内で再度CONNECTをしなおす。
ORA-00279:
変更 59877344(04/04/2001 10:21:10で生成)にはスレッド番号
1が必要です。
ORA-00289:
検討すべきログ・ファイル: /vol1/database/orcl/arch01/arch_1_15.log
ORA-00280:
変更 59877344(スレッド 1)は順序番号 15に存在します。
ログの指定:
{<RET>=suggested | filename | AUTO | CANCEL}
cancel
ORA-01547:
警告: RECOVERは成功しましたがOPEN
RESETLOGSが次のエラーを受け取りました。
ORA-01194:
ファイル 1は一貫した状態にするためにさらにリカバリが必要です。
ORA-01110:
データ・ファイル 1 : /vol1/database/orcl/system/inst1_sys.dbf
ORA-01112:
メディアのリカバリ処理が開始されていません。
Case 01
|
SYSTEM表領域のデータファイルの消失
|
|
説明
|
|
SYSTEM表領域のデータファイルのような重要なデータファイルが消失した場合は、回復処理で使用できるオプションが限られている。
|
|
障害状況
|
|
ディスクがクラッシュし、ディスク上のSYSTEM表領域のデータファイルが消失した。
|
|
解決方法
|
|
通常のデータファイルはオフライン状態でもデータベースは起動できるが、SYSTEM表領域に所属しているデータファイルは例外である。この場合、最新のオンラインあるいはオフラインバックアップからSYSTEMのデータファイルをリストアし、データベースの回復処理を実行するしか解決方法はない。
ディスクのクラッシュ等によってデータファイルがいくつか破損した場合、破損したすべてのデータファイルをオンラインあるいはオフラインバックアップからリストアする必要があることに注意すること。
データベースをオープンするには、データベースをマウントして、RECOVER DATABASEコマンドを実行する必要がある。
|
|
評価
|
|
評価実施日
|
|
評価実施機
|
test
|
|
事前準備：
1.
テストのために数回ログ・スイッチをしておく。
2. SYSTEM表領域に属するデータファイルを削除する。
rm /vol1/database/orcl/system/inst1_sys.dbf
《 重要 》
回復処理の際に、障害個所を探し当てるために以下の手順を実行する。
以下の手順を踏まなければ、正確な障害個所を把握することはできない！
① アラート・ファイルを確認する。
ORACLEデータベースに何か障害が発生した場合は、まずアラート・ファイルの内容を確認すること。
このファイルには障害の情報の他に、データベースの構成に影響を与えるようなタスク（ALTERコマンドによる変更等）も記録されている。
このテスト環境では、アラート・ファイルは以下の場所に保存されている。
/vol1/database/orcl/admin/bdump/alert_inst1.log
② トレース・ファイルを確認する。
上記①と同じ場所に、トレース・ファイルも格納されている。各プロセス（DBWR、ARCH、LGWR、SMON等）ごとにファイルが生成されているので、最新の日付のものの内容を確認する。
③ 動的パフォーマンス表を検索する。
- V$DATAFILEでファイルの位置、ファイル番号、状態を確認する。
SQL> select
name, file#, status from v$datafile;
- V$RECOVER_FILEでリカバリーが必要なファイルを確認する。
SQL> select
* from v$recover_file;
- V$RECOVERY_FILE_STATUSでリカバリーが必要なファイルを確認する。
SQL> select
* from v$recovery_file_status;
④ OSプロンプトからoerrコマンド（ORACLEユーティリティー）を実行し、エラー番号より障害内容を確認する（このユーティリティーの使用方法は、後述「oerrコマンドによるエラー内容の確認」を参照のこと）。
・
SYSTEM表領域に属するデータファイルに障害がある状態で、データベースをオープンしようとするとエラーが表示され起動できない。
SQL> startup
pfile=/vol1/database/orcl/admin/pfile/initinst1.ora
ORACLEインスタンスが起動しました。
Total System Global Area 1314236540 bytes
Fixed Size
116860 bytes
Variable Size
125943808 bytes
Database Buffers
1187840000 bytes
Redo Buffers
335872 bytes
データベースがマウントされました。
ORA-01157: ???????? 1???/?????????DBWR???????????????????
ORA-01110: ???????? 1 : /vol1/database/orcl/system/inst1_sys.dbf
・
SYSTEM表領域はオンラインでは回復処理ができないため、一度shutdownしマウント状態までデータベースを起動しなおす。
SQL> startup
mount pfile=/vol1/database/orcl/admin/pfile/initinst1.ora
ORACLEインスタンスが起動しました。
Total System Global Area 1314236540 bytes
Fixed Size
116860 bytes
Variable Size 125943808 bytes
Database Buffers
1187840000 bytes
Redo Buffers
335872 bytes
データベースがマウントされました。
・
データベースをマウント状態にし、RECOVER
DATABASEを実行する。
SQL> recover
database
ORA-00279: 変更 59857249(04/04/2001 09:18:49で生成)にはスレッド番号
1が必要です。
ORA-00289: 検討すべきログ・ファイル: /vol1/database/orcl/arch01/arch_1_10.log
ORA-00280: 変更 59857249(スレッド 1)は順序番号 10に存在します。
ログの指定: {<RET>=suggested | filename | AUTO | CANCEL}
auto
ORA-00279: 変更 59857294(04/04/2001 17:45:58で生成)にはスレッド番号
1が必要です。
ORA-00289: 検討すべきログ・ファイル: /vol1/database/orcl/arch01/arch_1_11.log
ORA-00280: 変更 59857294(スレッド 1)は順序番号 11に存在します。
ORA-00278: ログ・ファイル
/vol1/database/orcl/arch01/arch_1_10.logはこのリカバリでは必要なくなりました。
ORA-00279: 変更 59857295(04/04/2001 17:46:06で生成)にはスレッド番号
1が必要です。
ORA-00289: 検討すべきログ・ファイル: /vol1/database/orcl/arch01/arch_1_12.log
ORA-00280: 変更 59857295(スレッド 1)は順序番号 12に存在します。
ORA-00278: ログ・ファイル
/vol1/database/orcl/arch01/arch_1_11.logはこのリカバリでは必要なくなりました。
ORA-00279: 変更 59857296(04/04/2001 17:46:13で生成)にはスレッド番号
1が必要です。
ORA-00289: 検討すべきログ・ファイル: /vol1/database/orcl/arch01/arch_1_13.log
ORA-00280: 変更 59857296(スレッド 1)は順序番号 13に存在します。
ORA-00278: ログ・ファイル
/vol1/database/orcl/arch01/arch_1_12.logはこのリカバリでは必要なくなりました。
ログが適用されました。
メディア・リカバリが完了しました。
・
データベースの回復処理が完了したら、オープン状態にする。
SQL> alter
database open;
データベースが変更されました。
|
|
備考
|
|
|
|
|
|
|
|
Case 02
|
ロールバックセグメントを持たないSYSTEM表領域以外のデータファイルの消失
|
|
説明
|
|
ロールバックセグメントが格納されていないような、SYSTEM表領域以外のデータファイルが消失した場合、たくさんのオプションの中から回復方法を選択できる。
ここでは以下の3つの方法を評価することにする。
1. データベースの回復
2. データファイルの回復
3. 表領域の回復
|
|
障害状況
|
|
ディスクがクラッシュし、ユーザーデータ表領域に格納されていたデータファイルの1つが消失した。
この表領域にはロールバックセグメントは1つも格納されていない。
|
|
解決方法
|
|
SYSTEM表領域以外のデータファイルが消失した場合、そのデータファイルを手動で回復するための方法は3つある。RECOVER DATABASEコマンドを使用する場合は、データベースをオープン状態ではなく、マウント状態にする必要がある。つまり、オフラインの回復処理を実行する必要がある。
RECOVER DATAFILEコマンドを使用する場合、該当するデータファイルはオフラインにしておく必要があるが、データベースはオープン状態かマウント状態のどちらでもかまわない。
RECOVER TABLESPACEコマンドを使用する場合は、該当する表領域をオフライン状態にし、データベースをオープン状態にする必要がある。
|
|
評価
|
|
評価実施日
|
2003/**/**
|
評価実施機
|
test
|
|
事前準備：
1. 擬似障害を発生させる。
擬似障害を起こすために、マニュアルでデータファイルを削除する。
rm /vol1/database/orcl/data01/inst1_data07.dbf
2. データベースをshutdownする。
データファイルを削除した後で、データベースをshutdownしようとすると以下のようなエラーが発生し、shutdownできない。
SQL> shutdown
ORA-01116: データベース・ファイル 12のオープンでエラーが発生しました。
ORA-01110: データ・ファイル 12 : /vol1/database/orcl/data01/inst1_data07.dbf
ORA-27041: ファイルをオープンできません。
IBM AIX RISC System/6000 Error: 2: No such file or directory
Additional information: 3
《 重要 》
回復処理の際に、障害個所を探し当てるために以下の手順を実行する。
以下の手順を踏まなければ、正確な障害個所を把握することはできない！
① アラート・ファイルを確認する。
ORACLEデータベースに何か障害が発生した場合は、まずアラート・ファイルの内容を確認すること。
このファイルには障害の情報の他に、データベースの構成に影響を与えるようなタスク（ALTERコマンドによる変更等）も記録されている。
このテスト環境では、アラート・ファイルは以下の場所に保存されている。
/vol1/database/orcl/admin/bdump/alert_inst1.log
② トレース・ファイルを確認する。
上記①と同じ場所に、トレース・ファイルも格納されている。各プロセス（DBWR、ARCH、LGWR、SMON等）ごとにファイルが生成されているので、最新の日付のものの内容を確認する。
③ 動的パフォーマンス表を検索する。
- V$DATAFILEでファイルの位置、ファイル番号、状態を確認する。
SQL> select
name, file#, status from v$datafile;
- V$RECOVER_FILEでリカバリーが必要なファイルを確認する。
SQL> select
* from v$recover_file;
- V$RECOVERY_FILE_STATUSでリカバリーが必要なファイルを確認する。
SQL> select
* from v$recovery_file_status;
④ OSプロンプトからoerrコマンド（ORACLEユーティリティー）を実行し、エラー番号より障害内容を確認する（このユーティリティーの使用方法は、後述「oerrコマンドによるエラー内容の確認」を参照のこと）。
方法１：データファイルの回復
・
消失したデータファイルを、オフラインまたはオンライン・バックアップから復元する。
・
データファイルの回復はオンラインでもオフラインも可能であるが、オンラインでの回復を実行する場合は該当するデータファイルをオフライン状態にしなければならない。
SQL> shutdown
abort
ORACLEインスタンスがシャットダウンされました。
・
RECOVER DATAFILEを実行する（データベースはマウントかオープン状態）。
SQL> startup
mount pfile=/vol1/database/orcl/admin/pfile/initinst1.ora
ORACLEインスタンスが起動しました。
Total System Global Area 1314236540 bytes
Fixed Size
116860 bytes
Variable Size
125943808 bytes
Database Buffers
1187840000 bytes
Redo Buffers 335872
bytes
データベースがマウントされました。
・
RECOVER DATAFILEを実行し、障害が起こったデータファイルのリカバリーを実行する。ログの指定は通常はAUTOで良い。
SQL> recover
datafile '/vol1/database/orcl/data01/inst1_data07.dbf'
ORA-00279: ?? 59857116(04/02/2001 09:43:55???)????????
1??????
ORA-00289: ????????????: /vol1/database/orcl/arch01/arch_1_8.log
ORA-00280: ?? 59857116(???? 1)????? 8???????
ログの指定: {<RET>=suggested | filename | AUTO | CANCEL}
auto
ORA-00279: ?? 59857163(04/02/2001 12:37:14???)????????
1??????
ORA-00289: ????????????: /vol1/database/orcl/arch01/arch_1_9.log
ORA-00280: ?? 59857163(???? 1)????? 9???????
ORA-00278: ??????? /vol1/database/orcl/arch01/arch_1_8.log???????????????????
ORA-00279: ?? 59857164(04/02/2001 12:37:24???)????????
1??????
ORA-00289: ????????????: /vol1/database/orcl/arch01/arch_1_10.log
ORA-00280: ?? 59857164(???? 1)????? 10???????
ORA-00278: ??????? /vol1/database/orcl/arch01/arch_1_9.log???????????????????
ORA-00279: ?? 59857165(04/02/2001 12:37:32???)????????
1??????
ORA-00289: ????????????: /vol1/database/orcl/arch01/arch_1_11.log
ORA-00280: ?? 59857165(???? 1)????? 11???????
ORA-00278: ??????? /vol1/database/orcl/arch01/arch_1_10.log???????????????????
ログが適用されました。
メディア・リカバリが完了しました。
・
リカバリーが完了したら、データベースをオープンする。
・
以下のSQL文を発行し、障害が起こったデータファイルのSTATUSを調べる。データファイルの状態がOFFLINEであれば、ONLINEにする。
SQL> select
name, file#, status from v$datafile;
<<検索結果>>
：
/vol1/database/orcl/data01/inst1_data07.dbf 12 OFFLINE
：
：
・
データファイルがOFFLINEの場合は、以下のコマンドを発行してONLINEにする。
SQL> alter
database datafile '/vol1/database/orcl/data01/inst1_data07.dbf'
online;
データベースが変更されました。
方法２：データベースの回復
・
消失したデータファイルを、オフラインまたはオンライン・バックアップから復元する。
ただ戻した状態では当然データベースは起動も停止もできない。この状態でshutdownを行おうとすると、以下のようなメッセージが表示される。
SQL> shutdown
ORA-01122: データベース・ファイル 12の照合検査でエラーが発生しました。
ORA-01110: データ・ファイル 12 : /vol1/database/orcl/data01/inst1_data07.dbf
ORA-01208: データ・ファイルは古いバージョンです。現行バージョンにアクセスできません。
・
ABORTオプション付きでデータベースを停止する。
SQL> shutdown
abort
ORACLEインスタンスがシャットダウンされました。
・
RECOVER DATABASEを実行するために、MOUNTオプション付きでデータベースを起動する。
SQL> startup
mount pfile=/vol1/database/orcl/admin/pfile/initinst1.ora
ORACLEインスタンスが起動しました。
・
データベースがマウントされたらRECOVER
DATABASEを実行する。ログの指定は通常はAUTOで良い。
SQL> recover
database
ORA-00279: ?? 59857116(04/02/2001 09:43:55???)????????
1??????
ORA-00289: ????????????: /vol1/database/orcl/arch01/arch_1_8.log
ORA-00280: ?? 59857116(???? 1)????? 8???????
ログの指定: {<RET>=suggested | filename | AUTO | CANCEL}
auto
ORA-00279: ?? 59857164(04/02/2001 18:29:44???)????????
1??????
ORA-00289: ????????????: /vol1/database/orcl/arch01/arch_1_9.log
ORA-00280: ?? 59857164(???? 1)????? 9???????
ORA-00278: ??????? /vol1/database/orcl/arch01/arch_1_8.log???????????????????
ログが適用されました。
メディア・リカバリが完了しました。
・
リカバリーが完了したら、データベースをオープンする。
SQL> alter
database open;
データベースが変更されました。
方法３：表領域の回復
|
|
備考
|
|
以下のSQL文を発行することにより、データファイルの絶対パス付きデータファイル名、ファイル番号、状態を確認することができる。
select
name, file#, status from v$datafile;
|
|
|
|
|
|
Case 03
|
ロールバックセグメントを持つSYSTEM表領域以外のデータファイルの消失
|
|
説明
|
|
SYSTEM表領域以外のデータファイルが消失し、それにロールバックセグメントが格納されていた場合は、回復処理を行う際には注意を要する。特にオンライン回復処理を実行する場合は、このような状況から回復するための方法を良く理解しておく必要がある。
|
|
障害状況
|
|
媒体障害のため、ロールバックセグメント表領域に所属しているデータファイルがすべて消失した。
|
|
解決方法
|
|
消失したデータファイルがロールバックセグメントの表領域に所属している場合、回復処理は注意が必要である。オンライン回復処理を実行するために、消失したデータファイルを媒体回復処理時にすべてオフライン状態にした。つまり該当するデータファイルに所属しているロールバックセグメントを、すべて回復する必要がある。ただし、回復処理を実行している間、該当するロールバックセグメントを示しているアクティブなトランザクションに関連する行には、一切アクセスできない。
つまり、該当するロールバックセグメントが格納されているデータファイルを回復するまで、新しいアプリケーションを処理するために一時的なロールバックセグメントを作成する必要がある。
|
|
評価
|
|
評価実施日
|
2001/04/03
|
評価実施機
|
test
|
|
事前準備：
1. 擬似障害を発生させる。
擬似障害を起こすために、マニュアルでデータファイルを削除する。
rm /vol1/database/orcl/rbs01/
inst1_rbs01.dbf
2. データベースをshutdownする。
《 重要 》
回復処理の際に、障害個所を探し当てるために以下の手順を実行する。
以下の手順を踏まなければ、正確な障害個所を把握することはできない！
① アラート・ファイルを確認する。
ORACLEデータベースに何か障害が発生した場合は、まずアラート・ファイルの内容を確認すること。
このファイルには障害の情報の他に、データベースの構成に影響を与えるようなタスク（ALTERコマンドによる変更等）も記録されている。
このテスト環境では、アラート・ファイルは以下の場所に保存されている。
/vol1/database/orcl/admin/bdump/alert_inst1.log
② トレース・ファイルを確認する。
上記①と同じ場所に、トレース・ファイルも格納されている。各プロセス（DBWR、ARCH、LGWR、SMON等）ごとにファイルが生成されているので、最新の日付のものの内容を確認する。
③ 動的パフォーマンス表を検索する。
- V$DATAFILEでファイルの位置、ファイル番号、状態を確認する。
SQL> select
name, file#, status from v$datafile;
- V$RECOVER_FILEでリカバリーが必要なファイルを確認する。
SQL> select
* from v$recover_file;
- V$RECOVERY_FILE_STATUSでリカバリーが必要なファイルを確認する。
SQL> select
* from v$recovery_file_status;
④ OSプロンプトからoerrコマンド（ORACLEユーティリティー）を実行し、エラー番号より障害内容を確認する（このユーティリティーの使用方法は、後述「oerrコマンドによるエラー内容の確認」を参照のこと）。
方法１：表領域の回復
・
データベースをマウント状態で起動する。
SQL> startup
mount pfile=/vol1/database/orcl/admin/pfile/initinst1.ora
ORACLEインスタンスが起動しました。
Total System Global Area 1314236540 bytes
Fixed Size
116860 bytes
Variable Size
125943808 bytes
Database Buffers
1187840000 bytes
Redo Buffers 335872
bytes
データベースがマウントされました。
・
RBSのデータファイルに障害がある状態で、データベースを起動しようとするとオープンの段階で以下のようなエラーが表示される。
SQL> startup
pfile=/vol1/database/orcl/admin/pfile/initinst1.ora
ORACLEインスタンスが起動しました。
Total System Global Area 1314236540 bytes
Fixed Size
116860
bytes
Variable Size
125943808 bytes
Database Buffers
1187840000 bytes
Redo Buffers
335872 bytes
データベースがマウントされました。
ORA-01157: ???????? 3???/?????????DBWR???????????????????
ORA-01110: ???????? 3 : /vol1/database/orcl/rbs01/inst1_rbs01.dbf
この状態はオープンはできず、マウントの状態である。
・
データベースをオープンするために障害は発生したデータファイルをオフラインにする。
SQL> alter
database datafile '/vol1/database/orcl/rbs01/inst1_rbs01.dbf'
offline;
データベースが変更されました。
・
ロールバックセグメントが全滅の場合は、アプリケーションを処理するために一時的なロールバックセグメントを作成する必要がある。
SQL> create
rollback segment temp1 tablespace system;
・
以下のSQL文を発行し、現在のロールバック・セグメントの状態を把握する。
SQL> select
segment_name, status from dba_rollback_segs;
SEGMENT_NAME
STATUS
------------------------------ ----------------
SYSTEM
ONLINE
RBS0
OFFLINE
RBS1
OFFLINE
RBS2
OFFLINE
RBS3
OFFLINE
RBS4
OFFLINE
RBS5
OFFLINE
RBS6
OFFLINE
RB01
OFFLINE
RBL1
ONLINE
10行が選択されました。
・
この状態であればデータベースをオープン状態にできるが、ロールバックセグメントは障害の状態のままであるので、この後リカバリーが必要である。
SQL> alter
database open;
・
表領域に対してRECOVERを実行する。
SQL> recover
tablespace cl_rbs01
ORA-00279: 変更 59857116(04/02/2001 09:43:55で生成)にはスレッド番号
1が必要です。
ORA-00289: 検討すべきログ・ファイル: /vol1/database/orcl/arch01/arch_1_8.log
ORA-00280: 変更 59857116(スレッド 1)は順序番号 8に存在します。
ログの指定: {<RET>=suggested | filename | AUTO | CANCEL}
auto
ORA-00279: 変更 59857163(04/03/2001 11:36:13で生成)にはスレッド番号
1が必要です。
ORA-00289: 検討すべきログ・ファイル: /vol1/database/orcl/arch01/arch_1_9.log
ORA-00280: 変更 59857163(スレッド 1)は順序番号 9に存在します。
ORA-00278: ログ・ファイル
/vol1/database/orcl/arch01/arch_1_8.logはこのリカバリでは必要なくなりました。
ORA-00279: 変更 59857164(04/03/2001 11:36:22で生成)にはスレッド番号
1が必要です。
ORA-00289: 検討すべきログ・ファイル: /vol1/database/orcl/arch01/arch_1_10.log
ORA-00280: 変更 59857164(スレッド 1)は順序番号 10に存在します。
ORA-00278: ログ・ファイル
/vol1/database/orcl/arch01/arch_1_9.logはこのリカバリでは必要なくなりました。
ORA-00279: 変更 59857165(04/03/2001 11:36:25で生成)にはスレッド番号
1が必要です。
ORA-00289: 検討すべきログ・ファイル: /vol1/database/orcl/arch01/arch_1_11.log
ORA-00280: 変更 59857165(スレッド 1)は順序番号 11に存在します。
ORA-00278: ログ・ファイル
/vol1/database/orcl/arch01/arch_1_10.logはこのリカバリでは必要なくなりました。
ログが適用されました。
メディア・リカバリが完了しました。
方法２：データファイルの回復
・
データベースをマウント状態で起動する。
SQL> startup
mount pfile=/vol1/database/orcl/admin/pfile/initinst1.ora
ORACLEインスタンスが起動しました。
Total System Global Area 1314236540 bytes
Fixed Size
116860 bytes
Variable Size
125943808 bytes
Database Buffers
1187840000 bytes
Redo Buffers
335872 bytes
データベースがマウントされました。
・
以下のSQL文を発行し、データファイルの状況を把握する。
SQL> select
name, file#, status from v$datafile;
：
（中略）
：
/vol1/database/orcl/rbs01/inst1_rbs01.dbf 3 RECOVER
・
データファイルの回復はオフラインでもオンラインでも可能（ただしオンラインの場合は、データファイルをオフラインにする必要がある）なので、データベースをオープンする場合は以下のコマンドを発行する。
SQL> alter
database open;
データベースが変更されました。
・
データファイルに対して回復処理を実行する（オンラインでもオフラインでも可）。
SQL> recover
datafile '/vol1/database/orcl/rbs01/inst1_rbs01.dbf'
ORA-00279: 変更 59857116(04/02/2001 09:43:55で生成)にはスレッド番号
1が必要です。
ORA-00289: 検討すべきログ・ファイル: /vol1/database/orcl/arch01/arch_1_8.log
ORA-00280: 変更 59857116(スレッド 1)は順序番号 8に存在します。
ログの指定: {<RET>=suggested | filename | AUTO | CANCEL}
auto
ORA-00279: 変更 59857164(04/03/2001 15:58:48で生成)にはスレッド番号
1が必要です。
ORA-00289: 検討すべきログ・ファイル: /vol1/database/orcl/arch01/arch_1_9.log
ORA-00280: 変更 59857164(スレッド 1)は順序番号 9に存在します。
ORA-00278: ログ・ファイル
/vol1/database/orcl/arch01/arch_1_8.logはこのリカバリでは必要なくなりました。
ORA-00279: 変更 59857165(04/03/2001 15:58:56で生成)にはスレッド番号
1が必要です。
ORA-00289: 検討すべきログ・ファイル: /vol1/database/orcl/arch01/arch_1_10.log
ORA-00280: 変更 59857165(スレッド 1)は順序番号 10に存在します。
ORA-00278: ログ・ファイル
/vol1/database/orcl/arch01/arch_1_9.logはこのリカバリでは必要なくなりました。
ORA-00279: 変更 59857166(04/03/2001 15:59:00で生成)にはスレッド番号
1が必要です。
ORA-00289: 検討すべきログ・ファイル: /vol1/database/orcl/arch01/arch_1_11.log
ORA-00280: 変更 59857166(スレッド 1)は順序番号 11に存在します。
ORA-00278: ログ・ファイル
/vol1/database/orcl/arch01/arch_1_10.logはこのリカバリでは必要なくなりました。
ログが適用されました。
メディア・リカバリが完了しました。
・
回復処理後のステータスを以下のSQL文を発行して、確認する。
SQL> select
name, file#, status from v$datafile;
：
（中略）
：
/vol1/database/orcl/rbs01/inst1_rbs01.dbf 3 OFFLINE
この段階ではまだデータファイルの状態はオフラインのままであるので、オンラインにする必要がある。
・
以下のSQL文を発行して、データファイルをオンラインにする。
SQL> alter
database datafile '/vol1/database/orcl/rbs01/inst1_rbs01.dbf'
online;
データベースが変更されました。
|
|
備考
|
|
ロールバックセグメントのデータファイル回復処理を実行する場合、重要な手順がある。ORACLE初期化ファイル（Zurichの場合は、”initinst1.ora”）を変更し、ROLLBACK_SEGMENTSパラメーターをコメント化する作業が必要である。
この作業を実施しないと、データベースオープン時に該当するロールバックセグメントを見つけることができないため、データベースをオープンすることができない。
|
|
|
|
|
|
Case 04
|
未アーカイブオンラインREDOログファイルの消失
|
|
説明
|
|
ARCHプロセスによってまだアーカイブされていないオンラインREDOログファイルは、未アーカイブオンラインREDOログファイルという。オンラインREDOログファイルを多重化していない場合は、これらのファイルが消失すると、データが消失する可能性がある。
|
|
障害状況
|
|
データベースがクラッシュしただけでなく媒体障害も発生し、オンラインREDOログファイルがすべて消失した。ただし、データファイルとカレントの制御ファイルはすべて無事だった。
|
|
解決方法
|
|
クラッシュ発生後、データファイルは無事だったが、クラッシュ回復処理を実行できないため（オンラインREDOログファイルがすべて消失しているので）、それらのファイルを使用することはできない。このような状況でデータベースを強制的にオープンすると、データベースの一貫性が崩れる可能性がある。
未アーカイブのREDOログファイルが消失した場合は、クラッシュ回復処理を実行できないため、そのような場合は媒体回復処理を実行する必要がある。この場合は、すべてのデータファイルをオンライン（またはオフライン）の全体バックアップからリストアした後、使用可能な最後のアーカイブログファイルが適用されるまでロールフォワード処理を実行する必要がある。これは不完全な回復処理であるため、表領域の回復処理もデータファイルの回復処理も実行できない。RECOVER DATABASEコマンドを使うしか方法はない。
|
|
評価
|
|
評価実施日
|
2003/**/**
|
評価実施機
|
test
|
|
事前準備：
1. テスト準備としてABORTオプションを指定しデータベースをshutdownする。
SQL> shutdown abort
ORACLEインスタンスがシャットダウンされました。
2. すべてのオンラインREDOログファイルを削除する。
rm /vol1/database/orcl/redo01/inst1_redo01.dbf
rm /vol1/database/orcl/redo01/inst1_redo02.dbf
《 重要 》
回復処理の際に、障害個所を探し当てるために以下の手順を実行する。
以下の手順を踏まなければ、正確な障害個所を把握することはできない！
① アラート・ファイルを確認する。
ORACLEデータベースに何か障害が発生した場合は、まずアラート・ファイルの内容を確認すること。
このファイルには障害の情報の他に、データベースの構成に影響を与えるようなタスク（ALTERコマンドによる変更等）も記録されている。
このテスト環境では、アラート・ファイルは以下の場所に保存されている。
/vol1/database/orcl/admin/bdump/alert_inst1.log
② トレース・ファイルを確認する。
上記①と同じ場所に、トレース・ファイルも格納されている。各プロセス（DBWR、ARCH、LGWR、SMON等）ごとにファイルが生成されているので、最新の日付のものの内容を確認する。
③ 動的パフォーマンス表を検索する。
- V$DATAFILEでファイルの位置、ファイル番号、状態を確認する。
SQL> select
name, file#, status from v$datafile;
- V$RECOVER_FILEでリカバリーが必要なファイルを確認する。
SQL> select
* from v$recover_file;
- V$RECOVERY_FILE_STATUSでリカバリーが必要なファイルを確認する。
SQL> select
* from v$recovery_file_status;
④ OSプロンプトからoerrコマンド（ORACLEユーティリティー）を実行し、エラー番号より障害内容を確認する（このユーティリティーの使用方法は、後述「oerrコマンドによるエラー内容の確認」を参照のこと）。
未アーカイブREDOログファイルが消失した場合は、クラッシュ回復は実行できない。
そのため、すべてのデータファイルをオンライン（またはオフライン）バックアップからリストアし、使用可能な最後のアーカイブログファイルが適用されるまでロールフォワード処理を実行する必要がある。
ただしこれは不完全回復のため、表領域の回復もデータファイルの回復も実行できず、データベースの回復（RECOVER DATABASE）を実行するしかない。
・
すべてのデータファイルをバックアップからリストアする。
SYSTEM表領域のデータファイルも忘れずにリストアすること！！
・
データベースをマウント状態まで起動する。
SQL> startup
mount pfile=/vol1/database/orcl/admin/pfile/initinst1.ora
ORACLEインスタンスが起動しました。
Total System Global Area 1314236540 bytes
Fixed Size
116860 bytes
Variable Size
125943808 bytes
Database Buffers
1187840000 bytes
Redo Buffers
335872 bytes
データベースがマウントされました。
・
データベース回復を実行する。
SQL> recover
database until cancel;
ORA-00279: ?? 59857249(04/04/2001 09:18:49???)????????
1??????
ORA-00289: ????????????: /vol1/database/orcl/arch01/arch_1_10.log
ORA-00280: ?? 59857249(???? 1)????? 10???????
ログの指定: {<RET>=suggested | filename | AUTO | CANCEL}
< enter >
ORA-00279: ?? 59877295(04/04/2001 10:19:28???)????????
1??????
ORA-00289: ????????????: /vol1/database/orcl/arch01/arch_1_11.log
ORA-00280: ?? 59877295(???? 1)????? 11???????
ORA-00278: ??????? /vol1/database/orcl/arch01/arch_1_10.log???????????????????
ログの指定: {<RET>=suggested | filename | AUTO | CANCEL}
< enter >
ORA-00279: ?? 59877341(04/04/2001 10:20:46???)????????
1??????
ORA-00289: ????????????: /vol1/database/orcl/arch01/arch_1_12.log
ORA-00280: ?? 59877341(???? 1)????? 12???????
ORA-00278: ??????? /vol1/database/orcl/arch01/arch_1_11.log???????????????????
ログの指定: {<RET>=suggested | filename | AUTO | CANCEL}
< enter >
ORA-00279: ?? 59877342(04/04/2001 10:20:57???)????????
1??????
ORA-00289: ????????????: /vol1/database/orcl/arch01/arch_1_13.log
ORA-00280: ?? 59877342(???? 1)????? 13???????
ORA-00278: ??????? /vol1/database/orcl/arch01/arch_1_12.log???????????????????
ログの指定: {<RET>=suggested | filename | AUTO | CANCEL}
< enter >
ORA-00279: ?? 59877343(04/04/2001 10:21:04???)????????
1??????
ORA-00289: ????????????: /vol1/database/orcl/arch01/arch_1_14.log
ORA-00280: ?? 59877343(???? 1)????? 14???????
ORA-00278: ??????? /vol1/database/orcl/arch01/arch_1_13.log???????????????????
ログの指定: {<RET>=suggested | filename | AUTO | CANCEL}
< enter >
ORA-00279: ?? 59877344(04/04/2001 10:21:10???)????????
1??????
ORA-00289: ????????????: /vol1/database/orcl/arch01/arch_1_15.log
ORA-00280: ?? 59877344(???? 1)????? 15???????
ORA-00278: ??????? /vol1/database/orcl/arch01/arch_1_14.log???????????????????
ログの指定: {<RET>=suggested | filename | AUTO | CANCEL}
< enter >
ORA-00279: 変更 59877344(04/04/2001 10:21:10で生成)にはスレッド番号
1が必要です。
ORA-00289: 検討すべきログ・ファイル: /vol1/database/orcl/arch01/arch_1_15.log
ORA-00280: 変更 59877344(スレッド 1)は順序番号 15に存在します。
ログの指定: {<RET>=suggested | filename | AUTO | CANCEL}
cancel
メディア・リカバリが取り消されました。始されていません。
・
不完全回復処理なのでRESETLOGSオプションを指定し、データベースをオープンする。
SQL> alter
database open resetlogs;
データベースが変更されました。
・
消失したオンラインREDOログファイルは、データベースのオープン処理の一部として、自動的に再作成される。
|
|
備考
|
|
REDOログの破損状態を判別するため、以下のコマンドでV$LOGを問い合わせることができる。
SQL>
select * from v$log;
|
|
|
|
|
|
Case 05
|
バックアップされた制御ファイルを使用した回復処理
|
|
説明
|
|
バックアップされた制御ファイルを使用した回復処理は、慎重を要する。回復処理は可能であればカレントの制御ファイルを使用して行うようにする。その次に最善の方法は、新しい制御ファイルを作成する方法である。RESETLOGSオプションを指定してデータベースを起動する必要があるため、バックアップされた制御ファイルを使用する方法は最後の手段である。
|
|
障害状況
|
|
制御ファイルが多重化されておらず、かつその制御ファイルが消失してしまった。そのためバックアップされた制御ファイルをコピーし、データベースを起動しようとした。
|
|
解決方法
|
|
方法としては2つある。
データファイルとオンラインREDOログファイルはすべて無事なので、CREATE CONTROLFILEコマンドを使用して新しい制御ファイルを作成すれば、回復処理を必要に応じて実行でき、データベースを起動できる。
また、バックアップされた制御ファイルを使用することもできる。ただし、バックアップされた制御ファイルを使用する場合は、媒体回復処理を実行する必要がある。また、USING BACKUP CONTROLFILEオプションも指定しなければならない。回復処理が完了したら、RESETLOGSオプションを指定してデータベースを起動し、データベースの完全なバックアップを行う必要がある。
|
|
評価
|
|
評価実施日
|
2003/**/**
|
評価実施機
|
test
|
|
《 重要 》
回復処理の際に、障害個所を探し当てるために以下の手順を実行する。
以下の手順を踏まなければ、正確な障害個所を把握することはできない！
① アラート・ファイルを確認する。
ORACLEデータベースに何か障害が発生した場合は、まずアラート・ファイルの内容を確認すること。
このファイルには障害の情報の他に、データベースの構成に影響を与えるようなタスク（ALTERコマンドによる変更等）も記録されている。
このテスト環境では、アラート・ファイルは以下の場所に保存されている。
/vol1/database/orcl/admin/bdump/alert_inst1.log
② トレース・ファイルを確認する。
上記①と同じ場所に、トレース・ファイルも格納されている。各プロセス（DBWR、ARCH、LGWR、SMON等）ごとにファイルが生成されているので、最新の日付のものの内容を確認する。
③ 動的パフォーマンス表を検索する。
- V$DATAFILEでファイルの位置、ファイル番号、状態を確認する。
SQL> select
name, file#, status from v$datafile;
- V$RECOVER_FILEでリカバリーが必要なファイルを確認する。
SQL> select
* from v$recover_file;
- V$RECOVERY_FILE_STATUSでリカバリーが必要なファイルを確認する。
SQL> select
* from v$recovery_file_status;
④ OSプロンプトからoerrコマンド（ORACLEユーティリティー）を実行し、エラー番号より障害内容を確認する（このユーティリティーの使用方法は、後述「oerrコマンドによるエラー内容の確認」を参照のこと）。
・
REDOログ・ファイルを何回か切り替えてみる。
SQL> alter
system switch logfile;
システムが変更されました。
・
ABORTオプション付きでデータベースをshutdownする。
SQL> shutdown
abort
ORACLEインスタンスがシャットダウンされました。
・
テストのためにバックアップから（古い）制御ファイルをリストアする。
・
データベースをオープンしようとすると以下のように、古い制御ファイルが使用されているというエラーが表示される。
SQL> startup
mount pfile=/vol1/database/orcl/admin/pfile/initinst1.ora
ORACLEインスタンスが起動しました。
Total System Global Area 1314236540 bytes
Fixed Size
116860 bytes
Variable Size
125943808 bytes
Database Buffers
1187840000 bytes
Redo Buffers
335872 bytes
データベースがマウントされました。
SQL> alter
database open;
alter database open
*
1行でエラーが発生しました。
ORA-01122: データベース・ファイル 1の照合検査でエラーが発生しました。
ORA-01110: データ・ファイル 1 : /vol1/database/orcl/system/inst1_sys.dbf
ORA-01207: ファイルが制御ファイルより新しくなっています(制御ファイルが古い)。
・
制御ファイルのポジションが正しくないため、通常のRECOVER
DATABASEを実行しても以下のようにエラーとなる。
SQL> recover
database
ORA-00283: エラーによってリカバリ・セッションは取り消されました。
ORA-01122: データベース・ファイル 1の照合検査でエラーが発生しました。
ORA-01110: データ・ファイル 1 : /vol1/database/orcl/system/inst1_sys.dbf
ORA-01207: ファイルが制御ファイルより新しくなっています(制御ファイルが古い)。
・
バックアップからリストアした制御ファイルを使用して回復処理を実行する場合は、以下のように”USING BACKUP CONTROLFILE”オプションの指定が必要である。
SQL> recover
database using backup controlfile;
ORA-00279: 変更 59857249(04/04/2001 09:18:30で生成)にはスレッド番号
1が必要です。
ORA-00289: 検討すべきログ・ファイル: /vol1/database/orcl/arch01/arch_1_10.log
ORA-00280: 変更 59857249(スレッド 1)は順序番号 10に存在します。
ログの指定: {<RET>=suggested | filename | AUTO | CANCEL}
auto
ORA-00279: 変更 59857293(04/04/2001 13:47:32で生成)にはスレッド番号
1が必要です。
ORA-00289: 検討すべきログ・ファイル: /vol1/database/orcl/arch01/arch_1_11.log
ORA-00280: 変更 59857293(スレッド 1)は順序番号 11に存在します。
ORA-00278: ログ・ファイル
/vol1/database/orcl/arch01/arch_1_10.logはこのリカバリでは必要なくなりました。
ORA-00279: 変更 59857294(04/04/2001 13:47:43で生成)にはスレッド番号
1が必要です。
ORA-00289: 検討すべきログ・ファイル: /vol1/database/orcl/arch01/arch_1_12.log
ORA-00280: 変更 59857294(スレッド 1)は順序番号 12に存在します。
ORA-00278: ログ・ファイル
/vol1/database/orcl/arch01/arch_1_11.logはこのリカバリでは必要なくなりました。
ORA-00279: 変更 59857295(04/04/2001 13:47:51で生成)にはスレッド番号
1が必要です。
ORA-00289: 検討すべきログ・ファイル: /vol1/database/orcl/arch01/arch_1_13.log
ORA-00280: 変更 59857295(スレッド 1)は順序番号 13に存在します。
ORA-00278: ログ・ファイル
/vol1/database/orcl/arch01/arch_1_12.logはこのリカバリでは必要なくなりました。
ORA-00279: 変更 59857296(04/04/2001 13:47:58で生成)にはスレッド番号
1が必要です。
ORA-00289: 検討すべきログ・ファイル: /vol1/database/orcl/arch01/arch_1_14.log
ORA-00280: 変更 59857296(スレッド 1)は順序番号 14に存在します。
ORA-00278: ログ・ファイル
/vol1/database/orcl/arch01/arch_1_13.logはこのリカバリでは必要なくなりました。
ORA-00279: 変更 59857297(04/04/2001 13:48:01で生成)にはスレッド番号
1が必要です。
ORA-00289: 検討すべきログ・ファイル: /vol1/database/orcl/arch01/arch_1_15.log
ORA-00280: 変更 59857297(スレッド 1)は順序番号 15に存在します。
ORA-00278: ログ・ファイル
/vol1/database/orcl/arch01/arch_1_14.logはこのリカバリでは必要なくなりました。
ORA-00308: アーカイブ・ログ
/vol1/database/orcl/arch01/arch_1_15.logをオープンできません。
ORA-27037: ファイル・ステータスを取得できません。
IBM AIX RISC System/6000 Error: 2: No such file or directory
Additional information: 3
・
データベースを通常通り起動しようとするとエラーになる。これはバックアップから制御ファイルをリストアしたため、ログ順序番号等の情報が古くなり、データファイルが持つ情報と一致しないからである。
そのためこの場合、データベースをオープンするにはRESETLOGSオプションを指定しなければ起動しない。
SQL> alter
database open;
alter database open
*
1行でエラーが発生しました。
ORA-01589:
DBをオープンするにはRESETLOGS/NORESETLOGSを使用しなければなりません。
SQL> alter
database open resetlogs;
データベースが変更されました。
|
|
備考
|
|
新しくCREATE
CONTROLFILEコマンドにより制御ファイルを再作成する場合は、”/vol1/database/orcl/admin/udump”ディレクトリーの中に”ora_22152_inst1.trc”というようなファイルを参照のこと。
すべてのファイルがCREATE CONTROLFILE用のものではないが、コールド・バックアップ時に”alter database backup controlfile to trace”を実行しているので再作成用のスクリプトが存在する。
|
|
|
|
|
|
Case 06
|
REDOログ・ファイルの回復処理
|
|
説明
|
|
以下に示す手順でログ・ファイルを再作成する。
・
REDOログを作成する位置を検索
・
消失したファイルが格納されているログ・グループを削除
・
ログ・グループを再作成
・
データベースをオープン
・
データベースをより早くオープンしたい場合は、CLEAR
LOGFILEを使用
|
|
障害状況
|
|
REDOログ・ファイル・グループを構成しているデータ・ファイルの1つが消失した。
|
|
解決方法
|
|
データベースは、REDOログ・ファイルが再作成されるまでオープンできない。
データベースには少なくとも2つのログ・グループが常に存在しなければならず、グループが2つしかない場合はログ・グループは削除することができない。
REDOログの再作成は、以下の手順を実行すると素早く行える。
|
|
評価
|
|
評価実施日
|
|
評価実施機
|
test
|
|
《 重要 》
回復処理の際に、障害個所を探し当てるために以下の手順を実行する。
以下の手順を踏まなければ、正確な障害個所を把握することはできない！
① アラート・ファイルを確認する。
ORACLEデータベースに何か障害が発生した場合は、まずアラート・ファイルの内容を確認すること。
このファイルには障害の情報の他に、データベースの構成に影響を与えるようなタスク（ALTERコマンドによる変更等）も記録されている。
このテスト環境では、アラート・ファイルは以下の場所に保存されている。
/vol1/database/orcl/admin/bdump/alert_inst1.log
② トレース・ファイルを確認する。
上記①と同じ場所に、トレース・ファイルも格納されている。各プロセス（DBWR、ARCH、LGWR、SMON等）ごとにファイルが生成されているので、最新の日付のものの内容を確認する。
③ 動的パフォーマンス表を検索する。
- V$DATAFILEでファイルの位置、ファイル番号、状態を確認する。
SQL> select
name, file#, status from v$datafile;
- V$RECOVER_FILEでリカバリーが必要なファイルを確認する。
SQL> select
* from v$recover_file;
- V$RECOVERY_FILE_STATUSでリカバリーが必要なファイルを確認する。
SQL> select
* from v$recovery_file_status;
④ OSプロンプトからoerrコマンド（ORACLEユーティリティー）を実行し、エラー番号より障害内容を確認する（このユーティリティーの使用方法は、後述「oerrコマンドによるエラー内容の確認」を参照のこと）。
テスト時には、”/vol1/database/orcl/redo01/inst1_redo01.dbf”を削除しておく。
1. REDOログ・ファイルが消失した状態でデータベースをオープンしようとすると、以下のようなエラーが表示される。表示されたデータ・ファイルに障害が発生している。
SQL> alter
database open;
alter database open
*
1行でエラーが発生しました。
ORA-00313: ログ・グループ 1(スレッド 1)のメンバーをオープンできません。
ORA-00312: オンライン・ログ 1 スレッド 1: '
/vol1/database/orcl/redo01/inst1_redo01.dbf'
2. ファイルが過去に格納されていた場所を検索する。
SQL> select
* from v$logfile;
GROUP# STATUS
---------- -------
MEMBER
--------------------------------------------------------------------------------
2
/vol1/database/orcl/redo02/inst1_redo02.dbf
1
/vol1/database/orcl/redo01/inst1_redo01.dbf
3. 少なくとも2つのログ・グループがなければならないので、もし2つしかグループがない場合には、一時的に別のグループを作成しておく。
SQL> alter
database add logfile group 3 ‘/vol1/database/orcl/redo01/inst1_redo03.dbf’
size 10m;
データベースが変更されました。
4. コマンドを入力し、障害があったログ・グループを削除する。ただし、障害がおきたREDOログ・ファイルが現在使用されているもの（ARC:NO STATUS:CURRENT）の場合、以下のようにエラーが表示され削除はできない。
障害があったファイルが現行ログ・ファイルでない場合は、下記６以降を参照のこと。
SQL> alter
database drop logfile group 1;
alter database drop logfile group 1
*
1行でエラーが発生しました。
ORA-01623: ログ 1は現行ログ(スレッド 1)なので削除できません。
ORA-00312: オンライン・ログ 1 スレッド 1: '
/vol1/database/orcl/redo01/inst1_redo01.dbf'
5. 上記のグループの削除が現行ログのために出来なかった場合は、以下のコマンドにより強制的に消去する。
このコマンドを発行すると、ログ・ファイルの削除（DROP LOGFILE）と追加（ADD LOGFILE）が行われる。
SQL> alter
database clear unarchived logfile
group 1;
データベースが変更されました。
オプションUNARCHIVEDを指定するのは、対象のファイルが現行ログ・ファイルの場合である。
もし対象のファイルが“現行ログ・ファイルでない場合”は、UNARCHIVEDオプションは不要である。
SQL> alter
database clear logfile group 1;
UNARCHIVEDオプション指定のCLEAR LOGFILEを実行した場合は、すぐにバックアップを作成すること。
6. コマンドを入力し、消失したログ・ファイルを再作成する。
SQL> alter
database add logfile group 1 '/vol1/database/orcl/redo01/inst1_redo01.dbf'
size 10m;
データベースが変更されました。
7. コマンドを入力し、一時的に追加したログ・グループを削除する。
SQL> alter
database drop logfile group 3;
データベースが変更されました。
8. 追加したログ・ファイルをOSから物理的に削除する。
rm /vol1/database/orcl/redo01/inst1_redo03.dbf
9. コマンドを入力し、データベースをオープンする。
SQL> alter
database open;
上記のログ・ファイルの再作成の手順は、以下の2つの手順で簡単に行うことも可能である。
以下のコマンドであれば、ログ・グループが2つ（最小グループ数）しかない場合でも、一時的なグループの追加なしにログ・ファイルの再作成が可能である。
1. バックアップから消失したファイルをリストア（コピー）する。
2. SQL>
alter database
clear logfile '/vol1/database/orcl/redo01/inst1_redo01.dbf';
データベースが変更されました。
3. データベースをオープンする。
SQL> alter
database open;
データベースが変更されました。
|
|
備考
|
|
|
|
|
|
|
|
RECOVER構文について
データベースを回復するには、以下のコマンドのいずれかを発行する。
データベースの状態（オンライン or オフライン）により、発行できるRECOVERコマンドは異なる。
・
recover [automatic] database
このコマンドは、クローズ・データベース（マウントの状態）の回復にのみ使用できる。
・
recover [automatic] tablespace
<number> | <name>
このコマンドは、オープン・データベース（オープンの状態）の回復にのみ使用できる。
・
recover [automatic] datafile
<number> | <name>
このコマンドは、オープン・データベースの回復およびクローズ・データベースの回復の両方に使用する事ができる。
automatic
: アーカイブ・ログ・ファイルとREDOログ・ファイルを自動的に適用する。
データベースをユーザーに開放した状態（オープン状態）で回復させたい場合は、方法としては表領域の回復処理とデータ・ファイルの回復処理のどちらか1つを選択しなければならない。
ただしデータ・ファイルの回復処理をオンラインで実行するには、該当する障害ファイルの状態を一度オフラインにし、その後RECOVER DATAFILEを実行する必要がある。
また、RECOVER DATAFILE後はデータ・ファイルはオフライン状態なので、オンラインに｢戻さなければならない。
SQL> alter database datafile
‘/vol1/database/orcl/data01/inst1_data01.dbf’ offline;
SQL> recover datafile
‘/vol1/database/orcl/data01/inst1_data01.dbf’
SQL> alter database datafile
‘/vol1/database/orcl/data01/inst1_data01.dbf’ online;
アーカイブを異なる位置へ復元した場合
アーカイブ・ログをLOG_ARCHIVE_DESTディレクトリーに復元しない場合、回復する前または回復中に、以下のいずれかの方法でOracleに知らせる必要がある。
・
RECOVERプロンプトで、位置と名前を指定する。
Specify log: {<RET>=suggested | filename | AUTO |
CANCEL}
・
ALTER SYSTEM ARCHIVEコマンドを使用する。
SVRMGR> alter system archive log start to <new location>;
・ RECOVER
FROM <LOCATION>コマンドを使用する。
SVRMGR> recover from ‘<new location>’ database;
別の位置へ復元した場合
1. 制御ファイルが別の位置に復元された場合、パラメータ・ファイルを更新する。
2.
データ・ファイルまたがREDOログが別の位置または別名で復元された場合、以下に示すステップを実行する。
- インスタンスをマウントする。
- ALTER DATABASEコマンドを使用して、制御ファイル内のエントリーを新しい
ファイル位置で更新する。
SVRMGR> alter database rename file
2> ‘/disk1/data/user_01.dbf’
3> to ‘/disk2/data/user_01.dbf’;
注意
ALTER DATABASE RENAMEコマンドを発行する時には、その前に各ファイルが新しい位置にあることを確認すること。
回復が必要なデータ・ファイルの確認
・
回復が必要なデータ・ファイルおよび回復開始時点を検索するには、以下に示すV$RECOVER_FILEビューを表示する。
SVRMGR> select * from v$recover_file;
・ アーカイブ・ログ・ファイルを確認するには、すべてのアーカイブが記録されたV$ARCHIVED_LOGを表示するか、回復中に必要なアーカイブが記録されたV$RECOVERY_LOGを表示する。
SVRMGR> select * from v$recovery_log;
回復状態に関する情報の表示
サーバー・プロセスとユーザーが行うメディア回復のステータス情報は、以下の2つのデータ・ディクショナリーに格納されている。
リカバリーはこれらのディクショナリーを参照しながら行うこと。
・
V$RECOVERY_STATUS
データベースの回復情報がすべて含まれる。
- 回復の開始時間
- 必要なログ順序番号
- 前回適用されたログの状態
- 回復にユーザー入力が必要な理由
・
V$RECOVERY_FILE_STATUS
回復の必要がある各データ・ファイルの情報が含まれる。
- 回復が必要なファイル
- 回復の状態
oerrコマンドによるエラー内容の確認
OSプロンプトから入力できるORACLEのユーティリティーが存在する。
このユーティリティーを使用すれば、ORACLEから返されたエラー・コードをもとにそのエラーの内容と対応方法を知ることができる。
使用方法は以下の通り。
ORACLEのエラー・コードは、3文字のプレフィックスにより分類されている。
例えばもしORACLEからORA-7300というエラー・コードを受け取ったならば、それは分類が”ora”でエラー番号は”7300”ということになる。
もしこのエラーの詳細を調べたいのであれば、以下のようにOSのプロンプトから入力する。
$ oerr ora 7300
その他
・
データ・ファイルをオフラインにするには、以下のコマンドを発行する。
データ・ファイルに障害がある場合は、IMMEDIATEオプション無しではオフラインにならないので、注意すること。
SQL> alter database datafile ‘/disk3/data/df2.dbf’
offline immediate;
・ 表領域をオフラインにするには、以下のコマンドを発行する。
データ・ファイルに障害がある場合は、IMMEDIATEオプション無しではオフラインにならないので、注意すること。
SQL> alter tablespace CL_DAT01 offline immediate;
2001/08/14追記
Oracleインスタンス異常終了時
Oracleインスタンスが起動すると、UNIXの共有メモリーやセマフォがOracleにより取得される。
Oracleインスタンスが異常終了してしまった場合あるいはshutdown
abortで強制的にシャットダウンした場合に、これらを解放しないままでいることがある。
インスタンスの異常終了あるいは強制終了時には、現在のセマフォおよび共有メモリーの状況を確認し、解放されていないものが存在する場合は、以下の例に従い解放すること。
・
メッセージ待ち行列、共有メモリー、セマフォすべての状況を確認する場合。
% ipcs
・
それぞれを別個に確認する場合。
% ipcs –q ･･･
メッセージ待ち行列の表示
% ipcs –m ･･･
共有メモリーの表示
% ipcs –s ･･･
セマフォの表示
inst1インスタンスの状況は、以下のようになっている。
root@/(test): ipcs
/dev/mem からの IPC 状況:
Tue Aug 14 13:01:33 JST 2001
T
ID
KEY
MODE
OWNER GROUP
メッセージ待ち行列:
q
0 0x6105d185 --rw-rw---- root system
q
1 0x5305d185 --rw-rw-rw- root system
q
2 0x4305d194 --rw-rw-rw- root system
q
3 0x4105d194 --rw-rw-rw- root system
q
4 0x4107001c -Rrw-rw---- root printq
共用メモリ:
m
0 0x00006000 --rw-rw-rw- root system
m 3145729
0xf94382c4 --rw-r----- oracle oinstall
m
2 0x0d052af9 --rw-rw-rw- root system
セマフォ:
s 393216
0x00006000 --ra-ra-ra- root system
s
1 0x6205281b --ra-r--r-- root system
s
2 0x01052a91 --ra------- root system
上記例の所有者：oracleが掴んでいる共有メモリーを解放するには、以下のコマンドを実行する。
% ipcrm –m 3145729
但し1つのサーバーに複数のインスタンスが稼動している場合は、一旦すべてのインスタンスを停止させた後で共有メモリーやセマフォの解放を行うこと。
