Recovery Managerのバックアップおよびリカバリの最適化

(1)

Recovery Manager のバックアップ

およびリカバリの最適化

オラクル・ホワイト・ペーパー

(2)

Recovery Manager のバックアップ

およびリカバリの最適化

概要 ... 3

Recovery Managerの概要 ... 4

Recovery Managerによるバックアップ ... 4

バックアップおよびリストア・パフォーマンスに影響を及ぼす要素 ... 4

バックアップ・デバイスの速度 ... 5

並列性... 5

テープのバックアップ ... 5

ディスクのバックアップ ... 6

一般的な情報 ... 6

バックアップ・セットの多重化 ... 6

バッファ・サイズ... 7

バックアップ読取りバッファ ... 7

バックアップ書込みバッファ ... 8

メモリーの割当て元 ... 9

同期I/Oと非同期I/O ... 9

増分バックアップの使用... 10

ブロック・チェックの使用... 12

チェックサム ... 12

論理ブロック・チェック ... 12

圧縮の使用... 13

メディア・リカバリ・パフォーマンスに影響を及ぼす要素 ... 14

アーカイブ・ログおよび/または増分の適用数 ... 14

リカバリが必要なデータファイルの数 ... 15

アーカイブ・ログの場所... 15

パラレル・リカバリ... 16

一般的なデータベース・パフォーマンス ... 17

結論 ... 18

(3)

Recovery Manager のバックアップ

およびリカバリの最適化

概要

バックアップのパフォーマンスは、一般に割り当てられた時間枠をバックアップ が超えた場合、詳細に検証されます。Oracle Database 10g の新規の DURATION パ ラメータにより、バックアップにかかる時間を Recovery Manager に知らせることができ、時間切れになるとバックアップが停止します。次のバックアップ実行時 Recovery Manager は前回停止した場所から作業を開始します。この機能はバックアップ時間枠全体を複数の小さな枠に分けますがバックアップ・パフォーマンス全体の最適化には問題が残ります。リストアおよびリカバリのパフォーマンスの問題が明らかになったときには、すでに遅すぎることがあります。リカバリ作業に 6 時間要してまだ終了しないが、今すぐにデータベースを使用することが必要な場合などです。ここでは、バックアップ、リストアおよびリカバリ操作のパフォーマンスに影響を及ぼす要素を説明し、事前にパフォーマンスを監視および改善するガイドを提供します。

このホワイト・ペーパーでは、読者が Recovery Manager（RMAN）を使用して Oracle データベースのバックアップ管理を行っていることを想定しており、ユーザーの管理によるバックアップ（RMAN 以外）のパフォーマンスについては説明していません。ここで実施したテストはすべて、SUSE Linux Enterprise Server が稼働する 2Way の Intel プロセッサ上で Oracle Database 10g R10.1.0.3 を使用しています。これは、ハイエンドでも大型サーバーでもないため、テストは単純に最適化のみの検証に実施されました。

ここでは、テストのアクティビティにかかった CPU タイムも示します。この値は、 CPU used by this session（統計#12）の v$sesstat から取得されます。このセッションは、Recovery Manager によってチャネルが割り当てられるときに作成するセッションです。このセッションは、読取り、物理ブロック・チェックおよび論理ブロック・チェック、圧縮、バックアップ・セットへの書込みに使用される CPU タイムを示します。注意: ここで示すテスト結果は公式な Oracle パフォーマンス値ではなく、単に、バックアップ、リストアおよびリカバリ操作のパフォーマンス特性を表しています。結果は、ハードウェア、オペレーティング・システム、ネットワーク、データベース構成などによって大きく異なります。

(4)

Recovery Manager の概要

Recovery Manager は、DBA による Oracle データベースのバックアップおよびリカバリ管理を容易にするツールとして、Oracle8 から導入されました。それ以来 Oracle の各リリースで改善されてきました。Recovery Manager は RDBMS カーネルに構築されるため、破損妥当性チェックなど様々なデータベース機能が活用できます。

Recovery Managerアーキテクチャおよび機能の詳細は、『Oracle Databaseバックアップおよびリカバリ基礎ガイド』を参照してください。このホワイト・ペーパーでは、読者が基本的なRecovery Managerの構成要素および用語を理解しているものと想定し、関連機能のみを必要に応じて説明しています。注意: ここでは、このホワイト・ペーパーにおいて用語の「バックアップ・パフォーマンス・ビュー」は、同期 I/O が使用されている場合は V$BACKUP_SYNC_IO に、非同期I/O が使用されている場合は V$BACKUP_ASYNC_IO ビューに相当します。

Recovery Manager によるバックアップ

