RMAN によるリストアとリカバリ

Oracleレベル: 上級所要時間: 30 分~数時間 (データベースのサイズによる)

障害発生時に適切な RMAN リカバリを手順どおりに実施します。19 のシナリオ: データファイル、SYSTEM/UNDO、一時ファイル、破損ブロック、オンライン REDO ログ、制御ファイル、spfile の損失、全体リストア、別ディレクトリ/ASM および別サーバーへのリストア、ポイントインタイムリカバリ (CDB または PDB PITR)、Flashback Database、表領域 PITR、単一表のリカバリ (RECOVER TABLE)、削除された PDB、Data Guard からのネットワーク経由リストア (FROM SERVICE)、アーカイブログのみのリストア、移動したバックアップの登録 (CATALOG)、データを書き込まない予行演習 (PREVIEW/VALIDATE)。各シナリオは診断 → セーフティネット → 実施 → 検証 → 新規バックアップの順に進み、シングルインスタンス、Oracle Restart、RAC (CLUSTER_DATABASE=FALSE で単一インスタンスからリカバリ) で別々の手順を示します。扱うのはバックアップの取得ではなくリカバリです。バックアップ計画については「Oracle バックアップ戦略」ガイドを参照してください。

構成: サーバー 1 台 (シングルインスタンスまたは Oracle Restart) または RAC。新規ホストのシナリオではソース + ターゲット

シナリオ

