移行前に知っておきたい、Oracle Database 12c新機能のオモテとウラ Vol.7

前回はOracle Database 12c（以下、12c）のオプティマイザ新機能について解説しました。今回は、より細かいリカバリが可能になったバックアップ関連の新機能を紹介します。

機密情報を扱い、情報システムの中心とも言えるデータベースにとって、バックアップは欠かすことのできない重要な要素です。現在ではWebサービスやソーシャル・ネットワークなど、あらゆる場面で日常的にデータベースが使われる時代になっているため、データ損失によって多額の金銭的損害が発生するだけでなく、企業に対するマイナス・イメージが即座に伝播してしまいます。

ハードウェアの故障やオペレーション・ミスなどのリスクを抱えるデータベースにとって、バックアップはまさに保険とも言える存在ですが、バックアップさえ取得していれば安心かというと、決してそのようなことはありません。バックアップは戻す（リストアまたはリカバリする^※1ために取得するものなので、「何を」「どこまで」「どうやって」戻すのかというリカバリ要件をきちんと考えておく必要があります。これをやらないと、使えもしないバックアップを日々量産し続けることになってしまいます。

※1：Oracle Databaseでは、バックアップしたファイルを再配置することを「リストア」、そのファイルに変更履歴を適用してデータを回復させることを「リカバリ」と呼びます。

しかし実際には、こうしたリカバリ要件の検討を十分にできないままデータベースを運用しているケースが数多く存在します。以下のグラフは、弊社にて実施したリカバリの課題に関するアンケート結果をまとめたものです。意外なことに「リカバリを試したことがない」という回答が過半数を超えています。一度も障害が発生していなかったり、リカバリを試せる環境がないなど事情は様々ですが、有事の際にリカバリできないリスクを抱えているデータベースは少なくないようです。

具体的な失敗例を見てみましょう。A社のデータベースはアーカイブログ・モードで運用されており、毎日夜間バッチの前にRecovery Manager（以下、RMAN）による全体バックアップ（物理バックアップ）を取得しています。これまで一度も障害が発生していませんでしたが、ある日オペレーション・ミスにより誤って当日分と翌日分の夜間バッチが続けて実行されてしまいました。事前に作成しておいた翌日分のジョブを、流し忘れと勘違いして実行してしまったのです。これにより、いくつかの表が本来ではありえない状態に更新されてしまいました。

事態に気づいた担当者はすぐにジョブをキャンセルし、データベースのサポートに電話します。誤って更新された表だけを元に戻す方法がないか問い合わせましたが、サポートからは表領域のリストア・リカバリを案内されました。幸い手順書があったので問題なくコマンドを実行できたものの、表領域のサイズが大きすぎてリストアに時間がかかってしまい、翌朝の営業開始に間に合いませんでした。

A社のバックアップには2つの問題点があります。1つはリストアに必要な時間を把握できていなかったことです。せっかくバックアップを取得していても、決められた時間内にリストアできないのでは全く意味がありません。特にデータベースのサイズが大きい場合は、それに比例してリストア時間が長くならないような手法を検討するべきです。

もう1つは、リストア・リカバリの単位が大きすぎることです。データベース全体が壊れてしまうような障害ならまだしも、オペレーション・ミスによっていくつかの表を更新しただけで大規模なリストアが必要になるようでは、効率が良いとは言えません。

後者の解決策としては、Data Pumpによる論理バックアップや、フラッシュバック機能の利用などがあります。もしこれらを利用できれば、今回のようなオペレーション・ミスが発生したとしても短時間で対処することができます。ただし、RMANの物理バックアップが不要になるわけではないので、結果的にバックアップを2重で持ってしまうという欠点もあります。実際の運用でも、物理バックアップと論理バックアップを併用しているケースは珍しくありませんが、バックアップの時間が延びたり、バックアップ先の容量が不足したりといった新たな問題を抱えることになります。

このような状況を解消するため、12cではRMANのバックアップを使った表単位のPoint-in-Timeリカバリ（時間指定のリカバリ）ができるようになりました。RMANのバックアップさえ取得しておけば、データベースの全損から軽度のオペレーション・ミスまで幅広く対応できます。論理バックアップの代替としても使用できるので、バックアップの無駄をなくす効果もあります。機能の位置付けとしては、従来から使用できる表領域単位のPoint-in-Timeリカバリと同じく、Enterprise Editionの標準機能となっています。

表単位のPoint-in-Timeリカバリは、これまでにない一風変わった仕組みで動いています。リカバリが実行されると、対象のデータベースとは別に「補助データベース」が作成され、まずその中でリストアとリカバリを行います。リカバリが完了すると、そのデータをData Pumpでエクスポートし、対象のデータベースにインポートします。そして最後に補助データベースが削除され、一連の処理が完了します。つまり、過去の姿をしたデータベースを別に作り出して、そこからデータを復元しているのです。

