[DBA] バックアップおよびリカバリ
この連載も、とうとう今回で最後です。最後に学習するのはバックアップ・リカバリです！ バックアップ・リカバリはDBAの責務として非常に重要であり、Bronze DBA 12cの試験でも問われます。不測の障害に備えてバックアップを取得し、障害発生時には適切なリカバリを迅速に行う！ DBAとしてとてもカッコイイですね！ リカバリが必要な事態は、往々にして緊急性の高い場合が多いですが、そのような状況下で適切な処置を行うには正確な知識が必要不可欠です。バックアップ・リカバリは、真のOracle Databaseエキスパートになるため避けては通れない項目です。しっかり学習していきましょう！
Oracleのリカバリ機能について
ひとくちに「リカバリ」と言っても、障害の種類によって対応する方法は異なります。まずは、Oracleのリカバリ機能について確認しておきましょう。
- インスタンス障害による異常終了後の自動リカバリ
- ハード障害などによるメディアリカバリ
- ユーザー操作ミスに対してフラッシュバック・テクノロジを使ったリカバリ
（1）は、前回（第8回）のREDOログのところで説明した内容です。インスタンスが異常終了した際、次回起動時にバックグラウンドプロセスのSMONが自動的にリカバリをしてくれます。そして（2）が、今回のメインとなります。ハード障害等でデータファイルに欠落が出た場合にバックアップを用いて復旧します。（3）はユーザー操作ミスにより表を削除してしまった、あるいは不適切なデータ更新をしてしまった場合に、Oracleの機能であるフラッシュバック・テクノロジで復旧させるというもので、今回の最後の部分で説明していきます。まずはメディアリカバリのためのバックアップについて見ていきましょう。
バックアップのタイプ
バックアップのタイプは「一貫性バックアップ（オフラインバックアップ）」と「非一貫性バックアップ（オンラインバックアップ）」の2つに分けることができます。それぞれの特徴を確認していきましょう。まずは「一貫性バックアップ」についてです。
「一貫性バックアップ」の特徴
- データベースを停止させた状態で取得するバックアップ
- REDOログ内のすべてのコミット済の変更がデータファイルに適用されている
- 取得したバックアップをリストアするだけでデータベースをオープン可能
REDOログ内の変更履歴をすべてデータファイルに反映させるために、データベースは正常に停止する必要があります。データベースをオープンするために一貫性の取れた資源をまとめてコピー（バックアップ）して、障害発生時にはすべて戻す（リストア）といった感じです。以下の図でも確認しておきましょう。
一貫性バックアップ
（補足情報）
上記の図ではREDOログもバックアップしていますが、一貫性バックアップではREDO情報はすでにデータファイルに反映されていますので、取得は必須ではありません。
いかがですか？ 一貫性バックアップはイメージしやすいと思います。このバックアップとリストアによる復旧方法が基本ベースとなるので、しっかりと確認しておきましょう。次に「非一貫性バックアップ」について説明します。
「非一貫性バックアップ」の特徴
- データベースがオープンした状態で取得するバックアップ
- REDOログ内のすべてのコミット済の変更がデータファイルに適用されているとは限らない
- 取得したバックアップをリストア後にリカバリが必要
非一貫性バックアップは、オープン中に取得できるメリットがあります。ただしREDOログ内の変更履歴がデータファイルに反映されているとは限らないため、バックアップをリストア後にREDOログやアーカイブREDOログを適用するリカバリが別途必要になります。さて、新しく「アーカイブREDOログ」という用語が出てきました。以下の図を見ながら確認していきましょう。
非一貫性バックアップ
非一貫性バックアップを使ったリストア＆リカバリの流れを示しています。図の説明を少し補足しておきましょう。REDOログに番号が振られていますが、これはログ順序番号を示しています。ログスイッチすると、REDOログにはログ順序番号が割り当てられます。その他の各ファイルの番号は、その番号までREDOログの内容が反映されていると考えてください。3月26日に障害が発生したため、データファイルをリストアしています。その後リカバリには3月23日以降の変更内容として［10］［11］［12］［13］のREDOログが必要になります。REDOログは循環式で使用され古い情報は上書きされてしまうので、ログスイッチによる上書きの前に別ファイルに保存する必要があります。これがアーカイブREDOログになります。REDOログをアーカイブREDOログとして保存するのは、バックグラウンドプロセスのARCn（アーカイバ）の役目で、実行するためにはデータベースをARCHIVELOGモードに変更する必要があります。デフォルトのモードは、NOARCHIVELOGです。
24日と25日のREDOログはログスイッチで上書きされていますが、アーカイブREDOログとして残していますよね。リカバリにより、これらの情報を適用すれば障害発生直後の状態まで復旧ができるというわけです。
さぁ、ここまで確認したところで、問題に挑戦してみましょう！
非一貫性バックアップについて正しい内容をすべて選択してください。
（a）バックアップをリストア後、すぐにデータベースがオープンできる
（b）データベースがオープン時に取得することができるバックアップである
（c）データファイルに反映されていない変更内容をREDOログ、アーカイブREDOログを使用してリカバリができる
（d）バックアップをリストア後、リカバリ処理を実行する必要がある
選択肢（a）のようにリストアのみでデータベースがオープン可能なバックアップは、一貫性バックアップなので不正解です。選択肢（b）、（c）、（d）の内容は非一貫性バックアップについての説明となるのですべて正しいです。正解は （b）、（c）、（d）となります。
問題を続けます。
ARCHIVELOGモードの運用について、正しい内容を述べているものをすべて選択してください。
（a）データベースのデフォルトのモードである
（b）REDOログファイルのアーカイブ先としてデフォルトでは高速リカバリ領域が使われる
（c）トランザクションの完全リカバリが可能となる
（d）最後にバックアップした時点までのリカバリのみとなる
（e）データベースのオープン中にバックアップが取得できる
NOARCHIVELOGがデフォルトのモードなので選択肢（a）は誤りです。選択肢（b）の高速リカバリ領域とはバックアップやリカバリの際に使用するファイルを一元管理する領域と考えてください。アーカイブREDOログもデフォルトでこの領域に格納されていきます。高速リカバリ領域に関係する初期化パラメータも覚えておきましょう。
高速リカバリ領域関連の初期化パラメータ
| 初期化パラメータ | 説明 |
|---|---|
| db_recovery_file_dest | 高速リカバリ領域のデフォルトの位置を指定します。高速リカバリ領域には、アーカイブREDOログ、フラッシュバック・ログおよびRMANバックアップの他に、現行の制御ファイルやオンラインREDOログの多重コピーが含まれています |
| db_recovery_file_dest_size | 高速リカバリ領域で使用する最大サイズを指定します |
RMANはバックアップ・リカバリを行うための専用ツールであり、詳細は後述します。選択肢（b）は正しい内容となります。選択肢（c）の完全リカバリとは、REDOログ、アーカイブREDOログを適用してデータベースの障害発生直後の状態までリカバリすることを意味しており、ARCHIVELOGモードで運用の説明として正しい内容です。追加で「完全リカバリ」以外に「Point-in-timeリカバリ（不完全リカバリ）」があることも押さえておきましょう。Point-in-timeリカバリとは、データベースを過去のある時点の状態にまで復旧するリカバリのことです。復旧したい時点より古いバックアップをすべてリストアした後、戻したい時点までREDO情報を適用していきます。選択肢（d）は「最後にバックアップした時点のリカバリのみ……」と書いてあり、ARCHIVELOGモードの説明として適切ではありません。選択肢（e）はARCHIVELOGモードで可能なバックアップなので、正しい内容です。以上より正解は（b）、（c）、（e）となります。
さらに問題を解いていきましょう。
ARCHIVELOGモードで運用しているデータベースがあります。データベースの全体バックアップは取得しています。クリティカルではないUSERS表領域のデータファイルに障害が発生しました。リカバリ手順について最も適切な方法を選択してください。
1. USERS表領域をリカバリする
2. データベースインスタンスを停止する
3. データベースをMOUNT状態にする
4. バックアップからUSERS表領域のデータファイルをリストアする
5. USERS表領域をオフラインにする
6. データベースをOPENする
7. USERS表領域をオンラインにする
（a）2 → 3 → 4 → 1 → 6
（b）2 → 3 → 5 → 4 → 1 → 7 → 6
（c）5 → 4 → 1 → 7
（d）5 → 4 → 2 → 1 → 7 → 6
（e）2 → 5 → 4 → 1 → 7 → 6
リカバリの手順に関する問題です。まず用語の確認をします。全体バックアップというのは、その名の通りデータベース全体を対象とするバックアップであり、以下のファイルが対象になります。
- 制御ファイル
- すべてのデータファイル
- アーカイブREDOログ
- サーバー・パラメータ・ファイル
ARCHIVELOGモードで運用と書いてあるので、リストア後にリカバリが必要です。さて「クリティカルではない」というキーワードがこの問題の重要なポイントです。まず先に、クリティカルな表領域のデータファイルとは何かを考えましょう。クリティカルなファイルとはそのファイルが存在しないとデータベースのオープンを維持できないファイルのことで、SYSTEM表領域とUNDO表領域が該当します。これらの表領域のデータファイルに障害が発生した場合はデータベースを停止後、MOUNT状態にしてリカバリ処理を行います。逆にクリティカルでないファイルとはSYSTEM表領域、UNDO表領域以外のデータファイルのことで、これらの表領域のデータファイルに障害が発生した場合は、データベースをオープンにした状態で復旧することが可能です。
さぁ、これで選択肢はかなり絞れます。データベースの停止が不要ですので、選択肢（a）、（b）、（e）は除外できますね。データファイルをリストアする前に該当表領域はオフラインにする必要があり、選択肢（c）、（d）ともにオフライン処理後にリストアを行っていますが、選択肢（d）はその後データベースを停止しているので誤りです。したがって正解は（c）になります。
なお、クリティカルな表領域のファイルで障害が発生した場合の復旧方法は選択肢（a）の手順になるので、合わせて覚えておきましょう。
RMAN（Recovery Manager）を使用したバックアップ
Oracle Databaseには、RMAN（Recovery Manager）と呼ばれるバックアップやリカバリの専用ツールが標準で実装されています。RMANを使用するとバックアップの取得や管理の手順が非常に簡素化されて、ユーザー操作によるメンテナンスを軽減することが可能です。RMANで取得できるバックアップの種類について確認していきましょう。
イメージコピー
イメージコピーは、制御ファイル、データファイルまたはアーカイブREDOログのコピーです。OSのコピーコマンドで取得するのと同じと考えればいいでしょう。1つのファイルには1つのイメージコピーのみを含みます。以下は、データファイルのイメージコピーを取得している図です。
イメージコピーの模式図
バックアップセット
バックアップセットはRMAN独自のフォーマットで、1つ以上の制御ファイル、データファイル、アーカイブREDOログまたはサーバー・パラメータ・ファイルを含めることができます。バックアップセット内の物理ファイルのことをバックアップピースと呼び、バックアップセットは1つ以上のバックアップピースを含む論理単位となります。バックアップセットには未使用ブロックを含めないという圧縮機能があるため、イメージコピーより領域を節約できるメリットがあります。以下は、データファイルをバックアップセットで取得している図です。
データファイルをバックアップセットで取得する状態の模式図
RMANのデフォルトのバックアップ形式はバックアップセットになりますので、覚えておきましょう。
ではRMANのバックアップに関する問題をやってみます。
RMANを使用して取得するバックアップについて正しいものを1つ選択してください。
（a）RMANのバックアップではREDOログ、アーカイブREDOログを取得できる
（b）バックアップセットはOSのコピーコマンドで取得したものと同等のファイルである
（c）バックアップセットにサーバー・パラメータ・ファイルを含めることができる
（d）RMANのデフォルトのバックアップ形式はイメージコピーである
（e）RMANで取得する全体バックアップはイメージコピーのみ取得できる
選択肢（a）は正解のように見えますが、気をつけてください！ アーカイブREDOログはバックアップとして取得しますが、REDOログは取得しません。なぜでしょう？ それはバックアップしたREDOログはリカバリ時に必要がないからです。ARCHIVELOGモードの場合、ARCnプロセスがREDOログの内容をアーカイブREDOログに書き出していますよね。もし仮にバックアップしたREDOログを現在使用しているREDOログに上書きすると、最新の状態まで復旧することができなくなります。NOARCHIVELOGモードの場合は、一貫性のとれたバックアップを取得するためREDOログの情報はすでにデータファイルに反映されています。REDOログ自体の障害はREDOログを多重化することで対応します。結論として、バックアップにREDOログを含める必要がないということです。理解を深めるために、一貫性バックアップ、非一貫性バックアップの図を改めて確認してみるとよいでしょう。選択肢（b）はイメージコピーの説明なので誤りです。選択肢（c）は正しい内容であり、バックアップセットにはサーバー・パラメータ・ファイルを含めることが可能です。RMANのバックアップ形式はデフォルトがバックアップセットなので、選択肢（d）は誤りです。全体バックアップはバックアップセットでも取得できるので、選択肢（e）も誤りです。以上の結果から、正解は（c）となります。
RMAN（Recovery Manager）を使用したリカバリ
RMANには障害の診断から復旧のためのアドバイス、また自動で復旧処理を行ってくれるデータ・リカバリ・アドバイザという機能があります。非常に便利な機能ですね。以下にSYSTEM表領域のデータファイルに障害が発生した状態で、データ・リカバリ・アドバイザを使用した内容があるので確認しておきましょう。
STEP1：障害発生
SYSTEM表領域用のデータファイルにエラーが発生しているため、起動できません。
障害が発生し、データベースを起動できない
STEP2：認識している障害情報を表示
RMANで該当のデータベースに接続（rman target /）し、list failureコマンドを実行します。
list failureコマンドで障害情報を表示
※障害の診断が表示されない場合はvalidate databaseコマンドを実行し、検証チェックをします
STEP3：手動および自動の修復オプションを分析・決定
advise failureコマンドを実行し、修復オプション（自動および手動の両方）を決定します。
advise failureコマンドで修復オプションを決める
STEP4：障害を修復
repair failureコマンドを実行して自動的にリストア＆リカバリを実行します。
復旧後、データベースをオープンします。
repair failureコマンドでリストア＆リカバリを実行
データ・リカバリ・アドバイザの使用方法の流れがつかめたでしょうか。では1つ問題をやってみましょう。
推奨リカバリ計画を使用して障害を自動的に修復するRMANの機能を選択してください。
（a）自動データベース診断モニター（ADDM）
（b）自動ワークロードリポジトリ（AWR）
（c）メモリー・アドバイザ
（d）データ・リカバリ・アドバイザ
（e）SQLチューニング・アドバイザ
これはすぐに正解が分かったでしょう（笑）。正解は（d）ですね。
その他の選択肢にも注目してください。Oracleには様々なアドバイザがあり、Bronze DBA 12cの試験範囲として各アドバイザで何ができるのかを押さえておく必要があります。主なものを以下にまとめておきましたので参考にしてください。
主要なアドバイザ一覧
| アドバイザ名 | 説明 |
|---|---|
| ADDM （自動データベース診断モニター） | データベース全体のパフォーマンス診断を行う機能で、AWRスナップショットを分析し問題に対する推奨事項を生成する ※AWRスナップショットはデータベースの統計やワークロード情報などを一定間隔（デフォルトは60分）でSYSAUX表領域に格納する機能 |
| メモリー・アドバイザ | SGAやSGAの各コンポーネント、PGAといったメモリーサイズの最適化情報を提示する |
| SQLチューニング・アドバイザ | 単一のSQL文に対してパフォーマンスを向上させるための推奨事項（索引作成、SQLの書き換え、統計取得）を生成する |
| SQLアクセス・アドバイザ | 特定のSQLワークロードに対してのチューニング事項（索引作成やマテリアライズド・ビュー、パーティション表）を推奨する |
| UNDOアドバイザ | UNDO表領域の最小限必要なサイズを計算する |
| セグメントアドバイザ | 領域の断片化が存在しているセグメントを識別し、それらのセグメントの断片化を解消する方法について推奨事項を生成する |
フラッシュバック・テクノロジ
最後に、フラッシュバック・テクノロジについて学習します。主にユーザー操作ミスなどに対応するリカバリ機能で、バックアップをリストアする必要がありません。フラッシュバックの機能にはいくつかありますが、今回は「フラッシュバック表」と「フラッシュバックドロップ」を確認しましょう。
フラッシュバック機能
| フラッシュバック機能 | 使用データ | 説明 |
|---|---|---|
| フラッシュバック表 | UNDOデータ | 表内のコミット済みのデータを過去の特定の時点にまでリカバリする |
| フラッシュバック ドロップ | ゴミ箱 | DROPした表をゴミ箱から復旧させる |
フラッシュバックドロップの使用データが「ゴミ箱」とありますが、仮に誤って表をDROPしたとしても該当表領域には維持された状態で残り、管理表であるディクショナリに「削除した」という情報を格納する動作となります。Windows OSのゴミ箱を想像してください。ゴミ箱にファイルを捨てても、すぐに戻せますよね。あのイメージと同じと考えるとよいでしょう。
では最後の問題です！
以下の［操作1］と［操作2］を続けて実行しました。
［操作1］
CREATE TABLE TEST (a1 number);
INSERT INTO TEST VALUES(1);
COMMIT;
DROP TABLE TEST;
［操作2］
CREATE TABLE TEST (a1 number, a2 number);
INSERT INTO TEST VALUES(1,2);
COMMIT;
DROP TABLE TEST;
その後、以下のようにフラッシュバックドロップを実行しました。
FLASHBACK TABLE TEST TO BEFORE DROP;
この結果について正しい内容を述べているものを選択してください。
（a）［操作1］で作成したTEST表の内容がリカバリされる
（b）［操作2］で作成したTEST表の内容がリカバリされる
（c）ゴミ箱に同じ名前のオブジェクトがあるためTEST1、TEST2のように別名でリカバリされる
（d）ゴミ箱に同じ名前のオブジェクトがあるためエラーとなる
同じ名前の表が削除された場合、直前に削除された表をリカバリするため正解の選択肢は（b）になります。補足情報ですが、［操作1］で作成したTEST表はリカバリできないのか？ というとリカバリ可能です。user_recyclebinを検索し、ゴミ箱に入っているオブジェクト名を直接指定します。参考までに実行例を載せておきましょう。
（1）ゴミ箱内のオブジェクト名（object_name）を検索
ゴミ箱内を検索
（2）リカバリしたいobject_nameを指定
リカバリするオブジェクト名を指定
「フラッシュバック表」と「フラッシュバックドロップ」はマニュアルなどを確認して、実機にて実際に操作してみるとよいでしょう！
終わりに
ORACLE MASTER Bronze Oracle Database 12c資格取得を目指した連載、全9回を担当させていただきました。まだまだ書きたいこと、伝えたいこともあり名残惜しいですが…… 今回の連載内容が、少しでもお役に立てれば本当に幸いです。
第1回でもお話しましたが、ORACLE MASTERの資格は自らのモチベーションや市場価値を高め、お客様からの信頼を得られる資格です。Bronzeを取得しているということは、SQL文を理解し実行できること、Oracle Databaseを管理するための基本的な知識を持っていることを証明します。ぜひ、真のOracle Databaseエキスパートになるための第一歩を踏み出していただきたいと思います。
最後までお付き合いいただき、誠にありがとうございました！
* OracleとJavaは、Oracle Corporation 及びその子会社、関連会社の米国及びその他の国における登録商標です。文中の社名、商品名等は各社の商標または登録商標である場合があります。
