OracleDBAの技術メモ

最近物覚えが悪くなったので仕事中に調べた後々役立つ情報をメモしております。

[PR]

[PR]上記の広告は3ヶ月以上新規記事投稿のないブログに表示されています。新しい記事を書く事で広告が消えます。

実行計画取得

以下のSQL文により実行計画を取得できる。
ここではExcel等へ取り込みやすくするために、カンマ区切りで出力するようにしている。

select
          operation
|| ',' || options
|| ',' || object_node
|| ',' || object_owner
|| ',' || object_name
|| ',' || object_alias
|| ',' || id
|| ',' || parent_id
|| ',' || depth
|| ',' || position
|| ',' || search_columns
|| ',' || cost
|| ',' || cardinality
|| ',' || bytes
|| ',' || other_tag
|| ',' || cpu_cost
|| ',' || io_cost
|| ',' || temp_space
|| ',' || access_predicates
|| ',' || filter_predicates
|| ',' || time
from gv$sql_plan
where sql_id = '～';

これで、SQL*Plus上でAUTOTRACE ONと同等（若干劣る？）の情報量が出力できる。
ただし、少々編集が必要。
AWR SQLレポート等では出力されない抽出条件は
「access_predicates」、「filter_predicates」に格納される。

また、FROM句のテーブルを DBA_HIST_SQL_PLAN にすることにより、
過去の実行計画も参照できる。
ただし、実行計画が変わっている場合は、SQL_IDも変わっている？
確認のために DBA_HIST_SQLTEXT 等を参照して確認した方がよい。
DBA_HIST_SQL_PLAN では「access_predicates」、「filter_predicates」列も存在するが、
内容は格納されない模様。

ORDER BY句はあえて付加していない。
V$SQL_PLAN はメモリ上に常駐しているため、問合せによって負荷をかけることは少ないが、
ORDER BY句を付加すると余計なソート処理が入るので、
問合せ件数によってはレスポンスも遅くなり、サーバに負荷がかかる恐れもある。

USE_NLヒントの使い方まとめ

(1)まずは内部表と外部表について理解しましょう。

    内部表と外部表について
    http://techmemo.tou3.com/Entry/14/

(2)USE_NLヒントが有効にならない状況について理解しましょう。

    内部表の決定（USE_NLヒントが有効にならない原因）
    http://techmemo.tou3.com/Entry/15/

(3)最後にUSE_NLヒントを有効にするためにORDEREDヒントを併用する方法を理解しましょう。

    USE_NLヒントを有効にするために
    http://techmemo.tou3.com/Entry/16/

待機イベント－SQL*Net more data from client

待機イベント　SQL*Net more data from client　について。

某N社のサポートに問い合わせた結果以下のような回答が来た。

==========
該当の待機イベントはクライアント側へデータを送信中の状態で発生致します。
クライアントより、サーバ側へのselectを実施した場合、
まずは、サーバ側で必要なデータを抽出し、その後クライアントにデータを送信し、
その時に発生する待機イベントとなります。

一般的にはネットワーク設定を変更することで
改善する可能性はございます。ORACLE側でチューニングいただける
範囲としてはSDU サイズの設定やTCP 送受信バッファの変更等がございます。
こちらについては以下のKROWNにて説明がございますので
合わせてご確認頂けますと幸いでございます。
　
　KROWN#125105
　Oracle Net パフォーマンスチューニング

しかしながら、該当の待機イベントについてはアイドルイベントとなり、
特にチューニング対象のイベントではございません。
==========

原因はOracleDB側ではなく、接続してきているクライアント側にあるという見解な様子。

CRブロックとは

OracleRACのCache Fusionを調べているとよく出てくるCRブロックについて。

CRブロック
　　↓
Consistent Read Block
　　↓
読み取り一貫性ブロック

多くの場合、データ更新中のブロックに対して別ノードから参照要求があった場合に
一部UNDOのデータ等を使用して作成されるブロック。

CRブロック作成時には必ずログフラッシュ（ログバッファをREDOへ書き出す処理）が発生する。
そのため、このログフラッシュが遅延するとCRブロックの転送も待機する。

待機イベント－gc buffer busy acquire

待機イベント：gc buffer busy acquire とは

バッファの確保解除を待機している状態。
RACの別ノードで確保・保留されているブロックを受け取る場合に多く発生する。

これ以上詳しい情報がないので、「buffer busy waits」のCache Fusion版であると仮定して
「buffer busy waits」の状態を調べた。
「buffer busy waits」は以下の何れかの状態になっているとのこと
　(1)別のセッションがバッファをバッファ・キャッシュに読み取っている
　　　　　（そのため、その読み取りが完了するまで待機する）
　(2)バッファはバッファ・キャッシュにあるが非互換モードになっている
　　　　　（別のセッションがバッファを変更している）

上記が、RAC上の別々のノード間で発生しているということか？

参考：
　　・Oracle Real Application Clusters(Oracle RAC)のキモ～Cache Fusionに注目する～
　　　　http://www.oracle.com/technetwork/jp/articles/yagi-cache-fusion-098964-ja.html

　　・（書籍）ORACLE MASTER Export[RAC]編　株式会社翔泳社刊（通称黒本）