「基本からわかる！高性能×高可用性データベースシステムの作り方」indexページ▶▶
第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プロセスで並列に実行することが可能になっています。
リカバリ性能のボトルネックになる要素の一般的な傾向は、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はデータファイルの中の特定のデータブロックをリストア/リカバリすることが可能です。これをブロック・メディア・リカバリと呼びます。次回はブロック・メディア・リカバリの説明を予定しています。