Comments
Description
Transcript
Recovery Managerのバックアップおよびリカバリの最適化
Recovery Manager のバックアップ およびリカバリの最適化 オラクル・ホワイト・ペーパー 2005 年 7 月 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 Recovery Manager のバックアップおよびリカバリの最適化 2 Oracle Corporation 発行「RMAN Backup and Recovery Optimization」の翻訳版です。 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 パフォーマンス値ではなく、単 に、バックアップ、リストアおよびリカバリ操作のパフォーマンス特性を表 しています。結果は、ハードウェア、オペレーティング・システム、ネット ワーク、データベース構成などによって大きく異なります。 Recovery Manager のバックアップおよびリカバリの最適化 3 Oracle Corporation 発行「RMAN Backup and Recovery Optimization」の翻訳版です。 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 は、フォー マットされていないブロックのバックアップを作成しません。 バックアップおよびリストア・パフォーマンスに影響を及ぼす 要素 バックアップおよびリストア・パフォーマンスに影響を及ぼす要素は多数ありま す。 • バックアップ・デバイスの速度 • 並列性 • バックアップ・セットの多重化 Recovery Manager のバックアップおよびリカバリの最適化 4 Oracle Corporation 発行「RMAN Backup and Recovery Optimization」の翻訳版です。 • バッファ・サイズ • 同期 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 つ割り当てると、デバイス Recovery Manager のバックアップおよびリカバリの最適化 5 Oracle Corporation 発行「RMAN Backup and Recovery Optimization」の翻訳版です。 が他のチャネルでバックアップ・セットを作成してから 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 が永続的に低下しないよう監視が必要にな ります。 Recovery Manager のバックアップおよびリカバリの最適化 6 Oracle Corporation 発行「RMAN Backup and Recovery Optimization」の翻訳版です。 もう 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、バックアップ・セット内のファ イル数）です。 Recovery Manager のバックアップおよびリカバリの最適化 7 Oracle Corporation 発行「RMAN Backup and Recovery Optimization」の翻訳版です。 バックアップ時にアルゴリズムが実際のバッファ割当てと一致するため、 MAXOPENFILES に異なる数値を使用してデータベースをバックアップする際の データファイルおよびバックアップ・セットに分割されるバッファを次の表に示 します。 MAXOPENFILES ブロック・ バッファ・ ファイル 1 度に開く バッファ・ サイズ （バイト） サイズ （Kb） 当たりの バッファ数 ファイル数 サイズ合計 （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 10 8192 128 4 10 4.5 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 つのバックアップには、小さいバッファ・サ Recovery Manager のバックアップおよびリカバリの最適化 8 Oracle Corporation 発行「RMAN Backup and Recovery Optimization」の翻訳版です。 イズおよび大きいバッファ・サイズを適用しました。サイズの変更には、次のコ マンドを使用します。 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 スレーブの有効化をお薦めします。チャネル・プロセ スは、スレーブ・プロセスへの書込みを割り当てて書込みの完了を待たずにバッ ファの充填を再開します。 Recovery Manager のバックアップおよびリカバリの最適化 9 Oracle Corporation 発行「RMAN Backup and Recovery Optimization」の翻訳版です。 テープ・ストリーミングとは 大量のデータが高速でテープに入力されている場合、テープ・ドライブは現 在進行中の書込みの終了と同時に次のテープの位置にさらに書込みが可能 です。ドライブ・モーターは、最高速で連続回転して書き込むため、テープ は書込みを行うヘッドの前を「流れ」ます。 テープ・ストリーミングの維持に十分なデータがない場合、通常テープ・ド ライブは、データの受信が中断した時点で停止し、書き込まれた最後のブ ロックの場所まで巻き戻した後、新規データの到着を待ちます。テープを絶 えず前後に動かすとテープの寿命が短くなり、バックアップ時間も遅くなり ます。 増分バックアップの使用 バックアップ実行時間を短縮する最善の方法の 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 ファイルの完全バック アップを作成した場合の結果を比較します。 Recovery Manager のバックアップおよびリカバリの最適化 10 Oracle Corporation 発行「RMAN Backup and Recovery Optimization」の翻訳版です。 空き領域（%） スキャンされた バックアップ 所要時間 ブロック数 されたブロック数 （秒） 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 列を確認してく ださい。 リストア速度は、最適化された増分バックアップによって影響されませ ん。バックアップの速度以外は、結果のバックアップ・セットは、通常 Recovery Manager のバックアップおよびリカバリの最適化 11 Oracle Corporation 発行「RMAN Backup and Recovery Optimization」の翻訳版です。 の増分バックアップによってバックアップが作成された場合と変わらな いためです。 ブロック・チェックの使用 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 バックアップに追加すると、少 なからずバックアップ・パフォーマンスに影響を与えます。これは自分の環境で テストを行って、ベンチマークに基づいたパフォーマンスへの影響を確認する必 要があります。 Recovery Manager のバックアップおよびリカバリの最適化 12 Oracle Corporation 発行「RMAN Backup and Recovery Optimization」の翻訳版です。 チェックサムおよび論理ブロック・チェックの影響は、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 の使用率および全体の時間 について同様にパフォーマンスに影響を与えます。 圧縮 バックアップ・ バックアップ・ 時間 CPU セットのブ読取り セット・サイズ （秒） （秒） ブロック数 （Mb） 無 778109 6079 559 209.37 有 778109 517 1133 1093.37 表 10: リストア速度に対する Recovery Manager の圧縮影響 バックアップ圧縮テストと同様、CPU に多くの時間がかかるうえ、バックアップ のリストアに 2 倍の時間を要します。 Recovery Manager 圧縮は、テープ・デバイスがネットワーク全体にマウントされ ている場合に使用すると効果的です。この場合、Recovery Manager は、バックアッ プ・ピースをデータベース・サーバーからテープ・サーバーに送信する必要があ ります。圧縮により、ネットワークを移動するデータ量が著しく減少し、バック アップおよびリストア時間の短縮だけでなく他のネットワーク・ユーザーへの負 担も軽減されます。 Recovery Manager のバックアップおよびリカバリの最適化 13 Oracle Corporation 発行「RMAN Backup and Recovery Optimization」の翻訳版です。 メディア・リカバリ・パフォーマンスに影響を及ぼす要素 リカバリ・パフォーマンスに影響を及ぼす要素は多数あります。 • アーカイブ・ログ数および増分の適用回数 • リカバリが必要なデータファイルの数 • アーカイブ・ログの場所 • パラレル・リカバリ • 一般的なデータベース・パフォーマンス この項では、このリカバリ段階でベース・レベルのバックアップ（レベル 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 秒であったことがわかります。 テスト・システムでは、バックアップはディスクに作成されたため、増分バック アップのリストア速度は予想どおり高速でした。増分バックアップがテープ・デ バイスまたはテープのロケーティングを必要とするテープ・サイロから発生して いる場合は、テープをマウントしてバックアップの先頭を見つけます。これには 長時間かかる可能性があります。各システムでのバックアップ・メディアからの アーカイブ・ログおよびリストアが、どの速度で大きく異なるかがここでの要点 です。今後、この相違点をテストする価値があります。このことで障害発生時、 時間期待値に合ったバックアップ戦略の実行だけですみます。 初期のテストで説明したとおり、増分バックアップのタイプ（累積または差分） も、アーカイブ・ログの適用が増分バックアップのリストアよりも低速かどうか の判断に役立ちます。 Recovery Manager のバックアップおよびリカバリの最適化 14 Oracle Corporation 発行「RMAN Backup and Recovery Optimization」の翻訳版です。 リカバリが必要なデータファイルの数 メディア・リカバリの実行時は、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）が使用されている場合は、リ Recovery Manager のバックアップおよびリカバリの最適化 15 Oracle Corporation 発行「RMAN Backup and Recovery Optimization」の翻訳版です。 カバリ時間は一層長くなります。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に設定 Recovery Manager のバックアップおよびリカバリの最適化 16 Oracle Corporation 発行「RMAN Backup and Recovery Optimization」の翻訳版です。 されている場合は、デフォルトのバッファは 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 の使用率もさら に高くなります。 Recovery Manager のバックアップおよびリカバリの最適化 17 Oracle Corporation 発行「RMAN Backup and Recovery Optimization」の翻訳版です。 結論 このホワイト・ペーパーでは、バックアップ、リストアおよびリカバリ速度の最 適化を図るために検討すべき要件を多数示しました。 バックアップおよびリストア処理の速度は次の点を考慮することで制御できます。 • 増分バックアップを使用する。リストア速度がバックアップ速度よりも 重要な場合は、累積増分バックアップを使用する。 • 使用可能な各テープ・デバイスにチャネル 1 つを割り当てる。 • テープにバックアップを作成する場合は、メモリー・バッファのサイズ を増やす。 • バックアップが必要なデータ量を減らす − 空または静的データファイ ルのスキャンは時間およびリソースを著しく浪費する。 • ブロック・チェンジ・トラッキング機能を使用して大幅に増分バックアッ プ・パフォーマンスを高める。 • ブロック・チェック機能のタイプをバックアップおよびリストアに対し て有効化する。 • Recovery Manager またはメディア・マネージャ・レイヤーで使用されてい る圧縮タイプ。 メディア・リカバリ速度は次を考慮することで制御できます。 • 適用が必要なアーカイブ・ログ数が多いほど、リカバリ速度は遅くなる。 • リストアおよび適用が必要な増分バックアップの数。 • 使用される増分バックアップのタイプ（差分または累積）。 • リカバリが必要なデータファイルの数。リストアおよびリカバリする データファイルが多いと、バッファ・キャッシュへの読取りおよびデー タファイルへの書込みが必要なデータ・ブロックが増えることを意味す る。 • 破損問題が発生した場合は、データファイル全体をリストアおよびリカ バリするかわりにブロック・メディア・リカバリを使用する。 • パラレル・リカバリを使用する。これにより、パラレル実行スレーブ・ プロセス間で REDO 適用処理をパーティション化して REDO 適用時間を 短縮できる。 • 一般的なデータベース・パフォーマンスのチューニング。データベース の速度が遅い場合、リカバリ、データベースを最適化してからリカバリ の最適化を始めること。 ここで実施したテストにより最適化の要点を示しました。提案された調整を行っ ても、システムによってパフォーマンス効果が異なることをご了承ください。バッ クアップ、リストアおよびリカバリ速度は、システムで使用されるハードウェア の速度、さらにバックアップがリモート・テープ・サーバーに格納されるときの ネットワーク待機時間によって大きく異なります。 Recovery Manager のバックアップおよびリカバリの最適化 18 Oracle Corporation 発行「RMAN Backup and Recovery Optimization」の翻訳版です。 バックアップ、リストアおよびリカバリは、十分なテストを行い、障害の防止だ けでなく、割り当てられた時間枠内で確実にバックアップを行い、リストアおよ びリカバリが品質保証契約（SLA）に準拠していることが必要です。 Recovery Manager のバックアップおよびリカバリの最適化 19 Oracle Corporation 発行「RMAN Backup and Recovery Optimization」の翻訳版です。 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 Copyright © 2005, Oracle. All rights reserved. この文書はあくまで参考資料であり、掲載されている情報は予告なしに変更されることがあります。 オラクル社は、本ドキュメントの無謬性を保証しません。また、本ドキュメントは、法律で明示的または暗黙的に記載 されているかどうかに関係なく、商品性または特定の目的に対する適合性に関する暗黙の保証や条件を含む一切の保証 または条件に制約されません。オラクル社は、本書の内容に関していかなる保証もいたしません。また、本書により、 契約上の直接的および間接的義務も発生しません。本書は、事前の書面による承諾を得ることなく、電子的または物理 的に、いかなる形式や方法によっても再生または伝送することはできません。 Oracle は、Oracle Corporation の登録商標です。その他の名称は、それぞれの所有者の商標です。