DBA は、Recovery Manager を使用してデータファイル、制御ファイル、SPFILE およびアーカイブ・ログファイルをバックアップできます。作成されたバックアップは、次のいずれかの形式で格納されます。 • イメージ・コピー − バックアップするファイルを正確にビットごとにコピーするもので、ディスクにのみ格納されテープには直接書き込まれません。イメージ・コピー作成のパフォーマンスのチューニングは単にディスクからディスクへのコピーなため、ここではイメージ・コピーの詳細は説明していません。 • バックアップ・セット − データファイル、アーカイブ・ログ、制御ファイルまたは SPFILE の論理グループです（データファイルおよびアーカイブ・ログは同じバックアップ・セットに結合できません）。バックアップ・セットは、Recovery Manager からテープ・ライブラリにインタフェースを提供するソフトウェア・レイヤーであるメディア管理層（MML）を使用して、ディスクまたはテープ上に作成できます。このホワイト・ペーパーでは、このようなバックアップ・タイプを説明します。バックアップ・セットには、データが多重化されている複数のファイルを含むことができます。バックアップ・セットを作成する際、Recovery Manager は、フォーマットされていないブロックのバックアップを作成しません。

バックアップおよびリストア・パフォーマンスに影響を及ぼす

要素

バックアップおよびリストア・パフォーマンスに影響を及ぼす要素は多数あります。 • バックアップ・デバイスの速度 • 並列性 • バックアップ・セットの多重化

(5)

• バッファ・サイズ • 同期 I/O 対非同期 I/O • 増分バックアップの使用 • ブロック・チェックの使用 • 圧縮の使用アーカイブ・ログおよび増分バックアップによるデータベースに対するリカバリ・プロセスについては、後の項で説明します。

バックアップ・デバイスの速度

バックアップの最高速度は、次のように算出できます。最大 Mb/Sec = min（ディスク読取り Mb/s、テープ書込み Mb/s）これ以上高速のバックアップは不可能です。すでに説明したとおり、バックアップの最初にデータファイルとアーカイブ・ログファイルの読取りおよびブロックの読取りバッファへの配置が実行されます。バッファを満たす最高速度は、物理的な場所とキャッシングおよびディスクの最高読取り速度によって異なります。Recovery Manager を介したディスクからのスループットは、type=’INPUT’に指定されたバックアップ・パフォーマンス・ビューの effective_bytes_per_second 列で監視できます。これが、ディスクの予 想読取り速度より遅い場合は、sar などの OS データ、特定のディスクおよび論理 ボリューム・マネージャ実装のディスク監視データにより要因を調べる必要があります。バックアップの書込みに使用されるデバイスの速度も、type=’OUTPUT’に指定された effective_bytes_per_second 列のバックアップ・パフォーマンス・ビューで監視できます。I/O 速度がテープ・デバイスの期待値より遅い場合は、 MML およびドライブ・オプションを調べて、物理的なテープ・ブロック・サイズ（通常大きいほどよい）、つまりテープ圧縮（バックアップが遅くなる）を調整し、データをそのドライブに確実にストリーミングする必要があります。各チャネルに多重化されたファイル数が増加するとテープのストリーミング能力が向上することがありますが、1 つのバックアップ・セットに含まれるデータファイルのサブセットのリストア・パフォーマンスは下がります。

並列性

チャネルとは、Recovery Manager から物理バックアップ・デバイス（ディスクまたはテープ）への通信経路です。この項では、テープおよびディスクのバックアップ用チャネルを割り当てるベスト・プラクティスを説明します。

テープのバックアップ

バックアップに使用できる物理テープ・デバイス 1 つに対してチャネル 1 つの割当てをお薦めします。チャネルごとに、独自のバックアップ・セットが作成されます。MML によって異なりますが、2 つのテープ・デバイスにチャネルを 3 つ割り当てると、デバイス

(6)

が他のチャネルでバックアップ・セットを作成してから 3 つ目のチャネルがバックアップ・セットの作成を開始するか、または 2 つのバックアップ・セットがテープに組み合されます。このようなバックアップの組合せでは、バックアップ時間は短縮されますが、リストア時間は極端に長くなります。

ディスクのバックアップ

出力がストライプ化される物理デバイス 1 つに対してチャネル 1 つの割当てをお薦めします。

一般的な情報

自動チャネル並列性を使用する場合、Recovery Manager は均一サイズのバックアップ・セットを作成するためにチャネル間へのデータファイル配布を試行し、次の処理を実行します。 • チャネル間でバックアップするファイル数の分割 • チャネル間でファイルを含む読取り中のディスクの均一化 • 各バックアップ・セットのサイズの統一自動チャネル並列性は、『Oracle Databaseバックアップおよびリカバリ・アドバンスト・ユーザーズ・ガイド』の「第 2 章」に記述されています。

バックアップ・セットの多重化

filesperset バックアップ・オプションの調整により、バックアップが高速になりますが、すべてのデータファイルをリストアしない場合のリストア時間にも大きく影響します。これは、セット当たり異なる数のファイルのレベル 0 のバックアップを複数作成したテストで示されています。データファイルが 1 つ削除され、リストアのために各バックアップ・セットを使用する際、時間情報が収集されます。結果を次の表 1 に示します。 BS 内の ファイル数 BS サイズ （ブロック） リストアされたファイル･サイズ （ブロック） 時間 （秒） CPU （秒） 8 702320 97727 132 39.42 4 658221 97727 110 36.92 2 132773 97727 82 29.92 1 97730 97727 74 25.62 表 1: リストア速度に対する filesperset の影響結果から、filesperset の数を小さな値に維持すると、ファイルのリストア時間が短縮されることが明らかです。データベース全体をリストアする場合は、バックアップ・セットが増えるとリストア時間が長くなります。これは、より多くのリクエストが MML に送信されるためです。これは、重大なパフォーマンス低下ではありませんが、バックアップの filesperset が永続的に低下しないよう監視が必要になります。