予行演習: RESTORE … PREVIEW / VALIDATE (何も変更しない) — 何も壊れていませんが、バックアップが本当にリカバリに足りるかをデータを書き込まずに確認したい場合です (データベースはオープンのまま)。月次のリストア訓練や、どのシナリオを選ぶべきか確信がないときの最初の手順でもあります。
バックアップを別ディレクトリへ移動した / RMAN がバックアップを見つけられない (CATALOG) — バックアップピースは存在するが RMAN が認識していない (移動した、NFS が変わった、別サーバーから持ってきた) ため、RMAN-06023/06025 が出ます。データベースはオープンのままです。
アーカイブログのみリストアする (RESTORE ARCHIVELOG) — LogMiner、スタンバイのギャップ解消または手動リカバリのために、特定の順序番号範囲のアーカイブログがディスク上に必要な場合です。データベースはオープンのままで、どのファイルも上書きされません。
単一のデータファイルまたは表領域の損失/破損 (データベースはオープンのまま) — データベースはオープンしており、1 つのデータファイルまたは表領域だけが読めません (ORA-01157/01110/01116)。それ以外はすべて動作しています。ファイルが SYSTEM/UNDO に属する場合は「SYSTEM または UNDO」、一時ファイルの場合は「一時ファイル」、ファイルは開けるが数ブロックが破損している場合 (ORA-01578) は「破損ブロック」のカードを選んでください。
破損ブロックがある (ORA-01578、ブロックメディアリカバリ) — 問合せで ORA-01578/ORA-26040 が出る、バックアップが ORA-19566 で停止する、または VALIDATE で破損ブロックが見つかった場合です。ファイルの残りは健全です。データベースはオープンのままで、破損したブロックだけを修復します (Enterprise Edition。SE2 ではファイルをリストアします)。ファイル全体が開けない場合 (ORA-01157) は「単一のデータファイル」カードを使います。
SYSTEM または UNDO のデータファイルを損失 (データベースがオープンしない) — 損失または破損したファイルが SYSTEM または UNDO 表領域に属しています。オフラインにできないため、データベース (PDB のファイルであればその PDB のみ) を停止し、MOUNT 状態でリストアします。データ損失はありません。他の表領域のファイルであれば、「単一のデータファイル」カードでデータベースを停止せずに対処できます。
一時ファイルの損失または破損 (TEMP 表領域) — ソート/ハッシュ処理で ORA-01157/ORA-01187/ORA-25153 が出ており、ファイルが一時ファイルである場合です (エラーメッセージ中の番号が db_files の値より大きい。例: data file 201)。リストアは不要で、新しい一時ファイルを追加します。データベースはオープンのままです。
オンライン REDO ログの損失または破損 — アラートログに ORA-00313/00312 (オープンできない) または ORA-00327/00366/00367 (破損) が出ています。1 つのメンバーだけを損失した場合やグループが INACTIVE の場合、データベースはオープンのままです。CURRENT グループを損失した場合はリストア + RESETLOGS が必要で、直近のトランザクションは失われます。グループの状態は診断手順で表示されるので、それに従って選択してください。
制御ファイルのすべてのコピーを損失 — インスタンスが MOUNT 段階で制御ファイルを見つけられない、または読めません (ORA-00205/00202/00210)。データファイルと REDO は健全です。コピーのいずれかが健全ならリストアは不要です (診断手順で分かります)。すべて損失した場合は autobackup からリストアして RESETLOGS でオープンします。オンライン REDO が健全なのでデータ損失はありません。
spfile 損失 — spfile が削除または破損しました。インスタンスが起動しない (ORA-01078/LRM-00109)、または起動中だがファイルがない状態です。データファイルには触れず、データ損失はありません。インスタンスがまだ起動中であれば停止時間も発生しません。
全体リストア、同一サーバー (データファイルを損失。制御ファイルと REDO は健全) — データファイルのすべてまたは大半が失われ、制御ファイルとオンライン REDO ログは健全な場合です。データベースは停止しますが、データ損失はありません。ファイルがあった旧ディスク/ディレクトリがもう使えない場合は「別ディレクトリ」カード、制御ファイルも損失している場合はまず「制御ファイル」カード、サーバーが完全に失われた場合は「別サーバーへのリストア」カードを選んでください。
ディスク喪失: データベースを別ディレクトリ / ASM へリストアする (SET NEWNAME) — データファイルが置かれていたディスクまたはディスクグループが使用できません。制御ファイルと REDO は健全です。ファイルを新しいディレクトリまたは ASM ディスクグループへリストアします。データベースは停止しますが、データ損失はありません。
時点 / SCN へのリカバリ (PITR、RESETLOGS) — 誤った DELETE/UPDATE/TRUNCATE や不具合のあるアプリケーションのリリースに対し、データベース (または PDB のみ) を過去の時点に戻します。その時点以降の変更はすべて失われます (RESETLOGS)。まず範囲の狭い方法を検討してください: 単一の表 →「単一の表をリカバリ」、単一の表領域 → TSPITR、フラッシュバックが有効 →「Flashback Database」(リストア不要で、はるかに高速)。
Flashback Database で巻き戻す (リストアポイント / SCN / 時刻) — フラッシュバックが有効、または保証付きリストアポイントがあり、どのファイルも損失していない場合、リストアせずに数分で巻き戻せます (Enterprise Edition)。RESETLOGS が必要です。有効かどうか: SELECT flashback_on FROM v$database; → YES、または v$restore_point に GUARANTEE_FLASHBACK_DATABASE = YES の行がある。
表領域を過去の時点に戻す (TSPITR) — 誤った操作が 1 つの表領域内のオブジェクトだけに影響し、データベースの残りは現在のままにしておく必要がある場合です (Enterprise Edition)。処理中その表領域はオフラインになり、中のオブジェクトはすべて目標時点に戻ります。影響を受けたのが 1、2 個の表だけなら、「単一の表をリカバリ」のほうが戻す範囲が小さくて済みます。
単一の表をリカバリする (RECOVER TABLE、12c 以降の Enterprise Edition) — 1 つの表が誤って削除または破損し、データベースの残りはそのままにしておく必要がある場合です (12c 以降の Enterprise Edition)。DROP されて PURGE されていなければ、まずごみ箱を確認してください: FLASHBACK TABLE … TO BEFORE DROP なら数秒で済みます (診断手順で表示されます)。
削除された PDB を元に戻す (DROP PLUGGABLE DATABASE) — PDB が DROP PLUGGABLE DATABASE で削除されました。ファイルが残っていれば XML で再度プラグインします。ファイルも削除されていればバックアップから戻します (21c 以降は 1 コマンド、19c は一時 CDB 経由)。CDB はオープンのままです。
別サーバーへのリストア (新規ホスト、制御ファイルの autobackup から) — サーバーが完全に失われた、またはコピー/テスト環境を構築する場合に、バックアップを別のサーバーへリストアします (シングルインスタンス、ファイルシステムのみ)。バックアップ済みの最後のアーカイブログまでリカバリし、それ以降は失われます。コピーは RESETLOGS でオープンします。
Data Guard: ファイルをスタンバイ/プライマリからネットワーク経由で取得する (FROM SERVICE) — Data Guard がある場合、プライマリで損失したデータファイルをスタンバイから、遅れているスタンバイや損失したスタンバイ制御ファイルをプライマリから、バックアップピースを使わずに取得できます (12c 以降)。

