DROP SHADOW CTRL

TEXT DROP SHADOW OFF

GaragebandとiMovieで

検索

検索用語を入力

Web Blog内

検索フォームを送信

プロフィール

Twitter

Tweets by @discus_hamburg

2024年9月
日	月	火	水	木	金	土
1	2	3	4	5	6	7
8	9	10	11	12	13	14
15	16	17	18	19	20	21
22	23	24	25	26	27	28
29	30

最近のトラックバック

[memo]メモを取りつつ楽しめるようなスタイル (wmo6hash::blog)
ダーリンはGoogleで軽食なり。 (今日のゴハン)
�� プログラムは読む時間の方が長い - 遥か彼方の彼方から (�� プログラムは読む時間の方が長い - 遥か彼方の彼方から)
今流行のケブンリッジ関数・・・しってました！？ (あにずむ)
poken (drmarのメモ)
Photo exhibition "Natural Faces of AIDS Orphans"　写真展「エイズ孤児の素顔」@JICA地球ひろば　広尾 (メガ放談)
創る心とおもてなし―第1回 Webエンジニア料理対決に参加する (Kwappa開発室)
創る心とおもてなし～第一回webエンジニア料理対決に参加した (Mac De Oracle)
徹底比較!! PostgreSQL vs MySQLパート2 with 勝手に vs Firebird (14) (キムラデービーブログ)
Oracle de XMLDB #18 (discus)

Oracle

OTN US

Apple

その他

ブログ de ノベルティ
ノベルティグッズをただ、ただ、記録していくブログ。Mac De Oracleでは出来ないネタなので、別ブログを立てた次第。

Googleの広告

RSS

RSSを表示する

当サイトについて

プライバシーポリシー

■プライバシーポリシー

■個人情報の利用目的

　当ブログでは、メールでのお問い合わせ、ブログへのコメントの際、名前（ハンドルネーム）等の個人情報をご登録いただく場合がございます。これらの個人情報は質問に対する回答などでご連絡する場合や、スパムコメント抑止のために利用させていただくものであり、個人情報をご提供いただく際の目的以外では利用いたしません。

■個人情報の第三者への開示

　当サイトでは、個人情報は適切に管理し、以下に該当する場合を除いて第三者に開示することはありません。

本人のご了解がある場合
法令等への協力のため、開示が必要となる場合

個人情報の開示、訂正、追加、削除、利用停止については、ご本人からの個人データの開示、訂正、追加、削除、利用停止のご希望の場合には、ご本人であることを確認させていただいた上で速やかに対応させていただきます。

■アクセス解析ツールについて

　当サイトでは、Googleによるアクセス解析ツール「Googleアナリティクス」を利用しています。このGoogleアナリティクスはトラフィックデータの収集のためにCookieを使用しています。このトラフィックデータは匿名で収集されており、個人を特定するものではありません。この機能はCookieを無効にすることで収集を拒否することが出来ますので、お使いのブラウザの設定をご確認ください。

目的：アクセス数を把握するため
送信先：Google LCC
Googleは受け取った情報をどのように利用するか：Googleの規約に従います
送信される情報：以下４点(R), ユーザー数、セッションの統計情報、おおよその位置情報、ブラウザとデバイスの情報

■広告の配信について

当サイトはGoogleとAmazonの広告を配信しています。

Googleについて

Google及びGoogleのパートナー（第三者配信事業者）の提供する広告を設置しております。その広告配信にはCookieを使用し、当サイトやその他のサイトへの過去のアクセス情報に基づいて広告を配信します。

Google が広告 Cookie を使用することにより、当サイトや他のサイトにアクセスした際の情報に基づいて、Google やそのパートナーが適切な広告を表示しています。

お客様はGoogleアカウントの広告設定ページ（https://adssettings.google.com/u/0/authenticated）で、パーソナライズ広告を無効にできます。また aboutads.info のページにアクセスして頂き、パーソナライズ広告掲載に使用される第三者配信事業者のCookieを無効にできます。

その他、Googleの広告におけるCookieの取り扱い詳細については、Googleのポリシーと規約ページ（https://policies.google.com/technologies/ads）をご覧ください。

Amazonについて

AmazonはアソシエイトリンクのURLに含まれるパラメータを通じて利用者が直前に閲覧したアソシエイトサイトに関する情報などを収集し、これをアソシエイトパートナーに対する紹介料の算定、報告及び支払いに使用したり、アソシエイトパートナーによる複数のウェブサイトや商品戦略毎のパフォーマンスの分析に供したりしています。

アソシエイトパートナーの利用目的：閲覧の傾向や履歴の分析のため広告効果の分析のため
外部送信プログラム名：Amazonアソシエイトプログラム
送信先の会社名：アマゾンジャパン合同会社
送信する情報の内容：閲覧した内容についての情報送信先の利用目的：自社の広告宣伝を目的とした広告情報の掲載のため、ウェブサイトやアプリの監視のため

Amazonによる個人に関する情報の取得及び取扱いに関する方針につきましてはAmazon.co.jpプライバシー規約をご覧ください。

■免責事項

　当サイトからリンクやバナーなどによって他のサイトに移動された場合、移動先サイトで提供される情報、サービス等について一切の責任を負いません。当サイトのコンテンツ・情報につきまして、可能な限り正確な情報を掲載するよう努めておりますが、誤情報が入り込んだり、情報が古くなっていることもございます。当サイトに掲載された内容によって生じた損害等の一切の責任を負いかねますのでご了承ください。

■プライバシーポリシーの変更について

　当サイトは、個人情報に関して適用される日本の法令を遵守するとともに、本ポリシーの内容を適宜見直しその改善に努めます。
修正された最新のプライバシーポリシーは常に本ページにて開示されます。

2023年1月16日 (月)

実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 / No.61 / ANSI JOINのおまけのおまけ

年を跨いで, ”実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 / No.61 / ANSI JOINのおまけ”のおまけです.

前回の投稿から間隔が空いていたので, まずは, 簡単な復習から.

ANSI構文のON句の結合条件でORが利用されているという, スーパータイプ, サブタイプテーブルの実装崩れというか, 大人の事情に押し切られて負けた感じありありの半端な状態.
あ, そうだ, Oralceの外部結合だとOR使えないけど, ANSIなら使えるじゃん！
という流れを感じるSQL文を, Oracleのオプティマイザは, LATERALへの書き換え(VW_LAT_E87C3AAF)や, OR EXPANDの書き換え(VW_ORE_FDF394AE)を駆使して, 物凄い最適化を行っていました.

この例では, 外部表, 内部表の多重度は, 1:0..1. かつ, スーパータイプ, サブタイプでいうところの不完全なサブタイプ.
さらに, 内部表は, 単純にニコイチにしただけのようなサブタイプテーブルで外部表との結合列が2列（おそらく本来同一列に統合されていただろう. . と思われる）ある. 惜しい！という感じのモデル.
比較的軽度のモデリング障害ではあるので, このまま使うのであれば, LATERAL変換されるのを避けるような書き換え, 比較的単純な HASH JOIN なるようにすればそこそこ改善できそうな感じはしますよね（いわゆるTemp落ちはある程度発生する前提で）

なお, この例で AUTO TRACEでの実行時間と, SQL MONITORの実行時間（DB内部）に差異があることに気づいた方もいると思いますが. これ, クライアントがデータをFETCHしている時間ですね. 行数が多いので. SQL*Plusの場合, デフォルトのFETCH SIZEが15なので行数が多いと, FETCHの際, サーバーからの受信で時間がかかります.
（この症状は以前, 高フェッチ圧症として紹介したこともあるので, 覚えている方も多いのではないかと思います. この例では1行の行サイズも大きめかつ, 行数も多めにして SELECT * にしているのでそこそこ目立つ時間になるようにしています. これも別のエントリーでネタにするための仕込みではあるのですが, 今回の記事では気にしないでください. SQLモニターのサーバー内部での純粋な処理時間だけで, 書き換え前後での差を見て行きます！）

SCOTT@orclpdb1> @dayx
  1  SELECT *
  2  FROM
  3    supertype st
  4    LEFT OUTER JOIN nikoichi_mitaina_subtype nmst
  5    ON
  6      st.pkey = nmst.col1
  7*     OR st.pkey = nmst.col2

10001行が選択されました. 

経過: 00:00:01.41

実行計画
----------------------------------------------------------
Plan hash value: 2133431102

-------------------------------------------------------------------------------------------------------------
| Id  | Operation                        | Name                     | Rows  | Bytes | Cost (%CPU)| Time     |
-------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                 |                          | 20002 |    20M| 40226   (1)| 00:00:02 |
|   1 |  MERGE JOIN OUTER                |                          | 20002 |    20M| 40226   (1)| 00:00:02 |
|   2 |   TABLE ACCESS FULL              | SUPERTYPE                | 10001 |  4971K|   204   (0)| 00:00:01 |
|   3 |   BUFFER SORT                    |                          |     2 |  1082 | 40021   (1)| 00:00:02 |
|   4 |    VIEW                          | VW_LAT_E87C3AAF          |     2 |  1082 |     4   (0)| 00:00:01 |
|   5 |     VIEW                         | VW_ORE_FDF394AE          |     2 |  1082 |     4   (0)| 00:00:01 |
|   6 |      UNION-ALL                   |                          |       |       |            |          |
|   7 |       TABLE ACCESS BY INDEX ROWID| NIKOICHI_MITAINA_SUBTYPE |     1 |  1009 |     2   (0)| 00:00:01 |
|*  8 |        INDEX UNIQUE SCAN         | UK1                      |     1 |       |     1   (0)| 00:00:01 |
|*  9 |       TABLE ACCESS BY INDEX ROWID| NIKOICHI_MITAINA_SUBTYPE |     1 |  1009 |     2   (0)| 00:00:01 |
|* 10 |        INDEX UNIQUE SCAN         | UK2                      |     1 |       |     1   (0)| 00:00:01 |
-------------------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   8 - access("ST"."PKEY"="NMST"."COL1")
       filter("NMST"."COL1" IS NOT NULL)
   9 - filter(LNNVL("ST"."PKEY"="NMST"."COL1"))
  10 - access("ST"."PKEY"="NMST"."COL2")
       filter("NMST"."COL2" IS NOT NULL)

統計
----------------------------------------------------------
          0  recursive calls
          0  db block gets
      32231  consistent gets
          0  physical reads
          0  redo size
   15493776  bytes sent via SQL*Net to client　(別エントリ向け)
       7378  bytes received via SQL*Net from client
        668  SQL*Net roundtrips to/from client (別エントリ向け)
      10001  sorts (memory)
          0  sorts (disk)
      10001  rows processed


  1  SELECT /*+ MONITOR */ *
  2  FROM
  3    supertype st
  4    LEFT OUTER JOIN nikoichi_mitaina_subtype nmst
  5    ON
  6      st.pkey = nmst.col1
  7*     OR st.pkey = nmst.col2

DBMS_SQLTUNE.REPORT_SQL_MONITOR(SQL_ID=>NULL,TYPE=>'TEXT')
--------------------------------------------------------------------------------------------------------------------------------------
SQL Monitoring Report

SQL Text
------------------------------
SELECT /*+ MONITOR */ * FROM supertype st LEFT OUTER JOIN nikoichi_mitaina_subtype nmst ON st.pkey = nmst.col1 OR st.pkey = nmst.col2

Global Information
------------------------------
 Status              :  DONE (ALL ROWS)

 ...略...

 Duration            :  3s（別ネタ向け仕込み）

 ...略...

Global Stats
=================================================
| Elapsed |   Cpu   |  Other   | Fetch | Buffer |
| Time(s) | Time(s) | Waits(s) | Calls |  Gets  |
=================================================
|    0.37 |    0.31 |     0.06 |   668 |  32231 |
=================================================

SQL Plan Monitoring Details (Plan Hash Value=2133431102)
=====================================================================================================================================================================
| Id |             Operation              |           Name           |  Rows   | Cost  |   Time    | Start  | Execs |   Rows   |  Mem  | Activity | Activity Detail |
|    |                                    |                          | (Estim) |       | Active(s) | Active |       | (Actual) | (Max) |   (%)    |   (# samples)   |
=====================================================================================================================================================================
|  0 | SELECT STATEMENT                   |                          |         |       |         4 |     +0 |     1 |    10001 |     . |          |                 |
|  1 |   MERGE JOIN OUTER                 |                          |   20002 | 40226 |         4 |     +0 |     1 |    10001 |     . |          |                 |
|  2 |    TABLE ACCESS FULL               | SUPERTYPE                |   10001 |   204 |         4 |     +0 |     1 |    10001 |     . |          |                 |
|  3 |    BUFFER SORT                     |                          |       2 | 40021 |         4 |     +0 | 10001 |    10000 |  2048 |          |                 |
|  4 |     VIEW                           | VW_LAT_E87C3AAF          |       2 |     4 |         4 |     +0 | 10001 |    10000 |     . |          |                 |
|  5 |      VIEW                          | VW_ORE_FDF394AE          |       2 |     4 |         4 |     +0 | 10001 |    10000 |     . |          |                 |
|  6 |       UNION-ALL                    |                          |         |       |         4 |     +0 | 10001 |    10000 |     . |          |                 |
|  7 |        TABLE ACCESS BY INDEX ROWID | NIKOICHI_MITAINA_SUBTYPE |       1 |     2 |         4 |     +0 | 10001 |     5000 |     . |          |                 |
|  8 |         INDEX UNIQUE SCAN          | UK1                      |       1 |     1 |         4 |     +0 | 10001 |     5000 |     . |          |                 |
|  9 |        TABLE ACCESS BY INDEX ROWID | NIKOICHI_MITAINA_SUBTYPE |       1 |     2 |         4 |     +0 | 10001 |     5000 |     . |          |                 |
| 10 |         INDEX UNIQUE SCAN          | UK2                      |       1 |     1 |         4 |     +0 | 10001 |     5000 |     . |          |                 |
=====================================================================================================================================================================

では, 書き換えて, LATERAL変換を避け, HASH JOINになるようにしてみましょう. (WITH句を利用していますが, 再利用ではなく読みやすさ狙いです. Oracleもそれを理解できるのでインラインビューとして扱われます)
今回のようなデータモデル障害の場合は, 治療もシンプルで良いのですがw（例に取り上げるのがメンドクサイやつだと, 解説するのもメンドクサイし良いことないので）

現場どのようになっているかを理解する必要があります. この例では, col1列とcol2列は実は同一列で良いだろうということになるので, 以下のように書き換えれば, JOIN ON ... OR　なんて現時点のオプティマイザでは, ほぼ危険な感じしかしない実行計画になるようなSQLへの書き換えも回避できるのではないでしょうか？
結果は見ての通り, 別エントリ向けの仕込みであるFETCH時間を除いたデータベース内部のみの処理時間は, 0.37sec から 0.15secと62%ほど改善しています（ただ, このデータ量で私の環境だとPGA内に収まっているのでTemp落ちの影響は見えないですね. オンメモリなら勝ちは確実ですが）

  1  WITH
  2  t1 AS
  3  (
  4    SELECT
  5      pkey
  6      , CASE
  7          WHEN col2 IS NULL
  8            THEN col1
  9            ELSE col2
 10      END AS join_key
 11      ,description
 12    FROM
 13      nikoichi_mitaina_subtype
 14    WHERE
 15      col1 IS NOT NULL
 16      OR col2 IS NOT NULL
 17  )
 18  SELECT *
 19  FROM
 20    supertype st
 21    LEFT OUTER JOIN t1
 22    ON
 23*     st.pkey = t1.join_key

10001行が選択されました. 

経過: 00:00:01.28

実行計画
----------------------------------------------------------
Plan hash value: 2223315184

-------------------------------------------------------------------------------------------------------
| Id  | Operation          | Name                     | Rows  | Bytes |TempSpc| Cost (%CPU)| Time     |
-------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT   |                          | 10001 |    14M|       |  1224   (1)| 00:00:01 |
|*  1 |  HASH JOIN OUTER   |                          | 10001 |    14M|  5096K|  1224   (1)| 00:00:01 |
|   2 |   TABLE ACCESS FULL| SUPERTYPE                | 10001 |  4971K|       |   204   (0)| 00:00:01 |
|*  3 |   TABLE ACCESS FULL| NIKOICHI_MITAINA_SUBTYPE |  7500 |  7390K|       |   410   (1)| 00:00:01 |
-------------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   1 - access("ST"."PKEY"=CASE  WHEN (ROWID(+) IS NOT NULL) THEN CASE  WHEN ("COL2"(+) IS
              NULL) THEN "COL1"(+) ELSE "COL2"(+) END  ELSE NULL END )
   3 - filter("COL1"(+) IS NOT NULL OR "COL2"(+) IS NOT NULL)

統計
----------------------------------------------------------
          0  recursive calls
          0  db block gets
       2748  consistent gets
          0  physical reads
          0  redo size
   15483707  bytes sent via SQL*Net to client（別ネタ向け仕込み）
       7378  bytes received via SQL*Net from client
        668  SQL*Net roundtrips to/from client（別ネタ向け仕込み）
          0  sorts (memory)
          0  sorts (disk)
      10001  rows processed


  1  WITH
  2  t1 AS
  3  (
  4    SELECT
  5      pkey
  6      , CASE
  7          WHEN col2 IS NULL
  8            THEN col1
  9            ELSE col2
 10      END AS join_key
 11      ,description
 12    FROM
 13      nikoichi_mitaina_subtype
 14    WHERE
 15      col1 IS NOT NULL
 16      OR col2 IS NOT NULL
 17  )
 18  SELECT /*+ MONITOR */ *
 19  FROM
 20    supertype st
 21    LEFT OUTER JOIN t1
 22    ON
 23*     st.pkey = t1.join_key

DBMS_SQLTUNE.REPORT_SQL_MONITOR(SQL_ID=>NULL,TYPE=>'TEXT')
----------------------------------------------------------------------------------------------------------------
SQL Monitoring Report

SQL Text
------------------------------
WITH t1 AS ( SELECT pkey , CASE WHEN col2 IS NULL THEN col1 ELSE col2 END AS join_key ,description
FROM nikoichi_mitaina_subtype WHERE col1 IS NOT NULL OR col2 IS NOT NULL ) SELECT /*+ MONITOR */ *
FROM supertype st LEFT OUTER JOIN t1 ON st.pkey = t1.join_key

Global Information
------------------------------
 Status              :  DONE (ALL ROWS)

 ...略...

 Duration            :  2s（別ネタ向け仕込み）

 ...略...

Global Stats
=================================================
| Elapsed |   Cpu   |  Other   | Fetch | Buffer |
| Time(s) | Time(s) | Waits(s) | Calls |  Gets  |
=================================================
|    0.15 |    0.13 |     0.02 |   668 |   2748 |
=================================================

SQL Plan Monitoring Details (Plan Hash Value=2223315184)
======================================================================================================================================================
| Id |      Operation       |           Name           |  Rows   | Cost |   Time    | Start  | Execs |   Rows   |  Mem  | Activity | Activity Detail |
|    |                      |                          | (Estim) |      | Active(s) | Active |       | (Actual) | (Max) |   (%)    |   (# samples)   |
======================================================================================================================================================
|  0 | SELECT STATEMENT     |                          |         |      |         3 |     +0 |     1 |    10001 |     . |          |                 |
|  1 |   HASH JOIN OUTER    |                          |   10001 | 1224 |         3 |     +0 |     1 |    10001 |   7MB |          |                 |
|  2 |    TABLE ACCESS FULL | SUPERTYPE                |   10001 |  204 |         1 |     +0 |     1 |    10001 |     . |          |                 |
|  3 |    TABLE ACCESS FULL | NIKOICHI_MITAINA_SUBTYPE |    7500 |  410 |         3 |     +0 |     1 |    10000 |     . |          |                 |
======================================================================================================================================================

将来のデータ量が100倍だとして. . . . HASH JOIN化してTemp落ちの影響も含めて見ておきましょう

SCOTT@orclpdb1> @dayx-1
  1* DROP TABLE supertype

表が削除されました. 

経過: 00:00:00.47
  1  CREATE TABLE supertype
  2  (
  3    pkey NUMBER PRIMARY KEY
  4    , attr1 NUMBER NOT NULL
  5    , attr2 NUMBER NOT NULL
  6    , note VARCHAR2(500)
  7* )

表が作成されました. 

経過: 00:00:00.15
  1* DROP TABLE nikoichi_mitaina_subtype

表が削除されました. 

経過: 00:00:00.05
  1  CREATE TABLE nikoichi_mitaina_subtype
  2  (
  3    pkey NUMBER PRIMARY KEY
  4    , col1 NUMBER
  5    , col2 NUMBER
  6    , description VARCHAR2(1000)
  7    , CONSTRAINT uk1 unique (col1) USING INDEX
  8    , CONSTRAINT uk2 unique (col2) USING INDEX
  9* )

表が作成されました. 

経過: 00:00:00.03
  1  DECLARE
  2    cMAX_ROWS CONSTANT NUMBER := 1000000;
  3  BEGIN
  4    FOR i IN 1..cMAX_ROWS LOOP
  5      INSERT INTO supertype VALUES(i,0,0,LPAD(i,500,'*'));
  6      INSERT INTO nikoichi_mitaina_subtype VALUES(
  7        i
  8        , CASE WHEN MOD(i,2) = 0 THEN i ELSE null END
  9        , CASE WHEN MOD(i,2) = 1 THEN i ELSE null END
 10        , LPAD(i,1000,'*')
 11      );
 12      IF MOD(i,100) = 0 THEN COMMIT; END IF;
 13    END LOOP;
 14    INSERT INTO supertype VALUES(cMAX_ROWS+1,0,0,null);
 15    COMMIT;
 16    DBMS_STATS.GATHER_TABLE_STATS(ownname=>'SCOTT',tabname=>'SUPERTYPE',no_invalidate=>false,cascade=>true);
 17    DBMS_STATS.GATHER_TABLE_STATS(ownname=>'SCOTT',tabname=>'NIKOICHI_MITAINA_SUBTYPE',no_invalidate=>false,cascade=>true);
 18* END;

PL/SQLプロシージャが正常に完了しました. 

経過: 00:04:37.66

まず元ネタのLATERALとOR EXPAND書き換えされている方はどうか. . SQLモニターのExecが綺麗に増加（当然ですが）

SCOTT@orclpdb1> @dayx
  1  SELECT *
  2  FROM
  3    supertype st
  4    LEFT OUTER JOIN nikoichi_mitaina_subtype nmst
  5    ON
  6      st.pkey = nmst.col1
  7*     OR st.pkey = nmst.col2

1000001行が選択されました. 

経過: 00:02:23.03

実行計画
----------------------------------------------------------
Plan hash value: 2133431102

-------------------------------------------------------------------------------------------------------------
| Id  | Operation                        | Name                     | Rows  | Bytes | Cost (%CPU)| Time     |
-------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                 |                          |  2000K|  2004M|  6022K  (1)| 00:03:56 |
|   1 |  MERGE JOIN OUTER                |                          |  2000K|  2004M|  6022K  (1)| 00:03:56 |
|   2 |   TABLE ACCESS FULL              | SUPERTYPE                |  1000K|   486M| 19524   (1)| 00:00:01 |
|   3 |   BUFFER SORT                    |                          |     2 |  1082 |  6002K  (1)| 00:03:55 |
|   4 |    VIEW                          | VW_LAT_E87C3AAF          |     2 |  1082 |     6   (0)| 00:00:01 |
|   5 |     VIEW                         | VW_ORE_FDF394AE          |     2 |  1082 |     6   (0)| 00:00:01 |
|   6 |      UNION-ALL                   |                          |       |       |            |          |
|   7 |       TABLE ACCESS BY INDEX ROWID| NIKOICHI_MITAINA_SUBTYPE |     1 |  1012 |     3   (0)| 00:00:01 |
|*  8 |        INDEX UNIQUE SCAN         | UK1                      |     1 |       |     2   (0)| 00:00:01 |
|*  9 |       TABLE ACCESS BY INDEX ROWID| NIKOICHI_MITAINA_SUBTYPE |     1 |  1012 |     3   (0)| 00:00:01 |
|* 10 |        INDEX UNIQUE SCAN         | UK2                      |     1 |       |     2   (0)| 00:00:01 |
-------------------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   8 - access("ST"."PKEY"="NMST"."COL1")
       filter("NMST"."COL1" IS NOT NULL)
   9 - filter(LNNVL("ST"."PKEY"="NMST"."COL1"))
  10 - access("ST"."PKEY"="NMST"."COL2")
       filter("NMST"."COL2" IS NOT NULL)

統計
----------------------------------------------------------
          0  recursive calls
          0  db block gets
    3561836  consistent gets
      71485  physical reads
          0  redo size
 1552273780  bytes sent via SQL*Net to client（別ネタ向け仕込み）
     734925  bytes received via SQL*Net from client
      66668  SQL*Net roundtrips to/from client（別ネタ向け仕込み）
    1000001  sorts (memory)
          0  sorts (disk)
    1000001  rows processed


  1  SELECT /*+ MONITOR */ *
  2  FROM
  3    supertype st
  4    LEFT OUTER JOIN nikoichi_mitaina_subtype nmst
  5    ON
  6      st.pkey = nmst.col1
  7*     OR st.pkey = nmst.col2

DBMS_SQLTUNE.REPORT_SQL_MONITOR(SQL_ID=>NULL,TYPE=>'TEXT')
-----------------------------------------------------------------------------------------
SQL Monitoring Report

SQL Text
------------------------------
SELECT /*+ MONITOR */ * FROM supertype st LEFT OUTER JOIN nikoichi_mitaina_subtype nmst
ON st.pkey = nmst.col1 OR st.pkey = nmst.col2

Global Information
------------------------------
 Status              :  DONE (ALL ROWS)

 ...略...

 Duration            :  219s（別ネタ向け仕込み）

 ...略...

Global Stats
===========================================================================
| Elapsed |   Cpu   |    IO    |  Other   | Fetch | Buffer | Read | Read  |
| Time(s) | Time(s) | Waits(s) | Waits(s) | Calls |  Gets  | Reqs | Bytes |
===========================================================================
|      37 |      32 |     0.22 |     4.20 | 66668 |     4M |  573 | 558MB |
===========================================================================

SQL Plan Monitoring Details (Plan Hash Value=2133431102)
====================================================================================================================================================================================
| Id |             Operation              |           Name           |  Rows   | Cost  |   Time    | Start  | Execs |   Rows   | Read | Read  |  Mem  | Activity | Activity Detail |
|    |                                    |                          | (Estim) |       | Active(s) | Active |       | (Actual) | Reqs | Bytes | (Max) |   (%)    |   (# samples)   |
====================================================================================================================================================================================
|  0 | SELECT STATEMENT                   |                          |         |       |       220 |     +0 |     1 |       1M |      |       |     . |          |                 |
|  1 |   MERGE JOIN OUTER                 |                          |      2M |    6M |       220 |     +0 |     1 |       1M |      |       |     . |     6.90 | Cpu (2)         |
|  2 |    TABLE ACCESS FULL               | SUPERTYPE                |      1M | 19524 |       220 |     +0 |     1 |       1M |  573 | 558MB |     . |    10.34 | Cpu (3)         |
|  3 |    BUFFER SORT                     |                          |       2 |    6M |       220 |     +0 |    1M |       1M |      |       |  2048 |    17.24 | Cpu (5)         |
|  4 |     VIEW                           | VW_LAT_E87C3AAF          |       2 |     6 |       220 |     +0 |    1M |       1M |      |       |     . |          |                 |
|  5 |      VIEW                          | VW_ORE_FDF394AE          |       2 |     6 |       220 |     +0 |    1M |       1M |      |       |     . |          |                 |
|  6 |       UNION-ALL                    |                          |         |       |       220 |     +0 |    1M |       1M |      |       |     . |     6.90 | Cpu (2)         |
|  7 |        TABLE ACCESS BY INDEX ROWID | NIKOICHI_MITAINA_SUBTYPE |       1 |     3 |       220 |     +0 |    1M |     500K |      |       |     . |          |                 |
|  8 |         INDEX UNIQUE SCAN          | UK1                      |       1 |     2 |       220 |     +0 |    1M |     500K |      |       |     . |    17.24 | Cpu (5)         |
|  9 |        TABLE ACCESS BY INDEX ROWID | NIKOICHI_MITAINA_SUBTYPE |       1 |     3 |       220 |     +0 |    1M |     500K |      |       |     . |          |                 |
| 10 |         INDEX UNIQUE SCAN          | UK2                      |       1 |     2 |       220 |     +0 |    1M |     500K |      |       |     . |     6.90 | Cpu (2)         |
====================================================================================================================================================================================

LATERAL変換を避け, HASH JOINにしてくれるような書き換えを行った方はどうかというと.
やはり, PGA内に収まっていたHASH JOINと比較して, Temp落ち（1GBほど）の影響で改善幅は減っていますが, 37sec が 32secと, 15%程度は勝っていますね. Temp落ちは避けられないですからね.

であれば, Temp落ちの落ちている先を速くすれば良いではないか. . . ということで, メモリにさえ余裕があれば, 使いすぎないようにした上で, tmpfs を使ってみましょうか. （一時表領域はなければOracleが再作成してくれるので）

  1  WITH
  2  t1 AS
  3  (
  4    SELECT
  5      pkey
  6      , CASE
  7          WHEN col2 IS NULL
  8            THEN col1
  9            ELSE col2
 10      END AS join_key
 11      ,description
 12    FROM
 13      nikoichi_mitaina_subtype
 14    WHERE
 15      col1 IS NOT NULL
 16      OR col2 IS NOT NULL
 17  )
 18  SELECT *
 19  FROM
 20    supertype st
 21    LEFT OUTER JOIN t1
 22    ON
 23*     st.pkey = t1.join_key

1000001行が選択されました. 

経過: 00:02:24.20

実行計画
----------------------------------------------------------
Plan hash value: 2223315184

-------------------------------------------------------------------------------------------------------
| Id  | Operation          | Name                     | Rows  | Bytes |TempSpc| Cost (%CPU)| Time     |
-------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT   |                          |  1000K|  1451M|       |   120K  (1)| 00:00:05 |
|*  1 |  HASH JOIN OUTER   |                          |  1000K|  1451M|   497M|   120K  (1)| 00:00:05 |
|   2 |   TABLE ACCESS FULL| SUPERTYPE                |  1000K|   486M|       | 19524   (1)| 00:00:01 |
|*  3 |   TABLE ACCESS FULL| NIKOICHI_MITAINA_SUBTYPE |   750K|   723M|       | 39559   (1)| 00:00:02 |
-------------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   1 - access("ST"."PKEY"=CASE  WHEN (ROWID(+) IS NOT NULL) THEN CASE  WHEN ("COL2"(+) IS
              NULL) THEN "COL1"(+) ELSE "COL2"(+) END  ELSE NULL END )
   3 - filter("COL1"(+) IS NOT NULL OR "COL2"(+) IS NOT NULL)

統計
----------------------------------------------------------
       1297  recursive calls
          0  db block gets
     229696  consistent gets
     374740  physical reads
          0  redo size
 1551273711  bytes sent via SQL*Net to client（別ネタ向け仕込み）
     734925  bytes received via SQL*Net from client
      66668  SQL*Net roundtrips to/from client（別ネタ向け仕込み）
          0  sorts (memory)
          0  sorts (disk)
    1000001  rows processed


  1  WITH
  2  t1 AS
  3  (
  4    SELECT
  5      pkey
  6      , CASE
  7          WHEN col2 IS NULL
  8            THEN col1
  9            ELSE col2
 10      END AS join_key
 11      ,description
 12    FROM
 13      nikoichi_mitaina_subtype
 14    WHERE
 15      col1 IS NOT NULL
 16      OR col2 IS NOT NULL
 17  )
 18  SELECT /*+ MONITOR */ *
 19  FROM
 20    supertype st
 21    LEFT OUTER JOIN t1
 22    ON
 23*     st.pkey = t1.join_key

DBMS_SQLTUNE.REPORT_SQL_MONITOR(SQL_ID=>NULL,TYPE=>'TEXT')
----------------------------------------------------------------------------------------------
SQL Monitoring Report

SQL Text
------------------------------
WITH t1 AS ( SELECT pkey , CASE WHEN col2 IS NULL THEN col1 ELSE col2 END AS join_key
,description FROM nikoichi_mitaina_subtype WHERE col1 IS NOT NULL OR col2 IS NOT NULL )
SELECT /*+ MONITOR */ * FROM supertype st LEFT OUTER JOIN t1 ON st.pkey = t1.join_key

Global Information
------------------------------
 Status              :  DONE (ALL ROWS)

 ...略...

 Duration            :  223s

 ...略...

Global Stats
================================================================================
| Elapsed |   Cpu   |    IO    | Fetch | Buffer | Read | Read  | Write | Write |
| Time(s) | Time(s) | Waits(s) | Calls |  Gets  | Reqs | Bytes | Reqs  | Bytes |
================================================================================
|      32 |      17 |       15 | 66668 |   230K | 6887 |   3GB |  5169 |   1GB |
================================================================================

SQL Plan Monitoring Details (Plan Hash Value=2223315184)
==============================================================================================================================================================================================================
| Id |      Operation       |           Name           |  Rows   | Cost  |   Time    | Start  | Execs |   Rows   | Read | Read  | Write | Write |  Mem  | Temp  | Activity |         Activity Detail         |
|    |                      |                          | (Estim) |       | Active(s) | Active |       | (Actual) | Reqs | Bytes | Reqs  | Bytes | (Max) | (Max) |   (%)    |           (# samples)           |
==============================================================================================================================================================================================================
|  0 | SELECT STATEMENT     |                          |         |       |       222 |     +2 |     1 |       1M |      |       |       |       |     . |     . |          |                                 |
|  1 |   HASH JOIN OUTER    |                          |      1M |  120K |       223 |     +1 |     1 |       1M | 5169 |   1GB |  5169 |   1GB | 184MB |   1GB |    90.62 | Cpu (9)                         |
|    |                      |                          |         |       |           |        |       |          |      |       |       |       |       |       |          | SQL*Net more data to client (7) |
|    |                      |                          |         |       |           |        |       |          |      |       |       |       |       |       |          | direct path write temp (13)     |
|  3 |    TABLE ACCESS FULL | NIKOICHI_MITAINA_SUBTYPE |    750K | 39559 |        67 |     +7 |     1 |       1M | 1145 |   1GB |       |       |     . |     . |     6.25 | Cpu (2)                         |
==============================================================================================================================================================================================================

ということで, メモリに余裕があるので　tmpfsを使って遊んでみましょう. 2GB固定サイズの一時表領域を作成して, SCOTTユーザーのデフォルト一時表領域にしました

[master@localhost ~]$ df -TH
ファイルシス        タイプ   サイズ  使用  残り 使用% マウント位置
tmpfs               tmpfs      9.3G   17k  9.3G    1% /dev/shm
tmpfs               tmpfs      9.3G  9.7M  9.3G    1% /run
tmpfs               tmpfs      9.3G     0  9.3G    0% /sys/fs/cgroup
/dev/mapper/ol-root xfs         48G   44G  4.3G   92% /
/dev/mapper/ol-work xfs         11G  109M   11G    2% /work

...略...

[master@localhost ~]$ sudo mkdir /oratemp
...略...
[master@localhost ~]$ ls -l / | grep oratemp
drwxrwxrwt.   2 root     root       60  1月 14 12:03 oratemp
[master@localhost ~]$ sudo mount -t tmpfs tmpfs /oratemp
[sudo] master のパスワード:
[master@localhost ~]$ df -TH
ファイルシス        タイプ   サイズ  使用  残り 使用% マウント位置
devtmpfs            devtmpfs   9.3G     0  9.3G    0% /dev
tmpfs               tmpfs      9.3G   17k  9.3G    1% /dev/shm
tmpfs               tmpfs      9.3G  9.7M  9.3G    1% /run
tmpfs               tmpfs      9.3G     0  9.3G    0% /sys/fs/cgroup
/dev/mapper/ol-root xfs         48G   44G  4.3G   92% /
/dev/mapper/ol-work xfs         11G  109M   11G    2% /work

...略...

tmpfs               tmpfs      9.3G     0  9.3G    0% /oratemp

一時表領域を作成して, scottのデフォルト一時表領域にする

...略...
SYS@orclpdb1> create temporary tablespace hogetemp tempfile '/oratemp/hogetmp.dbf' size 2g;

表領域が作成されました. 

SYS@orclpdb1> alter user scott temporary tablespace hogetemp;

ユーザーが変更されました.

では, オリジナルから. こちらそもそもTemp落ちしないので, LATERALビューへのアクセス回数が積み上がるだけなので, 該当表の物理読み込みが影響しなければほぼCPUタイムですね

SCOTT@orclpdb1> @dayx
  1  SELECT /*+ MONITOR */ *
  2  FROM
  3    supertype st
  4    LEFT OUTER JOIN nikoichi_mitaina_subtype nmst
  5    ON
  6      st.pkey = nmst.col1
  7*     OR st.pkey = nmst.col2

DBMS_SQLTUNE.REPORT_SQL_MONITOR(SQL_ID=>NULL,TYPE=>'TEXT')
------------------------------------------------------------------------------------------
SQL Monitoring Report

SQL Text
------------------------------
SELECT /*+ MONITOR */ * FROM supertype st LEFT OUTER JOIN nikoichi_mitaina_subtype nmst
ON st.pkey = nmst.col1 OR st.pkey = nmst.col2

Global Information
------------------------------
 Status              :  DONE (ALL ROWS)

...略...

 Duration            :  188s（別ネタ向け仕込み）

...略...

Global Stats
===========================================================================
| Elapsed |   Cpu   |    IO    |  Other   | Fetch | Buffer | Read | Read  |
| Time(s) | Time(s) | Waits(s) | Waits(s) | Calls |  Gets  | Reqs | Bytes |
===========================================================================
|      39 |      34 |     0.21 |     4.62 | 66668 |     4M |  575 | 559MB |
===========================================================================

SQL Plan Monitoring Details (Plan Hash Value=2133431102)
=========================================================================================================================================================================================
| Id |             Operation              |           Name           |  Rows   | Cost  |   Time    | Start  | Execs |   Rows   | Read | Read  |  Mem  | Activity |   Activity Detail    |
|    |                                    |                          | (Estim) |       | Active(s) | Active |       | (Actual) | Reqs | Bytes | (Max) |   (%)    |     (# samples)      |
=========================================================================================================================================================================================
|  0 | SELECT STATEMENT                   |                          |         |       |       189 |     +0 |     1 |       1M |      |       |     . |          |                      |
|  1 |   MERGE JOIN OUTER                 |                          |      2M |    6M |       189 |     +0 |     1 |       1M |      |       |     . |     2.78 | Cpu (1)              |
|  2 |    TABLE ACCESS FULL               | SUPERTYPE                |      1M | 19593 |       189 |     +0 |     1 |       1M |  575 | 559MB |     . |    13.89 | Cpu (4)              |
|    |                                    |                          |         |       |           |        |       |          |      |       |       |          | direct path read (1) |
|  3 |    BUFFER SORT                     |                          |       2 |    6M |       189 |     +0 |    1M |       1M |      |       |  2048 |    22.22 | Cpu (8)              |
|  4 |     VIEW                           | VW_LAT_E87C3AAF          |       2 |     6 |       189 |     +0 |    1M |       1M |      |       |     . |          |                      |
|  5 |      VIEW                          | VW_ORE_FDF394AE          |       2 |     6 |       189 |     +0 |    1M |       1M |      |       |     . |          |                      |
|  6 |       UNION-ALL                    |                          |         |       |       189 |     +0 |    1M |       1M |      |       |     . |     2.78 | Cpu (1)              |
|  7 |        TABLE ACCESS BY INDEX ROWID | NIKOICHI_MITAINA_SUBTYPE |       1 |     3 |       189 |     +0 |    1M |     500K |      |       |     . |     8.33 | Cpu (3)              |
|  8 |         INDEX UNIQUE SCAN          | UK1                      |       1 |     2 |       189 |     +0 |    1M |     500K |      |       |     . |     5.56 | Cpu (2)              |
|  9 |        TABLE ACCESS BY INDEX ROWID | NIKOICHI_MITAINA_SUBTYPE |       1 |     3 |       189 |     +0 |    1M |     500K |      |       |     . |     8.33 | Cpu (3)              |
| 10 |         INDEX UNIQUE SCAN          | UK2                      |       1 |     2 |       189 |     +0 |    1M |     500K |      |       |     . |    13.89 | Cpu (5)              |
=========================================================================================================================================================================================

では, HASH JOINになるように書き換えた方のTemp落ちの時間は...想定通り短縮していますね. 15secほどあったIO Waits(s)ものが1/15程度まで減っています.
結果的に, 39sec -> 21secとなりました. Temp落ちする前提だから落ちた先のIOレイテンシーが小さければこうなるわけですけども. 逆に落ちた先のIOレイテンシーが大きければ影響も大きくなりますよね.

  1  WITH
  2  t1 AS
  3  (
  4    SELECT
  5      pkey
  6      , CASE
  7          WHEN col2 IS NULL
  8            THEN col1
  9            ELSE col2
 10      END AS join_key
 11      ,description
 12    FROM
 13      nikoichi_mitaina_subtype
 14    WHERE
 15      col1 IS NOT NULL
 16      OR col2 IS NOT NULL
 17  )
 18  SELECT /*+ MONITOR */ *
 19  FROM
 20    supertype st
 21    LEFT OUTER JOIN t1
 22    ON
 23*     st.pkey = t1.join_key

DBMS_SQLTUNE.REPORT_SQL_MONITOR(SQL_ID=>NULL,TYPE=>'TEXT')
--------------------------------------------------------------------------------------------
SQL Monitoring Report

SQL Text
------------------------------
WITH t1 AS ( SELECT pkey , CASE WHEN col2 IS NULL THEN col1 ELSE col2 END AS join_key
,description FROM nikoichi_mitaina_subtype WHERE col1 IS NOT NULL OR col2 IS NOT NULL )
SELECT /*+ MONITOR */ * FROM supertype st LEFT OUTER JOIN t1 ON st.pkey = t1.join_key

Global Information
------------------------------
 Status              :  DONE (ALL ROWS)

...略...

 Duration            :  211s（別ネタ向け仕込み）

...略...

Global Stats
===========================================================================================
| Elapsed |   Cpu   |    IO    |  Other   | Fetch | Buffer | Read | Read  | Write | Write |
| Time(s) | Time(s) | Waits(s) | Waits(s) | Calls |  Gets  | Reqs | Bytes | Reqs  | Bytes |
===========================================================================================
|      21 |      16 |     1.65 |     3.28 | 66668 |   247K | 5566 |   3GB |  3855 | 934MB |
===========================================================================================

SQL Plan Monitoring Details (Plan Hash Value=2223315184)
==============================================================================================================================================================================================================
| Id |      Operation       |           Name           |  Rows   | Cost  |   Time    | Start  | Execs |   Rows   | Read | Read  | Write | Write |  Mem  | Temp  | Activity |         Activity Detail         |
|    |                      |                          | (Estim) |       | Active(s) | Active |       | (Actual) | Reqs | Bytes | Reqs  | Bytes | (Max) | (Max) |   (%)    |           (# samples)           |
==============================================================================================================================================================================================================
|  0 | SELECT STATEMENT     |                          |         |       |       210 |     +2 |     1 |       1M |      |       |       |       |     . |     . |          |                                 |
|  1 |   HASH JOIN OUTER    |                          |      1M |  119K |       211 |     +1 |     1 |       1M | 3855 | 934MB |  3855 | 934MB | 367MB |   1GB |    85.71 | sort segment request (1)        |
|    |                      |                          |         |       |           |        |       |          |      |       |       |       |       |       |          | Cpu (10)                        |
|    |                      |                          |         |       |           |        |       |          |      |       |       |       |       |       |          | SQL*Net message to client (1)   |
|    |                      |                          |         |       |           |        |       |          |      |       |       |       |       |       |          | SQL*Net more data to client (6) |
|  2 |    TABLE ACCESS FULL | SUPERTYPE                |      1M | 19593 |         3 |     +2 |     1 |       1M |  575 | 559MB |       |       |     . |     . |          |                                 |
|  3 |    TABLE ACCESS FULL | NIKOICHI_MITAINA_SUBTYPE |    750K | 38796 |       120 |     +4 |     1 |       1M | 1134 |   1GB |       |       |     . |     . |    14.29 | Cpu (2)                         |
|    |                      |                          |         |       |           |        |       |          |      |       |       |       |       |       |          | direct path read (1)            |
==============================================================================================================================================================================================================

既存表定義を変えないでということになるとこの辺りが限界でしょうね.

オプティマイザは進化し続けていますが, モデル起因だったり構文起因だったり, まだまだ頑張っているけど, 何でもかんでもい感じに最適化できるわけではないので, モデリング頑張りましょうね. というのは不変ですよね. と思います.
今回の例は比較的単純かしていますが, 多重度が 1:*　で結合カーディナリティが多くなるタイプや, スーパータイプ, サブタイプの共存的サブタイプだとさらに結合カーディナリティが増加するので, UNIONに分割してあげるなど別の手を駆使しないと対応しにくいタイプもあるので, 頭の片隅に置いておくと良さそうです.

2022年分のおまけのおまけ. これで, おしまい.

では, また.

投稿日時 2023年1月16日 (月) 00時00分チューニング, SQL, Oracle Database 11g, Oracle Database 11g Release 2, Oracle Database 12c release 1, パフォーマンス, Advent Calendar, Oracle Database 12c Release 2, Oracle Database 18c, Oracle Database 19c, Oracle Database 21c | 固定リンク | 0 | コメント (0)

2022年12月23日 (金)

実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 23 / No.58 / ANTI JOIN

Day 22は, Subquery Unnestingを取り上げました. 最近は積極的にUnnestingしているように思うのですが, 皆さんはどう思いますか？

では, Day 23の窓を開けましょう！

今日は, 昨日話題にした, Subquery Unnesting の発動も必要ですが　ANTI JOIN　の実行計画という名のレントゲンから, いくつか特徴のある物をピックアップ（全バリエーション取れなかった言い訳w）.

ANTI JOIN（結合されなかった主問い合わせの対象行を返す）もJOINのナカーマなであるわけで, Nested Loop Join, Hash Join, Merge joinがあり, さらに, NULLを考慮する必要のある結合列がないか, 一つか, それ以上かで, Null-Awareなし, NA(Null-Aware), SNA(Single Null-Aware) でOperation列に表示されるOperation名にいくつかのバリエーションがあります.
とはいえ, ANTI JOINかNULLを意識する必要があるかないか大きな分類で, JOIN方式は通常のJOINと同じ種類があるのはご存知の通り.

NOT EXISTS演算子や, NOT IN条件かつSubquery Unnestingが発動していると, 直感的にイメージできるようになってればいいかもしれないですね. かつ, NULLを意識してるなどもOperation名から見切れるとなお.
たった1文のOperationにそこまで情報が詰め込まれているんですよね.

参考）

Oracle Database 21c SQL Tuning Guide / 9.3.4 Antijoins

いつもと同じように 21c で確認します.

SCOTT@orclpdb1> select banner from v$version;

BANNER
----------------------------------------------------------------------
Oracle Database 21c Enterprise Edition Release 21.0.0.0.0 - Production

ヒントまで使ってなんとか, NESTED LOOPS ANTI　が取れました（なかなか言うこと聞いてくれなかったw）
結合列でNULLを意識する必要のない場合に現れます.

HR@orclpdb1> @day23-2
1  SELECT
2    /*+
3      NO_INDEX(departments DEPT_ID_PK)
4    */
5    department_id
6    , department_name
7  FROM
8    departments
9  WHERE
10    department_id NOT IN
11    (
12       SELECT
13         /*+
14           NL_AJ
15         */
16         department_id
17       FROM
18         employees
19       WHERE
20         department_id IS NOT NULL
21*   )

DEPARTMENT_ID DEPARTMENT_NAME
------------- ----------------------
          120 Treasury
          130 Corporate Tax
          140 Control And Credit

...略...

          240 Government Sales
          250 Retail Sales
          260 Recruiting
          270 Payroll

16行が選択されました. 

実行計画
----------------------------------------------------------
Plan hash value: 3082375452

----------------------------------------------------------------------------------------
| Id  | Operation          | Name              | Rows  | Bytes | Cost (%CPU)| Time     |
----------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT   |                   |    17 |   323 |     3   (0)| 00:00:01 |
|   1 |  NESTED LOOPS ANTI |                   |    17 |   323 |     3   (0)| 00:00:01 |
|   2 |   TABLE ACCESS FULL| DEPARTMENTS       |    27 |   432 |     3   (0)| 00:00:01 |
|*  3 |   INDEX RANGE SCAN | EMP_DEPARTMENT_IX |    41 |   123 |     0   (0)| 00:00:01 |
----------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

 3 - access("DEPARTMENT_ID"="DEPARTMENT_ID")
     filter("DEPARTMENT_ID" IS NOT NULL)

一つ前のSQL文とほぼ同じですが, IS NOT NULL条件を取り除いてあります.
NESTED LOOPS ANTI SNAです, SNAとなっているので, NULLを意識する必要のあることがわかります.

  1  SELECT
  2    /*+
  3      NO_INDEX(departments DEPT_ID_PK)
  4    */
  5    department_id
  6    , department_name
  7  FROM
  8    departments
  9  WHERE
 10    department_id NOT IN
 11    (
 12       SELECT
 13         department_id
 14       FROM
 15         employees
 16*   )

レコードが選択されませんでした. 

実行計画
----------------------------------------------------------
Plan hash value: 2953329389

--------------------------------------------------------------------------------------------
| Id  | Operation              | Name              | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT       |                   |     1 |    19 |     6   (0)| 00:00:01 |
|*  1 |  FILTER                |                   |       |       |            |          |
|   2 |   NESTED LOOPS ANTI SNA|                   |    17 |   323 |     6  (50)| 00:00:01 |
|   3 |    TABLE ACCESS FULL   | DEPARTMENTS       |    27 |   432 |     3   (0)| 00:00:01 |
|*  4 |    INDEX RANGE SCAN    | EMP_DEPARTMENT_IX |    41 |   123 |     0   (0)| 00:00:01 |
|*  5 |   TABLE ACCESS FULL    | EMPLOYEES         |     1 |     3 |     3   (0)| 00:00:01 |
--------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   1 - filter( NOT EXISTS (SELECT 0 FROM "EMPLOYEES" "EMPLOYEES" WHERE
              "DEPARTMENT_ID" IS NULL))
   4 - access("DEPARTMENT_ID"="DEPARTMENT_ID")
   5 - filter("DEPARTMENT_ID" IS NULL)

MERGE JOIN ANTIが現れています. NA, SNAが現れていないことから, NULLは考慮しないANTI JOINであることがわかります.

SCOTT@orclpdb1> @day23

  1  SELECT
  2    deptno
  3    ,dname
  4  FROM
  5    dept
  6  WHERE
  7    deptno NOT IN
  8    (
  9       SELECT
 10         deptno
 11       FROM
 12         emp
 13       WHERE
 14         deptno IS NOT NULL
 15*   )

    DEPTNO DNAME
---------- ------------------------------------------
        40 OPERATIONS

実行計画
----------------------------------------------------------
Plan hash value: 1353548327

----------------------------------------------------------------------------------------
| Id  | Operation                    | Name    | Rows  | Bytes | Cost (%CPU)| Time     |
----------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT             |         |     1 |    16 |     6  (17)| 00:00:01 |
|   1 |  MERGE JOIN ANTI             |         |     1 |    16 |     6  (17)| 00:00:01 |
|   2 |   TABLE ACCESS BY INDEX ROWID| DEPT    |     4 |    52 |     2   (0)| 00:00:01 |
|   3 |    INDEX FULL SCAN           | PK_DEPT |     4 |       |     1   (0)| 00:00:01 |
|*  4 |   SORT UNIQUE                |         |    12 |    36 |     4  (25)| 00:00:01 |
|*  5 |    TABLE ACCESS FULL         | EMP     |    12 |    36 |     3   (0)| 00:00:01 |
----------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   4 - access("DEPTNO"="DEPTNO")
       filter("DEPTNO"="DEPTNO")
   5 - filter("DEPTNO" IS NOT NULL)

MERGE JOIN ANTI NAが出ています. NAがあるので, NULLを考慮したMERGE JOIN ANTIであることがわかります. でもこれ本当は, SNAではないのか？（時間があったら10053でも追ってみようかなぁ）

  1  SELECT
  2    deptno
  3    ,dname
  4  FROM
  5    dept
  6  WHERE
  7    deptno NOT IN
  8    (
  9       SELECT
 10         deptno
 11       FROM
 12         emp
 13*   )

    DEPTNO DNAME
---------- ------------------------------------------
        40 OPERATIONS

実行計画
----------------------------------------------------------
Plan hash value: 218628244

-------------------------------------------------------------------------------------------------
| Id  | Operation                             | Name    | Rows  | Bytes | Cost (%CPU)| Time     |
-------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                      |         |     1 |    16 |     6  (17)| 00:00:01 |
|   1 |  MERGE JOIN ANTI NA                   |         |     1 |    16 |     6  (17)| 00:00:01 |
|   2 |   SORT JOIN                           |         |     4 |    52 |     2   (0)| 00:00:01 |
|   3 |    TABLE ACCESS BY INDEX ROWID BATCHED| DEPT    |     4 |    52 |     2   (0)| 00:00:01 |
|   4 |     INDEX FULL SCAN                   | PK_DEPT |     4 |       |     1   (0)| 00:00:01 |
|*  5 |   SORT UNIQUE                         |         |    12 |    36 |     4  (25)| 00:00:01 |
|   6 |    TABLE ACCESS FULL                  | EMP     |    12 |    36 |     3   (0)| 00:00:01 |
-------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   5 - access("DEPTNO"="DEPTNO")
       filter("DEPTNO"="DEPTNO")

HASH JOIN ANTIが現れています. NULLを考慮させないために, IS NOT NULL条件を追加しています.

 1  SELECT
 2    empno
 3    ,ename
 4  FROM
 5    emp
 6  WHERE
 7    emp.deptno NOT IN
 8    (
 9       SELECT
10         /*+
11           HASH_AJ
12         */
13         dept.deptno
14       FROM
15         dept
16       WHERE
17         dept.deptno = 50
18         AND dept.deptno IS NOT NULL
19    )
20*   AND emp.deptno IS NOT NULL

    EMPNO ENAME
---------- ------------------------------
     7499 ALLEN
     7521 WARD

...略...

     7369 SMITH
     7566 JONES
     7902 FORD

12行が選択されました. 

実行計画
----------------------------------------------------------
Plan hash value: 4131168823

------------------------------------------------------------------------------
| Id  | Operation          | Name    | Rows  | Bytes | Cost (%CPU)| Time     |
------------------------------------------------------------------------------
|   0 | SELECT STATEMENT   |         |    11 |   176 |     3   (0)| 00:00:01 |
|*  1 |  HASH JOIN ANTI    |         |    11 |   176 |     3   (0)| 00:00:01 |
|*  2 |   TABLE ACCESS FULL| EMP     |    12 |   156 |     3   (0)| 00:00:01 |
|*  3 |   INDEX UNIQUE SCAN| PK_DEPT |     1 |     3 |     0   (0)| 00:00:01 |
------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

  1 - access("EMP"."DEPTNO"="DEPT"."DEPTNO")
  2 - filter("EMP"."DEPTNO" IS NOT NULL)
  3 - access("DEPT"."DEPTNO"=50)

HASH JOIN ANTI SNAが現れています. NULLを考慮する必要のあるSNAが付いた, HASH JOIN ANTIですね.

  1  SELECT
  2    empno
  3    ,ename
  4  FROM
  5    emp
  6  WHERE
  7    deptno NOT IN
  8    (
  9       SELECT
 10         deptno
 11       FROM
 12         dept
 13       WHERE
 14         deptno = 50
 15*   )

     EMPNO ENAME
---------- ------------------------------
      7499 ALLEN
      7521 WARD
      7654 MARTIN

...略...

      7369 SMITH
      7566 JONES
      7902 FORD

12行が選択されました. 

実行計画
----------------------------------------------------------
Plan hash value: 2782438375

------------------------------------------------------------------------------
| Id  | Operation          | Name    | Rows  | Bytes | Cost (%CPU)| Time     |
------------------------------------------------------------------------------
|   0 | SELECT STATEMENT   |         |    11 |   176 |     3   (0)| 00:00:01 |
|*  1 |  HASH JOIN ANTI SNA|         |    11 |   176 |     3   (0)| 00:00:01 |
|   2 |   TABLE ACCESS FULL| EMP     |    12 |   156 |     3   (0)| 00:00:01 |
|*  3 |   INDEX UNIQUE SCAN| PK_DEPT |     1 |     3 |     0   (0)| 00:00:01 |
------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   1 - access("DEPTNO"="DEPTNO")
   3 - access("DEPTNO"=50)

次は, HASH JOIN ANTI NAが出ているので, NULLを複数列で考慮してもらう必要があるので, 無理感はありますがw. 一応, 取れたw　NA付きのHASH JOIN ANTIのOperationです.

SCOTT@orclpdb1> desc foo
名前                                    NULL?    型
----------------------------------------- -------- ----------------------------
COL1                                      NOT NULL NUMBER
COL2                                      NOT NULL NUMBER
COL3                                               NUMBER

SCOTT@orclpdb1> desc bar
名前                                    NULL?    型
----------------------------------------- -------- ----------------------------
COL0                                      NOT NULL NUMBER
COL1                                               NUMBER
COL2                                               NUMBER
COL4                                               NUMBER

 1  SELECT
 2    col1
 3  FROM
 4    foo
 5  WHERE
 6    col3 NOT IN
 7    (
 8       SELECT
 9          col2
10        FROM
11          bar
12*   )

レコードが選択されませんでした. 

実行計画
----------------------------------------------------------
Plan hash value: 3985729167

---------------------------------------------------------------------------
| Id  | Operation          | Name | Rows  | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------
|   0 | SELECT STATEMENT   |      |     1 |    39 |     4   (0)| 00:00:01 |
|*  1 |  HASH JOIN ANTI NA |      |     1 |    39 |     4   (0)| 00:00:01 |
|   2 |   TABLE ACCESS FULL| FOO  |     1 |    26 |     2   (0)| 00:00:01 |
|   3 |   TABLE ACCESS FULL| BAR  |     1 |    13 |     2   (0)| 00:00:01 |
---------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

  1 - access("COL3"="COL2")

狙った通りのOperationを行わせるのって難しいですねwwwwwwww (^^;;;;;;; NA, SNAまで考えるとw　

なかなか, これだけのバリエーション, 現場で見ることはないわけですけどもwww 今回のレントゲンシリーズで一番疲れたw
今日は, ここまで,

残り2日だ.

明日も, 頑張って, 窓を開きますよ. ここまできたらw

投稿日時 2022年12月23日 (金) 00時00分チューニング, SQL, Oracle Database 11g, Oracle Database 11g Release 2, Oracle Database 12c release 1, パフォーマンス, Advent Calendar, Oracle Database 12c Release 2, Oracle Database 18c, Oracle Database 19c, Oracle Database 21c | 固定リンク | 0 | コメント (0)

2022年12月21日 (水)

実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 21 / No.56 / INLIST ITERATOR と Sub Query と STATISTICS COLLECTOR

Previously on Mac De Oracle...

Day 20は, DISTINCT Eliminationを取り上げました. 古くから実装されているElimination機能ですが, 知ってる方いましたかね？w　古すぎでしょうかw. とはいえ, この恩恵を得ている方も実は多いかもしれませんよ. クソデカクエリー追いきれてないかもしれないですし.

では, Day 21の窓を開けましょう！

久々に, 実行計画は, SQL文のレントゲン写真だ！　っぽく, 実行計画に現れるOperationを楽しんで診ていきましょう！

いつもと同じように 21c で確認します.

SCOTT@orclpdb1> select banner from v$version;

BANNER
----------------------------------------------------------------------
Oracle Database 21c Enterprise Edition Release 21.0.0.0.0 - Production

今日のテーマはIN条件とサブクエリー. IN条件といえば, 昔, 悩ませ過ぎは及ばざるがごとし #1という記事を書いてました. （そのころはまだIT業界に居なかった？　方も多そうですが）
IN条件, 索引を使って少量のデータをアクセスするには, 以下の実行計画にあるように, 　INLIST ITERATORで繰り返しアクセスするは問題ないわけですが, 大量にあるとかなり性能面で影響が出ます. （悩ませ過ぎは及ばざるがごとし #1などは, ハードパース時間に影響がでたケースです）

SCOTT@orclpdb1> @day21
  1  SELECT *
  2  FROM
  3    emp
  4  WHERE
  5*   empno IN (7369,7499)

     EMPNO ENAME                          JOB                                MGR HIREDATE        SAL       COMM     DEPTNO
---------- ------------------------------ --------------------------- ---------- -------- ---------- ---------- ----------
      7369 SMITH                          CLERK                             7902 80-12-17        800                    20
      7499 ALLEN                          SALESMAN                          7698 81-02-20       1600        300         30

実行計画
----------------------------------------------------------
Plan hash value: 2355049923

---------------------------------------------------------------------------------------
| Id  | Operation                    | Name   | Rows  | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT             |        |     2 |    78 |     2   (0)| 00:00:01 |
|   1 |  IINLIST ITERATOR            |        |       |       |            |          |
|   2 |   TABLE ACCESS BY INDEX ROWID| EMP    |     2 |    78 |     2   (0)| 00:00:01 |
|*  3 |    INDEX UNIQUE SCAN         | PK_EMP |     2 |       |     1   (0)| 00:00:01 |
---------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   3 - access("EMPNO"=7369 OR "EMPNO"=7499)

性能問題も多かった影響なのか？！, Oracle Database 9i R2頃以降, IN条件が, 結合に書き換えられるように（私の感覚でしかないのですが, 最近は, より積極的に書き換えが行われる傾向があるように感じます）なっています.
以下のようにサブクエリーを利用しているケースが典型例ですね. IN条件だけでなく, EXISTS演算子や, スカラー副問合せなどもこの書き換えの対象です. この書き換えは, Subquery Unnestingと呼ばれています. ご存知の方も多いですよね. 今日の主役はそれでなく, INLIST ITERATOR　の方ですが, これ両方話さないとOperationの向き不向きが見えないのでw

  1  SELECT
  2    *
  3  FROM
  4    emp
  5  WHERE
  6    deptno IN (
  7      SELECT
  8        deptno
  9      FROM
 10        dept
 11      WHERE
 12        dname IN ('SALES','ACCOUNT')
 13*   )

     EMPNO ENAME                          JOB                                MGR HIREDATE        SAL       COMM     DEPTNO
---------- ------------------------------ --------------------------- ---------- -------- ---------- ---------- ----------
      7499 ALLEN                          SALESMAN                          7698 81-02-20       1600        300         30
      7521 WARD                           SALESMAN                          7698 81-02-22       1250        500         30
      7654 MARTIN                         SALESMAN                          7698 81-09-28       1250       1400         30
      7698 BLAKE                          MANAGER                           7839 81-05-01       2850                    30
      7844 TURNER                         SALESMAN                          7698 81-09-08       1500          0         30
      7900 JAMES                          CLERK                             7698 81-12-03        950                    30

6行が選択されました. 

実行計画
----------------------------------------------------------
Plan hash value: 4207756064

---------------------------------------------------------------------------------------
| Id  | Operation                    | Name   | Rows  | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT             |        |     8 |   416 |     5   (0)| 00:00:01 |
|   1 |  NESTED LOOPS                |        |     8 |   416 |     5   (0)| 00:00:01 |
|   2 |   NESTED LOOPS               |        |     8 |   416 |     5   (0)| 00:00:01 |
|*  3 |    TABLE ACCESS FULL         | DEPT   |     2 |    26 |     3   (0)| 00:00:01 |
|*  4 |    INDEX RANGE SCAN          | IX_EMP |     4 |       |     0   (0)| 00:00:01 |
|   5 |   TABLE ACCESS BY INDEX ROWID| EMP    |     4 |   156 |     1   (0)| 00:00:01 |
---------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   3 - filter("DNAME"='ACCOUNT' OR "DNAME"='SALES')
   4 - access("DEPTNO"="DEPTNO")

Note
-----
   - this is an adaptive plan

前述した実行計画の Noteに, - this is an adaptive plan　と気になる情報が出ています. これ, 実行計画上は, Subquery Unnestingされて, Nested Loop Join　(NLJ) になっていますが, 駆動表のヒット件数に応じて, それ以外の結合メソッドに
へ切り替わる可能性があることを示しています. これは, adaptive planと呼ばれている機能です.
実際, NLJなのかそれ以外なのかをみる方法は, SQL Monitor, Actual Planを利用する方法と, 以下のように, Adaptive Planを表示させ, どちらで動作したのかを確認する方法があります.

ここで登場するのが, Adaptive Planの鍵になる, STATISTICS COLLECTOR というOperationです. ここで駆動表の件数をみつつ, これは！　HJ向きのと判断すれば, NLJ から HJ へ切り替えることになります.
今回は, NLJ のままですね. ()

  1* SELECT * FROM TABLE(DBMS_XPLAN.display_cursor(format => 'adaptive'))

PLAN_TABLE_OUTPUT
------------------------------------------------------------------------------
SQL_ID  cuxwr51s6gs61, child number 0
-------------------------------------
SELECT   * FROM   emp WHERE   deptno IN (     SELECT       deptno
FROM       dept     WHERE       dname IN ('SALES','ACCOUNT')   )

Plan hash value: 4207756064

------------------------------------------------------------------------------------------
|   Id  | Operation                     | Name   | Rows  | Bytes | Cost (%CPU)| Time     |
------------------------------------------------------------------------------------------
|     0 | SELECT STATEMENT              |        |       |       |     5 (100)|          |
|- *  1 |  HASH JOIN                    |        |     8 |   416 |     5   (0)| 00:00:01 |
|     2 |   NESTED LOOPS                |        |     8 |   416 |     5   (0)| 00:00:01 |
|     3 |    NESTED LOOPS               |        |     8 |   416 |     5   (0)| 00:00:01 |
|-    4 |     STATISTICS COLLECTOR      |        |       |       |            |          |
|  *  5 |      TABLE ACCESS FULL        | DEPT   |     2 |    26 |     3   (0)| 00:00:01 |
|  *  6 |     INDEX RANGE SCAN          | IX_EMP |     4 |       |     0   (0)|          |
|     7 |    TABLE ACCESS BY INDEX ROWID| EMP    |     4 |   156 |     1   (0)| 00:00:01 |
|-    8 |   TABLE ACCESS FULL           | EMP    |     4 |   156 |     1   (0)| 00:00:01 |
------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   1 - access("DEPTNO"="DEPTNO")
   5 - filter(("DNAME"='ACCOUNT' OR "DNAME"='SALES'))
   6 - access("DEPTNO"="DEPTNO")

Note
-----
   - this is an adaptive plan (rows marked '-' are inactive)

残り, 4日, 最終日はクリスマスで, 日曜日じゃないか！今年は.
大きめのネタをぶん投げて, おまけブログでまとめる感じにするか. 悩みどころだ. それとも軽めのネタで最後まで通すか.

明日も担当は, 私ですよ. （全部俺アドベントカレンダー, 来年はどうしようw　なんの苦行だという感じw　でも, それ楽しんでる俺は...w）

では, また　:)

投稿日時 2022年12月21日 (水) 00時00分 Oracle, チューニング, SQL, Oracle Database 11g, Oracle Database 11g Release 2, Oracle Database 12c release 1, パフォーマンス, Advent Calendar, Oracle Database 12c Release 2, Oracle Database 18c, Oracle Database 19c, Oracle Database 21c | 固定リンク | 0 | コメント (0)

2022年12月20日 (火)

実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 20 / No.55 / DISTINCT Elimination

Previously on Mac De Oracle...
Day 19は, かなり地味にデビューしていた機能ですが、変なところで目立った　Group by Elimination　にフォーカスを当てました。この手のEliminationは、実行計画という名のレントゲンからは見えなくなってしまう。何か悪さをしているときの調査は難易度高めです。基本的に操作が行われなくなるわけですが、例としてお見せしたような単純なSQLなら別ですが、クソデカクエリーだと、キッツイですよねw　結果不正って。

と言うことで、Day 20の窓を開けましょう！

今日は、 DISTINCT Eliminationです。またか！　と。そういうEliminationもある。ということ知っておいた方が良いと思うので、eliminationネタの最後として、ちょっと飽きてきた感じはありますが取り上げてみました。この機能の提供も古く、機能が提供されていなかった時代を知る人の方が少ないかもしれませんw

ちなみに、今回も該当機能をを局所的に無効化する例を書いていますが、ヒントが提供されていない最適化もあるので、そう言う場合は、隠しパラメータからそれらしいのを探してして、検証して効果の有無を確かめると良いと思います。MOSに書かれてないケースも多いのでBlogなどから情報を集めたりして、最終的には動作確認。もし不具合などと関連しているようであればサポートへ問い合わせても対応してくれるでしょう。コミュニティーにこれどうよ？と投げてみるのもありだと思います。Jonathanもネタもとは、コミュニティーでのやりとりだったりすることも多く、調べてみたら、そうだった！という記事も多く、本当に助かった！って経験は何度もあります！！！。

parameterはこんなあたりから見つけると楽ですよん。
Difference of Initialization Parameters between 19c (19.3.0.0.0) and 21c (21.3.0.0.0) - including hidden params
Difference of Initialization Parameters between 19c (19.3.0.0.0) and 21c (21.3.0.0.0)

いつもと同じように 21c で確認します.

SCOTT@orclpdb1> select banner from v$version;

BANNER
----------------------------------------------------------------------
Oracle Database 21c Enterprise Edition Release 21.0.0.0.0 - Production

前回と同じデータを使います。（こんな使いまわせるテストデータを作るスクリプト用意しておくと何かと便利ですよ！）

SCOTT@orclpdb1> @day20
  1* DROP TABLE business_day_calendar

表が削除されました。

  1  CREATE TABLE business_day_calendar AS
  2  WITH
  3    FUNCTION get_num_of_dates
  4    RETURN NUMBER IS
  5      l_dummy_date DATE;
  6      --
  7      eORA01839 exception;
  8      pragma exception_init(eORA01839, -1839);
  9    BEGIN
 10      -- validate leap year
 11      l_dummy_date := TO_DATE(TO_CHAR(SYSDATE, 'YYYY') || '0229', 'YYYYMMDD');
 12      RETURN 366;
 13    EXCEPTION
 14      WHEN eORA01839 THEN
 15        RETURN 365;
 16    END;
 17  SELECT
 18    TO_DATE(TRUNC(SYSDATE,'YYYY') + level - 1) AS business_date
 19    , CASE
 20        WHEN TO_CHAR(
 21          TO_DATE(TRUNC(SYSDATE,'YYYY') + level - 1)
 22          , 'DY'
 23          , 'NLS_DATE_LANGUAGE=AMERICAN'
 24        ) IN ('SUN','WED')
 25        THEN '1'
 26        ELSE '0'
 27      END AS is_holiday
 28  FROM
 29    dual
 30  CONNECT BY
 31*   level <= get_num_of_dates

表が作成されました。

  1  ALTER TABLE business_day_calendar
  2    ADD CONSTRAINT pk_business_day_calendar PRIMARY KEY
  3    (
  4      business_date
  5    )
  6*   USING INDEX

表が変更されました。

はい、主キー列にDISTINCTを使ってますが、無駄ですよね！（いきなり本題w）

DISTINCT操作は見事に実行計画から排除されています！（簡単ですね。とは言っても実行計画を見ただけでは、DISTINCT Eliminationが行われていることには気付けないわけですけども）

  1  SELECT
  2    DISTINCT business_date
  3  FROM
  4*   business_day_calendar

BUSINESS
--------
22-01-01
22-01-02
22-01-03

...略...

22-12-29
22-12-30
22-12-31

365行が選択されました。

実行計画
----------------------------------------------------------
Plan hash value: 1786497156

---------------------------------------------------------------------------------------------
| Id  | Operation        | Name                     | Rows  | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT |                          |   365 |  2920 |     1   (0)| 00:00:01 |
|   1 |  INDEX FULL SCAN | PK_BUSINESS_DAY_CALENDAR |   365 |  2920 |     1   (0)| 00:00:01 |
---------------------------------------------------------------------------------------------

統計
----------------------------------------------------------
          0  recursive calls
          0  db block gets
         26  consistent gets
          0  physical reads
          0  redo size
       8855  bytes sent via SQL*Net to client
        316  bytes received via SQL*Net from client
         26  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
        365  rows processed

では、元栓というか、Optimizer自体を、とーーーく昔の状態にしてみましょう（DISTINCT Eliminationがバックポートもされてない時代の10g 10.2.0.3。こういうことができるOracle面白いですよね）
このようなことを本番でやるのはかなりレアで、よっぽど新しい機能を使いたくないか、めちゃめちゃキツイ大人の事情があるんだと思います（知らんけど）

Optimizerを10g R2ぐらいに戻したことで、DISTINCT操作として、SORT UNIQUE NOSORTが合わられましたが、INDEX FULL SCANでユニークキーをアクセスしているのでNOSORTとなり、SORT UNIQUE操作はスキップされていることがわかります。ソート順に索引を全捜査する INDEX FULL SCANだからこそできる動きですね。

  1  SELECT
  2    /*+
  3      OPTIMIZER_FEATURES_ENABLE('10.2.0.3')
  4    */
  5    DISTINCT business_date
  6  FROM
  7*   business_day_calendar

BUSINESS
--------
22-01-01
22-01-02
22-01-03

...略...

22-12-29
22-12-30
22-12-31

365行が選択されました。

実行計画
----------------------------------------------------------
Plan hash value: 311283176

-----------------------------------------------------------------------------------------------
| Id  | Operation          | Name                     | Rows  | Bytes | Cost (%CPU)| Time     |
-----------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT   |                          |   365 |  2920 |     2  (50)| 00:00:01 |
|   1 |  SORT UNIQUE NOSORT|                          |   365 |  2920 |     2  (50)| 00:00:01 |
|   2 |   INDEX FULL SCAN  | PK_BUSINESS_DAY_CALENDAR |   365 |  2920 |     1   (0)| 00:00:01 |
-----------------------------------------------------------------------------------------------

統計
----------------------------------------------------------
          0  recursive calls
          0  db block gets
         26  consistent gets
          0  physical reads
          0  redo size
       8855  bytes sent via SQL*Net to client
        316  bytes received via SQL*Net from client
         26  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
        365  rows processed

Optimizerの能力を10gに戻してしまうのも勿体ないので、よく使う局所的な方法。特定のSQLだけが影響するのであれば、この方法がおすすめです。
元々の機能に影響を受けていない。逆に恩恵を受けているものあるかもしれません。
前回の結果不正などもそうですが、どの方法で治療するというかチューニングかは、対応するエンジニア考え方や、該当する患者さん（システムや、お客様の大人の事情w）にもよりますが、私は、基本的に局所的な対処で済むのなら、そちらを選ぶ方針です。
なるべく狭い範囲、SQL、セッションあたりで無効、有効にして、経過観察、副作用有無、対処した範囲外で、同一理由による問題が発生していないか。もし狭い範囲の対処では無理なら徐々に広げる。最終系がインスタンス全体で。みたいな流れにすることで、無駄に全て止めてしまうということを避けたい（恩恵を受けているのもあるはずということを前提にしています）。この辺りは考え方次第なので、絶対、こうするのが良いとか悪いという話では無いですが。長い目で考えるとそれが良いのでは無いかと個人的には思います。
この機能、直接利用できるヒントはないので、隠しパラメータでon/offできます。冒頭で紹介したパラメータ一覧には隠しパラメータもリストしているので、こういう時はクエリ投げずに該当ページを検索すると楽ですよん:)

  1  SELECT
  2    /*+
  3      OPT_PARAM('_optimizer_distinct_elimination','false')
  4    */
  5    DISTINCT business_date
  6  FROM
  7*   business_day_calendar

BUSINESS
--------
22-01-01
22-01-02
22-01-03

...略...

22-12-29
22-12-30
22-12-31

365行が選択されました。

実行計画
----------------------------------------------------------
Plan hash value: 311283176

-----------------------------------------------------------------------------------------------
| Id  | Operation          | Name                     | Rows  | Bytes | Cost (%CPU)| Time     |
-----------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT   |                          |   365 |  2920 |     2  (50)| 00:00:01 |
|   1 |  SORT UNIQUE NOSORT|                          |   365 |  2920 |     2  (50)| 00:00:01 |
|   2 |   INDEX FULL SCAN  | PK_BUSINESS_DAY_CALENDAR |   365 |  2920 |     1   (0)| 00:00:01 |
-----------------------------------------------------------------------------------------------

統計
----------------------------------------------------------
          0  recursive calls
          0  db block gets
         26  consistent gets
          0  physical reads
          0  redo size
       8855  bytes sent via SQL*Net to client
        316  bytes received via SQL*Net from client
         26  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
        365  rows processed

別テストケースで確認してみましょう。

  1* DROP TABLE case2

表が削除されました。

  1  CREATE TABLE case2
  2  (
  3    id NUMBER PRIMARY KEY
  4    , col2 NUMBER NOT NULL
  5    , col3 NUMBER
  6    , col4 VARCHAR2(10) NOT NULL
  7    , CONSTRAINT uix_case2 UNIQUE (col2,col3) USING INDEX
  8* )

表が作成されました。

  1  BEGIN
  2    FOR i IN 1..2000 LOOP
  3      INSERT INTO case2 VALUES(i, i, NULL, LPAD(TO_CHAR(i),10,'*'));
  4      IF MOD(i,100) = 0 THEN COMMIT; END IF;
  5    END LOOP;
  6* END;

PL/SQLプロシージャが正常に完了しました。

このテストケースでは、複合一意キーかつ、第二キーに null を許しています。
（Oraleの索引は、null が含まれない！という都市伝説がありましたが、そんなことはないのは以前解説していた通りです。一部の列にnullを許可した一意キーでもDISTINCT Eliminationは発動することを確認するテストケースです）

この例では、第二キー列がnullableで、この状態では、第二キー列全てを null にしています。DISTINCT Eliminationの条件を満たすため、DISTINCT 捜査が排除されていることがわかります！

  1  SELECT
  2    DISTINCT col2, col3
  3  FROM
  4*   case2

      COL2       COL3
---------- ----------
       541 [null]
       542 [null]
       543 [null]

...略...

      1998 [null]
      1999 [null]
      2000 [null]

2000行が選択されました。

実行計画
----------------------------------------------------------
Plan hash value: 1081843087

----------------------------------------------------------------------------------
| Id  | Operation            | Name      | Rows  | Bytes | Cost (%CPU)| Time     |
----------------------------------------------------------------------------------
|   0 | SELECT STATEMENT     |           |  2000 | 52000 |     5   (0)| 00:00:01 |
|   1 |  INDEX FAST FULL SCAN| UIX_CASE2 |  2000 | 52000 |     5   (0)| 00:00:01 |
----------------------------------------------------------------------------------

OPT_PARAM('_optimizer_distinct_elimination','false')でDISTINCT Eliminationを無効化すれば、DISTINCT 操作は現れますが、INDEX FAST FULL SCANとなっているため HASH UNIQUE操作が行われていることがわかります。
実際には、ユニーク索引なので、不要ではあるのですが:)

  1  SELECT
  2    /*+
  3      OPT_PARAM('_optimizer_distinct_elimination','false')
  4    */
  5    DISTINCT col2, col3
  6  FROM
  7*   case2

      COL2       COL3
---------- ----------
       555 [null]
       585 [null]
       586 [null]

...略...

      1986 [null]
      1989 [null]
      1990 [null]

2000行が選択されました。

実行計画
----------------------------------------------------------
Plan hash value: 523836292

-----------------------------------------------------------------------------------
| Id  | Operation             | Name      | Rows  | Bytes | Cost (%CPU)| Time     |
-----------------------------------------------------------------------------------
|   0 | SELECT STATEMENT      |           |  2000 | 52000 |     6  (17)| 00:00:01 |
|   1 |  HASH UNIQUE          |           |  2000 | 52000 |     6  (17)| 00:00:01 |
|   2 |   INDEX FAST FULL SCAN| UIX_CASE2 |  2000 | 52000 |     5   (0)| 00:00:01 |
-----------------------------------------------------------------------------------

では、ちょっと初歩的な確認で、1, nullというすでに存在する値をINSERTしてみましょう。当然エラーです。UIX_CASE2は一意キーなので。

  1* INSERT INTO case2 VALUES(2001,1,NULL,'test')
INSERT INTO case2 VALUES(2001,1,NULL,'test')
*
行1でエラーが発生しました。:
ORA-00001: 一意制約(SCOTT.UIX_CASE2)に反しています

第二キーがnullではない値を登録しておきます。

  1* INSERT INTO case2 VALUES(2002,1,1,'test')

1行が作成されました。

  1* COMMIT

コミットが完了しました。

特にどうだということもないのですがw　正しく、DISTINCT EliminationされINDEX FAST FULL SCANだけの実行計画という名のレントゲンが現れています。ニッコリ（どちらかというと、索引に null　入らないという本当の意味を知らずにいる方もいるのではないだろうかという余計な心配をしただけのお節介なテストケース。というだけだったかもしれません）

  1  SELECT
  2    DISTINCT col2, col3
  3  FROM
  4*   case2

      COL2       COL3
---------- ----------
       541 [null]
       542 [null]
       543 [null]

...略...

         1          1
         1 [null]
         2 [null]
         3 [null]

...略...

       538 [null]
       539 [null]
       540 [null]

2001行が選択されました。

実行計画
----------------------------------------------------------
Plan hash value: 1081843087

----------------------------------------------------------------------------------
| Id  | Operation            | Name      | Rows  | Bytes | Cost (%CPU)| Time     |
----------------------------------------------------------------------------------
|   0 | SELECT STATEMENT     |           |  2000 | 52000 |     5   (0)| 00:00:01 |
|   1 |  INDEX FAST FULL SCAN| UIX_CASE2 |  2000 | 52000 |     5   (0)| 00:00:01 |
----------------------------------------------------------------------------------

ということで、 Day 20はここまで。

残り5日。追い込みだーーーーっ
明日も、私が担当なので、よろしくお願いします。

投稿日時 2022年12月20日 (火) 00時00分 Oracle, チューニング, SQL, Oracle Database 11g, Oracle Database 11g Release 2, Oracle Database 12c release 1, パフォーマンス, Advent Calendar, Oracle Database 12c Release 2, Oracle Database 18c, Oracle Database 19c, Oracle Database 21c | 固定リンク | 0 | コメント (0)

2022年12月18日 (日)

実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 18 / No.53 / Join Elimination

Previously on Mac De Oracle...
Day 17は, order by Elimination にフォーカスをあてました. チューニングの現場で気づいたのが最初だったと思いますが, SQL文を見ていて, これ無駄なソートだなぁなんて思いながら実行計画という名のレントゲンをみていたら, おお！　NOSORTとかではなく, ORDER BY自体が消されてる！　賢い！　と.

では, Day 18のお題, Join Eliminationです. (登場したのは10gR2 ぐらいのはずですが, 間違ってたらツッコミ歓迎)
この排除系書き換えも, 実行計画という名のレントゲンシリーズでは, まだ紹介していなかったので, 今回は, ヒントで無効化する例も含め, 軽めの内容でw, 診ていきたいと思います. （参照整合性制約アレルギーネタを思い出すw）

いつもと同じように 21c で確認します.

SCOTT@orclpdb1> select banner from v$version;

BANNER
----------------------------------------------------------------------
Oracle Database 21c Enterprise Edition Release 21.0.0.0.0 - Production

対象となる表には外部参照整合制約があることが前提です.

customers表を結合していますが, 参照整合性制約でcustomers表に存在する顧客しか注文できないという制約があります. つまり, この参照整合性制約があるため, INNER JOINやEXISTSを利用して存在チェックする必要はないということを意味しています.
Join EliminationによりSQLが書き換えられ結合が排除されていることがわかります. 実行計画には, ORDER_PKをIndex Only Scanしているだけで, customers表やcustomersの索引を結合しているOperationは含まれていない！！！
結合しないので, 結合のコスト及び, customers表やcustomersの索引へのアクセスコストが削減されています. 実行統計からは, Pysical Readや, Buffer Getsの低下という形で現れてきます.

とはいえ, 参照整合性制約アレルギーのお持ちの方も多く, 一生目にすることのない方々も, 残念ながら多いのも事実です.
参照整合性制約アレルギーが発症してしまうと, 一生付き合っていくことになちゃいますからね（大抵の場合）

Day19の内容とDay18のネタを入れ替えたので, day19.sqlを実行しているところは気にしないでくださいw

OE@orclpdb1> @day19
  1  SELECT
  2    order_id
  3  FROM
  4    orders o
  5    INNER JOIN customers c
  6    ON
  7      o.customer_id = c.customer_id
  8  WHERE
  9*   order_id < 2400

  ORDER_ID
----------
      2354
      2355
      2356
      2357
      2358

...略...

      2396
      2397
      2398
      2399

実行計画
----------------------------------------------------------
Plan hash value: 1653993310

-----------------------------------------------------------------------------
| Id  | Operation        | Name     | Rows  | Bytes | Cost (%CPU)| Time     |
-----------------------------------------------------------------------------
|   0 | SELECT STATEMENT |          |    46 |   184 |     1   (0)| 00:00:01 |
|*  1 |  INDEX RANGE SCAN| ORDER_PK |    46 |   184 |     1   (0)| 00:00:01 |
-----------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   1 - access("O"."ORDER_ID"<2400)

統計
----------------------------------------------------------
          0  recursive calls
          0  db block gets
          5  consistent gets
          0  physical reads
          0  redo size
       1482  bytes sent via SQL*Net to client
         85  bytes received via SQL*Net from client
          5  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
         46  rows processed
/code>

NO_ELIMINATE_JOINヒントを利用し, Join Eliminationを抑止してみましょう.
NO_ELIMINATE_JOINは, 使うことがあるのか？　と思う方もいるかもしれませんが, 例えば, 不具合で7445とか, その他結果不正などに当たった時, かつ, 局所的対応で回避できそうなケースでは, 該当SQLにヒントを埋め込み, Join Eliminationの抑止で回避したりします.
どこで起きるかわからんので, インスタンスレベルで止めるケースもなくなないですが, そういう場合は, 隠しパラメータで無効化するのが一般的です. （ほぼ使わないと思いますが, ELIMINATE_JOIN　でJoin Eliminationを利用できます. インスタンスレベルで無効化している状態で, 特定のSQLだけはJoin Eliminationしたいという場合に使うぐらいですね. 滅多にないと思いますが）

  1  SELECT
  2    /*+
  3      NO_ELIMINATE_JOIN(c)
  4    */
  5    order_id
  6  FROM
  7    orders o
  8    INNER JOIN customers c
  9    ON
 10      o.customer_id = c.customer_id
 11  WHERE
 12*   order_id < 2400

  ORDER_ID
----------
      2354
      2355
      2356
      2357
      2358

...略...

      2392
      2393
      2394
      2395
      2396
      2397
      2398
      2399

実行計画
----------------------------------------------------------
Plan hash value: 875022219

-----------------------------------------------------------------------------------------------------
| Id  | Operation                            | Name         | Rows  | Bytes | Cost (%CPU)| Time     |
-----------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                     |              |    46 |   552 |     2   (0)| 00:00:01 |
|   1 |  NESTED LOOPS                        |              |    46 |   552 |     2   (0)| 00:00:01 |
|*  2 |   TABLE ACCESS BY INDEX ROWID BATCHED| ORDERS       |    46 |   368 |     2   (0)| 00:00:01 |
|*  3 |    INDEX RANGE SCAN                  | ORDER_PK     |    46 |       |     1   (0)| 00:00:01 |
|*  4 |   INDEX UNIQUE SCAN                  | CUSTOMERS_PK |     1 |     4 |     0   (0)| 00:00:01 |
-----------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   2 - filter("O"."CUSTOMER_ID">0)
   3 - access("O"."ORDER_ID"<2400)
   4 - access("O"."CUSTOMER_ID"="C"."CUSTOMER_ID")

統計
----------------------------------------------------------
          0  recursive calls
          0  db block gets
         15  consistent gets
          0  physical reads
          0  redo size
       1482  bytes sent via SQL*Net to client
         85  bytes received via SQL*Net from client
          5  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
         46  rows processed
/code>

アドベントカレンダー終わったら, もう, 今年も残りわずか....

ということで, 出口が見えつつある, アドベントカレンダー全部俺, 明日も, 俺が書きますw
では, また.

参考）
Join Elimination（結合の排除）と参照整合性制約　/ FAQ
db tech showcase Tokyo 2013 - A35 特濃JPOUG：潮溜まりでジャブジャブ, SQLチューニングの「参照整合性制約アレルギー」を参照のこと

投稿日時 2022年12月18日 (日) 00時00分 Oracle, チューニング, SQL, Oracle Database 11g, Oracle Database 11g Release 2, Oracle Database 12c release 1, パフォーマンス, Advent Calendar, Oracle Database 12c Release 2, Oracle Database 18c, Oracle Database 19c, Oracle Database 21c | 固定リンク | 0 | コメント (0)

2022年12月13日 (火)

実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 13 / No.48 / MULTI-TABLE INSERT

Previously on Mac De Oracle... Day 12は, TEMP TABLE TRANSFORMATIONにフォーカスをあてました. WITH句以外でも内部的に行われますが, 一時表へのマテリアライズを意図した話ではありますが, クソでかSQLの可読性向上のために利用されることも少なくなく, そのようなケースではインラインビューとして展開されるとうお話しでした. オプティマイザが間違えなければ:)

それでは, Day 13 の窓を開けましょう！.

今日は, MULTI-TABLE INSERT　です. え！, INSERT文なのに？　みたいに思った方もいるかもしれませんが, MULTI-TABLE INSERTは特徴的なOperationgが現れるので, 知っていた方が良いですよ. ただ, この構文自体はOracleの方言なので, なかなかお目にかからない（マルチテーブルインサート自体は他のRDBMSにもありますが, 癖の多い部分の一つなので）のですがねw　良い機能だと思いますけどね！
では, 診ていこうと思います.

いつもと同じように 21c で確認します.

SCOTT@orclpdb1> select banner from v$version;

BANNER
----------------------------------------------------------------------
Oracle Database 21c Enterprise Edition Release 21.0.0.0.0 - Production

Oracle Database 23cからdualを省略できるようになるらしいですが！　21cまでは, MULTI TABLE INSERTを利用する場合, SELECT * FROM dual　が必須です. 不要になるとかなり便利ですよね.
以下では, 文字通り複数表へINSERTしていますが, a href="https://discus-hamburg.cocolog-nifty.com/mac_de_oracle/2020/12/post-10aa61.html">同一表へ複数行INSERTすることもできます. 何気に便利でしょこれ.

SCOTT@orclpdb1> @day13
  1  INSERT ALL
  2    INTO emp(empno, ename) VALUES(7788, 'Lucky')
  3    INTO dept(deptno, dname) VALUES(88, 'QA')
  4* SELECT * FROM dual

2行が作成されました.

さて, 実行計画は, どうでしょうか. MULTI-TABLE INSERTに加えて, INTOが複数現れます. 現状, FAST DUALも出ますけど:)

実行計画
----------------------------------------------------------
Plan hash value: 2939908344

--------------------------------------------------------------------
| Id  | Operation           | Name | Rows  | Cost (%CPU)| Time     |
--------------------------------------------------------------------
|   0 | INSERT STATEMENT    |      |     1 |     2   (0)| 00:00:01 |
|   1 |  MULTI-TABLE INSERT |      |       |            |          |
|   2 |   FAST DUAL         |      |     1 |     2   (0)| 00:00:01 |
|   3 |   INTO              | EMP  |       |            |          |
|   4 |   INTO              | DEPT |       |            |          |
--------------------------------------------------------------------

統計
----------------------------------------------------------
          6  recursive calls
         11  db block gets
         10  consistent gets
          4  physical reads
       1288  redo size
        188  bytes sent via SQL*Net to client
         41  bytes received via SQL*Net from client
          1  SQL*Net roundtrips to/from client
          2  sorts (memory)
          0  sorts (disk)
          2  rows processed

この手の方言って, SQL標準で使用禁止みたいに書かれてたりすることが多くて, なんで？という気はします. 方言でも性能面で有利に働くのであれば例外は設けておくべきだと, 個人的は思うんですよね.
昔. 階層問合せ使わずに（典型的なSQLアンチパターンで）ヒーヒー言ってた現場を思い出したり. かなり昔ですけどね　ー＞　その現場へ有用性説明し階層問い合わせに書き換えたことで, 皆さん幸せな感じになってましたよーと：）

調子が出てきたので, また明日も, 担当は, 私です！

ではでは.

Related article on Mac De Oracle

投稿日時 2022年12月13日 (火) 00時00分 Oracle, チューニング, SQL, Oracle Database 11g, Oracle Database 12c release 1, パフォーマンス, Advent Calendar, Oracle Database 12c Release 2, Oracle Database 18c, Oracle Database 19c, Oracle Database 21c | 固定リンク | 0 | コメント (0)

2022年12月12日 (月)

実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 12 / No.47 /　TEMP TABLE TRANSFORMATION

Previously on Mac De Oracle... Day 11は, GROUPING SETS, ROLLUP, CUBEでした. ROLLUP, CUBEが登場したのは, Oracle Database 8i なので, 1999年あたりだったと思います. それまでUNIONを使ったクソ重, クソクエリーが多かった記憶はありますw　ROLLUP, CUBEが神様に見えましたものw　

それでは, Day 12 の窓を開けましょう！.

今日の実行計画という名のレントゲンは, TEMP TABLE TRANSFORMATION です. 内部的に変換されて行われて現れることもあるこのOperationですが, 意図的にTEMP TABLE TRANSFORMATIONに行う場合で有名なのはCTEではないでしょうか？
類似する話題LOAD AS SELECT (CURSOR DURATION MEMORY)を取り上げていました, 内容としては11g,12c,18c,19cの差異の話。今回はその元となるTEMP TABLE TRANSFORMATIONにフォーカスをあてます。

では診ていこうと思います.

いつもと同じように 21c で確認します.

SCOTT@orclpdb1> select banner from v$version;

BANNER
----------------------------------------------------------------------
Oracle Database 21c Enterprise Edition Release 21.0.0.0.0 - Production

ちなみに, WITH句でCTEを使ったら必ず, TEMP TABLE TRANSFORMATION　でマテリアライズされるということでもなく, マテリアライズするよ理, インラインビューのままでいいよねとオプティマイザが判断してインラインビューとして展開する場合もあります. それを強制する　INLINE というヒントもあります.
WITH句が利用されるケースの１つとして, 可読性向上だけを目的としている場合WITH句で定義されたクエリーが一度しか参照されていないようなケースでは, マテリアライズして一時表作るよりインラインビューで十分という判断でそのような最適化が行われます:)
逆に, マテリアライズして, 一時表に変換してほいしケースもあります. （複数回参照しているのに....みたいな場合ですね. 場合は, MATERIALIZE ヒントでオプティマイザヒントに教えてあげましょう. 最近ミスらなくなった気がしないでもない. オプティマイザも進化してますからね）

以下, オプティマイザはCTEと認識して, 一時表へマテリアライズした上で, 一時票表を再利用しています.

SCOTT@orclpdb1> @day12
  1  WITH temp_emp AS
  2  (
  3   SELECT
  4     emp.*
  5     ,dept.dname
  6   FROM
  7     emp
  8     INNER JOIN dept
  9     ON
 10       emp.deptno = dept.deptno
 11  )
 12  SELECT
 13    *
 14  FROM
 15    temp_emp
 16  WHERE
 17    temp_emp.empno = 7369
 18  UNION
 19  SELECT
 20    *
 21  FROM
 22    temp_emp
 23  WHERE
 24*   temp_emp.deptno = 20

     EMPNO ENAME                          JOB                                MGR HIREDATE        SAL       COMM     DEPTNO DNAME
---------- ------------------------------ --------------------------- ---------- -------- ---------- ---------- ---------- ------------------------------------------
      7369 SMITH                          CLERK                             7902 80-12-17        800                    20 RESEARCH
      7902 FORD                           ANALYST                           7566 81-12-03       3000                    20 RESEARCH
      7566 JONES                          MANAGER                           7839 81-04-02       2975                    20 RESEARCH

実行計画
----------------------------------------------------------
Plan hash value: 1235767800

----------------------------------------------------------------------------------------------------------------------
| Id  | Operation                                | Name                      | Rows  | Bytes | Cost (%CPU)| Time     |
----------------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                         |                           |     8 |   768 |     6  (34)| 00:00:01 |
|   1 |  TEMP TABLE TRANSFORMATION               |                           |       |       |            |          |
|   2 |   LOAD AS SELECT (CURSOR DURATION MEMORY)| SYS_TEMP_0FD9D665A_DDA815 |       |       |            |          |
|   3 |    MERGE JOIN                            |                           |     4 |   208 |     6  (17)| 00:00:01 |
|   4 |     TABLE ACCESS BY INDEX ROWID          | DEPT                      |     4 |    52 |     2   (0)| 00:00:01 |
|   5 |      INDEX FULL SCAN                     | PK_DEPT                   |     4 |       |     1   (0)| 00:00:01 |
|*  6 |     SORT JOIN                            |                           |     4 |   156 |     4  (25)| 00:00:01 |
|*  7 |      TABLE ACCESS FULL                   | EMP                       |     4 |   156 |     3   (0)| 00:00:01 |
|   8 |   HASH UNIQUE                            |                           |     8 |   768 |     6  (34)| 00:00:01 |
|   9 |    UNION-ALL                             |                           |       |       |            |          |
|* 10 |     VIEW                                 |                           |     4 |   384 |     2   (0)| 00:00:01 |
|  11 |      TABLE ACCESS FULL                   | SYS_TEMP_0FD9D665A_DDA815 |     4 |   196 |     2   (0)| 00:00:01 |
|* 12 |     VIEW                                 |                           |     4 |   384 |     2   (0)| 00:00:01 |
|  13 |      TABLE ACCESS FULL                   | SYS_TEMP_0FD9D665A_DDA815 |     4 |   196 |     2   (0)| 00:00:01 |
----------------------------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   6 - access("EMP"."DEPTNO"="DEPT"."DEPTNO")
       filter("EMP"."DEPTNO"="DEPT"."DEPTNO")
   7 - filter("EMP"."DEPTNO"=20 OR "EMP"."EMPNO"=7369)
  10 - filter("TEMP_EMP"."EMPNO"=7369)
  12 - filter("TEMP_EMP"."DEPTNO"=20)

統計
----------------------------------------------------------
          0  recursive calls
          0  db block gets
          8  consistent gets
          0  physical reads
          0  redo size
       1362  bytes sent via SQL*Net to client
         52  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          1  sorts (memory)
          0  sorts (disk)
          3  rows processed

CTEの一時表へのマテリアライズを　INLINE　ヒントでインラインに展開するようにした例です. 一時表へのマテリアライズが抑止され, SQL本文に同一クエリーが展開されている様子が見えます.
WITH句がサポートされていなかった頃は, 事前に一時表を作成して使ったり苦労していたことを思うと, これも非常に便利な機能ですよね.

  1  WITH temp_emp AS
  2  (
  3   SELECT
  4     /*+
  5       inline
  6     */
  7     emp.*
  8     ,dept.dname
  9   FROM
 10     emp
 11     INNER JOIN dept
 12     ON
 13       emp.deptno = dept.deptno
 14  )
 15  SELECT
 16    *
 17  FROM
 18    temp_emp
 19  WHERE
 20    temp_emp.empno = 7369
 21  UNION
 22  SELECT
 23    *
 24  FROM
 25    temp_emp
 26  WHERE
 27*   temp_emp.deptno = 20

     EMPNO ENAME                          JOB                                MGR HIREDATE        SAL       COMM     DEPTNO DNAME
---------- ------------------------------ --------------------------- ---------- -------- ---------- ---------- ---------- ------------------------------------------
      7369 SMITH                          CLERK                             7902 80-12-17        800                    20 RESEARCH
      7566 JONES                          MANAGER                           7839 81-04-02       2975                    20 RESEARCH
      7902 FORD                           ANALYST                           7566 81-12-03       3000                    20 RESEARCH

実行計画
----------------------------------------------------------
Plan hash value: 119758422

---------------------------------------------------------------------------------------------------
| Id  | Operation                              | Name     | Rows  | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                       |          |     4 |   208 |     5  (20)| 00:00:01 |
|   1 |  HASH UNIQUE                           |          |     4 |   208 |     5  (20)| 00:00:01 |
|   2 |   UNION-ALL                            |          |       |       |            |          |
|   3 |    NESTED LOOPS                        |          |     1 |    52 |     2   (0)| 00:00:01 |
|   4 |     TABLE ACCESS BY INDEX ROWID        | EMP      |     1 |    39 |     1   (0)| 00:00:01 |
|*  5 |      INDEX UNIQUE SCAN                 | PK_EMP   |     1 |       |     0   (0)| 00:00:01 |
|   6 |     TABLE ACCESS BY INDEX ROWID        | DEPT     |     1 |    13 |     1   (0)| 00:00:01 |
|*  7 |      INDEX UNIQUE SCAN                 | PK_DEPT  |     1 |       |     0   (0)| 00:00:01 |
|   8 |    NESTED LOOPS                        |          |     3 |   156 |     2   (0)| 00:00:01 |
|   9 |     TABLE ACCESS BY INDEX ROWID        | DEPT     |     1 |    13 |     1   (0)| 00:00:01 |
|* 10 |      INDEX UNIQUE SCAN                 | PK_DEPT  |     1 |       |     0   (0)| 00:00:01 |
|  11 |     TABLE ACCESS BY INDEX ROWID BATCHED| EMP      |     3 |   117 |     1   (0)| 00:00:01 |
|* 12 |      INDEX RANGE SCAN                  | IX01_EMP |     3 |       |     0   (0)| 00:00:01 |
---------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   5 - access("EMP"."EMPNO"=7369)
   7 - access("EMP"."DEPTNO"="DEPT"."DEPTNO")
  10 - access("DEPT"."DEPTNO"=20)
  12 - access("EMP"."DEPTNO"=20)

統計
----------------------------------------------------------
          0  recursive calls
          0  db block gets
          8  consistent gets
          0  physical reads
          0  redo size
       1362  bytes sent via SQL*Net to client
         52  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          3  rows processed

サッカーの判定に利用されているVAR(Video Assistant Referee)ですが, 人の判断だと微妙なところとは人それぞれのブレが現れるので, テニスでもそうですがわかりやすいので良いんじゃないかと思いますが. ね. （ここ数日そういうブレによる判定へ意義申し立てしたりしてるw　しかも見落としだし原因は. ）

でちょいと, めんどくせーなーとなっていたりしているわけですけども.

それはさておき.

明日も, アドベントの担当は私ですw

ではまた.

参考）

SCOTT@orclpdb1> select name,inverse, sql_feature from v$sql_hint where name in ('INLINE');

NAME                 INVERSE              SQL_FEATURE
-------------------- -------------------- ------------------------------
INLINE               MATERIALIZE          QKSFM_TRANSFORMATION

Related article on Mac De Oracle

投稿日時 2022年12月12日 (月) 00時00分 Oracle, チューニング, SQL, Oracle Database 11g, Oracle Database 11g Release 2, Oracle Database 12c release 1, パフォーマンス, Advent Calendar, Oracle Database 12c Release 2, Oracle Database 18c, Oracle Database 19c, Oracle Database 21c | 固定リンク | 0 | コメント (0)

2022年12月11日 (日)

実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 11 / No.46 / GROUPING SETS, ROLLUP, CUBE

Previously on Mac De Oracle... Day 10は, MAT_VIEW REWRITE ACCESS FULLでした. Materialized Viewアクセスへ内部でRewriteする機能は随分前からありますが, Oracle Databaseらしい機能の一つだなぁ. と思います. 6.7 Using Real-time Materialized Viewsのように既存機能のブラッシュアップなど継続的に細かい改善が行われていたりします.

それでは, Day 11 の窓を開けましょう！.

まだ紹介していない既存の実行計画多いんですよね. SQLもそうですが, 実行計画になるとますます奥が深いですといいますか, このシリーズ, ネタは沢山あるので当分持ちそうですw

まず, 2011年の面倒くさい大人の事情縛りシリーズのネタですが, 考え方は今でも同じなので, 一度, 軽く眺めておいてください. その間に準備しますのでw.. (違
なお, SQLヒントの書き方で, 最近, ヒントが利用されたかどうかレポートされるようになったことで, USE_HASH, USE_NLのヒントの書き方が云々とかいう話をたまに聞きますが, エラーではなくて無視されるというのが仕様なので, それをうまく利用した使い方を, 面倒くさい大人の事情だらけの現場で考えて今に至った結果であるということは, いずれどこかで説明したいとは思います. （ポイントはチューニングする際の手間削減だったり, どこまで固定するべきか, しないほうが良いかという判断だったりします. 経年で変化もしますからね. ただ, それが手癖になっているという点は否めないわけですけども）
・いろいろと面倒くさい大人の事情縛りのOracleパフォーマンスチューニング #1
・いろいろと面倒くさい大人の事情縛りのOracleパフォーマンスチューニング #2
・いろいろと面倒くさい大人の事情縛りのOracleパフォーマンスチューニング #3
・いろいろと面倒くさい大人の事情縛りのOracleパフォーマンスチューニング #4
・いろいろと面倒くさい大人の事情縛りのOracleパフォーマンスチューニング #5
・いろいろと面倒くさい大人の事情縛りのOracleパフォーマンスチューニング #6
・いろいろと面倒くさい大人の事情縛りのOracleパフォーマンスチューニング #7 おまけ
 ・いろいろと面倒くさい大人の事情縛りのOracleパフォーマンスチューニング８おまけのおまけ
 ・いろいろと面倒くさい大人の事情縛りのOracleパフォーマンスチューニング番外編

昔の2011年ぐらいの頃の　Oracle Database の実行計画を見たことない年齢のエンジニア多くなってきているとは思いますが, どうでしたか？　上記の過去エントリー. 今でも考え方の基本のキです.

ということで, やっと, 今日の本題です.

データはなくても想定した実行計画のキーワードは取得できるので, 表（データなし）と索引だけ作っておきます. （データ登録するのが面倒だったということでもありますが, 影響はないのでw）
なお, 以下表は, ・いろいろと面倒くさい大人の事情縛りのOracleパフォーマンスチューニング #1で利用したものと同一です.

SCOTT@orclpdb1> @day11
  1* drop table test1

表が削除されました. 

経過: 00:00:00.04
  1  create table test1
  2  (
  3  	starting_date char(8) not null,
  4  	shop_code char(4) not null,
  5  	sales_figure number not null,
  6  	item_code char(10) not null,
  7  	constraint pk_test1 primary key (starting_date,item_code,shop_code) using index nologging
  8  )
  9* nologging

表が作成されました. 

経過: 00:00:00.02
  1* drop table test2

表が削除されました. 

経過: 00:00:00.05
  1  create table test2
  2  (
  3  	starting_date char(8) not null,
  4  	shop_code char(4) not null,
  5  	sales_figure number not null,
  6  	item_code char(10) not null,
  7  	constraint pk_test2 primary key (starting_date,item_code,shop_code) using index global nologging
  8  )
  9  partition by hash(starting_date)
 10  (
 11   	partition test201,
 12   	partition test202,
 13   	partition test203,
 14   	partition test204
 15  )
 16* nologging

表が作成されました. 

経過: 00:00:00.02
  1* drop table test3

表が削除されました. 

経過: 00:00:00.07
  1  create table test3
  2  (
  3  	starting_date char(8) not null,
  4  	shop_code char(4) not null,
  5  	sales_figure number not null,
  6  	item_code char(10) not null,
  7  	constraint pk_test3 primary key (starting_date,item_code,shop_code) using index local
  8  	(
  9  		partition test301idx,
 10  		partition test302idx,
 11  		partition test303idx,
 12  		partition test304idx,
 13  		partition test305idx,
 14  		partition test306idx,
 15  		partition test307idx,
 16  		partition test308idx,
 17  		partition test309idx,
 18  		partition test310idx,
 19  		partition test311idx,
 20  		partition test312idx,
 21  		partition testmaxidx
 22  	)
 23  	nologging
 24   )
 25   partition by range(starting_date) (
 26   	partition test301 values less than ('20110201') ,
 27   	partition test302 values less than ('20110301') ,
 28   	partition test303 values less than ('20110401') ,
 29   	partition test304 values less than ('20110501') ,
 30  	partition test305 values less than ('20110601') ,
 31  	partition test306 values less than ('20110701') ,
 32  	partition test307 values less than ('20110801') ,
 33  	partition test308 values less than ('20110901') ,
 34  	partition test309 values less than ('20111001') ,
 35  	partition test310 values less than ('20111101') ,
 36  	partition test311 values less than ('20111201') ,
 37  	partition test312 values less than ('20120101') ,
 38   	partition testmax values less than (maxvalue)
 39  )
 40* nologging

表が作成されました. 

経過: 00:00:00.05

GROUPING SETSから.
GROUPING SETSというキーワードは実行計画には現れまん. 内部で後半で説明するROLLUPが含まれる一時表が生成されるように書き換えられる挙動が特徴です. 2011の頃の実行計画と大きく違うのは, CURSOR DURATION MEMORYなんて操作が行われてるあたりですね.
GROUPING SETSというキーワードはないですが, 内部的には, CTEが利用されてROLLUP等と併用されている挙動なので, CTEによる一時表の生成コストがポイントになります. 最近はSSDがほとんどだろうと思うので, HDDだった頃ほど, 一時表の生成コストは気にならないケースも多いかもしれないですけども, 状況次第, どこまでチューニングするか次第というところはありますよね.

  1  SELECT
  2       CASE
  3          WHEN quarter IS NULL THEN month
  4          ELSE quarter
  5       END AS month
  6      ,CASE
  7          WHEN grouping_id = 1 THEN 'ALL'
  8          ELSE shop_code
  9       END AS shop_code
 10     ,sales_figure
 11  FROM (
 12     SELECT
 13          grouping_id(shop_code) as grouping_id
 14         ,quarter
 15         ,month
 16         ,shop_code
 17         ,SUM(sales_figure) AS sales_figure
 18     FROM
 19     (
 20         SELECT
 21             CASE
 22                 WHEN SUBSTR(starting_date,5,2) BETWEEN '04' AND '06' THEN 'Q1'
 23                 WHEN SUBSTR(starting_date,5,2) BETWEEN '07' AND '09' THEN 'Q2'
 24                 WHEN SUBSTR(starting_date,5,2) BETWEEN '10' AND '12' THEN 'Q3'
 25                 WHEN SUBSTR(starting_date,5,2) BETWEEN '01' AND '03' THEN 'Q4'
 26             END AS quarter
 27             ,SUBSTR(starting_date,1,6) AS month
 28             ,shop_code
 29             ,sales_figure
 30         FROM
 31             test2
 32         WHERE
 33             SUBSTR(starting_date,1,6) BETWEEN '201101' AND '201103'
 34     )
 35     GROUP BY GROUPING SETS (
 36         (month, shop_code),
 37         (quarter, shop_code),
 38         (month),
 39         (quarter)
 40     )
 41  )
 42  WHERE
 43         shop_code = '1000'
 44      OR grouping_id  = 1
 45  ORDER BY
 46       month
 47*     ,shop_code

レコードが選択されませんでした. 

経過: 00:00:00.03

レコードが選択されませんでした. 

経過: 00:00:00.01

実行計画
----------------------------------------------------------
Plan hash value: 2567395266

----------------------------------------------------------------------------------------------------------------------------------------
| Id  | Operation                                  | Name                      | Rows  | Bytes | Cost (%CPU)| Time     | Pstart| Pstop |
----------------------------------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                           |                           |     1 |    50 |    11  (28)| 00:00:01 |       |       |
|   1 |  SORT ORDER BY                             |                           |     1 |    50 |    11  (28)| 00:00:01 |       |       |
|   2 |   VIEW                                     |                           |     1 |    50 |    10  (20)| 00:00:01 |       |       |
|   3 |    TEMP TABLE TRANSFORMATION               |                           |       |       |            |          |       |       |
|   4 |     LOAD AS SELECT (CURSOR DURATION MEMORY)| SYS_TEMP_0FD9D6620_DD3617 |       |       |            |          |       |       |
|   5 |      PARTITION HASH ALL                    |                           |     1 |    29 |     2   (0)| 00:00:01 |     1 |     4 |
|*  6 |       TABLE ACCESS FULL                    | TEST2                     |     1 |    29 |     2   (0)| 00:00:01 |     1 |     4 |
|   7 |     LOAD AS SELECT (CURSOR DURATION MEMORY)| SYS_TEMP_0FD9D6621_DD3617 |       |       |            |          |       |       |
|   8 |      HASH GROUP BY ROLLUP                  |                           |     1 |    29 |     3  (34)| 00:00:01 |       |       |
|   9 |       TABLE ACCESS FULL                    | SYS_TEMP_0FD9D6620_DD3617 |     1 |    29 |     2   (0)| 00:00:01 |       |       |
|  10 |     LOAD AS SELECT (CURSOR DURATION MEMORY)| SYS_TEMP_0FD9D6621_DD3617 |       |       |            |          |       |       |
|  11 |      HASH GROUP BY ROLLUP                  |                           |     1 |    23 |     3  (34)| 00:00:01 |       |       |
|  12 |       TABLE ACCESS FULL                    | SYS_TEMP_0FD9D6620_DD3617 |     1 |    23 |     2   (0)| 00:00:01 |       |       |
|  13 |     VIEW                                   |                           |     1 |    50 |     2   (0)| 00:00:01 |       |       |
|* 14 |      TABLE ACCESS FULL                     | SYS_TEMP_0FD9D6621_DD3617 |     1 |    29 |     2   (0)| 00:00:01 |       |       |
----------------------------------------------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   6 - filter(SUBSTR("SYS_TBL_$1$"."STARTING_DATE",1,6)>='201101' AND SUBSTR("SYS_TBL_$1$"."STARTING_DATE",1,6)<='201103')
  14 - filter("SYS_TEMP_0FD9D6621_DD3617"."C1"='1000' OR BIN_TO_NUM(SYS_OP_VECBIT(SYS_OP_NUMTORAW("SYS_TEMP_0FD9D6621_DD3617"."D
              0"),1))=1)

Hint Report (identified by operation id / Query Block Name / Object Alias):
Total hints for statement: 1 (U - Unused (1))
---------------------------------------------------------------------------

  13 -  SEL$80FD2AB9
         U -  NO_MERGE

Note
-----
   - dynamic statistics used: dynamic sampling (level=2)

統計
----------------------------------------------------------
          0  recursive calls
          2  db block gets
          0  consistent gets
          0  physical reads
        384  redo size
        542  bytes sent via SQL*Net to client
         41  bytes received via SQL*Net from client
          1  SQL*Net roundtrips to/from client
          1  sorts (memory)
          0  sorts (disk)
          0  rows processed

次に, ROLLUP. GROUPPING SETSで内部的に行われていますが, 実際にROLLUPを実行するとこうなります. （最初のSQL分とは集計内容が異なるので結果は同一ではないことはお気づきだと思います. データが無い状態で実行しているのでわかりづらいですが, ご注意くさだい）

  1  SELECT
  2     CASE
  3         WHEN grouping_id(month) = 1 THEN
  4             CASE
  5                 WHEN SUBSTR(MIN(month),5,2)||SUBSTR(MAX(month),5,2) = '0406' THEN 'Q1'
  6                 WHEN SUBSTR(MIN(month),5,2)||SUBSTR(MAX(month),5,2) = '0709' THEN 'Q2'
  7                 WHEN SUBSTR(MIN(month),5,2)||SUBSTR(MAX(month),5,2) = '1012' THEN 'Q3'
  8                 WHEN SUBSTR(MIN(month),5,2)||SUBSTR(MAX(month),5,2) = '0103' THEN 'Q4'
  9             END
 10          ELSE month
 11      END AS month
 12     ,CASE
 13          WHEN grouping_id(shop_code) = 1 THEN 'ALL'
 14          ELSE shop_code
 15      END AS shop_code
 16     ,SUM(sales_figure) AS sales_figure
 17  FROM
 18      (
 19          SELECT
 20               SUBSTR(starting_date,1,6) AS month
 21              ,shop_code
 22              ,SUM(sales_figure) AS sales_figure
 23          FROM
 24              test2
 25          WHERE
 26              starting_date BETWEEN '20110101' AND '20110331'
 27          GROUP BY
 28              SUBSTR(starting_date,1,6)
 29             ,shop_code
 30      )
 31  GROUP BY
 32      ROLLUP(month,shop_code)
 33  HAVING
 34      shop_code = '1000'
 35      OR grouping_id(shop_code) = 1
 36  ORDER BY
 37      month
 38*    ,shop_code

レコードが選択されませんでした. 

経過: 00:00:00.02

レコードが選択されませんでした. 

経過: 00:00:00.01

実行計画
----------------------------------------------------------
Plan hash value: 3343531542

----------------------------------------------------------------------------------------------------------------------------
| Id  | Operation                                       | Name     | Rows  | Bytes | Cost (%CPU)| Time     | Pstart| Pstop |
----------------------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                                |          |     1 |    33 |     4  (75)| 00:00:01 |       |       |
|   1 |  SORT ORDER BY                                  |          |     1 |    33 |     4  (75)| 00:00:01 |       |       |
|*  2 |   FILTER                                        |          |       |       |            |          |       |       |
|   3 |    HASH GROUP BY ROLLUP                         |          |     1 |    33 |     4  (75)| 00:00:01 |       |       |
|   4 |     VIEW                                        |          |     1 |    33 |     2  (50)| 00:00:01 |       |       |
|   5 |      HASH GROUP BY                              |          |     1 |    29 |     2  (50)| 00:00:01 |       |       |
|   6 |       TABLE ACCESS BY GLOBAL INDEX ROWID BATCHED| TEST2    |     1 |    29 |     1   (0)| 00:00:01 | ROWID | ROWID |
|*  7 |        INDEX RANGE SCAN                         | PK_TEST2 |     1 |       |     1   (0)| 00:00:01 |       |       |
----------------------------------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   2 - filter("SHOP_CODE"='1000' OR GROUPING_ID(BIN_TO_NUM(SYS_OP_GROUPING("SHOP_CODE",1,0,SYS_OP_BITVEC)))=1)
   7 - access("STARTING_DATE">='20110101' AND "STARTING_DATE"<='20110331')

Note
-----
   - dynamic statistics used: dynamic sampling (level=2)

統計
----------------------------------------------------------
          0  recursive calls
          0  db block gets
          0  consistent gets
          0  physical reads
          0  redo size
        542  bytes sent via SQL*Net to client
         41  bytes received via SQL*Net from client
          1  SQL*Net roundtrips to/from client
          1  sorts (memory)
          0  sorts (disk)
          0  rows processed

最後は, CUBEです. これは, GROUPING SETSで行っていたことと同じことをCUBEを使って実現しています. 同じ結果を得るのであれば, CUBEの方が有利そうだ, という点に気づいた方は多いだろう思います:)

  1  SELECT
  2     CASE
  3         WHEN grouping_id(month) = 1 THEN
  4             CASE
  5                 WHEN SUBSTR(MIN(month),5,2)||SUBSTR(MAX(month),5,2) = '0406' THEN 'Q1'
  6                 WHEN SUBSTR(MIN(month),5,2)||SUBSTR(MAX(month),5,2) = '0709' THEN 'Q2'
  7                 WHEN SUBSTR(MIN(month),5,2)||SUBSTR(MAX(month),5,2) = '1012' THEN 'Q3'
  8                 WHEN SUBSTR(MIN(month),5,2)||SUBSTR(MAX(month),5,2) = '0103' THEN 'Q4'
  9             END
 10          ELSE month
 11      END AS month
 12     ,CASE
 13          WHEN grouping_id(shop_code) = 1 THEN 'ALL'
 14          ELSE shop_code
 15      END AS shop_code
 16     ,SUM(sales_figure) AS sales_figure
 17  FROM
 18      (
 19          SELECT
 20               SUBSTR(starting_date,1,6) AS month
 21              ,shop_code
 22              ,SUM(sales_figure) AS sales_figure
 23          FROM
 24              test2
 25          WHERE
 26              starting_date BETWEEN '20110101' AND '20110331'
 27          GROUP BY
 28              SUBSTR(starting_date,1,6)
 29             ,shop_code
 30      )
 31  GROUP BY
 32      CUBE(month,shop_code)
 33  HAVING
 34      shop_code = '1000'
 35      OR grouping_id(shop_code) = 1
 36  ORDER BY
 37      month
 38*    ,shop_code

レコードが選択されませんでした. 

経過: 00:00:00.01

レコードが選択されませんでした. 

経過: 00:00:00.00

実行計画
----------------------------------------------------------
Plan hash value: 2588666537

------------------------------------------------------------------------------------------------------------------------------
| Id  | Operation                                         | Name     | Rows  | Bytes | Cost (%CPU)| Time     | Pstart| Pstop |
------------------------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                                  |          |     1 |    33 |     4  (75)| 00:00:01 |       |       |
|   1 |  SORT ORDER BY                                    |          |     1 |    33 |     4  (75)| 00:00:01 |       |       |
|*  2 |   FILTER                                          |          |       |       |            |          |       |       |
|   3 |    SORT GROUP BY                                  |          |     1 |    33 |     4  (75)| 00:00:01 |       |       |
|   4 |     GENERATE CUBE                                 |          |     1 |    33 |     4  (75)| 00:00:01 |       |       |
|   5 |      SORT GROUP BY                                |          |     1 |    33 |     4  (75)| 00:00:01 |       |       |
|   6 |       VIEW                                        |          |     1 |    33 |     2  (50)| 00:00:01 |       |       |
|   7 |        HASH GROUP BY                              |          |     1 |    29 |     2  (50)| 00:00:01 |       |       |
|   8 |         TABLE ACCESS BY GLOBAL INDEX ROWID BATCHED| TEST2    |     1 |    29 |     1   (0)| 00:00:01 | ROWID | ROWID |
|*  9 |          INDEX RANGE SCAN                         | PK_TEST2 |     1 |       |     1   (0)| 00:00:01 |       |       |
------------------------------------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   2 - filter("SHOP_CODE"='1000' OR GROUPING_ID(BIN_TO_NUM(SYS_OP_GROUPING("SHOP_CODE",1,0,SYS_OP_BITVEC)))=1)
   9 - access("STARTING_DATE">='20110101' AND "STARTING_DATE"<='20110331')

Note
-----
   - dynamic statistics used: dynamic sampling (level=2)

統計
----------------------------------------------------------
          0  recursive calls
          0  db block gets
          0  consistent gets
          0  physical reads
          0  redo size
        542  bytes sent via SQL*Net to client
         41  bytes received via SQL*Net from client
          1  SQL*Net roundtrips to/from client
          3  sorts (memory)
          0  sorts (disk)
          0  rows processed

アドベントカレンダー書いているだけで, 12月が終わってしまう気がするw

ということを, 言っても, やはり, 明日も担当は, 私ですw

では, また.

参考） Oracle Database 21c - Data Warehousing Guide / 21 SQL for Aggregation in Data Warehouses

投稿日時 2022年12月11日 (日) 00時00分 Oracle, チューニング, SQL, Oracle Database 11g, Oracle Database 12c release 1, パフォーマンス, Advent Calendar, Oracle Database 12c Release 2, Oracle Database 18c, Oracle Database 19c, Oracle Database 21c | 固定リンク | 0 | コメント (0)

2022年12月 5日 (月)

実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 5 / No.40 / PIVOT and UNPIVOT

Previously on Mac De Oracle...
Day 4は, SQLというより, in-memory operationに追加された, In-Memory Hybrid Scans　の実行計画という名のレントゲンをみながら, どのような状況で発動するのかを簡単に確認しましたー.

なかな面白い動きでしたね. 別途時間を取って深掘りしないとね, と. :)

ということで, Day 5 の窓を開けましょう. 今日は, 新機能というより以前からあったのにレントゲン取ってなかったよね？　ということで　PIVOT and UNPIVOT　を診てみたいと思います.

いつもと同じように 21c で確認します.

SCOTT@orclpdb1> select banner from v$version;

BANNER
----------------------------------------------------------------------
Oracle Database 21c Enterprise Edition Release 21.0.0.0.0 - Production

最初は, pivot 向けデータの準備から

SCOTT@orclpdb1> @day5

表が削除されました. 

  1  CREATE TABLE for_pivot
  2  AS
  3  SELECT
  4    stat_name
  5  , value
  6  FROM
  7    v$sys_time_model
  8  WHERE
  9    stat_name IN (
 10      'DB time'
 11    , 'DB CPU'
 12    , 'background elapsed time'
 13    , 'background cpu time'
 14*   )

表が作成されました. 

  1* CREATE INDEX ix_for_pivot ON for_pivot(stat_name)

索引が作成されました. 

  1  SELECT
  2    *
  3  FROM
  4*   for_pivot

STAT_NAME                           VALUE
------------------------------ ----------
DB time                         143415979
DB CPU                          127540525
background elapsed time           7381483
background cpu time               6340262
/code>

PIVOTで行持ちを列持ちに変換してみます.

おお, 実行計画には, PIVOT とか出ないのですよーーーー！！　（知ってましたか！
こいつも実行計画を見ただけでは, PIVOTが行われているかは読み取れないですねw　アクセスパス以外は注意する箇所はあまりないわけですけども:)

  1  SELECT
  2    db_time
  3   ,db_cpu
  4  FROM
  5  (
  6    SELECT
  7      stat_name
  8    , value
  9    FROM
 10      for_pivot
 11    WHERE
 12      stat_name IN ('DB time', 'DB CPU')
 13  )
 14  PIVOT
 15  (
 16    MAX(value)
 17    FOR stat_name IN
 18    (
 19      'DB time' AS db_time
 20     ,'DB CPU' AS db_cpu
 21    )
 22* )

   DB_TIME     DB_CPU
---------- ----------
 143415979  127540525


実行計画
----------------------------------------------------------
Plan hash value: 1690715989

-------------------------------------------------------------------------------------------------------
| Id  | Operation                              | Name         | Rows  | Bytes | Cost (%CPU)| Time     |
-------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                       |              |     1 |    26 |     2   (0)| 00:00:01 |
|   1 |  VIEW                                  |              |     1 |    26 |     2   (0)| 00:00:01 |
|   2 |   SORT AGGREGATE                       |              |     1 |    22 |            |          |
|   3 |    INLIST ITERATOR                     |              |       |       |            |          |
|   4 |     TABLE ACCESS BY INDEX ROWID BATCHED| FOR_PIVOT    |     2 |    44 |     2   (0)| 00:00:01 |
|*  5 |      INDEX RANGE SCAN                  | IX_FOR_PIVOT |     2 |       |     1   (0)| 00:00:01 |
-------------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   5 - access("STAT_NAME"='DB CPU' OR "STAT_NAME"='DB time')

統計
----------------------------------------------------------
          0  recursive calls
          0  db block gets
          3  consistent gets
          0  physical reads
          0  redo size
        677  bytes sent via SQL*Net to client
         52  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          1  rows processed
/code>

次に, UNPIVOT 向けデータの準備

表が削除されました. 

  1  CREATE TABLE for_unpivot
  2  AS
  3  SELECT
  4  	db_time
  5  	,db_cpu
  6  	,bg_time
  7  	,bg_cpu
  8  FROM
  9  	(
 10  		SELECT
 11  			stat_name
 12  			,value
 13  		FROM
 14  			v$sys_time_model
 15  	)
 16  PIVOT
 17  	(
 18  		MAX(value)
 19  		FOR stat_name IN
 20  			(
 21  				'DB time' AS db_time
 22  				,'DB CPU' AS db_cpu
 23  				,'background elapsed time' AS bg_time
 24  				,'background cpu time' AS bg_cpu
 25  			)
 26* 	)

表が作成されました. 

  1* COMMIT

コミットが完了しました. 

  1  SELECT
  2    *
  3  FROM
  4*   for_unpivot

   DB_TIME     DB_CPU    BG_TIME     BG_CPU
---------- ---------- ---------- ----------
 143522885  127634777    7381483    6340262
/code>

UNPIVOT では, PIVOT とは異なり, 実行計画上 UNPIVOT であることが読み取れます！！！　ここ試験に出ますよ！（嘘w

  1  SELECT
  2    stat_name
  3  , value
  4  FROM
  5    for_unpivot
  6  UNPIVOT
  7  (
  8    value FOR stat_name IN
  9    (
 10        db_time
 11      , db_cpu
 12      , bg_time
 13      , bg_cpu
 14    )
 15  )
 16* ORDER BY stat_name

STAT_NAME                           VALUE
------------------------------ ----------
BG_CPU                            6340262
BG_TIME                           7381483
DB_CPU                          127634777
DB_TIME                         143522885

実行計画
----------------------------------------------------------
Plan hash value: 3659757171

------------------------------------------------------------------------------------
| Id  | Operation            | Name        | Rows  | Bytes | Cost (%CPU)| Time     |
------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT     |             |     4 |    72 |     6  (17)| 00:00:01 |
|   1 |  SORT ORDER BY       |             |     4 |    72 |     6  (17)| 00:00:01 |
|*  2 |   VIEW               |             |     4 |    72 |     5   (0)| 00:00:01 |
|   3 |    UNPIVOT           |             |       |       |            |          |
|   4 |     TABLE ACCESS FULL| FOR_UNPIVOT |     1 |    26 |     3   (0)| 00:00:01 |
------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   2 - filter("unpivot_view_005"."VALUE" IS NOT NULL)

統計
----------------------------------------------------------
          0  recursive calls
          0  db block gets
          2  consistent gets
          0  physical reads
          0  redo size
        781  bytes sent via SQL*Net to client
         52  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          1  sorts (memory)
          0  sorts (disk)
          4  rows processed
/code>

ということで, 　Operation には, なぜ, UNPIVOT　は現れるのに, PIVOT が現れないのだろう. . . その謎を求め, 一向は洞窟の奥深くへ進んでいくのであった. . . .

昔からサポートされている PIVOT / UNPIVOT ですが, 改めて実行計画というレントゲンを診てみると, 新しい気づきとかあって良いですね.

参考 SQL Language Reference / PIVOT and UNPIVOT

Oracle Database 11g：Oracle ACEディレクター, Arup Nanda - PIVOT and UNPIVOT

ということで, 明日の担当は, またまた私ですw

投稿日時 2022年12月 5日 (月) 00時00分 Oracle, チューニング, SQL, Oracle Database 11g, Oracle Database 11g Release 2, Oracle Database 12c release 1, パフォーマンス, Advent Calendar, Oracle Database 12c Release 2, Oracle Database 18c, Oracle Database 19c, Oracle Database 21c | 固定リンク | 0 | コメント (0)

2022年4月 9日 (土)

実行計画は、SQL文のレントゲン写真だ！ No.34 - 似て非なるもの　USE_CONCAT　と　OR_EXPAND ヒントと　手書きSQLのレントゲンの見分け方

Previously on Mac De Oracle
前回のレントゲンは、BITMAP CONVERSION TO ROWIDSでした。複数の索引を同時に使うという昔からあるオペレーションでした。

今回は単にレントゲンを見ていくだけではなく、同じ問い合わせ結果（よくある間違いなどもいれてありますw）になるものの微妙に違うレントゲンをみつつ、元のSQL文、それに今回ヒントになにが使われているか、見ていきたいと思います。

これが前回のエントリで使ったSQL分です. 問い合わせ結果と実行計画（前回のエントリで取り上げたBITMAP CONVERSIONです。この問い合わせ結果と実行計画という名のレントゲンをよーーーーーーーーーく、覚えておいてくださいね。

いくつかのレントゲンを使って、これなーーーーーーーんだ？　wみたいなw

これが原型なので、覚えておいてください。

select
  *
from
  tab311
where
  unique_id= 1
  or sub_item_code = '0001000000';

UNIQUE_ID SUB_ITEM_CODE                  FOO                                                 IS_DELETE
---------- ------------------------------ -------------------------------------------------- ----------
         1 0000000002                     **************************************************          0
                                          **************************************************
                                          **************************************************
                                          **************************************************
                                          *************************************************1

         1 0001000001                     fooooooooooooo1                                             0
         2 0001000000                     fooooooo2                                                   0
         1 0001000000                     2****                                                       0

---------------------------------------------------------------------------------------------------------------
| Id  | Operation                           | Name                    | Rows  | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                    |                         |     5 |  1345 |     8  (13)| 00:00:01 |
|   1 |  TABLE ACCESS BY INDEX ROWID BATCHED| TAB311                  |     5 |  1345 |     8  (13)| 00:00:01 |
|   2 |   BITMAP CONVERSION TO ROWIDS       |                         |       |       |            |          |
|   3 |    BITMAP OR                        |                         |       |       |            |          |
|   4 |     BITMAP CONVERSION FROM ROWIDS   |                         |       |       |            |          |
|   5 |      SORT ORDER BY                  |                         |       |       |            |          |
|*  6 |       INDEX RANGE SCAN              | TAB311_PK               |       |       |     3   (0)| 00:00:01 |
|   7 |     BITMAP CONVERSION FROM ROWIDS   |                         |       |       |            |          |
|*  8 |      INDEX RANGE SCAN               | TAB311_IX_SUB_ITEM_CODE |       |       |     3   (0)| 00:00:01 |
---------------------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   6 - access("UNIQUE_ID"=1)
       filter("UNIQUE_ID"=1)
   8 - access("SUB_ITEM_CODE"='0001000000')

統計
----------------------------------------------------------
          0  recursive calls
          0  db block gets
          8  consistent gets
          0  physical reads
          0  redo size
       1248  bytes sent via SQL*Net to client
         52  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          1  sorts (memory)
          0  sorts (disk)
          4  rows processed

前回のエントリでも少し書いたのですが、CONCATENATION がレントゲンに現れるときは、BITMAP CONVERTなど効率が悪いOR条件の実行計画を改善するため、OR条件部分を分離排除し、2つの索引それぞれを有効に利用させるためのヒントによるチューニングで行なった場合が多いです。オプティマイザが選択するケースもありますが。

ヒントで強制的にすることもありますが、ヒントが効かないケースは多も多いのは事実です。理由は内部的に2つのクエリーに分解しているわけですが、それぞれで利用する索引のアクセス効率が悪いオプティマイザに見えている場合にはヒントが効かない場合が多いように思います。
なんとなーーーくざっくりなイメージですが、UNIONのような形に内部的に書き換えていると思うとわかりやすいかもしれないですね。。UNIONとでてないのでUNIONのようなものとしかかけないのですがW
とにかく、CONCATENATIONを見つけたら　USE_CONCAT ヒントでチューニングされてるね！
と脊髄反応できるようになっているとよいですね！

 UNIQUE_ID SUB_ITEM_CODE                  FOO                                                 IS_DELETE
---------- ------------------------------ -------------------------------------------------- ----------
         2 0001000000                     fooooooo2                                                   0
         1 0001000000                     2****                                                       0
         1 0000000002                     **************************************************          0
                                          **************************************************
                                          **************************************************
                                          **************************************************
                                          *************************************************1

         1 0001000001                     fooooooooooooo1                                             0

----------------------------------------------------------------------------------------------------------------
| Id  | Operation                            | Name                    | Rows  | Bytes | Cost (%CPU)| Time     |
----------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                     |                         |     5 |  1345 |    11   (0)| 00:00:01 |
|   1 |  CONCATENATION                       |                         |       |       |            |          |
|   2 |   TABLE ACCESS BY INDEX ROWID BATCHED| TAB311                  |     4 |  1076 |     7   (0)| 00:00:01 |
|*  3 |    INDEX RANGE SCAN                  | TAB311_IX_SUB_ITEM_CODE |     4 |       |     3   (0)| 00:00:01 |
|   4 |   TABLE ACCESS BY INDEX ROWID BATCHED| TAB311                  |     1 |   269 |     4   (0)| 00:00:01 |
|*  5 |    INDEX RANGE SCAN                  | TAB311_PK               |     1 |       |     3   (0)| 00:00:01 |
----------------------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   3 - access("SUB_ITEM_CODE"='0001000000')
   5 - access("UNIQUE_ID"=1)
       filter(LNNVL("SUB_ITEM_CODE"='0001000000'))

統計
----------------------------------------------------------
          0  recursive calls
          0  db block gets
         11  consistent gets
          0  physical reads
          0  redo size
       1228  bytes sent via SQL*Net to client
         52  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          4  rows processed

上記のレントゲンの元はこれです。USE_CONCATヒント使われてますよね。このケースではオプティマイザは言うことを聞いてくれたようですね。w

select
  /*+
    use_concat
  */
  *
from
  tab311
where
  unique_id= 1
  or sub_item_code = '0001000000';

では、オプティマイザが言うことを聞いてくれなかった場合、Oracle Database 12c R1まではどうやって、治療していたか。知りたく無いですか？
USE_CONCATでUNIONのように内部的書き換えてくれると、SQLへはヒントの追加だけで済むので、同値検証等も不要で患者さんの痛みは少なくてすむわけですが、先にも買いたように必ず効くわけでもないという、ちょっと癖のあるヒントなんです。で、12c R1までは、しかたないの、SQL構文変更という中程度の難易度の手術（SQL書き換えw）が必要でした。

先ほと、UNIONのようにと書きましたが、まさに、それで、UNIONまたは、UNION ALLに書き換えてしまうという手術ですw

どちらでやってもよいのですが、重複データの排除がどれだけの負荷になるかというところかなと思います。重複排除するデータ量が多いのであれば UNION にしてHASH UNIQUEによる重複行排除の方がよいかもしれませんし、少量なら UNION ALLでフィルタリングによる重複行排除のほうがよいかもしれません。HASH UNIQUEにしてもPGA不足でTEMP落ちしてしまうようなことがあるのならフィルタリングのほうがよさそうですし、その時の状況次第かと思います。

では、ずは、UNION を使った書き換えから。

ソートしていないので並びが変わってますが、あえてソートしていません。Id=2のUNION-ALLとId=1にHASH UNIQUEというoperationがありますが、これが現在のUNIONの典型的なoperationです。HASH UNIQUEがなかったころは、SORT UNIQUEだったわけですが、その影響でデータがソートされていたので、諸々勘違いしてデフォルトでソートされるんだー、みたいな勘違いしている方も一定数存在していた時期があり、HASH UNIQUEがなって順序通りになってない！　と勝手にザワザワしていたこともありましたね。それ知ってる方々はOracleにながーーーーいこと関わっている方だと思いますw　注意しましょうね。思った通りの並びにしたい場合は、ちゃんとORDER BY句でソートしましょうね。（これ言いたかっただけw）
あと、最近は、UNIONをパラレル実行できるようになったので、その場合も、順序はバラバラになります。シリアルに実行している場合は上位にあるクエリから処理されるのでその順序で行が戻されていましたが、パラレルだと何が来るかはその時々ですね。

脇道にそれましたが、手書きでSQLを UNION に書き換えた場合のレントゲンはこんな感じです。UNION-ALLのオペレーションの後に重複行排除のUNIQUE操作が必ず入るので覚えやすいと思います。

 UNIQUE_ID SUB_ITEM_CODE                  FOO                                                 IS_DELETE
---------- ------------------------------ -------------------------------------------------- ----------
         1 0000000002                     **************************************************          0
                                          **************************************************
                                          **************************************************
                                          **************************************************
                                          *************************************************1

         1 0001000000                     2****                                                       0
         1 0001000001                     fooooooooooooo1                                             0
         2 0001000000                     fooooooo2                                                   0

-----------------------------------------------------------------------------------------------------------------
| Id  | Operation                             | Name                    | Rows  | Bytes | Cost (%CPU)| Time     |
-----------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                      |                         |     5 |  1345 |    12   (9)| 00:00:01 |
|   1 |  HASH UNIQUE                          |                         |     5 |  1345 |    12   (9)| 00:00:01 |
|   2 |   UNION-ALL                           |                         |       |       |            |          |
|   3 |    TABLE ACCESS BY INDEX ROWID BATCHED| TAB311                  |     1 |   269 |     4   (0)| 00:00:01 |
|*  4 |     INDEX RANGE SCAN                  | TAB311_PK               |     1 |       |     3   (0)| 00:00:01 |
|   5 |    TABLE ACCESS BY INDEX ROWID BATCHED| TAB311                  |     4 |  1076 |     7   (0)| 00:00:01 |
|*  6 |     INDEX RANGE SCAN                  | TAB311_IX_SUB_ITEM_CODE |     4 |       |     3   (0)| 00:00:01 |
-----------------------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   4 - access("UNIQUE_ID"=1)
   6 - access("SUB_ITEM_CODE"='0001000000')

統計
----------------------------------------------------------
          0  recursive calls
          0  db block gets
          9  consistent gets
          0  physical reads
          0  redo size
       1225  bytes sent via SQL*Net to client
         52  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          4  rows processed

もともとOR条件でしたが、それぞれの索引を有効に活用させるため、2つの文に分解し、それらを UNIONしています。UNIONで重複排除も行なっているわけです。

select
  *
from
  tab311
where
  unique_id = 1
union
select
  *
 from
   tab311
 where
   sub_item_code = '0001000000';

次に、UNION ALLへ手動で書き換えた場合はどうなるかレントゲンを見てみましょう。

結果も正しいです。レントゲンで見える UNION と UNION-ALLとの違いは、重複行排除のUNIQUEオペレーションが無いところです。Id=1にあるUNION-ALL だけで、 HASH UNIQUEがありません。
これ大丈夫なのでしょうか？　重複行を排除するオペレーションがないなんで、たまため結果が正しいだけでしょうか？？？

実は、実行計画に現れない違いが述語部分にあります。 Predicate Information (identified by operation id):セクションに 4 - filter(LNNVL("UNIQUE_ID"=1)) とあるのに気づきましたか？

4は、実行計画の Id = 4を示しています。これは Id = 4の TAB311のアクセス時に、"UNIQUE_ID"=1　であれば falseとして該当行をフィルタリングして捨てていることを意味しています。
つまり、UNIONで　HASH UNIQUEを行なっていた重複行を排除と同様の効果をえるフィルター条件なんです。この条件にで、 Id = 2 と Id = 3で取得されたUNIQUE_ID=1の行を捨てています

 UNIQUE_ID SUB_ITEM_CODE                  FOO                                                 IS_DELETE
---------- ------------------------------ -------------------------------------------------- ----------
         1 0000000002                     **************************************************          0
                                          **************************************************
                                          **************************************************
                                          **************************************************
                                          *************************************************1

         1 0001000000                     2****                                                       0
         1 0001000001                     fooooooooooooo1                                             0
         2 0001000000                     fooooooo2                                                   0

----------------------------------------------------------------------------------------------------------------
| Id  | Operation                            | Name                    | Rows  | Bytes | Cost (%CPU)| Time     |
----------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                     |                         |     5 |  1345 |    11   (0)| 00:00:01 |
|   1 |  UNION-ALL                           |                         |       |       |            |          |
|   2 |   TABLE ACCESS BY INDEX ROWID BATCHED| TAB311                  |     1 |   269 |     4   (0)| 00:00:01 |
|*  3 |    INDEX RANGE SCAN                  | TAB311_PK               |     1 |       |     3   (0)| 00:00:01 |
|*  4 |   TABLE ACCESS BY INDEX ROWID BATCHED| TAB311                  |     4 |  1076 |     7   (0)| 00:00:01 |
|*  5 |    INDEX RANGE SCAN                  | TAB311_IX_SUB_ITEM_CODE |     4 |       |     3   (0)| 00:00:01 |
----------------------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   3 - access("UNIQUE_ID"=1)
   4 - filter(LNNVL("UNIQUE_ID"=1))
   5 - access("SUB_ITEM_CODE"='0001000000')

統計
----------------------------------------------------------
          0  recursive calls
          0  db block gets
         10  consistent gets
          0  physical reads
          0  redo size
       1225  bytes sent via SQL*Net to client
         52  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          4  rows processed

UNION ALLでの書き換えは、以下のようなSQL文でした。and LNNVL(unique_id=1)という条件追加がポイントです。

select
  *
from
  tab311
where
  unique_id = 1
union all
select
  *
from
  tab311
where
  sub_item_code = '0001000000'
  and LNNVL(unique_id=1);

では、つい忘れそうな、フィルター条件追加をわすれてUNION ALLにしてしまった場合はどうなるでしょう？　もう想像できますよねw

SQLの違いからみてみましょう。 and LNNVL(unique_id=1)　と言う条件が無いこと以外前述のSQLと同じです。

select
  *
from
  tab311
where
  unique_id = 1
union all
select
  *
from
  tab311
where
  sub_item_code = '0001000000';

実行してみると。。。。。あららららら、ちゃっしゃいましたな感じの結果ですねw Predicate Information (identified by operation id): には重複排除のフィルター条件は見当たりません。（当然ですね。書き忘れているわけですから）

UNIQUE_ID = 1　でもあり、SUB_ITEM_CODE = '0001000000' である行が2回リストされています。ざんねーーーん。注意しましょうね。

 UNIQUE_ID SUB_ITEM_CODE                  FOO                                                 IS_DELETE
---------- ------------------------------ -------------------------------------------------- ----------
         1 0000000002                     **************************************************          0
                                          **************************************************
                                          **************************************************
                                          **************************************************
                                          *************************************************1

         1 0001000000                     2****                                                       0
         1 0001000001                     fooooooooooooo1                                             0
         2 0001000000                     fooooooo2                                                   0
         1 0001000000                     2****                                                       0


----------------------------------------------------------------------------------------------------------------
| Id  | Operation                            | Name                    | Rows  | Bytes | Cost (%CPU)| Time     |
----------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                     |                         |     5 |  1345 |    11   (0)| 00:00:01 |
|   1 |  UNION-ALL                           |                         |       |       |            |          |
|   2 |   TABLE ACCESS BY INDEX ROWID BATCHED| TAB311                  |     1 |   269 |     4   (0)| 00:00:01 |
|*  3 |    INDEX RANGE SCAN                  | TAB311_PK               |     1 |       |     3   (0)| 00:00:01 |
|   4 |   TABLE ACCESS BY INDEX ROWID BATCHED| TAB311                  |     4 |  1076 |     7   (0)| 00:00:01 |
|*  5 |    INDEX RANGE SCAN                  | TAB311_IX_SUB_ITEM_CODE |     4 |       |     3   (0)| 00:00:01 |
----------------------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   3 - access("UNIQUE_ID"=1)
   5 - access("SUB_ITEM_CODE"='0001000000')

統計
----------------------------------------------------------
          0  recursive calls
          0  db block gets
         10  consistent gets
          0  physical reads
          0  redo size
       1239  bytes sent via SQL*Net to client
         52  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          5  rows processed

よーーーーし、バグになるのが怖いから、常に　UNION だーーーと安全策に流れそうですが、性能面ではフィルタリングと HASH UNIQUE、または、SORT UNIQUEかということであれば、データ量次第でどちらが良いか判断した方がよいだろうと。個人的には思っています。フィルターしたほうが有利なケースも当然ありますし、しないほうが良い場合もあるでしょう。

最後に、今日のタイトルにも書いた NO_EXPAND これ少々気難しい、USE_CONCATの後継として 12c R2　で登場したヒントです。内部の書き換えもそれまでのCONCATENATIONではなく、UNION　ALLとフィルタリングにより重複行排除が行われるように、内部的に書き換えられるのが特徴です。なんでこれもっと早く実装してくれなかったんですかね？　強強ですね。USE_CONCATの気まぐれ感は消えてる感じがします。

事実、某所で、USE_CONCAT効かなくて、しぬーーーーーみたいな状況で、たまたま 12c R2だったので、NO_EXPAND　で回避したーーーーなんてこともありました。そういことで、USE_EXPANDをUSE_CONCATの代わりにUSE_EXPANDを使うことをおすすめしますw　（それ以外にもメリットも多いですし、それはまた、次回にでも）

select
  /*+
    or_expand
  */
  *
from
  tab311
where
  unique_id= 1
  or sub_item_code = '0001000000';

 UNIQUE_ID SUB_ITEM_CODE                  FOO                                                 IS_DELETE
---------- ------------------------------ -------------------------------------------------- ----------
         1 0000000002                     **************************************************          0
                                          **************************************************
                                          **************************************************
                                          **************************************************
                                          *************************************************1

         1 0001000000                     2****                                                       0
         1 0001000001                     fooooooooooooo1                                             0
         2 0001000000                     fooooooo2                                                   0

レントゲンを見ると、手書きで書いた UNION ALLへの書き換えと微妙に違うの気づきますか？　これまで紹介してきた手書きでの書き換えとヒントに夜書き換えは4つありますが、それぞれ実行計画に特徴があるんです。（もしかしたら将来は区別しにくくなるかもしれませんが、現状は区別できます！！！

OR_EXPANヒントでUNION ALL変換した場合 Id = 1にあるような、インラインビューがは登場します。VW_ORE_5F0E22D2　とオプティマイザが動的に名称をつけますが、ポイントは　VW_ORE_* というprefixが作ろころですね。VWはびゅー。OREは、OR_Expand の大文字部分みたいですねw　（そのうち内部的に生成されるインラインビュー名もまとめて紹介したいですね。すでに誰かやってそうな気もしますがw）

実行計画
----------------------------------------------------------
Plan hash value: 3148130991

-----------------------------------------------------------------------------------------------------------------
| Id  | Operation                             | Name                    | Rows  | Bytes | Cost (%CPU)| Time     |
-----------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                      |                         |     5 |  1450 |    11   (0)| 00:00:01 |
|   1 |  VIEW                                 | VW_ORE_5F0E22D2         |     5 |  1450 |    11   (0)| 00:00:01 |
|   2 |   UNION-ALL                           |                         |       |       |            |          |
|   3 |    TABLE ACCESS BY INDEX ROWID BATCHED| TAB311                  |     1 |   269 |     4   (0)| 00:00:01 |
|*  4 |     INDEX RANGE SCAN                  | TAB311_PK               |     1 |       |     3   (0)| 00:00:01 |
|*  5 |    TABLE ACCESS BY INDEX ROWID BATCHED| TAB311                  |     4 |  1076 |     7   (0)| 00:00:01 |
|*  6 |     INDEX RANGE SCAN                  | TAB311_IX_SUB_ITEM_CODE |     4 |       |     3   (0)| 00:00:01 |
-----------------------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   4 - access("UNIQUE_ID"=1)
   5 - filter(LNNVL("UNIQUE_ID"=1))
   6 - access("SUB_ITEM_CODE"='0001000000')

統計
----------------------------------------------------------
          0  recursive calls
          0  db block gets
         10  consistent gets
          0  physical reads
          0  redo size
       1225  bytes sent via SQL*Net to client
         52  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          4  rows processed

長くなったので、まとめです。
ヒントによる OR条件のUNIONのような書き換えや、UNION ALLへの書き換え、または、人が UNION や UNION ALLへ手書きで書き換えたSQLのレントゲン、それぞれに特徴があり、4つとも、レントゲンから元のSQLがイメージできるんですよ！！！

USE_CONCATによる書き換え Oracle 8i 8.1以降〜

select
  /*+
    use_concat
  */
  *
from
  tab311
where
  unique_id= 1
  or sub_item_code = '0001000000';

----------------------------------------------------------------------------------------------------------------
| Id  | Operation                            | Name                    | Rows  | Bytes | Cost (%CPU)| Time     |
----------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                     |                         |     5 |  1345 |    11   (0)| 00:00:01 |
|   1 |  CONCATENATION                       |                         |       |       |            |          |
|   2 |   TABLE ACCESS BY INDEX ROWID BATCHED| TAB311                  |     4 |  1076 |     7   (0)| 00:00:01 |
|*  3 |    INDEX RANGE SCAN                  | TAB311_IX_SUB_ITEM_CODE |     4 |       |     3   (0)| 00:00:01 |
|   4 |   TABLE ACCESS BY INDEX ROWID BATCHED| TAB311                  |     1 |   269 |     4   (0)| 00:00:01 |
|*  5 |    INDEX RANGE SCAN                  | TAB311_PK               |     1 |       |     3   (0)| 00:00:01 |
----------------------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   3 - access("SUB_ITEM_CODE"='0001000000')
   5 - access("UNIQUE_ID"=1)
       filter(LNNVL("SUB_ITEM_CODE"='0001000000'))

OR_EXPANDによる書き換え Oracle 12cR2以降〜

select
  /*+
    or_expand
  */
  *
from
  tab311
where
  unique_id= 1
  or sub_item_code = '0001000000';

-----------------------------------------------------------------------------------------------------------------
| Id  | Operation                             | Name                    | Rows  | Bytes | Cost (%CPU)| Time     |
-----------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                      |                         |     5 |  1450 |    11   (0)| 00:00:01 |
|   1 |  VIEW                                 | VW_ORE_5F0E22D2         |     5 |  1450 |    11   (0)| 00:00:01 |
|   2 |   UNION-ALL                           |                         |       |       |            |          |
|   3 |    TABLE ACCESS BY INDEX ROWID BATCHED| TAB311                  |     1 |   269 |     4   (0)| 00:00:01 |
|*  4 |     INDEX RANGE SCAN                  | TAB311_PK               |     1 |       |     3   (0)| 00:00:01 |
|*  5 |    TABLE ACCESS BY INDEX ROWID BATCHED| TAB311                  |     4 |  1076 |     7   (0)| 00:00:01 |
|*  6 |     INDEX RANGE SCAN                  | TAB311_IX_SUB_ITEM_CODE |     4 |       |     3   (0)| 00:00:01 |
-----------------------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   4 - access("UNIQUE_ID"=1)
   5 - filter(LNNVL("UNIQUE_ID"=1))
   6 - access("SUB_ITEM_CODE"='0001000000')

手動書き換え　UNION

select
  *
from
  tab311
where
  unique_id = 1
union
select
  *
 from
   tab311
 where
   sub_item_code = '0001000000';

-----------------------------------------------------------------------------------------------------------------
| Id  | Operation                             | Name                    | Rows  | Bytes | Cost (%CPU)| Time     |
-----------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                      |                         |     5 |  1345 |    12   (9)| 00:00:01 |
|   1 |  HASH UNIQUE                          |                         |     5 |  1345 |    12   (9)| 00:00:01 |
|   2 |   UNION-ALL                            |                         |       |       |            |          |
|   3 |    TABLE ACCESS BY INDEX ROWID BATCHED| TAB311                  |     1 |   269 |     4   (0)| 00:00:01 |
|*  4 |     INDEX RANGE SCAN                  | TAB311_PK               |     1 |       |     3   (0)| 00:00:01 |
|   5 |    TABLE ACCESS BY INDEX ROWID BATCHED| TAB311                  |     4 |  1076 |     7   (0)| 00:00:01 |
|*  6 |     INDEX RANGE SCAN                  | TAB311_IX_SUB_ITEM_CODE |     4 |       |     3   (0)| 00:00:01 |
-----------------------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   4 - access("UNIQUE_ID"=1)
   6 - access("SUB_ITEM_CODE"='0001000000')

手動書き換え　UNION ALL + 重複排除フィルター条件追加

select
  *
from
  tab311
where
  unique_id = 1
union all
select
  *
from
  tab311
where
  sub_item_code = '0001000000'
  and LNNVL(unique_id=1);

----------------------------------------------------------------------------------------------------------------
| Id  | Operation                            | Name                    | Rows  | Bytes | Cost (%CPU)| Time     |
----------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                     |                         |     5 |  1345 |    11   (0)| 00:00:01 |
|   1 |  UNION-ALL                           |                         |       |       |            |          |
|   2 |   TABLE ACCESS BY INDEX ROWID BATCHED| TAB311                  |     1 |   269 |     4   (0)| 00:00:01 |
|*  3 |    INDEX RANGE SCAN                  | TAB311_PK               |     1 |       |     3   (0)| 00:00:01 |
|*  4 |   TABLE ACCESS BY INDEX ROWID BATCHED| TAB311                  |     4 |  1076 |     7   (0)| 00:00:01 |
|*  5 |    INDEX RANGE SCAN                  | TAB311_IX_SUB_ITEM_CODE |     4 |       |     3   (0)| 00:00:01 |
----------------------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   3 - access("UNIQUE_ID"=1)
   4 - filter(LNNVL("UNIQUE_ID"=1))
   5 - access("SUB_ITEM_CODE"='0001000000')

レントゲンから諸々読み取るスキルは大切だと思っているので、みんなもレントゲンというなの実行計画は読んでみるといいよーーーっ。おすすめ。

では、次回へつづく

投稿日時 2022年4月 9日 (土) 16時19分 Oracle, チューニング, SQL, Oracle Database 11g, Oracle Database 11g Release 2, Oracle Database 12c release 1, パフォーマンス, Oracle Database 12c Release 2, Oracle Database 18c, Oracle Database 19c, Oracle Database 21c | 固定リンク | 0 | コメント (0)

2022年4月 7日 (木)

実行計画は、SQL文のレントゲン写真だ！ No.33 - BITMAP CONVERSION TO ROWIDS

Previously on Mac De Oracle
前回は外部表特有のoperationであるEXTERNAL TABLE ACCESS FULL / INMEMORY FULL のレントゲンでした。

今日は、昔からあるBITMAP CONVERSION TO ROWIDSを見てみたいと思います。

SQLチューニング・ガイド 8.4.2 ビットマップのROWIDへの変換
SQLチューニング・ガイド 8.4.2 ビットマップのROWIDへの変換 / 21c

このオペレーションは、複数の索引からbitmapを生成しその結果のrowidを用いて表をアクセスするところにあります。通常一つの索引が利用されますが、この場合は複数の索引が利用されるところが特徴です。
ただ、bitmapに変換コストより、unionに書き換えたり（内部的な書き換えも含む）したほうが効率が良かったりします。なので意外と嫌われてたりw　なので、STAR TRANSFORM などで見るぐららいで、結構それ以外の方向へチューニングされているケースのほうが多いかもしれません。でもこれで問題なければそのままでも問題はないわけですが。

あ、そういえば、以前、CONCATENATIONのレントゲンを紹介していましたね。
ちょうどよいので、CONCATENATIONのレントゲン撮影時と同じ表とSQL文を使って BITMAP CONVERSION TO ROWIDS のレントゲンを見てみましょう :)

SCOTT@orclpdb1> desc tab311
名前                                    NULL?    型
----------------------------------------- -------- ----------------------------
UNIQUE_ID                                 NOT NULL NUMBER(10)
SUB_ITEM_CODE                             NOT NULL CHAR(10)
FOO                                       NOT NULL VARCHAR2(500)
IS_DELETE                                 NOT NULL NUMBER(1)

SCOTT@orclpdb1> select count(1) from tab311

COUNT(1)
----------
2000000

経過: 00:00:00.09

実行計画を見てわかると思いますが、　2つの索引(TAB311_PK, TAB311_IX_SUB_ITEM_CODE)のROWIDからBITMAPを作り(Id=3,7)、それを BITMAP OR (SQL文の7行目 Id=3)した結果をROWIDへ変換(Id=2)、複数のROWIDをまとめ、IOリクエストを少なくするための ROWID BATCHED(Id=1)で表(TAB311)をアクセスしていことが読み取れます。
ROWIDでアクセスするので、基本的に少量の行にアクセスする場合には有利ではあります。ただ、BITMAPへの変換コスト次第というところではあるわけです。なので、BITMAPの変換のないタイプのトランスフォームを狙ったHINTを利用したり、SQL文自体を書き換えたりするケースは少なくありません。意外に嫌いな方が多くてw　大抵チューニングされてしまい、あまり見かけることはないかもしれませんw　

SCOTT@orclpdb1> r
  1  select
  2    *
  3  from
  4    tab311
  5  where
  6    unique_id= 1
  7*   or sub_item_code = '0001000000'

経過: 00:00:00.01

実行計画
----------------------------------------------------------
Plan hash value: 1263461875

---------------------------------------------------------------------------------------------------------------
| Id  | Operation                           | Name                    | Rows  | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                    |                         |     5 |  1345 |     8  (13)| 00:00:01 |
|   1 |  TABLE ACCESS BY INDEX ROWID BATCHED| TAB311                  |     5 |  1345 |     8  (13)| 00:00:01 |
|   2 |   BITMAP CONVERSION TO ROWIDS       |                         |       |       |            |          |
|   3 |    BITMAP OR                        |                         |       |       |            |          |
|   4 |     BITMAP CONVERSION FROM ROWIDS   |                         |       |       |            |          |
|   5 |      SORT ORDER BY                  |                         |       |       |            |          |
|*  6 |       INDEX RANGE SCAN              | TAB311_PK               |       |       |     3   (0)| 00:00:01 |
|   7 |     BITMAP CONVERSION FROM ROWIDS   |                         |       |       |            |          |
|*  8 |      INDEX RANGE SCAN               | TAB311_IX_SUB_ITEM_CODE |       |       |     3   (0)| 00:00:01 |
---------------------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   6 - access("UNIQUE_ID"=1)
       filter("UNIQUE_ID"=1)
   8 - access("SUB_ITEM_CODE"='0001000000')

統計
----------------------------------------------------------
          0  recursive calls
          0  db block gets
          7  consistent gets
          0  physical reads
          0  redo size
       1103  bytes sent via SQL*Net to client
         52  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          1  sorts (memory)
          0  sorts (disk)
          1  rows processed

ちなみに、CONCATENATIONのエントリーを見ていただくのがよいとは思いますが、これも比較的古くからある、CONCATENATIONを使ったSQL変換のレントゲンも改めて載せておきます。
（USE_CONCATヒントで強制しています。みなさん、知っているとは思いますが、NO_EXPANDヒントが逆のヒントです）

実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 Day 17 / CONCATENATION
UNION のような実行計画ですが、UNIONとは出てませんw　これはまた別の機会に。ただ、ほぼ同等の意味で、OR条件でそれぞれに最適な索引を使うことでindex range scanやindex unique scanを効かせて高速にアクセスしようとしています。
BITMAPとの相互変換などが無い分、安定して早いケースは経験的にも多いのは確かです。どちらを選ぶかはやはり、登録されているデータの傾向と検索条件次第ではあります。ただ一般的BITMAP変換を避ける傾向が強いのは確かではありますね。

SCOTT@orclpdb1> r
  1  select
  2    /*+
  3       use_concat
  4    */
  5    *
  6  from
  7    tab311
  8  where
  9    unique_id= 1
 10*   or sub_item_code = '0001000000'

経過: 00:00:00.00

実行計画
----------------------------------------------------------
Plan hash value: 1344230703

----------------------------------------------------------------------------------------------------------------
| Id  | Operation                            | Name                    | Rows  | Bytes | Cost (%CPU)| Time     |
----------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                     |                         |     5 |  1345 |    11   (0)| 00:00:01 |
|   1 |  CONCATENATION                       |                         |       |       |            |          |
|   2 |   TABLE ACCESS BY INDEX ROWID BATCHED| TAB311                  |     4 |  1076 |     7   (0)| 00:00:01 |
|*  3 |    INDEX RANGE SCAN                  | TAB311_IX_SUB_ITEM_CODE |     4 |       |     3   (0)| 00:00:01 |
|   4 |   TABLE ACCESS BY INDEX ROWID BATCHED| TAB311                  |     1 |   269 |     4   (0)| 00:00:01 |
|*  5 |    INDEX RANGE SCAN                  | TAB311_PK               |     1 |       |     3   (0)| 00:00:01 |
----------------------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   3 - access("SUB_ITEM_CODE"='0001000000')
   5 - access("UNIQUE_ID"=1)
       filter(LNNVL("SUB_ITEM_CODE"='0001000000'))


統計
----------------------------------------------------------
          0  recursive calls
          0  db block gets
          8  consistent gets
          0  physical reads
          0  redo size
       1091  bytes sent via SQL*Net to client
         52  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          1  rows processed

GWも間近だ。そろそろ予定考えないとな。その前にACEのKPIはクリアしておかないと。追い込み追い込みw

ということで、次回へつづく。

投稿日時 2022年4月 7日 (木) 21時21分 Oracle, チューニング, FAQ, SQL, Oracle Database 11g, Oracle Database 11g Release 2, Oracle Database 12c release 1, パフォーマンス, Oracle Database 12c Release 2, Oracle Database 18c, Oracle Database 19c, Oracle Database 21c | 固定リンク | 0 | コメント (0)

2022年3月26日 (土)

実行計画は、SQL文のレントゲン写真だ！ No.31 - TEMP TABLE TRANSFORMATION LOAD AS SELECT (CURSOR DURATION MEMORY)

さて、実行計画のバリエーションの数だけ、レントゲンはありますよー（まだネタには余裕があるw）

ということで、今回は、12c前後で変化したところを見ておきたいと思います。

タイトルにも書いた

TEMP TABLE TRANSFORMATION
  LOAD AS SELECT (CURSOR DURATION MEMORY)

は、12c以降のリリースから見られるWITH CTEで繰り返し利用されることが自明で性能改善につながると想定される場合に、一時表にマテリアライズされたときのオペレーションですよね。
（みなさんご存知だとおもいます。

12c以降のリリースしか利用したことのない方は、気づかないと思いますが、11gまで少々違いました。

TEMP TABLE TRANSFORMATION
　　LOAD AS SELECT

違いといっても、CURSOR DURATION MEMORY があるかないかなのですがw、細かい改善の一つでだよね。と。

ちょうど良いネタなので、昨年末のAdvent CalendarのSQL文と実行計画でバージョン間のレントゲン写真の差を確認しておきましょう:)

まず、一つまえの 19cから。
Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production

Id=2のオペレーションは、LOAD AS SELECT (CURSOR DURATION MEMORY)　ですね。

もう一点、Predicate Informationセクションには、/*+ CACHE ("T1") */　というヒントが内部的に利用されていますね。ふーむ。
また、アダプティブな挙動もレポートされていないようですね。計画自体もindex only scanですし、まあ、想定通りというところですね。

参考までに、OPTIMIZER_DYNAMIC_SAMPLING = 2 と。デフォルトのままです。

CURSOR DURATION MEMORYの挙動については、
SQLチューニング・ガイド cursor-duration一時表

にあるように、シリアル実行では、PGAを利用するようですね。パラレルだと違うのか... でいずれもメモリ上に乗らなくなると、一時セグメントがストレージ上に確保されると記載されているのでTEMP表領域が利用されそうですね。
メモリに余裕があり、かつ、繰り返し参照されるケースでは効果はありそうですよね。ストレージに落ちてしまうと、direct path read from tempが発生するでしょうし、ストレージを繰り返しアクセスするかしないかの違いは大きいかも。
とはいえ、WITH句のCTEで性能改善を狙うケースでポイントになるところは同じなので、その点は忘れないようにしておきたいところですね。（例外は巨大なSQLで可読性向上を目的とした場合ぐらい）

Execution Plan
----------------------------------------------------------
Plan hash value: 3964084889

----------------------------------------------------------------------------------------------------------------------
| Id  | Operation                                | Name                      | Rows  | Bytes | Cost (%CPU)| Time     |
----------------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                         |                           |     7 |   553 |    12   (0)| 00:00:01 |
|   1 |  TEMP TABLE TRANSFORMATION               |                           |       |       |            |          |
|   2 |   LOAD AS SELECT (CURSOR DURATION MEMORY)| SYS_TEMP_0FD9D6640_6FF953 |       |       |            |          |
|   3 |    WINDOW SORT                           |                           |     7 |   119 |     8   (0)| 00:00:01 |
|   4 |     NESTED LOOPS                         |                           |     7 |   119 |     8   (0)| 00:00:01 |
|   5 |      NESTED LOOPS                        |                           |     7 |    77 |     4   (0)| 00:00:01 |
|   6 |       INDEX FULL SCAN                    | SYS_C0012896              |     4 |    24 |     1   (0)| 00:00:01 |
|*  7 |       INDEX FAST FULL SCAN               | SYS_C0012900              |     2 |    10 |     1   (0)| 00:00:01 |
|*  8 |      INDEX FAST FULL SCAN                | SYS_C0012898              |     1 |     6 |     1   (0)| 00:00:01 |
|   9 |   LOAD AS SELECT (CURSOR DURATION MEMORY)| SYS_TEMP_0FD9D6641_6FF953 |       |       |            |          |
|  10 |    WINDOW SORT                           |                           |     7 |   371 |     2   (0)| 00:00:01 |
|* 11 |     FILTER                               |                           |       |       |            |          |
|  12 |      VIEW                                |                           |     7 |   371 |     2   (0)| 00:00:01 |
|  13 |       TABLE ACCESS FULL                  | SYS_TEMP_0FD9D6640_6FF953 |     7 |   119 |     2   (0)| 00:00:01 |
|* 14 |      VIEW                                |                           |     7 |   210 |     2   (0)| 00:00:01 |
|  15 |       TABLE ACCESS FULL                  | SYS_TEMP_0FD9D6640_6FF953 |     7 |   119 |     2   (0)| 00:00:01 |
|* 16 |      VIEW                                |                           |     7 |   210 |     2   (0)| 00:00:01 |
|  17 |       TABLE ACCESS FULL                  | SYS_TEMP_0FD9D6640_6FF953 |     7 |   119 |     2   (0)| 00:00:01 |
|  18 |   VIEW                                   |                           |     7 |   553 |     2   (0)| 00:00:01 |
|  19 |    WINDOW SORT                           |                           |     7 |   371 |     2   (0)| 00:00:01 |
|* 20 |     FILTER                               |                           |       |       |            |          |
|  21 |      VIEW                                |                           |     7 |   371 |     2   (0)| 00:00:01 |
|  22 |       TABLE ACCESS FULL                  | SYS_TEMP_0FD9D6641_6FF953 |     7 |   217 |     2   (0)| 00:00:01 |
|* 23 |      VIEW                                |                           |     1 |    30 |     1   (0)| 00:00:01 |
|  24 |       TABLE ACCESS FULL                  | SYS_TEMP_0FD9D6641_6FF953 |     7 |   217 |     2   (0)| 00:00:01 |
|* 25 |      VIEW                                |                           |     1 |    30 |     1   (0)| 00:00:01 |
|  26 |       TABLE ACCESS FULL                  | SYS_TEMP_0FD9D6641_6FF953 |     7 |   217 |     2   (0)| 00:00:01 |
----------------------------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   7 - filter("NAME"='Scott' AND "ANIMALS"."KIND"='Snake' OR "NAME"='Steve' AND "ANIMALS"."KIND"<>'Dog' AND
              "ANIMALS"."KIND"<>'Snake' OR "NAME"='Hiro' AND "ANIMALS"."KIND"<>'Turtle' AND "ANIMALS"."KIND"<>'Snake' OR
              "NAME"='Larry' AND "ANIMALS"."KIND"<>'Snake')
   8 - filter(("OWNERS"."NAME"='Hiro' AND "PETS"."NAME"='Tiger' OR "OWNERS"."NAME"<>'Hiro' AND
              "PETS"."NAME"<>'Tiger') AND ("NAME"='Wendy' AND "KIND"='Dog' OR "NAME"='Tiger' AND "KIND"<>'Dog' AND
              "KIND"<>'Turtle' OR "NAME"='Lisa' AND "KIND"<>'Snake' AND "KIND"<>'Dog' OR "NAME"='Taro' AND "KIND"<>'Dog'))
  11 - filter("NUM_OF_ROWS"=1 OR "NUM_OF_ROWS">1 AND  NOT EXISTS (SELECT 0 FROM  (SELECT /*+ CACHE ("T1") */
              "C0" "NUM_OF_ROWS","C1" "OWNER_NAME","C2" "PET_NAME","C3" "ANIMAL_KIND" FROM
              "SYS"."SYS_TEMP_0FD9D6640_6FF953" "T1") "UNKNOWN_PET_OWNERS" WHERE "PET_NAME"=:B1 AND "NUM_OF_ROWS"=1) AND
              NOT EXISTS (SELECT 0 FROM  (SELECT /*+ CACHE ("T1") */ "C0" "NUM_OF_ROWS","C1" "OWNER_NAME","C2"
              "PET_NAME","C3" "ANIMAL_KIND" FROM "SYS"."SYS_TEMP_0FD9D6640_6FF953" "T1") "UNKNOWN_PET_OWNERS" WHERE
              "ANIMAL_KIND"=:B2 AND "NUM_OF_ROWS"=1))
  14 - filter("PET_NAME"=:B1 AND "NUM_OF_ROWS"=1)
  16 - filter("ANIMAL_KIND"=:B1 AND "NUM_OF_ROWS"=1)
  20 - filter("NUM_OF_ROWS"=1 OR "NUM_OF_ROWS">1 AND  NOT EXISTS (SELECT 0 FROM  (SELECT /*+ CACHE ("T1") */
              "C0" "NUM_OF_ROWS","C1" "OWNER_NAME","C2" "PET_NAME","C3" "ANIMAL_KIND" FROM
              "SYS"."SYS_TEMP_0FD9D6641_6FF953" "T1") "TEMP_PET_OWNERS" WHERE "PET_NAME"=:B1 AND "NUM_OF_ROWS"=1) AND  NOT
              EXISTS (SELECT 0 FROM  (SELECT /*+ CACHE ("T1") */ "C0" "NUM_OF_ROWS","C1" "OWNER_NAME","C2" "PET_NAME","C3"
              "ANIMAL_KIND" FROM "SYS"."SYS_TEMP_0FD9D6641_6FF953" "T1") "TEMP_PET_OWNERS" WHERE "ANIMAL_KIND"=:B2 AND

              "NUM_OF_ROWS"=1))
  23 - filter("PET_NAME"=:B1 AND "NUM_OF_ROWS"=1)
  25 - filter("ANIMAL_KIND"=:B1 AND "NUM_OF_ROWS"=1)

Statistics
----------------------------------------------------------
          0  recursive calls
          0  db block gets
         49  consistent gets
          0  physical reads
          0  redo size
        922  bytes sent via SQL*Net to client
       2090  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          3  sorts (memory)
          0  sorts (disk)
          4  rows processed

では次、12R1の場合です。(12R2は19cと同じなので省略)
Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production

基本的にデフォルト設定のままなので、　OPTIMIZER_DYNAMIC_SAMPLING = 2　でもろもろ止めたりしていませんw

12cR2以降との違いの１つめ！
12cR1では、CURSOR DURATION MEMORY　オペレーションがありません！！　

12cR2以降との違いの２つめ！
/*+ CACHE ("T1") */ではなく、/*+ CACHE_TEMP_TABLE ("T1") */　という一時表専用のヒントが担っている点。
CACHE_TEMP_TABLEヒントって解説がないヒントなのですが、12cR2以降はCACHEヒントという解説のある通常の表と同じヒントに置き換えられいますね。一時表だけ特別なわけではないので統一したのでしょうか（中の人のみぞ知るw）

Note部分にもでてますが、動的統計とプランディレクティブが動いてますね。再起コールが減らないのもその影響のようです。19cの挙動とは興味深い違いですね。データ量が多くなった場合にどう変化するのかなという気はしますがw

ちなみに、この挙動は、11cR2とくらべて、プランディレクティブが無い以外の挙動は同じ。

Execution Plan
----------------------------------------------------------
Plan hash value: 3787387246

--------------------------------------------------------------------------------------------------------
| Id  | Operation                  | Name                      | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT           |                           |     7 |   448 |    13   (8)| 00:00:01 |
|   1 |  TEMP TABLE TRANSFORMATION |                           |       |       |            |          |
|   2 |   LOAD AS SELECT           | SYS_TEMP_0FD9D6647_566AED |       |       |            |          |
|   3 |    WINDOW SORT             |                           |     8 |   136 |     8   (0)| 00:00:01 |
|   4 |     NESTED LOOPS           |                           |     8 |   136 |     8   (0)| 00:00:01 |
|   5 |      NESTED LOOPS          |                           |     8 |    88 |     4   (0)| 00:00:01 |
|   6 |       INDEX FULL SCAN      | SYS_C0014925              |     4 |    24 |     1   (0)| 00:00:01 |
|*  7 |       INDEX FAST FULL SCAN | SYS_C0014929              |     2 |    10 |     1   (0)| 00:00:01 |
|*  8 |      INDEX FAST FULL SCAN  | SYS_C0014927              |     1 |     6 |     1   (0)| 00:00:01 |
|   9 |   LOAD AS SELECT           | SYS_TEMP_0FD9D6648_566AED |       |       |            |          |
|  10 |    WINDOW SORT             |                           |     7 |   371 |     2   (0)| 00:00:01 |
|* 11 |     FILTER                 |                           |       |       |            |          |
|  12 |      VIEW                  |                           |     7 |   371 |     2   (0)| 00:00:01 |
|  13 |       TABLE ACCESS FULL    | SYS_TEMP_0FD9D6647_566AED |     7 |   119 |     2   (0)| 00:00:01 |
|* 14 |      VIEW                  |                           |     1 |    30 |     1   (0)| 00:00:01 |
|  15 |       TABLE ACCESS FULL    | SYS_TEMP_0FD9D6647_566AED |     7 |   119 |     2   (0)| 00:00:01 |
|* 16 |      VIEW                  |                           |     1 |    30 |     1   (0)| 00:00:01 |
|  17 |       TABLE ACCESS FULL    | SYS_TEMP_0FD9D6647_566AED |     7 |   119 |     2   (0)| 00:00:01 |
|  18 |   SORT ORDER BY            |                           |     7 |   448 |     3  (34)| 00:00:01 |
|* 19 |    FILTER                  |                           |       |       |            |          |
|  20 |     VIEW                   |                           |     7 |   448 |     2   (0)| 00:00:01 |
|  21 |      TABLE ACCESS FULL     | SYS_TEMP_0FD9D6648_566AED |     7 |   217 |     2   (0)| 00:00:01 |
|* 22 |     VIEW                   |                           |     7 |   210 |     2   (0)| 00:00:01 |
|  23 |      TABLE ACCESS FULL     | SYS_TEMP_0FD9D6648_566AED |     7 |   217 |     2   (0)| 00:00:01 |
|* 24 |     VIEW                   |                           |     7 |   210 |     2   (0)| 00:00:01 |
|  25 |      TABLE ACCESS FULL     | SYS_TEMP_0FD9D6648_566AED |     7 |   217 |     2   (0)| 00:00:01 |


--------------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   7 - filter("OWNERS"."NAME"='Scott' AND "ANIMALS"."KIND"='Snake' OR "OWNERS"."NAME"='Steve'
              AND "ANIMALS"."KIND"<>'Dog' AND "ANIMALS"."KIND"<>'Snake' OR "OWNERS"."NAME"='Hiro' AND
              "ANIMALS"."KIND"<>'Turtle' AND "ANIMALS"."KIND"<>'Snake' OR "OWNERS"."NAME"='Larry' AND
              "ANIMALS"."KIND"<>'Snake')
   8 - filter(("OWNERS"."NAME"='Hiro' AND "PETS"."NAME"='Tiger' OR "OWNERS"."NAME"<>'Hiro' AND
              "PETS"."NAME"<>'Tiger') AND ("PETS"."NAME"='Wendy' AND "ANIMALS"."KIND"='Dog' OR
              "PETS"."NAME"='Tiger' AND "ANIMALS"."KIND"<>'Dog' AND "ANIMALS"."KIND"<>'Turtle' OR
              "PETS"."NAME"='Lisa' AND "ANIMALS"."KIND"<>'Snake' AND "ANIMALS"."KIND"<>'Dog' OR
              "PETS"."NAME"='Taro' AND "ANIMALS"."KIND"<>'Dog'))
  11 - filter("NUM_OF_ROWS"=1 OR "NUM_OF_ROWS">1 AND  NOT EXISTS (SELECT 0 FROM  (SELECT /*+
              CACHE_TEMP_TABLE ("T1") */ "C0" "NUM_OF_ROWS","C1" "OWNER_NAME","C2" "PET_NAME","C3"
              "ANIMAL_KIND" FROM "SYS"."SYS_TEMP_0FD9D6647_566AED" "T1") "PET_OWNER_UNKNOWN" WHERE
              "PET_NAME"=:B1 AND "NUM_OF_ROWS"=1) AND  NOT EXISTS (SELECT 0 FROM  (SELECT /*+
              CACHE_TEMP_TABLE ("T1") */ "C0" "NUM_OF_ROWS","C1" "OWNER_NAME","C2" "PET_NAME","C3"
              "ANIMAL_KIND" FROM "SYS"."SYS_TEMP_0FD9D6647_566AED" "T1") "PET_OWNER_UNKNOWN" WHERE
              "ANIMAL_KIND"=:B2 AND "NUM_OF_ROWS"=1))
  14 - filter("PET_NAME"=:B1 AND "NUM_OF_ROWS"=1)
  16 - filter("ANIMAL_KIND"=:B1 AND "NUM_OF_ROWS"=1)
  19 - filter("NUM_OF_ROWS"=1 OR "NUM_OF_ROWS">1 AND  NOT EXISTS (SELECT 0 FROM  (SELECT /*+
              CACHE_TEMP_TABLE ("T1") */ "C0" "NUM_OF_ROWS","C1" "OWNER_NAME","C2" "PET_NAME","C3"
              "ANIMAL_KIND" FROM "SYS"."SYS_TEMP_0FD9D6648_566AED" "T1") "PET_OWNERS" WHERE "PET_NAME"=:B1
              AND "NUM_OF_ROWS"=1) AND  NOT EXISTS (SELECT 0 FROM  (SELECT /*+ CACHE_TEMP_TABLE ("T1") */
              "C0" "NUM_OF_ROWS","C1" "OWNER_NAME","C2" "PET_NAME","C3" "ANIMAL_KIND" FROM
              "SYS"."SYS_TEMP_0FD9D6648_566AED" "T1") "PET_OWNERS" WHERE "ANIMAL_KIND"=:B2 AND
              "NUM_OF_ROWS"=1))
  22 - filter("PET_NAME"=:B1 AND "NUM_OF_ROWS"=1)
  24 - filter("ANIMAL_KIND"=:B1 AND "NUM_OF_ROWS"=1)

Note
-----
   - dynamic statistics used: dynamic sampling (level=2)
   - 5 Sql Plan Directives used for this statement

Statistics
----------------------------------------------------------
          4  recursive calls
         36  db block gets
        126  consistent gets
          2  physical reads
       1160  redo size
        811  bytes sent via SQL*Net to client
        552  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          3  sorts (memory)
          0  sorts (disk)
          4  rows processed

そして、最後は、私の環境で最も古いOracle 11.1.0.7

Oracle Database 11g Enterprise Edition Release 11.1.0.7.0 - 64bit Production

わかっちゃいたけど、オプティマイザの進化が見えて嬉しいですねw

なかなか苦しい実行計画ですね。これは。。。w

Index only Scanにはなっていますが、マテリアライズする部分の実行計画が.. オプティマイザありがとう。（主に最新版のほうですけどw）

本題にもどると、このリリースではCURSOR DURATION MEMORYがないのは当然ですが、CACHE_TEMP_TABLEヒントが利用されているという点に関しては、12cR1と同じ
そして、アダプティブな挙動も一切ない自体の実行計画ですね。ここには戻りたくないですよね。みなさんw

アダプティブな挙動はないにしても、再起コールがおおいし、実行計画が行けてないのでヒントで補正してみたくなりますよねw

Plan hash value: 3067991639

----------------------------------------------------------------------------------------------------------
| Id  | Operation                    | Name                      | Rows  | Bytes | Cost (%CPU)| Time     |
----------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT             |                           |     7 |   448 |    14  (15)| 00:00:01 |
|   1 |  TEMP TABLE TRANSFORMATION   |                           |       |       |            |          |
|   2 |   LOAD AS SELECT             |                           |       |       |            |          |
|   3 |    WINDOW SORT               |                           |     8 |   240 |     9  (12)| 00:00:01 |
|   4 |     CONCATENATION            |                           |       |       |            |          |
|   5 |      NESTED LOOPS            |                           |     7 |   210 |     7   (0)| 00:00:01 |
|   6 |       NESTED LOOPS           |                           |     9 |   225 |     7   (0)| 00:00:01 |
|   7 |        NESTED LOOPS          |                           |     5 |   100 |     4   (0)| 00:00:01 |
|   8 |         NESTED LOOPS         |                           |     7 |   105 |     4   (0)| 00:00:01 |
|   9 |          NESTED LOOPS        |                           |     4 |    40 |     1   (0)| 00:00:01 |
|  10 |           INDEX FULL SCAN    | SYS_C009964               |     4 |    20 |     1   (0)| 00:00:01 |
|* 11 |           INDEX UNIQUE SCAN  | SYS_C009964               |     1 |     5 |     0   (0)| 00:00:01 |
|* 12 |          INDEX FAST FULL SCAN| SYS_C009962               |     2 |    10 |     1   (0)| 00:00:01 |
|* 13 |         INDEX UNIQUE SCAN    | SYS_C009962               |     1 |     5 |     0   (0)| 00:00:01 |
|* 14 |        INDEX FAST FULL SCAN  | SYS_C009960               |     2 |    10 |     1   (0)| 00:00:01 |
|* 15 |       INDEX UNIQUE SCAN      | SYS_C009960               |     1 |     5 |     0   (0)| 00:00:01 |
|  16 |      NESTED LOOPS            |                           |     1 |    30 |     1   (0)| 00:00:01 |
|  17 |       NESTED LOOPS           |                           |     2 |    50 |     1   (0)| 00:00:01 |
|  18 |        NESTED LOOPS          |                           |     1 |    20 |     0   (0)| 00:00:01 |
|  19 |         NESTED LOOPS         |                           |     1 |    15 |     0   (0)| 00:00:01 |
|  20 |          NESTED LOOPS        |                           |     1 |    10 |     0   (0)| 00:00:01 |
|* 21 |           INDEX UNIQUE SCAN  | SYS_C009962               |     1 |     5 |     0   (0)| 00:00:01 |
|* 22 |           INDEX UNIQUE SCAN  | SYS_C009960               |     1 |     5 |     0   (0)| 00:00:01 |
|* 23 |          INDEX UNIQUE SCAN   | SYS_C009962               |     4 |    20 |     0   (0)| 00:00:01 |
|* 24 |         INDEX UNIQUE SCAN    | SYS_C009960               |     4 |    20 |     0   (0)| 00:00:01 |
|* 25 |        INDEX FULL SCAN       | SYS_C009964               |     2 |    10 |     1   (0)| 00:00:01 |
|* 26 |       INDEX UNIQUE SCAN      | SYS_C009964               |     1 |     5 |     0   (0)| 00:00:01 |
|  27 |   LOAD AS SELECT             |                           |       |       |            |          |
|  28 |    WINDOW SORT               |                           |     7 |   217 |     2   (0)| 00:00:01 |
|* 29 |     FILTER                   |                           |       |       |            |          |
|  30 |      VIEW                    |                           |     7 |   217 |     2   (0)| 00:00:01 |
|  31 |       TABLE ACCESS FULL      | SYS_TEMP_0FD9D660C_11BDA4 |     7 |   210 |     2   (0)| 00:00:01 |
|* 32 |      VIEW                    |                           |     1 |    30 |     1   (0)| 00:00:01 |
|  33 |       TABLE ACCESS FULL      | SYS_TEMP_0FD9D660C_11BDA4 |     7 |   210 |     2   (0)| 00:00:01 |
|* 34 |      VIEW                    |                           |     1 |    30 |     1   (0)| 00:00:01 |
|  35 |       TABLE ACCESS FULL      | SYS_TEMP_0FD9D660C_11BDA4 |     7 |   210 |     2   (0)| 00:00:01 |
|  36 |   SORT ORDER BY              |                           |     7 |   448 |     3  (34)| 00:00:01 |
|* 37 |    FILTER                    |                           |       |       |            |          |
|  38 |     VIEW                     |                           |     7 |   448 |     2   (0)| 00:00:01 |
|  39 |      TABLE ACCESS FULL       | SYS_TEMP_0FD9D660D_11BDA4 |     7 |   217 |     2   (0)| 00:00:01 |
|* 40 |     VIEW                     |                           |     7 |   210 |     2   (0)| 00:00:01 |
|  41 |      TABLE ACCESS FULL       | SYS_TEMP_0FD9D660D_11BDA4 |     7 |   217 |     2   (0)| 00:00:01 |
|* 42 |     VIEW                     |                           |     7 |   210 |     2   (0)| 00:00:01 |
|  43 |      TABLE ACCESS FULL       | SYS_TEMP_0FD9D660D_11BDA4 |     7 |   217 |     2   (0)| 00:00:01 |
----------------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

  11 - access("ANIMALS"."KIND"="ANIMALS"."KIND")
  12 - filter("PETS"."NAME"='Wendy' AND "ANIMALS"."KIND"='Dog' OR "PETS"."NAME"='Tiger' AND
              "ANIMALS"."KIND"<>'Dog' AND "ANIMALS"."KIND"<>'Turtle' OR "PETS"."NAME"='Lisa' AND
              "ANIMALS"."KIND"<>'Snake' AND "ANIMALS"."KIND"<>'Dog' OR "PETS"."NAME"='Taro' AND
              "ANIMALS"."KIND"<>'Dog')
  13 - access("PETS"."NAME"="PETS"."NAME")
       filter("PETS"."NAME"<>'Tiger')
  14 - filter("OWNERS"."NAME"='Scott' AND "ANIMALS"."KIND"='Snake' OR "OWNERS"."NAME"='Steve' AND
              "ANIMALS"."KIND"<>'Dog' AND "ANIMALS"."KIND"<>'Snake' OR "OWNERS"."NAME"='Hiro' AND
              "ANIMALS"."KIND"<>'Turtle' AND "ANIMALS"."KIND"<>'Snake' OR "OWNERS"."NAME"='Larry' AND
              "ANIMALS"."KIND"<>'Snake')
  15 - access("OWNERS"."NAME"="OWNERS"."NAME")
       filter("OWNERS"."NAME"<>'Hiro')
  21 - access("PETS"."NAME"='Tiger')
  22 - access("OWNERS"."NAME"='Hiro')
       filter(LNNVL("OWNERS"."NAME"<>'Hiro') OR LNNVL("PETS"."NAME"<>'Tiger'))
  23 - access("PETS"."NAME"="PETS"."NAME")
  24 - access("OWNERS"."NAME"="OWNERS"."NAME")
  25 - filter("OWNERS"."NAME"='Scott' AND "ANIMALS"."KIND"='Snake' OR "OWNERS"."NAME"='Steve' AND
              "ANIMALS"."KIND"<>'Dog' AND "ANIMALS"."KIND"<>'Snake' OR "OWNERS"."NAME"='Hiro' AND
              "ANIMALS"."KIND"<>'Turtle' AND "ANIMALS"."KIND"<>'Snake' OR "OWNERS"."NAME"='Larry' AND
              "ANIMALS"."KIND"<>'Snake')
  26 - access("ANIMALS"."KIND"="ANIMALS"."KIND")
       filter("PETS"."NAME"='Wendy' AND "ANIMALS"."KIND"='Dog' OR "PETS"."NAME"='Tiger' AND
              "ANIMALS"."KIND"<>'Dog' AND "ANIMALS"."KIND"<>'Turtle' OR "PETS"."NAME"='Lisa' AND
              "ANIMALS"."KIND"<>'Snake' AND "ANIMALS"."KIND"<>'Dog' OR "PETS"."NAME"='Taro' AND
              "ANIMALS"."KIND"<>'Dog')
  29 - filter("NUM_OF_ROWS"=1 OR "NUM_OF_ROWS">1 AND  NOT EXISTS (SELECT 0 FROM  (SELECT /*+
              CACHE_TEMP_TABLE ("T1") */ "C0" "NUM_OF_ROWS","C1" "OWNER_NAME","C2" "PET_NAME","C3"
              "ANIMAL_KIND" FROM "SYS"."SYS_TEMP_0FD9D660C_11BDA4" "T1") "PET_OWNER_UNKNOWN" WHERE
              "PET_NAME"=:B1 AND "NUM_OF_ROWS"=1) AND  NOT EXISTS (SELECT 0 FROM  (SELECT /*+ CACHE_TEMP_TABLE
              ("T1") */ "C0" "NUM_OF_ROWS","C1" "OWNER_NAME","C2" "PET_NAME","C3" "ANIMAL_KIND" FROM
              "SYS"."SYS_TEMP_0FD9D660C_11BDA4" "T1") "PET_OWNER_UNKNOWN" WHERE "ANIMAL_KIND"=:B2 AND
              "NUM_OF_ROWS"=1))
  32 - filter("PET_NAME"=:B1 AND "NUM_OF_ROWS"=1)
  34 - filter("ANIMAL_KIND"=:B1 AND "NUM_OF_ROWS"=1)
  37 - filter("NUM_OF_ROWS"=1 OR "NUM_OF_ROWS">1 AND  NOT EXISTS (SELECT 0 FROM  (SELECT /*+
              CACHE_TEMP_TABLE ("T1") */ "C0" "NUM_OF_ROWS","C1" "OWNER_NAME","C2" "PET_NAME","C3"
              "ANIMAL_KIND" FROM "SYS"."SYS_TEMP_0FD9D660D_11BDA4" "T1") "PET_OWNERS" WHERE "PET_NAME"=:B1 AND
              "NUM_OF_ROWS"=1) AND  NOT EXISTS (SELECT 0 FROM  (SELECT /*+ CACHE_TEMP_TABLE ("T1") */ "C0"
              "NUM_OF_ROWS","C1" "OWNER_NAME","C2" "PET_NAME","C3" "ANIMAL_KIND" FROM
              "SYS"."SYS_TEMP_0FD9D660D_11BDA4" "T1") "PET_OWNERS" WHERE "ANIMAL_KIND"=:B2 AND "NUM_OF_ROWS"=1))
  40 - filter("PET_NAME"=:B1 AND "NUM_OF_ROWS"=1)
  42 - filter("ANIMAL_KIND"=:B1 AND "NUM_OF_ROWS"=1)

統計
----------------------------------------------------------
          4  recursive calls
         16  db block gets
         85  consistent gets
          2  physical reads
       1156  redo size
        807  bytes sent via SQL*Net to client
        520  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          3  sorts (memory)
          0  sorts (disk)
          4  rows processed

アダプティブな挙動がないにしても、再起コールがおおいし、実行計画が行けてないのでヒントで補正してみたくなりますよねw
NO_EXPANDヒントでCONCATENATIONを抑止してみましたw
それでもイマイチだ。古いオプティマイザとの挙動の違いをみると、ほんと、最新版のオプテマイザの良さが身にしみますw

Plan hash value: 2841796482

---------------------------------------------------------------------------------------------------------
| Id  | Operation                   | Name                      | Rows  | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT            |                           |     7 |   448 |    13   (8)| 00:00:01 |
|   1 |  TEMP TABLE TRANSFORMATION  |                           |       |       |            |          |
|   2 |   LOAD AS SELECT            |                           |       |       |            |          |
|   3 |    WINDOW SORT              |                           |     7 |   210 |     8   (0)| 00:00:01 |
|   4 |     NESTED LOOPS            |                           |     7 |   210 |     8   (0)| 00:00:01 |
|   5 |      NESTED LOOPS           |                           |    12 |   300 |     8   (0)| 00:00:01 |
|   6 |       NESTED LOOPS          |                           |     7 |   140 |     4   (0)| 00:00:01 |
|   7 |        NESTED LOOPS         |                           |     7 |   105 |     4   (0)| 00:00:01 |
|   8 |         NESTED LOOPS        |                           |     4 |    40 |     1   (0)| 00:00:01 |
|   9 |          INDEX FULL SCAN    | SYS_C009964               |     4 |    20 |     1   (0)| 00:00:01 |
|* 10 |          INDEX UNIQUE SCAN  | SYS_C009964               |     1 |     5 |     0   (0)| 00:00:01 |
|* 11 |         INDEX FAST FULL SCAN| SYS_C009962               |     2 |    10 |     1   (0)| 00:00:01 |
|* 12 |        INDEX UNIQUE SCAN    | SYS_C009962               |     1 |     5 |     0   (0)| 00:00:01 |
|* 13 |       INDEX FAST FULL SCAN  | SYS_C009960               |     2 |    10 |     1   (0)| 00:00:01 |
|* 14 |      INDEX UNIQUE SCAN      | SYS_C009960               |     1 |     5 |     0   (0)| 00:00:01 |
|  15 |   LOAD AS SELECT            |                           |       |       |            |          |
|  16 |    WINDOW SORT              |                           |     7 |   217 |     2   (0)| 00:00:01 |
|* 17 |     FILTER                  |                           |       |       |            |          |
|  18 |      VIEW                   |                           |     7 |   217 |     2   (0)| 00:00:01 |
|  19 |       TABLE ACCESS FULL     | SYS_TEMP_0FD9D6624_11BDA4 |     7 |   210 |     2   (0)| 00:00:01 |
|* 20 |      VIEW                   |                           |     1 |    30 |     1   (0)| 00:00:01 |
|  21 |       TABLE ACCESS FULL     | SYS_TEMP_0FD9D6624_11BDA4 |     7 |   210 |     2   (0)| 00:00:01 |
|* 22 |      VIEW                   |                           |     1 |    30 |     1   (0)| 00:00:01 |
|  23 |       TABLE ACCESS FULL     | SYS_TEMP_0FD9D6624_11BDA4 |     7 |   210 |     2   (0)| 00:00:01 |
|  24 |   SORT ORDER BY             |                           |     7 |   448 |     3  (34)| 00:00:01 |
|* 25 |    FILTER                   |                           |       |       |            |          |
|  26 |     VIEW                    |                           |     7 |   448 |     2   (0)| 00:00:01 |
|  27 |      TABLE ACCESS FULL      | SYS_TEMP_0FD9D6625_11BDA4 |     7 |   217 |     2   (0)| 00:00:01 |
|* 28 |     VIEW                    |                           |     7 |   210 |     2   (0)| 00:00:01 |
|  29 |      TABLE ACCESS FULL      | SYS_TEMP_0FD9D6625_11BDA4 |     7 |   217 |     2   (0)| 00:00:01 |
|* 30 |     VIEW                    |                           |     7 |   210 |     2   (0)| 00:00:01 |
|  31 |      TABLE ACCESS FULL      | SYS_TEMP_0FD9D6625_11BDA4 |     7 |   217 |     2   (0)| 00:00:01 |
---------------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

10 - access("ANIMALS"."KIND"="ANIMALS"."KIND")
11 - filter("PETS"."NAME"='Wendy' AND "ANIMALS"."KIND"='Dog' OR "PETS"."NAME"='Tiger' AND
            "ANIMALS"."KIND"<>'Dog' AND "ANIMALS"."KIND"<>'Turtle' OR "PETS"."NAME"='Lisa' AND
            "ANIMALS"."KIND"<>'Snake' AND "ANIMALS"."KIND"<>'Dog' OR "PETS"."NAME"='Taro' AND
            "ANIMALS"."KIND"<>'Dog')
12 - access("PETS"."NAME"="PETS"."NAME")
13 - filter("OWNERS"."NAME"='Scott' AND "ANIMALS"."KIND"='Snake' OR "OWNERS"."NAME"='Steve'
            AND "ANIMALS"."KIND"<>'Dog' AND "ANIMALS"."KIND"<>'Snake' OR "OWNERS"."NAME"='Hiro' AND
            "ANIMALS"."KIND"<>'Turtle' AND "ANIMALS"."KIND"<>'Snake' OR "OWNERS"."NAME"='Larry' AND
            "ANIMALS"."KIND"<>'Snake')
14 - access("OWNERS"."NAME"="OWNERS"."NAME")
     filter("OWNERS"."NAME"='Hiro' AND "PETS"."NAME"='Tiger' OR "OWNERS"."NAME"<>'Hiro' AND
            "PETS"."NAME"<>'Tiger')
17 - filter("NUM_OF_ROWS"=1 OR "NUM_OF_ROWS">1 AND  NOT EXISTS (SELECT 0 FROM  (SELECT /*+
            CACHE_TEMP_TABLE ("T1") */ "C0" "NUM_OF_ROWS","C1" "OWNER_NAME","C2" "PET_NAME","C3"
            "ANIMAL_KIND" FROM "SYS"."SYS_TEMP_0FD9D6624_11BDA4" "T1") "PET_OWNER_UNKNOWN" WHERE
            "PET_NAME"=:B1 AND "NUM_OF_ROWS"=1) AND  NOT EXISTS (SELECT 0 FROM  (SELECT /*+ CACHE_TEMP_TABLE
            ("T1") */ "C0" "NUM_OF_ROWS","C1" "OWNER_NAME","C2" "PET_NAME","C3" "ANIMAL_KIND" FROM
            "SYS"."SYS_TEMP_0FD9D6624_11BDA4" "T1") "PET_OWNER_UNKNOWN" WHERE "ANIMAL_KIND"=:B2 AND
            "NUM_OF_ROWS"=1))
20 - filter("PET_NAME"=:B1 AND "NUM_OF_ROWS"=1)
22 - filter("ANIMAL_KIND"=:B1 AND "NUM_OF_ROWS"=1)
25 - filter("NUM_OF_ROWS"=1 OR "NUM_OF_ROWS">1 AND  NOT EXISTS (SELECT 0 FROM  (SELECT /*+
            CACHE_TEMP_TABLE ("T1") */ "C0" "NUM_OF_ROWS","C1" "OWNER_NAME","C2" "PET_NAME","C3"
            "ANIMAL_KIND" FROM "SYS"."SYS_TEMP_0FD9D6625_11BDA4" "T1") "PET_OWNERS" WHERE "PET_NAME"=:B1 AND
            "NUM_OF_ROWS"=1) AND  NOT EXISTS (SELECT 0 FROM  (SELECT /*+ CACHE_TEMP_TABLE ("T1") */ "C0"
            "NUM_OF_ROWS","C1" "OWNER_NAME","C2" "PET_NAME","C3" "ANIMAL_KIND" FROM
            "SYS"."SYS_TEMP_0FD9D6625_11BDA4" "T1") "PET_OWNERS" WHERE "ANIMAL_KIND"=:B2 AND
            "NUM_OF_ROWS"=1))
28 - filter("PET_NAME"=:B1 AND "NUM_OF_ROWS"=1)
30 - filter("ANIMAL_KIND"=:B1 AND "NUM_OF_ROWS"=1)

統計
----------------------------------------------------------
        4  recursive calls
       16  db block gets
       84  consistent gets
        2  physical reads
     1156  redo size
      807  bytes sent via SQL*Net to client
      520  bytes received via SQL*Net from client
        2  SQL*Net roundtrips to/from client
        3  sorts (memory)
        0  sorts (disk)
        4  rows processed

SQLのレントゲン写真、バージョンと共に基本形wが変化していくので、常に差分と最新の内容を把握しておきたいですよね。いざ、診療するとなったときには役に立つ、はず！！

今回利用したSQL文や表定義およびデータは、誰がどんな名前のペットを飼っているのかな？解答編 / JPOUG Advent Calendar Day 23を参照ください。

では、また。

投稿日時 2022年3月26日 (土) 11時07分 Oracle, チューニング, FAQ, SQL, Oracle Database 11g, Oracle Database 12c release 1, パフォーマンス, Oracle Database 19c | 固定リンク | 0 | コメント (0)

2021年3月22日 (月)

19cの初期化パラメータ数や隠しパラメータ数などどう変化したのか、久々に確認してみた

ORACLE-ORCLCDB@SYS> select banner_full from v$version;

BANNER_FULL
------------------------------------------------------------------------
Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production
Version 19.3.0.0.0

compute sum label 'Total' of "Num Of Parameters" on report
break on report
WITH cte_params AS
(
  SELECT
    a.ksppinm
  FROM
    x$ksppi a JOIN x$ksppcv b
    ON a.indx = b.indx

)
SELECT
   *
FROM
(
  SELECT
   '1. Single underscore parameters' AS "CATEGORY"
   , COUNT(1) AS "Num Of Parameters"
  FROM
   cte_params
  WHERE
   REGEXP_LIKE(ksppinm, '^([_][^_]){1}.*')
  UNION
  SELECT
   '2. Double underscore parameters'
   , COUNT(1)
  FROM
   cte_params
  WHERE
   REGEXP_LIKE(ksppinm, '^[_]{2}.*')
  UNION
  SELECT
   '3. Non hidden parameters'
   , COUNT(1)
  FROM
   cte_params
  WHERE
   REGEXP_LIKE(ksppinm, '^[^_].*')
)
ORDER by
 category;

カウントした結果配は以下のとおり。やはりhidden parameter、かなり増えてますよね。

CATEGORY                        Num Of Parameters
------------------------------- -----------------
1. Single underscore parameters              4934
2. Double underscore parameters                30
3. Non hidden parameters                      448
                                -----------------
Total                                        5412

経過: 00:00:00.06

ぽかぽか陽気すぎて、海辺でパタパタしたいw

・Difference of Initialization Parameters between 11g r1 (11.1.0.6.0) and 12c r1 (12.1.0.1.0) - including hidden params
・Difference of Initialization Parameters between 11g and 12c #2

投稿日時 2021年3月22日 (月) 17時34分 Oracle, Oracle Database 11g, Oracle Database 11g Release 2, Oracle Database 12c release 1, Oracle Database 12c Release 2, Oracle Database 19c | 固定リンク | 0 | コメント (0)

2019年9月30日 (月)

なぜ、そこに、LONG型があるんだ / FAQ

all/dba/user_tab_columns

https://docs.oracle.com/cd/E82638_01/refrn/ALL_TAB_COLUMNS.html#GUID-F218205C-7D76-4A83-8691-BFD2AD372B63

これらのビューは、列の属性関連の情報を持つビューです。
たまに、便利なびゅーではあるのですが、これらのビューをアクセスする使うスクリプトというかPL/SQLでコード書くこともあるのですが、一箇所だけ、使いにくいところがあります。

どこかわかります？

下位互換のためだろうと思われるのですが、一般には推奨されていない　LONG型の列　が残っています。

ご存知だとは思いますが、一般的なガイドだと、CLOBの利用が推奨されています。
下位互換のためだから仕方ないのだとは思うのですが。

LONG型といえば、とにかく制約が多くて、文字列操作を行うにもめんどくさいわけで、実際に利用したい状況になると、うううううっとなることしばしば。

LONG型

で、普段どうやって、その面倒くさいところを回避しているかといえば、CLOBに変換してしまうことがが多いです。
CLOBにしてしまえば、沢山の制約から解放されますしね　:)

以下のような感じで。

SCOTT> l
  1  CREATE TABLE my_dba_tab_columns
  2  AS
  3  SELECT
  4    owner
  5    ,table_name
  6    ,column_name
  7    ,data_type
  8    ,data_type_mod
  9    ,data_type_owner
 10    ,data_length
 11    ,data_precision
 12    ,data_scale
 13    ,nullable
 14    ,column_id
 15    ,TO_CLOB(default_length) AS default_length
 16    ,num_distinct
 17    ,low_value
 18    ,high_value
 19    ,density
 20    ,num_nulls
 21    ,num_buckets
 22    ,last_analyzed
 23    ,sample_size
 24    ,character_set_name
 25    ,char_col_decl_length
 26    ,global_stats
 27    ,user_stats
 28    ,avg_col_len
 29    ,char_length
 30    ,char_used
 31    ,v80_fmt_image
 32    ,data_upgraded
 33    ,histogram
 34    ,default_on_null
 35    ,identity_column
 36    ,sensitive_column
 37    ,evaluation_edition
 38    ,unusable_before
 39    ,unusable_beginning
 40    ,collation
 41  FROM
 42*   dba_tab_columns
SCOTT> /

Table created.

SCOTT> desc dba_tab_columns
 Name                                      Null?    Type
 ----------------------------------------- -------- ----------------------------
 OWNER                                     NOT NULL VARCHAR2(128)
 TABLE_NAME                                NOT NULL VARCHAR2(128)
 COLUMN_NAME                               NOT NULL VARCHAR2(128)
 DATA_TYPE                                          VARCHAR2(128)
 DATA_TYPE_MOD                                      VARCHAR2(3)
 DATA_TYPE_OWNER                                    VARCHAR2(128)
 DATA_LENGTH                               NOT NULL NUMBER
 DATA_PRECISION                                     NUMBER
 DATA_SCALE                                         NUMBER
 NULLABLE                                           VARCHAR2(1)
 COLUMN_ID                                          NUMBER
 DEFAULT_LENGTH                                     NUMBER
 DATA_DEFAULT                                       LONG
 NUM_DISTINCT                                       NUMBER
 LOW_VALUE                                          RAW(2000)
 HIGH_VALUE                                         RAW(2000)
 DENSITY                                            NUMBER
 NUM_NULLS                                          NUMBER
 NUM_BUCKETS                                        NUMBER
 LAST_ANALYZED                                      DATE
 SAMPLE_SIZE                                        NUMBER
 CHARACTER_SET_NAME                                 VARCHAR2(44)
 CHAR_COL_DECL_LENGTH                               NUMBER
 GLOBAL_STATS                                       VARCHAR2(3)
 USER_STATS                                         VARCHAR2(3)
 AVG_COL_LEN                                        NUMBER
 CHAR_LENGTH                                        NUMBER
 CHAR_USED                                          VARCHAR2(1)
 V80_FMT_IMAGE                                      VARCHAR2(3)
 DATA_UPGRADED                                      VARCHAR2(3)
 HISTOGRAM                                          VARCHAR2(15)
 DEFAULT_ON_NULL                                    VARCHAR2(3)
 IDENTITY_COLUMN                                    VARCHAR2(3)
 SENSITIVE_COLUMN                                   VARCHAR2(3)
 EVALUATION_EDITION                                 VARCHAR2(128)
 UNUSABLE_BEFORE                                    VARCHAR2(128)
 UNUSABLE_BEGINNING                                 VARCHAR2(128)
 COLLATION                                          VARCHAR2(100)

SCOTT> desc my_dba_tab_columns
 Name                                      Null?    Type
 ----------------------------------------- -------- ----------------------------
 OWNER                                     NOT NULL VARCHAR2(128)
 TABLE_NAME                                NOT NULL VARCHAR2(128)
 COLUMN_NAME                               NOT NULL VARCHAR2(128)
 DATA_TYPE                                          VARCHAR2(128)
 DATA_TYPE_MOD                                      VARCHAR2(3)
 DATA_TYPE_OWNER                                    VARCHAR2(128)
 DATA_LENGTH                               NOT NULL NUMBER
 DATA_PRECISION                                     NUMBER
 DATA_SCALE                                         NUMBER
 NULLABLE                                           VARCHAR2(1)
 COLUMN_ID                                          NUMBER
 DEFAULT_LENGTH                                     CLOB
 NUM_DISTINCT                                       NUMBER
 LOW_VALUE                                          RAW(2000)
 HIGH_VALUE                                         RAW(2000)
 DENSITY                                            NUMBER
 NUM_NULLS                                          NUMBER
 NUM_BUCKETS                                        NUMBER
 LAST_ANALYZED                                      DATE
 SAMPLE_SIZE                                        NUMBER
 CHARACTER_SET_NAME                                 VARCHAR2(44)
 CHAR_COL_DECL_LENGTH                               NUMBER
 GLOBAL_STATS                                       VARCHAR2(3)
 USER_STATS                                         VARCHAR2(3)
 AVG_COL_LEN                                        NUMBER
 CHAR_LENGTH                                        NUMBER
 CHAR_USED                                          VARCHAR2(1)
 V80_FMT_IMAGE                                      VARCHAR2(3)
 DATA_UPGRADED                                      VARCHAR2(3)
 HISTOGRAM                                          VARCHAR2(15)
 DEFAULT_ON_NULL                                    VARCHAR2(3)
 IDENTITY_COLUMN                                    VARCHAR2(3)
 SENSITIVE_COLUMN                                   VARCHAR2(3)
 EVALUATION_EDITION                                 VARCHAR2(128)
 UNUSABLE_BEFORE                                    VARCHAR2(128)
 UNUSABLE_BEGINNING                                 VARCHAR2(128)
 COLLATION                                          VARCHAR2(100)

db tech showcase 2019もおわり、今年も残すところ 3ヶ月あまり。一年早い. そして。
来週は、開催時期を秋に変更してから2回目の多摩川花火大会。天気がよいといいのですが:)

ではまた。

投稿日時 2019年9月30日 (月) 00時56分 Oracle, FAQ, SQL, Oracle Database 11g, Oracle Database 12c release 1, Oracle Database 12c Release 2, Oracle Database 18c, Oracle Database 19c | 固定リンク | 0 | コメント (0)

2019年8月25日 (日)

FAQ / PL/SQL PACKAGEでパプリックスコープを持つ定数をSQL文中で利用するには...

かなーり、ご無沙汰しておりました。（本業でいっぱいいっぱいで、という言い訳はこれぐらいにしてw）偶に聞かれることがあるので、FAQネタから。パッケージでパブリックなスコープを持つ定数は無名PL/SQLブロックやパッケージ、プロシージャ、ファンクションでしか参照できないんですよねー例えば、DBMS_CRYPTOパッケージでHASHファンクションを利用してSH-256を作成したいなーと思って、

39.4 DBMS_CRYPTOのアルゴリズム
https://docs.oracle.com/cd/F19136_01/arpls/DBMS_CRYPTO.html#GUID-CE3CF17D-E781-47CB-AEE7-19A9B2BCD3EC

DBMS_CRYPTO.HASH()は関数なのでSQL文から呼びたーい、と以下のような使い方をすると...

SQL> SELECT DBMS_CRYPTO.HASH(TO_CLOB('hoge'), DBMS_CRYPTO.HASH_SH2569) AS "SH-256" FROM dual;
SELECT DBMS_CRYPTO.HASH(TO_CLOB('hoge'), DBMS_CRYPTO.HASH_SH2569) AS "SH-256" FROM dual
                                         *
ERROR at line 1:
ORA-00904: "DBMS_CRYPTO"."HASH_SH2569": invalid identifier


SQL>
SQL> select DBMS_CRYPTO.HASH_SH256 from dual;
select DBMS_CRYPTO.HASH_SH256 from dual
       *
ERROR at line 1:
ORA-06553: PLS-221: 'HASH_SH256' is not a procedure or is undefined

見事にエラーとなるわけです。 DBMS_CRYPTO.HASH_SH256は、パッケージファンクションではないので...利用可能なのはPL/SQLでのみ。

SQL> set serveroutput on
SQL>
¥SQL>
SQL> begin
  2    dbms_output.put_line('DBMS_CRYPTO.HASH_SH256 : ' || DBMS_CRYPTO.HASH_SH256);
  3  end;
  4  /
DBMS_CRYPTO.HASH_SH256 : 4

PL/SQL procedure successfully completed.

SQL文で活用する為には、ファンクションでラップする必要があります。以下のように。

SQL> l
  1  CREATE OR REPLACE FUNCTION get_hash_sh256_type
  2  RETURN NUMBER
  3  AS
  4  BEGIN
  5    RETURN DBMS_CRYPTO.HASH_SH256;
  6* END;
SQL> /

Function created.

SQL>

冒頭でエラーとなっていたSQL文をDBMS_CRYPTO.HASH_SH256を返すファンクションを使うように書き換えると、はい、できました。

SQL> l
  1  SELECT
  2    DBMS_CRYPTO.HASH(
  3	     TO_CLOB('hoge')
  4	     , get_hash_sh256_type()
  5    ) AS "SH-256"
  6  FROM
  7*   dual
SQL> /

SH-256
--------------------------------------------------------------------------------
ECB666D778725EC97307044D642BF4D160AABB76F56C0069C71EA25B1E926825

SQL>

露店の焼きそばと焼き鳥を食べつつ、晩夏の夏祭りと、涼しい朝晩の気温で熟睡可能な山形より。では、では。

投稿日時 2019年8月25日 (日) 06時01分 PL/SQL, FAQ, SQL, Oracle Database 11g, Oracle Database 11g Release 2, Oracle Database 12c release 1, Oracle Database 12c Release 2, Oracle Database 18c, Oracle Database 19c | 固定リンク | 0 | コメント (0)

2019年3月22日 (金)

ORA_HASH()を使ってリストパーティションにハッシュパーティションのような均一配分を

ハッシュパーティションってリストパーティションみたいにパーティション狙い撃ちできて、かつ、ハッシュパーティションみたいに、データをパーティション間で均一化できないのかなぁ
というずいぶん昔の話を思い出して、そう言えば書いてないかもしれない。いつの話だよってぐらい昔の話だけどw
どうやったかというと、
ハッシュキーにふさわしい値をもつ列を決める（一意キーとか主キー列が理想、カーディナリティの低い、分布に偏りのあるデータを持つ列は使わない）

で、ハッシュキーが決まったら、話は早くて、ORA_HASH()関数で取得できるハッシュ値を利用したリストパーティションを作成するだけ。
ゴニョゴニュ言わなくても、SQLとPL/SQLのコードを見ていただければ、理解していただけるかと。

ORCL@SCOTT> l
  1  CREATE TABLE list_p_tab
  2  (
  3    id_code VARCHAR2(10) NOT NULL
  4    , foo VARCHAR2(30)
  5    , id_code_hash_value NUMBER(2) NOT NULL
  6  )
  7  PARTITION BY LIST (id_code_hash_value)
  8  (
  9    PARTITION list_p_tab_p1 VALUES(0)
 10    ,PARTITION list_p_tab_p2 VALUES(1)
 11    ,PARTITION list_p_tab_p3 VALUES(2)
 12    ,PARTITION list_p_tab_p4 VALUES(3)
 13* )
ORCL@SCOTT> /

Table created.

ORCL@SCOTT> ALTER TABLE list_p_tab ADD CONSTRAINT gpk_list_p_tab PRIMARY KEY(id_code) USING INDEX GLOBAL;

Table altered.

 ORCL@SCOTT> l
  1  DECLARE
  2    TYPE id_code_t IS TABLE OF list_p_tab.id_code%TYPE INDEX BY PLS_INTEGER;
  3    TYPE foo_t IS TABLE OF list_p_tab.foo%TYPE INDEX BY PLS_INTEGER;
  4    id_codes id_code_t;
  5    foos foo_t;
  6    k PLS_INTEGER := 1;
  7  BEGIN
  8    FOR i IN 1..400000 LOOP
  9        id_codes(k)            := TO_CHAR(i,'fm0000000009');
 10        foos(k)                := i;
 11        k := k + 1;
 12        IF k > 1000 THEN
 13          FORALL j in 1..k-1
 14            INSERT INTO list_p_tab VALUES(id_codes(j), foos(j), ORA_HASH(id_codes(j),3));
 15          COMMIT;
 16          k := 1;
 17        END IF;
 18    END LOOP;
 19* END;
ORCL@SCOTT> /

PL/SQL procedure successfully completed.

Elapsed: 00:00:12.28

ORCL@SCOTT> exec dbms_stats.gather_table_stats(ownname=>'SCOTT',tabname=>'LIST_P_TAB',granularity=>'ALL',cascade=>true,no_invalidate=>false,degree=>4);

PL/SQL procedure successfully completed.

Elapsed: 00:00:02.51

ORCL@SCOTT> r
  1  select
  2    table_name
  3    ,partition_name
  4    ,num_rows
  5  from
  6    user_tab_partitions
  7  where
  8    table_name = 'LIST_P_TAB'
  9  order by
 10*   1,2

TABLE_NAME                     PARTITION_NAME                   NUM_ROWS
------------------------------ ------------------------------ ----------
LIST_P_TAB                     LIST_P_TAB_P1                       99901
LIST_P_TAB                     LIST_P_TAB_P2                      100194
LIST_P_TAB                     LIST_P_TAB_P3                      100056
LIST_P_TAB                     LIST_P_TAB_P4                       99849

ORCL@SCOTT> select id_code_hash_value,count(1) from list_p_tab group by id_code_hash_value order by 1;

ID_CODE_HASH_VALUE   COUNT(1)
------------------ ----------
                 0      99901
                 1     100194
                 2     100056
                 3      99849

Elapsed: 00:00:00.06

ORCL@SCOTT> explain plan for 
  2  select
  3    *
  4  from
  5    list_p_tab
  6  where
  7    id_code_hash_value = 1;       

Explained.

Elapsed: 00:00:00.10
ORCL@SCOTT> @?/rdbms/admin/utlxpls

PLAN_TABLE_OUTPUT
----------------------------------------------------------------------------------------------------
Plan hash value: 2143708561

----------------------------------------------------------------------------------------------------
| Id  | Operation             | Name       | Rows  | Bytes | Cost (%CPU)| Time     | Pstart| Pstop |
----------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT      |            |   100K|  2054K|   275   (1)| 00:00:01 |       |       |
|   1 |  PARTITION LIST SINGLE|            |   100K|  2054K|   275   (1)| 00:00:01 |     2 |     2 |
|   2 |   TABLE ACCESS FULL   | LIST_P_TAB |   100K|  2054K|   275   (1)| 00:00:01 |     2 |     2 |
----------------------------------------------------------------------------------------------------

グローバル索引を作成してあるので、パーティション関係ない検索は主キー索引経由でも可。

ORCL@SCOTT> explain plan for select * from list_p_tab where id_code = '00004000000';

Explained.

Elapsed: 00:00:00.02
ORCL@SCOTT> @?/rdbms/admin/utlxpls

PLAN_TABLE_OUTPUT
---------------------------------------------------------------------------------------------------------------------
Plan hash value: 4132161764

---------------------------------------------------------------------------------------------------------------------
| Id  | Operation                          | Name           | Rows  | Bytes | Cost (%CPU)| Time     | Pstart| Pstop |
---------------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                   |                |     1 |    21 |     3   (0)| 00:00:01 |       |       |
|   1 |  TABLE ACCESS BY GLOBAL INDEX ROWID| LIST_P_TAB     |     1 |    21 |     3   (0)| 00:00:01 | ROWID | ROWID |
|*  2 |   INDEX UNIQUE SCAN                | GPK_LIST_P_TAB |     1 |       |     2   (0)| 00:00:01 |       |       |
---------------------------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   2 - access("ID_CODE"='00004000000')

投稿日時 2019年3月22日 (金) 00時37分 Oracle, PL/SQL, その他, チューニング, FAQ, SQL, Oracle Database 11g, Oracle Database 11g Release 2, Oracle Database 12c release 1, Oracle Database 12c Release 2, Oracle Database 18c | 固定リンク | 0 | コメント (0)

2019年3月21日 (木)

Join Elimination（結合の排除）と参照整合性制約　/ FAQ

偶に聞かれることがあるので、再び、Join Elimination（結合の排除）について

まずは、以下のSQL文を。

order表とcustomers表をinner joinしている単純な文ですが、重要なのは、実行計画の方！

order表とcustomers表をinner joinしているのに、order表だけ（この場合、order表の主キー索引だけのIndex Only Scanになっていますが）で、customes表を結合していせん。

理由は単純で、以下のSQL文では、customsers表の結合が不要なだけなんです。なぜかわかりますか？

以前、浅瀬でジャブジャブしていたセッション資料にヒントがあります。

db tech showcase Tokyo 2013 - A35 特濃JPOUG：潮溜まりでジャブジャブ、SQLチューニングの「参照整合性制約アレルギー」を参照のこと

order表に定義されている参照整合性制約によりcustomer_idがcustomsers表に存在していることを確認するための結合は不要と、オプティマイザーが判断した結果なんですよね。これ。

上記以外のケースでも無駄な結合を排除しようとする最適化を行うことがあります。内部的にはSQL文を書き換えてくれているわけですね。無駄に結合を行わないために。。。10053トレースをとって、　Join Elimination で grep をかけてみるとオプティマイザの気持ちが見えてきます:)

ORCL@OE> explain plan for
  2  select
  3    distinct
  4    order_id
  5  from
  6    orders o 
  7    , customers c
  8  where
  9    o.customer_id = c.customer_id
 10    and order_id < 2400;

Explained.

ORCL@OE> @?/rdbms/admin/utlxpls

PLAN_TABLE_OUTPUT
-----------------------------------------------------------------------------
Plan hash value: 1653993310

-----------------------------------------------------------------------------
| Id  | Operation        | Name     | Rows  | Bytes | Cost (%CPU)| Time     |
-----------------------------------------------------------------------------
|   0 | SELECT STATEMENT |          |    46 |   184 |     1   (0)| 00:00:01 |
|*  1 |  INDEX RANGE SCAN| ORDER_PK |    46 |   184 |     1   (0)| 00:00:01 |
-----------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   1 - access("ORDER_ID"<2400)

上記、SQL文は、参照整合性制約により、orders表に存在するcustomer_idがcustomers表に存在することが保証されているため、結合により存在確認が不要となり、Optimizerは内部的にSQL文を以下のように書き換えたということになります。賢いですよね。

ORCL@OE> r
  1  explain plan for
  2  select
  3    distinct
  4    order_id
  5  from
  6    orders o
  7  where
  8*   order_id < 2400

Explained.

ORCL@OE> @?/rdbms/admin/utlxpls

PLAN_TABLE_OUTPUT
-----------------------------------------------------------------------------
Plan hash value: 1653993310

-----------------------------------------------------------------------------
| Id  | Operation        | Name     | Rows  | Bytes | Cost (%CPU)| Time     |
-----------------------------------------------------------------------------
|   0 | SELECT STATEMENT |          |    46 |   184 |     1   (0)| 00:00:01 |
|*  1 |  INDEX RANGE SCAN| ORDER_PK |    46 |   184 |     1   (0)| 00:00:01 |
-----------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   1 - access("ORDER_ID"<2400)

13 rows selected.

order表の参照整合性制約を確認しておきます。

ORCL@OE> r
  1  select
  2    table_name
  3    ,owner
  4    ,constraint_name
  5    ,constraint_type
  6    ,r_owner
  7    ,r_constraint_name
  8    ,status
  9    ,rely
 10  from
 11    user_constraints
 12  where
 13*   constraint_type='R'

TABLE_NAME                     OWNER                          CONSTRAINT_NAME                C R_OWNER                        R_CONSTRAINT_NAME              STATUS   RELY
------------------------------ ------------------------------ ------------------------------ - ------------------------------ ------------------------------ -------- ----
ORDERS                         OE                             ORDERS_CUSTOMER_ID_FK          R OE                             CUSTOMERS_PK                   ENABLED
INVENTORIES                    OE                             INVENTORIES_WAREHOUSES_FK      R OE                             WAREHOUSES_PK                  ENABLED
INVENTORIES                    OE                             INVENTORIES_PRODUCT_ID_FK      R OE                             PRODUCT_INFORMATION_PK         ENABLED
ORDER_ITEMS                    OE                             ORDER_ITEMS_ORDER_ID_FK        R OE                             ORDER_PK                       ENABLED
ORDER_ITEMS                    OE                             ORDER_ITEMS_PRODUCT_ID_FK      R OE                             PRODUCT_INFORMATION_PK         ENABLED
PRODUCT_DESCRIPTIONS           OE                             PD_PRODUCT_ID_FK               R OE                             PRODUCT_INFORMATION_PK         ENABLED

ORCL@OE> r
  1  select
  2    table_name
  3    ,column_name
  4    ,constraint_name
  5  from
  6    user_cons_columns
  7  where
  8    table_name in ('ORDERS','CUSTOMERS')
  9  order by
 10*   table_name

TABLE_NAME                     COLUMN_NAME                    CONSTRAINT_NAME
------------------------------ ------------------------------ ------------------------------
CUSTOMERS                      CUSTOMER_ID                    CUSTOMERS_PK
CUSTOMERS                      CUST_FIRST_NAME                CUST_FNAME_NN
CUSTOMERS                      CUSTOMER_ID                    CUSTOMER_ID_MIN
CUSTOMERS                      CREDIT_LIMIT                   CUSTOMER_CREDIT_LIMIT_MAX
CUSTOMERS                      CUST_LAST_NAME                 CUST_LNAME_NN
ORDERS                         ORDER_ID                       ORDER_PK
ORDERS                         ORDER_TOTAL                    ORDER_TOTAL_MIN
ORDERS                         ORDER_MODE                     ORDER_MODE_LOV
ORDERS                         CUSTOMER_ID                    ORDER_CUSTOMER_ID_NN
ORDERS                         CUSTOMER_ID                    ORDERS_CUSTOMER_ID_FK
ORDERS                         ORDER_DATE                     ORDER_DATE_NN

Oracle SQL DeveloperでリバースエンジニアリングしたERDは以下のとおり

では、最後に、参照整合性制約を無効化した場合、実行計画はどうなるか見ておきましょう。

ORCL@OE> alter table orders disable constraint orders_customer_id_fk;

Table altered.

ORCL@OE> r
  1  select
  2    table_name
  3    ,owner
  4    ,constraint_name
  5    ,constraint_type
  6    ,r_owner
  7    ,r_constraint_name
  8    ,status
  9    ,rely
 10  from
 11    user_constraints
 12  where
 13*   constraint_type='R'

TABLE_NAME                     OWNER                          CONSTRAINT_NAME                C R_OWNER                        R_CONSTRAINT_NAME              STATUS   RELY
------------------------------ ------------------------------ ------------------------------ - ------------------------------ ------------------------------ -------- ----
ORDERS                         OE                             ORDERS_CUSTOMER_ID_FK          R OE                             CUSTOMERS_PK                   DISABLED
INVENTORIES                    OE                             INVENTORIES_WAREHOUSES_FK      R OE                             WAREHOUSES_PK                  ENABLED
INVENTORIES                    OE                             INVENTORIES_PRODUCT_ID_FK      R OE                             PRODUCT_INFORMATION_PK         ENABLED
ORDER_ITEMS                    OE                             ORDER_ITEMS_ORDER_ID_FK        R OE                             ORDER_PK                       ENABLED
ORDER_ITEMS                    OE                             ORDER_ITEMS_PRODUCT_ID_FK      R OE                             PRODUCT_INFORMATION_PK         ENABLED
PRODUCT_DESCRIPTIONS           OE                             PD_PRODUCT_ID_FK               R OE                             PRODUCT_INFORMATION_PK         ENABLED

あらまあ、不思議w わざとらしいw

customers表げ結合されちゃってネステッドループ結合に！

ORCL@OE> r
  1  explain plan for
  2  select
  3    distinct
  4    order_id
  5  from
  6    orders o
  7    , customers c
  8  where
  9    o.customer_id = c.customer_id
 10*   and order_id < 2400

Explained.

ORCL@OE> @?/rdbms/admin/utlxpls

PLAN_TABLE_OUTPUT
----------------------------------------------------------------------------------------------
Plan hash value: 2552081916

----------------------------------------------------------------------------------------------
| Id  | Operation                     | Name         | Rows  | Bytes | Cost (%CPU)| Time     |
----------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT              |              |    46 |   552 |     3  (34)| 00:00:01 |
|   1 |  SORT UNIQUE NOSORT           |              |    46 |   552 |     3  (34)| 00:00:01 |
|   2 |   NESTED LOOPS SEMI           |              |    46 |   552 |     2   (0)| 00:00:01 |
|*  3 |    TABLE ACCESS BY INDEX ROWID| ORDERS       |    46 |   368 |     2   (0)| 00:00:01 |
|*  4 |     INDEX RANGE SCAN          | ORDER_PK     |    46 |       |     1   (0)| 00:00:01 |
|*  5 |    INDEX UNIQUE SCAN          | CUSTOMERS_PK |   319 |  1276 |     0   (0)| 00:00:01 |
----------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   3 - filter("O"."CUSTOMER_ID">0)
   4 - access("ORDER_ID"<2400)
   5 - access("O"."CUSTOMER_ID"="C"."CUSTOMER_ID")

目黒方面の密林で、美登利の寿司弁当を食べるのが最近のマイブームw

ではまた。

投稿日時 2019年3月21日 (木) 16時12分チューニング, FAQ, SQL, Oracle Database 11g, Oracle Database 11g Release 2, Oracle Database 12c release 1, パフォーマンス, Index Only Scan, Oracle Database 12c Release 2, Oracle Database 18c | 固定リンク | 0 | コメント (0)

2019年2月21日 (木)

Wait Events

データベース関連で待機イベントと言えば、これまでは、Oracle Database しか浮かばなかったわけですが、今は、PostgreSQL、そして、MySQL にも実装された。

待機イベントを知らずして、どうするの？　でも大丈夫。今までOracleの待機イベントに親しんできたデータベースエンジニアの活躍の場が広がるんじゃないかなぁ。。。と遠くをみている。。。

Oracle Database Wait Events

PostgreSQL Wait Events

MySQL : 25.12.15.1 Wait Event Summary Tables

投稿日時 2019年2月21日 (木) 21時29分 FAQ, Oracle Database 11g, Oracle Database 11g Release 2, MySQL, PostgreSQL, Oracle Database 12c release 1, Oracle Database 12c Release 2, Oracle Database 18c | 固定リンク | 0 | コメント (0) | トラックバック (0)

2019年2月11日 (月)

SQL*Plusでcsv出力できるんですよ #2 null はどうなる？ / FAQ

前回は、SQL*Plusでcsvファイルをお手軽にできることを確認したので、今回はもう少し細かいところを確認しておきます。

csvファイルを作成するOracle Databaseのバージョン等は以下のとおり。

SQL> select
  2    banner_full
  3  from
  4    v$version;

BANNER_FULL
--------------------------------------------------------------------------------
Oracle Database 18c Enterprise Edition Release 18.0.0.0.0 - Production
Version 18.3.0.0.0

データベースキャラクタセットは最近では一般的なAL32UTF8

SQL> r
  1  select
  2    parameter
  3    , value
  4  from
  5    nls_database_parameters
  6  where
  7*   parameter in ('NLS_CHARACTERSET')

PARAMETER                                VALUE
---------------------------------------- ------------------------------
NLS_CHARACTERSET                         AL32UTF8

SQL> 
SQL> !echo $NLS_LANG
Japanese_Japan.AL32UTF8

SQL> !echo $LANG
ja_JP.UTF-8

適当に作成した表は以下のとおり。NULLの取り込みを見ておきたかったのでnullも含めてあります。

SQL> desc test
 名前                                    NULL?    型
 ----------------------------------------- -------- ----------------------------
 ID                                        NOT NULL NUMBER
 DATA                                               VARCHAR2(10)
 FOO                                       NOT NULL VARCHAR2(10)
 
SQL> select * from test order by id;

        ID DATA       FOO
---------- ---------- ----------
         1 テスト     note
         2 平成       note
         3 abcdbef    note
         4 あ         note
         5 A          note
         6            note

6行が選択されました。

id=6のdata列は　null なのですが空白区別しにくいので可視化して確認しておきます。
注意）set null コマンドで設定した文字列は csv作成時のにも反映されるため空にリセットすることをお忘れなく。

SQL> set null [null]
SQL> select * from test order by id;

        ID DATA       FOO
---------- ---------- ----------
         1 テスト     note
         2 平成       note
         3 abcdbef    note
         4 あ         note
         5 A          note
         6 [null]     note

6行が選択されました。

SQL> set null ""

csvファイルの作成。スクリプトの例は前回の記事（SQL*Plusでcsv出力できるんですよ / FAQ）参照のこと。

SQL> @makecsv test
SQL> !cat loaddata_test.csv
1,"テスト","note"
2,"平成","note"
3,"abcdbef","note"
4,"あ","note"
5,"A","note"
6,,"note"

SQL> exit
Oracle Database 18c Enterprise Edition Release 18.0.0.0.0 - Productionとの接続が切断されました。
discus-mother:˜ oracle$

ということで、 nullは、,, としてcsvファイルに書き出されることを確認しました。
だたし、set nullでnullを他の文字列に置き換えている場合には、置換した文字列がそのままcsvファイルへかきだされてしまうので注意が必要です。

previously on Mac De Oracle
SQL*Plusでcsv出力できるんですよ / FAQ

数日前の朝、仕事先に向かおうとしら、ちょいと熱っぽい？、頭痛もあるな！　と体温を測ったら37度、インフル？
と思い仕事を休んで夕方まで様子見。。。熱は夜更けすぎに、平熱と変わっていましたw めでたしめでたし:) インフルじゃなくてよかった。
家庭内隔離解除されてほっとしているところ。。
では、また。

投稿日時 2019年2月11日 (月) 15時31分 FAQ, SQL, Oracle Database 11g, Oracle Database 11g Release 2, Oracle Database 12c release 1, Oracle Database 12c Release 2, Oracle Database 18c | 固定リンク | 0 | コメント (0) | トラックバック (0)

2018年5月 2日 (水)

Oracle Database Connect 2018 エキスパートはどう考えるか？体感！パフォーマンスチューニング Ⅱ （番外編＝没ネタ）

Oracle Database Connect 2018 エキスパートはどう考えるか？体感！パフォーマンスチューニング Ⅱ
～Autonomous Databaseの到来において必要となるチューニングとは～

これ、パフォーマンスチューニングネタをまとめ上げるまで、みなさんスケジュール調整し、
オンライン／オフラインミーティングを繰り返してネタを詰めていくという、かなーり面倒なことをやっています。
私なんて、ネタの候補検討だけで16時間ぐらい使ってますからねw（自分の余暇を使って、半分楽しみながら、締め切りがあるので半分苦しみながらw）

余談はこれくらいにして、今日の本題です。:)

Oracle Database Connect 2018 エキスパートはどう考えるか？体感！パフォーマンスチューニング Ⅱ で没にしたネタがあるのですが、
そのまま捨てるのも勿体ないので、多少取得情報を追加した状態で公開しちゃおうと思います。

お時間のありますときに、頭の体操、AWRレポートの解析方法（最近はADDM、ASHレポートまで含まれています）のトレーニングにどうぞ。

遅延原因の想定と、想定原因の特定情報は、このエントリ~~では公開しません。おそらくGW開けの12日あたりか、その一週間後の19日ごろには原因を公開しようかと:)~~の後半に追記してあります:)

なお、本ページに公開した情報以外に、追加で見たい情報がある場合は、コメント欄やtwのmentionで具体的にリクエストいただければ、取得されている情報の範囲内で追加公開します。取得されてない情報はその旨を追記していきます。:)
まずは、エスパー力全開で、原因を想定してみてください。>
(かなり難易度高めだとは思いますが、過去この状況に遭遇した経験をお持ちのかたは、ここに公開した程度の情報から勘で言い当てたりしちゃうんですよね。実は、昨年末に、何年か振りでこの症状を目にしたのでネタにしよう思いました。)

以下取得された情報は以下のとおり。以下の情報を元に遅延原因を想定してみてください。

なーんでだ？！

状況説明
試験時には問題のなかった処理（30分以内に終了する状態が正常な状態です。）をリリースしました。
ところが、30分以上経過しても終了しません。遅延原因を想定、特定してください。
なお、本番環境のメンテナンス時間中に試験を行ったため、データベースインスタンス内で試験を行いリリースしています。
ちなみに、試験時の処理時間は、約21分でしたが、リリース時は約56分と大幅に遅延。

他のトランザクションが走行している状況をミックスするとより
本物っぽくなり、特定に苦労するので面白いのですが、
遅延している処理だけが走行している状況にしてあります。

資料1 試験時（正常時）AWRレポート
 資料2 リリース時（遅延時）AWRレポート
 資料3 試験時（正常時）とリリース時（遅延時）のAWR DIFFレポート

資料4 試験時（正常時）CPU利用率グラフ(調査による多少のノイズあり）

資料5 リリース時（遅延時）CPU利用率グラグ(スパイク部分調査による多少のノイズあり）

GWも後半スタート、天気は少々荒れそうですが、みなさん、よいGWを！

Twitterでのやり取り....

ここまでくるとなにかが見えてきたかな。。。原因を特定するまであと一歩な感じ。

追加資料1（遅延時）
top

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
13058 oracle    20   0 10.434g 365704 359548 R 100.0  1.4   1:05.70 oracle_13058_or
 5973 oracle    20   0 1955632 253648  73812 S   4.7  1.0   1:42.62 gnome-shell
 4657 oracle    -2   0 10.417g  58792  55660 S   2.0  0.2   0:12.15 ora_vktm_orcl12
 1285 root      20   0  483544  76000  21372 S   1.7  0.3   0:55.11 Xorg
 4862 oracle    20   0 10.417g  68960  65868 S   1.3  0.3   0:01.23 ora_lg00_orcl12
  223 root      20   0       0      0      0 S   0.7  0.0   0:00.49 kworker/u24:3
13059 oracle    20   0  157976   4564   3544 R   0.7  0.0   0:00.29 top
   ...略...

追加資料2（遅延時）
sar -P ALL

   ...略...
02:47:29 AM    CPU     %user     %nice   %system   %iowait    %steal     %idle
02:47:34 AM    all      4.78      0.00      2.36      0.07      0.00     92.80
02:47:34 AM      0      1.06      0.00      1.06      0.85      0.00     97.03
02:47:34 AM      1      0.20      0.00      0.40      0.00      0.00     99.40
02:47:34 AM      2      0.00      0.00      0.00      0.00      0.00    100.00
02:47:34 AM      3      0.00      0.00      0.00      0.00      0.00    100.00
02:47:34 AM      4      0.00      0.00      0.20      0.00      0.00     99.80
02:47:34 AM      5      0.00      0.00      0.00      0.00      0.00    100.00
02:47:34 AM      6      0.00      0.00      0.00      0.00      0.00    100.00
02:47:34 AM      7     68.08      0.00     31.92      0.00      0.00      0.00
02:47:34 AM      8      0.00      0.00      0.00      0.00      0.00    100.00
02:47:34 AM      9      0.00      0.00      0.00      0.00      0.00    100.00
02:47:34 AM     10      0.00      0.00      0.00      0.00      0.00    100.00
02:47:34 AM     11      0.00      0.00      0.20      0.20      0.00     99.60
   ...略...

追加資料3（遅延時）
perf top -C 7

Samples: 107K of event 'cpu-clock', Event count (approx.): 29550214790                                                              

Overhead  Shared Object       Symbol
   4.36%  libc-2.17.so        [.] vfprintf
   2.77%  oracle              [.] lxoCpStr
   2.00%  [kernel]            [k] __radix_tree_lookup
   1.94%  oracle              [.] dbgfcsIlcsGetNextDef
   1.58%  oracle              [.] skgovprint
   1.48%  [kernel]            [k] __do_softirq
   1.44%  [kernel]            [k] selinux_file_permission
   1.43%  oracle              [.] dbgaFmtAttrCb_int
   1.36%  [kernel]            [k] system_call_after_swapgs
   1.33%  oracle              [.] dbgaAttrFmtProcArg
   1.26%  oracle              [.] dbgtfmWriteMetadata
   1.13%  oracle              [.] dbgtfdFileWrite
   1.02%  libc-2.17.so        [.] _IO_default_xsputn
   ...略...

その後のやりとり　（Twitter）

そして核心に迫る追加資料が...あったんです。（しばちょうさん風にはしづらかったw）

正常時（試験時）の追加情報はないようです。リリース後は常に遅いらしい。

ふむふむ。

以下、遅延時のstrace -c -pの情報を取得してもらいました。
straceで眺めるとsystem call write()がダントツで上位にきています。その次が lseek()

追加資料4
strace -c -p

[oracle@localhost ˜]$ sudo strace -c -p 13058
Process 13058 attached
^CProcess 13058 detached
% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
 77.24   47.883538           1  35085592           write
 19.22   11.913638           1  17542850           lseek
  3.53    2.191099           1   3414889           getrusage
  0.01    0.006377          12       524           semop
  0.00    0.000403           7        62           close
  0.00    0.000210           4        54           chown
  0.00    0.000126           2        63           open
  0.00    0.000099           2        54           lstat
  0.00    0.000050           1        54           chmod
  0.00    0.000029           1        54           stat
  0.00    0.000028           3        10           semtimedop
  0.00    0.000015           0        54           fcntl
  0.00    0.000010           1         8           read
  0.00    0.000007           1         8           select
  0.00    0.000000           0         3           mmap
  0.00    0.000000           0         6           rt_sigprocmask
  0.00    0.000000           0         1           rt_sigreturn
  0.00    0.000000           0         1           readlink
------ ----------- ----------- --------- --------- ----------------
100.00   61.995629              56044287           total

そろそろ突き止めた感が。

なにかを、どこかに、書き出してますよね。

lsofで書き込みに絞って取得してもった結果は以下のとおり。

[root@localhost ˜]# lsof -p 13058 | grep -E '[0-9]+w'
oracle_13 13058 oracle    1w      CHR    1,3         0t0      1038 /dev/null
oracle_13 13058 oracle    2w      CHR    1,3         0t0      1038 /dev/null
oracle_13 13058 oracle    7w      REG   8,17  2351882843  71176413 /u01/app/oracle/diag/rdbms/orcl12c/orcl12c/trace/orcl12c_ora_13058.trc
oracle_13 13058 oracle    8w      REG   8,17   358606101  71176414 /u01/app/oracle/diag/rdbms/orcl12c/orcl12c/trace/orcl12c_ora_13058.trm

ほう。　.trcファイルへ大量の書き込みがあります。

このようになるときは、なにが起っていると思いますか？

.trcファイルに大量の書き込みのあるケースとして、SQLトレースが有効になっている場合です。（意図したSQLトレースなら問題はないですが...意図していない場合はちょいと問題ですよね。）

ということで、確定診断に移りましょう。

SQL*Plus: Release 12.2.0.1.0 Production on Wed Apr 25 01:23:13 2018

Copyright (c) 1982, 2016, Oracle.  All rights reserved.

Connected.
ORCL@SYSTEM> 
ORCL@SYSTEM> select username,status,event,sql_trace from v$session where paddr = (select addr from v$process where spid = 13058)

USERNAME                       STATUS   EVENT                                                            SQL_TRAC
------------------------------ -------- ---------------------------------------------------------------- --------
SCOTT                          ACTIVE   log file switch completion                                       ENABLED

見ての通り、
SQL_TRACE列がdisabled（デフォルト)からenabledに変わっていることから、.trcファイルへの大量の書き出しは、セッションレベルでSQLトレースが有効化されたため、と言えますよね。

今回の新規リリースバッチ処理遅延の原因は、

SQLトレースを有効化したままリリースしたしまったことにより、オーバーヘッドが発生し、グルグル系バッチ処理のスループットが低下したため！　

ということでした。SQLトレースを利用したあとの無効化をお忘れなく！ :)

SQLトレースは便利な機能の一つですが、インスタンスレベルやグルグル系バッチ処理での利用時は大量のトレース情報の書き出し等によるオーバーヘッドが発生します。
便利なツールではありますが、スループットの低下等による影響を考慮して利用するタイプのツールでもあります。
また、利用した後は、必ず、無効化することもお忘れなく...

ミイラ取りがミイラになってしまってはいみないですから.....ね :)

投稿日時 2018年5月 2日 (水) 23時12分 PL/SQL, チューニング, SQL, Oracle Database 11g, Oracle Database 11g Release 2, Oracle Database 12c release 1, パフォーマンス, Oracle Database 12c Release 2, Oracle Database Connect | 固定リンク | 0 | コメント (0) | トラックバック (0)

2018年3月18日 (日)

Temp落ち #9 - 自動PGA管理で_pga_max_sizeと戯れたPGAサイズって本当に使えるのか？ 12.2.0.1版

Previously on Mac De Oracle

自動PGA管理下で、_pga_max_size隠しパラメータとpga_aggregate_targetを最大値に設定するした場合、global memory boundは
最大で、約839GBまで増加することがわかりました。

ただ、これは、内部的なパラメータ上の話。

今日は、実際にソートやハッシュ結合を行なわせ、PGAのSQL Work Areaサイズがどこまで利用できるものなのか確認してみることにします。

さて、どういう結末になりますやら（w

随分前から同じようなことを試している方はいますし....:)

なぜ今そこをdiggingしちゃってるのか？　って？

メモリーたっぷりあるのに、何故Temp落ち？　が話題になったからに決まってるじゃないですかw

まず、デフォルト設定では最大サイズだった　1GB を超えられるか？　の確認

注意） 事前にpga_aggregate_target および　_pga_max_size をそれぞれ 4TB - 1に設定し、パラメータの上では、global memory boundが約839GBにしてあります。

なお、Temp落ちの確認データやスクリプトはTemp落ち #4 - 手動PGA管理で作業領域として指定可能な最大サイズ de Temp落ちの確認のエントリーを参照のこと。

ソートやハッシュ結合は2GB程度になるように調整しています。
2GBのソート

ORCL@SCOTT> @auto_sortwk2gb_optimal.sql

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
workarea_size_policy                 string      AUTO

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
pga_aggregate_target                 big integer 4398046511103

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
_pga_max_size                        big integer 4398046511103

NAME                                                                        VALUE UNIT             CON_ID
---------------------------------------------------------------- ---------------- ------------ ----------
global memory bound                                                  879609302016 bytes                 0

  1  SELECT
  2      /*+
  3          MONITOR
  4      */
  5      *
  6  FROM
  7      m1
  8  WHERE
  9      id <= 'C750000'
 10  ORDER BY
 11      id
 12*     ,rev#
old   1: select dbms_sqltune.report_sql_monitor(sql_id=>'&1', type=>'text') from dual
new   1: select dbms_sqltune.report_sql_monitor(sql_id=>'', type=>'text') from dual

DBMS_SQLTUNE.REPORT_SQL_MONITOR(SQL_ID=>'',TYPE=>'TEXT')
------------------------------------------------------------------------------------------
SQL Monitoring Report

・・・中略・・・

SQL Plan Monitoring Details (Plan Hash Value=3534657201)
========================================================================================================================================================
| Id |      Operation       | Name |  Rows   | Cost  |   Time    | Start  | Execs |   Rows   | Read | Read  |  Mem  | Activity |    Activity Detail    |
|    |                      |      | (Estim) |       | Active(s) | Active |       | (Actual) | Reqs | Bytes | (Max) |   (%)    |      (# samples)      |
========================================================================================================================================================
|  0 | SELECT STATEMENT     |      |         |       |        34 |     +2 |     1 |       1M |      |       |     . |     5.26 | Cpu (1)               |
|  1 |   SORT ORDER BY      |      |      1M |  553K |        34 |     +2 |     1 |       1M |      |       |   2GB |    26.32 | Cpu (5)               |
|  2 |    TABLE ACCESS FULL | M1   |      1M | 90829 |        17 |     +1 |     1 |       1M | 2637 |   3GB |     . |    68.42 | Cpu (3)               |
|    |                      |      |         |       |           |        |       |          |      |       |       |          | direct path read (10) |
========================================================================================================================================================

2GBのハッシュ結合

ORCL@SCOTT> @auto_hashwk2gb_optimal.sql

・・・中略・・・

NAME                                                                     VALUE UNIT             CON_ID
---------------------------------------------------------------- ------------- ------------ ----------
global memory bound                                               879609302016 bytes                 0

  1  SELECT
  2      /*+
  3          MONITOR
  4          LEADING(m1 m2)
  5          USE_HASH(m2)
  6      */
  7      *
  8  FROM
  9      m1
 10      INNER JOIN m2
 11      ON
 12          m1.id = m2.id
 13          AND m1.rev# = m2.rev#
 14  WHERE
 15*     m1.id <= 'C084000'
old   1: select dbms_sqltune.report_sql_monitor(sql_id=>'&1', type=>'text') from dual
new   1: select dbms_sqltune.report_sql_monitor(sql_id=>'', type=>'text') from dual

DBMS_SQLTUNE.REPORT_SQL_MONITOR(SQL_ID=>'',TYPE=>'TEXT')
------------------------------------------------------------------------------------------
SQL Monitoring Report

・・・中略・・・

SQL Plan Monitoring Details (Plan Hash Value=1822065247)
===========================================================================================================================================================
| Id |      Operation       | Name |  Rows   | Cost  |   Time    | Start  | Execs |   Rows   | Read | Read  |  Mem  | Activity |     Activity Detail      |
|    |                      |      | (Estim) |       | Active(s) | Active |       | (Actual) | Reqs | Bytes | (Max) |   (%)    |       (# samples)        |
===========================================================================================================================================================
|  0 | SELECT STATEMENT     |      |         |       |        37 |     +2 |     1 |     840K |      |       |     . |     4.35 | Cpu (1)                  |
|  1 |   HASH JOIN          |      |    843K |  351K |        37 |     +2 |     1 |     840K |      |       |   2GB |    26.09 | Cpu (5)                  |
|    |                      |      |         |       |           |        |       |          |      |       |       |          | PGA memory operation (1) |
|  2 |    TABLE ACCESS FULL | M1   |    843K | 90828 |        15 |     +1 |     1 |     840K | 2633 |   3GB |     . |    52.17 | Cpu (1)                  |
|    |                      |      |         |       |           |        |       |          |      |       |       |          | direct path read (11)    |
|  3 |    TABLE ACCESS FULL | M2   |    846K | 90581 |        23 |    +16 |     1 |     840K | 2619 |   3GB |     . |    17.39 | Cpu (2)                  |
|    |                      |      |         |       |           |        |       |          |      |       |       |          | direct path read (2)     |
===========================================================================================================================================================

ソートやハッシュ結合は4GB程度になるように調整しています。
見ての通り、ソートは4GBのメモリー内ソートですが、ハッシュ結合は、2GBまで使ったところで Temp落ち！（こんなもんなんですよ。実は!)
4GBのソート

ORCL@SCOTT> @auto_sortwk4gb_optimal.sql

・・・中略・・・

NAME                                                                     VALUE UNIT             CON_ID
---------------------------------------------------------------- ------------- ------------ ----------
global memory bound                                               879609302016 bytes                 0

  1  SELECT
  2      /*+
  3          MONITOR
  4      */
  5      *
  6  FROM
  7      m1
  8  WHERE
  9      id <= 'C085000'
 10  UNION ALL
 11  SELECT *
 12  FROM
 13      m1 m12
 14  WHERE
 15      id <= 'C085000'
 16  ORDER BY
 17*     1, 2
old   1: select dbms_sqltune.report_sql_monitor(sql_id=>'&1', type=>'text') from dual
new   1: select dbms_sqltune.report_sql_monitor(sql_id=>'', type=>'text') from dual

DBMS_SQLTUNE.REPORT_SQL_MONITOR(SQL_ID=>'',TYPE=>'TEXT')
-----------------------------------------------------------------------------------------
SQL Monitoring Report

・・・中略・・・

SQL Plan Monitoring Details (Plan Hash Value=2686238998)
============================================================================================================================================================
| Id |       Operation       | Name |  Rows   | Cost  |   Time    | Start  | Execs |   Rows   | Read | Read  |  Mem  | Activity |     Activity Detail      |
|    |                       |      | (Estim) |       | Active(s) | Active |       | (Actual) | Reqs | Bytes | (Max) |   (%)    |       (# samples)        |
============================================================================================================================================================
|  0 | SELECT STATEMENT      |      |         |       |        40 |     +2 |     1 |       2M |      |       |     . |    27.78 | Cpu (5)                  |
|  1 |   SORT ORDER BY       |      |      2M |  182K |        41 |     +1 |     1 |       2M |      |       |   4GB |    38.89 | Cpu (6)                  |
|    |                       |      |         |       |           |        |       |          |      |       |       |          | PGA memory operation (1) |
|  2 |    UNION-ALL          |      |         |       |        12 |     +2 |     1 |       2M |      |       |     . |          |                          |
|  3 |     TABLE ACCESS FULL | M1   |    855K | 90828 |         6 |     +2 |     1 |     850K | 2633 |   3GB |     . |    22.22 | Cpu (2)                  |
|    |                       |      |         |       |           |        |       |          |      |       |       |          | direct path read (2)     |
|  4 |     TABLE ACCESS FULL | M1   |    855K | 90828 |         6 |     +8 |     1 |     850K | 2633 |   3GB |     . |    11.11 | Cpu (2)                  |
============================================================================================================================================================

4GBのハッシュ結合 最大3GBのPGAが消費されていますが、Temp落ちしないサイズ、つまり、optimalで処理する場合には、最大2GBが最大サイズとなっています。以下を3GBのハッシュ結合にすると、2GBまでPGAを消費し、一時表領域が3GB利用されます。

ORCL@SCOTT> @auto_hashwk4gb_optimal.sql
old   1: select dbms_sqltune.report_sql_monitor(sql_id=>'&1', type=>'text') from dual
new   1: select dbms_sqltune.report_sql_monitor(sql_id=>'', type=>'text') from dual

DBMS_SQLTUNE.REPORT_SQL_MONITOR(SQL_ID=>'',TYPE=>'TEXT')
------------------------------------------------------------------------------------------
SQL Monitoring Report

・・・中略・・・

SQL Plan Monitoring Details (Plan Hash Value=3532417599)
=========================================================================================================================================================================================
| Id |       Operation        | Name |  Rows   | Cost  |   Time    | Start  | Execs |   Rows   | Read  | Read  | Write | Write |  Mem  | Temp  | Activity |       Activity Detail       |
|    |                        |      | (Estim) |       | Active(s) | Active |       | (Actual) | Reqs  | Bytes | Reqs  | Bytes | (Max) | (Max) |   (%)    |         (# samples)         |
=========================================================================================================================================================================================
|  0 | SELECT STATEMENT       |      |         |       |       216 |     +2 |     1 |       3M |       |       |       |       |     . |     . |     4.49 | Cpu (7)                     |
|  1 |   HASH JOIN            |      |      2M |  670K |       217 |     +1 |     1 |       3M | 18091 |   4GB | 18091 |   4GB |   3GB |   4GB |    79.49 | Cpu (87)                    |
|    |                        |      |         |       |           |        |       |          |       |       |       |       |       |       |          | direct path read temp (19)  |
|    |                        |      |         |       |           |        |       |          |       |       |       |       |       |       |          | direct path write temp (18) |
|  2 |    VIEW                |      |      2M |  182K |         9 |     +2 |     1 |       2M |       |       |       |       |     . |     . |          |                             |
|  3 |     UNION-ALL          |      |         |       |         9 |     +2 |     1 |       2M |       |       |       |       |     . |     . |          |                             |
|  4 |      TABLE ACCESS FULL | M1   |    752K | 90828 |         5 |     +2 |     1 |     750K |  2633 |   3GB |       |       |     . |     . |     1.92 | Cpu (3)                     |
|  5 |      TABLE ACCESS FULL | M1   |    752K | 90828 |         4 |     +7 |     1 |     750K |  2633 |   3GB |       |       |     . |     . |     1.92 | Cpu (3)                     |
|  6 |    VIEW                |      |      2M |  181K |        78 |    +99 |     1 |       2M |       |       |       |       |     . |     . |     0.64 | Cpu (1)                     |
|  7 |     UNION-ALL          |      |         |       |        78 |    +99 |     1 |       2M |       |       |       |       |     . |     . |          |                             |
|  8 |      TABLE ACCESS FULL | M2   |    759K | 90581 |        50 |    +92 |     1 |     750K |  2618 |   3GB |       |       |     . |     . |     9.62 | Cpu (2)                     |
|    |                        |      |         |       |           |        |       |          |       |       |       |       |       |       |          | direct path read (13)       |
|  9 |      TABLE ACCESS FULL | M2   |    759K | 90581 |        36 |   +141 |     1 |     750K |  2618 |   3GB |       |       |     . |     . |     1.92 | Cpu (2)                     |
|    |                        |      |         |       |           |        |       |          |       |       |       |       |       |       |          | direct path read (1)        |
=========================================================================================================================================================================================

では、最後に
ソートやハッシュ結合のサイズが8GB程度ならどうでしょうか？
結果は、ソートは4GBを使い切ったのち、Temp落ち、ハッシュ結合は、やはり、3GBまで利用したのちTemp落ちでした。なんと！（ちょっとわざとらしいリアクションしてすみませんw）

8GBのソート

ORCL@SCOTT> @auto_sortwk8gb_optimal.sql

・・・中略・・・

NAME                                                                     VALUE UNIT             CON_ID
---------------------------------------------------------------- ------------- ------------ ----------
global memory bound                                               879609302016 bytes                 0

  1  SELECT
  2      /*+
  3          MONITOR
  4      */
  5      *
  6  FROM
  7      m1
  8  WHERE
  9      id <= 'C090000'
 10  UNION ALL
 11  SELECT *
 12  FROM
 13      m1 m12
 14  WHERE
 15      id <= 'C090000'
 16  UNION ALL
 17  SELECT *
 18  FROM
 19      m1 m13
 20  WHERE
 21      id <= 'C090000'
 22  UNION ALL
 23  SELECT *
 24  FROM
 25      m1 m14
 26  WHERE
 27      id <= 'C090000'
 28  ORDER BY
 29*     1, 2
old   1: select dbms_sqltune.report_sql_monitor(sql_id=>'&1', type=>'text') from dual
new   1: select dbms_sqltune.report_sql_monitor(sql_id=>'', type=>'text') from dual

DBMS_SQLTUNE.REPORT_SQL_MONITOR(SQL_ID=>'',TYPE=>'TEXT')
------------------------------------------------------------------------------------------
SQL Monitoring Report

・・・中略・・・

SQL Plan Monitoring Details (Plan Hash Value=946172832)
=========================================================================================================================================================================================
| Id |       Operation       | Name |  Rows   | Cost  |   Time    | Start  | Execs |   Rows   | Read  | Read  | Write | Write |  Mem  | Temp  | Activity |       Activity Detail        |
|    |                       |      | (Estim) |       | Active(s) | Active |       | (Actual) | Reqs  | Bytes | Reqs  | Bytes | (Max) | (Max) |   (%)    |         (# samples)          |
=========================================================================================================================================================================================
|  0 | SELECT STATEMENT      |      |         |       |       279 |     +2 |     1 |       4M |       |       |       |       |     . |     . |     5.79 | Cpu (6)                      |
|    |                       |      |         |       |           |        |       |          |       |       |       |       |       |       |          | PGA memory operation (1)     |
|    |                       |      |         |       |           |        |       |          |       |       |       |       |       |       |          | local write wait (7)         |
|  1 |   SORT ORDER BY       |      |      4M |  363K |       279 |     +2 |     1 |       4M | 38603 |   8GB | 32072 |   8GB |   4GB |   8GB |    84.30 | Cpu (49)                     |
|    |                       |      |         |       |           |        |       |          |       |       |       |       |       |       |          | PGA memory operation (1)     |
|    |                       |      |         |       |           |        |       |          |       |       |       |       |       |       |          | direct path read temp (28)   |
|    |                       |      |         |       |           |        |       |          |       |       |       |       |       |       |          | direct path write temp (126) |
|  2 |    UNION-ALL          |      |         |       |       176 |     +2 |     1 |       4M |       |       |       |       |     . |     . |          |                              |
|  3 |     TABLE ACCESS FULL | M1   |    907K | 90828 |        16 |     +1 |     1 |     900K |  2633 |   3GB |       |       |     . |     . |     4.55 | Cpu (2)                      |
|    |                       |      |         |       |           |        |       |          |       |       |       |       |       |       |          | direct path read (9)         |
|  4 |     TABLE ACCESS FULL | M1   |    907K | 90828 |         8 |    +17 |     1 |     900K |  2633 |   3GB |       |       |     . |     . |     2.48 | Cpu (5)                      |
|    |                       |      |         |       |           |        |       |          |       |       |       |       |       |       |          | direct path read (1)         |
|  5 |     TABLE ACCESS FULL | M1   |    907K | 90828 |        79 |    +26 |     1 |     900K |  2633 |   3GB |       |       |     . |     . |     2.48 | Cpu (2)                      |
|    |                       |      |         |       |           |        |       |          |       |       |       |       |       |       |          | direct path read (4)         |
|  6 |     TABLE ACCESS FULL | M1   |    907K | 90828 |        72 |   +106 |     1 |     900K |  2633 |   3GB |       |       |     . |     . |     0.41 | Cpu (1)                      |
=========================================================================================================================================================================================

8GBのハッシュ結合

ORCL@SCOTT> @auto_hashwk8gb_optimal.sql

・・・中略・・・

NAME                                                                     VALUE UNIT             CON_ID
---------------------------------------------------------------- ------------- ------------ ----------
global memory bound                                               879609302016 bytes                 0

  1  SELECT
  2      /*+
  3          MONITOR
  4          LEADING(m1 m2)
  5          USE_HASH(m2)
  6      */
  7      *
  8  FROM
  9      (
 10          SELECT * FROM m1 m11
 11          UNION ALL
 12          SELECT * FROM m1 m12
 13          UNION ALL
 14          SELECT * FROM m1 m13
 15      ) m1
 16      INNER JOIN
 17      (
 18          SELECT * FROM m2 m21
 19          UNION ALL
 20          SELECT * FROM m2 m22
 21          UNION ALL
 22          SELECT * FROM m2 m23
 23      ) m2
 24      ON
 25          m1.id = m2.id
 26          AND m1.rev# = m2.rev#
 27  WHERE
 28*     m1.id <= 'C075000'
old   1: select dbms_sqltune.report_sql_monitor(sql_id=>'&1', type=>'text') from dual
new   1: select dbms_sqltune.report_sql_monitor(sql_id=>'', type=>'text') from dual

DBMS_SQLTUNE.REPORT_SQL_MONITOR(SQL_ID=>'',TYPE=>'TEXT')
------------------------------------------------------------------------------------------
SQL Monitoring Report

・・・中略・・・

SQL Plan Monitoring Details (Plan Hash Value=2506347387)
=========================================================================================================================================================================================
| Id |       Operation        | Name |  Rows   | Cost  |   Time    | Start  | Execs |   Rows   | Read  | Read  | Write | Write |  Mem  | Temp  | Activity |       Activity Detail       |
|    |                        |      | (Estim) |       | Active(s) | Active |       | (Actual) | Reqs  | Bytes | Reqs  | Bytes | (Max) | (Max) |   (%)    |         (# samples)         |
=========================================================================================================================================================================================
|  0 | SELECT STATEMENT       |      |         |       |       350 |     +2 |     1 |       7M |       |       |       |       |     . |     . |     9.18 | Cpu (18)                    |
|    |                        |      |         |       |           |        |       |          |       |       |       |       |       |       |          | PGA memory operation (1)    |
|  1 |   HASH JOIN            |      |      5M |    1M |       350 |     +2 |     1 |       7M | 31032 |   7GB | 31032 |   7GB |   3GB |   8GB |    67.15 | Cpu (81)                    |
|    |                        |      |         |       |           |        |       |          |       |       |       |       |       |       |          | direct path read temp (36)  |
|    |                        |      |         |       |           |        |       |          |       |       |       |       |       |       |          | direct path write temp (22) |
|  2 |    VIEW                |      |      2M |  272K |        27 |     +2 |     1 |       2M |       |       |       |       |     . |     . |          |                             |
|  3 |     UNION-ALL          |      |         |       |        27 |     +2 |     1 |       2M |       |       |       |       |     . |     . |     0.97 | Cpu (2)                     |
|  4 |      TABLE ACCESS FULL | M1   |    752K | 90828 |        16 |     +1 |     1 |     750K |  2633 |   3GB |       |       |     . |     . |     7.25 | Cpu (3)                     |
|    |                        |      |         |       |           |        |       |          |       |       |       |       |       |       |          | direct path read (12)       |
|  5 |      TABLE ACCESS FULL | M1   |    752K | 90828 |         5 |    +18 |     1 |     750K |  2633 |   3GB |       |       |     . |     . |     1.45 | Cpu (2)                     |
|    |                        |      |         |       |           |        |       |          |       |       |       |       |       |       |          | direct path read (1)        |
|  6 |      TABLE ACCESS FULL | M1   |    752K | 90828 |         7 |    +23 |     1 |     750K |  2633 |   3GB |       |       |     . |     . |     1.93 | Cpu (2)                     |
|    |                        |      |         |       |           |        |       |          |       |       |       |       |       |       |          | direct path read (2)        |
|  7 |    VIEW                |      |      2M |  272K |       130 |    +97 |     1 |       2M |       |       |       |       |     . |     . |          |                             |
|  8 |     UNION-ALL          |      |         |       |       130 |    +97 |     1 |       2M |       |       |       |       |     . |     . |     0.48 | Cpu (1)                     |
|  9 |      TABLE ACCESS FULL | M2   |    759K | 90581 |        47 |    +88 |     1 |     750K |  2618 |   3GB |       |       |     . |     . |     4.83 | Cpu (3)                     |
|    |                        |      |         |       |           |        |       |          |       |       |       |       |       |       |          | direct path read (7)        |
| 10 |      TABLE ACCESS FULL | M2   |    759K | 90581 |        41 |   +134 |     1 |     750K |  2618 |   3GB |       |       |     . |     . |     4.35 | Cpu (5)                     |
|    |                        |      |         |       |           |        |       |          |       |       |       |       |       |       |          | direct path read (4)        |
| 11 |      TABLE ACCESS FULL | M2   |    759K | 90581 |        53 |   +174 |     1 |     750K |  2618 |   3GB |       |       |     . |     . |     2.42 | Cpu (1)                     |
|    |                        |      |         |       |           |        |       |          |       |       |       |       |       |       |          | direct path read (4)        |
=========================================================================================================================================================================================

これ、Linuxのカーネルパラメータのvm.max_map_count

/proc/sys/vm/max_map_count

65530

が絡んでるよねという話と、隠しパラメータの realfree_heap関連のパラメータでも調整できそうだよね。という話はあるんですが...それはPL/SQLのはなし...で


_realfree_heap_pagesize                        65536                          TRUE
_use_realfree_heap                             TRUE                           TRUE

とりあえず、
vm/max_map_countを196608

にして
_realfree_heap_pagesize=65536 や
_realfree_heap_pagesize=256K

などとして戯れてみましたが

ソートやハッシュ結合で利用可能なサイズは、それらで制御できるものでもありません。いまのところ。

ORCL@SCOTT> @auto_sortwk8gb_optimal.sql

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
workarea_size_policy                 string      AUTO

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
pga_aggregate_target                 big integer 4398046511103

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
_pga_max_size                        big integer 4398046511103

NAME                                                                     VALUE UNIT             CON_ID
---------------------------------------------------------------- ------------- ------------ ----------
global memory bound                                               879609302016 bytes                 0

/proc/sys/vm/max_map_count
196608

  1  SELECT
  2      /*+
  3          MONITOR
  4      */
  5      *
  6  FROM
  7      m1
  8  WHERE
  9      id <= 'C090000'
 10  UNION ALL
 11  SELECT *
 12  FROM
 13      m1 m12
 14  WHERE
 15      id <= 'C090000'
 16  UNION ALL
 17  SELECT *
 18  FROM
 19      m1 m13
 20  WHERE
 21      id <= 'C090000'
 22  UNION ALL
 23  SELECT *
 24  FROM
 25      m1 m14
 26  WHERE
 27      id <= 'C090000'
 28  ORDER BY
 29*     1, 2
old   1: select dbms_sqltune.report_sql_monitor(sql_id=>'&1', type=>'text') from dual
new   1: select dbms_sqltune.report_sql_monitor(sql_id=>'', type=>'text') from dual

DBMS_SQLTUNE.REPORT_SQL_MONITOR(SQL_ID=>'',TYPE=>'TEXT')
------------------------------------------------------------------------------------------
SQL Monitoring Report

・・・中略・・・

SQL Plan Monitoring Details (Plan Hash Value=946172832)
=========================================================================================================================================================================================
| Id |       Operation       | Name |  Rows   | Cost  |   Time    | Start  | Execs |   Rows   | Read  | Read  | Write | Write |  Mem  | Temp  | Activity |       Activity Detail        |
|    |                       |      | (Estim) |       | Active(s) | Active |       | (Actual) | Reqs  | Bytes | Reqs  | Bytes | (Max) | (Max) |   (%)    |         (# samples)          |
=========================================================================================================================================================================================
|  0 | SELECT STATEMENT      |      |         |       |       295 |     +2 |     1 |       4M |       |       |       |       |     . |     . |     3.38 | Cpu (8)                      |
|  1 |   SORT ORDER BY       |      |      4M |  363K |       297 |     +1 |     1 |       4M | 38603 |   8GB | 38600 |   8GB |   4GB |   8GB |    91.56 | Cpu (43)                     |
|    |                       |      |         |       |           |        |       |          |       |       |       |       |       |       |          | direct path read temp (12)   |
|    |                       |      |         |       |           |        |       |          |       |       |       |       |       |       |          | direct path write temp (162) |
|  2 |    UNION-ALL          |      |         |       |       205 |     +2 |     1 |       4M |       |       |       |       |     . |     . |     0.84 | Cpu (2)                      |
|  3 |     TABLE ACCESS FULL | M1   |    907K | 90828 |         6 |     +2 |     1 |     900K |  2633 |   3GB |       |       |     . |     . |     2.11 | Cpu (1)                      |
|    |                       |      |         |       |           |        |       |          |       |       |       |       |       |       |          | direct path read (4)         |
|  4 |     TABLE ACCESS FULL | M1   |    907K | 90828 |         7 |     +8 |     1 |     900K |  2633 |   3GB |       |       |     . |     . |     0.42 | Cpu (1)                      |
|  5 |     TABLE ACCESS FULL | M1   |    907K | 90828 |       100 |    +14 |     1 |     900K |  2633 |   3GB |       |       |     . |     . |     0.84 | Cpu (2)                      |
|  6 |     TABLE ACCESS FULL | M1   |    907K | 90828 |        94 |   +113 |     1 |     900K |  2633 |   3GB |       |       |     . |     . |     0.84 | Cpu (2)                      |
=========================================================================================================================================================================================

ちなみに、PL/SQLで巨大なPGAメモリーを利用する場合は、しっかり9GBとか...やばい状態になったら、pga_aggregate_limitで抑えてくれると思いますが.....

[oracle@localhost ˜]$ ulimit -v -m
virtual memory          (kbytes, -v) unlimited
max memory size         (kbytes, -m) unlimited

orcl12c@SYS> @show_param

KSPPINM                                        KSPPSTVL                       KSPPSTDF
---------------------------------------------- ------------------------------ ------------------------------
_pga_max_size                                  4398046511103                  FALSE
_realfree_heap_pagesize                        65536                          TRUE
_use_realfree_heap                             TRUE                           TRUE
pga_aggregate_limit                            0                              FALSE
pga_aggregate_target                           4398046511103                  FALSE


/proc/sys/vm/max_map_count
65530

PGAを大量に消費するスクリプトは以下のブログを参考に
Max PGA Research: Check that a process can allocate a large volume of memory / Yury's Blog


ORCL@SCOTT> @plsql_pga8gb 8192
old   2: c_count number := 1024*&1;
new   2: c_count number := 1024*8192;

PL/SQL procedure successfully completed.

実際に確保されたPGAサイズなど。。。

ORCL@SCOTT> r
  1  select
  2  	vss.value/1024/1024/1024 "GB"
  3  	,vsn.name
  4  	,vss.sid
  5  from
  6  	v$sesstat vss
  7  	inner join v$statname vsn
  8  	on
  9  		vss.statistic# = vsn.statistic#
 10  		and vss.con_id = vsn.con_id
 11  		and (vsn.name like '%pga%' or vsn.name like '%uga%')
 12  where
 13  	sid IN (select sid from v$session where username='SCOTT')
 14  order by
 15* 	sid,name

        GB NAME                                                                    SID
---------- ---------------------------------------------------------------- ----------
9.49698084 session pga memory                                                      321
9.49698084 session pga memory max                                                  321
1.48221001 session uga memory                                                      321
3.99991362 session uga memory max                                                  321

[oracle@localhost ˜]$ free -h
              total        used        free      shared  buff/cache   available
Mem:            22G        1.0G        9.6G         11G         11G         10G
Swap:          4.0G        8.7M        4.0G

・・・中略・・・

[oracle@localhost ˜]$ free -h
              total        used        free      shared  buff/cache   available
Mem:            22G         10G        128M         11G         11G        705M
Swap:          4.0G        8.8M        4.0G

ここまでくればおわかりだと思いますが、global memory bound (約839GB)からは巨大なPGAサイズになりそうに思えますが、Temp落ちせずにソート可能なサイズは、隠しパラメータを調整した場合でも最大4GB、ハッシュ結合は、2GBが上限、となっています。いまのところ。。。。

ということは、2014年の以下のプレゼンでも話題になっていましたよね。:)
Overcome Oracle PGA Memory Limits Mar.5.2014 Alex Fatkulin / Enkatic

だったら、どのようにして、Temp落ち　に立ち向かえばいいんだろう.....次回へ続く　:)

10gR2(64bit)のころのままなので、以下のシリーズも合わせて読んでおくといいですよ：）

・Temp落ち #1 - "Temp落ち" って？
・Temp落ち #2 - PGA (Program Global Area)
・Temp落ち #3 - 手動PGA管理で作業領域として指定可能な最大サイズ
・Temp落ち #4 - 手動PGA管理で作業領域として指定可能な最大サイズ de Temp落ちの確認
・Temp落ち #5 - pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? 12.2.0.1版（その前に少し脱線）
・Temp落ち #6 - pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? 12.2.0.1版
・Temp落ち #7 - 自動PGA管理で到達可能な最大サイズ de Temp落ちの確認 12.2.0.1版
・Temp落ち #8 - 自動PGA管理でパラメータ上設定可能な最大サイズは？（実際に利用可能なサイズとは限りませんが。意味深） 12.2.0.1版

投稿日時 2018年3月18日 (日) 13時25分チューニング, FAQ, SQL, Oracle Database 11g, Oracle Database 11g Release 2, Oracle Database 12c release 1, パフォーマンス, Oracle Database 12c Release 2 | 固定リンク | 0 | コメント (0) | トラックバック (0)

2018年3月12日 (月)

Temp落ち #8 - 自動PGA管理でパラメータ上設定可能な最大サイズは？（実際に利用可能なサイズとは限りませんが。意味深） 12.2.0.1版

Previously on Mac De Oracle

自動PGA管理下では、SQL Work Areaサイズは、pga_aggregate_targetのサイズに応じて変化し、最大1GBまで調整され、それのサイズ以上のソートやハッシュ結合は、もれなく、"Temp落ち" する。
手動PGA管理下では、最大2GBまで指定できました。。自動だと1GBまでなのか。。。と残念がる声が、昔は海だった方面から聞こえた気がしましたが、たぶん、気のせいw

というところまででした。

今日は、自動PGA管理下ではそれが最大なのか？　のか？　自己責任で試してみることにしますw

まずはこれまでの復習。

自動PGA管理で、SQL Work Areaサイズの算出に関わるパラメータは以下の通り

pga_aggregate_target = 10MB 〜 4TB - 1
_pga_max_size = 200MB 〜　2GB
（Oracleが動的に値を調整している_pga_max_sizeパラメータへユーザーが値を設定してしまうとOracleの自動調整が無効化され、設定した値で固定されてしまうので注意が必要です。）

私の観測範囲だとおおよそ以下のように変化します。最近は大量のメモリーを搭載したサーバーが多いので、pga_aggregate_targetが10GB以上という状況も普通になってきたので、自動PGA管理下のSQL Work Areaサイズは最大1GBとざっくり丸暗記しても困ることは思いますw（ちょっと乱暴かw）

pga_aggregate_target = 10MB〜10GB - 1 :
_pga_max_size = 200MB 〜　2047MB
GREATEST(pga_aggregate_target*0.2 ,200MB)

pga_aggregate_target = 10GB以上〜4TB-1 :
_pga_max_size = 2GB
LEAST(pga_aggregate_target*0.2 ,2GB)

_pga_max_sizeはpga_aggregate_targetの値に応じて動的に変化し、それらを元に _smm_max_size が算出される

LEAST(pga_aggregate_target * 0.2, _pga_max_size * 0.5)

pga_aggregate_target = 10MB〜10GB-1
_pga_max_size = 200MB〜2047MB
_smm_max_size = 2MB〜1023MB

pga_aggregate_target = 10GB〜4TB-1
_pga_max_size = 2048MB
_smm_max_size = 1024MB

_smm_max_sizeは、v$pgastatのglobal memory boundだろうということは確からしいということまでは確認しました。

いままでの結果をまとめると
PGAのSQL Work Areaサイズの最大サイズを示す global memory boundは、pga_aggregate_targetが10MB〜10GB-1までは2MB〜1023MBで調整され、pga_aggregate_targetが10GB〜4TB-1では、1024MB (1GB) で固定されている、というのが、Oracle 10GR2〜12cR2まで動きであることは間違いなさそう:)

自動PGA管理下でSQL Work Areaを1GBを超えるサイズにするにはどのパラメータをどのような値に設定すればよいか。。。
その鍵を握るパラメータは

_pga_max_size

(いまいちピンとこないという方は、過去のエントリーを参照していただけるとスッキリすると思います。）

ただ、冒頭にも書きましたが（昔それでハマったw）、（Oracleが動的に値を調整している_pga_max_sizeパラメータへユーザーが値を設定してしまうとOracleの自動調整が無効化され、設定した値で固定されてしまうので注意が必要です。）
という点はお忘れなく。また、今後も同仕様のままである保証はなく、世界中のOracle使いの方達が調べ上げた結果、現状はこんな感じ。
という状況だと認識しておいたほうが無難だと思っています。

とはいえ、実際どこまで設定可能なのか？　　1GBを以上使えるのか？　知りたいですよね...

長い前置きはこれぐらいにして、
実際にSQL Work Areaサイズに対応したメモリーが実際にどの程度割り当てられるのかということの確認は後回しですが、パラメータの上では、どこまで設定できるのかというところを確認しました。

なお、
以下のエラーメッセージから、_pga_max_sizeに設定可能な値は、pga_aggregate_targetと同様（Big Integer）、10MB〜4TB-1までであると思われます。

orcl12c@SYS> show parameter _pga_max_size

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
_pga_max_size                        big integer 2G

orcl12c@SYS> alter system set "_pga_max_size" = 4T scope=memory;
alter system set "_pga_max_size" = 4T scope=memory
*
行1でエラーが発生しました。:
ORA-02097: 指定した値が無効なので、パラメータを変更できません。 ORA-00093:
_pga_max_sizeは、10Mから4096G-1の間に設定する必要があります。

ということで、
_pga_max_sizeを1GB/10GB/100GB/1TB/4T-1のそれぞれに設定したうえで、Temp落ち #6 - pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? 12.2.0.1版で利用したスクリプトを利用し、global memory boundやその他パラメータの変化を確認しました。

ログの例

orcl12c@SYS> alter system set "_pga_max_size" = 10m scope=both;

システムが変更されました。

orcl12c@SYS> show parameter _pga_max_size

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
_pga_max_size                        big integer 10m


orcl12c@SYS> @dotest_auto_workarea
<< 10m >>
接続されました。
  1* alter system set pga_aggregate_target=&1 scope=spfile
旧   1: alter system set pga_aggregate_target=&1 scope=spfile
新   1: alter system set pga_aggregate_target=10m scope=spfile

システムが変更されました。

データベースがクローズされました。
データベースがディスマウントされました。
ORACLEインスタンスがシャットダウンされました。
ORACLEインスタンスが起動しました。

Total System Global Area 2147483648 bytes
Fixed Size                  8794848 bytes
Variable Size             603983136 bytes
Database Buffers         1526726656 bytes
Redo Buffers                7979008 bytes
データベースがマウントされました。
データベースがオープンされました。
+++ initial parameters +++

KSPPINM                                        KSPPSTVL                       KSPPSTDF
---------------------------------------------- ------------------------------ ------------------------------
__pga_aggregate_target                         16777216                       FALSE

・・・中略・・・

pga_aggregate_limit                            0                              FALSE
pga_aggregate_target                           10485760                       FALSE

50行が選択されました。

/proc/sys/vm/max_map_count

65530

+++ v$pgastat +++

NAME                                                                  VALUE UNIT             CON_ID
---------------------------------------------------------------- ---------- ------------ ----------
aggregate PGA target parameter                                           10 MB                    0
aggregate PGA auto target                                                 4 MB                    0
global memory bound                                                       2 MB                    0

・・・中略・・・

結果は以下のグラフと表にまとめたとおり。
_pga_max_size=4TB-1、pga_aggregate_target=4TB-1の時のglobal memory bound (v$pgastat) = _smm_max_size が最大となり、約839GBとなることがわかりました。
パラメータ上は839GB程度まで増加しますが、ほんとうにPGAがそんなサイズまで利用可能なのでしょうか？....（怪しいです。答え、知ってるんですけどねw。。

ということで、

次回は実際に、そんなに使えんのかよ！　という実験をしてみたいと思います :)

つづく。

投稿日時 2018年3月12日 (月) 10時58分チューニング, FAQ, SQL, Oracle Database 11g, Oracle Database 11g Release 2, Oracle Database 12c release 1, パフォーマンス, Oracle Database 12c Release 2 | 固定リンク | 0 | コメント (0) | トラックバック (0)

2018年3月 8日 (木)

Temp落ち #7 - 自動PGA管理で到達可能な最大サイズ de Temp落ちの確認 12.2.0.1版

Previously on Mac De Oracle

自動PGA管理で利用可能なSQL Work Areaサイズはいくつなのか？の確認でした。
これまで同様、隠しパラメータ等の変更をしないデフォルトの設定では最大1GBまで到達することを確認しました。
また、手動PGA管理で利用可能な最大サイズより小さいことも再確認しました。

今日は自動PGA管理下ではオンメモリーで処理可能なサイズは1GBまでなのか、それを超えた場合はもれなく　"Temp落ち" なのか確認することにします。

確認用データおよび方法は前々回のエントリーを参照ください。

自動PGA管理でGlobal Memory Bound = 1GB（自動PGA管理での最大 Sort作業領域サイズ）

メモリーソートで1GBぐらいまで利用していることが確認できます。（ソートされるデータ量は1GB以下程度に制限しています。）

ORCL@SCOTT> @auto_sortwk1gb_optimal

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
workarea_size_policy                 string      AUTO

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
pga_aggregate_target                 big integer 4398046511103

NAME                                                                  VALUE UNIT             CON_ID
---------------------------------------------------------------- ---------- ------------ ----------
global memory bound                                              1073741824 bytes                 0

  1  SELECT
  2      /*+
  3          MONITOR
  4      */
  5      *
  6  FROM
  7      m1
  8  WHERE
  9      id <= 'C045000'
 10  ORDER BY
 11      id
 12*     ,rev#
old   1: select dbms_sqltune.report_sql_monitor(sql_id=>'&1', type=>'text') from dual
new   1: select dbms_sqltune.report_sql_monitor(sql_id=>'', type=>'text') from dual

DBMS_SQLTUNE.REPORT_SQL_MONITOR(SQL_ID=>'',TYPE=>'TEXT')
------------------------------------------------------------------------------------------
SQL Monitoring Report

・・・中略・・・

Global Stats
===========================================================================
| Elapsed |   Cpu   |    IO    |  Other   | Fetch | Buffer | Read | Read  |
| Time(s) | Time(s) | Waits(s) | Waits(s) | Calls |  Gets  | Reqs | Bytes |
===========================================================================
|    4.78 |    3.85 |     0.34 |     0.59 | 30001 |   334K | 2633 |   3GB |
===========================================================================

SQL Plan Monitoring Details (Plan Hash Value=3534657201)
==================================================================================================================================================
| Id |      Operation       | Name |  Rows   | Cost  |   Time    | Start  | Execs |   Rows   | Read | Read  |  Mem  | Activity | Activity Detail |
|    |                      |      | (Estim) |       | Active(s) | Active |       | (Actual) | Reqs | Bytes | (Max) |   (%)    |   (# samples)   |
==================================================================================================================================================
|  0 | SELECT STATEMENT     |      |         |       |        10 |     +2 |     1 |     450K |      |       |     . |    33.33 | Cpu (2)         |
|  1 |   SORT ORDER BY      |      |    456K |  302K |        11 |     +1 |     1 |     450K |      |       |   1GB |    33.33 | Cpu (2)         |
|  2 |    TABLE ACCESS FULL | M1   |    456K | 90827 |         3 |     +2 |     1 |     450K | 2633 |   3GB |     . |    33.33 | Cpu (2)         |
==================================================================================================================================================

Temp落ちする程度のデータ量でソートさせた場合も、PGAの作業領域は最大1GBまで利用されていたことが確認できます。

ORCL@SCOTT> @auto_sortwk1gb_mpass    

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
workarea_size_policy                 string      AUTO

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
pga_aggregate_target                 big integer 4398046511103

NAME                                                                  VALUE UNIT             CON_ID
---------------------------------------------------------------- ---------- ------------ ----------
global memory bound                                              1073741824 bytes                 0

  1  SELECT
  2      /*+
  3          MONITOR
  4      */
  5      *
  6  FROM
  7      m1
  8  WHERE
  9      id <= 'C050000'
 10  ORDER BY
 11      id
 12*     ,rev#
old   1: select dbms_sqltune.report_sql_monitor(sql_id=>'&1', type=>'text') from dual
new   1: select dbms_sqltune.report_sql_monitor(sql_id=>'', type=>'text') from dual

DBMS_SQLTUNE.REPORT_SQL_MONITOR(SQL_ID=>'',TYPE=>'TEXT')
------------------------------------------------------------------------------------------
SQL Monitoring Report

・・・中略・・・

Global Stats
===========================================================================================
| Elapsed |   Cpu   |    IO    |  Other   | Fetch | Buffer | Read | Read  | Write | Write |
| Time(s) | Time(s) | Waits(s) | Waits(s) | Calls |  Gets  | Reqs | Bytes | Reqs  | Bytes |
===========================================================================================
|      16 |    6.91 |     7.91 |     0.71 | 33335 |   334K | 7996 |   4GB |  4431 |   1GB |
===========================================================================================

SQL Plan Monitoring Details (Plan Hash Value=3534657201)
=====================================================================================================================================================================================
| Id |      Operation       | Name |  Rows   | Cost  |   Time    | Start  | Execs |   Rows   | Read | Read  | Write | Write |  Mem  | Temp  | Activity |      Activity Detail       |
|    |                      |      | (Estim) |       | Active(s) | Active |       | (Actual) | Reqs | Bytes | Reqs  | Bytes | (Max) | (Max) |   (%)    |        (# samples)         |
=====================================================================================================================================================================================
|  0 | SELECT STATEMENT     |      |         |       |        22 |     +2 |     1 |     500K |      |       |       |       |     . |     . |     6.25 | Cpu (1)                    |
|  1 |   SORT ORDER BY      |      |    507K |  326K |        22 |     +2 |     1 |     500K | 5363 |   1GB |  4431 |   1GB |   1GB |   1GB |    68.75 | Cpu (4)                    |
|    |                      |      |         |       |           |        |       |          |      |       |       |       |       |       |          | direct path read temp (1)  |
|    |                      |      |         |       |           |        |       |          |      |       |       |       |       |       |          | direct path write temp (6) |
|  2 |    TABLE ACCESS FULL | M1   |    507K | 90828 |        13 |     +1 |     1 |     500K | 2633 |   3GB |       |       |     . |     . |    25.00 | Cpu (3)                    |
|    |                      |      |         |       |           |        |       |          |      |       |       |       |       |       |          | direct path read (1)       |
=====================================================================================================================================================================================

自動PGA管理でGlobal Memory Bound = 1GB（自動PGA管理での最大 Hash作業領域サイズ）

Hash Joinの場合も、自動PGA管理の最大サイズ程度まで利用されていることが確認できます。（Temp落ちしない程度のデータ量にしています。）

ORCL@SCOTT> @auto_hashwk1gb_optimal

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
workarea_size_policy                 string      AUTO

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
pga_aggregate_target                 big integer 4398046511103

NAME                                                                  VALUE UNIT             CON_ID
---------------------------------------------------------------- ---------- ------------ ----------
global memory bound                                              1073741824 bytes                 0

  1  SELECT
  2      /*+
  3          MONITOR
  4          LEADING(m1 m2)
  5          USE_HASH(m2)
  6      */
  7      *
  8  FROM
  9      m1
 10      INNER JOIN m2
 11      ON
 12          m1.id = m2.id
 13          AND m1.rev# = m2.rev#
 14  WHERE
 15*     m1.id <= 'C042000'
old   1: select dbms_sqltune.report_sql_monitor(sql_id=>'&1', type=>'text') from dual
new   1: select dbms_sqltune.report_sql_monitor(sql_id=>'', type=>'text') from dual

DBMS_SQLTUNE.REPORT_SQL_MONITOR(SQL_ID=>'',TYPE=>'TEXT')
------------------------------------------------------------------------------------------
SQL Monitoring Report

・・・中略・・・

Global Stats
===========================================================================
| Elapsed |   Cpu   |    IO    |  Other   | Fetch | Buffer | Read | Read  |
| Time(s) | Time(s) | Waits(s) | Waits(s) | Calls |  Gets  | Reqs | Bytes |
===========================================================================
|    7.29 |    5.05 |     0.68 |     1.55 | 28001 |   695K | 5251 |   5GB |
===========================================================================

SQL Plan Monitoring Details (Plan Hash Value=1822065247)
==================================================================================================================================================
| Id |      Operation       | Name |  Rows   | Cost  |   Time    | Start  | Execs |   Rows   | Read | Read  |  Mem  | Activity | Activity Detail |
|    |                      |      | (Estim) |       | Active(s) | Active |       | (Actual) | Reqs | Bytes | (Max) |   (%)    |   (# samples)   |
==================================================================================================================================================
|  0 | SELECT STATEMENT     |      |         |       |        14 |     +2 |     1 |     420K |      |       |     . |    22.22 | Cpu (2)         |
|  1 |   HASH JOIN          |      |    423K |  268K |        15 |     +1 |     1 |     420K |      |       |   1GB |    22.22 | Cpu (2)         |
|  2 |    TABLE ACCESS FULL | M1   |    432K | 90827 |         2 |     +2 |     1 |     420K | 2633 |   3GB |     . |    11.11 | Cpu (1)         |
|  3 |    TABLE ACCESS FULL | M2   |    423K | 90580 |        13 |     +3 |     1 |     420K | 2618 |   3GB |     . |    44.44 | Cpu (4)         |
==================================================================================================================================================

Hash Joinの場合もSort時と同じように、一時表領域も利用が必要となるデータ量になると、一旦、自動PGA管理の最大サイズ程度まで利用したうえでTemp落ちしていることが確認できます。

ORCL@SCOTT> @auto_hashwk1gb_mpass

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
workarea_size_policy                 string      AUTO

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
pga_aggregate_target                 big integer 4398046511103

NAME                                                                  VALUE UNIT             CON_ID
---------------------------------------------------------------- ---------- ------------ ----------
global memory bound                                              1073741824 bytes                 0

  1  SELECT
  2      /*+
  3          MONITOR
  4          LEADING(m1 m2)
  5          USE_HASH(m2)
  6      */
  7      *
  8  FROM
  9      m1
 10      INNER JOIN m2
 11      ON
 12          m1.id = m2.id
 13          AND m1.rev# = m2.rev#
 14  WHERE
 15*     m1.id <= 'C055000'
old   1: select dbms_sqltune.report_sql_monitor(sql_id=>'&1', type=>>'text') from dual
new   1: select dbms_sqltune.report_sql_monitor(sql_id=>'', type=>'text') from dual

DBMS_SQLTUNE.REPORT_SQL_MONITOR(SQL_ID=>'',TYPE=>'TEXT')
------------------------------------------------------------------------------------------
SQL Monitoring Report

・・・中略・・・

Global Stats
============================================================================================
| Elapsed |   Cpu   |    IO    |  Other   | Fetch | Buffer | Read  | Read  | Write | Write |
| Time(s) | Time(s) | Waits(s) | Waits(s) | Calls |  Gets  | Reqs  | Bytes | Reqs  | Bytes |
============================================================================================
|      24 |    7.18 |       15 |     1.99 | 36668 |   687K | 10829 |   6GB |  5578 |   1GB |
============================================================================================

SQL Plan Monitoring Details (Plan Hash Value=1822065247)
======================================================================================================================================================================================
| Id |      Operation       | Name |  Rows   | Cost  |   Time    | Start  | Execs |   Rows   | Read | Read  | Write | Write |  Mem  | Temp  | Activity |       Activity Detail       |
|    |                      |      | (Estim) |       | Active(s) | Active |       | (Actual) | Reqs | Bytes | Reqs  | Bytes | (Max) | (Max) |   (%)    |         (# samples)         |
======================================================================================================================================================================================
|  0 | SELECT STATEMENT     |      |         |       |        33 |     +2 |     1 |     550K |      |       |       |       |     . |     . |    14.29 | Cpu (4)                     |
|  1 |   HASH JOIN          |      |    551K |  293K |        33 |     +2 |     1 |     550K | 5578 |   1GB |  5578 |   1GB |   1GB |   1GB |    67.86 | Cpu (8)                     |
|    |                      |      |         |       |           |        |       |          |      |       |       |       |       |       |          | direct path read temp (1)   |
|    |                      |      |         |       |           |        |       |          |      |       |       |       |       |       |          | direct path write temp (10) |
|  2 |    TABLE ACCESS FULL | M1   |    551K | 90828 |        16 |     +1 |     1 |     550K | 2633 |   3GB |       |       |     . |     . |     7.14 | Cpu (1)                     |
|    |                      |      |         |       |           |        |       |          |      |       |       |       |       |       |          | direct path read (1)        |
|  3 |    TABLE ACCESS FULL | M2   |    557K | 90580 |        16 |    +16 |     1 |     550K | 2618 |   3GB |       |       |     . |     . |    10.71 | Cpu (3)                     |
======================================================================================================================================================================================

PGAの最大サイズは異なりますが、自動PGA管理、手動PGA管理いずれでの場合でも制限値を超えた場合は、もれなく　"Temp落ち" するということはご理解いただけたのではないかと思います。

では、次回は恒例？w の隠しパラメータと戯れた場合、自動PGA管理下ではどこまで増加させることができるのか？。。。。確認してみたいと思います。

投稿日時 2018年3月 8日 (木) 22時08分チューニング, FAQ, SQL, Oracle Database 11g, Oracle Database 11g Release 2, Oracle Database 12c release 1, パフォーマンス, Oracle Database 12c Release 2 | 固定リンク | 0 | コメント (0) | トラックバック (0)

2018年3月 7日 (水)

Temp落ち #6 - pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? 12.2.0.1版

Previously on Mac De Oracle
pga_aggregate_target scope=memory or bothでそれまでとはことなる動きとエラーは発生するところの話でした。

きょうは、自動PGA管理下ではどうなるか確認しておきます。
以前、簡単に確認した範囲結果から、これまでの仕様と大きな違いはないとみています。（変わっていないと思っていたのでブログでも書いていなかったのですが、"Temp落ち"ネタの準備運動も兼ね現状を確認しながら進めてみたいと思います）

まず環境情報から、
確認に利用するインスタンスのPGA以外のパラメータは以下の通りです。
（隠しパラメータは必要がある場合には適宜変更します。また、いくつかのパラメータは確認の都合上物理メモリーサイズ以上に設定することがあります。それらの変更が必要な場合には事前に解説する予定です。）

OS等の情報は以前のエントリーを参照のこと。

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
sga_max_size                         big integer 12G
sga_min_size                         big integer 0
sga_target                           big integer 12G

今回の主役である自動PGA管理のパラメータの初期設定は以下の通り（隠しパラメータを除く）
pga_aggregate_limit = 0 に設定し、pga_aggregate_targetの上限値制限を仕様上のサイズ4096GB - 1まで利用できるようにしておきます。（以前と同様の手順で確認するために、pga_aggregate_limitによる制限を無効化しています。なお、pga_aggregate_limitを0以外に設定して行う場合には、pga_aggregate_targetを4TB - 1まで設定することを考慮すると、pga_aggregate_limitは、8TB以上に設定する必要があります。）

orcl12c@SYS> show parameter pga_aggregate

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
pga_aggregate_limit                  big integer 0
pga_aggregate_target                 big integer 10M

上記設定からスタートして、pga_aggregate_targetを10MB/50MB/100MB/500MB/1GB/5GB/10GB/50GB/100GB/500GB/1T/4TB - 1と増加させながら、pgaサイズおよび、関連する隠しパラメータ(_pga_max_sizeや_smm_*など）がどのように変化するか、pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? Season2 #8の手順で確認します。

昔のように実行ログをペタペタ貼っていると長くなるので、確認結果を表とグラフにしました。
想定通り以前と変わっていませんでした:)

デフォルト設定のままであれば、pga_aggregate_targetを限界値まで大きく増やしたとしても、10GB以降、個々のソート操作やハッシュ結合操作で利用できるPGAのSQL work areaサイズはv$pgastatのglobal memory boundの示す通り、1GB（シリアル実行時）が最大であることが確認できます。　えーーー。手動PGA管理より最大サイズ小さいじゃんと、今更驚かないようにしましょうねw （以前からそうなのですからw）
つまり、自動PGA管理の場合、特定の隠しパラメータを変更しない限り、1GBを超えるソート処理はやハッシュ結合操作は全て、"Temp落ち" する宿命にあるわけです。12cR2であっても。
え"〜〜〜〜〜っ！　と一応、驚いておきましょうw。　メモリーを沢山積んでるマシンは最近多いわけですが、このあたりはなぜか変わってません。

ちなみに、v$pgastatの示すglobal memory boundは、どこから？　という確認がしたくて、　_smm_max_sizeの変化と比較しているグラグも作成しておきました。
_smm_max_sizeパラメータはpga_aggregate_targetのサイズ変化に伴い変化する隠しパラメータですが、このパラメータがglobal memory boundの元になっているのは確からしいですね。

最後のグラフは、pga_aggregate_targetの値とv$pgastatのglobal memory boundの変化をまとめたグラフです。
global memory boundで示されるPGAのSQL Work Areaサイズの最大サイズには上限があることがわかります：）

次回は、自動PGA管理では、1GBを超えるソートやハッシュ結合はもれなく"Temp落ち"するのか確認してみることにします。

参考：このエントリーで利用したスクリプト
（今後の確認も兼ねてw このエントリーでネタにしている以外で関連しそうなパラメータも取得して変化を確認できるようにしてあります。）

orcl12c@SYS> !cat show_param.sql
set linesize 200
col ksppinm for a46
col ksppstvl for a30
col ksppstdf for a30
select
   a.ksppinm
  ,b.ksppstvl
  ,b.ksppstdf
from
  x$ksppi a join x$ksppcv b
  on a.indx = b.indx
where
  a.ksppinm in (
	'pga_aggregate_target'
	,'pga_aggregate_limit'
	,'_use_realfree_heap'
	,'_realfree_heap_pagesize'
  )
or a.ksppinm like '%\_smm%' escape '\'
or a.ksppinm like '%\_pga%' escape '\'
order by
  a.ksppinm
/

!echo /proc/sys/vm/max_map_count
!more /proc/sys/vm/max_map_count

orcl12c@SYS> !cat show_pgstat.sql
select
  name
 ,case
    when unit='bytes' then
      value/1024/1024
    else value
  end "VALUE"
 ,case
    when unit='bytes' then
      'MB'
    else unit
  end "UNIT"
 ,con_id
from
  v$pgastat
where
  name in (
    'aggregate PGA target parameter'
    ,'aggregate PGA auto target'
    ,'global memory bound'
    ,'total PGA used for auto workareas'
    ,'maximum PGA used for auto workareas'
    ,'total PGA used for manual workareas'
    ,'maximum PGA used for manual workareas'
  )  
;

orcl12c@SYS> !cat auto_workarea.sql
conn sys/oracle@orcl12c as sysdba
alter system set pga_aggregate_target=&1 scope=spfile
.
r
shutdown immediate
startup

prompt +++ initial parameters +++
@show_param

prompt +++ v$pgastat +++
@show_pgstatå

orcl12c@SYS> !cat doTest_auto_workarea.sql
prompt << 10m >>
@auto_workarea 10m

prompt << 50m >>
@auto_workarea 50m

prompt << 100m >>
@auto_workarea 100m

prompt << 500m >>
@auto_workarea 500m

prompt << 1g >>
@auto_workarea 1g

prompt << 5g >>
@auto_workarea 5g

prompt << 10g >>
@auto_workarea 10g

prompt << 50g >>
@auto_workarea 50g

prompt << 100g >>
@auto_workarea 100g

prompt << 500g >>
@auto_workarea 500g

prompt << 1t >>
@auto_workarea 1t

prompt << 4t - 1 >>
@auto_workarea 4398046511103

実行例

orcl12c@SYS> @doTest_auto_workarea.sql
<< 10m >>
Connected.
  1* alter system set pga_aggregate_target=&1 scope=spfile
old   1: alter system set pga_aggregate_target=&1 scope=spfile
new   1: alter system set pga_aggregate_target=10m scope=spfile

System altered.

Database closed.
Database dismounted.
ORACLE instance shut down.
ORACLE instance started.

Total System Global Area 1.2885E+10 bytes
Fixed Size                  8807168 bytes
Variable Size            1375735040 bytes
Database Buffers         5033164800 bytes
Redo Buffers               24743936 bytes
In-Memory Area           6442450944 bytes
Database mounted.
Database opened.
+++ initial parameters +++

KSPPINM                                        KSPPSTVL                       KSPPSTDF
---------------------------------------------- ------------------------------ ------------------------------
__pga_aggregate_target                         33554432                       FALSE

・・・略・・・

pga_aggregate_limit                            0                              FALSE
pga_aggregate_target                           10485760                       FALSE

50 rows selected.

/proc/sys/vm/max_map_count

65530

+++ v$pgastat +++

NAME                                                                  VALUE UNIT             CON_ID
---------------------------------------------------------------- ---------- ------------ ----------
aggregate PGA target parameter                                           10 MB                    0
aggregate PGA auto target                                                 4 MB                    0
global memory bound                                                       2 MB                    0
total PGA used for auto workareas                                .106445313 MB                    0
maximum PGA used for auto workareas                              .106445313 MB                    0
total PGA used for manual workareas                                       0 MB                    0
maximum PGA used for manual workareas                                     0 MB                    0

7 rows selected.

・・・略・・・

投稿日時 2018年3月 7日 (水) 16時17分チューニング, FAQ, SQL, Oracle Database 11g, Oracle Database 11g Release 2, Oracle Database 12c release 1, パフォーマンス, Oracle Database 12c Release 2 | 固定リンク | 0 | コメント (0) | トラックバック (0)

2018年2月22日 (木)

Temp落ち #4 - 手動PGA管理で作業領域として指定可能な最大サイズ de Temp落ちの確認

Previously on Mac De Oracle
手動PGA管理で作業領域として指定可能な最大サイズは、2GB - 1までということの確認でした。
本当に、その程度のサイズまでPGAの作業領域が利用されるのでしょうか？。　念のために確認しておきましょう。 実は、それより少ないサイズで頭打ちなんてことは、ないかな〜　と　わざとらしく言ってみたりして（意味深w

その前に、指定した作業領域を使い切れるぐらい（つまり、Temp落ちさせられる程度）のデータ量の表を準備しておきます。
今回は、Nested Loop Join（NLJ)やソート回避などのための索引は作成しません。Temp落ちのネタなので。

M1とM2の2表を作成し、それぞれ、2.5GB程度のセグメントサイズにしておきます。 なお、以下の無名PL/SQLブロックでは、FORALLを利用して1000行単位でバルク処理しています。配列を利用するのでメモリー使用量にはそれなりに配慮が必要ですが。:)
単純なぐるぐる系INSERTにしてしまうとデータ量が多い場合、性能的に辛くなってしまうので、ここ重要！

ORCL@SCOTT> l
  1  CREATE TABLE m1
  2  (
  3  	id CHAR(7) NOT NULL
  4  	,rev# NUMBER NOT NULL
  5  	,value NUMBER NOT NULL
  6  	,description VARCHAR2(4000)
  7  	,additional_info CHAR(200)
  8* ) NOLOGGING
ORCL@SCOTT> /

Table created.

ORCL@SCOTT> l
  1  DECLARE
  2      TYPE IDS_t IS TABLE OF m1.id%TYPE INDEX BY PLS_INTEGER;
  3      TYPE REV#S_t IS TABLE OF m1.rev#%TYPE INDEX BY PLS_INTEGER;
  4      TYPE VALS_t IS TABLE OF m1.value%TYPE INDEX BY PLS_INTEGER;
  5      IDs IDS_t;
  6      REV#s REV#S_t;
  7      VALs VALS_t;
  8      k PLS_INTEGER := 1;
  9  BEGIN
 10      FOR i IN 1..100000 LOOP
 11          FOR j IN 1..10 LOOP
 12              IDs(k) := 'C' || TO_CHAR(i, 'FM000000');
 13              REV#s(k) := j;
 14              VALs(k) := i + j;
 15              k := k + 1;
 16          END LOOP;
 17          IF MOD(i, 100) = 0 THEN
 18              FORALL l in 1..1000 EXECUTE IMMEDIATE
 19                  'INSERT /*+ APPEND_VALUE NO_GATHER_OPTIMIZER_STATISTICS */ INTO m1 '
 20                   || 'VALUES(:1, :2, :3,  LPAD(''X'',2000, ''X''), LPAD(''9'',200,''9''))'
 21                   USING IDs(l), REV#s(l), VALs(l);
 22              COMMIT;
 23              k := 1;
 24          END IF;
 25      END LOOP;
 26* END;
ORCL@SCOTT> /

PL/SQL procedure successfully completed.

Elapsed: 00:01:22.45
ORCL@SCOTT> select count(1) from m1;

  COUNT(1)
----------
   1000000

ORCL@SCOTT> select segment_name,sum(bytes)/1024/1024/1024 "GB" from user_segments where segment_name='M1' group by segment_name;

SEGMENT_NAME                           GB
------------------------------ ----------
M1                                 2.5625

ORCL@SCOTT> l
  1  CREATE TABLE m2
  2  (
  3  	id CHAR(7) NOT NULL
  4  	,rev# NUMBER NOT NULL
  5  	,value NUMBER NOT NULL
  6  	,description VARCHAR2(4000)
  7* ) NOLOGGING
ORCL@SCOTT> /

Table created.

ORCL@SCOTT> l
  1  INSERT /*+ APPEND NO_GATHER_OPTIMIZER_STATISTICS */ INTO m2
  2* SELECT id,rev#,value,description FROM m1
ORCL@SCOTT> /

1000000 rows created.

Elapsed: 00:00:40.22
ORCL@SCOTT> commit;

Commit complete.

ORCL@SCOTT> exec dbms_stats.gather_table_stats(ownname=>'SCOTT',tabname=>'M1',no_invalidate=>false,method_opt=>'FOR ALL COLUMNS SIZE SKEWONLY');

PL/SQL procedure successfully completed.

ORCL@SCOTT> exec dbms_stats.gather_table_stats(ownname=>'SCOTT',tabname=>'M2',no_invalidate=>false,method_opt=>'FOR ALL COLUMNS SIZE SKEWONLY');

PL/SQL procedure successfully completed.

これで、準備完了。
ちなみに、NO_GATHER_OPTIMIZER_STATISTICSヒントを利用していますが、データ登録後に、ヒストグラムも含めて取得したかったため、バルクロード時のオンラインオプティマイザ統計収集を行わないようにするためのヒントです。
データ登録後オプティマイザ統計を取得するため、データ登録時のオンラインオプティマイザ統計のオーバーヘッドは無駄となるためです。利用できるなら利用したほうがよいとは思いますが、制限もあるのでご一読を（バルク・ロードのためのオンライン統計収集）

手動PGA管理で2GB - 1（手動PGA管理での最大 Sort作業領域サイズ）

メモリーソートで2GBぐらいまで利用していることが確認できます。（ソートされるデータ量が2GB以下程度に制限しています。）

ORCL@SCOTT> @manual_sortwk2gb_optimal    
  1* alter session set workarea_size_policy=manual

Session altered.

  1* alter session set sort_area_size = 2147483647

Session altered.

  1  SELECT
  2      /*+
  3          MONITOR
  4      */
  5      *
  6  FROM
  7      m1
  8  WHERE
  9      id <= 'C075000'
 10  ORDER BY
 11      id
 12*     ,rev#
old   1: select dbms_sqltune.report_sql_monitor(sql_id=>'&1', type=>'text') from dual
new   1: select dbms_sqltune.report_sql_monitor(sql_id=>'', type=>'text') from dual

DBMS_SQLTUNE.REPORT_SQL_MONITOR(SQL_ID=>'',TYPE=>'TEXT')
------------------------------------------------------------------------------------------
SQL Monitoring Report

・・・中略・・・

Global Stats
=================================================
| Elapsed |   Cpu   |  Other   | Fetch | Buffer |
| Time(s) | Time(s) | Waits(s) | Calls |  Gets  |
=================================================
|    5.42 |    4.13 |     1.29 | 50001 |   334K |
=================================================

SQL Plan Monitoring Details (Plan Hash Value=3534657201)
===================================================================================================================================
| Id |      Operation       | Name |  Rows   | Cost  |   Time    | Start  | Execs |   Rows   |  Mem  | Activity | Activity Detail |
|    |                      |      | (Estim) |       | Active(s) | Active |       | (Actual) | (Max) |   (%)    |   (# samples)   |
===================================================================================================================================
|  0 | SELECT STATEMENT     |      |         |       |        15 |     +2 |     1 |     750K |     . |    20.00 | Cpu (1)         |
|  1 |   SORT ORDER BY      |      |    752K |  439K |        16 |     +1 |     1 |     750K |   2GB |    60.00 | Cpu (3)         |
|  2 |    TABLE ACCESS FULL | M1   |    752K | 90828 |         3 |     +2 |     1 |     750K |     . |    20.00 | Cpu (1)         |
===================================================================================================================================

Temp落ちする程度のデータ量でソートさせた場合も、PGAの作業領域は一旦、2GBまで利用されていることが確認できます。

ORCL@SCOTT> @manual_sortwk2gb
  1* alter session set workarea_size_policy=manual

Session altered.

  1* alter session set sort_area_size = 2147483647

Session altered.

  1  SELECT
  2      /*+
  3          MONITOR
  4      */
  5      *
  6  FROM
  7      m1
  8  ORDER BY
  9      id
 10*     ,rev#
old   1: select dbms_sqltune.report_sql_monitor(sql_id=>'&1', type=>'text') from dual
new   1: select dbms_sqltune.report_sql_monitor(sql_id=>'', type=>'text') from dual

DBMS_SQLTUNE.REPORT_SQL_MONITOR(SQL_ID=>'',TYPE=>'TEXT')
-------------------------------------------------------------------------------------------
SQL Monitoring Report

・・・中略・・・

Global Stats
===========================================================================================
| Elapsed |   Cpu   |    IO    |  Other   | Fetch | Buffer | Read | Read  | Write | Write |
| Time(s) | Time(s) | Waits(s) | Waits(s) | Calls |  Gets  | Reqs | Bytes | Reqs  | Bytes |
===========================================================================================
|      46 |      11 |       15 |       20 | 66668 |   334K | 2148 |   2GB |  2146 |   2GB |
===========================================================================================

SQL Plan Monitoring Details (Plan Hash Value=3534657201)
=====================================================================================================================================================================================
| Id |      Operation       | Name |  Rows   | Cost  |   Time    | Start  | Execs |   Rows   | Read | Read  | Write | Write |  Mem  | Temp  | Activity |      Activity Detail       |
|    |                      |      | (Estim) |       | Active(s) | Active |       | (Actual) | Reqs | Bytes | Reqs  | Bytes | (Max) | (Max) |   (%)    |        (# samples)         |
=====================================================================================================================================================================================
|  0 | SELECT STATEMENT     |      |         |       |        60 |     +2 |     1 |       1M |      |       |       |       |     . |     . |     6.38 | Cpu (2)                    |
|    |                      |      |         |       |           |        |       |          |      |       |       |       |       |       |          | PGA memory operation (1)   |
|  1 |   SORT ORDER BY      |      |      1M |  553K |        61 |     +1 |     1 |       1M | 2148 |   2GB |  2146 |   2GB |   2GB |   2GB |    91.49 | Cpu (32)                   |
|    |                      |      |         |       |           |        |       |          |      |       |       |       |       |       |          | direct path read temp (10) |
|    |                      |      |         |       |           |        |       |          |      |       |       |       |       |       |          | direct path write temp (1) |
|  2 |    TABLE ACCESS FULL | M1   |      1M | 90822 |        27 |     +2 |     1 |       1M |      |       |       |       |     . |     . |     2.13 | Cpu (1)                    |
=====================================================================================================================================================================================

手動PGA管理で2GB - 1（手動PGA管理での最大 Hash作業領域サイズ） Hash Joinの場合も、手動PGA管理で設定可能な最大サイズ程度まで利用されていることが確認できます。（Temp落ちしない程度のデータ量にしています。）

ORCL@SCOTT> @manual_hashwk2gb_optimal
  1* alter session set workarea_size_policy = manual

Session altered.

  1* alter session set hash_area_size = 2147483647

Session altered.

  1  SELECT
  2      /*+
  3          MONITOR
  4          LEADING(m1 m2)
  5          USE_HASH(m2)
  6      */
  7      *
  8  FROM
  9      m1
 10      INNER JOIN m2
 11      ON
 12          m1.id = m2.id
 13          AND m1.rev# = m2.rev#
 14  WHERE
 15*     m1.id <= 'C075000'
old   1: select dbms_sqltune.report_sql_monitor(sql_id=>'&1', type=>'text') from dual
new   1: select dbms_sqltune.report_sql_monitor(sql_id=>'', type=>'text') from dual

DBMS_SQLTUNE.REPORT_SQL_MONITOR(SQL_ID=>'',TYPE=>'TEXT')
------------------------------------------------------------------------------------------
SQL Monitoring Report

・・・中略・・・

Global Stats
===========================================================================
| Elapsed |   Cpu   |    IO    |  Other   | Fetch | Buffer | Read | Read  |
| Time(s) | Time(s) | Waits(s) | Waits(s) | Calls |  Gets  | Reqs | Bytes |
===========================================================================
|    8.05 |    4.66 |     0.16 |     3.23 | 50001 |   717K | 2618 |   3GB |
===========================================================================

SQL Plan Monitoring Details (Plan Hash Value=1822065247)
==================================================================================================================================================
| Id |      Operation       | Name |  Rows   | Cost  |   Time    | Start  | Execs |   Rows   | Read | Read  |  Mem  | Activity | Activity Detail |
|    |                      |      | (Estim) |       | Active(s) | Active |       | (Actual) | Reqs | Bytes | (Max) |   (%)    |   (# samples)   |
==================================================================================================================================================
|  0 | SELECT STATEMENT     |      |         |       |        21 |     +2 |     1 |     750K |      |       |     . |    12.50 | Cpu (1)         |
|  1 |   HASH JOIN          |      |    752K |  181K |        22 |     +1 |     1 |     750K |      |       |   2GB |    25.00 | Cpu (2)         |
|  2 |    TABLE ACCESS FULL | M1   |    752K | 90828 |         2 |     +2 |     1 |     750K |      |       |     . |    25.00 | Cpu (2)         |
|  3 |    TABLE ACCESS FULL | M2   |    759K | 90581 |        20 |     +3 |     1 |     750K | 2618 |   3GB |     . |    37.50 | Cpu (3)         |
==================================================================================================================================================

Hash Joinの場合もSort時と同じように、一時表領域も利用させる程度のデータ量になると、一旦、手動PGA管理で設定可能な最大サイズ程度まで利用したうえでTemp落ちしていることが確認できます。

ORCL@SCOTT> @manual_hashwk2gb
  1* alter session set workarea_size_policy = manual

Session altered.

  1* alter session set hash_area_size = 2147483647

Session altered.

  1  SELECT
  2      /*+
  3          MONITOR
  4          LEADING(m1 m2)
  5          USE_HASH(m2)
  6      */
  7      *
  8  FROM
  9      m1
 10      INNER JOIN m2
 11      ON
 12          m1.id = m2.id
 13*         AND m1.rev# = m2.rev#
old   1: select dbms_sqltune.report_sql_monitor(sql_id=>'&1', type=>'text') from dual
new   1: select dbms_sqltune.report_sql_monitor(sql_id=>'', type=>'text') from dual

DBMS_SQLTUNE.REPORT_SQL_MONITOR(SQL_ID=>'',TYPE=>'TEXT')
------------------------------------------------------------------------------------------
SQL Monitoring Report

・・・中略・・・

Global Stats
===========================================================================================
| Elapsed |   Cpu   |    IO    |  Other   | Fetch | Buffer | Read | Read  | Write | Write |
| Time(s) | Time(s) | Waits(s) | Waits(s) | Calls |  Gets  | Reqs | Bytes | Reqs  | Bytes |
===========================================================================================
|      12 |    5.68 |     2.17 |     4.59 | 66668 |   706K | 3133 |   3GB |   515 | 511MB |
===========================================================================================

SQL Plan Monitoring Details (Plan Hash Value=1822065247)
=====================================================================================================================================================================================
| Id |      Operation       | Name |  Rows   | Cost  |   Time    | Start  | Execs |   Rows   | Read | Read  | Write | Write |  Mem  | Temp  | Activity |      Activity Detail       |
|    |                      |      | (Estim) |       | Active(s) | Active |       | (Actual) | Reqs | Bytes | Reqs  | Bytes | (Max) | (Max) |   (%)    |        (# samples)         |
=====================================================================================================================================================================================
|  0 | SELECT STATEMENT     |      |         |       |        30 |     +2 |     1 |       1M |      |       |       |       |     . |     . |    25.00 | Cpu (4)                    |
|  1 |   HASH JOIN          |      |      1M |  189K |        31 |     +1 |     1 |       1M |  515 | 511MB |   515 | 511MB |   2GB | 515MB |    43.75 | Cpu (5)                    |
|    |                      |      |         |       |           |        |       |          |      |       |       |       |       |       |          | direct path read temp (1)  |
|    |                      |      |         |       |           |        |       |          |      |       |       |       |       |       |          | direct path write temp (1) |
|  2 |    TABLE ACCESS FULL | M1   |      1M | 90822 |         6 |     +0 |     1 |       1M |      |       |       |       |     . |     . |    12.50 | Cpu (2)                    |
|  3 |    TABLE ACCESS FULL | M2   |      1M | 90574 |        24 |     +5 |     1 |       1M | 2618 |   3GB |       |       |     . |     . |    18.75 | Cpu (2)                    |
|    |                      |      |         |       |           |        |       |          |      |       |       |       |       |       |          | direct path read (1)       |
=====================================================================================================================================================================================

おまけ 1つのSQLの実行で利用されるPGAの作業領域は1つだけではないということも確認しておきましょうかね。（知ってる方はスルーしてよいですよ：）
以下の例では、MERGE JOINさせていますが、表M1と表M2それぞれのSort作業領域は、Merge Join終了時まで保持されることになるため、最大3GBのSort作業領域が利用されています。（SQLモニターの結果ではわかりにくいのですが。。。）
なお、手動PGA管理、自動PGA管理に関係なく、実行される操作により複数の作業領域が同時に確保されることがあります。
（ちなみに、自動PGA管理で利用されるPGA_AGGREGATE_LIMITがPGA_AGGREGATE_TARGETの2倍とされるのも、このような動きが考慮された結果だと知っていると、納得感はあるかもしれません。）

前回使った図で朱色で示したSQL Work Areaが複数ありますが、Hash/Sort/Bitmap系など複数のタイプおよび同一タイプの作業領域が同時に確保されることも意図した図になっているのは、これが理由なんです。

ORCL@SCOTT> @manual_sortwk2gb2_optimal
  1* alter session set workarea_size_policy = manual

Session altered.

  1* alter session set sort_area_size = 2147483647

Session altered.

  1  SELECT
  2      /*+
  3          MONITOR
  4          USE_MERGE(m1 m2)
  5      */
  6      *
  7  FROM
  8      m1
  9      INNER JOIN m2
 10      ON
 11          m1.id = m2.id
 12          AND m1.rev# = m2.rev#
 13  WHERE
 14*     m1.id <= 'C075000'
old   1: select dbms_sqltune.report_sql_monitor(sql_id=>'&1', type=>'text') from dual
new   1: select dbms_sqltune.report_sql_monitor(sql_id=>'', type=>'text') from dual

DBMS_SQLTUNE.REPORT_SQL_MONITOR(SQL_ID=>'',TYPE=>'TEXT')
-------------------------------------------------------------------------------------------
SQL Monitoring Report

・・・中略・・・

Global Stats
===========================================================================
| Elapsed |   Cpu   |    IO    |  Other   | Fetch | Buffer | Read | Read  |
| Time(s) | Time(s) | Waits(s) | Waits(s) | Calls |  Gets  | Reqs | Bytes |
===========================================================================
|      17 |      10 |     4.75 |     2.19 | 50001 |   667K | 5251 |   5GB |
===========================================================================

SQL Plan Monitoring Details (Plan Hash Value=1391069689)
========================================================================================================================================================
| Id |       Operation       | Name |  Rows   | Cost  |   Time    | Start  | Execs |   Rows   | Read | Read  |  Mem  | Activity |   Activity Detail    |
|    |                       |      | (Estim) |       | Active(s) | Active |       | (Actual) | Reqs | Bytes | (Max) |   (%)    |     (# samples)      |
========================================================================================================================================================
|  0 | SELECT STATEMENT      |      |         |       |        23 |    +10 |     1 |     750K |      |       |     . |    14.29 | Cpu (2)              |
|  1 |   MERGE JOIN          |      |    752K |  849K |        23 |    +10 |     1 |     750K |      |       |     . |          |                      |
|  2 |    SORT JOIN          |      |    752K |  439K |        32 |     +1 |     1 |     750K |      |       |   2GB |    21.43 | Cpu (3)              |
|  3 |     TABLE ACCESS FULL | M1   |    752K | 90828 |         8 |     +2 |     1 |     750K | 2633 |   3GB |     . |    35.71 | Cpu (3)              |
|    |                       |      |         |       |           |        |       |          |      |       |       |          | direct path read (2) |
|  4 |    SORT JOIN          |      |    759K |  410K |        23 |    +10 |  750K |     750K |      |       |   1GB |    14.29 | Cpu (2)              |
|  5 |     TABLE ACCESS FULL | M2   |    759K | 90581 |         5 |    +10 |     1 |     750K | 2618 |   3GB |     . |    14.29 | Cpu (2)              |
========================================================================================================================================================

SQLモニターの結果ではわかりにくいわけですが、v$sesstatをから眺めれば状況がよくわかります！
2つのソート作業領域が同時に確保されたことで、2GB + 1GB = 3GB程度のサイズにまで達していることが確認できます。

ORCL@SYSTEM> r
  1  select
  2  	vss.value/1024/1024/1024 "GB"
  3  	,vsn.name
  4  	,vss.sid
  5  from
  6  	v$sesstat vss
  7  	inner join v$statname vsn
  8  	on
  9  		vss.statistic# = vsn.statistic#
 10  		and vss.con_id = vsn.con_id
 11  		and vsn.name like '%pga%'
 12  where
 13  	sid IN (select sid from v$session where username='SCOTT')
 14  order by
 15* 	sid,name

        GB NAME                                                                    SID
---------- ---------------------------------------------------------------- ----------
3.04611414 session pga memory                                                      203
3.04611414 session pga memory max                                                  203

では、次回はやっとw、真打、自動PGA管理下での確認。（引っ張り過ぎかもしれないw）
つづく。

・Temp落ち #1 - "Temp落ち" って？
・Temp落ち #2 - PGA (Program Global Area)
・Temp落ち #3 - 手動PGA管理で作業領域として指定可能な最大サイズ

投稿日時 2018年2月22日 (木) 12時00分 PL/SQL, チューニング, FAQ, SQL, Oracle Database 11g, Oracle Database 11g Release 2, Oracle Database 12c release 1, パフォーマンス, Oracle Database 12c Release 2 | 固定リンク | 0 | コメント (0) | トラックバック (0)

2018年2月20日 (火)

Temp落ち #3 - 手動PGA管理で作業領域として指定可能な最大サイズ

自動PGA管理は12cでどうなんだっけ？という確認の前に、
いままで何度か質問されたことがあり、FAQだと思っているので

手動PGA管理で利用する以下パラメータの最大サイズはいくつ？　

HASH_AREA_SIZE
SORT_AREA_SIZE
BITMAP_MERGE_AREA_SIZE
CREATE_BITMAP_AREA_SIZE

ということを書いておきたいと思います。

これからしばらく続く　Temp落ち　ネタで利用する環境で固定部分は以下のとおり
（初期化パラメータ等は必要に応じて載せるつもりです。）

環境は以下のとおり。
host osとguest osのバージョンやメモリーサイズなど

discus:˜ oracle$ sw_vers
ProductName:	Mac OS X
ProductVersion:	10.13.3
BuildVersion:	17D47

discus:˜ oracle$ system_profiler SPHardwareDataType | grep -E 'Processor Name|Cores|Memory'
      Processor Name: 6-Core Intel Xeon
      Total Number of Cores: 12
      Memory: 32 GB

discus:˜ oracle$ VBoxManage -v
5.2.6r120293

discus:˜ oracle$ VBoxManage showvminfo e3d4f948-b2e6-4db3-a89d-df637d87a372 | grep -E 'Memory size|OS type|Number of CPUs'
Memory size:     23569MB
Number of CPUs:  12
OS type:                             Linux26_64


orcl12c@SYS> select * from v$version;

BANNER                                                                               CON_ID
-------------------------------------------------------------------------------- ----------
Oracle Database 12c Enterprise Edition Release 12.2.0.1.0 - 64bit Production              0
PL/SQL Release 12.2.0.1.0 - Production                                                    0
CORE    12.2.0.1.0	Production                                                            0
TNS for Linux: Version 12.2.0.1.0 - Production                                            0
NLSRTL Version 12.2.0.1.0 - Production                                                    0


orcl12c@SYS> show pdbs

    CON_ID CON_NAME                       OPEN MODE  RESTRICTED
---------- ------------------------------ ---------- ----------
         2 PDB$SEED                       READ ONLY  NO
         3 ORCL                           READ WRITE NO

さて、今日の本題

手動PGA管理で各SQL Work Area Sizeを決定する以下の初期化パラメータの最大サイズは？　いくつでしょう？　
すでにご存知のかたはスキップしていいですよ:)

マニュアルを読んでみるときづくのですが、手動PGA管理で各SQL Work Area Sizeを決定する4パラメータとも、「０以上、上限はOS依存」のような記述になっています。

そう、マニュアルを読んだだけではまったく参考にならないわけです。（え〜〜っ！）

そこで、みなさんサポートを頼るなり、ご自分でMOSを検索するなり、そこそこの苦労をして入手することになります。
私みたいな性格だと、どのマニュアルでもいいからまとめて載せてよーめんどくさいから。と、めんどくさい病の発作がでたりしますw

なので、環境があるのなら、you 試しちゃいなよー。が手っ取り早いかなーと（最終的にMOSとかサポートを頼るにしてもw）

上限はOS依存とだけしか記載されていませんが、私の観測範囲では、2GB - 1 が上限 となっています。
以下、Linux/Solaris/Windowsでの検証ログ。

Oracle® Databaseリファレンス　12cリリース2 (12.2) E72905-03より

HASH_AREA_SIZE
https://docs.oracle.com/cd/E82638_01/REFRN/HASH_AREA_SIZE.htm

SORT_AREA_SIZE
https://docs.oracle.com/cd/E82638_01/REFRN/SORT_AREA_SIZE.htm

BITMAP_MERGE_AREA_SIZE
https://docs.oracle.com/cd/E82638_01/REFRN/BITMAP_MERGE_AREA_SIZE.htm

CREATE_BITMAP_AREA_SIZE
https://docs.oracle.com/cd/E82638_01/REFRN/CREATE_BITMAP_AREA_SIZE.htm

Linux

orcl12c@SYS> !uname -r; cat /etc/redhat-release /etc/oracle-release
4.1.12-94.3.6.el7uek.x86_64
Red Hat Enterprise Linux Server release 7.3 (Maipo)
Oracle Linux Server release 7.3

orcl12c@SYS> create pfile from spfile;

File created.

orcl12c@SYS> --2GB  
orcl12c@SYS> select 2*1024*1024*1024 from dual;

2*1024*1024*1024
----------------
      2147483648

orcl12c@SYS> alter system set hash_area_size = 2147483648 scope=spfile;
alter system set hash_area_size = 2147483648 scope=spfile
                                  *
ERROR at line 1:
ORA-02017: integer value required

orcl12c@SYS> alter system set sort_area_size = 2147483648 scope=spfile;
alter system set sort_area_size = 2147483648 scope=spfile
                                  *
ERROR at line 1:
ORA-02017: integer value required

orcl12c@SYS> alter system set bitmap_merge_area_size = 2147483648 scope=spfile;
alter system set bitmap_merge_area_size = 2147483648 scope=spfile
                                          *
ERROR at line 1:
ORA-02017: integer value required

orcl12c@SYS> alter system set create_bitmap_area_size = 2147483648 scope=spfile;
alter system set create_bitmap_area_size = 2147483648 scope=spfile
                                           *
ERROR at line 1:
ORA-02017: integer value required

orcl12c@SYS> --2GB - 1
orcl12c@SYS> select 2*1024*1024*1024-1 from dual;

2*1024*1024*1024-1
------------------
        2147483647

orcl12c@SYS> alter system set hash_area_size = 2147483647 scope=spfile;

System altered.

orcl12c@SYS> alter system set sort_area_size = 2147483647 scope=spfile;

System altered.

orcl12c@SYS> alter system set bitmap_merge_area_size = 2147483647 scope=spfile;

System altered.

orcl12c@SYS> alter system set create_bitmap_area_size = 2147483647 scope=spfile;

System altered.

orcl12c@SYS> shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down.
orcl12c@SYS> create spfile from pfile;

File created.

orcl12c@SYS>

Solaris 11 (x86)

SQL> !uname -r; cat /etc/release
5.11
                             Oracle Solaris 11.3 X86
  Copyright (c) 1983, 2015, Oracle and/or its affiliates.  All rights reserved.
                            Assembled 06 October 2015

SQL> 
SQL> create pfile from spfile;

ファイルが作成されました。

SQL> --2GB
SQL> select 2*1024*1024*1024 from dual;

2*1024*1024*1024
----------------
      2147483648

SQL> alter system set hash_area_size = 2147483648 scope=spfile;
alter system set hash_area_size = 2147483648 scope=spfile
                                  *
行1でエラーが発生しました。:
ORA-02017: 整数値が必要です。


SQL> alter system set sort_area_size = 2147483648 scope=spfile;
alter system set sort_area_size = 2147483648 scope=spfile
                                  *
行1でエラーが発生しました。:
ORA-02017: 整数値が必要です。


SQL> alter system set bitmap_merge_area_size = 2147483648 scope=spfile;
alter system set bitmap_merge_area_size = 2147483648 scope=spfile
                                          *
行1でエラーが発生しました。:
ORA-02017: 整数値が必要です。


SQL> alter system set create_bitmap_area_size = 2147483648 scope=spfile;
alter system set create_bitmap_area_size = 2147483648 scope=spfile
                                           *
行1でエラーが発生しました。:
ORA-02017: 整数値が必要です。


SQL> --2GB - 1
SQL> select 2*1024*1024*1024-1 from dual;

2*1024*1024*1024-1
------------------
	2147483647

SQL> alter system set hash_area_size = 2147483647 scope=spfile;

システムが変更されました。

SQL> alter system set sort_area_size = 2147483647 scope=spfile;

システムが変更されました。

SQL> alter system set bitmap_merge_area_size = 2147483647 scope=spfile;

システムが変更されました。

SQL> alter system set create_bitmap_area_size = 2147483647 scope=spfile;

システムが変更されました。

SQL> shutdown immediate
データベースがクローズされました。
データベースがディスマウントされました。
ORACLEインスタンスがシャットダウンされました。
ERROR:
ORA-12514: TNS:
リスナーは接続記述子でリクエストされたサービスを現在認識していません


警告: Oracleにはもう接続されていません。
SQL> conn sys/oracle@orcl122 as sysdba
ERROR:
ORA-12514: TNS:
リスナーは接続記述子でリクエストされたサービスを現在認識していません


SQL> exit
bash-4.1$ export ORACLE_SID=orcl122
bash-4.1$ sqlplus / as sysdba

SQL*Plus: Release 12.2.0.1.0 Production on 月 2月 19 22:44:47 2018

Copyright (c) 1982, 2016, Oracle.  All rights reserved.

アイドル・インスタンスに接続しました。

SQL> startup
ORACLEインスタンスが起動しました。

Total System Global Area  838860800 bytes
Fixed Size		    8790120 bytes
Variable Size		  356519832 bytes
Database Buffers	  465567744 bytes
Redo Buffers		    7983104 bytes
データベースがマウントされました。
データベースがオープンされました。
SQL> show parameter _area_size

NAME				     TYPE	 VALUE
------------------------------------ ----------- ------------------------------
bitmap_merge_area_size               integer     2147483647
create_bitmap_area_size              integer     2147483647
hash_area_size                       integer     2147483647
sort_area_size                       integer     2147483647
workarea_size_policy                 string      AUTO
SQL> 
SQL> shutdown immediate
データベースがクローズされました。
データベースがディスマウントされました。
ORACLEインスタンスがシャットダウンされました。
SQL> 
SQL> create spfile from pfile;

File created.

Microsoft Windows

Oracle Database 12c Enterprise Edition Release 12.2.0.1.0 - 64bit Production
に接続されました。
SQL>
SQL> $ver

Microsoft Windows [Version 10.0.16299.125]

SQL> create pfile from spfile;

ファイルが作成されました。

SQL> --2GB
SQL> select 2*1024*1024*1024 from dual;

2*1024*1024*1024
----------------
      2147483648

SQL> alter system set hash_area_size = 2147483648 scope=spfile;
alter system set hash_area_size = 2147483648 scope=spfile
                                  *
行1でエラーが発生しました。:
ORA-02017: 整数値が必要です。

SQL> alter system set sort_area_size = 2147483648 scope=spfile;
alter system set sort_area_size = 2147483648 scope=spfile
                                  *
行1でエラーが発生しました。:
ORA-02017: 整数値が必要です。

SQL> alter system set bitmap_merge_area_size = 2147483648 scope=spfile;
alter system set bitmap_merge_area_size = 2147483648 scope=spfile
                                          *
行1でエラーが発生しました。:
ORA-02017: 整数値が必要です。

SQL> alter system set create_bitmap_area_size = 2147483648 scope=spfile;
alter system set create_bitmap_area_size = 2147483648 scope=spfile
                                           *
行1でエラーが発生しました。:
ORA-02017: 整数値が必要です。


SQL> --2GB - 1
SQL> select 2*1024*1024*1024-1 from dual;

2*1024*1024*1024-1
------------------
        2147483647

SQL> alter system set hash_area_size = 2147483647 scope=spfile;

システムが変更されました。

SQL> alter system set sort_area_size = 2147483647 scope=spfile;

システムが変更されました。

SQL> alter system set bitmap_merge_area_size = 2147483647 scope=spfile;

システムが変更されました。

SQL> alter system set create_bitmap_area_size = 2147483647 scope=spfile;

システムが変更されました。

SQL> shutdown immediate
データベースがクローズされました。
データベースがディスマウントされました。
ORACLEインスタンスがシャットダウンされました。
ERROR:ORA-12514: TNSリスナーは接続記述子でリクエストされたサービスを現在認識していません
SQL> 警告: Oracleにはもう接続されていません。
SQL> exit
Disconnected
C:\Users\discus>set ORACLE_SID=orcl122SQL> 
C:\Users\discus>sqlplus / as sysdba
SQL*Plus: Release 12.2.0.1.0 Production on 月 2月 19 22:28:45 2018
Copyright (c) 1982, 2016, Oracle.  All rights reserved.
SQL> 
アイドル・インスタンスに接続しました。
SQL> create spfile from pfile;
SQL> 
File created.
SQL> exit
Disconnected

C:\Users\discus>

ということで、

手動PGA管理でSQL Work Area Sizeを制御する初期化パラメータで指定可能な最大サイズは

2GB -1

ということになります。(HP-UXやAIXは未確認なので情報いただけたら、ここに追記しまーす。:)

次回へつづく。

・Temp落ち #1 - "Temp落ち" って？
・Temp落ち #2 - PGA (Program Global Area)

投稿日時 2018年2月20日 (火) 18時00分 Linux, チューニング, FAQ, SQL, Oracle Database 11g, Windows, Oracle Database 11g Release 2, Solaris, Oracle Database 12c release 1, パフォーマンス, Oracle Database 12c Release 2 | 固定リンク | 0 | コメント (0) | トラックバック (0)

2018年2月18日 (日)

Temp落ち #2 - PGA (Program Global Area)

Previously on Mac De Oracle
”Temp落ち”ってなに？　
という話と、それを確認できるツールをいくつか紹介したところまででした。

余談

このネタを書きながら、"Temp落ち"とは異なる理由で今回ネタにするメモリー領域の事を調べていた事を思い出しました。（懐かしい）

当時、自動PGA管理に関する情報があまりなく、新・ソートに関する検証　その１　ペンネーム　グリーンペペを隅から隅まで読み試していました：)。その何年か後に、グリーンペペさんが、だれなのかを知ることに。。業界狭いですw

むか〜し、Windows(32bit)環境のOracleで、」ORA-12518が頻発していたトラブルの原因は今回のネタで取り上げるメモリー領域だった！なんてこともあるので、構造等、知ってて損はないですよ:)

では、今回のお話。

"Hash JoinやSortなどの処理をできる限りメモリー上で行う"という、そのメモリー領域とは？？？
PGA (Program Global Area)と呼ばれるメモリー領域のSQL Work Areaに確保されます。
また、それらのサイズを制御する初期化パラメータがあります。（後述）
PGAは、おおよそ以下のような構造で、サーバープロセスやバックグランドプロセス毎に確保されます。”ここ大切"

参考)
PGAのメモリーサイズを制御するパラメータは、以下の通り（隠しパラメータもありますが、とりあえずデフォルト前提で：）

以下の4パラメータは、手動PGA管理で利用されるパラメータで、自動PGA管理が主流となった今ではあまり利用されることはありません。（たま〜〜に使いたくなるときはありますが、結局使わなかったり、それは別の機会にでも書くことにします）

HASH_AREA_SIZE
https://docs.oracle.com/cd/E82638_01/REFRN/HASH_AREA_SIZE.htm

SORT_AREA_SIZE
https://docs.oracle.com/cd/E82638_01/REFRN/SORT_AREA_SIZE.htm

BITMAP_MERGE_AREA_SIZE
https://docs.oracle.com/cd/E82638_01/REFRN/BITMAP_MERGE_AREA_SIZE.htm

CREATE_BITMAP_AREA_SIZE
https://docs.oracle.com/cd/E82638_01/REFRN/CREATE_BITMAP_AREA_SIZE.htm

Oracle database 9.2.0以降、自動PGA管理が登場し、上記4パラメータで個別にサイズを管理する必要がなくなりました。
PGA_AGGREGATE_TARGET/PGA_AGGREATE_LIMITの２つのパラメータで自動PGA管理で行う方法に慣れておいた方が良いと思います。

余談
ちなみに、10gR1〜11gR2までは、PGA_AGGREGATE_TARGETパラメータだけだったのですが、その頃、自動PGA管理で割り当てられるサイズを検証していたネタは以下:) pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? Season2 #8 https://discus-hamburg.cocolog-nifty.com/mac_de_oracle/2010/09/pga_aggregate-7.html
ところで、ひさびさに以下マニュアルを読んで見たのですが、何度見てもモヤモヤは消えない感じのままなのがつらいです。もう少しなんとかならんかなー。
と思わなくもないです...w 作業領域の割り当てルールを明記しないのは、何故なんだろうと、ズーーーーっと考えてる。書いてくれてれば楽なのにな〜と。

Oracle® Databaseパフォーマンス・チューニング・ガイド 12cリリース2 (12.2) E72901-03
16 プログラム・グローバル領域のチューニング
https://docs.oracle.com/cd/E82638_01/TGDBA/tuning-program-global-area.htm

Oracle® Databaseリファレンス 12cリリース2 (12.2) E72905-03
PGA_AGGREGATE_LIMIT
https://docs.oracle.com/cd/E82638_01/REFRN/PGA_AGGREGATE_LIMIT.htm

12.2からResource Managerを利用して特定のコンシューマ・グループ内の各セッションに割り当てられるようになったようで、 PGAメモリー使用量に絶対制限を設定し、超過した場合にはORA-10260エラーとさせることができるようになったようですね。（まだ試したことはないのですが）
16.3.2 リソース・マネージャを使用したプログラム・グローバル領域のサイズ設定
https://docs.oracle.com/cd/E82638_01/TGDBA/tuning-program-global-area.htm

PGA_AGGREGATE_TARGET
https://docs.oracle.com/cd/E82638_01/REFRN/PGA_AGGREGATE_TARGET.htm

12cの自動PGA管理について軽く確認した感触だと、12cR2でPDB毎の制御ができるようになった事以外、大きな変化ないんじゃないかと思っているのですが、そういえばちゃんと確認したことないな。。。
次回は、昔試した方法で、12cでもPGA割り当てルールに変化はないのか確認しておきますか。。。18cはどうなるんだろ:)

続く。

・Temp落ち #1 - "Temp落ち" って？

投稿日時 2018年2月18日 (日) 14時00分チューニング, FAQ, SQL, Oracle Database 11g, Oracle Database 11g Release 2, Oracle Database 12c release 1, Oracle Database 12c Release 2 | 固定リンク | 0 | コメント (0) | トラックバック (0)

2017年12月 4日 (月)

”utl_file I/O” - この症状はあれの可能性が高いですね。

JPOUG Advent Calendar 2017の4日目のエントリーです。

さて、最近あまりお目にかかってなかったUTL_FILEパッケージで表データをcsvに書きだすネタにしました。

先日、UTL_FILEパッケージを利用した処理が想定以上に遅いという相談をうけました。
AWRレポートをみると、上位の待機イベントは、”utl_file I/O"。

！！！！おーーーこれは、珍しいというか、久々にみた病気w

UTL_FILEパッケージを利用したI/Oをグルグルしているとか、でかいファイル読み書きしているかの、どちらかですよねw
ということで、この症状の治療法を考えてみます。

＜参考 - 環境＞

MacBook:˜ system_profiler SPHardwareDataType | grep -E 'Model|Processor|Cores|Memory'
      Model Name: MacBook
      Model Identifier: MacBook9,1
      Processor Name: Intel Core m5
      Processor Speed: 1.2 GHz
      Number of Processors: 1
      Total Number of Cores: 2
      Memory: 8 GB

ホストOS
MacBook:˜ discus$ sw_vers
ProductName:	Mac OS X
ProductVersion:	10.13.1
BuildVersion:	17B1003

MacBook:˜ discus$ VBoxManage -version
5.1.30r118389


ゲストOSとOracle Database
orcl@SYS> !uname -a
Linux localhost.localdomain 4.1.12-94.3.6.el7uek.x86_64 #2 SMP Tue May 30 19:25:15 PDT 2017 x86_64 x86_64 x86_64 GNU/Linux

orcl@SYS> !cat /etc/oracle-release
Oracle Linux Server release 7.3

orcl@SYS> 
orcl@SYS> select * from v$version;

BANNER                                                                               CON_ID
-------------------------------------------------------------------------------- ----------
Oracle Database 12c Enterprise Edition Release 12.2.0.1.0 - 64bit Production              0
PL/SQL Release 12.2.0.1.0 - Production                                                    0
CORE	12.2.0.1.0	Production                                                            0
TNS for Linux: Version 12.2.0.1.0 - Production                                            0
NLSRTL Version 12.2.0.1.0 - Production                                                    0

UTL_FILEでファイル出力する際、ちょっとした手順の漏れが性能差として現れてしまうことがあります。
表の行長は数百バイト程度ですが、行数は数千万〜数億行なんていう状況だと、性能差が顕著に現れてしまうので注意が必要です。

以下の表、セグメントサイズは1GB程度ですが、行数は1千万行以上あります。
この表データをUTL_FILEパッケージを利用してcsvに出力してみます。

ORCL@SCOTT> select segment_name,sum(bytes)/1024/1024/1024 "GB" from user_segments group by segment_name;

SEGMENT_NAME                           GB
------------------------------ ----------
ABOUT_100BYTES_ROWS              .9140625
PK_ABOUT_100BYTES_ROWS            .171875


ORCL@SCOTT> select count(1) from about_100bytes_rows;

  COUNT(1)
----------
  10737420

表の1行は100bytes(改行コード含）です。

ORCL@SCOTT%gt; r
  1  SELECT
  2  	LENGTH(
  3  		TO_CHAR(id,'FM000000000000000000000000000009')
  4  		||','||FOO
  5  	) row_length
  6  FROM
  7  	about_100bytes_rows
  8  WHERE
  9* 	rownum <= 1

ROW_LENGTH
----------
        99

次の2つのコードの赤太文字部分に着目してください。
その部分が異なるだけで処理時間に大きな差が出ます。

DECLARE
	cDIR_NAME CONSTANT VARCHAR2(30) := 'FILES_DIR';
	cFILE_NAME CONSTANT VARCHAR2(128) := 'no_writebuffering_'||TO_CHAR(systimestamp, 'rrmmddhh24miss.ff')||'.txt';
	cBufferSize CONSTANT BINARY_INTEGER := 32767;
	cOpenMode CONSTANT VARCHAR2(2) := 'w';
	fileHandle UTL_FILE.FILE_TYPE;
	
	cBulkReadLimit CONSTANT PLS_INTEGER := 324;
	TYPE tBulkReadArray IS TABLE OF VARCHAR2(8192) INDEX BY BINARY_INTEGER;
	bulkReadArray tBulkReadArray;
	CURSOR cur_about100bytesRow IS
		SELECT
			TO_CHAR(id,'FM000000000000000000000000000009')
			||','||FOO
			AS csvrow
		FROM
			about_100bytes_rows
		;
BEGIN
	OPEN cur_about100bytesRow;
	fileHandle := UTL_FILE.FOPEN(cDIR_NAME, cFILE_NAME, cOpenMode, cBufferSize);
	LOOP
		FETCH cur_about100bytesRow
			BULK COLLECT INTO bulkReadArray
			LIMIT cBulkReadLimit;
		
		EXIT WHEN bulkReadArray.COUNT = 0;
		
		FOR i IN bulkReadArray.FIRST..bulkReadArray.LAST LOOP
			UTL_FILE.PUT_LINE(
				file => fileHandle
				, buffer => bulkReadArray(i)
				, autoflush => true
			);
		END LOOP;
	END LOOP;
	UTL_FILE.FFLUSH(fileHandle);
	UTL_FILE.FCLOSE(fileHandle);
	CLOSE cur_about100bytesRow;
EXCEPTION
	WHEN OTHERS THEN
		IF UTL_FILE.IS_OPEN(fileHandle) THEN
			UTL_FILE.FCLOSE(fileHandle);
		END IF;
		
		IF cur_about100bytesRow%ISOPEN THEN
			CLOSE cur_about100bytesRow;
		END IF;
		RAISE;
END;
/


PL/SQLプロシージャが正常に完了しました。

経過: 00:02:27.05

DECLARE
	cDIR_NAME CONSTANT VARCHAR2(30) := 'FILES_DIR';
	cFILE_NAME CONSTANT VARCHAR2(128) := 'writebuffering_'||TO_CHAR(systimestamp, 'rrmmddhh24miss.ff')||'.txt';
	cBufferSize CONSTANT BINARY_INTEGER := 32767;
	cOpenMode CONSTANT VARCHAR2(2) := 'w';
	fileHandle UTL_FILE.FILE_TYPE;
	buffer VARCHAR2(32767);
	
	cBulkReadLimit CONSTANT PLS_INTEGER := 324;
	TYPE tBulkReadArray IS TABLE OF VARCHAR2(8192) INDEX BY BINARY_INTEGER;
	bulkReadArray tBulkReadArray;
	CURSOR cur_about100bytesRow IS
		SELECT
			TO_CHAR(id,'FM000000000000000000000000000009')
			||','||FOO
			AS csvrow
		FROM
			about_100bytes_rows
		;
BEGIN
	OPEN cur_about100bytesRow;
	fileHandle := UTL_FILE.FOPEN(cDIR_NAME, cFILE_NAME, cOpenMode, cBufferSize);
	LOOP
		FETCH cur_about100bytesRow
			BULK COLLECT INTO bulkReadArray
			LIMIT cBulkReadLimit;
		
		EXIT WHEN bulkReadArray.COUNT = 0;
	
		buffer := NULL;	
		FOR i IN bulkReadArray.FIRST..bulkReadArray.LAST LOOP
			buffer := buffer || bulkReadArray(i) || UTL_TCP.CRLF;   
 		END LOOP;
		UTL_FILE.PUT(fileHandle, buffer);
		UTL_FILE.FFLUSH(fileHandle);
	END LOOP;
	UTL_FILE.FFLUSH(fileHandle);
	UTL_FILE.FCLOSE(fileHandle);
	CLOSE cur_about100bytesRow;
EXCEPTION
	WHEN OTHERS THEN
		IF UTL_FILE.IS_OPEN(fileHandle) THEN
			UTL_FILE.FCLOSE(fileHandle);
		END IF;
		
		IF cur_about100bytesRow%ISOPEN THEN
			CLOSE cur_about100bytesRow;
		END IF;
		RAISE;
END;
/


PL/SQLプロシージャが正常に完了しました。

経過: 00:00:43.96

何が違うかお分ですよね！
UTL_FILE.PUT_LINE/UTL_FILE.PUTが違う！！w
その部分は重要ではなく、100Bytes単位に書き込んでいるか、約32KB単位で書き込んでいるかが重要なんです。

UTL_FILEは最大32767バイトのバッファを利用できますが、前者はバッファを有効利用せず、100Bytes毎に書き出しています。後者は約32KB単位で書き出しています。

その差はAWRレポートからも見えてきます。

AWRレポート（一部抜粋）
UTL_FILEパッケージによるI/Oの待機は、”utl_file I/O”という待機イベントで現れます。

Avg Waitは短いですが、理由は100バイト単位の小さいなサイズの書き込みを繰り返しているわけなので、そんなとこでしょう。

Top 10 Foreground Events by Total Wait Time

                                           Total Wait       Avg   % DB Wait
Event                                Waits Time (sec)      Wait   time Class
------------------------------ ----------- ---------- --------- ------ --------
DB CPU                                          147.4             99.3
utl_file I/O                    32,212,266       49.5    1.54us   33.3 User I/O
direct path read                     1,881        1.2  620.61us     .8 User I/O
resmgr:cpu quantum                       1         .1   85.85ms     .1 Schedule
db file sequential read                 17          0     .98ms     .0 User I/O
PGA memory operation                    90          0   35.13us     .0 Other
latch: shared pool                       1          0    1.05ms     .0 Concurre
control file sequential read            80          0   12.83us     .0 System I
Disk file operations I/O                 6          0   73.67us     .0 User I/O
SQL*Net message to client                2          0    9.00us     .0 Network

一方、約32KB単位でバッファリングして書き出している場合、Waits回数が激減しています。
Avg Waitsは大きくなっていますが、書き出しサイズにほぼ比例しているので想定通りというところ。

Top 10 Foreground Events by Total Wait Time

                                           Total Wait       Avg   % DB Wait
Event                                Waits Time (sec)      Wait   time Class
------------------------------ ----------- ---------- --------- ------ --------
DB CPU                                             45             98.5
utl_file I/O                        66,288       27.4  413.54us   60.1 User I/O
direct path read                     1,881          1  550.71us    2.3 User I/O
db file sequential read                 88          0  443.38us     .1 User I/O
direct path write                        2          0    4.69ms     .0 User I/O
control file sequential read            80          0   33.25us     .0 System I
latch: shared pool                       1          0    2.38ms     .0 Concurre
Disk file operations I/O                 4          0  323.50us     .0 User I/O
PGA memory operation                    79          0   15.73us     .0 Other
SQL*Net message to client                4          0   20.25us     .0 Network

utl_file.put/put_lineでcsvを出力しているdeviceのiostat(util%)
まだまだ余裕があるのでI/Oで詰まっているのではなく、UTL_FILE.PUT/PUT_LINEの使い方の影響が大きいということですね。

最後に、
UTL_FILEパッケージの入出力時にはバッファの有効利用をお忘れなく。(つい忘れちゃうこともあるので、急いでるときとかw）
扱うデータが多い場合は得に。

そして、みなさま、
メリークリスマス（まだエントリーを書くかもしれませんがw）
#JPOUG

投稿日時 2017年12月 4日 (月) 00時10分 PL/SQL, チューニング, FAQ, Oracle Database 11g, Oracle Database 11g Release 2, JPOUG, Oracle Database 12c release 1, Advent Calendar, Oracle Database 12c Release 2 | 固定リンク | 0 | コメント (0) | トラックバック (0)

2017年11月 7日 (火)

DBMS_ADVISOR.CREATE_FILE()プロシージャは、Diagnostic/Tuning Pack不要らしいということの確認

Previously on Mac De Oracle

余談

DBMS_ADVISOR.CREATE_FILEとなっているがライセンス上、diagnostic/tuning packライセンスはなくてもアクセスしてできるように読み取れるのだけと、もしかすると、この影響で、DBMS_ADVISOR.CREATE_FILEの存在は知っていても使ってないのかあるのかな？？

以下のマニュアルを読む限り、Diagnostic/Tuning Packでは、DBMS_ADVISORパッケージ全体ではなく、Diagnostic/Tuning Packに関連するパラメータを与える必要のある機能についての制限であることしか記載されていない。
つまり、DBMS_ADVISOR.CREATE_FILE()に関して言えば、Diagnostic/Tuning Pack特有の機能ではないから利用可能なはず。　←間違ってたらツッコミ希望w

Oracle® Databaseライセンス情報 12cリリース1 (12.1) 2 オプションおよびパック
https://docs.oracle.com/cd/E49329_01/license.121/b71334/options.htm

なんてことを書いたところ、

control_management_pack_access=none

でも使えるとなら間違いなくないんじゃないの？
というコメントがあったので試してみました。　マニュアルの通りだと思われます。ということですね。FAQ!

orcl@SYS> show parameter control_management_pack_access

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
control_management_pack_access        string     NONE
orcl@SYS> 
orcl@SYS> l
1 DECLARE
2     reportClob CLOB := EMPTY_CLOB();
3 BEGIN
4     reportClob := 'test test test';
5     DBMS_ADVISOR.CREATE_FILE(
6     buffer => reportClob
7     ,location => 'REP_DIR'
8     ,filename => 'test.txt'
9 );
10* END;
orcl@SYS> /

PL/SQLプロシージャが正常に完了しました。

経過: 00:00:00.23
orcl@SYS> !ls report 
test.txt

orcl@SYS> !cat report/test.txt
test test test

・DBMS_SQLTUNE.PACK_STGTAB_SQLSETって、例外投げんのかよw
・SQL Tuning Setのキャプチャから退避までのスクリプト（やっつけ）
・SQL Tuning Set (STS)のフィルタリング
・DBMS_SQLTUNE.REPORT_ANALYSIS_TASK()ファンクションで生成されるCLOB型のレポートをファイルに保存する簡単な方法

投稿日時 2017年11月 7日 (火) 00時05分 PL/SQL, チューニング, FAQ, Oracle Database 11g, Oracle Database 11g Release 2, Oracle Database 12c release 1, Oracle Database 12c Release 2 | 固定リンク | 0 | コメント (0) | トラックバック (0)

2017年11月 3日 (金)

DBMS_SQLTUNE.REPORT_ANALYSIS_TASK()ファンクションで生成されるCLOB型のレポートをファイルに保存する簡単な方法

Previously on Mac De Oracle
STSとの格闘というかSPAとの格闘に疲れてきたところw ですが、
SQL Tuning Set (STS)のフィルタリング
などで、SQLSETを程よい大きさに分割するところまでたどり着きましたw

今回は、いくつかある細かい分析方法については、一旦、置いといて、
分析レポートを保存する簡単な方法についての備忘録

分析などにこの記事も参考になると思いますが、紹介している記事でも分析レポートをファイルに保存する方法はSQL*Plusのコマンドを駆使して行われています。
個人的には少々やぼったい方法かなと感じている方法なんですが、以前はこんなやりかたが多かったようにも思います。

var rep CLOB
...略...
EXEC :rep := DBMS_SQLSPA.REPORT_ANALYSIS_TASK('STSNAM','TEXT',...
spo hoge_report.txt
print :rep
spo off

SQL*PlusとPL/SQLが行ったり来たりするところや、ループ制御しにくいので、この方法は避けたい。。。。

かといって、DBMS_OUTPUT.PUT_LINEで行おうとするとset linesize等の制御が面倒くさいし
結局、SQL*Plusの機能にも依存してしまうので、いまひとつ。

PL/SQLだけで行う方法として、UTL_FILEパッケージを利用してファイル出力する方法もありますが、
UTL_FILEパッケージで提供されているAPIはlow levelなものばかりなので、急ぎの時にはめんどくさくて、やだw

もっと簡単なやつないの？？？？？

あります！w

DBMS_ADVISOR.CREATE_FILE(buffer, location, filename)

なぜ、UTL_FILEパッケージに入れてくれないんだw と思いたくなる方もいるかと思いますが、理由はよくわかりませんw
（UTL_FILEパッケージはlow levelなAPIだけだから入れたくないのかも、かも、かも。と思ってますが、DBMS_ADVISORパッケージに入れるとは。どういうつもりだ！w）

UTL_FILE.CREATE_FILE()ってあったほうが直感的に探しやすくないかw UTL_FILEみて無い！！
となると、他を探すこともあまりなくなって、結局、コード書いてる場面を多く見てる＞＜　

Oracle® Databaseライセンス情報 12cリリース1 (12.1) 2 オプションおよびパック
https://docs.oracle.com/cd/E49329_01/license.121/b71334/options.htm

とりあえず、SQLSETの分析レポートをDBMS_ADVISOR.CREATE_FILE()を利用して保存するやっつけスクリプトを作ってみました
これを元に育てていけるかなw

実行例）

注）STS20171102というSQLSETを事前に作成してあります。

orcl@SYS> select * from v$version;

BANNER                                                                               CON_ID
-------------------------------------------------------------------------------- ----------
Oracle Database 12c Enterprise Edition Release 12.2.0.1.0 - 64bit Production              0
PL/SQL Release 12.2.0.1.0 - Production                                                    0
CORE	12.2.0.1.0	Production                                                            0
TNS for Linux: Version 12.2.0.1.0 - Production                                            0
NLSRTL Version 12.2.0.1.0 - Production                                                    0


orcl@SYS> select owner,name,statement_count,created from dba_sqlset order by name;

OWNER      NAME                           STATEMENT_COUNT CREATED
---------- ------------------------------ --------------- ---------
SPAUSER    STS20171102                               1003 02-NOV-17

spa.sqlのパラメータは、SQLSETと分析レポートの出力ディレクトリオブジェクトとSQLを実行するスキーマ向けのDBリンクです。

スクリプトの概要
・初回の分析（SQLSETで元のSQLを分析）
・２回目の分析（新環境でSQLを実行して分析)
・初回と２回目の比較レポート作成／保存
・レポートを出力後、分析に利用したタスクを削除



orcl@SYS> @spa STS20171102 rep_dir link_4_target

task name:STS20171102 has been droped.
***END***

PL/SQL procedure successfully completed.

分析レポートは、ディレクトリオブジェクトに対応づけられたパスに保存されます

orcl@SYS> !ls -l report
-rw-r--r-- 1 oracle oinstall 13688 11月  3 02:44 DIFF_STS20171102171103024433.txt

orcl@SYS> !cat report/DIFF_STS20171102171103024433.txt

General Information
---------------------------------------------------------------------------------------------

 Task Information:                              Workload Information:                         
 ---------------------------------------------  --------------------------------------------- 
  Task Name    : STS20171102                     SQL Tuning Set Name        : STS20171102     
  Task Owner   : SYS                             SQL Tuning Set Owner       : SPAUSER         
  Description  :                                 Total SQL Statement Count  : 1003            

Execution Information:
---------------------------------------------------------------------------------------------
  Execution Name             : DIFF_STS20171102       Started             : 11/03/2017 02:44:26  
  Execution Type             : COMPARE PERFORMANCE    Last Updated        : 11/03/2017 02:44:29  
  Description                :                        Global Time Limit   : UNLIMITED            
  Scope                      : COMPREHENSIVE          Per-SQL Time Limit  : UNUSED               
  Status                     : COMPLETED              Number of Errors    : 0                    
  Number of Unsupported SQL  : 4                                                                 

Analysis Information:
---------------------------------------------------------------------------------------------
 Before Change Execution:                       After Change Execution:                       
 ---------------------------------------------  --------------------------------------------- 
  Execution Name      : SOURCE_STS20171102       Execution Name      : TARGET_STS20171102     
  Execution Type      : CONVERT SQLSET           Execution Type      : TEST EXECUTE REMOTE    
  Scope               : COMPREHENSIVE            Database Link       : LINK_4_TARGET          
  Status              : COMPLETED                Scope               : COMPREHENSIVE          
  Started             : 11/03/2017 02:44:04      Status              : COMPLETED              
  Last Updated        : 11/03/2017 02:44:04      Started             : 11/03/2017 02:44:04    
  Global Time Limit   : UNLIMITED                Last Updated        : 11/03/2017 02:44:18    
  Per-SQL Time Limit  : UNUSED                   Global Time Limit   : UNLIMITED              
                                                 Per-SQL Time Limit  : UNUSED                 
                                                 Number of Errors    : 0                      
                                                                                              
 ---------------------------------------------                                                
 Comparison Metric: ELAPSED_TIME                                                              
 ------------------                                                                           
 Workload Impact Threshold: 1%                                                                
 --------------------------                                                                   
 SQL Impact Threshold: 1%                                                                     
 ----------------------                                                                       

Report Summary
---------------------------------------------------------------------------------------------

Projected Workload Change Impact:
-------------------------------------------
 Overall Impact      :  0% 
 Improvement Impact  :  0% 
 Regression Impact   :  0% 

SQL Statement Count
-------------------------------------------
 SQL Category  SQL Count  Plan Change Count 
 Overall             999                490 
 Unchanged           995                490 
 Unsupported           4                  0 

Top 100 SQL Sorted by Absolute Value of Change Impact on the Workload
---------------------------------------------------------------------------------------------
-----------------------------------------------------------------------------------------
|           |               | Impact on | Execution | Metric | Metric | Impact | Plan   |
| object_id | sql_id        | Workload  | Frequency | Before | After  | on SQL | Change |
-----------------------------------------------------------------------------------------
|      1477 | 7hys3h7ysgf9m |       .1% |         1 |  14630 |     33 | 99.77% | n      |
|      1811 | cw6vxf0kbz3v1 |      .03% |         1 |   3602 |     24 | 99.33% | n      |
|      1175 | 2s9mmb6g8kbqb |      .01% |         1 |   1537 |     20 |  98.7% | n      |

...中略...

|      1691 | az25yp5qunj77 |      .01% |         1 |    882 |     20 | 97.73% | n      |
|      1896 | faun6bjrjqr17 |      .01% |         1 |    881 |     19 | 97.84% | n      |
|      1956 | g7a2tmw1nrxbh |      .01% |         1 |    881 |     19 | 97.84% | n      |
-----------------------------------------------------------------------------------------
Note: time statistics are displayed in microseconds
---------------------------------------------------------------------------------------------


---------------------------------------------------------------------------------------------

スクリプトは以下のとおり、無名PL/SQLブロックにしてあります。
レポートのタイプなどは固定にしてますが、それらも含めてパラメータにしてもいいかも。

ちなみに、このエントリの本題である、DBMS_ADVISOR.CREATE_FILE()は赤字部分です！

orcl@SYS> !cat spa.sql

set serveroutput on
DECLARE
	report_clob CLOB;
	cSQLSET_OWNER VARCHAR2(30) := 'SPAUSER';
	cSQLSET_NAME VARCHAR2(20) := UPPER('&1');
	cEXECUTION_NAME_PREFIX_SOURCE VARCHAR2(7) := 'SOURCE_';
	cEXECUTION_NAME_PREFIX_TARGET VARCHAR2(7) := 'TARGET_';
	cEXECUTION_NAME_PREFIX_DIFF   VARCHAR2(5) := 'DIFF_';
	cREPORT_TYPE CONSTANT VARCHAR2(4) := 'text';
	cFILE_EXTENTION CONSTANT VARCHAR2(5) := '.txt';
	cDIRECTORY_NAME CONSTANT VARCHAR2(30) := UPPER('&2');
	cDB_LINK_4_PARSING_SCHEMA CONSTANT VARCHAR2(128) := UPPER('&3');
	stmt_task VARCHAR2(64);

	PROCEDURE drop_task (iTASK_NAME VARCHAR2)
	IS
	BEGIN
        	FOR task_rec IN (
                	SELECT
                        	task_name
                	FROM
                        	dba_advisor_tasks
                	WHERE
                        	task_name = iTASK_NAME
                        	AND advisor_name = 'SQL Performance Analyzer'
        	) LOOP
                	DBMS_OUTPUT.PUT_LINE(
				'task name:'||task_rec.task_name||' has been droped.'
			);
                	DBMS_SQLPA.DROP_ANALYSIS_TASK(
            			task_name => task_rec.task_name
                	);
        	END LOOP;
	END drop_task;
BEGIN
	--Create analysis task
	stmt_task := DBMS_SQLPA.CREATE_ANALYSIS_TASK(
		sqlset_name => cSQLSET_NAME
		,basic_filter => 'parsing_schema_name in (''SCOTT'')'
		,sqlset_owner => cSQLSET_OWNER
		,task_name => cSQLSET_NAME
	);

	--SQL Analysis on Source DB
	DBMS_SQLPA.EXECUTE_ANALYSIS_TASK(
		task_name => cSQLSET_NAME
		,execution_type => 'CONVERT SQLSET'
		,execution_name => 
			cEXECUTION_NAME_PREFIX_SOURCE
			|| cSQLSET_NAME
		,execution_params => 
			DBMS_ADVISOR.ARGLIST(
				'sqlset_name', cSQLSET_NAME
				,'sqlset_owner', cSQLSET_OWNER
		)
	);

	--SQL Analysis on Target DB
	DBMS_SQLPA.EXECUTE_ANALYSIS_TASK(
		task_name => cSQLSET_NAME
		,execution_type => 'EXECUTE'
		,execution_name => 
			cEXECUTION_NAME_PREFIX_TARGET
			|| cSQLSET_NAME
		,execution_params =>
			DBMS_ADVISOR.ARGLIST(
				'DATABASE_LINK', cDB_LINK_4_PARSING_SCHEMA	
				,'EXECUTE_FULLDML', 'TRUE'
			)
	);

	--Comparison Source and Target Analysys 
	DBMS_SQLPA.EXECUTE_ANALYSIS_TASK(
		task_name => cSQLSET_NAME
		,execution_type => 'COMPARE'
		,execution_name => 
			cEXECUTION_NAME_PREFIX_DIFF
			|| cSQLSET_NAME
		,execution_params =>
			DBMS_ADVISOR.ARGLIST(
				'PLAN_LINES_COMPARISON','ALWAYS'
			)
	);

	--Make comparison report
	report_clob := DBMS_SQLPA.REPORT_ANALYSIS_TASK(
		task_name => cSQLSET_NAME
		,execution_name => 
			cEXECUTION_NAME_PREFIX_DIFF
			|| cSQLSET_NAME
		,type => cREPORT_TYPE
		,level => 'typical'
		,section => 'summary'
	);

	--Save comparison report
	DBMS_ADVISOR.CREATE_FILE(
		buffer => report_clob
		,location => cDIRECTORY_NAME
		,filename => 
			cEXECUTION_NAME_PREFIX_DIFF
			||cSQLSET_NAME
			||TO_CHAR(systimestamp, 'RRMMDDHH24MISS')
			||cFILE_EXTENTION
	);

	--Drop Task
	drop_task(cSQLSET_NAME);
	DBMS_OUTPUT.PUT_LINE('***END***');
EXCEPTION
	WHEN OTHERS THEN
		drop_task(cSQLSET_NAME);
		RAISE;
END;
/

・DBMS_SQLTUNE.PACK_STGTAB_SQLSETって、例外投げんのかよw
・SQL Tuning Setのキャプチャから退避までのスクリプト（やっつけ）
・SQL Tuning Set (STS)のフィルタリング

投稿日時 2017年11月 3日 (金) 16時51分 PL/SQL, チューニング, SQL, Oracle Database 11g, Oracle Database 11g Release 2, Oracle Database 12c release 1, Oracle Database 12c Release 2 | 固定リンク | 0 | コメント (0) | トラックバック (0)

2017年10月30日 (月)

SQL Tuning Set (STS)のフィルタリング

Previously on Mac De Oracle
前回は、やっつけすくりぷとを書いたところまででした。

ということで、今回のやっつけスクリプトの準備というかアイデア

SQLSET大量のSQL文キャプチャされていて、SQLSETにキャプチャされている大量のSQL文を一括でSPAでまわしたりすることが辛い場合があります。
そんなときはどうすればよいか。。なやみますよね。。。ほんと。。
SQL Performance AnalyzerによるSQLパフォーマンス比較実行例(API)

SQLSETから、より細かなSQLSETにほぼ当分に分割し、新たなSQLSETを作成したいような場合もあるかもしれません。
そんな時はどうするか？

手取りばやくやるなら、ORA_HASH()が便利ですよね。（SQLSETの全表走査はさけられないのですが、Exaならw）

たとえば、以下のSQLSETがあったとして、300件程度に均等に分割したいという場合。
ora_hash()のバケット数はだいたい12ぐらいでできそうですね。

orcl@SYS> select name,statement_count,created from dba_sqlset order by name;

NAME                           STATEMENT_COUNT CREATED
------------------------------ --------------- ---------
STS20171029                               3819 29-OCT-17

orcl@SYS> select statement_count/300 from dba_sqlset where name='STS20171029';

STATEMENT_COUNT/300
-------------------
              12.73

いい感じに分割できそうです。

orcl@SYS> r
  1  select
  2    ora_hash(sql_id,12) as hash#
  3   ,count(sql_id)
  4  from
  5    table(dbms_sqltune.select_sqlset(
  6      sqlset_name=>'STS20171029'
  7     ,basic_filter=>null
  8    ))
  9  group by
 10    ora_hash(sql_id,12)
 11* order by 1

     HASH# COUNT(SQL_ID)
---------- -------------
         0           289
         1           293
         2           278
         3           296
         4           297
         5           281
         6           282
         7           298
         8           288
         9           304
        10           305
        11           298
        12           310

13 rows selected.

実際に利用するには、basic_filterでwhere句の条件文そのものを書いてあげます。サブクエリも書けますが、データ量が多い場合は性能面に注意しながらいろいろ試してみるといいと思います。
basic_filterでは、SQLSET_ROWオブジェクト・タイプの属性を利用したフィルタリングができるのですが、インジェクションですよね。構文を見ている限り;)
Oracle® Database PL/SQLパッケージおよびタイプ・リファレンス 12c リリース1 (12.1) SQLSET_ROWオブジェクト・タイプ

orcl@SYS> set serveroutput on
orcl@SYS> r
  1  begin
  2    for i in 0..12 loop
  3      for sqlset_rec in
  4      (
  5        select count(sql_id) as num_sql
  6        from
  7          table(dbms_sqltune.select_sqlset(
  8            sqlset_name=>'STS20171029'
  9           ,basic_filter=>'ora_hash(sql_id,12)='||i
 10          ))
 11      )
 12      loop
 13        dbms_output.put_line('hash#='||to_char(i,'fm99')||':'||sqlset_rec.num_sql);
 14      end loop;
 15    end loop;
 16* end;
hash#=0:289
hash#=1:293
hash#=2:278
hash#=3:296
hash#=4:297
hash#=5:281
hash#=6:282
hash#=7:298
hash#=8:288
hash#=9:304
hash#=10:305
hash#=11:298
hash#=12:310

PL/SQL procedure successfully completed.

ハッシュ値10でsql_id数をカウント！
うまくできそうですよね。

orcl@SYS> r
  1  select
  2    count(sql_id)
  3  from
  4    table(dbms_sqltune.select_sqlset(
  5      sqlset_name=>'STS20171029'
  6     ,basic_filter=>'ora_hash(sql_id,12) = 10'
  7*   ))

COUNT(SQL_ID)
-------------
          305

参考
Oracle® Database PL/SQLパッケージおよびタイプ・リファレンス　12c リリース1 (12.1) DBMS_SQLTUNE
Oracle® Database SQL言語リファレンス 12cリリース1 (12.1) ORA_HASH

・DBMS_SQLTUNE.PACK_STGTAB_SQLSETって、例外投げんのかよw
・SQL Tuning Setのキャプチャから退避までのスクリプト（やっつけ）

投稿日時 2017年10月30日 (月) 01時22分 PL/SQL, チューニング, SQL, Oracle Database 11g, Oracle Database 11g Release 2, Oracle Database 12c release 1, Oracle Database 12c Release 2 | 固定リンク | 0 | コメント (0) | トラックバック (0)

2017年10月 7日 (土)

SQL Tuning Setのキャプチャから退避までのスクリプト（やっつけ）

Previously on Mac De Oracleは
DBMS_SQLTUNE.PACK_STGTAB_SQLSETって、例外投げんのかよwという備忘録でした、

今回は
以下のURLで紹介されているSTS (SQL Tuning Set)へSQLの性能統計や実行計画をキャプチャしちゃおう！
Oracle DatabaseのSTS(SQL Tuning Set) を活用して、SQLの性能統計や実行計画をキャプチャする。 / ora_gonsuke777

というSTS機能を利用した応用編w　（という名のやっつけスクリプト）　を書いたので、備忘録

STSでSQLの実行計画や性能統計をキャプチャするのはいいのですが、キャプチャするデータが多い場合、SYSAUX表領域を圧迫したり、拡張したりしてしまうことがあります。
本番環境で表領域サイズにドキドキする日々を送るのも嫌なので、一定期間STSヘキャプチャしたあとSTSを退避、削除したいよね。という方向の話が湧いてきたりしますw

で、書いたやっつけスクリプトが以下。(11g2と12cR1でテスト済み）
STSをキャプチャする時間、インターバル、そして、STSを退避するためのステージング表を作成するスキーマ名と、エクスポートに必要なディレクトリオブジェクト名を
パラメータに取ります。キャプチャする時間とインターバルは秒を指定します。エクスポートは、DBMS_DATAPUMPパッケージを利用しています。
今回利用したパッケージの詳細は以下を参照のこと:)

Oracle® Database PL/SQLパッケージおよびタイプ・リファレンス 11g リリース2(11.2) B56262-06
- DBMS_SQLTUNEサブプログラムの要約
- 46 DBMS_DATAPUMP

なお、本スクリプト実施前に、DataPump Export向けディレクトリオブジェクトを、ステージング表を作成するユーザを作成しておく必要があります。
（後半の実行例は、STS_EXP_DIRディレクトリオブジェクト、STSUSRユーザを事前に作成）
sts_capture.sql

SET SERVEROUTPUT ON
/*
  Arguments :
    &1 - Schema name for sts staging table
    &2 - Directory object name for Data Pump Export
    &3 - Duration for SQLSET capturing (sec)
    &4 - Sampling interval for SQLSET (sec)
*/
DECLARE
  -- for STS capturing and packing
  vStsName VARCHAR2(30) := 'STS' || TO_CHAR(SYSDATE, 'YYYYMMDDHH24MISS');
  cTimeLimit CONSTANT POSITIVE := &3;  
  cInterval CONSTANT POSITIVE := &4; 
  cCaptureOpt CONSTANT VARCHAR2(20) := 'MERGE';
  cStagingSchema CONSTANT VARCHAR2(30) := UPPER('&1');
  v4Debug VARCHAR2(50);
  
  -- for DataPump Export Job
  cDirectory CONSTANT VARCHAR2(20) := UPPER('&2');
  IsSkipExport BOOLEAN := false;
  i NUMBER;
  vDataPumpJobHandle NUMBER; 
  vProgress_ratio NUMBER;
  vJobState VARCHAR2(30);
  oLogEntry ku$_LogEntry;
  oStatus ku$_Status;
BEGIN
  DBMS_OUTPUT.ENABLE;
  
  -- STS名にInstance#を付加
  -- （RAC環境での複数ノードでの実行を考慮してインスタンス番号を付加）
  v4Debug := 'Build STSNAME';
  FOR instance_rec IN (SELECT TO_CHAR(instance_number) AS inum FROM v$instance) LOOP
    vStsName := vStsName || instance_rec.inum;
  END LOOP;
  
  -- SQLSETの作成
  v4Debug := 'CREATE_SQLSET';
  DBMS_SQLTUNE.CREATE_SQLSET (
    sqlset_name => vStsName
    ,sqlset_owner => NULL
  );

  -- カーソルキャッシュからSTSへ定期キャプチャ
  v4Debug := 'CAPTURE_CURSOR_CACHE_SQLSET';
  DBMS_SQLTUNE.CAPTURE_CURSOR_CACHE_SQLSET (
    sqlset_name => vStsName
    ,time_limit => cTimeLimit
    ,repeat_interval => cInterval
    ,capture_option => cCaptureOpt
    ,capture_mode => DBMS_SQLTUNE.MODE_REPLACE_OLD_STATS
    ,basic_filter =>
      'parsing_schema_name NOT IN (
         ''SYS'', ''SYSTEM'', ''APEX_050000'', ''APEX_040000'', ''SYSMAN''
      )'
    ,sqlset_owner => NULL
  );
  
  -- STSエクスポート向けステージング表の作成
  v4Debug := 'CREATE_STGTAB_SQLSET';
  DBMS_SQLTUNE.CREATE_STGTAB_SQLSET (
    table_name => vStsName
    ,schema_name => cStagingSchema
    ,db_version => NULL
  );
  
  -- STSをステージング表へパック
  v4Debug := 'PACK_STGTAB_SQLSET';
  BEGIN
  DBMS_SQLTUNE.PACK_STGTAB_SQLSET (
    sqlset_name => vStsName
    ,sqlset_owner => NULL
    ,staging_table_name => vStsName
    ,staging_schema_owner => cStagingSchema
    ,db_version => NULL
  );
  EXCEPTION
    WHEN OTHERS THEN
      IF sqlcode = -15701 THEN
        IsSkipExport := true;
        DBMS_OUTPUT.PUT_LINE('*** Info - No data packed from SQLSET ***');
      ELSE
        RAISE;
      END IF;
  END;

  IF IsSkipExport = false 
  THEN
    -- ステージング表を表モードでエクスポート 
    -- エクスポートのモード等の設定
    v4Debug := 'OPEN';
    vDataPumpJobHandle 
     := DBMS_DATAPUMP.OPEN (
       operation => 'EXPORT'
       ,job_mode => 'TABLE'
       ,remote_link => NULL
       ,job_name => vStsName
       ,version => 'LATEST'
     );

    -- エスポートダンプファイルとログファイルの設定
    v4Debug := 'ADD_FILE - dumpfile';
    DBMS_DATAPUMP.ADD_FILE (
      handle => vDataPumpJobHandle
      ,filename => vStsName || '.dmp'
      ,directory => cDirectory
      ,filetype => DBMS_DATAPUMP.KU$_FILE_TYPE_DUMP_FILE
    );

    v4Debug := 'ADD_FILE - logfile';
    DBMS_DATAPUMP.ADD_FILE (
      handle => vDataPumpJobHandle
      ,filename => vStsName || '.log'
      ,directory => cDirectory
      ,filetype => DBMS_DATAPUMP.KU$_FILE_TYPE_LOG_FILE
    );

    -- メターデータフィルタの設定
    -- エクスポート対象表のスキーマ
    v4Debug := 'METADATA_FILTER - schema name';
    DBMS_DATAPUMP.METADATA_FILTER (
      handle => vDataPumpJobHandle
      ,name => 'SCHEMA_LIST'
      ,value => '''' || cStagingSchema || ''''
    );

    -- エクスポート対象表
    v4Debug := 'METADATA_FILTER - table name';
    DBMS_DATAPUMP.METADATA_FILTER (
      handle => vDataPumpJobHandle
      ,name => 'NAME_LIST'
      ,value => '''' || vStsName || ''''
    );

    -- DataPump Exportジョブの実行
    v4Debug := 'START_JOB';
    DBMS_DATAPUMP.START_JOB (
      handle => vDataPumpJobHandle
    );

    -- DataPump Exportジョブ状況監視と終了判定
    -- ジョブ終了または停止されるまでループして待機
    v4Debug := 'JOB_STATE';
    vProgress_ratio := 0;
    vJobState := 'UNDEFINED';
    WHILE (vJobState != 'COMPLETED') AND (vJobState != 'STOPPED') LOOP
      DBMS_DATAPUMP.GET_STATUS (
        vDataPumpJobHandle
        ,DBMS_DATAPUMP.KU$_STATUS_JOB_ERROR 
          + DBMS_DATAPUMP.KU$_STATUS_JOB_STATUS 
          + DBMS_DATAPUMP.KU$_STATUS_WIP
        ,-1
        ,vJobState
        ,oStatus
      );

      -- 処理中(Work-In-Progress : WIP)または、
      -- エラーのいずれかのメッセージを受け取ったら表示
      IF (BITAND(oStatus.mask, DBMS_DATAPUMP.KU$_STATUS_WIP) != 0)
      THEN
        oLogEntry := oStatus.wip;
      ELSE
        IF (BITAND(oStatus.mask, DBMS_DATAPUMP.KU$_STATUS_JOB_ERROR) != 0)
        THEN
          oLogEntry := oStatus.error;
        ELSE
          oLogEntry := NULL;
        END IF;
      END IF;
      IF oLogEntry IS NOT NULL
      THEN
        i := oLogEntry.FIRST;
        WHILE i IS NOT NULL LOOP
          DBMS_OUTPUT.PUT_LINE(oLogEntry(i).LogText);
          i := oLogEntry.NEXT(i);
        END LOOP;
      END IF;
    END LOOP;

    -- Data Pump Exportジョブ終了
    DBMS_DATAPUMP.DETACH(vDataPumpJobHandle);
  END IF;
    
  -- ステージング表の削除
  v4Debug := 'Drop staging table';
  EXECUTE IMMEDIATE 'DROP TABLE ' || cStagingSchema || '.' || vStsName || ' PURGE';
  
  -- SQLSETの削除
  v4Debug := 'DROP_SQLSET';
  DBMS_SQLTUNE.DROP_SQLSET (
    sqlset_name => vStsName
  );

EXCEPTION
  WHEN OTHERS THEN
    DBMS_OUTPUT.PUT_LINE(sqlerrm());
    DBMS_OUTPUT.PUT_LINE(v4Debug);
    RAISE;
END;
/
EXIT

STSが空ではない場合の実行例
キャプチャ処理は600秒実行しキャプチャ間隔は120秒、キャプチャ終了後、STSUSRスキーマにステージング表を作成、STSをステージング表へパック、ステージング表を指定したディレクトリオブジェクト以下にDataPump Exportしています。

[oracle@guppy ˜]$ sqlplus system@orcl @sts_capture stsusr sts_exp_dir 10*60 2*60

SQL*Plus: Release 12.1.0.2.0 Production on Fri Oct 6 15:13:53 2017

Copyright (c) 1982, 2014, Oracle.  All rights reserved.

Enter password: 

Connected to:
Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production
With the Partitioning, OLAP, Advanced Analytics and Real Application Testing options

old   4:   cTimeLimit CONSTANT POSITIVE := &3;
new   4:   cTimeLimit CONSTANT POSITIVE := 10*60;
old   5:   cInterval CONSTANT POSITIVE := &4;
new   5:   cInterval CONSTANT POSITIVE := 2*60;
old   7:   cStagingSchema CONSTANT VARCHAR2(30) := UPPER('&1');
new   7:   cStagingSchema CONSTANT VARCHAR2(30) := UPPER('stsusr');
old  11:   cDirectory CONSTANT VARCHAR2(20) := UPPER('&2');
new  11:   cDirectory CONSTANT VARCHAR2(20) := UPPER('sts_exp_dir');
Starting "SYS"."STS201710061513571":
Estimate in progress using BLOCKS method...
Processing object type TABLE_EXPORT/TABLE/TABLE_DATA
Total estimation using BLOCKS method: 1.062 MB
Processing object type TABLE_EXPORT/TABLE/TABLE
Processing object type TABLE_EXPORT/TABLE/INDEX/STATISTICS/INDEX_STATISTICS
Processing object type TABLE_EXPORT/TABLE/STATISTICS/TABLE_STATISTICS
Processing object type TABLE_EXPORT/TABLE/STATISTICS/MARKER
. . exported "STSUSR"."STS201710061513571"               51.55 KB       1 rows
Master table "SYS"."STS201710061513571" successfully loaded/unloaded
******************************************************************************
Dump file set for SYS.STS201710061513571 is:
/home/oracle/exp/STS201710061513571.dmp
Job "SYS"."STS201710061513571" successfully completed at Fri Oct 6 15:26:50 2017 elapsed 0 00:00:47

PL/SQL procedure successfully completed.

STSが空の場合の例
ステージング表へのSTSのパックやDataPump Exportの実行をパイパス。STSが空であることを表示して終了します。
なお、以下の例ではキャプチャ時間と間隔は意図的に短くしてあります。

[oracle@guppy  ˜]$ sqlplus system@orcl @sts_capture stsusr sts_exp_dir 2*60 60

SQL*Plus: Release 12.1.0.2.0 Production on Fri Oct 6 16:04:55 2017

Copyright (c) 1982, 2014, Oracle.  All rights reserved.

Enter password: 

Connected to:
Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production
With the Partitioning, OLAP, Advanced Analytics and Real Application Testing options

old   4:   cTimeLimit CONSTANT POSITIVE := &3;
new   4:   cTimeLimit CONSTANT POSITIVE := 2*60;
old   5:   cInterval CONSTANT POSITIVE := &4;
new   5:   cInterval CONSTANT POSITIVE := 60;
old   7:   cStagingSchema CONSTANT VARCHAR2(30) := UPPER('&1');
new   7:   cStagingSchema CONSTANT VARCHAR2(30) := UPPER('stsusr');
old  11:   cDirectory CONSTANT VARCHAR2(20) := UPPER('&2');
new  11:   cDirectory CONSTANT VARCHAR2(20) := UPPER('sts_exp_dir');
*** Info - No data packed from SQLSET ***

PL/SQL procedure successfully completed.

このスクリプトをshellに組み込んでcronでも定期実行したりDBMS_SCHEDULERで定期実行するのも良いかな。
オレオレサンプルなので、より便利に改造して使ってね。v

投稿日時 2017年10月 7日 (土) 00時48分チューニング, SQL, Oracle Database 11g, Oracle Database 11g Release 2, Oracle Database 12c release 1, Oracle Database 12c Release 2 | 固定リンク | 0 | コメント (0) | トラックバック (0)

2017年9月 1日 (金)

ORA-12034 #2

前回の通り、高速リフレッシュの間にdata pump export / importを完了させれば、ORA-12034なんて起きないはず。

VirtualBoxの環境は試験開始前のスナップショットで戻してあります

SQL*Plus: Release 12.1.0.2.0 Production on Mon Aug 28 20:57:49 2017

Copyright (c) 1982, 2014, Oracle.  All rights reserved.

Connected to:
Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production
With the Partitioning, OLAP, Advanced Analytics and Real Application Testing options

orcl@MVIEW_SCHEMA1> @mview_info_c
Connected.

¥Session altered.

ROWNER               RNAME                  REFGROUP        JOB B INTERVAL             NEXT_DATE               CON_ID
-------------------- -------------------- ---------- ---------- - -------------------- ------------------- ----------
MVIEW_SCHEMA1        MV_MASTER                    61         81 N sysdate+5/1440       2017/08/28 21:00:54          3

MVIEW_NAME                     REFRES REFRESH_ LAST_REF AFTER_FAST_REFRESH  COMPILE_STATE
------------------------------ ------ -------- -------- ------------------- -------------------
MV_MASTER                      DEMAND FAST     FAST     UNDEFINED           VALID

       JOB LOG_USER             SCHEMA_USER          LAST_DATE           NEXT_DATE           INTERVAL               FAILURES WHAT
---------- -------------------- -------------------- ------------------- ------------------- -------------------- ---------- ------------------------------------------------------------
        81 MVIEW_SCHEMA1        MVIEW_SCHEMA1        2017/08/28 20:55:54 2017/08/28 21:00:54 sysdate+5/1440                0 dbms_refresh.refresh('"MVIEW_SCHEMA1"."MV_MASTER"');

前回は5分間隔だったので、余裕をもたせて30分にしてあります。
本番環境で5分間隔の高速リフレッシュを30分にしたり、止めたりってことはかなり敷居が高いとは思いますが、そのあたりは空気を読んで対応する必要があるかと。　:)

orcl12c@SYS> conn mview_schema1@orcl
Connected.
orcl@MVIEW_SCHEMA1> alter materialized view mv_master refresh next sysdate+30/1440;

Materialized view altered.

orcl@MVIEW_SCHEMA1> @mview_info_c
Connected.

Session altered.


ROWNER               RNAME                  REFGROUP        JOB B INTERVAL             NEXT_DATE               CON_ID
-------------------- -------------------- ---------- ---------- - -------------------- ------------------- ----------
MVIEW_SCHEMA1        MV_MASTER                    61         81 N sysdate+30/1440      2017/08/28 21:30:36          3

MVIEW_NAME                     REFRES REFRESH_ LAST_REF AFTER_FAST_REFRESH  COMPILE_STATE
------------------------------ ------ -------- -------- ------------------- -------------------
MV_MASTER                      DEMAND FAST     FAST     UNDEFINED           VALID

       JOB LOG_USER             SCHEMA_USER          LAST_DATE           NEXT_DATE           INTERVAL               FAILURES WHAT
---------- -------------------- -------------------- ------------------- ------------------- -------------------- ---------- ------------------------------------------------------------
        81 MVIEW_SCHEMA1        MVIEW_SCHEMA1        2017/08/28 20:55:54 2017/08/28 21:30:36 sysdate+30/1440               0 dbms_refresh.refresh('"MVIEW_SCHEMA1"."MV_MASTER"');

準備は整ったので、高速リフレッシュが終わったタイミングでexportからimportまでをやっつけちゃいます！
まずはエクスポート

Connected to: Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production
With the Partitioning, OLAP, Advanced Analytics and Real Application Testing options
Starting "SYSTEM"."SYS_EXPORT_SCHEMA_01":  system/********@orcl directory=workdir dumpfile=mview_schema1.dmp logfile=exp_mview_schema1.log schemas=mview_schema1 
Estimate in progress using BLOCKS method...
Processing object type SCHEMA_EXPORT/TABLE/TABLE_DATA
Total estimation using BLOCKS method: 64 KB
Processing object type SCHEMA_EXPORT/USER
Processing object type SCHEMA_EXPORT/SYSTEM_GRANT
Processing object type SCHEMA_EXPORT/DEFAULT_ROLE
Processing object type SCHEMA_EXPORT/TABLESPACE_QUOTA
Processing object type SCHEMA_EXPORT/PRE_SCHEMA/PROCACT_SCHEMA
Processing object type SCHEMA_EXPORT/DB_LINK
Processing object type SCHEMA_EXPORT/TABLE/TABLE
Processing object type SCHEMA_EXPORT/TABLE/COMMENT
Processing object type SCHEMA_EXPORT/TABLE/CONSTRAINT/CONSTRAINT
Processing object type SCHEMA_EXPORT/TABLE/INDEX/STATISTICS/INDEX_STATISTICS
Processing object type SCHEMA_EXPORT/TABLE/STATISTICS/TABLE_STATISTICS
Processing object type SCHEMA_EXPORT/STATISTICS/MARKER
Processing object type SCHEMA_EXPORT/MATERIALIZED_VIEW
Processing object type SCHEMA_EXPORT/JOB
Processing object type SCHEMA_EXPORT/REFRESH_GROUP
. . exported "MVIEW_SCHEMA1"."MV_MASTER"                   5.5 KB       2 rows
Master table "SYSTEM"."SYS_EXPORT_SCHEMA_01" successfully loaded/unloaded
******************************************************************************
Dump file set for SYSTEM.SYS_EXPORT_SCHEMA_01 is:
  /u01/userhome/oracle/mview_schema1.dmp
Job "SYSTEM"."SYS_EXPORT_SCHEMA_01" successfully completed at Mon Aug 28 21:05:00 2017 elapsed 0 00:00:56

[oracle@vbgeneric ˜]$ sqlplus master_schema@orcl

SQL*Plus: Release 12.1.0.2.0 Production on Mon Aug 28 21:05:19 2017

Copyright (c) 1982, 2014, Oracle.  All rights reserved.


Connected to:
Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production
With the Partitioning, OLAP, Advanced Analytics and Real Application Testing options

orcl@MASTER_SCHEMA> select count(*) from mlog$_master;

  COUNT(*)
----------
         0

orcl@MASTER_SCHEMA> conn mview_schema1@orcl
Connected.

orcl@MVIEW_SCHEMA1> @mview_info_c
Connected.

Session altered.


ROWNER               RNAME                  REFGROUP        JOB B INTERVAL             NEXT_DATE               CON_ID
-------------------- -------------------- ---------- ---------- - -------------------- ------------------- ----------
MVIEW_SCHEMA1        MV_MASTER                    61         81 N sysdate+30/1440      2017/08/28 21:30:36          3

MVIEW_NAME                     REFRES REFRESH_ LAST_REF AFTER_FAST_REFRESH  COMPILE_STATE
------------------------------ ------ -------- -------- ------------------- -------------------
MV_MASTER                      DEMAND FAST     FAST     UNDEFINED           VALID

       JOB LOG_USER             SCHEMA_USER          LAST_DATE           NEXT_DATE           INTERVAL               FAILURES WHAT
---------- -------------------- -------------------- ------------------- ------------------- -------------------- ---------- ------------------------------------------------------------
        81 MVIEW_SCHEMA1        MVIEW_SCHEMA1        2017/08/28 20:55:54 2017/08/28 21:30:36 sysdate+30/1440               0 dbms_refresh.refresh('"MVIEW_SCHEMA1"."MV_MASTER"');

次にインポートしてMviewを複製！　

orcl12c@SYS> conn system@orcl2
Connected.
orcl2@SYSTEM>  create directory workdir as '/u01/userhome/oracle';

Directory created.

orcl2@SYSTEM> exit
Disconnected from Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production
With the Partitioning, OLAP, Advanced Analytics and Real Application Testing options
[oracle@vbgeneric ˜]$ impdp system@orcl2 directory=workdir dumpfile=mview_schema1.dmp logfile=imp_mview_schema1.dmp 

Import: Release 12.1.0.2.0 - Production on Mon Aug 28 21:07:13 2017

Copyright (c) 1982, 2014, Oracle and/or its affiliates.  All rights reserved.

Connected to: Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production
With the Partitioning, OLAP, Advanced Analytics and Real Application Testing options
Master table "SYSTEM"."SYS_IMPORT_FULL_01" successfully loaded/unloaded
Starting "SYSTEM"."SYS_IMPORT_FULL_01":  system/********@orcl2 directory=workdir dumpfile=mview_schema1.dmp logfile=imp_mview_schema1.dmp 
Processing object type SCHEMA_EXPORT/USER
Processing object type SCHEMA_EXPORT/SYSTEM_GRANT
Processing object type SCHEMA_EXPORT/DEFAULT_ROLE
Processing object type SCHEMA_EXPORT/TABLESPACE_QUOTA
Processing object type SCHEMA_EXPORT/PRE_SCHEMA/PROCACT_SCHEMA
Processing object type SCHEMA_EXPORT/DB_LINK
Processing object type SCHEMA_EXPORT/TABLE/TABLE
Processing object type SCHEMA_EXPORT/TABLE/TABLE_DATA
. . imported "MVIEW_SCHEMA1"."MV_MASTER"                   5.5 KB       2 rows
Processing object type SCHEMA_EXPORT/TABLE/COMMENT
Processing object type SCHEMA_EXPORT/TABLE/CONSTRAINT/CONSTRAINT
Processing object type SCHEMA_EXPORT/TABLE/INDEX/STATISTICS/INDEX_STATISTICS
Processing object type SCHEMA_EXPORT/TABLE/STATISTICS/TABLE_STATISTICS
Processing object type SCHEMA_EXPORT/STATISTICS/MARKER
Processing object type SCHEMA_EXPORT/MATERIALIZED_VIEW
Processing object type SCHEMA_EXPORT/JOB
Processing object type SCHEMA_EXPORT/REFRESH_GROUP
Job "SYSTEM"."SYS_IMPORT_FULL_01" successfully completed at Mon Aug 28 21:07:40 2017 elapsed 0 00:00:23

複製完了！！！！
結果はいかに...

[oracle@vbgeneric ˜]$ sqlplus mview_schema1@orcl2

SQL*Plus: Release 12.1.0.2.0 Production on Mon Aug 28 21:08:09 2017

Copyright (c) 1982, 2014, Oracle.  All rights reserved.


Connected to:
Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production
With the Partitioning, OLAP, Advanced Analytics and Real Application Testing options

orcl2@MVIEW_SCHEMA1> @mview_info_c
Connected.

Session altered.

ROWNER               RNAME                  REFGROUP        JOB B INTERVAL             NEXT_DATE               CON_ID
-------------------- -------------------- ---------- ---------- - -------------------- ------------------- ----------
MVIEW_SCHEMA1        MV_MASTER                    61         81 N sysdate+30/1440      2017/08/28 22:00:46          5
MVIEW_SCHEMA1        MV_MASTER                    61         81 N sysdate+30/1440      2017/08/28 22:00:46          3

MVIEW_NAME                     REFRES REFRESH_ LAST_REF AFTER_FAST_REFRESH  COMPILE_STATE
------------------------------ ------ -------- -------- ------------------- -------------------
MV_MASTER                      DEMAND FAST     FAST     UNDEFINED           VALID
MV_MASTER                      DEMAND FAST     FAST     UNDEFINED           VALID

       JOB LOG_USER             SCHEMA_USER          LAST_DATE           NEXT_DATE           INTERVAL               FAILURES WHAT
---------- -------------------- -------------------- ------------------- ------------------- -------------------- ---------- ------------------------------------------------------------
        81 MVIEW_SCHEMA1        MVIEW_SCHEMA1        2017/08/28 21:30:46 2017/08/28 22:00:46 sysdate+30/1440               0 dbms_refresh.refresh('"MVIEW_SCHEMA1"."MV_MASTER"');
        81 MVIEW_SCHEMA1        MVIEW_SCHEMA1        2017/08/28 21:30:46 2017/08/28 22:00:46 sysdate+30/1440               0 dbms_refresh.refresh('"MVIEW_SCHEMA1"."MV_MASTER"');

予想通り成功しました！

エクスポート〜インポートによるMVIEW複製までを高速リフレッシュの間に行うことが可能ならば例のエラーは回避できることが確認できました。
が、
小さなMViewならまだしも、巨大なMView、巨大なMViewが複数あるリフレッシュグループだったりすると、それはもう大変な作業になることは想像できます。
大人の事情でMViewの高速リフレッシュを止められない、とか高速リフレッシュ間隔が非常短い場合には無理しないで、ほかの手を考えた方が良いと思います。
ただし、他の手を進めるにも時間には余裕を持った方がいいですよね。なんでギリギリなんだろうねと、よく思います。
夏休みの最後の1週間で宿題全部やりきるみたいなのは嫌ですよねw

Data Pumpも癖モノだよね〜w　その１ - queryパラメーターの解析タイミング
Data Pumpも癖モノだよね〜w　その２ - Materialized ViewをTableとして移行する
Data Pumpも癖モノだよね〜w　その3 - dbms_job と dbms_scheduler との複雑な関係
Data Pumpも癖モノだよね〜w　その4 - schemaモードでMviewを他のPDBへ複製
Data Pumpも癖モノだよね〜w　その4と1/2 - schemaモードでMviewを他のPDBへ複製 (紛らわしいステータスw）
Data Pumpも癖モノだよね〜w　その5 - schemaモードでMviewを他のPDBへ複製（オプジェクトパス de 絞り込み）
Data Pumpも癖モノだよね〜w　その6 - schemaモードでMviewを他のPDBへ複製（オプジェクトパスが不足すると...）
ORA-12034

投稿日時 2017年9月 1日 (金) 06時00分 FAQ, Oracle Database 11g, Oracle Database 11g Release 2, Oracle Database 12c release 1, Oracle Database 12c Release 2 | 固定リンク | 0 | コメント (0) | トラックバック (0)

2017年8月31日 (木)

ORA-12034

一ヶ月の家庭内、ワンオペも無事終了したので、ブログも今年前半のペースで再開か！？w

ということで、
以前ちょっとだけ書いた高速リフレッシュを止めてないと完全リフレッシュが必要になってしまう。タイミングの問題にフォーカスしてみようと思います。

どのようなタイミングの問題かというと、

ORA-12034: materialized view log on "xxxxxx"."xxxxxxx" younger than last refresh

出会った方も意外と多かったりしてw　

前述のエラーは、materialized view logが絡んいるので、”高速リフレッシュ”時に発生するエラーです！
高速リフレッシュを行なっている環境でこの状態になってしまうと、”高速リフレッシュ”の再開には”完全リフレッシュ”が必須となってしまうところが怖いというか面倒くさいところ。
マスターサイトも含めて同期するサイズが小さければ完全リフレッシュも面倒なことにならない場合もありますが、数十GB以上の巨大なマテビューだったら、どうします？？？
マテリアライズドビューのリフレッシュ間隔が短いシステムだと、完全リフレッシュに要する時間が大問題になることも... (色々な状況が想定されていない構成だと、そうなりやすい.....なw

もう少し簡単に言うと、
materialized view logの伝播が必要なデータ有無に関係なく、リフレッシュ時刻を跨いてしまうかどうか！　なんですよね、これ。

実際にどうなるか、materialized view logは空の状態で、Data Pumpも癖モノだよね〜w　その２ - Materialized ViewをTableとして移行する
の環境を利用して再現させてみます。環境の詳細は、Data Pumpも癖モノだよね〜w　その4 - schemaモードでMviewを他のPDBへ複製参照のこと。

VirtualBoxのスナップショットから基本レプリケーション環境構築済みの状態（以前いろいろ行った試験前の状態）に戻してあります。

まず、高速リフレッシュの状態がどうなっているか確認してみると....５分間隔（INTERVAL列）で動作中であることがわかりますよね！（DBMS_JOBのINTERVALの指定方法っ非直感的わかりづらいので早くなくなってほしいw）
直近の高速リフレッシュが終わり、MLOGも0件。つまりマテリアライズドビューに反映する必要のあるデータは存在しない状態にしてあります。



orcl@MVIEW_SCHEMA1> select job,log_user,schema_user,last_date,next_date,interval,failures,what from user_jobs;

       JOB LOG_USER             SCHEMA_USER          LAST_DATE           NEXT_DATE           INTERVAL               FAILURES WHAT
---------- -------------------- -------------------- ------------------- ------------------- -------------------- ---------- ------------------------------------------------------------
        81 MVIEW_SCHEMA1        MVIEW_SCHEMA1        2017/08/28 09:00:44 2017/08/28 09:05:44 sysdate+5/1440                0 dbms_refresh.refresh('"MVIEW_SCHEMA1"."MV_MASTER"');

前述の状態（5分間隔の高速リフレッシュが動作中の状態）で、次の高速リフレッシュが実行されるまでの間にマテリアライズドビュー関連オブジェクトを含むschemaを丸ごとエクスポートします（他のデータベースへ複製するために）
エラーを再現するData Pump Export、Importと高速リフレッシュ間隔との間合いは下図の通り

上図の通りの流れでData Pump ExportからImportまでを行い、ORA-12034の発生状況を確認

Connected to: Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production
With the Partitioning, OLAP, Advanced Analytics and Real Application Testing options
Starting "SYSTEM"."SYS_EXPORT_SCHEMA_01":  system/********@orcl directory=workdir dumpfile=mview_schema1.dmp logfile=exp_mview_schema1.log schemas=mview_schema1 
Estimate in progress using BLOCKS method...
Processing object type SCHEMA_EXPORT/TABLE/TABLE_DATA
Total estimation using BLOCKS method: 64 KB
Processing object type SCHEMA_EXPORT/USER
Processing object type SCHEMA_EXPORT/SYSTEM_GRANT
Processing object type SCHEMA_EXPORT/DEFAULT_ROLE
Processing object type SCHEMA_EXPORT/TABLESPACE_QUOTA
Processing object type SCHEMA_EXPORT/PRE_SCHEMA/PROCACT_SCHEMA
Processing object type SCHEMA_EXPORT/DB_LINK
Processing object type SCHEMA_EXPORT/TABLE/TABLE
Processing object type SCHEMA_EXPORT/TABLE/COMMENT
Processing object type SCHEMA_EXPORT/TABLE/CONSTRAINT/CONSTRAINT
Processing object type SCHEMA_EXPORT/TABLE/INDEX/STATISTICS/INDEX_STATISTICS
Processing object type SCHEMA_EXPORT/TABLE/STATISTICS/TABLE_STATISTICS
Processing object type SCHEMA_EXPORT/STATISTICS/MARKER
Processing object type SCHEMA_EXPORT/MATERIALIZED_VIEW
Processing object type SCHEMA_EXPORT/JOB
Processing object type SCHEMA_EXPORT/REFRESH_GROUP
. . exported "MVIEW_SCHEMA1"."MV_MASTER"                   5.5 KB       2 rows
Master table "SYSTEM"."SYS_EXPORT_SCHEMA_01" successfully loaded/unloaded
******************************************************************************
Dump file set for SYSTEM.SYS_EXPORT_SCHEMA_01 is:
  /u01/userhome/oracle/mview_schema1.dmp
Job "SYSTEM"."SYS_EXPORT_SCHEMA_01" successfully completed at Mon Aug 28 09:02:48 2017 elapsed 0 00:00:54

念のためマスターサイトでMLOGの件数を確認しておきます。
マテビューサイトと同期する必要のあるデータはないことが確認できます。

orcl@MASTER_SCHEMA> select count(*) from mlog$_master;

  COUNT(*)
----------
         0

という確認を行なっている間いに高速リフレッシュが実行されました！（LAST_DATE列、NEXT_DATE列、FAILURES列から正常にリフレッシュされたことを確認できます）

orcl@MVIEW_SCHEMA1> select job,log_user,schema_user,last_date,next_date,interval,failures,what from user_jobs;
       JOB LOG_USER             SCHEMA_USER          LAST_DATE           NEXT_DATE           INTERVAL               FAILURES WHAT
---------- -------------------- -------------------- ------------------- ------------------- -------------------- ---------- ------------------------------------------------------------
        81 MVIEW_SCHEMA1        MVIEW_SCHEMA1        2017/08/28 09:05:48 2017/08/28 09:10:48 sysdate+5/1440                0 dbms_refresh.refresh('"MVIEW_SCHEMA1"."MV_MASTER"');

まず、異なるPDBにディレクトリオブジェクトを作成して、schemaごとインポートします。
この時点で以前のエントリにもあるようにORCL:master_schema.masterをマスターサイトするmviewが、ORCL:mview_schema1.mview_masterとORCL2:mview_schema1.mview_masterという構成になります。

orcl2@SYSTEM> create directory workdir as '/u01/userhome/oracle';

Directory created.


Starting "SYSTEM"."SYS_IMPORT_FULL_01":  system/********@orcl2 directory=workdir dumpfile=mview_schema1.dmp logfile=imp_mview_schema1.dmp 
Processing object type SCHEMA_EXPORT/USER
Processing object type SCHEMA_EXPORT/SYSTEM_GRANT
Processing object type SCHEMA_EXPORT/DEFAULT_ROLE
Processing object type SCHEMA_EXPORT/TABLESPACE_QUOTA
Processing object type SCHEMA_EXPORT/PRE_SCHEMA/PROCACT_SCHEMA
Processing object type SCHEMA_EXPORT/DB_LINK
Processing object type SCHEMA_EXPORT/TABLE/TABLE
Processing object type SCHEMA_EXPORT/TABLE/TABLE_DATA
. . imported "MVIEW_SCHEMA1"."MV_MASTER"                   5.5 KB       2 rows
Processing object type SCHEMA_EXPORT/TABLE/COMMENT
Processing object type SCHEMA_EXPORT/TABLE/CONSTRAINT/CONSTRAINT
Processing object type SCHEMA_EXPORT/TABLE/INDEX/STATISTICS/INDEX_STATISTICS
Processing object type SCHEMA_EXPORT/TABLE/STATISTICS/TABLE_STATISTICS
Processing object type SCHEMA_EXPORT/STATISTICS/MARKER
Processing object type SCHEMA_EXPORT/MATERIALIZED_VIEW
Processing object type SCHEMA_EXPORT/JOB
Processing object type SCHEMA_EXPORT/REFRESH_GROUP
Job "SYSTEM"."SYS_IMPORT_FULL_01" successfully completed at Mon Aug 28 10:02:09 2017 elapsed 0 00:00:22

インポートが無事終わったので、高速リフレッシュの状態を確認！！

おおおおおおおお〜〜、インポートしたschemaに含まれるMVIEWは高速リフレッシュに失敗しています。
なんということでしょうw（狙い通りなので、わざとらしいですねw）

なお、LAST_REF列がCOMPLETEという完全リフレッシュを示すステータスになっていますが、これはで確認下通り、昔からこんな動作だった曖昧な記憶があるので仕様だと思われますが、
インポート時に完全リフレッシュしているわけでもないのに、完全リフレッシュ扱いとされている紛らわしい状態になります。（このステータスが影響している可能性もありそうな...）

orcl2@MVIEW_SCHEMA1> @mview_info_c
Connected.

Session altered.

ROWNER               RNAME                  REFGROUP        JOB B INTERVAL             NEXT_DATE               CON_ID
-------------------- -------------------- ---------- ---------- - -------------------- ------------------- ----------
MVIEW_SCHEMA1        MV_MASTER                    61         81 N sysdate+5/1440       2017/08/28 10:06:46          3
MVIEW_SCHEMA1        MV_MASTER                    61         81 N sysdate+5/1440       2017/08/28 10:04:22          5


MVIEW_NAME                     REFRES REFRESH_ LAST_REF AFTER_FAST_REFRESH  COMPILE_STATE
------------------------------ ------ -------- -------- ------------------- -------------------
MV_MASTER                      DEMAND FAST     FAST     UNDEFINED           VALID
MV_MASTER                      DEMAND FAST     COMPLETE UNDEFINED           VALID


       JOB LOG_USER             SCHEMA_USER          LAST_DATE           NEXT_DATE           INTERVAL               FAILURES WHAT
---------- -------------------- -------------------- ------------------- ------------------- -------------------- ---------- ------------------------------------------------------------
        81 MVIEW_SCHEMA1        MVIEW_SCHEMA1        2017/08/28 10:01:46 2017/08/28 10:06:46 sysdate+5/1440                0 dbms_refresh.refresh('"MVIEW_SCHEMA1"."MV_MASTER"');
        81 MVIEW_SCHEMA1        MVIEW_SCHEMA1                            2017/08/28 10:04:22 sysdate+5/1440                1 dbms_refresh.refresh('"MVIEW_SCHEMA1"."MV_MASTER"');

高速リフレッシュのが実行され２度目の失敗、failusers列が２になっています。いずれ高速リフレッシュジョブは自動的に停止されます。
（自動停止される前に問題に対処すればそのまま継続されます）

orcl2@MVIEW_SCHEMA1> @mview_info_c
Connected.

Session altered.

ROWNER               RNAME                  REFGROUP        JOB B INTERVAL             NEXT_DATE               CON_ID
-------------------- -------------------- ---------- ---------- - -------------------- ------------------- ----------
MVIEW_SCHEMA1        MV_MASTER                    61         81 N sysdate+5/1440       2017/08/28 10:08:26          5
MVIEW_SCHEMA1        MV_MASTER                    61         81 N sysdate+5/1440       2017/08/28 10:06:46          3


MVIEW_NAME                     REFRES REFRESH_ LAST_REF AFTER_FAST_REFRESH  COMPILE_STATE
------------------------------ ------ -------- -------- ------------------- -------------------
MV_MASTER                      DEMAND FAST     FAST     UNDEFINED           VALID
MV_MASTER                      DEMAND FAST     COMPLETE UNDEFINED           VALID


       JOB LOG_USER             SCHEMA_USER          LAST_DATE           NEXT_DATE           INTERVAL               FAILURES WHAT
---------- -------------------- -------------------- ------------------- ------------------- -------------------- ---------- ------------------------------------------------------------
        81 MVIEW_SCHEMA1        MVIEW_SCHEMA1        2017/08/28 10:01:46 2017/08/28 10:06:46 sysdate+5/1440                0 dbms_refresh.refresh('"MVIEW_SCHEMA1"."MV_MASTER"');
        81 MVIEW_SCHEMA1        MVIEW_SCHEMA1                            2017/08/28 10:08:26 sysdate+5/1440                2 dbms_refresh.refresh('"MVIEW_SCHEMA1"."MV_MASTER"');

では、原因を調査してみましょう！

P列（POSSIBLE列）の　REFRESH_FAST行がNになっていて高速リフレッシュできない状態になっています。
コメントにはmv log is newer than last full refresh 記載されています。　このメッセージ冒頭で書いたメッセージと微妙に違うのですが、

orcl2@MVIEW_SCHEMA1> @?/rdbms/admin/utlxmv

Table created.

orcl2@MVIEW_SCHEMA1> exec dbms_mview.explain_mview('MV_MASTER','TEST01');

PL/SQL procedure successfully completed.

orcl2@MVIEW_SCHEMA1> SELECT mvname,capability_name,related_text,related_num,msgno,possible,msgtxt,seq FROM mv_capabilities_table;

MVNAME                         CAPABILITY_NAME                RELATED_TEXT         RELATED_NUM      MSGNO P MSGTXT                                                                                            SEQ
------------------------------ ------------------------------ -------------------- ----------- ---------- - ------------------------------------------------------------------------------------------ ----------
MV_MASTER                      PCT                                                                        N                                                                                                     1
MV_MASTER                      REFRESH_COMPLETE                                                           Y                                                                                                  1002
MV_MASTER                      REFRESH_FAST                                                               N                                                                                                  2003
MV_MASTER                      REWRITE                                                                    N                                                                                                  3004
MV_MASTER                      PCT_TABLE                      MASTER                        52       2068 N relation is not a partitioned table                                                              4005
MV_MASTER                      REFRESH_FAST_AFTER_INSERT      MASTER_SCHEMA.MASTER                   2077 N mv log is newer than last full refresh                           5006
MV_MASTER                      REFRESH_FAST_AFTER_ONETAB_DML                                         2146 N see the reason why REFRESH_FAST_AFTER_INSERT is disabled                                         6007
MV_MASTER                      REFRESH_FAST_AFTER_ANY_DML                                            2161 N see the reason why REFRESH_FAST_AFTER_ONETAB_DML is disabled                                     7008
MV_MASTER                      REFRESH_FAST_PCT                                                      2197 N PCT FAST REFRESH is not possible if query contains a remote table                                8009
MV_MASTER                      REWRITE_FULL_TEXT_MATCH        MASTER                        52       2099 N mv references a remote table or view in the FROM list                                            9010
MV_MASTER                      REWRITE_FULL_TEXT_MATCH                                               2159 N query rewrite is disabled on the materialized view                                               9011
MV_MASTER                      REWRITE_PARTIAL_TEXT_MATCH                                            2159 N query rewrite is disabled on the materialized view                                              10012
MV_MASTER                      REWRITE_GENERAL                                                       2159 N query rewrite is disabled on the materialized view                                              11013
MV_MASTER                      REWRITE_PCT                                                           2158 N general rewrite is not possible or PCT is not possible on any of the detail tables              12014
MV_MASTER                      PCT_TABLE_REWRITE              MASTER                        52       2068 N relation is not a partitioned table                                                             13015

15 rows selected.

試しに手動で高速リフレッシュさせてみます。

orcl2@MVIEW_SCHEMA1> exec dbms_refresh.refresh('"MVIEW_SCHEMA1"."MV_MASTER"');
BEGIN dbms_refresh.refresh('"MVIEW_SCHEMA1"."MV_MASTER"'); END;

*
ERROR at line 1:
ORA-12034: materialized view log on "MASTER_SCHEMA"."MASTER" younger than last refresh
ORA-06512: at "SYS.DBMS_SNAPSHOT", line 2821
ORA-06512: at "SYS.DBMS_SNAPSHOT", line 3058
ORA-06512: at "SYS.DBMS_IREFRESH", line 687
ORA-06512: at "SYS.DBMS_REFRESH", line 195
ORA-06512: at line 1

冒頭で説明した高速リフレッシュ時のエラーが発生していることがわかります。
そして、.......
このエラーが発生してしまうと、完全リフレッシュで回復させるしかありません！！！！！　

参考：
新規マテリアライズド・ビュー・サイトでの高速リフレッシュ・エラー

"新規マテリアライズド・ビュー・サイトでマテリアライズド・ビュー作成中に、マスター表またはマスター・マテリアライズド・ビューのマテリアライズド・ビュー・ログがパージされる場合があります。これが発生すると、次のエラーが検出される場合があります。

ORA-12004 REFRESH FAST cannot be used for materialized view materialized_view_name
ORA-12034 materialized view log on materialized_view_name younger than last refresh"

回避策として使えそうな方法は....
高速リフレッシュを停止して行う方法もあります（止められないシステムもあるので大人の事情しだいでしょうけど）
デプロイメントテンプレートで対応できそうな要件か十分検討、検証した上でやる必要があると思います。（完全リフレッシュするマテビューが巨大すぎて完全リフレッシュだけで作業時間オーバーなんてこともありえますから）

マニュアルに記載されている回避方法ってのもあるけど、手順がめんどくさい＞＜　な。　可能なら止めちゃった方が楽そうだが、大人の事情が絡んでるとそうもいかないだろうし、結局めんどくさいw
めんどくさいの嫌いなので試したこともないんだけど、時間があったら回避できるか試してみるか....な。

新規マテリアライズド・ビュー・サイトを追加するときの問題の回避

次回は、高速リフレッシュを跨がないように、したら回避できるよね。と言うお話へつづく
リフレッシュの間に終わらないとNGだけどw　、高速リフレッシュの間にexport/importが終わればこの問題は発生しない。。わけで。
次回のネタのイメージ（リフレッシュをまた跨らなければ例のエラーは発生しないという確認:）

Data Pumpも癖モノだよね〜w　その１ - queryパラメーターの解析タイミング

Data Pumpも癖モノだよね〜w　その２ - Materialized ViewをTableとして移行する

Data Pumpも癖モノだよね〜w　その3 - dbms_job と dbms_scheduler との複雑な関係

Data Pumpも癖モノだよね〜w　その4 - schemaモードでMviewを他のPDBへ複製

Data Pumpも癖モノだよね〜w　その4と1/2 - schemaモードでMviewを他のPDBへ複製 (紛らわしいステータスw）

Data Pumpも癖モノだよね〜w　その5 - schemaモードでMviewを他のPDBへ複製（オプジェクトパス de 絞り込み）

Data Pumpも癖モノだよね〜w　その6 - schemaモードでMviewを他のPDBへ複製（オプジェクトパスが不足すると...）

投稿日時 2017年8月31日 (木) 13時20分 FAQ, Oracle Database 11g, Oracle Database 11g Release 2, Oracle Database 12c release 1, Oracle Database 12c Release 2 | 固定リンク | 0 | コメント (0) | トラックバック (0)

2017年5月 2日 (火)

あまりにもネタになってないので、少しだけ　sysresv　のことを書いといた

共有メモリやセマフォセットの数などの確認は、ipcsでほぼ足りてるわけですが。（複数インスタンスが起動している場合を除く）
あまりにもネタになってないので、少しだけ　sysresvのことを書いといた:)

[oracle@vbgeneric ˜]$ sysresv

IPC Resources for ORACLE_SID "orcl12c" :
Maximum shared memory segment size (shmmax): 4398046511104 bytes
Total system shared memory (shmall): 4398046511104 bytes
Total system shared memory count (shmmni): 4096
*********************** Dumping ipcs output ********************

------ Message Queues --------
key        msqid      owner      perms      used-bytes   messages    

------ Shared Memory Segments --------
key        shmid      owner      perms      bytes      nattch     status      
0x00000000 0          oracle     600        8802304    173                     
0x00000000 32769      oracle     600        822083584  87                      
0x00000000 65538      oracle     600        7974912    87                      
0x21485470 98307      oracle     600        16384      87                      
0x00000000 262148     oracle     600        524288     2          dest         
0x00000000 294917     oracle     600        4194304    2          dest         
0x00000000 393222     oracle     600        33554432   2          dest         
0x00000000 491527     oracle     600        4194304    2          dest         
0x00000000 524296     oracle     600        1048576    2          dest         

------ Semaphore Arrays --------
key        semid      owner      perms      nsems     
0x245b195c 163840     oracle     600        152       
0x245b195d 196609     oracle     600        152       
0x245b195e 229378     oracle     600        152       

*********************** End of ipcs command dump **************


***************** Dumping Resource Limits(s/h) *****************
core file size                         0 KB/UNLIMITED         
data seg size                     UNLIMITED/UNLIMITED         
scheduling priority                    0 KB/0 KB              
file size                         UNLIMITED/UNLIMITED         
pending signals                       30 KB/30 KB             
max locked memory                    128 GB/128 GB            
max memory size                   UNLIMITED/UNLIMITED         
open files                            64 KB/64 KB             
POSIX message queues                 800 KB/800 KB            
real-time priority                     0 KB/0 KB              
stack size                            32 MB/32 MB             
cpu time                          UNLIMITED/UNLIMITED         
max user processes                    16 KB/16 KB             
virtual memory                    UNLIMITED/UNLIMITED         
file locks                        UNLIMITED/UNLIMITED         

***************** End of Resource Limits Dump ******************
Maximum map count configured per process:  65530
Total /dev/shm size: 4050014208 bytes, used: 98304 bytes
Shared Memory:
ID		KEY
32769   	0x00000000
65538   	0x00000000
0       	0x00000000
98307   	0x21485470
Semaphores:
ID		KEY
163840  	0x245b195c
196609  	0x245b195d
229378  	0x245b195e
Oracle Instance alive for sid "orcl12c"
[oracle@vbgeneric ˜]$

[oracle@vbgeneric ˜]$  ipcs -sb

------ Semaphore Arrays --------
key        semid      owner      perms      nsems     
0x245b195c 163840     oracle     600        152       
0x245b195d 196609     oracle     600        152       
0x245b195e 229378     oracle     600        152

[oracle@vbgeneric ˜]$  ipcs -st

------ Semaphore Operation/Change Times --------
semid    owner      last-op                    last-changed              
163840   oracle      Tue May  2 01:35:32 2017   Tue May  2 01:26:30 2017  
196609   oracle      Not set                    Tue May  2 01:26:30 2017  
229378   oracle      Tue May  2 01:26:35 2017   Tue May  2 01:26:30 2017

投稿日時 2017年5月 2日 (火) 15時00分 Oracle, FAQ, Oracle Database 11g, Oracle Database 11g Release 2, Oracle Database 12c release 1, Oracle Database 12c Release 2 | 固定リンク | 0 | コメント (0) | トラックバック (0)

2014年8月19日 (火)

pivotとSQL*PlusとSETコマンドと #2

昨日の続きですw

v$sys_time_modelの列データを行データへpivotで変換し、かつシェルで定期的に取得してみたものの、出力形式は今ひとつ。　iostatやvmstatのように出力したい。

前回のエントリーの出力結果は以下の通りでした。

[oracle ˜]$ ./sample.sh

SQL*Plus: Release 12.1.0.2.0 Production on 日 8月 17 21:10:47 2014

Copyright (c) 1982, 2014, Oracle.  All rights reserved.


Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production
With the Partitioning, OLAP, Advanced Analytics and Real Application Testing options
に接続されました。
21:10:48 SCOTT> 
                        DB_TIME                          DB_CPU                         BG_TIME                          BG_CPU
------------------------------- ------------------------------- ------------------------------- -------------------------------
                       66172667                         7714783                       127809578                        27114874

経過: 00:00:00.02
21:10:48 SCOTT>
                        DB_TIME                          DB_CPU                         BG_TIME                          BG_CPU
------------------------------- ------------------------------- ------------------------------- -------------------------------
                       66179178                         7720782                       128085853                        27160868

経過: 00:00:00.01
21:10:57 SCOTT>
                        DB_TIME                          DB_CPU                         BG_TIME                          BG_CPU
------------------------------- ------------------------------- ------------------------------- -------------------------------
                       66180864                         7723782                       128249102                        27197862

経過: 00:00:00.00

じゃまな出力は、以下の通り

SQL*Plusのプロンプト
ヘッダー行
経過時間
出力の状態から見て、余分な改行

そして、不足している出力はメトリックのログ取得時のタイムスタンプ

以下のSQL*Plusシステム変数を調整追加すればなんとかなりそうな感じ。。。。

SQL*Plusのプロンプトは、　set sqlp ""　で抑止。
ヘッダー行は、 set head off で抑止
経過時間は、　set timi off で抑止
余分な改行は、たぶん、　set newp none で抑止
直接関係ないけど、Excelにコピペするときにじゃまになるので set tab offでタブの混入抑止

不足しているログ取得時のタイムスタンプは、シェルのdateコマンドで取得した日時をSQL文に埋め込むことでなんとかなりそうな気がします。

と頭に浮かんだら忘れないうちに試してみますよ〜

★横に長くてごめんなさい。時間取れたらSyntaxHighlighterとか入れます詐欺 m(_ _)m

#!/bin/bash
#
(
echo "conn scott/tiger"
echo "set timi off time off tab off sqlp \"\" head off newp none"
echo "col db_time for 999999999999999999999999999999"
echo "col db_cpu for 999999999999999999999999999999"
echo "col bg_time for 999999999999999999999999999999"
echo "col bg_cpu for 999999999999999999999999999999"
while [ 1 ] 
do
        echo "SELECT db_time,db_cpu,bg_time,bg_cpu FROM (SELECT stat_name,value FROM v\$sys_time_model) PIVOT (MAX(value) FOR stat_name IN ('DB time' AS db_time,'DB CPU' AS db_cpu,'background elapsed time' AS bg_time,'background cpu time' AS bg_cpu));"
        sleep 10
done
) | sqlplus /nolog

ん〜〜〜〜〜、なんか、惜しい！！！！　　いい感じにななったのに。... しばし考える。。。。

[oracle ˜]$ ./sample.sh

SQL*Plus: Release 12.1.0.2.0 Production on 日 8月 17 21:45:43 2014

Copyright (c) 1982, 2014, Oracle.  All rights reserved.

21:45:43 > 接続されました。
21:45:44 SCOTT>                        67126005                         8476651                       182158980                        37408311

                       67129138                         8479651                       182310474                        37445305

きた〜〜〜、神が降りてきたのでちょっと書き換えた

#!/bin/bash
#
(
echo "conn scott/tiger"
echo "set timi off time off sqlp \"\""
echo "col db_time for 999999999999999999999999999999"
echo "col db_cpu for 999999999999999999999999999999"
echo "col bg_time for 999999999999999999999999999999"
echo "col bg_cpu for 999999999999999999999999999999"
while [ 1 ] 
do
	t=`date +'%DT%T'`
        echo "SELECT SUBSTR('${t}',1,INSTR('${t}','T')-1) as logged_date,SUBSTR('${t}',INSTR('${t}','T')+1) as logged_time,db_time,db_cpu,bg_time,bg_cpu FROM (SELECT stat_name,value FROM v\$sys_time_model) PIVOT (MAX(value) FOR stat_name IN ('DB time' AS db_time,'DB CPU' AS db_cpu,'background elapsed time' AS bg_time,'background cpu time' AS bg_cpu));"
	echo "set head off newp none"
        sleep 10
done
) | sqlplus /nolog

ん〜〜〜、まだ余計な改行というか空行がある。。。なんだこれ。。。。再び、考え中........ あ、あれだ！　出力行数を返すやつ！

SQL*Plus: Release 12.1.0.2.0 Production on 日 8月 17 21:56:21 2014

Copyright (c) 1982, 2014, Oracle.  All rights reserved.

21:56:21 > 接続されました。
21:56:22 SCOTT> 
LOGGED_D LOGGED_T                         DB_TIME                          DB_CPU                         BG_TIME                          BG_CPU
-------- -------- ------------------------------- ------------------------------- ------------------------------- -------------------------------
08/17/14 21:56:21                        67688748                         8937570                       198751230                        40650823

08/17/14 21:56:31                        67695983                         8945569                       199012673                        40699815

で、できたのがこれ。

#!/bin/bash
#
(
echo "conn scott/tiger"
echo "set timi off time off sqlp \"\" feed off"
echo "col db_time for 999999999999999999999999999999"
echo "col db_cpu for 999999999999999999999999999999"
echo "col bg_time for 999999999999999999999999999999"
echo "col bg_cpu for 999999999999999999999999999999"
while [ 1 ] 
do
	t=`date +'%DT%T'`
        echo "SELECT SUBSTR('${t}',1,INSTR('${t}','T')-1) as logged_date,SUBSTR('${t}',INSTR('${t}','T')+1) as logged_time,db_time,db_cpu,bg_time,bg_cpu FROM (SELECT stat_name,value FROM v\$sys_time_model) PIVOT (MAX(value) FOR stat_name IN ('DB time' AS db_time,'DB CPU' AS db_cpu,'background elapsed time' AS bg_time,'background cpu time' AS bg_cpu));"
	echo "set head off newp none"
        sleep 10
done

) | sqlplus /nolog

出力結果は以下のようになり、 iostatやvmstat風にヘッダー行は一度だけ、その後、定期的に取得されるメトリックが出力されていくイメージに！ :)

[oracle ˜]$ ./sample.sh

SQL*Plus: Release 12.1.0.2.0 Production on 日 8月 17 22:02:59 2014

Copyright (c) 1982, 2014, Oracle.  All rights reserved.

22:02:59 > 接続されました。
22:02:59 SCOTT> 
LOGGED_D LOGGED_T                         DB_TIME                          DB_CPU                         BG_TIME                          BG_CPU
-------- -------- ------------------------------- ------------------------------- ------------------------------- -------------------------------
08/17/14 22:02:59                        68026469                         9252517                       211057107                        42641516
08/17/14 22:03:09                        68034074                         9261515                       211217278                        42686507
08/17/14 22:03:19                        68039874                         9267514                       211414489                        42730501
08/17/14 22:03:29                        68045221                         9272514                       211576132                        42769498
08/17/14 22:03:39                        68051396                         9276513                       211844118                        42862480
^C
Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production
With the Partitioning, OLAP, Advanced Analytics and Real Application Testing optionsとの接続が切断されました。

Enjoy!

・pivotとSQL*PlusとSETコマンドと

投稿日時 2014年8月19日 (火) 06時00分チューニング, SQL, Oracle Database 11g, Oracle Database 12c release 1, パフォーマンス | 固定リンク | 0 | コメント (0) | トラックバック (0)

2014年8月18日 (月)

pivotとSQL*PlusとSETコマンドと

Oracle Databaseの性能試験で以下のようなメトリックを定期取得して、分析やビジュアライズに利用している方も多いと思います。（思ってます。）
でも、ですねぇ。
以下のv$sys_time_model動的パフォーマンスビューも典型例なのですが、列持ちのメトリックが多いので集計にはかなり苦労します。というか、してます。

v$sys_time_model動的パフォーマンスビューの出力例）

SCOTT> SELECT stat_name, value from v$sys_time_model;

STAT_NAME                                                             VALUE
---------------------------------------------------------------- ----------
DB time                                                            64073868
DB CPU                                                              6549986
background elapsed time                                            42988476
background cpu time                                                11080311

・・・以下略・・・

列持ちなんですよね、　列持ち！（しつこいw

行持ちにしたいですよね。　どう料理しましょう。　まさか、手作業ではやってないですよね。

SQL文でやってますよね！　私もそうです。
ちなみに、UNION連打はしてませんからね！（キリっ！

昔はほかに手がなかったのですが、Oracle11gから便利で比較的読みやすい構文がサポートされています。

列持ちを行持ちにするといえば....そうです、あれです。 pivot

ということで、

pivotを使って、v$sys_time_modelを例にオレオレv$sys_time_modelを作り出してみます。
（これができれば、数あるオラクルの動的パフォーマンスビューをもっと好きになれるんじゃないかなぁ。と思います。）

では、早速

v$sys_time_modelの stat_name列の列値が、'DB time'、'DB CPU'、 'background elapsed time'、'background cpu time'の４つのメトリックを列持ちから行持ちに変え、オレオレv$sys_time_model作り出すSQL文です。
ビューは作りませんけど (^^;;;

SELECT 
	db_time
	,db_cpu
	,bg_time
	,bg_cpu 
FROM 
	(
		SELECT 
			stat_name
			,value 
		FROM 
			v$sys_time_model
	) 
PIVOT 
	(
		MAX(value) 
		FOR stat_name IN 
			(
				'DB time' AS db_time
				,'DB CPU' AS db_cpu
				,'background elapsed time' AS bg_time
				,'background cpu time' AS bg_cpu
			)
	)
;

これを実行すると以下のような結果になります。本来４行なのですが、１行にできるんです！便利ですね。 pivot （pivotの逆の操作をする unpivotもあります）

   DB_TIME     DB_CPU    BG_TIME     BG_CPU
---------- ---------- ---------- ----------
  63895360    6364016   32965031    8718671

いい感じになってきました。

しかし、まだ物足りないですよね。　そう！
取得時のタイムスタンプとか、例えば iostat や vmstatのように定期的に取得したくなってきます！！！！

「門外不出のOracle現場ワザ」　第5章　DBアクセスの空白地帯コネクションプーリングを極めるの定期的にSQLを発行するシェルを作成するには？　でも解説されているのでこの方法で取得されている方も多いと思います。:)

ただ、そのまんまだと以下のような出力になってしまいます。 iostatやvmstatの出力をイメージしちゃうと余分な表示が多いわけです。

[oracle ˜]$ ./sample.sh

SQL*Plus: Release 12.1.0.2.0 Production on 日 8月 17 21:10:47 2014

Copyright (c) 1982, 2014, Oracle.  All rights reserved.


Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production
With the Partitioning, OLAP, Advanced Analytics and Real Application Testing options
に接続されました。
21:10:48 SCOTT> 
                        DB_TIME                          DB_CPU                         BG_TIME                          BG_CPU
------------------------------- ------------------------------- ------------------------------- -------------------------------
                       66172667                         7714783                       127809578                        27114874

経過: 00:00:00.02
21:10:48 SCOTT>
                        DB_TIME                          DB_CPU                         BG_TIME                          BG_CPU
------------------------------- ------------------------------- ------------------------------- -------------------------------
                       66179178                         7720782                       128085853                        27160868

経過: 00:00:00.01
21:10:57 SCOTT>
                        DB_TIME                          DB_CPU                         BG_TIME                          BG_CPU
------------------------------- ------------------------------- ------------------------------- -------------------------------
                       66180864                         7723782                       128249102                        27197862

経過: 00:00:00.00

前述の出力は以下のコードで取得したのですが、実はそんなに手を加えなくても vmstatやiostatのような出力形式で、みなさんの大好きなExcelで集計しやすくすることができるんですよ。
どこを変更すればよいか分かった人、手を挙げて〜〜〜〜っ!

注）scottユーザにselect any dictionaryシステム権限付けてます。

#!/bin/bash
#
(
echo "conn scott/tiger"
echo "set timi on time on"
echo "col db_time for 999999999999999999999999999999"
echo "col db_cpu for 999999999999999999999999999999"
echo "col bg_time for 999999999999999999999999999999"
echo "col bg_cpu for 999999999999999999999999999999"
while [ 1 ] 
do
        echo "SELECT db_time,db_cpu,bg_time,bg_cpu FROM (SELECT stat_name,value FROM v\$sys_time_model) PIVOT (MAX(value) FOR stat_name IN ('DB time' AS db_time,'DB CPU' AS db_cpu,'background elapsed time' AS bg_time,'background cpu time' AS bg_cpu));"
        sleep 10
done
) | sqlplus /nolog

つづきは、次のエントリーで :)

投稿日時 2014年8月18日 (月) 06時57分チューニング, SQL, Oracle Database 11g, Oracle Database 12c release 1, パフォーマンス | 固定リンク | 0 | コメント (0) | トラックバック (0)

2014年8月 4日 (月)

Difference of Initialization Parameters between 11g and 12c #2

以前、11gと12cの初期化パラメータ数を比較したエントリーを書いたのですが、12c R1も 12.1.0.1.0と12.1.0.2.0でまたまた大きく変わっているようだったので調べてみた。

Oracle Database 11g R1 11.1.0.6.0
Oracle Database 11g R2 11.2.0.1.0
Oracle Database 12c R1 12.1.0.1.0
上記に加え、先日リリースされた Oracle database 12c R1 12.1.0.2.0　を加え、とりあえずパラメータ数だけを比較しました。　（差分はまた別途 TODO)

今回も隠しパラメータの増加が目立ちます。(@@)

11.1.0.6.0から11.2.0.1.0で302個の隠しパラメータが増加、
11.2.0.1.0から12.1.0.1.0で926個の隠しパラメータが増加、
そして今回、 12.1.0.1.0から12.1.0.2.0で612個の隠しパラメータが増加し、
11g R2と 12c R1の単純な比較では1500個以上の隠しパラメータが増加している。

これらの隠しパラメータの中で、有名人になるパラメータは登場するのかしないのか...
今後のお楽しみは尽きないわけですが。。。それにしてもすごい増加量、ですよね。

・Difference of Initialization Parameters between 11g r1 (11.1.0.6.0) and 12c r1 (12.1.0.1.0) - including hidden params

投稿日時 2014年8月 4日 (月) 06時00分 Oracle Database 11g, Oracle Database 12c release 1 | 固定リンク | 0 | コメント (0) | トラックバック (0)

2014年4月20日 (日)

シーケンス.NEXTVALが使えないからぐるぐる〜〜〜っとしていいですか？　（30歳　エンジニア　男性）

CREATE TABLE 〜　AS SELECT文でシーケンス.NEXTVALって使えないからぐるぐる〜〜〜っとしたループ処理しないといけないですよね〜。

と質問されたのですが、１文で書けますからね！
（SQL文でワンライナーって言いそうになったけど、飲み込んだw)

準備

SCOTT> l
  1  CREATE TABLE table_foobar
  2  (
  3  	id NUMBER PRIMARY KEY
  4  	,data VARCHAR2(10)
  5* )
SCOTT> /

表が作成されました。

SCOTT> l
  1  INSERT INTO table_foobar
  2  	SELECT
  3  		LEVEL
  4  		,'D'||TO_CHAR(LEVEL,'FM099999999')
  5  	FROM
  6  		dual
  7  	CONNECT BY
  8* 		LEVEL <= 100.
SCOTT> /

100行が作成されました。

SCOTT> commit;

コミットが完了しました。

SCOTT> SELECT * FROM table_foobar ORDER BY id;

        ID DATA
---------- ----------
         1 D000000001
         2 D000000002
         3 D000000003
         4 D000000004
         5 D000000005
         6 D000000006
         7 D000000007
         8 D000000008
         9 D000000009
        10 D000000010

　　　...中略...

        90 D000000090
        91 D000000091
        92 D000000092
        93 D000000093
        94 D000000094
        95 D000000095
        96 D000000096
        97 D000000097
        98 D000000098
        99 D000000099
       100 D000000100

100行が選択されました。

前述のデータを複製しtable_foobar_tmp表を作成するとします。
なお、DATA列はそのままで、ID列は、次のシーケンスを利用してID = 1..100の順にシーケンスから採番しなおしたい。
（以下のシーケンスの定義からすると、 ID=1 は、1000、 ID=2は、1001にしたい。）

SCOTT> CREATE SEQUENCE seq_foobar start with 1000 maxvalue 999999999;

順序が作成されました。

１文で書けますよね!

SCOTT> l
  1  CREATE TABLE table_foobar_tmp
  2  AS
  3  	SELECT
  4  		seq_foobar.NEXTVAL AS id
  5  		,t01.data
  6  	FROM
  7  		(
  8  			SELECT
  9  				id
 10  				,data
 11  			FROM
 12  				table_foobar
 13  			ORDER BY
 14  				id
 15* 		) t01
SCOTT> /

表が作成されました。

SCOTT> SELECT * FROM table_foobar_tmp ORDER BY ID;

        ID DATA
---------- ----------
      1000 D000000001
      1001 D000000002
      1002 D000000003
      1003 D000000004
      1004 D000000005
      1005 D000000006
      1006 D000000007
      1007 D000000008
      1008 D000000009
      1009 D000000010
      1010 D000000011

　　　...中略...

      1090 D000000091
      1091 D000000092
      1092 D000000093
      1093 D000000094
      1094 D000000095
      1095 D000000096
      1096 D000000097
      1097 D000000098
      1098 D000000099
      1099 D000000100

100行が選択されました。

はい、できました！

マニュアルには、「NEXTVALへの参照が含まれる単一のSQL文の中では、Oracleは、次の各行につき1回順序を増加させます。」
と記載されているので、質問してきた方は、マニュアルを読んでいないか、マニュアル読んでなくても実際に試していない食わず嫌い状態だったか、
以下のようなシーケンスの制限に遭遇して、できないんだ！と思い込んでしまった。

病は気からという状態だったのでしょうね。:)

SCOTT> l
  1  CREATE TABLE table_foobar_tmp_NG
  2  AS
  3      SELECT
  4          seq_foobar.NEXTVAL AS ID
  5          ,t01.data
  6      FROM
  7      	table_foobar t01
  8      ORDER BY
  9*     	t01.id
SCOTT> /
        seq_foobar.NEXTVAL AS ID
                   *
行4でエラーが発生しました。:
ORA-02287: ここでは順序番号は使用できません。

エラーメッセージを見ても、Action がRemove the sequence numberだけですからね....

SCOTT> !oerr ORA 2287
02287, 00000, "sequence number not allowed here"
// *Cause: The specified sequence number (CURRVAL or NEXTVAL) is inappropriate
//	  here in the statement.
// *Action: Remove the sequence number.

そんな時はマニュアルを..
Oracle® Database SQL言語リファレンス 11gリリース2 (11.2) 順序疑似列

順序値の使用方法には、CREATE TABLE ... AS SELECTで使用できると書いてるのに。なんでだろう？
と,、なるかもしれないですが、よ〜〜〜くマニュアルを読んでくださいよ〜っ。

順序値の制限事項にGROUP BY句やORDER BY句を持つSELECT文では使用できないとも書かれているところにちゅうも〜〜〜〜く！

ORDER BY句を含んでいるのでORA-02287回避のために、サブクエリにして別クエリブロック化、シーケンスを利用しているクエリブロックにはORDER BY句を含まないようにしているところがポイント :)

テストデータ作るときとか、知ってると便利ですよ〜と。

SCOTT> l
  1  CREATE TABLE table_foobar_tmp
  2  AS
  3  	SELECT
  4  		seq_foobar.NEXTVAL AS id
  5  		,t01.data
  6  	FROM
  7  		(
  8  			SELECT
  9  				id
 10  				,data
 11  			FROM
 12  				table_foobar
 13  			ORDER BY
 14  				id
 15* 		) t01
SCOTT> /

Enjoy SQL!

投稿日時 2014年4月20日 (日) 12時50分 Oracle, FAQ, Oracle Database 11g, Oracle Database 12c release 1 | 固定リンク | 0 | コメント (0) | トラックバック (0)

2014年1月 6日 (月)

SELECT ~ FOR UPDATE SKIP LOCKED　その4 - もしもITL不足だったら...

skip lockedのつづきです。

ITLエントリー不足時のskip lockedの動きを確認してみるか....

100行が1ブロックに収まるような表を作成しておく...計算上、ITLエントリーは最大で4エントリー程度になるように....したつもり....
（ASSMで、INITRANSはデフォルト、ブロックサイズは8KB、PCTFREEは0%）

SCOTT@pdborcl> r
  1  select
  2      objectid
  3      ,file#
  4      ,block#
  5      ,count(id) as num_of_rows
  6  from
  7  (
  8      select
  9           dbms_rowid.rowid_object(rowid) as objectid
 10          ,dbms_rowid.rowid_relative_fno(rowid) as file#
 11          ,dbms_rowid.rowid_block_number(rowid) as block#
 12          ,id
 13      from
 14          q
 15  )
 16  group by
 17      objectid
 18      ,file#
 19      ,block#
 20  order by
 21      objectid
 22      ,file#
 23*     ,block#

  OBJECTID      FILE#     BLOCK# NUM_OF_ROWS
---------- ---------- ---------- -----------
     93077          9     972461         100

※セッション１ - lockできた

SESSION1@pdborcl> select * from q where id = '0001' for update;

ID
----
TEXT_STRING
----------------------------------------------------------------------
0001
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

※セッション２ - lockできた。この時点で 1 + 1 = 2 のITLエントリは使い切っている。

SESSION2@pdborcl> select * from q where id = '0002' for update;

ID
----
TEXT_STRING
---------------------------------------------------------------------
0002
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

※セッション３ - lockできた。　ITLがブロック内の空きスペースに作れたため :)

SESSION3@pdborcl> select * from q where id = '0003' for update;

ID
----
TEXT_STRING
---------------------------------------------------------------------
0003
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

※セッション４ - 計算上のITLエントリー数の上限値. 問題なくlockできた。

SESSION4@pdborcl> select * from q where id = '0004' for update;

ID
----
TEXT_STRING
---------------------------------------------------------------------
0004
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

※セッション５ - 狙い通り！　５つめのITLエントリーを作成するだけの空きがブロック内にない状況なので待機しちゃう :)

SESSION5@pdborcl> select * from q where id = '0005' for update;

待機イベント見れば一目瞭然、ITLエントリー不足で待機してますね！

SYS@pdborcl> select username,event from v$session where username = 'SCOTT'

USERNAME   EVENT
---------- ----------------------------------------
SCOTT      SQL*Net message from client
SCOTT      SQL*Net message from client
SCOTT      enq: TX - allocate ITL entry
SCOTT      SQL*Net message from client
SCOTT      SQL*Net message from client

ここまでは、ITL不足な状況のfor update文ではよく見かける光景ですよね :)

for update skip lockedにすると.....

※セッション１ - locked!

SESSION1@pdborcl> select * from q where id = '0001' for update skip locked;

ID
----
TEXT_STRING
---------------------------------------------------------------------
0001
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

※セッション２ - locked!!

SESSION2@pdborcl> select * from q where id = '0002' for update skip locked;

ID
----
TEXT_STRING
---------------------------------------------------------------------
0002
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

※セッション３　- locked!!!

SESSON3@pdborcl> select * from q where id = '0003' for update skip locked;

ID
----
TEXT_STRING
---------------------------------------------------------------------
0003
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

※セッション４ - locked!!!!

SESSION4@pdborcl> select * from q where id = '0004' for update skip locked;

ID
----
TEXT_STRING
---------------------------------------------------------------------
0004
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

※セッション５（ITLエントリーが確保できず id = '0005'の行をlockすることができないので空振りします。興味深い動きですよね。)

SESSION5@pdborcl> select * from q where id = '0005' for update skip locked;

レコードが選択されませんでした。

次回へつづく.....かもしれない。

・SELECT ~ FOR UPDATE SKIP LOCKED　その１ - @sh2ndさんエントリの復習など
・SELECT ~ FOR UPDATE SKIP LOCKED　その２
・SELECT ~ FOR UPDATE SKIP LOCKED　その３

投稿日時 2014年1月 6日 (月) 23時51分 SQL, Oracle Database 11g, Oracle Database 11g Release 2, Oracle Database 12c release 1 | 固定リンク | 0 | コメント (0) | トラックバック (0)

2014年1月 5日 (日)

SELECT ~ FOR UPDATE SKIP LOCKED　その3

skip lockedのつづきです。

skip lockedの特徴を確認しておきますか！

skip lockedはロックの獲得ができた行だけをロック待機なしで返してくれる :)
IDが'0001', '0002', '0003', '0005'の行をロックしておく。

SESSION1@pdborcl> select id from q where id in ('0001', '0002', '0003', '0005') for update skip locked;

ID
----
0001
0002
0003
0005

IDが '0001','0002','0003'の行は先行のトランザクションで既にロックされているため、ロックできた行だけがロック待機なしで返される。

SESSION2@pdborcl> select id from q where id in ('0001', '0002', '0003', '0004', '0005', '0006') for update skip locked;

ID
----
0004
0006

もちろん、ロックできる行が１行もなければロックを待機せず空振！

SESSION3@pdborcl> select id from q where id in ('0001', '0002', '0003') for update skip locked;

レコードが選択されませんでした。

つづく。

・SELECT ~ FOR UPDATE SKIP LOCKED　その１ - @sh2ndさんエントリの復習など
・SELECT ~ FOR UPDATE SKIP LOCKED　その２

投稿日時 2014年1月 5日 (日) 16時33分 SQL, Oracle Database 11g, Oracle Database 11g Release 2, Oracle Database 12c release 1 | 固定リンク | 0 | コメント (0) | トラックバック (0)

2013年12月31日 (火)

SELECT ~ FOR UPDATE SKIP LOCKED　その２

つづきです。

そういえば、skip lockedって構文がマニュアルでは解説されていないリリースででふつーーーーに、使われててビビったことあったな。
(マニュアルに書かれていないリリースでは、自己責任使ってねw)

・Oracle12c R1 - SKIP LOCKED
http://docs.oracle.com/cd/E49329_01/server.121/b71278/statements_10002.htm#SQLRF55374

・Oracle11g R2 - (skip locked、推奨事項などが追記された）
http://docs.oracle.com/cd/E16338_01/server.112/b56299/statements_10002.htm#i2126016

・Oracle11g R1 - (skip locked登場）
http://otndnld.oracle.co.jp/document/products/oracle11g/111/doc_dvd/server.111/E05750-03/statements_10.htm#7292

・Oracle10g R2 (ここまでのマニュアルにはskip lookedは記載されていない。AQがらみで使われていたのは確かだ....)
http://otndnld.oracle.co.jp/document/products/oracle10g/102/doc_cd/server.102/B19201-02/statements_10.html#6799

どのあたりのバージョンから登場していたのかはJonathan Lewisさんのブログからたどれば分かると思うよ...
http://jonathanlewis.wordpress.com/2010/05/31/skip-locked/

Oracle11g R2のドキュメントからは以下のような追記されている。

「この機能は、Oracle Streams Advanced Queuingなどのマルチコンシューマ・キュー環境で使用するために設計されています。
　キュー・コンシューマは、他のコンシューマによってロックされた行はスキップして未ロックの行を取得できるので、
　他のコンシューマの操作が終了するまで待つ必要はなくなります。
　SKIP LOCKED機能を直接使用するかわりに、Oracle Streams Advanced Queuing APIを使用することをお薦めします。」

と。

以下のリリースで確認したが skip lockedに関して動作の差は無いようだ。
2013/1/5追記
動作の差は無いようだ、とは書いたが、結果オーライってことでございます。内部動作までは見えないので（キリつ
・Oracle11g R1 11.1.0.7.0
・Oracle11g R2 11.2.0.1.0
・Oracle11g R2 11.2.0.2.0
・Oracle12c R1 12.1.0.1.0

※セッション１
SESSION1> select * from q order by id;

	ID DATA
---------- ----------
	 1 a
	 2 b
	 3 c

※セッション１
SESSION1>  SELECT id, data FROM q WHERE id = (SELECT MIN(id) FROM q) FOR UPDATE SKIP LOCKED;

	ID DATA
---------- ----------
	 1 a

			※セッション２
			SKIP LOCKEDなのでしようとしていたレコードがロックできなければ空振りし、ロック獲得を待機しません
			SESSION2>  SELECT id, data FROM q WHERE id = (SELECT MIN(id) FROM q) FOR UPDATE SKIP LOCKED;

			レコードが選択されませんでした。


※セッション１
SESSION1> DELETE FROM q WHERE id = 1;

1行が削除されました。

			※セッション２
			何度やっても同じですよね :)
			SESSION2>  SELECT id, data FROM q WHERE id = (SELECT MIN(id) FROM q) FOR UPDATE SKIP LOCKED;

			レコードが選択されませんでした。


※セッション１
SESSION1> COMMIT;

コミットが完了しました。

SESSION1> 

			※セッション２
			ここで初めて、対象レコードがロックできます！
			マルチコンシューマ・キュー環境向けって意味がよ〜〜〜〜く分かる動きだと思います
			SESSION2>  SELECT id, data FROM q WHERE id = (SELECT MIN(id) FROM q) FOR UPDATE SKIP LOCKED;

				ID DATA
			---------- ----------
				 2 b

skip lockedって面白いよね。

skip lockedの特徴について、もう少し書く予定、多分、来年へつづく。。。。。

みなさま、良いお年を！

・SELECT ~ FOR UPDATE SKIP LOCKED　その１ - @sh2ndさんエントリの復習など

投稿日時 2013年12月31日 (火) 18時24分 SQL, Oracle Database 11g, Oracle Database 11g Release 2, Oracle Database 12c release 1 | 固定リンク | 0 | コメント (0) | トラックバック (0)

SELECT ~ FOR UPDATE SKIP LOCKED　その１ - @sh2ndさんのエントリの復習など

JPOUT Advent Calender 2013の@sh2ndさんのエントリーが面白かったので大晦日に酒飲みながら... :)
まずは twitterでのやり取りなど....

20131231_113305

20131231_163205

イケテナイとか、良いとか、自由に言えるのはユーザーだからこそだと思うんだ。
セールストークじゃない生の情報って大切だ。

ということで、skip locked へ行く前に、Oracle11g R1 11.1.0.7.0 および、Oracle12c R1 12.1.0.1.0 で @sh2ndさんのエントリーの復習から :)

※セッション１
SESSION1> select * from q order by id;

        ID DATA
---------- ----------
         1 a
         2 b
         3 c

※セッション１
SESSION1> SELECT id, data FROM q WHERE id = (SELECT MIN(id) FROM q) FOR UPDATE;

        ID DATA
---------- ----------
         1 a

				※セッション２
				SESSION2> SELECT id, data FROM q WHERE id = (SELECT MIN(id) FROM q) FOR UPDATE;
				（ここで待たされる。待つことは正しい動き）

※セッション１
SESSION1> DELETE FROM q WHERE id = 1;

1行が削除されました。

※セッション１
SESSION1> commit;

コミットが完了しました。

SESSION1> 

				※セッション２はここでロックを獲得できる。
						        		ID DATA
				---------- ----------
				         2 b

				SESSION2>

Oracle11g R2 11.2.0.1.0とOracle11g R2 11.2.0.2.0は、Wrong Resultだったんだと思うが...

※セッション１
SESSION1> select * from q order by id;

	ID DATA
---------- ----------
	 1 a
	 2 b
	 3 c

※セッション１
SESSION1> SELECT id, data FROM q WHERE id = (SELECT MIN(id) FROM q) FOR UPDATE;

	ID DATA
---------- ----------
	 1 a

				※セッション２
				SESSION2> SELECT id, data FROM q WHERE id = (SELECT MIN(id) FROM q) FOR UPDATE;
				(ここで待たされる。というところまでは同じ）


※セッション１
SESSION1> DELETE FROM q WHERE id = 1;

1行が削除されました。

※セッション１
SESSION1> COMMIT;

コミットが完了しました。

SESSION1> 

				※セッション２ (注１
				（しか〜〜〜し、なんとレコードが選択されませんでした！！！！！）
				レコードが選択されませんでした。

				SESSION2>

結果
Oracle READ COMMITTED

11.1.0.7.0 ID=2を取得

11.2.0.1.0 空振り

11.2.0.2.0 空振り

12.1.0.1.0 ID=2を取得

注１）
Oracle11g 11.2.0.3.0以降では修正されているとのこと...(私は手持ちのが無かったので未確認...だれか書いてw)

SELECT ~ FOR UPDATE SKIP LOCKEDへつづく...

投稿日時 2013年12月31日 (火) 16時33分 SQL, Oracle Database 11g, Oracle Database 11g Release 2, JPOUG, Oracle Database 12c release 1 | 固定リンク | 0 | コメント (0) | トラックバック (0)

2013年11月17日 (日)

db tech showcase tokyo 2013 - A35 - JPOUG特濃：潮溜まりでジャブジャブ、SQLチューニング

11/13〜15に開催されたdb tech showcase tokyo 2013 の最終日、午後の４枠で特濃JPOUGとてセッションを行いました。

貴重な機会を提供いただいたインサイトテクノロジーの皆様ありがとうございました。
また、お忙しい中、セッションに参加してくださった皆様、ありがとうございました。

A35
15:00-15:45 / 「JPOUG特濃：潮溜まりでジャブジャブ、SQLチューニング」のセッション資料を公開しました。

塩分濃いめの潮溜まりで釣り上げたSQLは治療できるかどうかもわからない病になっていました….
治療できたか、できなかったのか……

曲者すぎる難病もありますが、何かの機会に思い出していただければと思います。

みなさん、楽しい時間をありがとう。

db tech showcase Tokyo 2013 - A35 特濃JPOUG：潮溜まりでジャブジャブ、SQLチューニング from Hiroshi Sekiguchi

投稿日時 2013年11月17日 (日) 00時11分 Oracle, Oracle Database 11g, 勉強会, イベント, JPOUG, Oracle Database 12c release 1, DB Tech Showcase | 固定リンク | 0 | コメント (0) | トラックバック (0)

2012年5月 1日 (火)

オプティマイザをだましちゃお！　（マジック・ザ・ギャザリング風w かも)

ということで、準備から。なにやら索引がいるのか怪しい列にまでBツリー索引を作成しちゃってます ;)

23:34:03 SYS> conn scott/tiger
接続されました。
23:36:01 SCOTT> 
23:36:01 SCOTT> 
23:36:01 SCOTT> create table deluding_tab (id number not null, status number(2) not null, data varchar2(500)) nologging;

表が作成されました。

23:50:47 SCOTT> begin for i in 1..100000 loop insert into deluding_tab values(i,0,lpad(i,500,'*')); end loop; end;
23:55:22   2  /

PL/SQLプロシージャが正常に完了しました。

23:55:27 SCOTT> commit;

コミットが完了しました。

23:55:31 SCOTT> alter table deluding_tab add constraint pk_deluding_tab primary key (id) using index nologging;

表が変更されました。

23:56:07 SCOTT> create index ix_deluding_tab on deluding_tab(status) nologging;

索引が作成されました。

23:58:26 SCOTT> exec dbms_stats.gather_table_stats(ownname=>'SCOTT',tabname=>'DELUDING_TAB', -
23:58:34 > no_invalidate=>false,cascade=>true,method_opt=>'FOR ALL COLUMNS SIZE AUTO');

PL/SQLプロシージャが正常に完了しました。

ヒストグラムの状態も見ておきましょ。

TABLE_NAME                     COLUMN_NAME                    NUM_BUCKETS HISTOGRAM
------------------------------ ------------------------------ ----------- ---------------
DELUDING_TAB                   ID                             1           NONE
DELUDING_TAB                   STATUS                         1           NONE
DELUDING_TAB                   DATA                           1           NONE

登録したデータ件数も見ておきましょうか。

00:03:27 SCOTT> 
00:08:41 SCOTT> select count(1) from deluding_tab;

  COUNT(1)
----------
    100000

では、オプティマイザとデュエル！

アンタップ、アップキープ、ドロー！　

00:03:54 SCOTT> select * from deluding_tab where status = 1;

レコードが選択されませんでした。

経過: 00:00:00.01

実行計画
----------------------------------------------------------
Plan hash value: 1226994206

------------------------------------------------------------------------------------------------
| Id  | Operation                   | Name            | Rows  | Bytes | Cost (%CPU) | Time     |
------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT            |                 |     1 |   508 |     2    (0)| 00:00:01 |
|   1 |  TABLE ACCESS BY INDEX ROWID| DELUDING_TAB    |     1 |   508 |     2    (0)| 00:00:01 |
|*  2 |   INDEX RANGE SCAN          | IX_DELUDING_TAB |     1 |       |     1    (0)| 00:00:01 |
------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   2 - access("STATUS"=1)


統計
----------------------------------------------------------
      1  recursive calls
      0  db block gets
      2  consistent gets
      0  physical reads
      0  redo size
    487  bytes sent via SQL*Net to client
    509  bytes received via SQL*Net from client
      1  SQL*Net roundtrips to/from client
      0  sorts (memory)
      0  sorts (disk)
      0  rows processed

データはヒットしていないですね。索引レンジスキャンは妥当な実行計画:)

お〜〜っと、ここで、インスタント!　全データをヒント無しで、索引レンジスキャン！

ちなみに、遊戯王ばかりで、マジック・ザ・ギャザリングをしらない、最近の子の為に解説しておくと、フラッシュタイミングで使うカードと似たような使い方をするカードのことだぉ

00:07:27 SCOTT> select * from deluding_tab where status = 2;

100000行が選択されました。

経過: 00:00:02.32

実行計画
----------------------------------------------------------
Plan hash value: 1226994206

------------------------------------------------------------------------------------------------
| Id  | Operation                   | Name            | Rows  | Bytes | Cost (%CPU) | Time     |
------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT            |                 |     1 |   508 |     2    (0)| 00:00:01 |
|   1 |  TABLE ACCESS BY INDEX ROWID| DELUDING_TAB    |     1 |   508 |     2    (0)| 00:00:01 |
|*  2 |   INDEX RANGE SCAN          | IX_DELUDING_TAB |     1 |       |     1    (0)| 00:00:01 |
------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   2 - access("STATUS"=2)


統計
----------------------------------------------------------
       1  recursive calls
       0  db block gets
   20166  consistent gets
       0  physical reads
       0  redo size
53229491  bytes sent via SQL*Net to client
   73846  bytes received via SQL*Net from client
    6668  SQL*Net roundtrips to/from client
       0  sorts (memory)
       0  sorts (disk)
  100000  rows processed

ターンエンド。

リテラル値指定、かつ、全件ヒットするからTABLE FULL SCANになるはずなのに、何故、INDEX RANGE SCANしてすげ〜時間かかっているんだ〜〜〜〜というマジックの秘密は次回。

バインド変数使ってなくてもオプティマイザをだませるんだぉ

つづく。

投稿日時 2012年5月 1日 (火) 05時19分チューニング, SQL, Oracle Database 11g | 固定リンク | 0 | コメント (0) | トラックバック (0)

2012年4月28日 (土)

述語のつづきの続き。

前回の続きです。

今回の例も今ひとつといえばそうなのでだけど、述語プッシュで索引が利用されることを期待した書き方なのに残念な結果になっている以下のようなパターン、意外と見かけるんですよー
オプティマイザが進化して今以上に賢くなったら気にしなくても最適化してくれるかもしれないけど………

11:28:59 SCOTT> l   
  1  select
  2     v1.id
  3     ,v1.data
  4  from
  5     (
  6         select
  7             to_char(id) as id
  8             ,data
  9         from
 10             push_pred_test1
 11         union
 12         select
 13            to_char(id) as id
 14            ,data
 15         from
 16            push_pred_test2
 17     ) v1
 18  where
 19*    v1.id = 10
11:30:40 SCOTT> /

11行が選択されました。

経過: 00:00:01.58

実行計画
----------------------------------------------------------
Plan hash value: 2712236156

------------------------------------------------------------------------------------------
| Id  | Operation            | Name            | Rows  | Bytes | Cost (%CPU)  | Time     |
------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT     |                 |    11 |   814 |  4857     (1)| 00:00:59 |
|   1 |  VIEW                |                 |    11 |   814 |  4857     (1)| 00:00:59 |
|   2 |   SORT UNIQUE        |                 |    11 |  1166 |  4857    (91)| 00:00:59 |
|   3 |    UNION-ALL         |                 |       |       |              |          |
|*  4 |     TABLE ACCESS FULL| PUSH_PRED_TEST1 |     1 |   106 |   445     (1)| 00:00:06 |
|*  5 |     TABLE ACCESS FULL| PUSH_PRED_TEST2 |    10 |  1060 |  4410     (1)| 00:00:53 |
------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   4 - filter(TO_NUMBER(TO_CHAR("ID"))=10)
   5 - filter(TO_NUMBER(TO_CHAR("ID"))=10)


統計
----------------------------------------------------------
      0  recursive calls
      0  db block gets
  17554  consistent gets
  15960  physical reads
      0  redo size
   1819  bytes sent via SQL*Net to client
    520  bytes received via SQL*Net from client
      2  SQL*Net roundtrips to/from client
      1  sorts (memory)
      0  sorts (disk)
     11  rows processed

11:30:43 SCOTT>

こんな実行計画を期待して書いたはず (^^)

11:31:49 SCOTT> l
  1  select
  2     to_char(v1.id) as id
  3     ,v1.data
  4  from
  5     (
  6         select
  7             id
  8             ,data
  9         from
 10             push_pred_test1
 11         union
 12         select
 13             id
 14             ,data
 15         from
 16             push_pred_test2
 17     ) v1
 18  where
 19*    v1.id = 10
11:31:50 SCOTT> /

11行が選択されました。

経過: 00:00:00.00

実行計画
----------------------------------------------------------
Plan hash value: 2774814350

--------------------------------------------------------------------------------------------------------
| Id  | Operation                      | Name               | Rows   | Bytes  | Cost (%CPU) | Time     |
--------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT               |                    |     11 |    715 |      8  (25)| 00:00:01 |
|   1 |  VIEW                          |                    |     11 |    715 |      8  (25)| 00:00:01 |
|   2 |   SORT UNIQUE                  |                    |     11 |  1166  |      8  (75)| 00:00:01 |
|   3 |    UNION-ALL                   |                    |        |        |             |          |
|   4 |     TABLE ACCESS BY INDEX ROWID| PUSH_PRED_TEST1    |      1 |    106 |      2   (0)| 00:00:01 |
|*  5 |      INDEX UNIQUE SCAN         | PK_PUSH_PRED_TEST1 |      1 |        |      1   (0)| 00:00:01 |
|   6 |     TABLE ACCESS BY INDEX ROWID| PUSH_PRED_TEST2    |     10 |  1060  |      4   (0)| 00:00:01 |
|*  7 |      INDEX RANGE SCAN          | PK_PUSH_PRED_TEST2 |     10 |        |      3   (0)| 00:00:01 |
--------------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   5 - access("ID"=10)
   7 - access("ID"=10)


統計
----------------------------------------------------------
      0  recursive calls
      0  db block gets
      7  consistent gets
      0  physical reads
      0  redo size
   1819  bytes sent via SQL*Net to client
    520  bytes received via SQL*Net from client
      2  SQL*Net roundtrips to/from client
      1  sorts (memory)
      0  sorts (disk)
     11  rows processed

11:31:51 SCOTT>

ここまでのあらすじ

・述語 ;)
・述語 ;) のつづき

投稿日時 2012年4月28日 (土) 12時10分チューニング, SQL, Oracle Database 11g | 固定リンク | 0 | コメント (0) | トラックバック (0)

2012年4月 8日 (日)

いん！、イン！、Index どっぷり Inde Only Access生活w - Oracle OpenWorld Unconference presented by JPOUG

Oracle OpenWorld Unconference presented by JPOUG
とこかで聞いたようなタイトルを"インデックス"に置換えた「いん！、イン！、Index どっぷり Inde Only Scan生活w」のセッション資料を公開します。
（相変わらず文才ないな〜〜と落ち込む....作文嫌いは死ぬまで治らないと思ってるが、がんばって書くw)

（~~デモ内容とデモ環境情報を追加予定です。~~ 2012/4/15デモとデモ環境情報追加しました）

直前にデモ環境のOracle11gR2が起動しないという想定外のトラブルを乗り越えw かなりイッパイ、イッパイの状態でしたが楽しい時間を過ごさせていただきました。

関係者の皆様、ご来場の皆様、ありがとうございました。

Safari以外のブラウザではアニメーション効果はありませんが、Safari (Mac/iPad/iPhone)ではKeynote風（但し、ページ間のトランジッションなし）に表示されます。

(2012/4/10追加)
セッションで利用したデモ環境の情報を載せておきます。

MacBook Air late 2010 13inch 2GB (MacOS X Lion)
VirtualBox4.1.10 for MacOS X
GuestOS：CentOS5.8 x86　
DB : Oracle11g R2 11.2.0.1.0 EE for Linux x86

VMの設定は以下のようになってます。
仮想ディスクはほかにもいろいろやるので合計で21GBほどにしてあります :)

(2012/4/15)host i/o cacheはオフにしてあります。
Vbox_no_hostio_cache

late2010のMBAはメモリが2GBなので、VMには1GBのメモリを割り当ててます。
~~(オラクルのmemory_targetなどの値も書いたほうがいいのかな〜）~~

(2012/4/15追記）
メモリサイズがギリギリなのでOracleのメモリ関連初期化パラメータも以下の通りで少なめです。

memory_max_target                    big integer 404M
memory_target                        big integer 404M
sga_max_size                         big integer 404M
sga_target                           big integer 0
pga_aggregate_target                 big integer 0

(2012/4/15追記）
・デモで使った表これ。

13:56:52 SCOTT> desc tab1
 名前                        NULL?    型
 ----------------------------- -------- --------------------
 UNIQUE_ID                     NOT NULL NUMBER
 NON_UNIQUE_ID                          NUMBER(10)
 NON_UNIQUE_ID2                         NUMBER(5)
 DATA                                   VARCHAR2(500)
 IS_DELETE                              NUMBER(1)
 STATUS_CODE                            CHAR(2)

13:56:55 SCOTT> desc tab2
 名前                        NULL?    型
 ----------------------------- -------- --------------------
 UNIQUE_ID2                    NOT NULL NUMBER(5)
 DATA                                   VARCHAR2(500)
 IS_DELETE                              NUMBER(1)

こんなデータを登録して...

13:56:58 SCOTT> 
15:01:15 SCOTT> begin for i in 1..100000 loop insert into tab1 values(i,ora_hash(i,999),ora_hash(i,99),lpad(i,500,'*'),0,'00'); end loop; end;
15:01:17 SCOTT> /

PL/SQLプロシージャが正常に完了しました。

経過: 00:00:25.46
15:01:44 SCOTT> commit;

コミットが完了しました。

経過: 00:00:00.01
15:01:59 SCOTT> exec dbms_stats.gather_table_stats(ownname=>'SCOTT',tabname=>'TAB1',no_invalidate=>false,cascade=>true);

PL/SQLプロシージャが正常に完了しました。

経過: 00:00:08.50
15:09:43 SCOTT> begin for i in 1..200 loop insert into tab2 values(i,lpad(i,500,'*'),0); end loop; end;
15:10:12   2  /

PL/SQLプロシージャが正常に完了しました。

経過: 00:00:00.05
15:10:13 SCOTT> commit;

コミットが完了しました。

経過: 00:00:00.08
15:10:16 SCOTT> exec dbms_stats.gather_table_stats(ownname=>'SCOTT',tabname=>'TAB2',no_invalidate=>false,cascade=>true);

PL/SQLプロシージャが正常に完了しました。

経過: 00:00:00.99
15:10:50 SCOTT>

データ件数、データのカーディナリティは以下のようになってます。

15:10:50 SCOTT> @show_tab_info
tabnameに値を入力してください: tab1

SEGMENT_NAME                   SEGMENT_TYPE       SEGMENT_SU         MB   NUM_ROWS DISTINCT_KEYS CLUSTERING_FACTOR VISIBLE
------------------------------ ------------------ ---------- ---------- ---------- ------------- ----------------- -------
TAB1                           TABLE              ASSM               62     100000                                 YES
TAB1_IX1                       INDEX              ASSM                3     100000          1000             99400 YES
TAB1_IX2                       INDEX              ASSM                3     100000           100             94181 YES
TAB1_PK                        INDEX              ASSM                2     100000        100000              7693 YES

経過: 00:00:00.78

TABLE_NAME                     INDEX_NAME                     COLUMN_NAME          DESC DATA_TYPE     NUM_NULLS    DENSITY NUM_DISTINCT HI_VALUE      LO_VALUE      HISTOGRAM
------------------------------ ------------------------------ -------------------- ---- ------------ ---------- ---------- ------------ ------------- ------------- ---------------
TAB1                           TAB1_IX1                       NON_UNIQUE_ID        ASC  NUMBER                0       .001         1000 999           0             NONE

                               TAB1_IX2                       NON_UNIQUE_ID2       ASC  NUMBER                0 5.0182E-06          100 99            0             FREQUENCY

                               TAB1_PK                        UNIQUE_ID            ASC  NUMBER                0     .00001       100000 100000        1             NONE


経過: 00:00:02.51
15:17:47 SCOTT> @show_tab_info
tabnameに値を入力してください: tab2

SEGMENT_NAME                   SEGMENT_TYPE       SEGMENT_SU         MB   NUM_ROWS DISTINCT_KEYS CLUSTERING_FACTOR VISIBLE
------------------------------ ------------------ ---------- ---------- ---------- ------------- ----------------- -------
TAB2                           TABLE              ASSM                1        200                                 YES
TAB2_PK                        INDEX              ASSM                1        200           200                15 YES

経過: 00:00:00.78

TABLE_NAME                     INDEX_NAME                     COLUMN_NAME          DESC DATA_TYPE     NUM_NULLS    DENSITY NUM_DISTINCT HI_VALUE      LO_VALUE      HISTOGRAM
------------------------------ ------------------------------ -------------------- ---- ------------ ---------- ---------- ------------ ------------- ------------- ---------------
TAB2                           TAB2_PK                        UNIQUE_ID2           ASC  NUMBER                0       .005          200 200           1             NONE


経過: 00:00:02.55
15:18:03 SCOTT>

注）毎回buffer cacheをクリア、かつ、ソフトパース時の結果を載せています。

・demo1

通常ならこの実行計画であればなにもしないですよね...

こんな良さげな実行計画でもSQL文と実行計画それに表定義をじ〜〜〜〜〜〜っと見ていると解決策が見えてきますよね。そうindex only accessならね。

14:45:34 SCOTT> 
14:45:34 SCOTT> set autot trace exp stat
14:45:34 SCOTT> @demo1

システムが変更されました。

経過: 00:00:00.03
  1  select
  2       unique_id
  3      ,status_code
  4  from
  5      tab1
  6  where
  7      unique_id between 1 and 1000
  8*     and is_delete = 0

998行が選択されました。

経過: 00:00:00.07

実行計画
----------------------------------------------------------
Plan hash value: 1911646434

---------------------------------------------------------------------------------------
| Id  | Operation                   | Name    | Rows  | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT            |         |   999 | 10989 |    81   (0)| 00:00:01 |
|*  1 |  TABLE ACCESS BY INDEX ROWID| TAB1    |   999 | 10989 |    81   (0)| 00:00:01 |
|*  2 |   INDEX RANGE SCAN          | TAB1_PK |  1000 |       |     4   (0)| 00:00:01 |
---------------------------------------------------------------------------------------

Predicate Information (identified by operation id):                                    
---------------------------------------------------                                    

   1 - filter("IS_DELETE"=0)                                                           
   2 - access("UNIQUE_ID">=1 AND "UNIQUE_ID"<=1000)                                   
 

統計
----------------------------------------------------------                             
          0  recursive calls                                                           
          0  db block gets                                                             
        210  consistent gets                                                           
         80  physical reads                                                            
          0  redo size                                                                 
      19586  bytes sent via SQL*Net to client                                          
       1142  bytes received via SQL*Net from client                                    
         68  SQL*Net roundtrips to/from client                                         
          0  sorts (memory)                                                            
          0  sorts (disk)                                                              
        998  rows processed

is_deleteなんて列を参照するためにだけに行長の長い行を持つ表を、しかも、レンジスキャンしているのでデータアクセス量が多くなっているんですよね。
そこで、index only access

index only accessするための索引を作成してしまえばそれを回避できますよね.

14:45:36 SCOTT> @demo1_ix
create index tab1_ix_demo1 on tab1(unique_id,is_delete,status_code) nologging invisible

索引が作成されました。

経過: 00:00:00.80
alter session set optimizer_use_invisible_indexes=true

セッションが変更されました。

経過: 00:00:00.01

TABLE ACCESSが消えました！
consistent getsは、1/3に減少しましたよね :) 時間も 70msから10ms程度に改善してます。

14:46:05 SCOTT> @demo1

システムが変更されました。

経過: 00:00:00.04
  1  select
  2       unique_id
  3      ,status_code
  4  from
  5      tab1
  6  where
  7      unique_id between 1 and 1000
  8*     and is_delete = 0

998行が選択されました。

経過: 00:00:00.01

実行計画
----------------------------------------------------------                             
Plan hash value: 327556384                                                             

----------------------------------------------------------------------------------     
| Id  | Operation        | Name          | Rows  | Bytes | Cost (%CPU)| Time     |     
----------------------------------------------------------------------------------     
|   0 | SELECT STATEMENT |               |   999 | 10989 |     4   (0)| 00:00:01 |     
|*  1 |  INDEX RANGE SCAN| TAB1_IX_DEMO1 |   999 | 10989 |     4   (0)| 00:00:01 |     
----------------------------------------------------------------------------------     

Predicate Information (identified by operation id):                                    
---------------------------------------------------                                    

   1 - access("UNIQUE_ID">=1 AND "IS_DELETE"=0 AND "UNIQUE_ID"<=1000)                  
       filter("IS_DELETE"=0)                                                           


統計
----------------------------------------------------------                             
          0  recursive calls                                                           
          0  db block gets                                                             
         70  consistent gets                                                           
          4  physical reads                                                            
          0  redo size                                                                 
      19586  bytes sent via SQL*Net to client                                          
       1142  bytes received via SQL*Net from client                                    
         68  SQL*Net roundtrips to/from client                                         
          0  sorts (memory)                                                            
          0  sorts (disk)                                                              
        998  rows processed

次のデモのために作成した索引を削除しておきます。

14:46:13 SCOTT> @drop_demo1_ix
drop index tab1_ix_demo1

索引が削除されました。

経過: 00:00:00.61
alter session set optimizer_use_invisible_indexes=false

セッションが変更されました。

経過: 00:00:00.00

・demo2

demo1同様に行長の長い行をある程度の範囲でレンジスキャンかつ、group/order by句があるのでソート処理が行われています。

これも通常ならチューニングなんてしないのですが、大人の事情で何かできないか？　

と聞かれればindex only accessにして表をアクセスしない＋ソート処理も省略しましょうか！　と返してあげることが多いです。

14:47:05 SCOTT> @demo2

システムが変更されました。

経過: 00:00:00.02
  1  select
  2      non_unique_id2
  3      ,count(1)
  4  from
  5      tab1
  6  where
  7      non_unique_id  = 70
  8      and is_delete = 0
  9  group by
 10      non_unique_id2
 11  order by
 12*     non_unique_id2

経過: 00:00:00.06

実行計画
----------------------------------------------------------                             
Plan hash value: 1524069294                                                            

-----------------------------------------------------------------------------------------    
| Id  | Operation                    | Name     | Rows  | Bytes | Cost (%CPU)| Time     |    
-----------------------------------------------------------------------------------------    
|   0 | SELECT STATEMENT             |          |    63 |   630 |   102   (1)| 00:00:02 |    
|   1 |  SORT GROUP BY               |          |    63 |   630 |   102   (1)| 00:00:02 |    
|*  2 |   TABLE ACCESS BY INDEX ROWID| TAB1     |   100 |  1000 |   101   (0)| 00:00:02 |    
|*  3 |    INDEX RANGE SCAN          | TAB1_IX1 |   100 |       |     1   (0)| 00:00:01 |    
-----------------------------------------------------------------------------------------    

Predicate Information (identified by operation id):                                    
---------------------------------------------------                                    

   2 - filter("IS_DELETE"=0)                                                           
   3 - access("NON_UNIQUE_ID"=70)                                                      


統計
----------------------------------------------------------                             
          0  recursive calls                                                           
          0  db block gets                                                             
        103  consistent gets                                                           
        103  physical reads                                                            
          0  redo size                                                                 
        517  bytes sent via SQL*Net to client                                          
        416  bytes received via SQL*Net from client                                    
          2  SQL*Net roundtrips to/from client                                         
          1  sorts (memory)                                                            
          0  sorts (disk)                                                              
          1  rows processed

index only scanにしてソート処理も省略するための索引を作成します。

ではどのような索引を作成すればよいのでしょう？

実行計画のPredicate Informationセクションにはどのような索引を作成するかを決定するための重要な情報がリストされています。

気づきましたか？

以下の２行が重要。

2 - filter("IS_DELETE"=0)
3 - access("NON_UNIQUE_ID"=70)

NON_UNIQUE_ID列に作成されている索引を利用して行を取得し、IS_DELETE=0 でフィルタ処理を実施していることがわかります。

ということは、　NON_UNIQUE_ID,IS_DELETEの２列（つまりWHERE句に記述されている検索条件）がアクセスパスですよね。

次に、選択リスト/GROUP BY句/ORDER BY句を見ると NON_UNIQUE_ID2毎のCOUNT()を取りNON_UNIQUE_ID2を昇順にソートしていることがわかります。

NON_UNIQUE_ID,IS_DELETE列アクセスして、NON_UNIQUE_ID2が昇順にソート済みとなっている索引があればindex only accessになるはず！

14:47:14 SCOTT> @demo2_ix
create index tab1_ix_demo2 on tab1(non_unique_id,is_delete,non_unique_id2) logging invisible

索引が作成されました。

経過: 00:00:00.63
alter session set optimizer_use_invisible_indexes=true

セッションが変更されました。

経過: 00:00:00.01

結果は...

index range scanのみになり、SORT GROUP BY NOSORTというオペレーションからもわかるように、ソート処理が省略されています。;)

consistent getsは約1/50、処理時間は60msから10msまで改善しました。

14:47:28 SCOTT> @demo2

システムが変更されました。

経過: 00:00:00.03
  1  select
  2      non_unique_id2
  3      ,count(1)
  4  from
  5      tab1
  6  where
  7      non_unique_id  = 70
  8      and is_delete = 0
  9  group by
 10      non_unique_id2
 11  order by
 12*     non_unique_id2

経過: 00:00:00.01

実行計画
----------------------------------------------------------                             
Plan hash value: 2668135026                                                            

-------------------------------------------------------------------------------------- 
| Id  | Operation            | Name          | Rows  | Bytes | Cost (%CPU)| Time     | 
-------------------------------------------------------------------------------------- 
|   0 | SELECT STATEMENT     |               |    63 |   630 |     1   (0)| 00:00:01 | 
|   1 |  SORT GROUP BY NOSORT|               |    63 |   630 |     1   (0)| 00:00:01 | 
|*  2 |   INDEX RANGE SCAN   | TAB1_IX_DEMO2 |   100 |  1000 |     1   (0)| 00:00:01 | 
-------------------------------------------------------------------------------------- 

Predicate Information (identified by operation id):                                    
---------------------------------------------------                                    

   2 - access("NON_UNIQUE_ID"=70 AND "IS_DELETE"=0)                                    


統計
----------------------------------------------------------                             
          0  recursive calls                                                           
          0  db block gets                                                             
          2  consistent gets                                                           
          2  physical reads                                                            
          0  redo size                                                                 
        517  bytes sent via SQL*Net to client                                          
        416  bytes received via SQL*Net from client                                    
          2  SQL*Net roundtrips to/from client                                         
          0  sorts (memory)                                                            
          0  sorts (disk)                                                              
          1  rows processed

作成した索引を削除して次のデモへ。

14:47:33 SCOTT> @drop_demo2_ix
drop index tab1_ix_demo2

索引が削除されました。

経過: 00:00:00.10
alter session set optimizer_use_invisible_indexes=false

セッションが変更されました。

経過: 00:00:00.00

・demo3

これdemo2の応用編です. 行長の長い行をある程度の範囲でレンジ検索し、最小値(min)を取得するものです。最大値(max)でも考え方は同じ。

14:47:49 SCOTT> @demo3

システムが変更されました。

経過: 00:00:00.04
  1  select
  2      min(non_unique_id2)
  3  from
  4      tab1
  5  where
  6      non_unique_id = 70
  7*     and is_delete = 0

経過: 00:00:00.05

実行計画
----------------------------------------------------------                             
Plan hash value: 255634452                                                             

-----------------------------------------------------------------------------------------    
| Id  | Operation                    | Name     | Rows  | Bytes | Cost (%CPU)| Time     |    
-----------------------------------------------------------------------------------------    
|   0 | SELECT STATEMENT             |          |     1 |    10 |   101   (0)| 00:00:02 |    
|   1 |  SORT AGGREGATE              |          |     1 |    10 |            |          |    
|*  2 |   TABLE ACCESS BY INDEX ROWID| TAB1     |   100 |  1000 |   101   (0)| 00:00:02 |    
|*  3 |    INDEX RANGE SCAN          | TAB1_IX1 |   100 |       |     1   (0)| 00:00:01 |    
-----------------------------------------------------------------------------------------    

Predicate Information (identified by operation id):                                    
---------------------------------------------------                                    

   2 - filter("IS_DELETE"=0)                                                           
   3 - access("NON_UNIQUE_ID"=70)                                                      


統計
----------------------------------------------------------                             
          0  recursive calls                                                           
          0  db block gets                                                             
        103  consistent gets                                                           
        103  physical reads                                                            
          0  redo size                                                                 
        456  bytes sent via SQL*Net to client                                          
        416  bytes received via SQL*Net from client                                    
          2  SQL*Net roundtrips to/from client                                         
          0  sorts (memory)                                                            
          0  sorts (disk)                                                              
          1  rows processed

demo2と同様に、WHERE句で参照されている検索条件列がアクセスパスになるような索引に、選択リスト中のmin()関数で参照されている列を追加した索引でindex only accessになりそうですよね。

14:47:51 SCOTT> @demo3_ix
create index tab1_ix_demo3 on tab1(non_unique_id, is_delete, non_unique_id2) nologging invisible

索引が作成されました。

経過: 00:00:00.65
alter session set optimizer_use_invisible_indexes=true

セッションが変更されました。

経過: 00:00:00.00

結果は、狙い通りになりました！

処理時間は40msから10msへ。consistent getsは約1/50に改善しました。

実行計画のINDEX RANGE SCAN (MIN/MAX) 〜 FIRST ROWSという素敵なオペレーションが現れています。

Rowsを見ると索引作成前は 100行選択して1行返すという無駄の多い(99行は捨てている）操作から１行とってきて１行返すというエコな動きをしていることが確認できます！　素敵ですね。

14:48:05 SCOTT> @demo3

システムが変更されました。

経過: 00:00:00.04
  1  select
  2      min(non_unique_id2)
  3  from
  4      tab1
  5  where
  6      non_unique_id = 70
  7*     and is_delete = 0

経過: 00:00:00.01

実行計画
----------------------------------------------------------                             
Plan hash value: 3012701563                                                            

----------------------------------------------------------------------------------------------
| Id  | Operation                    | Name          | Rows  | Bytes | Cost (%CPU)| Time     |
----------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT             |               |     1 |    10 |     2   (0)| 00:00:01 |
|   1 |  SORT AGGREGATE              |               |     1 |    10 |            |          |
|   2 |   FIRST ROW                  |               |     1 |    10 |     2   (0)| 00:00:01 |
|*  3 |    INDEX RANGE SCAN (MIN/MAX)| TAB1_IX_DEMO3 |     1 |    10 |     2   (0)| 00:00:01 |
----------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):                                    
---------------------------------------------------                                    

   3 - access("NON_UNIQUE_ID"=70 AND "IS_DELETE"=0)                                    


統計
----------------------------------------------------------                             
          0  recursive calls                                                           
          0  db block gets                                                             
          2  consistent gets                                                           
          2  physical reads                                                            
          0  redo size                                                                 
        456  bytes sent via SQL*Net to client                                          
        416  bytes received via SQL*Net from client                                    
          2  SQL*Net roundtrips to/from client                                         
          0  sorts (memory)                                                            
          0  sorts (disk)                                                              
          1  rows processed

~~作詞絵~~作成した索引を削除して次のデモへ...

14:48:09 SCOTT> @drop_demo3_ix
drop index tab1_ix_demo3

索引が削除されました。

経過: 00:00:00.09
alter session set optimizer_use_invisible_indexes=false

セッションが変更されました。

経過: 00:00:00.01

・demo4

大人の事情で実行計画だけみてるとチューニングなんて不要でしょ！　という感じのクエリをチューニングできないか？

と依頼されたら・・・

２つの表を結合した結果でgorup/order byしているのでソート処理のバイパスはできせんが、index only accessを使ってNested Loop結合でアクセスされるブロック数を最小化することはできますよね。

14:48:26 SCOTT> @demo4

システムが変更されました。

経過: 00:00:00.12
  1  select
  2      d.non_unique_id
  3     ,m.unique_id2
  4     ,count(1)
  5  from
  6      tab2 m join tab1 d
  7      on m.unique_id2 = d.non_unique_id2
  8         and m.is_delete = 0
  9         and d.is_delete = 0
 10  where
 11      m.unique_id2 between 1 and 10
 12  group by
 13      d.non_unique_id
 14      ,m.unique_id2
 15  order by
 16      d.non_unique_id
 17*     ,m.unique_id2

100行が選択されました。

経過: 00:00:01.71

実行計画
----------------------------------------------------------                             
Plan hash value: 1194523033                                                            

-------------------------------------------------------------------------------------------  
| Id  | Operation                      | Name     | Rows  | Bytes | Cost (%CPU)| Time     |  
-------------------------------------------------------------------------------------------  
|   0 | SELECT STATEMENT               |          |  1034 | 16544 |   539   (1)| 00:00:07 |  
|   1 |  SORT GROUP BY                 |          |  1034 | 16544 |   539   (1)| 00:00:07 |  
|   2 |   NESTED LOOPS                 |          |       |       |            |          |  
|   3 |    NESTED LOOPS                |          |  1034 | 16544 |   537   (0)| 00:00:07 |  
|*  4 |     TABLE ACCESS BY INDEX ROWID| TAB2     |    10 |    60 |     2   (0)| 00:00:01 |  
|*  5 |      INDEX RANGE SCAN          | TAB2_PK  |    10 |       |     1   (0)| 00:00:01 |  
|*  6 |     INDEX RANGE SCAN           | TAB1_IX2 |   111 |       |     1   (0)| 00:00:01 |  
|*  7 |    TABLE ACCESS BY INDEX ROWID | TAB1     |   103 |  1030 |   106   (0)| 00:00:02 |  
-------------------------------------------------------------------------------------------  

Predicate Information (identified by operation id):                                    
---------------------------------------------------                                    

   4 - filter("M"."IS_DELETE"=0)                                                       
   5 - access("M"."UNIQUE_ID2">=1 AND "M"."UNIQUE_ID2"<=10)                           
    6 - access("M"."UNIQUE_ID2"="D"."NON_UNIQUE_ID2")                                   
       filter("D"."NON_UNIQUE_ID2"<=10 AND "D"."NON_UNIQUE_ID2">=1)                   
   7 - filter("D"."IS_DELETE"=0)                                                       


統計
----------------------------------------------------------                             
          0  recursive calls                                                           
          0  db block gets                                                             
       9604  consistent gets                                                           
       5793  physical reads                                                            
          0  redo size                                                                 
       2588  bytes sent via SQL*Net to client                                          
        482  bytes received via SQL*Net from client                                    
          8  SQL*Net roundtrips to/from client                                         
          1  sorts (memory)                                                            
          0  sorts (disk)                                                              
        100  rows processed

WHERE句やPredicate Informationからも駆動表(TAB2)と内部表(TAB1)は判断できると思います。

駆動表(TAB2)はWHERE句の検索条件および結合条件でアクセスパスとなる列が参照されています。
内部表(TAB1)はWHERE句では参照されておらず、結合条件でのみアクセスパスとなる列が参照されていることがわかります。

選択リストやGROUP/ORDER BY句から、内部表(TAB1)のNON_UNIQUE_ID列も索引に含める必要があるとわかるはずです。

既に気づいた方も多いと思うのですが、index only access化に必要な索引列候補はSQL文だけでも見つけることができるんですよ。

ただ、複雑な結合などが含まれる場合は、実行計画計画やPredicate Informationに有益な情報が載っているので、できれば合わせて見ておくと吉ですね。　

Truth is out there! :) って場合もあるってことで。

14:48:31 SCOTT> @demo4_ix
create index tab2_ix_demo4 on tab2(unique_id2,is_delete) nologging invisible

索引が作成されました。

経過: 00:00:00.06
create index tab1_ix_demo4 on tab1(non_unique_id2, is_delete, non_unique_id) nologging invisible

索引が作成されました。

経過: 00:00:01.21
alter session set optimizer_use_invisible_indexes=true

セッションが変更されました。

経過: 00:00:00.00

大きなクエリほど効果は絶大ということで。

1710msから50msに改善してます。consistents getsは、1/291に :)

14:49:04 SCOTT> @demo4

システムが変更されました。

経過: 00:00:00.05
  1  select
  2      d.non_unique_id
  3     ,m.unique_id2
  4     ,count(1)
  5  from
  6      tab2 m join tab1 d
  7      on m.unique_id2 = d.non_unique_id2
  8         and m.is_delete = 0
  9         and d.is_delete = 0
 10  where
 11      m.unique_id2 between 1 and 10
 12  group by
 13      d.non_unique_id
 14      ,m.unique_id2
 15  order by
 16      d.non_unique_id
 17*     ,m.unique_id2

100行が選択されました。

経過: 00:00:00.04

実行計画
----------------------------------------------------------                             
Plan hash value: 1672990879                                                            

------------------------------------------------------------------------------------   
| Id  | Operation          | Name          | Rows  | Bytes | Cost (%CPU)| Time     |   
------------------------------------------------------------------------------------   
|   0 | SELECT STATEMENT   |               |  1034 | 16544 |    31   (4)| 00:00:01 |   
|   1 |  SORT GROUP BY     |               |  1034 | 16544 |    31   (4)| 00:00:01 |   
|   2 |   NESTED LOOPS     |               |  1034 | 16544 |    30   (0)| 00:00:01 |   
|*  3 |    INDEX RANGE SCAN| TAB1_IX_DEMO4 | 10314 |   100K|    30   (0)| 00:00:01 |   
|*  4 |    INDEX RANGE SCAN| TAB2_IX_DEMO4 |     1 |     6 |     0   (0)| 00:00:01 |   
------------------------------------------------------------------------------------   

Predicate Information (identified by operation id):                                    
---------------------------------------------------                                    

   3 - access("D"."NON_UNIQUE_ID2">=1 AND "D"."IS_DELETE"=0 AND                        
              "D"."NON_UNIQUE_ID2"<=10)                                                
       filter("D"."IS_DELETE"=0)                                                       
   4 - access("M"."UNIQUE_ID2"="D"."NON_UNIQUE_ID2" AND "M"."IS_DELETE"=0)             
       filter("M"."UNIQUE_ID2"<=10 AND "M"."UNIQUE_ID2">=1)                           
 

統計
----------------------------------------------------------                             
          0  recursive calls                                                           
          0  db block gets                                                             
         33  consistent gets                                                           
         31  physical reads                                                            
          0  redo size                                                                 
       2588  bytes sent via SQL*Net to client                                          
        482  bytes received via SQL*Net from client                                    
          8  SQL*Net roundtrips to/from client                                         
          1  sorts (memory)                                                            
          0  sorts (disk)                                                              
        100  rows processed

14:49:09 SCOTT> @drop_demo4_ix
drop index tab1_ix_demo4

索引が削除されました。

経過: 00:00:00.11
drop index tab2_ix_demo4

索引が削除されました。

経過: 00:00:00.04
alter session set optimizer_use_invisible_indexes=false

セッションが変更されました。

経過: 00:00:00.00

Enjoy!

・Index Only Access (Index Only Scan) っていいよね（デメリットもあるけどさ） #1
・Index Only Access (Index Only Scan) っていいよね（デメリットもあるけどさ） #2

投稿日時 2012年4月 8日 (日) 21時41分チューニング, SQL, Oracle Database 11g, VirtualBox, OOW, JPOUG, Index Only Scan | 固定リンク | 0 | コメント (1) | トラックバック (0)

2012年1月30日 (月)

AWRレポート、AWR SQLレポート一括取得スクリプトを作ったよ。

Statspackレポートもそうなのですが、AWRレポート／AWR SQLレポートも個別に取得していると凄ーく辛いんですよね。一日分出力するとか、AWRレポートで処理時間の長いSQL文のAWR SQLレポートを個別に取得しようとなると...

ただでさえ忙しいのに、AWRレポート取得するのに時間掛けたくないですよね。

ということで、やっつけで作ったのですが、そのまま載せるのもあれなんで、やっつけで作った感じを多少減らしてgithubに公開しました。;)

https://github.com/discus/Oracle-AWR-batch-generation-script/blob/master/awrreport_batch.sql

もっといい感じに改造してくれるといいな〜とかとか... :)

Oracle11g R1/R2 Enterprise Edition、HTML形式で出力します。(RAC環境では試してないので多分だめかと。)。
（AWRを利用するには追加ライセンスが必要なのでご注意を）

使い方は・・

SQL*plusを起動し、select any dictionaryシステム権限、dbms_repositoryパッケージの実行権限が付与されたユーザで接続して実行するだけ。
SYSTEMユーザでやる事が多いけど、所変わればなんとやらなので・・・そこんとこよろしく。(w

一括取得なので実行当日を含めてn日分のAWRレポートを取得し、同時に処理時間の長いTop20のAWR SQLレポートも取得します。
レポートは各スナップショット間（今のところ固定）で取得します。

指定するパラメータは、以下の３つ。

Enter snap_id for starting AWR report generation. [NULL] :

AWRレポートを取得する最初のSNAP_IDを指定します。 NULLがデフォルトでほとんどの場合デフォルトのままで事足りると思います。

Enter number of days for reporting period. [1] :

一括取得する日数を指定します。当日を含みます。
当日分のAWRレポートを出力するのであれば、デフォルト値の1のままでOKです。

Enter suffix for AWR reports filename. [NULL] : test

保存するAWRレポートのファイル名に付加するsuffixを指定します。
試験名とか設定するといいですよね。

"test"と指定した場合

awrrpt_nnnn_nnnn_test.htmlや
awrsqrpt_nnnn_nnnn_test_sqlid.html

の形式で保存します。(nnnnはSNAP_ID)

実行例１）当日分の全レポートを取得する例

SYSTEM> 
SYSTEM> !ls -l awr*.sql
-rw-r--r-- 1 oracle oinstall 6065  1月 29 18:23 awrreport_batch.sql

SYSTEM> @awrreport_batch   
 --
-- Oracle AWR and AWR SQL report batch generation script
--
-- ***** This script always generate html format AWR reports. *****
--
Enter snap_id for starting AWR report generation. [NULL] : 
Enter number of days for reporting period. [1] : 
Enter suffix for AWR reports filename. [NULL] : test
--
--
--
clear break compute;
repfooter off;
ttitle off;
btitle off;

・・・中略・・・

<p />
<br /><a class="awr" href="#top">Back to Top</a><p />
</body></html>

SYSTEM>

実行例２）当日分かつsnap_id=291以降で一括取得。（事前にsnap_idを調べておいてね）

SYSTEM> 
SYSTEM> @awrreport_batch
--
-- Oracle AWR and AWR SQL report batch generation script
--
-- ***** This script always generate html format AWR reports. *****
--
Enter snap_id for starting AWR report generation. [NULL] : 291
Enter number of days for reporting period. [1] : 
Enter suffix for AWR reports filename. [NULL] : test
--
--
--
clear break compute;
repfooter off;
ttitle off;
btitle off;

・・・中略・・・

<p />
<br /><a class="awr" href="#top">Back to Top</a><p />
</body></html>

SYSTEM> 
SYSTEM> 
SYSTEM> !ls -l *.html
-rw-r--r-- 1 oracle oinstall 379083  1月 29 22:23 awrrpt_291_292_test.html
-rw-r--r-- 1 oracle oinstall  11899  1月 29 22:23 awrsqrpt_291_292_test_0c83z9rqx45hu.html
-rw-r--r-- 1 oracle oinstall  11899  1月 29 22:23 awrsqrpt_291_292_test_0h3mfbzk6uyw0.html
-rw-r--r-- 1 oracle oinstall  11897  1月 29 22:23 awrsqrpt_291_292_test_2p7t0mw7zvu5z.html

・・・中略・・・

-rw-r--r-- 1 oracle oinstall  11899  1月 29 22:23 awrsqrpt_291_292_test_bhtycgwkxhfj9.html
-rw-r--r-- 1 oracle oinstall  11900  1月 29 22:23 awrsqrpt_291_292_test_bpaggvtfkar9k.html
-rw-r--r-- 1 oracle oinstall  11899  1月 29 22:23 awrsqrpt_291_292_test_c50hdbyuwhfn6.html
-rw-r--r-- 1 oracle oinstall  11892  1月 29 22:23 awrsqrpt_291_292_test_g3f3cw3zy5aat.html

SYSTEM>

なお、Oracleインスタンスが再起動された期間でawrrpt.sqlなどを実行すると、レポートが作成できずエラーでSQL*Plusも終了してしまいますが、本スクリプトでは該当部分のレポートはスキップするようにしてあります。:)

Instance     DB Name      Snap Id   Snap Started       Level
------------ ------------ --------- ------------------ -----
lampeye      LAMPEYE            274 29 1月  2012 09:33     1
                                275 29 1月  2012 10:00     1
                                276 29 1月  2012 10:30     1
                                277 29 1月  2012 11:00     1
                                278 29 1月  2012 11:30     1
                                279 29 1月  2012 12:00     1
                                280 29 1月  2012 12:30     1
                                281 29 1月  2012 13:00     1
                                282 29 1月  2012 13:30     1
                                283 29 1月  2012 14:00     1
                                284 29 1月  2012 14:30     1
                                285 29 1月  2012 15:00     1
                                286 29 1月  2012 15:30     1
                                287 29 1月  2012 16:00     1
                                288 29 1月  2012 16:30     1
                                289 29 1月  2012 17:00     1
                                290 29 1月  2012 17:30     1

                                291 29 1月  2012 18:31     1  ←再起動されてる
                                292 29 1月  2012 18:34     1

                                293 29 1月  2012 22:26     1　←再起動されてる

Enjoy!

投稿日時 2012年1月30日 (月) 23時02分 Oracle, PL/SQL, FAQ, SQL, ダウンロード, Oracle Database 11g, Open Source, Oracle11g R2, Oracle Database 11g Release 2 | 固定リンク | 0 | コメント (2) | トラックバック (0)

2012年1月14日 (土)

shutdown immeidateしない、ほかの理由に遭遇！（FYI)

ず〜〜〜〜っと、追記しようと思ってたんだけど書いてなかったので、徹夜明けで早起きした次いでなんで書いておきます。

もう一年近く前のネタなんだけどね。「shutdown immeidateしない、ほかの理由に遭遇！」

＞ yoheia-a さんありがとう :)

私か書いた記事がキッカケで調べなきゃいけなくなったらしいんだけどね。 ;)

http://d.hatena.ne.jp/yohei-a/20110627/1309180675

・shutdown immeidateしない、ほかの理由に遭遇！
・shutdown immeidateしない、ほかの理由に遭遇！ #2
・shutdown immeidateしない、ほかの理由に遭遇！ #3
・shutdown immeidateしない、ほかの理由に遭遇！おまけ
・shutdown immeidateしない、ほかの理由に遭遇！おまけのおまけ（でた〜最近、よくあるパターンw）

投稿日時 2012年1月14日 (土) 05時06分 Oracle, Mac, Linux, FAQ, Oracle Database 11g, Mac(Intel x86), Oracle11g R2 | 固定リンク | 0 | コメント (0) | トラックバック (0)

2012年1月 6日 (金)

Index Only Access (Index Only Scan) っていいよね（デメリットもあるけどさ） #2

Index Only Accessのいいとこ、紹介しちゃいますの続きです。

前回は、索引しかアクセスしない（Index Only Access）場合と、索引＋表データもアクセスしちゃう場合の実行計画上の違いを確認しましたよね。

今回は、Index Only Accessで得られる改善効果の１つであるソート処理の回避について簡単な例で確認してみます。

※VISIBLE/INVISIBLEにしている索引の詳細は前回の記事を参照してくださいね。

Now Playing ♪ - ハイスクールララバイ / イモ欽トリオ - 1981

まず、最初は、悪い子の例から。

索引を全表走査した上で　order by seq#　でソート処理が実行されます。酷いですね。検索条件列に適切な索引を作れよ〜〜〜っ。という状態ですね。

SQL> alter index tab10_i01 invisible;

索引が変更されました。

SQL> alter index tab10_i02 invisible;

索引が変更されました。

SQL> select seq# from tab10 where non_unique_key = '0000000001' order by seq#;

10行が選択されました。

経過: 00:00:04.99

実行計画
----------------------------------------------------------
Plan hash value: 2100371779

----------------------------------------------------------------------------
| Id  | Operation           | Name  | Rows | Bytes | Cost (%CPU)| Time     |
----------------------------------------------------------------------------
|   0 | SELECT STATEMENT    |       |   10 |   160 | 16788   (1)| 00:03:22 |
|   1 |  SORT ORDER BY      |       |   10 |   160 | 16788   (1)| 00:03:22 |
|*  2 |   TABLE ACCESS FULL | TAB10 |   10 |   160 | 16787   (1)| 00:03:22 |
----------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   2 - filter("NON_UNIQUE_KEY"='0000000001')


統計
----------------------------------------------------------
      0  recursive calls
      0  db block gets
  61544  consistent gets
  61540  physical reads
      0  redo size
    655  bytes sent via SQL*Net to client
    520  bytes received via SQL*Net from client
      2  SQL*Net roundtrips to/from client
      1  sorts (memory)
      0  sorts (disk)
     10  rows processed

次に、普通の子の例。

検索条件であるnon_unique_keyに定義された索引を使いIndex range scanかつ、seq#をアクセスするために表データをrowidでアクセス。その後にソート処理が行われています。

普通の子らしい、よい実行計画ですね。 :)

SQL> alter index tab10_i01 visible;

索引が変更されました。

SQL> alter index tab10_i02 invisible;  

索引が変更されました。

SQL> select seq# from tab10 where non_unique_key = '0000000001' order by seq#;

10行が選択されました。

経過: 00:00:00.08

実行計画
----------------------------------------------------------
Plan hash value: 1783972576

------------------------------------------------------------------------------------------
| Id  | Operation                    | Name      | Rows  | Bytes | Cost (%CPU)| Time     |
------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT             |           |    10 |   160 |     5  (20)| 00:00:01 |
|   1 |  SORT ORDER BY               |           |    10 |   160 |     5  (20)| 00:00:01 |
|   2 |   TABLE ACCESS BY INDEX ROWID| TAB10     |    10 |   160 |     4   (0)| 00:00:01 |
|*  3 |    INDEX RANGE SCAN          | TAB10_I01 |    10 |       |     3   (0)| 00:00:01 |
------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   3 - access("NON_UNIQUE_KEY"='0000000001')


統計
----------------------------------------------------------
      0  recursive calls
      0  db block gets
      4  consistent gets
     17  physical reads
      0  redo size
    655  bytes sent via SQL*Net to client
    520  bytes received via SQL*Net from client
      2  SQL*Net roundtrips to/from client
      1  sorts (memory)
      0  sorts (disk)
     10  rows processed

そして、最後は、良い子の登場。

この子、データ量が多くなった場合、ソート処理も足枷になると考えたようで　Index only accessを利用したソート処理回避作戦を取ったようです。　
実行計画をみればわかりますが、索引しかアクセスしておらず、SORT ORDER BY というオペレーションも消えています!

検索条件である、non_unique_key列とソート対象のseq#列の２列からなる複合索引を利用するIndex only accessを狙ったようですね。

ただし、これには order by seq# [asc]であるという大前提があります。
order by seq# desc　というソートも考慮する必要がある場合には、non_unique_key [asc]とseq# desc とした別の複合索引必要になります。（デメリットといえばデメリットですかね、）

order by seq# descというソート条件が仕様上無い事を事前に確認しておけば、なお完璧ですよね〜。　良い子。流石です。 :)

SQL> alter index tab10_i01 invisible;

索引が変更されました。

SQL> alter index tab10_i02 visible;  

索引が変更されました。

SQL> select seq# from tab10 where non_unique_key = '0000000001' order by seq#;

10行が選択されました。

経過: 00:00:00.01

実行計画
----------------------------------------------------------
Plan hash value: 489654843

------------------------------------------------------------------------------
| Id  | Operation        | Name      | Rows  | Bytes | Cost (%CPU)| Time     |
------------------------------------------------------------------------------
|   0 | SELECT STATEMENT |           |    10 |   160 |     3   (0)| 00:00:01 |
|*  1 |  INDEX RANGE SCAN| TAB10_I02 |    10 |   160 |     3   (0)| 00:00:01 |
------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   1 - access("NON_UNIQUE_KEY"='0000000001')


統計
----------------------------------------------------------
      0  recursive calls
      0  db block gets
      4  consistent gets
     16  physical reads
      0  redo size
    655  bytes sent via SQL*Net to client
    520  bytes received via SQL*Net from client
      2  SQL*Net roundtrips to/from client
      0  sorts (memory)
      0  sorts (disk)
     10  rows processed

次回へつづく。（他のソート回避の例も紹介しちゃうか、考えちう）

・Index Only Access (Index Only Scan) っていいよね（デメリットもあるけどさ） #1

・いん！、イン！、Index どっぷり Inde Only Access生活w - Oracle OpenWorld Unconference presented by JPOUG

投稿日時 2012年1月 6日 (金) 11時12分 Oracle, チューニング, SQL, Oracle Database 11g, Oracle11g R2, Oracle Database 11g Release 2, Index Only Scan | 固定リンク | 0 | コメント (0) | トラックバック (0)

2012年1月 4日 (水)

Index Only Access (Index Only Scan) っていいよね（デメリットもあるけどさ） #1

さて、OracleさんがAppleさんのOSで楽しいことしてくれないから最近つまんなくなりつつあるので、普通にSQL文のチューニングネタです。

鬼熱かった、鬼熱かった！ :: Insight out 2011- DB tech showcaseでもかなり触れていた、Index Only Scan日本ではこの表現が割合的に多いようなのですが、Index Only Accessって言ってましたね、トムカイトさんも。英語では後者のほうが一般的なのかもしれません。ここではIndex Only Accessってことにしておきます。;)

デメリットもあるけど、Index Only Accessのいいとこばかりを中心に、書いちゃうよ〜w

まず、前提から。

TAB10表は以下のように定義してあります。意図的に表データが大きくなるようにしてあります :)

 名前                NULL?    型
 ------------------ -------- --------------
 SEQ#               NOT NULL NUMBER
 NON_UNIQUE_KEY     NOT NULL CHAR(10)
 DATA                        VARCHAR2(500)

また、以下のような索引を事前に索引しているが、PK_TAB10という主キー索引以外はINVISIBLEとして作成してある。
INVISIBLEで作成しておくと、索引は通常通りメンテナンスされるが、オプティマイザは実行計画作成時にINVISIBLEな索引を利用しないというOracle11gから登場した便利な機能

また前述の表には以下のような主キー(PK_TAB10)と非ユニークな索引が２つ作成してあります。（あまり良い例ではないですがご勘弁を）
但し、TAB10_I01、TAB10_I02の２索引は、INVISIBLEで作成してあります。効果確認時など便利ですよね。
(不可視索引の詳細はマニュアル「Oracle Database 管理者ガイド　11gリリース1（11.1）不可視索引の作成」を参照のこと。）



INDEX_NAME   COLUMN_NAME
------------ -------------------
PK_TAB10     SEQ#

TAB10_I01    NON_UNIQUE_KEY

TAB10_I02    NON_UNIQUE_KEY
             SEQ#

検証時の処理時間及び、実行統計は、各クエリを２回実行し２回目の処理時間及び、実行統計を載せてあります。
（２回目の実行前にバッファキャッシュをクリアしてあるので、ソフトパース＋キャッシュミスほぼ100%という状況の処理時間及び実行統計情報です。）

テストデータは以下件数で、non_unique_keyは偏りはなく均一に分布させあります。
実際のはなし、均等になることの方が稀ではあると思いますけど、Index Only Accessの効果を見る事ができればそれでOKなので。

COUNT(1)
----------
    800000


COUNT(DISTINCTNON_UNIQUE_KEY)
-----------------------------
                        80000


NON_UNIQUE   COUNT(1)
---------- ----------
0000000001         10
0000000002         10
0000000003         10
0000000004         10
0000000005         10
0000000006         10
0000000007         10
0000000008         10
0000000009         10
0000000010         10
0000000011         10
0000000012         10
0000000013         10
0000000014         10
0000000015         10
0000000016         10
0000000017         10
0000000018         10
0000000019         10
0000000020         10

・・・以下略・・・

まず最初は一番分かりやすい、Index Only Accessの例から。

non_unique_key列に、TAB10_I01という非ユニーク索引を作成してありますが、現状、INVISIBLE状態にしてあるため索引が無く全表走査がとなっていますよね。

SQL> set autot trace exp stat
SQL>
SQL> select count(non_unique_key) from tab10 where non_unique_key between '0000000001' and '0000000010';

経過: 00:00:04.32

実行計画
----------------------------------------------------------
Plan hash value: 1584905094

----------------------------------------------------------------------------
| Id  | Operation          | Name  | Rows  | Bytes | Cost (%CPU)| Time     |
----------------------------------------------------------------------------
|   0 | SELECT STATEMENT   |       |     1 |    11 | 16787   (1)| 00:03:22 |
|   1 |  SORT AGGREGATE    |       |     1 |    11 |            |          |
|*  2 |   TABLE ACCESS FULL| TAB10 |   100 |  1100 | 16787   (1)| 00:03:22 |
----------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   2 - filter("NON_UNIQUE_KEY"<='0000000010' AND
          "NON_UNIQUE_KEY">='0000000001')


統計
----------------------------------------------------------
      0  recursive calls
      0  db block gets
  61544  consistent gets
  61539  physical reads
      0  redo size
    562  bytes sent via SQL*Net to client
    520  bytes received via SQL*Net from client
      2  SQL*Net roundtrips to/from client
      0  sorts (memory)
      0  sorts (disk)
      1  rows processed

ここで、TAB10_I01索引をVISIBLEへ変更して同一クエリを実行してみると……
TAB10_I01索引を利用した実行計画はIndex Range Scanに変化します。しかも、表データはアクセスしていません。これがIndex Only Accessの典型的な例です。アクセスブロック数も処理時間も大きく改善していますよね。

ただ、Index only scanにはデメリットもあります。

それは、索引が多くなればなるほどDML文には足枷になり遅くなるため点です。参照と更新、挿入、削除のバランスを取るのが大切ですが、
とにかく参照を速くする、更新、挿入、削除の処理性能などは少々犠牲にしても問題ないのであれば、どんどんやっちゃいます！（ご利用は計画的にw)

SQL> alter index tab10_i01 visible;
SQL> 
SQL> select count(non_unique_key) from tab10 where non_unique_key between '0000000001' and '0000000010';

経過: 00:00:00.02

実行計画
----------------------------------------------------------
Plan hash value: 3770330610

-------------------------------------------------------------------------------
| Id  | Operation         | Name      | Rows  | Bytes | Cost (%CPU) | Time     |
-------------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |           |     1 |    11 |     3    (0)| 00:00:01 |
|   1 |  SORT AGGREGATE   |           |     1 |    11 |             |          |
|*  2 |   INDEX RANGE SCAN| TAB10_I01 |   100 |  1100 |     3    (0)| 00:00:01 |
-------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   2 - access("NON_UNIQUE_KEY">='0000000001' AND
          "NON_UNIQUE_KEY"<='0000000010')


統計
----------------------------------------------------------
      0  recursive calls
      0  db block gets
      3  consistent gets
      3  physical reads
      0  redo size
    562  bytes sent via SQL*Net to client
    520  bytes received via SQL*Net from client
      2  SQL*Net roundtrips to/from client
      0  sorts (memory)
      0  sorts (disk)
      1  rows processed

ちなみに、クエリは少々違うのですが、Index only accessで無い場合は、index range scan＋table access by index rowidとなり以下のような実行計画になっちゃいます。
（こちらの方がよく目にする実行計画じゃないでしょうかね。私も性能的な問題等なければ以下のような実行計画であれば良しとしておくことが多いのも事実です。。）

実行計画
----------------------------------------------------------
Plan hash value: 1097902029

------------------------------------------------------------------------------------------
| Id  | Operation                    | Name      | Rows  | Bytes | Cost (%CPU)| Time     |
------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT             |           |   100 | 51700 |    11   (0)| 00:00:01 |
|   1 |  TABLE ACCESS BY INDEX ROWID | TAB10     |   100 | 51700 |    11   (0)| 00:00:01 |
|*  2 |   INDEX RANGE SCAN           | TAB10_I02 |   100 |       |     3   (0)| 00:00:01 |
------------------------------------------------------------------------------------------

次回へつづく。（忙しくてなかなか書けないかもw)

投稿日時 2012年1月 4日 (水) 20時43分 Oracle, チューニング, SQL,

Oracle	READ COMMITTED
11.1.0.7.0	ID=2を取得
11.2.0.1.0	空振り
11.2.0.2.0	空振り
12.1.0.1.0	ID=2を取得

DROP SHADOW CTRL

GaragebandとiMovieで

検索

Twitter

最近の記事

最近のコメント

最近のトラックバック

カテゴリー

Oracle

Apple

その他

Googleの広告

RSS

当サイトについて

2023年1月16日 (月)

2022年12月23日 (金)

2022年12月21日 (水)

2022年12月20日 (火)

2022年12月18日 (日)

2022年12月13日 (火)

2022年12月12日 (月)

2022年12月11日 (日)

2022年12月 5日 (月)

2022年4月 9日 (土)

2022年4月 7日 (木)

2022年3月26日 (土)

2021年3月22日 (月)

2019年9月30日 (月)

2019年8月25日 (日)

2019年3月22日 (金)

2019年3月21日 (木)

2019年2月21日 (木)

2019年2月11日 (月)

2018年5月 2日 (水)

今回の新規リリースバッチ処理遅延の原因は、

SQLトレースを有効化したままリリースしたしまったことにより、オーバーヘッドが発生し、グルグル系バッチ処理のスループットが低下したため！

ということでした。SQLトレースを利用したあとの無効化をお忘れなく！ :)

2018年3月18日 (日)

ただ、これは、内部的なパラメータ上の話。

だったら、どのようにして、Temp落ち に立ち向かえばいいんだろう.....次回へ続く :)

2018年3月12日 (月)

_pga_max_size

次回は実際に、そんなに使えんのかよ！ という実験をしてみたいと思います :)

2018年3月 8日 (木)

2018年3月 7日 (水)

2018年2月22日 (木)

2018年2月20日 (火)

2018年2月18日 (日)

2017年12月 4日 (月)

2017年11月 7日 (火)

2017年11月 3日 (金)

2017年10月30日 (月)

2017年10月 7日 (土)

2017年9月 1日 (金)

2017年8月31日 (木)

2017年5月 2日 (火)

2014年8月19日 (火)

2014年8月18日 (月)

2014年8月 4日 (月)

2014年4月20日 (日)

2014年1月 6日 (月)

2014年1月 5日 (日)

2013年12月31日 (火)

2013年11月17日 (日)

2012年5月 1日 (火)

2012年4月28日 (土)

2012年4月 8日 (日)

2012年1月30日 (月)

2012年1月14日 (土)

2012年1月 6日 (金)

2012年1月 4日 (水)

SQLトレースを有効化したままリリースしたしまったことにより、オーバーヘッドが発生し、グルグル系バッチ処理のスループットが低下したため！　

だったら、どのようにして、Temp落ち　に立ち向かえばいいんだろう.....次回へ続く　:)

次回は実際に、そんなに使えんのかよ！　という実験をしてみたいと思います :)