(7)

もう 1 つの考慮点は、失敗したバックアップの再開にかかる時間です。Recovery Manager は、バックアップ・セット・レベルでバックアップを再開します。このため、中断されていた大きなバックアップ・セットの作成には、小さなバックアップ・セット（多重化値が小さいバックアップ・セット）より時間がかかります。

バッファ・サイズ

バックアップを作成する際、Recovery Manager は各ブロックを入力バッファに読み取る必要があります。ブロックのバックアップの必要性の確認後、破損検出に様々なブロック妥当性チェックが実行されます。次に、ブロックは出力バッファにコピーされます。書込みバッファは、多重化データ・ブロックまたはアーカイブ・ログ・ブロックの格納に使用され、次にバックアップ・メディア（ディスクまたはテープ）に書き込まれます。これを次の図 1 に示します。図 1: バックアップ中のメモリー・バッファの使用

バックアップ読取りバッファ

バックアップ中に使用されるディスク読取りバッファのサイズおよび数については『Oracle Databaseバックアップおよびリカバリ・アドバンスト・ユーザーズ・ガイド』を参照してください。割り当てられたチャネル 当たりのファイル数 バッファ・サイズ ファイル数 < 4 各バッファ=1Mb、チャネル当たりの総バッファ・サイズは最大 16Mb 4 ≥ ファイル数 ≤ 8 各バッファ=512k、チャネル当たりの総バッファ・サイズは最大 16Mb。ファイル当たりのバッファ数は、ファイル数によって異なります。ファイル数 > 8 各バッファ=128k、ファイル当たり 4 バッファ。したがって、各ファイルのバッファは 512Kb。表 2: 読取りバッファ割当てアルゴリズムバックアップ中に割り当てられる読取りバッファの数およびサイズを調整するパラメータは、チャネル・パラメータ MAXOPENFILES です。このパラメータは、 Recovery Manager が、バックアップに入力するために同時に開くデータファイルの最大数を指定します。デフォルト値は最小（8、バックアップ・セット内のファイル数）です。

(8)

バックアップ時にアルゴリズムが実際のバッファ割当てと一致するため、 MAXOPENFILES に異なる数値を使用してデータベースをバックアップする際のデータファイルおよびバックアップ・セットに分割されるバッファを次の表に示します。 MAXOPENFILES ブロック・ サイズ （バイト）バッファ・ サイズ （Kb） ファイル 当たりの バッファ数 1 度に開く ファイル数 バッファ・サイズ合計 （MB） 1 8192 1024 16 1 16 2 8192 1024 8 2 16 3 8192 1024 5 3 15 4 8192 512 8 4 16 5 8192 512 6 5 15 6 8192 512 5 6 15 7 8192 512 4 7 14 8 8192 512 4 8 16 9 8192 128 4 9 4.5 10 8192 128 4 10 5 表 3: データファイル・バックアップ用ディスク読取りバッファ割当て各ファイル（データファイルおよびアーカイブ・ログ）に割り当てられたバッファの数およびサイズは、次の問合せで確認できます。

SELECT set_count, device_type, type, filename, buffer_size, buffer_count, open_time, close_time

FROM v$backup_async_io

ORDER BY set_count,type, open_time, close_time;

読取りバッファの割当てに Oracle が使用するアルゴリズムは適切ですが、 v$backup_async_io を監視してメモリー不足の問題が発生しないよう、バックアップ読取りバッファに割り当てられているメモリー量を表示します。表 3 に示すテストでは、バックアップ作成に要した時間に変化はありません。

バックアップ書込みバッファ

バックアップ書込みバッファは、テープ・デバイスおよびディスク・デバイスによってサイズが異なります。デバイス・タイプチャネル当たりの バッファ数 バッファ・サイズ 割り当てられた バッファ合計 DISK 4 1Mb 4Mb SBT 4 256Kb 1Mb 表 4: デフォルトの書込みバッファ割当てパフォーマンスを高めるには、大きな書込みバッファを使用する方法もあります。これを示すために、異なる書込みバッファ・サイズで 1 つのデータベースのバックアップを 3 つ作成しました。1 つ目のバックアップには、標準バッファ設定（1Mb バッファ）を使用しました。後の 2 つのバックアップには、小さいバッファ・サ

(9)

イズおよび大きいバッファ・サイズを適用しました。サイズの変更には、次のコマンドを使用します。

Smaller buffer ( 32k * 4 = 128Kb buffer):

configure channel device type sbt parms=’BLKSIZE=32768'; Larger buffer ( 512k * 4 = 2Mb buffer):

configure channel device type sbt parms='BLKSIZE=524288’; 次の表には、バックアップ・パフォーマンス・ビューからのバックアップの結果を示します。バッファ・サイズ合計（バイト） I/O 数 I/O 時間（100 秒単位） 131,072 60564 6174 1,048,576（デフォルト） 7571 5959 2,097,152 3786 5053 表 5: 異なる書込みバッファ・サイズの I/O 速度

メモリーの割当て元

