SPA利用のツボ！ 「テストモード」「評価メトリック」の選び方：【12c対応】とにかく苦労しない「RAT」簡単攻略テクニック（5）（2/3 ページ）

[長内麻記，株式会社アシスト]

Convert SQLSETの性能情報は「環境の影響を受ける」

　3つのテストモードのうちConvert SQLSETには、さらに注意点があります。「Covert SQLSETで抽出した性能情報は、STS取得環境に流れたその他の処理の影響を受けた結果」なのです。

　例えばバッチ処理の実行中にリソースが枯渇した場合、同時間帯に流れていた他のSQLの影響で、経過時間が長くなっている可能性があります。このときもしもSTSを取得していたとすると、STSには遅くなった経過時間の情報が格納されてしまいます。この情報をConvert SQLSETのテスト結果として用います。

　これに対して、Test ExecuteはSQLを1本1本シリアルに実行するため、その他の処理の影響を受けていない経過時間を記録します。

　この2つを比較すると誤った結論に飛び付くことになります。外的要因によってConvert SQLSETの実行結果が長くなったために、本当は性能が劣化するSQLであっても、性能が改善しているように見えてしまう可能性があるのです（図4）。

図4　あるSQLを外的要因がない環境で検証した場合（左）と外的影響があった場合（右）では結果が大きく異なる

　Convert SQLSETを使った場合、この問題を避ける方法があります。性能が劣化するSQLに加えて、性能が改善するSQLもチェックしましょう。

　性能が改善する全てのSQLをチェックすると時間がかかり過ぎるので、実行計画が変わったSQLのうち、××％以上性能が改善したものはチェック対象外、××％未満の性能改善だったものはチェック対象にするというように、あらかじめしきい値を決めておくとよいでしょう。

「試行の比較」ステップで選択する“比較メトリック”

　ここまでは経過時間で比較する場合を考えて説明しました。

　「試行の比較」ステップでは、経過時間以外の比較メトリック（評価する性能軸）を選択できます。他の比較メトリックを選んだ場合にも、Convert SQLSETについて留意点があります。

　代表的な比較メトリックとそれぞれ評価できる内容、Convert SQLSET利用時の留意点を表1にまとめました。

比較メトリック	計測内容	評価できること	Convert SQLSET利用時の留意点
オプティマイザコスト （optimizer_cost）	オプティマイザが見積もった実行計画のコスト	実行計画の良しあし（≠性能の良しあし）	なし
バッファー読み取り量（buffer_gets）	バッファー読み取りブロック数	SQL文自体の負荷	本番環境のUNDO読み取り量を含むため、試行値が大きくなる可能性がある（特にOLTP処理において）
CPU時間 （cpu_time）	SQLの処理に要したCPU処理時間	ハードウェア性能を加味したSQLのCPU処理時間（待機イベントの時間を考慮しない）	本番環境とテスト環境のハードウェア性能の差を加味する必要がある
経過時間 （elapsed_time）	SQLの実行に要した経過時間	ハードウェア性能を加味したSQLのレスポンス速度（待機イベントの時間も考慮する）	バッファーまたはディスクアクセスの影響を受ける。Test ExecuteはSQLを2回以上実行するため、バッファーからの読み取りを含み、計測値に差が出る可能性がある。ハードウェア性能の差を加味する必要がある
表1　比較メトリックごとの評価内容とConvert SQLSET利用時の留意点

　オプティマイザコストを比較メトリックに選んだ場合、Convert SQLSET利用時の留意点は特にありません。そもそもこのコストはオプティマイザが見積もった実行計画の良しあしを表していて、性能の良しあしとは直結しません。性能を確認するのであれば、その他の3つの比較メトリックから選びましょう。

　CPU時間や経過時間を選んだ場合、ハードウェア性能によって結果が左右されるため、Convert SQLSETであってもTest Executeであっても実行環境間のハードウェアの性能差を考慮しなければなりません。

　バッファー読み取り量を選んだ場合、バッファーキャッシュから読み取るブロック数は、ハードウェア性能による影響を受けません。そのため、SQL自体の負荷として取り扱うことができます。ただし、Convert SQLSETで抽出した結果はUNDO読み取り量を含むため、値が実際よりも大きくなる傾向があります。注意が必要です。