一見すると無駄な動きが多いように思えますが、これらの動作はすべて自動的に行われるため、ユーザ側の作業が増えるということはありません。また、内部的にData Pumpのエクスポート／インポートを使用しているため、表の名前を変えてインポートしたり、ダンプ・ファイルだけを生成してインポートをしないといった使い方もできます。過去の表を別の名前でインポートし、現在の表とデータ差異を見比べるといったこともできるので、元の場所に戻すだけの従来型バックアップに比べて、使い勝手が大きく向上しています。

表単位のPoint-in-Timeリカバリを実際に行いながら、補助データベースの動きと使用上の注意点を見ていきましょう。検証に使用するのは、以下のシングル・データベースです。

「rectest表を誤って削除してしまった」というケースを想定し、表単位のPoint-in-Timeリカバリを行います。コマンドは非常にシンプルで、RECOVER TABLE文のUNTIL TIME句に時間、AUXILIARY DESTINATION句に補助データベースの場所をそれぞれ指定するだけです。あとはすべて自動的に処理が行われるため、難しい操作は必要ありません。今回は以下のコマンドでリカバリを行います。

実行後しばらくすると、以下のメッセージと共に補助データベース用のインスタンスが作成されます。初期化パラメータはすべて自動的に決定され、ユーザが指定することはできません。SGA_TARGETが1GBとかなり小さめに指定されており、既存のインスタンスに影響が出ないよう配慮したパラメータになっていることが分かります。

補助データベース用のインスタンスが起動すると、制御ファイル→データ・ファイルの順にリストアが行われます。リストアされるのはSYSTEM、SYSAUX、UNDOTBS1などデータベースに最低限必要な表領域のデータ・ファイルと、リカバリ対象の表が含まれる表領域のデータ・ファイルのみです。不要なデータ・ファイルはリストアされないというのが重要なポイントです。今回の例だと、IDX表領域のデータ・ファイルはリストアの対象外となっています。

ここで注意したいのが、リストアされるデータ・ファイルのサイズです。補助データベースだからと言って特別にサイズが小さくなるわけではなく、SYSTEMやSYSAUX、リカバリ対象の表を含むデータ・ファイルがそのままのサイズでリストアされます。例えば、500GBあるデータ・ファイルの中から1GBの表だけをリカバリしたいという場合でも、500GBをすべてリストアしなければなりません。領域不足の場合はエラーになるため、ストレージにはある程度の余裕が必要です。もし表単位のPoint-in-Timeリカバリを使用するのであれば、設計の段階で補助データベース用の領域を確保しておくようにしましょう。

補助データベースのリストア・リカバリが終わると、Data Pumpによる表のExportが行われます。Exportのダンプ・ファイルは補助データベースと異なる場所に配置することもできるので、領域に余裕がない場合は分散して配置することを検討してください。

最後にImportが行われ、リカバリ処理が完了します。補助データベースやダンプ・ファイルはすべて自動的に削除され、リカバリのために使用していた領域はすべて解放されます。

以上が表単位のPoint-in-Timeリカバリにおける一連の動作です。コマンドを1行入力するだけで補助データベースの作成からリカバリまで自動的に行ってくれるため、非常に簡単で実用的な機能であると言えます。

ただし、何度か取り上げたように、処理の途中で補助データベースを作成したり、ダンプ・ファイルを生成する箇所があるので、領域不足には注意してください。表単位のPoint-in-Timeリカバリで生成されるファイルをまとめると以下のようになります。これらのファイルがすべて同時に存在できるだけの領域があるかを確認してからリカバリを行うようにしましょう。なお、今回の検証では、5GBの表をリカバリするのに補助データベース ＋ ダンプ・ファイル + アーカイブログ・ファイルで合計約30GBの領域が必要となりました。

また、今回は該当しませんでしたが、表がSYSスキーマの所有物である場合や、SYSTEMおよびSYSAUX表領域に作成されている場合はリカバリができないという制限があります。

領域と制限事項に注意しながら使用すれば、これまで対応できなかった短時間での復旧や、過去データの一時的な参照など様々な場面で役立つ「使えるバックアップ」になることは間違いありませんので、12cにアップグレードする際は、バックアップも併せて見直してみることをお勧めします。

・移行前に知っておきたい、Oracle Database 12c新機能のオモテとウラ Vol.1
・移行前に知っておきたい、Oracle Database 12c新機能のオモテとウラ Vol.2
・移行前に知っておきたい、Oracle Database 12c新機能のオモテとウラ Vol.3
・移行前に知っておきたい、Oracle Database 12c新機能のオモテとウラ Vol.4
・移行前に知っておきたい、Oracle Database 12c新機能のオモテとウラ Vol.5
・移行前に知っておきたい、Oracle Database 12c新機能のオモテとウラ Vol.6

最後までご覧いただきありがとうございました。
本記事でご紹介した製品・サービスに関するコンテンツをご用意しています。また、この記事の他にも、IT技術情報に関する執筆記事を多数公開しておりますのでぜひご覧ください。