読取りバッファおよび書込みバッファのメモリーは、I/O スレーブが使用されていないかぎり、PGA から割り当てられます。各チャネルには、固有の I/O バッファ・セットがあります。I/O スレーブが使用中の場合は、バッファ・メモリーが共有プールから割り当てられ、プライマリ・プロセスおよび I/O スレーブ・プロセス間でデータ送信を可能にします。ラージ・プール領域が LARGE_POOL_SIZE パラメータで割り当てられている場合は、共有プールのかわりにこれが使用されます。ラージ・プールを使用して共有プールの競合を減らすことをお薦めします。

同期 I/O と非同期 I/O

テープ・デバイスの使用目的は、テープ・ストリーミングを維持することです。テープ I/O はすべて同期化されているため、チャネル・プロセスはテープへの書込みが完了してから、読取りバッファを再開・充填します。読取りバッファの充填している時、テープ・デバイスは次の書込みバッファ・データを待ちます。これは連続的なテープのストリーミングを妨げるため、最適なバックアップ方法ではありません。したがって、非同期 I/O をエミュレートする BACKUP_TAPE_IO_SLAVES 初期化パラメータでのテープ I/O スレーブの有効化をお薦めします。チャネル・プロセスは、スレーブ・プロセスへの書込みを割り当てて書込みの完了を待たずにバッファの充填を再開します。

(10)

テープ・ストリーミングとは 大量のデータが高速でテープに入力されている場合、テープ・ドライブは現在進行中の書込みの終了と同時に次のテープの位置にさらに書込みが可能です。ドライブ・モーターは、最高速で連続回転して書き込むため、テープは書込みを行うヘッドの前を「流れ」ます。テープ・ストリーミングの維持に十分なデータがない場合、通常テープ・ドライブは、データの受信が中断した時点で停止し、書き込まれた最後のブロックの場所まで巻き戻した後、新規データの到着を待ちます。テープを絶えず前後に動かすとテープの寿命が短くなり、バックアップ時間も遅くなります。

増分バックアップの使用

バックアップ実行時間を短縮する最善の方法の 1 つは、単純にバックアップするデータ量を減らすことです。いくつかのガイドラインを示します。 • 価格参照や定義データなど、全く変更されないデータベースまたはほとんど変更されないデータベースに含まれる静的データは、そのデータをデータ自身の表領域に入れます。この表領域は読取り専用にしてからバックアップします。データの変更時には、表領域を読取り/書込みモードにして変更後、読取り専用モードに戻して別のバックアップを作成します。注意: 表領域のバックアップをほとんど作成しない場合は、バックアップの作成日付を必ず確認し、テープ・ライブラリから消去されないようにしてください。一度消去すると、リカバリに必要なデータが失われます。バックアップ作成の日付に制限がある場合は、必ず期限切れ前に読取り専用データのバックアップを新しく作成してください。Recovery Manager は、バックアップ最適化機能で自動的にこれを実行します。 • バックアップ戦略に差分増分バックアップが含まれている場合は、データベースに問い合せて、通常バックアップ間において変更されるブロック数の検索ができます。変更頻度が低いため頻繁にバックアップを必要としないデータファイルを次の問合せで識別できます。

SELECT set_count, set_stamp, file#, data file_blocks, blocks “BACKUP_BLOCKS”

FROM v$backup_data file ORDER BY set_count, file#;

• 大量のデータを含む大きなデータファイルと比較し、データが少ない大きなデータファイルの完全なバックアップも時間がかかります。これは、各データ・ブロックをメモリー・バッファに読み取り、使用頻度を確認し評価するためです。これを示すため、異なる空き領域数を持つ 500Mb ファイルの完全バックアップを作成した場合の結果を比較します。

(11)

空き領域（%） スキャンされた ブロック数 バックアップ されたブロック数 所要時間 （秒） 100% 64000 8 22 50% 64000 31678 31 <0.79% 64000 63496 49 表 6: バックアップ時間およびデータファイルの空き領域小さなテスト・システムでのディスクへのバックアップ時間は最長でもわずか 49 秒でしたが、ファイルが空でも、8 ブロックのみのバックアップに、その 45%の時間を要しました。これを使用される頻度が高く、より多くの大きなデータファイルを扱うシステムで考えてみてください。大量の空き領域を含む大きなデータファイル（2GB 以上）の場合は、サイズを変更し（ファイルの最後にオブジェクト・エクステントがない場合）、次に、自動拡張を設定してバックアップで空の領域のスキャンにかかる時間の浪費を防止できます。 • Oracle Database 10g で導入されたブロック・チェンジ・トラッキングの使用を検討してください。最適化された増分機能を使用してバックアップを作成できます。バックアップ中にデータファイル全体をスキャンするかわりに、ブロック・チェンジ・トラッキングを有効にすると、変更トラッキング・ファイルは、ビットマップ・パターンを使用して、変更されたデータ・ブロックの場所を追跡しデータ・ブロックの範囲を示します。変更されたブロックの追跡にも、パフォーマンス・オーバーヘッドはほとんど発生しません。ブロック・チェンジ・トラッキングを有効にした状態で最適化された増分機能を使用すると、バックアップ速度が大きく改善します。これをテストするために、まずレベル 0 の増分で、データベース全体のバックアップを作成しました。DML アクティビティがデータベースに生成され、次にレベル 1 の増分が行われました。ブロック・チェンジ・トラッキングを 1 度失効化し、その後再度有効化することを繰り返しました。結果を次の表に示します。 最適化された 増分データベースの ブロック数 読取り ブロック数 バックアップ のブロック数 所要時間 （秒） 無 404160 404160 36567 156 有 404160 72832 37215 35 表 7: 最適化された増分バックアップを使用した高速化最適化された増分バックアップを使用した場合に読取り中のブロック数が減少するため、高速になることは明らかです。バックアップに最適化増分機能を使用しているかどうか確認するには、 v$backup_data ファイルの USED_CHANGE_TRACKING 列を確認してください。リストア速度は、最適化された増分バックアップによって影響されません。バックアップの速度以外は、結果のバックアップ・セットは、通常

