>> 連載トップページに戻る

 

基本からわかる!高性能×高可用性データベースシステムの作り方

第8回 バックアップ/リカバリ(3)RMAN増分バックアップとリストア/リカバリ


著者紹介


日下部 明 (くさかべ あきら)

日本オラクル Oracle Database担当。Oracle GRID Centerのラインマネージャとしてオラクルの持つ最新技術をパートナー各社と共同で検証し、多くのホワイトペーパーを執筆・レビューしてきました。以後、Oracle Databaseのセキュリティ製品のリリースマネージャを担当。これらの経験を元にミッションクリティカルな案件のソリューションデザインの提案などを担当しています。著書に「これは使えるOracle新機能活用術」(翔泳社)。


第8回 バックアップ/リカバリ(3)RMAN増分バックアップとリストア/リカバリ


第7回ではRMANのバックアップ/リカバリの仕組みと、データ・リカバリ・アドバイザについて説明しました。今回は、バックアップ・ファイルのサイズを小さくする増分バックアップを扱います。増分バックアップをリストア/リカバリするには、どのバックアップ・ファイルをリストアし、どこの時点のREDOログからリカバリが開始されるのでしょうか。増分バックアップの欠点を改善する増分更新バックアップについても解説します。


1 フルバックアップからのリストア/リカバリ

データベースの障害に備え、バックアップを取得しておくことは実質的に必須の運用です。最も基本的なバックアップは、データファイル全体を取得するフルバックアップです。フルバックアップを取得したデータベースでデータファイルに障害が発生した場合、リカバリ、つまりREDOログの適用はデータファイルのバックアップの取得を開始した時点からになります。そのため、リカバリ時間を最小にするためには、リストアするデータファイルは最も新しいバックアップからのものを優先します。RMANでは、フルバックアップを複数世代保持していると、restoreコマンドは自動的に最新のフルバックアップからリストアします。

img-1

フルバックアップのメリットは、すべてのデータブロックの直近のバックアップがあるため、リカバリ時間が最小になることです。リカバリ時間の観点からは、バックアップの間隔は短い方が良いのですが、フルバックアップをローカル・ストレージに何世代も保持することはストレージ容量の観点からはあまり現実的ではありません。そこで、前回のバックアップから更新されたデータブロックのみをコピーするという増分バックアップの機能がRMANにはあります。

2 増分バックアップ

Oracle DatabaseではSystem Change Number(SCN)という単調増加するカウンタで更新の順序を管理しています。データファイルの各データブロックは更新されたときのSCNを記録しており、前回のバックアップ時点のSCNと比較することで、前回のバックアップから更新されたかを判断することができます。

増分バックアップの起点となるすべてのデータブロックのバックアップをlevel 0と呼びます。フルバックアップもlevel 0増分バックアップのどちらもすべてのデータブロックをコピーするというものですが、意味としては異なります。増分バックアップを取得するには、フルバックアップではなく増分バックアップのlevel 0をまず取得する必要があります。level 0の増分バックアップを取得するコマンドは以下のようになります。

RMAN> backup incremental level 0 database;

level 0の時点から更新されたデータブロックの増分バックアップをlevel 1と呼びます。増分バックアップは前回のバックアップ時点から更新されたブロックを抜き出したものですが、「前回のバックアップ」が何を指すかによって、差分増分バックアップと累積増分バックアップの2種類があります。

img-2

差分増分バックアップは前回の増分バックアップ時点から更新されたデータブロックを抜き出します。1回目のlevel 1はlevel 0からの増分ですが、2回目以降のlevel 1は前回のlevel 1からの増分です。差分増分バックアップのコマンドは以下のようになります。

RMAN> backup incremental level 1;

累積増分バックアップはlevel 0増分バックアップ時点から更新されたデータブロックを抜き出します。1回目のlevel 1はlevel 0からの増分です。そして、2回目以降のlevel 1もlevel 0からの増分です。そのため、累積増分バックアップのファイル・サイズはバックアップを取得するにつれ徐々に大きくなっていきます。累積増分バックアップのコマンドはcumulativeというキーワードが付きます。

RMAN> backup incremental cumulative level 1;

累積増分バックアップよりも差分増分バックアップの方がlevel 1バックアップのファイル・サイズが小さくなるため優れているように思えますが、必ずしもそうとは言い切れません。違いはリストア/リカバリにも現れます。

3 増分バックアップからのリストア/リカバリ

level 1バックアップはデータファイルの断片であるため、リストア/リカバリするためにはまず起点となるlevel 0バックアップをリストアします。その上にlevel 1バックアップをリストアします。差分増分バックアップと累積増分バックアップでは、どのlevel 1バックアップをリストアするかが異なります。

3.1 差分増分バックアップからのリストア/リカバリ

差分増分バックアップは前回の差分増分バックアップからの増分であるため、リストアするのはlevel 0とすべてのlevel 1になります。

img-3

差分増分バックアップからのリストア/リカバリもフルバックアップの場合と同様にRMANのrestoreコマンドとrecoverコマンドを使用します。restoreコマンドを発行するとlevel 0バックアップがリストアされます。

RMAN> restore datafile xx;

そして、level 1バックアップがリストアされるのはrecoverコマンドを発行したときです。

