ユーザー管理のバックアップとリカバリ：独学！ ORACLE MASTER Gold 11g講座（10）（2/2 ページ）
不完全リカバリ
ユーザー管理による不完全リカバリの場合、回復に使うバックアップファイルを選ぶ必要があります。
完全リカバリでは、一番最近に取得したバックアップをリストアすればよいのですが、不完全リカバリでは復旧したい時点よりも過去にさかのぼって取得してあるバックアップを、全データファイルについてリストアする必要があるからです。
その他、全体的な流れを以下のコマンドとともに確認します。
時間ベースの不完全リカバリ
1．データベースを停止します。
SQL> SHUTDOWN IMMEDIATE
2．全てのデータファイルについて、目的の時間に戻ることが可能なバックアップを、元のデータファイル位置にコピーします。
3．マウントモードで起動します。
SQL> STARTUP MOUNT
4．時間指定を付け加えたRECOVER コマンドを実行します。
SQL> RECOVER AUTOMATIC DATABASE UNTIL TIME '2011-11-23 12:43:56';
5．RESETLOGS オプションでデータベースをオープンします。
SQL> ALTER DATABASE OPEN RESETLOGS;
取り消しベースの不完全リカバリ
取り消しベースとは、RMANでいうところの「ログ順序ベースのリカバリ」と同等の作業です。不完全リカバリを行う理由については第8回を参照してください。
今回は、ログ順序番号59番が壊れたため、58番までのログを全て適用するという想定で、ご紹介します。
1．データベースが停止していない場合は、データベースを停止します。
2．全てのデータファイルについて、58番のアーカイブログ取得時点よりも過去のバックアップを元のデータファイル位置にコピーします。
3．マウントモードで起動します。
4．RECOVERコマンドを実行します。
SQL> RECOVER DATABASE UNTIL CANCEL;
このコマンドで、適用するログファイルを聞いてくるので、Enterキー、あるいはファイルパスの入力で応答していきます。今回は、所定の位置にアーカイブログが存在する前提で、適用対象の58番まで、Enterとします。
ORA-00279: 変更1187562(11/18/2011 17:18:24で生成)にはスレッド1が必要です
ORA-00289: 検討すべきログ・ファイル:/home/oracle/arch/1_56_750707953.dbf
ORA-00280: 変更1187562(スレッド1)は順序番号56に存在します。
ログの指定: {<RET>=suggested | filename | AUTO | CANCEL}
-- Enterを入力
ORA-00278: ログ・ファイル'/home/oracle/arch/1_56_750707953.dbf'はこのリカバリでは必要なくなりました
ORA-00279: 変更1189558(11/18/2011 17:21:13で生成)にはスレッド1が必要です
ORA-00289: 検討すべきログ・ファイル:/home/oracle/arch/1_57_750707953.dbf
ORA-00280: 変更1189558(スレッド1)は順序番号57に存在します。
-- 58番までEnter入力
59番において、「CANCEL」と入力します。
ORA-00279: 変更1190815(11/18/2011 17:21:16で生成)にはスレッド1が必要です
ORA-00289: 検討すべきログ・ファイル:/home/oracle/arch/1_59_750707953.dbf
ORA-00280: 変更1190815(スレッド1)は順序番号59に存在します。
ログの指定: {<RET>=suggested | filename | AUTO | CANCEL}
CANCEL -- CANCEL と入力してください
メディア・リカバリが取り消されました。
5．RESETLOGS オプションでデータベースをオープンします。
SQL> ALTER DATABASE OPEN RESETLOGS;
以上が、ユーザー管理のリカバリ方法です。バックアップの取得履歴を、私たち自身で確認しますので、特に不完全リカバリでは、どのバックアップを使えばいいのかという判断が必要になります。コマンド的な観点では当然RMANを利用した方が便利です。
ですが、ストレージシステムが持つファイルのバックアップ機能と併用することで、バックアップ時間を数秒にしてしまうことも可能です。費用対効果を考慮する必要が出てきますが、バックアップ負荷が懸念される場合には、ハードウェア構成を整え、ユーザー管理バックアップを運用計画の中に取り入れるソリューションが存在します。
一時表領域のリカバリ
一時表領域は、ソートデータなど、SQL処理においてメモリ上で処理しきれないデータを退避させるための領域です。一時表領域を構成するファイルは「一時ファイル」と呼ばれます。この領域に記録する内容は、作業中のみ必要であり、永久に保存し続ける必要はありません。
ひと言で説明すると「壊れたら作り直せばよい」というスタンスでリカバリに望みます。
データベースのオープン時に一時ファイルの損失を検出した場合、Oracle は、壊れた一時ファイルを自動的に作成し直します。インスタンス稼働中に、エラーが検出された場合は、手動で作り直します。一時ファイルを別途追加し、壊れた一時ファイルの登録を削除します。以下のコマンドがその流れです。
SQL> ALTER TABLESPACE 一時表領域名 2> ADD TEMPFILE '新規追加のファイルパス' SIZE ファイルサイズ; SQL> ALTER TABLESPACE 一時表領域名 2> DROP TEMPFILE '壊れたのファイルパス';
次回は、再びRMANに使り、バックアップ＆リカバリを応用した機能を紹介します。
問題1
データベースをARCHIVELOGモードで稼働しています。
ALTER TABLESPACE 表領域名 BEGIN BACKUP;
を発行した場合の正しい説明は、次のうちどれか選びなさい。
a. 表領域がバックアップモードの時は追加のREDOログが生成される
b. バックアップモードの表領域は各DBブロックヘッダが固定される
c. バックアップモードの表領域は、データファイルがオフラインになりコピーに備える
d. 一時表領域のバックアップには、BEGIN バックアップコマンドは必要ない
正解：a
●解説
b.についてはバックアップのときにロックされるのはファイルヘッダでありブロックヘッダではありません。
c.については、オンラインのままバックアップ可能にするモードがバックアップモードです
d.については、一時表領域のファイルはそもそもオンラインでバックアップをする必要がありません。
問題2
SYSAUX表領域がクラッシュしました。データベースはARCHIVELOGモードで稼働しており、SYSAUX表領域のデータファイルは、ユーザー管理のバックアップが行われています。次の（1）〜（9）を最も素早く復旧できる手順にしたものを選びなさい。
（1） SYSAUX表領域をオフラインにする
（2） インスタンスを停止する
（3） SYSAUX表領域をリストアする
（4） SYSAUX表領域とSYSTEM表領域をリストアする
（5） インスタンスをマウント状態にする
（6） SYSAUX表領域をリカバリする
（7） SYSAUX表領域とSYSTEM表領域をリカバリする
（8） SYSAUX表領域をオンラインにする
（9） データベースをオープンにする
a. （1） → （3） → （7） → （8） → （9）
b. （2） → （3） → （5） → （9） → （8）
c. （2） → （4） → （5） → （7） → （9）
d. （1） → （3） → （6） → （8）
正解：d
●解説
SYSTEM表領域か、UNDO表領域が壊れた場合は、インスタンスを停止する必要がありますが、今回はその必要がありません。また復旧対象の表領域もSYSAUXのみで大丈夫です。
問題3
カレントのREDOログが全滅したため、不完全リカバリを行う必要がある。どのユーザー管理不完全リカバリを選ぶべきか。
a. ログ順序ベース
b. 時間ベース
c. 取り消しベース
d. 変更ベース
正解：c
●解説
カレントのREDOログ損失について詳細は第9回をご覧ください。その際の不完全リカバリはREDOログ単位で復旧ポイントを決定する「a.ログ順序ベース」か「c.取り消しベース」を選びます。両者とも同等の作業ですが、問題文中にユーザー管理と指定されていますので「c.取り消しベース」が正解です。
Copyright © ITmedia, Inc. All Rights Reserved.
注目のテーマ
ITmediaはアイティメディア株式会社の登録商標です。