(12)

の増分バックアップによってバックアップが作成された場合と変わらないためです。

ブロック・チェックの使用

Recovery Manager は、複数の異なるブロック適性チェックを実行して、バックアップおよびリストア時の破損を検出する機能を提供します。

チェックサム

デフォルトでの Recovery Manager は、db_block_checksum パラメータの設定とは関係なく、バックアップの一部として書き込まれたブロックのチェックサムを計算します。ブロックにすでにチェックサム値が含まれている場合、Recovery Manager はその値が正しいことを検証します。チェックサム作成機能は、バックアップ・コマンドの一部として NOCHECKSUM 句を指定することで無効になります。ただし、これは推奨しません。チェックサムは、常に SYSTEM データファイルおよび制御ファイルに対して作成されています。

論理ブロック・チェック

Recovery Manager は、バックアップされている各データ・ブロック内に含まれる論理構造を確認する機能もあります。このチェックは、db_block_checking 初期化パラメータ使用時に使用される論理ブロック・チェックと同じです。バックアップ中に論理チェックを有効にするには、BACKUP コマンドで CHECK LOGICAL オプションを使用してください。デフォルトでは、論理チェックが使用されません。各チェックのバックアップ・パフォーマンスへの影響を示すために、各オプションを有効にした状態で、データベースの完全バックアップを実行しました。結果は次のとおりです。チェックサムの有無論理チェックの有無 読取り ブロック数 時間 （秒） CPU （秒） 無無 825920 623.67 227.08 有無 825920 622.33 229.93 有有 825920 624.67 245.81 表 8: バックアップに対するチェックサムおよび論理ブロック・チェックの影響表 8 は、チェックサム検証がバックアップ・パフォーマンスにほとんど影響がないことを示します。DB_BLOCK_CHECKSUMS の init.ora 値が TRUE に設定されているため、各データ・ブロックにはすでにチェックサムが含まれます。このため、 Recovery Manager は各ブロックを読み取って、ブロックのチェックサムが正しいかどうかを検証します。この Recovery Manager のバックアップでのブロック破損検出機能を使用できるよう、チェックサムは無効にしないことをお薦めします。

CHECK LOGICAL パラメータをRecovery Manager バックアップに追加すると、少なからずバックアップ・パフォーマンスに影響を与えます。これは自分の環境でテストを行って、ベンチマークに基づいたパフォーマンスへの影響を確認する必要があります。

(13)

チェックサムおよび論理ブロック・チェックの影響は、Recovery Manager リストアの場合と同じです。チェックサムの有無論理チェックの有無データベースの ブロック数 時間 （秒） CPU （秒） 無無 825920 559 210.53 有無 825920 559 211.14 有有 825920 610 218.53 表 9: リストアに対するチェックサムおよび論理ブロック・チェックの影響

圧縮の使用

Oracle Database 10g 以前は、RMAN が使用できる圧縮タイプは、未使用ブロック圧縮（未使用ブロックはバックアップされない）のみでした。Oracle Database 10g ではバイナリ圧縮機能が導入され、バックアップ・セットのサイズを 50%以上圧縮できます。圧縮関連の処理量が増加すると、バックアップおよびリストアの時間も増加します。CPU の使用率も増加します。 MMLでもテープ圧縮機能が提供される場合は、テストを行って、Recovery Manager の圧縮機能を使用した場合よりも圧縮率とバックアップ時間が高いかどうか確認してください。バックアップおよびリストア中はパフォーマンスが低下するため、絶対にRecovery ManagerおよびMMLで圧縮機能を使用しないでください。 Recovery ManagerおよびMML両方で使用される時間とCPUに対してテストを行って、どちらが最適か確認してください。バックアップ・セットが占める領域が問題にならない場合は、圧縮を使用しないでください。圧縮されたバックアップ・セットのリストアは、CPU の使用率および全体の時間について同様にパフォーマンスに影響を与えます。圧縮バックアップ・セットのブ読取り ブロック数 バックアップ・セット・サイズ （Mb） 時間 （秒） CPU （秒） 無 778109 6079 559 209.37 有 778109 517 1133 1093.37 表 10: リストア速度に対する Recovery Manager の圧縮影響バックアップ圧縮テストと同様、CPU に多くの時間がかかるうえ、バックアップのリストアに 2 倍の時間を要します。 Recovery Manager 圧縮は、テープ・デバイスがネットワーク全体にマウントされている場合に使用すると効果的です。この場合、Recovery Manager は、バックアップ・ピースをデータベース・サーバーからテープ・サーバーに送信する必要があります。圧縮により、ネットワークを移動するデータ量が著しく減少し、バックアップおよびリストア時間の短縮だけでなく他のネットワーク・ユーザーへの負担も軽減されます。

