REDOログファイルに障害が発生したら：独学！ ORACLE MASTER Gold 11g講座（9）（2/2 ページ）

» 2011年11月11日 00時00分公開

[武見弘之，システム・テクノロジー・アイ]

チェックポイントについてしっかり理解しよう

　チェックポイントについては第1回でも解説していますが、REDOログファイルのステータスを理解するには必ず押さえておかなければならないポイントですので、あらためて説明します。

　チェックポイントとは、メモリの内容とデータファイルを同期するイベントを指す言葉です。このチェックポイントの時点でDatabase Writer（DBWn）は、DBバッファキャッシュ上のデータのうち変更があったものをすべてデータファイルに書き込みます。チェックポイントが発生するタイミングはいろいろです、Oracleはデータベースなどを管理するためのパラメータをいろいろ持っていますが、それらのうち、特定のパラメータの値がしきい値が超えると発生します。

　では、インスタンスクラッシュが発生すると、どのような状態になるでしょうか？

　LGWRはコミットでログを書き込みますが、DBWnはコミットと同期しません。そのため、コミットしたDMLの内容がすべてデータファイルに反映されているとは限らないのです。

　そこでデータファイルに反映されていないコミットデータを、インスタンスの再起動時にREDOログから自動回復します。その回復の起点は、最後に発生したチェックポイントです。これより過去のログはすでにデータファイルに反映されているため、回復には必要ありません。

　チェックポイントよりさらに前に発生したDML(1)と(2)はすでにデータファイルに書き込み済みです。

　これをロググループ単位で確認してみましょう。INACTIVEのグループの内容には回復に必要となるログはありませんが、ACTIVEとなっているグループはこの回復のために必要なログを抱えています。

　ログスイッチは、一周した先のファイルがACTIVEグループだった場合、チェックポイントが完了し、INACTIVEとなるまで、書き込み待ちを発生させます。ACTIVEステータスのまま上書きされることはありません。このことはパフォーマンス上の問題となりますが、インスタンスクラッシュから回復するためのログは必ず保護することになります。

　なお、これらのステータスはいずれもアーカイブログの取得とは関係ないということに注意してください。

ステータス別の回復法

　ステータス別に、REDOロググループのファイルがすべて壊れた場合を考えてみます。

　REDOログファイルのステータスがINACTIVEの場合、回復手順は難しくありません。アーカイブログへのデータの記録を済ませていれば、このREDOログファイルは必要ありません。

　ログスイッチを繰り返すことでいずれ1周しますが、1周する前にこのグループを削除し、新たにグループを追加すれば良いのです。そして、削除したグループと同じグループとしてグループを追加する作業を1つのコマンドにまとめたものが、CLEAR LOGFILEコマンドです。

ALTER DATABASE CLEAR LOGFILE 壊れたグループ番号;

　ただし、インスタンスクラッシュには対応できても、もしアーカイブログへの記録が済んでいなければ、メディア障害に対応できません。また、ARCHIVELOGモードである以上、アーカイブとして獲得していないREDOログの上書きや消去はできないのが普通です。

　ステータスがINACTIVEでも、アーカイブログが済んでいない場合は、無理やりログファイルをクリアすることになります。それには、以下のコマンドを実行します。

ALTER DATABASE CLEAR UNARCHIVED LOGFILE 壊れたグループ番号;

　もちろん、このコマンドを実行するとアーカイブログの連続性が失われます。すなわち、この後でデータファイルに損失が発生しても、最新のコミットまで復旧することはできません。

　ただし、データベース全体のバックアップを取得しておけば、過去のアーカイブログは必要なくなります。このコマンドを実行した後は、速やかに全体バックアップを取得してください。

　ステータスがACTIVEのREDOログファイルは、まだインスタンスクラッシュからの回復に必要です。ただし、チェックポイントが成功すれば、INACTIVEと同じ状態になります。チェックポイントを強制するには、以下のコマンドを実行します。

SQL> ALTER SYSTEM CHECKPOINT;

　ただし、このチェックポイントに失敗したときは、次に説明するステータスがCURRENTのREDOログファイルが壊れた場合と同じ扱いになります。

　ステータスがCURRENTであるREDOログファイルに損失が発生しても、LGWRは書き込みを続けようとします。しかし、この状態ではLGWRはいずれ異常を検出し、インスタンスクラッシュが発生します。

　こうなると、壊れたログファイルにある内容をあきらめ、ログ順序ベースの不完全リカバリを試みるしかありません。ログ順序ベースの不完全リカバリの手順は第8回で紹介しています。

　以上が、REDOログファイルが損失したときのリカバリ方法です。いずれかのREDOログファイルが壊れると、アラートログに記録が残りますが、多重化したグループの一部が壊れたまま動き続けるという綱渡り状態になります。そして、CURRENTに当たるグループが全滅したときは、不完全リカバリををすることになります。今回はREDOログ自体のリカバリを紹介しましたが、グループ全滅という憂き目に合わないよう、監視体制を整えてください。

　次回も、ユーザー管理のバックアップとリカバリについて解説します。