目次
前回のおさらい
前回「データベースは心臓」は、本連載を執筆するにあたっての目的や、タイトルの由来をお伝えしました。
「私が経験した出来事を一人でも多くの方に共有することで、DBAの気持ちをお届け出来たらいいな！と思っております。」と記載しました通り、今回は「DBAあるある」をお伝えしていきます。
ある日、投げっぱなしジャーマンが来た
お客様「たろーさん、ちょっといいですか？」
たろー「はい、どうしました？」
お客様「昨日、某システムのデータベースが遅かったらしいんだけど、原因を調べてもらえないですか？」
たろー「わかりました。データベース構成を詳しく教えて下さい」
お客様「いや、そういった資料は無いんです。」
たろー「え？」
お客様「スキーマ名とパスワードが書かれた資料くらいならありますよ。」
たろー「…えーっと、データベースが遅かった時間帯って分かりますか？」
お客様「いやー、それも分からないんですよ。」
たろー「…データベースがアプリケーションから、どのように使われているか分かりますか？」
お客様「その辺の情報もないから、とにかく実機を触って調査して下さい。」
たろー「…はい、わかりました。」
投げっぱなしジャーマンが来た・・・
『詳しい情報は無いけど、DBが遅いからとりあえず調査してくれ。』
時々そういう状況に出会う不運なDBAの方もいらっしゃるのではないでしょうか？
今回は、見ず知らずのDBの状況をどこまで分析調査できるか？に迫ります。
何も準備をしていないのに・・・
実機には触れるとのことなので、とりあえずログの調査やら何やら出来ることからやっていきます。
パフォーマンス状況を調べるにあたり、まず分かったことを列挙すると
● データベースはシングルインスタンス構成（11gR2）
● Enterprise Edition ではなく、Standard Editionであり、AWRは使えない。
● Statspack はインストールすらされていない。
● vmstat 等のOSリソース情報も取得されていない。
・・・この状態で、何をどう調べりゃいいんだ？？？
Oracle Databaseに用意されている動的パフォーマンスビュー(V$)
こんな時、皆さんにお伝えしたい動的パフォーマンスビューがあります。
それは、V$SQLSTATSです。
このビューは、インスタンス起動時からのSQLカーソルに関する基本的なパフォーマンス統計情報を参照することができます。
とあるSQLが実行された回数（EXECUTIONS）や、処理に掛かった合計時間(ELAPSED_TIME)、そのうちCPU処理に費やされたCPU時間(CPU_TIME)等が一発で分かる優れものです。
サンプルコード
SQL毎の処理時間の大きい順に表示する
SELECT SQL_TEXT
,SQL_ID
,PLAN_HASH_VALUE
,EXECUTIONS
,ELAPSED_TIME
,CPU_TIME
,LAST_ACTIVE_TIME
FROM V$SQLSTATS
ORDER BY ELAPSED_TIME desc
ELAPSED_TIMEは処理に掛かった合計時間ですので、ORDER BY 句でその降順で表示してやれば、どのSQLに一番時間が掛かっているかが分かります。
ただ、実行回数（EXECUTIONS）が多いSQLのELAPSED_TIMEが大きくなるのは自然です。
たくさん実行されれば、その分、合計時間も増えますからね。
問題なのは、実行回数が少ないにも関わらず、ELAPSED_TIMEが大きいSQLです。
ELAPSED_TIME ÷ EXECUTIONS = １実行あたりの処理時間
ですので、その値が大きいSQLからチューニング候補に挙げていけばよいでしょう。
V$SQLSTATSには、ELAPSED_TIMEの他にCPU_TIMEや、今回はシングルインスタンス構成だったので登場しませんでしたが、Real Application Clusters（以下、RAC）構成の場合は CLUSTER_WAIT_TIMEでRAC固有の処理時間を確認することが出来るので、是非みなさん、マニュアルを参照しながら色々と試してみて下さい。
但し、先ほども述べましたが、これは、「インスタンス起動時からの合計時間」です。
AWRやStatspack のように、ある期間の情報を抽出出来るものではないので、注意して下さい。
本来なら、こういうことを想定して、定期的に Statspack スナップショットを取得したりOSリソース情報を取得する構成にすべきなんですが、予算の関係でそれが出来ないシステムって、世の中に多数存在するのが実情なんですよね・・・。
V$SQLSTATSの内部動作
V$SQLSTATSは10gR2 から登場した動的パフォーマンスビューで、参照時に共有プールの保護にミューテックスという仕組みを使用します。
共有プールの保護にはラッチとミューテックスという２つの仕組みがあるのですが、ミューテックスのほうが負荷が小さく、高速に動作します。
そのため、V$SQLSTATSはV$SQLやV$SQLAREAを参照するよりも効率よく、高速に動作します。
V$SQLSTATSは、私が Oracle の中で２番目に好きな動的パフォーマンスビューです。
では１番好きなのは何かと言うと・・・（それは、また別の機会に）
次回予告
次回は「正体不明のパフォーマンス悪化の謎を解き明かせ！」をお送りします。
お楽しみにっ！
投稿者プロフィール
