概要
バインド変数を使用することで、大きく以下のようなメリットが得られます。
* 共有プールの節約
* SQLインジェクション対策になる
バインド変数の関連箇所
バインド変数の使用
バインド変数の問題点
バインドピークとその問題点
スポンサーリンク
ハードパースとソフトパースについての解説
様々な実行計画を生成し、最適な実行計画を選択
統計情報が収集済みのとき(ソフトパース)
* 統計情報を利用
* 統計情報:表、列、索引、システム
統計がない時or古い時(ハードパース)
* 動的サンプリングで収集した統計情報を利用
統計が不足している際、SQL実行時に自動的統計をサンプリング
サンプリングレベルを0-10で指定(0はOFF)
実行計画生成時、1つの親カーソルに対し、1つ以上の子カーソルが生成
以前に実行されていない場合⇒ハードパース(実行計画を生成)
ディクショナリ・キャッシュを利用し、SQL文の構文や権限をチェック
共有プールの共有SQL領域を確保⇒実行計画を生成
共有SQL領域にキャッシュされている実行計画を利用
- オプティマイザや行ソースジェネレータによる処理が不要⇒CPU負荷の軽減
- 新たな共有SQL領域の確保が不要⇒メモリ使用量の低減
以前に実行されている場合⇒ソフトパース(実行計画を再利用)
共有SQL領域上にある以前の実行計画を再利用
SQL文を実行した際のメモリ上の動作を説明
SQL文を発行した後、メモリ上では大きく以下のような流れとなる
1. SQLリクエストを受信
↓
2. カーソルのオープン
↓
3. 実行計画の生成/再利用
↓
4. SQL文の実行
↓
5. カーソルのクローズ
- 問合せ実行状況の情報: たとえば、全表スキャンの場合、この領域にはスキャンの進行情報が格納される
- SQL作業領域:ソートやハッシュ結合など、メモリー集中型の操作に必要な場合に割り当てられる
SQLや実行計画を解析する際の最低限知っておくべきと考える情報を記載します。
Oracleは実行されたSQL文を13桁の「文字列」で管理していますが、この文字列のことをSQL識別子(SQL_ID)と呼びます。
SQL識別子(SQL_ID)はSQLテキストに依存して作成されます。そのため、以下の特徴があります。
SQL_IDは、13文字の文字列で表される基数32の数字です。
各文字は数字または32の小文字のいずれかとなります。
※例) ddzxfryd0uq9t
文字e、i、l、oは、転記エラーのリスクを制限するために使用されていません。
SQL_IDは、実際にはSQLステートメントの文字から生成されたハッシュ(MD5)です。
そのため、その大文字小文字と空白が保持されていると仮定すると、同じSQLステートメントは、使用されるすべてのデータベースで同じSQL_IDを持ちます。
Oracleは実行計画も一意の識別子(識別番号)で管理していますが、この識別子のことをPLAN_HASH_VALUEと呼びます。
PLAN_HASH_VALUEは実行計画に依存して作成されます。
以下の特徴があります。
PLAN_HASH_VALUEが同一であれば同一の実行計画とみなせます。
例えば検証環境と本番環境のPLAN_HASH_VALUEが同一であれば、実行計画が同じと言えます。
SQLを実行すると、SQLがHard Parseされて実行計画が共有プールに格納されます。
共有プールに格納された、SQL文と実行計画のセットをカーソルと呼びます。
カーソルはV$SQLやその関連表に格納され、V$SQLの1レコードが1カーソルに対応します。
カーソルはスキーマや実行計画の違いを管理するために使用されます。
このため、ある1つのSQL文(SQL_ID)であっても複数のカーソルが存在する場合があります。
例:同じSQL文(SQL_ID)を別のスキーマで実行した場合、同一のSQL_IDに複数のカーソルが作成されます。
場合によっては同じSQL_IDであっても複数の実行計画ができる場合があります。
V$SQLAREAは、共有SQL領域の統計情報を示し、SQL文字列ごとに1行ずつ表示します。
メモリー内にあり、解析済で、実行準備のできているSQL文に関する統計情報を提供します。
V$SQLは、GROUP BY句のない共有SQL領域についての統計情報を示し、入力された元のSQLテキストの子カーソルごとに1行ずつ表示します。
V$SQLに表示される統計情報は、通常、問合せの実行が終了した時点で更新されます。
ただし、問合せの実行が長期にわたる場合は、5秒ごとに更新されます。
これによって、実行中に、長時間実行されるSQL文の影響を容易に確認できます。
V$SQL_PLANは、ライブラリ・キャッシュにロードされる子カーソルごとの実行計画情報を示します。
V$SQLTEXTは、SGA内の共有SQLカーソルに属するSQL文のテキストを示します。
Expert Oracle SQL
www.amazon.co.jp
Category | Wait Class | Event |
---|---|---|
RAC | Cluster | gc cr/current (multi block) request |
Cluster | gc cr/current grant 2-way | |
Cluster | gc cr/current block 2-way/3-way | |
Cluster | gc buffer busy acquire/release |
RACにはインターコネクトを通したデータのやり取りに関する待機イベントがある。
これらの待機イベントは大きく2種類に分けられる。
- GES(Global Enqueue Service)の待機イベント:インスタンス間の排他制御に関連
- GCS(Global Cache Service)の待機イベント:インスタンス間のバッファキャッシュ一貫性に関連
本記事ではGCSの説明を行う
ブロックを取得する際、ディスクと自ノードのバッファキャッシュ以外に他インスタンスのバッファキャッシュも取得先の選択肢となるため、ブロック取得の手続きがシングルインスタンスより複雑になる
Category | Wait Class | Event |
---|---|---|
I/O | User I/O | db file sequential read |
User I/O | db file scattered read | |
User I/O | direct path read | |
Commit | log file sync | |
System I/O | db file parallel write | |
Memory | Configuration | free buffer waits |
N/W | Network | SQL*Net more data to client |
待機イベントは、プロセスがCPUを使用できず、待機させられるイベントのこと。 待機の要因に基づき細分化されているため、この点を利用してパフォーマンス分析・チューニングの実施が可能
AWR/StatspackのDB CPUと待機イベントの関係性は以下のような流れ
主な待機イベントの関係図
負荷の傾向把握のために参照する指標の関係図は以下
スポンサーリンク