STATSPACKを使用したSQL分析

STATSPACKを使用してパフォーマンスに影響を与えていると思われるSQLを分析します

 

SQLに関する情報とは

 

STATSPACKにはSQLに関する情報が６つあり、「SQL　XXX　by　XXX」の形式で表示されます

重複する情報もありますが、問題あるSQLを推測するには有効な情報です

それぞれの上位に表示されるSQLは注意が必要です

 

１．SQL ordered by CPU

SQLがCPU負荷の高い順に表示されます

処理負荷が高いことを示しているので、まずはチューニングの対象と考えます

無駄な処理をしている可能性が高いので、処理負荷が高い原因を分析します

LOOP処理やソート処理（JOINによる暗黙ソートなど）を疑います

 

２．SQL ordered by Elapsed

SQLがElapse Timeの長い順に表示されます

処理時間が長いということはリソースを長く、多く消費していることを示しているので、まずはチューニングの対象と考えます

ソート処理（JOINによる暗黙ソート等を含む）やファイルI/Oが多いか、ラッチ競合は発生していないかを疑います

 

３．SQL ordered by Gets

SQLがバッファ読込（所謂LOGICAL　READです）の多い順に表示されます

バッファ取得が多いということはラッチ競合の原因となる可能性がありますので、ラッチ競合が出ている場合はチューニング対象と考えます

Segments by Logical Readsのオブジェクト（テーブルやインデックス）とSQLがそれらのオブジェクトを使用しているようなら要注意です

 

４．SQL ordered by Reads

SQLがDISK（物理）読込（所謂PHYSICAL　READ)の多い順に表示されます

過剰なI/OはCBLCラッチ競合の遠因となる可能性が大きいので、ラッチ競合が出ている場合はチューニング対象と考えます

Segments by Physical Readsのオブジェクト（テーブルやインデックス）とSQLがそれらのオブジェクトを使用しているようなら要注意です

 

５．SQL ordered by Executions

SQLが実行回数の多い順に表示されます

頻繁に実行されるSQLは、全体的なパフォーマンスに最も大きな影響を与えるため、最初からチューニングの対象と考えます

実行回数が妥当かを分析します

特に、CPU負荷が高いとか、Elapse Timeが長いところにも出現しているSQLはチューニングの対象です

実行回数が多いので、少しのチューニングで効果が大きい場合もあります（塵も積もれば何とやらです）

 

６．SQL ordered by Parse Calls

SQLが解析回数の多い順に表示されます

ハードパースの時間やライブラリキャッシュの使用など無駄なリソース使用の原因となりますので、他のチューニングより優先度は低くなりますがチューニング対象と考えておきます

SQLの構文の問題の可能性がありますので、コーディング規約やバインド変数化やPL/SQL化などSQLの作りに問題はないかを分析します

 

チューニングのポイント

STATSPACKのSQL order　by　XXXの項目値のまとめとチューニングのポイントは以下になります