開始前の確認

インシデントを記録し、アプリケーションチームに連絡済みです: いつ、何が起きたか、どのエラーメッセージか。リカバリ開始前に現状のコピーを取得できる場合は取得済みです (サーバー/ディスクのスナップショット、少なくとも残っているデータファイル、制御ファイル、オンライン REDO ログのコピー)。誤った手順で状況がさらに悪化する可能性があります。
バックアップにアクセスできる (マウント済みで読み取り可能): …… と、アーカイブログ用の FRA ……。バックアップがテープ/MML にある場合は、SBT チャネルとソフトウェアのエージェントが動作している。
DBID が分かっている (…)。分からない場合: 過去の RMAN ログの connected to target database: … (DBID=…) の行…、または autobackup のファイル名 (…_cf_c-<DBID>-<YYYYMMDD>-<nn>)…。
補助ディレクトリ … が存在し、SYSTEM + SYSAUX + UNDO + 表の表領域分の空き領域がある。サーバーには一時インスタンス用に約 2 GB の空きメモリがある。
…RECOVER TABLE ("Recovering tables and table partitions from RMAN backups") は Enterprise Edition の機能です。…Standard Edition 2 には RECOVER TABLE がありません。以下の手順の代わりに、バックアップを別サーバーにリストアし (「別サーバーへのリストア」+ PITR)、Data Pump で表を取り出してください。…
ターゲットサーバーに同じ Oracle バージョン、同じ RU レベルがソフトウェアのみでインストールされている (opatch lspatches が両側で同じ)、oracle ユーザー/グループとディレクトリ構成がソースと同じ、ディスク容量が十分にある。ターゲットで同じ名前のデータベースが稼働していない。
メンテナンス/停止時間の枠が承認済み… (このシナリオではデータベースはオープンのままで、影響を受けるのは対象オブジェクトのみ)…。バックアップのスケジューラ (cron/systemd/scheduler) はリカバリ完了まで停止済み。停止しないと、作業の途中でバックアップや DELETE OBSOLETE が実行されるおそれがあります。
Clusterware の登録内容が分かっている: spfile とパスワードファイルの場所、…インスタンスとノード…データベースの状態… (srvctl config database -db …)。この出力はリカバリ前に保存しておいてください。
…Block media recovery…Tablespace point-in-time recovery…Flashback Database… は Enterprise Edition の機能で、Standard Edition 2 ではコマンドが動作しません。このシナリオの SE2 での手順は各ステップで別途示します。
一時 (補助) インスタンス用に、ディレクトリ …………… に SYSTEM + SYSAUX + UNDO… + …… + PDB… 分の空き領域があり、サーバーにも少なくともターゲットの sga_target 分の空きメモリがある (RMAN はデフォルトで一時インスタンスに同じ SGA を割り当てます)。
Data Guard の準備ができている: 両側でパスワードファイルが同じ (SYS または SYSBACKUP のパスワードが同じ)、このサーバーの tnsnames.ora に … と … のエントリがある、COMPATIBLE ≥ 12.0。FROM SERVICE は OS 認証 (rman target /) では動作しません。RMAN はパスワードで接続します。
Flashback Database 用に FRA が定義されており、フラッシュバックロギングが有効 (FLASHBACK_ON = YES) か、目標時点が保証付きリストアポイントである。どのデータファイルも損失/破損していない (フラッシュバックでは損失したファイルは戻りません)。目標時点以降にデータファイルの縮小 (shrink) や制御ファイルの再作成を行っていない。

ガイドのフェーズ