(14)

メディア・リカバリ・パフォーマンスに影響を及ぼす要素

リカバリ・パフォーマンスに影響を及ぼす要素は多数あります。 • アーカイブ・ログ数および増分の適用回数 • リカバリが必要なデータファイルの数 • アーカイブ・ログの場所 • パラレル・リカバリ • 一般的なデータベース・パフォーマンスこの項では、このリカバリ段階でベース・レベルのバックアップ（レベル 0 または完全バックアップ）を使用してデータファイルが Recovery Manager からリストアされていると想定して説明します。

アーカイブ・ログおよび/または増分の適用数

Recovery Manager によってベース・レベルのバックアップがリストアされた後、リカバリ・フェーズが開始されます。Recovery Manager は、まずデータベースのロールフォワードに使用できる適切な増分バックアップを探します。適切な増分バックアップが見つからない場合は、要求されたアーカイブ・ログが検索されます（ARCHIVELOG モードで実行していると想定しています）。増分バックアップを使用したデータベースのリカバリはアーカイブ REDO ログ・ファイルよりも高速であることは説明しました。これは、ARCHIVELOG モードでデータベースのベース・レベル 0 のバックアップを作成することで簡単にテストできます。長時間にわたってデータベースに DML を実行し、10 個から 20 個のアーカイブ・ログを作成後、増分バックアップを作成します。データベースを削除し、ベース・レベル 0 のバックアップをリストアします。次に、Recovery Manager を使用してデータベースをリカバリします。増分バックアップがリストアされ時間が計測されます。再度ベース・レベル 0 をリストアしますが、データベースのリカバリには、Recovery Manager ではなく、‘RECOVER AUTOMATIC DATABASE’コマンドで SQL*Plus を使用し、増分リストアにかかる時間を比較します。このテストによって、アーカイブ・ログを適用した場合のリカバリに要した時間が 789 秒であるのに対し、増分リストアでは 46 秒であったことがわかります。テスト・システムでは、バックアップはディスクに作成されたため、増分バックアップのリストア速度は予想どおり高速でした。増分バックアップがテープ・デバイスまたはテープのロケーティングを必要とするテープ・サイロから発生している場合は、テープをマウントしてバックアップの先頭を見つけます。これには長時間かかる可能性があります。各システムでのバックアップ・メディアからのアーカイブ・ログおよびリストアが、どの速度で大きく異なるかがここでの要点です。今後、この相違点をテストする価値があります。このことで障害発生時、時間期待値に合ったバックアップ戦略の実行だけですみます。初期のテストで説明したとおり、増分バックアップのタイプ（累積または差分）も、アーカイブ・ログの適用が増分バックアップのリストアよりも低速かどうかの判断に役立ちます。

(15)

リカバリが必要なデータファイルの数

メディア・リカバリの実行時は、REDO レコードの影響を受ける各データ・ブロックをバッファ・キャッシュに読み取ることが必要です。その後でデータ・ブロックに REDO を適用できます。必要以上のデータファイルをリカバリすると、不要なリカバリ処理が必要になります。障害の処理に必要な最低限のデータファイルのみをリストアおよびリカバリしてください。10 件のみのデータファイルのリカバリが必要な場合に、100 件リストアすることは意味がありません。 データファイル内のブロック破損によって障害が発生した場合は、Oracle9i で導入 されたブロック・メディア・リカバリの使用を検討してください。データファイル全体をリストアおよびリカバリするかわりに、個々のデータ・ブロックをバックアップからリストアすることが可能で、アーカイブ・ログまたは増分バックアップ、あるいはその両方を使用してリカバリできます。ブロック・メディア・リカバリで短縮可能な時間を示すため 102,400 8Kb ブロックのデータファイルで異なる数のデータ・ブロックを破損してテストを行い、ブロック・メディア・リカバリとデータファイル・リカバリのリカバリ時間合計（リストアを含む）を明らかにしました。ブロック破損は、データファイル全体に均一に広げました。ブロックの破損前に、データファイルのレベル 0 のバックアップを作成し、データベースに対して TPCC テストを実行（データファイルの 34,113 データ・ブロックを変更）しました。また、アーカイブ・ログはリカバリ中にリストアが必要ないようディスクに残しました。 破損ブロックの数 データファイル・ リカバリ時間（秒） ブロック・メディア・ リカバリ時間（秒） 10 941 145 99 925 155 991 937 219 5000 922 616 10000 938 1156 表 11: ブロック・メディア・リカバリ速度とデータファイル・リカバリ速度の比較表 11 のように、ブロック・メディア・リカバリではデータファイル全体のリストアおよびリカバリと比べ、個々のブロックのリカバリ時間が著しく短縮されています。ある点から、データファイル全体のリカバリよりブロック・メディア・リカバリの方が長くなります。テストでは、データファイルの約 10%に相当する 10,000 ブロック前後に見られました。ブロック・メディア・リカバリの効果が減少し始める点は、システムにより異なります。しかし、このテストでは、ブロック・メディア・リカバリを使用するデータファイルのブロック数が多すぎると、データファイル全体のリストアおよびリカバリよりも速度が落ちることがわかりました。

