「バッファキャッシュ」関連の待機イベントと「パフォーマンス統計情報」を読み解く:しばちょう先生の試して納得! DBAへの道(改)(5)(1/2 ページ)
データベース技術や知識は、座学だけでなく「実際に手を動かして、実際に試して」理解を深めよう──。日本オラクルのデータベーススペシャリストが「新人をDBAに育てる際に使用する課題」をベースに、DBAがすぐ実践できる即効テクニックを紹介。今回は「バッファキャッシュ関連の待機イベントとパフォーマンス統計情報の読み解き方」を解説します。
皆さんこんにちは。日本オラクルの“しばちょう”こと、柴田長(しばたつかさ)です。
「データベースのパフォーマンス問題が発生!」──。そんな時に参照するのがAWR(Automatic Workload Repository)レポートやStatspackレポートです。しかし、待機イベントやパフォーマンス統計情報は意外と“絶妙なタッチ”で記載されています。それを読み解く力がなければ問題を具体的に解決することはできません。
今回はこのAWRレポートを読めるようなるまでの第一ステップとして「バッファキャッシュ関連の待機イベントやパフォーマンス統計情報の読み解き方」を体験していきましょう。
演習1:AWRレポートから「キャッシュヒット率が高い」かどうかを評価する
以下のAWRレポート(先頭部分だけ抜き出したもの)を確認し、キャッシュヒット率が高いかどうかを考えてみましょう。
このAWRレポートは、私のPCから引っ張り出してきたOracle Database 11g Enterprise Edition Release 11.2.0.2のものです。Snap Timeから、2011年の2月に取得したものと分かります。AWRレポートはバージョンが上がるにつれて進化し続けていますが、基本的な読み方は大きく変化していません。安心してください。
AWRレポートを分析する際にまずやってほしいことは、上記で抜粋した「AWRレポートの先頭部分」に全て目を通すことです。というのは、ここに全ての情報が集約されていると言っても過言ではないからです。経験豊富なDBAならば本演習の答えはサラっと出てしまうでしょう。しかし、そこをネチッこく私が解説していくのがこの連載の目的なのでガマンして読み進めてくださいね。
まず、最上部でバージョン情報(Release)、Oracle Real Application Clusters(RAC)のデータベース構成かどうか、CPUコア数(CPUs、Cores、Sockets)、物理メモリ容量(Memory/GB)などの環境情報から、他のAWRレポートと比較する場合にハードウェア増強が行われているか否かを認識できます。Memoryに関しては、Report SummaryにあるCache SizesでもSGA(System Grobal Area:Oracle Databaseが使うメモリ領域)の設定サイズを確認しておきましょう。
次に確認するのは、このAWRレポートの期間(Elapsed)です。値は約3分間(180秒)であることを読み取れます。比較する他のAWRレポートの期間が異なる場合、待機イベントやパフォーマンス統計情報の「総回数」は単純に比較できません。この値は必ず把握しておきましょう。
Load Profileのセクションは、ワークロードの傾向を理解するために重要な情報です。私がまず確認するのは「Redo size」行の「Per Sec」列の値です。感覚値としては、秒間のRedo生成量(Bytes/sec:バイト/秒)が1MB以下ならば更新処理が少ないと感じます。5M〜10MB/秒前後ならば標準的で、20MB/秒を超えてくると少し多め、40MB/秒を越えると多いという感覚です。ちなみに私が経験した最も多いRedo生成量は、1つのデータベースインスタンスで200MB/秒を超えていました。
Instance Efficiency Percentagesのセクションには「Buffer Hit %」という、それらしい名称の項目があります。これが「99.00」と表示されていることから、演習1の回答は「高い」になる気がします。
しかし、こんな簡単な演習であるはずはないと疑問を抱いた皆さん、その通りです。「99.00」という数字は確かに「100%」に近い値ではありますが、「高い」か「低い」かは相対的で、曖昧なものです。厳密に何%以上だから高くて十分だ、という指標にはなりません。
キャッシュヒット率は、「バッファキャッシュを経由するデータブロックの読み込み総回数に対して、ディスクから読まずにバッファキャッシュ上にキャッシュされているデータブロックが見つかった(ヒットした)回数の割合」のことです。つまり、100%からヒット率を引いた確率でディスクからデータブロックを読み込んだことを意味するので、今回のAWRレポートでは「1%」がディスクへアクセスしたことになります。この1%分のIOPSに対してディスクの持つ性能が上回るかどうかが、キャッシュヒット率の「高い/低い」を判断するのに重要な指標になります。
例えばキャッシュヒット率が99.00%の場合、バッファキャッシュを経由するブロック読み込み総回数が100回ならばディスクI/Oが1回発生するだけです。しかし、総回数が100万回ならば1万回もディスクI/Oが発生することになります。具体的にはディスクI/Oの回数を見極めると見えてくるわけですね。
なお、キャッシュヒット率は次の計算式で表すこともできます。次の演習で解説するバッファキャッシュに関連する待機イベントやパフォーマンス統計情報を実機で体験することで、この計算式の意味を理解することができるでしょう。
1 − ("physical reads cache" / ("consistent gets from cache" + "db block gets from cache"))
Copyright © ITmedia, Inc. All Rights Reserved.
関連記事
- 【Oracle Database】忘れていませんか? 「アラートログ調査」に必要な、たった3つのキホン
データベース管理システムの運用でトラブルが発生したらどうするか。データベースサポートスペシャリストが現場目線の解決Tipsをお届けします。今回は基本編として「アラートログの調査で押さえるべき3つのポイント」を解説します。【Oracle Database 12c対応版】 - 障害発生! 問題切り分けはスピード勝負
Oracleデータベースの運用管理者は、突発的に直面するパフォーマンス障害にどうやって対処したらよいか。本連載は、非常に複雑なOracleのアーキテクチャに頭を悩ます管理者に向け、短時間で問題を切り分け、対処法を見つけるノウハウを紹介する。対象とするバージョンはOracle8から9iまでを基本とし、10gの情報は随時加えていく。(編集局) - パフォーマンス向上の最短コースを知る
本連載では、Oracleデータベースのパフォーマンス・チューニングの中から、特にSQLのチューニングに注目して、実践レベルの手法を解説する。読者はOracleデータベースのアーキテクチャを理解し、運用管理の実務経験を積んでいることが望ましい。対象とするバージョンは現状広く使われているOracle9iの機能を基本とするが、Oracle 10gで有効な情報も随時紹介していく。(編集局) - SQL実践講座
SQLは、データを操作するために非常に簡単な構文で構成されているように見えます。ところが実際に使い込んでいくと、一見簡単に取得できるように見えるデータが取得できない場面にぶち当たることもあります。こういった場面のために、SQLの効率的な使い方をエッセンスにしてお伝えします。