第7回 続々・バッファキャッシュ関連の待機イベントとパフォーマンス統計情報を読み解く：しばちょう先生の試して納得！DBAへの道（改）（7）（3/3 ページ）

データベース技術や知識は、座学だけでなく「実際に手を動かして、実際に試して」理解を深めよう──。日本オラクルのデータベーススペシャリストが「新人をDBAに育てる際に使用する課題」をベースに、DBAがすぐ実践できる即効テクニックを紹介。今回は「バッファキャッシュ関連の待機イベントとパフォーマンス統計情報の読み解き方」について、前々回、前回に引き続き解説します。

[柴田長，日本オラクル株式会社]

演習5：再び、AWRレポートから「キャッシュヒット率が高い」かどうかを評価する

　3つの待機イベント「db file sequential read」「db file scattered read」「direct path read」が発生する処理の違いと、関連する幾つかのパフォーマンス統計情報を理解した今、あらためて、第5回の演習1で提示したAWRレポートの、99.00%というキャッシュヒット率が、高いのか低いのかをあらためて評価してみましょう。きっと皆さんが確認したいであろう、統計情報のセクションも掲載しておきます。

　Top5待機イベントには、シングルブロック読み込みを示す待機イベント「db file sequential read」と、マルチブロック読み込みを示す待機イベント「db file scattered read」が記録されています。「これだけを見ると、Table Full Scanが発生しているのかと疑いますが……」という話をしていましたが、あらためて、パフォーマンス統計情報を見て判断してみましょう。

　ディスクから読み込まれた総回数は、統計情報physical readsから94,797回であり、統計情報physical reads cacheが9万4797回であることから、その全てがバッファキャッシュ上へ読み込まれたことが理解できます。

　統計情報「physical reads direct」が0回ですから、大きな表のTable Full Scanは発生していないでしょう。ただし、統計情報physical reads prefetch warmupがカウントアップしていることから、Pre-Warming機能が動作していることが理解できます。

　AWRレポートにはインスタンス起動日時を示す「Startup Time」とスナップショット日時「Begin Snap」が記載されていますが、その2つの日時が近いことからも、バッファキャッシュが空の状態で負荷テストを開始したのだろうと推測することもできますね。なるほど。待機イベント「db file scattered read」はPre-Warming機能が動作したために発生していると推測できるので無視しても良いでしょう。

　次に、統計情報physical readsの1秒間当たりの回数を確認してみると、525回／秒です。これは、どのような数字なのかイメージができますか？　ちょっと古い私の指標で申し訳ないですが、8KB単位のI/Oで、7200rpmのHDD1本当たり200〜300IOPSは稼げます。つまり、525IOPSは、HDDが2、3本あれば十分なのです。もちろん、HDDへは書き込み処理も行われますから、統計情報physical writesの値（179.08回／秒）を加算しても、約700IOPSでしょう。

　もちろん、HDDの書き込み性能と読み込み性能は同じではなく、書き込みコストの方が大きい傾向にあります。80％ぐらい（160〜240IOPS）のI/O性能は得られると想定すると、700/160＝4〜5本で問題なさそうという結論になります。結論として、求められるIOPSはそれほど多くはないので、「このAWRレポートのキャッシュヒット率は十分に高い」と私は評価します。

　ここまで長々と解説してきましたが、1秒間当たりのphysical readsとphysical writesの値は、AWRレポートのLoad Profileセクションに掲載されていたりします。よって、以前も述べたように、「ここ（AWRレポートの始め）に全ての情報が集約されていると言っても過言ではない」ですね。

　さて、複数回にわたり、バッファキャッシュ関連の待機イベントとパフォーマンス統計情報を体験いただきましたが、いかがでしたでしょうか？　体験した待機イベントと統計情報は、全体の数と比較すれば非常に少ないですが、一番よく目にするものだと思います。次に何かしらのAWRレポートを見た時に、「こんな処理が流れているのでないか？」と推測できるようになってきていると思います。これが「実に推理小説を読むように面白い」と感じるようになってきたら、あなたはもう、Oracle Databaseから離れることはできないでしょう。

　ちなみに、今回のように待機イベントと統計情報から、「ディスクのIOPSが足りている？　足りていない？」といった議論が可能になっているのも、実はASMを使用してデータファイルを全ディスク上にストライピングしているからです。一昔前のように、RAWデバイス上にデータファイルを配置していたとしたら、RAWデバイスごとのIOPSを分析しなければならなかったのですよね。そうすると、「ASMによって細かく分析しなくてよくなったというメリットもあるな」と、ちょっと今回の連載には直接関係ないのですけど、ASM好きな私としては感じました。それではまた次回お会いしましょう！

筆者紹介

柴田長（しばた つかさ）

日本オラクル データベーススペシャリスト。Oracle GRID Centerの設立当初からオラクルの持つ最新技術をパートナー各社と共同で検証し、これまでにリアルなパフォーマンスに裏付けられた数多くのホワイトペーパーを執筆。2017年現在は、大規模案件の現場を訪問し、お客さまのシステムに最適なソリューションデザインの提案やパフォーマンストラブルの問題解決に従事している