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

 

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

第10回 バックアップ/リカバリ(5)RMANでのリストア/リカバリ時間の短縮


著者紹介


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

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


第10回 バックアップ/リカバリ(5)RMANでのリストア/リカバリ時間の短縮


第9回では、RMANでのバックアップの読み取りブロック数を減少させる高速増分バックアップと、バックアップの並列化によるバックアップ時間の短縮について説明しました。今回はRMANでのリストア/リカバリ時間の短縮について説明します。バックアップと同様に、リストア/リカバリも並列化することができます。

1 リストアの並列化

RMANでは、バックアップの並列化と同様に、複数のRMANチャネルを構成することによりリストアも並列化することができます。第9回でも説明しましたが、RMANのCONFIGUREコマンドでPRALLELISMを設定します。以下の例では並列度を4に設定しています。

RMAN> CONFIGURE DEVICE TYPE disk PARALLELISM 4;

新しいRMAN構成パラメータ:
CONFIGURE DEVICE TYPE DISK PARALLELISM 4 BACKUP TYPE TO BACKUPSET;
新しいRMAN構成パラメータが格納できました

複数のRMANチャネルを設定した状態でRESTOREコマンドを発行すると、リストアが並列に実行されます。

2 リカバリの並列化

データファイルのリストアが完了した次に行うことは、REDOログの適用(リカバリ)です。REDOログにはデータベースに対する更新処理(チェンジ・ベクタ)がSystem Change Number(SCN)の順にシーケンシャルに記録されています。しかし、データベースへのチェンジ・ベクタの適用は並列に実行することが可能です。 メディア・リカバリの並列化は、何も設定しなくてもデフォルトで並列化されます。Oracle Database 11g Release 1以降では、RECOVERコマンドのPRALLEL句で並列度を指定しない場合はOracleインスタンスの初期化パラメータCPU_COUNTの値に等しい並列度でリカバリが実行されます。CPU_COUNTのデフォルト値はOSが認識しているCPUスレッド数です。

RMAN> RECOVER DATABASE [PARALLEL n];

メディア・リカバリが開始されると、PRnnというOracleインスタンスのバックグラウンド・プロセスが生成されます。PRnnはメディア・リカバリの間だけ生存するプロセスです。以下はCPU_COUNT=24の環境でリカバリを実行したときに生成されるPRnnプロセスをpsコマンドで見た例です。

$ ps -efH
UID        PID  PPID  C STIME TTY          TIME CMD
...
oracle   25342     1 31 15:43 ?        00:00:04   ora_pr00_sidb18a
oracle   25344     1 14 15:43 ?        00:00:02   ora_pr01_sidb18a
oracle   25346     1 31 15:43 ?        00:00:04   ora_pr02_sidb18a
oracle   25348     1 20 15:43 ?        00:00:03   ora_pr03_sidb18a
oracle   25350     1 19 15:43 ?        00:00:02   ora_pr04_sidb18a
oracle   25352     1 19 15:43 ?        00:00:02   ora_pr05_sidb18a
oracle   25354     1 12 15:43 ?        00:00:01   ora_pr06_sidb18a
oracle   25356     1 27 15:43 ?        00:00:04   ora_pr07_sidb18a
oracle   25358     1  7 15:43 ?        00:00:01   ora_pr08_sidb18a
oracle   25360     1  6 15:43 ?        00:00:01   ora_pr09_sidb18a
oracle   25362     1  7 15:43 ?        00:00:01   ora_pr0a_sidb18a
oracle   25364     1  6 15:43 ?        00:00:00   ora_pr0b_sidb18a
oracle   25366     1  5 15:43 ?        00:00:00   ora_pr0c_sidb18a
oracle   25368     1  4 15:43 ?        00:00:00   ora_pr0d_sidb18a
oracle   25370     1  8 15:43 ?        00:00:01   ora_pr0e_sidb18a
oracle   25372     1  7 15:43 ?        00:00:01   ora_pr0f_sidb18a
oracle   25374     1  6 15:43 ?        00:00:00   ora_pr0g_sidb18a
oracle   25376     1  8 15:43 ?        00:00:01   ora_pr0h_sidb18a
oracle   25378     1 12 15:43 ?        00:00:01   ora_pr0i_sidb18a
oracle   25380     1  7 15:43 ?        00:00:01   ora_pr0j_sidb18a
oracle   25382     1  7 15:43 ?        00:00:01   ora_pr0k_sidb18a
oracle   25384     1  8 15:43 ?        00:00:01   ora_pr0l_sidb18a
oracle   25386     1 15 15:43 ?        00:00:02   ora_pr0m_sidb18a
oracle   25388     1 21 15:43 ?        00:00:03   ora_pr0n_sidb18a
oracle   25390     1 21 15:43 ?        00:00:03   ora_pr0o_sidb18a

REDOログから読み込まれたチェンジ・ベクタには、どのデータブロックに対しどのような変更を行ったかが記録されています。チェンジ・ベクタのデータブロック・アドレスをハッシュした値に基づいて、そのチェンジ・ベクタをどのPRnnプロセスが適用するかが決定されます。つまり、あるデータブロックのリカバリは特定のPRnnプロセスのみが担当します。複数のPRnnプロセスが同じデータブロックを変更するということはありません。
REDOログにはSystem Change Number(SCN)の順にチェンジ・ベクタが記録されており、1つのデータブロックは1つのPRnnプロセスからしか変更されないため、複数のチェンジ・ベクタによる複数のデータブロックのリカバリを複数のPRnnプロセスで並列に実行することが可能になっています。

img-1

リカバリ性能のボトルネックになる要素の一般的な傾向は、REDOログが配置されたストレージのシーケンシャルI/O性能ではなく、CPU性能もしくはデータファイルが配置されたストレージのランダムI/O性能になります。
莫大な量のREDOログをリカバリする事態になったとき、リカバリの進捗を「REDOログをxx本適用した」というようにREDOログの尺度で語ることになるのですが、ストレージのハードウェアの性能はランダムI/OのスループットよりもシーケンシャルI/Oのスループットの方がはるかに高い値を示すものなので、リカバリに時間がかかる原因が「REDOログを読むのが遅い」ということになっているのはまれなことです。
REDOログをどこから適用する必要があるかは、リストアしたデータファイルのバックアップをいつ取得したかによって決まります。リストアしたデータブロックの状態からリカバリしたい時点(障害発生直前の状態)までの更新の差分だけREDOログを適用することになります。そのため、バックアップを取得する間隔を短くしておくと、リカバリに必要なREDOログの量も少なくなります。バックアップはデータベースのストレージに負荷をかけるため、SQLの実行性能への影響を懸念してあまりとらないという設計をする人もいる(!)のですが、もしファイル破損が起きた場合の迅速な復旧という観点からは、毎日バックアップを取得することをお勧めします。第9回で説明した高速増分バックアップを使用すれば、前回のバックアップから更新されたデータブロックにのみアクセスするのでフルバックアップと比較してストレージの負荷を下げることができます。また、Data Guardのフィジカル・スタンバイを構成すると、スタンバイ・データベース側でバックアップを取得し、それをプライマリ・データベースにリストアすることも可能です。

ここまでの説明では、リストアをファイル単位で行うという暗黙の仮定を置いていました。RMANでバックアップを取得する最小単位は1本のデータファイルですが、リストア/リカバリの最小単位はデータファイルではありません。RMANはデータファイルの中の特定のデータブロックをリストア/リカバリすることが可能です。これをブロック・メディア・リカバリと呼びます。次回はブロック・メディア・リカバリの説明を予定しています。