RMAN> recover datafile xx;

recoverコマンドを発行すると、RMANはすべてのlevel 1差分増分バックアップを正しい順序でリストアし、REDOログを適用します。REDOログの適用は最新のlevel 1を取得したところからです。

3.2 累積増分バックアップからのリストア/リカバリ

累積増分バックアップはlevel 0からの増分であるため、最新のlevel 1は以前に取得したlevel 1のすべての更新を含んでいます。そのため、リストアするのはlevel 0と最新のlevel 1のみです。

img-4

累積増分バックアップからのリストア/リカバリに使用するコマンドは差分増分バックアップの場合と同じです。restoreコマンドを発行するとlevel 0バックアップがリストアされます。

RMAN> restore datafile xx;

そして、level 1バックアップがリストアされるのはrecoverコマンドを発行したときです。

RMAN> recover datafile xx;

このとき、リストアされるのは最新のlevel 1累積増分バックアップのみです。その後、REDOログが適用されます。REDOログの適用は最新のlevel 1を取得したところからです。

差分増分バックアップはlevel 1バックアップのファイル・サイズが小さくなりますが、level 0とすべてのlevel 1差分増分を順にリストアしていく必要があります。これに対し、累積増分バックアップではlevel 1累積増分バックアップのファイル・サイズは徐々に大きくなっていきます。しかしリストアはlevel 0と最新のlevel 1累積増分のみで、差分増分バックアップよりもリストア時間の短縮が期待できます。

差分増分バックアップと累積増分バックアップには一長一短があります。これらのすきまを埋めるため、Oracle Database 10gで増分更新バックアップという機能が実装されました。

3.3 増分更新バックアップ

増分バックアップはフルバックアップに比べてファイル・サイズを小さくすることができますが、リストアにかかる時間が長くなります。増分更新バックアップのアイデアは、level 0バックアップにあらかじめlevel 1を適用したものをバックアップ側に用意しておくというものです。すると、リストアは、最新のlevel 1バックアップを取得した時点のデータファイル全体のイメージ1回で済みます。そして、REDOログの適用は最新のlevel 1バックアップを取得した時点のところからです。

img-5

増分更新バックアップは2つの操作から構成されます。1つ目は増分バックアップの取得で、2つ目は増分バックアップの適用です。

増分更新バックアップのためのコマンドにはfor recover of copyというキーワードが付きます。増分更新バックアップのためのlevel 1は差分増分でも累積増分のどちらでも構いません。

RMAN> backup incremental level 1 for recover of copy with tag 'incr_update' database;

このコマンドはlevel 1となっていますが、もしlevel 0が取得されていなければ自動的にlevel 0が取得されます。tagはバックアップを区別する識別子です。

level 1を取得したら、recover copyコマンドでそれをlevel 0に適用します。

RMAN> recover copy of database with tag 'incr_update';

増分更新バックアップからのリストア/リカバリの手順はフルバックアップや通常の増分更新バックアップと同じです。まず、該当するデータファイルをオフラインにし、restoreコマンドでリストアします。

RMAN> restore datafile xx;

このとき、リストアされるのはlevel 1バックアップが適用されたlevel 0のデータファイルであり、リストアはこの1回のみです。リストアが完了したら、recoverコマンドでREDOログを適用します。

RMAN> recover datafile xx;

リカバリが完了したら、該当データファイルをオンラインにするとSQLの実行が可能になります。

フルバックアップ、差分増分バックアップ、累積増分バックアップそして増分更新バックアップを説明してきましたが、どのバックアップ方法を選択してもRMANでのリストア/リカバリの手順は同じになることに気づかれたでしょうか?どのバックアップ方法であったとしても、restore/recoverコマンドは適切なバックアップ・ファイルを自動的に選択します。

4 Zero Data Loss Recovery Applianceの仮想フルバックアップ

データファイル障害に備えて、最新のデータファイルに近い状態にしておく目的では増分更新バックアップは優れた機能です。しかし、増分更新バックアップでlevel 0にlevel 1を適用すると、それをロールバックすることはできません。また、REDOログによる更新の適用も時間を進める方向には可能ですが、時間をさかのぼる方向に変更することはできません。

テストなどで過去の状態のデータベースを複製したいというのはよくあることです。過去の状態のデータベースを複製するには、目的の時刻よりも前の時刻のフルバックアップもしくはlevel 0バックアップが必要です。そのため、過去の状態のデータベースを複製するという要件がある場合は、フルバックアップもしくはlevel 0を複数世代持つことになります。

Oracle Zero Data Loss Recovery Appliance(ZDLRA)はこれを特異な方法で解決します。ZDLRAはストレージに実体としてはlevel 1増分バックアップによるデータファイルの断片を保持するのですが、このデータファイルの断片をつなぎ合わせて、任意のバックアップ時点のデータファイル全体のイメージを構成することができます。これを仮想フルバックアップと呼びます。そのため、level 0を取得するのは最初の1度だけでよく、以降はlevel 1のみです。仮想フルバックアップの仕組みによって、バックアップ・ファイルのサイズを小さく抑えつつも、データファイルの障害に備えて最新のイメージを用意したいという要件と、テストのために過去のイメージを用意したいという要件を両立します。

img-6