Oracleインスタンス・リカバリの仕組みと手順

Oracle Databaseを運用する上で、避けて通れないのが「インスタンス障害」です。突然の停電やプロセス停止によりデータベースがダウンした際、一貫性を保ちつつ自動復旧させる仕組みがインスタンス・リカバリです。

本記事では、インスタンス障害が発生する原因から、内部で行われるロールフォワード・ロールバックの仕組み、リカバリ時間を制御するパラメータまで、DBAが知っておくべき基礎知識を解説します。

💰 【PR】Oracleエンジニアの市場価値、調べてみませんか？

Oracleのスキルは需要が高く、特定の資格や経験を持っていると年収が大幅にアップするケースがあります。まずはIT専門のエージェントで非公開求人をチェックしてみませんか？

インスタンス・リカバリの最短実行手順
1. インスタンス障害とは？発生原因と影響
1. 主な発生原因
2. データベースへの影響
2. インスタンス・リカバリの仕組み：2つのフェーズ
1. (1) ロールフォワード（前進復帰）
2. (2) ロールバック（後退復帰）
3. リカバリ時間を短縮する設定（FAST_START_MTTR_TARGET）
4. アラート・ログでの確認方法
1. アラートログの出力例
5. 運用上の注意点と防止策
6. FAQ：よくある質問
まとめ

インスタンス・リカバリの最短実行手順

インスタンス・リカバリは通常、障害後の起動時に自動的に行われます。管理者が行うべき最短のステップは以下の通りです。

インスタンスの起動: SQL*Plus等から STARTUP コマンドを実行する。
自動リカバリの待機: Oracleが制御ファイルの一致を確認し、自動的にリカバリを開始します。
完了確認: アラート・ログに Completed redo application や Database opened が出力されるのを監視する。

1. インスタンス障害とは？発生原因と影響

インスタンス障害とは、SGA（メモリ構造）やバックグラウンドプロセスが予期せず停止し、データベースにアクセスできなくなる状態を指します。

主な発生原因

電源トラブル: サーバーの突発的な停電。
OS障害: カーネルパニックなどのシステムクラッシュ。
ハードウェア故障: メモリやCPUの異常。
不適切な操作: 管理者による SHUTDOWN ABORT や OSレベルでのプロセス強制終了（kill）。

データベースへの影響

メモリ上のデータ（バッファ・キャッシュ）がディスク（データファイル）に書き込まれる前に停止するため、コミット済みのデータが失われたり、未コミットのデータが残ったりする「非整合性」が生じます。これを解消するのがリカバリの役割です。

2. インスタンス・リカバリの仕組み：2つのフェーズ

Oracleは、次回起動時に「オンライン・REDOログ」と「UNDOデータ」を使用して、自動的に整合性を取り戻します。

(1) ロールフォワード（前進復帰）

目的: 障害直前までのコミット済みデータを再現する。
仕組み: REDOログファイルに記録された変更履歴をすべてデータファイルに適用します。この時点では、まだ未コミットのデータも含まれています。

(2) ロールバック（後退復帰）

目的: 障害時に終了していなかった未コミットのトランザクションを取り消す。
仕組み: UNDO表領域の情報を使用し、完了していない処理を障害前の状態へ戻します。これにより、完全な整合性が確保されます。

3. リカバリ時間を短縮する設定（FAST_START_MTTR_TARGET）

大規模なシステムではリカバリに時間がかかることがあります。これを制御するのが FAST_START_MTTR_TARGET パラメータです。

単位: 秒
デフォルト: 0（自動計算）
設定の仕組み: この値を短く設定すると、Oracleはチェックポイント（メモリからディスクへの書き込み）の頻度を上げ、リカバリ時に読み込むべきREDOログの量を減らそうとします。

設定例（リカバリ目標を30秒にする場合）:

-- システム全体に反映（動的変更可能）
ALTER SYSTEM SET FAST_START_MTTR_TARGET = 30;

注意点: 目標値を短くしすぎると、DBWR（データベース・ライター）の書き込み負荷が増大し、通常稼働時のパフォーマンスに影響を与える可能性があります。

4. アラート・ログでの確認方法

リカバリの進捗は、アラート・ログでリアルタイムに確認できます。

ログの確認コマンド（Linux例）:

tail -f $ORACLE_BASE/diag/rdbms/<DB名>/<インスタンス名>/trace/alert_<インスタンス名>.log

アラートログの出力例

Starting up instance (normal)
Database mounted in Exclusive Mode
Instance Recovery started
Redo applied up to change number 1234567
Recovery of Online Redo Log: Thread 1 Group 1 Seq# 456 Reading mem 0
Recovery of Online Redo Log: Thread 1 Group 2 Seq# 457 Reading mem 0
Recovery completed for thread 1
Instance Recovery completed at SCN 1234567
Database opened

5. 運用上の注意点と防止策

インスタンス・リカバリは「ディスク（データファイル）が壊れていないこと」が前提です。

メディア障害への備え: ディスク自体が故障した場合は、インスタンス・リカバリでは直せません。必ず RMAN（Recovery Manager） 等によるバックアップを取得してください。
リソース監視: メモリ枯渇によるインスタンス停止を防ぐため、OSリソースの監視を徹底します。
戻し方: リカバリ自体は自動ですが、もしリカバリ後に特定のデータが意図せず消えている（未コミットだった）場合は、バックアップからのポイント・イン・タイム・リカバリを検討する必要があります。

6. FAQ：よくある質問

Q：インスタンス・リカバリは手動で実行できますか？ A：いいえ。Oracleが起動時に不整合を検知すると自動で実行します。手動で開始するコマンドはありません。

Q：ロールバック中にデータベースは使えますか？ A：はい。近年のOracle（19c含む）では、ロールフォワードが完了した時点でデータベースをオープンし、バックグラウンドでロールバックを行う「ファスト・スタート・リカバリ」が機能するため、早期のサービス再開が可能です。

Q：SHUTDOWN IMMEDIATEでもリカバリは走りますか？ A：いいえ。IMMEDIATE や NORMAL は正常終了時にチェックポイントを行うため、次回の起動時にリカバリは発生しません。

まとめ

インスタンス・リカバリは、異常終了後の起動時に自動で行われる。
ロールフォワード（REDO適用）とロールバック（UNDO適用）の2段階で構成される。
FAST_START_MTTR_TARGET で目標時間を調整できるが、オーバーヘッドに注意。
ディスク故障時には対応できないため、定期的なバックアップが必須。

本記事は Oracle Database 19c を対象に解説します（他バージョンは画面や既定値が異なる場合があります）。

[参考]
Oracle Database バックアップおよびリカバリ・ユーザーズ・ガイド 19c

💰 【PR】Oracleエンジニアの市場価値、調べてみませんか？

▶ テックゴー｜IT転職エージェントの無料キャリア面談