クラッシュ・リカバリ、インスタンス・リカバリ
クラッシュ・リカバリ処理
シングルインスタンス(※1) および RAC によるマルチインスタンスの環境において、すべてのインスタンスが異常終了(電源断、クラッシュ、ABORT)した場合に行われる処理。
リカバリ処理は、再起動(次回の起動)時に自動的に試みられる。
自動的にリカバリされるからといって完全にリカバリできる保証はない。
電源ボタンによる OS レベルのシャットダウンやセッション切断が面倒との理由から SHUTDOWN ABORT を定常的に行っていると SMON からこき使われた…と、しっぺ返しを受けるかもしれない。(※2)
特に Windows の場合にはサービスの停止にはデフォルト値として通常 20 秒の期限が設けられており、
これを超過すると強制終了になる。
あなたの Windws の Oracle は知らぬ間にクラッシュ・リカバリが行われていてませんか？
RAC の場合には最初に起動したインスタンスがすべてのインスタンスのリカバリを行なうらしい。
(※1) あるオラクルマスタ対策本には シングルインスタンスの場合は インスタンス・リカバリであると明記している。（どちらが正しいのだろう？）⇒ クラッシュ・リカバリかインスタンスリカバリか？
(※2) 案の定というか 2007月9月に神戸の新聞社が SHUTDOWN ABORT による運用をしたことに起因してオラクルの再起動時のクラッシュリカバリー時に ORA-600 でデータベースが起動しないトラブルが発生。紙面が作れずに他社にシステムを借りるというトラブルはニュース等で大きく報じられた。（KROWN-No.126205 にて一般公開されている）
回復プロセス
異常終了時にはデータファイル、REDOログファイルに含まれる SCN（システム変更番号）の同期が取れていない状態になっている。
回復処理(リカバリは最終チェックポイントから行う)
- SMON がリカバリ処理を開始する
⇒ バックグラウンド・プロセス (Beginning crash recovery 〜 Completed crash recovery)
- オンライン REDO ログを取り出し、データファイルに適用
⇒ ロールフォワード
アーカイブログモードで運用している場合には、アーカイブログのファイルを要求する場合もある。
- 処理が終了していなかった(未解決)トランザクションを ロールバック する。
⇒ トランザクションリカバリ(tx recovery)
- 各データファイルと REDO の同期を行う ⇒ チェックポイント
インスタンス・リカバリ
RAC （旧：パラレルサーバー）構成において、一部のインスタンスに障害が発生したときに生存中の別のインスタンスから
障害の発生した オンライン REDO ログファイル を使用して回復処理を行なうリカバリ。
障害の発生したインスタンスが使用していたリソースの解放も行なわれる。
クラッシュ・リカバリ か インスタンス・リカバリか？
インスタンス・リカバリという言葉が RAC の一部障害からのリカバリだけでなく インスタンス障害 から復旧するという意味で広義で使っていることが多いが厳密には正しい用語の使い方とは言えないようである。
「バックアップおよびリカバリ基礎」をマニュアル参照、マニュアルの原文でも確認してみたが同じ表記になっているので誤訳ではなさそう。しかし、マニュアル自体に間違いがあったりするのがオラクルのマニュアルの伝統である。
関連事項
