2023.12.19
SQLチューニング 2nd Season（第6回）
第2章 SQLチューニング対象選定方法（3/8）
SQLチューニング対象の選定方法 の3回目は
「チューニング対象選択のための情報及び活用ツール」の後半 です。
それでは早速スタートしましょう！！
2.2.3.1 SQL関連V$* VIEW（続き）
以下は、11gR1, 11gR2, 12cR1に新たに追加されたカラムをまとめた内容です。
| 11gR1 | 11gR2 | 12cR1 |
| IS_BIND_SENSITIVE | IO_CELL_OFFLOAD_ELIGIBLE_BYTES | FULL_PLAN_HASH_VALUE |
| IS_BIND_AWARE | IO_INTERCONNECT_BYTES | CON_ID |
| IS_SHAREABLE | PHYSICAL_READ_REQUESTS | IS_REOPTIMIZABLE |
| SQL_PATCH | PHYSICAL_READ_BYTES | IS_RESOLVED_ADAPTIVE_PLAN |
| SQL_PLAN_BASELINE | PHYSICAL_WRITE_REQUESTS | IM_SCANS |
| TYPECHECK_MEM | PHYSICAL_WRITE_BYTES | IM_SCAN_BYTES_UNCOMPRESSED |
| OPTIMIZED_PHY_READ_REQUESTS | IM_SCAN_BYTES_INMEMORY | |
| LOCKED_TOTAL | ||
| PINNED_TOTAL | ||
| IO_CELL_UNCOMPRESSED_BYTES | ||
| IO_CELL_OFFLOAD_RETURNED_BYTES |
io_cell_offload_eligible_bytes
Exadata装置を使用する場合、Smart Scanを利用して cell offloadingでどれだけ実行するか？ が重要な改善方法の
一つであると言えます。
したがって、装置がExadataであれば、io_cell_offload_eligible_bytesカラムを利用して Exadata Software 機能を
正しく使用しているか？ Health Checkを行うことができるため、チューニング対象となるクエリについての現状を
判断するにあたって大きな助けになります。
上記にある二つの表は、各バージョンごとに追加されたカラムをまとめたものです。
ここで言及されているカラム以外にもどのようなカラムが追加されたか？をまずは確認してみてください。
その上で、チューニング対象の抽出、及び性能分析を行う際にご活用いただければと思います。
Oracleの New Feature について確認した上で、バージョン別に新しく追加されたカラムを利用して、効率的に
チューニング対象となるSQLを抽出することは、SQLの性能管理において非常に重要な部分です。
$SQL_BIND_CAPTURE
SQLチューニング時、Bind変数が占める割合は非常に高いです。
Bind変数に値を正しく適用してこそ、SQLを完璧に実行することができます。
またその結果として、SQLチューニング作業が正しく行われることにも繋がります。
したがって、Bind変数に関連するビューである V$SQL_BIND_CAPTURE は、SQLチューニング時には常に使用
されるものであると考えてください。
このビューのCapture周期は、 Hidden Parameter である “_cursor_bind_capture_interval” によって決定され、
基本値は15分です。このCapture周期により、V$SQL_BIND_CAPTURE には全てのBIND DataがCaptureされません。
仮にCapture周期を短くしたとしても、すべてのSQL文のBIND変数をCaptureすることは不可能です。
また、当該ビューはCaptureされたデータであるため、リアルタイムに実行中のSQLのBind変数値は保存
されていませんが、V$SQL_MONITORビューを通じてリアルタイムのBind変数値を照会することができます。
| カラム | データ型 | 説明 |
| HASH_VALUE | NUMBER | Library Cache内にあるParent CursorのHash値 |
| SQL_ID | VARCHAR2 （13） | Library CacheにあるParent Cursor SQL識別子です。 |
| 名前 | VARCHAR2（30） | Bind変数の名前 |
| ポジション | NUMBER | SQL文でBind変数の位置(1から始まる) |
| データタイプ | NUMBER | Bind Dataタイプの内部的な識別子 |
| VALUE_STRING | VARCHAR2（4000） | 文字タイプで表現されたBind値 |
V$SQL_PLAN
Library CacheにLoadされたSQLの実行PLANを抽出することができます。
V$SQL_PLANビューはSQLのPLAN情報を照会する以外に、下記のように多様に活用されます。
・ SQLの実行計画 （ Execution PLAN ） ・ 特定のObject（ テーブルorインデックス ）を使うSQL照会（ Object_Nameカラムを活用 ） ・ データアクセスパターン把握 （ Full Table Scan or Index Scan – Optionsカラムを活用 ） ・ 特定のObjectの照会パターンを把握（ Object_Name, Access Predicates, Filter Predicatesカラムを活用 ） |
上記の内容以外にも、このビューを活用する方法は様々です。
例えば、特定のテーブルにインデックスを生成する時、V$SQL_PLANビューからそのテーブルを照会するSQLを
抽出して影響度を把握するのに使うこともできます。
このように、V$SQL_PLANビューは多様に活用することができるので、知っておいて損は無いビューです。
| カラム | Datatype | 説明 |
| HASH_VALUE | NUMBER | Library Cache内にParent CursorのHash値 （ADDRESSとHASH_VALUEでV$SQLAREAとJoin可能） |
| SQL_ID | VARCHAR2（13） | Library CacheにあるParent Cursor SQL識別子 |
| PLAN_HASH_VALUE | NUMBER | SQLプランに対する数値的な表現値。 一つのPLAN_HASH_VALUEを他のものと比較することで簡単に 二つの計画が同じかどうかを識別可能 |
| OPERATION | VARCHAR2（30） | SQL実行中に発生したOperationを表現 (Ex. TABLE ACCESS) |
| OPTIONS | VARCHAR2（30） | SQL実行中に発生したOperationのOptionを表現 (Ex. FULL) |
| OBJECT_OWNER | VARCHAR2（30） | Objectを所有しているUser名 |
| OBJECT_NAME | VARCHAR2（30） | SQL実行計画に表示されるObjectの名前 |
| OBJECT_TYPE | VARCHAR2（20） | ObjectのType |
| OPTIMIZER | VARCHAR2（20） | Planの最初の行に対するOptimizerの現在のMode (Ex. ALL_ROWS) |
| ID | NUMBER | 実行計画の各段階ごとに割り当てられた番号 |
| PARENT_ID | NUMBER | 現在の実行計画の直前の段階の割り当てられた番号。 |
| COST | NUMBER | OptimizerのCost-Basedアプローチで演算の予測されたコスト。 Rule-Basedアプローチの場合、このColumnの値はNullです。 |
| CARDINALITY | NUMBER | Cost-Based Optimizerで予測された値で、演算実行によって生成 されたRow数。 |
| BYTES | NUMBER (In Bytes) | Cost-Based Optimizerで予測された値で、演算実行によって生成 されたByte数。 |
| ACCESS_PREDICATES | VARCHAR2（4000） | WHERE条件に合致するDataを抽出する時、ACCESSで抽出される情報 |
| FILTER_PREDICATES | VARCHAR2（4000） | WHERE条件に合致するDataを抽出する時、FILTERで抽出される情報 |
V$SQLTEXT
SQLのFULL TEXTを照会できるビューです。V$SQL_TEXTはOracle9i環境でたくさん使っていたViewです。
10g以降から V$SQL, V$SQLAREAにSQL_FULLTEXT カラムが追加されたので、SQL TEXTを抽出するためには
使用しません。最近では使わないビューであるので、カラムの使用としてはここでは除外することにします。
V$SQL_MONITOR
CPU TimeまたはI/O Timeが5秒以上のSQLの実行履歴を照会することができます。
現在実行中のSQLの実行情報を1秒単位でRefreshし、SQLの実行が終わってもすぐに削除されません。
少なくとも1分間は実行履歴が保存されます。
また、リアルタイム実行中のSQLのBind値を抽出することができ、より意味があるBind変数値を抽出する際には
非常に便利に使うことが可能です。
| カラム | データ型 | 説明 |
| STATUS | VARCHAR2（19） | SQLの実行状況： EXECUTING – 実行中 DONE (ERROR) – Errorと一緒に実行が完了しました。 DONE (FIRST N ROWS) – すべてのRowがFetchされる前にApplication によって実行完了。 DONE (ALL ROWS) – すべてのRowがFetchされ、実行完了します。 DONE – 実行完了 (parallel execution) |
| SID | NUMBER | SQLを実行したSessionのSID(Session identifier)。 |
| SQL_ID | VARCHAR2（13） | 現在実行中のSQL ID |
| SQL_EXEC_START | 日付 | SQLの実行が開始された時間 |
| SQL_PLAN_HASH_VALUE | NUMBER | SQL PLANのハッシュ値 |
| SESSION_SERIAL# | NUMBER | Sessionのシリアル番号。 |
| ELAPSED_TIME | NUMBER | Elapsed time (in microseconds); 実行時に更新されます。 |
| CPU_TIME | NUMBER | CPU time (in microseconds); 実行時に更新されます。 |
| FETCHES | NUMBER | Fetch Row数; 実行時にUpdateされます。 |
| BUFFER_GETS | NUMBER | SQLのBlock Read量; 実行時にUpdateされます。 |
| DISK_READS | NUMBER | SQLのDisk Read量; 実行時にUpdateされます。 |
| DIRECT_WRITES | NUMBER | SQLのDirect Write量;実行時にUpdateされます。 |
現在実行してるSQLのBind変数の値を調べるためには下記のスクリプトを使うことができます。
SELECT bv.name name ,
bv.pos position,
bv.type type,
bv.value value
FROM v$sql_monitor s ,
xmltable( '/binds/bind'
passing xmltype( s.binds_xml )
COLUMNS name VARCHAR2( 30 ) path '@name' ,
pos NUMBER path '@pos',
type VARCHAR2( 15 ) path '@dtystr' ,
value VARCHAR2( 4000 ) path '.'
) bv
WHERE s.sql_id=&sql_id
AND s.sid=&sid
ORDER BY bv.pos
V$ACTIVE_SESSION_HISTORY
名前の通り、ActiveなSessionのHistory情報を提供します。
収集周期は1秒であり、保管周期はSysauxテーブルスペースのサイズとActive Sessionの数によって異なります。
DB セッションは CPU によって占有されたり、Idle wait classes 状態に属する Event を待機していない限り、
active 状態とみなされます。
また、sampleごとに各active sessionに対する一つの rowを含み、最も最新のSession sample rowsを一番最初に
結果値として返します。V$ACTIVE_SESSION_HISTORYは、チューニング対象を抽出するよりも、モニタリングと
パフォーマンス問題の分析のカテゴリーで非常に有用に使用されます。
特に、Blocking_*, Current_* カラムの場合、現在のセッションのHolderセッションや、現在のセッションが
どのようなオブジェクトをIOしているかなどの有用な情報を提供するため、パフォーマンス問題の分析が非常に容易です。
ほとんどのColumnはV$SESSIONと同じです。
下の表は、10gR2 ~ 12cR1 まで V$ACTIVE_SESSION_HISTORY にカラムが追加された部分をまとめたものです。
| 10gR2 | 11gR1 | 11gR2 | 12cR1 |
| FORCE_MATCHING_SIGNATURE | REMOTE_INSTANCE# | IS_AWR_SAMPLE | SQL_ADAPTIVE_PLAN_RESOLVED |
| BLOCKING_SESSION | TOP_LEVEL_SQL_ID | IS_SQLID_CURRENT | SQL_FULL_PLAN_HASH_VALUE |
| BLOCKING_SESSION_STATUS | TOP_LEVEL_SQL_OPCODE | SQL_OPNAME | IN_INMEMORY_QUERY |
| BLOCKING_SESSION_SERIAL#。 | SQL_PLAN_LINE_ID | PX_FLAGS | IN_INMEMORY_POPULATE1 |
| P1TEXT | SQL_PLAN_OPERATION | BLOCKING_INST_ID | IN_INMEMORY_PREPOPULATE1 |
| P2TEXT | SQL_PLAN_OPTIONS | BLOCKING_HANGCHAIN_INFO | IN_INMEMORY_REPOPULATE1 |
| P3TEXT | SQL_EXEC_ID | TOP_LEVEL_CALL# | IN_INMEMORY_TREPOPULATE1 |
| WAIT_CLASS | SQL_EXEC_START | TOP_LEVEL_CALL_NAME | DELTA_READ_MEM_BYTES |
| WAIT_CLASS_ID | PLSQL_ENTRY_OBJECT_ID | TIME_MODEL | CON_ID |
| XID | PLSQL_ENTRY_SUBPROGRAM_ID | IN_SEQUENCE_LOAD | DBOP_NAME |
| PLSQL_OBJECT_ID | CAPTURE_OVERHEAD | DBOP_EXEC_ID | |
| PLSQL_SUBPROGRAM_ID | REPLAY_OVERHEAD | ||
| PLSQL_SUBPROGRAM_ID | IS_CAPTURED | ||
| QC_SESSION_SERIAL# | IS_REPLAYED | ||
| CURRENT_ROW# | MODULE | ||
| CONSUMER_GROUP_ID | ACTION | ||
| REMOTE_INSTANCE# | MACHINE | ||
| IN_CONNECTION_MGMT | PORT | ||
| IN_PARSE | ECID | ||
| IN_HARD_PARSE | DBREPLAY_FILE_ID | ||
| IN_SQL_EXECUTION | DBREPLAY_CALL_COUNTER | ||
| IN_PLSQL_EXECUTION | TM_DELTA_TIME | ||
| IN_PLSQL_RPC | TM_DELTA_CPU_TIME | ||
| IN_PLSQL_COMPILATION | TM_DELTA_DB_TIME | ||
| IN_JAVA_EXECUTION | DELTA_TIME | ||
| IN_BIND | DELTA_READ_IO_REQUESTS | ||
| IN_CURSOR_CLOSE | DELTA_WRITE_IO_REQUESTS | ||
| DELTA_READ_IO_BYTES | |||
| DELTA_WRITE_IO_BYTES | |||
| DELTA_INTERCONNECT_IO_BYTES | |||
| PGA_ALLOCATED | |||
| TEMP_SPACE_ALLOCATED |
下記の表は、V$ACTIVE_SESSION_HISTORYで照会できるカラムについての説明です。
（Oracle 11.2.0.4バージョンに基づいて作成されました）
Oracleのマニュアルを参考すれば簡単に分かる内容ですが、V$ACTIVE_SESSION_HISTORYビューで照会できるデータは、パフォーマンスの問題を分析する時にとても便利なので、カラムの説明として追加しました。
| カラム | データ型 | 説明 |
| SAMPLE_ID | NUMBER | サンプルID |
| SAMPLE_TIME | TIMESTAMP（3） | Sampleがサンプリングされた時間 |
| SESSION_ID | NUMBER | Session識別子V$SESSIONのSIDとジョイント可能 |
| SESSION_SERIAL# | NUMBER | Session Serial番号(SessionのObjectに対する識別子)、V$SESSIONのSERIAL#と結合可能。 |
| SQL_ID | VARCHAR2（13） | サンプリング時間中に実行されたSessionのSQL文に対する識別子。 |
| SQL_PLAN_LINE_ID | NUMBER | SQLプランラインID |
| SQL_PLAN_OPERATION | VARCHAR2（30） | Plan Operation名 |
| SQL_PLAN_OPTIONS | VARCHAR2（30） | プラン運用オプション |
| SQL_EXEC_ID | NUMBER | SQL実行識別子 |
| SQL_EXEC_START | 日付 | SQLが実行された時間 |
| EVENT | VARCHAR2（64） | SESSION_STATE=WAITINGの場合、SessionのEventはサンプリングされる時間を待ちます。 SESSION_STATE=ON CPUの場合、このColumnはNULLです。 |
| EVENT_ID | NUMBER | 待機している、または最後に待機した Session の Resource や Event の識別子。 |
| EVENT# | NUMBER | 待機している、または最後に待機したSessionのResourceやEventのNo. |
| SEQ# | NUMBER | 待機現象を唯一区別できるSequence Number。 |
| P1TEXT | VARCHAR2（64） | 最初の追加のParameterのText |
| P1 | NUMBER | 最初の追加Parameter |
| P2TEXT | VARCHAR2（64） | 2つ目の追加のParameterのText |
| P2 | NUMBER | 2つ目の追加Parameter |
| P3TEXT | VARCHAR2（64） | 3つ目の追加のParameterのText |
| P3 | NUMBER | 3つ目の追加Parameter |
| WAIT_CLASS | VARCHAR2（64） | Sessionがサンプリング時間中に待機するEventのWait Class名、V$SESSIONのWAIT_CLASSと結合可能。 |
| WAIT_TIME | NUMBER | サンプリングされる時、SessionがCPUを占有する場合、SessionがEventを最後に待機した総Wait Time、 もしこの値が0の場合、Sessionはサンプリングを待機中とみなします。 Note: WAIT_TIME=0 かどうかを問わず、サンプリング中は 、WAIT_TIME 自体の値だけを観察する よりもSESSION_STATE を調べる方が便利、V$SESSION のWAIT_TIME と結合可能 |
| SESSION_STATE | VARCHAR2（7） | Sessionの状態 ・WAITING ・ ON CPU |
| TIME_WAITED | NUMBER | もし、SESSION_STATE=WAITINGの場合、Sessionは実際にEventを待機するために時間を費やし、 このColumnはサンプリングが収集される過程で待機される現象のために用意されている。 もし、Wait Eventが1秒以上持続し、1つ以上のSession Sample Rowによってかかった場合、 Wait Eventのための実際の時間経過は、そのSessionの最後のSample Rowに記入されます。 この情報は最新のSession Sampleに対しては使用できません。 |
| BLOCKING_SESSION_STATUS | VARCHAR2（11） | Blocking Sessionの状態 ・VALID ・ ホルダーなし ・ NOT IN WAIT ・ UNKNOWN |
| BLOCKING_SESSION | NUMBER | Blocking Sessionに対するSession識別子、BlockしているSessionが同じInstanceに存在し、 SessionがEnqueuesを待機したり、”buffer busy”である場合にのみ入力される、 V$SESSIONのBLOCKING_SESSIONと結合可能 |
| BLOCKING_SESSION_SERIAL# | NUMBER | Blocking Sessionのシリアル番号 |
| BLOCKING_INST_ID | NUMBER | BLOCKING_SESSIONで表示されるBlockerのInstance番号 |
| CURRENT_OBJ# | NUMBER | Sessionが参照しているObjectのObject ID、この情報はSessionがApplication, Cluser, Concurrency, User I/O Wait Eventを待機する場合のみ使用可能、V$SESSIONのROW_WAIT_OBJ#とジョイン可能 |
| CURRENT_FILE# | NUMBER | Sessionが参照しているObjectが含まれているBlockのFile Number、この情報はSessionがApplication, Cluser, Concurrency, User I/O Wait Eventを待機する場合のみ使用可能、V$SESSIONのROW_WAIT_FILE#と結合可能 |
| CURRENT_ROW# | NUMBER | Sessionが参照しているRow識別子、この情報はSessionがApplication, Cluser, Concurrency, User I/O Wait Eventを待機する場合にのみ使用可能、V$SESSIONのROW_WAIT_ROW#と結合可能 |
| REMOTE_INSTANCE# | NUMBER | Sessionが待機しているBlockをサポートするRemote Instance識別子、この情報はSessionがCluster eventsを待機する場合のみ使用可能。 |
| PROGRAM | VARCHAR2（48） | Operation System Program名 |
| MODULE | VARCHAR2（48） | DBMS_APPLICATION_INFO.SET_MODULE Procedure の実行で付与される MODULE 名 |
| ACTION | VARCHAR2（32） | DBMS_APPLICATION_INFO.SET_MODULE Procedureの実行で付与されるACTION名 |
| CLIENT_ID | VARCHAR2（64） | SessionのClinet識別子、V$SESSIONのCLIENT_IDENTIFIERと結合可能 |
| MACHINE | VARCHAR2（64） | Client の O/S Machine 名 |
SQL関連 DBA_HIST_* VIEW
SQL性能関連Dictionary ViewのAWRビューを通じて過去のSQL実行履歴を抽出することができます。
このようなSQL性能関連ビューはDBA_HIST_SQLSTAT, DBA_HIST_SQLBIND, DBA_HIST_SQL_PLAN などを使います。
それぞれのビューが持つ意味とカラム情報について説明します。
SQL性能改善が必要な対象を抽出したら、次の段階としてSQLに対する分析が必要です。
V$SQL では、改善が必要な対象だけを抽出することができるだけで、いつ、どのようなパターンで実行されるかは
分かりません。SQLの実行パターンは改善方法を決定する際には非常に重要な情報であるため、以前は業務担当者や
開発担当者を通じてどのような役割をするSQLなのか、いつ実行されるクエリなのかを100%依存して確認しなければ
なりませんでした。
DBA_HIST系列AWR性能ビューはHIST(ory)値、つまり、収集周期を持っているため、SQL改善対象を抽出することが
できるだけでなく、SQL自体を理解するのにも大きな助けになります。
AWRビューを利用して、既存の業務(開発)担当者から聞いたり、リアルタイムモニタリングを通じて確認可能だった部分を100%解消することはできませんが、当該SQLがいつから実行されるクエリなのか、毎日同じパターンで実行されるのか？
いつ実行計画(plan hash value)が変更されたのか？などの情報(根拠)を確認することができるので、
SQL改善過程で必須的に参考しなければなりません。
代表的なAWRビューであるDBA_HIST_SQLSTAT、DBA_HIST_SQLBIND、DBA_HIST_SQL_PLANなどを使います。
それぞれのビューが持つ意味とカラム情報について説明します。
DBA_HIST_SQLSTAT
SQL実行内訳の履歴情報を各SNAP_IDごとに照会できるビューです。
*TOTAL値はインスタンスがStartupされた後の統計値であり、*_DELTA値はDBA_HIST_SNAPHOSTビューのBEGIN_INTERVAL_TIMEからEND_INTERVAL_TIMEまでの値です。
| 10gR2 | 11gR1 | 11gR2 | 12cR1 |
| FORCE_MATCHING_SIGNATURE | 変化なし | PARSING_USER_ID | CON_DBID |
| PARSING_SCHEMA_NAME | IO_OFFLOAD_ELIG_BYTES_TOTAL | CON_ID | |
| PX_SERVERS_EXECS_TOTAL | IO_OFFLOAD_ELIG_BYTES_DELTA | ||
| PX_SERVERS_EXECS_DELTA | IO_INTERCONNECT_BYTES_TOTAL | ||
| BIND_DATA | IO_INTERCONNECT_BYTES_DELTA | ||
| PHYSICAL_READ_REQUESTS_TOTAL | |||
| PHYSICAL_READ_REQUESTS_DELTA | |||
| PHYSICAL_READ_BYTES_TOTAL | |||
| PHYSICAL_READ_BYTES_DELTA | |||
| PHYSICAL_WRITE_REQUESTS_TOTAL | |||
| PHYSICAL_WRITE_REQUESTS_DELTA | |||
| PHYSICAL_WRITE_BYTES_TOTAL | |||
| PHYSICAL_WRITE_BYTES_DELTA | |||
| OPTIMIZED_PHYSICAL_READS_TOTAL | |||
| OPTIMIZED_PHYSICAL_READS_DELTA | |||
| CELL_UNCOMPRESSED_BYTES_TOTAL | |||
| CELL_UNCOMPRESSED_BYTES_DELTA | |||
| IO_OFFLOAD_RETURN_BYTES_TOTAL | |||
| IO_OFFLOAD_RETURN_BYTES_DELTA | |||
| FLAG |
DBA_HIST_SQLBIND
SQL実行履歴のうち、Bind変数の値の履歴を照会できるビューです。
| カラム | データ型 | 説明 |
| SNAP_ID | NUMBER | スナップショット識別子 |
| DBID | NUMBER | SnapshotのためのDatabase識別子 |
| INSTANCE_NUMBER | NUMBER | SnapshotのためのInstance番号 |
| SQL_ID | VARCHAR2（13） | Library CacheにあるParent Cursor SQL識別子です。 |
| NAME | VARCHAR2（30） | Bind変数の名前 |
| POSITION | NUMBER | SQL文でBind変数の位置(1から始まる) |
| DUP_POSITION | NUMBER | 名前によってBindが行われ、Bind変数が重複すると、 最初のBind変数のPositionを提供します。 |
| DATATYPE | NUMBER | Bind Dataタイプの内部的な識別子 |
| DATATYPE_STRING | VARCHAR2（15） | Bind Dataタイプの文字的な表現 |
| VALUE_STRING | VARCHAR2（4000） | 文字タイプで表現されたBind値 |
| VALUE_ANYDATA | ANYDATA | Sys.AnyData型で表したBindの値。 この表現方法はプログラム的にBindの値を理解するのに便利。 |
DBA_HIST_SQL_PLAN
SQL文の実行PLANの履歴情報を照会できるビューで、SNAP SHOTごとにそれぞれPLAN情報を照会できるため、
SQL PLAN照会および変更履歴を把握する際に便利です。
| カラム | データ型 | 説明 |
| DBID | NUMBER | Database識別子 |
| SQL_ID | VARCHAR2（13） | Library CacheにあるParent Cursor SQL識別子 |
| PLAN_HASH_VALUE | NUMBER | SQLプランに対する数値的な表現値。 1つのPLAN_HASH_VALUEを他のものと比較することで 簡単に二つの計画が同じかどうかを識別可能 |
| ID | NUMBER | それぞれの実行計画段階に付けられた番号 |
| OPERATION | VARCHAR2（30） | SQL実行中に発生したOperationを表現 (Ex. TABLE ACCESS) |
| OPTIONS | VARCHAR2（30） | SQL実行中に発生したOperationのOptionを表現 (Ex. FULL) |
| OBJECT# | NUMBER | Table や Index の Object 番号 |
| OBJECT_OWNER | VARCHAR2（30） | TableやIndexを含んでいるSchemaを所有しているUserの名前。 |
| OBJECT_NAME | VARCHAR2（31） | Table や Index の名前 |
| OBJECT_TYPE | VARCHAR2（20） | Objectの種類 |
| OPTIMIZER | VARCHAR2（20） | Planの最初のRowに対するOptimizerの現在のMode (Ex. ALL_ROWS) |
| PARENT_ID | NUMBER | 現在の段階での演算結果に対する次の段階の実行識別子。 |
| COST | NUMBER | OptimizerのCost-Basedアプローチで演算の予測されたコスト。 Rule-Basedアプローチの場合、このColumnの値はNullです。 |
| CARDINALITY | NUMBER | Cost-Based Optimizerで予測された値で、演算実行によって生成されたRow数。 |
| BYTES | NUMBER (In Bytes) | Cost-Based Optimizerで予測された値で、演算実行によって生成されたByte数。 |
| PARTITION_START | VARCHAR2（5） | アクセスされたPartition範囲のStart Partition |
| PARTITION_STOP | VARCHAR2（5） | アクセスされたPartition範囲のStop Partition |
| PARTITION_ID | NUMBER | PARTITION_START, PARTITION_STOP Column 2つの値をまとめて計算する手順 |
| CPU_COST | NUMBER | Cost-Based Optimizer で予測されたCPUコスト。 Rule-Based Optimizer でこのColumnの値はNullです。 |
| IO_COST | NUMBER | Cost-Based Optimizer で予測されたI/Oコスト。 Rule-Based Optimizer でこのColumnの値はNullです。 |
| ACCESS_PREDICATES | VARCHAR2（4000） | WHERE条件に合致するDataを抽出するとき、ACCESSで抽出される情報 |
| FILTER_PREDICATES | VARCHAR2（4000） | WHERE条件に合致するDataを抽出する時、FILTERで抽出される情報 |
DBA_HIST_SQLTEXT
SQL TEXTがCLOBで保存され、SQL FULL TEXTの抽出が可能です。
このビューはV$SQLの情報をCaptureし、DBA_HIST_SQLSTATと一緒に使われます。
DBA_HIST_SQLSTATビューはSQL_FULLTEXTを持っていないため、DBA_HIST_SQLTEXTビューと結合して
使う必要があります。
| カラム | データ型 | 説明 |
| DBID | NUMBER | Database識別子 |
| SQL_ID | VARCHAR2（13） | Library CacheにあるParent Cursor SQL識別子 |
| SQL_TEXT | CLOB | CLOB形式で表したSQLの全文 |
| COMMAND_TYPE | NUMBER | Oracleコマンドタイプの定義 |
2.2.3 パフォーマンス管理ソリューションの活用
最後にパフォーマンス管理ソリューションの活用について説明していきます。
SQLチューニング対象をより簡単かつ正確に選定するためには、DBモニタリング及び性能管理ソリューションを
多くの場面で活用することができます。
ここでは『 MaxGauge（マックスゲージ） 』を利用したパフォーマンス管理について簡単に説明します。
MaxGaugeは、性能管理ソリューションとして最も認知度が高い製品です。
韓国の株式会社エクセム（日本国内では日本エクセム株式会社）が開発・販売するプロダクト製品です。
パフォーマンス管理ソリューションに求められる機能には、大きく2つが存在します。
その2つとは『 リアルタイム監視 』と『 事後分析 』です。
リアルタイム監視は文字通り、現在接続している Active Session の実行情報をリアルタイムで監視します。
そして、事後分析では OracleのAWR のようにすべてのセッションで実行した履歴を保存して障害やパフォーマンスの
問題が発生した時に原因の調査・分析を行うことができます。
リアルタイム監視
リアルタイムモニター（Realtime Monitor）
この画面は、リアルタイム監視モニター機能の一部を表示しています。
パフォーマンス管理製品を活用すれば、Oracleの重要なモニタリング指標であるCPU、Lock、Statistics、Wait、Active Sessionなどの各種情報を簡単にモニタリングすることができます。
さらには、現在実行されているセッション情報と、そのセッションで実行されているSQLの状況をリアルタイムで簡単に
確認することができるため、パフォーマンス問題を引き起こす原因となっている可能性があるSQLを簡単・正確に
抽出することが可能です。
事後分析
パフォーマンスアナライザー（Performance Analyzer）
こちらの画面は、パフォーマンス管理ソリューションの事後分析機能の一つであるTOP SQL抽出画面です。
パフォーマンス管理ソリューションは Oracle Databaseのすべてのトランザクション履歴情報 を保存しているため、
問題発生時に正確な対応が可能です。
また、区間別リソース(CPU, Elapsed Time, Logical I/O, Physical I/O, Execution)の使用量が多いSQLを簡単に
抽出することができ、Schema, Program, Module, Machine, OS User別に性能改善対象を抽出することが容易です。
このように性能管理ソリューションを活用すれば、より便利に目的の情報を抽出することができ、
SQLチューニング対象の選定に多くの助けを得ることができます。
SQLチューニングブログ 2nd Season（第6回） 終
次回ブログテーマ
『 ケース別 SQLチューニング対象選定方法 』
データベース運用でお困りなら
日本エクセムまで お気軽にご相談ください！！
私たちは、日本のITインフラにおける
『 プロジェクト運営 ～ システム運用 』の安定化と効率化を推進します。
日本エクセム 公式Xアカウント
最新情報を随時ポスト中！是非、フォローをお願いします。
掲載内容についてのお問い合せは
日本エクセム株式会社 営業推進部（担当：田中）まで
Mail：sales@ex-em.co.jp
こちらの問い合わせフォームもご利用ください
