制御ファイルが全滅・・ぶっ壊れた！
データファイル全損障害時のリカバリと同様、
これも重めだが、バックアップが取れていればリカバリ可能だ。
ここではオンラインバックアップからの戻しを想定した、メディアリカバリの流れを解説する。
リカバリ手順
(1) アラートログを参照しエラー状態を確認
発生し得るエラーは、ORA-00205 などがある。
※以後、アラートログを参照しつつ作業することをお勧めする。
Unix/Linuxの場合は、tail -f コマンドが便利。
(2) データベースの接続確認
$ sqlplus / as sysdba
ログインできた場合は abort オプションで強制シャットダウン
この場合、デフォルトの normal や immediate は不可。
SQL> shutdown abort
(3) バックアップからデータファイルをリストア
オンラインバックアップで取得したデータファイルを OS コマンドで戻す。
(4) マウントモードで起動
$ sqlplus / as sysdba
停止状態のため、 アイドル・インスタンスへ接続 と表示される。
SQL> startup mount
正常にマウントされることを確認。
(5) リカバリ実施
SQL> recover database using backup controlfile;
後は自動的にアーカイブからリカバリが行われるが、
途中で以下が出力した場合は手動で対応が必要となる。
---------------------------------------------------------
検討すべきログ・ファイル:＜アーカイブログファイル＞
ログの指定: {=suggested | filename | AUTO | CANCEL}
---------------------------------------------------------
この場合、アーカイブログファイルのフルパスを指定し Enter を押下するのだが、
困ったことに、アーカイブログそのものが出力されていないのに、
ログ順序番号以上のファイルを要求される場合がある。
これは予想だが、ログスイッチされ順序番号が繰り上がったものの、障害の影響により、
アーカイブが正常に行われなかった可能性が高いのではないかと思う。
そこで、最新の REDO ログファイルを指定してみると対処が可能であった。
ログの指定: {=suggested | filename | AUTO | CANCEL}
この後に、REDOログファイルのフルパスを指定し Enter を押下。
正常に適用が行われると、以下のメッセージが出力される。
ログが適用されました。メディア・リカバリが完了しました。
(6) インスタンス起動(リセットログ)
SQL> alter database open resetlogs;
resetlogs オプションでインスタンスを起動する。
(ログ順序番号が1にリセットされる)
以上。可能なら復旧したタイミングで、コールドバックアップを取得。