アーカイブ・ログの場所

リカバリするアーカイブ・ログがすでにディスクに存在する場合、アーカイブ・ログをバックアップからリストアするよりもリカバリは短時間で完了します。バックアップ圧縮（Recovery Manager または MML）が使用されている場合は、リ

(16)

カバリ時間は一層長くなります。20 のアーカイブ・ログを適用またはリストアして、これらのログをテスト・システムに適用する単純なテストでは、リストア時間がさらに 2 分程要しました。このテストではディスク・バックアップを使用しました。バックアップがテープ上にあり 100 以上のアーカイブ・ログの適用が必要な場合、この所要時間は、さらに大幅に増加します。リカバリ時間を短縮するため、多くのアーカイブ・ログを必要に応じてディスクに保存しておくことをお薦めします。ディスクに保存するログ・ファイルの数は、バックアップ頻度および保存に使用できるディスク領域によって異なります。

パラレル・リカバリ

PARALLEL_AUTOMATIC_TUNING init.ora パラメータを使用しない場合、Oracle は、デフォルトではリカバリ・コマンドを発行するシングル・プロセスを使用してメディア・リカバリを実行します。このシングル・プロセスはアーカイブ・ログを読み取り、リカバリされる固有のデータファイルに必要な変更を決定します。データ・ブロックはバッファ・キャッシュに読み取られて REDO が適用されます。アーカイブ・ログの完全な適用ごとに、メディア・リカバリ・チェックポイントが発生し、バッファ・キャッシュ内の使用済ブロックをすべてデータファイルに書き込む指示を DBWR にします。ファイル・ヘッダーおよび制御ファイルも、チェックポイント情報で更新されます。特に大量の REDO を多量のデータファイルのリカバリに適用する場合など、単一のプロセスとしては処理量が多くなります。メディア・リカバリにかかる時間を短縮するため、Oracle はパラレル・リカバリ機能を提供しています。複数の CPU マシンで、RECOVER コマンドで使用する並列度を指定できます。リカバリ・コマンドを発行するプロセスは従来どおりアーカイブ・ログを読み取りますが、キャッシュ内のブロックを読み取る直接の REDO の適用ではなく、読取り処理をパラレル実行スレーブ・プロセスに引き渡します。確実に SCN 順に REDO がデータファイルに適用されるため、パラレル・スレーブは異なる範囲のデータ・ブロックで動作します。これにより相互干渉が回避され、 REDO はデータ・ブロックごとに SCN 順に適用されます。パラレル・リカバリを使用して少数のデータファイルをリカバリする場合は、処理のパーティション化に追加の計算が必要なうえ、スレーブおよびコーディネータ・プロセス間の追加の IPC 通信も必要となるため時間がかかります。最上位の待機イベントについては、v$session_wait と v$system_event を監視してください。複数の異なるタイプの PX Deq イベントがあった場合は、並列度が下がるとリカバリ時間が増える場合があります。パラレル・リカバリを使用すると、コーディネータ・プロセスがアーカイブ・ログ内の各 REDO 変更に対してパーティション化処理を計算するだけでなく、他にもリカバリを実行するプロセスがあるため CPU の使用率も増加します。CPU が飽和状態でないかぎり（sar –u に相当するものがないか検索してください）、パラレル・リカバリでの CPU 問題は起こりません。パラレル・リカバリの最後の考慮点は、メモリーの使用です。init.oraパラメータのPARALLEL_AUTOMATIC_TUNINGがFALSE（デフォルト値）に設定されている場合、パラレル処理間のメッセージに使用されるバッファは 2,148 バイトで、共有プールから割り当てられます。PARALLEL_AUTOMATIC_TUNINGがTRUEに設定

(17)

されている場合は、デフォルトのバッファは 4096 バイトで、ラージ・プールから割り当てられます。PARALLEL_EXECUTION_MESSAGE_SIZE init.oraパラメータでバッファ・サイズを調整することで、パラレル・リカバリの速度を短縮できますが、共有またはラージ・プールのメモリーの使用率を監視したリソース不足の防止も必要になります。メディア・リカバリの詳細は、リカバリのベスト・プラクティスに関する『MAAホワイト・ペーパー』を参照してください。

一般的なデータベース・パフォーマンス

