調査時のポイント
１．変更SQLを探す
変更時には履歴をとり、調査が行いやすいように考える。
３．同時アクセス数の増加していないか
DBサーバのMemory利用率でSwap（pi,po）が多く発生している状況では
調整すべき。
対策：①Memory追加
②同時アクセスを減らす
２．統計情報が最新であるか？
データ更新がされているが、統計情報が更新されていないと
古い情報でSQLが動く。
４．ロックの競合がないか
発生していた場合は、アプリの要因であれば見直しを考える。
５．StatsPack注目点
①大量のバッファ読み込みを行っているSQL
SQL ordered by Reads for DB
※適切でない索引や、連結索引の一部を使用している可能性がある
②実行回数の多いSQL
SQL ordered by Executions
※実行回数の多いSQLは、1回の実行でアクセスするブロック数が少ない場合でも、
合計すると非常に多くのブロック数となることがあるため、チューニング対象となります。
例えば、1回の実行で20ブロックをスキャンしている（読み込む）SQLが10万回実行されている
場合を考えてみてください。
チューニングにより、スキャンする（読み込む）ブロック数をわずか5ブロック減らせれば、
5ブロック*10万回で50万ブロック分、ORACLEブロックサイズが8Kbytesの場合では、4Gbytes分
の論理読み込みを排除することができる計算になります。
③
consistent gets
SQL検索のためにアクセスしたブロック数
→SQL実行に費やすCPU時間はこれに比例する
この値が二倍になっている場合は、使用するCPU時間も２倍ということになる
★実行計画の取得
・StatsPackから実行計画を確認する方法
SQL> conn perfstat/password
SQL> @$ORACLE_HOME/rdbms/admin/sprepsql.sql
・
・
・
通常のレポート作成と同様にbeginとendのsnap_idを指定して・・・
次のところで「Hash Value」値を指定する。
Specify the Hash Value
~~~~~~~~~~~~~~~~~~~~~~
hash_valueに値を入力してください: 1315228457
Hash Value specified is: 1315228457
以降は同様にレポート名を指定すると出来上がり！
レポートの内容は、こんな感じになりました。
********************************************************************************
--------------------------------------------------------------------------------
| Operation | PHV/Object Name | Rows | Bytes| Cost
|
--------------------------------------------------------------------------------
|SELECT STATEMENT |----- 184110842 -----| | | 1939
|
|SORT AGGREGATE | | 1 | 22 |
|
| PARTITION RANGE ALL | | | |
|
| TABLE ACCESS FULL |TEST_TAB1 | 52K| 1M| 1939
|
--------------------------------------------------------------------------------
********************************************************************************
フルスキャンが発生している事を確認できました。
今回の例は簡単なSQLでしたが、結構使えそうな機能です。
