Recovery Managerのチューニング・ポイント集：Oracleバックアップ／リカバリ講座（10）（3/4 ページ）

本記事では、Oracleデータベースのバックアップ／リストア／リカバリについて、そのアーキテクチャ、代表的なバックアップ手法、論理／物理バックアップ、RMANといった全般的な内容を解説していく。（編集部）

[渡辺学，株式会社アゲハ]

RMANでのバックアップにおけるチューニング方法

　Oracle SQLチューニング講座の第1回「パフォーマンス向上の最短コースを知る」のパフォーマンス・チューニング概要でも説明しましたが、バックアップでもその処理時間がシステム要件を満たしていれば、処理効率が悪くても特にチューニングする必要はありません。もちろんシステム構築時から要件を満たすために最大限のパフォーマンス・チューニングを行いたい場合や、例えば当初予想していたデータ量以上にデータが増え続けているシステムなどで、将来的にバックアップが許容時間内に終わらなくなってしまう場合などもあると思います。そこでここからはRMANのバックアップにおけるパフォーマンス・チューニングに関して説明していきます。

パフォーマンスの妥当性の判断

　RMANによるバックアップでは、ディスクもしくはテープのI/O処理が大きなウエートを占めているため、まずそれぞれにおけるパフォーマンスの妥当性について確認する必要があります。

　動的パフォーマンスビューのV$BACKUP_ASYNC_IO（非同期I/Oが使用されている場合）、V$BACKUP_SYNC_IO（同期I/Oが使用されている場合）を参照することで、RMANを介したバックアップ・デバイスへのスループットがどれくらいなのか、読み出し、書き出しのどちらにボトルネックがあるかを確認できます。

*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***

　TYPE列が「INPUT」の場合はディスクからの読み込み時の処理、「OUTPUT」の場合はバックアップ・デバイスへの書き込み時の処理を表しており、処理速度を表す「EFFECTIVE_BYTES_PER_SECOND」列や、バックアップ時のI/Oのパフォーマンスを表す値（「IO_COUNT」列／「LONG_WAITS」列）を確認することで、どこにボトルネックがあるのかを見つける手掛かりになります。

　リスト4を見ると、TYPE列が「OUTPUT」の「LW_IC」列の値が約「25％」となっています。一般的な目安としてこの値が定常的に「30％」を超えている場合には、書き込み時のI/O処理で問題がある可能性が考えられます（v$backup_async_ioとv$backup_sync_ioの詳細についてはマニュアル「Oracle Database リファレンス 10gリリース2（10.2）」を確認してください）。

　RMANのバックアップにおいて、パフォーマンスの妥当性に問題があった場合には、以降で挙げるポイントを確認し、チューニングを進めていくことになります。