状況把握 — 状況を把握する · 状況を把握する · ごみ箱を確認する (DROP ならバックアップ不要の可能性) · 目標時点を決める
必要なバックアップはあるか — インスタンスを MOUNT モードで起動する · インスタンスを MOUNT モードで起動する (srvctl) · バックアップを一覧表示する · autobackup ファイルを探す · リカバリをプレビューする (PREVIEW) · バックアップピースを読み取って検証する (VALIDATE) …
データファイル / 表領域のリカバリ (オンライン) — … をオフラインにする · … をリストアしてリカバリする · … をオンラインにする
全体リストア (同一サーバー) — データベースをリストア、リカバリしてオープンする · …クラスタモードに戻し、Clusterware でデータベースを起動する…Clusterware (Oracle Restart) でデータベースを再起動する…
時点 / SCN へのリカバリ (PITR) — 戻す前に現在の状態をバックアップする · データベースを単一インスタンスで MOUNT にする (srvctl) · …PDB…データベース…を目標時点に戻す · …クラスタモードに戻し、Clusterware でデータベースを起動する…Clusterware (Oracle Restart) でデータベースを再起動する…
単一の表をリカバリする (RECOVER TABLE) — 補助ディレクトリを準備する · 目標時点から表をリカバリする · 戻ったデータを比較する
制御ファイルのリカバリ — 制御ファイルのコピーが残っているか確認する · 制御ファイルのコピーが残っているか確認する (ASM) · インスタンスを NOMOUNT で起動する (srvctl) · 制御ファイルを autobackup からリストアしてオープンする · …クラスタモードに戻し、Clusterware でデータベースを起動する…Clusterware (Oracle Restart) でデータベースを再起動する…
spfile のリカバリ — メモリ上のパラメータから spfile を書き直す · メモリ上のパラメータから spfile を ASM に書き込む · spfile を autobackup からリストアする · spfile を autobackup から ASM にリストアする · インスタンスが spfile で起動したことを確認する
ソースサーバー: 情報を収集してバックアップを転送する — 最新のバックアップを取得する · DBID、autobackup、ディレクトリ一覧を書き出す · バックアップとパスワードファイルをターゲットにコピーする
ターゲットサーバー: リストアとリカバリ — ディレクトリを作成する · oratab のエントリを追加する · spfile と制御ファイルをリストアして MOUNT する · バックアップピースを登録する (CATALOG) · リストアし、最後のアーカイブログまでリカバリしてオープンする · コピーをソースから切り離す (任意)
診断: RMAN がバックアップを見つけられない理由 — バックアップピースの新しい場所を確認する · RMAN が把握しているバックアップと不足しているものを一覧表示する
セーフティネット — 制御ファイルの現在の状態をコピーする
バックアップを RMAN に登録する — 新しいディレクトリのピースを登録する (CATALOG START WITH) · 旧所在地の記録を削除する
検証: バックアップが見つかるようになったか — リカバリを再度プレビューする · バックアップスクリプトを新しい場所に合わせて修正する
診断: どのアーカイブログが必要で、バックアップにあるか — アーカイブログがディスク上にあるか確認する · アーカイブログのバックアップを探してプレビューする
セーフティネット: リストア先ディレクトリと空き領域 — リストア先ディレクトリを準備する
アーカイブログをリストアする — アーカイブログをリストアする (RESTORE ARCHIVELOG)
検証と後片付け — リストアしたアーカイブログを一覧表示する · 作業後にリストアしたアーカイブログを削除する
診断: 破損ブロックか — ファイルをスキャンする (VALIDATE) · 破損ブロックとその所属オブジェクトを一覧表示する
セーフティネット: 健全なコピーとアーカイブの連続性があるか — ファイルのバックアップとリカバリの連続性をプレビューする
破損ブロックを修復する — 破損ブロックをバックアップから修復する (RECOVER CORRUPTION LIST) · Standard Edition 2: データファイルをリストアする · NOLOGGING ブロックを修正する (ある場合)
検証: ブロックは健全か — ファイルを再スキャンする · 根本原因を調べる: ディスクとストレージのエラー
診断: ファイルは SYSTEM または UNDO か — インスタンスを MOUNT モードで起動する · インスタンスを MOUNT モードで起動する (srvctl) · ファイルが SYSTEM または UNDO であることを確認する · 必要なバックアップをプレビューして検証する
セーフティネット — 制御ファイルの現在の状態をコピーする
SYSTEM / UNDO データファイルをリストアする — PDB をクローズする · データファイルをリストア、リカバリしてオープンする · …クラスタモードに戻し、Clusterware でデータベースを起動する…Clusterware (Oracle Restart) でデータベースを再起動する…
診断: 損失したファイルは一時ファイルか — 一時ファイルとその状態を確認する · ファイルとアラートログを確認する
セーフティネット: 空き領域の確認 — 新しい一時ファイル用の空き領域を確認する
新しい一時ファイルを追加し、損失したファイルを削除する — 新しい一時ファイルを追加し、損失したファイルを削除する
検証 — 一時表領域を検証する
診断: どのグループが、どの状態か — REDO ロググループの状態を確認する

環境に合わせた手順プランを開く →