日常のアクティビティでデータベースの速度が遅い場合、高速なリカバリは期待できません。リカバリでは、基礎となるデータベース・サーバー・プロセスを使用してタスクを実行するため、一般的なパフォーマンスの問題が存在すると、リカバリにも同様の問題が発生します。次の点を最適化することにより、リカバリ時間を改善できます。 • I/O − リカバリは、全アーカイブ・ログ・コンテンツの読取り、データファイルからのデータ・ブロックの読取り、次に一旦 REDO が適用されたディスクへの使用済ブロック・バックアップの書込みが必要なことから、読取りおよび書込み集約性が非常に高い処理となっています。OS 固有のツールで v$filestat を監視して、ハードウェアに適切な読取りおよび書込み時間の実現が必要です。低速 I/O では、メディア・リカバリの実行にかかる時間が著しく低下します。 • DBWR パフォーマンス − DBWR の主な役目は、データファイルからのデータの読取りに使用されるバッファ・キャッシュ内にクリーンなバッファが十分あることです。ブロックが更新されると、DBWR はバッファをディスクに書き込み、再利用時にはこれをバッファ・キャッシュに戻します。DBWR がバッファのクリーニングに対処できない場合は、空きバッファ待ち（free buffer waits）イベントを待ちます。I/O に問題がない場合はマルチ DBWR プロセス（OS が非同期 I/O をサポートしていない、または非同期 I/O が無効の場合は DBWR スレーブ）により待機数が減少します。 • CPU の使用 − リカバリが必要な各データ・ブロックは、REDO 変更の適用前にバッファ・キャッシュに読み取られるため、最初に取得が必要なラッチが多数あります。これには、キャッシュ・バッファ・チェーンとキャッシュ・バッファlruチェーンが含まれます。ラッチの取得およびブロックへの変更はすべて CPU サイクルが必要なため、メディア・リカバリ中はデータベースに対して十分な CPU 帯域幅を確保する必要があります。大量の予備 CPU を持ち通常はトランザクションを低速処理しているサーバーでは、より集中的にデータ・ブロックの変更を適用するために、メディア・リカバリ時に CPU の使用が急増する場合があります。前述のとおり、パラレル・リカバリを使用している場合、CPU の使用率もさらに高くなります。

(18)

結論

このホワイト・ペーパーでは、バックアップ、リストアおよびリカバリ速度の最適化を図るために検討すべき要件を多数示しました。バックアップおよびリストア処理の速度は次の点を考慮することで制御できます。 • 増分バックアップを使用する。リストア速度がバックアップ速度よりも重要な場合は、累積増分バックアップを使用する。 • 使用可能な各テープ・デバイスにチャネル 1 つを割り当てる。 • テープにバックアップを作成する場合は、メモリー・バッファのサイズを増やす。 • バックアップが必要なデータ量を減らす − 空または静的データファイルのスキャンは時間およびリソースを著しく浪費する。 • ブロック・チェンジ・トラッキング機能を使用して大幅に増分バックアップ・パフォーマンスを高める。 • ブロック・チェック機能のタイプをバックアップおよびリストアに対して有効化する。 • Recovery Manager またはメディア・マネージャ・レイヤーで使用されている圧縮タイプ。メディア・リカバリ速度は次を考慮することで制御できます。 • 適用が必要なアーカイブ・ログ数が多いほど、リカバリ速度は遅くなる。 • リストアおよび適用が必要な増分バックアップの数。 • 使用される増分バックアップのタイプ（差分または累積）。 • リカバリが必要なデータファイルの数。リストアおよびリカバリするデータファイルが多いと、バッファ・キャッシュへの読取りおよびデータファイルへの書込みが必要なデータ・ブロックが増えることを意味する。 • 破損問題が発生した場合は、データファイル全体をリストアおよびリカバリするかわりにブロック・メディア・リカバリを使用する。 • パラレル・リカバリを使用する。これにより、パラレル実行スレーブ・プロセス間で REDO 適用処理をパーティション化して REDO 適用時間を短縮できる。 • 一般的なデータベース・パフォーマンスのチューニング。データベースの速度が遅い場合、リカバリ、データベースを最適化してからリカバリの最適化を始めること。ここで実施したテストにより最適化の要点を示しました。提案された調整を行っても、システムによってパフォーマンス効果が異なることをご了承ください。バックアップ、リストアおよびリカバリ速度は、システムで使用されるハードウェアの速度、さらにバックアップがリモート・テープ・サーバーに格納されるときのネットワーク待機時間によって大きく異なります。

(19)

バックアップ、リストアおよびリカバリは、十分なテストを行い、障害の防止だけでなく、割り当てられた時間枠内で確実にバックアップを行い、リストアおよびリカバリが品質保証契約（SLA）に準拠していることが必要です。

(20)

Recovery Manager のバックアップおよびリカバリの最適化 2005 年 7 月著書: Stephan Haisley 寄稿者: RMAN Development Oracle Corporation World Headquarters 500 Oracle Parkway Redwood Shores, CA 94065 U.S.A. 海外からのお問合せ窓口: 電話: +1.650.506.7000 ファックス: +1.650.506.7200 www.oracle.com

この文書はあくまで参考資料であり、掲載されている情報は予告なしに変更されることがあります。オラクル社は、本ドキュメントの無謬性を保証しません。また、本ドキュメントは、法律で明示的または暗黙的に記載されているかどうかに関係なく、商品性または特定の目的に対する適合性に関する暗黙の保証や条件を含む一切の保証または条件に制約されません。オラクル社は、本書の内容に関していかなる保証もいたしません。また、本書により、契約上の直接的および間接的義務も発生しません。本書は、事前の書面による承諾を得ることなく、電子的または物理的に、いかなる形式や方法によっても再生または伝送することはできません。