Mac De Oracle: SQL

DROP SHADOW CTRL

TEXT DROP SHADOW OFF

GaragebandとiMovieで

検索

検索用語を入力

Web Blog内

検索フォームを送信

プロフィール

Twitter

Tweets by @discus_hamburg

2025年12月
日	月	火	水	木	金	土
	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	31

最近のトラックバック

[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プライバシー規約をご覧ください。

■免責事項

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

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

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

2025年9月30日 (火)

帰ってきた！標準はあるにはあるが癖の多いSQL #19 - c_alias の癖（おまけ）

書き漏らしていたことに気づいたので、
今日のテーマは、

帰ってきた！標準はあるにはあるが癖の多いSQL #18 - t_alias と c_alias にも癖が出る

の癖のおまけw

Oracle Database、PostgreSQL、MySQLの表エイリアスと列エイリアスの文法の癖の違いを思い出してもらった上で、今日の列エイリアスの癖も合わせて覚えておくと良いかもしれません。

とは言え、サブクエリで該当構文を使うことはあまり無さそうな気はします。
どちらかというと、表値コンストラクタの記述で効果的な構文だと思うので。。。（表値コンストラクタネタは、別エントリーにて）

まず、帰ってきた！標準はあるにはあるが癖の多いSQL #18 - t_alias と c_alias にも癖が出るの列エイリアスの癖の復習から。

インラインビュー（サブクエリ）の列エイリアスを以下のような構文で書けるDBと書けないDBを見てみましょう。

SELECT
  *
FROM
(
   SELECT
     empno
     , 'a'
   FROM
     emp
) t01 (empno, dummy_col)
;

Oracle Database 23ai ver. 23.8 Oracle Databaseではこの構文は許されていませんよね！　表値コンストラクタがサポートされた流れで通常のサブクエリでも使えるようになるかもしれませんが、、、、。

SCOTT@localhost:1521/freepdb1> select banner_full from v$version;

BANNER_FULL
--------------------------------------------------------------------------------
Oracle Database 23ai Free Release 23.0.0.0.0 - Develop, Learn, and Run for Free
Version 23.8.0.25.04

SCOTT@localhost:1521/freepdb1> l
  1  SELECT
  2    *
  3  FROM
  4  (
  5     SELECT
  6       empno
  7       , 'a'
  8     FROM
  9       emp
 10  ) t01 (empno, dummy_col)
 11*
COTT@localhost:1521/freepdb1> /
) t01 (empno, dummy_col)
      *
行10でエラーが発生しました。:
ORA-03048: SQL予約語'('は、'..., 'a'
FROM
emp
) t01 'の後では構文的に有効ではありません ヘルプ:
https://docs.oracle.com/error-help/db/ora-03048/

MySQL 8.4 MySQLでは可能でしたよね。

mysql> select version();
+-----------+
| version() |
+-----------+
| 8.4.6     |
+-----------+

mysql> SELECT
    ->   *
    -> FROM
    -> (
    ->    SELECT
    ->      empno
    ->      , 'a'
    ->    FROM
    ->      emp
    -> ) t01 (empno, dummy_col)
    -> ;
+-------+-----------+
| empno | dummy_col |
+-------+-----------+
|  7782 | a         |
|  7839 | a         |

...略...

|  7844 | a         |
|  7900 | a         |
+-------+-----------+
14 rows in set (0.01 sec)

PostgreSQL 17.5 PostgreSQLでも可能ですよね。
ここまでは、帰ってきた！標準はあるにはあるが癖の多いSQL #18 - t_alias と c_alias にも癖が出るでも書いてました。

perftestdb=> SELECT
perftestdb->   *
perftestdb-> FROM
perftestdb-> (
perftestdb(>    SELECT
perftestdb(>      empno
perftestdb(>      , 'a'
perftestdb(>    FROM
perftestdb(>      emp
perftestdb(> ) t01 (empno, dummy_col)
perftestdb-> ;
 empno | dummy_col 
-------+-----------
  7369 | a
  7499 | a

...略...

  7902 | a
  7934 | a
(14 rows)

で、書き忘れていたのは以降の癖。

以下のように、複数ある列の一方だけのつもりで、列エイリアスを書いたら。。。。どうなるか。

どうなると思います？

SELECT
  *
FROM
(
   SELECT
     empno
     , 'a'
   FROM
     emp
) t01 (dummy_col)
;

Oracle Database 23ai 23.8 Oracle Databaseではそもそもサブクエリに対するこの構文は許されていないのでエラーです。

SCOTT@localhost:1521/freepdb1> l
  1  SELECT
  2    *
  3  FROM
  4  (
  5     SELECT
  6       empno
  7       , 'a'
  8     FROM
  9       emp
 10  ) t01 (dummy_col)
 11*
10:30:52 SCOTT@localhost:1521/freepdb1> /
) t01 (dummy_col)
      *
行10でエラーが発生しました。:
ORA-03048: SQL予約語'('は、'..., 'a'
FROM
emp
) t01 'の後では構文的に有効ではありません ヘルプ:
https://docs.oracle.com/error-help/db/ora-03048/

MySQL 8.4.5 おお！　変化しましたね。 MySQLでは全列定義しないとエラーになるようです。全列のエイリアスを指定するか、しないかのどちらかということですね！　わかりやすい気がしますね。これ。

mysql> SELECT
    ->   *
    -> FROM
    -> (
    ->    SELECT
    ->      empno
    ->      , 'a'
    ->    FROM
    ->      emp
    -> ) t01 (dummy_col)
    -> ;
ERROR 1353 (HY000): In definition of view, derived table or common table expression, SELECT list and column names list have different column counts

PostgreSQL 17.5 では、真打w PostgreSQL。PostreSQLでは一部でも構文エラーにはならない！！！！　まじか、じゃ、指定した列エイリアスはどの列を対象にするの？！！！！！！

サブクエリの列数と同数の列エイリアスを指定しない場合、SELECTリストの列順に対応させているだけのようですね！。この例では、empno列と、無名の列の2列がありますが、列エイリアスで置き換えられたのは、最初のempno列！です

エラーにならないだけに、ちょっと注意が必要な癖ですよね！
エラーにはならないことが、正しいというわけでもないので。。。このケースでは意図しない列名を列エイリアスで置換してしまっているわけで。。MySQLのようにエラーにしてくれた方が嬉しいのではないだろうか。

perftestdb=> SELECT
perftestdb->   *
perftestdb-> FROM
perftestdb-> (
perftestdb(>    SELECT
perftestdb(>      empno
perftestdb(>      , 'a'
perftestdb(>    FROM
perftestdb(>      emp
perftestdb(> ) t01 (dummy_col)
perftestdb-> ;
 dummy_col | ?column? 
-----------+----------
      7369 | a
      7499 | a

...略...

      7902 | a
      7934 | a
(14 rows)

最後に、サブクエリで、各列毎に列エイリアスを指定した方が可読性は良いと考えているので、その比較用w
（前述した列エイリアス構文が、その威力を発揮するのは表値コンストラクタを利用する場合ぐらいになるだろうと思っています）

こんな感じでも、

SELECT
  *
FROM
(
   SELECT
     empno 
     , 'a' AS dummy_col
   FROM
     emp
) t01
;

下記のような場合でも読みやすいとおもいます:)

SELECT
  *
FROM
(
   SELECT
     empno AS empno
     , 'a' AS dummy_col
   FROM
     emp
) t01
;

Oracle

SCOTT@localhost:1521/freepdb1> l  1  SELECT
  2    *
  3  FROM
  4  (
  5     SELECT
  6       empno
  7       , 'a' AS dummy_col
  8     FROM
  9       emp
 10  ) t01
 11*
SCOTT@localhost:1521/freepdb1> /

     EMPNO DUMMY_COL
---------- ---------
      7369 a
      7499 a

...略...

      7902 a
      7934 a

14行が選択されました。

SCOTT@localhost:1521/freepdb1> l
  1  SELECT
  2    *
  3  FROM
  4  (
  5     SELECT
  6       empno AS empno
  7       , 'a' AS dummy_col
  8     FROM
  9       emp
 10  ) t01
 11*
SCOTT@localhost:1521/freepdb1> /

     EMPNO DUMMY_COL
---------- ---------
      7369 a
      7499 a

...略...

      7902 a
      7934 a

14行が選択されました。

MySQL

mysql> SELECT
    ->   *
    -> FROM
    -> (
    ->    SELECT
    ->      empno 
    ->      , 'a' AS dummy_col
    ->    FROM
    ->      emp
    -> ) t01
    -> ;
+-------+-----------+
| empno | dummy_col |
+-------+-----------+
|  7782 | a         |
|  7839 | a         |

...略...

|  7844 | a         |
|  7900 | a         |
+-------+-----------+
14 rows in set (0.00 sec)

mysql> SELECT
    ->   *
    -> FROM
    -> (
    ->    SELECT
    ->      empno AS empno
    ->      , 'a' AS dummy_col
    ->    FROM
    ->      emp
    -> ) t01
    -> ;
+-------+-----------+
| empno | dummy_col |
+-------+-----------+
|  7782 | a         |
|  7839 | a         |

...略...

|  7844 | a         |
|  7900 | a         |
+-------+-----------+
14 rows in set (0.00 sec)

PostgreSQL

perftestdb=> SELECT
perftestdb->   *
perftestdb-> FROM
perftestdb-> (
perftestdb(>    SELECT
perftestdb(>      empno 
perftestdb(>      , 'a' AS dummy_col
perftestdb(>    FROM
perftestdb(>      emp
perftestdb(> ) t01
perftestdb-> ;
 empno | dummy_col 
-------+-----------
  7369 | a
  7499 | a

...略...

  7902 | a
  7934 | a
(14 rows)

perftestdb=> SELECT
perftestdb->   *
perftestdb-> FROM
perftestdb-> (
perftestdb(>    SELECT
perftestdb(>      empno AS empno
perftestdb(>      , 'a' AS dummy_col
perftestdb(>    FROM
perftestdb(>      emp
perftestdb(> ) t01
perftestdb-> ;
 empno | dummy_col
-------+-----------
  7369 | a
  7499 | a

...略...

  7902 | a
  7934 | a
(14 rows)

癖にも色々あります。
PostgreSQLのケースではエラーにならないからといって、だいじょーふだ！！、とは言えないタイプも癖もあます。

別エントリーで予定している表値コンストラクタではこの列エイリアスの構文が重要だったりするので、混乱しないよう、
効果的な場所で使っていく必要はありそうだなぁと思っているところ:)
Oracleのように、そもそも表値エイリアスでしか使えない場合は悩む必要もないわけですが。（いまのところ）

やっと東京も東北方面の気温に近づきつつある。。気もするw

では、また。

Enjoy SQL and 癖 !

投稿日時 2025年9月30日 (火) 17時00分 Oracle, FAQ, SQL, MySQL, PostgreSQL, Oracle Database 23ai | 固定リンク | 0 | コメント (0)

2025年8月24日 (日)

帰ってきた！標準はあるにはあるが癖の多いSQL #18 - t_alias と c_alias にも癖が出る

Previously on Mac De Oracle
前回は、ANY_VALUE()、癖ないじゃんという話でした。

今日は、

t_alias と c_alias　

なんて言うと、バイオハザードがちょっと浮かぶのは私だけか。。（t-virusっぽい響きがあるだけだがw）

ということで、唐突ですがw、

SCOTT@localhost:1521/freepdb1> select * from dept order by deptno;

    DEPTNO DNAME          LOC
---------- -------------- -------------
        10 ACCOUNTING     NEW YORK
        20 RESEARCH       DALLAS
        30 SALES          CHICAGO
        40 OPERATIONS     BOSTON

経過: 00:00:00.00
SCOTT@localhost:1521/freepdb1> select * from emp order by deptno,empno;

     EMPNO ENAME      JOB              MGR HIREDATE        SAL       COMM     DEPTNO
---------- ---------- --------- ---------- -------- ---------- ---------- ----------
      7782 CLARK      MANAGER         7839 81-06-09       2450                    10
      7839 KING       PRESIDENT            81-11-17       5000                    10
      7934 MILLER     CLERK           7782 82-01-23       1300                    10
      7369 SMITH      CLERK           7902 80-12-17        800                    20
      7566 JONES      MANAGER         7839 81-04-02       2975                    20
      7788 SCOTT      ANALYST         7566 87-04-19       3000                    20
      7876 ADAMS      CLERK           7788 87-05-23       1100                    20
      7902 FORD       ANALYST         7566 81-12-03       3000                    20
      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

14行が選択されました。

上記の表が、Oracle database/MySQL/PostgreSQLにあったとします。というか、あります。

この時、2表を結合（外部結合でも内部結合でも良いです）する際、DEPT表をインラインビュー化し、そのビューに表エイリアスと列エイリアスを記述する場合、どのような構文が浮かびますか？

t_alias = 表エイリアス
c_alias = 列エイリアス

と言うのが今日の癖のテーマです:)

よくあるのは以下のな感じ. 列、表　の直後に列エイリアス、表エイリアスを記述する。見落としもつけ忘れも発生しにくく、可読性も良いと思います。

SELECT
  e.empno
  ,e.ename
  ,d.department_name
  ,d.department_loc
FROM
  emp e
  INNER JOIN
  (
    SELECT
      deptno
      ,dname AS department_name
      ,loc AS department_loc
    FROM
      dept
  ) d
  ON
    e.deptno = d.deptno

;

ところが、以下のような構文も可能なrdbmsもあります。はい。これが今日の癖！ www

FROM table_reference [AS] alias ( column1 [, column2 [, ...]] )

参考） PostgreSQL 17 / 7.2. テーブル式 / 7.2.1.2. テーブルと列の別名
https://www.postgresql.jp/document/17/html/queries-table-expressions.html#QUERIES-TABLE-ALIASES

SELECT
  e.empno
  ,e.ename
  ,d.department_name
  ,d.department_loc
FROM
  emp e
  INNER JOIN 
  (
    SELECT
      deptno
      ,dname
      ,loc
    FROM
      dept
  ) d (
    deptno
    , department_name
    , department_loc
  )
  ON
    e.deptno = d.deptno
;

まず最初は、PostgreSQLから。
マニュアルに明記されているくらいですから当然、どちらも問題なく使えます。

perftestdb=> SELECT
perftestdb->   e.empno
perftestdb->   ,e.ename
perftestdb->   ,d.department_name
perftestdb->   ,d.department_loc
perftestdb-> FROM
perftestdb->   emp e
perftestdb->   INNER JOIN 
perftestdb->   (
perftestdb(>     SELECT
perftestdb(>       deptno
perftestdb(>       ,dname
perftestdb(>       ,loc
perftestdb(>     FROM
perftestdb(>       dept
perftestdb(>   ) d (
perftestdb(>     deptno
perftestdb(>     , department_name
perftestdb(>     , department_loc
perftestdb(>   )
perftestdb->   ON
perftestdb->     e.deptno = d.deptno
perftestdb-> ;
 empno | ename  | department_name | department_loc 
-------+--------+-----------------+----------------
  7369 | SMITH  | RESEARCH        | DALLAS
  7499 | ALLEN  | SALES           | CHICAGO
  7521 | WARD   | SALES           | CHICAGO
  7566 | JONES  | RESEARCH        | DALLAS
  7654 | MARTIN | SALES           | CHICAGO
  7698 | BLAKE  | SALES           | CHICAGO
  7782 | CLARK  | ACCOUNTING      | NEW YORK
  7788 | SCOTT  | RESEARCH        | DALLAS
  7839 | KING   | ACCOUNTING      | NEW YORK
  7844 | TURNER | SALES           | CHICAGO
  7876 | ADAMS  | RESEARCH        | DALLAS
  7900 | JAMES  | SALES           | CHICAGO
  7902 | FORD   | RESEARCH        | DALLAS
  7934 | MILLER | ACCOUNTING      | NEW YORK
(14 rows)

perftestdb=> SELECT
perftestdb->   e.empno
perftestdb->   ,e.ename
perftestdb->   ,d.department_name
perftestdb->   ,d.department_loc
perftestdb-> FROM
perftestdb->   emp e
perftestdb->   INNER JOIN
perftestdb->   (
perftestdb(>     SELECT
perftestdb(>       deptno
perftestdb(>       ,dname AS department_name
perftestdb(>       ,loc AS department_loc
perftestdb(>     FROM
perftestdb(>       dept
perftestdb(>   ) d
perftestdb->   ON
perftestdb->     e.deptno = d.deptno
perftestdb-> ;
 empno | ename  | department_name | department_loc 
-------+--------+-----------------+----------------
  7369 | SMITH  | RESEARCH        | DALLAS
  7499 | ALLEN  | SALES           | CHICAGO
  7521 | WARD   | SALES           | CHICAGO
  7566 | JONES  | RESEARCH        | DALLAS
  7654 | MARTIN | SALES           | CHICAGO
  7698 | BLAKE  | SALES           | CHICAGO
  7782 | CLARK  | ACCOUNTING      | NEW YORK
  7788 | SCOTT  | RESEARCH        | DALLAS
  7839 | KING   | ACCOUNTING      | NEW YORK
  7844 | TURNER | SALES           | CHICAGO
  7876 | ADAMS  | RESEARCH        | DALLAS
  7900 | JAMES  | SALES           | CHICAGO
  7902 | FORD   | RESEARCH        | DALLAS
  7934 | MILLER | ACCOUNTING      | NEW YORK
(14 rows)

次に、MySQL。
明確に記載されているドキュメントは見つけられなかった（知ってたら教えてw）のですが、以下のようにどちらも実行できます。

（ありがとうございました。篠田さんに教えていただきました）

MySQL 8.0 リファレンスマニュアル / SQL ステートメント / データ操作ステートメント / サブクエリー / 導出テーブル

mysql> SELECT
    ->   e.empno
    ->   ,e.ename
    ->   ,d.department_name
    ->   ,d.department_loc
    -> FROM
    ->   emp e
    ->   INNER JOIN 
    ->   (
    ->     SELECT
    ->       deptno
    ->       ,dname
    ->       ,loc
    ->     FROM
    ->       dept
    ->   ) d (
    ->     deptno
    ->     , department_name
    ->     , department_loc
    ->   )
    ->   ON
    ->     e.deptno = d.deptno
    -> ;
+-------+--------+-----------------+----------------+
| empno | ename  | department_name | department_loc |
+-------+--------+-----------------+----------------+
|  7782 | CLARK  | ACCOUNTING      | NEW YORK       |
|  7839 | KING   | ACCOUNTING      | NEW YORK       |
|  7934 | MILLER | ACCOUNTING      | NEW YORK       |
|  7369 | SMITH  | RESEARCH        | DALLAS         |
|  7566 | JONES  | RESEARCH        | DALLAS         |
|  7788 | SCOTT  | RESEARCH        | DALLAS         |
|  7876 | ADAMS  | RESEARCH        | DALLAS         |
|  7902 | FORD   | RESEARCH        | DALLAS         |
|  7499 | ALLEN  | SALES           | CHICAGO        |
|  7521 | WARD   | SALES           | CHICAGO        |
|  7654 | MARTIN | SALES           | CHICAGO        |
|  7698 | BLAKE  | SALES           | CHICAGO        |
|  7844 | TURNER | SALES           | CHICAGO        |
|  7900 | JAMES  | SALES           | CHICAGO        |
+-------+--------+-----------------+----------------+
14 rows in set (0.00 sec)

mysql> SELECT
    ->   e.empno
    ->   ,e.ename
    ->   ,d.department_name
    ->   ,d.department_loc
    -> FROM
    ->   emp e
    ->   INNER JOIN
    ->   (
    ->     SELECT
    ->       deptno
    ->       ,dname AS department_name
    ->       ,loc AS department_loc
    ->     FROM
    ->       dept
    ->   ) d
    ->   ON
    ->     e.deptno = d.deptno
    -> ;
+-------+--------+-----------------+----------------+
| empno | ename  | department_name | department_loc |
+-------+--------+-----------------+----------------+
|  7782 | CLARK  | ACCOUNTING      | NEW YORK       |
|  7839 | KING   | ACCOUNTING      | NEW YORK       |
|  7934 | MILLER | ACCOUNTING      | NEW YORK       |
|  7369 | SMITH  | RESEARCH        | DALLAS         |
|  7566 | JONES  | RESEARCH        | DALLAS         |
|  7788 | SCOTT  | RESEARCH        | DALLAS         |
|  7876 | ADAMS  | RESEARCH        | DALLAS         |
|  7902 | FORD   | RESEARCH        | DALLAS         |
|  7499 | ALLEN  | SALES           | CHICAGO        |
|  7521 | WARD   | SALES           | CHICAGO        |
|  7654 | MARTIN | SALES           | CHICAGO        |
|  7698 | BLAKE  | SALES           | CHICAGO        |
|  7844 | TURNER | SALES           | CHICAGO        |
|  7900 | JAMES  | SALES           | CHICAGO        |
+-------+--------+-----------------+----------------+
14 rows in set (0.01 sec)

最後の、Oracle Database.
最後に出てきたと言うことは、はい、本日のオチですねw

マニュアル上でも記載はないので、その通りの結果です。

参考） Oracle Database 23 / SQL言語リファレンス / SELECT / table_reference::=
https://docs.oracle.com/cd/G11854_01/sqlrf/SELECT.html#GUID-CFA006CA-6FF1-4972-821E-6996142A51C6__I2126863

SCOTT@localhost:1521/freepdb1> @t_alias_c_alias_test  1  SELECT
  2    e.empno
  3    ,e.ename
  4    ,d.department_name
  5    ,d.department_loc
  6  FROM
  7    emp e
  8    INNER JOIN
  9    (
 10      SELECT
 11        deptno
 12        ,dname
 13        ,loc
 14      FROM
 15        dept
 16    ) d (
 17      deptno
 18      , department_name
 19      , department_loc
 20    )
 21    ON
 22*     e.deptno = d.deptno
  ) d (
      *
行16でエラーが発生しました。:
ORA-02000: ON or USINGキーワードがありません。 ヘルプ:
https://docs.oracle.com/error-help/db/ora-02000/

経過: 00:00:00.01

  1  SELECT
  2    e.empno
  3    ,e.ename
  4    ,d.department_name
  5    ,d.department_loc
  6  FROM
  7    emp e
  8    INNER JOIN
  9    (
 10      SELECT
 11        deptno
 12        ,dname AS department_name
 13        ,loc AS department_loc
 14      FROM
 15        dept
 16    ) d
 17    ON
 18*     e.deptno = d.deptno

     EMPNO ENAME      DEPARTMENT_NAME  DEPARTMENT_LOC
---------- ---------- ---------------- ---------------
      7369 SMITH      RESEARCH         DALLAS
      7499 ALLEN      SALES            CHICAGO
      7521 WARD       SALES            CHICAGO
      7566 JONES      RESEARCH         DALLAS
      7654 MARTIN     SALES            CHICAGO
      7698 BLAKE      SALES            CHICAGO
      7782 CLARK      ACCOUNTING       NEW YORK
      7788 SCOTT      RESEARCH         DALLAS
      7839 KING       ACCOUNTING       NEW YORK
      7844 TURNER     SALES            CHICAGO
      7876 ADAMS      RESEARCH         DALLAS
      7900 JAMES      SALES            CHICAGO
      7902 FORD       RESEARCH         DALLAS
      7934 MILLER     ACCOUNTING       NEW YORK

14行が選択されました。

と言うことで、

帰ってきた！標準はあるにはあるが癖の多いSQL #18 - t_alias と c_alias にも癖が出る

ここまで。

普段使わないような構文に出会うと、ちょっと固まったりしますよねw

あ、そうそう、固まるといえば、
最近、クマとの接近遭遇が市街地でも多くなり、
散歩に行くにも、"クルマ"に気をつけてー、のついでに、”クマ”にも気をつけて〜っ　
と言った方がいいかもねと言う程度に頻度が高くて、マジで散歩しにくいので、
なんとかして欲しいと思う、
万が一であったら、固まってしまいそう。。。。。

涼しくなりつつある、北の地より。

ではまた。

Enjoy SQL and SQLの癖w

関連エントリー

投稿日時 2025年8月24日 (日) 07時49分 Oracle, FAQ, SQL, MySQL, PostgreSQL | 固定リンク | 0 | コメント (0)

2025年8月22日 (金)

帰ってきた！標準はあるにはあるが癖の多いSQL #17 - ANY_VALUE() ってなかなかいいじゃん、癖無さそう！

さて、
今回は久々に、標準はあるにはあるが癖の多いSQLシリーズです！　

データが小さいとその価値はほぼわからないかもしれませんが、ひょんなところで出会ってしまった！と、いうような状況で役立つかもしれませんwwww

今日のお題は、ANY_VALUE()関数。　集約関数の仲間です:)

MySQLやOracle Databaseのマニュアルでは使い所を理解しやすい解説があります。おすすめです。
一方、PostgreSQLのマニュアルシンプルすぎる解説ゆえ、この関数はなに？　なにが美味しいの？　みたいな顔になってしまうかもしれません。がw、ググってみてください、いろいろ見つかります！

この関数に出会ってよかった！　ということを思いながらw
以下の曲をBGMにして眺めてみてください:)

ラブ・ストーリーは突然に / 小田和正

少量のデータだとその良さに気づきにくいのですが、万が一の時は、ANY_VALUE()集約関数を思い出してみてください。
リソース消費は数が多くなるとボディーブローにはなるので、リソース使用量削減に重箱の隅をつつくようなことしないといけないとかw そんな時にも役立つかも。。。しれないです。

参考）

Oracle / ANY_VALUE() - 19cからサポートされました
https://docs.oracle.com/cd/F19136_01/sqlrf/any_value.html

MySQL / ANY_VALUE() - 5.7からサポートされました
https://dev.mysql.com/doc/refman/8.0/ja/miscellaneous-functions.html#function_any-value

PostgreSQL / ANY_VALUE() - 16からサポートされました
https://www.postgresql.jp/document/17/html/functions-aggregate.html

環境

HostOS : macOS Sonoma 14.7.7 (arm64)
VirtualBox 7.1 (arm64)

GuestOS : Oracle Linux 8u10 (arm64)
　Oracle Database 23ai 23.8 (arm64)
　PostgreSQL 17.5 (arm64)
　MySQL 8.4.6 (arm64)

テストケース

テストケース1)

集約する列データ長が長がーーーい

テストケース2)

集約する列データは短めでもデータ量が多いケース

の2つを用意しました。
データ量はどちらも多めにしました。理由は、集計関数やGROUP BYの性能差分はデータ量が少ないと差分が見にくいためです:)
これぐらいデータにして、やっと、ふむふむと頷ける差分が見えるのではないかと思います。

計測は３回実行しています（１回目には諸々ノイズが乗りやすいので参考程度にしています）

では、先に結果から。
全体的に ANY_VALUE()が軽めの傾向として出てきているのは間違いないと思います。あえてそういう目的で追加してきた関数ですし。MySQLやOracle DatabaseのマニュアルではANY_VALUE()集約関数についての解説もわかりやすいとおもいます。
ANY_VALUE()の用途が広く認知されれば、可読性向上という意味もきっちり出てきそうな気はします。（個人的にはw。今は微妙は感じを持っている方は多いと思いますが、非集約列をGROUP BY句に記述するのも、MIN/MAX集約関数を使うのも可読性という意味では微妙だと思っているので、そういう目的の関数の登場で方向は定まるのではないかと。。。。w）
PostgreSQLのマニュアルに目を向けると、他の関数の説明とのバランスもあると思うのでw、さらりと書かれていて、初めて見た方は、君は何？　
という感じになりそうではあるのですが、ググると結構情報も多くなってきたので何ものかを知るのに困ることもないと思います。

個別のまとめ

Oracle Database 23ai free

環境による差異は多少ありそうですが、GROUP BYで対処する場合とANY_VALUE()で対処する場合では、列サイズが長い場合にはANY_VALUE()の方が効果的に対処できそうですね。CPUに優しくなっています。
一方該当列の列サイズが比較的短い場合には、GROUP BY / ANY_VALUE()大きな差はでにくです。ANYU_VALUE()の認知度次第ですが、この手のハンドリングのための記述として認知度があがると、可読性としては向上しそうな気がします。

注）軽かった順に列挙してます。

テストケース1)

ANY_VALUE() -> GROUP BY句で対処 -> MAX()

テストケース2)

ANY_VALUE() -> GROUP BY句で対処 -> MAX()

PostgreSQL

PostgreSQLでは、やはり、ANY_VALUE()が早いですが、MAX()とかなり近い結果となり、GROUP BYが最も遅いという結果になりました。
面白い。

テストケース1)

ANY_VALUE() -> MAX() -> GROUP BY句で対処

テストケース2)

ANY_VALUE() -> MAX() -> GROUP BY句で対処

MySQL

MySQLではすべてが、Aggregate using temporary table　となっていたので条件的には同じ状態で比較できた分わかりやすい結果になっていました。
MySQLでもこの手のケースでANY_VALUE()を利用しておいた方がお得でしょうね。

テストケース1)

ANY_VALUE() -> MAX() -> GROUP BY句で対処

テストケース2)

ANY_VALUE() -> MAX() -> GROUP BY句で対処

Oracle Databaseでの処理時間まとめ

SQLモニターを利用して取得.

列サイズ長め GROUP BY

Global Stats
==============================================================================
| Elapsed |   Cpu   |    IO    | Application | Fetch | Buffer | Read | Read  |
| Time(s) | Time(s) | Waits(s) |  Waits(s)   | Calls |  Gets  | Reqs | Bytes |
==============================================================================
|    0.67 |    0.56 |     0.11 |        0.00 |     2 |   250K | 1981 |   2GB |
|    0.62 |    0.53 |     0.09 |             |     2 |   250K | 1981 |   2GB |
|    0.61 |    0.52 |     0.09 |             |     2 |   250K | 1981 |   2GB |
==============================================================================

MAX

Global Stats
================================================================
| Elapsed |   Cpu   |    IO    | Fetch | Buffer | Read | Read  |
| Time(s) | Time(s) | Waits(s) | Calls |  Gets  | Reqs | Bytes |
================================================================
|    0.78 |    0.67 |     0.11 |     2 |   250K | 1981 |   2GB |
|    0.74 |    0.65 |     0.09 |     2 |   250K | 1981 |   2GB |
|    0.73 |    0.65 |     0.09 |     2 |   250K | 1981 |   2GB |
================================================================

ANY_VALUE

Global Stats
================================================================
| Elapsed |   Cpu   |    IO    | Fetch | Buffer | Read | Read  |
| Time(s) | Time(s) | Waits(s) | Calls |  Gets  | Reqs | Bytes |
================================================================
|    0.34 |    0.25 |     0.09 |     2 |   250K | 1981 |   2GB |
|    0.33 |    0.25 |     0.09 |     2 |   250K | 1981 |   2GB |
|    0.34 |    0.25 |     0.09 |     2 |   250K | 1981 |   2GB |
================================================================

列サイズ短めで件数が多い

GROUP BY

Global Stats
================================================================
| Elapsed |   Cpu   |    IO    | Fetch | Buffer | Read | Read  |
| Time(s) | Time(s) | Waits(s) | Calls |  Gets  | Reqs | Bytes |
================================================================
|    1.65 |    1.42 |     0.23 |     2 |   171K | 1363 |   1GB |
|    1.15 |    1.10 |     0.06 |     2 |   171K | 1363 |   1GB |
|    1.16 |    1.10 |     0.06 |     2 |   171K | 1363 |   1GB |
================================================================

MAX

Global Stats
================================================================
| Elapsed |   Cpu   |    IO    | Fetch | Buffer | Read | Read  |
| Time(s) | Time(s) | Waits(s) | Calls |  Gets  | Reqs | Bytes |
================================================================
|    1.66 |    1.55 |     0.12 |     2 |   171K | 1363 |   1GB |
|    1.29 |    1.23 |     0.06 |     2 |   171K | 1363 |   1GB |
|    1.29 |    1.23 |     0.06 |     2 |   171K | 1363 |   1GB |
================================================================

ANY_VALUE

Global Stats
================================================================
| Elapsed |   Cpu   |    IO    | Fetch | Buffer | Read | Read  |
| Time(s) | Time(s) | Waits(s) | Calls |  Gets  | Reqs | Bytes |
================================================================
|    1.47 |    1.38 |     0.10 |     2 |   171K | 1363 |   1GB |
|    1.15 |    1.09 |     0.06 |     2 |   171K | 1363 |   1GB |
|    1.15 |    1.09 |     0.06 |     2 |   171K | 1363 |   1GB |
================================================================

PostgreSQL

PostgreSQLのwork_memが小さかった影響で、GROUP BYによる対処ではTemp落ちして一人負けしてました。設定チューニングしていたらMAX/ANY_VALUEに近い結果になっていたかもね。（Oracleみたいにデフォでいい感じってあれではなかった、しくじりw）
とはいえ、MAX()とANY_VALUE()の差があまりないのもPostgreSQLの特徴ですかね。

列サイズ長め

GROUP BY

 Execution Time: 3533.979 ms
 Execution Time: 3570.032 ms
 Execution Time: 3553.467 ms

MAX

 Execution Time: 439.917 ms
 Execution Time: 434.463 ms
 Execution Time: 434.348 ms

ANY_VALUE

 Execution Time: 461.668 ms
 Execution Time: 444.132 ms
 Execution Time: 431.056 ms

列サイズ短めで件数が多い

GROUP BY

 Execution Time: 4300.000 ms
 Execution Time: 4635.630 ms
 Execution Time: 4595.763 ms

MAX

 Execution Time: 4449.759 ms
 Execution Time: 4449.591 ms
 Execution Time: 4425.708 ms

ANY_VALUE

 Execution Time: 4240.994 ms
 Execution Time: 4145.707 ms
 Execution Time: 4018.328 ms

MySQL

列サイズ長め

GROUP BY

1 row in set (13.16 sec)
1 row in set (13.03 sec)
1 row in set (13.03 sec)

MAX

1 row in set (8.59 sec)
1 row in set (8.60 sec)
1 row in set (9.40 sec)

ANY_VALUE

1 row in set (0.49 sec)
1 row in set (0.43 sec)
1 row in set (0.49 sec)

列サイズ短めで件数が多い

GROUP BY

1 row in set (21.31 sec)
1 row in set (21.90 sec)
1 row in set (20.89 sec)

MAX

1 row in set (15.68 sec)
1 row in set (16.16 sec)
1 row in set (16.16 sec)

ANY_VALUE

1 row in set (8.35 sec)
1 row in set (8.54 sec)
1 row in set (8.20 sec)

ということで、

帰ってきた！標準はあるにはあるが癖の多いSQL #17 - ANY_VALUE() 、
癖があるとおもったのですが、癖はなかったですw

では、また。

朝晩の風が、あきっぽい、北のエリアより。。。夏祭りが終われば、あっというまに秋、、、になるはずw

Enjoy SQL! and RDBMS!

関連エントリー

以下、興味のある方向けのログと今回適当に作ったデータ作成スクリプトなどを載せています。以降は長いので興味のない方は飛ばしてくださいww

ーーーーーーーログーーーーーーー

Oracle Database

-- 列サイズ長め（準備）
SCOTT@localhost:1521/freepdb1> @any_value.sql
  1* DROP TABLE IF EXISTS any_value_table PURGE

表が削除されました。

経過: 00:00:00.20
  1  CREATE TABLE any_value_table
  2  (
  3    ordered_date DATE NOT NULL
  4    , order_id INTEGER NOT NULL
  5    , product_id INTEGER NOT NULL
  6    , product_name VARCHAR(2000) NOT NULL
  7    , qty INTEGER NOT NULL
  8    , CONSTRAINT pk_any_value_table PRIMARY KEY (order_id, product_id, ordered_date)
  9* )

表が作成されました。

経過: 00:00:00.04
  1  DECLARE
  2    o_date DATE := SYSDATE;
  3  BEGIN
  4    FOR i IN 1..1000000 LOOP
  5      INSERT INTO any_value_table
  6        (ordered_date
  7         , order_id
  8         , product_id
  9         , product_name
 10         , qty
 11        ) VALUES (o_date, i, 1, 'ITEM_1'||lpad('*',1600,'*'), 1);
 12      IF mod(i,100) = 0 THEN commit; END IF;
 13    END LOOP;
 14* END;

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

経過: 00:02:58.25

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

経過: 00:00:42.26

SEGMENT_NAME                           GB
------------------------------ ----------
ANY_VALUE_TABLE                1.96582031

経過: 00:00:00.03

...中略...

-- ２回目
非集計列がGROUP BY句に定義もされず、集計関数も利用されていない場合は、エラーになることの確認！
SCOTT@localhost:1521/freepdb1> @any_value_test
  1  SELECT
  2    product_id
  3    ,product_name
  4    ,SUM(qty) AS total
  5  FROM
  6    any_value_table
  7  GROUP BY
  8*   product_id
  ,product_name
   *
行3でエラーが発生しました。:
ORA-00979: "PRODUCT_NAME": GROUP BY句に出現するか、集計関数で使用される必要があります 
ヘルプ:
https://docs.oracle.com/error-help/db/ora-00979/

経過: 00:00:00.01
  1  SELECT /*+ MONITOR */
  2    product_id
  3    ,product_name
  4    ,SUM(qty) AS total
  5  FROM
  6    any_value_table
  7  GROUP BY
  8    product_id
  9*   , product_name

PRODUCT_ID PRODUCT_NAME　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　      TOTAL
---------- ----------------------------------------------------------------------------------------------------------- ----------
         1 ITEM_1*****************************************************************************************************    1000000
           ***********************************************************************************************************

...中略...

           ***********************************************************************************************************
           ***********************************************************************************************************
           *
           
経過: 00:00:00.58

...中略...

SQL Text
------------------------------
SELECT /*+ MONITOR */ product_id ,product_name 
,SUM(qty) AS total FROM any_value_table 
GROUP BY product_id , product_name

...中略...

Global Stats
================================================================
| Elapsed |   Cpu   |    IO    | Fetch | Buffer | Read | Read  |
| Time(s) | Time(s) | Waits(s) | Calls |  Gets  | Reqs | Bytes |
================================================================
|    0.62 |    0.53 |     0.09 |     2 |   250K | 1981 |   2GB |
================================================================

SQL Plan Monitoring Details (Plan Hash Value=3772843140)
=====================================================================================================================================================
| Id |      Operation       |      Name       |  Rows   | Cost  |   Time    | Start  | Execs |   Rows   | Read | Read  | Activity | Activity Detail |
|    |                      |                 | (Estim) |       | Active(s) | Active |       | (Actual) | Reqs | Bytes |   (%)    |   (# samples)   |
=====================================================================================================================================================
|  0 | SELECT STATEMENT     |                 |         |       |         1 |     +1 |     1 |        1 |      |       |          |                 |
|  1 |   HASH GROUP BY      |                 |       1 | 69634 |         1 |     +1 |     1 |        1 |      |       |   100.00 | Cpu (1)         |
|  2 |    TABLE ACCESS FULL | ANY_VALUE_TABLE |      1M | 69619 |         1 |     +1 |     1 |       1M | 1981 |   2GB |          |                 |
=====================================================================================================================================================

...中略...

SQL Text
------------------------------
SELECT /*+ MONITOR */ product_id ,MAX(product_name) AS product_name 
,SUM(qty) AS total FROM any_value_table 
GROUP BY product_id

...中略...

Global Stats
================================================================
| Elapsed |   Cpu   |    IO    | Fetch | Buffer | Read | Read  |
| Time(s) | Time(s) | Waits(s) | Calls |  Gets  | Reqs | Bytes |
================================================================
|    0.74 |    0.65 |     0.09 |     2 |   250K | 1981 |   2GB |
================================================================

SQL Plan Monitoring Details (Plan Hash Value=3772843140)
=====================================================================================================================================================
| Id |      Operation       |      Name       |  Rows   | Cost  |   Time    | Start  | Execs |   Rows   | Read | Read  | Activity | Activity Detail |
|    |                      |                 | (Estim) |       | Active(s) | Active |       | (Actual) | Reqs | Bytes |   (%)    |   (# samples)   |
=====================================================================================================================================================
|  0 | SELECT STATEMENT     |                 |         |       |         1 |     +0 |     1 |        1 |      |       |          |                 |
|  1 |   HASH GROUP BY      |                 |       1 | 69634 |         1 |     +0 |     1 |        1 |      |       |          |                 |
|  2 |    TABLE ACCESS FULL | ANY_VALUE_TABLE |      1M | 69619 |         1 |     +0 |     1 |       1M | 1981 |   2GB |          |                 |
=====================================================================================================================================================

...中略...

SQL Text
------------------------------
SELECT /*+ MONITOR */ product_id ,ANY_VALUE(product_name) AS product_name 
,SUM(qty) AS total FROM any_value_table 
GROUP BY product_id

...中略...

Global Stats
================================================================
| Elapsed |   Cpu   |    IO    | Fetch | Buffer | Read | Read  |
| Time(s) | Time(s) | Waits(s) | Calls |  Gets  | Reqs | Bytes |
================================================================
|    0.33 |    0.25 |     0.09 |     2 |   250K | 1981 |   2GB |
================================================================

SQL Plan Monitoring Details (Plan Hash Value=3772843140)
=====================================================================================================================================================
| Id |      Operation       |      Name       |  Rows   | Cost  |   Time    | Start  | Execs |   Rows   | Read | Read  | Activity | Activity Detail |
|    |                      |                 | (Estim) |       | Active(s) | Active |       | (Actual) | Reqs | Bytes |   (%)    |   (# samples)   |
=====================================================================================================================================================
|  0 | SELECT STATEMENT     |                 |         |       |         1 |     +1 |     1 |        1 |      |       |          |                 |
|  1 |   HASH GROUP BY      |                 |       1 | 69634 |         1 |     +1 |     1 |        1 |      |       |   100.00 | Cpu (1)         |
|  2 |    TABLE ACCESS FULL | ANY_VALUE_TABLE |      1M | 69619 |         1 |     +1 |     1 |       1M | 1981 |   2GB |          |                 |
=====================================================================================================================================================

...中略...

-- 列サイズ短めで件数が多い（準備）
SCOTT@localhost:1521/freepdb1> @any_value2.sql
  1* DROP TABLE IF EXISTS any_value_table PURGE

表が削除されました。

経過: 00:00:00.13
  1  CREATE TABLE any_value_table
  2  (
  3    ordered_date DATE NOT NULL
  4    , order_id INTEGER NOT NULL
  5    , product_id INTEGER NOT NULL
  6    , product_name VARCHAR(2000) NOT NULL
  7    , qty INTEGER NOT NULL
  8    , CONSTRAINT pk_any_value_table PRIMARY KEY (order_id, product_id, ordered_date)
  9* )

表が作成されました。

経過: 00:00:00.01
  1  DECLARE
  2    o_date DATE := SYSDATE;
  3  BEGIN
  4    FOR i IN 1..20000000 LOOP
  5      INSERT INTO any_value_table
  6        (ordered_date
  7         , order_id
  8         , product_id
  9         , product_name
 10         , qty
 11        ) VALUES (o_date, i, 1, 'ITEM_1'||LPAD('*',30,'*'), 1);
 12      IF mod(i,1000) = 0 THEN commit; END IF;
 13    END LOOP;
 14* END;

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

経過: 00:12:27.16

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

経過: 00:00:17.83

SEGMENT_NAME                           GB
------------------------------ ----------
ANY_VALUE_TABLE                    1.3125

経過: 00:00:00.06

...中略...

-- ２回目
SCOTT@localhost:1521/freepdb1> @any_value_test2
  1  SELECT /*+ monitor */
  2    product_id
  3    ,product_name
  4    ,SUM(qty) AS total
  5  FROM
  6    any_value_table
  7  GROUP BY
  8    product_id
  9*   , product_name

PRODUCT_ID PRODUCT_NAME                              TOTAL
---------- ------------------------------------ ----------
         1 ITEM_1******************************   20000000

経過: 00:00:01.11

...中略...

SQL Text
------------------------------
SELECT /*+ monitor */ product_id ,product_name 
,SUM(qty) AS total FROM any_value_table 
GROUP BY product_id , product_name

...中略...

Global Stats
================================================================
| Elapsed |   Cpu   |    IO    | Fetch | Buffer | Read | Read  |
| Time(s) | Time(s) | Waits(s) | Calls |  Gets  | Reqs | Bytes |
================================================================
|    1.15 |    1.10 |     0.06 |     2 |   171K | 1363 |   1GB |
================================================================

SQL Plan Monitoring Details (Plan Hash Value=3772843140)
=====================================================================================================================================================
| Id |      Operation       |      Name       |  Rows   | Cost  |   Time    | Start  | Execs |   Rows   | Read | Read  | Activity | Activity Detail |
|    |                      |                 | (Estim) |       | Active(s) | Active |       | (Actual) | Reqs | Bytes |   (%)    |   (# samples)   |
=====================================================================================================================================================
|  0 | SELECT STATEMENT     |                 |         |       |         1 |     +1 |     1 |        1 |      |       |          |                 |
|  1 |   HASH GROUP BY      |                 |       1 | 46860 |         1 |     +1 |     1 |        1 |      |       |          |                 |
|  2 |    TABLE ACCESS FULL | ANY_VALUE_TABLE |     20M | 46510 |         1 |     +1 |     1 |      20M | 1363 |   1GB |   100.00 | Cpu (1)         |
=====================================================================================================================================================

...中略...

SQL Text
------------------------------
SELECT /*+ monitor */ product_id ,MAX(product_name) AS product_name 
,SUM(qty) AS total FROM any_value_table 
GROUP BY product_id

...中略...

Global Stats
================================================================
| Elapsed |   Cpu   |    IO    | Fetch | Buffer | Read | Read  |
| Time(s) | Time(s) | Waits(s) | Calls |  Gets  | Reqs | Bytes |
================================================================
|    1.29 |    1.23 |     0.06 |     2 |   171K | 1363 |   1GB |
================================================================

SQL Plan Monitoring Details (Plan Hash Value=3772843140)
=====================================================================================================================================================
| Id |      Operation       |      Name       |  Rows   | Cost  |   Time    | Start  | Execs |   Rows   | Read | Read  | Activity | Activity Detail |
|    |                      |                 | (Estim) |       | Active(s) | Active |       | (Actual) | Reqs | Bytes |   (%)    |   (# samples)   |
=====================================================================================================================================================
|  0 | SELECT STATEMENT     |                 |         |       |         1 |     +2 |     1 |        1 |      |       |          |                 |
|  1 |   HASH GROUP BY      |                 |       1 | 46860 |         1 |     +2 |     1 |        1 |      |       |          |                 |
|  2 |    TABLE ACCESS FULL | ANY_VALUE_TABLE |     20M | 46510 |         2 |     +1 |     1 |      20M | 1363 |   1GB |   100.00 | Cpu (1)         |
=====================================================================================================================================================

...中略...

SQL Text
------------------------------
SELECT /*+ monitor */ product_id ,ANY_VALUE(product_name) AS product_name 
,SUM(qty) AS total FROM any_value_table 
GROUP BY product_id

...中略...

Global Stats
================================================================
| Elapsed |   Cpu   |    IO    | Fetch | Buffer | Read | Read  |
| Time(s) | Time(s) | Waits(s) | Calls |  Gets  | Reqs | Bytes |
================================================================
|    1.15 |    1.09 |     0.06 |     2 |   171K | 1363 |   1GB |
================================================================

SQL Plan Monitoring Details (Plan Hash Value=3772843140)
==========================================================================================================================================================
| Id |      Operation       |      Name       |  Rows   | Cost  |   Time    | Start  | Execs |   Rows   | Read | Read  | Activity |   Activity Detail    |
|    |                      |                 | (Estim) |       | Active(s) | Active |       | (Actual) | Reqs | Bytes |   (%)    |     (# samples)      |
==========================================================================================================================================================
|  0 | SELECT STATEMENT     |                 |         |       |         1 |     +1 |     1 |        1 |      |       |          |                      |
|  1 |   HASH GROUP BY      |                 |       1 | 46860 |         1 |     +1 |     1 |        1 |      |       |          |                      |
|  2 |    TABLE ACCESS FULL | ANY_VALUE_TABLE |     20M | 46510 |         2 |     +0 |     1 |      20M | 1363 |   1GB |   100.00 | direct path read (1) |
==========================================================================================================================================================

PostgreSQL

-- 列サイズ長め（準備）
perftestdb=> \i ./any_value.sql
Timing is on.
DROP TABLE
Time: 7.248 ms
CREATE TABLE
Time: 3.827 ms
DO
Time: 24680.064 ms (00:24.680)
ANALYZE
Time: 104.675 ms
Timing is off.

...中略...

-- ２回目
PostgreSQLでも非集計列をGROUP BYに記述しないと、エラーになりますよね。
perftestdb=> \i ./any_value_test.sql
psql:any_value_test.sql:11: ERROR:  column "any_value_table.product_name" must appear in the GROUP BY clause 
or be used in an aggregate function
LINE 3:   ,product_name
           ^


注）出力内容は見やすく加工しちゃってます
 product_id |                                             product_name                                                    |  total   
------------+-------------------------------------------------------------------------------------------------------------+--------
          1 | ITEM_1***************************************************************************************************** | 1000000
              ***********************************************************************************************************
              ***********************************************************************************************************

...中略...

              ***********************************************************************************************************
              ***********************************************************************************************************
              *
(1 row)


GROUP BYで対処したケースで、work_memセットし忘れてデフォのままだったので Temp落ちして一人負けしてました。すみません。
                                                                   QUERY PLAN                                                                    
-------------------------------------------------------------------------------------------------------------------------------------------------
 GroupAggregate  (cost=2471963.84..2491963.84 rows=1000000 width=1622) (actual time=3044.982..3044.983 rows=1 loops=1)
   Output: product_id, product_name, sum(qty)
   Group Key: any_value_table.product_id, any_value_table.product_name
   Buffers: shared hit=250000, temp read=598111 written=598519
   ->  Sort  (cost=2471963.84..2474463.84 rows=1000000 width=1618) (actual time=2479.915..2867.067 rows=1000000 loops=1)
         Output: product_id, product_name, qty
         Sort Key: any_value_table.product_id, any_value_table.product_name
         Sort Method: external merge  Disk: 1595032kB
         Buffers: shared hit=250000, temp read=598111 written=598519
         ->  Seq Scan on scott.any_value_table  (cost=0.00..260000.00 rows=1000000 width=1618) (actual time=0.012..216.822 rows=1000000 loops=1)
               Output: product_id, product_name, qty
               Buffers: shared hit=250000
 Planning:
   Buffers: shared hit=2
   Memory: used=14kB  allocated=16kB
 Planning Time: 0.409 ms
 Execution Time: 3570.032 ms
(17 rows)

...中略...

                                                                QUERY PLAN                                                                 
-------------------------------------------------------------------------------------------------------------------------------------------
 HashAggregate  (cost=267500.00..267500.01 rows=1 width=44) (actual time=434.445..434.445 rows=1 loops=1)
   Output: product_id, max((product_name)::text), sum(qty)
   Group Key: any_value_table.product_id
   Batches: 1  Memory Usage: 24kB
   Buffers: shared hit=250000
   ->  Seq Scan on scott.any_value_table  (cost=0.00..260000.00 rows=1000000 width=1618) (actual time=0.003..122.488 rows=1000000 loops=1)
         Output: ordered_date, order_id, product_id, product_name, qty
         Buffers: shared hit=250000
 Planning:
   Memory: used=14kB  allocated=16kB
 Planning Time: 0.324 ms
 Execution Time: 434.463 ms
(12 rows)

 ...中略...
 
                                                                QUERY PLAN                                                                 
-------------------------------------------------------------------------------------------------------------------------------------------
 HashAggregate  (cost=267500.00..267500.01 rows=1 width=44) (actual time=444.114..444.114 rows=1 loops=1)
   Output: product_id, any_value(product_name), sum(qty)
   Group Key: any_value_table.product_id
   Batches: 1  Memory Usage: 24kB
   Buffers: shared hit=250000
   ->  Seq Scan on scott.any_value_table  (cost=0.00..260000.00 rows=1000000 width=1618) (actual time=0.003..138.239 rows=1000000 loops=1)
         Output: ordered_date, order_id, product_id, product_name, qty
         Buffers: shared hit=250000
 Planning:
   Memory: used=14kB  allocated=16kB
 Planning Time: 0.043 ms
 Execution Time: 444.132 ms
(12 rows)

...中略...

-- 列サイズ短めで件数が多い（準備）
perftestdb=> \i ./any_value2.sql
Timing is on.
DROP TABLE
Time: 126.466 ms
CREATE TABLE
Time: 6.143 ms
DO
Time: 80158.605 ms (01:20.159)
ANALYZE
Time: 136.012 ms
Timing is off.
perftestdb=> 

...中略...

-- ２回目
perftestdb=> \i ./any_value_test2.sql
SET
 product_id |             product_name             |  total   
------------+--------------------------------------+----------
          1 | ITEM_1****************************** | 20000000
(1 row)

                                                                 QUERY PLAN                                                                 
--------------------------------------------------------------------------------------------------------------------------------------------
 HashAggregate  (cost=556186.00..556186.01 rows=1 width=49) (actual time=4635.607..4635.608 rows=1 loops=1)
   Output: product_id, product_name, sum(qty)
   Group Key: any_value_table.product_id, any_value_table.product_name
   Batches: 1  Memory Usage: 24kB
   Buffers: shared hit=206186
   ->  Seq Scan on scott.any_value_table  (cost=0.00..406186.00 rows=20000000 width=45) (actual time=0.004..1041.109 rows=20000000 loops=1)
         Output: ordered_date, order_id, product_id, product_name, qty
         Buffers: shared hit=206186
 Planning:
   Buffers: shared hit=3
   Memory: used=14kB  allocated=16kB
 Planning Time: 0.063 ms
 Execution Time: 4635.630 ms
(13 rows)

...中略...

                                                                 QUERY PLAN                                                                 
--------------------------------------------------------------------------------------------------------------------------------------------
 HashAggregate  (cost=556186.00..556186.01 rows=1 width=44) (actual time=4449.572..4449.572 rows=1 loops=1)
   Output: product_id, max((product_name)::text), sum(qty)
   Group Key: any_value_table.product_id
   Batches: 1  Memory Usage: 24kB
   Buffers: shared hit=206186
   ->  Seq Scan on scott.any_value_table  (cost=0.00..406186.00 rows=20000000 width=45) (actual time=0.004..1007.065 rows=20000000 loops=1)
         Output: ordered_date, order_id, product_id, product_name, qty
         Buffers: shared hit=206186
 Planning:
   Memory: used=14kB  allocated=16kB
 Planning Time: 0.049 ms
 Execution Time: 4449.591 ms
(12 rows)

...中略...

                                                                 QUERY PLAN                                                                 
--------------------------------------------------------------------------------------------------------------------------------------------
 HashAggregate  (cost=556186.00..556186.01 rows=1 width=44) (actual time=4145.688..4145.688 rows=1 loops=1)
   Output: product_id, any_value(product_name), sum(qty)
   Group Key: any_value_table.product_id
   Batches: 1  Memory Usage: 24kB
   Buffers: shared hit=206186
   ->  Seq Scan on scott.any_value_table  (cost=0.00..406186.00 rows=20000000 width=45) (actual time=0.005..1006.129 rows=20000000 loops=1)
         Output: ordered_date, order_id, product_id, product_name, qty
         Buffers: shared hit=206186
 Planning:
   Memory: used=14kB  allocated=16kB
 Planning Time: 0.050 ms
 Execution Time: 4145.707 ms
(12 rows)

MySQL

-- 列サイズ長め（準備）
mysql> \. /home/master/any_value.sql
Query OK, 0 rows affected (0.03 sec)

Empty set (0.00 sec)

Query OK, 0 rows affected (0.05 sec)

Empty set (0.00 sec)

Query OK, 0 rows affected (0.05 sec)

Empty set (0.00 sec)

Query OK, 0 rows affected (0.01 sec)

Query OK, 0 rows affected (0.00 sec)

+--------------+
| @@AUTOCOMMIT |
+--------------+
|            0 |
+--------------+
1 row in set (0.00 sec)

Query OK, 0 rows affected (2 min 38.38 sec)

Empty set (0.00 sec)

Query OK, 0 rows affected (0.01 sec)

+--------------+
| @@AUTOCOMMIT |
+--------------+
|            1 |
+--------------+
1 row in set (0.00 sec)

+----------------------------+---------+----------+----------+
| Table                      | Op      | Msg_type | Msg_text |
+----------------------------+---------+----------+----------+
| perftestdb.any_value_table | analyze | status   | OK       |
+----------------------------+---------+----------+----------+
1 row in set (0.01 sec)

...中略...

-- ２回目
MySQLでも今のリリースでは、非集計列をGROUP BY 句に記述しないとエラーになりますよね。
mysql> \. /home/master/any_value_test.sql
ERROR 1055 (42000): Expression #2 of SELECT list is not in GROUP BY clause and contains nonaggregated column
 'perftestdb.any_value_table.product_name' which is not functionally dependent on columns in GROUP BY clause;
 this is incompatible with sql_mode=only_full_group_by


注）出力内容は見やすく加工しちゃってます
+------------+-------------------------------------------------------------------------------------------------------------+----------+
| product_id | product_name                                                                                                | total    |
+------------+-------------------------------------------------------------------------------------------------------------+----------+
|          1 | ITEM_1***************************************************************************************************** | 20000000 |
|            | *********************************************************************************************************** |          |
|            | *********************************************************************************************************** |          |

...中略...

|            | *********************************************************************************************************** |          |
|            | *********************************************************************************************************** |          |
|            | *                                                                                                           |          |
+------------+-------------------------------------------------------------------------------------------------------------+----------+
1 row in set (13.03 sec)

+-------------------------------------------------------------------------------------------------------------+
| EXPLAIN                                                                                                     |
+-------------------------------------------------------------------------------------------------------------+
| -> Table scan on   (actual time=12979..12979 rows=1 loops=1)
    -> Aggregate using temporary table  (actual time=12979..12979 rows=1 loops=1)
        -> Table scan on any_value_table  (cost=116731 rows=888992) (actual time=0.0124..290 rows=1e+6 loops=1)
 |
+-------------------------------------------------------------------------------------------------------------+
1 row in set (12.98 sec)

...中略...

+-------------------------------------------------------------------------------------------------------------+
| EXPLAIN                                                                                                     |
+-------------------------------------------------------------------------------------------------------------+
| -> Table scan on   (actual time=8620..8620 rows=1 loops=1)
    -> Aggregate using temporary table  (actual time=8620..8620 rows=1 loops=1)
        -> Table scan on any_value_table  (cost=116731 rows=888992) (actual time=0.0136..288 rows=1e+6 loops=1)
 |
+-------------------------------------------------------------------------------------------------------------+
1 row in set (8.62 sec)

...中略...

+-------------------------------------------------------------------------------------------------------------+
| EXPLAIN                                                                                                     |
+-------------------------------------------------------------------------------------------------------------+
| -> Table scan on   (actual time=492..492 rows=1 loops=1)
    -> Aggregate using temporary table  (actual time=492..492 rows=1 loops=1)
        -> Table scan on any_value_table  (cost=116731 rows=888992) (actual time=0.0163..258 rows=1e+6 loops=1)
 |
+-------------------------------------------------------------------------------------------------------------+
1 row in set (0.49 sec)

...中略...


-- 列サイズ短めで件数が多い（準備）
mysql> \. /home/master/any_value2.sql
Query OK, 0 rows affected (0.03 sec)

Empty set (0.00 sec)

Query OK, 0 rows affected (0.04 sec)

Empty set (0.00 sec)

Query OK, 0 rows affected (0.01 sec)

Empty set (0.00 sec)

Query OK, 0 rows affected (0.02 sec)

Query OK, 0 rows affected (0.00 sec)

+--------------+
| @@AUTOCOMMIT |
+--------------+
|            0 |
+--------------+
1 row in set (0.00 sec)

Query OK, 0 rows affected (9 min 11.20 sec)

Empty set (0.00 sec)

Query OK, 0 rows affected (0.00 sec)

+--------------+
| @@AUTOCOMMIT |
+--------------+
|            1 |
+--------------+
1 row in set (0.00 sec)

+----------------------------+---------+----------+----------+
| Table                      | Op      | Msg_type | Msg_text |
+----------------------------+---------+----------+----------+
| perftestdb.any_value_table | analyze | status   | OK       |
+----------------------------+---------+----------+----------+
1 row in set (0.03 sec)

...中略...

-- ２回目
mysql> \. /home/master/any_value_test2.sql
+------------+--------------------------------------+----------+
| product_id | product_name                         | total    |
+------------+--------------------------------------+----------+
|          1 | ITEM_1****************************** | 20000000 |
+------------+--------------------------------------+----------+
1 row in set (21.90 sec)

+-------------------------------------------------------------------------------------------------------------+
| EXPLAIN                                                                                                     |
+-------------------------------------------------------------------------------------------------------------+
| -> Table scan on   (actual time=22964..22964 rows=1 loops=1)
    -> Aggregate using temporary table  (actual time=22964..22964 rows=1 loops=1)
        -> Table scan on any_value_table  (cost=2.01e+6 rows=19.9e+6) (actual time=0.0134..4447 rows=20e+6 loops=1)
 |
+-------------------------------------------------------------------------------------------------------------+
1 row in set (22.97 sec)

...中略...

+-------------------------------------------------------------------------------------------------------------+
| EXPLAIN                                                                                                     |
+-------------------------------------------------------------------------------------------------------------+
| -> Table scan on   (actual time=17478..17478 rows=1 loops=1)
    -> Aggregate using temporary table  (actual time=17478..17478 rows=1 loops=1)
        -> Table scan on any_value_table  (cost=2.01e+6 rows=19.9e+6) (actual time=0.0115..4399 rows=20e+6 loops=1)
 |
+-------------------------------------------------------------------------------------------------------------+
1 row in set (17.48 sec)

...中略...

+-------------------------------------------------------------------------------------------------------------+
| EXPLAIN                                                                                                     |
+-------------------------------------------------------------------------------------------------------------+
| -> Table scan on   (actual time=9273..9273 rows=1 loops=1)
    -> Aggregate using temporary table  (actual time=9273..9273 rows=1 loops=1)
        -> Table scan on any_value_table  (cost=2.01e+6 rows=19.9e+6) (actual time=0.0116..4208 rows=20e+6 loops=1)
 |
+-------------------------------------------------------------------------------------------------------------+
1 row in set (9.28 sec)

-------------------- Scripts ----------------------

Oracle Database

列長の長いテストケース準備

any_value.sql

DROP TABLE IF EXISTS any_value_table PURGE
.
l
/

CREATE TABLE any_value_table
(
  ordered_date DATE NOT NULL 
  , order_id INTEGER NOT NULL
  , product_id INTEGER NOT NULL
  , product_name VARCHAR(2000) NOT NULL
  , qty INTEGER NOT NULL
  , CONSTRAINT pk_any_value_table PRIMARY KEY (order_id, product_id, ordered_date)
)
.
l
/

DECLARE
  o_date DATE := SYSDATE;
BEGIN
  FOR i IN 1..1000000 LOOP
    INSERT INTO any_value_table 
      (ordered_date
       , order_id
       , product_id
       , product_name
       , qty
      ) VALUES (o_date, i, 1, 'ITEM_1'||lpad('*',1600,'*'), 1);
    IF mod(i,100) = 0 THEN commit; END IF;
  END LOOP;
END;
.
l
/

EXEC DBMS_STATS.GATHER_TABLE_STATS(ownname=>'SCOTT',tabname=>'any_value_table',cascade=>true,no_invalidate=>false);
select segment_name,bytes/1024/1024/1024 "GB" from user_segments where segment_name = upper('any_value_table');

列長の長いケースのテスト（エラーになるSQL含む）

any_value_test.sql

SET LINESIZE 300
SET PAGESIZE 1000
SET LONGCHUNK 1000
SET LONG 100000

-- error --
SELECT
  product_id
  ,product_name
  ,SUM(qty) AS total
FROM
  any_value_table
GROUP BY
  product_id
.
l
/

SELECT /*+ monitor */
  product_id
  ,product_name
  ,SUM(qty) AS total
FROM
  any_value_table
GROUP BY
  product_id
  , product_name
.
l
/
select DBMS_SQLTUNE.REPORT_SQL_MONITOR(SQL_ID=>NULL,TYPE=>'TEXT');

SELECT /*+ monitor */
  product_id
  ,MAX(product_name) AS product_name
  ,SUM(qty) AS total
FROM
  any_value_table
GROUP BY
  product_id
.
l
/
select DBMS_SQLTUNE.REPORT_SQL_MONITOR(SQL_ID=>NULL,TYPE=>'TEXT');


SELECT /*+ monitor */
  product_id
  ,ANY_VALUE(product_name) AS product_name
  ,SUM(qty) AS total
FROM
  any_value_table
GROUP BY
  product_id
.
l
/
select DBMS_SQLTUNE.REPORT_SQL_MONITOR(SQL_ID=>NULL,TYPE=>'TEXT');

列サイズ短めで件数が多いテストケースの準備

any_value2.sql


DROP TABLE IF EXISTS any_value_table PURGE
.
l
/

CREATE TABLE any_value_table
(
  ordered_date DATE NOT NULL 
  , order_id INTEGER NOT NULL
  , product_id INTEGER NOT NULL
  , product_name VARCHAR(2000) NOT NULL
  , qty INTEGER NOT NULL
  , CONSTRAINT pk_any_value_table PRIMARY KEY (order_id, product_id, ordered_date)
)
.
l
/


DECLARE
  o_date DATE := SYSDATE;
BEGIN
  FOR i IN 1..20000000 LOOP
    INSERT INTO any_value_table 
      (ordered_date
       , order_id
       , product_id
       , product_name
       , qty
      ) VALUES (o_date, i, 1, 'ITEM_1'||LPAD('*',30,'*'), 1);
    IF mod(i,1000) = 0 THEN commit; END IF;v  END LOOP;
END;
.
l
/

col product_name for a30
EXEC DBMS_STATS.GATHER_TABLE_STATS(ownname=>'SCOTT',tabname=>'any_value_table',cascade=>true,no_invalidate=>false);
select segment_name,bytes/1024/1024/1024 "GB" from user_segments where segment_name = upper('any_value_table');

列サイズ短めで件数が多いテストケースの準備

any_value_test2.sql

SET LINESIZE 300
SET PAGESIZE 1000
SET LONGCHUNK 1000
SET LONG 100000


SELECT /*+ monitor */
  product_id
  ,product_name
  ,SUM(qty) AS total
FROM
  any_value_table
GROUP BY
  product_id
  , product_name
.
l
/

select DBMS_SQLTUNE.REPORT_SQL_MONITOR(SQL_ID=>NULL,TYPE=>'TEXT');

SELECT /*+ monitor */
  product_id
  ,MAX(product_name) AS product_name
  ,SUM(qty) AS total
FROM
  any_value_table
GROUP BY
  product_id
.
l
/

select DBMS_SQLTUNE.REPORT_SQL_MONITOR(SQL_ID=>NULL,TYPE=>'TEXT');

SELECT /*+ monitor */
  product_id
  ,ANY_VALUE(product_name) AS product_name
  ,SUM(qty) AS total
FROM
  any_value_table
GROUP BY
  product_id
.
l
/
select DBMS_SQLTUNE.REPORT_SQL_MONITOR(SQL_ID=>NULL,TYPE=>'TEXT');

PostgreSQL

列長の長いテストケース準備

any_value.sql

\timing
DROP TABLE IF EXISTS any_value_table;

CREATE TABLE any_value_table
(
  ordered_date DATE NOT NULL 
  , order_id INTEGER NOT NULL
  , product_id INTEGER NOT NULL
  , product_name VARCHAR(2000) NOT NULL
  , qty INTEGER NOT NULL
  , CONSTRAINT pk_any_value_table PRIMARY KEY (order_id, product_id, ordered_date)
);

DO $$
DECLARE
  o_date DATE := CURRENT_DATE;
BEGIN
    FOR i IN 1..1000000 LOOP
      INSERT INTO any_value_table 
        (ordered_date
         , order_id
         , product_id
         , product_name
         , qty
        ) VALUES (o_date, i, 1, 'ITEM_1'||lpad('*',1600,'*'), 1);
      IF mod(i,100) = 0 THEN 
        COMMIT;
      END IF;
    END LOOP;
END
$$;

analyze any_value_table;
\timing

列長の長いテストケース(エラーケース含む)
any_value_test.sql

-- error --
SELECT
  product_id
  ,product_name
  ,SUM(qty) AS total
FROM
  any_value_table
GROUP BY
  product_id
;

set max_parallel_workers_per_gather = 0;
SELECT 
  product_id
  ,product_name
  ,SUM(qty) AS total
FROM
  any_value_table
GROUP BY
  product_id
  , product_name
;

explain (analyze,buffers,memory,summary,verbose)
SELECT 
  product_id
  ,product_name
  ,SUM(qty) AS total
FROM
  any_value_table
GROUP BY
  product_id
  , product_name
;

SELECT 
  product_id
  ,MAX(product_name) AS product_name
  ,SUM(qty) AS total
FROM
  any_value_table
GROUP BY
  product_id
;

explain (analyze,buffers,memory,summary,verbose)
SELECT 
  product_id
  ,MAX(product_name) AS product_name
  ,SUM(qty) AS total
FROM
  any_value_table
GROUP BY
  product_id
;

SELECT 
  product_id
  ,ANY_VALUE(product_name) AS product_name
  ,SUM(qty) AS total
FROM
  any_value_table
GROUP BY
  product_id
;

explain (analyze,buffers,memory,summary,verbose)
SELECT 
  product_id
  ,ANY_VALUE(product_name) AS product_name
  ,SUM(qty) AS total
FROM
  any_value_table
GROUP BY
  product_id
;

列サイズ短めで件数が多いテストケースの準備

any_value2.sql

\timing
DROP TABLE IF EXISTS any_value_table;

CREATE TABLE any_value_table
(
  ordered_date DATE NOT NULL 
  , order_id INTEGER NOT NULL
  , product_id INTEGER NOT NULL
  , product_name VARCHAR(2000) NOT NULL
  , qty INTEGER NOT NULL
  , CONSTRAINT pk_any_value_table PRIMARY KEY (order_id, product_id, ordered_date)
);

DO $$
DECLARE
  o_date DATE := CURRENT_DATE;
BEGIN
  FOR i IN 1..20000000 LOOP
    INSERT INTO any_value_table
       (ordered_date
       , order_id
       , product_id
       , product_name
       , qty
      ) VALUES (o_date, i, 1, 'ITEM_1'||LPAD('*',30,'*'), 1);
    IF mod(i,1000) = 0 THEN commit; END IF;
  END LOOP;
END
$$
;

analyze any_value_table;
\timing

列サイズ短めで件数が多いテストケース

any_value_test2.sql

set max_parallel_workers_per_gather = 0;

SELECT  
  product_id
  ,product_name
  ,SUM(qty) AS total
FROM
  any_value_table
GROUP BY
  product_id
  , product_name;

explain (analyze,buffers,memory,summary,verbose)
SELECT 
  product_id
  ,product_name
  ,SUM(qty) AS total
FROM
  any_value_table
GROUP BY
  product_id
  , product_name;


SELECT
  product_id
  ,MAX(product_name) AS product_name
  ,SUM(qty) AS total
FROM
  any_value_table
GROUP BY
  product_id;


explain (analyze,buffers,memory,summary,verbose)
SELECT
  product_id
  ,MAX(product_name) AS product_name
  ,SUM(qty) AS total
FROM
  any_value_table
GROUP BY
  product_id;


SELECT
  product_id
  ,ANY_VALUE(product_name) AS product_name
  ,SUM(qty) AS total
FROM
  any_value_table
GROUP BY
  product_id;

explain (analyze,buffers,memory,summary,verbose)
SELECT
  product_id
  ,ANY_VALUE(product_name) AS product_name
  ,SUM(qty) AS total
FROM
  any_value_table
GROUP BY
  product_id;

MySQL

列長の長いテストケース準備

any_value.sql

DROP TABLE IF EXISTS any_value_table;
show warnings;

CREATE TABLE any_value_table
(
  ordered_date DATE NOT NULL 
  , order_id INTEGER NOT NULL
  , product_id INTEGER NOT NULL
  , product_name VARCHAR(2000) NOT NULL
  , qty INTEGER NOT NULL
  , CONSTRAINT pk_any_value_table PRIMARY KEY (order_id, product_id, ordered_date)
);
show warnings;

DROP PROCEDURE IF EXISTS make_any_table_data;
show warnings;

DELIMITER $$
CREATE PROCEDURE make_any_table_data()
BEGIN
  DECLARE o_date DATE DEFAULT CURRENT_DATE;
  DECLARE i INTEGER DEFAULT 1;
  DECLARE r_count INTEGER DEFAULT 1000000;
  loop1: LOOP
    INSERT INTO any_value_table
      (ordered_date
       , order_id
       , product_id
       , product_name
       , qty
      ) VALUES (o_date, i, 1, CONCAT('ITEM_1', lpad('*',1600,'*')), 1);
    IF mod(i,100) = 0 THEN commit; END IF;
    SET i = i + 1;
    IF i > r_count THEN LEAVE loop1; END IF;
  END LOOP loop1;
END
$$
DELIMITER ;

set AUTOCOMMIT=0;
select @@AUTOCOMMIT;

CALL make_any_table_data; 
show warnings;

set AUTOCOMMIT=1;
select @@AUTOCOMMIT;

analyze table any_value_table;

列長の長いテストケース(エラーケース含む)

any_value_test.sql

-- error --
SELECT
  product_id
  ,product_name
  ,SUM(qty) AS total
FROM
  any_value_table
GROUP BY
  product_id
;


SELECT 
  product_id
  ,product_name
  ,SUM(qty) AS total
FROM
  any_value_table
GROUP BY
  product_id
  , product_name
;

explain analyze format=tree
SELECT 
  product_id
  ,product_name
  ,SUM(qty) AS total
FROM
  any_value_table
GROUP BY
  product_id
  , product_name
;


SELECT 
  product_id
  ,MAX(product_name) AS product_name
  ,SUM(qty) AS total
FROM
  any_value_table
GROUP BY
  product_id
;

explain analyze format=tree
SELECT 
  product_id
  ,MAX(product_name) AS product_name
  ,SUM(qty) AS total
FROM
  any_value_table
GROUP BY
  product_id
;

SELECT 
  product_id
  ,ANY_VALUE(product_name) AS product_name
  ,SUM(qty) AS total
FROM
  any_value_table
GROUP BY
  product_id
;


explain analyze format=tree
SELECT 
  product_id
  ,ANY_VALUE(product_name) AS product_name
  ,SUM(qty) AS total
FROM
  any_value_table
GROUP BY
  product_id
;

列サイズ短めで件数が多いテストケース（準備）

any_value2.sql

DROP TABLE IF EXISTS any_value_table;
show warnings;

CREATE TABLE any_value_table
(
  ordered_date DATE NOT NULL 
  , order_id INTEGER NOT NULL
  , product_id INTEGER NOT NULL
  , product_name VARCHAR(2000) NOT NULL
  , qty INTEGER NOT NULL
  , CONSTRAINT pk_any_value_table PRIMARY KEY (order_id, product_id, ordered_date)
);
show warnings;

DROP PROCEDURE IF EXISTS make_any_table_data;
show warnings;

DELIMITER $$
CREATE PROCEDURE make_any_table_data()
BEGIN
  DECLARE o_date DATE DEFAULT CURRENT_DATE;
  DECLARE i INTEGER DEFAULT 1;
  DECLARE r_count INTEGER DEFAULT 20000000;
  loop1: LOOP
    INSERT INTO any_value_table
      (ordered_date
       , order_id
       , product_id
       , product_name
       , qty
      ) VALUES (o_date, i, 1, CONCAT('ITEM_1', LPAD('*',30,'*')), 1);
    IF mod(i,1000) = 0 THEN commit; END IF;
    SET i = i + 1;
    IF i > r_count THEN LEAVE loop1; END IF;
  END LOOP loop1;
END
$$
DELIMITER ; 

set AUTOCOMMIT=0;
select @@AUTOCOMMIT;

CALL make_any_table_data;
show warnings;

set AUTOCOMMIT=1;
select @@AUTOCOMMIT;

analyze table any_value_table;

列サイズ短めで件数が多いテストケース

any_value_test2.sql

SELECT  
  product_id
  ,product_name
  ,SUM(qty) AS total
FROM
  any_value_table
GROUP BY
  product_id
  , product_name;

explain analyze format=tree
SELECT 
  product_id
  ,product_name
  ,SUM(qty) AS total
FROM
  any_value_table
GROUP BY
  product_id
  , product_name;

SELECT
  product_id
  ,MAX(product_name) AS product_name
  ,SUM(qty) AS total
FROM
  any_value_table
GROUP BY
  product_id;


explain analyze format=tree
SELECT
  product_id
  ,MAX(product_name) AS product_name
  ,SUM(qty) AS total
FROM
  any_value_table
GROUP BY
  product_id;


SELECT
  product_id
  ,ANY_VALUE(product_name) AS product_name
  ,SUM(qty) AS total
FROM
  any_value_table
GROUP BY
  product_id;

explain analyze format=tree
SELECT
  product_id
  ,ANY_VALUE(product_name) AS product_name
  ,SUM(qty) AS total
FROM
  any_value_table
GROUP BY
  product_id;

投稿日時 2025年8月22日 (金) 19時00分 Oracle, Oracle以外のデータベース, チューニング, SQL, MySQL, PostgreSQL, パフォーマンス, Oracle Database 23ai | 固定リンク | 0 | コメント (0)

2025年7月 4日 (金)

実行計画は, SQL文のレントゲン写真だ！ No.67 / AI Vector Search - VECTOR INDEX HNSW SCAN のバリエーション

Previously on Mac De Oracle
前回は、VECTOR INDEX はどこ？、見積もりサイズだとそれなりのサイズだったのに... の謎を探るべく、我々は洞窟の奥へ向かった！(完結編)でした。
今日は、再びレントゲン写真に戻り、VECTOR INDEX HNSW SCAN のバリエーションをいくつか確認しておこうと思います。
（なかなか興味深いので、一度診ておけば、いざというときに慌てなくて済むと思います）

いきなりってのもあれなので、先に以下のマニュアルを一読しておくと良いと思います。マニュアルでもポイントが解説されているネタなので:)　解説しないとちょっと分かりずらい点が多いからだと思いますがw

Oracle Database 23ai / Oracle AI Vector Search ユーザーズ・ガイド / HNSW ベクトルインデックスのオプティマイザプランのバリエーションを解説している章があります。なかなか興味深い。
おそらく、表には積極的に登場してこない補助表が、突然実行計画に現れることへの戸惑いと実行計画の読み方にちょっとした癖がある点の緩和と実行計画のバリエーションごとのメリデメを理解してもらうためにも解説が必要だったのだろうなぁ。と想像。
Oracle Database / Release 23 / Oracle AI Vector Search User's Guide / Optimizer Plans for HNSW Vector Indexes

INMEMORYな索引なのに、OperationにINMEMORYというキーワードが無くて、おや？　と違和感があったり、ちょっとめんどくさい癖があるなぁと。。。w

まずは、
vector_index_neighbor_graph_reloadパラメータはCDBレベルで restart に設定した ( Oracle Database 23ai 23.6以降はデフォルトが restart になっています ) ので再起動しても vector index (HNSW) はポピュレートされメモリー上に復活しているはず。。。という確認から。

[oracle@localhost ~]$ sudo service oracle stop
[sudo] oracle のパスワード:
Stopping oracle (via systemctl):  
                                                           [  OK  ]
[oracle@localhost ~]$ 
[oracle@localhost ~]$ sudo service oracle start
Starting oracle (via systemctl):  
                                                           [  OK  ]
[oracle@localhost ~]$ 
[oracle@localhost ~]$ sqlplus scott@localhost:1521/freepdb1

...略...

Oracle Database 23ai Free Release 23.0.0.0.0 - Develop, Learn, and Run for Free
Version 23.4.0.24.05
に接続されました。
SCOTT@localhost:1521/freepdb1> @show_vector_mem_pool    

POOL                       ALLOC_BYTES USED_BYTES POPULATE_STATUS
-------------------------- ----------- ---------- --------------------------
1MB POOL                     369098752  236978176 DONE
64KB POOL                    150994944    2686976 DONE
IM POOL METADATA              16777216   16777216 DONE

経過: 00:00:00.05
SCOTT@localhost:1521/freepdb1> @show_vector_segments

       OBJ   MEMBYTES
---------- ----------
         0     131072
     80126  239534080

経過: 00:00:00.02

それぞれの実行計画のpros/consはマニュアルで読んでもらうとして、
VECTOR INDEX HNSW SCAN PRE-FILTER WITH JOIN BACKから診てみましょう。

JOIN BACKするかしないかの違いは最後にもう一度ベース表をアクセスするかどうか。（次の実行計画で言うと、Id=5でSEARCH_DATAをtable access by index rowidでアクセスしている箇所がJOIN BACK)
これらのバリエーションはデータ量とフィルタリング量との兼ね合いになるのでベクトル索引で近傍検索の実行計画をヒントで固定化するのは比較的難易度が高そう（どちらの傾向に固定した方が良いかの判断は難しい）だろうな、と思っているところ。固定できるか、したほうが良いかの見極めというか、割り切りなのかもしれないが決め打ちするだけの情報は揃えた上で決める必要はりそう。最初は経過観察なのが良いだろうと思っているところだが。。。とはいえ、覚えていて損ないかなぁ。

また、これらのバリエーションでは、VECTOR INDEX (HNSW)以外に、補助表の主役であるMAP表が登場します（Id=9の部分)。
VECTOR INDEX (HNSW)本体だけでなく補助表の存在も把握しておくことが大切な理由はここにもあります。（ベース表に比べるとサイズは小さいわけですが）

後半で別途まとめますが、この実行では内部ビューが新たに作られています。
Id=7の VW_HPJ_91CF1FF7 がそれです。内部的に作成されるビューにはそれぞれのトランスフォームに関連する短縮名が付与されるのが、これまでのOracle Databaseのオプティマイザのお約束ですね。
VW_HPJ_、 Hnsw scan Pre-filter with Join back -> HPJ になりそうですよね。 VW_HPJ_という内部ビューをみたらVECTOR_INDEX_TRANSFORM VECTOR INDEX HNSW SCAN PRE_FILTER WITH JOIN BACKが行われていると考えてよいでしょうね。

SELECT
  /*+
    GATHER_PLAN_STATISTICS
  */
  id
  , description
  , community
  , location_desc
  , district
  , TO_NUMBER( v_distance ) AS v_distance
FROM
(
  SELECT
    /*+ 
      VECTOR_INDEX_TRANSFORM(search_data search_data_hnsw_ix pre_filter_with_join_back)
    */
    id
    , description
    , community
    , location_desc
    , district
    , VECTOR_DISTANCE
      (
        vector_desc
        , VECTOR_EMBEDDING
         (
           all_minilm_l6 USING 'Incident in which someone may have been murdered' AS data
         )
      , COSINE
    ) v_distance
  FROM
    search_data
  WHERE
    community = 'AUSTIN'
  ORDER BY
    v_distance
  FETCH APPROX FIRST 20 ROWS ONLY
)
/


Plan hash value: 3994424349

--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
| Id  | Operation                              | Name                                                        | Starts | E-Rows |E-Bytes|E-Temp | Cost (%CPU)| E-Time   | A-Rows |   A-Time   | Buffers | Reads  |  OMem |  1Mem | Used-Mem |
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                       |                                                             |      1 |        |       |       |  6649 (100)|          |     20 |00:00:00.93 |     412 |    410 |       |       |          |
|   1 |  VIEW                                  |                                                             |      1 |      1 |   157 |       |  6649   (1)| 00:00:01 |     20 |00:00:00.93 |     412 |    410 |       |       |          |
|*  2 |   COUNT STOPKEY                        |                                                             |      1 |        |       |       |            |          |     20 |00:00:00.93 |     412 |    410 |       |       |          |
|   3 |    VIEW                                |                                                             |      1 |      1 |   157 |       |  6649   (1)| 00:00:01 |     20 |00:00:00.93 |     412 |    410 |       |       |          |
|*  4 |     SORT ORDER BY STOPKEY              |                                                             |      1 |      1 |  1665 |       |  6649   (1)| 00:00:01 |     20 |00:00:00.93 |     412 |    410 |  4096 |  4096 | 4096  (0)|
|*  5 |      TABLE ACCESS BY INDEX ROWID       | SEARCH_DATA                                                 |      1 |      1 |  1665 |       |  6648   (1)| 00:00:01 |     20 |00:00:00.94 |     412 |    410 |       |       |          |
|   6 |       VECTOR INDEX HNSW SCAN PRE-FILTER| SEARCH_DATA_HNSW_IX                                         |      1 |      1 |  1665 |       |  6648   (1)| 00:00:01 |     20 |00:00:00.93 |     392 |    390 |       |       |          |
|   7 |        VIEW                            | VW_HPJ_91CF1FF7                                             |      1 |   6235 |   152K|       |  6647   (1)| 00:00:01 |   6235 |00:00:00.06 |     392 |    390 |       |       |          |
|*  8 |         HASH JOIN RIGHT OUTER          |                                                             |      1 |   6235 |     9M|  3296K|  6647   (1)| 00:00:01 |   6235 |00:00:00.06 |     392 |    390 |  8506K|  2096K| 9004K (0)|
|   9 |          TABLE ACCESS FULL             | VECTOR$SEARCH_DATA_HNSW_IX$78074_80224_0$HNSW_ROWID_VID_MAP |      1 |    125K|  1831K|       |   102   (0)| 00:00:01 |    125K|00:00:00.01 |     373 |    371 |       |       |          |
|* 10 |          INDEX RANGE SCAN              | SEARCH_DATA_COMMNITY_IX                                     |      1 |   6235 |       |       |    23   (0)| 00:00:01 |   6235 |00:00:00.01 |      19 |     19 |       |       |          |
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Query Block Name / Object Alias (identified by operation id):
-------------------------------------------------------------

   1 - SEL$3        / "from$_subquery$_001"@"SEL$1"
   2 - SEL$3
   3 - SEL$7185E227 / "from$_subquery$_003"@"SEL$3"
   4 - SEL$7185E227
   5 - SEL$7185E227 / "SEARCH_DATA"@"SEL$2"
   6 - SEL$7185E227 / "SEARCH_DATA"@"SEL$2"
   7 - SEL$BF33016E / "VW_HPJ_91CF1FF7"@"SEL$2"
   8 - SEL$BF33016E
   9 - SEL$BF33016E / "VTIX_RIDVID"@"SEL$2"
  10 - SEL$BF33016E / "SEARCH_DATA"@"SEL$2"

...略...

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

   2 - filter(ROWNUM<=20)
   4 - filter(ROWNUM<=20)
   5 - filter("SEARCH_DATA"."COMMUNITY"='AUSTIN')
   8 - access("SEARCH_DATA".ROWID="VTIX_RIDVID"."BASE_TABLE_ROWID")
  10 - access("SEARCH_DATA"."COMMUNITY"='AUSTIN')

...略...

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

  10 -  SEL$BF33016E / "SEARCH_DATA"@"SEL$2"
           -  VECTOR_INDEX_TRANSFORM(search_data search_data_hnsw_ix pre_filter_with_join_back)

次に、VECTOR INDEX HNSW SCAN PRE-FILTER WITHOUT JOIN BACKを診てみましょう。
違いは、JOIN BACKがないところですよね、ヒントの通りw。
実行計画のId=5でVECTOR INDEX HNSW SCAN PRE_FILTERが行われていますが、その後でベース表を再度アクセスすることはありません。
なお、今回の検索パターンだと join back したほうが多少軽めですよね。んーーー難しい。普段はオプティマイザにお任せのほうが良いかもなと思うわけです。よほどのことがない限り。はい。

ここでも、新たな内部ビュー、 VW_HPF_475999B9 が作成されています。 VW_HPF_、 Hnsw scan Pre-Filter without join back -> HPF でしょうか。ちょっとムズイw VW_HPF_内部ビューを見つけたら、VECTOR INDEX HNSW SCAN PRE-FILTER WITHOUT JOIN BACKが行われてると理解して良さそうです。

このケースでも補助表であるMAP表が登場します。なにこれ？　俺は作ってないぞ！　と驚かないようにしてくださいねw。（当ブログを読んだ方は驚くことはないはずですがw）
また、マニュアルにも記載されていますが、Hash join だけでなく Nested Loops Joinになることもあります。データ量と索引有無次第ではありますが、覚えておくと良いでしょう。（この例では Apaptive Planが選択されているため、どちらの結合方式になるかは、Join Cardinarity次第です）

SELECT
  /*+
    GATHER_PLAN_STATISTICS
  */
  id
  , description
  , community
  , location_desc
  , district
  , TO_NUMBER( v_distance ) AS v_distance
FROM
(
  SELECT
    /*+ 
      VECTOR_INDEX_TRANSFORM(search_data search_data_hnsw_ix pre_filter_without_join_back) 
    */
    id
    , description
    , community
    , location_desc
    , district
    , VECTOR_DISTANCE
      (
        vector_desc
        , VECTOR_EMBEDDING
         (
           all_minilm_l6 USING 'Incident in which someone may have been murdered' AS data
         )
      , COSINE
    ) v_distance
  FROM
    search_data
  WHERE
    community = 'AUSTIN'
  ORDER BY
    v_distance
  FETCH APPROX FIRST 20 ROWS ONLY
)
/


--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
|   Id  | Operation                                    | Name                                                        | Starts | E-Rows |E-Bytes| Cost (%CPU)| E-Time   | A-Rows |   A-Time   | Buffers | Reads  |  OMem |  1Mem | Used-Mem |
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
|     0 | SELECT STATEMENT                             |                                                             |      1 |        |       |  5998 (100)|          |     20 |00:00:02.77 |    5929 |   5904 |       |       |          |
|     1 |  VIEW                                        |                                                             |      1 |     20 |  3140 |  5998   (1)| 00:00:01 |     20 |00:00:02.77 |    5929 |   5904 |       |       |          |
|  *  2 |   COUNT STOPKEY                              |                                                             |      1 |        |       |            |          |     20 |00:00:02.77 |    5929 |   5904 |       |       |          |
|     3 |    VIEW                                      |                                                             |      1 |     20 |  3140 |  5998   (1)| 00:00:01 |     20 |00:00:02.77 |    5929 |   5904 |       |       |          |
|  *  4 |     SORT ORDER BY STOPKEY                    |                                                             |      1 |     20 | 35220 |  5998   (1)| 00:00:01 |     20 |00:00:02.77 |    5929 |   5904 |  4096 |  4096 | 4096  (0)|
|     5 |      VECTOR INDEX HNSW SCAN PRE-FILTER       | SEARCH_DATA_HNSW_IX                                         |      1 |     20 | 35220 |  5997   (1)| 00:00:01 |     20 |00:00:02.77 |    5929 |   5904 |  1278K|  1076K| 1175K (0)|
|     6 |       VIEW                                   | VW_HPF_475999B9                                             |      1 |   6235 |  1071K|  5996   (1)| 00:00:01 |   6235 |00:00:02.13 |    5914 |   5904 |       |       |          |
|  *  7 |        HASH JOIN OUTER                       |                                                             |      1 |   6235 |   499K|  5996   (1)| 00:00:01 |   6235 |00:00:02.13 |    5914 |   5904 |  1448K|  1287K| 1856K (0)|
|-    8 |         NESTED LOOPS OUTER                   |                                                             |      1 |   6235 |   499K|  5996   (1)| 00:00:01 |   6235 |00:00:10.37 |    5540 |   5533 |       |       |          |
|-    9 |          STATISTICS COLLECTOR                |                                                             |      1 |        |       |            |          |   6235 |00:00:10.36 |    5540 |   5533 |       |       |          |
|    10 |           TABLE ACCESS BY INDEX ROWID BATCHED| SEARCH_DATA                                                 |      1 |   6235 |   407K|  5893   (1)| 00:00:01 |   6235 |00:00:10.36 |    5540 |   5533 |       |       |          |
|  * 11 |            INDEX RANGE SCAN                  | SEARCH_DATA_COMMNITY_IX                                     |      1 |   6235 |       |    23   (0)| 00:00:01 |   6235 |00:00:00.01 |      19 |     19 |       |       |          |
|-   12 |          TABLE ACCESS BY INDEX ROWID         | VECTOR$SEARCH_DATA_HNSW_IX$78074_80224_0$HNSW_ROWID_VID_MAP |      0 |      1 |    15 |   102   (0)| 00:00:01 |      0 |00:00:00.01 |       0 |      0 |       |       |          |
|- * 13 |           INDEX UNIQUE SCAN                  | SYS_C0013920                                                |      0 |        |       |            |          |      0 |00:00:00.01 |       0 |      0 |       |       |          |
|    14 |         TABLE ACCESS FULL                    | VECTOR$SEARCH_DATA_HNSW_IX$78074_80224_0$HNSW_ROWID_VID_MAP |      1 |    125K|  1831K|   102   (0)| 00:00:01 |    125K|00:00:00.03 |     374 |    371 |       |       |          |
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Query Block Name / Object Alias (identified by operation id):
-------------------------------------------------------------

   1 - SEL$3        / "from$_subquery$_001"@"SEL$1"
   2 - SEL$3
   3 - SEL$2D1A9934 / "from$_subquery$_003"@"SEL$3"
   4 - SEL$2D1A9934
   5 - SEL$2D1A9934 / "SEARCH_DATA"@"SEL$2"
   6 - SEL$6D23FDEA / "VW_HPF_475999B9"@"SEL$475999B9"
   7 - SEL$6D23FDEA
   8 - SEL$6D23FDEA
  10 - SEL$6D23FDEA / "SEARCH_DATA"@"SEL$2"
  11 - SEL$6D23FDEA / "SEARCH_DATA"@"SEL$2"
  12 - SEL$6D23FDEA / "VTIX_RIDVID"@"SEL$EBB9871C"
  13 - SEL$6D23FDEA / "VTIX_RIDVID"@"SEL$EBB9871C"
  14 - SEL$6D23FDEA / "VTIX_RIDVID"@"SEL$EBB9871C"

...略...

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

   2 - filter(ROWNUM<=20)
   4 - filter(ROWNUM<=20)
   7 - access("SEARCH_DATA".ROWID="VTIX_RIDVID"."BASE_TABLE_ROWID")
  11 - access("SEARCH_DATA"."COMMUNITY"='AUSTIN')
  13 - access("SEARCH_DATA".ROWID="VTIX_RIDVID"."BASE_TABLE_ROWID")

...略...

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

  10 -  SEL$6D23FDEA / "SEARCH_DATA"@"SEL$2"
           -  VECTOR_INDEX_TRANSFORM(search_data search_data_hnsw_ix pre_filter_without_join_back)

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

次は、VECTOR INDEX TRANSFORM IN-FILTER WITH JOIN BACK これまでの PRE-FILTERではなく、IN-FILTER + JOIN BACKをヒントで強制しています

なお、マニュアルにも記載がありますが、In-filterの実行計画の読み方は少々癖があります！

Id=8の元表のアクセスを見てください！。いきなり、TABLE ACCESS BY USER ROWID で SEARCH_DATA 表をアクセスしています！！！
この実行計画の開始ポイントは、Id=8ではなく、Id=6の VECTOR INDEX HNSW SCAN IN-FILTER で、VECTOR INDEX (HNSW)である SEARCH_DATA_HNSW_IX 索引をトラバースしている部分です:)
Id=6で識別されたベクトルごとに、Id=8の元表に対応するrowidのフィルタが適用され、関連する列が抽出されます!!!!!!!

VECTOR INDEX TRANSFORMの時の実行計画の読み方は正しく覚えないと軽くハマりそうですねw 少々癖があるので覚えるしかないですよ！w（ここも試験にでるよ！！w しらんけど）

最後に、Id=5でJOIN BACKして、COUNT STOPKEYの操作へ遷移していきます！！！！

また、ここでも内部生成の新たなビューが登場しています。
VW_HIJ_ ですね。 HIJ -> Hnsw scan In-filter with Join back ということでしょうね。想像するに。　

SELECT
  /*+
    GATHER_PLAN_STATISTICS
  */
  id
  , description
  , community
  , location_desc
  , district
  , TO_NUMBER( v_distance ) AS v_distance
FROM
(
  SELECT
    /*+ 
      VECTOR_INDEX_TRANSFORM(search_data search_data_hnsw_ix in_filter_with_join_back) 
    */
    id
    , description
    , community
    , location_desc
    , district
    , VECTOR_DISTANCE
      (
        vector_desc
        , VECTOR_EMBEDDING
         (
           all_minilm_l6 USING 'Incident in which someone may have been murdered' AS data
         )
      , COSINE
    ) v_distance
  FROM
    search_data
  WHERE
    community = 'AUSTIN'
  ORDER BY
    v_distance
  FETCH APPROX FIRST 20 ROWS ONLY
)
/


-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
| Id  | Operation                             | Name                | Starts | E-Rows |E-Bytes| Cost (%CPU)| E-Time   | A-Rows |   A-Time   | Buffers | Reads  |  OMem |  1Mem | Used-Mem |
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                      |                     |      1 |        |       |     3 (100)|          |     20 |00:00:02.28 |    4725 |   4431 |       |       |          |
|   1 |  VIEW                                 |                     |      1 |      1 |   157 |     3  (34)| 00:00:01 |     20 |00:00:02.28 |    4725 |   4431 |       |       |          |
|*  2 |   COUNT STOPKEY                       |                     |      1 |        |       |            |          |     20 |00:00:02.28 |    4725 |   4431 |       |       |          |
|   3 |    VIEW                               |                     |      1 |      1 |   157 |     3  (34)| 00:00:01 |     20 |00:00:02.28 |    4725 |   4431 |       |       |          |
|*  4 |     SORT ORDER BY STOPKEY             |                     |      1 |      1 |  1652 |     3  (34)| 00:00:01 |     20 |00:00:02.28 |    4725 |   4431 |  4096 |  4096 | 4096  (0)|
|*  5 |      TABLE ACCESS BY INDEX ROWID      | SEARCH_DATA         |      1 |      1 |  1652 |     2   (0)| 00:00:01 |     20 |00:00:02.28 |    4725 |   4431 |       |       |          |
|   6 |       VECTOR INDEX HNSW SCAN IN-FILTER| SEARCH_DATA_HNSW_IX |      1 |      1 |  1652 |     2   (0)| 00:00:01 |     20 |00:00:02.28 |    4705 |   4423 |       |       |          |
|   7 |        VIEW                           | VW_HIJ_475999B9     |   4773 |      1 |       |     1   (0)| 00:00:01 |    265 |00:00:01.59 |    4705 |   4423 |       |       |          |
|*  8 |         TABLE ACCESS BY USER ROWID    | SEARCH_DATA         |   4773 |      1 |  1652 |     1   (0)| 00:00:01 |    265 |00:00:01.59 |    4705 |   4423 |       |       |          |
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Query Block Name / Object Alias (identified by operation id):
-------------------------------------------------------------

   1 - SEL$3        / "from$_subquery$_001"@"SEL$1"
   2 - SEL$3
   3 - SEL$79710E8E / "from$_subquery$_003"@"SEL$3"
   4 - SEL$79710E8E
   5 - SEL$79710E8E / "SEARCH_DATA"@"SEL$2"
   6 - SEL$79710E8E / "SEARCH_DATA"@"SEL$2"
   7 - SEL$860F096D / "VW_HIJ_475999B9"@"SEL$2"
   8 - SEL$860F096D / "SEARCH_DATA"@"SEL$2"

...略...

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

   2 - filter(ROWNUM<=20)
   4 - filter(ROWNUM<=20)
   5 - filter("SEARCH_DATA"."COMMUNITY"='AUSTIN')
   8 - filter("SEARCH_DATA"."COMMUNITY"='AUSTIN')

...略...

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

   8 -  SEL$860F096D / "SEARCH_DATA"@"SEL$2"
           -  VECTOR_INDEX_TRANSFORM(search_data search_data_hnsw_ix in_filter_with_join_back)

最後に、VECTOR INDEX TRANSFORM IN-FILTER WITHOUT JOIN BACK In-filtewrでJoin Backなしというタイプです。

このタイプがもっとも無駄がなさそうですね。今回の例で使っている検索パターンだと。。。:)

これもマニュアルの記述されているとおり、実行計画の開始位置にクセがあります。
Id=5の VECTOR INDEX HNSW SCAN IN-FILTER で、VECTOR INDEX (HNSW) をトラバースするところがスタートです。
次に、Id=7のベース表をVECTOR INDEXから取得したrowidでアクセス。
その後、COUNT STOPKEYの操作へ入ります。

そして、ここでも新顔の内部ビュー、 VW_HIF_ -> Hnsw scan In-Filter with join back ということで、 HIFになっていると思われます:)

SELECT
  /*+
    GATHER_PLAN_STATISTICS
  */
  id
  , description
  , community
  , location_desc
  , district
  , TO_NUMBER( v_distance ) AS v_distance
FROM
(
  SELECT
    /*+ 
      VECTOR_INDEX_TRANSFORM(search_data search_data_hnsw_ix in_filter_without_join_back) 
    */
    id
    , description
    , community
    , location_desc
    , district
    , VECTOR_DISTANCE
      (
        vector_desc
        , VECTOR_EMBEDDING
         (
           all_minilm_l6 USING 'Incident in which someone may have been murdered' AS data
         )
      , COSINE
    ) v_distance
  FROM
    search_data
  WHERE
    community = 'AUSTIN'
  ORDER BY
    v_distance
  FETCH APPROX FIRST 20 ROWS ONLY
 )
/


------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
| Id  | Operation                            | Name                | Starts | E-Rows |E-Bytes| Cost (%CPU)| E-Time   | A-Rows |   A-Time   | Buffers | Reads  |  OMem |  1Mem | Used-Mem |
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                     |                     |      1 |        |       |     3 (100)|          |     20 |00:00:00.52 |    4705 |    733 |       |       |          |
|   1 |  VIEW                                |                     |      1 |     20 |  3140 |     3  (34)| 00:00:01 |     20 |00:00:00.52 |    4705 |    733 |       |       |          |
|*  2 |   COUNT STOPKEY                      |                     |      1 |        |       |            |          |     20 |00:00:00.52 |    4705 |    733 |       |       |          |
|   3 |    VIEW                              |                     |      1 |     20 |  3140 |     3  (34)| 00:00:01 |     20 |00:00:00.52 |    4705 |    733 |       |       |          |
|*  4 |     SORT ORDER BY STOPKEY            |                     |      1 |     20 | 34960 |     3  (34)| 00:00:01 |     20 |00:00:00.52 |    4705 |    733 |  4096 |  4096 | 4096  (0)|
|   5 |      VECTOR INDEX HNSW SCAN IN-FILTER| SEARCH_DATA_HNSW_IX |      1 |     20 | 34960 |     2   (0)| 00:00:01 |     20 |00:00:00.52 |    4705 |    733 |   835K|   835K|  543K (0)|
|   6 |       VIEW                           | VW_HIF_475999B9     |   4773 |      1 |   151 |     1   (0)| 00:00:01 |    265 |00:00:00.02 |    4705 |    733 |       |       |          |
|*  7 |        TABLE ACCESS BY USER ROWID    | SEARCH_DATA         |   4773 |      1 |    67 |     1   (0)| 00:00:01 |    265 |00:00:00.02 |    4705 |    733 |       |       |          |
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Query Block Name / Object Alias (identified by operation id):
-------------------------------------------------------------

   1 - SEL$3        / "from$_subquery$_001"@"SEL$1"
   2 - SEL$3
   3 - SEL$81BAFB36 / "from$_subquery$_003"@"SEL$3"
   4 - SEL$81BAFB36
   5 - SEL$81BAFB36 / "SEARCH_DATA"@"SEL$2"
   6 - SEL$066A4CD4 / "VW_HIF_475999B9"@"SEL$475999B9"
   7 - SEL$066A4CD4 / "SEARCH_DATA"@"SEL$2"

...略...

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

   2 - filter(ROWNUM<=20)
   4 - filter(ROWNUM<=20)
   7 - filter("SEARCH_DATA"."COMMUNITY"='AUSTIN')

...略...

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

   7 -  SEL$066A4CD4 / "SEARCH_DATA"@"SEL$2"
           -  VECTOR_INDEX_TRANSFORM(search_data search_data_hnsw_ix in_filter_without_join_back)

まとめ VECTOR INDEX TRANSFORM の特徴

・VECTOR INDEX (HNSW)以外に、補助表であるMAP表が使われる（場合によってはその索引も）
・In-filter時の実行計画開始の開始ポイントに癖があるので要注意
・内部で生成されるビューがバリエーション分増加した

最後に、今回新たに登場した内部ビュー名と、これまでに把握されている内部ビューのまとめ。

VECTOR INDEX TRANSFORM

VW_HPJ_ / Hnsw scan Pre-filter with Join back
VW_HPF_ / Hnsw scan Pre-Filter with join back
VW_HIJ_ / Hnsw scan In-filter with Join back
VW_HIF_ / Hnsw scan In-Filter with join back

上記に加え以前からいくつかメジャーな内部生成ビューがまとめられていいます。覚えておくとなにが行われているか分かり易いと思いますよ。
Internal Views / Oracle Scratchpad / Jonathan Lewis

では、また！

Enjoin Execution Plans, SQLs, and AI Vector Search!

Related article on Mac De Oracle
実行計画は, SQL文のレントゲン写真だ！

投稿日時 2025年7月 4日 (金) 12時48分 Oracle, チューニング, FAQ, SQL, パフォーマンス, in-memory, VECTOR, AI, Oracle Database 23ai | 固定リンク | 0 | コメント (0)

2025年6月25日 (水)

VECTOR INDEX はどこ？、見積もりサイズだとそれなりのサイズだったのに... の謎を探るべく、我々は洞窟の奥へ向かった！(完結編)

Previously on Mac De Oracle
前回はVECTOR INDEX はどこ？、見積もりサイズだとそれなりのサイズだったのに... の謎を探るべく、我々は洞窟の奥へ向かった！(後編) でした。
謎は、ほぼ解決したかな？と、思ったのですが、モヤモヤは晴れずwww
ということで、完結編的な何か。という位置付けのまとめを書いておくことにしました。（なお、23.5以降VECTOR INDEX関連も機能追加があったり。。。まあ、追いかけるの大変です）

注）ちょい古いリリースなので最新リリースとは挙動など異なる点がある可能性がある点、ご了承ください

SCOTT@localhost:1521/freepdb1> select banner_full from v$version;

BANNER_FULL
--------------------------------------------------------------------------------
Oracle Database 23ai Free Release 23.0.0.0.0 - Develop, Learn, and Run for Free
Version 23.4.0.24.05

インメモリー近傍グラフ・ベクトル索引の特徴まとめ (的なもの)

インメモリー近傍グラフ・ベクトル索引は、ディクショナリービューからは、OBJECTでもSEGMENTも無い扱いになっているよう見えてしまう。
しかし、vecsys.vector$indexにリストされるOBJECT_IDは、*_OBJECTSと共通で、vecsys.vector$indexにはあるが、*_OBJECTS上はIDが欠番のように見える（後述）。無いけどあるみたいな不思議な扱いになっている。（今のところ）
なぜそうしたのだろう？....

Oraclerならお馴染みの *_OBJECTS　や　*_SEGMENTS　には現れないが、in-memory onlyのオブジェクトとして専用のプール上にポピューレートされた場合に存在している in-memory indexである。
（ここテストにでますよ。嘘w）

また、in-memory vector indexの補助表及び関連する索引はリストされる（セグメントサイズは、deferred segment creationであるものも含むため状況次第）
メモリー上とは言っても他と同じ扱いで、属性としてin-memory onlyのような列を追加すればよかったのでは？と、個人的には思っていたりする。。。

参考）
(上記の時事検証 23ai 23.4で行ったため、最新のリリースとは差異がある可能性があり、気づいた差分について随時補足追記してあります)
作成したin-memory vector index ( SEARCH_DATA_HNSW_IX ) の IDX_OBJN(列名の短縮系も*_OBJECTSで利用されているOBJECT_IDとな異なり、IDX_OBJN ( N は Numberの略と思われる) という、いわゆるシノニムになってしまっている（この点も状況をわかりにくくしている原因でしょうね。Oraclerじゃない方が作ったような違和感を感じる）

SCOTT@localhost:1521/freepdb1> select idx_objn, idx_name from vecsys.vector$index;

  IDX_OBJN IDX_NAME
---------- -------------------------------
     80113 SEARCH_DATA_HNSW_IX

で、この IDX_OBJN = OBJECT_ID ( *_OBJECTS で使われている　）、いきなりシノニムになってる！　と仮説をたて UESR_OBJECTSを検索してみると、存在しない！　（何ぃ〜〜〜っ！）
ちがうのか？（*_OBJECTSにはリストされないだけで、採番元は同じなので、はやり仮説は正しかったw。後述）

SCOTT@localhost:1521/freepdb1> select object_name,object_type from user_objects where object_id = 80113;

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

念の為、data_object_idでも検索してみる（こちらにもないですよねーw）

SCOTT@localhost:1521/freepdb1> select object_name,object_type from user_objects where data_object_id = 80113;

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

USER_SEGMENTSをVECTOR INDEX NAMEで検索してみるがやはり無い。ストレージ上のデータをそのままインメモリー化しているわけではないいうことだろうと想像するが。ではメモリー上の情報は。。。

SCOTT@localhost:1521/freepdb1> select segment_name from user_segments where segment_name = 'SEARCH_DATA_HNSW_IX';

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

VECTOR INDEXとしては、 *_INDEXES から確認は可能であるが”！。。。

SCOTT@localhost:1521/freepdb1> select index_name,index_type,table_name from user_indexes where table_name='SEARCH_DATA';

 INDEX_NAME                     INDEX_TYPE                  TABLE_NAME
------------------------------ --------------------------- ------------------------------
SYS_IL0000078074C00009$$       LOB                         SEARCH_DATA
SEARCH_DATA_HNSW_IX            VECTOR                      SEARCH_DATA

in-memory vector indexはSGA上の専用メモリープール上に造られる。
では、v$vector_memory_poolからポピュレートされていることを確認。

SCOTT@localhost:1521/freepdb1> l
  1  SELECT
  2    pool
  3    , alloc_bytes
  4    , used_bytes
  5    , populate_status
  6  FROM
  7*   v$vector_memory_pool
SCOTT@localhost:1521/freepdb1> /

POOL                       ALLOC_BYTES USED_BYTES POPULATE_STATUS
-------------------------- ----------- ---------- --------------------------
1MB POOL                     369098752  236978176 DONE
64KB POOL                    150994944    2686976 DONE
IM POOL METADATA              16777216   16777216 DONE

ちなみに、vector indexがポピュレートされる前の状態は以下。1MB/64KB Poolが消費されたことがわかります。つまり、236,978,176 + 2,686,976 = 239,665,152 = 228.6MB

POOL                       ALLOC_BYTES USED_BYTES POPULATE_STATUS
-------------------------- ----------- ---------- --------------------------
1MB POOL                     369098752          0 DONE
64KB POOL                    150994944          0 DONE
IM POOL METADATA              16777216   16777216 DONE

in-memory vector indexのメモリセグメントの詳細を確認するには　v$vector_mem_segments_detail　を参照する。vecsys.vector$indexのidx_objnにリストされていた 80113 が 239MB　程度使用されていることがわかる。
（このサイズ、覚えておいてくださいね。後で使います。 239,534,080 = 228.4MB）

SCOTT@localhost:1521/freepdb1> l
  1  SELECT
  2    obj
  3    , membytes
  4  FROM
  5*   v$vector_mem_segments_detail
SCOTT@localhost:1521/freepdb1> /

       OBJ   MEMBYTES
---------- ----------
         0     131072
     80113  239534080

in-memory vector index (HNSW)の補助表と関連索引の object_id を見てみましょう。
vecsys.vector$indexでは、idx_objn となっていた列の値と連続していること点が確認できます。つまり、object_id　を採番しているシーケンスを利用している。。。in-memory vector index (HNSW) も *_OBJECTSに含まれている扱い。。。だが、*_objectsには含まれていません！！！！

CREATE VECTOR INDEXで作成された、in-memory vector index（ SEARCH_DATA_HNSW_IX ）の idx_objn = 80113 , その後に作成される補助表及び索引の *_objects.object_id　は、80114 以降が採番されています。
かつ、80113 という object_id は、*_objects にはリストされず。
妙ですよね。内部的には *_objectsに含まれていてもおかしくないと思われる扱いにであるかのように見えますよね。うーーむ。

SCOTT@localhost:1521/freepdb1> l
  1  WITH
  2    vector_idx_auxiliary_tables
  3    AS (
  4      SELECT
  5       idx_name AS vector_index_name
  6       , REPLACE(aux_table_name,'"','') AS aux_table_name
  7      FROM
  8      (
  9          SELECT
 10            vvi.idx_name AS idx_name
 11            ,vvi.idx_auxiliary_tables.rowid_vid_map_name
 12            ,vvi.idx_auxiliary_tables.shared_journal_transaction_commits_name
 13            ,vvi.idx_auxiliary_tables.shared_journal_change_log_name
 14          FROM
 15            vecsys.vector$index vvi
 16      ) objs
 17      UNPIVOT (
 18        aux_table_name FOR related_obj_name IN
 19        (
 20          rowid_vid_map_name
 21          , shared_journal_transaction_commits_name
 22          , shared_journal_change_log_name
 23        )
 24      )
 25    )
 26  SELECT
 27    object_id
 28  ,object_name
 29  ,object_type
 30  FROM
 31    user_objects
 32  WHERE
 33    object_name in (
 34  SELECT
 35    aux_table_name AS segment_name
 36  FROM
 37    vector_idx_auxiliary_tables
 38  WHERE
 39    vector_idx_auxiliary_tables.vector_index_name = 'SEARCH_DATA_HNSW_IX'
 40  UNION ALL
 41  SELECT
 42    index_name AS segment_name
 43  FROM
 44    user_indexes
 45  WHERE
 46    EXISTS
 47    (
 48       SELECT
 49         1
 50       FROM
 51         vector_idx_auxiliary_tables
 52       WHERE
 53         vector_idx_auxiliary_tables.aux_table_name = user_indexes.table_name
 54         AND vector_idx_auxiliary_tables.vector_index_name = 'SEARCH_DATA_HNSW_IX'
 55    )
 56* )
SCOTT@localhost:1521/freepdb1> /

 OBJECT_ID OBJECT_NAME                                                                                                                      OBJECT_TYPE
---------- -------------------------------------------------------------------------------------------------------------------------------- -----------------------
     80114 VECTOR$SEARCH_DATA_HNSW_IX$78074_80113_0$HNSW_ROWID_VID_MAP                                                                      TABLE
     80115 SYS_C0013840                                                                                                                     INDEX
     80117 VECTOR$SEARCH_DATA_HNSW_IX$78074_80113_0$HNSW_SHARED_JOURNAL_TRANSACTION_COMMITS                                                 TABLE PARTITION
     80116 VECTOR$SEARCH_DATA_HNSW_IX$78074_80113_0$HNSW_SHARED_JOURNAL_TRANSACTION_COMMITS                                                 TABLE
     80118 PK_XID_80113                                                                                                                     INDEX
     80120 VECTOR$SEARCH_DATA_HNSW_IX$78074_80113_0$HNSW_SHARED_JOURNAL_CHANGE_LOG                                                          TABLE PARTITION
     80119 VECTOR$SEARCH_DATA_HNSW_IX$78074_80113_0$HNSW_SHARED_JOURNAL_CHANGE_LOG                                                          TABLE
     80124 SYS_IL0000080119C00007$$                                                                                                         INDEX PARTITION
     80123 SYS_IL0000080119C00007$$                                                                                                         INDEX

9行が選択されました。

SCOTT@localhost:1521/freepdb1> l
  1 select object_id, data_object_id from user_objects where object_name = 'SEARCH_DATA'
SCOTT@localhost:1521/freepdb1> /

 OBJECT_ID DATA_OBJECT_ID
---------- --------------
     78074          78796

ここまでで、in-memory vector indexはどこ？
って話の場所的なところは見切れたかなと思いますが、
もう一つ、explain plan for create vector index及び、dbms_space.create_index_costプロシージャでの見積もりサイズは、信じて良いのか？、よくないのか？

エラーにはなってないが、信用してよいのだろうか。。。
ちなみに、23.6以降だが、INDEX_VECTOR_MEMORY_ADVISORプシージャによりインメモリーサイズを見積もることができるようになった。とか。。。すぐには用意できないのでw 23.4で一旦確認してみる

CREATE VECTOR INDEXで作成されるINMEMORYの索引オブジェクトに加え、補助表とよばれる表が複数存在する。未検証だが変更をトラックするタイプの補助表は更新量によってはセグメントサイズが一時的に増加する可能性あり

変更をトラッキングするのための2つのパーティション表と関連索引に関しては変更が無い限りセグメントは作成されない。はず。（deferred segment creationになっているようなので）
つまり新規作成時にはオブジェクトとしては存在するものの、セグメントは存在しない。
ということは、残る一つの補助表（仮でMAP表と呼ぶことにする）とその索引はある程度のセグメントを保持することになるだろうと予想。
また、インメモリー索引自体はベース表のVECTOR列のサイズに依存するのではないだろうか。。。と。

とりあえず、補助表のセグメントサイズを改めて確認してみる（in-memory vector index を何度かdrop/createしていためセグメント名に含まれるobject_idが異なりますが気になさらず。。）
今回のケース 125,000行のデータでは合計で 9MB 程度です。誤差の範囲程度のサイズではあります。ではメモリ上のサイズを占めるデータのベースとなる表のセグメントサイズも今一度確認しておきましょう。

SEGMENT_NAME                                                                     SEGMENT_TYPE               MB
-------------------------------------------------------------------------------- ------------------ ----------
VECTOR$SEARCH_DATA_HNSW_IX$78074_79519_0$HNSW_ROWID_VID_MAP                      TABLE                       3
SYS_C0013800                                                                     INDEX                       6

VECTORデータ型の列以外もありますが、ベース表のセグメントサイズは、 249MB あります。。。おやおや、サイズ、近似してますよね。。

SCOTT@localhost:1521/freepdb1> r
  1* select segment_name,segment_type,bytes / 1024 /1024 "MB" from user_segments where segment_name = 'SEARCH_DATA'

SEGMENT_NAME                   SEGMENT_TYPE               MB
------------------------------ ------------------ ----------
SEARCH_DATA                    TABLE                     248

もう少しベース表のセグメントサイズを調べてみましょう。

SCOTT@localhost:1521/freepdb1> l
  1  create table search_data_without_vector_desc
  2  as
  3  select
  4    id
  5    ,primary_description
  6    ,description
  7    ,location_desc
  8    ,district
  9    ,ward
 10    ,community
 11    ,c_year
 12* from search_data
SCOTT@localhost:1521/freepdb1> /

表が作成されました。

SCOTT@localhost:1521/freepdb1> exec dbms_stats.gather_table_stats(ownname=>'SCOTT',tabname=>upper('search_data_without_vector_desc'),cascade=>true,no_invalidate=>false);

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

おお、10MBなので、VECTORデータ型の列を含むSEARCH_DATA表のVECTORデータ型部分のサイズは、238MB　程度みたいですね。むむむ。。。

SCOTT@localhost:1521/freepdb1> r
  1  select
  2    segment_name
  3    ,segment_type
  4    ,bytes / 1024 /1024 "MB"
  5  from
  6    user_segments
  7  where
  8*   segment_name = upper('search_data_without_vector_desc')

SEGMENT_NAME                    SEGMENT_TYPE               MB
------------------------------- ------------------ ----------
SEARCH_DATA_WITHOUT_VECTOR_DESC TABLE                      10

in-memory vector index (HNSW)のメモリー消費サイズは、　228.4MB
（これに、補助表のMAP表と索引のセグメントサイズ 9MB を加算すると、237.4MB　おおおおおおおおーっ）

ベース表のVECTORデータ型だけのセグメントサイズは、238MB　

で、ですねぇ〜、EXPLAIN PLAN FOR CREATE VECTOR INDEX ...の見積もりサイズと、DBMS_SPACE.CREATE_INDEX_COSTプロシージャによる見積もり。。。VECTOR INDEXに対応できているという情報は未確認のままですが。。。

EXPLAIN PLAN FOR CREATE VECTOR INDEX ...
- estimated index size: 293M bytes

DBMS_SPACE.CREATE_INDEX_COSTプロシージャによるセグメントサイズ見積もり...
Segment Size (MB) :280

という結果になりました。偶然近い値だったの？？。。ということでもなさそうな気はします。。

ただし、ストレージのセグメントサイズではなくて、VECTOR MEMORY AREAで消費される索引サイズの見積もりとして....

みなさんは、どう思います？？？？

おまけの疑問というか違和感（これまでも少しだけ触れたが、妙な違和感がある）

これまでのIN-MEMORYとはことなり、VECTOR INDEX (HNSW)の場合、実行計画のオペレーション ( VECTOR INDEX HNSW SCAN ) には、INMEMORYというワードが含まれず勘違いしやすい気がするのに、
なぜ？ INMEMORYを含めなかったのだろう。また、*_OBJECTS/*_SEGMENTSを使わず、OBJECT_IDをIDX_OBJNというシノニムまで作り、vecsys.vector$index　で別管理かつ、補助表をJSONに書き込んでいる。
SQL文面倒なんすけど。。というのとこれまでの*_OBJECTSの存在と、vecsys.vector$indexのidx_objnの分離（*_objectsのobject_idの採番と同じなのに。。）といい、これまでと違う空気感が強い。

少し調べたのですが、
以下メッセージからも読み取れるように　INMEMORY というワードは、Oracle Database上、In-Memory Column Store Architectureをイメージさせるものではないことは確かようだ、
では、なぜ、INMEMORYというキーワードを実行計画のオペレーション名に含めなかった理由は少々理解しにくい。INMEMORY VECTOR INDEX HNSW SCANのほうがイメージしやすいと思うのは私だけだろうか。。。
このフワフワしてるところが違和感の原因でもあるな。。。

ORA-51815
INMEMORY NEIGHBOR GRAPH HNSW vector index snapshot is too old.
Oracle Database 23ai / Error Messages Oracle Database / Database Error Messages / ORA-51815

最後に、vector_index_neighbor_graph_reload を restartにすると再ロードされるよ（scope=bothでspfileにも同時に反映できるよ！）

23.4までは初期化パラメータ vector_index_neighbor_graph_reload のデフォルトが OFF であった。
インスタンス再起動で VECTOR INDEX (HNSW) がインメモリー上に再作成されない！！！w（なんだとーーー！）
23.6以降では、デフォルトが変更になり、 restart がデフォルトになっています。ここ試験にでるよ（知らんけどw

おまけに、ADB-Sだと、V$VECTOR_INDEXなんてビューが提供されていたり。。。なぜ全てで提供しないのだろう。。。23.4だからって話でもなさそうで。。

関連するディクショナリービューなどが整備されてないように見える（今後整備されるような気はする）。対応しきれていない部分はJSON化して回避しているようにも見える（やめて〜〜w）

ということで、最終的な私の理解のビジュアル化w 2025/6/25時点、かつ、Oracle Database 23ai 23.4 を元にした理解は以下の通り（まだ理解不足な箇所はあるかもしれない）

なお、
DBMS_VECTOR.GET_INDEX_STATUSプロシージャが返すステータスをみると興味深い内容が載っている
Oracle Database 23 / Oracle AI Vector Search User's Guide / Vector Index Status, Checkpoint, and Advisor Procedures / GET_INDEX_STATUS

CREATE VECTOR INDEX (HNSW)に関する状態を取得するプロシージャが返すステータスには以下のように記載されている。In-memory vector index (HNSW)のDDL発行からvector memory poolにロードされ、multi-layered HNSW graphができあがるまでのステータスがわかります！！！

そしてここでも、なんでプロシージャ必要だったのだろう。。。。と、言う素朴な疑問が！！！

Oracle Databaseには昔から、V$SESSION_LONGOPSってビューがあって。。。。
長時間操作のステータスがわかるようになっているのだが.....

ますます、なぜ、これまでの機能やビューを有効に再利用していないのだろう。。。という点が気になる...。が、現状は見切れたかな、と。
（もう一つのVector Indexのタイプと更新トラッキングと反映、いくつかの実行計画パターンの確認を除く）

HNSW Index Initialization
Initialization phase for the HNSW vector index creation

HNSW Index Auxiliary Tables Creation
Creation of the internal auxiliary tables for the HNSW Neighbor Graph vector index

HNSW Index Graph Allocation
Allocation of memory from the vector memory pool for the HNSW graph

HNSW Index Loading Vectors
Loading of the base table vectors into the vector pool memory

HNSW Index Graph Construction
Creation of the multi-layered HNSW graph with the previously loaded vectors

HNSW Index Creation Completed
HNSW vector index creation finished

では、また。

Enjoy SQL! and AI vector search!

・Oracle Database 23ai freeで試すVector Search - ONNXモデル準備編
・Oracle Database 23ai freeで試すVector Search - データ準備編
・実行計画は, SQL文のレントゲン写真だ！ No.66 / AI Vector Search - VECTOR INDEX HNSW SCAN
・VECTOR INDEX はどこ？、見積もりサイズだとそれなりのサイズだったのに... の謎を探るべく、我々は洞窟の奥へ向かった！(前編)
・VECTOR INDEX はどこ？、見積もりサイズだとそれなりのサイズだったのに... の謎を探るべく、我々は洞窟の奥へ向かった！(後編)

投稿日時 2025年6月25日 (水) 00時00分 Oracle, FAQ, SQL, in-memory, INDEX, Oracle Database 23c Free Developer Release, JSON, VECTOR, AI | 固定リンク | 0 | コメント (0)

2025年6月18日 (水)

VECTOR INDEX はどこ？、見積もりサイズだとそれなりのサイズだったのに... の謎を探るべく、我々は洞窟の奥へ向かった！(後編)

Previously on Mac De Oracle
前回は、VECTOR INDEX はどこ？、見積もりサイズだとそれなりのサイズだったのに... の謎を探るべく、我々は洞窟の奥へ向かった！(前編) でした。
今日はその後編です。

10046トレースよりVECTOR INDEX（HNSW）作成では前回の通り、補助表3つ（うち2つは変更をトラックするためなので作成直後は空）、それらの表に加え、各1つの索引が作成されるということがハッキリしました。
ただ、VECTOR INDEXの補助表はvecsys.vector$indexという表にJSONとして保持されている点と、USER_INDEXESから確認できるVECTOR INDEX自体は実態を持たない、さらに、Oraclerにはお馴染みの*_INDEXESなどから単純に取得できないことも見えてきました（今後もっと便利になることを期待したいですね）

(2025/6/18追記)
これ、HNSWってインメモリーと言っても、元ネタは永続化されているわけで、それをメモリープールにポピュレートしてるって理解（間違ってないとは思うけど、違ってたらコメントもらえるとありがたいです）なので、後編ではそのあたりを見ておこうかと。。。
インメモリー近傍グラフ・ベクトル索引

(作成される補助表の名称にVECTOR INDEXのベース表の名称が入っているようなので中間一致で検索していますが、これだとノイズも多くなるので検索キツイですよね。索引名はシステム生成名称なのでベース表の名称で中間一致検索はできません！。このケースに限ればなんとか拾えてるけどという感じではありますね。。。ということで後半ではJSONから引っこ抜いてなんとかするパズルもwやってますw)

SCOTT@localhost:1521/freepdb1> select index_name , table_name, index_type from user_indexes where table_name like '%SEARCH_DATA%';

INDEX_NAME                     TABLE_NAME                                                                       INDEX_TYPE
------------------------------ -------------------------------------------------------------------------------- ---------------------------
SYS_IL0000079525C00007$$       VECTOR$SEARCH_DATA_HNSW_IX$78074_79519_0$HNSW_SHARED_JOURNAL_CHANGE_LOG          LOB
SYS_IL0000078074C00009$$       SEARCH_DATA                                                                      LOB
SEARCH_DATA_HNSW_IX            SEARCH_DATA                                                                      VECTOR
SYS_C0013800                   VECTOR$SEARCH_DATA_HNSW_IX$78074_79519_0$HNSW_ROWID_VID_MAP                      NORMAL
PK_XID_79519                   VECTOR$SEARCH_DATA_HNSW_IX$78074_79519_0$HNSW_SHARED_JOURNAL_TRANSACTION_COMMITS NORMAL

SCOTT@localhost:1521/freepdb1> r
  1  SELECT
  2    idx_name
  3    ,(
  4       SELECT
  5         table_name
  6       FROM
  7         user_tables
  8       WHERE
  9         user_tables.table_name = (
 10           SELECT
 11             object_name
 12           FROM
 13             user_objects
 14           WHERE
 15             user_objects.object_id = vecsys.vector$index.idx_base_table_objn
 16        )
 17     ) AS tab_name
 18    ,JSON_SERIALIZE(
 19      idx_auxiliary_tables
 20      RETURNING VARCHAR2 PRETTY
 21    ) AS idx_auxiliary_tables
 22  FROM
 23    vecsys.vector$index
 24  WHERE
 25*   idx_name = 'SEARCH_DATA_HNSW_IX'

IDX_NAME                       TAB_NAME                       IDX_AUXILIARY_TABLES
------------------------------ ------------------------------ ----------------------------------------------------------------------------------------------------------------------------------
SEARCH_DATA_HNSW_IX            SEARCH_DATA                    {
                                                                "rowid_vid_map_objn" : 79520,
                                                                "shared_journal_transaction_commits_objn" : 79522,
                                                                "shared_journal_change_log_objn" : 79525,
                                                                "rowid_vid_map_name" : "VECTOR$SEARCH_DATA_HNSW_IX$78074_79519_0$HNSW_ROWID_VID_MAP",
                                                                "shared_journal_transaction_commits_name" : "VECTOR$SEARCH_DATA_HNSW_IX$78074_79519_0$HNSW_SHARED_JOURNAL_TRANSACTION_COMMITS",
                                                                "shared_journal_change_log_name" : "VECTOR$SEARCH_DATA_HNSW_IX$78074_79519_0$HNSW_SHARED_JOURNAL_CHANGE_LOG"
                                                              }

これまでの調査の結果、VECTOR INEDEX (HNSW) であるSEARCH_DATA_HNSW_IXはオブジェクトでもなく、セグメントもない（当然、シノニムにもなれない。仮にも索引ですから）
VECTOR INDEX (HNSW)の索引セグメントのサイズは、作成直後のIDX_AUXILIARY_TABLESと、索引があればそれら索引のセグメントサイズの合計ということになりますよね！！！
（やっと見えてきたw、なんなんだこれ）

こんな感じでJSONからIDX_AUXILIARY_TABLESにある関連表のオブジェクトID、または、テーブル名を取り出しUSER_INDEXESから索引も合わせて取得したうえで、それぞれのセグメントサイズの合計を取得すれば物理的なサイズは見えますよね。。。。（めんどくさいw）

SCOTT@localhost:1521/freepdb1> l
  1  WITH
  2    vector_idx_auxiliary_tables
  3    AS (
  4      SELECT
  5       idx_name AS vector_index_name
  6       , REPLACE(aux_table_name,'"','') AS aux_table_name
  7      FROM
  8      (
  9          SELECT
 10            vvi.idx_name AS idx_name
 11            ,vvi.idx_auxiliary_tables.rowid_vid_map_name
 12            ,vvi.idx_auxiliary_tables.shared_journal_transaction_commits_name
 13            ,vvi.idx_auxiliary_tables.shared_journal_change_log_name
 14          FROM
 15            vecsys.vector$index vvi
 16      ) objs
 17      UNPIVOT (
 18        aux_table_name FOR related_obj_name IN
 19        (
 20          rowid_vid_map_name
 21          , shared_journal_transaction_commits_name
 22          , shared_journal_change_log_name
 23        )
 24      )
 25    )
 26  SELECT
 27    aux_table_name AS segment_name
 28  FROM
 29    vector_idx_auxiliary_tables
 30  WHERE
 31    vector_idx_auxiliary_tables.vector_index_name = 'SEARCH_DATA_HNSW_IX'
 32  UNION ALL
 33  SELECT
 34    index_name AS segment_name
 35  FROM
 36    user_indexes
 37  WHERE
 38    EXISTS
 39    (
 40       SELECT
 41         1
 42       FROM
 43         vector_idx_auxiliary_tables
 44       WHERE
 45         vector_idx_auxiliary_tables.aux_table_name = user_indexes.table_name
 46         AND vector_idx_auxiliary_tables.vector_index_name = 'SEARCH_DATA_HNSW_IX'
 47    )
 48*
SCOTT@localhost:1521/freepdb1> /

SEGMENT_NAME
---------------------------------------------------------------------------------------
VECTOR$SEARCH_DATA_HNSW_IX$78074_79519_0$HNSW_ROWID_VID_MAP
VECTOR$SEARCH_DATA_HNSW_IX$78074_79519_0$HNSW_SHARED_JOURNAL_TRANSACTION_COMMITS
VECTOR$SEARCH_DATA_HNSW_IX$78074_79519_0$HNSW_SHARED_JOURNAL_CHANGE_LOG
SYS_C0013800
PK_XID_79519
SYS_IL0000079525C00007$$

6行が選択されました。

経過: 00:00:00.16

では、あらためて、EXPLAIN PLAN FOR CREATE VECTOR INDEX...の見積もりサイズと、実際のサイズを比較してみましょう!

SCOTT@localhost:1521/freepdb1> l
  1  explain plan for
  2  CREATE VECTOR INDEX search_data_hnsw_ix ON search_data ( vector_desc )
  3    ORGANIZATION
  4      INMEMORY NEIGHBOR GRAPH
  5      DISTANCE COSINE
  6*     WITH TARGET ACCURACY 90
SCOTT@localhost:1521/freepdb1> /

解析されました。

経過: 00:00:00.02
SCOTT@localhost:1521/freepdb1> @?/rdbms/admin/utlxpls

PLAN_TABLE_OUTPUT
-----------------------------------------------------------------------------------------------
Plan hash value: 2727344110

----------------------------------------------------------------------------------------------
| Id  | Operation              | Name                | Rows  | Bytes | Cost (%CPU)| Time     |
----------------------------------------------------------------------------------------------
|   0 | CREATE INDEX STATEMENT |                     |   125K|   188M| 14689   (1)| 00:00:01 |
|   1 |  VECTOR INDEX BUILD    | SEARCH_DATA_HNSW_IX |       |       |            |          |
----------------------------------------------------------------------------------------------

Note
-----
   - estimated index size: 293M bytes

なんどかコメントしてますが、SEARCH_DATA_HNSW_IXという索引セグメントは無く！、複数の補助表と索引群から構成されている。それらの作成直後のサイズは....

SCOTT@localhost:1521/freepdb1> r
  1  WITH
  2    vector_idx_auxiliary_tables
  3    AS (
  4      SELECT
  5       idx_name AS vector_index_name
  6       , REPLACE(aux_table_name,'"','') AS aux_table_name
  7      FROM
  8      (
  9          SELECT
 10            vvi.idx_name AS idx_name
 11            ,vvi.idx_auxiliary_tables.rowid_vid_map_name
 12            ,vvi.idx_auxiliary_tables.shared_journal_transaction_commits_name
 13            ,vvi.idx_auxiliary_tables.shared_journal_change_log_name
 14          FROM
 15            vecsys.vector$index vvi
 16      ) objs
 17      UNPIVOT (
 18        aux_table_name FOR related_obj_name IN
 19        (
 20          rowid_vid_map_name
 21          , shared_journal_transaction_commits_name
 22          , shared_journal_change_log_name
 23        )
 24      )
 25    )
 26  SELECT
 27    user_segments.segment_name
 28    , user_segments.segment_type
 29    , user_segments.bytes / 1024 / 1024 AS "MB"
 30  FROM
 31    user_segments
 32    INNER JOIN
 33    (
 34      SELECT
 35        aux_table_name AS segment_name
 36      FROM
 37        vector_idx_auxiliary_tables
 38      WHERE
 39        vector_idx_auxiliary_tables.vector_index_name = 'SEARCH_DATA_HNSW_IX'
 40      UNION ALL
 41      SELECT
 42        index_name AS segment_name
 43      FROM
 44        user_indexes
 45      WHERE
 46        EXISTS
 47        (
 48           SELECT
 49             1
 50           FROM
 51             vector_idx_auxiliary_tables
 52           WHERE
 53             vector_idx_auxiliary_tables.aux_table_name = user_indexes.table_name
 54             AND vector_idx_auxiliary_tables.vector_index_name = 'SEARCH_DATA_HNSW_IX'
 55        )
 56     ) vector_idx_aux_objects
 57     ON
 58       vector_idx_aux_objects.segment_name = user_segments.segment_name
 59*

SEGMENT_NAME                                                                     SEGMENT_TYPE               MB
-------------------------------------------------------------------------------- ------------------ ----------
VECTOR$SEARCH_DATA_HNSW_IX$78074_79519_0$HNSW_ROWID_VID_MAP                      TABLE                       3
SYS_C0013800                                                                     INDEX                       6

誤差が大きいですよね。正しく見積もれてない可能性が高いように思いますが、少なく出るよりマシ程度かもしれません。今後のチューニングに期待。。。。。というところでしょうか。。。

SCOTT@localhost:1521/freepdb1> l
  1  explain plan for
  2  CREATE VECTOR INDEX search_data_hnsw_ix ON search_data ( vector_desc )
  3    ORGANIZATION
  4      INMEMORY NEIGHBOR GRAPH
  5      DISTANCE COSINE
  6*     WITH TARGET ACCURACY 90
SCOTT@localhost:1521/freepdb1> /

だと、

- estimated index size: 293M bytes
ですが、
実際には以下の通り、　9M Bytes程度でした。
（もしかして、VECTOR INDEX　(HNSW)ってINMEMORYだからメモリーサイズ？　んなことないか、いや、あったりしてw　と思ったりし始めているw　 23ai 23.6では、DBMS_VECTOR.INDEX_VECTOR_MEMORY_ADVISORプロシージャによりメモリーサイズを見積もれるようになっていたりする。。怪しい。2025/6/19追記）

SEGMENT_NAME                                                                     SEGMENT_TYPE               MB
-------------------------------------------------------------------------------- ------------------ ----------
VECTOR$SEARCH_DATA_HNSW_IX$78074_79519_0$HNSW_ROWID_VID_MAP                      TABLE                       3
SYS_C0013800                                                                     INDEX                       6

Bツリー索引の見積り（19cで確かめたときは、これほど大きな差にはなっていませんでした）に比べると精度は低そうですよね。と言うより、VECTOR INDEXには対応できてないのかもしれませんね....

おまけで、
DBMS_SPACEパッケージの索引サイズ見積もりも試しておきましょう。。。。。やはり、explain plan for文同様にVECTOR INDEXのセグメントサイズ見積もりには対応してなさそう。（小さくでるわけではないのですがw）

SCOTT@localhost:1521/freepdb1> set serveroutput on
SCOTT@localhost:1521/freepdb1> l
  1  DECLARE
  2    used_bytes NUMBER;
  3    segment_bytes NUMBER;
  4  BEGIN
  5    DBMS_SPACE.CREATE_INDEX_COST (
  6      ddl=> 'CREATE VECTOR INDEX search_data_hnsw_ix ON search_data ( vector_desc )'
  7            || ' ORGANIZATION'
  8            || ' INMEMORY NEIGHBOR GRAPH'
  9            || ' DISTANCE COSINE'
 10            || ' WITH TARGET ACCURACY 90'
 11      , used_bytes => used_bytes
 12      , alloc_bytes =>  segment_bytes
 13    );
 14    DBMS_OUTPUT.PUT_LINE('Segment Size (MB) :'||segment_bytes/1024/1024);
 15    DBMS_OUTPUT.PUT_LINE('Index data Size (MB) :'||used_bytes/1024/1024);
 16* END;
SCOTT@localhost:1521/freepdb1> /
Segment Size (MB) :280
Index data Size (MB) :188.94672393798828125

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

Enjoy SQL, PL/SQL and VECTOR SEARCH!

VECTOR INDEXの謎はもう少し探る必要があるようだ...w (後編のおまけにつづくw）

めちゃ快適な気温の場所なので、
東京は猛暑と聞いて恐怖している

では、また。

参考）
今回利用したコードの一部

WITH
  vector_idx_auxiliary_tables
  AS (
    SELECT
     idx_name AS vector_index_name
     , REPLACE(aux_table_name,'"','') AS aux_table_name
    FROM
    (
        SELECT
          vvi.idx_name AS idx_name
          ,vvi.idx_auxiliary_tables.rowid_vid_map_name
          ,vvi.idx_auxiliary_tables.shared_journal_transaction_commits_name
          ,vvi.idx_auxiliary_tables.shared_journal_change_log_name
        FROM
          vecsys.vector$index vvi
    ) objs
    UNPIVOT (
      aux_table_name FOR related_obj_name IN
      (
        rowid_vid_map_name
        , shared_journal_transaction_commits_name
        , shared_journal_change_log_name
      )
    )
  )
SELECT
  aux_table_name AS segment_name
FROM
  vector_idx_auxiliary_tables
WHERE
  vector_idx_auxiliary_tables.vector_index_name = 'SEARCH_DATA_HNSW_IX'
UNION ALL
SELECT
  index_name AS segment_name
FROM
  user_indexes
WHERE
  EXISTS
  (
     SELECT
       1
     FROM
       vector_idx_auxiliary_tables
     WHERE
       vector_idx_auxiliary_tables.aux_table_name = user_indexes.table_name
       AND vector_idx_auxiliary_tables.vector_index_name = 'SEARCH_DATA_HNSW_IX'
  )
;

WITH
  vector_idx_auxiliary_tables
  AS (
    SELECT
     idx_name AS vector_index_name
     , REPLACE(aux_table_name,'"','') AS aux_table_name
    FROM
    (
        SELECT
          vvi.idx_name AS idx_name
          ,vvi.idx_auxiliary_tables.rowid_vid_map_name
          ,vvi.idx_auxiliary_tables.shared_journal_transaction_commits_name
          ,vvi.idx_auxiliary_tables.shared_journal_change_log_name
        FROM
          vecsys.vector$index vvi
    ) objs
    UNPIVOT (
      aux_table_name FOR related_obj_name IN
      (
        rowid_vid_map_name
        , shared_journal_transaction_commits_name
        , shared_journal_change_log_name
      )
    )
  )
SELECT
  user_segments.segment_name
  , user_segments.segment_type
  , user_segments.bytes / 1024 / 1024 AS "MB"
FROM
  user_segments
  INNER JOIN
  (
    SELECT
      aux_table_name AS segment_name
    FROM
      vector_idx_auxiliary_tables
    WHERE
      vector_idx_auxiliary_tables.vector_index_name = 'SEARCH_DATA_HNSW_IX'
    UNION ALL
    SELECT
      index_name AS segment_name
    FROM
      user_indexes
    WHERE
      EXISTS
      (
         SELECT
           1
         FROM
           vector_idx_auxiliary_tables
         WHERE
           vector_idx_auxiliary_tables.aux_table_name = user_indexes.table_name
           AND vector_idx_auxiliary_tables.vector_index_name = 'SEARCH_DATA_HNSW_IX'
      )
   ) vector_idx_aux_objects
   ON
     vector_idx_aux_objects.segment_name = user_segments.segment_name
;

set serveroutput on
DECLARE
  used_bytes NUMBER;
  segment_bytes NUMBER;
BEGIN
  DBMS_SPACE.CREATE_INDEX_COST (
    ddl=> 'CREATE VECTOR INDEX search_data_hnsw_ix ON search_data ( vector_desc )'
          || ' ORGANIZATION'
          || ' INMEMORY NEIGHBOR GRAPH'
          || ' DISTANCE COSINE'
          || ' WITH TARGET ACCURACY 90'
    , used_bytes => used_bytes
    , alloc_bytes =>  segment_bytes
  );
  DBMS_OUTPUT.PUT_LINE('Segment Size (MB) :'||segment_bytes/1024/1024);
  DBMS_OUTPUT.PUT_LINE('Index data Size (MB) :'||used_bytes/1024/1024);
END;
/

投稿日時 2025年6月18日 (水) 00時00分 Oracle, PL/SQL, チューニング, FAQ, SQL, パフォーマンス, in-memory, INDEX, Oracle Database 23c Free Developer Release, JSON, VECTOR, AI | 固定リンク | 0 | コメント (0)

2025年6月17日 (火)

VECTOR INDEX はどこ？、見積もりサイズだとそれなりのサイズだったのに... の謎を探るべく、我々は洞窟の奥へ向かった！(前編)

Previously on Mac De Oracle
前回は、実行計画は, SQL文のレントゲン写真だ！ No.66 / AI Vector Search - VECTOR INDEX HNSW SCANでした。
今日はそれに絡んで気づいたVECTOR INDEXの謎を追いかけてみることにします。

前回の最後の宿題というか謎の一つ目、覚えてますか？　　そう、VECTOR INDEXを作成後、まあよくある、USER_INDEXESを検索して作成されたVECTOR INDEXの名称を確認して、EXPLAIN PLAN FORで見積もった索引サイズとどの程度乖離しているのだろうと、手癖でUSER_SEGMENTSをアクセスしてみると、なな、なーーーーーんと、ない、無い！、なーーーい！。　（INMEMORYとはいっても元ネタがあってINMEMORY化されるわけで仕組み的に理解しにくいのと、これまでのディクショナリービューの使い方と異なっていてものすごく追いにくい）
なんで？　という謎。

SCOTT@localhost:1521/freepdb1> select index_name,index_type,table_name from user_indexes where table_name='SEARCH_DATA';

 INDEX_NAME                     INDEX_TYPE                  TABLE_NAME
------------------------------ --------------------------- ------------------------------
SYS_IL0000078074C00009$$       LOB                         SEARCH_DATA
SEARCH_DATA_HNSW_IX            VECTOR                      SEARCH_DATA

経過: 00:00:00.05
SCOTT@localhost:1521/freepdb1> select segment_name from user_segments where segment_name = 'SEARCH_DATA_HNSW_IX';

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

その後、アッ！　
いつもと違うビューがあったことを思い出し、覗いてみると、
作成したVECTOR INDEX (HNSW)の名称とともに、IDX_AUXILIARY_TABLES列（JSONデータ型）に、なにやらそれらしい値があるじゃありませんか！！！
そーなんだーーーーっ。VECTOR INDEXの名称は、VECTOR INDEXの補助表の集まりをまとめる為だけの存在？！！！
というところまででした。

SCOTT@localhost:1521/freepdb1> r
  1* SELECT * FROM vecsys.vector$index

  IDX_OBJN   IDX_OBJD IDX_OWNER# IDX_NAME                       IDX_BASE_TABLE_OBJN IDX_BASE_TABLE_OWNER# IDX_PARAMS                     IDX_AUXILIARY_TABLES           
---------- ---------- ---------- ------------------------------ ------------------- --------------------- ------------------------------ ------------------------------
     78797                   153 SEARCH_DATA_HNSW_IX                          78074                   153 {"type":"HNSW","num_neighbors" {"rowid_vid_map_objn":78798,"s
                                                                                                          :32,"efConstruction":200,"dist hared_journal_transaction_comm
                                                                                                          ance":"COSINE","accuracy":90," its_objn":78800,"shared_journa
                                                                                                          vector_type":"FLOAT32","vector l_change_log_objn":78803,"rowi
                                                                                                          _dimension":384,"degree_of_par d_vid_map_name":"VECTOR$SEARCH
                                                                                                          allelism":1,"pdb_id":3,"indexe _DATA_HNSW_IX$78074_78797_0$HN
                                                                                                          d_col":"VECTOR_DESC"}          SW_ROWID_VID_MAP","shared_jour
                                                                                                                                         nal_transaction_commits_name":
                                                                                                                                         "VECTOR$SEARCH_DATA_HNSW_IX$78
                                                                                                                                         074_78797_0$HNSW_SHARED_JOURNA
                                                                                                                                         L_TRANSACTION_COMMITS","shared
                                                                                                                                         _journal_change_log_name":"VEC
                                                                                                                                         TOR$SEARCH_DATA_HNSW_IX$78074_
                                                                                                                                         78797_0$HNSW_SHARED_JOURNAL_CH
                                                                                                                                         ANGE_LOG"}
                                                                                                                                         
SCOTT@localhost:1521/freepdb1> r
  1  SELECT
  2    JSON_SERIALIZE(idx_params RETURNING VARCHAR2 PRETTY) AS "INDEX PARAM"
  3    ,JSON_SERIALIZE(idx_auxiliary_tables RETURNING VARCHAR2 PRETTY) AS "INDEX AUX"
  4* FROM vecsys.vector$index

INDEX PARAM                                        INDEX AUX
-------------------------------------------------- --------------------------------------------------------------------------------------------------------------------------------------------
{                                                  {
  "type" : "HNSW",                                   rowid_vid_map_objn" : 78798,
  "num_neighbors" : 32,                              "shared_journal_transaction_commits_objn" : 78800,
  "efConstruction" : 200,                            "shared_journal_change_log_objn" : 78803,
  "distance" : "COSINE",                             "rowid_vid_map_name" : "VECTOR$SEARCH_DATA_HNSW_IX$78074_78797_0$HNSW_ROWID_VID_MAP",
  "accuracy" : 90,                                   "shared_journal_transaction_commits_name" : "VECTOR$SEARCH_DATA_HNSW_IX$78074_78797_0$HNSW_SHARED_JOURNAL_TRANSACTION_COMMITS",
  "vector_type" : "FLOAT32",                         "shared_journal_change_log_name" : "VECTOR$SEARCH_DATA_HNSW_IX$78074_78797_0$HNSW_SHARED_JOURNAL_CHANGE_LOG"
  "vector_dimension" : 384,                        }
  "degree_of_parallelism" : 1,
  "pdb_id" : 3,
  "indexed_col" : "VECTOR_DESC"
}

一旦ここまでの情報を整理すると

VECTOR INDEX（この例ではHNSW)の実態は、複数の補助表から構成されており、それらをまとめているのが作成時に指定したVECTOR INDEXの名称。
オブジェクトとしては存在しているが、それ自体は、セグメントを持たない!!!（IN MEMORY展開される索引だからとはいっても。。なにかしらあるのでは。。？）

現時点の23aiには、使い勝手の良いディクショナリービューは提供されていない。。。。まじか！

その代わりに、vecsys.vector$indexディクショナリー表（ビューではない）から詳細を追うことができる。（vecsysスキーマ）

さらに、補助表を見つけるためには、該当ディクショナリー表のIDX_AUXILIARY_TABLES列に格納されているJSONの*_objnや、補助表のオブジェクトID、*_nameから探れ！、と。
ようするに、このJSONに対象となるVECTOR INDEXとその実態の依存関係が入っている！！！！！
（ちなみに、表しかないが、おそらく、関連索引もありそうだ、というかあるだろうな。補助表の索引は補助表をキーにしてUSER_INDEXESから探すしかないだろうけども。）

ここまで見てきたところで、
めんどくせーーーーーーーーーーーーーっ！　なぜ、依存関係をJSONに突っ込んだの？。。。。という顔をしているところwwwww

そしてもう一つの謎、EXPLAIN PLAN FOR CREATE VECTOR INDEX ...foo bar ..として見積もられたVECTOR INDEXの見積もりサイズって、こいつら補助表含めた合計値？　
なのか？　　。。。だよなw 精度的に微妙な気がしなくも無い

全部かき集めて、合計して、見積もりサイズとの差分を見てみよう！
B*Treeの索引見積もりって、結構いい感じのサイズを弾き出してくれるわけだが。。。果たして。。。こいつは、どうなんだ？　SEARCH_DATA_HNSW_IXって実態持ってないし。。。

では、もっと探ってみなければw

そのまえに、CREATE VECTOR INDEXの謎を探るべくw
10046トレースで洞窟の奥に潜入することにします！　ww (わからなくなったら、これしかない！)

SCOTT@localhost:1521/freepdb1> desc search_data
 名前                                    NULL?    型
 ----------------------------------------- -------- ----------------------------
 ID                                                 NUMBER
 PRIMARY_DESCRIPTION                                VARCHAR2(40)
 DESCRIPTION                                        VARCHAR2(100)
 LOCATION_DESC                                      VARCHAR2(100)
 DISTRICT                                           VARCHAR2(30)
 WARD                                               NUMBER
 COMMUNITY                                          VARCHAR2(30)
 C_YEAR                                             NUMBER
 VECTOR_DESC                                        VECTOR(*, *)

SCOTT@localhost:1521/freepdb1> select count(*) from search_data

  COUNT(*)
----------
    125000

作成済みVECTOR INDEX (HNSW)を削除しておきます。

SCOTT@localhost:1521/freepdb1> drop index search_data_hnsw_ix;

索引が削除されました。

経過: 00:00:01.77

SCOTT@localhost:1521/freepdb1> select index_name , table_name, index_type from user_indexes where table_name like '%SEARCH_DATA%';

INDEX_NAME                     TABLE_NAME                     INDEX_TYPE
------------------------------ ------------------------------ ---------------------------
SYS_IL0000078074C00009$$       SEARCH_DATA                    LOB

SCOTT@localhost:1521/freepdb1> select table_name,column_name,segment_name,index_name from user_lobs where table_name like '%SEARCH_DATA%';

TABLE_NAME                     COLUMN_NAME                    SEGMENT_NAME                   INDEX_NAME
------------------------------ ------------------------------ ------------------------------ ------------------------------
SEARCH_DATA                    VECTOR_DESC                    SYS_LOB0000078074C00009$$      SYS_IL0000078074C00009$$

経過: 00:00:00.07

10046トレースの準備ができたので、トレースを設定しCREATE VECTOR INDEX文を実行して洞窟の奥へw

SCOTT@localhost:1521/freepdb1> show parameter timed_statistics

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
timed_statistics                     boolean     TRUE

SCOTT@localhost:1521/freepdb1> show parameter max_dump_file_size

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
max_dump_file_size                   string      32M
SCOTT@localhost:1521/freepdb1> alter session set max_dump_file_size = unlimited;

セッションが変更されました。

経過: 00:00:00.00
SCOTT@localhost:1521/freepdb1> show parameter tracefile_identifier

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
tracefile_identifier                 string
SCOTT@localhost:1521/freepdb1> alter session set tracefile_identifier = 'create_vector_index';

セッションが変更されました。

経過: 00:00:00.00
SCOTT@localhost:1521/freepdb1> alter session set events '10046 trace name context forever, level 12';

セッションが変更されました。

経過: 00:00:00.02
SCOTT@localhost:1521/freepdb1> l
  1  CREATE VECTOR INDEX search_data_hnsw_ix ON search_data ( vector_desc )
  2    ORGANIZATION
  3    INMEMORY NEIGHBOR GRAPH
  4    DISTANCE COSINE
  5*   WITH TARGET ACCURACY 90
SCOTT@localhost:1521/freepdb1> /

索引が作成されました。

経過: 00:00:39.24
SCOTT@localhost:1521/freepdb1> alter session set events '10046 trace name context off';

セッションが変更されました。

経過: 00:00:00.01

...略...

[oracle@localhost ~]$ echo $ORACLE_BASE
/opt/oracle
[oracle@localhost ~]$ cd $ORACLE_BASE/diag/rdbms/free/FREE/trace
[oracle@localhost trace]$ pwd
/opt/oracle/diag/rdbms/free/FREE/trace
[oracle@localhost trace]$ 
[oracle@localhost trace]$ ll *create_vector_index*
-rw-r-----. 1 oracle oinstall 2836064  6月 12 00:24 FREE_ora_4133_create_vector_index.trc
-rw-r-----. 1 oracle oinstall  602896  6月 12 00:24 FREE_ora_4133_create_vector_index.trm
[oracle@localhost trace]$ 
[oracle@localhost trace]$ tkprof FREE_ora_4133_create_vector_index.trc FREE_ora_4133_create_vector_index.txt waits=yes explain=scott@localhost:1521/freepdb1 sys=yes 

...略...

[oracle@localhost trace]$ ll *create_vector_index*
-rw-r-----. 1 oracle oinstall 2836064  6月 12 00:24 FREE_ora_4133_create_vector_index.trc
-rw-r-----. 1 oracle oinstall  602896  6月 12 00:24 FREE_ora_4133_create_vector_index.trm
-rw-rw-r--. 1 oracle oracle    500986  6月 12 00:30 FREE_ora_4133_create_vector_index.txt
[oracle@localhost trace]$ 
[oracle@localhost trace]$ view FREE_ora_4133_create_vector_index.txt

ということで、整形したトレースファイルからCREATE文を抜き出してみた。
これは私が実行したDDL文なので参考程度に...

CREATE VECTOR INDEX search_data_hnsw_ix ON search_data ( vector_desc )
  ORGANIZATION
  INMEMORY NEIGHBOR GRAPH
  DISTANCE COSINE
  WITH TARGET ACCURACY 90

以降、トレースから抜き出した補助表及関連する索引を作成するDDL
VECTOR$SEARCH_DATA_HNSW_IX$78074_79461_0$HNSW_ROWID_VID_MAP表、および、主キー索引の作成（基本的にこの補助表が主役)

CREATE TABLE SCOTT.VECTOR$SEARCH_DATA_HNSW_IX$78074_79461_0$HNSW_ROWID_VID_MAP 
(base_table_rowid ROWID PRIMARY KEY, vertex_id NUMBER)
  
CREATE UNIQUE INDEX "SCOTT"."SYS_C0013760" on
  "SCOTT"."VECTOR$SEARCH_DATA_HNSW_IX$78074_79461_0$HNSW_ROWID_VID_MAP"("BASE_TABLE_ROWID")
   NOPARALLEL

VECTOR$SEARCH_DATA_HNSW_IX$78074_79461_0$HNSW_SHARED_JOURNAL_TRANSACTION_COMMITS表、および、主キー索引の作成

CREATE TABLE SCOTT.VECTOR$SEARCH_DATA_HNSW_IX$78074_79461_0$HNSW_SHARED_JOURNAL_TRANSACTION_COMMITS 
(usn NUMBER NOT NULL, slot NUMBER NOT NULL, seq
  NUMBER NOT NULL, commit_scn NUMBER NOT NULL, 
  CONSTRAINT pk_xid_79461 PRIMARY KEY(usn, slot, seq)) 
  PARTITION BY RANGE(commit_scn) 
  INTERVAL(100)
  (PARTITION pdefault VALUES LESS THAN (0))

CREATE UNIQUE INDEX "SCOTT"."PK_XID_79461" on
  "SCOTT"."VECTOR$SEARCH_DATA_HNSW_IX$78074_79461_0$HNSW_SHARED_JOURNAL_TRANSACTION_COMMITS"("USN","SLOT","SEQ") 
  NOPARALLEL

VECTOR$SEARCH_DATA_HNSW_IX$78074_79461_0$HNSW_SHARED_JOURNAL_CHANGE_LOG表の作成（HNSW_SHARED_JOURNAL_TRANSACTION_COMMITS表の参照パーティションになっている）

CREATE TABLE SCOTT.VECTOR$SEARCH_DATA_HNSW_IX$78074_79461_0$HNSW_SHARED_JOURNAL_CHANGE_LOG 
(usn NUMBER NOT NULL, slot NUMBER NOT NULL, seq NUMBER NOT
  NULL, xcn NUMBER, base_table_rowid ROWID, dml_op VARCHAR2(10), 
  data_vector vector(384, FLOAT32), 
  CONSTRAINT fk_xid_79461 FOREIGN KEY(usn, slot, seq)
  REFERENCES 
  SCOTT.VECTOR$SEARCH_DATA_HNSW_IX$78074_79461_0$HNSW_SHARED_JOURNAL_TRANSACTION_COMMITS(usn, slot, seq)) 
  PARTITION BY REFERENCE(fk_xid_79461)

各表をdescribeしてみると...

VECTOR列を持つ表のROWIDとVERTEX_IDをマップしていますね、表を見てなんとなく想像できる列名で素敵w。RDBMSのモデリングで列からなにやってるか想像もできねー設計しているのを見たりしてると心が清くなった気がしますね。
これがVECTOR INDEXの主役といってもよいでしょうね。

SCOTT@localhost:1521/freepdb1> desc VECTOR$SEARCH_DATA_HNSW_IX$78074_79461_0$HNSW_ROWID_VID_MAP
 名前                                    NULL?    型
 ----------------------------------------- -------- ----------------------------
 BASE_TABLE_ROWID                          NOT NULL ROWID
 VERTEX_ID                                          NUMBER

次の２つの表は、元の表のVECTORに影響のある更新がトラックされているみたい。詳しい資料読んではいないのですが、変更をトラックしていく表っぽうので、変更のない状況では空なんじゃないだろうか。。。あとで確認します。

SCOTT@localhost:1521/freepdb1> desc VECTOR$SEARCH_DATA_HNSW_IX$78074_79461_0$HNSW_SHARED_JOURNAL_TRANSACTION_COMMITS
 名前                                    NULL?    型
 ----------------------------------------- -------- ----------------------------
 USN                                       NOT NULL NUMBER
 SLOT                                      NOT NULL NUMBER
 SEQ                                       NOT NULL NUMBER
 COMMIT_SCN                                NOT NULL NUMBER

SCOTT@localhost:1521/freepdb1> desc VECTOR$SEARCH_DATA_HNSW_IX$78074_79461_0$HNSW_SHARED_JOURNAL_CHANGE_LOG
 名前                                    NULL?    型
 ----------------------------------------- -------- ----------------------------
 USN                                       NOT NULL NUMBER
 SLOT                                      NOT NULL NUMBER
 SEQ                                       NOT NULL NUMBER
 XCN                                                NUMBER
 BASE_TABLE_ROWID                                   ROWID
 DML_OP                                             VARCHAR2(10)
 DATA_VECTOR                                        VECTOR(384, FLOAT32)

一応user_indexesビューから全体を見てみます。USER_INDEXESビューを通して見ると新たに7つのオブジェクトが作成されたことがわかります！！！！（赤字部分）
vecsys.vector$index表からは、補助表の存在しか見えませんでしたが、索引も作成されてます。実際にはこの表と索引のセグメントサイズの合計が、VECTOR INDEX作成時のセグメントサイズってことですよね？！（INMEMORYだからメモリーサイズって可能性もなくはないけど、どっちかわからんw）　とはいえ、CREATE VECTOR INDEX ほげほげ索引で、指定したほげほげ索引自体はセグメントは持たない！(INMEMORYテーブルとは異なる持ち方をしているだけなのかもしれないが、わかりにくいw）


SCOTT@localhost:1521/freepdb1> select index_name , table_name from user_indexes where table_name like '%SEARCH_DATA%';

INDEX_NAME                     TABLE_NAME
------------------------------ ----------------------------------------------------------------------------------------------------
SYS_IL0000078074C00009$$       SEARCH_DATA
SEARCH_DATA_HNSW_IX            SEARCH_DATA
SYS_C0013720                   VECTOR$SEARCH_DATA_HNSW_IX$78074_79421_0$HNSW_ROWID_VID_MAP
PK_XID_79421                   VECTOR$SEARCH_DATA_HNSW_IX$78074_79421_0$HNSW_SHARED_JOURNAL_TRANSACTION_COMMITS
SYS_IL0000079427C00007$$       VECTOR$SEARCH_DATA_HNSW_IX$78074_79421_0$HNSW_SHARED_JOURNAL_CHANGE_LOG

経過: 00:00:00.29

表名を中間一致検索すると関連する索引と表をリストすることができますが、これだとなんかイケてない感じが強いのでvecsys.vector$index表より扱いやすいビューを提供してもらいたいですね！　まじで (苦笑

長くなってしまったので、一旦、謎の１つをまとめておきたいと思います。
VECTOR INDEX (HNSW)のセグメントサイズとEXPLAIN PLAN FOR CREATE VECTOR INDEX...の見積もりサイズの差分確認は次回のおたのしみということで。

CREATE VECTOR INDEX search_data_hnsw_ix ON search_data ( vector_desc )
  ORGANIZATION
  INMEMORY NEIGHBOR GRAPH
  DISTANCE COSINE
  WITH TARGET ACCURACY 90

作成されるベクター索引(今回の例では、search_data_hnsw_ix)は *_INDEXESにはVECTOR索引としてリストされるが実体は持たない（INMEMORYとはいっても何がどうINMEMORY化されるかディクショナリーから追いやすかったテーブルのINMEMORY化とは傾向が違いそう）。
補助表とその索引を含めたオブジェクト群をアクセスするためのキーのような存在。ベクター索引（今回のHNSW索引の例では、マップ表とベクターの更新をトラックするパーティション表と参照パーティション表からなる３表と付随する３つの索引から構成されている。ベクター索引の主役は、ベクター列をもつベース表のROWIDをVERTEX_IDをマップするマップ表とその索引。変更がない状態であれば、おそらくこの２つのオブジェクトがセベクター索引のセグメントサイズの総量になりそう。

また、
これらオブジェクト（索引も含め）を簡単に一覧するビューは無く、中間一致検索で無理やり検索するか、vecsys.vector$index表のJSONデータを使って他のビューと結合して取得する必要がありそう（めんどくせぇw）

ということまでは見えた。（以下は、洞窟の奥へ潜入したときの手書きメモww）

もうひとつ、前述の通り、search_data_hnsw_ixというベクター索引の便宜上のオブジェクトは同一名のセグメントは持っていません。しかし、以下のようなSELECT文では、該当ベクター索引が利用されていることを示すオブジェクトとして現れてくるというのも特徴的ですね。
SQL文と実行計画によってはMAP表が現われてくることもあるようなので、その例についてもいずれ書こうと思っています:)　（それはそれで謎いですよね。突然裏の主役が実行計画に顔を出してくるわけなのでw）

SCOTT@localhost:1521/freepdb1> r
  1  SELECT
  2    id
  3    , description
  4    , community
  5    , location_desc
  6    , district
  7    , TO_NUMBER( v_distance ) AS v_distance
  8  FROM
  9  (
 10    SELECT
 11      id
 12      , description
 13      , community
 14      , location_desc
 15      , district
 16      , VECTOR_DISTANCE
 17        (
 18          vector_desc
 19          , VECTOR_EMBEDDING
 20           (
 21             all_minilm_l6 USING 'Incident in which someone may have been murdered' AS data
 22           )
 23        , COSINE
 24      ) v_distance
 25    FROM
 26      search_data
 27    ORDER BY
 28      v_distance
 29    FETCH APPROX FIRST 10 ROWS ONLY
 30* )


10行が選択されました。

経過: 00:00:00.32

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

-------------------------------------------------------------------------------------------------------
| Id  | Operation                       | Name                | Rows  | Bytes | Cost (%CPU)| Time     |
-------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                |                     |    10 |  1570 |     2  (50)| 00:00:01 |
|   1 |  VIEW                           |                     |    10 |  1570 |     2  (50)| 00:00:01 |
|*  2 |   COUNT STOPKEY                 |                     |       |       |            |          |
|   3 |    VIEW                         |                     |    10 |  1570 |     2  (50)| 00:00:01 |
|*  4 |     SORT ORDER BY STOPKEY       |                     |    10 | 16400 |     2  (50)| 00:00:01 |
|   5 |      TABLE ACCESS BY INDEX ROWID| SEARCH_DATA         |    10 | 16400 |     1   (0)| 00:00:01 |
|   6 |       VECTOR INDEX HNSW SCAN    | SEARCH_DATA_HNSW_IX |    10 | 16400 |     1   (0)| 00:00:01 |
-------------------------------------------------------------------------------------------------------

なお、今回利用している Oracle Database 23.4は最近の更新ペースからするとすでに古いリリースになっていますw　
VECTOR関連追加など含め結構な差分がりそうですね。例えば、DBMS_VECTOR.INDEX_VECTOR_MEMORY_ADVISOR()プロシージャが無いなど。（マニュアルには記載されているんですが、リリースいくつから有効というような表記は見当たらず）
また、VirtualBox Applienceだと、現時点では、23.7 が最新みたいなので入れ替えないとな。。。

23って、機能的にいつ頃落ち着くんだろうなぁ〜っ。

次回へ、つづく！

Enjoy SQL! and JSON?!

投稿日時 2025年6月17日 (火) 00時00分 Oracle, PL/SQL, チューニング, FAQ, SQL, VirtualBox, パフォーマンス, INDEX, Oracle Database 23c Free Developer Release, JSON, VECTOR, AI | 固定リンク | 0 | コメント (0)

2025年6月 5日 (木)

実行計画は, SQL文のレントゲン写真だ！ No.66 / AI Vector Search - VECTOR INDEX HNSW SCAN

Previously on Mac De Oracle
前回は、Oracle Database 23ai freeで試すVector Search - データ準備編でした。
今回は、AI Vector SearchでVECTOR INDEX HNSW SCANとそれが利用できない場合の実行計画という名のSQL文のレントゲンを診ていきたいと思います。:)

その前に、VECTOR INDEX HNSW を利用する前に必要な準備がまだ残っていました。
vector_memory_sizeの設定です。デフォルトでは 0 になっています。

Oracle Dataabase 23ai / Oracle AI Vector Search User's Guide/ Oracle AI Vector Search Parameters

https://docs.oracle.com/en/database/oracle/oracle-database/23/vecse/oracle-ai-vector-search-parameters.html

SYS@FREE> show parameter memory

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------

...略...

inmemory_xmem_size                   big integer 0
memory_max_size                      big integer 0
memory_max_target                    big integer 0
memory_size                          big integer 0
memory_target                        big integer 0
optimizer_inmemory_aware             boolean     TRUE
shard_apply_max_memory_size          integer     0
shared_memory_address                integer     0
vector_memory_size                   big integer 0

SYS@FREE> show parameter sga

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
allow_group_access_to_sga            boolean     FALSE
lock_sga                             boolean     FALSE
pre_page_sga                         boolean     TRUE
sga_max_size                         big integer 1536M
sga_min_size                         big integer 0
sga_target                           big integer 1536M

Oracle Database 23ai / Oracle AI Vector Searchユーザーズ・ガイド / ベクトル・プールのサイズ設定

https://docs.oracle.com/cd/G11854_01/vecse/size-vector-pool.html

今回はギリギリですがw 512MBに設定して試します。

SYS@FREE> create pfile from spfile;

ファイルが作成されました。

経過: 00:00:00.01
SYS@FREE> ALTER SYSTEM SET vector_memory_size=512m SCOPE=spfile
SYS@FREE> shutdown immediate
データベースがクローズされました。
データベースがディスマウントされました。
ORACLEインスタンスがシャットダウンされました。
SYS@FREE> startup
ORACLEインスタンスが起動しました。

Total System Global Area 1603726344 bytes
Fixed Size                  5360648 bytes
Variable Size             654311424 bytes
Database Buffers          402653184 bytes
Redo Buffers                4530176 bytes
Vector Memory Area        536870912 bytes
データベースがマウントされました。
データベースがオープンされました。
SYS@FREE> 
SYS@FREE> show parameter vector_memory_size

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
vector_memory_size                   big integer 512M

vector_memory_sizeサイズの準備ができたので、Vector Index (HNSW) を作成します。

まずは、HNSWタイプののVector Indexを作成します。

SCOTT@localhost:1521/freepdb1> l
  1  CREATE VECTOR INDEX search_data_hnsw_ix ON search_data ( vector_desc )
  2    ORGANIZATION
  3      INMEMORY NEIGHBOR GRAPH
  4      IDISTANCE COSINE
  5*     WITH TARGET ACCURACY 90
SCOTT@localhost:1521/freepdb1> /

索引が作成されました。

経過: 00:00:36.13
SCOTT@localhost:1521/freepdb1> r
  1  select index_name,table_name,index_type,index_subtype,uniqueness,ityp_name
  2* from user_indexes where table_name = 'SEARCH_DATA'

INDEX_NAME                     TABLE_NAME                     INDEX_TYPE                  INDEX_SUBTYPE                UNIQUENES ITYP_NAME
------------------------------ ------------------------------ --------------------------- ---------------------------- --------- --------------------
SYS_IL0000078074C00009$$       SEARCH_DATA                    LOB                                                      UNIQUE
SEARCH_DATA_HNSW_IX            SEARCH_DATA                    VECTOR                      INMEMORY_NEIGHBOR_GRAPH_HNSW NONUNIQUE

経過: 00:00:00.00
SCOTT@localhost:1521/freepdb1> exec dbms_stats.gather_table_stats(ownname=>'SCOTT',tabname=>'SEARCH_DATA',no_invalidate=>false, cascade=>true);

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

ちなみに、vector_memory_sizeに指定したメモリサイズでは小さすぎる場合、以下のエラーが発生します。vector_memory_sizeを増加するか、データ量を削減するかどちらかなんですよね。Oracle Database 23ai Freeってメモリサイズの制限も厳しいので。

CREATE VECTOR INDEX search_data_hnsw_ix ON search_data ( vector_desc )
                                           *
行1でエラーが発生しました。:
ORA-51961: ベクトル・メモリー領域が不足しています。 ヘルプ:
https://docs.oracle.com/error-help/db/ora-51961/

VECTOR INDEX HNSW SCAN + TABLE ACCESS BY INDEX ROWIDになるか確認してみましょう.

索引（Hierarchical Navigable Small World (HNSW)またはInverted File Flat (IVF)ベクトル索引）を利用させるためには、以下のガイドラインに従うことが重要なので一読しておくことをおすすめしておきます。（知らないと簡単にハマってしまうので）

Oracle Database 23ai / Oracle AI Vector Searchユーザーズ・ガイド / 索引使用のガイドライン

https://docs.oracle.com/cd/G11854_01/vecse/guidelines-using-vector-indexes.html

シカゴの犯罪データから、"Incident in which someone may have been murdered" という条件で殺人事件に絡んでそうな事件を10件検索してみます。APPROXというキーワードも重要なので忘れずに。

SELECT
  id
  , description
  , community
  , location_desc
  , district
  , TO_NUMBER( v_distance ) AS v_distance
FROM
(
  SELECT 
    id
    , description
    , community
    , location_desc
    , district
    , VECTOR_DISTANCE 
      (
        vector_desc
        , VECTOR_EMBEDDING
         (
           all_minilm_l6 USING 'Incident in which someone may have been murdered' AS data
         )
      , COSINE
    ) v_distance
  FROM 
    search_data
  ORDER BY 
    v_distance 
  FETCH APPROX FIRST 10 ROWS ONLY
)
/

おおおおおお、索引使ってる:) ほっとした

ただ、これまでの INMEMORYとはことなり、INMEMORYにあるはずので索引アクセスのはずなのに、実行計画のOPERATIONには、INMEMORYというキーワードがないこと。ディクショナリービューの使い方もこれまでとは異なる傾向がり、なかなか分かりづらい部分も多い。今回気づいた違和感というか謎は要調査（2025/6/20追記）

SCOTT@localhost:1521/freepdb1> l
  1  SELECT
  2    id
  3    , description
  4    , community
  5    , location_desc
  6    , district
  7    , TO_NUMBER( v_distance ) AS v_distance
  8  FROM
  9  (
 10    SELECT
 11      id
 12      , description
 13      , community
 14      , location_desc
 15      , district
 16      , VECTOR_DISTANCE
 17        (
 18          vector_desc
 19          , VECTOR_EMBEDDING
 20           (
 21             all_minilm_l6 USING 'Incident in which someone may have been murdered' AS data
 22           )
 23        , COSINE
 24      ) v_distance
 25    FROM
 26      search_data
 27    ORDER BY
 28      v_distance
 29    FETCH APPROX FIRST 10 ROWS ONLY
 30* )
SCOTT@localhost:1521/freepdb1> /

        ID DESCRIPTION                              COMMUNITY            LOCATION_DESC                            DISTRICT   V_DISTANCE
---------- ---------------------------------------- -------------------- ---------------------------------------- ---------- ----------
  13405240 AGGRAVATED - OTHER DANGEROUS WEAPON      AUSTIN               APARTMENT                                15TH       .631286621
  13405155 AGGRAVATED - OTHER DANGEROUS WEAPON      AUSTIN               HOSPITAL BUILDING / GROUNDS              15TH       .631286621
  13395521 AGGRAVATED - OTHER DANGEROUS WEAPON      MORGAN PARK          RESIDENCE                                22ND       .631286621
  13404912 AGGRAVATED - OTHER DANGEROUS WEAPON      ASHBURN              SCHOOL - PUBLIC BUILDING                 8TH        .631286621
  13405606 AGGRAVATED - OTHER DANGEROUS WEAPON      AVALON PARK          STREET                                   4TH        .631286621
  13509969 AGGRAVATED - OTHER DANGEROUS WEAPON      AUBURN GRESHAM       APARTMENT                                6TH        .631286621
  13396440 AGGRAVATED - OTHER DANGEROUS WEAPON      DUNNING              STREET                                   16TH       .631286621
  13396497 AGGRAVATED - OTHER DANGEROUS WEAPON      WOODLAWN             APARTMENT                                3RD        .631286621
  13405235 AGGRAVATED - OTHER DANGEROUS WEAPON      NEAR WEST SIDE       SIDEWALK                                 12TH       .631286621
  13396404 AGGRAVATED - OTHER DANGEROUS WEAPON      NEAR NORTH SIDE      CONVENIENCE STORE                        18TH       .631286621

10行が選択されました。

経過: 00:00:00.37
SCOTT@localhost:1521/freepdb1> set autot trace exp stat
SCOTT@localhost:1521/freepdb1> r
  1  SELECT
  2    id
  3    , description
  4    , community
  5    , location_desc
  6    , district
  7    , TO_NUMBER( v_distance ) AS v_distance
  8  FROM
  9  (
 10    SELECT
 11      id
 12      , description
 13      , community
 14      , location_desc
 15      , district
 16      , VECTOR_DISTANCE
 17        (
 18          vector_desc
 19          , VECTOR_EMBEDDING
 20           (
 21             all_minilm_l6 USING 'Incident in which someone may have been murdered' AS data
 22           )
 23        , COSINE
 24      ) v_distance
 25    FROM
 26      search_data
 27    ORDER BY
 28      v_distance
 29    FETCH APPROX FIRST 10 ROWS ONLY
 30* )


10行が選択されました。

経過: 00:00:00.32

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

-------------------------------------------------------------------------------------------------------
| Id  | Operation                       | Name                | Rows  | Bytes | Cost (%CPU)| Time     |
-------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                |                     |    10 |  1570 |     2  (50)| 00:00:01 |
|   1 |  VIEW                           |                     |    10 |  1570 |     2  (50)| 00:00:01 |
|*  2 |   COUNT STOPKEY                 |                     |       |       |            |          |
|   3 |    VIEW                         |                     |    10 |  1570 |     2  (50)| 00:00:01 |
|*  4 |     SORT ORDER BY STOPKEY       |                     |    10 | 16400 |     2  (50)| 00:00:01 |
|   5 |      TABLE ACCESS BY INDEX ROWID| SEARCH_DATA         |    10 | 16400 |     1   (0)| 00:00:01 |
|   6 |       VECTOR INDEX HNSW SCAN    | SEARCH_DATA_HNSW_IX |    10 | 16400 |     1   (0)| 00:00:01 |
-------------------------------------------------------------------------------------------------------

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

   2 - filter(ROWNUM<=10)
   4 - filter(ROWNUM<=10)


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

ヒントで索引を利用できなくしてみます。新しいヒントが結構追加されていますが、それらについては、また、別の機会にでも。

Oracle Database 23ai / Oracle AI Vector Search User's Guide / Vector Index Hints

https://docs.oracle.com/en/database/oracle/oracle-database/23/vecse/vector-index-hints.html

SELECT
  id
  , description
  , community
  , location_desc
  , district
  , TO_NUMBER( v_distance ) AS v_distance
FROM
(
  SELECT 
    /*+
      NO_VECTOR_INDEX_SCAN(search_data)
    */
    id
    , description
    , community
    , location_desc
    , district
    , VECTOR_DISTANCE 
      (
        vector_desc
        , VECTOR_EMBEDDING
         (
           all_minilm_l6 USING 'Incident in which someone may have been murdered' AS data
         )
      , COSINE
    ) v_distance
  FROM 
    search_data
  ORDER BY 
    v_distance 
  FETCH APPROX FIRST 10 ROWS ONLY
)
/

 
10行が選択されました。

経過: 00:00:03.84

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

------------------------------------------------------------------------------------------------
| Id  | Operation                | Name        | Rows  | Bytes |TempSpc| Cost (%CPU)| Time     |
------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT         |             |    10 |  1570 |       | 51357   (1)| 00:00:03 |
|   1 |  VIEW                    |             |    10 |  1570 |       | 51357   (1)| 00:00:03 |
|*  2 |   COUNT STOPKEY          |             |       |       |       |            |          |
|   3 |    VIEW                  |             |   125K|    18M|       | 51357   (1)| 00:00:03 |
|*  4 |     SORT ORDER BY STOPKEY|             |   125K|   195M|   244M| 51357   (1)| 00:00:03 |
|   5 |      TABLE ACCESS FULL   | SEARCH_DATA |   125K|   195M|       |  8543   (1)| 00:00:01 |
------------------------------------------------------------------------------------------------

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

   2 - filter(ROWNUM<=10)
   4 - filter(ROWNUM<=10)


統計
----------------------------------------------------------
       5635  recursive calls
          0  db block gets
      48201  consistent gets
      46497  physical reads
          0  redo size
       1589  bytes sent via SQL*Net to client
        108  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
        119  sorts (memory)
          0  sorts (disk)
         10  rows processed

APPROXキーワードをEXACTに変えました。これもVECTOR INDEXを利用できなくなる条件の一つです。診てみましょう

SELECT
  id
  , description
  , community
  , location_desc
  , district
  , TO_NUMBER( v_distance ) AS v_distance
FROM
(
  SELECT 
    id
    , description
    , community
    , location_desc
    , district
    , VECTOR_DISTANCE 
      (
        vector_desc
        , VECTOR_EMBEDDING
         (
           all_minilm_l6 USING 'Incident in which someone may have been murdered' AS data
         )
      , COSINE
    ) v_distance
  FROM 
    search_data
  ORDER BY 
    v_distance 
  FETCH EXACT FIRST 10 ROWS ONLY
)
/

実行計画とは関係ないですが、APPROXとEXACTの問い合わせ結果って結構違うのね。。。

SCOTT@localhost:1521/freepdb1> /

        ID DESCRIPTION                              COMMUNITY            LOCATION_DESC                            DISTRICT   V_DISTANCE
---------- ---------------------------------------- -------------------- ---------------------------------------- ---------- ----------
  13325717 OTHER CRIME AGAINST PERSON               BRIDGEPORT           APARTMENT                                9TH        .382904768
  13331403 OTHER CRIME AGAINST PERSON               HEGEWISCH            APARTMENT                                4TH        .382904768
  13329763 OTHER CRIME AGAINST PERSON               NEAR NORTH SIDE      SMALL RETAIL STORE                       18TH       .382904768
  13330138 OTHER CRIME AGAINST PERSON               ROSELAND             STREET                                   5TH        .382904768
  13329559 OTHER CRIME AGAINST PERSON               CHICAGO LAWN         APARTMENT                                8TH        .382904768
  13329389 OTHER CRIME AGAINST PERSON               BELMONT CRAGIN       ALLEY                                    25TH       .382904768
  13328588 OTHER CRIME AGAINST PERSON               LOOP                 APARTMENT                                1ST        .382904768
  13328610 OTHER CRIME AGAINST PERSON               SOUTH CHICAGO        APARTMENT                                4TH        .382904768
  13325825 OTHER CRIME AGAINST PERSON               WEST RIDGE           PARKING LOT / GARAGE (NON RESIDENTIAL)   24TH       .382904768
  13326308 OTHER CRIME AGAINST PERSON               PULLMAN              STREET                                   5TH        .382904768
  
  
  
実行計画
----------------------------------------------------------
Plan hash value: 2441119222

------------------------------------------------------------------------------------------------
| Id  | Operation                | Name        | Rows  | Bytes |TempSpc| Cost (%CPU)| Time     |
------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT         |             |    10 |  1570 |       | 51357   (1)| 00:00:03 |
|   1 |  VIEW                    |             |    10 |  1570 |       | 51357   (1)| 00:00:03 |
|*  2 |   COUNT STOPKEY          |             |       |       |       |            |          |
|   3 |    VIEW                  |             |   125K|    18M|       | 51357   (1)| 00:00:03 |
|*  4 |     SORT ORDER BY STOPKEY|             |   125K|   195M|   244M| 51357   (1)| 00:00:03 |
|   5 |      TABLE ACCESS FULL   | SEARCH_DATA |   125K|   195M|       |  8543   (1)| 00:00:01 |
------------------------------------------------------------------------------------------------

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

   2 - filter(ROWNUM<=10)
   4 - filter(ROWNUM<=10)

ということで、
実行計画は, SQL文のレントゲン写真だ！ No.66 / AI Vector Search - VECTOR INDEX HNSW SCAN
はここまで。

今回は一部だけ試してますが更新関連なども含めいろいろな仕組みがあるようで。。。ちょっと追っかけてみないと見えてこないところも多いです。マニュアルも多いですし。。。斜め読みしていて、まじか。。。。となっているところ。

ところで、前回explain plan 文でVector Indexサイズの見積もりを取得していたのですが、覚えてますでしょうか？実はちょっとクセがあるみたいなんですよね。*_SEGMENTSビューからは索引名では見つからないので。。。

あれ、 SEARCH_DATA_HNSW_IX　というVECTOR索引って、索引名で検索しても、*_SEGMENTSビューにでないのか。別の名前になってるのか。。。　セグメントサイズ見たかったのに。。。という謎だけ投げつけて、宿題としておきますw（わざとらしいw） うううーーーーむ、いろいろと知っておく必要なる事項は多そうですねぇ。。。。。

SCOTT@localhost:1521/freepdb1> select index_name,index_type,table_name from user_indexes where table_name='SEARCH_DATA';

INDEX_NAME                     INDEX_TYPE                  TABLE_NAME
------------------------------ --------------------------- ------------------------------
SYS_IL0000078074C00009$$       LOB                         SEARCH_DATA
SEARCH_DATA_HNSW_IX            VECTOR                      SEARCH_DATA

経過: 00:00:00.05
SCOTT@localhost:1521/freepdb1> select segment_name from user_segments where segment_name = 'SEARCH_DATA_HNSW_IX';

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

SCOTT@localhost:1521/freepdb1> r
  1* SELECT * FROM vecsys.vector$index

  IDX_OBJN   IDX_OBJD IDX_OWNER# IDX_NAME                       IDX_BASE_TABLE_OBJN IDX_BASE_TABLE_OWNER# IDX_PARAMS                     IDX_AUXILIARY_TABLES           
---------- ---------- ---------- ------------------------------ ------------------- --------------------- ------------------------------ ------------------------------
     78797                   153 SEARCH_DATA_HNSW_IX                          78074                   153 {"type":"HNSW","num_neighbors" {"rowid_vid_map_objn":78798,"s
                                                                                                          :32,"efConstruction":200,"dist hared_journal_transaction_comm
                                                                                                          ance":"COSINE","accuracy":90," its_objn":78800,"shared_journa
                                                                                                          vector_type":"FLOAT32","vector l_change_log_objn":78803,"rowi
                                                                                                          _dimension":384,"degree_of_par d_vid_map_name":"VECTOR$SEARCH
                                                                                                          allelism":1,"pdb_id":3,"indexe _DATA_HNSW_IX$78074_78797_0$HN
                                                                                                          d_col":"VECTOR_DESC"}          SW_ROWID_VID_MAP","shared_jour
                                                                                                                                         nal_transaction_commits_name":
                                                                                                                                         "VECTOR$SEARCH_DATA_HNSW_IX$78
                                                                                                                                         074_78797_0$HNSW_SHARED_JOURNA
                                                                                                                                         L_TRANSACTION_COMMITS","shared
                                                                                                                                         _journal_change_log_name":"VEC
                                                                                                                                         TOR$SEARCH_DATA_HNSW_IX$78074_
                                                                                                                                         78797_0$HNSW_SHARED_JOURNAL_CH
                                                                                                                                         ANGE_LOG"}
                                                                                                                                         
SCOTT@localhost:1521/freepdb1> r
  1  SELECT
  2    JSON_SERIALIZE(idx_params RETURNING VARCHAR2 PRETTY) AS "INDEX PARAM"
  3    ,JSON_SERIALIZE(idx_auxiliary_tables RETURNING VARCHAR2 PRETTY) AS "INDEX AUX"
  4* FROM vecsys.vector$index

INDEX PARAM                                        INDEX AUX
-------------------------------------------------- --------------------------------------------------------------------------------------------------------------------------------------------
{                                                  {
  "type" : "HNSW",                                   "rowid_vid_map_objn" : 78798,
  "num_neighbors" : 32,                              "shared_journal_transaction_commits_objn" : 78800,
  "efConstruction" : 200,                            "shared_journal_change_log_objn" : 78803,
  "distance" : "COSINE",                             "rowid_vid_map_name" : "VECTOR$SEARCH_DATA_HNSW_IX$78074_78797_0$HNSW_ROWID_VID_MAP",
  "accuracy" : 90,                                   "shared_journal_transaction_commits_name" : "VECTOR$SEARCH_DATA_HNSW_IX$78074_78797_0$HNSW_SHARED_JOURNAL_TRANSACTION_COMMITS",
  "vector_type" : "FLOAT32",                         "shared_journal_change_log_name" : "VECTOR$SEARCH_DATA_HNSW_IX$78074_78797_0$HNSW_SHARED_JOURNAL_CHANGE_LOG"
  "vector_dimension" : 384,                        }
  "degree_of_parallelism" : 1,
  "pdb_id" : 3,
  "indexed_col" : "VECTOR_DESC"
}

では、また！

Enjoin Execution Plans, SQLs, and AI Vector Search!

Related article on Mac De Oracle
実行計画は, SQL文のレントゲン写真だ！

AI Vector Search

・Oracle Database 23ai freeで試すVector Search - ONNXモデル準備編
・Oracle Database 23ai freeで試すVector Search - データ準備編

投稿日時 2025年6月 5日 (木) 00時00分チューニング, FAQ, SQL, パフォーマンス, INDEX, Oracle Database 23c Free Developer Release, JSON, VECTOR, AI | 固定リンク | 0 | コメント (0)

2025年6月 4日 (水)

Oracle Database 23ai freeで試すVector Search - データ準備編

Previously on Mac De Oracle
前回は、 ONNXモデル準備編でした。意外にすんなりできちゃいましたね。
で、今回は、Vector Searchのレントゲンという名の実行計画を取得するデータの準備編です。

ただし、Oracle Database 23ai Freeを利用するため以下のリソース制限があります。
その制限の中で行える量に調整しつつ準備します。

Oracle Database 23ai Free limitations

https://www.oracle.com/database/free/

Resource limit up to
・2 CPUs (for foreground processes)
・2 GB of RAM
・12 GB of user data on disk (included SYSAUX)

VirtualBOXの対象VMストレージサイズは十分なサイズにしてあります。(Oracle Database 23ai Freeの制限以上は確保してあります。Linux上での作業領域含む)

% VBoxManage showvminfo 25951093-0df5-47e8-823c-ac7fdf2902bf | grep Memory
Memory size:                 4096MB

VM上からみたストレージ空き容量とCPU数

[oracle@localhost work4vector]$ sudo df -aH | grep '/sd.'
[sudo] oracle のパスワード:
/dev/sda3         58G   20G   38G   35% /
/dev/sda1        1.1G  346M  719M   33% /boot

[oracle@localhost work4vector]$ grep cpu.cores /proc/cpuinfo | sort -u
cpu cores  : 2

Oracle Database 23aiのデータサイズは以下の通り。制限まで十分に余裕はあります

SYS@localhost:1521/freepdb1> r
  1* select file_name,tablespace_name,bytes/1024/1024/1024 "GB",autoextensible from dba_data_files

FILE_NAME                                              TABLESPACE_NAME                        GB AUT
------------------------------------------------------ ------------------------------ ---------- ---
/opt/oracle/oradata/FREE/FREEPDB1/sysaux01.dbf         SYSAUX                          .76171875 YES
/opt/oracle/oradata/FREE/FREEPDB1/users01.dbf          USERS                          .463867188 YES
/opt/oracle/oradata/FREE/FREEPDB1/system01.dbf         SYSTEM                         .419921875 YES
/opt/oracle/oradata/FREE/FREEPDB1/undotbs01.dbf        UNDOTBS1                         .1953125 YES

Vector Search向けサンプルデータはGetting Started with Oracle Database 23ai AI Vector Searchでも紹介されているChicago Data Portalのオープンデータを利用します。結構いいサイズのデータが公開されています。
とは言ってもVector Indexも含めたサイズを考えると、Oracle Database 23ai Freeに全データを取り込むのは現実的なく一部を取り込んで使うことにします。

一部を使うとはいっても結構なサイズです。データ自体欠損していたりするのもあるようなのでそれなりに工夫して使いまっすw
ETL屋さんの腕の見せ所ですねww

スクリーンショット1

スクリーンショット2

Chcago Data Portalから取得したオープンデータのCSV形式ファイルは以下のとおり。

シカゴの犯罪データで2001年から直近のデータまで公開されています。 データセットには座標を含むGEOデータも含まれていますが今回は利用しません。このデータセットだけで1.9GB程度ですが、最終的に取り込むのは1年分より少ない程度にします。
chicago_crimes_2001_20250508.csv

属性やコード値の意味および、マスタデータとなるデータセットは何かという情報は、Chicago Data Portalで該当するデータセットを開くと表示される列ヘッダーのヘルプポップアップダイアログに記載されています。
（前述、スクリーンショット２参照のこと）
以下のマスターデータセットは、chicago_crimes_2001_20250508.csv　と結合してコード値の読み替えなどに利用します。

Community Areaとして定義されているエリア名称などが含まれます（最新のもの） Boundaries_-_Community_Areas_20250508.csv

Districtの地区名称などが定義されています（最新のもの） PoliceDistrictDec2012_20250508.csv

シカゴ警察が利用しているイリノイ州の標準犯罪レポートIUCRコードマスター（最新のもの） Chicago_Police_Department_-_Illinois_Uniform_Crime_Reporting__IUCR__Codes_20250512.csv

使うかわからないですが、犯罪発生データに含まれているWARDの情報のマスターデータセットです（最新のものですが、結局使わなかったw） WARDS_2015_20250508.csv

上記データは、以下に作成したディレクトリオブジェクトに対応するディレクトリに配置して外部表のソースとなります。

SYS@localhost:1521/freepdb1> create directory chicago_crimes_data_dir as '/home/oracle/work4vector';

ディレクトリが作成されました。

経過: 00:00:00.46
SYS@localhost:1521/freepdb1> r
  1* select directory_name, directory_path from dba_directories where directory_name = upper('chicago_crimes_data_dir')

DIRECTORY_NAME                 DIRECTORY_PATH
------------------------------ ------------------------------
CHICAGO_CRIMES_DATA_DIR        /home/oracle/work4vector

経過: 00:00:00.01

SYS@localhost:1521/freepdb1> grant read on directory chicago_crimes_data_dir to scott;
権限付与が成功しました。

経過: 00:00:00.04

SCOTT@localhost:1521/freepdb1> !ls -l
合計 1917360
-rw-r--r--. 1 oracle oracle         3566  5月  9 09:46 Boundaries_-_Community_Areas_20250508.csv
-rw-r--r--. 1 oracle oracle        22307  5月 12 23:33 Chicago_Police_Department_-_Illinois_Uniform_Crime_Reporting__IUCR__Codes_20250512.csv
-rw-r--r--. 1 oracle oracle          202  5月  9 09:47 PoliceDistrictDec2012_20250508.csv
-rw-r--r--. 1 oracle oracle         1558  5月  9 09:48 WARDS_2015_20250508.csv
-rw-r--r--. 1 oracle oracle   1947211979  5月  9 03:40 chicago_crimes_2001_20250508.csv

Vector Searchで利用する表は以下、それ以外はこの表のデータを作りだすための元となるデータで外部票として取り込みVector Searchで利用する表データに変換します。
(DROP TABLE IF EXISTS構文は、Oracle Database 23ai 以降で使えます)

 DROP TABLE IF EXISTS search_data PURGE;
 CREATE TABLE search_data
 (
   id NUMBER
   , primary_description VARCHAR2(40)
   , description VARCHAR2(100)
   , location_desc VARCHAR2(100)
   , district VARCHAR2(30)
   , ward NUMBER
   , community VARCHAR2(30)
   , c_year NUMBER
   , vector_desc VECTOR
 )
 /

上記表のインプットとなる各外部票は以下の通り。

シカゴの犯罪データのオリジナルです。search_data_org（外部表）

列コメントにある数字と列名は、search_dataの列順と列名に対応しています。（ただし、そのままセットするものもあれば適宜型変換やマスターデータと結合して読み替えたりします。元になる列を示しています。
chicago_crimes_2001_20250508_2.csvというファイルがありますが、chicago_crimes_2001_20250508.csvのうちBad dataとして弾かれたデータが出力される.badファイルを元にデータが通るように整形したものを再度インプットとして利用したものです。

CREATE TABLE search_data_org
(
  id                VARCHAR2(100)    -- 1 id
 ,case_number       VARCHAR2(100) 
 ,case_Date         VARCHAR2(100) 
 ,block             VARCHAR2(100) 
 ,iucr              VARCHAR2(100)    -- 2 primary_description
 ,primary_type      VARCHAR2(100) 
 ,description       VARCHAR2(100)    -- 3 description
 ,Location_desc     VARCHAR2(100)    -- 4 location_desc
 ,arrest            VARCHAR2(100) 
 ,domestic          VARCHAR2(100) 
 ,beat              VARCHAR2(100) 
 ,district          VARCHAR2(100)    -- 5 district
 ,ward              VARCHAR2(100)    -- 6 ward
 ,community         VARCHAR2(100)    -- 7 community
 ,fbi_code          VARCHAR2(100) 
 ,x_coordinate      VARCHAR2(100) 
 ,y_coordinate      VARCHAR2(100) 
 ,c_year            VARCHAR2(100)    -- 8 c_year
 ,updated_on        VARCHAR2(100) 
 ,latitude          VARCHAR2(100) 
 ,longitude         VARCHAR2(100) 
 ,location          VARCHAR2(100) 
) 
ORGANIZATION EXTERNAL (
  TYPE ORACLE_LOADER
  DEFAULT DIRECTORY chicago_crimes_data_dir
  ACCESS PARAMETERS (
    RECORDS DELIMITED BY NEWLINE 
    FIELDS TERMINATED BY ',' OPTIONALLY ENCLOSED BY '"' 
    MISSING FIELD VALUES ARE NULL
    (
       id                     
      ,case_number
      ,case_Date
      ,block
      ,iucr
      ,primary_type
      ,description           
      ,Location_desc         
      ,arrest
      ,domestic
      ,beat
      ,district              
      ,ward                  
      ,community             
      ,fbi_code
      ,x_coordinate
      ,y_coordinate
      ,c_year                 
      ,updated_on
      ,latitude
      ,longitude
      ,location1
      ,location2
    )
    COLUMN TRANSFORMS
    (
      location FROM CONCAT 
      ( 
        location1
        ,location2 
      )
    )
  )
  LOCATION (
    'chicago_crimes_2001_20250508.csv'
    ,'chicago_crimes_2001_20250508_2.csv'
  )
)
REJECT LIMIT UNLIMITED
/

以降、マスターデータセットの外部表定義です。

communitiesマスタ（外部表）
AREA_NUMBER列がキーです。search_data_org外部表（シカゴの犯罪データ）のcommunity列と結合することで（列名違いすぎるwww、実案件だったらキレてるな、俺w）、COMMUNITY_NAMEに読み替えることができる、と。。。
とは言え、ちょいと怪しいので外部結合するようにしとくかw

CREATE TABLE communities 
(
  AREA_NUMBER NUMBER
  , COMMUNITY_NAME VARCHAR2(100)
  , AREA_NUM_1 NUMBER
  , SHAPE_AREA NUMBER
  , SHAPE_LEN NUMBER
)
ORGANIZATION EXTERNAL (
  TYPE ORACLE_LOADER
  DEFAULT DIRECTORY chicago_crimes_data_dir
  ACCESS PARAMETERS (
    RECORDS DELIMITED BY NEWLINE 
    SKIP 1
    FIELDS TERMINATED BY ',' OPTIONALLY ENCLOSED BY '"' 
    MISSING FIELD VALUES ARE NULL
    (
      AREA_NUMBER
      , COMMUNITY_NAME
      , AREA_NUM_1
      , SHAPE_AREA
      , SHAPE_LEN
    )
  )
  LOCATION (
    'Boundaries_-_Community_Areas_20250508.csv'
  )
)REJECT LIMIT UNLIMITED/

districtsマスタ（外部表）
DIST_NUMBER列がキーで、search_data_org外部表（シカゴの犯罪データ）のdistrict列と結合することで、DIST_LABELに読み替えることができます。(これも列名が異なっていて非常にわかりにくいwwww なんでこんな状態なのみたいなw)
これも外部結合の方が良さそうな雰囲気はありますね。実際詳しく追ったわけではないですがw

CREATE TABLE districts
(
   DIST_LABEL VARCHAR2(100)
   , DIST_NUMBER NUMBER
)
ORGANIZATION EXTERNAL (
  TYPE ORACLE_LOADER
  DEFAULT DIRECTORY chicago_crimes_data_dir
  ACCESS PARAMETERS (
    RECORDS DELIMITED BY NEWLINE 
    SKIP 1
    FIELDS TERMINATED BY ',' OPTIONALLY ENCLOSED BY '"' 
    MISSING FIELD VALUES ARE NULL
    (
       DIST_LABEL
       , DIST_NUMBER
    )
  )
  LOCATION (
    'PoliceDistrictDec2012_20250508.csv'
  )
)
REJECT LIMIT UNLIMITED
/

illinoi_uniform_crime_reporting_codesマスタ（外部表）
iucr列とsearch_data_org外部表（シカゴの犯罪データ）のiucr列を結合することでprimary_descriptionに読み替えることができます。結合キー列名が同じなのはよろしいのですが、ここまでバラバラなのにここだけ同じなのかww （これもなんとなく怪しいので、外部結合にしようと思います）

CREATE TABLE illinoi_uniform_crime_reporting_codes
(
  iucr                     VARCHAR2(5)
  , primary_description    VARCHAR2(100)
  , secondary_description  VARCHAR2(100)
  , index_code             CHAR(1)
  , active                 BOOLEAN NOT NULL
)
ORGANIZATION EXTERNAL (
  TYPE ORACLE_LOADER
  DEFAULT DIRECTORY chicago_crimes_data_dir
  ACCESS PARAMETERS (
    RECORDS DELIMITED BY NEWLINE 
    FIELDS TERMINATED BY ',' OPTIONALLY ENCLOSED BY '"' 
    MISSING FIELD VALUES ARE NULL
    (
      iucr
      ,primary_description
      ,secondary_description
      ,index_code
      ,active
    )
  )
  LOCATION (
    'Chicago_Police_Department_-_Illinois_Uniform_Crime_Reporting__IUCR__Codes_20250512.csv'
  )
)
REJECT LIMIT UNLIMITED
/

最後にsearch_dataにVECTORを埋め込んだデータを登録するためのIASです。VECTOR_EMBEDDING関数でsearch_data_org.descriptionを元にVECTORデータを生成しています。
全データ（830万件）のうち、2024年に発生したデータのID順で、125,000行だけ登録します。（理由は、Oracle Database 23ia Freeのデータ量というより2GBまでしか使えないというメモリサイズの制限が重しになっているためです。後述）

TRUNCATE TABLE search_data;
INSERT INTO search_data
(
  id
  , primary_description
  , description
  , location_desc
  , district
  , ward
  , community
  , c_year
  , vector_desc
)
SELECT
  sdo.id                       AS id
 , iucrc.primary_description   AS primary_description
 , sdo.description             AS description
 , sdo.Location_desc           AS Location_desc
 , d.dist_label                AS district
 , TO_NUMBER(sdo.ward)         AS ward
 , c.community_name            AS community
 , TO_NUMBER(sdo.c_year)       AS c_year
 , VECTOR_EMBEDDING(all_minilm_l6 USING sdo.description AS data) AS vector_desc
FROM 
  search_data_org sdo
  LEFT OUTER JOIN districts d
  ON
    TO_NUMBER(sdo.district) = d.dist_number
  LEFT OUTER JOIN communities c
  ON 
    TO_NUMBER(sdo.community) = c.area_number
  LEFT OUTER JOIN illinoi_uniform_crime_reporting_codes iucrc
  ON
    sdo.iucr = iucrc.iucr
WHERE
  TO_NUMBER(sdo.c_year) IN 2024
ORDER BY
  id
  , c_year
FETCH FIRST 125000 ROWS ONLY
/

では最初に、Vector Searchで利用する表だけ作成しておきます。データは前述のIASでガツンと登録しちゃいます。

SCOTT@localhost:1521/freepdb1> l
  1   CREATE TABLE search_data
  2   (
  3     id NUMBER
  4     , primary_description VARCHAR2(40)
  5     , description VARCHAR2(100)
  6     , location_desc VARCHAR2(100)
  7     , district VARCHAR2(30)
  8     , ward NUMBER
  9     , community VARCHAR2(30)
 10     , c_year NUMBER
 11     , vector_desc VECTOR
 12*  )
SCOTT@localhost:1521/freepdb1> /

表が作成されました。

経過: 00:00:00.03

もろもろエラーデータを補正しつつw なんとか search_data_org 外部表の作成に成功！　（エラーになっていたログはバッサリ削除しましたが。。。）

SCOTT@localhost:1521/freepdb1> l
  1  CREATE TABLE search_data_org
  2  (
  3    id                VARCHAR2(100)    -- 1
  4   ,case_number       VARCHAR2(100)
  5   ,case_Date         VARCHAR2(100)
  6   ,block             VARCHAR2(100)
  7   ,iucr              VARCHAR2(100)    -- 2 
  8   ,primary_type      VARCHAR2(100)
  9   ,description       VARCHAR2(100)    -- 3
 10   ,Location_desc     VARCHAR2(100)    -- 4
 11   ,arrest            VARCHAR2(100)
 12   ,domestic          VARCHAR2(100)
 13   ,beat              VARCHAR2(100)
 14   ,district          VARCHAR2(100)    -- 5 nullあり
 15   ,ward              VARCHAR2(100)    -- 6 nullあり
 16   ,community         VARCHAR2(100)    -- 7 数値データのみ、nullあり
 17   ,fbi_code          VARCHAR2(100)
 18   ,x_coordinate      VARCHAR2(100)
 19   ,y_coordinate      VARCHAR2(100)
 20   ,c_year            VARCHAR2(100)    -- 8 数値データのみ
 21   ,updated_on        VARCHAR2(100)
 22   ,latitude          VARCHAR2(100)
 23   ,longitude         VARCHAR2(100)
 24   ,location          VARCHAR2(100)
 25  )
 26  ORGANIZATION EXTERNAL (
 27    TYPE ORACLE_LOADER
 28    DEFAULT DIRECTORY chicago_crimes_data_dir
 29    ACCESS PARAMETERS (
 30      RECORDS DELIMITED BY NEWLINE
 31      FIELDS TERMINATED BY ',' OPTIONALLY ENCLOSED BY '"'
 32      MISSING FIELD VALUES ARE NULL
 33      (
 34         id
 35        ,case_number
 36        ,case_Date
 37        ,block
 38        ,iucr
 39        ,primary_type
 40        ,description
 41        ,Location_desc
 42        ,arrest
 43        ,domestic
 44        ,beat
 45        ,district
 46        ,ward
 47        ,community
 48        ,fbi_code
 49        ,x_coordinate
 50        ,y_coordinate
 51        ,c_year
 52        ,updated_on
 53        ,latitude
 54        ,longitude
 55        ,location1
 56        ,location2
 57      )
 58      COLUMN TRANSFORMS
 59      (
 60        location FROM CONCAT
 61        (
 62          location1
 63          ,location2
 64        )
 65      )
 66    )
 67    LOCATION (
 68      'chicago_crimes_2001_20250508.csv'
 69      ,'chicago_crimes_2001_20250508_2.csv'
 70    )
 71  )
 72* REJECT LIMIT UNLIMITED
SCOTT@localhost:1521/freepdb1> /

表が作成されました。

経過: 00:00:00.02
SCOTT@localhost:1521/freepdb1> select count(1) from search_data_org;

  COUNT(1)
----------
   8307418

経過: 00:00:36.80
SCOTT@localhost:1521/freepdb1> ! ls -l *.bad
ls: '*.bad' にアクセスできません: No such file or directory

communitiesマスタ（外部表）の作成

SCOTT@localhost:1521/freepdb1> l
  1  CREATE TABLE communities
  2  (
  3    AREA_NUMBER NUMBER
  4    , COMMUNITY_NAME VARCHAR2(100)
  5    , AREA_NUM_1 NUMBER
  6    , SHAPE_AREA NUMBER
  7    , SHAPE_LEN NUMBER
  8  )
  9  ORGANIZATION EXTERNAL (
 10    TYPE ORACLE_LOADER
 11    DEFAULT DIRECTORY chicago_crimes_data_dir
 12    ACCESS PARAMETERS (
 13      RECORDS DELIMITED BY NEWLINE
 14      SKIP 1
 15      FIELDS TERMINATED BY ',' OPTIONALLY ENCLOSED BY '"'
 16      MISSING FIELD VALUES ARE NULL
 17      (
 18        AREA_NUMBER
 19        , COMMUNITY_NAME
 20        , AREA_NUM_1
 21        , SHAPE_AREA
 22        , SHAPE_LEN
 23      )
 24    )
 25    LOCATION (
 26      'Boundaries_-_Community_Areas_20250508.csv'
 27    )
 28  )
 29* REJECT LIMIT UNLIMITED
SCOTT@localhost:1521/freepdb1> /

表が作成されました。

経過: 00:00:00.03

SCOTT@localhost:1521/freepdb1> select count(1) from communities;

  COUNT(1)
----------
        77

経過: 00:00:00.03
SCOTT@localhost:1521/freepdb1> ! ls -l *.bad
ls: '*.bad' にアクセスできません: No such file or directory

districtsマスタ（外部表）の作成

SCOTT@localhost:1521/freepdb1> l
  1  CREATE TABLE districts
  2  (
  3     DIST_LABEL VARCHAR2(100)
  4     , DIST_NUMBER NUMBER
  5  )
  6  ORGANIZATION EXTERNAL (
  7    TYPE ORACLE_LOADER
  8    DEFAULT DIRECTORY chicago_crimes_data_dir
  9    ACCESS PARAMETERS (
 10      RECORDS DELIMITED BY NEWLINE
 11      SKIP 1
 12      FIELDS TERMINATED BY ',' OPTIONALLY ENCLOSED BY '"'
 13      MISSING FIELD VALUES ARE NULL
 14      (
 15         DIST_LABEL
 16         , DIST_NUMBER
 17      )
 18    )
 19    LOCATION (
 20      'PoliceDistrictDec2012_20250508.csv'
 21    )
 22  )
 23* REJECT LIMIT UNLIMITED
SCOTT@localhost:1521/freepdb1> /

表が作成されました。

経過: 00:00:00.02

SCOTT@localhost:1521/freepdb1> ! ls -l *.bad
ls: '*.bad' にアクセスできません: No such file or directory

SCOTT@localhost:1521/freepdb1> select count(1) from districts;

  COUNT(1)
----------
        25

経過: 00:00:00.04

illinoi_uniform_crime_reporting_codesマスタ（外部表）の作成

SCOTT@localhost:1521/freepdb1> l
  1  CREATE TABLE illinoi_uniform_crime_reporting_codes
  2  (
  3    iucr                     VARCHAR2(5)
  4    , primary_description    VARCHAR2(100)
  5    , secondary_description  VARCHAR2(100)
  6    , index_code             CHAR(1)
  7    , active                 BOOLEAN NOT NULL
  8  )
  9  ORGANIZATION EXTERNAL (
 10    TYPE ORACLE_LOADER
 11    DEFAULT DIRECTORY chicago_crimes_data_dir
 12    ACCESS PARAMETERS (
 13      RECORDS DELIMITED BY NEWLINE
 14      FIELDS TERMINATED BY ',' OPTIONALLY ENCLOSED BY '"'
 15      MISSING FIELD VALUES ARE NULL
 16      (
 17        iucr
 18        ,primary_description
 19        ,secondary_description
 20        ,index_code
 21        ,active
 22      )
 23    )
 24    LOCATION (
 25      'Chicago_Police_Department_-_Illinois_Uniform_Crime_Reporting__IUCR__Codes_20250512.csv'
 26    )
 27  )
 28* REJECT LIMIT UNLIMITED
SCOTT@localhost:1521/freepdb1> /

表が作成されました。

経過: 00:00:00.02

SCOTT@localhost:1521/freepdb1> ! ls -l *.bad
ls: '*.bad' にアクセスできません: No such file or directory

SCOTT@localhost:1521/freepdb1> select count(1) from illinoi_uniform_crime_reporting_codes;

  COUNT(1)
----------
       410

経過: 00:00:00.02

では、最後の仕上げ。VECTOR INDEX以外はこれで完成です！！！, 0.25GB程度の消費ですね。表だけで。VECTOR INDEXは別途作成します。

SCOTT@localhost:1521/freepdb1> l
  1  INSERT INTO search_data
  2  (
  3    id
  4    , primary_description
  5    , description
  6    , location_desc
  7    , district
  8    , ward
  9    , community
 10    , c_year
 11    , vector_desc
 12  )
 13  SELECT
 14    sdo.id                       AS id
 15   , iucrc.primary_description   AS primary_description
 16   , sdo.description             AS description
 17   , sdo.Location_desc           AS Location_desc
 18   , d.dist_label                AS district
 19   , TO_NUMBER(sdo.ward)         AS ward
 20   , c.community_name            AS community
 21   , TO_NUMBER(sdo.c_year)       AS c_year
 22   , VECTOR_EMBEDDING(all_minilm_l6 USING sdo.description AS data) AS vector_desc
 23  FROM
 24    search_data_org sdo
 25    LEFT OUTER JOIN districts d
 26    ON
 27      TO_NUMBER(sdo.district) = d.dist_number
 28    LEFT OUTER JOIN communities c
 29    ON
 30      TO_NUMBER(sdo.community) = c.area_number
 31    LEFT OUTER JOIN illinoi_uniform_crime_reporting_codes iucrc
 32    ON
 33      sdo.iucr = iucrc.iucr
 34  WHERE
 35    TO_NUMBER(sdo.c_year) IN 2024
 36  ORDER BY
 37    id
 38    , c_year
 39* FETCH FIRST 125000 ROWS ONLY
SCOTT@localhost:1521/freepdb1> /

125000 行が作成されました。

経過: 00:39:28.49
SCOTT@localhost:1521/freepdb1> commit;

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

経過: 00:00:00.04
SCOTT@localhost:1521/freepdb1> select segment_name,bytes/1024/1024/1024 "GB" 
2 from user_segments where segment_name = 'SEARCH_DATA';

SEGMENT_NAME                           GB
------------------------------ ----------
SEARCH_DATA                      .2421875

経過: 00:00:00.29
SCOTT@localhost:1521/freepdb1> exec dbms_stats.gather_table_stats(ownname=>'SCOTT',tabname=>'SEARCH_DATA',no_invalidate=>false);

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

経過: 00:00:05.97

ちなみに、前述のIASの実行計画はこんな感じ。

---------------------------------------------------------------------------------------------------------------------------------
| Id  | Operation                       | Name                                  | Rows  | Bytes |TempSpc| Cost (%CPU)| Time     |
---------------------------------------------------------------------------------------------------------------------------------
|   0 | INSERT STATEMENT                |                                       |   551K|    55M|       | 77540   (1)| 00:00:04 |
|   1 |  LOAD TABLE CONVENTIONAL        | SEARCH_DATA                           |       |       |       |            |          |
|   2 |   SORT ORDER BY                 |                                       |   551K|    55M|    61M| 77540   (1)| 00:00:04 |
|*  3 |    HASH JOIN RIGHT OUTER        |                                       |   551K|    55M|       | 64408   (1)| 00:00:03 |
|   4 |     EXTERNAL TABLE ACCESS FULL  | DISTRICTS                             |    25 |   200 |       |     2   (0)| 00:00:01 |
|*  5 |     HASH JOIN RIGHT OUTER       |                                       |   510K|    47M|       | 64405   (1)| 00:00:03 |
|*  6 |      EXTERNAL TABLE ACCESS FULL | ILLINOI_UNIFORM_CRIME_REPORTING_CODES |   410 |  8610 |       |     3   (0)| 00:00:01 |
|*  7 |      HASH JOIN RIGHT OUTER      |                                       |   510K|    37M|       | 64401   (1)| 00:00:03 |
|   8 |       EXTERNAL TABLE ACCESS FULL| COMMUNITIES                           |    77 |  1232 |       |     2   (0)| 00:00:01 |
|*  9 |       EXTERNAL TABLE ACCESS FULL| SEARCH_DATA_ORG                       |   510K|    29M|       | 64398   (1)| 00:00:03 |
---------------------------------------------------------------------------------------------------------------------------------

次回、VECTOR SEARCHの実行計画という名のレントゲンネタのために、VECTOR INDEXサイズの見積サイズを確認しておきましょう。(Hierarchical Navigable Small World索引を利用します)
以下のように

参考） Oracle Database Release 23 / Oracle AI Vector Searchユーザーズ・ガイド / ベクトル索引の様々なカテゴリの管理

https://docs.oracle.com/cd/G11854_01/vecse/manage-different-categories-vector-indexes.html

Oracle Database Release 23 / Oracle AI Vector Searchユーザーズ・ガイド / ベクトル索引の使用に関するガイドライン

https://docs.oracle.com/cd/G11854_01/vecse/guidelines-using-vector-indexes.html

Oracle Database Release 23 / Oracle AI Vector Searchユーザーズ・ガイド / ベクトル索引のオプティマイザ計画

https://docs.oracle.com/cd/G11854_01/vecse/optimizer-plans-vector-indexes.html

Oracle Database Release 23 / Oracle AI Vector Searchユーザーズ・ガイド / 6 ベクトル索引およびハイブリッド・ベクトル索引の作成

https://docs.oracle.com/cd/G11854_01/vecse/create-vector-indexes-and-hybrid-vector-indexes.html#VECSE-GUID-8AF956F3-D951-4968-9B79-A6E180E87456

Oracle Database Release 23 / Oracle AI Vector Searchユーザーズ・ガイド / インメモリー近傍グラフ・ベクトル索引

https://docs.oracle.com/cd/G11854_01/vecse/memory-neighbor-graph-vector-index.html

Oracle Database Release 23 / Oracle AI Vector Searchユーザーズ・ガイド / Hierarchical Navigable Small World索引の理解

https://docs.oracle.com/cd/G11854_01/vecse/understand-hierarchical-navigable-small-world-indexes.html

Oracle Database Release 23 / Oracle AI Vector Searchユーザーズ・ガイド / Hierarchical Navigable Small World索引の構文およびパラメータ

https://docs.oracle.com/cd/G11854_01/vecse/hierarchical-navigable-small-world-index-syntax-and-parameters.html

冒頭で約830万行のデータから125,000行に制限したと書きましたが、その理由はベクトル・プールをSGA内に確保する必要があるからなんですよー。
そもそも、Oracle Database 23ai Free はメモリサイズの制限もあるので、その範囲に収まるようデータ量を制限しました。（ストレージより先にメモリサイズの制限にあたりそうだったので。。。w）

Oracle Database Release 23 / Oracle AI Vector Searchユーザーズ・ガイド / ベクトル・プールのサイズ設定

https://docs.oracle.com/cd/G11854_01/vecse/size-vector-pool.html

以下のVECTOR HNSW INDEXを作成予定なのですが、索引サイズを見積りサイズを確認しておきましょう。（Oracle Databaseには昔から便利なコマンドがあります。Explainで索引サイズの見積もりができるんですよね。

CREATE VECTOR INDEX search_data_hnsw_ix ON search_data ( vector_desc )
  ORGANIZATION
  INMEMORY NEIGHBOR GRAPH
  DISTANCE COSINE
  WITH TARGET ACCURACY 90
/

SCOTT@localhost:1521/freepdb1> l
  1  explain plan for
  2  CREATE VECTOR INDEX search_data_hnsw_ix ON search_data ( vector_desc )
  3    ORGANIZATION
  4      INMEMORY NEIGHBOR GRAPH
  5      DISTANCE COSINE
  6*     WITH TARGET ACCURACY 90
05:41:08 SCOTT@localhost:1521/freepdb1> /

解析されました。

経過: 00:00:00.02
SCOTT@localhost:1521/freepdb1> @?/rdbms/admin/utlxpls

PLAN_TABLE_OUTPUT
-----------------------------------------------------------------------------------------------
Plan hash value: 2727344110

----------------------------------------------------------------------------------------------
| Id  | Operation              | Name                | Rows  | Bytes | Cost (%CPU)| Time     |
----------------------------------------------------------------------------------------------
|   0 | CREATE INDEX STATEMENT |                     |   125K|   188M| 14689   (1)| 00:00:01 |
|   1 |  VECTOR INDEX BUILD    | SEARCH_DATA_HNSW_IX |       |       |            |          |
----------------------------------------------------------------------------------------------

Note
-----
   - estimated index size: 293M bytes

12GBまでデータを使えるんだけどインメモリー系機能使おうとすると、メモリサイズの制限キツイよねと、思ったりw

Enjoy SQL and Oracle Database.

次回へ続く。

・Oracle Database 23ai freeで試すVector Search - ONNXモデル準備編

投稿日時 2025年6月 4日 (水) 00時00分 PL/SQL, SQL, Oracle Database 23c Free Developer Release, VECTOR, AI | 固定リンク | 0 | コメント (0)

2025年6月 3日 (火)

Oracle Database 23ai freeで試すVector Search - ONNXモデル準備編

Getting Started with Oracle Database 23ai AI Vector Search
https://blogs.oracle.com/database/post/getting-started-with-oracle-database-23ai-ai-vector-search

上記ブログを見て、これも実行計画はSQL文のレントゲン写真ネタにはなりそうだなぁ、と思い。いきなり準備を始めたw　今日はその準備（日本語対応してないモデル）

環境は以下の通り。
VirtualBOX向けPrebuild VMを利用（なお、Arm64ではなく、Intel Mac）
いずれ、Arm64のネタも書く予定ではいますがw　それだと古ーーーーーい Oracleだとこんな結果に。。。みたいな差分比較ネタができないのでw　とりあえず。X86_64環境にて。。。(Arm64ネイティブの環境はまだ作りかけなのでw)

クラウドではなくオフラインでも楽しめる環境（23ai Freeなのでリソース制限の範囲内で遊べる環境にします）を作ります。

*** mac info. ***
ProductName:	macOS
ProductVersion:	12.7.6
BuildVersion:	21H1320
 
*** macOS ver. ***
      Model Name: MacBook
      Processor Name: Dual-Core Intel Core m5
      Processor Speed: 1.2 GHz
      Number of Processors: 1
      Total Number of Cores: 2
      Memory: 8 GB
 
*** VirtualBox ver. ***
7.0.10r158379

[oracle@localhost ~]$ cat /etc/oracle-release /etc/redhat-release
Oracle Linux Server release 8.9
Red Hat Enterprise Linux release 8.9 (Ootpa)
[oracle@localhost ~]$ uname -srpo
Linux 5.15.0-3.60.5.1.el8uek.x86_64 x86_64 GNU/Linux

SCOTT@localhost:1521/freepdb1> select banner_full from v$version;

BANNER_FULL
--------------------------------------------------------------------------------
Oracle Database 23ai Free Release 23.0.0.0.0 - Develop, Learn, and Run for Free
Version 23.4.0.24.05

12.2 ONNXモデルへの事前トレーニング済モデルの変換: エンドツーエンドの手順
https://docs.oracle.com/cd/G28130_01/2-23ai/mlpug/convert-pretrained-models-onnx-model-end-end-instructions.html

の手順に沿ってONNIXモデルの準備をします！。　

ドキュメント斜め読みしながら環境をつくっていたこともあり、インストールするOML4Pyのリリースが異なっていたりしてやり直したりしているログも含めているため読みずらいかもしれません。悪しからず m(_ _)m　　
進める前に、必要なversionなど事前確認しておくとスムーズだと思います。。。。。（お前が言うか〜っw

初っ端からエラー！。なんだろ。（すんなり進むのかこれw）

Pythonのインストール

[oracle@localhost ~]$ sudo yum install libffi-devel openssl openssl-devel tk-devel xz-devel zlib-devel bzip2-devel readline-devel libuuid-devel ncurses-devel libaio
[sudo] oracle のパスワード:
Oracle Linux 8 BaseOS Latest (x86_64)                                             0.0  B/s |   0  B     08:00
Errors during downloading metadata for repository 'ol8_baseos_latest':
  - Curl error (28): Timeout was reached for https://yum-us-phoenix-1.oracle.com/repo/OracleLinux/OL8/baseos/latest/x86_64/repodata/repomd.xml 
  [Connection timed out after 120000 milliseconds]
エラー: repo 'ol8_baseos_latest' のメタデータのダウンロードに失敗しました : Cannot download repomd.xml: Cannot download repodata/repomd.xml: All mirrors were tried

こんなの見つけた〜。多分これ。
yum update not working using Oracle Database 23ai Free Container Image Lite #2900
https://github.com/oracle/docker-images/issues/2900

間違いない！　これが原因だ
書かれている対策をまんま適用して。。。。

[oracle@localhost ~]$ cd /etc/yum/vars/
[oracle@localhost vars]$ ll
合計 8
-rw-r--r--. 1 root root 11  5月  1  2024 ocidomain
-rw-r--r--. 1 root root 14  5月  1  2024 ociregion
[oracle@localhost vars]$ cat ociregion
-us-phoenix-1
[oracle@localhost vars]$ cat ocidomain
oracle.com

[oracle@localhost vars]$ sudo mv ociregion ociregion.org
[sudo] oracle のパスワード:
[oracle@localhost vars]$ sudo su -
[root@localhost ~]#  sudo echo -n "" >  /etc/yum/vars/ociregion
[root@localhost ~]#  cat /etc/yum/vars/ociregion
[root@localhost ~]# exit
logout

気を取り直して、もう一度。

[oracle@localhost ~]$ sudo yum install libffi-devel openssl openssl-devel tk-devel xz-devel zlib-devel bzip2-devel readline-devel libuuid-devel ncurses-devel libaio

Oracle Linux 8 BaseOS Latest (x86_64)                                                5.0 MB/s |  97 MB     00:19
Oracle Linux 8 Application Stream (x86_64)                                           5.1 MB/s |  70 MB     00:13
Latest Unbreakable Enterprise Kernel Release 7 for Oracle Linux 8 (x86_64)           5.1 MB/s |  61 MB     00:12

...略...

パッケージ openssl-1:1.1.1k-12.el8_9.x86_64 は既にインストールされています。
パッケージ libaio-0.3.112-1.el8.x86_64 は既にインストールされています。
依存関係が解決しました。
===============================================================================================================
 パッケージ                            アーキテクチャー       バージョン            リポジトリー             サイズ
===============================================================================================================
インストール:
 bzip2-devel                          x86_64                1.0.6-28.el8_10      ol8_baseos_latest       224 k

 ...略...

 xorg-x11-proto-devel                 noarch                2020.1-3.el8         ol8_appstream           280 k

トランザクションの概要
===============================================================================================================
インストール    32 パッケージ
アップグレード  10 パッケージ

ダウンロードサイズの合計: 17 M
これでよろしいですか? [y/N]: y
パッケージのダウンロード:
(1/42): bzip2-devel-1.0.6-28.el8_10.x86_64.rpm                               1.5 MB/s | 224 kB     00:00

...略...

(42/42): util-linux-2.32.1-46.0.1.el8.x86_64.rpm                             3.6 MB/s | 2.5 MB     00:00
-----------------------------------------------------------------------------------------------------------
合計                                                                         4.3 MB/s |  17 MB     00:03

...略...

トランザクションのテストに成功しました。
トランザクションを実行中
  準備             :                                                                     1/1
  scriptletの実行中: libuuid-2.32.1-46.0.1.el8.x86_64                                    1/1
  アップグレード中 : libuuid-2.32.1-46.0.1.el8.x86_64                                     1/52

...略...

  xz-devel-5.2.4-4.el8_6.x86_64           zlib-devel-1.2.11-25.el8.x86_64

[oracle@localhost ~]$ mkdir -p $HOME/python
[oracle@localhost ~]$ wget https://www.python.org/ftp/python/3.12.0/Python-3.12.0.tgz

--2025-05-13 02:48:50--  https://www.python.org/ftp/python/3.12.0/Python-3.12.0.tgz

...略...

HTTP による接続要求を送信しました、応答を待っています... 200 OK
長さ: 27195214 (26M) [application/octet-stream]
`Python-3.12.0.tgz' に保存中

Python-3.12.0.tgz    100%[===================================>]  25.93M  4.79MB/s 時間 5.4s

2025-05-13 02:48:56 (4.80 MB/s) - `Python-3.12.0.tgz' へ保存完了 [27195214/27195214]

[oracle@localhost ~]$ tar -xvzf Python-3.12.0.tgz --strip-components=1 -C /home/$USER/python
Python-3.12.0/Grammar/
Python-3.12.0/Grammar/python.gram

...略...

Python-3.12.0/Objects/tupleobject.c
Python-3.12.0/install-sh

[oracle@localhost ~]$ cd $HOME/python
[oracle@localhost python]$ ./configure --prefix=$HOME/python

checking build system type... x86_64-pc-linux-gnu
checking host system type... x86_64-pc-linux-gnu

...略...

configure: creating Modules/Setup.local
configure: creating Makefile
configure:

If you want a release build with all stable optimizations active (PGO, etc),
please run ./configure --enable-optimizations

[oracle@localhost python]$ make clean; make

find . -depth -name '__pycache__' -exec rm -rf {} ';'
find . -name '*.py[co]' -exec rm -f {} ';'
find . -name '*.[oa]' -exec rm -f {} ';'

...略...

# Pristine binaries before BOLT optimization.
rm -f *.prebolt
# BOLT instrumented binaries.
rm -f *.bolt_inst
gcc -pthread -c -fno-strict-overflow -Wsign-compare -DNDEBUG -g -O3 -Wall    
-std=c11 -Wextra -Wno-unused-parameter -Wno-missing-field-initializers -Wstrict-prototypes 
-Werror=implicit-function-declaration -fvisibility=hidden  -I./Include/internal  
-I. -I./Include    -DPy_BUILD_CORE -o Programs/python.o ./Programs/python.c

...略...

LC_ALL=C sed -e 's,\$(\([A-Za-z0-9_]*\)),\$\{\1\},g' < Misc/python-config.sh >python-config
The following modules are *disabled* in configure script:
_sqlite3

The necessary bits to build these optional modules were not found:
_dbm                  _gdbm                 nis
To find the necessary bits, look in configure.ac and config.log.

Checked 111 modules (31 built-in, 75 shared, 1 n/a on linux-x86_64, 1 disabled, 3 missing, 0 failed on import)

[oracle@localhost python]$ make altinstall

Creating directory /home/oracle/python/bin
Creating directory /home/oracle/python/lib

...略...

The necessary bits to build these optional modules were not found:
_dbm                  _gdbm                 nis
To find the necessary bits, look in configure.ac and config.log.

Checked 111 modules (31 built-in, 75 shared, 1 n/a on linux-x86_64, 1 disabled, 3 missing, 0 failed on import)
Creating directory /home/oracle/python/lib/python3.12
Creating directory /home/oracle/python/lib/python3.12/asyncio

...略...

Looking in links: /tmp/tmp9k7fgbr3
Processing /tmp/tmp9k7fgbr3/pip-23.2.1-py3-none-any.whl
Installing collected packages: pip
  WARNING: The script pip3.12 is installed in '/home/oracle/python/bin' which is not on PATH.
  Consider adding this directory to PATH or, if you prefer to suppress this warning, use --no-warn-script-location.
Successfully installed pip-23.2.1

ここまでマニュアルの通り。想定外のエラーもなく順調ですね〜

変数PYTHONHOME、PATHおよび LD_LIBRARY_PATHを設定〜python3およびpip3のシンボリックリンクの作成など

[oracle@localhost python]$ export PYTHONHOME=$HOME/python
[oracle@localhost python]$ export PATH=$PYTHONHOME/bin:$PATH
[oracle@localhost python]$ export LD_LIBRARY_PATH=$PYTHONHOME/lib:$LD_LIBRARY_PATH
[oracle@localhost python]$ cd $HOME/python/bin
[oracle@localhost bin]$ ln -s python3.12 python3
[oracle@localhost bin]$ ln -s pip3.12 pip3
[oracle@localhost bin]$ cd $HOME
[oracle@localhost ~]$ wget https://download.oracle.com/otn_software/linux/instantclient/2340000/instantclient-basic-linux.x64-23.4.0.24.05.zip

--2025-05-13 03:03:13--  https://download.oracle.com/otn_software/linux/instantclient/2340000/instantclient-basic-linux.x64-23.4.0.24.05.zip

...略...

HTTP による接続要求を送信しました、応答を待っています... 200 OK
長さ: 118377607 (113M) [application/zip]
`instantclient-basic-linux.x64-23.4.0.24.05.zip' に保存中

instantclient-basic-linux.x64-23.4.0.24.05.zip  100%[===========================>] 112.89M  5.83MB/s 時間 18s

2025-05-13 03:03:31 (6.38 MB/s) - `instantclient-basic-linux.x64-23.4.0.24.05.zip' へ保存完了 [118377607/118377607]

[oracle@localhost ~]$
[oracle@localhost ~]$ unzip instantclient-basic-linux.x64-23.4.0.24.05.zip
Archive:  instantclient-basic-linux.x64-23.4.0.24.05.zip
replace META-INF/MANIFEST.MF? [y]es, [n]o, [A]ll, [N]one, [r]ename: A
  inflating: META-INF/MANIFEST.MF

...略...

  instantclient_23_4/libocci.so.21.1 -> libocci.so.23.1
  instantclient_23_4/libocci.so.22.1 -> libocci.so.23.1
[oracle@localhost ~]$
[oracle@localhost ~]$ export LD_LIBRARY_PATH=$HOME/instantclient_23_4:$LD_LIBRARY_PATH

.bashrcにも以下環境変数を追加しておきます

export PYTHONHOME=$HOME/python
export PATH=$PYTHONHOME/bin:$PATH
export LD_LIBRARY_PATH=$PYTHONHOME/lib:$LD_LIBRARY_PATH

[oracle@localhost ~]$ vi .bashrc
[oracle@localhost ~]$ cat .bashrc
# .bashrc

# Source global definitions
if [ -f /etc/bashrc ]; then
	. /etc/bashrc
fi

...略...

export TWO_TASK=FREEPDB1
fi


# Environment variables for Python

export PYTHONHOME=$HOME/python
export PATH=$PYTHONHOME/bin:$PATH
export LD_LIBRARY_PATH=$PYTHONHOME/lib:$LD_LIBRARY_PATH

# Note: If Python is used to load models to the database, set this environment variable for the Oracle Instant Client.

export LD_LIBRARY_PATH=$HOME/instantclient_23_4:$LD_LIBRARY_PATH

requirements.txtの作成

[oracle@localhost ~]$ vi requirements.txt
[oracle@localhost ~]$ cat requirements.txt
--extra-index-url https://download.pytorch.org/whl/cpu
pandas==2.1.1
setuptools==68.0.0
scipy==1.12.0
matplotlib==3.8.4
oracledb==2.2.0
scikit-learn==1.4.1post1
numpy==1.26.4
onnxruntime==1.17.0
onnxruntime-extensions==0.10.1
onnx==1.16.0
torch==2.2.0+cpu
transformers==4.38.1
sentencepiece==0.2.0

pip3のアップグレード

[oracle@localhost ~]$ pip3 install --upgrade pip

Requirement already satisfied: pip in ./python/lib/python3.12/site-packages (23.2.1)
Collecting pip
  Obtaining dependency information for pip
    from https://files.pythonhosted.org/packages/29/a2/d40fb2460e883eca5199c62cfc2463fd261f760556ae6290f88488c362c0/pip-25.1.1-py3-none-any.whl.metadata
  Downloading pip-25.1.1-py3-none-any.whl.metadata (3.6 kB)
Downloading pip-25.1.1-py3-none-any.whl (1.8 MB)
   ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 1.8/1.8 MB 6.3 MB/s eta 0:00:00
Installing collected packages: pip
  Attempting uninstall: pip
    Found existing installation: pip 23.2.1
    Uninstalling pip-23.2.1:
      Successfully uninstalled pip-23.2.1
Successfully installed pip-25.1.1

[oracle@localhost ~]$ pip3 install -r requirements.txt

Looking in indexes: https://pypi.org/simple, https://download.pytorch.org/whl/cpu
Collecting pandas==2.1.1 (from -r requirements.txt (line 2))
  Downloading pandas-2.1.1-cp312-cp312-manylinux_2_17_x86_64.manylinux2014_x86_64.whl.metadata (18 kB)
Collecting setuptools==68.0.0 (from -r requirements.txt (line 3))

...略...

Successfully installed MarkupSafe-3.0.2 certifi-2025.4.26 cffi-1.17.1 charset-normalizer-3.4.2 coloredlogs-15.0.1 contourpy-1.3.2 
cryptography-44.0.3 cycler-0.12.1 filelock-3.18.0 flatbuffers-25.2.10 fonttools-4.58.0 fsspec-2025.3.2 hf-xet-1.1.1 huggingface-hub-0.31.1 
humanfriendly-10.0 idna-3.10 jinja2-3.1.6 joblib-1.5.0 kiwisolver-1.4.8 matplotlib-3.8.4 mpmath-1.3.0 networkx-3.4.2 numpy-1.26.4 onnx-1.16.0 
onnxruntime-1.17.0 onnxruntime-extensions-0.10.1 oracledb-2.2.0 packaging-25.0 pandas-2.1.1 pillow-11.2.1 protobuf-6.30.2 pycparser-2.22 
pyparsing-3.2.3 python-dateutil-2.9.0.post0 pytz-2025.2 pyyaml-6.0.2 regex-2024.11.6 requests-2.32.3 safetensors-0.5.3 scikit-learn-1.4.1.post1 
scipy-1.12.0 sentencepiece-0.2.0 setuptools-68.0.0 six-1.17.0 sympy-1.14.0 threadpoolctl-3.6.0 tokenizers-0.15.2 torch-2.2.0+cpu 
tqdm-4.67.1 transformers-4.38.1 typing-extensions-4.13.2 tzdata-2025.2 urllib3-2.4.0

あ”！
oml-2.1をインストールしてしまっていたので、oml-2.0をインストールしなおし. (oml-2.1でやってもよかったけどw

Oracle Machine Learning for Python Downloads
https://www.oracle.com/database/technologies/oml4py-downloads.html

から、2.0をダウンロード（oml4py-client-linux-x86_64-2.0.zip）して、と。。。。

ということでreinstall

[oracle@localhost ~]$ unzip oml4py-client-linux-x86_64-2.0.zip
Archive:  oml4py-client-linux-x86_64-2.0.zip
  inflating: client/client.pl
  inflating: client/OML4PInstallShared.pm
  inflating: client/oml-2.0-cp312-cp312-linux_x86_64.whl
 extracting: client/oml4py.ver

[oracle@localhost ~]$ pip3 install client/oml-2.0-cp312-cp312-linux_x86_64.whl
Processing ./client/oml-2.0-cp312-cp312-linux_x86_64.whl
Requirement already satisfied: numpy>=1.26.4 in ./python/lib/python3.12/site-packages (from oml==2.0) (2.2.5)

...略...

Requirement already satisfied: six>=1.5 in ./python/lib/python3.12/site-packages (from python-dateutil>=2.7->matplotlib>=3.7.2->oml==2.0) (1.17.0)
Requirement already satisfied: joblib>=1.2.0 in ./python/lib/python3.12/site-packages (from scikit-learn>=1.2.1->oml==2.0) (1.5.0)
Requirement already satisfied: threadpoolctl>=3.1.0 in ./python/lib/python3.12/site-packages (from scikit-learn>=1.2.1->oml==2.0) (3.6.0)
Installing collected packages: oml
  Attempting uninstall: oml
    Found existing installation: oml 2.1
    Uninstalling oml-2.1:
      Successfully uninstalled oml-2.1
Successfully installed oml-2.0

なにか怒られてるな。なぜだ。。。。numpy 1.xが必要っぽい。。。

[oracle@localhost ~]$ python3
Python 3.12.0 (main, May 13 2025, 02:54:53) [GCC 8.5.0 20210514 (Red Hat 8.5.0-20.0.3)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>>
>>> import oml

A module that was compiled using NumPy 1.x cannot be run in
NumPy 2.2.5 as it may crash. To support both 1.x and 2.x
versions of NumPy, modules must be compiled with NumPy 2.0.
Some module may need to rebuild instead e.g. with 'pybind11>=2.12'.

If you are a user of the module, the easiest solution will be to
downgrade to 'numpy<2' or try to upgrade the affected module.
We expect that some modules will need time to support NumPy 2.

Traceback (most recent call last):  File "", line 1, in 
  File "/home/oracle/python/lib/python3.12/site-packages/oml/__init__.py", line 77, in 
    from oml.utils import *
  File "/home/oracle/python/lib/python3.12/site-packages/oml/utils/__init__.py", line 23, in 
    from .embeddings import EmbeddingModelConfig,EmbeddingModel
  File "/home/oracle/python/lib/python3.12/site-packages/oml/utils/_pipeline/__init__.py", line 22, in 
    from .PipelineBuilder import PipelineBuilder

...略...

/home/oracle/python/lib/python3.12/site-packages/torch/nn/modules/transformer.py:20: UserWarning: 
Failed to initialize NumPy: _ARRAY_API not found (Triggered internally at ../torch/csrc/utils/tensor_numpy.cpp:84.)
  device: torch.device = torch.device(torch._C._get_default_device()),  # torch.device('cpu'),

A module that was compiled using NumPy 1.x cannot be run in
NumPy 2.2.5 as it may crash. To support both 1.x and 2.x
versions of NumPy, modules must be compiled with NumPy 2.0.
Some module may need to rebuild instead e.g. with 'pybind11>=2.12'.

If you are a user of the module, the easiest solution will be to
downgrade to 'numpy<2' or try to upgrade the affected module.
We expect that some modules will need time to support NumPy 2.

Traceback (most recent call last):  File "", line 1, in 
  File "/home/oracle/python/lib/python3.12/site-packages/oml/__init__.py", line 77, in 
    from oml.utils import *

    ...略...

    from onnxruntime.capi._pybind_state import ExecutionMode  # noqa: F401
  File "/home/oracle/python/lib/python3.12/site-packages/onnxruntime/capi/_pybind_state.py", line 32, in 
    from .onnxruntime_pybind11_state import *  # noqa
AttributeError: _ARRAY_API not found
/home/oracle/python/lib/python3.12/site-packages/oml/__init__.py:80: UserWarning: oml.utils import failed
  warn('oml.utils import failed')
>>>

ということで、 numpy 1.x にする。。。うまくいった

[oracle@localhost ~]$ pip3 install --upgrade numpy==1.26.4
Collecting numpy==1.26.4
  Using cached numpy-1.26.4-cp312-cp312-manylinux_2_17_x86_64.manylinux2014_x86_64.whl.metadata (61 kB)
Using cached numpy-1.26.4-cp312-cp312-manylinux_2_17_x86_64.manylinux2014_x86_64.whl (18.0 MB)
Installing collected packages: numpy
  Attempting uninstall: numpy
    Found existing installation: numpy 2.2.5
    Uninstalling numpy-2.2.5:
      Successfully uninstalled numpy-2.2.5
Successfully installed numpy-1.26.4

やっふーーーーーーーー！

[oracle@localhost ~]$ python3
Python 3.12.0 (main, May 13 2025, 02:54:53) [GCC 8.5.0 20210514 (Red Hat 8.5.0-20.0.3)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>>
>>>
>>> import oml
>>>
>>> from oml.utils import EmbeddingModel, EmbeddingModelConfig
>>> EmbeddingModelConfig.show_preconfigured()
['sentence-transformers/all-mpnet-base-v2', 'sentence-transformers/all-MiniLM-L6-v2'
 , 'sentence-transformers/multi-qa-MiniLM-L6-cos-v1', 'ProsusAI/finbert'
 ,'medicalai/ClinicalBERT', 'sentence-transformers/distiluse-base-multilingual-cased-v2'
 , 'sentence-transformers/all-MiniLM-L12-v2', 'BAAI/bge-small-en-v1.5'
 , 'BAAI/bge-base-en-v1.5', 'taylorAI/bge-micro-v2', 'intfloat/e5-small-v2', 'intfloat/e5-base-v2'
 , 'prajjwal1/bert-tiny', 'thenlper/gte-base'
 , 'thenlper/gte-small', 'TaylorAI/gte-tiny', 'infgrad/stella-base-en-v2'
 , 'sentence-transformers/paraphrase-multilingual-mpnet-base-v2'
 , 'intfloat/multilingual-e5-base', 'intfloat/multilingual-e5-small'
 , 'sentence-transformers/stsb-xlm-r-multilingual']
>>>

DBMS_VECTOR.LOAD_ONNX_MODELを使用してデータベースに手動でアップロード可能な、ONNXファイルを生成
"事前構成済の埋込みモデルをローカル・ファイルにエクスポートします。oml.utilsからEmbeddingModelをインポートします。これにより、ONNX形式モデルがローカル・ファイル・システムにエクスポートされます。"

ディレクトリオプジェクト向けのディレクトリを先に作成し、そのディレクトリで行うと便利ですね。

[oracle@localhost ~]$ cd work4vector/
[oracle@localhost work4vector]$ pwd
/home/oracle/work4vector
[oracle@localhost work4vector]$ python3
Python 3.12.0 (main, May 13 2025, 02:54:53) [GCC 8.5.0 20210514 (Red Hat 8.5.0-20.0.3)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from oml.utils import EmbeddingModel
>>> em = EmbeddingModel(model_name="sentence-transformers/all-MiniLM-L6-v2")
>>> em.export2file("all-MiniLM-L6-v2", output_dir=".")
/home/oracle/python/lib/python3.12/site-packages/huggingface_hub/file_download.py:943: FutureWarning: `resume_download` is deprecated 
and will be removed in version 1.0.0. Downloads always resume when possible. If you want to force a new download, use `force_download=True`.
  warnings.warn(
tokenizer_config.json: 100%|████████████████████████████████████████████████| 350/350 [00:00<00:00, 821kB/s]
vocab.txt: 100%|████████████████████████████████████████████████████████████| 232k/232k [00:00<00:00, 565kB/s]
special_tokens_map.json: 100%|██████████████████████████████████████████████| 112/112 [00:00<00:00, 463kB/s]
tokenizer.json: 100%|███████████████████████████████████████████████████████| 466k/466k [00:00<00:00, 1.47MB/s]
config.json: 100%|██████████████████████████████████████████████████████████| 612/612 [00:00<00:00, 3.88MB/s]
model.safetensors: 100%|████████████████████████████████████████████████████| 90.9M/90.9M [00:13<00:00, 6.72MB/s]
>>>

[oracle@localhost work4vector]$ ll all-MiniLM-L6-v2.onnx
-rw-rw-r--. 1 oracle oracle 90621438  5月 13 05:47 all-MiniLM-L6-v2.onnx

[oracle@localhost work4vector]$ sqlplus sys@localhost:1521/freepdb1 as sysdba

...略...

Oracle Database 23ai Free Release 23.0.0.0.0 - Develop, Learn, and Run for Free
Version 23.4.0.24.05
に接続されました。
SYS@localhost:1521/freepdb1> create directory onnx_dir as '/home/oracle/work4vector';

ディレクトリが作成されました。

経過: 00:00:00.08
SYS@localhost:1521/freepdb1> !pwd
/home/oracle/work4vector

SYS@localhost:1521/freepdb1> grant read,write on directory onnx_dir to scott;

権限付与が成功しました。

経過: 00:00:00.05
SYS@localhost:1521/freepdb1> grant create mining model to scott;

権限付与が成功しました。

経過: 00:00:00.02

DBMS_VECTOR.LOAD_ONNX_MODELプロシージャを使用して、OMLユーザー・スキーマにモデルをロードする

コードは以下

BEGIN
   DBMS_VECTOR.LOAD_ONNX_MODEL(
     directory => 'ONNX_DIR',
     file_name => 'all-MiniLM-L6-v2.onnx',
     model_name => 'ALL_MINILM_L6');
END;
/

SCOTT@localhost:1521/freepdb1> l
  1  BEGIN
  2     DBMS_VECTOR.LOAD_ONNX_MODEL(
  3       directory => 'ONNX_DIR',
  4       file_name => 'all-MiniLM-L6-v2.onnx',
  5       model_name => 'ALL_MINILM_L6');
  6* END;
SCOTT@localhost:1521/freepdb1> /

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

経過: 00:00:08.93

SQLを使用してモデルを確認

SQL文は以下

SELECT
  model_name
  , algorithm
  , mining_function
FROM
  user_mining_models
WHERE
  model_name = 'ALL_MINILM_L6'
/

SCOTT@localhost:1521/freepdb1> l
  1  SELECT
  2    model_name
  3    , algorithm
  4    , mining_function
  5  FROM
  6    user_mining_models
  7  WHERE
  8*   model_name = 'ALL_MINILM_L6'
SCOTT@localhost:1521/freepdb1> /

MODEL_NAME                     ALGORITHM                      MINING_FUNCTION
------------------------------ ------------------------------ ------------------------------
ALL_MINILM_L6                  ONNX                           EMBEDDING

経過: 00:00:00.01

ユーザーがアクセスできるモデルを確認するビューからも確認しておきます。

SQLはこんな感じ

SELECT
  view_name
  , view_type
FROM
  user_mining_model_views
WHERE
  model_name = 'ALL_MINILM_L6'
ORDER BY
  view_name
/

SCOTT@localhost:1521/freepdb1> l
  1  SELECT
  2    view_name
  3    , view_type
  4  FROM
  5    user_mining_model_views
  6  WHERE
  7    model_name = 'ALL_MINILM_L6'
  8  ORDER BY
  9*   view_name
SCOTT@localhost:1521/freepdb1> /

VIEW_NAME                      VIEW_TYPE
------------------------------ ------------------------------
DM$VJALL_MINILM_L6             ONNX Metadata Information
DM$VMALL_MINILM_L6             ONNX Model Information
DM$VPALL_MINILM_L6             ONNX Parsing Information

経過: 00:00:00.01

上記ビューを問い合わせモデルの情報を確認:)

SCOTT@localhost:1521/freepdb1> SELECT * FROM dm$vmall_minilm_l6;

NAME                           VALUE
------------------------------ -----------------------------------------------
Producer Name                  onnx.compose.merge_models
Graph Name                     tokenizer_main_graph
Graph Description              Graph combining tokenizer and main_graph
                               tokenizer
                               main_graph
Version                        1
Input[0]                       input:string[?]
Output[0]                      embedding:float32[?,384]

6行が選択されました。

経過: 00:00:00.00

VECTOR_EMBEDDING SQLスコアリング関数を軽く試す！

SQL文はこんな感じ

SELECT VECTOR_EMBEDDING(ALL_MINILM_L6 USING 'RES' as DATA) AS embedding;

SCOTT@localhost:1521/freepdb1> r
  1* SELECT VECTOR_EMBEDDING(ALL_MINILM_L6 USING 'RES' as DATA) AS embedding

EMBEDDING
----------------------------------------------------------------------------------------------------
[-1.16423056E-001,1.54331746E-002,-4.69262414E-002,7.16730766E-003,3.50234732E-002,-4.02988419E-002,
.08232533E-002,4.99225073E-002,-1.86311249E-002,-2.62796488E-002,-3.2601878E-002,5.22731952E-002,-9.

...略...

-003,6.00763485E-002,1.91014066E-001,7.64457136E-002,1.46513591E-002,3.13854888E-002]


経過: 00:00:00.36

関数しか実行していないので面白い実行計画は現れませんが一応、確認だけw

SCOTT@localhost:1521/freepdb1> set autot trace exp stat
SCOTT@localhost:1521/freepdb1> r
  1* SELECT VECTOR_EMBEDDING(ALL_MINILM_L6 USING 'RES' as DATA) AS embedding

経過: 00:00:00.33

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

-----------------------------------------------------------------
| Id  | Operation        | Name | Rows  | Cost (%CPU)| Time     |
-----------------------------------------------------------------
|   0 | SELECT STATEMENT |      |     1 |     2   (0)| 00:00:01 |
|   1 |  FAST DUAL       |      |     1 |     2   (0)| 00:00:01 |
-----------------------------------------------------------------


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

user_mining_models 、user_mining_model_attributesビューなんてのありますね。ふむふむ

SCOTT@localhost:1521/freepdb1> SELECT model_name, mining_function, algorithm, algorithm_type, model_size FROM user_mining_models;

MODEL_NAME                     MINING_FUNCTION                ALGORITHM                      ALGORITHM_ MODEL_SIZE
------------------------------ ------------------------------ ------------------------------ ---------- ----------
ALL_MINILM_L6                  EMBEDDING                      ONNX                           NATIVE       90621438

経過: 00:00:00.02

SCOTT@localhost:1521/freepdb1> l
  1  SELECT model_name, attribute_name, attribute_type, data_type, vector_info
  2*      FROM   user_mining_model_attributes
SCOTT@localhost:1521/freepdb1> /

MODEL_NAME                     ATTRIBUTE_NAME                 ATTRIBUTE_TY DATA_TYPE                      VECTOR_INFO
------------------------------ ------------------------------ ------------ ------------------------------ ------------------------------
ALL_MINILM_L6                  ORA$ONNXTARGET                 VECTOR       VECTOR                         VECTOR(384,FLOAT32)
ALL_MINILM_L6                  DATA                           TEXT         VARCHAR2

経過: 00:00:00.01

ONNX形式の埋込みモデルを使用して、ユーザーの入力テキスト文字列「hello」をベクトルに変換してみる。ベクトル眺めても意味わからないけども、とりあえず、できてるみたいw

SCOTT@localhost:1521/freepdb1> col EMBEDDING for a200
SCOTT@localhost:1521/freepdb1> SELECT TO_VECTOR(VECTOR_EMBEDDING(all_minilm_l6 USING 'hello' as data)) AS EMBEDDING;

EMBEDDING
-----------------------------------------------------------------------------------------------
[-6.27717897E-002,5.49588911E-002,5.21648414E-002,8.57899487E-002,-8.27489197E-002,-7.45729804E-
002,6.85546845E-002,1.83963589E-002,-8.20114315E-002,-3.73847559E-002,1.21248914E-002,3.51829384
E-003,-4.13423125E-003,-4.37844135E-002,2.18073577E-002,-5.10276016E-003,1.95467062E-002,-4.2348

...略...

-4.67414372E-002,-1.34112127E-002,6.51347339E-002,5.09059429E-002,5.1483497E-002,7.09215924E-003]


経過: 00:00:00.67

ということで、準備完了（このモデルだと日本語は対応してないみたいだけど、ひとまず、軽く遊べる小さなOracle Database 23ai Free on VirtualBOXの環境の準備完了！

SQL文もここまでくると、何やっているのか理解しながら進めないと、迷子になりそうな気がしないでもないw

次回へつづく。

投稿日時 2025年6月 3日 (火) 00時00分 Oracle, PL/SQL, Linux, SQL, VirtualBox, Oracle Database 23c Free Developer Release, VECTOR, AI | 固定リンク | 0 | コメント (0)

2025年5月26日 (月)

スマートロジックの亜種のお話 / PostgreSQL, MySQL, Oracle Databaseそれぞれの影響

本題に入る前に、

祝！　Mac De Oracle 20周年記念!!!!! Happy 20th Anniversary Mac De Oracle !!!

20年前の第一回目の記事はどんな内容だったでしょう！！！！
Panther De Oracle10g その１

MacOS (Mac OS X 10.3 / Panther ) に直接イントールして遊べる Oracle Database　があったころの話ですw
なつかしい！
また、当時は失敗作と名高いw　（今のMac Studio並の筐体）PowerMac G4 Cube 450Mhz改　Sonnet 1.2Ghz　832GMB RAM　を使っていました。これまた懐かしいSonnetのCPUカードで。

そして最後に、最も大切なブログの名前　"Mac De Oracle" は、どう閃いたのか！！！
当時、Zopeネタのブログ、 "Cube De Zope" からG4 Cube繋がりでインスパイアされて、 de だけ頂いて (^^)　、
（知ってるかたどれぐらいいるのでしょうね）

付けたタイトルが、Mac De Oracle でした。

あ、忘れちゃいけない、そもそもブログ書いたら〜。Oracleの!!
と、背中を推してくれたのは妻なんですけどねw　
彼女の一言がなかったら Mac De Oracleも Oracle ACEにもなってなかったでしょうね。
ありがとう！

ということで、

これからも雑多なネタ織り交ぜて、楽しく書いていくことになるw
Mac De Oracle (まだ残してあるIntel MacのVirtalBoxで動いてたりするネタも多いのですけどもw)　を、よろしくお願いいたします。 m(_ _)m

では、本日のおはなし。（ちょいと長めです）

WHERE句でCOALESCE関数を利用したスマートロジックの亜種って、Poor performanceを起こすってネタ、世間ではかなり書かれている印象なのですが、今日は、そんな中でも癖の強そうな、COALESCE関数を使ったスマートロジックの亜種の話。。

スマートロジックの亜種と書いた理由は、動的SQLで素直に書けばなんの問題のないもない比較的単純なSQL文を、COALESCE関数とNULLを組み合わせ動的SQLを回避したいという意図で書かれたものだから。。です。

また、この亜種は利用するデータベース（オプティマイザーだが）で影響の出方も異なるというところが、興味深いところだったりします。
なお、影響が小さそうに見える症状でも、膨大な量のデータも扱っている方達には、塵も積もれば。。。。という点には、むむむむ。。。となるはず。。

Oracle Database 21c, MySQL 8.0.36, PostgreSQL 16.3 いずれも、ちょい前のリリースにしてあります。前からそうだからってのも診てもらおうと。。。
(なお、今回利用している環境は、MacBook Intel 上のVirtualBoxのVMを利用しています。このためだけにIntel Macが残っているww)

piraruku ~ % sw_vers
ProductName:	macOS
ProductVersion:	12.7.6
BuildVersion:	21H1320
piraruku ~ % /usr/sbin/system_profiler SPHardwareDataType | grep -E '(Processor|Cores|Memory|Chip|Model Name)'
      Model Name: MacBook
      Processor Name: Dual-Core Intel Core m5
      Processor Speed: 1.2 GHz
      Number of Processors: 1
      Total Number of Cores: 2
      Memory: 8 GB
piraruku ~ % VBoxManage -V
7.0.10r158379

Oracle Databaseの表と索引、データ件数ですが、MySQL, PostgreSQLでも同一の表、索引、データを登録してあります。

SCOTT@orclpdb1> desc customers
 名前                                    NULL?    型
 ----------------------------------------- -------- ----------------------------------
 CUSTOMER_ID                               NOT NULL NUMBER(6)
 FIRST_NAME                                NOT NULL VARCHAR2(20)
 LAST_NAME                                 NOT NULL VARCHAR2(20)
 ADDRESS                                            VARCHAR2(40)
 PHONE_NUMBER                                       VARCHAR2(25)

SCOTT@orclpdb1> desc orders
 名前                                    NULL?    型
 ----------------------------------------- -------- ----------------------------------
 ORDER_ID                                  NOT NULL NUMBER(12)
 ORDER_DATE                                NOT NULL TIMESTAMP(6) WITH LOCAL TIME　ZONE
 ORDER_MODE                                         VARCHAR2(8)
 CUSTOMER_ID                               NOT NULL NUMBER(6)
 ORDER_STATUS                                       NUMBER(2)
 ORDER_TOTAL                                        NUMBER(8,2)
 SALES_REP_ID                                       NUMBER(6)
 PROMOTION_ID                                       NUMBER(6)


 TABLE_NAME                     INDEX_NAME                     COLUMN_NAME
 ------------------------------ ------------------------------ ------------------------------
 CUSTOMERS                      PK_CUSTOMERS                   CUSTOMER_ID
 ORDERS                         FK_ORDERS_CUSTOMERS            CUSTOMER_ID
 ORDERS                         PK_ORDERS                      ORDER_ID

SCOTT@orclpdb1> select count(1) from orders;

  COUNT(1)
----------
       105

SCOTT@orclpdb1> select count(1) from customers;

  COUNT(1)
----------
       319

まずは、問題のSQL文の例から診てもらいましょう。

SELECT
  orders.order_id
  , orders.order_date
  , customers.first_name
FROM
  orders
  INNER JOIN customers
  ON
    orders.customer_id = customers.customer_id
WHERE
  customers.customer_id = COALESCE(:cust_id, customers.customer_id)
  AND orders.order_id = COALESCE(:order_id, orders.order_id);

みなさん, 上記SQL文のWHERE句で、なにをスマートにやりたい（と思っている）のか、わかりますか？

答え

バインド変数（cust_id, order_id）にどちも NULL がセットされた場合は、全顧客のオーダーをリスト.
特定のcust_idが指定されたら、該当顧客の前オーダーをリスト(このときorder_idはNULL).
特定のorder_idが指定された、該当オーダーをリスト（このときcust_idはNULL).
どちらの変数にも特定のオーダーと顧客が指定されたら該当するオーダーをリスト。

ようするに、全件取得と特定のデータの取得で個別のWHEREの条件に書きかける動的SQLにすればよいわけですけども、
動的SQLを回避したい、ただそこだけに着目してしまった"スマートロジックの亜種"になっています。

WHERE句のCOALESCE関数。SELECTリストならともかく、検索時の弊害が多くなる使い方ですよね。
スマートなように見えているのは机の上だけです。

実際にオプティマイザがどうするか次第ですが、大抵の場合、検索時のフィルタリングが諸悪の根源になる場合が多いいですよね。ご存知の方も多いと思います。
（データ量が多い場合は軽視できない部分です。それらについてもググると沢山ヒットするはずです）

で、
Oracle Database/MySQL/PostgreSQLのうち一つで、フィルタリング以外の影響を引き起こすことに気がついてしまったので、メモがわりに書いておきまっす”

(今回利用したスクリプトは後半に貼ってあります)

Oracle Database 21c から診てみましょう。

SCOTT@orclpdb1> select banner_legacy from v$version;

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

1) :cust_id, :order_id どちらも NULL にした場合（なお、バインドピークは有効のままです）

事前の想定通り、全データ取得のケースであるにもかかわらず、Table full scannの操作で、COALESCE関数を伴うフィルタリングが現れています。明らかに電力の無駄遣いw　データが少ないと影響は見えにくいですが。
(HASH JOINで利用されている赤字にしている作業用メモリサイズは覚えておいてくださいね。改善後の実行計画の部分で必要になります）

SCOTT@orclpdb1> @testrun1 null null

   CUST_ID
----------
[null]

  ORDER_ID
----------
[null]

  1  SELECT
  2    /*+
  3      gather_plan_statistics
  4    */
  5    orders.order_id
  6    , orders.order_date
  7    , customers.first_name
  8  FROM
  9    orders
 10    INNER JOIN customers
 11    ON
 12      orders.customer_id = customers.customer_id
 13  WHERE
 14    customers.customer_id = COALESCE(:cust_id, customers.customer_id)
 15*   AND orders.order_id = COALESCE(:order_id, orders.order_id)

...略...

Plan hash value: 23084738

-------------------------------------------------------------------------------------------------------------------------
| Id  | Operation          | Name      | Starts | Cost (%CPU)| A-Rows |   A-Time   | Buffers |  OMem |  1Mem | Used-Mem |
-------------------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT   |           |      1 |     6 (100)|    105 |00:00:00.01 |      13 |       |       |          |
|*  1 |  HASH JOIN         |           |      1 |     6   (0)|    105 |00:00:00.01 |      13 |  1376K|  1376K| 1558K (0)|
|*  2 |   TABLE ACCESS FULL| ORDERS    |      1 |     5   (0)|    105 |00:00:00.01 |       2 |       |       |          |
|*  3 |   TABLE ACCESS FULL| CUSTOMERS |      1 |     1   (0)|    319 |00:00:00.01 |      11 |       |       |          |
-------------------------------------------------------------------------------------------------------------------------

...略...

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

   1 - access("ORDERS"."CUSTOMER_ID"="CUSTOMERS"."CUSTOMER_ID")
   2 - filter("ORDERS"."ORDER_ID"=COALESCE(:ORDER_ID,"ORDERS"."ORDER_ID"))
   3 - filter("CUSTOMERS"."CUSTOMER_ID"=COALESCE(:CUST_ID,"CUSTOMERS"."CUSTOMER_ID"))

なお、opt_param('_optim_peek_user_binds', 'false')ヒントでbind peekをオフにしても同じ結果でした。

2) :cust_id, :order_idともに値をNULL以外に設定した場合（バインドピーク有効のままですがハードパースさせています）

実行計画が変化しました。ただ、ORDERSではTable Full Scanのままです。(データ量が少ない影響かもしれないですね。とは言え気になるw）

SCOTT@orclpdb1> @testrun1 144 2435

   CUST_ID
----------
       144

  ORDER_ID
----------
      2435

...略...

Plan hash value: 4191309613

----------------------------------------------------------------------------------------------------------------------------
| Id  | Operation                    | Name         | Starts | E-Rows |E-Bytes| Cost (%CPU)| A-Rows |   A-Time   | Buffers |
----------------------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT             |              |      1 |        |       |     6 (100)|      1 |00:00:00.01 |       4 |
|   1 |  NESTED LOOPS                |              |      1 |      1 |    30 |     6   (0)|      1 |00:00:00.01 |       4 |
|   2 |   NESTED LOOPS               |              |      1 |      1 |    30 |     6   (0)|      1 |00:00:00.01 |       3 |
|*  3 |    TABLE ACCESS FULL         | ORDERS       |      1 |      1 |    19 |     5   (0)|      1 |00:00:00.01 |       2 |
|*  4 |    INDEX UNIQUE SCAN         | PK_CUSTOMERS |      1 |      1 |       |     0   (0)|      1 |00:00:00.01 |       1 |
|   5 |   TABLE ACCESS BY INDEX ROWID| CUSTOMERS    |      1 |      1 |    11 |     1   (0)|      1 |00:00:00.01 |       1 |
----------------------------------------------------------------------------------------------------------------------------

...略...

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

   3 - filter("ORDERS"."ORDER_ID"=COALESCE(:ORDER_ID,"ORDERS"."ORDER_ID"))
   4 - access("ORDERS"."CUSTOMER_ID"="CUSTOMERS"."CUSTOMER_ID")
      filter("CUSTOMERS"."CUSTOMER_ID"=COALESCE(:CUST_ID,"CUSTOMERS"."CUSTOMER_ID"))

ORDERSの主キー索引をユニークスキャンさせるようにindexヒントを追加すると素直に効いてくれますね。ですが、ここがポイントです。index full scanしています。

ここ試験にでますよ。これCOALESCE関数の影響です。主キー索引からindex unique scanすればよいはずですが、できななくなるんですよ。

index full scan + table access by index rowid batched　(１行だけ) ですが. 結局、無駄なデータにアクセスして捨てていることになりますね。ほとんどを。これじゃダメですよね。
実行計画は、全くスマートじゃなくなっていますww

SCOTT@orclpdb1> @testrun1 144 2435

...略...

  1  SELECT
  2    /*+
  3      gather_plan_statistics
  4      index(orders pk_orders)
  5    */
  6    orders.order_id

...略...

Plan hash value: 109917740

--------------------------------------------------------------------------------------------------------------------
| Id  | Operation                             | Name         | Starts | Cost (%CPU)| A-Rows |   A-Time   | Buffers |
--------------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                      |              |      1 |     3 (100)|      1 |00:00:00.01 |       4 |
|   1 |  NESTED LOOPS                         |              |      1 |     3   (0)|      1 |00:00:00.01 |       4 |
|   2 |   NESTED LOOPS                        |              |      1 |     3   (0)|      1 |00:00:00.01 |       3 |
|   3 |    TABLE ACCESS BY INDEX ROWID BATCHED| ORDERS       |      1 |     2   (0)|      1 |00:00:00.01 |       2 |
|*  4 |     INDEX FULL SCAN                   | PK_ORDERS    |      1 |     1   (0)|      1 |00:00:00.01 |       1 |
|*  5 |    INDEX UNIQUE SCAN                  | PK_CUSTOMERS |      1 |     0   (0)|      1 |00:00:00.01 |       1 |
|   6 |   TABLE ACCESS BY INDEX ROWID         | CUSTOMERS    |      1 |     1   (0)|      1 |00:00:00.01 |       1 |
--------------------------------------------------------------------------------------------------------------------

...略...

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

   4 - filter("ORDERS"."ORDER_ID"=COALESCE(:ORDER_ID,"ORDERS"."ORDER_ID"))
   5 - access("ORDERS"."CUSTOMER_ID"="CUSTOMERS"."CUSTOMER_ID")
       filter("CUSTOMERS"."CUSTOMER_ID"=COALESCE(:CUST_ID,"CUSTOMERS"."CUSTOMER_ID"))

3) 1)を動的SQLで回避した場合、全件取得はWHERE句のない文になりますよね！

最適な実行計画にするために動的SQL化し生成されたSQL文を実行して1)のケースがどう改善されるか診てみましょう

全行取得するのでWHERE句は不要。シンプルになりました。
余計なフィルタリングも消えました。

この例だとMERGE JOINになっていますが、データ量が少ない影響だと推測。
ソートに使うメモリを索引を使って回避している動きがあることから利用するメモリサイズが少なくなるためでしょうね。データ量が大きくなるとHash Joinに切り替わるかもしれないですね。
（理由は、1)の実行計画のHASH JOINが利用するメモリサイズとの比較で小さくなっていることがわかります）

  1  SELECT
  2      /*+
  3        gather_plan_statistics
  4      */
  5      orders.order_id
  6      , orders.order_date
  7      , customers.first_name
  8    FROM
  9      orders
 10      INNER JOIN customers
 11      ON
 12*       orders.customer_id = customers.customer_id

...略...

Plan hash value: 3079428679

---------------------------------------------------------------------------------------------------------------------------------------------
| Id  | Operation                    | Name                | Starts | Cost (%CPU)| A-Rows |   A-Time   | Buffers |  OMem |  1Mem | Used-Mem |
---------------------------------------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT             |                     |      1 |     9 (100)|    105 |00:00:00.01 |      20 |       |       |          |
|   1 |  MERGE JOIN                  |                     |      1 |     9  (12)|    105 |00:00:00.01 |      20 |       |       |          |
|   2 |   TABLE ACCESS BY INDEX ROWID| ORDERS              |      1 |     2   (0)|    105 |00:00:00.01 |      16 |       |       |          |
|   3 |    INDEX FULL SCAN           | FK_ORDERS_CUSTOMERS |      1 |     1   (0)|    105 |00:00:00.01 |       8 |       |       |          |
|*  4 |   SORT JOIN                  |                     |    105 |     7  (15)|    105 |00:00:00.01 |       4 | 20480 | 20480 |18432  (0)|
|   5 |    TABLE ACCESS FULL         | CUSTOMERS           |      1 |     6   (0)|    319 |00:00:00.01 |       4 |       |       |          |
---------------------------------------------------------------------------------------------------------------------------------------------

...略...

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

   4 - access("ORDERS"."CUSTOMER_ID"="CUSTOMERS"."CUSTOMER_ID")
       filter("ORDERS"."CUSTOMER_ID"="CUSTOMERS"."CUSTOMER_ID")

4) 2)の改善

動的SQL化によりCOALESCE関数は不要でわかりやすいSQL文ですよね。こちらのほうが自然ですw

見ての通り、WHERE句に記述されているCOALESCE関数を含むフィルタリングが消え、スッキリしたPredicate Informationの内容に変化しました。これで安心！

  1  SELECT
  2      /*+
  3        gather_plan_statistics
  4      */
  5      orders.order_id
  6      , orders.order_date
  7      , customers.first_name
  8    FROM
  9      orders
 10      INNER JOIN customers
 11      ON
 12        orders.customer_id = customers.customer_id WHERE
 13             customers.customer_id = :cust_id
 14*            AND orders.order_id = :order_id

...略...

-----------------------------------------------------------------------------------------------------------
| Id  | Operation                    | Name         | Starts | Cost (%CPU)| A-Rows |   A-Time   | Buffers |
-----------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT             |              |      1 |     2 (100)|      1 |00:00:00.01 |       4 |
|   1 |  NESTED LOOPS                |              |      1 |     2   (0)|      1 |00:00:00.01 |       4 |
|   2 |   TABLE ACCESS BY INDEX ROWID| CUSTOMERS    |      1 |     1   (0)|      1 |00:00:00.01 |       2 |
|*  3 |    INDEX UNIQUE SCAN         | PK_CUSTOMERS |      1 |     0   (0)|      1 |00:00:00.01 |       1 |
|*  4 |   TABLE ACCESS BY INDEX ROWID| ORDERS       |      1 |     1   (0)|      1 |00:00:00.01 |       2 |
|*  5 |    INDEX UNIQUE SCAN         | PK_ORDERS    |      1 |     0   (0)|      1 |00:00:00.01 |       1 |
-----------------------------------------------------------------------------------------------------------

...略...

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

   3 - access("CUSTOMERS"."CUSTOMER_ID"=:CUST_ID)
   4 - filter("ORDERS"."CUSTOMER_ID"=:CUST_ID)
   5 - access("ORDERS"."ORDER_ID"=:ORDER_ID)

次は、MySQL 8.0.36

mysql> select version();
+-----------+
| version() |
+-----------+
| 8.0.36    |
+-----------+

1) :cust_id, :order_id どちらも NULL にした場合

Oracle Databaseでの症状同様に、無駄なフィルタリングが現れていますよね

mysql> set @cust_id = null;
Query OK, 0 rows affected (0.00 sec)

mysql> set @order_id = null;
Query OK, 0 rows affected (0.00 sec)

mysql> select @cust_id;
+--------------------+
| @cust_id           |
+--------------------+
| NULL               |
+--------------------+v1 row in set (0.00 sec)

mysql> select @order_id;
+----------------------+
| @order_id            |
+----------------------+
| NULL                 |
+----------------------+
1 row in set (0.01 sec)

mysql> explain format=tree
    -> SELECT
    ->   orders.order_id
    ->   , orders.order_date
    ->   , customers.first_name
    -> FROM
    ->   orders
    ->   INNER JOIN customers
    ->   ON
    ->     orders.customer_id = customers.customer_id
    -> WHERE
    ->   customers.customer_id = COALESCE(@cust_id, customers.customer_id)
    ->   AND orders.order_id = COALESCE(@order_id, orders.order_id);
+-----------------------------------------------------------------------------------------------------------+
| EXPLAIN                                                                                                   |
+-----------------------------------------------------------------------------------------------------------+
| -> Nested loop inner join  (cost=13.6 rows=10.5)
    -> Filter: ((cast(orders.customer_id as double) = cast(coalesce(((@cust_id)),orders.customer_id) as double)) 
       and (cast(orders.order_id as double) = cast(coalesce(((@order_id)),orders.order_id) as double)))  (cost=2.05 rows=10.5)
        -> Table scan on orders  (cost=2.05 rows=105)
    -> Single-row index lookup on customers using PRIMARY (customer_id=orders.customer_id)  (cost=1.01 rows=1)
 |
+-----------------------------------------------------------------------------------------------------------+

2):cust_id, :order_idねともに値をNULL以外に設定した場合

このケースもOracle Databaseでの症状に類ていますよね。ふむふむ

mysql> set @cust_id = 144;
Query OK, 0 rows affected (0.00 sec)

mysql> set @order_id = 2435;
Query OK, 0 rows affected (0.00 sec)

mysql> select @cust_id;
+----------+
| @cust_id |
+----------+
|      144 |
+----------+
1 row in set (0.00 sec)

mysql> select @order_id;
+-----------+
| @order_id |
+-----------+
|      2435 |
+-----------+
1 row in set (0.00 sec)

mysql> explain format=tree
    -> SELECT
    ->   orders.order_id
    ->   , orders.order_date
    ->   , customers.first_name
    -> FROM
    ->   orders
    ->   INNER JOIN customers
    ->   ON
    ->     orders.customer_id = customers.customer_id
    -> WHERE
    ->   customers.customer_id = COALESCE(@cust_id, customers.customer_id)
    ->   AND orders.order_id = COALESCE(@order_id, orders.order_id);
+-----------------------------------------------------------------------------------------------------------+
| EXPLAIN                                                                                                   |
+-----------------------------------------------------------------------------------------------------------+
| -> Nested loop inner join  (cost=13.6 rows=10.5)
    -> Filter: ((orders.customer_id = coalesce(((@cust_id)),orders.customer_id)) 
        and (orders.order_id = coalesce(((@order_id)),orders.order_id)))  (cost=2.05 rows=10.5)
        -> Table scan on orders  (cost=2.05 rows=105)
    -> Single-row index lookup on customers using PRIMARY (customer_id=orders.customer_id)  (cost=1.01 rows=1)
 |
+-----------------------------------------------------------------------------------------------------------+

3) 1)を動的SQLにして適切なSQLになった対策後の結果

そもそも全行取得するのになんでフィルタリングさせちゃうようなWHERE句を書くのかと。。
フィルタリングはなくなり綺麗なものです。

mysql> explain format=tree
    -> SELECT
    ->   orders.order_id
    ->   , orders.order_date
    ->   , customers.first_name
    -> FROM
    ->   orders
    ->   INNER JOIN customers
    ->   ON
    ->     orders.customer_id = customers.customer_id;
+-----------------------------------------------------------------------------------------------------------+
| EXPLAIN                                                                                                   |
+-----------------------------------------------------------------------------------------------------------+
| -> Nested loop inner join  (cost=127 rows=105)
    -> Table scan on orders  (cost=11.5 rows=105)
    -> Single-row index lookup on customers using PRIMARY (customer_id=orders.customer_id)  (cost=1 rows=1)
 |
+-----------------------------------------------------------------------------------------------------------+

4) 3)同様に動的SQLにして、COALESCE関数を排除した結果。

無駄なフルタリングも一歳なし。こうでなくちゃw COAESCE関数を含むフィルタなんていらんのですよ。

mysql> set @cust_id = 144;
Query OK, 0 rows affected (0.00 sec)

mysql> set @order_id = 2435;
Query OK, 0 rows affected (0.00 sec)

mysql> select @cust_id;
+----------+
| @cust_id |
+----------+
|      144 |
+----------+
1 row in set (0.00 sec)

mysql> select @order_id;
+-----------+
| @order_id |
+-----------+
|      2435 |
+-----------+
1 row in set (0.00 sec)

mysql> explain format=tree
    -> SELECT
    ->   orders.order_id
    ->   , orders.order_date
    ->   , customers.first_name
    -> FROM
    ->   orders
    ->   INNER JOIN customers
    ->   ON
    ->     orders.customer_id = customers.customer_id
    -> WHERE
    ->   customers.customer_id = @cust_id
    ->   AND orders.order_id = @order_id;
+-------------------------------------------------------+
| EXPLAIN                                               |
+-------------------------------------------------------+
| -> Rows fetched before execution  (cost=0..0 rows=1)
 |
+-------------------------------------------------------+

そして、最後は、PostgreSQL 16.3　

とりを務めているぐらいなのでw、
Oracle Database, MySQLとはちょっと違った影響がありそうなのは、気づいている方が多そう。。。。
それがどのような違いなのか診てみましょう。

perftestdb=> select version();
                                                 version                                                 
---------------------------------------------------------------------------------------------------------
 PostgreSQL 16.3 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 8.5.0 20210514 (Red Hat 8.5.0-22), 64-bit
(1 行)

1) :cust_id, :order_id どちらも NULL にした場合

全行取得してINNER JOINするだけですが、Join Cardinarityが変です！！！！！

Rows Removed by Join Filter: 3129とあります。105rows*31rowsなので、なぜか直積しちゃってますね。わぉ！　細かいところだが一部のROWSなんとなく合わないようなきもするが、そこは見てないことにしておこう。。フィルタリングが余計なのはOracle Database, MySQLと同じ。

症状としては重症の類ですよね。

データが多くなった場合の直積はフィルタリング以上にキツイですよーーーーっ！

perftestdb=> \pset null [null]
Null表示は"[null]"です。
perftestdb=> \set cust_id NULL
perftestdb=> \set order_id NULL
perftestdb=> \echo :cust_id
NULL
perftestdb=> \echo :order_id
NULL
perftestdb=> explain (analyze,verbose)
perftestdb-> SELECT
perftestdb->   orders.order_id
perftestdb->   , orders.order_date
perftestdb->   , customers.first_name
perftestdb-> FROM
perftestdb->   orders
perftestdb->   INNER JOIN customers
perftestdb->   ON
perftestdb->     orders.customer_id = customers.customer_id
perftestdb-> WHERE
perftestdb->   customers.customer_id = COALESCE(:cust_id, customers.customer_id)
perftestdb->   AND orders.order_id = COALESCE(:order_id, orders.order_id);

                                               QUERY PLAN                                 
--------------------------------------------------------------------------------------------------------------
 Nested Loop  (cost=0.00..10.33 rows=1 width=18) (actual time=0.025..1.416 rows=105 loops=1)
   Output: orders.order_id, orders.order_date, customers.first_name
   Inner Unique: true
   Join Filter: (orders.customer_id = customers.customer_id)
    Rows Removed by Join Filter: 3129
   ->  Seq Scan on public.orders  (cost=0.00..2.31 rows=1 width=16) (actual time=0.016..0.041 rows=105 loops=1)
         Output: orders.order_id, orders.order_date, orders.order_mode, orders.customer_id
                 , orders.order_status, orders.order_total, orders.sales_rep_id, orders.promotion_id
          Filter: (orders.order_id = COALESCE(orders.order_id))
   ->  Seq Scan on public.customers  (cost=0.00..7.99 rows=2 width=10) (actual time=0.001..0.007 rows=31 loops=105)
         Output: customers.customer_id, customers.first_name
                 , customers.last_name, customers.address, customers.phone_number
          Filter: (customers.customer_id = COALESCE(customers.customer_id))
 Planning Time: 0.456 ms
 Execution Time: 1.453 ms

2):cust_id, :order_idともに値をNULL以外に設定した場合

主キーを利用するかと思いきや、COALESCE関数の影響で全表走査してフィルタリングしてほぼ捨ててますねなぜ(???)

perftestdb=> \pset null [null]
Null表示は"[null]"です。
perftestdb=> \set cust_id 144
perftestdb=> \set order_id 2435
perftestdb=> \echo :cust_id
144
perftestdb=> \echo :order_id
2435
perftestdb=> explain (analyze,verbose)
SELECT
  orders.order_id
  , orders.order_date
  , customers.first_name
FROM
  orders
  INNER JOIN customers
  ON
    orders.customer_id = customers.customer_id
WHERE
  customers.customer_id = COALESCE(:cust_id, customers.customer_id)
  AND orders.order_id = COALESCE(:order_id, orders.order_id);
  
                                             QUERY PLAN                                                
--------------------------------------------------------------------------------------------------------------
 Nested Loop  (cost=0.00..10.57 rows=1 width=18) (actual time=0.062..0.155 rows=1 loops=1)
   Output: orders.order_id, orders.order_date, customers.first_name
   ->  Seq Scan on public.orders  (cost=0.00..2.58 rows=1 width=16) 
                                                              (actual time=0.038..0.064 rows=1 loops=1)
         Output: orders.order_id, orders.order_date, orders.order_mode, orders.customer_id
                 , orders.order_status, orders.order_total, orders.sales_rep_id, orders.promotion_id
         Filter: ((orders.customer_id = 144) AND (orders.order_id = 2435))
         Rows Removed by Filter: 104
   ->  Seq Scan on public.customers  (cost=0.00..7.99 rows=1 width=10) 
                                                                 (actual time=0.020..0.085 rows=1 loops=1)
         Output: customers.customer_id, customers.first_name
                 , customers.last_name, customers.address, customers.phone_number
         Filter: (customers.customer_id = 144)
         Rows Removed by Filter: 318
 Planning Time: 0.253 ms
 Execution Time: 0.225 ms

ちょいと気になるのでヒントでどうなるか追加で診ておきましょう。このケースでは改善。
pg_hint_planで索引スキャンでよりよくできますね。（データ量の影響だろうか。。）

perftestdb=> explain (analyze,verbose)
SELECT
  /*+
    IndexScan(orders pk_orders)
    IndexScan(customers pk_customers)
  */
  orders.order_id
  , orders.order_date
  , customers.first_name
FROM
  orders
  INNER JOIN customers
  ON
    orders.customer_id = customers.customer_id
WHERE
  customers.customer_id = COALESCE(:cust_id, customers.customer_id)
  AND orders.order_id = COALESCE(:order_id, orders.order_id);
  
                                             QUERY PLAN                                                    
--------------------------------------------------------------------------------------------------------------
  Nested Loop  (cost=0.29..16.34 rows=1 width=18) (actual time=0.039..0.043 rows=1 loops=1)
   Output: orders.order_id, orders.order_date, customers.first_name
   ->  Index Scan using pk_orders on public.orders  
              (cost=0.14..8.16 rows=1 width=16) (actual time=0.027..0.028 rows=1 loops=1)
         Output: orders.order_id, orders.order_date, orders.order_mode, orders.customer_id
                 , orders.order_status, orders.order_total, orders.sales_rep_id, orders.promotion_id
         Index Cond: (orders.order_id = 2435)
         Filter: (orders.customer_id = 144)
   ->  Index Scan using pk_customers on public.customers  
              (cost=0.15..8.17 rows=1 width=10) (actual time=0.008..0.010 rows=1 loops=1)
         Output: customers.customer_id, customers.first_name, customers.last_name
                 , customers.address, customers.phone_number
         Index Cond: (customers.customer_id = 144)
 Planning Time: 0.290 ms
 Execution Time: 0.083 ms

3) 1)の対策後。動的SQLにしてWHERE句を除外するだけです

無駄なWHERE句が消えて、スッキリ。こちらもOracle Databaseの改善後に類似したMerge Joinになってますね。直積が無くなってますねーーーー

perftestdb=> \pset null [null]
Null表示は"[null]"です。
perftestdb=> \set cust_id NULL
perftestdb=> \set order_id NULL
perftestdb=> \echo :cust_id
NULL
perftestdb=> \echo :order_id
NULL
perftestdb=> 
perftestdb=> explain (analyze,verbose)
perftestdb-> SELECT
perftestdb->   orders.order_id
perftestdb->   , orders.order_date
perftestdb->   , customers.first_name
perftestdb-> FROM
perftestdb->   orders
perftestdb->   INNER JOIN customers
perftestdb->   ON
perftestdb->     orders.customer_id = customers.customer_id
perftestdb-> ;
                                          QUERY PLAN                                     
-----------------------------------------------------------------------------------------------------
 Merge Join  (cost=5.72..11.81 rows=105 width=18) (actual time=0.116..0.240 rows=105 loops=1)
   Output: orders.order_id, orders.order_date, customers.first_name
   Merge Cond: (customers.customer_id = orders.customer_id)
   ->  Index Scan using pk_customers on public.customers  (cost=0.15..19.93 rows=319 width=10) 
                                                          (actual time=0.012..0.040 rows=71 loops=1)
         Output: customers.customer_id, customers.first_name
                 , customers.last_name, customers.address, customers.phone_number
   ->  Sort  (cost=5.57..5.84 rows=105 width=16) (actual time=0.098..0.118 rows=105 loops=1)
         Output: orders.order_id, orders.order_date, orders.customer_id
         Sort Key: orders.customer_id
         Sort Method: quicksort  Memory: 29kB
         ->  Seq Scan on public.orders  (cost=0.00..2.05 rows=105 width=16) 
                                        (actual time=0.012..0.047 rows=105 loops=1)
               Output: orders.order_id, orders.order_date, orders.customer_id
 Planning Time: 0.324 ms
 Execution Time: 0.289 ms

4) 3)と同様の対策。動的SQLにしてCOALESCE関数を利用しない。一般的な条件を付加するだけです。

データ少ないからか、Seq Scanのままですね。
まじかw

perftestdb=> \pset null [null]
Null表示は"[null]"です。
perftestdb=> \set cust_id 144
perftestdb=> \set order_id 2435
perftestdb=> \echo :cust_id
144
perftestdb=> \echo :order_id
2435
perftestdb=> explain (analyze,verbose)
perftestdb-> SELECT
perftestdb->   orders.order_id
perftestdb->   , orders.order_date
perftestdb->   , customers.first_name
perftestdb-> FROM
perftestdb->   orders
perftestdb->   INNER JOIN customers
perftestdb->   ON
perftestdb->     orders.customer_id = customers.customer_id
perftestdb-> WHERE
perftestdb->   customers.customer_id = :cust_id
perftestdb->   AND orders.order_id = :order_id;

                                               QUERY PLAN                                                    
----------------------------------------------------------------------------------------------------------------
 Nested Loop  (cost=0.00..10.57 rows=1 width=18) (actual time=0.037..0.097 rows=1 loops=1)
   Output: orders.order_id, orders.order_date, customers.first_name
   ->  Seq Scan on public.orders  (cost=0.00..2.58 rows=1 width=16) 
                                                             (actual time=0.022..0.039 rows=1 loops=1)
         Output: orders.order_id, orders.order_date, orders.order_mode, orders.customer_id
         　　　　　, orders.order_status, orders.order_total, orders.sales_rep_id, orders.promotion_id
         Filter: ((orders.customer_id = 144) AND (orders.order_id = 2435))
         Rows Removed by Filter: 104
   ->  Seq Scan on public.customers  (cost=0.00..7.99 rows=1 width=10) 
                                                                (actual time=0.011..0.053 rows=1 loops=1)
         Output: customers.customer_id, customers.first_name, customers.last_name
         　　　　　, customers.address, customers.phone_number
         Filter: (customers.customer_id = 144)
         Rows Removed by Filter: 318
 Planning Time: 0.199 ms
 Execution Time: 0.132 ms

pg_hint_planでIndexScanを強制してみましょう。。すんなり改善。
プランナーの判断だと索引使ってくれなかったのですが、ヒントで改善できる状況は確認。状況に応じて人がアシストしてあげるのがいいですかね。

perftestdb=> explain (analyze,verbose)
perftestdb-> SELECT
perftestdb->   /*+
perftestdb*>     IndexScan(orders pk_orders)
perftestdb*>     IndexScan(customers pk_customers)
perftestdb*>   */
perftestdb->   orders.order_id
perftestdb->   , orders.order_date
perftestdb->   , customers.first_name
perftestdb-> FROM
perftestdb->   orders
perftestdb->   INNER JOIN customers
perftestdb->   ON
perftestdb->     orders.customer_id = customers.customer_id
perftestdb-> WHERE
perftestdb->   customers.customer_id = :cust_id
perftestdb->   AND orders.order_id = :order_id;

                                                               QUERY PLAN                                                                
------------------------------------------------------------------------------------------------------------------------------------------
 Nested Loop  (cost=0.29..16.34 rows=1 width=18) (actual time=0.039..0.043 rows=1 loops=1)
   Output: orders.order_id, orders.order_date, customers.first_name
   ->  Index Scan using pk_orders on public.orders  (cost=0.14..8.16 rows=1 width=16) 
                                                                               (actual time=0.027..0.028 rows=1 loops=1)
         Output: orders.order_id, orders.order_date, orders.order_mode, orders.customer_id
         　　　　　, orders.order_status, orders.order_total, orders.sales_rep_id, orders.promotion_id
         Index Cond: (orders.order_id = 2435)
         Filter: (orders.customer_id = 144)
   ->  Index Scan using pk_customers on public.customers  (cost=0.15..8.17 rows=1 width=10)  
                                                                                     (actual time=0.008..0.010 rows=1 loops=1)
         Output: customers.customer_id, customers.first_name, customers.last_name
         　　　　　, customers.address, customers.phone_number
         Index Cond: (customers.customer_id = 144)
 Planning Time: 0.290 ms
 Execution Time: 0.083 ms
(11 行)

まとめると、
当初の想定通りいいことは全くない！！　スマートなやりかたに見えているだけでしたよね
COALESCE関数をWHERE句で利用したスマートロジックはかなりリスキー。

今回試した全てのケースで、余分なフィルタリングが常に行われたりするリスクに加え、
PostgreSQLでは直積まで発生しちゃいました。やばいです。

ということで、

Mac De Oracle ブログ開設 20周年記念のエントリー。おわり。

では、まだ。

Enjoy SQLs! and Optimizers!

==== サンプルコード ====
Oracle Database側で簡易的に動的SQL化して生成した全件取得、キー指定版のSQLをPostgreSQL/MySQLで再利用しました。

Oracle database

SCOTT@orclpdb1> !cat testrun1.sql
set termout on
variable cust_id number
variable order_id number
set autop on 
set null [null]
exec :cust_id := &1
exec :order_id := &2

SELECT
  /*+
    gather_plan_statistics
  */
  orders.order_id
  , orders.order_date
  , customers.first_name
FROM
  orders
  INNER JOIN customers
  ON
    orders.customer_id = customers.customer_id
WHERE
  customers.customer_id = COALESCE(:cust_id, customers.customer_id)
  AND orders.order_id = COALESCE(:order_id, orders.order_id)
.
l
set termout off
/
set termout on
@show_actualplan.sql

-- 簡易的にSQL*PLus内で動的SQLを組み立てて実行
set feed off
set timi off
set head off
set termout off
set veri off
spool temp_sql.sql
SELECT 
  'SELECT
    /*+
      gather_plan_statistics
    */
    orders.order_id
    , orders.order_date
    , customers.first_name
  FROM
    orders
    INNER JOIN customers
    ON
      orders.customer_id = customers.customer_id '
  ||
  CASE 
    WHEN 
      :cust_id IS NOT NULL 
      AND :order_id IS NOT NULL
    THEN
        'WHERE
           customers.customer_id = :cust_id
           AND orders.order_id = :order_id'
  END
FROM
 dual;
select '.' from dual;
select 'l' from dual;
select 'set termout off' from dual;
select '/' from dual;
select 'set termout on' from dual;
select '@show_actualplan.sql' from dual;
spo off
set feed on
set timi on
set head on
set termout on
set veri on
@temp_sql.sql

undefine 1
undefine 2
undefine cust_id
undefine order_id

show_actualplan.sql

set long 20000
set longchunk 400
select * from table(dbms_xplan.display_cursor(format=>'ALL ALLSTATS LAST +OUTLINE'));

MySQL

set @cust_id = null;
set @order_id = null;
select @cust_id;
select @order_id;


--スマートロジック版（すまーとじゃないけど）
explain format=tree
SELECT
  orders.order_id
  , orders.order_date
  , customers.first_name
FROM
  orders
  INNER JOIN customers
  ON
    orders.customer_id = customers.customer_id
WHERE
  customers.customer_id = COALESCE(@cust_id, customers.customer_id)
  AND orders.order_id = COALESCE(@order_id, orders.order_id);


--動的SQL（生成済み全件取得のSQL)
explain format=tree
SELECT
  orders.order_id
  , orders.order_date
  , customers.first_name
FROM
  orders
  INNER JOIN customers
  ON
    orders.customer_id = customers.customer_id;
    

set @cust_id = 144;
set @order_id = 2435;
select @cust_id;
select @order_id;


--スマートロジック版（すまーとじゃないけど）
explain format=tree
SELECT
  orders.order_id
  , orders.order_date
  , customers.first_name
FROM
  orders
  INNER JOIN customers
  ON
    orders.customer_id = customers.customer_id
WHERE
  customers.customer_id = COALESCE(@cust_id, customers.customer_id)
  AND orders.order_id = COALESCE(@order_id, orders.order_id);


--動的SQL（生成済みキー指定のSQL)
explain format=tree
SELECT
  orders.order_id
  , orders.order_date
  , customers.first_name
FROM
  orders
  INNER JOIN customers
  ON
    orders.customer_id = customers.customer_id
WHERE
  customers.customer_id = @cust_id
  AND orders.order_id = @order_id;

PostgreSQL

\pset null [null]
\set cust_id NULL
\set order_id NULL
\echo :cust_id
\echo :order_id

--スマートロジック版（すまーとじゃないけど）
explain (analyze,verbose)
SELECT
  orders.order_id
  , orders.order_date
  , customers.first_name
FROM
  orders
  INNER JOIN customers
  ON
    orders.customer_id = customers.customer_id
WHERE
  customers.customer_id = COALESCE(:cust_id, customers.customer_id)
  AND orders.order_id = COALESCE(:order_id, orders.order_id);
  

--動的SQL（生成済み全件取得のSQL)
explain (analyze,verbose)
SELECT
  orders.order_id
  , orders.order_date
  , customers.first_name
FROM
  orders
  INNER JOIN customers
  ON
    orders.customer_id = customers.customer_id
;


\pset null [null]
\set cust_id 144
\set order_id 2435
\echo :cust_id
\echo :order_id


--スマートロジック版（すまーとじゃないけど）
explain (analyze,verbose)
SELECT
  orders.order_id
  , orders.order_date
  , customers.first_name
FROM
  orders
  INNER JOIN customers
  ON
    orders.customer_id = customers.customer_id
WHERE
  customers.customer_id = COALESCE(:cust_id, customers.customer_id)
  AND orders.order_id = COALESCE(:order_id, orders.order_id);


--スマートロジック版（すまーとじゃないけど、キー指定版、SQL hint付き）
explain (analyze,verbose)
SELECT
  /*+
    IndexScan(orders pk_orders)
    IndexScan(customers pk_customers)
  */
  orders.order_id
  , orders.order_date
  , customers.first_name
FROM
  orders
  INNER JOIN customers
  ON
    orders.customer_id = customers.customer_id
WHERE
  customers.customer_id = COALESCE(:cust_id, customers.customer_id)
  AND orders.order_id = COALESCE(:order_id, orders.order_id);
   

--動的SQL（生成済みキー指定のSQL、SQL hint付き)
explain (analyze,verbose)
SELECT
  /*+
    IndexScan(orders pk_orders)
    IndexScan(customers pk_customers)
  */
  orders.order_id
  , orders.order_date
  , customers.first_name
FROM
  orders
  INNER JOIN customers
  ON
    orders.customer_id = customers.customer_id
WHERE
  customers.customer_id = :cust_id
  AND orders.order_id = :order_id;


--動的SQL（生成済みキー指定のSQL)
explain (analyze,verbose)
SELECT
  orders.order_id
  , orders.order_date
  , customers.first_name
FROM
  orders
  INNER JOIN customers
  ON
    orders.customer_id = customers.customer_id
WHERE
  customers.customer_id = :cust_id
  AND orders.order_id = :order_id;

投稿日時 2025年5月26日 (月) 00時00分 Oracle, Oracle以外のデータベース, チューニング, FAQ, SQL, MySQL, PostgreSQL, パフォーマンス, NULL, Oracle Database 21c | 固定リンク | 0 | コメント (0)

2025年4月28日 (月)

とあるJargon絡みのおはなし

久々のDatabaseネタですw

先日、ぐるぐる系がほんとうに嫌いなんだなぁ、というアトモスフィアを感じる会話に交ぜてもらいww、
ちょっと思い出したことがあったので書いてみようと思います。
（悪いとか良いとかそういうくくりの話に振るつもりはないので、どの方法をどう使うか、よーく考えて判断しましょうね、ぐらいの気持ちで書いいてますw）

世の中には、意図的にぐるぐる系バッチだけ、index unique scanや、access by rowidだけになることを狙い、統計情報も意図的に設定（e.g. https://docs.oracle.com/cd/F82042_01/arpls/DBMS_STATS.html#GUID-F993ADFE-85A9-4939-84D1-CC7A6E5C56D2 など）したり、あたまを振り絞って考え抜かれた　ぐるぐる系　の世界があったります。
待機イベントは、DB cpu, db file sequential readが主体で。（私は、やりたいとは思わないけどw）

ところで、

ぐるぐる系ってのは、いわゆるN+1問題に類する処理。
フレームワーク起因でそうなりやすいやつだけでなく、意図的にぐるぐるしちゃうというのもすべて含めたもの。基本的にネガティブな意味で使われていますw。
そんなJargonが存在する現場では、的確に意図が伝わるってのがメリットだったり。。。
N+1がさぁ〜より、ぐるぐるがさぁ〜ってほうが日本語の脳みそにはイメージしやすくてグっと来るw 方は多い感じはしますw。現場でうまれたJargonですのでw　英語3文字略語よりわかりやすくて良い(個人差ありw)

もう一つ、ぐるぐる系の反対語のJargonって知ってます？

答え: ガツン系

ここまでの用語解説部分はツッコミいれるところではないので、かるくスルーしてくださいませ。前説ですから。　m(_ _)m

（ちょっと脱線しすぎた感じはするけどもwwww）

ということで（どう言うことだ！w）、ながーーーーーーい前置きはこれぐらいにして本題へ。

ぐるぐる系とガツン系の予習をしていただいたところでww
ちょっとしたサンプルを紹介し、どちらを選ぶかは、アナタしだいです。という意味で、打ちっぱなしというか投げっぱなしの話を書いておこう思います。

今回の例ではストアドプロシージャ化してあります。
ストアドプロシージャでぐるぐるしちゃった場合、ネットワークレイテンシーの影響は受けないのですが繰り返し部分のオーバーヘッド有無の差異は見えるはずです。
SQL文の繰り返しもそうですが、それ以外のオーバーヘッドも積もると山になるわけで。

なお、SQL文がものすごく軽いくて速い、かつ、バッチ専用の別サーバーで実行される場合は繰り返し実行されるロジックだけでなく、サーバー間のネットワークレイテンシーの影響が見過ごせないぐらい（回避不能でもありますが）目立ってくることも思い出してくださいね。
以下の図をイメージしておくと危険な香りを感じ取れるのではないか思います。（特にクラウド上では）

パートの処理時間は記載の時間程度かかるった場合のイメージで書いています。処理時間の延び具合も実際の処理だったり環境でも異なるのであくまで、そんなイメージにしてあります。

普通のぐるぐる系のイメージ（オンプレミスで隣接しているような環境だネットワークレイテンシーは短いのは言うまでもないですが）

普通のぐるぐる系がネットワークレイテンシーの遅い環境に乗せられてしまった場合のイメージ（オンプレミス環境で熟成されたぐるぐる系がクラウドに乗ったらこうなったなんて話は、稀によく聞きますw。しかも自分たちではどうしようもないですよね。こればかりは。）

普通のグルグル系のがネットワークレイテンシーの遅い環境に乗せられてしまった上に、実行計画がぶれて大変なことになってしまったイメージ

最後に、がツン系にして回避したイメージ

この辺り大切なので、試験にでるよ！（ないないw

利用したリリースは以下の通り。

Oracle Database 21c Enterprise Edition Release 21.0.0.0.0 - Production
Version 21.3.0.0.0

差分マージを例ネタに、ぐるぐる系とガツン系の例、そして、ぐるぐる系のループ内で実行されるSQL文の実行計画が最悪の状態でぐるぐるしている例を載せておきますね。

準備

以下ディレクトリにcsvファイルを作成してあります。連番で100000行のデータが入っています。

[oracle@localhost ~]$ ll /home/oracle/rowbyrow_or_batch/*.csv
-rw-r--r--. 1 oracle oinstall 588894  1月 16 14:39 /home/oracle/rowbyrow_or_batch/data.csv
[oracle@localhost ~]$ cat /home/oracle/rowbyrow_or_batch/data.csv
1
2
3
4

...中略...

99996
99997
99998
99999
100000
[oracle@localhost ~]$

差分データを外部表で提供するためにディレクトリオブジェクト、対応するディレクトリを作成します。

SCOTT@orclpdb1> create directory rowbyrow_or_batch as '/home/oracle/rowbyrow_or_batch';

ディレクトリが作成されました。

経過: 00:00:00.24
SCOTT@orclpdb1> select directory_name, directory_path from dba_directories where directory_name = upper('rowbyrow_or_batch');

DIRECTORY_NAME                 DIRECTORY_PATH
------------------------------ -------------------------------------------------
ROWBYROW_OR_BATCH              /home/oracle/rowbyrow_or_batch

経過: 00:00:00.09
SCOTT@orclpdb1>

次に外部表を定義します。この時点では該当ディレクトリにcsvファイルは実在しなくても問題ありませんが、実行前には対応するファイルシステムのディレクトとcsvファイルを作成、配置しておく必要はあります。
（外部表作成時にそれらの存在は確認されていないだけです）

SCOTT@orclpdb1> DROP TABLE csv_data PURGE;
SCOTT@orclpdb1> CREATE TABLE csv_data
(
  id NUMBER NOT NULL
)
ORGANIZATION EXTERNAL (
  TYPE ORACLE_LOADER
  DEFAULT DIRECTORY rowbyrow_or_batch
  ACCESS PARAMETERS (
    RECORDS DELIMITED BY NEWLINE
    FIELDS TERMINATED BY '|'
    (
      id
    )
  )
  LOCATION (
    'data.csv'
  )
);

表が作成されました。

経過: 00:00:00.03

SCOTT@orclpdb1> desc csv_data
 名前                                    NULL?    型
 ----------------------------------------- -------- ----------------------------
 ID                                        NOT NULL NUMBER

SCOTT@orclpdb1> select min(id),max(id),count(1) from csv_data;

   MIN(ID)    MAX(ID)   COUNT(1)
---------- ---------- ----------
         1     100000     100000

SCOTT@orclpdb1> select count(distinct id) from csv_data;

COUNT(DISTINCTID)
-----------------
           100000

差分データをマージする表を作成してデータを登録しておきます。（統計情報取得も忘れずに）

SCOTT@orclpdb1> CREATE TABLE tmp
(
 ID NUMBER NOT NULL
 , CONSTRAINT pk_tmp PRIMARY KEY (id) USING INDEX
);

表が作成されました。

経過: 00:00:00.17
SCOTT@orclpdb1> BEGIN
  FOR i in 50001..200000 LOOP
    INSERT INTO tmp VALUES(i);
    IF MOD(i,100) = 0 THEN COMMIT; END IF;
  END LOOP;
END;
/

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

経過: 00:00:08.57
SCOTT@orclpdb1> EXEC DBMS_STATS.GATHER_TABLE_STATS(ownname=>'SCOTT',tabname=>'TMP',cascade=>true, no_invalidate=>false);

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

経過: 00:00:01.86
SCOTT@orclpdb1> select min(id),max(id),count(1) from tmp;

   MIN(ID)    MAX(ID)   COUNT(1)
---------- ---------- ----------
     50001     200000     150000

経過: 00:00:00.03

はい！　準備完了。

上記表へ、csvファイルというか外部表との差分を追加する処理をぐるぐる系と、ガツン系。
そして、おまけで、荒れ狂う実行計画のうるぐるぐる系（ヒントを使って最悪の実行計画にしてるだけですが）w 実行してみましょう。

特に落ちはないですが、打ちっぱなしというか、投げぱなしにしますので、
みなさん、遠ーーーくを見ながら、あーだーこーだビール片手のおつまみにでもして考えてみるのも良いか、と。。

まず、ぐるぐる系から。

SCOTT@orclpdb1> select min(id),max(id),count(id) from tmp;

   MIN(ID)    MAX(ID)  COUNT(ID)
---------- ---------- ----------
     50001     200000     150000

経過: 00:00:00.01
SCOTT@orclpdb1>  exec rowbyrow_proc;

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

経過: 00:00:04.69
SCOTT@orclpdb1> select min(id),max(id),count(id) from tmp;

   MIN(ID)    MAX(ID)  COUNT(ID)
---------- ---------- ----------
         1     200000     200000

経過: 00:00:00.01

次は、ガツン系で。

SCOTT@orclpdb1> select min(id),max(id),count(id) from tmp;

   MIN(ID)    MAX(ID)  COUNT(ID)
---------- ---------- ----------
     50001     200000     150000

経過: 00:00:00.01
SCOTT@orclpdb1> exec allrows_batch_proc;

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

経過: 00:00:00.76
SCOTT@orclpdb1> select min(id),max(id),count(id) from tmp;

   MIN(ID)    MAX(ID)  COUNT(ID)
---------- ---------- ----------
         1     200000     200000

最後に、おまけ。　荒れ狂うぐるぐる系w。（繰り返し実行されるSQL文の実行計画が最悪という設定)
こうなっちゃた経験のある方も少ないないはず。荒れ狂わないように最良の実行計画に固定しちゃう予防策を取っておく方が安全ではあります。

SCOTT@orclpdb1> select min(id),max(id),count(id) from tmp;

   MIN(ID)    MAX(ID)  COUNT(ID)
---------- ---------- ----------
     50001     200000     150000

経過: 00:00:00.18
SCOTT@orclpdb1> exec badboy_rowbyrow_proc;

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

経過: 00:28:02.30
SCOTT@orclpdb1> select min(id),max(id),count(id) from tmp;

   MIN(ID)    MAX(ID)  COUNT(ID)
---------- ---------- ----------
         1     200000     200000

経過: 00:00:00.31

それぞれの実行計画も載せておきますね。

ぐるぐる系のrowbyrow_procプロシージャで実行したSQL文
(実際に3つの方法で確認してますが、monitor/gather_plan_statisticsヒントつけちゃってるのに、autotraceの結果だけのせているのでヒントが気になるかたは外しても問題ないです。多少処理時間は速くなるはずですが。)

MERGE
  /*+
    monitor
    gather_plan_statistics
    index(tmp pk_tmp)
  */
  INTO tmp
USING (
  SELECT
    :l_id AS id
  FROM
    dual
) diff_data
ON
  ( tmp.id = diff_data.id )
WHEN NOT MATCHED THEN
  INSERT VALUES
  (
    diff_data.id
  )
;

SCOTT@orclpdb1> l
  1  MERGE
  2    /*+
  3      monitor
  4      gather_plan_statistics
  5      index(tmp pk_tmp)
  6    */
  7    INTO tmp
  8  USING (
  9    SELECT
 10      :l_id AS id
 11    FROM
 12      dual
 13  ) diff_data
 14  ON
 15    ( tmp.id = diff_data.id )
 16  WHEN NOT MATCHED THEN
 17    INSERT VALUES
 18    (
 19      diff_data.id
 20*   )
SCOTT@orclpdb1> /

1行がマージされました。

経過: 00:00:00.02

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

-------------------------------------------------------------------------------
| Id  | Operation            | Name   | Rows  | Bytes | Cost (%CPU)| Time     |
-------------------------------------------------------------------------------
|   0 | MERGE STATEMENT      |        |     1 |    23 |     3   (0)| 00:00:01 |
|   1 |  MERGE               | TMP    |       |       |            |          |
|   2 |   VIEW               |        |       |       |            |          |
|   3 |    NESTED LOOPS OUTER|        |     1 |    23 |     3   (0)| 00:00:01 |
|   4 |     VIEW             |        |     1 |    18 |     3   (0)| 00:00:01 |
|   5 |      FAST DUAL       |        |     1 |       |     3   (0)| 00:00:01 |
|*  6 |     INDEX UNIQUE SCAN| PK_TMP |     1 |     5 |     0   (0)| 00:00:01 |
-------------------------------------------------------------------------------

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

   6 - access("TMP"."ID"(+)=TO_NUMBER("DIFF_DATA"."ID"))

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

ガツン系（allrows_batch_procプロシージャで実行）

MERGE
  /*+
    monitor
    gather_plan_statistics
    index_ffs(tmp pk_tmp)
  */
  INTO tmp
  USING (
    SELECT
      id
    FROM
      csv_data
  ) diff_data
  ON ( tmp.id = diff_data.id )
WHEN NOT MATCHED THEN
  INSERT VALUES
  (
    diff_data.id
  )
 ;

SCOTT@orclpdb1>
  1  MERGE
  2    /*+
  3      monitor
  4      gather_plan_statistics
  5      index_ffs(tmp pk_tmp)
  6    */
  7    INTO tmp
  8    USING (
  9      SELECT
 10        id
 11      FROM
 12        csv_data
 13    ) diff_data
 14    ON ( tmp.id = diff_data.id )
 15  WHEN NOT MATCHED THEN
 16    INSERT VALUES
 17    (
 18      diff_data.id
 19*   )
SCOTT@orclpdb1> /

50000行がマージされました。

経過: 00:00:00.60

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

------------------------------------------------------------------------------------------
| Id  | Operation                     | Name     | Rows  | Bytes | Cost (%CPU)| Time     |
------------------------------------------------------------------------------------------
|   0 | MERGE STATEMENT               |          |   100K|  1757K|   289  (15)| 00:00:01 |
|   1 |  MERGE                        | TMP      |       |       |            |          |
|   2 |   VIEW                        |          |       |       |            |          |
|*  3 |    HASH JOIN OUTER            |          |   100K|   976K|   289  (15)| 00:00:01 |
|*  4 |     EXTERNAL TABLE ACCESS FULL| CSV_DATA |   100K|   488K|    57  (20)| 00:00:01 |
|   5 |     INDEX FAST FULL SCAN      | PK_TMP   |   150K|   732K|   214   (6)| 00:00:01 |
------------------------------------------------------------------------------------------

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

   3 - access("TMP"."ID"(+)="ID")
   4 - filter(SYS_OP_XTNN("CSV_DATA"."ID"))

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

荒れ狂うぐるぐる系badboy_rowbyrow_procプロシージャで実行したSQL文
計測回数が少ないので参考程度ですが、荒れ狂ってない場合の同一SQLと比較して、4倍も遅い状況。（一回当たりは　0.08秒でも積み上がると笑えないですね）

MERGE
  /*+
    monitor
    gather_plan_statistics
    index_ffs(tmp pk_tmp)
  */
  INTO tmp
USING (
  SELECT
    :l_id AS id
  FROM
    dual
) diff_data
ON
  ( tmp.id = diff_data.id )
WHEN NOT MATCHED THEN
  INSERT VALUES
  (
    diff_data.id
  )
;

SCOTT@orclpdb1> l
  1  MERGE
  2    /*+
  3      monitor
  4      gather_plan_statistics
  5      index_ffs(tmp pk_tmp)
  6    */
  7    INTO tmp
  8  USING (
  9    SELECT
 10      :l_id AS id
 11    FROM
 12      dual
 13  ) diff_data
 14  ON
 15    ( tmp.id = diff_data.id )
 16  WHEN NOT MATCHED THEN
 17    INSERT VALUES
 18    (
 19      diff_data.id
 20*   )
SCOTT@orclpdb1> /

1行がマージされました。

経過: 00:00:00.08

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

----------------------------------------------------------------------------------
| Id  | Operation               | Name   | Rows  | Bytes | Cost (%CPU)| Time     |
----------------------------------------------------------------------------------
|   0 | MERGE STATEMENT         |        |     1 |    23 |   226  (10)| 00:00:01 |
|   1 |  MERGE                  | TMP    |       |       |            |          |
|   2 |   VIEW                  |        |       |       |            |          |
|*  3 |    HASH JOIN OUTER      |        |     1 |    23 |   226  (10)| 00:00:01 |
|   4 |     VIEW                |        |     1 |    18 |     3   (0)| 00:00:01 |
|   5 |      FAST DUAL          |        |     1 |       |     3   (0)| 00:00:01 |
|   6 |     INDEX FAST FULL SCAN| PK_TMP |   150K|   732K|   214   (6)| 00:00:01 |
----------------------------------------------------------------------------------

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

   3 - access("TMP"."ID"(+)=TO_NUMBER("DIFF_DATA"."ID"))

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

本日利用したコードは以下の通り（csvファイルを作成したコードは略）

create directory rowbyrow_or_batch as '/home/oracle/rowbyrow_or_batch';
select directory_name, directory_path from dba_directories where directory_name = upper('rowbyrow_or_batch');

DROP TABLE csv_data PURGE;
CREATE TABLE csv_data
(
  id NUMBER NOT NULL
)
ORGANIZATION EXTERNAL (
  TYPE ORACLE_LOADER
  DEFAULT DIRECTORY rowbyrow_or_batch
  ACCESS PARAMETERS (
    RECORDS DELIMITED BY NEWLINE
    FIELDS TERMINATED BY ','
    (
      id
    )
  )
  LOCATION (
    'data.csv'
  )
);

DROP TABLE tmp PURGE;
CREATE TABLE tmp
(
 ID NUMBER NOT NULL
 , CONSTRAINT pk_tmp PRIMARY KEY (id) USING INDEX
);

BEGIN
  FOR i in 50001..200000 LOOP
    INSERT INTO tmp VALUES(i);
    IF MOD(i,100) = 0 THEN COMMIT; END IF;
  END LOOP;
END;
/

EXEC DBMS_STATS.GATHER_TABLE_STATS(ownname=>'SCOTT',tabname=>'TMP',cascade=>true, no_invalidate=>false);


CREATE OR REPLACE PROCEDURE allrows_batch_proc AS
BEGIN
  MERGE
    /*+
      monitor
      gather_plan_statistics
      index_ffs(tmp pk_tmp)
    */
    INTO tmp
    USING (
      SELECT
        id
      FROM
        csv_data
    ) diff_data
    ON ( tmp.id = diff_data.id )
  WHEN NOT MATCHED THEN
    INSERT VALUES
    (
      diff_data.id
    );
  COMMIT;
EXCEPTION
  WHEN OTHERS THEN
    ROLLBACK;
    RAISE;
END;
/

CREATE OR REPLACE PROCEDURE rowbyrow_proc AS
  C_DIR CONSTANT VARCHAR2(30) := 'ROWBYROW_OR_BATCH';
  C_FILE_NAME CONSTANT VARCHAR2(30) := 'data.csv';
  C_BUFFERSIZE CONSTANT BINARY_INTEGER := 32767;
  C_OPENMODE CONSTANT VARCHAR2(2) := 'r';
  fileHandle UTL_FILE.FILE_TYPE;
  line VARCHAR2(32767);
  l_id NUMBER;
  rowcount NUMBER;
BEGIN
  fileHandle := UTL_FILE.FOPEN(C_DIR, C_FILE_NAME, C_OPENMODE, C_BUFFERSIZE);
  BEGIN
    LOOP
      UTL_FILE.GET_LINE(fileHandle, line, C_BUFFERSIZE);
      l_id := TO_NUMBER(line);

      MERGE
        /*+
          monitor
          gather_plan_statistics
          index(tmp pk_tmp)
        */
        INTO tmp
      USING (
        SELECT
          l_id AS id
        FROM
          dual
      ) diff_data
      ON
        ( tmp.id = diff_data.id )
      WHEN NOT MATCHED THEN
        INSERT VALUES
        (
          diff_data.id
        );

      rowcount := rowcount + 1;
       IF MOD(rowcount, 100) = 0 THEN
         COMMIT;
         NULL;
       END IF;
    END LOOP;

  EXCEPTION
    WHEN NO_DATA_FOUND THEN  /* EOF */
      NULL;
  END;
  COMMIT;
  UTL_FILE.FCLOSE(fileHandle);
EXCEPTION
  WHEN OTHERS THEN
    ROLLBACK;
    IF UTL_FILE.IS_OPEN(fileHandle) THEN
      UTL_FILE.FCLOSE(fileHandle);
    END IF;
    RAISE;
END;
/

CREATE OR REPLACE PROCEDURE badboy_rowbyrow_proc AS
  C_DIR CONSTANT VARCHAR2(30) := 'ROWBYROW_OR_BATCH';
  C_FILE_NAME CONSTANT VARCHAR2(30) := 'data.csv';
  C_BUFFERSIZE CONSTANT BINARY_INTEGER := 32767;
  C_OPENMODE CONSTANT VARCHAR2(2) := 'r';
  fileHandle UTL_FILE.FILE_TYPE;
  line VARCHAR2(32767);
  l_id NUMBER;
  rowcount NUMBER;
BEGIN
  fileHandle := UTL_FILE.FOPEN(C_DIR, C_FILE_NAME, C_OPENMODE, C_BUFFERSIZE);
  BEGIN
    LOOP
      UTL_FILE.GET_LINE(fileHandle, line, C_BUFFERSIZE);
      l_id := TO_NUMBER(line);

      MERGE
        /*+
          monitor
          gather_plan_statistics
          index_ffs(tmp pk_tmp)
        */
        INTO tmp
      USING (
        SELECT
          l_id AS id
        FROM
          dual
      ) diff_data
      ON
        ( tmp.id = diff_data.id )
      WHEN NOT MATCHED THEN
        INSERT VALUES
        (
          diff_data.id
        );

      rowcount := rowcount + 1;
       IF MOD(rowcount, 100) = 0 THEN
         COMMIT;
         NULL;
       END IF;
    END LOOP;

  EXCEPTION
    WHEN NO_DATA_FOUND THEN  /* EOF */
      NULL;
  END;
  COMMIT;
  UTL_FILE.FCLOSE(fileHandle);
EXCEPTION
  WHEN OTHERS THEN
    ROLLBACK;
    IF UTL_FILE.IS_OPEN(fileHandle) THEN
      UTL_FILE.FCLOSE(fileHandle);
    END IF;
    RAISE;
END;
/

Enjoy SQL!

今年は、桜吹雪を2回も見ることができたのですが、おそらく、20年ぶりw
では、また。

投稿日時 2025年4月28日 (月) 12時00分 Oracle, PL/SQL, チューニング, SQL, Cloud computing, パフォーマンス, B*Tree | 固定リンク | 0 | コメント (0)

2025年1月30日 (木)

実行計画は, SQL文のレントゲン写真だ！ No.65 / 忘れ去られたオプティマイザーヒントとTABLE ACCESS BY USER ROWID

2025年最初のレントゲン写真ネタです。今日は、みなさん（私も忘れてましたw）、忘れちゃってると思う（あまり使うこともないので）ROWIDの話題で、2025年最初のSQLネタエントリーにしたいと思います。（他のネタを考えていたのですが、軽めのネタにしてみましたw）

ROWIDヒント、今現存公開されている最古のオンラインマニュアルでは、Oracle 7 Server 7.3.3 以降から9iのマニュアルに記載されています。（もっと前からあるよね〜。7.0のマニュアルとか流石に見つからないので確認できないですがw）
で、主役ではなくなりほぼ使われなくなったヒントとして、忘れ去られてしまうきっかけは、Oracle Database 10g以降のマニュアルに記載されなくなったことが大きいでしょうね。使うこともほぼ無いと言って良いヒントだからかなぁ
昔すぎて覚えてないですねw

他にも、使ってもらっては困る黒魔術的なヒントもマニュアルから隠されたりしたこともありました。v$sql_hintには残ってますが11g以降サポートされなくなりヒントを指定しても無視されるようになった有名なヒントですね。。。。w　（まだ利用できたバージョンで、某氏が使おうとした黒魔術を必死で止めた思い出が蘇るw）
余談はこれぐらいで、本題へ。

現在確認できるオンラインマニュアルだと9iまで記載されていることが確認できます。
Oracle7 Server 7.3.3
Oracle7 Tuning, release 7.3.3 / Optimization Modes and Hints / Hints for Access Methods / ROWID

Oracle Database 8i 8.1.7
Oracle8i SQL リファレンス Vol.1 リリース 8.1 P.92 / ヒント / アクセス方法のヒント / ROWID

Oracle Database 9iR2
Oracle9i Database Performance Tuning Guide and Reference Release 2 (9.2) / ROWID

10g以降のマニュアルからは表記が消えています。ただし、v$sql_planには残っており、これまで通りに使えます（もそもそのアクセスパスを利用すること自体、かなりレアな状況ですよね :)
Oracle Database 10gR2
Oracle Database Online Documentation, 10g Release 2 (10.2) / Administration Database Performance Tuning Guide / 16 Using Optimizer Hints / 16.1.2.2 Hints for Access Paths

Oracle Database 11gR2
Oracle Database SQL言語リファレンス 11gリリース2 (11.2) / コメント / 表3-21 機能のカテゴリに分類したヒント

21cで確かめてみましょう。

Oracle Database 21c Enterprise Edition Release 21.0.0.0.0 - Production
Version 21.3.0.0.0

SCOTT@orclpdb1> select * from v$sql_hint where name = 'ROWID';

NAME       SQL_FEATUR CLASS      INVERSE    TARGET_LEVEL   PROPERTY VERSION    VERSION_OU     CON_ID
---------- ---------- ---------- ---------- ------------ ---------- ---------- ---------- ----------
ROWID      QKSFM_CBO  ACCESS                           4        272 8.0.0      8.1.7               0

ROWID擬似列でそれぞれのROWIDを取り出してみますね。むかーし、ROWIDを使って、データブロック番号順にソートして性能問題を回避したことありましたっけw ( db tech showcase Tokyo 2013 - A35 特濃JPOUG：潮溜まりでジャブジャブ、SQLチューニング / バッファキャッシュ欠乏症 )

SCOTT@orclpdb1> select rowid,empno,ename from emp;

ROWID                   EMPNO ENAME
------------------ ---------- ------------------------------
AAASguAAMAAAACTAAA       7369 SMITH
AAASguAAMAAAACTAAB       7499 ALLEN
AAASguAAMAAAACTAAC       7521 WARD
AAASguAAMAAAACTAAD       7566 JONES
AAASguAAMAAAACTAAE       7654 MARTIN
AAASguAAMAAAACTAAF       7698 BLAKE
AAASguAAMAAAACTAAG       7782 CLARK
AAASguAAMAAAACTAAH       7839 KING
AAASguAAMAAAACTAAI       7844 TURNER
AAASguAAMAAAACTAAJ       7900 JAMES
AAASguAAMAAAACTAAK       7902 FORD
AAASguAAMAAAACTAAL       7934 MILLER

12行が選択されました。

まずROWIDヒントを使わず、単純に、ROWID疑義列を使って一本引きw

すごいですよね。ピンポイントでアクセスするので1blockだけしか読みこんんでないですよね。
（ROWID関する注意などはマニュアルを見てくさだい。特にROWIDのリスキーな使い方などがわかると思うので。むかーーーーし、むかーーーし、ROWIDに仕様変更がありそういう使い方をしていたシステムの移行はかなり大変だったらしい。私は幸いなことにそういつ使い方をしていたシステムに出会わなかったのでラッキーではありましたが。。）

SCOTT@orclpdb1> set autot trace exp stat
SCOTT@orclpdb1> select * from emp where rowid = 'AAASguAAMAAAACTAAA';

経過: 00:00:00.05

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

-----------------------------------------------------------------------------------
| Id  | Operation                  | Name | Rows  | Bytes | Cost (%CPU)| Time     |
-----------------------------------------------------------------------------------
|   0 | SELECT STATEMENT           |      |     1 |    39 |     1   (0)| 00:00:01 |
|   1 |  TABLE ACCESS BY USER ROWID| EMP  |     1 |    39 |     1   (0)| 00:00:01 |
-----------------------------------------------------------------------------------


統計
----------------------------------------------------------
          0  recursive calls
          0  db block gets
          1  consistent gets
          0  physical reads
          0  redo size
       1142  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

さて、意地悪な実験ですw TABLE ACCESS BY USER ROWIDとなるところをですが、INDEXヒントやFULLヒントで抑止してみるととうなるか見ておきましょう。（想像通りだと思いますけども）

SCOTT@orclpdb1> select /*+ FULL(emp) */ * from emp where rowid = 'AAASguAAMAAAACTAAA';

経過: 00:00:00.01

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

--------------------------------------------------------------------------
| Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |      |     1 |    39 |     6   (0)| 00:00:01 |
|*  1 |  TABLE ACCESS FULL| EMP  |     1 |    39 |     6   (0)| 00:00:01 |
--------------------------------------------------------------------------

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

   1 - filter(ROWID='AAASguAAMAAAACTAAA')


統計
----------------------------------------------------------
          1  recursive calls
          0  db block gets
          7  consistent gets
          0  physical reads
          0  redo size
       1142  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

SCOTT@orclpdb1> select /*+ INDEX(emp) */ * from emp where rowid = 'AAASguAAMAAAACTAAA';

経過: 00:00:00.07

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

----------------------------------------------------------------------------------------------
| Id  | Operation                           | Name   | Rows  | Bytes | Cost (%CPU)| Time     |
----------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                    |        |     1 |    39 |     2   (0)| 00:00:01 |
|   1 |  TABLE ACCESS BY INDEX ROWID BATCHED| EMP    |     1 |    39 |     2   (0)| 00:00:01 |
|*  2 |   INDEX FULL SCAN                   | PK_EMP |     1 |       |     1   (0)| 00:00:01 |
----------------------------------------------------------------------------------------------

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

   2 - filter(ROWID='AAASguAAMAAAACTAAA')


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

最後に、ROWIDヒントが使えることをSQL Hint Reportも含めて確認してみましょう。

SCOTT@orclpdb1> set autot off
SCOTT@orclpdb1> select /*+ gather_plan_statistics rowid(emp) */ * from emp where rowid = 'AAASguAAMAAAACTAAA';

     EMPNO ENAME                          JOB                                MGR HIREDATE        SAL       COMM     DEPTNO
---------- ------------------------------ --------------------------- ---------- -------- ---------- ---------- ----------
      7369 SMITH                          CLERK                             7902 80-12-17        800                    20

経過: 00:00:00.00
SCOTT@orclpdb1> @show_actualplan

PLAN_TABLE_OUTPUT
------------------------------------------------------------------------------------------------------------------------------
SQL_ID  69yuykdp7c1za, child number 0
-------------------------------------
select /*+ gather_plan_statistics rowid(emp) */ * from emp where rowid
= 'AAASguAAMAAAACTAAA'

Plan hash value: 1116584662

-----------------------------------------------------------------------------------------------------------------------------
| Id  | Operation                  | Name | Starts | E-Rows |E-Bytes| Cost (%CPU)| E-Time   | A-Rows |   A-Time   | Buffers |
-----------------------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT           |      |      1 |        |       |     1 (100)|          |      1 |00:00:00.01 |       1 |
|   1 |  TABLE ACCESS BY USER ROWID| EMP  |      1 |      1 |    39 |     1   (0)| 00:00:01 |      1 |00:00:00.01 |       1 |
-----------------------------------------------------------------------------------------------------------------------------

Query Block Name / Object Alias (identified by operation id):
-------------------------------------------------------------

   1 - SEL$1 / "EMP"@"SEL$1"

Outline Data
-------------

  /*+
      BEGIN_OUTLINE_DATA
      IGNORE_OPTIM_EMBEDDED_HINTS
      OPTIMIZER_FEATURES_ENABLE('21.1.0')
      DB_VERSION('21.1.0')
      ALL_ROWS
      OUTLINE_LEAF(@"SEL$1")
      ROWID(@"SEL$1" "EMP"@"SEL$1")
      END_OUTLINE_DATA
  */

Column Projection Information (identified by operation id):
-----------------------------------------------------------

   1 - "EMP"."EMPNO"[NUMBER,22], "EMP"."ENAME"[VARCHAR2,10], "EMP"."JOB"[VARCHAR2,9], "EMP"."MGR"[NUMBER,22],
       "EMP"."HIREDATE"[DATE,7], "EMP"."SAL"[NUMBER,22], "EMP"."COMM"[NUMBER,22], "EMP"."DEPTNO"[NUMBER,22]

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

   1 -  SEL$1 / "EMP"@"SEL$1"
           -  rowid(emp)

Enjoy SQL

では、また。

投稿日時 2025年1月30日 (木) 12時00分 Oracle, チューニング, FAQ, SQL, パフォーマンス | 固定リンク | 0 | コメント (0)

2024年12月27日 (金)

先生！、全行アクセスしてるのに Nested Loop Join しちゃうんです！　（東京都　ITエンジニア男性） - optimizer_mode は正しく設定しましょう！

ということで、（どういうことだw
（今日のねたはアドベントカレンダーのネタを考えていた時に思い出したネタです）

さて、本題。

Oracle DatabaseのSQLチューニングや実行計画の読み方を学び始めたとき、最初に学ぶ（多分）、コストベースオプティマイザが作り出す実行計画に大きく影響を与える初期化パラメータ。
そのパラメータは何か？、
みなさん、パッと思う浮かでしょうか？

_optim_peek_user_binds ってアンダースコアパラメータを思い浮かべた方は居ないはず！（と断言してしまったが、意外と結構居たりして..

それは絶対にないと信じwww、
今日は、 optimizer_mode 初期化パラメータのお話をしてみたいと思います。

冒頭で書いたようにに、 Oracle Database の実行計画やSQLチューニングを学び始めたときに、最初に習う、覚えるのは、このパラメータだったと。思う（私の記憶ではw 私の場合、その最初の頃が昔すぎて怪しい）

それが、
optimizer_modeパラメータです。

この類のパラメータがあるのは Oracle Database だけではないかと思います。
例えば、Hash Join/Merge Joinを無効にして、Nested Loop Joinだけにするなど複数のオプションを組み合わせて似たような挙動にすることはできるものは多いですが、Oracle Databaseのように単一パラメータで、緩めに制御できるのは他にはないと思います。

このパラメータ、むかーーーーーーーーーーーーーーーしからあって、現在の ALL_ROWS/FISRT_ROWS_N というオプションになる前はCHOOSEやRULEというオプションがありました。
これは、Oracle Database 10gリリース1(10.1) 10gR1でルールベースオプティマイザが非サポートとなったタイミングで廃止され、現在この初期化パラメータがサポートしているオプションは以下のようになっています。デフォルトは ALL_ROWS です。

Database / Oracle / Oracle Database / Release 19 / Database Reference / 1.248 OPTIMIZER_MODE https://docs.oracle.com/en/database/oracle/oracle-database/19/refrn/OPTIMIZER_MODE.html

OPTIMIZER_MODE = { FIRST_ROWS_[1 | 10 | 100 | 1000] | FIRST_ROWS | ALL_ROWS }

このパラメータのオプションの特徴をざっくり解説してしまうと、
optimizer_mode = ALL_ROWSだとスループットを最大限にする実行計画が選択されます。（一般的にバッチだったり、分析系のSQLの実行計画に向いているのがこのモードで、デフォルトはこれです）
optimizer_mode = FIRST_ROWS_Nに設定した場合、N行の結果を如何に速く返すか、つまり、レスポンスタイムの良さを実現するための実行計画が選択されます。（一般的にはOLTP向きとされる実行計画になります。結合方法として Nested Loop Joinが選ばれやすくなります。全行じゃなくても最初の１行を早くクライアントへ返してあげられるような実行計画になりやすいですのがこのモードです）

ちなみに　FIRST_ROWS は下位互換として残されているだけなので最近では使うことはないです。

ALL_ROWSがデフォルトなので、多くの場合、デフォルトのままで、OLTP系のSQLでは、index scanや、nested loop joinになるようにWHERE句を記述したり、ヒント等で制御したりしているケースが多いのではないでしょうか？
一方、optimizer_mode = first_rows_n　に設定しておき, OLTP向きの実行計画をデフォルトで選択しやすい状況にしているケースもそれなりに見かけます（かなり少ないと思いますが、ちゃんと考えて設定しているという意味では、自分たちのシステムのワークロードで重要なのはどれだ！　認識している証かもしれません。どちらにするかは方針次第ではあるのですが。）

と、ここまでが、ながーーーい前説ですw

今回のタイトル　”先生！、全行アクセスしてるのに、Nested Loop Joinしちゃうんです！” 　

もうお分かりですねw　今日のネタ。

今日の患者さん、 optimizer_mode = first_rows_1 となっている環境で、where句もない結合を伴うクエリーが、Nested Loop Joinで、全行読み込んでしまったことに悩んでいました。
optimizer_mode = first_rows_n という設定になっていることにも気づいてなかったようですね。 all_rows の感覚のままでいると戸惑うのも当然です。

チューニング前に、オプティマイザに影響する初期化パラメータを確認しておくことをお勧めします！！！
チューニングをお願いされた場合、該当する初期化パラメータの設定も一緒に提供してもらう。
セッションレベルで変更されている場合もあるので、それらの情報も提供してもらうことが大切ですよ。忘れないでくださいね。
それらパラメータ情報も、ERに運び込まれた患者SQLを救うには大切な情報なのです！

このケースの場合、治療は非常に簡単で、初期化パラメータ optimizer_mode はそのままで、 ALL_ROWS ヒントを該当SQLに埋め込むのが手っ取り早いと思います。セッションレベルで optimizer_mode = all_rowsにするのもありです。

強力なヒントではないので軽視されがちな初期化パラメータですが、実は、ひょんなことで、その実力に気付いたりするものですwwwwwwww
ただ、ざっくりとした実行計画の傾向を支持するものなので、追加のヒントで矯正したりする必要もあることは忘れないでください。

では、早速、その効力を確認することにします。 21cを利用します。古くても新しくても挙動は同じです、
また、ネタ的に面白いので一時表での挙動も含めています　：）
一時表は統計情報の持ち方等が永続表とは異なるので別の注意が必要です。（参考　津島博士のパフォーマンス講座　第35回　オプティマイザ統計の運用について（２））

統計情報に影響され難い例なので、知っておくと、どこかで役立つと思いますよ！多分。:)

まず、環境と今回の主役となる初期化パラメータの確認から。

optimizer_dynamic_sampling
optimizer_mode
をセッションレベルで制御。ヒント制御しても同じ。
（なお、optimizer_adaptive_plansが発動すると分かりにくくなるので無効化しておきます）

SCOTT@orclpdb1> select banner_full from v$version;

BANNER_FULL
----------------------------------------------------------------------------------------------------
Oracle Database 21c Enterprise Edition Release 21.0.0.0.0 - Production
Version 21.3.0.0.0

SCOTT@orclpdb1> show parameter optimizer_mode

NAME                                 TYPE                              VALUE
------------------------------------ --------------------------------- ------------------------------
optimizer_mode                       string                            ALL_ROWS

SCOTT@orclpdb1> show parameter optimizer_dynamic_sampling

NAME                                 TYPE                              VALUE
------------------------------------ --------------------------------- ------------------------------
optimizer_dynamic_sampling           integer                           2

SCOTT@orclpdb1> show parameter optimizer_adaptive_plans

NAME                                 TYPE                              VALUE
------------------------------------ --------------------------------- ------------------------------
optimizer_adaptive_plans             boolean                           TRUE

前提条件は以下の通り。

1. 表には大量のデータが登録されている。
2. 2表をINNNER JOINするが、WHERE句のないクエリー。
3. 統計の無い状態、無いが動的統計有効、それに統計のある状態、それぞれで検証

普通に考えれば、table full scan + Hash Joinが実行計画として選択されるケースですが、、、どうなりますか。ニヤニヤ。（想像できる結果なのでw

一時表での実行計画から確認してみます。

統計情報なし、動的統計取得なし、Adaptive plansも無効です。 データ量、SQL文ではWHERE句による絞り込み条件も無いため、全表走査＋ハッシュ結合となって欲しいケースですが、 first_row_1 と all_rows の違いは如何に。。。

SCOTT@orclpdb1> alter session set optimizer_adaptive_plans = false;

セッションが変更されました。

SCOTT@orclpdb1> alter session set optimizer_dynamic_sampling = 0;

セッションが変更されました。

SCOTT@orclpdb1> alter session set optimizer_mode = first_rows_1;

セッションが変更されました。

SCOTT@orclpdb1> create global temporary table hoge_tmp (id number not null primary key, memo varchar2(100)) on commit preserve rows;

表が作成されました。

SCOTT@orclpdb1> create global temporary table hoge_tmp2 (id number not null primary key, memo varchar2(100)) on commit preserve rows;

表が作成されました。

SCOTT@orclpdb1> select table_name,num_rows from user_tables where table_name in ('HOGE_TMP','HOGE_TMP2');

TABLE_NAME                       NUM_ROWS
------------------------------ ----------
HOGE_TMP
HOGE_TMP2

SCOTT@orclpdb1> select table_name,index_name,num_rows from user_indexes where table_name in ('HOGE_TMP','HOGE_TMP2');

TABLE_NAME                     INDEX_NAME                       NUM_ROWS
------------------------------ ------------------------------ ----------
HOGE_TMP                       SYS_C0010733
HOGE_TMP2                      SYS_C0010735

SCOTT@orclpdb1> select table_name,num_rows,scope from user_tab_statistics where table_name in ('HOGE_TMP','HOGE_TMP2');

TABLE_NAME                       NUM_ROWS SCOPE
------------------------------ ---------- ---------------------
HOGE_TMP                                  SHARED
HOGE_TMP2                                 SHARED

SCOTT@orclpdb1> select table_name,index_name,num_rows,scope from user_ind_statistics where table_name in ('HOGE_TMP','HOGE_TMP2');

TABLE_NAME                     INDEX_NAME                       NUM_ROWS SCOPE
------------------------------ ------------------------------ ---------- ---------------------
HOGE_TMP                       SYS_C0010733                              SHARED
HOGE_TMP2                      SYS_C0010735                              SHARED

SCOTT@orclpdb1> begin for i in 1..100000 loop insert into hoge_tmp values(i,lpad('x',100,'x')); if mod(i,1000) = 0 then commit; end if; end loop; end;
  2  /

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

SCOTT@orclpdb1> begin for i in 1..100000 loop insert into hoge_tmp2 values(i,lpad('x',100,'x')); if mod(i,1000) = 0 then commit; end if; end loop; end;
  2  /

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

SCOTT@orclpdb1> select table_name,num_rows from user_tables where table_name in ('HOGE_TMP','HOGE_TMP2');

TABLE_NAME                       NUM_ROWS
------------------------------ ----------
HOGE_TMP
HOGE_TMP2

SCOTT@orclpdb1> select table_name,index_name,num_rows from user_indexes where table_name in ('HOGE_TMP','HOGE_TMP2');

TABLE_NAME                     INDEX_NAME                       NUM_ROWS
------------------------------ ------------------------------ ----------
HOGE_TMP                       SYS_C0010733
HOGE_TMP2                      SYS_C0010735

SCOTT@orclpdb1> select table_name,num_rows,scope from user_tab_statistics where table_name in ('HOGE_TMP','HOGE_TMP2');

TABLE_NAME                       NUM_ROWS SCOPE
------------------------------ ---------- ---------------------
HOGE_TMP                                  SHARED
HOGE_TMP2                                 SHARED

SCOTT@orclpdb1> select table_name,index_name,num_rows,scope from user_ind_statistics where table_name in ('HOGE_TMP','HOGE_TMP2');

TABLE_NAME                     INDEX_NAME                       NUM_ROWS SCOPE
------------------------------ ------------------------------ ---------- ---------------------
HOGE_TMP                       SYS_C0010733                              SHARED
HOGE_TMP2                      SYS_C0010735                              SHARED

あらびっくり！（知ってたけどw
100,000行の結合がNested Loop Joinになっています。駆動表は Table full scan しちゃってます。って（WHERE句ないのでここは当然ですがw）
問題は、Nested Loop Joinになっている。INDEX UNIQUE SCANを 100,000回ぐるぐる繰り返しているということになります！　まじですw

一時表で統計情報もなくて、動的統計取得も無効されている影響だな！　そう思ったあなた。そういうケースもありますがw
WHERE句もないSQLでNested Loop Joinを選択してしまうのは危険ですよ。(昔は特殊な事情で、それでもこれで行くか〜というレアなこともなくはなかったですがw　最近はほぼないですからね)

（後半で、統計情報なんて関係ねぇってネタをご用意してありますので、長いですがお付き合いくださいw）

SCOTT@orclpdb1> -- 一時表（Global Temporary Table）のセッション固有統計なし
SCOTT@orclpdb1> alter session set optimizer_adaptive_plans = false;

セッションが変更されました。

SCOTT@orclpdb1> alter session set optimizer_dynamic_sampling = 0;

セッションが変更されました。

SCOTT@orclpdb1> alter session set optimizer_mode = first_rows_1;

セッションが変更されました。

SCOTT@orclpdb1> set autot trace exp stat
SCOTT@orclpdb1> select * from hoge_tmp a inner join hoge_tmp2 b on a.id = b.id;

100000行が選択されました。

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

---------------------------------------------------------------------------------------------
| Id  | Operation                    | Name         | Rows  | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT             |              |     1 |   130 |     4   (0)| 00:00:01 |
|   1 |  NESTED LOOPS                |              |     1 |   130 |     4   (0)| 00:00:01 |
|   2 |   TABLE ACCESS FULL          | HOGE_TMP     |  8168 |   518K|     3   (0)| 00:00:01 |
|   3 |   TABLE ACCESS BY INDEX ROWID| HOGE_TMP2    |     1 |    65 |     1   (0)| 00:00:01 |
|*  4 |    INDEX UNIQUE SCAN         | SYS_C0010735 |     1 |       |     0   (0)| 00:00:01 |
---------------------------------------------------------------------------------------------

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

   4 - access("A"."ID"="B"."ID")

統計
----------------------------------------------------------
         25  recursive calls
          0  db block gets
     119340  consistent gets
          0  physical reads
          0  redo size
    2812231  bytes sent via SQL*Net to client
      73378  bytes received via SQL*Net from client
       6668  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
     100000  rows processed

SCOTT@orclpdb1> set autot off

では、 all_rows にして再実行します。他の設定は同じです。
はい、見事に、 Table full scan + Hash Join の実行計画が選択されました！！！！

違いは、first_rows_1 であるか、 all_rows であるかだけです。それだけなんです。

SCOTT@orclpdb1> -- 一時表（Global Temporary Table）のセッション固有統計なし
SCOTT@orclpdb1> alter session set optimizer_adaptive_plans = false;

セッションが変更されました。

SCOTT@orclpdb1> alter session set optimizer_dynamic_sampling = 0;

セッションが変更されました。

SCOTT@orclpdb1> alter session set optimizer_mode = all_rows;

セッションが変更されました。

SCOTT@orclpdb1> set autot trace exp stat
SCOTT@orclpdb1> select * from hoge_tmp a inner join hoge_tmp2 b on a.id = b.id;

100000行が選択されました。

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

--------------------------------------------------------------------------------
| Id  | Operation          | Name      | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------------
|   0 | SELECT STATEMENT   |           |  8168 |  1036K|   150   (3)| 00:00:01 |
|*  1 |  HASH JOIN         |           |  8168 |  1036K|   150   (3)| 00:00:01 |
|   2 |   TABLE ACCESS FULL| HOGE_TMP  |  8168 |   518K|    74   (2)| 00:00:01 |
|   3 |   TABLE ACCESS FULL| HOGE_TMP2 |  8168 |   518K|    74   (2)| 00:00:01 |
--------------------------------------------------------------------------------

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

   1 - access("A"."ID"="B"."ID")

統計
----------------------------------------------------------
         22  recursive calls
          0  db block gets
       9334  consistent gets
          0  physical reads
          0  redo size
    2812231  bytes sent via SQL*Net to client
      73599  bytes received via SQL*Net from client
       6668  SQL*Net roundtrips to/from client
          3  sorts (memory)
          0  sorts (disk)
     100000  rows processed

SCOTT@orclpdb1> set autot off

さらに深掘りしてみましょう。
統計情報の有無が影響しないことを確認してみましょう。一時表なので永続表とは異なる統計情報の持ち方になっていることをお忘れなく。でも、大丈夫ですよ。持ってますからw

SCOTT@orclpdb1> -- 一時表（Global Temporary Table）のセッション固有統計取得
SCOTT@orclpdb1> exec dbms_stats.gather_table_stats(ownname=>'SCOTT',tabname=>'HOGE_TMP',cascade=>true,no_invalidate=>false);

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

SCOTT@orclpdb1> exec dbms_stats.gather_table_stats(ownname=>'SCOTT',tabname=>'HOGE_TMP2',cascade=>true,no_invalidate=>false);

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

SCOTT@orclpdb1> select table_name,num_rows from user_tables where table_name in ('HOGE_TMP','HOGE_TMP2');

TABLE_NAME                       NUM_ROWS
------------------------------ ----------
HOGE_TMP
HOGE_TMP2

SCOTT@orclpdb1> select table_name,index_name,num_rows from user_indexes where table_name in ('HOGE_TMP','HOGE_TMP2');

TABLE_NAME                     INDEX_NAME                       NUM_ROWS
------------------------------ ------------------------------ ----------
HOGE_TMP                       SYS_C0010733
HOGE_TMP2                      SYS_C0010735

SCOTT@orclpdb1> select table_name,num_rows,scope from user_tab_statistics where table_name in ('HOGE_TMP','HOGE_TMP2');

TABLE_NAME                       NUM_ROWS SCOPE
------------------------------ ---------- ---------------------
HOGE_TMP                                  SHARED
HOGE_TMP2                                 SHARED
HOGE_TMP2                          100000 SESSION
HOGE_TMP                           100000 SESSION

SCOTT@orclpdb1> select table_name,index_name,num_rows,scope from user_ind_statistics where table_name in ('HOGE_TMP','HOGE_TMP2');

TABLE_NAME                     INDEX_NAME                       NUM_ROWS SCOPE
------------------------------ ------------------------------ ---------- ---------------------
HOGE_TMP                       SYS_C0010733                              SHARED
HOGE_TMP2                      SYS_C0010735                              SHARED
HOGE_TMP                       SYS_C0010733                       100000 SESSION
HOGE_TMP2                      SYS_C0010735                       100000 SESSION

一時表のセッション固有統計により駆動表の見積もり行数が、100K 担っている点に注目。大量にデータがヒットすることが、見えていながら、 first_roww_1 という１行目のレスポンスタイムを最短にするため、Nested Loop Joinが行われているます！

統計情報なんて、関係ねぇっ、って感じなのが確認できたので、実は、ほっとしていたりw...

SCOTT@orclpdb1> -- dyamic sampling off
SCOTT@orclpdb1> -- first_rows_1
SCOTT@orclpdb1> -- 一時表（Global Temporary Table）のセッション固有統計あり
SCOTT@orclpdb1> alter session set optimizer_adaptive_plans = false;

セッションが変更されました。

SCOTT@orclpdb1> alter session set optimizer_dynamic_sampling = 0;

セッションが変更されました。

SCOTT@orclpdb1> alter session set optimizer_mode = first_rows_1;

セッションが変更されました。

SCOTT@orclpdb1> set autot trace exp stat
SCOTT@orclpdb1> select * from hoge_tmp a inner join hoge_tmp2 b on a.id = b.id;

100000行が選択されました。

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

---------------------------------------------------------------------------------------------
| Id  | Operation                    | Name         | Rows  | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT             |              |     2 |   424 |     5   (0)| 00:00:01 |
|   1 |  NESTED LOOPS                |              |     2 |   424 |     5   (0)| 00:00:01 |
|   2 |   TABLE ACCESS FULL          | HOGE_TMP     |   100K|    10M|     3   (0)| 00:00:01 |
|   3 |   TABLE ACCESS BY INDEX ROWID| HOGE_TMP2    |     1 |   106 |     1   (0)| 00:00:01 |
|*  4 |    INDEX UNIQUE SCAN         | SYS_C0010735 |     1 |       |     0   (0)| 00:00:01 |
---------------------------------------------------------------------------------------------

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

   4 - access("A"."ID"="B"."ID")

Note
-----
   - Global temporary table session private statistics used

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

SCOTT@orclpdb1> set autot off

確認するまでもないですが、 all_rows で他の条件は同一のケースも見てみましょう。
こちらは安定の、table full scan + hash joinのままですね。（予想通りですw）

SCOTT@orclpdb1> -- dyamic sampling off
SCOTT@orclpdb1> -- all_rows
SCOTT@orclpdb1> -- 一時表（Global Temporary Table）のセッション固有統計あり
SCOTT@orclpdb1> alter session set optimizer_adaptive_plans = false;

セッションが変更されました。

SCOTT@orclpdb1> alter session set optimizer_dynamic_sampling = 0;

セッションが変更されました。

SCOTT@orclpdb1> alter session set optimizer_mode = all_rows;

セッションが変更されました。

SCOTT@orclpdb1> set autot trace exp stat
SCOTT@orclpdb1> select * from hoge_tmp a inner join hoge_tmp2 b on a.id = b.id;

100000行が選択されました。

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

----------------------------------------------------------------------------------------
| Id  | Operation          | Name      | Rows  | Bytes |TempSpc| Cost (%CPU)| Time     |
----------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT   |           |   100K|    20M|       |  6154   (2)| 00:00:01 |
|*  1 |  HASH JOIN         |           |   100K|    20M|    11M|  6154   (2)| 00:00:01 |
|   2 |   TABLE ACCESS FULL| HOGE_TMP  |   100K|    10M|       |  1110   (2)| 00:00:01 |
|   3 |   TABLE ACCESS FULL| HOGE_TMP2 |   100K|    10M|       |  1110   (2)| 00:00:01 |
----------------------------------------------------------------------------------------

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

   1 - access("A"."ID"="B"."ID")

Note
-----
   - Global temporary table session private statistics used

統計
----------------------------------------------------------
        705  recursive calls
         14  db block gets
      10430  consistent gets
          0  physical reads
          0  redo size
    2812231  bytes sent via SQL*Net to client
      73378  bytes received via SQL*Net from client
       6668  SQL*Net roundtrips to/from client
        170  sorts (memory)
          0  sorts (disk)
     100000  rows processed

SCOTT@orclpdb1> set autot off

一時表でもう一つ確認しておきましょう。
一時表（Global Temporary Table）のセッション固有統計なしで、動的統計有効にした場合、 first_rows_1 / all_rows の実行計画はどうなるでしょうか。

一旦、セッションを終了して、一時表を空にします。

SCOTT@orclpdb1> exit
Oracle Database 21c Enterprise Edition Release 21.0.0.0.0 - Production
Version 21.3.0.0.0との接続が切断されました。
[oracle@localhost ~]$ sqlplus scott@orclpdb1

...略...

SCOTT@orclpdb1> begin for i in 1..100000 loop insert into hoge_tmp values(i,lpad('x',100,'x')); if mod(i,1000) = 0 then commit; end if; end loop; end;
  2  /

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

SCOTT@orclpdb1> begin for i in 1..100000 loop insert into hoge_tmp2 values(i,lpad('x',100,'x')); if mod(i,1000) = 0 then commit; end if; end loop; end;
  2  /

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

SCOTT@orclpdb1> select table_name,num_rows from user_tables where table_name in ('HOGE_TMP','HOGE_TMP2');

TABLE_NAME                       NUM_ROWS
------------------------------ ----------
HOGE_TMP
HOGE_TMP2

SCOTT@orclpdb1> select table_name,index_name,num_rows from user_indexes where table_name in ('HOGE_TMP','HOGE_TMP2');

TABLE_NAME                     INDEX_NAME                       NUM_ROWS
------------------------------ ------------------------------ ----------
HOGE_TMP                       SYS_C0010733
HOGE_TMP2                      SYS_C0010735

SCOTT@orclpdb1> select table_name,num_rows,scope from user_tab_statistics where table_name in ('HOGE_TMP','HOGE_TMP2');

TABLE_NAME                       NUM_ROWS SCOPE
------------------------------ ---------- ---------------------
HOGE_TMP                                  SHARED
HOGE_TMP2                                 SHARED

SCOTT@orclpdb1> select table_name,index_name,num_rows,scope from user_ind_statistics where table_name in ('HOGE_TMP','HOGE_TMP2');

TABLE_NAME                     INDEX_NAME                       NUM_ROWS SCOPE
------------------------------ ------------------------------ ---------- ---------------------
HOGE_TMP                       SYS_C0010733                              SHARED
HOGE_TMP2                      SYS_C0010735                              SHARED

お〜〜〜〜。変化しました〜、動的統計取得で挙動が変わりますね。。。。とはいえ、 Merg Joinです！
実行計画、最悪ですよね。
重いソート処理を回避するために、主キーをindex full scan（主キー順に読み込む）した後に、 Table Access by index rowid ですよ。みなさん！
次に、table access fullの後に、SORT JOIN してます。。consistent getsもこれまでで最も多いですね。どうせなら table full scan + hash join を選んで欲しかったw
とはいえ、optimizer_mode = first_rows_1にするぐらいだから、動的統計って無効化していることも多いので、有効にするまでは気が回らなそうな気もしますね。
いずれにしてもあまり良い設定の相性ではないのは街がないですね。このケースでは。動的統計のレベルによっても変化してより良い実行計画に変化するとは思いますが。（今回の目的ではないのでその確認まではしません）

SCOTT@orclpdb1> -- first_rows_1
SCOTT@orclpdb1> -- 一時表（Global Temporary Table）のセッション固有統計なし
SCOTT@orclpdb1> alter session set optimizer_adaptive_plans = false;

セッションが変更されました。

SCOTT@orclpdb1> alter session set optimizer_mode = first_rows_1;

セッションが変更されました。

SCOTT@orclpdb1> alter session set optimizer_dynamic_sampling = 2;

セッションが変更されました。

SCOTT@orclpdb1> set autot trace exp stat
SCOTT@orclpdb1> select * from hoge_tmp a inner join hoge_tmp2 b on a.id = b.id;

100000行が選択されました。

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

---------------------------------------------------------------------------------------------
| Id  | Operation                    | Name         | Rows  | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT             |              |     1 |   130 |   569   (2)| 00:00:01 |
|   1 |  MERGE JOIN                  |              |     1 |   130 |   569   (2)| 00:00:01 |
|   2 |   TABLE ACCESS BY INDEX ROWID| HOGE_TMP2    | 97069 |  6161K|     3   (0)| 00:00:01 |
|   3 |    INDEX FULL SCAN           | SYS_C0010735 |     2 |       |     2   (0)| 00:00:01 |
|*  4 |   SORT JOIN                  |              | 95480 |  6060K|   566   (2)| 00:00:01 |
|   5 |    TABLE ACCESS FULL         | HOGE_TMP     | 95480 |  6060K|   566   (2)| 00:00:01 |
---------------------------------------------------------------------------------------------

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

   4 - access("A"."ID"="B"."ID")
       filter("A"."ID"="B"."ID")

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

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

SCOTT@orclpdb1> set autot off

同じ条件で、 all_rows に変えてみましょう。おそらくいい感じになるのではないでしょうか（これまで同様に）

SCOTT@orclpdb1> -- all_rows
SCOTT@orclpdb1> -- 一時表（Global Temporary Table）のセッション固有統計なし
SCOTT@orclpdb1> alter session set optimizer_adaptive_plans = false;

セッションが変更されました。

SCOTT@orclpdb1> alter session set optimizer_mode = all_rows;

セッションが変更されました。

SCOTT@orclpdb1> alter session set optimizer_dynamic_sampling = 2;

セッションが変更されました。

SCOTT@orclpdb1> set autot trace exp stat
SCOTT@orclpdb1> select * from hoge_tmp a inner join hoge_tmp2 b on a.id = b.id;

100000行が選択されました。

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

----------------------------------------------------------------------------------------
| Id  | Operation          | Name      | Rows  | Bytes |TempSpc| Cost (%CPU)| Time     |
----------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT   |           | 95481 |    11M|       |  4699   (2)| 00:00:01 |
|*  1 |  HASH JOIN         |           | 95481 |    11M|  7184K|  4699   (2)| 00:00:01 |
|   2 |   TABLE ACCESS FULL| HOGE_TMP  | 95480 |  6060K|       |  1109   (2)| 00:00:01 |
|   3 |   TABLE ACCESS FULL| HOGE_TMP2 | 97069 |  6161K|       |  1110   (2)| 00:00:01 |
----------------------------------------------------------------------------------------

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

   1 - access("A"."ID"="B"."ID")

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

統計
----------------------------------------------------------
         13  recursive calls
          0  db block gets
       9426  consistent gets
          0  physical reads
          0  redo size
    2812231  bytes sent via SQL*Net to client
      73599  bytes received via SQL*Net from client
       6668  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
     100000  rows processed

SCOTT@orclpdb1> set autot off
SCOTT@orclpdb1> exit

最後に、永続表での実行計画も確認しておきます。

SCOTT@orclpdb1> drop table hoge_tmp purge;

表が削除されました。

SCOTT@orclpdb1> drop table hoge_tmp2 purge;

表が削除されました。

SCOTT@orclpdb1> create table hoge_tmp (id number not null primary key, memo varchar2(100));

表が作成されました。

SCOTT@orclpdb1> create table hoge_tmp2 (id number not null primary key, memo varchar2(100));
  2  /

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

SCOTT@orclpdb1> begin for i in 1..100000 loop insert into hoge_tmp2 values(i,lpad('x',100,'x')); if mod(i,1000) = 0 then commit; end if; end loop; end;
  2  /

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

SCOTT@orclpdb1> select table_name,num_rows from user_tables where table_name in ('HOGE_TMP','HOGE_TMP2');

TABLE_NAME                       NUM_ROWS
------------------------------ ----------
HOGE_TMP
HOGE_TMP2

SCOTT@orclpdb1> select table_name,index_name,num_rows from user_indexes where table_name in ('HOGE_TMP','HOGE_TMP2');

TABLE_NAME                     INDEX_NAME                       NUM_ROWS
------------------------------ ------------------------------ ----------
HOGE_TMP                       SYS_C0010737
HOGE_TMP2                      SYS_C0010739

SCOTT@orclpdb1> select table_name,num_rows,scope from user_tab_statistics where table_name in ('HOGE_TMP','HOGE_TMP2');

TABLE_NAME                       NUM_ROWS SCOPE
------------------------------ ---------- ---------------------
HOGE_TMP                                  SHARED
HOGE_TMP2                                 SHARED

SCOTT@orclpdb1> select table_name,index_name,num_rows,scope from user_ind_statistics where table_name in ('HOGE_TMP','HOGE_TMP2');

TABLE_NAME                     INDEX_NAME                       NUM_ROWS SCOPE
------------------------------ ------------------------------ ---------- ---------------------
HOGE_TMP                       SYS_C0010737                              SHARED
HOGE_TMP2                      SYS_C0010739                              SHARED

永続表のケースで、統計なし、動的統計オフで、first_rows_1の場合は、一時表と同様に駆動表を全表走査した上で、Nested Loop Joinしています。first_rows_1の影響をそのまま受けています。

SCOTT@orclpdb1> -- first_rows_1
SCOTT@orclpdb1> -- 統計なし
SCOTT@orclpdb1> alter session set optimizer_adaptive_plans = false;

セッションが変更されました。

SCOTT@orclpdb1> alter session set optimizer_dynamic_sampling = 0;

セッションが変更されました。

SCOTT@orclpdb1> alter session set optimizer_mode = first_rows_1;

セッションが変更されました。

SCOTT@orclpdb1> set autot trace exp stat
SCOTT@orclpdb1> select * from hoge_tmp a inner join hoge_tmp2 b on a.id = b.id;

100000行が選択されました。

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

---------------------------------------------------------------------------------------------
| Id  | Operation                    | Name         | Rows  | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT             |              |     1 |   130 |     4   (0)| 00:00:01 |
|   1 |  NESTED LOOPS                |              |     1 |   130 |     4   (0)| 00:00:01 |
|   2 |   NESTED LOOPS               |              |     1 |   130 |     4   (0)| 00:00:01 |
|   3 |    TABLE ACCESS FULL         | HOGE_TMP     |    82 |  5330 |     3   (0)| 00:00:01 |
|*  4 |    INDEX UNIQUE SCAN         | SYS_C0010739 |     1 |       |     0   (0)| 00:00:01 |
|   5 |   TABLE ACCESS BY INDEX ROWID| HOGE_TMP2    |     1 |    65 |     1   (0)| 00:00:01 |
---------------------------------------------------------------------------------------------

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

   4 - access("A"."ID"="B"."ID")

統計
----------------------------------------------------------
         84  recursive calls
         23  db block gets
     126963  consistent gets
        231  physical reads
       4336  redo size
    2812231  bytes sent via SQL*Net to client
      73378  bytes received via SQL*Net from client
       6668  SQL*Net roundtrips to/from client
         13  sorts (memory)
          0  sorts (disk)
     100000  rows processed

SCOTT@orclpdb1> set autot off

他の条件は同じで、 all_rows に変更した場合同様に、全表走査＋ハッシュ結合（いいですねぇ。バッチ処理ならこれが一番良いですね。

SCOTT@orclpdb1> -- all_rows
SCOTT@orclpdb1> -- 統計なし
SCOTT@orclpdb1> alter session set optimizer_adaptive_plans = false;

セッションが変更されました。

SCOTT@orclpdb1> alter session set optimizer_dynamic_sampling = 0;

セッションが変更されました。

SCOTT@orclpdb1> alter session set optimizer_mode = all_rows;

セッションが変更されました。

SCOTT@orclpdb1> set autot trace exp stat
SCOTT@orclpdb1> select * from hoge_tmp a inner join hoge_tmp2 b on a.id = b.id;

100000行が選択されました。

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

--------------------------------------------------------------------------------
| Id  | Operation          | Name      | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------------
|   0 | SELECT STATEMENT   |           |    82 | 10660 |     6   (0)| 00:00:01 |
|*  1 |  HASH JOIN         |           |    82 | 10660 |     6   (0)| 00:00:01 |
|   2 |   TABLE ACCESS FULL| HOGE_TMP  |    82 |  5330 |     3   (0)| 00:00:01 |
|   3 |   TABLE ACCESS FULL| HOGE_TMP2 |    82 |  5330 |     3   (0)| 00:00:01 |
--------------------------------------------------------------------------------

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

   1 - access("A"."ID"="B"."ID")

統計
----------------------------------------------------------
        189  recursive calls
          5  db block gets
       9700  consistent gets
          1  physical reads
        184  redo size
    2812231  bytes sent via SQL*Net to client
      73599  bytes received via SQL*Net from client
       6668  SQL*Net roundtrips to/from client
         28  sorts (memory)
          0  sorts (disk)
     100000  rows processed

SCOTT@orclpdb1> set autot off

永続表、統計情報なし、動的統計取得有効、first_rows_1。一時表同様の結果です。永続表と一時表による違いは無さそうですね。これはNLJより避けたいw

SCOTT@orclpdb1> -- first_rows_1
SCOTT@orclpdb1> -- 統計なし
SCOTT@orclpdb1> -- 動的統計有効
SCOTT@orclpdb1> alter session set optimizer_adaptive_plans = false;

セッションが変更されました。

SCOTT@orclpdb1> alter session set optimizer_dynamic_sampling = 2;

セッションが変更されました。

SCOTT@orclpdb1> alter session set optimizer_mode = first_rows_1;

セッションが変更されました。

SCOTT@orclpdb1> set autot trace exp stat
SCOTT@orclpdb1> select * from hoge_tmp a inner join hoge_tmp2 b on a.id = b.id;

100000行が選択されました。

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

---------------------------------------------------------------------------------------------
| Id  | Operation                    | Name         | Rows  | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT             |              |     1 |   130 |   795   (2)| 00:00:01 |
|   1 |  MERGE JOIN                  |              |     1 |   130 |   795   (2)| 00:00:01 |
|   2 |   TABLE ACCESS BY INDEX ROWID| HOGE_TMP     |   124K|  7911K|     3   (0)| 00:00:01 |
|   3 |    INDEX FULL SCAN           | SYS_C0010737 |     2 |       |     2   (0)| 00:00:01 |
|*  4 |   SORT JOIN                  |              | 92574 |  5876K|   792   (2)| 00:00:01 |
|   5 |    TABLE ACCESS FULL         | HOGE_TMP2    | 92574 |  5876K|   792   (2)| 00:00:01 |
---------------------------------------------------------------------------------------------

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

   4 - access("A"."ID"="B"."ID")
       filter("A"."ID"="B"."ID")

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

統計
----------------------------------------------------------
        181  recursive calls
         26  db block gets
      16729  consistent gets
        182  physical reads
        140  redo size
    2812231  bytes sent via SQL*Net to client
      73599  bytes received via SQL*Net from client
       6668  SQL*Net roundtrips to/from client
         24  sorts (memory)
          0  sorts (disk)
     100000  rows processed

SCOTT@orclpdb1> set autot off

永続表、統計情報なし、動的統計取得有効、all_rowsも、一時表のケースと同様。安定して、全表走査＋ハッシュ結合が行われています。 all_rows にするべきSQLですからね。

SCOTT@orclpdb1> -- all_rows
SCOTT@orclpdb1> -- 統計なし
SCOTT@orclpdb1> -- 動的統計有効
SCOTT@orclpdb1> alter session set optimizer_adaptive_plans = false;

セッションが変更されました。

SCOTT@orclpdb1> alter session set optimizer_dynamic_sampling = 2;

セッションが変更されました。

SCOTT@orclpdb1> alter session set optimizer_mode = all_rows;

セッションが変更されました。

SCOTT@orclpdb1> set autot trace exp stat
SCOTT@orclpdb1> select * from hoge_tmp a inner join hoge_tmp2 b on a.id = b.id;

100000行が選択されました。

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

----------------------------------------------------------------------------------------
| Id  | Operation          | Name      | Rows  | Bytes |TempSpc| Cost (%CPU)| Time     |
----------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT   |           | 92574 |    11M|       |  5148   (2)| 00:00:01 |
|*  1 |  HASH JOIN         |           | 92574 |    11M|  6968K|  5148   (2)| 00:00:01 |
|   2 |   TABLE ACCESS FULL| HOGE_TMP2 | 92574 |  5876K|       |  1173   (2)| 00:00:01 |
|   3 |   TABLE ACCESS FULL| HOGE_TMP  |   124K|  7911K|       |  1177   (2)| 00:00:01 |
----------------------------------------------------------------------------------------

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

   1 - access("A"."ID"="B"."ID")

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

統計
----------------------------------------------------------
         32  recursive calls
          0  db block gets
       9438  consistent gets
          0  physical reads
          0  redo size
    2812231  bytes sent via SQL*Net to client
      73378  bytes received via SQL*Net from client
       6668  SQL*Net roundtrips to/from client
          3  sorts (memory)
          0  sorts (disk)
     100000  rows processed

SCOTT@orclpdb1> set autot off

いよいよ最後、動的統計取得を無効化して、静的統計による挙動を確認します。

SCOTT@orclpdb1> -- 統計取得
SCOTT@orclpdb1> exec dbms_stats.gather_table_stats(ownname=>'SCOTT',tabname=>'HOGE_TMP',cascade=>true,no_invalidate=>false);

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

SCOTT@orclpdb1> exec dbms_stats.gather_table_stats(ownname=>'SCOTT',tabname=>'HOGE_TMP2',cascade=>true,no_invalidate=>false);

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

SCOTT@orclpdb1> select table_name,num_rows from user_tables where table_name in ('HOGE_TMP','HOGE_TMP2');

TABLE_NAME                       NUM_ROWS
------------------------------ ----------
HOGE_TMP                           100000
HOGE_TMP2                          100000

SCOTT@orclpdb1> select table_name,index_name,num_rows from user_indexes where table_name in ('HOGE_TMP','HOGE_TMP2');

TABLE_NAME                     INDEX_NAME                       NUM_ROWS
------------------------------ ------------------------------ ----------
HOGE_TMP                       SYS_C0010737                       100000
HOGE_TMP2                      SYS_C0010739                       100000

SCOTT@orclpdb1> select table_name,num_rows,scope from user_tab_statistics where table_name in ('HOGE_TMP','HOGE_TMP2');

TABLE_NAME                       NUM_ROWS SCOPE
------------------------------ ---------- ---------------------
HOGE_TMP                           100000 SHARED
HOGE_TMP2                          100000 SHARED

SCOTT@orclpdb1> select table_name,index_name,num_rows,scope from user_ind_statistics where table_name in ('HOGE_TMP','HOGE_TMP2');

TABLE_NAME                     INDEX_NAME                       NUM_ROWS SCOPE
------------------------------ ------------------------------ ---------- ---------------------
HOGE_TMP                       SYS_C0010737                       100000 SHARED
HOGE_TMP2                      SYS_C0010739                       100000 SHARED

統計情報あり、動的統計有効ですが、動作しないはずですね。統計情報は最新ですし。 first_rows_1では期待した結果（良いという意味ではないw）が得られています。
駆動表を全表走査してNested Loop Joinが行われています。動的統計取得の副作用で、Merge Joinになることもなかったようですね。

SCOTT@orclpdb1> -- 統計あり
SCOTT@orclpdb1> -- 動的統計有効
SCOTT@orclpdb1> alter session set optimizer_adaptive_plans = false;

セッションが変更されました。

SCOTT@orclpdb1> alter session set optimizer_dynamic_sampling = 2;

セッションが変更されました。

SCOTT@orclpdb1> alter session set optimizer_mode = first_rows_1;

セッションが変更されました。

SCOTT@orclpdb1> set autot trace exp stat
SCOTT@orclpdb1> select * from hoge_tmp a inner join hoge_tmp2 b on a.id = b.id;

100000行が選択されました。

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

---------------------------------------------------------------------------------------------
| Id  | Operation                    | Name         | Rows  | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT             |              |     2 |   424 |     5   (0)| 00:00:01 |
|   1 |  NESTED LOOPS                |              |     2 |   424 |     5   (0)| 00:00:01 |
|   2 |   NESTED LOOPS               |              |     2 |   424 |     5   (0)| 00:00:01 |
|   3 |    TABLE ACCESS FULL         | HOGE_TMP     |   100K|    10M|     3   (0)| 00:00:01 |
|*  4 |    INDEX UNIQUE SCAN         | SYS_C0010739 |     1 |       |     0   (0)| 00:00:01 |
|   5 |   TABLE ACCESS BY INDEX ROWID| HOGE_TMP2    |     1 |   106 |     1   (0)| 00:00:01 |
---------------------------------------------------------------------------------------------

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

   4 - access("A"."ID"="B"."ID")

統計
----------------------------------------------------------
          5  recursive calls
          0  db block gets
     126786  consistent gets
          0  physical reads
          0  redo size
    2812231  bytes sent via SQL*Net to client
      73599  bytes received via SQL*Net from client
       6668  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
     100000  rows processed

SCOTT@orclpdb1> set autot off

同一条件で、 all_rows の場合です。こちらも想定通り、全表走査＋ハッシュ結合になっています。

最後に、 optimizer_mode をチューニングのゴールに合わせて、バッチ、分析系、そして、OLTPと、
all_rows または、first_rows_n　のいずれか正しく設定することも想定外の実行計画を防ぐことに役立つか、お分かりいただけたのではないでしょうか？
効果の薄い機能ではなく、重要な役目をもつ、 optimizer_mode、お忘れなく。ヒントでも使えます。状況に合わせて使い分けることをお勧めします:)

おまけ 昔、OTHER_XML列からOUTLINEを取り出すなんてネタ書いてましたが、しっかりと、optimizer_modeに対応するヒントが含まれています。
OTHER_XMLの中身 / Mac De Oracle / 2015年12月 4日 (金) https://discus-hamburg.cocolog-nifty.com/mac_de_oracle/2015/12/other_xml-7f15.html

では、また。

良いお年をお迎えください。

Enjoy! SQL and Optimizer Features! ：）

今回利用したSQLなど

alter session set optimizer_adaptive_plans = false;
alter session set optimizer_dynamic_sampling = 0;
alter session set optimizer_mode = first_rows_1;


create global temporary table hoge_tmp (id number not null primary key, memo varchar2(100)) on commit preserve rows;
create global temporary table hoge_tmp2 (id number not null primary key, memo varchar2(100)) on commit preserve rows;


select table_name,num_rows from user_tables where table_name in ('HOGE_TMP','HOGE_TMP2');
select table_name,index_name,num_rows from user_indexes where table_name in ('HOGE_TMP','HOGE_TMP2');
select table_name,num_rows,scope from user_tab_statistics where table_name in ('HOGE_TMP','HOGE_TMP2');
select table_name,index_name,num_rows,scope from user_ind_statistics where table_name in ('HOGE_TMP','HOGE_TMP2');

begin for i in 1..100000 loop insert into hoge_tmp values(i,lpad('x',100,'x')); if mod(i,1000) = 0 then commit; end if; end loop; end;
/
begin for i in 1..100000 loop insert into hoge_tmp2 values(i,lpad('x',100,'x')); if mod(i,1000) = 0 then commit; end if; end loop; end;
/


select table_name,num_rows from user_tables where table_name in ('HOGE_TMP','HOGE_TMP2');
select table_name,index_name,num_rows from user_indexes where table_name in ('HOGE_TMP','HOGE_TMP2');
select table_name,num_rows,scope from user_tab_statistics where table_name in ('HOGE_TMP','HOGE_TMP2');
select table_name,index_name,num_rows,scope from user_ind_statistics where table_name in ('HOGE_TMP','HOGE_TMP2');

-- 一時表（Global Temporary Table）のセッション固有統計なし
alter session set optimizer_adaptive_plans = false;
alter session set optimizer_dynamic_sampling = 0;
alter session set optimizer_mode = first_rows_1;
set autot trace exp stat
select * from hoge_tmp a inner join hoge_tmp2 b on a.id = b.id;
set autot off

-- 一時表（Global Temporary Table）のセッション固有統計なし
alter session set optimizer_adaptive_plans = false;
alter session set optimizer_dynamic_sampling = 0;
alter session set optimizer_mode = all_rows;
set autot trace exp stat
select * from hoge_tmp a inner join hoge_tmp2 b on a.id = b.id;
set autot off


-- 一時表（Global Temporary Table）のセッション固有統計取得
exec dbms_stats.gather_table_stats(ownname=>'SCOTT',tabname=>'HOGE_TMP',cascade=>true,no_invalidate=>false);
exec dbms_stats.gather_table_stats(ownname=>'SCOTT',tabname=>'HOGE_TMP2',cascade=>true,no_invalidate=>false);

select table_name,num_rows from user_tables where table_name in ('HOGE_TMP','HOGE_TMP2');
select table_name,index_name,num_rows from user_indexes where table_name in ('HOGE_TMP','HOGE_TMP2');
select table_name,num_rows,scope from user_tab_statistics where table_name in ('HOGE_TMP','HOGE_TMP2');
select table_name,index_name,num_rows,scope from user_ind_statistics where table_name in ('HOGE_TMP','HOGE_TMP2');

-- dyamic sampling off
-- first_rows_1
-- 一時表（Global Temporary Table）のセッション固有統計あり
alter session set optimizer_adaptive_plans = false;
alter session set optimizer_dynamic_sampling = 0;
alter session set optimizer_mode = first_rows_1;
set autot trace exp stat
select * from hoge_tmp a inner join hoge_tmp2 b on a.id = b.id;
set autot off

-- dyamic sampling off
-- all_rows
-- 一時表（Global Temporary Table）のセッション固有統計あり
alter session set optimizer_adaptive_plans = false;
alter session set optimizer_dynamic_sampling = 0;
alter session set optimizer_mode = all_rows;
set autot trace exp stat
select * from hoge_tmp a inner join hoge_tmp2 b on a.id = b.id;
set autot off



+++　一時表（Global Temporary Table）のセッション固有統計なしで、動的統計有効　+++

alter session set optimizer_adaptive_plans = false;
alter session set optimizer_mode = first_rows_1;
alter session set optimizer_dynamic_sampling = 2;

select table_name,num_rows from user_tables where table_name in ('HOGE_TMP','HOGE_TMP2');
select table_name,index_name,num_rows from user_indexes where table_name in ('HOGE_TMP','HOGE_TMP2');
select table_name,num_rows,scope from user_tab_statistics where table_name in ('HOGE_TMP','HOGE_TMP2');
select table_name,index_name,num_rows,scope from user_ind_statistics where table_name in ('HOGE_TMP','HOGE_TMP2');


begin for i in 1..100000 loop insert into hoge_tmp values(i,lpad('x',100,'x')); if mod(i,1000) = 0 then commit; end if; end loop; end;
/
begin for i in 1..100000 loop insert into hoge_tmp2 values(i,lpad('x',100,'x')); if mod(i,1000) = 0 then commit; end if; end loop; end;
/


select table_name,num_rows from user_tables where table_name in ('HOGE_TMP','HOGE_TMP2');
select table_name,index_name,num_rows from user_indexes where table_name in ('HOGE_TMP','HOGE_TMP2');
select table_name,num_rows,scope from user_tab_statistics where table_name in ('HOGE_TMP','HOGE_TMP2');
select table_name,index_name,num_rows,scope from user_ind_statistics where table_name in ('HOGE_TMP','HOGE_TMP2');


-- first_rows_1
-- 一時表（Global Temporary Table）のセッション固有統計なし
alter session set optimizer_adaptive_plans = false;
alter session set optimizer_mode = first_rows_1;
alter session set optimizer_dynamic_sampling = 2;
set autot trace exp stat
select * from hoge_tmp a inner join hoge_tmp2 b on a.id = b.id;
set autot off


-- all_rows
-- 一時表（Global Temporary Table）のセッション固有統計なし
alter session set optimizer_adaptive_plans = false;
alter session set optimizer_mode = all_rows;
alter session set optimizer_dynamic_sampling = 2;
set autot trace exp stat
select * from hoge_tmp a inner join hoge_tmp2 b on a.id = b.id;
set autot off




--パーマネント表でも同じ

alter session set optimizer_adaptive_plans = false;
alter session set optimizer_dynamic_sampling = 0;
alter session set optimizer_mode = first_rows_1;


create table hoge_tmp (id number not null primary key, memo varchar2(100));
create table hoge_tmp2 (id number not null primary key, memo varchar2(100));


select table_name,num_rows from user_tables where table_name in ('HOGE_TMP','HOGE_TMP2');
select table_name,index_name,num_rows from user_indexes where table_name in ('HOGE_TMP','HOGE_TMP2');
select table_name,num_rows,scope from user_tab_statistics where table_name in ('HOGE_TMP','HOGE_TMP2');
select table_name,index_name,num_rows,scope from user_ind_statistics where table_name in ('HOGE_TMP','HOGE_TMP2');

begin for i in 1..100000 loop insert into hoge_tmp values(i,lpad('x',100,'x')); if mod(i,1000) = 0 then commit; end if; end loop; end;
/
begin for i in 1..100000 loop insert into hoge_tmp2 values(i,lpad('x',100,'x')); if mod(i,1000) = 0 then commit; end if; end loop; end;
/


select table_name,num_rows from user_tables where table_name in ('HOGE_TMP','HOGE_TMP2');
select table_name,index_name,num_rows from user_indexes where table_name in ('HOGE_TMP','HOGE_TMP2');
select table_name,num_rows,scope from user_tab_statistics where table_name in ('HOGE_TMP','HOGE_TMP2');
select table_name,index_name,num_rows,scope from user_ind_statistics where table_name in ('HOGE_TMP','HOGE_TMP2');


-- first_rows_1
-- 統計なし
alter session set optimizer_adaptive_plans = false;
alter session set optimizer_dynamic_sampling = 0;
alter session set optimizer_mode = first_rows_1;
set autot trace exp stat
select * from hoge_tmp a inner join hoge_tmp2 b on a.id = b.id;
set autot off

-- all_rows
-- 統計なし
alter session set optimizer_adaptive_plans = false;
alter session set optimizer_dynamic_sampling = 0;
alter session set optimizer_mode = all_rows;
set autot trace exp stat
select * from hoge_tmp a inner join hoge_tmp2 b on a.id = b.id;
set autot off


-- first_rows_1
-- 統計なし
-- 動的統計有効
alter session set optimizer_adaptive_plans = false;
alter session set optimizer_dynamic_sampling = 2;
alter session set optimizer_mode = first_rows_1;
set autot trace exp stat
select * from hoge_tmp a inner join hoge_tmp2 b on a.id = b.id;
set autot off


-- all_rows
-- 統計なし
-- 動的統計有効
alter session set optimizer_adaptive_plans = false;
alter session set optimizer_dynamic_sampling = 2;
alter session set optimizer_mode = all_rows;
set autot trace exp stat
select * from hoge_tmp a inner join hoge_tmp2 b on a.id = b.id;
set autot off


-- 統計取得
exec dbms_stats.gather_table_stats(ownname=>'SCOTT',tabname=>'HOGE_TMP',cascade=>true,no_invalidate=>false);
exec dbms_stats.gather_table_stats(ownname=>'SCOTT',tabname=>'HOGE_TMP2',cascade=>true,no_invalidate=>false);

select table_name,num_rows from user_tables where table_name in ('HOGE_TMP','HOGE_TMP2');
select table_name,index_name,num_rows from user_indexes where table_name in ('HOGE_TMP','HOGE_TMP2');
select table_name,num_rows,scope from user_tab_statistics where table_name in ('HOGE_TMP','HOGE_TMP2');
select table_name,index_name,num_rows,scope from user_ind_statistics where table_name in ('HOGE_TMP','HOGE_TMP2');

-- first_rows_1
-- 統計あり
-- 動的統計有効
alter session set optimizer_adaptive_plans = false;
alter session set optimizer_dynamic_sampling = 2;
alter session set optimizer_mode = first_rows_1;
set autot trace exp stat
select * from hoge_tmp a inner join hoge_tmp2 b on a.id = b.id;
set autot off


-- all_rows
-- 統計あり
-- 動的統計有効
alter session set optimizer_adaptive_plans = false;
alter session set optimizer_dynamic_sampling = 2;
alter session set optimizer_mode = all_rows;
set autot trace exp stat
select * from hoge_tmp a inner join hoge_tmp2 b on a.id = b.id;
set autot off

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

2024年12月21日 (土)

帰ってきた！標準はあるにはあるが癖の多いSQL #17 - 文字数取得関数も癖が強い

本エントリーは、
JPOUG Advent Calendar 2024
MySQL Advent Calendar 2024
PostgreSQL Advent Calendar 2024 の21目の記事です。

JPOUG Advent Calendar 2024の昨日のポストは、takashitel(おおの)さんの「RMANで表単位リカバリをする際の注意点（RMAN-06024）」、
MySQL Advent Calendar 2024の昨日のポストは、yoku0825さんの「Blackholeストレージエンジンとバイナリログと 2024」、
PostgreSQL Advent Calendar 2024の昨日のポストは、Noriyoshi Shinodaさんの「PostgreSQL と Oracle Database でシーケンスの動作を比較する」（シリーズ1）、および Shimooo_mutenkaさんの「【PostgreSQL】リストアの進捗状況を監視・表示するシェルスクリプト」（シリーズ2）
でした。

では、本題。

同じ名称の関数でも癖があるので移行するようなケースでは注意した方がいいよ！
という非互換はみなさんご存知の通りだと思います。

それでも検証漏れに気づいた時の雰囲気の悪さと言ったらなんとも言えませんよね。
その影響で、その他の非互換についても漏れているのでは？
と疑われてしまったり、玉突きでタスクが増えたり良いことはありません。

そんなことを一つでも減らしたいというネタです。:)

同じ結果を返す関数でも名称が違う程度ならまだ分かり易いですが、インプットする値による挙動の違いは把握するのが難しいですよね。
（マニュアルに書かれていたり書かれていなかったり、書かれていても気づきにくいところに書かれていたり、関数そのものの影響ではなかったり、様々な要因があります）

今日はそのような癖の一つで、文字数取得関数の癖。（すでに、前述した癖の一つに気づいちゃった方もいると思いますが、No Spoiler!でw）
今回のネタも有名なものの一つだと思いますが、あらためて、意識しておこう！
という意味も込めて取り上げてみました。（癖のあるシリーズでもまだ取り上げてなかったこともありますw）

長いのでw 最初に癖のまとめを。

文字数取得関数 ・Oracle Database

LENGTH()
NULLが渡された場合、 NULL が返される
空文字が渡された場合、 NULL が返される（Oracle Databaseが空文字をNULLとして扱うため）
CHAR(n)全てが空白の文字列の場合、空白分の文字数が返る。CHAR(10 CHAR)の場合は、10.
CHAR型の後続空白は文字数にカウントされる。e.g. CHAR(10 CHAR) <= 'ABC'の場合、右側を空白埋めして 10 が返される

参考）
Oracle Database / Release 19 / SQL言語リファレンス / LENGTH

今回の主役であるLENGTH()関数については以下のような記載があります。
Oracle Database / Release 19 / SQL Language Reference / Table C-1 Oracle Support of Core SQL Features

"E021-04, CHARACTER_LENGTH function: use LENGTH function instead" 上記、ドキュメントに記載されている通り、Oracle DatabaseのLENGTH()関数は方言なんですよね！！
早速、癖者感が強くなったところでw、次へ進みましょうwwww

・MySQL

CHAR_LENGTH() / CHARACTER_LENGTH()
NULLが渡された場合、 NULL が返される
空文字が渡された場合、0 が返される
全て空白の文字列の場合、 0 が返されさる（空白がトリムされるため）
CHAR型の後続空白は文字数にカウントされない。（空白がトリムされるため）ただし、 CHAR_LENGTH(CAST('12345 ' AS CHAR(10)))、 CHAR_LENGTH(CAST('12345 ' AS CHAR(30)))のようなケースでは空白を含むリテラルの文字数が返る。(Release 8.0.36)

参考）
MySQL 8.0 リファレンスマニュアル / データ型 / 文字列データ型 / CHAR および VARCHAR 型
https://dev.mysql.com/doc/refman/8.0/ja/char.html

"CHARACTER_LENGTH() は CHAR_LENGTH() のシノニム。E021-04対応とのこと。標準対応ということですね。Oracle Databaseはやってないですけど" なお、 LENGTH( str ) は、Oracle Databaseだと LENGTHB( char ) 相当ですね。バイト数を返してくるので。まじか！　この類の関数の癖の多さと強さは半端ないですね。有名な違いなので見落とされることはなさそうな気もしますが、注意が必要な部分です。
Oracle Database 以外で要注意なのはCHAR型の右側のスペースの扱いですね。該当関数云々というよりも。

"CHAR 値は格納されると、指定された長さになるように右側がスペースで埋められます。 PAD_CHAR_TO_FULL_LENGTH SQL モードが有効になっていないかぎり、CHAR 値が取り出されるときに、末尾のスペースが削除されます。"

MySQL 8.0 リファレンスマニュアル / 関数と演算子 / 文字列関数および演算子 / LENGTH(str) MySQL 8.0 リファレンスマニュアル / 関数と演算子 / 文字列関数および演算子 / CHAR_LENGTH(str) ”文字で測定された文字列 str の長さを返します。マルチバイト文字は、単一の文字としてカウントされます。つまり、5 つの 2 バイト文字を含む文字列では、LENGTH() は 10 を返し、CHAR_LENGTH() は 5 を返します。”

MySQL 8.0 リファレンスマニュアル / 関数と演算子 / 文字列関数および演算子 / CHARACTER_LENGTH(str)

・PostgreSQL

CHAR_LENGTH() / CHARACTER_LENGTH() / LENGTH()
NULLが渡された場合、 NULL が返される
空文字が渡された場合、0 が返される
全て空白の文字列の場合、 0 が返されさる（空白がトリムされるため）
CHAR型の後続空白は文字数にカウントされない（空白がトリムされるため）

参考）
PostgreSQL 16.4文書 / 第9章関数と演算子 / 9.4. 文字列関数と演算子
 PostgreSQL 16.4文書 / D.1. サポートされている機能 / D.1. サポートされている機能 / CHARACTER_LENGTH関数

”021-04 コア CHARACTER_LENGTH関数 - 数える前にCHARACTER値の最後の空白を除去します”

の冒頭でも以下のような注意点が記載されています。
”character型の値は関数あるいは演算子に適用される前にtextに変換され、character値の末尾の空白が削除されることになります。”

とさらりとまとめちゃいましたが、なかなかの癖者であることがお分かりいただけたかと思います。

移行する際にこの対応が漏れてしまうと、バグに直結する部分なのでしっかりと対処したいですよね。これ。

この程度書いただけでお腹いっぱい感はありますがw、簡単な確認ログも載せておきます。

Oracle Database Oracle Databaseに慣れてると、まあ、ふむふむって結果ではあります。

Oracle Database 21c Enterprise Edition Release 21.0.0.0.0 - Production
Version 21.3.0.0.0

1)
マニュアルに記載されているように、 NULL の場合は、NULLが返ります。

SCOTT@orclpdb1> set null [null]
SCOTT@orclpdb1> SELECT LENGTH(null) AS "NULL" FROM dual;

      NULL
----------
[null]

2)
Oracle Database は空文字は NULL として扱われる別の癖があるため、空文字の場合は、NULL と同じ結果が返ります。

SCOTT@orclpdb1> SELECT LENGTH('') AS "Empty String" FROM dual;

Empty String
------------
[null]

SCOTT@orclpdb1> SELECT LENGTH(' ') AS "SINGLE-BYTE SPACE" FROM dual;

SINGLE-BYTE SPACE
-----------------
                1

SCOTT@orclpdb1> SELECT LENGTH('　') AS "MULTI-BYTE SPACE" FROM dual;

MULTI-BYTE SPACE
----------------
               1

SCOTT@orclpdb1> SELECT LENGTH('12345') AS "SINGLE-BYTE CHARs" FROM dual;

SINGLE-BYTE CHARs
-----------------
                5

SCOTT@orclpdb1> SELECT LENGTH('あいうえお') AS "MULTI-BYTE CHARs" FROM dual;

MULTI-BYTE CHARs
----------------
               5

SCOTT@orclpdb1> SELECT LENGTH('12345     ') AS "SINGLE-BYTE CHARs + SPACEs" FROM dual;

SINGLE-BYTE CHARs + SPACEs
--------------------------
                        10

SCOTT@orclpdb1> SELECT LENGTH('あいうえお　　　　　') AS "MULTI-BYTE CHARs + MLUTI-BYTE SPACEs" FROM dual;

MULTI-BYTE CHARs + MLUTI-BYTE SPACEs
------------------------------------
                                  10

SCOTT@orclpdb1> SELECT LENGTH(CAST('12345' AS CHAR(10))) AS "SINGLE-BYTE CHARs + SPACEs" FROM dual;

SINGLE-BYTE CHARs + SPACEs
--------------------------
                        10

10)

SCOTT@orclpdb1> SELECT LENGTH(CAST('12345     ' AS CHAR(10))) AS "SINGLE-BYTE CHARs + SPACEs" FROM dual;

SINGLE-BYTE CHARs + SPACEs
--------------------------
                        10

11)

SCOTT@orclpdb1> SELECT LENGTH(CAST('12345' AS VARCHAR2(10))) AS "SINGLE-BYTE CHARs + SPACEs" FROM dual;

SINGLE-BYTE CHARs + SPACEs
--------------------------
                         5

12)

SCOTT@orclpdb1> SELECT LENGTH(CAST('12345     ' AS VARCHAR2(10))) AS "SINGLE-BYTE CHARs + SPACEs" FROM dual;

SINGLE-BYTE CHARs + SPACEs
--------------------------
                        10

MySQL CHARの時の挙動に注目です。CASTしたケースの挙動はなかなかキツめな気がします。

Oracle DatabaseのLENGTH()に相当するのは、CHAR_LENGTH()ですが、空文字の扱いはOracle Databaseが特殊なので要注意なのは言うまでもありません。

+-----------+
| VERSION() |
+-----------+
| 8.0.36    |
+-----------+

mysql> SELECT CHAR_LENGTH(null) AS "NULL";
+------+
| NULL |
+------+
| NULL |
+------+

2)
Oracle Databaseとは異なり。空文字は空文字としてカウントされています。こちらが標準の動き（Oracle Database側に癖があります）

mysql> SELECT CHAR_LENGTH('') AS "Empty String";
+--------------+
| Empty String |
+--------------+
|            0 |
+--------------+

mysql> SELECT CHAR_LENGTH(' ') AS "SINGLE-BYTE SPACE";
+-------------------+
| SINGLE-BYTE SPACE |
+-------------------+
|                 1 |
+-------------------+

mysql> SELECT CHAR_LENGTH('　') AS "MULTI-BYTE SPACE";
+------------------+
| MULTI-BYTE SPACE |
+------------------+
|                1 |
+------------------+

mysql> SELECT CHAR_LENGTH('12345') AS "SINGLE-BYTE CHARs";
+-------------------+
| SINGLE-BYTE CHARs |
+-------------------+
|                 5 |
+-------------------+

mysql> SELECT CHAR_LENGTH('あいうえお') AS "MULTI-BYTE CHARs";
+------------------+
| MULTI-BYTE CHARs |
+------------------+
|                5 |
+------------------+

mysql> SELECT CHAR_LENGTH('12345     ') AS "SINGLE-BYTE CHARs + SPACEs";
+----------------------------+
| SINGLE-BYTE CHARs + SPACEs |
+----------------------------+
|                         10 |
+----------------------------+

mysql> SELECT CHAR_LENGTH('あいうえお　　　　　') AS "MULTI-BYTE CHARs + MLUTI-BYTE SPACEs";
+--------------------------------------+
| MULTI-BYTE CHARs + MLUTI-BYTE SPACEs |
+--------------------------------------+
|                                   10 |
+--------------------------------------+

9)
これはマニュアルに記載されている通りの結果ですね。Oracle Databaseとは異なり, CHAR(10)へキャストされた際に付加される空白は含まれていません。なお、MySQL 8.0 リファレンスマニュアル / MySQL サーバーの管理 / MySQL Server / サーバー SQL モード / 5.1.11 サーバー SQL モードには、PAD_CHAR_TO_FULL_LENGTH の記述がありますが、最新版ではdeprecatedになっています。

mysql> SELECT CHAR_LENGTH(CAST('12345' AS CHAR(10))) AS "SINGLE-BYTE CHARs";
+-------------------+
| SINGLE-BYTE CHARs |
+-------------------+
|                 5 |
+-------------------+

9-1)
前述の特性から言うと、ちょっと怪しい挙動ですよね。なんだろこの動き。(8.0.36)

mysql> SELECT CHAR_LENGTH(CAST('12345     ' AS CHAR(10))) AS "SINGLE-BYTE CHARs + SPACEs";
+----------------------------+
| SINGLE-BYTE CHARs + SPACEs |
+----------------------------+
|                         10 |
+----------------------------+

9-2)
面白い挙動ですね。もう一つついでに確認しておきましょう。リテラルで指定した文字列が、CASTしたCHAR(n)のn以下の場合、CHAR(n)のnが返る訳ではなく、リテラルの文字数（後続の空白を含む）そのものが返されます。なんとなく、怪しい挙動ですね。やはり。

mysql>  SELECT CHAR_LENGTH(CAST('12345     ' AS CHAR(30))) AS "SINGLE-BYTE CHARs + SPACEs";
+----------------------------+
| SINGLE-BYTE CHARs + SPACEs |
+----------------------------+
|                         10 |
+----------------------------+

9-3)
CHAR(7)よりは長い文字列を渡しているので、超過した文字は切られて 7文字となっています。これは予想通り。

mysql>  SELECT CHAR_LENGTH(CAST('12345      ' AS CHAR(7))) AS "SINGLE-BYTE CHARs + SPACEs";
+----------------------------+
| SINGLE-BYTE CHARs + SPACEs |
+----------------------------+
|                          7 |
+----------------------------+

MySQLのCAST()ではVARCHAR/TEXTへのキャストはできないようなので、CHAR(n)へのキャストのみ確認してみました。CHARだけ見れれば良いので十分ではありますが。CHARの時の文字列に続く空白の扱いの癖の影響なので。

PostgreSQL Oracle DatabaseのLENGTH()に相当するのは、CHAR_LENGTH()ですが、空文字の扱いはOracle Databasegが特殊なので要注意なのは言うまでもありません）
また、LENGTH()も同様に文字数を返してくるのがわかります。。。。PostgreSQLの場合、関数名も同じにできるし、NULL関連の癖に注意すれば良さそうに見えるわけですが。。。。。油断しちゃいけませんよねw

                                                 version                                                 
---------------------------------------------------------------------------------------------------------
 PostgreSQL 16.3 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 8.5.0 20210514 (Red Hat 8.5.0-22), 64-bit

perftestdb=> \pset null [null]
Null表示は"[null]"です。

perftestdb=> SELECT LENGTH(null) AS "NULL";
  NULL  
--------
 [null]

2)
空文字の挙動はMySQLと同じですよね。

perftestdb=> SELECT LENGTH('') AS "Empty String";
 Empty String 
--------------
            0

perftestdb=> SELECT LENGTH(' ') AS "SINGLE-BYTE SPACE";
 SINGLE-BYTE SPACE 
-------------------
                 1

perftestdb=> SELECT LENGTH('　') AS "MULTI-BYTE SPACE";
 MULTI-BYTE SPACE 
------------------
                1

perftestdb=> SELECT LENGTH('12345') AS "SINGLE-BYTE CHARs";
 SINGLE-BYTE CHARs 
-------------------
                 5

perftestdb=> SELECT LENGTH('あいうえお') AS "MULTI-BYTE CHARs";
 MULTI-BYTE CHARs 
------------------
                5

perftestdb=> SELECT LENGTH('12345     ') AS "SINGLE-BYTE CHARs + SPACEs";
 SINGLE-BYTE CHARs + SPACEs 
----------------------------
                         10

perftestdb=> SELECT LENGTH('あいうえお　　　　　') AS "MULTI-BYTE CHARs + MLUTI-BYTE SPACEs";
 MULTI-BYTE CHARs + MLUTI-BYTE SPACEs 
--------------------------------------
                                   10

9)
MySQLとPostgreSQLは同じ挙動ですね。

perftestdb=> SELECT LENGTH(CAST('12345' AS CHAR(10))) AS "SINGLE-BYTE CHARs";
 SINGLE-BYTE CHARs 
-------------------
                 5

10)
空白が埋めされたわけではなく、文字列として空白を渡した場合も、トリムされて、5文字となります。（MySQLもこの動きを予想していたのになんだろあの動き）

perftestdb=> SELECT LENGTH(CAST('12345     ' AS CHAR(10))) AS "SINGLE-BYTE CHARs + SPACEs";
 SINGLE-BYTE CHARs + SPACEs 
----------------------------
                          5

11)

perftestdb=> SELECT LENGTH(CAST('12345' AS VARCHAR(10))) AS "SINGLE-BYTE CHARs";
 SINGLE-BYTE CHARs 
-------------------
                 5

12)

perftestdb=> SELECT LENGTH(CAST('12345     ' AS VARCHAR(10))) AS "SINGLE-BYTE CHARs + SPACEs";
 SINGLE-BYTE CHARs + SPACEs 
----------------------------
                         10

13)

perftestdb=> SELECT LENGTH(CAST('12345' AS TEXT)) AS "SINGLE-BYTE CHARs";
 SINGLE-BYTE CHARs 
-------------------
                 5

14)

perftestdb=> SELECT LENGTH(CAST('12345     ' AS TEXT)) AS "SINGLE-BYTE CHARs + SPACEs";
 SINGLE-BYTE CHARs + SPACEs 
----------------------------
                         10

CHAR_LENGTH()でも同様に確認しておきましょう。LENGTH()でいいじゃん感じですけどもw。

perftestdb=> SELECT CHAR_LENGTH(null) AS "NULL";
  NULL  
--------
 [null]

perftestdb=> SELECT CHAR_LENGTH('') AS "Empty String";
 Empty String 
--------------
            0

perftestdb=> SELECT CHAR_LENGTH(' ') AS "SINGLE-BYTE SPACE";
 SINGLE-BYTE SPACE 
-------------------
                 1

perftestdb=> SELECT CHAR_LENGTH('　') AS "MULTI-BYTE SPACE";
 MULTI BYTE SPACE 
------------------
                1

perftestdb=> SELECT CHAR_LENGTH('12345') AS "SINGLE-BYTE CHARs";
 SINGLE-BYTE CHARs 
-------------------
                 5

perftestdb=> SELECT CHAR_LENGTH('あいうえお') AS "MULTI-BYTE CHARs";
 MULTI-BYTE CHARs 
------------------
                5

perftestdb=> SELECT CHAR_LENGTH('12345     ') AS "SINGLE-BYTE CHARs + SPACEs";
 SINGLE-BYTE CHARs + SPACEs 
----------------------------
                         10

perftestdb=> SELECT CHAR_LENGTH('あいうえお　　　　　') AS "MULTI-BYTE CHARs + MLUTI-BYTE SPACEs";
 MULTI-BYTE CHARs + MLUTI-BYTE SPACEs 
--------------------------------------
                                   10

perftestdb=> SELECT CHAR_LENGTH(CAST('12345' AS CHAR(10))) AS "SINGLE-BYTE CHARs";
 SINGLE-BYTE CHARs 
-------------------
                 5

perftestdb=> SELECT CHAR_LENGTH(CAST('12345     ' AS CHAR(10))) AS "SINGLE-BYTE CHARs + SPACEs";
 SINGLE-BYTE CHARs + SPACEs 
----------------------------
                          "5

perftestdb=> SELECT CHAR_LENGTH(CAST('12345' AS VARCHAR(10))) AS "SINGLE-BYTE CHARs";
 SINGLE-BYTE CHARs 
-------------------
                 5

perftestdb=> SELECT CHAR_LENGTH(CAST('12345     ' AS VARCHAR(10))) AS "SINGLE-BYTE CHARs + SPACEs";
 SINGLE-BYTE CHARs + SPACEs 
----------------------------
                         10

perftestdb=> SELECT CHAR_LENGTH(CAST('12345' AS TEXT)) AS "SINGLE-BYTE CHARs";
 SINGLE-BYTE CHARs 
-------------------
                 5

perftestdb=> SELECT CHAR_LENGTH(CAST('12345     ' AS TEXT)) AS "SINGLE-BYTE CHARs + SPACEs";
 SINGLE-BYTE CHARs + SPACEs 
----------------------------
                         10

CHAR型の空白の扱いが癖の元なので、表の列がCHAR型の場合の動きも少し見ておきましょう。
まずは、データの準備、Oracle Database/MySQL/PostgreSQLそれぞれで、CHAR(10)の列を1列持つ表とデータを用意しました。

Oracle Database

SCOTT@orclpdb1> l
  1  CREATE TABLE str
  2  (
  3    memo VARCHAR2(40 CHAR)
  4    , c CHAR(10 CHAR)
  5* )
SCOTT@orclpdb1> /

表が作成されました。

SCOTT@orclpdb1> l
  1  INSERT ALL
  2    INTO str(memo, c) VALUES('NULL', null)
  3    INTO str(memo, c) VALUES('Empty string', '')
  4    INTO str(memo, c) VALUES('SINGLE-BYTE SPACE', ' ')
  5    INTO str(memo, c) VALUES('SINGLE-BYTE 2 SPACEs', '  ')
  6    INTO str(memo, c) VALUES('SINGLE-BYTE CHAR and SPACE', '1 ')
  7    INTO str(memo, c) VALUES('SINGLE-BYTE CHARs', '12345')
  8    INTO str(memo, c) VALUES('SINGLE-BYTE CHARs', '12345     ')
  9*   SELECT null FROM dual
SCOTT@orclpdb1> /

7行が作成されました。

SCOTT@orclpdb1> COMMIT;

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

MySQL

mysql> CREATE TABLE str
    -> (
    ->   memo VARCHAR(40)
    ->   , c CHAR(10)
    -> );
Query OK, 0 rows affected (0.29 sec)

mysql> INSERT 
    ->   INTO str(memo, c) 
    ->     VALUES('NULL', null)
    ->          ,('Empty string', '')
    ->          ,('SINGLE-BYTE SPACE', ' ')
    ->          ,('SINGLE-BYTE 2 SPACEs', '  ')
    ->          ,('SINGLE-BYTE CHAR and SPACE', '1 ')
    ->          ,('SINGLE-BYTE CHARs', '12345')
    ->          ,('SINGLE-BYTE CHARs', '12345     ')
    -> ;
Query OK, 7 rows affected (0.03 sec)
Records: 7  Duplicates: 0  Warnings: 0

mysql>

PostgreSQL

perftestdb=> CREATE TABLE str
perftestdb-> (
perftestdb(>   memo VARCHAR(40)
perftestdb(>   , c CHAR(10)
perftestdb(> );
CREATE TABLE

perftestdb->   INTO str(memo, c) 
perftestdb->     VALUES('NULL', null)
perftestdb->          ,('Empty string', '')
perftestdb->          ,('SINGLE-BYTE SPACE', ' ')
perftestdb->          ,('SINGLE-BYTE 2 SPACEs', '  ')
perftestdb->          ,('SINGLE-BYTE CHAR and SPACE', '1 ')
perftestdb->          ,('SINGLE-BYTE CHARs', '12345')
perftestdb->          ,('SINGLE-BYTE CHARs', '12345     ')
perftestdb-> ;
INSERT 0 7
perftestdb=>

リテラル値をキャストした場合とは少々異なる結果になりました。
MySQLとPostgreSQLは同一の挙動を示します。MySQLの場合、'12345 'をCHAR(10)へCASTした時の挙動の違い、やはり気になりますね。

Oracle Database

SCOTT@orclpdb1> SELECT memo, CASE WHEN c IS NULL THEN c ELSE '"'||c||'"' END AS "CHAR(10)", LENGTH(c) FROM str;

MEMO                                     CHAR(10)                              LENGTH(C)
---------------------------------------- ------------------------------------ ----------
NULL                                     [null]                               [null]
Empty string                             [null]                               [null]
SINGLE-BYTE SPACE                        "          "                                 10
SINGLE-BYTE 2 SPACEs                     "          "                                 10
SINGLE-BYTE CHAR and SPACE               "1         "                                 10
SINGLE-BYTE CHARs                        "12345     "                                 10
SINGLE-BYTE CHARs                        "12345     "                                 10

MySQL

mysql> SELECT memo, CASE WHEN c IS NULL THEN c ELSE CONCAT('"', c, '"') END AS "CHAR(10)", CHAR_LENGTH(c) FROM str;
+----------------------------+----------+----------------+
| memo                       | CHAR(10) | CHAR_LENGTH(c) |
+----------------------------+----------+----------------+
| NULL                       | NULL     |           NULL |
| Empty string               | ""       |              0 |
| SINGLE-BYTE SPACE          | ""       |              0 |
| SINGLE-BYTE 2 SPACEs       | ""       |              0 |
| SINGLE-BYTE CHAR and SPACE | "1"      |              1 |
| SINGLE-BYTE CHARs          | "12345"  |              5 |
| SINGLE-BYTE CHARs          | "12345"  |              5 |
+----------------------------+----------+----------------+

PostgreSQL

perftestdb=> SELECT memo, CASE WHEN c IS NULL THEN c ELSE '"'||c||'"' END AS "CHAR(10)", LENGTH(c) FROM str;
            memo            | CHAR(10) | length 
----------------------------+----------+--------
 NULL                       | [null]   | [null]
 Empty string               | ""       |      0
 SINGLE-BYTE SPACE          | ""       |      0
 SINGLE-BYTE 2 SPACEs       | ""       |      0
 SINGLE-BYTE CHAR and SPACE | "1"      |      1
 SINGLE-BYTE CHARs          | "12345"  |      5
 SINGLE-BYTE CHARs          | "12345"  |      5

明日の、JPOUG Advent Calendar 2024は、rkondoさん、MySQL Advent Calendar 2024は、今の所空いていますが誰かが書くはずw、そして、PostgreSQL Advent Calendar 2024は、kingtomo1122さん(シリーズ1)、yamatattsuさん(シリーズ2)です。

メーリークリスマスには少し早いですが、メリークリスマス！
良いお年をお迎えください。

では、また来年！（DTMのポストはまだする予定、DTMの全部俺アドベントカレンダーやってますのでw ）

Enjoy! SQL!

投稿日時 2024年12月21日 (土) 00時00分 Oracle, FAQ, SQL, MySQL, PostgreSQL, JPOUG, Advent Calendar | 固定リンク | 0 | コメント (0)

2024年12月13日 (金)

実行計画は, SQL文のレントゲン写真だ！ No.65 / JPOUG Advent Calendar 2024 / JSON-Relational Duality Views

本エントリーは、13日の金曜日のエントリーです。
昨日のポストは、Takayuki Nishio (Nisshii0)さんの「[Oracle] ここが違うよ Autonomous Database！初めてデータ移行して気づいたこと」でした。

ということで、私のターン。

皆様の期待通り？、13日の金曜日なので、JSON を取り上げておきたいと思います。(実は元々別のながーーーいネタを用意していたのですが、13日の金曜日であることに気づきwww 以下略)
Oracle Database のJSON関連機能について、すでに多くの方がブログ等で書かれていることもあり、本エントリーでは、Mac De Oracleっぽくw、実行計画という名のレントゲン写真はどうなのかw を診ておきたいと思います。

Stable Diffusion WebUI

対象とするのは、JSON-Relational Duality Views です。
この機能、名前の通り、リレーショナル表のままで、JSONにマッピングするVIEWを通して使えるようにしたものでOracle Database 23aiの新機能の一つです。（雑に解説すると。。）

気になりますよね。JSON-Relational Duality Viewsを介してアクセスした場合の実行計画！！！！

ちょっとわき道に逸れるのですが、Oracle Databaseには、RDFView という機能があります。リレーショナル表のままで、RDF Graphのトリプルとして参照する機能ですよね。これまた雑に解説すると。

実行計画は,SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 おまけ#3
トリプルとして扱うために、対象の列毎にSELECT文を作る必要がありかつ３列なのでUNIONも必要で、という想像通りのなかなかのレントゲン写真（実行計画でした）。

果たして、JSON-Relational Duality Views ではどうなるのか。。。。

早速、試してみましょう。

23aiを利用しています。

COTT@localhost:1521/freepdb1> select banner_full from v$version;

BANNER_FULL
--------------------------------------------------------------------------------
Oracle Database 23ai Free Release 23.0.0.0.0 - Develop, Learn, and Run for Free
Version 23.4.0.24.05

まず、JSON-Relational Duality ViewsはViewなので元になるリレーショナル表を決めちゃいます。dept表をもとにして department表を作って使いましょう。 dept表のままでも良いのですけどもw

SCOTT@localhost:1521/freepdb1> set linesize 80
SCOTT@localhost:1521/freepdb1> desc dept
 Name                                      Null?    Type
 ----------------------------------------- -------- ----------------------------
 DEPTNO                                    NOT NULL NUMBER(2)
 DNAME                                              VARCHAR2(14)
 LOC                                                VARCHAR2(13)

SCOTT@localhost:1521/freepdb1> select * from dept;

    DEPTNO DNAME          LOC
---------- -------------- -------------
        10 ACCOUNTING     NEW YORK
        20 RESEARCH       DALLAS
        30 SALES          CHICAGO
        40 OPERATIONS     BOSTON

SCOTT@localhost:1521/freepdb1> create table department as select * from dept;

Table created.

SCOTT@localhost:1521/freepdb1> alter table department add constraint pk_department primary key (deptno) using index;

Table altered.

department表の列をJSONのキーにマップしちゃうだけ（おまけで, UPDATE/INSERT/DELETEも許可していますが、今回はSELECTしかしませんw）
JSON RELATIONAL DUALITY VIEWを作成します。（見るとリレーショナル表の列とJSONのキーをマップしているだけですね。シンプル）

SCOTT@localhost:1521/freepdb1> l
  1  CREATE JSON RELATIONAL DUALITY VIEW department_dv
  2  AS
  3    SELECT
  4      JSON { '_id'            : d.deptno,
  5             'departmentName' : d.dname,
  6             'location'       : d.loc }
  7    FROM
  8      department d
  9*   WITH UPDATE INSERT DELETE
SCOTT@localhost:1521/freepdb1> /

View created.

SCOTT@localhost:1521/freepdb1> select collection_name,collection_type from user_json_collections;

COLLECTION_NAME                COLLECTION_T
------------------------------ ------------
DEPARTMENT_DV                  DUALITY VIEW

SCOTT@localhost:1521/freepdb1> set linesize 400
COTT@localhost:1521/freepdb1> select * from user_json_duality_views;

VIEW_NAME                      JSON ROOT_TABLE_NAME                ROOT_TABLE_OWNER               ALLOW_INSER ALLOW_UPDAT ALLOW_DELET READ_ONLY   JSON_SCHEMA                    STATUS
------------------------------ ---- ------------------------------ ------------------------------ ----------- ----------- ----------- ----------- ------------------------------ -------
DEPARTMENT_DV                  DATA DEPARTMENT                     SCOTT                          TRUE        TRUE        TRUE        FALSE       {"title":"DEPARTMENT_DV","dbOb VALID
                                                                                                                                                  ject":"SCOTT.DEPARTMENT_DV","d
                                                                                                                                                  bObjectType":"dualit

特に何も指定せず問い合わせると、まんまのJSONが返されます。

SCOTT@localhost:1521/freepdb1> set long 4000
SCOTT@localhost:1521/freepdb1> set longchunk 4000
SCOTT@localhost:1521/freepdb1> set linesize 400
SCOTT@localhost:1521/freepdb1> select * from department_dv;

DATA
--------------------------------------------------------------------------------------------------------------------------------------------------
{"_id":10,"_metadata":{"etag":"66F269F721C734BAE74D56D6A948D0F6","asof":"0000000001799313"},"departmentName":"ACCOUNTING","location":"NEW YORK"}
{"_id":20,"_metadata":{"etag":"8A0701C115BFECAB64C34E2FF406FFDA","asof":"0000000001799313"},"departmentName":"RESEARCH","location":"DALLAS"}
{"_id":30,"_metadata":{"etag":"A7CDA588F9052B35B56E00BB22B6EC6F","asof":"0000000001799313"},"departmentName":"SALES","location":"CHICAGO"}
{"_id":40,"_metadata":{"etag":"93AE902896310C0DFFCE3FC70E0479F6","asof":"0000000001799313"},"departmentName":"OPERATIONS","location":"BOSTON"}

さて、table full scanになると思いますが、とりあえず見てみましょう。

SCOTT@localhost:1521/freepdb1> set autot trace exp stat
SCOTT@localhost:1521/freepdb1> select * from department_dv;

Elapsed: 00:00:00.03

Execution Plan
----------------------------------------------------------
Plan hash value: 826413278

--------------------------------------------------------------------------------
| Id  | Operation         | Name       | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |            |     4 |    80 |     3   (0)| 00:00:01 |
|   1 |  TABLE ACCESS FULL| DEPARTMENT |     4 |    80 |     3   (0)| 00:00:01 |
--------------------------------------------------------------------------------

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

SCOTT@localhost:1521/freepdb1> set autot off
SCOTT@localhost:1521/freepdb1> set linesize 80
SCOTT@localhost:1521/freepdb1> desc department_dv
 Name                                      Null?    Type
 ----------------------------------------- -------- ----------------------------
 DATA                                               JSON

SCOTT@localhost:1521/freepdb1> set linesize 400
SCOTT@localhost:1521/freepdb1> col _id for a30
SCOTT@localhost:1521/freepdb1> col departmentName for a30
SCOTT@localhost:1521/freepdb1> col location for a30

...略...

リレーショナル表っぽいクエリーにもできます。

SCOTT@localhost:1521/freepdb1> r
  1  select d.data."_id",
  2         d.data."departmentName",
  3         d.data."location"
  4  from   department_dv d
  5* order by 1

_id                            departmentName                 location
------------------------------ ------------------------------ ------------------------------
10                             "ACCOUNTING"                   "NEW YORK"
20                             "RESEARCH"                     "DALLAS"
30                             "SALES"                        "CHICAGO"
40                             "OPERATIONS"                   "BOSTON"

では、次に、主キーにマップした _id 列でアクセスしてみましょう。おおおおお、普通に、INDEX UQNIQE SCANでしたね。（想像していた通りですがw）
Predicate Information に現れるアクセスパスを見ると、 access("D"."DEPTNO"=30) となっており、内部的にはリレーショナル表を問い合わせるSQL文に書き換えられているように見えますよね（まだ調べていないですがw）

SCOTT@localhost:1521/freepdb1> set autot trace exp stat
SCOTT@localhost:1521/freepdb1> select json_serialize(d.data pretty) from department_dv d where d.data."_id" = 30;

Elapsed: 00:00:00.01

Execution Plan
----------------------------------------------------------
Plan hash value: 3132674683

---------------------------------------------------------------------------------------------
| Id  | Operation                   | Name          | Rows  | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT            |               |     1 |    20 |     1   (0)| 00:00:01 |
|   1 |  TABLE ACCESS BY INDEX ROWID| DEPARTMENT    |     1 |    20 |     1   (0)| 00:00:01 |
|*  2 |   INDEX UNIQUE SCAN         | PK_DEPARTMENT |     1 |       |     0   (0)| 00:00:01 |
---------------------------------------------------------------------------------------------

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

 2 - access("D"."DEPTNO"=30)


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

SCOTT@localhost:1521/freepdb1> set autot off
SCOTT@localhost:1521/freepdb1> r
  1* select json_serialize(d.data pretty) from department_dv d where d.data."location" = 'CHICAGO'

JSON_SERIALIZE(D.DATAPRETTY)
----------------------------------------------------------------------------------------------------
{
  "_id" : 30,
  "_metadata" :
  {
    "etag" : "A7CDA588F9052B35B56E00BB22B6EC6F",
    "asof" : "0000000001799BF8"
  },
  "departmentName" : "SALES",
  "location" : "CHICAGO"
}

...略...

SCOTT@localhost:1521/freepdb1> r
  1  select
  2    d.data."_id" as deptno
  3  , d.data."departmentName" as department_name
  4  , d.data."location" as location
  5  from
  6    department_dv d
  7  where
  8*   d.data."location" = 'CHICAGO'

DEPTNO                         DEPARTMENT_NAME                LOCATION
------------------------------ ------------------------------ ------------------------------
30                             "SALES"                        "CHICAGO"

JSON-Relational Duality Viewsから問い合わせてもリレーショナル表を直接問い合わせるのと同じなんですねぇ。なんとなく安心w

13日の金曜日のJSONネタなので、恐ろしーい結果を期待していた方、ごめんなさいwwww JSON怖くないですw

明日のJPOUG Advent Calendar 2024は、ketsujiさんです。

投稿日時 2024年12月13日 (金) 00時00分 Oracle, チューニング, FAQ, SQL, JPOUG, パフォーマンス, Advent Calendar, RDF Graph, Oracle Database 23c Free Developer Release, JSON | 固定リンク | 0 | コメント (0)

2024年10月 2日 (水)

ミックさんの「SQL緊急救命室 ──非効率なコードを改善せよ！」を査読でお手伝いした話

SQL緊急救命室 ──非効率なコードを改善せよ！ - ミック（著）が9月14日に発売されました。

緊急治療wが必要なレベルのSQLと格闘する若手とベテラン医師（じゃなくて、DBエンジニア）のやり取り、覚えているだろうか。。
そう、2011-2012年にWeb+DB Pressに掲載されていた妙に親近感を覚えるやり取りw　（それに加え、時代に合わせた新ネタもあり）

気楽に読めるSQL本なので、ワイン片手にニヤニヤしながら楽しめると思います（若手の立場でも、ベテラン、いずれの目線でもw）

余談
日頃から打ちっぱなしでタイポ多めの私が査読をお願いされまして、長ーい付き合いもあり断りきれずにw（嘘、喜んでぇ〜！）
お手伝いさせていただきました。今まで気づけなかった細かいSQLの癖に気づいたり、ちょっと得した気分もありましたw

ミックさん、新型コロナ後遺症で一時は心配な状況でしたが、見事に復活、勢い余って書籍のリリースラッシュ、体調大丈夫なの？　
と余計な心配したりしてますが、完全復活したみたいで、マジで、よかった、よかった:)

投稿日時 2024年10月 2日 (水) 20時00分日記・コラム・つぶやき, SQL, 本, パフォーマンス | 固定リンク | 0 | コメント (0)

2024年9月 1日 (日)

なぜ、主キー制約の追加時間に違いがでるのでしょうか？　（東京都　ITエンジニア　男性）/ FAQ のおまけ

Previously on Mac De Oracle
前回は、なぜ、主キー制約の追加時間に違いがでるのでしょうか？　（東京都　ITエンジニア　男性）/ FAQでした。
今日は、おまけとして、前回意図的に書いていなかったツールを利用した場合にも意図せず発症してしまう一例を紹介したいと思います。

前回のエントリーで以下のようなことを書いていたのですがおぼえているでしょうか？。
回避方法は、主キー列のNOT NULL制約（チェック制約）が落ちてしまうのを避ければよいだけなので大した内容ではないのですが、Data Pumpっていう癖の多いツールが絡む場合の例なので書いておいたほうが良いかなぁと。ww

”それ以外のケースでは、各種ツール（Oracle database純正のもを含む）の使い方次第では意図せず遭遇してしまうこともあります。(ex. impdp利用時のオブジェクトの扱いを制御するパラメータの使い方によるもの、とか)”

では、早速準備から。
impdpするので、expdpしておかないといけません。それより前にData Pump用のディレクトリオブジェクトを作っておきましょう。ホスト側に実際のディレクトリを用意して権限なども忘れずに設定しておきましょうね。
CREATE DIRECTORY文ではそこまで検証してくれないので、impdp/expdp実行時に、”あ”〜っ” みたいなエラーに遭遇しないようにしておきますw（けっこうやらかしがちなんですけどね。私もwwww)

[oracle@localhost work]$ sqlplus scott@orclpdb1

...中略...

Oracle Database 21c Enterprise Edition Release 21.0.0.0.0 - Production
Version 21.3.0.0.0
に接続されました。
SCOTT@orclpdb1> CREATE DIRECTORY mydump_dir AS '/work';

ディレクトリが作成されました。

経過: 00:00:00.57
SCOTT@orclpdb1> ! ls -l /work
合計 0

SCOTT@orclpdb1>

次に、前回も作成したTABLE_2だけを用意します。主キー列にはNOT NULL制約があり、主キー制約も作成しておきます。（主キー制約追加で遅延が発生しなかった状態）

SCOTT@orclpdb1> @additional_example.sql

表が削除されました。

経過: 00:00:00.54
  1  CREATE TABLE table_2
  2  (
  3    id1 NUMBER NOT NULL
  4   ,id2 NUMBER NOT NULL
  5   ,text VARCHAR2(10)
  6* )

表が作成されました。

経過: 00:00:00.11
 名前                                    NULL?    型
 ----------------------------------------- -------- ----------------------------
 ID1                                       NOT NULL NUMBER
 ID2                                       NOT NULL NUMBER
 TEXT                                               VARCHAR2(10)

  1  BEGIN
  2    FOR i in 1..15000000 LOOP
  3      INSERT INTO table_2 VALUES(i,i,i);
  4      IF MOD(i,1000) = 0
  5      THEN
  6        COMMIT;
  7      END IF;
  8    END LOOP;
  9* END;

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

経過: 00:07:06.40
  1* ALTER TABLE table_2 ADD CONSTRAINT pk_table_2 PRIMARY KEY (id1, id2) USING INDEX

表が変更されました。

経過: 00:00:35.23

expdpで表モードでエクスポートしておきます。TABLE_2だけで十分。
正常にエクスポートできたら準備完了！

[oracle@localhost ~]$ expdp scott@orclpdb1 tables=scott.table_2 directory=mydump_dir dumpfile=scott_table_2.dmp

Export: Release 21.0.0.0.0 - Production on 土 8月 31 15:36:56 2024
Version 21.3.0.0.0

Copyright (c) 1982, 2021, Oracle and/or its affiliates.  All rights reserved.
パスワード: 

接続先: Oracle Database 21c Enterprise Edition Release 21.0.0.0.0 - Production
"SCOTT"."SYS_EXPORT_TABLE_01"を起動しています: scott/********@orclpdb1 tables=scott.table_2 directory=mydump_dir dumpfile=scott_table_2.dmp 
オブジェクト型TABLE_EXPORT/TABLE/TABLE_DATAの処理中です
オブジェクト型TABLE_EXPORT/TABLE/INDEX/STATISTICS/INDEX_STATISTICSの処理中です
オブジェクト型TABLE_EXPORT/TABLE/STATISTICS/TABLE_STATISTICSの処理中です
オブジェクト型TABLE_EXPORT/TABLE/STATISTICS/MARKERの処理中です
オブジェクト型TABLE_EXPORT/TABLE/TABLEの処理中です
オブジェクト型TABLE_EXPORT/TABLE/CONSTRAINT/CONSTRAINTの処理中です
. . "SCOTT"."TABLE_2"                           344.8 MB 15000000行がエクスポートされました
マスター表"SCOTT"."SYS_EXPORT_TABLE_01"は正常にロード/アンロードされました
******************************************************************************
SCOTT.SYS_EXPORT_TABLE_01に設定されたダンプ・ファイルは次のとおりです:
  /work/scott_table_2.dmp
ジョブ"SCOTT"."SYS_EXPORT_TABLE_01"が土 8月 31 15:38:00 2024 elapsed 0 00:00:50で正常に完了しました

では、主キー制約の追加で時間を要してしまう例の紹介から。

excludeオプションで、CONSTRAINTを除外してしまっています。後述しますが、これ方法で除外してしまうと全ての制約が除外されてしまいます。 NOT NULLもCHECK制約とい制約の一つなので、副作用を考慮せず除外してしまうと、NULLBALEな状態でインポートされていまうことを意味します。
つまり、今回話題にしている症状が発症してしまう典型的な状況が作り出されてしまうということですよね。そろそろ気づき始めましたかね？　

以下のインポートのログには、CONSTRAINTオブジェクトがインポートされたとは記録されません。exclude しちゃってますからね！（実は、制約名で一部の制約だけにしても同様のログになるのでわかりにくいのですけどね！　Data Pumpの癖の一つw）

[oracle@localhost ~]$ impdp scott@orclpdb1 tables=scott.table_2 exclude=constraint table_exists_action=replace directory=mydump_dir dumpfile=scott_table_2.dmp

Import: Release 21.0.0.0.0 - Production on 土 8月 31 16:15:43 2024
Version 21.3.0.0.0

Copyright (c) 1982, 2021, Oracle and/or its affiliates.  All rights reserved.
パスワード: 

接続先: Oracle Database 21c Enterprise Edition Release 21.0.0.0.0 - Production
マスター表"SCOTT"."SYS_IMPORT_TABLE_01"は正常にロード/アンロードされました
"SCOTT"."SYS_IMPORT_TABLE_01"を起動しています: scott/********@orclpdb1 tables=scott.table_2 exclude=constraint table_exists_action=replace directory=mydump_dir
 dumpfile=scott_table_2.dmp 
オブジェクト型TABLE_EXPORT/TABLE/TABLEの処理中です
オブジェクト型TABLE_EXPORT/TABLE/TABLE_DATAの処理中です
. . "SCOTT"."TABLE_2"                           344.8 MB 15000000行がインポートされました
オブジェクト型TABLE_EXPORT/TABLE/STATISTICS/TABLE_STATISTICSの処理中です
オブジェクト型TABLE_EXPORT/TABLE/STATISTICS/MARKERの処理中です
ジョブ"SCOTT"."SYS_IMPORT_TABLE_01"が土 8月 31 16:17:02 2024 elapsed 0 00:01:05で正常に完了しました

インポート完了後、desc でみると ID1, ID2ともにNULLABLEになっています。まずい状態ですよね
制約は全く存在しません。（exclude=constraintにしてしまったので当然ではあるわけですがw）

[oracle@localhost ~]$ sqlplus scott@orclpdb1

...中略...

Oracle Database 21c Enterprise Edition Release 21.0.0.0.0 - Production
Version 21.3.0.0.0
に接続されました。
1SCOTT@orclpdb1> set line 80
1SCOTT@orclpdb1> desc table_2
 名前                                    NULL?    型
 ----------------------------------------- -------- ----------------------------
 ID1                                                NUMBER
 ID2                                                NUMBER
 TEXT                                               VARCHAR2(10)

SCOTT@orclpdb1> SELECT table_name,constraint_name,constraint_type,search_condition FROM user_constraints WHERE table_name = 'TABLE_2';

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

経過: 00:00:04.90
SCOTT@orclpdb1> SELECT COUNT(1) FROM table_2;

  COUNT(1)
----------
  15000000

経過: 00:00:01.03

主キー制約追加で例の症状を発症させてみましょう！　主キー制約追加に、10秒もかかってますね。

SCOTT@orclpdb1> CREATE UNIQUE INDEX pk_table_2 ON table_2(id1, id2);

索引が作成されました。

経過: 00:00:30.11
SCOTT@orclpdb1> ALTER TABLE table_2 ADD CONSTRAINT pk_table_2 PRIMARY KEY (id1, id2) USING INDEX pk_table_2;

表が変更されました。

経過: 00:00:10.60
SCOTT@orclpdb1> desc table_2
 名前                                    NULL?    型
 ----------------------------------------- -------- ----------------------------
 ID1                                       NOT NULL NUMBER
 ID2                                       NOT NULL NUMBER
 TEXT                                               VARCHAR2(10)

SCOTT@orclpdb1> set line 400
SCOTT@orclpdb1> SELECT table_name,constraint_name,constraint_type,search_condition FROM user_constraints WHERE table_name = 'TABLE_2'

TABLE_NAME                     CONSTRAINT_NAME                CON SEARCH_CONDITION
------------------------------ ------------------------------ --- ------------------------------
TABLE_2                        PK_TABLE_2                     P

経過: 00:00:00.02

再確認のため、ID1, ID2をNOT NULLに変更した上で、主キー制約を追加してましょう。
見事に瞬殺で完了しているのがわかります！

SCOTT@orclpdb1> ALTER TABLE table_2 DROP PRIMARY KEY DROP INDEX;

表が変更されました。

経過: 00:00:00.39
SCOTT@orclpdb1> ALTER TABLE table_2 MODIFY (id1 NUMBER NOT NULL, id2 NUMBER NOT NULL);

表が変更されました。

経過: 00:00:03.02
SCOTT@orclpdb1> CREATE UNIQUE INDEX pk_table_2 ON table_2(id1, id2);

索引が作成されました。

経過: 00:00:27.11
SCOTT@orclpdb1> ALTER TABLE table_2 ADD CONSTRAINT pk_table_2 PRIMARY KEY (id1, id2) USING INDEX pk_table_2;

表が変更されました。

経過: 00:00:00.01
SCOTT@orclpdb1> set line 80
SCOTT@orclpdb1> desc table_2
 名前                                    NULL?    型
 ----------------------------------------- -------- ----------------------------
 ID1                                       NOT NULL NUMBER
 ID2                                       NOT NULL NUMBER
 TEXT                                               VARCHAR2(10)

SCOTT@orclpdb1> set line 400
SCOTT@orclpdb1> SELECT table_name,constraint_name,constraint_type,search_condition FROM user_constraints WHERE table_name = 'TABLE_2';

TABLE_NAME                     CONSTRAINT_NAME                CON SEARCH_CONDITION
------------------------------ ------------------------------ --- ------------------------------
TABLE_2                        SYS_C0010546                   C   "ID1" IS NOT NULL
TABLE_2                        SYS_C0010547                   C   "ID2" IS NOT NULL
TABLE_2                        PK_TABLE_2                     P

経過: 00:00:00.03

ということで、Data Pumpのマニュアルの excludeオプションの仕様を確認！！！

Oracle Database / Release 23 / ユーティリティ / 2 Oracle Data Pumpエクスポート / 2.4.23 EXCLUDE https://docs.oracle.com/cd/F82042_01/sutil/oracle-data-pump-export-utility.html#SUTIL-GUID-64249296-2AFF-40EA-AA44-BC0A1B5A1E7C

"制約の除外
次の制約は明示的に除外できません。
表の作成とロードを正常に行うために必要な制約。たとえば、索引構成表の主キー制約、REF列を持つ表のREF SCOPEおよびWITH ROWID制約など
たとえば、次のEXCLUDE文は、次のように解釈されます。
EXCLUDE=CONSTRAINTでは、表の正常な作成およびロードに必要な制約を除く、すべての制約を除外します。
EXCLUDE=REF_CONSTRAINTは、参照整合性(外部キー)制約を除外します。"

と記されています。

SCHEMA_EXPORT_OBJECTSで確認しておきましょう. Oracle Data Pumpと仲良くなるために忘れちゃいけないのがこのビューですよ。（覚えておきましょう）
TABLE/CONSTRAINT , TABLE/CONSTRAINT/REF_CONSTRAINT という制約に関連するオブジェクトパスがありますが、ここがポイント。マニュアル通り、exclude/includeで制御できるのはこのレベルまで
参照整合性制約と、すべての制約のいずれかのパスしか選べません。つまりこれより細かく、例えば、主キー制約だけexcludeしたいという場合には、ピンポイントでオブジェクト名でフィルタする必要があるということを意味します。

つまり、 impdpのexcludeオプションで constraint としてインポートしてしまったため、主キー制約だけでなく、今回話題にしている主キー列のNOT NULL制約（CHECK制約で検証されることは前回も記載したとおり）も丸っと削除されてしまったため、今回話題にしている主キー制約の追加で時間を要してしまう症状が発症してしまった！！　ということ。　前回少しだけ触れていた、ツールの使い方によっては影響を受ける可能性があるということの一例です。

SCOTT@orclpdb1> SELECT object_path,comments FROM schema_export_objects WHERE object_path LIKE '%TABLE%' ORDER BY object_path;

OBJECT_PATH                                                  COMMENTS
------------------------------------------------------------ ----------------------------------------------------

...中略...

SCHEMA_EXPORT/TABLE/COMMENT                                  Table and column comments on the selected tables
SCHEMA_EXPORT/TABLE/CONSTRAINT                               Constraints (including referential constraints)
SCHEMA_EXPORT/TABLE/CONSTRAINT/REF_CONSTRAINT                Referential constraints
SCHEMA_EXPORT/TABLE/FGA_POLICY                               Fine-grained auditing policies

...中略...

TABLE/COMMENT                                                Table and column comments on the selected tables
TABLE/CONSTRAINT                                             Constraints (including referential constraints)
TABLE/CONSTRAINT/REF_CONSTRAINT                              Referential constraints
TABLE/FGA_POLICY                                             Fine-grained auditing policies
TABLE/GRANT                                                  Object grants on the selected tables

...中略...

TABLE/RLS_POLICY/RLS_POLICY                                  Fine-grained access control policies
TABLE/TRIGGER                                                Triggers
TABLESPACE_QUOTA                                             Tablespace quotas granted to users associated with the selected schemas

52行が選択されました。

経過: 00:00:00.40

対処方法は細かくフィルタして、NOT NULL制約は残したまま、主キー制約だけexceludeしましょう。簡単ですよね。Data Pumpに慣れている皆さんなら:)
マニュアルには書かれていないですが、コマンドラインの場合、"(ダブルクォート)や、'(シングルクォート)を利用する場合はバックスラッシュ（Windowsだと¥だったかな。使わないのでド忘れしたので間違ってたらツッコミよろしゅう）でエスケープしておく必要があります。ここでも、Data Pumpの癖が炸裂してますねw ()
今回は、PK_TABLE_2という主キー制約だけを除外しています。（インポート後にNOT NULL制約はインポートされていることを確認します）

[oracle@localhost ~]$ impdp scott@orclpdb1 tables=scott.table_2 exclude=constraint:\"=\'PK_TABLE_2\'\" table_exists_action=replace directory=mydump_dir dumpfile=scott_table_2.dmp

Import: Release 21.0.0.0.0 - Production on 土 8月 31 16:43:11 2024
Version 21.3.0.0.0

Copyright (c) 1982, 2021, Oracle and/or its affiliates.  All rights reserved.
パスワード: 

接続先: Oracle Database 21c Enterprise Edition Release 21.0.0.0.0 - Production
マスター表"SCOTT"."SYS_IMPORT_TABLE_01"は正常にロード/アンロードされました
"SCOTT"."SYS_IMPORT_TABLE_01"を起動しています: scott/********@orclpdb1 tables=scott.table_2 exclude=constraint:"='PK_TABLE_2'" table_exists_action=replace directory=mydump_dir dumpfile=scott_table_2.dmp 
オブジェクト型TABLE_EXPORT/TABLE/TABLEの処理中です
オブジェクト型TABLE_EXPORT/TABLE/TABLE_DATAの処理中です
. . "SCOTT"."TABLE_2"                           344.8 MB 15000000行がインポートされました
オブジェクト型TABLE_EXPORT/TABLE/STATISTICS/TABLE_STATISTICSの処理中です
オブジェクト型TABLE_EXPORT/TABLE/STATISTICS/MARKERの処理中です
ジョブ"SCOTT"."SYS_IMPORT_TABLE_01"が土 8月 31 16:44:22 2024 elapsed 0 00:01:02で正常に完了しました

正常にインポートできました！　制約関連が想定通りにインポートされているか確認！
（excludeオプションでCONSTRAINTを除外してしまうと、オブジェクト名でフィルタリングしていたとしてもCONSTRAINTがインポートされた（一部）とは記録もされません。この癖も改善して惜しい癖なんだけどなかなか改善してくれないですね→オラクルさん）

ID1, ID2列に NOT NULL制約が付いています。また、主キー制約は存在していません。
descコマンドや、dba/user_tab_clumnsでは、主キー制約によるNOT NULLの制約であっても、NOT NULLと表示されるため確認は、必ず、dba/user_constraintsで該当列のconstraint_typeが'C'でsearch_conditionに xxxx IS NOT NULLというチェック制約でNOT NULLが保証されていることを確認する必要あるので見落とさないようにしてくださいね。（ここ重要!!）

[oracle@localhost ~]$ sqlplus scott@orclpdb1

...中略...

Oracle Database 21c Enterprise Edition Release 21.0.0.0.0 - Production
Version 21.3.0.0.0
に接続されました。
SCOTT@orclpdb1> set line 80
SCOTT@orclpdb1> desc table_2
 名前                                    NULL?    型
 ----------------------------------------- -------- ----------------------------
 ID1                                       NOT NULL NUMBER
 ID2                                       NOT NULL NUMBER
 TEXT                                               VARCHAR2(10)

SCOTT@orclpdb1> set line 400
SCOTT@orclpdb1> col constraint_name for a30
SCOTT@orclpdb1> SELECT table_name,constraint_name,constraint_type,search_condition FROM user_constraints WHERE table_name = 'TABLE_2';

TABLE_NAME                     CONSTRAINT_NAME                CON SEARCH_CONDITION
------------------------------ ------------------------------ --- --------------------------------------------------------------------------------
TABLE_2                        SYS_C0010597                   C   "ID1" IS NOT NULL
TABLE_2                        SYS_C0010598                   C   "ID2" IS NOT NULL

経過: 00:00:00.02
SCOTT@orclpdb1> SELECT table_name,index_name FROM user_indexes WHERE table_name = 'TABLE_2';

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

経過: 00:00:00.08

では、主キー制約の追加が瞬殺で終わることを確認して、今回のネタはおしまい！　:)

SCOTT@orclpdb1> CREATE UNIQUE INDEX pk_table_2 ON table_2(id1, id2);

索引が作成されました。

経過: 00:00:29.75
SCOTT@orclpdb1> ALTER TABLE table_2 ADD CONSTRAINT pk_table_2 PRIMARY KEY (id1, id2) USING INDEX pk_table_2;

表が変更されました。

経過: 00:00:00.07

SCOTT@orclpdb1> set line 80
SCOTT@orclpdb1> desc table_2
 名前                                    NULL?    型
 ----------------------------------------- -------- ----------------------------
 ID1                                       NOT NULL NUMBER
 ID2                                       NOT NULL NUMBER
 TEXT                                               VARCHAR2(10)

SCOTT@orclpdb1> set line 400
SCOTT@orclpdb1> SELECT table_name,constraint_name,constraint_type,search_condition FROM user_constraints WHERE table_name = 'TABLE_2';

TABLE_NAME                     CONSTRAINT_NAME                CON SEARCH_CONDITION
------------------------------ ------------------------------ --- --------------------------------------------------------------------------------
TABLE_2                        SYS_C0010597                   C   "ID1" IS NOT NULL
TABLE_2                        SYS_C0010598                   C   "ID2" IS NOT NULL
TABLE_2                        PK_TABLE_2                     P

経過: 00:00:00.02
SCOTT@orclpdb1> SELECT table_name,index_name FROM user_indexes WHERE table_name = 'TABLE_2';

TABLE_NAME                     INDEX_NAME
------------------------------ ------------------------------
TABLE_2                        PK_TABLE_2

経過: 00:00:00.01

ノロノロ台風？みたいなやつ、まじではなく、どこかへいってほしいっすねw （天候がめんどくさいことになってて勘弁してくれという感じの東京より

ではまた。

参考）準備に利用したスクリプト

[oracle@localhost ~]$ cat additional_example.sql
DROP TABLE table_2;

CREATE TABLE table_2
(
  id1 NUMBER NOT NULL
 ,id2 NUMBER NOT NULL
 ,text VARCHAR2(10)
)
.
l
/
set line 80
desc table_2
set line 400

BEGIN
  FOR i in 1..15000000 LOOP
    INSERT INTO table_2 VALUES(i,i,i);
    IF MOD(i,1000) = 0 
    THEN 
      COMMIT;
    END IF;
  END LOOP;
END;
.
l
/

ALTER TABLE table_2 ADD CONSTRAINT pk_table_2 PRIMARY KEY (id1, id2) USING INDEX
.
l
/

・RDS Oracle 雑多なメモ#18 / DBMS_DATAPUMPパッケージ de expdp/impdp
・RDS Oracle 雑多なメモ#19 FAQ / DBMS_DATAPUMPパッケージ de ジョブの停止

・なぜ、主キー制約の追加時間に違いがでるのでしょうか？　（東京都　ITエンジニア　男性）/ FAQ

投稿日時 2024年9月 1日 (日) 07時54分 Oracle, チューニング, FAQ, SQL, パフォーマンス | 固定リンク | 0 | コメント (0)

2024年8月30日 (金)

なぜ、主キー制約の追加時間に違いがでるのでしょうか？　（東京都　ITエンジニア　男性）/ FAQ

え～〜っ、
十年ひと昔てぇなぁこと申しますけれど、十年経つと元へ戻るんですってねぇ。
あの問題でハマった〜ってぇ話題をおもいだしやして、ググってみたんでさぁ、ありましたよ、ありましたよ！
十年数年前。

落語調で入ってみましたww

さて、今日の患者さん、
何にハマってたのかぁってぇと、主キー制約を追加するのに〜、偉い時間がかかって、頭を抱えて相談に。
（いい加減、落語っぽい言葉遣いヤメぇ！w

この話題、10年以上前のOracle Forumでも話題になった有名な、FAQだよねー。
元々そういうリスクのあるテーブル定義だったり、各種ツールの使い方によっては遭遇することもあるので、この症状を覚えておくと対処もしやすいですよ。というお話をしたいと思います。

まずは、当時話題になったスレ。
Oracle Forum - SQL & PL/SQL "ALTER TABLE xxx add constraint primary key" takes long long time!

この症状、ご存知の方も多いと思うのですが、Forum外で言及しているエントリーって見たこともあまりないので、実はあまり知られてなかったりして。。w　という心配もあり、メモがわりにブログに書いておきますね:)

ただし、この症状が顕著に現れるのは大規模な表の場合だけ（数十TBとか）なので、少量のデータだと気づかずというか影響していないことも多いので注意が必要なんです。（データが増加してから初めて気づいたりしてザワザワしたりするので）
巨大なデータを扱う場合、物凄い遅延に繋がってしまったりするので、舐めちゃいけません。

症状と原因をサクッとまとめると、

きっかけとなる主キー制約には以下の特徴があります。
・主キー制約では、キー値（複合キーの場合はキー全体で）が一意であり、NULL が含まれないでないことが保証されます。
NULLでないことが保証されるという点が今回のポイント。NULLと聞いてガタッとしたあなた！。いいリアクションです！w

主キー制約追加時には、主キーに含まれる列の値は NULL ではないことが検証されます。

（ここが大切なので3度書いておきましたw 太字でw

この NULL ではないことを保証するために、追加のIOと NULL でないことのチェックが塵も積もで、処理時間が伸びてしまう症状につながります。これは対象のデータ量に比例して伸びるので、データ量が少ないとほぼ気づきませんw
ただでさえ処理時間を要する大量データの場合のみ顕著な影響が現れます！！！！！

ただ、一般的には、主キー列として利用される列は NOT NULL となっている多いはずですが、
稀に、どうせ主キー制約でNOT NULLが保証されるから、それぞれの列には NOT NULL制約 (Oracle DatabaseではCHECK制約として実装されます) を付加しない！　という方も見かけますが、それ手を抜かない方がいいですよ。
そんな横着していると、今回お見せするような症状を発症してしまうことがあります。
それ以外のケースでは、各種ツール（Oracle database純正のもを含む）の使い方次第では意図せず遭遇してしまうこともあります。(ex. impdp利用時のオブジェクトの扱いを制御するパラメータの使い方によるもの、とか)

症状と原因が理解できれば対処方法は簡単。そのような状態を避ければ良いだけですね！　w
そんな大した話ではなくて、
・主キー制約に含める列は列定義レベルで、NOT NULL制約を付加しておきましょう！
・各種ツールの利用方法による副作用で、NULLABLEになってしまうようなケースでは、その状況を回避する利用手順なり、オプションを選ぶようにすることです。

これ覚えておくと、妙なところで時間溶かさなくて済むので、頭の片隅に置いておくと良いと思いますよ:)

では、簡単な例で、遅延の発生と、裏で何が起こっているのか10046トレースで、サクッと軽めに確認しておきましょう！

スクリプトの内容は本記事の後半に載せますので参考にしてみてください。

table_1/tabl_2を作成して、それぞれ、400MBほどになるようにデータを登録。（違いは、id2の列がNULLABLEかNOT NULLかだけです。この列は複合主キーに含まれます）


SCOTT@orclpdb1> @why_do_you_think_it_is_slow_adding_the_primary_constraint.sql

表が削除されました。

経過: 00:00:01.25

表が削除されました。

経過: 00:00:00.07
  1  CREATE TABLE table_1
  2  (
  3    id1 NUMBER NOT NULL
  4   ,id2 NUMBER
  5   ,text VARCHAR2(10)
  6* )

表が作成されました。

経過: 00:00:00.18
 名前                                    NULL?    型
 ----------------------------------------- -------- ----------------------------
 ID1                                       NOT NULL NUMBER
 ID2                                                NUMBER
 TEXT                                               VARCHAR2(10)

  1  CREATE TABLE table_2
  2  (
  3    id1 NUMBER NOT NULL
  4   ,id2 NUMBER NOT NULL
  5   ,text VARCHAR2(10)
  6* )

表が作成されました。

経過: 00:00:00.02
 名前                                    NULL?    型
 ----------------------------------------- -------- ----------------------------
 ID1                                       NOT NULL NUMBER
 ID2                                       NOT NULL NUMBER
 TEXT                                               VARCHAR2(10)

  1  BEGIN
  2    FOR i in 1..15000000 LOOP
  3      INSERT ALL
  4        INTO table_1 VALUES(i,i,i)
  5        INTO table_2 VALUES(i,i,i)
  6      SELECT null FROM dual
  7      ;
  8      IF MOD(i,1000) = 0
  9      THEN
 10        COMMIT;
 11      END IF;
 12    END LOOP;
 13* END;

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

経過: 00:11:42.62

ALTER TABLE ADD CONSTRAINT PRIMARY KEYで id1とid2の複合キーで主キー制約を追加。同時に索引も作成させる
今回の程度データ量だとびっくりするほどの差は見えずらいですが、id2がnullableであるtable_1の方が、約11秒ほど処理時間が長くなっています！
ちょっとわかりにくくなる原因は、制約追加と同時に索引も作成しているため索引作成の時間に埋もれやすく、索引作成の時間だと勘違いする方が多い影響もありますが、データ量が多くなればなるほどこの差は大きくなります。

  1* ALTER TABLE table_1 ADD CONSTRAINT pk_table_1 PRIMARY KEY (id1, id2) USING INDEX

表が変更されました。

経過: 00:00:48.31
  1* ALTER TABLE table_2 ADD CONSTRAINT pk_table_2 PRIMARY KEY (id1, id2) USING INDEX

表が変更されました。

経過: 00:00:36.92

最初の例は、索引の作成時間も含まれいるため制約の追加のオーバーヘッドがわかりにくいので他の手順で確認してみると。。。。
ALTER TABLE ADD CONSTRAINT PRIMARY KEY USING [事前に作成しておいた一意索引名]部分（赤字）に注目。
制約の追加で、id2がNULLABLEかNOT NULLという部分だけの違いで、272倍の差になっています。table_2の制約追加時間はデータ量が増加してもほぼ一定なので、データ量が増加した場合の影響はどれぐらいかは想像してみてくださいね。
今回は、2列からなる複合主キーの1列だけですが、異なる条件では差は広がる可能性はあります。（環境の差も含め）

  1* ALTER TABLE table_1 DROP PRIMARY KEY DROP INDEX

表が変更されました。

経過: 00:00:00.93
  1* ALTER TABLE table_2 DROP PRIMARY KEY DROP INDEX

表が変更されました。

経過: 00:00:00.10
  1* CREATE UNIQUE INDEX pk_table_1 ON table_1(id1, id2)

索引が作成されました。

経過: 00:00:33.84
  1* CREATE UNIQUE INDEX pk_table_2 ON table_2(id1, id2)

索引が作成されました。

経過: 00:00:36.13
  1* ALTER TABLE table_1 ADD CONSTRAINT pk_table_1 PRIMARY KEY (id1, id2) USING INDEX pk_table_1

表が変更されました。

経過: 00:00:05.44
  1* ALTER TABLE table_2 ADD CONSTRAINT pk_table_2 PRIMARY KEY (id1, id2) USING INDEX pk_table_2

表が変更されました。

経過: 00:00:00.02

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

経過: 00:00:18.53

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

経過: 00:00:15.50

SEGMENT_NAME                           MB
------------------------------ ----------
PK_TABLE_1                            368
PK_TABLE_2                            368
TABLE_1                               416
TABLE_2                               416

経過: 00:00:00.26

最後にNOT NULLにしておけば回避できることも確認
table_1のid2列をNOT NULLに変更して。。。

  1* ALTER TABLE table_1 DROP PRIMARY KEY DROP INDEX

表が変更されました。

経過: 00:00:00.41

 名前                                    NULL?    型
 ----------------------------------------- -------- ----------------------------
 ID1                                       NOT NULL NUMBER
 ID2                                                NUMBER
 TEXT                                               VARCHAR2(10)

  1* ALTER TABLE table_1 MODIFY id2 NUMBER NOT NULL

表が変更されました。

経過: 00:00:03.14

変更後のtabl_1 (table_2と同一定義になっています！)表の id2はNULLABLE から NOT NULL へ変更

 名前                                    NULL?    型
 ----------------------------------------- -------- ----------------------------
 ID1                                       NOT NULL NUMBER
 ID2                                       NOT NULL NUMBER
 TEXT                                               VARCHAR2(10)

table_2同様の処理時間となり大きく改善！ 11秒のオーバーヘッドが消えてますね！

  1* ALTER TABLE table_1 ADD CONSTRAINT pk_table_1 PRIMARY KEY (id1, id2) USING INDEX

表が変更されました。

経過: 00:00:34.65

主キー制約の追加部分に絞って改善を確認してみましょう！
table_2同様の処理時間となり大きく改善！ 0.02秒で完了　

  1* ALTER TABLE table_1 DROP PRIMARY KEY DROP INDEX

表が変更されました。

経過: 00:00:00.13
  1* CREATE UNIQUE INDEX pk_table_1 ON table_1(id1, id2)

索引が作成されました。

経過: 00:00:32.22
  1* ALTER TABLE table_1 ADD CONSTRAINT pk_table_1 PRIMARY KEY (id1, id2) USING INDEX pk_table_1

表が変更されました。

経過: 00:00:00.02

最後に、10046トレースで違い見る！
一目瞭然ですよね。　10046トレースでALTER文を拾ってみると、ID2列がNULLABLEdであるケースではexecuteで大量のqueryが発生していて、db file scattered readやdb file sequential readでオブジェクトを読みにに行っていることがわかります。これようするに該当列値に NULLが存在しないことを保証しなければならない主キー制約の宿命なわけですが、この作業を軽くしてくれているので、table_2のid2列にあるようなNOT NULL制約です。これがあればメタ情報をみるだけで NULL は存在しないことを確認できちゃいますからね。処理時間の差はそこだけです！

SCOTT@orclpdb1> @dive_in
DROP TABLE table_1 PURGE
           *
行1でエラーが発生しました。:
ORA-00942: 表またはビューが存在しません。

経過: 00:00:00.01
DROP TABLE table_2 PURGE
           *
行1でエラーが発生しました。:
ORA-00942: 表またはビューが存在しません。

経過: 00:00:00.01
  1  CREATE TABLE table_1
  2  (
  3    id1 NUMBER NOT NULL
  4   ,id2 NUMBER
  5   ,text VARCHAR2(10)
  6* )

表が作成されました。

 名前                                    NULL?    型
 ----------------------------------------- -------- ----------------------------
 ID1                                       NOT NULL NUMBER
 ID2                                                NUMBER
 TEXT                                               VARCHAR2(10)

  1  CREATE TABLE table_2
  2  (
  3    id1 NUMBER NOT NULL
  4   ,id2 NUMBER NOT NULL
  5   ,text VARCHAR2(10)v  6* )

表が作成されました。

 名前                                    NULL?    型
 ----------------------------------------- -------- ----------------------------
 ID1                                       NOT NULL NUMBER
 ID2                                       NOT NULL NUMBER
 TEXT                                               VARCHAR2(10)

  1  BEGIN
  2    FOR i in 1..15000000 LOOP
  3      INSERT ALL
  4        INTO table_1 VALUES(i,i,i)
  5        INTO table_2 VALUES(i,i,i)
  6      SELECT null FROM dual
  7      ;
  8      IF MOD(i,1000) = 0
  9      THEN
 10        COMMIT;
 11      END IF;
 12    END LOOP;
 13* END;

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

  1* CREATE UNIQUE INDEX pk_table_1 ON table_1(id1, id2)

索引が作成されました。

  1* CREATE UNIQUE INDEX pk_table_2 ON table_2(id1, id2)

索引が作成されました。

Oracle Database 21c Enterprise Edition Release 21.0.0.0.0 - Production
Version 21.3.0.0.0との接続が切断されました。
接続されました。

セッションが変更されました。

...略...

経過: 00:00:00.02
  1* ALTER TABLE table_1 ADD CONSTRAINT pk_table_1 PRIMARY KEY (id1, id2) USING INDEX pk_table_1

表が変更されました。

経過: 00:00:07.12

セッションが変更されました。

経過: 00:00:00.01
Oracle Database 21c Enterprise Edition Release 21.0.0.0.0 - Production
Version 21.3.0.0.0との接続が切断されました。
接続されました。

...略...

セッションが変更されました。

経過: 00:00:00.01
  1* ALTER TABLE table_2 ADD CONSTRAINT pk_table_2 PRIMARY KEY (id1, id2) USING INDEX pk_table_2

表が変更されました。

経過: 00:00:00.05

セッションが変更されました。

経過: 00:00:00.00
Oracle Database 21c Enterprise Edition Release 21.0.0.0.0 - Production
Version 21.3.0.0.0との接続が切断されました。
接続されました。

表が削除されました。

表が削除されました。

[oracle@localhost ~]$ ls -lrt $ORACLE_BASE/diag/rdbms/orclcdb/ORCLCDB/trace/*table_1*
-rw-r-----. 1 oracle oinstall  48367  8月 28 20:11 /opt/oracle/diag/rdbms/orclcdb/ORCLCDB/trace/ORCLCDB_ora_7254_10046_table_1_slow.trm
-rw-r-----. 1 oracle oinstall 348949  8月 28 20:11 /opt/oracle/diag/rdbms/orclcdb/ORCLCDB/trace/ORCLCDB_ora_7254_10046_table_1_slow.trc
[oracle@localhost ~]$ tkprof /opt/oracle/diag20dbms/orclcdb/ORCLCDB/trace/ORCLCDB_ora_7254_10046_table_1_slow.trc ORCLCDB_ora_7254_10046_table_1_slow.txt sys=yes waits=yes

TKPROF: Release 21.0.0.0.0 - Development on 水 8月 28 20:14:16 2024

[oracle@localhost ~]$ view ORCLCDB_ora_7254_10046_table_1_slow.txt

...略...

SQL ID: 48v4hxnmpykdy Plan Hash: 0

ALTER TABLE table_1 ADD CONSTRAINT pk_table_1 PRIMARY KEY (id1, id2) USING
  INDEX pk_table_1

call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        1      0.01       0.02          2          4          0           0
Execute      1      4.15       6.85      48874      52229          2           0
Fetch        0      0.00       0.00          0          0          0           0
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total        2      4.16       6.88      48876      52233          2           0

Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 109

Elapsed times include waiting on following events:
  Event waited on                             Times   Max. Wait  Total Waited
  ----------------------------------------   Waited  ----------  ------------
  Disk file operations I/O                        1        0.00          0.00
  db file scattered read                       1425        0.01          2.03
  db file sequential read                        54        0.00          0.04
  Compression analysis                            9        0.00          0.00
  log file sync                                   1        0.00          0.00
  PGA memory operation                            1        0.00          0.00
  SQL*Net message to client                       1        0.00          0.00
  SQL*Net message from client                     1        0.00          0.00
********************************************************************************

...略...


[oracle@localhost ~]$ ls -lrt $ORACLE_BASE/diag/rdbms/orclcdb/ORCLCDB/trace/*table_2*
-rw-r-----. 1 oracle oinstall 15431  8月 28 20:11 /opt/oracle/diag/rdbms/orclcdb/ORCLCDB/trace/ORCLCDB_ora_7256_10046_table_2_fast.trm
-rw-r-----. 1 oracle oinstall 67970  8月 28 20:11 /opt/oracle/diag/rdbms/orclcdb/ORCLCDB/trace/ORCLCDB_ora_7256_10046_table_2_fast.trc
[oracle@localhost ~]$ 
[oracle@localhost ~]$ tkprof /opt/oracle/diag/rdbms/orclcdb/ORCLCDB/trace/ORCLCDB_ora_7256_10046_table_2_fast.trc ORCLCDB_ora_7256_10046_table_2_fast.txt  sys=yes waits=yes

TKPROF: Release 21.0.0.0.0 - Development on 水 8月 28 20:17:33 2024

[oracle@localhost ~]$ view ORCLCDB_ora_7256_10046_table_2_fast.txt

...略...

SQL ID: 7x7hqgxcpkyky Plan Hash: 0

ALTER TABLE table_2 ADD CONSTRAINT pk_table_2 PRIMARY KEY (id1, id2) USING
  INDEX pk_table_2

call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        1      0.00       0.01          2          4          0           0
Execute      1      0.00       0.00          3         41          2           0
Fetch        0      0.00       0.00          0          0          0           0
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total        2      0.01       0.01          5         45          2           0

Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 109

Elapsed times include waiting on following events:
  Event waited on                             Times   Max. Wait  Total Waited
  ----------------------------------------   Waited  ----------  ------------
  Compression analysis                            9        0.00          0.00
  SQL*Net message to client                       1        0.00          0.00
  SQL*Net message from client                     1        0.00          0.00
********************************************************************************

（参考）利用したスクリプト

[oracle@localhost ~]$ cat why_do_you_think_it_is_slow_adding_the_primary_constraint.sql
set line 80
DROP TABLE table_1 PURGE;
DROP TABLE table_2 PURGE;

CREATE TABLE table_1
(
  id1 NUMBER NOT NULL
 ,id2 NUMBER
 ,text VARCHAR2(10)
)
.
l
/
desc table_1

CREATE TABLE table_2
(
  id1 NUMBER NOT NULL
 ,id2 NUMBER NOT NULL
 ,text VARCHAR2(10)
)
.
l
/
desc table_2

set line 400

BEGIN
  FOR i in 1..15000000 LOOP
    INSERT ALL
      INTO table_1 VALUES(i,i,i)
      INTO table_2 VALUES(i,i,i)
    SELECT null FROM dual
    ;
    IF MOD(i,1000) = 0 
    THEN 
      COMMIT;
    END IF;
  END LOOP;
END;
.
l
/

ALTER TABLE table_1 ADD CONSTRAINT pk_table_1 PRIMARY KEY (id1, id2) USING INDEX
.
l
/

ALTER TABLE table_2 ADD CONSTRAINT pk_table_2 PRIMARY KEY (id1, id2) USING INDEX
.
l
/

ALTER TABLE table_1 DROP PRIMARY KEY DROP INDEX
.
l
/
ALTER TABLE table_2 DROP PRIMARY KEY DROP INDEX
.
l
/

CREATE UNIQUE INDEX pk_table_1 ON table_1(id1, id2)
.
l
/
CREATE UNIQUE INDEX pk_table_2 ON table_2(id1, id2)
.
l
/
ALTER TABLE table_1 ADD CONSTRAINT pk_table_1 PRIMARY KEY (id1, id2) USING INDEX pk_table_1
.
l
/
ALTER TABLE table_2 ADD CONSTRAINT pk_table_2 PRIMARY KEY (id1, id2) USING INDEX pk_table_2
.
l
/

@gather_tab_stats table_1
@gather_tab_stats table_2

col segment_name for a30
SELECT 
  SEGMENT_NAME
 ,BLOCKS * 8 / 1024 AS "MB"
FROM
  USER_SEGMENTS
WHERE
  SEGMENT_NAME IN (
    'TABLE_1'
   ,'TABLE_2'
   ,'PK_TABLE_1'
   ,'PK_TABLE_2'
  )
ORDER BY 
  SEGMENT_NAME
;

PROMPT **************** table_1のid2列をNOT NULLに変更 ******************
ALTER TABLE table_1 DROP PRIMARY KEY DROP INDEX
.
l
/

set line 80
PROMPT 変更前のtable_1
desc table_1
ALTER TABLE table_1 MODIFY id2 NUMBER NOT NULL
.
l
/
PROMPT 変更後のtabl_1 (table_2と同一定義になっています！) id2はNULLABLE から NOT NULL へ変更されました
desc table_1
set line 400

PROMPT  ******　table_2同様の処理時間となり大きく改善！　*******
ALTER TABLE table_1 ADD CONSTRAINT pk_table_1 PRIMARY KEY (id1, id2) USING INDEX
.
l
/

PROMPT ***** 主キー制約の追加部分に絞って改善を確認してみましょう！
ALTER TABLE table_1 DROP PRIMARY KEY DROP INDEX
.
l
/
CREATE UNIQUE INDEX pk_table_1 ON table_1(id1, id2)
.
l
/

PROMPT ******  table_2同様の処理時間となり大きく改善！ *****
ALTER TABLE table_1 ADD CONSTRAINT pk_table_1 PRIMARY KEY (id1, id2) USING INDEX pk_table_1
.
l
/

（参考）内部で利用している統計情報取得スクリプト

[oracle@localhost ~]$ cat gather_tab_stats.sql
set verify on
eXEC DBMS_STATS.GATHER_TABLE_STATS(ownname=>'SCOTT',tabname=>upper('&1'),cascade=>true,no_invalidate=>false);
set verify off
undefine 1

（参考）10046トレース状況を覗くためのスクリプト

[oracle@localhost ~]$ cat dive_in.sql
set line 80
DROP TABLE table_1 PURGE;
DROP TABLE table_2 PURGE;

CREATE TABLE table_1
(
  id1 NUMBER NOT NULL
 ,id2 NUMBER
 ,text VARCHAR2(10)
)
.
l
/
desc table_1

CREATE TABLE table_2
(
  id1 NUMBER NOT NULL
 ,id2 NUMBER NOT NULL
 ,text VARCHAR2(10)
)
.
l
/
desc table_2

set line 400
BEGIN
  FOR i in 1..15000000 LOOP
    INSERT ALL
      INTO table_1 VALUES(i,i,i)
      INTO table_2 VALUES(i,i,i)
    SELECT null FROM dual
    ;
    IF MOD(i,1000) = 0 
    THEN 
      COMMIT;
    END IF;
  END LOOP;
END;
.
l
/

CREATE UNIQUE INDEX pk_table_1 ON table_1(id1, id2)
.
l
/
CREATE UNIQUE INDEX pk_table_2 ON table_2(id1, id2)
.
l
/

disconnect

connect scott/[パスワード]@orclpdb1
ALTER SESSION SET tracefile_identifier='10046_table_1_slow';
ALTER SESSION SET timed_statistics = true;
ALTER SESSION SET statistics_level=all;
ALTER SESSION SET max_dump_file_size = unlimited;
ALTER SESSION SET events '10046 trace name context forever,level 12';
ALTER TABLE table_1 ADD CONSTRAINT pk_table_1 PRIMARY KEY (id1, id2) USING INDEX pk_table_1
.
l
/
ALTER SESSION SET events '10046 trace name context off';
disconnect

connect scott/[パスワード]@orclpdb1
ALTER SESSION SET tracefile_identifier='10046_table_2_fast';
ALTER SESSION SET timed_statistics = true;
ALTER SESSION SET statistics_level=all;
ALTER SESSION SET max_dump_file_size = unlimited;
ALTER SESSION SET events '10046 trace name context forever,level 12';
ALTER TABLE table_2 ADD CONSTRAINT pk_table_2 PRIMARY KEY (id1, id2) USING INDEX pk_table_2
.
l
/
ALTER SESSION SET events '10046 trace name context off';
disconnect

connect scott/[パスワード]@orclpdb1
DROP TABLE table_1 PURGE;
DROP TABLE table_2 PURGE;

酷暑じゃなければ、台風起因の大雨の東京より。
みなさん、安全最優先で！

ではまた。

投稿日時 2024年8月30日 (金) 12時00分 Oracle, チューニング, FAQ, SQL, パフォーマンス, INDEX | 固定リンク | 0 | コメント (0)

2024年8月21日 (水)

実行計画は, SQL文のレントゲン写真だ！ No.64 / 先生、私のLEFT OUTER JOINが無いんです！！（Join Elimination番外編）

色々な患者さんが来るわけですが、年に一度ぐらい、私のJOINが無いんです！　みたいなこともあります。

ということで、似たアトモスフィアを感じる

患者「先生、私のLEFT OUTER JOINが無いんです！！」
というところから、今回の物語は始まりますw

私「どれどれ」（触診というか問診というかw）　SQL文を診る。。
私「あ！w これは！！！！w 」

私「大丈夫ですよ！、りっぱな、 INNER JOIN です。栄養状態も良さそうですねwwww」
　「念の為、レントゲン（実行計画）も撮っておきましょう」

患者 (キョトン！)

私「ほら〜〜」

（以下、Oracle Databaseです）

SCOTT@orclpdb1> select banner_full from v$version;

BANNER_FULL
----------------------------------------------------------------------
Oracle Database 21c Enterprise Edition Release 21.0.0.0.0 - Production
Version 21.3.0.0.0

SCOTT@orclpdb1> @where_did_my_left_outer_join_go.sql
  1  SELECT
  2    e.empno
  3  FROM
  4    emp e
  5    LEFT OUTER JOIN dept d
  6    ON
  7      e.deptno = d.deptno
  8  WHERE
  9*   d.dname = 'ACCOUNTING'

     EMPNO
----------
      7782
      7839

解析されました。

PLAN_TABLE_OUTPUT
------------------------------------------------------------------------------------------------------
Plan hash value: 2904284165

------------------------------------------------------------------------------------------------------
| Id  | Operation                             | Name         | Rows  | Bytes | Cost (%CPU)| Time     |
------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                      |              |     4 |    80 |     3   (0)| 00:00:01 |
|   1 |  NESTED LOOPS                         |              |     4 |    80 |     3   (0)| 00:00:01 |
|   2 |   NESTED LOOPS                        |              |     4 |    80 |     3   (0)| 00:00:01 |
|   3 |    TABLE ACCESS BY INDEX ROWID BATCHED| DEPT         |     1 |    13 |     2   (0)| 00:00:01 |
|*  4 |     INDEX RANGE SCAN                  | IX_DEPT_NAME |     1 |       |     1   (0)| 00:00:01 |
|*  5 |    INDEX RANGE SCAN                   | IX_DEPT      |     4 |       |     0   (0)| 00:00:01 |
|   6 |   TABLE ACCESS BY INDEX ROWID         | EMP          |     4 |    28 |     1   (0)| 00:00:01 |
------------------------------------------------------------------------------------------------------

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

   4 - access("D"."DNAME"='ACCOUNTING')
   5 - access("E"."DEPTNO"="D"."DEPTNO")

19行が選択されました。

って、コントはこれぐらいにして、本題。

最近、なんだか、なんでもかんでも LEFT OUTER JOINで書いちゃう病気多くないですかね。。:(

可読性も悪いし、本人は INNER JOINしてる意識があるのやら、ないのやら。 オプティマイザはしっかり反応して内部で書き換えてくれちゃってるので、 LEFT OUTER JOIN　なんて書かれてても、無駄だからそれ！　ということでINNER JOINにしてくれています。
Nested Loopが利用される場合、本当に、OUTER JOINなのであれば、外部表（駆動表）になる表は構文上から簡単に特定できますが、INNER JOINだとHASH JOIN同様に結合順を見極める作業も必要になるので要注意です。
(なお、Hash Joinでは外部表と内部表はオプティマイザヒントで入れ替え可能ですが、MySQLのHash Joinでは現状入れ替えることはできないので注意が必要です / 帰ってきた！標準はあるにはあるが癖の多いSQL #8、Hash Joinさせるにも癖が出る)

治療の難易度を上げてしまうだけで良いこともないので、OUTER/INNER は適切に使い分けてほしいものですよね。

単純な症例を一つ。MySQL/PostgreSQLでも同じ。

環境の準備 Oracle Databaseのemp/dept表を元に、制約は主キー制約、索引は以下のようになっています。（記載は略しますが、MySQL/PostgreSQLともに同様の表と索引を用意してあります）

SCOTT@orclpdb1> break on table_name on index_name skip page
SCOTT@orclpdb1> r
  1  select table_name,index_name,column_name
  2  from user_ind_columns
  3  where table_name in ('EMP','DEPT')
  4* order by table_name,index_name,column_position

TABLE_NAME                     INDEX_NAME                     COLUMN_NAME
------------------------------ ------------------------------ ------------------------------
DEPT                           IX_DEPT_NAME                   DNAME

TABLE_NAME                     INDEX_NAME                     COLUMN_NAME
------------------------------ ------------------------------ ------------------------------
DEPT                           PK_DEPT                        DEPTNO

TABLE_NAME                     INDEX_NAME                     COLUMN_NAME
------------------------------ ------------------------------ ------------------------------
EMP                            IX_DEPT                        DEPTNO

TABLE_NAME                     INDEX_NAME                     COLUMN_NAME
------------------------------ ------------------------------ ------------------------------
EMP                            PK_EMP                         EMPNO

SCOTT@orclpdb1> 
SCOTT@orclpdb1> select * from emp order by empno;

     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
      7521 WARD                           SALESMAN                          7698 81-02-22       1250        500         30
      7566 JONES                          MANAGER                           7839 81-04-02       2975                    20
      7654 MARTIN                         SALESMAN                          7698 81-09-28       1250       1400         30
      7698 BLAKE                          MANAGER                           7839 81-05-01       2850                    30
      7782 CLARK                          MANAGER                           7839 81-06-09       2450                    10
      7839 KING                           PRESIDENT                              81-11-17       5000                    10
      7844 TURNER                         SALESMAN                          7698 81-09-08       1500          0         30
      7900 JAMES                          CLERK                             7698 81-12-03        950                    30
      7902 FORD                           ANALYST                           7566 81-12-03       3000                    20
      7934 MILLER                         CLERK                             7782 82-01-23       1300

12行が選択されました。

SCOTT@orclpdb1> select * from dept order by deptno;

    DEPTNO DNAME                                      LOC
---------- ------------------------------------------ ---------------------------------------
        10 ACCOUNTING                                 NEW YORK
        20 RESEARCH                                   DALLAS
        30 SALES                                      CHICAGO
        40 OPERATIONS                                 BOSTON

SCOTT@orclpdb1> r
  1  select table_name,constraint_name,constraint_type
  2  from user_constraints
  3  where table_name in ('EMP','DEPT')
  4* order by table_name,constraint_type

TABLE_NAME                     CONSTRAINT_NAME                CON
------------------------------ ------------------------------ ---
DEPT                           PK_DEPT                        P
EMP                            PK_EMP                         P

PostgreSQL データ量が少ない影響だと思いますが、HASH JOINになってますね。とはいえ、LEFT OUTER JOINではなく、Oracle Database同様に、INNER JOINに書き換えられています。
当然ですよね。INNER JOINなんですもの。
pg_hint_planのヒントを使ってNLJにした実行計画でも確認しておきました:)

perftestdb=> select version();
                                                 version                                                 
---------------------------------------------------------------------------------------------------------
 PostgreSQL 16.3 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 8.5.0 20210514 (Red Hat 8.5.0-22), 64-bit
(1 行)

perftestdb=> \! cat where_did_my_left_outer_join_go.sql
SELECT
  e.empno
FROM
  emp e
  LEFT OUTER JOIN dept d
  ON
    e.deptno = d.deptno
WHERE
  d.dname = 'ACCOUNTING'
;

explain 
SELECT
  e.empno
FROM
  emp e
  LEFT OUTER JOIN dept d
  ON
    e.deptno = d.deptno
WHERE
  d.dname = 'ACCOUNTING'
;

SELECT
  /*+
    Leading(d e)
    NestLoop(d e)
    IndexScan(d ix_dname)
    IndexScan(e ix_deptno)
  */
  e.empno
FROM
  emp e
  LEFT OUTER JOIN dept d
  ON
    e.deptno = d.deptno
WHERE
  d.dname = 'ACCOUNTING'
;

explain 
SELECT
  /*+
    Leading(d e)
    NestLoop(d e)
    IndexScan(d ix_dname)
    IndexScan(e ix_deptno)
  */
  e.empno
FROM
  emp e
  LEFT OUTER JOIN dept d
  ON
    e.deptno = d.deptno
WHERE
  d.dname = 'ACCOUNTING'
;
perftestdb=> \i where_did_my_left_outer_join_go.sql
 empno 
-------
  7782
  7839
(2 行)

                            QUERY PLAN                            
------------------------------------------------------------------
 Hash Join  (cost=1.06..2.27 rows=3 width=5)
   Hash Cond: (e.deptno = d.deptno)
   ->  Seq Scan on emp e  (cost=0.00..1.14 rows=14 width=10)
   ->  Hash  (cost=1.05..1.05 rows=1 width=5)
         ->  Seq Scan on dept d  (cost=0.00..1.05 rows=1 width=5)
               Filter: ((dname)::text = 'ACCOUNTING'::text)
(6 行)

 empno 
-------
  7782
  7839
(2 行)

                                  QUERY PLAN                                  
------------------------------------------------------------------------------
 Nested Loop  (cost=0.27..16.39 rows=3 width=5)
   ->  Index Scan using ix_dname on dept d  (cost=0.13..8.15 rows=1 width=5)
         Index Cond: ((dname)::text = 'ACCOUNTING'::text)
   ->  Index Scan using ix_deptno on emp e  (cost=0.14..8.21 rows=4 width=10)
         Index Cond: (deptno = d.deptno)
(5 行)

perftestdb=>

MySQL MySQLもInner Joinに書き換えてますよね。だって、どこからどうみても、INNER JOINですもの。

mysql> select version();
+-----------+
| version() |
+-----------+
| 8.0.36    |
+-----------+
1 row in set (0.00 sec)

mysql> 
mysql> \! cat where_did_my_left_outer_join_go.sql
SELECT
  e.empno
FROM
  emp e
  LEFT OUTER JOIN dept d
  ON
    e.deptno = d.deptno
WHERE
  d.dname = 'ACCOUNTING'
;

explain format=tree
SELECT
  e.empno
FROM
  emp e
  LEFT OUTER JOIN dept d
  ON
    e.deptno = d.deptno
WHERE
  d.dname = 'ACCOUNTING'
;
mysql> \. where_did_my_left_outer_join_go.sql
+-------+
| empno |
+-------+
|  7782 |
|  7839 |
+-------+
2 rows in set (0.08 sec)

+-------------------------------------------------------------------------------------------+
| EXPLAIN                                                                                   |
+-------------------------------------------------------------------------------------------+
| -> Nested loop inner join  (cost=0.95 rows=3.5)
    -> Filter: (d.deptno is not null)  (cost=0.35 rows=1)
        -> Covering index lookup on d using ix_dname (dname='ACCOUNTING')  (cost=0.35 rows=1)
    -> Covering index lookup on e using emp_deptno (deptno=d.deptno)  (cost=0.6 rows=3.5)
 |
+-------------------------------------------------------------------------------------------+
1 row in set (0.07 sec)

では、また。

いつまで、この酷暑が続くのやら。。。。

投稿日時 2024年8月21日 (水) 12時00分 Oracle, チューニング, FAQ, SQL, MySQL, PostgreSQL, パフォーマンス | 固定リンク | 0 | コメント (0)

2024年7月24日 (水)

実行計画は, SQL文のレントゲン写真だ！ No.63 / Join Elimination （再び）その3

Previously on Mac De Oracle
実行計画は, SQL文のレントゲン写真だ！ No.63 / Join Elimination （再び）その2では、限定的なようですが、PostgreSQL 16では Join Elimination が行われることを確認しました。（全く行わないとわけではないようですね。PostgreSQL。）

今日は、Join Elimination (再び) の最後に、もう一つだけ、めちゃめちゃシンプルな Join Elimination の挙動を追ってみることにします。

前回り作成した、foo/barの2表を少々作り変えて foo2 / bar2 の2表を作成します。
Oracle Database同様の表をMySQL/PostgreSQLにも作成して検証。（今回もデータの有無は影響しないので、データは未登録です）
(なおデータ型は、MySQL/PostgreSQLに合わせて変更しています。e.g. NUMBER->INTEGER, VARCHAR2 -> VARCHAR。データは未登録では統計情報は PostgreSQL/MySQLでも取得します)

COTT@orclpdb1> l
  1  CREATE TABLE foo2 (
  2    id NUMBER
  3   , note VARCHAR2(100)
  4   , PRIMARY KEY (id)
  5* )
SCOTT@orclpdb1> /

表が作成されました。

SCOTT@orclpdb1> l
  1  CREATE TABLE bar2 (
  2    id NUMBER
  3   , sq NUMBER NOT NULL
  4   , memo VARCHAR2(100)
  5   , PRIMARY KEY (id, sq)
  6* )
SCOTT@orclpdb1> /

表が作成されました。

SCOTT@orclpdb1> @gather_tab_stats foo2

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

SCOTT@orclpdb1> @gather_tab_stats bar2

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

上記表を作成後、以下のSQL文を実行します。これもOracle Databaseでは Join Elimination される構文にしています。2つ目の例に類似していますが、 foo2.id = bar2.id は、 1 : 0..* の関係にあります。
したがって　foo2.id = bar2.id という結合条件では Join Elimination できませんが、代わりにインラインビュー内で小細工しています。:)
bar2 WHERE 1=0 として、インライビューの結果は、常に0行となり、そもそも結合不要なので結合自体を除外してしまえ！　というシンプルな Join Elimination の確認です。
この手の文、トリッキーでわかりにくいので個人的には好みではありませんが、ERPなどでは結構、見るような気がしますw

SELECT
  foo2.id
 , foo2.note
FROM
  foo2
  LEFT OUTER JOIN
  (
     SELECT * FROM bar2 WHERE 1=0
  ) bar2
  ON
    foo2.id = bar2.id;

Oracle Database (21c) Oracle Databaseの場合、無駄な結合を除外しているのことを確認できますよね。
この挙動を知っているからこそ、動的SQLの代替としてこのような記述をする傾向があることも理解はしていますが、元の文は読みにくくなるし、ヒント文も埋め込みにくいので、素直に動的SQLにしてくれたらいいのに。。と思ったことがなんとかありますw （Oracle DatabaseのオプティマイザーはSQL文を書き換えて最適化することも多く、この手の構文とヒントによるチューニングは相性的に悪いことが多く、チューニング難易度があがることもあり、個人的には嫌いだ！！　というのもあるのですけどもw）

SCOTT@orclpdb1> l
  1  EXPLAIN PLAN FOR
  2  SELECT
  3    foo2.id
  4   , foo2.note
  5  FROM
  6    foo2
  7    LEFT OUTER JOIN
  8    (
  9       SELECT * FROM bar2 WHERE 1=0
 10    ) bar2
 11    ON
 12*     foo2.id = bar2.id
SCOTT@orclpdb1> /

解析されました。

経過: 00:00:00.01
SCOTT@orclpdb1> @?/rdbms/admin/utlxpls

PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------
Plan hash value: 2844017661

--------------------------------------------------------------------------
| Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |      |     1 |    65 |     3   (0)| 00:00:01 |
|   1 |  TABLE ACCESS FULL| FOO2 |     1 |    65 |     3   (0)| 00:00:01 |
--------------------------------------------------------------------------

8行が選択されました。

PostgreSQL (16.3) ちょっと微妙な感じですが、 Join elimination ではないですね。Nested Loop Left Joinが残ってますし。
とはいえ、 bar2にはアクセスしていないことは確認できるので似たような挙動にはなるのかも。。。
興味深いですね。。。

perftestdb=> EXPLAIN verbose
perftestdb-> SELECT
perftestdb->   foo2.id
perftestdb->  , foo2.note
perftestdb-> FROM
perftestdb->   foo2
perftestdb->   LEFT OUTER JOIN
perftestdb->   (
perftestdb(>      SELECT * FROM bar2 WHERE 1=0
perftestdb(>   ) bar2
perftestdb->   ON
perftestdb->     foo2.id = bar2.id;
                            QUERY PLAN 
-------------------------------------------------------------------
 Nested Loop Left Join  (cost=0.00..0.01 rows=1 width=222)
   Output: foo2.id, foo2.note
   Join Filter: (false AND (foo2.id = id))
   ->  Seq Scan on public.foo2  (cost=0.00..0.00 rows=1 width=222)
         Output: foo2.id, foo2.note
   ->  Result  (cost=0.00..0.00 rows=0 width=4)
         Output: id
         One-Time Filter: false
(8 行)

MySQL (8.0.36) MySQLもPostgreSQLと類似しています。Left Hash Joinは残っているので、Join eliminationではないと考えて良いと思います。

mysql> EXPLAIN format=tree
    -> SELECT
    ->   foo2.id
    ->  , foo2.note
    -> FROM
    ->   foo2
    ->   LEFT OUTER JOIN
    ->   (
    ->      SELECT * FROM bar2 WHERE 1=0
    ->   ) bar2
    ->   ON
    ->     foo2.id = bar2.id;
+-----------------------------------------------------------------------------------+
| EXPLAIN                                                                           |
+-----------------------------------------------------------------------------------+
| -> Left hash join (no condition)  (cost=0.25 rows=0)
    -> Table scan on foo2  (cost=0.35 rows=1)
    -> Hash
        -> Zero rows (Impossible filter)  (cost=0..0 rows=0)
 |
+-----------------------------------------------------------------------------------+
1 row in set (0.01 sec)

今回のレントゲン。いや、実行計画の比較。たまたま閃いたので試してみたのですが想像の斜め上をいく面白さでした。

まとめると、

Oracle Database
Join eliminationによる結合の最適化を行う

PostgreSQL (16以前では未確認)

特定のケースでは、Join elimination できるようだ。（全く行っていないわけではない）

MySQL

現時点8.0までは、Join eliminationは実装されていないようだ。

では、また。

Enjoy SQL! and Execution Plan!

実行計画は, SQL文のレントゲン写真だ！ No.63 / Join Elimination （再び）その1で検証に利用した表の作成ログです。
Oracle Databaseのscottユーザで作成したcustomers/orders表をcsv形式でエクスポート後、Oracle Databaseのcustomers/ordersと同じ表をPostgreSQL/MySQLそれぞれで作成、最後にcsvファイルからデータをロードしています。
試してみたい方は参考にしてみてください。

ーーーcustomers/orders表作成ログーーー

Oracle Database サンプルスキーマ OE で scottユーザへ　customers/orders表へのSELECT権限を付与後、scottユーザ側で、customers/orders表をCTAS。その後、csv形式で、それぞれのデータをexportしています。

oeユーザで。

OE@orclpdb1> grant select on customers to scott;

権限付与が成功しました。

OE@orclpdb1> grant select on orders to scott;

権限付与が成功しました。

以降、scottユーザで。

SCOTT@orclpdb1> l
  1  CREATE TABLE customers AS
  2   SELECT
  3     cust.customer_id
  4     , cust.cust_first_name AS first_name
  5     , cust.cust_last_name AS last_name
  6     , cust.address
  7     , cust.phone# AS phone_number
  8   FROM
  9   (
 10     SELECT
 11       c.customer_id
 12       , c.cust_first_name
 13       , c.cust_last_name
 14       , c.cust_address.street_address AS address
 15       , cr.COLUMN_VALUE AS phone#
 16       , ROW_NUMBER()
 17           OVER (
 18             PARTITION BY c.customer_id
 19             ORDER BY c.customer_id
 20       ) AS phone_count
 21     FROM
 22       oe.customers c
 23       , TABLE(c.phone_numbers) cr
 24     ORDER BY
 25       c.customer_id
 26       , phone_count
 27   ) cust
 28   WHERE
 29*    cust.phone_count = 1
SCOTT@orclpdb1> /

表が作成されました。

SCOTT@orclpdb1> alter table customers add constraint pk_customers primary key (customer_id) using index;

表が変更されました。

SCOTT@orclpdb1> create table orders as select * from oe.orders;

表が作成されました。

SCOTT@orclpdb1> desc orders                                  
 名前                                    NULL?    型
 ----------------------------------------- -------- ----------------------------
 ORDER_ID                                           NUMBER(12)
 ORDER_DATE                                NOT NULL TIMESTAMP(6) WITH LOCAL TIME ZONE
 ORDER_MODE                                         VARCHAR2(8)
 CUSTOMER_ID                               NOT NULL NUMBER(6)
 ORDER_STATUS                                       NUMBER(2)
 ORDER_TOTAL                                        NUMBER(8,2)
 SALES_REP_ID                                       NUMBER(6)
 PROMOTION_ID                                       NUMBER(6)

SCOTT@orclpdb1> alter table orders add constraint pk_orders primary key (order_id) using index;

表が変更されました。

SCOTT@orclpdb1> alter table orders add constraint fk_orders_customers foreign key (customer_id) references customers;

表が変更されました。

SCOTT@orclpdb1> desc customers
 名前                                    NULL?    型
 ----------------------------------------- -------- ----------------------------
 CUSTOMER_ID                                        NUMBER(6)
 FIRST_NAME                                NOT NULL VARCHAR2(20)
 LAST_NAME                                 NOT NULL VARCHAR2(20)
 ADDRESS                                            VARCHAR2(40)
 PHONE_NUMBER                                       VARCHAR2(25)

SCOTT@orclpdb1> create index fk_orders_customers on orders(customer_id);

索引が作成されました。

SCOTT@orclpdb1> l
  1  select
  2    table_name
  3    , index_name
  4    , column_name
  5  from
  6    user_ind_columns
  7  where
  8    table_name in ('CUSTOMERS', 'ORDERS')
  9  order by
 10    table_name
 11    , index_name
 12*   , column_position
SCOTT@orclpdb1> /

TABLE_NAME                     INDEX_NAME                     COLUMN_NAME
------------------------------ ------------------------------ ------------------------------
CUSTOMERS                      PK_CUSTOMERS                   CUSTOMER_ID
ORDERS                         FK_ORDERS_CUSTOMERS            CUSTOMER_ID
ORDERS                         PK_ORDERS                      ORDER_ID

SCOTT@orclpdb1> r
  1  select
  2    table_name
  3    , constraint_name
  4    , constraint_type
  5    , r_owner
  6    , r_constraint_name
  7  from
  8    user_constraints
  9  where
 10    table_name in ('CUSTOMERS','ORDERS')
 11*   and constraint_type in ('P','R')

TABLE_NAME                     CONSTRAINT_NAME      CON R_OWNER              R_CONSTRAINT_NAME
------------------------------ -------------------- --- -------------------- --------------------
ORDERS                         FK_ORDERS_CUSTOMERS  R   SCOTT                PK_CUSTOMERS
CUSTOMERS                      PK_CUSTOMERS         P
ORDERS                         PK_ORDERS            P

SCOTT@orclpdb1> select count(1) from customers;

  COUNT(1)
----------
       319

SCOTT@orclpdb1> select count(1) from orders;

  COUNT(1)
----------
       105

SCOTT@orclpdb1> 
SCOTT@orclpdb1> !cat gather_tab_stats.sql
set verify on
exec dbms_stats.gather_table_stats(ownname=>'SCOTT',tabname=>upper('&1'),cascade=>true,no_invalidate=>false);
set verify off
undefine 1

SCOTT@orclpdb1> @gather_tab_stats.sql orders

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

SCOTT@orclpdb1> @gather_tab_stats.sql customers

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

SCOTT@orclpdb1> 
SCOTT@orclpdb1> !cat makecsv.sql
-- 
-- parameter 1 : table name
-- 
set feed off
set timi off
set head off
set termout off
set veri off
set markup csv on
spool loaddata_&1..csv
select * from &1; 
spo off
set markup csv off
set termout on
set head on
set feed on
set veri on
undefine 1

SCOTT@orclpdb1> @makecsv customers
SCOTT@orclpdb1> @makecsv orders
SCOTT@orclpdb1> !ls -l loaddata*.csv
-rw-r--r--. 1 oracle oinstall 19021  7月 13 19:42 loaddata_customers.csv
-rw-r--r--. 1 oracle oinstall  6064  7月 13 19:42 loaddata_orders.csv

PostgreSQL (16.3) customers/orders表を作成（主キー制約や、参照整合性制約含む）、外部キー列に索引を作成したあと、copyコマンドでcsvファイルからデータをロードして統計情報取得という内容です。

perftestdb=> 
perftestdb=> CREATE TABLE customers
perftestdb-> (
perftestdb(>   customer_id INTEGER NOT NULL
perftestdb(>   , first_name VARCHAR(20) NOT NULL
perftestdb(>   , last_name VARCHAR(20) NOT NULL
perftestdb(>   , address VARCHAR(40)
perftestdb(>   , phone_number VARCHAR(25)
perftestdb(>   , CONSTRAINT pk_customers PRIMARY KEY (customer_id)
perftestdb(> );
CREATE TABLE
perftestdb=> CREATE TABLE orders
perftestdb-> (
perftestdb(>   order_id INTEGER NOT NULL
perftestdb(>   , order_date TIMESTAMP WITH TIME ZONE NOT NULL
perftestdb(>   , order_mode VARCHAR(8)
perftestdb(>   , customer_id INTEGER NOT NULL
perftestdb(>   , order_status SMALLINT
perftestdb(>   , order_total NUMERIC(8,2)vperftestdb(>   , sales_rep_id INTEGER
perftestdb(>   , promotion_id  INTEGER
perftestdb(>   , CONSTRAINT pk_orders PRIMARY KEY (order_id)
perftestdb(>   , CONSTRAINT fk_orders_customers foreign key (customer_id) references customers
perftestdb(> );
CREATE TABLE
perftestdb=> 
perftestdb=> CREATE INDEX fk_orders_customers ON orders(customer_id);
CREATE INDEX
perftestdb=> 
perftestdb=> \copy customers(customer_id,first_name,last_name,address,phone_number) from 'loaddata_customers.csv' csv
COPY 319
perftestdb=> \copy orders(order_id,order_date,order_mode,customer_id,order_status,order_total,sales_rep_id,promotion_id) from 'loaddata_orders.csv' csv
COPY 105
perftestdb=> vacuum analyze customers;
VACUUM
perftestdb=> vacuum analyze orders;
VACUUM
perftestdb=> 
 count 
-------
   319
(1 行)

perftestdb=> select count(1) from orders;
 count 
-------
   105
(1 行)

MySQL (8.0.36) customers/orders表を作成（主キー制約や、参照整合性制約含む）、外部キー列に索引を作成後、loadコマンドでcsvファイルからデータをロードして、統計情報取得という流れになっています
(loadコマンドでワーニングでてたりしますが、今回のテストでは影響ないので気にしないでください。。(^^;;;

mysql> CREATE TABLE customers
    -> (
    ->   customer_id INTEGER NOT NULL
    ->   , first_name VARCHAR(20) NOT NULL
    ->   , last_name VARCHAR(20) NOT NULL
    ->   , address VARCHAR(40)
    ->   , phone_number VARCHAR(25)
    ->   , CONSTRAINT pk_customers PRIMARY KEY (customer_id)
    -> );
Query OK, 0 rows affected (0.18 sec)

mysql> CREATE TABLE orders
    -> (
    ->   order_id INTEGER NOT NULL
    ->   , order_date TIMESTAMP NOT NULL
    ->   , order_mode VARCHAR(8)
    ->   , customer_id INTEGER NOT NULL
    ->   , order_status SMALLINT
    ->   , order_total NUMERIC(8,2)
    ->   , sales_rep_id INTEGER
    ->   , promotion_id  INTEGER
    ->   , CONSTRAINT pk_orders PRIMARY KEY (order_id)
    ->   , CONSTRAINT fk_orders_customers foreign key (customer_id) references customers (customer_id) 
    -> );
Query OK, 0 rows affected (0.07 sec)
mysql> CREATE INDEX fk_orders_customers ON orders(customer_id);
Query OK, 0 rows affected (0.09 sec)
Records: 0  Duplicates: 0  Warnings: 0

[master@localhost ~]$ mysql -u root -D perftestdb -p --local-infile=1
Enter password: 

....中略....

mysql> 
mysql> \! ls -l load*
-rw-rw-r--. 1 master master 19021  7月 14 19:26 loaddata_customers.csv
-rw-rw-r--. 1 master master  6064  7月 14 19:27 loaddata_orders.csv

mysql> load data local infile "./loaddata_customers.csv" into table perftestdb.customers fields terminated by ',' optionally enclosed by '"';
Query OK, 319 rows affected (0.10 sec)
Records: 319  Deleted: 0  Skipped: 0  Warnings: 0

mysql> load data local infile "./loaddata_orders.csv" into table perftestdb.orders fields terminated by ',' optionally enclosed by '"';
Query OK, 105 rows affected, 140 warnings (0.05 sec)
Records: 105  Deleted: 0  Skipped: 0  Warnings: 140

mysql> analyze table  perftestdb.customers;
+----------------------+---------+----------+----------+
| Table                | Op      | Msg_type | Msg_text |
+----------------------+---------+----------+----------+
| perftestdb.customers | analyze | status   | OK       |
+----------------------+---------+----------+----------+
1 row in set (0.05 sec)

mysql> analyze table  perftestdb.orders;
+-------------------+---------+----------+----------+
| Table             | Op      | Msg_type | Msg_text |
+-------------------+---------+----------+----------+
| perftestdb.orders | analyze | status   | OK       |
+-------------------+---------+----------+----------+
1 row in set (0.02 sec)

mysql> select count(1) from perftestdb.customers;
+----------+
| count(1) |
+----------+
|      319 |
+----------+
1 row in set (0.02 sec)

mysql> select count(1) from perftestdb.orders;
+----------+
| count(1) |
+----------+
|      105 |
+----------+
1 row in set (0.07 sec)

投稿日時 2024年7月24日 (水) 12時00分 Oracle, チューニング, FAQ, SQL, MySQL, PostgreSQL, パフォーマンス | 固定リンク | 0 | コメント (0)

2024年7月23日 (火)

実行計画は, SQL文のレントゲン写真だ！ No.63 / Join Elimination （再び）その2

Previously on Mac De Oracle
実行計画は, SQL文のレントゲン写真だ！ No.63 / Join Elimination （再び）その1では、参照整合性制約を利用した Join Elimination の挙動を確認しました。

PostgreSQL、意外にも（知ってたくせに〜w）行われませんでしたね　MySQLは事前の想定通りでしたが:)

では、次の Join Elimination のテストケースを確認してみましょう。

シンプルな例で試しています。Oracle Database / PostgreSQL / MySQL それぞれに以下の2表を作成しておきます。
どちらの表も id 列が主キーですが、前回のケースのような参照整合性制約はありません。

Oracle Database同様の表をMySQL/PostgreSQLにも作成して検証。（データはあってもなくても結合の除外には影響しないためデータは登録していません）
(なおデータ型は、MySQL/PostgreSQLに合わせて変更しています。e.g. NUMBER->INTEGER, VARCHAR2 -> VARCHAR。　また、MySQL/PostgreSQLそれぞれで統計情報も取得しておきます）

SCOTT@orclpdb1> CREATE TABLE foo (id NUMBER PRIMARY KEY, note VARCHAR2(100));

表が作成されました。

SCOTT@orclpdb1> CREATE TABLE bar (id NUMBER PRIMARY KEY, memo VARCHAR2(100));

表が作成されました。

SCOTT@orclpdb1> !cat gather_tab_stats.sql
set verify on
exec dbms_stats.gather_table_stats(ownname=>'SCOTT',tabname=>upper('&1'),cascade=>true,no_invalidate=>false);
set verify off
undefine 1

SCOTT@orclpdb1> @gather_tab_stats foo

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

SCOTT@orclpdb1> @gather_tab_stats bar

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

前述の表を使い、以下のSQL文を実行します！
このSQL文では、bar表を外部結合していますが、SELECTリストでは bar表を参照していません。
また、foo.id = bar.id は 1 : 0..1 であるため、bar表の対象行の結合されるかどうかは問合せ結果に影響しないようにしてあります。つまり、bar表は結合しなくてもよい問合せにしてあります。。。
（さあ、どうなるでしょうね。楽しくなってきました）

SELECT
  foo.id
  , foo.note
FROM
  foo
  LEFT OUTER JOIN bar
  ON
    foo.id = bar.id;

Oracle Database (21c)
すばらしい。無駄な結合を見つけ、Join Elimination していることを確認できます。（分かってましたけどw）

SCOTT@orclpdb1> l
  1  EXPLAIN PLAN FOR
  2  SELECT
  3    foo.id
  4    , foo.note
  5  FROM
  6    foo
  7    LEFT OUTER JOIN bar
  8    ON
  9*     foo.id = bar.id
 SCOTT@orclpdb1> /

解析されました。

経過: 00:00:00.01
SCOTT@orclpdb1> @?/rdbms/admin/utlxpls 

PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------
Plan hash value: 1245013993

--------------------------------------------------------------------------
| Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |      |     1 |    65 |     3   (0)| 00:00:01 |
|   1 |  TABLE ACCESS FULL| FOO  |     1 |    65 |     3   (0)| 00:00:01 |
--------------------------------------------------------------------------

8行が選択されました。

PostgreSQL (16.3)
おおおおおおおーーーーーーーっ。このケースでは、PostgreSQLも Join Elimination しています！！！！！
bar表が結合されていません！　これまた新しい気づき。メモメモw

PostgreSQLのプランナー。 Join Elimination を全く実装していないのかと思いましたが、限定的なようですが、 Join Elimination が実装されているように見えますよね。
興味深い。発展途上というところか。。（次回のPostgreSQL アンカンファレンスで聞いてみようかな）

perftestdb=> EXPLAIN verbose
perftestdb-> SELECT
perftestdb->   foo.id
perftestdb->   , foo.note
perftestdb-> FROM
perftestdb->   foo
perftestdb->   LEFT OUTER JOIN bar
perftestdb->   ON
perftestdb->     foo.id = bar.id;

                         QUERY PLAN                         
------------------------------------------------------------
 Seq Scan on public.foo  (cost=0.00..0.00 rows=1 width=222)
   Output: foo.id, foo.note
(2 行)

MySQL (8.0.36)
んーーーーっ。MySQLのオプティマイザーは、Join Elimination は考慮していないように見えますよ。軽量なオプティマイザーが売りだからだろうか。。

mysql> EXPLAIN format=tree
    -> SELECT
    ->   foo.id
    ->   , foo.note
    -> FROM
    ->   foo
    ->   LEFT OUTER JOIN bar
    ->   ON
    ->     foo.id = bar.id;
+-----------------------------------------------------------------------------------------------+
| EXPLAIN                                                                                       |
+-----------------------------------------------------------------------------------------------+
| -> Nested loop left join  (cost=0.7 rows=1)
    -> Table scan on foo  (cost=0.35 rows=1)
    -> Single-row covering index lookup on bar using PRIMARY (id=foo.id)  (cost=0.35 rows=1)
 |
+-----------------------------------------------------------------------------------------------+
1 row in set (0.03 sec)

海外のブログでは、実装されてない！　と言い切られているのもありましたが、PostgreSQL 16 では限定的ですが行われるようですね。（PostgreSQL 16より前のリリースってどうなんだろう。。13のままにしてたほうがおもしろかったかな。。。むむむ

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

投稿日時 2024年7月23日 (火) 12時00分 Oracle, チューニング, FAQ, SQL, MySQL, PostgreSQL, パフォーマンス | 固定リンク | 0 | コメント (0)

2024年7月22日 (月)

実行計画は, SQL文のレントゲン写真だ！ No.63 / Join Elimination （再び）その1

Previously on Mac De Oracle
前回はコレクション型をアクセスした場合の実行計画がどうなるのかを確認しました。

今回は少し嗜好を変えて。。

先日、Oracle Databaseの Join Elimination が行われている実行計画を、ぼーっと眺めていたのですが、、そういえば、PostgreSQL / MySQL ってどうなんだっけ？　と。気になりまして。はい。
ちょいとぐぐると、海外のブログ等では、Join Elimination - Advanced SQL tuningなど含め、PostgreSQL / MySQL 共に実装されてない。ということが書かれているのが多かったのですが、とにかく自分の目で確かめてみるか。。。ということに。。

Oracle Databaseの実行計画の話ではないですが、本「実行計画は, SQL文のレントゲン写真だ！」シリーズの番外編的な位置付けで、今回含め3回に分けた現時点の動きを確認してみます。

まずは、Oracle Databaseでの Join elimination の復習 - 無駄に結合してないですよね？

・Join Elimination（結合の排除）と参照整合性制約　/ FAQ
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 18 / No.53 / Join Elimination
・join elimination（結合の排除）のバリエーション / FAQ

Oracle Databaseの主要な Join Elimination 思い出しましたか？　復讐できましたよね！？　
ということで、PostgreSQL / MySQL 含め確認していきますよ〜っ！

今回は以下のバージョンのOracle Database/PostgreSQL/MySQLを利用。（PostgreSQL、やっと16にした! w

SCOTT@orclpdb1> select banner_full from v$version;

BANNER_FULL
----------------------------------------------------------------------
Oracle Database 21c Enterprise Edition Release 21.0.0.0.0 - Production
Version 21.3.0.0.0

perftestdb=> select version();
                                                 version                                                 
---------------------------------------------------------------------------------------------------------
 PostgreSQL 16.3 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 8.5.0 20210514 (Red Hat 8.5.0-22), 64-bit
(1 行)

mysql>
+-----------+
| version() |
+-----------+
| 8.0.36    |
+-----------+
1 row in set (0.00 sec)

この検証では、 Oracle Database のサンプルスキーマの一つである OE スキーマから、cusotomersの一部の列、および orders表を元に scottスキーマへ複製し、参照整合性制約を追加（ orders表のcustomer_idからcustomers表の主キーを参照 )します。データはあってもなくても構わないのですが、customers/orders表に関しては別ネタで検証する際に利用することも兼ねてデータもロードしています。
（表や参照整合性など利用したオブジェクト、ロード等含めたログは、最後 ( 後日公開予定 / 実行計画は, SQL文のレントゲン写真だ！ No.63 / Join Elimination （再び）その3 ) に記載しています）

さっそく、結果から見ていきましよう（面白いですよー、そうなの！！！　いう感じではありました。Oraclerからするとw

まずは、参照整合性制約で保証されていることで、結合不要と判断される Join Elimination から。 ( db tech showcase Tokyo 2013 - A35 特濃JPOUG：潮溜まりでジャブジャブ、SQLチューニングの「参照整合性制約アレルギー」でも紹介していたので、この挙動については知っているかたは多いと思います。参照整合性制約を使ってないとお目にかかることはないタイプの Join Elimination ではあるのですけどもw )

Oracle Database / PostgreSQL / MySQL それぞれに以下のような表と主キー制約、および、参照整合性制約 (orders.customer_id -> customers.customer_id)を作成します。

Oracle Databaseでの定義内容 (なおデータ型は、MySQL/PostgreSQLに合わせて変更しています。e.g. NUMBER(n)->INTEGER or SMALLINT, VARCHAR2-> VARCHAR, TIMESTAMP WITH LOCAL TIME ZONE -> TIMESTAMP WITH TIME ZONE, TIMESTAMP)

SCOTT@orclpdb1> desc customers
 名前                                    NULL?    型
 ----------------------------------------- -------- ----------------------------
 CUSTOMER_ID                                        NUMBER(6)
 FIRST_NAME                                NOT NULL VARCHAR2(20)
 LAST_NAME                                 NOT NULL VARCHAR2(20)
 ADDRESS                                            VARCHAR2(40)
 PHONE_NUMBER                                       VARCHAR2(25)

SCOTT@orclpdb1> desc orders                                  
 名前                                    NULL?    型
 ----------------------------------------- -------- ----------------------------
 ORDER_ID                                           NUMBER(12)
 ORDER_DATE                                NOT NULL TIMESTAMP(6) WITH LOCAL TIME
                                                     ZONE
 ORDER_MODE                                         VARCHAR2(8)
 CUSTOMER_ID                               NOT NULL NUMBER(6)
 ORDER_STATUS                                       NUMBER(2)
 ORDER_TOTAL                                        NUMBER(8,2)
 SALES_REP_ID                                       NUMBER(6)
 PROMOTION_ID                                       NUMBER(6)

TABLE_NAME                     INDEX_NAME                     COLUMN_NAME
------------------------------ ------------------------------ ------------------------------
CUSTOMERS                      PK_CUSTOMERS                   CUSTOMER_ID
ORDERS                         FK_ORDERS_CUSTOMERS            CUSTOMER_ID
ORDERS                         PK_ORDERS                      ORDER_ID

TABLE_NAME                     CONSTRAINT_NAME      CON R_OWNER              R_CONSTRAINT_NAME
------------------------------ -------------------- --- -------------------- --------------------
ORDERS                         FK_ORDERS_CUSTOMERS  R   SCOTT                PK_CUSTOMERS
CUSTOMERS                      PK_CUSTOMERS         P
ORDERS                         PK_ORDERS            P

このケースで実行するSQL文はそれぞれ共通で以下を使います。

SELECT
  DISTINCT
  order_id
FROM
  orders o 
  INNER JOIN customers c
  ON o.customer_id = c.customer_id
WHERE
  order_id < 2400;

Oracle Database (21c) customers表は結合されず、join elimination されていることがわかります。inner join で保証しようとしている orders 表に存在している order_idだcustomer表に存在している顧客の注文であるということが参照整合性制約で保証されているため、結合は不要と判断されたわけです。
参照整合性制約アレルギーのみなさんには耳の痛い話ではありますが、この制約のメリットの一つは、Join Eliminationだったりします。
話は少し脱線しますが、発症すると一生ものの参照整合性制約アレルギーなのでw うまく付き合っていきたいものですよね。使いたい！と思えなくなってしまうものなので、Pros/Consをよーーーーーく考えて上で判断したい仕組みですよね。

SCOTT@orclpdb1> l
  1  EXPLAIN PLAN FOR
  2  SELECT
  3    DISTINCT
  4    order_id
  5  FROM
  6    orders o
  7    INNER JOIN customers c
  8    ON o.customer_id = c.customer_id
  9  WHERE
 10*   order_id < 2400
SCOTT@orclpdb1> /

解析されました。

経過: 00:00:00.01
SCOTT@orclpdb1> @?/rdbms/admin/utlxpls

PLAN_TABLE_OUTPUT
------------------------------------------------------------------------------
Plan hash value: 2834288864

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

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

   1 - access("ORDER_ID"<2400)

13行が選択されました。

念のため、参照整合性制約が無い場合はどうなるか確認しておきましょう。
Join Elimination されず、customers表が結合されている状況が確認できますよね！！

SCOTT@orclpdb1> alter table orders disable constraint fk_orders_customers;

表が変更されました。

経過: 00:00:00.31
SCOTT@orclpdb1> l
  1  EXPLAIN PLAN FOR
  2  SELECT
  3    DISTINCT
  4    order_id
  5  FROM
  6    orders o
  7    INNER JOIN customers c
  8    ON o.customer_id = c.customer_id
  9  WHERE
 10*   order_id < 2400
SCOTT@orclpdb1> /

解析されました。

経過: 00:00:00.01
SCOTT@orclpdb1> @?/rdbms/admin/utlxpls

PLAN_TABLE_OUTPUT
----------------------------------------------------------------------------------------------
Plan hash value: 572428435

----------------------------------------------------------------------------------------------
| 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          | PK_ORDERS    |    46 |       |     1   (0)| 00:00:01 |
|*  5 |    INDEX UNIQUE SCAN          | PK_CUSTOMERS |     1 |     4 |     0   (0)| 00:00:01 |
----------------------------------------------------------------------------------------------

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

   4 - access("ORDER_ID"<2400)
   5 - access("O"."CUSTOMER_ID"="C"."CUSTOMER_ID")

18行が選択されました。

PostgreSQL (16.3) なんとーーー。PostgreSQLの場合は、Join elimination しないのか。（初めて知った！！！）　脳のシワが一つ増えた！

perftestdb=> explain verbose
perftestdb-> SELECT
perftestdb->   DISTINCT
perftestdb->   order_id
perftestdb-> FROM
perftestdb->   orders o 
perftestdb->   INNER JOIN customers c
perftestdb->   on o.customer_id = c.customer_id
perftestdb-> WHERE
perftestdb->   order_id < 2400;
                                                QUERY PLAN                                                 
-----------------------------------------------------------------------------------------------------------
 HashAggregate  (cost=7.52..7.98 rows=46 width=4)
   Output: o.order_id
   Group Key: o.order_id
   ->  Merge Join  (cost=3.73..7.40 rows=46 width=4)
         Output: o.order_id
         Merge Cond: (c.customer_id = o.customer_id)
         ->  Index Only Scan using pk_customers on public.customers c  (cost=0.15..12.93 rows=319 width=4)
               Output: c.customer_id
         ->  Sort  (cost=3.58..3.70 rows=46 width=8)
               Output: o.order_id, o.customer_id
               Sort Key: o.customer_id
               ->  Seq Scan on public.orders o  (cost=0.00..2.31 rows=46 width=8)
                     Output: o.order_id, o.customer_id
                     Filter: (o.order_id < 2400)
(14 行)

Join Eliminationされていないので参照整合性制約の有無が影響しないのは自明ですが、念の為w 参照整合性制約を削除して実行計画を確認してみます。
(PostgreSQLでは参照整合性制約を無効化／有効化することができないため、dropすることで無効化しています)

一目瞭然、影響していないことがわかります。（そうなのかーーーー。まじで知らなかったこれ）

perftestdb=> alter table orders drop constraint fk_orders_customers;
ALTER TABLE
perftestdb=*> commit;
COMMIT
perftestdb=> explain verbose
perftestdb-> SELECT
perftestdb->   DISTINCT
perftestdb->   order_id
perftestdb-> FROM
perftestdb->   orders o 
perftestdb->   INNER JOIN customers c
perftestdb->   ON o.customer_id = c.customer_id
perftestdb-> WHERE
perftestdb->   order_id < 2400;
                                                QUERY PLAN                                                 
-----------------------------------------------------------------------------------------------------------
 HashAggregate  (cost=7.52..7.98 rows=46 width=4)
   Output: o.order_id
   Group Key: o.order_id
   ->  Merge Join  (cost=3.73..7.40 rows=46 width=4)
         Output: o.order_id
         Merge Cond: (c.customer_id = o.customer_id)
         ->  Index Only Scan using pk_customers on public.customers c  (cost=0.15..12.93 rows=319 width=4)
               Output: c.customer_id
         ->  Sort  (cost=3.58..3.70 rows=46 width=8)
               Output: o.order_id, o.customer_id
               Sort Key: o.customer_id
               ->  Seq Scan on public.orders o  (cost=0.00..2.31 rows=46 width=8)
                     Output: o.order_id, o.customer_id
                     Filter: (o.order_id < 2400)
(14 行)

MySQL (8.0.36) MySQLもPostgreSQL同様に、参照整合性制約があったとしても customers表を結合しており、Join elimination は行われていません。
（海外の記事の通り、MySQL/PostgreSQLでは Join Elimination　による結合の最適化は実装されていないように見えますね。これまでのところは。）

mysql> explain format=tree
    -> SELECT
    ->   DISTINCT
    ->   order_id
    -> FROM
    ->   orders o 
    ->   INNER JOIN customers c
    ->   ON o.customer_id = c.customer_id
    -> WHERE
    ->   order_id < 2400;
+---------------------------------------------------------------------------------------------------------------------+
| EXPLAIN                                                                                                             |
+---------------------------------------------------------------------------------------------------------------------+
| -> Table scan on   (cost=30.2..33.3 rows=46)
    -> Temporary table with deduplication  (cost=30.2..30.2 rows=46)
        -> Nested loop inner join  (cost=25.6 rows=46)
            -> Filter: (o.order_id < 2400)  (cost=9.48 rows=46)
                -> Index range scan on o using PRIMARY over (order_id < 2400)  (cost=9.48 rows=46)
            -> Limit: 1 row(s)  (cost=0.252 rows=1)
                -> Single-row covering index lookup on c using PRIMARY (customer_id=o.customer_id)  (cost=0.252 rows=1)
 |
+---------------------------------------------------------------------------------------------------------------------+
1 row in set (0.01 sec)

MySQLでも同様に、参照整合性制約を無効化します。
（こちらも、有効／無効だけを制御することはできず、参照整合性制約を削除して無効化する必要があります。戻すどきめんどくさいのだけどもw FOREIGN_KEY_CHECKSでチェックしないという方法はあるらしい）

こちらも参照整合性制約の有無は影響していないことは明らかですね。

mysql> alter table orders drop foreign key fk_orders_customers;
Query OK, 0 rows affected (0.03 sec)
Records: 0  Duplicates: 0  Warnings: 0

mysql> explain format=tree
    -> SELECT
    ->   DISTINCT
    ->   order_id
    -> FROM
    ->   orders o 
    ->   INNER JOIN customers c
    ->   ON o.customer_id = c.customer_id
    -> WHERE
    ->   order_id < 2400;
+---------------------------------------------------------------------------------------------------------------------+
| EXPLAIN                                                                                                             |
+---------------------------------------------------------------------------------------------------------------------+
| -> Table scan on   (cost=30.2..33.3 rows=46)
    -> Temporary table with deduplication  (cost=30.2..30.2 rows=46)
        -> Nested loop inner join  (cost=25.6 rows=46)
            -> Filter: (o.order_id < 2400)  (cost=9.48 rows=46)
                -> Index range scan on o using PRIMARY over (order_id < 2400)  (cost=9.48 rows=46)
            -> Limit: 1 row(s)  (cost=0.252 rows=1)
                -> Single-row covering index lookup on c using PRIMARY (customer_id=o.customer_id)  (cost=0.252 rows=1)
 |
+---------------------------------------------------------------------------------------------------------------------+
1 row in set (0.00 sec)

いきなり違いが見えて、楽しいーーーーぞっ。 :)

海側も無茶苦茶暑いのだろうか、海風吹いてそうでもないのだろうか。。と湘南方面を見ながらw

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

投稿日時 2024年7月22日 (月) 12時00分 Oracle, チューニング, FAQ, SQL, MySQL, PostgreSQL, パフォーマンス | 固定リンク | 0 | コメント (0)

2024年7月12日 (金)

実行計画は, SQL文のレントゲン写真だ！ No.62 / ORDBMS機能であるコレクション型の列をアクセスする実行計画ってどうなるの？

前回の実行計画は, SQL文のレントゲン写真だ！は2023/1だったので、Long time no seeな感じではありますが、このシリーズもネタストックが多いのでまだまだ続けていく予定です:)

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

さて、今日のレントゲンからはどのような状況が見えるのでしょうか。。。

一から準備するのは大変なのでサンプルスキーマである、OEの customers表を利用します。
Oracle Database Release 18 / Database Sample Schemas / 4.5 OEサンプル・スキーマの表の説明

オブジェクト型の列が複数ありますね。ニコニコ（よいサンプルだw）
（今回のエントリーでは、CUST_ADDRESS、CUST_ADDRESS列を利用します）

OE@orclpdb1> desc customers
 名前                                    NULL?    型
 ----------------------------------------- -------- ----------------------------
 CUSTOMER_ID                               NOT NULL NUMBER(6)
 CUST_FIRST_NAME                           NOT NULL VARCHAR2(20)
 CUST_LAST_NAME                            NOT NULL VARCHAR2(20)
 CUST_ADDRESS                                       CUST_ADDRESS_TYP
 PHONE_NUMBERS                                      PHONE_LIST_TYP
 NLS_LANGUAGE                                       VARCHAR2(3)
 NLS_TERRITORY                                      VARCHAR2(30)
 CREDIT_LIMIT                                       NUMBER(9,2)
 CUST_EMAIL                                         VARCHAR2(40)
 ACCOUNT_MGR_ID                                     NUMBER(6)
 CUST_GEO_LOCATION                                  MDSYS.SDO_GEOMETRY
 DATE_OF_BIRTH                                      DATE
 MARITAL_STATUS                                     VARCHAR2(20)
 GENDER                                             VARCHAR2(1)
 INCOME_LEVEL                                       VARCHAR2(20)

利用する列に絞ってデータを覗いてみます。
（オブジェクト型を利用している2列を含む５列に絞ってあります）

OE@orclpdb1> r
  1  SELECT
  2    c.customer_id
  3    , c.cust_first_name
  4    , c.cust_last_name
  5    , c.cust_address AS address
  6    , c.phone_numbers AS phones
  7  FROM
  8    customers c
  9  WHERE
 10*   customer_id = 348

CUSTOMER_ID CUST_FIRST_NAME      CUST_LAST_NAME       ADDRESS(STREET_ADDRESS, POSTAL_CODE, CITY, STATE_P PHONES
----------- -------------------- -------------------- -------------------------------------------------- ----------------------------------------------------
        348 Kelly                Lange                CUST_ADDRESS_TYP('Piazza Del Congresso 22', '36121 PHONE_LIST_TYP('+39 49 012 4373', '+39 49 083 4373')
                                                      9', 'San Giminiano', NULL, 'IT')

ひとつめは、CUST_ADDRESS_TYP型、住所情報ですね。複数ある属性から、STREET_ADDRESS　だけをアクセスすることにします

OE@orclpdb1> set linesize 80
OE@orclpdb1> desc CUST_ADDRESS_TYP
 名前                                    NULL?    型
 ----------------------------------------- -------- ----------------------------
 STREET_ADDRESS                                     VARCHAR2(40)
 POSTAL_CODE                                        VARCHAR2(10)
 CITY                                               VARCHAR2(30)
 STATE_PROVINCE                                     VARCHAR2(10)
 COUNTRY_ID                                         CHAR(2)

ふたつめは、PHONE_LIST_TYP型、複数の電話を持つことを前提としたモデルですが、最大で5個までですね。それ以上の人はどうするのでしょう？（という余計なことはここでは気にしないでw
電話番号は２つは不要なので、最初の電話番号だけを利用することします。 1顧客1電話番号（主番号）という問い合わせにすると面白そうですね。すこし難易度を上げたSELECT文のほうが面白いですし:)

OE@orclpdb1> desc PHONE_LIST_TYP
 PHONE_LIST_TYP VARRAY(5) OF VARCHAR2(25)

ところで、
オブジェクト型に出くわすと、Oracle Databaseって色々飲み込んだというか取り込んだORDBMSでもあることを思い出させてくれますw
それと同時に、ああああ〜〜っ。構文どうだっけーーーーと。（サクッと出てこないw
(ちなみに、Oracle Database 8の頃にORDBMSの機能が取り込まれた。と言う、ちょっと曖昧な記憶がありますが、おそらくその頃なので、1997年ぐらいですよねw)

ということで、オブジェクト型にアクセスしつつ、今日の実行計画というレントゲン写真を診ながら動きを確認してみましょう。
CUST_ADDRESS_TYP型の属性は単純なので修飾してあげればよいですよね。

 OE@orclpdb1> r
  1  SELECT
  2    customer_id
  3    , cust_first_name
  4    , cust_last_name
  5    , cust_address.street_address
  6  FROM
  7    customers 
  8  WHERE
  9*   customer_id = 348
  , cust_address.street_address
    *
行5でエラーが発生しました。:
ORA-00904: "CUST_ADDRESS"."STREET_ADDRESS": 無効な識別子です。

あ”〜やっちまった。オブジェクト型を扱うときは、表エイリアスが必要だったはず！

OE@orclpdb1> r
  1  SELECT
  2    c.customer_id
  3    , c.cust_first_name
  4    , c.cust_last_name
  5    , c.cust_address.street_address
  6  FROM
  7    customers c
  8  WHERE
  9*   customer_id = 348

CUSTOMER_ID CUST_FIRST_NAME      CUST_LAST_NAME       CUST_ADDRESS.STREET_ADDRESS
----------- -------------------- -------------------- ------------------------------
        348 Kelly                Lange                Piazza Del Congresso 22

では、cusomters表に含まれる、CUST_ADDRESS_TYP型を含むクエリーの実行計画はどうなるか...

よく見る index unique scan + table access by index rowid、ユニークキーまたは主キーによる1行だけのアクセスですね。ふむふむ。

OE@orclpdb1> r
  1  explain plan for SELECT
  2    c.customer_id
  3    , c.cust_first_name
  4    , c.cust_last_name
  5    , c.cust_address.street_address
  6  FROM
  7    customers c
  8  WHERE
  9*   customer_id = 348

解析されました。

経過: 00:00:00.00
OE@orclpdb1> @?/rdbms/admin/utlxpls

PLAN_TABLE_OUTPUT
---------------------------------------------------------------------------------------------
Plan hash value: 4238351645

--------------------------------------------------------------------------------------------
| Id  | Operation                   | Name         | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT            |              |     1 |    37 |     1   (0)| 00:00:01 |
|   1 |  TABLE ACCESS BY INDEX ROWID| CUSTOMERS    |     1 |    37 |     1   (0)| 00:00:01 |
|*  2 |   INDEX UNIQUE SCAN         | CUSTOMERS_PK |     1 |       |     0   (0)| 00:00:01 |
--------------------------------------------------------------------------------------------

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

   2 - access("CUSTOMER_ID"=348)

次に、customers表に含まれるコレクションオブジェクPHONE_LIST_TYP型をアクセスしてみます。
少しずつオブジェクト型を思い出してきましたw

コレクション型は、表として扱う必要があるので、TABLEファンクションを使う必要がありますよね（思い出してきましたw　パイプラインファンクションと同じ考え方）
PHONE_LIST_TYP型はコレクション型で属性名のないVARCHAR2のVARRAY型です。TABLEファンクションを利用した場合、単一列の仮想表として返されるので、列名には、COLUMN_VALUE疑似列を使います。XML/JSONでも応用できる知識なので覚えておくと便利です。
Oracle Database Release 19 / SQL言語リファレンス / COLUMN_VALUE疑似列
c.cust_address.street_addresとして、CUST_ADDRESS_TYP型のstreet_addres属性まで指定することで通常の列のように扱えます。それほどトリッキーな構文ではないですよね。

コレクション型のアクセス方法は独特なので、いざという時に慌てないよう、日頃からSQLパズルなどで遊んでいると良いかもしれません。
ある程度使えるようになっていないと、道に迷って時間を溶かすことになるので。。。

customers表のPHONE_LIST_TYP型コレクションには複数の電話番号が含まれています（よくありますよね。固定電話番号、携帯とか複数登録させるユーザー登録画面など）
このSELECT文では、PHONE_LIST_TYP型コレクションから最初の電話番号を主電話番号として取り出し(ROW_NUMBERウィンドウ関数を利用している箇所)、1顧客N電話番号ではなく、1顧客1電話番号（主番号のみ）でリストしています。

表エイリアスは必須（前述の通り）になりますが、もう一つ、コレクション型を仮想表にするTABLEファンクションを利用しています。ここがポイント。
結合しているイメージでOK。中に抱えているコレクションを仮想表として取り出し結合していると思えばイメージしやすいはず:)　
（実行計画では、それをそのままおこなっている部分があります。実行計画の赤字部分の操作を、よーく確認しておいてください）

OE@orclpdb1> r
  1   SELECT
  2     cust.customer_id
  3     , cust.phone# AS primary_phone#
  4   FROM
  5   (
  6     SELECT
  7       c.customer_id
  8       , cr.COLUMN_VALUE AS phone#
  9       , ROW_NUMBER()
 10           OVER (
 11             PARTITION BY c.customer_id
 12             ORDER BY c.customer_id
 13       ) AS phone_count
 14     FROM
 15       customers c
 16       , TABLE(c.phone_numbers) cr
 17     ORDER BY
 18       c.customer_id
 19       , phone_count
 20   ) cust
 21   WHERE
 22*    cust.phone_count = 1

CUSTOMER_ID PRIMARY_PHONE#
----------- ---------------------------------------------------------------------------
        101 +1 317 123 4104
        102 +1 317 123 4111

....中略....

        980 +91 80 012 3837
        981 +86 10 012 3839

このコレクション型から配列の属性を取り出すSELECT文の実行計画は以下の通り。コレクション自体は表の列として保持されているのでcustomers表以外へのオブジェクトにはアクセスしませんが、TABLEファンクションで作り出した仮想表から属性を取り出す際の操作として、COLLECTION ITERATOR PICKLER FETCH が行われています。
この　COLLECTION ITERATOR PICKLER FETCH　って以前、実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 9 / No.44 / COLLECTION ITERATOR PICKLER FETCHで紹介したことがあるので覚えている方も多いと思います。テーブルファンクション特有の操作です。

また、ウィンドウ関数で必要となるソートをCUSTOMERS表の主キーをINDEX FULL SCANすることで回避していのも面白い最適化です。
ソートするよりソート済みの主キーを使ってアクセスしたほうが効率的と判断した結果、INDEX FULL SCAN -> WINDOW NOSORT という操作が行われています。
データ量が多くなるケースだとソートを避ける最適化が多く見られるものOracle Databaseのオプティマイザの特徴ですね。わかりやすくて好きです:)　
悪くない実行計画ではないでしょうか。

OE@orclpdb1> r
  1   EXPLAIN PLAN FOR SELECT
  2     cust.customer_id
  3     , cust.phone# AS primary_phone#
  4   FROM
  5   (
  6     SELECT
  7       c.customer_id
  8       , cr.COLUMN_VALUE AS phone#
  9       , ROW_NUMBER()
 10           OVER (
 11             PARTITION BY c.customer_id
 12             ORDER BY c.customer_id
 13       ) AS phone_count
 14     FROM
 15       customers c
 16       , TABLE(c.phone_numbers) cr
 17     ORDER BY
 18       c.customer_id
 19       , phone_count
 20   ) cust
 21   WHERE
 22*    cust.phone_count = 1

解析されました。

経過: 00:00:00.17
OE@orclpdb1> @?/rdbms/admin/utlxpls

PLAN_TABLE_OUTPUT
----------------------------------------------------------------------------------------------------
Plan hash value: 2349769165

-----------------------------------------------------------------------------------------------------
| Id  | Operation                            | Name         | Rows  | Bytes | Cost (%CPU)| Time     |
-----------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                     |              |   319 | 12760 | 22981   (2)| 00:00:01 |
|*  1 |  VIEW                                |              |   319 | 12760 | 22981   (2)| 00:00:01 |
|*  2 |   WINDOW NOSORT                      |              |  2605K|   201M| 22981   (2)| 00:00:01 |
|   3 |    NESTED LOOPS                      |              |  2605K|   201M| 22981   (2)| 00:00:01 |
|   4 |     TABLE ACCESS BY INDEX ROWID      | CUSTOMERS    |   319 | 25201 |    10   (0)| 00:00:01 |
|   5 |      INDEX FULL SCAN                 | CUSTOMERS_PK |   319 |       |     1   (0)| 00:00:01 |
|   6 |     COLLECTION ITERATOR PICKLER FETCH|              |  8168 | 16336 |    72   (2)| 00:00:01 |
-----------------------------------------------------------------------------------------------------

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

   1 - filter("CUST"."PHONE_COUNT"=1)
   2 - filter(ROW_NUMBER() OVER ( PARTITION BY "C"."CUSTOMER_ID" ORDER BY  NULL )<=1)

ということで、実行計画は読めてなんぼ、という感じなので、読む練習は怠らないようにしておきたいものですね。いろいろな機能が追加されてくるので。。。RDBMSっぽくないやつがRDBMSっぽい世界でどのように最適化され、実行されていくのか。。。最近はAI というかVector？もあるし

雨ばかりの東京より。雨が降らなきゃ猛暑だし。

ではまた。

投稿日時 2024年7月12日 (金) 12時00分 Oracle, チューニング, FAQ, SQL, パフォーマンス | 固定リンク | 0 | コメント (0)

2024年7月11日 (木)

帰ってきた！標準はあるにはあるが癖の多いSQL #16 - FROM句のインラインビューのエイリアスにもクセがある（必須だったり、任意だったり）

Previously on Mac De Oracle
前回の癖は、SELECTリストに記述したスカラー副問合せが実行計画上どうみせられるかにも癖がでるというお話でした。

今日は副問合せは副問合せでもインラインビューの話題です。
FROM句でインラインビューを使う場合、表エイリアスを記述しなくてもエラーにはならいってのは、Oraclerを長年やってると不思議なことではないというか、そういうものだと思ってたりします。
とはいえ、可読性含や不思議な結果になったりする不具合などに遭遇するリスクを回避する意味でも表エイリアスを記述するのが手癖になっているかたも多いのではないでしょうか。私もそうですw（コーディング規約にも記載されていることは多いと思いますし）

ということで、今日の癖を見てみることにしますw

Oracle Database (23ai) インラインビューで表エイリアスを記述しなくても文法エラーにはなりません。
Oracle Database / Release 19 / SQL言語リファレンス / SELECT / table_reference::=のダイアグラムにあるように表エイリアスを省略可能です。（前述したように省略しないことの方が多いですけども、可読性向上のためにも）

SCOTT@localhost:1521/freepdb1> @inlineview_alias_name.sql
  1  SELECT
  2    empno
  3   ,ename
  4  FROM
  5  (
  6    SELECT
  7      empno
  8     ,ename
  9     ,mgr
 10    FROM
 11      emp
 12  )
 13  WHERE
 14*   mgr IS NULL

     EMPNO ENAME
---------- ----------
      7839 KING


  1  SELECT
  2    empno
  3   ,ename
  4  FROM
  5  (
  6    SELECT
  7      /*+ NO_MERGE */
  8      empno
  9     ,ename
 10     ,mgr
 11    FROM
 12      emp
 13  )
 14  WHERE
 15*   mgr IS NULL

     EMPNO ENAME
---------- ----------
      7839 KING


  1  SELECT
  2    empno
  3   ,ename
  4  FROM
  5  (
  6    SELECT
  7      empno
  8     ,ename
  9     ,mgr
 10    FROM
 11      emp
 12  ) iv_emp
 13  WHERE
 14*   mgr IS NULL

     EMPNO ENAME
---------- ----------
      7839 KING

MySQL (8.0.36) インラインビューに表エイリアスを記述しないと見事にエラーになります。コーディング規約で書くこと！なんて明記しなくても、書かないとシンタックスエラーなので書き忘れて、あ”〜っということはないわけすw
MySQL 8.0 リファレンスマニュアル / SQL ステートメント / データ操作ステートメント / SELECT ステートメント / 13.2.10.2 JOIN 句 / table_subqueryに、”table_subquery は、FROM 句では導出テーブルまたはサブクエリーとも呼ばれます。セクション13.2.11.8「導出テーブル」を参照してください。このようなサブクエリーには、サブクエリーの結果にテーブル名を指定するエイリアスを含める必要があります。”と記載されています。

mysql> SELECT
    ->   empno
    ->  ,ename
    -> FROM
    -> (
    ->   SELECT 
    ->     empno
    ->    ,ename
    ->    ,mgr
    ->   FROM
    ->     emp
    -> )
    -> WHERE
    ->   mgr IS NULL
    -> ;
ERROR 1248 (42000): Every derived table must have its own alias


mysql> SELECT
    ->   empno
    ->  ,ename
    -> FROM
    -> (
    ->   SELECT
    ->     empno
    ->    ,ename
    ->    ,mgr
    ->   FROM
    ->     emp
    -> ) iv_emp
    -> WHERE
    ->   mgr IS NULL
    -> ;
+-------+-------+
| empno | ename |
+-------+-------+
|  7839 | KING  |
+-------+-------+
1 row in set (0.00 sec)


mysql> SELECT
    ->   /*+ NO_MERGE(iv_emp) */
    ->   empno
    ->  ,ename
    -> FROM
    -> (
    ->   SELECT
    ->     empno
    ->    ,ename
    ->    ,mgr
    ->   FROM
    ->     emp
    -> ) iv_emp
    -> WHERE
    ->   mgr IS NULL
    -> ;
+-------+-------+
| empno | ename |
+-------+-------+
|  7839 | KING  |
+-------+-------+
1 row in set (0.02 sec)

PostgreSQL (13.14) PostgreSQLもMySQLと同じ挙動ですね。
PostgreSQL 13.1文書 / 第7章問い合わせ / 7.2. テーブル式 / 7.2.1. FROM句 / 7.2.1.3. 副問い合わせに、"7.2.1.3. 副問い合わせ派生テーブルを指定する副問い合わせは括弧で囲む必要があります。また、（7.2.1.2にあるように）必ずテーブル別名が割り当てられている必要があります。例を示します。"とあります。

perftestdb=> SELECT
perftestdb->   empno
perftestdb->  ,ename
perftestdb-> FROM
perftestdb-> (
perftestdb(>   SELECT 
perftestdb(>     empno
perftestdb(>    ,ename
perftestdb(>    ,mgr
perftestdb(>   FROM
perftestdb(>     emp
perftestdb(> )
perftestdb-> WHERE
perftestdb->   mgr IS NULL
perftestdb-> ;
ERROR:  subquery in FROM must have an alias
行 5: (
      ^
HINT:  For example, FROM (SELECT ...) [AS] foo.

perftestdb=> SELECT
perftestdb->   empno
perftestdb->  ,ename
perftestdb-> FROM
perftestdb-> (
perftestdb(>   SELECT
perftestdb(>     empno
perftestdb(>    ,ename
perftestdb(>    ,mgr
perftestdb(>   FROM
perftestdb(>     emp
perftestdb(> ) iv_emp
perftestdb-> WHERE
perftestdb->   mgr IS NULL
perftestdb-> ;
 empno | ename 
-------+-------
  7839 | KING
(1 行)

実際、この手の癖に遭遇したOracle Databaseなど表エイリアス不要の世界の方々は、「おまえは、なにをいっているんだぁ〜」という感じで一瞬固まったあとに、あ〜〜〜〜っ！　、なるとは思いますけどw

ところで、最近のdown pour半端ない感じがします。私の子供の頃でも台風以外でみたことのないような集中的な豪雨が頻発しています。用心しても来るものはきてしまうわけですが、正しい情報を入手して早めに避難するなりしましょうね。と。実家近くの川の水位が落ち着いたのをみて安堵する。。。

Enjoy SQL! and 癖。

投稿日時 2024年7月11日 (木) 12時00分 Oracle, FAQ, SQL, MySQL, PostgreSQL | 固定リンク | 0 | コメント (0)

2024年7月10日 (水)

帰ってきた！標準はあるにはあるが癖の多いSQL #15 - 実行計画でスカラー副問合せの見せ方にも癖がでる

さて、今日はまた、癖の話をしたいと思います！
今回のネタには標準があるわけではないですが、SELECTリストに記述するスカラー副問合せの実行計画上の見せ方の癖というか違いw

実は、このネタ、2020年ぐらいに、目黒方面（ご存知の方だけwww）にある某所で定期開催される内部勉強会的なLT大会で使ったネタだったのですが、そのあとゴタゴタしていて、ブログで書き漏らしていたことを、昨日ネタリストを纏めていた時に思い出した次いでに小ネタとして書いておきます。　(その時のKeynoteのタイトルページだけ載せておきますw）

この癖を把握していれば、SELECTリストに記述されたスカラー副問合せチューニングするような案件に遭遇してしまったときでも何かの役に立つかもしれません。
（少なくとも実行計画を見ただけで、これはSELECTリストにスカラー副問合せがある！　ということは一瞬で理解できるようになるはず。。。）

では早速見てみましょう。(Oracle Databaseではお馴染みの表とデータをMySQL/PostgreSQLでも事前に作成してあります)

SCOTT@orclpdb1> select * from dept;

    DEPTNO DNAME                                      LOC
---------- ------------------------------------------ ---------------------------------------
        10 ACCOUNTING                                 NEW YORK
        20 RESEARCH                                   DALLAS
        30 SALES                                      CHICAGO
        40 OPERATIONS                                 BOSTON
        
SCOTT@orclpdb1> select * from emp;

     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
      7521 WARD                           SALESMAN                          7698 81-02-22       1250        500         30
      7566 JONES                          MANAGER                           7839 81-04-02       2975                    20
      7654 MARTIN                         SALESMAN                          7698 81-09-28       1250       1400         30
      7698 BLAKE                          MANAGER                           7839 81-05-01       2850                    30
      7782 CLARK                          MANAGER                           7839 81-06-09       2450                    10
      7839 KING                           PRESIDENT                              81-11-17       5000                    10
      7844 TURNER                         SALESMAN                          7698 81-09-08       1500          0         30
      7900 JAMES                          CLERK                             7698 81-12-03        950                    30
      7902 FORD                           ANALYST                           7566 81-12-03       3000                    20
      7934 MILLER                         CLERK                             7782 82-01-23       1300                    10

実行計画で見えるSELECT中のスカラー副問合せの位置に注目してください。（赤字にしてあります）

Oracle Databaseでは本体のクエリーより上に表示されますが、PostgreSQL/MySQLでは逆で、下に表示されます。

このような見せ方の違いが逆になるのって以前もご紹介したの覚えているでしょうか？
そう、帰ってきた！標準はあるにはあるが癖の多いSQL #7 - Hash Joinの実行計画の見せ方にも癖がでるで紹介した癖ですね。
HASH JOINのBUILD/PROBEは実行計画上、Oracle DatabaseとPostgreSQL/MySQLでは順序が逆に表現されていましたよね！

これに気づけば、あなたも、道にまようこともなく実行計画を追っていけるはず！！ :)

Oracle Database (21c)
（このようにスカラー副問合せ部分が性能上ネックになりそうな場合、Oracle Databaseのオプティマイザは、スカラー副問合せを結合に書き換えて最適化することがあるため、この例ではそれを無効化するNO_UNNESTヒントを利用しています。）

Oracle Database 21c Enterprise Edition Release 21.0.0.0.0 - Production
Version 21.3.0.0.0
に接続されました。
SCOTT@orclpdb1> !cat scalar_subquery_plan.sql
SELECT	
  deptno
  ,dname
  ,(
     SELECT
       /*+ NO_UNNEST */
       MAX(sal)
     FROM
       emp 
     WHERE
       emp.deptno = dept.deptno
  ) AS max_sal
FROM
  dept
ORDER BY 
  deptno
;

SCOTT@orclpdb1> set autot trace exp stat
SCOTT@orclpdb1> @scalar_subquery_plan.sql

経過: 00:00:00.18

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

------------------------------------------------------------------------------------------------
| Id  | Operation                            | Name    | Rows  | Bytes | Cost (%CPU)| Time     |
------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                     |         |     5 |    65 |     9   (0)| 00:00:01 |
|   1 |  SORT AGGREGATE                      |         |     1 |     7 |            |          |
|   2 |   TABLE ACCESS BY INDEX ROWID BATCHED| EMP     |     4 |    28 |     2   (0)| 00:00:01 |
|*  3 |    INDEX RANGE SCAN                  | IX_DEPT |     4 |       |     1   (0)| 00:00:01 |
|   4 |  TABLE ACCESS BY INDEX ROWID         | DEPT    |     5 |    65 |     3   (0)| 00:00:01 |
|   5 |   INDEX FULL SCAN                    | PK_DEPT |     5 |       |     1   (0)| 00:00:01 |
------------------------------------------------------------------------------------------------

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

   3 - access("EMP"."DEPTNO"=:B1)

見ての通り、PostgreSQL/MySQLはスカラー副問合せ部分の実行計画の位置がOracle Databaseのそれとは異なることがわかると思います。:)
PostgreSQL(13.14)

perftestdb=> \! cat scalar_subquery_plan.sql
EXPLAIN ANALYZE
SELECT	
  deptno
  ,dname
  ,(
     SELECT
       MAX(sal)
     FROM
       emp 
     WHERE
       emp.deptno = dept.deptno
  ) AS max_sal
FROM
  dept
ORDER BY 
  deptno
;
perftestdb=> \i scalar_subquery_plan.sql
                                                   QUERY PLAN                                                    
-----------------------------------------------------------------------------------------------------------------
 Sort  (cost=5.87..5.88 rows=4 width=46) (actual time=0.246..0.247 rows=4 loops=1)
   Sort Key: dept.deptno
   Sort Method: quicksort  Memory: 25kB
   ->  Seq Scan on dept  (cost=0.00..5.83 rows=4 width=46) (actual time=0.065..0.095 rows=4 loops=1)
         SubPlan 1
           ->  Aggregate  (cost=1.19..1.20 rows=1 width=32) (actual time=0.016..0.017 rows=1 loops=4)
                 ->  Seq Scan on emp  (cost=0.00..1.18 rows=5 width=5) (actual time=0.003..0.006 rows=4 loops=4)
                       Filter: (deptno = dept.deptno)
                       Rows Removed by Filter: 10
 Planning Time: 1.916 ms
 Execution Time: 0.843 ms
(11 行)

MySQL(8.0.36)

mysql> \! cat scalar_subquery_plan.sql
EXPLAIN FORMAT=tree
SELECT	
  deptno
  ,dname
  ,(
     SELECT
       MAX(sal)
     FROM
       emp 
     WHERE
       emp.deptno = dept.deptno
  ) AS max_sal
FROM
  dept
ORDER BY 
  deptno
;

mysql> \. scalar_subquery_plan.sql
+----------------------------------------------------------------------+
| EXPLAIN                                                              |
+----------------------------------------------------------------------+
| -> Index scan on dept using PRIMARY  (cost=0.65 rows=4)
-> Select #2 (subquery in projection; dependent)
    -> Aggregate: max(emp.sal)  (cost=1.28 rows=1)
        -> Filter: (emp.deptno = dept.deptno)  (cost=1.14 rows=1.4)
            -> Table scan on emp  (cost=1.14 rows=14)
 |
+----------------------------------------------------------------------+
1 row in set, 1 warning (0.05 sec)
mysql> show warnings;
+-------+------+------------------------------------------------------------------------------------+
| Level | Code | Message                                                                            |
+-------+------+------------------------------------------------------------------------------------+
| Note  | 1276 | Field or reference 'perftestdb.dept.deptno' of SELECT #2 was resolved in SELECT #1 |
+-------+------+------------------------------------------------------------------------------------+
1 row in set (0.01 sec)

ただし、Oracle DatabaseだけはSELECTリストのスカラー副問合せをUNNESTして結合に書き換える最適化を行うこともあるので、実行計画だけだと元のSQL文に記述されているSELECTリスト中のスカラー副問合せに気付けないこともあります.
とはいえ、一般的には、そこに至るまでの間に、SQL文は抜き出せているでしょうから困ることはないでしょうね。（現場がリモートで、実行計画だけ送られてきた！なんてことでもなければw）

SELECTリスト中に記載したスカラー副問合せがUNNESTされてMERGE JOINに書き換えられた例（UNNESTヒント利用）
2013年、Oracle Database 12cR1で実装された最適化機能で、Scalar Subquery Unnesting Transformation (Oracle Database 12c R1 New Feature)でも説明していますので、詳しく知りたい方は参考にしてみてください。

SCOTT@orclpdb1> !cat scalar_subquery_unnest.sql
SELECT
  deptno
  ,dname
  ,(
     SELECT
       /*+ UNNEST */
       MAX(sal)
     FROM
       emp
     WHERE
       emp.deptno = dept.deptno
  ) AS max_sal
FROM
  dept
ORDER BY
  deptno
;

SCOTT@orclpdb1> @scalar_subquery_unnest.sql

経過: 00:00:00.17

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

-----------------------------------------------------------------------------------------
| Id  | Operation                    | Name     | Rows  | Bytes | Cost (%CPU)| Time     |
-----------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT             |          |     5 |   145 |    11  (19)| 00:00:01 |
|   1 |  MERGE JOIN OUTER            |          |     5 |   145 |    11  (19)| 00:00:01 |
|   2 |   TABLE ACCESS BY INDEX ROWID| DEPT     |     5 |    65 |     3   (0)| 00:00:01 |
|   3 |    INDEX FULL SCAN           | PK_DEPT  |     5 |       |     1   (0)| 00:00:01 |
|*  4 |   SORT JOIN                  |          |     4 |    64 |     8  (25)| 00:00:01 |
|   5 |    VIEW                      | VW_SSQ_1 |     4 |    64 |     7  (15)| 00:00:01 |
|   6 |     HASH GROUP BY            |          |     4 |    28 |     7  (15)| 00:00:01 |
|   7 |      TABLE ACCESS FULL       | EMP      |    14 |    98 |     6   (0)| 00:00:01 |
-----------------------------------------------------------------------------------------

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

   4 - access("ITEM_1"(+)="DEPT"."DEPTNO")
       filter("ITEM_1"(+)="DEPT"."DEPTNO")

Enjoy SQL! and 癖

ではまた。

投稿日時 2024年7月10日 (水) 17時00分 Oracle, チューニング, FAQ, SQL, MySQL, PostgreSQL, Oracle Database 12c release 1, パフォーマンス, Oracle Database 12c Release 2, Oracle Database 18c, Oracle Database 19c, Oracle Database 21c, Oracle Database 23c Free Developer Release | 固定リンク | 0 | コメント (0)

2024年7月 1日 (月)

帰ってきた！標準はあるにはあるが癖の多いSQL #14 - コメントを書く位置にも癖がでる (SQL Clientにも癖がある)

Previously on Mac De Oracle
前回は、帰ってきた！標準はあるにはあるが癖の多いSQL #13 - コメント書くにも癖があるでした。
今回は、続編w とは言ってもMySQLが主役ではありませんし、DBMSのエンジンの癖でもなく、SQL Clentの癖のお話です。

前回利用したSQL文（SQLスクリプト化してありますが、スクリプト化せずコピペしても同じ）に以下のような位置に一行コメントを書いてみました。
MySQLの制限も考慮して、(--)の後には半角スペースを忘れずに！

MySQL (8.0.26) ふむふむ、という感じですよね。

[master@localhost ~]$ mysql -u scott -D perftestdb -p 
Enter password: 

....略...

mysql> \! cat one_more_thing.sql
SELECT 
  empno
 ,ename
FROM
  emp
WHERE
  mgr IS NULL; -- It means president of the company.
mysql> 
mysql> 
mysql> \. one_more_thing.sql
+-------+-------+
| empno | ename |
+-------+-------+
|  7839 | KING  |
+-------+-------+
1 row in set (0.01 sec)

mysql>

PostgreSQL (13.14) PostgreSQLもふむふむという感じ。

psql -d perftestdb -U discus -p 5432 -W -h localhost
パスワード： 
psql (13.14)
"help"でヘルプを表示します。

....略...

perftestdb=> \! cat one_more_thing.sql
SELECT 
  empno
 ,ename
FROM
  emp
WHERE
  mgr IS NULL; -- It means president of the company.
perftestdb=> 
perftestdb=> 
perftestdb=> \i one_more_thing.sql
 empno | ename 
-------+-------
  7839 | KING
(1 行)

perftestdb=>

Oracle Database (23ai)

さて、お待ちかね、今回の癖の持ち主も実はOracle。といっても、SQL clientのSQL*Plusです。挙動を見てみましょう。
おやおや〜〜〜〜。結果が返らずスクリプトが終了しちゃいました。どういうこと？

[oracle@localhost ~]$ sqlplus -version

SQL*Plus: Release 23.0.0.0.0 - Production
Version 23.4.0.24.05

[oracle@localhost ~]$ sqlplus scott/tiger@localhost:1521/freepdb1

....略...

SCOTT@localhost:1521/freepdb1> !cat one_more_thing.sql
SELECT 
  empno
 ,ename
FROM
  emp
WHERE
  mgr IS NULL; -- It means president of the company.


SCOTT@localhost:1521/freepdb1> @one_more_thing.sql

SQL文はしっかりSQL*Plusのバッファにあるに、どういうことでしょう。 r または / で再実行させると、、

え、え、エラ〜だぁ！　。。。。
いったい、おまえは、何をいっているんだぁ（ジョジョ風）

SCOTT@localhost:1521/freepdb1> l
  1  SELECT
  2    empno
  3   ,ename
  4  FROM
  5    emp
  6  WHERE
  7*   mgr IS NULL; -- It means president of the company.
SCOTT@localhost:1521/freepdb1> /
  mgr IS NULL; -- It means president of the company.
             *
ERROR at line 7:
ORA-03048: SQL reserved word ';' is not syntactically valid following '...FROM
emp
WHERE
mgr IS NULL'
Help: https://docs.oracle.com/error-help/db/ora-03048/

これ、一行コメントの位置がまずいんです。 SQL*PLusの癖せいです。（昔からの癖ですので。。。
(;)セミコロンの後に記述されている一行コメントを該当行の上において、セミコロンより前になるように修正してみましょう！

こんどは正しい結果が返ってきました！ wwww SQL*Plusの癖もわかりにくいですね。癖の存在をしらないと。。。（マニュアルにも記載されているので参考にしてください）

SCOTT@localhost:1521/freepdb1> edit one_more_thing.sql

SCOTT@localhost:1521/freepdb1> !cat one_more_thing.sql
SELECT 
  empno
 ,ename
FROM
  emp
WHERE
  -- It means president of the company.
  mgr IS NULL;

SCOTT@localhost:1521/freepdb1> @one_more_thing.sql

     EMPNO ENAME
---------- ----------
      7839 KING

参考）

Oracle Database / Release 19 / ユーザーズ・ガイドおよびリファレンス / 5 SQL*Plusでのスクリプトの使用 / 文の終了記号(ピリオド、セミコロンまたはスラッシュ)の後に、コメントを挿入しないでください。

では、最後に、Oracle純正のSQL client、実は、最近はもう一つあるんです。 Oraclerならみなさんご存知の、SQLcl です。
こちら、SQL*Plusと異なり、前述した癖がありません。MySQL/PostgreSQL純正のSQL clientと同じ位置に一行コメントを書いても怒られることはありません。なかなか難しいですね。Oracle純正でも挙動が異なるのでご注意くださいね。。。（苦笑いw

この挙動の違い、私もついさっき気づいたんですけどね。wwwww このエントリー書きながらwwwww (本当ですw)

[oracle@localhost ~]$ sql -version

SQLcl: リリース24.1.0.0 Production ビルド: 24.1.0.087.0929

[oracle@localhost ~]$ sql scott/tiger@localhost:1521/freepdb1

....略...

SCOTT@localhost:1521/freepdb1> !cat one_more_thing.sql
SELECT 
  empno
 ,ename
FROM
  emp
WHERE
  mgr IS NULL;  -- It means president of the company.

SCOTT@localhost:1521/freepdb1> 
SCOTT@localhost:1521/freepdb1> @one_more_thing.sql

   EMPNO ENAME    
________ ________ 
    7839 KING

SQL Client特有の癖もあるので本体以外でも癖には注意しましょうね。

Enjoy SQL! and 癖。

ではまた。

投稿日時 2024年7月 1日 (月) 20時25分 Oracle, FAQ, SQL, MySQL, PostgreSQL, SQL Client | 固定リンク | 0 | コメント (0)

帰ってきた！標準はあるにはあるが癖の多いSQL #13 - コメント書くにも癖がある

人間、なくて七癖。とか申しまして、わしゃ癖がない。といぅ人でも、七つぐらいは癖がある。と言ぅんですなぁ。
SQLも同じで、標準に対応しています。と言う割には、びっくりするぐらい癖があります。
（なぜか落語風w）

ということで、本日の癖、SQLにコメントを書くときは、どのタイプがお好きですかね？　みなさん。
複数行コメントと単一行コメント併用していますが、知ってる人しかしらない（そりゃそうだ）w
コメントを書くにも、ちょっとした癖の持ち主もいたりします。

Oracle Database (23ai)

SCOTT@localhost:1521/freepdb1> !cat sqlcomment.sql
SELECT
  /*
    foo
    bar
  */
  empno
 ,ename  --foobar
FROM
  emp
WHERE
  empno = 7900;

SCOTT@localhost:1521/freepdb1> @sqlcomment.sql

     EMPNO ENAME
---------- ----------
      7900 JAMES

PostgreSQL (13.14) Oracle Databaseと同じルールなのでそのまま使えます

perftestdb=> \! cat sqlcomment.sql
SELECT
  /*
    foo
    bar
  */
  empno
 ,ename  --foobar
FROM
  emp
WHERE
  empno = 7900;
perftestdb=> \i sqlcomment.sql
 empno | ename 
-------+-------
  7900 | JAMES
(1 行)

MySQL (8.0.36) MySQLでは一行コメント(--)の後に半角スペースが必須となっているので注意なのね。

mysql> \! cat sqlcomment.sql
SELECT
  /*
    foo
    bar
  */
  empno
 ,ename  --foobar
FROM
  emp
WHERE
  empno = 7900;
mysql> 
mysql> \. sqlcomment.sql
ERROR 1054 (42S22): Unknown column 'foobar' in 'field list'
mysql>

なかなか、いい癖もってますよね。MySQL

MySQLの場合、一行コメントとして、(#)もサポートされていて、こちらは、(#)の半角スペースは必須ではないと！！

mysql> \! cat sqlcomment.sql
SELECT
  /*
    foo
    bar
  */
  empno
 ,ename  #foobar
FROM
  emp
WHERE
  empno = 7900;
mysql> \. sqlcomment.sql
+-------+-------+
| empno | ename |
+-------+-------+
|  7900 | JAMES |
+-------+-------+
1 row in set (0.04 sec)

最後に、MySQLで有効なコメント記述を確認しておこう。(/* */)や(-- )という記述にしておけば、他のRDBMSで使う時にも楽そうではありますよね。(--)のスペースが必須なのは注意するとして。。

mysql> \! cat sqlcomment.sql
SELECT
  /*
    foo
    bar
  */
  empno  -- Do not forget "white space" following "--"
 ,ename  #foobar
FROM
  emp
WHERE
  empno = 7900;
mysql> 
mysql> 
mysql> \. sqlcomment.sql
+-------+-------+
| empno | ename |
+-------+-------+
|  7900 | JAMES |
+-------+-------+
1 row in set (0.01 sec)

おあとがよろしいようで。。。。

一行コメント(--)の後に空白を置くか置かないかってとこまで気を使う必要があるみたいなので、MySQLへ乗り換えたり、MySQLでも実行できるSQL文やスクリプトを用意する場合には注意したい部分ですすねー。ハマりそうなきもするけどw（一行コメントの部分もケアされているSQLコーディング標準がああって厳格に管理されていれば問題ないと思いますけども）

参考）

・Oracle Database / Release 19 / SQL言語リファレンス / コメント
・PostgreSQL 13.1文書 / 第4章 SQLの構文 / 4.1.5. コメント
・MySQL 8.0 リファレンスマニュアル / 言語構造 / コメント

梅雨らしい雨の降る、ちがさき、、いや、東京よりw。
ではまた。

投稿日時 2024年7月 1日 (月) 12時00分 Oracle, FAQ, SQL, MySQL, PostgreSQL | 固定リンク | 0 | コメント (0)

2024年6月29日 (土)

帰ってきた！標準はあるにはあるが癖の多いSQL #12 - 引用符にも癖がでるし、NULLのソート構文にも癖がある！（後編）ー列エイリアスの扱いにも癖がある！

Previously on Mac De Oracle
前回は、帰ってきた！標準はあるにはあるが癖の多いSQL #11 - 引用符にも癖がでるし、NULLのソート構文にも癖がある！（前編）でした、

引用符にも多少の方言が存在すること、NULLのソート方法にも同様に方言が存在することを確認しました。
今回はその後編です。

引用符で囲んだ識別子（列名、表名、列エイリアス、表エイリアス）を英語だと、Quoted Identifier と記載されシノニムはあまり見かけません。（SQL-1992などでは、delimited identifier と記されている程度ですかね）日本語のマニュアル等では翻訳影響だと思いますが、多少揺れていたりします。

Oraclerのみなさんだと、引用識別子　のほうが馴染み深い日本語訳だと思いますが、他のRDBMSの日本語マニュアルでは、引用符付き識別子　と記載されていたりします。とうのは前回にも書いてますが、Oracle Database/PostgreSQL/MySQLの間でも多少表現は違ったりします。

参考）
・Database Oracle / Release 19 / SQL言語リファレンス / データベース・オブジェクト名および修飾子 / データベース・オブジェクトのネーミング規則
・MySQL 8.0 リファレンスマニュアル / 言語構造 / スキーマオブジェクト名
・PostgreSQL 13.1文書 / 第4章 SQLの構文 / 4.1. 字句の構造

という前置きはこれぐらいで。本日のお題。列エイリアスの扱いの癖！

今日のお題は、列エイリアスの扱いの癖　を見てみます（気づかないと意外にハマりますよーーw）

今回も前回同様、お馴染みの、emp表を、Oracle Database 23ai/PostgreSQL 13.14/MySQL 8.0.36　それぞれに作成してあります。（以下はOracle Database）

SCOTT@localhost:1521/freepdb1> desc emp
 Name                                      Null?    Type
 ----------------------------------------- -------- ----------------------------
 EMPNO                                     NOT NULL NUMBER(4)
 ENAME                                              VARCHAR2(10)
 JOB                                                VARCHAR2(9)
 MGR                                                NUMBER(4)
 HIREDATE                                           DATE
 SAL                                                NUMBER(7,2)
 COMM                                               NUMBER(7,2)
 DEPTNO                                             NUMBER(2)

SCOTT@localhost:1521/freepdb1> select * from emp order by empno;

     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
      7521 WARD       SALESMAN        7698 81-02-22       1250        500         30
      7566 JONES      MANAGER         7839 81-04-02       2975                    20
      7654 MARTIN     SALESMAN        7698 81-09-28       1250       1400         30
      7698 BLAKE      MANAGER         7839 81-05-01       2850                    30
      7782 CLARK      MANAGER         7839 81-06-09       2450                    10
      7788 SCOTT      ANALYST         7566 87-04-19       3000                    20
      7839 KING       PRESIDENT            81-11-17       5000                    10
      7844 TURNER     SALESMAN        7698 81-09-08       1500          0         30
      7876 ADAMS      CLERK           7788 87-05-23       1100                    20
      7900 JAMES      CLERK           7698 81-12-03        950                    30
      7902 FORD       ANALYST         7566 81-12-03       3000                    20
      7934 MILLER     CLERK           7782 82-01-23       1300                    10

14 rows selected.

では、前回のおさらいから、MySQLだけ癖が強い結果となりましたが、問い合わせたい結果はどれも正しいですよね！（標準はあるにはあるが、癖の多いSQLらしい。素晴らしい結果ですよねw）

Oracle Database 23ai

SCOTT@localhost:1521/freepdb1> set null [null]
SCOTT@localhost:1521/freepdb1> @quoted_identification.sql
  1  SELECT
  2    mgr AS "Boss's emp no."
  3  , COUNT(empno) AS head_counts
  4  FROM
  5    emp
  6  GROUP BY
  7    "Boss's emp no."
  8  ORDER BY
  9*   "Boss's emp no." NULLS FIRST

Boss's emp no. HEAD_COUNTS
-------------- -----------
[null]                   1
          7566           2
          7698           5
          7782           1
          7788           1
          7839           3
          7902           1

7 rows selected.

PostgreSQL 13.14

perftestdb=> \pset null [null]
Null表示は"[null]"です。
perftestdb=> \! cat quoted_identification.sql
SELECT
  mgr AS "Boss's emp no."
, COUNT(empno) AS head_counts
FROM
  emp
GROUP BY
  "Boss's emp no."
ORDER BY 
  "Boss's emp no." NULLS FIRST
;
perftestdb=> \i quoted_identification.sql
 Boss's emp no. | head_counts 
----------------+-------------
         [null] |           1
           7566 |           2
           7698 |           5
           7782 |           1
           7788 |           1
           7839 |           3
           7902 |           1
(7 行)

MySQL 8.0.36

mysql> \! cat quoted_identification.sql
SELECT
  mgr AS `Boss's emp no.`
, COUNT(empno) AS head_counts
FROM
  emp
GROUP BY
  `Boss's emp no.`
ORDER BY 
  `Boss's emp no.` IS NULL DESC
 ,`Boss's emp no.` ASC
;
mysql> 
mysql> \. quoted_identification.sql
+----------------+-------------+
| Boss's emp no. | head_counts |
+----------------+-------------+
|           NULL |           1 |
|           7566 |           2 |
|           7698 |           5 |
|           7782 |           1 |
|           7788 |           1 |
|           7839 |           3 |
|           7902 |           1 |
+----------------+-------------+
7 rows in set (0.01 sec)

今日は、上記のクエリー列エイリアスにちょっと意地の悪い変更を行なって、その挙動の違いを見てみたいと思います。（おもしろいよ、それぞれの個性が出てて）
オリジナルでは、mgr AS "Boss's emp no."　としていた列エイリアスですが、まずは、 mgr AS empno と、非識別引用子にして、かつ、emp表の列名である　empno と同じ名称にしてあります。。。 AS 列エイリアス　にはなっているので文法的には正しいです。。。よね。ちょっと嫌な予感はしますがw

(MySQLの場合、ORDER BY句の構文が異なります。以下、Oracle Database 23ai/PostgreSQL向け)

Before

SELECT
  mgr AS Boss's emp no."
, COUNT(empno) AS head_counts
FROM
  emp
GROUP BY
  "Boss's emp no."
ORDER BY 
  "Boss's emp no." NULLS FIRST;

After

SELECT
  mgr AS empno
, COUNT(empno) AS head_counts
FROM
  emp
GROUP BY
  empno
ORDER BY 
  empno NULLS FIRST;

では、早速、MySQLから実験してみましょう！

mysql> desc emp;
+----------+--------------+------+-----+---------+-------+
| Field    | Type         | Null | Key | Default | Extra |
+----------+--------------+------+-----+---------+-------+
| empno    | smallint     | NO   | PRI | NULL    |       |
| ename    | varchar(10)  | YES  |     | NULL    |       |
| job      | varchar(10)  | YES  |     | NULL    |       |
| mgr      | smallint     | YES  |     | NULL    |       |
| hiredate | date         | YES  |     | NULL    |       |
| sal      | decimal(7,2) | YES  |     | NULL    |       |
| comm     | decimal(7,2) | YES  |     | NULL    |       |
| deptno   | smallint     | YES  |     | NULL    |       |
+----------+--------------+------+-----+---------+-------+
8 rows in set (0.05 sec)

mysql> \! cat quoted_identification2.sql
SELECT
  mgr AS empno
, COUNT(empno) AS head_counts
FROM
  emp
GROUP BY
  empno
ORDER BY 
  empno IS NULL DESC
 ,empno ASC
;

おおおおおおおおおーーーーーーー。想定外の結果がががががー（いや、予想してましたよw）。

mysql> \. quoted_identification2.sql
+-------+-------------+
| empno | head_counts |
+-------+-------------+
|  NULL |           1 |
|  7566 |           1 |
|  7566 |           1 |
|  7698 |           1 |
|  7698 |           1 |
|  7698 |           1 |
|  7698 |           1 |
|  7698 |           1 |
|  7782 |           1 |
|  7788 |           1 |
|  7839 |           1 |
|  7839 |           1 |
|  7839 |           1 |
|  7902 |           1 |
+-------+-------------+
14 rows in set, 1 warning (0.02 sec)

ワーニングがでてますね。覗いてみると、どうやら、empno が曖昧だけど、実行しておいたから。。。。と。emp表のempnoと　mgr列に対する列エイリアス、どちらか曖昧だけど、とりあえず、emp表のempno列の方でやっといたでーーー。ということみたいですね。まじか。。。 AS 列エイリアス　とSQLで書いてるから列エイリアスとしてみてくれんの？？？（ちょっとわざとらしいセリフを入れてみましたw）

mysql> show warnings;
+---------+------+------------------------------------------------+
| Level   | Code | Message                                        |
+---------+------+------------------------------------------------+
| Warning | 1052 | Column 'empno' in group statement is ambiguous |
+---------+------+------------------------------------------------+
1 row in set (0.00 sec)

そうか、列エイリアスと表の列名が被ってて、曖昧だと。　では、　引用符を使って、これは、列エイリアスだーーーーーーとわかるように書けば良いのでは？？　　
ということで試してみる。

MySQLのデフォルトの引用符(`)バッククォートで囲った結果。。。だめだ。。。。引用識別子にしても、表の列側としてハンドリングされている。。。。。

mysql> \! cat quoted_identification2.sql
SELECT
  mgr AS `empno`
, COUNT(empno) AS head_counts
FROM
  emp
GROUP BY
  `empno`
ORDER BY 
  `empno` IS NULL DESC
 ,`empno` ASC
;
mysql> \. quoted_identification2.sql
+-------+-------------+
| empno | head_counts |
+-------+-------------+
|  NULL |           1 |
|  7566 |           1 |
|  7566 |           1 |
|  7698 |           1 |
|  7698 |           1 |
|  7698 |           1 |
|  7698 |           1 |
|  7698 |           1 |
|  7782 |           1 |
|  7788 |           1 |
|  7839 |           1 |
|  7839 |           1 |
|  7839 |           1 |
|  7902 |           1 |
+-------+-------------+
14 rows in set, 1 warning (0.00 sec)

mysql> show warnings;
+---------+------+------------------------------------------------+
| Level   | Code | Message                                        |
+---------+------+------------------------------------------------+
| Warning | 1052 | Column 'empno' in group statement is ambiguous |
+---------+------+------------------------------------------------+
1 row in set (0.00 sec)

mysql>

気を取り直して、PostgreSQL ではどうなのでしょう？

perftestdb=> \d+ emp
                                          テーブル"public.emp"
    列    |        タイプ         | 照合順序 | Null 値を許容 | デフォルト | ストレージ | 統計目標 | 説明 
----------+-----------------------+----------+---------------+------------+------------+----------+------
 empno    | numeric(4,0)          |          | not null      |            | main       |          | 
 ename    | character varying(10) |          |               |            | extended   |          | 
 job      | character varying(9)  |          |               |            | extended   |          | 
 mgr      | numeric(4,0)          |          |               |            | main       |          | 
 hiredate | date                  |          |               |            | plain      |          | 
 sal      | numeric(7,2)          |          |               |            | main       |          | 
 comm     | numeric(7,2)          |          |               |            | main       |          | 
 deptno   | numeric(2,0)          |          |               |            | main       |          | 
インデックス:
    "pk_emp" PRIMARY KEY, btree (empno)
    "ix_deptno" btree (deptno)
外部キー制約:
    "fk_deptno" FOREIGN KEY (deptno) REFERENCES dept(deptno)
アクセスメソッド: heap

perftestdb=> \! cat quoted_identification.sql
SELECT
  mgr AS empno
, COUNT(empno) AS head_counts
FROM
  emp
GROUP BY
  empno
ORDER BY 
  empno NULLS FIRST
;

ギョギョ！　サカナくんみたいな声がでますね！w MySQLと同じ挙動です！！！！　なーーーーーーーんーーーーーーだってーーーーーーーっ。　MySQLとは異なりワーニングもなく、結果が想定結果を違うんだーー。というところから列エイリアスが列エイリアスと認識されていないことに気づいてあげないとならないですね。。。これだと。　難易度が上がったw
MySQL、意外と親切かも。ワーニングで教えてくれるなんて。。。

perftestdb=> \pset null [null]
Null表示は"[null]"です。
perftestdb=> \i quoted_identification.sql
 empno  | head_counts 
--------+-------------
 [null] |           1
   7566 |           1
   7566 |           1
   7698 |           1
   7698 |           1
   7698 |           1
   7698 |           1
   7698 |           1
   7782 |           1
   7788 |           1
   7839 |           1
   7839 |           1
   7839 |           1
   7902 |           1
(14 行)

では、引用識別子に書き換えてみましょう。。。。。あ、まじで、PostgreSQLもMySQLと同じ挙動ですね。列エイリアスだよーーーーーと明示しても、表の列としてのハンドリングを優先しています。。。むむむ。

perftestdb=> \pset null [null]
Null表示は"[null]"です。
perftestdb=> \! cat quoted_identification2.sql
SELECT
  mgr AS "empno"
, COUNT(empno) AS head_counts
FROM
  emp
GROUP BY
  "empno"
ORDER BY 
  "empno" NULLS FIRST
;
perftestdb=> \i quoted_identification2.sql
 empno  | head_counts 
--------+-------------
 [null] |           1
   7566 |           1
   7566 |           1
   7698 |           1
   7698 |           1
   7698 |           1
   7698 |           1
   7698 |           1
   7782 |           1
   7788 |           1
   7839 |           1
   7839 |           1
   7839 |           1
   7902 |           1
(14 行)

perftestdb=>

では、ここまでくると、わかりますよね。　前回のエントリーで、MySQL　の立ち位置にいるのは、Oracle Database 23ai でーーーす。
なお、23aiからGROUP BYに列エイリアスが書けるようになってます。

結果を見てみましょうw

おおおおおーーーーーー。まじでーーーー。
MySQL/PostgreSQLと異なる挙動。列エイリアス（非引用識別子）と表の列名が被ってる影響で列エイリアスがエイリアスとして認識されていないためエラーとして扱っていますね。興味深い。いや、実はミスに気づきやすいのかも。。。

SCOTT@localhost:1521/freepdb1> set null [null]
SCOTT@localhost:1521/freepdb1> edit quoted_identification.sql

SCOTT@localhost:1521/freepdb1> @quoted_identification.sql
  1  SELECT
  2    mgr AS empno
  3  , COUNT(empno) AS head_counts
  4  FROM
  5    emp
  6  GROUP BY
  7    empno
  8  ORDER BY
  9*   empno NULLS FIRST
  mgr AS empno
  *
ERROR at line 2:
ORA-00979: "MGR": must appear in the GROUP BY clause or be used in an aggregate function
Help: https://docs.oracle.com/error-help/db/ora-00979/

非識別引用子のままだと、表の列名である、empno　と区別できない（AS empno と記載しても）ので、引用識別子にしてみます。PostgreSQL/Oracle Databaseの引用符は(")ダブルクォートですよね。

実行してみると。。。。。。あーーーーら不思議、MySQL/PostgreSQLとは異なり、引用識別子にしてあげることで、emp表のempno列とはことなる、列エイリアスと認識して、正しく処理しています。。。なんと。。。というか、この実装のほうが引用識別子の意味としては理解しやすくないですかね。。どうなんだろう。

SCOTT@localhost:1521/freepdb1> !cp quoted_identification.sql quoted_identification2.sql

SCOTT@localhost:1521/freepdb1> edit quoted_identification2.sql

SCOTT@localhost:1521/freepdb1> @quoted_identification2.sql
  1  SELECT
  2    mgr AS "empno"
  3  , COUNT(empno) AS head_counts
  4  FROM
  5    emp
  6  GROUP BY
  7    "empno"
  8  ORDER BY
  9*   "empno" NULLS FIRST

     empno HEAD_COUNTS
---------- -----------
[null]               1
      7566           2
      7698           5
      7782           1
      7788           1
      7839           3
      7902           1

7 rows selected.

Elapsed: 00:00:00.01
SCOTT@localhost:1521/freepdb1> set linesize 80
SCOTT@localhost:1521/freepdb1> desc emp
 Name                                      Null?    Type
 ----------------------------------------- -------- ----------------------------
 EMPNO                                     NOT NULL NUMBER(4)
 ENAME                                              VARCHAR2(10)
 JOB                                                VARCHAR2(9)
 MGR                                                NUMBER(4)
 HIREDATE                                           DATE
 SAL                                                NUMBER(7,2)
 COMM                                               NUMBER(7,2)
 DEPTNO                                             NUMBER(2)

SCOTT@localhost:1521/freepdb1>

引用識別子/非引用識別子が既存の列名と同じ場合の評価の仕方は皆バラバラですねw。思いっきり実装依存の部分なので、列、表名に対するエイリアスを指定する場合には注意しましょう。
（個人的な感覚でしかないですがw

Oracle Databaseの実装のほうが直感的には理解しやすいきがします）

MySQLの場合、PostgreSQL同様に実行されますが、面白い特徴は、ワーニングという形で、"Warning 1052 | Column 'empno' in group statement is ambiguous" を示してくれることですね。MySQLでは warningのカウントに注意!!!　忘れないようにしたいですね。重要なコメントが書かれてたりしますw

この3者の中で、もっとも問題に気づきにくいのは、PostgreSQLでしょうか。。。
挙動がMySQL側に似ているので、MySQLのようにちょっと曖昧だけど、実行だけしておいたよ！　的なワーニングでも返してくれると、
MySQLのように気づきやすくなるかもしれませんね。＞　各位

これだから、癖のあるSQLとの付き合いはやめられないwww

Enjoy SQL！　そして、癖！　もw

ではまた。

投稿日時 2024年6月29日 (土) 07時19分 Oracle, FAQ, SQL, MySQL, PostgreSQL, Oracle Database 23c Free Developer Release | 固定リンク | 0 | コメント (0)

2024年6月23日 (日)

VirtualBox TestBuild 7.0.97r163606 (2024-06-21T11:55:16Z) for macOS/ARM64における現時点でのOracle Database 21cの起動、停止時間の記録

2024-06-21に最新のTestBuildが公開されていました。

恒例のOracle Database 21c on VirtualBox TestBuild for macOS/ARM64 の起動時間の記録です。

oracle@Mac-Studio ~ % ./print_env.sh
 
*** mac info. ***
ProductName:		macOS
ProductVersion:		14.5
BuildVersion:		23F79
 
*** maxOS ver. ***
      Model Name: Mac Studio
      Chip: Apple M1 Ultra
      Total Number of Cores: 20 (16 performance and 4 efficiency)
      Memory: 64 GB
 
*** VirtualBox ver. ***
7.0.97r163606

M1で停止時間が2桁秒台になったほか、起動時間も改善してますね！

起動1回目 : 130 sec
停止1回目 :  66 sec
起動2回目 : 145 sec
停止2回目 :  45 sec

oracle@angelfish ~ % ./print_env.sh

*** mac info. ***
      Model Name: MacBook Air
      Chip: Apple M2
      Total Number of Cores: 8 (4 performance and 4 efficiency)
      Memory: 24 GB

*** macOS ver. ***
ProductName:		macOS
ProductVersion:		14.5
BuildVersion:		23F79

*** VirtualBox ver. ***
7.0.97r163606

起動停止時間の記録をとり始めてから、M2でも最短記録ですね！！！！　

起動1回目 : 108 sec
停止1回目 :  34 sec
起動2回目 :  91 sec
停止2回目 :  49 sec

今回は、起動停止時間ともこれまでの最速値です。(^^) (^^) (^^)

次回のリリースが楽しみですね。。。

VMのOSバージョンなどは過去のエントリーを見ていただくとして、M1/M2 それぞれ以下のPostgreSQL/MySQL/Oracle Databaseが起動することを確認。

PostgreSQL

[master@localhost ~]$ sudo su - postgres -c 'psql -d perftestdb -U discus -p 5432 -W -h localhost -c "select version()"'

                                                 version                                                  
----------------------------------------------------------------------------------------------------------
 PostgreSQL 13.14 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 8.5.0 20210514 (Red Hat 8.5.0-20), 64-bit
(1 行)

MySQL

[master@localhost ~]$ mysql -u scott -D perftestdb -p -h localhost -e 'select version();'

+-----------+
| version() |
+-----------+
| 8.0.36    |
+-----------+

Oracle Database 21c

[oracle@localhost ~]$ sqlplus / as sysdba @version

...略...

BANNER_FULL
----------------------------------------------------------------------
Oracle Database 21c Enterprise Edition Release 21.0.0.0.0 - Production
Version 21.3.0.0.0

Oracle Database 23ai

[oracle@localhost ~]$ sql hr/oracle@localhost:1521/freepdb1 @version

...略...

BANNER_FULL                                                                                             
________________________________________________________________________________
Oracle Database 23ai Free Release 23.0.0.0.0 - Develop, Learn, and Run for Free
Version 23.4.0.24.05

VirtualBox Team　がんばれ〜〜〜〜〜 :)

では、次回の起動停止時間ログをお楽しみに:)

・
・MySQL 8.0.32 , PostgreSQL 13.4 and Oracle Database 21c on Oracle Linux 8 on VirtualBox for Apple Silicon Test Build 7.0.97_BETA5r160702
・ySQL 8.0.32 , PostgreSQL 13.6 and Oracle Database 21c on Oracle Linux 8.5 on VirtualBox for Apple Silicon Test Build 7.0.97_BETA5r161342
・MySQL 8.0.32 , PostgreSQL 13.6 and Oracle Database 21c on Oracle Linux 8.5 on VirtualBox for Apple Silicon Test Build 7.0.97_BETA5r161709
・MySQL 8.0.36 , PostgreSQL 13.14, Oracle Database 21c, Oracle Database 23ai on VirtualBox for Apple Silicon Test Build 7.0.97_BETA r162957
・VirtualBox TestBuild for macOS/ARM64における現時点でのOracle Database 21cの起動、停止時間の記録 / 7.0.97r162957(2024/4/26) / 7.0.97r163029(2024/5/3)
・VirtualBox TestBuild 7.0.97r163376 (2024-05-28T15:08:56Z) for macOS/ARM64における現時点でのOracle Database 21cの起動、停止時間の記録
・VirtualBox TestBuild 7.0.97r163425 (2024-06-05T13:13:46Z) for macOS/ARM64における現時点でのOracle Database 21cの起動、停止時間の記録

投稿日時 2024年6月23日 (日) 17時29分 Oracle, Mac, SQL, VirtualBox, MySQL, PostgreSQL, Oracle Database 21c, Oracle Database 23c Free Developer Release, Apple Silicon ARM64 | 固定リンク | 0 | コメント (0)

2024年6月22日 (土)

帰ってきた！標準はあるにはあるが癖の多いSQL #11 - 引用符にも癖がでるし、NULLのソート構文にも癖がある！（前編）

Oracle ACE Program的に新年度に切り替わり。今期もOracle ACE Proに認定されました。:)

前置きはそれぐらいにして、今日の本題。

column expressionのaliasや、 table, view, subqueryなどのaliasを指定する際に利用することがある引用符、通常は (")ダブルクォートで囲むわけですが、そんな引用符にも癖があるというお話。
SQL-1992のドラフトではありますが以下のドキュメントを delimited identifier で検索すると見つけることができます。
( (Second Informal Review Draft) ISO/IEC 9075:1992, Database Language SQL- July 30, 1992 )

ついでに、世間ではいろいろ言われて肩身の狭い？想いをしているかもしれない NULL. そのNULLのソートが必要になってしまった場合にも、ソートの構文に癖がある！！

ほんと、みんな、癖多すぎますよね！（w
いい感じに差し支えない単語にすると、個性　があるというか... これだからSQLは楽しいって話もありますけども。人によるかなw

Oracle Database 23ai / PostgreSQL 13.14 / MySQL 8.0.36 のそれぞれで、どうなるか見てみましょう。

それぞれのデータベースに以下のような emp表を事前に作成しておきます。Oraclerにはお馴染みの表です:)

SCOTT@localhost:1521/freepdb1> select * from emp order by empno;

     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
      7521 WARD       SALESMAN        7698 81-02-22       1250        500         30
      7566 JONES      MANAGER         7839 81-04-02       2975                    20
      7654 MARTIN     SALESMAN        7698 81-09-28       1250       1400         30
      7698 BLAKE      MANAGER         7839 81-05-01       2850                    30
      7782 CLARK      MANAGER         7839 81-06-09       2450                    10
      7788 SCOTT      ANALYST         7566 87-04-19       3000                    20
      7839 KING       PRESIDENT            81-11-17       5000                    10
      7844 TURNER     SALESMAN        7698 81-09-08       1500          0         30
      7876 ADAMS      CLERK           7788 87-05-23       1100                    20
      7900 JAMES      CLERK           7698 81-12-03        950                    30
      7902 FORD       ANALYST         7566 81-12-03       3000                    20
      7934 MILLER     CLERK           7782 82-01-23       1300                    10

14 rows selected.

まず、Oracle Database 23ai
なぜ最新にしたかと言うと、GROUP BYで　alias が利用可能になった最初のリリースだからなのですw　（例で利用するクエリで利用する必要があるので）
（ GROUP BY列の別名または位置の指定が可能に！ / 23ai〜 / SQL / FAQ ）

SCOTT@localhost:1521/freepdb1> select banner_full from v$version;

BANNER_FULL
-------------------------------------------------------------------------------
Oracle Database 23ai Free Release 23.0.0.0.0 - Develop, Learn, and Run for Free
Version 23.4.0.24.05

この例では、別名に空白などを含めているため引用符が必要になります。
Oracle Databaseの場合は昔から (") ダブルクォートですね。
一般的には引用符を必要としない記述にすることが多いのではないでしょうか。プログラムで扱うには面倒ですからね。（印字するだけの目的なら別ですが）
とはいえ、引用符の利用が必須のケースや、コーディング規約次第というところはあります。
SQL言語リファレンス/ データベース・オブジェクト名および修飾子/ データベース・オブジェクトのネーミング規則

NULLの位置が最初に来るようにソートするには、NULLS FIRSTですよね。みなさんもご存知のはず。

Oraclerのみなさんには GROUP BY でいきなりaliasを使う構文で目新しいですよね。すっきり書けるようになって嬉しい:)

SCOTT@localhost:1521/freepdb1> set null [null]
SCOTT@localhost:1521/freepdb1> @quoted_identification.sql
  1  SELECT
  2    mgr AS "Boss's emp no."
  3  , COUNT(empno) AS head_counts
  4  FROM
  5    emp
  6  GROUP BY
  7    "Boss's emp no."
  8  ORDER BY
  9*   "Boss's emp no." NULLS FIRST

Boss's emp no. HEAD_COUNTS
-------------- -----------
[null]                   1
          7566           2
          7698           5
          7782           1
          7788           1
          7839           3
          7902           1

7 rows selected.

次は、PostgreSQL　
Oracle Database同様、引用符が必要な別名は、ダブルクォートを利用します。( PostgreSQL 16.0 / 4.1.1. 識別子とキーワード )

NULLS FIRSTでNULLをいい感じにソートする方法も同じですね。

perftestdb=> select version();
                                                 version                                                  
----------------------------------------------------------------------------------------------------------
 PostgreSQL 13.14 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 8.5.0 20210514 (Red Hat 8.5.0-20), 64-bit
(1 行)

perftestdb=> 
perftestdb=> \pset null [null]
Null表示は"[null]"です。
perftestdb=> \! cat quoted_identification.sql
SELECT
  mgr AS "Boss's emp no."
, COUNT(empno) AS head_counts
FROM
  emp
GROUP BY
  "Boss's emp no."
ORDER BY 
  "Boss's emp no." NULLS FIRST;
;
perftestdb=> \i quoted_identification.sql
 Boss's emp no. | head_counts 
----------------+-------------
         [null] |           1
           7566 |           2
           7698 |           5
           7782 |           1
           7788 |           1
           7839 |           3
           7902 |           1
(7 行)

さて、最後は、MySQLです。

気付いたかと思いますが、本日の癖の主役ですw

MySQLのデフォルトの引用符は、なんと、(`) バッククォートです。手癖で、ダブルクォートをタイプして、え！と一瞬固まる、Oraclerが。。＞　俺だよw
( MySQL 8.0 リファレンスマニュアル / 言語構造 / スキーマオブジェクト名 )

また、NULLのソートも可能ですが、見たこともない構文でソートします。私まだよくわかってないですが、これで良いらしい。この癖に慣れる必要もありそう。。

+-----------+
| version() |
+-----------+
| 8.0.36    |
+-----------+
1 row in set (0.00 sec)

mysql> \! cat quoted_identification.sql
SELECT
  mgr AS `Boss's emp no.`
, COUNT(empno) AS head_counts
FROM
  emp
GROUP BY
  `Boss's emp no.`
ORDER BY 
  `Boss's emp no.` IS NULL DESC
 ,`Boss's emp no.` ASC
;
mysql> 
mysql> \. quoted_identification.sql
+----------------+-------------+
| Boss's emp no. | head_counts |
+----------------+-------------+
|           NULL |           1 |
|           7566 |           2 |
|           7698 |           5 |
|           7782 |           1 |
|           7788 |           1 |
|           7839 |           3 |
|           7902 |           1 |
+----------------+-------------+
7 rows in set (0.01 sec)

ところで、MySQLでも、(")ダブルクォートを引用符にすることができます。
( MySQL 8.0 リファレンスマニュアル / 5.1.11 サーバー SQL モード / ANSI_QUOTES 参照のこと )

sql_modeに ANSI_QUOTESを設定することで使えるようになります。。。。あ〜っ、スッキリ。NULLのソート構文以外はw

mysql> select @@sql_mode;
+-----------------------------------------------------------------------------------------------------------------------+
| @@sql_mode                                                                                                            |
+-----------------------------------------------------------------------------------------------------------------------+
| ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION |
+-----------------------------------------------------------------------------------------------------------------------+
1 row in set (0.00 sec)

mysql> set session sql_mode = concat(@@sql_mode,',ANSI_QUOTES');
Query OK, 0 rows affected (0.01 sec)

mysql> select @@sql_mode;
+-----------------------------------------------------------------------------------------------------------------------------------+
| @@sql_mode                                                                                                                        |
+-----------------------------------------------------------------------------------------------------------------------------------+
| ANSI_QUOTES,ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION |
+-----------------------------------------------------------------------------------------------------------------------------------+
1 row in set (0.00 sec)

mysql> \! cat quoted_identification.sql
SELECT
  mgr AS "Boss's emp no."
, COUNT(empno) AS head_counts
FROM
  emp
GROUP BY
  "Boss's emp no."
ORDER BY 
  "Boss's emp no." IS NULL DESC
 ,"Boss's emp no." ASC
;
mysql> \. quoted_identification.sql
+----------------+-------------+
| Boss's emp no. | head_counts |
+----------------+-------------+
|           NULL |           1 |
|           7566 |           2 |
|           7698 |           5 |
|           7782 |           1 |
|           7788 |           1 |
|           7839 |           3 |
|           7902 |           1 |
+----------------+-------------+
7 rows in set (0.00 sec)

mysql>

ANSI_QUOTESを無効にすると、GROUP BY で指定した alias 無効となり、デフォルトで有効化されているONLY_FULL_GROUP_BYのため、ERROR 1055　となります。なんとなく理解した！

mysql> select @@sql_mode;
+-----------------------------------------------------------------------------------------------------------------------------------+
| @@sql_mode                                                                                                                        |
+-----------------------------------------------------------------------------------------------------------------------------------+
| ANSI_QUOTES,ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION |
+-----------------------------------------------------------------------------------------------------------------------------------+
1 row in set (0.01 sec)

mysql> set session sql_mode = replace(@@sql_mode,'ANSI_QUOTES,','');
Query OK, 0 rows affected (0.00 sec)

mysql> select @@sql_mode;
+-----------------------------------------------------------------------------------------------------------------------+
| @@sql_mode                                                                                                            |
+-----------------------------------------------------------------------------------------------------------------------+
| ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION |
+-----------------------------------------------------------------------------------------------------------------------+
1 row in set (0.00 sec)

mysql> \! cat quoted_identification.sql
SELECT
  mgr AS "Boss's emp no."
, COUNT(empno) AS head_counts
FROM
  emp
GROUP BY
  "Boss's emp no."
ORDER BY 
  "Boss's emp no." IS NULL DESC
 ,"Boss's emp no." ASC
;
mysql> \. quoted_identification.sql
ERROR 1055 (42000): Expression #1 of SELECT list is not in GROUP BY clause and contains nonaggregated column 'perftestdb.emp.mgr' which is not functionally dependent on columns in GROUP BY clause; this is incompatible
 with sql_mode=only_full_group_by

そういえば、
英語だと、大抵は、quoted identifier と書かれていますが、日本語表記だと引用符付き識別子とか、引用識別子、各社のドキュメントで微妙に違いがあったりして難しいなぁ。と思ったり。
quoted identifier　ってカタカタにしたら長くてタイプするの面倒、結局、Oraclerなので、引用識別子/非引用識別子　で通りしゃったりしますけど。

ではでは。
次回へつづく。

投稿日時 2024年6月22日 (土) 11時56分 Oracle, FAQ, SQL, MySQL, PostgreSQL, NULL, Oracle Database 23c Free Developer Release | 固定リンク | 0 | コメント (0)

2024年5月29日 (水)

帰ってきた！標準はあるにはあるが癖の多いSQL #10、BOOLEAN型にも癖が出る（後編）の　おまけ　- SQL*PlusのautotraceでSQL Analysis Reportが出力される！ (23ai〜)

ちょっと意地悪してみました。

前回のエントリで、以下のようにindex only scanにできるBOOLEAN型の単列索引を作成したのを覚えていますか？

SCOTT@freepdb1> create index ix_bool_example2 on example2(b1);

Index created.

SCOTT@freepdb1> set autot trace exp stat
SCOTT@freepdb1> select count(1) from example2 where b1;

Execution Plan
----------------------------------------------------------
Plan hash value: 1159143718

--------------------------------------------------------------------------------------
| Id  | Operation         | Name             | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |                  |     1 |     1 |     1   (0)| 00:00:01 |
|   1 |  SORT AGGREGATE   |                  |     1 |     1 |            |          |
|*  2 |   INDEX RANGE SCAN| IX_BOOL_EXAMPLE2 |    16 |    16 |     1   (0)| 00:00:01 |
--------------------------------------------------------------------------------------

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

   2 - access("B1"=TRUE)

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

この状態で、述語のBOOLEAN列（索引列）に暗黙型変換が発生する意地悪をしてみました。
BOOLEAN列を数値として計算した後に、falseと比較しているので、TO_NUMBER() の後に、TO_BOOLEAN()されています。当然、索引は使えなくなるので index only scan から table access fullに変わっています！　（狙い通りですね。こんなことしないと思いますけどもw

で、みなさん、SQL*Plusのautoraceに見慣れない情報が出力されているのに気づきませんか！？

そう、Oracle Database 23ai free developerでは、SQL*PlusのautotraceでSQL Analysis reportが表示され、index range scan　できるよう、述語の書き換えをご検討くさい！　とレコメンドされています！（赤字部分）

このメッセージカスタマイズできたりしたらw 「チッ、少しは考えたSQL書けよな〜。」と上から目線のメッセージに変えてみたいw（無理でしょうけどもw）　

ということで、おまけでした！

SCOTT@freepdb1> select b1 from example2 where (b1 - 1) = false;

18 rows selected.

Execution Plan
----------------------------------------------------------
Plan hash value: 1894430233

------------------------------------------------------------------------------
| Id  | Operation         | Name     | Rows  | Bytes | Cost (%CPU)| Time     |
------------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |          |     1 |     1 |     3   (0)| 00:00:01 |
|*  1 |  TABLE ACCESS FULL| EXAMPLE2 |     1 |     1 |     3   (0)| 00:00:01 |
------------------------------------------------------------------------------

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

   1 - filter(TO_BOOLEAN(TO_NUMBER("B1")-1)=FALSE)

SQL Analysis Report (identified by operation id/Query Block Name/Object Alias):
-------------------------------------------------------------------------------

   1 -  SEL$1 / "EXAMPLE2"@"SEL$1"
           -  The following columns have predicates which preclude their
              use as keys in index range scan. Consider rewriting the
              predicates.
                "B1"

Statistics
----------------------------------------------------------
          9  recursive calls
          6  db block gets
         11  consistent gets
          0  physical reads
       1012  redo size
        914  bytes sent via SQL*Net to client
        133  bytes received via SQL*Net from client
          3  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
         18  rows processed

この例だと的確なレコメンドしてるんだけど、もっとムズイやつだとどうなるんだろうね。誰か本番で使って結果公開して欲しい :)

Enjoy SQL!

投稿日時 2024年5月29日 (水) 19時30分 Oracle, チューニング, FAQ, SQL, パフォーマンス, Oracle Database 23c Free Developer Release | 固定リンク | 1 | コメント (0)

帰ってきた！標準はあるにはあるが癖の多いSQL #10、BOOLEAN型にも癖が出る（後編）

Previously on Mac De Oracle
前回は、BOOLEAN型に使える値の差異について、Oracle Database 23ai/PostgreSQL/MySQLで比較してみました。なかなか癖がありますよね。それぞれw Oracle Database 23aiは、Db2やSnowflakeの仕様に類似していそうでしたよね。（未検証ですが）
ということで、5月もラストスパートwで、BOOLEANネタ後編で締めたいと思いますw

BOOLEAN/BOOL型どちらでもOKということなので、一応確認しておきます。

Oracle Database

SCOTT@freepdb1> create table sample3 (b1 boolean, b2 bool);

Table created.

SCOTT@freepdb1> desc sample3
 Name                                      Null?    Type
 ----------------------------------------- -------- ----------------------------
 B1                                                 BOOLEAN
 B2                                                 BOOLEAN
 
SCOTT@freepdb1> drop table sample3 purge;Table dropped.

PostgreSQL

perftestdb=> create table sample3 (b1 boolean, b2 bool);
CREATE TABLE
perftestdb=> \d sample3
               テーブル"public.sample3"
 列 | タイプ  | 照合順序 | Null 値を許容 | デフォルト 
----+---------+----------+---------------+------------
 b1 | boolean |          |               | 
 b2 | boolean |          |               | 

perftestdb=> drop table sample3;
DROP TABLE
perftestdb=>

MySQL

mysql> create table sample3 (b1 boolean, b2 bool);
Query OK, 0 rows affected (0.27 sec)

mysql> desc sample3;
+-------+------------+------+-----+---------+-------+
| Field | Type       | Null | Key | Default | Extra |
+-------+------------+------+-----+---------+-------+
| b1    | tinyint(1) | YES  |     | NULL    |       |
| b2    | tinyint(1) | YES  |     | NULL    |       |
+-------+------------+------+-----+---------+-------+
2 rows in set (0.04 sec)

mysql> drop table sample3;
Query OK, 0 rows affected (0.10 sec)

次は、データサイズ。
MySQL/PostgreSQLそれぞれマニュアルにて、1バイトと記載されていますが、Oracle Databaseでは発見できす（仕方ないので直接確認してみますw）
PostgreSQL - https://www.postgresql.jp/document/13/html/datatype-boolean.html MySQL BOOLEAN = TINYINT - https://dev.mysql.com/doc/refman/8.0/ja/other-vendor-data-types.html MySQL TINYINTのサイズ - https://dev.mysql.com/doc/refman/8.0/ja/integer-types.html

Oracleも1バイトのようですね！

SCOTT@freepdb1> set null [null]
SCOTT@freepdb1> col dump(b1) for a30
SCOTT@freepdb1> col vsize(b1) for 9990
SCOTT@freepdb1> select dump(b1),vsize(b1) from example2

DUMP(B1)                       VSIZE(B1)
------------------------------ ---------
Typ=252 Len=1: 1                       1
Typ=252 Len=1: 1                       1
Typ=252 Len=1: 1                       1
Typ=252 Len=1: 1                       1

...中略...

Typ=252 Len=1: 0                       1
Typ=252 Len=1: 0                       1
Typ=252 Len=1: 0                       1
Typ=252 Len=1: 0                       1
NULL                           [null]

33 rows selected.

BOOLEAN型を文字、数値へキャストするとどうなるでしょう？

Oracle Database BOOLEAN型の数値へのキャストは、1 (true) / 0 (false)、文字列へのキャストは、'TRUE' / 'FALSE' になるようですね。CHAR型へのキャストの場合、空白埋めされるようですね（マニュアルより）。

SCOTT@freepdb1> select id,b1,to_number(b1),memo from example2 order by id;

        ID B1          TO_NUMBER(B1) MEMO
---------- ----------- ------------- ----------
         1 TRUE                    1 TRUE
         2 TRUE                    1 true
         3 TRUE                    1 True
         4 TRUE                    1 ON
         5 TRUE                    1 on
         6 TRUE                    1 On
         7 TRUE                    1 YES
         8 TRUE                    1 yes
         9 TRUE                    1 Yes
        10 TRUE                    1 T
        11 TRUE                    1 t
        12 TRUE                    1 Y
        13 TRUE                    1 y
        14 TRUE                    1 1
        15 TRUE                    1 0.01
        16 TRUE                    1 -0.01
        17 TRUE                    1 10
        18 TRUE                    1 -12
        19 FALSE                   0 FALSE
        20 FALSE                   0 false
        21 FALSE                   0 False
        22 FALSE                   0 OFF
        23 FALSE                   0 off
        24 FALSE                   0 Off
        25 FALSE                   0 NO
        26 FALSE                   0 no
        27 FALSE                   0 No
        28 FALSE                   0 F
        29 FALSE                   0 f
        30 FALSE                   0 N
        31 FALSE                   0 n
        32 FALSE                   0 0
        33 [null]      [null]        null

33 rows selected.

SCOTT@freepdb1> select id,b1,to_char(b1),memo from example2 order by id;

        ID B1          TO_CHA MEMO
---------- ----------- ------ ----------
         1 TRUE        TRUE   TRUE
         2 TRUE        TRUE   true
         3 TRUE        TRUE   True
         4 TRUE        TRUE   ON
         5 TRUE        TRUE   on
         6 TRUE        TRUE   On
         7 TRUE        TRUE   YES
         8 TRUE        TRUE   yes
         9 TRUE        TRUE   Yes
        10 TRUE        TRUE   T
        11 TRUE        TRUE   t
        12 TRUE        TRUE   Y
        13 TRUE        TRUE   y
        14 TRUE        TRUE   1
        15 TRUE        TRUE   0.01
        16 TRUE        TRUE   -0.01
        17 TRUE        TRUE   10
        18 TRUE        TRUE   -12
        19 FALSE       FALSE  FALSE
        20 FALSE       FALSE  false
        21 FALSE       FALSE  False
        22 FALSE       FALSE  OFF
        23 FALSE       FALSE  off
        24 FALSE       FALSE  Off
        25 FALSE       FALSE  NO
        26 FALSE       FALSE  no
        27 FALSE       FALSE  No
        28 FALSE       FALSE  F
        29 FALSE       FALSE  f
        30 FALSE       FALSE  N
        31 FALSE       FALSE  n
        32 FALSE       FALSE  0
        33 [null]      [null] null

33 rows selected.

PostgreSQL PostgreSQLは想定の範囲内ですね。'true'/'false', 1/0 になるようですね

perftestdb=> \pset null [null]
Null表示は"[null]"です。
perftestdb=> 
perftestdb=> select id,b1,b1::varchar,memo from example2 order by id;
 id |   b1   |   b1   | memo  
----+--------+--------+-------
  1 | t      | true   | TRUE
  2 | t      | true   | true
  3 | t      | true   | True
  4 | t      | true   | ON
  5 | t      | true   | on
  6 | t      | true   | On
  7 | t      | true   | YES
  8 | t      | true   | yes
  9 | t      | true   | Yes
 10 | t      | true   | T
 11 | t      | true   | t
 12 | t      | true   | Y
 13 | t      | true   | y
 14 | t      | true   | 1
 17 | t      | true   | 10
 19 | f      | false  | FALSE
 20 | f      | false  | false
 21 | f      | false  | False
 22 | f      | false  | OFF
 23 | f      | false  | off
 24 | f      | false  | Off
 25 | f      | false  | NO
 26 | f      | false  | no
 27 | f      | false  | No
 28 | f      | false  | F
 29 | f      | false  | f
 30 | f      | false  | N
 31 | f      | false  | n
 32 | f      | false  | 0
 33 | [null] | [null] | null
(30 行)

perftestdb=> select id,b1,b1::integer,memo from example2 order by id;
 id |   b1   |   b1   | memo  
----+--------+--------+-------
  1 | t      |      1 | TRUE
  2 | t      |      1 | true
  3 | t      |      1 | True
  4 | t      |      1 | ON
  5 | t      |      1 | on
  6 | t      |      1 | On
  7 | t      |      1 | YES
  8 | t      |      1 | yes
  9 | t      |      1 | Yes
 10 | t      |      1 | T
 11 | t      |      1 | t
 12 | t      |      1 | Y
 13 | t      |      1 | y
 14 | t      |      1 | 1
 17 | t      |      1 | 10
 19 | f      |      0 | FALSE
 20 | f      |      0 | false
 21 | f      |      0 | False
 22 | f      |      0 | OFF
 23 | f      |      0 | off
 24 | f      |      0 | Off
 25 | f      |      0 | NO
 26 | f      |      0 | no
 27 | f      |      0 | No
 28 | f      |      0 | F
 29 | f      |      0 | f
 30 | f      |      0 | N
 31 | f      |      0 | n
 32 | f      |      0 | 0
 33 | [null] | [null] | null
(30 行)

MySQL TINYINTのまま文字列に変換されちゃいますね。これはこれで癖が強いといえば強い

mysql> select id,b1,cast(b1 as char),memo from example2 order by id;
+----+------+------------------+-------+
| id | b1   | cast(b1 as char) | memo  |
+----+------+------------------+-------+
|  1 |    1 | 1                | TRUE  |
|  2 |    1 | 1                | true  |
|  3 |    1 | 1                | True  |
| 14 |    1 | 1                | 1     |
| 15 |    0 | 0                | 0.01  |
| 16 |    0 | 0                | -0.01 |
| 19 |    0 | 0                | FALSE |
| 20 |    0 | 0                | false |
| 21 |    0 | 0                | False |
| 32 |    0 | 0                | 0     |
| 33 | NULL | NULL             | null  |
+----+------+------------------+-------+

Boolean型は索引にも利用できるので、念の為、Boolean型の検索でリテラルとして使える記述がどう評価されるか確認しておきましょうね。
暗黙のキャストやらなんやらあるのかないのか。。。索引に含めた場合、キャストされて索引として利用できないないケースなど把握しておくと便利ですよー。:)

Oracle Database 23ai Oracleの場合、簡易な方法として、SQL*Plusのオートトレースを利用し、 Predicate Information（述語情報）を見て filterの際に、関数が適用され内部的にキャストされてしまうかどうかで判断していくことにします。
ついでに、boolean列に非ユニーク索引（単一列索引）を作成しておき、索引が利用されることも見ておきます。

全てのケースは実施していませんが、大文字小文字は無視される前提で、小文字で検証しています。
TRUEとして解釈されるリテラル値 (文字列は大文字小文字は無視される。数値は、0以外の数値は全て、TRUEと解釈される。e.g. -1,10,0.1,-1.5 など) TRUE. 'ON', 'YES', 'T', 'Y', 1, 0以外の数値

FALSEとして解釈されるリテラル値 (文字列は大文字小文字は無視される。数値は、0のみFALSEと解釈される) FALSE, 'OFF', 'NO', 'F', 'N', 0

以上が、OracleのBOOELAN型で利用できるリテラル値なので、

true, 'on', 'yes', 't', 'y', 1, 0以外の数値(10, 0.1, -2, -0.1)、全てにおいて、内部的にTRUEとしてハンドリングされていることがわかります。
（キャストされているわけではなく、TRUEとして評価されていることが、predicate information及び、index only scanになっているところでも判断できます）

ますます、　true/false, nullだけ使えばいいじゃんって感じがしますね。

以下、検証ログ

SCOTT@freepdb1> create index ix_bool_example2 on example2(b1);

Index created.

SCOTT@freepdb1> select b1 from example2 where b1 = true;

18 rows selected.

...中略...

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

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

   1 - access("B1"=TRUE)

Statistics
----------------------------------------------------------
          7  recursive calls
          4  db block gets

...中略...

         18  rows processed

SCOTT@freepdb1> select b1 from example2 where b1 = 't';

18 rows selected.

...中略...

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

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

   1 - access("B1"=TRUE)

Statistics
----------------------------------------------------------
          1  recursive calls
...中略...

         18  rows processed

SCOTT@freepdb1> select b1 from example2 where b1 = 'y';

18 rows selected.

...中略...

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

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

   1 - access("B1"=TRUE)

Statistics
----------------------------------------------------------
          1  recursive calls
          0  db block gets

...中略...

         18  rows processed

SCOTT@freepdb1> select b1 from example2 where b1 = 'yes';

18 rows selected.

...中略...

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

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

   1 - access("B1"=TRUE)

Statistics
----------------------------------------------------------
          1  recursive calls
          0  db block gets

...中略...

         18  rows processed

SCOTT@freepdb1> select b1 from example2 where b1 = 'on';

18 rows selected.

...中略...

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

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

   1 - access("B1"=TRUE)

Statistics
----------------------------------------------------------
          1  recursive calls
          0  db block gets

...中略...

         18  rows processed

SCOTT@freepdb1> select b1 from example2 where b1 = 1;

18 rows selected.

...中略...

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

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

   1 - access("B1"=TRUE)

Statistics
----------------------------------------------------------
          1  recursive calls
          0  db block gets

...中略...

         18  rows processed

SCOTT@freepdb1> select b1 from example2 where b1 = 10;

18 rows selected.

...中略...

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

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

   1 - access("B1"=TRUE)

Statistics
----------------------------------------------------------
          1  recursive calls
          0  db block gets

...中略...

         18  rows processed

SCOTT@freepdb1> select b1 from example2 where b1 = 0.1;

18 rows selected.

...中略...

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

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

   1 - access("B1"=TRUE)

Statistics
----------------------------------------------------------
          1  recursive calls
          0  db block gets

...中略...

         18  rows processed

05:53:05 SCOTT@192.168.1.23:1521/freepdb1> select b1 from example2 where b1 = -2;

18 rows selected.

...中略...

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

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

   1 - access("B1"=TRUE)

Statistics
----------------------------------------------------------
          1  recursive calls
          0  db block gets

...中略...

         18  rows processed

SCOTT@freepdb1> select b1 from example2 where b1 = -0.1;

18 rows selected.

...中略...

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

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

  1 - access("B1"=TRUE)

Statistics
----------------------------------------------------------
          1  recursive calls
          0  db block gets

...中略...

         18  rows processed

PostgreSQL

TRUEとして解釈されるリテラル値 (文字列は大文字小文字は無視される。数値は、正の整数のみTRUEと解釈され、負の整数や少数はエラーとなる。　-1, 0.1, -1.5などはエラー) TRUE. 'ON', 'YES', 'T', 'Y', 1, 0以外の正の整数のみ（ただし、booleanへのキャストが必要）

FALSEとして解釈されるリテラル値 (文字列は大文字小文字は無視される。数値は、0のみFALSEと解釈される) FALSE, 'OFF', 'NO', 'F', 'N', 0

true, 'on', 'yes', 't', 'y', 1, 0以外の正の整数のみ（ただし、booleanへのキャスト必須）(10) 全てにおいて、内部的にTRUEとしてハンドリングされていることがわかります。
（キャストされているわけではなく、Index Cond:及び、、hintで矯正していますが、Index Scan uging..になっているところでも判断できます）

0以外の正の整数以外(0.1, -2, -0.1)は、エラーになっていることが確認できます。

perftestdb=> create index ix_bool_example2 on example2(b1);
CREATE INDEX
perftestdb=> explain (analyze,verbose) select /*+ IndexScan(example2 ix_bool_example2) */ b1 from example2 where b1 = true;
                                                             QUERY PLAN                                                             
------------------------------------------------------------------------------------------------------------------------------------
 Index Scan using ix_bool_example2 on public.example2  (cost=0.14..8.40 rows=15 width=1) (actual time=0.093..0.098 rows=15 loops=1)
   Output: b1
   Index Cond: (example2.b1 = true)
 Planning Time: 13.020 ms
 Execution Time: 8.653 ms
(5 行)
perftestdb=> explain (analyze,verbose) select /*+ IndexScan(example2 ix_bool_example2) */ b1 from example2 where b1 = 'on';
                                                             QUERY PLAN                                                             
------------------------------------------------------------------------------------------------------------------------------------
 Index Scan using ix_bool_example2 on public.example2  (cost=0.14..8.40 rows=15 width=1) (actual time=0.038..0.046 rows=15 loops=1)
   Output: b1
   Index Cond: (example2.b1 = true)
 Planning Time: 0.259 ms
 Execution Time: 0.142 ms
(5 行)

perftestdb=> explain (analyze,verbose) select /*+ IndexScan(example2 ix_bool_example2) */ b1 from example2 where b1 = 'yes';
                                                             QUERY PLAN                                                             
------------------------------------------------------------------------------------------------------------------------------------
 Index Scan using ix_bool_example2 on public.example2  (cost=0.14..8.40 rows=15 width=1) (actual time=0.021..0.026 rows=15 loops=1)
   Output: b1
   Index Cond: (example2.b1 = true)
 Planning Time: 0.168 ms
 Execution Time: 0.087 ms
(5 行)

perftestdb=> explain (analyze,verbose) select /*+ IndexScan(example2 ix_bool_example2) */ b1 from example2 where b1 = 't';
                                                             QUERY PLAN                                                             
------------------------------------------------------------------------------------------------------------------------------------
 Index Scan using ix_bool_example2 on public.example2  (cost=0.14..8.40 rows=15 width=1) (actual time=0.022..0.030 rows=15 loops=1)
   Output: b1
   Index Cond: (example2.b1 = true)
 Planning Time: 0.173 ms
 Execution Time: 0.117 ms
(5 行)

perftestdb=> explain (analyze,verbose) select /*+ IndexScan(example2 ix_bool_example2) */ b1 from example2 where b1 = 'y';
                                                             QUERY PLAN                                                             
------------------------------------------------------------------------------------------------------------------------------------
 Index Scan using ix_bool_example2 on public.example2  (cost=0.14..8.40 rows=15 width=1) (actual time=0.017..0.021 rows=15 loops=1)
   Output: b1
   Index Cond: (example2.b1 = true)
 Planning Time: 0.119 ms
 Execution Time: 0.066 ms
(5 行)

perftestdb=> explain (analyze,verbose) select /*+ IndexScan(example2 ix_bool_example2) */ b1 from example2 where b1 = 1;
ERROR:  operator does not exist: boolean = integer
行 1: ...example2 ix_bool_example2) */ b1 from example2 where b1 = 1;
                                                                 ^
HINT:  No operator matches the given name and argument types. You might need to add explicit type casts.
perftestdb=> explain (analyze,verbose) select /*+ IndexScan(example2 ix_bool_example2) */ b1 from example2 where b1 = 1::boolean;
                                                             QUERY PLAN                                                             
------------------------------------------------------------------------------------------------------------------------------------
 Index Scan using ix_bool_example2 on public.example2  (cost=0.14..8.40 rows=15 width=1) (actual time=0.010..0.015 rows=15 loops=1)
   Output: b1
   Index Cond: (example2.b1 = true)
 Planning Time: 0.125 ms
 Execution Time: 0.067 ms
(5 行)
perftestdb=> explain (analyze,verbose) select /*+ IndexScan(example2 ix_bool_example2) */ b1 from example2 where b1 = 0.1::boolean;
ERROR:  cannot cast type numeric to boolean
行 1: ..._bool_example2) */ b1 from example2 where b1 = 0.1::boolean;
                                                           ^
perftestdb=> explain (analyze,verbose) select /*+ IndexScan(example2 ix_bool_example2) */ b1 from example2 where b1 = -2::boolean;
ERROR:  operator does not exist: - boolean
行 1: ... ix_bool_example2) */ b1 from example2 where b1 = -2::boolea...
                                                           ^
HINT:  No operator matches the given name and argument type. You might need to add an explicit type cast.
perftestdb=> explain (analyze,verbose) select /*+ IndexScan(example2 ix_bool_example2) */ b1 from example2 where b1 = -0.1::boolean; 
ERROR:  cannot cast type numeric to boolean
行 1: ...bool_example2) */ b1 from example2 where b1 = -0.1::boolean;

暗黙型変換ではないですが、暗黙変換同様に関数が利用された場合は、索引が利用できなくなることが確認できますよね。

perftestdb=> explain (analyze,verbose) select /*+ IndexScan(example2 ix_bool_example2) */ b1 from example2 where (b1::integer - 1)::boolean = false;
                                                          QUERY PLAN                                                           
-------------------------------------------------------------------------------------------------------------------------------
 Seq Scan on public.example2  (cost=10000000000.00..10000000001.52 rows=20 width=1) (actual time=0.027..0.041 rows=15 loops=1)
   Output: b1
   Filter: (NOT (((example2.b1)::integer - 1))::boolean)
   Rows Removed by Filter: 15
 Planning Time: 0.171 ms
 Execution Time: 2.737 ms
(6 行)

MySQL

TRUEとして解釈されるリテラル値
TRUE, 1のみ。（エラーにはならないが、0以外の数字は数字として整数として登録さえるので要注意）

FALSEとして解釈されるリテラル値
FALSE, 0のみ

なので、true,1 は内部的に　　true と扱われていることがわかります。
'yes'はやなりエラーですね。

mysql> create index ix_bool_example2 on example2(b1);
Query OK, 0 rows affected (1.28 sec)
Records: 0  Duplicates: 0  Warnings: 0

mysql> explain analyze select b1 from example2 where b1 = true;
+---------------------------------------------------------------------------------------------------------------------------------------+
| EXPLAIN                                                                                                                               |
+---------------------------------------------------------------------------------------------------------------------------------------+
| -> Covering index lookup on example2 using ix_bool_example2 (b1=true)  (cost=0.651 rows=4) (actual time=0.04..0.0441 rows=4 loops=1)
 |
+---------------------------------------------------------------------------------------------------------------------------------------+
1 row in set (0.03 sec)

mysql> explain analyze select b1 from example2 where b1 = 1;
+--------------------------------------------------------------------------------------------------------------------------------------+
| EXPLAIN                                                                                                                              |
+--------------------------------------------------------------------------------------------------------------------------------------+
| -> Covering index lookup on example2 using ix_bool_example2 (b1=1)  (cost=0.651 rows=4) (actual time=0.0165..0.0203 rows=4 loops=1)
 |
+--------------------------------------------------------------------------------------------------------------------------------------+
1 row in set (0.00 sec)

文字列だとエラーになるかと思いきや。ワーニング扱いですね。文字列がトランケートされた結果、述語が b1 = 0 に変更されてしまっています。これはダメですね。

mysql> explain analyze select b1 from example2 where b1 = 'yes';
+--------------------------------------------------------------------------------------------------------------------------------------+
| EXPLAIN                                                                                                                              |
+--------------------------------------------------------------------------------------------------------------------------------------+
| -> Covering index lookup on example2 using ix_bool_example2 (b1=0)  (cost=0.851 rows=6) (actual time=0.0179..0.0222 rows=6 loops=1)
 |
+--------------------------------------------------------------------------------------------------------------------------------------+
1 row in set, 1 warning (0.01 sec)
mysql> show warnings;
+---------+------+-----------------------------------------+
| Level   | Code | Message                                 |
+---------+------+-----------------------------------------+
| Warning | 1292 | Truncated incorrect DOUBLE value: 'yes' |
+---------+------+-----------------------------------------+
1 row in set (0.01 sec)

整数の正の値、負の値。予想通りそのまま、数値として比較されています。エラーにならないのでこれは避けた方が良さそう

mysql> explain analyze select b1 from example2 where b1 = 100;
+---------------------------------------------------------------------------------------------------------------------------------------+
| EXPLAIN                                                                                                                               |
+---------------------------------------------------------------------------------------------------------------------------------------+
| -> Covering index lookup on example2 using ix_bool_example2 (b1=100)  (cost=0.35 rows=1) (actual time=0.0214..0.0214 rows=0 loops=1)
 |
+---------------------------------------------------------------------------------------------------------------------------------------+
1 row in set (0.01 sec)

mysql> explain analyze select b1 from example2 where b1 = -100;
+------------------------------------------------------------------------------------------------------------------------------------------+
| EXPLAIN                                                                                                                                  |
+------------------------------------------------------------------------------------------------------------------------------------------+
| -> Covering index lookup on example2 using ix_bool_example2 (b1=-(100))  (cost=0.35 rows=1) (actual time=0.0147..0.0147 rows=0 loops=1)
 |
+------------------------------------------------------------------------------------------------------------------------------------------+
1 row in set (0.01 sec)

少数の場合もエラーにはなりません。述語は (Impossible WHERE)　なことになってますね。これらも避けた方が良さそう。

mysql> explain analyze select b1 from example2 where b1 = 0.1;
+--------------------------------------------------------------------------------------------------+
| EXPLAIN                                                                                          |
+--------------------------------------------------------------------------------------------------+
| -> Zero rows (Impossible WHERE)  (cost=0..0 rows=0) (actual time=281e-6..281e-6 rows=0 loops=1)
 |
+--------------------------------------------------------------------------------------------------+
1 row in set (0.01 sec)

mysql> explain analyze select b1 from example2 where b1 = -0.1;
+--------------------------------------------------------------------------------------------------+
| EXPLAIN                                                                                          |
+--------------------------------------------------------------------------------------------------+
| -> Zero rows (Impossible WHERE)  (cost=0..0 rows=0) (actual time=176e-6..176e-6 rows=0 loops=1)
 |
+--------------------------------------------------------------------------------------------------+
1 row in set (0.00 sec)

最後に、意地悪な検証を。

こんなことやらないと思いますけども、MySQL独特な挙動ですね。index only scanのまま、filterしてますね。TINYINTである影響なのでしょうね。面白いですが真似しないようにw。　この手の作り込んだら探すの大変そうだし。（データ積んでしっかり検証すると炙り出せるとは思うけどw）

mysql> explain analyze select b1 from example2 where (b1 - 1) = false;
+-------------------------------------------------------------------------------------------------------------------------------+
| EXPLAIN                                                                                                                       |
+-------------------------------------------------------------------------------------------------------------------------------+
| -> Filter: ((example2.b1 - 1) = false)  (cost=1.35 rows=11) (actual time=1.78..1.8 rows=4 loops=1)
    -> Covering index scan on example2 using ix_bool_example2  (cost=1.35 rows=11) (actual time=0.234..0.251 rows=11 loops=1)
 |
+-------------------------------------------------------------------------------------------------------------------------------+
1 row in set (0.05 sec)

BOOLEAN型の癖、総まとめ

BOOLEAN/BOOLどちらでも定義可能 (Oracle/PostgreSQL/MySQL)
(MySQLは内部的には、TINYINT型なのでそれ由来の癖がある)

データサイズは、1バイト (Oracle/PostgreSQL/MySQL)

利用可能なリテラル値（INSERT/UPDATEでセットする場合） TRUEとして扱われる値 TRUE　
(Oracle/PostgreSQL/MySQL, No case sensitive)

'ON'
(Oracle/PostgreSQL, No case sensitive)
(MySQLでは使えない)

'YES'
(Oracle/PostgreSQL, No case sensitive)
(MySQLでは使えない)

'T'
(Oracle/PostgreSQL, No case sensitive)
(MySQLでは使えない)

'Y'
(Oracle/PostgreSQL, No case sensitive)
(MySQLでは使えない)

1
(Oracle/MySQL)
(PostgreSQL booleanへのキャストが必要)

0以外の数値
(Oracle 少数及び負の整数も含む)
(PostgreSQL 正の整数のみ)
(MySQL 少数以下を切り捨てた整数として扱われるのでCHECK制約などで保護した方が安全なのではないだろうか。内部的にTINYINTである影響だろう)

FALSEとして扱われる値 FALSE
(Oracle/PostgreSQL/MySQL, No case sensitive)

'OFF'
(Oracle/PostgreSQL, No case sensitive)
(MySQLでは使えない)

'NO'
(Oracle/PostgreSQL, No case sensitive)
(MySQLでは使えない)

'F'
(Oracle/PostgreSQL, No case sensitive)
(MySQLでは使えない)

'N'
(Oracle/PostgreSQL, No case sensitive)
(MySQLでは使えない)

0
(Oracle/MySQL)
(PostgreSQL booleanへのキャストが必要)

利用可能なリテラル値（述語で利用する場合） TRUEとして扱われる値 TRUE　
(Oracle/PostgreSQL/MySQL, No case sensitive)

'ON'
(Oracle/PostgreSQL, No case sensitive)
(MySQL　利用すると値が切り捨てられ、WHERE boolean列 = 'ON' が WHERE boolean列 = 0 に書き換えられてします。ワーニングなどで確認できるが、避けた方が良い。 sql_mode挙動が変わったりするのかは未確認)

'YES'
(Oracle/PostgreSQL, No case sensitive)
(MySQL　利用すると値が切り捨てられ、WHERE boolean列 = 'YES' が WHERE boolean列 = 0 に書き換えられてします。ワーニングなどで確認できるが、避けた方が良い。 sql_mode挙動が変わったりするのかは未確認)

'T'
(Oracle/PostgreSQL, No case sensitive)
(MySQL　利用すると値が切り捨てられ、WHERE boolean列 = 'T' が WHERE boolean列 = 0 に書き換えられてします。ワーニングなどで確認できるが、避けた方が良い。 sql_mode挙動が変わったりするのかは未確認)

'Y'
(Oracle/PostgreSQL, No case sensitive)
(MySQL　利用すると値が切り捨てられ、WHERE boolean列 = 'Y' が WHERE boolean列 = 0 に書き換えられてします。ワーニングなどで確認できるが、避けた方が良い。 sql_mode挙動が変わったりするのかは未確認)

1
(Oracle/MySQL)
(PostgreSQL booleanへのキャストが必要)

0以外の数値
(Oracle 少数及び負の整数も含む)
(PostgreSQL 正の整数のみ)
(MySQL 内部的にTINYINTである影響だろうか、エラーとはならず、数値として扱われたり、切り捨てられたりする。避けた方が良い。 e.g. WHERE boolean列 = 100や、WHERE boolean列 = 0.1 など。 sql_mode挙動が変わったりするのかは未確認)

FALSEとして扱われる値 FALSE
(Oracle/PostgreSQL/MySQL, No case sensitive)

'OFF'
(Oracle/PostgreSQL, No case sensitive)
(MySQL　利用すると値が切り捨てられ、WHERE boolean列 = 'OFF' が WHERE boolean列 = 0 に書き換えられてします。ワーニングなどで確認できるが、避けた方が良い。 sql_mode挙動が変わったりするのかは未確認)

'NO'
(Oracle/PostgreSQL, No case sensitive)
(MySQL　利用すると値が切り捨てられ、WHERE boolean列 = 'NO' が WHERE boolean列 = 0 に書き換えられてします。ワーニングなどで確認できるが、避けた方が良い。 sql_mode挙動が変わったりするのかは未確認)

'F'
(Oracle/PostgreSQL, No case sensitive)
(MySQL　利用すると値が切り捨てられ、WHERE boolean列 = 'F' が WHERE boolean列 = 0 に書き換えられてします。ワーニングなどで確認できるが、避けた方が良い。 sql_mode挙動が変わったりするのかは未確認)

'N'
(Oracle/PostgreSQL, No case sensitive)
(MySQL　利用すると値が切り捨てられ、WHERE boolean列 = 'N' が WHERE boolean列 = 0 に書き換えられてします。ワーニングなどで確認できるが、避けた方が良い。 sql_mode挙動が変わったりするのかは未確認)

0
(Oracle/MySQL)
(PostgreSQL booleanへのキャストが必要)

全体的に、true/false (null) を使うように規約で制限したり、CHECK制約で保護しておいた方が混乱を避けられるのではないだろうか。。

癖ありすぎ！　w w

では、また。

投稿日時 2024年5月29日 (水) 19時00分 Oracle, FAQ, SQL, MySQL, PostgreSQL, Oracle Database 23c Free Developer Release | 固定リンク | 0 | コメント (0)

帰ってきた！標準はあるにはあるが癖の多いSQL #9、BOOLEAN型にも癖が出る

PostgreSQL/MySQLには実装済みだった Boolean型がやっとOracle Database 23aiで追加されました。長ーい間実装されなかったデータ型なので、number型を使ったりして代替されていたわけですが、23ai以降は普通に使えるってことですね。
ただ、タイトルの通り、標準はあるものの、それぞれの実装には癖があります！！！！w

どのような癖があるのか、知っておきましょう。　（兼、自分用メモ）
Oracle/PostgreSQL/MySQLで違いを見てみます。

Oracle Database 23ai

SCOTT@freepdb1> select banner_full from v$version;

BANNER_FULL
--------------------------------------------------------------------------------
Oracle Database 23ai Free Release 23.0.0.0.0 - Develop, Learn, and Run for Free
Version 23.4.0.24.05

PostgreSQL
例によってw こちらの都合により、13.14を使っています。

perftestdb=> select version();
                                                 version                                                  
----------------------------------------------------------------------------------------------------------
 PostgreSQL 13.14 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 8.5.0 20210514 (Red Hat 8.5.0-20), 64-bit
(1 行)

MySQL

mysql> select version();
+-----------+
| version() |
+-----------+
| 8.0.36    |
+-----------+
1 row in set (0.02 sec)

データ登録時、どの値がBOOLEANとして扱われるのかマニュアルから拾った値を元に確認しておきたいと思います。キャストが必要だったりする場合には、暗黙型変換とか気にしておいた方が良いですからね。索引にも使えるデータ型ですし。。。

Oracle Database 23ai
TRUEとして解釈されるリテラル値 (文字列は大文字小文字は無視される。数値は、0以外の数値は全て、TRUEと解釈される。e.g. -1,10,0.1,-1.5 など)
TRUE. 'ON', 'YES', 'T', 'Y', 1, 0以外の数値

FALSEとして解釈されるリテラル値 (文字列は大文字小文字は無視される。数値は、0のみFALSEと解釈される)
FALSE, 'OFF', 'NO', 'F', 'N', 0

この仕様、Db2やSnowflakeのBOOLEAN型と同じように見えますね。（試してないですけどw）

マニュアルに記載されている通りの挙動。。。数値を指定した時の解釈もマニュアル通りなのですが、こんな使い方したくないですよねw 挙動確認なので試してはいますが。。。。

SCOTT@freepdb1> @boolean_literals.sql

Table dropped.
Table created.
1 row created.
1 row created.

...中略...

1 row created.
1 row created.
Commit complete.

        ID B1          MEMO
---------- ----------- ----------
         1 TRUE        TRUE
         2 TRUE        true
         3 TRUE        True
         4 TRUE        ON
         5 TRUE        on
         6 TRUE        On
         7 TRUE        YES
         8 TRUE        yes
         9 TRUE        Yes
        10 TRUE        T
        11 TRUE        t
        12 TRUE        Y
        13 TRUE        y
        14 TRUE        1
        15 TRUE        0.01
        16 TRUE        -0.01
        17 TRUE        10
        18 TRUE        -12
        19 FALSE       FALSE
        20 FALSE       false
        21 FALSE       False
        22 FALSE       OFF
        23 FALSE       off
        24 FALSE       Off
        25 FALSE       NO
        26 FALSE       no
        27 FALSE       No
        28 FALSE       F
        29 FALSE       f
        30 FALSE       N
        31 FALSE       n
        32 FALSE       0
        33 [null]      null

33 rows selected.

PostgreSQL 13.14
TRUEとして解釈されるリテラル値 (文字列は大文字小文字は無視される。数値は、正の整数のみTRUEと解釈され、負の整数や少数はエラーとなる。　-1, 0.1, -1.5などはエラー)
TRUE. 'ON', 'YES', 'T', 'Y', 1, 0以外の正の整数のみ（ただし、booleanへのキャストが必要）

FALSEとして解釈されるリテラル値 (文字列は大文字小文字は無視される。数値は、0のみFALSEと解釈される)
FALSE, 'OFF', 'NO', 'F', 'N', 0

Oracleに類似していますが、数値の扱いが微妙に違いますね。

perftestdb=> \i boolean_literals.sql
DROP TABLE
CREATE TABLE
INSERT 0 1
INSERT 0 1

...中略...

INSERT 0 1
INSERT 0 1
INSERT 0 1
psql:boolean_literals.sql:19: ERROR:  column "b1" is of type boolean but expression is of type integer
行 1: insert into example2 values(14, 1, '1');
                                      ^
HINT:  You will need to rewrite or cast the expression.
INSERT 0 1
psql:boolean_literals.sql:21: ERROR:  column "b1" is of type boolean but expression is of type numeric
行 1: insert into example2 values(15, 0.01, '0.01');
                                      ^
HINT:  You will need to rewrite or cast the expression.
psql:boolean_literals.sql:22: ERROR:  cannot cast type numeric to boolean
行 1: insert into example2 values(15, 0.01::boolean, '0.01');v                                          ^
psql:boolean_literals.sql:23: ERROR:  column "b1" is of type boolean but expression is of type numeric
行 1: insert into example2 values(16, -0.1, '-0.01');
                                      ^
HINT:  You will need to rewrite or cast the expression.
psql:boolean_literals.sql:24: ERROR:  cannot cast type numeric to boolean
行 1: insert into example2 values(16, -0.1::boolean, '-0.01');
                                          ^
psql:boolean_literals.sql:25: ERROR:  column "b1" is of type boolean but expression is of type integer
行 1: insert into example2 values(17, 10, '10');
                                      ^
HINT:  You will need to rewrite or cast the expression.
INSERT 0 1
psql:boolean_literals.sql:27: ERROR:  column "b1" is of type boolean but expression is of type integer
行 1: insert into example2 values(18, -12, '-12');
                                      ^
HINT:  You will need to rewrite or cast the expression.
psql:boolean_literals.sql:28: ERROR:  operator does not exist: - boolean
行 1: insert into example2 values(18, -12::boolean, '-12');
                                      ^
HINT:  No operator matches the given name and argument type. You might need to add an explicit type cast.
INSERT 0 1
INSERT 0 1

...中略...

INSERT 0 1
INSERT 0 1
psql:boolean_literals.sql:44: ERROR:  column "b1" is of type boolean but expression is of type integer
行 1: insert into example2 values(32, 0, '0');
                                      ^
HINT:  You will need to rewrite or cast the expression.
INSERT 0 1
INSERT 0 1
Null表示は"[null]"です。
 id |   b1   | memo  
----+--------+-------
  1 | t      | TRUE
  2 | t      | true
  3 | t      | True
  4 | t      | ON
  5 | t      | on
  6 | t      | On
  7 | t      | YES
  8 | t      | yes
  9 | t      | Yes
 10 | t      | T
 11 | t      | t
 12 | t      | Y
 13 | t      | y
 14 | t      | 1
 17 | t      | 10
 19 | f      | FALSE
 20 | f      | false
 21 | f      | False
 22 | f      | OFF
 23 | f      | off
 24 | f      | Off
 25 | f      | NO
 26 | f      | no
 27 | f      | No
 28 | f      | F
 29 | f      | f
 30 | f      | N
 31 | f      | n
 32 | f      | 0
 33 | [null] | null
(30 行)

perftestdb=>

MySQL 8.0.32
実データ型がTINYINTであるためですが、
数値の場合0,1以外ではエラーは出ないようで注意が必要ですよね。CHECK制約で保護するとかだろうか。。。

TRUEとして解釈されるリテラル値
TRUE, 1のみ。（エラーにはならないが、0以外の数字は数字として整数として登録さえるので要注意）

FALSEとして解釈されるリテラル値
FALSE, 0のみ

Oracle/PostgreSQLとも違い、最低限に絞ってるって感じですが、数値を指定した時の挙動には要注意ですね。内部の型はTINYINTなので。。。文字列を全て受け付けないのは、これもTINYINTである影響ですかね?

mysql> select @@sql_mode; +-----------------------------------------------------------------------------------------------------------------------+ | @@sql_mode | +-----------------------------------------------------------------------------------------------------------------------+ | ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION | +-----------------------------------------------------------------------------------------------------------------------+ 1 row in set (0.01 sec) mysql> \. boolean_literals.sql Query OK, 0 rows affected (0.05 sec) ...中略... Query OK, 1 row affected (0.01 sec) ERROR 1366 (HY000): Incorrect integer value: 'ON' for column 'b1' at row 1 ERROR 1366 (HY000): Incorrect integer value: 'on' for column 'b1' at row 1 ERROR 1366 (HY000): Incorrect integer value: 'On' for column 'b1' at row 1 ERROR 1366 (HY000): Incorrect integer value: 'YES' for column 'b1' at row 1 ERROR 1366 (HY000): Incorrect integer value: 'yes' for column 'b1' at row 1 ERROR 1366 (HY000): Incorrect integer value: 'Yes' for column 'b1' at row 1 ERROR 1366 (HY000): Incorrect integer value: 'T' for column 'b1' at row 1 ERROR 1366 (HY000): Incorrect integer value: 't' for column 'b1' at row 1 ERROR 1366 (HY000): Incorrect integer value: 'Y' for column 'b1' at row 1 ERROR 1366 (HY000): Incorrect integer value: 'y' for column 'b1' at row 1 Query OK, 1 row affected (0.01 sec) ...中略... Query OK, 1 row affected (0.01 sec) ERROR 1366 (HY000): Incorrect integer value: 'OFF' for column 'b1' at row 1 ERROR 1366 (HY000): Incorrect integer value: 'off' for column 'b1' at row 1 ERROR 1366 (HY000): Incorrect integer value: 'Off' for column 'b1' at row 1 ERROR 1366 (HY000): Incorrect integer value: 'NO' for column 'b1' at row 1 ERROR 1366 (HY000): Incorrect integer value: 'no' for column 'b1' at row 1 ERROR 1366 (HY000): Incorrect integer value: 'No' for column 'b1' at row 1 ERROR 1366 (HY000): Incorrect integer value: 'F' for column 'b1' at row 1 ERROR 1366 (HY000): Incorrect integer value: 'f' for column 'b1' at row 1 ERROR 1366 (HY000): Incorrect integer value: 'N' for column 'b1' at row 1 ERROR 1366 (HY000): Incorrect integer value: 'n' for column 'b1' at row 1 Query OK, 1 row affected (0.01 sec) Query OK, 1 row affected (0.01 sec) +----+------+-------+ | id | b1 | memo | +----+------+-------+ | 1 | 1 | TRUE | | 2 | 1 | true | | 3 | 1 | True | | 14 | 1 | 1 | | 15 | 0 | 0.01 | | 16 | 0 | -0.01 | | 17 | 10 | 10 | | 18 | -12 | -12 | | 19 | 0 | FALSE | | 20 | 0 | false | | 21 | 0 | False | | 32 | 0 | 0 | | 33 | NULL | null | +----+------+-------+ 13 rows in set (0.00 sec)

長くなりそうなので、次回へ続く！w　

今回のまとめ

Oracle > PostgreSQL > MySQLのような感じで使える値の種類はサブセットになってる感じですね。　なので、true/false , nullだけ使ってればどこに行っても問題はなさそう。。ではあります。

Oracle Database 23ai/MySQL/PostgreSQL共通
BOOLEAN/BOOL型として定義可能。
（ただし、MySQLでは実態はTINYINTなので、TINYINT由来の癖があるので注意

TRUEとして扱われる値
TRUE　
(Oracle/PostgreSQL/MySQL, No case sensitive)

'ON'
(Oracle/PostgreSQL, No case sensitive)
(MySQLでは使えない)

'YES'
(Oracle/PostgreSQL, No case sensitive)
(MySQLでは使えない)

'T'
(Oracle/PostgreSQL, No case sensitive)
(MySQLでは使えない)

'Y'
(Oracle/PostgreSQL, No case sensitive)
(MySQLでは使えない)

1
(Oracle/MySQL)
(PostgreSQL booleanへのキャストが必要)

0以外の数値
(Oracle 少数及び負の整数も含む)
(PostgreSQL 正の整数のみ)
(MySQL 少数以下を切り捨てた整数として扱われるのでCHECK制約などで保護した方が安全なのではないだろうか。内部的にTINYINTである影響だろう)

FALSEとして扱われる値
FALSE
(Oracle/PostgreSQL/MySQL, No case sensitive)

'OFF'
(Oracle/PostgreSQL, No case sensitive)
(MySQLでは使えない)

'NO'
(Oracle/PostgreSQL, No case sensitive)
(MySQLでは使えない)

'F'
(Oracle/PostgreSQL, No case sensitive)
(MySQLでは使えない)

'N'
(Oracle/PostgreSQL, No case sensitive)
(MySQLでは使えない)

0
(Oracle/MySQL)
(PostgreSQL booleanへのキャストが必要)

全体的に、true/false (null) を使うように規約等、場合によってはCHECK制約で保護しておいた方が、何かと混乱を避けられるのではないだろうか。。

補足）

この検証に利用したスクリプト
Oracle Database 23ai

SCOTT/freepdb1> !cat boolean_literals.sql drop table if exists example2; create table example2 (id number primary key, b1 boolean, memo varchar2(10)); -- TRUE insert into example2 values(1, TRUE, 'TRUE'); insert into example2 values(2, true, 'true'); insert into example2 values(3, True, 'True'); insert into example2 values(4, 'ON', 'ON'); insert into example2 values(5, 'on', 'on'); insert into example2 values(6, 'On', 'On'); insert into example2 values(7, 'YES', 'YES'); insert into example2 values(8, 'yes', 'yes'); insert into example2 values(9, 'Yes', 'Yes'); insert into example2 values(10, 'T', 'T'); insert into example2 values(11, 't', 't'); insert into example2 values(12, 'Y', 'Y'); insert into example2 values(13, 'y', 'y'); insert into example2 values(14, 1, '1'); insert into example2 values(15, 0.01, '0.01'); insert into example2 values(16, -0.1, '-0.01'); insert into example2 values(17, 10, '10'); insert into example2 values(18, -12, '-12'); -- FALSE insert into example2 values(19, FALSE, 'FALSE'); insert into example2 values(20, false, 'false'); insert into example2 values(21, False, 'False'); insert into example2 values(22, 'OFF', 'OFF'); insert into example2 values(23, 'off', 'off'); insert into example2 values(24, 'Off', 'Off'); insert into example2 values(25, 'NO', 'NO'); insert into example2 values(26, 'no', 'no'); insert into example2 values(27, 'No', 'No'); insert into example2 values(28, 'F', 'F'); insert into example2 values(29, 'f', 'f'); insert into example2 values(30, 'N', 'N'); insert into example2 values(31, 'n', 'n'); insert into example2 values(32, 0, '0'); -- NULL insert into example2 values(33, null, 'null'); commit; -- check set NULL [null] select * from example2 order by id;

PostgreSQL 13.14

erftestdb=> \! cat boolean_literals.sql drop table if exists example2; create table example2 (id integer primary key, b1 boolean, memo varchar(10)); -- TRUE insert into example2 values(1, TRUE, 'TRUE'); insert into example2 values(2, true, 'true'); insert into example2 values(3, True, 'True'); insert into example2 values(4, 'ON', 'ON'); insert into example2 values(5, 'on', 'on'); insert into example2 values(6, 'On', 'On'); insert into example2 values(7, 'YES', 'YES'); insert into example2 values(8, 'yes', 'yes'); insert into example2 values(9, 'Yes', 'Yes'); insert into example2 values(10, 'T', 'T'); insert into example2 values(11, 't', 't'); insert into example2 values(12, 'Y', 'Y'); insert into example2 values(13, 'y', 'y'); insert into example2 values(14, 1, '1'); insert into example2 values(14, 1::boolean, '1'); insert into example2 values(15, 0.01, '0.01'); insert into example2 values(15, 0.01::boolean, '0.01'); insert into example2 values(16, -0.1, '-0.01'); insert into example2 values(16, -0.1::boolean, '-0.01'); insert into example2 values(17, 10, '10'); insert into example2 values(17, 10::boolean, '10'); insert into example2 values(18, -12, '-12'); insert into example2 values(18, -12::boolean, '-12'); -- FALSE insert into example2 values(19, FALSE, 'FALSE'); insert into example2 values(20, false, 'false'); insert into example2 values(21, False, 'False'); insert into example2 values(22, 'OFF', 'OFF'); insert into example2 values(23, 'off', 'off'); insert into example2 values(24, 'Off', 'Off'); insert into example2 values(25, 'NO', 'NO'); insert into example2 values(26, 'no', 'no'); insert into example2 values(27, 'No', 'No'); insert into example2 values(28, 'F', 'F'); insert into example2 values(29, 'f', 'f'); insert into example2 values(30, 'N', 'N'); insert into example2 values(31, 'n', 'n'); insert into example2 values(32, 0, '0'); insert into example2 values(32, 0::boolean, '0'); -- NULL insert into example2 values(33, null, 'null'); -- check \pset null [null] select * from example2 order by id;

MySQL 8.0.32

mysql> \! cat boolean_literals.sql drop table if exists example2; create table example2 (id integer primary key, b1 boolean, memo varchar(10)); -- TRUE insert into example2 values(1, TRUE, 'TRUE'); insert into example2 values(2, true, 'true'); insert into example2 values(3, True, 'True'); insert into example2 values(4, 'ON', 'ON'); insert into example2 values(5, 'on', 'on'); insert into example2 values(6, 'On', 'On'); insert into example2 values(7, 'YES', 'YES'); insert into example2 values(8, 'yes', 'yes'); insert into example2 values(9, 'Yes', 'Yes'); insert into example2 values(10, 'T', 'T'); insert into example2 values(11, 't', 't'); insert into example2 values(12, 'Y', 'Y'); insert into example2 values(13, 'y', 'y'); insert into example2 values(14, 1, '1'); insert into example2 values(15, 0.01, '0.01'); insert into example2 values(16, -0.1, '-0.01'); insert into example2 values(17, 10, '10'); insert into example2 values(18, -12, '-12'); -- FALSE insert into example2 values(19, FALSE, 'FALSE'); insert into example2 values(20, false, 'false'); insert into example2 values(21, False, 'False'); insert into example2 values(22, 'OFF', 'OFF'); insert into example2 values(23, 'off', 'off'); insert into example2 values(24, 'Off', 'Off'); insert into example2 values(25, 'NO', 'NO'); insert into example2 values(26, 'no', 'no'); insert into example2 values(27, 'No', 'No'); insert into example2 values(28, 'F', 'F'); insert into example2 values(29, 'f', 'f'); insert into example2 values(30, 'N', 'N'); insert into example2 values(31, 'n', 'n'); insert into example2 values(32, 0, '0'); -- NULL insert into example2 values(33, null, 'null'); -- check select * from example2 order by id;

ここまで見た感じ、true/false,　必要があれば null を使う側のルールとしておくと、みんな幸せになれる気がするよね。BOOLEAN型って。

参考資料）
Oracle Database 23 / 開発者ガイド / 外部データ型
"https://docs.oracle.com/cd/F82042_01/lnoci/data-types.html#GUID-D69455D9-CE01-44CC-B5A9-E541C7774805

Oracle Database 23 / SQL言語リファレンス / ブールデータ型
https://docs.oracle.com/cd/F82042_01/sqlrf/Data-Types.html#GUID-285FFCA8-390D-4FA9-9A51-47B84EF5F83A

Oracle Database 23 / SQL言語リファレンス / Oracleの組込みデータ型
https://docs.oracle.com/cd/F82042_01/sqlrf/Data-Types.html#GUID-7B72E154-677A-4342-A1EA-C74C1EA928E6

PostgreSQL / データ型 / 論理値データ型
https://www.postgresql.jp/document/13/html/datatype-boolean.html

マニュアルによると、PostgreSQLのBOOLEAN型もサイズは１バイト
PostgreSQL 13 / 8.6. 論理値データ型
https://www.postgresql.jp/document/13/html/datatype-boolean.html

MySQL その他のデータベースエンジンのデータ型の使用　 - BOOLEAN/BOOL
https://dev.mysql.com/doc/refman/8.0/ja/other-vendor-data-types.html

MySQL 数値型の記憶域要件 - TINYINT
https://dev.mysql.com/doc/refman/8.0/ja/storage-requirements.html#data-types-storage-reqs-numeric

MySQLのBOOLEANはTINYINT型で1バイトということですね。Boolean型のサイズはMySQL/Oracle/PostgreSQLどれも1バイト。
MySQL 8.0 / 11.1.6 Boolean Literals
https://dev.mysql.com/doc/refman/8.0/en/boolean-literals.html

長くなりそうなので、次回へ続くw

こういうことで、この手の　SQLの癖w　なかなか厳しいなw 　Enjoy SQL!

関連エントリー
・標準はあるにはあるが癖の多いSQL 全部俺　#1 Pagination
・標準はあるにはあるが癖の多いSQL 全部俺　#2 関数名は同じでも引数が逆の罠！
・標準はあるにはあるが癖の多いSQL 全部俺　#3 データ型確認したい時あるんです
・標準はあるにはあるが癖の多いSQL 全部俺　#4 リテラル値での除算の内部精度も違うのよ!
・標準はあるにはあるが癖の多いSQL 全部俺　#5 和暦変換機能ある方が少数派
・標準はあるにはあるが癖の多いSQL 全部俺　#6 時間厳守！
・標準はあるにはあるが癖の多いSQL 全部俺　#7 期間リテラル！
・標準はあるにはあるが癖の多いSQL 全部俺　#8 翌月末日って何日？
・標準はあるにはあるが癖の多いSQL 全部俺　#9 部分文字列の扱いでも癖が出る＞＜
・標準はあるにはあるが癖の多いSQL 全部俺　#10 文字列連結の罠（有名なやつ）
・標準はあるにはあるが癖の多いSQL 全部俺　#11 デュエル、じゃなくて、デュアル
・標準はあるにはあるが癖の多いSQL 全部俺　#12 文字[列]探すにも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#13 あると便利ですが意外となかったり
・標準はあるにはあるが癖の多いSQL 全部俺　#14 連番の集合を返すにも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#15 SQL command line client
・標準はあるにはあるが癖の多いSQL 全部俺　#16 SQLのレントゲンを撮る方法
・標準はあるにはあるが癖の多いSQL 全部俺　#17 その空白は許されないのか？
・標準はあるにはあるが癖の多いSQL 全部俺　#18 (+)の外部結合は方言
・標準はあるにはあるが癖の多いSQL 全部俺　#19 帰ってきた、部分文字列の扱いでも癖w
・標準はあるにはあるが癖の多いSQL 全部俺　#20 結果セットを単一列に連結するにも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#21 演算結果にも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#22 集合演算にも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#23 複数行INSERTにも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#24 乱数作るにも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#25 SQL de Fractalsにも癖がある:)
・標準はあるにはあるが癖の多いSQL 全部俺　おまけ SQL de 湯婆婆やるにも癖がでるw
・帰ってきた！標準はあるにはあるが癖の多いSQL #1 SQL de ROT13 やるにも癖が出るw
・帰ってきた！標準はあるにはあるが癖の多いSQL #2 Actual Plan取得中のキャンセルでも癖が出る
・帰ってきた！標準はあるにはあるが癖の多いSQL #3 オプティマイザの結合順評価テーブル数上限にも癖が出る
・帰ってきた！標準はあるにはあるが癖の多いSQL #4 Optimizer Traceの取得でも癖がでる
・帰ってきた！標準はあるにはあるが癖の多いSQL #5 - Optimizer Hint でも癖が多い
・帰ってきた！標準はあるにはあるが癖の多いSQL #6 - Hash Joinの結合ツリーにも癖がでる
・帰ってきた！標準はあるにはあるが癖の多いSQL #7 - Hash Joinの実行計画にも癖がでる
・帰ってきた！標準はあるにはあるが癖の多いSQL #8 - Hash Joinさせるにも癖が出る

投稿日時 2024年5月29日 (水) 17時00分 Oracle, FAQ, SQL, ダウンロード, MySQL, PostgreSQL, パフォーマンス, Oracle Database 23c Free Developer Release | 固定リンク | 0 | コメント (0)

2024年5月19日 (日)

構文図で見る、SELECT文の構文拡張の歴史 w

2015年にイベント開催のコメントおまけで、Oracle DatabaseのSQLからSELECT文の構文拡張の歴史をOracle Database 7.3と12.1版のマニュアルに記載されている構文図の長さを使って可視化したことがあったのですが、覚えているでしょうか？w　（多分、忘れてますよねw）

JPOUG> SET EVENTS 20151017 を開催します！

Oracle Database 23aiがリリースされてSQLシンタックスの拡張をマニュアルをつらつら読んでて思ったのですが、色々拡張されてますよね！
ということで、Oracle Database 7.3 / 8i 8.1.6 / 12cR1 12.1 / 23ai それぞれのSELECT文の拡張の歴史を構文図の長さを使って、今一度、可視化して残しておこうと思います。

みなさん、SQLの進化というか拡張に、追いつけていますよね。。。ね。。。。ね！？　（大変ですけどもw）

各バージョンのSELECT文の構文図のソースは以下です。みなさんもマニュアルのページ数の増加や構文図の拡張に着目しつつ追ってみるのも楽しいかもしれません。　　

・Oracle7 Server SQL Reference Manual - SELECT
・Oracle8i SQL Reference Release 2 (8.1.6) - SELECT and Subqueries
・Database SQL Language Reference 12c 12.1 - SELECT
・SQL Language Reference - Oracle Database 23ai - SELECT

Oracle Database 9i, 10g, 11gのダイアグラムは端折ってますが、これぐらい差分があったほうが、インパクトがあっていいかなぁ。と思いあえて載せていません :)

12cR1以降長すぎてこれぐらい小さくしないと収まりませんw　

オチも何もないですが、現場からは以上です！　（なお、実際のリリース年は多少前後しているかもしれません）

Enjoy SQL!

ではまた。

投稿日時 2024年5月19日 (日) 09時34分 Oracle, FAQ, SQL, Oracle Database 12c release 1, Oracle Database 23c Free Developer Release | 固定リンク | 0 | コメント (0)

2024年5月16日 (木)

GROUP BY列の別名または位置の指定が可能に！ / 23ai〜 / SQL / FAQ

23c 改め、23ai になった Oracle Database 23aiですが、SQLの使い勝手の改善がいくつか。
有名なのは、from dual　を書かなくても良くなったこと。ですが、有名すぎるのであえて書きません！w

ということで、ちょっとマイナーだけど便利ですよね！　という　「GROUP BY列の別名または位置の指定が可能に！ / 23ai〜」　というお話。

参考　ー　Oracle Databaseリリース23cの変更点
https://docs.oracle.com/cd/F82042_01/sqlrf/Changes-in-This-Release-for-Oracle-Database-SQL-Language-Reference.html

自分用アップデートメモでもありますw

まずこれまでのおさらいということで、Oracle Database 21c EEで挙動を確認しておきます。

SCOTT@orclpdb1> select banner_full from v$version; BANNER_FULL ----------------------------------------------------------------------- Oracle Database 21c Enterprise Edition Release 21.0.0.0.0 - Production Version 21.3.0.0.0 SCOTT@orclpdb1> select * from emp; EMPNO ENAME JOB MGR HIREDATE SAL COMM DEPTNO ---------- ---------- --------- ---------- --------- ---------- ---------- ---------- 7369 SMITH CLERK 7902 17-DEC-80 800 20 7499 ALLEN SALESMAN 7698 20-FEB-81 1600 300 30 7521 WARD SALESMAN 7698 22-FEB-81 1250 500 30 7566 JONES MANAGER 7839 02-APR-81 2975 20 7654 MARTIN SALESMAN 7698 28-SEP-81 1250 1400 30 7698 BLAKE MANAGER 7839 01-MAY-81 2850 30 7782 CLARK MANAGER 7839 09-JUN-81 2450 10 7788 SCOTT ANALYST 7566 19-APR-87 3000 20 7839 KING PRESIDENT 17-NOV-81 5000 10 7844 TURNER SALESMAN 7698 08-SEP-81 1500 0 30 7876 ADAMS CLERK 7788 23-MAY-87 1100 20 7900 JAMES CLERK 7698 03-DEC-81 950 30 7902 FORD ANALYST 7566 03-DEC-81 3000 20 7934 MILLER CLERK 7782 23-JAN-82 1300 10 14 rows selected.

group by 別名指定。。見事にエラーになります！

SCOTT@orclpdb1> l 1 SELECT 2 TO_CHAR(hiredate,'YYYY') AS year 3 , COUNT(1) AS hired 4 FROM 5 emp 6 GROUP BY 7 year 8 ORDER BY 9* year SCOTT@orclpdb1> / year * 行7でエラーが発生しました。: ORA-00904: "YEAR": 無効な識別子です。

group by 位置指定。。これも間違いなくエラーです！。。。

SCOTT@orclpdb1> l 1 SELECT 2 TO_CHAR(hiredate,'YYYY') AS year 3 , COUNT(1) AS hired 4 FROM 5 emp 6 GROUP BY 7 1 8 ORDER BY 9* year SCOTT@orclpdb1> / TO_CHAR(hiredate,'YYYY') AS year * 行2でエラーが発生しました。: ORA-00979: GROUP BYの式ではありません。

ということで、これまではこんな面倒が書き方してたわけです。はい。。。

SCOTT@orclpdb1> l 1 SELECT 2 TO_CHAR(hiredate,'YYYY') AS year 3 , COUNT(1) AS hired 4 FROM 5 emp 6 GROUP BY 7 TO_CHAR(hiredate,'YYYY') 8 ORDER BY 9* year SCOTT@orclpdb1> / YEAR HIRED ------------ ---------- 1980 1 1981 10 1982 1 1987 2

これまでは、こんな感じ。まあ面倒臭いですよね。

しかーーーーし、23ai以降では、そんな面倒は忘れてください。

SCOTT/freepdb1> select banner_full from v$version; BANNER_FULL ------------------------------------------------------------------------------- Oracle Database 23ai Free Release 23.0.0.0.0 - Develop, Learn, and Run for Free Version 23.4.0.24.05 SCOTT/freepdb1> select * from emp; EMPNO ENAME JOB MGR HIREDATE SAL COMM DEPTNO ---------- ---------- --------- ---------- --------- ---------- ---------- ---------- 7369 SMITH CLERK 7902 17-DEC-80 800 20 7499 ALLEN SALESMAN 7698 20-FEB-81 1600 300 30 7521 WARD SALESMAN 7698 22-FEB-81 1250 500 30 7566 JONES MANAGER 7839 02-APR-81 2975 20 7654 MARTIN SALESMAN 7698 28-SEP-81 1250 1400 30 7698 BLAKE MANAGER 7839 01-MAY-81 2850 30 7782 CLARK MANAGER 7839 09-JUN-81 2450 10 7788 SCOTT ANALYST 7566 19-APR-87 3000 20 7839 KING PRESIDENT 17-NOV-81 5000 10 7844 TURNER SALESMAN 7698 08-SEP-81 1500 0 30 7876 ADAMS CLERK 7788 23-MAY-87 1100 20 7900 JAMES CLERK 7698 03-DEC-81 950 30 7902 FORD ANALYST 7566 03-DEC-81 3000 20 7934 MILLER CLERK 7782 23-JAN-82 1300 10 14 rows selected.

group by 別名指定。おおおおおおーーぅ！　　できた。

SCOTT/freepdb1> l 1 SELECT 2 TO_CHAR(hiredate,'YYYY') AS year 3 , COUNT(1) AS hired 4 FROM 5 emp 6 GROUP BY 7 year 8 ORDER BY 9* year SCOTT/freepdb1> / YEAR HIRED ---- ---------- 1980 1 1981 10 1982 1 1987 2

group by 位置指定....？　

SCOTT/freepdb1> l 1 SELECT 2 TO_CHAR(hiredate,'YYYY') AS year 3 , COUNT(1) AS hired 4 FROM 5 emp 6 GROUP BY 7 1 8 ORDER BY 9 year 10* SCOTT/freepdb1> / TO_CHAR(hiredate,'YYYY') AS year * ERROR at line 2: ORA-03162: "HIREDATE": must appear in the GROUP BY clause or be used in an aggregate function as 'group_by_position_enabled' is FALSE Help: https://docs.oracle.com/error-help/db/ora-03162/

なんと、23ai free developerではデフォルトで無効化されてる！？。。。とは言っても、位置指定は、order by でも使わない場合が多いので、デフォルトオフでも影響はないですかね。一般的には。

SCOTT/freepdb1> show parameter group_by_position_enabled NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ group_by_position_enabled boolean FALSE SCOTT/freepdb1> alter session set group_by_position_enabled = true; Session altered. SCOTT/freepdb1> show parameter group_by_position_enabled NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ group_by_position_enabled boolean TRUE SCOTT/freepdb1> l 1 SELECT 2 TO_CHAR(hiredate,'YYYY') AS year 3 , COUNT(1) AS hired 4 FROM 5 emp 6 GROUP BY 7 1 8 ORDER BY 9 year 10* SCOTT/freepdb1> / YEAR HIRED ---- ---------- 1980 1 1981 10 1982 1 1987 2

strong>最後に、従来の面倒臭い構文の確認。

SCOTT/freepdb1> l 1 SELECT 2 TO_CHAR(hiredate,'YYYY') AS year 3 , COUNT(1) AS hired 4 FROM 5 emp 6 GROUP BY 7 TO_CHAR(hiredate,'YYYY') 8 ORDER BY 9* year SCOTT/freepdb1> / YEAR HIRED ---- ---------- 1980 1 1981 10 1982 1 1987 2

Enjoy SQL!

では、また

投稿日時 2024年5月16日 (木) 12時00分 Oracle, FAQ, SQL, Oracle Database 11g Release 2, Oracle Database 12c release 1, Oracle Database 12c Release 2, Oracle Database 18c, Oracle Database 19c, Oracle Database 21c, Oracle Database 23c Free Developer Release | 固定リンク | 0 | コメント (0)

2024年3月25日 (月)

Oracleのマニュアルで Bushy Join Tree と説明されてる図、Zigzag Join Treeだよね？、いわゆる、Bushy Join Tree は無いのか？　いいえ、あります！

久々の技術ネタの投稿です。
昨年末のエントリーに軽くスルーしていた面白いネタが隠れていたのですが、気付いた方はどれぐいたでしょうか？　多分、ぼぼ居ないだろうとは思いますがw

ということで、本日のお題は、軽くスルーしていた面白いネタとして、

Oracleでも、一般的に Bushy Join って言われているJoin Treeを生成することもできるのだ!

。。。というお話をしたいと思います。

Oracleのマニュアル( SQL Tuning Guide / Join - Oracle Database 23c )では、一応、Bushy Join Tree という記述をされているのですが、実際には、Zigzag Join Tree なんですよね。結合ツリーの図も実際の実行計画も。

一方、PostgreSQLでは、見間違えようながない Bushy Join Tree が生成されているのがわかります。
帰ってきた！標準はあるにはあるが癖の多いSQL #6 - Hash Joinの結合ツリーにも癖がでる

Oracleさんのマニュアルのリンク貼っても、リンク切れしちゃうので、いずれリンク切れしちゃう想定でマニュアルの図を手書きでw　（といっても、 Pagesで書いたのですが）を貼っておきますね。
なお、本エントリーの後半に参考になりそうなリンクを貼っておきました。（Oracleさんのマニュアルリンクよりはリンク切れし難いと信じてw）

Oracleでは Zigzag も Bushy Join Tree のように扱われてるかのうように見えちゃいますが、実は、Bushy Join Tree に分類される結合ツリーは別に存在していたりします。
最近のOracleだとあまり目にする機会は無いように思いますが。。。特に、11g以降は見た記憶はないです。。。初期のOracleだと比較的目にしていたような気もしますが。（思い出せない！　それぐらい昔ではないかと。。。）

では、さっそく、冒頭で紹介した帰ってきた！標準はあるにはあるが癖の多いSQL #6 - Hash Joinの結合ツリーにも癖がでるの該当部分を再掲して確認してみましょう！

再掲

Oracle Database

SCOTT@orclpdb1> @ora_sql_hj.sql 1 SELECT 2 /*+ 3 MONITOR 4 USE_HASH(t1 t2 t3 t4) 5 */ 6 t1.id 7 , t1.t1_c1 8 , t2.s_id 9 , t2.t2_c1 10 , t3.b_id 11 , t3.t3_c1 12 , t4.a_id 13 , t4.c_id 14 , t4.t4_c1 15 FROM 16 t1 17 INNER JOIN t2 18 ON 19 t1.id = t2.id 20 INNER JOIN t3 21 ON 22 t1.id = t3.id 23 INNER JOIN t4 24 ON 25* t1.id = t4.id ...略... SQL Plan Monitoring Details (Plan Hash Value=122725940) =================================================================================================================================================== | 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 | | | | 1 | +0 | 1 | 25000 | | | . | | | | 1 | HASH JOIN | | 25000 | 12 | 1 | +0 | 1 | 25000 | | | 1MB | | | | 2 | TABLE ACCESS FULL | T4 | 500 | 3 | 1 | +0 | 1 | 500 | 2 | 49152 | . | | | | 3 | HASH JOIN | | 500 | 9 | 1 | +0 | 1 | 500 | | | 1MB | | | | 4 | HASH JOIN | | 50 | 6 | 1 | +0 | 1 | 50 | | | 1MB | | | | 5 | TABLE ACCESS FULL | T1 | 10 | 3 | 1 | +0 | 1 | 10 | 2 | 49152 | . | | | | 6 | TABLE ACCESS FULL | T2 | 50 | 3 | 1 | +0 | 1 | 50 | 2 | 49152 | . | | | | 7 | TABLE ACCESS FULL | T3 | 100 | 3 | 1 | +0 | 1 | 100 | 2 | 49152 | . | | | ===================================================================================================================================================

ご覧のとおり、T1からT3までの結合はLeft Deep Join で、T4をRight Deep Joinで結合している、Zigzag Join Treeになっています（Oracleのマニュアルだと、Bushy Join Treeと記載されている結合ツリー）

では、PostgreSQLの Bushy Join Tree を再確認してみましょう。

PostgreSQL

perftestdb=> \! cat pg_sql_hj.sql explain (analyze) SELECT /*+ HashJoin(t1 t2 t3 t4) */ t1.id , t1.t1_c1 , t2.s_id , t2.t2_c1 , t3.b_id , t3.t3_c1 , t4.a_id , t4.c_id , t4.t4_c1 FROM t1 INNER JOIN t2 ON t1.id = t2.id INNER JOIN t3 ON t1.id = t3.id INNER JOIN t4 ON t1.id = t4.id ; perftestdb=> \i pg_sql_hj.sql QUERY PLAN ----------------------------------------------------------------------------------------------------------------------- Id=1 Hash Join (cost=17.48..309.84 rows=25000 width=36) (actual time=3.405..10.466 rows=25000 loops=1) Hash Cond: (t1.id = t2.id) Id=2 -> Hash Join (cost=1.23..11.09 rows=500 width=24) (actual time=1.696..1.989 rows=500 loops=1) Hash Cond: (t4.id = t1.id) Id=3 -> Seq Scan on t4 (cost=0.00..8.00 rows=500 width=16) (actual time=0.907..0.993 rows=500 loops=1) Id=4 -> Hash (cost=1.10..1.10 rows=10 width=8) (actual time=0.721..0.722 rows=10 loops=1) Buckets: 1024 Batches: 1 Memory Usage: 9kB Id=5 -> Seq Scan on t1 (cost=0.00..1.10 rows=10 width=8) (actual time=0.705..0.707 rows=10 loops=1) Id=6 -> Hash (cost=10.00..10.00 rows=500 width=24) (actual time=1.687..1.687 rows=500 loops=1) Buckets: 1024 Batches: 1 Memory Usage: 36kB Id=7 -> Hash Join (cost=2.12..10.00 rows=500 width=24) (actual time=1.400..1.554 rows=500 loops=1) Hash Cond: (t3.id = t2.id)) Id=8 -> Seq Scan on t3 (cost=0.00..2.00 rows=100 width=12) (actual time=0.701..0.712 rows=100 loops=1) Id=9 -> Hash (cost=1.50..1.50 rows=50 width=12) (actual time=0.679..0.680 rows=50 loops=1) Buckets: 1024 Batches: 1 Memory Usage: 11kB Id=10 -> Seq Scan on t2 (cost=0.00..1.50 rows=50 width=12) (actual time=0.648..0.656 rows=50 loops=1)

上記はどちらも、HASH JOINをヒントで強制しているだけですが、それでも、オプティマイザの癖というか特徴は現れています。
ZigzagとBushyの違いと一口に言っちゃうと、簡単過ぎますが。

以下、SQL文の結合条件部分を抜粋してみました。赤字部分を注意深く見てください。

FROM t1 INNER JOIN t2 ON t1.id = t2.id INNER JOIN t3 ON t1.id = t3.id INNER JOIN t4 ON t1.id = t4.id

PostgreSQLのActual Planに見やすいよう、Idを振ってみました。
Id=7でINNER JOINしていますが、何が気づきませんか？　特に、PostgreSQLの Bushy Join Tree で起きている変化に。。。（前述したSQLの赤字部分に注目）

私が実行したSQL文の結合条件と異なっている部分があります！　(内部でオプティマイザというかプランナが最適化のために書き換えた部分です)　
結合条件を書き換え t1とt3ではなく、t2とt3を結合し、Bushy Join Tree で Hash Join されていますよね！！！！！(同意なのが自明なので書き換えているわけです。 Bushy Join Tree にするために)

一方、OracleもPostgreSQLとおなじタイプの Bushy Join Tree になることもあるのですが、このような書き換えは起こらなかったはず。。。

念の為、Oracleの結合条件が変化していないことをこの時点で確認しておきましょう。
PostgreSQL同様に、赤字部分に注目してください。SQLに記述されている結合条件のまま。

1 EXPLAIN PLAN FOR 2 SELECT 3 /*+ 4 MONITOR 5 USE_HASH(t1 t2 t3 t4) 6 */ 7 t1.id 8 , t1.t1_c1 9 , t2.s_id 10 , t2.t2_c1 11 , t3.b_id 12 , t3.t3_c1 13 , t4.a_id 14 , t4.c_id 15 , t4.t4_c1 16 FROM 17 t1 18 INNER JOIN t2 19 ON 20 t1.id = t2.id 21 INNER JOIN t3 22 ON 23 t1.id = t3.id 24 INNER JOIN t4 25 ON 26* t1.id = t4.id 解析されました。経過: 00:00:00.02 PLAN_TABLE_OUTPUT ----------------------------------------------------------------------------- Plan hash value: 122725940 ----------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ----------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 25000 | 878K| 12 (0)| 00:00:01 | |* 1 | HASH JOIN | | 25000 | 878K| 12 (0)| 00:00:01 | | 2 | TABLE ACCESS FULL | T4 | 500 | 6000 | 3 (0)| 00:00:01 | |* 3 | HASH JOIN | | 500 | 12000 | 9 (0)| 00:00:01 | |* 4 | HASH JOIN | | 50 | 750 | 6 (0)| 00:00:01 | | 5 | TABLE ACCESS FULL| T1 | 10 | 60 | 3 (0)| 00:00:01 | | 6 | TABLE ACCESS FULL| T2 | 50 | 450 | 3 (0)| 00:00:01 | | 7 | TABLE ACCESS FULL | T3 | 100 | 900 | 3 (0)| 00:00:01 | ----------------------------------------------------------------------------- Predicate Information (identified by operation id): --------------------------------------------------- 1 - access("T1"."ID"="T4"."ID") 3 - access("T1"."ID"="T3"."ID") 4 - access("T1"."ID"="T2"."ID")

では、Oracleには、PostgreSQLで見られる Bushy Join Tree は存在しないのか？　

冒頭でも書きましたが、存在します！

BUSHY_JOINヒントまでありますw

ほぼ、お目にかかることは無くなった気がしますが。。。最近は。。

PostgreSQLとおなじ実行計画になるように、ゴニョゴニョしてみましたw （何が起こるでしょう。。。w）

なお、LEADINGヒントで、オプティマイザが内部的に生成する Bushy Join 向けのインラインビュー（ VW_BUSHY_0C91E486 ）を指定していますが、このインラインビュー名は事前に確認することはできないので、一度、インラインビューを生成させインラインビュー名を確認した後に指定しています。
（内部的に生成されるインラインビュー名称なので、手順としてはそれしかありません！）

BUSHY_JOINヒント、なんとなく、pg_hint_plan で使うような構文に似てますよねw　Oracleで ZigZag Join Tree (Oracleのマニュアルだと Zigzag な Tree だけど、Bushy Join となっているので注意)になっている状態を BUSHY_JOINヒントであえて、Bushy Join に書き換えることは無いと思いますが、使い方を理解していると、何かの役になる、、、かも。（なるとは言ってないw）

SCOTT@orclpdb1> @ora_sql_hj_bushy_join 1 SELECT 2 /*+ 3 MONITOR 4 LEADING(VW_BUSHY_0C91E486) 5 USE_HASH(t2 t3) 6 USE_HASH(t1 t4) 7 BUSHY_JOIN((t2 t3) (t1 t4)) 8 */ 9 t1.id 10 , t1.t1_c1 11 , t2.s_id 12 , t2.t2_c1 13 , t3.b_id 14 , t3.t3_c1 15 , t4.a_id 16 , t4.c_id 17 , t4.t4_c1 18 FROM 19 t1 20 INNER JOIN t2 21 ON 22 t1.id = t2.id 23 INNER JOIN t3 24 ON 25 t1.id = t3.id 26 INNER JOIN t4 27 ON 28* t1.id = t4.id DBMS_SQLTUNE.REPORT_SQL_MONITOR(SQL_ID=>'',TYPE=>'TEXT') ------------------------------------------------------------------------------------- SQL Monitoring Report ...略... SQL Plan Monitoring Details (Plan Hash Value=3887185) =================================================================================================================================================== | 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 | 25000 | . | | | | 1 | HASH JOIN | | 250K | 80 | 3 | +0 | 1 | 25000 | 2MB | | | | 2 | VIEW | VW_BUSHY_0C91E486 | 5000 | 72 | 1 | +0 | 1 | 5000 | . | | | | 3 | MERGE JOIN CARTESIAN | | 5000 | 72 | 1 | +0 | 1 | 5000 | . | | | | 4 | TABLE ACCESS FULL | T2 | 50 | 3 | 1 | +0 | 1 | 50 | . | | | | 5 | BUFFER SORT | | 100 | 69 | 1 | +0 | 50 | 5000 | 6144 | | | | 6 | TABLE ACCESS FULL | T3 | 100 | 1 | 1 | +0 | 1 | 100 | . | | | | 7 | VIEW | VW_BUSHY_CF941F82 | 500 | 6 | 3 | +0 | 1 | 500 | . | | | | 8 | HASH JOIN | | 500 | 6 | 3 | +0 | 1 | 500 | 1MB | | | | 9 | TABLE ACCESS FULL | T1 | 10 | 3 | 1 | +0 | 1 | 10 | . | | | | 10 | TABLE ACCESS FULL | T4 | 500 | 3 | 3 | +0 | 1 | 500 | . | | | ===================================================================================================================================================

PostgreSQLのように結合条件を書き換えてくれるまでは行わないようですね。Oracleのオプティマイザでは。
MERGE JOIN CARTESIAN となって、直積が発生してしまいました。PostgreSQLのように結合条件を書き換えていない結果として、結合条件の無い結合の強制となってしまった結果、直積が発生したわけです。

であれば、オリジナルの結合条件を書き換えて、それっぽくなるようにしてみましょう！
PostgreSQLのプランナのように結合条件を書き換えて再実行！！。

おお！
思い通りの実行計画になりました！

このような箇所でもオプティマイザの特徴は現れるので注意したいですね。Oracleでこの形にしたくなることは無いとは思いますけども。

ちなみに、Oracleのオプティマイザが内部的に、インラインビューを作る場合、どうやらネーミングルールがあるようで（マニュアルには記載されていないですけどもw）
VW_BUSHY_xxxxxxx となっている場合は、Bushy Join を行うためのインラインビュー名であるということは知られています
（知らない方もおおいかもしれませんが。Internal Views / Oracle Scratchpad by Jonathan Lewisあたりでそこそこまとめられていますが、Bushy Joinのためのはリストされてないですが、知らなくても困らないとは思います。OracleのBusy Join自体が現状はかなりレアな存在なので）

1 SELECT 2 /*+ 3 MONITOR 4 LEADING(VW_BUSHY_0C91E486) 5 USE_HASH(t2 t3) 6 USE_HASH(t1 t4) 7 BUSHY_JOIN((t2 t3) (t1 t4)) 8 */ 9 t1.id 10 , t1.t1_c1 11 , t2.s_id 12 , t2.t2_c1 13 , t3.b_id 14 , t3.t3_c1 15 , t4.a_id 16 , t4.c_id 17 , t4.t4_c1 18 FROM 19 t1 20 INNER JOIN t2 21 ON 22 t1.id = t2.id 23 INNER JOIN t3 24 ON 25 t2.id = t3.id 26 INNER JOIN t4 27 ON 28* t1.id = t4.id DBMS_SQLTUNE.REPORT_SQL_MONITOR(SQL_ID=>'',TYPE=>'TEXT') ---------------------------------------------------------------------------------------------------- SQL Monitoring Report SQL Text ...略... SQL Plan Monitoring Details (Plan Hash Value=400336061) ================================================================================================================================================= | 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 | 25000 | . | | | | 1 | HASH JOIN | | 25000 | 12 | 3 | +0 | 1 | 25000 | 1MB | | | | 2 | VIEW | VW_BUSHY_0C91E486 | 500 | 6 | 1 | +0 | 1 | 500 | . | | | | 3 | HASH JOIN | | 500 | 6 | 1 | +0 | 1 | 500 | 1MB | | | | 4 | TABLE ACCESS FULL | T2 | 50 | 3 | 1 | +0 | 1 | 50 | . | | | | 5 | TABLE ACCESS FULL | T3 | 100 | 3 | 1 | +0 | 1 | 100 | . | | | | 6 | VIEW | VW_BUSHY_CF941F82 | 500 | 6 | 3 | +0 | 1 | 500 | . | | | | 7 | HASH JOIN | | 500 | 6 | 3 | +0 | 1 | 500 | 1MB | | | | 8 | TABLE ACCESS FULL | T1 | 10 | 3 | 1 | +0 | 1 | 10 | . | | | | 9 | TABLE ACCESS FULL | T4 | 500 | 3 | 3 | +0 | 1 | 500 | . | | | =================================================================================================================================================

Oracleでも、一般的に言われている Bushy Join Tree へ持っていくことはできるよ。あえて使わないけど、というかこれに持っていきたい時って想像できないわけですけどもね。Zigzag Join Treeで対応しちゃうだろうから。。。

ということで、Oracleでかなり久々に見た（無理やりですけどもw）、Bushy Join Tree　もあるんだよ！　の巻。完。。

今回使ったスクリプト

Oracle(PostgreSQLと同じ実行計画になるよう結合条件を書き換え,内部生成されるインラインビュー名称を確認した上で、LEADINGで結合順を聖書したもの)

SCOTT@orclpdb1> ! cat ora_sql_hj_bushy_join.sql SELECT /*+ MONITOR LEADING(VW_BUSHY_0C91E486) USE_HASH(t2 t3) USE_HASH(t1 t4) BUSHY_JOIN((t2 t3) (t1 t4)) */ t1.id , t1.t1_c1 , t2.s_id , t2.t2_c1 , t3.b_id , t3.t3_c1 , t4.a_id , t4.c_id , t4.t4_c1 FROM t1 INNER JOIN t2 ON t1.id = t2.id INNER JOIN t3 ON t2.id = t3.id INNER JOIN t4 ON t1.id = t4.id . l set tab off set termout off / set termout on @show_realtime_sql

PostgreSQL

perftestdb=> \! cat pg_sql_hj.sql explain (analyze) SELECT /*+ HashJoin(t1 t2 t3 t4) */ t1.id , t1.t1_c1 , t2.s_id , t2.t2_c1 , t3.b_id , t3.t3_c1 , t4.a_id , t4.c_id , t4.t4_c1 FROM t1 INNER JOIN t2 ON t1.id = t2.id INNER JOIN t3 ON t1.id = t3.id INNER JOIN t4 ON t1.id = t4.id ;

なお、テーブル、索引、登録したデータなどは、過去のエントリーを参照ください。
帰ってきた！標準はあるにはあるが癖の多いSQL #6 - Hash Joinの結合ツリーにも癖がでる

参考)

Trees

https://resources.mpi-inf.mpg.de/departments/d5/teaching/ss09/queryoptimization/lecture4.pdf

Classification of Join Ordering Problems

https://resources.mpi-inf.mpg.de/departments/d5/teaching/ss09/queryoptimization/lecture5.pdf

Specialized Course "Query Optimization"

https://resources.mpi-inf.mpg.de/departments/d5/teaching/ss09/queryoptimization/

では、また、面白そうなネタを見つけたら書こうと思います。:)

投稿日時 2024年3月25日 (月) 20時55分 Oracle, チューニング, SQL, PostgreSQL, パフォーマンス | 固定リンク | 0 | コメント (0)

2024年2月21日 (水)

Top N Queryの弱点と対策

久々にSQLチューニングネタです。しかも、真面目な感じのタイトルw

11年前に、rownum使って満足しちゃってると.....おまけのおまけ FETCH FIRST N ROWS ONLY編という、rownumや、fetch first N rows only でTOP N rows を取得する際に、忘れがちな問題として、TOP N rowsの行数未満（空振りを含む）の場合、全行読み込んでしまうので、絞り込みしにくいような検索で、rownumやfetch first N rowsで全表走査を回避したつもりになっていると、痛い目にあうよ！

というネタを書いていました。

この大切な癖、忘れちゃってませんか？　大変なことになりますよ。。ということで、再びこのネタを書くことにしました。

Oracle Database 21cを使っていますが11年も昔から変わったところはないので、塩漬けしている古〜いオラクルでも楽しめる内容にしてありますw

まず、今日の準備から

SCOTT@orclpdb1> @fullscanfulness 表が削除されました。経過: 00:00:01.31 1 create table fullscanfulness 2 ( 3 id number not null 4 ,dummy_text varchar2(4000) 5 ,hoge_flg number(1) not null 6 ,constraint pk_fullscanfulness primary key(id) 7* ) 表が作成されました。経過: 00:00:00.29 1 begin 2 for i in 1..100000 loop 3 insert into fullscanfulness values(i,lpad('*',3500,'*'),0); 4 if mod(i,100)=0 then commit; end if; 5 end loop; 6* end; PL/SQLプロシージャが正常に完了しました。経過: 00:00:22.45 1* insert into fullscanfulness values(100001,lpad('*',3500,'*'),1) 1行が作成されました。経過: 00:00:00.01 コミットが完了しました。経過: 00:00:00.01 PL/SQLプロシージャが正常に完了しました。経過: 00:00:03.53 1* select count(1) from fullscanfulness COUNT(1) ---------- 100001 経過: 00:00:00.01 SEGMENT_NAME BLOCKS ------------------------------ ---------- FULLSCANFULNESS 51200 PK_FULLSCANFULNESS 256 経過: 00:00:00.19

と、クセのありそうな、なんとなく、見る機会の多そうなフラグ列のある表に主キーだけがある状態です。
なお、最後のデータ id=100001だけフラグ列が　1　になっています。最後の行なので、物理的にも最後尾にしてあります（意図的に）

フラグ＝１になっている行が表どの位置にあるかイメージ図で書くと以下のような感じ

表セグメントのブロック数は上記のとおりですが、まずは、実際にtable full scan させてみましょう　physical reads/ consistent gets からもわかるように綺麗にw 読み込まれてます！

SCOTT@orclpdb1> set autot trace exp stat SCOTT@orclpdb1> @fullscanfulness2 1 SELECT 2 id 3 ,substr(dummy_text,1,10) as dummy 4 FROM 5* fullscanfulness 100001行が選択されました。経過: 00:00:03.34 実行計画 ---------------------------------------------------------- Plan hash value: 1963277787 ------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 100K| 334M| 13807 (1)| 00:00:01 | | 1 | TABLE ACCESS FULL| FULLSCANFULNESS | 100K| 334M| 13807 (1)| 00:00:01 | ------------------------------------------------------------------------------------- 統計 ---------------------------------------------------------- 137 recursive calls 0 db block gets 53724 consistent gets 50133 physical reads 0 redo size 2322822 bytes sent via SQL*Net to client 73599 bytes received via SQL*Net from client 6668 SQL*Net roundtrips to/from client 27 sorts (memory) 0 sorts (disk) 100001 rows processed

では、早速、本題ですw

rownumでも良いのですが、fetch first N rows onlyで WHERE句なし、つまり、全表走査上等な状態ですが、10行取得だけ。つまり、table full scanではありますが、10行取得したところまでで終了させます。
WINDOW NOSORT STOPKEYというオペレーションが増加しています。rownumだと、STOPKEYだけですよね。ここがrownumとは違うところですが、動作としては行数をカウントして、制限値に達したところで走査終了とするためのオペレーションが追加されています。
これで、table full scanであっても、全データブロックを読み取ることはないですよね。みなさんご存知の通りです。 consistent gets = 8 なので、 8 ブロックしか読みこんでません。

ここまではいいですよね。

1 SELECT 2 id 3 ,substr(dummy_text,1,10) as dummy 4 FROM 5 fullscanfulness 6* FETCH FIRST 10 ROWS ONLY 10行が選択されました。経過: 00:00:00.00 実行計画 ---------------------------------------------------------- Plan hash value: 1910161288 ------------------------------------------------------------------------------------------ | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ------------------------------------------------------------------------------------------ | 0 | SELECT STATEMENT | | 10 | 480 | 3 (0)| 00:00:01 | |* 1 | VIEW | | 10 | 480 | 3 (0)| 00:00:01 | |* 2 | WINDOW NOSORT STOPKEY| | 10 | 35060 | 3 (0)| 00:00:01 | | 3 | TABLE ACCESS FULL | FULLSCANFULNESS | 10 | 35060 | 3 (0)| 00:00:01 | ------------------------------------------------------------------------------------------ Predicate Information (identified by operation id): --------------------------------------------------- 1 - filter("from$_subquery$_002"."rowlimit_$$_rownumber"<=10) 2 - filter(ROW_NUMBER() OVER ( ORDER BY NULL )<=10) 統計 ---------------------------------------------------------- 1 recursive calls 0 db block gets 8 consistent gets 0 physical reads 0 redo size 800 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) 10 rows processed

では、次の例

WHERE句で条件を指定しておきます。なかなか渋い検索条件ですよね。一般的に索引は作成しにくいですw。　
TOP N クエリーなので一つ前の例のように table full scanは回避できるは。。。。ですよね。

想定通り、必要な行数取得後に、table full scanは止まって必要最小限の表データブロックだけアクセスしています。　いいじゃないですか。。これで。

1 SELECT 2 id 3 ,substr(dummy_text,1,10) as dummy 4 FROM 5 fullscanfulness 6 WHERE 7 hoge_flg = 0 8* FETCH FIRST 10 ROWS ONLY 10行が選択されました。経過: 00:00:00.01 実行計画 ---------------------------------------------------------- Plan hash value: 1910161288 ------------------------------------------------------------------------------------------ | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ------------------------------------------------------------------------------------------ | 0 | SELECT STATEMENT | | 10 | 480 | 5 (0)| 00:00:01 | |* 1 | VIEW | | 10 | 480 | 5 (0)| 00:00:01 | |* 2 | WINDOW NOSORT STOPKEY| | 10 | 35080 | 5 (0)| 00:00:01 | |* 3 | TABLE ACCESS FULL | FULLSCANFULNESS | 10 | 35080 | 5 (0)| 00:00:01 | ------------------------------------------------------------------------------------------ Predicate Information (identified by operation id): --------------------------------------------------- 1 - filter("from$_subquery$_002"."rowlimit_$$_rownumber"<=10) 2 - filter(ROW_NUMBER() OVER ( ORDER BY NULL )<=10) 3 - filter("HOGE_FLG"=0) 統計 ---------------------------------------------------------- 1 recursive calls 0 db block gets 8 consistent gets 0 physical reads 0 redo size 800 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) 10 rows processed

では、Top N クエリーをやめて、WHERE条件だけ指定します。 hoge_flg = 1　である、表データブロックの最後のブロック格納されている行を１行取得してみましょう。

hoge_flg列には索引はないので、table full scanしかできません。当然、全データブロックを読み込み（物理読み込み）して1行取得しています。これも想定通りです。Top N クエリーで制限していないので最後まで読み込んでしまいますよね。

1 SELECT 2 id 3 ,substr(dummy_text,1,10) as dummy 4 FROM 5 fullscanfulness 6 WHERE 7* hoge_flg = 1 経過: 00:00:00.19 実行計画 ---------------------------------------------------------- Plan hash value: 1963277787 ------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 50001 | 167M| 13807 (1)| 00:00:01 | |* 1 | TABLE ACCESS FULL| FULLSCANFULNESS | 50001 | 167M| 13807 (1)| 00:00:01 | ------------------------------------------------------------------------------------- Predicate Information (identified by operation id): --------------------------------------------------- 1 - filter("HOGE_FLG"=1) 統計 ---------------------------------------------------------- 1 recursive calls 0 db block gets 50144 consistent gets 50133 physical reads 0 redo size 673 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

さて、次が問題です。

一つ前の例と同じWHERE条件で、FETCH FIRST 10 ROWS ONLYでTop N クエリーしてみましょう。どうなったかわかりますか？

実行計画上は、これまでと同じく、 table full scanで、STOPKEYによる途中停止オペレーションも含まれていますが、、、、全データブロックを読み込んでしまいました。

なぜでしょう？

理由は、Top N クエリーの条件に指定された行数に満たない行数しか存在しなかったから、ですね！。　
これが rownum / fetch first N rows onlyの弱点なのです。条件に満たないことが確定するのは、table full scanで全データブロックを読み込み終わるまで確定しません。
最後まで読み切ってしまうんです。途中で止まらないのです。。。

大問題ですね！これw（ワロてますが）

僕たちの Top N クエリー、ダメじゃん。みたいな。（そんなことはないですが、考慮が漏れているだけなのでw）

1 SELECT 2 id 3 ,substr(dummy_text,1,10) as dummy 4 FROM 5 fullscanfulness 6 WHERE 7 hoge_flg = 1 8* FETCH FIRST 10 ROWS ONLY 経過: 00:00:00.34 実行計画 ---------------------------------------------------------- Plan hash value: 1910161288 ------------------------------------------------------------------------------------------ | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ------------------------------------------------------------------------------------------ | 0 | SELECT STATEMENT | | 10 | 480 | 5 (0)| 00:00:01 | |* 1 | VIEW | | 10 | 480 | 5 (0)| 00:00:01 | |* 2 | WINDOW NOSORT STOPKEY| | 10 | 35080 | 5 (0)| 00:00:01 | |* 3 | TABLE ACCESS FULL | FULLSCANFULNESS | 10 | 35080 | 5 (0)| 00:00:01 | ------------------------------------------------------------------------------------------ Predicate Information (identified by operation id): --------------------------------------------------- 1 - filter("from$_subquery$_002"."rowlimit_$$_rownumber"<=10) 2 - filter(ROW_NUMBER() OVER ( ORDER BY NULL )<=10) 3 - filter("HOGE_FLG"=1) 統計 ---------------------------------------------------------- 1 recursive calls 0 db block gets 50153 consistent gets 50082 physical reads 0 redo size 673 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

でも、もう一つ、残念なお知らせ。というか例を。

FETCH FIRST N ROWSの条件に満たなかったから、全データブロックを読んでしまったわけだから、条件を満たせば、絶対、俺たちの Top N クエリーは、table full scanの途中で止まってくれるはずだ！

そんなことはないですねw

以下の例では、FETCH FISRT N ROWSの条件を満たせてはいますが、ヒットした1行のデータは、運の悪いことに、全表データブロック中、最も最後のブロックに存在しています。
したがって、索引のないこの表では、最後のデータブロックを読み込むまで、FETCH FIRST N ROWSの条件は満たせないため、全データブロックを読み込むしかなくなっています。残念！
（対象行を最後のデータブロックになるような小細工をしていたのはこれを見せたかったわけです）

1 SELECT 2 id 3 ,substr(dummy_text,1,10) as dummy 4 FROM 5 fullscanfulness 6 WHERE 7 hoge_flg = 1 8* FETCH FIRST 1 ROWS ONLY 経過: 00:00:00.33 実行計画 ---------------------------------------------------------- Plan hash value: 1910161288 ------------------------------------------------------------------------------------------ | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ------------------------------------------------------------------------------------------ | 0 | SELECT STATEMENT | | 1 | 48 | 2 (0)| 00:00:01 | |* 1 | VIEW | | 1 | 48 | 2 (0)| 00:00:01 | |* 2 | WINDOW NOSORT STOPKEY| | 1 | 3508 | 2 (0)| 00:00:01 | |* 3 | TABLE ACCESS FULL | FULLSCANFULNESS | 1 | 3508 | 2 (0)| 00:00:01 | ------------------------------------------------------------------------------------------ Predicate Information (identified by operation id): --------------------------------------------------- 1 - filter("from$_subquery$_002"."rowlimit_$$_rownumber"<=1) 2 - filter(ROW_NUMBER() OVER ( ORDER BY NULL )<=1) 3 - filter("HOGE_FLG"=1) 統計 ---------------------------------------------------------- 1 recursive calls 0 db block gets 50124 consistent gets 50053 physical reads 0 redo size 673 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

さらに、Top N クエリーの弱点を再確認してみましょう。

今度は、空振りする検索条件です。対象データは０件です。そうでう。ここまでついて来れた皆さんなら、もうお気づきだと思いますが。空振りする検索条件だと、０件であることが確定するのはどういう状態になった時でしょうか？

そうです。　変なマウントおじさんが登場してきた時（違w

ではなくて、全データブロックを読み終えた時ですね。　table full scan　は Top N クエリーだけでは止まれないケースが存在するんですよ。みなさん！

1 SELECT 2 id 3 ,substr(dummy_text,1,10) as dummy 4 FROM 5 fullscanfulness 6 WHERE 7 hoge_flg = 9 8* FETCH FIRST 1 ROWS ONLY レコードが選択されませんでした。経過: 00:00:00.20 実行計画 ---------------------------------------------------------- Plan hash value: 1910161288 ------------------------------------------------------------------------------------------ | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ------------------------------------------------------------------------------------------ | 0 | SELECT STATEMENT | | 1 | 48 | 13807 (1)| 00:00:01 | |* 1 | VIEW | | 1 | 48 | 13807 (1)| 00:00:01 | |* 2 | WINDOW NOSORT STOPKEY| | 1 | 3508 | 13807 (1)| 00:00:01 | |* 3 | TABLE ACCESS FULL | FULLSCANFULNESS | 1 | 3508 | 13807 (1)| 00:00:01 | ------------------------------------------------------------------------------------------ Predicate Information (identified by operation id): --------------------------------------------------- 1 - filter("from$_subquery$_002"."rowlimit_$$_rownumber"<=1) 2 - filter(ROW_NUMBER() OVER ( ORDER BY NULL )<=1) 3 - filter("HOGE_FLG"=9) 統計 ---------------------------------------------------------- 1 recursive calls 0 db block gets 50145 consistent gets 50133 physical reads 0 redo size 453 bytes sent via SQL*Net to client 41 bytes received via SQL*Net from client 1 SQL*Net roundtrips to/from client 0 sorts (memory) 0 sorts (disk) 0 rows processed

では、追加の確認、Top N クエリーの条件が早期に満たされれば、table full scanは回避できますよね。という念の為の確認です。
以下では、表の先頭ブロックに Top N クエリーの条件を満足させるためのデータを用意しました。

この状態であれば、table full scanは止められるはずです。（常にこんな状態になることは稀なわけですけども）

結果は見ての通り、table full scanは途中で止まりました。当然と言えば当然ですが。

1* update fullscanfulness set hoge_flg = 1 where id between 1 and 9 9行が更新されました。経過: 00:00:00.02 コミットが完了しました。経過: 00:00:00.00 1* select id from fullscanfulness where hoge_flg=1 ID ---------- 3 4 5 6 7 8 9 1 2 100001 10行が選択されました。経過: 00:00:00.21 1 SELECT 2 id 3 ,substr(dummy_text,1,10) as dummy 4 FROM 5 fullscanfulness 6 WHERE 7 hoge_flg = 1 8* FETCH FIRST 1 ROWS ONLY 経過: 00:00:00.01 実行計画 ---------------------------------------------------------- Plan hash value: 1910161288 ------------------------------------------------------------------------------------------ | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ------------------------------------------------------------------------------------------ | 0 | SELECT STATEMENT | | 1 | 48 | 2 (0)| 00:00:01 | |* 1 | VIEW | | 1 | 48 | 2 (0)| 00:00:01 | |* 2 | WINDOW NOSORT STOPKEY| | 1 | 3508 | 2 (0)| 00:00:01 | |* 3 | TABLE ACCESS FULL | FULLSCANFULNESS | 1 | 3508 | 2 (0)| 00:00:01 | ------------------------------------------------------------------------------------------ Predicate Information (identified by operation id): --------------------------------------------------- 1 - filter("from$_subquery$_002"."rowlimit_$$_rownumber"<=1) 2 - filter(ROW_NUMBER() OVER ( ORDER BY NULL )<=1) 3 - filter("HOGE_FLG"=1) 統計 ---------------------------------------------------------- 1 recursive calls 0 db block gets 3 consistent gets 0 physical reads 0 redo size 671 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

では、事前準備で、表の先頭ブロックには9行だけ WHERE条件に該当するデータを置きました。ただし、 Top N クエリーの条件は満たせません。
Top N クエリーの条件を満たすための最後のピースは、表データの最後尾のブロックに置いてあります。

結果は、またまた、 Top N クエリーの効果で、table full scanが途中で止まることはできず、全データブロックを読み込んでしまいました。辛いですね（この状況）

1 SELECT 2 id 3 ,substr(dummy_text,1,10) as dummy 4 FROM 5 fullscanfulness 6 WHERE 7 hoge_flg = 1 8* FETCH FIRST 10 ROWS ONLY 10行が選択されました。経過: 00:00:00.34 実行計画 ---------------------------------------------------------- Plan hash value: 1910161288 ------------------------------------------------------------------------------------------ | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ------------------------------------------------------------------------------------------ | 0 | SELECT STATEMENT | | 10 | 480 | 5 (0)| 00:00:01 | |* 1 | VIEW | | 10 | 480 | 5 (0)| 00:00:01 | |* 2 | WINDOW NOSORT STOPKEY| | 10 | 35080 | 5 (0)| 00:00:01 | |* 3 | TABLE ACCESS FULL | FULLSCANFULNESS | 10 | 35080 | 5 (0)| 00:00:01 | ------------------------------------------------------------------------------------------ Predicate Information (identified by operation id): --------------------------------------------------- 1 - filter("from$_subquery$_002"."rowlimit_$$_rownumber"<=10) 2 - filter(ROW_NUMBER() OVER ( ORDER BY NULL )<=10) 3 - filter("HOGE_FLG"=1) 統計 ---------------------------------------------------------- 1 recursive calls 0 db block gets 50125 consistent gets 50053 physical reads 0 redo size 802 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) 10 rows processed

次の例では、表データの最後尾のデータブロックに置いたデータのフラグを0にして、WHERE条件を満たす行を 9行にしました。
これだと、表データの先頭にある数ブロックだけでは、 Top N クエリーの条件を満たせません。

結果は、見るまでもなく（見てますがw）、表の全データブロックを読み込むまで終了できません。

1* update fullscanfulness set hoge_flg = 0 where id = 100001 1行が更新されました。経過: 00:00:00.00 コミットが完了しました。経過: 00:00:00.01 1 SELECT 2 id 3 ,substr(dummy_text,1,10) as dummy 4 FROM 5 fullscanfulness 6 WHERE 7 hoge_flg = 1 8* FETCH FIRST 10 ROWS ONLY 9行が選択されました。経過: 00:00:00.34 実行計画 ---------------------------------------------------------- Plan hash value: 1910161288 ------------------------------------------------------------------------------------------ | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ------------------------------------------------------------------------------------------ | 0 | SELECT STATEMENT | | 10 | 480 | 5 (0)| 00:00:01 | |* 1 | VIEW | | 10 | 480 | 5 (0)| 00:00:01 | |* 2 | WINDOW NOSORT STOPKEY| | 10 | 35080 | 5 (0)| 00:00:01 | |* 3 | TABLE ACCESS FULL | FULLSCANFULNESS | 10 | 35080 | 5 (0)| 00:00:01 | ------------------------------------------------------------------------------------------ Predicate Information (identified by operation id): --------------------------------------------------- 1 - filter("from$_subquery$_002"."rowlimit_$$_rownumber"<=10) 2 - filter(ROW_NUMBER() OVER ( ORDER BY NULL )<=10) 3 - filter("HOGE_FLG"=1) 統計 ---------------------------------------------------------- 0 recursive calls 0 db block gets 50154 consistent gets 50082 physical reads 0 redo size 792 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) 9 rows processed

では、いよいよ。Top N クエリーの弱点に対する対策には何が効くのかみていきましょう。あれしかないですけどもw

一般的な状況だと、ほぼ、作成したくない索引を作ってみます。この状況では仕方ないですw（意図的ですがw）

1* create index ix_fullscanfulness on fullscanfulness(hoge_flg) 索引が作成されました。経過: 00:00:00.44

念の為、索引を強制するヒントを追加しています。

条件は一つ前の例と同じです。違いはフラグ列に作成した単一列索引だけです。

結果は、ご覧の通り。　狙い通り、 Top N クエリーの条件は満たせていませんが、WHERE条件に一致する行だけを索引経由で取得することで、 table full scanを完全に回避しています。　これが Top N クエリーの弱点回避への最後の希望です：）
状況次第ですが、かなり、何この索引と突っ込まれる系の索引を作成しなければいけなくなることも多いです。ですが、これしかないのです。

1 SELECT 2 /*+ 3 INDEX(fullscanfulness ix_fullscanfulness) 4 */ 5 id 6 ,substr(dummy_text,1,10) as dummy 7 FROM 8 fullscanfulness 9 WHERE 10 hoge_flg = 1 11* FETCH FIRST 10 ROWS ONLY 9行が選択されました。経過: 00:00:00.01 実行計画 ---------------------------------------------------------- Plan hash value: 3248696394 ---------------------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ---------------------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 10 | 480 | 7 (0)| 00:00:01 | |* 1 | VIEW | | 10 | 480 | 7 (0)| 00:00:01 | |* 2 | WINDOW NOSORT STOPKEY | | 10 | 35080 | 7 (0)| 00:00:01 | | 3 | TABLE ACCESS BY INDEX ROWID| FULLSCANFULNESS | 10 | 35080 | 7 (0)| 00:00:01 | |* 4 | INDEX RANGE SCAN | IX_FULLSCANFULNESS | 50001 | | 1 (0)| 00:00:01 | ---------------------------------------------------------------------------------------------------- Predicate Information (identified by operation id): --------------------------------------------------- 1 - filter("from$_subquery$_002"."rowlimit_$$_rownumber"<=10) 2 - filter(ROW_NUMBER() OVER ( ORDER BY NULL )<=10) 4 - access("HOGE_FLG"=1) 統計 ---------------------------------------------------------- 1 recursive calls 0 db block gets 9 consistent gets 1 physical reads 0 redo size 792 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) 9 rows processed

さらに、 Top N クエリーの弱点回避の効果を確認してみましょう。

次は、Top N クエリーの条件は満たせていますが、WHERE条件を満たせる行が、表データブロックの先頭と最後尾に存在しているケースです。

表の先頭ブロックに9行の該当データがあるので、最後尾のデータブロックにある行を更新して置きます。索引が存在しない状態では、table full scanを途中で止めることはできませんでしたが、どうなりましか？

止まっていますよね！

1* update fullscanfulness set hoge_flg = 1 where id = 100001 1行が更新されました。経過: 00:00:00.00 コミットが完了しました。経過: 00:00:00.01 1 SELECT 2 /*+ 3 INDEX(fullscanfulness ix_fullscanfulness) 4 */ 5 id 6 ,substr(dummy_text,1,10) as dummy 7 FROM 8 fullscanfulness 9 WHERE 10 hoge_flg = 1 11* FETCH FIRST 10 ROWS ONLY 10行が選択されました。経過: 00:00:00.00 実行計画 ---------------------------------------------------------- Plan hash value: 3248696394 ---------------------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ---------------------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 10 | 480 | 7 (0)| 00:00:01 | |* 1 | VIEW | | 10 | 480 | 7 (0)| 00:00:01 | |* 2 | WINDOW NOSORT STOPKEY | | 10 | 35080 | 7 (0)| 00:00:01 | | 3 | TABLE ACCESS BY INDEX ROWID| FULLSCANFULNESS | 10 | 35080 | 7 (0)| 00:00:01 | |* 4 | INDEX RANGE SCAN | IX_FULLSCANFULNESS | 50001 | | 1 (0)| 00:00:01 | ---------------------------------------------------------------------------------------------------- Predicate Information (identified by operation id): --------------------------------------------------- 1 - filter("from$_subquery$_002"."rowlimit_$$_rownumber"<=10) 2 - filter(ROW_NUMBER() OVER ( ORDER BY NULL )<=10) 4 - access("HOGE_FLG"=1) 統計 ---------------------------------------------------------- 0 recursive calls 0 db block gets 10 consistent gets 0 physical reads 0 redo size 802 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) 10 rows processed

WHERE条件を変更しました。表データブロックの先頭ブロックに該当行全てが含まれるようにしてみました。もともと、table full scanが途中で止まるケースですが、索引を利用させても遜色ない結果を得られます。唯一の違いは索引の存在ですね。DMLなどには性能的にマイナスの影響はありますが索引の数次第のところもあるので、どちらが大切かをよく検討、検証して決める必要はあります

1* update fullscanfulness set hoge_flg = 0 where id between 1 and 9 9行が更新されました。経過: 00:00:00.00 コミットが完了しました。経過: 00:00:00.00 1 SELECT 2 /*+ 3 INDEX(fullscanfulness ix_fullscanfulness) 4 */ 5 id 6 ,substr(dummy_text,1,10) as dummy 7 FROM 8 fullscanfulness 9 WHERE 10 hoge_flg = 0 11* FETCH FIRST 10 ROWS ONLY 10行が選択されました。経過: 00:00:00.00 実行計画 ---------------------------------------------------------- Plan hash value: 3248696394 ---------------------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ---------------------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 10 | 480 | 7 (0)| 00:00:01 | |* 1 | VIEW | | 10 | 480 | 7 (0)| 00:00:01 | |* 2 | WINDOW NOSORT STOPKEY | | 10 | 35080 | 7 (0)| 00:00:01 | | 3 | TABLE ACCESS BY INDEX ROWID| FULLSCANFULNESS | 10 | 35080 | 7 (0)| 00:00:01 | |* 4 | INDEX RANGE SCAN | IX_FULLSCANFULNESS | 50001 | | 1 (0)| 00:00:01 | ---------------------------------------------------------------------------------------------------- Predicate Information (identified by operation id): --------------------------------------------------- 1 - filter("from$_subquery$_002"."rowlimit_$$_rownumber"<=10) 2 - filter(ROW_NUMBER() OVER ( ORDER BY NULL )<=10) 4 - access("HOGE_FLG"=0) 統計 ---------------------------------------------------------- 1 recursive calls 0 db block gets 9 consistent gets 0 physical reads 0 redo size 800 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) 10 rows processed

もう一つ、意地悪な確認をしてみましょう。

表データの中間付近に、WHERE条件を満たす行を配置して、索引を利用できないよう　NO_INDEXヒントに変更します。

結果は、想定通り、 Top N クエリーは、表データの1/2ほどまで table full scanを行って停止することがわかります。

1* update fullscanfulness set hoge_flg = 0 where id between 1 and 9 or id = 100001 10行が更新されました。経過: 00:00:00.00 1* update fullscanfulness set hoge_flg = 1 where id between 50000 and 50010 11行が更新されました。経過: 00:00:00.01 コミットが完了しました。経過: 00:00:00.00 1 SELECT 2 /*+ 3 NO_INDEX(fullscanfulness ix_fullscanfulness) 4 */ 5 id 6 ,substr(dummy_text,1,10) as dummy 7 FROM 8 fullscanfulness 9 WHERE 10 hoge_flg = 1 11* FETCH FIRST 10 ROWS ONLY 10行が選択されました。経過: 00:00:00.24 実行計画 ---------------------------------------------------------- Plan hash value: 1910161288 ------------------------------------------------------------------------------------------ | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ------------------------------------------------------------------------------------------ | 0 | SELECT STATEMENT | | 10 | 480 | 5 (0)| 00:00:01 | |* 1 | VIEW | | 10 | 480 | 5 (0)| 00:00:01 | |* 2 | WINDOW NOSORT STOPKEY| | 10 | 35080 | 5 (0)| 00:00:01 | |* 3 | TABLE ACCESS FULL | FULLSCANFULNESS | 10 | 35080 | 5 (0)| 00:00:01 | ------------------------------------------------------------------------------------------ Predicate Information (identified by operation id): --------------------------------------------------- 1 - filter("from$_subquery$_002"."rowlimit_$$_rownumber"<=10) 2 - filter(ROW_NUMBER() OVER ( ORDER BY NULL )<=10) 3 - filter("HOGE_FLG"=1) 統計 ---------------------------------------------------------- 1 recursive calls 0 db block gets 24739 consistent gets 24672 physical reads 0 redo size 818 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) 10 rows processed

同じ状態で、ヒントを元に戻し、索引を利用できるようにします。

当然ですが、必要最小限のデータブロックを索引使って取得するようになり、 table full scan は回避できます。

1 SELECT 2 /*+ 3 INDEX(fullscanfulness ix_fullscanfulness) 4 */ 5 id 6 ,substr(dummy_text,1,10) as dummy 7 FROM 8 fullscanfulness 9 WHERE 10 hoge_flg = 1 11* FETCH FIRST 10 ROWS ONLY 10行が選択されました。経過: 00:00:00.01 実行計画 ---------------------------------------------------------- Plan hash value: 3248696394 ---------------------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ---------------------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 10 | 480 | 7 (0)| 00:00:01 | |* 1 | VIEW | | 10 | 480 | 7 (0)| 00:00:01 | |* 2 | WINDOW NOSORT STOPKEY | | 10 | 35080 | 7 (0)| 00:00:01 | | 3 | TABLE ACCESS BY INDEX ROWID| FULLSCANFULNESS | 10 | 35080 | 7 (0)| 00:00:01 | |* 4 | INDEX RANGE SCAN | IX_FULLSCANFULNESS | 50001 | | 1 (0)| 00:00:01 | ---------------------------------------------------------------------------------------------------- Predicate Information (identified by operation id): --------------------------------------------------- 1 - filter("from$_subquery$_002"."rowlimit_$$_rownumber"<=10) 2 - filter(ROW_NUMBER() OVER ( ORDER BY NULL )<=10) 4 - access("HOGE_FLG"=1) 統計 ---------------------------------------------------------- 0 recursive calls 0 db block gets 9 consistent gets 0 physical reads 0 redo size 818 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) 10 rows processed

次の例は、空振りのケースでも索引アクセスなら瞬時に空振りが判定できますよね！！　という確認です。

WHERE条件に対応した索引を用意するだけで、索引を見たたけで対象データが存在しないことが判定できます。空振りして、table full scanして、全データブロックを総ナメなんて無駄ですよね。

1 SELECT 2 /*+ 3 INDEX(fullscanfulness ix_fullscanfulness) 4 */ 5 id 6 ,substr(dummy_text,1,10) as dummy 7 FROM 8 fullscanfulness 9 WHERE 10 hoge_flg = 9 11* FETCH FIRST 10 ROWS ONLY レコードが選択されませんでした。経過: 00:00:00.01 実行計画 ---------------------------------------------------------- Plan hash value: 3248696394 ---------------------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ---------------------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 10 | 480 | 2 (0)| 00:00:01 | |* 1 | VIEW | | 10 | 480 | 2 (0)| 00:00:01 | |* 2 | WINDOW NOSORT STOPKEY | | 1 | 3508 | 2 (0)| 00:00:01 | | 3 | TABLE ACCESS BY INDEX ROWID| FULLSCANFULNESS | 1 | 3508 | 2 (0)| 00:00:01 | |* 4 | INDEX RANGE SCAN | IX_FULLSCANFULNESS | 1 | | 1 (0)| 00:00:01 | ---------------------------------------------------------------------------------------------------- Predicate Information (identified by operation id): --------------------------------------------------- 1 - filter("from$_subquery$_002"."rowlimit_$$_rownumber"<=10) 2 - filter(ROW_NUMBER() OVER ( ORDER BY NULL )<=10) 4 - access("HOGE_FLG"=9) 統計 ---------------------------------------------------------- 1 recursive calls 0 db block gets 2 consistent gets 0 physical reads 0 redo size 453 bytes sent via SQL*Net to client 41 bytes received via SQL*Net from client 1 SQL*Net roundtrips to/from client 0 sorts (memory) 0 sorts (disk) 0 rows processed

そんな索引でも索引に含まれていない列でソートされたりすると困ることもあります。という例です。

次の例は、索引でtable full scanを回避できていたTop N クエリーが仕様変更され、索引に含まれないid列のソートが追加されてしまいました。
その結果。。。索引エントリーが読み込まれ、かつ、ソートまでされる結果となってしまいました。ありゃありゃw

1 SELECT 2 /*+ 3 INDEX(fullscanfulness ix_fullscanfulness) 4 */ 5 id 6 ,substr(dummy_text,1,10) as dummy 7 FROM 8 fullscanfulness 9 WHERE 10 hoge_flg = 0 11 ORDER BY 12 id DESC 13* FETCH FIRST 10 ROWS ONLY 10行が選択されました。経過: 00:00:00.56 実行計画 ---------------------------------------------------------- Plan hash value: 3127027845 -------------------------------------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time | -------------------------------------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 10 | 610 | | 61653 (1)| 00:00:03 | |* 1 | VIEW | | 10 | 610 | | 61653 (1)| 00:00:03 | |* 2 | WINDOW SORT PUSHED RANK | | 50001 | 167M| 195M| 61653 (1)| 00:00:03 | | 3 | TABLE ACCESS BY INDEX ROWID BATCHED| FULLSCANFULNESS | 50001 | 167M| | 25103 (1)| 00:00:01 | |* 4 | INDEX RANGE SCAN | IX_FULLSCANFULNESS | 50001 | | | 92 (2)| 00:00:01 | -------------------------------------------------------------------------------------------------------------------- Predicate Information (identified by operation id): --------------------------------------------------- 1 - filter("from$_subquery$_002"."rowlimit_$$_rownumber"<=10) 2 - filter(ROW_NUMBER() OVER ( ORDER BY INTERNAL_FUNCTION("ID") DESC )<=10) 4 - access("HOGE_FLG"=0) 統計 ---------------------------------------------------------- 49 recursive calls 0 db block gets 50651 consistent gets 50123 physical reads 0 redo size 818 bytes sent via SQL*Net to client 52 bytes received via SQL*Net from client 2 SQL*Net roundtrips to/from client 9 sorts (memory) 0 sorts (disk) 10 rows processed

前述の例は、索引の効果がなくなってしまったことが原因なので、仕様変更に合わせ、索引も変更しなければなりません！

仕様変更に対応した索引を作成します。新規作成していますが、作り直しでも良いですね。列が増加しただけで他に影響がない索引であれば。

1* create index ix2_fullscanfulness on fullscanfulness(hoge_flg, id desc) 索引が作成されました。経過: 00:00:00.51 1 SELECT 2 /*+ 3 INDEX(fullscanfulness ix2_fullscanfulness) 4 */ 5 id 6 ,substr(dummy_text,1,10) as dummy 7 FROM 8 fullscanfulness 9 WHERE 10 hoge_flg = 0 11 ORDER BY 12 id DESC 13* FETCH FIRST 10 ROWS ONLY 10行が選択されました。経過: 00:00:00.01 実行計画 ---------------------------------------------------------- Plan hash value: 3270412619 ------------------------------------------------------------------------------------------------------ | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ------------------------------------------------------------------------------------------------------ | 0 | SELECT STATEMENT | | 10 | 610 | 9 (12)| 00:00:01 | | 1 | SORT ORDER BY | | 10 | 610 | 9 (12)| 00:00:01 | |* 2 | VIEW | | 10 | 610 | 8 (0)| 00:00:01 | |* 3 | WINDOW NOSORT STOPKEY | | 10 | 35080 | 8 (0)| 00:00:01 | | 4 | TABLE ACCESS BY INDEX ROWID| FULLSCANFULNESS | 50001 | 167M| 8 (0)| 00:00:01 | |* 5 | INDEX RANGE SCAN | IX2_FULLSCANFULNESS | 10 | | 2 (0)| 00:00:01 | ------------------------------------------------------------------------------------------------------ Predicate Information (identified by operation id): --------------------------------------------------- 2 - filter("from$_subquery$_002"."rowlimit_$$_rownumber"<=10) 3 - filter(ROW_NUMBER() OVER ( ORDER BY SYS_OP_DESCEND("ID"))<=10) 5 - access("HOGE_FLG"=0) 統計 ---------------------------------------------------------- 1 recursive calls 0 db block gets 8 consistent gets 1 physical reads 0 redo size 818 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) 10 rows processed

フルスキャンそんなにしたいのでしょうか？　無駄なエネルギーを消費させて。。謎は深まる、　

フルスキャンフルネスな感じなのだろうか。。

では、また。

・rownum使って満足しちゃってると.....おまけ
・rownum使って満足しちゃってると.....おまけのおまけ FETCH FIRST N ROWS ONLY編

投稿日時 2024年2月21日 (水) 20時19分 Oracle, チューニング, SQL, パフォーマンス | 固定リンク | 0 | コメント (0)

2023年12月22日 (金)

PostgreSQLのexplain analyze中にCTRL+Cでキャンセルすると、途中まで実行されているActual Planの結果は出力されないわけだが、その挙動を、ほんの少し追ってみた件

本エントリーは、PostgreSQL Advent Calendar 2023 シリーズ2の Day 22向けエントリーです

今回は、PostgreSQLオンリーで、投げっぱなしだったやつをちょっと掘り下げた時のメモ的なエントリーです。。

以前、

・MySQL 8.0.32 / explain analyze 実行途中でキャンセルできるみたいだけど、キャンセルしたら、Actual Plan、途中まで出るの？
・帰ってきた！標準はあるにはあるが癖の多いSQL #2 Actual Plan取得中のキャンセルでも癖が出る

というエントリーを書いたのですが、

explain (analyze) 実行中、CTRL+C した時、どのようにハンドングしてるんだろう？
Hookで拾って、extensionで、explain (analyze) でも途中までは結果を書き出せるようにできちゃったりするのだろうか？　と。　

気になりすぎてしまったのでw、該当ソースコードを追い、象が生息する森の奥地に入ってみることにした。。。。

https://github.com/postgres/postgres

ただ、あてもないのに森林の奥地入り込むのは、迷子になる危険を感じたのでw、ちょっとだけ、生態を調べてみたw

すると、幸運なことに、先人が足を踏み入れた痕跡と思われるメモ見つけることができた。

PostgreSQLのシグナル周り
https://qiita.com/KazuyaTomita/items/6feb708d73190032dfed

ふむふむ、なんとなくわかった気持ちになる。。（理解したとは言ってない）

PostgreSQLのActual Plan取得のログ。
見ての通り、PostgreSQLは、explain (analyze)実行中にCTRL+Cでキャンセルすると、シンプルなキャンセルメッセージを返すだけ。
（MySQL/Oracleでは、キャンセルされるまでのActual Planを返してくれる。冒頭のリンク参照）

この表示されているメッセージは手がかりになりそうだなぁ。。。。

perftestdb=> explain (analyze, buffers, verbose) WITH RECURSIVE gen_nums(v) AS ( SELECT 1 UNION ALL SELECT v + 1 FROM gen_nums WHERE v + 1 <= 100000000 ) SELECT v from gen_nums; ^Cキャンセル要求を送信しました ERROR: canceling statement due to user request perftestdb=>

シグナル周りのハンドリング部分のコードを追って、このメッセージを出力しているところを特定すると良さげな気がしますよね。

ただ、explain を実行している箇所とは違いそうではある。。。ざっくり目だが。

postgres.cのPostgresMain()に以下の文がありますな〜

postgres.c

pqsignal(SIGINT, StatementCancelHandler); /* cancel current query */

そして、至る所で、 CHECK_FOR_INTERRUPTS ()マクロが呼ばれてます〜〜。

CHECK_FOR_INTERRUPTS()マクロで、呼ばれているのが、　ProcessInterrupts() ですね。

miscadmin.h

/* Service interrupt, if one is pending and it's safe to service it now */ #define CHECK_FOR_INTERRUPTS() \ do { \ if (INTERRUPTS_PENDING_CONDITION()) \ ProcessInterrupts(); \ } while(0)

ProcessInterrupts()をみると、以下に見覚えのあるエラーメッセージ "canceling statement due to user request"を出力している箇所を発見。

postgres.c

/* * If we are reading a command from the client, just ignore the cancel * request --- sending an extra error message won't accomplish * anything. Otherwise, go ahead and throw the error. */ if (!DoingCommandRead) { LockErrorCleanup(); ereport(ERROR, (errcode(ERRCODE_QUERY_CANCELED), errmsg("canceling statement due to user request"))); }

explain (analyze)に関わりそうな以下のコードでは、CHECK_FOR_INTERRUPTSはないのだけど、executer配下のコードには沢山ある。。。

explain.c

execMain.c

...　extensionでなんとか、、というのは雰囲気的に難しそうな。。。

explain (actual plan取得含む）実行中に CTRL+C　キャンセルすると、

postgres.c の PostgresMain() -> CHECK_FOR_INTERRUPTS() -> ProcessInterrupts() -> ereport() -> errmsg("canceling statement due to user request") を出力して実行キャンセル
と言う流れっぽい。斜め読みした限りでは。

ぱっと見だが、

errmsg("canceling statement due to user request")の前に、

1. commandが実行されているか
2. 1.であれば、commandは、explain かつ analyzeか？
3. 2.であれば、explain analyzeのキャンセルされる前に取得されたActual Planの結果を出力

みたいなことを、ProcessInterrupts()内でやらないと難しそうだよなぁ〜と。extensionでやれそうな感じにも見えないし。。。
一旦、そっとGitHubを開いていたブラウザのタブを閉じたww

と言うことで、冬の夜長に、PostgreSQLのコードをちょっと追ってみた話はここまで。

PostgreSQL Advent Calendar 2023 ですがw 恒例？の、Oracle Pipelined Table Function で Christmas ASCII Art(クロスポストに続き2回目）

関連エントリー
・MySQL 8.0.32 / explain analyze 実行途中でキャンセルできるみたいだけど、キャンセルしたら、Actual Plan、途中まで出るの？
・帰ってきた！標準はあるにはあるが癖の多いSQL #2 Actual Plan取得中のキャンセルでも癖が出る

投稿日時 2023年12月22日 (金) 00時00分チューニング, SQL, PostgreSQL, パフォーマンス, Advent Calendar | 固定リンク | 0 | コメント (0)

2023年12月17日 (日)

帰ってきた！標準はあるにはあるが癖の多いSQL #8、Hash Joinさせるにも癖が出る

本エントリーは、
MySQL Advent Calendar 2023 シリーズ1
PostgreSQL Advent Calendar 2023 シリーズ1
JPOUG Advent Calendar 2023

の Day 17 向けエントリーです。

また、本エントリー向け予習エントリーを投稿していますので、一読していただくと私が何と戦っていたのかw 理解しやすいのではないかと思います

予習　その１は、以下。
帰ってきた！標準はあるにはあるが癖の多いSQL #5 - Optimizer Hint でも癖が多い

予習　その２は、以下。
帰ってきた！標準はあるにはあるが癖の多いSQL #6 - Hash Joinの結合ツリーにも癖がでる

予習　その３は、以下。
帰ってきた！標準はあるにはあるが癖の多いSQL #7 - Hash Joinの実行計画の見せ方にも癖がでる

ということで、これまでの予習で学んだことを利用して、もしも、こんなデータ（予習　その２　を参照のこと）で、以下のようなSQLがあった場合、Hash Joinの特性上いい感じの実行計画にさせるにはどうHintingするのが良いのか考えてみたいと思います。
（答えが見えている方は多いとは思いますけどもw）

以下のSQL文を使い、後述のような実行計画に制御することを目指してみます。

SELECT t1.id , t1.t1_c1 , t2.s_id , t2.t2_c1 , t3.b_id , t3.t3_c1 , t4.a_id , t4.c_id , t4.t4_c1 , t0.m_id , t0.t0_c1 FROM t1 INNER JOIN t2 ON t1.id = t2.id INNER JOIN t3 ON t1.id = t3.id INNER JOIN t4 ON t1.id = t4.id INNER JOIN t0 ON t1.id = t0.id ;

いざというときに慌てずに、どうするかを判断、チューニングできるようになっておくと良いですよねー。
そう言う、いざ、という場面には付き合わされない人も、雑学的になんとなーーーく理解しているだけでも良いのではないかと思います。

Oracleの実行計画風ですが、こんな実行計画にオプティマイザーヒントだけで制御してみたいなぁ。というのがお題。右側にコメントしているBuild/Probeの関係を覚えておいてください。この形にするのが目的です。
（予習に目を通した方は、あ”〜っ。と何かに気づいちゃったと思いますけどもw）

ポイントになるのは、t0の結合です。　t1,t2,t3,t4と結合した結果が、t0の行数より多くなります。（そうなるようにデータを用意したので）Hash Joinを想定しているので、最後にt0を結合する場合には、t0をBuildにしたいですよね。。。
（Hash Joinの結合順で理想なのは、常にBuildの方が小さくなる結合順なので、以下の形が理想的だとのがわかりやすいようにJoin cardinarityも記載してあります）

HJ (join card = 2,500,000) -> t0 (rows = 1,000) -- Build -> HJ (join card = 250,000) -- Probe -> HJ (join card = 500) -- Build -> HJ (join card = 50) -- Build -> t1 (rows = 10) -- Build -> t2 (rows = 50) -- Probe -> t3 (rows = 100) -- Probe -> t4 (rows = 500) -- Probe

なお、これまでの予習で、MySQLは、Hash Join はできるけど、Build/Probeの制御ができない。 Left Deep Join Treeにしかならないのもどうしようもない。　
オプティマイザヒントでは無理だろうと想像はできるわけですがw 折角なので、できるところまで試して、挙動をみておきましょう:)

再掲
テーブル定義とデータ量は以下、予習　その２参照のこと。
帰ってきた！標準はあるにはあるが癖の多いSQL #6 - Hash Joinの結合ツリーにも癖がでる

まず、Oracleからですかねぇ。やはり。豊富なオプティマイザヒントと最適化が行えることが強みの一つだと思います。

Oracle Database 21c

ちょっと暴れてたのでw NO_SWAP_JOIN_INPUTSを使ってますが、実行計画としては狙ったところに持っていけますよね。Oraclerの方なら、ふむふむ。というところだと思います。
t1, t2, t3, t4, t0の順で結合しますが、最後の、t0の結合時は、Buildを t0　にしてね！　というHinging。実践でも結構使う場面はありますよね。
(実行計画の右側に確認しやすくするため、どちらが (Build) / (Probe) なのかをコメントしてあります）

SCOTT@ORCLCDB> select banner_full from v$version; BANNER_FULL ----------------------------------------------------------------------- Oracle Database 21c Enterprise Edition Release 21.0.0.0.0 - Production Version 21.3.0.0.0 SCOTT@orclpdb1> @advent_sql_ora 1 SELECT 2 /*+ 3 MONITOR 4 LEADING(t1 t2 t3 t4 t0) 5 USE_HASH(t1 t2 t3 t4 t0) 6 NO_SWAP_JOIN_INPUTS(t4) 7 SWAP_JOIN_INPUTS(t0) 8 */ 9 t1.id 10 , t1.t1_c1 11 , t2.s_id 12 , t2.t2_c1 13 , t3.b_id 14 , t3.t3_c1 15 , t4.a_id 16 , t4.c_id 17 , t4.t4_c1 18 , t0.m_id 19 , t0.t0_c1 20 FROM 21 t1 22 INNER JOIN t2 23 ON 24 t1.id = t2.id 25 INNER JOIN t3 26 ON 27 t1.id = t3.id 28 INNER JOIN t4 29 ON 30 t1.id = t4.id 31 INNER JOIN t0 32 ON 33* t1.id = t0.id ...略... SQL Plan Monitoring Details (Plan Hash Value=3728371915) ==================================================================================================================================================== | 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 | | | | 106 | +0 | 1 | 3M | | | . | | | | 1 | HASH JOIN | | 3M | 29 | 106 | +0 | 1 | 3M | | | 1MB | | | | 2 | TABLE ACCESS FULL | T0 | 1000 | 3 | 1 | +0 | 1 | 1000 | 2 | 49152 | . | | | (Build) | 3 | HASH JOIN | | 25000 | 12 | 106 | +0 | 1 | 25000 | | | 1MB | | | (Probe) | 4 | HASH JOIN | | 500 | 9 | 1 | +0 | 1 | 500 | | | 1MB | | | (Build) | 5 | HASH JOIN | | 50 | 6 | 1 | +0 | 1 | 50 | | | 1MB | | | (Build) | 6 | TABLE ACCESS FULL | T1 | 10 | 3 | 1 | +0 | 1 | 10 | 2 | 49152 | . | | | (Build) | 7 | TABLE ACCESS FULL | T2 | 50 | 3 | 1 | +0 | 1 | 50 | 2 | 49152 | . | | | (Probe) | 8 | TABLE ACCESS FULL | T3 | 100 | 3 | 1 | +0 | 1 | 100 | 2 | 49152 | . | | | (Probe) | 9 | TABLE ACCESS FULL | T4 | 500 | 3 | 106 | +0 | 1 | 500 | 3 | 81920 | . | | | (Probe) ====================================================================================================================================================

簡単に解説すると、t1からt4まではLeft Deep Join Tree、t0は、術式反転w で Right Deep Join Treeになるように、SWAP_JOIN_INPUTSしてます。

Id=5で、Id=6のt1（Build）と、Id=7のt2（Probe）をHash Join
Id=4で、Id=5の結果（Build）と、Id=8のt3（Probe）をHash Join
Id=3で、Id=4の結果（Build）と、Id=9のt4（Probe）をHash Join
Id=2で、SWAP_JOIN_INPUTSヒントで入れ替えた、Id=2のt0(Build)と、Id=3の結果（Probe）をHash Join

狙った実行計画に制御できました。ニッコリ。

参考）使ったSQLスクリプトは以下の通り。

SCOTT@ORCLCDB> !cat show_realtime_sqlplan.sql set linesize 1000 set long 1000000 set longchunksize 1000000 select dbms_sqltune.report_sql_monitor(sql_id=>'', type=>'text') from dual; SCOTT@ORCLCDB> !cat advent_sql_ora.sql SELECT /*+ MONITOR LEADING(t1 t2 t3 t4 t0) USE_HASH(t1 t2 t3 t4 t0) NO_SWAP_JOIN_INPUTS(t4) SWAP_JOIN_INPUTS(t0) */ t1.id , t1.t1_c1 , t2.s_id , t2.t2_c1 , t3.b_id , t3.t3_c1 , t4.a_id , t4.c_id , t4.t4_c1 , t0.m_id , t0.t0_c1 FROM t1 INNER JOIN t2 ON t1.id = t2.id INNER JOIN t3 ON t1.id = t3.id INNER JOIN t4 ON t1.id = t4.id INNER JOIN t0 ON t1.id = t0.id . l set tab off set termout off / set termout on @show_realtime_sqlplan

PostgreSQL 13.4 with pg_hint_plan 1.3.9
なんで、最新のPostgreSQLじゃないのか？　単にアップデートサボってるだなので、気にししないでw

perftestdb=# select version(); version -------------------------------------------------------------------------------------------------------- PostgreSQL 13.4 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 8.4.1 20200928 (Red Hat 8.4.1-1), 64-bit perftestdb=# select * from pg_extension where extname='pg_hint_plan'; oid | extname | extowner | extnamespace | extrelocatable | extversion | extconfig | extcondition --------+--------------+----------+--------------+----------------+------------+-----------------+-------------- 131364 | pg_hint_plan | 10 | 131363 | f | 1.3.9 | {131367,131365} | {"",""} perftestdb=> show shared_preload_libraries; shared_preload_libraries ----------------------------------------------- pg_hint_plan

pg_hint_planのLeadingヒントの使い方慣れるまで結構迷子になってましたw。空気感でなんとなーく使い方を理解できたかなぁ。という感じ。
pg_hint_planのLeading(pair)の書き方と、順序の指定順って、Oraclerの感覚的には逆なんですよね。Hash Joinの時だけは。。。というところ気づきました？　みなさん。（主に、Oracle方面の）

perftestdb=> \! cat advent_sql_pg.sql explain (analyze) SELECT /*+ Leading(((t4 (t3 (t2 t1))) t0)) HashJoin(t0 t1 t2 t3 t4) SeqScan(t0) SeqScan(t1) SeqScan(t2) SeqScan(t3) SeqScan(t4) */ t1.id , t1.t1_c1 , t2.s_id , t2.t2_c1 , t3.b_id , t3.t3_c1 , t4.a_id , t4.c_id , t4.t4_c1 , t0.m_id , t0.t0_c1 FROM t1 INNER JOIN t2 ON t1.id = t2.id INNER JOIN t3 ON t1.id = t3.id INNER JOIN t4 ON t1.id = t4.id INNER JOIN t0 ON t1.id = t0.id ; perftestdb=> \i advent_sql_pg.sql QUERY PLAN ---------------------------------------------------------------------------------------------------------------------------------------- Id=1 Hash Join (cost=46.66..28524.66 rows=2500000 width=44) (actual time=0.875..574.957 rows=2500000 loops=1) Hash Cond: (t1.id = t0.id) Id=2 (Probe) -> Hash Join (cost=18.16..308.66 rows=25000 width=48) (actual time=0.429..11.123 rows=25000 loops=1) Hash Cond: (t4.id = t1.id) Id=3 (Probe) -> Seq Scan on t4 (cost=0.00..8.00 rows=500 width=16) (actual time=0.006..0.776 rows=500 loops=1) Id=4 (Build) -> Hash (cost=11.91..11.91 rows=500 width=32) (actual time=0.418..0.423 rows=500 loops=1) Buckets: 1024 Batches: 1 Memory Usage: 40kB Id=5 -> Hash Join (cost=4.04..11.91 rows=500 width=32) (actual time=0.072..0.270 rows=500 loops=1) Hash Cond: (t3.id = t1.id) Id=6 (Probe) -> Seq Scan on t3 (cost=0.00..2.00 rows=100 width=12) (actual time=0.004..0.016 rows=100 loops=1) Id=7 (Build) -> Hash (cost=3.41..3.41 rows=50 width=20) (actual time=0.064..0.067 rows=50 loops=1) Buckets: 1024 Batches: 1 Memory Usage: 11kB Id=8 -> Hash Join (cost=1.23..3.41 rows=50 width=20) (actual time=0.018..0.053 rows=50 loops=1) Hash Cond: (t2.id = t1.id) Id=9 (Probe) -> Seq Scan on t2 (cost=0.00..1.50 rows=50 width=12) (actual time=0.004..0.011 rows=50 loops=1) Id=10 (Build) -> Hash (cost=1.10..1.10 rows=10 width=8) (actual time=0.008..0.009 rows=10 loops=1) Buckets: 1024 Batches: 1 Memory Usage: 9kB Id=11 -> Seq Scan on t1 (cost=0.00..1.10 rows=10 width=8) (actual time=0.003..0.005 rows=10 loops=1) Id=12 (Build) -> Hash (cost=16.00..16.00 rows=1000 width=12) (actual time=0.437..0.437 rows=1000 loops=1) Buckets: 1024 Batches: 1 Memory Usage: 51kB Id=13 -> Seq Scan on t0 (cost=0.00..16.00 rows=1000 width=12) (actual time=0.022..0.219 rows=1000 loops=1)

解説のために、Id=noと、Build/Probeを見やすくするためにコメント (Build) / (Probe) を追加しています

Oracleと同じように制御できているか、確認しましょう。

Id=8で、Id=11のt1をSeq ScanしてId=10でハッシュ表作成（Build）と、Id=9のt2をSec Scan（Probe）をHash Join
Id=5で、Id=8の結果を元に、Id=7でハッシュ表作成（Build）と、Id=6のt3 Seq Scan（Probe）をHash Join
Id=2で、Id=5の結果を元に、Id=4でハッシュ表作成（Build）と、Id=3のt4 Seq Scan（Probe）をHash Join
Id=1で、Id=13のt0をSeq ScanしてId=12でハッシュ表作成（Build）と、Id=2の結果（Probe）をHash Join

狙い通りの実行計画になっています！、Yahooooo!!

今一度、Oracleの実行計画と比較してみると、Hash JoinのBuild/Probeの表現が逆になっていることがよくわかりますよね。（前回の予習の通りです）

======================================================================================================================= | Id | Operation | Name | Rows | Cost | Time | Start | Execs | Rows | Read | Read | Mem | | | | | (Estim) | | Active(s) | Active | | (Actual) | Reqs | Bytes | (Max) | ======================================================================================================================= | 0 | SELECT STATEMENT | | | | 106 | +0 | 1 | 3M | | | . | | 1 | HASH JOIN | | 3M | 29 | 106 | +0 | 1 | 3M | | | 1MB | (Build) | 2 | TABLE ACCESS FULL | T0 | 1000 | 3 | 1 | +0 | 1 | 1000 | 2 | 49152 | . | (Probe) | 3 | HASH JOIN | | 25000 | 12 | 106 | +0 | 1 | 25000 | | | 1MB | (Build) | 4 | HASH JOIN | | 500 | 9 | 1 | +0 | 1 | 500 | | | 1MB | (Build) | 5 | HASH JOIN | | 50 | 6 | 1 | +0 | 1 | 50 | | | 1MB | (Build) | 6 | TABLE ACCESS FULL | T1 | 10 | 3 | 1 | +0 | 1 | 10 | 2 | 49152 | . | (Probe) | 7 | TABLE ACCESS FULL | T2 | 50 | 3 | 1 | +0 | 1 | 50 | 2 | 49152 | . | (Probe) | 8 | TABLE ACCESS FULL | T3 | 100 | 3 | 1 | +0 | 1 | 100 | 2 | 49152 | . | (Probe) | 9 | TABLE ACCESS FULL | T4 | 500 | 3 | 106 | +0 | 1 | 500 | 3 | 81920 | . | =======================================================================================================================

最後に、
MySQL 8.0.32
これも現時点のリリースよりちょっと前のですが、こちらの都合なので、気にしないでくださいw

mysql> select version(); +-----------+ | version() | +-----------+ | 8.0.32 | +-----------+ 1 row in set (0.01 sec) mysql>

無理やり、Hash Joinにはしていますが、PostgreSQLのpg_hint_planのように結合優先順位をペアで制御する方法も、Oracleのように、SWAP_JOIN_INPUTSヒントを使うこともできません。Left Deep Join Treeにしかならないということなので、それが理由ではありますが。とりあえず、こんな感じにしかなりません。JOIN_ORDERヒントの結合順は、OracleのLEADINGヒントに近い考え方で支えているのがわかります。要するに、Buhy Join Treeが可能であれば、これは解決できるわけですが、それは無理なので、t0をBuildにすることができず、これが限界といことになりますよね。（ちょっと思いついたことがあるので、このあと、もうひとあがきしてみますがw）

あと、ヒントで面白いのは、主キー索引を利用させないためのヒント。primaryって指定が必要なんので覚えておくと便利ですよね。
マニュアルにも記載されていますが、インデックスヒントが非推奨になる前に、オプティマイザヒントに慣れておいたほうがよさそうですし。

MySQL 8.0 / 8.9.4 インデックスヒント

”注記
MySQL 8.0.20 の時点で、サーバーは、インデックスオプティマイザヒント JOIN_INDEX, GROUP_INDEX, ORDER_INDEX、および INDEX(NO_JOIN_INDEX, NO_GROUP_INDEX, NO_ORDER_INDEX および FORCE INDEX オプティマイザヒントに相当およびを置き替える)、および NO_INDEX オプティマイザヒント (IGNORE INDEX インデックスヒントに相当し、それらを置き換える) をサポートします。したがって、USE INDEX、FORCE INDEX および IGNORE INDEX は、MySQL の将来のリリースで非推奨になり、後で完全に削除される予定です。詳細は、インデックスレベルのオプティマイザヒントを参照してください。”

mysql> \! cat advent_sql_my.sql explain analyze SELECT /*+ JOIN_ORDER(t1,t2,t3,t4,t0) NO_JOIN_INDEX(t1 primary) NO_JOIN_INDEX(t2 primary) NO_JOIN_INDEX(t3 primary) NO_JOIN_INDEX(t4 primary) NO_JOIN_INDEX(t0 primary) */ t1.id , t1.t1_c1 , t2.s_id , t2.t2_c1 , t3.b_id , t3.t3_c1 , t4.a_id , t4.c_id , t4.t4_c1 , t0.m_id , t0.t0_c1 FROM t1 INNER JOIN t2 ON t1.id = t2.id INNER JOIN t3 ON t1.id = t3.id INNER JOIN t4 ON t1.id = t4.id INNER JOIN t0 ON t1.id = t0.id ; mysql> \. advent_sql_my.sql +---------------------------------------------------------------------------------------------------------------------------+ | EXPLAIN | +---------------------------------------------------------------------------------------------------------------------------+ Id=1 | -> Inner hash join (t0.id = t1.id) (cost=2525558.24 rows=2500000) (actual time=23.139..356.660 rows=2500000 loops=1) Id=2 (Probe) -> Table scan on t0 (cost=0.00 rows=1000) (actual time=0.083..0.512 rows=1000 loops=1) Id=3 (Build) -> Hash Id=4 -> Inner hash join (t4.id = t1.id) (cost=25552.55 rows=25000) (actual time=0.679..4.613 rows=25000 loops=1) Id=5 (Probe) -> Table scan on t4 (cost=0.01 rows=500) (actual time=0.057..0.330 rows=500 loops=1) Id=6 (Build) -> Hash Id=7 -> Inner hash join (t3.id = t1.id) (cost=551.75 rows=500) (actual time=0.223..0.412 rows=500 loops=1) Id=8 (Probe) -> Table scan on t3 (cost=0.03 rows=100) (actual time=0.041..0.069 rows=100 loops=1) Id=9 (Build) -> Hash Id=10 -> Inner hash join (t2.id = t1.id) (cost=51.50 rows=50) (actual time=0.106..0.146 rows=50 loops=1) Id=11 (Probe) -> Table scan on t2 (cost=0.08 rows=50) (actual time=0.025..0.040 rows=50 loops=1) Id=12 (Build) -> Hash Id=13 -> Table scan on t1 (cost=1.25 rows=10) (actual time=0.040..0.048 rows=10 loops=1) | +---------------------------------------------------------------------------------------------------------------------------+
（確認し訳するため、Id=nと(Build) / (Probe)を示すコメントを追記してあります）
Id=10で、Id=13のt1をTable Scanてから、Id=12でハッシュ表作成（Build）と、Id=11で、t2をTable Scan（Probe）をHash Join
Id=7で、Id=10の結果を元に、Id=9でハッシュ表作成（Build）と、Id=8のt3 Table Scan（Probe）をHash Join
Id=4で、Id=7の結果を元に、Id=6でハッシュ表作成（Build）と、Id=5のt4 Table Scan（Probe）をHash Join
Id=1で、Id=4の結果を元に、Id=3でハッシュ表作成（Build）と、Id=2のt0 Table Scan（Prove）をHash Hoin

最後のt0をBuildにしたいわけですけども、Build表制御することができないので。こんな感じですね。

と、一つだけ、思いついたので、SQL魔改造でなんとかならんか、試してみます。
（ヒントだけでなんとかするという趣旨からはズレるのですけどもw）

ダメ元で試してみますw

おおおおお、一瞬、できた！　か？　　と思いましたが、やはり無理です。CTEでサブクエリーとして先に一時表としてマテリアライズしたら行くかなぁ。
と思いましたが、MySQLは、一時表でも、自動的に内部的な主キーが作成されるという、... clustered indexなのか。。。一時表も。という気づき。
この方法では、CTEを使っていますが、インラインビューにして、NO_MERGEヒントにしても同様に、一時表としてマテリアライズされるようで、同様の結果でした。。。。

記載はしていませんが、マテリアライズされた一時表の　　という内部的な主キーですが、現状、 NO_JOIN_INDEXヒントで止められないので、t0の結合はNLJにしかできませんでした。。。

現時点のMySQLのオプティマイザの気持ちが、少しだけ、理解できるようになった気がします :)

mysql> \! cat advent_sql2_my.sql explain analyze WITH t1234 AS ( SELECT /*+ QB_NAME(ilv1) JOIN_ORDER(t1,t2,t3,t4) NO_JOIN_INDEX(t1 primary) NO_JOIN_INDEX(t2 primary) NO_JOIN_INDEX(t3 primary) NO_JOIN_INDEX(t4 primary) */ t1.id , t1.t1_c1 , t2.s_id , t2.t2_c1 , t3.b_id , t3.t3_c1 , t4.a_id , t4.c_id , t4.t4_c1 FROM t1 INNER JOIN t2 ON t1.id = t2.id INNER JOIN t3 ON t1.id = t3.id INNER JOIN t4 ON t1.id = t4.id ), t00 AS ( SELECT /*+ QB_NAME(ilv2) NO_INDEX(t0 primary) */ t0.id , t0.m_id , t0.t0_c1 FROM t0 ) SELECT /*+ JOIN_ORDER(@ilv2) NO_MERGE(t00) */ t1234.id , t1234.t1_c1 , t1234.s_id , t1234.t2_c1 , t1234.b_id , t1234.t3_c1 , t1234.a_id , t1234.c_id , t1234.t4_c1 , t00.m_id , t00.t0_c1 FROM t1234 INNER JOIN t00 ON t1234.id = t00.id ; mysql> \. advent_sql2_my.sql +---------------------------------------------------------------------------------------------------------------------------+ | EXPLAIN | +---------------------------------------------------------------------------------------------------------------------------+ | -> Nested loop inner join (cost=2588052.66 rows=25000001) (actual time=2.449..1233.983 rows=2500000 loops=1) -> Inner hash join (t4.id = t1.id) (cost=25552.55 rows=25000) (actual time=0.626..11.339 rows=25000 loops=1) -> Table scan on t4 (cost=0.01 rows=500) (actual time=0.031..2.330 rows=500 loops=1) -> Hash -> Inner hash join (t3.id = t1.id) (cost=551.75 rows=500) (actual time=0.403..0.483 rows=500 loops=1) -> Table scan on t3 (cost=0.03 rows=100) (actual time=0.024..0.037 rows=100 loops=1) -> Hash -> Inner hash join (t2.id = t1.id) (cost=51.50 rows=50) (actual time=0.329..0.350 rows=50 loops=1) -> Table scan on t2 (cost=0.08 rows=50) (actual time=0.021..0.028 rows=50 loops=1) -> Hash -> Table scan on t1 (cost=1.25 rows=10) (actual time=0.190..0.199 rows=10 loops=1) -> Index lookup on t00 using (id=t1.id) (cost=201.25..203.50 rows=10) (actual time=0.002..0.036 rows=100 loops=25000) -> Materialize CTE t00 (cost=201.00..201.00 rows=1000) (actual time=1.803..1.803 rows=1000 loops=1) -> Table scan on t0 (cost=101.00 rows=1000) (actual time=0.024..0.514 rows=1000 loops=1) | +---------------------------------------------------------------------------------------------------------------------------+ 1 row in set (2.77 sec)

（Warningも出てないので、オプティマイザヒントの指定方法としては良さげだが、狙い通りにはなりませんw）

では、最後に、このポストへ至るまでの予習ポストも含め、リンクを再掲しておきます

予習その１

帰ってきた！標準はあるにはあるが癖の多いSQL #5 - Optimizer Hint でも癖が多い

予習その２

帰ってきた！標準はあるにはあるが癖の多いSQL #6 - Hash Joinの結合ツリーにも癖がでる

予習その３

帰ってきた！標準はあるにはあるが癖の多いSQL #7 - Hash Joinの実行計画にも癖がでる

皆様、メリークリスマス & 良いお年をお迎えください。 :)　/ Oracle database 23c with pipe line function / SQL de Christmas Tree 、4K対応で作り直しましたw
恒例？の、Oracle Pipelined Table Function で Christmas ASCII Art

関連エントリー

・標準はあるにはあるが癖の多いSQL 全部俺　#1 Pagination
・標準はあるにはあるが癖の多いSQL 全部俺　#2 関数名は同じでも引数が逆の罠！
・標準はあるにはあるが癖の多いSQL 全部俺　#3 データ型確認したい時あるんです
・標準はあるにはあるが癖の多いSQL 全部俺　#4 リテラル値での除算の内部精度も違うのよ!
・標準はあるにはあるが癖の多いSQL 全部俺　#5 和暦変換機能ある方が少数派
・標準はあるにはあるが癖の多いSQL 全部俺　#6 時間厳守！
・標準はあるにはあるが癖の多いSQL 全部俺　#7 期間リテラル！
・標準はあるにはあるが癖の多いSQL 全部俺　#8 翌月末日って何日？
・標準はあるにはあるが癖の多いSQL 全部俺　#9 部分文字列の扱いでも癖が出る＞＜
・標準はあるにはあるが癖の多いSQL 全部俺　#10 文字列連結の罠（有名なやつ）
・標準はあるにはあるが癖の多いSQL 全部俺　#11 デュエル、じゃなくて、デュアル
・標準はあるにはあるが癖の多いSQL 全部俺　#12 文字[列]探すにも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#13 あると便利ですが意外となかったり
・標準はあるにはあるが癖の多いSQL 全部俺　#14 連番の集合を返すにも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#15 SQL command line client
・標準はあるにはあるが癖の多いSQL 全部俺　#16 SQLのレントゲンを撮る方法
・標準はあるにはあるが癖の多いSQL 全部俺　#17 その空白は許されないのか？
・標準はあるにはあるが癖の多いSQL 全部俺　#18 (+)の外部結合は方言
・標準はあるにはあるが癖の多いSQL 全部俺　#19 帰ってきた、部分文字列の扱いでも癖w
・標準はあるにはあるが癖の多いSQL 全部俺　#20 結果セットを単一列に連結するにも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#21 演算結果にも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#22 集合演算にも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#23 複数行INSERTにも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#24 乱数作るにも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#25 SQL de Fractalsにも癖がある:)
・標準はあるにはあるが癖の多いSQL 全部俺　おまけ SQL de 湯婆婆やるにも癖がでるw
・帰ってきた！標準はあるにはあるが癖の多いSQL #1 SQL de ROT13 やるにも癖が出るw
・帰ってきた！標準はあるにはあるが癖の多いSQL #2 Actual Plan取得中のキャンセルでも癖が出る
・帰ってきた！標準はあるにはあるが癖の多いSQL #3 オプティマイザの結合順評価テーブル数上限にも癖が出る
・帰ってきた！標準はあるにはあるが癖の多いSQL #4 Optimizer Traceの取得でも癖がでる
・帰ってきた！標準はあるにはあるが癖の多いSQL #5 - Optimizer Hint でも癖が多い
・帰ってきた！標準はあるにはあるが癖の多いSQL #6 - Hash Joinの結合ツリーにも癖がでる
・帰ってきた！標準はあるにはあるが癖の多いSQL #7 - Hash Joinの実行計画にも癖がでる

投稿日時 2023年12月17日 (日) 00時00分 Oracle, チューニング, SQL, MySQL, PostgreSQL, JPOUG, パフォーマンス, Advent Calendar | 固定リンク | 0 | コメント (0)

2023年12月10日 (日)

帰ってきた！標準はあるにはあるが癖の多いSQL #7 - Hash Joinの実行計画の見せ方にも癖がでる

本エントリーは、MySQL Advent Calendar 2023 シリーズ2 / Day 10とPostgreSQL Advent Calendar 2023 シリーズ2 / Day 10へのクロスポスト、および、JPOUG Advent Calendar 2023 / Day 10 の裏番組　（ADVENTARはシリーズ増やせないので）　エントリーで、12/17日向けの　予習　その３　という位置付けのエントリーです。

予習　その１は、以下。
帰ってきた！標準はあるにはあるが癖の多いSQL #5 - Optimizer Hint でも癖が多い

予習　その２は、以下。
帰ってきた！標準はあるにはあるが癖の多いSQL #6 - Hash Joinの結合ツリーにも癖がでる

MySQLは、Left Deep Join Treeにしかならない、というところまで理解できたのが前回までの予習でした。

今日は、もう少し、理解を深めておこうと言うことで、MySQLでは無理だけど、 PostgreSQL と Oracle で結合ツリーの種別（Oracleのマニュアルに記載されている分類の範囲）で、Right Deep Join、Left Deep Join、Bushy Joinでは、どのような実行計画として見えるのかを確認しておきましょう。

まず初めに、MySQLはできない Right Deep Join Tree で Hash Join させると、どのような実行計画に見えるか？　の比較から。

Oracle Database 21c
Oraclerなら見慣れたSWAP_JOIN_INPUTSヒント利用の典型的な例です。Id=6でt1(build)がtable full scanされ、ID=7のt2(Probe)と結合されています。t3, t4はそれぞれ、Buildとなっていることが読み取れます。

Oracle Database 21c / Right Deep Join Tree / Hash Join
（実行計画の右端に (Build) なのか、　(Probe)　を確認しやすいようにコメントを付加しています）

SCOTT@orclpdb1> @ora_sql_rightdj.sql 1 SELECT 2 /*+ 3 MONITOR 4 LEADING(t1 t2 t3 t4) 5 USE_HASH(t1 t2 t3 t4) 6 SWAP_JOIN_INPUTS(t3) 7 SWAP_JOIN_INPUTS(t4) 8 */ 9 t1.id 10 , t1.t1_c1 11 , t2.s_id 12 , t2.t2_c1 13 , t3.b_id 14 , t3.t3_c1 15 , t4.a_id 16 , t4.c_id 17 , t4.t4_c1 18 FROM 19 t1 20 INNER JOIN t2 21 ON 22 t1.id = t2.id 23 INNER JOIN t3 24 ON 25 t1.id = t3.id 26 INNER JOIN t4 27 ON 28* t1.id = t4.id ...略... SQL Plan Monitoring Details (Plan Hash Value=3835853103) =================================================================================================================================================== | 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 | | | | 2 | +0 | 1 | 25000 | | | . | | | | 1 | HASH JOIN | | 25000 | 12 | 2 | +0 | 1 | 25000 | | | 1MB | | | | 2 | TABLE ACCESS FULL | T4 | 500 | 3 | 1 | +0 | 1 | 500 | 2 | 49152 | . | | | (Build) | 3 | HASH JOIN | | 500 | 9 | 2 | +0 | 1 | 500 | | | 1MB | | | (Probe) | 4 | TABLE ACCESS FULL | T3 | 100 | 3 | 1 | +0 | 1 | 100 | 2 | 49152 | . | | | (Build) | 5 | HASH JOIN | | 50 | 6 | 2 | +0 | 1 | 50 | | | 1MB | | | (Probe) | 6 | TABLE ACCESS FULL | T1 | 10 | 3 | 1 | +0 | 1 | 10 | 2 | 49152 | . | | | (Build) | 7 | TABLE ACCESS FULL | T2 | 50 | 3 | 2 | +0 | 1 | 50 | 2 | 49152 | . | | | (Probe) ===================================================================================================================================================

PostgreSQL 13.4 / pg_hint_plan 1.3.9 / Right Deep Join Tree / Hash Join

OracleとはBuild表の位置が逆なので、OracleのLeft deep join treeの実行計画に読み間違えそうですがw PostgreSQLのRight Deep Join Treeだとこのような実行計画として表示されます。
Oracleでは、Id=6でT1がBuild表になり、Id=7のt2(Probe)と結合するように表現されますが、
PostgreSQLでは、 ★ で示した行で、t1が、Seq ScansされてHash表が作成されている。つまり、Build表になっており、t2(Probe)と結合されています。Oracleの感覚で読んでしまうと、あれ？　となるところだと思います。
t3, t4から、それぞれ、Hash表が作成されているので、Buildになっていることがわかります:)　
同じ実行計画になるようにしてみましたが、実行計画の見せ方では、Oracle/PostgreSQLでは差異がありますよね。ただ、MySQLのTree表示もPostgreSQLに類似しているので、PostgreSQLのに慣れてると、MySQLのTree formatの実行計画は読みやすいかもしれません）

Orableのように、SWAP_JOIN_INPUTSヒントでBuild/Probeを制御するヒントが存在しないので、代わりに、LeadingヒントのLeading()構文を利用して制御しています。OracleのLEADING + SWAP_JOIN_JOINPSと比べると可読性は劣化する（個人の感想です）の使い方が難しいく感じますね。慣れなのかなぁ。これ。

（実行計画の左端に (Build) なのか、　(Probe)　を確認しやすいようにコメントを付加しています）

perftestdb=> \! cat pg_sql_rightdj.sql explain (analyze) SELECT /*+ Leading((((t2 t1) t3) t4)) HashJoin(t1 t2 t3 t4) */ t1.id , t1.t1_c1 , t2.s_id , t2.t2_c1 , t3.b_id , t3.t3_c1 , t4.a_id , t4.c_id , t4.t4_c1 FROM t1 INNER JOIN t2 ON t1.id = t2.id INNER JOIN t3 ON t1.id = t3.id INNER JOIN t4 ON t1.id = t4.id ; perftestdb=> \i pg_sql_rightdj.sql QUERY PLAN ---------------------------------------------------------------------------------------------------------------------- Hash Join (cost=18.73..308.66 rows=25000 width=36) (actual time=3.352..8.740 rows=25000 loops=1) Hash Cond: (t1.id = t4.id) (Probe) -> Hash Join (cost=4.47..11.91 rows=500 width=32) (actual time=2.316..2.460 rows=500 loops=1) Hash Cond: (t1.id = t3.id) (Probe) -> Hash Join (cost=1.23..2.91 rows=50 width=20) (actual time=1.534..1.562 rows=50 loops=1) Hash Cond: (t2.id = t1.id) (Probe) -> Seq Scan on t2 (cost=0.00..1.50 rows=50 width=12) (actual time=0.744..0.750 rows=50 loops=1) (Build) -> Hash (cost=1.10..1.10 rows=10 width=8) (actual time=0.723..0.724 rows=10 loops=1) Buckets: 1024 Batches: 1 Memory Usage: 9kB ★ -> Seq Scan on t1 (cost=0.00..1.10 rows=10 width=8) (actual time=0.705..0.707 rows=10 loops=1) (Build) -> Hash (cost=2.00..2.00 rows=100 width=12) (actual time=0.760..0.761 rows=100 loops=1) Buckets: 1024 Batches: 1 Memory Usage: 13kB -> Seq Scan on t3 (cost=0.00..2.00 rows=100 width=12) (actual time=0.715..0.732 rows=100 loops=1) (Build) -> Hash (cost=8.00..8.00 rows=500 width=16) (actual time=1.012..1.013 rows=500 loops=1) Buckets: 1024 Batches: 1 Memory Usage: 32kB -> Seq Scan on t4 (cost=0.00..8.00 rows=500 width=16) (actual time=0.792..0.905 rows=500 loops=1)

MySQL 8.0.32 / Right Deep Join Tree / Hash Join
できないので、なし。

次、みんさんが、見慣れている（？）、Left Deep Join Tree にすると Hash Join の実行計画は、それぞれどのように見えるのでしょうか？　比較してみましょう。

Oraclerには、わかりやすいですよね(慣れの問題かもしれませんけどもw) 。Id=4で、t1がBuild表となってt2(Probe)と結合。。。以下、t3, t4がそれぞれ、ProbeとしてHash Joinされています。
Oracle 21 / Left Deep Join Tree / Hash Join

Id=4でt1がtable full scan(Build)で、ID=5 のt2 (Probe) と結合されています。t3, t4はそれぞれのProbeとなっていることが読み取れます。;)

（実行計画の右端に (Build) なのか、　(Probe)　を確認しやすいようにコメントを付加しています）

SCOTT@orclpdb1> @ora_sql_leftdj.sql 1 SELECT 2 /*+ 3 MONITOR 4 LEADING(t1 t2 t3 t4) 5 USE_HASH(t1 t2 t3 t4) 6 NO_SWAP_JOIN_INPUTS(t4) 7 */ 8 t1.id 9 , t1.t1_c1 10 , t2.s_id 11 , t2.t2_c1 12 , t3.b_id 13 , t3.t3_c1 14 , t4.a_id 15 , t4.c_id 16 , t4.t4_c1 17 FROM 18 t1 19 INNER JOIN t2 20 ON 21 t1.id = t2.idv 22 INNER JOIN t3 23 ON 24 t1.id = t3.id 25 INNER JOIN t4 26 ON 27* t1.id = t4.id ...略... SQL Plan Monitoring Details (Plan Hash Value=894925296) ==================================================================================================================================== | Id | Operation | Name | Rows | Cost | Time | Start | Execs | Rows | Mem | Activity | Activity Detail | | | | | (Estim) | | Active(s) | Active | | (Actual) | (Max) | (%) | (# samples) | ==================================================================================================================================== | 0 | SELECT STATEMENT | | | | 2 | +0 | 1 | 25000 | . | | | | 1 | HASH JOIN | | 25000 | 12 | 2 | +0 | 1 | 25000 | 1MB | | | | 2 | HASH JOIN | | 500 | 9 | 1 | +0 | 1 | 500 | 1MB | | | (Build) | 3 | HASH JOIN | | 50 | 6 | 1 | +0 | 1 | 50 | 1MB | | | (Build) | 4 | TABLE ACCESS FULL | T1 | 10 | 3 | 1 | +0 | 1 | 10 | . | | | (Build) | 5 | TABLE ACCESS FULL | T2 | 50 | 3 | 1 | +0 | 1 | 50 | . | | | (Probe) | 6 | TABLE ACCESS FULL | T3 | 100 | 3 | 1 | +0 | 1 | 100 | . | | | (Probe) | 7 | TABLE ACCESS FULL | T4 | 500 | 3 | 2 | +0 | 1 | 500 | . | | | (Probe) ====================================================================================================================================

PostgreSQL 13.4 / pg_hint_plan 1.3.9 / Left Deep Join Tree / Hash Join
★ のある行で、t1がSeq Scanされ、その上位の行で、Hashが作成されているので、Buildとなっていることがわかります。次に、同一階層で t2がSeq ScanされHash Joinされています。
t3, t4はそれぞれProbeになっていることが読み取れます。ぱっと見は、Oracleの ight Deep Join Tree で見られる実行計画の形に似てますが。。。(^^;;;;

（実行計画の左端に (Build) なのか、　(Probe)　を確認しやすいようにコメントを付加しています）

perftestdb=> \! cat pg_sql_leftdj.sql explain (analyze) SELECT /*+ Leading((t4 (t3 (t2 t1)))) HashJoin(t2 t1 t3 t4) */ t1.id , t1.t1_c1 , t2.s_id , t2.t2_c1 , t3.b_id , t3.t3_c1 , t4.a_id , t4.c_id , t4.t4_c1 FROM t1 INNER JOIN t2 ON t1.id = t2.id INNER JOIN t3 ON t1.id = t3.id INNER JOIN t4 ON t1.id = t4.id ; perftestdb=> perftestdb=> \i pg_sql_leftdj.sql QUERY PLAN ---------------------------------------------------------------------------------------------------------------------------------- Hash Join (cost=17.66..308.16 rows=25000 width=36) (actual time=0.522..8.362 rows=25000 loops=1) Hash Cond: (t4.id = t1.id) (Probe) -> Seq Scan on t4 (cost=0.00..8.00 rows=500 width=16) (actual time=0.012..0.101 rows=500 loops=1) (Build) -> Hash (cost=11.41..11.41 rows=500 width=32) (actual time=0.462..0.467 rows=500 loops=1) Buckets: 1024 Batches: 1 Memory Usage: 40kB -> Hash Join (cost=3.54..11.41 rows=500 width=32) (actual time=0.122..0.328 rows=500 loops=1) Hash Cond: (t3.id = t1.id) (Probe) -> Seq Scan on t3 (cost=0.00..2.00 rows=100 width=12) (actual time=0.004..0.017 rows=100 loops=1) (Build) -> Hash (cost=2.91..2.91 rows=50 width=20) (actual time=0.098..0.102 rows=50 loops=1) Buckets: 1024 Batches: 1 Memory Usage: 11kB -> Hash Join (cost=1.23..2.91 rows=50 width=20) (actual time=0.039..0.068 rows=50 loops=1) Hash Cond: (t2.id = t1.id) (Probe) -> Seq Scan on t2 (cost=0.00..1.50 rows=50 width=12) (actual time=0.005..0.011 rows=50 loops=1) (Build) -> Hash (cost=1.10..1.10 rows=10 width=8) (actual time=0.016..0.018 rows=10 loops=1) Buckets: 1024 Batches: 1 Memory Usage: 9kB ★ -> Seq Scan on t1 (cost=0.00..1.10 rows=10 width=8) (actual time=0.003..0.004 rows=10 loops=1)

MySQL 8.0.32 / Left Deep Join Tree / Hash Join
これは、前回のエントリーでも紹介した無理やり Hash Join にした例なので、特に解説はしませんが、PostgreSQLに類似した実行計画になっていますよね。

現状、MySQLは、HASH JOIN を強制するヒント、Build/Probeを制御するヒント、PostgreSQLのように結合順の優先順位を細かく指定するヒントもないため、Nested Loop Join にならないようヒントで制御するしか Hash Join を強制する方法はなさそうです。
Left Deep Join Tree にしかならないのでこともあり、Hash Join で、 Bushy Join Treeや、Right Deep Join Treeのようなチューニングはできないですね。

実際、関わった案件で、Hash Join が選択されたのは良いと思うけど、Build/Probeを入れ替えられたら、もっとサクッと終わるはずなのに、と言う状況になって初めて、この事実を知りました。（なので、このエントリー書いているのですけどもw）
できないのかよ。。とw

以下実行計画の ★ を付与した行で、t1がTable Scanされ、その上位の行で、Hashが作成されているので、Buildとなっていることがわかります。次に、同一階層で t2がTable Scan後に、Hash Joinされています。
t3, t4は、Probeになっていることも読み取れます。PostgreSQLの実行計画の表示方法に類似してますよね。

（実行計画の左端に (Build) なのか、　(Probe)　を確認しやすいようにコメントを付加しています）

mysql> \! cat my_sql_leftdj.sql explain analyze SELECT /*+ JOIN_ORDER(t1,t2,t3,t4) NO_JOIN_INDEX(t2 primary) NO_JOIN_INDEX(t3 primary) NO_JOIN_INDEX(t4 primary) */ t1.id , t1.t1_c1 , t2.s_id , t2.t2_c1 , t3.b_id , t3.t3_c1 , t4.a_id , t4.c_id , t4.t4_c1 FROM t1 INNER JOIN t2 ON t1.id = t2.id INNER JOIN t3 ON t1.id = t3.id INNER JOIN t4 ON t1.id = t4.id ; mysql> \. my_sql_leftdj.sql +-----------------------------------------------------------------------------------------------------------------------+ | EXPLAIN | +-----------------------------------------------------------------------------------------------------------------------+ | -> Inner hash join (t4.id = t1.id) (cost=25552.55 rows=25000) (actual time=0.643..5.045 rows=25000 loops=1) (Probe) -> Table scan on t4 (cost=0.01 rows=500) (actual time=0.052..0.346 rows=500 loops=1) (Build) -> Hash -> Inner hash join (t3.id = t1.id) (cost=551.75 rows=500) (actual time=0.216..0.380 rows=500 loops=1) (Probe) -> Table scan on t3 (cost=0.03 rows=100) (actual time=0.041..0.069 rows=100 loops=1) (Build) -> Hash -> Inner hash join (t2.id = t1.id) (cost=51.50 rows=50) (actual time=0.100..0.141 rows=50 loops=1) (Probe) -> Table scan on t2 (cost=0.08 rows=50) (actual time=0.026..0.041 rows=50 loops=1) (Build) -> Hash ★ -> Table scan on t1 (cost=1.25 rows=10) (actual time=0.039..0.047 rows=10 loops=1) | +-----------------------------------------------------------------------------------------------------------------------+

Bushy Joinのも書こうと思ってましたが、前回ので十分そうなので、省略。（Left/Right Join Treeのミックスですし）MySQLは、Right Deep Join Treeにはならないので、結果なしです。

と言うことで、
Advent Calendar 2023 / Day 17向けの準備運動的な予習（その３）はここまで。

では、また。

関連エントリー

・標準はあるにはあるが癖の多いSQL 全部俺　#1 Pagination
・標準はあるにはあるが癖の多いSQL 全部俺　#2 関数名は同じでも引数が逆の罠！
・標準はあるにはあるが癖の多いSQL 全部俺　#3 データ型確認したい時あるんです
・標準はあるにはあるが癖の多いSQL 全部俺　#4 リテラル値での除算の内部精度も違うのよ!
・標準はあるにはあるが癖の多いSQL 全部俺　#5 和暦変換機能ある方が少数派
・標準はあるにはあるが癖の多いSQL 全部俺　#6 時間厳守！
・標準はあるにはあるが癖の多いSQL 全部俺　#7 期間リテラル！
・標準はあるにはあるが癖の多いSQL 全部俺　#8 翌月末日って何日？
・標準はあるにはあるが癖の多いSQL 全部俺　#9 部分文字列の扱いでも癖が出る＞＜
・標準はあるにはあるが癖の多いSQL 全部俺　#10 文字列連結の罠（有名なやつ）
・標準はあるにはあるが癖の多いSQL 全部俺　#11 デュエル、じゃなくて、デュアル
・標準はあるにはあるが癖の多いSQL 全部俺　#12 文字[列]探すにも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#13 あると便利ですが意外となかったり
・標準はあるにはあるが癖の多いSQL 全部俺　#14 連番の集合を返すにも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#15 SQL command line client
・標準はあるにはあるが癖の多いSQL 全部俺　#16 SQLのレントゲンを撮る方法
・標準はあるにはあるが癖の多いSQL 全部俺　#17 その空白は許されないのか？
・標準はあるにはあるが癖の多いSQL 全部俺　#18 (+)の外部結合は方言
・標準はあるにはあるが癖の多いSQL 全部俺　#19 帰ってきた、部分文字列の扱いでも癖w
・標準はあるにはあるが癖の多いSQL 全部俺　#20 結果セットを単一列に連結するにも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#21 演算結果にも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#22 集合演算にも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#23 複数行INSERTにも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#24 乱数作るにも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#25 SQL de Fractalsにも癖がある:)
・標準はあるにはあるが癖の多いSQL 全部俺　おまけ SQL de 湯婆婆やるにも癖がでるw
・帰ってきた！標準はあるにはあるが癖の多いSQL #1 SQL de ROT13 やるにも癖が出るw
・帰ってきた！標準はあるにはあるが癖の多いSQL #2 Actual Plan取得中のキャンセルでも癖が出る
・帰ってきた！標準はあるにはあるが癖の多いSQL #3 オプティマイザの結合順評価テーブル数上限にも癖が出る
・帰ってきた！標準はあるにはあるが癖の多いSQL #4 Optimizer Traceの取得でも癖がでる
・帰ってきた！標準はあるにはあるが癖の多いSQL #5 - Optimizer Hint でも癖が多い
・帰ってきた！標準はあるにはあるが癖の多いSQL #6 - Hash Joinの結合ツリーにも癖がでる

投稿日時 2023年12月10日 (日) 11時25分 Oracle, チューニング, SQL, MySQL, PostgreSQL, パフォーマンス, Advent Calendar | 固定リンク | 0 | コメント (0)

2023年12月 9日 (土)

帰ってきた！標準はあるにはあるが癖の多いSQL #6 - Hash Joinの結合ツリーにも癖がでる

本エントリーは、MySQL Advent Calendar 2023 シリーズ2 / Day 9とPostgreSQL Advent Calendar 2023 シリーズ2 / Day 9へのクロスポスト、および、JPOUG Advent Calendar 2023 / Day 9 の裏番組　（ADVENTARはシリーズ増やせないので）　エントリーで、12/17日向けの　予習　その２　という位置付けのエントリーです。

予習　その１は、以下。
帰ってきた！標準はあるにはあるが癖の多いSQL #5 - Optimizer Hint でも癖が多い

少し前に、MySQLでもHash Joinになるんだね。といいうエントリーを書きました。覚えてますか？　
MySQL 8.0.32では NLJに使えるINDEXが存在していても、Hash Joinをヒントで強制することができる！（オプティマイザが選択することもある！）

その時点では、

MySQLのHash Joinを強制するオプティマイザーヒントも廃止されているようだし、Build/Probeの制御もできないよね？ヒントないし。
とか、
オプティマイザーヒントで強制できないけど、オプティマイザーが勝手に選んじゃうこともあるのか〜、NLJに利用できる索引あっても。。
勝手に選ばれることはあってもヒントではもろもろ制御できない。最初に戻る。

という状況ループ状態でしたw

そこで、閃いたのが、MySQLで、Hash Joinが自動発動する条件。その条件に合う状況にすればいいじゃん。と！
Hash Joinを強制するヒントはなくても、Nested Loop Joinに使ってる主索引（MySQLの場合は主キーはクラスター索引）を、オプティマイザーヒントで無効化してしまえば、勝手に、Hash Joinするよね！？　

という確認ばかりに目が行ってしまって、気づきませんでした！！！！

MySQLのHash Joinの実行計画ツリーを見て、Oracle/PostgreSQLと違う点、何か気づきませんか？　
みなさん！　これ試験に出ますよw（嘘
答え合わせは後半でw

それでは、環境づくりから（少々長めですw）
それぞれの DB（ Oracle Database 21c / PostgreSQL 13.4 with pg_hint_plan 1.3.9 / MySQL 8.0.32 ）で、そのまま実行できるDDLにしてあります。
表と索引作成（各DB共通）、データ登録、そして、統計取得まで行っています。

Oracle/PostgreSQL/MySQL共通DDL

cre_advent_tabs.sql -- 10 rows CREATE TABLE t1 ( id INT NOT NULL , t1_c1 INT NOT NULL , CONSTRAINT t1_pk PRIMARY KEY (id) ); -- 50 rows CREATE TABLE t2 ( id INT NOT NULL , s_id INT NOT NULL , t2_c1 INT NOT NULL , CONSTRAINT t2_pk PRIMARY KEY (id, s_id) ); -- 100 rows CREATE TABLE t3 ( id INT NOT NULL , b_id INT NOT NULL , t3_c1 INT NOT NULL , CONSTRAINT t3_pk PRIMARY KEY (id, b_id) ); -- 500 rows CREATE TABLE t4 ( id INT NOT NULL , a_id INT NOT NULL , c_id INT NOT NULL , t4_c1 INT NOT NULL , CONSTRAINT t4_pk PRIMARY KEY (id, a_id, c_id) ); -- 1000 rows CREATE TABLE t0 ( id INT NOT NULL , m_id INT NOT NULL , t0_c1 INT NOT NULL , CONSTRAINT t0_pk PRIMARY KEY (id, m_id) );

Oracle 21c向けデータ登録と統計取得からデータ件数確認までのスクリプトと実行例

make_data4oracle.sql -- for t1 BEGIN FOR i IN 1..10 LOOP INSERT INTO t1 VALUES(i,i); END LOOP; COMMIT; DBMS_STATS.GATHER_TABLE_STATS(ownname=>'SCOTT', tabname=>'T1', cascade=>true, no_invalidate=>false); END; / SELECT COUNT(1) FROM t1; -- for t2 BEGIN FOR i IN 1..10 LOOP FOR j IN 1..5 LOOP INSERT INTO t2 VALUES(i,j,i+j); END LOOP; END LOOP; COMMIT;v DBMS_STATS.GATHER_TABLE_STATS(ownname=>'SCOTT', tabname=>'T2', cascade=>true, no_invalidate=>false); END; / SELECT COUNT(1) FROM t2; -- for t3 BEGINv FOR i IN 1..10 LOOP FOR j IN 1..10 LOOP INSERT INTO t3 VALUES(i,j,i+j); END LOOP; END LOOP; COMMIT; DBMS_STATS.GATHER_TABLE_STATS(ownname=>'SCOTT', tabname=>'T3', cascade=>true, no_invalidate=>false); END; / SELECT COUNT(1) FROM t3; -- for t4 BEGIN FOR i IN 1..10 LOOP FOR j IN 1..10 LOOP FOR k IN 1..5 LOOP INSERT INTO t4 VALUES(i,j,k,i+j); END LOOP; END LOOP; COMMIT; END LOOP; DBMS_STATS.GATHER_TABLE_STATS(ownname=>'SCOTT', tabname=>'T4', cascade=>true, no_invalidate=>false); END; / SELECT COUNT(1) FROM t4; -- for t0 BEGIN FOR i IN 1..10 LOOP FOR j IN 1..100 LOOP INSERT INTO t0 VALUES(i,j,i+j); END LOOP; COMMIT; END LOOP; DBMS_STATS.GATHER_TABLE_STATS(ownname=>'SCOTT', tabname=>'T0', cascade=>true, no_invalidate=>false); END; / SELECT COUNT(1) FROM t0;

SCOTT@orclpdb1> @make_data4oracle PL/SQLプロシージャが正常に完了しました。 COUNT(1) ---------- 10 PL/SQLプロシージャが正常に完了しました。 COUNT(1) ---------- 50 PL/SQLプロシージャが正常に完了しました。 COUNT(1) ---------- 100 PL/SQLプロシージャが正常に完了しました。 COUNT(1) ---------- 500 PL/SQLプロシージャが正常に完了しました。 COUNT(1) ---------- 1000

PostgreSQL 13.4向けデータ登録と統計取得からデータ件数確認までのスクリプトと実行例

perftestdb=> \i cre_advent_tabs.sql CREATE TABLE CREATE TABLE CREATE TABLE CREATE TABLE CREATE TABLE perftestdb=>

PostgreSQL向けデータ登録と統計取得からデータ件数確認までのスクリプトと実行例

make_data4postgresql.sql -- for t1 DO $$ BEGIN FOR i IN 1..10 LOOP INSERT INTO t1 VALUES(i,i); END LOOP; COMMIT; END $$ ; VACUUM VERBOSE ANALYZE t1; SELECT COUNT(1) FROM t1; -- for t2 DO $$ BEGIN FOR i IN 1..10 LOOP FOR j IN 1..5 LOOP INSERT INTO t2 VALUES(i,j,i+1); END LOOP; END LOOP; COMMIT; END $$ ; VACUUM VERBOSE ANALYZE t2; SELECT COUNT(1) FROM t2; -- for t3 DO $$ BEGIN FOR i IN 1..10 LOOP FOR j IN 1..10 LOOP INSERT INTO t3 VALUES(i,j,i+1); END LOOP; END LOOP; COMMIT; END $$ ; VACUUM VERBOSE ANALYZE t3; SELECT COUNT(1) FROM t3; -- for t4 DO $$ BEGIN FOR i IN 1..10 LOOP FOR j IN 1..10 LOOP FOR k IN 1..5 LOOP INSERT INTO t4 VALUES(i,j,k,i+j); END LOOP; END LOOP; COMMIT; END LOOP; END $$ ; VACUUM VERBOSE ANALYZE t4; SELECT COUNT(1) FROM t4; -- for t0 DO $$ BEGIN FOR i IN 1..10 LOOP FOR j IN 1..100 LOOP INSERT INTO t0 VALUES(i,j,i+j); END LOOP; COMMIT; END LOOP; END $$ ; VACUUM VERBOSE ANALYZE t0; SELECT COUNT(1) FROM t0;

perftestdb=> \i make_data4postgresql.sql DO psql:make_data4postgresql.sql:12: INFO: vacuuming "public.t1" psql:make_data4postgresql.sql:12: INFO: "t1": found 0 removable, 10 nonremovable row versions in 1 out of 1 pages DETAIL: 0 dead row versions cannot be removed yet, oldest xmin: 530026 There were 0 unused item identifiers. Skipped 0 pages due to buffer pins, 0 frozen pages. 0 pages are entirely empty. CPU: user: 0.00 s, system: 0.00 s, elapsed: 0.00 s. psql:make_data4postgresql.sql:12: INFO: analyzing "public.t1" psql:make_data4postgresql.sql:12: INFO: "t1": scanned 1 of 1 pages, containing 10 live rows and 0 dead rows; 10 rows in sample, 10 estimated total rows VACUUM count ------- 10 (1 行) DO psql:make_data4postgresql.sql:30: INFO: vacuuming "public.t2" psql:make_data4postgresql.sql:30: INFO: "t2": found 0 removable, 50 nonremovable row versions in 1 out of 1 pages DETAIL: 0 dead row versions cannot be removed yet, oldest xmin: 530028 There were 0 unused item identifiers. Skipped 0 pages due to buffer pins, 0 frozen pages. 0 pages are entirely empty. CPU: user: 0.00 s, system: 0.00 s, elapsed: 0.00 s. psql:make_data4postgresql.sql:30: INFO: analyzing "public.t2" psql:make_data4postgresql.sql:30: INFO: "t2": scanned 1 of 1 pages, containing 50 live rows and 0 dead rows; 50 rows in sample, 50 estimated total rows VACUUM count ------- 50 (1 行) DO psql:make_data4postgresql.sql:48: INFO: vacuuming "public.t3" psql:make_data4postgresql.sql:48: INFO: "t3": found 0 removable, 100 nonremovable row versions in 1 out of 1 pages DETAIL: 0 dead row versions cannot be removed yet, oldest xmin: 530030 There were 0 unused item identifiers. Skipped 0 pages due to buffer pins, 0 frozen pages. 0 pages are entirely empty. CPU: user: 0.00 s, system: 0.00 s, elapsed: 0.00 s. psql:make_data4postgresql.sql:48: INFO: analyzing "public.t3" psql:make_data4postgresql.sql:48: INFO: "t3": scanned 1 of 1 pages, containing 100 live rows and 0 dead rows; 100 rows in sample, 100 estimated total rows VACUUM count ------- 100 (1 行) DO psql:make_data4postgresql.sql:67: INFO: vacuuming "public.t4" psql:make_data4postgresql.sql:67: INFO: "t4": found 0 removable, 500 nonremovable row versions in 3 out of 3 pages DETAIL: 0 dead row versions cannot be removed yet, oldest xmin: 530041 There were 0 unused item identifiers. Skipped 0 pages due to buffer pins, 0 frozen pages. 0 pages are entirely empty. CPU: user: 0.00 s, system: 0.00 s, elapsed: 0.00 s. psql:make_data4postgresql.sql:67: INFO: analyzing "public.t4" psql:make_data4postgresql.sql:67: INFO: "t4": scanned 3 of 3 pages, containing 500 live rows and 0 dead rows; 500 rows in sample, 500 estimated total rows VACUUM count ------- 500 (1 行) DO psql:make_data4postgresql.sql:85: INFO: vacuuming "public.t0" psql:make_data4postgresql.sql:85: INFO: "t0": found 0 removable, 1000 nonremovable row versions in 6 out of 6 pages DETAIL: 0 dead row versions cannot be removed yet, oldest xmin: 530052 There were 0 unused item identifiers. Skipped 0 pages due to buffer pins, 0 frozen pages. 0 pages are entirely empty. CPU: user: 0.00 s, system: 0.00 s, elapsed: 0.00 s. psql:make_data4postgresql.sql:85: INFO: analyzing "public.t0" psql:make_data4postgresql.sql:85: INFO: "t0": scanned 6 of 6 pages, containing 1000 live rows and 0 dead rows; 1000 rows in sample, 1000 estimated total rows VACUUM count ------- 1000 (1 行)

MySQL 8.0.32向けデータ登録と統計取得からデータ件数確認までのスクリプトと実行例

mysql> \. cre_advent_tabs.sql Query OK, 0 rows affected (0.06 sec) Query OK, 0 rows affected (0.05 sec) Query OK, 0 rows affected (0.05 sec) Query OK, 0 rows affected (0.04 sec) Query OK, 0 rows affected (0.07 sec) mysql>

MySQL向けデータ登録と統計取得からデータ件数確認までのスクリプトと実行例

make_data4mysql.sql DELIMITER // CREATE PROCEDURE make_data4mysql() BEGIN DECLARE i, j, k INT; -- for t1 SET i = 1; WHILE i <= 10 DO INSERT INTO t1 VALUES(i,i); SET i = i + 1; END WHILE; COMMIT; -- for t2 SET i = 1; WHILE i <= 10 DO SET j = 1; WHILE j <= 5 DO INSERT INTO t2 VALUES(i,j,i+1); SET j = j + 1; END WHILE; SET i = i + 1; END WHILE; COMMIT; -- for t3 SET i = 1; WHILE i <= 10 DO SET j = 1; WHILE j <= 10 DO INSERT INTO t3 VALUES(i,j,i+1); SET j = j + 1; END WHILE; SET i = i + 1; END WHILE; COMMIT; -- for t4 SET i = 1; WHILE i <= 10 DO SET j = 1; WHILE j <= 10 DO SET k = 1; WHILE k <= 5 DO INSERT INTO t4 VALUES(i,j,k,i+j); SET k = k + 1; END WHILE; SET j = j + 1; END WHILE; SET i = i + 1; COMMIT; END WHILE; -- for t0 SET i = 1; WHILE i <= 10 DO SET j = 1; WHILE j <= 100 DO INSERT INTO t0 VALUES(i,j,i+j); SET j = j + 1; END WHILE; SET i = i + 1; COMMIT; END WHILE; END // DELIMITER ; CALL make_data4mysql(); ANALYZE TABLE t1, t2, t3, t4, t0; SELECT COUNT(1) FROM t1; SELECT COUNT(1) FROM t2; SELECT COUNT(1) FROM t3; SELECT COUNT(1) FROM t4; SELECT COUNT(1) FROM t0; DROP PROCEDURE make_data4mysql;

mysql> \. make_data4mysql.sql Query OK, 0 rows affected (0.03 sec) Query OK, 0 rows affected (11.20 sec) +---------------+---------+----------+----------+ | Table | Op | Msg_type | Msg_text | +---------------+---------+----------+----------+ | perftestdb.t1 | analyze | status | OK | | perftestdb.t2 | analyze | status | OK | | perftestdb.t3 | analyze | status | OK | | perftestdb.t4 | analyze | status | OK | | perftestdb.t0 | analyze | status | OK | +---------------+---------+----------+----------+ 5 rows in set (0.07 sec) +----------+ | COUNT(1) | +----------+ | 10 | +----------+ 1 row in set (0.01 sec) +----------+ | COUNT(1) | +----------+ | 50 | +----------+ 1 row in set (0.00 sec) +----------+ | COUNT(1) | +----------+ | 100 | +----------+ 1 row in set (0.02 sec) +----------+ | COUNT(1) |v+----------+ | 500 | +----------+ 1 row in set (0.01 sec) +----------+ | COUNT(1) | +----------+ | 1000 | +----------+ 1 row in set (0.02 sec) Query OK, 0 rows affected (0.01 sec) mysql>
準備できた！

実行計画を理解するための参考
（Oracleのマニュアルで解説されているBushy Join Treeは、Zigzag Join Treeと言われている結合ツリーに見えますよね。Oracleは、Bushy/Zigzagは区別してなさそう）

参考）
Hash JoinのBuild/Probeって何？　という方は、以下も読んでおくと良いです

Oracle Database Release 23 / SQL Tuning Guide - 9.2.2.2.2 Hash Join: Basic Steps

https://docs.oracle.com/en/database/oracle/oracle-database/23/tgsql/joins.html#GUID-9EE5CD4C-B90C-4E61-83DC-BD585D79635C

結合ツリーついて

Oracle Database Release 23 / SQL Tuning Guide - 9.1.1 Join Trees

https://docs.oracle.com/en/database/oracle/oracle-database/23/tgsql/joins.html#GUID-31B0F249-A5AA-41E9-AE98-A484FC5C487C

では最初に、Oracle Database 21cから。
それっぽいの形にしたHash Joinの実行計画をお見せします。
これは、Oracleのマニュアルで言うと、Bushy Join Tree です。

SCOTT@orclpdb1> @ora_sql_hj.sql 1 SELECT 2 /*+ 3 MONITOR 4 USE_HASH(t1 t2 t3 t4) 5 */ 6 t1.id 7 , t1.t1_c1 8 , t2.s_id 9 , t2.t2_c1 10 , t3.b_id 11 , t3.t3_c1 12 , t4.a_id 13 , t4.c_id 14 , t4.t4_c1 15 FROM 16 t1 17 INNER JOIN t2 18 ON 19 t1.id = t2.id 20 INNER JOIN t3 21 ON 22 t1.id = t3.id 23 INNER JOIN t4 24 ON 25* t1.id = t4.id ...略... SQL Plan Monitoring Details (Plan Hash Value=122725940) =================================================================================================================================================== | 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 | | | | 1 | +0 | 1 | 25000 | | | . | | | | 1 | HASH JOIN | | 25000 | 12 | 1 | +0 | 1 | 25000 | | | 1MB | | | | 2 | TABLE ACCESS FULL | T4 | 500 | 3 | 1 | +0 | 1 | 500 | 2 | 49152 | . | | | | 3 | HASH JOIN | | 500 | 9 | 1 | +0 | 1 | 500 | | | 1MB | | | | 4 | HASH JOIN | | 50 | 6 | 1 | +0 | 1 | 50 | | | 1MB | | | | 5 | TABLE ACCESS FULL | T1 | 10 | 3 | 1 | +0 | 1 | 10 | 2 | 49152 | . | | | | 6 | TABLE ACCESS FULL | T2 | 50 | 3 | 1 | +0 | 1 | 50 | 2 | 49152 | . | | | | 7 | TABLE ACCESS FULL | T3 | 100 | 3 | 1 | +0 | 1 | 100 | 2 | 49152 | . | | | ===================================================================================================================================================

上記の解説

Id=5 T1をTable Full Scan (Build表)
Id=6 T2をTable Full Scan (Probe表).
Id=4 T1とT2をHash Join (on memoryでHash Join完了）

Id=4 Id=5,6のHash Joinの結果(Build表)
Id=7 T3をTable Full Scan (Probe表)
Id=3 Id=4の結合結果とT3をHash Join (on memoryでHash Join完了）

Id=2 T4をTable Full Scan (Build表)
Id=3 Id=4の結合結果とT3の結合結果 (Probe表)
Id=2 T4とId=3の結合結果をHash Join (On memoryでHash Join完了）

という順序なので、
引用したOracleのマニュアルで言う、Bushy Join Tree になっています。
Oracleのマニュアルでは、Bushy Join Treeとなっていますが、他では、Zigzag Join Treeとして分類されていたりするツリーです。。LeftとRight Deep Join TreeがMixされた形ですよね、これ。

これを結合ツリーで書くと、以下のようになります。

次は、PostgreSQL 13.4 with pg_hint_plan 1.3.9で同じくHash Joinになるようにヒントで強制した実行計画です。

この結合ツリーは、Bushy Join Treeですね。

perftestdb=> \! cat pg_sql_hj.sql explain (analyze) SELECT /*+ HashJoin(t1 t2 t3 t4) */ t1.id , t1.t1_c1 , t2.s_id , t2.t2_c1 , t3.b_id , t3.t3_c1 , t4.a_id , t4.c_id , t4.t4_c1 FROM t1 INNER JOIN t2 ON t1.id = t2.id INNER JOIN t3 ON t1.id = t3.id INNER JOIN t4 ON t1.id = t4.id ; perftestdb=> \i pg_sql_hj.sql QUERY PLAN ----------------------------------------------------------------------------------------------------------------------- Id=1 Hash Join (cost=17.48..309.84 rows=25000 width=36) (actual time=3.405..10.466 rows=25000 loops=1) Hash Cond: (t1.id = t2.id) Id=2 -> Hash Join (cost=1.23..11.09 rows=500 width=24) (actual time=1.696..1.989 rows=500 loops=1) Hash Cond: (t4.id = t1.id) Id=3 -> Seq Scan on t4 (cost=0.00..8.00 rows=500 width=16) (actual time=0.907..0.993 rows=500 loops=1) Id=4 -> Hash (cost=1.10..1.10 rows=10 width=8) (actual time=0.721..0.722 rows=10 loops=1) Buckets: 1024 Batches: 1 Memory Usage: 9kB Id=5 -> Seq Scan on t1 (cost=0.00..1.10 rows=10 width=8) (actual time=0.705..0.707 rows=10 loops=1) Id=6 -> Hash (cost=10.00..10.00 rows=500 width=24) (actual time=1.687..1.687 rows=500 loops=1) Buckets: 1024 Batches: 1 Memory Usage: 36kB Id=7 -> Hash Join (cost=2.12..10.00 rows=500 width=24) (actual time=1.400..1.554 rows=500 loops=1) Hash Cond: (t3.id = t2.id) Id=8 -> Seq Scan on t3 (cost=0.00..2.00 rows=100 width=12) (actual time=0.701..0.712 rows=100 loops=1) Id=9 -> Hash (cost=1.50..1.50 rows=50 width=12) (actual time=0.679..0.680 rows=50 loops=1) Buckets: 1024 Batches: 1 Memory Usage: 11kB Id=10 -> Seq Scan on t2 (cost=0.00..1.50 rows=50 width=12) (actual time=0.648..0.656 rows=50 loops=1)

解説しやすいように実行計画のノードにIdを振っています:)

Oracleの実行計画と大きく違うのは、Build表とProbe表の順序です。Oracleの場合、同一階層の上位が、Build表で、その下にProbe表がリストされますが、
PostgreSQL(MySQLも同様）では、同一階層上で、Probe表が上位に、その下に Hash（ハッシュ表を作成している操作。Oracleでは実行計画上この操作は現れません）、さらにその下位階層にBuild表のTable Full scanという形で表現されています。
階層の一番深い部分から実行されるので、上記例だと、Id=16のt2（Build表）のSeq Scan (Oracleで言うTable Full Scanが最初に実行され、次に、Id=15のHashが行われていることがわかります。

Id=10 t2 Seq Scan (Oracleで言うTable Full Scan)
Id=9 Id=10の結果を元にHash表作成　（つまり、t2がBuild)
Id=8 t3 Seq Scan (Probe)
Id=7 t2, t3をHash Join

Id=6 Id=7(t2, t3のHash Join)の結果を元にHash表作成（Build)

Id=5 t1 Seq Scan
Id=4 Id=5の結果を元にHash表作成（Build）
Id=3 t4 Seq Scan (Probe)
Id=2 t1, t4をHash Join

Id=1 Id=6の結果(Build), Id=2の結果（Probe)としてHash Join

こうやって1Step毎に追っていくと、OracleとPostgreSQLの実行計画のTree listで、Hash JoinのBuildとProbeの位置が異なっていることに気づきやすいですよね。（ちなみに、MySQLのTree formatも同様です）

これを結合ツリーで書くと、以下のようになります。

最後に、MySQL 8.0.32です。
Hash Joinを強制する直接的なヒントも、Budling/Probe表を制御するヒントも方法存在しませんが、Hash Joinになるよう結合順を指定した上で、Nested Loop Joinになってしまうのを抑止するために、Nested Loop Joindで利用する主キー索引の利用を抑止しました。
（MySQLの主キーはクラスター索引なので、主キーがNested Loop Joinに利用される場合、索引の利用を抑止するには、NO_JOIN_INDEXヒントで primary を指定する必要があります）

なお、JOIN_ORDERヒントで結合順を指定した理由は、結合順を指定することでNested Loop Joinに利用される主キー(primary)を、NO_JOIN_INDEXヒントで確実抑止したかったためです。

ちなみに、この結合ツリーは、Left Deep Join Treeですね。

mysql> \! cat my_sql_leftdj.sql explain analyze SELECT /*+ JOIN_ORDER(t1,t2,t3,t4) NO_JOIN_INDEX(t2 primary) NO_JOIN_INDEX(t3 primary) NO_JOIN_INDEX(t4 primary) */ t1.id , t1.t1_c1 , t2.s_id , t2.t2_c1 , t3.b_id , t3.t3_c1 , t4.a_id , t4.c_id , t4.t4_c1 FROM t1 INNER JOIN t2 ON t1.id = t2.id INNER JOIN t3 ON t1.id = t3.id INNER JOIN t4 ON t1.id = t4.id ; mysql> \. my_sql_leftdj.sql +-----------------------------------------------------------------------------------------------------------------------+ | EXPLAIN | +-----------------------------------------------------------------------------------------------------------------------+ Id=1 | -> Inner hash join (t4.id = t1.id) (cost=25552.55 rows=25000) (actual time=0.643..5.045 rows=25000 loops=1) Id=2 -> Table scan on t4 (cost=0.01 rows=500) (actual time=0.052..0.346 rows=500 loops=1) Id=3 -> Hash Id=4 -> Inner hash join (t3.id = t1.id) (cost=551.75 rows=500) (actual time=0.216..0.380 rows=500 loops=1) Id=5 -> Table scan on t3 (cost=0.03 rows=100) (actual time=0.041..0.069 rows=100 loops=1) Id=6 -> Hash Id=7 -> Inner hash join (t2.id = t1.id) (cost=51.50 rows=50) (actual time=0.100..0.141 rows=50 loops=1) Id=8 -> Table scan on t2 (cost=0.08 rows=50) (actual time=0.026..0.041 rows=50 loops=1) Id=9 -> Hash Id=10 -> Table scan on t1 (cost=1.25 rows=10) (actual time=0.039..0.047 rows=10 loops=1) | +-----------------------------------------------------------------------------------------------------------------------+

既にお分かりだと思いますが、答え合わせです。:)

OracleのRight Deep Joinに見慣れている皆さん（私も含むw）が、Right Deep Joinと勘違いしちゃうケースはありますが、Build表とProbe表の現れる位置が、Oracleの実行計画と逆なんですよね。
（何度見ても、OracleでRight Deep Join Treeにした実行計画の形とダブってしまって、慣れないw）
このような形になっているHash Joinの実行計画って、PostgreSQLも含め、Left Deep Join Treeなんですよね。

参考）MySQLが、Left Deep Join Treeにしかならない理由はこれ。
Chapter 4. Query Performance Optimization The execution plan
https://www.oreilly.com/library/view/high-performance-mysql/9780596101718/ch04.html#how_mysql_joins_multiple_table
"MySQL always begins with one table and finds matching rows in the next table. Thus, MySQL’s query execution plans always take the form of a left-deep tree"とあります。

Nested Loop Joinって、Left Deep Join Treeになるから、MySQLだとHash Joinでも、 Left Deep Join Treeなのかなぁ。と。ただ、一時期、クラウド方面にあるMySQL互換で、HASH_JOIN_BUILDINGとかいうヒントが加えられていたこともありました。NewSQL系でも拡張されているケースもあるようです。

前述のMySQLの実行計画を追っかけてみると、、、

Id=10 t1 Table Scan
Id=11 Id=10で読み込んだ結果からHash表を作成（つまり、t1がBuild）
Id=7,8 T2 Table Scan (Probe）してId=11とHash Join
Id=6 Id=7のHash Joinの結果からHash表作成 (Build）
Id=4,5 T3 Table Scan (Probe)してId=6とHash Join
Id=3 Id=4のHash Joinの結果からHash表作成（Build）
Id=1,2 T4 Table Scan (Probe)しId=3とHash Join

これを結合ツリーで書くと、以下のように Left Deep Treeになりまよね。
（表示されているExlplainの実行計画を見ていると、OracleのHash JoinでRight Deep Join Treeに錯覚してしまうのなんとかならんかねぇ。と思いつつ、慣れるしかないな。と言う答えしか出てこなかった。PostgreSQLも同じ表示方法だし。慣れろ→自分w）

ということで、
MySQLのHash Joinの実行計画ツリーを見て、何か気づきませんか？　
みなさん！　これ試験に出ますよw（嘘

の答えは、

MySQLは、Left Deep Join Tree　しか、しない。でした！

ざっくりとしたまとめ的なやつ
Oracle/PostgreSQL/MySQLそれぞれ、Hash Joinだけを強制して結合順はオプティマイザー任せにした場合。

Oracle/PostgreSQLは、Bushy Join Tree
データ次第では、Left/Right Deep Join Treeの可能性もあるでしょうけども。今回のケースでは、Bushy Join Tree, 細かめに分類すると、Oracleの結合ツリーは、Zigzagですね。ちなみに、Oracleには、BUSHY_JOINというヒントがあったりします（使ったことないけどw）。

MySQLは、Left Deep Join Tree にしかならんよ。と。

以下の方針が変更されない限り、変わることはなさそう。

再掲

https://www.oreilly.com/library/view/high-performance-mysql/9780596101718/ch04.html#how_mysql_joins_multiple_table
"MySQL always begins with one table and finds matching rows in the next table. Thus, MySQL’s query execution plans always take the form of a left-deep tree"

予習、その３へ続く。

では、また。:)

関連エントリー

・標準はあるにはあるが癖の多いSQL 全部俺　#1 Pagination
・標準はあるにはあるが癖の多いSQL 全部俺　#2 関数名は同じでも引数が逆の罠！
・標準はあるにはあるが癖の多いSQL 全部俺　#3 データ型確認したい時あるんです
・標準はあるにはあるが癖の多いSQL 全部俺　#4 リテラル値での除算の内部精度も違うのよ!
・標準はあるにはあるが癖の多いSQL 全部俺　#5 和暦変換機能ある方が少数派
・標準はあるにはあるが癖の多いSQL 全部俺　#6 時間厳守！
・標準はあるにはあるが癖の多いSQL 全部俺　#7 期間リテラル！
・標準はあるにはあるが癖の多いSQL 全部俺　#8 翌月末日って何日？
・標準はあるにはあるが癖の多いSQL 全部俺　#9 部分文字列の扱いでも癖が出る＞＜
・標準はあるにはあるが癖の多いSQL 全部俺　#10 文字列連結の罠（有名なやつ）
・標準はあるにはあるが癖の多いSQL 全部俺　#11 デュエル、じゃなくて、デュアル
・標準はあるにはあるが癖の多いSQL 全部俺　#12 文字[列]探すにも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#13 あると便利ですが意外となかったり
・標準はあるにはあるが癖の多いSQL 全部俺　#14 連番の集合を返すにも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#15 SQL command line client
・標準はあるにはあるが癖の多いSQL 全部俺　#16 SQLのレントゲンを撮る方法
・標準はあるにはあるが癖の多いSQL 全部俺　#17 その空白は許されないのか？
・標準はあるにはあるが癖の多いSQL 全部俺　#18 (+)の外部結合は方言
・標準はあるにはあるが癖の多いSQL 全部俺　#19 帰ってきた、部分文字列の扱いでも癖w
・標準はあるにはあるが癖の多いSQL 全部俺　#20 結果セットを単一列に連結するにも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#21 演算結果にも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#22 集合演算にも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#23 複数行INSERTにも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#24 乱数作るにも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#25 SQL de Fractalsにも癖がある:)
・標準はあるにはあるが癖の多いSQL 全部俺　おまけ SQL de 湯婆婆やるにも癖がでるw
・帰ってきた！標準はあるにはあるが癖の多いSQL #1 SQL de ROT13 やるにも癖が出るw
・帰ってきた！標準はあるにはあるが癖の多いSQL #2 Actual Plan取得中のキャンセルでも癖が出る
・帰ってきた！標準はあるにはあるが癖の多いSQL #3 オプティマイザの結合順評価テーブル数上限にも癖が出る
・帰ってきた！標準はあるにはあるが癖の多いSQL #4 Optimizer Traceの取得でも癖がでる
・帰ってきた！標準はあるにはあるが癖の多いSQL #5 - Optimizer Hint でも癖が多い

投稿日時 2023年12月 9日 (土) 00時00分 Oracle, チューニング, SQL, MySQL, PostgreSQL, パフォーマンス, Advent Calendar | 固定リンク | 0 | コメント (0)

2023年11月22日 (水)

帰ってきた！標準はあるにはあるが癖の多いSQL #5 - Optimizer Hint でも癖が多い

癖の多いSQLシリーズネタは沢山あるわけですが、今回は、Oracle/PostgreSQL/MySQLで利用可能なオプティマイザヒントのざっくりしたまとめ。

というか、Advent Calendar向けの準備運動的ななエントリーその１. 意味の同じオプティマイザーヒントを使った何かをネタにしようとしてまーすw（その２は、どうするか検討中w）

各DBの Optimizer Hint　(PostgreSQLは、pg_hint_plan拡張機能を利用）の数（特定の最適化の有効化、無効化ヒントはそれぞれ1ヒントとしてカウント。e.g. INDEX, NO_INDEXで2つとカウントする）

Oracle Database 21c : 388

（圧倒的に多いヒント。まあ、Oracle Database 8.1ぐらいからありますからねぇw 様々な最適化を制御できるようになっているということでもあるわけですけども。それにしても多いですね）

PostgreSQL with pg_hint_plan : 26

（pg_hint_planのドキュメントから拾って数得ました。これぐらいなんですね。）

MySQL 8.0.x : 37

（MySQL 8.0の Optimizer Hint には、HASH_JOIN/NO_HASH_JOINのように特定のリリースでしか使えないものなども含まれる）

MySQL系のAurora MySQL compatible, TiDBなどは、独自のヒントをいくつか追加しているものもある。e.g. HASH JOINのBUILD/PROBE表を制御するものなど。。ただし、Aurora MySQLの場合は、Vanila MySQLでHASH_JOINヒントが廃止された影響で、HASH_JOIN_BUILDINGなどの関連ヒントが廃止されるなど、各DB毎に多少温度差のある対応があり、Vanila以外のMySQLを利用する場合には利用可能な Optimizer Hint は個別に調査動作確認しておくことをお勧めする。

参考 Aurora MySQL hints（独自拡張あり）

https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Reference.Hints.html

TiDB(独自拡張あり)

https://docs.pingcap.com/ja/tidb/stable/optimizer-hints

YagabyteDB (pg_hint_planを使うようなので、Vanila PostgreSQLと同じ！)

https://docs.yugabyte.com/preview/explore/query-1-performance/pg-hint-plan/

Oracleのマニュアルでは、全量が解説されているわけではないので、v$sql_hintビューを問い合わせた結果も載せておきます。(ドキュメントのリンク貼っても、OracleさんのドキュメントURLって簡単にリンク切れになるのですが、取り敢えず貼っときますw)
YOracle Database 21c SQL Language Reference / Table 2-23 Hints by Functional Category

https://docs.oracle.com/en/database/oracle/oracle-database/21/sqlrf/Comments.html#GUID-D316D545-89E2-4D54-977F-FC97815CD62E__BABEAFGF

中には、黒魔術すぎた影響でw 指定しても無視(ヒントレポートでは、常に Error 扱い)されるヒントもあります( 参考: https://blogs.oracle.com/otnjp/post/tsushima-hakushi-11 )

（10gぐらいまでのSQLチューニング経験者なら一度ぐらいは聞いたことがあるかもしれねい、BYPASS_UJVC ヒントが有名ですね. ちなみに、このヒント単体で使うと単純に無視されヒントレーポートにも現れません。なお、v$sql_hintには残されていますw）

DISCUS@ORCLCDB> select * from v$sql_hint order by name; NAME SQL_FEATURE CLASS INVERSE TARGET_LEVEL PROPERTY VERSION VERSION_OU ---------------------------------------- ------------------------------ ------------------------------ ------------------------------ ------------ ---------- ---------- ---------- ADAPTIVE_PLAN QKSFM_ADAPTIVE_PLAN ADAPTIVE_PLAN NO_ADAPTIVE_PLAN 1 16 12.1.0.2 12.1.0.2 ALL_ROWS QKSFM_ALL_ROWS MODE 1 16 8.1.0 10.2.0.1 ANALYTIC_VIEW_SQL QKSFM_COMPILATION ANALYTIC_VIEW_SQL 2 0 20.1.0 AND_EQUAL QKSFM_AND_EQUAL ACCESS 4 304 8.1.0 8.1.7 ANSI_REARCH QKSFM_ANSI_REARCH ANSI_REARCH NO_ANSI_REARCH 2 16 12.1.0.2 12.1.0.2 ANSWER_QUERY_USING_STATS QKSFM_ANSWER_QUERY_USING_STATS ANSWER_QUERY_USING_STATS NO_ANSWER_QUERY_USING_STATS 2 16 18.1.0 18.1.0 ANTIJOIN QKSFM_TRANSFORMATION ANTIJOIN 2 16 9.0.0 APPEND QKSFM_CBO APPEND NOAPPEND 1 0 8.1.0 APPEND_VALUES QKSFM_CBO APPEND_VALUES NOAPPEND 1 0 11.2.0.1 AUTO_REOPTIMIZE QKSFM_AUTO_REOPT AUTO_REOPTIMIZE NO_AUTO_REOPTIMIZE 1 0 12.1.0.1 AV_CACHE QKSFM_EXECUTION AV_CACHE 2 0 18.1.0 BATCH_TABLE_ACCESS_BY_ROWID QKSFM_EXECUTION BATCH_TABLE_ACCESS_BY_ROWID NO_BATCH_TABLE_ACCESS_BY_ROWID 4 272 12.1.0.1 12.1.0.1 BIND_AWARE QKSFM_CURSOR_SHARING BIND_AWARE NO_BIND_AWARE 1 0 11.1.0.7 BITMAP QKSFM_CBO BITMAP 2 256 8.1.0 8.1.5 BITMAP_AND QKSFM_BITMAP_TREE BITMAP_AND 4 48 12.1.0.1 12.1.0.1 BITMAP_TREE QKSFM_BITMAP_TREE ACCESS 4 304 10.2.0.1 10.2.0.1 BUFFER QKSFM_CBO BUFFER NO_BUFFER 2 0 8.1.5 BUSHY_JOIN QKSFM_BUSHY_JOIN BUSHY_JOIN NO_BUSHY_JOIN 2 16 12.2.0.1 12.2.0.1 BYPASS_RECURSIVE_CHECK QKSFM_ALL BYPASS_RECURSIVE_CHECK 2 0 9.0.0 BYPASS_UJVC QKSFM_CBO BYPASS_UJVC 2 0 8.1.5 CACHE QKSFM_EXECUTION CACHE NOCACHE 4 256 8.1.0 CACHE_CB QKSFM_CBO CACHE_CB NOCACHE 4 256 8.1.5 CARDINALITY QKSFM_STATS CARDINALITY 14 272 9.0.0 CHANGE_DUPKEY_ERROR_INDEX QKSFM_DML CHANGE_DUPKEY_ERROR_INDEX 4 288 11.1.0.7 CHECK_ACL_REWRITE QKSFM_CHECK_ACL_REWRITE CHECK_ACL_REWRITE NO_CHECK_ACL_REWRITE 1 0 11.1.0.6 CHOOSE QKSFM_CHOOSE MODE 1 16 8.1.0 CLUSTER QKSFM_CBO ACCESS 4 272 8.0.0 8.1.7 CLUSTERING QKSFM_CLUSTERING CLUSTERING NO_CLUSTERING 1 0 12.1.0.1 12.1.0.1 CLUSTER_BY_ROWID QKSFM_CBO CLUSTER_BY_ROWID NO_CLUSTER_BY_ROWID 4 272 12.1.0.1 12.1.0.1 COALESCE_SQ QKSFM_COALESCE_SQ COALESCE_SQ NO_COALESCE_SQ 2 16 11.2.0.1 11.2.0.1 COLUMN_STATS QKSFM_STATS TABLE_STATS 1 272 10.1.0.3 CONNECT_BY_CB_WHR_ONLY QKSFM_TRANSFORMATION CONNECT_BY_CB_WHR_ONLY NO_CONNECT_BY_CB_WHR_ONLY 2 16 10.2.0.5 10.2.0.5 CONNECT_BY_COMBINE_SW QKSFM_ALL CONNECT_BY_COMBINE_SW NO_CONNECT_BY_COMBINE_SW 2 16 10.2.0.4 10.2.0.4 CONNECT_BY_COST_BASED QKSFM_TRANSFORMATION CONNECT_BY_COST_BASED NO_CONNECT_BY_COST_BASED 2 16 10.2.0.2 10.2.0.2 CONNECT_BY_ELIM_DUPS QKSFM_ALL CONNECT_BY_ELIM_DUPS NO_CONNECT_BY_ELIM_DUPS 2 16 11.2.0.1 11.2.0.1 CONNECT_BY_FILTERING QKSFM_ALL CONNECT_BY_FILTERING NO_CONNECT_BY_FILTERING 2 16 10.2.0.2 10.2.0.2 CONTAINERS QKSFM_ALL CONTAINERS 1 0 12.2.0.1 12.2.0.1 COST_XML_QUERY_REWRITE QKSFM_COST_XML_QUERY_REWRITE COST_XML_QUERY_REWRITE NO_COST_XML_QUERY_REWRITE 1 0 11.1.0.6 11.1.0.6 CPU_COSTING QKSFM_CPU_COSTING CPU_COSTING NO_CPU_COSTING 2 16 9.0.0 CUBE_AJ QKSFM_JOIN_METHOD ANTIJOIN 2 16 12.1.0.1 12.1.0.1 CUBE_GB QKSFM_CBO CUBE_GB 2 0 8.1.5 CUBE_SJ QKSFM_JOIN_METHOD SEMIJOIN 2 16 12.1.0.1 12.1.0.1 CURRENT_INSTANCE QKSFM_ALL CURRENT_INSTANCE 1 0 18.1.0 CURSOR_SHARING_EXACT QKSFM_CBO CURSOR_SHARING_EXACT 2 0 9.0.0 DAGG_OPTIM_GSETS QKSFM_GROUPING_SET_XFORM DAGG_OPTIM_GSETS NO_DAGG_OPTIM_GSETS 2 0 21.1.0 21.1.0 DATA_SECURITY_REWRITE_LIMIT QKSFM_DATA_SECURITY_REWRITE DATA_SECURITY_REWRITE_LIMIT NO_DATA_SECURITY_REWRITE 1 0 12.1.0.1 12.1.0.1 DATA_VALIDATE QKSFM_EXECUTION DATA_VALIDATE 1 0 12.2.0.1 DBMS_STATS QKSFM_DBMS_STATS DBMS_STATS 1 0 10.2.0.1 DB_VERSION QKSFM_ALL DB_VERSION 1 272 11.1.0.6 11.1.0.6 DECORRELATE QKSFM_DECORRELATE DECORRELATE NO_DECORRELATE 2 16 12.1.0.1 12.1.0.1 DENORM_AV QKSFM_COMPILATION DENORM_AV 2 0 20.1.0 DEREF_NO_REWRITE QKSFM_ALL DEREF_NO_REWRITE 1 0 8.1.0 DISABLE_PARALLEL_DML QKSFM_DML ENABLE_PARALLEL_DML ENABLE_PARALLEL_DML 1 0 11.2.0.4 DIST_AGG_PROLLUP_PUSHDOWN QKSFM_PQ DIST_AGG_PROLLUP_PUSHDOWN NO_DIST_AGG_PROLLUP_PUSHDOWN 2 16 12.2.0.1 12.2.0.1 DML_UPDATE QKSFM_CBO DML_UPDATE 1 0 9.0.0 DOMAIN_INDEX_FILTER QKSFM_CBO DOMAIN_INDEX_FILTER NO_DOMAIN_INDEX_FILTER 4 304 11.1.0.6 11.1.0.6 DOMAIN_INDEX_NO_SORT QKSFM_CBO DOMAIN_INDEX_SORT DOMAIN_INDEX_SORT 2 0 8.1.5 10.2.0.1 DOMAIN_INDEX_SORT QKSFM_CBO DOMAIN_INDEX_SORT DOMAIN_INDEX_NO_SORT 2 0 8.1.5 10.2.0.1 DRIVING_SITE QKSFM_ALL DRIVING_SITE 4 256 8.1.0 8.1.7 DST_UPGRADE_INSERT_CONV QKSFM_ALL DST_UPGRADE_INSERT_CONV NO_DST_UPGRADE_INSERT_CONV 1 0 11.2.0.1 DYNAMIC_SAMPLING QKSFM_DYNAMIC_SAMPLING DYNAMIC_SAMPLING 6 272 9.2.0 DYNAMIC_SAMPLING_EST_CDN QKSFM_DYNAMIC_SAMPLING_EST_CDN DYNAMIC_SAMPLING_EST_CDN 4 272 9.2.0 ELIMINATE_JOIN QKSFM_TABLE_ELIM ELIMINATE_JOIN NO_ELIMINATE_JOIN 4 16 10.2.0.1 10.2.0.1 ELIMINATE_OBY QKSFM_OBYE ELIMINATE_OBY NO_ELIMINATE_OBY 2 16 10.2.0.1 10.2.0.1 ELIMINATE_SQ QKSFM_ELIMINATE_SQ ELIMINATE_SQ NO_ELIMINATE_SQ 2 16 12.2.0.1 12.2.0.1 ELIM_GROUPBY QKSFM_TRANSFORMATION ELIM_GROUPBY NO_ELIM_GROUPBY 2 16 12.1.0.2 12.1.0.2 ENABLE_PARALLEL_DML QKSFM_DML ENABLE_PARALLEL_DML DISABLE_PARALLEL_DML 1 0 11.2.0.4 EXPAND_GSET_TO_UNION QKSFM_TRANSFORMATION EXPAND_GSET_TO_UNION NO_EXPAND_GSET_TO_UNION 2 0 9.2.0 10.1.0 EXPAND_TABLE QKSFM_TABLE_EXPANSION EXPAND_TABLE NO_EXPAND_TABLE 4 16 11.2.0.1 11.2.0.1 EXPR_CORR_CHECK QKSFM_CBO EXPR_CORR_CHECK 1 0 8.0.0 FACT QKSFM_STAR_TRANS FACT NO_FACT 4 272 8.1.0 8.1.7 FACTORIZE_JOIN QKSFM_JOINFAC FACTORIZE_JOIN NO_FACTORIZE_JOIN 2 16 11.2.0.1 11.2.0.1 FBTSCAN QKSFM_CBO FBTSCAN 1 0 10.1.0.3 FIRST_ROWS QKSFM_FIRST_ROWS MODE 1 16 8.1.0 10.2.0.1 FORCE_JSON_TABLE_TRANSFORM QKSFM_JSON_REWRITE FORCE_JSON_TABLE_TRANSFORM NO_JSON_TABLE_TRANSFORM 1 0 20.1.0 20.1.0 FORCE_XML_QUERY_REWRITE QKSFM_XML_REWRITE FORCE_XML_QUERY_REWRITE NO_XML_QUERY_REWRITE 1 0 9.2.0 11.1.0.6 FRESH_MV QKSFM_MVIEWS FRESH_MV 1 0 12.2.0.1 FULL QKSFM_FULL ACCESS 4 272 8.1.0 8.1.7 FULL_OUTER_JOIN_TO_OUTER QKSFM_CBO FULL_OUTER_JOIN_TO_OUTER NO_FULL_OUTER_JOIN_TO_OUTER 4 272 11.2.0.3 11.2.0.3 GATHER_OPTIMIZER_STATISTICS QKSFM_DBMS_STATS GATHER_OPTIMIZER_STATISTICS NO_GATHER_OPTIMIZER_STATISTICS 1 0 12.1.0.1 GATHER_PLAN_STATISTICS QKSFM_GATHER_PLAN_STATISTICS GATHER_PLAN_STATISTICS 1 0 10.1.0.3 GBY_CONC_ROLLUP QKSFM_TRANSFORMATION GBY_CONC_ROLLUP 2 0 9.0.0 GBY_PUSHDOWN QKSFM_ALL GBY_PUSHDOWN NO_GBY_PUSHDOWN 2 16 10.2.0.5 10.2.0.5 HASH QKSFM_ALL ACCESS 4 272 8.1.0 8.1.7 HASHSET_BUILD QKSFM_EXECUTION HASHSET_BUILD 2 16 21.1.0 21.1.0 HASH_AJ QKSFM_JOIN_METHOD ANTIJOIN 2 16 8.1.0 8.1.7 HASH_SJ QKSFM_JOIN_METHOD SEMIJOIN 2 16 8.1.0 8.1.7 HWM_BROKERED QKSFM_CBO HWM_BROKERED 2 0 9.0.0 IGNORE_OPTIM_EMBEDDED_HINTS QKSFM_ALL IGNORE_OPTIM_EMBEDDED_HINTS 1 0 10.1.0.3 10.2.0.1 IGNORE_ROW_ON_DUPKEY_INDEX QKSFM_DML IGNORE_ROW_ON_DUPKEY_INDEX 4 288 11.1.0.7 IGNORE_WHERE_CLAUSE QKSFM_ALL IGNORE_WHERE_CLAUSE 1 0 9.2.0 INCLUDE_VERSION QKSFM_ALL INCLUDE_VERSION 1 0 10.1.0.3 INDEX QKSFM_INDEX ACCESS NO_INDEX 4 304 8.0.0 8.1.7 INDEX_ASC QKSFM_INDEX_ASC ACCESS NO_INDEX 4 304 8.1.0 INDEX_COMBINE QKSFM_INDEX_COMBINE ACCESS 4 432 8.1.0 8.1.7 INDEX_DESC QKSFM_INDEX_DESC ACCESS NO_INDEX 4 304 8.1.0 8.1.7 INDEX_FFS QKSFM_INDEX_FFS ACCESS 4 304 8.1.0 8.1.7 INDEX_JOIN QKSFM_INDEX_JOIN ACCESS 4 304 8.1.5 10.1.0.3 INDEX_RRS QKSFM_CBO ACCESS 4 304 9.0.0 INDEX_RS_ASC QKSFM_INDEX_RS_ASC ACCESS 4 304 11.1.0.6 11.1.0.6 INDEX_RS_DESC QKSFM_INDEX_RS_DESC ACCESS 4 304 11.1.0.6 11.1.0.6 INDEX_SS QKSFM_INDEX_SS ACCESS NO_INDEX_SS 4 304 9.0.0 10.2.0.1 INDEX_SS_ASC QKSFM_INDEX_SS_ASC ACCESS NO_INDEX_SS 4 304 9.0.0 INDEX_SS_DESC QKSFM_INDEX_SS_DESC ACCESS NO_INDEX_SS 4 304 9.0.0 10.2.0.1 INDEX_STATS QKSFM_STATS TABLE_STATS 1 272 10.1.0.3 INLINE QKSFM_TRANSFORMATION INLINE MATERIALIZE 2 16 9.0.0 18.1.0 INLINE_XMLTYPE_NT QKSFM_ALL INLINE_XMLTYPE_NT 1 0 10.2.0.1 INMEMORY QKSFM_EXECUTION INMEMORY NO_INMEMORY 6 64 12.1.0.2 12.1.0.2 INMEMORY_PRUNING QKSFM_EXECUTION INMEMORY_PRUNING NO_INMEMORY_PRUNING 6 64 12.1.0.2 12.1.0.2 JSON_LENGTH QKSFM_EXECUTION JSON_LENGTH 1 0 19.1.0 LEADING QKSFM_JOIN_ORDER LEADING 8 272 8.1.6 10.1.0.3 LOCAL_INDEXES QKSFM_CBO LOCAL_INDEXES 2 0 9.0.0 MATERIALIZE QKSFM_TRANSFORMATION INLINE INLINE 2 16 9.0.0 18.1.0 MEMOPTIMIZE_WRITE QKSFM_EXECUTION MEMOPTIMIZE_WRITE 1 0 18.1.0 MERGE QKSFM_CVM MERGE NO_MERGE 6 16 8.1.0 10.1.0 MERGE_AJ QKSFM_JOIN_METHOD ANTIJOIN 2 16 8.1.0 8.1.7 MERGE_CONST_ON QKSFM_CBO MERGE_CONST_ON 1 0 8.0.0 MERGE_SJ QKSFM_JOIN_METHOD SEMIJOIN 2 16 8.1.0 8.1.7 MODEL_COMPILE_SUBQUERY QKSFM_TRANSFORMATION MODEL_COMPILE_SUBQUERY 2 0 10.2.0.1 MODEL_DONTVERIFY_UNIQUENESS QKSFM_TRANSFORMATION MODEL_DONTVERIFY_UNIQUENESS 2 0 10.1.0.3 MODEL_DYNAMIC_SUBQUERY QKSFM_TRANSFORMATION MODEL_DYNAMIC_SUBQUERY 2 0 10.2.0.1 MODEL_MIN_ANALYSIS QKSFM_TRANSFORMATION MODEL_MIN_ANALYSIS 2 0 10.1.0.3 MODEL_NO_ANALYSIS QKSFM_ALL MODEL_MIN_ANALYSIS 2 0 10.1.0.3 MODEL_PUSH_REF QKSFM_TRANSFORMATION MODEL_PUSH_REF NO_MODEL_PUSH_REF 2 0 10.1.0.3 MONITOR QKSFM_ALL MONITOR NO_MONITOR 1 0 11.1.0.6 MV_MERGE QKSFM_TRANSFORMATION MV_MERGE 2 0 9.0.0 NATIVE_FULL_OUTER_JOIN QKSFM_ALL NATIVE_FULL_OUTER_JOIN NO_NATIVE_FULL_OUTER_JOIN 2 16 10.2.0.3 10.2.0.3 NESTED_TABLE_FAST_INSERT QKSFM_ALL NESTED_TABLE_FAST_INSERT 1 0 10.1.0.3 NESTED_TABLE_GET_REFS QKSFM_ALL NESTED_TABLE_GET_REFS 1 0 8.1.0 NESTED_TABLE_SET_SETID QKSFM_ALL NESTED_TABLE_SET_SETID 1 0 8.1.5 NLJ_BATCHING QKSFM_EXECUTION ACCESS NO_NLJ_BATCHING 4 272 11.1.0.6 11.1.0.6 NLJ_PREFETCH QKSFM_EXECUTION NLJ_PREFETCH NO_NLJ_PREFETCH 4 272 11.1.0.6 11.1.0.6 NL_AJ QKSFM_JOIN_METHOD ANTIJOIN 2 16 8.0.0 NL_SJ QKSFM_JOIN_METHOD SEMIJOIN 2 16 8.0.0 NOAPPEND QKSFM_CBO APPEND APPEND 1 0 8.1.0 NOCACHE QKSFM_EXECUTION CACHE CACHE 4 256 8.1.0 NOPARALLEL QKSFM_PARALLEL SHARED SHARED 5 256 8.1.0 NO_ACCESS QKSFM_ALL NO_ACCESS 4 256 8.1.5 8.1.7 NO_ADAPTIVE_PLAN QKSFM_ADAPTIVE_PLAN ADAPTIVE_PLAN ADAPTIVE_PLAN 1 16 12.1.0.2 12.1.0.2 NO_ANSI_REARCH QKSFM_ANSI_REARCH ANSI_REARCH ANSI_REARCH 2 16 12.1.0.2 12.1.0.2 NO_ANSWER_QUERY_USING_STATS QKSFM_ANSWER_QUERY_USING_STATS ANSWER_QUERY_USING_STATS ANSWER_QUERY_USING_STATS 2 16 18.1.0 18.1.0 NO_AUTO_REOPTIMIZE QKSFM_AUTO_REOPT AUTO_REOPTIMIZE AUTO_REOPTIMIZE 1 0 12.1.0.1 NO_BASETABLE_MULTIMV_REWRITE QKSFM_ALL REWRITE REWRITE 2 16 10.1.0.3 10.1.0.3 NO_BATCH_TABLE_ACCESS_BY_ROWID QKSFM_EXECUTION BATCH_TABLE_ACCESS_BY_ROWID BATCH_TABLE_ACCESS_BY_ROWID 4 272 12.1.0.1 12.1.0.1 NO_BIND_AWARE QKSFM_CURSOR_SHARING BIND_AWARE BIND_AWARE 1 0 11.1.0.7 NO_BUFFER QKSFM_CBO BUFFER BUFFER 2 0 8.1.5 NO_BUSHY_JOIN QKSFM_BUSHY_JOIN BUSHY_JOIN BUSHY_JOIN 2 16 12.2.0.1 12.2.0.1 NO_CARTESIAN QKSFM_ALL NO_CARTESIAN 4 336 10.2.0.1 NO_CHECK_ACL_REWRITE QKSFM_CHECK_ACL_REWRITE NO_CHECK_ACL_REWRITE CHECK_ACL_REWRITE 1 0 11.1.0.6 NO_CLUSTERING QKSFM_CLUSTERING CLUSTERING CLUSTERING 1 0 12.1.0.1 12.1.0.1 NO_CLUSTER_BY_ROWID QKSFM_CBO CLUSTER_BY_ROWID CLUSTER_BY_ROWID 4 272 12.1.0.1 12.1.0.1 NO_COALESCE_SQ QKSFM_COALESCE_SQ COALESCE_SQ COALESCE_SQ 2 16 11.2.0.1 11.2.0.1 NO_CONNECT_BY_CB_WHR_ONLY QKSFM_TRANSFORMATION CONNECT_BY_CB_WHR_ONLY CONNECT_BY_CB_WHR_ONLY 2 16 10.2.0.5 10.2.0.5 NO_CONNECT_BY_COMBINE_SW QKSFM_ALL CONNECT_BY_COMBINE_SW CONNECT_BY_COMBINE_SW 2 16 10.2.0.4 10.2.0.4 NO_CONNECT_BY_COST_BASED QKSFM_TRANSFORMATION CONNECT_BY_COST_BASED CONNECT_BY_COST_BASED 2 16 10.2.0.2 10.2.0.2 NO_CONNECT_BY_ELIM_DUPS QKSFM_ALL CONNECT_BY_ELIM_DUPS CONNECT_BY_ELIM_DUPS 2 16 11.2.0.1 11.2.0.1 NO_CONNECT_BY_FILTERING QKSFM_ALL CONNECT_BY_FILTERING CONNECT_BY_FILTERING 2 16 10.2.0.2 10.2.0.2 NO_COST_XML_QUERY_REWRITE QKSFM_COST_XML_QUERY_REWRITE NO_COST_XML_QUERY_REWRITE COST_XML_QUERY_REWRITE 1 0 11.1.0.6 11.1.0.6 NO_CPU_COSTING QKSFM_CPU_COSTING CPU_COSTING CPU_COSTING 2 16 9.0.0 NO_DAGG_OPTIM_GSETS QKSFM_GROUPING_SET_XFORM DAGG_OPTIM_GSETS DAGG_OPTIM_GSETS 2 0 21.1.0 21.1.0 NO_DATA_SECURITY_REWRITE QKSFM_DATA_SECURITY_REWRITE DATA_SECURITY_REWRITE_LIMIT DATA_SECURITY_REWRITE_LIMIT 1 0 12.1.0.1 12.1.0.1 NO_DECORRELATE QKSFM_DECORRELATE DECORRELATE DECORRELATE 2 16 12.1.0.1 12.1.0.1 NO_DIST_AGG_PROLLUP_PUSHDOWN QKSFM_PQ DIST_AGG_PROLLUP_PUSHDOWN DIST_AGG_PROLLUP_PUSHDOWN 2 16 12.2.0.1 12.2.0.1 NO_DOMAIN_INDEX_FILTER QKSFM_CBO NO_DOMAIN_INDEX_FILTER DOMAIN_INDEX_FILTER 4 304 11.1.0.6 11.1.0.6 NO_DST_UPGRADE_INSERT_CONV QKSFM_ALL DST_UPGRADE_INSERT_CONV DST_UPGRADE_INSERT_CONV 1 0 11.2.0.1 21.1.0.1 NO_ELIMINATE_JOIN QKSFM_TABLE_ELIM ELIMINATE_JOIN ELIMINATE_JOIN 4 16 10.2.0.1 10.2.0.1 NO_ELIMINATE_OBY QKSFM_OBYE ELIMINATE_OBY ELIMINATE_OBY 2 16 10.2.0.1 10.2.0.1 NO_ELIMINATE_SQ QKSFM_ELIMINATE_SQ ELIMINATE_SQ ELIMINATE_SQ 2 16 12.2.0.1 12.2.0.1 NO_ELIM_GROUPBY QKSFM_TRANSFORMATION ELIM_GROUPBY ELIM_GROUPBY 2 16 12.1.0.2 12.1.0.2 NO_EXPAND QKSFM_USE_CONCAT OR_EXPAND USE_CONCAT 2 16 8.1.0 8.1.7 NO_EXPAND_GSET_TO_UNION QKSFM_TRANSFORMATION EXPAND_GSET_TO_UNION EXPAND_GSET_TO_UNION 2 0 9.2.0 10.1.0 NO_EXPAND_TABLE QKSFM_TABLE_EXPANSION EXPAND_TABLE EXPAND_TABLE 4 16 11.2.0.1 11.2.0.1 NO_FACT QKSFM_STAR_TRANS FACT FACT 4 272 8.1.0 8.1.7 NO_FACTORIZE_JOIN QKSFM_JOINFAC FACTORIZE_JOIN FACTORIZE_JOIN 2 16 11.2.0.1 11.2.0.1 NO_FULL_OUTER_JOIN_TO_OUTER QKSFM_CBO FULL_OUTER_JOIN_TO_OUTER FULL_OUTER_JOIN_TO_OUTER 4 272 11.2.0.3 11.2.0.3 NO_GATHER_OPTIMIZER_STATISTICS QKSFM_DBMS_STATS GATHER_OPTIMIZER_STATISTICS GATHER_OPTIMIZER_STATISTICS 1 0 12.1.0.1 NO_GBY_PUSHDOWN QKSFM_ALL GBY_PUSHDOWN GBY_PUSHDOWN 2 16 10.2.0.5 10.2.0.5 NO_INDEX QKSFM_INDEX NO_INDEX INDEX 4 304 8.1.5 8.1.7 NO_INDEX_FFS QKSFM_INDEX_FFS NO_INDEX_FFS INDEX_FFS 4 304 10.1.0.3 10.1.0.3 NO_INDEX_SS QKSFM_INDEX_SS NO_INDEX_SS INDEX_SS 4 304 10.1.0.3 10.1.0.3 NO_INMEMORY QKSFM_EXECUTION INMEMORY INMEMORY 6 64 12.1.0.2 12.1.0.2 NO_INMEMORY_PRUNING QKSFM_EXECUTION INMEMORY_PRUNING INMEMORY_PRUNING 6 64 12.1.0.2 12.1.0.2 NO_JSON_TABLE_TRANSFORM QKSFM_JSON_REWRITE FORCE_JSON_TABLE_TRANSFORM FORCE_JSON_TABLE_TRANSFORM 1 0 20.1.0 20.1.0 NO_LOAD QKSFM_EXECUTION NO_LOAD 1 0 11.1.0.6 NO_MERGE QKSFM_CVM MERGE MERGE 6 16 8.0.0 10.1.0 NO_MODEL_PUSH_REF QKSFM_ALL MODEL_PUSH_REF MODEL_PUSH_REF 2 0 10.1.0.3 NO_MONITOR QKSFM_ALL MONITOR MONITOR 1 0 11.1.0.6 NO_MONITORING QKSFM_ALL NO_MONITORING 1 0 8.0.0 NO_MULTIMV_REWRITE QKSFM_ALL REWRITE REWRITE 2 16 10.1.0.3 10.1.0.3 NO_NATIVE_FULL_OUTER_JOIN QKSFM_ALL NATIVE_FULL_OUTER_JOIN NATIVE_FULL_OUTER_JOIN 2 16 10.2.0.3 10.2.0.3 NO_NLJ_BATCHING QKSFM_EXECUTION ACCESS NLJ_BATCHING 4 272 11.1.0.6 11.1.0.6 NO_NLJ_PREFETCH QKSFM_EXECUTION NLJ_PREFETCH NLJ_PREFETCH 4 272 11.1.0.6 11.1.0.6 NO_OBY_GBYPD_SEPARATE QKSFM_PQ OBY_GBYPD_SEPARATE OBY_GBYPD_SEPARATE 2 16 21.1.0 21.1.0 NO_ORDER_ROLLUPS QKSFM_TRANSFORMATION NO_ORDER_ROLLUPS 2 0 8.0.0 NO_OR_EXPAND QKSFM_CBQT_OR_EXPANSION OR_EXPAND OR_EXPAND 2 16 12.2.0.1 12.2.0.1 NO_OUTER_JOIN_TO_ANTI QKSFM_CBO OUTER_JOIN_TO_ANTI OUTER_JOIN_TO_ANTI 4 272 11.2.0.3 11.2.0.3 NO_OUTER_JOIN_TO_INNER QKSFM_OUTER_JOIN_TO_INNER OUTER_JOIN_TO_INNER OUTER_JOIN_TO_INNER 6 16 11.1.0.6 11.1.0.6 NO_PARALLEL QKSFM_CBO SHARED SHARED 5 256 10.1.0.3 NO_PARALLEL_INDEX QKSFM_PQ PARALLEL_INDEX PARALLEL_INDEX 4 288 8.1.0 NO_PARTIAL_COMMIT QKSFM_CBO NO_PARTIAL_COMMIT 1 0 10.1.0.3 NO_PARTIAL_JOIN QKSFM_PARTIAL_JOIN PARTIAL_JOIN PARTIAL_JOIN 4 272 12.1.0.1 12.1.0.1 NO_PARTIAL_ROLLUP_PUSHDOWN QKSFM_PQ PARTIAL_ROLLUP_PUSHDOWN PARTIAL_ROLLUP_PUSHDOWN 2 16 12.1.0.1 12.1.0.1 NO_PLACE_DISTINCT QKSFM_DIST_PLCMT PLACE_DISTINCT PLACE_DISTINCT 2 16 11.2.0.1 11.2.0.1 NO_PLACE_GROUP_BY QKSFM_PLACE_GROUP_BY PLACE_GROUP_BY PLACE_GROUP_BY 2 16 11.1.0.6 11.1.0.6 NO_PQ_CONCURRENT_UNION QKSFM_PQ PQ_CONCURRENT_UNION PQ_CONCURRENT_UNION 3 0 12.1.0.1 12.1.0.1 NO_PQ_EXPAND_TABLE QKSFM_TABLE_EXPANSION PQ_EXPAND_TABLE PQ_EXPAND_TABLE 4 16 19.1.0 19.1.0 NO_PQ_NONLEAF_SKEW QKSFM_PQ PQ_NONLEAF_SKEW PQ_NONLEAF_SKEW 4 272 21.1.0 21.1.0 NO_PQ_REPLICATE QKSFM_PQ_REPLICATE PQ_REPLICATE PQ_REPLICATE 4 272 12.1.0.1 12.1.0.1 NO_PQ_SKEW QKSFM_PQ PQ_SKEW PQ_SKEW 4 272 12.1.0.1 12.1.0.1 NO_PRUNE_GSETS QKSFM_TRANSFORMATION NO_PRUNE_GSETS 2 0 9.0.0 NO_PULL_PRED QKSFM_PULL_PRED PULL_PRED PULL_PRED 4 16 10.2.0.1 10.2.0.1 NO_PUSH_HAVING_TO_GBY QKSFM_EXECUTION PUSH_HAVING_TO_GBY PUSH_HAVING_TO_GBY 2 0 18.1.0 18.1.0 NO_PUSH_PRED QKSFM_FILTER_PUSH_PRED PUSH_PRED PUSH_PRED 6 16 8.1.0 8.1.5 NO_PUSH_SUBQ QKSFM_TRANSFORMATION PUSH_SUBQ PUSH_SUBQ 2 16 9.2.0 10.2.0.5 NO_PX_FAULT_TOLERANCE QKSFM_PQ PX_FAULT_TOLERANCE PX_FAULT_TOLERANCE 1 0 12.1.0.1 12.1.0.1 NO_PX_JOIN_FILTER QKSFM_PX_JOIN_FILTER PX_JOIN_FILTER PX_JOIN_FILTER 4 336 10.2.0.1 11.1.0.6 NO_QKN_BUFF QKSFM_CBO NO_QKN_BUFF 2 0 9.2.0 NO_QUERY_TRANSFORMATION QKSFM_TRANSFORMATION NO_QUERY_TRANSFORMATION 1 16 10.1.0.3 NO_REF_CASCADE QKSFM_CBO REF_CASCADE_CURSOR REF_CASCADE_CURSOR 1 0 9.2.0 NO_REORDER_WIF QKSFM_PARTITION REORDER_WIF REORDER_WIF 2 0 18.1.0 18.1.0 NO_RESULT_CACHE QKSFM_EXECUTION RESULT_CACHE RESULT_CACHE 2 0 11.1.0.6 NO_REWRITE QKSFM_TRANSFORMATION REWRITE REWRITE 2 16 8.1.5 8.1.7 NO_SEMIJOIN QKSFM_TRANSFORMATION SEMIJOIN SEMIJOIN 2 16 9.0.0 NO_SEMI_TO_INNER QKSFM_CBO NO_SEMI_TO_INNER SEMI_TO_INNER 4 272 11.2.0.3 11.2.0.3 NO_SET_GBY_PUSHDOWN QKSFM_ALL SET_GBY_PUSHDOWN SET_GBY_PUSHDOWN 2 16 20.1.0 20.1.0 NO_SET_TO_JOIN QKSFM_SET_TO_JOIN SET_TO_JOIN SET_TO_JOIN 2 16 10.1.0.3 10.1.0.3 NO_SQL_TUNE QKSFM_ALL NO_SQL_TUNE 1 0 10.2.0.1 NO_STAR_TRANSFORMATION QKSFM_STAR_TRANS STAR_TRANSFORMATION STAR_TRANSFORMATION 6 16 10.1.0.3 10.1.0.3 NO_STATEMENT_QUEUING QKSFM_PARALLEL STATEMENT_QUEUING STATEMENT_QUEUING 1 0 11.2.0.1 NO_STATS_GSETS QKSFM_ALL NO_STATS_GSETS 2 0 8.0.0 NO_SUBQUERY_PRUNING QKSFM_CBO SUBQUERY_PRUNING SUBQUERY_PRUNING 4 272 11.1.0.6 11.1.0.6 NO_SUBSTRB_PAD QKSFM_EXECUTION NO_SUBSTRB_PAD 1 0 11.2.0.1 NO_SWAP_JOIN_INPUTS QKSFM_CBO SWAP_JOIN_INPUTS SWAP_JOIN_INPUTS 4 272 10.1.0.3 10.1.0.3 NO_TABLE_LOOKUP_BY_NL QKSFM_TABLE_LOOKUP_BY_NL TABLE_LOOKUP_BY_NL TABLE_LOOKUP_BY_NL 4 16 11.2.0.2 11.2.0.2 NO_TRANSFORM_DISTINCT_AGG QKSFM_TRANSFORMATION TRANSFORM_DISTINCT_AGG TRANSFORM_DISTINCT_AGG 2 0 11.2.0.1 11.2.0.1 NO_UNNEST QKSFM_UNNEST UNNEST UNNEST 2 16 8.1.6 10.1.0 NO_USE_CUBE QKSFM_USE_CUBE JOIN USE_CUBE 4 336 12.1.0.1 12.1.0.1 NO_USE_DAGG_UNION_ALL_GSETS QKSFM_GROUPING_SET_XFORM DAGG_OPTIM_GSETS USE_DAGG_UNION_ALL_GSETS 2 0 12.2.0.1 12.2.0.1 NO_USE_HASH QKSFM_USE_HASH NO_USE_HASH USE_HASH 4 336 10.1.0.3 10.1.0.3 NO_USE_HASH_AGGREGATION QKSFM_ALL USE_HASH_AGGREGATION USE_HASH_AGGREGATION 2 0 10.2.0.1 10.2.0.5 NO_USE_HASH_GBY_FOR_DAGGPSHD QKSFM_ALL USE_HASH_GBY_FOR_DAGGPSHD USE_HASH_GBY_FOR_DAGGPSHD 2 0 12.2.0.1 12.2.0.1 NO_USE_HASH_GBY_FOR_PUSHDOWN QKSFM_ALL USE_HASH_GBY_FOR_PUSHDOWN USE_HASH_GBY_FOR_PUSHDOWN 2 0 11.2.0.2 11.2.0.2 NO_USE_INVISIBLE_INDEXES QKSFM_INDEX USE_INVISIBLE_INDEXES USE_INVISIBLE_INDEXES 1 0 11.1.0.6 11.1.0.6 NO_USE_MERGE QKSFM_USE_MERGE NO_USE_MERGE USE_MERGE 4 336 10.1.0.3 10.1.0.3 NO_USE_NL QKSFM_USE_NL NO_USE_NL USE_NL 4 336 10.1.0.3 10.1.0.3 NO_USE_PARTITION_WISE_DISTINCT QKSFM_PARTITION USE_PARTITION_WISE_DISTINCT USE_PARTITION_WISE_DISTINCT 2 0 12.2.0.1 12.2.0.1 NO_USE_PARTITION_WISE_GBY QKSFM_PARTITION USE_PARTITION_WISE_GBY USE_PARTITION_WISE_GBY 2 0 12.2.0.1 12.2.0.1 NO_USE_PARTITION_WISE_WIF QKSFM_PARTITION USE_PARTITION_WISE_WIF USE_PARTITION_WISE_WIF 2 0 18.1.0 18.1.0 NO_USE_SCALABLE_GBY_INVDIST QKSFM_PQ USE_SCALABLE_GBY_INVDIST USE_SCALABLE_GBY_INVDIST 2 0 19.1.0 19.1.0 NO_USE_VECTOR_AGGREGATION QKSFM_VECTOR_AGG USE_VECTOR_AGGREGATION USE_VECTOR_AGGREGATION 2 16 12.1.0.2 12.1.0.2 NO_VECTOR_TRANSFORM QKSFM_VECTOR_AGG VECTOR_TRANSFORM VECTOR_TRANSFORM 2 16 12.1.0.2 12.1.0.2 NO_VECTOR_TRANSFORM_DIMS QKSFM_VECTOR_AGG VECTOR_TRANSFORM_DIMS VECTOR_TRANSFORM_DIMS 4 80 12.1.0.2 12.1.0.2 NO_VECTOR_TRANSFORM_FACT QKSFM_VECTOR_AGG VECTOR_TRANSFORM_FACT VECTOR_TRANSFORM_FACT 4 80 12.1.0.2 12.1.0.2 NO_XDB_FASTPATH_INSERT QKSFM_ALL XDB_FASTPATH_INSERT XDB_FASTPATH_INSERT 1 0 11.2.0.2 NO_XMLINDEX_REWRITE QKSFM_XMLINDEX_REWRITE XMLINDEX_REWRITE XMLINDEX_REWRITE 1 0 11.1.0.6 11.1.0.6 NO_XMLINDEX_REWRITE_IN_SELECT QKSFM_XMLINDEX_REWRITE XMLINDEX_REWRITE XMLINDEX_REWRITE_IN_SELECT 1 0 11.1.0.6 11.1.0.6 NO_XML_DML_REWRITE QKSFM_XML_REWRITE NO_XML_DML_REWRITE 1 0 10.2.0.1 11.1.0.6 NO_XML_QUERY_REWRITE QKSFM_XML_REWRITE FORCE_XML_QUERY_REWRITE FORCE_XML_QUERY_REWRITE 1 0 9.2.0 11.1.0.6 NO_ZONEMAP QKSFM_ZONEMAP ZONEMAP ZONEMAP 4 256 12.1.0.1 12.1.0.1 NUM_INDEX_KEYS QKSFM_CBO ACCESS 4 304 10.2.0.3 10.2.0.3 OBY_GBYPD_SEPARATE QKSFM_PQ OBY_GBYPD_SEPARATE NO_OBY_GBYPD_SEPARATE 2 16 21.1.0 21.1.0 OLD_PUSH_PRED QKSFM_OLD_PUSH_PRED OLD_PUSH_PRED 6 16 10.2.0.1 10.2.0.1 OPAQUE_TRANSFORM QKSFM_TRANSFORMATION OPAQUE_TRANSFORM 1 0 10.1.0.3 OPAQUE_XCANONICAL QKSFM_TRANSFORMATION OPAQUE_XCANONICAL 1 0 10.1.0.3 OPTIMIZER_FEATURES_ENABLE QKSFM_ALL OPTIMIZER_FEATURES_ENABLE 1 272 10.1.0.3 10.2.0.1 OPT_ESTIMATE QKSFM_OPT_ESTIMATE OPT_ESTIMATE 14 272 10.1.0.3 OPT_PARAM QKSFM_ALL OPT_PARAM 1 272 10.2.0.1 10.2.0.1 ORDERED QKSFM_CBO ORDERED 2 16 8.1.0 8.1.7 ORDERED_PREDICATES QKSFM_CBO ORDERED_PREDICATES 2 16 8.0.0 ORDER_KEY_VECTOR_USE QKSFM_VECTOR_AGG ORDER_KEY_VECTOR_USE 2 272 21.1.0 21.1.0 ORDER_SUBQ QKSFM_TRANSFORMATION ORDER_SUBQ 2 16 12.2.0.1 12.2.0.1 OR_EXPAND QKSFM_CBQT_OR_EXPANSION OR_EXPAND NO_OR_EXPAND 2 16 12.2.0.1 12.2.0.1 OSON_GET_CONTENT QKSFM_JSON OSON_GET_CONTENT 1 0 21.1.0 21.1.0 OUTER_JOIN_TO_ANTI QKSFM_CBO OUTER_JOIN_TO_ANTI NO_OUTER_JOIN_TO_ANTI 4 272 11.2.0.3 11.2.0.3 OUTER_JOIN_TO_INNER QKSFM_OUTER_JOIN_TO_INNER OUTER_JOIN_TO_INNER NO_OUTER_JOIN_TO_INNER 6 16 11.1.0.6 11.1.0.6 OUTLINE QKSFM_ALL OUTLINE 2 0 10.2.0.1 10.2.0.1 OUTLINE_LEAF QKSFM_ALL OUTLINE_LEAF 2 0 10.2.0.1 10.2.0.1 OVERFLOW_NOMOVE QKSFM_CBO OVERFLOW_NOMOVE 2 0 9.0.0 PARALLEL_INDEX QKSFM_PQ PARALLEL_INDEX NO_PARALLEL_INDEX 4 288 8.1.0 PARTIAL_JOIN QKSFM_PARTIAL_JOIN PARTIAL_JOIN NO_PARTIAL_JOIN 4 272 12.1.0.1 12.1.0.1 PARTIAL_ROLLUP_PUSHDOWN QKSFM_PQ PARTIAL_ROLLUP_PUSHDOWN NO_PARTIAL_ROLLUP_PUSHDOWN 2 16 12.1.0.1 12.1.0.1 PDB_LOCAL_ONLY QKSFM_DML PDB_LOCAL_ONLY 1 0 18.1.0 PIV_GB QKSFM_ALL PIV_GB 2 0 8.1.0 PIV_SSF QKSFM_ALL PIV_SSF 2 0 8.1.0 PLACE_DISTINCT QKSFM_DIST_PLCMT PLACE_DISTINCT NO_PLACE_DISTINCT 2 16 11.2.0.1 11.2.0.1 PLACE_GROUP_BY QKSFM_PLACE_GROUP_BY PLACE_GROUP_BY NO_PLACE_GROUP_BY 2 16 11.1.0.6 11.1.0.6 PQ_CONCURRENT_UNION QKSFM_PQ PQ_CONCURRENT_UNION NO_PQ_CONCURRENT_UNION 3 0 12.1.0.1 12.1.0.1 PQ_DISTRIBUTE QKSFM_PQ_DISTRIBUTE PQ_DISTRIBUTE 4 272 8.1.5 8.1.7 PQ_DISTRIBUTE_WINDOW QKSFM_PQ PQ_DISTRIBUTE_WINDOW 2 16 12.1.0.1 12.1.0.1 PQ_EXPAND_TABLE QKSFM_TABLE_EXPANSION PQ_EXPAND_TABLE NO_PQ_EXPAND_TABLE 4 16 19.1.0 19.1.0 PQ_FILTER QKSFM_PQ PQ_FILTER 2 0 12.1.0.1 12.1.0.1 PQ_MAP QKSFM_PQ_MAP PQ_MAP PQ_NOMAP 4 272 9.0.0 10.2.0.1 PQ_NOMAP QKSFM_PQ_MAP PQ_MAP PQ_MAP 4 272 9.0.0 10.2.0.1 PQ_NONLEAF_SKEW QKSFM_PQ PQ_NONLEAF_SKEW NO_PQ_NONLEAF_SKEW 4 272 21.1.0 21.1.0 PQ_REPLICATE QKSFM_PQ_REPLICATE PQ_REPLICATE NO_PQ_REPLICATE 4 272 12.1.0.1 12.1.0.1 PQ_SKEW QKSFM_PQ PQ_SKEW NO_PQ_SKEW 4 272 12.1.0.1 12.1.0.1 PRECOMPUTE_SUBQUERY QKSFM_TRANSFORMATION PRECOMPUTE_SUBQUERY 2 0 10.2.0.1 PRESERVE_OID QKSFM_ALL PRESERVE_OID 1 0 10.2.0.1 PULL_PRED QKSFM_PULL_PRED PULL_PRED NO_PULL_PRED 4 16 10.2.0.1 10.2.0.1 PUSH_HAVING_TO_GBY QKSFM_EXECUTION PUSH_HAVING_TO_GBY NO_PUSH_HAVING_TO_GBY 2 0 18.1.0 18.1.0 PUSH_PRED QKSFM_FILTER_PUSH_PRED PUSH_PRED NO_PUSH_PRED 6 16 8.1.0 8.1.5 PUSH_SUBQ QKSFM_TRANSFORMATION PUSH_SUBQ NO_PUSH_SUBQ 2 16 8.1.0 10.2.0.5 PX_FAULT_TOLERANCE QKSFM_PQ PX_FAULT_TOLERANCE NO_PX_FAULT_TOLERANCE 1 0 12.1.0.1 12.1.0.1 PX_JOIN_FILTER QKSFM_PX_JOIN_FILTER PX_JOIN_FILTER NO_PX_JOIN_FILTER 4 336 10.2.0.1 11.1.0.6 QB_NAME QKSFM_ALL QB_NAME 2 256 10.1.0.3 QUARANTINE QKSFM_EXECUTION QUARANTINE 1 0 19.1.0 QUEUE_CURR QKSFM_CBO ACCESS 4 256 8.0.0 QUEUE_ROWP QKSFM_CBO ACCESS 4 256 8.0.0 RBO_OUTLINE QKSFM_RBO RBO_OUTLINE 1 0 10.2.0.1 10.2.0.1 REF_CASCADE_CURSOR QKSFM_CBO REF_CASCADE_CURSOR NO_REF_CASCADE 1 0 9.2.0 REMOTE_MAPPED QKSFM_ALL REMOTE_MAPPED 2 272 8.1.0 REORDER_WIF QKSFM_PARTITION REORDER_WIF NO_REORDER_WIF 2 0 18.1.0 18.1.0 RESERVOIR_SAMPLING QKSFM_EXECUTION RESERVOIR_SAMPLING 1 0 12.1.0.2 RESTORE_AS_INTERVALS QKSFM_CBO RESTORE_AS_INTERVALS 2 0 8.1.5 RESTRICT_ALL_REF_CONS QKSFM_ALL RESTRICT_ALL_REF_CONS 1 0 10.1.0.3 RESULT_CACHE QKSFM_EXECUTION RESULT_CACHE NO_RESULT_CACHE 2 0 11.1.0.6 RETRY_ON_ROW_CHANGE QKSFM_DML RETRY_ON_ROW_CHANGE 1 0 11.1.0.7 REWRITE QKSFM_TRANSFORMATION REWRITE NO_REWRITE 2 16 8.1.5 8.1.7 REWRITE_OR_ERROR QKSFM_TRANSFORMATION REWRITE 2 0 10.1.0.3 ROWID QKSFM_CBO ACCESS 4 272 8.0.0 8.1.7 RULE QKSFM_RBO MODE 1 16 8.1.0 8.1.5 SAVE_AS_INTERVALS QKSFM_CBO SAVE_AS_INTERVALS 2 0 8.1.5 SCN_ASCENDING QKSFM_ALL SCN_ASCENDING 1 0 8.1.5 SEMIJOIN QKSFM_TRANSFORMATION SEMIJOIN NO_SEMIJOIN 2 16 9.0.0 SEMIJOIN_DRIVER QKSFM_CBO SEMIJOIN_DRIVER 2 16 8.1.0 8.1.7 SEMI_TO_INNER QKSFM_CBO SEMI_TO_INNER NO_SEMI_TO_INNER 4 272 11.2.0.3 11.2.0.3 SET_GBY_PUSHDOWN QKSFM_ALL SET_GBY_PUSHDOWN NO_SET_GBY_PUSHDOWN 2 16 20.1.0 20.1.0 SET_TO_JOIN QKSFM_SET_TO_JOIN SET_TO_JOIN NO_SET_TO_JOIN 2 16 10.1.0.3 10.1.0.3 SHARED QKSFM_PARALLEL SHARED NO_PARALLEL 5 256 8.1.0 SKIP_EXT_OPTIMIZER QKSFM_CBO SKIP_EXT_OPTIMIZER 2 16 9.0.0 SKIP_PROXY QKSFM_ALL SKIP_PROXY 1 0 18.1.0 SKIP_UNQ_UNUSABLE_IDX QKSFM_CBO SKIP_UNQ_UNUSABLE_IDX 1 0 10.1.0.3 SQLLDR QKSFM_CBO SQLLDR 1 0 9.0.0 SQL_SCOPE QKSFM_COMPILATION SQL_SCOPE 1 0 12.2.0.1 STAR QKSFM_STAR_TRANS STAR 2 16 8.1.0 STAR_TRANSFORMATION QKSFM_STAR_TRANS STAR_TRANSFORMATION NO_STAR_TRANSFORMATION 6 16 8.1.0 8.1.7 STATEMENT_QUEUING QKSFM_PARALLEL STATEMENT_QUEUING NO_STATEMENT_QUEUING 1 0 11.2.0.1 STREAMS QKSFM_CBO STREAMS 1 0 10.1.0.3 SUBQUERY_PRUNING QKSFM_CBO SUBQUERY_PRUNING NO_SUBQUERY_PRUNING 4 272 11.1.0.6 11.1.0.6 SUPPRESS_LOAD QKSFM_DDL SUPPRESS_LOAD 1 0 18.1.0 SWAP_JOIN_INPUTS QKSFM_CBO SWAP_JOIN_INPUTS NO_SWAP_JOIN_INPUTS 4 272 8.1.0 8.1.7 SYSTEM_STATS QKSFM_ALL SYSTEM_STATS 1 272 18.1.0 SYS_DL_CURSOR QKSFM_CBO SYS_DL_CURSOR 1 0 9.2.0 SYS_PARALLEL_TXN QKSFM_CBO SYS_PARALLEL_TXN 2 0 8.1.6 SYS_RID_ORDER QKSFM_ALL SYS_RID_ORDER 2 0 9.2.0 TABLE_LOOKUP_BY_NL QKSFM_TABLE_LOOKUP_BY_NL TABLE_LOOKUP_BY_NL NO_TABLE_LOOKUP_BY_NL 4 16 11.2.0.2 11.2.0.2 TABLE_STATS QKSFM_STATS TABLE_STATS 1 272 10.1.0.3 TIV_GB QKSFM_ALL PIV_GB 2 0 8.1.0 TIV_SSF QKSFM_ALL PIV_SSF 2 0 8.1.0 TRACING QKSFM_EXECUTION TRACING 1 0 10.1.0.3 TRANSFORM_DISTINCT_AGG QKSFM_TRANSFORMATION TRANSFORM_DISTINCT_AGG NO_TRANSFORM_DISTINCT_AGG 2 0 11.2.0.1 11.2.0.1 UNNEST QKSFM_UNNEST UNNEST NO_UNNEST 2 16 8.1.6 10.1.0 USE_ANTI QKSFM_CBO USE_ANTI 4 272 8.1.0 USE_CONCAT QKSFM_USE_CONCAT OR_EXPAND NO_EXPAND 2 16 8.1.0 8.1.7 USE_CUBE QKSFM_USE_CUBE JOIN NO_USE_CUBE 4 336 12.1.0.1 12.1.0.1 USE_DAGG_UNION_ALL_GSETS QKSFM_GROUPING_SET_XFORM DAGG_OPTIM_GSETS NO_USE_DAGG_UNION_ALL_GSETS 2 0 12.2.0.1 12.2.0.1 USE_HASH QKSFM_USE_HASH JOIN NO_USE_HASH 4 464 8.1.0 8.1.7 USE_HASH_AGGREGATION QKSFM_ALL USE_HASH_AGGREGATION NO_USE_HASH_AGGREGATION 2 0 10.2.0.1 10.2.0.5 USE_HASH_GBY_FOR_DAGGPSHD QKSFM_ALL USE_HASH_GBY_FOR_DAGGPSHD NO_USE_HASH_GBY_FOR_DAGGPSHD 2 0 12.2.0.1 12.2.0.1 USE_HASH_GBY_FOR_PUSHDOWN QKSFM_ALL USE_HASH_GBY_FOR_PUSHDOWN NO_USE_HASH_GBY_FOR_PUSHDOWN 2 0 11.2.0.2 11.2.0.2 USE_HIDDEN_PARTITIONS QKSFM_PARTITION USE_HIDDEN_PARTITIONS 2 0 12.1.0.1 USE_INVISIBLE_INDEXES QKSFM_INDEX USE_INVISIBLE_INDEXES NO_USE_INVISIBLE_INDEXES 1 0 11.1.0.6 11.1.0.6 USE_MERGE QKSFM_USE_MERGE JOIN NO_USE_MERGE 4 336 8.1.0 8.1.7 USE_MERGE_CARTESIAN QKSFM_USE_MERGE_CARTESIAN JOIN 4 336 11.1.0.6 11.1.0.6 USE_NL QKSFM_USE_NL JOIN NO_USE_NL 4 336 8.1.0 8.1.7 USE_NL_WITH_INDEX QKSFM_USE_NL_WITH_INDEX USE_NL_WITH_INDEX NO_USE_NL 4 304 10.1.0.3 USE_PARTITION_WISE_DISTINCT QKSFM_PARTITION USE_PARTITION_WISE_DISTINCT NO_USE_PARTITION_WISE_DISTINCT 2 0 12.2.0.1 12.2.0.1 USE_PARTITION_WISE_GBY QKSFM_PARTITION USE_PARTITION_WISE_GBY NO_USE_PARTITION_WISE_GBY 2 0 12.2.0.1 12.2.0.1 USE_PARTITION_WISE_WIF QKSFM_PARTITION USE_PARTITION_WISE_WIF NO_USE_PARTITION_WISE_WIF 2 0 18.1.0 18.1.0 USE_SCALABLE_GBY_INVDIST QKSFM_PQ USE_SCALABLE_GBY_INVDIST NO_USE_SCALABLE_GBY_INVDIST 2 0 19.1.0 19.1.0 USE_SEMI QKSFM_CBO USE_SEMI 4 272 8.1.0 USE_TTT_FOR_GSETS QKSFM_TRANSFORMATION USE_TTT_FOR_GSETS 2 0 9.0.0 USE_VECTOR_AGGREGATION QKSFM_VECTOR_AGG USE_VECTOR_AGGREGATION NO_USE_VECTOR_AGGREGATION 2 16 12.1.0.2 12.1.0.2 USE_WEAK_NAME_RESL QKSFM_ALL USE_WEAK_NAME_RESL 1 0 10.1.0.3 VECTOR_READ QKSFM_CBO VECTOR_READ 1 0 10.1.0.3 VECTOR_READ_TRACE QKSFM_CBO VECTOR_READ_TRACE 1 0 10.1.0.3 VECTOR_TRANSFORM QKSFM_VECTOR_AGG VECTOR_TRANSFORM NO_VECTOR_TRANSFORM 2 16 12.1.0.2 12.1.0.2 VECTOR_TRANSFORM_DIMS QKSFM_VECTOR_AGG VECTOR_TRANSFORM_DIMS NO_VECTOR_TRANSFORM_DIMS 4 80 12.1.0.2 12.1.0.2 VECTOR_TRANSFORM_FACT QKSFM_VECTOR_AGG VECTOR_TRANSFORM_FACT NO_VECTOR_TRANSFORM_FACT 4 80 12.1.0.2 12.1.0.2 WITH_PLSQL QKSFM_ALL WITH_PLSQL 1 0 12.1.0.1 XDB_FASTPATH_INSERT QKSFM_ALL XDB_FASTPATH_INSERT NO_XDB_FASTPATH_INSERT 1 0 11.2.0.2 XMLINDEX_REWRITE QKSFM_XMLINDEX_REWRITE XMLINDEX_REWRITE NO_XMLINDEX_REWRITE 1 0 11.1.0.6 11.1.0.6 XMLINDEX_REWRITE_IN_SELECT QKSFM_XMLINDEX_REWRITE XMLINDEX_REWRITE NO_XMLINDEX_REWRITE_IN_SELECT 1 0 11.1.0.6 11.1.0.6 XMLINDEX_SEL_IDX_TBL QKSFM_ALL XMLINDEX_SEL_IDX_TBL 1 0 11.2.0.1 XMLTSET_DML_ENABLE QKSFM_ALL XMLTSET_DML_ENABLE 1 0 12.2.0.1 XML_DML_RWT_STMT QKSFM_XML_REWRITE XML_DML_RWT_STMT 1 0 11.1.0.6 11.1.0.6 X_DYN_PRUNE QKSFM_CBO X_DYN_PRUNE 2 0 10.1.0.3 ZONEMAP QKSFM_ZONEMAP ZONEMAP NO_ZONEMAP 4 256 12.1.0.1 12.1.0.1 388行が選択されました。

PostgreSQL / pg_hint_plan (22-Nov-2023時点）

pg_hint_planのヒントもOracleの影響を受けているところもあるけども、PostgreSQL独特の言い回しを使う傾向はありますよね。面白いのは、LEADINGヒントで（a b）みたいなペアで優先度を記述する部分。これかなり慣れが必要な気がします。

https://github.com/ossc-db/pg_hint_plan

https://github.com/ossc-db/pg_hint_plan/blob/master/docs/hint_list.md

Hint list

Format Description

Scan method SeqScan(table) Forces sequential scan on the table.

TidScan(table) Forces TID scan on the table.

IndexScan(table[ index...]) Forces index scan on the table. Restricts to specified indexes if any.

IndexOnlyScan(table[ index...]) Forces index-only scan on the table. Restricts to specified indexes if any. Index scan may be used if index-only scan is not available.

BitmapScan(table[ index...]) Forces bitmap scan on the table. Restricts to specified indexes if any.

IndexScanRegexp(table[ POSIX Regexp...])
IndexOnlyScanRegexp(table[ POSIX Regexp...])
BitmapScanRegexp(table[ POSIX Regexp...]) Forces index scan, index-only scan (For PostgreSQL 9.2 and later) or bitmap scan on the table. Restricts to indexes that matches the specified POSIX regular expression pattern.

NoSeqScan(table) Forces to not do sequential scan on the table.

NoTidScan(table) Forces to not do TID scan on the table.

NoIndexScan(table) Forces to not do index scan and index-only scan on the table.

NoIndexOnlyScan(table) Forces to not do index only scan on the table.

NoBitmapScan(table) Forces to not do bitmap scan on the table.

Join method NestLoop(table table[ table...]) Forces nested loop for the joins on the tables specified.

HashJoin(table table[ table...]) Forces hash join for the joins on the tables specified.

MergeJoin(table table[ table...]) Forces merge join for the joins on the tables specified.

NoNestLoop(table table[ table...]) Forces to not do nested loop for the joins on the tables specified.

NoHashJoin(table table[ table...]) Forces to not do hash join for the joins on the tables specified.

NoMergeJoin(table table[ table...]) Forces to not do merge join for the joins on the tables specified.

Join order Leading(table table[ table...]) Forces join order as specified.

Leading(<join pair>) Forces join order and directions as specified. A join pair is a pair of tables and/or other join pairs enclosed by parentheses, which can make a nested structure.

Behavior control on Join Memoize(table table[ table...]) Allows the topmost join of a join among the specified tables to Memoize the inner result. Not enforced.

NoMemoize(table table[ table...]) Inhibits the topmost join of a join among the specified tables from Memoizing the inner result.

Row number correction Rows(table table[ table...] correction) Corrects row number of a result of the joins on the tables specified. The available correction methods are absolute (#), addition (+), subtract (-) and multiplication (*). should be a string that strtod() can understand.

Parallel query configuration Parallel(table <# of workers> [soft|hard]) Enforces or inhibits parallel execution of the specified table. <# of workers> is the desired number of parallel workers, where zero means inhibiting parallel execution. If the third parameter is soft (default), it just changes max_parallel_workers_per_gather and leaves everything else to the planner. Hard enforces the specified number of workers.

GUC Set(GUC-param value) Sets GUC parameter to the value defined while planner is running.

MySQL 8.0

https://dev.mysql.com/doc/refman/8.0/en/optimizer-hints.html

Table 8.2 Optimizer Hints Available

MySQLのOptimizer HintsはOracleにもある同一用途のヒントもちらほら。ヒント名も同一で:)

Hint Name Description Applicable Scopes

BKA, NO_BKA Affects Batched Key Access join processing Query block, table

BNL, NO_BNL Prior to MySQL 8.0.20: affects Block Nested-Loop join processing; MySQL 8.0.18 and later: also affects hash join optimization; MySQL 8.0.20 and later: affects hash join optimization only Query block, table

DERIVED_CONDITION_PUSHDOWN, NO_DERIVED_CONDITION_PUSHDOWN Use or ignore the derived condition pushdown optimization for materialized derived tables (Added in MySQL 8.0.22) Query block, table

GROUP_INDEX, NO_GROUP_INDEX Use or ignore the specified index or indexes for index scans in GROUP BY operations (Added in MySQL 8.0.20) Index

HASH_JOIN, NO_HASH_JOIN Affects Hash Join optimization (MySQL 8.0.18 only Query block, table

INDEX, NO_INDEX Acts as the combination of JOIN_INDEX, GROUP_INDEX, and ORDER_INDEX, or as the combination of NO_JOIN_INDEX, NO_GROUP_INDEX, and NO_ORDER_INDEX (Added in MySQL 8.0.20) Index

INDEX_MERGE, NO_INDEX_MERGE Affects Index Merge optimization Table, index

JOIN_FIXED_ORDER Use table order specified in FROM clause for join order Query block

JOIN_INDEX, NO_JOIN_INDEX Use or ignore the specified index or indexes for any access method (Added in MySQL 8.0.20) Index

JOIN_ORDER Use table order specified in hint for join order Query block

JOIN_PREFIX Use table order specified in hint for first tables of join order Query block

JOIN_SUFFIX Use table order specified in hint for last tables of join order Query block

MAX_EXECUTION_TIME Limits statement execution time Global

MERGE, NO_MERGE Affects derived table/view merging into outer query block Table

MRR, NO_MRR Affects Multi-Range Read optimization Table, index

NO_ICP Affects Index Condition Pushdown optimization Table, index

NO_RANGE_OPTIMIZATION Affects range optimization Table, index

ORDER_INDEX, NO_ORDER_INDEX Use or ignore the specified index or indexes for sorting rows (Added in MySQL 8.0.20) Index

QB_NAME Assigns name to query block Query block

RESOURCE_GROUP Set resource group during statement execution Global

SEMIJOIN, NO_SEMIJOIN Affects semijoin strategies; beginning with MySQL 8.0.17, this also applies to antijoins Query block

SKIP_SCAN, NO_SKIP_SCAN Affects Skip Scan optimization Table, index

SET_VAR Set variable during statement execution Global

SUBQUERY Affects materialization, IN-to-EXISTS subquery strategies Query block

いよいよ、Advent Calendar 2023の季節が近くなってきました。今年は、全部俺シリーズは、やらずに、Oracle/PostgreSQL/MySQLのカレンダーへクロスポストすることだけは決めてます〜 :)
全部俺では無いけど、いくつかエントリーは書く予定ではいます。このエントリーもAdvent Calendarネタへ繋がるネタなのですけどね。w

では、また。

関連エントリー

・Oracle Database 20c 20.1.0以降〜21c 21.1.0で v$sql_hintに追加されたヒント/ FAQ

・標準はあるにはあるが癖の多いSQL 全部俺　#1 Pagination
・標準はあるにはあるが癖の多いSQL 全部俺　#2 関数名は同じでも引数が逆の罠！
・標準はあるにはあるが癖の多いSQL 全部俺　#3 データ型確認したい時あるんです
・標準はあるにはあるが癖の多いSQL 全部俺　#4 リテラル値での除算の内部精度も違うのよ!
・標準はあるにはあるが癖の多いSQL 全部俺　#5 和暦変換機能ある方が少数派
・標準はあるにはあるが癖の多いSQL 全部俺　#6 時間厳守！
・標準はあるにはあるが癖の多いSQL 全部俺　#7 期間リテラル！
・標準はあるにはあるが癖の多いSQL 全部俺　#8 翌月末日って何日？
・標準はあるにはあるが癖の多いSQL 全部俺　#9 部分文字列の扱いでも癖が出る＞＜
・標準はあるにはあるが癖の多いSQL 全部俺　#10 文字列連結の罠（有名なやつ）
・標準はあるにはあるが癖の多いSQL 全部俺　#11 デュエル、じゃなくて、デュアル
・標準はあるにはあるが癖の多いSQL 全部俺　#12 文字[列]探すにも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#13 あると便利ですが意外となかったり
・標準はあるにはあるが癖の多いSQL 全部俺　#14 連番の集合を返すにも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#15 SQL command line client
・標準はあるにはあるが癖の多いSQL 全部俺　#16 SQLのレントゲンを撮る方法
・標準はあるにはあるが癖の多いSQL 全部俺　#17 その空白は許されないのか？
・標準はあるにはあるが癖の多いSQL 全部俺　#18 (+)の外部結合は方言
・標準はあるにはあるが癖の多いSQL 全部俺　#19 帰ってきた、部分文字列の扱いでも癖w
・標準はあるにはあるが癖の多いSQL 全部俺　#20 結果セットを単一列に連結するにも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#21 演算結果にも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#22 集合演算にも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#23 複数行INSERTにも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#24 乱数作るにも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#25 SQL de Fractalsにも癖がある:)
・標準はあるにはあるが癖の多いSQL 全部俺　おまけ SQL de 湯婆婆やるにも癖がでるw
・帰ってきた！標準はあるにはあるが癖の多いSQL #1 SQL de ROT13 やるにも癖が出るw
・帰ってきた！標準はあるにはあるが癖の多いSQL #2 Actual Plan取得中のキャンセルでも癖が出る
・帰ってきた！標準はあるにはあるが癖の多いSQL #3 オプティマイザの結合順評価テーブル数上限にも癖が出る
・帰ってきた！標準はあるにはあるが癖の多いSQL #4 Optimizer Traceの取得でも癖がでる

投稿日時 2023年11月22日 (水) 20時00分 Oracle, チューニング, FAQ, SQL, MySQL, PostgreSQL, パフォーマンス | 固定リンク | 0 | コメント (0)

2023年10月11日 (水)

Oracle SQL Hinting Tips / #JoelKallmanDay

Joel Kallman Day 2023 : Announcement
の通り、本ポストは、Joel Kallman Day 2023 向けのブログポストでもあります。詳細はTimeのブログ参照のこと。

Previously on Mac De Oracle
前回は、rebuild index後のindexサイズって結局、create indexのexplainで見積もれるんだよね、というお話でした。

今回から数回、OracleのSQL ヒントの使い方テクニックでも紹介して行こうかなと思っています。
まず、最近のヒント周りの劇的な進化というか便利になったこと、最近といっても、数ヶ月とかいう単位ではないのですけどもw

Oracle 19c から hint usage report が表示されるようになりました。

19.3.3.4 ヒント使用状況レポート: 例
https://docs.oracle.com/cd/F19136_01/tgsql/influencing-the-optimizer.html#GUID-1697E7CA-9DD0-4C0D-9BC9-E4E17334C0AA

これ、今までなんでなかったの？　という感じはあります。（全くなかったわけではないのですが、よほどのことがなけれそこまでトレースしなかったというのが一番の理由でしょうね。取得および、確認方法が面倒だったのでw）

最近は、ヒントの種類も、使用頻度も多くなってきたことが影響しているのでしょうか。。。ヒント使用状況レポートがほしいという要望が多くなったのでしょうかね？　

ただ、hint usage report で簡単に確認できるようになったのは良いことだと思うのですが、その副作用というような現象に気づくことも、それなりに多くなってきました。。。

その副作用とは、ヒントが、Unusedとなるような記述は避けるべき！　のような話です
（風の便り程度で実際そうなっている状況に遭遇はしていないのですが）

それ以来、
ヒントの書き方の標準を決める際に、過度に、strictになって、逆にヒントを使いこなせない状況になったりしていないだろうか？
もしくは、その兆候があるのではないかと心配になることがあります。
昔から使われてきた柔軟なヒント記述方法が、変に制限されたりすることのないようにしてほしいものだとは思います。
（そう意味も込めて、マニュアルにも書いてるからね、この方法というのも点も強調しつつ、簡単な検証方法も合わせて紹介しています）

USE_HASHヒント
https://docs.oracle.com/cd/F19136_01/sqlrf/Comments.html#GUID-FA1147B3-BCAA-41F9-B6A2-8DEDABF1C021

USE_NLヒント
https://docs.oracle.com/cd/F19136_01/sqlrf/Comments.html#GUID-56DAA0EC-54BB-4E9D-9049-BCEA934F7A89

マニュアルにも例が記載されていますが、USE_NLやUSE_HASHヒントには、内部表（HASH結合の場合は、プローブ表）を指定します、単一表指定、複数表指定どちらも可能です。

例えば、A表とB表を2表を結合する例で言えば、
Nested Loop Join(NLJ)の駆動表、Hash Join(HJ)のビルド表が、A表だとして、

/*+ LEADING(A) USE_NL(B) */
/*+ LEADING(A) USE_HASH(B) */

のようにヒントを書くことができます。LEADINGヒントで駆動表（NLJの場合）または、ビルド表（HJの場合）を指定し、内部表または、ビルド表をUSE_NL（NLJの場合）または、USE_HASH（HJの場合）で指定する。

では、マニュアルにも記載されている以下のような記述は、どのような意味なのか、みなさん、お分かりでしょうか？

/*+ USE_NL(A B) */ 同じ意味ですが、　/*+ USE_NL(A) USE_NL(B) */
/*+ USE_HASH(A B) */ 同じ意味ですが、　/*+ USE_HASH(A) USE_HASH(B) */

A表とB表の2表ですから、どちらかが、駆動表（NLJの場合）、または、ビルド表（HJの場合）で、どちらかが、内部表（NLJの場合）、または、プローブ表（HJの場合）となります。
これらのヒントに指定した表は、指定しても無視される表（駆動表または、ビルド表）、つまり、Unused となる表も含めて記載しています。（エラーではないく、使われないだけだからですが）

あえて、そうする意味はなんでしょう。みなさんお分かりでしょうか？

答えは、結合順序はオプティマイザの判断に任せ、結合方法だけを、NLJ や HJ　にしたい！！！！！

ということです。

意外にこのような状況は多くあります。
要するに、駆動表や、ビルド表は状況に応じて柔軟に変えてもらって良いが、結合方法だけは、絶対、NLJにしたい。もしくは、HJにしたいというケースですね！
（チューニングで呼ばれて行った先で、業務観点からどの表が駆動表や、ビルド表ですか？　と聞いて、即答してくれないと、おじさん困ってしまうんですねw わからんと言われてたら、リスク覚悟で現状のデータ量から決めるか、このように決めないで、オプティマイザに任せる。みなさんもオプティマイザを信じてください！　と、言ったもののw、統計情報取得止められてたりすると、まあ、信じられないみたいな状況もあるわけです。はい。wwwww)

他のTech Tipsとして、結合順は状況に応じて人の手で書き換えること（前述したように担当者も結合順を把握していないとか、一旦、固定したけども、やはり間違ってたケースや、経年で傾向が変わったので変更したい etc.）を想定して、ヒント修正によるミスのリスクを最小化するため。（修正範囲をLEADINGヒントだけにして、変更箇所を最小にしたい場合です）

駆動表または、ビルド表の変更前
/*+ LEADING(A B) USE_NL(A B) */
/*+ LEADING(A B) USE_HASH(A B) */
/*+ LEADING(A) USE_NL(A B) */
/*+ LEADING(A) USE_HASH(A B) */

駆動表または、ビルド表の変更後
/*+ LEADING(B A) USE_NL(A B) */
/*+ LEADING(B A) USE_HASH(A B) */
/*+ LEADING(B) USE_NL(A B) */
/*+ LEADING(B) USE_HASH(A B) */

これらのヒントは、LEADINGヒントの結合順を変更するだけで、駆動表やビルド表を切り替えることができます。USE_NL、USE_HASHヒントは変更する必要がありません。（ヒント指定時のミスの発生箇所を最小化できるわけです＝変更箇所を少なくした）

しかし、以下のように記述していた場合はどうでしょう？
駆動表や、ビルド表を変更する場合、LEADING/USE_NL/USE_HASH全てのヒントを適切に修正する必要があります。

変更前
/*+ LEADING(A) USE_NL(B) */
/*+ LEADING(A) USE_HASH(B) */

変更後
/*+ LEADING(B) USE_NL(A) */
/*+ LEADING(B) USE_HASH(A) */

変更し忘れたことによりヒントが無効となり、遅延に繋がってしまったということは意外に多いです。修正しているのは、人ですからね。間違いはあります。修正する箇所と量を最小化すれば、ミスの発生リスクは減らせます。
もう一つの効果として、可読性が向上する（個人的な感覚かもしれませんが）のではないかと考えています。

ということで長い前置きはこれぐらいにして挙動を確認してみましょう。

結合順はオプティマイザ任せにして固定せず、結合方法だけをHJにした場合、Hint Usage Reportにはどうのようにレポートされるのか、また実行計画は想定通りなのか等を確認してみましょう。

Oracle Database 21cを利用して検証します。ちなみに、この方法は、Oracle 11gの頃から実戦で利用されている方法です。（マニュアルにも例が記載されているので、将来的にも挙動が変わることはないでしょう。影響でかいですからね。挙動が変わるとw）
なお、隠しパラメータのカスタマイズはせず、インストール時のままです。

SCOTT@orclpdb1> select banner from v$version; BANNER ----------------------------------------------------------------------- Oracle Database 21c Enterprise Edition Release 21.0.0.0.0 - Production

検証用の表とデータ登録、統計情報取得、データ件数確認
（なお、本検証で利用したスクリプトはこのブログの後半に記載してあります）

SCOTT@orclpdb1> @hinting_tech1 表が削除されました。経過: 00:00:00.84 表が作成されました。経過: 00:00:00.19 表が削除されました。経過: 00:00:00.51 表が作成されました。経過: 00:00:00.07 PL/SQLプロシージャが正常に完了しました。経過: 00:00:06.41 PL/SQLプロシージャが正常に完了しました。経過: 00:00:13.93 1 BEGIN 2 DBMS_STATS.GATHER_TABLE_STATS(ownname=>'SCOTT', tabname=>'TABLE_A', cascade=>true, no_invalidate=>false); 3* END; PL/SQLプロシージャが正常に完了しました。経過: 00:00:01.71 1 BEGIN 2 DBMS_STATS.GATHER_TABLE_STATS(ownname=>'SCOTT', tabname=>'TABLE_B', cascade=>true, no_invalidate=>false); 3* END; PL/SQLプロシージャが正常に完了しました。経過: 00:00:01.16 1* SELECT COUNT(1) FROM table_a COUNT(1) ---------- 50000 経過: 00:00:00.01 1* SELECT COUNT(1) FROM table_b COUNT(1) ---------- 100000 経過: 00:00:00.01 PL/SQLプロシージャが正常に完了しました。経過: 00:00:00.03

何もチューニングしていないオリジナルのSQLと実行計画を確認しておきます。少量のデータに絞って、結合（索引あり）しています。
駆動表がTABLE_Aで、NLJしていることが確認できます。

1 SELECT 2 * 3 FROM 4 table_a a 5 INNER JOIN table_b b 6 ON 7 a.id = b.id 8* AND a.id BETWEEN :s AND :e 経過: 00:00:00.04 実行計画 ---------------------------------------------------------- Plan hash value: 1883513077 ------------------------------------------------------------------------------------------------------ | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ------------------------------------------------------------------------------------------------------ | 0 | SELECT STATEMENT | | 125 | 489K| 203 (0)| 00:00:01 | |* 1 | FILTER | | | | | | | 2 | NESTED LOOPS | | 125 | 489K| 203 (0)| 00:00:01 | | 3 | NESTED LOOPS | | 125 | 489K| 203 (0)| 00:00:01 | | 4 | TABLE ACCESS BY INDEX ROWID BATCHED| TABLE_A | 125 | 244K| 78 (0)| 00:00:01 | |* 5 | INDEX RANGE SCAN | SYS_C009317 | 225 | | 2 (0)| 00:00:01 | |* 6 | INDEX UNIQUE SCAN | SYS_C009318 | 1 | | 0 (0)| 00:00:01 | | 7 | TABLE ACCESS BY INDEX ROWID | TABLE_B | 1 | 2006 | 1 (0)| 00:00:01 | ------------------------------------------------------------------------------------------------------ Predicate Information (identified by operation id): --------------------------------------------------- 1 - filter(TO_NUMBER(:E)>=TO_NUMBER(:S)) 5 - access("A"."ID">=TO_NUMBER(:S) AND "A"."ID"<=TO_NUMBER(:E)) 6 - access("A"."ID"="B"."ID") filter("B"."ID">=TO_NUMBER(:S) AND "B"."ID"<=TO_NUMBER(:E)) Note ----- - this is an adaptive plan 統計 ---------------------------------------------------------- 73 recursive calls 21 db block gets 143 consistent gets 8 physical reads 4108 redo size 8944 bytes sent via SQL*Net to client 52 bytes received via SQL*Net from client 2 SQL*Net roundtrips to/from client 11 sorts (memory) 0 sorts (disk) 5 rows processed

NLJをヒント使って、HJに強制します。索引アクセスを行わないようにFULLヒントも併用していますが、LEADINGヒントは利用せず、ビルド表の決定はオプティマイザに任せています。
実行結果とヒント使用状況レポートを確認すると、オプティマイザの判断により、TABLE_Aがビルド表となっため、USE_HASH(A)がUnusedとしてレポートされてますが、残るヒントは利用され、NLJからHJへ変更が行われています。
Unusedは最終的に利用されなかったという意味で、ヒント構文場問題があるわけではなくヒントとしては正しいが、最終的に利用されなかった。このケースではビルド表となった表TABLE_Aを指定していた、USE_HASH(A)が利用されなかったということですね。
理由は、USE_HASH/USE_NLに指定する表は、プローブ表または、内部表となっているためで、このケースではオプティマイザが最終的にTABLE_Aをビルド表としたためUSE_HASH(A)が利用されなかったということを意味しています。

1 SELECT 2 /*+ 3 FULL(a) 4 FULL(b) 5 USE_HASH(a) 6 USE_HASH(b) 7 */ 8 * 9 FROM 10 table_a a 11 INNER JOIN table_b b 12 ON 13 a.id = b.id 14* AND a.id BETWEEN :s AND :e 経過: 00:00:00.24 実行計画 ---------------------------------------------------------- Plan hash value: 3176705182 ------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 125 | 489K| 13783 (1)| 00:00:01 | |* 1 | FILTER | | | | | | |* 2 | HASH JOIN | | 125 | 489K| 13783 (1)| 00:00:01 | |* 3 | TABLE ACCESS FULL| TABLE_A | 125 | 244K| 4678 (1)| 00:00:01 | |* 4 | TABLE ACCESS FULL| TABLE_B | 250 | 489K| 9105 (1)| 00:00:01 | ------------------------------------------------------------------------------- Predicate Information (identified by operation id): --------------------------------------------------- 1 - filter(TO_NUMBER(:E)>=TO_NUMBER(:S)) 2 - access("A"."ID"="B"."ID") 3 - filter("A"."ID">=TO_NUMBER(:S) AND "A"."ID"<=TO_NUMBER(:E)) 4 - filter("B"."ID">=TO_NUMBER(:S) AND "B"."ID"<=TO_NUMBER(:E)) Hint Report (identified by operation id / Query Block Name / Object Alias): Total hints for statement: 1 (U - Unused (1)) --------------------------------------------------------------------------- 3 - SEL$58A6D7F6 / "A"@"SEL$1" U - USE_HASH(a) 統計 ---------------------------------------------------------- 30 recursive calls 0 db block gets 50366 consistent gets 50282 physical reads 0 redo size 8944 bytes sent via SQL*Net to client 52 bytes received via SQL*Net from client 2 SQL*Net roundtrips to/from client 4 sorts (memory) 0 sorts (disk) 5 rows processed

USE_HASH(a b)という記載ですが、前述のヒントと同じ意味です。この例のような指定方法だと、ヒント使用状況レポートの読み方の理解が重要になります。
U - USE_HASH(a b)　というレポートがありますが、これだけだと、ヒント全体が利用されなかったのか？　と思われるかもしれませんが、
もう一つ上の、3 - SEL$58A6D7F6 / "A"@"SEL$1"に着目する必要があります。該当ヒントの A が利用されなかったということを意味しています。

1 SELECT 2 /*+ 3 FULL(a) 4 FULL(b) 5 USE_HASH(a b) 6 */ 7 * 8 FROM 9 table_a a 10 INNER JOIN table_b b 11 ON 12 a.id = b.id 13* AND a.id BETWEEN :s AND :e 経過: 00:00:00.23 実行計画 ---------------------------------------------------------- Plan hash value: 3176705182 ------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 125 | 489K| 13783 (1)| 00:00:01 | |* 1 | FILTER | | | | | | |* 2 | HASH JOIN | | 125 | 489K| 13783 (1)| 00:00:01 | |* 3 | TABLE ACCESS FULL| TABLE_A | 125 | 244K| 4678 (1)| 00:00:01 | |* 4 | TABLE ACCESS FULL| TABLE_B | 250 | 489K| 9105 (1)| 00:00:01 | ------------------------------------------------------------------------------- Predicate Information (identified by operation id): --------------------------------------------------- 1 - filter(TO_NUMBER(:E)>=TO_NUMBER(:S)) 2 - access("A"."ID"="B"."ID") 3 - filter("A"."ID">=TO_NUMBER(:S) AND "A"."ID"<=TO_NUMBER(:E)) 4 - filter("B"."ID">=TO_NUMBER(:S) AND "B"."ID"<=TO_NUMBER(:E)) Hint Report (identified by operation id / Query Block Name / Object Alias): Total hints for statement: 1 (U - Unused (1)) --------------------------------------------------------------------------- 3 - SEL$58A6D7F6 / "A"@"SEL$1" U - USE_HASH(a b) 統計 ---------------------------------------------------------- 24 recursive calls 0 db block gets 50298 consistent gets 50282 physical reads 0 redo size 8944 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

この検証では、LEADINGヒントを利用せず、オプティマイザ任せにしてあります。もう一つの検証として、オプティマイザが駆動表というかビルド表にする表を変えたケースも確認しておきたいですよね！　ヒント指定の思惑通りの挙動になるか。。。確認は必要ですよからねw （実案件ではここまで確認はしませんけどもw 本記事の目的がその確認ですのでw）

データをからにして、行数を逆にして、駆動表というかビルド表が変わるように仕掛けておきます。

1* truncate table table_a 表が切り捨てられました。経過: 00:00:00.44 1* truncate table table_b 表が切り捨てられました。経過: 00:00:00.13 PL/SQLプロシージャが正常に完了しました。経過: 00:00:07.02 PL/SQLプロシージャが正常に完了しました。経過: 00:00:13.49 1 BEGIN 2 DBMS_STATS.GATHER_TABLE_STATS(ownname=>'SCOTT', tabname=>'TABLE_A', cascade=>true, no_invalidate=>false); 3* END; PL/SQLプロシージャが正常に完了しました。経過: 00:00:03.19 1 BEGIN 2 DBMS_STATS.GATHER_TABLE_STATS(ownname=>'SCOTT', tabname=>'TABLE_B', cascade=>true, no_invalidate=>false); 3* END; PL/SQLプロシージャが正常に完了しました。経過: 00:00:01.54 1* SELECT COUNT(1) FROM table_a COUNT(1) ---------- 100000 経過: 00:00:00.02 1* SELECT COUNT(1) FROM table_b COUNT(1) ---------- 50000 経過: 00:00:00.01

何もしていないオプティマイザ任せの実行計画は、NLJで、狙い通りにTABLE_Bが駆動表に切り替わっています。（うまく行ってよかったw）

1 SELECT 2 * 3 FROM 4 table_a a 5 INNER JOIN table_b b 6 ON 7 a.id = b.id 8* AND b.id BETWEEN :s AND :e 経過: 00:00:00.05 実行計画 ---------------------------------------------------------- Plan hash value: 3627193911 ------------------------------------------------------------------------------------------------------ | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ------------------------------------------------------------------------------------------------------ | 0 | SELECT STATEMENT | | 125 | 489K| 203 (0)| 00:00:01 | |* 1 | FILTER | | | | | | | 2 | NESTED LOOPS | | 125 | 489K| 203 (0)| 00:00:01 | | 3 | NESTED LOOPS | | 125 | 489K| 203 (0)| 00:00:01 | | 4 | TABLE ACCESS BY INDEX ROWID BATCHED| TABLE_B | 125 | 244K| 78 (0)| 00:00:01 | |* 5 | INDEX RANGE SCAN | SYS_C009318 | 225 | | 2 (0)| 00:00:01 | |* 6 | INDEX UNIQUE SCAN | SYS_C009317 | 1 | | 0 (0)| 00:00:01 | | 7 | TABLE ACCESS BY INDEX ROWID | TABLE_A | 1 | 2006 | 1 (0)| 00:00:01 | ------------------------------------------------------------------------------------------------------ Predicate Information (identified by operation id): --------------------------------------------------- 1 - filter(TO_NUMBER(:E)>=TO_NUMBER(:S)) 5 - access("B"."ID">=TO_NUMBER(:S) AND "B"."ID"<=TO_NUMBER(:E)) 6 - access("A"."ID"="B"."ID") filter("A"."ID">=TO_NUMBER(:S) AND "A"."ID"<=TO_NUMBER(:E)) Note ----- - this is an adaptive plan 統計 ---------------------------------------------------------- 86 recursive calls 0 db block gets 113 consistent gets 7 physical reads 0 redo size 8944 bytes sent via SQL*Net to client 52 bytes received via SQL*Net from client 2 SQL*Net roundtrips to/from client 9 sorts (memory) 0 sorts (disk) 5 rows processed

先ほどと同じヒントを指定しました。LEADINGヒントはないので、オプティマイザは、TABLE_Bをビルド表として選択しました。狙い通りですね。
ということは、今度は、USE_HASH(B)がUnusedになるはずです。ビルド表になりましたからね。先ほどは、プローブ表だったわけですが。

ヒント使用状況レポートの詳細にはいかのようにレポートされました。USE_HASH(A B)という表よりは直感的に理解しやすいと思いますが、B　Unusedですよということですね。
3 - SEL$58A6D7F6 / "B"@"SEL$1"
U - USE_HASH(b)

1 SELECT 2 /*+ 3 FULL(a) 4 FULL(b) 5 USE_HASH(a) 6 USE_HASH(b) 7 */ 8 * 9 FROM 10 table_a a 11 INNER JOIN table_b b 12 ON 13 a.id = b.id 14* AND b.id BETWEEN :s AND :e 経過: 00:00:00.22 実行計画 ---------------------------------------------------------- Plan hash value: 3989351480 ------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 125 | 489K| 13783 (1)| 00:00:01 | |* 1 | FILTER | | | | | | |* 2 | HASH JOIN | | 125 | 489K| 13783 (1)| 00:00:01 | |* 3 | TABLE ACCESS FULL| TABLE_B | 125 | 244K| 4678 (1)| 00:00:01 | |* 4 | TABLE ACCESS FULL| TABLE_A | 250 | 489K| 9105 (1)| 00:00:01 | ------------------------------------------------------------------------------- Predicate Information (identified by operation id): --------------------------------------------------- 1 - filter(TO_NUMBER(:E)>=TO_NUMBER(:S)) 2 - access("A"."ID"="B"."ID") 3 - filter("B"."ID">=TO_NUMBER(:S) AND "B"."ID"<=TO_NUMBER(:E)) 4 - filter("A"."ID">=TO_NUMBER(:S) AND "A"."ID"<=TO_NUMBER(:E)) Hint Report (identified by operation id / Query Block Name / Object Alias): Total hints for statement: 1 (U - Unused (1)) --------------------------------------------------------------------------- 3 - SEL$58A6D7F6 / "B"@"SEL$1" U - USE_HASH(b) 統計 ---------------------------------------------------------- 113 recursive calls 0 db block gets 50787 consistent gets 50526 physical reads 0 redo size 8944 bytes sent via SQL*Net to client 52 bytes received via SQL*Net from client 2 SQL*Net roundtrips to/from client 25 sorts (memory) 0 sorts (disk) 5 rows processed

USE_HASH(a b)という表記にした例です意味は同じですが、USE_HASH(a b)全体がUnusedなのかと勘違いしそうですよね。よーく見てみましょう。SEL$58A6D7F6 / "B"@"SEL$1" とあり、 USE_HASH(a b)のうち、B が Unusedであることが確認できます。
3 - SEL$58A6D7F6 / "B"@"SEL$1"
U - USE_HASH(a b)

1 SELECT 2 /*+ 3 FULL(a) 4 FULL(b) 5 USE_HASH(a b) 6 */ 7 * 8 FROM 9 table_a a 10 INNER JOIN table_b b 11 ON 12 a.id = b.id 13* AND b.id BETWEEN :s AND :e 経過: 00:00:00.23 実行計画 ---------------------------------------------------------- Plan hash value: 3989351480 ------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 125 | 489K| 13783 (1)| 00:00:01 | |* 1 | FILTER | | | | | | |* 2 | HASH JOIN | | 125 | 489K| 13783 (1)| 00:00:01 | |* 3 | TABLE ACCESS FULL| TABLE_B | 125 | 244K| 4678 (1)| 00:00:01 | |* 4 | TABLE ACCESS FULL| TABLE_A | 250 | 489K| 9105 (1)| 00:00:01 | ------------------------------------------------------------------------------- Predicate Information (identified by operation id): --------------------------------------------------- 1 - filter(TO_NUMBER(:E)>=TO_NUMBER(:S)) 2 - access("A"."ID"="B"."ID") 3 - filter("B"."ID">=TO_NUMBER(:S) AND "B"."ID"<=TO_NUMBER(:E)) 4 - filter("A"."ID">=TO_NUMBER(:S) AND "A"."ID"<=TO_NUMBER(:E)) Hint Report (identified by operation id / Query Block Name / Object Alias): Total hints for statement: 1 (U - Unused (1)) --------------------------------------------------------------------------- 3 - SEL$58A6D7F6 / "B"@"SEL$1" U - USE_HASH(a b) 統計 ---------------------------------------------------------- 5 recursive calls 0 db block gets 50541 consistent gets 50526 physical reads 0 redo size 8944 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

本検証で利用したスクリプト（ hinting_tech1.sql ）

drop table table_a purge / create table table_a ( id number primary key , dummy_str varchar2(2000) ) / drop table table_b purge / create table table_b ( id number primary key , dummy_str varchar2(2000) ) / BEGIN FOR i IN 1..50000 LOOP INSERT INTO table_a VALUES(i,LPAD('*',2000,'*')); IF MOD(i,100) = 0 THEN COMMIT; END IF; END LOOP; END; / BEGIN FOR i IN 1..100000 LOOP INSERT INTO table_b VALUES(i,LPAD('*',2000,'*')); IF MOD(i,100) = 0 THEN COMMIT; END IF; END LOOP; END; / BEGIN DBMS_STATS.GATHER_TABLE_STATS(ownname=>'SCOTT', tabname=>'TABLE_A', cascade=>true, no_invalidate=>false); END; . l / BEGIN DBMS_STATS.GATHER_TABLE_STATS(ownname=>'SCOTT', tabname=>'TABLE_B', cascade=>true, no_invalidate=>false); END; . l / SELECT COUNT(1) FROM table_a . l / SELECT COUNT(1) FROM table_b . l / REM **** Original - No Hint - 1-0 **** VARIABLE s NUMBER VARIABLE e NUMBER BEGIN :s := 1; :e := 5; END; . / SELECT * FROM table_a a INNER JOIN table_b b ON a.id = b.id AND a.id BETWEEN :s AND :e . l set autot trace exp stat / set autot off REM **** pattern 1-1 **** SELECT /*+ FULL(a) FULL(b) USE_HASH(a) USE_HASH(b) */ * FROM table_a a INNER JOIN table_b b ON a.id = b.id AND a.id BETWEEN :s AND :e . l set autot trace exp stat / set autot off REM **** pattern 1-2 **** SELECT /*+ FULL(a) FULL(b) USE_HASH(a b) */ * FROM table_a a INNER JOIN table_b b ON a.id = b.id AND a.id BETWEEN :s AND :e . l set autot trace exp stat / set autot off truncate table table_a . l / truncate table table_b . l / BEGIN FOR i IN 1..50000 LOOP INSERT INTO table_b VALUES(i,LPAD('*',2000,'*')); IF MOD(i,100) = 0 THEN COMMIT; END IF; END LOOP; END; / BEGIN FOR i IN 1..100000 LOOP INSERT INTO table_a VALUES(i,LPAD('*',2000,'*')); IF MOD(i,100) = 0 THEN COMMIT; END IF; END LOOP; END; / BEGIN DBMS_STATS.GATHER_TABLE_STATS(ownname=>'SCOTT', tabname=>'TABLE_A', cascade=>true, no_invalidate=>false); END; . l / BEGIN DBMS_STATS.GATHER_TABLE_STATS(ownname=>'SCOTT', tabname=>'TABLE_B', cascade=>true, no_invalidate=>false); END; . l / SELECT COUNT(1) FROM table_a . l / SELECT COUNT(1) FROM table_b . l / REM **** Original - No Hint - 2-0 **** SELECT * FROM table_a a INNER JOIN table_b b ON a.id = b.id AND b.id BETWEEN :s AND :e . l set autot trace exp stat / set autot off REM **** pattern 2-1 **** SELECT /*+ FULL(a) FULL(b) USE_HASH(a) USE_HASH(b) */ * FROM table_a a INNER JOIN table_b b ON a.id = b.id AND b.id BETWEEN :s AND :e . l set autot trace exp stat / set autot off REM **** pattern 2-2 **** SELECT /*+ FULL(a) FULL(b) USE_HASH(a b) */ * FROM table_a a INNER JOIN table_b b ON a.id = b.id AND b.id BETWEEN :s AND :e . l set autot trace exp stat / set autot off

やっと、涼しくなってきたけど、涼しくなるのが急すぎて、まじで季節の変化が急激になってきたなぁと。

では、また。

投稿日時 2023年10月11日 (水) 00時00分 Oracle, チューニング, FAQ, SQL, パフォーマンス | 固定リンク | 0 | コメント (0)

2023年9月28日 (木)

explain plan for文で、rebuild　後の索引サイズも見積れる！ / FAQ

Jonathan Lewisが、索引rebuild後のサイズ見積もりで昔からある方法を紹介していた. そういえば、私が以前紹介していた方法で見積もれるよね！
ということで、簡単な例で紹介しておきますね。

この方法、通常は、create indexの時にしか使えないのですが、結局のところ、alter index ...rebuildも、create indexもindexを作成することには違いはないので、rebuilddでもcreateでも最終的な索引サイズには同じだよね。という単純な発想です。どうせ、ballpark figureなわけで、厳密性不要なわけですし、リーズナブルだと思います。

参考
explain plan文 De 索引サイズ見積 / FAQ

では、試してみましょう！

索引の無い表を作ります！

1 CREATE TABLE foobar 2 ( 3 key_code CHAR(10) NOT NULL 4* ) 表が作成されました。

データを登録します。この例では　10万行登録してあります。（単純なぐるぐる方式ですが、大した量ではないので気にしないでくださいw）

1 BEGIN 2 FOR i IN 1..100000 LOOP 3 INSERT INTO foobar VALUES(TO_CHAR(i,'FM0000000009')); 4 IF MOD(i,100) = 0 5 THEN 6 COMMIT; 7 END IF; 8 END LOOP; 9* END; PL/SQLプロシージャが正常に完了しました。

統計情報を取得します。

1 BEGIN 2 DBMS_STATS.GATHER_TABLE_STATS(ownname=>'SCOTT', tabname=>'FOOBAR', cascade=>true, no_invalidate=>false); 3* END; PL/SQLプロシージャが正常に完了しました。

まずは、create index文で作成される索引サイズの見積もりを行います。(見積もりだけなので実際には作成されません！）
3145KBとの見積もりです

1* EXPLAIN PLAN FOR CREATE INDEX ix_foobar ON foobar(key_code) 解析されました。 @?/rdbms/admin/utlxpls PLAN_TABLE_OUTPUT ------------------------------------------------------------------------------------ Plan hash value: 4144366834 ------------------------------------------------------------------------------------ | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ------------------------------------------------------------------------------------ | 0 | CREATE INDEX STATEMENT | | 100K| 1074K| 143 (1)| 00:00:01 | | 1 | INDEX BUILD NON UNIQUE| IX_FOOBAR | | | | | | 2 | SORT CREATE INDEX | | 100K| 1074K| | | | 3 | TABLE ACCESS FULL | FOOBAR | 100K| 1074K| 69 (2)| 00:00:01 | ------------------------------------------------------------------------------------ Note ----- - estimated index size: 3145K bytes 14行が選択されました。

では、見積もりとの乖離を確認するために実際に索引を作成して、セグメントサイズを確認してみましょう。
3072KBとなりました。見積もりは、3145KBでした。大きな差はないですよね。これで十分でしょう。

1* CREATE INDEX ix_foobar ON foobar(key_code) 索引が作成されました。

統計情報を取得して、セグメントサイズを確認します。

1 BEGIN 2 DBMS_STATS.GATHER_TABLE_STATS(ownname=>'SCOTT', tabname=>'FOOBAR', cascade=>true, no_invalidate=>false); 3* END; PL/SQLプロシージャが正常に完了しました。 1* select segment_name,segment_type,sum(bytes)/1024 AS "KB" from user_segments where segment_name = 'IX_FOOBAR' group by segment_name,segment_type SEGMENT_NAME SEGMENT_TYPE KB ------------------------------ ------------------------------------------------------ ---------- IX_FOOBAR INDEX 3072

次に rebuild したサイズを見積もるため、50%程度のデータを削除します。

1* DELETE FROM foobar WHERE key_code BETWEEN '0000000000' AND '0000050000' 50000行が削除されました。 1* COMMIT コミットが完了しました。

統計を取得します。

1 BEGIN 2 DBMS_STATS.GATHER_TABLE_STATS(ownname=>'SCOTT', tabname=>'FOOBAR', cascade=>true, no_invalidate=>false); 3* END; PL/SQLプロシージャが正常に完了しました。

50%削除しましたが、rebuild前なのでサイズはcreate index時と同じですよね。

1* select segment_name,segment_type,sum(bytes)/1024 AS "KB" from user_segments where segment_name = 'IX_FOOBAR' group by segment_name,segment_type SEGMENT_NAME SEGMENT_TYPE KB ------------------------------ ------------------------------------------------------ ---------- IX_FOOBAR INDEX 3072

この状態で、alter index .... rebuild文ではなく、create index文でサイズを見積もります。
2097KBになると見積もられました。

1* EXPLAIN PLAN FOR CREATE INDEX ix_foobar ON foobar(key_code) 解析されました。 @?/rdbms/admin/utlxpls PLAN_TABLE_OUTPUT ------------------------------------------------------------------------------------ Plan hash value: 4144366834 ------------------------------------------------------------------------------------ | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ------------------------------------------------------------------------------------ | 0 | CREATE INDEX STATEMENT | | 50000 | 537K| 80 (0)| 00:00:01 | | 1 | INDEX BUILD NON UNIQUE| IX_FOOBAR | | | | | | 2 | SORT CREATE INDEX | | 50000 | 537K| | | | 3 | TABLE ACCESS FULL | FOOBAR | 50000 | 537K| 43 (0)| 00:00:01 | ------------------------------------------------------------------------------------ Note ----- - estimated index size: 2097K bytes 14行が選択されました。

alter index ... rebuildは、expla plan forでは索引サイズを見積もれないことも、念の為に確認しておきましょう。
見積もられないですよね。間違いなく！

1* EXPLAIN PLAN FOR ALTER INDEX ix_foobar REBUILD 解析されました。 @?/rdbms/admin/utlxpls PLAN_TABLE_OUTPUT ------------------------------------------------------------------------------------ Plan hash value: 4144366834 ------------------------------------------------------------------------------------ | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ------------------------------------------------------------------------------------ | 0 | ALTER INDEX STATEMENT | | 50000 | 537K| 43 (0)| 00:00:01 | | 1 | INDEX BUILD NON UNIQUE| IX_FOOBAR | | | | | | 2 | SORT CREATE INDEX | | 50000 | 537K| | | | 3 | TABLE ACCESS FULL | FOOBAR | 50000 | 537K| 43 (0)| 00:00:01 | ------------------------------------------------------------------------------------ 10行が選択されました。

最後に、実際に alter index ... rebuildしてみるとサイズはどうなるでしょうか！　確認してみましょう！
はい！　　2048KBとreuildしてコンパクトになりました！。　見積もりサイズは、2097KB でした。この程度の誤差は問題にもならないでしょう。

1* ALTER INDEX ix_foobar REBUILD 索引が変更されました。 1* select segment_name,segment_type,sum(bytes)/1024 AS "KB" from user_segments where segment_name = 'IX_FOOBAR' group by segment_name,segment_type SEGMENT_NAME SEGMENT_TYPE KB ------------------------------ ------------------------------------------------------ ---------- IX_FOOBAR INDEX 2048

今回使用したSQLスクリプト

[oracle@localhost ~]$ cat estimate_rebuild_index_size.sql DROP TABLE foobar PURGE . l / CREATE TABLE foobar ( key_code CHAR(10) NOT NULL ) . l / BEGIN FOR i IN 1..100000 LOOP INSERT INTO foobar VALUES(TO_CHAR(i,'FM0000000009')); IF MOD(i,100) = 0 THEN COMMIT; END IF; END LOOP; END; . l / BEGIN DBMS_STATS.GATHER_TABLE_STATS(ownname=>'SCOTT', tabname=>'FOOBAR', cascade=>true, no_invalidate=>false); END; . l / EXPLAIN PLAN FOR CREATE INDEX ix_foobar ON foobar(key_code) . l / @?/rdbms/admin/utlxpls CREATE INDEX ix_foobar ON foobar(key_code) . l / BEGIN DBMS_STATS.GATHER_TABLE_STATS(ownname=>'SCOTT', tabname=>'FOOBAR', cascade=>true, no_invalidate=>false); END; . l / select segment_name,segment_type,sum(bytes)/1024 AS "KB" from user_segments where segment_name = 'IX_FOOBAR' group by segment_name,segment_type . l / DELETE FROM foobar WHERE key_code BETWEEN '0000000000' AND '0000050000' . l / COMMIT . l / BEGIN DBMS_STATS.GATHER_TABLE_STATS(ownname=>'SCOTT', tabname=>'FOOBAR', cascade=>true, no_invalidate=>false); END; . l / select segment_name,segment_type,sum(bytes)/1024 AS "KB" from user_segments where segment_name = 'IX_FOOBAR' group by segment_name,segment_type . l / EXPLAIN PLAN FOR CREATE INDEX ix_foobar ON foobar(key_code) . l / @?/rdbms/admin/utlxpls EXPLAIN PLAN FOR CREATE INDEX ix_foobar ON foobar(key_code) . l / @?/rdbms/admin/utlxpls EXPLAIN PLAN FOR ALTER INDEX ix_foobar REBUILD . l / @?/rdbms/admin/utlxpls ALTER INDEX ix_foobar REBUILD . l / select segment_name,segment_type,sum(bytes)/1024 AS "KB" from user_segments where segment_name = 'IX_FOOBAR' group by segment_name,segment_type . l / DROP TABLE foobar PURGE . l /

ちょっと、涼しくなったと思ったら、残暑がキツイ。

では、また。

投稿日時 2023年9月28日 (木) 18時57分 Oracle, FAQ, SQL | 固定リンク | 0 | コメント (0)

2023年9月23日 (土)

帰ってきた！標準はあるにはあるが癖の多いSQL #4 Optimizer Traceの取得でも癖がでる

Previously on Mac De Oracle
前回は、MySQLのHash Join を取り上げました。MySQL 8.0.32では NLJに使えるINDEXが存在していても、Hash Joinをヒントで強制することができる！（オプティマイザが選択することがある！）
（MySQLの生い立ちを考えると、Hash Joinとか言われると、MySQLもHash Joinが必要な時代になったのか〜。と遠くを見る自分がいるw）

ということで、今回は、前々回とりあげた、
悩ませ過ぎは及ばざるがごとし（MySQL 8.0.32編）で思い出したネタで、オプティマイザがパースに悩むというか、考えすぎている姿を、時間ではなく、オプティマイザトレースのサイズから見える化して比較！！！　してみたいと思います。

実は、
10億年以上前に、Oracle Databaseで同じことやってましたw

MySQLへ話を戻すと、
MySQLのオプティマイザトレースは、Oracle Databaseのそれとは少々ことなり、パラメータで指定されたメモリー上にJSON形式で記録され、INFORMATION_SCHEMA経由で問い合わせて確認します。
パラメータで指定されたメモリーサイズを超えるトレースは切り捨てられてしまいます。Oracle Databaseのオプティマイザトレースとは異なる注意点ですね。

また、面白い特徴もあります。
オプティマイザトレースの出力サイズを事前に予測することはできないわけですが、メモリー内に記録しきれず切り捨てたバイト数をレポートしてくれます。
その機能を利用し、切り捨てたれたトレースのバイト数とトレースを記録するために指定したメモリーのバイト数の合計からトレースのサイズを確認することはできます！　面白い仕組みを提供してくれてますよね。

余談
Oracle/MySQLは、オプティマイザトレースを明示的に取得できますが、PostgreSQLって、オプティマイザトレースだけを取得するOracleの10053トレースやMySQLのoptimizer_trace=onに類似する方法はなかったはず。
（DB側の機能の一部としてはないという認識なので、もし勘違いしていたら、ツッコミ🙇よろしくお願いします）

細けーことはこれぐらいにして、比較してみましょう。

まず、前回もネタにした、パース時間のながーーーーーーい、クエリー。
explainだけで、29秒　です！！　　11!　の組み合わせをみているわけですから、デフォルト設定のMySQL、ものすごーく考えてますよね。
OracleとかPostgreSQLならとっくに諦めている数です。

参考）
検証で利用しているMySQLの表及び索引定義とSQLスクリプトは以下ブログ参照のこと。
帰ってきた！標準はあるにはあるが癖の多いSQL #3 オプティマイザの結合順評価テーブル数上限にも癖が出る

mysql> select version(); +-----------+ | version() | +-----------+ | 8.0.32 | +-----------+ 1 row in set (0.00 sec)

mysql> \. test1.sql Database changed +----------------------------------------------------------------------------------------------------------------------+ | PLAIN | +----------------------------------------------------------------------------------------------------------------------+ | -> Nested loop inner join (cost=7163.00 rows=10240) -> Nested loop inner join (cost=3579.00 rows=5120) -> Nested loop inner join (cost=1787.00 rows=2560) -> Nested loop inner join (cost=891.00 rows=1280) -> Nested loop inner join (cost=443.00 rows=640) -> Nested loop inner join (cost=219.00 rows=320) -> Nested loop inner join (cost=107.00 rows=160) -> Nested loop inner join (cost=51.00 rows=80) -> Nested loop inner join (cost=23.00 rows=40) -> Nested loop inner join (cost=9.00 rows=20) -> Index scan on master using ix_master (cost=2.00 rows=10) -> Index lookup on detail using PRIMARY (id=`master`.id) (cost=0.52 rows=2) -> Index lookup on t2 using PRIMARY (id=`master`.id) (cost=0.51 rows=2) -> Index lookup on t3 using PRIMARY (id=`master`.id) (cost=0.51 rows=2) -> Index lookup on t4 using PRIMARY (id=`master`.id) (cost=0.50 rows=2) -> Index lookup on t5 using PRIMARY (id=`master`.id) (cost=0.50 rows=2) -> Index lookup on t6 using PRIMARY (id=`master`.id) (cost=0.50 rows=2) -> Index lookup on t7 using PRIMARY (id=`master`.id) (cost=0.50 rows=2) -> Index lookup on t8 using PRIMARY (id=`master`.id) (cost=0.50 rows=2) -> Index lookup on t9 using PRIMARY (id=`master`.id) (cost=0.50 rows=2) -> Index lookup on t10 using PRIMARY (id=`master`.id) (cost=0.50 rows=2) | +----------------------------------------------------------------------------------------------------------------------+ 1 row in set (29.05 sec)

MySQLでオプティマイザトレースを取得するには、optimizer_trace を on 、optimizer_trace_max_mem_size　にオプティマイザトレース記録に必要なメモリーサイズを指定します。
その後、explain文でオプティマイザトレースを取得します。なお、今回は、explainでパース部分だけをトレースして比較します。
https://dev.mysql.com/doc/refman/8.0/en/information-schema-optimizer-trace-table.html

optimizer_trace_max_mem_size を 100 bytesにして、確実に切り捨てが起きるように設定します。

mysql> show variables like 'optimizer_trace'; +-----------------+--------------------------+ | Variable_name | Value | +-----------------+--------------------------+ | optimizer_trace | enabled=off,one_line=off | +-----------------+--------------------------+ 1 row in set (0.18 sec) mysql> SET optimizer_trace="enabled=on"; Query OK, 0 rows affected (0.01 sec) mysql> show variables like 'optimizer_trace'; +-----------------+-------------------------+ | Variable_name | Value | +-----------------+-------------------------+ | optimizer_trace | enabled=on,one_line=off | +-----------------+-------------------------+ 1 row in set (0.00 sec) mysql> show variables like 'optimizer_trace_max_mem_size'; +------------------------------+---------+ | Variable_name | Value | +------------------------------+---------+ | optimizer_trace_max_mem_size | 1048576 | +------------------------------+---------+ 1 row in set (0.00 sec) mysql> SET optimizer_trace_max_mem_size = 100; Query OK, 0 rows affected (0.00 sec) mysql> show variables like 'optimizer_trace_max_mem_size'; +------------------------------+-------+ | Variable_name | Value | +------------------------------+-------+ | optimizer_trace_max_mem_size | 100 | +------------------------------+-------+ 1 row in set (0.00 sec)

オプティマイザトレースの準備ができたので、explainしてみましょう！

mysql> \. test1.sql Database changed +----------------------------------------------------------------------------------------------------------------------+ | PLAIN | +----------------------------------------------------------------------------------------------------------------------+ | -> Nested loop inner join (cost=7163.00 rows=10240) -> Nested loop inner join (cost=3579.00 rows=5120) -> Nested loop inner join (cost=1787.00 rows=2560) -> Nested loop inner join (cost=891.00 rows=1280) -> Nested loop inner join (cost=443.00 rows=640) -> Nested loop inner join (cost=219.00 rows=320) -> Nested loop inner join (cost=107.00 rows=160) -> Nested loop inner join (cost=51.00 rows=80) -> Nested loop inner join (cost=23.00 rows=40) -> Nested loop inner join (cost=9.00 rows=20) -> Index scan on master using ix_master (cost=2.00 rows=10) -> Index lookup on detail using PRIMARY (id=`master`.id) (cost=0.52 rows=2) -> Index lookup on t2 using PRIMARY (id=`master`.id) (cost=0.51 rows=2) -> Index lookup on t3 using PRIMARY (id=`master`.id) (cost=0.51 rows=2) -> Index lookup on t4 using PRIMARY (id=`master`.id) (cost=0.50 rows=2) -> Index lookup on t5 using PRIMARY (id=`master`.id) (cost=0.50 rows=2) -> Index lookup on t6 using PRIMARY (id=`master`.id) (cost=0.50 rows=2) -> Index lookup on t7 using PRIMARY (id=`master`.id) (cost=0.50 rows=2) -> Index lookup on t8 using PRIMARY (id=`master`.id) (cost=0.50 rows=2) -> Index lookup on t9 using PRIMARY (id=`master`.id) (cost=0.50 rows=2) -> Index lookup on t10 using PRIMARY (id=`master`.id) (cost=0.50 rows=2) | +----------------------------------------------------------------------------------------------------------------------+ 1 row in set (7 min 3.67 sec)

次に、INFORMATION_SCHEMA.OPTIMIZER_TRACEからオプティマイザトレースを取得してみます。

2147483647 bytes （切り捨てられたトレースのサイズ）+ 100 bytes （optimizer_trace_max_mem_sizeパラメータに指定したサイズ）= 2,147,483,747 bytes およそ 2GB です

mysql> SELECT * FROM INFORMATION_SCHEMA.OPTIMIZER_TRACE\G *************************** 1. row *************************** QUERY: explain format=tree select * from master inner join detail on master.id = detail.id inner join detail t2 on t2.id = detail.id inner join detail t3 on t3.id = t2.id inner join detail t4 on t4.id = t3.id inner join detail t5 on t5.id = t4.id inner join detail t6 on t6.id = t5.id inner join detail t7 on t7.id = t6.id inner join detail t8 on t8.id = t7.id inner join detail t9 on t9.id = t8.id inner join detail t10 on t10.id = t9.id TRACE: { "steps": [ { "join_preparation": { "select#": 1, "steps": [ { "expanded_query": "/* select#1 */ select `master`.`id` AS `id`,`master`.`dummya` AS `dummya`,`detail`.`id` AS `id`,`detail`.`subid` AS `subid`,`detail`.`dummya` AS `dummya`,`t2`.`id` AS `id`, `t2`.`subid` AS `subid`,`t2`.`dummya` AS `dummya`,`t3`.`id` AS `id`,`t3`.`subid` AS `subid`,`t3`.`dummya` AS `dummya`,`t4`.`id` AS `id`,`t4`.`subid` AS `subid`,`t4`.`dummya` AS `dummya`, `t5`.`id` AS `id`,`t5`.`subid` AS `subid`,`t5`.`dummya` AS `dummya`,`t6`.`id` AS `id`,`t6`.`subid` AS `subid`,`t6`.`dummya` AS `dummya`,`t7`.`id` AS `id`,`t7`.`subid` AS `subid`, `t7`.`dummya` AS `dummya`,`t8`.`id` AS `id`,`t8`.`subid` AS `subid`,`t8`.`dummya` AS `dummya`,`t9`.`id` AS `id`,`t9`.`subid` AS `subid`,`t9`.`dummya` AS `dummya`,`t10`.`id` AS `id`, `t10`.`subid` AS `subid`,`t10`.`dummya` AS `dummya` from ((((((((((`master` join `detail` on((`master`.`id` = `detail`.`id`))) join `detail` `t2` on((`t2`.`id` = `detail`.`id`))) join `detail` `t3` on((`t3`.`id` = `t2`.`id`))) join `detail` `t4` on((`t4`.`id` = `t3`.`id`))) join `detail` `t5` on((`t5`.`id` = `t4`.`id`))) join `detail` `t6` on((`t6`.`id` = `t5`.`id`))) join `detail` `t7` on((`t7`.`id` = `t6`.`id`))) join `detail` `t8` on((`t8`.`id` = `t7`.`id`))) join `detail` `t9` on((`t9`.`id` = `t8`.`id`))) join `detail` `t10` on((`t10`.`id` = `t9`.`id`)))" }, { "transformations_to_nested_joins": { "transformations": [ "JOIN_condition_to_WHERE", "parenthesis_removal" ], "expanded_query": "/* select#1 */ select `master`.`id` AS `id`,`master`.`dummya` AS `dummya`,`detail`.`id` AS `id`,`detail`.`subid` AS `subid`,`detail`.`dummya` AS `dummya`, `t2`.`id` AS `id`,`t2`.`subid` AS `subid`,`t2`.`dummya` AS `dummya`,`t3`.`id` AS `id`,`t3`.`subid` AS `subid`,`t3`.`dummya` AS `dummya`,`t4`.`id` AS `id`,`t4`.`subid` AS `subid`, `t4`.`dummya` AS `dummya`,`t5`.`id` AS `id`,`t5`.`subid` AS `subid`,`t5`.`dummya` AS `dummya`,`t6`.`id` AS `id`,`t6`.`subid` AS `subid`,`t6`.`dummya` AS `dummya`,`t7`.`id` AS `id`, `t7`.`subid` AS `subid`,`t7`.`dummya` AS `dummya`,`t8`.`id` AS `id`,`t8`.`subid` AS `subid`,`t8`.`dummya` AS `dummya`,`t9`.`id` AS `id`,`t9`.`subid` AS `subid`, `t9`.`dummya` AS `dummya`,`t10`.`id` AS `id`,`t10`.`subid` AS `subid`,`t10`.`dummya` AS `dummya` from `master` join `detail` join `detail` `t2` join `detail` `t3` join `detail` `t4` join `detail` `t5` join `detail` `t6` join `detail` `t7` join `detail` `t8` join `detail` `t9` join `detail` `t10` where ((`t10`.`id` = `t9`.`id`) and (`t9`.`id` = `t8`.`id`) and (`t8`.`id` = `t7`.`id`) and (`t7`.`id` = `t6`.`id`) and (`t6`.`id` = `t5`.`id`) and (`t5`.`id` = `t4`.`id`) and (`t4`.`id` = `t3`.`id`) and (`t3`.`id` = `t2`.`id`) and (`t2`.`id` = `detail`.`id`) and (`master`.`id` = `detail`.`id`))" } } ] } }, ....中略.... }, "condition_filtering_pct": 100, "rows_for_plan": 10240, "cost_for_plan": 7163, "pruned_by_cost": true } MISSING_BYTES_BEYOND_MAX_MEM_SIZE: 2147483647 INSUFFICIENT_PRIVILEGES: 0 1 row in set (0.26 sec) mysql>

次に、考え過ぎているオプティマイザに、
JOIN_ORDERヒントを利用し、結合順を　考えるな！　感じろ！　作戦でオプティマイザに考えさせないように。。。パースも速いし、オプティマイザトレースのJSONのサイズも小さい!

mysql> \. test1.sql Database changed +----------------------------------------------------------------------------------------------------------------------+ | PLAIN | +----------------------------------------------------------------------------------------------------------------------+ | -> Nested loop inner join (cost=7163.00 rows=10240) -> Nested loop inner join (cost=3579.00 rows=5120) -> Nested loop inner join (cost=1787.00 rows=2560) -> Nested loop inner join (cost=891.00 rows=1280) -> Nested loop inner join (cost=443.00 rows=640) -> Nested loop inner join (cost=219.00 rows=320) -> Nested loop inner join (cost=107.00 rows=160) -> Nested loop inner join (cost=51.00 rows=80) -> Nested loop inner join (cost=23.00 rows=40) -> Nested loop inner join (cost=9.00 rows=20) -> Index scan on master using ix_master (cost=2.00 rows=10) -> Index lookup on detail using PRIMARY (id=`master`.id) (cost=0.52 rows=2) -> Index lookup on t2 using PRIMARY (id=`master`.id) (cost=0.51 rows=2) -> Index lookup on t3 using PRIMARY (id=`master`.id) (cost=0.51 rows=2) -> Index lookup on t4 using PRIMARY (id=`master`.id) (cost=0.50 rows=2) -> Index lookup on t5 using PRIMARY (id=`master`.id) (cost=0.50 rows=2) -> Index lookup on t6 using PRIMARY (id=`master`.id) (cost=0.50 rows=2) -> Index lookup on t7 using PRIMARY (id=`master`.id) (cost=0.50 rows=2) -> Index lookup on t8 using PRIMARY (id=`master`.id) (cost=0.50 rows=2) -> Index lookup on t9 using PRIMARY (id=`master`.id) (cost=0.50 rows=2) -> Index lookup on t10 using PRIMARY (id=`master`.id) (cost=0.50 rows=2) | +----------------------------------------------------------------------------------------------------------------------+ 1 row in set (0.00 sec)

オプティマイザトレース結果のJSONサイズは、

57379 bytes (切り捨てられたトレースのバイト数) + 100 bytes（optimizer_trace_max_mem_sizeパラメータに指定したサイズ） = 57,479 bytes 、約　56 KBとなりました。

2GB vs 56KB

オプティマイザトレースのJSONサイズからオプティマイザの仕事量を覗いてみるのも面白いですよね。（俺だけか喜んでるのw）

mysql> SELECT * FROM INFORMATION_SCHEMA.OPTIMIZER_TRACE\G *************************** 1. row *************************** QUERY: explain format=tree select /*+ JOIN_ORDER(master,detail,t2,t3,t4,t5,t6,t7,t8,t9,t10) */ * from master inner join detail on master.id = detail.id inner join detail t2 on t2.id = detail.id inner join detail t3 on t3.id = t2.id inner join detail t4 on t4.id = t3.id inner join detail t5 on t5.id = t4.id inner join detail t6 on t6.id = t5.id inner join detail t7 on t7.id = t6.id inner join detail t8 on t8.id = t7.id inner join detail t9 on t9.id = t8.id inner join detail t10 on t10.id = t9.id TRACE: MISSING_BYTES_BEYOND_MAX_MEM_SIZE: 57379 INSUFFICIENT_PRIVILEGES: 0 1 row in set (0.00 sec)

ということで、　MySQLのオプティマイザトレースはメモリー中に記録され、メモリーに記録できないトレースは切り捨てられる。
また、切り捨てられたサイズ＋オプティマイザトレース向けメモリーサイズからトレースを完全に取得するためのメモリーサイズを確認できる。
ただし、必要がメモリーの空き次第ではありそうですね。ということで、Oracle Databaseの 10053トレースとはちょっと違う注意点もあるな。

という知見を得た :)

Oracle Database の 10053トレースでのトレースによる考えている仕事量の見える化同様に、MySQLのオプティマイザトレースでも、オプティマイザが考えすぎていると様子をトレースサイズで見える化してみるという検証はここまで。
MySQLのオプティマイザトレースをなんとなく眺めて、なぜ、その判断をしたのだなどを追うのはまた別の機会に;)

10月も近いのに、muggy　な気候の続く、東京より。

ではまた。

関連エントリー
・悩ませ過ぎは及ばざるがごとし（MySQL 8.0.32編）
・悩ませ過ぎは及ばざるがごとし #7 - おまけ

・標準はあるにはあるが癖の多いSQL 全部俺　#1 Pagination
・標準はあるにはあるが癖の多いSQL 全部俺　#2 関数名は同じでも引数が逆の罠！
・標準はあるにはあるが癖の多いSQL 全部俺　#3 データ型確認したい時あるんです
・標準はあるにはあるが癖の多いSQL 全部俺　#4 リテラル値での除算の内部精度も違うのよ!
・標準はあるにはあるが癖の多いSQL 全部俺　#5 和暦変換機能ある方が少数派
・標準はあるにはあるが癖の多いSQL 全部俺　#6 時間厳守！
・標準はあるにはあるが癖の多いSQL 全部俺　#7 期間リテラル！
・標準はあるにはあるが癖の多いSQL 全部俺　#8 翌月末日って何日？
・標準はあるにはあるが癖の多いSQL 全部俺　#9 部分文字列の扱いでも癖が出る＞＜
・標準はあるにはあるが癖の多いSQL 全部俺　#10 文字列連結の罠（有名なやつ）
・標準はあるにはあるが癖の多いSQL 全部俺　#11 デュエル、じゃなくて、デュアル
・標準はあるにはあるが癖の多いSQL 全部俺　#12 文字[列]探すにも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#13 あると便利ですが意外となかったり
・標準はあるにはあるが癖の多いSQL 全部俺　#14 連番の集合を返すにも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#15 SQL command line client
・標準はあるにはあるが癖の多いSQL 全部俺　#16 SQLのレントゲンを撮る方法
・標準はあるにはあるが癖の多いSQL 全部俺　#17 その空白は許されないのか？
・標準はあるにはあるが癖の多いSQL 全部俺　#18 (+)の外部結合は方言
・標準はあるにはあるが癖の多いSQL 全部俺　#19 帰ってきた、部分文字列の扱いでも癖w
・標準はあるにはあるが癖の多いSQL 全部俺　#20 結果セットを単一列に連結するにも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#21 演算結果にも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#22 集合演算にも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#23 複数行INSERTにも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#24 乱数作るにも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#25 SQL de Fractalsにも癖がある:)
・標準はあるにはあるが癖の多いSQL 全部俺　おまけ SQL de 湯婆婆やるにも癖がでるw
・帰ってきた！標準はあるにはあるが癖の多いSQL #1 SQL de ROT13 やるにも癖が出るw
・帰ってきた！標準はあるにはあるが癖の多いSQL #2 Actual Plan取得中のキャンセルでも癖が出る
・帰ってきた！標準はあるにはあるが癖の多いSQL #3 オプティマイザの結合順評価テーブル数上限にも癖が出る

投稿日時 2023年9月23日 (土) 08時25分 Oracle, チューニング, FAQ, SQL, MySQL, PostgreSQL, パフォーマンス | 固定リンク | 0 | コメント (0)

2023年9月 7日 (木)

MySQL 8.0.32では NLJに使えるINDEXが存在していても、Hash Joinをヒントで強制することができる！（オプティマイザが選択することがある！）

Previously on Mac De Oracle
前回は悩ませ過ぎは及ばざるがごとし（MySQL 8.0.32編）で、パース時間が長い場合、ヒントを使うことでパース時間を短縮させることが可能なケースもあるというという話でした。Oracleでも同様のケースがあることもお話ししました。が、その中で、MySQL 8.0.32 ではオプティマイザが、NLJで利用するINDEXが存在していても、HJを選択することがあることに気づいた！（どうやら、該当表がバッファープールに乗っているとNLJを選択しやすくなる傾向もありそう）という、予告編までw

ということで、今日は、MySQL 8.0.32　では、NLJに利用するINDEXが存在していても、オプティマイザは、HJを選択することもあるし、ヒントによってHJを矯正できるのか？　ということを確認してみました。

これまでの、MySQL 8.0.x台のHash Joinの適用範囲および挙動は以下のブログで取り上げられています。（非常に参考になりました。ありがたいですね。本当に ;)

MySQL 8.0.18のHASH JOINを試した（tom__bo’s Blog）
https://tombo2.hatenablog.com/entry/2019/10/14/212100

MySQL 8.0.20 のハッシュジョイン（Hash Join）を INDEX があるテーブルで試してみる（Qiita @hmatsu47）
https://qiita.com/hmatsu47/items/e473a3e566b910d61f5b

MySQL 8.0.20 でHASH JOINが効くケースが拡大した (mita2 database life)
https://mita2db.hateblo.jp/entry/2020/05/03/174101

と、NLJ可能な索引があるとなぜか、HJにならなかった。ついでに、HASH_JOINというヒントは、8.0.18でしか効果がない！
https://dev.mysql.com/doc/refman/8.0/ja/optimizer-hints.html#optimizer-hints-table-level

MySQL 8.0 Manual
https://dev.mysql.com/doc/refman/8.0/en/hash-joins.html

"8.2.1.4 Hash Join Optimization By default, MySQL (8.0.18 and later) employs hash joins whenever possible. It is possible to control whether hash joins are employed using one of the BNL and NO_BNL optimizer hints, or by setting block_nested_loop=on or block_nested_loop=off as part of the setting for the optimizer_switch server system variable.
Note
MySQL 8.0.18 supported setting a hash_join flag in optimizer_switch, as well as the optimizer hints HASH_JOIN and NO_HASH_JOIN. In MySQL 8.0.19 and later, none of these have any effect any longer.

Beginning with MySQL 8.0.18, MySQL employs a hash join for any query for which each join has an equi-join condition, and in which there are no indexes that can be applied to any join conditions, such as this one:"

ななな、なーーーん、だってーーーーーーっ！。

だが、しかし、8.0.32 になるとマニュアルの記載では特に見かけなかったが、NLJに使える索引がある場合でも等価結合でHash Joinになるではありませんか。みなさん！

まじでーーーというか、実際、そうなるもん！

以下、前回のブログ参照のこと。
悩ませ過ぎは及ばざるがごとし（MySQL 8.0.32編） (Mac De Oracle)
https://discus-hamburg.cocolog-nifty.com/mac_de_oracle/2023/09/post-bee50f.html

ただし、 HASH_JOINヒントは使えないので、どのようにヒントを書けば Hash Joinを強制できるのだろう？　8.0.32編　ということで、試してみた！

結論から言ってしまうと

MySQL 8.0.32　では NLJに使えるINDEXが存在していても、Hash Joinを強制することができる！　（いつから変わったかは不明だが、8.0.32では可能！）
MySQL 8.0.32　では NLJに使えるINDEXが存在していても、Hash Joinを強制することができる！　（いつから変わったかは不明だが、8.0.32では可能！）

詳細は、以下の検証を。比較的気楽にヒントでHJを強制できるようです（だたしちょっと分かりずらいね。Oracleとかと比べると）

表定義等は前々回のエントリー参照のこと。帰ってきた！標準はあるにはあるが癖の多いSQL #3 オプティマイザの結合順評価テーブル数上限にも癖が出る

起動直後、バッファキャッシュが空だと（未検証）Hash Joinが選択されるので、まずは、オプティマイザが Hash Join (等価結合でNLJに利用できる索引が存在する状況でも）が選択されている（前回のブログのおさらい）

[master@localhost ~]$ sudo service mysqld restart Redirecting to /bin/systemctl restart mysqld.service [master@localhost ~]$ mysql -u scott -p Enter password: Welcome to the MySQL monitor. Commands end with ; or \g. Your MySQL connection id is 8 Server version: 8.0.32 Source distribution Copyright (c) 2000, 2023, Oracle and/or its affiliates. Oracle is a registered trademark of Oracle Corporation and/or its affiliates. Other names may be trademarks of their respective owners. Type 'help;' or '\h' for help. Type '\c' to clear the current input statement. mysql> select version(); +-----------+ | version() | +-----------+ | 8.0.32 | +-----------+ 1 row in set (0.00 sec) mysql> mysql> \. test1.sql Reading table information for completion of table and column names You can turn off this feature to get a quicker startup with -A Database changed +----------------------------------------------------------------------------------------------------------------------+ | EXPLAIN | +----------------------------------------------------------------------------------------------------------------------+ | -> Inner hash join (t10.id = `master`.id) (cost=20489.43 rows=10240) -> Table scan on t10 (cost=0.00 rows=20) -> Hash -> Inner hash join (t9.id = `master`.id) (cost=10238.74 rows=5120) -> Table scan on t9 (cost=0.00 rows=20) -> Hash -> Inner hash join (t8.id = `master`.id) (cost=5113.38 rows=2560) -> Table scan on t8 (cost=0.00 rows=20) -> Hash -> Inner hash join (t7.id = `master`.id) (cost=2550.45 rows=1280) -> Table scan on t7 (cost=0.00 rows=20) -> Hash -> Inner hash join (t6.id = `master`.id) (cost=1268.60 rows=640) -> Table scan on t6 (cost=0.00 rows=20) -> Hash -> Inner hash join (t5.id = `master`.id) (cost=627.24 rows=320) -> Table scan on t5 (cost=0.01 rows=20) -> Hash -> Inner hash join (t4.id = `master`.id) (cost=306.09 rows=160) -> Table scan on t4 (cost=0.02 rows=20) -> Hash -> Inner hash join (t3.id = `master`.id) (cost=145.03 rows=80) -> Table scan on t3 (cost=0.03 rows=20) -> Hash -> Inner hash join (t2.id = `master`.id) (cost=64.01 rows=40) -> Table scan on t2 (cost=0.06 rows=20) -> Hash -> Inner hash join (detail.id = `master`.id) (cost=23.00 rows=20) -> Table scan on detail (cost=0.12 rows=20) -> Hash -> Index scan on master using ix_master (cost=2.00 rows=10) | +----------------------------------------------------------------------------------------------------------------------+ 1 row in set (0.01 sec)

関連する表をアクセスしてバッファープールに乗った状態にすると。オプティマイザは、INDEXを利用したNLJを選択するようになった。（前回のブログのおさらい）

mysql> mysql> select * from master; +----+--------+ | id | dummya | +----+--------+ | 1 | 1 | | 10 | 10 | ....中略.... | 7 | 7 | | 8 | 8 | | 9 | 9 | +----+--------+ 10 rows in set (0.01 sec) mysql> select * from detail; +----+-------+--------+ | id | subid | dummya | +----+-------+--------+ | 1 | 1 | 11 | | 1 | 2 | 12 | | 2 | 1 | 21 | | 2 | 2 | 22 | ....中略.... | 9 | 1 | 91 | | 9 | 2 | 92 | | 10 | 1 | 101 | | 10 | 2 | 102 | +----+-------+--------+ 20 rows in set (0.01 sec) mysql> \. test1.sql Database changed +----------------------------------------------------------------------------------------------------------------------+ | EXPLAIN | +----------------------------------------------------------------------------------------------------------------------+ | -> Nested loop inner join (cost=7163.00 rows=10240) -> Nested loop inner join (cost=3579.00 rows=5120) -> Nested loop inner join (cost=1787.00 rows=2560) -> Nested loop inner join (cost=891.00 rows=1280) -> Nested loop inner join (cost=443.00 rows=640) -> Nested loop inner join (cost=219.00 rows=320) -> Nested loop inner join (cost=107.00 rows=160) -> Nested loop inner join (cost=51.00 rows=80) -> Nested loop inner join (cost=23.00 rows=40) -> Nested loop inner join (cost=9.00 rows=20) -> Index scan on master using ix_master (cost=2.00 rows=10) -> Index lookup on detail using PRIMARY (id=`master`.id) (cost=0.52 rows=2) -> Index lookup on t2 using PRIMARY (id=`master`.id) (cost=0.51 rows=2) -> Index lookup on t3 using PRIMARY (id=`master`.id) (cost=0.51 rows=2) -> Index lookup on t4 using PRIMARY (id=`master`.id) (cost=0.50 rows=2) -> Index lookup on t5 using PRIMARY (id=`master`.id) (cost=0.50 rows=2) -> Index lookup on t6 using PRIMARY (id=`master`.id) (cost=0.50 rows=2) -> Index lookup on t7 using PRIMARY (id=`master`.id) (cost=0.50 rows=2) -> Index lookup on t8 using PRIMARY (id=`master`.id) (cost=0.50 rows=2) -> Index lookup on t9 using PRIMARY (id=`master`.id) (cost=0.50 rows=2) -> Index lookup on t10 using PRIMARY (id=`master`.id) (cost=0.50 rows=2) | +----------------------------------------------------------------------------------------------------------------------+ 1 row in set (0.00 sec)

オプティマイザがNLJを選択するようになった状況で、Hash Join となるヒントを追加（ヒント等は後半のスクリプト test1_hj.sql　を参照のこと）すると、NLJで利用可能なINDEXが存在していたとしても、HJを強制できる。(8.0.20ごろまでは、HJは選択されなかったようなので、8.0.21から8.0.32の間でHJの適用範囲がさらに拡大されたのでしょうね。想像ですけども）

mysql> mysql> \. test1_hj.sql Database changed +----------------------------------------------------------------------------------------------------------------------+ | EXPLAIN | +----------------------------------------------------------------------------------------------------------------------+ | -> Inner hash join (t10.id = `master`.id) (cost=20468.86 rows=10240) -> Table scan on t10 (cost=0.00 rows=20) -> Hash -> Inner hash join (t9.id = `master`.id) (cost=10226.19 rows=5120) -> Table scan on t9 (cost=0.00 rows=20) -> Hash -> Inner hash join (t8.id = `master`.id) (cost=5104.85 rows=2560) -> Table scan on t8 (cost=0.00 rows=20) -> Hash -> Inner hash join (t7.id = `master`.id) (cost=2544.11 rows=1280) -> Table scan on t7 (cost=0.00 rows=20) -> Hash -> Inner hash join (t6.id = `master`.id) (cost=1263.65 rows=640) -> Table scan on t6 (cost=0.00 rows=20) -> Hash -> Inner hash join (t5.id = `master`.id) (cost=623.31 rows=320) -> Table scan on t5 (cost=0.00 rows=20) -> Hash -> Inner hash join (t4.id = `master`.id) (cost=303.02 rows=160) -> Table scan on t4 (cost=0.01 rows=20) -> Hash -> Inner hash join (t3.id = `master`.id) (cost=142.76 rows=80) -> Table scan on t3 (cost=0.01 rows=20) -> Hash -> Inner hash join (t2.id = `master`.id) (cost=62.50 rows=40) -> Table scan on t2 (cost=0.02 rows=20) -> Hash -> Inner hash join (detail.id = `master`.id) (cost=22.25 rows=20) -> Table scan on detail (cost=0.05 rows=20) -> Hash -> Table scan on master (cost=2.00 rows=10) | +----------------------------------------------------------------------------------------------------------------------+ 1 row in set (0.03 sec)

ついでなので、NLJになるようにがっつりヒントで固めてみた場合はどうなるか？　想定通り、NLJに倒せますね。（前回のブログのおさらい）

mysql> mysql> \. test1_nlj.sql Database changed +----------------------------------------------------------------------------------------------------------------------+ | EXPLAIN | +----------------------------------------------------------------------------------------------------------------------+ | -> Nested loop inner join (cost=7173.00 rows=10240) -> Nested loop inner join (cost=3589.00 rows=5120) -> Nested loop inner join (cost=1797.00 rows=2560) -> Nested loop inner join (cost=901.00 rows=1280) -> Nested loop inner join (cost=453.00 rows=640) -> Nested loop inner join (cost=229.00 rows=320) -> Nested loop inner join (cost=117.00 rows=160) -> Nested loop inner join (cost=61.00 rows=80) -> Nested loop inner join (cost=33.00 rows=40) -> Nested loop inner join (cost=19.00 rows=20) -> Index scan on master using ix_master (cost=12.00 rows=10) -> Index lookup on detail using PRIMARY (id=`master`.id) (cost=0.52 rows=2) -> Index lookup on t2 using PRIMARY (id=`master`.id) (cost=0.51 rows=2) -> Index lookup on t3 using PRIMARY (id=`master`.id) (cost=0.51 rows=2) -> Index lookup on t4 using PRIMARY (id=`master`.id) (cost=0.50 rows=2) -> Index lookup on t5 using PRIMARY (id=`master`.id) (cost=0.50 rows=2) -> Index lookup on t6 using PRIMARY (id=`master`.id) (cost=0.50 rows=2) -> Index lookup on t7 using PRIMARY (id=`master`.id) (cost=0.50 rows=2) -> Index lookup on t8 using PRIMARY (id=`master`.id) (cost=0.50 rows=2) -> Index lookup on t9 using PRIMARY (id=`master`.id) (cost=0.50 rows=2) -> Index lookup on t10 using PRIMARY (id=`master`.id) (cost=0.50 rows=2) | +----------------------------------------------------------------------------------------------------------------------+ 1 row in set (0.00 sec) mysql>

検証で利用した表と索引定義は前回のブログ参照のこと。

以下、今回検証で利用したスクリプト

オリジナル。結合順だけ JOIN_ORDERで制御。オプティマイザが、NLJ/HJをその時の気分で（嘘w）、その時の状況で判断して、NLJ/HJのいずれかを選択する（ことがわかっている 8.0.32　では）

[master@localhost ~]$ cat test1.sql use perftestdb; explain format=tree select /*+ JOIN_ORDER(master,detail,t2,t3,t4,t5,t6,t7,t8,t9,t10) */ * from master inner join detail on master.id = detail.id inner join detail t2 on t2.id = detail.id inner join detail t3 on t3.id = t2.id inner join detail t4 on t4.id = t3.id inner join detail t5 on t5.id = t4.id inner join detail t6 on t6.id = t5.id inner join detail t7 on t7.id = t6.id inner join detail t8 on t8.id = t7.id inner join detail t9 on t9.id = t8.id inner join detail t10 on t10.id = t9.id ;

JOIN_ORDER/NO_INDEX/NO_JOIN_INDEXヒントを利用して、結合順と索引スキャンの抑止、そして、NLJで利用する索引の利用を抑止することで　HJ　になるようにしたスクリプト

[master@localhost ~]$ cat test1_hj.sql use perftestdb; explain format=tree select /*+ JOIN_ORDER(master,detail,t2,t3,t4,t5,t6,t7,t8,t9,t10) NO_INDEX(master ix_master) NO_JOIN_INDEX(detail primary) NO_JOIN_INDEX(t2 primary) NO_JOIN_INDEX(t3 primary) NO_JOIN_INDEX(t4 primary) NO_JOIN_INDEX(t5 primary) NO_JOIN_INDEX(t6 primary) NO_JOIN_INDEX(t7 primary) NO_JOIN_INDEX(t8 primary) NO_JOIN_INDEX(t9 primary) NO_JOIN_INDEX(t10 primary) */ * from master inner join detail on master.id = detail.id inner join detail t2 on t2.id = detail.id inner join detail t3 on t3.id = t2.id inner join detail t4 on t4.id = t3.id inner join detail t5 on t5.id = t4.id inner join detail t6 on t6.id = t5.id inner join detail t7 on t7.id = t6.id inner join detail t8 on t8.id = t7.id inner join detail t9 on t9.id = t8.id inner join detail t10 on t10.id = t9.id ;

最後に、前回も利用した NLJ　に倒すためのガチガチヒントバージョンのスクリプト

[master@localhost ~]$ cat test1_nlj.sql use perftestdb; explain format=tree select /*+ JOIN_ORDER(master,detail,t2,t3,t4,t5,t6,t7,t8,t9,t10) INDEX(master ix_master) JOIN_INDEX(detail primary) JOIN_INDEX(t2 primary) JOIN_INDEX(t3 primary) JOIN_INDEX(t4 primary) JOIN_INDEX(t5 primary) JOIN_INDEX(t6 primary) JOIN_INDEX(t7 primary) JOIN_INDEX(t8 primary) JOIN_INDEX(t9 primary) JOIN_INDEX(t10 primary) */ * from master inner join detail on master.id = detail.id inner join detail t2 on t2.id = detail.id inner join detail t3 on t3.id = t2.id inner join detail t4 on t4.id = t3.id inner join detail t5 on t5.id = t4.id inner join detail t6 on t6.id = t5.id inner join detail t7 on t7.id = t6.id inner join detail t8 on t8.id = t7.id inner join detail t9 on t9.id = t8.id inner join detail t10 on t10.id = t9.id ;

ということで、まだまだまだ、蒸し暑いし、台風直撃しそうな、東京からお送りしました。台風に注意しつつ週末を過ごすしかなさそう。

では、また。

・悩ませ過ぎは及ばざるがごとし（MySQL 8.0.32編）

投稿日時 2023年9月 7日 (木) 17時10分チューニング, FAQ, SQL, MySQL, パフォーマンス | 固定リンク | 0 | コメント (0)

2023年9月 2日 (土)

帰ってきた！標準はあるにはあるが癖の多いSQL #3 オプティマイザの結合順評価テーブル数上限にも癖が出る

Previously on Mac De Oracle前回の癖はw
帰ってきた！標準はあるにはあるが癖の多いSQL #2 Actual Plan取得中のキャンセルでも癖が出る
でした。
実は、今日の癖は、その検証時に気づいた、MySQLで結合表数が多いと、パース時間長くなってね？　というか長いよね！　という点。

オプティマイザは、皆さんの難しい（いや、難しい必要はないですが）SQLを無駄なく、そのSQLに見合った最短の時間で結果を返そうと努力して実行計画を立てています。これを解析フェーズとかパース時間とか、ハードパース時間とかいくつかのバリエーションで表現していたりします。
今回は、中をとってw パース時間としますね。SQL文の実行計画を立てる、オプティマイザがあれやこれや考えて実行計画を立て終えるまでの時間のことです。

先日の検証で、10表結合したのですが、MySQLでは、20秒以上要していました。実行計画でオプティマイザ考えすぎて帰ってこない。SQL文の実行ではなく実行計画を立てるところで時間がかかるケースはいくつか有名なのがありますが。
そうならないように各データベースは閾値を設けています。今回は、結合順評価テーブル数上限　ってやつです。結合する表の順序の組み合わせをどこまで検討するかということなのですが、これが、票数が増えると鰻登りに増加します。
今回のケースだと、1011表なので、10!11!ですね。2表をを繰り返し結合していてもしっかり考えてくれちゃいます。

ただ、何も考えずにオプティマイザに時間を与えていると、パース時間だけでとんでもない時間になったり、性能要件に見合わないといったケースが出てきます。なので、適当なところで手を打って、オプティマイザに考えさせ過ぎないようしています。
その閾値のデフォルト値が、MySQLとOracle/PostgreSQLとでは結構違うみたい。というところが今回の癖！

ちなみに、Oracleの例ですが、結合以外にINリストに大量にリテラルがあり、かつ考慮する必要のある索引も多いケースでは、悩ませ過ぎは及ばざるがごとし #7 - おまけなんてことも起こりますw オプティマイザを悩ませすぎると大変なので、そんな時は、SQLヒントなどを使って、オプティマイザに考えさせないという治療で回避するのが特効薬ですw

余談はこれぐらいにして、本題へ。

Note:
(MySQL/PostgreSQL/Oracle 23c freeそれぞれ、同一Virtualbox VMを利用して検証しているため、CPUリソース等の差異はありません）

最初は、ネタの発端になったMySQL 8.0.32から

mysql> select version(); +-----------+ | version() | +-----------+ | 8.0.32 | +-----------+ 1 row in set (0.00 sec) mysql> show tables; +----------------------+ | Tables_in_perftestdb | +----------------------+ | detail | | master | +----------------------+ 2 rows in set (0.00 sec) mysql> desc detail; +--------+-------------+------+-----+---------+-------+ | Field | Type | Null | Key | Default | Extra | +--------+-------------+------+-----+---------+-------+ | id | int | NO | PRI | NULL | | | subid | int | NO | PRI | NULL | | | dummya | varchar(10) | YES | | NULL | | +--------+-------------+------+-----+---------+-------+ 3 rows in set (0.00 sec) mysql> show indexes from detail; +--------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+---------+------------+ | Table | Non_unique | Key_name | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment | Index_comment | Visible | Expression | +--------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+---------+------------+ | detail | 0 | PRIMARY | 1 | id | A | 10 | NULL | NULL | | BTREE | | | YES | NULL | | detail | 0 | PRIMARY | 2 | subid | A | 20 | NULL | NULL | | BTREE | | | YES | NULL | +--------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+---------+------------+ 2 rows in set (0.02 sec) mysql> desc master; +--------+-------------+------+-----+---------+-------+ | Field | Type | Null | Key | Default | Extra | +--------+-------------+------+-----+---------+-------+ | id | int | NO | PRI | NULL | | | dummya | varchar(10) | YES | MUL | NULL | | +--------+-------------+------+-----+---------+-------+ 2 rows in set (0.00 sec) mysql> show indexes from master; +--------+------------+-----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+---------+------------+ | Table | Non_unique | Key_name | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment | Index_comment | Visible | Expression | +--------+------------+-----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+---------+------------+ | master | 0 | PRIMARY | 1 | id | A | 10 | NULL | NULL | | BTREE | | | YES | NULL | | master | 1 | ix_master | 1 | dummya | A | 10 | NULL | NULL | YES | BTREE | | | YES | NULL | +--------+------------+-----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+---------+------------+ 2 rows in set (0.02 sec) mysql> analyze table master; +-------------------+---------+----------+----------+ | Table | Op | Msg_type | Msg_text | +-------------------+---------+----------+----------+ | perftestdb.master | analyze | status | OK | +-------------------+---------+----------+----------+ 1 row in set (0.04 sec) mysql> analyze table detail; +-------------------+---------+----------+----------+ | Table | Op | Msg_type | Msg_text | +-------------------+---------+----------+----------+ | perftestdb.detail | analyze | status | OK | +-------------------+---------+----------+----------+ 1 row in set (0.02 sec) mysql>

表定義とデータは以前のエントリーも参考に
MySQL 8.0.32 / explain analyze 実行途中でキャンセルできるみたいだけど、キャンセルしたら、Actual Plan、途中まで出るの？

では、

MySQL 8.0.32で、パースに時間を要するケースの再現。optimizer_search_depthパラメータはデフォルトのまま

MySQL : optimizer_search_depth optimizer_search_depth

mysql> show variables like 'optimizer_search_depth'; +------------------------+-------+ | Variable_name | Value | +------------------------+-------+ | optimizer_search_depth | 62 | +------------------------+-------+ 1 row in set (0.00 sec) mysql> \. test1.sql Database changed +----------------------------------------------------------------------------------------------------------------------+ | EXPLAIN | +----------------------------------------------------------------------------------------------------------------------+ | -> Nested loop inner join (cost=7162.25 rows=10240) -> Nested loop inner join (cost=3578.25 rows=5120) -> Nested loop inner join (cost=1786.25 rows=2560) -> Nested loop inner join (cost=890.25 rows=1280) -> Nested loop inner join (cost=442.25 rows=640) -> Nested loop inner join (cost=218.25 rows=320) -> Nested loop inner join (cost=106.25 rows=160) -> Nested loop inner join (cost=50.25 rows=80) -> Nested loop inner join (cost=22.25 rows=40) -> Nested loop inner join (cost=8.25 rows=20) -> Index scan on master using ix_master (cost=1.25 rows=10) -> Index lookup on detail using PRIMARY (id=`master`.id) (cost=0.52 rows=2) -> Index lookup on t2 using PRIMARY (id=`master`.id) (cost=0.51 rows=2) -> Index lookup on t3 using PRIMARY (id=`master`.id) (cost=0.51 rows=2) -> Index lookup on t4 using PRIMARY (id=`master`.id) (cost=0.50 rows=2) -> Index lookup on t5 using PRIMARY (id=`master`.id) (cost=0.50 rows=2) -> Index lookup on t6 using PRIMARY (id=`master`.id) (cost=0.50 rows=2) -> Index lookup on t7 using PRIMARY (id=`master`.id) (cost=0.50 rows=2) -> Index lookup on t8 using PRIMARY (id=`master`.id) (cost=0.50 rows=2) -> Index lookup on t9 using PRIMARY (id=`master`.id) (cost=0.50 rows=2) -> Index lookup on t10 using PRIMARY (id=`master`.id) (cost=0.50 rows=2) | +----------------------------------------------------------------------------------------------------------------------+ 1 row in set (21.37 sec)

パースに 21.37 sec 要していますね。 62!まで結合順を探査する設定ですから、このケースだと、10!まで行っているということなのでしょうね。

では、Oracleなどで設けられてる閾値と同等の　6　にせってしてみた場合のパース時間はどうでしょうね。このケースで実行計画を間違うことはない（単純なので）ですが、複雑な結合だと、実行計画をミスする率は多くなりそうですけども、Oracleとかだとその程度で使ってますし。。この程度でも良いのかもしれません。時間かかってもいいよというケースも当然あるので、非機能要件次第ではありますけどね。

mysql> set optimizer_search_depth = 6; Query OK, 0 rows affected (0.00 sec) mysql> show variables like 'optimizer_search_depth'; +------------------------+-------+ | Variable_name | Value | +------------------------+-------+ | optimizer_search_depth | 6 | +------------------------+-------+ 1 row in set (0.00 sec) mysql> \. test1.sql Database changed +----------------------------------------------------------------------------------------------------------------------+ | EXPLAIN | +----------------------------------------------------------------------------------------------------------------------+ | -> Nested loop inner join (cost=7162.25 rows=10240) -> Nested loop inner join (cost=3578.25 rows=5120) -> Nested loop inner join (cost=1786.25 rows=2560) -> Nested loop inner join (cost=890.25 rows=1280) -> Nested loop inner join (cost=442.25 rows=640) -> Nested loop inner join (cost=218.25 rows=320) -> Nested loop inner join (cost=106.25 rows=160) -> Nested loop inner join (cost=50.25 rows=80) -> Nested loop inner join (cost=22.25 rows=40) -> Nested loop inner join (cost=8.25 rows=20) -> Index scan on master using ix_master (cost=1.25 rows=10) -> Index lookup on detail using PRIMARY (id=`master`.id) (cost=0.52 rows=2) -> Index lookup on t2 using PRIMARY (id=`master`.id) (cost=0.51 rows=2) -> Index lookup on t3 using PRIMARY (id=`master`.id) (cost=0.51 rows=2) -> Index lookup on t4 using PRIMARY (id=`master`.id) (cost=0.50 rows=2) -> Index lookup on t5 using PRIMARY (id=`master`.id) (cost=0.50 rows=2) -> Index lookup on t6 using PRIMARY (id=`master`.id) (cost=0.50 rows=2) -> Index lookup on t7 using PRIMARY (id=`master`.id) (cost=0.50 rows=2) -> Index lookup on t8 using PRIMARY (id=`master`.id) (cost=0.50 rows=2) -> Index lookup on t9 using PRIMARY (id=`master`.id) (cost=0.50 rows=2) -> Index lookup on t10 using PRIMARY (id=`master`.id) (cost=0.50 rows=2) | +----------------------------------------------------------------------------------------------------------------------+ 1 row in set (0.27 sec)

はい！　パース時間は、一気短縮され、 0.27 sec　になりました。Oracleのハードパースでもこれぐらいなこんな程度だとは思います。

次に、PostgreSQLで確認してみましょ。 PostgreSQLの場合は、Oracleに近かったはず。表定義とデータ量は同じです。

PostgreSQLでは、結合順序評価上限は以下join_collapse_limitパラメータで制御するようですね。あまり気にしてなかったので脳のしわが一つ増えた！ defaultは、8　でOracleより多少、多いというところですね。
join_collapse_limit

perftestdb=> select version(); version -------------------------------------------------------------------------------------------------------- PostgreSQL 13.6 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 8.5.0 20210514 (Red Hat 8.5.0-4), 64-bit (1 行) perftestdb=> show join_collapse_limit; join_collapse_limit --------------------- 8 (1 行) perftestdb=> \d+ master テーブル"public.master" 列 | タイプ | 照合順序 | Null 値を許容 | デフォルト | ストレージ | 統計目標 | 説明 --------+-----------------------+----------+---------------+------------+------------+----------+------ id | integer | | not null | | plain | | dummya | character varying(10) | | | | extended | | インデックス: "master_pkey" PRIMARY KEY, btree (id) アクセスメソッド: heap perftestdb=> \d+ detail テーブル"public.detail" 列 | タイプ | 照合順序 | Null 値を許容 | デフォルト | ストレージ | 統計目標 | 説明 --------+-----------------------+----------+---------------+------------+------------+----------+------ id | integer | | not null | | plain | | subid | integer | | not null | | plain | | dummya | character varying(10) | | | | extended | | インデックス: "pk_detail" PRIMARY KEY, btree (id, subid) アクセスメソッド: heap perftestdb=> analyze verbose master; INFO: analyzing "public.master" INFO: "master": scanned 1 of 1 pages, containing 10 live rows and 0 dead rows; 10 rows in sample, 10 estimated total rows ANALYZE perftestdb=> analyze verbose detail; INFO: analyzing "public.detail" INFO: "detail": scanned 1 of 1 pages, containing 20 live rows and 0 dead rows; 20 rows in sample, 20 estimated total rows ANALYZE perftestdb=>

では試してみましょう。

perftestdb=> \timing on タイミングは on です。 perftestdb=> perftestdb=> perftestdb=> \i ./test1_pg.sql QUERY PLAN ----------------------------------------------------------------------------------------------- Hash Join (cost=19.53..156.40 rows=10240 width=116) Hash Cond: (master.id = t8.id) -> Hash Join (cost=12.93..31.40 rows=1280 width=83) Hash Cond: (master.id = detail.id) -> Hash Join (cost=6.33..10.00 rows=160 width=50) Hash Cond: (master.id = t4.id) -> Hash Join (cost=2.67..4.45 rows=40 width=28) Hash Cond: (master.id = t7.id) -> Hash Join (cost=1.23..2.50 rows=20 width=17) Hash Cond: (t6.id = master.id) -> Seq Scan on detail t6 (cost=0.00..1.20 rows=20 width=11) -> Hash (cost=1.10..1.10 rows=10 width=6) -> Seq Scan on master (cost=0.00..1.10 rows=10 width=6) -> Hash (cost=1.20..1.20 rows=20 width=11) -> Seq Scan on detail t7 (cost=0.00..1.20 rows=20 width=11) -> Hash (cost=3.15..3.15 rows=40 width=22) -> Hash Join (cost=1.45..3.15 rows=40 width=22) Hash Cond: (t4.id = t5.id) -> Seq Scan on detail t4 (cost=0.00..1.20 rows=20 width=11) -> Hash (cost=1.20..1.20 rows=20 width=11) -> Seq Scan on detail t5 (cost=0.00..1.20 rows=20 width=11) -> Hash (cost=5.60..5.60 rows=80 width=33) -> Hash Join (cost=2.90..5.60 rows=80 width=33) Hash Cond: (detail.id = t3.id) -> Hash Join (cost=1.45..3.15 rows=40 width=22) Hash Cond: (detail.id = t2.id) -> Seq Scan on detail (cost=0.00..1.20 rows=20 width=11) -> Hash (cost=1.20..1.20 rows=20 width=11) -> Seq Scan on detail t2 (cost=0.00..1.20 rows=20 width=11) -> Hash (cost=1.20..1.20 rows=20 width=11) -> Seq Scan on detail t3 (cost=0.00..1.20 rows=20 width=11) -> Hash (cost=5.60..5.60 rows=80 width=33) -> Hash Join (cost=2.90..5.60 rows=80 width=33) Hash Cond: (t8.id = t10.id) -> Hash Join (cost=1.45..3.15 rows=40 width=22) Hash Cond: (t8.id = t9.id) -> Seq Scan on detail t8 (cost=0.00..1.20 rows=20 width=11) -> Hash (cost=1.20..1.20 rows=20 width=11) -> Seq Scan on detail t9 (cost=0.00..1.20 rows=20 width=11) -> Hash (cost=1.20..1.20 rows=20 width=11) -> Seq Scan on detail t10 (cost=0.00..1.20 rows=20 width=11) (41 行) 時間: 29.117 ミリ秒 perftestdb=>

MySQLで上限を制限した時間と似たような時間でパースが行われていますね。ただ、HASH JOINが選択されていますがw この辺りも、MySQLの生い立ちと、PostgreSQL、そしてOracleの違いとして現れてきます。MySQL 8のHash Joinって、MySQL 8.0.20 でHASH JOINが効くケースが拡大したという元々、Block Nested Loopの置き換えとしての意味が強かったという生い立ちが影響しているようにも見えます。なので、等価結合のINNER JOIN（今回の例）の場合、MySQL 8.0.32でもNLJが選択されているということのようですね。似てるようで似てないRDBMSの世界。まだまだ、私も学びが必要ですね。ちょっと曲のあるMySQLのHash Joinの発動条件。。いずれPostgreSQLやOracleっぽくHash Joinをカジュアルに使えちゃう日が来るのだろうか。。。

最後に真打w Oracle Database

今回は、23c Freeで試します。ただし、前回のエントリーにあるように、23c freeでは、"_optimizer_max_permutations" = 300と少なく設定されています。
今回の確認では、正式リリースされれば、通常の 2000 になるだろう。という想定で、 2000 にしてハードパース時間を確認しておきます。

SCOTT@freepdb1> select banner from v$version; BANNER -------------------------------------------------------------------------------- Oracle Database 23c Free, Release 23.0.0.0.0 - Developer-Release

デフォルトの設定はいかですが、.sqlスクリプト内で、 _optimizer_max_permutations を 2000 に設定して実行します！

parameter name parameter value -------------------------------- ------------------------------ _optimizer_max_permutations 300 _optimizer_search_limit 5 SCOTT@freepdb1> desc master 名前 NULL? 型 ----------------------------------------- -------- ---------------------------- ID NOT NULL NUMBER DUMMYA VARCHAR2(10) SCOTT@freepdb1> desc detail 名前 NULL? 型 ----------------------------------------- -------- ---------------------------- ID NOT NULL NUMBER SUBID NOT NULL NUMBER DUMMYA VARCHAR2(10) SCOTT@freepdb1> select table_name,index_name,column_name from user_ind_columns where table_name in ('MASTER','DETAIL') order by table_name,index_name,column_position; TABLE_NAME INDEX_NAME COLUMN_NAME ------------------------------ ------------------------------ ------------------------------ DETAIL PK_DETAIL ID DETAIL PK_DETAIL SUBID MASTER SYS_C008265 ID SCOTT@freepdb1> exec dbms_stats.gather_table_stats(ownname=>'SCOTT',tabname=>'MASTER',cascade=>true,no_invalidate=>false); PL/SQLプロシージャが正常に完了しました。経過: 00:00:01.08 SCOTT@freepdb1> exec dbms_stats.gather_table_stats(ownname=>'SCOTT',tabname=>'DETAIL',cascade=>true,no_invalidate=>false); PL/SQLプロシージャが正常に完了しました。経過: 00:00:00.13

では、試してみましょう！

SCOTT@freepdb1> @test1_ora セッションが変更されました。経過: 00:00:00.01 NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ _optimizer_max_permutations integer 2000 1* alter system flush shared_pool システムが変更されました。経過: 00:00:00.68 解析されました。経過: 00:00:00.27

一般的なOracleの_optimizer_max_permutationsパラメータの設定で、 0.27 sec　となりました. こんなもんでしょうね。- this is an adaptive plan　となっているので、ACTUAL PLANを見ないと確定できないケースですが、多分
Hash joinが選ばれていることでしょうw(なので確認まではしませんが)

ついでなので、実行計画（見積もり）を見ておきましょう。　hash joinになってますね。一部、SORT MERGE JOINになってますが、

SCOTT@freepdb1> @?/rdbms/admin/utlxpls PLAN_TABLE_OUTPUT ----------------------------------------------------------------------------------------------------- Plan hash value: 3620033460 ----------------------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ----------------------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 10240 | 950K| 33 (4)| 00:00:01 | |* 1 | HASH JOIN | | 10240 | 950K| 33 (4)| 00:00:01 | | 2 | TABLE ACCESS FULL | DETAIL | 20 | 180 | 3 (0)| 00:00:01 | |* 3 | HASH JOIN | | 5120 | 430K| 30 (4)| 00:00:01 | | 4 | TABLE ACCESS FULL | DETAIL | 20 | 180 | 3 (0)| 00:00:01 | |* 5 | HASH JOIN | | 2560 | 192K| 27 (4)| 00:00:01 | | 6 | TABLE ACCESS FULL | DETAIL | 20 | 180 | 3 (0)| 00:00:01 | |* 7 | HASH JOIN | | 1280 | 87040 | 24 (5)| 00:00:01 | | 8 | TABLE ACCESS FULL | DETAIL | 20 | 180 | 3 (0)| 00:00:01 | |* 9 | HASH JOIN | | 640 | 37760 | 21 (5)| 00:00:01 | | 10 | TABLE ACCESS FULL | DETAIL | 20 | 180 | 3 (0)| 00:00:01 | |* 11 | HASH JOIN | | 320 | 16000 | 18 (6)| 00:00:01 | | 12 | TABLE ACCESS FULL | DETAIL | 20 | 180 | 3 (0)| 00:00:01 | |* 13 | HASH JOIN | | 160 | 6560 | 15 (7)| 00:00:01 | |* 14 | HASH JOIN | | 80 | 2560 | 12 (9)| 00:00:01 | |* 15 | HASH JOIN | | 40 | 920 | 9 (12)| 00:00:01 | | 16 | MERGE JOIN | | 20 | 280 | 6 (17)| 00:00:01 | | 17 | TABLE ACCESS BY INDEX ROWID| MASTER | 10 | 50 | 2 (0)| 00:00:01 | | 18 | INDEX FULL SCAN | SYS_C008265 | 10 | | 1 (0)| 00:00:01 | |* 19 | SORT JOIN | | 20 | 180 | 4 (25)| 00:00:01 | | 20 | TABLE ACCESS FULL | DETAIL | 20 | 180 | 3 (0)| 00:00:01 | | 21 | TABLE ACCESS FULL | DETAIL | 20 | 180 | 3 (0)| 00:00:01 | | 22 | TABLE ACCESS FULL | DETAIL | 20 | 180 | 3 (0)| 00:00:01 | | 23 | TABLE ACCESS FULL | DETAIL | 20 | 180 | 3 (0)| 00:00:01 | ----------------------------------------------------------------------------------------------------- Note ----- - this is an adaptive plan 174行が選択されました。経過: 00:00:00.71

MySQL/PostgreSQL/Oracleそれぞれ、ハードパースの結合順評価テーブル数上限にも癖というか違いがあって、かつ、それが、パース時間の差になってみたり。癖が多いですよね。それぞれの特徴というか。
ついでに、実行計画、MySQLのHash Joinの発動ケース。現状OracleやPostgreSQLのようには使えないので、その辺りは、認識しておいた方が良いですよね。癖として；）

8月末に東北に居たのですが、例年だと朝晩は涼しくて、過ごしやすいのに、今年は、ダメですね。東京と同じです。農作物への影響が気になりますね。寒暖の差が美味しさに影響するのもありますからね。。。

では、また。

次回は、OracleのSQLヒントネタでもしようかと思ってます。Oracleのヒントレポートが出力されるようになって、そこ気になる、なぜ。みたいな方も多かったり、それにより無用な議論があったりと聞いているのでw 一応書いておこうかなと。

MySQL/PostgreSQL/Oracleで利用したスクリプト（テーブル、索引定義およびデータ取得と統計取得コマンドは本文参照のこと）

MySQL

[master@localhost ~]$ cat test1.sql use perftestdb; explain select * from master inner join detail on master.id = detail.id inner join detail t2 on t2.id = detail.id inner join detail t3 on t3.id = t2.id inner join detail t4 on t4.id = t3.id inner join detail t5 on t5.id = t4.id inner join detail t6 on t6.id = t5.id inner join detail t7 on t7.id = t6.id inner join detail t8 on t8.id = t7.id inner join detail t9 on t9.id = t8.id inner join detail t10 on t10.id = t9.id ;

PostgreSQL

[master@localhost ~]$ cat test1_pg.sql explain select * from master inner join detail on master.id = detail.id inner join detail t2 on t2.id = detail.id inner join detail t3 on t3.id = t2.id inner join detail t4 on t4.id = t3.id inner join detail t5 on t5.id = t4.id inner join detail t6 on t6.id = t5.id inner join detail t7 on t7.id = t6.id inner join detail t8 on t8.id = t7.id inner join detail t9 on t9.id = t8.id inner join detail t10 on t10.id = t9.id ;

Oracle

[master@localhost ~]$ cat test1_ora.sql alter session set "_optimizer_max_permutations"=2000; show parameter "_optimizer_max_permutations" alter system flush shared_pool . l / explain plan for select * from master inner join detail on master.id = detail.id inner join detail t2 on t2.id = detail.id inner join detail t3 on t3.id = t2.id inner join detail t4 on t4.id = t3.id inner join detail t5 on t5.id = t4.id inner join detail t6 on t6.id = t5.id inner join detail t7 on t7.id = t6.id inner join detail t8 on t8.id = t7.id inner join detail t9 on t9.id = t8.id inner join detail t10 on t10.id = t9.id ;

関連エントリー
・Oracle Database 23c Free Developer Releaseの”_optimizer_max_permutations” parameterの設定値について

・標準はあるにはあるが癖の多いSQL 全部俺　#1 Pagination
・標準はあるにはあるが癖の多いSQL 全部俺　#2 関数名は同じでも引数が逆の罠！
・標準はあるにはあるが癖の多いSQL 全部俺　#3 データ型確認したい時あるんです
・標準はあるにはあるが癖の多いSQL 全部俺　#4 リテラル値での除算の内部精度も違うのよ!
・標準はあるにはあるが癖の多いSQL 全部俺　#5 和暦変換機能ある方が少数派
・標準はあるにはあるが癖の多いSQL 全部俺　#6 時間厳守！
・標準はあるにはあるが癖の多いSQL 全部俺　#7 期間リテラル！
・標準はあるにはあるが癖の多いSQL 全部俺　#8 翌月末日って何日？
・標準はあるにはあるが癖の多いSQL 全部俺　#9 部分文字列の扱いでも癖が出る＞＜
・標準はあるにはあるが癖の多いSQL 全部俺　#10 文字列連結の罠（有名なやつ）
・標準はあるにはあるが癖の多いSQL 全部俺　#11 デュエル、じゃなくて、デュアル
・標準はあるにはあるが癖の多いSQL 全部俺　#12 文字[列]探すにも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#13 あると便利ですが意外となかったり
・標準はあるにはあるが癖の多いSQL 全部俺　#14 連番の集合を返すにも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#15 SQL command line client
・標準はあるにはあるが癖の多いSQL 全部俺　#16 SQLのレントゲンを撮る方法
・標準はあるにはあるが癖の多いSQL 全部俺　#17 その空白は許されないのか？
・標準はあるにはあるが癖の多いSQL 全部俺　#18 (+)の外部結合は方言
・標準はあるにはあるが癖の多いSQL 全部俺　#19 帰ってきた、部分文字列の扱いでも癖w
・標準はあるにはあるが癖の多いSQL 全部俺　#20 結果セットを単一列に連結するにも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#21 演算結果にも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#22 集合演算にも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#23 複数行INSERTにも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#24 乱数作るにも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#25 SQL de Fractalsにも癖がある:)
・標準はあるにはあるが癖の多いSQL 全部俺　おまけ SQL de 湯婆婆やるにも癖がでるw
・帰ってきた！標準はあるにはあるが癖の多いSQL #1 SQL de ROT13 やるにも癖が出るw・帰ってきた！標準はあるにはあるが癖の多いSQL #2 Actual Plan取得中のキャンセルでも癖が出る

投稿日時 2023年9月 2日 (土) 12時59分 Oracle, チューニング, FAQ, SQL, MySQL, PostgreSQL, パフォーマンス | 固定リンク | 0 | コメント (0)

2023年9月 1日 (金)

Oracle Database 23c Free Developer Releaseの”_optimizer_max_permutations” parameterの設定値について

Previously on Mac De Oracle..
前回のお話は、帰ってきた！標準はあるにはあるが癖の多いSQL #2 Actual Plan取得中のキャンセルでも癖が出るでした。Oracle/PostgreSQL/MySQLそれぞれ、再帰問合せで試してみましたが、興味深い違いが出ました。思わず、PostgreSQLのソースコード読み始めてしまいましたwwww

ということで、本日は、その流れで気づいてOracle 23c Freeのひみつ！

たまたま気づいたのですけど、 Oracle Database 23c Free Developer Release で、
under scored parameterの　"_optimizer_max_permutations"　って、 300なんですね。随分少ない設定にされていました。

これ

5! (120) < 6! (720) ということを意味するので、6表以上の結合では、通常のOracleより実行計画をミスりやすいということを意味しています。
（なぜなのでしょう、Free Developer Releaseだからではないか？　というコメントももらいましたが、そうなのですかねぇ。でもそうかもしれないw。理由はなぜなのかわからんので何とも言えないですね）
なので、多数の結合を伴うSQLの検証には注意した方が良いですね。もしくは、通常の 2000　ぐらいまであげて試すとかしておいた方が良いかもね。
FreeのDeveloper Releaseだから 300　になっているのか確認できる資料は見つからなかったけど。

念の為、調べてみるとやはり、23c Free Developer Releaseのみ少なく設定されていました。

SYS@free> select banner from v$version; BANNER -------------------------------------------------------------------------------- Oracle Database 23c Free, Release 23.0.0.0.0 - Developer-Release parameter name parameter value -------------------------------- ------------------------------ _optimizer_max_permutations 300 _optimizer_search_limit 5

BANNER ---------------------------------------------------------------------- Oracle Database 21c Enterprise Edition Release 21.0.0.0.0 - Production parameter name parameter value ------------------------------ ------------------------------ _optimizer_max_permutations 2000 _optimizer_search_limit 5

BANNER -------------------------------------------------------------------------------- Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production parameter name parameter value ------------------------------ ------------------------------ optimizer_max_permutations 2000 _optimizer_search_limit 5

BANNER -------------------------------------------------------------------------------- Oracle Database 18c Enterprise Edition Release 18.0.0.0.0 - Production parameter name parameter value ------------------------------ ------------------------------ _optimizer_max_permutations 2000 _optimizer_search_limit 5

BANNER -------------------------------------------------------------------------------- Oracle Database 12c Enterprise Edition Release 12.2.0.1.0 - 64bit Production PL/SQL Release 12.2.0.1.0 - Production CORE 12.2.0.1.0 Production TNS for Linux: Version 12.2.0.1.0 - Production NLSRTL Version 12.2.0.1.0 - Production parameter name parameter value ------------------------------ ------------------------------ _optimizer_max_permutations 2000 _optimizer_search_limit 5

Oracle 23c の正式版がリリースされたら皆さんも、2000になっているか確認しましょうね！（多分、2000になっていると思うけどw）

東京の8月が毎日真夏日だったなんで、話題。来年は毎日、猛暑日じゃなければ良いのですけども。。。
残暑厳しい東京からお送りしました。

では、また。

投稿日時 2023年9月 1日 (金) 18時16分チューニング, FAQ, SQL, パフォーマンス, Oracle Database 12c Release 2, Oracle Database 18c, Oracle Database 19c, Oracle Database 21c, Oracle Database 23c Free Developer Release | 固定リンク | 0 | コメント (0)

2023年8月29日 (火)

帰ってきた！標準はあるにはあるが癖の多いSQL #2 Actual Plan取得中のキャンセルでも癖が出る

前々回のエントリーで、MySQL 8.0.32のActual Plan取得中にキャンセルしてもキャンセルされるまでのActual Planを取得できることを確認した。

では、OracleやPostgreSQLではどうなのだろう？（Oracleは皆さんご存知だと思いますが、確認の意味も含めて）

Oracle Database 21c と PostgreSQL 13.6 (私の環境の都合上w）で確認しておこうと思います。

Actual Plan欲しいけど、本番環境でしか試せないとか、実行に数時間以上要するような状況と大人の事情で、泣く泣くキャンセルしなければいけない。
でも、途中まででもいいからActual Plan返してくれたら、原因特定できる。。。かもしれないし。。。と思いますよね。

MySQL 8.0.32では、キャンセルしても途中まで取得できました。
（SQLパースフェーズの場合を除く。これはOracleでも、PostgreSQLでも同じでしょう。だって、実行前の解析フェーズでキャンセルされたらActual Planなんて返しようがないですからね）

では、Oracle Database 21cから見てみましょう！
(ご存知の方も多いと思いますので最初に答えを言っちゃうと、Oracleの場合、Actual Plan取得でも、SQLモニターの場合でもキャンセルしても途中までの結果を見ることができます！)

再帰問合せを利用した連番生成を行う方法で試してみます。

SYS@ORCLCDB> select banner_full from v$version; BANNER_FULL ------------------------------------------------------------------------------------------ Oracle Database 21c Enterprise Edition Release 21.0.0.0.0 - Production　Version 21.3.0.0.0

gather_plan_statisticsヒントを利用した、Actual Plan取得（キャンセルせず最後まで実行した例です）

SCOTT@freepdb1> @actual 1 WITH gen_nums(v) 2 AS 3 ( 4 SELECT /*+ gather_plan_statistics */ 1 5 FROM 6 dual 7 UNION ALL 8 SELECT v + 1 9 FROM 10 gen_nums 11 WHERE v + 1 <= 10000000 12 ) 13* SELECT v from gen_nums

SCOTT@freepdb1> @actual_plan 6n3sc0n82t9dq PLAN_TABLE_OUTPUT -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- SQL_ID 6n3sc0n82t9dq, child number 0 ------------------------------------- WITH gen_nums(v) AS ( SELECT /*+ gather_plan_statistics */ 1 FROM dual UNION ALL SELECT v + 1 FROM gen_nums WHERE v + 1 <= 10000000 ) SELECT v from gen_nums Plan hash value: 1492144221 -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | Id | Operation | Name | Starts | E-Rows |E-Bytes| Cost (%CPU)| E-Time | A-Rows | A-Time | Buffers | Writes | OMem | 1Mem | Used-Mem | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 1 | | | 4 (100)| | 10M|00:07:57.97 | 105M| 28831 | | | | | 1 | VIEW | | 1 | 2 | 26 | 4 (0)| 00:00:01 | 10M|00:07:57.97 | 105M| 28831 | | | | | 2 | UNION ALL (RECURSIVE WITH) BREADTH FIRST| | 1 | | | | | 10M|00:07:53.30 | 105M| 28831 | 2048 | 2048 | 97M (0)| | 3 | FAST DUAL | | 1 | 1 | | 2 (0)| 00:00:01 | 1 |00:00:00.01 | 0 | 0 | | | | | 4 | RECURSIVE WITH PUMP | | 10M| | | | | 9999K|00:00:16.81 | 0 | 0 | | | | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

同SQLを途中でキャンセルした例です。
A-Rows/A-Timeが途中まで実行されたことを示しています。

SCOTT@freepdb1> @actual 1 WITH gen_nums(v) 2 AS 3 ( 4 SELECT /*+ gather_plan_statistics */ 1 5 FROM 6 dual 7 UNION ALL 8 SELECT v + 1 9 FROM 10 gen_nums 11 WHERE v + 1 <= 10000000 12 ) 13* SELECT v from gen_nums ^CSCOTT@freepdb1>

SCOTT@freepdb1> @actual_plan 6n3sc0n82t9dq PLAN_TABLE_OUTPUT --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- SQL_ID 6n3sc0n82t9dq, child number 0 ------------------------------------- WITH gen_nums(v) AS ( SELECT /*+ gather_plan_statistics */ 1 FROM dual UNION ALL SELECT v + 1 FROM gen_nums WHERE v + 1 <= 10000000 ) SELECT v from gen_nums Plan hash value: 1492144221 -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | Id | Operation | Name | Starts | E-Rows |E-Bytes| Cost (%CPU)| E-Time | A-Rows | A-Time | Buffers | Writes | OMem | 1Mem | Used-Mem | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 1 | | | 4 (100)| | 7479K|00:06:29.48 | 76M| 21535 | | | | | 1 | VIEW | | 1 | 2 | 26 | 4 (0)| 00:00:01 | 7479K|00:06:29.48 | 76M| 21535 | | | | | 2 | UNION ALL (RECURSIVE WITH) BREADTH FIRST| | 1 | | | | | 7479K|00:06:25.85 | 76M| 21535 | 2048 | 2048 | 2048 (0)| | 3 | FAST DUAL | | 1 | 1 | | 2 (0)| 00:00:01 | 1 |00:00:00.01 | 0 | 0 | | | | | 4 | RECURSIVE WITH PUMP | | 7479K| | | | | 7479K|00:00:12.40 | 0 | 0 | | | | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

次に、SQL監視の例を見てみます。まず、キャンセルせず、最後まで実行した場合の例

Global Information ------------------------------ Status : DONE (ALL ROWS) Instance ID : 1 Session : SCOTT (379:17125) SQL ID : 8m5nwydj0rk2t ...中略... Global Stats ============================================================================ | Elapsed | Cpu | IO | Other | Fetch | Buffer | Write | Write | | Time(s) | Time(s) | Waits(s) | Waits(s) | Calls | Gets | Reqs | Bytes | ============================================================================ | 294 | 195 | 3.56 | 95 | 100K | 105M | 1126 | 225MB | ============================================================================ SQL Plan Monitoring Details (Plan Hash Value=1492144221) ============================================================================================================================================================================================ | Id | Operation | Name | Rows | Cost | Time | Start | Execs | Rows | Write | Write | Mem | Temp | Activity | Activity Detail | | | | | (Estim) | | Active(s) | Active | | (Actual) | Reqs | Bytes | (Max) | (Max) | (%) | (# samples) | ============================================================================================================================================================================================ | 0 | SELECT STATEMENT | | | | 411 | +0 | 1 | 10M | | | . | . | | | | 1 | VIEW | | 2 | 4 | 411 | +0 | 1 | 10M | | | . | . | | | | 2 | UNION ALL (RECURSIVE WITH) BREADTH FIRST | | | | 411 | +0 | 1 | 10M | 1126 | 225MB | 98MB | 226MB | 95.44 | Cpu (248) | | | | | | | | | | | | | | | | direct path write temp (3) | | 3 | FAST DUAL | | 1 | 2 | 1 | +0 | 1 | 1 | | | . | . | | | | 4 | RECURSIVE WITH PUMP | | | | 411 | +0 | 10M | 10M | | | . | . | 1.90 | Cpu (5) | ============================================================================================================================================================================================

次に途中でキャンセルした場合の例。 410sec要していたので、10sec後ぐらいにキャンセルしました。どちらの方法でもキャンセルした場合でも途中までのActual Planを取得できました。MySQLは、Actual Plan取得時のキャンセルの挙動をOracle Database側にあわせたのでしょうかね？

SQLモニターの場合、Global informationのStatusにも着目してください。全行取得できたのか、途中で止められたのか、エラーで途中終了したのかなどの情報も確認できます。

1 WITH gen_nums(v) 2 AS 3 ( 4 SELECT /*+ MONITOR */　1 5 FROM 6 dual 7 UNION ALL 8 SELECT v + 1 9 FROM 10 gen_nums 11 WHERE v + 1 <= 10000000 12 ) 13* SELECT v from gen_nums ^CSCOTT@orclpdb1>

Global Information ------------------------------ Status : DONE (FIRST N ROWS) Instance ID : 1 Session : SCOTT (379:17125) SQL ID : 8m5nwydj0rk2t ...中略... Global Stats ================================================= | Elapsed | Cpu | Other | Fetch | Buffer | | Time(s) | Time(s) | Waits(s) | Calls | Gets | ================================================= | 10 | 5.49 | 4.45 | 7216 | 2M | ================================================= SQL Plan Monitoring Details (Plan Hash Value=1492144221) ========================================================================================================================================================= | Id | Operation | Name | Rows | Cost | Time | Start | Execs | Rows | Mem | Activity | Activity Detail | | | | | (Estim) | | Active(s) | Active | | (Actual) | (Max) | (%) | (# samples) | ========================================================================================================================================================= | 0 | SELECT STATEMENT | | | | 19 | +0 | 1 | 722K | . | | | | 1 | VIEW | | 2 | 4 | 19 | +0 | 1 | 722K | . | | | | 2 | UNION ALL (RECURSIVE WITH) BREADTH FIRST | | | | 19 | +0 | 1 | 722K | 34MB | 83.33 | Cpu (5) | | 3 | FAST DUAL | | 1 | 2 | 1 | +0 | 1 | 1 | . | | | | 4 | RECURSIVE WITH PUMP | | | | 19 | +0 | 722K | 722K | . | | | =========================================================================================================================================================

次にPostgreSQL

perftestdb=> select version(); version -------------------------------------------------------------------------------------------------------- PostgreSQL 13.6 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 8.5.0 20210514 (Red Hat 8.5.0-4), 64-bit (1 行)

キャンセルせず、最後まで実行した例

perftestdb=> explain (analyze, buffers, verbose) perftestdb-> WITH RECURSIVE gen_nums(v) perftestdb-> AS perftestdb-> ( perftestdb(> SELECT 1 perftestdb(> UNION ALL perftestdb(> SELECT v + 1 perftestdb(> FROM perftestdb(> gen_nums perftestdb(> WHERE v + 1 <= 100000000 perftestdb(> ) perftestdb-> SELECT v from gen_nums; QUERY PLAN ----------------------------------------------------------------------------------------------------------------------------------------- CTE Scan on gen_nums (cost=3.21..3.83 rows=31 width=4) (actual time=0.007..98357.448 rows=100000000 loops=1) Output: gen_nums.v Buffers: temp written=170898 CTE gen_nums -> Recursive Union (cost=0.00..3.21 rows=31 width=4) (actual time=0.005..67023.784 rows=100000000 loops=1) -> Result (cost=0.00..0.01 rows=1 width=4) (actual time=0.002..0.002 rows=1 loops=1) Output: 1 -> WorkTable Scan on gen_nums gen_nums_1 (cost=0.00..0.26 rows=3 width=4) (actual time=0.000..0.000 rows=1 loops=100000000) Output: (gen_nums_1.v + 1) Filter: ((gen_nums_1.v + 1) <= 100000000) Rows Removed by Filter: 0 Planning Time: 0.090 ms Execution Time: 103968.625 ms (13 行)

キャンセルした例。
Planning Time: 0.090 ms なので、パースフェーズ中にキャンセルする方が難しいですね。103秒ほど要するので、60秒ぐらいでキャンセルしましたが、PostgreSQLの場合は、Actual Plan取得中のキャンセルでは何も出力されません。
XにPostしたところ、篠田さんから、本体側で対応しないと返せなようだ、とコメントをもらいコードを見始めたり() 機能として、あったら便利かもしれないですね。PostgreSQLでも。キャンセルしたところまでのActual Planを返してくれたら問題解決の糸口になることもあるだろうし。

perftestdb=> explain (analyze, buffers, verbose) WITH RECURSIVE gen_nums(v) AS ( SELECT 1 UNION ALL SELECT v + 1 FROM gen_nums WHERE v + 1 <= 100000000 ) SELECT v from gen_nums; ^Cキャンセル要求を送信しました ERROR: canceling statement due to user request perftestdb=>

温泉三昧と、いつも満席で諦めてた蕎麦屋のいくつかは食べ歩けた遅いお盆休みも終わり。もう9月が目の前ですね。

では、また。

・標準はあるにはあるが癖の多いSQL 全部俺　#1 Pagination
・標準はあるにはあるが癖の多いSQL 全部俺　#2 関数名は同じでも引数が逆の罠！
・標準はあるにはあるが癖の多いSQL 全部俺　#3 データ型確認したい時あるんです
・標準はあるにはあるが癖の多いSQL 全部俺　#4 リテラル値での除算の内部精度も違うのよ!
・標準はあるにはあるが癖の多いSQL 全部俺　#5 和暦変換機能ある方が少数派
・標準はあるにはあるが癖の多いSQL 全部俺　#6 時間厳守！
・標準はあるにはあるが癖の多いSQL 全部俺　#7 期間リテラル！
・標準はあるにはあるが癖の多いSQL 全部俺　#8 翌月末日って何日？
・標準はあるにはあるが癖の多いSQL 全部俺　#9 部分文字列の扱いでも癖が出る＞＜
・標準はあるにはあるが癖の多いSQL 全部俺　#10 文字列連結の罠（有名なやつ）
・標準はあるにはあるが癖の多いSQL 全部俺　#11 デュエル、じゃなくて、デュアル
・標準はあるにはあるが癖の多いSQL 全部俺　#12 文字[列]探すにも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#13 あると便利ですが意外となかったり
・標準はあるにはあるが癖の多いSQL 全部俺　#14 連番の集合を返すにも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#15 SQL command line client
・標準はあるにはあるが癖の多いSQL 全部俺　#16 SQLのレントゲンを撮る方法
・標準はあるにはあるが癖の多いSQL 全部俺　#17 その空白は許されないのか？
・標準はあるにはあるが癖の多いSQL 全部俺　#18 (+)の外部結合は方言
・標準はあるにはあるが癖の多いSQL 全部俺　#19 帰ってきた、部分文字列の扱いでも癖w
・標準はあるにはあるが癖の多いSQL 全部俺　#20 結果セットを単一列に連結するにも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#21 演算結果にも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#22 集合演算にも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#23 複数行INSERTにも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#24 乱数作るにも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#25 SQL de Fractalsにも癖がある:)
・標準はあるにはあるが癖の多いSQL 全部俺　おまけ SQL de 湯婆婆やるにも癖がでるw
・帰ってきた！標準はあるにはあるが癖の多いSQL #1 SQL de ROT13 やるにも癖が出るw

投稿日時 2023年8月29日 (火) 06時00分 Oracle, チューニング, FAQ, SQL, MySQL, PostgreSQL, パフォーマンス | 固定リンク | 0 | コメント (0)

2023年8月 7日 (月)

帰ってきた！標準はあるにはあるが癖の多いSQL #1 SQL de ROT13 やるにも癖が出るw

先日、Facebookの思い出なんぞを見返していたら、子供が小さい頃、ROT13で、謎の文字列を解かせる、コナンくん遊びをしてたことを思い出した。

ROT13

流石に小さい頃なので、難易度を下げるためROT13の文字対応表をヒントとして与えることにしようと思ったのですが、それだと逆に簡単になり過ぎると考え、文字列の順番を示す数字を、犯人からのメッセージとして、

謎の数字から犯人のメッセージを解け！。

みたいなことをやっていました。

意外と受けが良くて、複数の問題を解いて遊んで、問題を作る方が疲れるというわけわからん事態になってしまったことがありましたw

ということで、

本日の、帰ってきた！標準はあるにはあるが癖の多いSQL　は、 ROT13やるにも、Oracle/PostgreSQL/MySQLの癖が出ますよ！。というお話。

(実装は、SQL script file化してパラメータ渡し、渡せない癖のあるものは、代替方法にて渡すことにします。また、SQLだけで解決することにします）

前置きはこれぐらいにして、早速、間違いない、Oracleからw

ROT13 cipher実装するのにベタな感じで、PL/SQLになどに逃げる必要はないです。非常に強力な関数、 translate() 一発で解決できますよ。

SCOTT@freepdb1> select banner from v$version; BANNER -------------------------------------------------------------------------------- Oracle Database 23c Free, Release 23.0.0.0.0 - Developer-Release 経過: 00:00:00.02

文字列をrot13/derot13するSQL scriptファイルです。
Oracleの場合、単純です。translate()で対応する文字を返すようにするだけです。

SCOTT@freepdb1> !cat rot13.sql SELECT TRANSLATE ( '&1' ,'ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz' ,'NOPQRSTUVWXYZABCDEFGHIJKLMnopqrstuvwxyzabcdefghijklm' ) ; UNDEFINE 1

SCOTT@freepdb1> !cat derot13.sql SELECT TRANSLATE ( '&1' ,'NOPQRSTUVWXYZABCDEFGHIJKLMnopqrstuvwxyzabcdefghijklm' ,'ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz') ; UNDEFINE 1

では、実行！　うまく行った！
簡単でしょ！この手のSQL文でのお遊びは。

SCOTT@freepdb1> @rot13 'Mac De Oracle' TRANSLATE('MA ------------- Znp Qr Benpyr 経過: 00:00:00.00

SCOTT@freepdb1> @derot13 'Znp Qr Benpyr' TRANSLATE('ZN ------------- Mac De Oracle 経過: 00:00:00.01

つづいで、PostgreSQLです。

perftestdb=> select version(); version -------------------------------------------------------------------------------------------------------- PostgreSQL 13.6 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 8.5.0 20210514 (Red Hat 8.5.0-4), 64-bit (1 行)

実行！　

[postgres@localhost ~]$ psql -d perftestdb -U discus -p 5432 -W -h localhost -f /var/lib/pgsql/pg_rot13.sql -v str="'Mac De Oracle'" translate --------------- Znp Qr Benpyr (1 行)

[postgres@localhost ~]$ psql -d perftestdb -U discus -p 5432 -W -h localhost -f /var/lib/pgsql/pg_derot13.sql -v str="'Znp Qr Benpyr'" translate --------------- Mac De Oracle (1 行)

PostgreSQLの場合、translate()関数が実装されており、Oracleと同じように利用できました。SQL scriptファイル実行時のパラメータの渡し方に癖がある感じですかね。（なかなか、慣れないです。これ）

[postgres@localhost ~]$ cat pg_rot13.sql SELECT TRANSLATE ( :str ,'NOPQRSTUVWXYZABCDEFGHIJKLMnopqrstuvwxyzabcdefghijklm' ,'ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz') ;

[postgres@localhost ~]$ cat pg_derot13.sql SELECT TRANSLATE ( ':str' ,'ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz' ,'NOPQRSTUVWXYZABCDEFGHIJKLMnopqrstuvwxyzabcdefghijklm') ;

さて、最後は、MySQL 8.0.xを利用します。理由は使える構文が多くなったためですが。おそらくそれ以前のMySQLだと実装はかなり辛い。

mysql> select version(); +-----------+ | version() | +-----------+ | 8.0.32 | +-----------+ 1 row in set (0.00 sec)

理由は、見ての通り、再帰問合せを利用する必要があるためです。これ使えないとかなりキツイ。w
ついでに、translate()関数も存在しないため、バリバリ既存の関数を使ってシンプルに書いても多分これぐらいw

他に、もっといいやり方あるよーって方、ブログ書いて公開してほしいっす！
ちなみに、ググったら、こんなのをGitHubで見つけました。同じ方法じゃなくてよかったという感じではあります :)　俺オリジナルだ:)

こちらの方は、function化したようですね
https://github.com/samuelfaj/MySQL-rot13/blob/master/MySQL_rot13.sql

では、私が作ったSQL scriptファイルでパラメータをSETコマンドで渡す方法。苦心の跡が見えるかと思います。（これは無理だ、function化して逃げるかー。と一瞬過りましたが、閃いた方法がよかったという感じ）

mysql> \! cat mysql_rot13.sql WITH RECURSIVE rot13(v) AS ( SELECT 1 UNION ALL SELECT v + 1 FROM rot13 WHERE v + 1 <= CHAR_LENGTH(@str) ) SELECT GROUP_CONCAT( CASE WHEN INSTR( CAST('ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz' AS BINARY) , SUBSTR(@str, v, 1) ) = 0 THEN SUBSTR(@str, v, 1) ELSE SUBSTR( 'NOPQRSTUVWXYZABCDEFGHIJKLMnopqrstuvwxyzabcdefghijklm' , INSTR( CAST('ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyza' AS BINARY) , SUBSTR(@str, v, 1) ) , 1 ) END SEPARATOR '' ) AS rot13 FROM rot13 ;

mysql> \! cat mysql_derot13.sql WITH RECURSIVE derot13(v) AS ( SELECT 1 UNION ALL SELECT v + 1 FROM derot13 WHERE v + 1 <= CHAR_LENGTH(@str) ) SELECT GROUP_CONCAT( CASE WHEN INSTR( CAST('NOPQRSTUVWXYZABCDEFGHIJKLMnopqrstuvwxyzabcdefghijklm' AS BINARY) , SUBSTR(@str, v, 1) ) = 0 THEN SUBSTR(@str, v, 1) ELSE SUBSTR( 'ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz' , INSTR( CAST('NOPQRSTUVWXYZABCDEFGHIJKLMnopqrstuvwxyzabcdefghijklm' AS BINARY) , SUBSTR(@str, v, 1) ) , 1 ) END SEPARATOR '' ) AS derot13 FROM derot13 ;

では実行。

mysql> set @str='Mac De Oracle'; Query OK, 0 rows affected (0.01 sec) mysql> \. mysql_rot13.sql +---------------+ | rot13 | +---------------+ | Znp Qr Benpyr | +---------------+ 1 row in set (0.00 sec)

mysql> set @str='Znp Qr Benpyr'; Query OK, 0 rows affected (0.00 sec) mysql> \. mysql_derot13.sql +---------------+ | derot13 | +---------------+ | Mac De Oracle | +---------------+ 1 row in set (0.00 sec)

ということで、いろいろな、癖という鞭に打たれても、ニッコリ笑える。変態になれると良いですね :)

まだまだまだ、クソ暑い、東京からお送りしました。　ではまた。

・標準はあるにはあるが癖の多いSQL 全部俺　#1 Pagination
・標準はあるにはあるが癖の多いSQL 全部俺　#2 関数名は同じでも引数が逆の罠！
・標準はあるにはあるが癖の多いSQL 全部俺　#3 データ型確認したい時あるんです
・標準はあるにはあるが癖の多いSQL 全部俺　#4 リテラル値での除算の内部精度も違うのよ!
・標準はあるにはあるが癖の多いSQL 全部俺　#5 和暦変換機能ある方が少数派
・標準はあるにはあるが癖の多いSQL 全部俺　#6 時間厳守！
・標準はあるにはあるが癖の多いSQL 全部俺　#7 期間リテラル！
・標準はあるにはあるが癖の多いSQL 全部俺　#8 翌月末日って何日？
・標準はあるにはあるが癖の多いSQL 全部俺　#9 部分文字列の扱いでも癖が出る＞＜
・標準はあるにはあるが癖の多いSQL 全部俺　#10 文字列連結の罠（有名なやつ）
・標準はあるにはあるが癖の多いSQL 全部俺　#11 デュエル、じゃなくて、デュアル
・標準はあるにはあるが癖の多いSQL 全部俺　#12 文字[列]探すにも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#13 あると便利ですが意外となかったり
・標準はあるにはあるが癖の多いSQL 全部俺　#14 連番の集合を返すにも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#15 SQL command line client
・標準はあるにはあるが癖の多いSQL 全部俺　#16 SQLのレントゲンを撮る方法
・標準はあるにはあるが癖の多いSQL 全部俺　#17 その空白は許されないのか？
・標準はあるにはあるが癖の多いSQL 全部俺　#18 (+)の外部結合は方言
・標準はあるにはあるが癖の多いSQL 全部俺　#19 帰ってきた、部分文字列の扱いでも癖w
・標準はあるにはあるが癖の多いSQL 全部俺　#20 結果セットを単一列に連結するにも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#21 演算結果にも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#22 集合演算にも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#23 複数行INSERTにも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#24 乱数作るにも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#25 SQL de Fractalsにも癖がある:)
・標準はあるにはあるが癖の多いSQL 全部俺　おまけ SQL de 湯婆婆やるにも癖がでるw

投稿日時 2023年8月 7日 (月) 21時23分 Oracle, SQL, MySQL, PostgreSQL | 固定リンク | 0 | コメント (0)

2023年8月 4日 (金)

MySQL 8.0.32 / explain analyze 実行途中でキャンセルできるみたいだけど、キャンセルしたら、Actual Plan、途中まで出るの？

本年度一発目のw　Databaseネタは、なんと、MySQLネタからのスタートですw

MySQL 8.0.18以降、Actualプランが取得できるようになってた。
また、MySQL 8.0.20 以降、KILL QUERY または CTRL-C を使用してこのステートメントを終了できるとある。
ただ、マニュアルに記載されているのはここまでで、キャンセルできることは記載されているが、キャンセルした場合のActual Planはどこまで出力されるのだろう？　or 全く出力されない？

OracleのリアルタイムSQL監視だとキャンセルすると不完全ではあるけども、なんとなーく判断できる程度の情報は途中まで取得できるが、
GATHER_PLAN_STATISTICSヒントなどを使ったActualプランは最後まで実行しないとアcつあlはしゅとくできない。どちらのタイプに似ているのでしょうね？

長時間（数日とかw）かかってしまうようになったSQLのActualプラン取得するの意外と難しいケースも場合によってはあったりするわけで。。。そんなとき、Actualみたいけど、キャンセルしたらどうなるのだろうと。。
途中まででも取得できるのか、それとも、Nothingなのか。。。

MySQLのActualプランの取得はどうなんだろう。。。ということで、試してみた。

EXPLAIN ANALYZE による情報の取得
https://dev.mysql.com/doc/refman/8.0/ja/explain.html#explain-analyze

結論から書くと、
MySQL 8.0.32での検証だが、

explain analyzeで取得できるActual Planは、対応しているSQL文の実行中にCTRL-Cでキャンセルしても、その時点までの、Actual Planを表示してくれる!!!!!!

ただし、パース時間が異常に長めのSQL文(結合数めちゃ多いとか）だと、実行以前に、パース時間が長いため、パースフェーズでキャンセルしてしまうの何も表示されない。。と（最初はこちらを引いてしまったので、常に表示されないものかと思い込んでしまった）
他の方法で実行をキャンセルした場合も同じだろう。とは思う。

いや、他にも出力されないケースがあるとか、その検証方法だから出力されているだけどか、MySQLのexplain analyzeのディープなツッコミがありましたら、よろしくお願いします。:)

MySQLの8.0台ってマイナー番号変わっても機能追加されたり変化しているので、一応。 MySQL 8.0.32 上では。ということにしておく。

以下、検証の記録的なもの。

確認に使用した　MySQLのバージョン

[master@localhost ~]$ mysql -u scott -p Enter password: Welcome to the MySQL monitor. Commands end with ; or \g. Your MySQL connection id is 8 Server version: 8.0.32 Source distribution Copyright (c) 2000, 2023, Oracle and/or its affiliates. Oracle is a registered trademark of Oracle Corporation and/or its affiliates. Other names may be trademarks of their respective owners. Type 'help;' or '\h' for help. Type '\c' to clear the current input statement. mysql> select version(); +-----------+ | version() | +-----------+ | 8.0.32 | +-----------+ 1 row in set (0.00 sec)

事前に準備したクエリ向け表と索引など

Database changed mysql> use perftestdb Reading table information for completion of table and column names You can turn off this feature to get a quicker startup with -A Database changed mysql> mysql> desc master; +--------+-------------+------+-----+---------+-------+ | Field | Type | Null | Key | Default | Extra | +--------+-------------+------+-----+---------+-------+ | id | int | NO | PRI | NULL | | | dummya | varchar(10) | YES | | NULL | | +--------+-------------+------+-----+---------+-------+ 2 rows in set (0.01 sec) mysql> desc detail; +--------+-------------+------+-----+---------+-------+ | Field | Type | Null | Key | Default | Extra | +--------+-------------+------+-----+---------+-------+ | id | int | NO | PRI | NULL | | | subid | int | NO | PRI | NULL | | | dummya | varchar(10) | YES | | NULL | | +--------+-------------+------+-----+---------+-------+ 3 rows in set (0.00 sec) mysql> show indexes from master; +--------+------------+----------+--------------+-------------+------------+ | Table | Non_unique | Key_name | Seq_in_index | Column_name | Index_type | +--------+------------+----------+--------------+-------------+------------+ | master | 0 | PRIMARY | 1 | id | BTREE | +--------+------------+----------+--------------+-------------+------------+ 1 row in set (0.02 sec) mysql> show indexes from detail; +--------+------------+----------+--------------+-------------+------------+ | Table | Non_unique | Key_name | Seq_in_index | Column_name | Index_type | +--------+------------+----------+--------------+-------------+------------+ | detail | 0 | PRIMARY | 1 | id | BTREE | | detail | 0 | PRIMARY | 2 | subid | BTREE | +--------+------------+----------+--------------+-------------+------------+ 2 rows in set (0.02 sec) mysql> select * from master; +----+--------+ | id | dummya | +----+--------+ | 1 | 1 | | 2 | 2 | | 3 | 3 | | 4 | 4 | | 5 | 5 | | 6 | 6 | | 7 | 7 | | 8 | 8 | | 9 | 9 | | 10 | 10 | +----+--------+ 10 rows in set (0.01 sec) mysql> select * from detail; +----+-------+--------+ | id | subid | dummya | +----+-------+--------+ | 1 | 1 | 11 | | 1 | 2 | 12 | | 2 | 1 | 21 | | 2 | 2 | 22 | | 3 | 1 | 31 | ...略... | 7 | 1 | 71 | | 7 | 2 | 72 | | 8 | 1 | 81 | | 8 | 2 | 82 | | 9 | 1 | 91 | | 9 | 2 | 92 | | 10 | 1 | 101 | | 10 | 2 | 102 | +----+-------+--------+ 20 rows in set (0.01 sec)

検証用に作ったSQL。どのぐらいのElapsed Timeかanaluyzeをつけて実行して、キャンセルしやすい程度のElapsed Timeか確認しておきます。

mysql> explain analyze -> select * -> from -> master inner join detail -> on master.id = detail.id -> inner join detail t2 -> on -> t2.id = detail.id -> inner join detail t3 -> on -> t3.id = t2.id -> inner join detail t4 -> on -> t4.id = t3.id -> inner join detail t5 -> on -> t5.id = t4.id -> inner join detail t6 -> on -> t6.id = t5.id -> inner join detail t7 -> on -> t7.id = t6.id -> inner join detail t8 -> on -> t8.id = t7.id -> inner join detail t9 -> on -> t9.id = t8.id -> inner join detail t10 -> on -> t10.id = t9.id -> ; +------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | EXPLAIN | +------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | -> Nested loop inner join (cost=5729.85 rows=8192) (actual time=0.115..37.938 rows=10240 loops=1) -> Nested loop inner join (cost=2862.65 rows=4096) (actual time=0.108..18.747 rows=5120 loops=1) -> Nested loop inner join (cost=1429.05 rows=2048) (actual time=0.102..9.267 rows=2560 loops=1) -> Nested loop inner join (cost=712.25 rows=1024) (actual time=0.097..4.689 rows=1280 loops=1) -> Nested loop inner join (cost=353.85 rows=512) (actual time=0.091..2.336 rows=640 loops=1) -> Nested loop inner join (cost=174.65 rows=256) (actual time=0.086..1.203 rows=320 loops=1) -> Nested loop inner join (cost=85.05 rows=128) (actual time=0.080..0.630 rows=160 loops=1) -> Nested loop inner join (cost=40.25 rows=64) (actual time=0.075..0.337 rows=80 loops=1) -> Nested loop inner join (cost=17.85 rows=32) (actual time=0.069..0.189 rows=40 loops=1) -> Nested loop inner join (cost=6.65 rows=16) (actual time=0.063..0.110 rows=20 loops=1) -> Table scan on master (cost=1.05 rows=8) (actual time=0.041..0.047 rows=10 loops=1) -> Index lookup on detail using PRIMARY (id=`master`.id) (cost=0.53 rows=2) (actual time=0.005..0.006 rows=2 loops=10) -> Index lookup on t2 using PRIMARY (id=`master`.id) (cost=0.51 rows=2) (actual time=0.003..0.004 rows=2 loops=20) -> Index lookup on t3 using PRIMARY (id=`master`.id) (cost=0.51 rows=2) (actual time=0.002..0.003 rows=2 loops=40) -> Index lookup on t4 using PRIMARY (id=`master`.id) (cost=0.50 rows=2) (actual time=0.002..0.003 rows=2 loops=80) -> Index lookup on t5 using PRIMARY (id=`master`.id) (cost=0.50 rows=2) (actual time=0.002..0.003 rows=2 loops=160) -> Index lookup on t6 using PRIMARY (id=`master`.id) (cost=0.50 rows=2) (actual time=0.002..0.003 rows=2 loops=320) -> Index lookup on t7 using PRIMARY (id=`master`.id) (cost=0.50 rows=2) (actual time=0.002..0.003 rows=2 loops=640) -> Index lookup on t8 using PRIMARY (id=`master`.id) (cost=0.50 rows=2) (actual time=0.002..0.003 rows=2 loops=1280) -> Index lookup on t9 using PRIMARY (id=`master`.id) (cost=0.50 rows=2) (actual time=0.002..0.003 rows=2 loops=2560) -> Index lookup on t10 using PRIMARY (id=`master`.id) (cost=0.50 rows=2) (actual time=0.002..0.003 rows=2 loops=5120) | +------------------------------------------------------------------------------------------------------------------------------------------------------------------+ 1 row in set (21.18 sec)

では、explain analyseを途中でキャンセルしてみます。elapsed timeが21秒ほどなので、20秒後にキャンセルしてみます。

mysql> explain analyze select * from master inner join detail on master.id = detail.id inner join detail t2 on t2.id = master.id inner join detail t3 on t3.id = master.id inner join detail t4 on t4.id = master.id inner join detail t5 on t5.id = master.id inner join detail t6 on t6.id = master.id inner join detail t7 on t7.id = master.id inner join detail t8 on t8.id = master.id inner join detail t9 on t9.id = master.id inner join detail t10 on t10.id = master.id ; ^C^C -- query aborted ERROR 1317 (70100): Query execution was interrupted mysql>

！　やはり、実行途中のキャンセルだとActual Planは何も出力されないみたい。。。。

？？ん？　いや、なんか違うな。これw！

SQL文の実行時間はたいしたことない。人間がこの時間内にピンポイントでキャンセルするには短すぎるよね。
SQL文の実行時間は、約38ミリ秒！！！　こっちだw 最終に表示されている21秒には、SQLのパース時間も含まれているはず。。。。見逃した。俺としたことが。。。

| -> Nested loop inner join (cost=5729.85 rows=8192) (actual time=0.115..37.938 rows=10240 loops=1)

キャンセルしたのは、SQL実行後、おおよそ、20秒後。SQLのActualタイムを見ると38ミリ秒なので、ギリギリ、パース時間中に被ってそう。

1 row in set (21.00 sec)

だとしたら、まず、そこから確認。パースにどの程度要しているか、explainだけにすれば、良さそうだよね。Oracle Databaseでもそうだし。(PostgreSQLはパース時間も表示してくれたりするけども。あれ意外に便利なんだよ）

mysql> explain format=tree -> select * -> from -> master inner join detail -> on master.id = detail.id -> inner join detail t2 -> on -> t2.id = detail.id -> inner join detail t3 -> on -> t3.id = t2.id -> inner join detail t4 -> on -> t4.id = t3.id -> inner join detail t5 -> on -> t5.id = t4.id -> inner join detail t6 -> on -> t6.id = t5.id -> inner join detail t7 -> on -> t7.id = t6.id -> inner join detail t8 -> on -> t8.id = t7.id -> inner join detail t9 -> on -> t9.id = t8.id -> inner join detail t10 -> on -> t10.id = t9.id -> ; +------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | EXPLAIN | +------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | -> Nested loop inner join (cost=5729.85 rows=8192) -> Nested loop inner join (cost=2862.65 rows=4096) -> Nested loop inner join (cost=1429.05 rows=2048) -> Nested loop inner join (cost=712.25 rows=1024) -> Nested loop inner join (cost=353.85 rows=512) -> Nested loop inner join (cost=174.65 rows=256) -> Nested loop inner join (cost=85.05 rows=128) -> Nested loop inner join (cost=40.25 rows=64) -> Nested loop inner join (cost=17.85 rows=32) -> Nested loop inner join (cost=6.65 rows=16) -> Table scan on master (cost=1.05 rows=8) -> Index lookup on detail using PRIMARY (id=`master`.id) (cost=0.53 rows=2) -> Index lookup on t2 using PRIMARY (id=`master`.id) (cost=0.51 rows=2) -> Index lookup on t3 using PRIMARY (id=`master`.id) (cost=0.51 rows=2) -> Index lookup on t4 using PRIMARY (id=`master`.id) (cost=0.50 rows=2) -> Index lookup on t5 using PRIMARY (id=`master`.id) (cost=0.50 rows=2) -> Index lookup on t6 using PRIMARY (id=`master`.id) (cost=0.50 rows=2) -> Index lookup on t7 using PRIMARY (id=`master`.id) (cost=0.50 rows=2) -> Index lookup on t8 using PRIMARY (id=`master`.id) (cost=0.50 rows=2) -> Index lookup on t9 using PRIMARY (id=`master`.id) (cost=0.50 rows=2) -> Index lookup on t10 using PRIMARY (id=`master`.id) (cost=0.50 rows=2) | +------------------------------------------------------------------------------------------------------------------------------------------------------------------+ 1 row in set (21.84 sec)

お！　予想通り、explainでパースだけさせたら、explain analyze（SQL文の実行を含む）とほぼ同じ 21秒台。想定は正しそう。

だとすると、今回確認したいことを実現するには、..... SQLの実行時間をもっと長くして、人がw キャンセルしやすい程度に実行時間を間延びさせておく必要がある。。
とはいえ、大量のデータを用意する時間もVMのストレージもないと。。。

さて、どうするか。。。。

***** ここで、　一休さん、考え中。。。木魚の音。ポク、ポク、ポク。。。。w *****

***** ここで、　一休さん、閃いた。。。鐘の音、チーーーーーん *****
　
sleep()関数を使って、眠らせると時間稼ぎできるのでは？　　やってみよう！
おおおおお、いい感じだ。

mysql> explain analyze -> select *, sleep(0.01) -> from -> master inner join detail -> on master.id = detail.id -> inner join detail t2 -> on -> t2.id = detail.id -> inner join detail t3 -> on -> t3.id = t2.id -> inner join detail t4 -> on -> t4.id = t3.id -> inner join detail t5 -> on -> t5.id = t4.id -> inner join detail t6 -> on -> t6.id = t5.id -> inner join detail t7 -> on -> t7.id = t6.id -> inner join detail t8 -> on -> t8.id = t7.id -> inner join detail t9 -> on -> t9.id = t8.id -> inner join detail t10 -> on -> t10.id = t9.id -> ; +------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | EXPLAIN | +------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | -> Nested loop inner join (cost=5729.85 rows=8192) (actual time=0.170..232.399 rows=10240 loops=1) -> Nested loop inner join (cost=2862.65 rows=4096) (actual time=0.164..75.457 rows=5120 loops=1) -> Nested loop inner join (cost=1429.05 rows=2048) (actual time=0.159..37.659 rows=2560 loops=1) -> Nested loop inner join (cost=712.25 rows=1024) (actual time=0.154..17.709 rows=1280 loops=1) -> Nested loop inner join (cost=353.85 rows=512) (actual time=0.149..9.612 rows=640 loops=1) -> Nested loop inner join (cost=174.65 rows=256) (actual time=0.143..4.658 rows=320 loops=1) -> Nested loop inner join (cost=85.05 rows=128) (actual time=0.138..2.285 rows=160 loops=1) -> Nested loop inner join (cost=40.25 rows=64) (actual time=0.132..1.174 rows=80 loops=1) -> Nested loop inner join (cost=17.85 rows=32) (actual time=0.126..0.625 rows=40 loops=1) -> Nested loop inner join (cost=6.65 rows=16) (actual time=0.120..0.347 rows=20 loops=1) -> Table scan on master (cost=1.05 rows=8) (actual time=0.097..0.122 rows=10 loops=1) -> Index lookup on detail using PRIMARY (id=`master`.id) (cost=0.53 rows=2) (actual time=0.017..0.021 rows=2 loops=10) -> Index lookup on t2 using PRIMARY (id=`master`.id) (cost=0.51 rows=2) (actual time=0.010..0.013 rows=2 loops=20) -> Index lookup on t3 using PRIMARY (id=`master`.id) (cost=0.51 rows=2) (actual time=0.010..0.013 rows=2 loops=40) -> Index lookup on t4 using PRIMARY (id=`master`.id) (cost=0.50 rows=2) (actual time=0.010..0.013 rows=2 loops=80) -> Index lookup on t5 using PRIMARY (id=`master`.id) (cost=0.50 rows=2) (actual time=0.010..0.014 rows=2 loops=160) -> Index lookup on t6 using PRIMARY (id=`master`.id) (cost=0.50 rows=2) (actual time=0.011..0.015 rows=2 loops=320) -> Index lookup on t7 using PRIMARY (id=`master`.id) (cost=0.50 rows=2) (actual time=0.009..0.012 rows=2 loops=640) -> Index lookup on t8 using PRIMARY (id=`master`.id) (cost=0.50 rows=2) (actual time=0.011..0.015 rows=2 loops=1280) -> Index lookup on t9 using PRIMARY (id=`master`.id) (cost=0.50 rows=2) (actual time=0.010..0.014 rows=2 loops=2560) -> Index lookup on t10 using PRIMARY (id=`master`.id) (cost=0.50 rows=2) (actual time=0.010..0.028 rows=2 loops=5120) | +------------------------------------------------------------------------------------------------------------------------------------------------------------------+ 1 row in set (2 min 47.64 sec)

Elapsed Timeがパース時間より長くなったので、できそう。　60秒後にキャンセルすれば余裕はありそう。

1 row in set (2 min 47.64 sec)

explain analyzeを実行して、60秒後にキャンセルした！

mysql> explain analyze -> select *, sleep(0.01) -> from -> master inner join detail -> on master.id = detail.id -> inner join detail t2 -> on -> t2.id = detail.id -> inner join detail t3 -> on -> t3.id = t2.id -> inner join detail t4 -> on -> t4.id = t3.id -> inner join detail t5 -> on -> t5.id = t4.id -> inner join detail t6 -> on -> t6.id = t5.id -> inner join detail t7 -> on -> t7.id = t6.id -> inner join detail t8 -> on -> t8.id = t7.id -> inner join detail t9 -> on -> t9.id = t8.id -> inner join detail t10 -> on -> t10.id = t9.id -> ; ^C^C -- query aborted +------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | EXPLAIN | +------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | -> Nested loop inner join (cost=5729.85 rows=8192) (actual time=0.113..92.382 rows=2639 loops=1) -> Nested loop inner join (cost=2862.65 rows=4096) (actual time=0.106..29.480 rows=1320 loops=1) -> Nested loop inner join (cost=1429.05 rows=2048) (actual time=0.101..14.323 rows=660 loops=1) -> Nested loop inner join (cost=712.25 rows=1024) (actual time=0.096..7.161 rows=330 loops=1) -> Nested loop inner join (cost=353.85 rows=512) (actual time=0.090..3.507 rows=165 loops=1) -> Nested loop inner join (cost=174.65 rows=256) (actual time=0.085..1.624 rows=83 loops=1) -> Nested loop inner join (cost=85.05 rows=128) (actual time=0.079..0.867 rows=42 loops=1) -> Nested loop inner join (cost=40.25 rows=64) (actual time=0.073..0.352 rows=21 loops=1) -> Nested loop inner join (cost=17.85 rows=32) (actual time=0.068..0.210 rows=11 loops=1) -> Nested loop inner join (cost=6.65 rows=16) (actual time=0.062..0.122 rows=6 loops=1) -> Table scan on master (cost=1.05 rows=8) (actual time=0.040..0.044 rows=3 loops=1) -> Index lookup on detail using PRIMARY (id=`master`.id) (cost=0.53 rows=2) (actual time=0.021..0.024 rows=2 loops=3) -> Index lookup on t2 using PRIMARY (id=`master`.id) (cost=0.51 rows=2) (actual time=0.011..0.014 rows=2 loops=6) -> Index lookup on t3 using PRIMARY (id=`master`.id) (cost=0.51 rows=2) (actual time=0.009..0.012 rows=2 loops=11) -> Index lookup on t4 using PRIMARY (id=`master`.id) (cost=0.50 rows=2) (actual time=0.020..0.024 rows=2 loops=21) -> Index lookup on t5 using PRIMARY (id=`master`.id) (cost=0.50 rows=2) (actual time=0.014..0.017 rows=2 loops=42) -> Index lookup on t6 using PRIMARY (id=`master`.id) (cost=0.50 rows=2) (actual time=0.015..0.022 rows=2 loops=83) -> Index lookup on t7 using PRIMARY (id=`master`.id) (cost=0.50 rows=2) (actual time=0.014..0.021 rows=2 loops=165) -> Index lookup on t8 using PRIMARY (id=`master`.id) (cost=0.50 rows=2) (actual time=0.016..0.021 rows=2 loops=330) -> Index lookup on t9 using PRIMARY (id=`master`.id) (cost=0.50 rows=2) (actual time=0.015..0.022 rows=2 loops=660) -> Index lookup on t10 using PRIMARY (id=`master`.id) (cost=0.50 rows=2) (actual time=0.015..0.044 rows=2 loops=1320) | +------------------------------------------------------------------------------------------------------------------------------------------------------------------+ 1 row in set, 1 warning (1 min 3.57 sec)

SQLのActualタイムは、92ミリ秒、処理した行数が、2629行。

| -> Nested loop inner join (cost=5729.85 rows=8192) (actual time=0.113..92.382 rows=2639 loops=1)

以下を見ると、loopsが、1320回となっている。

-> Index lookup on t10 using PRIMARY (id=`master`.id) (cost=0.50 rows=2) (actual time=0.015..0.044 rows=2 loops=1320)

やった〜〜〜。　MySQLの explain analyzeは、"SQLの実行途中"(パース時間が長い割に、実行時間が短い場合は、実行中にキャンセルするのが難しいので表示されないケースはあるので注意）でキャンセルしても、途中までのActual Planを返してくれる！

念の為、sleep()関数を使ったトリッキーな再現方法ではなく、実際にSQLの実行中にキャンセルする方法を思いついたので、さらに、試してみる！

お分かりだろうか。みなさん大好き（？）、　~~再起問い合わせ~~再帰問合せでシーケンス番号を生成するクエリーだ。100000000ぐらい生成すれば、いい感じの実行時間になるだろうと、思われるので、まず、このSQLのパース時間だけ確認。

mysql> SET SESSION cte_max_recursion_depth = 100000000; Query OK, 0 rows affected (0.00 sec)

パース時間はほぼかかってないですね。先ほどの例は、結合する表が多いので、パース時間は長くなる傾向があるので、シンプルなSQLだけど、実行時間は、なげ〜〜〜〜ぞ〜というのにしてみた。

mysql> explain format=tree -> WITH RECURSIVE gen_nums(v) -> AS -> ( -> SELECT 1 -> UNION ALL -> SELECT v + 1 -> FROM -> gen_nums -> WHERE v + 1 <= 100000000 -> ) -> SELECT v from gen_nums; +------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | EXPLAIN | +------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | -> Table scan on gen_nums (cost=3.87..5.56 rows=3) -> Materialize recursive CTE gen_nums (cost=3.03..3.03 rows=3) -> Rows fetched before execution (cost=0.00..0.00 rows=1) -> Repeat until convergence -> Filter: ((gen_nums.v + 1) <= 100000000) (cost=2.73 rows=2) -> Scan new records on gen_nums (cost=2.73 rows=2) | +------------------------------------------------------------------------------------------------------------------------------------------------------------------+ 1 row in set (0.00 sec)

explain analyzeの実時間を確認

mysql> explain analyze -> WITH RECURSIVE gen_nums(v) -> AS -> ( -> SELECT 1 -> UNION ALL -> SELECT v + 1 -> FROM -> gen_nums -> WHERE v + 1 <= 100000000 -> ) -> SELECT v from gen_nums; +------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | EXPLAIN | +------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | -> Table scan on gen_nums (cost=3.87..5.56 rows=3) (actual time=139082.095..178091.268 rows=100000000 loops=1) -> Materialize recursive CTE gen_nums (cost=3.03..3.03 rows=3) (actual time=139081.959..139081.959 rows=100000000 loops=1) -> Rows fetched before execution (cost=0.00..0.00 rows=1) (actual time=0.000..0.000 rows=1 loops=1) -> Repeat until convergence -> Filter: ((gen_nums.v + 1) <= 100000000) (cost=2.73 rows=2) (actual time=0.003..29453.367 rows=50000000 loops=2) -> Scan new records on gen_nums (cost=2.73 rows=2) (actual time=0.002..21852.139 rows=50000000 loops=2) | +------------------------------------------------------------------------------------------------------------------------------------------------------------------+ 1 row in set (3 min 8.46 sec)

Actual timeは、178秒なので、60秒後にキャンセルすればよさそうですね。

| -> Table scan on gen_nums (cost=3.87..5.56 rows=3) (actual time=139082.095..178091.268 rows=100000000 loops=1)

では、キャンセルでどうなるか検証！！

mysql> explain analyze -> WITH RECURSIVE gen_nums(v) -> AS -> ( -> SELECT 1 -> UNION ALL -> SELECT v + 1 -> FROM -> gen_nums -> WHERE v + 1 <= 100000000 -> ) -> SELECT v from gen_nums; ^C^C -- query aborted +------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | EXPLAIN | +------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | -> Table scan on gen_nums (cost=3.87..5.56 rows=3) (never executed) -> Materialize recursive CTE gen_nums (cost=3.03..3.03 rows=3) (never executed) -> Rows fetched before execution (cost=0.00..0.00 rows=1) (actual time=0.000..0.000 rows=1 loops=1) -> Repeat until convergence -> Filter: ((gen_nums.v + 1) <= 100000000) (cost=2.73 rows=2) (actual time=0.004..27789.355 rows=47924088 loops=1) -> Scan new records on gen_nums (cost=2.73 rows=2) (actual time=0.002..20555.788 rows=47924088 loops=1) | +------------------------------------------------------------------------------------------------------------------------------------------------------------------+ 1 row in set, 1 warning (1 min 3.94 sec)

60行でキャンセルしたので、ほぼ同じ。

1 row in set, 1 warning (1 min 3.94 sec

以下の行ソースを見ると、Actual timeが21秒ほど、rowsも47924088行。

-> Scan new records on gen_nums (cost=2.73 rows=2) (actual time=0.002..20555.788 rows=47924088 loops=1)

興味深い部分は、以下の2行の行ソース。never execute　と表示されている。

| -> Table scan on gen_nums (cost=3.87..5.56 rows=3) (never executed) -> Materialize recursive CTE gen_nums (cost=3.03..3.03 rows=3) (never executed) ¥

これを見る限り、MySQLのexplain analyzeは、SQL文の実行フェース中にキャンセルすると、その時点までの Actual Planを出力してくれる。これ、結構嬉しいよね。長時間実行で、仕方なくキャンセルするにしても途中の状態。運が良ければ、詰まっている部分が見えるかもしれないわけで。。。

いや、他にも出力されないケースがあるとか、その検証方法だから出力されているだけどか、MySQLのexplain analyzeのディープなツッコミがありましたら、よろしくお願いします。:) (大事なので、2度書いておくw）

以上、explain analyze のブラックボックステスト。　実行途中でキャンセルできるみたいだけど、キャンセルしたら、Actual Plan、途中まで出るの？　の巻。終わり。

似てるようで、似てない。それぞれのRDBMSの世界w。　ではまた。

　

参考）
EXPLAIN ANALYZE による情報の取得
https://dev.mysql.com/doc/refman/8.0/ja/explain.html#explain-analyze

投稿日時 2023年8月 4日 (金) 06時00分 Oracle, Linux, チューニング, FAQ, SQL, MySQL, パフォーマンス | 固定リンク | 0 | コメント (0)

2023年2月 2日 (木)

join elimination（結合の排除）のバリエーション / FAQ

Previously on Mac De Oracle
SQL*Plus -Fastオプション / FAQでした。

今日は、結合排除のバリエーションをいくつか紹介しておこうと思います。
なんどか説明していた無駄に結合してないですよね？の例は、参照整合性制約を頼りに結合排除が行われるものでした。

今日はそれに加えて、典型的な例を2つ紹介しておきたいと思います。（ここ”　”、試験に出ませんよ！w　でないけど大切：）

一つ目は、結合列がそれぞれユニークキーかプライマリキーで一意で、1 : 0..1 で外部結合されるケース
結合の排除は、その結合を排除しても結果に影響しなことが自明な場合に発動するので、条件を満たしています。ただ、参照整合性制約のパターン同様に、SQL文を見ただけでは気づけないですよね。
あれ、実行計画にSQL文に記載されている表がない！？　で制約を見てみて、あ”〜〜〜〜理解。みたいなw

実行計画ではSQLモニターも含め、Join Eliminationしたことを明示的に示すコメント等はありません。結合が消えていることで気づくことが多いわけですw（よーく考えたら、その結合イラねーじゃんというわけですけどもw0

1* CREATE TABLE foo (id NUMBER PRIMARY KEY, note VARCHAR2(100)) 表が作成されました。 1* CREATE TABLE bar (id NUMBER PRIMARY KEY, memo VARCHAR2(100)) 表が作成されました。 1 SELECT 2 foo.id 3 , foo.note 4 FROM 5 foo 6 LEFT OUTER JOIN bar 7 ON 8* foo.id = bar.id 実行計画 ---------------------------------------------------------- Plan hash value: 1245013993 -------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | -------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 1 | 65 | 2 (0)| 00:00:01 | | 1 | TABLE ACCESS FULL| FOO | 1 | 65 | 2 (0)| 00:00:01 | -------------------------------------------------------------------------- Note ----- - dynamic statistics used: dynamic sampling (level=2)

この手の制約による結合の排除は、前提になる制約が結合排除の条件からはずれると排除されなくなります。
たとえば、前述の例で、それぞれの表を主キーで　1:0..1 で外部結合していましたよね？
それが仕様変更で、片方の方の主キーが複合主キーになってしまい。1:* の外部結合になってしまうと。。。。結合排除できなくなります。排除した場合、クエリー結果に影響するから。

1 CREATE TABLE foo2 ( 2 id NUMBER 3 , note VARCHAR2(100) 4 , PRIMARY KEY (id) 5* ) 表が作成されました。 1 CREATE TABLE bar2 ( 2 id NUMBER 3 , sq NUMBER NOT NULL 4 , memo VARCHAR2(100) 5 , PRIMARY KEY (id, sq) 6* ) 表が作成されました。 1 SELECT 2 foo2.id 3 , foo2.note 4 FROM 5 foo2 6 LEFT OUTER JOIN bar2 7 ON 8* foo2.id = bar2.id 実行計画 ---------------------------------------------------------- Plan hash value: 3679270243 ---------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ---------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 1 | 78 | 3 (0)| 00:00:01 | | 1 | NESTED LOOPS OUTER| | 1 | 78 | 3 (0)| 00:00:01 | | 2 | TABLE ACCESS FULL| FOO2 | 1 | 65 | 2 (0)| 00:00:01 | |* 3 | INDEX RANGE SCAN | SYS_C009222 | 1 | 13 | 1 (0)| 00:00:01 | ---------------------------------------------------------------------------------- Predicate Information (identified by operation id): --------------------------------------------------- 3 - access("FOO2"."ID"="BAR2"."ID"(+))

では、結合の排除のもう一つの例。これは制約というより、排除を狙った意図的な方法です。
動的なSQlが利用されているアプリケーションで使われていることが多い印象ですが、この方法は好き嫌い激しいかもしれないですね。私は好きじゃないですw　が偶にみます。

このクエリは、1:* の外部結合なのですが、WHERE 1=0　によって結果を返しません。なのでクエリー結果に影響しないことが自明なので排除されている。ということになります。

1 SELECT 2 foo2.id 3 , foo2.note 4 FROM 5 foo2 6 LEFT OUTER JOIN 7 ( 8 SELECT * FROM bar2 WHERE 1=0 9 ) bar2 10 ON 11* foo2.id = bar2.id 実行計画 ---------------------------------------------------------- Plan hash value: 2844017661 -------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | -------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 1 | 65 | 2 (0)| 00:00:01 | | 1 | TABLE ACCESS FULL| FOO2 | 1 | 65 | 2 (0)| 00:00:01 | -------------------------------------------------------------------------- Note ----- - dynamic statistics used: dynamic sampling (level=2)

ということで、今年も残すところあと11ヶ月ですねw
長いことやってたプロジェクトが一つ形になったみたいな、ならないような、hear through the grapevine.

では、また。

・Join Elimination（結合の排除）と参照整合性制約　/ FAQ
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 18 / No.53 / Join Elimination

投稿日時 2023年2月 2日 (木) 00時00分チューニング, FAQ, SQL, Opera, パフォーマンス | 固定リンク | 0 | コメント (0)

2023年1月27日 (金)

SQL*Plus -Fastオプション / FAQ

Previously on Mac De Oracle.
前回は、アドベントカレンダーのおまけのおまけwでした

今日は、そこで仕込んでおいたネタを使い、SQL*Plusも機能拡張されてたのすっかり忘れていた！　ので、
高Fetch圧症の話に絡めてSQL*Plusの-F[ast]オプション書いておこうと思います。

軽めですが。

Fetch回数削減に効果があるので、多数の行をFetchするような時は思い出すと良いですね。
Client/Server間のrount tripが減ることに繋がるわけで、そこが慢性病の原因なら少しでも楽になれたら良いと思いますし。
（ということで、Fetch Sizeも忘れないでね。という気持ちを込めて。）

最初は、-Fastオプションなしで。arraysizeのデフォルトは 15です。なお、この -F[ast]オプションは、Oracle Database 12c 12.2以降でサポートされています。

[oracle@localhost ~]$ sqlplus scott/tiger@orclpdb1 ...略... Oracle Database 21c Enterprise Edition Release 21.0.0.0.0 - Production Version 21.3.0.0.0 に接続されました。 SCOTT@orclpdb1> @dayx2 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:18.83 実行計画 ---------------------------------------------------------- Plan hash value: 2223315184 ------------------------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time | ------------------------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 1000K| 1451M| | 119K (1)| 00:00:05 | |* 1 | HASH JOIN OUTER | | 1000K| 1451M| 497M| 119K (1)| 00:00:05 | | 2 | TABLE ACCESS FULL| SUPERTYPE | 1000K| 486M| | 19593 (1)| 00:00:01 | |* 3 | TABLE ACCESS FULL| NIKOICHI_MITAINA_SUBTYPE | 750K| 723M| | 38796 (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 229599 consistent gets 374715 physical reads 0 redo size 1551273711 bytes sent via SQL*Net to client 735146 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 ------------------------------ ...略... Duration : 173s ...略... Fetch Calls : 66668 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 | =========================================================================================== | 17 | 15 | 1.59 | 0.84 | 66668 | 230K | 6878 | 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 | | | | 172 | +2 | 1 | 1M | | | | | . | . | | | | 1 | HASH JOIN OUTER | | 1M | 119K | 173 | +1 | 1 | 1M | 5169 | 1GB | 5169 | 1GB | 184MB | 1GB | 76.92 | Cpu (9) | | | | | | | | | | | | | | | | | | SQL*Net more data to client (1) | | 2 | TABLE ACCESS FULL | SUPERTYPE | 1M | 19593 | 1 | +2 | 1 | 1M | 575 | 559MB | | | . | . | | | | 3 | TABLE ACCESS FULL | NIKOICHI_MITAINA_SUBTYPE | 750K | 38796 | 47 | +2 | 1 | 1M | 1134 | 1GB | | | . | . | 15.38 | Cpu (2) | ==============================================================================================================================================================================================================

次に、-F[ast]オプションで接続します。このオプションにより、ARRAYSIZE = 100に設定されます。それ以外にも3.5.1.5 FASTオプションいくつかの設定が変更されます。

[oracle@localhost ~]$ sqlplus -Fast scott/tiger@orclpdb1 ...略... Oracle Database 21c Enterprise Edition Release 21.0.0.0.0 - Production Version 21.3.0.0.0 に接続されました。 SCOTT@orclpdb1> @dayx2 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:01:55.03 実行計画 ---------------------------------------------------------- Plan hash value: 2223315184 ------------------------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time | ------------------------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 1000K| 1451M| | 119K (1)| 00:00:05 | |* 1 | HASH JOIN OUTER | | 1000K| 1451M| 497M| 119K (1)| 00:00:05 | | 2 | TABLE ACCESS FULL| SUPERTYPE | 1000K| 486M| | 19593 (1)| 00:00:01 | |* 3 | TABLE ACCESS FULL| NIKOICHI_MITAINA_SUBTYPE | 750K| 723M| | 38796 (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 216797 consistent gets 374715 physical reads 0 redo size 1539940308 bytes sent via SQL*Net to client 110262 bytes received via SQL*Net from client 10001 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 ------------------------------ ...略... Duration : 146s ...略... Fetch Calls : 10001 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 | ============================================================================================ | 17 | 14 | 1.76 | 1.72 | 10001 | 216K | 6878 | 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 | | | | 145 | +2 | 1 | 1M | | | | | . | . | | | | 1 | HASH JOIN OUTER | | 1M | 119K | 146 | +1 | 1 | 1M | 5169 | 1GB | 5169 | 1GB | 184MB | 1GB | 100.00 | Cpu (14) | | | | | | | | | | | | | | | | | | SQL*Net more data to client (4) | | 2 | TABLE ACCESS FULL | SUPERTYPE | 1M | 19593 | 1 | +2 | 1 | 1M | 575 | 559MB | | | . | . | | | | 3 | TABLE ACCESS FULL | NIKOICHI_MITAINA_SUBTYPE | 750K | 38796 | 42 | +2 | 1 | 1M | 1134 | 1GB | | | . | . | | | ==============================================================================================================================================================================================================

-Fastオプションなしの場合と比較してみるとSQL*Net roundtrips to/from clientなど減ってますよね:)
このround tripは、待機イベントSQL*Net more data to clientなどで現れます。(SQL監視のActivity Detailsにも現れていますので、覚えておくと良いと思います)

-Fastオプションなし（auto trace)

1551273711 bytes sent via SQL*Net to client 735146 bytes received via SQL*Net from client 66668 SQL*Net roundtrips to/from client

-Fastオプションあり（auto trace)

1539940308 bytes sent via SQL*Net to client 110262 bytes received via SQL*Net from client 10001 SQL*Net roundtrips to/from client

-Fastオプションなし（SQL監視)

Global Information ------------------------------ ...略... Duration : 173s ...略... Fetch Calls : 66668

-Fastオプションあり（auto trace)

Global Information ------------------------------ ...略... Dration : 146s ...略... Fetch Calls : 10001

早く、ポカポカ陽気にならないかなぁ。

と思う寒い日々。

では、また。

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

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年分のおまけのおまけ. これで, おしまい.

では, また.

Related article on Mac De Oracle

・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 1 / TABLE FULL SCAN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 2 / INDEX UNIQUE SCAN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 3 / INDEX RANGE SCAN, Index Only Scan
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 4 / INDEX RANGE SCAN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 5 / INDEX RANGE SCAN, INLIST ITERATOR
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 6 / INDEX FAST SCAN, Index Only Scan
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 7 / INDEX FULL SCAN,Index Only Scan
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 8 / INDEX SKIP SCAN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 9 / TABLE ACCESS INMEMORY FULL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 10 / NESTED LOOP JOIN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 11 / MERGE JOIN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 12 / HASH JOIN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 13 / HASH JOIN OUTER
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 14 / HASH JOIN FULL OUTER
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 15 / PX, TABLE ACCESS FULL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 16 / CONCATENATION
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 17 / SORT UNIQUE, UNION-ALL = UNION
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 18 / UNION-ALL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 19 / INTERSECTION
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 20 / MINUS
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 21 / WINDOW NOSORT STOPKEY
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 22 / COUNT STOPKEY
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 23 / HASH JOIN - LEFT-DEEP JOIN vs RIGHT-DEEP JOIN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 24 / CONNECT BY NO FILTERING WITH START-WITH
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 25 / UNION ALL (RECURSIVE WITH) DEPTH FIRST, RECURSIVE WITH PUMP
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#1 / STAR TRANSFORM, VECTOR TRANSFORM (DWH向け)
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#2 / MERGE (UPSERT)
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#3 / RDFView
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#4 / INDEX FULL SCAN (MIN/MAX) - Index Only Scan
・実行計画は, SQL文のレントゲン写真だ！ No.30 - LOAD TABLE CONVENTIONAL vs. LOAD AS SELECT
・実行計画は, SQL文のレントゲン写真だ！ No.31 - TEMP TABLE TRANSFORMATION LOAD AS SELECT (CURSOR DURATION MEMORY)
・実行計画は, SQL文のレントゲン写真だ！ No.32 - EXTERNAL TABLE ACCESS FULL / INMEMORY FULL
・実行計画は, SQL文のレントゲン写真だ！ No.33 - BITMAP CONVERSION TO ROWIDS
・実行計画は, SQL文のレントゲン写真だ！ No.34 - 似て非なるもの　USE_CONCAT　と　OR_EXPAND ヒントと　手書きSQLのレントゲンの見分け方
 ・実行計画は, SQL文のレントゲン写真だ！ No.35 - 似て非なるもの USE_CONCAT と OR_EXPANDヒントとパラレルクエリー
 ・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 1　/ No.36 / INTERSECT ALL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 2　/ No.37 / MINUS ALL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 3　/ No.38 / EXCEPT and EXCEPT ALL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 4 / No.39 / In-Memory Hybrid Scans
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 5 / No.40 / PIVOT and UNPIVOT
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 6 / No.41 / In-Memory Vectorized Join
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 7 / No.42 / INDEX RANGE SCAN (MULTI VALUE)
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 8 / No.43 / TABLE ACCESS BY INDEX ROWID BATCHED
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 9 / No.44 / COLLECTION ITERATOR PICKLER FETCH
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 10 / No.45 / MAT_VIEW REWRITE ACCESS FULL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 11 / No.46 / GROUPING SETS, ROLLUP, CUBE
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 12 / No.47 /　TEMP TABLE TRANSFORMATION
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 13 / No.48 / MULTI-TABLE INSERT
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 14 / No.49 / the DUAL Table
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 15 / No.50 / REMOTE
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 16 / No.51 / Concurrent Execution of Union All and Union
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 17 / No.52 / Order by Elimination
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 18 / No.53 / Join Elimination
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 19 / No.54 / Group by Elimination
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 20 / No.55 / DISTINCT Elimination
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 21 / No.56 / INLIST ITERATOR と Sub Query と STATISTICS COLLECTOR
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 22 / No.57 / Subquery Unnesting
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 23 / No.58 / ANTI JOIN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 24 / No.59 / SQL MACRO (19.7〜)
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 25 / No.60 / ANSI JOIN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 / No.60 / ANSI JOINのおまけ

投稿日時 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月26日 (月)

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

さて, 恒例のアドベントカレンダーのおまけw

Day25で, 性能面で気になる部分のコメントしていた点を思い出してください. INDEX UNIQUE SCANを繰り返している点. 問題にならないなら良いのですが, （データ件数がそれ以上増加しなければ, 安定した処理時間にはなるわけですが....)
データ量次第の危さを感じますとコメントしていた点を思い出してください.

では, 私が, 懸念しているINDEX UNIQUE SCANの回数をSQLモニターという名の内視鏡的な方法で診ていきましょう.
VW_LAT_E87C3AAFのLATERALビューに変換されている操作以降がSUPERTYPE表のヒット件数分繰り返されています. この部分こそ, "データ量次第の危さ”と言った理由です.

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 Stats ================================================= | Elapsed | Cpu | Other | Fetch | Buffer | | Time(s) | Time(s) | Waits(s) | Calls | Gets | ================================================= | 0.42 | 0.37 | 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 | | | | 3 | +0 | 1 | 10001 | . | | | | 1 | MERGE JOIN OUTER | | 20002 | 40226 | 3 | +0 | 1 | 10001 | . | | | | 2 | TABLE ACCESS FULL | SUPERTYPE | 10001 | 204 | 3 | +0 | 1 | 10001 | . | | | | 3 | BUFFER SORT | | 2 | 40021 | 3 | +0 | 10001 | 10000 | 2048 | | | | 4 | VIEW | VW_LAT_E87C3AAF | 2 | 4 | 3 | +0 | 10001 | 10000 | . | | | | 5 | VIEW | VW_ORE_FDF394AE | 2 | 4 | 3 | +0 | 10001 | 10000 | . | | | | 6 | UNION-ALL | | | | 3 | +0 | 10001 | 10000 | . | | | | 7 | TABLE ACCESS BY INDEX ROWID | NIKOICHI_MITAINA_SUBTYPE | 1 | 2 | 3 | +0 | 10001 | 5000 | . | | | | 8 | INDEX UNIQUE SCAN | UK1 | 1 | 1 | 3 | +0 | 10001 | 5000 | . | | | | 9 | TABLE ACCESS BY INDEX ROWID | NIKOICHI_MITAINA_SUBTYPE | 1 | 2 | 3 | +0 | 10001 | 5000 | . | | | | 10 | INDEX UNIQUE SCAN | UK2 | 1 | 1 | 3 | +0 | 10001 | 5000 | . | | | =====================================================================================================================================================================

今回のケースでは, CPUバウンドになっていますが, キャッシュヒット率が高ければ, CPUバンドでしょうし, 乗り切らないほど巨大であれば, IOバウンドになって現れそうですよね.

どちらの表のデータ件数も今以上に増加（現時点の処理時間が想定範囲内であることを前提としています）する可能性があり, 読みきれない部分があるのであれば, LATERALビュー変換されたこの実行計画は避けた方が良いだろうという意見に反対される方は少ないのではないでしょうか.

であれば, 方法は一つ.
そう, 自分で, 書き換えれば良いですね. データ量が増加しても安定して, 多少無駄なアクセスがあっても処理時間が安定しやすい方向へ最適化が行われるSQL構文へ. （多少, SQL文が長くなってたとしても）

ということで, どう構文変更して書き換えたらいい感じになりそうか考えてみてね, 冬休みの頭の体操になるのではないかと思います:)
（答え合わせはしませんよ）

ではまた. （Oracleネタとしては, 今年はここまで）　また来年お会いしましょう. みなさん, 良いお年を！

Related article on Mac De Oracle
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 1 / TABLE FULL SCAN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 2 / INDEX UNIQUE SCAN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 3 / INDEX RANGE SCAN, Index Only Scan
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 4 / INDEX RANGE SCAN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 5 / INDEX RANGE SCAN, INLIST ITERATOR
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 6 / INDEX FAST SCAN, Index Only Scan
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 7 / INDEX FULL SCAN,Index Only Scan
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 8 / INDEX SKIP SCAN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 9 / TABLE ACCESS INMEMORY FULL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 10 / NESTED LOOP JOIN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 11 / MERGE JOIN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 12 / HASH JOIN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 13 / HASH JOIN OUTER
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 14 / HASH JOIN FULL OUTER
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 15 / PX, TABLE ACCESS FULL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 16 / CONCATENATION
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 17 / SORT UNIQUE, UNION-ALL = UNION
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 18 / UNION-ALL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 19 / INTERSECTION
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 20 / MINUS
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 21 / WINDOW NOSORT STOPKEY
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 22 / COUNT STOPKEY
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 23 / HASH JOIN - LEFT-DEEP JOIN vs RIGHT-DEEP JOIN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 24 / CONNECT BY NO FILTERING WITH START-WITH
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 25 / UNION ALL (RECURSIVE WITH) DEPTH FIRST, RECURSIVE WITH PUMP
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#1 / STAR TRANSFORM, VECTOR TRANSFORM (DWH向け)
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#2 / MERGE (UPSERT)
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#3 / RDFView
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#4 / INDEX FULL SCAN (MIN/MAX) - Index Only Scan
・実行計画は, SQL文のレントゲン写真だ！ No.30 - LOAD TABLE CONVENTIONAL vs. LOAD AS SELECT
・実行計画は, SQL文のレントゲン写真だ！ No.31 - TEMP TABLE TRANSFORMATION LOAD AS SELECT (CURSOR DURATION MEMORY)
・実行計画は, SQL文のレントゲン写真だ！ No.32 - EXTERNAL TABLE ACCESS FULL / INMEMORY FULL
・実行計画は, SQL文のレントゲン写真だ！ No.33 - BITMAP CONVERSION TO ROWIDS
・実行計画は, SQL文のレントゲン写真だ！ No.34 - 似て非なるもの　USE_CONCAT　と　OR_EXPAND ヒントと　手書きSQLのレントゲンの見分け方
 ・実行計画は, SQL文のレントゲン写真だ！ No.35 - 似て非なるもの USE_CONCAT と OR_EXPANDヒントとパラレルクエリー
 ・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 1　/ No.36 / INTERSECT ALL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 2　/ No.37 / MINUS ALL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 3　/ No.38 / EXCEPT and EXCEPT ALL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 4 / No.39 / In-Memory Hybrid Scans
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 5 / No.40 / PIVOT and UNPIVOT
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 6 / No.41 / In-Memory Vectorized Join
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 7 / No.42 / INDEX RANGE SCAN (MULTI VALUE)
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 8 / No.43 / TABLE ACCESS BY INDEX ROWID BATCHED
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 9 / No.44 / COLLECTION ITERATOR PICKLER FETCH
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 10 / No.45 / MAT_VIEW REWRITE ACCESS FULL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 11 / No.46 / GROUPING SETS, ROLLUP, CUBE
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 12 / No.47 /　TEMP TABLE TRANSFORMATION
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 13 / No.48 / MULTI-TABLE INSERT
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 14 / No.49 / the DUAL Table
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 15 / No.50 / REMOTE
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 16 / No.51 / Concurrent Execution of Union All and Union
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 17 / No.52 / Order by Elimination
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 18 / No.53 / Join Elimination
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 19 / No.54 / Group by Elimination
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 20 / No.55 / DISTINCT Elimination
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 21 / No.56 / INLIST ITERATOR と Sub Query と STATISTICS COLLECTOR
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 22 / No.57 / Subquery Unnesting
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 23 / No.58 / ANTI JOIN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 24 / No.59 / SQL MACRO (19.7〜)
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 25 / No.60 / ANSI JOIN

投稿日時 2022年12月26日 (月) 00時00分チューニング, SQL, 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月25日 (日)

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

Previously on Mac De Oracle...
Day 24は, SQL MACROにフォーカスをあてました. SEMI JOINだろうと思ってた方々 m(_ _)m 元々今日のネタの伏線をはろうとしていたので, いずれにしても, SEMI JOINではなかったのですがw

と, いうことで Day 25！
ついに, アドベントカレンダー　実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022も千秋楽です

最終日ですので, 大人の事情に金縛りに会いながらも, 頑張って作ってしまったと思われる, 稀に, よくみるタイプのモデルを, それぞれのバージョンのOracleオプティマイザが, どう最適化しようと苦労しているのか, 実行計画というレントゲンを通し, 生暖か, いや, 熱い眼差しでワイン片手に, 観察しつつ, アドベントカレンダー　実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022を締めくくりたいと思います. （オチはないかもw）

当医院に担ぎ込まれてきたSQL文を問診してみると, こんな感じに見えました. （スーパータイプ, サブタイプテーブルを大人の事情で無理強いされて出来上がってしまったような危うい雰囲気であります. 本題はモデルの良し悪しではないので, これ以上, ツッコまないよ）

ということで, 稀によく見るタイプの患者さんを図に起こしてみました. ん〜, かなり複雑な事情がありそうですね！
参考までに, スーパータイプ, サブタイプの概念モデルの実装方法についてはいくつかのパターンがあります. サブタイプがニコイチになっている割に, 結合キーが２個というところが大人の事情を強く感じますが.
（スーパータイプ, サブタイプよくわからんという方は, 斜め読みするならスーパータイプ／サブタイプのテーブルへの実装 / hmatsu47が良いかなと思います）

他に, 外傷がないか SQL文　を診ておきましょう, SQL文はこんなでした. ANSI構文でなければ, こうはならないですよね. Oracleの方言では結合条件のORは書けないので, UNIONで書くことになるのですが, Oracleの方言でこれを書こうとすると割と大変です. UNIONで書いた方が割と無難な実行計画に最適化されやすいというのもありますが, さて, ANSI構文ではどうなりますか. .
（SQLは雰囲気が伝わるように作ってありますw）

SELECT * FROM supertype st LEFT OUTER JOIN nikoichi_mitaina_subtype nmst ON st.pkey = nmst.col1 OR st.pkey = nmst.col2 ;

では, 実行計画という名のレントゲンを11gR1, 11gR2, 12cR1, 12cR2, 18c, 19c, 21cで, 最適化の違いを診ていきましょう. なお, 隠しパラメータ含めパラメータはデフォルト設定です.
データの準備

SCOTT@orclpdb1> @day25-0 1* DROP TABLE supertype 表が削除されました. 経過: 00:00:00.05 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.03 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 BEGIN 2 FOR i IN 1..10000 LOOP 3 INSERT INTO supertype VALUES(i,0,0,LPAD(i,500,'*')); 4 INSERT INTO nikoichi_mitaina_subtype VALUES( 5 i 6 , CASE WHEN MOD(i,2) = 0 THEN i ELSE null END 7 , CASE WHEN MOD(i,2) = 1 THEN i ELSE null END 8 , LPAD(i,1000,'*') 9 ); 10 IF MOD(i,100) = 0 THEN COMMIT; END IF; 11 END LOOP; 12 INSERT INTO supertype VALUES(10001,0,0,null); 13 COMMIT; 14 DBMS_STATS.GATHER_TABLE_STATS(ownname=>'SCOTT',tabname=>'SUPERTYPE',no_invalidate=>false,cascade=>true); 15 DBMS_STATS.GATHER_TABLE_STATS(ownname=>'SCOTT',tabname=>'NIKOICHI_MITAINA_SUBTYPE',no_invalidate=>false,cascade=>true); 16* END; PL/SQLプロシージャが正常に完了しました. 経過: 00:00:02.83

現時点でリリースされている最新版, 21cから順に, 11gR2まで遡って診ていきます

やはり, 最新のオプティマイザは, なかなかやりますね.

結合条件のORをId=5, VW_ORE_FDF394AEで分かるように, OR_EXPANDしているようです.
さらに, その結果を, Id=6, VW_LAT_E87C3AAFで分かるように, LATERALビューに変換し, MERGE JOIN OUTERしています. LATERALが使えるようになったリリースであることも大きく影響しているように見えます.
（実は, 昨日のネタは, LATERALして伏線にしようと思ってたのですが, SQL MACROの面白さ先にしたくなったのでしたw）

さらに, 興味深いのは, NIKOICHI_MITAINA_SUBTYPEのユニーク索引をIS NOT NULLでフィルタリングしながらアクセスしているところ. 流石です. とは言っても, INDEX UNIQUE SCANしているのでデータ量次第の危さも感じますよね. キャッシュに乗ってたら早そうですが.

SCOTT@orclpdb1> select banner from v$version; BANNER ------------------------------------------------------------------------ Oracle Database 21c Enterprise Edition Release 21.0.0.0.0 - Production SCOTT@orclpdb1> @day25 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行が選択されました. 実行計画 ---------------------------------------------------------- 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

冒頭で, ”Oracleの方言でこれを書こうとすると割と大変です. ”と書きましたが, 以下が理由です.
同じような表現はできないのです. 方言でこれを書こうとすると割と大変と言ったのはこの理由からなんです.

1 SELECT * 2 FROM 3 supertype st 4 , nikoichi_mitaina_subtype nmst 5 WHERE 6 st.pkey = nmst.col1(+) 7* OR st.pkey = nmst.col2(+) OR st.pkey = nmst.col2(+) * 行7でエラーが発生しました. : ORA-01719: ORまたはINオペランドの中で外部結合演算子(+)は使用できません

余談はこれぐらいにして, 19cではどうか見てみましょう（結果飲み）
同じ実行計画です. LATERALやOR_EXPANDが実装が利用されていることから, それらが実装されたあたりからはこのような実行計画が生成されている可能性が高いですね.

SCOTT@ORCL> select banner from v$version; BANNER -------------------------------------------------------------------------------- Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production Execution Plan ---------------------------------------------------------- Plan hash value: 2133431102 ------------------------------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ------------------------------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 20002 | 20M| 40219 (1)| 00:00:02 | | 1 | MERGE JOIN OUTER | | 20002 | 20M| 40219 (1)| 00:00:02 | | 2 | TABLE ACCESS FULL | SUPERTYPE | 10001 | 4971K| 204 (0)| 00:00:01 | | 3 | BUFFER SORT | | 2 | 1082 | 40015 (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)

18cではどうでしょう（結果のみ）
やはり, 同じ, Plan hash valueになっていますね. なるほどなるほど.

SCOTT> select banner from v$version; BANNER -------------------------------------------------------------------------------- Oracle Database 18c Enterprise Edition Release 18.0.0.0.0 - Production Execution Plan ---------------------------------------------------------- Plan hash value: 2133431102 ------------------------------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ------------------------------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 20002 | 20M| 40218 (1)| 00:00:02 | | 1 | MERGE JOIN OUTER | | 20002 | 20M| 40218 (1)| 00:00:02 | | 2 | TABLE ACCESS FULL | SUPERTYPE | 10001 | 4971K| 204 (0)| 00:00:01 | | 3 | BUFFER SORT | | 2 | 1082 | 40014 (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)

お！, 12cR2も同じ実行計画になりますね！

orcl@SCOTT> select banner from v$version; BANNER -------------------------------------------------------------------------------- Oracle Database 12c Enterprise Edition Release 12.2.0.1.0 - 64bit Production PL/SQL Release 12.2.0.1.0 - Production CORE 12.2.0.1.0 Production TNS for Linux: Version 12.2.0.1.0 - Production NLSRTL Version 12.2.0.1.0 - Production Execution Plan ---------------------------------------------------------- Plan hash value: 2133431102 ------------------------------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ------------------------------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 20002 | 20M| 40217 (1)| 00:00:02 | | 1 | MERGE JOIN OUTER | | 20002 | 20M| 40217 (1)| 00:00:02 | | 2 | TABLE ACCESS FULL | SUPERTYPE | 10001 | 4971K| 204 (0)| 00:00:01 | | 3 | BUFFER SORT | | 2 | 1082 | 40013 (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)

12cR1はどうでしょう. おっと, ここで差が出ました. OR_EXPANDではなく, USE_CONCATが行われています. たた, VW_LAT_E87C3AAFがあることからLATERALビューが内部的に利用されていることが見えますね.
性能に影響しそうなのは, NESTED LOOPS OUTERになっているあたりでしょうね. データ量が大きい想定見積もりに倒れている最近のリリースとは明らかに異なり. 危険な感じの実行計画ではあります.

SCOTT@pdborcl12c> select banner from v$version; BANNER -------------------------------------------------------------------------------- Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production PL/SQL Release 12.1.0.2.0 - Production CORE 12.1.0.2.0 Production TNS for Linux: Version 12.1.0.2.0 - Production NLSRTL Version 12.1.0.2.0 - Production 実行計画 ---------------------------------------------------------- Plan hash value: 3799136614 ----------------------------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ----------------------------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 20002 | 20M| 40216 (1)| 00:00:02 | | 1 | NESTED LOOPS OUTER | | 20002 | 20M| 40216 (1)| 00:00:02 | | 2 | TABLE ACCESS FULL | SUPERTYPE | 10001 | 4971K| 204 (0)| 00:00:01 | | 3 | VIEW | VW_LAT_E87C3AAF | 2 | 1082 | 4 (0)| 00:00:01 | | 4 | CONCATENATION | | | | | | | 5 | TABLE ACCESS BY INDEX ROWID| NIKOICHI_MITAINA_SUBTYPE | 1 | 1009 | 2 (0)| 00:00:01 | |* 6 | INDEX UNIQUE SCAN | UK2 | 1 | | 1 (0)| 00:00:01 | |* 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 | ----------------------------------------------------------------------------------------------------------- Predicate Information (identified by operation id): --------------------------------------------------- 6 - access("ST"."PKEY"="NMST"."COL2") filter("NMST"."COL2" IS NOT NULL) 7 - filter(LNNVL("NMST"."COL2" IS NOT NULL) OR LNNVL("ST"."PKEY"="NMST"."COL2")) 8 - access("ST"."PKEY"="NMST"."COL1") filter("NMST"."COL1" IS NOT NULL)

11gR2です. LATERALビューも消え, USE_CONCATが行われているだけで, さらに, NESTED LOOPS OUTERなのでデータ量が多いとやはり危険なタイプの実行計画になっているのがわかります.

orcl@SCOTT> select banner from v$version; BANNER -------------------------------------------------------------------------------- Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production PL/SQL Release 11.2.0.4.0 - Production CORE 11.2.0.4.0 Production TNS for Linux: Version 11.2.0.4.0 - Production NLSRTL Version 11.2.0.4.0 - Production orcl@SCOTT> @day25 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 Execution Plan ---------------------------------------------------------- Plan hash value: 2117741269 ----------------------------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ----------------------------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 20002 | 20M| 40236 (1)| 00:08:03 | | 1 | NESTED LOOPS OUTER | | 20002 | 20M| 40236 (1)| 00:08:03 | | 2 | TABLE ACCESS FULL | SUPERTYPE | 10001 | 4971K| 205 (1)| 00:00:03 | | 3 | VIEW | | 2 | 1082 | 4 (0)| 00:00:01 | | 4 | CONCATENATION | | | | | | | 5 | TABLE ACCESS BY INDEX ROWID| NIKOICHI_MITAINA_SUBTYPE | 1 | 1009 | 2 (0)| 00:00:01 | |* 6 | INDEX UNIQUE SCAN | UK2 | 1 | | 1 (0)| 00:00:01 | |* 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 | ----------------------------------------------------------------------------------------------------------- Predicate Information (identified by operation id): --------------------------------------------------- 6 - access("ST"."PKEY"="NMST"."COL2") filter("NMST"."COL2" IS NOT NULL) 7 - filter(LNNVL("NMST"."COL2" IS NOT NULL) OR LNNVL("ST"."PKEY"="NMST"."COL2")) 8 - access("ST"."PKEY"="NMST"."COL1") filter("NMST"."COL1" IS NOT NULL)

このケース, 最新のリリースでは, LATERALビューを使い, MERGE JOINも利用するような多くの内部的な書き換えが行われ, いい感じの実行計画が生成されています.

ただ, 稀に, そうでもないケースもあります. （ググってみると結構ある. あった. ことがわかります）
そのような場合, 結合条件でORを利用する構文を書き換え, UNIONを使った構文（このケースではオプティマイザが内部的に変換していますが）へ書き換えてしまった方が良い実行計画にできる場合があります. （その方がヒントでの細かい制御もしやすい場合があります）
その辺りは, 状況に応じ臨機応変に対応すれば良いと思います.
今回のMERGE OUTER JOINで想定より遅い場合には, やはり構文変更してしまった方が処理時間は安定して, 無難な方向になるケースもありそうに思います.

ということで, 今年のアドベントカレンダーは, しゅうーーーりょう！！

参考） Internal Views / Oracle Scratchpad

I wish you all a Merry Christmas and a Happy New Year!

ではまた ;)

Related article on Mac De Oracle
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 1 / TABLE FULL SCAN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 2 / INDEX UNIQUE SCAN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 3 / INDEX RANGE SCAN, Index Only Scan
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 4 / INDEX RANGE SCAN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 5 / INDEX RANGE SCAN, INLIST ITERATOR
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 6 / INDEX FAST SCAN, Index Only Scan
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 7 / INDEX FULL SCAN,Index Only Scan
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 8 / INDEX SKIP SCAN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 9 / TABLE ACCESS INMEMORY FULL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 10 / NESTED LOOP JOIN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 11 / MERGE JOIN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 12 / HASH JOIN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 13 / HASH JOIN OUTER
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 14 / HASH JOIN FULL OUTER
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 15 / PX, TABLE ACCESS FULL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 16 / CONCATENATION
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 17 / SORT UNIQUE, UNION-ALL = UNION
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 18 / UNION-ALL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 19 / INTERSECTION
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 20 / MINUS
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 21 / WINDOW NOSORT STOPKEY
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 22 / COUNT STOPKEY
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 23 / HASH JOIN - LEFT-DEEP JOIN vs RIGHT-DEEP JOIN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 24 / CONNECT BY NO FILTERING WITH START-WITH
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 25 / UNION ALL (RECURSIVE WITH) DEPTH FIRST, RECURSIVE WITH PUMP
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#1 / STAR TRANSFORM, VECTOR TRANSFORM (DWH向け)
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#2 / MERGE (UPSERT)
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#3 / RDFView
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#4 / INDEX FULL SCAN (MIN/MAX) - Index Only Scan
・実行計画は, SQL文のレントゲン写真だ！ No.30 - LOAD TABLE CONVENTIONAL vs. LOAD AS SELECT
・実行計画は, SQL文のレントゲン写真だ！ No.31 - TEMP TABLE TRANSFORMATION LOAD AS SELECT (CURSOR DURATION MEMORY)
・実行計画は, SQL文のレントゲン写真だ！ No.32 - EXTERNAL TABLE ACCESS FULL / INMEMORY FULL
・実行計画は, SQL文のレントゲン写真だ！ No.33 - BITMAP CONVERSION TO ROWIDS
・実行計画は, SQL文のレントゲン写真だ！ No.34 - 似て非なるもの　USE_CONCAT　と　OR_EXPAND ヒントと　手書きSQLのレントゲンの見分け方
 ・実行計画は, SQL文のレントゲン写真だ！ No.35 - 似て非なるもの USE_CONCAT と OR_EXPANDヒントとパラレルクエリー
 ・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 1　/ No.36 / INTERSECT ALL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 2　/ No.37 / MINUS ALL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 3　/ No.38 / EXCEPT and EXCEPT ALL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 4 / No.39 / In-Memory Hybrid Scans
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 5 / No.40 / PIVOT and UNPIVOT
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 6 / No.41 / In-Memory Vectorized Join
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 7 / No.42 / INDEX RANGE SCAN (MULTI VALUE)
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 8 / No.43 / TABLE ACCESS BY INDEX ROWID BATCHED
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 9 / No.44 / COLLECTION ITERATOR PICKLER FETCH
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 10 / No.45 / MAT_VIEW REWRITE ACCESS FULL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 11 / No.46 / GROUPING SETS, ROLLUP, CUBE
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 12 / No.47 /　TEMP TABLE TRANSFORMATION
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 13 / No.48 / MULTI-TABLE INSERT
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 14 / No.49 / the DUAL Table
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 15 / No.50 / REMOTE
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 16 / No.51 / Concurrent Execution of Union All and Union
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 17 / No.52 / Order by Elimination
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 18 / No.53 / Join Elimination
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 19 / No.54 / Group by Elimination
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 20 / No.55 / DISTINCT Elimination
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 21 / No.56 / INLIST ITERATOR と Sub Query と STATISTICS COLLECTOR
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 22 / No.57 / Subquery Unnesting
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 23 / No.58 / ANTI JOIN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 24 / No.59 / SQL MACRO (19.7〜)

投稿日時 2022年12月25日 (日) 00時00分 Oracle, チューニング, SQL, 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月24日 (土)

実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 24 / No.59 / SQL MACRO (19.7〜)

Previously on Mac De Oracle...

Day 23は, ANTI JOINにフォーカスをあてました. そうくれば, 次は, SEMI JOINだろう？　と思ったあなた！　ハズレですw

では, Day 24 クリスマスイブの窓を開けましょう！
実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 9 / No.44 / COLLECTION ITERATOR PICKLER FETCH
で, パイプラインテーブルファンクションだと, ファンクションが実行されていることしかExplain等で見る事はできなくて, COLLECTION ITERATOR PICKLER FETCH だけなんだよね, と言うお話をしました.

1 SELECT 2 * 3 FROM 4* day9_pkg.list_2_latest_sales(2, 20, 5745) PROD_ID CUST_ID TIME_ID CHANNEL_ID PROMO_ID QUANTITY_SOLD AMOUNT_SOLD ---------- ---------- -------- ---------- ---------- ------------- ----------- 20 5745 01-12-31 2 999 1 628.89 実行計画 ---------------------------------------------------------- Plan hash value: 457385954 --------------------------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | --------------------------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 8168 | 16336 | 29 (0)| 00:00:01 | | 1 | COLLECTION ITERATOR PICKLER FETCH| LIST_2_LATEST_SALES | 8168 | 16336 | 29 (0)| 00:00:01 | ---------------------------------------------------------------------------------------------------------

レントゲン屋さん的にはw　辛いよね. と.　間接的に見るしかないわけで. 少々面倒, 対応を意識していないと難しいですし.

今日は, クリスマスイブですし, Oracleさんもどんどん新機能提供してくれてて, それファンクションじゃないの？　いえ, いえ. ？？今日は, SQLマクロ(SQM)の実行計画という名のレントゲンです.

SQLマクロ(SQM)を作ります. パイプラインテーブルファンクションと似てますけども, SQL_MACROです.

SCOTT@orclpdb1> @day24 1* DROP FUNCTION sq_macro_sample ファンクションが削除されました. 1 CREATE FUNCTION sq_macro_sample 2 ( 3 p_first_rows NUMBER 4 , p_table_name DBMS_TF.TABLE_T 5 ) 6 RETURN VARCHAR2 7 SQL_MACRO 8 IS 9 BEGIN 10 RETURN 11 'SELECT 12 * 13 FROM 14 p_table_name 15 FETCH FIRST sq_macro_sample.p_first_rows ROWS ONLY' 16 ; 17* END; ファンクションが作成されました.

おおおおおおおおおお〜っと. マクロが展開されて, emp表の直接アクセスしている. （マクロだからそりゃそうだw）
レントゲンを見てみましょう.

パイプラインテーブルファンクションと外見からはあまり違いに気づかないというか, 気づけないですが. レントゲンの結果は全く違います！　マクロが展開されて, 普通の SQL文の実行計画という名のレントゲンを見ることができます.

1 SELECT 2 * 3 FROM 4* sq_macro_sample(3, emp) 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 7521 WARD SALESMAN 7698 81-02-22 1250 500 30 実行計画 ---------------------------------------------------------- Plan hash value: 3611411408 ------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 3 | 300 | 2 (0)| 00:00:01 | |* 1 | VIEW | | 3 | 300 | 2 (0)| 00:00:01 | |* 2 | WINDOW NOSORT STOPKEY| | 3 | 117 | 2 (0)| 00:00:01 | | 3 | TABLE ACCESS FULL | EMP | 3 | 117 | 2 (0)| 00:00:01 | ------------------------------------------------------------------------------- Predicate Information (identified by operation id): --------------------------------------------------- 1 - filter("from$_subquery$_009"."rowlimit_$$_rownumber"<=3) 2 - filter(ROW_NUMBER() OVER ( ORDER BY NULL )<=3) 統計 ---------------------------------------------------------- 0 recursive calls 0 db block gets 3 consistent gets 0 physical reads 0 redo size 1262 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

おおおおおおおおおお〜っと. 2回目w　　マクロが展開されて, dept表の直接アクセスしている. （マクロだからそりゃそうだw）

1 SELECT 2 * 3 FROM 4* sq_macro_sample(2, dept) DEPTNO DNAME LOC ---------- ------------------------------------------ --------------------------------------- 10 ACCOUNTING NEW YORK 20 RESEARCH DALLAS 実行計画 ---------------------------------------------------------- Plan hash value: 3452784451 ------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 2 | 86 | 3 (0)| 00:00:01 | |* 1 | VIEW | | 2 | 86 | 3 (0)| 00:00:01 | |* 2 | WINDOW NOSORT STOPKEY| | 2 | 40 | 3 (0)| 00:00:01 | | 3 | TABLE ACCESS FULL | DEPT | 2 | 40 | 3 (0)| 00:00:01 | ------------------------------------------------------------------------------- Predicate Information (identified by operation id): --------------------------------------------------- 1 - filter("from$_subquery$_009"."rowlimit_$$_rownumber"<=2) 2 - filter(ROW_NUMBER() OVER ( ORDER BY NULL )<=2) 統計 ---------------------------------------------------------- 0 recursive calls 0 db block gets 3 consistent gets 0 physical reads 0 redo size 827 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) 2 rows processed

みなさん, SQL_MACRO, 実は, 物凄く, いいいやつ, っぽい感じがします. 慣れるまでは敷居高そうでもありますがw　
マニュアルを真面目に読んで, 倒れそうになりました. （斜め読みでは理解しきれない深さを感じます）

入門としては, HNakaieさんのエントリがわかりやすいですかね.
Oracle DatabaseのSQLマクロを検証する /

参考）
Oracle Database 21c Database PL/SQL Language Reference / 14.64 SQL_MACRO Clause

ということで, 　Happy Holidays中の方も, Hard Wroking Now!な方も, I wish you all a Merry Christmas.

そういえば, もう1週間以上前ですがw, アメリカのOracleの中の人からのメッセージが, Happy Holidays! で締めくくられていました.
日本人の感覚だと, え, と思わなくもないわけですが, アメリカとかだとそうだよねーーー. そう言う時期だよねーーと, 思いつつ,
アドベントカレンダー全部俺のネタ作りに追われているw　俺, なんなの？　みたいに思ったりw

では, アドベントカレンダー最終日の担当も, 私です.

ではまた.

Related article on Mac De Oracle

・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 1 / TABLE FULL SCAN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 2 / INDEX UNIQUE SCAN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 3 / INDEX RANGE SCAN, Index Only Scan
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 4 / INDEX RANGE SCAN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 5 / INDEX RANGE SCAN, INLIST ITERATOR
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 6 / INDEX FAST SCAN, Index Only Scan
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 7 / INDEX FULL SCAN,Index Only Scan
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 8 / INDEX SKIP SCAN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 9 / TABLE ACCESS INMEMORY FULL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 10 / NESTED LOOP JOIN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 11 / MERGE JOIN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 12 / HASH JOIN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 13 / HASH JOIN OUTER
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 14 / HASH JOIN FULL OUTER
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 15 / PX, TABLE ACCESS FULL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 16 / CONCATENATION
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 17 / SORT UNIQUE, UNION-ALL = UNION
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 18 / UNION-ALL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 19 / INTERSECTION
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 20 / MINUS
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 21 / WINDOW NOSORT STOPKEY
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 22 / COUNT STOPKEY
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 23 / HASH JOIN - LEFT-DEEP JOIN vs RIGHT-DEEP JOIN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 24 / CONNECT BY NO FILTERING WITH START-WITH
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 25 / UNION ALL (RECURSIVE WITH) DEPTH FIRST, RECURSIVE WITH PUMP
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#1 / STAR TRANSFORM, VECTOR TRANSFORM (DWH向け)
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#2 / MERGE (UPSERT)
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#3 / RDFView
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#4 / INDEX FULL SCAN (MIN/MAX) - Index Only Scan
・実行計画は, SQL文のレントゲン写真だ！ No.30 - LOAD TABLE CONVENTIONAL vs. LOAD AS SELECT
・実行計画は, SQL文のレントゲン写真だ！ No.31 - TEMP TABLE TRANSFORMATION LOAD AS SELECT (CURSOR DURATION MEMORY)
・実行計画は, SQL文のレントゲン写真だ！ No.32 - EXTERNAL TABLE ACCESS FULL / INMEMORY FULL
・実行計画は, SQL文のレントゲン写真だ！ No.33 - BITMAP CONVERSION TO ROWIDS
・実行計画は, SQL文のレントゲン写真だ！ No.34 - 似て非なるもの　USE_CONCAT　と　OR_EXPAND ヒントと　手書きSQLのレントゲンの見分け方
 ・実行計画は, SQL文のレントゲン写真だ！ No.35 - 似て非なるもの USE_CONCAT と OR_EXPANDヒントとパラレルクエリー
 ・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 1　/ No.36 / INTERSECT ALL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 2　/ No.37 / MINUS ALL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 3　/ No.38 / EXCEPT and EXCEPT ALL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 4 / No.39 / In-Memory Hybrid Scans
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 5 / No.40 / PIVOT and UNPIVOT
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 6 / No.41 / In-Memory Vectorized Join
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 7 / No.42 / INDEX RANGE SCAN (MULTI VALUE)
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 8 / No.43 / TABLE ACCESS BY INDEX ROWID BATCHED
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 9 / No.44 / COLLECTION ITERATOR PICKLER FETCH
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 10 / No.45 / MAT_VIEW REWRITE ACCESS FULL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 11 / No.46 / GROUPING SETS, ROLLUP, CUBE
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 12 / No.47 /　TEMP TABLE TRANSFORMATION
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 13 / No.48 / MULTI-TABLE INSERT
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 14 / No.49 / the DUAL Table
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 15 / No.50 / REMOTE
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 16 / No.51 / Concurrent Execution of Union All and Union
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 17 / No.52 / Order by Elimination
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 18 / No.53 / Join Elimination
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 19 / No.54 / Group by Elimination
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 20 / No.55 / DISTINCT Elimination
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 21 / No.56 / INLIST ITERATOR と Sub Query と STATISTICS COLLECTOR
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 22 / No.57 / Subquery Unnesting
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 23 / No.58 / ANTI JOIN

投稿日時 2022年12月24日 (土) 00時00分 Oracle, チューニング, SQL, パフォーマンス, Advent Calendar, 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

Related article on Mac De Oracle

・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 1 / TABLE FULL SCAN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 2 / INDEX UNIQUE SCAN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 3 / INDEX RANGE SCAN, Index Only Scan
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 4 / INDEX RANGE SCAN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 5 / INDEX RANGE SCAN, INLIST ITERATOR
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 6 / INDEX FAST SCAN, Index Only Scan
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 7 / INDEX FULL SCAN,Index Only Scan
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 8 / INDEX SKIP SCAN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 9 / TABLE ACCESS INMEMORY FULL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 10 / NESTED LOOP JOIN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 11 / MERGE JOIN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 12 / HASH JOIN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 13 / HASH JOIN OUTER
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 14 / HASH JOIN FULL OUTER
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 15 / PX, TABLE ACCESS FULL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 16 / CONCATENATION
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 17 / SORT UNIQUE, UNION-ALL = UNION
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 18 / UNION-ALL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 19 / INTERSECTION
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 20 / MINUS
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 21 / WINDOW NOSORT STOPKEY
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 22 / COUNT STOPKEY
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 23 / HASH JOIN - LEFT-DEEP JOIN vs RIGHT-DEEP JOIN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 24 / CONNECT BY NO FILTERING WITH START-WITH
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 25 / UNION ALL (RECURSIVE WITH) DEPTH FIRST, RECURSIVE WITH PUMP
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#1 / STAR TRANSFORM, VECTOR TRANSFORM (DWH向け)
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#2 / MERGE (UPSERT)
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#3 / RDFView
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#4 / INDEX FULL SCAN (MIN/MAX) - Index Only Scan
・実行計画は, SQL文のレントゲン写真だ！ No.30 - LOAD TABLE CONVENTIONAL vs. LOAD AS SELECT
・実行計画は, SQL文のレントゲン写真だ！ No.31 - TEMP TABLE TRANSFORMATION LOAD AS SELECT (CURSOR DURATION MEMORY)
・実行計画は, SQL文のレントゲン写真だ！ No.32 - EXTERNAL TABLE ACCESS FULL / INMEMORY FULL
・実行計画は, SQL文のレントゲン写真だ！ No.33 - BITMAP CONVERSION TO ROWIDS
・実行計画は, SQL文のレントゲン写真だ！ No.34 - 似て非なるもの　USE_CONCAT　と　OR_EXPAND ヒントと　手書きSQLのレントゲンの見分け方
 ・実行計画は, SQL文のレントゲン写真だ！ No.35 - 似て非なるもの USE_CONCAT と OR_EXPANDヒントとパラレルクエリー
 ・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 1　/ No.36 / INTERSECT ALL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 2　/ No.37 / MINUS ALL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 3　/ No.38 / EXCEPT and EXCEPT ALL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 4 / No.39 / In-Memory Hybrid Scans
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 5 / No.40 / PIVOT and UNPIVOT
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 6 / No.41 / In-Memory Vectorized Join
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 7 / No.42 / INDEX RANGE SCAN (MULTI VALUE)
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 8 / No.43 / TABLE ACCESS BY INDEX ROWID BATCHED
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 9 / No.44 / COLLECTION ITERATOR PICKLER FETCH
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 10 / No.45 / MAT_VIEW REWRITE ACCESS FULL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 11 / No.46 / GROUPING SETS, ROLLUP, CUBE
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 12 / No.47 /　TEMP TABLE TRANSFORMATION
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 13 / No.48 / MULTI-TABLE INSERT
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 14 / No.49 / the DUAL Table
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 15 / No.50 / REMOTE
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 16 / No.51 / Concurrent Execution of Union All and Union
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 17 / No.52 / Order by Elimination
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 18 / No.53 / Join Elimination
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 19 / No.54 / Group by Elimination
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 20 / No.55 / DISTINCT Elimination
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 21 / No.56 / INLIST ITERATOR と Sub Query と STATISTICS COLLECTOR
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 22 / No.57 / Subquery Unnesting

投稿日時 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）

では, また　:)

Related article on Mac De Oracle

・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 1 / TABLE FULL SCAN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 2 / INDEX UNIQUE SCAN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 3 / INDEX RANGE SCAN, Index Only Scan
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 4 / INDEX RANGE SCAN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 5 / INDEX RANGE SCAN, INLIST ITERATOR
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 6 / INDEX FAST SCAN, Index Only Scan
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 7 / INDEX FULL SCAN,Index Only Scan
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 8 / INDEX SKIP SCAN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 9 / TABLE ACCESS INMEMORY FULL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 10 / NESTED LOOP JOIN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 11 / MERGE JOIN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 12 / HASH JOIN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 13 / HASH JOIN OUTER
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 14 / HASH JOIN FULL OUTER
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 15 / PX, TABLE ACCESS FULL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 16 / CONCATENATION
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 17 / SORT UNIQUE, UNION-ALL = UNION
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 18 / UNION-ALL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 19 / INTERSECTION
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 20 / MINUS
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 21 / WINDOW NOSORT STOPKEY
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 22 / COUNT STOPKEY
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 23 / HASH JOIN - LEFT-DEEP JOIN vs RIGHT-DEEP JOIN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 24 / CONNECT BY NO FILTERING WITH START-WITH
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 25 / UNION ALL (RECURSIVE WITH) DEPTH FIRST, RECURSIVE WITH PUMP
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#1 / STAR TRANSFORM, VECTOR TRANSFORM (DWH向け)
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#2 / MERGE (UPSERT)
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#3 / RDFView
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#4 / INDEX FULL SCAN (MIN/MAX) - Index Only Scan
・実行計画は, SQL文のレントゲン写真だ！ No.30 - LOAD TABLE CONVENTIONAL vs. LOAD AS SELECT
・実行計画は, SQL文のレントゲン写真だ！ No.31 - TEMP TABLE TRANSFORMATION LOAD AS SELECT (CURSOR DURATION MEMORY)
・実行計画は, SQL文のレントゲン写真だ！ No.32 - EXTERNAL TABLE ACCESS FULL / INMEMORY FULL
・実行計画は, SQL文のレントゲン写真だ！ No.33 - BITMAP CONVERSION TO ROWIDS
・実行計画は, SQL文のレントゲン写真だ！ No.34 - 似て非なるもの　USE_CONCAT　と　OR_EXPAND ヒントと　手書きSQLのレントゲンの見分け方
 ・実行計画は, SQL文のレントゲン写真だ！ No.35 - 似て非なるもの USE_CONCAT と OR_EXPANDヒントとパラレルクエリー
 ・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 1　/ No.36 / INTERSECT ALL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 2　/ No.37 / MINUS ALL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 3　/ No.38 / EXCEPT and EXCEPT ALL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 4 / No.39 / In-Memory Hybrid Scans
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 5 / No.40 / PIVOT and UNPIVOT
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 6 / No.41 / In-Memory Vectorized Join
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 7 / No.42 / INDEX RANGE SCAN (MULTI VALUE)
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 8 / No.43 / TABLE ACCESS BY INDEX ROWID BATCHED
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 9 / No.44 / COLLECTION ITERATOR PICKLER FETCH
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 10 / No.45 / MAT_VIEW REWRITE ACCESS FULL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 11 / No.46 / GROUPING SETS, ROLLUP, CUBE
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 12 / No.47 /　TEMP TABLE TRANSFORMATION
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 13 / No.48 / MULTI-TABLE INSERT
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 14 / No.49 / the DUAL Table
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 15 / No.50 / REMOTE
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 16 / No.51 / Concurrent Execution of Union All and Union
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 17 / No.52 / Order by Elimination
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 18 / No.53 / Join Elimination
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 19 / No.54 / Group by Elimination
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 20 / No.55 / DISTINCT Elimination

投稿日時 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日。追い込みだーーーーっ
明日も、私が担当なので、よろしくお願いします。

Related article on Mac De Oracle
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 1 / TABLE FULL SCAN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 2 / INDEX UNIQUE SCAN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 3 / INDEX RANGE SCAN, Index Only Scan
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 4 / INDEX RANGE SCAN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 5 / INDEX RANGE SCAN, INLIST ITERATOR
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 6 / INDEX FAST SCAN, Index Only Scan
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 7 / INDEX FULL SCAN,Index Only Scan
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 8 / INDEX SKIP SCAN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 9 / TABLE ACCESS INMEMORY FULL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 10 / NESTED LOOP JOIN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 11 / MERGE JOIN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 12 / HASH JOIN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 13 / HASH JOIN OUTER
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 14 / HASH JOIN FULL OUTER
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 15 / PX, TABLE ACCESS FULL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 16 / CONCATENATION
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 17 / SORT UNIQUE, UNION-ALL = UNION
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 18 / UNION-ALL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 19 / INTERSECTION
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 20 / MINUS
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 21 / WINDOW NOSORT STOPKEY
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 22 / COUNT STOPKEY
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 23 / HASH JOIN - LEFT-DEEP JOIN vs RIGHT-DEEP JOIN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 24 / CONNECT BY NO FILTERING WITH START-WITH
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 25 / UNION ALL (RECURSIVE WITH) DEPTH FIRST, RECURSIVE WITH PUMP
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#1 / STAR TRANSFORM, VECTOR TRANSFORM (DWH向け)
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#2 / MERGE (UPSERT)
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#3 / RDFView
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#4 / INDEX FULL SCAN (MIN/MAX) - Index Only Scan
・実行計画は, SQL文のレントゲン写真だ！ No.30 - LOAD TABLE CONVENTIONAL vs. LOAD AS SELECT
・実行計画は, SQL文のレントゲン写真だ！ No.31 - TEMP TABLE TRANSFORMATION LOAD AS SELECT (CURSOR DURATION MEMORY)
・実行計画は, SQL文のレントゲン写真だ！ No.32 - EXTERNAL TABLE ACCESS FULL / INMEMORY FULL
・実行計画は, SQL文のレントゲン写真だ！ No.33 - BITMAP CONVERSION TO ROWIDS
・実行計画は, SQL文のレントゲン写真だ！ No.34 - 似て非なるもの　USE_CONCAT　と　OR_EXPAND ヒントと　手書きSQLのレントゲンの見分け方
 ・実行計画は, SQL文のレントゲン写真だ！ No.35 - 似て非なるもの USE_CONCAT と OR_EXPANDヒントとパラレルクエリー
 ・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 1　/ No.36 / INTERSECT ALL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 2　/ No.37 / MINUS ALL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 3　/ No.38 / EXCEPT and EXCEPT ALL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 4 / No.39 / In-Memory Hybrid Scans
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 5 / No.40 / PIVOT and UNPIVOT
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 6 / No.41 / In-Memory Vectorized Join
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 7 / No.42 / INDEX RANGE SCAN (MULTI VALUE)
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 8 / No.43 / TABLE ACCESS BY INDEX ROWID BATCHED
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 9 / No.44 / COLLECTION ITERATOR PICKLER FETCH
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 10 / No.45 / MAT_VIEW REWRITE ACCESS FULL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 11 / No.46 / GROUPING SETS, ROLLUP, CUBE
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 12 / No.47 /　TEMP TABLE TRANSFORMATION
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 13 / No.48 / MULTI-TABLE INSERT
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 14 / No.49 / the DUAL Table
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 15 / No.50 / REMOTE
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 16 / No.51 / Concurrent Execution of Union All and Union
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 17 / No.52 / Order by Elimination
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 18 / No.53 / Join Elimination
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 19 / No.54 / Group by Elimination

投稿日時 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月19日 (月)

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

このポストは, JPOUG Advent Calendar 2022 Day 19と帰ってきた！　実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺） Advent Calendar 2022へクロスポストしています.

JPOUG Advent Calendar 2022 Day 18は, tomoさんのSPM使ってる？でした. 使ってますか？ヒント埋込派, パッケージなんでSPMっす！とか大人の事情で色々ありそうですね.

Previously on Mac De Oracle... Day 18は, Join Elimination にフォーカスをあてました. Join Eliminationも他のElimination系書き換えは, 実行計画上存在が消されてしまうので, 実際行われたかどうか気づきにくいケースが多いです. 以前も書きましたが, Explain plan等で, Elimination Informationとかリストしてくれると便利かもしれません.

ということで, 今日, Day 19は, そんなElimination InformationがExplain plan等で表示されたら嬉しいかもね, という気持ちが強くなるネタにしました.

では, Day 19のお題, Group by Eliminationです.
この機能, 目立たないですが, 変なところで目立ったので意外に有名かもしれません. 機能として登場したのは, 12cR2ごろでした. Jonathanも書いてるから間違いない！

変なところで目立ってしまった. そんなに目立たない存在だった, Group by Eliminationの確認
目立ってしまった理由は, 結果不正. 　できれば7445の方が分かりやすくて良かったわけですが, 出会いたくないですよねー. 結果不正.
（なお, すでに修正されており, 想定する結果が返されるようになっているようです. 詳細は本ページ末の参考リンクのJonathanのエントリー参照のこと）

まず, 検証用のデータ準備から（ちょいと凝ったことやってますが, 単純に当年のカレンダーで, その日が営業日か休業日かをフラグで持たせるだけのでデータで, 2022年の一年分のデータを作りました. day18.sqlを実行していますが, こちらの都合w公開日を入れ替えた影響なので, 気にしないでくださいw

SCOTT@orclpdb1> @day18 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 表が変更されました.

今回は, この Order BY Elimination をちょっと有名にしてしまった, 結果不正から. 12cR2で試してみます. CASE 2の結果が想定と異なっています.

orcl@SCOTT> select banner from v$version; BANNER -------------------------------------------------------------------------------- Oracle Database 12c Enterprise Edition Release 12.2.0.1.0 - 64bit Production

CASE 1特に問題は起きていません. 想定通りの結果が帰り, Group By Eliminationの発動条件にはなっていないため, Group By操作が行われています.

1 SELECT 2 EXTRACT(MONTH from business_date) 3 , COUNT( 4 CASE 5 WHEN TO_CHAR( 6 business_date 7 , 'DY' 8 , 'NLS_DATE_LANGUAGE=AMERICAN' 9 ) IN ('SUN','WED') 10 THEN 1 11 END 12 ) AS holidays 13 FROM 14 business_day_calendar 15 GROUP BY 16* EXTRACT(MONTH from business_date) EXTRACT(MONTHFROMBUSINESS_DATE) HOLIDAYS ------------------------------- ---------- 1 9 6 9 11 9 2 8 4 8 5 9 8 9 3 9 7 9 9 8 10 9 12 8 12 rows selected. Execution Plan ---------------------------------------------------------- Plan hash value: 100882575 --------------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | --------------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 365 | 2920 | 2 (50)| 00:00:01 | | 1 | HASH GROUP BY | | 365 | 2920 | 2 (50)| 00:00:01 | | 2 | INDEX FULL SCAN| PK_BUSINESS_DAY_CALENDAR | 365 | 2920 | 1 (0)| 00:00:01 | ---------------------------------------------------------------------------------------------

CASE 2 おやおやおや, おかしなことになってます. 実行計画をみると, 動作対象ではないはずなのに, GROUP BY 操作が排除されているのが分かります！　結果不正です. HASH GROUP BYが排除されています！　その影響で, GROUP BYが行われていません！！！！

1 SELECT 2 TO_CHAR(business_date, 'YYYYMM') 3 , COUNT(1) 4 FROM 5 business_day_calendar 6 GROUP BY 7* TO_CHAR(business_date, 'YYYYMM') TO_CHA COUNT(1) ------ ---------- 202201 1 202201 1 202201 1 ...略... 202212 1 202212 1 202212 1 365 rows selected. Execution Plan ---------------------------------------------------------- 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 | ---------------------------------------------------------------------------------------------

CASE 2 の結果不正回避 では, 結果不正回避策を取ってみましょう. 何度か利用している, no_elim_groupbyヒントで回避できるか試します！
結果不正の理由は, 本来発動しない条件であるにもかかわらず発動してしまった　Group By Eliminationにる影響であることが分かります.

これをみると, なおさら, Explain Plan等でどのような書き換えが動作したのかしないのか一覧できるような情報が欲しいなと思ったりするわけです. .

orcl@SCOTT> @day18-2 1 SELECT 2 /*+ 3 no_elim_groupby 4 */ 5 TO_CHAR(business_date, 'YYYYMM') 6 , COUNT(1) 7 FROM 8 business_day_calendar 9 GROUP BY 10* TO_CHAR(business_date, 'YYYYMM') TO_CHA COUNT(1) ------ ---------- 202205 31 202209 30 202211 30 202212 31 202202 28 202208 31 202207 31 202210 31 202201 31 202204 30 202203 31 202206 30 12 rows selected. Execution Plan ---------------------------------------------------------- Plan hash value: 100882575 --------------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | --------------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 365 | 2920 | 2 (50)| 00:00:01 | | 1 | HASH GROUP BY | | 365 | 2920 | 2 (50)| 00:00:01 | | 2 | INDEX FULL SCAN| PK_BUSINESS_DAY_CALENDAR | 365 | 2920 | 1 (0)| 00:00:01 | ---------------------------------------------------------------------------------------------

CASE 3 こちらは正しく GROUP BY Eliminationが発動していますね. GROUP BYしなくても問題ないクエリですから！

1 SELECT 2 business_date 3 , COUNT(1) 4 FROM 5 business_day_calendar 6 GROUP BY 7* business_date BUSINESS_ COUNT(1) --------- ---------- 01-JAN-22 1 02-JAN-22 1 03-JAN-22 1 ...略... 29-DEC-22 1 30-DEC-22 1 31-DEC-22 1 365 rows selected. Execution Plan ---------------------------------------------------------- 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 | ---------------------------------------------------------------------------------------------

CASE 4 GROUP BY　Eliminationを無効化しても他のバージョンと結果同じで, 想定した結果通りです. CASE 3と結果は同じなのは当たり前.

1 SELECT 2 /*+ 3 no_elim_groupby 4 */ 5 business_date 6 , COUNT(1) 7 FROM 8 business_day_calendar 9 GROUP BY 10* business_date BUSINESS_ COUNT(1) --------- ---------- 01-JAN-22 1 02-JAN-22 1 03-JAN-22 1 ...略... 29-DEC-22 1 30-DEC-22 1 31-DEC-22 1 365 rows selected. Execution Plan ---------------------------------------------------------- Plan hash value: 3672056694 ------------------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ------------------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 365 | 2920 | 1 (0)| 00:00:01 | | 1 | SORT GROUP BY NOSORT| | 365 | 2920 | 1 (0)| 00:00:01 | | 2 | INDEX FULL SCAN | PK_BUSINESS_DAY_CALENDAR | 365 | 2920 | 1 (0)| 00:00:01 | -------------------------------------------------------------------------------------------------

では, 私が確認したテストケースの範囲で結果不正が起きていない, 21cは全テストケース, それ以外のバージョンでは, 結果不正の発生していた CASE 2　の実行計画という名のレントゲンを並べておきたいと思います. 頭に浮かんだイメージは, レントゲン写真を光るボードに沢山貼り付けてる感じw

Oracle Database 21cのCASE 1 - CASE 4まで全て

SCOTT@orclpdb1> select banner from v$version; BANNER ---------------------------------------------------------------------- Oracle Database 21c Enterprise Edition Release 21.0.0.0.0 - Production

CASE 1:Group By Eliminationは発生しないケース

1 SELECT 2 EXTRACT(MONTH from business_date) 3 , COUNT( 4 CASE 5 WHEN TO_CHAR( 6 business_date 7 , 'DY' 8 , 'NLS_DATE_LANGUAGE=AMERICAN' 9 ) IN ('SUN','WED') 10 THEN 1 11 END 12 ) AS holidays 13 FROM 14 business_day_calendar 15 GROUP BY 16* EXTRACT(MONTH from business_date) EXTRACT(MONTHFROMBUSINESS_DATE) HOLIDAYS ------------------------------- ---------- 1 9 2 8 3 9 4 8 5 9 6 9 7 9 8 9 9 8 10 9 11 9 12 8 12行が選択されました. 実行計画 ---------------------------------------------------------- Plan hash value: 100882575 --------------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | --------------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 365 | 2920 | 2 (50)| 00:00:01 | | 1 | HASH GROUP BY | | 365 | 2920 | 2 (50)| 00:00:01 | | 2 | INDEX FULL SCAN| PK_BUSINESS_DAY_CALENDAR | 365 | 2920 | 1 (0)| 00:00:01 | ---------------------------------------------------------------------------------------------

CASE 2:Group By Eliminationは発生しないケース(12cR2でGroup By Eliminationの誤作動で結果不正となったテストケース)

1 SELECT 2 TO_CHAR(business_date, 'YYYYMM') 3 , COUNT(1) 4 FROM 5 business_day_calendar 6 GROUP BY 7* TO_CHAR(business_date, 'YYYYMM') TO_CHAR(BUSINESS_D COUNT(1) ------------------ ---------- 202201 31 202202 28 202203 31 202204 30 202205 31 202206 30 202207 31 202208 31 202209 30 202210 31 202211 30 202212 31 12行が選択されました. 実行計画 ---------------------------------------------------------- Plan hash value: 100882575 --------------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | --------------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 365 | 2920 | 2 (50)| 00:00:01 | | 1 | HASH GROUP BY | | 365 | 2920 | 2 (50)| 00:00:01 | | 2 | INDEX FULL SCAN| PK_BUSINESS_DAY_CALENDAR | 365 | 2920 | 1 (0)| 00:00:01 | ---------------------------------------------------------------------------------------------

CASE 3:Group By Eliminationが発生するケース

1 SELECT 2 business_date 3 , COUNT(1) 4 FROM 5 business_day_calendar 6 GROUP BY 7* business_date BUSINESS_DATE COUNT(1) --------------- ---------- 20220101 000000 1 20220102 000000 1 20220103 000000 1 ...略... 20221228 000000 1 20221229 000000 1 20221230 000000 1 20221231 000000 1 365行が選択されました. 経過: 00:00:00.01 実行計画 ---------------------------------------------------------- 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 | ---------------------------------------------------------------------------------------------

CASE 4:Group By Eliminationが発生するケースで, no_elim_groupby　ヒントでGroup By Eliminationを抑止したケース

1 SELECT 2 /*+ 3 no_elim_groupby 4 */ 5 business_date 6 , COUNT(1) 7 FROM 8 business_day_calendar 9 GROUP BY 10* business_date BUSINESS_DATE COUNT(1) --------------- ---------- 20220101 000000 1 20220102 000000 1 20220103 000000 1 20220104 000000 1 ...略... 20221228 000000 1 20221229 000000 1 20221230 000000 1 20221231 000000 1 365行が選択されました. 実行計画 ---------------------------------------------------------- Plan hash value: 3672056694 ------------------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ------------------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 365 | 2920 | 1 (0)| 00:00:01 | | 1 | SORT GROUP BY NOSORT| | 365 | 2920 | 1 (0)| 00:00:01 | | 2 | INDEX FULL SCAN | PK_BUSINESS_DAY_CALENDAR | 365 | 2920 | 1 (0)| 00:00:01 | -------------------------------------------------------------------------------------------------

Oracle Database 19cです. CASE 2だけ確認します.

SCOTT@orcl> select banner from v$version; BANNER -------------------------------------------------------------------------------- Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production

CASE 2:このリリースでも問題は無さそうですね

1 SELECT 2 TO_CHAR(business_date, 'YYYYMM') 3 , COUNT(1) 4 FROM 5 business_day_calendar 6 GROUP BY 7* TO_CHAR(business_date, 'YYYYMM') TO_CHA COUNT(1) ------ ---------- 202206 30 202203 31 202210 31 202212 31 202202 28 202211 30 202204 30 202208 31 202209 30 202201 31 202205 31 202207 31 12 rows selected. Execution Plan ---------------------------------------------------------- Plan hash value: 100882575 --------------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | --------------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 365 | 2920 | 2 (50)| 00:00:01 | | 1 | HASH GROUP BY | | 365 | 2920 | 2 (50)| 00:00:01 | | 2 | INDEX FULL SCAN| PK_BUSINESS_DAY_CALENDAR | 365 | 2920 | 1 (0)| 00:00:01 | ---------------------------------------------------------------------------------------------

Oracle Database 18c です. 同様に, CASE 2のみ確認しています.

SCOTT> select banner from v$version; BANNER -------------------------------------------------------------------------------- Oracle Database 18c Enterprise Edition Release 18.0.0.0.0 - Production

CASE 2:このリリースでも問題は無さそう

1 SELECT 2 TO_CHAR(business_date, 'YYYYMM') 3 , COUNT(1) 4 FROM 5 business_day_calendar 6 GROUP BY 7* TO_CHAR(business_date, 'YYYYMM') TO_CHA COUNT(1) ------ ---------- 202206 30 202203 31 202210 31 202212 31 202202 28 202211 30 202204 30 202208 31 202209 30 202201 31 202205 31 202207 31 12 rows selected. Execution Plan ---------------------------------------------------------- Plan hash value: 100882575 --------------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | --------------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 365 | 2920 | 2 (50)| 00:00:01 | | 1 | HASH GROUP BY | | 365 | 2920 | 2 (50)| 00:00:01 | | 2 | INDEX FULL SCAN| PK_BUSINESS_DAY_CALENDAR | 365 | 2920 | 1 (0)| 00:00:01 | ---------------------------------------------------------------------------------------------

ちょっと思ったのですが, 現状, 10053トレース等をみるしかないタイプの書き換えでも, OTHER_XML列からOUTLINEを抜き出すと比較的簡単に発動有無がわかるものもあるかもしれないですね. 今回のように固有のヒントでON/OFFできるタイプだとOUTLINEには, elim_groupby のようなヒントが含まれているだろうし. （全てではないとは思いますが）

ふ〜〜〜っ. JPOUG Advent Calendar 2022 の自分のターンも終わって, 自分の分をなんとかするだけだーーーーー.

ということで,
帰ってきた！　実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺） Advent Calendar 2022は, 明日も私が担当です. よろしくお願いします.
そして, JPOUG Advent Calendar 2022 Day 20は, 凌直孝さんの担当です. よろしくお願いします！

では, また:)

参考）

Group by Elimination / Oracle Scratchpad
A Look at the Oracle Group-by Bug / Database Journal

Related article on Mac De Oracle
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 1 / TABLE FULL SCAN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 2 / INDEX UNIQUE SCAN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 3 / INDEX RANGE SCAN, Index Only Scan
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 4 / INDEX RANGE SCAN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 5 / INDEX RANGE SCAN, INLIST ITERATOR
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 6 / INDEX FAST SCAN, Index Only Scan
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 7 / INDEX FULL SCAN,Index Only Scan
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 8 / INDEX SKIP SCAN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 9 / TABLE ACCESS INMEMORY FULL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 10 / NESTED LOOP JOIN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 11 / MERGE JOIN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 12 / HASH JOIN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 13 / HASH JOIN OUTER
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 14 / HASH JOIN FULL OUTER
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 15 / PX, TABLE ACCESS FULL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 16 / CONCATENATION
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 17 / SORT UNIQUE, UNION-ALL = UNION
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 18 / UNION-ALL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 19 / INTERSECTION
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 20 / MINUS
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 21 / WINDOW NOSORT STOPKEY
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 22 / COUNT STOPKEY
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 23 / HASH JOIN - LEFT-DEEP JOIN vs RIGHT-DEEP JOIN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 24 / CONNECT BY NO FILTERING WITH START-WITH
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 25 / UNION ALL (RECURSIVE WITH) DEPTH FIRST, RECURSIVE WITH PUMP
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#1 / STAR TRANSFORM, VECTOR TRANSFORM (DWH向け)
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#2 / MERGE (UPSERT)
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#3 / RDFView
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#4 / INDEX FULL SCAN (MIN/MAX) - Index Only Scan
・実行計画は, SQL文のレントゲン写真だ！ No.30 - LOAD TABLE CONVENTIONAL vs. LOAD AS SELECT
・実行計画は, SQL文のレントゲン写真だ！ No.31 - TEMP TABLE TRANSFORMATION LOAD AS SELECT (CURSOR DURATION MEMORY)
・実行計画は, SQL文のレントゲン写真だ！ No.32 - EXTERNAL TABLE ACCESS FULL / INMEMORY FULL
・実行計画は, SQL文のレントゲン写真だ！ No.33 - BITMAP CONVERSION TO ROWIDS
・実行計画は, SQL文のレントゲン写真だ！ No.34 - 似て非なるもの　USE_CONCAT　と　OR_EXPAND ヒントと　手書きSQLのレントゲンの見分け方
 ・実行計画は, SQL文のレントゲン写真だ！ No.35 - 似て非なるもの USE_CONCAT と OR_EXPANDヒントとパラレルクエリー
 ・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 1　/ No.36 / INTERSECT ALL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 2　/ No.37 / MINUS ALL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 3　/ No.38 / EXCEPT and EXCEPT ALL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 4 / No.39 / In-Memory Hybrid Scans
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 5 / No.40 / PIVOT and UNPIVOT
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 6 / No.41 / In-Memory Vectorized Join
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 7 / No.42 / INDEX RANGE SCAN (MULTI VALUE)
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 8 / No.43 / TABLE ACCESS BY INDEX ROWID BATCHED
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 9 / No.44 / COLLECTION ITERATOR PICKLER FETCH
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 10 / No.45 / MAT_VIEW REWRITE ACCESS FULL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 11 / No.46 / GROUPING SETS, ROLLUP, CUBE
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 12 / No.47 /　TEMP TABLE TRANSFORMATION
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 13 / No.48 / MULTI-TABLE INSERT
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 14 / No.49 / the DUAL Table
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 15 / No.50 / REMOTE
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 16 / No.51 / Concurrent Execution of Union All and Union
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 17 / No.52 / Order by Elimination
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 18 / No.53 / Join Elimination

投稿日時 2022年12月19日 (月) 00時00分 Oracle, チューニング, SQL, 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チューニングの「参照整合性制約アレルギー」を参照のこと

Related article on Mac De Oracle

・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 1 / TABLE FULL SCAN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 2 / INDEX UNIQUE SCAN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 3 / INDEX RANGE SCAN, Index Only Scan
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 4 / INDEX RANGE SCAN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 5 / INDEX RANGE SCAN, INLIST ITERATOR
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 6 / INDEX FAST SCAN, Index Only Scan
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 7 / INDEX FULL SCAN,Index Only Scan
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 8 / INDEX SKIP SCAN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 9 / TABLE ACCESS INMEMORY FULL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 10 / NESTED LOOP JOIN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 11 / MERGE JOIN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 12 / HASH JOIN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 13 / HASH JOIN OUTER
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 14 / HASH JOIN FULL OUTER
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 15 / PX, TABLE ACCESS FULL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 16 / CONCATENATION
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 17 / SORT UNIQUE, UNION-ALL = UNION
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 18 / UNION-ALL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 19 / INTERSECTION
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 20 / MINUS
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 21 / WINDOW NOSORT STOPKEY
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 22 / COUNT STOPKEY
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 23 / HASH JOIN - LEFT-DEEP JOIN vs RIGHT-DEEP JOIN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 24 / CONNECT BY NO FILTERING WITH START-WITH
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 25 / UNION ALL (RECURSIVE WITH) DEPTH FIRST, RECURSIVE WITH PUMP
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#1 / STAR TRANSFORM, VECTOR TRANSFORM (DWH向け)
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#2 / MERGE (UPSERT)
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#3 / RDFView
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#4 / INDEX FULL SCAN (MIN/MAX) - Index Only Scan
・実行計画は, SQL文のレントゲン写真だ！ No.30 - LOAD TABLE CONVENTIONAL vs. LOAD AS SELECT
・実行計画は, SQL文のレントゲン写真だ！ No.31 - TEMP TABLE TRANSFORMATION LOAD AS SELECT (CURSOR DURATION MEMORY)
・実行計画は, SQL文のレントゲン写真だ！ No.32 - EXTERNAL TABLE ACCESS FULL / INMEMORY FULL
・実行計画は, SQL文のレントゲン写真だ！ No.33 - BITMAP CONVERSION TO ROWIDS
・実行計画は, SQL文のレントゲン写真だ！ No.34 - 似て非なるもの　USE_CONCAT　と　OR_EXPAND ヒントと　手書きSQLのレントゲンの見分け方
 ・実行計画は, SQL文のレントゲン写真だ！ No.35 - 似て非なるもの USE_CONCAT と OR_EXPANDヒントとパラレルクエリー
 ・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 1　/ No.36 / INTERSECT ALL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 2　/ No.37 / MINUS ALL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 3　/ No.38 / EXCEPT and EXCEPT ALL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 4 / No.39 / In-Memory Hybrid Scans
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 5 / No.40 / PIVOT and UNPIVOT
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 6 / No.41 / In-Memory Vectorized Join
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 7 / No.42 / INDEX RANGE SCAN (MULTI VALUE)
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 8 / No.43 / TABLE ACCESS BY INDEX ROWID BATCHED
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 9 / No.44 / COLLECTION ITERATOR PICKLER FETCH
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 10 / No.45 / MAT_VIEW REWRITE ACCESS FULL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 11 / No.46 / GROUPING SETS, ROLLUP, CUBE
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 12 / No.47 /　TEMP TABLE TRANSFORMATION
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 13 / No.48 / MULTI-TABLE INSERT
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 14 / No.49 / the DUAL Table
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 15 / No.50 / REMOTE
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 16 / No.51 / Concurrent Execution of Union All and Union
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 17 / No.52 / Order by Elimination

投稿日時 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月17日 (土)

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

Previously on Mac De Oracle... Day 16は, Concurrent Execution of Union All and Union にフォーカスをあてました. 使う機会があったら試してみてくださいね. 私は, この機能が登場した頃, Spatialな機能でRDFを使った際, Exadataでバリバリ活用してたというか, されていたという記憶があります.

では, Day 17のお題, Order by Eliminationです. 文字通り, Order byが排除される, 書き換え機能の一種です. だからと言って, 無駄なOrder by句書いても大丈夫ってことではないですから, 注意しましょうw

10gR2ぐらいから実装されている最適化の一つですね. 多少無駄なOrder byを書いちゃっても無駄だと判断されれば, 行われません. （だからと言って, 気にしないでOrder By書いちゃってもいいという話ではありませんがw）

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

SCOTT@orclpdb1> select banner from v$version; BANNER ---------------------------------------------------------------------- Oracle Database 21c Enterprise Edition Release 21.0.0.0.0 - Production

emp表の索引などはいかの通り（scottのemp表を知らない方向け. いるのか？）

SCOTT@orclpdb1> desc emp 名前 NULL? 型 ----------------------------------------- -------- ---------------------------- EMPNO NOT NULL NUMBER(4) ENAME VARCHAR2(10) JOB VARCHAR2(9) MGR NUMBER(4) HIREDATE DATE SAL NUMBER(7,2) COMM NUMBER(7,2) DEPTNO NUMBER(2) SCOTT@orclpdb1> select index_name,column_name from user_ind_columns where 2 table_name = 'EMP' order by index_name,column_position; INDEX_NAME COLUMN_NAME ------------------------------ ------------------------------ IX01_EMP DEPTNO PK_EMP EMPNO

SQL中に ORDER BY句がありますが, NOSORT操作もないのにソートされていません. そもそも書き換えられて, ORDER BY句が削除されているんですよーーーー.
このケースでは, empno順にソートされた結果返ってきているかのう様に見えますが, それは索引をempno順に読無ことで, ソートを排除できるからなんですよね. 索引がなければ, ソートは必要なのです. ちなみに, INDEX FULL SCAN はソートされたキー順に索引を全てスキャンするところがポイント, INDEX FAST FULL SCANはとは違うのはみなさんご存知のはずなのでコマけーことは省略.

SCOTT@orclpdb1> @day17 1 SELECT 2 * 3 FROM 4 emp 5 ORDER BY 6* empno 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 7521 WARD SALESMAN 7698 81-02-22 1250 500 30 7566 JONES MANAGER 7839 81-04-02 2975 20 7654 MARTIN SALESMAN 7698 81-09-28 1250 1400 30 7698 BLAKE MANAGER 7839 81-05-01 2850 30 7782 CLARK MANAGER 7839 81-06-09 2450 10 7839 KING PRESIDENT 81-11-17 5000 10 7844 TURNER SALESMAN 7698 81-09-08 1500 0 30 7900 JAMES CLERK 7698 81-12-03 950 30 7902 FORD ANALYST 7566 81-12-03 3000 20 7934 MILLER CLERK 7782 82-01-23 1300 10 実行計画 ---------------------------------------------------------- Plan hash value: 4170700152 -------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | -------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 12 | 468 | 2 (0)| 00:00:01 | | 1 | TABLE ACCESS BY INDEX ROWID| EMP | 12 | 468 | 2 (0)| 00:00:01 | | 2 | INDEX FULL SCAN | PK_EMP | 12 | | 1 (0)| 00:00:01 | -------------------------------------------------------------------------------------- 統計 ---------------------------------------------------------- 0 recursive calls 0 db block gets 4 consistent gets 0 physical reads 0 redo size 1669 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) 12 rows processed

こちらも, 無用なORDER BY句が削除されています. 賢い. オプティマイザー！
以下のORDER BYは, みるからに無駄なソートですが, オプティマイザーは気づいて排除しています.

1 SELECT 2 COUNT(ename) 3 FROM 4 ( 5 SELECT 6 * 7 FROM 8 emp 9 ORDER BY 10 ename 11* ) COUNT(ENAME) ------------ 12 実行計画 ---------------------------------------------------------- Plan hash value: 2083865914 --------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | --------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 1 | 6 | 3 (0)| 00:00:01 | | 1 | SORT AGGREGATE | | 1 | 6 | | | | 2 | TABLE ACCESS FULL| EMP | 12 | 72 | 3 (0)| 00:00:01 | --------------------------------------------------------------------------- 統計 ---------------------------------------------------------- 0 recursive calls 0 db block gets 6 consistent gets 0 physical reads 0 redo size 595 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

EXPLAIN等改善してほしいなと思うのはこれらのElimination関連情報, 今回のように無駄なORDER BYを排除したという情報を, Elimination Informationとしてリストしたら良いのではないかと思っています. 最近, SQLヒントに関する情報をリストするようになったのでできるのではないだろうかと. ただ, 諸々内部でSQL文を書き換えたりするから, 実は面倒なのかもねw 　10053トレースなら見える訳ですが, 毎回取得するわけにもいかないしね.

ついに, 　Day 17 done. あと少しだ頑張れ, 俺w

ということで, 残念ですが, 明日も私です.
ではまた.

Related article on Mac De Oracle
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 1 / TABLE FULL SCAN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 2 / INDEX UNIQUE SCAN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 3 / INDEX RANGE SCAN, Index Only Scan
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 4 / INDEX RANGE SCAN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 5 / INDEX RANGE SCAN, INLIST ITERATOR
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 6 / INDEX FAST SCAN, Index Only Scan
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 7 / INDEX FULL SCAN,Index Only Scan
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 8 / INDEX SKIP SCAN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 9 / TABLE ACCESS INMEMORY FULL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 10 / NESTED LOOP JOIN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 11 / MERGE JOIN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 12 / HASH JOIN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 13 / HASH JOIN OUTER
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 14 / HASH JOIN FULL OUTER
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 15 / PX, TABLE ACCESS FULL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 16 / CONCATENATION
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 17 / SORT UNIQUE, UNION-ALL = UNION
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 18 / UNION-ALL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 19 / INTERSECTION
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 20 / MINUS
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 21 / WINDOW NOSORT STOPKEY
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 22 / COUNT STOPKEY
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 23 / HASH JOIN - LEFT-DEEP JOIN vs RIGHT-DEEP JOIN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 24 / CONNECT BY NO FILTERING WITH START-WITH
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 25 / UNION ALL (RECURSIVE WITH) DEPTH FIRST, RECURSIVE WITH PUMP
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#1 / STAR TRANSFORM, VECTOR TRANSFORM (DWH向け)
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#2 / MERGE (UPSERT)
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#3 / RDFView
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#4 / INDEX FULL SCAN (MIN/MAX) - Index Only Scan
・実行計画は, SQL文のレントゲン写真だ！ No.30 - LOAD TABLE CONVENTIONAL vs. LOAD AS SELECT
・実行計画は, SQL文のレントゲン写真だ！ No.31 - TEMP TABLE TRANSFORMATION LOAD AS SELECT (CURSOR DURATION MEMORY)
・実行計画は, SQL文のレントゲン写真だ！ No.32 - EXTERNAL TABLE ACCESS FULL / INMEMORY FULL
・実行計画は, SQL文のレントゲン写真だ！ No.33 - BITMAP CONVERSION TO ROWIDS
・実行計画は, SQL文のレントゲン写真だ！ No.34 - 似て非なるもの　USE_CONCAT　と　OR_EXPAND ヒントと　手書きSQLのレントゲンの見分け方
 ・実行計画は, SQL文のレントゲン写真だ！ No.35 - 似て非なるもの USE_CONCAT と OR_EXPANDヒントとパラレルクエリー
 ・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 1　/ No.36 / INTERSECT ALL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 2　/ No.37 / MINUS ALL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 3　/ No.38 / EXCEPT and EXCEPT ALL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 4 / No.39 / In-Memory Hybrid Scans
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 5 / No.40 / PIVOT and UNPIVOT
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 6 / No.41 / In-Memory Vectorized Join
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 7 / No.42 / INDEX RANGE SCAN (MULTI VALUE)
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 8 / No.43 / TABLE ACCESS BY INDEX ROWID BATCHED
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 9 / No.44 / COLLECTION ITERATOR PICKLER FETCH
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 10 / No.45 / MAT_VIEW REWRITE ACCESS FULL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 11 / No.46 / GROUPING SETS, ROLLUP, CUBE
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 12 / No.47 /　TEMP TABLE TRANSFORMATION
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 13 / No.48 / MULTI-TABLE INSERT
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 14 / No.49 / the DUAL Table
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 15 / No.50 / REMOTE
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 16 / No.51 / Concurrent Execution of Union All and Union

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

2022年12月16日 (金)

実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 16 / No.51 / Concurrent Execution of Union All and Union

Previously on Mac De Oracle... Day 15は, 分散, リモートクエリーにフォーカスをあてました. 好き嫌い多いネタだったかもしれませんねぇw

では, Day 16のお題, Concurrent Execution of Union All and Union

これは何かというと, 12c R1以降だったか？（定かでないw）に, UNION/UNION ALLの各分岐がパラレルで実行されるという機能です. それまではシリアルに処理されていたので, 分岐が多いほど処理時間も増加していた訳ですが, 分岐がそれぞれパラレルで実行される分処理時間は短くなるというやつですね.

Concurrent Execution of Union All and Unionが実行されている時の特徴は, PX SELECTOR　があるかどうかで見分けます.

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

SCOTT@orclpdb1> select banner from v$version; BANNER ---------------------------------------------------------------------- Oracle Database 21c Enterprise Edition Release 21.0.0.0.0 - Production

準備として, 12c R1以前ではシリアルに処理される代表格, リモート表を用意します. （昨日のネタはこの準備のためでもあったり）

SCOTT@orclpdb2> @day16 1* CREATE DATABASE LINK remote_scott CONNECT TO scott IDENTIFIED BY tiger USING 'orclpdb1' データベース・リンクが作成されました. 1 CREATE TABLE local_emp 2 AS 3 SELECT * 4 FROM 5 emp@remote_scott 6 ORDER BY 7 empno 8* FETCH FIRST 5 ROWS ONLY 表が作成されました. 1* INSERT INTO local_emp(empno, ename) VALUES(1, 'NULL') 1行が作成されました.

クエリーの結果、たまたま、empno順に並んでいるように見える結果もありますが、ソートしたい場合は、必ず！！！　ORDER BY句が必要ですからねw（誰となくw）

シリアルで実行してみます. よく見る実行計画という名のレントゲンです. リモート表は Operationが　REMOTE　として現れています. 2つある分岐は, シリアルに実行されます.

1 SELECT 2 * 3 FROM 4 local_emp 5 UNION ALL 6 SELECT 7 * 8 FROM 9* emp@remote_scott 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 7521 WARD SALESMAN 7698 81-02-22 1250 500 30 7566 JONES MANAGER 7839 81-04-02 2975 20 7654 MARTIN SALESMAN 7698 81-09-28 1250 1400 30 1 NULL 7369 SMITH CLERK 7902 80-12-17 800 20 7499 ALLEN SALESMAN 7698 81-02-20 1600 300 30 7521 WARD SALESMAN 7698 81-02-22 1250 500 30 7566 JONES MANAGER 7839 81-04-02 2975 20 7654 MARTIN SALESMAN 7698 81-09-28 1250 1400 30 7698 BLAKE MANAGER 7839 81-05-01 2850 30 7782 CLARK MANAGER 7839 81-06-09 2450 10 7839 KING PRESIDENT 81-11-17 5000 10 7844 TURNER SALESMAN 7698 81-09-08 1500 0 30 7900 JAMES CLERK 7698 81-12-03 950 30 7902 FORD ANALYST 7566 81-12-03 3000 20 7934 MILLER CLERK 7782 82-01-23 1300 10 実行計画 ---------------------------------------------------------- Plan hash value: 1607333107 ------------------------------------------------------------------------------------------------ | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Inst |IN-OUT| ------------------------------------------------------------------------------------------------ | 0 | SELECT STATEMENT | | 18 | 990 | 5 (0)| 00:00:01 | | | | 1 | UNION-ALL | | | | | | | | | 2 | TABLE ACCESS FULL| LOCAL_EMP | 6 | 522 | 2 (0)| 00:00:01 | | | | 3 | REMOTE | EMP | 12 | 468 | 3 (0)| 00:00:01 | REMOT~ | R->S | ------------------------------------------------------------------------------------------------ Remote SQL Information (identified by operation id): ---------------------------------------------------- 3 - SELECT "EMPNO","ENAME","JOB","MGR","HIREDATE","SAL","COMM","DEPTNO" FROM "EMP" "EMP" (accessing 'REMOTE_SCOTT' ) Note ----- - dynamic statistics used: dynamic sampling (level=2)

次に, パラレルクエリーにして, かつ, Concurrent Execution を抑止する　NO_PQ_CONCURRENT_UNION 　を付加して実行してみました.
PX SELECTOR は現れていません. パラレルクエリーではありますが, 分岐は, 順に処理されていきます.

1 SELECT 2 /*+ 3 PARALLEL(3) 4 NO_PQ_CONCURRENT_UNION 5 */ 6 * 7 FROM 8 local_emp 9 UNION ALL 10 SELECT 11 * 12 FROM 13* emp@remote_scott 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 7521 WARD SALESMAN 7698 81-02-22 1250 500 30 7566 JONES MANAGER 7839 81-04-02 2975 20 7654 MARTIN SALESMAN 7698 81-09-28 1250 1400 30 1 NULL 7369 SMITH CLERK 7902 80-12-17 800 20 7499 ALLEN SALESMAN 7698 81-02-20 1600 300 30 7521 WARD SALESMAN 7698 81-02-22 1250 500 30 7566 JONES MANAGER 7839 81-04-02 2975 20 7654 MARTIN SALESMAN 7698 81-09-28 1250 1400 30 7698 BLAKE MANAGER 7839 81-05-01 2850 30 7782 CLARK MANAGER 7839 81-06-09 2450 10 7839 KING PRESIDENT 81-11-17 5000 10 7844 TURNER SALESMAN 7698 81-09-08 1500 0 30 7900 JAMES CLERK 7698 81-12-03 950 30 7902 FORD ANALYST 7566 81-12-03 3000 20 7934 MILLER CLERK 7782 82-01-23 1300 10 実行計画 ---------------------------------------------------------- Plan hash value: 3305250800 ---------------------------------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | TQ/Ins |IN-OUT| PQ Distrib | ---------------------------------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 18 | 990 | 5 (0)| 00:00:01 | | | | | 1 | UNION-ALL | | | | | | | | | | 2 | PX COORDINATOR | | | | | | | | | | 3 | PX SEND QC (RANDOM)| :TQ10000 | 6 | 522 | 2 (0)| 00:00:01 | Q1,00 | P->S | QC (RAND) | | 4 | PX BLOCK ITERATOR | | 6 | 522 | 2 (0)| 00:00:01 | Q1,00 | PCWC | | | 5 | TABLE ACCESS FULL| LOCAL_EMP | 6 | 522 | 2 (0)| 00:00:01 | Q1,00 | PCWP | | | 6 | REMOTE | EMP | 12 | 468 | 3 (0)| 00:00:01 | REMOT~ | R->S | | ---------------------------------------------------------------------------------------------------------------- Remote SQL Information (identified by operation id): ---------------------------------------------------- 6 - SELECT /*+ SHARED (3) */ "EMPNO","ENAME","JOB","MGR","HIREDATE","SAL","COMM","DEPTNO" FROM "EMP" "EMP" (accessing 'REMOTE_SCOTT' ) Note ----- - dynamic statistics used: dynamic sampling (level=2) - Degree of Parallelism is 3 because of hint

本日の主役　PX SELECTOR が REMOTE 操作の上に出てきました. この状態であれば, 各分岐はパラレルに処理されることになり, 分岐が順に処理されるより処理時間は短縮されることになります（REMOTE処理が重かったら, その処理時間に引きづら訳ですが, 順に処理するよりは早く終わると予想できますよね）

1 SELECT 2 /*+ 3 PARALLEL(3) 4 */ 5 * 6 FROM 7 local_emp 8 UNION ALL 9 SELECT 10 * 11 FROM 12* emp@remote_scott EMPNO ENAME JOB MGR HIREDATE SAL COMM DEPTNO ---------- ------------------------------ --------------------------- ---------- -------- ---------- ---------- ---------- 1 NULL 7369 SMITH CLERK 7902 80-12-17 800 20 7499 ALLEN SALESMAN 7698 81-02-20 1600 300 30 7521 WARD SALESMAN 7698 81-02-22 1250 500 30 7566 JONES MANAGER 7839 81-04-02 2975 20 7654 MARTIN SALESMAN 7698 81-09-28 1250 1400 30 7369 SMITH CLERK 7902 80-12-17 800 20 7499 ALLEN SALESMAN 7698 81-02-20 1600 300 30 7521 WARD SALESMAN 7698 81-02-22 1250 500 30 7566 JONES MANAGER 7839 81-04-02 2975 20 7654 MARTIN SALESMAN 7698 81-09-28 1250 1400 30 7698 BLAKE MANAGER 7839 81-05-01 2850 30 7782 CLARK MANAGER 7839 81-06-09 2450 10 7839 KING PRESIDENT 81-11-17 5000 10 7844 TURNER SALESMAN 7698 81-09-08 1500 0 30 7900 JAMES CLERK 7698 81-12-03 950 30 7902 FORD ANALYST 7566 81-12-03 3000 20 7934 MILLER CLERK 7782 82-01-23 1300 10 実行計画 ---------------------------------------------------------- Plan hash value: 2359762278 ---------------------------------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | TQ |IN-OUT| PQ Distrib | ---------------------------------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 18 | 990 | 5 (0)| 00:00:01 | | | | | 1 | PX COORDINATOR | | | | | | | | | | 2 | PX SEND QC (RANDOM) | :TQ10000 | | | | | Q1,00 | P->S | QC (RAND) | | 3 | UNION-ALL | | | | | | Q1,00 | PCWP | | | 4 | PX BLOCK ITERATOR | | 6 | 522 | 2 (0)| 00:00:01 | Q1,00 | PCWC | | | 5 | TABLE ACCESS FULL| LOCAL_EMP | 6 | 522 | 2 (0)| 00:00:01 | Q1,00 | PCWP | | | 6 | PX SELECTOR | | | | | | Q1,00 | PCWP | | | 7 | REMOTE | EMP | 12 | 468 | 3 (0)| 00:00:01 | Q1,00 | PCWP | | ---------------------------------------------------------------------------------------------------------------- Remote SQL Information (identified by operation id): ---------------------------------------------------- 7 - SELECT /*+ SHARED (3) */ "EMPNO","ENAME","JOB","MGR","HIREDATE","SAL","COMM","DEPTNO" FROM "EMP" "EMP" (accessing ':Q1000' ) Note ----- - dynamic statistics used: dynamic sampling (level=2) - Degree of Parallelism is 3 because of hint

以下, UNIONでも同様に, 実行計画というレントゲンを確認しておきましょう. まずはシリアル.

1 SELECT 2 * 3 FROM 4 local_emp 5 UNION 6 SELECT 7 * 8 FROM 9* emp@remote_scott 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 7521 WARD SALESMAN 7698 81-02-22 1250 500 30 7566 JONES MANAGER 7839 81-04-02 2975 20 7654 MARTIN SALESMAN 7698 81-09-28 1250 1400 30 1 NULL 7698 BLAKE MANAGER 7839 81-05-01 2850 30 7782 CLARK MANAGER 7839 81-06-09 2450 10 7839 KING PRESIDENT 81-11-17 5000 10 7844 TURNER SALESMAN 7698 81-09-08 1500 0 30 7900 JAMES CLERK 7698 81-12-03 950 30 7902 FORD ANALYST 7566 81-12-03 3000 20 7934 MILLER CLERK 7782 82-01-23 1300 10 実行計画 ---------------------------------------------------------- Plan hash value: 2189749816 ------------------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Inst |IN-OUT| ------------------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 18 | 990 | 7 (29)| 00:00:01 | | | | 1 | HASH UNIQUE | | 18 | 990 | 7 (29)| 00:00:01 | | | | 2 | UNION-ALL | | | | | | | | | 3 | TABLE ACCESS FULL| LOCAL_EMP | 6 | 522 | 2 (0)| 00:00:01 | | | | 4 | REMOTE | EMP | 12 | 468 | 3 (0)| 00:00:01 | REMOT~ | R->S | ------------------------------------------------------------------------------------------------- Remote SQL Information (identified by operation id): ---------------------------------------------------- 4 - SELECT "EMPNO","ENAME","JOB","MGR","HIREDATE","SAL","COMM","DEPTNO" FROM "EMP" "EMP" (accessing 'REMOTE_SCOTT' ) Note ----- - dynamic statistics used: dynamic sampling (level=2)

NO_PQ_CONCURRENT_UNIONでConcurrent Execution を抑止してみると, 順に処理されていることがわかります.

1 SELECT 2 /*+ 3 PARALLEL(3) 4 NO_PQ_CONCURRENT_UNION 5 */ 6 * 7 FROM 8 local_emp 9 UNION 10 SELECT 11 * 12 FROM 13* emp@remote_scott EMPNO ENAME JOB MGR HIREDATE SAL COMM DEPTNO ---------- ------------------------------ --------------------------- ---------- -------- ---------- ---------- ---------- 7902 FORD ANALYST 7566 81-12-03 3000 20 7566 JONES MANAGER 7839 81-04-02 2975 20 7654 MARTIN SALESMAN 7698 81-09-28 1250 1400 30 7369 SMITH CLERK 7902 80-12-17 800 20 1 NULL 7900 JAMES CLERK 7698 81-12-03 950 30 7934 MILLER CLERK 7782 82-01-23 1300 10 7839 KING PRESIDENT 81-11-17 5000 10 7782 CLARK MANAGER 7839 81-06-09 2450 10 7499 ALLEN SALESMAN 7698 81-02-20 1600 300 30 7844 TURNER SALESMAN 7698 81-09-08 1500 0 30 7521 WARD SALESMAN 7698 81-02-22 1250 500 30 7698 BLAKE MANAGER 7839 81-05-01 2850 30 実行計画 ---------------------------------------------------------- Plan hash value: 622056383 ----------------------------------------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | TQ/Ins |IN-OUT| PQ Distrib | ----------------------------------------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 18 | 990 | 7 (29)| 00:00:01 | | | | | 1 | PX COORDINATOR | | | | | | | | | | 2 | PX SEND QC (RANDOM) | :TQ10002 | 18 | 990 | 7 (29)| 00:00:01 | Q1,02 | P->S | QC (RAND) | | 3 | HASH UNIQUE | | 18 | 990 | 7 (29)| 00:00:01 | Q1,02 | PCWP | | | 4 | PX RECEIVE | | 18 | 990 | 7 (29)| 00:00:01 | Q1,02 | PCWP | | | 5 | PX SEND HASH | :TQ10001 | 18 | 990 | 7 (29)| 00:00:01 | Q1,01 | P->P | HASH | | 6 | HASH UNIQUE | | 18 | 990 | 7 (29)| 00:00:01 | Q1,01 | PCWP | | | 7 | UNION-ALL | | | | | | Q1,01 | PCWP | | | 8 | PX BLOCK ITERATOR | | 6 | 522 | 2 (0)| 00:00:01 | Q1,01 | PCWC | | | 9 | TABLE ACCESS FULL | LOCAL_EMP | 6 | 522 | 2 (0)| 00:00:01 | Q1,01 | PCWP | | | 10 | BUFFER SORT | | | | | | Q1,01 | PCWC | | | 11 | PX RECEIVE | | 12 | 468 | 3 (0)| 00:00:01 | Q1,01 | PCWP | | | 12 | PX SEND ROUND-ROBIN| :TQ10000 | 12 | 468 | 3 (0)| 00:00:01 | | S->P | RND-ROBIN | | 13 | REMOTE | EMP | 12 | 468 | 3 (0)| 00:00:01 | REMOT~ | R->S | | ----------------------------------------------------------------------------------------------------------------------- Remote SQL Information (identified by operation id): ---------------------------------------------------- 13 - SELECT /*+ SHARED (3) */ "EMPNO","ENAME","JOB","MGR","HIREDATE","SAL","COMM","DEPTNO" FROM "EMP" "EMP" (accessing 'REMOTE_SCOTT' ) Note ----- - dynamic statistics used: dynamic sampling (level=2) - Degree of Parallelism is 3 because of hint

UNIONでもPX SELECTORが現れ, 分岐がパラレルに処理されていることが見えます. ：）

1 SELECT 2 /*+ 3 PARALLEL(3) 4 */ 5 * 6 FROM 7 local_emp 8 UNION 9 SELECT 10 * 11 FROM 12* emp@remote_scott EMPNO ENAME JOB MGR HIREDATE SAL COMM DEPTNO ---------- ------------------------------ --------------------------- ---------- -------- ---------- ---------- ---------- 7499 ALLEN SALESMAN 7698 81-02-20 1600 300 30 7844 TURNER SALESMAN 7698 81-09-08 1500 0 30 7521 WARD SALESMAN 7698 81-02-22 1250 500 30 7698 BLAKE MANAGER 7839 81-05-01 2850 30 7902 FORD ANALYST 7566 81-12-03 3000 20 7566 JONES MANAGER 7839 81-04-02 2975 20 7654 MARTIN SALESMAN 7698 81-09-28 1250 1400 30 7369 SMITH CLERK 7902 80-12-17 800 20 1 NULL 7900 JAMES CLERK 7698 81-12-03 950 30 7934 MILLER CLERK 7782 82-01-23 1300 10 7839 KING PRESIDENT 81-11-17 5000 10 7782 CLARK MANAGER 7839 81-06-09 2450 10 実行計画 ---------------------------------------------------------- Plan hash value: 3647789528 -------------------------------------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | TQ |IN-OUT| PQ Distrib | -------------------------------------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 18 | 990 | 7 (29)| 00:00:01 | | | | | 1 | PX COORDINATOR | | | | | | | | | | 2 | PX SEND QC (RANDOM) | :TQ10001 | 18 | 990 | 7 (29)| 00:00:01 | Q1,01 | P->S | QC (RAND) | | 3 | HASH UNIQUE | | 18 | 990 | 7 (29)| 00:00:01 | Q1,01 | PCWP | | | 4 | PX RECEIVE | | 18 | 990 | 7 (29)| 00:00:01 | Q1,01 | PCWP | | | 5 | PX SEND HASH | :TQ10000 | 18 | 990 | 7 (29)| 00:00:01 | Q1,00 | P->P | HASH | | 6 | HASH UNIQUE | | 18 | 990 | 7 (29)| 00:00:01 | Q1,00 | PCWP | | | 7 | UNION-ALL | | | | | | Q1,00 | PCWP | | | 8 | PX BLOCK ITERATOR | | 6 | 522 | 2 (0)| 00:00:01 | Q1,00 | PCWC | | | 9 | TABLE ACCESS FULL| LOCAL_EMP | 6 | 522 | 2 (0)| 00:00:01 | Q1,00 | PCWP | | | 10 | PX SELECTOR | | | | | | Q1,00 | PCWP | | | 11 | REMOTE | EMP | 12 | 468 | 3 (0)| 00:00:01 | Q1,00 | PCWP | | -------------------------------------------------------------------------------------------------------------------- Remote SQL Information (identified by operation id): ---------------------------------------------------- 11 - SELECT /*+ SHARED (3) */ "EMPNO","ENAME","JOB","MGR","HIREDATE","SAL","COMM","DEPTNO" FROM "EMP" "EMP" (accessing ':Q1000' ) Note ----- - dynamic statistics used: dynamic sampling (level=2) - Degree of Parallelism is 3 because of hint

ちなみに, Concurrent Execution of Union All and Union　と書いている通り, MINUS/EXCEPT/INTERSECTでは今まで通りです. 　EXCEPTとINTERSECTの実行計画で見てみます. PX SELECTOR は現れていません. (MINUSとEXCEPTはどちらもMINUSとして扱われているので片方だけで十分です)

1 SELECT 2 /*+ 3 PARALLEL(3) 4 */ 5 * 6 FROM 7 local_emp 8 EXCEPT 9 SELECT 10 * 11 FROM 12* emp@remote_scott EMPNO ENAME JOB MGR HIREDATE SAL COMM DEPTNO ---------- ------------------------------ --------------------------- ---------- -------- ---------- ---------- ---------- 1 NULL 実行計画 ---------------------------------------------------------- Plan hash value: 331225933 ------------------------------------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | TQ/Ins |IN-OUT| PQ Distrib | ------------------------------------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 6 | 990 | 7 (29)| 00:00:01 | | | | | 1 | PX COORDINATOR | | | | | | | | | | 2 | PX SEND QC (RANDOM) | :TQ10002 | | | | | Q1,02 | P->S | QC (RAND) | | 3 | MINUS HASH | | | | | | Q1,02 | PCWP | | | 4 | PX RECEIVE | | | | | | Q1,02 | PCWP | | | 5 | PX SEND HASH | :TQ10001 | | | | | Q1,01 | P->P | HASH | | 6 | HASH UNIQUE | | 6 | 522 | 3 (34)| 00:00:01 | Q1,01 | PCWP | | | 7 | PX BLOCK ITERATOR | | 6 | 522 | 2 (0)| 00:00:01 | Q1,01 | PCWC | | | 8 | TABLE ACCESS FULL| LOCAL_EMP | 6 | 522 | 2 (0)| 00:00:01 | Q1,01 | PCWP | | | 9 | BUFFER SORT | | | | | | Q1,02 | PCWC | | | 10 | PX RECEIVE | | 12 | 468 | 3 (0)| 00:00:01 | Q1,02 | PCWP | | | 11 | PX SEND HASH | :TQ10000 | 12 | 468 | 3 (0)| 00:00:01 | | S->P | HASH | | 12 | REMOTE | EMP | 12 | 468 | 3 (0)| 00:00:01 | REMOT~ | R->S | | ------------------------------------------------------------------------------------------------------------------- Remote SQL Information (identified by operation id): ---------------------------------------------------- 12 - SELECT /*+ SHARED (3) */ "EMPNO","ENAME","JOB","MGR","HIREDATE","SAL","COMM","DEPTNO" FROM "EMP" "EMP" (accessing 'REMOTE_SCOTT' ) Note ----- - dynamic statistics used: dynamic sampling (level=2) - Degree of Parallelism is 3 because of hint

1 SELECT 2 /*+ 3 PARALLEL(3) 4 */ 5 * 6 FROM 7 local_emp 8 INTERSECT 9 SELECT 10 * 11 FROM 12* emp@remote_scott EMPNO ENAME JOB MGR HIREDATE SAL COMM DEPTNO ---------- ------------------------------ --------------------------- ---------- -------- ---------- ---------- ---------- 7369 SMITH CLERK 7902 80-12-17 800 20 7566 JONES MANAGER 7839 81-04-02 2975 20 7654 MARTIN SALESMAN 7698 81-09-28 1250 1400 30 7499 ALLEN SALESMAN 7698 81-02-20 1600 300 30 7521 WARD SALESMAN 7698 81-02-22 1250 500 30 実行計画 ---------------------------------------------------------- Plan hash value: 1417135745 ------------------------------------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | TQ/Ins |IN-OUT| PQ Distrib | ------------------------------------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 6 | 990 | 7 (29)| 00:00:01 | | | | | 1 | PX COORDINATOR | | | | | | | | | | 2 | PX SEND QC (RANDOM) | :TQ10002 | | | | | Q1,02 | P->S | QC (RAND) | | 3 | INTERSECTION HASH | | | | | | Q1,02 | PCWP | | | 4 | PX RECEIVE | | | | | | Q1,02 | PCWP | | | 5 | PX SEND HASH | :TQ10001 | | | | | Q1,01 | P->P | HASH | | 6 | HASH UNIQUE | | 6 | 522 | 3 (34)| 00:00:01 | Q1,01 | PCWP | | | 7 | PX BLOCK ITERATOR | | 6 | 522 | 2 (0)| 00:00:01 | Q1,01 | PCWC | | | 8 | TABLE ACCESS FULL| LOCAL_EMP | 6 | 522 | 2 (0)| 00:00:01 | Q1,01 | PCWP | | | 9 | BUFFER SORT | | | | | | Q1,02 | PCWC | | | 10 | PX RECEIVE | | 12 | 468 | 3 (0)| 00:00:01 | Q1,02 | PCWP | | | 11 | PX SEND HASH | :TQ10000 | 12 | 468 | 3 (0)| 00:00:01 | | S->P | HASH | | 12 | REMOTE | EMP | 12 | 468 | 3 (0)| 00:00:01 | REMOT~ | R->S | | ------------------------------------------------------------------------------------------------------------------- Remote SQL Information (identified by operation id): ---------------------------------------------------- 12 - SELECT /*+ SHARED (3) */ "EMPNO","ENAME","JOB","MGR","HIREDATE","SAL","COMM","DEPTNO" FROM "EMP" "EMP" (accessing 'REMOTE_SCOTT' ) Note ----- - dynamic statistics used: dynamic sampling (level=2) - Degree of Parallelism is 3 because of hint

ということで, Day 16 done

残り9日だ. ふ〜〜〜〜っ. 明日も絶対, 担当は私です.

ではまた.

参考） Oracle Database 21c - VLDB and Partitioning Guide / 8.5.3.14 Concurrent Execution of Union All

Related article on Mac De Oracle
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 1 / TABLE FULL SCAN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 2 / INDEX UNIQUE SCAN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 3 / INDEX RANGE SCAN, Index Only Scan
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 4 / INDEX RANGE SCAN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 5 / INDEX RANGE SCAN, INLIST ITERATOR
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 6 / INDEX FAST SCAN, Index Only Scan
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 7 / INDEX FULL SCAN,Index Only Scan
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 8 / INDEX SKIP SCAN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 9 / TABLE ACCESS INMEMORY FULL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 10 / NESTED LOOP JOIN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 11 / MERGE JOIN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 12 / HASH JOIN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 13 / HASH JOIN OUTER
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 14 / HASH JOIN FULL OUTER
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 15 / PX, TABLE ACCESS FULL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 16 / CONCATENATION
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 17 / SORT UNIQUE, UNION-ALL = UNION
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 18 / UNION-ALL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 19 / INTERSECTION
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 20 / MINUS
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 21 / WINDOW NOSORT STOPKEY
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 22 / COUNT STOPKEY
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 23 / HASH JOIN - LEFT-DEEP JOIN vs RIGHT-DEEP JOIN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 24 / CONNECT BY NO FILTERING WITH START-WITH
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 25 / UNION ALL (RECURSIVE WITH) DEPTH FIRST, RECURSIVE WITH PUMP
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#1 / STAR TRANSFORM, VECTOR TRANSFORM (DWH向け)
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#2 / MERGE (UPSERT)
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#3 / RDFView
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#4 / INDEX FULL SCAN (MIN/MAX) - Index Only Scan
・実行計画は, SQL文のレントゲン写真だ！ No.30 - LOAD TABLE CONVENTIONAL vs. LOAD AS SELECT
・実行計画は, SQL文のレントゲン写真だ！ No.31 - TEMP TABLE TRANSFORMATION LOAD AS SELECT (CURSOR DURATION MEMORY)
・実行計画は, SQL文のレントゲン写真だ！ No.32 - EXTERNAL TABLE ACCESS FULL / INMEMORY FULL
・実行計画は, SQL文のレントゲン写真だ！ No.33 - BITMAP CONVERSION TO ROWIDS
・実行計画は, SQL文のレントゲン写真だ！ No.34 - 似て非なるもの　USE_CONCAT　と　OR_EXPAND ヒントと　手書きSQLのレントゲンの見分け方
 ・実行計画は, SQL文のレントゲン写真だ！ No.35 - 似て非なるもの USE_CONCAT と OR_EXPANDヒントとパラレルクエリー
 ・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 1　/ No.36 / INTERSECT ALL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 2　/ No.37 / MINUS ALL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 3　/ No.38 / EXCEPT and EXCEPT ALL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 4 / No.39 / In-Memory Hybrid Scans
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 5 / No.40 / PIVOT and UNPIVOT
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 6 / No.41 / In-Memory Vectorized Join
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 7 / No.42 / INDEX RANGE SCAN (MULTI VALUE)
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 8 / No.43 / TABLE ACCESS BY INDEX ROWID BATCHED
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 9 / No.44 / COLLECTION ITERATOR PICKLER FETCH
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 10 / No.45 / MAT_VIEW REWRITE ACCESS FULL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 11 / No.46 / GROUPING SETS, ROLLUP, CUBE
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 12 / No.47 /　TEMP TABLE TRANSFORMATION
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 13 / No.48 / MULTI-TABLE INSERT
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 14 / No.49 / the DUAL Table
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 15 / No.50 / REMOTE

投稿日時 2022年12月16日 (金) 00時00分 Oracle, チューニング, SQL, 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月15日 (木)

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

Previously on Mac De Oracle...
Day 14は, the DUAL Table にフォーカスをあてました. 23cでは省略できるようになる. やっと, と言う感じもしなくないですが. やっとと言う言葉しかないわけです. はいw

帰ってきた！　実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺） Advent Calendar 2022も遂に, 残り10回. 頑張ってネタ考えようw
それでは, Day 15 の窓を開けましょう！.

REMOTE と聞いて, ピンと来た方w　多いと思いますが, そうです, 変なおじ, いや, 変なSQL, 違うw, 　リモートクエリーか, 分散クエリーのどちらかで現れるOperationです. 　リモートクエリーと分散クエリーの違いは, この辺り, とかググっていただくとして.

リモートクエリーとか分散クエリー嫌いな方も多いとは思いますがw　とにかく簡単な例で診てみましょう.

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

SCOTT@orclpdb1> select banner from v$version; BANNER ---------------------------------------------------------------------- Oracle Database 21c Enterprise Edition Release 21.0.0.0.0 - Production

検証を簡単に行うため, 2つのPDBを用意し, 一方のPDBのSCOTTへDatabase Linkを作成しています.

SCOTT@orclpdb2> @day15 1* CREATE DATABASE LINK remote_scott CONNECT TO scott IDENTIFIED BY tiger USING 'orclpdb1' データベース・リンクが作成されました. 経過: 00:00:00.01 1 CREATE TABLE local_emp 2 AS 3 SELECT * 4 FROM 5 emp@remote_scott 6 ORDER BY 7 empno 8* FETCH FIRST 5 ROWS ONLY 表が作成されました. 経過: 00:00:00.09

今回の例は分散クエリーです（複数のデータベースを問い合わせてるので）. Database Linkを介してアクセスされる表へのOperationは, REMOTE となり, REMOTEデータベースへSQL文の実行がリクエストされることになります.
リクエストされるSQLは, 最近では, AUTO TRACEのRemote SQL Informationセクションでも確認できるようになっています（便利ですよね）. 該当SQLをリモートデータベースで実行して実行計画を確認することができます.

1 SELECT 2 * 3 FROM 4 local_emp 5 INTERSECT 6 SELECT 7 * 8 FROM 9* emp@remote_scott 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 7521 WARD SALESMAN 7698 81-02-22 1250 500 30 7566 JONES MANAGER 7839 81-04-02 2975 20 7654 MARTIN SALESMAN 7698 81-09-28 1250 1400 30 実行計画 ---------------------------------------------------------- Plan hash value: 63876577 ------------------------------------------------------------------------------------------------ | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Inst |IN-OUT| ------------------------------------------------------------------------------------------------ | 0 | SELECT STATEMENT | | 5 | 903 | 7 (29)| 00:00:01 | | | | 1 | INTERSECTION HASH | | | | | | | | | 2 | TABLE ACCESS FULL| LOCAL_EMP | 5 | 435 | 2 (0)| 00:00:01 | | | | 3 | REMOTE | EMP | 12 | 468 | 3 (0)| 00:00:01 | REMOT~ | R->S | ------------------------------------------------------------------------------------------------ Remote SQL Information (identified by operation id): ---------------------------------------------------- 3 - SELECT "EMPNO","ENAME","JOB","MGR","HIREDATE","SAL","COMM","DEPTNO" FROM "EMP" "EMP" (accessing 'REMOTE_SCOTT' ) Note ----- - dynamic statistics used: dynamic sampling (level=2) 統計 ---------------------------------------------------------- 0 recursive calls 0 db block gets 3 consistent gets 0 physical reads 0 redo size 1352 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

9年ほど前, クエリー分裂症の治療の様子を見たい方はこちらのスライド見てね. :)

ということで, 明日も私です:)

Related article on Mac De Oracle

・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 1 / TABLE FULL SCAN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 2 / INDEX UNIQUE SCAN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 3 / INDEX RANGE SCAN, Index Only Scan
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 4 / INDEX RANGE SCAN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 5 / INDEX RANGE SCAN, INLIST ITERATOR
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 6 / INDEX FAST SCAN, Index Only Scan
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 7 / INDEX FULL SCAN,Index Only Scan
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 8 / INDEX SKIP SCAN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 9 / TABLE ACCESS INMEMORY FULL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 10 / NESTED LOOP JOIN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 11 / MERGE JOIN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 12 / HASH JOIN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 13 / HASH JOIN OUTER
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 14 / HASH JOIN FULL OUTER
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 15 / PX, TABLE ACCESS FULL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 16 / CONCATENATION
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 17 / SORT UNIQUE, UNION-ALL = UNION
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 18 / UNION-ALL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 19 / INTERSECTION
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 20 / MINUS
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 21 / WINDOW NOSORT STOPKEY
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 22 / COUNT STOPKEY
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 23 / HASH JOIN - LEFT-DEEP JOIN vs RIGHT-DEEP JOIN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 24 / CONNECT BY NO FILTERING WITH START-WITH
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 25 / UNION ALL (RECURSIVE WITH) DEPTH FIRST, RECURSIVE WITH PUMP
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#1 / STAR TRANSFORM, VECTOR TRANSFORM (DWH向け)
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#2 / MERGE (UPSERT)
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#3 / RDFView
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#4 / INDEX FULL SCAN (MIN/MAX) - Index Only Scan
・実行計画は, SQL文のレントゲン写真だ！ No.30 - LOAD TABLE CONVENTIONAL vs. LOAD AS SELECT
・実行計画は, SQL文のレントゲン写真だ！ No.31 - TEMP TABLE TRANSFORMATION LOAD AS SELECT (CURSOR DURATION MEMORY)
・実行計画は, SQL文のレントゲン写真だ！ No.32 - EXTERNAL TABLE ACCESS FULL / INMEMORY FULL
・実行計画は, SQL文のレントゲン写真だ！ No.33 - BITMAP CONVERSION TO ROWIDS
・実行計画は, SQL文のレントゲン写真だ！ No.34 - 似て非なるもの　USE_CONCAT　と　OR_EXPAND ヒントと　手書きSQLのレントゲンの見分け方
 ・実行計画は, SQL文のレントゲン写真だ！ No.35 - 似て非なるもの USE_CONCAT と OR_EXPANDヒントとパラレルクエリー
 ・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 1　/ No.36 / INTERSECT ALL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 2　/ No.37 / MINUS ALL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 3　/ No.38 / EXCEPT and EXCEPT ALL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 4 / No.39 / In-Memory Hybrid Scans
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 5 / No.40 / PIVOT and UNPIVOT
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 6 / No.41 / In-Memory Vectorized Join
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 7 / No.42 / INDEX RANGE SCAN (MULTI VALUE)
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 8 / No.43 / TABLE ACCESS BY INDEX ROWID BATCHED
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 9 / No.44 / COLLECTION ITERATOR PICKLER FETCH
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 10 / No.45 / MAT_VIEW REWRITE ACCESS FULL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 11 / No.46 / GROUPING SETS, ROLLUP, CUBE
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 12 / No.47 /　TEMP TABLE TRANSFORMATION
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 13 / No.48 / MULTI-TABLE INSERT
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 14 / No.49 / the DUAL Table

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

2022年12月14日 (水)

実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 14 / No.49 / the DUAL Table

Previously on Mac De Oracle... Day 13は, MULTI-TABLE INESRT にフォーカスをあてました. 癖は多いですけども, 便利ですよねーと思っている文の一つでした.

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

Oracle Databaseでは有名すぎる, Selecting from the DUAL Tableですが, 遂に, 21c23cで省略できるようになる！！らしい. まだ, 23cは触ったことはないですが, リリースされたら試してみたいですよね. というか, 多分, みんな, 間違いなく, ブログに書くネタだろうと思いますw

今日は, そんな消えゆく, dual 表, ありがとう. という意味も込めて, 魚拓として, 実行計画という名のレントゲンを残しておこうと思います. （23cリリースされた時の引用にもなるのでw)

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

SCOTT@orclpdb1> select banner from v$version; BANNER ---------------------------------------------------------------------- Oracle Database 21c Enterprise Edition Release 21.0.0.0.0 - Production

dual表って実在する表なんですよねw.
昔, 誰かが, dual表へ行をINSERTして, dual表が複数行返すようにしたらどうなるか？　なんていう, おイタをしていたような...誰だろうなぁ, あれやってたのw　

SCOTT@orclpdb1> @day14 1* SELECT * FROM dual DUM --- X 経過: 00:00:00.01 経過: 00:00:00.01 実行計画 ---------------------------------------------------------- Plan hash value: 272002086 -------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | -------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 1 | 2 | 2 (0)| 00:00:01 | | 1 | TABLE ACCESS FULL| DUAL | 1 | 2 | 2 (0)| 00:00:01 | -------------------------------------------------------------------------- 統計 ---------------------------------------------------------- 0 recursive calls 0 db block gets 2 consistent gets 0 physical reads 0 redo size 587 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

Oracle Database 10g R1以降では, DUMMY列にアクセスしない場合には, dual表へのconsistent getsの発生が抑止されるようになりました. その場合 FAST DUAL としてOperationに現れます

1* SELECT null FROM dual N - 経過: 00:00:00.00 経過: 00:00:00.01 実行計画 ---------------------------------------------------------- Plan hash value: 1388734953 ----------------------------------------------------------------- | Id | Operation | Name | Rows | Cost (%CPU)| Time | ----------------------------------------------------------------- | 0 | SELECT STATEMENT | | 1 | 2 (0)| 00:00:01 | | 1 | FAST DUAL | | 1 | 2 (0)| 00:00:01 | ----------------------------------------------------------------- 統計 ---------------------------------------------------------- 0 recursive calls 0 db block gets 0 consistent gets 0 physical reads 0 redo size 584 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

SELECT * FROM dual　の動きで面白いところの一つは, 前回のエントリーで, Multi Table Insertのような構文では, SELECT * FROM dual を使っていますが, SELECT * FROM dual 単体で使う時とは異なり, 実行計画中では, しっかり, コストの低い FAST DUAL が現れている点です. 21cまでは, 文法上必須なわけですが, SELECT * FROM dual と書いた場合でも, ただのお約束上の話なので, よしなに　FAST DUAL してくれていると言うことになります. ただ、23cになったら記述不要になるようなので, SQL文には書かなくなりそうな気がします（下位互換で残るのはあるでしょうけども）.

と, 言うことで, 本日はここまで.

はぁ. アドベントカレンダー全部俺も折り返しましたが, まだ, 先は長いw
バテ気味な感じが, しつつも, 明日も私が担当します！
では, また.

Related article on Mac De Oracle
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 1 / TABLE FULL SCAN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 2 / INDEX UNIQUE SCAN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 3 / INDEX RANGE SCAN, Index Only Scan
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 4 / INDEX RANGE SCAN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 5 / INDEX RANGE SCAN, INLIST ITERATOR
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 6 / INDEX FAST SCAN, Index Only Scan
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 7 / INDEX FULL SCAN,Index Only Scan
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 8 / INDEX SKIP SCAN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 9 / TABLE ACCESS INMEMORY FULL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 10 / NESTED LOOP JOIN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 11 / MERGE JOIN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 12 / HASH JOIN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 13 / HASH JOIN OUTER
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 14 / HASH JOIN FULL OUTER
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 15 / PX, TABLE ACCESS FULL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 16 / CONCATENATION
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 17 / SORT UNIQUE, UNION-ALL = UNION
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 18 / UNION-ALL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 19 / INTERSECTION
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 20 / MINUS
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 21 / WINDOW NOSORT STOPKEY
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 22 / COUNT STOPKEY
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 23 / HASH JOIN - LEFT-DEEP JOIN vs RIGHT-DEEP JOIN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 24 / CONNECT BY NO FILTERING WITH START-WITH
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 25 / UNION ALL (RECURSIVE WITH) DEPTH FIRST, RECURSIVE WITH PUMP
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#1 / STAR TRANSFORM, VECTOR TRANSFORM (DWH向け)
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#2 / MERGE (UPSERT)
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#3 / RDFView
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#4 / INDEX FULL SCAN (MIN/MAX) - Index Only Scan
・実行計画は, SQL文のレントゲン写真だ！ No.30 - LOAD TABLE CONVENTIONAL vs. LOAD AS SELECT
・実行計画は, SQL文のレントゲン写真だ！ No.31 - TEMP TABLE TRANSFORMATION LOAD AS SELECT (CURSOR DURATION MEMORY)
・実行計画は, SQL文のレントゲン写真だ！ No.32 - EXTERNAL TABLE ACCESS FULL / INMEMORY FULL
・実行計画は, SQL文のレントゲン写真だ！ No.33 - BITMAP CONVERSION TO ROWIDS
・実行計画は, SQL文のレントゲン写真だ！ No.34 - 似て非なるもの　USE_CONCAT　と　OR_EXPAND ヒントと　手書きSQLのレントゲンの見分け方
 ・実行計画は, SQL文のレントゲン写真だ！ No.35 - 似て非なるもの USE_CONCAT と OR_EXPANDヒントとパラレルクエリー
 ・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 1　/ No.36 / INTERSECT ALL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 2　/ No.37 / MINUS ALL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 3　/ No.38 / EXCEPT and EXCEPT ALL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 4 / No.39 / In-Memory Hybrid Scans
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 5 / No.40 / PIVOT and UNPIVOT
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 6 / No.41 / In-Memory Vectorized Join
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 7 / No.42 / INDEX RANGE SCAN (MULTI VALUE)
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 8 / No.43 / TABLE ACCESS BY INDEX ROWID BATCHED
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 9 / No.44 / COLLECTION ITERATOR PICKLER FETCH
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 10 / No.45 / MAT_VIEW REWRITE ACCESS FULL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 11 / No.46 / GROUPING SETS, ROLLUP, CUBE
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 12 / No.47 /　TEMP TABLE TRANSFORMATION
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 13 / No.48 / MULTI-TABLE INSERT

投稿日時 2022年12月14日 (水) 00時00分 Oracle, チューニング, SQL, パフォーマンス, Advent Calendar, 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

・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 1 / TABLE FULL SCAN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 2 / INDEX UNIQUE SCAN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 3 / INDEX RANGE SCAN, Index Only Scan
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 4 / INDEX RANGE SCAN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 5 / INDEX RANGE SCAN, INLIST ITERATOR
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 6 / INDEX FAST SCAN, Index Only Scan
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 7 / INDEX FULL SCAN,Index Only Scan
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 8 / INDEX SKIP SCAN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 9 / TABLE ACCESS INMEMORY FULL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 10 / NESTED LOOP JOIN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 11 / MERGE JOIN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 12 / HASH JOIN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 13 / HASH JOIN OUTER
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 14 / HASH JOIN FULL OUTER
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 15 / PX, TABLE ACCESS FULL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 16 / CONCATENATION
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 17 / SORT UNIQUE, UNION-ALL = UNION
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 18 / UNION-ALL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 19 / INTERSECTION
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 20 / MINUS
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 21 / WINDOW NOSORT STOPKEY
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 22 / COUNT STOPKEY
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 23 / HASH JOIN - LEFT-DEEP JOIN vs RIGHT-DEEP JOIN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 24 / CONNECT BY NO FILTERING WITH START-WITH
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 25 / UNION ALL (RECURSIVE WITH) DEPTH FIRST, RECURSIVE WITH PUMP
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#1 / STAR TRANSFORM, VECTOR TRANSFORM (DWH向け)
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#2 / MERGE (UPSERT)
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#3 / RDFView
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#4 / INDEX FULL SCAN (MIN/MAX) - Index Only Scan
・実行計画は, SQL文のレントゲン写真だ！ No.30 - LOAD TABLE CONVENTIONAL vs. LOAD AS SELECT
・実行計画は, SQL文のレントゲン写真だ！ No.31 - TEMP TABLE TRANSFORMATION LOAD AS SELECT (CURSOR DURATION MEMORY)
・実行計画は, SQL文のレントゲン写真だ！ No.32 - EXTERNAL TABLE ACCESS FULL / INMEMORY FULL
・実行計画は, SQL文のレントゲン写真だ！ No.33 - BITMAP CONVERSION TO ROWIDS
・実行計画は, SQL文のレントゲン写真だ！ No.34 - 似て非なるもの　USE_CONCAT　と　OR_EXPAND ヒントと　手書きSQLのレントゲンの見分け方
 ・実行計画は, SQL文のレントゲン写真だ！ No.35 - 似て非なるもの USE_CONCAT と OR_EXPANDヒントとパラレルクエリー
 ・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 1　/ No.36 / INTERSECT ALL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 2　/ No.37 / MINUS ALL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 3　/ No.38 / EXCEPT and EXCEPT ALL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 4 / No.39 / In-Memory Hybrid Scans
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 5 / No.40 / PIVOT and UNPIVOT
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 6 / No.41 / In-Memory Vectorized Join
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 7 / No.42 / INDEX RANGE SCAN (MULTI VALUE)
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 8 / No.43 / TABLE ACCESS BY INDEX ROWID BATCHED
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 9 / No.44 / COLLECTION ITERATOR PICKLER FETCH
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 10 / No.45 / MAT_VIEW REWRITE ACCESS FULL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 11 / No.46 / GROUPING SETS, ROLLUP, CUBE
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 12 / No.47 /　TEMP TABLE TRANSFORMATION

投稿日時 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

・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 1 / TABLE FULL SCAN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 2 / INDEX UNIQUE SCAN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 3 / INDEX RANGE SCAN, Index Only Scan
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 4 / INDEX RANGE SCAN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 5 / INDEX RANGE SCAN, INLIST ITERATOR
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 6 / INDEX FAST SCAN, Index Only Scan
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 7 / INDEX FULL SCAN,Index Only Scan
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 8 / INDEX SKIP SCAN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 9 / TABLE ACCESS INMEMORY FULL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 10 / NESTED LOOP JOIN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 11 / MERGE JOIN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 12 / HASH JOIN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 13 / HASH JOIN OUTER
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 14 / HASH JOIN FULL OUTER
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 15 / PX, TABLE ACCESS FULL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 16 / CONCATENATION
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 17 / SORT UNIQUE, UNION-ALL = UNION
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 18 / UNION-ALL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 19 / INTERSECTION
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 20 / MINUS
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 21 / WINDOW NOSORT STOPKEY
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 22 / COUNT STOPKEY
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 23 / HASH JOIN - LEFT-DEEP JOIN vs RIGHT-DEEP JOIN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 24 / CONNECT BY NO FILTERING WITH START-WITH
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 25 / UNION ALL (RECURSIVE WITH) DEPTH FIRST, RECURSIVE WITH PUMP
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#1 / STAR TRANSFORM, VECTOR TRANSFORM (DWH向け)
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#2 / MERGE (UPSERT)
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#3 / RDFView
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#4 / INDEX FULL SCAN (MIN/MAX) - Index Only Scan
・実行計画は, SQL文のレントゲン写真だ！ No.30 - LOAD TABLE CONVENTIONAL vs. LOAD AS SELECT
・実行計画は, SQL文のレントゲン写真だ！ No.31 - TEMP TABLE TRANSFORMATION LOAD AS SELECT (CURSOR DURATION MEMORY)
・実行計画は, SQL文のレントゲン写真だ！ No.32 - EXTERNAL TABLE ACCESS FULL / INMEMORY FULL
・実行計画は, SQL文のレントゲン写真だ！ No.33 - BITMAP CONVERSION TO ROWIDS
・実行計画は, SQL文のレントゲン写真だ！ No.34 - 似て非なるもの　USE_CONCAT　と　OR_EXPAND ヒントと　手書きSQLのレントゲンの見分け方
 ・実行計画は, SQL文のレントゲン写真だ！ No.35 - 似て非なるもの USE_CONCAT と OR_EXPANDヒントとパラレルクエリー
 ・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 1　/ No.36 / INTERSECT ALL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 2　/ No.37 / MINUS ALL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 3　/ No.38 / EXCEPT and EXCEPT ALL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 4 / No.39 / In-Memory Hybrid Scans
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 5 / No.40 / PIVOT and UNPIVOT
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 6 / No.41 / In-Memory Vectorized Join
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 7 / No.42 / INDEX RANGE SCAN (MULTI VALUE)
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 8 / No.43 / TABLE ACCESS BY INDEX ROWID BATCHED
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 9 / No.44 / COLLECTION ITERATOR PICKLER FETCH
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 10 / No.45 / MAT_VIEW REWRITE ACCESS FULL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 11 / No.46 / GROUPING SETS, ROLLUP, CUBE

投稿日時 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

Related article on Mac De Oracle ・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 1 / TABLE FULL SCAN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 2 / INDEX UNIQUE SCAN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 3 / INDEX RANGE SCAN, Index Only Scan
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 4 / INDEX RANGE SCAN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 5 / INDEX RANGE SCAN, INLIST ITERATOR
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 6 / INDEX FAST SCAN, Index Only Scan
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 7 / INDEX FULL SCAN,Index Only Scan
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 8 / INDEX SKIP SCAN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 9 / TABLE ACCESS INMEMORY FULL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 10 / NESTED LOOP JOIN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 11 / MERGE JOIN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 12 / HASH JOIN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 13 / HASH JOIN OUTER
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 14 / HASH JOIN FULL OUTER
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 15 / PX, TABLE ACCESS FULL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 16 / CONCATENATION
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 17 / SORT UNIQUE, UNION-ALL = UNION
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 18 / UNION-ALL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 19 / INTERSECTION
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 20 / MINUS
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 21 / WINDOW NOSORT STOPKEY
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 22 / COUNT STOPKEY
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 23 / HASH JOIN - LEFT-DEEP JOIN vs RIGHT-DEEP JOIN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 24 / CONNECT BY NO FILTERING WITH START-WITH
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 25 / UNION ALL (RECURSIVE WITH) DEPTH FIRST, RECURSIVE WITH PUMP
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#1 / STAR TRANSFORM, VECTOR TRANSFORM (DWH向け)
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#2 / MERGE (UPSERT)
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#3 / RDFView
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#4 / INDEX FULL SCAN (MIN/MAX) - Index Only Scan
・実行計画は, SQL文のレントゲン写真だ！ No.30 - LOAD TABLE CONVENTIONAL vs. LOAD AS SELECT
・実行計画は, SQL文のレントゲン写真だ！ No.31 - TEMP TABLE TRANSFORMATION LOAD AS SELECT (CURSOR DURATION MEMORY)
・実行計画は, SQL文のレントゲン写真だ！ No.32 - EXTERNAL TABLE ACCESS FULL / INMEMORY FULL
・実行計画は, SQL文のレントゲン写真だ！ No.33 - BITMAP CONVERSION TO ROWIDS
・実行計画は, SQL文のレントゲン写真だ！ No.34 - 似て非なるもの　USE_CONCAT　と　OR_EXPAND ヒントと　手書きSQLのレントゲンの見分け方
 ・実行計画は, SQL文のレントゲン写真だ！ No.35 - 似て非なるもの USE_CONCAT と OR_EXPANDヒントとパラレルクエリー
 ・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 1　/ No.36 / INTERSECT ALL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 2　/ No.37 / MINUS ALL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 3　/ No.38 / EXCEPT and EXCEPT ALL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 4 / No.39 / In-Memory Hybrid Scans
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 5 / No.40 / PIVOT and UNPIVOT
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 6 / No.41 / In-Memory Vectorized Join
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 7 / No.42 / INDEX RANGE SCAN (MULTI VALUE)
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 8 / No.43 / TABLE ACCESS BY INDEX ROWID BATCHED
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 9 / No.44 / COLLECTION ITERATOR PICKLER FETCH
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 10 / No.45 / MAT_VIEW REWRITE ACCESS FULL

投稿日時 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月10日 (土)

実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 10 / No.45 / MAT_VIEW REWRITE ACCESS FULL

Previously on Mac De Oracle...
Day 9は, COLLECTION ITERATOR PICKLER FETCHでした. パイプラインテーブルファンクションだけに限りませんが, 利用者定義プロシージャやファンクション内から実行されるSQL文の有無, そして, 実行計画の把握という一手間多くなるタイプです. 特にパイプラインテーブルファンクションについては, 実行計画に特殊な操作として現れるのが特徴というお話しでした.

では, Day 10 の窓を開けましょう.

今日も, 紹介済みだと勘違いして忘れていた, MAT_VIEW REWRITE ACCESS FULL です！

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

SCOTT@orclpdb1> select banner from v$version; BANNER ---------------------------------------------------------------------- Oracle Database 21c Enterprise Edition Release 21.0.0.0.0 - Production

データ作りが面倒なので, 再びサンプルスキーマのSHの力を借りましょうw　（アドベントカレンダー, 全部俺は, ある意味体力, 気力の勝負w　でもあるので, 楽できるところは楽に行きましょう :）

SH@orclpdb1> @day10 1 CREATE MATERIALIZED VIEW LOG ON sales 2 WITH 3 SEQUENCE 4 , ROWID 5 ( 6 prod_id 7 , quantity_sold 8 , amount_sold 9 ) 10* INCLUDING NEW VALUES マテリアライズド・ビュー・ログが作成されました. 1 CREATE MATERIALIZED VIEW LOG ON products 2 WITH 3 ROWID 4 ( 5 prod_id 6 , prod_name 7 , prod_category 8 , prod_subcategory) 9* INCLUDING NEW VALUES マテリアライズド・ビュー・ログが作成されました. 1 CREATE MATERIALIZED VIEW mv_sales_4_day10 2 REFRESH FAST ON DEMAND 3 ENABLE QUERY REWRITE 4 AS 5 SELECT 6 prod_name 7 , SUM(quantity_sold) AS sum_quantity 8 , SUM(amount_sold) AS sum_amount 9 FROM 10 sales 11 INNER JOIN products 12 ON 13 sales.prod_id = products.prod_id 14 GROUP BY 15* prod_name マテリアライズド・ビューが作成されました.

マテビューの準備ができたので, 本日の主役. Query Rewriteが働いで, sales, products表ではなく, materialize viewが full scan されるように書き換えられ, MAT_VIEW REWRITE ACCESS FULLが現れています！
処理時間もいい感じですよね. 　経過: 00:00:00.02　となっています.

1 SELECT 2 prod_name 3 , SUM(quantity_sold) 4 , SUM(amount_sold) 5 FROM 6 sales 7 INNER JOIN products 8 ON 9 sales.prod_id = products.prod_id 10 GROUP BY 11* prod_name PROD_NAME SUM(QUANTITY_SOLD) SUM(AMOUNT_SOLD) -------------------------------------------------- ------------------ ---------------- 5MP Telephoto Digital Camera 6002 6312268.4 17" LCD w/built-in HDTV Tuner 6010 7189171.77 Envoy 256MB - 40GB 5766 5635963.08 Y Box 6929 2082330.3 Mini DV Camcorder with 3.5" Swivel LCD 6160 8314815.4 Envoy Ambassador 9591 15011642.5 ...略... Smash up Boxing 7844 260436.75 Martial Arts Champions 6711 148558.92 Comic Book Heroes 4572 101214.6 Fly Fishing 4091 34547.82 Finding Fido 6168 78881.08 Adventures with Numbers 12742 175563.92 Extension Cable 7576 60713.47 Xtend Memory 15191 366858.31 71行が選択されました. 経過: 00:00:00.02 71行が選択されました. 実行計画 ---------------------------------------------------------- Plan hash value: 3048942819 ------------------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ------------------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 71 | 2627 | 3 (0)| 00:00:01 | | 1 | MAT_VIEW REWRITE ACCESS FULL| MV_SALES_4_DAY10 | 71 | 2627 | 3 (0)| 00:00:01 | ------------------------------------------------------------------------------------------------- 統計 ---------------------------------------------------------- 0 recursive calls 0 db block gets 7 consistent gets 0 physical reads 0 redo size 4356 bytes sent via SQL*Net to client 96 bytes received via SQL*Net from client 6 SQL*Net roundtrips to/from client 0 sorts (memory) 0 sorts (disk) 71 rows processed

ついでなの, Query Rewirteを無効にしてみるとどうなるでしょうか？　当然, オリジナルのsales, products表が結合されます！　
処理時間も大幅に増加して, 　経過: 00:00:00.28　ですね！　かなりの差ですよねこれ. このあたりもうまく使いたい, Oracleの便利な機能の一つではありますね.

1 SELECT 2 /*+ 3 NO_REWRITE 4 */ 5 prod_name 6 , SUM(quantity_sold) 7 , SUM(amount_sold) 8 FROM 9 sales 10 INNER JOIN products 11 ON 12 sales.prod_id = products.prod_id 13 GROUP BY 14* prod_name PROD_NAME SUM(QUANTITY_SOLD) SUM(AMOUNT_SOLD) -------------------------------------------------- ------------------ ---------------- 5MP Telephoto Digital Camera 6002 6312268.4 17" LCD w/built-in HDTV Tuner 6010 7189171.77 Envoy 256MB - 40GB 5766 5635963.08 Y Box 6929 2082330.3 Mini DV Camcorder with 3.5" Swivel LCD 6160 8314815.4 ...略... Martial Arts Champions 6711 148558.92 Comic Book Heroes 4572 101214.6 Fly Fishing 4091 34547.82 Finding Fido 6168 78881.08 Adventures with Numbers 12742 175563.92 Extension Cable 7576 60713.47 Xtend Memory 15191 366858.31 71行が選択されました. 経過: 00:00:00.28 71行が選択されました. 実行計画 ---------------------------------------------------------- Plan hash value: 504757596 ---------------------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Pstart| Pstop | ---------------------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 71 | 4260 | 574 (11)| 00:00:01 | | | | 1 | HASH GROUP BY | | 71 | 4260 | 574 (11)| 00:00:01 | | | |* 2 | HASH JOIN | | 72 | 4320 | 573 (11)| 00:00:01 | | | | 3 | VIEW | VW_GBC_5 | 72 | 2160 | 570 (11)| 00:00:01 | | | | 4 | HASH GROUP BY | | 72 | 864 | 570 (11)| 00:00:01 | | | | 5 | PARTITION RANGE ALL| | 918K| 10M| 523 (3)| 00:00:01 | 1 | 28 | | 6 | TABLE ACCESS FULL | SALES | 918K| 10M| 523 (3)| 00:00:01 | 1 | 28 | | 7 | TABLE ACCESS FULL | PRODUCTS | 72 | 2160 | 3 (0)| 00:00:01 | | | ---------------------------------------------------------------------------------------------------- Predicate Information (identified by operation id): --------------------------------------------------- 2 - access("ITEM_1"="PRODUCTS"."PROD_ID") Note ----- - this is an adaptive plan 統計 ---------------------------------------------------------- 0 recursive calls 0 db block gets 1641 consistent gets 0 physical reads 0 redo size 4356 bytes sent via SQL*Net to client 96 bytes received via SQL*Net from client 6 SQL*Net roundtrips to/from client 0 sorts (memory) 0 sorts (disk) 71 rows processed 1* DROP MATERIALIZED VIEW LOG ON sales マテリアライズド・ビュー・ログが削除されました. 1* DROP MATERIALIZED VIEW LOG ON products マテリアライズド・ビュー・ログが削除されました. 1* DROP MATERIALIZED VIEW mv_sales_4_day10 マテリアライズド・ビューが削除されました.

さてさて, やっと, Day 10です. まだ半分も終わってないのかと, 遠ーーーーーーーーーーくをみるなど.

そんなこと, してても, 明日も私が担当なので, 何か考えますw

参考）
Oracle Database 21c / Data Warehousing Guide - 6 Advanced Materialized Views

Related article on Mac De Oracle
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 1 / TABLE FULL SCAN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 2 / INDEX UNIQUE SCAN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 3 / INDEX RANGE SCAN, Index Only Scan
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 4 / INDEX RANGE SCAN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 5 / INDEX RANGE SCAN, INLIST ITERATOR
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 6 / INDEX FAST SCAN, Index Only Scan
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 7 / INDEX FULL SCAN,Index Only Scan
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 8 / INDEX SKIP SCAN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 9 / TABLE ACCESS INMEMORY FULL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 10 / NESTED LOOP JOIN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 11 / MERGE JOIN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 12 / HASH JOIN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 13 / HASH JOIN OUTER
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 14 / HASH JOIN FULL OUTER
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 15 / PX, TABLE ACCESS FULL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 16 / CONCATENATION
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 17 / SORT UNIQUE, UNION-ALL = UNION
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 18 / UNION-ALL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 19 / INTERSECTION
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 20 / MINUS
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 21 / WINDOW NOSORT STOPKEY
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 22 / COUNT STOPKEY
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 23 / HASH JOIN - LEFT-DEEP JOIN vs RIGHT-DEEP JOIN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 24 / CONNECT BY NO FILTERING WITH START-WITH
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 25 / UNION ALL (RECURSIVE WITH) DEPTH FIRST, RECURSIVE WITH PUMP
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#1 / STAR TRANSFORM, VECTOR TRANSFORM (DWH向け)
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#2 / MERGE (UPSERT)
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#3 / RDFView
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#4 / INDEX FULL SCAN (MIN/MAX) - Index Only Scan
・実行計画は, SQL文のレントゲン写真だ！ No.30 - LOAD TABLE CONVENTIONAL vs. LOAD AS SELECT
・実行計画は, SQL文のレントゲン写真だ！ No.31 - TEMP TABLE TRANSFORMATION LOAD AS SELECT (CURSOR DURATION MEMORY)
・実行計画は, SQL文のレントゲン写真だ！ No.32 - EXTERNAL TABLE ACCESS FULL / INMEMORY FULL
・実行計画は, SQL文のレントゲン写真だ！ No.33 - BITMAP CONVERSION TO ROWIDS
・実行計画は, SQL文のレントゲン写真だ！ No.34 - 似て非なるもの　USE_CONCAT　と　OR_EXPAND ヒントと　手書きSQLのレントゲンの見分け方
 ・実行計画は, SQL文のレントゲン写真だ！ No.35 - 似て非なるもの USE_CONCAT と OR_EXPANDヒントとパラレルクエリー
 ・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 1　/ No.36 / INTERSECT ALL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 2　/ No.37 / MINUS ALL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 3　/ No.38 / EXCEPT and EXCEPT ALL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 4 / No.39 / In-Memory Hybrid Scans
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 5 / No.40 / PIVOT and UNPIVOT
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 6 / No.41 / In-Memory Vectorized Join
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 7 / No.42 / INDEX RANGE SCAN (MULTI VALUE)
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 8 / No.43 / TABLE ACCESS BY INDEX ROWID BATCHED
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 9 / No.44 / COLLECTION ITERATOR PICKLER FETCH

投稿日時 2022年12月10日 (土) 00時00分 Oracle, チューニング, SQL, 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月 9日 (金)

実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 9 / No.44 / COLLECTION ITERATOR PICKLER FETCH

Previously on Mac De Oracle...
Day 8は, レントゲンで紹介済みだと, すっかり勘違いして紹介し忘れていた TABLE ACCESS BY INDEX ROWID BATCHED でした. 索引スキャンはしているけど, 実行回数が多かったり,　実行回数は少ないが, 一回あたりのBuffer gets, Physical Readsが多いケースでは, ボディーブローのような感じで結構影響出るタイプであるケースも少なくないので, もし必要があれば, Index Only ScanなどでIO数削減して（重箱の隅を突くような）治療に繋がることも多い身近なOperationでもあるので知っておくと何かの時には助けになりますよ. きっと.

ということで, Day 9 の窓を開けましょう.

今日の主役は, COLLECTION ITERATOR PICKLER FETCHです.
どのような時に現れるOperationか, 既にググってる方はお気づきだと思いますがw　パイプラインテーブルファンクションを利用してコレクションを返している場合です. これ意外に多くなってきているようにも思いますが, PJ次第なのかなとは思います. 上手く使えば味方になったり. .

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

SCOTT@orclpdb1> select banner from v$version; BANNER ---------------------------------------------------------------------- Oracle Database 21c Enterprise Edition Release 21.0.0.0.0 - Production

Pipelined table function で ascii artで使ったパイプラインテーブルファンクションで実行計画を見てみましょう. (ちなみに, ASCII ARTのYouTube動画には無音です:)

前述のパイプラインテーブルファンクションでは, 表データをアクセスしていませんが, 表をアクセスしている場合でも, パイプラインテーブルファンクション内部から実行されているSQLは表面上現れません.

SCOTT@orclpdb1> set autot trace exp stat SCOTT@orclpdb1> select * from tree(50, 0.2); 4651行が選択されました. 実行計画 ---------------------------------------------------------- Plan hash value: 1806254315 ------------------------------------------------------------------------------------------ | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ------------------------------------------------------------------------------------------ | 0 | SELECT STATEMENT | | 8168 | 16336 | 29 (0)| 00:00:01 | | 1 | COLLECTION ITERATOR PICKLER FETCH| TREE | 8168 | 16336 | 29 (0)| 00:00:01 | ------------------------------------------------------------------------------------------ 統計 ---------------------------------------------------------- 23 recursive calls 0 db block gets 26 consistent gets 0 physical reads 0 redo size 311383 bytes sent via SQL*Net to client 3462 bytes received via SQL*Net from client 312 SQL*Net roundtrips to/from client 0 sorts (memory) 0 sorts (disk) 4651 rows processed

以下, サンプルスキーマであるshのsales表をアクセスするパイプラインテーブルファンクションですが, 実行計画には, COLLECTION ITERATOR PICKLER FETCHが現れるだけであることが分かります.
通常このように, PL/SQLなどのUDFやプロシージャ内部から実行されるSQL文はAWR等で別途確認していく必要があるという点は, 21cでも同様です. この辺りは, 仕方ないかなという感じはしますが, もう少し楽に該当SQL文の実行計画が確認できたら楽になるかな. という気はします.

データを確認し, 引数に利用する値を選んでいるようす.

SH@orclpdb1> desc sales 名前 NULL? 型 ----------------------------------------- -------- ---------------------------- PROD_ID NOT NULL NUMBER CUST_ID NOT NULL NUMBER TIME_ID NOT NULL DATE CHANNEL_ID NOT NULL NUMBER PROMO_ID NOT NULL NUMBER QUANTITY_SOLD NOT NULL NUMBER(10,2) AMOUNT_SOLD NOT NULL NUMBER(10,2) SH@orclpdb1> SH@orclpdb1> select * from sales order by time_id desc fetch first 10 rows only; PROD_ID CUST_ID TIME_ID CHANNEL_ID PROMO_ID QUANTITY_SOLD AMOUNT_SOLD ---------- ---------- -------- ---------- ---------- ------------- ----------- 14 1472 01-12-31 3 351 1 1193.02 20 3042 01-12-31 3 351 1 628.89 20 8182 01-12-31 2 999 1 628.89 20 7231 01-12-31 2 999 1 628.89 20 5745 01-12-31 2 999 1 628.89 20 3973 01-12-31 2 999 1 628.89 20 1978 01-12-31 3 999 1 628.89 20 118 01-12-31 3 999 1 628.89 20 1978 01-12-31 2 999 1 628.89 16 4958 01-12-31 3 999 1 298.11

パイプラインテーブルファンクションの作成中

SH@orclpdb1> @day9 1 CREATE OR REPLACE PACKAGE day9_pkg AS 2 CURSOR cur_2_latest_sales ( 3 in_channel_id sales.channel_id%TYPE 4 ,in_prod_id sales.prod_id%TYPE 5 ,in_cust_id sales.cust_id%TYPE 6 ) IS 7 SELECT 8 * 9 FROM 10 sales 11 WHERE 12 channel_id = in_channel_id 13 AND prod_id = in_prod_id 14 AND cust_id = in_cust_id 15 ORDER BY 16 time_id DESC 17 FETCH FIRST 2 ROWS ONLY; 18 19 TYPE outtable_type IS TABLE OF sales%ROWTYPE; 20 21 FUNCTION list_2_latest_sales ( 22 in_channel_id IN sales.channel_id%TYPE 23 ,in_prod_id IN sales.prod_id%TYPE 24 ,in_cust_id IN sales.cust_id%TYPE 25 ) 26 RETURN outtable_type PIPELINED; 27* END day9_pkg; パッケージが作成されました. 経過: 00:00:00.00 エラーはありません. 1 CREATE OR REPLACE PACKAGE BODY day9_pkg AS 2 FUNCTION list_2_latest_sales ( 3 in_channel_id IN sales.channel_id%TYPE 4 ,in_prod_id IN sales.prod_id%TYPE 5 ,in_cust_id IN sales.cust_id%TYPE 6 ) 7 RETURN outtable_type PIPELINED IS 8 sales_rec outtable_type; 9 BEGIN 10 FOR sales_rec IN cur_2_latest_sales(in_channel_id, in_prod_id, in_cust_id) LOOP 11 PIPE ROW(sales_rec); 12 END LOOP; 13 RETURN; 14 END list_2_latest_sales; 15* END day9_pkg; パッケージ本体が作成されました. 経過: 00:00:00.00 エラーはありません.

以下, テーブルファンクションでsales表をアクセスしていますが, 見える範囲は21cになっても同じで, テーブルファンクションの場合は, COLLECTION ITERATOR PICKLER FETCHという形で表に見える状態なんですよ.
内部で, SQLが実行されているかどうかは, 実行計画からだけでは判断できない例の一つでもあります. このOperationを見つけたら, ファンクション内部で利用されているSQL文を特定しておくと後々役に立つこともあります.

1 SELECT 2 * 3 FROM 4* day9_pkg.list_2_latest_sales(2, 20, 5745) PROD_ID CUST_ID TIME_ID CHANNEL_ID PROMO_ID QUANTITY_SOLD AMOUNT_SOLD ---------- ---------- -------- ---------- ---------- ------------- ----------- 20 5745 01-12-31 2 999 1 628.89 経過: 00:00:00.00 経過: 00:00:00.01 実行計画 ---------------------------------------------------------- Plan hash value: 457385954 --------------------------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | --------------------------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 8168 | 16336 | 29 (0)| 00:00:01 | | 1 | COLLECTION ITERATOR PICKLER FETCH| LIST_2_LATEST_SALES | 8168 | 16336 | 29 (0)| 00:00:01 | --------------------------------------------------------------------------------------------------------- 統計 ---------------------------------------------------------- 2 recursive calls 0 db block gets 49 consistent gets 0 physical reads 0 redo size 1093 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

テーブルファンクションから実行されるSQLは以下のような感じです. 実際にはバインド変数が利用されるため, バインドピークによる影響も合わせて見る必要もあります（バインドピーク無効にしているところって, まだありそうですしね. 昔からの大人の事情に縛られまくっているところとか）

1 SELECT 2 * 3 FROM 4 sales 5 WHERE 6 channel_id = 2 7 AND prod_id = 20 8 AND cust_id = 5745 9 ORDER BY 10 time_id DESC 11* FETCH FIRST 2 ROWS ONLY PROD_ID CUST_ID TIME_ID CHANNEL_ID PROMO_ID QUANTITY_SOLD AMOUNT_SOLD ---------- ---------- -------- ---------- ---------- ------------- ----------- 20 5745 01-12-31 2 999 1 628.89 実行計画 ---------------------------------------------------------- Plan hash value: 3545264548 ------------------------------------------------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Pstart| Pstop | ------------------------------------------------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 2 | 218 | 59 (2)| 00:00:01 | | | |* 1 | VIEW | | 2 | 218 | 59 (2)| 00:00:01 | | | |* 2 | WINDOW SORT PUSHED RANK | | 1 | 29 | 59 (2)| 00:00:01 | | | | 3 | PARTITION RANGE ALL | | 1 | 29 | 58 (0)| 00:00:01 | 1 | 28 | |* 4 | TABLE ACCESS BY LOCAL INDEX ROWID BATCHED| SALES | 1 | 29 | 58 (0)| 00:00:01 | 1 | 28 | | 5 | BITMAP CONVERSION TO ROWIDS | | | | | | | | | 6 | BITMAP AND | | | | | | | | |* 7 | BITMAP INDEX SINGLE VALUE | SALES_CUST_BIX | | | | | 1 | 28 | |* 8 | BITMAP INDEX SINGLE VALUE | SALES_PROD_BIX | | | | | 1 | 28 | ------------------------------------------------------------------------------------------------------------------------------- Predicate Information (identified by operation id): --------------------------------------------------- 1 - filter("from$_subquery$_002"."rowlimit_$$_rownumber"<=2) 2 - filter(ROW_NUMBER() OVER ( ORDER BY INTERNAL_FUNCTION("SALES"."TIME_ID") DESC )<=2) 4 - filter("CHANNEL_ID"=2) 7 - access("CUST_ID"=5745) 8 - access("PROD_ID"=20) 統計 ---------------------------------------------------------- 0 recursive calls 0 db block gets 49 consistent gets 0 physical reads 0 redo size 1093 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

v$sqlareaビューからはこんな感じでSQL_IDが取得できるので, AWRなどから問題になっていそうならば. こいつの実行計画をおっていく感じ. まあ, ファンクションやプロシージャで実装されている場合だと一手間増える感じなのは21cでも変わらんですね. （この例ではplan_hash_valueを指定していますが、バインド変数が利用されているケースでは同一とは限らないのでご注意ください）
SH@orclpdb1> select sql_id,plan_hash_value,sql_text from v$sqlarea where sql_text like '%SALES%' and plan_hash_value = 3545264548;

SQL_ID PLAN_HASH_VALUE SQL_TEXT --------------------------------------- --------------- ---------------------------------------------------------------------------------------------------- 5ang5upk282ga 3545264548 SELECT * FROM SALES WHERE CHANNEL_ID = :B3 AND PROD_ID = :B2 AND CUST_ID = :B1 ORDER BY TIME_ID DESC FETCH FIRST 2 ROWS ONLY

さて, さて, 続きのネタ考えてると, 睡眠不足になりそうな週にw突入してきたぞw

参考）
Oracle Database 21c / 13.5 Chaining Pipelined Table Functions for Multiple Transformations

眠くても, 明日の担当は, 私しかいませんので, やりますw　はい.

Related article on Mac De Oracle
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 1 / TABLE FULL SCAN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 2 / INDEX UNIQUE SCAN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 3 / INDEX RANGE SCAN, Index Only Scan
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 4 / INDEX RANGE SCAN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 5 / INDEX RANGE SCAN, INLIST ITERATOR
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 6 / INDEX FAST SCAN, Index Only Scan
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 7 / INDEX FULL SCAN,Index Only Scan
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 8 / INDEX SKIP SCAN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 9 / TABLE ACCESS INMEMORY FULL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 10 / NESTED LOOP JOIN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 11 / MERGE JOIN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 12 / HASH JOIN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 13 / HASH JOIN OUTER
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 14 / HASH JOIN FULL OUTER
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 15 / PX, TABLE ACCESS FULL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 16 / CONCATENATION
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 17 / SORT UNIQUE, UNION-ALL = UNION
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 18 / UNION-ALL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 19 / INTERSECTION
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 20 / MINUS
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 21 / WINDOW NOSORT STOPKEY
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 22 / COUNT STOPKEY
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 23 / HASH JOIN - LEFT-DEEP JOIN vs RIGHT-DEEP JOIN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 24 / CONNECT BY NO FILTERING WITH START-WITH
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 25 / UNION ALL (RECURSIVE WITH) DEPTH FIRST, RECURSIVE WITH PUMP
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#1 / STAR TRANSFORM, VECTOR TRANSFORM (DWH向け)
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#2 / MERGE (UPSERT)
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#3 / RDFView
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#4 / INDEX FULL SCAN (MIN/MAX) - Index Only Scan
・実行計画は, SQL文のレントゲン写真だ！ No.30 - LOAD TABLE CONVENTIONAL vs. LOAD AS SELECT
・実行計画は, SQL文のレントゲン写真だ！ No.31 - TEMP TABLE TRANSFORMATION LOAD AS SELECT (CURSOR DURATION MEMORY)
・実行計画は, SQL文のレントゲン写真だ！ No.32 - EXTERNAL TABLE ACCESS FULL / INMEMORY FULL
・実行計画は, SQL文のレントゲン写真だ！ No.33 - BITMAP CONVERSION TO ROWIDS
・実行計画は, SQL文のレントゲン写真だ！ No.34 - 似て非なるもの　USE_CONCAT　と　OR_EXPAND ヒントと　手書きSQLのレントゲンの見分け方
 ・実行計画は, SQL文のレントゲン写真だ！ No.35 - 似て非なるもの USE_CONCAT と OR_EXPANDヒントとパラレルクエリー
 ・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 1　/ No.36 / INTERSECT ALL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 2　/ No.37 / MINUS ALL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 3　/ No.38 / EXCEPT and EXCEPT ALL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 4 / No.39 / In-Memory Hybrid Scans
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 5 / No.40 / PIVOT and UNPIVOT
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 6 / No.41 / In-Memory Vectorized Join
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 7 / No.42 / INDEX RANGE SCAN (MULTI VALUE)
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 8 / No.43 / TABLE ACCESS BY INDEX ROWID BATCHED

投稿日時 2022年12月 9日 (金) 00時00分 Oracle, チューニング, SQL, 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月 8日 (木)

実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 8 / No.43 / TABLE ACCESS BY INDEX ROWID BATCHED

Previously on Mac De Oracle...
Day 7は, 実行計画という名のレントゲンにもしっかり現れる安心感のあるJINDEX RANGE SCAN (MULTI VALUE)という操作というJSON絡みの機能のお話でした. やはり, レントゲンだけで診れた方が楽ですねw
帰ってきた！　実行計画は、SQL文のレントゲン写真だ！　Oracle Database (全部俺） Advent Calendar 2022もやっと1/3ぐらいw　毎年思うけど, 大変. 全部俺だとw

ということで, Day 8 の窓を開けましょう.

今日は, すでに紹介済みと勘違いして, すっかり忘れていた TABLE ACCESS BY INDEX ROWID BATCHED　について診ていきたいというか, 改めて確認しておきましょう.

TABLE ACCESS BY INDEX ROWID BATCHEDが登場したのは12cの頃です. 2014年に本ブログでも扱っていました. その時の解説で復習しておきましょう.

実は, この, TABLE ACCESS BY INDEX ROWID BATCHED, 実行計画のOperationに現れるようになったのは, 12cからですが, 内部的には, 11gでも同様の挙動を示していました.
11gの頃は, Operation上は, TABLE ACCESS BY INDEX ROWIDとして現れていましたが, 内部的には, 待機イベント, db file parallel readとして起きている、ということが分かる程度でした. そう, 実行計画という名のレントゲンだけでは判別できない部類の動きでした. その後, 12cになってからOperationとして簡易に判断できるようになりました.

以下, 2014年の記事ですが, SQLトレースを取得して待機イベントも含め調べてた思い出.
TABLE ACCESS BY INDEX ROWID BATCHED (Oracle Database 12c R1) ってなに！　#1
TABLE ACCESS BY INDEX ROWID BATCHED (Oracle Database 12c R1) ってなに！　#2
TABLE ACCESS BY INDEX ROWID BATCHED (Oracle Database 12c R1) ってなに！　#3

では, レントゲンを見てみましょう. （索引レンジスキャンするケースでは, TABLE ACCESS BY INDEX ROWID BATCHEDになる場合が圧倒的に多くなったようにも感じるので, 比較的よく見るOperationだと思います）
INDEX RANGE SCAN + TABLE ACCESS BY INDEX ROWID BATCHEDが行われており, かつ、索引のクラスタリングファクターが大きめ（行数に近い）である場合, Index Only Scanによって, ギリギリまでチューニングできる可能性が高いケースが多いのも, このタイプのOperationあ現れた時の特徴だったりします.

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

SCOTT@orclpdb1> select banner from v$version; BANNER ---------------------------------------------------------------------- Oracle Database 21c Enterprise Edition Release 21.0.0.0.0 - Production

データの準備は以下.

SCOTT@orclpdb1> @day8 1* DROP TABLE day8 表が削除されました. 1 CREATE TABLE day8 2 ( 3 id NUMBER PRIMARY KEY 4 ,string_data VARCHAR2(500) 5* ) 表が作成されました. 1 DECLARE 2 i NUMBER(4) := 0; 3 num_of_rows CONSTANT NUMBER(4) := 1000; 4 done BOOLEAN := false; 5 BEGIN 6 WHILE NOT done LOOP 7 BEGIN 8 INSERT INTO day8 VALUES(TRUNC(DBMS_RANDOM.VALUE(1,3001)), LPAD(TO_CHAR(i),500,'*')); 9 i := i + 1; 10 IF i >= num_of_rows THEN EXIT; END IF; 11 EXCEPTION 12 WHEN DUP_VAL_ON_INDEX THEN 13 NULL; 14 END; 15 IF MOD(i,100) = 0 THEN COMMIT; END IF; 16 END LOOP; 17* END; PL/SQLプロシージャが正常に完了しました. 1 BEGIN 2 DBMS_STATS.GATHER_TABLE_STATS(ownname=>'SCOTT',tabname=>UPPER('day8'),no_invalidate=>false,cascade=>true); 3* END; PL/SQLプロシージャが正常に完了しました. 1 SELECT id 2 FROM 3 day8 4 ORDER BY id 5* FETCH FIRST 5 ROWS ONLY ID ---------- 4 8 10 12 15

良かったw　綺麗に, TABLE ACCESS BY INDEX ROWID BATCHEDが出てますね.

SCOTT@orclpdb1> @day8-2 4 15 1 SELECT 2 id 3 ,substr(string_data,1,10) 4 FROM 5 day8 6 WHERE 7* id BETWEEN &1 AND &2 旧 7: id BETWEEN &1 AND &2 新 7: id BETWEEN 4 AND 15 ID SUBSTR(STRING_DATA,1,10) ---------- ----------------------------------- 4 ********** 8 ********** 10 ********** 12 ********** 15 ********** 旧 7: id BETWEEN &1 AND &2 新 7: id BETWEEN 4 AND 15 実行計画 ---------------------------------------------------------- Plan hash value: 145644201 --------------------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | --------------------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 5 | 2525 | 7 (0)| 00:00:01 | | 1 | TABLE ACCESS BY INDEX ROWID BATCHED| DAY8 | 5 | 2525 | 7 (0)| 00:00:01 | |* 2 | INDEX RANGE SCAN | SYS_C008604 | 5 | | 2 (0)| 00:00:01 | --------------------------------------------------------------------------------------------------- Predicate Information (identified by operation id): --------------------------------------------------- 2 - access("ID">=4 AND "ID"<=15) 統計 ---------------------------------------------------------- 0 recursive calls 0 db block gets 8 consistent gets 0 physical reads 0 redo size 779 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

やっと, 実行計画は, SQL文のレントゲン写真だ！というタイトルっぽいネタになったような気がしたところで, 本日はこれまで.

明日の担当は, 私しかいないので, 私が書きますw　（全部俺）

Related article on Mac De Oracle
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 1 / TABLE FULL SCAN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 2 / INDEX UNIQUE SCAN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 3 / INDEX RANGE SCAN, Index Only Scan
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 4 / INDEX RANGE SCAN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 5 / INDEX RANGE SCAN, INLIST ITERATOR
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 6 / INDEX FAST SCAN, Index Only Scan
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 7 / INDEX FULL SCAN,Index Only Scan
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 8 / INDEX SKIP SCAN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 9 / TABLE ACCESS INMEMORY FULL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 10 / NESTED LOOP JOIN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 11 / MERGE JOIN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 12 / HASH JOIN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 13 / HASH JOIN OUTER
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 14 / HASH JOIN FULL OUTER
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 15 / PX, TABLE ACCESS FULL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 16 / CONCATENATION
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 17 / SORT UNIQUE, UNION-ALL = UNION
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 18 / UNION-ALL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 19 / INTERSECTION
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 20 / MINUS
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 21 / WINDOW NOSORT STOPKEY
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 22 / COUNT STOPKEY
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 23 / HASH JOIN - LEFT-DEEP JOIN vs RIGHT-DEEP JOIN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 24 / CONNECT BY NO FILTERING WITH START-WITH
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 25 / UNION ALL (RECURSIVE WITH) DEPTH FIRST, RECURSIVE WITH PUMP
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#1 / STAR TRANSFORM, VECTOR TRANSFORM (DWH向け)
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#2 / MERGE (UPSERT)
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#3 / RDFView
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#4 / INDEX FULL SCAN (MIN/MAX) - Index Only Scan
・実行計画は, SQL文のレントゲン写真だ！ No.30 - LOAD TABLE CONVENTIONAL vs. LOAD AS SELECT
・実行計画は, SQL文のレントゲン写真だ！ No.31 - TEMP TABLE TRANSFORMATION LOAD AS SELECT (CURSOR DURATION MEMORY)
・実行計画は, SQL文のレントゲン写真だ！ No.32 - EXTERNAL TABLE ACCESS FULL / INMEMORY FULL
・実行計画は, SQL文のレントゲン写真だ！ No.33 - BITMAP CONVERSION TO ROWIDS
・実行計画は, SQL文のレントゲン写真だ！ No.34 - 似て非なるもの　USE_CONCAT　と　OR_EXPAND ヒントと　手書きSQLのレントゲンの見分け方
 ・実行計画は, SQL文のレントゲン写真だ！ No.35 - 似て非なるもの USE_CONCAT と OR_EXPANDヒントとパラレルクエリー
 ・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 1　/ No.36 / INTERSECT ALL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 2　/ No.37 / MINUS ALL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 3　/ No.38 / EXCEPT and EXCEPT ALL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 4 / No.39 / In-Memory Hybrid Scans
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 5 / No.40 / PIVOT and UNPIVOT
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 6 / No.41 / In-Memory Vectorized Join
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 7 / No.42 / INDEX RANGE SCAN (MULTI VALUE)

投稿日時 2022年12月 8日 (木) 00時00分 Oracle, チューニング, SQL, 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月 7日 (水)

実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 7 / No.42 / INDEX RANGE SCAN (MULTI VALUE)

Previously on Mac De Oracle...
Day 6は, 実行計画という名のレントゲンにも現れないタイプ。SQLモニターアクティブレポート(html)という名の内視鏡を利用してなんとか見ることができました。また、v$sysstatからシステム統計という名の血液検査を利用してもある判断できることを確認しました。最近、レントゲンだけで確定できないタイプの多くなってきて遠ーくを見ることが多くなってきたかもねーw

さて、帰ってきた！　実行計画は、SQL文のレントゲン写真だ！　Oracle Database (全部俺） Advent Calendar 2022もなんとか1/3ほどです。持つのかネタというより、検証するのツレーのが多すぎて、記事アップが間に合うのか？　これw（レントゲンに映したいだけのシリーズのはずなのにw）

ということで、 Day 7の窓を開けましょう。今日は、レントゲンで分かるタイプです（一安心w）

Multi-Value Functional Indexです。21cより前は、JSON_VALUE()を利用する関数索引は、Single-Valueだけが利用できました。Single-Valueだけだと辛い場面は多いわけで、その課題への答えが、Multi-Value Functional Indexですね。
JSONへの対応を追っていると、XMLへの対応が始まった頃のOracle Databaseを思い出すお年頃の私なので、色々当時のことを思い出してしまいます（ところで、XML Masterっていう資格知ってます？w　みなさん？）

余談はこれぐらいにして、本題へ。

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

SCOTT@orclpdb1> select banner from v$version; BANNER ---------------------------------------------------------------------- Oracle Database 21c Enterprise Edition Release 21.0.0.0.0 - Production

table、データを用意します。

SCOTT@orclpdb1> @day7 1* DROP TABLE groups 表が削除されました。経過: 00:00:00.04 1* CREATE TABLE groups (group_list_json JSON) 表が作成されました。経過: 00:00:00.02 1 INSERT INTO 2 groups(group_list_json) 3 SELECT 4 JSON_OBJECT 5 ( 6 'group_id' VALUE deptno 7 ,'object_type' VALUE JSON_ARRAYAGG 8 ( 9 JSON_OBJECT 10 ( 11 'member_id' VALUE empno 12 ,'member_name' VALUE ename 13 ) RETURNING CLOB 14 ) RETURNING CLOB 15 ) 16 FROM 17 emp 18 GROUP BY 19* deptno 3行が作成されました。経過: 00:00:00.01 1* COMMIT コミットが完了しました。経過: 00:00:00.01

multi-value functional indexを作成！ group_id毎に配列を持っており、配列に含まれている member_idに対して、MULTIVALUE INDEXを作成しています！

1* CREATE MULTIVALUE INDEX groups_mvix ON groups t1( t1.group_list_json.object_type.member_id.number() ) 索引が作成されました。経過: 00:00:00.01

本日の主役はこれです。
JSON_EXISTS()でMULTIVALUE INDEXを作成した、 member_id　で指定したメンバーが含まれているメンバー全員の名前を取得しています。（その元となっている、JSONも）

想定通り、MULTIVALUE INDEXをアクセスしており、実行計画にも分かりやすく現れています:)
ついでに、Predicate Information には興味深い情報も現れていますね。これもアドベントカレンダー以外でネタになりそうです。

JSONTABLE EVALUATIONというオペレーションは、SQL/JSON Function である、JSON_TABLE()　の操作を示しています。（なぜ、PIVOTが実行計画のOperationに現れないのか、ますます、謎ですなw）

1 SELECT 2 member_name 3 , group_list_json 4 FROM 5 groups 6 ,JSON_TABLE 7 ( 8 group_list_json, '$.object_type[*]' 9 COLUMNS 10 ( 11 member_name VARCHAR2(10) PATH '$.member_name' 12 ) 13 ) 14 WHERE 15 JSON_EXISTS 16 ( 17 group_list_json 18 ,'$.object_type?(@.member_id == 7499)' 19* ) MEMBER_NAME GROUP_LIST_JSON ------------------------------ ---------------------------------------------------------------------------------------------------- ALLEN {"group_id":30,"object_type":[{"member_id":7499,"member_name":"ALLEN"},{"member_id":7900,"member_nam e":"JAMES"},{"member_id":7844,"member_name":"TURNER"},{"member_id":7698,"member_name":"BLAKE"},{"mem ber_id":7654,"member_name":"MARTIN"},{"member_id":7521,"member_name":"WARD"}]} JAMES TURNER BLAKE MARTIN WARD 6行が選択されました。経過: 00:00:00.02 6行が選択されました。経過: 00:00:00.01 実行計画 ---------------------------------------------------------- Plan hash value: 1011849735 ---------------------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ---------------------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 8168 | 32M| 31 (0)| 00:00:01 | | 1 | NESTED LOOPS | | 8168 | 32M| 31 (0)| 00:00:01 | | 2 | TABLE ACCESS BY INDEX ROWID BATCHED| GROUPS | 1 | 4115 | 2 (0)| 00:00:01 | | 3 | HASH UNIQUE | | 8168 | 32M| | | |* 4 | INDEX RANGE SCAN (MULTI VALUE) | GROUPS_MVIX | 1 | | 1 (0)| 00:00:01 | | 5 | JSONTABLE EVALUATION | | | | | | ---------------------------------------------------------------------------------------------------- Predicate Information (identified by operation id): --------------------------------------------------- 4 - access(JSON_QUERY("GROUP_LIST_JSON" /*+ LOB_BY_VALUE */ FORMAT OSON , '$.object_type.member_id.number()' RETURNING NUMBER ASIS WITHOUT ARRAY WRAPPER ERROR ON ERROR NULL ON EMPTY NULL ON MISMATCH MULTIVALUE)=7499) Note ----- - dynamic statistics used: dynamic sampling (level=2) 統計 ---------------------------------------------------------- 0 recursive calls 0 db block gets 2 consistent gets 0 physical reads 0 redo size 3446 bytes sent via SQL*Net to client 532 bytes received via SQL*Net from client 8 SQL*Net roundtrips to/from client 0 sorts (memory) 0 sorts (disk) 6 rows processed

久々に、実行計画という名のレントゲンだけで完結した記事で、ホットしたw　（なんだこの気持ちはw
ということで、スッキリしたわけですが、 JSONの構文に、XMLの構文と同じような、思い出を思い出しつつw　　明日は、やっぱり、私が担当です:)

参考） Oracle Database 21c / 28.8 Creating Multivalue Function-Based Indexes for JSON_EXISTS

Related article on Mac De Oracle
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 1 / TABLE FULL SCAN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 2 / INDEX UNIQUE SCAN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 3 / INDEX RANGE SCAN, Index Only Scan
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 4 / INDEX RANGE SCAN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 5 / INDEX RANGE SCAN, INLIST ITERATOR
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 6 / INDEX FAST SCAN, Index Only Scan
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 7 / INDEX FULL SCAN,Index Only Scan
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 8 / INDEX SKIP SCAN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 9 / TABLE ACCESS INMEMORY FULL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 10 / NESTED LOOP JOIN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 11 / MERGE JOIN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 12 / HASH JOIN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 13 / HASH JOIN OUTER
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 14 / HASH JOIN FULL OUTER
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 15 / PX, TABLE ACCESS FULL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 16 / CONCATENATION
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 17 / SORT UNIQUE, UNION-ALL = UNION
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 18 / UNION-ALL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 19 / INTERSECTION
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 20 / MINUS
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 21 / WINDOW NOSORT STOPKEY
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 22 / COUNT STOPKEY
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 23 / HASH JOIN - LEFT-DEEP JOIN vs RIGHT-DEEP JOIN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 24 / CONNECT BY NO FILTERING WITH START-WITH
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 25 / UNION ALL (RECURSIVE WITH) DEPTH FIRST, RECURSIVE WITH PUMP
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#1 / STAR TRANSFORM, VECTOR TRANSFORM (DWH向け)
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#2 / MERGE (UPSERT)
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#3 / RDFView
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#4 / INDEX FULL SCAN (MIN/MAX) - Index Only Scan
・実行計画は, SQL文のレントゲン写真だ！ No.30 - LOAD TABLE CONVENTIONAL vs. LOAD AS SELECT
・実行計画は, SQL文のレントゲン写真だ！ No.31 - TEMP TABLE TRANSFORMATION LOAD AS SELECT (CURSOR DURATION MEMORY)
・実行計画は, SQL文のレントゲン写真だ！ No.32 - EXTERNAL TABLE ACCESS FULL / INMEMORY FULL
・実行計画は, SQL文のレントゲン写真だ！ No.33 - BITMAP CONVERSION TO ROWIDS
・実行計画は, SQL文のレントゲン写真だ！ No.34 - 似て非なるもの　USE_CONCAT　と　OR_EXPAND ヒントと　手書きSQLのレントゲンの見分け方
 ・実行計画は, SQL文のレントゲン写真だ！ No.35 - 似て非なるもの USE_CONCAT と OR_EXPANDヒントとパラレルクエリー
 ・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 1　/ No.36 / INTERSECT ALL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 2　/ No.37 / MINUS ALL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 3　/ No.38 / EXCEPT and EXCEPT ALL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 4 / No.39 / In-Memory Hybrid Scans
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 5 / No.40 / PIVOT and UNPIVOT
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 6 / No.41 / In-Memory Vectorized Join

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

2022年12月 6日 (火)

実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 6 / No.41 / In-Memory Vectorized Join

Previously on Mac De Oracle...
Day 5は, 実行計画というレントゲンにも現れない PIVOT の謎。みたいなオチですが、UNPIVOTは現れるんだよねー。ということでした。

今日は、さらに、このタイトルでいいのか！　という結末になっております　（乞うご期待w

ということで、 Day 6の窓を開けましょう。

今回、データを準備するのは、面倒だな、と思ったので、サンプルスキーマである SH　スキーマの sales表とcustomer表を利用します。ただ、少しだけ準備は必要ですが.
(なお、INMEMORY_DEEP_VECTORIZATION パラメータのデフォルト値は、TRUEなので, INMEMORY_SIZE パラメータが設定されているのであれば、追加の設定は不要です）

SH@orclpdb1> show parameter INMEMORY_DEEP_VECTORIZATION NAME TYPE VALUE ------------------------------------ --------------------------------- ------------------------------ inmemory_deep_vectorization boolean TRUE

では、準備を。
各表をIn-Memory化してポピュレーションする必要があります。v$im_segmentsビューからすべて載ったことを確認します。

SH@orclpdb1> alter table customers inmemory priority high memcompress for capacity low; 表が変更されました。 SH@orclpdb1> alter table sales inmemory priority high memcompress for capacity low; 表が変更されました。 SH@orclpdb1> select /*+ full(s) no_parallel(s) */ count(*) from sales s; count(*) ---------- 918843 SH@orclpdb1> select /*+ full(c) no_parallel(c) */ count(*) from customers c; count(*) ---------- 55500 SH@orclpdb1> select segment_name,inmemory_size,bytes_not_populated from v$im_segments; SEGMENT_NAME INMEMORY_SIZE BYTES_NOT_POPULATED ------------------------------ ------------- ------------------- SALES 1310720 0 SALES 1310720 0 SALES 1310720 0 DAY4 15990784 0 SALES 1310720 0 SALES 1310720 0 SALES 1310720 0 SALES 1310720 0 SALES 1310720 0 SALES 1310720 0 SALES 1310720 0 SALES 1310720 0 SALES 1310720 0 CUSTOMERS 2359296 0 SALES 1310720 0 SALES 1310720 0 SALES 1310720 0 SALES 1310720 0 18行が選択されました。

実行計画という名のレントゲンがテーマのシリーズですがw　実行計画を見ただけでは、はっきりわからないというPIVOTに続き、2つ目の事例が！！！！！
実行時に実施するかどうかを判断しているとのことで、実行計画を立てている時点では判断できず、実行後または、実行中にのみ確認できるということらしい（なんとかならんのか。ん〜〜〜〜）

ということで、SQLモニターアクティブレポート(html)という名の内視鏡を利用して診る必要のある事例であることがわかりました！！！！！！！
(各表はin-memory fullでアクセスされてます。前提はクリアしているHASH JOINになっています)

SH@orclpdb1> @day6 1 SELECT 2 /*+ 3 NO_STAR_TRANSFORMATION 4 NO_VECTOR_TRANSFORM 5 FULL(c) 6 FULL(s) 7 MONITOR 8 */ 9 count(*) 10 FROM 11 sales s 12 INNER JOIN customers c 13 ON 14* s.cust_id = c.cust_id 実行計画 ---------------------------------------------------------- Plan hash value: 3219640484 ----------------------------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Pstart| Pstop | ----------------------------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 1 | 10 | 56 (24)| 00:00:01 | | | | 1 | SORT AGGREGATE | | 1 | 10 | | | | | |* 2 | HASH JOIN | | 918K| 8973K| 56 (24)| 00:00:01 | | | | 3 | TABLE ACCESS INMEMORY FULL | CUSTOMERS | 55500 | 270K| 17 (6)| 00:00:01 | | | | 4 | PARTITION RANGE ALL | | 918K| 4486K| 34 (21)| 00:00:01 | 1 | 28 | | 5 | TABLE ACCESS INMEMORY FULL| SALES | 918K| 4486K| 34 (21)| 00:00:01 | 1 | 28 | ----------------------------------------------------------------------------------------------------------- Predicate Information (identified by operation id): --------------------------------------------------- 2 - access("S"."CUST_ID"="C"."CUST_ID") 統計 ---------------------------------------------------------- 4 recursive calls 0 db block gets 36 consistent gets 0 physical reads 0 redo size 593 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 ...略...

内視鏡で撮影したスナップショットにもメモしてありますが、HASH JOIN操作の行のInfo列の双眼鏡アイコンをクリックすることで、In-Memory Vectorized Joinが行われたか否かを確認することができます。
DeepVec Hash Joins が重要なキーワードです。見逃さないようにしてくださいね。

今の所、この方法が最も確実で分かりやすい方法です。

次に、通常のHASH JOINとどう違うのかも見ておきましょう。
sales表と、customers表を非インメモリー化します。

SH@orclpdb1> alter table customers no inmemory; 表が変更されました。 SH@orclpdb1> alter table sales no inmemory; 表が変更されました。 SH@orclpdb1> select segment_name,inmemory_size,bytes_not_populated from v$im_segments; SEGMENT_NAME INMEMORY_SIZE BYTES_NOT_POPULATED ------------------------------ ------------- ------------------- DAY4 15990784 0

1 SELECT 2 /*+ 3 NO_STAR_TRANSFORMATION 4 NO_VECTOR_TRANSFORM 5 FULL(c) 6 FULL(s) 7 MONITOR 8 */ 9 count(*) 10 FROM 11 sales s 12 INNER JOIN customers c 13 ON 14* s.cust_id = c.cust_id 実行計画 ---------------------------------------------------------- Plan hash value: 3219640484 --------------------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Pstart| Pstop | --------------------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 1 | 10 | 947 (2)| 00:00:01 | | | | 1 | SORT AGGREGATE | | 1 | 10 | | | | | |* 2 | HASH JOIN | | 918K| 8973K| 947 (2)| 00:00:01 | | | | 3 | TABLE ACCESS FULL | CUSTOMERS | 55500 | 270K| 423 (1)| 00:00:01 | | | | 4 | PARTITION RANGE ALL| | 918K| 4486K| 518 (2)| 00:00:01 | 1 | 28 | | 5 | TABLE ACCESS FULL | SALES | 918K| 4486K| 518 (2)| 00:00:01 | 1 | 28 | --------------------------------------------------------------------------------------------------- Predicate Information (identified by operation id): --------------------------------------------------- 2 - access("S"."CUST_ID"="C"."CUST_ID") 統計 ---------------------------------------------------------- 178 recursive calls 0 db block gets 3444 consistent gets 1586 physical reads 220 redo size 593 bytes sent via SQL*Net to client 52 bytes received via SQL*Net from client 2 SQL*Net roundtrips to/from client 21 sorts (memory) 0 sorts (disk) 1 rows processed ...略...

SQLモニターアクティブレポート(html)というなの内視鏡のスナップショット画像から、例の双眼鏡アイコンをクリックして結果をみると、In-Memory Vectorized Joinが行われていないことが分かります。また、In-memory table full も抑止したのでその差は物凄い差になって現れますね。
In-Memory Vectorized Join 19.39 ms
Hash Join / In-Memory Off 0.13 s

....

SQLモニターアクティブレポート(html)以外に、システム統計からも確認できるようですね。慣れないと読みにくいかも知れないですが、特定のSQL実行前後の変化を見る必要があります。ちょっと面倒ですね。セッション統計でも拾えるのだろうか。。。。（要追跡調査）

SOURCE NAME Before After ---------- ---------------------------------------- -------------------- -------------------- sysstat IM simd KV add rows 610500 666000 sysstat IM simd KV probe calls 176 192 sysstat IM simd KV probe keys 393888 429696 sysstat IM simd KV probe rows 393888 429696 sysstat IM simd decode symbol calls 352 384 sysstat IM simd decode unpack calls 176 192 sysstat IM simd decode unpack selective calls 176 192

最後に、インメモリーにポピュレートされた状態で、In-Memory Vectorized Joinを無効化して差分をみてみましょう。

SH@orclpdb1> alter session set INMEMORY_DEEP_VECTORIZATION = false; セッションが変更されました。 SH@orclpdb1> show parameter INMEMORY_DEEP_VECTORIZATION NAME TYPE VALUE ------------------------------------ --------------------------------- ------------------------------ inmemory_deep_vectorization boolean FALSE

該当表はポピュレートされている状態です

SH@orclpdb1> select segment_name,inmemory_size,bytes_not_populated from v$im_segments; SEGMENT_NAME INMEMORY_SIZE BYTES_NOT_POPULATED ------------------------------ ------------- ------------------- SALES 1310720 0 SALES 1310720 0 SALES 1310720 0 DAY4 15990784 0 SALES 1310720 0 SALES 1310720 0 SALES 1310720 0 SALES 1310720 0 SALES 1310720 0 SALES 1310720 0 SALES 1310720 0 SALES 1310720 0 SALES 1310720 0 CUSTOMERS 2359296 0 SALES 1310720 0 SALES 1310720 0 SALES 1310720 0 SALES 1310720 0

実行計画は、In-Memory Vectorized Joinが行われたものと同じ（Plan hash valueが同一）ですが、前後で取得したシステム統計値で、In-Memory Vectorized Joinに関連するsimd関連の数値に変化がみられません！！！！
システム統計をみるとIn-Memory Vectorized Joinは動作してないことが分かります。とはいえ、SQLモニターレポート（アクティブレポート）が明らかに見やすいとは思います。

1 SELECT 2 /*+ 3 NO_STAR_TRANSFORMATION 4 NO_VECTOR_TRANSFORM 5 FULL(c) 6 FULL(s) 7 MONITOR 8 */ 9 count(*) 10 FROM 11 sales s 12 INNER JOIN customers c 13 ON 14* s.cust_id = c.cust_id 経過: 00:00:00.03 実行計画 ---------------------------------------------------------- Plan hash value: 3219640484 ----------------------------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Pstart| Pstop | ----------------------------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 1 | 10 | 56 (24)| 00:00:01 | | | | 1 | SORT AGGREGATE | | 1 | 10 | | | | | |* 2 | HASH JOIN | | 918K| 8973K| 56 (24)| 00:00:01 | | | | 3 | TABLE ACCESS INMEMORY FULL | CUSTOMERS | 55500 | 270K| 17 (6)| 00:00:01 | | | | 4 | PARTITION RANGE ALL | | 918K| 4486K| 34 (21)| 00:00:01 | 1 | 28 | | 5 | TABLE ACCESS INMEMORY FULL| SALES | 918K| 4486K| 34 (21)| 00:00:01 | 1 | 28 | ----------------------------------------------------------------------------------------------------------- Predicate Information (identified by operation id): --------------------------------------------------- 2 - access("S"."CUST_ID"="C"."CUST_ID") 統計 ---------------------------------------------------------- 33 recursive calls 0 db block gets 67 consistent gets 0 physical reads 0 redo size 593 bytes sent via SQL*Net to client 52 bytes received via SQL*Net from client 2 SQL*Net roundtrips to/from client 8 sorts (memory) 0 sorts (disk) 1 rows processed ...略... SOURCE NAME Before After ---------- -------------------------------------------------- ---------- ---------- sysstat IM simd KV add rows 0 0 sysstat IM simd KV probe calls 0 0 sysstat IM simd KV probe keys 0 0 sysstat IM simd KV probe rows 0 0 sysstat IM simd decode symbol calls 0 0 sysstat IM simd decode unpack calls 0 0 sysstat IM simd decode unpack selective calls 0 0

In-Memory Vectorized Joinが、利用されたかどうかを判断しやすいというわけではないですが、システム統計の差分で判断するのも、ありといえばアリですかね。この結果をみると。
In-Memory Vectorized Joinを無効化すると、IM simd ***という複数の統計値が変化しなくなりました！
ただ、血液検査みたいなものなので、これは、一般的には、判断の敷居が上がる気がします。

もう少し簡易に動作有無が判断できるようになると良いのではないかと思います。

例えば、実行後の　NOTE)　等のテキストで、実行されたことが判断できる情報を付加してもらうとか。auto explainでもいいし、AWR SQLレポートや実行計画をリストするときに、追加で特定のビューを問い合わせると分かるとか、とか。

実行時間の差にも注目してみてください。

どちらもIn-Memory table full scanが行われた場合、このケースでIn-Memory Vectorized Joinを利用した場合、10％ほど改善しています、より効果的な場面で利用すれば大きな改善につながりそうではありますね。
In-Memory Vectorized Join 有効化　19.39 ms
In-Memory Vectorized Join 無効化　22.54 ms

明日も、やはり、担当は、私ですw

参考）
Oracle Database 21c / 8.3 Optimizing Joins Using In-Memory Deep Vectorization

Related article on Mac De Oracle
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 1 / TABLE FULL SCAN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 2 / INDEX UNIQUE SCAN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 3 / INDEX RANGE SCAN, Index Only Scan
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 4 / INDEX RANGE SCAN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 5 / INDEX RANGE SCAN, INLIST ITERATOR
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 6 / INDEX FAST SCAN, Index Only Scan
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 7 / INDEX FULL SCAN,Index Only Scan
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 8 / INDEX SKIP SCAN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 9 / TABLE ACCESS INMEMORY FULL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 10 / NESTED LOOP JOIN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 11 / MERGE JOIN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 12 / HASH JOIN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 13 / HASH JOIN OUTER
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 14 / HASH JOIN FULL OUTER
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 15 / PX, TABLE ACCESS FULL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 16 / CONCATENATION
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 17 / SORT UNIQUE, UNION-ALL = UNION
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 18 / UNION-ALL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 19 / INTERSECTION
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 20 / MINUS
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 21 / WINDOW NOSORT STOPKEY
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 22 / COUNT STOPKEY
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 23 / HASH JOIN - LEFT-DEEP JOIN vs RIGHT-DEEP JOIN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 24 / CONNECT BY NO FILTERING WITH START-WITH
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 25 / UNION ALL (RECURSIVE WITH) DEPTH FIRST, RECURSIVE WITH PUMP
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#1 / STAR TRANSFORM, VECTOR TRANSFORM (DWH向け)
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#2 / MERGE (UPSERT)
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#3 / RDFView
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#4 / INDEX FULL SCAN (MIN/MAX) - Index Only Scan
・実行計画は, SQL文のレントゲン写真だ！ No.30 - LOAD TABLE CONVENTIONAL vs. LOAD AS SELECT
・実行計画は, SQL文のレントゲン写真だ！ No.31 - TEMP TABLE TRANSFORMATION LOAD AS SELECT (CURSOR DURATION MEMORY)
・実行計画は, SQL文のレントゲン写真だ！ No.32 - EXTERNAL TABLE ACCESS FULL / INMEMORY FULL
・実行計画は, SQL文のレントゲン写真だ！ No.33 - BITMAP CONVERSION TO ROWIDS
・実行計画は, SQL文のレントゲン写真だ！ No.34 - 似て非なるもの　USE_CONCAT　と　OR_EXPAND ヒントと　手書きSQLのレントゲンの見分け方
 ・実行計画は, SQL文のレントゲン写真だ！ No.35 - 似て非なるもの USE_CONCAT と OR_EXPANDヒントとパラレルクエリー
 ・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 1　/ No.36 / INTERSECT ALL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 2　/ No.37 / MINUS ALL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 3　/ No.38 / EXCEPT and EXCEPT ALL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 4 / No.39 / In-Memory Hybrid Scans
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 5 / No.40 / PIVOT and UNPIVOT

投稿日時 2022年12月 6日 (火) 00時00分 Oracle, チューニング, SQL, パフォーマンス, Advent Calendar, 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

Related article on Mac De Oracle ・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 1 / TABLE FULL SCAN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 2 / INDEX UNIQUE SCAN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 3 / INDEX RANGE SCAN, Index Only Scan
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 4 / INDEX RANGE SCAN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 5 / INDEX RANGE SCAN, INLIST ITERATOR
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 6 / INDEX FAST SCAN, Index Only Scan
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 7 / INDEX FULL SCAN,Index Only Scan
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 8 / INDEX SKIP SCAN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 9 / TABLE ACCESS INMEMORY FULL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 10 / NESTED LOOP JOIN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 11 / MERGE JOIN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 12 / HASH JOIN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 13 / HASH JOIN OUTER
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 14 / HASH JOIN FULL OUTER
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 15 / PX, TABLE ACCESS FULL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 16 / CONCATENATION
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 17 / SORT UNIQUE, UNION-ALL = UNION
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 18 / UNION-ALL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 19 / INTERSECTION
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 20 / MINUS
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 21 / WINDOW NOSORT STOPKEY
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 22 / COUNT STOPKEY
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 23 / HASH JOIN - LEFT-DEEP JOIN vs RIGHT-DEEP JOIN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 24 / CONNECT BY NO FILTERING WITH START-WITH
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 25 / UNION ALL (RECURSIVE WITH) DEPTH FIRST, RECURSIVE WITH PUMP
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#1 / STAR TRANSFORM, VECTOR TRANSFORM (DWH向け)
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#2 / MERGE (UPSERT)
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#3 / RDFView
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#4 / INDEX FULL SCAN (MIN/MAX) - Index Only Scan
・実行計画は, SQL文のレントゲン写真だ！ No.30 - LOAD TABLE CONVENTIONAL vs. LOAD AS SELECT
・実行計画は, SQL文のレントゲン写真だ！ No.31 - TEMP TABLE TRANSFORMATION LOAD AS SELECT (CURSOR DURATION MEMORY)
・実行計画は, SQL文のレントゲン写真だ！ No.32 - EXTERNAL TABLE ACCESS FULL / INMEMORY FULL
・実行計画は, SQL文のレントゲン写真だ！ No.33 - BITMAP CONVERSION TO ROWIDS
・実行計画は, SQL文のレントゲン写真だ！ No.34 - 似て非なるもの　USE_CONCAT　と　OR_EXPAND ヒントと　手書きSQLのレントゲンの見分け方
 ・実行計画は, SQL文のレントゲン写真だ！ No.35 - 似て非なるもの USE_CONCAT と OR_EXPANDヒントとパラレルクエリー
 ・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 1　/ No.36 / INTERSECT ALL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 2　/ No.37 / MINUS ALL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 3　/ No.38 / EXCEPT and EXCEPT ALL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 4　/ No.39 / In-Memory Hybrid Scans

投稿日時 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年12月 4日 (日)

実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 4　/ No.39 / In-Memory Hybrid Scans

reviously on Mac De Oracle...
Day3は, Oracleの場合の　EXCEPT/EXCEPT ALLは, 内部で MINUS/MINUS ALLになってるね. やってること同じだし. SQLのキーワードが違うだけなので, まあ, そりゃそうだという感じの実装になっているようだ.
というところを, 実行計画という名のレントゲンで確認しましたw

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

タイトルの通り, SQL単体ではなく, 実行計画上の新機能を診てみたいと思います. 狙い通りのレントゲンが取れるでしょうか. . . .

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

SCOTT@orclpdb1> select banner from v$version; BANNER ---------------------------------------------------------------------- Oracle Database 21c Enterprise Edition Release 21.0.0.0.0 - Production

なお, 今回は, in-memory機能を利用するのでお約束の　inmemory_size　パラメータを確認しておきますよ.
以前, 何度かセットし忘れで in-memory 発動せず！
みたいなこと何度かやらかしてたのことを思い出しますw
ちなみに, この　inmemory_size パラメータのデフォルトは 0

SYS@ORCLCDB> show parameter inmemory_size NAME TYPE VALUE ------------------------------------ --------------------------------- ------------------------------ inmemory_size big integer 112M

まず, 準備から. データサイズが大したことないのと, データのカーディナリティもあまり深く考えてなかったのでイマイチかも知れません.

in-memory columnsと no in-memory columnsを持つ表を作成します. In-Memory Hybrid Scansは, 同一表の列がインメモリーだったり非インメモリーだったという状況で効果のある操作なので. :)

SCOTT@orclpdb1> @day4 表が削除されました. 経過: 00:00:04.17 1 CREATE TABLE day4 2 ( 3 no_im_id NUMBER 4 , im_subid NUMBER 5 , no_im_str VARCHAR2(1000) 6 , im_str VARCHAR2(1000) 7 ) 8 INMEMORY PRIORITY HIGH 9 MEMCOMPRESS FOR CAPACITY LOW 10 NO INMEMORY ( 11 no_im_id 12 , no_im_str 13* ) 表が作成されました. 経過: 00:00:00.02 1 BEGIN 2 FOR i IN 1..100000 LOOP 3 INSERT 4 INTO day4 5 VALUES(i, i+1000, LPAD(TO_CHAR(i),1000,'*'), LPAD(TO_CHAR(i+1000),1000.,'*')); 6 IF MOD(i,100) = 0 7 THEN 8 COMMIT; 9 END IF; 10 END LOOP; 11* END; PL/SQLプロシージャが正常に完了しました. 経過: 00:00:16.88

定義を確認しておきましょうね.

1 SELECT 2 table_name 3 , inmemory_compression "compression" 4 , inmemory_priority "priority" 5 FROM 6 user_tables 7 WHERE 8* table_name = 'DAY4' TABLE_NAME compression priority ---------- --------------------------------------------------- ------------------------ DAY4 FOR CAPACITY LOW HIGH 経過: 00:00:00.00 1 SELECT 2 obj_num 3 , segment_column_id 4 , inmemory_compression 5 FROM 6 v$im_column_level im 7 INNER JOIN dba_objects do 8 ON 9 im.obj_num = do.object_id 10 WHERE 11* do.object_name = 'DAY4' OBJ_NUM SEGMENT_COLUMN_ID INMEMORY_COM ---------- ----------------- ------------ 77251 1 NO INMEMORY 77251 2 DEFAULT 77251 3 NO INMEMORY 77251 4 DEFAULT 経過: 00:00:00.01

データのPOPULATEを行います. 必要な列はすべてインメモリーにPOPULATEされたようです:)

1 SELECT 2 /*+ 3 FULL(day4) 4 NO_PARALLEL(day4) 5 */ 6 COUNT(*) 7 FROM 8* day4 COUNT(*) ---------- 100000 経過: 00:00:00.08 1 SELECT 2 segment_name 3 , inmemory_size 4 , bytes_not_populated 5 FROM 6* v$im_segments SEGMENT_NAME INMEMORY_SIZE BYTES_NOT_POPULATED ------------ ------------- ------------------- DAY4 15990784 0 経過: 00:00:00.01

準備運動からw　SELECT LISTにある２列は, どちらも非インメモリー列なので, 結果としてはよく見る　table full scanになります. 当然の結果ですね.

1 SELECT 2 MAX(no_im_id) 3 , COUNT(no_im_str) 4 FROM 5* day4 MAX(NO_IM_ID) COUNT(NO_IM_STR) ------------- ---------------- 100000 100000 経過: 00:00:00.09 実行計画 ---------------------------------------------------------- Plan hash value: 2217228964 --------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | --------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 1 | 515 | 9104 (1)| 00:00:01 | | 1 | SORT AGGREGATE | | 1 | 515 | | | | 2 | TABLE ACCESS FULL| DAY4 | 87887 | 43M| 9104 (1)| 00:00:01 | --------------------------------------------------------------------------- Note ----- - dynamic statistics used: dynamic sampling (level=2) 統計 ---------------------------------------------------------- 0 recursive calls 0 db block gets 33544 consistent gets 0 physical reads 0 redo size 685 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

ベタな検証その2. 今度は, SELECT LISTの2列はどちらもインメモリー列です. 結果はみなさんの想像の通り, TABLE ACCESS INMEMORY FULLです.
consistent getsが非常に少なくなっています. （処理時間的なところはまあ, データ量次第なので大きな差にはなってないですね. 深く分析していないので, 別の機会にデータ量などを変えつつ検証しておきたいですよね, この辺り）

1 SELECT 2 MAX(im_subid) 3 , COUNT(im_str) 4 FROM 5* day4 MAX(IM_SUBID) COUNT(IM_STR) ------------- ------------- 101000 100000 経過: 00:00:00.10 実行計画 ---------------------------------------------------------- Plan hash value: 2217228964 ------------------------------------------------------------------------------------ | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ------------------------------------------------------------------------------------ | 0 | SELECT STATEMENT | | 1 | 515 | 382 (13)| 00:00:01 | | 1 | SORT AGGREGATE | | 1 | 515 | | | | 2 | TABLE ACCESS INMEMORY FULL| DAY4 | 87887 | 43M| 382 (13)| 00:00:01 | ------------------------------------------------------------------------------------ Note ----- - dynamic statistics used: dynamic sampling (level=2) 統計 ---------------------------------------------------------- 0 recursive calls 0 db block gets 11 consistent gets 0 physical reads 0 redo size 683 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

次に, in-memory hybrid scan発動の条件に該当しない例をみてみましょう.
このクエリーでは, SELECT　LISTにインメモリー列のみ. WHERE句に非インメモリー列のみがありますが, これは, in-memory hybrid scan発動条件に一致しません.

結果として, 通常のTABLE ACCESS FULLとなってしまいますので注意しましょうね.

1 SELECT 2 MAX(im_subid) 3 , COUNT(im_str) 4 FROM 5 day4 6 WHERE 7* no_im_id < 5000 MAX(IM_SUBID) COUNT(IM_STR) ------------- ------------- 5999 4999 経過: 00:00:00.08 実行計画 ---------------------------------------------------------- Plan hash value: 2217228964 --------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | --------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 1 | 528 | 9104 (1)| 00:00:01 | | 1 | SORT AGGREGATE | | 1 | 528 | | | |* 2 | TABLE ACCESS FULL| DAY4 | 4794 | 2471K| 9104 (1)| 00:00:01 | --------------------------------------------------------------------------- Predicate Information (identified by operation id): --------------------------------------------------- 2 - filter("NO_IM_ID"<5000) Note ----- - dynamic statistics used: dynamic sampling (level=2) 統計 ---------------------------------------------------------- 0 recursive calls 0 db block gets 33544 consistent gets 0 physical reads 0 redo size 684 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

最後に, 本日の主役の登場です！

SELECT LISTには, 非インメモリー列のみ. WHERE句には, インメモリー列のみが利用されています. これが発動条件です.
結果として, これまで, みたことのないOperationである, 　TABLE ACCESS INMEMORY FULL (HYBRID)　が現れています. ふむふむ.
consistent getsもかなり少ないですし, このケースでは, 処理時間も早くなっていますね. ますます別途詳しく調査したくなりまし:)

なんとなくですが, この　in-memory hybrid scan　を見て, MySQL Heatwaveが浮かんできますよね. 諸々応用しているのでしょうかね...

1 SELECT 2 MAX(no_im_id) 3 , COUNT(no_im_str) 4 FROM 5 day4 6 WHERE 7* im_subid < 5000 MAX(NO_IM_ID) COUNT(NO_IM_STR) ------------- ---------------- 3999 3999 経過: 00:00:00.02 実行計画 ---------------------------------------------------------- Plan hash value: 2217228964 --------------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | --------------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 1 | 528 | 9104 (1)| 00:00:01 | | 1 | SORT AGGREGATE | | 1 | 528 | | | |* 2 | TABLE ACCESS INMEMORY FULL (HYBRID)| DAY4 | 1598 | 823K| 9104 (1)| 00:00:01 | --------------------------------------------------------------------------------------------- Predicate Information (identified by operation id): --------------------------------------------------- 2 - filter("IM_SUBID"<5000) Note ----- - dynamic statistics used: dynamic sampling (level=2) 統計 ---------------------------------------------------------- 0 recursive calls 0 db block gets 1342 consistent gets 0 physical reads 0 redo size 687 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

アドベントカレンダー, 全部俺をやらなきゃ, 師走は走り回るほど忙しいわけではないはずだったのになぁw　と, 遠ーーーくを見てるw

では, また,

明日の担当も！　私です.

参考 Database In-Memory Office Hours / In-Memory Hybrid Scans

そして, Ask Tomがこんな感じになるとは:) いい感じですよね.
Database In-Memory Office Hours / ASK TOM

Database In-Memory Guide / 21c

Related article on Mac De Oracle
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 1 / TABLE FULL SCAN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 2 / INDEX UNIQUE SCAN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 3 / INDEX RANGE SCAN, Index Only Scan
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 4 / INDEX RANGE SCAN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 5 / INDEX RANGE SCAN, INLIST ITERATOR
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 6 / INDEX FAST SCAN, Index Only Scan
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 7 / INDEX FULL SCAN,Index Only Scan
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 8 / INDEX SKIP SCAN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 9 / TABLE ACCESS INMEMORY FULL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 10 / NESTED LOOP JOIN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 11 / MERGE JOIN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 12 / HASH JOIN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 13 / HASH JOIN OUTER
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 14 / HASH JOIN FULL OUTER
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 15 / PX, TABLE ACCESS FULL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 16 / CONCATENATION
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 17 / SORT UNIQUE, UNION-ALL = UNION
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 18 / UNION-ALL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 19 / INTERSECTION
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 20 / MINUS
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 21 / WINDOW NOSORT STOPKEY
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 22 / COUNT STOPKEY
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 23 / HASH JOIN - LEFT-DEEP JOIN vs RIGHT-DEEP JOIN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 24 / CONNECT BY NO FILTERING WITH START-WITH
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 25 / UNION ALL (RECURSIVE WITH) DEPTH FIRST, RECURSIVE WITH PUMP
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#1 / STAR TRANSFORM, VECTOR TRANSFORM (DWH向け)
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#2 / MERGE (UPSERT)
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#3 / RDFView
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#4 / INDEX FULL SCAN (MIN/MAX) - Index Only Scan
・実行計画は, SQL文のレントゲン写真だ！ No.30 - LOAD TABLE CONVENTIONAL vs. LOAD AS SELECT
・実行計画は, SQL文のレントゲン写真だ！ No.31 - TEMP TABLE TRANSFORMATION LOAD AS SELECT (CURSOR DURATION MEMORY)
・実行計画は, SQL文のレントゲン写真だ！ No.32 - EXTERNAL TABLE ACCESS FULL / INMEMORY FULL
・実行計画は, SQL文のレントゲン写真だ！ No.33 - BITMAP CONVERSION TO ROWIDS
・実行計画は, SQL文のレントゲン写真だ！ No.34 - 似て非なるもの　USE_CONCAT　と　OR_EXPAND ヒントと　手書きSQLのレントゲンの見分け方
 ・実行計画は, SQL文のレントゲン写真だ！ No.35 - 似て非なるもの USE_CONCAT と OR_EXPANDヒントとパラレルクエリー
 ・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 1　/ No.36 / INTERSECT ALL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 2　/ No.37 / MINUS ALL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 3　/ No.38 / EXCEPT and EXCEPT ALL

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

2022年12月 3日 (土)

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

Day 2は, Oracleの方言である集合演算 MINUS ALL の実行計画というレントゲンを確認しました. MINUSでも19cまでは, ALLはサポートされていませんでした. サポートされるようになった理由は, 今日レントゲンを見ていくEXCEPT/EXCEPT ALLのサポートが影響してそうですね. やることは同じですので:)

では,　お約束のw
なお, 今回のSQL文の結果セットはソートされているように並んでいますが, たまたま昇順に並んでいるだけなので, ソートが必要な場合は. 必ず. ORDER BY句を付けてくださいね.

ということで, Day 3の窓を開けましょう！

MINUSは方言ですが, 標準SQLに合わせた形で同様の機能を持つEXCEPTがサポートされました. また, 方言であるMINUSも同様にサポートは継続されています. 下位互換の意味もあると思いますが, MINUS/MINUS ALLの実行計画というレントゲンと比較しながら見ると良いと思います.

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

SCOTT@orclpdb1> select banner from v$version; BANNER ---------------------------------------------------------------------- Oracle Database 21c Enterprise Edition Release 21.0.0.0.0 - Production

Day 1と同じ表とデータを利用します(再掲). 意図的に, 該当表には索引を作成していません.

SCOTT@orclpdb1> @day3 1 SELECT 2 num 3 FROM 4* groupa NUM ---------- 1 2 2 3 4 4 5 7行が選択されました. 1 SELECT 2 num 3 FROM 4* groupb NUM ---------- 0 2 3 3 4 4 4 7 8行が選択されました.

最初は, EXCEPT ALL から診てみます 実行計画を見て〜〜〜〜〜〜くださ〜〜〜〜い, 驚きますよ！！！！　

内部では, MINUS ALL　に書き換えられている！！　これが MINUS ALLをサポートした理由ですねw　やってることが同じなので, まあ無駄が無いのは確かだw

EXCEPT ALLが内部で, MINUS ALLに書き換えられているのでしょうか. 今回はトレースを取得して追いかける余力はないので, その辺りは別の機会にでも.
また, このケースでもHASH操作が現れています.

1 SELECT 2 num 3 FROM 4 groupa 5 EXCEPT ALL 6 SELECT 7 num 8 FROM 9* groupb NUM ---------- 1 2 5 実行計画 ---------------------------------------------------------- Plan hash value: 895579533 ----------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ----------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 7 | 45 | 8 (25)| 00:00:01 | | 1 | MINUS ALL HASH | | | | | | | 2 | TABLE ACCESS FULL| GROUPA | 7 | 21 | 3 (0)| 00:00:01 | | 3 | TABLE ACCESS FULL| GROUPB | 8 | 24 | 3 (0)| 00:00:01 | ----------------------------------------------------------------------------- 統計 ---------------------------------------------------------- 0 recursive calls 0 db block gets 12 consistent gets 0 physical reads 0 redo size 648 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

次は, EXCEPT 同様に, HASH操作を伴うMINUSとして現れています. やっている集合演算も同じですから, 実行計画だけ見せられたら, EXCEPTなのかMINUSなのかは区別できないでしょうね. 区別する必要もないわけですけども.
プロジェクトのSQL標準がどちらを使うか定めていれば, どちらかなのかは想像できるかも知れませんがw

1 SELECT 2 num 3 FROM 4 groupa 5 EXCEPT 6 SELECT 7 num 8 FROM 9* groupb NUM ---------- 1 5 実行計画 ---------------------------------------------------------- Plan hash value: 2352437695 ----------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ----------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 7 | 45 | 8 (25)| 00:00:01 | | 1 | MINUS HASH | | | | | | | 2 | TABLE ACCESS FULL| GROUPA | 7 | 21 | 3 (0)| 00:00:01 | | 3 | TABLE ACCESS FULL| GROUPB | 8 | 24 | 3 (0)| 00:00:01 | ----------------------------------------------------------------------------- 統計 ---------------------------------------------------------- 0 recursive calls 0 db block gets 12 consistent gets 0 physical reads 0 redo size 640 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) 2 rows processed

次に, 索引アクセスがある場合はどうなるかを確認します.　利用するデータや表はDay1と同じです.(再掲) なお, 索引等の情報は前回のエントリーをご覧ください

1 SELECT 2 unique_id 3 FROM 4 tab311 5 WHERE 6* unique_id BETWEEN 1 AND 50 UNIQUE_ID ---------- 1 1 1 2 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 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 53行が選択されました. 1 SELECT 2 unique_id 3 FROM 4 tab312 5 WHERE 6* unique_id BETWEEN 25 AND 75 UNIQUE_ID ---------- 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 51行が選択されました.

まずは, EXCEPT ALLから Table Full Scanであろうが, Index Range Scanであろうが, HASH操作になる点も含め, MINUS ALLそのものですね:)

1 SELECT 2 unique_id 3 FROM 4 tab311 5 WHERE 6 unique_id BETWEEN 1 AND 50 7 EXCEPT ALL 8 SELECT 9 unique_id 10 FROM 11 tab312 12 WHERE 13* unique_id BETWEEN 25 AND 75 UNIQUE_ID ---------- 1 1 1 2 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 27行が選択されました. 実行計画 ---------------------------------------------------------- Plan hash value: 381125746 --------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | --------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 50 | 612 | 8 (25)| 00:00:01 | | 1 | MINUS ALL HASH | | | | | | |* 2 | INDEX RANGE SCAN| TAB311_PK | 50 | 300 | 3 (0)| 00:00:01 | |* 3 | INDEX RANGE SCAN| IX01_TAB312 | 52 | 312 | 3 (0)| 00:00:01 | --------------------------------------------------------------------------------- Predicate Information (identified by operation id): --------------------------------------------------- 2 - access("UNIQUE_ID">=1 AND "UNIQUE_ID"<=50) 3 - access("UNIQUE_ID">=25 AND "UNIQUE_ID"<=75)v 統計 ---------------------------------------------------------- 0 recursive calls 0 db block gets 6 consistent gets 0 physical reads 0 redo size 1040 bytes sent via SQL*Net to client 63 bytes received via SQL*Net from client 3 SQL*Net roundtrips to/from client 0 sorts (memory) 0 sorts (disk) 27 rows processed

EXCEPTの実行計画という名のレントゲンはどうでしょう？

思った通り MINUS と同じ実行計画が現れています

1 SELECT 2 unique_id 3 FROM 4 tab311 5 WHERE 6 unique_id BETWEEN 1 AND 50 7 EXCEPT 8 SELECT 9 unique_id 10 FROM 11 tab312 12 WHERE 13* unique_id BETWEEN 25 AND 75 UNIQUE_ID ---------- 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 24行が選択されました. 実行計画 ---------------------------------------------------------- Plan hash value: 2829086308 ----------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ----------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 50 | 612 | 8 (25)| 00:00:01 | | 1 | MINUS | | | | | | | 2 | SORT UNIQUE NOSORT| | | | | | |* 3 | INDEX RANGE SCAN | TAB311_PK | 50 | 300 | 3 (0)| 00:00:01 | | 4 | SORT UNIQUE NOSORT| | | | | | |* 5 | INDEX RANGE SCAN | IX01_TAB312 | 52 | 312 | 3 (0)| 00:00:01 | ----------------------------------------------------------------------------------- Predicate Information (identified by operation id): --------------------------------------------------- 3 - access("UNIQUE_ID">=1 AND "UNIQUE_ID"<=50) 5 - access("UNIQUE_ID">=25 AND "UNIQUE_ID"<=75) 統計 ---------------------------------------------------------- 0 recursive calls 0 db block gets 9 consistent gets 0 physical reads 0 redo size 993 bytes sent via SQL*Net to client 63 bytes received via SQL*Net from client 3 SQL*Net roundtrips to/from client 0 sorts (memory) 0 sorts (disk) 24 rows processed

19cでは, EXCEPT/EXCEPT ALLともに未サポートなので, どちらもシンタックスエラーです. 当然と言えば当然の結果です:)

SCOTT@orcl> select banner from v$version; BANNER -------------------------------------------------------------------------------- Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production

1 SELECT 2 unique_id 3 FROM 4 tab311 5 WHERE 6 unique_id BETWEEN 1 AND 50 7 EXCEPT ALL 8 SELECT 9 unique_id 10 FROM 11 tab312 12 WHERE 13* unique_id BETWEEN 25 AND 75 EXCEPT ALL * ERROR at line 7: ORA-00933: SQL command not properly ended

1 SELECT 2 unique_id 3 FROM 4 tab311 5 WHERE 6 unique_id BETWEEN 1 AND 50 7 EXCEPT 8 SELECT 9 unique_id 10 FROM 11 tab312 12 WHERE 13* unique_id BETWEEN 25 AND 75 EXCEPT * ERROR at line 7: ORA-00933: SQL command not properly ended

まだまだ, Day 3　ですねーーーーw

意外に多くの, ITアドベントカレンダー全部俺, または, 準全部俺（タイトルに全部俺って書いてないだけで, 多分, 全部俺になっちゃうでしょうーーっなカレンダー立てた方含め,
楽しんでやってきましょう. 　w

明日の Day 4の担当は, なんとーーーっ, 私ですw

では, また.

参考）

19c UNION [ALL], INTERSECTおよびMINUS演算子

21c The Set Operators

Related article on Mac De Oracle
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 1 / TABLE FULL SCAN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 2 / INDEX UNIQUE SCAN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 3 / INDEX RANGE SCAN, Index Only Scan
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 4 / INDEX RANGE SCAN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 5 / INDEX RANGE SCAN, INLIST ITERATOR
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 6 / INDEX FAST SCAN, Index Only Scan
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 7 / INDEX FULL SCAN,Index Only Scan
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 8 / INDEX SKIP SCAN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 9 / TABLE ACCESS INMEMORY FULL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 10 / NESTED LOOP JOIN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 11 / MERGE JOIN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 12 / HASH JOIN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 13 / HASH JOIN OUTER
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 14 / HASH JOIN FULL OUTER
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 15 / PX, TABLE ACCESS FULL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 16 / CONCATENATION
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 17 / SORT UNIQUE, UNION-ALL = UNION
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 18 / UNION-ALL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 19 / INTERSECTION
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 20 / MINUS
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 21 / WINDOW NOSORT STOPKEY
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 22 / COUNT STOPKEY
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 23 / HASH JOIN - LEFT-DEEP JOIN vs RIGHT-DEEP JOIN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 24 / CONNECT BY NO FILTERING WITH START-WITH
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 25 / UNION ALL (RECURSIVE WITH) DEPTH FIRST, RECURSIVE WITH PUMP
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#1 / STAR TRANSFORM, VECTOR TRANSFORM (DWH向け)
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#2 / MERGE (UPSERT)
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#3 / RDFView
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#4 / INDEX FULL SCAN (MIN/MAX) - Index Only Scan
・実行計画は, SQL文のレントゲン写真だ！ No.30 - LOAD TABLE CONVENTIONAL vs. LOAD AS SELECT
・実行計画は, SQL文のレントゲン写真だ！ No.31 - TEMP TABLE TRANSFORMATION LOAD AS SELECT (CURSOR DURATION MEMORY)
・実行計画は, SQL文のレントゲン写真だ！ No.32 - EXTERNAL TABLE ACCESS FULL / INMEMORY FULL
・実行計画は, SQL文のレントゲン写真だ！ No.33 - BITMAP CONVERSION TO ROWIDS
・実行計画は, SQL文のレントゲン写真だ！ No.34 - 似て非なるもの　USE_CONCAT　と　OR_EXPAND ヒントと　手書きSQLのレントゲンの見分け方
 ・実行計画は, SQL文のレントゲン写真だ！ No.35 - 似て非なるもの USE_CONCAT と OR_EXPANDヒントとパラレルクエリー
 ・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 1　/ No.36 / INTERSECT ALL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 2　/ No.37 / MINUS ALL

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

2022年12月 2日 (金)

実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 2　/ No.37 / MINUS ALL

Previously on Mac De Oracle...
帰ってきた！　実行計画は、SQL文のレントゲン写真だ！　Oracle Database (全部俺） Advent Calendar 2022始まっちゃいましたw

Day 1は, 19cまでのINTERSECTに加え, 21c（正確には20c）からサポートされたINTRESECT ALLの実行計画というレントゲンはどう見えるのか？を確認しました.
21cからはHASH操作が加わっているとことは興味深いので, HASH操作について観点を変えて実行計画というレントゲンを見ておかねば, という気がしていますね. 今のところ, おまけとして考えているところですw（ネタがキツくなったら普通にやるかもw）

ということで, Day 2の窓を開けましょう！

なお, 今回のSQL文の結果セットはソートされているように並んでいますが, たまたま昇順に並んでいるだけなので, ソートが必要な場合は, 必ず, ORDER BY句を付けてくださいね.

INTERSECTと同様に, 19cまでは, ALLがサポートされていなかったOracleの方言である集合演算 MINUS にも MINUS ALLがサポートされました.
21c以降で利用できます. 実際には20cですが世に出てくることは無かったわけで,　事実上21c以降といってもいいですよね（おそらく）

21cでみてみましょう.

SCOTT@orclpdb1> select banner from v$version; BANNER ---------------------------------------------------------------------- Oracle Database 21c Enterprise Edition Release 21.0.0.0.0 - Production

Day 1と同じ表とデータを利用します(再掲). 意図的に, 該当表には索引を作成していません.

SCOTT@orclpdb1> @day2 1 SELECT 2 num 3 FROM 4* groupa NUM ---------- 1 2 2 3 4 4 5 7行が選択されました. 1 SELECT 2 num 3 FROM 4* groupb NUM ---------- 0 2 3 3 4 4 4 7 8行が選択されました.

今回の主役, MINUS ALLの実行計画という名のレントゲンから診てみます.

OperationにMINUS ALLと現れています. わかりやすいですね. また, ここでもHASH操作が現れています. 21cの特徴でもあるので頭の片隅に置いといた方が良さそうです.

1 SELECT 2 num 3 FROM 4 groupa 5 MINUS ALL 6 SELECT 7 num 8 FROM 9* groupb NUM ---------- 1 2 5 実行計画 ---------------------------------------------------------- Plan hash value: 895579533 ----------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ----------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 7 | 45 | 8 (25)| 00:00:01 | | 1 | MINUS ALL HASH | | | | | | | 2 | TABLE ACCESS FULL| GROUPA | 7 | 21 | 3 (0)| 00:00:01 | | 3 | TABLE ACCESS FULL| GROUPB | 8 | 24 | 3 (0)| 00:00:01 | ----------------------------------------------------------------------------- 統計 ---------------------------------------------------------- 0 recursive calls 0 db block gets 12 consistent gets 0 physical reads 0 redo size 648 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

次にこれまでもサポートされていた, MINUSの実行計画という名のレントゲンから診てみます.

これも判断しやすいですね. キーワードとなるMINUSが, Operationに現れています. 同様に, HASHも.

1 SELECT 2 num 3 FROM 4 groupa 5 MINUS 6 SELECT 7 num 8 FROM 9* groupb NUM ---------- 1 5 実行計画 ---------------------------------------------------------- Plan hash value: 2352437695 ----------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ----------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 7 | 45 | 8 (25)| 00:00:01 | | 1 | MINUS HASH | | | | | | | 2 | TABLE ACCESS FULL| GROUPA | 7 | 21 | 3 (0)| 00:00:01 | | 3 | TABLE ACCESS FULL| GROUPB | 8 | 24 | 3 (0)| 00:00:01 | ----------------------------------------------------------------------------- 統計 ---------------------------------------------------------- 0 recursive calls 0 db block gets 12 consistent gets 0 physical reads 0 redo size 640 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) 2 rows processed

次に, 索引アクセスがある場合はどうなるかを確認します.　利用するデータや表はDay1と同じです.(再掲)
なお, 索引等の情報は前回のエントリーをご覧ください

1 SELECT 2 unique_id 3 FROM 4 tab311 5 WHERE 6* unique_id BETWEEN 1 AND 50 UNIQUE_ID ---------- 1 1 1 2 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 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 53行が選択されました. 1 SELECT 2 unique_id 3 FROM 4 tab312 5 WHERE 6* unique_id BETWEEN 25 AND 75 UNIQUE_ID ---------- 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 51行が選択されました.

まずは, MINUS ALLから

Table Full Scanであろうが, Index Range Scanであろうが, HASH操作になるというのも特徴のようですね. 興味深いです.

1 SELECT 2 unique_id 3 FROM 4 tab311 5 WHERE 6 unique_id BETWEEN 1 AND 50 7 MINUS ALL 8 SELECT 9 unique_id 10 FROM 11 tab312 12 WHERE 13* unique_id BETWEEN 25 AND 75 UNIQUE_ID ---------- 1 1 1 2 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 27行が選択されました. 実行計画 ---------------------------------------------------------- Plan hash value: 381125746 --------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | --------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 50 | 612 | 8 (25)| 00:00:01 | | 1 | MINUS ALL HASH | | | | | | |* 2 | INDEX RANGE SCAN| TAB311_PK | 50 | 300 | 3 (0)| 00:00:01 | |* 3 | INDEX RANGE SCAN| IX01_TAB312 | 52 | 312 | 3 (0)| 00:00:01 | --------------------------------------------------------------------------------- Predicate Information (identified by operation id): --------------------------------------------------- 2 - access("UNIQUE_ID">=1 AND "UNIQUE_ID"<=50) 3 - access("UNIQUE_ID">=25 AND "UNIQUE_ID"<=75) 統計 ---------------------------------------------------------- 0 recursive calls 0 db block gets 6 consistent gets 0 physical reads 0 redo size 1040 bytes sent via SQL*Net to client 63 bytes received via SQL*Net from client 3 SQL*Net roundtrips to/from client 0 sorts (memory) 0 sorts (disk) 27 rows processed

MINUSはどうでしょう？

お! やはり, 挙動が変わりますね. これは, 索引を利用することを重要視した結果と言えそうです. SORT UNIQUE NOSORTなので, ソートなしでUNIQUE操作を行っています. ソートのバイバスを重要視したということになりますね.
ここも非常に興味深い動きですね.

1 SELECT 2 unique_id 3 FROM 4 tab311 5 WHERE 6 unique_id BETWEEN 1 AND 50 7 MINUS 8 SELECT 9 unique_id 10 FROM 11 tab312 12 WHERE 13* unique_id BETWEEN 25 AND 75 UNIQUE_ID ---------- 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 24行が選択されました. 実行計画 ---------------------------------------------------------- Plan hash value: 2829086308 ----------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ----------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 50 | 612 | 8 (25)| 00:00:01 | | 1 | MINUS | | | | | | | 2 | SORT UNIQUE NOSORT| | | | | | |* 3 | INDEX RANGE SCAN | TAB311_PK | 50 | 300 | 3 (0)| 00:00:01 | | 4 | SORT UNIQUE NOSORT| | | | | | |* 5 | INDEX RANGE SCAN | IX01_TAB312 | 52 | 312 | 3 (0)| 00:00:01 | ----------------------------------------------------------------------------------- Predicate Information (identified by operation id): --------------------------------------------------- 3 - access("UNIQUE_ID">=1 AND "UNIQUE_ID"<=50) 5 - access("UNIQUE_ID">=25 AND "UNIQUE_ID"<=75) 統計 ---------------------------------------------------------- 0 recursive calls 0 db block gets 9 consistent gets 0 physical reads 0 redo size 993 bytes sent via SQL*Net to client 63 bytes received via SQL*Net from client 3 SQL*Net roundtrips to/from client 0 sorts (memory) 0 sorts (disk) 24 rows processed

では, 最後に, 19cでも実行計画という名のレントゲンを診ておきたいと思います.

SYS@orclcdb> select banner from v$version; BANNER -------------------------------------------------------------------------------- Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production

MINUS ALLは未サポートなので, シンタックスエラーになります.

SCOTT@orcl> @day2 1 SELECT 2 num 3 FROM 4 groupa 5 MINUS ALL 6 SELECT 7 num 8 FROM 9* groupb MINUS ALL * ERROR at line 5: ORA-00928: missing SELECT keyword

以前からサポートされているMINUS, やはり, SORT UNIQUE操作が利用されています. 21cのMINUSとは異なる動きのあることが見えてきます.

1 SELECT 2 num 3 FROM 4 groupa 5 MINUS 6 SELECT 7 num 8 FROM 9* groupb NUM ---------- 1 5 Execution Plan ---------------------------------------------------------- Plan hash value: 2070324559 ------------------------------------------------------------------------------ | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ------------------------------------------------------------------------------ | 0 | SELECT STATEMENT | | 7 | 45 | 8 (25)| 00:00:01 | | 1 | MINUS | | | | | | | 2 | SORT UNIQUE | | 7 | 21 | 4 (25)| 00:00:01 | | 3 | TABLE ACCESS FULL| GROUPA | 7 | 21 | 3 (0)| 00:00:01 | | 4 | SORT UNIQUE | | 8 | 24 | 4 (25)| 00:00:01 | | 5 | TABLE ACCESS FULL| GROUPB | 8 | 24 | 3 (0)| 00:00:01 | ------------------------------------------------------------------------------ Statistics ---------------------------------------------------------- 0 recursive calls 0 db block gets 12 consistent gets 0 physical reads 0 redo size 599 bytes sent via SQL*Net to client 421 bytes received via SQL*Net from client 2 SQL*Net roundtrips to/from client 2 sorts (memory) 0 sorts (disk) 2 rows processed

アドベントカレンダー, 今のところ順調だが, 25回分全てのネタを書き終わったわけではないので, 先はナゲーーーーーーーなーーーと, 遠ーーーくを見てるw

Day3の担当は, 私です. よろしくお願いしますw

では, また, 明日.

参考）

19c
UNION [ALL], INTERSECTおよびMINUS演算子

21c
The Set Operators

Related article on Mac De Oracle
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 1 / TABLE FULL SCAN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 2 / INDEX UNIQUE SCAN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 3 / INDEX RANGE SCAN, Index Only Scan
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 4 / INDEX RANGE SCAN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 5 / INDEX RANGE SCAN, INLIST ITERATOR
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 6 / INDEX FAST SCAN, Index Only Scan
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 7 / INDEX FULL SCAN,Index Only Scan
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 8 / INDEX SKIP SCAN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 9 / TABLE ACCESS INMEMORY FULL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 10 / NESTED LOOP JOIN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 11 / MERGE JOIN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 12 / HASH JOIN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 13 / HASH JOIN OUTER
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 14 / HASH JOIN FULL OUTER
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 15 / PX, TABLE ACCESS FULL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 16 / CONCATENATION
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 17 / SORT UNIQUE, UNION-ALL = UNION
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 18 / UNION-ALL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 19 / INTERSECTION
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 20 / MINUS
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 21 / WINDOW NOSORT STOPKEY
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 22 / COUNT STOPKEY
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 23 / HASH JOIN - LEFT-DEEP JOIN vs RIGHT-DEEP JOIN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 24 / CONNECT BY NO FILTERING WITH START-WITH
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 25 / UNION ALL (RECURSIVE WITH) DEPTH FIRST, RECURSIVE WITH PUMP
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#1 / STAR TRANSFORM, VECTOR TRANSFORM (DWH向け)
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#2 / MERGE (UPSERT)
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#3 / RDFView
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#4 / INDEX FULL SCAN (MIN/MAX) - Index Only Scan
・実行計画は, SQL文のレントゲン写真だ！ No.30 - LOAD TABLE CONVENTIONAL vs. LOAD AS SELECT
・実行計画は, SQL文のレントゲン写真だ！ No.31 - TEMP TABLE TRANSFORMATION LOAD AS SELECT (CURSOR DURATION MEMORY)
・実行計画は, SQL文のレントゲン写真だ！ No.32 - EXTERNAL TABLE ACCESS FULL / INMEMORY FULL
・実行計画は, SQL文のレントゲン写真だ！ No.33 - BITMAP CONVERSION TO ROWIDS
・実行計画は, SQL文のレントゲン写真だ！ No.34 - 似て非なるもの　USE_CONCAT　と　OR_EXPAND ヒントと　手書きSQLのレントゲンの見分け方
 ・実行計画は, SQL文のレントゲン写真だ！ No.35 - 似て非なるもの USE_CONCAT と OR_EXPANDヒントとパラレルクエリー
 ・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 1　/ No.36 / INTERSECT ALL

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

2022年12月 1日 (木)

実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 1　/ No.36 / INTERSECT ALL

さあ, 今年もやってきましたよ. 12月の風物詩ITアドベントカレンダーの季節が loL. 今年は久々に, 復活

実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺

最後まで体力とネタが持つでしょうかww （いや, なんとしてもネタを持たせないと
帰ってきた！　実行計画は、SQL文のレントゲン写真だ！　Oracle Database (全部俺） Advent Calendar 2022

Day 1の窓は, 他のデータベースでも話題になっている標準SQLへの対応ネタから.
Oracle 19cまでは未対応だった, いくつかの集合演算子が, 20c以降でサポートされるようになりました.

簡単なとこからですよー!（最初から飛ばしすぎると後半息切れするのでw）

前述の集合演算子の拡張で特徴的だなと感じたのは, 今までALLがサポートされていなかった演算子でALLが使えるようになった事ですよね！

今回は, ALLがサポートされたINTERSECTの実行計画を見て見ましょう.

INTERSETのレントゲンは以前も紹介していました(Oracle 19c以前の実行計画)
https://discus-hamburg.cocolog-nifty.com/mac_de_oracle/2019/12/post-9e4acc.html

今回のアドベントカレンダーでは, Oracle Database 21c Enterprise Edition を使います. (比較の為に, 旧リリースを使う場合もあります)

SCOTT@orclpdb1> select banner from v$version; BANNER ------------------------------------------------------------------------ Oracle Database 21c Enterprise Edition Release 21.0.0.0.0 - Production

groupa表と, groupbh表を用意しました. num列だけの単純な表です（なお, 索引は作っていません. 理由は単純な集合演算を行いたかったから:)

SCOTT@orclpdb1> @day1 1 SELECT 2 num 3 FROM 4* groupa NUM ---------- 1 2 2 3 4 4 5 7行が選択されました. 1 SELECT 2 num 3 FROM 4* groupb NUM ---------- 0 2 3 3 4 4 4 7 8行が選択されました.

上記のようなデータがあったとして, INTERSECT ALLするとどうなるか.

1 SELECT 2 num 3 FROM 4 groupa 5 INTERSECT ALL 6 SELECT 7 num 8 FROM 9* groupb NUM ---------- 2 3 4 4

INTERSECTION ALL HASH と出てますね.　21cではこれを手がかりに, INTERSECT ALL行われていると判断できますね.

INTERSECTION ALL, このケースだとHASH操作を組み合わせてる. ふむむむ 21cだからですかね. 以前まではなかったはずなので, 後半で19cを利用して試してみましょう.

実行計画 ---------------------------------------------------------- Plan hash value: 2581184127 -------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | -------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 7 | 45 | 8 (25)| 00:00:01 | | 1 | INTERSECTION ALL HASH| | | | | | | 2 | TABLE ACCESS FULL | GROUPA | 7 | 21 | 3 (0)| 00:00:01 | | 3 | TABLE ACCESS FULL | GROUPB | 8 | 24 | 3 (0)| 00:00:01 | --------------------------------------------------------------------------------

では, 以前のリリースからあったALL無しだとどうなるか. HASH操作も出てますね. 興味深い. 大量データを扱う場合は有利でしょうね.

1 SELECT 2 num 3 FROM 4 groupa 5 IINTERSECT 6 SELECT 7 num 8 FROM 9* groupb NUM ---------- 2 3 4 実行計画 ---------------------------------------------------------- Plan hash value: 3344747026 ----------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ----------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 7 | 45 | 8 (25)| 00:00:01 | | 1 | INTERSECTION HASH | | | | | | | 2 | TABLE ACCESS FULL| GROUPA | 7 | 21 | 3 (0)| 00:00:01 | | 3 | TABLE ACCESS FULL| GROUPB | 8 | 24 | 3 (0)| 00:00:01 | -----------------------------------------------------------------------------

では, HASHが選ばれない場合の簡単な例を.

表定義はこんな感じ. （削除フラグ！！！があるけど気にしないでね. 他のネタでも使いたいのでw）

名前 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) 名前 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)

索引関連はこんな感じ（索引スキャンしてもらうことを狙っています）

TABLE_NAME INDEX_NAME INDEX_TYPE UNIQUENESS ------------------------------ ------------------------------ ------------------------------ --------------------------- TAB311 TAB311_PK NORMAL UNIQUE TAB311 TAB311_IX_SUB_ITEM_CODE NORMAL NONUNIQUE TAB312 IX01_TAB312 NORMAL NONUNIQUE TAB312 IX02_TAB312 NORMAL NONUNIQUE TABLE_NAME INDEX_NAME COLUMN_NAME ------------------------------ ------------------------------ ------------------------------ TAB311 TAB311_IX_SUB_ITEM_CODE SUB_ITEM_CODE TAB311 TAB311_PK UNIQUE_ID TAB311 TAB311_PK SUB_ITEM_CODE TAB312 IX01_TAB312 UNIQUE_ID TAB312 IX02_TAB312 SUB_ITEM_CODE TAB312 IX01_TAB312 SUB_ITEM_CODE

以下のようなデータを用意しました.

1 SELECT 2 unique_id 3 FROM 4 tab311 5 WHERE 6* unique_id BETWEEN 1 AND 50 UNIQUE_ID ---------- 1 1 1 2 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 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 53行が選択されました. 1 SELECT 2 unique_id 3 FROM 4 tab312 5 WHERE 6* unique_id BETWEEN 25 AND 75 UNIQUE_ID ---------- 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 51行が選択されました.

INTERSECにしてみました. 索引が利用できる程度の取得件数なので索引を利用したSORT UNIQNE NOSORTが実行されています.
状況によっては, このようなケースもあることを思えておきましょうね. 索引利用が妥当なのかは個別の条件に応じて判断していく必要があります.
この場合は問題はないでしょう. ポイントはIndex only scanで必要最小限の範囲をアクセスして, かつ, 索引を利用してソートを回避しているところですね.

1 SELECT 2 unique_id 3 FROM 4 tab311 5 WHERE 6 unique_id BETWEEN 1 AND 50 7 INTERSECT 8 SELECT 9 unique_id 10 FROM 11 tab312 12 WHERE 13* unique_id BETWEEN 25 AND 75 UNIQUE_ID ---------- 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 26行が選択されました. 実行計画 ---------------------------------------------------------- Plan hash value: 547955931 ----------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ----------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 50 | 612 | 8 (25)| 00:00:01 | | 1 | INTERSECTION | | | | | | | 2 | SORT UNIQUE NOSORT| | | | | | |* 3 | INDEX RANGE SCAN | TAB311_PK | 50 | 300 | 3 (0)| 00:00:01 | | 4 | SORT UNIQUE NOSORT| | | | | | |* 5 | INDEX RANGE SCAN | IX01_TAB312 | 52 | 312 | 3 (0)| 00:00:01 | ----------------------------------------------------------------------------------- Predicate Information (identified by operation id): --------------------------------------------------- 3 - access("UNIQUE_ID">=1 AND "UNIQUE_ID"<=50) 5 - access("UNIQUE_ID">=25 AND "UNIQUE_ID"<=75)

おまけ, 19cでは INTERSECT ALLはサポートされいませんが, 実行計画の違いを見ておきましょう.

SCOTT@ORCL> select banner from v$version; BANNER -------------------------------------------------------------------------------- Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production

SCOTT@ORCL> @day1 1 SELECT 2 num 3 FROM 4* groupa NUM ---------- 1 2 2 3 4 4 5 7 rows selected. 1 SELECT 2 num 3 FROM 4* groupb NUM ---------- 0 2 3 3 4 4 4 7

19cでは当然, シンタックスエラーです.

1 SELECT 2 num 3 FROM 4 groupa 5 INTERSECT ALL 6 SELECT 7 num 8 FROM 9* groupb INTERSECT ALL * ERROR at line 5: ORA-00928: missing SELECT keyword

21cでは, HASH操作が行われてましたが, 19cでは, HASHの代わりに, SORT UNIQUEが現れていますね. 興味深い違いです. それぞれのリリースで同一統計情報で操作が変化する点は, しっかり押さえておきましょう. 今後のチューニングに役立つかもしれませんよー.

1 SELECT 2 num 3 FROM 4 groupa 5 INTERSECT 6 SELECT 7 num 8 FROM 9* groupb NUM ---------- 2 3 4 Execution Plan ---------------------------------------------------------- Plan hash value: 2012227029 ------------------------------------------------------------------------------ | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ------------------------------------------------------------------------------ | 0 | SELECT STATEMENT | | 7 | 45 | 8 (25)| 00:00:01 | | 1 | INTERSECTION | | | | | | | 2 | SORT UNIQUE | | 7 | 21 | 4 (25)| 00:00:01 | | 3 | TABLE ACCESS FULL| GROUPA | 7 | 21 | 3 (0)| 00:00:01 | | 4 | SORT UNIQUE | | 8 | 24 | 4 (25)| 00:00:01 | | 5 | TABLE ACCESS FULL| GROUPB | 8 | 24 | 3 (0)| 00:00:01 | ------------------------------------------------------------------------------

参考）

19c UNION [ALL], INTERSECTおよびMINUS演算子

21c The Set Operators

ひとまず, Day 1の窓をあけた. 明日に続く.

最後に、今回は、ORDER BY句を付加していませんが、付けてくださいよ。ソートが必要な場合は！！！！

今回の例ではたまたま昇順に並んでいるだけですからね。

Related article on Mac De Oracle

・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 1 / TABLE FULL SCAN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 2 / INDEX UNIQUE SCAN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 3 / INDEX RANGE SCAN, Index Only Scan
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 4 / INDEX RANGE SCAN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 5 / INDEX RANGE SCAN, INLIST ITERATOR
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 6 / INDEX FAST SCAN, Index Only Scan
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 7 / INDEX FULL SCAN,Index Only Scan
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 8 / INDEX SKIP SCAN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 9 / TABLE ACCESS INMEMORY FULL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 10 / NESTED LOOP JOIN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 11 / MERGE JOIN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 12 / HASH JOIN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 13 / HASH JOIN OUTER
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 14 / HASH JOIN FULL OUTER
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 15 / PX, TABLE ACCESS FULL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 16 / CONCATENATION
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 17 / SORT UNIQUE, UNION-ALL = UNION
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 18 / UNION-ALL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 19 / INTERSECTION
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 20 / MINUS
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 21 / WINDOW NOSORT STOPKEY
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 22 / COUNT STOPKEY
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 23 / HASH JOIN - LEFT-DEEP JOIN vs RIGHT-DEEP JOIN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 24 / CONNECT BY NO FILTERING WITH START-WITH
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 25 / UNION ALL (RECURSIVE WITH) DEPTH FIRST, RECURSIVE WITH PUMP
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#1 / STAR TRANSFORM, VECTOR TRANSFORM (DWH向け)
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#2 / MERGE (UPSERT)
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#3 / RDFView
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#4 / INDEX FULL SCAN (MIN/MAX) - Index Only Scan
・実行計画は, SQL文のレントゲン写真だ！ No.30 - LOAD TABLE CONVENTIONAL vs. LOAD AS SELECT
・実行計画は, SQL文のレントゲン写真だ！ No.31 - TEMP TABLE TRANSFORMATION LOAD AS SELECT (CURSOR DURATION MEMORY)
・実行計画は, SQL文のレントゲン写真だ！ No.32 - EXTERNAL TABLE ACCESS FULL / INMEMORY FULL
・実行計画は, SQL文のレントゲン写真だ！ No.33 - BITMAP CONVERSION TO ROWIDS
・実行計画は, SQL文のレントゲン写真だ！ No.34 - 似て非なるもの　USE_CONCAT　と　OR_EXPAND ヒントと　手書きSQLのレントゲンの見分け方
 ・実行計画は, SQL文のレントゲン写真だ！ No.35 - 似て非なるもの USE_CONCAT と OR_EXPANDヒントとパラレルクエリー

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

2022年11月23日 (水)

Oracle Database 20c 20.1.0以降〜21c 21.1.0で v$sql_hintに追加されたヒント/ FAQ

Oracle Database 21c 21.1.0 EEで。20.1.0以降で追加されたSQLヒントをみておく。

SYS@ORCLCDB> select * from v$sql_hint where version in ('20.1.0', '21.1.0') order by version,name; NAME SQL_FEATURE CLASS INVERSE TARGET_LEVEL PROPERTY VERSION VERSION_OU ------------------------------ ------------------------------ ------------------------------ ------------------------------ ------------ ---------- ---------- ---------- ANALYTIC_VIEW_SQL QKSFM_COMPILATION ANALYTIC_VIEW_SQL 2 0 20.1.0 DENORM_AV QKSFM_COMPILATION DENORM_AV 2 0 20.1.0 FORCE_JSON_TABLE_TRANSFORM QKSFM_JSON_REWRITE FORCE_JSON_TABLE_TRANSFORM NO_JSON_TABLE_TRANSFORM 1 0 20.1.0 20.1.0 NO_JSON_TABLE_TRANSFORM QKSFM_JSON_REWRITE FORCE_JSON_TABLE_TRANSFORM FORCE_JSON_TABLE_TRANSFORM 1 0 20.1.0 20.1.0 NO_SET_GBY_PUSHDOWN QKSFM_ALL SET_GBY_PUSHDOWN SET_GBY_PUSHDOWN 2 16 20.1.0 20.1.0 SET_GBY_PUSHDOWN QKSFM_ALL SET_GBY_PUSHDOWN NO_SET_GBY_PUSHDOWN 2 16 20.1.0 20.1.0 DAGG_OPTIM_GSETS QKSFM_GROUPING_SET_XFORM DAGG_OPTIM_GSETS NO_DAGG_OPTIM_GSETS 2 0 21.1.0 21.1.0 HASHSET_BUILD QKSFM_EXECUTION HASHSET_BUILD 2 16 21.1.0 21.1.0 NO_DAGG_OPTIM_GSETS QKSFM_GROUPING_SET_XFORM DAGG_OPTIM_GSETS DAGG_OPTIM_GSETS 2 0 21.1.0 21.1.0 NO_OBY_GBYPD_SEPARATE QKSFM_PQ OBY_GBYPD_SEPARATE OBY_GBYPD_SEPARATE 2 16 21.1.0 21.1.0 NO_PQ_NONLEAF_SKEW QKSFM_PQ PQ_NONLEAF_SKEW PQ_NONLEAF_SKEW 4 272 21.1.0 21.1.0 OBY_GBYPD_SEPARATE QKSFM_PQ OBY_GBYPD_SEPARATE NO_OBY_GBYPD_SEPARATE 2 16 21.1.0 21.1.0 ORDER_KEY_VECTOR_USE QKSFM_VECTOR_AGG ORDER_KEY_VECTOR_USE 2 272 21.1.0 21.1.0 OSON_GET_CONTENT QKSFM_JSON OSON_GET_CONTENT 1 0 21.1.0 21.1.0 PQ_NONLEAF_SKEW QKSFM_PQ PQ_NONLEAF_SKEW NO_PQ_NONLEAF_SKEW 4 272 21.1.0 21.1.0 15行が選択されました。

投稿日時 2022年11月23日 (水) 21時25分 FAQ, SQL, Oracle Database 21c | 固定リンク | 0 | コメント (0)

2022年11月10日 (木)

帰ってきた！　実行計画は、SQL文のレントゲン写真だ！　Oracle Database (全部俺） Advent Calendar 2022

Oracle Databaseの実行計画を中心にしていますが、他のDatabaseの実行計画も合わせて載せるかもしれません。

基本的に、全部俺で予定していますが、どうーーーしても、どうーーーしても、俺、私にも書かせろ！

という方は、ご連絡ください。:)

投稿日時 2022年11月10日 (木) 07時06分 Oracle, SQL, パフォーマンス, Advent Calendar | 固定リンク | 0 | コメント (0)

2022年7月 1日 (金)

explain plan文 De 索引サイズ見積 / FAQ

久々の投稿ですw

というか、Oracle ACEのKPIを考えるとどうしても、こうなってしまう大人の事情。

今期一発目の投稿は、意外と知られていない？　explain plan文 De 索引サイズ見積。

統計情報などに依存はしますが、100億年に一度ぐらい、索引サイズどれぐらいになるかねぇ。みたいな聞かれかたしたときに、サクっとタイプして、ほれ！

と、Slackでなげかえしちゃって、飲みに行きましょうね。そこ必死にやるところじゃない時代なわけで。

では、21cもあるのですが、データ仕込むのめんどくさかったので、ありもの 19cの環境で試してみましょう。ちなみに、explain plan で索引サイズを見積もるのは私の記憶によると10gぐらいから使ってた記憶はあるので、昔からのOraclerだと知ってる方は多いはず。(もっと前からあるよーというツッコミ歓迎w）

表の存在とデータを大量に登録してあるtest表を使います。統計は最新化

[oracle@localhost ~]$ sqlplus scott/tiger

SQL*Plus: Release 19.0.0.0.0 - Production on Wed Jun 29 22:59:46 2022
Version 19.3.0.0.0

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

Last Successful login time: Mon Jun 06 2022 21:39:58 -04:00

Connected to:
Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production
Version 19.3.0.0.0

SQL> desc test
Name　　　Null? Type
------- ------------------------ -------- ----------------------------
NUM NUMBER

SQL> exec dbms_stats.gather_table_stats(ownname=>'SCOTT',tabname=>'TEST',cascade=>true,no_invalidate=>false);

PL/SQL procedure successfully completed.

explain plan文でcreate index文を解析します。索引は作成されないので、躊躇なくタイプしちゃってくださいw
解析が終わったら、utlxpls.sqlを実行すれば見積もりサイズを確認できます。

10m行登録してるのでそれなりのサイズになるようですね。243MB という見積もりがでました！

SQL> explain plan for create index test on test(num);

Explained.

SQL> @?/rdbms/admin/utlxpls

PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------
Plan hash value: 2829245909

-------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
-------------------------------------------------------------------------------
| 0 | CREATE INDEX STATEMENT | | 10M| 57M| 9958 (1) | 00:00:01 |
| 1 | INDEX BUILD NON UNIQUE| TEST | | | | |
| 2 | SORT CREATE INDEX | | 10M| 57M| | |
| 3 | TABLE ACCESS FULL | TEST | 10M| 57M| 4414 (2) | 00:00:01 |
-------------------------------------------------------------------------------

PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------
Note
-----
- estimated index size: 243M bytes

14 rows selected.

SQL>

Explain plan文以外では、使い勝手が悪いというかタイプする文字数多くて嫌いな、DBMS_SPACE.CREATE_INDEX_COST()　があります。
以下のような無名PL/SQLブロックを書いておくか、あらかじめ俺俺関数(UDFね)として登録しておくと便利ですが、explain planでいいかなぁ。私はw

set serveroutput on
DECLARE
used_bytes NUMBER;
segment_bytes NUMBER;
BEGIN
DBMS_SPACE.CREATE_INDEX_COST (
ddl=> 'CREATE INDEX test ON test(num)'
, used_bytes => used_bytes
, alloc_bytes => segment_bytes
);
DBMS_OUTPUT.PUT_LINE('Segment Size (MB) :'||segment_bytes/1024/1024);
DBMS_OUTPUT.PUT_LINE('Index data Size (MB) :'||used_bytes/1024/1024);
END;
/

Explain planより情報量は多いですが、セグメントサイズがどれぐらいになるか知りたいわけなので、他の情報は捨てちゃうことが多い感じはします。
DBMS_SPACE.CREATE_INDEX_COST()パッケージプロシージャでは 232MB という見積もり結果となりました。

SQL> set serveroutput on
SQL> l
1 DECLARE
2 used_bytes NUMBER;
3 segment_bytes NUMBER;
4 BEGIN
5 DBMS_SPACE.CREATE_INDEX_COST (
6 ddl=> 'CREATE INDEX test ON test(num)'
7 , used_bytes => used_bytes
8 , alloc_bytes => segment_bytes
9 );
10 DBMS_OUTPUT.PUT_LINE('Segment Size (MB) :'||segment_bytes/1024/1024);
11 DBMS_OUTPUT.PUT_LINE('Index data Size (MB) :'||used_bytes/1024/1024);
12* END;
SQL> /
Segment Size (MB) :232
Index data Size (MB) :57.220458984375

PL/SQL procedure successfully completed.

SQL>

実際のセグメントサイズはどれぐらいでしょう？　実際に索引を作ったあとセグメントサイズをみてみました。

SQL> select segment_name,bytes/1024/1024 "MB" from user_segments where segment_name='TEST' and segment_type='INDEX';

SEGMENT_NAME MB
------------------------------ ----------
TEST 192

SQL>

今年も半年すぎたけど、アドベントカレンダー全部俺をやるべきか悩む。まとめてアウトプットするので、ちびちびアウトプットするのとどちらがよいか。。。w

では、また。

投稿日時 2022年7月 1日 (金) 04時05分 Oracle, PL/SQL, FAQ, SQL | 固定リンク | 0 | コメント (0)

2022年4月11日 (月)

実行計画は、SQL文のレントゲン写真だ！ No.35 - 似て非なるもの USE_CONCAT と OR_EXPANDヒントとパラレルクエリー

Previously on Mac De Oracle
前回は、その前のエントリーの流れから、標準はあるにはあるが癖の多いSQL - #27 LNNVL is 何？と思った方向けでちょいと脱線してました。
今日は、話を元に戻しますw

USE_CANTATとOR_EXPAND、レントゲン（実行計画）をみて、どこがどう違うのかは理解できたのではないかと思います。ではなぜ、今後使うとしたら、OR_EXPANDなのかは、USE_CONCATとより言うことを聞いてくれやすいという他にもう一つあるのですが、それは何かわかりますか？
大人の事情で、しばらく関わりが薄かった時期（w　にこのヒントの効果を知ったのですが、もう一つのメリットまでは知らなかったんですよw。　斜め読みだけしてると取りこぼしちゃいますねw

答えはパラレルクエリーにした場合の違い。

OR_EXPANDによる書き換えとUNION-ALLへの内部的な書き換えの効果で、パラレルクエリーとの相性が良くなっているんですよね。

早速、レントゲンをみてみましょう　:)
（あ、書き忘れてましたが、Oracle Database 21cを使ってます）

USE_CONCATを使ってCONCATENATION(Id=1のoperation)を強制してかつパラレルクエリーにしています。PX COORDINATOR が Id=2とId=9に現れているのでUNIONの各SELECT文はシリアルに実行されているようですね。この挙動は変わってなさそうです。

SCOTT@orclpdb1> r 1 select 2 /*+ 3 parallel(4) 4 use_concat 5 */ 6 * 7 from 8 tab311 9 where 10 unique_id= 1 11* or sub_item_code = '0001000000' 経過: 00:00:00.44 実行計画 ---------------------------------------------------------- Plan hash value: 1305058436 ----------------------------------------------------------------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | TQ |IN-OUT| PQ Distrib | ----------------------------------------------------------------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 4 | 1076 | 8 (0)| 00:00:01 | | | | | 1 | CONCATENATION | | | | | | | | | | 2 | PX COORDINATOR | | | | | | | | | | 3 | PX SEND QC (RANDOM) | :TQ20001 | 2 | 538 | 4 (0)| 00:00:01 | Q2,01 | P->S | QC (RAND) | | 4 | TABLE ACCESS BY INDEX ROWID BATCHED| TAB311 | 2 | 538 | 4 (0)| 00:00:01 | Q2,01 | PCWP | | | 5 | BUFFER SORT | | | | | | Q2,01 | PCWC | | | 6 | PX RECEIVE | | 1 | | 3 (0)| 00:00:01 | Q2,01 | PCWP | | | 7 | PX SEND HASH (BLOCK ADDRESS) | :TQ20000 | 1 | | 3 (0)| 00:00:01 | | S->P | HASH (BLOCK| |* 8 | INDEX RANGE SCAN | TAB311_IX_SUB_ITEM_CODE | 1 | | 3 (0)| 00:00:01 | | | | | 9 | PX COORDINATOR | | | | | | | | | | 10 | PX SEND QC (RANDOM) | :TQ10001 | 2 | 538 | 4 (0)| 00:00:01 | Q1,01 | P->S | QC (RAND) | | 11 | TABLE ACCESS BY INDEX ROWID BATCHED| TAB311 | 2 | 538 | 4 (0)| 00:00:01 | Q1,01 | PCWP | | | 12 | BUFFER SORT | | | | | | Q1,01 | PCWC | | | 13 | PX RECEIVE | | 1 | | 3 (0)| 00:00:01 | Q1,01 | PCWP | | | 14 | PX SEND HASH (BLOCK ADDRESS) | :TQ10000 | 1 | | 3 (0)| 00:00:01 | | S->P | HASH (BLOCK| |* 15 | INDEX RANGE SCAN | TAB311_PK | 1 | | 3 (0)| 00:00:01 | | | | ----------------------------------------------------------------------------------------------------------------------------------------------- Predicate Information (identified by operation id): --------------------------------------------------- 8 - access("SUB_ITEM_CODE"='0001000000') 15 - access("UNIQUE_ID"=1) filter(LNNVL("SUB_ITEM_CODE"='0001000000')) Note ----- - dynamic statistics used: dynamic sampling (level=AUTO (SYSTEM)) - Degree of Parallelism is 4 because of hint

OR_EXPANDでU内部的にUNION-ALLに書き換えてパラレルクエrーにすると。。。。。。おーーーーー。違う！！！ Id=1にあるPX COORDINATOR だけになってますね。各SELECT文もパラレル化されているようです。:)
結構違いますね。やはり、使うなら、USE_CANTATよりOR_EXPANDのようが良さそうですね。これで思い出した！　ORDERED　と LEADINGヒントのような感じですかねー。同じ機能を持つ後発ヒントの方が色々と使い勝手が良くなってることって意外に多いです！

SCOTT@orclpdb1> r 1 select 2 /*+ 3 parallel(4) 4 or_expand 5 */ 6 * 7 from 8 tab311 9 where 10 unique_id= 1 11* or sub_item_code = '0001000000' 経過: 00:00:00.14 実行計画 ---------------------------------------------------------- Plan hash value: 3317360125 ------------------------------------------------------------------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | TQ |IN-OUT| PQ Distrib | ------------------------------------------------------------------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 4 | 1160 | 8 (0)| 00:00:01 | | | | | 1 | PX COORDINATOR | | | | | | | | | | 2 | PX SEND QC (RANDOM) | :TQ10002 | 4 | 1160 | 8 (0)| 00:00:01 | Q1,02 | P->S | QC (RAND) | | 3 | BUFFER SORT | | 4 | 1160 | | | Q1,02 | PCWP | | | 4 | VIEW | VW_ORE_5F0E22D2 | 4 | 1160 | 8 (0)| 00:00:01 | Q1,02 | PCWP | | | 5 | UNION-ALL | | | | | | Q1,02 | PCWP | | | 6 | TABLE ACCESS BY INDEX ROWID BATCHED| TAB311 | 2 | 538 | 4 (0)| 00:00:01 | Q1,02 | PCWP | | | 7 | BUFFER SORT | | | | | | Q1,02 | PCWC | | | 8 | PX RECEIVE | | 1 | | 3 (0)| 00:00:01 | Q1,02 | PCWP | | | 9 | PX SEND HASH (BLOCK ADDRESS) | :TQ10000 | 1 | | 3 (0)| 00:00:01 | Q1,00 | S->P | HASH (BLOCK| | 10 | PX SELECTOR | | | | | | Q1,00 | SCWC | | |* 11 | INDEX RANGE SCAN | TAB311_PK | 1 | | 3 (0)| 00:00:01 | Q1,00 | SCWP | | |* 12 | TABLE ACCESS BY INDEX ROWID BATCHED| TAB311 | 2 | 538 | 4 (0)| 00:00:01 | Q1,02 | PCWP | | | 13 | BUFFER SORT | | | | | | Q1,02 | PCWC | | | 14 | PX RECEIVE | | 1 | | 3 (0)| 00:00:01 | Q1,02 | PCWP | | | 15 | PX SEND HASH (BLOCK ADDRESS) | :TQ10001 | 1 | | 3 (0)| 00:00:01 | Q1,01 | S->P | HASH (BLOCK| | 16 | PX SELECTOR | | | | | | Q1,01 | SCWC | | |* 17 | INDEX RANGE SCAN | TAB311_IX_SUB_ITEM_CODE | 1 | | 3 (0)| 00:00:01 | Q1,01 | SCWP | | ------------------------------------------------------------------------------------------------------------------------------------------------- Predicate Information (identified by operation id): --------------------------------------------------- 11 - access("UNIQUE_ID"=1) 12 - filter(LNNVL("UNIQUE_ID"=1)) 17 - access("SUB_ITEM_CODE"='0001000000') Note ----- - dynamic statistics used: dynamic sampling (level=AUTO (SYSTEM)) - Degree of Parallelism is 4 because of hint

前々回手動でunionに書き換えたSQLをパラレルにするとどうなるだろう。。。
ほう。

select /*+ parallel(4) */ * from tab311 where unique_id = 1 union select * from tab311 where sub_item_code = '0001000000'; 実行計画 ---------------------------------------------------------- Plan hash value: 3983264199 --------------------------------------------------------------------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | TQ |IN-OUT| PQ Distrib | --------------------------------------------------------------------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 5 | 1345 | 11 (19)| 00:00:01 | | | | | 1 | PX COORDINATOR | | | | | | | | | | 2 | PX SEND QC (RANDOM) | :TQ10003 | 5 | 1345 | 11 (19)| 00:00:01 | Q1,03 | P->S | QC (RAND) | | 3 | HASH UNIQUE | | 5 | 1345 | 11 (19)| 00:00:01 | Q1,03 | PCWP | | | 4 | PX RECEIVE | | 5 | 1345 | 11 (19)| 00:00:01 | Q1,03 | PCWP | | | 5 | PX SEND HASH | :TQ10002 | 5 | 1345 | 11 (19)| 00:00:01 | Q1,02 | P->P | HASH | | 6 | HASH UNIQUE | | 5 | 1345 | 11 (19)| 00:00:01 | Q1,02 | PCWP | | | 7 | UNION-ALL | | | | | | Q1,02 | PCWP | | | 8 | TABLE ACCESS BY INDEX ROWID BATCHED| TAB311 | 3 | 807 | 4 (0)| 00:00:01 | Q1,02 | PCWP | | | 9 | PX RECEIVE | | 3 | | 3 (0)| 00:00:01 | Q1,02 | PCWP | | | 10 | PX SEND HASH (BLOCK ADDRESS) | :TQ10000 | 3 | | 3 (0)| 00:00:01 | Q1,00 | S->P | HASH (BLOCK| | 11 | PX SELECTOR | | | | | | Q1,00 | SCWC | | |* 12 | INDEX RANGE SCAN | TAB311_PK | 3 | | 3 (0)| 00:00:01 | Q1,00 | SCWP | | | 13 | TABLE ACCESS BY INDEX ROWID BATCHED| TAB311 | 2 | 538 | 5 (0)| 00:00:01 | Q1,02 | PCWP | | | 14 | PX RECEIVE | | 2 | | 3 (0)| 00:00:01 | Q1,02 | PCWP | | | 15 | PX SEND HASH (BLOCK ADDRESS) | :TQ10001 | 2 | | 3 (0)| 00:00:01 | Q1,01 | S->P | HASH (BLOCK| | 16 | PX SELECTOR | | | | | | Q1,01 | SCWC | | |* 17 | INDEX RANGE SCAN | TAB311_IX_SUB_ITEM_CODE | 2 | | 3 (0)| 00:00:01 | Q1,01 | SCWP | | --------------------------------------------------------------------------------------------------------------------------------------------------- Predicate Information (identified by operation id): --------------------------------------------------- 12 - access("UNIQUE_ID"=1) 17 - access("SUB_ITEM_CODE"='0001000000') Note ----- - dynamic statistics used: dynamic sampling (level=AUTO (SYSTEM)) - Degree of Parallelism is 4 because of hint

同じく、前々回手動でunion all + フィルタ条件追加に書き換えたSQLをパラレルにするとどうなるだろう。。。
おおおおおーーーーーーっと。これはCONCATENATIONの実行計画にそっくりですね。CONCATENATIONの部分がUNION-ALLになっている程度の違い。2つのPX COORDINATOR がある点も共通しています。。。むむ。

このSQLをOR_EXPANDの実行計画と同じようにするには......あ！　あれだ！

select /*+ parallel(4) */ * from tab311 where unique_id = 1 union all select * from tab311 where sub_item_code = '0001000000' and LNNVL(unique_id=1); 実行計画 ---------------------------------------------------------- Plan hash value: 1844591072 ----------------------------------------------------------------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | TQ |IN-OUT| PQ Distrib | ----------------------------------------------------------------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 4 | 1076 | 9 (0)| 00:00:01 | | | | | 1 | UNION-ALL | | | | | | | | | | 2 | PX COORDINATOR | | | | | | | | | | 3 | PX SEND QC (RANDOM) | :TQ10001 | 3 | 807 | 4 (0)| 00:00:01 | Q1,01 | P->S | QC (RAND) | | 4 | TABLE ACCESS BY INDEX ROWID BATCHED| TAB311 | 3 | 807 | 4 (0)| 00:00:01 | Q1,01 | PCWP | | | 5 | BUFFER SORT | | | | | | Q1,01 | PCWC | | | 6 | PX RECEIVE | | 3 | | 3 (0)| 00:00:01 | Q1,01 | PCWP | | | 7 | PX SEND HASH (BLOCK ADDRESS) | :TQ10000 | 3 | | 3 (0)| 00:00:01 | Q1,00 | S->P | HASH (BLOCK| | 8 | PX SELECTOR | | | | | | Q1,00 | SCWC | | |* 9 | INDEX RANGE SCAN | TAB311_PK | 3 | | 3 (0)| 00:00:01 | Q1,00 | SCWP | | | 10 | PX COORDINATOR | | | | | | | | | | 11 | PX SEND QC (RANDOM) | :TQ20001 | 1 | 269 | 5 (0)| 00:00:01 | Q2,01 | P->S | QC (RAND) | |* 12 | TABLE ACCESS BY INDEX ROWID BATCHED| TAB311 | 1 | 269 | 5 (0)| 00:00:01 | Q2,01 | PCWP | | | 13 | BUFFER SORT | | | | | | Q2,01 | PCWC | | | 14 | PX RECEIVE | | 2 | | 3 (0)| 00:00:01 | Q2,01 | PCWP | | | 15 | PX SEND HASH (BLOCK ADDRESS) | :TQ20000 | 2 | | 3 (0)| 00:00:01 | Q2,00 | S->P | HASH (BLOCK| | 16 | PX SELECTOR | | | | | | Q2,00 | SCWC | | |* 17 | INDEX RANGE SCAN | TAB311_IX_SUB_ITEM_CODE | 2 | | 3 (0)| 00:00:01 | Q2,00 | SCWP | | ----------------------------------------------------------------------------------------------------------------------------------------------- Predicate Information (identified by operation id): --------------------------------------------------- 9 - access("UNIQUE_ID"=1) 12 - filter(LNNVL("UNIQUE_ID"=1)) 17 - access("SUB_ITEM_CODE"='0001000000') Note ----- - dynamic statistics used: dynamic sampling (level=AUTO (SYSTEM)) - Degree of Parallelism is 4 because of hint

ということで、
前々回手動でunion all + フィルタ条件追加に書き換えたSQLを単純にパラレルクエリーにしてもイマイチだったので、OR_EXPANDのような実行計画にするために、インラインビューにしてみました！！！　どうでしょう？　OR_EXPANDの実行計画と同じようになりました。
ポイントは、前々回のOR_EXPANDの実行計画中に現れるインラインビュー　VW_ORE_5F0E22D2　です。内部的にインラインビューを追加してるんですよね！　OR_EXPANDのUNION ALL書き換え。
インラインビュー化したことで、Id=4にビューが登場しています。OR_EXPANDでは、VW_ORE_*　と名付けられるOR_EXPANDトランスフォームにより追加されるインラインビューと同じ役割を持っていますが、内部的に書き換えられて追加されるインラインビューとは異なり動的に名称が付加されません。

インラインビューが決めて！　というか、意外と忘れがちなので注意しないとね。

select /*+ parallel(4) */ * from ( select * from tab311 where unique_id = 1 union all select * from tab311 where sub_item_code = '0001000000' and LNNVL(unique_id=1) ); 経過: 00:00:00.03 実行計画 ---------------------------------------------------------- Plan hash value: 3706965944 ------------------------------------------------------------------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | TQ |IN-OUT| PQ Distrib | ------------------------------------------------------------------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 4 | 1160 | 9 (0)| 00:00:01 | | | | | 1 | PX COORDINATOR | | | | | | | | | | 2 | PX SEND QC (RANDOM) | :TQ10002 | 4 | 1160 | 9 (0)| 00:00:01 | Q1,02 | P->S | QC (RAND) | | 3 | BUFFER SORT | | 4 | 1160 | | | Q1,02 | PCWP | | | 4 | VIEW | | 4 | 1160 | 9 (0)| 00:00:01 | Q1,02 | PCWP | | | 5 | UNION-ALL | | | | | | Q1,02 | PCWP | | | 6 | TABLE ACCESS BY INDEX ROWID BATCHED| TAB311 | 3 | 807 | 4 (0)| 00:00:01 | Q1,02 | PCWP | | | 7 | BUFFER SORT | | | | | | Q1,02 | PCWC | | | 8 | PX RECEIVE | | 3 | | 3 (0)| 00:00:01 | Q1,02 | PCWP | | | 9 | PX SEND HASH (BLOCK ADDRESS) | :TQ10000 | 3 | | 3 (0)| 00:00:01 | Q1,00 | S->P | HASH (BLOCK| | 10 | PX SELECTOR | | | | | | Q1,00 | SCWC | | |* 11 | INDEX RANGE SCAN | TAB311_PK | 3 | | 3 (0)| 00:00:01 | Q1,00 | SCWP | | |* 12 | TABLE ACCESS BY INDEX ROWID BATCHED| TAB311 | 1 | 269 | 5 (0)| 00:00:01 | Q1,02 | PCWP | | | 13 | BUFFER SORT | | | | | | Q1,02 | PCWC | | | 14 | PX RECEIVE | | 2 | | 3 (0)| 00:00:01 | Q1,02 | PCWP | | | 15 | PX SEND HASH (BLOCK ADDRESS) | :TQ10001 | 2 | | 3 (0)| 00:00:01 | Q1,01 | S->P | HASH (BLOCK| | 16 | PX SELECTOR | | | | | | Q1,01 | SCWC | | |* 17 | INDEX RANGE SCAN | TAB311_IX_SUB_ITEM_CODE | 2 | | 3 (0)| 00:00:01 | Q1,01 | SCWP | | ------------------------------------------------------------------------------------------------------------------------------------------------- Predicate Information (identified by operation id): --------------------------------------------------- 11 - access("UNIQUE_ID"=1) 12 - filter(LNNVL("UNIQUE_ID"=1)) 17 - access("SUB_ITEM_CODE"='0001000000') Note ----- - dynamic statistics used: dynamic sampling (level=AUTO (SYSTEM)) - Degree of Parallelism is 4 because of hint

4月はじめだと言うのに、夏日とか、北の方面の友人からは31度だとか、最近の異常気象ほんとに農家泣かせな感じ。最近は天気予想が細かい範囲ででるので以前より対応しやすいのかもしれないけど。
こんな、陽気だとぶらりと湘南あたりからリモートワークしたいw

ではまた。

Related article on Mac De Oracle
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 1 / TABLE FULL SCAN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 2 / INDEX UNIQUE SCAN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 3 / INDEX RANGE SCAN, Index Only Scan
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 4 / INDEX RANGE SCAN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 5 / INDEX RANGE SCAN, INLIST ITERATOR
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 6 / INDEX FAST SCAN, Index Only Scan
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 7 / INDEX FULL SCAN,Index Only Scan
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 8 / INDEX SKIP SCAN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 9 / TABLE ACCESS INMEMORY FULL
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 10 / NESTED LOOP JOIN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 11 / MERGE JOIN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 12 / HASH JOIN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 13 / HASH JOIN OUTER
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 14 / HASH JOIN FULL OUTER
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 15 / PX, TABLE ACCESS FULL
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 16 / CONCATENATION
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 17 / SORT UNIQUE, UNION-ALL = UNION
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 18 / UNION-ALL
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 19 / INTERSECTION
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 20 / MINUS
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 21 / WINDOW NOSORT STOPKEY
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 22 / COUNT STOPKEY
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 23 / HASH JOIN - LEFT-DEEP JOIN vs RIGHT-DEEP JOIN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 24 / CONNECT BY NO FILTERING WITH START-WITH
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 25 / UNION ALL (RECURSIVE WITH) DEPTH FIRST, RECURSIVE WITH PUMP
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#1 / STAR TRANSFORM, VECTOR TRANSFORM (DWH向け)
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#2 / MERGE (UPSERT)
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#3 / RDFView
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#4 / INDEX FULL SCAN (MIN/MAX) - Index Only Scan
・実行計画は、SQL文のレントゲン写真だ！ No.30 - LOAD TABLE CONVENTIONAL vs. LOAD AS SELECT
・実行計画は、SQL文のレントゲン写真だ！ No.31 - TEMP TABLE TRANSFORMATION LOAD AS SELECT (CURSOR DURATION MEMORY)
・実行計画は、SQL文のレントゲン写真だ！ No.32 - EXTERNAL TABLE ACCESS FULL / INMEMORY FULL
・実行計画は、SQL文のレントゲン写真だ！ No.33 - BITMAP CONVERSION TO ROWIDS
・実行計画は、SQL文のレントゲン写真だ！ No.34 - 似て非なるもの　USE_CONCAT　と　OR_EXPAND ヒントと　手書きSQLのレントゲンの見分け方

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

2022年4月 9日 (土)

標準はあるにはあるが癖の多いSQL - #27 LNNVL is 何？と思った方向け

Previously on Mac De Oracle.
前回のエントリで使った関数覚えてますか？　LNNVL関数。　

Oracle純正の方言で、他のデータベースがネイティブでサポートしてるのって無さそうと思いつつ、気になったので軽くしらべてみた。

LNNVL
https://docs.oracle.com/en/database/oracle/oracle-database/21/sqlrf/LNNVL.html#GUID-FBCCE9B1-614E-45FA-8EE1-DFAA4F936867

基本的に移行対応や互換目的ぐらいですね。

Oracle Database の LNNVL を PostgreSQL で実現する
https://taityo-diary.hatenablog.jp/entry/2018/04/30/222335

PolarDB for Oracle にはある模様ですね。互換ということなので、だよね。というところですね。
https://www.alibabacloud.com/help/en/polardb-for-oracle/latest/lnnvl-function

折角なので、↑の例題の答えあわせしてみました。

SCOTT@orclpdb1> set null [null] SCOTT@orclpdb1> select * from account where lnnvl(year is not null); NAME YEAR ------------------------------------------------------------ ---------- peter2007 [null] SCOTT@orclpdb1> select * from account where lnnvl(year<2003); NAME YEAR ------------------------------------------------------------ ---------- peter2003 2003 peter2004 2004 peter2005 2005 peter2006 2006 peter2007 [null] SCOTT@orclpdb1> select * from account where lnnvl(year is null); NAME YEAR ------------------------------------------------------------ ---------- peter2001 2001 peter2002 2002 peter2003 2003 peter2004 2004 peter2005 2005 peter2006 2006 6行が選択されました。 SCOTT@orclpdb1> select * from account where lnnvl(year=2008); NAME YEAR ------------------------------------------------------------ ---------- peter2001 2001 peter2002 2002 peter2003 2003 peter2004 2004 peter2005 2005 peter2006 2006 peter2007 [null] 7行が選択されました。 SCOTT@orclpdb1> select * from account where lnnvl(year! =2008); NAME YEAR ------------------------------------------------------------ ---------- peter2007 [null]

合ってそう。

PostgreSQLのExtensionである、oraface　ではサポートしてますね。移行需要多いですからね。
https://github.com/orafce/orafce/search?q=LNNVL

たまたま見つけたのですが、Apache Spark。コメントのやりとりみて、まあ、そうですよねーーーというオチだったw
https://issues.apache.org/jira/browse/SPARK-21931

NVL2ほどは見当たらない、かなり強めの方言ですからね。　RedshiftやSnowflakeでもないね。これww　
では、また。

・標準はあるにはあるが癖の多いSQL 全部俺　#1 Pagination
・標準はあるにはあるが癖の多いSQL 全部俺　#2 関数名は同じでも引数が逆の罠！
・標準はあるにはあるが癖の多いSQL 全部俺　#3 データ型確認したい時あるんです
・標準はあるにはあるが癖の多いSQL 全部俺　#4 リテラル値での除算の内部精度も違うのよ!
・標準はあるにはあるが癖の多いSQL 全部俺　#5 和暦変換機能ある方が少数派
・標準はあるにはあるが癖の多いSQL 全部俺　#6 時間厳守！
・標準はあるにはあるが癖の多いSQL 全部俺　#7 期間リテラル！
・標準はあるにはあるが癖の多いSQL 全部俺　#8 翌月末日って何日？
・標準はあるにはあるが癖の多いSQL 全部俺　#9 部分文字列の扱いでも癖が出る＞＜
・標準はあるにはあるが癖の多いSQL 全部俺　#10 文字列連結の罠（有名なやつ）
・標準はあるにはあるが癖の多いSQL 全部俺　#11 デュエル、じゃなくて、デュアル
・標準はあるにはあるが癖の多いSQL 全部俺　#12 文字[列]探すにも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#13 あると便利ですが意外となかったり
・標準はあるにはあるが癖の多いSQL 全部俺　#14 連番の集合を返すにも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#15 SQL command line client
・標準はあるにはあるが癖の多いSQL 全部俺　#16 SQLのレントゲンを撮る方法
・標準はあるにはあるが癖の多いSQL 全部俺　#17 その空白は許されないのか？
・標準はあるにはあるが癖の多いSQL 全部俺　#18 (+)の外部結合は方言
・標準はあるにはあるが癖の多いSQL 全部俺　#19 帰ってきた、部分文字列の扱いでも癖w
・標準はあるにはあるが癖の多いSQL 全部俺　#20 結果セットを単一列に連結するにも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#21 演算結果にも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#22 集合演算にも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#23 複数行INSERTにも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#24 乱数作るにも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#25 SQL de Fractalsにも癖がある:)
・標準はあるにはあるが癖の多いSQL 全部俺　#26 おまけ SQL de 湯婆婆やるにも癖がでるw

投稿日時 2022年4月 9日 (土) 17時58分 Oracle, Oracle以外のデータベース, FAQ, SQL | 固定リンク | 0 | コメント (0)

実行計画は、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')

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

では、次回へつづく

Related article on Mac De Oracle
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 1 / TABLE FULL SCAN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 2 / INDEX UNIQUE SCAN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 3 / INDEX RANGE SCAN, Index Only Scan
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 4 / INDEX RANGE SCAN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 5 / INDEX RANGE SCAN, INLIST ITERATOR
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 6 / INDEX FAST SCAN, Index Only Scan
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 7 / INDEX FULL SCAN,Index Only Scan
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 8 / INDEX SKIP SCAN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 9 / TABLE ACCESS INMEMORY FULL
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 10 / NESTED LOOP JOIN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 11 / MERGE JOIN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 12 / HASH JOIN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 13 / HASH JOIN OUTER
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 14 / HASH JOIN FULL OUTER
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 15 / PX, TABLE ACCESS FULL
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 16 / CONCATENATION
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 17 / SORT UNIQUE, UNION-ALL = UNION
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 18 / UNION-ALL
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 19 / INTERSECTION
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 20 / MINUS
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 21 / WINDOW NOSORT STOPKEY
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 22 / COUNT STOPKEY
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 23 / HASH JOIN - LEFT-DEEP JOIN vs RIGHT-DEEP JOIN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 24 / CONNECT BY NO FILTERING WITH START-WITH
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 25 / UNION ALL (RECURSIVE WITH) DEPTH FIRST, RECURSIVE WITH PUMP
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#1 / STAR TRANSFORM, VECTOR TRANSFORM (DWH向け)
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#2 / MERGE (UPSERT)
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#3 / RDFView
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#4 / INDEX FULL SCAN (MIN/MAX) - Index Only Scan
・実行計画は、SQL文のレントゲン写真だ！ No.30 - LOAD TABLE CONVENTIONAL vs. LOAD AS SELECT
・実行計画は、SQL文のレントゲン写真だ！ No.31 - TEMP TABLE TRANSFORMATION LOAD AS SELECT (CURSOR DURATION MEMORY)
・実行計画は、SQL文のレントゲン写真だ！ No.32 - EXTERNAL TABLE ACCESS FULL / INMEMORY FULL
・実行計画は、SQL文のレントゲン写真だ！ No.33 - BITMAP CONVERSION TO ROWIDS

投稿日時 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

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

Related article on Mac De Oracle
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 1 / TABLE FULL SCAN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 2 / INDEX UNIQUE SCAN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 3 / INDEX RANGE SCAN, Index Only Scan
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 4 / INDEX RANGE SCAN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 5 / INDEX RANGE SCAN, INLIST ITERATOR
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 6 / INDEX FAST SCAN, Index Only Scan
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 7 / INDEX FULL SCAN,Index Only Scan
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 8 / INDEX SKIP SCAN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 9 / TABLE ACCESS INMEMORY FULL
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 10 / NESTED LOOP JOIN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 11 / MERGE JOIN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 12 / HASH JOIN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 13 / HASH JOIN OUTER
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 14 / HASH JOIN FULL OUTER
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 15 / PX, TABLE ACCESS FULL
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 16 / CONCATENATION
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 17 / SORT UNIQUE, UNION-ALL = UNION
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 18 / UNION-ALL
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 19 / INTERSECTION
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 20 / MINUS
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 21 / WINDOW NOSORT STOPKEY
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 22 / COUNT STOPKEY
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 23 / HASH JOIN - LEFT-DEEP JOIN vs RIGHT-DEEP JOIN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 24 / CONNECT BY NO FILTERING WITH START-WITH
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 25 / UNION ALL (RECURSIVE WITH) DEPTH FIRST, RECURSIVE WITH PUMP
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#1 / STAR TRANSFORM, VECTOR TRANSFORM (DWH向け)
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#2 / MERGE (UPSERT)
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#3 / RDFView
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#4 / INDEX FULL SCAN (MIN/MAX) - Index Only Scan
・実行計画は、SQL文のレントゲン写真だ！ No.30 - LOAD TABLE CONVENTIONAL vs. LOAD AS SELECT
・実行計画は、SQL文のレントゲン写真だ！ No.31 - TEMP TABLE TRANSFORMATION LOAD AS SELECT (CURSOR DURATION MEMORY)
・実行計画は、SQL文のレントゲン写真だ！ No.32 - EXTERNAL TABLE ACCESS FULL / INMEMORY FULL

投稿日時 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年4月 1日 (金)

実行計画は、SQL文のレントゲン写真だ！ No.32 - EXTERNAL TABLE ACCESS FULL / INMEMORY FULL

Previously on Mac De Oracle
前回は、ルーティーンとなったw、19cと20cのパラメータ差分チェックでした。

今日は、元の路線に戻り、「実行計画は、SQL文のレントゲン写真だ！」シリーズです :)

前回のパラメータ差分チェックで、外部表を利用していたので、18c以降で変更された In-Memory External Tables　とそれまでの　External Tableのレントゲンを見ておこうと思います。

利用するのはOaracle Database 21cですが、In-Memory External Tablesは、18c以降であれば使える機能なので使えるはず！

12cまでのnon In-Memory External Tablesなころのレントゲンからです。

外部表は　EXTERNAL TABLE ACCESS FULL　というオペレーションになっています。CSVファイルを全て読み込んでいることを表ています。ここ大切なので、覚えておきましょう。

Oracle Database 12c Enterprise Edition Release 12.1.0.1.0 - 64bit Production

---------------------------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time | ---------------------------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 8168 | 2727K| | 629 (1)| 00:00:01 | | 1 | SORT ORDER BY | | 8168 | 2727K| 2984K| 629 (1)| 00:00:01 | | 2 | VIEW | VW_FOJ_0 | 8168 | 2727K| | 30 (4)| 00:00:01 | |* 3 | HASH JOIN FULL OUTER | | 8168 | 2727K| | 30 (4)| 00:00:01 | | 4 | VIEW | | 838 | 139K| | 1 (100)| 00:00:01 | |* 5 | FIXED TABLE FULL | X$KSPPI | 838 | 58660 | | 1 (100)| 00:00:01 | | 6 | EXTERNAL TABLE ACCESS FULL| KSPPI_11_1_0_7_0 | 8168 | 1363K| | 29 (0)| 00:00:01 | ----------------------------------------------------------------------------------------------------------

外部表をフルスキャンしている。実際にはcsvファイルをまるっと読んで、ですよねーー。という感じ。外部表を利用されたことのある方であれば、ふむふむというところだと思います。

では21cの環境に切り替えて、前回Difference of Initialization Parameters between 19c (19.3.0.0.0) and 21c (21.3.0.0.0) - including hidden paramsを行った sysユーザーに接続して違いを見ていきましょう。

まずは、インメモリーを使わない状態で見てみます。（rpmでインストールしてconfigureしただけの21cデフォルトの状態。。のはずw。　こちらではカスタマイズしてないので）

ビルド表とプローブ表が12cR1の実行計画と逆になってますが、まあ気にしないw
外部表は、12cR1と同様に　EXTERNAL TABLE ACCESS FULL　ですね。

Oracle Database 21c Enterprise Edition Release 21.0.0.0.0　Version 21.3.0.0.0

---------------------------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time | ---------------------------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 5997 | 2002K| | 457 (1)| 00:00:01 | | 1 | SORT ORDER BY | | 5997 | 2002K| 2192K| 457 (1)| 00:00:01 | | 2 | VIEW | VW_FOJ_0 | 5997 | 2002K| | 15 (7)| 00:00:01 | |* 3 | HASH JOIN FULL OUTER | | 5997 | 1399K| | 15 (7)| 00:00:01 | | 4 | EXTERNAL TABLE ACCESS FULL| KSPPI_19_3_0_0_0 | 5412 | 359K| | 14 (0)| 00:00:01 | | 5 | VIEW | | 5997 | 1001K| | 1 (100)| 00:00:01 | |* 6 | FIXED TABLE FULL | X$KSPPI | 5997 | 415K| | 1 (100)| 00:00:01 | ----------------------------------------------------------------------------------------------------------

では、外部表をインメモリー対応に作り変えます。
INMEMORY句を追加してる箇所がポイントですね。

DROP TABLE ksppi_19_3_0_0_0; CREATE TABLE ksppi_19_3_0_0_0 ( ksppinm VARCHAR2(80) ,ksppdesc VARCHAR2(255) ) ORGANIZATION EXTERNAL ( TYPE ORACLE_LOADER DEFAULT DIRECTORY ext_tab ACCESS PARAMETERS ( RECORDS DELIMITED BY NEWLINE FIELDS TERMINATED BY '|' ( ksppinm ,ksppdesc ) ) LOCATION ( '19.3.0.0.0.ksppi.csv' ) ) INMEMORY MEMCOMPRESS FOR CAPACITY ;

おおお？？　ビルド表とプローブ表が入れ替わりましたが、外部表は、EXTERNAL TABLE ACCESS FULL　のままですね。
なにか設定し忘れているようです。

---------------------------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time | ---------------------------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 102K| 33M| | 7807 (1)| 00:00:01 | | 1 | SORT ORDER BY | | 102K| 33M| 36M| 7807 (1)| 00:00:01 | | 2 | VIEW | VW_FOJ_0 | 102K| 33M| | 341 (1)| 00:00:01 | |* 3 | HASH JOIN FULL OUTER | | 102K| 33M| | 341 (1)| 00:00:01 | | 4 | VIEW | | 5997 | 1001K| | 1 (100)| 00:00:01 | |* 5 | FIXED TABLE FULL | X$KSPPI | 5997 | 415K| | 1 (100)| 00:00:01 | | 6 | EXTERNAL TABLE ACCESS FULL| KSPPI_19_3_0_0_0 | 102K| 16M| | 341 (1)| 00:00:01 | ----------------------------------------------------------------------------------------------------------

ん、外部表自体のインメモリー定義は問題なさそうですね。

SYS@ORCLCDB> r 1 select table_name, inmemory, inmemory_compression 2* from user_tables where EXTERNAL = 'YES' TABLE_NAME INMEMORY INMEMORY_COMPRESSION ------------------------------ ------------------------ --------------------------------------------------- OPATCH_XML_INV DISABLED KSPPI_19_3_0_0_0 ENABLED FOR CAPACITY LOW

ポピュレーションされてないのか？

SYS@ORCLCDB> select SEGMENT_NAME,INMEMORY_SIZE,BYTES_NOT_POPULATED,POPULATE_STATUS,IS_EXTERNAL from v$im_segments; レコードが選択されませんでした。

あ”〜〜っ！　Oracle ACEのKPI入力期限まであと3ヶ月ある。あせるなwwww　大丈夫だw（謎

では、手動で。

SYS@ORCLCDB> exec dbms_inmemory.populate('SYS','KSPPI_19_3_0_0_0'); PL/SQLプロシージャが正常に完了しました。 SYS@ORCLCDB> select SEGMENT_NAME,INMEMORY_SIZE,BYTES_NOT_POPULATED,POPULATE_STATUS,IS_EXTERNAL from v$im_segments; レコードが選択されませんでした。

ん？　なんで？
あれか！

SYS@ORCLCDB> show parameter inmemory_size NAME TYPE VALUE ------------------------------------ --------------------------------- ------------------------------ inmemory_size big integer 0

やはり、だよね〜w デフォルトのままだもの。そりゃそうだ。

では、変更しましょう。inmemory_sizeは、最低 100MBは指定しないといけないので、今回は最低サイズ（十分だと思うので）に。

SYS@ORCLCDB> create pfile from spfile; ファイルが作成されました。 SYS@ORCLCDB> alter system set inmemory_size = 100m scope=spfile; システムが変更されました。 SYS@ORCLCDB> shutdown immediate データベースがクローズされました。データベースがディスマウントされました。 ORACLEインスタンスがシャットダウンされました。 SYS@ORCLCDB> startup ORACLEインスタンスが起動しました。 Total System Global Area 5586811432 bytes Fixed Size 9697832 bytes Variable Size 956301312 bytes Database Buffers 4496293888 bytes Redo Buffers 7077888 bytes In-Memory Area 117440512 bytes データベースがマウントされました。データベースがオープンされました。 SYS@ORCLCDB> show parameter inmemory_size NAME TYPE VALUE ------------------------------------ --------------------------------- ------------------------------ inmemory_size big integer 112M

よし！！　これで大丈夫なはず。

SYS@ORCLCDB> select SEGMENT_NAME,INMEMORY_SIZE,BYTES_NOT_POPULATED,POPULATE_STATUS,IS_EXTERNAL from v$im_segments; レコードが選択されませんでした。 SYS@ORCLCDB> exec dbms_inmemory.populate('SYS','KSPPI_19_3_0_0_0'); PL/SQLプロシージャが正常に完了しました。 SYS@ORCLCDB> select SEGMENT_NAME,INMEMORY_SIZE,BYTES_NOT_POPULATED,POPULATE_STATUS,IS_EXTERNAL from v$im_segments; SEGMENT_NAME INMEMORY_SIZE BYTES_NOT_POPULATED POPULATE_STATUS IS_EXTERNAL ------------------------------ ------------- ------------------- --------------------------------------- --------------- KSPPI_19_3_0_0_0 1179648 0 COMPLETED TRUE

では、こんどこそ！！

---------------------------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time | ---------------------------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 102K| 33M| | 7807 (1)| 00:00:01 | | 1 | SORT ORDER BY | | 102K| 33M| 36M| 7807 (1)| 00:00:01 | | 2 | VIEW | VW_FOJ_0 | 102K| 33M| | 341 (1)| 00:00:01 | |* 3 | HASH JOIN FULL OUTER | | 102K| 33M| | 341 (1)| 00:00:01 | | 4 | VIEW | | 5997 | 1001K| | 1 (100)| 00:00:01 | |* 5 | FIXED TABLE FULL | X$KSPPI | 5997 | 415K| | 1 (100)| 00:00:01 | | 6 | EXTERNAL TABLE ACCESS FULL| KSPPI_19_3_0_0_0 | 102K| 16M| | 341 (1)| 00:00:01 | ----------------------------------------------------------------------------------------------------------

あれ〜〜〜〜〜〜〜っ。　もう一つ忘れてた。query_rewrite_integrity.

Database Reference 2.294 QUERY_REWRITE_INTEGRITY
https://docs.oracle.com/en/database/oracle/oracle-database/21/refrn/QUERY_REWRITE_INTEGRITY.html

SYS@ORCLCDB> alter session set query_rewrite_integrity=stale_tolerated; セッションが変更されました。

外部表のオペレーションが　EXTERNAL TABLE ACCESS INMEMORY FULL　に変化しました。

------------------------------------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time | ------------------------------------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 102K| 33M| | 7807 (1)| 00:00:01 | | 1 | SORT ORDER BY | | 102K| 33M| 36M| 7807 (1)| 00:00:01 | | 2 | VIEW | VW_FOJ_0 | 102K| 33M| | 341 (1)| 00:00:01 | |* 3 | HASH JOIN FULL OUTER | | 102K| 33M| | 341 (1)| 00:00:01 | | 4 | VIEW | | 5997 | 1001K| | 1 (100)| 00:00:01 | |* 5 | FIXED TABLE FULL | X$KSPPI | 5997 | 415K| | 1 (100)| 00:00:01 | | 6 | EXTERNAL TABLE ACCESS INMEMORY FULL| KSPPI_19_3_0_0_0 | 102K| 16M| | 341 (1)| 00:00:01 | -------------------------------------------------------------------------------------------------------------------

まとめ

18cで登場した In-Memory External Tables のレントゲンは以下の通り。
EXTERNAL TABLE ACCESS INMEMORY FULL というオペレーションがポイントです。
また、INMEMORY_SIZEパラメータの設定や、QUERY_REWRITE_INTEGRITYパラメータをstale_toleratedにする必要あります。忘れがち？！

21cでの non in-memory external tables と in-memory external tables のレントゲンをSQL MONITORの実行計画を。

non in-memory external tables : EXTERNAL TABLE ACCESS FULL

Global Stats ===================================================================================================== | Elapsed | Cpu | IO | PL/SQL | Other | Fetch | Buffer | Read | Read | Write | Write | | Time(s) | Time(s) | Waits(s) | Time(s) | Waits(s) | Calls | Gets | Reqs | Bytes | Reqs | Bytes | ===================================================================================================== | 0.06 | 0.05 | 0.00 | 0.00 | 0.00 | 406 | 121 | 1 | 512KB | 16 | 683 | ===================================================================================================== SQL Plan Monitoring Details (Plan Hash Value=1973289935) ======================================================================================================================================================================================== | Id | Operation | Name | Rows | Cost | Time | Start | Execs | Rows | Read | Read | Write | Write | Mem | Activity | Activity Detail | | | | | (Estim) | | Active(s) | Active | | (Actual) | Reqs | Bytes | Reqs | Bytes | (Max) | (%) | (# samples) | ======================================================================================================================================================================================== | 0 | SELECT STATEMENT | | | | 1 | +1 | 1 | 6066 | | | | | . | | | | 1 | SORT ORDER BY | | 102K | 7807 | 1 | +1 | 1 | 6066 | | | | | 676KB | | | | 2 | VIEW | VW_FOJ_0 | 102K | 341 | 1 | +1 | 1 | 6066 | | | | | . | | | | 3 | HASH JOIN FULL OUTER | | 102K | 341 | 1 | +1 | 1 | 6066 | | | | | 2MB | | | | 4 | VIEW | | 5997 | 1 | 1 | +1 | 1 | 5997 | | | | | . | | | | 5 | FIXED TABLE FULL | X$KSPPI | 5997 | 1 | 1 | +1 | 1 | 5997 | | | | | . | | | | 6 | EXTERNAL TABLE ACCESS FULL | KSPPI_19_3_0_0_0 | 102K | 341 | 1 | +1 | 1 | 5412 | 1 | 512KB | 16 | | . | | | ========================================================================================================================================================================================

in-memory external tables : EXTERNAL TABLE ACCESS INMEMORY FULL

Global Stats ====================================================================================== | Elapsed | Cpu | IO | PL/SQL | Other | Fetch | Buffer | Write | Write | | Time(s) | Time(s) | Waits(s) | Time(s) | Waits(s) | Calls | Gets | Reqs | Bytes | ====================================================================================== | 0.04 | 0.04 | 0.00 | 0.00 | 0.00 | 406 | 48 | 16 | 683 | ====================================================================================== SQL Plan Monitoring Details (Plan Hash Value=1973289935) ================================================================================================================================================================================== | Id | Operation | Name | Rows | Cost | Time | Start | Execs | Rows | Write | Write | Mem | Activity | Activity Detail | | | | | (Estim) | | Active(s) | Active | | (Actual) | Reqs | Bytes | (Max) | (%) | (# samples) | ================================================================================================================================================================================== | 0 | SELECT STATEMENT | | | | 2 | +0 | 1 | 6066 | | | . | | | | 1 | SORT ORDER BY | | 102K | 7807 | 2 | +0 | 1 | 6066 | | | 676KB | | | | 2 | VIEW | VW_FOJ_0 | 102K | 341 | 1 | +0 | 1 | 6066 | | | . | | | | 3 | HASH JOIN FULL OUTER | | 102K | 341 | 1 | +0 | 1 | 6066 | | | 3MB | | | | 4 | VIEW | | 5997 | 1 | 1 | +0 | 1 | 5997 | | | . | | | | 5 | FIXED TABLE FULL | X$KSPPI | 5997 | 1 | 1 | +0 | 1 | 5997 | | | . | | | | 6 | EXTERNAL TABLE ACCESS INMEMORY FULL | KSPPI_19_3_0_0_0 | 102K | 341 | 2 | +0 | 1 | 5412 | 16 | | . | | | ==================================================================================================================================================================================

レントゲンは大切 !!!! :)

東京は一気に葉桜になりつつある。。。ではまた。

Related article on Mac De Oracle
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 1 / TABLE FULL SCAN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 2 / INDEX UNIQUE SCAN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 3 / INDEX RANGE SCAN, Index Only Scan
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 4 / INDEX RANGE SCAN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 5 / INDEX RANGE SCAN, INLIST ITERATOR
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 6 / INDEX FAST SCAN, Index Only Scan
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 7 / INDEX FULL SCAN,Index Only Scan
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 8 / INDEX SKIP SCAN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 9 / TABLE ACCESS INMEMORY FULL
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 10 / NESTED LOOP JOIN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 11 / MERGE JOIN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 12 / HASH JOIN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 13 / HASH JOIN OUTER
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 14 / HASH JOIN FULL OUTER
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 15 / PX, TABLE ACCESS FULL
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 16 / CONCATENATION
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 17 / SORT UNIQUE, UNION-ALL = UNION
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 18 / UNION-ALL
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 19 / INTERSECTION
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 20 / MINUS
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 21 / WINDOW NOSORT STOPKEY
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 22 / COUNT STOPKEY
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 23 / HASH JOIN - LEFT-DEEP JOIN vs RIGHT-DEEP JOIN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 24 / CONNECT BY NO FILTERING WITH START-WITH
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 25 / UNION ALL (RECURSIVE WITH) DEPTH FIRST, RECURSIVE WITH PUMP
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#1 / STAR TRANSFORM, VECTOR TRANSFORM (DWH向け)
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#2 / MERGE (UPSERT)
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#3 / RDFView
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#4 / INDEX FULL SCAN (MIN/MAX) - Index Only Scan
実行計画は、SQL文のレントゲン写真だ！ No.30 - LOAD TABLE CONVENTIONAL vs. LOAD AS SELECT
実行計画は、SQL文のレントゲン写真だ！ No.31 - TEMP TABLE TRANSFORMATION LOAD AS SELECT (CURSOR DURATION MEMORY)

投稿日時 2022年4月 1日 (金) 21時13分 Oracle, チューニング, FAQ, SQL, Oracle Database 12c release 1, パフォーマンス, 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を参照ください。

では、また。

Related article on Mac De Oracle
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 1 / TABLE FULL SCAN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 2 / INDEX UNIQUE SCAN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 3 / INDEX RANGE SCAN, Index Only Scan
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 4 / INDEX RANGE SCAN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 5 / INDEX RANGE SCAN, INLIST ITERATOR
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 6 / INDEX FAST SCAN, Index Only Scan
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 7 / INDEX FULL SCAN,Index Only Scan
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 8 / INDEX SKIP SCAN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 9 / TABLE ACCESS INMEMORY FULL
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 10 / NESTED LOOP JOIN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 11 / MERGE JOIN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 12 / HASH JOIN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 13 / HASH JOIN OUTER
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 14 / HASH JOIN FULL OUTER
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 15 / PX, TABLE ACCESS FULL
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 16 / CONCATENATION
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 17 / SORT UNIQUE, UNION-ALL = UNION
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 18 / UNION-ALL
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 19 / INTERSECTION
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 20 / MINUS
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 21 / WINDOW NOSORT STOPKEY
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 22 / COUNT STOPKEY
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 23 / HASH JOIN - LEFT-DEEP JOIN vs RIGHT-DEEP JOIN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 24 / CONNECT BY NO FILTERING WITH START-WITH
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 25 / UNION ALL (RECURSIVE WITH) DEPTH FIRST, RECURSIVE WITH PUMP
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#1 / STAR TRANSFORM, VECTOR TRANSFORM (DWH向け)
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#2 / MERGE (UPSERT)
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#3 / RDFView
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#4 / INDEX FULL SCAN (MIN/MAX) - Index Only Scan
・実行計画は、SQL文のレントゲン写真だ！ No.30 - LOAD TABLE CONVENTIONAL vs. LOAD AS SELECT

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

2022年3月21日 (月)

古くて新しい？遅延ブロッククリーンアウト (deferred block cleanout) #13

随分間が空いてしまったのです、覚えてますかねw　前回のネタ。私もほぼ忘れてました　orz. w

思い出しながら進めましょう:)

Previously on Mac De Oracle
前回は、CTASだと、内部的にdirect path writeされてしまうのでクリーンアウトが必要な状況にはならないという動きを確認しました。

scattered read同様に、sequential readだとどうなの？（という遠くから声が聞こえたきがしたのでw）

とはいえ、遅延ブロッククリーンアウトって、自分の理解だと、全表走査時の動きだと思っているので、多分、起きないよなーと。頭の上に雲型の吹き出した出た状態でイメージしているところ。

では、試してみましょう。

これまでと異なる箇所は、sequential read　でぐるぐるループさせたいので、該当表に主キー索引を作成します。また、table full scanではなく、index unique scan で全行アクセスさせてみます。（この動きが大きく異なる部分です）

strong>0) 対象表のdrop/create と主キー作成
対象表のHOGE2は削除して作り直し。このテストケースでは主キーアクセスさせるため、合わせて主キーも作成しておきます。

SCOTT@orcl> @droppurge_create_hoge2_with_pk.sql 1* drop table hoge2 purge Table dropped. Elapsed: 00:00:00.51 1* create table hoge2 (id number, data varchar2(2000), constraint pk_hoge2 primary key (id) using index) Table created. Elapsed: 00:00:00.07 1* select segment_name,blocks from user_segments where segment_name like '%HOGE2%' no rows selected Elapsed: 00:00:00.13

1) 統計をクリアするためOracle再起動

$ sudo service oracle restart [sudo] password for oracle: Restarting oracle (via systemctl): [ OK ]

2) PDBのscottでログインしてclient_infoをセット
v$sessionのclient_info列の'TargetSession'文字列で他のSCOTTユーザーのセッションを特定するため。

SCOTT@orcl> @set_client_info 1 begin 2 DBMS_APPLICATION_INFO.SET_CLIENT_INFO('Target Session'); 3* end; PL/SQL procedure successfully completed. Elapsed: 00:00:00.00 SCOTT@orcl>

3) CDBのSYSで統計取得（初回）
内容は省略！（思い出したいかたはこの辺りを参照ください。。

4) PDBのSCOTTユーザーでNOAPPENDヒント付きIASを実行（データサイズは、コミットクリーンアウトではクリーンアウト仕切れないサイズ）／　未コミット

NOAPPENDヒントを利用している理由は前回までの内容を見ていただければわかりますが、direct path writeさせたないためです。これによりコミットクリーンアウトではクリーンアウトできない状況、つまり、遅延ブロッククリーンアウトが必要となる状態を作っています。

SCOTT@orcl> @ias_noappend_from_hoge.sql 1* insert /*+ noappend */ into hoge2 select * from hoge 200000 rows created. Elapsed: 00:00:19.63 14:32:40 SCOTT@orcl>

5) CDBのSYSで統計取得（未コミット）

検証中に統計値が変動したもののみ記載

狙い通りdirect path writeは抑止できていることは確認できます。
(CDB）システム統計

SOURCE NAME VALUE ------- ---------------------------------------------------- --------------- sysstat DBWR checkpoint buffers written 22,918 sysstat DBWR checkpoints 72 sysstat DBWR thread checkpoint buffers written 22,918 sysstat DBWR transaction table writes 22 sysstat DBWR undo block writes 983 sysstat cleanouts only - consistent read gets 0 sysstat commit cleanout failures: block lost 0 sysstat commit cleanout failures: callback failure 0 sysstat commit cleanouts 1,601 sysstat commit cleanouts successfully completed 1,601 sysstat consistent gets 122,604 sysstat db block changes 564,554 sysstat deferred (CURRENT) block cleanout applications 12 sysstat free buffer requested 70,607 sysstat immediate (CR) block cleanout applications 0 sysstat immediate (CURRENT) block cleanout applications 1,752 sysstat no work - consistent read gets 67,108 sysstat physical reads 66,750 sysstat physical reads direct 66,709 sysstat physical writes 22,918 sysstat physical writes from cache 22,918 sysstat physical writes non checkpoint 22,918 sysstat redo blocks written 967,108 sysstat redo size 479,412,088 sysstat redo writes 378

(PDB)　SCOTTのセッション統計
こちらから見てもdirect path writeは発生していません

SOURCE NAME VALUE ------- ---------------------------------------------------- --------------- sesstat cleanouts only - consistent read gets 0 sesstat commit cleanout failures: block lost 0 sesstat commit cleanouts 1,589 sesstat commit cleanouts successfully completed 1,589 sesstat consistent gets 122,204 sesstat db block changes 564,506 sesstat deferred (CURRENT) block cleanout applications 7 sesstat free buffer requested 70,595 sesstat immediate (CR) block cleanout applications 0 sesstat immediate (CURRENT) block cleanout applications 1,748 sesstat no work - consistent read gets 66,884 sesstat physical reads 66,740 sesstat physical reads direct 66,709 sesstat redo size 478,945,336

該当期間の待機イベント記録されていないですよね。狙い通りなので準備としては問題なしです。

EVENT WAIT_CLASS ---------------------------------------------------------------- ----------------- SQL*Net message from client Idle log buffer space Configuration events in waitclass Other Other direct path read User I/O log file switch (private strand flush incomplete) Configuration log file switch completion Configuration log file sync Commit db file sequential read User I/O SQL*Net message to client Network Disk file operations I/O User I/O db file scattered read User I/O

6) CDB or PDBのSYSユーザで接続し、buffer cacheをflushする

SYS@orclcdb> @flush_buffercache.sql 1* alter system flush buffer_cache System altered. Elapsed: 00:00:09.04 14:36:26 SYS@orclcdb>

7) CDBのSYSで統計取得（buffer cacheをflush後）
strong>(CDB）システム統計
検証中に統計値が変動したもののみ記載

バッファキャッシュをフラッシュしたのでキャッシュから書き出されたことを示す　physical writes from cache　および関連する統計値が上昇しています。これも想定通りの挙動ですね。

SOURCE NAME VALUE ------- ---------------------------------------------------- --------------- sysstat DBWR checkpoint buffers written 0 sysstat DBWR checkpoints 0 sysstat DBWR thread checkpoint buffers written 0 sysstat DBWR transaction table writes 8 sysstat DBWR undo block writes 1912 sysstat cleanouts only - consistent read gets 0 sysstat commit cleanout failures: block lost 0 sysstat commit cleanout failures: callback failure 0 sysstat commit cleanouts 43 sysstat commit cleanouts successfully completed 43 sysstat consistent gets 20793 sysstat db block changes 429 sysstat deferred (CURRENT) block cleanout applications 21 sysstat free buffer requested 1013 sysstat immediate (CR) block cleanout applications 0 sysstat immediate (CURRENT) block cleanout applications 9 sysstat no work - consistent read gets 12321 sysstat physical reads 977 sysstat physical reads direct 0 sysstat physical writes 47900 sysstat physical writes from cache 47900 sysstat physical writes non checkpoint 47900 sysstat redo blocks written 2017 sysstat redo size 994652 sysstat redo writes 23

(PDB)　SCOTTのセッション統計

キャッシュをフラッシュしただけなので、該当セッションの統計には変化がありません。（まあ、そうですよねw）

SOURCE NAME VALUE ------- ---------------------------------------------------- --------------- sesstat cleanouts only - consistentread gets 0 sesstat commit cleanout failures: block lost 0 sesstat commit cleanouts 0 sesstat commit cleanouts successfully completed 0 sesstat consistent gets 0 sesstat db block changes 0 sesstat deferred (CURRENT) block cleanout applications 0 sesstat free buffer requested 0 sesstat immediate (CR) block cleanout applications 0 sesstat immediate (CURRENT) block cleanout applications 0 sesstat no work - consistent read gets 0 sesstat physical reads 0 sesstat physical reads direct 0 sesstat physical writes 0 sesstat physical writes direct 0 sesstat physical writes from cache 0 sesstat physical writes non checkpoint 0 sesstat redo blocks written 0 sesstat redo size 0

8) PDBのSCOTTユーザーでコミットの実行

SCOTT@orcl> commit; Commit complete. Elapsed: 00:00:00.01

9) CDBのSYSで統計取得（コミット後）
strong>(CDB）システム統計
コミット時点ではクリーンアウト仕切れないほどの更新ブロック数かつ、コミット前にバッファキャッシュをフラッシュしているので、コミット時のクリーンアウトもできない状態なっています（これも事前の準備の通りの結果。なので問題なし）
commit cleanouts　と　commit cleanout failures: block lost　がポイントです。コミット時にクリーンアウトできる量（過去の記事を参照のこと）の閾値以下の量ですら、事前にキャッシュからフラッシュしまっているので、クリーンアウトに失敗（できないようにしたので当然ですが）しています。両方の統計値が同一であるとくことは、コミットクリーンアウトしようとした全てでくりアウトできなかった。理由はキャッシュに該当ブロックがキャッシュから落ちていたから（意図的に落としたわけですが）ということを意味します。予定通りですね。

コミットの時点で最低現おこなうクリーンアウトもさせていないですが、このケースでは　11140　ブロックをコミット時にクリーンアウトしようとしているので、コミット時のクリーンアウトが行われていたとしても　50,000 ブロック以上は遅延されていたことになりますね。今回は、　66,667　ブロックがク後続のSQLで参照されるついでにクリーンアウトされることになります。

検証中に統計値が変動したもののみ記載

SOURCE NAME VALUE ------- ---------------------------------------------------- --------------- sysstat DBWR checkpoint buffers written 0 sysstat DBWR checkpoints 0 sysstat DBWR thread checkpoint buffers written 0 sysstat DBWR transaction table writes 0 sysstat DBWR undo block writes 0 sysstat cleanouts only - consistent read gets 0 sysstat commit cleanout failures: block lost 11140 sysstat commit cleanout failures: callback failure 0 sysstat commit cleanouts 11140 sysstat commit cleanouts successfully completed 0 sysstat consistent gets 34 sysstat db block changes 1 sysstat deferred (CURRENT) block cleanout applications 0 sysstat free buffer requested 8 sysstat immediate (CR) block cleanout applications 0 sysstat immediate (CURRENT) block cleanout applications 0 sysstat no work - consistent read gets 5 sysstat physical reads 8 sysstat physical reads direct 0 sysstat physical writes 0 sysstat physical writes from cache 0 sysstat physical writes non checkpoint 0 sysstat redo blocks written 3 sysstat redo size 456 sysstat redo writes 3

(PDB)　SCOTTのセッション統計
セッションレベルでみるよりはっきり見るとことができます。

SOURCE NAME VALUE ------- ---------------------------------------------------- --------------- sesstat cleanouts only - consistent read gets 0 sesstat commit cleanout failures: block lost 11140 sesstat commit cleanouts 11140 sesstat commit cleanouts successfully completed 0 sesstat consistent gets 0 sesstat db block changes 1 sesstat deferred (CURRENT) block cleanout applications 0 sesstat free buffer requested 1 sesstat immediate (CR) block cleanout applications 0 sesstat immediate (CURRENT) block cleanout applications 0 sesstat no work - consistent read gets 0 sesstat physical reads 1 sesstat physical reads direct 0 sesstat physical writes 0 sesstat physical writes direct 0 sesstat physical writes from cache 0 sesstat physical writes non checkpoint 0 sesstat redo blocks written 0 sesstat redo size 176

10) PDBのSCOTTユーザーで遅延ブロッククリーンアウト有無確認（対象表を主キーによる一意検索で全行アクセス）

さて、事前に想定している実行計画になっているかプランだけ確認しておきましょう。主キーによる索引ユニークスキャンであることが確認できます。想定通りです。この実行計画で、200,000 行をグルグル参照した場合、遅延されたブロッククリーンアウトが行われるでしょうか。。。。（してくれないと思いますが。。。試してみましょう）

SCOTT@orcl> set autot trace exp 14:41:47 SCOTT@orcl> select * from hoge2 where id = 1; Elapsed: 00:00:00.00 Execution Plan ---------------------------------------------------------- Plan hash value: 3319133482 ---------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ---------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 1 | 1015 | 1 (0)| 00:00:01 | | 1 | TABLE ACCESS BY INDEX ROWID| HOGE2 | 1 | 1015 | 1 (0)| 00:00:01 | |* 2 | INDEX UNIQUE SCAN | PK_HOGE2 | 1 | | 1 (0)| 00:00:01 | ---------------------------------------------------------------------------------------- Predicate Information (identified by operation id): --------------------------------------------------- 2 - access("ID"=1) SCOTT@orcl> set autot off SCOTT@orcl> SCOTT@orcl> @table_unique_scan_hoge2.sql 1 begin 2 for i in 1..&1 loop 3 for hoge2_rec in (select * from hoge2 where id = i) loop 4 null; 5 end loop; 6 end loop; 7* end; Enter value for 1: 200000 old 2: for i in 1..&1 loop new 2: for i in 1..200000 loop PL/SQL procedure successfully completed. Elapsed: 00:00:14.94 14:39:36 SCOTT@orcl>

11) CDBのSYSで統計取得（遅延ブロッククリーンアウト有無確認。対象表を主キーによる一意検索で全行アクセス）
strong>(CDB）システム統計

クリーンアウトが行われていれば、データブロックの総数　66,667　ブロックは少なくともクリーンアップの対象になっているはずですが。。。。。
cleanout系の統計値に動きはありませんよね。

SOURCE NAME VALUE ------- ---------------------------------------------------- --------------- sysstat DBWR checkpoint buffers written 21 sysstat DBWR checkpoints 0 sysstat DBWR thread checkpoint buffers written 0 sysstat DBWR transaction table writes 5 sysstat DBWR undo block writes 5 sysstat cleanouts only - consistent read gets 0 sysstat commit cleanout failures: block lost 0 sysstat commit cleanout failures: callback failure 15 sysstat commit cleanouts 366 sysstat commit cleanouts successfully completed 351 sysstat consistent gets 632775 sysstat db block changes 7848 sysstat deferred (CURRENT) block cleanout applications 169 sysstat free buffer requested 76662 sysstat immediate (CR) block cleanout applications 0 sysstat immediate (CURRENT) block cleanout applications 169 sysstat no work - consistent read gets 21822 sysstat physical reads 69501 sysstat physical reads direct 0 sysstat physical writes 21 sysstat physical writes from cache 21 sysstat physical writes non checkpoint 10 sysstat redo blocks written 5132 sysstat redo size 2536084 sysstat redo writes 28

(PDB)　SCOTTのセッション統計

physical reads は、67706 ブロックなのでほ、HOGE2表の索引と表のセグメントサイズほどは物理読み込みされたということになります。ただ、cleanouts only - consistent read gets　などのクリーンアウトを示す統計値はほぼ動いていません。ようするに、db file sequential readとなる index unique scan　ではブロッククリーンアウトは発生しないということを意味しています。

おおおーーー。だったら、グルグル系の処理で一行ごとに処理するのが最高じゃん！　という単純な話ではないので要注意ですからねw

SOURCE NAME VALUE ------- ---------------------------------------------------- --------------- sesstat cleanouts only - consistent read gets 0 sesstat commit cleanout failures: block lost 0 sesstat commit cleanouts 4 sesstat commit cleanouts successfully completed 4 sesstat consistent gets 600005 sesstat db block changes 14 sesstat deferred (CURRENT) block cleanout applications 2 sesstat free buffer requested 74540 sesstat immediate (CR) block cleanout applications 0 sesstat immediate (CURRENT) block cleanout applications 2 sesstat no work - consistent read gets 0 sesstat physical reads 67706 sesstat physical reads direct 0 sesstat physical writes 0 sesstat physical writes direct 0 sesstat physical writes from cache 0 sesstat physical writes non checkpoint 0 sesstat redo blocks written 0 sesstat redo size 2152

10) PDBのSCOTTユーザーで遅延ブロッククリーンアウト有無確認（sacattered read）

single block readを行うindex unique scanではクリーンアウトが発生しなかったということは、全表走査させる table full scan かつ scattered readさせれば発生するのではないでしょうか？　という確認です。
auto traceで統計情報をみると、なにやら、REDOログが大量に生成されてますよね。。。これは！！！

SCOTT@orcl> @table_full_scan_hoge2.sql 1* alter session set "_serial_direct_read" = never Session altered. Elapsed: 00:00:00.01 1* alter session set "_very_large_object_threshold" = 20400 Session altered. Elapsed: 00:00:00.00 set autot trace exp stat 1* select * from hoge2 200000 rows selected. Elapsed: 00:00:06.55 Execution Plan ---------------------------------------------------------- Plan hash value: 1530105727 --------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | --------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 172K| 167M| 18223 (1)| 00:00:01 | | 1 | TABLE ACCESS FULL| HOGE2 | 172K| 167M| 18223 (1)| 00:00:01 | --------------------------------------------------------------------------- Note ----- - dynamic statistics used: dynamic sampling (level=2) Statistics ---------------------------------------------------------- 10 recursive calls 1 db block gets 147157 consistent gets 377 physical reads 5866968 redo size 406775148 bytes sent via SQL*Net to client 147265 bytes received via SQL*Net from client 13335 SQL*Net roundtrips to/from client 0 sorts (memory) 0 sorts (disk) 200000 rows processed set autot off 14:56:56 SCOTT@orcl>

11) CDBのSYSで統計取得（遅延ブロッククリーンアウト有無確認。対象表を主キーによる一意検索で全行アクセス）
strong>(CDB）システム統計

SOURCE NAME VALUE ------- ---------------------------------------------------- --------------- sysstat DBWR checkpoint buffers written 1121 sysstat DBWR checkpoints 0 sysstat DBWR thread checkpoint buffers written 0 sysstat DBWR transaction table writes 36 sysstat DBWR undo block writes 347 sysstat cleanouts only - consistent read gets 66676 sysstat commit cleanout failures: block lost 0 sysstat commit cleanout failures: callback failure 0 sysstat commit cleanouts 806 sysstat commit cleanouts successfully completed 806 sysstat consistent gets 174296 sysstat db block changes 80773 sysstat deferred (CURRENT) block cleanout applications 383 sysstat free buffer requested 2095 sysstat immediate (CR) block cleanout applications 66676 sysstat immediate (CURRENT) block cleanout applications 75 sysstat no work - consistent read gets 27953 sysstat physical reads 1842 sysstat physical reads direct 0 sysstat physical writes 1121 sysstat physical writes from cache 1121 sysstat physical writes non checkpoint 981 sysstat redo blocks written 16550 sysstat redo size 8074260 sysstat redo writes 351

(PDB)　SCOTTのセッション統計
HOGE2の表のクリーンアウト対象ブロック数、66,667　きっちり同じ数字が現れました。しかも cleanoutに関わる統計でかつ、大量のREDOログも生成されています。でました〜〜〜w　クリーンアウト。全表走査かつ、scattered readで。

SOURCE NAME VALUE ------- ---------------------------------------------------- --------------- sesstat cleanouts only - consistent read gets 66667 sesstat commit cleanout failures: block lost 0 sesstat commit cleanouts 1 sesstat commit cleanouts successfully completed 1 sesstat consistent gets 153731 sesstat db block changes 66718 sesstat deferred (CURRENT) block cleanout applications 0 sesstat free buffer requested 690 sesstat immediate (CR) block cleanout applications 66667 sesstat immediate (CURRENT) block cleanout applications 0 sesstat no work - consistent read gets 16317 sesstat physical reads 680 sesstat physical reads direct 0 sesstat redo size 5877252

まとめ

index unique scanでグルグルさせつつ、全行アクセスしても発生しないですよね！
single block readになるunique index scanでは、遅延ブロッククリーンアウトは発生しない。（想像通りでよかったw）
で、そのあとで全表走査（scattered read)させてみると、やはり、遅延ブロッククリーンアウトは発生するわけですよ。面白いです。ほんと。

さあ、5月末まで追い込みだw　ブログ書かないとw　（頑張って、アドベントカレンダー全部俺やっとくほうが実は楽なのかもしれないw）

では、また。

・古くて新しい？遅延ブロッククリーンアウト (deferred block cleanout) #1
・古くて新しい？遅延ブロッククリーンアウト (deferred block cleanout) #2
・古くて新しい？遅延ブロッククリーンアウト (deferred block cleanout) #3
・古くて新しい？遅延ブロッククリーンアウト (deferred block cleanout) #4
・古くて新しい？遅延ブロッククリーンアウト (deferred block cleanout) #5
・古くて新しい？遅延ブロッククリーンアウト (deferred block cleanout) #6
・古くて新しい？遅延ブロッククリーンアウト (deferred block cleanout) #7
・古くて新しい？遅延ブロッククリーンアウト (deferred block cleanout) #8
・古くて新しい？遅延ブロッククリーンアウト (deferred block cleanout) #9
・古くて新しい？遅延ブロッククリーンアウト (deferred block cleanout) #10
・古くて新しい？遅延ブロッククリーンアウト (deferred block cleanout) #11
・古くて新しい？遅延ブロッククリーンアウト (deferred block cleanout) #12

投稿日時 2022年3月21日 (月) 15時46分 Oracle, PL/SQL, チューニング, FAQ, SQL, パフォーマンス, Oracle Database 19c | 固定リンク | 0 | コメント (0)

2021年12月23日 (木)

誰がどんな名前のペットを飼っているのかな？解答編 / JPOUG Advent Calendar Day 23

さーて、いよいよ残りの窓も残りわずか、JPOUGアドベントカレンダー、22番目の窓は、Kazuhiro TakahashiさんのDBLINKを使ったときのLOBの制約について　[SQL・DDL]でした。

23番目の窓は、1番目の窓でネタ振りしたエントリーの解答編です。みなさんには簡単過ぎますよねw　どのような方法で解いたのでしょう:) 気になる!

私は、愚直な方法にしてみました。（予告通りw

まず、前回提示したDDLで元となる3表とデータを準備

ペットのオーナー = owners

ペットの名前 = pets

動物の種類 = animals

create table owners (name varchar2(30) not null unique); create table pets (name varchar2(30) not null unique); create table animals (kind varchar2(30) not null unique); -- owners insert into owners(name) values('Hiro'); insert into owners(name) values('Larry'); insert into owners(name) values('Scott'); insert into owners(name) values('Steve'); -- pets insert into pets(name) values('Lisa'); insert into pets(name) values('Taro'); insert into pets(name) values('Tiger'); insert into pets(name) values('Wendy'); -- animals insert into animals(kind) values('Cat'); insert into animals(kind) values('Dog'); insert into animals(kind) values('Snake'); insert into animals(kind) values('Turtle'); commit;

SCOTT@ORCL> select name from owners; NAME ------------------------------- Hiro Larry Scott Steve Elapsed: 00:00:00.01 SCOTT@ORCL> select name from pets; NAME ------------------------------ Lisa Taro Tiger Wendy Elapsed: 00:00:00.01 SCOTT@ORCL> select kind from animals; KIND ------------------------------ Cat Dog Snake Turtle Elapsed: 00:00:00.01

前回、簡単に脳内イメージをダンプしておきましたが、それらを元に関連エンティティの代用で3つのビューを作成することにしました。

見ていきましょう。

「ペットのオーナー」と「ペットの名前」を関連づけるビュー = owners_pets

ペットのオーナーとペットの名前の関係として、

Hiro　:　「僕が飼っているのは、Tiger だよ。 Turtle じゃないよ」

だけがあるので、

Hiro は Tiger　という名のペットを飼っている。

Hiro 以外は、Tiger　という名のペット以外のいずれかを飼っている

という関連を以下のビューで定義

create view owners_pets as select owners.name as owner_name , pets.name as pet_name from owners cross join pets where ( owners.name = 'Hiro' and pets.name = 'Tiger' ) or ( owners.name != 'Hiro' and pets.name != 'Tiger' ) /

問い合わせると以下のようになります（OWNER_NAME,PET_NAME列で昇順にソートしています）

OWNER_NAME PET_NAME ------------------------------------------------------------ ------------------------------ Hiro Tiger Larry Lisa Larry Taro Larry Wendy Scott Lisa Scott Taro Scott Wendy Steve Lisa Steve Taro Steve Wendy 10 rows selected.

２つめのビューは、
「ペットの名前」と「動物の種類」を関連づけるビュー = pets_animals

Hiro　:「僕が飼っているのは、Tiger だよ。 Turtle じゃないよ」

Larry :「Snake の名前は、Lisa じゃないよ」

Steve :「Dog の名前は Wendy だよ。僕は Dog はかってないけど」

問題からペットの名前と動物の種類の関係として、以下が読み取れます。

Wendyは、Dogだ。

Tigerは、Turtleではない。また、Dogでもない。（同種のペットは複数いない。Wendy=Dogなので）

Lisaは、Snakeではない。また、Dogでもない

Taroは、少なくとも、Dogではない。

上記を元に作成したビューは以下

create view pets_animals as select pets.name as pet_name , animals.kind as animal_kind from pets cross join animals where ( pets.name = 'Wendy' and animals.kind = 'Dog' ) or ( pets.name = 'Tiger' and animals.kind not in ('Dog', 'Turtle') ) or ( pets.name = 'Lisa' and animals.kind not in ('Snake', 'Dog') ) or ( pets.name = 'Taro' and animals.kind not in ('Dog') ) /

問い合わせると以下のようになります（PET_NAME, ANIMAL_KIND列で昇順にソートしています）

PET_NAME ANIMAL_KIND ------------------------------ ------------------------------ Lisa Cat Lisa Turtle Taro Cat Taro Snake Taro Turtle Tiger Cat Tiger Snake Wendy Dog 8 rows selected.

3つ目のビュー、
「ペットのオーナー」と「動物の種類」を関連づけるビュー = owners_animals

Hiro　:「僕が飼っているのは、Tiger だよ。 Turtle じゃないよ」

Scott :「僕は Snake を飼っているよ」

Steve :「Dog の名前は Wendy だよ。僕は Dog はかってないけど」

問題からペットのオーナーと動物の種類を関連として、以下が読み取れますよね。

Scottは、Snakeを飼っている

Steveは、Dogを飼っていない。また、Snakeも飼っていない（同種のペットを飼っているオーナーはおらず、SnakeはScottが飼っているから）

Hiroは、Turtleは飼っていない。また、Snakeも飼っていない（理由は同上）

Larryは、何をか不明だが、少なくとも、Snakeではない（理由は同上）

上記を元に作ったビューが以下

create view owners_animals as select owners.name as owner_name , animals.kind as animal_kind from owners cross join animals where ( owners.name = 'Scott' and animals.kind = 'Snake' ) or ( owners.name = 'Steve' and animals.kind not in ('Dog', 'Snake') ) or ( owners.name = 'Hiro' and animals.kind not in ('Turtle', 'Snake') ) or ( owners.name = 'Larry' and animals.kind not in ('Snake') ) /

問い合わせると以下のようになります（OWNER_NAME, ANIMAL_KIND列で昇順にソートしています）

OWNER_NAME ANIMAL_KIND ------------------------------------------------------------ ------------------------------ Hiro Cat Hiro Dog Larry Cat Larry Dog Larry Turtle Scott Snake Steve Cat Steve Turtle 8 rows selected.

オーナー、ペットの名前、ペットの種類の関連を作成したので、これらを結合してみましょう（まだ途中経過ですよ）

ここまで来ると直積は不要ですねw
しかし、まだ、オーナー→ペットの名前→動物の種類の候補が複数あるオーナーが残っています！！！　

Hiroと、Scottは確定ですが、LarryとSteveは複数候補があるので、さらに絞り込んでいく必要がありますよね。

select count(op.owner_name) over( partition by op.owner_name ) as num_of_rows , op.owner_name , op.pet_name , oa.animal_kind from owners_pets op inner join owners_animals oa on op.owner_name = oa.owner_name inner join pets_animals pa on op.pet_name = pa.pet_name and oa.animal_kind = pa.animal_kind order by op.owner_name , op.pet_name , oa.animal_kind /

3つのビューを結合すると以下の結果を得られますが、繋がりを１つに絞りきれていません。＞＜

NUM_OF_ROWS OWNER_NAME PET_NAME ANIMAL_KIND ----------- ------------------------------ ------------------------------ ------------------------------ 1 Hiro Tiger Cat 5 Larry Lisa Cat 5 Larry Lisa Turtle 5 Larry Taro Cat 5 Larry Taro Turtle 5 Larry Wendy Dog 1 Scott Taro Snake 4 Steve Lisa Cat 4 Steve Lisa Turtle 4 Steve Taro Cat 4 Steve Taro Turtle 11 rows selected.

上記、結合結果から　num_or_rows = 1　は確定、2以上は絞りきれておらず、複数の候補が残っていることが見えてきます。

ここでポイントになるのは、確定したデータです。同一名のペットおよび、同種のペットはない！！　という条件があるので、HiroとScottがオーナーであると確定したことで以下が決まります。

まだ、複数候補が残っているオーナーに関して、

ペットの名前において、TigerとTaroは、Larryまたは、Steveのペット名ではない

動物の種類において、CatとSnakeは、Larryまたは、Steveが飼っている動物の種類ではない

これをもう少しブラッシュアップすると以下のようになります。

まだ、複数候補が残っているオーナーに関して、

ペットの名前において、オーナーの確定した名前は除外できる

動物の種類において、オーナーの確定した種類は除外できる

オーナーが確定した状態、複数の候補が残っている状態は、ウィンドウ関数COUNT()でカウントした行数で判断できるようにしてあります！！！

よし、解けそうだ！w

with pet_owner_unknown as ( select count(op.owner_name) over( partition by op.owner_name ) as num_of_rows , op.owner_name , op.pet_name , oa.animal_kind from owners_pets op inner join owners_animals oa on op.owner_name = oa.owner_name inner join pets_animals pa on op.pet_name = pa.pet_name and oa.animal_kind = pa.animal_kind order by op.owner_name , op.pet_name , oa.animal_kind ) select count(owner_name) over( partition by owner_name ) as num_of_rows , owner_name , pet_name , animal_kind from pet_owner_unknown where num_of_rows = 1 or ( num_of_rows > 1 and pet_name not in ( select pet_name from pet_owner_unknown where num_of_rows = 1 ) and animal_kind not in ( select animal_kind from pet_owner_unknown where num_of_rows = 1 ) ) order by owner_name /

結果は！！

NUM_OF_ROWS OWNER_NAME PET_NAME ANIMAL_KIND ----------- ------------------------------ ------------------------------ ------------------------------ 1 Hiro Tiger Cat 2 Larry Wendy Dog 2 Larry Lisa Turtle 1 Scott Taro Snake 1 Steve Lisa Turtle

あ”〜〜〜おしい、まだ、Larryが確定できてないw　Larry〜〜〜〜〜〜っw　狙ったわけではありませんが、Larryが残ってしまったw　

ここまでくれば、あと一息w

同じ条件を適用して。。。。

with pet_owner_unknown as ( select count(op.owner_name) over( partition by op.owner_name ) as num_of_rows , op.owner_name , op.pet_name , oa.animal_kind from owners_pets op inner join owners_animals oa on op.owner_name = oa.owner_name inner join pets_animals pa on op.pet_name = pa.pet_name and oa.animal_kind = pa.animal_kind order by op.owner_name , op.pet_name , oa.animal_kind ), pet_owners as ( select count(owner_name) over( partition by owner_name ) as num_of_rows , owner_name , pet_name , animal_kind from pet_owner_unknown where num_of_rows = 1 or ( num_of_rows > 1 and pet_name not in ( select pet_name from pet_owner_unknown where num_of_rows = 1 ) and animal_kind not in ( select animal_kind from pet_owner_unknown where num_of_rows = 1 ) ) order by owner_name ) select owner_name , pet_name , animal_kind from pet_owners where num_of_rows = 1 or ( num_of_rows > 1 and pet_name not in ( select pet_name from pet_owners where num_of_rows = 1 ) and animal_kind not in ( select animal_kind from pet_owners where num_of_rows = 1 ) ) order by owner_name /

OWNER_NAME PET_NAME ANIMAL_KIND ------------------------------ ------------------------------ ------------------------------ Hiro Tiger Cat Larry Wendy Dog Scott Taro Snake Steve Lisa Turtle

できたーーーー。

明日のクリスマスイブ、24番目の窓は、みやくるさんのターンです。お楽しみに〜〜〜〜。

メリークリスマス！　そして、よいお年をお迎えください。

あ！、 One more thing!

実行計画はみておきましょうね。おそらくIndex Only ScanとTemp Table Transform後のマテリアライズされた一時表の全表走査のはず！

SCOTT@ORCL> 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

お！　ほぼ想定通りですが、　LOAD AS SELECT (CURSOR DURATION MEMORY)　とありますね。12cの機能だったと思う（間違ってたら誰かコメントよろ）。
TEMP TABLE TRANSFORMATIONで、一時表を使用して問合せを実行したことを示していますが、CURSOR DURATION MEMORYとでているので、メモリーが利用可能であればメモリーへ一時表の結果を格納したことを示しています。（メモリーが使用できなかった場合は、一時データをディスクに書き込みます）という動きですね。メモリー使えればキャッシュされることになるので、一時表の全表走査のコストは低めに抑えられるということになります。この仕組みのおかげで、OLTPライクな軽めのSQLでもWITHがいい感じで使える可能性もあるな。と個人的には思ってるところ。一時表にしたところで行数絞り込めてないとOLTPにはキツイ場合もありますけど、その辺りは見極めと行数のブレの可能性次第。。。

Execution Plan ---------------------------------------------------------- Plan hash value: 1308123330 ---------------------------------------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ---------------------------------------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 7 | 553 | 13 (8)| 00:00:01 | | 1 | TEMP TABLE TRANSFORMATION | | | | | | | 2 | LOAD AS SELECT (CURSOR DURATION MEMORY)| SYS_TEMP_0FD9D6619_665472 | | | | | | 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_0FD9D661A_665472 | | | | | | 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_0FD9D6619_665472 | 7 | 119 | 2 (0)| 00:00:01 | |* 14 | VIEW | | 1 | 30 | 1 (0)| 00:00:01 | | 15 | TABLE ACCESS FULL | SYS_TEMP_0FD9D6619_665472 | 7 | 119 | 2 (0)| 00:00:01 | |* 16 | VIEW | | 1 | 30 | 1 (0)| 00:00:01 | | 17 | TABLE ACCESS FULL | SYS_TEMP_0FD9D6619_665472 | 7 | 119 | 2 (0)| 00:00:01 | | 18 | SORT ORDER BY | | 7 | 553 | 3 (34)| 00:00:01 | |* 19 | FILTER | | | | | | | 20 | VIEW | | 7 | 553 | 2 (0)| 00:00:01 | | 21 | TABLE ACCESS FULL | SYS_TEMP_0FD9D661A_665472 | 7 | 217 | 2 (0)| 00:00:01 | |* 22 | VIEW | | 7 | 210 | 2 (0)| 00:00:01 | | 23 | TABLE ACCESS FULL | SYS_TEMP_0FD9D661A_665472 | 7 | 217 | 2 (0)| 00:00:01 | |* 24 | VIEW | | 7 | 210 | 2 (0)| 00:00:01 | | 25 | TABLE ACCESS FULL | SYS_TEMP_0FD9D661A_665472 | 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_0FD9D6619_665472" "T1") "PET_OWNER_UNKNOWN" 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_0FD9D6619_665472" "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 ("T1") */ "C0" "NUM_OF_ROWS","C1" "OWNER_NAME","C2" "PET_NAME","C3" "ANIMAL_KIND" FROM "SYS"."SYS_TEMP_0FD9D661A_665472" "T1") "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_0FD9D661A_665472" "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) Statistics ---------------------------------------------------------- 0 recursive calls 2 db block gets 49 consistent gets 0 physical reads 384 redo size 835 bytes sent via SQL*Net to client 1827 bytes received via SQL*Net from client 2 SQL*Net roundtrips to/from client 3 sorts (memory) 0 sorts (disk) 4 rows processed

では。また。

誰がどんな名前のペットを飼っているのかな？その１ / JPOUG Advent Calendar Day 1

類似エントリー
標準はあるにはあるが癖の多いSQL 全部俺　おまけ SQL de 湯婆婆やるにも癖がでるw
標準はあるにはあるが癖の多いSQL 全部俺　#25 SQL de Fractalsにも癖がある:)
こんなのでいいのかなぁ。ズンドコキヨシ　　ObjectScript / MUMPS
PL/SQL de ケンブリッジ関数
 Mac de Caché というか MUMPS というか Objectscript か
 Oracle de Fizzbuzz #2
Oracle de Fizzbuzz #1 -　いまごろ・・・ですが・・

投稿日時 2021年12月23日 (木) 00時00分 Oracle, SQL, JPOUG, Advent Calendar | 固定リンク | 0 | コメント (0)

2021年9月25日 (土)

古くて新しい？遅延ブロッククリーンアウト (deferred block cleanout) #12

Previously on Mac De Oracle
前回、前々回とIASでdirect path writeであるか否かで、そのコミットおよび遅延ブロッククリーンアウトの有無が決まるという動きを確認しました。

今回は、DDLですが、親戚みたいな挙動のCTASではどうなるか確認しておきます。CTASはDDLなのでコミットは不要ですよね。また、 direct path writeが前提になっていることも皆さんご存知の通り。

ということは、IAS + APPENDヒントで、direct path write させた時と同じような挙動になるはず。。。。ですよね。

手順はいつもの図でご確認ください。（DDLなので手順も単純になっています）

0) 対象表のdrop
対象表のHOGE2は削除しておきます。CTASで作成することになるので。

SCOTT@orcl> @droppurge_hoge2.sql 1* drop table hoge2 purge Table dropped. Elapsed: 00:00:02.79

1) 統計をクリアするためOracle再起動

$ sudo service oracle restart

2) PDBのscottでログインしてclient_infoをセット
v$sessionのclient_info列の'TargetSession'文字列で他のSCOTTユーザーのセッションを特定するため。

SCOTT@orcl> @set_client_info 1 begin 2 DBMS_APPLICATION_INFO.SET_CLIENT_INFO('Target Session'); 3* end; PL/SQL procedure successfully completed. Elapsed: 00:00:00.00 SCOTT@orcl>

3) CDBのSYSで統計取得（初回）
内容は省略！（ベースラインを取得しているだけなので）

SYS$orclcdb> @show_stat scott ...略...

4) PDBのSCOTTユーザーでCTAS（データサイズは、コミットクリーンアウトではクリーンアウト仕切れないサイズ）

SCOTT@orcl> @ctas_from_hoge.sql 1* create table hoge2 as select * from hoge Table created. Elapsed: 00:00:07.41

5) CDBのSYSで統計取得（CTAS後）
DDLなのでコミットはありませんが、念の為に確認すると、commit cleanouts、commit cleanouts successfully completed　はほんの少しだけ。このテストケースではノイズ程度の量です。
DDL終了時にクリーンアウトは発生していないと読み取れます。（この後の手順で遅延クリーンアウトも発生していなければ。direct path writeではクリーンアウトが必要な状態にはならないということは間違いないと判断するできますよね）

参考程度ですが、physical writes 、physical writes direct、physical writes non checkpoint が同数です。物理書き込みが発生し、かつ、direct path writeでチェックポイントで書き出されたものではないということが確認できます。想定通り、CTASは direct path writeで書き出されているということがわかります。
(HOGE表のデータが載っているブロック数は、66667 ブロックであることは以前確認した通りの値です)

また、physical reads　と　physical reads direct は、HOGE表のブロック数以上あり、HOGE表は direct path readでお読み込まれていることがわかります。このときのfree buffer requested は非常に低いことは、バッファキャッシュを介さず、ストレージへ書き出されていることを示しています。

統計値が変動したもののみ記載
(CDB）システム統計

SOURCE NAME VALUE ------- ---------------------------------------------------- --------------- sysstat commit cleanouts 21 sysstat commit cleanouts successfully completed 21 sysstat consistent gets 72654 sysstat db block changes 3898 sysstat deferred (CURRENT) block cleanout applications 7 sysstat free buffer requested 819 sysstat immediate (CURRENT) block cleanout applications 8 sysstat no work - consistent read gets 69569 sysstat physical reads 67150 sysstat physical reads direct 66709 sysstat physical writes 66667 sysstat physical writes direct 66667 sysstat physical writes non checkpoint 66667

(PDB)　SCOTTのセッション統計

SOURCE NAME VALUE ------- ---------------------------------------------------- --------------- sesstat commit cleanouts 21 sesstat commit cleanouts successfully completed 21 sesstat consistent gets 72366 sesstat db block changes 3898 sesstat deferred (CURRENT) block cleanout applications 7 sesstat free buffer requested 818 sesstat immediate (CURRENT) block cleanout applications 8 sesstat no work - consistent read gets 69415 sesstat physical reads 67149 sesstat physical reads direct 66709 sesstat physical writes 66667 sesstat physical writes direct 66667 sesstat physical writes non checkpoint 66667

6) PDBのSCOTTユーザーで遅延ブロッククリーンアウト有無確認（対象表をscattered readで全表走査）

IASで direct path writeさせた場合同様に、direct path writeで書き出された場合、クリーンアウトするブロックは存在しないため、遅延ブロッククリーンアウトも発生しないという状況になります。
REDOは多少生成あれていますが、recursive call 等によるものと考えられ、このテストケースではノイズの類程度です。システム／セッション統計値をみることでその点も確認できます。

SCOTT@orcl> @table_full_scan_hoge2.sql 1* alter session set "_serial_direct_read" = never Session altered. Elapsed: 00:00:00.00 1* alter session set "_very_large_object_threshold" = 20400 Session altered. Elapsed: 00:00:00.00 set autot trace exp stat 1* select * from hoge2 200000 rows selected. Elapsed: 00:00:06.66 Execution Plan ---------------------------------------------------------- Plan hash value: 1530105727 --------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | --------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 200K| 382M| 18174 (1)| 00:00:01 | | 1 | TABLE ACCESS FULL| HOGE2 | 200K| 382M| 18174 (1)| 00:00:01 | --------------------------------------------------------------------------- Statistics ---------------------------------------------------------- 14 recursive calls 12 db block gets 80022 consistent gets 66669 physical reads 2108 redo size 406775148 bytes sent via SQL*Net to client 147265 bytes received via SQL*Net from client 13335 SQL*Net roundtrips to/from client 0 sorts (memory) 0 sorts (disk) 200000 rows processed set autot off

7) CDBのSYSで統計取得（遅延ブロッククリーンアウト有無確認。対象表をscattered readで全表走査）
deferred (CURRENT) block cleanout applications　や、immediate (CURRENT) block cleanout applicationsなど遅延ブロッククリーンアウトで動く統計に極わずかに動きがありますが、数ブロックなので気にする程度ではないです。遅延ブロッククリーンアウトは発生していないと読み取れます。

また、physical reads は該当表のブロック数程度のブロック数となっており、physical reads direct が発生していないことから、 scattered read　でバッファキャッシュに載せられたことが確認できます。free buffer requested もほぼ同じ値になっていることからも同様のことが言えます。

統計値が変動したもののみ記載
(CDB）システム統計

SOURCE NAME VALUE ------- ---------------------------------------------------- --------------- sysstat commit cleanouts 16 sysstat commit cleanouts successfully completed 16 sysstat consistent gets 105725 sysstat db block changes 255 sysstat deferred (CURRENT) block cleanout applications 8 sysstat free buffer requested 67608 sysstat immediate (CURRENT) block cleanout applications 2 sysstat no work - consistent read gets 94138 sysstat physical reads 67567

(PDB)　SCOTTのセッション統計

SOURCE NAME VALUE ------- ---------------------------------------------------- --------------- sesstat commit cleanouts 6 sesstat commit cleanouts successfully completed 6 sesstat consistent gets 86719 sesstat db block changes 43 sesstat deferred (CURRENT) block cleanout applications 3 sesstat free buffer requested 66791 sesstat immediate (CURRENT) block cleanout applications 2 sesstat no work - consistent read gets 82976 sesstat physical reads 66783

まとめ

CTASはDDLで、　direct path write を伴うため、IASのAPPEND同様、対象データブロックはクリーンアウトが必要な状態にはならず、コミットおよび遅延ブロッククリーンアウトは発生しない！
ことが確認できました。　：）

次回は、一旦中締めにしますか。

つづく。

目がショボショボしてるから、なにか浮遊物の影響を受けてる気がする。ブタクサやヨモギの季節だもんな。（目だけなんだよなー。アレルギーの酷方のように鼻水でたりとかではなくて。疲れ目用の目薬では、効かないw）

・古くて新しい？遅延ブロッククリーンアウト (deferred block cleanout) #1
・古くて新しい？遅延ブロッククリーンアウト (deferred block cleanout) #2
・古くて新しい？遅延ブロッククリーンアウト (deferred block cleanout) #3
・古くて新しい？遅延ブロッククリーンアウト (deferred block cleanout) #4
・古くて新しい？遅延ブロッククリーンアウト (deferred block cleanout) #5
・古くて新しい？遅延ブロッククリーンアウト (deferred block cleanout) #6
・古くて新しい？遅延ブロッククリーンアウト (deferred block cleanout) #7
・古くて新しい？遅延ブロッククリーンアウト (deferred block cleanout) #8
・古くて新しい？遅延ブロッククリーンアウト (deferred block cleanout) #9
・古くて新しい？遅延ブロッククリーンアウト (deferred block cleanout) #10
・古くて新しい？遅延ブロッククリーンアウト (deferred block cleanout) #11

投稿日時 2021年9月25日 (土) 00時00分 Oracle, PL/SQL, チューニング, FAQ, SQL, パフォーマンス, Oracle Database 19c | 固定リンク | 0 | コメント (0)

2021年9月24日 (金)

古くて新しい？遅延ブロッククリーンアウト (deferred block cleanout) #11

Previously on Mac De Oracle
前回は、クリーンアウトの後始末をさせられる側ではなく、そもそも、後始末不要な状況もあるという確認でした。
IAS（Insert as Select)でdirect path writeで書き込まれたブロックは、クリーンアウトする必要がない状態なので、コミットクリーンアウトも遅延ブロッククリーンアウトも発生していないことはシステム統計やセッション統計からも明らかでした。

今回は、今一度確認ということで、IASでも非direct path writeだったら、やはりコミットクリーンアウトや遅延ブロッククリーンアウトは発生するよね！　というところだけは見ておこうと思います。

手順は前回と同じ。前回と異なる点は、4) の部分。IASで NOAPPEND ヒントを使い direct path writeを抑止している部分のみ。

0) 対象表のdrop/create

SCOTT@orcl> @droppurge_create_hoge2.sql 1* drop table hoge2 purge Table dropped. Elapsed: 00:00:00.67 1* create table hoge2 (id number, data varchar2(2000)) Table created. Elapsed: 00:00:00.05 1* select segment_name,blocks from user_segments where segment_name like '%HOGE2%' no rows selected Elapsed: 00:00:00.16

1) 統計をクリアするためOracle再起動

$ sudo service oracle restart

2) PDBのscottでログインしてclient_infoをセット
v$sessionのclient_info列の'TargetSession'文字列で他のSCOTTユーザーのセッションを特定するため。

SCOTT@orcl> @set_client_info 1 begin 2 DBMS_APPLICATION_INFO.SET_CLIENT_INFO('Target Session'); 3* end; PL/SQL procedure successfully completed. Elapsed: 00:00:00.00 SCOTT@orcl>

3) CDBのSYSで統計取得（初回）
内容は省略！（ベースラインを取得しているだけなので）

SYS$orclcdb> @show_stat scott ...略...

4) PDBのSCOTTユーザーでIAS（データサイズは、コミットクリーンアウトではクリーンアウト仕切れないサイズ、コミットなし）
このケースでは非direct path write でINSERTしたいので NOAPPEND ヒントで direct path write を抑止しています。

SCOTT@orcl> @ias_noappend_from_hoge.sql 1* insert /*+ noappend */ into hoge2 select * from hoge 200000 rows created. Elapsed: 00:00:16.79

5) CDBのSYSで統計取得（APPENDヒント付きのIAS後、未コミット）

IASでHOGE表を読み込み、HOGE2表へ非direct path write している様子が確認できますよね。HOGE表の読み込みは direct path read 、HOGE2表へは非direct path write していることが読み取れます。
free buffer requested で読み込みブロック相当のブロックがバッファキャッシュへ載せられているように見えますが、読み込みは direct path read　なのでバッファキャッシュには載りません。ようするに、HOGE2表向けのデータと考えることができますよね。このキャッシュされたブロックが本当にHOGE2表向けブロックであるかどうかは、これ以降の操作で物理読み込みが発生しないということで確認することができます。

(HOGE表のデータが載っているブロック数は、66667 ブロックであることは前々回も確認した通りの値です)

統計値が変動したもののみ記載
(CDB）システム統計

SOURCE NAME VALUE ------- ---------------------------------------------------- --------------- sysstat DBWR checkpoint buffers written 19158 sysstat DBWR checkpoints 2 sysstat DBWR thread checkpoint buffers written 19158 sysstat DBWR transaction table writes 22 sysstat DBWR undo block writes 299 sysstat commit cleanouts 6 sysstat commit cleanouts successfully completed 6 sysstat consistent gets 110098 sysstat db block changes 443304 sysstat deferred (CURRENT) block cleanout applications 5 sysstat free buffer requested 67998 sysstat immediate (CURRENT) block cleanout applications 1 sysstat no work - consistent read gets 66823 sysstat physical reads 66730 sysstat physical reads direct 66709 sysstat physical writes 19158 sysstat physical writes from cache 19158 sysstat physical writes non checkpoint 19158 sysstat transaction tables consistent reads - undo records applied 2

(PDB)　SCOTTのセッション統計

SOURCE NAME VALUE ------- ---------------------------------------------------- --------------- sesstat commit cleanouts 6 sesstat commit cleanouts successfully completed 6 sesstat consistent gets 109971 sesstat db block changes 443304 sesstat deferred (CURRENT) block cleanout applications 5 sesstat free buffer requested 67996 sesstat immediate (CURRENT) block cleanout applications 1 sesstat no work - consistent read gets 66781 sesstat physical reads 66730 sesstat physical reads direct 66709

6) PDBのSCOTTユーザーでコミットの実行

SCOTT@orcl> commit; Commit complete.

7) CDBのSYSで統計取得（コミット後）
APPENDモードのIASと異なり、NOAAPENDモードでは、はやり、コミットクリーンアウトが発生しています。バッファキャッシュの10%-15%の範囲のブロックがコミット時にクリーンアウトされている状況が　commit cleanouts successfully completed　および、commit cleanouts　から確認することができます。

統計値が変動したもののみ記載
(CDB）システム統計

SOURCE NAME VALUE ------- ---------------------------------------------------- --------------- sysstat commit cleanouts 55709 sysstat commit cleanouts successfully completed 55709 sysstat consistent gets 18547 sysstat db block changes 289 sysstat deferred (CURRENT) block cleanout applications 4 sysstat free buffer requested 791 sysstat no work - consistent read gets 10937 sysstat physical reads 758 sysstat transaction tables consistent reads - undo records applied 1

(PDB)　SCOTTのセッション統計

SOURCE NAME VALUE ------- ---------------------------------------------------- --------------- sesstat commit cleanouts 55700 sesstat commit cleanouts successfully completed 55700 sesstat db block changes 1

8) PDBのSCOTTユーザーで遅延ブロッククリーンアウト有無確認（対象表をscattered readで全表走査）

direct path writeと非direct path writeの違いはハッキリでました。REDOログは大量に生成され、遅延ブロッククリーンアウトは発生しているようです。
また、物理読み込みは発生していないので、バッファキャッシュにヒットしているという状況も読み取れます。

SCOTT@orcl> @table_full_scan_hoge2.sql 1* alter session set "_serial_direct_read" = never Session altered. Elapsed: 00:00:00.00 1* alter session set "_very_large_object_threshold" = 20400 Session altered. Elapsed: 00:00:00.00 set autot trace exp stat 1* select * from hoge2 200000 rows selected. Elapsed: 00:00:05.74 Execution Plan ---------------------------------------------------------- Plan hash value: 1530105727 --------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | --------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 172K| 167M| 18223 (1)| 00:00:01 | | 1 | TABLE ACCESS FULL| HOGE2 | 172K| 167M| 18223 (1)| 00:00:01 | --------------------------------------------------------------------------- Note ----- - dynamic statistics used: dynamic sampling (level=2) Statistics ---------------------------------------------------------- 19 recursive calls 13 db block gets 91462 consistent gets 2 physical reads 967388 redo size 406775148 bytes sent via SQL*Net to client 147265 bytes received via SQL*Net from client 13335 SQL*Net roundtrips to/from client 0 sorts (memory) 0 sorts (disk) 200000 rows processed ¥ set autot off

9) CDBのSYSで統計取得（遅延ブロッククリーンアウト有無確認。対象表をscattered readで全表走査）
実行統計の示す通り、遅延ブロッククリーンアウトが発生していることは、immediate (CR) block cleanout applications、cleanouts only - consistent read getsのブロック数からもハッキリ確認することができます！（コミットクリーンアウトできなかったブロック数です）

physical readsはほんの少しありますが、発生していないとみなしても良い程度です。このケースはscattered readが発生していない。つまり、非direct path writeでバッファキャッシュに載ったブロックにヒットしていることで、scattered readの必要がなかった！　ということを意味しています。もし、この時、バッファキャッシュから該当表のブロックがある程度落ちていれば、physical readsが表のブロック数程度まで増加していたはずです。（多数の同時実行トランザクションが存在する状況であればキャッシュからエージアウトされ、物理読み込みが大量に発生するというケースは珍しくありません。その分処理時間も長くなるわけで、程度とデータサイズサイズしだいで処理時間も延びることが予想できます。場合よっては、処理時間がかかりすぎて、ザワザワしたり。。。w）

統計値が変動したもののみ記載
(CDB）システム統計

SOURCE NAME VALUE ------- ---------------------------------------------------- --------------- sysstat cleanouts only - consistent read gets 10967 sysstat commit cleanouts 19 sysstat commit cleanouts successfully completed 19 sysstat consistent gets 98619 sysstat db block changes 11065 sysstat deferred (CURRENT) block cleanout applications 8 sysstat free buffer requested 180 sysstat immediate (CR) block cleanout applications 10967 sysstat immediate (CURRENT) block cleanout applications 5 sysstat no work - consistent read gets 72340 sysstat physical reads 169

(PDB)　SCOTTのセッション統計

SOURCE NAME VALUE ------- ---------------------------------------------------- --------------- sesstat cleanouts only - consistent read gets 10967 sesstat commit cleanouts 6 sesstat commit cleanouts successfully completed 6 sesstat consistent gets 98015 sesstat db block changes 11011 sesstat deferred (CURRENT) block cleanout applications 2 sesstat free buffer requested 121 sesstat immediate (CR) block cleanout applications 10967 sesstat immediate (CURRENT) block cleanout applications 2 sesstat no work - consistent read gets 72013 sesstat physical reads 113

まとめ

IASで非direct path write してINSERTされた場合、ブロッククリーンアウトが通常通り発生する（コミット時でも遅延でも）
direct path write時との統計値の違いからも明らかですね。

前回のIAS（APPEND)時の遅延ブロッククリーンアウトがなかったケースの統計を再掲しておきます。統計値の違いをよーく確認してみてください。（試験に。。。でないですけどw）

統計値が変動したもののみ記載
(CDB）システム統計

SOURCE NAME 　 VALUE ------- ---------------------------------------------------- --------------- sysstat cleanouts only - consistent read gets 1 sysstat commit cleanouts 16 sysstat commit cleanouts successfully completed 16 sysstat consistent gets 105046 sysstat db block changes 225 sysstat deferred (CURRENT) block cleanout applications 9 sysstat free buffer requested 67576 sysstat immediate (CR) block cleanout applications 1 sysstat immediate (CURRENT) block cleanout applications 2 sysstat no work - consistent read gets 93908 sysstat physical reads 67536

(PDB)　SCOTTのセッション統計

SOURCE NAME VALUE ------- ---------------------------------------------------- --------------- sesstat cleanouts only - consistent read gets 1 sesstat commit cleanouts 6 sesstat commit cleanouts successfully completed 6 sesstat consistent gets 86566 sesstat db block changes 44 sesstat deferred (CURRENT) block cleanout applications 3 sesstat free buffer requested 66778 sesstat immediate (CR) block cleanout applications 1 sesstat immediate (CURRENT) block cleanout applications 2 sesstat no work - consistent read gets 82891 sesstat physical reads 66770

次回は、CTAS ( create table as select ) ではどうなるか確かめます。（まだいくつかの関連統計を動かせていないケースありw）

次回へつづく。

東京は、自転車での移動や買い物のほうが渋滞や混雑のストレスがなくていいな。久々に coutry side側をドライブしてたが、ノーストレレスだった。一転機能は、買い物でドライブするも、いちいち渋滞w
WfHも年単位になると、すでに都心の満員電車や渋滞に耐えられない感じになってる気がしないでもないw （渋滞でスタックしている時間がもったいないw）

・古くて新しい？遅延ブロッククリーンアウト (deferred block cleanout) #1
・古くて新しい？遅延ブロッククリーンアウト (deferred block cleanout) #2
・古くて新しい？遅延ブロッククリーンアウト (deferred block cleanout) #3
・古くて新しい？遅延ブロッククリーンアウト (deferred block cleanout) #4
・古くて新しい？遅延ブロッククリーンアウト (deferred block cleanout) #5
・古くて新しい？遅延ブロッククリーンアウト (deferred block cleanout) #6
・古くて新しい？遅延ブロッククリーンアウト (deferred block cleanout) #7
・古くて新しい？遅延ブロッククリーンアウト (deferred block cleanout) #8
・古くて新しい？遅延ブロッククリーンアウト (deferred block cleanout) #9
・古くて新しい？遅延ブロッククリーンアウト (deferred block cleanout) #10

投稿日時 2021年9月24日 (金) 11時00分 Oracle, PL/SQL, チューニング, FAQ, SQL, パフォーマンス, Oracle Database 19c | 固定リンク | 0 | コメント (0)

2021年9月22日 (水)

古くて新しい？遅延ブロッククリーンアウト (deferred block cleanout) #10

Previously on Mac De Oracle
前回は、SELECT文であっても遅延ブロッククリーンアウトが発生すると該当ブロックは更新され、REDOログも生成される。ただし、direct path read で読み込まれた場合を除く。
という動きをみました。

今回もdirect pathがらみです。といっても direct path write だったら、コミットクリーンアウトや、遅延ブロッククリーンアウトはどういう扱いになるのだろう。。。と
（このシリーズの初回で紹介したいろいろなブログに答えはあるのですがw）

システム統計やセッション統計の統計値から、それをどう読み取るか。γGTP高いから肝臓あたりに問題があるか、検査前日に酒飲んじゃったでしょ！　的なところを診て、なにがおきているか診察していくシリーズなので、それぞれの統計と、auto traceによる実行計画と実行統計を診ていくわけですが。。w

ということで、今回は、前回利用していた表を元にIASで別表を作成し、コミット前後の状況を診ていきたいとおもいます。IASと言っても direct path write　になるケースと従来型のロードがあるのは皆さんご存知だと思いますが、まずは、 direct path writeの方から挙動を診ていくことにします。手順はざっとこんな感じ

そういえば、以前、IASで、direct path write かどうか判別しやすくなったよねーというネタをやってましたね。実行計画だけでも違いがわかりやすくなっているので便利になりました。：）

実行計画は、SQL文のレントゲン写真だ！ No.30より、LOAD TABL CONVENTIONAL vs. LOAD AS SELECTの実行計画の違い。

0) 対象表のdrop/create

SCOTT@orcl> @droppurge_create_hoge2.sql 1* drop table hoge2 purge Table dropped. Elapsed: 00:00:00.74 1* create table hoge2 (id number, data varchar2(2000)) Table created. Elapsed: 00:00:00.07 1* select segment_name,blocks from user_segments where segment_name like '%HOGE2%' no rows selected Elapsed: 00:00:00.15

1) 統計をクリアするためOracle再起動

$ sudo service oracle restart

2) PDBのscottでログインしてclient_infoをセット
v$sessionのclient_info列の'TargetSession'文字列で他のSCOTTユーザーのセッションを特定するため。

SCOTT@orcl> @set_client_info 1 begin 2 DBMS_APPLICATION_INFO.SET_CLIENT_INFO('Target Session'); 3* end; PL/SQL procedure successfully completed. Elapsed: 00:00:00.00 SCOTT@orcl>

3) CDBのSYSで統計取得（初回）
内容は省略！（ベースラインを取得しているだけなので）

SYS$orclcdb> @show_stat scott ...略...

4) PDBのSCOTTユーザーでIAS（データサイズは、コミットクリーンアウトではクリーンアウト仕切れないサイズ、コミットなし）
このケースでは direct path write でINSERTしたいので APPEND ヒントで direct path write を強制しています。 direct path read とは異なり、ヒントで制御できるのは楽w

SCOTT@orcl> @ias_from_hoge.sql 1* insert /*+ append */ into hoge2 select * from hoge 200000 rows created. Elapsed: 00:00:10.42

5) CDBのSYSで統計取得（APPENDヒント付きのIAS後、未コミット）

IASでHOGE表を読み込み、HOGE2表へdirect path write している様子が確認できますよね。HOGE表の読み込みは direct path read 、HOGE2表へは direct path write している状況がはっきりでていてわかりやすい結果を得られました :)
(HOGE表のデータが載っているブロック数は、66667 ブロックであることは前回も確認した通りの値です)

統計値が変動したもののみ記載
(CDB）システム統計

SOURCE NAME VALUE ------- ---------------------------------------------------- --------------- sysstat commit cleanouts 16 sysstat commit cleanouts successfully completed 16 sysstat consistent gets 72460 sysstat db block changes 3131 sysstat deferred (CURRENT) block cleanout applications 12 sysstat free buffer requested 792 sysstat immediate (CURRENT) block cleanout applications 3 sysstat no work - consistent read gets 69328 sysstat physical reads 67121 sysstat physical reads direct 66709 sysstat physical writes 66667 sysstat physical writes direct 66667 sysstat physical writes non checkpoint 66667

(PDB)　SCOTTのセッション統計

SOURCE NAME VALUE ------- ---------------------------------------------------- --------------- sesstat commit cleanouts 16 sesstat commit cleanouts successfully completed 16 sesstat consistent gets 72373 sesstat db block changes 3131 sesstat deferred (CURRENT) block cleanout applications 12 sesstat free buffer requested 792 sesstat immediate (CURRENT) block cleanout applications 3 sesstat no work - consistent read gets 69291 sesstat physical reads 67121 sesstat physical reads direct 66709 sesstat physical writes 66667 sesstat physical writes direct 66667 sesstat physical writes non checkpoint 66667

6) PDBのSCOTTユーザーでコミットの実行

SCOTT@orcl> commit; Commit complete.

7) CDBのSYSで統計取得（コミット後）
direct path writeでバッファキャッシュを経由せず書き出されたブロックはコミット時にはクリーンアウトの対象にはなっていないようですね。。。。統計をみる限りノイズ程度ですね。
ということは全てのブロックが遅延ブロッククリーンアウト対象になってしまうのか、または、その逆で、最初からクリーンアウト対象にもなっていないかということになります。次の全表走査の結果でどちらであるか、わかるはずです！！！！（ニヤニヤ、それ、ねらってやってるので、答えは知っているわけですがw）

統計値が変動したもののみ記載
(CDB）システム統計

SOURCE NAME VALUE ------- ---------------------------------------------------- --------------- sysstat commit cleanouts 25 sysstat commit cleanouts successfully completed 25 sysstat consistent gets 12104 sysstat db block changes 1557 sysstat deferred (CURRENT) block cleanout applications 12 sysstat free buffer requested 714 sysstat immediate (CURRENT) block cleanout applications 4 sysstat no work - consistent read gets 7192 sysstat physical reads 705

(PDB)　SCOTTのセッション統計

SOURCE NAME VALUE ------- ---------------------------------------------------- --------------- sesstat commit cleanouts 2 sesstat commit cleanouts successfully completed 2 sesstat consistent gets 864 sesstat db block changes 1474 sesstat deferred (CURRENT) block cleanout applications 1 sesstat free buffer requested 37 sesstat no work - consistent read gets 351 sesstat physical reads 32

8) PDBのSCOTTユーザーで遅延ブロッククリーンアウト有無確認（対象表をscattered readで全表走査）

REDOログは多少生成されていますが、実際に遅延ブロッククリーンアウトが発生した場合REDOログ量この程度では少なすぎますよね。
今回の検証目的からするとノイズの類ですね。むむむ。これは。。。。
（物理読み込みは発生しているので、direct path read か、scattered readのどちらかということにはなります。期待している動きは、Scattered read 。）

SCOTT@orcl> @table_full_scan_hoge2.sql 1* alter session set "_serial_direct_read" = never Session altered. Elapsed: 00:00:00.00 1* alter session set "_very_large_object_threshold" = 20400 Session altered. Elapsed: 00:00:00.00 set autot trace exp stat 1* select * from hoge2 200000 rows selected. Elapsed: 00:00:06.84 Execution Plan ---------------------------------------------------------- Plan hash value: 1530105727 --------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | --------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 200K| 382M| 18174 (1)| 00:00:01 | | 1 | TABLE ACCESS FULL| HOGE2 | 200K| 382M| 18174 (1)| 00:00:01 | --------------------------------------------------------------------------- Statistics ---------------------------------------------------------- 13 recursive calls 12 db block gets 80022 consistent gets 66668 physical reads 2284 redo size 406775148 bytes sent via SQL*Net to client 147265 bytes received via SQL*Net from client 13335 SQL*Net roundtrips to/from client 0 sorts (memory) 0 sorts (disk) 200000 rows processed set autot off

9) CDBのSYSで統計取得（遅延ブロッククリーンアウト有無確認。対象表をscattered readで全表走査）
physical reads は想定通りのブロック以上になっていますが、physical reads direct は発生していないので、scattered readによる全表走査であると読み取ることができます。
ただ、この状態でも、遅延ブロッククリーンアウトの発生を示す統計値はノイズ程度の値です。

つまり、direct path write でINSERTされたデータブロックはクリーンアウトが必要な状態だということになりますね。興味深い動きですよね。メモしておいたほうが良さそうです :)

統計値が変動したもののみ記載
(CDB）システム統計

SOURCE NAME VALUE ------- ---------------------------------------------------- --------------- sysstat cleanouts only - consistent read gets 1 sysstat commit cleanouts 16 sysstat commit cleanouts successfully completed 16 sysstat consistent gets 105046 sysstat db block changes 225 sysstat deferred (CURRENT) block cleanout applications 9 sysstat free buffer requested 67576 sysstat immediate (CR) block cleanout applications 1 sysstat immediate (CURRENT) block cleanout applications 2 sysstat no work - consistent read gets 93908 sysstat physical reads 67536

(PDB)　SCOTTのセッション統計

SOURCE NAME VALUE ------- ---------------------------------------------------- --------------- sesstat cleanouts only - consistent read gets 1 sesstat commit cleanouts 6 sesstat commit cleanouts successfully completed 6 sesstat consistent gets 86566 sesstat db block changes 44 sesstat deferred (CURRENT) block cleanout applications 3 sesstat free buffer requested 66778 sesstat immediate (CR) block cleanout applications 1 sesstat immediate (CURRENT) block cleanout applications 2 sesstat no work - consistent read gets 82891 sesstat physical reads 66770

まとめ

IASで direct path write してINSERTされた場合、ブロッククリーンアウトは発生しない！（コミット時でも遅延でも）
そもそもクリーンアウトが必要な状態になっていないというのが正しいのでしょうね。統計値としては全く動いてないに等しいので。

これも試験にでますよ（嘘w

次回は、同じIASもdirect path write　ではないケースではどうなるでしょう。。。（ここまでのエントリーを読んでいる方は、結果は想像できそうではありますが）

次回へつづく。

遅めの夏休みですが、まあ、普段とちがうのは、いろいろなタスクの締め切りに追われずに、マイペースな時間の過ごし方になるぐらいだな。この状況下ではw

・古くて新しい？遅延ブロッククリーンアウト (deferred block cleanout) #1
・古くて新しい？遅延ブロッククリーンアウト (deferred block cleanout) #2
・古くて新しい？遅延ブロッククリーンアウト (deferred block cleanout) #3
・古くて新しい？遅延ブロッククリーンアウト (deferred block cleanout) #4
・古くて新しい？遅延ブロッククリーンアウト (deferred block cleanout) #5
・古くて新しい？遅延ブロッククリーンアウト (deferred block cleanout) #6
・古くて新しい？遅延ブロッククリーンアウト (deferred block cleanout) #7
・古くて新しい？遅延ブロッククリーンアウト (deferred block cleanout) #8
・古くて新しい？遅延ブロッククリーンアウト (deferred block cleanout) #9

投稿日時 2021年9月22日 (水) 00時00分 Oracle, PL/SQL, チューニング, FAQ, SQL, パフォーマンス, Oracle Database 19c | 固定リンク | 0 | コメント (0)

2021年9月21日 (火)

古くて新しい？遅延ブロッククリーンアウト (deferred block cleanout) #9

Previously on Mac De Oracle
バッファキャッシュから溢れ出る程度のデータを登録しコミットした場合は、コミットクリーンアウトがどうなるか、遅延ブロッククリーンアウトされるブロック数はどの程度になるかという、寄り道でしたw

今回は、寄り道し過ぎて忘れるところだった、前回まで、scattered readを伴うtable full scanで発生していた遅延ブロッククリーンアウトが direct path read だったらどうなるか、というシリーズ :)　
(まだ続くのかーーーっ！　はいw　いろんなケースがありますから。シンプルなケースであっても。それぞれの基本的な挙動を知っいて損はないとおもいます。複雑なケースだと脳汁出過ぎるくらい複雑なので考えたくもなくなるのでw)

では、早速再現してみましょう。手順はこれまで行なってきたとおりで、違いは遅延ブロッククリーンアウトを発生させるためのtable full scanでdirect path readさせるという部分のみ。手順はscattered readとの比較も入れるので長くなってしまうので、追加ステップを追記した図を見てもらうと何やっているか、流れは理解しやすいかもしれません。

事前準備
（バッファキャッシュのサイズは元のサイズに戻してあります）

SYS@orclcdb> show sga Total System Global Area 4294963960 bytes Fixed Size 9143032 bytes Variable Size 805306368 bytes Database Buffers 3472883712 bytes Redo Buffers 7630848 bytes

200,000行登録したデータ(セグメントサイズ農地純粋にデータが乗っているブロック数）が乗っているブロック数はこんなところ。セグメントサイズはこれより多いですよ。行データが載っているブロックだけカウントしているので。

SCOTT@orcl> select count(distinct dbms_rowid.rowid_block_number(rowid)) as "blocks" from hoge; blocks ---------- 66667

ということで、セグメントサイズも確認。

SCOTT@orcl> select segment_name,blocks from user_segments where segment_name = 'HOGE'; SEGMENT_NAME BLOCKS ------------------------------ ---------- HOGE 67584

バッファキャッシュの10-15%程度はコミットクリーンアウトされるので、間をとってこれぐらいはコミットクリーンアウトされる。。。

SCOTT@orcl> select 3472883712 / 8192 * 0.13 from dual; 3472883712/8192*0.13 -------------------- 55111.68

残りは遅延ブロッククリーンアウトする。だいだいこんなもん。

SCOTT@orcl> select 66667 - 55112 from dual; 66667-55112 ----------- 11555

direct path read狙いの全表走査（シリアル実行で発動させることを意図していますが、言うこときいてくれるかあなぁ）

$ cat table_full_scan_with_dpr.sql alter session set "_serial_direct_read" = always . l / alter session set "_very_large_object_threshold" = 512 . l / !echo set autot trace exp stat set autot trace exp stat select * from hoge . l / !echo set autot off set autot off

Scattered Read狙いの全表走査のスクリプト

$ cat table_full_scan.sql alter session set "_serial_direct_read" = never . l / alter session set "_very_large_object_threshold" = 20400 . l / !echo set autot trace exp stat set autot trace exp stat select * from hoge . l / !echo set autot off set autot off

さて、うまく再現できるかどうか。。(今回もやったことをほぼすべて載せているので長いです）

0) 対象表をdrop/create
オブジェクトを作り直し前提合せ

SCOTT@orcl> @droppurge_create_hoge Table dropped. Table created. SCOTT@orcl> select segment_name,blocks from user_segments where segment_name like '%HOGE%'; no rows selected

1) 統計をクリアためOracle再起動

$ sudo service oracle restart

2) PDBのscottでログインしてclient_infoをセット
v$sessionのclient_info列の'TargetSession'文字列で他のSCOTTユーザーのセッションを特定するため。

SCOTT@orcl> @set_client_info 1 begin 2 DBMS_APPLICATION_INFO.SET_CLIENT_INFO('TargetSession'); 3* end; PL/SQL procedure successfully completed. Elapsed: 00:00:00.00 SCOTT@orcl>

3) CDBのSYSで統計取得（初回）
内容は省略！（ベースラインを取得しているだけなので）

SYS$orclcdb> @show_stat scott ...略...

4) PDBのSCOTTユーザーでINSERT（データ量2倍、コミットなし）
データサイズはバッファキャッシュに載るサイズ、コミットクリーンアウトではクリーンアウト仕切れないサイズで、ある程度の遅延ブロッククリーンアウトが発生するサイズになっているのは以前と同じ。

SCOTT@orcl> @insert_each_rows_2 1* begin for i in 1..200000 loop insert into hoge values(i, lpad('*', 2000, '*')); end loop; end; PL/SQL procedure successfully completed. Elapsed: 00:00:29.48 SCOTT@orcl>

5) CDBのSYSで統計取得（INSERT後、未コミット）
insertしただけなので、insertしたデータ量に応じたブロック数がバッファキャッシュに確保されたという程度の情報( free buffer requested = 68766 なので事前に確認していた 66667 以上になっています)は確認できます。
（バッファキャッシュに収まるデータ量ですし）ただ、checkpointの発生でいくらか書き出されているのも見えますよね( DBWR checkpoint buffers written )

統計値が変動したもののみ記載
(CDB）システム統計

SOURCE NAME　　　　　　　　　　　　　　　　　　　　　　　 VALUE ------- ---------------------------------------------------- --------------- sysstat DBWR checkpoint buffers written 22909 sysstat DBWR checkpoints 3 sysstat DBWR thread checkpoint buffers written 22902 sysstat DBWR transaction table writes 6 sysstat DBWR undo block writes 573 sysstat commit cleanouts 6 sysstat commit cleanouts successfully completed 6 sysstat consistent gets 49682 sysstat db block changes 744727 sysstat deferred (CURRENT) block cleanout applications 4 sysstat free buffer requested 68766 sysstat immediate (CURRENT) block cleanout applications 1 sysstat no work - consistent read gets 82 sysstat physical reads 9 sysstat physical writes 22909 sysstat physical writes from cache 22909 sysstat physical writes non checkpoint 22892

(PDB)　SCOTTのセッション統計

SOURCE NAME　　　　　　　　　　　　　　　　　　　　　　　 VALUE ------- ---------------------------------------------------- --------------- sesstat commit cleanouts 6 sesstat commit cleanouts successfully completed 6 sesstat consistent gets 49561 sesstat db block changes 744727 sesstat deferred (CURRENT) block cleanout applications 4 sesstat free buffer requested 68766 sesstat immediate (CURRENT) block cleanout applications 1 sesstat no work - consistent read gets 40 sesstat physical reads 9

6) PDBのSCOTTユーザーでコミットの実行

SCOTT@orcl> commit; Commit complete.

7) CDBのSYSで統計取得（コミット後）
コミットクリーンアウトされているブロック数を見ると、事前に計算していたバッファキャッシュの13%( 55112 blocks )に近い 55700 ブロックがコミットのタイミングでクリーンアウトされていることがわかります。ここまでは想定通りの動きです。

統計値が変動したもののみ記載
(CDB）システム統計

SOURCE NAME　　　　　　　　　　　　　　　　　　　　　　　 VALUE ------- ---------------------------------------------------- --------------- sysstat commit cleanout failures: callback failure 15 sysstat commit cleanouts 56077 sysstat commit cleanouts successfully completed 56062 sysstat consistent gets 50494 sysstat db block changes 7894 sysstat deferred (CURRENT) block cleanout applications 158 sysstat free buffer requested 3217 sysstat immediate (CURRENT) block cleanout applications 154 sysstat no work - consistent read gets 32764 sysstat physical reads 2962

(PDB)　SCOTTのセッション統計

SOURCE NAME　　　　　　　　　　　　　　　　　　　　　　　 VALUE ------- ---------------------------------------------------- --------------- sesstat commit cleanouts 55700 sesstat commit cleanouts successfully completed 55700 sesstat db block changes 1

8) PDBのSCOTTユーザーで、遅延ブロッククリーンアウト影響有無確認（対象表をdirect path readで全表走査）
全表走査させてコミットクリーンアウトされなかったブロックがクリーンアウトを確認します。ただし、全表走査ではありますが、direct path read で読み込ませるように工夫しています。

さて狙い通りになるかどうか。。。パラレルクエリーでない場合の強制はちょいとむずいのですが、見る限り、REDOログは生成されています。

ただ、以前のscattered read ( db file sequential read )で発生させた遅延ブロッククリーンアウトの検証結果に比べると明らかに少ない。。
なにかが違いますね。。。。むむむ。なんだろう？
scattered readでほぼ同じバッファキャッシュサイズで、遅延ブロッククリーンアウトさせた際、967432 redo size　というサイズが生成されていたのを思い出してみてください！！！　明らかに少ないです。。。。

SCOTT@orcl> @table_full_scan_with_dpr.sql 1* alter session set "_serial_direct_read" = always Session altered. Elapsed: 00:00:00.00 1* alter session set "_very_large_object_threshold" = 512 Session altered. Elapsed: 00:00:00.00 set autot trace exp stat 1* select * from hoge 200000 rows selected. Elapsed: 00:00:10.84 Execution Plan ---------------------------------------------------------- Plan hash value: 2339479017 -------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | -------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 214K| 207M| 18223 (1)| 00:00:01 | | 1 | TABLE ACCESS FULL| HOGE | 214K| 207M| 18223 (1)| 00:00:01 | -------------------------------------------------------------------------- Note ----- - dynamic statistics used: dynamic sampling (level=2) Statistics ---------------------------------------------------------- 23 recursive calls 13 db block gets 113559 consistent gets 66712 physical reads 2996 redo size 4539159 bytes sent via SQL*Net to client 147264 bytes received via SQL*Net from client 13335 SQL*Net roundtrips to/from client 0 sorts (memory) 0 sorts (disk) 200000 rows processed set autot off

9) CDBのSYSで統計取得（遅延ブロッククリーンアウト有無確認）（対象表をdirect path readで全表走査）
direct path read、遅延ブロッククリーンアウトの有無をシステム統計およびセッション統計から読み取ってみます！

物理読み込み( physical writes )とダイレクトパスリードを示す( physical writes from cache )が同じであることから、間違いなく direct path readが発生しています。ブロック数も　66667　ブロックを超えていることは確認できます。
ただ、immediate (CR) block cleanout applications が想定している量の3倍ぐらいあります:)
遅延ブロッククリーンアウトは行われているのは間違いないですが、前述の通りREDOサイズが異常に少ない。どういうことだろう。。（想定通りの結果に、ニヤニヤなわけですがw）

真相を探るため、われわれはアマゾンの奥深くへ入っていくのであった。。。W

少々本題からそれますが、DBWR parallel query checkpoint buffers written　で 44793 ブロックほど書き出されています。これが発生するのは direct path readの影響です。direct path read バッファキャッシュを介ず、常にストレージからデータを読み込む必要があります。この検証では、INSERTでバッファキャッシュに載っているデータであるため一旦書き出す必要があります。書き出されたデータを direct path read で読み込むのでこんな動きになっているというわけですね。。。。。

これ、よくよく考えると、コミットクリーンアウトされていないブロックもそのままの状態で書き出されてますよね。。。ここ試験にでますよ（嘘ですw

統計値が変動したもののみ記載
(CDB）システム統計

SOURCE NAME　　　　　　　　　　　　　　　　　　　　　　　 VALUE ------- ---------------------------------------------------- --------------- sysstat DBWR checkpoint buffers written 44793 sysstat DBWR checkpoints 2 sysstat DBWR object drop buffers written 2 sysstat DBWR parallel query checkpoint buffers written 44793 sysstat cleanouts only - consistent read gets 33057 sysstat commit cleanouts 18 sysstat commit cleanouts successfully completed 18 sysstat consistent gets 120519 sysstat db block changes 97 sysstat deferred (CURRENT) block cleanout applications 8 sysstat free buffer requested 127 sysstat immediate (CR) block cleanout applications 33057 sysstat immediate (CURRENT) block cleanout applications 5 sysstat no work - consistent read gets 50145 sysstat physical reads 66827 sysstat physical reads direct 66710 sysstat physical writes 44795 sysstat physical writes from cache 44795 sysstat physical writes non checkpoint 44795

(PDB)　SCOTTのセッション統計

SOURCE NAME　　　　　　　　　　　　　　　　　　　　　　　 VALUE ------- ---------------------------------------------------- --------------- sesstat cleanouts only - consistent read gets 33057 sesstat commit cleanouts 5 sesstat commit cleanouts successfully completed 5 sesstat consistent gets 120131 sesstat db block changes 48 sesstat deferred (CURRENT) block cleanout applications 1 sesstat free buffer requested 120 sesstat immediate (CR) block cleanout applications 33057 sesstat immediate (CURRENT) block cleanout applications 2 sesstat no work - consistent read gets 49952 sesstat physical reads 66823 sesstat physical reads direct 66710

10) Oracle再起動
Oracleを再起動して、諸々綺麗にした状態で、今一度、direct path readで全表走査させてみましょう。

$ sudo service oracle restart

11) PDBのscottでログインしてclient_infoをセット
v$sessionのclient_info列の'TargetSession'文字列で他のSCOTTユーザーのセッションを特定するため。

SCOTT@orcl> @set_client_info 1 begin 2 DBMS_APPLICATION_INFO.SET_CLIENT_INFO('TargetSession'); 3* end; PL/SQL procedure successfully completed. Elapsed: 00:00:00.00 SCOTT@orcl>

12) CDBのSYSで統計取得（再起動後初回）
内容は省略！（ベースラインを取得しているだけなので）

SYS$orclcdb> @show_stat scott ...略...

13) PDBのSCOTTユーザーで、遅延ブロッククリーンアウト影響有無確認（対象表をdirect path readで全表走査）2回目
お！！！　REDOが生成されていないですね。Scattered Readの場合でも、コミット時でも一度クリーンアウトされたブロックはクリーンアウト済みなので、クリーンアウトされるような挙動は発生しませんでしたが、 direct path read　でもおなじかなーー。

と。。。。とりあえず、システム統計とセッション統計も確認しておきましょう！

SCOTT@orcl> @table_full_scan_with_dpr.sql 1* alter session set "_serial_direct_read" = always Session altered. Elapsed: 00:00:00.00 1* alter session set "_very_large_object_threshold" = 512 Session altered. Elapsed: 00:00:00.00 set autot trace exp stat 1* select * from hoge 200000 rows selected. Elapsed: 00:00:03.90 Execution Plan ---------------------------------------------------------- Plan hash value: 2339479017 -------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | -------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 214K| 207M| 18223 (1)| 00:00:01 | | 1 | TABLE ACCESS FULL| HOGE | 214K| 207M| 18223 (1)| 00:00:01 | -------------------------------------------------------------------------- Note ----- - dynamic statistics used: dynamic sampling (level=2) Statistics ---------------------------------------------------------- 33 recursive calls 0 db block gets 91159 consistent gets 66938 physical reads 0 redo size 4539159 bytes sent via SQL*Net to client 147264 bytes received via SQL*Net from client 13335 SQL*Net roundtrips to/from client 5 sorts (memory) 0 sorts (disk) 200000 rows processed set autot off

14) CDBのSYSで統計取得（遅延ブロッククリーンアウト有無確認）（対象表をdirect path readで全表走査）2回目
セッション統計のphysical readsとhysical reads direct は同一であることから direct path readになっていることは間違いありません。また、ブロック数も 66667 ブロック以上にはなっているので全ブロック読み込まれているようですね。
ただ、妙な値を示している統計があります。

immediate (CR) block cleanout applications 　10959　

遅延ブロッククリーンアウトが行われている時に上がる統計です。しかも、コミットクリーンアウトされたブロック数を差し引いたブロック数にほぼ一致します。（1回目の実行ではこの3倍ぐらいに跳ね上がっていましたが。。一度クリーンアウトされたのでは？？）

さらに不思議なことに、REDO生成されないんですね。。。。

ん？　ちょっと待ってください。一度、クリーンアウトされたブロックがなぜ、再度クリーンアウトされているのでしょう？　scattered readで遅延ブロッククリーンアウトされたケースと動きが違います！！！！！！

Oracleを再起動する前のステップでREDOログが異常に少ないにも関わらず、遅延クリーンアウトされていた統計値が高くなった。Oracleを再起動した後でも、同様に、direct path read で読み込み、遅延ブロッククリーンアウト発生。しかもREDOログはありません。。。これって、クリーンアウト行われているようですが、実際にはメモリー上だけで実祭のブロックはクリーンアウトされずに残っているということですよね。なんども発生しているわけですから。
（ブロックダンプしなくても統計値から状況は見えてきましたよね！！）

direct path readはその名の通り、バッファキャッシュを介さず、常にストレージからデータブロックを読み込み、PGAへ。このケースだとSELECT文なので単純にPGAへ直接読み込み、メモリ上ではクリーンアップは行なっているようですが、クエリーが終了すれば、単に捨てられるのみ。。。なので、クリーンアウトの結果は永続化されない。。。ということになりますよね！

ということは、SELECT文の場合は、scattered read等でバッファキャッシュを経由させないと、遅延ブロッククリーンアウトは、ずーっと先延ばしされる。。。direct path readのSELECT文を2回実行してクリーンアウトさせたわけだが、この後、scattered readで全表走査させれば、遅延ブロッククリーンアウトが発生して、大量のREDOログが生成されるて、完全にクリーンアウトされる。。。。。。はず。。。ですよね。

試してみよう！！！！

統計値が変動したもののみ記載
(CDB）システム統計

SOURCE NAME　　　　　　　　　　　　　　　　　　　　　　　 VALUE ------- ---------------------------------------------------- --------------- sysstat DBWR checkpoints 1 sysstat DBWR object drop buffers written 2 sysstat cleanouts only - consistent read gets 10959 sysstat commit cleanouts 36 sysstat commit cleanouts successfully completed 36 sysstat consistent gets 106766 sysstat db block changes 166 sysstat deferred (CURRENT) block cleanout applications 18 sysstat free buffer requested 1130 sysstat immediate (CR) block cleanout applications 10959 sysstat immediate (CURRENT) block cleanout applications 10 sysstat no work - consistent read gets 77392 sysstat physical reads 67827 sysstat physical reads direct 66710 sysstat physical writes 2 sysstat physical writes from cache 2 sysstat physical writes non checkpoint 2

(PDB)　SCOTTのセッション統計

SOURCE NAME　　　　　　　　　　　　　　　　　　　　　　　 VALUE ------- ---------------------------------------------------- --------------- sesstat cleanouts only - consistent read gets 10959 sesstat commit cleanouts 2 sesstat commit cleanouts successfully completed 2 sesstat consistent gets 98223 sesstat db block changes 30 sesstat deferred (CURRENT) block cleanout applications 1 sesstat free buffer requested 587 sesstat immediate (CR) block cleanout applications 10959 sesstat no work - consistent read gets 72324 sesstat physical reads 67289 sesstat physical reads direct 66710

15) Oracle再起動
諸々情報を綺麗にするので再起動！！

$ sudo service oracle restart

16) PDBのscottでログインしてclient_infoをセット
v$sessionのclient_info列の'TargetSession'文字列で他のSCOTTユーザーのセッションを特定するため。

SCOTT@orcl> @set_client_info 1 begin 2 DBMS_APPLICATION_INFO.SET_CLIENT_INFO('TargetSession'); 3* end; PL/SQL procedure successfully completed. Elapsed: 00:00:00.00 SCOTT@orcl>

17) CDBのSYSで統計取得（再々起動後初回）
内容は省略！（ベースラインを取得しているだけなので）

SYS$orclcdb> @show_stat scott ...略...

18) PDBのSCOTTユーザーで、遅延ブロッククリーンアウト影響有無確認（対象表をscattered readで全表走査）3回目

キターーーーーーーーーーーーーーっ！。　予想的中！！。（競馬ならいいのにw）　

大量のREDOログが生成され、物理読み込みも初生しています。direct path readで全表走査させた時とは明らかに違う！！！（以前、見た光景！！w）

SCOTT@orcl> @table_full_scan.sql 1* alter session set "_serial_direct_read" = never Session altered. Elapsed: 00:00:00.00 1* alter session set "_very_large_object_threshold" = 20400 Session altered. Elapsed: 00:00:00.00 set autot trace exp stat 1* select * from hoge 200000 rows selected. Elapsed: 00:00:04.84 Execution Plan ---------------------------------------------------------- Plan hash value: 2339479017 -------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | -------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 214K| 207M| 18223 (1)| 00:00:01 | | 1 | TABLE ACCESS FULL| HOGE | 214K| 207M| 18223 (1)| 00:00:01 | -------------------------------------------------------------------------- Note ----- - dynamic statistics used: dynamic sampling (level=2) Statistics ---------------------------------------------------------- 33 recursive calls 0 db block gets 91170 consistent gets 66720 physical reads 964436 redo size 4539159 bytes sent via SQL*Net to client 147264 bytes received via SQL*Net from client 13335 SQL*Net roundtrips to/from client 5 sorts (memory) 0 sorts (disk) 200000 rows processed set autot off

19) CDBのSYSで統計取得（遅延ブロッククリーンアウト有無確認）（対象表をscattered readで全表走査）3回目

physical reads が想定ブロック数以上あるため、物理読み込みされ全ブロックが読み込まれていると読み取れます。また、physical reads direct は変化していません。（変化のない統計は記載していません）
つまり direct path read ではなく scattered read で全表走査が行われたことを示しています。

immediate (CR) block cleanout applications 10959

という統計から、遅延ブロッククリーンアウトが発生し、ほぼ想定していたブロック数であることも確認できます。

統計値が変動したもののみ記載
(CDB）システム統計

SOURCE NAME　　　　　　　　　　　　　　　　　　　　　　　 VALUE ------- ---------------------------------------------------- --------------- sysstat cleanouts only - consistent read gets 10959 sysstat commit cleanouts 3 sysstat commit cleanouts successfully completed 3 sysstat consistent gets 98846 sysstat db block changes 10992 sysstat deferred (CURRENT) block cleanout applications 2 sysstat free buffer requested 67078 sysstat immediate (CR) block cleanout applications 10959 sysstat no work - consistent read gets 72660 sysstat physical reads 67069

(PDB)　SCOTTのセッション統計

SOURCE NAME　　　　　　　　　　　　　　　　　　　　　　　 VALUE ------- ---------------------------------------------------- --------------- sesstat cleanouts only - consistent read gets 10959 sesstat commit cleanouts 2 sesstat commit cleanouts successfully completed 2 sesstat consistent gets 98234 sesstat db block changes 10988 sesstat deferred (CURRENT) block cleanout applications 1 sesstat free buffer requested 67071 sesstat immediate (CR) block cleanout applications 10959 sesstat no work - consistent read gets 72324 sesstat physical reads 67063

20) Oracle再起動
以前の検証で、scattered readでブロッククリーンアウトされた場合のSELECT文であっても結果は永続化されるので、再度読み込ませた場合はクリーンアウト済みなので再度遅延クリーンアウトが発生しないことは確認確認済みですが、今一度確認しておきましょうw

$ sudo service oracle restart

21) PDBのscottでログインしてclient_infoをセット
v$sessionのclient_info列の'TargetSession'文字列で他のSCOTTユーザーのセッションを特定するため。

SCOTT@orcl> @set_client_info 1 begin 2 DBMS_APPLICATION_INFO.SET_CLIENT_INFO('TargetSession'); 3* end; PL/SQL procedure successfully completed. Elapsed: 00:00:00.00 SCOTT@orcl>

22) CDBのSYSで統計取得（再再々起動後初回）
内容は省略！（ベースラインを取得しているだけなので）

SYS$orclcdb> @show_stat scott ...略...

23) PDBのSCOTTユーザーで、遅延ブロッククリーンアウト影響有無確認（対象表をscattered readで全表走査）4回目

想定通り、遅延ブロッククリーンアウトは発生せず、REDOログも生成されていません！　めでたしめでたしw

SCOTT@orcl> @table_full_scan.sql 1* alter session set "_serial_direct_read" = never Session altered. Elapsed: 00:00:00.01 1* alter session set "_very_large_object_threshold" = 20400 Session altered. Elapsed: 00:00:00.00 set autot trace exp stat 1* select * from hoge 200000 rows selected. Elapsed: 00:00:04.32 Execution Plan ---------------------------------------------------------- Plan hash value: 2339479017 -------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | -------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 214K| 207M| 18223 (1)| 00:00:01 | | 1 | TABLE ACCESS FULL| HOGE | 214K| 207M| 18223 (1)| 00:00:01 | -------------------------------------------------------------------------- Note ----- - dynamic statistics used: dynamic sampling (level=2) Statistics ---------------------------------------------------------- 33 recursive calls 0 db block gets 80211 consistent gets 66719 physical reads 0 redo size 4539159 bytes sent via SQL*Net to clientyoutub 147264 bytes received via SQL*Net from client 13335 SQL*Net roundtrips to/from client 5 sorts (memory) 0 sorts (disk) 200000 rows processed set autot off

24) CDBのSYSで統計取得（遅延ブロッククリーンアウト有無確認）（対象表をscattered readで全表走査）4回目
physical reads はありますが、 physical reads direct は変化していません。これは scattered read で全データを読み込んだと見て良いでしょうね。読み込んだブロックサイズも該当表の想定データブロック数程度です。
また、遅延ブロッククリーンアウトが発生したことを示す統計は変化していないことから、遅延ブロッククリーンアウトは発生していないことも読み取れます。(^^)

統計値が変動したもののみ記載
(CDB）システム統計

SOURCE NAME　　　　　　　　　　　　　　　　　　　　　　　 VALUE ------- ---------------------------------------------------- --------------- sysstat commit cleanouts 3 sysstat commit cleanouts successfully completed 3 sysstat consistent gets 87659 sysstat db block changes 34 sysstat deferred (CURRENT) block cleanout applications 2 sysstat free buffer requested 67058 sysstat no work - consistent read gets 83510 sysstat physical reads 67048

(PDB)　SCOTTのセッション統計

SOURCE NAME　　　　　　　　　　　　　　　　　　　　　　　 VALUE ------- ---------------------------------------------------- --------------- sesstat commit cleanouts 2 sesstat commit cleanouts successfully completed 2 sesstat consistent gets 87049 sesstat db block changes 30 sesstat deferred (CURRENT) block cleanout applications 1 sesstat free buffer requested 67051 sesstat no work - consistent read gets 83175 sesstat physical reads 67042

まとめ

SELECT文であっても、遅延ブロッククリーンアウトが発生すると該当ブロックは更新され、REDOログが生成される。ただし、direct path read で読み込まれた場合を除く。
ということのようですね。

ふむふむという興味深い動きですよね。これ。:)

では、次回は direct path に関わる別の動きも確認してみましょうか。。。
このシリーズ、まだまだ引っ張れそうw

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

台風の影響を心配したけどなんとか良い天気の遅い夏休みで。暑くも寒くもないく散歩の気持ちいい秋空 :)

・古くて新しい？遅延ブロッククリーンアウト (deferred block cleanout) #1
・古くて新しい？遅延ブロッククリーンアウト (deferred block cleanout) #2
・古くて新しい？遅延ブロッククリーンアウト (deferred block cleanout) #3
・古くて新しい？遅延ブロッククリーンアウト (deferred block cleanout) #4
・古くて新しい？遅延ブロッククリーンアウト (deferred block cleanout) #5
・古くて新しい？遅延ブロッククリーンアウト (deferred block cleanout) #6
・古くて新しい？遅延ブロッククリーンアウト (deferred block cleanout) #7
・古くて新しい？遅延ブロッククリーンアウト (deferred block cleanout) #8

投稿日時 2021年9月21日 (火) 06時00分 Oracle, PL/SQL, チューニング, FAQ, SQL, パフォーマンス, Oracle Database 19c | 固定リンク | 0 | コメント (0)

2021年9月14日 (火)

古くて新しい？遅延ブロッククリーンアウト (deferred block cleanout) #8

Previously on Mac De Oracle
前回からのつづき（ちょいと寄り道中）
です。

では、とっとと試してみましょうw

バッファキャッシュから溢れ出る程度のデータ量だったら、どうなるのかなーーーー、という検証です。やりたいことは図の通りです。

検証方法を考えていたのですが、自動共有メモリー管理になっているのと、sga_max_size/sga_targetを小さくしすぎるとOracle Databaseが起動しないなど諸々引きそうなので、shared_pool_sizeを大きく設定して、バッファキャッシュに回せるメモリーを減らすことで、バッファキャッシュを小さく、バッファから溢れる程度のデータ量も少なくて済むようにして試してみることにします。

準備段階から書いてます。再現させる環境をどうセットアップしたかっていうことも重要だと思うのですよね。少々長くなっちゃいますが。

検証準備

CDBに接続して初期化パラメータを調整！！

SGAコンポーネントの状況
Database Buffersが、3G以上になってます。検証データ量も多くなってしまうので、これを1GB程度まで下げたいですね。検証時間も節約できますし、最小の手数で検証できるほうが良いですから:)

SYS@orclcdb> show sga Total System Global Area 4294963960 bytes Fixed Size 9143032 bytes Variable Size 805306368 bytes Database Buffers 3472883712 bytes Redo Buffers 7630848 bytes SYS@orclcdb> select 3472883712 / 1024 / 1024 AS "MB" from dual; MB ---------- 3312 Elapsed: 00:00:00.00

sga_max_size,sga_min_sizeが4GBですが、ここはそのままにします。あまり小さくしすぎると起動しなくなったり。(^^;;;;

SYS@orclcdb> show parameter sga NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ allow_group_access_to_sga boolean FALSE lock_sga boolean FALSE pre_page_sga boolean TRUE sga_max_size big integer 4G sga_min_size big integer 0 sga_target big integer 4G unified_audit_sga_queue_size integer 1048576

自動SGA管理なので、Shared Pool Sizeに大きめの値を設定。
自動SGA管理下で自動管理対象メモリーコンポーネントパラメータに値を設定した場合、その値が下限値となり最低でもその値は確保されるという仕組みを利用します！

SYS@orclcdb> show parameter shared_pool NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ shared_pool_reserved_size big integer 39426457 shared_pool_size big integer 0

起動しなくなっても戻しやすいようにspfileをpfileに書き出して退避後に、shared_pool_sizeを3GBへ増やします。これで4Gのうちの3G程度がshared poolに割り当てられ、バッファキャッシュは1GBぐらいになるはず。（VirtualBoxなのでスナップショット取得しておいて戻すのもありですけどw）

SYS@orclcdb> create pfile='pfile20210912.ora' from spfile; File created. Elapsed: 00:00:00.00 SYS@orclcdb> alter system set shared_pool_size = 3g scope=both; System altered. Elapsed: 00:00:00.77

Database Buffersがいい感じにシュリンクしました。1GBぐらいになりました。これで進めますよー。

SYS@orclcdb> show sga Total System Global Area 4294963960 bytes Fixed Size 9143032 bytes Variable Size 3238002688 bytes Database Buffers 1040187392 bytes Redo Buffers 7630848 bytes SYS@orclcdb> select 1040187392 / 1024 / 1024 AS "MB" from dual; MB ---------- 992 Elapsed: 00:00:00.01

ざっくりとブロック数を計算

SYS@orclcdb> select 1040187392 / 8192 AS "blocks"　from dual; blocks --------------- 126976 Elapsed: 00:00:00.01

前回のHOGE表に200,000 rowsで、66,667 blocks のデータを生成したので、126,976 blocks を満たすデータ量にしようとすると 400,000 rowsほど必要になりそうですね。。。。少々多めで、バッファキャッシュから溢れる程度の量で、 500,000 rowsのデータを登録することにしましょう！！！！

SYS@orclcdb> select ceil(126976 / 66667) * 200000 AS "rows" from dual; rows ---------- 400000 Elapsed: 00:00:00.00

これまでの検証から 10%-15%程度がCOMMITクリーンアウトされ、残りが遅延されるのは確認できたので、126976 blocks のバッファキャッシュだと、　17,777 blocks ぐらいがコミットクリーンアウトされそうですね。(今回のテストケースではコミットクリーンアウトされないけど。。された場合は最大でこの程度。。。というメモです。はい)

SYS@orclcdb> select ceil(126976 * 0.14) AS "blocks for commit cleanout" from dual; blocks for commit cleanout -------------------------- 17777 Elapsed: 00:00:00.00

前回作成したデータは、200,000rowsで、66,667 blocksだったので、500,000 rows だと、ざっくり　166,668 blocks ほど。

SCOTT@orcl> select ceil(66667 / 2 * 5) AS "blocks" from dual; blocks ---------- 166668 Elapsed: 00:00:00.00

なので、遅延ブロッククリーンアウトされると想定される（コミットクリーンアウト分を覗くと）ブロック数は、148,891 blocks 程度にはなりそう。

SYS@orclcdb> select ceil((66667 / 2 * 5) - 17777) AS "blocks" from dual; blocks ---------- 148891 Elapsed: 00:00:00.01

それに加えて、バッファキャッシュに収まらず、コミットする前にバッファキャッシュから落とされ、ストレージへかきだされてしまうブロック数は、これまた、ざっくり計算すると　39,692 blocks ほどですかね。バッファキャッシュのサイズから全てのブロックは乗り切らないので、最初に読み込まれていたブロックから落とされていくことにはなりますね。。
とはいえ、この検証ではキャッシュ落とされるブロック数は特に気にしてなくて、バッファキャッシュ以上のブロック数が生成されていればいいので、落とされそうなのが確認できればOK.

SYS@orclcdb> select ceil((66667 / 2 * 5) - 126976) AS "blocks" from dual; blocks ---------- 39692 Elapsed: 00:00:00.00

とりあえず、生成するデータ量（行数）の算出とバッファキャッシュサイズの調整はおわり。

次に、実際にデータを生成してブロック数とセグメントサイズを確認して、実行用スクリプトの調整を行なっておきます。

PDBでテストデータの実サイズの確認

SCOTT@orcl> @droppurge_create_hoge.sql 1* drop table hoge purge Table dropped. Elapsed: 00:00:00.25 1* create table hoge (id number, data varchar2(2000)) Table created. Elapsed: 00:00:00.04 1* select segment_name,blocks from user_segments where segment_name like '%HOGE%' no rows selected Elapsed: 00:00:00.11

500,000行登録！！

SCOTT@orcl> @insert_each_rows_5.sql 1* begin for i in 1..500000 loop insert into hoge values(i, lpad('*', 2000, '*')); end loop; end; PL/SQL procedure successfully completed. Elapsed: 00:02:37.68

データが登録されているブロック数は、166,667 blocks で、事前に計算していた　166,668 blocks にほぼおなじ。（狙い通り）
セグメントサイズは、約 1344 MB ですね。

SCOTT@orcl> select count(distinct dbms_rowid.rowid_block_number(rowid)) as "blocks" from hoge; blocks ---------- 166667 Elapsed: 00:00:05.03 SCOTT@orcl> select segment_name,blocks,bytes/1024/1024 AS "MB" from user_segments where segment_name = 'HOGE'; SEGMENT_NAME BLOCKS MB ------------------------------ ---------- ---------- HOGE 172032 1344 Elapsed: 00:00:00.17

Scattered read でTable Full Scanできるように少々隠しパラメータを調整しておきますね。念の為。（セッションレベルで調整してます）
セグメントサイズが、1344 MBなので、_very_large_object_threshold　は、2048 MBぐらい設定しておけば、Scattered readのまま行けそうですね。

$ cat table_full_scan.sql alter session set "_serial_direct_read" = never . l / alter session set "_very_large_object_threshold" = 2040 . l / !echo set autot trace exp stat set autot trace exp stat select * from hoge . l / !echo set autot off set autot off

準備完了！！！！！

準備長かったけどw　やっと本題です！！！w　実行している内容はいままでと同じなのでかなり端折ってポイントだけ記載。

バッファキャッシュから溢れるほどのデータ量で。コミットクリーンアウトはどうなるのだろうか。。。。想定では、ほぼコミットクリーンアウトできないはずではあるのだが。。。。

CDBのSYSで統計取得（コミット後）

commit cleanouts successfully completedはどれぐらいだったのか。。。。。ありません。commit cleanouts successfully completedに差分がなかったので、コミットクリーンアウトしようして失敗、commit cleanout failures: block lostと同数なので、１ブロックもコミットクリーンアウトできない！　　commit cleanout failures: block lostがバッファキャッシュに対象ブロックがなかったことを示しています。

つまり、バッファキャッシュに乗り切らなため、最初にINSERTされたブロックはそのままストレージへ物理書き込みされて追い出された結果。。ということになりますね。

登録したブロック全てが遅延クリーンアウト対象になってしまった、ということになります。コミット時にクリーンアウトできてないわけだから！！！！！！！！　（イメージ図でざっくり書いたとおりの感じに。。。

差分のあった統計のみ記載

CDB）システム統計

SOURCE NAME VALUE ------- ------------------------------------------------- -------------------- sysstat commit cleanout failures: block lost 3028 sysstat commit cleanouts 3028 sysstat consistent gets 274 sysstat db block changes 1 sysstat no work - consistent read gets 149 sysstat physical reads 60

(PDB)　SCOTTのセッション統計

SOURCE NAME VALUE ------- ------------------------------------------------- -------------------- sesstat commit cleanout failures: block lost 3028 sesstat commit cleanouts 3028 sesstat db block changes 1

次に、Scattered Readが実行される全表走査を行わせ、遅延ブロッククリーンアウトどれだけ発生するか結果確認！

PDBのSCOTTユーザーで、遅延ブロッククリーンアウト影響有無確認（対象表を全表走査）
想定通り、物理読み込み（この時点ではscattered readなのか、direct path readなのかわかりませんが）になっています。また、大量のREDOログが生成されているので遅延ブロッククリーンアウトが発生しています。

SCOTT@orcl> @table_full_scan.sql 1* alter session set "_serial_direct_read" = never Session altered. Elapsed: 00:00:00.00 1* alter session set "_very_large_object_threshold" = 2040 Session altered. Elapsed: 00:00:00.00 set autot trace exp stat 1* select * from hoge 500000 rows selected. Elapsed: 00:01:03.08 Execution Plan ---------------------------------------------------------- Plan hash value: 2339479017 -------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | -------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 669K| 647M| 46462 (1)| 00:00:02 | | 1 | TABLE ACCESS FULL| HOGE | 669K| 647M| 46462 (1)| 00:00:02 | -------------------------------------------------------------------------- Note ----- - dynamic statistics used: dynamic sampling (level=2) Statistics ---------------------------------------------------------- 46 recursive calls 13 db block gets 367852 consistent gets 160269 physical reads 14670268 redo size 1016952118 bytes sent via SQL*Net to client 367706 bytes received via SQL*Net from client 33335 SQL*Net roundtrips to/from client 2 sorts (memory) 0 sorts (disk) 500000 rows processed set autot off

物理読み込みを伴う全表走査でどの程度の遅延ブロッククリーンアウトが発生したか統計を確認！！！！

CDBのSYSで統計取得（遅延ブロッククリーンアウト有無確認）

想定どおり、INSERTした全ブロックが、immediate (CR) block cleanout applications = 166667 で遅延ブロッククリーンアウトされたことがわかります。（冒頭に記載していますが、データが格納されているブロック数は、　166667 blocks　でしたよね）
physical readsは意図通り発生していますが、physical reads directが変化していないので、狙い通りScattered Readになったようですね

差分のあった統計のみ記載

CDB）システム統計

SOURCE NAME VALUE ------- ------------------------------------------------- -------------------- sysstat DBWR checkpoint buffers written 241 sysstat DBWR thread checkpoint buffers written 241 sysstat DBWR undo block writes 1109 sysstat cleanouts only - consistent read gets 166667 sysstat commit cleanouts 55 sysstat commit cleanouts successfully completed 55 sysstat consistent gets 377331 sysstat db block changes 166904 sysstat deferred (CURRENT) block cleanout applications 29 sysstat immediate (CR) block cleanout applications 166667 sysstat immediate (CURRENT) block cleanout applications 15 sysstat no work - consistent read gets 38449 sysstat physical reads 160805 sysstat physical writes 137551 sysstat physical writes from cache 137551 sysstat physical writes non checkpoint 137466

(PDB)　SCOTTのセッション統計

SOURCE NAME VALUE ------- ------------------------------------------------- -------------------- sesstat cleanouts only - consistent read gets 166667 sesstat commit cleanouts 6 sesstat commit cleanouts successfully completed 6 sesstat consistent gets 374538 sesstat db block changes 166710 sesstat deferred (CURRENT) block cleanout applications 3 sesstat immediate (CR) block cleanout applications 166667 sesstat immediate (CURRENT) block cleanout applications 1 sesstat no work - consistent read gets 36779 sesstat physical reads 160513

念の為、今一度、物理読み込みを伴う全表走査を行なって、クリーンアウトされたのか確認してみましょうw（疑い深いw）
もう一度、PDBのSCOTTユーザーで、遅延ブロッククリーンアウト影響有無確認（対象表を全表走査）

redo sizeが 0 なのでクリーンアウトは発生してない。想定通り

SCOTT@orcl> @table_full_scan.sql 1* alter session set "_serial_direct_read" = never Session altered. Elapsed: 00:00:00.00 1* alter session set "_very_large_object_threshold" = 2040 Session altered. Elapsed: 00:00:00.00 set autot trace exp stat 1* select * from hoge 500000 rows selected. Elapsed: 00:00:33.17 Execution Plan ---------------------------------------------------------- Plan hash value: 2339479017 -------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | -------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 669K| 647M| 46462 (1)| 00:00:02 | | 1 | TABLE ACCESS FULL| HOGE | 669K| 647M| 46462 (1)| 00:00:02 | -------------------------------------------------------------------------- Note ----- - dynamic statistics used: dynamic sampling (level=2) Statistics ---------------------------------------------------------- 0 recursive calls 0 db block gets 200399 consistent gets 148198 physical reads 0 redo size 1016952118 bytes sent via SQL*Net to client 367706 bytes received via SQL*Net from client 33335 SQL*Net roundtrips to/from client 0 sorts (memory) 0 sorts (disk) 500000 rows processed set autot off

同様に、統計でも確認してみます！
CDBのSYSで統計取得（遅延ブロッククリーンアウト有無確認）

クリーンアウトを示す統計値は上昇していません！！！（うんうんw）

差分のあった統計のみ記載

CDB）システム統計

SOURCE NAME VALUE ------- ------------------------------------------------- -------------------- sysstat DBWR checkpoint buffers written 732 sysstat commit cleanouts 1 sysstat commit cleanouts successfully completed 1 sysstat consistent gets 200522 sysstat db block changes 13 sysstat deferred (CURRENT) block cleanout applications 1 sysstat no work - consistent read gets 200403 sysstat physical reads 148200 sysstat physical writes 68570 sysstat physical writes from cache 68570 sysstat physical writes non checkpoint 68331

(PDB)　SCOTTのセッション統計

SOURCE NAME VALUE ------- ------------------------------------------------- -------------------- sesstat consistent gets 200414 sesstat db block changes 9 sesstat no work - consistent read gets 200366 sesstat physical reads 148198

OK. Done. ということで、まとめ！

バッファキャッシュには収まりきれないデータ量の場合、コミットクリーンアウトしようとしていたブロックも追い出されてしまうので、結果的に、全ブロックが遅延ブロッククリーンアウトになった。というイメージしていた結果の通りでした。
（今回のケースもシンプルケースなので比較的予想しやすい結果ですが、クリーンアウトに関わる統計は以外に多く、複雑な動きになるものもあります。再現するののめんどくさいのでしませんがw）

寄り道はここまで、次回は、こんどこそ、direct path readと遅延ブロッククリーンアウトの関係をみていきたいと思います。

来週天気いいかなー。遅い夏休みなのに。微妙な気がしてきた。。。。。

・古くて新しい？遅延ブロッククリーンアウト (deferred block cleanout) #1
・古くて新しい？遅延ブロッククリーンアウト (deferred block cleanout) #2
・古くて新しい？遅延ブロッククリーンアウト (deferred block cleanout) #3
・古くて新しい？遅延ブロッククリーンアウト (deferred block cleanout) #4
・古くて新しい？遅延ブロッククリーンアウト (deferred block cleanout) #5
・古くて新しい？遅延ブロッククリーンアウト (deferred block cleanout) #6
・古くて新しい？遅延ブロッククリーンアウト (deferred block cleanout) #7

投稿日時 2021年9月14日 (火) 12時00分 Oracle, PL/SQL, チューニング, FAQ, SQL, パフォーマンス, Oracle Database 19c | 固定リンク | 0 | コメント (0)

2021年9月12日 (日)

古くて新しい？遅延ブロッククリーンアウト (deferred block cleanout) #7

Previously on Mac De Oracle
前回は、コミットクリーンアウトと遅延クリーンアウト、そして、そこにTable Full ScanでScattered Read （待機イベントだと db file scattered read) を絡めてストレージへ永続化されたクリーンアウトが遅延されてしまったブロックを物理読み込みませつつ遅延ブロッククリーンアウトを再現させてみました。
また、次回は、図中のscattered read 部分を direct path read にしつつ、最後の最後で、scattered read　にしてみる、とか、そんなイメージをぼやーーーーんと浮かべながら、発生させる方法をどうするか考えてますw。つづく。なんてことを言っていましたが、またまた、ちょいと寄り道ですしますw

バッファキャッシュから溢れるぐらいのデータをぐるぐる系INSERTで、しかも1回のコミットにしたら、コミット前にあふれたデータはストレージへ書き出され、かつ、クリーンアウトも遅延されるよなー。という予想を元に、ちょいと遊んでから次に進みたいw　と思います。

これまでの流れから、基本的なクリーンアウトおよび遅延ブロッククリーンアウトとしては以下ようなパターンを確認してきました。

バッファキャッシュの上でコミットクリーンアウトおよび、遅延ブロッククリーンアウト（単純なタイプ）が行われているケース

ここからが想像というか、私が理解している範囲から想像した動き。バッファキャッシュから溢れはしないけど、いっぱいいっぱいな場合は、クリーンアウトされるブロックがキャッシュ上に多くあるだろうな。と.
とは言っても、バッファキャッシュ上ではあるわけです。

そこで、ちょいと意地悪をして、バッファキャッシュから溢れ出る程度のデータ量だったどうなるのかなーーーーと。冒頭ですでコメントしているわけですけどもw　多分、以下のような動きだよねー、と。
そういえば、以前、DBTSで行なったセッションの「バッファキャッシュ欠乏症」の部分で、似たようなバッファキャッシュから溢れ出したブロックの挙動をなんとかするみたいな資料も今回の動きを想像するにはよいかもしれないですね。

と、思い、頭の中のイメージを Pagesでざざっと作ったところで、本日はここまで。次回へつづく。

Beat SaberとWalkingの合わせ技で、効果的な減量継続中w

・古くて新しい？遅延ブロッククリーンアウト (deferred block cleanout) #1
・古くて新しい？遅延ブロッククリーンアウト (deferred block cleanout) #2
・古くて新しい？遅延ブロッククリーンアウト (deferred block cleanout) #3
・古くて新しい？遅延ブロッククリーンアウト (deferred block cleanout) #4
・古くて新しい？遅延ブロッククリーンアウト (deferred block cleanout) #5
・古くて新しい？遅延ブロッククリーンアウト (deferred block cleanout) #6

投稿日時 2021年9月12日 (日) 00時00分 Oracle, PL/SQL, チューニング, FAQ, SQL, パフォーマンス, Oracle Database 19c | 固定リンク | 0 | コメント (0)

2021年9月10日 (金)

古くて新しい？遅延ブロッククリーンアウト (deferred block cleanout) #6

Previously on Mac De Oracle
前々回と前回はバッファキャッシュの10%を超えるデータ量のINSERT文の実行とCOMMITの実行で、バッファキャッシュの10%-15%程度は、COMMIT時にクリーンアウトされ、残ったブロックのクリーンアウトは先送りされる。という検証を2つのパターンで確認してみました。

どのような流れで発生するかを各ステップ毎にシステム統計（CDB）とクエリーを実行するセッションのセッション統計（PDB)を取得し、どのように統計値が変化すれば、コミットクリーンアウトや遅延ブロッククリーンアウトが起きているのかを見ながらすすめました。以下２つのエントリーで確認した動きの違いはイメージできたのか少々不安ではありますがw　（そこそこ長いエントリーなのでw）

こちら前々回は、クリーンアウトが遅延されたブロックが永続化される前に、遅延ブロッククリーンアウトさせてみたケース
古くて新しい？遅延ブロッククリーンアウト (deferred block cleanout) #4
で、

前回は、クリーンアウトが遅延されたブロックが永続化された後に、遅延ブロッククリーンアウトさせてみたケース
古くて新しい？遅延ブロッククリーンアウト (deferred block cleanout) #5

なんです　：）　

まだ、イメージつかめない方もいるかもしれないので

超ざっくりした絵が頭の中に浮かばない方向けに、上記検証を行う前に、私の頭の中にうかんだ、ラフイメージをほぼそのまま

（こまけーとこは気にしないでくださいね。ラフイメージですから、こうだろうなーというのを想像している状態そのままのイメージですのでw）

クリーンアウトが遅延されたブロックが永続化される前に、遅延ブロッククリーンアウトさせてみたケース
古くて新しい？遅延ブロッククリーンアウト (deferred block cleanout) #4

クリーンアウトが遅延されたブロックが永続化された後に、遅延ブロッククリーンアウトさせてみたケース
古くて新しい？遅延ブロッククリーンアウト (deferred block cleanout) #5

再現させてるケースはシンプルなものなので処理時間云々を比較してはいないですが、複雑なケースになると、本来スマートスキャンさせたいのにシングルブロックリードが多くなったりするケースなど、以前紹介したURLを見ていただければ参考になるかもしれないですね。
クエリーやDMLの処理時間が伸びてビビるぐらいに仕事量が増えてたり、先送りされたことで、もろもろ後処理が複雑化する場合もあるわけで）

ということで、こんな図をイメージしながら、ネタ作ってます。はいw

次回は、図中のscattered read 部分を direct path read にしつつ、最後の最後で、scattered read　にしてみる、とか、そんなイメージをぼやーーーーんと浮かべながら、発生させる方法をどうするか考えてますw。つづく。

・古くて新しい？遅延ブロッククリーンアウト (deferred block cleanout) #1
・古くて新しい？遅延ブロッククリーンアウト (deferred block cleanout) #2
・古くて新しい？遅延ブロッククリーンアウト (deferred block cleanout) #3
・古くて新しい？遅延ブロッククリーンアウト (deferred block cleanout) #4
・古くて新しい？遅延ブロッククリーンアウト (deferred block cleanout) #5

投稿日時 2021年9月10日 (金) 12時00分 Oracle, PL/SQL, チューニング, FAQ, SQL, パフォーマンス, Oracle Database 19c | 固定リンク | 0 | コメント (0)

2021年9月 9日 (木)

古くて新しい？遅延ブロッククリーンアウト (deferred block cleanout) #5

前回はバッファキャッシュの10%を超えるデータブロックへのINSERT文の実行とCOMMITの実行で、バッファキャッシュの13%-15%程度はCOMMIT時にクリーンアウトされ、残りは遅延ブロッククリーンアウト（先送り）される。
direct path readではないSELECT文による(前回のケースでは scattered read）)遅延ブロッククリーンアウトは、１度のみ発生するという状況を確認しました。

ところで、
前回のエントリで、2度、全表走査（前回の検証ではscattered read）を実行しているのですが、物理読み込みは発生させていません。（INSERT→COMMIT→SELECT→SELECTという流れで、十分なバッファキャッシュがあるので、当然ではあるのですがw）
バッファキャッシュに乗ったままのブロックが遅延クリーンアウトされていたわけです。

前回のエントリ：古くて新しい？遅延ブロッククリーンアウト (deferred block cleanout) #4

-------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | -------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 194K| 188M| 18189 (1)| 00:00:01 | | 1 | TABLE ACCESS FULL| HOGE | 194K| 188M| 18189 (1)| 00:00:01 | --------------------------------------------------------------------------

1. 遅延ブロッククリーンアウトを発生させた場合。遅延ブロッククリーンアウト対象のデータがバッファキャッシュ上ににあるためクリーンアウトに伴う物理読み込みはない。

Statistics ---------------------------------------------------------- 46 recursive calls 13 db block gets 91636 consistent gets 7 physical reads 967348 redo size 406775148 bytes sent via SQL*Net to client 147264 bytes received via SQL*Net from client 13335 SQL*Net roundtrips to/from client 2 sorts (memory) 0 sorts (disk) 200000 rows processed

2. 直後に再度全表走査した場合も、キャッシュヒットしているので、物理読み込みはない

Statistics ---------------------------------------------------------- 0 recursive calls 0 db block gets 80061 consistent gets 0 physical reads 0 redo size 406775148 bytes sent via SQL*Net to client 147264 bytes received via SQL*Net from client 13335 SQL*Net roundtrips to/from client 0 sorts (memory) 0 sorts (disk) 200000 rows processed

前述の1.2.それぞれの実行で物理読み込みだったなにか変化はあるのだろうか。。。予想では、上記に加えてscattered readに伴う物理読み込みが増えるだけのはずです。その動きを見てみることにします。（こういう動きを見ていると楽しいですよねw）
手順は前回と同じですが、各全表走査の前にインスタンスを再起動してバッファキャッシュを空にしておきます。
(buffer cacheをflushすればいいじゃん。という声も聞こえてきそうですが、今回は再起動でクリアしました。はいw)

前回から多少変更したスクリプトも載せておきます（本文中にもありますが）、細かい解説は後述

$ cat table_full_scan.sql alter session set "_serial_direct_read" = never . l / alter session set "_very_large_object_threshold" = 1056 . l / !echo set autot trace exp stat set autot trace exp stat select * from hoge . l / !echo set autot off set autot off

0) 対象表をdrop/create
オブジェクト作り直し

SCOTT@orcl> @droppurge_create_hoge Table dropped. Table created. SCOTT@orcl> select segment_name,blocks from user_segments where segment_name like '%HOGE%'; no rows selected

1) 統計をクリアするのにインスタンス再起動

$ sudo service oracle restart

2) PDBのscottでログインし、client_infoをセット
v$sessionのclient_info列の'TargetSession'文字列で他のSCOTTユーザーのセッションと区別するため

SCOTT@orcl> @set_client_info 1 begin 2 DBMS_APPLICATION_INFO.SET_CLIENT_INFO('TargetSession'); 3* end; PL/SQL procedure successfully completed. Elapsed: 00:00:00.00 SCOTT@orcl>

3) CDBのSYSで統計取得（初回）

内容は省略！（統計差分取得のためのベースラインを取得しているだけ）

SYS$orclcdb> @show_stat scott

4) PDBのSCOTTユーザーでデータINSERT（データ量2倍、コミットなし）

SCOTT@orcl> @insert_each_rows_2 1* begin for i in 1..200000 loop insert into hoge values(i, lpad('*', 2000, '*')); end loop; end; PL/SQL procedure successfully completed. Elapsed: 00:00:29.48 SCOTT@orcl>

5) CDBのSYSで統計取得（INSERT後、未コミット）

未コミットの状態なので特に、気にせず、ふーーーん。ぐらいの感じで眺めていただければいいですね。前回同様に、commit cleanouts, commit cleanouts successfully completed, deferred (CURRENT) block cleanout applications, immediate (CURRENT) block cleanout applicationsといったクリーンアウト関連統計が極わずかありますが、この時点で発生しているのは本題ではないので気にしなくてOK

差分のある統計のみ記載

(CDB）システム統計

SOURCE NAME VALUE ------- ------------------------------------------------- -------------------- sysstat DBWR checkpoint buffers written 23589 sysstat DBWR checkpoints 2 sysstat DBWR thread checkpoint buffers written 22643 sysstat DBWR transaction table writes 50 sysstat DBWR undo block writes 848 sysstat cleanouts and rollbacks - consistent read gets 5 sysstat commit cleanout failures: callback failure 20 sysstat commit cleanouts 1320 sysstat commit cleanouts successfully completed 1300 sysstat consistent gets 124041 sysstat db block changes 757165 sysstat deferred (CURRENT) block cleanout applications 715 sysstat immediate (CR) block cleanout applications 5 sysstat immediate (CURRENT) block cleanout applications 196 sysstat no work - consistent read gets 46398 sysstat physical reads 4063 sysstat physical writes 23589 sysstat physical writes from cache 23589 sysstat physical writes non checkpoint 23494

(PDB)　SCOTTのセッション統計

SOURCE NAME VALUE ------- ------------------------------------------------- -------------------- sesstat commit cleanouts 6 sesstat commit cleanouts successfully completed 6 sesstat consistent gets 49596 sesstat db block changes 744727 sesstat deferred (CURRENT) block cleanout applications 4 sesstat immediate (CURRENT) block cleanout applications 1 sesstat no work - consistent read gets 49 sesstat physical reads 15

6) PDBのSCOTTユーザーでコミットの実行

SCOTT@orcl> commit; Commit complete.

7) CDBのSYSで統計取得（コミット後）
前回同様ノイズもなく、綺麗にコミット時のクリーンアウトが発生しています。バッファキャッシュの約14-5%程度なのは前回と変わらずですね。

差分のある統計のみ記載

(CDB）システム統計

SOURCE NAME VALUE ------- ------------------------------------------------- -------------------- sysstat commit cleanouts 55700 sysstat commit cleanouts successfully completed 55700 sysstat db block changes 1

(PDB)　SCOTTのセッション統計

SOURCE NAME VALUE ------- ------------------------------------------------- -------------------- sesstat commit cleanouts 55700 sesstat commit cleanouts successfully completed 55700 sesstat db block changes 1

8) Oracle Databaseを再起動してバッファキャッシュをクリア

ここが前回と違う手順で、クリーンアウトされないブロックはずーーーーーっと残るよね。ということの確認でもあります。（alter system flush buffer_cacheでも同じことができるわけですが、ここでは再起動しています）

$ sudo service oracle restart [sudo] password for oracle: Restarting oracle (via systemctl): [ OK ] $

9) PDBのscottでログインし、client_infoをセット

disconnectしたので再度、client infoをセットし直し！

SCOTT@orcl> @set_client_info 1 begin 2 DBMS_APPLICATION_INFO.SET_CLIENT_INFO('TargetSession'); 3* end; PL/SQL procedure successfully completed. Elapsed: 00:00:00.00 SCOTT@orcl>

10) CDBのSYSで統計取得（再起動後初回）

内容は省略！（再起動したので統計値の差分取得用ベースライン統計の取得）

SYS$orclcdb> @show_stat scott

11) PDBのSCOTTユーザーで、遅延ブロッククリーンアウト影響有無確認（対象表を全表走査）- scattered read / table full scan の1回目

ここでは待機イベントまでは確認できませんが、Table full scanと実行統計よりRedoログがたっぷり生成されていることは確認できます。SELECT文ですが。。。つまり、遅延ブロッククリーンアウトが発生しているということですね。確認は後述の統計で。
狙い通り、物理読み込みも発生しています！

Note)
"_very_large_object_threshold" = 1056　としているのは、direct path readとなる上限セグメントサイズをhoge表が超えているためdirect path readを抑止するためにこの隠しパラメータで上限値を引き上げ、scattered readになるように強制しています。

SCOTT@orcl> @table_full_scan.sql 1* alter session set "_serial_direct_read" = never Session altered. Elapsed: 00:00:00.01 1* alter session set "_very_large_object_threshold" = 1056 Session altered. Elapsed: 00:00:00.00 set autot trace exp stat 1* select * from hoge 200000 rows selected. Elapsed: 00:00:06.10 Execution Plan ---------------------------------------------------------- Plan hash value: 2339479017 -------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | -------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 214K| 207M| 18223 (1)| 00:00:01 | | 1 | TABLE ACCESS FULL| HOGE | 214K| 207M| 18223 (1)| 00:00:01 | -------------------------------------------------------------------------- Note ----- - dynamic statistics used: dynamic sampling (level=2) Statistics ---------------------------------------------------------- 38 recursive calls 13 db block gets 91519 consistent gets 67073 physical reads 967432 redo size 406775148 bytes sent via SQL*Net to client 147264 bytes received via SQL*Net from client 13335 SQL*Net roundtrips to/from client 5 sorts (memory) 0 sorts (disk) 200000 rows processed set autot off SCOTT@orcl>

12) CDBのSYSで統計取得（遅延ブロッククリーンアウト有無確認）/ scattered read / table full scan の１回目

遅延ブロッククリーンアウト関連統計値が上昇しているので、遅延ブロッククリーンアウトの発生が確認できます。ここまでは前回と同じ。（同じじゃないと困りますがw）

違う点は、事前にインスタンスを再起動しているため、physical reads が上昇しています。これは hoge表を scattered readで全表走査しているからです。（phsical read directは発生していない）バッファキャッシュを経由するのでconsistent gets,no work - consistent read gets も上昇しています。狙い通りです。

そして、重量な遅延ブロッククリーンアウトですが、バッファキャッシュでヒットしていた時と同数のブロックで発生しています。（ニッコリ

インスタンスの停止や起動があったとしても、クリーンアウトが先送りされたブロックはアクセスされない限りクリーンアウトされず残っているということを示しています！！！！（ここ試験にでますよー。嘘）

(CDB）システム統計

SOURCE NAME VALUE ------- ------------------------------------------------- -------------------- sysstat cleanouts only - consistent read gets 10967 sysstat commit cleanouts 7 sysstat commit cleanouts successfully completed 7 sysstat consistent gets 98967 sysstat db block changes 11016 sysstat deferred (CURRENT) block cleanout applications 3 sysstat immediate (CR) block cleanout applications 10967 sysstat immediate (CURRENT) block cleanout applications 2 sysstat no work - consistent read gets 72543 sysstat physical reads 67403

(PDB)　SCOTTのセッション統計

SOURCE NAME VALUE ------- ------------------------------------------------- -------------------- sesstat cleanouts only - consistent read gets 10967 sesstat commit cleanouts 6 sesstat commit cleanouts successfully completed 6 sesstat consistent gets 98357 sesstat db block changes 11012 sesstat deferred (CURRENT) block cleanout applications 2 sesstat immediate (CR) block cleanout applications 10967 sesstat immediate (CURRENT) block cleanout applications 2 sesstat no work - consistent read gets 72208 sesstat physical reads 67397

13) Oracle Databaseを再起動してバッファキャッシュをクリア

再度、インスタンスを再起動して、バッファキャッシュをクリアします。後続の全表走査では、遅延ブロッククリーンアウトは発生せず、物理読み込み(この検証では scattered readさせています)を伴うTable full scanが行われるだけのはずです。

$ sudo service oracle restart [sudo] password for oracle: Restarting oracle (via systemctl): [ OK ] $

14) PDBのscottでログインし、client_infoをセット

disconnectしたので再度、client infoをセットし直し！

SCOTT@orcl> @set_client_info 1 begin 2 DBMS_APPLICATION_INFO.SET_CLIENT_INFO('TargetSession'); 3* end; PL/SQL procedure successfully completed. Elapsed: 00:00:00.00 SCOTT@orcl>

15) CDBのSYSで統計取得（再起動後初回）

内容は省略！（再起動したのでベースラインとなる統計を取得）

SYS$orclcdb> @show_stat scott

16) PDBのSCOTTユーザーで、遅延ブロッククリーンアウト影響有無確認（対象表を全表走査）- scattered read / table full scan の2回目

実行統計から、physical readsが、発生しています。Redoは生成されていないことも読み取れるので、遅延ブロッククリーンアウトは発生していないことも確認できます。：）　想定通りですね。

SCOTT@orcl> @table_full_scan.sql 1* alter session set "_serial_direct_read" = never Session altered. Elapsed: 00:00:00.00 1* alter session set "_very_large_object_threshold" = 1056 Session altered. Elapsed: 00:00:00.00 set autot trace exp stat 1* select * from hoge 200000 rows selected. Elapsed: 00:00:06.44 Execution Plan ---------------------------------------------------------- Plan hash value: 2339479017 -------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | -------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 214K| 207M| 18223 (1)| 00:00:01 | | 1 | TABLE ACCESS FULL| HOGE | 214K| 207M| 18223 (1)| 00:00:01 | -------------------------------------------------------------------------- Note ----- - dynamic statistics used: dynamic sampling (level=2) Statistics ---------------------------------------------------------- 30 recursive calls 0 db block gets 80211 consistent gets 66719 physical reads 0 redo size 406775148 bytes sent via SQL*Net to client 147264 bytes received via SQL*Net from client 13335 SQL*Net roundtrips to/from client 5 sorts (memory) 0 sorts (disk) 200000 rows processed set autot off SCOTT@orcl>

17) CDBのSYSで統計取得（遅延ブロッククリーンアウト有無確認）/ scattered read / table full scan の2回目

physical reads は発生していますが、physical reads directではないことが確認できます。Table full scanをscattered readで読み込んでいるという想定通りの結果。　
遅延ブロッククリーンアウトを示deferred (CURRENT) block cleanout applications 、immediate (CURRENT) block cleanout applicationsや、コミットクリーンアウトを示すcommit cleanouts 、commit cleanouts successfully completed という統計が極わずかに変動していますが、今回の検証ではノイズなので気にしたくてOK。

(CDB）システム統計

SOURCE NAME VALUE ------- ------------------------------------------------- -------------------- sysstat DBWR checkpoint buffers written 11 sysstat commit cleanouts 15 sysstat commit cleanouts successfully completed 15 sysstat consistent gets 87375 sysstat db block changes 79 sysstat deferred (CURRENT) block cleanout applications 12 sysstat immediate (CURRENT) block cleanout applications 3 sysstat no work - consistent read gets 83322 sysstat physical reads 67028 sysstat physical writes 11 sysstat physical writes from cache 11 sysstat physical writes non checkpoint 11

(PDB)　SCOTTのセッション統計

SOURCE NAME VALUE ------- ------------------------------------------------- -------------------- sesstat commit cleanouts 2 sesstat commit cleanouts successfully completed 2 sesstat consistent gets 86936 sesstat db block changes 29 sesstat deferred (CURRENT) block cleanout applications 1 sesstat no work - consistent read gets 83098 sesstat physical reads 67023

まとめ

遅延ブロッククリーンアウトは、インスタンスを停止して残ったままということが確認できました。（クリアされるまで残るのですよねー）
クリーンアウトが遅延されているブロックが物理読み込みされた（アクセスされた）タイミングで遅延ブロッククリーンアウトが発生することも確認できました。（物理読み込みの有無には関係しない）
バッファキャッシュ上の遅延ブロッククリーンアウト同様、クリーンアウトされたブロックでは、再度、クリーンアウト対象になるような更新が発生しなければ、遅延ブロッククリーンアウトは発生しない

久しぶりにシステム統計やセッション統計を見ててワクワクしてきましたよーーーーっw

ところで、
冒頭でも記載しましたが、バッファキャッシュ上の遅延ブロッククリーンアウト（再掲）に加え、物理読み込みを伴う遅延ブロッククリーンアウトのauto traceの結果をまとめて記載しておきます。SELECT文ですが、REDOログが生成されている場合は遅延ブロッククリーンアウトが発生しているということになります。

実行計画

-------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | -------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 194K| 188M| 18189 (1)| 00:00:01 | | 1 | TABLE ACCESS FULL| HOGE | 194K| 188M| 18189 (1)| 00:00:01 | --------------------------------------------------------------------------

1. 遅延ブロッククリーンアウトを発生させた場合。遅延ブロッククリーンアウト対象のデータがバッファキャッシュ上ににあるためクリーンアウトに伴う物理読み込みはない。

Statistics ---------------------------------------------------------- 46 recursive calls 13 db block gets 91636 consistent gets 7 physical reads 967348 redo size 406775148 bytes sent via SQL*Net to client 147264 bytes received via SQL*Net from client 13335 SQL*Net roundtrips to/from client 2 sorts (memory) 0 sorts (disk) 200000 rows processed

2. 直後に再度全表走査した場合も、キャッシュヒットしているので、物理読み込みはない

Statistics ---------------------------------------------------------- 0 recursive calls 0 db block gets 80061 consistent gets 0 physical reads 0 redo size 406775148 bytes sent via SQL*Net to client 147264 bytes received via SQL*Net from client 13335 SQL*Net roundtrips to/from client 0 sorts (memory) 0 sorts (disk) 200000 rows processed

3. 遅延ブロッククリーンアウトを発生させた場合。遅延ブロッククリーンアウト対象のデータを物理読み込みし、バッファキャッシュに載せている動きが見えます。

Statistics ---------------------------------------------------------- 38 recursive calls 13 db block gets 91519 consistent gets 67073 physical reads 967432 redo size 406775148 bytes sent via SQL*Net to client 147264 bytes received via SQL*Net from client 13335 SQL*Net roundtrips to/from client 5 sorts (memory) 0 sorts (disk) 200000 rows processed

4. 3.の直後に再度全表走査した場合。事前にキャッシュをクリアしているため、物理読み込みがありますが、遅延ブロッククリーンアウトは発生していません。（Redoが生成されていないことで確認できます）

Statistics ---------------------------------------------------------- 30 recursive calls 0 db block gets 80211 consistent gets 66719 physical reads 0 redo size 406775148 bytes sent via SQL*Net to client 147264 bytes received via SQL*Net from client 13335 SQL*Net roundtrips to/from client 5 sorts (memory) 0 sorts (disk) 200000 rows processed

ではでは。
次回は、scattered readのtable full scanではなく、direct path readだったらどうなるのか調べてみましょうか。。（いろいろな再現方法があるわけですが、手間のかからないお手軽な再現方法で確認してみようと思いますw）

洗濯機の修理が終わって一安心w　ということで、次回へつづく。

・古くて新しい？遅延ブロッククリーンアウト (deferred block cleanout) #1
・古くて新しい？遅延ブロッククリーンアウト (deferred block cleanout) #2
・古くて新しい？遅延ブロッククリーンアウト (deferred block cleanout) #3
・古くて新しい？遅延ブロッククリーンアウト (deferred block cleanout) #4

投稿日時 2021年9月 9日 (木) 00時00分 Oracle, PL/SQL, チューニング, FAQ, SQL, パフォーマンス, Oracle Database 19c | 固定リンク | 0 | コメント (0)

2021年9月 3日 (金)

古くて新しい？遅延ブロッククリーンアウト (deferred block cleanout) #4

Previously on Mac De Oracle
前回はバッファキャッシュの10%未満のデータブロックへのINSERT文の実行とCOMMITの実行で、遅延ブロッククリーンアウトは発生せず、COMMIT時にすべての対象ブロックがクリーンアウトされるということを確認しました。

今回は、そのデータ量を倍にして、バッファキャッシュの10％程度を超えるデータブロックが遅延ブロッククリーンアウトされるのかを見ていくことにします。手順は前回と同じですが、遅延ブロッククリーンアウトさせた後で、もう一度全表走査してクリーンアウトが繰り返されないことも確認しておきます（次回以降に予定している確認への伏線なのですがw）

0) 対象表をdrop/create
オブジェクトを作り直して前提条件を合わせておきます

SCOTT@orcl> @droppurge_create_hoge Table dropped. Table created. SCOTT@orcl> select segment_name,blocks from user_segments where segment_name like '%HOGE%'; no rows selected

1) 統計をクリアするのにOracle再起動

$ sudo service oracle restart

2) PDBのscottでログインし、client_infoをセット
v$sessionのclient_info列の'TargetSession'文字列で他のSCOTTユーザーのセッションと区別できるようにしています

SCOTT@orcl> @set_client_info 1 begin 2 DBMS_APPLICATION_INFO.SET_CLIENT_INFO('Target Session'); 3* end; PL/SQL procedure successfully completed. Elapsed: 00:00:00.00 SCOTT@orcl>

3) CDBのSYSで統計取得（初回）

内容は省略！（ベースラインを取得しているだけなので）

SYS$orclcdb> @show_stat

4) PDBのSCOTTユーザーでデータINSERT（データ量2倍、コミットなし）

SCOTT@orcl> @insert_each_rows_2 1* begin for i in 1..200000 loop insert into hoge values(i, lpad('*', 2000, '*')); end loop; end; PL/SQL procedure successfully completed. Elapsed: 00:00:29.48 SCOTT@orcl>

5) CDBのSYSで統計取得（INSERT後、未コミット）

INSERTしただけです。未コミットなので特に気になる情報は現れていません。この値からコミット後にどのように変化するのか？　という部分に注目する必要があるんですよー。
deferred (CURRENT) block cleanout applications と　immediate (CURRENT) block cleanout applications が僅かにありますが、この時点では気にする部分ではないです

（値の変化が1以上ある統計のみ表示）

(CDB）システム統計

SOURCE NAME VALUE ------- ------------------------------------------------- -------------------- sysstat DBWR checkpoint buffers written 22756 sysstat DBWR checkpoints 33 sysstat DBWR thread checkpoint buffers written 22756 sysstat DBWR transaction table writes 22 sysstat DBWR undo block writes 606 sysstat consistent gets 49761 sysstat db block changes 744980 sysstat deferred (CURRENT) block cleanout applications 4 sysstat immediate (CURRENT) block cleanout applications 1 sysstat no work - consistent read gets 192 sysstat physical reads 18 sysstat physical writes 22756 sysstat physical writes from cache 22756 sysstat physical writes non checkpoint 22756

(PDB)　SCOTTのセッション統計

SOURCE NAME VALUE ------- ------------------------------------------------- -------------------- sesstat consistent gets 49501 sesstat db block changes 744980 sesstat deferred (CURRENT) block cleanout applications 4 sesstat immediate (CURRENT) block cleanout applications 1 sesstat no work - consistent read gets 65 sesstat physical reads 17

6) PDBのSCOTTユーザーでコミットの実行

SCOTT@orcl> commit; Commit complete.

7) CDBのSYSで統計取得（コミット後）

この結果、ノイズも少なく、綺麗に取れてます！！！　w

前々回の事前確認の通り、2倍のデータブロック数は、 66667ブロック　で、バッファキャッシュの10%は、ざっくり計算で、42394ブロック。つまり、想定では 42394ブロックほどが、commit時のブロッククリーンアウトの対象と想定していました。

覚えてますか？　みなさん！

実際にcommit時にクリーンアウトされたのはどれぐらいでしょう？　
結果は、55700ブロックとなりました。想定より多いですねw　ほぼ合ってはいますが。
実際にはバッファキャッシュの13%〜15％程度が閾値になっているように見えます。とはいえ、commit時にcleanoutされたブロック数は 55700ブロックですから、残る 10967ブロックのcleanoutは遅延されたということは確実です。commit対象のデータブロック全てをcleanoutするわけではない、ということは確認できたのではないでしょうか？

(差分が1以上ある統計のみ記載)
(CDB）システム統計

SOURCE NAME VALUE ------- ------------------------------------------------- -------------------- sysstat commit cleanouts 55700 sysstat commit cleanouts successfully completed 55700 sysstat db block changes 1

(PDB)　SCOTTのセッション統計

SOURCE NAME VALUE ------- ------------------------------------------------- -------------------- sesstat commit cleanouts 55700 sesstat commit cleanouts successfully completed 55700 sesstat db block changes 1

8) PDBのSCOTTユーザーで、遅延ブロッククリーンアウト影響有無確認（対象表を全表走査）

SCOTT@orcl> sset autot trace exp stat SCOTT@orcl> salter session set "_serial_direct_read" = never; Session altered. Elapsed: 00:00:00.00 SCOTT@orcl> select * from hoge; 200000 rows selected. Elapsed: 00:00:05.14 Execution Plan ---------------------------------------------------------- Plan hash value: 2339479017 -------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | -------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 194K| 188M| 18189 (1)| 00:00:01 | | 1 | TABLE ACCESS FULL| HOGE | 194K| 188M| 18189 (1)| 00:00:01 | -------------------------------------------------------------------------- Note ----- - dynamic statistics used: dynamic sampling (level=2) Statistics ---------------------------------------------------------- 46 recursive calls 13 db block gets 91636 consistent gets 7 physical reads 967348 redo size 406775148 bytes sent via SQL*Net to client 147264 bytes received via SQL*Net from client 13335 SQL*Net roundtrips to/from client 2 sorts (memory) 0 sorts (disk) 200000 rows processed

9) CDBのSYSで統計取得（遅延ブロッククリーンアウト有無確認）

遅延ブロッククリーンアウトは、事前の計算通り、 10967ブロック発生しています。SELECT文では、immediate (CR) block cleanout applications として現れることも確認できます。
また、cleanouts only - consistent read gets としても同数計上されているところが見てます。綺麗に現れています。

commit cleanouts, ommit cleanouts successfully completed がでていますが、ここでは気にしなくてよいですね、極わずかで。SELECT文なので。
immediate (CURRENT) block cleanout applications、deferred (CURRENT) block cleanout applications もでていますが、同じく極わずかで、対象表のものではないと考えられるためここでは気にしなくて良いですね。

しかし、計算通りに発生してくれると確認が楽w　（想定外の動きじゃなくてよかったw）

(CDB）システム統計

SOURCE NAME VALUE ------- ------------------------------------------------- -------------------- sysstat DBWR checkpoint buffers written 272 sysstat DBWR thread checkpoint buffers written 272 sysstat cleanouts only - consistent read gets 10967 sysstat commit cleanouts 16 sysstat commit cleanouts successfully completed 16 sysstat consistent gets 117000 sysstat db block changes 11207 sysstat deferred (CURRENT) block cleanout applications 10 sysstat immediate (CR) block cleanout applications 10967 sysstat immediate (CURRENT) block cleanout applications 2 sysstat no work - consistent read gets 83351 sysstat physical reads 939 sysstat physical writes 272 sysstat physical writes from cache 272 sysstat physical writes non checkpoint 260

(PDB)　SCOTTのセッション統計

SOURCE NAME VALUE ------- ------------------------------------------------- -------------------- sesstat cleanouts only - consistent read gets 10967 sesstat commit cleanouts 6 sesstat commit cleanouts successfully completed 6 sesstat consistent gets 98162 sesstat db block changes 11011 sesstat deferred (CURRENT) block cleanout applications 2 sesstat immediate (CR) block cleanout applications 10967 sesstat immediate (CURRENT) block cleanout applications 2 sesstat no work - consistent read gets 72113 sesstat physical reads 122

10) PDBのSCOTTユーザーで、遅延ブロッククリーンアウト影響有無確認（対象表を全表走査）

そして、ここからがおまけの確認ステップです

もう一度、同じ表を全表走査してみます。どうなると思いますか？　遅延されていたブロッククリーンアウトも行われたのですから、当然、該当オブジェクトで遅延ブロッククリーンアウトは発生しない。はず！　ですよね。

確認してみましょう。（発生してたらどうしようw、もうしそうなったらバグレポートでも上げようかなw）

.......

Redoは生成されてない！　（よかった！　想定どおりだ！w）

SCOTT@orcl> @table_full_scan 1* alter session set "_serial_direct_read" = never Session altered. Elapsed: 00:00:00.00 set autot trace exp stat 1* select * from hoge 200000 rows selected. Elapsed: 00:00:05.43 Execution Plan ---------------------------------------------------------- Plan hash value: 2339479017 -------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | -------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 214K| 207M| 18223 (1)| 00:00:01 | | 1 | TABLE ACCESS FULL| HOGE | 214K| 207M| 18223 (1)| 00:00:01 | -------------------------------------------------------------------------- Note ----- - dynamic statistics used: dynamic sampling (level=2) Statistics ---------------------------------------------------------- 0 recursive calls 0 db block gets 80061 consistent gets 0 physical reads 0 redo size 406775148 bytes sent via SQL*Net to client 147264 bytes received via SQL*Net from client 13335 SQL*Net roundtrips to/from client 0 sorts (memory) 0 sorts (disk) 200000 rows processed set autot off SCOTT@orcl>

11) CDBのSYSで統計取得（遅延ブロッククリーンアウト有無確認）2回目

これもノイズが少なく綺麗に取れました。該当セッションでは物理読み込みも発生していないので、キャッシュから全データを読み込んだようです。

そして、想定どおり、該当セッションでは遅延ブロッククリーンアウトは発生していません！

commit cleanouts、commit cleanouts successfully completed、deferred (CURRENT) block cleanout applicationsが1ブロックありますがCDB側の管理情報関連でしょうね。気にする部分ではないですね。

（差分のあった統計のみ記載）

(CDB）システム統計

SOURCE NAME VALUE ------- ------------------------------------------------- -------------------- sysstat commit cleanouts 1 sysstat commit cleanouts successfully completed 1 sysstat consistent gets 80150 sysstat db block changes 13 sysstat deferred (CURRENT) block cleanout applications 1 sysstat no work - consistent read gets 80075

(PDB)　SCOTTのセッション統計

SOURCE NAME VALUE ------- ------------------------------------------------- -------------------- sesstat consistent gets 80076 sesstat db block changes 9 sesstat no work - consistent read gets 80043

まとめ

おおよそ、バッファキャッシュの10%程度が commit時にcleanout　されるという点については、約15%程度と見ておいたほうが良さそうですが、まあ大きな違いはないので、その辺りに閾値があると考えて問題はなさそうです。
また、それを超えるブロックについては、cleanoutが先送りされ、最初に該当ブロックにアクセスしたSQLがその影響を受ける。

この検証ではSELECT文では、immediate (CR) block cleanout applications　という形で統計に現れました。UPDATE文やDELETE文の場合は他の統計として現れそうですね。(CURRENT)関連のcleanoutの統計は今回動いていないのでSQL文を変えて同じような検証をしてみると面白い結果をえられそうです。

そして、SELECT文で、遅延ブロッククリーンアウトされてしまえば、その間に更新が発生しなければ、クリーンアウトは発生しない（おまけで検証した部分ですが、別検証では興味深い動きを紹介する予定です。その伏線でもあります）

次回へつづく

5年目を迎えた、パナソニックのドラム洗濯機がH故障した。慌てて近所のコインランドリーを検索w　近所にあってよかったw

・古くて新しい？遅延ブロッククリーンアウト (deferred block cleanout) #1
・古くて新しい？遅延ブロッククリーンアウト (deferred block cleanout) #2
・古くて新しい？遅延ブロッククリーンアウト (deferred block cleanout) #3

投稿日時 2021年9月 3日 (金) 12時00分 Oracle, PL/SQL, チューニング, FAQ, SQL, パフォーマンス, Oracle Database 19c | 固定リンク | 0 | コメント (0)

2021年9月 2日 (木)

古くて新しい？遅延ブロッククリーンアウト (deferred block cleanout) #3

Previously on Mac De Oracle
前回は準備を終えたところまででした。

今日は、簡単なところから確認していきましょう。

もしも、「遅延ブロッククリーンアウトが起きない程度のブロック更新量だったなら。。。」。結果は遅延ブロッククリーンアウトは起きないはず。　ですよね。

ざっと手順を紹介しておきましょう。下図の 1)〜9)の順で行います

前述の手順で、各操作後の統計の差分（変化量）を見る。マニュアルの統計の説明ってざっくり過ぎてよくわからないのが多いわけですがw、操作と値の変化を合わせて観察すると、それなりには理解できる程度に値が変化していることに気づきますw　：）

1) 統計をクリアするのにOracle再起動

$ sudo service oracle restart

2) PDBのscottでログインし、client_infoをセット
v$sessionのclient_info列の'TargetSession'文字列で他のSCOTTユーザーのセッションと区別できるようにしています。

SCOTT@orcl> @set_client_info 1 begin 2 DBMS_APPLICATION_INFO.SET_CLIENT_INFO('TargetSession'); 3* end; PL/SQL procedure successfully completed.

3) CDBのSYSで統計取得（初回）
初回なのですべてリストしていますが、CON_ID=0のCDBのシステム統計([g]v$sysstat)とCON_ID=3のPDBの2)のCLIENT_INFOを設定されたセッションのセッション統計([g]v$sesstat)を取得します。
今回のケースではcleanoutが含まれている統計の差異だけに着目すれば良いのですが。準備運動程度のテストケースなので一応すべて載せておきます :)
（マルチテナントだと、DBRWの動きを見るにはCDBのDBWR関連の統計を見る必要があるため、CDBのシステム統計とPDBの当該セッションのセッション統計を対象にしています）

SYS$orclcdb> @show_stat SOURCE NAME VALUE CON_ID ------- ------------------------------------------------------------ -------------------- ---------- sysstat DBWR checkpoint buffers written 0 0 sysstat DBWR checkpoints 0 0 sysstat DBWR fusion writes 0 0 sysstat DBWR lru scans 0 0 sysstat DBWR object drop buffers written 0 0 sysstat DBWR parallel query checkpoint buffers written 0 0 sysstat DBWR revisited being-written buffer 0 0 sysstat DBWR tablespace checkpoint buffers written 0 0 sysstat DBWR thread checkpoint buffers written 0 0 sysstat DBWR transaction table writes 0 0 sysstat DBWR undo block writes 0 0 sysstat cleanouts and rollbacks - consistent read gets 6 0 sysstat cleanouts only - consistent read gets 0 0 sysstat commit cleanout failures: block lost 0 0 sysstat commit cleanout failures: buffer being written 0 0 sysstat commit cleanout failures: callback failure 0 0 sysstat commit cleanout failures: cannot pin 0 0 sysstat commit cleanout failures: hot backup in progress 0 0 sysstat commit cleanout failures: write disabled 0 0 sysstat commit cleanouts 570 0 sysstat commit cleanouts successfully completed 570 0 sysstat consistent gets 158,083 0 sysstat db block changes 3,247 0 sysstat deferred (CURRENT) block cleanout applications 316 0 sysstat immediate (CR) block cleanout applications 6 0 sysstat immediate (CURRENT) block cleanout applications 15 0 sysstat no work - consistent read gets 108,516 0 sysstat physical reads 12,551 0 sysstat physical reads direct 0 0 sysstat physical writes 0 0 sysstat physical writes direct 0 0 sysstat physical writes from cache 0 0 sysstat physical writes non checkpoint 0 0 sysstat transaction tables consistent read rollbacks 0 0 sysstat transaction tables consistent reads - undo records applied 0 0 sesstat DBWR checkpoint buffers written 0 3 sesstat DBWR checkpoints 0 3 sesstat DBWR fusion writes 0 3 sesstat DBWR lru scans 0 3 sesstat DBWR object drop buffers written 0 3 sesstat DBWR parallel query checkpoint buffers written 0 3 sesstat DBWR revisited being-written buffer 0 3 sesstat DBWR tablespace checkpoint buffers written 0 3 sesstat DBWR thread checkpoint buffers written 0 3 sesstat DBWR transaction table writes 0 3 sesstat DBWR undo block writes 0 3 sesstat cleanouts and rollbacks - consistent read gets 0 3 sesstat cleanouts only - consistent read gets 0 3 sesstat commit cleanout failures: block lost 0 3 sesstat commit cleanout failures: buffer being written 0 3 sesstat commit cleanout failures: callback failure 0 3 sesstat commit cleanout failures: cannot pin 0 3 sesstat commit cleanout failures: hot backup in progress 0 3 sesstat commit cleanout failures: write disabled 0 3 sesstat commit cleanouts 1 3 sesstat commit cleanouts successfully completed 1 3 sesstat consistent gets 374 3 sesstat db block changes 4 3 sesstat deferred (CURRENT) block cleanout applications 1 3 sesstat immediate (CR) block cleanout applications 0 3 sesstat immediate (CURRENT) block cleanout applications 0 3 sesstat no work - consistent read gets 220 3 sesstat physical reads 28 3 sesstat physical reads direct 0 3 sesstat physical writes 0 3 sesstat physical writes direct 0 3 sesstat physical writes from cache 0 3 sesstat physical writes non checkpoint 0 3 sesstat transaction tables consistent read rollbacks 0 3 sesstat transaction tables consistent reads - undo records applied 0 3

4) PDBのSCOTTユーザーでデータINSERT（コミットなし）
データを1行単位でインサートしています。バルクインサートも使ってないです。綺麗なぐるぐる系ですねw。コミット時の効果を確認しやすいようにコミットは後で実行します！
このインサートで、前回の事前準備の時に確認しておいた、33334ブロックが更新されることになります

SCOTT@orcl> @insert_each_rows 1* begin for i in 1..100000 loop insert into hoge values(i, lpad('*', 2000, '*')); end loop; end; PL/SQL procedure successfully completed.

5) CDBのSYSで統計取得（INSERT後、未コミット）

注）　3)の統計との差分のみ記載

未コミットであるこの時点で、commitクリーンアウトが発生（該当セッション統計でも同数発生。commit cleanoutsとcommit cleanouts successfully completed）してますが、これは気にしなくてもよいですね。
実行したトランザクションは、未コミットなので、この実行による直接的な影響ではないので。
また、deferred (CURRENT) block cleanout applicationsやimmediate (CURRENT) block cleanout applications の遅延ブロッククリーンアウトを示す統計も微量ですがこれも同様とみて良いでしょう。

この時点で統計取得理由は、操作毎に変化する統計を追うためなので、ふーーん。ぐらいでの雰囲気でOKです　：）
コミット後とその後に該当オブジェクトをアクセスさせた時の遅延ブロッククリーンアウトの有無部分の部分が主役ですので。

参考）
INSERTした行の含まれる全ブロックはバッファキャッシュに載り切るブロック数なので、バッファキャッシュから書き出されているような動きも観測されていないのは確認できると思います。
（physical writes from cache,physical writes non checkpoint,physical writesの統計に変化がないので未記載ですが、それらの統計が動いていないということがその理由です）

(CDB）システム統計

SOURCE NAME　　　　　　　　　　　　　　　　　　　　　　　 VALUE ------- ---------------------------------------------------- --------------- sysstat DBWR checkpoints 1 sysstat commit cleanouts 6 sysstat commit cleanouts successfully completed 6 sysstat consistent gets 22884 sysstat db block changes 373785 sysstat deferred (CURRENT) block cleanout applications 5 sysstat immediate (CURRENT) block cleanout applications 1 sysstat no work - consistent read gets 59 sysstat physical reads 12

(PDB)　SCOTTのセッション統計

SOURCE NAME　　　　　　　　　　　　　　　　　　　　　　　 VALUE ------- ---------------------------------------------------- --------------- sesstat commit cleanouts 6 sesstat commit cleanouts successfully completed 6 sesstat consistent gets 22816 sesstat db block changes 373785 sesstat deferred (CURRENT) block cleanout applications 5 sesstat immediate (CURRENT) block cleanout applications 1 sesstat no work - consistent read gets 49 sesstat physical reads 12

6) PDBのSCOTTユーザーでコミットの実行

SCOTT@orcl> commit; Commit complete.

7) CDBのSYSで統計取得（コミット後）

注）5)と7)で取得した統計の差分のみ記載

ここが主役ですよー。このケースではバッファキャッシュの10%に満たないブロック数になるようにしたINSERT文(繰り返し実行)で 33334ブロックになるようにしました。これらを1度でcommitした場合、すべてのブロックがcommit時にblock cleanoutされるはずです。

では見てみましょう。

SCOTTのセッション統計より、commit cleanouts および commit cleanouts successfully completed　から想定どおり全ブロックがcommit時にcleanoutされていることがわかります！
システム統計はインスタンス全体なのでPDBのそれら統計より大きめにでているのも確認できます。CDB側ではほんの少し　deferred (CURRENT) block cleanout applications　がありますが、管理情報系の遅延ブロッククリーンアウトでしょうね。　
古くて新しい？遅延ブロッククリーンアウト (deferred block cleanout) #1で紹介したとおり 10%　未満では　commit 時点で該当ブロックすべてcleanoutされることが確認できました。

(CDB）システム統計

SOURCE NAME　　　　　　　　　　　　　　　　　　　　　　　 VALUE ------- ---------------------------------------------------- --------------- sysstat DBWR checkpoint buffers written 139 sysstat DBWR transaction table writes 22 sysstat DBWR undo block writes 55 sysstat commit cleanouts 33343 sysstat commit cleanouts successfully completed 33343 sysstat consistent gets 18111 sysstat db block changes 138 sysstat deferred (CURRENT) block cleanout applications 5 sysstat no work - consistent read gets 10853 sysstat physical reads 827 sysstat physical writes 139 sysstat physical writes from cache 139 sysstat physical writes non checkpoint 139

(PDB)　SCOTTのセッション統計

SOURCE NAME　　　　　　　　　　　　　　　　　　　　　　　 VALUE ------- ---------------------------------------------------- --------------- sesstat commit cleanouts 33334 sesstat commit cleanouts successfully completed 33334 sesstat db block changes 1

8) PDBのSCOTTユーザーで、遅延ブロッククリーンアウト影響有無確認（対象表を全表走査）

_serial_direct_read = never はdirect path readさせないためのおまじないです。direct path readで読み込まれたケースの動きは別エントリーで見ていく予定なので、direct path readを発生させずtable full scan (ようするにバッファキャッシュに載せる動き)で読み込むよう強制しています。
また、行数が多いのでその時間の短縮のためにautot trace exp statを有効にしてSELECT文を実行させつつ、termout offと同じ効果とauto explainの機能でSELECT文の実行統計からredoの生成有無を確認しています。（redoがあるということはなんらかの更新が行われているわけで、SELECT文の場合は比較的容易に遅延ブロッククリーンアウトの発生を推測できる統計にもなります）
以下のケースでは多少redoが生成されていますが、おそらく　recursive callによるもので、HOGE表のオブジェクトそのものに対するもではなさそうです。（このケースではhoge表のオブジェクトに対する遅延ブロッククリーンアウトや
コミット時のブロッククリーンアウトの観察が主題なので、周りのノイズはあまり気にしなくてもOK（追いかけたい場合は別ですがw)

SCOTT@orcl> set autot trace exp stat SCOTT@orcl> alter session set "_serial_direct_read" = never; Session altered. Elapsed: 00:00:00.00 SCOTT@orcl> select * from hoge; 100000 rows selected. Elapsed: 00:00:02.59 Execution Plan ---------------------------------------------------------- Plan hash value: 2339479017 -------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | -------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 57526 | 55M| 9098 (1)| 00:00:01 | | 1 | TABLE ACCESS FULL| HOGE | 57526 | 55M| 9098 (1)| 00:00:01 | -------------------------------------------------------------------------- Note ----- - dynamic statistics used: dynamic sampling (level=2) Statistics ---------------------------------------------------------- 21 recursive calls 13 db block gets 40465 consistent gets 3 physical reads 2212 redo size 203382760 bytes sent via SQL*Net to client 73706 bytes received via SQL*Net from client 6668 SQL*Net roundtrips to/from client 0 sorts (memory) 0 sorts (disk) 100000 rows processed SCOTT@orcl> set autot off

9) CDBのSYSで統計取得（遅延ブロッククリーンアウト有無確認）

注）7)のコミット時点からとの差異のみ記載。

多少ですが、SELECT文でredoが生成されてはいます。これは、commit cleanouts/commit cleanouts successfully completed (commit時に実施されるblock cleanout)と遅延ブロッククリーンアウトの統計の一つ、deferred (CURRENT) block cleanout applications が現れている影響ですね。コミット時点でHOGE表の全ブロックはcleanout済みなので recursive callによる内部管理情報関連で定常的に現れるものと考えられ、この検証では気にするところではないのでスルーしてください。

また、physical reads は、ほぼないため、この全表走査では、物理読み込み（direct path read含む）は、発生していないことも確認できます。
HOGE表はバッファキャッシュに載ったままという意図通りの状態にはなっているようです。
これ、今後のテストケースでも利用するので、キャッシュからエージアウトされないという点が確認できてると、以降の検証やりやすいんです:)

(CDB) システム統計

SOURCE NAME　　　　　　　　　　　　　　　　　　　　　　　 VALUE ------- ---------------------------------------------------- --------------- sysstat DBWR checkpoint buffers written 34849 sysstat DBWR transaction table writes 32 sysstat DBWR undo block writes 897 sysstat commit cleanouts 558 sysstat commit cleanouts successfully completed 558 sysstat consistent gets 69973 sysstat db block changes 2862 sysstat deferred (CURRENT) block cleanout applications 311 sysstat immediate (CURRENT) block cleanout applications 28 sysstat no work - consistent read gets 57908 sysstat physical reads 812 sysstat physical writes 34849 sysstat physical writes from cache 34849 sysstat physical writes non checkpoint 34738

(PDB)　SCOTTのセッション統計

SOURCE NAME　　　　　　　　　　　　　　　　　　　　　　　 VALUE ------- ---------------------------------------------------- --------------- sesstat commit cleanouts 5 sesstat consistent gets 47037 sesstat db block changes 38 sesstat deferred (CURRENT) block cleanout applications 4 sesstat no work - consistent read gets 43103 sesstat physical reads 117

まとめ

DMLにより更新されたブロック数が、バッファキャッシュの10%未満のブロック数である場合、commit時にすべてcleanoutされ、対象表では遅延ブロッククリーンアウトは発生しない。
（想定通りなのですが、ちょいと安心w　19cでどう動くか確認してなかってしので少々ドキドキしてたw　のはナイショ）

というわけで、今回はここまで。

いきなり涼しくなって、なんだこりゃ。。。。

・古くて新しい？遅延ブロッククリーンアウト (deferred block cleanout) #1
・古くて新しい？遅延ブロッククリーンアウト (deferred block cleanout) #2

投稿日時 2021年9月 2日 (木) 00時00分 Oracle, PL/SQL, チューニング, FAQ, SQL, パフォーマンス, Oracle Database 19c | 固定リンク | 0 | コメント (0)

2021年8月31日 (火)

古くて新しい？遅延ブロッククリーンアウト (deferred block cleanout) #2

Previously on Mac De Oracle

前回は、遅延ブロッククリーンアウトに限らず、大きく変わったわけでも、最近実装された機能でもないのに意外に知られてないのか、良いところ悪いところ含め、現場でロストしてしまっているような知識って意外と多いのかもねー。なんて感じたので遅延ブロッククリーンアウトネタのURLリンクをまとめてみた。

続編書くにしても、同じようなことやっても面白くないので、ブロックダンプのような方法は使わず、[g]v$sysstatや[g]v$sesstatなどの統計から、ちょいと血糖値や尿酸値高めだよね的な角度からどのような変化が起きるか見ていくことにした :)

環境はVirtualBox上の19cでこれからの主流になるマルチテナントで試してみます。（非マルチテナントでの変化見ててもこれからはあまり役に立たないので）

今日は準備編

VirtualBox
https://www.virtualbox.org/

Pre-Built Developer VMs (for Oracle VM VirtualBox)のDatabase App Development VMとか
https://www.oracle.com/downloads/developer-vm/community-downloads.html

事前に準備しておくスクリプトは以下のとおり。繰り返し実行するので作っておくと便利ですよ。:)

まず最初に、遅延ブロッククリーンアウトはバッファキャッシュの10%ほどのブロックをコミット時にクリーンアウトして、残りを先送りするという基本的なお約束があるので、上記環境のOracle 19cがどの程度のバッファキャッシュなのかとブロックサイズを確認。これ大切ですよ。スクリプト準備する上でも　：）

メモリサイズは大きめですが。。。w　うちのは。(^^;;;

$ VBoxManage -v 6.1.26r145957 $ $ VBoxManage showvminfo 'Oracle DB Developer VM　19.3' | grep -E 'Memory|CPUs' Memory size: 16384MB Number of CPUs: 4 $

コミット時にブロッククリーンアウトされそうなブロック数をざっくり算出すると　42394　ブロックぐらいになりそう。

SYS@orclcdb> show sga Total System Global Area 4294963960 bytes Fixed Size 9143032 bytes Variable Size 805306368 bytes Database Buffers 3472883712 bytes Redo Buffers 7630848 bytes SYS@orclcdb> SYS@orclcdb> show parameter db_block_size NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ db_block_size integer 8192 SYS@orclcdb> SYS@orclcdb> select ceil( 3472883712 / 8192 * 0.1 ) from dual; CEIL(3472883712/8192*0.1) ------------------------- 42394 Elapsed: 00:00:00.00

42394ブロックを超える程度のサイズのデータを生成するINSERT文と、その範囲に収まるデータ量生成INSERT文スクリプトを作れば良さそうですね。

想定されるブロックに収まる程度の量。1ブロック 8KB　でデフォルトのPCTFREEは10%なのでざっくり6000bytes/rec超えるぐらい。
で、1ブロックに3行ぐらい入るようにすれば面白いかな。。

ということで、

表はなんどもdrop/createするので以下のDDLで。初回は索引を作らず、表のみので影響をみることにする。

$ cat droppurge_create_hoge.sql drop table hoge purge; create table hoge (id number, data varchar2(2000));

データ作成（バッファキャッシュの10％未満のデータ登録）
なお、確実に遅延ブロッククリーンアウトの影響を見たいので１行ごとのINSERTを繰り返し、コミット前後の状態の変化も見たいのでcommitも含めていない。（commitは別途実行する）

$ cat insert_rows.sql begin for i in 1..100000 loop insert into hoge values(i, lpad('*', 2000, '*')); end loop; end; . l /

ブロック数の事前確認

SCOTT@ORCL> select count(distinct dbms_rowid.rowid_block_number(rowid)) as "blocks" from hoge; blocks ---------- 33334

データ作成（バッファキャッシュの10％を超えるのデータ登録）
単純にループ回数を倍にして増量。これで事前に算出したバッファキャッシュの10％以上のブロック数は更新される。。。はず。

$ cat insert_rows_2.sql begin for i in 1..200000 loop insert into hoge values(i, lpad('*', 2000, '*')); end loop; end; . l /

ブロック数の事前確認（20,000ブロックぐらい？は遅延される想定）

SCOTT@ORCL> select count(distinct dbms_rowid.rowid_block_number(rowid)) as "blocks" from hoge; blocks ---------- 66667

ここまでが遅延ブロッククリーンアウトを意図的に起こすためのデータ作成SQLスクリプト

以降は、遅延ブロッククリーンアウトの発生等を見るための[g]v$sysstatと[g]v$sestatを取得するスクリプトと、[g]v$sesstatから特定のセッションを取得するためのクライアント情報をセットするスクリプト。

$ cat set_client_info.sql BEGIN DBMS_APPLICATION_INFO.SET_CLIENT_INFO('TargetSession'); END; . l /

システム統計とセッション統計を取得して差分を見ていく必要があるので各統計のスナップショット取得用スクリプトが必要なわけですが、今回はマルチテナント環境。なので、システム統計はCDB全体から、セッション統計は該当するPDBかつ、前述のスクリプトでClient Infoが設定されているセッションに限定するスクリプトを作る必要があるんですよね。DBWRの動きも含めてみたいときって。少し多めに統計名を取得していますが、実際に重要なのはcleanout系の統計ですね。いくつかのテストケースを実施する上で合わせてみておきたい統計も事前に入れてあります:)

$ cat show_stat.sql set linesize 400 set tab off set pagesize 1000 col name for a60 col value for 999,999,999,999,999 SELECT 'sysstat' AS "SOURCE" , name , value , con_id FROM gv$sysstat WHERE name IN ( 'physical writes direct' , 'physical writes from cache' , 'physical writes non checkpoint' , 'consistent gets' , 'no work - consistent read gets' , 'cleanouts and rollbacks - consistent read gets' , 'cleanouts only - consistent read gets' , 'deferred (CURRENT) block cleanout applications' , 'immediate (CR) block cleanout applications' , 'immediate (CURRENT) block cleanout applications' , 'commit cleanout failures: block lost' , 'commit cleanout failures: buffer being written' , 'commit cleanout failures: callback failure' , 'commit cleanout failures: cannot pin' , 'commit cleanout failures: hot backup in progress' , 'commit cleanout failures: write disabled' , 'commit cleanouts' , 'commit cleanouts successfully completed' , 'db block changes' , 'physical read requests' , 'physical reads' , 'physical reads direct' , 'physical write requests' , 'physical writes' , 'physical writes direct' , 'DBWR checkpoint buffers written' , 'DBWR thread checkpoint buffers written' , 'DBWR tablespace checkpoint buffers written' , 'DBWR parallel query checkpoint buffers written' , 'DBWR object drop buffers written' , 'DBWR transaction table writes' , 'DBWR undo block writes' , 'DBWR revisited being-written buffer' , 'DBWR lru scans' , 'DBWR checkpoints' , 'DBWR fusion writes' , 'transaction tables consistent reads - undo records applied' , 'transaction tables consistent read rollbacks' ) UNION ALL SELECT 'sesstat' AS "SOURCE" , name , value , vsesstat.con_id FROM gv$sesstat vsesstat inner join gv$statname vstatnam on vsesstat.statistic# = vstatnam.statistic# WHERE name IN ( 'physical writes direct' , 'physical writes from cache' , 'physical writes non checkpoint' , 'consistent gets' , 'no work - consistent read gets' , 'cleanouts and rollbacks - consistent read gets' , 'cleanouts only - consistent read gets' , 'deferred (CURRENT) block cleanout applications' , 'immediate (CR) block cleanout applications' , 'immediate (CURRENT) block cleanout applications' , 'commit cleanout failures: block lost' , 'commit cleanout failures: buffer being written' , 'commit cleanout failures: callback failure' , 'commit cleanout failures: cannot pin' , 'commit cleanout failures: hot backup in progress' , 'commit cleanout failures: write disabled' , 'commit cleanouts' , 'commit cleanouts successfully completed' , 'db block changes' , 'physical read requests' , 'physical reads' , 'physical reads direct' , 'physical write requests' , 'physical writes' , 'physical writes direct' , 'DBWR checkpoint buffers written' , 'DBWR thread checkpoint buffers written' , 'DBWR tablespace checkpoint buffers written' , 'DBWR parallel query checkpoint buffers written' , 'DBWR object drop buffers written' , 'DBWR transaction table writes' , 'DBWR undo block writes' , 'DBWR revisited being-written buffer' , 'DBWR lru scans' , 'DBWR checkpoints' , 'DBWR fusion writes' , 'transaction tables consistent reads - undo records applied' , 'transaction tables consistent read rollbacks' ) and sid = ( select sid from gv$session where username = upper('&1') and client_info = 'TargetSession' ) order by 4, 1, 2 ; undefine 1

ちなみに、統計を使って状況を確認する方法って意外に利用されているんですよね。日本だとあまり活用されてないようにも感じることは多いのですが、日々の統計を追っかけてると、どのメトリックが高く跳ね上がるのか把握できるので知ってて損することはないと思います:)

そういえば、Tanel PoderのSnapperもその手のツールではありますね。
Session Snapper
http://tech.e2sn.com/oracle-scripts-and-tools/session-snapper

私の過去のセッションでもElappsed Timeを見せないでチューニング効果を見てもらうネタとしてシステム統計を使ってたりします。
db tech showcase Tokyo 2013 - A35 特濃JPOUG：潮溜まりでジャブジャブ、SQLチューニング
https://www.slideshare.net/discus_hamburg/db-tech-showcase-tokyo-2013-a35-sql

少々脱線しますが、
最近、VirtualBox、なつかしー。なんて言う方もいますが、古いバージョンのOracleを残しておけるので、リリース毎の動きの差などを見たい場合は便利なのですよーw（クラウドだと強制アップグレードされちゃうので旧バージョンとの動作比較をネタにしたいときなどには向いてないw）

次回へつづく

東京では救急車のサイレンがまだまだ通常より多く聞こえます。。。。

Stay home, Stay Safe and Stay Hydrated.

・古くて新しい？遅延ブロッククリーンアウト (deferred block cleanout) #1

投稿日時 2021年8月31日 (火) 12時00分 Oracle, PL/SQL, チューニング, FAQ, SQL, パフォーマンス, Oracle Database 19c | 固定リンク | 0 | コメント (0)

2021年8月23日 (月)

古くて新しい？遅延ブロッククリーンアウト (deferred block cleanout) #1

昔からOracle Database触ってると結構当たり前だったことではあるけど、最近、主にExadata以降にOraclerになったエンジニアへ伝承というかノウハウの一つとして継承されていないのかなー。
と感じることが何度かあり、属人化とは少々違う、失われた知識みたいなのもあるのかではないかと。。。そんなアトモスフィアを感じつつ、遅延ブロッククリーンアウトについて軽く書こうかなと。

と、今思ってるだけで、めんどくさくなって続かないかもしれませんw　

昔からある有名な遅延ブロッククリーンアウトの情報はMOSにもありますが、読んだことある方はどれぐらいいるのだろう。かなーーーり昔は日本独自？のMetalinkとかKROWNで細かく書かれていた（ような）記憶はあるが、最近はそこまで書かれてないような。。。まあいいかw

遅延ロギング・ブロック・クリーンアウトについて(KROWN:48106) (Doc ID 1716869.1)

こまけーことは置いといて、MOSとか、他のブログを読むと動きはざっくり理解できると思うのですが、

ポイントは、Buffer Cache サイズのおおよそ10%ぐらいまでがcommit時にクリーンアウトされる最大サイズ、それ以外は先送りされるというところ。
commit時にクリーンアウトされないので、後続のSQL文で該当するブロックがアクセスされたタイミングでタイミングでクリーンアウトされる。通常は更新を伴わないSELECT文でも発生する。そこで気づく方は多いわけです。はい。

SELECT文なのになんでREDOが生成されているんだろう？？？？　と。

例えば、Buffer Cacheが 10ブロック分あったとして、UPDATE文で5ブロック更新してcommitした場合、10ブロックの10%の1ブロックだけがcommit時にブロッククリーンアウトされ、残りの 4ブロックのクリーンアウトは遅延される。ざっくり言えばそんな感じ。
DMLでINSERT/DELETE/UPDATEでどのどの程度のブロックが更新されるかで、遅延されるブロック数はざっくり判断できしちゃいます。
ちなみに、どのタイミングでどの程度、クリーンアウトされたかという統計情報はあるが、トランザクションがcommitされたタイミングでどれぐらいクリーンアウトが遅延されたブロックが存在するかを示す統計はないので、どの程度の更新ブロックがあるかと、commit時にクリーンアウトできるブロック数の差分からざっくり判断するのがリーズナブル（他の流派の方もいるかもしれないがw）

OLTPのようなショートトランザクションでは、あまりクリーンアウトが先送りされることはないわけですが、ロングトランザクションでコミット１回というタイプだと、commit時にはブロックをクリーンアウトしきれない程度のブロックが更新され、クリーンアウトが遅延されるという状況は仕様どおりなわけです。。。。ロングトランザクションで発生しやすいということにはなりますね。（だったら、ぐるぐる系のバッチ更新処理って最高じゃね？、。。。それはちょっと。。。w　向かう方向が違うかなw）

話は少し代わりますが、前述のようにcommtのタイミングではBuffer Cacheの10%程度までなので、Buffer Cache を大きくすれば、commit時にクリーンアウトされる最大サイズも大きくなる。。。というのは簡単にイメージできると思います。。。

そして、遅延クリーンアウトブロックが発生しないケースがあるのご存知ですか？（知ってて損はないですよ。。）

以下のサイトで有益な情報を提供しているので一度は見ておくと良いと思います。

最近のOraclerは知らないかもしれないけど、AskTomでもTomが、遅延グロッククリーンアウトについて答えてます。　

このQAでのポイントは回答にある以下の部分、ここでも10 percent of our buffer cacheと言及されていますよね。これ2005のQAです。この頃まだ小学生だった方達が今Oraclerとしてデビューしてたりするわけですよねw　

”If we were to re-run the above example with the buffer cache set to hold at least 5,000 blocks, we'll find that we generate little to no redo on any of the SELECTs - we will not have to clean dirty blocks during either of our SELECT statements. This is because the 500 blocks we modified fit comfortably into 10 percent of our buffer cache, and we are the only user. There is no one else is mucking around with the data, and no one else is causing our data to be flushed to disk or accessing those blocks. In a live system, it will be normal for at least some of the blocks to not be cleaned out sometimes.”

Does select generate undo ? / AskTom / 2005

これは比較的新しいQAですね
delayed block cleanout / AskTom / 2017

レジェンド、ジョナサンルイスのブログでも
Clean it up　/ Jonathan Lewis / 2009

MaxGuage for Oracleで有名なエクセムさんのブログ

この記事で引用されているMetalinkは、現在のMOSには存在しないのでMOSのアカウントがあるかたが頑張って検索してもヒットしないのでご注意を。（日付が記載されていないので何年の記事かわからないですが、記事自体かなり古いはずなのでネタ元も古いと思ってください）
遅延ブロッククリーンアウト / エクセムさんのブログ

このブログでも10%ルールの話は出てきています。
Delayed Block Cleanout in Oracle / databasejournal By David Fitzjarrell / 2015

比喩がわかりにくいかもしれないけど、有名な Shit the Oracle さんのブログ　（このエントリーも日付がないけど、適当なタイミングでUpdateされているような、気がしないでもない）
遅延ブロッククリーンアウト / SHIFT-the-Oracle

以下、システムサポートさんのブログ、わかりやすいですよね。冒頭で少し紹介した遅延クリーンアウトブロックが発生しないケースにも軽くふれてますね。direct path writeしているケースに注目ですよ！
フルスキャンで何故シングルブロックリードが発生するのか？(2/2)

NTTDのOracle ACE 高橋さんもExadataでの遅延ブロッククリーンアウトの洗礼を受けた模様、比較的最近なのですね。　：）
exadataと遅延ブロッククリーンアウトとシングルブロックリード / オラクルデータベースの技術メモ

ブロックダンプしながら確認するなんて、マニアックですよね。w　このかた。前述のシステムサポートさんの記事で紹介されているdirect path writeのケースも検証されています。素敵です。
遅延ブロッククリーンアウトを観測する① / SQL*Plusの使いにくさは異常

ということで、私が書かなくても、これだけの情報があるので、書こうか書かないか、迷うーーーーっw。
紹介したエントリーの内容を確認するための方法こんな方法でも確認できるよー的な内容にしましょうかね。。。

では、Stay Home and Stay Safe.

次回へつづく。

投稿日時 2021年8月23日 (月) 18時07分 Oracle, チューニング, FAQ, SQL, パフォーマンス | 固定リンク | 0 | コメント (0)

2021年2月13日 (土)

実行計画は、SQL文のレントゲン写真だ！ No.30

OracleのResource Managerネタを書こう書こうと思いつつ類似ネタが他のブログでも扱われていることに気づきw
ネタを被らないようにしたいなぁとw　考えているうちにすでに2月の半ばw　もうすこし考えまするw

ということで、今回はこないだ、実行計画という名のレントゲンネタに絡んだtwitterのやりとりがあったついでなので、INSERTの実行計画をいくつか追加しておきます。

Oracleもバージョンが上がるごとに実行計画の改善やオペレーション名を変えたりするので古いバージョンだと、そんなオペレーション出なーーーい。ということもありますが、そんなオペレーションがでたら、こんな意味なんだぁ。

と理解しておけば裏でどう動いているかイメージしやすいのではないかと思います。それがイメージできていれば、もし、性能問題に絡んでいた時にはどう対処するのが良いか、助けになるとはずです (^^)

DIRECT PATH LOADING登場前のOracle Databaseでは気にする必要はなかったのですが、DIRECT PATHが行われるようになってから実行計画のOperationでDIRECT PATHとの区別がつきやすいように追加されたという微かな記憶があります。
（まちがっていたらコメントいただけますと m(_ _)m

ということで、実行計画の見てみましょう。INSERT文なので単純ですw　INSERTのoperationが（裏で）どう行われているかの違いです。
（以下の実行計画ではIASを利用して500MBほどの元表から同一定義の別表へ全データをINSERTしています）

LOAD TABLE CONVENTIONALというoperationが該当部分。　覚えておくと何かの役にはたつと思います！

この実行計画になるように以下のようにNOAPPENDヒントでdirect path writeを抑止しています。ヒントの使い方も覚えておくとなにかのときにや役立ちますよ:)
NO_GATHER_OPTIMIZER_STATISTICSヒントは今回の実行計画には直接関係ないリアルタイム統計の取得を抑止するヒントです。
19cのおそらく後半のリリースから従来型のDMLでもリアルタイム統計が取得されるようになったようです。この例ではじゃまなので抑止。

従来型のDMLでもリアルタイム統計が取得される https://docs.oracle.com/cd/F19136_01/tgsql/optimizer-statistics-concepts.html#GUID-769E609D-0312-43A7-9581-3F3EACF10BA9

Real-Time Statistics https://docs.oracle.com/en/database/oracle/oracle-database/19/dblic/Licensing-Information.html#GUID-0F9EB85D-4610-4EDF-89C2-4916A0E7AC87

INSERT /*+ MONITOR NOAPPEND NO_GATHER_OPTIMIZER_STATISTICS */ INTO hoge2 SELECT * FROM hoge ;

では、つづいて、direct path writeが動作した場合は該当部分のoperationはどうなるでしょうか？　:)

LOAD AS SELECT に変わったoperationが該当部分です！　operation は　LOAD AS SELECT　ですが、待機イベントは direct path write です。
どのようなoperationがどのような待機イベントに繋がるのかっていうのもおぼえておくと何かの役に立ちますよ ;)

実行したINSERT文のヒントがNOAPPPENDからAPPENDに変えてあることに注目。この例ではdirect path writeをヒントで強制しています。

INSERT /*+ MONITOR APPEND NO_GATHER_OPTIMIZER_STATISTICS */ INTO hoge2 SELECT * FROM hoge ;

最後に、NO_GATHER_OPTIMIZER_STATISTICS ヒントを外してリアルタイム統計取得が動いた場合にはどのようなoperationになるかみてみましょう。

OPTIMIZER STATISTICS GATHERING というoperationが現れました。これは19cの後半で追加された従来型DMLでのリアルタイム統計取得が動作した場合も現れるとマニュアルに記載されているoperationとも同一です。
direct path writeなのかによらず、リアルタイム統計取得の動作有無を確認するためにはこのoperationの有無をチェックする必要があります！

INSERT /*+ MONITOR APPEND */ INTO hoge2 SELECT * FROM hoge ;

なかなかよい、レントゲンコレクションが撮れたな　:)

Related article on Mac De Oracle
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 1 / TABLE FULL SCAN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 2 / INDEX UNIQUE SCAN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 3 / INDEX RANGE SCAN, Index Only Scan
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 4 / INDEX RANGE SCAN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 5 / INDEX RANGE SCAN, INLIST ITERATOR
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 6 / INDEX FAST SCAN, Index Only Scan
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 7 / INDEX FULL SCAN,Index Only Scan
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 8 / INDEX SKIP SCAN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 9 / TABLE ACCESS INMEMORY FULL
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 10 / NESTED LOOP JOIN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 11 / MERGE JOIN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 12 / HASH JOIN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 13 / HASH JOIN OUTER
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 14 / HASH JOIN FULL OUTER
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 15 / PX, TABLE ACCESS FULL
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 16 / CONCATENATION
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 17 / SORT UNIQUE, UNION-ALL = UNION
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 18 / UNION-ALL
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 19 / INTERSECTION
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 20 / MINUS
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 21 / WINDOW NOSORT STOPKEY
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 22 / COUNT STOPKEY
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 23 / HASH JOIN - LEFT-DEEP JOIN vs RIGHT-DEEP JOIN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 24 / CONNECT BY NO FILTERING WITH START-WITH
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 25 / UNION ALL (RECURSIVE WITH) DEPTH FIRST, RECURSIVE WITH PUMP
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#1 / STAR TRANSFORM, VECTOR TRANSFORM (DWH向け)
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#2 / MERGE (UPSERT)
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#3 / RDFView
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#4 / INDEX FULL SCAN (MIN/MAX) - Index Only Scan

投稿日時 2021年2月13日 (土) 16時07分 Oracle, チューニング, FAQ, SQL, Oracle Database 19c | 固定リンク | 0 | コメント (0)

2021年1月15日 (金)

SQL Macros / ほぼ理解した、つもり

SQL Macrosの使い道、ほぼ理解した:)

現在提供されている　Live SQL 20.4.2(19c 19.8.0.0.0)で実行可能であることを確認<

Oracle DatabaseのSQLマクロを検証する
https://qiita.com/nakaie/items/75358c3138328dd985c4

SQL Macros - Creating parameterised views
https://livesql.oracle.com/apex/livesql/file/tutorial_KQNYERE8ZF07EZMRR6KJ0RNIR.html<

他のRDBMSからの移行では効果ありそうな気はするが、DWH系かなぁ。MySQLやPostgreSQLから移行してくるのは多くはなさそうだし。
その逆となると色々考え混むわけだが、新機能なのでそこまで影響なさそうな気もする。

昔関わったプロジェクトで、PL/SQL禁止されていた記憶はある。そのようなプロジェクトだと即、禁止されそうな機能ではあるが、単純にSQL文が内部展開されるのだとすると書き換えは容易にかもしれない。内部的にどうなるのか現物が出てきてたら詳しく見ておきたいところ。

個人的に、こいつの使い道は、既存UDFの高速化などがメインになるのかなと、遠ーくをみて妄想しているところ:)
特にデータ量が膨大になればなるほど此の手のが効いてくるわけで。

投稿日時 2021年1月15日 (金) 11時28分 SQL, Oracle Database 19c, Live SQL, SQL Macro | 固定リンク | 0 | コメント (0)

2020年12月26日 (土)

標準はあるにはあるが癖の多いSQL 全部俺　おまけ SQL de 湯婆婆やるにも癖がでるw

恒例の標準はあるにはあるが癖の多いSQL 全部俺w Advent Calendar 2020のおまけですw

忙しすぎて、この手の遊びが疎かになっておりました。完全に乗り遅れておりましたが、湯婆婆やりましたw

スタジオジブリさん、「画像は常識の範囲でご自由にお使いください。」とのことでありがたく使わせていただきます！
https://www.ghibli.jp/works/chihiro/#frame

では、Oracle (19c)を使って、Oracle 湯婆婆　から
Advent Calendar 標準はあるにはあるが癖の多いSQL 全部俺でも登場したSUBSTR/DBMS_RANDOM.VALUEや文字列連結の違い。
それに、SQLスクリプトでインタラクティブにパラメータを渡せるかという点にも違いがあります。

SQL*Plus/psqlではインタラクティブにパラメータを渡せますが、mysqlにはなさそう（あったらコメントください）

インタラクティブにパラメータを渡せるSQL*Plus/psqlでは、それぞれ、ACCEPTや\promptなどで名前を入力しています。
mysqlでは仕方ないのでSETコマンドで設定する方法をとりました。

ORACLE> @ora_yubaba 契約書だよ。そこに名前を書きな。山田千尋湯婆婆 -------------------------------------------------------------------------------- フン山田千尋というのかい。贅沢な名だねぇ今からお前の名前は田だ。いいかい、田だよ。わかったら返事をするんだ、 !!

$ cat ora_yubaba.sql SET LINESIZE 80 SET TAB OFF SET VERIFY OFF ACCEPT fullname CHAR PROMPT '契約書だよ。そこに名前を書きな。' WITH yourname AS ( SELECT SUBSTR( '&&fullname' , DBMS_RANDOM.VALUE(1,LENGTH('&&fullname')), 1 ) AS newname FROM dual ) SELECT 'フン ' ||'&&fullname' ||' というのかい。贅沢な名だねぇ' ||CHR(13)||CHR(10) ||'今からお前の名前は ' ||newname ||' だ。いいかい、' ||newname ||' だよ。' ||CHR(13)||CHR(10)||'わかったら返事をするんだ、' ||CHR(13)||CHR(10)||'!!' AS "湯婆婆" FROM yourname; undefine fullname SET VERIFY ON

PostgreSQL (12)

次は、PostgreSQL 湯婆婆

postgres=> \i postgresql_yubaba.sql 契約書だよ。そこに名前を書きな : 山田千尋湯婆婆 ---------------------------------------------- フン　山田千尋というのかい。贅沢な名だねぇ + 今からお前の名は田　だ。いいかい、田だよ。+ わかったら返事をするんだ、 + !! (1 row)

$ cat postgresql_yubaba.sql \prompt '契約書だよ。そこに名前を書きな : ' fullname WITH yourname AS ( SELECT SUBSTR( :'fullname'::TEXT , CEIL(RANDOM() * LENGTH(:'fullname'::TEXT))::INTEGER, 1::INTEGER ) AS newname ) SELECT 'フン　' ||:'fullname' ||' というのかい。贅沢な名だねぇ' ||E'\n' ||'今からお前の名は ' ||newname ||'　だ。いいかい、' ||newname ||' だよ。' ||E'\n'||'わかったら返事をするんだ、' ||E'\n'||'!!' AS "湯婆婆" FROM yourname;

MySQL 8.0

最後に、MySQL 湯婆婆

mysql> SET @契約書だよ。そこに名前を書きな = '山田千尋'; Query OK, 0 rows affected (0.13 sec) mysql> \! vi mysql_yubaba.sql mysql> \. mysql_yubaba.sql Query OK, 0 rows affected (0.02 sec) *************************** 1. row *************************** 湯婆婆: フン　山田千尋というのかい。贅沢な名だねぇ今からお前の名は尋　だ。いいかい、尋だよ。わかったら返事をするんだ、 !! 1 row in set (0.02 sec)

$ cat mysql_yubaba.sql SET sql_mode = 'ANSI'; WITH yourname AS ( SELECT SUBSTRING( @契約書だよ。そこに名前を書きな , CEIL(RAND() * CHAR_LENGTH(@契約書だよ。そこに名前を書きな)), 1 ) AS newname ) SELECT 'フン　' ||@契約書だよ。そこに名前を書きな ||' というのかい。贅沢な名だねぇ' ||'\r\n' ||'今からお前の名は ' ||newname ||'　だ。いいかい、' ||newname ||' だよ。' ||'\r\n'||'わかったら返事をするんだ、' ||'\r\n'||'!!' AS "湯婆婆" FROM yourname\G

こういう遊びはみなさん好きですよね？　
では、また。

似たようなネタのエントリー
・Oracle de Fizzbuzz #1 -　いまごろ・・・ですが・・
・Oracle de Fizzbuzz #2
・Mac de Caché というか MUMPS というか Objectscript か - fizzbuzz
・PL/SQL de ケンブリッジ関数
・こんなのでいいのかなぁ。ズンドコキヨシ　　ObjectScript / MUMPS

・標準はあるにはあるが癖の多いSQL 全部俺　#1 Pagination
・標準はあるにはあるが癖の多いSQL 全部俺　#2 関数名は同じでも引数が逆の罠！
・標準はあるにはあるが癖の多いSQL 全部俺　#3 データ型確認したい時あるんです
・標準はあるにはあるが癖の多いSQL 全部俺　#4 リテラル値での除算の内部精度も違うのよ!
・標準はあるにはあるが癖の多いSQL 全部俺　#5 和暦変換機能ある方が少数派
・標準はあるにはあるが癖の多いSQL 全部俺　#6 時間厳守！
・標準はあるにはあるが癖の多いSQL 全部俺　#7 期間リテラル！
・標準はあるにはあるが癖の多いSQL 全部俺　#8 翌月末日って何日？
・標準はあるにはあるが癖の多いSQL 全部俺　#9 部分文字列の扱いでも癖が出る＞＜
・標準はあるにはあるが癖の多いSQL 全部俺　#10 文字列連結の罠（有名なやつ）
・標準はあるにはあるが癖の多いSQL 全部俺　#11 デュエル、じゃなくて、デュアル
・標準はあるにはあるが癖の多いSQL 全部俺　#12 文字[列]探すにも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#13 あると便利ですが意外となかったり
・標準はあるにはあるが癖の多いSQL 全部俺　#14 連番の集合を返すにも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#15 SQL command line client
・標準はあるにはあるが癖の多いSQL 全部俺　#16 SQLのレントゲンを撮る方法
・標準はあるにはあるが癖の多いSQL 全部俺　#17 その空白は許されないのか？
・標準はあるにはあるが癖の多いSQL 全部俺　#18 (+)の外部結合は方言
・標準はあるにはあるが癖の多いSQL 全部俺　#19 帰ってきた、部分文字列の扱いでも癖w
・標準はあるにはあるが癖の多いSQL 全部俺　#20 結果セットを単一列に連結するにも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#21 演算結果にも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#22 集合演算にも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#23 複数行INSERTにも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#24 乱数作るにも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#25 SQL de Fractalsにも癖がある:)

投稿日時 2020年12月26日 (土) 00時00分 Oracle, FAQ, SQL, MySQL, PostgreSQL, Advent Calendar | 固定リンク | 0 | コメント (0)

2020年12月25日 (金)

標準はあるにはあるが癖の多いSQL 全部俺　#25 SQL de Fractalsにも癖がある:)

標準はあるにはあるが癖の多いSQL 全部俺w Advent Calendar 2020の25日目です。

５年前にクリスマスのお遊び - SQL de Fractals :)というネタを書いてました。

EXPLAIN EXTENDED - Happy New Year!
元ネタは、ARRAY_TO_STRINGとARRAY_AGGの組み合わせ、とgenerate_seriesを利用した再帰問合せを利用したPostgreSQLバージョンのSQL

今であれば、以下のように書き換え、STRING_AGGでけにした方が良いのではないだろうか。
また、generate_series部分の方言の影響を最小にするのであれば、この部分も再帰問合せを利用した一連番号のセット生成にするなどの変更は可能ですね。

では、オリジナルのPostgreSQLの構文でARRAY_TO_STRINGとARRAY_AGGをSTRING_AGGに変更した例から（generate_seriesを階層再帰問合せにすることも可能）

PostgreSQL

WITH RECURSIVE q (r, i, rx, ix, g) AS ( SELECT r::DOUBLE PRECISION * 0.02 , i::DOUBLE PRECISION * 0.02 , .0::DOUBLE PRECISION , .0::DOUBLE PRECISION , 0 FROM generate_series(-60, 20) r , generate_series(-50, 50) i UNION ALL SELECT r , i , CASE WHEN ABS(rx * rx + ix * ix) <= 2 THEN rx * rx - ix * ix END + r , CASE WHEN ABS(rx * rx + ix * ix) <= 2 THEN 2 * rx * ix END + i , g + 1 FROM q WHERE rx IS NOT NULL AND g < 99 ) SELECT STRING_AGG(s, '' ORDER BY r) AS Mandelbrot FROM ( SELECT i, r, SUBSTRING(' .:-=+*#%@', MAX(g) / 10 + 1, 1) s FROM q GROUP BY i, r ) q GROUP BY i ORDER BY i;

Oracle

では、上記、非互換の多いSQLをOracle向けに書き換えてみましょう。一連番号生成はOracleの方言である階層問合せにしてあります。あえてw
また、PostgreSQLのSTRING_AGG部分は、OracleのLISTAGGで代替しています。

WITH q (r, i, rx, ix, g) AS ( SELECT CAST(r.r AS DOUBLE PRECISION) * 0.02 AS r , CAST(i.i AS DOUBLE PRECISION) * 0.02 AS i , CAST(.0 AS DOUBLE PRECISION) AS rx , CAST(.0 AS DOUBLE PRECISION) AS ix , 0 AS g FROM ( SELECT LEVEL - 61 AS r FROM DUAL CONNECT BY LEVEL <= 80 ) r, ( SELECT LEVEL - 51 AS i FROM DUAL CONNECT BY LEVEL <= 100 ) i UNION ALL SELECT r , i , CASE WHEN ABS(rx * rx + ix * ix) <= 2 THEN rx * rx - ix * ix END + r AS rx , CASE WHEN ABS(rx * rx + ix * ix) <= 2 THEN 2 * rx * ix END + i AS ix , g + 1 AS g FROM q WHERE rx IS NOT NULL AND g < 99 ) SELECT LISTAGG(s,'') WITHIN GROUP ( ORDER BY r ) AS Mandelbrot FROM ( SELECT i, r, SUBSTR(' .:-=+*#%@', MAX(g) / 10 + 1, 1) s FROM q GROUP BY i, r ) q GROUP BY i ORDER BY i;

MySQL 8.0

さて、最後は、これまで一連番号生成が辛かったMySQLです。
MySQL 8.0から再帰問合せが利用できるようになったおかげてMySQLのSQLでもこんな遊びができるようになりました！！！！

すげーーーーーーーっ！

再帰問合せを駆使し、PostgreSQLのSTRING_AGG、OracleのLISTAGGの代替としてGROUP_CONCAT関数を利用しています。
部分文字列はSUBSTRINGですね。
そしてもう一つの非互換対応が　TRUNCATE(MAX(g) / 10 + 1, 0)　部分です。
OracleとPostgreSQLは　MAX(g) / 10 + 1　だけでも問題ないですが、MySQLでは MAX(g) / 10 + 1　の結果は整数にはなりません。
その対策としてTRUNCATEを追加しています。

なかなか痺れますね。これまで紹介してきた非互換対応の総まとめは大げさですが、それらを有効に組み合わせて書き換えてみました。

WITH RECURSIVE q (r, i, rx, ix, g) AS ( SELECT CAST(r.v AS DOUBLE PRECISION) * 0.02 AS r , CAST(i.v AS DOUBLE PRECISION) * 0.02 AS i , CAST(0.0 AS DOUBLE PRECISION) AS rx , CAST(0.0 AS DOUBLE PRECISION) AS ix , 0 AS g FROM ( WITH RECURSIVE gen_nums(v) AS ( SELECT -60 UNION ALL SELECT v + 1 FROM gen_nums WHERE v + 1 < 20 ) SELECT v from gen_nums ) r ,( WITH RECURSIVE gen_nums(v) AS ( SELECT -50 UNION ALL SELECT v + 1 FROM gen_nums WHERE v + 1 < 50 ) SELECT v from gen_nums ) i UNION ALL SELECT CAST(r AS DOUBLE PRECISION) AS r , CAST(i AS DOUBLE PRECISION) AS i , CAST( CASE WHEN ABS(rx * rx + ix * ix) <= 2 THEN rx * rx - ix * ix END + r AS DOUBLE PRECISION ) AS rx , CAST( CASE WHEN ABS(rx * rx + ix * ix) <= 2 THEN 2 * rx * ix END + i AS DOUBLE PRECISION ) AS ix , g + 1 AS g FROM q WHERE rx IS NOT NULL AND g < 99 ) SELECT GROUP_CONCAT(s,'' ORDER BY r SEPARATOR '') AS Mandelbrot FROM ( SELECT i, r, SUBSTRING(' .:-=+*#%@', TRUNCATE(MAX(g) / 10 + 1, 0), 1) s FROM q GROUP BY i, r ) q GROUP BY q.i ORDER BY q.i;

ちなみに、Redshiftは再帰的なCTEは現時点では未サポートなので再帰問合せが必要なお遊びは今のところできません。

Amazon Redshift - サポートされていないPostgreSQL機能
https://docs.aws.amazon.com/ja_jp/redshift/latest/dg/c_unsupported-postgresql-features.html

さてさて、なんとか25個の窓を開けることができました。

今年は、コロナ禍の中、大変厳しい一年になりましたが、みなさま、お身体を大事に、そして、ご家族と過ごす時間を大切に。

メリークリスマス。（何年か前に作った Pipeline function で christmas treeのムービーで）

・標準はあるにはあるが癖の多いSQL 全部俺　#1 Pagination
・標準はあるにはあるが癖の多いSQL 全部俺　#2 関数名は同じでも引数が逆の罠！
・標準はあるにはあるが癖の多いSQL 全部俺　#3 データ型確認したい時あるんです
・標準はあるにはあるが癖の多いSQL 全部俺　#4 リテラル値での除算の内部精度も違うのよ!
・標準はあるにはあるが癖の多いSQL 全部俺　#5 和暦変換機能ある方が少数派
・標準はあるにはあるが癖の多いSQL 全部俺　#6 時間厳守！
・標準はあるにはあるが癖の多いSQL 全部俺　#7 期間リテラル！
・標準はあるにはあるが癖の多いSQL 全部俺　#8 翌月末日って何日？
・標準はあるにはあるが癖の多いSQL 全部俺　#9 部分文字列の扱いでも癖が出る＞＜
・標準はあるにはあるが癖の多いSQL 全部俺　#10 文字列連結の罠（有名なやつ）
・標準はあるにはあるが癖の多いSQL 全部俺　#11 デュエル、じゃなくて、デュアル
・標準はあるにはあるが癖の多いSQL 全部俺　#12 文字[列]探すにも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#13 あると便利ですが意外となかったり
・標準はあるにはあるが癖の多いSQL 全部俺　#14 連番の集合を返すにも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#15 SQL command line client
・標準はあるにはあるが癖の多いSQL 全部俺　#16 SQLのレントゲンを撮る方法
・標準はあるにはあるが癖の多いSQL 全部俺　#17 その空白は許されないのか？
・標準はあるにはあるが癖の多いSQL 全部俺　#18 (+)の外部結合は方言
・標準はあるにはあるが癖の多いSQL 全部俺　#19 帰ってきた、部分文字列の扱いでも癖w
・標準はあるにはあるが癖の多いSQL 全部俺　#20 結果セットを単一列に連結するにも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#21 演算結果にも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#22 集合演算にも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#23 複数行INSERTにも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#24 乱数作るにも癖がある

投稿日時 2020年12月25日 (金) 00時00分 Oracle, FAQ, SQL, MySQL, PostgreSQL, Advent Calendar, AWS | 固定リンク | 0 | コメント (0)

2020年12月24日 (木)

標準はあるにはあるが癖の多いSQL 全部俺　#24 乱数作るにも癖がある

標準はあるにはあるが癖の多いSQL 全部俺w Advent Calendar 2020の24日目です。

たまに、乱数が必要になることがあるのですが、その乱数生成にも癖があるんですよね。

簡単ですが今日はこれぐらいでw　（ラストスパートで息切れ中w

いつものようにOracleから

131.4 DBMS_RANDOMサブプログラムの要約
131.4.7 VALUEファンクション
https://docs.oracle.com/cd/F19136_01/arpls/DBMS_RANDOM.html#GUID-AAD9E936-D74F-440D-9E16-24F3F0DE8D31

Oracleの場合は組み込み関数ではなく、パッケージ関数として提供されています。この点が大きな違いですよね。

ORACLE> SELECT (DBMS_RANDOM.VALUE(1,10)) FROM dual; (DBMS_RANDOM.VALUE(1,10)) ------------------------- 3.37937063 ORACLE> SELECT DBMS_RANDOM.VALUE FROM dual; VALUE ---------- .853380477

PostgreSQL

表9.6 乱数関数
https://www.postgresql.jp/document/12/html/functions-math.html

postgres=> select random(); random ------------------- 0.774311667308211 (1 row)

MySQL

三者三様で皆関数名も違ったり、提供されている機能も差がありますね。

RAND([N])
https://dev.mysql.com/doc/refman/8.0/en/mathematical-functions.html#function_rand

mysql> select rand(); +--------------------+ | rand() | +--------------------+ | 0.6516789492700984 | +--------------------+ 1 row in set (0.06 sec)

クリスマス、何食べようか考えているところで、年越しそば予約してないことに気づくw　（なんとかなるさw

・標準はあるにはあるが癖の多いSQL 全部俺　#1 Pagination
・標準はあるにはあるが癖の多いSQL 全部俺　#2 関数名は同じでも引数が逆の罠！
・標準はあるにはあるが癖の多いSQL 全部俺　#3 データ型確認したい時あるんです
・標準はあるにはあるが癖の多いSQL 全部俺　#4 リテラル値での除算の内部精度も違うのよ!
・標準はあるにはあるが癖の多いSQL 全部俺　#5 和暦変換機能ある方が少数派
・標準はあるにはあるが癖の多いSQL 全部俺　#6 時間厳守！
・標準はあるにはあるが癖の多いSQL 全部俺　#7 期間リテラル！
・標準はあるにはあるが癖の多いSQL 全部俺　#8 翌月末日って何日？
・標準はあるにはあるが癖の多いSQL 全部俺　#9 部分文字列の扱いでも癖が出る＞＜
・標準はあるにはあるが癖の多いSQL 全部俺　#10 文字列連結の罠（有名なやつ）
・標準はあるにはあるが癖の多いSQL 全部俺　#11 デュエル、じゃなくて、デュアル
・標準はあるにはあるが癖の多いSQL 全部俺　#12 文字[列]探すにも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#13 あると便利ですが意外となかったり
・標準はあるにはあるが癖の多いSQL 全部俺　#14 連番の集合を返すにも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#15 SQL command line client
・標準はあるにはあるが癖の多いSQL 全部俺　#16 SQLのレントゲンを撮る方法
・標準はあるにはあるが癖の多いSQL 全部俺　#17 その空白は許されないのか？
・標準はあるにはあるが癖の多いSQL 全部俺　#18 (+)の外部結合は方言
・標準はあるにはあるが癖の多いSQL 全部俺　#19 帰ってきた、部分文字列の扱いでも癖w
・標準はあるにはあるが癖の多いSQL 全部俺　#20 結果セットを単一列に連結するにも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#21 演算結果にも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#22 集合演算にも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#23 複数行INSERTにも癖がある

投稿日時 2020年12月24日 (木) 00時00分 Oracle, FAQ, SQL, MySQL, PostgreSQL, Advent Calendar | 固定リンク | 0 | コメント (0)

2020年12月23日 (水)

標準はあるにはあるが癖の多いSQL 全部俺　#23 複数行INSERTにも癖がある

標準はあるにはあるが癖の多いSQL 全部俺w Advent Calendar 2020の23日目です。

クリスマスイブイブですね。なんとかここまできたw

ネタ尽きた感がなくもないですが、ほぼ使っている方はいないのではないかという、複数行INSERTにも癖があるというお話

では、Oracleからみてください

Oracle

INESRT
https://docs.oracle.com/cd/F19136_01/sqlrf/INSERT.html#GUID-903F8043-0254-4EE9-ACC1-CB8AC0AF3423

この構文実は、マルチテーブルインサートの変形パターンで同一表へ複数インサートするようにしたもの。。。
そもそもこの構文が方言ではあるのですが、。。。。

ORACLE> desc a Name Null? Type ----------------------------------------- -------- ---------------------------- ID NUMBER STR VARCHAR2(100) ORACLE> INSERT ALL 2 INTO a VALUES(2,'yama') 3 INTO a VALUES(3,'kawa') 4 INTO a VALUES(4,'umi') 5 SELECT * FROM dual;

PostgreSQL

PostgreSQLにはやはりない。そりゃ、Oracleの方言だからねw　ですが、一応同一表なら可能です。

INSERT
https://www.postgresql.jp/document/12/html/sql-insert.html

同じく、MySQLも同一構文。。。。

postgres=> \d a Table "bill.a" Column | Type | Collation | Nullable | Default --------+------------------------+-----------+----------+--------- id | integer | | | str | character varying(100) | | | postgres=> postgres=> INSERT postgres-> INTO a VALUES postgres-> (2,'yama') postgres-> ,(3,'kawa') postgres-> ,(4,'umi'); INSERT 0 3

MySQL(8.0)

INSERT
https://dev.mysql.com/doc/refman/8.0/en/insert.html

mysql> desc a; +-------+--------------+------+-----+---------+-------+ | Field | Type | Null | Key | Default | Extra | +-------+--------------+------+-----+---------+-------+ | id | int | YES | | NULL | | | str | varchar(100) | YES | | NULL | | +-------+--------------+------+-----+---------+-------+ 2 rows in set (0.02 sec) mysql> INSERT -> INTO a VALUES -> (2,'yama') -> ,(3,'kawa') -> ,(4,'umi'); Query OK, 3 rows affected (0.07 sec) Records: 3 Duplicates: 0 Warnings: 0

クリスマスイブのネタ何にしよう。本気で浮かばないw　（最終日のネタはほぼできているのにw）

・標準はあるにはあるが癖の多いSQL 全部俺　#1 Pagination
・標準はあるにはあるが癖の多いSQL 全部俺　#2 関数名は同じでも引数が逆の罠！
・標準はあるにはあるが癖の多いSQL 全部俺　#3 データ型確認したい時あるんです
・標準はあるにはあるが癖の多いSQL 全部俺　#4 リテラル値での除算の内部精度も違うのよ!
・標準はあるにはあるが癖の多いSQL 全部俺　#5 和暦変換機能ある方が少数派
・標準はあるにはあるが癖の多いSQL 全部俺　#6 時間厳守！
・標準はあるにはあるが癖の多いSQL 全部俺　#7 期間リテラル！
・標準はあるにはあるが癖の多いSQL 全部俺　#8 翌月末日って何日？
・標準はあるにはあるが癖の多いSQL 全部俺　#9 部分文字列の扱いでも癖が出る＞＜
・標準はあるにはあるが癖の多いSQL 全部俺　#10 文字列連結の罠（有名なやつ）
・標準はあるにはあるが癖の多いSQL 全部俺　#11 デュエル、じゃなくて、デュアル
・標準はあるにはあるが癖の多いSQL 全部俺　#12 文字[列]探すにも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#13 あると便利ですが意外となかったり
・標準はあるにはあるが癖の多いSQL 全部俺　#14 連番の集合を返すにも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#15 SQL command line client
・標準はあるにはあるが癖の多いSQL 全部俺　#16 SQLのレントゲンを撮る方法
・標準はあるにはあるが癖の多いSQL 全部俺　#17 その空白は許されないのか？
・標準はあるにはあるが癖の多いSQL 全部俺　#18 (+)の外部結合は方言
・標準はあるにはあるが癖の多いSQL 全部俺　#19 帰ってきた、部分文字列の扱いでも癖w
・標準はあるにはあるが癖の多いSQL 全部俺　#20 結果セットを単一列に連結するにも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#21 演算結果にも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#22 集合演算にも癖がある
・

投稿日時 2020年12月23日 (水) 00時00分 Oracle, FAQ, SQL, MySQL, PostgreSQL, Advent Calendar | 固定リンク | 0 | コメント (0)

2020年12月22日 (火)

標準はあるにはあるが癖の多いSQL 全部俺　#22 集合演算にも癖がある

標準はあるにはあるが癖の多いSQL 全部俺w Advent Calendar 2020の22日目です。

さて、残すところ、今日をいれてあと4回

なんとなくネタが１つ足りてない気がするがw　なんとかするw

ということで、集合演算の癖を見てみましょう。Oracle 20cがリリースされていたら試せた機能もありますが、使える環境がないので、マニュアルだけ貼っておきます。

Oracle 20c - SQL set演算子の拡張 - union [all] / minus [all] / intersect [all] / except[all]
https://docs.oracle.com/cd/F32587_01/ftnew/enhanced-sql-set-operators1.html

19cまではこんな感じ

Oracle 19c - UNION [ALL]、INTERSECTおよびMINUS演算子
https://docs.oracle.com/cd/F19136_01/sqlrf/The-UNION-ALL-INTERSECT-MINUS-Operators.html#GUID-B64FE747-586E-4513-945F-80CB197125EE

MINUSはOracleの方言です。そのうちシノニム扱いされて、EXCEPTが一般的に利用されることになっていくのでしょうね。

Oracle

ORACLE> r 1 SELECT * 2 FROM 3 ( 4 WITH gen_nums(v) 5 AS 6 ( 7 SELECT 1 8 FROM 9 dual 10 UNION ALL 11 SELECT v + 1 12 FROM 13 gen_nums 14 WHERE v + 1 <= 10 15 ) 16 SELECT v FROM gen_nums 17 ) 18 UNION 19 SELECT * 20 FROM 21 ( 22 WITH gen_nums(v) 23 AS 24 ( 25 SELECT 5 26 FROM 27 dual 28 UNION ALL 29 SELECT v + 1 30 FROM 31 gen_nums 32 WHERE v + 1 <= 15 33 ) 34 SELECT v FROM gen_nums 35 ) 36* ORDER BY 1 V ---------- 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 15 rows selected. ORACLE> r 1 SELECT * 2 FROM 3 ( 4 WITH gen_nums(v) 5 AS 6 ( 7 SELECT 1 8 FROM 9 dual 10 UNION ALL 11 SELECT v + 1 12 FROM 13 gen_nums 14 WHERE v + 1 <= 10 15 ) 16 SELECT v FROM gen_nums 17 ) 18 UNION ALL 19 SELECT * 20 FROM 21 ( 22 WITH gen_nums(v) 23 AS 24 ( 25 SELECT 5 26 FROM 27 dual 28 UNION ALL 29 ELECT v + 1 30 FROM 31 gen_nums 32 WHERE v + 1 <= 15 33 ) 34 SELECT v FROM gen_nums 35 ) 36* ORDER BY 1 V ---------- 1 2 3 4 5 5 6 6 7 7 8 8 9 9 10 10 11 12 13 14 15 21 rows selected. ORACLE> r 1 SELECT * 2 FROM 3 ( 4 WITH gen_nums(v) 5 AS 6 ( 7 SELECT 1 8 FROM 9 dual 10 UNION ALL 11 SELECT v + 1 12 FROM 13 gen_nums 14 WHERE v + 1 <= 10 15 ) 16 SELECT v FROM gen_nums 17 ) 18 INTERSECT 19 SELECT * 20 FROM 21 ( 22 WITH gen_nums(v) 23 AS 24 ( 25 SELECT 5 26 FROM 27 dual 28 UNION ALL 29 SELECT v + 1 30 FROM 31 gen_nums 32 WHERE v + 1 <= 15 33 ) 34 SELECT v FROM gen_nums 35 ) 36* ORDER BY 1 V ---------- 5 6 7 8 9 10 6 rows selected. ORACLE> r 1 SELECT * 2 FROM 3 ( 4 WITH gen_nums(v) 5 AS 6 ( 7 SELECT 1 8 FROM 9 dual 10 UNION ALL 11 SELECT v + 1 12 FROM 13 gen_nums 14 WHERE v + 1 <= 10 15 ) 16 SELECT v FROM gen_nums 17 ) 18 MINUS 19 SELECT * 20 FROM 21 ( 22 WITH gen_nums(v) 23 AS 24 ( 25 SELECT 5 26 FROM 27 dual 28 UNION ALL 29 SELECT v + 1 30 FROM 31 gen_nums 32 WHERE v + 1 <= 15 33 ) 34 SELECT v FROM gen_nums 35 ) 36* ORDER BY 1 V ---------- 1 2 3 4

PostgreSQL

union [all] / intersect[all] / except[all]
https://www.postgresql.jp/document/12/html/queries-union.html

これらの構文に関しては、PostgreSQLの方が一歩先でしたね：）

Oracle 20c以降ではこんなことができるようになるよ、というイメージをPostgreSQLで掴んでおくと良いかもしれないですねー

postgres=> SELECT * postgres-> FROM postgres-> ( postgres(> WITH RECURSIVE gen_nums(v) postgres(> AS postgres(> ( postgres(> SELECT 1 postgres(> UNION ALL postgres(> SELECT v + 1 postgres(> FROM postgres(> gen_nums postgres(> WHERE v + 1 <= 10 postgres(> ) postgres(> SELECT v FROM gen_nums postgres(> ) a postgres-> UNION postgres-> SELECT * postgres-> FROM postgres-> ( postgres(> WITH RECURSIVE gen_nums(v) postgres(> AS postgres(> ( postgres(> SELECT 5 postgres(> UNION ALL postgres(> SELECT v + 1 postgres(> FROM postgres(> gen_nums postgres(> WHERE v + 1 <= 15 postgres(> ) postgres(> SELECT v FROM gen_nums postgres(> ) b postgres-> ORDER BY 1; v ---- 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 (15 rows) postgres=> SELECT * postgres-> FROM postgres-> ( postgres(> WITH RECURSIVE gen_nums(v) postgres(> AS postgres(> ( postgres(> SELECT 1 postgres(> UNION ALL postgres(> SELECT v + 1 postgres(> FROM postgres(> gen_nums postgres(> WHERE v + 1 <= 10 postgres(> ) postgres(> SELECT v FROM gen_nums postgres(> ) a postgres-> UNION ALL postgres-> SELECT * postgres-> FROM postgres-> ( postgres(> WITH RECURSIVE gen_nums(v) postgres(> AS postgres(> ( postgres(> SELECT 5 postgres(> UNION ALL postgres(> SELECT v + 1 postgres(> FROM postgres(> gen_nums postgres(> WHERE v + 1 <= 15 postgres(> ) postgres(> SELECT v FROM gen_nums postgres(> ) b postgres-> ORDER BY 1; v ---- 1 2 3 4 5 5 6 6 7 7 8 8 9 9 10 10 11 12 13 14 15 (21 rows) postgres=> SELECT * postgres-> FROM postgres-> ( postgres(> WITH RECURSIVE gen_nums(v) postgres(> AS postgres(> ( postgres(> SELECT 1 postgres(> UNION ALL postgres(> SELECT v + 1 postgres(> FROM postgres(> gen_nums postgres(> WHERE v + 1 <= 10 postgres(> ) postgres(> SELECT v FROM gen_nums postgres(> ) a postgres-> INTERSECT postgres-> SELECT * postgres-> FROM postgres-> ( postgres(> WITH RECURSIVE gen_nums(v) postgres(> AS postgres(> ( postgres(> SELECT 5 postgres(> UNION ALL postgres(> SELECT v + 1 postgres(> FROM postgres(> gen_nums postgres(> WHERE v + 1 <= 15 postgres(> ) postgres(> SELECT v FROM gen_nums postgres(> ) b postgres-> ORDER BY 1; v ---- 5 6 7 8 9 10 (6 rows) postgres=> SELECT * postgres-> FROM postgres-> ( postgres(> WITH RECURSIVE gen_nums(v) postgres(> AS postgres(> ( postgres(> SELECT 1 postgres(> UNION ALL postgres(> SELECT v + 1 postgres(> FROM postgres(> gen_nums postgres(> WHERE v + 1 <= 10 postgres(> ) postgres(> SELECT v FROM gen_nums postgres(> ) a postgres-> INTERSECT ALL postgres-> SELECT * postgres-> FROM postgres-> ( postgres(> WITH RECURSIVE gen_nums(v) postgres(> AS postgres(> ( postgres(> SELECT 5 postgres(> UNION ALL postgres(> SELECT v + 1 postgres(> FROM postgres(> gen_nums postgres(> WHERE v + 1 <= 15 postgres(> ) postgres(> SELECT v FROM gen_nums postgres(> ) b postgres-> ORDER BY 1; v ---- 5 6 7 8 9 10 (6 rows) postgres=> SELECT * postgres-> FROM postgres-> ( postgres(> WITH RECURSIVE gen_nums(v) postgres(> AS postgres(> ( postgres(> SELECT 1 postgres(> UNION ALL postgres(> SELECT v + 1 postgres(> FROM postgres(> gen_nums postgres(> WHERE v + 1 <= 10 postgres(> ) postgres(> SELECT v FROM gen_nums postgres(> ) a postgres-> EXCEPT postgres-> SELECT * postgres-> FROM postgres-> ( postgres(> WITH RECURSIVE gen_nums(v) postgres(> AS postgres(> ( postgres(> SELECT 5 postgres(> UNION ALL postgres(> SELECT v + 1 postgres(> FROM postgres(> gen_nums postgres(> WHERE v + 1 <= 15 postgres(> ) postgres(> SELECT v FROM gen_nums postgres(> ) b postgres-> ORDER BY 1; v --- 1 2 3 4 (4 rows) postgres=> SELECT * postgres-> FROM postgres-> ( postgres(> WITH RECURSIVE gen_nums(v) postgres(> AS postgres(> ( postgres(> SELECT 1 postgres(> UNION ALL postgres(> SELECT v + 1 postgres(> FROM postgres(> gen_nums postgres(> WHERE v + 1 <= 10 postgres(> ) postgres(> SELECT v FROM gen_nums postgres(> ) a postgres-> EXCEPT ALL postgres-> SELECT * postgres-> FROM postgres-> ( postgres(> WITH RECURSIVE gen_nums(v) postgres(> AS postgres(> ( postgres(> SELECT 5 postgres(> UNION ALL postgres(> SELECT v + 1 postgres(> FROM postgres(> gen_nums postgres(> WHERE v + 1 <= 15 postgres(> ) postgres(> SELECT v FROM gen_nums postgres(> ) b postgres-> ORDER BY 1; v --- 1 2 3 4 (4 rows)

MySQL (8.0)

union [all]

13.2.10.3 UNION Clause
https://dev.mysql.com/doc/refman/8.0/en/union.html

MySQLはこれらの部分では少々遅れてますね。実際同じ結果を得ようとすると工夫しないといけないです。
これまで実装されてこなかったということは、恐そのような用途で利用されることが少なかったということなのでしょうか。（想像でしかないけど。。なんとなく今後は実装されそうな方向に向かっているような雰囲気も感じつつ。）

mysql> SELECT * -> FROM -> ( -> WITH RECURSIVE gen_nums(v) -> AS -> ( -> SELECT 1 -> UNION ALL -> SELECT v + 1 -> FROM -> gen_nums -> WHERE v + 1 <= 10 -> ) -> SELECT v FROM gen_nums -> ) a -> UNION -> SELECT * -> FROM -> ( -> WITH RECURSIVE gen_nums(v) -> AS -> ( -> SELECT 5 -> UNION ALL -> SELECT v + 1 -> FROM -> gen_nums -> WHERE v + 1 <= 15 -> ) -> SELECT v FROM gen_nums -> ) b -> ORDER BY 1; +------+ | v | +------+ | 1 | | 2 | | 3 | | 4 | | 5 | | 6 | | 7 | | 8 | | 9 | | 10 | | 11 | | 12 | | 13 | | 14 | | 15 | +------+ 15 rows in set (0.02 sec) mysql> SELECT * -> FROM -> ( -> WITH RECURSIVE gen_nums(v) -> AS -> ( -> SELECT 1 -> UNION ALL -> SELECT v + 1 -> FROM -> gen_nums -> WHERE v + 1 <= 10 -> ) -> SELECT v FROM gen_nums -> ) a -> UNION ALL -> SELECT * -> FROM -> ( -> WITH RECURSIVE gen_nums(v) -> AS -> ( -> SELECT 5 -> UNION ALL -> SELECT v + 1 -> FROM -> gen_nums -> WHERE v + 1 <= 15 -> ) -> SELECT v FROM gen_nums -> ) b -> ORDER BY 1; +------+ | v | +------+ | 1 | | 2 | | 3 | | 4 | | 5 | | 5 | | 6 | | 6 | | 7 | | 7 | | 8 | | 8 | | 9 | | 9 | | 10 | | 10 | | 11 | | 12 | | 13 | | 14 | | 15 | +------+ 21 rows in set (0.02 sec)

来年は全部俺、どうするかな。ネタの一気放出みたいな時間取りやすければいいんだけど。先週までは本気で辛かった。時間ギリギリでw

・標準はあるにはあるが癖の多いSQL 全部俺　#1 Pagination
・標準はあるにはあるが癖の多いSQL 全部俺　#2 関数名は同じでも引数が逆の罠！
・標準はあるにはあるが癖の多いSQL 全部俺　#3 データ型確認したい時あるんです
・標準はあるにはあるが癖の多いSQL 全部俺　#4 リテラル値での除算の内部精度も違うのよ!
・標準はあるにはあるが癖の多いSQL 全部俺　#5 和暦変換機能ある方が少数派
・標準はあるにはあるが癖の多いSQL 全部俺　#6 時間厳守！
・標準はあるにはあるが癖の多いSQL 全部俺　#7 期間リテラル！
・標準はあるにはあるが癖の多いSQL 全部俺　#8 翌月末日って何日？
・標準はあるにはあるが癖の多いSQL 全部俺　#9 部分文字列の扱いでも癖が出る＞＜
・標準はあるにはあるが癖の多いSQL 全部俺　#10 文字列連結の罠（有名なやつ）
・標準はあるにはあるが癖の多いSQL 全部俺　#11 デュエル、じゃなくて、デュアル
・標準はあるにはあるが癖の多いSQL 全部俺　#12 文字[列]探すにも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#13 あると便利ですが意外となかったり
・標準はあるにはあるが癖の多いSQL 全部俺　#14 連番の集合を返すにも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#15 SQL command line client
・標準はあるにはあるが癖の多いSQL 全部俺　#16 SQLのレントゲンを撮る方法
・標準はあるにはあるが癖の多いSQL 全部俺　#17 その空白は許されないのか？
・標準はあるにはあるが癖の多いSQL 全部俺　#18 (+)の外部結合は方言
・標準はあるにはあるが癖の多いSQL 全部俺　#19 帰ってきた、部分文字列の扱いでも癖w
・標準はあるにはあるが癖の多いSQL 全部俺　#20 結果セットを単一列に連結するにも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#21 演算結果にも癖がある

投稿日時 2020年12月22日 (火) 00時00分 Oracle, FAQ, SQL, MySQL, PostgreSQL, Advent Calendar | 固定リンク | 0 | コメント (0)

2020年12月21日 (月)

標準はあるにはあるが癖の多いSQL 全部俺　#21 演算結果にも癖がある

標準はあるにはあるが癖の多いSQL 全部俺w Advent Calendar 2020の21日目です。

以前取り上げた内容にも近いですが、演算だけに着目した方がわかりやすいだろうということでネタにしてみました。

SQLを移植する場合は、このようなところでも注意しないと。。。ね。デフォルトの挙動に任せたままでは危険ですね

Oracle

ORACLE> SELECT 1 / 3 FROM dual; 1/3 ---------- .333333333 ORACLE> SELECT 1 / 3 * 3 FROM dual; 1/3*3 ---------- 1 ORACLE> SELECT (1 / 3) * 3 FROM dual; (1/3)*3 ---------- 1 ORACLE> SELECT CAST(1 AS DOUBLE PRECISION) / CAST(3 AS DOUBLE PRECISION) * CAST(3 AS DOUBLE PRECISION) FROM dual; CAST(1ASDOUBLEPRECISION)/CAST(3ASDOUBLEPRECISION)*CAST(3ASDOUBLEPRECISION) -------------------------------------------------------------------------- 1 ORACLE> SELECT DUMP(CAST(1 AS DOUBLE PRECISION) / CAST(3 AS DOUBLE PRECISION)) FROM dual; DUMP(CAST(1ASDOUBLEPRECISION)/CAST(3ASDOUBLEPRECISION)) -------------------------------------------------------------------------------- Typ=2 Len=21: 192,34,34,34,34,34,34,34,34,34,34,34,34,34,34,34,34,34,34,34,34 ORACLE> SELECT DUMP(CAST(1 AS DOUBLE PRECISION) / CAST(3 AS DOUBLE PRECISION) * CAST(3 AS DOUBLE PRECISION)) FROM dual; DUMP(CAST(1ASDOUBLEPRECISION)/CAST(3ASDOUBLEPRECISION)*CAST(3ASDOUBLEPRECISION)) -------------------------------------------------------------------------------- Typ=2 Len=21: 192,100,100,100,100,100,100,100,100,100,100,100,100,100,100,100,10 0,100,100,100,100

MySQL

Oracleに近いですが、若干差異がありますね。

mysql> SELECT 1 / 3; +--------+ | 1 / 3 | +--------+ | 0.3333 | +--------+ 1 row in set (0.02 sec) mysql> SELECT 1 / 3 * 3; +-----------+ | 1 / 3 * 3 | +-----------+ | 1.0000 | +-----------+ 1 row in set (0.02 sec) mysql> SELECT CAST(1 AS DOUBLE PRECISION) / 3 * 3; +---------------------------+ | cast(1 as double) / 3 * 3 | +---------------------------+ | 1 | +---------------------------+ 1 row in set (0.26 sec) mysql> SELECT CAST(1 AS DOUBLE) / CAST(3 AS DOUBLE) * 3; +-------------------------------------------+ | cast(1 as double) / cast(3 as double) * 3 | +-------------------------------------------+ | 1 | +-------------------------------------------+ 1 row in set (0.02 sec) mysql> SELECT CAST(1 AS DOUBLE) / CAST(3 AS DOUBLE) * CAST(3 AS DOUBLE); +-----------------------------------------------------------+ | cast(1 as double) / cast(3 as double) * cast(3 as double) | +-----------------------------------------------------------+ | 1 | +-----------------------------------------------------------+ 1 row in set (0.01 sec)

PostgreSQL

PostgreSQLはデフォルトの挙動が明らかに異なります。

postgres=> SELECT 1 / 3; ?column? ---------- 0 (1 row) postgres=> SELECT 1 / 3 * 3; ?column? ---------- 0 (1 row) postgres=> SELECT 1::DOUBLE PRECISION / 3::DOUBLE PRECISION * 3::DOUBLE PRECISION; ?column? ---------- 1 (1 row) postgres=> SELECT PG_TYPEOF(1::DOUBLE PRECISION / 3::DOUBLE PRECISION * 3::DOUBLE PRECISION); pg_typeof ------------------ double precision (1 row) postgres=> SELECT PG_TYPEOF(1 / 3 * 3); pg_typeof ----------- integer (1 row)

あと少し :)

・標準はあるにはあるが癖の多いSQL 全部俺　#1 Pagination
・標準はあるにはあるが癖の多いSQL 全部俺　#2 関数名は同じでも引数が逆の罠！
・標準はあるにはあるが癖の多いSQL 全部俺　#3 データ型確認したい時あるんです
・標準はあるにはあるが癖の多いSQL 全部俺　#4 リテラル値での除算の内部精度も違うのよ!
・標準はあるにはあるが癖の多いSQL 全部俺　#5 和暦変換機能ある方が少数派
・標準はあるにはあるが癖の多いSQL 全部俺　#6 時間厳守！
・標準はあるにはあるが癖の多いSQL 全部俺　#7 期間リテラル！
・標準はあるにはあるが癖の多いSQL 全部俺　#8 翌月末日って何日？
・標準はあるにはあるが癖の多いSQL 全部俺　#9 部分文字列の扱いでも癖が出る＞＜
・標準はあるにはあるが癖の多いSQL 全部俺　#10 文字列連結の罠（有名なやつ）
・標準はあるにはあるが癖の多いSQL 全部俺　#11 デュエル、じゃなくて、デュアル
・標準はあるにはあるが癖の多いSQL 全部俺　#12 文字[列]探すにも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#13 あると便利ですが意外となかったり
・標準はあるにはあるが癖の多いSQL 全部俺　#14 連番の集合を返すにも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#15 SQL command line client
・標準はあるにはあるが癖の多いSQL 全部俺　#16 SQLのレントゲンを撮る方法
・標準はあるにはあるが癖の多いSQL 全部俺　#17 その空白は許されないのか？
・標準はあるにはあるが癖の多いSQL 全部俺　#18 (+)の外部結合は方言
・標準はあるにはあるが癖の多いSQL 全部俺　#19 帰ってきた、部分文字列の扱いでも癖w
・標準はあるにはあるが癖の多いSQL 全部俺　#20 結果セットを単一列に連結するにも癖がある

投稿日時 2020年12月21日 (月) 04時02分 Oracle, FAQ, SQL, MySQL, PostgreSQL, Advent Calendar | 固定リンク | 0 | コメント (0)

2020年12月20日 (日)

標準はあるにはあるが癖の多いSQL 全部俺　#20 結果セットを単一列に連結するにも癖がある

標準はあるにはあるが癖の多いSQL 全部俺w Advent Calendar 2020の20日目です。

また、本記事はJPOUG Advent Calendar 2020の20日目の窓へクロスポストしています。
JPOUG Advent Calendar 2020の19日目はNaotaka ShinogiさんのNutanix Eraで描くDatabase管理とOracleSEのデータ同期でした。

さて、今日は、最終日のネタ作りの途中でどうしても、非互換なところと格闘しないといけないので、その部分の対応をかねてw

今回は、結果セット（複数行）を単一列に連結する集約関数 Oracleでは LISTAGG()という関数の非互換です。
同様の関数はあるものの関数名は違うし多少引数も違うのでぱっと見、どう書き換えるかってなると迷うわけです。知ってれば別ですけども。

では、早速みてみましょう。

Oracle

LISTAGG

LISTAGG( [ ALL ] [ DISTINCT ] measure_expr [, 'delimiter'] [listagg_overflow_clause] ) [ WITHIN GROUP ] (order_by_clause) [OVER query_partition_clause]
https://docs.oracle.com/cd/F19136_01/sqlrf/LISTAGG.html#GUID-B6E50D8E-F467-425B-9436-F7F8BF38D466

使ったことがある方なら、ああ、アレかと思い出せると思います。あまり使う機会はないので私もマニュアル見て思出すことが多いですね。この関数w

ORACLE> *1 SELECT * FROM list; ID STR ---------- ------------- 1 foo 1 bar 1 tiger 1 scott 2 bill 2 steve ORACLE> r 1 SELECT 2 id 3 , LISTAGG(str, ',') 4 WITHIN GROUP 5 ( 6 ORDER BY str 7 ) 8 AS lists 9 FROM 10 list 11 GROUP BY id 12* ORDER BY id ID LISTS ---------- ---------------------------------------- 1 bar,foo,scott,tiger 2 bill,steve

次は、MySQL(8.0)

MySQLでは　GROUP_CONCAT()関数が該当します。使い方は似ていますが、セパレータの指定方法に特徴がありますね。

GROUP_CONCAT(expr)
https://dev.mysql.com/doc/refman/8.0/en/aggregate-functions.html#function_group-concat

GROUP_CONCAT([DISTINCT] expr [,expr ...]
[ORDER BY {unsigned_integer | col_name | expr}
[ASC | DESC] [,col_name ...]]
[SEPARATOR str_val])

mysql> SELECT -> id -> , GROUP_CONCAT( -> str -> ORDER BY str -> SEPARATOR ',' -> ) -> AS lists -> FROM -> list -> GROUP BY id -> ORDER BY id; +------+---------------------+ | id | lists | +------+---------------------+ | 1 | bar,foo,scott,tiger | | 2 | bill,steve | +------+---------------------+ 2 rows in set (0.03 sec)

PostgreSQL

PostgreSQLには類似する機能を持つ関数が複数ありますが、LISTAGG()と同じ結果を得る場合には、array_agg＋array_to_string関数の組み合わせか、LISTAGGに近いSTRING_AGG()関数を単独で利用します。

array_agg(expression)
string_agg(expression, delimiter)
https://www.postgresql.jp/document/12/html/functions-aggregate.html

array_to_string(anyarray, text [, text])
https://www.postgresql.jp/document/12/html/functions-array.html

postgres=> SELECT postgres-> id postgres-> , STRING_AGG( postgres(> str, ',' postgres(> ORDER BY str postgres(> ) postgres-> AS lists postgres-> FROM postgres-> list postgres-> GROUP BY id postgres-> ORDER BY id; id | lists ----+--------------------- 1 | bar,foo,scott,tiger 2 | bill,steve

postgres=> SELECT postgres-> id postgres-> , ARRAY_TO_STRING( postgres(> ARRAY_AGG(str ORDER BY str) postgres(> , ',' postgres(> ) postgres-> AS lists postgres-> FROM postgres-> list postgres-> GROUP BY id postgres-> ORDER BY id; id | lists ----+--------------------- 1 | bar,foo,scott,tiger 2 | bill,steve

最終日のエントリーはこの集約関数やSUBSTR()など、標準はあるにはあるが癖の多いSQL 全部俺w Advent Calendar 2020で紹介した複数のSQL構文や関数を利用したネタを予定しています。（ネタが厳しくなったら早めに公開するかもしれませんが）

明日の12月21日のJPOUG Advent Calendar 2020は Yohei Azekatsu さんです。何か、やらかして。。。いや、何か、やってくれることでしょうw　よろしくおねがいします！

・標準はあるにはあるが癖の多いSQL 全部俺　#1 Pagination
・標準はあるにはあるが癖の多いSQL 全部俺　#2 関数名は同じでも引数が逆の罠！
・標準はあるにはあるが癖の多いSQL 全部俺　#3 データ型確認したい時あるんです
・標準はあるにはあるが癖の多いSQL 全部俺　#4 リテラル値での除算の内部精度も違うのよ!
・標準はあるにはあるが癖の多いSQL 全部俺　#5 和暦変換機能ある方が少数派
・標準はあるにはあるが癖の多いSQL 全部俺　#6 時間厳守！
・標準はあるにはあるが癖の多いSQL 全部俺　#7 期間リテラル！
・標準はあるにはあるが癖の多いSQL 全部俺　#8 翌月末日って何日？
・標準はあるにはあるが癖の多いSQL 全部俺　#9 部分文字列の扱いでも癖が出る＞＜
・標準はあるにはあるが癖の多いSQL 全部俺　#10 文字列連結の罠（有名なやつ）
・標準はあるにはあるが癖の多いSQL 全部俺　#11 デュエル、じゃなくて、デュアル
・標準はあるにはあるが癖の多いSQL 全部俺　#12 文字[列]探すにも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#13 あると便利ですが意外となかったり
・標準はあるにはあるが癖の多いSQL 全部俺　#14 連番の集合を返すにも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#15 SQL command line client
・標準はあるにはあるが癖の多いSQL 全部俺　#16 SQLのレントゲンを撮る方法
・標準はあるにはあるが癖の多いSQL 全部俺　#17 その空白は許されないのか？
・標準はあるにはあるが癖の多いSQL 全部俺　#18 (+)の外部結合は方言
・標準はあるにはあるが癖の多いSQL 全部俺　#19 帰ってきた、部分文字列の扱いでも癖w

投稿日時 2020年12月20日 (日) 00時00分 Oracle, FAQ, SQL, MySQL, PostgreSQL, Advent Calendar | 固定リンク | 0 | コメント (0)

2020年12月19日 (土)

標準はあるにはあるが癖の多いSQL 全部俺　#19 帰ってきた、部分文字列の扱いでも癖w

標準はあるにはあるが癖の多いSQL 全部俺w Advent Calendar 2020の19日目です。

標準はあるにはあるが癖の多いSQL 全部俺　#9 部分文字列の扱いでも癖が出る＞＜
で、すっかり忘れてた。非互換ではその手のが多いw

部分文字列の扱いの癖、盲点というかなんというか、小数の扱いの違いを忘れてましたw

Oracle

Positionが大きい場合の挙動では　Oracle以外は空文字を返します。これも非互換は非互換ですが。

注目してもらいたいのは、整数じゃないとき。Oracleは、小数点以下切り捨てで動きます。

ORACLE> set tab off ORACLE> set null [NULL] ORACLE> col str for a30 ORACLE> SELECT SUBSTR('1234567890', 10, 1) AS str FROM dual; STR ------------------------------ 0 ORACLE> SELECT SUBSTR('1234567890', 11, 1) AS str FROM dual; STR ------------------------------ [NULL] ORACLE> SELECT SUBSTR('1234567890',10.4, 1) AS str FROM dual; STR ------------------------------ 0 ORACLE> SELECT SUBSTR('1234567890',10.5, 1) AS str FROM dual; STR ------------------------------ 0 ORACLE> SELECT SUBSTR('1234567890',10.9, 1) AS str FROM dual; STR ------------------------------ 0

MySQL (8.0)

Positionが範囲外であれば空文字を返すのは冒頭で説明した通りですが、Oracleと明らかに違うのは、小数点以下は四捨五入
整数以外も受け付けてくれますが、デフォルトの挙動で、切り捨てか、四捨五入という違いにより取り出される結果に差異が出ます。ハマりますよね。これw

mysql> SELECT SUBSTRING('1234567890', 10, 1) AS str; +-----+ | str | +-----+ | 0 | +-----+ 1 row in set (0.01 sec) mysql> SELECT SUBSTRING('1234567890', 11, 1) AS str; +-----+ | str | +-----+ | | +-----+ 1 row in set (0.02 sec) mysql> SELECT SUBSTRING('1234567890', 10.4, 1) AS str; +-----+ | str | +-----+ | 0 | +-----+ 1 row in set (0.02 sec) mysql> SELECT SUBSTRING('1234567890', 10.5, 1) AS str; +-----+ | str | +-----+ | | +-----+ 1 row in set (0.06 sec) mysql> SELECT SUBSTRING('1234567890', 10.9, 1) AS str; +-----+ | str | +-----+ | | +-----+ 1 row in set (0.02 sec) mysql> SELECT SUBSTRING('1234567890', 1.4, 1) AS str; +-----+ | str | +-----+ | 1 | +-----+ 1 row in set (0.01 sec) mysql> SELECT SUBSTRING('1234567890', 1.5, 1) AS str; +-----+ | str | +-----+ | 2 | +-----+ 1 row in set (0.02 sec) mysql> SELECT CONCAT(CONCAT('''',SUBSTRING('1234567890', 10.9, 1)),'''') AS str; +-----+ | str | +-----+ | '' | +-----+ 1 row in set (0.02 sec)

PostgreSQL

こちらPostgreSQLは単純、Positionに指定できるのは整数のみです。ある意味わかりやすいですw　文字列の位置が　1.9とかなかなかですからね。

postgres=> SELECT SUBSTRING('1234567890', 10, 1) AS str; str ----- 0 (1 row) postgres=> SELECT SUBSTRING('1234567890', 11, 1) AS str; str ----- (1 row) postgres=> SELECT CONCAT(CONCAT('''',SUBSTRING('1234567890', 11, 1)),'''') AS str; str ----- '' (1 row) postgres=> SELECT SUBSTRING('1234567890', 10.4, 1) AS str; ERROR: function pg_catalog.substring(unknown, numeric, integer) does not exist LINE 1: SELECT SUBSTRING('1234567890', 10.4, 1) AS str;

おまけ

Redshift

PostgreSQLの血筋のはずですが、少数はエラーにもならず、そんなのねーよ。的な空文字が帰ってきます。なかなか男前です。素直に考えれば、1.9のところって文字の途中な訳で。。。

これもなかなか気づかいないです。エラーにはならないタイプなので、結果をみて？？？？　としばらく悩むタイプですね。非互換としては事前に判断が難しいタイプ。リテラルで少数指定されていれば気づきやすいですが、バインド変数だったりすると気づくのは、かなり辛いです。

redshift=# SELECT SUBSTRING('1234567890', 10, 1) AS str; str ----- 0 (1 row) redshift=# SELECT SUBSTRING('1234567890', 11, 1) AS str; str ----- (1 row) redshift=# SELECT SUBSTRING('1234567890', 10.4, 1) AS str; str ----- (1 row) redshift=# SELECT SUBSTRING('1234567890', 10.5, 1) AS str; str ----- (1 row) redshift=# SELECT SUBSTRING('1234567890', 10.9, 1) AS str; str ----- (1 row) redshift=# SELECT SUBSTRING('1234567890', 1.4, 1) AS str; str ----- (1 row) redshift=# SELECT SUBSTRING('1234567890', 1.5, 1) AS str; str ----- (1 row) redshift=# SELECT CONCAT(CONCAT('''',SUBSTRING('1234567890', 10.9, 1)),'''') AS str; str ----- '' (1 row)

hr>
さあ、カウントダウンだw　(^^;;;;;

・標準はあるにはあるが癖の多いSQL 全部俺　#1 Pagination
・標準はあるにはあるが癖の多いSQL 全部俺　#2 関数名は同じでも引数が逆の罠！
・標準はあるにはあるが癖の多いSQL 全部俺　#3 データ型確認したい時あるんです
・標準はあるにはあるが癖の多いSQL 全部俺　#4 リテラル値での除算の内部精度も違うのよ!
・標準はあるにはあるが癖の多いSQL 全部俺　#5 和暦変換機能ある方が少数派
・標準はあるにはあるが癖の多いSQL 全部俺　#6 時間厳守！
・標準はあるにはあるが癖の多いSQL 全部俺　#7 期間リテラル！
・標準はあるにはあるが癖の多いSQL 全部俺　#8 翌月末日って何日？
・標準はあるにはあるが癖の多いSQL 全部俺　#9 部分文字列の扱いでも癖が出る＞＜
・標準はあるにはあるが癖の多いSQL 全部俺　#10 文字列連結の罠（有名なやつ）
・標準はあるにはあるが癖の多いSQL 全部俺　#11 デュエル、じゃなくて、デュアル
・標準はあるにはあるが癖の多いSQL 全部俺　#12 文字[列]探すにも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#13 あると便利ですが意外となかったり
・標準はあるにはあるが癖の多いSQL 全部俺　#14 連番の集合を返すにも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#15 SQL command line client
・標準はあるにはあるが癖の多いSQL 全部俺　#16 SQLのレントゲンを撮る方法
・標準はあるにはあるが癖の多いSQL 全部俺　#17 その空白は許されないのか？
・標準はあるにはあるが癖の多いSQL 全部俺　#18 (+)の外部結合は方言

投稿日時 2020年12月19日 (土) 16時46分 Oracle, FAQ, SQL, MySQL, PostgreSQL, Advent Calendar, AWS | 固定リンク | 0 | コメント (0)

2020年12月18日 (金)

標準はあるにはあるが癖の多いSQL 全部俺　#18 (+)の外部結合は方言

標準はあるにはあるが癖の多いSQL 全部俺w Advent Calendar 2020の18日目です。

今日はこまけーことに気づいてしまい、ブログ忘れそうだったw

ということで、２時間を切ったところで書いてますw

今日は、(+)を使った外部結合はOracle以外で通るのか（まあ、通らないですけどねー、Oracleの方言なのでw

と言った結合関連ネタを軽めで m(_ _)m

Oracle

(+)を使ったOracleの外部結合は、方言として有名ですよね。私は随分前から使わなくなってしまったので、今日は久々なにタイプした気がしますw
ANSI構文より(+)をオススメされる時があることはあるのですが、大抵の場合、実行計画がイケてるない時の対策としてだったりします。最近のは調べてないですが、。。。時間があったらネタにしてみたいと思います。。。w

ORACLE> SELECT * 2 FROM 3 m, d 4 WHERE 5 m.id = d.id(+); ID ID SUBID ---------- ---------- ---------- 1 1 1 2 2 1 3 ORACLE> SELECT * 2 FROM 3 m 4 LEFT OUTER JOIN d 5 ON m.id = d.id; ID ID SUBID ---------- ---------- ---------- 1 1 1 2 2 1 3 ORACLE> SELECT * 2 FROM 3 m, d; ID ID SUBID ---------- ---------- ---------- 1 1 1 2 1 1 3 1 1 1 2 1 2 2 1 3 2 1 ORACLE> SELECT * 2 FROM 3 m 4 CROSS JOIN d; ID ID SUBID ---------- ---------- ---------- 1 1 1 2 1 1 3 1 1 1 2 1 2 2 1 3 2 1 ORACLE> SELECT * 2 FROM 3 m, d 4 WHERE 5 m.id = d.id; ID ID SUBID ---------- ---------- ---------- 1 1 1 2 2 1 ORACLE> SELECT * 2 FROM 3 m 4 INNER JOIN d 5 ON m.id = d.id; ID ID SUBID ---------- ---------- ---------- 1 1 1 2 2 1

PostgreSQL

お次はPostgreSQL、通りませんよね！

postgres=> SELECT * postgres-> FROM postgres-> m postgres-> LEFT OUTER JOIN d postgres-> ON m.id = d.id; id | id | subid ----+----+------- 1 | 1 | 1 2 | 2 | 1 3 | | (3 rows) postgres=> SELECT * postgres-> FROM postgres-> m, d postgres-> WHERE postgres-> m.id = d.id(+); ERROR: syntax error at or near ")" LINE 5: m.id = d.id(+); ^ postgres=> SELECT * postgres-> FROM postgres-> m, d; id | id | subid ----+----+------- 1 | 1 | 1 1 | 2 | 1 2 | 1 | 1 2 | 2 | 1 3 | 1 | 1 3 | 2 | 1 (6 rows) postgres=> SELECT * postgres-> FROM postgres-> m postgres-> CROSS JOIN d; id | id | subid ----+----+------- 1 | 1 | 1 1 | 2 | 1 2 | 1 | 1 2 | 2 | 1 3 | 1 | 1 3 | 2 | 1 (6 rows) postgres=> SELECT * postgres-> FROM postgres-> m, d postgres-> WHERE postgres-> m.id = d.id; id | id | subid ----+----+------- 1 | 1 | 1 2 | 2 | 1 (2 rows) postgres=> SELECT * postgres-> FROM postgres-> m postgres-> INNER JOIN d postgres-> ON m.id = d.id; id | id | subid ----+----+------- 1 | 1 | 1 2 | 2 | 1 (2 rows)

MySQL (8.0)

それは、MySQLでも同じ。。。で(+)はエラーですよねー

mysql> SELECT * -> FROM -> m -> LEFT OUTER JOIN d -> ON m.id = d.id; +------+------+-------+ | id | id | subid | +------+------+-------+ | 1 | 1 | 1 | | 2 | 2 | 1 | | 3 | NULL | NULL | +------+------+-------+ 3 rows in set (0.07 sec) mysql> SELECT * -> FROM -> m, d -> WHERE -> m.id = d.id(+); ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ')' at line 5 mysql> SELECT * -> FROM -> m, d; +------+------+-------+ | id | id | subid | +------+------+-------+ | 1 | 2 | 1 | | 1 | 1 | 1 | | 2 | 2 | 1 | | 2 | 1 | 1 | | 3 | 2 | 1 | | 3 | 1 | 1 | +------+------+-------+ 6 rows in set (0.06 sec) mysql> SELECT * -> FROM -> m -> CROSS JOIN d; +------+------+-------+ | id | id | subid | +------+------+-------+ | 1 | 2 | 1 | | 1 | 1 | 1 | | 2 | 2 | 1 | | 2 | 1 | 1 | | 3 | 2 | 1 | | 3 | 1 | 1 | +------+------+-------+ 6 rows in set (0.04 sec) mysql> SELECT * -> FROM -> m, d -> WHERE -> m.id = d.id; +------+------+-------+ | id | id | subid | +------+------+-------+ | 1 | 1 | 1 | | 2 | 2 | 1 | +------+------+-------+ 2 rows in set (0.05 sec) mysql> mysql> SELECT * -> FROM -> m -> INNER JOIN d -> ON m.id = d.id; +------+------+-------+ | id | id | subid | +------+------+-------+ | 1 | 1 | 1 | | 2 | 2 | 1 | +------+------+-------+ 2 rows in set (0.03 sec)

Redshift

Redshiftでは〜、通じるんですよね。　(+)　の外部結合

WHERE 句の Oracle スタイルの外部結合
https://docs.aws.amazon.com/ja_jp/redshift/latest/dg/r_WHERE_oracle_outer.html

ギリギリ 18個目の窓を開けたw　(^^;;;;;

・標準はあるにはあるが癖の多いSQL 全部俺　#1 Pagination
・標準はあるにはあるが癖の多いSQL 全部俺　#2 関数名は同じでも引数が逆の罠！
・標準はあるにはあるが癖の多いSQL 全部俺　#3 データ型確認したい時あるんです
・標準はあるにはあるが癖の多いSQL 全部俺　#4 リテラル値での除算の内部精度も違うのよ!
・標準はあるにはあるが癖の多いSQL 全部俺　#5 和暦変換機能ある方が少数派
・標準はあるにはあるが癖の多いSQL 全部俺　#6 時間厳守！
・標準はあるにはあるが癖の多いSQL 全部俺　#7 期間リテラル！
・標準はあるにはあるが癖の多いSQL 全部俺　#8 翌月末日って何日？
・標準はあるにはあるが癖の多いSQL 全部俺　#9 部分文字列の扱いでも癖が出る＞＜
・標準はあるにはあるが癖の多いSQL 全部俺　#10 文字列連結の罠（有名なやつ）
・標準はあるにはあるが癖の多いSQL 全部俺　#11 デュエル、じゃなくて、デュアル
・標準はあるにはあるが癖の多いSQL 全部俺　#12 文字[列]探すにも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#13 あると便利ですが意外となかったり
・標準はあるにはあるが癖の多いSQL 全部俺　#14 連番の集合を返すにも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#15 SQL command line client
・標準はあるにはあるが癖の多いSQL 全部俺　#16 SQLのレントゲンを撮る方法
・標準はあるにはあるが癖の多いSQL 全部俺　#17 その空白は許されないのか？

投稿日時 2020年12月18日 (金) 22時36分 Oracle, FAQ, SQL, MySQL, PostgreSQL, Advent Calendar, AWS | 固定リンク | 0 | コメント (0)

2020年12月17日 (木)

標準はあるにはあるが癖の多いSQL 全部俺　#17 その空白は許されないのか？

標準はあるにはあるが癖の多いSQL 全部俺w Advent Calendar 2020の17日目です。

もう少しだ頑張れ、自分w

ということで、今日は、そうなの？　みたいな違いをみてみます。
関数と()の間に空白が入るとどうなるか。。。

では、いつもの通り Oracle から初めて、PostgreSQL , MySQLの順に見てみます。

Oracle

まあ、普通ですよね

ORACLE> SELECT COUNT(1) FROM dual; COUNT(1) ---------- 1 ORACLE> SELECT COUNT( 1 ) FROM dual; COUNT(1) ---------- 1 ORACLE> SELECT COUNT (1) FROM dual; COUNT(1) ---------- 1 ¥ ORACLE> SELECT COUNT ( 1 ) FROM dual; COUNT(1) ---------- 1

PostgreSQL (Redshiftも同じ)

これもなんとことはない。。。

postgres=> SELECT COUNT(1); count ------- 1 (1 row) postgres=> SELECT COUNT( 1 ); count ------- 1 (1 row) postgres=> SELECT COUNT (1); count ------- 1 (1 row) postgres=> SELECT COUNT ( 1 ); count ------- 1 (1 row)

MySQL (8.0)

おおおおおー。これは！

mysql> SELECT COUNT(1); +----------+ | count(1) | +----------+ | 1 | +----------+ 1 row in set (0.02 sec) ¥ mysql> SELECT COUNT( 1 ); +------------+ | count( 1 ) | +------------+ | 1 | +------------+ 1 row in set (0.03 sec) mysql> SELECT COUNT (1); ERROR 1046 (3D000): No database selected mysql> SELECT COUNT ( 1 ); ERROR 1046 (3D000): No database selected

ところが、sql_modeをANSIにすると。。。。。

ここ知らないと？？ってなりますよね。関数と()の間にスペース入れるかどうかって、私はスペースなし派ですが、流派によってはありそうな。。。知らんけど。

5.1.11 Server SQL Modes
https://dev.mysql.com/doc/refman/8.0/en/sql-mode.html

MySQLに絵文字を保存しようとしたら文字列が消える問題
http://soudai1025.blogspot.com/2016/03/"

mysql> set sql_mode = 'ANSI'; Query OK, 0 rows affected (0.06 sec) mysql> SELECT COUNT(1); +----------+ | count(1) | +----------+ | 1 | +----------+ 1 row in set (0.05 sec) mysql> SELECT COUNT( 1 ); +------------+ | count( 1 ) | +------------+ | 1 | +------------+ 1 row in set (0.01 sec) mysql> SELECT COUNT (1); +-----------+ | count (1) | +-----------+ | 1 | +-----------+ 1 row in set (0.06 sec) mysql> SELECT COUNT ( 1 ); +-------------+ | count ( 1 ) | +-------------+ | 1 | +-------------+ 1 row in set (0.04 sec)

眠いw

・標準はあるにはあるが癖の多いSQL 全部俺　#1 Pagination
・標準はあるにはあるが癖の多いSQL 全部俺　#2 関数名は同じでも引数が逆の罠！
・標準はあるにはあるが癖の多いSQL 全部俺　#3 データ型確認したい時あるんです
・標準はあるにはあるが癖の多いSQL 全部俺　#4 リテラル値での除算の内部精度も違うのよ!
・標準はあるにはあるが癖の多いSQL 全部俺　#5 和暦変換機能ある方が少数派
・標準はあるにはあるが癖の多いSQL 全部俺　#6 時間厳守！
・標準はあるにはあるが癖の多いSQL 全部俺　#7 期間リテラル！
・標準はあるにはあるが癖の多いSQL 全部俺　#8 翌月末日って何日？
・標準はあるにはあるが癖の多いSQL 全部俺　#9 部分文字列の扱いでも癖が出る＞＜
・標準はあるにはあるが癖の多いSQL 全部俺　#10 文字列連結の罠（有名なやつ）
・標準はあるにはあるが癖の多いSQL 全部俺　#11 デュエル、じゃなくて、デュアル
・標準はあるにはあるが癖の多いSQL 全部俺　#12 文字[列]探すにも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#13 あると便利ですが意外となかったり
・標準はあるにはあるが癖の多いSQL 全部俺　#14 連番の集合を返すにも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#15 SQL command line client
・標準はあるにはあるが癖の多いSQL 全部俺　#16 SQLのレントゲンを撮る方法

投稿日時 2020年12月17日 (木) 19時52分 Oracle, FAQ, SQL, MySQL, PostgreSQL, Advent Calendar, AWS | 固定リンク | 0 | コメント (0)

2020年12月16日 (水)

標準はあるにはあるが癖の多いSQL 全部俺　#16 SQLのレントゲンを撮る方法

標準はあるにはあるが癖の多いSQL 全部俺w Advent Calendar 2020の16日目です。

さて、別の関数ネタをやろうと思うと予定外の打ち合わせが多く、今日も癖の多いSQLネタのはずが、その癖の多いSQLのレントゲン（実行計画）の撮り方の違いをネタにしてみました。m(_ _)m

大きな進化を遂げたのはいうまでも無く、MySQLですね。8.0になって大幅に機能格納した感があります。チューニングもしやすくなることでしょうね:)

こうやって、CTEの再帰問合せの実行計画見ながらハードリカー飲むのもいいものですw

まず、Oracleの実行計画確認方法はEEオプション含め3つ。SQL*Plusのauto trace以外はActual Planが確認できます。一手間かかりますが。

8 SQL*Plusのチューニング
https://docs.oracle.com/cd/F19136_01/sqpug/tuning-SQL-Plus.html#GUID-233D9103-017C-4832-B5E1-E38D32F9B00D

Oracle その1 / auto trace :　SQL*Plusの機能で、オプションなしで利用できますが Actual Plan は見ることができません＞＜実行統計は見れるのですけども

ORACLE> set tab off ORACLE> set linesize 300 ORACLE> set autot trace exp ORACLE> r 1 WITH gen_nums(v) 2 AS 3 ( 4 SELECT 1 5 FROM 6 dual 7 UNION ALL 8 SELECT v + 1 9 FROM 10 gen_nums 11 WHERE v + 1 <= 10 12 ) 13 SELECT v from gen_nums 14* Execution Plan ---------------------------------------------------------- Plan hash value: 1492144221 -------------------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | -------------------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 2 | 26 | 4 (0)| 00:00:01 | | 1 | VIEW | | 2 | 26 | 4 (0)| 00:00:01 | | 2 | UNION ALL (RECURSIVE WITH) BREADTH FIRST| | | | | | | 3 | FAST DUAL | | 1 | | 2 (0)| 00:00:01 | |* 4 | RECURSIVE WITH PUMP | | | | | | -------------------------------------------------------------------------------------------------- Predicate Information (identified by operation id): --------------------------------------------------- 4 - filter("V"+1<=10)

Oracleその２ / DBMS_XPLAN.DISPLAY_CURSOR()を利用したActual Plan取得（これはSEでも使えるオプション不要の機能

DBMS_XPLAN.DISPLAY_CURSOR
https://docs.oracle.com/cd/F19136_01/tgsql/generating-and-displaying-execution-plans.html#GUID-83F88700-3902-4D19-8182-AF2B92AEA7EB

ORACLE> r 1 WITH gen_nums(v) 2 AS 3 ( 4 SELECT /*+ GATHER_PLAN_STATISTICS */ 1 5 FROM 6 dual 7 UNION ALL 8 SELECT v + 1 9 FROM 10 gen_nums 11 WHERE v + 1 <= 10 12 ) 13* SELECT v from gen_nums 1 2 3 4 5 6 7 8 9 10 10 rows selected. ORACLE> SELECT * FROM TABLE(DBMS_XPLAN.display_cursor(format=>'ALLSTATS LAST')); SQL_ID a8yzv4a008jvr, child number 0 ------------------------------------- WITH gen_nums(v) AS ( SELECT /*+ GATHER_PLAN_STATISTICS */ 1 FROM dual UNION ALL SELECT v + 1 FROM gen_nums WHERE v + 1 <= 10 ) SELECT v from gen_nums Plan hash value: 1492144221 -------------------------------------------------------------------------------------------------- | Id | Operation | Name | Starts | E-Rows | A-Rows | A-Time | -------------------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 1 | | 10 |00:00:00.01 | | 1 | VIEW | | 1 | 2 | 10 |00:00:00.01 | | 2 | UNION ALL (RECURSIVE WITH) BREADTH FIRST| | 1 | | 10 |00:00:00.01 | | 3 | FAST DUAL | | 1 | 1 | 1 |00:00:00.01 | | 4 | RECURSIVE WITH PUMP | | 10 | | 9 |00:00:00.01 | --------------------------------------------------------------------------------------------------

Oracle その3 / Real Time SQL　Monitor (EEオプション)

21 データベース操作の監視
https://docs.oracle.com/cd/F19136_01/tgsql/monitoring-database-operations.html#GUID-C941CE9D-97E1-42F8-91ED-4949B2B710BF

ORACLE> set pages 0 ORACLE> set linesize 1000 ORACLE> set long 1000000 ORACLE> set longchunksize 1000000 r 1 WITH gen_nums(v) 2 AS 3 ( 4 SELECT /*+ MONITOR */ 1 5 FROM 6 dual 7 UNION ALL 8 SELECT v + 1 9 FROM 10 gen_nums 11 WHERE v + 1 <= 10 12 ) 13* SELECT v from gen_nums 1 2 3 4 5 6 7 8 9 10 10 rows selected. ORACLE> select dbms_sqltune.report_sql_monitor(type=>'text') from dual; SQL Monitoring Report SQL Text ------------------------------ WITH gen_nums(v) AS ( SELECT /*+ MONITOR */ 1 FROM dual UNION ALL SELECT v + 1 FROM gen_nums WHERE v + 1 <= 10 ) SELECT v from gen_nums Global Information ------------------------------ Status : DONE (ALL ROWS) Instance ID : 1 Session : SCOTT (25:48803) SQL ID : 9g75y7v030mbt SQL Execution ID : 16777216 Execution Started : 12/15/2020 15:58:45 First Refresh Time : 12/15/2020 15:58:45 Last Refresh Time : 12/15/2020 15:58:45 Duration : .000232s Module/Action : SQL*Plus/- Service : orcl Program : sqlplus@localhost.localdomain (TNS V1-V3) Fetch Calls : 2 Global Stats ============================= | Elapsed | Cpu | Fetch | | Time(s) | Time(s) | Calls | ============================= | 0.00 | 0.00 | 2 | ============================= SQL Plan Monitoring Details (Plan Hash Value=1492144221) ================================================================================================================================================= | Id | Operation | Name | Rows | Cost | Time | Start | Execs | Rows | Activity | Activity Detail | | | | | (Estim) | | Active(s) | Active | | (Actual) | (%) | (# samples) | ================================================================================================================================================= | 0 | SELECT STATEMENT | | | | 1 | +0 | 1 | 10 | | | | 1 | VIEW | | 2 | 4 | 1 | +0 | 1 | 10 | | | | 2 | UNION ALL (RECURSIVE WITH) BREADTH FIRST | | | | 1 | +0 | 1 | 10 | | | | 3 | FAST DUAL | | 1 | 2 | 1 | +0 | 1 | 1 | | | | 4 | RECURSIVE WITH PUMP | | | | 1 | +0 | 10 | 9 | | | =================================================================================================================================================

MySQL

なんと、MySQL8.0から実行計画みやすいし、Actualまで出るじゃないですかーーーーーーー〜。

8.8.2 EXPLAIN Output Format
https://dev.mysql.com/doc/refman/8.0/en/explain-output.html

mysql> explain analyze WITH RECURSIVE gen_nums(v) -> AS -> ( -> SELECT 1 -> UNION ALL -> SELECT v + 1 -> FROM -> gen_nums -> WHERE v + 1 <= 10 -> ) -> SELECT v from gen_nums; +----------------------------------------------------------------------------------------------------------------+ | EXPLAIN | +----------------------------------------------------------------------------------------------------------------+ | -> Table scan on gen_nums (actual time=0.000..0.001 rows=10 loops=1) -> Materialize recursive CTE gen_nums (actual time=0.019..0.020 rows=10 loops=1) -> Rows fetched before execution (actual time=0.000..0.000 rows=1 loops=1) -> Repeat until convergence -> Filter: ((gen_nums.v + 1) <= 10) (cost=2.73 rows=2) (actual time=0.002..0.003 rows=4 loops=2) -> Scan new records on gen_nums (cost=2.73 rows=2) (actual time=0.001..0.001 rows=5 loops=2) | +----------------------------------------------------------------------------------------------------------------+ 1 row in set (0.06 sec)

PostgreSQL

そういえば、なんと無くMySQLの実行計画の見え方とPostgreSQLのは似てる気がします:)

14.1. EXPLAINの利用
https://www.postgresql.jp/document/12/html/using-explain.html

postgresql=> explain (analyze, buffers, verbose) WITH RECURSIVE gen_nums(v) AS ( SELECT 1 UNION ALL SELECT v + 1 FROM gen_nums WHERE v + 1 <= 10 ) SELECT v from gen_nums; QUERY PLAN ---------------------------------------------------------------------------------------------------------------------------------- CTE Scan on gen_nums (cost=3.21..3.83 rows=31 width=4) (actual time=0.004..0.016 rows=10 loops=1) Output: gen_nums.v CTE gen_nums -> Recursive Union (cost=0.00..3.21 rows=31 width=4) (actual time=0.003..0.013 rows=10 loops=1) -> Result (cost=0.00..0.01 rows=1 width=4) (actual time=0.001..0.002 rows=1 loops=1) Output: 1 -> WorkTable Scan on gen_nums gen_nums_1 (cost=0.00..0.26 rows=3 width=4) (actual time=0.001..0.001 rows=1 loops=10) Output: (gen_nums_1.v + 1) Filter: ((gen_nums_1.v + 1) <= 10) Rows Removed by Filter: 0 Planning Time: 0.055 ms Execution Time: 0.039 ms (12 rows)

さて、rebootしますよ。何かを。という話はもう少しあとでw

・標準はあるにはあるが癖の多いSQL 全部俺　#1 Pagination
・標準はあるにはあるが癖の多いSQL 全部俺　#2 関数名は同じでも引数が逆の罠！
・標準はあるにはあるが癖の多いSQL 全部俺　#3 データ型確認したい時あるんです
・標準はあるにはあるが癖の多いSQL 全部俺　#4 リテラル値での除算の内部精度も違うのよ!
・標準はあるにはあるが癖の多いSQL 全部俺　#5 和暦変換機能ある方が少数派
・標準はあるにはあるが癖の多いSQL 全部俺　#6 時間厳守！
・標準はあるにはあるが癖の多いSQL 全部俺　#7 期間リテラル！
・標準はあるにはあるが癖の多いSQL 全部俺　#8 翌月末日って何日？
・標準はあるにはあるが癖の多いSQL 全部俺　#9 部分文字列の扱いでも癖が出る＞＜
・標準はあるにはあるが癖の多いSQL 全部俺　#10 文字列連結の罠（有名なやつ）
・標準はあるにはあるが癖の多いSQL 全部俺　#11 デュエル、じゃなくて、デュアル
・標準はあるにはあるが癖の多いSQL 全部俺　#12 文字[列]探すにも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#13 あると便利ですが意外となかったり
・標準はあるにはあるが癖の多いSQL 全部俺　#14 連番の集合を返すにも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#15 SQL command line client

投稿日時 2020年12月16日 (水) 00時00分 Oracle, FAQ, SQL, MySQL, PostgreSQL, Advent Calendar | 固定リンク | 0 | コメント (0)

2020年12月15日 (火)

標準はあるにはあるが癖の多いSQL 全部俺　#15 SQL command line client

標準はあるにはあるが癖の多いSQL 全部俺w Advent Calendar 2020の15日目です。

最初に、これSQLじゃないじゃん！　はい。その通りです m(_ _)m

如何にもこうにも、時間取れなくて、安易な差異の紹介に走りました。　
とはいえ、SQL command line clentの使い勝手の違いって意外に無視できなかったりします
全ては紹介できないですが、個人的にどのエンジンのSQL command line clientでも使う機能だけですが:)

SQL command line clientでSQL叩いて、一旦、exitしてなんて面倒なことしたくないのでホストコマンドを実行したくなった時は ! とか \!　です。

Oracle

OracleのSQL*Plusでは ! でホストコマンドを実行できます(Windowsは host or $)

Use the following command to execute operating system commands. - ! [ command ]
https://docs.oracle.com/en/database/oracle/oracle-database/19/sqpqr/index.html#SQPQR108

ORACLE> ! date 2020年 12月15日火曜日 0時34分38秒 JST

PostgreSQL

psql - \! [ command ]
https://www.postgresql.jp/document/12/html/app-psql.html

postgres=> \! date 2020年 12月15日火曜日 0時35分34秒 JST

Mysql

mysql - \! [ command ]
https://dev.mysql.com/doc/refman/8.0/en/mysql-commands.html

mysql> \! date 2020年 12月15日火曜日 0時39分00秒 JST

そして、無くてはならない編集コマンド, edit や \e と言ったショートカットなどがありますね。一通り覚えておくと便利です。

ORACLE

ED[IT] [file_name[.ext]]
https://docs.oracle.com/cd/F19136_01/sqpug/EDIT.html#GUID-25BC5CA1-4B03-4186-8ED3-715B5C6A6C42

ORACLE> select 1 from dual; 1 ---------- 1 ORACLE> edit

PostgreSQL

\e, \edit [ filename ] [ line_number ]
https://www.postgresql.jp/document/12/html/app-psql.html

postgres=> select 1; ?column? ---------- 1 (1 row) postgres=> \e

MySQL

edit, \e
https://dev.mysql.com/doc/refman/8.0/en/mysql-commands.html

mysql> select 1; +---+ | 1 | +---+ | 1 | +---+ 1 row in set (0.02 sec) mysql> edit

これ、書いてて思い出した、explainの違いも書いておいた方がいいか。。。。これもSQLそのものではないけど、重要なはず。

・標準はあるにはあるが癖の多いSQL 全部俺　#1 Pagination
・標準はあるにはあるが癖の多いSQL 全部俺　#2 関数名は同じでも引数が逆の罠！
・標準はあるにはあるが癖の多いSQL 全部俺　#3 データ型確認したい時あるんです
・標準はあるにはあるが癖の多いSQL 全部俺　#4 リテラル値での除算の内部精度も違うのよ!
・標準はあるにはあるが癖の多いSQL 全部俺　#5 和暦変換機能ある方が少数派
・標準はあるにはあるが癖の多いSQL 全部俺　#6 時間厳守！
・標準はあるにはあるが癖の多いSQL 全部俺　#7 期間リテラル！
・標準はあるにはあるが癖の多いSQL 全部俺　#8 翌月末日って何日？
・標準はあるにはあるが癖の多いSQL 全部俺　#9 部分文字列の扱いでも癖が出る＞＜
・標準はあるにはあるが癖の多いSQL 全部俺　#10 文字列連結の罠（有名なやつ）
・標準はあるにはあるが癖の多いSQL 全部俺　#11 デュエル、じゃなくて、デュアル
・標準はあるにはあるが癖の多いSQL 全部俺　#12 文字[列]探すにも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#13 あると便利ですが意外となかったり
・標準はあるにはあるが癖の多いSQL 全部俺　#14 連番の集合を返すにも癖がある

投稿日時 2020年12月15日 (火) 11時53分 Oracle, FAQ, SQL, MySQL, PostgreSQL, Advent Calendar | 固定リンク | 0 | コメント (0)

2020年12月14日 (月)

標準はあるにはあるが癖の多いSQL 全部俺　#14 連番の集合を返すにも癖がある

標準はあるにはあるが癖の多いSQL 全部俺w Advent Calendar 2020の14日目です。

今回は大作（軽めにしたかったけど、少々難しのでそのまま載せることにしました）

業務上あまり多くないですが、一連番号の集合を作りたくなることがあります。シーケンスを使わずに。。

Oracleには昔から比較的簡単なクエリーで一連番号の集合を作り出せる（本来その目的のた目のクエリーではないですが）クエリーがいくつかあります。
PostgreSQLには、8.0(7.xぐらいから存在していたのか調べきれず。間違っていたらコメントいただけると助かります)ぐらいから集合を返す関数として、generate_series()が組み込まれています。
MySQLは調べた限りですが、その手の便利関数やクエリーはあまりなさそうでした。

でそれを救う救世主w　と言うのは大げさですが、WITH句を使った再帰問い合わせを使うと比較的互換の高い利用ができるようになってきました。
完全に同一構文ということではないのですけども。。。書き換える部分は少ない方だと思います：）

では、

Oracleから

まず、方言から古い順に紹介していきます。

Oracle/その1：階層問合せとlevel擬似列を利用する方法

他の方法に比べると処理時間なども有利ではあるのですが、Oracleだけでしか利用できない方法です。昔から利用している方は手グセでこちらをタイプすることも多いはずw
実行計画もシンプルで、Oracleで利用可能な方法の中では負荷は軽め（私が検証した範囲では）

階層問合せか、再帰問合せか、それが問題だ #2
https://discus-hamburg.cocolog-nifty.com/mac_de_oracle/2011/01/2-8488.html

階層問合せ
https://docs.oracle.com/cd/F19136_01/sqlrf/Hierarchical-Queries.html#GUID-0118DF1D-B9A9-41EB-8556-C6E7D6A5A84E

ORACLE> set tab off ORACLE> set linesize 300 ORACLE> r 1 SELECT 2 LEVEL AS r 3 FROM 4 dual 5 CONNECT BY 6 LEVEL <= 10 7* R ---------- 1 2 3 4 5 6 7 8 9 10 10 rows selected. Elapsed: 00:00:00.10 ORACLE>ORACLE> set autot trace exp ORACLE> r ...略... Execution Plan ---------------------------------------------------------- Plan hash value: 1236776825 ----------------------------------------------------------------------------- | Id | Operation | Name | Rows | Cost (%CPU)| Time | ----------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 1 | 2 (0)| 00:00:01 | |* 1 | CONNECT BY WITHOUT FILTERING| | | | | | 2 | FAST DUAL | | 1 | 2 (0)| 00:00:01 | ----------------------------------------------------------------------------- Predicate Information (identified by operation id): --------------------------------------------------- 1 - filter(LEVEL<=10)

Oracle/その2：CUBEとrownum擬似列を利用する方法

これOracle 8iぐらいから拡張されたという記憶（間違ってたらごめんなさい）が、CUBEというクロス集計が簡単に書ける構文で長いクエリー書かなくて済むようになったーーーと
リリースされた当時は嬉しかった拡張の一つです。こんな使い方もできるのなーというところですが、実行計画を見るとかなり重めなんですよね。実際階層問合せより重いので、一連番号生成目的で利用することはほぼないですが、できるということで紹介しておきます。

20.3 CUBE(GROUP BYの拡張)
https://docs.oracle.com/cd/F19136_01/dwhsg/sql-aggregation-data-warehouses.html#GUID-C5FDD050-DCE0-4FE1-9741-420E2F970A36

ROWNUM疑似列
https://docs.oracle.com/cd/F19136_01/sqlrf/ROWNUM-Pseudocolumn.html#GUID-2E40EC12-3FCF-4A4F-B5F2-6BC669021726

ORACLE> r 1 SELECT rownum 2 FROM 3 ( 4 SELECT 1 5 FROM 6 dual 7 GROUP BY 8 CUBE(1,1,1,1,1) 9 ) 10 WHERE 11* rownum <= 10 ROWNUM ---------- 1 2 3 4 5 6 7 8 9 10 10 rows selected. Elapsed: 00:00:00.16 Execution Plan ---------------------------------------------------------- Plan hash value: 2264780677 ---------------------------------------------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ---------------------------------------------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 1 | | 66 (0)| 00:00:01 | |* 1 | COUNT STOPKEY | | | | | | | 2 | VIEW | | 1 | | 66 (0)| 00:00:01 | | 3 | TEMP TABLE TRANSFORMATION | | | | | | | 4 | MULTI-TABLE INSERT | | | | | | | 5 | SORT GROUP BY NOSORT ROLLUP | | 1 | | 2 (0)| 00:00:01 | | 6 | FAST DUAL | | 1 | | 2 (0)| 00:00:01 | | 7 | DIRECT LOAD INTO (CURSOR DURATION MEMORY)| SYS_TEMP_0FD9D698E_276CE9B | | | | | | 8 | DIRECT LOAD INTO (CURSOR DURATION MEMORY)| SYS_TEMP_0FD9D698F_276CE9B | | | | | | 9 | VIEW | | 32 | 416 | 64 (0)| 00:00:01 | | 10 | VIEW | | 32 | 416 | 64 (0)| 00:00:01 | | 11 | UNION-ALL | | | | | | | 12 | TABLE ACCESS FULL | SYS_TEMP_0FD9D698E_276CE9B | 1 | 13 | 2 (0)| 00:00:01 | | 13 | TABLE ACCESS FULL | SYS_TEMP_0FD9D698E_276CE9B | 1 | 13 | 2 (0)| 00:00:01 | | 14 | TABLE ACCESS FULL | SYS_TEMP_0FD9D698E_276CE9B | 1 | 13 | 2 (0)| 00:00:01 | | 15 | TABLE ACCESS FULL | SYS_TEMP_0FD9D698E_276CE9B | 1 | 13 | 2 (0)| 00:00:01 | | 16 | TABLE ACCESS FULL | SYS_TEMP_0FD9D698E_276CE9B | 1 | 13 | 2 (0)| 00:00:01 | | 17 | TABLE ACCESS FULL | SYS_TEMP_0FD9D698E_276CE9B | 1 | 13 | 2 (0)| 00:00:01 | | 18 | TABLE ACCESS FULL | SYS_TEMP_0FD9D698E_276CE9B | 1 | 13 | 2 (0)| 00:00:01 | | 19 | TABLE ACCESS FULL | SYS_TEMP_0FD9D698E_276CE9B | 1 | 13 | 2 (0)| 00:00:01 | | 20 | TABLE ACCESS FULL | SYS_TEMP_0FD9D698E_276CE9B | 1 | 13 | 2 (0)| 00:00:01 | | 21 | TABLE ACCESS FULL | SYS_TEMP_0FD9D698E_276CE9B | 1 | 13 | 2 (0)| 00:00:01 | | 22 | TABLE ACCESS FULL | SYS_TEMP_0FD9D698E_276CE9B | 1 | 13 | 2 (0)| 00:00:01 | | 23 | TABLE ACCESS FULL | SYS_TEMP_0FD9D698E_276CE9B | 1 | 13 | 2 (0)| 00:00:01 | | 24 | TABLE ACCESS FULL | SYS_TEMP_0FD9D698E_276CE9B | 1 | 13 | 2 (0)| 00:00:01 | | 25 | TABLE ACCESS FULL | SYS_TEMP_0FD9D698E_276CE9B | 1 | 13 | 2 (0)| 00:00:01 | | 26 | TABLE ACCESS FULL | SYS_TEMP_0FD9D698E_276CE9B | 1 | 13 | 2 (0)| 00:00:01 | | 27 | TABLE ACCESS FULL | SYS_TEMP_0FD9D698E_276CE9B | 1 | 13 | 2 (0)| 00:00:01 | | 28 | TABLE ACCESS FULL | SYS_TEMP_0FD9D698E_276CE9B | 1 | 13 | 2 (0)| 00:00:01 | | 29 | TABLE ACCESS FULL | SYS_TEMP_0FD9D698E_276CE9B | 1 | 13 | 2 (0)| 00:00:01 | | 30 | TABLE ACCESS FULL | SYS_TEMP_0FD9D698E_276CE9B | 1 | 13 | 2 (0)| 00:00:01 | | 31 | TABLE ACCESS FULL | SYS_TEMP_0FD9D698E_276CE9B | 1 | 13 | 2 (0)| 00:00:01 | | 32 | TABLE ACCESS FULL | SYS_TEMP_0FD9D698E_276CE9B | 1 | 13 | 2 (0)| 00:00:01 | | 33 | TABLE ACCESS FULL | SYS_TEMP_0FD9D698E_276CE9B | 1 | 13 | 2 (0)| 00:00:01 | | 34 | TABLE ACCESS FULL | SYS_TEMP_0FD9D698E_276CE9B | 1 | 13 | 2 (0)| 00:00:01 | | 35 | TABLE ACCESS FULL | SYS_TEMP_0FD9D698E_276CE9B | 1 | 13 | 2 (0)| 00:00:01 | | 36 | TABLE ACCESS FULL | SYS_TEMP_0FD9D698E_276CE9B | 1 | 13 | 2 (0)| 00:00:01 | | 37 | TABLE ACCESS FULL | SYS_TEMP_0FD9D698E_276CE9B | 1 | 13 | 2 (0)| 00:00:01 | | 38 | TABLE ACCESS FULL | SYS_TEMP_0FD9D698E_276CE9B | 1 | 13 | 2 (0)| 00:00:01 | | 39 | TABLE ACCESS FULL | SYS_TEMP_0FD9D698E_276CE9B | 1 | 13 | 2 (0)| 00:00:01 | | 40 | TABLE ACCESS FULL | SYS_TEMP_0FD9D698E_276CE9B | 1 | 13 | 2 (0)| 00:00:01 | | 41 | TABLE ACCESS FULL | SYS_TEMP_0FD9D698E_276CE9B | 1 | 13 | 2 (0)| 00:00:01 | | 42 | TABLE ACCESS FULL | SYS_TEMP_0FD9D698E_276CE9B | 1 | 13 | 2 (0)| 00:00:01 | | 43 | TABLE ACCESS FULL | SYS_TEMP_0FD9D698F_276CE9B | 1 | 13 | 2 (0)| 00:00:01 | ---------------------------------------------------------------------------------------------------------------------------- Predicate Information (identified by operation id): --------------------------------------------------- 1 - filter(ROWNUM<=10)

Oracle/その3：再帰問合せを利用する方法

冒頭で紹介した階層問合せはOracleの方言ばりばりですが、階層問合せをサポートしているエンジンも多くなってきたこともあり、同一構文とまでは行きませんがかなり互換性は高い方法です。
汎用性のある方法にしたい場合は階層問合せを利用しておくと良いかもしれませんね。

Oracleの再帰問合せ構文では、recursive　がないのが大きな違いです。また、dual表の利用も必要なのでこの点が他のエンジンと違うところと思っておけば大丈夫だと思います。
意外と構文はシンプルです。階層問合せに比べるとタイプする文字列は多いですけどw

再帰的副問合せのファクタリング
https://docs.oracle.com/cd/F19136_01/sqlrf/SELECT.html#GUID-CFA006CA-6FF1-4972-821E-6996142A51C6

ORACLE> r 1 WITH gen_nums(v) 2 AS 3 ( 4 SELECT 1 5 FROM 6 dual 7 UNION ALL 8 SELECT v + 1 9 FROM 10 gen_nums 11 WHERE v + 1 <= 10 12 ) 13 SELECT v from gen_nums 14* V ---------- 1 2 3 4 5 6 7 8 9 10 10 rows selected. Elapsed: 00:00:00.16 Execution Plan ---------------------------------------------------------- Plan hash value: 1492144221 -------------------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | -------------------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 2 | 26 | 4 (0)| 00:00:01 | | 1 | VIEW | | 2 | 26 | 4 (0)| 00:00:01 | | 2 | UNION ALL (RECURSIVE WITH) BREADTH FIRST| | | | | | | 3 | FAST DUAL | | 1 | | 2 (0)| 00:00:01 | |* 4 | RECURSIVE WITH PUMP | | | | | | -------------------------------------------------------------------------------------------------- Predicate Information (identified by operation id): --------------------------------------------------- 4 - filter("V"+1<=10)

MySQL

調べた限りですが、MySQLにはPostgreSQLのような集合を返す関数として、generate_series()関数やOracleのような多くの方言はなさそうで
MySQL8.0からサポートされた再帰問合せが利用できます。Oracleで紹介した3つめの方法です。

多少構文は異なりますが、違うのは dual表がないのとrecursiveが必要なところ（MySQLの場合dual表を利用することも可能なので差異はrecursiveだけにすることもできます）

Recursive Common Table Expressions
https://dev.mysql.com/doc/refman/8.0/en/with.html#common-table-expressions-recursive

mysql> WITH RECURSIVE gen_nums(v) -> AS -> ( -> SELECT 1 -> UNION ALL -> SELECT v + 1 -> FROM -> gen_nums -> WHERE v + 1 <= 10 -> ) -> SELECT v from gen_nums; +------+ | v | +------+ | 1 | | 2 | | 3 | | 4 | | 5 | | 6 | | 7 | | 8 | | 9 | | 10 | +------+ 10 rows in set (0.06 sec) mysql> explain analyze WITH RECURSIVE gen_nums(v) -> AS -> ( -> SELECT 1 -> UNION ALL -> SELECT v + 1 -> FROM -> gen_nums -> WHERE v + 1 <= 10 -> ) -> SELECT v from gen_nums; +----------------------------------------------------------------------------------------------------------------+ | EXPLAIN | +----------------------------------------------------------------------------------------------------------------+ | -> Table scan on gen_nums (actual time=0.000..0.001 rows=10 loops=1) -> Materialize recursive CTE gen_nums (actual time=0.019..0.020 rows=10 loops=1) -> Rows fetched before execution (actual time=0.000..0.000 rows=1 loops=1) -> Repeat until convergence -> Filter: ((gen_nums.v + 1) <= 10) (cost=2.73 rows=2) (actual time=0.002..0.003 rows=4 loops=2) -> Scan new records on gen_nums (cost=2.73 rows=2) (actual time=0.001..0.001 rows=5 loops=2) | +----------------------------------------------------------------------------------------------------------------+ 1 row in set (0.06 sec)

さて、最後は、
PostgreSQL

PostgreSQL/その1：generate_series()関数を利用する方法

PostgreSQL方言の関数ですが、使いやすいですねタイプする文字数は一番少ない：）

9.24. 集合を返す関数 - 表9.61 連続値生成関数 - generate_series
https://www.postgresql.jp/document/12/html/functions-srf.html

postgresql=> SELECT r FROM generate_series(1, 10) r; r ---- 1 2 3 4 5 6 7 8 9 10 (10 rows) test=> explain (analyze,buffers,verbose) SELECT r FROM generate_series(1, 10) r; QUERY PLAN -------------------------------------------------------------------------------------------------------------------------------- Function Scan on pg_catalog.generate_series r (cost=0.00..10.00 rows=1000 width=4) (actual time=0.007..0.008 rows=10 loops=1) Output: r Function Call: generate_series(1, 10) Planning Time: 0.025 ms Execution Time: 0.022 ms (5 rows)

PostgreSQL/その2：再帰問合せを利用する方法

見ての通り、MySQLで利用した構文がそのまま利用できます。全体で見る再帰問合せを利用する方法がもっとも差異の少ないことがわかります。微妙なさなんですけどね。　無くせないものか。。そこw

7.8. WITH問い合わせ（共通テーブル式）
https://www.postgresql.jp/document/12/html/queries-with.html

postgresql=> WITH RECURSIVE gen_nums(v) postgresql-> AS postgresql-> ( postgresql(> SELECT 1 postgresql(> UNION ALL postgresql(> SELECT v + 1 postgresql(> FROM postgresql(> gen_nums postgresql(> WHERE v + 1 <= 10 postgresql(> ) postgresql-> SELECT v from gen_nums; v ---- 1 2 3 4 5 6 7 8 9 10 (10 rows) postgresql=> explain (analyze, buffers, verbose) WITH RECURSIVE gen_nums(v) AS ( SELECT 1 UNION ALL SELECT v + 1 FROM gen_nums WHERE v + 1 <= 10 ) SELECT v from gen_nums; QUERY PLAN ---------------------------------------------------------------------------------------------------------------------------------- CTE Scan on gen_nums (cost=3.21..3.83 rows=31 width=4) (actual time=0.004..0.016 rows=10 loops=1) Output: gen_nums.v CTE gen_nums -> Recursive Union (cost=0.00..3.21 rows=31 width=4) (actual time=0.003..0.013 rows=10 loops=1) -> Result (cost=0.00..0.01 rows=1 width=4) (actual time=0.001..0.002 rows=1 loops=1) Output: 1 -> WorkTable Scan on gen_nums gen_nums_1 (cost=0.00..0.26 rows=3 width=4) (actual time=0.001..0.001 rows=1 loops=10) Output: (gen_nums_1.v + 1) Filter: ((gen_nums_1.v + 1) <= 10) Rows Removed by Filter: 0 Planning Time: 0.055 ms Execution Time: 0.039 ms (12 rows)

ということで、今日は、役に立つような立たないような、でも何かの役に立ちそうなネタにしてみました。:)

・標準はあるにはあるが癖の多いSQL 全部俺　#1 Pagination
・標準はあるにはあるが癖の多いSQL 全部俺　#2 関数名は同じでも引数が逆の罠！
・標準はあるにはあるが癖の多いSQL 全部俺　#3 データ型確認したい時あるんです
・標準はあるにはあるが癖の多いSQL 全部俺　#4 リテラル値での除算の内部精度も違うのよ!
・標準はあるにはあるが癖の多いSQL 全部俺　#5 和暦変換機能ある方が少数派
・標準はあるにはあるが癖の多いSQL 全部俺　#6 時間厳守！
・標準はあるにはあるが癖の多いSQL 全部俺　#7 期間リテラル！
・標準はあるにはあるが癖の多いSQL 全部俺　#8 翌月末日って何日？
・標準はあるにはあるが癖の多いSQL 全部俺　#9 部分文字列の扱いでも癖が出る＞＜
・標準はあるにはあるが癖の多いSQL 全部俺　#10 文字列連結の罠（有名なやつ）
・標準はあるにはあるが癖の多いSQL 全部俺　#11 デュエル、じゃなくて、デュアル
・標準はあるにはあるが癖の多いSQL 全部俺　#12 文字[列]探すにも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#13 あると便利ですが意外となかったり

投稿日時 2020年12月14日 (月) 01時18分 FAQ, SQL, Opera, MySQL, PostgreSQL, Advent Calendar | 固定リンク | 0 | コメント (0)

2020年12月13日 (日)

標準はあるにはあるが癖の多いSQL 全部俺　#13 あると便利ですが意外となかったり

標準はあるにはあるが癖の多いSQL 全部俺w Advent Calendar 2020の13日目です。

ゼェゼェ。半ばに差し掛かりネタはあるものの書くことに疲れつつあるw　（頑張れ自分w

と言うことで、今日は、あれば便利なので使ったりしますが、意外とありそうでなかったりする INITCAP()

この関数単語の先頭を大文字にしてくれる関数ですが、　MySQLの組み込み関数にはなかったりします。PostgreSQLにはあったり。

最初は
Oracleから。

INITCAP(char)
https://docs.oracle.com/cd/F19136_01/sqlrf/INITCAP.html#GUID-9FE9E0EE-D6B6-4C2C-BDEF-4FF4E1314560

ORACLE> SELECT INITCAP('oracle') FROM dual; INITCA ------ Oracle ORACLE> SELECT INITCAP('oracle-elison') FROM dual; INITCAP('ORAC ------------- Oracle-Elison ORACLE> SELECT INITCAP('oracle,elison') FROM dual; INITCAP('ORAC ------------- Oracle,Elison ORACLE> SELECT INITCAP('oracle|elison') FROM dual; INITCAP('ORAC ------------- Oracle|Elison

PostgreSQL

PostgreSQLにはOracleと同じ関数がサポートされています。

initcap(string)
https://www.postgresql.jp/document/12/html/functions-string.html

postgres=> SELECT INITCAP('oracle'); initcap --------- Oracle (1 row) postgres=> SELECT INITCAP('oracle-elison'); initcap --------------- Oracle-Elison (1 row) postgres=> SELECT INITCAP('oracle,elison'); initcap --------------- Oracle,Elison (1 row) postgres=> SELECT INITCAP('oracle|elison'); initcap --------------- Oracle|Elison (1 row)

MySQL

個人的に意外だったのはMySQL. INITCAP()サポートされてません。UDFで作り込むしかないですね。

N/A
https://dev.mysql.com/doc/refman/8.0/en/string-functions.html

おまけ、
PostgreSQLを祖先にもつRedshiftにはPostgreSQL同様の関数がありました。

Redshift

INITCAP(string)
https://docs.aws.amazon.com/ja_jp/redshift/latest/dg/r_INITCAP.html

実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺） Advent Calendar 2019

・標準はあるにはあるが癖の多いSQL 全部俺　#1 Pagination
・標準はあるにはあるが癖の多いSQL 全部俺　#2 関数名は同じでも引数が逆の罠！
・標準はあるにはあるが癖の多いSQL 全部俺　#3 データ型確認したい時あるんです
・標準はあるにはあるが癖の多いSQL 全部俺　#4 リテラル値での除算の内部精度も違うのよ!
・標準はあるにはあるが癖の多いSQL 全部俺　#5 和暦変換機能ある方が少数派
・標準はあるにはあるが癖の多いSQL 全部俺　#6 時間厳守！
・標準はあるにはあるが癖の多いSQL 全部俺　#7 期間リテラル！
・標準はあるにはあるが癖の多いSQL 全部俺　#8 翌月末日って何日？
・標準はあるにはあるが癖の多いSQL 全部俺　#9 部分文字列の扱いでも癖が出る＞＜
・標準はあるにはあるが癖の多いSQL 全部俺　#10 文字列連結の罠（有名なやつ）
・標準はあるにはあるが癖の多いSQL 全部俺　#11 デュエル、じゃなくて、デュアル
・標準はあるにはあるが癖の多いSQL 全部俺　#12 文字[列]探すにも癖がある

投稿日時 2020年12月13日 (日) 03時10分 Oracle, FAQ, SQL, MySQL, PostgreSQL, Advent Calendar, AWS | 固定リンク | 0 | コメント (0)

2020年12月12日 (土)

標準はあるにはあるが癖の多いSQL 全部俺　#12 文字[列]探すにも癖がある

標準はあるにはあるが癖の多いSQL 全部俺w Advent Calendar 2020の12日目です。

私も癖多めですw

とうことで、アドベントカレンダーも約半分の折り返し地点です。ふー。

今日は、INSTR()

Oracleでは、SUBSTR()同様のバリエーションと挙動が見られます。ある意味分かり易ですね。
と言うことは、方言になりやすいはず。とも言えるわけです。はい。

では、見ていきましょう。

Oracle

positionは、SUBSTR()同様に負の値が使えます。0は、0しか返しません。
occurrenceは、正の値のみを取ります。

{ INSTR| INSTRB| INSTRC| INSTR2| INSTR4}(string , substring [, position [, occurrence ] ])
https://docs.oracle.com/cd/F19136_01/sqlrf/INSTR.html#GUID-47E3A7C4-ED72-458D-A1FA-25A9AD3BE113

ORACLE> SELECT INSTR('1234a56789a', 'a') FROM dual; INSTR('1234A56789A','A') ------------------------ 5 ORACLE> SELECT INSTR('1234a56789a', 'a', 1) FROM dual; INSTR('1234A56789A','A',1) -------------------------- 5 ORACLE> SELECT INSTR('1234a56789a', 'a', -1) FROM dual; INSTR('1234A56789A','A',-1) --------------------------- 11 ORACLE> SELECT INSTR('1234a56789a', 'a', 1, 1) FROM dual; INSTR('1234A56789A','A',1,1) ---------------------------- 　　　　　　　　　　　5 ORACLE> SELECT INSTR('1234a56789a', 'a', 1, 2) FROM dual; INSTR('1234A56789A','A',1,2) ---------------------------- 　　　　　　　　　　　11 ORACLE> SELECT INSTR('1234a56789a', 'a', -1, 2) FROM dual; INSTR('1234A56789A','A',-1,2) ----------------------------- 　　　　　　　　　　　5 ORACLE> SELECT INSTR('1234a56789a', 'a', -1, 1) FROM dual; INSTR('1234A56789A','A',-1,1) ----------------------------- 　　　　　　　　　　　11 ORACLE> SELECT INSTR('1234a56789a', 'a', 0) FROM dual; INSTR('1234A56789A','A',0) -------------------------- 　　　　　　　　　　　0 ORACLE> set null [NULL] ORACLE> SELECT INSTR('1234a56789a', 'a', null) FROM dual; INSTR('1234A56789A','A',NULL) ----------------------------- [NULL] ORACLE> SELECT INSTR('1234a56789a', 'a', '') FROM dual; INSTR('1234A56789A','A','') --------------------------- [NULL] ORACLE> SELECT INSTR('1234a56789a', '') FROM dual; INSTR('1234A56789A','') ----------------------- [NULL] ORACLE> SELECT INSTR('1234a56789a', NULL) FROM dual; INSTR('1234A56789A',NULL) ------------------------- [NULL] ORACLE> SELECT INSTR('1234a56789a', 'a', 1, 0) FROM dual; SELECT INSTR('1234a56789a', 'a', 1, 0) FROM dual * ERROR at line 1: ORA-01428: argument '0' is out of range ORACLE> SELECT INSTR('1234a56789a', 'a', 1, -1) FROM dual; SELECT INSTR('1234a56789a', 'a', 1, -1) FROM dual * ERROR at line 1: ORA-01428: argument '-1' is out of range

MySQL

SUBSTR()はOracleに類似した挙動を持つ部分が多かったMySQLもINSTR()についてはそうでもないですね。positionやoccurrenceなどの引数がありません。
ただ、LOCATE()と言う類似した関数があります。LOCATE()と言う関数ではposition引数がありますが、０以上の整数でのみOracleと同じ挙動で負の値は、常に０ゼロを返すようです。

positionやoccurrence を利用している場合の移行は要注意と言うところですね。

INSTR(str,substr)
https://dev.mysql.com/doc/refman/5.6/ja/string-functions.html#function_instr

mysql> SELECT INSTR('1234a56789a', 'a'); +---------------------------+ | instr('1234a56789a', 'a') | +---------------------------+ | 5 | +---------------------------+ 1 row in set (0.04 sec) mysql> SELECT INSTR('1234a56789a', ''); +--------------------------+ | instr('1234a56789a', '') | +--------------------------+ | 1 | +--------------------------+ 1 row in set (0.04 sec) mysql> SELECT INSTR('1234a56789a', null); +----------------------------+ | instr('1234a56789a', null) | +----------------------------+ | NULL | +----------------------------+ 1 row in set (0.03 sec) mysql> SELECT INSTR('1234a56789a', 'a', 1); ERROR 1582 (42000): Incorrect parameter count in the call to native function 'instr' mysql> SELECT INSTR('1234a56789a', 'a', 1, 1); ERROR 1582 (42000): Incorrect parameter count in the call to native function 'instr'

LOCATE(substr,str), LOCATE(substr,str,pos)
https://dev.mysql.com/doc/refman/8.0/en/string-functions.html#function_locate

mysql> SELECT LOCATE('a', '1234a56789a'); +----------------------------+ | locate('a', '1234a56789a') | +----------------------------+ | 5 | +----------------------------+ 1 row in set (0.08 sec) mysql> SELECT LOCATE('a', '1234a56789a', 2); +-------------------------------+ | locate('a', '1234a56789a', 2) | +-------------------------------+ | 5 | +-------------------------------+ 1 row in set (0.05 sec) mysql> SELECT LOCATE('a', '1234a56789a', 5); +-------------------------------+ | locate('a', '1234a56789a', 5) | +-------------------------------+ | 5 | +-------------------------------+ 1 row in set (0.08 sec) mysql> SELECT LOCATE('a', '1234a56789a', 6); +-------------------------------+ | locate('a', '1234a56789a', 6) | +-------------------------------+ | 11 | +-------------------------------+ 1 row in set (0.09 sec) mysql> SELECT LOCATE('a', '1234a56789a', -1); +--------------------------------+ | locate('a', '1234a56789a', -1) | +--------------------------------+ | 0 | +--------------------------------+ 1 row in set (0.35 sec) mysql> SELECT LOCATE('a', '1234a56789a', 1); +-------------------------------+ | locate('a', '1234a56789a', 1) | +-------------------------------+ | 5 | +-------------------------------+ 1 row in set (0.13 sec) mysql> SELECT LOCATE('a', '1234a56789a', 0); +-------------------------------+ | locate('a', '1234a56789a', 0) | +-------------------------------+ | 0 | +-------------------------------+ 1 row in set (0.35 sec)

PostgreSQL

42.13.3. 付録本節には、移植作業を簡略化するために使用できる、Oracle互換のinstr関数のコードがあります。
https://www.postgresql.jp/document/12/html/plpgsql-porting.html#PLPGSQL-PORTING-APPENDIX

INSTR()はないのですが、類似関数として以下があるようです。また、position()と言う関数もあります。ですが、どちらもpositionやoccurrenceといった引数はない。マニュアルにOracleからの移植作業向けUDFの解説がある点は興味深いところ。

strpos(string, substring)
https://www.postgresql.jp/document/7.4/html/functions-string.html

postgres=> SELECT STRPOS('1234a56789a', 'a'); strpos -------- 5 (1 row) postgres=> SELECT STRPOS('1234a56789a', ''); strpos -------- 1 (1 row) postgres=> \pset null [NULL] Null display is "[NULL]". postgres=> SELECT STRPOS('1234a56789a', NULL); strpos -------- [NULL] (1 row)

position(substring in string)
https://docs.aws.amazon.com/ja_jp/redshift/latest/dg/r_POSITION.html

postgres=> SELECT POSITION('a' in '1234a56789a'); position ---------- 5 (1 row) postgres=> SELECT POSITION('' in '1234a56789a'); position ---------- 1 (1 row) postgres=> SELECT POSITION(NULL in '1234a56789a'); position ---------- [NULL] (1 row) postgres=> SELECT POSITION(0 in '1234a56789a'); ERROR: function pg_catalog.position(unknown, integer) does not exist LINE 1: SELECT POSITION(0 in '1234a56789a'); ^ HINT: No function matches the given name and argument types. You might need to add explicit type casts. postgres=>

Redshift

PostgreSQL系の流れをくむRedshiftに、CHARINDEX()なる関数がある。同名の関数名が見つかるのはSQL Serverですね。それはそれで興味深い。

STRPOS(string, substring )
CHARINDEX( substring, string )
POSITION(substring IN string )
https://docs.aws.amazon.com/ja_jp/redshift/latest/dg/r_POSITION.html

実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺） Advent Calendar 2019

・標準はあるにはあるが癖の多いSQL 全部俺　#1 Pagination
・標準はあるにはあるが癖の多いSQL 全部俺　#2 関数名は同じでも引数が逆の罠！
・標準はあるにはあるが癖の多いSQL 全部俺　#3 データ型確認したい時あるんです
・標準はあるにはあるが癖の多いSQL 全部俺　#4 リテラル値での除算の内部精度も違うのよ!
・標準はあるにはあるが癖の多いSQL 全部俺　#5 和暦変換機能ある方が少数派
・標準はあるにはあるが癖の多いSQL 全部俺　#6 時間厳守！
・標準はあるにはあるが癖の多いSQL 全部俺　#7 期間リテラル！
・標準はあるにはあるが癖の多いSQL 全部俺　#8 翌月末日って何日？
・標準はあるにはあるが癖の多いSQL 全部俺　#9 部分文字列の扱いでも癖が出る＞＜
・標準はあるにはあるが癖の多いSQL 全部俺　#10 文字列連結の罠（有名なやつ）
・標準はあるにはあるが癖の多いSQL 全部俺　#11 デュエル、じゃなくて、デュアル

投稿日時 2020年12月12日 (土) 06時14分 Oracle, FAQ, SQL, MySQL, PostgreSQL, Advent Calendar, AWS | 固定リンク | 0 | コメント (0)

2020年12月11日 (金)

標準はあるにはあるが癖の多いSQL 全部俺　#11 デュエル、じゃなくて、デュアル

標準はあるにはあるが癖の多いSQL 全部俺w Advent Calendar 2020の10日目です。

ネタがなくてw　そこ狙って来たか！　

と思われるかもしれませんが、これを語らずして、非互換語るなかれw

とうことで、Oracleでは、当たり前に利用している　dual について

定数式をSELECT文で計算する場合などに指定する表です。dual表に、おイタしたりしたネタも過去あったような気がしますw

Oracleの方言なので、単純ですが、非互換では有名ですね。

では、本家から

Oracle

DUAL表からの選択
https://docs.oracle.com/cd/F19136_01/sqlrf/Selecting-from-the-DUAL-Table.html#GUID-0AB153FC-5238-4E79-8522-C9E2A04AB5E4

ORACLE> select 1 from dual; 1 ---------- 1 ORACLE> select 1; select 1 * ERROR at line 1: ORA-00923: FROM keyword not found where expected

MySQL

昨日のエントリで使ってしまったw　ので気づいた方もいると思いますが、MySQLは dual 付けられるんですよね。

13.2.10 SELECT Statement
https://dev.mysql.com/doc/refman/8.0/en/select.html

mysql> select 1 from dual; +---+ | 1 | +---+ | 1 | +---+ 1 row in set (0.06 sec) mysql> select 1; +---+ | 1 | +---+ | 1 | +---+ 1 row in set (0.04 sec)

PostgreSQL

PostgreSQLには dual を使うような習慣もないですし、文法的に用意されていません。無理やり dual 表を定義すれば別でしょうけど、無駄なだけなので移行するなら、素直に dualを削除が潔いと思いますw

SELECT
https://www.postgresql.jp/document/12/html/sql-select.html

postgres=> select 1 from dual; ERROR: relation "dual" does not exist LINE 1: select 1 from dual; ^ postgres=> select 1; ?column? ---------- 1 (1 row)

おまけ

Redshift

Redshiftにも　dual はありません。

SELECT
https://docs.aws.amazon.com/ja_jp/redshift/latest/dg/r_SELECT_synopsis.html

redshift=# select 1 from dual; ERROR: relation "dual" does not exist redshift=# select 1; ?column? ---------- 1 (1 row)

また、Athenaも同様です

SELECT
https://docs.aws.amazon.com/ja_jp/athena/latest/ug/select.html

新しい年には、何か変化が欲しいと感じる今日この頃w　

(2024.6更新)

喜ばしいことに、Oracle Database 23ai以降、from dualが必須ではなくなりました！
SELECT Withhout FROM Clause
https://docs.oracle.com/en/database/oracle/oracle-database/23/nfcoa/application_development.html#GUID-86198-1

実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺） Advent Calendar 2019

・標準はあるにはあるが癖の多いSQL 全部俺　#1 Pagination
・標準はあるにはあるが癖の多いSQL 全部俺　#2 関数名は同じでも引数が逆の罠！
・標準はあるにはあるが癖の多いSQL 全部俺　#3 データ型確認したい時あるんです
・標準はあるにはあるが癖の多いSQL 全部俺　#4 リテラル値での除算の内部精度も違うのよ!
・標準はあるにはあるが癖の多いSQL 全部俺　#5 和暦変換機能ある方が少数派
・標準はあるにはあるが癖の多いSQL 全部俺　#6 時間厳守！
・標準はあるにはあるが癖の多いSQL 全部俺　#7 期間リテラル！
・標準はあるにはあるが癖の多いSQL 全部俺　#8 翌月末日って何日？
・標準はあるにはあるが癖の多いSQL 全部俺　#9 部分文字列の扱いでも癖が出る＞＜
・標準はあるにはあるが癖の多いSQL 全部俺　#10 文字列連結の罠（有名なやつ）

投稿日時 2020年12月11日 (金) 00時00分 Oracle, FAQ, SQL, MySQL, PostgreSQL, Advent Calendar, AWS | 固定リンク | 0 | コメント (1)

2020年12月10日 (木)

標準はあるにはあるが癖の多いSQL 全部俺　#10 文字列連結の罠（有名なやつ）

標準はあるにはあるが癖の多いSQL 全部俺w Advent Calendar 2020の10日目です。

なんとか10日目の窓をあけましたw

今回は、有名な非互換なので、まさか、これに引っかかる方はいないと思いますが、定番のお約束みたいな非互換ネタなので書かないといけないですよね！！

では、いつも通り Oracle から。

NULLと空文字(マニュアルでは長さゼロの文字列値と記載されています。有名な非互換)
https://docs.oracle.com/cd/E82638_01/sqlrf/Nulls.html#GUID-B0BA4751-9D88-426A-84AD-BCDBD5584071

CONCAT(char1, char2)
https://docs.oracle.com/en/database/oracle/oracle-database/19/sqlrf/CONCAT.html#GUID-D8723EA5-C93A-45C3-83FB-1F3D2A4CEAF2

連結演算子
https://docs.oracle.com/cd/F19136_01/sqlrf/Concatenation-Operator.html#GUID-08C10738-706B-4290-B7CD-C279EBC90F7E

空文字をNULLとして扱う点と、||による文字列連結(CONCATと同意）の挙動がOracle以外の世界と違うんですよね。これも有名です。

ORACLE> SELECT 'foo' || 'bar' FROM dual; 'FOO'| ------ foobar ORACLE> SELECT 'foo' || '' FROM dual; 'FO --- foo ORACLE> SELECT 'foo' || NULL FROM dual; 'FO --- foo ORACLE> SELECT CONCAT('foo','bar') FROM dual; CONCAT ------ foobar ORACLE> SELECT CONCAT('foo','') FROM dual; CON --- foo ORACLE> SELECT CONCAT('foo',null) FROM dual; CON --- foo

PostgreSQL

PostgreSQLでは、Oracleと異なり文字列連結子でNULLを結合すると結果は、NULLになります。ここがOracleと異なる挙動ですね。
これを回避するにはconcat() or concat_ws()のいずれかを利用できます。

string || string
concat(str "any" [, str "any" [, ...] ])
concat_ws(sep text, str "any" [, str "any" [, ...] ])
https://www.postgresql.jp/document/12/html/functions-string.html

そして、これまた、悩ましいのは、 ||でNULLを結合した場合と、CONCAT_WS()でNULLを結合した挙動が異なるんですね。
||でNULLの場合はNULLですが、CONCATでNULLを結合するとOracleと同じ挙動になるんですよ。

postgres=> SELECT 'foo' || 'bar'; ?column? ---------- foobar (1 row) postgres=> SELECT 'foo' || ''; ?column? ---------- foo (1 row) postgres=> SELECT 'foo' || null; ?column? ---------- [NULL] (1 row) postgres=> SELECT CONCAT('foo', ''); concat -------- foo (1 row) postgres=> SELECT CONCAT('foo', NULL); concat -------- foo (1 row) postgres=> postgres=> SELECT CONCAT_WS('','foo','bar' ); concat_ws ----------- foobar (1 row) postgres=> SELECT CONCAT_WS('','foo','' ); concat_ws ----------- foo (1 row) postgres=> SELECT CONCAT_WS('','foo',NULL ); concat_ws ----------- foo (1 row) postgres=>

MySQL

MySQLでは、||　は文字列連結子ではなく、なんと、論理演算子！！！！！！　

え〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜~っ。

12.4.3 Logical Operators - OR, ||
https://dev.mysql.com/doc/refman/8.0/en/logical-operators.html

mysql> SELECT 'foo' || 'bar' FROM dual; +----------------+ | 'foo' || 'bar' | +----------------+ | 0 | +----------------+ 1 row in set, 3 warnings (0.03 sec) mysql> SELECT 'foo' || '' FROM dual; +-------------+ | 'foo' || '' | +-------------+ | 0 | +-------------+ 1 row in set, 2 warnings (0.04 sec) mysql> SELECT 'foo' || NULL FROM dual; +---------------+ | 'foo' || null | +---------------+ | NULL | +---------------+ 1 row in set, 2 warnings (0.06 sec)

実は逃げ道があるようで、sql_mode='PIPES_AS_CONCAT'　にすると文字列連結子に早変わり！w

ですが、挙動はPostgreSQL同様に、NULLと連結したり演算子すると結果はNULLになると言う一般的な動きをします。
Oracleは演算に関してはNULLが絡むとNULLになりますが、文字列連結だけはNULLが空文字のような扱いを受けると言う挙動を示します。理解しちゃえばあれですが、エラーにならないだけに混乱するタイプの非互換ですね。

PostgreSQLとは異なり、CONCAT_WS()だけがOracleと同じ挙動を示します。

CONCAT(str1,str2,...)
CONCAT_WS(separator,str1,str2,...)
https://dev.mysql.com/doc/refman/8.0/en/string-functions.html

mysql> set sql_mode='PIPES_AS_CONCAT'; Query OK, 0 rows affected (0.03 sec) mysql> SELECT 'foo' || 'bar' FROM dual; +----------------+ | 'foo' || 'bar' | +----------------+ | foobar | +----------------+ 1 row in set (0.02 sec) mysql> SELECT 'foo' || '' FROM dual; +-------------+ | 'foo' || '' | +-------------+ | foo | +-------------+ 1 row in set (0.04 sec) mysql> SELECT 'foo' || NULL FROM dual; +---------------+ | 'foo' || null | +---------------+ | NULL | +---------------+ 1 row in set (0.01 sec) mysql> SELECT CONCAT('foo','bar'); +---------------------+ | concat('foo','bar') | +---------------------+ | foobar | +---------------------+ 1 row in set (0.01 sec) mysql> SELECT CONCAT('foo',''); +------------------+ | concat('foo','') | +------------------+ | foo | +------------------+ 1 row in set (0.02 sec) mysql> SELECT CONCAT('foo',NULL); +--------------------+ | concat('foo',null) | +--------------------+ | NULL | +--------------------+ 1 row in set (0.03 sec) mysql> SELECT CONCAT_WS('foo',NULL); +-----------------------+ | concat_ws('foo',null) | +-----------------------+ | | +-----------------------+ 1 row in set (0.02 sec) mysql> SELECT CONCAT_WS('','foo',NULL); +--------------------------+ | concat_ws('','foo',null) | +--------------------------+ | foo | +--------------------------+ 1 row in set (0.01 sec) mysql> SELECT CONCAT_WS('','foo','bar'); +---------------------------+ | concat_ws('','foo','bar') | +---------------------------+ | foobar | +---------------------------+ 1 row in set (0.02 sec) mysql> SELECT CONCAT_WS('','foo',''); +------------------------+ | concat_ws('','foo','') | +------------------------+ | foo | +------------------------+ 1 row in set (0.02 sec) mysql> SELECT CONCAT_WS('','foo',NULL); +--------------------------+ | concat_ws('','foo',null) | +--------------------------+ | foo | +--------------------------+ 1 row in set (0.01 sec) mysql>

ややこしやー、ややこしやー。

みなさん、ついてこれてますか？　この手の内容が25日まで続きますからね。（私が続けられるか次第だが。。。。頑張りマッス！

実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺） Advent Calendar 2019

・標準はあるにはあるが癖の多いSQL 全部俺　#1 Pagination
・標準はあるにはあるが癖の多いSQL 全部俺　#2 関数名は同じでも引数が逆の罠！
・標準はあるにはあるが癖の多いSQL 全部俺　#3 データ型確認したい時あるんです
・標準はあるにはあるが癖の多いSQL 全部俺　#4 リテラル値での除算の内部精度も違うのよ!
・標準はあるにはあるが癖の多いSQL 全部俺　#5 和暦変換機能ある方が少数派
・標準はあるにはあるが癖の多いSQL 全部俺　#6 時間厳守！
・標準はあるにはあるが癖の多いSQL 全部俺　#7 期間リテラル！
・標準はあるにはあるが癖の多いSQL 全部俺　#8 翌月末日って何日？
・標準はあるにはあるが癖の多いSQL 全部俺　#9 部分文字列の扱いでも癖が出る＞＜

投稿日時 2020年12月10日 (木) 00時00分 Oracle, FAQ, SQL, MySQL, PostgreSQL, Advent Calendar, NULL | 固定リンク | 0 | コメント (0)

2020年12月 9日 (水)

標準はあるにはあるが癖の多いSQL 全部俺　#9 部分文字列の扱いでも癖が出る＞＜

標準はあるにはあるが癖の多いSQL 全部俺w Advent Calendar 2020の9日目です。

それでいいのだ！　バカボンのパパより。

いや、めんどくさいw

と言うことで、今日は単純そうにみえる部分文字列取得の違い。関数名の違いもあれば挙動の違いもあります。

そして、ものすごくバリエーションが多い。多すぎるので、SUBSTR()だけに絞りますw

Oracle

Unicodeキャラクタ向けSUBSTRCやUCS2コードポイント対応、UCS4コードポイント対応などのバリエーションが豊富ですが、それが方言になってますよね。

{ SUBSTR| SUBSTRB| SUBSTRC| SUBSTR2| SUBSTR4}(char, position [, substring_length ])
https://docs.oracle.com/cd/F19136_01/sqlrf/SUBSTR.html#GUID-C8A20B57-C647-4649-A379-8651AA97187E

SUBSTR()はこんな感じ。 positionをマイナスにすると一回りして切り出してきます。

ORACLE> select substr('hoge1234',1,4) from dual; SUBS ---- hoge ORACLE> select substr('hoge1234',-4,4) from dual; SUBS ---- 1234

MySQL

Oracleと同じ関数名、同じ引数をサポートしています。引数に特徴がありますね。from forを使った方が可読性は良いかもしれませんが、逆にウザがれる可能性も否定できません。その点個人の志向次第か。
positionにマイナスを指定した場合、Oracleと同じ挙動になりますね。興味深い。
そして、SUBSTR()はSUBSTRING()のシノニムと言うことなんですね。と言うことはオリジナルはSUBSTRING()なのか。。

SUBSTR() is a synonym for SUBSTRING().
SUBSTR(str,pos), SUBSTR(str FROM pos), SUBSTR(str,pos,len), SUBSTR(str FROM pos FOR len)
SUBSTRING(str,pos), SUBSTRING(str FROM pos), SUBSTRING(str,pos,len), SUBSTRING(str FROM pos FOR len)
https://dev.mysql.com/doc/refman/8.0/en/string-functions.html#function_substr

mysql> select substr('hoge1234',1,4); +------------------------+ | substr('hoge1234',1,4) | +------------------------+ | hoge | +------------------------+ 1 row in set (0.08 sec) mysql> select substr('hoge1234',-4,4); +-------------------------+ | substr('hoge1234',-4,4) | +-------------------------+ | 1234 | +-------------------------+ 1 row in set (0.07 sec)

PostgreSQL

最後にPostgreSQL、こちらはMySQLのオリジナルと同じ関数名SUBSTRING()となっています。ぱっと見、Oracleから関数名さえ変更すれば移行できそうですが、実はpositionにマイナスを指定した場合の挙動に違いがあります！
一回りせずに、空文字を返してきます！！！！　ここ要注意です。

substring(string [from int] [for int])
https://www.postgresql.jp/document/12/html/functions-string.html

postgres=> \pset null [NULL] Null display is "[NULL]". postgres=> select substring('hoge1234',1,4); substring ----------- hoge (1 row) postgres=> select substring('hoge1234',-4,4); substring ----------- (1 row)

おまけですが、PostgreSQLのSUBSTRING()関数では、パターンマッチングが行えるようです。Oraclerの私には、REGEXP_SUBSTR()をイメージしちゃうのですが、
調べてみると、PostgreSQLにはregexp_matches()関数もあります。@@ 違いがわからなくなってきたので、この辺りはあとでゆっくり勉強しておきます。w
(MySQL8.0になると、regexp_substr()関数がサポートされているようですね...終わりのない世界w)

substring(string from pattern)
substring(string from pattern for escape)

実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺） Advent Calendar 2019

・標準はあるにはあるが癖の多いSQL 全部俺　#1 Pagination
・標準はあるにはあるが癖の多いSQL 全部俺　#2 関数名は同じでも引数が逆の罠！
・標準はあるにはあるが癖の多いSQL 全部俺　#3 データ型確認したい時あるんです
・標準はあるにはあるが癖の多いSQL 全部俺　#4 リテラル値での除算の内部精度も違うのよ!
・標準はあるにはあるが癖の多いSQL 全部俺　#5 和暦変換機能ある方が少数派
・標準はあるにはあるが癖の多いSQL 全部俺　#6 時間厳守！
・標準はあるにはあるが癖の多いSQL 全部俺　#7 期間リテラル！
・標準はあるにはあるが癖の多いSQL 全部俺　#8 翌月末日って何日？

投稿日時 2020年12月 9日 (水) 00時00分 Oracle, SQL, MySQL, PostgreSQL, Advent Calendar | 固定リンク | 0 | コメント (0)

2020年12月 8日 (火)

標準はあるにはあるが癖の多いSQL 全部俺　#8 翌月末日って何日？

標準はあるにはあるが癖の多いSQL 全部俺w Advent Calendar 2020の8日目です。

日付関連の非互換はネタが沢山w　

翌月末日って何日？　を求める場合にも違いがあります。ほんとにもうww

Oracle

Oracleには、last_day()関数ががあります。date型の引数をとるので期間リテラルと演算可能。
では、Oracleで翌月末日を求めてみる。シンプルですね。

LAST_DAY(date)
https://docs.oracle.com/en/database/oracle/oracle-database/19/sqlrf/LAST_DAY.html#GUID-296C7C02-7FB9-4AAC-8927-6A79320CE0C6

ORACLE> alter session set nls_date_format = 'yyyy-mm-dd'; Session altered. ORACLE> select last_day(sysdate + interval '1' month) from dual; LAST_DAY(S ---------- 2021-01-31

Mysql

MySQLにもOracle同様にlast_day()関数を使って、簡単に「翌月末日って何日？」を求めることができますよね。

LAST_DAY(date)
https://dev.mysql.com/doc/refman/8.0/en/date-and-time-functions.html

mysql> select last_day(curdate() + interval 1 month); +----------------------------------------+ | last_day(curdate() + interval 1 month) | +----------------------------------------+ | 2021-01-31 | +----------------------------------------+ 1 row in set (0.03 sec)

Postgresql

なぜか、昔から頑なに　last_day()関数がありません。UDFで頑張るか、ちょいと頑張って「翌月末日って何日？」を求めなければいけません。
翌々月１日の前日が「翌月末日って何日？」なので、その方法で求めてみます。やれやれ、last_day()ってUDF作った方が楽そうですねw

N/A
https://www.postgresql.jp/document/12/html/functions-datetime.html

postgres=> select cast(date_trunc('month', current_date + interval '2 month') - interval '1 day' as date); date ------------ 2021-01-31 (1 row)

Redshift

PostgreSQLの流れを汲むRedshiftですが、last_day()関数ありました！ PostgreSQLに、もしあればこんな構文だろうと想像します。

LAST_DAY ( { date | timestamp } )
https://docs.aws.amazon.com/ja_jp/redshift/latest/dg/r_LAST_DAY.html

redshift=# select last_day(current_date + interval '1 month'); last_day ------------ 2021-01-31 (1 row)

ブログ書きながら寝落ちしてたw

実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺） Advent Calendar 2019

・標準はあるにはあるが癖の多いSQL 全部俺　#1 Pagination
・標準はあるにはあるが癖の多いSQL 全部俺　#2 関数名は同じでも引数が逆の罠！
・標準はあるにはあるが癖の多いSQL 全部俺　#3 データ型確認したい時あるんです
・標準はあるにはあるが癖の多いSQL 全部俺　#4 リテラル値での除算の内部精度も違うのよ!
・標準はあるにはあるが癖の多いSQL 全部俺　#5 和暦変換機能ある方が少数派
・標準はあるにはあるが癖の多いSQL 全部俺　#6 時間厳守！
・標準はあるにはあるが癖の多いSQL 全部俺　#7 期間リテラル！

投稿日時 2020年12月 8日 (火) 00時32分 Oracle, FAQ, SQL, MySQL, PostgreSQL, AWS | 固定リンク | 0 | コメント (0)

2020年12月 7日 (月)

標準はあるにはあるが癖の多いSQL 全部俺　#7 期間リテラル！

標準はあるにはあるが癖の多いSQL 全部俺w Advent Calendar 2020の7日目です。

さて、日付関連は非互換の宝庫ではありますが、ほんとなんで違うの。。。と言う微妙な違いだったり、キーーーーってなりますよね。なぜ合わせられないw

今日は期間リテラル。

Oracle

期間リテラル
https://docs.oracle.com/cd/F19136_01/sqlrf/Literals.html#GUID-49FADC66-794D-4763-88C7-B81BB4F26D9E

SQL> ALTER SESSION SET NLS_DATE_FORMAT = 'yyyy-mm-dd'; セッションが変更されました。 SQL> SELECT SYSDATE + INTERVAL '10' DAY FROM DUAL; SYSDATE+IN ---------- 2020-12-16

MySQL

Temporal Intervals
https://dev.mysql.com/doc/refman/8.0/en/expressions.html#temporal-intervals

mysql> SELECT CURDATE() + INTERVAL 10 DAY; +-----------------------------+ | curdate() + interval 10 day | +-----------------------------+ | 2020-12-16 | +-----------------------------+ 1 row in set (0.00 sec)

PostgreSQL

8.5. 日付/時刻データ型
https://www.postgresql.jp/document/12/html/datatype-datetime.html

sql=> SELECT CAST(CURRENT_DATE + INTERVAL '10 DAY' AS DATE); date ------------ 2020-12-16 (1 row)

実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺） Advent Calendar 2020

・標準はあるにはあるが癖の多いSQL 全部俺　#1 Pagination
・標準はあるにはあるが癖の多いSQL 全部俺　#2 関数名は同じでも引数が逆の罠！
・標準はあるにはあるが癖の多いSQL 全部俺　#3 データ型確認したい時あるんです
・標準はあるにはあるが癖の多いSQL 全部俺　#4 リテラル値での除算の内部精度も違うのよ!/a>
・標準はあるにはあるが癖の多いSQL 全部俺　#5 和暦変換機能ある方が少数派
・標準はあるにはあるが癖の多いSQL 全部俺　#6 時間厳守！

投稿日時 2020年12月 7日 (月) 00時00分 Oracle, FAQ, SQL, MySQL, PostgreSQL, Advent Calendar | 固定リンク | 0 | コメント (0)

2020年12月 6日 (日)

標準はあるにはあるが癖の多いSQL 全部俺　#6 時間厳守！

標準はあるにはあるが癖の多いSQL 全部俺w Advent Calendar 2020の6日目です。

日付、日時関連も非互換の多い部分ですね。

該当関数の挙動を見てみると違いと、以外と違いがあるので面白いですよ。日付、日時関数って多くて全てを取り上げてると大変なので、今回は、OracleのSYSDATEを取り上げて、PostgreSQLではどれ使うのがいいのかなぁ

と言うところを見ていきたいと思います。

まず、このエントリー内で利用している、関数の特性を示す単語の意味を定義しておきたいと思います。

・同一SQL文の上で何度callされても同じ日時を返す特性：文内同一
・同一SQL文の上でcallされる毎に異なる日時を返す特性：文内非同一
・同一トランザクション内で何度callしても同一日時を返す特性：トランザクション内同一
・同一トランザクション内でcallされる毎に異なる日時を返す特性：トランザクション内非同一

関数としては沢山ありすぎて個別に調査した内容を個別に書こうと思うと、アドベントカレンダーの一エントリーとして終わる気がししないのでw

軽めに書いてもこんな感じw

SYSDATEはタイムゾーンを持たないので、PostgreSQLのCURRENT_DATEかなー、と思ってしまうと大きな間違いで、もっとも挙動として近いのは、Oracleで利用していたタイムゾーンに合わせる形で利用するPostgreSQLのstatement_timestamp()と言うことになる。
有名なOrafceで提供されている oracle.sysdate()　も中を覗いてみると、statement_timestamp() が利用されている。

このエントリーの後半で挙動の確認方法と oracle.sysdate()　が　statement_timestamp()　を利用しているソースを記載しています。

Oracle Database

SYSDATE
https://docs.oracle.com/cd/E82638_01/sqlrf/SYSDATE.html#GUID-807F8FC5-D72D-4F4D-B66D-B0FE1A8FA7D2

年月日時分秒タイムゾーンなし

特性
文内同一、トランザクション内非同一

SYSTIMESTAMP
https://docs.oracle.com/cd/E82638_01/sqlrf/SYSTIMESTAMP.html#GUID-FCED18CE-A875-4D5D-9178-3DE4FA956516

年月日時分秒.秒未満精度(9) タイムゾーンあり

特性
文内同一、ランザクション内非同一

CURRENT_DATE
https://docs.oracle.com/cd/E82638_01/sqlrf/CURRENT_DATE.html#GUID-96795097-D6F0-4288-90E7-9D7C49B4F6E5

年月日時分秒タイムゾーンなし

特性
文内同一、トランザクション内非同一

CURRENT_TIMESTAMP
https://docs.oracle.com/cd/E82638_01/sqlrf/CURRENT_TIMESTAMP.html#GUID-CBD42B84-869D-45C7-9FFC-001DD7712097

年月日時分秒.秒未満精度(9) タイムゾーンあり

特性
文内同一、トランザクション内非同一

LOCALTIMESTAMP
https://docs.oracle.com/cd/E82638_01/sqlrf/LOCALTIMESTAMP.html#GUID-3C3D1F29-5F53-41F2-B2D6-A3767DFB22CA

年月日時分秒.秒未満精度(9) タイムゾーンなし

特性
文内同一、トランザクション内非同一

PostgreSQL
PostgreSQLのtimestamp型の秒未満精度は最大6桁であるため、Oracleのtimestamp型の最大精度より低いことに注意
https://www.postgresql.jp/document/12/html/functions-datetime.html

CURRENT_DATE
年月日（PostgreSQLのDATE型で返す）タイムゾーンなし

特性
文内同一、トランザクション内同一

CURRENT_TIMESTAMP
年月日時分秒.秒未満精度(6) タイムゾーンあり

特性
文内同一、トランザクション内同一

LOCALTIMESTAMP
年月日時分秒.秒未満精度(6) タイムゾーンなし

特性
文内同一、トランザクション内同一

clock_timestamp()
年月日時分秒.秒未満精度(6) タイムゾーンあり

特性
文内非同一、トランザクション内非同一

transaction_timestamp()
CURRENT_TIMESTAMPに同じ
関数名が具体的に何を返すか明確になっている点の違いのみ

特性
文内同一、トランザクション内同一

statement_timestamp()
年月日時分秒.秒未満精度(6) タイムゾーンあり

特性
文内同一、トランザクション内非同一
statement_timestamp()が、もっともOracleのSYSDATE/SYSTIMESTAMPに近い挙動を示す

now()
transaction_timestamp()の別名
利用することは推奨されていない（何を返すかわかりにくい関数名である影響と思われる)

特性
文内同一、トランザクション内同一

例

Oracle Database

トランザクション内同一性の確認（1秒間隔で3回実行）
Oracle Databaseの日付時刻関数は、トランザクション内非同一。

SYSDATE SYSTIMESTAMP -------------------- ---------------------------------------- 2020/11/08 16:12:03 2020/11/08 16:12:03.345275 +00:00 2020/11/08 16:12:04 2020/11/08 16:12:04.397601 +00:00 2020/11/08 16:12:05 2020/11/08 16:12:05.475719 +00:00 LOCALTIMESTAMP CURRENT_DATE CURRENT_TIMESTAMP ------------------------------ -------------------- ---------------------------------------- 2020/11/09 01:12:03.345277 2020/11/09 01:12:03 2020/11/09 01:12:03.345277 +09:00 2020/11/09 01:12:04.397603 2020/11/09 01:12:04 2020/11/09 01:12:04.397603 +09:00 2020/11/09 01:12:05.475721 2020/11/09 01:12:05 2020/11/09 01:12:05.475721 +09:00

文内同一性の確認（最後のカラムは、1秒待機後に返すようにして実行）
(ore_sleep()と言うUDFを作成し、内部で（Oracle 18cまで）dbms_lock.sleep(1) or （Oracle 19c以降）dbms_session.sleep(1) を実行)

以下の結果から、Oracle Databaseの日付時刻関数は、すべて文内同一。

SQL> SELECT sysdate, sysdate, ORE_SLEEP(1), sysdate FROM dual; SYSDATE SYSDATE ORE_SLEEP(1) SYSDATE ------------------- ------------------- -------------- ------------------- 2020/11/21 05:49:46 2020/11/21 05:49:46 0 2020/11/21 05:49:46 SQL> r 1 SELECT 2 systimestamp, systimestamp, ORE_SLEEP(1), systimestamp 3 FROM 4* dual SYSTIMESTAMP SYSTIMESTAMP OREO_SLEEP(1) SYSTIMESTAMP ---------------------------------------- ---------------------------------------- -------------- ---------------------------------------- 2020/11/21/05:48:19.459180 +00:00 2020/11/21/05:48:19.459180 +00:00 0 2020/11/21/05:48:19.459180 +00:00 SQL> r 1 SELECT 2 localtimestamp,localtimestamp,ORE_SLEEP(1),localtimestamp 3 FROM 4* dual LOCALTIMESTAMP LOCALTIMESTAMP ORE_SLEEP(1) LOCALTIMESTAMP ---------------------------------------- ---------------------------------------- -------------- ---------------------------------------- 2020/11/21 14:58:13.350655 2020/11/21 14:58:13.350655 0 2020/11/21 14:58:13.350655 SQL> r 1 SELECT 2 current_date,current_date,ORE_SLEEP(1),current_date 3 FROM 4* dual CURRENT_DATE CURRENT_DATE ORE_SLEEP(1) CURRENT_DATE ------------------- ------------------- -------------- ------------------- 2020/11/21 14:59:47 2020/11/21 14:59:47 0 2020/11/21 14:59:47 SQL> r 1 SELECT 2 current_timestamp,current_timestamp,ORE_SLEEP(1),current_timestamp 3 FROM 4* dual CURRENT_TIMESTAMP CURRENT_TIMESTAMP ORE_SLEEP(1) CURRENT_TIMESTAMP ---------------------------------------- ---------------------------------------- -------------- ---------------------------------------- 2020/11/21/15:00:41.661495 +09:00 2020/11/21/15:00:41.661495 +09:00 0 2020/11/21/15:00:41.661495 +09:00

PostgreSQL

トランザクション内同一性の確認（1秒間隔で3回実行）
PostgreSQLの日付時刻関数は、トランザクション内同一と非同一が混在

CURRENT_DATEは時刻を持たないためこの方法では検証不能だが、
マニュアルではトランザクション内で同一と記載されている。
clock_timestamp(),statement_timestamp()はトランザクション内非同一、それ以外は、トランザクション内同一。

current_date | current_timestamp | --------------+-------------------------------+ 2020-11-08 | 2020-11-08 16:12:05.897343+00 | 2020-11-08 | 2020-11-08 16:12:05.897343+00 | 2020-11-08 | 2020-11-08 16:12:05.897343+00 | clock_timestamp | localtimestamp | ------------------------------+----------------------------+ 2020-11-08 16:12:05.936468+00 | 2020-11-08 16:12:05.897343 | 2020-11-08 16:12:07.304506+00 | 2020-11-08 16:12:05.897343 | 2020-11-08 16:12:08.532788+00 | 2020-11-08 16:12:05.897343 | now | statement_timestamp | transaction_timestamp ------------------------------+-------------------------------+------------------------------- 2020-11-08 16:12:05.897343+00 | 2020-11-08 16:12:05.936423+00 | 2020-11-08 16:12:05.897343+00 2020-11-08 16:12:05.897343+00 | 2020-11-08 16:12:07.304408+00 | 2020-11-08 16:12:05.897343+00 2020-11-08 16:12:05.897343+00 | 2020-11-08 16:12:08.532704+00 | 2020-11-08 16:12:05.897343+00

文内同一性の確認（最後のカラムは、1秒待機後に返すようにして実行）
以下の結果から、PostgreSQL日付時刻関数は、文内同一/非同一混在。

current_dateについてはこの方法では検証できないが、ドキュメントより文内同一であると判断。

sql=> SELECT sql-> current_date, current_date, pg_sleep(1), current_date; current_date | current_date | pg_sleep | current_date --------------+--------------+----------+-------------- 2020-11-21 | 2020-11-21 | | 2020-11-21

文内同一

sql=> SELECT sql-> current_timestamp,current_timestamp,pg_sleep(1),current_timestamp; current_timestamp | current_timestamp | pg_sleep | current_timestamp -------------------------------+-------------------------------+----------+------------------------------- 2020-11-21 06:05:48.930432+00 | 2020-11-21 06:05:48.930432+00 | | 2020-11-21 06:05:48.930432+00

文内非同一

sql=> SELECT sql-> clock_timestamp(),clock_timestamp(),pg_sleep(1),clock_timestamp(); clock_timestamp | clock_timestamp | pg_sleep | clock_timestamp -------------------------------+-------------------------------+----------+------------------------------- 2020-11-21 06:08:48.920466+00 | 2020-11-21 06:08:48.920466+00 | | 2020-11-21 06:08:49.925492+00

文内同一

sql=> SELECT sql-> localtimestamp,localtimestamp,pg_sleep(1),localtimestamp; localtimestamp | localtimestamp | pg_sleep | localtimestamp ----------------------------+----------------------------+----------+---------------------------- 2020-11-21 06:19:19.547055 | 2020-11-21 06:19:19.547055 | | 2020-11-21 06:19:19.547055

文内同一

sql=> SELECT sql-> now(),now(),pg_sleep(1),now(); now | now | pg_sleep | now -------------------------------+-------------------------------+----------+------------------------------- 2020-11-21 06:20:07.457373+00 | 2020-11-21 06:20:07.457373+00 | | 2020-11-21 06:20:07.457373+00

文内同一

sql=> SELECT sql-> statement_timestamp(),statement_timestamp(),pg_sleep(1),statement_timestamp(); statement_timestamp | statement_timestamp | pg_sleep | statement_timestamp -------------------------------+-------------------------------+----------+------------------------------- 2020-11-21 06:20:52.502137+00 | 2020-11-21 06:20:52.502137+00 | | 2020-11-21 06:20:52.502137+00

文内同一

sql=> SELECT sql-> transaction_timestamp(),transaction_timestamp(),pg_sleep(1),transaction_timestamp(); transaction_timestamp | transaction_timestamp | pg_sleep | transaction_timestamp -------------------------------+-------------------------------+----------+------------------------------- 2020-11-21 06:21:24.562833+00 | 2020-11-21 06:21:24.562833+00 | | 2020-11-21 06:21:24.562833+00

orafce によるエミュレーション関数（参考)
https://github.com/orafce/orafce/blob/master/README.asciidoc

oracle.sysdate()
PostgreSQLのstatement_timestamp()をラップしているため属性はstatement_timestamp()と同じ
sysdate関数のエミュレーションとしては最も近い属性を持っていると見られる。
OracleのSYSDATE代替関数とされている。
特性としては、問題ないと考えられ、文内同一 (OracleのSYSDATEと同じ挙動）,トランザクション内非同一（OracleのSYSDATEと同じ挙動）

実装を見てみると、

https://github.com/orafce/orafce/blob/master/orafce--3.14.sql
の関数定義を見るとC言語の関数であり、statement_timestampをと言うコメントがある.　
statement_timestamp()がOracleのSYSDATEの挙動に近いと言う理由からなのだろうと想像する。納得感あり！！！！

CREATE FUNCTION oracle.sysdate() RETURNS oracle.date AS 'MODULE_PATHNAME','orafce_sysdate' LANGUAGE C STABLE STRICT; COMMENT ON FUNCTION oracle.sysdate() IS 'Ruturns statement timestamp at server time zone';

さらに、orafceのoracle.sysdate()のC言語のソースを追ってみる。。。
datefce.cのorafce_sysdateが本体であることがわかる
https://github.com/orafce/orafce/blob/master/builtins.h

extern PGDLLEXPORT Datum orafce_sysdate(PG_FUNCTION_ARGS);

https://github.com/orafce/orafce/blob/master/datefce.c

/******************************************************************** * * ora_sysdate - sysdate * * Syntax: * * timestamp sysdate() * * Purpose: * * Returns statement_timestamp in server time zone * Note - server time zone doesn't exists on PostgreSQL - emulated * by orafce_timezone * ********************************************************************/ Datum orafce_sysdate(PG_FUNCTION_ARGS) { Datum sysdate; Datum sysdate_scaled; sysdate = DirectFunctionCall2(timestamptz_zone, CStringGetTextDatum(orafce_timezone), TimestampTzGetDatum(GetCurrentStatementStartTimestamp())); /* necessary to cast to timestamp(0) to emulate Oracle's date */ sysdate_scaled = DirectFunctionCall2(timestamp_scale, sysdate, Int32GetDatum(0)); PG_RETURN_DATUM(sysdate_scaled); }

および、GetCurrentStatementStartTimestamp()よりstatement_timestamp()であることがわかる
https://docs.huihoo.com/doxygen/postgresql/backend_2utils_2adt_2timestamp_8c_source.html#l01239

01239 statement_timestamp(PG_FUNCTION_ARGS) 01240 { 01241 PG_RETURN_TIMESTAMPTZ(GetCurrentStatementStartTimestamp()); 01242 }

Oracleの検証に利用したコード、昔は、DBMS_LOCK.SLEEP()ってなんでDBMS_LOCKパッケージにあるの？　と言う感じだったが、最近はわかりやすいDBMS_SESSIONパッケージが推奨で、DBMS_LOCK.SLEEP()は非推奨なのでご注意を

ore_seep(seonds) - UDF sample CREATE OR REPLACE FUNCTION ore_sleep ( seconds NUMBER ) RETURN NUMBER AS BEGIN $IF DBMS_DB_VERSION.VER_LE_12 $THEN DBMS_LOCK.SLEEP(seconds); $ELSE DBMS_SESSION.SLEEP(seconds); $END RETURN 0; END; /

実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺） Advent Calendar 2020

・標準はあるにはあるが癖の多いSQL 全部俺　#1 Pagination
・標準はあるにはあるが癖の多いSQL 全部俺　#2 関数名は同じでも引数が逆の罠！
・標準はあるにはあるが癖の多いSQL 全部俺　#3 データ型確認したい時あるんです
・標準はあるにはあるが癖の多いSQL 全部俺　#4 リテラル値での除算の内部精度も違うのよ!/a>
・標準はあるにはあるが癖の多いSQL 全部俺　#5 和暦変換機能ある方が少数派

投稿日時 2020年12月 6日 (日) 12時49分 Oracle, FAQ, SQL, PostgreSQL, Advent Calendar | 固定リンク | 0 | コメント (0)

2020年12月 5日 (土)

標準はあるにはあるが癖の多いSQL 全部俺　#5 和暦変換機能ある方が少数派

標準はあるにはあるが癖の多いSQL 全部俺w Advent Calendar 2020の5日目です。

これもあるのが当たり前だよねーと思っていると、ないの！！　と言うありがちなネタで、日付の和暦変換など、

Oracleだとグローバリゼーション対応で組み込まれてます。昨年令和に切り替わったばかりなので、Oracleが中心の方々は、MySQLやPostgreSQL界隈は大丈夫なの？間に合うの？なんて話題も多かったことだろうと思います。
私もそうでした。でも心配する必要のあるのはOracleだけだったw と言う取り越し苦労でした。はい。

まず、Oracle

SCOTT@orcl> r 1 SELECT 2 TO_CHAR( 3 SYSDATE 4 , 'EEYY/MM/DD' 5 , 'NLS_CALENDAR = ''JAPANESE IMPERIAL''' 6 ) 7 FROM 8* DUAL TO_CHAR(SYSDATE,'EEYY/MM/DD','NLS_CALE -------------------------------------- 令和02/12/05 経過: 00:00:00.01 SCOTT@orcl>

Oracle 19c - Databaseグローバリゼーション・サポート・ガイド 3.7.1.4 紀元の年
https://docs.oracle.com/cd/F19136_01/nlspg/setting-up-globalization-support-environment.html#GUID-9674F2F3-D3A2-436A-83D1-7A8AC0D2B1ED

実は、年号が平成から令和切り替わると言う時になって始めて知ったのですが、みんな対応しているわけではないのですね。。和暦。
そう言う意味では、顧客要求をしっかり拾っていたと言うことなのでしょうね。

まだまだ、知らないことが多いSQLな世界w　

PostgreSQL

ないのでUDF等で対応ですよね

PostgreSQLの新元号への対応について
https://www.ashisuto.co.jp/support/gengo/product/postgresql.html

MySQL

ないのでUDF等で対応ですよね

と言うことで、RDS/Auroraにつても同様 この記事、現在は　Snowflake - Principal Cloud Support Engineer の松崎さんの記事ですね！
https://aws.amazon.com/jp/blogs/news/how-to-determine-whether-kaigen-japan-era-name-transition-affects-your-mysql-compatible-engines-running-on-rds/"

Redshift
ないので、必要ならUDF等で対応ですよね

実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺） Advent Calendar 2019

・標準はあるにはあるが癖の多いSQL 全部俺　#1 Pagination
・標準はあるにはあるが癖の多いSQL 全部俺　#2 関数名は同じでも引数が逆の罠！
・標準はあるにはあるが癖の多いSQL 全部俺　#3 データ型確認したい時あるんです
・標準はあるにはあるが癖の多いSQL 全部俺　#4 リテラル値での除算の内部精度も違うのよ!/a>

投稿日時 2020年12月 5日 (土) 13時40分 Oracle, SQL, MySQL, PostgreSQL, AWS | 固定リンク | 0 | コメント (0)

2020年12月 4日 (金)

標準はあるにはあるが癖の多いSQL 全部俺　#4 リテラル値での除算の内部精度も違うのよ!

標準はあるにはあるが癖の多いSQL 全部俺w Advent Calendar 2020の4日目です。

モルダー、あなた疲れてるのよ！　的なタイトルになってしまったw

エラーにはならないけど、この手の差異もなかなか嫌らしい差異ですよね。

結論から言うと、この差異の影響を避けるためにはデフォルトの挙動任せは危険かな。と言うことになるのですが、まあ、色々ありますよね。長いこと同じエンジン使って他ところへ乗り換えるとなると。

Oracle Database

なお、SQL*plusのnumformatパラメータは未設定の状態（デフォルト）です。

SQL> SELECT CAST((1.0/6.0) AS NUMBER(38,37)) FROM DUAL;

リテラル値の除算結果は小数点以下1桁の状態でデフォルトのキャストを利用した場合、内部的に小数点以下37桁精度。
実は、表示されている桁数は、SQL*Plusのnumformatの影響を受け、numformat(デフォルト小数点以下7桁)で丸る

一見小数点以下8桁に見えるが、

SQL> SELECT CAST((9/7) AS NUMBER(38,37)) FROM DUAL; CAST((9/7)ASNUMBER(38,37)) -------------------------- 1.28571429

numformatの桁数を大きくすると内部的は小数点以下37桁精度！

SQL> set numformat "0.0999999999999999999999999999999999999" SQL> SELECT CAST((9/7) AS NUMBER(38,37)) FROM DUAL; CAST((9/7)ASNUMBER(38,37)) ---------------------------------------- 1.2857142857142857142857142857142857143

ね！

SQL> SELECT CAST((9.0/7.0) AS NUMBER(38,37)) FROM DUAL; CAST((9.0/7.0)ASNUMBER(38,37)) ---------------------------------------- 1.2857142857142857142857142857142857143 SQL> SELECT CAST(CAST(9.0 AS NUMBER(38,37))/CAST(7.0 AS NUMBER(38,37)) AS NUMBER(38,37)) FROM DUAL; CAST(CAST(9.0ASNUMBER(38,37))/CAST(7.0ASNUMBER(38,37))ASNUMBER(38,37)) ---------------------------------------------------------------------- 1.2857142857142857142857142857142857143 SQL> SELECT CAST(CAST(9.0 AS NUMBER(38,37))/CAST(7.0 AS NUMBER(38,37)) AS NUMBER(38,37)) FROM DUAL; CAST(CAST(9.0ASNUMBER(38,37))/CAST(7.0ASNUMBER(38,37))ASNUMBER(38,37)) ---------------------------------------------------------------------- 1.2857142857142857142857142857142857143

Oracleの場合、返却時の精度が全ての計算精度に影響

SQL> SELECT CAST(CAST(9.0 AS NUMBER(38,8))/CAST(7.0 AS NUMBER(38,8)) AS NUMBER(38,37)) FROM DUAL; CAST(CAST(9.0ASNUMBER(38,8))/CAST(7.0ASNUMBER(38,8))ASNUMBER(38,37)) -------------------------------------------------------------------- 1.2857142857142857142857142857142857143 SQL> SELECT CAST(CAST(9.0 AS NUMBER(38,8))/CAST(7.0 AS NUMBER(38,8)) AS NUMBER(38,8)) FROM DUAL; CAST(CAST(9.0ASNUMBER(38,8))/CAST(7.0ASNUMBER(38,8))ASNUMBER(38,8)) ------------------------------------------------------------------- 1.2857142900000000000000000000000000000 SQL> SELECT CAST(CAST(9.0 AS NUMBER(38,37))/CAST(7.0 AS NUMBER(38,37)) AS NUMBER(38,8)) FROM DUAL; CAST(CAST(9.0ASNUMBER(38,37))/CAST(7.0ASNUMBER(38,37))ASNUMBER(38,8)) --------------------------------------------------------------------- 1.2857142900000000000000000000000000000 SQL> set numformat "0.09999999999999999999999999999999999999999999999" SQL> SELECT CAST((9/7) AS NUMBER(38,37)) FROM DUAL; CAST((9/7)ASNUMBER(38,37)) -------------------------------------------------- 1.28571428571428571428571428571428571430000000000 SQL> SELECT CAST((9.0/7.0) AS NUMBER(38,37)) FROM DUAL; CAST((9.0/7.0)ASNUMBER(38,37)) -------------------------------------------------- 1.28571428571428571428571428571428571430000000000 SQL> SELECT CAST(CAST(9.0 AS NUMBER(38,37))/CAST(7.0 AS NUMBER(38,37)) AS NUMBER(38,37)) FROM DUAL; CAST(CAST(9.0ASNUMBER(38,37))/CAST(7.0ASNUMBER(38,37))ASNUMBER(38,37)) ---------------------------------------------------------------------- 1.28571428571428571428571428571428571430000000000

PostgreSQLだとどうなるかと言うと、

整数として扱われ、除算結果もinteger型！

sql=> SELECT 9/7; ?column? ---------- 1 pg_typeof ----------- integer

リテラル値は小数点以下1桁の精度だが、除算結果は小数点以下16桁精度のnumeric型で返されるようだ。
PostgreSQLのマニュアルには記載されていないようだが、どこかに記載されてるのだろうか。。。知ってる方がいたらコメントお待ちしております。:)

sql=> SELECT 9.0/7.0; ?column? -------------------- 1.2857142857142857 pg_typeof ----------- numeric

小数点以下の精度0でnumeric型にキャスト**した場合も、除算結果は小数点以下16桁精度のnumeric型となるようだが、これもPostgreSQLのマニュアルには記載されていないようだ。
なお、PostgreSQLの場合numeric型へのキャストで指定できる最大精度は1000と記載され内部的にはそれ以上の精度となっている
詳細は　

8.1.2. 任意の精度を持つ数
https://www.postgresql.jp/document/11/html/datatype-numeric.html#DATATYPE-NUMERIC-DECIMAL

表8.2 数値データ型
https://www.postgresql.jp/document/11/html/datatype-numeric.html#DATATYPE-NUMERIC-TABLE
を参照のこと

sql=> SELECT 9::NUMERIC(100,0)/7::NUMERIC(100,0); ?column? -------------------- 1.2857142857142857 pg_typeof ----------- numeric

小数点以下精度1桁でnumeric型へキャスト**した場合も同様に、除算結果は小数点以下16桁のnumeric型になるのな。これ

sql=> SELECT 9::NUMERIC(100,1)/7::NUMERIC(100,1); ?column? -------------------- 1.2857142857142857 pg_typeof ----------- numeric

同様に小数点以下2桁でnumeric型へキャストし、除算した結果も小数点以下16桁精度のnumeric型として返される模様。

sql=> SELECT 9::NUMERIC(100,2)/7::NUMERIC(100,2); ?column? -------------------- 1.2857142857142857 pg_typeof ----------- numeric

小数点以下15桁のnumeric型にキャストした場合も結果は小数点以下16桁精度のnumeric型！

sql=> SELECT 9::NUMERIC(100,15)/7::NUMERIC(100,15); ?column? -------------------- 1.2857142857142857 pg_typeof ----------- numeric

小数点以下16桁のnumber型にキャストした場合は、指定したscaleで返された。

sql=> SELECT 9::NUMERIC(100,16)/7::NUMERIC(100,16); ?column? -------------------- 1.2857142857142857 pg_typeof -------------------- numeric

小数点以下17桁精度でnumeric型へキャストすると、指定した小数点以下17桁で除算結果が返された。
(どうやら、小数点以下16桁未満は小数点以下の精度を16桁として扱っているように見える

sql=> SELECT 9::NUMERIC(100,17)/7::NUMERIC(100,17); ?column? --------------------- 1.28571428571428571 pg_typeof ----------- numeric

表示される桁数が16桁なので内部も16桁かと思ったら、少々多めに持っているらしい。このあたりマニュアルに記載がない....
内部でも小数点以下16精度なのか？という疑問を確認するための確認の結果、小数点以下20桁なので多少大きめの精度で持っているだが、この辺りもPostgreSQLのマニュアルを見る限り記載されていないようだ。

sql=> SELECT CAST((1.0/6.0) AS NUMERIC(38,37)); numeric ----------------------------------------- 0.1666666666666666666700000000000000000

しかし、小数点以下1桁のリテラル値については、小数点以下16桁の精度で計算されてしまう。（ルールはあるようだがドキュメントに明確な記載が見当たらないのは辛いとこと。

sql=> SELECT CAST((9.0/7.0) AS NUMERIC (38,37)); numeric ----------------------------------------- 1.2857142857142857000000000000000000000

結局のところ、デフォルトの挙動に任せず、必要な精度にキャストすることで必要な精度を持たせるようにすることでOracleのデフォルトの挙動と同様の精度になりそう。これが無難な対応なんだろうね。

sql=> SELECT CAST((9.0::NUMERIC(38,37)/7.0::NUMERIC(38,37)) AS NUMERIC(38,37)); numeric ----------------------------------------- 1.2857142857142857142857142857142857143

PostgreSQLでは可能な精度の検証。Oracleからの移行ではここまでの精度は必要としない、よね。多分。

sql=> SELECT 9::NUMERIC(100,99)/7::NUMERIC(100,99); ?column? ------------------------------------------------------------------------------------------------------- 1.285714285714285714285714285714285714285714285714285714285714285714285714285714285714285714285714286 pg_typeof ----------- numeric

PostgreSQLで指定可能な最大精度（内部的な精度は1000を超えるがして可能な精度は1000)　　

試して！　Oracler皆びっくり！　な感じ

sql=> SELECT 9::NUMERIC(1000,999)/7::NUMERIC(1000,999);

そして、
計算結果とそれぞれのリテラル値の精度ではどちらが優先されるのか確認したところ、Oracleとは異なり、最大精度ではなく、リテラル値の制度が優先される結果となった。この点、Oracleからの移行では注意が必要かな。

以下は、小数点以下の精度を37桁に統一した結果だが、この場合Oracleと同様の精度の結果が得られる

sql=> SELECT (9.0::NUMERIC(38,37)/7.0::NUMERIC(38,37))::NUMERIC(38,37); numeric ----------------------------------------- 1.2857142857142857142857142857142857143

しかし、リテラル側の精度を落とし8桁にすると、16桁以下は全て16桁の精度になるという挙動が見られ流・

sql=> SELECT (9.0::NUMERIC(38,8)/7.0::NUMERIC(38,8))::NUMERIC(38,37); numeric ----------------------------------------- 1.2857142857142857000000000000000000000 sql=> SELECT (9.0::NUMERIC(38,16)/7.0::NUMERIC(38,16))::NUMERIC(38,37); numeric ----------------------------------------- 1.2857142857142857000000000000000000000

リテラル値の精度を17桁にすると、指定精度で結果を返すが、やはり計算結果の精度にはならない

sql=> SELECT (9.0::NUMERIC(38,17)/7.0::NUMERIC(38,17))::NUMERIC(38,37); numeric ----------------------------------------- 1.2857142857142857100000000000000000000

さらに、17桁の精度で計算し結果を16桁精度で返す例。

sql=> SELECT (9.0::NUMERIC(38,17)/7.0::NUMERIC(38,17))::NUMERIC(38,16); numeric -------------------- 1.2857142857142857

おまけ

Redshiftのnumeric型はPostgreSQL由来ではあるが、デフォルトの精度に関する挙動はPostgreSQLに近い。ただし、多少異なる部分もある。以下の例はPostgreSQL 11.xでは、小数点以下 20桁精度だったが、Redshiftでは16桁精度となっている。
微妙な違いだが違いがあるのは確かなので注意した方が良さげ

sql=# select cast((1.0/6.0) as numeric(38,37)); numeric ----------------------------------------- 0.1666666666666667000000000000000000000

噂のプログラム発動中だったのか。そんなの気にしてなかった。全くwwww

実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺） Advent Calendar 2019

・標準はあるにはあるが癖の多いSQL 全部俺　#1 Pagination
・標準はあるにはあるが癖の多いSQL 全部俺　#2 関数名は同じでも引数が逆の罠！
・標準はあるにはあるが癖の多いSQL 全部俺　#3 データ型確認したい時あるんです

投稿日時 2020年12月 4日 (金) 22時20分 Oracle, SQL, MySQL, PostgreSQL, AWS | 固定リンク | 0 | コメント (0)

2020年12月 3日 (木)

標準はあるにはあるが癖の多いSQL 全部俺　#3 データ型確認したい時あるんです

標準はあるにはあるが癖の多いSQL 全部俺w Advent Calendar 2020の3日目です。

忙しい、今年も勢いで始めた割には、事前にネタの構想があったわけでもないというギリギリの状態で書いてますがw
なんとか3つ目の窓をあけました。:)

今回は、データ型確認したいことありませんか？　という話。
Oracleを長年使い、PostgreSQL（互換含む）への移行という時に、調査していた時のこと、。。。

データ型見たいよね、これ。Oracleだとdump()で間接的にデータ型見れたなと。。。で他のエンジンではどうなのよ。。。と調べ始めたら結構大変でした。。
という２年半ぐらい前の苦労を思い出しつつ書いてみますw

調べていくと、わかりやすい関数名だったり、ありそうでないものもあるんですよね。。。。まさに、非互換の多い部分だった。。。

まず、Oracle
おなじみのdump()関数ですね。typ=nn の数字でデータ型を判断します. typ=2は、NUMBER型、typ=96は、CHAR型ですね。

SQL> select dump(123) from dual; DUMP(123) --------------------- Typ=2 Len=3: 194,2,24 SQL> select dump(123,8) from dual; DUMP(123,8) --------------------- Typ=2 Len=3: 302,2,30 SQL> select dump(123,10) from dual; DUMP(123,10) --------------------- Typ=2 Len=3: 194,2,24 SQL> select dump(123,16) from dual; DUMP(123,16) -------------------- Typ=2 Len=3: c2,2,18 SQL> select dump(123,17) from dual; DUMP(123,17) --------------------- Typ=2 Len=3: c2,^B,^X SQL> SQL> select dump('123',1016) from dual; DUMP('123',1016) -------------------------------------------- Typ=96 Len=3 CharacterSet=AL32UTF8: 31,32,33

次は、Postgresql

pg_typeof()って関数が使えます。結果がデータ型名で返されるのでわかりやすい！

sql=> select pg_typeof(123); pg_typeof ----------- integer (1 row) sql=> select pg_typeof('123'::text); pg_typeof ----------- text (1 row) sql=> select pg_typeof(now()); pg_typeof -------------------------- timestamp with time zone (1 row)

Athena

Prestoで使える関数なので、そのまま typeof()って関数でこれもデータ型名で返されます。
なぜ、Athenaかって？　勢いですかねぇ。

% aws athena start-query-execution --query-string "select typeof(123);" --result-configuration OutputLocation=s3://xxxx-athena-results -------------------------------------------------------------- | StartQueryExecution | +-------------------+----------------------------------------+ | QueryExecutionId | f658de1e-b711-433d-b603-15835b6e5de5 | +-------------------+----------------------------------------+ % % aws athena get-query-results --query-execution-id 92f46e33-0b2e-4e94-90b7-8acb3d6fce3b --output text | grep DATA DATA _col0 DATA integer

Redshift

N/A

MySQL
もし、あったらツッコミよろしくお願いします。 m(_ _)m

N/A
　

参考

Oracle - DUMP
https://docs.oracle.com/en/database/oracle/oracle-database/19/sqlrf/DUMP.html#GUID-A05793C9-B35D-4BA7-B68C-E3693BCF47A5

Oracle Built-in Data Types
https://docs.oracle.com/en/database/oracle/oracle-database/19/sqlrf/Data-Types.html#GUID-7B72E154-677A-4342-A1EA-C74C1EA928E6

PostgreSQL - 表9.63 システムカタログ情報関数 - pg_typeof
https://www.postgresql.jp/document/11/html/functions-info.html#FUNCTIONS-INFO-CATALOG-TABLE

Athena - 6.4. Conversion Functions - typeof
https://prestodb.io/docs/0.172/functions/conversion.html

実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺） Advent Calendar 2019

・標準はあるにはあるが癖の多いSQL 全部俺　#1 Pagination
・標準はあるにはあるが癖の多いSQL 全部俺　#2 関数名は同じでも引数が逆の罠！

投稿日時 2020年12月 3日 (木) 20時16分 Oracle, FAQ, SQL, MySQL, PostgreSQL, Advent Calendar, AWS | 固定リンク | 0 | コメント (0)

2020年12月 2日 (水)

標準はあるにはあるが癖の多いSQL 全部俺　#2 関数名は同じでも引数が逆の罠！

標準はあるにはあるが癖の多いSQL 全部俺w Advent Calendar 2020の2日目です。

今日は、心と時間の余裕がないので、軽めですw

いきなりですがタイトルの通り、関数名が同じなら引数の並びや数も一緒だ！

と決めつけちゃいけないw　案件です。　数時間ハマった挙句、マニュアルを読み直すという王道で解決した事案ですはい。マニュアル読みましょうね。読みづらいのもあるけど。。

現在の私、何をやってるかピンボケ感満載なロール名ではあるのですが、その名の通り、OracleのSQLで質問もうけるわ、たまには、SparkSQLでも質問受けたりしますw

そのSparkSQLでハマったのがrtrim(),ltrim()。

長年Oracleを使ってきたので、手癖でタイプしちゃうわけですよ！　思い込み、ダメ絶対！w

では、その大切なマニュアルの解説でRDBMSの有名どころのltrim/rtrimとSparkSQLのltrim/rtrimのシンタックスを確認してみましょう。

まず、Oracleは以下の通り。見たなれ安心感w

LTRIM( str [, trimStr] )str : トリムされるソースの文字列型または、リテラル文字列trimStr : トリムしたい文字列。デフォルトは、半角空白1文字
https://docs.oracle.com/cd/F19136_01/sqlrf/RTRIM.html#GUID-95A7DAFB-F7AB-48F4-BE24-64B3C7A840AA

次、PostgreSQL

RTRIM( str [, trimStr] )str : トリムされるソースの文字列型または、リテラル文字列trimStr : トリムしたい文字列。デフォルトは、半角空白1文字
https://www.postgresql.jp/document/11/html/functions-string.html

ついでなので、Redshift
PostgreSQLと同じですね。

RTRIM( string, trim_chars )　string : 切り捨てる文字列の列または式。 trim_chars : 末尾から切り捨てる文字を表す、文字列の列または式。
https://docs.aws.amazon.com/ja_jp/redshift/latest/dg/r_RTRIM.html

MySQL
MySQLのRTRIMには第二引数は無い! 単体では同じことができないので、他の関数と組み合わせるんでしょうね。（試してないですが）

RTRIM( str )str : トリムされるソースの文字列型または、リテラル文字列
https://dev.mysql.com/doc/refman/5.7/en/string-functions.html#function_rtrim

そして、最後に、今回ハマった
SparkSQL

RTRIM( [trimStr ,] str )str : トリムされるソースの文字列型または、リテラル文字列trimStr : トリムしたい文字列。デフォルトは、半角空白1文字
トリムしたい文字列の引数位置が、Oracle/PostgreSQL/Redshiftとは逆なので引数が少ないMySQLと異なりシンタックスエラーにならない＞＜
https://spark.apache.org/docs/2.3.1/api/sql/index.html#rtrim

rtrim()も同じです。

Oracle
https://docs.oracle.com/cd/F19136_01/sqlrf/RTRIM.html#GUID-95A7DAFB-F7AB-48F4-BE24-64B3C7A840AA

PostgreSQL
https://docs.oracle.com/cd/F19136_01/sqlrf/RTRIM.html#GUID-95A7DAFB-F7AB-48F4-BE24-64B3C7A840AA

Redshift
https://docs.oracle.com/cd/F19136_01/sqlrf/RTRIM.html#GUID-95A7DAFB-F7AB-48F4-BE24-64B3C7A840AA

MySQL
https://docs.oracle.com/cd/F19136_01/sqlrf/RTRIM.html#GUID-95A7DAFB-F7AB-48F4-BE24-64B3C7A840AA

SparkSQL
https://docs.oracle.com/cd/F19136_01/sqlrf/RTRIM.html#GUID-95A7DAFB-F7AB-48F4-BE24-64B3C7A840AA

簡単な例を

SparkSQL

>>> SQL="select rtrim('　', 'SparkSQL　') as d" >>> spark.sql(SQL).show() +--------+ | d | +--------+ |SparkSQL| +--------+

Oracle

SQL> select '|' || rtrim('SparkSQL ', ' ') || '|' as d from dual; D ---------- |SparkSQL|

PostgreSQL / Redshift

test=> select '|' || rtrim('SparkSQL ', ' ') || '|' as d; d ------------ |SparkSQL|

実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺） Advent Calendar 2019

・標準はあるにはあるが癖の多いSQL 全部俺　#1 Pagination

投稿日時 2020年12月 2日 (水) 18時31分 Oracle, FAQ, SQL, MySQL, PostgreSQL, Advent Calendar, AWS | 固定リンク | 0 | コメント (0)

2020年12月 1日 (火)

標準はあるにはあるが癖の多いSQL 全部俺　#1 Pagination

いよいよ始まりました。Advent Calendar 2020　
今年も勢いで全部俺ですw

JPOUG Advent Calendar 2020もよろしくお願いします！
（最後まで書けるのか、書き抜ける喜びw　どこかのCMっぽくなってしまいましたが、第一日めの窓を開けましょうw）

今年の全部俺はレントゲンではなく、標準はあれど、非常に癖の多いSQLを25回に渡り、眠い目を擦りながら書きづつけて行きたい（すでに希望になってるw）と思っております。はい。

先日、AthenaでLIMIT句使おうとして、エラーに遭遇したところからw

Oracle/MySQL/PostgreSQL/Redshiftとか LIMIT OFFSET的ところから違うわけですが（同じ部分もあります）、何も考えずに、Athenaに投げて、撃沈w
Prestoの311以降だとLIMIT OFFSETでPagination可能なわけですが、Amazon Athenaは今の所(2020/12/1現在）Presto 0.172なのをすっかり忘れてたわけです。はい。さーせん。

あ〜、SQLってバージョンでもそうですが、エンジン違えば、気が狂うw程度に違う時があって、き〜〜〜って。なることしばしば。
で、イラっとしたSQLの違いを Oracleの構文と比較しながら自分の備忘録として書いて残しておこうと思った次第です。

（なーんだ、自分の為か、と思わないでくださいね。明日はわが身かもしれませんよw）

以下、どの構文がどのエンジンで通るのかをざっとまとめたもの。

1.ROWNUMとWHERE句によるPagination
Oracle

SELECT id FROM ( SELECT ROWNUM as ln ,id FROM hoge ORDER BY id ) WHERE ln BETWEEN 1 AND 100;

2.ROW_NUMBER()ウィンドウ関数とWHERE句によるPagination
意外に使えるw　可読性悪いけどねー

Oracle / PostgreSQL / Redshift / Athena

SELECT id FROM ( SELECT ROW_NUMBER() OVER( ORDER BY id ) AS ln ,id FROM hoge ) WHERE ln BETWEEN 1 AND 100;

3.OFFSET句とFETCH FIRST n ROWS ONLYのPagination
Oracle / PostgreSQL

SELECT id FROM hoge ORDER BY id OFFSET 0 ROW FETCH FIRST 100 ROWS ONLY;

4.LIMIT句とOFFSET句のPagination
PostgreSQL / MySQL / Redshift

SELECT id FROM hoge ORDER BY id LIMIT 100 OFFSET 0;

ちなみに、Oracleでは、2.のROW_NUMBER()と3.のOFFSET + FETCHの構文の実行計画は同じなので、可読性が高い2.と3.いずれかと言われれば3.がおすすめ。

---------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ---------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 10 | 260 | 3 (0)| 00:00:01 | |* 1 | VIEW | | 10 | 260 | 3 (0)| 00:00:01 | |* 2 | WINDOW NOSORT STOPKEY| | 10 | 50 | 3 (0)| 00:00:01 | | 3 | INDEX FULL SCAN | HOGE_PK | 1000K| 4882K| 3 (0)| 00:00:01 | ----------------------------------------------------------------------------------- Predicate Information (identified by operation id): --------------------------------------------------- 1 - filter("LN">=1 AND "LN"<=100) 2 - filter(ROW_NUMBER() OVER ( ORDER BY "ID")<=100)

---------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ---------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 10 | 390 | 3 (0)| 00:00:01 | |* 1 | VIEW | | 10 | 390 | 3 (0)| 00:00:01 | |* 2 | WINDOW NOSORT STOPKEY| | 10 | 50 | 3 (0)| 00:00:01 | | 3 | INDEX FULL SCAN | HOGE_PK | 1000K| 4882K| 3 (0)| 00:00:01 | ----------------------------------------------------------------------------------- Predicate Information (identified by operation id): --------------------------------------------------- 1 - filter("from$_subquery$_002"."rowlimit_$$_rownumber"<=100 AND "from$_subquery$_002"."rowlimit_$$_rownumber">0) 2 - filter(ROW_NUMBER() OVER ( ORDER BY "ID")<=100)

参考
Oracle
https://docs.oracle.com/cd/E82638_01/sqlrf/ROWNUM-Pseudocolumn.html#GUID-2E40EC12-3FCF-4A4F-B5F2-6BC669021726
https://docs.oracle.com/cd/F19136_01/sqlrf/SELECT.html#GUID-CFA006CA-6FF1-4972-821E-6996142A51C6

MySQL
https://dev.mysql.com/doc/refman/8.0/en/select.html

PostgreSQL
https://www.postgresql.jp/document/11/html/queries-limit.html

Reshift
https://docs.aws.amazon.com/ja_jp/redshift/latest/dg/r_ORDER_BY_clause.html

Amazon Athena
https://docs.aws.amazon.com/ja_jp/athena/latest/ug/select.html

実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺） Advent Calendar 2019

寝ぼけながら書いているので、誤り等ございましたらご指摘願います。
仕事忙しいのに全部俺始めてしまい、かなり不安なスタートw（この時間だし）

投稿日時 2020年12月 1日 (火) 01時32分 Oracle, SQL, MySQL, PostgreSQL, Advent Calendar | 固定リンク | 0 | コメント (0)

2020年7月26日 (日)

RDS Oracle 雑多なメモ#21 / DBMS_DATAPUMPパッケージ　Schema mode de expdp/impdp - metadata onlyとデータのインポート

Previously, Mac De Oracle...

RDS Oracle 雑多なメモ#20 / DBMS_DATAPUMPパッケージ　Schema mode de expdp/impdpの準備 SQL_FILEモードでDDL抜き出し

でした。

今回は、RDS　Oracleへスキーマ単位のインポートでメタデータだけをインポートするにはどうするかというおはなし。

メタデータだけをインポートするにはこれまでに何度か話題にしたエクスポートされたオブジェクトとその階層を表すオブジェクトパスが重要な意味を持っています。

まずはフルエクスポートログにリストされるオブジェクトパスの例をご覧ください。

Processing object type DATABASE_EXPORT/EARLY_OPTIONS/VIEWS_AS_TABLES/TABLE_DATA Processing object type DATABASE_EXPORT/NORMAL_OPTIONS/TABLE_DATA Processing object type DATABASE_EXPORT/NORMAL_OPTIONS/VIEWS_AS_TABLES/TABLE_DATA Processing object type DATABASE_EXPORT/SCHEMA/TABLE/TABLE_DATA Processing object type DATABASE_EXPORT/SCHEMA/PACKAGE_BODIES/PACKAGE/PACKAGE_BODY Processing object type DATABASE_EXPORT/SCHEMA/TABLE/INDEX/STATISTICS/INDEX_STATISTICS Processing object type DATABASE_EXPORT/SCHEMA/TABLE/INDEX/STATISTICS/FUNCTIONAL_INDEX/INDEX_STATISTICS Processing object type DATABASE_EXPORT/SCHEMA/TABLE/STATISTICS/TABLE_STATISTICS Processing object type DATABASE_EXPORT/STATISTICS/MARKER Processing object type DATABASE_EXPORT/PRE_SYSTEM_IMPCALLOUT/MARKER Processing object type DATABASE_EXPORT/PRE_INSTANCE_IMPCALLOUT/MARKER Processing object type DATABASE_EXPORT/TABLESPACE Processing object type DATABASE_EXPORT/PROFILE Processing object type DATABASE_EXPORT/SCHEMA/USER Processing object type DATABASE_EXPORT/ROLE Processing object type DATABASE_EXPORT/RADM_FPTM Processing object type DATABASE_EXPORT/GRANT/SYSTEM_GRANT/PROC_SYSTEM_GRANT Processing object type DATABASE_EXPORT/SCHEMA/GRANT/SYSTEM_GRANT Processing object type DATABASE_EXPORT/SCHEMA/ROLE_GRANT Processing object type DATABASE_EXPORT/SCHEMA/DEFAULT_ROLE Processing object type DATABASE_EXPORT/SCHEMA/ON_USER_GRANT Processing object type DATABASE_EXPORT/SCHEMA/TABLESPACE_QUOTA Processing object type DATABASE_EXPORT/RESOURCE_COST Processing object type DATABASE_EXPORT/TRUSTED_DB_LINK Processing object type DATABASE_EXPORT/SCHEMA/SEQUENCE/SEQUENCE Processing object type DATABASE_EXPORT/DIRECTORY/DIRECTORY Processing object type DATABASE_EXPORT/DIRECTORY/GRANT/OWNER_GRANT/OBJECT_GRANT Processing object type DATABASE_EXPORT/DIRECTORY/GRANT/WITH_GRANT_OPTION/OBJECT_GRANT Processing object type DATABASE_EXPORT/CONTEXT Processing object type DATABASE_EXPORT/SCHEMA/PUBLIC_SYNONYM/SYNONYM Processing object type DATABASE_EXPORT/SCHEMA/TYPE/TYPE_SPEC Processing object type DATABASE_EXPORT/SYSTEM_PROCOBJACT/PRE_SYSTEM_ACTIONS/PROCACT_SYSTEM Processing object type DATABASE_EXPORT/SYSTEM_PROCOBJACT/PROCOBJ Processing object type DATABASE_EXPORT/SYSTEM_PROCOBJACT/POST_SYSTEM_ACTIONS/PROCACT_SYSTEM Processing object type DATABASE_EXPORT/SCHEMA/PROCACT_SCHEMA Processing object type DATABASE_EXPORT/EARLY_OPTIONS/VIEWS_AS_TABLES/TABLE Processing object type DATABASE_EXPORT/EARLY_POST_INSTANCE_IMPCALLOUT/MARKER Processing object type DATABASE_EXPORT/NORMAL_OPTIONS/TABLE

上記オブジェクトパスツリーを一部省略しつつ見やすくすると以下のようなツリー構造になっているのが理解しやすいはず。

図にも書いていますが、メタデータのみをインポートするにはデータを除外(Exclude)してしまえばよいわけです。

DATABASE_EXPORT/SCHEMA/TABLE/TABLE_DATA

また、同じツリーの階層にあるオブジェクトもスキーマレベルのインポートではインポートされないということも理解しやすいはずです。：）

なお、DATAPUMPが扱うオブジェクトパスの詳細は　
データベース・リファレンス - 6.238 SCHEMA_EXPORT_OBJECTS
を参照してくださいね。知らない方は多いですが、DATAPUMPと仲良くなるためには必要なビューです。

では、スキーマモードのメタデータオンリーインポートの仕込みから
同じデータベースへスキーマをインポートするので事前に削除しておきます。

BILL> drop user hoge cascade; User dropped. BILL> drop profile fizzbuzz; Profile dropped. BILL> drop role fizzbuzz; Role dropped. BILL> drop tablespace fizzbuzz including contents and datafiles; Tablespace dropped.

たとえばこの状態でスキーマレベルのインポートを行ってしまうと、もう、想像はできていると思いますが、依存オブジェクト不足によりインポートは失敗します。
ユーザーのデフォルト表領域や依存するプロファイルが存在しない状態ではインポート時に実行されるCREATE USER文がエラーとなりインポートはエラーで終了することになります。

BILL> @imp_schema_metadataonly data_pump_dir fullexp hoge Master table "BILL"."SYS_IMPORT_SCHEMA_03" successfully loaded/unloaded Starting "BILL"."SYS_IMPORT_SCHEMA_03": Processing object type DATABASE_EXPORT/SCHEMA/USER ORA-39083: Object type USER:"HOGE" failed to create with error: ORA-02380: profile FIZZBUZZ does not exist Failing sql is: CREATE USER "HOGE" IDENTIFIED BY VALUES ...中略... TABLESPACE "FIZZBUZZ" TEMPORARY TABLESPACE "TEMP" PROFILE "FIZZBUZZ" Processing object type DATABASE_EXPORT/SCHEMA/ROLE_GRANT ORA-39083: Object type ROLE_GRANT failed to create with error: ORA-01917: user or role 'HOGE' does not exist Failing sql is: GRANT "CONNECT" TO "HOGE" ORA-39083: Object type ROLE_GRANT failed to create with error: ORA-01924: role 'FIZZBUZZ' not granted or does not exist Failing sql is: GRANT "FIZZBUZZ" TO "HOGE" Processing object type DATABASE_EXPORT/SCHEMA/DEFAULT_ROLE ORA-39083: Object type DEFAULT_ROLE:"HOGE" failed to create with error: ORA-01918: user 'HOGE' does not exist ...中略... Job "BILL"."SYS_IMPORT_SCHEMA_03" completed with 7 error(s) at Fri Jul 24 17:51:45 2020 elapsed 0 00:00:03 PL/SQL procedure successfully completed.

では、上記のようなエラーを回避するため、前回フルエクスポートから取り出したDDL を実行して作成します。

BILL> CREATE BIGFILE TABLESPACE "FIZZBUZZ" DATAFILE 2 SIZE 104857600 3 AUTOEXTEND ON NEXT 104857600 MAXSIZE 1073741824 4 LOGGING ONLINE PERMANENT BLOCKSIZE 8192 5 EXTENT MANAGEMENT LOCAL AUTOALLOCATE DEFAULT 6 NOCOMPRESS SEGMENT SPACE MANAGEMENT AUTO; Tablespace created. BILL> CREATE ROLE "FIZZBUZZ"; Role created. BILL> CREATE PROFILE "FIZZBUZZ" 2 LIMIT 3 COMPOSITE_LIMIT DEFAULT 4 SESSIONS_PER_USER DEFAULT 5 CPU_PER_SESSION DEFAULT 6 CPU_PER_CALL DEFAULT 7 LOGICAL_READS_PER_SESSION DEFAULT 8 LOGICAL_READS_PER_CALL DEFAULT 9 IDLE_TIME UNLIMITED 10 CONNECT_TIME DEFAULT 11 PRIVATE_SGA DEFAULT 12 FAILED_LOGIN_ATTEMPTS DEFAULT 13 PASSWORD_LIFE_TIME DEFAULT 14 PASSWORD_REUSE_TIME DEFAULT 15 PASSWORD_REUSE_MAX DEFAULT 16 PASSWORD_VERIFY_FUNCTION DEFAULT 17 PASSWORD_LOCK_TIME DEFAULT 18 PASSWORD_GRACE_TIME DEFAULT 19 INACTIVE_ACCOUNT_TIME DEFAULT ; Profile created.

準備ができたので、メタデータオンリーのスキーマモードインポートを試してみます。
スキーマ以下のオブジェクトはインポート（統計情報をフィルタするのを忘れましたがw）できました。hoge表には1行だけデータがありますがデータはインポートされていないことが確認できるはずです。

BILL> @imp_schema_metadataonly data_pump_dir fullexp hoge Master table "BILL"."SYS_IMPORT_SCHEMA_04" successfully loaded/unloaded Starting "BILL"."SYS_IMPORT_SCHEMA_04": Processing object type DATABASE_EXPORT/SCHEMA/USER Processing object type DATABASE_EXPORT/SCHEMA/ROLE_GRANT Processing object type DATABASE_EXPORT/SCHEMA/DEFAULT_ROLE Processing object type DATABASE_EXPORT/SCHEMA/TABLESPACE_QUOTA Processing object type DATABASE_EXPORT/SCHEMA/PROCACT_SCHEMA Processing object type DATABASE_EXPORT/SCHEMA/TABLE/TABLE Processing object type DATABASE_EXPORT/SCHEMA/TABLE/STATISTICS/TABLE_STATISTICS Processing object type DATABASE_EXPORT/STATISTICS/MARKER Job "BILL"."SYS_IMPORT_SCHEMA_04" successfully completed at Fri Jul 24 17:56:34 2020 elapsed 0 00:00:13 PL/SQL procedure successfully completed. BILL> select username from dba_users where username='HOGE'; USERNAME ------------------------------ HOGE BILL> select count(1) from hoge.hoge; COUNT(1) ---------- 0

では次にデータだけをインポートしてみます。
TABLE_DATAのみをインポートする方法と、スキーマインポートで表が存在する場合に、データをTRUNCATE後、データインポートする方法があります。（表が存在している場合のデフォルトの動作はデータインポートのスキップです）
以下の例では通常のスキーマインポートで表が存在する場合、既存データをTRUNCATEしてデータをインポートする方法で行ってます。ユーザーが存在する場合にはCREATE USERは失敗し表が存在した場合にtruncate後にデータがインポートされます

BILL> @imp_schema data_pump_dir fullexp hoge Master table "BILL"."SYS_IMPORT_SCHEMA_01" successfully loaded/unloaded Starting "BILL"."SYS_IMPORT_SCHEMA_01": Processing object type DATABASE_EXPORT/SCHEMA/USER ORA-31684: Object type USER:"HOGE" already exists Processing object type DATABASE_EXPORT/SCHEMA/ROLE_GRANT Processing object type DATABASE_EXPORT/SCHEMA/DEFAULT_ROLE Processing object type DATABASE_EXPORT/SCHEMA/TABLESPACE_QUOTA Processing object type DATABASE_EXPORT/SCHEMA/PROCACT_SCHEMA Processing object type DATABASE_EXPORT/SCHEMA/TABLE/TABLE Table "HOGE"."HOGE" exists and has been truncated. Data will be loaded but all dependent metadata will be skipped due to table_exists_action of truncate Processing object type DATABASE_EXPORT/SCHEMA/TABLE/TABLE_DATA . . imported "HOGE"."HOGE" 5.046 KB 1 rows Processing object type DATABASE_EXPORT/SCHEMA/TABLE/STATISTICS/TABLE_STATISTICS Processing object type DATABASE_EXPORT/STATISTICS/MARKER Job "BILL"."SYS_IMPORT_SCHEMA_01" completed with 1 error(s) at Fri Jul 24 18:01:30 2020 elapsed 0 00:00:05 PL/SQL procedure successfully completed. BILL> select count(1) from hoge.hoge; COUNT(1) ---------- 1

スクリプトの例は以下のとおり
DBMS＿DATAPUMP．METADATA＿FILTER()プロシージャでデータを示すオブジェクトパス（DATABASE_EXPORT/SCHEMA/TABLE/TABLE_DATA）を除外しているところがポイント

BILL> !cat imp_schema_metadataonly.sql SET VERIFY OFF SET SERVEROUTPUT ON DECLARE v4Debug VARCHAR2(200); cDirectory CONSTANT VARCHAR2(30) := UPPER('&1'); cDumpFileName CONSTANT VARCHAR2(64) := '&2'||'.dmp'; cLogFileName CONSTANT VARCHAR2(64) := '&2'||'.log'; cSchemaName CONSTANT VARCHAR2(30) := UPPER('&3'); cExcludePath CONSTANT VARCHAR2(128) := 'DATABASE_EXPORT/SCHEMA/TABLE/TABLE_DATA'; i NUMBER; vDataPumpJobHandle NUMBER; vProgress_ratio NUMBER; vJobState VARCHAR2(30); oLogEntry ku$_LogEntry; oStatus ku$_Status; BEGIN DBMS_OUTPUT.ENABLE; v4Debug := 'OPEN'; vDataPumpJobHandle := DBMS_DATAPUMP.OPEN ( operation => 'IMPORT' ,job_mode => 'SCHEMA' ,job_name => NULL ,remote_link => NULL ); v4Debug := 'ADD_FILE - dumpfile'; DBMS_DATAPUMP.ADD_FILE ( handle => vDataPumpJobHandle ,filename => cDumpFileName ,directory => cDirectory ,filetype => DBMS_DATAPUMP.KU$_FILE_TYPE_DUMP_FILE ); v4Debug := 'ADD_FILE - logfile'; DBMS_DATAPUMP.ADD_FILE ( handle => vDataPumpJobHandle ,filename => cLogFileName ,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 => '''' || cSchemaName || '''' ); v4Debug := 'EXCLUDE_PATH='||cExcludePath; DBMS_DATAPUMP.METADATA_FILTER ( handle => vDataPumpJobHandle ,name => 'EXCLUDE_PATH_LIST' ,value => '''' || cExcludePath || '''' ); v4Debug := 'START_JOB'; DBMS_DATAPUMP.START_JOB ( handle => vDataPumpJobHandle ); 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 ); 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; DBMS_DATAPUMP.DETACH(vDataPumpJobHandle); EXCEPTION WHEN OTHERS THEN DBMS_OUTPUT.PUT_LINE(sqlerrm()); DBMS_OUTPUT.PUT_LINE(v4Debug); RAISE; END; / UNDEFINE 1 UNDEFINE 2 UNDEFINE 3 SET SERVEROUTPUT OFF SET VERIFY ON

DBMS_DATAPUMP.SET_PARAMETER()でTABLE_EXISTS_ACTION (表が存在する場合)でTRUNCATE（既存データのトランケート後データをインポート)する支持をしています。

BILL> !cat imp_schema.sql SET VERIFY OFF SET SERVEROUTPUT ON DECLARE v4Debug VARCHAR2(200); cDirectory CONSTANT VARCHAR2(30) := UPPER('&1'); cDumpFileName CONSTANT VARCHAR2(64) := '&2'||'.dmp'; cLogFileName CONSTANT VARCHAR2(64) := '&2'||'.log'; cSchemaName CONSTANT VARCHAR2(30) := UPPER('&3'); i NUMBER; vDataPumpJobHandle NUMBER; vProgress_ratio NUMBER; vJobState VARCHAR2(30); oLogEntry ku$_LogEntry; oStatus ku$_Status; BEGIN DBMS_OUTPUT.ENABLE; v4Debug := 'OPEN'; vDataPumpJobHandle := DBMS_DATAPUMP.OPEN ( operation => 'IMPORT' ,job_mode => 'SCHEMA' ,remote_link => NULL ); v4Debug := 'ADD_FILE - dumpfile'; DBMS_DATAPUMP.ADD_FILE ( handle => vDataPumpJobHandle ,filename => cDumpFileName ,directory => cDirectory ,filetype => DBMS_DATAPUMP.KU$_FILE_TYPE_DUMP_FILE ); v4Debug := 'ADD_FILE - logfile'; DBMS_DATAPUMP.ADD_FILE ( handle => vDataPumpJobHandle ,filename => cLogFileName ,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 => '''' || cSchemaName || '''' ); v4Debug := 'TABLE_EXISTS_ACTION=TRUNCATE'; DBMS_DATAPUMP.SET_PARAMETER ( handle => vDataPumpJobHandle ,name => 'TABLE_EXISTS_ACTION' ,value => 'TRUNCATE' ); v4Debug := 'START_JOB'; DBMS_DATAPUMP.START_JOB ( handle => vDataPumpJobHandle ); 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 ); 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; DBMS_DATAPUMP.DETACH(vDataPumpJobHandle); EXCEPTION WHEN OTHERS THEN DBMS_OUTPUT.PUT_LINE(sqlerrm()); DBMS_OUTPUT.PUT_LINE(v4Debug); RAISE; END; / UNDEFINE 1 UNDEFINE 2 UNDEFINE 3 SET SERVEROUTPUT OFF SET VERIFY ON

今回は、上記２つのスクリプトに分けましたが、１つにまとめるように作り変えればより便利できますよ！　それはみなさんへの宿題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へ複製（オプジェクトパスが不足すると...

・RDS Oracle 雑多なメモ#1 / FAQ
・RDS Oracle 雑多なメモ#2 / FAQ
・RDS Oracle 雑多なメモ#3 / FAQ
・RDS Oracle 雑多なメモ#4 / FAQ
・RDS Oracle 雑多なメモ#5 / FAQ
・RDS Oracle 雑多なメモ#6 / FAQ
・RDS Oracle 雑多なメモ#7 / FAQ
・RDS Oracle 雑多なメモ#8 / FAQ
・RDS Oracle 雑多なメモ#9 / FAQ
・RDS Oracle 雑多なメモ#10 / FAQ
・RDS Oracle 雑多なメモ#11 / FAQ
・RDS Oracle 雑多なメモ#12 / FAQ
・RDS Oracle 雑多なメモ#13 / FAQ
・RDS Oracle 雑多なメモ#14 - おまけ　/ FAQ
・RDS Oracle 雑多なメモ#15 - おまけのおまけ / FAQ
・RDS Oracle 雑多なメモ#16 - 再び:) / FAQ
・RDS Oracle 雑多なメモ#17/ FAQ
・RDS Oracle 雑多なメモ#18 / DBMS_DATAPUMPパッケージ de expdp/impdp
・RDS Oracle 雑多なメモ#19 FAQ / DBMS_DATAPUMPパッケージ de ジョブの停止
・RDS Oracle 雑多なメモ#20 / DBMS_DATAPUMPパッケージ　Schema mode de expdp/impdpの準備 SQL_FILEモードでDDL抜き出し

投稿日時 2020年7月26日 (日) 02時34分 Oracle, PL/SQL, FAQ, SQL, Data Pump, AWS | 固定リンク | 0 | コメント (0)

2020年7月25日 (土)

RDS Oracle 雑多なメモ#20 / DBMS_DATAPUMPパッケージ　Schema mode de expdp/impdpの準備 SQL_FILEモードでDDL抜き出し

RDS Oracle 雑多なメモ#20 / DBMS_DATAPUMPパッケージ　Schema mode de expdp/impdpの準備

Previously, Mac De Oracle...

RDS Oracle 雑多なメモ#19 FAQ / DBMS_DATAPUMPパッケージ de ジョブの停止

でした。

今回は、RDS　Oracleへスキーマ単位でインポートを行う準備に必要などを。

実は、RDS Oracleでは、フルインポートはしないようにと記載されています。ということは、つまりスキーマモードでのインポートと、それ以下の単位でのインポートのみを行うこと、となっています。ここがポイント

詳細は以下マニュアルを参照ください。
Amazon RDS での Oracle へのデータのインポート

フルモードでインポートできない場合の注意点として、スキーマレベルでインポートする際に必要となる可能性のあるオブジェクトは事前に何がしかの方法で作成しておく必要があるということを意味します。
代表的なオブジェクトは以下、

ユーザーのデフォルトTABLESPACE（USERS表をそのまま利用しているケースは希だと思います）

ユーザーのPROFILE（パスワード有効期限管理などで利用しているケースは多いかも）

ROLE（直接付与権限以外はロールを付与して権限を管理することは多いはずです）

DIRECTORY（Oracle側で事前に作成しているディレクトリ以外のディレクトリへのアクセスが必要な場合にはディレクトリオブジェクトも事前に作成しておく必要があります）

さらに、スキーマ間で依存している場合、特に、他のスキーマのオブジェクト権限を付与する必要がある場合は、スキーマをインポートする順番にも気を遣う必要も出てきます。
インポート時にエラーが出ないものもありますが。。それは今回のテーマではないのでこの辺でw
（依存しているオブジェクトは事前にALL/DBA_DEPENDENCIESビューを利用して調査しておくとよいでしょうね）

では、DDLを取得する前に、ネタを仕込んでおきましょう。

表領域 fizzbuzz をデフォルト表領域とし、プロファイル fizzbuzz　が設定されたユーザー hoge　を作成します。
また、connectロールとresourceロールを付与された　 fizzbuzz　ロールが hoge に付与されているとします。

表領域の追加

BILL> create tablespace fizzbuzz datafile size 100m autoextend on maxsize 1g; Tablespace created.

プロファイルの追加

BILL> create profile fizzbuzz limit idle_time unlimited; Profile created.

ロールの追加

BILL> create role fizzbuzz; Role created. BILL> grant connect to fizzbuzz; Grant succeeded. BILL> grant resource to fizzbuzz; Grant succeeded.

ユーザーの作成（デフォルト表領域とプロファイルの指定）

BILL> create user hoge identified by xxxxxxxxxxxxxxxx 2 default tablespace fizzbuzz 3 temporary tablespace temp 4 quota unlimited on fizzbuzz 5 profile fizzbuzz; User created.

ロールの付与

BILL> grant fizzbuzz to hoge; Grant succeeded.

上記のようなユーザーだとするとスキーマ単位のインポート前に表領域の作成、プロファイルの作成、ロールの作成が必要になりますよね。
（スキーマレベルのインポートでは依存オブジェクトが自動的にインポートされるわけでは無いので）

また、元のデータベースでOracle Managed Fileを利用した表領域では無い場合にはOracle Managed Fileを利用した表領域として再作成してあげる必要あります。（ここも重要。元のデータベースもOracle Managed fileを利用していればそのまま利用できます）

ということで、DBMS_METADATA.GET_DDL()または、フルエクスポートしたData Pumpのダンプファイルファイルから上記に該当するDDLを抜き出し、事前にオブジェクトを作成しておく必要がありますよね。
（DDLソースコード管理されているのであれば、それらを再利用することも可能だとは思いますが、世の中広いのでそんな管理されていないところも多いでしょうし。DDLを取り出す複数の方法は覚えてて損は無いですよ :）

今回は、フルエクスポートダンプファイルがあるので、そこからData Pump APIを利用して取り出してみようと思います。(DBMS_METADATA.GET_DDL()の方が楽だとは思います。個人的にはw)

フルダンプからDDLを取り出す際でも、重要なのがオブジェクトパス（このパスの階層を意識していないと思わぬ失敗をするのは昔のエントリの通り）ですが、今回は比較的シンプルなので確認してみましょう。

事前にエクスポートのログから以下のパスを探し出しておきます。
（今回の例では、表領域とプロファイル、それにロールへのオブジェクトパスです。以下がそのオブジェクトパス）

Processing object type DATABASE_EXPORT/TABLESPACE Processing object type DATABASE_EXPORT/PROFILE Processing object type DATABASE_EXPORT/ROLE

余談ですが、同じ階層オブジェクトパスにスキーマオブジェクトのパス(DATABASE_EXPORT/SCHEMA)が存在しています。同じ階層なので、スキーマレベルのインポートではTABLESPACE/ROLE/PROFILEはインポートされることはありません。（この階層構造を理解できれば楽）
DATABASE_EXPORT/SCHEMA以下がインポートの対象になるので、メタデータフィルターでEXCLUDE または INCLUDEするか制御できることになります。TABLESPACE,PROFILEやROLEはSCHEMAと同レベルなのでそもそも対象外となりフィルタすることはできません。

Processing object type DATABASE_EXPORT/SCHEMA/

理屈がわかれば癖の強いDATAPUMPなんてw　

では、DDLを取り出してみましょう。

前提のオブジェクトを含むフルエクスポートダンプファイル fullexp.dmp　は事前に取得済みであるとします。

BILL> @extract_ddl data_pump_dir fullexp DATABASE_EXPORT/TABLESPACE'',''DATABASE_EXPORT/PROFILE'',''DATABASE_EXPORT/ROLE Master table "BILL"."SYS_SQL_FILE_FULL_17" successfully loaded/unloaded Starting "BILL"."SYS_SQL_FILE_FULL_17": Processing object type DATABASE_EXPORT/TABLESPACE Processing object type DATABASE_EXPORT/PROFILE Processing object type DATABASE_EXPORT/ROLE Job "BILL"."SYS_SQL_FILE_FULL_17" successfully completed at Sun Jul 19 19:12:00 2020 elapsed 0 00:00:02 PL/SQL procedure successfully completed.

取り出したDDLを確認します

BILL> @cat_file data_pump_dir fullexp.txt TEXT ----------------------------------------------------------------------------- ...中略... -- new object type path: DATABASE_EXPORT/TABLESPACE ...中略... CREATE BIGFILE TABLESPACE "FIZZBUZZ" DATAFILE SIZE 104857600 AUTOEXTEND ON NEXT 104857600 MAXSIZE 1073741824 LOGGING ONLINE PERMANENT BLOCKSIZE 8192 EXTENT MANAGEMENT LOCAL AUTOALLOCATE DEFAULT NOCOMPRESS SEGMENT SPACE MANAGEMENT AUTO; -- new object type path: DATABASE_EXPORT/PROFILE ...中略... CREATE PROFILE "FIZZBUZZ" LIMIT COMPOSITE_LIMIT DEFAULT SESSIONS_PER_USER DEFAULT CPU_PER_SESSION DEFAULT CPU_PER_CALL DEFAULT LOGICAL_READS_PER_SESSION DEFAULT LOGICAL_READS_PER_CALL DEFAULT IDLE_TIME UNLIMITED CONNECT_TIME DEFAULT PRIVATE_SGA DEFAULT FAILED_LOGIN_ATTEMPTS DEFAULT PASSWORD_LIFE_TIME DEFAULT PASSWORD_REUSE_TIME DEFAULT PASSWORD_REUSE_MAX DEFAULT PASSWORD_VERIFY_FUNCTION DEFAULT PASSWORD_LOCK_TIME DEFAULT PASSWORD_GRACE_TIME DEFAULT INACTIVE_ACCOUNT_TIME DEFAULT ; -- new object type path: DATABASE_EXPORT/ROLE ...中略... CREATE ROLE "FIZZBUZZ"; ...中略...

スキーマ hogeインポート前に作成が必要なオブジェクトのDDLを取得できました。

これでスキーマレベルのインポート準備完了。
つづく。

参考）
DDLをダンプファイルから取り出すスクリプト例は以下の通り。DBMS_DATAPUMP.OPEN()関数でoperationに’SQL_FILE'を渡しているところとDBMS_DATAPUMP.METADATA_FILTER()プロシージャで取り出すDDLのオブジェクトパスリストを渡している箇所がポイントです
PL/SQLパッケージおよびタイプ・リファレンス - 47 DBMS_DATAPUMP

BILL> !cat extract_ddl.sql SET VERIFY OFF SET SERVEROUTPUT ON DECLARE v4Debug VARCHAR2(50); cDirectory CONSTANT VARCHAR2(30) := UPPER('&1'); cDumpFileName CONSTANT VARCHAR2(64) := '&2'||'.dmp'; cLogFileName CONSTANT VARCHAR2(64) := '&2'||'.log'; cDdlFileName CONSTANT VARCHAR2(64) := '&2'||'.txt'; cPathList CONSTANT VARCHAR2(4000) := UPPER('&3'); i NUMBER; vDataPumpJobHandle NUMBER; vProgress_ratio NUMBER; vJobState VARCHAR2(30); oLogEntry ku$_LogEntry; oStatus ku$_Status; BEGIN DBMS_OUTPUT.ENABLE; v4Debug := 'OPEN'; vDataPumpJobHandle := DBMS_DATAPUMP.OPEN ( operation => 'SQL_FILE' ,job_mode => 'FULL' ,remote_link => NULL ); v4Debug := 'ADD_FILE - dumpfile'; DBMS_DATAPUMP.ADD_FILE ( handle => vDataPumpJobHandle ,filename => cDumpFileName ,directory => cDirectory ,filetype => DBMS_DATAPUMP.KU$_FILE_TYPE_DUMP_FILE ); v4Debug := 'ADD_FILE - logfile'; DBMS_DATAPUMP.ADD_FILE ( handle => vDataPumpJobHandle ,filename => cLogFileName ,directory => cDirectory ,filetype => DBMS_DATAPUMP.KU$_FILE_TYPE_LOG_FILE ); v4Debug := 'ADD_FILE - Ddlfile'; DBMS_DATAPUMP.ADD_FILE ( handle => vDataPumpJobHandle ,filename => cDdlFileName ,directory => cDirectory ,filetype => DBMS_DATAPUMP.KU$_FILE_TYPE_SQL_FILE ); v4Debug := 'METADATA_FILTER - schema name'; DBMS_DATAPUMP.METADATA_FILTER ( handle => vDataPumpJobHandle ,name => 'INCLUDE_PATH_LIST' ,value => '''' || cPathList || '''' ); v4Debug := 'START_JOB'; DBMS_DATAPUMP.START_JOB ( handle => vDataPumpJobHandle ); 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 ); 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; DBMS_DATAPUMP.DETACH(vDataPumpJobHandle); EXCEPTION WHEN OTHERS THEN DBMS_OUTPUT.PUT_LINE(sqlerrm()); DBMS_OUTPUT.PUT_LINE(v4Debug); RAISE; END; / UNDEFINE 1 UNDEFINE 2 UNDEFINE 3 SET SERVEROUTPUT OFF SET VERIFY ON

やっと、いろいろ落ち着いたかと思ったら次から次に似たような事案が落ちてくる今日この頃w。
ということで、しばらくは機嫌悪いかも、ガルーーーーーっ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へ複製（オプジェクトパスが不足すると...

・RDS Oracle 雑多なメモ#1 / FAQ
・RDS Oracle 雑多なメモ#2 / FAQ
・RDS Oracle 雑多なメモ#3 / FAQ
・RDS Oracle 雑多なメモ#4 / FAQ
・RDS Oracle 雑多なメモ#5 / FAQ
・RDS Oracle 雑多なメモ#6 / FAQ
・RDS Oracle 雑多なメモ#7 / FAQ
・RDS Oracle 雑多なメモ#8 / FAQ
・RDS Oracle 雑多なメモ#9 / FAQ
・RDS Oracle 雑多なメモ#10 / FAQ
・RDS Oracle 雑多なメモ#11 / FAQ
・RDS Oracle 雑多なメモ#12 / FAQ
・RDS Oracle 雑多なメモ#13 / FAQ
・RDS Oracle 雑多なメモ#14 - おまけ　/ FAQ
・RDS Oracle 雑多なメモ#15 - おまけのおまけ / FAQ
・RDS Oracle 雑多なメモ#16 - 再び:) / FAQ
・RDS Oracle 雑多なメモ#17/ FAQ
・RDS Oracle 雑多なメモ#18 / DBMS_DATAPUMPパッケージ de expdp/impdp
・RDS Oracle 雑多なメモ#19 FAQ / DBMS_DATAPUMPパッケージ de ジョブの停止

投稿日時 2020年7月25日 (土) 04時06分 Oracle, PL/SQL, FAQ, SQL, Data Pump, AWS, RDS | 固定リンク | 0 | コメント (0)

2020年7月20日 (月)

RDS Oracle 雑多なメモ#19 FAQ / DBMS_DATAPUMPパッケージ de ジョブの停止

Previously, Mac De Oracle...

RDS Oracle 雑多なメモ#18 / DBMS_DATAPUMPパッケージ de expdp/impdp

DBMS_DATAPUMPパッケージを利用した　Full Export スクリプトと、ディレクトリ名は大文字で渡すことというマニュアルに記載されていない、発生するとしばらく道に迷ってしまいそうなエラーが返るというお話でした。

今日は、その続き、Data PumpジョブはコマンドラインであってもCTRL+Cでは停止することはできないことはみなさんご存知の通りだとは思います。

正しい停止手順は以下の通り

DBA_DATAPUMP_JOBSで停止したいDATAPUMPジョブ名とジョブオーナー名を確認する

4.199 DBA_DATAPUMP_JOBS
https://docs.oracle.com/cd/F19136_01/refrn/DBA_DATAPUMP_JOBS.html#GUID-141B1FA2-9DE4-4EAF-8270-630E68431DDA

expdp/impdpのattachコマンド、または、DBMS_DATAPUMP.ATTACH()ファンクションで該当ジョブへattachする

3.4.4 ATTACH　(expdp/impdpとも同じ対話コマンド)
https://docs.oracle.com/cd/F19136_01/sutil/datapump-import-utility.html#GUID-ADF15D47-FD19-4794-A5C4-685740AA04F9

47.5.2 ATTACHファンクション
https://docs.oracle.com/cd/F19136_01/arpls/DBMS_DATAPUMP.html#GUID-E073EA12-363D-4A6B-9596-1E1D40EA747C

expdp/impdpのkill_jobコマンド、または、DBMS_DATAPUMP.STOP_JOB()プロシージャで該当ジョブを停止する

2.5.7 KILL_JOB　(expdp/impdpとも同じ対話コマンド)
https://docs.oracle.com/cd/F19136_01/sutil/oracle-data-pump-export-utility.html#GUID-9DA12603-B6FA-4631-8DFA-B75466CAF178

47.5.16 STOP_JOBプロシージャ
https://docs.oracle.com/cd/F19136_01/arpls/DBMS_DATAPUMP.html#GUID-9CE265FA-F9C6-4816-8AE0-AD0BEF3DC3CA

コマンドラインでもAPI経由でも手順は全く同じ。利用するツールが異なるだけでなので、まずは手順を覚えることが大切なんですよね。これ。
あとは、コマンドラインでは以下のマニュアルを参照し、具体的なコマンドオプションを知る
DBMS_DATAPUMPプロシージャを利用する場合は以下のマニュアルを参照し、どのようなスクリプトになるかを知る

あとは、実践のみですよー、みなさん！ :)

では、DBMS_DATAPUMPパッケージでの例を（すでにエクスポートは実行中という状況からはじめます）

BILL> @show_datapump_jobs OWNER_NAME JOB_NAME STATE JOB_MODE OPERATION ----------------- ------------------------- ------------- ------------- ------------- BILL SYS_EXPORT_FULL_01 EXECUTING FULL EXPORT BILL> @cancel_datapump_job SYS_EXPORT_FULL_01 BILL PL/SQL procedure successfully completed. BILL> @show_datapump_jobs no rows selected BILL> @ls_dir data_pump_dir FILENAME TYPE FILESIZE MTIME --------------------------- ---------- ---------- --------- fullexp.log file 2761 18-JUL-20 datapump/ directory 4096 18-JUL-20 BILL> @cat_file data_pump_dir fullexp.log TEXT ---------------------------------------------------------------------------------------- FLASHBACK automatically enabled to preserve database integrity. Starting "BILL"."SYS_EXPORT_FULL_01": Processing object type DATABASE_EXPORT/EARLY_OPTIONS/VIEWS_AS_TABLES/TABLE_DATA Processing object type DATABASE_EXPORT/NORMAL_OPTIONS/TABLE_DATA Processing object type DATABASE_EXPORT/NORMAL_OPTIONS/VIEWS_AS_TABLES/TABLE_DATA Processing object type DATABASE_EXPORT/SCHEMA/TABLE/TABLE_DATA Processing object type DATABASE_EXPORT/SCHEMA/PACKAGE_BODIES/PACKAGE/PACKAGE_BODY Processing object type DATABASE_EXPORT/SCHEMA/TABLE/INDEX/STATISTICS/INDEX_STATISTICS Processing object type DATABASE_EXPORT/SCHEMA/TABLE/INDEX/STATISTICS/FUNCTIONAL_INDEX/INDEX_STATISTICS Processing object type DATABASE_EXPORT/SCHEMA/TABLE/STATISTICS/TABLE_STATISTICS Processing object type DATABASE_EXPORT/STATISTICS/MARKER Processing object type DATABASE_EXPORT/PRE_SYSTEM_IMPCALLOUT/MARKER Processing object type DATABASE_EXPORT/PRE_INSTANCE_IMPCALLOUT/MARKER Processing object type DATABASE_EXPORT/TABLESPACE Processing object type DATABASE_EXPORT/PROFILE Processing object type DATABASE_EXPORT/SCHEMA/USER Processing object type DATABASE_EXPORT/ROLE Processing object type DATABASE_EXPORT/RADM_FPTM Processing object type DATABASE_EXPORT/GRANT/SYSTEM_GRANT/PROC_SYSTEM_GRANT ...中略... Processing object type DATABASE_EXPORT/NORMAL_OPTIONS/TABLE Job "BILL"."SYS_EXPORT_FULL_01" stopped due to fatal error at Sat Jul 18 10:02:49 2020 elapsed 0 00:00:50 41 rows selected. BILL> @rm_file data_pump_dir fullexp.log DATA_PUMP_DIR/fullexp.log removed. PL/SQL procedure successfully completed. BILL> @ls_dir data_pump_dir FILENAME TYPE FILESIZE MTIME --------------------------- ---------- ---------- --------- datapump/ directory 4096 18-JUL-20

停止できましたー

今回利用したDATAPUMPジョブ停止スクリプトの例は以下のとおり。

BILL> !cat show_datapump_jobs.sql col owner_name for a30 col job_name for a30 col state for a30 col job_mode for a30 col operation for a30 SELECT owner_name , job_name , state , job_mode , operation FROM DBA_DATAPUMP_JOBS ORDER BY owner_name , job_name , state ;

BILL> !cat cancel_datapump_job.sql DECLARE hdl NUMBER; BEGIN hdl := DBMS_DATAPUMP.ATTACH( job_name => UPPER('&1') ,job_owner => UPPER('&2') ); DBMS_DATAPUMP.STOP_JOB( handle => hdl , immediate => 1 , keep_master => 0 ); END; /

ls_dir.sql, rm_file.sql　そして、cat_file.sqlの例は過去のエントリを参照してみてください。

ls_dir.sql
https://discus-hamburg.cocolog-nifty.com/mac_de_oracle/2018/09/rds-oracle-3-fa.html

rm_file.sql
https://discus-hamburg.cocolog-nifty.com/mac_de_oracle/2018/09/rds-oracle-7-fa.html

cat_file.sql
https://discus-hamburg.cocolog-nifty.com/mac_de_oracle/2018/09/rds-oracle-4-fa.html

では、次回へつづく。

・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へ複製（オプジェクトパスが不足すると...

・RDS Oracle 雑多なメモ#1 / FAQ
・RDS Oracle 雑多なメモ#2 / FAQ
・RDS Oracle 雑多なメモ#3 / FAQ
・RDS Oracle 雑多なメモ#4 / FAQ
・RDS Oracle 雑多なメモ#5 / FAQ
・RDS Oracle 雑多なメモ#6 / FAQ
・RDS Oracle 雑多なメモ#7 / FAQ
・RDS Oracle 雑多なメモ#8 / FAQ
・RDS Oracle 雑多なメモ#9 / FAQ
・RDS Oracle 雑多なメモ#10 / FAQ
・RDS Oracle 雑多なメモ#11 / FAQ
・RDS Oracle 雑多なメモ#12 / FAQ
・RDS Oracle 雑多なメモ#13 / FAQ
・RDS Oracle 雑多なメモ#14 - おまけ　/ FAQ
・RDS Oracle 雑多なメモ#15 - おまけのおまけ / FAQ
・RDS Oracle 雑多なメモ#16 - 再び:) / FAQ
・RDS Oracle 雑多なメモ#17/ FAQ
・RDS Oracle 雑多なメモ#18 / DBMS_DATAPUMPパッケージ de expdp/impdp

投稿日時 2020年7月20日 (月) 00時35分 Oracle, PL/SQL, FAQ, SQL, AWS, RDS | 固定リンク | 0 | コメント (0)

2020年7月19日 (日)

RDS Oracle 雑多なメモ#18 / DBMS_DATAPUMPパッケージ de expdp/impdp

さて、COVID-19の感染者も再び増加傾向にある今日この頃ですが、みなさま、お変わりありませんか？

半年ぶり以上ぶりのエントリです。（2020年のOracle ACEのKPIカウントもスタートしたのでやっと再始動）
再始動第一段目は、癖者の極み、Data Pumpネタで。

何年か前にも癖者だというエントリは書いたことがありますが、今回はコマンドラインではなく、DBMS_DATAPUMPパッケージ。そう、APIが主人公です

Data Pumpも癖モノだよね〜w　その6 - schemaモードでMviewを他のPDBへ複製（オプジェクトパスが不足すると...） https://discus-hamburg.cocolog-nifty.com/mac_de_oracle/2017/04/data-pumpw6---s.html

そして最近では、

DS Oracle 雑多なメモ#1 / FAQ　〜 https://discus-hamburg.cocolog-nifty.com/mac_de_oracle/2018/09/rds-oracle-1-fa.html

から

RDS Oracle 雑多なメモ#17/ FAQ https://discus-hamburg.cocolog-nifty.com/mac_de_oracle/2019/02/rds-oracle-17-f.html

何度かData Pumpネタを取り上げてきました、今回は RDS Oracleでは需要が多そうな
DBMS＿DATAPUMPパッケージからAPIを利用してexpdp/impdp相当の操作に特化していくつご紹介しておきます。

普段はコマンドラインだけでした操作したことないData Pumpですが、いざDBMS_DATAPUMPパッケージしか使えないという状況になって、涙目状態は辛いですよね。
そんなことにならないように普段から慣れておくとかスクリプト集を用意しておくと良いと思います。

コマンドラインでも癖もとだよねぇ〜というネタのとおりDBMS_DATAPUMPパッケージでも一癖あるのはおなじですw
とはいえ、コマンドラインである程度ポイントを抑えていればある程度は感でいけますよ。

では、さっそく、DBMS_DATAPUMPパッケージの準備運動として、Data Pump Full exportを試してみましょう。
以前も同類のスクリプトは公開済みなので、過去のエントリを読んだことがあるなら簡単なはず:)

環境 Oracle Client 19c (SQL*Plusパッケージが含まれているパッケージ） https://www.oracle.com/jp/database/technologies/instant-client.html

AWS RDS Oracle Database 19c https://aws.amazon.com/jp/console/

実行例）

BILL> @expdp_full data_pump_dir fullexp FLASHBACK automatically enabled to preserve database integrity. Starting "BILL"."SYS_EXPORT_FULL_01": Processing object type DATABASE_EXPORT/EARLY_OPTIONS/VIEWS_AS_TABLES/TABLE_DATA Processing object type DATABASE_EXPORT/NORMAL_OPTIONS/TABLE_DATA Processing object type DATABASE_EXPORT/NORMAL_OPTIONS/VIEWS_AS_TABLES/TABLE_DATA Processing object type DATABASE_EXPORT/SCHEMA/TABLE/TABLE_DATA Processing object type DATABASE_EXPORT/SCHEMA/PACKAGE_BODIES/PACKAGE/PACKAGE_BODY Processing object type DATABASE_EXPORT/SCHEMA/TABLE/INDEX/STATISTICS/INDEX_STATISTICS Processing object type DATABASE_EXPORT/SCHEMA/TABLE/INDEX/STATISTICS/FUNCTIONAL_INDEX/INDEX_STATISTICS Processing object type DATABASE_EXPORT/SCHEMA/TABLE/STATISTICS/TABLE_STATISTICS Processing object type DATABASE_EXPORT/STATISTICS/MARKER Processing object type DATABASE_EXPORT/PRE_SYSTEM_IMPCALLOUT/MARKER Processing object type DATABASE_EXPORT/PRE_INSTANCE_IMPCALLOUT/MARKER Processing object type DATABASE_EXPORT/TABLESPACE Processing object type DATABASE_EXPORT/PROFILE Processing object type DATABASE_EXPORT/SCHEMA/USER Processing object type DATABASE_EXPORT/ROLE Processing object type DATABASE_EXPORT/RADM_FPTM Processing object type DATABASE_EXPORT/GRANT/SYSTEM_GRANT/PROC_SYSTEM_GRANT ...中略... Processing object type DATABASE_EXPORT/SCHEMA/VIEW/VIEW Processing object type DATABASE_EXPORT/SCHEMA/TABLE/INDEX/INDEX Processing object type DATABASE_EXPORT/SCHEMA/TABLE/INDEX/FUNCTIONAL_INDEX/INDEX Processing object type DATABASE_EXPORT/SCHEMA/TABLE/CONSTRAINT/CONSTRAINT Processing object type DATABASE_EXPORT/SCHEMA/TABLE/CONSTRAINT/REF_CONSTRAINT Processing object type DATABASE_EXPORT/SCHEMA/TABLE/TRIGGER Processing object type DATABASE_EXPORT/SCHEMA/EVENT/TRIGGER Processing object type DATABASE_EXPORT/FINAL_POST_INSTANCE_IMPCALLOUT/MARKER Processing object type DATABASE_EXPORT/SCHEMA/POST_SCHEMA/PROCACT_SCHEMA Processing object type DATABASE_EXPORT/AUDIT_UNIFIED/AUDIT_POLICY_ENABLE Processing object type DATABASE_EXPORT/POST_SYSTEM_IMPCALLOUT/MARKER . . exported "SYS"."KU$_USER_MAPPING_VIEW" 5.921 KB 28 rows ...中略... . . exported "SCOTT"."TAB31" 541.6 MB 2000000 rows . . exported "SCOTT"."TAB311" 521.6 MB 2000000 rows . . exported "SCOTT"."TAB3" 267.9 MB 1000000 rows ...中略... . . exported "HOGE"."HOGE" 5.093 KB 1 rows ...中略... Master table "BILL"."SYS_EXPORT_FULL_01" successfully loaded/unloaded ****************************************************************************** Dump file set for BILL.SYS_EXPORT_FULL_01 is: /rdsdbdata/datapump/fullexp.dmp Job "BILL"."SYS_EXPORT_FULL_01" successfully completed at Sat Jul 18 10:25:02 2020 elapsed 0 00:04:25 PL/SQL procedure successfully completed. Elapsed: 00:04:27.32 BILL> BILL> @ls_dir data_pump_dir FILENAME TYPE FILESIZE MTIME ---------------------------------------------------------------------- ---------- ---------- --------- datapump/ directory 4096 18-JUL-20 fullexp.log file 9071 18-JUL-20 fullexp.dmp file 1461907456 18-JUL-20 Elapsed: 00:00:00.15

なお、上記で利用している ls_dir.sql　は以下エントリを参照のこと。　
RDS Oracle 雑多なメモ#3 / FAQ https://discus-hamburg.cocolog-nifty.com/mac_de_oracle/2018/09/rds-oracle-3-fa.html

RDS Oracle 雑多なメモ#9 / FAQでも紹介しているスクリプトを多少変更してあります。
Full ExportなのでDBMS_DATAPUMP.OPEN()のjob_modeパラメータが'FULL'になっている点と、DBMS_DATAPUMP.METADATA_FILTER()でEXCLUDEやINCLUDEしていない。つまり、Full Exportになっています。
https://discus-hamburg.cocolog-nifty.com/mac_de_oracle/2018/09/rds-oracle-9-fa.html

参考）PL/SQLパッケージおよびタイプ・リファレンス
https://docs.oracle.com/cd/F19136_01/arpls/DBMS_DATAPUMP.html#GUID-AEA7ED80-DB4A-4A70-B199-592287206348

なお、マニュアルには書かれてないのですが、ディレクトリ名は、"大文字" にするのがポイントです。Case Sensitiveで大文字しか認識しません。スクリプトを注意深く見ていただけると、UPPER()を使っている部分(赤字部分)があることに気づくとおもいます。もし、小文字で渡してしまうとDBMS_DATAPUMPパッケージの癖の強いエラーメッセージを受け取りことになり、意味わからなーーーーい。としばらくは迷子になってしまうことでしょう。後半で、UPPER()なしで小文字で渡してしまった場合にはどのようなエラーが返されるのかお見せしたいと思います。

BILL> !cat expdp_full.sql

SET VERIFY OFF SET SERVEROUTPUT ON DECLARE v4Debug VARCHAR2(50); cDirectory CONSTANT VARCHAR2(30) := UPPER('&1'); cDumpFileName CONSTANT VARCHAR2(128) := '&2'||'.dmp'; cLogFileName CONSTANT VARCHAR2(128) := '&2'||'.log'; i NUMBER; vDataPumpJobHandle NUMBER; vProgress_ratio NUMBER; vJobState VARCHAR2(30); oLogEntry ku$_LogEntry; oStatus ku$_Status; BEGIN DBMS_OUTPUT.ENABLE; v4Debug := 'OPEN'; vDataPumpJobHandle := DBMS_DATAPUMP.OPEN ( operation => 'EXPORT' ,job_mode => 'FULL' ,remote_link => NULL ,job_name => NULL ,version => 'LATEST' ); v4Debug := 'ADD_FILE - dumpfile'; DBMS_DATAPUMP.ADD_FILE ( handle => vDataPumpJobHandle ,filename => cDumpFileName ,directory => cDirectory( ,filetype => DBMS_DATAPUMP.KU$_FILE_TYPE_DUMP_FILE ); v4Debug := 'ADD_FILE - logfile'; DBMS_DATAPUMP.ADD_FILE ( handle => vDataPumpJobHandle ,filename => cLogFileName ,directory => cDirectory( ,filetype => DBMS_DATAPUMP.KU$_FILE_TYPE_LOG_FILE ); v4Debug := 'START_JOB'; DBMS_DATAPUMP.START_JOB ( handle => vDataPumpJobHandle ); 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 ); 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; DBMS_DATAPUMP.DETACH(vDataPumpJobHandle); EXCEPTION WHEN OTHERS THEN DBMS_OUTPUT.PUT_LINE(sqlerrm()); DBMS_OUTPUT.PUT_LINE(v4Debug); RAISE; END; / UNDEFINE 1 UNDEFINE 2 SET SERVEROUTPUT OFF SET VERIFY ON

では、少しだけ前振りしていた、もしも、ディレクトリ名を小文字で渡してしまったら....以下のようなエラーが返されます。

なかなかの癖者なエラーメッセージですよね。このエラーですぐに問題点に気づけたら達人に域ですw　（癖者な人よりは扱いやすいとは思いますがw　ただのAPIなので）

BILL> @expdp_full data_pump_dir fullexp2 old 3: cDirectory CONSTANT VARCHAR2(30) := '&1'; new 3: cDirectory CONSTANT VARCHAR2(30) := 'data_pump_dir'; old 4: cDumpFileName CONSTANT VARCHAR2(64) := '&2'||'.dmp'; new 4: cDumpFileName CONSTANT VARCHAR2(64) := 'fullexp2'||'.dmp'; old 5: cLogFileName CONSTANT VARCHAR2(64) := '&2'||'.log'; new 5: cLogFileName CONSTANT VARCHAR2(64) := 'fullexp2'||'.log'; ORA-39001: invalid argument value ADD_FILE - dumpfile DECLARE * ERROR at line 1: ORA-39001: invalid argument value ORA-06512: at line 86 ORA-06512: at "SYS.DBMS_SYS_ERROR", line 79 ORA-06512: at "SYS.DBMS_DATAPUMP", line 4929 ORA-06512: at "SYS.DBMS_DATAPUMP", line 5180 ORA-06512: at line 26

では、次回へつづく。

・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へ複製（オプジェクトパスが不足すると...

・RDS Oracle 雑多なメモ#1 / FAQ
・RDS Oracle 雑多なメモ#2 / FAQ
・RDS Oracle 雑多なメモ#3 / FAQ
・RDS Oracle 雑多なメモ#4 / FAQ
・RDS Oracle 雑多なメモ#5 / FAQ
・RDS Oracle 雑多なメモ#6 / FAQ
・RDS Oracle 雑多なメモ#7 / FAQ
・RDS Oracle 雑多なメモ#8 / FAQ
・RDS Oracle 雑多なメモ#9 / FAQ
・RDS Oracle 雑多なメモ#10 / FAQ
・RDS Oracle 雑多なメモ#11 / FAQ
・RDS Oracle 雑多なメモ#12 / FAQ
・RDS Oracle 雑多なメモ#13 / FAQ
・RDS Oracle 雑多なメモ#14 - おまけ　/ FAQ
・RDS Oracle 雑多なメモ#15 - おまけのおまけ / FAQ
・RDS Oracle 雑多なメモ#16 - 再び:) / FAQ
・RDS Oracle 雑多なメモ#17/ FAQ

投稿日時 2020年7月19日 (日) 02時59分 Oracle, PL/SQL, FAQ, SQL, AWS, RDS | 固定リンク | 0 | コメント (0)

2020年2月23日 (日)

実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 おまけ#4

2020年も2ヶ月が終わるところ, かつ, 新型コロナウィルスの影響をいろいろ受けつつ今後どうなるんだろうと, 週末は外出を最小限に入手困難なマスクの消費を抑える意味もあり必要最小限の外出にする作戦....
とはいえ, ネットでググると, 消毒用アルコール詰め替え4Lやマスクが, 想像の斜め上をいく値段で売られてて, なんなのだろうなんて...

余談はこれぐらいにして, 2019年のくれのネタのおまけの追加でございます.

Index Only Scanを利用したmin()/max()で性能チューニングという、比較的レアな治療をしたことのある方なら見覚えのあるレントゲン写真（実行計画）だと思います. （たまたまそうなってたということもありますが, これを狙ったチューニング方法もあります）

当然ですが、Index Only Scanを狙う場面は, 行長が長いがSELECT文では索引にできそうな（しても悪影響なさそうな）一部の列しか利用していない. ほぼ全ての列がSELECT文中で利用されているような場合にはIndex Only Scanは不向きなのはみなさんご存知の通りです.

なつかしいエントリですが, 以下エントリーのスライド（SlideShare使ってなかった頃なので, KeynoteをHTMLへ変換）を参照のこと.
いん！、イン！、Index どっぷり Inde Only Access生活w - Oracle OpenWorld Unconference presented by JPOUG

上記エントリーのスライドでも紹介していますが, MIN()/MAX()関数が利用されており, Index Only Scanが有効なケース（アクセスするブロック数が多くOLTPの性能が性能要件を満たせないようなケース. 大抵の場合、物理IOの影響か, キャッシュにヒットしてもBuffer読み込みが多すぎる、かつ、同時セッション数が多いような場合にはいろいろな改善効果が見込めます）で威力を発揮します.

例えば, db sequential read, read by other session, etc....の削減効果, キャッシュヒット率が高い場合で DB CPUは高いけど実は無駄に高いだけ〜な状況という名の内臓脂肪多くて隠れ肥満なシステムは, 物理IOが少なくてCPU利用率が高い事も多く, リソースうまく使い切ってますねー, スケールアップするしかなさそうですねーと誤診されるケースもあったりw
しっかり診察する必要はありますが, 治療できる可能性がある場合には, Buffer Getsを削減するためIndex Only Scanを利用したチューニングという名の治療(当然副作用を伴います. その点には注意が必要です)を続けることで大きく改善させた例もあります. 実際にそんなことをやってたこともありました.

Statisticsをみるとお判りだと思いますが, Id=2でINDEX FULL SCANとは出ていますが, physical readsが1回, 1blockのアクセスになっている点がポイントです.

実行計画からは, MAX()なのかMIN()なのかは見えてきません. したがって, 実行計画から判断可能なのは, 以下のいずれかであるというろころまでです.

select min(employee_id) from employees;

select max(employee_id) from employees;

-----
社内LT大会で、実行計画は、SQL文のレントゲン写真だ！っぽいLTをした！ @ SQL総合診療所目黒分室（当日、医者のコスプレするの忘れたのは内緒w）

previously on Mac De Oracle

・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 1 / TABLE FULL SCAN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 2 / INDEX UNIQUE SCAN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 3 / INDEX RANGE SCAN, Index Only Scan
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 4 / INDEX RANGE SCAN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 5 / INDEX RANGE SCAN, INLIST ITERATOR
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 6 / INDEX FAST SCAN, Index Only Scan
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 7 / INDEX FULL SCAN,Index Only Scan
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 8 / INDEX SKIP SCAN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 9 / TABLE ACCESS INMEMORY FULL
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 10 / NESTED LOOP JOIN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 11 / MERGE JOIN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 12 / HASH JOIN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 13 / HASH JOIN OUTER
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 14 / HASH JOIN FULL OUTER
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 15 / PX, TABLE ACCESS FULL
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 16 / CONCATENATION
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 17 / SORT UNIQUE, UNION-ALL = UNION
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 18 / UNION-ALL
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 19 / INTERSECTION
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 20 / MINUS
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 21 / WINDOW NOSORT STOPKEY
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 22 / COUNT STOPKEY
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 23 / HASH JOIN - LEFT-DEEP JOIN vs RIGHT-DEEP JOIN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 24 / CONNECT BY NO FILTERING WITH START-WITH
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 25 / UNION ALL (RECURSIVE WITH) DEPTH FIRST, RECURSIVE WITH PUMP
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#1 / STAR TRANSFORM, VECTOR TRANSFORM (DWH向け)
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#2 / MERGE (UPSERT)
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#3 / RDFView

投稿日時 2020年2月23日 (日) 20時56分 Oracle, チューニング, SQL | 固定リンク | 0 | コメント (0)

FAQ / SCOTTスキーマにあるEMP表とかどうすれば作れるの？

SCOTTスキーマをアンロックしたはいいけど、サンプル表がないーーーいなんてときは、utlsampl.sql を実行すればいいよ

SCOTT@orcl> select table_name from user_tables; no rows selected SCOTT@orcl> ! SCOTT@orcl> @?/rdbms/admin/utlsampl Disconnected from Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production Version0.0.0 [oracle@localhost ~]$ sqlplus scott@orcl Enter password: Last Successful login time: Sun Feb 23 2020 06:24:56 -05:00 SQL*Plus: Release 19.0.0.0.0 - Production on Sun Feb 23 06:24:56 2020 Version 19.3.0.0.0 Copyright (c) 1982, 2019, Oracle. All rights reserved. Last Successful login time: Sun Feb 23 2020 06:24:46 -05:00 Connected to: Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production Version 19.3.0.0.0 SCOTT@orcl> select table_name from user_tables; TABLE_NAME ------------------------------ DEPT EMP BONUS SALGRADE SCOTT@orcl> select * from emp; EMPNO ENAME JOB MGR HIREDATE SAL COMM DEPTNO ---------- ---------- --------- ---------- --------- ---------- ---------- ---------- 7369 SMITH CLERK 7902 17-DEC-80 800 20 7499 ALLEN SALESMAN 7698 20-FEB-81 1600 300 30 7521 WARD SALESMAN 7698 22-FEB-81 1250 500 30 7566 JONES MANAGER 7839 02-APR-81 2975 20 7654 MARTIN SALESMAN 7698 28-SEP-81 1250 1400 30 7698 BLAKE MANAGER 7839 01-MAY-81 2850 30 7782 CLARK MANAGER 7839 09-JUN-81 2450 10 7788 SCOTT ANALYST 7566 19-APR-87 3000 20 7839 KING PRESIDENT 17-NOV-81 5000 10 7844 TURNER SALESMAN 7698 08-SEP-81 1500 0 30 7876 ADAMS CLERK 7788 23-MAY-87 1100 20 7900 JAMES CLERK 7698 03-DEC-81 950 30 7902 FORD ANALYST 7566 03-DEC-81 3000 20 7934 MILLER CLERK 7782 23-JAN-82 1300 10 14 rows selected.

--
最近、英会話のレベルチェックうけて、1年半振りにレベルアップ:)

投稿日時 2020年2月23日 (日) 20時34分 Oracle, FAQ, SQL | 固定リンク | 0 | コメント (0)

2019年12月31日 (火)

Mac De Oracle - 気づいたら15年たってた / メモ

カーグラフィックTV（おじさんたちしか見ないだろうけどw）って結構振り返りネタしてるので、Mac De Oracleもたまにはそんなネタを。

ところで、このブログのタイトルですが、当時Mac de Zope（後にCube de Zopeに改名）というPythonというかZopeネタ扱っていたサイトがお気に入りで、その名称などにインスパイアされたのが、このMac De Oracle。
https://discus-hamburg.cocolog-nifty.com/mac_de_oracle/2007/08/post_5133.html

Mac De Oracle season 1 episode 1！記念すべき第一回話w うちの奥さんからBlog楽しいよー、書いてみなよーと、そそのかされたのが運の尽きw （嘘
2005/5/24 - Panther De Oracle10g その１

Cube G4からPowerMac G5になったので、season 2 かだよな〜。OracleからGeneric ConnectivityでPostgreSQL、MySQLそして、FirebirdとかDB Linkでぜーんぶ繋いでた。仕事でしらべてたとはいえ、いろいろ熱いなw
2005/12/31 - Mac De Oracle Heterogeneous! #3

2006年ぐらいからRACも避けて通れなくなりつつあり、資金のない中とうやってお勉強しましょうかということになるわけです。はい。OTN Professional というやつがあって、それを十二分に活用してたのがこと時期かな〜
まだリアルな環境ですね。
2006/12/30 - Mac De Oracle - １０万円 de RAC #2

実はこのころから開発片手に、チューニング案件が多くなってきました。ネタにもしてましたが、このころ多かったのが Rule Base OptimizerからCost base Optimizerに切り替わってCost Baseなにそれ、バインドピークなにそれー
みたいなところからシステムテストやら負荷テスト時期になる、あちこちで、火の手が上がる。みたいな時期でしたーw

バインド変数を全く使ってないシステムで、結合テストで負荷試験したらCPUリソース枯渇 - HPのデカイサーバーがw - バインド変数使えよ案件　とか

32bitのWindowsでメモリ不足が様々な問題を引き起こしてた、それにバインド変数つかってねーし、ORA-12518連発　- バインド変数使えよ、階層問合使えよ、32bitのメモリ空間のサイズ考えてねー　案件　とか

火消しでいろいろ呼ばれましたーw

という、今ではあまりお目にかからなくなってきたチューニングの数々ですが、これ以降SQLチューニング案件に関わることが多くなっていきますw が、子供がうまれて、それどころじゃない、という感じにもなったのがこのころですねw 保育園待機児童問題に気づいたのもこのころでした。
2007/12/31 - よいお年を！ 2008/12/28 - よいお年を！ 2009/12/31 - よいお年を！

子育てでドタバタしている間にも、世の中は変わっていきます、そして、VirtualBox de RAC というリアルな環境から仮想環境で Oracleと戯れ始めます。　　
2010/12/31 - VirtualBox de Oracle11g R2 RAC #13

この年に、JPOUG (Japan Oracle User Group)がBootしました。そして、そのきっかけを作ったGuutaraと先日で飲んだばかりw。twitterやjjugとかGoogle Waveとかゆるーいつながりがすべての始まりでしたね〜。
2011/12/31 - よいお年を！

このころRACネタを封印、s4r_agentさんがRAC何ノード起動できるかシリーズをスタート。SQLチューニングでスクランブルしたり、DBおそーいと呼ばれていったら、javascript遅いだけーみたいな IEのjs遅い案件に巻き込まれることもおおかった年w でした。
2012/12/25 - Indexがあれば、いいってもんじゃない。中身がたいせつ

こんなネタもやってましたねー
2013/12/31 - SELECT ~ FOR UPDATE SKIP LOCKED　その２

SQLチューニングキャラが確立されてきたこともあり、ネタ傾向が徐々に変わってきたような気がします。
2014/12/17 - 机上SQLチューニング、クイズ！　駆動表（外部表）はどれだ！！！！

細かいテクニックをおぼえるのに遊びながら覚えてたようなw
2015/12/30 - Pipelined table function で ascii art

昔のmacOSというかMacOSというか、Kanji Talkというか無駄なところにいろいろニッコリするような仕掛けがあってある意味余裕がある感じがしなくもないわけですが、最近のOS含め、そんなのあるのかなー。
2016/12/30 - 昔、Mac OSがやってようなことを...　VirtualBox の　GuestOS起動スプラッシュ

いろいろと悩み始めてた年ですw
2017/12/4 - ”utl_file I/O” - この症状はあれの可能性が高いですね。

そして, 移籍後、気持ちの余裕がなくてあまり書けてない年だったw
2018/11/25 - MacPro (mid2012)をmacOS Mojaveにアップデート / FAQ

気持ちの余裕は無いなりにw いろいろやってますw
2019/12/30 - 実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 おまけ#3

2019/12/31
そして、16年目へ

投稿日時 2019年12月31日 (火) 05時30分日記・コラム・つぶやき, Oracle, SQL | 固定リンク | 0 | コメント (0)

2019年12月30日 (月)

実行計画は,SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 おまけ#3

この実行計画がなにを行っているか見抜けたかたは, 前日のエントリーを読んだか, RDFVIEWを利用したRDF Graphを試したことがある方ぐらいだと思います.
RDF Semantic Graph「RDF 超入門」

RDFトリプルをRelational表にマップしてダイレクトにアクセスする方式なのですが, ご存じない方には何のこっちゃというのも仕方ないと思います.
3,4年前ぐらいに, なんとなーく流れ的に関わることになって, 寝る暇も惜しんでRDFトリプルストア (実態はオブジェクト表だったはず. 違ったらコメント頂けますと幸いです) とこのRDFVIEWのSQLチューニング方法を調べていたもんですw

そのころは余裕なさすぎてブログにも書けずじまいでしたが, 良い機会なのでRDFVIEWを問い合わせた実行計画をレントゲン写真として載せておきます.
詳細は前日の準備段階のエントリーを読んでいただけると良いかと思いますが, 知らない用語とかいきなりでてきているので, なんとなーくそんなもんかなーぐらいの理解よいと思います.

RDFVIEWのを問い合わせるSQL文は, SEM_MATCH()を利用するのが特徴で, RDFVIEW最大の特徴であるRelational表を直接よみながら, 最終的に RDFトリプルを返すという点にあります.
R2RML: RDB to RDF Mapping Language / W3Cあたりを読んでもらうと想像できるのではないかと思います. 読んで最初にきづくのは,それに関わっているのは Oracle社の方だったりしてるので納得感があります.

ということで、
SQLは以下のとおり. 関わったことがない方はこれまた見たこともない　SEM_MATCH()関数が大量のパラメータを取って呼び出されていることが見えるぐらいですね。
裏では, SEM_MODEL()で指定したRDF Graphのモデルに対応したRelational表のEMPLOYEES表からEMPLOYEE_IDを元に, FIRST_NAME, LAST_NAME, MANAGER_IDの3列を, それぞれをトリプルとして返すようなマッピングになっています.

SELECT s , p , o FROM TABLE ( SEM_MATCH ( '{?s ?p ?o}' , SEM_MODELS('TEST_MODEL1') , null , null , null , null , ' ' , null , null , 'RDFUSER' , 'LOCALNET' ) ) ORDER BY s ,p;

RDFUSER@orcl> desc employees Name Null? Type ----------------------------------------- -------- ---------------------------- EMPLOYEE_ID NOT NULL NUMBER(6) FIRST_NAME VARCHAR2(20) LAST_NAME NOT NULL VARCHAR2(25) EMAIL NOT NULL VARCHAR2(25) PHONE_NUMBER VARCHAR2(20) HIRE_DATE NOT NULL DATE JOB_ID NOT NULL VARCHAR2(10) SALARY NUMBER(8,2) COMMISSION_PCT NUMBER(2,2) MANAGER_ID NUMBER(6) DEPARTMENT_ID NUMBER(4) RDFUSER@orcl> break on index_name skip 1 RDFUSER@orcl> select index_name,column_name from user_ind_columns where table_name='EMPLOYEES' order by 1,2; INDEX_NAME COLUMN_NAME ------------------------------ ------------------------------ EMP_DEPARTMENT_IX DEPARTMENT_ID EMP_EMAIL_UK EMAIL EMP_EMP_ID_PK EMPLOYEE_ID EMP_JOB_IX JOB_ID EMP_MANAGER_IX MANAGER_ID EMP_NAME_IX FIRST_NAME LAST_NAME

では, 実行計画を読み解いてみましょう.

EMPLOYEES表からEMPLOYEE_IDを元に, FIRST_NAME, LAST_NAME, MANAGER_IDの3列と説明しましたが, それぞれの列に索引が存在しているため, Index Only Scanで索引のみをアクセスし,
Id=7,8,9でEMPLOYEE_IDをEMP_EMP_ID_PK索引から, MANAGER_IDをEMP_MANAGER_IX索引から EMPLOYEE_IDとMANAGER_IDの2列からなら行を結合で作り出しています.
Id=11,12,13で同じく, EMPLOYEE_IDとEMP_NAME_IX索引から, EMPLOYEE_IDとLAST_NAMEの2列からなる行を結合で作り出してます.
Id=15,16,17でも, EMPLOYEE_IDとEM_NAME_IX索引から, EMPLOYEE_IDとFAST_NAMEの2列からなる行を結合でつくりだしています.

これらの動きから, トリプルを作成するために, EMPLOYEE_ID列, MANAGER_ID, FAST_NAME, FIRST_NAME列ぞれぞれを取得するために複数回索引にアクセスしています.
もし索引がなかったら, それぞれの列を取得するために, 複数回全表走査を行うだろうということは容易に想像できます. これらの動きは、RDFVIEWの特性の一つになっています. Relational表に格納されたデータを即刻RDFトリプルとして参照したいという目的のために性能にはある程度目をつぶっている姿が見えてきます.
列持ちのデータをトリプルという, ある意味, 行持ちのデータへ縦横変換しているわけですから仕方ない動作ではあります.

データの新鮮さよりも性能を, というケースでは, ロードという作業は必要になりますがトリプルストアを利用したほうが有利にはなります. トリプルストアをアクセスする実行計画は気が向いたら載せるかもしれません.
覚えておいてほしいことは, Id=19やPredicate InformationにRDF_RRのようなオブジェクトとUNION ALLのVIEWが1~3個登場したらRDFVIEWだろうということです. 治療が必要になった場合などには役にたつかもしれません.

-----
それでは, みなさま, 良いお年をお迎えください.

previously on Mac De Oracle
・実行計画は,SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 1 / TABLE FULL SCAN
・実行計画は,SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 2 / INDEX UNIQUE SCAN
・実行計画は,SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 3 / INDEX RANGE SCAN, Index Only Scan
・実行計画は,SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 4 / INDEX RANGE SCAN
・実行計画は,SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 5 / INDEX RANGE SCAN, INLIST ITERATOR
・実行計画は,SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 6 / INDEX FAST SCAN, Index Only Scan
・実行計画は,SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 7 / INDEX FULL SCAN,Index Only Scan
・実行計画は,SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 8 / INDEX SKIP SCAN
・実行計画は,SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 9 / TABLE ACCESS INMEMORY FULL
・実行計画は,SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 10 / NESTED LOOP JOIN
・実行計画は,SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 11 / MERGE JOIN
・実行計画は,SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 12 / HASH JOIN
・実行計画は,SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 13 / HASH JOIN OUTER
・実行計画は,SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 14 / HASH JOIN FULL OUTER
・実行計画は,SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 15 / PX, TABLE ACCESS FULL
・実行計画は,SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 16 / CONCATENATION
・実行計画は,SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 17 / SORT UNIQUE, UNION-ALL = UNION
・実行計画は,SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 18 / UNION-ALL
・実行計画は,SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 19 / INTERSECTION
・実行計画は,SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 20 / MINUS
・実行計画は,SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 21 / WINDOW NOSORT STOPKEY
・実行計画は,SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 22 / COUNT STOPKEY
・実行計画は,SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 23 / HASH JOIN - LEFT-DEEP JOIN vs RIGHT-DEEP JOIN
・実行計画は,SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 24 / CONNECT BY NO FILTERING WITH START-WITH
・実行計画は,SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 25 / UNION ALL (RECURSIVE WITH) DEPTH FIRST, RECURSIVE WITH PUMP
・実行計画は,SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#1 / STAR TRANSFORM, VECTOR TRANSFORM (DWH向け)
・実行計画は,SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#2 / MERGE (UPSERT)

投稿日時 2019年12月30日 (月) 00時00分 Oracle, チューニング, SQL, Oracle Database 19c | 固定リンク | 0 | コメント (0)

2019年12月29日 (日)

RDFナレッジ・グラフ / 備忘録 19c

5年ぐらい前に触ったことがある程度で、すっかり忘れてしまった。しばらくぶりで思い出してパタパタしてみたら、Apache Jenaも含めていろいろ変わっていたので備忘録

RDFナレッジ・グラフ開発者ガイド RDFナレッジ・グラフの概要

R2RML: RDB to RDF Mapping Language

A Direct Mapping of Relational Data to RDF

いろいろ思い出しながら....

$ sqlplus sys@orclcdb as sysdba SQL*Plus: Release 19.0.0.0.0 - Production on Sat Dec 28 00:51:52 2019 Version 19.3.0.0.0 Copyright (c) 1982, 2019, Oracle. All rights reserved. Enter password: Connected to: Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production Version 19.3.0.0.0 SQL> col namespace for a30 SQL> col value for a40 SQL> col description for a50 SQL> set linesize 400 SQL> set tab off SYS@orclcdb> select * from MDSYS.RDF_PARAMETER; NAMESPACE ATTRIBUTE VALUE DESCRIPTION ------------------- ----------------- ------------- -------------------------------------------------- COMPONENT RDFCTX INSTALLED Semantic (Text) Search component COMPONENT RDFOLS INSTALLED RDF Optional component for OLS support MDSYS SEM_VERSION 19.1.0.0.0 VALID SYS@orclcdb> r 1 SELECT namespace, attribute, value FROM mdsys.rdf_parameter 2 WHERE namespace='MDSYS' 3 AND attribute IN ('FLOAT_DOUBLE_DECIMAL', 4 'XSD_TIME', 'XSD_BOOLEAN', 5* 'DATA_CONVERSION_CHECK') no rows selected SYS@orclcdb> conn system@orcl Enter password: Connected. SYSTEM@orcl> create tablespace rdf_users datafile 'rds_users01.dbf' size 128m reuse autoextend on next 64m maxsize unlimited segment space management auto; Tablespace created. SYSTEM@orcl> create user rdfuser identified by hogehoge default tablespace rdf_users temporary tablespace temp; User created. SYSTEM@orcl> grant create view to rdfuser; Grant succeeded. SYSTEM@orcl> grant unlimited tablespace to rdfuser; Grant succeeded. SYSTEM@orcl> grant unlimited tablespace to mdsys; Grant succeeded. SYSTEM@orcl> grant select any dictionary to rdfuser; Grant succeeded. SYSTEM@orcl> grant connect, resource to rdfuser; Grant succeeded. SYSTEM@orcl> execute sem_apis.create_sem_network('RDF_USERS', network_owner=>'RDFUSER', network_name=>'LOCALNET'); PL/SQL procedure successfully completed. SYSTEM@orcl> conn rdfuser@orcl Enter password: Connected. RDFUSER@orcl> RDFUSER@orcl> l 1 create table r2rmlview_nt_staging_tab ( 2 rdf$stc_sub varchar2(4000) not null 3 ,rdf$stc_pred varchar2(4000) not null 4 ,rdf$stc_obj varchar2(4000) not null 5 ) 6* nologging RDFUSER@orcl> / Table created. RDFUSER@orcl> l 1 create table rdfview_export_tab ( 2 rdf$stc_sub varchar2(4000) not null 3 ,rdf$stc_pred varchar2(4000) not null 4 ,rdf$stc_obj varchar2(4000) not null 5 ) 6* nologging RDFUSER@orcl> / Table created.

RDFでいろいろやるには sga_targetやsga_max_sizeはそれなりに必要なので適当に調整

そして、Apache Jenaのrdfcatもdeprecatedになってて、これまたしばし時代に追いつく作業を....

RDFUSER@orcl> !rdfcat --help ------------------------------------------------------------------ DEPRECATED: Please use 'riot' instead. http://jena.apache.org/documentation/io/#command-line-tools ------------------------------------------------------------------ ------------------------------------ DEPRECATED: Please use riot instead. ------------------------------------ Usage: java jena.rdfcat (option|input)* Concatenates the contents of zero or more input RDF documents. Options: -out N3 | N-TRIPLE | RDF/XML | RDF/XML-ABBREV -n expect subsequent inputs in N3 syntax -x expect subsequent inputs in RDF/XML syntax -t expect subsequent inputs in N-TRIPLE syntax -[no]include include rdfs:seeAlso and owl:imports input can be filename, URL, or - for stdin Recognised aliases for -n are: -n3 -ttl or -N3 Recognised aliases for -x are: -xml -rdf or -rdfxml Recognised aliases for -t are: -ntriple Output format aliases: x, xml or rdf for RDF/XML, n, n3 or ttl for N3, t or ntriple for N-TRIPLE See the Javadoc for jena.rdfcat for additional details.

rdfcatに変えて、riot ってやつをつかわなきゃいけなくなったっぽい。

RDFUSER@orcl> !riot -version Jena: VERSION: 3.13.1 Jena: BUILD_DATE: 2019-10-06T18:57:39+0000 RIOT: VERSION: 3.13.1 RIOT: BUILD_DATE: 2019-10-06T18:57:39+0000

ちなみに、SHユーザのEMPLOYEES表や索引をRDFUSERユーザへコピーした上で、以下のような、RDFVIEWとRelational表と列のマッピングをTurtle (Terse RDF Triple Language)で定義した。

RDFUSER@orcl> !cat test_real_rdf_r2rml.ttl @prefix rr: . @prefix xsd: . @prefix ex: . ex:TriplesMap_Employees rr:logicalTable [ rr:tableName "EMPLOYEES" ]; rr:subjectMap [ rr:template "http://r2rml.com/employees/{EMPLOYEE_ID}"; rr:class ex:Employees; ]; rr:predicateObjectMap [ rr:predicate ex:FirstName; rr:objectMap [ rr:column "FIRST_NAME" ]; ]; rr:predicateObjectMap [ rr:predicate ex:LastName; rr:objectMap [ rr:column "LAST_NAME" ]; ]; rr:predicateObjectMap [ rr:predicate ex:ManagerId; rr:objectMap [ rr:column "MANAGER_ID" ]; ].

5年ぐらい前の記憶ではrdfcatを利用して変換していたが、今は、 riot というコマンドを利用してTurtle(Terse RDF Triple Language)をN-Triplesへ変換するみたいね。

RDFUSER@orcl> !riot --out=N-TRIPLE test_real_rdf_r2rml.ttl > test_real_rdf_r2rml_use_riot.nt RDFUSER@orcl> !cat test_real_rdf_r2rml_use_riot.nt _:Bf70c7f0d1b418dc63ad89dbcea313cd1 "EMPLOYEES" . _:Bf70c7f0d1b418dc63ad89dbcea313cd1 . _:Bdd4cf5eb9ecb0b12212d342518513827 "http://r2rml.com/employees/{EMPLOYEE_ID}" . _:Bdd4cf5eb9ecb0b12212d342518513827 . _:Bdd4cf5eb9ecb0b12212d342518513827 . _:B310abfde7d61aac8f303fbd1f4ba5db8 . _:Bfe48b8372e4da59d0ce99e0e24b894ad "FIRST_NAME" . _:B310abfde7d61aac8f303fbd1f4ba5db8 _:Bfe48b8372e4da59d0ce99e0e24b894ad . _:B310abfde7d61aac8f303fbd1f4ba5db8 . _:B11c76919901c01b44cb0e2507a997c28 . _:B5474fc7a1b7c7302521175dac3c58028 "LAST_NAME" . _:B11c76919901c01b44cb0e2507a997c28 _:B5474fc7a1b7c7302521175dac3c58028 . _:B11c76919901c01b44cb0e2507a997c28 . _:Be7008cecff6b130ea15b4ba060cee0fb . _:B0f41936e13c4655082ee47f866dc9f61 "MANAGER_ID" . _:Be7008cecff6b130ea15b4ba060cee0fb _:B0f41936e13c4655082ee47f866dc9f61 . _:Be7008cecff6b130ea15b4ba060cee0fb .

SQL*Loaderを使用したステージング表へのN-Triple形式のデータのロードを参考

RDFUSER@orcl> !cat test_real_rdf_r2rml_nt_load.ctl UNRECOVERABLE LOAD DATA TRUNCATE into table r2rmlview_nt_staging_tab when (1) <> '#' ( RDF$STC_sub CHAR(4000) terminated by whitespace "( CASE WHEN substr(:RDF$STC_sub,1,1)='<' AND substr(:RDF$STC_sub,-1,1)='>' AND length(:RDF$STC_sub)>2 THEN :RDF$STC_sub WHEN substr(:RDF$STC_sub,1,2)='_:' AND REGEXP_LIKE(:RDF$STC_sub,'^(_:)[[:alpha:]][[:alnum:]]*$') THEN :RDF$STC_sub WHEN substr(:RDF$STC_sub,1,1) NOT IN ('\"','<','#') AND substr(:RDF$STC_sub,-1,1) NOT IN ('\"','>') THEN ('<' || SDO_RDF.replace_rdf_prefix(:RDF$STC_sub) || '>') WHEN substr(:RDF$STC_sub,1,1)='#' THEN SDO_RDF.raise_parse_error( 'Ignored Comment Line starting with ', :RDF$STC_sub) ELSE SDO_RDF.raise_parse_error('Invalid Subject', :RDF$STC_sub) END )", RDF$STC_pred CHAR(4000) terminated by whitespace "( CASE WHEN substr(:RDF$STC_pred,1,1)='<' AND substr(:RDF$STC_pred,-1,1)='>' AND length(:RDF$STC_pred)>2 THEN :RDF$STC_pred WHEN substr(:RDF$STC_pred,1,2) != '_:' AND substr(:RDF$STC_pred,1,1) NOT IN ('\"','<') AND substr(:RDF$STC_pred,-1,1) NOT IN ('\"','>') THEN ('<' || SDO_RDF.replace_rdf_prefix(:RDF$STC_pred) || '>') ELSE SDO_RDF.raise_parse_error('Invalid Predicate', :RDF$STC_pred) END )", -- -- right-trimming of WHITESPACEs is reqd for "RDF$STC_obj" -- (due to absence of "TERMINATED BY WHITESPACE") -- -- For ease of editing below replace -- "rtrim(:RDF$STC_obj,'. '||CHR(9)||CHR(10)||CHR(13))" with ":xy". -- and then replace back -- RDF$STC_obj CHAR(4000) "( CASE WHEN substr(rtrim(:RDF$STC_obj,'. '||CHR(9)||CHR(10)||CHR(13)),1,1)='<' AND substr(rtrim(:RDF$STC_obj,'. '||CHR(9)||CHR(10)||CHR(13)),-1,1)='>' AND length(rtrim(:RDF$STC_obj,'. '||CHR(9)||CHR(10)||CHR(13)))>2 THEN rtrim(:RDF$STC_obj,'. '||CHR(9)||CHR(10)||CHR(13)) WHEN substr(rtrim(:RDF$STC_obj,'. '||CHR(9)||CHR(10)||CHR(13)),1,1)='\"' AND substr(rtrim(:RDF$STC_obj,'. '||CHR(9)||CHR(10)||CHR(13)),-1,1)='\"' AND length(rtrim(:RDF$STC_obj,'. '||CHR(9)||CHR(10)||CHR(13)))>1 THEN rtrim(:RDF$STC_obj,'. '||CHR(9)||CHR(10)||CHR(13)) WHEN substr(rtrim(:RDF$STC_obj,'. '||CHR(9)||CHR(10)||CHR(13)),1,2)='_:' AND REGEXP_LIKE(rtrim(:RDF$STC_obj,'. '||CHR(9)||CHR(10)||CHR(13)), '^(_:)[[:alpha:]][[:alnum:]]*$') THEN rtrim(:RDF$STC_obj,'. '||CHR(9)||CHR(10)||CHR(13)) WHEN substr(rtrim(:RDF$STC_obj,'. '||CHR(9)||CHR(10)||CHR(13)),1,1) NOT IN ('\"','<') AND substr(rtrim(:RDF$STC_obj,'. '||CHR(9)||CHR(10)||CHR(13)),-1,1) NOT IN ('\"','>') THEN ('<' || SDO_RDF.replace_rdf_prefix( rtrim(:RDF$STC_obj,'. '||CHR(9)||CHR(10)||CHR(13))) || '>') WHEN substr(rtrim(:RDF$STC_obj,'. '||CHR(9)||CHR(10)||CHR(13)),1,1)='\"' AND substr(rtrim(:RDF$STC_obj,'. '||CHR(9)||CHR(10)||CHR(13)),-1,1) NOT IN ('\"','>') AND instr(rtrim(:RDF$STC_obj,'. '||CHR(9)||CHR(10)||CHR(13)),'\"\@',-1)>1 AND REGEXP_LIKE(rtrim(:RDF$STC_obj,'. '||CHR(9)||CHR(10)||CHR(13)), '^\"[[:print:]]*\"\@[[:alpha:]]+(-[[:alnum:]]+)*$') THEN rtrim(:RDF$STC_obj,'. '||CHR(9)||CHR(10)||CHR(13)) WHEN (substr(rtrim(:RDF$STC_obj,'. '||CHR(9)||CHR(10)||CHR(13)),1,1)='\"' AND instr(rtrim(:RDF$STC_obj,'. '||CHR(9)||CHR(10)||CHR(13)),'\"^^',-1)>1 AND (length(rtrim(:RDF$STC_obj,'. '||CHR(9)||CHR(10)||CHR(13)))- (instr(rtrim(:RDF$STC_obj,'. '||CHR(9)||CHR(10)||CHR(13)),'\"^^',-1)+4) )>0) THEN SDO_RDF.pov_typed_literal( rtrim(:RDF$STC_obj,'. '||CHR(9)||CHR(10)||CHR(13))) ELSE SDO_RDF.raise_parse_error( 'Invalid Object', rtrim(:RDF$STC_obj,'. '||CHR(9)||CHR(10)||CHR(13))) END )" ) RDFUSER@orcl> exit

$ sqlldr userid=rdfuser@orcl control=test_real_rdf_r2rml_nt_load.ctl data=test_real_rdf_r2rml_use_riot.nt direct=true skip=0 load=1000000 discardmax=0 bad=test_real_rdf_r2rml_nt_load.bad discard=test_real_rdf_r2rml_nt_load.rej log=test_real_rdf_r2rml_nt_load.log errors=1000000 Password: SQL*Loader: Release 19.0.0.0.0 - Production on Sat Dec 28 02:05:44 2019 Version 19.3.0.0.0 Copyright (c) 1982, 2019, Oracle and/or its affiliates. All rights reserved. Path used: Direct, LOAD=1000000 Load completed - logical record count 17. Table R2RMLVIEW_NT_STAGING_TAB: 17 Rows successfully loaded. Check the log file: test_real_rdf_r2rml_nt_load.log for more information about the load.

そして、SEM_MATCH()関数を利用してモデルと問い合わせると....

RDFUSER@orcl> @test_real_rdf_cre_rdfview.sql PL/SQL procedure successfully completed. RDFUSER@orcl> l 1 SELECT 2 s 3 , p 4 , o 5 FROM 6 TABLE ( 7 SEM_MATCH ( 8 '{?s ?p ?o}' 9 , SEM_MODELS('TEST_MODEL1') 10 , null 11 , null 12 , null 13 , null 14 , ' ' 15 , null 16 , null 17 , 'RDFUSER' 18 , 'LOCALNET' 19 ) 20 ) 21 ORDER BY 22 s 23 ,p 24* RDFUSER@orcl> RDFUSER@orcl> @test_query_rdfview.sql S P O ---------------------------------------- -------------------------------------------------- ---------------------------------------- http://r2rml.com/employees/100 http://r2rml.com/ns#FirstName Steven http://r2rml.com/employees/100 http://r2rml.com/ns#LastName King http://r2rml.com/employees/100 http://www.w3.org/1999/02/22-rdf-syntax-ns#type http://r2rml.com/ns#Employees http://r2rml.com/employees/101 http://r2rml.com/ns#FirstName Neena http://r2rml.com/employees/101 http://r2rml.com/ns#LastName Kochhar http://r2rml.com/employees/101 http://r2rml.com/ns#ManagerId 100 http://r2rml.com/employees/101 http://www.w3.org/1999/02/22-rdf-syntax-ns#type http://r2rml.com/ns#Employees http://r2rml.com/employees/102 http://r2rml.com/ns#FirstName Lex http://r2rml.com/employees/102 http://r2rml.com/ns#LastName De Haan http://r2rml.com/employees/102 http://r2rml.com/ns#ManagerId 100 ・・・中略・・・ http://r2rml.com/employees/205 http://r2rml.com/ns#FirstName Shelley http://r2rml.com/employees/205 http://r2rml.com/ns#LastName Higgins http://r2rml.com/employees/205 http://r2rml.com/ns#ManagerId 101 http://r2rml.com/employees/205 http://www.w3.org/1999/02/22-rdf-syntax-ns#type http://r2rml.com/ns#Employees http://r2rml.com/employees/206 http://r2rml.com/ns#FirstName William http://r2rml.com/employees/206 http://r2rml.com/ns#LastName Gietz http://r2rml.com/employees/206 http://r2rml.com/ns#ManagerId 205 http://r2rml.com/employees/206 http://www.w3.org/1999/02/22-rdf-syntax-ns#type http://r2rml.com/ns#Employees

投稿日時 2019年12月29日 (日) 22時10分 SQL, Oracle Database 19c, RDF Graph | 固定リンク | 0 | コメント (0)

実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 おまけ#2

Id=1とId=2のMERGE STATEMENTとMERGEですぐにわかるとおもいます. MERGE文(通称UPSERT)の実行計画というレントゲン写真w

merge into sample_table using sample_table_temp on (sample_table.id = sample_table_temp.id) when matched then update set sample_table.data = sample_table_temp.data, sample_table.update_timestamp = systimestamp when not matched then insert values ( sample_table_temp.id, sample_table_temp.data, systimestamp, null );

過去のMERGE文のエントリー, 少ないけど書いてた :)
MERGE文　#1 - 重複行の削除
 MERGE文　#2 - 同一表でマージ?!
----
PIVOT / UNPIVOTやWITH句でinlineになるかtemp tableとしてマテリアライズされるかなんてものありだよなぁと思いつつ。多分いつか書くということにして、別のネタを思いついたのでそれを先に書くか

previously on Mac De Oracle
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 1 / TABLE FULL SCAN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 2 / INDEX UNIQUE SCAN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 3 / INDEX RANGE SCAN, Index Only Scan
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 4 / INDEX RANGE SCAN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 5 / INDEX RANGE SCAN, INLIST ITERATOR
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 6 / INDEX FAST SCAN, Index Only Scan
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 7 / INDEX FULL SCAN、Index Only Scan
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 8 / INDEX SKIP SCAN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 9 / TABLE ACCESS INMEMORY FULL
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 10 / NESTED LOOP JOIN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 11 / MERGE JOIN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 12 / HASH JOIN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 13 / HASH JOIN OUTER
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 14 / HASH JOIN FULL OUTER
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 15 / PX, TABLE ACCESS FULL
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 16 / CONCATENATION
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 17 / SORT UNIQUE, UNION-ALL = UNION
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 18 / UNION-ALL
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 19 / INTERSECTION
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 20 / MINUS
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 21 / WINDOW NOSORT STOPKEY
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 22 / COUNT STOPKEY
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 23 / HASH JOIN - LEFT-DEEP JOIN vs RIGHT-DEEP JOIN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 24 / CONNECT BY NO FILTERING WITH START-WITH
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 25 / UNION ALL (RECURSIVE WITH) DEPTH FIRST, RECURSIVE WITH PUMP
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#1 / STAR TRANSFORM, VECTOR TRANSFORM (DWH向け)

投稿日時 2019年12月29日 (日) 00時00分 Oracle, チューニング, SQL | 固定リンク | 0 | コメント (0)

2019年12月28日 (土)

実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 おまけ#1

ヒントで無理やりSQL transformationーーーん, してますが、DWH系、スタースキーマで利用する star transformationです.
ファクト表から各ディメンジョン表への参照整合性制約とビットマップ索引が必須となります. また, BITMAP MERGE/BITMAP CONVERSION TO ROWIDS/TABLE ACCESS BY USER ROWID (Id=33)にあるようにROWIDで1行1行アクセスする動きからも想像できると思いますが, ディメンジョン表のデータでファクト表が十分に絞り込めないケースでは性能的メリットはありません。ファクト表が絞り込めずに, 数億行を1行1行取得（シリアルに）していることを思い描ければどのようなケースが使いどころかも想像できるのではないでしょうか？
実行計画の特徴は, BITMAP MERGE/BITMAP CONVERSION TO ROWIDS というディメンジョン表のビットマップ索引を利用したアクセスと, ファクト表をなる表をBITMAP CONVERSION TO ROWIDSでえられるROWIDでアクセスしているとという点.
そして、Noteセクションにリストされる - star transformation used for this statement で判断できます.

SELECT /*+ STAR_TRANSFORMATION */ ch.channel_class , c.cust_city , t.calendar_quarter_desc , SUM(s.amount_sold) sales_amount FROM sales s , times t , customers c , channels ch WHERE s.time_id = t.time_id AND s.cust_id = c.cust_id AND s.channel_id = ch.channel_id AND c.cust_state_province = 'CA' AND ch.channel_desc in ('Internet','Catalog') AND t.calendar_quarter_desc IN ('1999-Q1','1999-Q2') GROUP BY ch.channel_class , c.cust_city , t.calendar_quarter_desc;

もう一つ, star transformationといえば, vector transformationも書かないと. この実行計画という名のレントゲン写真も一目見れば忘れることはないという特徴を持っています.
全く同じSQLでも可能ですが、star transformationのようにディメンジョン表でファクト表のデータが十分に絞りきれない場合やright-deep joinでもハッシュ結合が重すぎてParallel Queryにしても伸び悩むケースでは, ほぼ結合を行わない(行っても結合する行数が少ないので影響がすくない) vector transformの出番ですよね.
KEY VECTOR USEでディメンジョン表からin-memory accumulatorと呼ばれる多次元構造体を作成し, TABLE ACCESS INMEMORY FULLでファクト表を高速に読み出しつつ, in-memory accumulator上で集計. ディメンジョン表をファクト表を結合しないので巨大なハッシュ結合によるtemp落ちからも解放されます.
Noteセクションに- vector transformation used for this statementとリストされます. 特徴を見分けやすいですよね.

SELECT /*+ VECTOR_TRANSFORM */ ch.channel_class , c.cust_city , t.calendar_quarter_desc , SUM(s.amount_sold) sales_amount FROM sales s , times t , customers c , channels ch WHERE s.time_id = t.time_id AND s.cust_id = c.cust_id AND s.channel_id = ch.channel_id GROUP BY ch.channel_class , c.cust_city , t.calendar_quarter_desc;

JPOUG Advent Calendar 2016の17日目のエントリーでも書いてました.
スタースキーマを扱う実行計画の特徴
-----
30日が私の仕事納めなので, あと2つかくかも

previously on Mac De Oracle
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 1 / TABLE FULL SCAN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 2 / INDEX UNIQUE SCAN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 3 / INDEX RANGE SCAN, Index Only Scan
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 4 / INDEX RANGE SCAN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 5 / INDEX RANGE SCAN, INLIST ITERATOR
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 6 / INDEX FAST SCAN, Index Only Scan
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 7 / INDEX FULL SCAN、Index Only Scan
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 8 / INDEX SKIP SCAN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 9 / TABLE ACCESS INMEMORY FULL
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 10 / NESTED LOOP JOIN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 11 / MERGE JOIN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 12 / HASH JOIN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 13 / HASH JOIN OUTER
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 14 / HASH JOIN FULL OUTER
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 15 / PX, TABLE ACCESS FULL
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 16 / CONCATENATION
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 17 / SORT UNIQUE, UNION-ALL = UNION
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 18 / UNION-ALL
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 19 / INTERSECTION
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 20 / MINUS
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 21 / WINDOW NOSORT STOPKEY
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 22 / COUNT STOPKEY
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 23 / HASH JOIN - LEFT-DEEP JOIN vs RIGHT-DEEP JOIN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 24 / CONNECT BY NO FILTERING WITH START-WITH
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 25 / UNION ALL (RECURSIVE WITH) DEPTH FIRST, RECURSIVE WITH PUMP

投稿日時 2019年12月28日 (土) 23時00分 Oracle, チューニング, SQL, Advent Calendar | 固定リンク | 0 | コメント (0)

2019年12月25日 (水)

実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 Day 25

実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 Day 25のエントリーです.
そして, ついに Advent Calendar 2019 全部俺　完走でございます. T_T 感涙w

Day 24 のつづきから.

CONNECT BY NO FILTERING WITH START-WITHとPredicate Information の 1 - access("MGR"=PRIOR "EMPNO")という部分から, Oracle Databaseの方言であると気づけた方は正解です.

CONNECT BY と　PRIOR を利用した階層問合です. この手の問合ができなかったRDBMSではアンチパターンとされていましたが, Oracle Databasedでは..思い出せない, Oracle 7のころにはすでに存在していた構文です.

以下のようなSQL文をイメージできたら正解だと思います.

select empno ,ename ,job ,mgr ,level from emp start with mgr is null connect by prior empno = mgr;

では, Advent Calendar最後なので, 本題と、あわせて解説もしてしまいましょう！

実行計画は以下のような感じになります.

最後のお題は, 他のRDBMSでも利用できるようになったものが多い, 再帰問合です. 階層問合と同じことも行えます.
ただし、実行計画を見ていただくとわかりますが, 階層問合より再帰問合のほうが実行計画で行う必要のある操作が多いことに気づくはずです. この例の再帰問合では, EMP表に加え, IX_EMP索引を INDEX FULL SCANしたうえで, EMP表を統べてアクセスしているように見えます. TABLE ACCESS FULLでもよいとは思いますが, オプティマイザのミスかもしれませんね.(詳細まで調べてないですが)
つまり, 階層問合のTABLE ACCESS FULLが一度だけの実行計画と比較しても明らかに操作が多いことがわかります. この結果から, 階層問合と同じ結果を再帰問合で得るより, 方言ではありますが, 階層問合を利用したほうがコストは低いと考えることができます. 標準的な再帰問合を利用するか方言の階層問合を利用するかはその時の判断にはなりますが, これらの特徴を理解したうで, どちらを利用するか判断したようが良いと, 私は考えています.

with employees ( empno , ename , job , mgr , lvl ) as ( select empno , ename , job , mgr , 1 lvl from emp where mgr is null union all select e1.empno , e1.ename , e1.job , e1.mgr , e2.lvl + 1 from emp e1 inner join employees e2 on e2.empno = e1.mgr ) search depth first by mgr , empno set order# select empno , ename , job , mgr , lvl from employees order by order#;

そういえば, 昔, 階層問合と再帰問合ネタを書いてましたw
階層問合せか、再帰問合せか、それが問題だ
 階層問合せか、再帰問合せか、それが問題だ #2
階層問合せか、再帰問合せか、それが問題だ #3 おまけ

--------
来年も JPOUG をよろしくお願いいたします。

では、皆様、メリークリスマス、そして、良いお年をお迎えください。

previously on Mac De Oracle
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 1 / TABLE FULL SCAN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 2 / INDEX UNIQUE SCAN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 3 / INDEX RANGE SCAN, Index Only Scan
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 4 / INDEX RANGE SCAN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 5 / INDEX RANGE SCAN, INLIST ITERATOR
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 6 / INDEX FAST SCAN, Index Only Scan
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 7 / INDEX FULL SCAN、Index Only Scan
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 8 / INDEX SKIP SCAN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 9 / TABLE ACCESS INMEMORY FULL
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 10 / NESTED LOOP JOIN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 11 / MERGE JOIN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 12 / HASH JOIN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 13 / HASH JOIN OUTER
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 14 / HASH JOIN FULL OUTER
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 15 / PX, TABLE ACCESS FULL
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 16 / CONCATENATION
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 17 / SORT UNIQUE, UNION-ALL = UNION
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 18 / UNION-ALL
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 19 / INTERSECTION
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 20 / MINUS
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 21 / WINDOW NOSORT STOPKEY
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 22 / COUNT STOPKEY
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 23 / HASH JOIN - LEFT-DEEP JOIN vs RIGHT-DEEP JOIN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 24 / CONNECT BY NO FILTERING WITH START-WITH

投稿日時 2019年12月25日 (水) 02時10分 Oracle, チューニング, SQL, イベント, Advent Calendar | 固定リンク | 0 | コメント (0)

2019年12月24日 (火)

実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 Day 24

実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 Day 24のエントリーです.

Day 23 のつづきから.

2つのHASH JOINのなにが違うのか. 実行計画の見た目は異なりますが, SQL文はどちらも同じです. (ただし, 2つめの実行計画はヒントを利用して強制した実行計画です.)
どちらの実行計画も3表をINNER JOINしています.

違いは結合順序.

一つ目は一般的なバッチ系処理でよく見かけますが, 二つ目はDWH系で見かけることが多いのではないでしょうか？　
バッチ系でも必要があれば同様の最適化は行われますが ;)

一つ目は小さいと見積もられているTAB3表をビルド表にして、次に小さいと見積もられているTAB311を結合、その結合結果をビルド表にしてTAB31と結合しています.

二つ目はヒントで無理やり変更している影響で実行計画の見積もり行数やサイズに惑わされてしまいますが, そこは気にしないでください. m(_ _)m
ビルド表が, TAB311とTAB31になっていることに気づければ100点です.
ハッシュ結合のビルド表には結果セットの小さいものが選ばれます.
つまり, TAB3表が実はDWHでいうFACT表になっているようなケースで, 結合するディメンジョン表の表が小さい表となる状況(スタースキーマ)をイメージできればOKだと思います.

SQL文は同じでもハッシュ結合するビルド表を適宜入れ替えています.
DWH系では, ファクト表が巨大であるケースが多く一つ目の実行計画場合, TAB3と結合した結果巨大なビルド表を持ち回ることになりハッシュ結合の特性上どうしても不利になります.
それを避けるため, ファクト表より小さいディメンジョン表が常にビルド表になるような実行計画が, 二つ目の実行計画です.

以下、津島さんが紹介している left-deep joinとright-deep joinも参考するとよいと思います.
津島博士のパフォーマンス講座　第46回　パーティション・プルーニングとハッシュ結合について
https://www.oracle.com/technetwork/jp/database/articles/tsushima/tsushima-hakushi-46-2547814-ja.html

以下のようなSQL文をイメージできたら正解だと思います.

select * from tab3 inner join tab31 on tab3.item_code = tab31.item_code inner join tab311 on tab3.unique_id = tab311.unique_id;

RIGHT-DEEP joinの実行計画へ強制変更させたヒントは以下のとおり. 二つ目の実行計画はこのヒントでオプティマイザの意思に反しw むりやり作り出した実行計画です.

select /*+ swap_join_inputs(tab31) swap_join_inputs(tab311) */ * from tab3 inner join tab31 on tab3.item_code = tab31.item_code inner join tab311 on tab3.unique_id = tab311.unique_id;

では、本題.

この実行計画という名のレントゲン写真から, どのようなSQL文をイメージしますか？　また, どのような特徴をもっていると思いますか？

CONNECT BY NO FILTERING WITH START-WITHはむかしからあるOracle Databaseの方言で, 最近は他のRDBMSでも似たような構文が使えるようになりましたよね...なんとなく, 最終日のヒントを書いてしまったような気がしないでもない.

--------
全部俺 Advent Calendarももう少し。がんばれ、俺w

Day 25 へつづく

previously on Mac De Oracle
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 1 / TABLE FULL SCAN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 2 / INDEX UNIQUE SCAN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 3 / INDEX RANGE SCAN, Index Only Scan
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 4 / INDEX RANGE SCAN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 5 / INDEX RANGE SCAN, INLIST ITERATOR
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 6 / INDEX FAST SCAN, Index Only Scan
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 7 / INDEX FULL SCAN、Index Only Scan
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 8 / INDEX SKIP SCAN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 9 / TABLE ACCESS INMEMORY FULL
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 10 / NESTED LOOP JOIN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 11 / MERGE JOIN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 12 / HASH JOIN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 13 / HASH JOIN OUTER
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 14 / HASH JOIN FULL OUTER
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 15 / PX, TABLE ACCESS FULL
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 16 / CONCATENATION
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 17 / SORT UNIQUE, UNION-ALL = UNION
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 18 / UNION-ALL
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 19 / INTERSECTION
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 20 / MINUS
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 21 / WINDOW NOSORT STOPKEY
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 22 / COUNT STOPKEY
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 23 / HASH JOIN - LEFT-DEEP JOIN vs RIGHT-DEEP JOIN

投稿日時 2019年12月24日 (火) 00時00分 Oracle, チューニング, SQL, イベント, Advent Calendar | 固定リンク | 0 | コメント (0)

2019年12月23日 (月)

実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 Day 23

実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 Day 23のエントリーです.

Day 22 のつづきから.

COUNT STOPKEY前日のWINDOW NOSORT STOPKEYに似てはいます. もうお気づきですよね？　方言のほうです.

STOPKEYなので, 行数をカウントしています. Predicate Informationをみると答えもでています. 1 - filter(ROWNUM<=3) が構文のヒントですよね.

以下のようなSQL文をイメージできたら正解だと思います.

select * from tab3 where rownum <= 3;

では、本題.

今回は, なんと, 2のレントゲン写真.

この実行計画という名のレントゲン写真から, どのようなSQL文をイメージしますか？　また, どのような特徴をもっていると思いますか？

どちらもDay 12に紹介したHASH JOINですが, 何かがちがいますよね？どのような状況なのでしょうか？

--------
ねむけをこらえつつw

Day 24 へつづく

previously on Mac De Oracle
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 1 / TABLE FULL SCAN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 2 / INDEX UNIQUE SCAN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 3 / INDEX RANGE SCAN, Index Only Scan
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 4 / INDEX RANGE SCAN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 5 / INDEX RANGE SCAN, INLIST ITERATOR
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 6 / INDEX FAST SCAN, Index Only Scan
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 7 / INDEX FULL SCAN、Index Only Scan
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 8 / INDEX SKIP SCAN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 9 / TABLE ACCESS INMEMORY FULL
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 10 / NESTED LOOP JOIN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 11 / MERGE JOIN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 12 / HASH JOIN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 13 / HASH JOIN OUTER
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 14 / HASH JOIN FULL OUTER
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 15 / PX, TABLE ACCESS FULL
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 16 / CONCATENATION
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 17 / SORT UNIQUE, UNION-ALL = UNION
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 18 / UNION-ALL
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 19 / INTERSECTION
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 20 / MINUS
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 21 / WINDOW NOSORT STOPKEY
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 22 / COUNT STOPKEY

投稿日時 2019年12月23日 (月) 00時00分 Oracle, チューニング, SQL, イベント, Advent Calendar | 固定リンク | 0 | コメント (0)

2019年12月22日 (日)

実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 Day 22

実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 Day 22のエントリーです.

Day 21 のつづきから.

WINDOW NOSORT STOPKEY STOPKEY とでて行数をカウントしてるってイメージが浮かんだらほぼ正解で, 方言をつかうか, SQL:2008 な違いになってきます. とは言っても多少癖が違ったりしますが.

比較的あたらしいと昨日書いていたのがヒントではあるのですが, WINDOW というところと,　Predicate Information に内部的には、ROW_NUMBER() OVER() とWINDOWS関数を利用しているところに気がつけば, SQL:2008 側の構文であるこに気づけるはずです.

以下のようなSQL文をイメージできたら正解だと思います.

select * from tab3 fetch first 3 rows only;

では、本題.

この実行計画という名のレントゲン写真から, どのようなSQL文をイメージしますか？　また, どのような特徴をもっていると思いますか？

これ, すでにヒント出ちゃってるので簡単ですよね.

--------
Advent Calendarもあと少し.

Day 23 へつづく

previously on Mac De Oracle
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 1 / TABLE FULL SCAN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 2 / INDEX UNIQUE SCAN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 3 / INDEX RANGE SCAN, Index Only Scan
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 4 / INDEX RANGE SCAN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 5 / INDEX RANGE SCAN, INLIST ITERATOR
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 6 / INDEX FAST SCAN, Index Only Scan
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 7 / INDEX FULL SCAN、Index Only Scan
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 8 / INDEX SKIP SCAN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 9 / TABLE ACCESS INMEMORY FULL
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 10 / NESTED LOOP JOIN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 11 / MERGE JOIN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 12 / HASH JOIN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 13 / HASH JOIN OUTER
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 14 / HASH JOIN FULL OUTER
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 15 / PX, TABLE ACCESS FULL
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 16 / CONCATENATION
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 17 / SORT UNIQUE, UNION-ALL = UNION
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 18 / UNION-ALL
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 19 / INTERSECTION
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 20 / MINUS
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 21 / WINDOW NOSORT STOPKEY

投稿日時 2019年12月22日 (日) 00時00分 Oracle, チューニング, SQL, イベント, Advent Calendar | 固定リンク | 0 | コメント (0)

2019年12月21日 (土)

実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 Day 21

実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 Day 21のエントリーです.
Day 20 のつづきから.

UNION, UNION ALLやINTERSECTIONににていますが, Operationがちがいますよね. UNION/INTERSCTIONときたら残るは..... MINUS そのまんまですw
Predicate InformationやOperetion部分から, UNIONやUNION ALLで使われた述語と同じなであることが確認できる2つのSELECT文が見えてきます. あとはそれらの結果セットをどうするかという違いですよね.

以下のようなSQL文をイメージできたら正解だと思います.

select * from tab311 where unique_id between 1 and 100 minus select * from tab311 where sub_item_code in ('0000000100','0100000000');

では、本題.

この実行計画という名のレントゲン写真から, どのようなSQL文をイメージしますか？　また, どのような特徴をもっていると思いますか？

おお, これは! 比較的あたらしい部類ですね. Oracle Databaseの実行計画では.

--------
ながいーーーーーい、ほぼ一ヶ月を抜けた....ほっとして熱でないといいけどw

Day 22 へつづく

previously on Mac De Oracle
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 1 / TABLE FULL SCAN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 2 / INDEX UNIQUE SCAN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 3 / INDEX RANGE SCAN, Index Only Scan
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 4 / INDEX RANGE SCAN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 5 / INDEX RANGE SCAN, INLIST ITERATOR
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 6 / INDEX FAST SCAN, Index Only Scan
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 7 / INDEX FULL SCAN、Index Only Scan
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 8 / INDEX SKIP SCAN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 9 / TABLE ACCESS INMEMORY FULL
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 10 / NESTED LOOP JOIN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 11 / MERGE JOIN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 12 / HASH JOIN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 13 / HASH JOIN OUTER
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 14 / HASH JOIN FULL OUTER
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 15 / PX, TABLE ACCESS FULL
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 16 / CONCATENATION
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 17 / SORT UNIQUE, UNION-ALL = UNION
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 18 / UNION-ALL
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 19 / INTERSECTION
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 20 / MINUS

投稿日時 2019年12月21日 (土) 00時00分 Oracle, チューニング, SQL, イベント, Advent Calendar | 固定リンク | 0 | コメント (0)

2019年12月20日 (金)

実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 Day 20

実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 Day 20のエントリーです.

Day 19 のつづきから.

UNIONやUNION ALLににていますが, Operationがちがいますよね. しかもわかりやすいです. INTERSECTION そのまんまです.

Predicate InformationやOperetion部分から, UNIONやUNION ALLで使った述語と同じで, 2つのSELECT文が見えてきます. あとはそれらの結果セットをどうするかという違いです.

以下のようなSQL文をイメージできたら正解だと思います.

select * from tab311 where unique_id between 1 and 100 intersect select * from tab311 where sub_item_code in ('0000000100','0100000000');

では、本題.

この実行計画という名のレントゲン写真から, どのようなSQL文をイメージしますか？　また, どのような特徴をもっていると思いますか？

MINUS...そこに気づけば簡単ですよね.

--------
お通しがカニっていいよなー（謎

Day 21 へつづく

previously on Mac De Oracle
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 1 / TABLE FULL SCAN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 2 / INDEX UNIQUE SCAN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 3 / INDEX RANGE SCAN, Index Only Scan
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 4 / INDEX RANGE SCAN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 5 / INDEX RANGE SCAN, INLIST ITERATOR
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 6 / INDEX FAST SCAN, Index Only Scan
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 7 / INDEX FULL SCAN、Index Only Scan
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 8 / INDEX SKIP SCAN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 9 / TABLE ACCESS INMEMORY FULL
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 10 / NESTED LOOP JOIN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 11 / MERGE JOIN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 12 / HASH JOIN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 13 / HASH JOIN OUTER
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 14 / HASH JOIN FULL OUTER
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 15 / PX, TABLE ACCESS FULL
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 16 / CONCATENATION
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 17 / SORT UNIQUE, UNION-ALL = UNION
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 18 / UNION-ALL
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 19 / INTERSECTION

投稿日時 2019年12月20日 (金) 00時00分 Oracle, チューニング, SQL, イベント, Advent Calendar | 固定リンク | 0 | コメント (0)

2019年12月19日 (木)

実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 Day 19

実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 Day 19のエントリーです.

Day 18 のつづきから.

Day 17のレントゲン写真とDay 18のレントゲン写真を比較するとすぐに気づけるとおもいます.
Day 17 - UNION

Day 18 - ? Similar to UNION

SORT UNIQUEというOperationがないだけです. :) となると答えは簡単.

Id = 1 がUNION-ALLというOperationから, UNION ALL という構文なのは明らかです.

Id = 3,2 そして, 　Predicate Informationの　”3 - access("UNIQUE_ID">=1 AND "UNIQUE_ID"<=100)” から一つ目のSELECT文は, 索引範囲検索で表をアクセス.

Id = 6.5.4 そして, 　Predicate Informationの "6 - access("SUB_ITEM_CODE"='0000000100' OR "SUB_ITEM_CODE"='0100000000')" から二つ目のSELECT文は, INLIST ITERATORで索引範囲検索で表を繰り返しアクセス.

以下のようなSQL文をイメージできたら正解だと思います.

select * from tab311 where unique_id between 1 and 100 union all select * from tab311 where sub_item_code in ('0000000100','0100000000');

UNION ALLも複数のSELECT文を実行するより1つのSQL文にしたほうが効率が良いのであれば、手術という名の書き換えしかないのは, UINONの場合と同じです. Index Only Scanが使える場合はUNION ALLのままにしておくなんてケースはあると思いますが, そもそも索引の追加はしてほしくないという, 大人の事情があるったり, なかったり.

大人って大変なんです. むーりーなものはむーりーと言われることはあって, それでも, こちらは, Index Only Scan or Die? って突きつけないといけないこともあるのでw Vector Transformな案件はそんなアトモスフィアだった, 遠ーい目w

そして, 「私, 失敗しないので！」　的なw 言葉を残しつつサクッと帰宅しちゃいましょ！ (またかよw
フリーランスにはメロンおじさんが必要だなw

では、本題.

この実行計画という名のレントゲン写真から, どのようなSQL文をイメージしますか？　また, どのような特徴をもっていると思いますか？

INTERSECTION...そこに気づけば簡単ですよね.

--------

Day 20 へつづく

previously on Mac De Oracle
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 1 / TABLE FULL SCAN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 2 / INDEX UNIQUE SCAN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 3 / INDEX RANGE SCAN, Index Only Scan
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 4 / INDEX RANGE SCAN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 5 / INDEX RANGE SCAN, INLIST ITERATOR
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 6 / INDEX FAST SCAN, Index Only Scan
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 7 / INDEX FULL SCAN、Index Only Scan
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 8 / INDEX SKIP SCAN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 9 / TABLE ACCESS INMEMORY FULL
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 10 / NESTED LOOP JOIN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 11 / MERGE JOIN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 12 / HASH JOIN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 13 / HASH JOIN OUTER
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 14 / HASH JOIN FULL OUTER
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 15 / PX, TABLE ACCESS FULL
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 16 / CONCATENATION
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 17 / SORT UNIQUE, UNION-ALL = UNION
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 18 / UNION-ALL

投稿日時 2019年12月19日 (木) 00時00分 Oracle, チューニング, SQL, イベント, Advent Calendar | 固定リンク | 0 | コメント (0)

2019年12月18日 (水)

実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 Day 18

実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 Day 18のエントリーです.

Day 17 のつづきから.

Day 17のレントゲン写真を読み解いてみましょう.

Id = 2 の　UNION-ALLというOperationから, UNION ALL という構文であることが読み取れます.

Id = 1 から UNION ALL であるが, SORT UNIQUE されている. つまり, UNION ALL した後に、各SELECT文から返された行から重複行を排除していることが読み取, 実際には, UNION ALL ではなく UNION であること希読み取れればあとは簡単.

Id = 4,3 そして, 　Predicate Informationの　”4 - access("UNIQUE_ID">=1 AND "UNIQUE_ID"<=100)” から一つ目のSELECT文は, 索引範囲検索で表をアクセス.

Id = 7, 6, 5 そして, 　Predicate Informationの "7 - access("SUB_ITEM_CODE"='0000000100' OR "SUB_ITEM_CODE"='0100000000')" から二つ目のSELECT文は, INLIST ITERATORで索引範囲検索で表を繰り返しアクセス.

以下のようなSQL文をイメージできたら正解だと思います.

select * from tab311 where unique_id between 1 and 100 union select * from tab311 where sub_item_code in ('0000000100','0100000000');

INDEX RANGE SCANで表をアクセスしているので、この例では無理ですが、可能ならCovering IndexでIndex Only Scanの持ち込む治療も行える可能性はあります. それはあくまで治療の必要のある大人の事情がある場合ですがw

なお、Day 16 の　CONCATENATION という, 最適化と同じ意味ではあるのですが、UNION のOperationと区別されている点に注目してください.

重要. 治療が必要な場合, NO＿EXPANDヒントという注射で治療するか, SQL書き換えという手術が必要なのか判断できるポイントになるからです!!!

重要. 治療が必要な場合, NO＿EXPANDヒントという注射で治療するか, SQL書き換えという手術が必要なのか判断できるポイントになるからです!!!

たいせつなので二度書きましたw (ひさびさw

UNION の場合, オプティマイザは, Day 16のようなSQL文へ内部的に書き換える最適化は行いません. (将来はどうなるかしりませんが) なので, UNION で索引使ってくれるかと思ってたが、使ってくれない. 無理に使わせても全表走査のほうが効率がよいのなら, Day 16のような構文に書き換える手術をおこない, 2回の全表走査から1回の全表走査で済むようにしちゃいましょ.

そして, 「私, 失敗しないので！」　的なw 言葉を残しつつサクッと帰宅しちゃいましょ！

では、本題.

この実行計画という名のレントゲン写真から, どのようなSQL文をイメージしますか？　また, どのような特徴をもっていると思いますか？

UNON系構文ぽい...簡単です. ちがいに気づけば.

--------
やらないことを決めないと時間がないw

そういえば, Doctor X で, やらないことを事前に伝えてるのに気づく.

Day 18 へつづく
そして、JPOUG Advent Calendar 2019も Day 18 へつづく

previously on Mac De Oracle
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 1 / TABLE FULL SCAN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 2 / INDEX UNIQUE SCAN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 3 / INDEX RANGE SCAN, Index Only Scan
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 4 / INDEX RANGE SCAN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 5 / INDEX RANGE SCAN, INLIST ITERATOR
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 6 / INDEX FAST SCAN, Index Only Scan
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 7 / INDEX FULL SCAN、Index Only Scan
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 8 / INDEX SKIP SCAN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 9 / TABLE ACCESS INMEMORY FULL
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 10 / NESTED LOOP JOIN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 11 / MERGE JOIN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 12 / HASH JOIN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 13 / HASH JOIN OUTER
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 14 / HASH JOIN FULL OUTER
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 15 / PX, TABLE ACCESS FULL
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 16 / CONCATENATION
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 17 / UNION

投稿日時 2019年12月18日 (水) 00時00分 Oracle, チューニング, SQL, イベント, Advent Calendar | 固定リンク | 0 | コメント (0)

2019年12月17日 (火)

実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 Day 17

実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 Day 17のエントリーです.
また、
JPOUG Advent Calendar 2019 Day 17のエントリーとのクロスポストとなっています.

Day 16 のつづきから.
そして、JPOUG Advent Calendar 2019 Day 16のエントリーは, 「 Oracle Advanced Queuing（ＡＱ）使ってみませんか？ / kjmtgm さん」でした

昨日の実行計画の特徴は, CONCATENATIONこのオペレーションを見たら, あれだ！　と気が付けるように日々精進しておくと, 一目置かれるような存在に, なれるとか, なれないとかw （保証はしませんw

このオペレーションは、SQLトランスフォームの一つです. 表を検索する際に、同一表の異なる列が OR 条件で利用されており、単一索引利用するより、OR条件のそれぞれの列で個別の索引を利用させることで複数の索引を同時に利用させるようにUNIONを利用し個別のSELECT文に分割統合します. （内部でどう書き換えているかは後半でお見せします）

実際のSQL文は、以下のようなSQL文をイメージできたら正解だと思います. USE_CONCATヒントで強制することもありますが, もちろんオプティマイザの判断で行うこともあります. オプティマイザの判断が誤っている場合には, NO_EXPANDヒントというヒントで抑止することも可能です.

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

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

SQLヒントや, オプティマイザに任せず, 書き換えるという昔のスタイルだと, 上記SQL文を以下のように書き換えると同じ意味になります ;) オプティマイザは偉い. まちがいもするけど. それは人も同じw 失敗を肥やしにして訂正するのも, 最近のオプティマイザの賢いところ. ですが, それでもだめなら, 人の手でw

このような書き換えが行われる, もしくは有利な場面は、ORで利用されている列がそれぞれ個別の索引を持ちそれぞれの条件で索引アクセスのコストが低くなる一意検索だったり, 比較的狭い範囲の索引範囲検索が有効な場合です. 統計情報と実態の乖離が大きい場合にはオプティマイザが誤って選択してしまうケースもあります. このままで行くか, 治療するかの見極めが必要になることも意外に多いタイプですね.
以下のような書き換えをした場合, 最悪のケースは, どちらのSELECT文でも全表走査してしまうケースで, どちらも索引を利用しないのが正しいのであれば, 2つのSELECT文で全表走査を2回行わせるより, 書き換える前のSQL文で1度だけ全表走査させたほうがはるかに効率できてきすw (セグメントサイズにもよりますが)

ポイントは, 2つのSQL文にしてUNIONしたほうが無駄ないのかどうかを考える！　ということです.

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

あ、しまった....あ...いいや、構文おなじだけだしw

では、本題.

この実行計画という名のレントゲン写真から, どのようなSQL文をイメージしますか？　また, どのような特徴をもっていると思いますか？

少しだけネタバレしましたが今回も特徴のあるわかりやすいOperationがでてますよね. 見た目は違いますが同じですが, ヒントw

--------
外資系って, 31まで仕事なのな, というのに気づいて 2 年目ですw 私個人の営業は 30までですがw

Day 18 へつづく
そして、JPOUG Advent Calendar 2019も Day 18 へつづく

previously on Mac De Oracle
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 1 / TABLE FULL SCAN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 2 / INDEX UNIQUE SCAN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 3 / INDEX RANGE SCAN, Index Only Scan
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 4 / INDEX RANGE SCAN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 5 / INDEX RANGE SCAN, INLIST ITERATOR
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 6 / INDEX FAST SCAN, Index Only Scan
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 7 / INDEX FULL SCAN、Index Only Scan
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 8 / INDEX SKIP SCAN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 9 / TABLE ACCESS INMEMORY FULL
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 10 / NESTED LOOP JOIN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 11 / MERGE JOIN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 12 / HASH JOIN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 13 / HASH JOIN OUTER
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 14 / HASH JOIN FULL OUTER
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 15 / PX, TABLE ACCESS FULL
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 16 / CONCATENATION

投稿日時 2019年12月17日 (火) 00時00分 Oracle, チューニング, SQL, イベント, JPOUG, Advent Calendar | 固定リンク | 0 | コメント (0)

2019年12月16日 (月)

実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 Day 16

実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 Day 16のエントリーです.

Day 15 のつづきから.

Id = 4のOperationはTABLE ACCESS FULLですが, Id = 1から Id = 3に特徴があります.
PX ときたら! そう, Parallel Executionですよね.

PX BLOCK ITERATORで非パーティションをパラレルにアクセスしていいます.

Note部分に, Degree of Parallelism is 4 because of hint なんてあるので、HINTを使ってパラレル化していることも読み取れます. HINTなしでもTABLE等に並列度が設定されている場合には設定されている並列度でパラレル化されます. 意図せずパラレル実行されている場合には、NO_PARALLELヒントで抑止したり, そもそも表や索引に並列度設定するつもりじゃなかったという場合には、表や索引の並列度をNOPARALLELにしましょう. 昔、そんな事故がありましたw

この場合, HINTが利用されているのはあきらかなので, 以下のようなSQL文をイメージできたら正解でしょうね.

select /*+ parallel(4) */ * from tab3;

ちなみに, このテーブルの並列度は, 以下の通りに設定されておりました.

SCOTT> select table_name,degree from user_tables where table_name='TAB3'; TABLE_NAME DEGREE ------------------------------ --------------- TAB3 1

では、本題.

この実行計画という名のレントゲン写真から, どのようなSQL文をイメージしますか？　また, どのような特徴をもっていると思いますか？

CONCATENATIONなのはわかると思いますが, わかりやすいOperationがでてますよね. それが, ポイント.

--------
3ヶ月がはえーよw

Day 17 へつづく

previously on Mac De Oracle
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 1 / TABLE FULL SCAN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 2 / INDEX UNIQUE SCAN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 3 / INDEX RANGE SCAN, Index Only Scan
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 4 / INDEX RANGE SCAN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 5 / INDEX RANGE SCAN, INLIST ITERATOR
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 6 / INDEX FAST SCAN, Index Only Scan
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 7 / INDEX FULL SCAN、Index Only Scan
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 8 / INDEX SKIP SCAN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 9 / TABLE ACCESS INMEMORY FULL
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 10 / NESTED LOOP JOIN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 11 / MERGE JOIN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 12 / HASH JOIN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 13 / HASH JOIN OUTER
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 14 / HASH JOIN FULL OUTER
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 15 / PX, TABLE ACCESS FULL

投稿日時 2019年12月16日 (月) 00時00分 Oracle, チューニング, SQL, イベント, Advent Calendar | 固定リンク | 0 | コメント (0)

2019年12月15日 (日)

実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 Day 15

実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 Day 15のエントリーです.

Day 14 のつづきから.

この実行計画はわかりやすいですよね, 読んだまんまです. HASH JOIN FULL OUTER

もうそのまま, SQLに書いちゃえばいいですよね. 結合条件は, Predicate Information に　Id=2 の部分は 2 - access("TAB3"."UNIQUE_ID"="TAB311"."UNIQUE_ID") としてリストされています.

以下のようなSQL文をイメージできたら正解でしょうね.

select * from tab3 full outer join tab311 on tab3.unique_id = tab311.unique_id;

では、本題.

この実行計画という名のレントゲン写真から, どのようなSQL文をイメージしますか？　また, どのような特徴をもっていると思いますか？

TABLE FULL SCANなのはわかると思いますが, 特殊なOperationがでてますよね. それが, ポイント.

--------
一日中缶詰で, チューナーっぽくない物書き、俺一番萌えないやつじゃん, それw

Day 16 へつづく

previously on Mac De Oracle
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 1 / TABLE FULL SCAN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 2 / INDEX UNIQUE SCAN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 3 / INDEX RANGE SCAN, Index Only Scan
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 4 / INDEX RANGE SCAN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 5 / INDEX RANGE SCAN, INLIST ITERATOR
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 6 / INDEX FAST SCAN, Index Only Scan
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 7 / INDEX FULL SCAN、Index Only Scan
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 8 / INDEX SKIP SCAN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 9 / TABLE ACCESS INMEMORY FULL
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 10 / NESTED LOOP JOIN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 11 / MERGE JOIN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 12 / HASH JOIN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 13 / HASH JOIN OUTER
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 14 / HASH JOIN FULL OUTER

投稿日時 2019年12月15日 (日) 00時00分 Oracle, チューニング, SQL, イベント, Advent Calendar | 固定リンク | 0 | コメント (0)

2019年12月14日 (土)

実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 Day 14

実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 Day 14のエントリーです.

Day 13 のつづきから.

眠気と戦いながらw 書いているので, タイポ多目とか. ケンブリッジ関数通してないのに文字の順序入れ替わっているとかありましたら, ここまでご連絡くださいませ.（どこだよーw

というジャブはこれぐらいにしておいて,

この実行計画も　adaptive plan となっているので, 実際には NESTED LOOPS で実行されている可能性のある HASH JOIN ですよね？　

HASH JOINのナカーマではありますが, HASH JOIN OUTER という部分で気づくかもしれませんが, OUTER という部分で外部結合であることがわかります.
また、Predicate Information には結合条件にOracleの方言に書き換えられた結合条件に気づけるとおもいましす. Id=1に対応するPredicate Informationの1 - access("TAB3"."UNIQUE_ID"="TAB311"."UNIQUE_ID"(+))がそれですね.

Predicate Informationも含め, 以下のようなSQL文をイメージできたら正解だとおもいます.

select * from tab3 left join tab311 on tab3.unique_id = tab311.unique_id where tab3.unique_id between 1 and 100;

では, 本題.

この実行計画という名のレントゲン写真から, どのようなSQL文をイメージしますか？　また, どのような特徴をもっていると思いますか？

今日は結合は結合でもあまり使わないですね. 業務系で使いどころがあまりなく....w....何年か前にExadataへの移行案件で, 出会った結構痺れるチューニング案件を思い出す, この結合.

--------
今日は寝落ちしてないけど、なんでこんなに忙しいんだw

Day 15 へつづく

previously on Mac De Oracle
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 1 / TABLE FULL SCAN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 2 / INDEX UNIQUE SCAN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 3 / INDEX RANGE SCAN, Index Only Scan
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 4 / INDEX RANGE SCAN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 5 / INDEX RANGE SCAN, INLIST ITERATOR
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 6 / INDEX FAST SCAN, Index Only Scan
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 7 / INDEX FULL SCAN、Index Only Scan
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 8 / INDEX SKIP SCAN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 9 / TABLE ACCESS INMEMORY FULL
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 10 / NESTED LOOP JOIN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 11 / MERGE JOIN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 12 / HASH JOIN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 13 / HASH JOIN OUTER

投稿日時 2019年12月14日 (土) 00時00分 Oracle, チューニング, SQL, イベント, Advent Calendar | 固定リンク | 0 | コメント (0)

2019年12月13日 (金)

実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 Day 13

実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 Day 13のエントリーです.

Day 12 のつづきから.

さてさて、Advent Calendarも半分ぐらい. あともうひと頑張りw

HASH JOINとは出ていても、TABLE ACCESS FULL SCANとはかぎらず、INDEX RANGE SCANとTABLE ACCESS BY INDEX ROWID BATCHEDとの組み合わせも意外に見かけます. このようなケースでは, 全表走査や高速索引走査(INDEX FAST FULL SCAN）でIndex Only Scan狙いの治療も考えられますが, それはおいといて.

ハッシュ結合で最初に見るべきポイントは、結合順. NESTED LOOPSも同じですが、結果セットの小さい方がビルド表（外部表, NESTED LOOPSの駆動表）になっているかを確認しておきましょう. もし違うのであれば、統計情報を最新化（実態との乖離が大きければ）、そうでなければヒント等で実行計画を管理する方向にするか. オプティマイザがなんとなく理解してくれるまでまつ.
ということになります.

また, Note部分に　- this is an adaptive plan が現れています. これは HASH JOIN かもしれないし、 NESTED LOOPSかもしれない　実行計画であることをしめしています. 実際にヒットする行数によってどちらになるかがきまります. この例ではSQL*Plusのautotraceを利用しているため, 静的な統計情報を基にした, 見積もりなので実際にはどちらのプランで動作したのかはわかりません.
動作時の実行計画を確認するには, Actural Planを確認する必要があります.

Enterprise Editionでオプションが利用できる状況であれば、SQLモニター, そうでなければ、DBMS_XPLAN.DISPLAY_CURSOR()を利用してActual Planを確認できます.

dbms_sqltune.report_sql_monitorを利用する. (typeパラメタータを 'text' にすることでhtmlではなく、textでレポートを出力することもできます)
「高度なSQL実行計画の取得」を実践する (2/3)

/*+ gather_plan_statistics */ やalter session set statistics_level=all;とDBMS_XPLAN.DISPLAY_CURSOR()を利用したActual Planの確認
DBMS_XPLAN.DISPLAY_CURSORの使い方とちょっとした落とし穴

余談がおおくなってしまいましたが, Predicate Informationも含めてイメージすれば, 以下のようなSQL文をイメージできたら正解だとおもいます.

select * from tab3 inner join tab311 on tab3.unique_id = tab311.unique_id where tab3.unique_id between 1 and 100;

では、本題.

この実行計画という名のレントゲン写真から, どのようなSQL文をイメージしますか？　また, どのような特徴をもっていると思いますか？

HASH JOIN だけどちょいとちがう.
--------
二日連続で寝落ちしてたw

Day 14 へつづく

previously on Mac De Oracle
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 1 / TABLE FULL SCAN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 2 / INDEX UNIQUE SCAN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 3 / INDEX RANGE SCAN, Index Only Scan
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 4 / INDEX RANGE SCAN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 5 / INDEX RANGE SCAN, INLIST ITERATOR
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 6 / INDEX FAST SCAN, Index Only Scan
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 7 / INDEX FULL SCAN、Index Only Scan
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 8 / INDEX SKIP SCAN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 9 / TABLE ACCESS INMEMORY FULL
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 10 / NESTED LOOP JOIN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 11 / MERGE JOIN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 12 / HASH JOIN

投稿日時 2019年12月13日 (金) 00時00分 Oracle, チューニング, SQL, イベント, Advent Calendar | 固定リンク | 0 | コメント (0)

2019年12月12日 (木)

実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 Day 12

実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 Day 12のエントリーです.

Day 11 のつづきから.

MERGE JOINは最近のOracle Databaseではあまり見かけなくなりましたが, 結合対象データが多い場合かつ, 特定の結合条件ではかならず選択されますよね？

等価結合(=)以外の結合条件で, データ量が多い場合には MERGE JOIN が選ばれます.

Predicate Informationの情報などから次のようなSQL文がメージできれば正解でしょう.

select * from tab3 inner join tab311 on tab3.unique_id > tab311.unique_id where tab3.unique_id between 1 and 100;

結合条件がMERGE JOINは, ソート処理を伴うこともありソート処理をバイパスできるような索引がない場合はかなり重くなる傾向があります.
今日の本題も予想できちゃいそうですが, ソートをバイパスできそうであれば,MERGE JOINを利用してチューニングしちゃうこともなくはないです. (巨大なデータのソート処理はやはり重いので避けたいところ)

そういえば, HASH JOINもMERGE JOINでも, Temp落ちが激しくて遅かったころは, あえて, NESTED LOOPSに倒すなんてこともありました.... Temp落ちしても早くなってきたので, そこまでするかってのは微妙ではありますが, 最近は.
いずれにしても, 症状と手術の副作用も考えてどうするかってところにはなりますが, 術後のリスクは相手にもしっかり伝えておくことは重要です.

この例の場合も, 大人の事情とSQLの列の利用状況などにもよりもよりますが, Index Only Scanを組み合わせたチューニングすることはあります. アクセスするブロック数がどれだけ減らせるかの検証は必要ですが.

また, 結合条件がない（意図的に行なっている場合も, 結合条件が漏れている場合もあり）場合もMERGE JOINにはなりますが, その場合は, ”MERGE JOIN (CARTESIAN)" というOperationに変わるので区別しやすいとおもいます.

では、本題.

この実行計画という名のレントゲン写真から, どのようなSQL文をイメージしますか？　また, どのような特徴をもっていると思いますか？

--------
晩御飯たべて、少し横になったら爆睡してて、さっき目覚めたのはナイショw

Day 13 へつづく

previously on Mac De Oracle
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 1 / TABLE FULL SCAN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 2 / INDEX UNIQUE SCAN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 3 / INDEX RANGE SCAN, Index Only Scan
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 4 / INDEX RANGE SCAN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 5 / INDEX RANGE SCAN, INLIST ITERATOR
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 6 / INDEX FAST SCAN, Index Only Scan
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 7 / INDEX FULL SCAN、Index Only Scan
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 8 / INDEX SKIP SCAN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 9 / TABLE ACCESS INMEMORY FULL
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 10 / NESTED LOOP JOIN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 11 / MERGE JOIN

投稿日時 2019年12月12日 (木) 00時00分 Oracle, チューニング, SQL, イベント, Advent Calendar | 固定リンク | 0 | コメント (0)

2019年12月11日 (水)

実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 Day 11

実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 Day 11のエントリーです.

Day 10 のつづきから.

Day 10 でついに結合の登場. 駆動表となるTAB3のTAB3_PK索引をINDEX UNIQUE SCAN(一意検索)してROWIDを取得(Id=3) 、Id=2でId=3で取得したROWIDを元にTAB3をTABLE ACCESS BY INDEX ROWIDでアクセス後、id=5でPredicate Informationにリストされている結合条件TAB311.UNIQUE_IDでTAB311_PK索引をINDEX RANGE SCAN して複数件のROWIDを取得、最後に、id=4で内部表となっているTAB311から、TABLE ACCESS BY INDEX ROWID BATCHEDで複数のROWIDに対応する複数の行を取得という実行計画になっています.
Nested Loop Joinの基本系といってもよい実行計画になっています。 Id=3,2でアクセスされている表が駆動表（外部表）で、この表は一般的に、内部表（Id=5,4でアクセスされている表）です.
一般的に、駆動表の結果セットは内部表の結果セットより少ないことが、Nested Loop Joinでの性能上重要な意味があります. 統計情報が不正確だったりすると本来内部表であるべき表が駆動表となって思わぬ処理遅延を引き起こします. この実行計画では索引スキャンが妥当か、妥当であること、駆動表が妥当であることなごが性能検証でのポイントになります.

以下のようなSQL文をイメージできたら大体あっていると思います.

select * from tab3 inner join tab311 on tab3.unique_id = tab311.unique_id where tab3.unique_id = 2;

また、大人の事情とSQLの列の利用状況などにもよりもよりますが、Index Only Scanを組み合わせて、Nested Loop Joinをチューニングすることもあります.

では、本題.

この実行計画という名のレントゲン写真から、どのようなSQL文をイメージしますか？　また、どのような特徴をもっていると思いますか？

比較的少量の等価結合では Nested Loop Joinが無難ですが、データ量が多い場合には、これでした. 古いバージョンのOracle Databaseで大量データの結合といえば、この結合という時代もありました. 最近はあまり見かけないのですが、特定の状況ではこれしか使えないという状況もあります. :)

--------
昨日は、ポンギ方面へ久々に行った. むかーし、むかーし、あの辺で仕事してたなぁ〜. 遠い目. そして、10年ぐらい前とは違うビル群...

Day 12 へつづく

previously on Mac De Oracle
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 1 / TABLE FULL SCAN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 2 / INDEX UNIQUE SCAN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 3 / INDEX RANGE SCAN, Index Only Scan
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 4 / INDEX RANGE SCAN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 5 / INDEX RANGE SCAN, INLIST ITERATOR
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 6 / INDEX FAST SCAN, Index Only Scan
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 7 / INDEX FULL SCAN、Index Only Scan
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 8 / INDEX SKIP SCAN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 9 / TABLE ACCESS INMEMORY FULL
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 10 / NESTED LOOP JOIN

投稿日時 2019年12月11日 (水) 00時00分 Oracle, チューニング, SQL, イベント, Advent Calendar | 固定リンク | 0 | コメント (0)

2019年12月10日 (火)

実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 Day 10

実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 Day 10のエントリーです.

Day 9 のつづきから.

TABLE ACCESS INMEMORY FULL となっているので、INMEMORYのTABLE ACCESS FULL という状況なのはすぐに読み取れるのではないでしょうか？
また、Predicate Information はリストされていないので、WHERE句がないという点にもきづくと思います. そう Day 1の1)のSQL文と同じ.
INMEMORYはEnterprise Editionの機能（SEに降りてくる機能もありますが、今のところ)なので、そのあたりも想像できます. （SQL文自体には関係ないわけで）

select * from tab3;

INMEMORYというoperationをみたら、in-memoryが有効化されていると判断すればよいとおもいます. (inmemory_sizeに100MB以上の値がセットされているはずです)
第53回　Oracle Database In-Memoryについて / 津島博士のパフォーマンス講座
 in-memory関連の謎パラメータ 18c / Mac De Oracle

TABLE ACCESS FULLで物理読み込みがきついのであれば、こんな手も使えなくもないということで....

では、Day 10の本題

この実行計画という名のレントゲン写真から、どのようなSQL文をイメージしますか？　また、どのような特徴をもっていると思いますか？

よく見かける実行計画なので、簡単だと思います. :)

昨日は、ポンギ方面へ久々に行った. むかーし、むかーし、あの辺で仕事してたなぁ〜. 遠い目. そして、10年ぐらい前とも違うビル群....

Day 11 へつづく

previously on Mac De Oracle
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 1 / TABLE FULL SCAN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 2 / INDEX UNIQUE SCAN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 3 / INDEX RANGE SCAN, Index Only Scan
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 4 / INDEX RANGE SCAN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 5 / INDEX RANGE SCAN, INLIST ITERATOR
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 6 / INDEX FAST SCAN, Index Only Scan
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 7 / INDEX FULL SCAN、Index Only Scan
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 8 / INDEX SKIP SCAN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 9 / TABLE ACCESS INMEMORY FULL

投稿日時 2019年12月10日 (火) 00時00分 Oracle, SQL, ダウンロード, イベント, Advent Calendar | 固定リンク | 0 | コメント (0)

2019年12月 9日 (月)

実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 Day 9

実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 Day 9のエントリーです.

Day 8 のつづきから.

INDEX SKIP SCANとでていて、Predicate Information に　"2 - access("SUB_ITEM_CODE"='0000000001') filter("SUB_ITEM_CODE"='0000000001')" とでている.
そして、TABLE ACCESS BY INDEX ROWID BATCHED あるとなれば、実行計画というレントゲンからSQL文をイメージできるのではないでしょうか？

ヒントで強制されていたり、オプティマイザが判断したかのいずれかのパターンなので以下のようなSQLが浮かぶのではないでしょうか？

select /*+ index_skip(tab31 tab31_pk) */ * from tab31 where sub_item_code='0000000001';
select * from tab31 where sub_item_code='0000000001';

ところで、INDEX SKIP SCAN はどのような状況かというと、　
TAB31_PK は複合索引であることが前提になります。複数の列からなるこの索引の列のうち、第2キー以降にPredicate Informationにリストされている sub_item_code列があることになります. たとえば、2列の複合索引があるとして、この実行計画では第2キーのsub_item_code列だけで検索されている. WHERE句で検索条件に利用されているのは　sub_item_code列だけということになります.

INDEX SKIP SCANはINDEX RANGE SCANになるような索引を作成した方が効率がよいことが多いですが、大人の事情縛りのチューニングなどでは、索引の最適化までは行えず、SKIP SCANの効果ができるようであれば、それ以上治療しないという選択もあります.
ただ、可能ならINDEX RANGE SCANになるような物理的な手術を行ったほうがよいケースのほうが圧倒的に多いです. SKIP SCANでもいよいよダメだ、という状況になってから慌てるぐらいなら、バッサリやっちゃったほうがスッキリすると思うんですね. そういうところに限って、夜中や休日に緊急オペで呼び出されるなんてことも意外におおかったです.
最終的には判断患者さんの判断にはなりますが、リスクは伝えておいた方がよいと思います.

さて、本題、Day 9の実行計画というレントゲン写真はこれ！

これは！
とにかく、実行計画をしっかり診てください.

この実行計画という名のレントゲン写真から、どのようなSQL文をイメージしますか？　また、どのような特徴をもっていると思いますか？

これは Enterprise Editionの機能ですよね...(ヒント:)

Day 10 へつづく

previously on Mac De Oracle
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 1 / TABLE FULL SCAN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 2 / INDEX UNIQUE SCAN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 3 / INDEX RANGE SCAN, Index Only Scan
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 4 / INDEX RANGE SCAN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 5 / INDEX RANGE SCAN, INLIST ITERATOR
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 6 / INDEX FAST SCAN, Index Only Scan
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 7 / INDEX FULL SCAN、Index Only Scan
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 8 / INDEX SKIP SCAN

投稿日時 2019年12月 9日 (月) 00時00分 Oracle, チューニング, SQL, イベント, Advent Calendar | 固定リンク | 0 | コメント (0)

2019年12月 8日 (日)

実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 Day 8

実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 Day 8のエントリーです.

Day 7 のつづきから.

Predicate Informationには何もない、かつ、TAB3_PKという索引を参照しているだけとなれば、Index Only Scanですよね.　unique_id列でTAB3_PKという索引があったとして、Day 7のように、INDEX FAST FULL SCANでもない.
索引のキー順に読まむ必要のあるような句があるということ. 索引のキー順に読ままなければならないのは、ORDER BY ですよね？

unique_idという列が索引に含まれていたとして、それ以外の列は参照されていない. そして、ORDER BY unique_id で昇順ソート要求があるなれば、以下のようなSQL文をイメージできていたら正解だと思います.
なお、降順ソートの場合もありますが、その場合は INDEX FULL SCAN DESCENDINGとなります.

select unique_id from tab3 order by unique_id;

さて、本題、Day 8の実行計画というレントゲン写真はこれ！

ほ、ほう、これは、めずらしい、INDEX SKIP SCAN

この実行計画という名のレントゲン写真から、どのようなSQL文をイメージしますか？　また、どのような特徴をもっていると思いますか？

あえて、SKIP SCANで治療したのはかなり少ないのですが、実際に効くケースもあるので、治療の選択肢としてはなくなないですね..索引を変更したりするリスクを避けたいという、大人の事情がある場合、ヒントで SKIP SCANをすることで、試験範囲を限定できたりすることもあります.
ポケットはたくさんあったほうがなにかと便利　:)

Day 9 へつづく

previously on Mac De Oracle
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 1 / TABLE FULL SCAN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 2 / INDEX UNIQUE SCAN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 3 / INDEX RANGE SCAN, Index Only Scan
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 4 / INDEX RANGE SCAN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 5 / INDEX RANGE SCAN, INLIST ITERATOR
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 6 / INDEX FAST SCAN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 7 / INDEX FULL SCAN、Index Only Scan

投稿日時 2019年12月 8日 (日) 00時00分 Oracle, チューニング, SQL, イベント, Advent Calendar | 固定リンク | 0 | コメント (0)

2019年12月 7日 (土)

実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 Day 7

実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 Day 7のエントリーです.

Day 6 のつづきから.

どのようなSQL文かイメージできたでしょうか？　その特徴は？

TABLE ACCESS BY INDEX ROWID BATCHEDも無いし、Predicate Information もない. ということはWHERE句はないと読み取れます.

Index Only Scanなのは間違いないですが、INDEX FAST FULL SCAN

このOperationは、高速全索引スキャンは索引順に読む必要のない場合に考慮される実行計画です。例えば、索引の順序づけにしたがって読み出したい場合、order by unique_idのように索引順に読み出したい場合には選択されません.

と、ここまでくれば、　WHERE句なし、ORDER BY句なしで、かつIndex Only Scanなので、SELECTリスト等、参照されている列すべてが索引にふうまれている問い合せと見て良いのではない.

オプティマイザの判断（判断に影響を与えるパラメータがある）で INDEX_FFSヒントを利用しているか、オプティマイザ判断でヒントはないかもしれない場合くらい、以下のようなヒント付きか、ヒントなしの以下SQLをイメージできていれば正解ではないでしょうか.
SCOTT> select /*+ index_ffs(tab3 tab3_pk) */ unique_id from tab3;
SCOTT> select unique_id from tab3;

グリーンペペさんのこんなエントリーを思い出しました:)
OraOraOracle Full / Scanを速くしちゃう　その６ / ペンネーム：グリーンペペ

yohei-aさんもこんな　straceしてたりして
ablog 不器用で落着きのない技術者のメモ / SQLトレースとstrace / yohei-a

さて、本題、Day 7の実行計画というレントゲン写真はこれ！

INDEX FULL SCAN ?

Day 6のOperationに似ていますが、FASTではありません.

この実行計画という名のレントゲン写真から、どのようなSQL文をイメージしますか？　また、どのような特徴をもっていると思いますか？

いろいろ考えちゃいますね〜。いろいろw

Day 8 へつづく

previously on Mac De Oracle
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 1 / TABLE FULL SCAN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 2 / INDEX UNIQUE SCAN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 3 / INDEX RANGE SCAN, Index Only Scan
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 4 / INDEX RANGE SCAN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 5 / INDEX RANGE SCAN, INLIST ITERATOR
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 6 / INDEX FAST FULL SCAN

投稿日時 2019年12月 7日 (土) 00時00分 Oracle, チューニング, SQL, イベント, Advent Calendar | 固定リンク | 0 | コメント (0)

2019年12月 6日 (金)

実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 Day 6

実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 Day 6のエントリーです.

Day 5 のつづきから.

どのようなSQL文かイメージできたでしょうか？　その特徴は？

"あれ？ INDEX RANGE SCAN + TABLE ACCESS BY INDEX ROWID BATCHED って Day 4 と同じ？　と思ったあなた！　よーく見てください〜. 違うんですよ〜っ！"

INLIST ITERATOR と Predicate Informationの3 - access("UNIQUE_ID"=1 OR "UNIQUE_ID"=10)

3 - access("UNIQUE_ID"=1 OR "UNIQUE_ID"=10) という述語をみれば、　WHERE句に　OR 条件があるのは明らかです. :) OR があるのは明らかですが、　実はINLIST ITERATOR というオペレーションは IN句を利用した場合にも発生します。　IN (a, b) って結局、 a or b なので内部的には同じ状況になっています。

この実行計画は、 id=1のINLIST ITERATOR 以下のid=2,3が2回実行されています. 3 - access("UNIQUE_ID"=1 OR "UNIQUE_ID"=10) = UNIQUE_ID IN (1, 10) となり、IN句の中の値の個数分繰り返されている　= 2回.

select * from tab311 where unique_id = 1 or unique_id = 10;
select * from tab311 where unique_id in (1, 10);

のいずれかということになります :) INLIST ITERATORで繰り返すのがよいのかはデータ量しだいだと思います。この場合、unique_idが主キーなので2回繰り返しても問題はないと思います。とはいえ、INDEX RANGE SCANだけを2回実行してROWIDをあつめて、TABLE ACCESS BY INDEX ROWID BATCHEDを1回実行したほうがよいのではないかと思わなくもない.
id=1とid=2のOperationを入れ替えれば、INLIST ITERATIONで繰り返すのはINDEX RANGE SCAN（実質、INDEX UNIQUE SCAN を 2回ですが）を2回実行してUNIQUE KEYから2つのROWIDをあつめ、そのあと、TABLE ACCESS BY INDEX ROWID BATCHEDをやったらいいんじゃないかなぁ（細かいこというと）と実行計画をみながら思ったのでした.

さて、本題、Day 6の実行計画というレントゲン写真はこれ！

? TABLE ACCESS BY INDEX ROWID BATCHED がないですね. でもちょっと違う.

INDEX FAST FULL SCANとでています

この実行計画という名のレントゲン写真から、どのようなSQL文をイメージしますか？　また、どのような特徴をもっていると思いますか？

いろいろ考えちゃいますね〜。いろいろw

Day 7 へつづく

previously on Mac De Oracle
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 1 / TABLE FULL SCAN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 2 / INDEX UNIQUE SCAN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 3 / INDEX RANGE SCAN, Index Only Scan
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 4 / INDEX RANGE SCAN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 5 / INDEX RANGE SCAN, INLIST ITERATOR

投稿日時 2019年12月 6日 (金) 00時00分ニュース, Oracle, SQL, イベント, Advent Calendar | 固定リンク | 0 | コメント (0)

2019年12月 5日 (木)

実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 Day 5

実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 Day 5のエントリーです.

Day 4 のつづきから.

どのようなSQL文かイメージできたでしょうか？　その特徴は？

"あれ？ INDEX RANGE SCANって Day 3 と同じ？　と思ったあなた！　よーく見てください〜. 違うんですよ〜っ！"

なにが Day 3 のINDEX RANGE SCANと違うか.... それは　Index Only Scanではないというところ.

Predicate Informationは、Day 3とほぼおなじ（リレラル値は異なりますが）、2 - access("UNIQUE_ID">=1 AND "UNIQUE_ID"<=2) となっています. WHERE unique_id BETWEEN 1 AND 2 のようなWHERE句が浮かびますよね？

残るOperationは、Id=1のTABLE ACCESS BY INDEX ROWID BATCHEDです. その他の句を思い浮かべるようなOperationはりません. WHERE句以外で、索引に含まれていない列がどこかに含まれているということに気づけば答えは簡単.

SELECTリストで　TAB3_PK索引に含まれていない列が参照されているということになります. 次のようなSQL文をイメージできたら正解だと思います.
SELECTリストは * にしてあるのは、SQL*Plusのautotraceでは、それらを特定するまでの情報はリストされないため、SELECTリストを * にしています. 索引に含まれている列以外を参照させればよいので.

select * from tab3 where unique_id between 1 and 2;

ちなみに、TABLE ACCESS BY INDEX ROWID BATCHEDというOperationは、Oracle Database 12cR1 から見られるようになったOperationです.
それまでは、TABLE ACCESS BY INDEX ROWID というOperationだけで、裏では、db file parallel read だったり、db file sequential readだったりしてたのが、実行計画からも判断できるようになって、おお〜っ. と感じたことを思い出した ;)
TABLE ACCESS BY INDEX ROWID BATCHED (Oracle Database 12c R1) ってなに！　#3

さて、本題、Day 5の実行計画というレントゲン写真はこれ！

INDEX RANGE SCANN + TABLE ACCESS BY INDEX ROWID BATCHED

Day 4 の実行計画に似てる、でもちょっと違う！

この実行計画という名のレントゲン写真から、どのようなSQL文をイメージしますか？　また、どのような特徴をもっていると思いますか？

本気で余裕のない師走w なんだこりゃw というアトモスフィアになってきましたが、皆様、そんな時こそ、体調管理しっかりしましょうね。（自分への注意喚起も込めてw）

Day 6 へつづく

previously on Mac De Oracle
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 1 / TABLE FULL SCAN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 2 / INDEX UNIQUE SCAN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 3 / INDEX RANGE SCAN, Index Only Scan
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 4 / INDEX RANGE SCAN

投稿日時 2019年12月 5日 (木) 00時00分 Oracle, チューニング, SQL, イベント, Advent Calendar | 固定リンク | 0 | コメント (0)

2019年12月 4日 (水)

実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 Day 4

実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 Day 4のエントリーです.

Day 3 のつづきから.

どのようなSQL文かイメージできたでしょうか？　その特徴は？

これ私がなんどもネタにしてきた、大好きな、Index Only Scan (Index Only Access という呼び方もあります）でっす:)

Id=1で、INDEX RANGE SCAN となっているので、TAB3_PK索引の特定の範囲、範囲は、Predicate Informationでリストされている　1 - access("UNIQUE_ID">=1 AND "UNIQUE_ID"<=10) なので、 TAB3_PK 索引を UNIQUE_IDが1〜10の範囲で検索していることがわかります.
また、この実行計画のポイントは、Day 2に見られたような、索引から得られる行の位置情報であるROWIDを利用した表へのアクセスがないところ.

これの意味するとこは、索引はアクセスするが、表はアクセスしないということを意味しています. つまり、索引だけをアクセスしています.

1 - access("UNIQUE_ID">=1 AND "UNIQUE_ID"<=10) といく述語があるので、WHERE句はあるはずですが、SELECTリストでは、索引列のみが参照されている！　= Index Only Scanということになります.

以下のようなSQL文を想像できていれば正解です. :)

select unique_id from tab3 where unique_id between 1 and 10;

Index Only Scanのイメージ図は以下のとおり.

Index Only Scanは表へのアクセスを省略できるのがメリットですが、複数のIndex Only Scanを狙いすぎため結果索引が多くなり、アンチパターンで有名なインデックスショットガンにならないような注意を必要とする点はみなさんご存知なのではないかと思います.
更新系処理の性能要件を満たせている限りガチで使った案件もなくはないですが、それはそれで索引のメンテナンスなども大変になることもあり、用法・用量には注意してくださいね. ;)

ということで、Day 4の実行計画というレントゲン写真はこれ！

INDEX RANGE SCAN

あれ？ INDEX RANGE SCANって Day 3 と同じ？　と思ったあなた！　よーく見てください〜. 違うんですよ〜っ！
Day 3との違いに気づければ、該当するSQL文をイメージするのは簡単なのではないかと思います.

この実行計画というなのレントゲン写真から、どのようなSQL文をイメージしますか？　また、どのような特徴をもっていると思いますか？

本気で余裕のない師走w なんだこりゃw というアトモスフィアになってきました、体調管理しっかりしないと...

Day 5 へつづく

previously on Mac De Oracle
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 1 / TABLE FULL SCAN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 2 / INDEX UNIQUE SCAN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 3 / INDEX RANGE SCAN, Index Only Scan

投稿日時 2019年12月 4日 (水) 00時00分 Oracle, チューニング, SQL, イベント, Advent Calendar | 固定リンク | 0 | コメント (0)

2019年12月 3日 (火)

実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 3

実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 Day 3のエントリーです.

Day 2 のつづきから.

どのようなSQL文かイメージできたでしょうか？　その特徴は？
Id = 2 で　INDEX UNIQUE SCAN を行なっている点、Predicate Information に　2 - access("UNIQUE_ID"=1) とあるので、　unique_id列に一意索引または主キー索引があり、 = 1 で一意検索して、得られた行を特定する情報(Oracleの場合ははrowid）を使って、TABLEから該当行をアクセスしているのが id = 1 の　TABLE ACCESS BY INDEX ROWID.
Predicate Information には他の情報はリストされていないので、以下のような SQL文をイメージされたとしたら、正解ではないでしょうか。
（ちなみに、SELECTリストは * にしています. SELECTリストに関わる情報は特にないので. 今回は、SQL*Plusのautotraceを利用していますが、SQLモニター等より詳細な情報を取得することができる機能もあります。必要に応じてツールを使い分けることも重要なスキルだと思います）

select * from tab3 where unique_id = 1;

そう言えば、2009か2010年ごろ昔某所某プロジェクトで、SQLから実行計画をイメージする千本ノック（大げさですが）みたいなことを依頼されてやったことがありましてw。その逆をやってるだけですね、これ！w よーく考えたらw

ということで、Day 3の実行計画というレントゲン写真はこれ！

INDEX RANGE SCAN

この実行計画というなのレントゲン写真から、どのようなSQL文をイメージしますか？　また、どのような特徴をもっていると思いますか？
今回のAdvent Calendarに絡めたネタにも慣れてきたころだと思うので、このレントゲン写真から自由に読み取ってみてくだしぁ ;)

Day 4 へつづく

previously on Mac De Oracle
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 1 / TABLE FULL SCAN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 2 / INDEX UNIQUE SCAN

投稿日時 2019年12月 3日 (火) 00時00分 Oracle, チューニング, SQL, イベント, Advent Calendar | 固定リンク | 0 | コメント (0)

2019年12月 2日 (月)

実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 2

実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 Day 2のエントリーです.

まずは、Day 1の答え

以下の実行計画　(SQL*Plusのauto trace機能を利用) は、TABLE ACCESS FULL ではありますが、Execution PlanセクションとStatisticsセクションしかありません。
また、SQL文にWHERE句がある場合、実行計画の補足情報として、Predicate Information (identified by operation id) セクションがリストされます。
このセクションでは述語、つまり、WHERE句に関わる情報がリストされます。
Predicate Information (identified by operation id) セクションが一切リストされていないこのケースでは、WHERE句自体がSQL文中に存在しないことも読み取ることができます。

ということで、以下の3パターンの可能性はなくなりました。理由はすでにお分かりですよね？

2) select * from tab3 where id + 1 = 10;
3) select * from tab3 where id between 1 and 400000;
4) select /*+ FULL(tab3) */ * from tab3 where id between 1 and 10;

結果として、単純な全表走査を行うSQL文である 1) が正解ということになります。

治療の必要は基本的にありませんが、全表走査しているだけで性能要件を満たせない場合には、全表走査を早くするための治療が必要になる場合があります.
必要があって全表走査しているのであれば全表走査は悪ではありません。
（性能要件は事前に問診等で確認しておくことをおすすめします)

1) select * from tab3;

では、本題であるDay 2のレントゲン写真は、以下！

これには、先ほど解説したばかりのPredicate Information (identified by operation id) がリストされ、2 - access("UNIQUE_ID"=1) という部分から unique_id列でアクセスしていることが読み取れます。

Id=2のoperationでは、INDEX UNIQUE SCANが行われています。INDEX UNIQUE SCANしている対象オブジェクトは、TAB3_PK です。 INDEX という部分から　TAB3_PK は索引であることも読み取れます。
かつ、UNIQUE SCAN ということなので、索引は一意索引または、主キー索引で、一意に値を特定できる索引であることも合わせて読み取れます。

この実行計画という名のレントゲン写真から、どのようなSQL文をイメージしますか？　また、どのような特徴をもっていると思いますか？

つづきは、Day 3にて。:)

寒いのも、寒い場所も嫌いですw

投稿日時 2019年12月 2日 (月) 00時00分 Oracle, チューニング, SQL, イベント, JPOUG, パフォーマンス, Advent Calendar | 固定リンク | 0 | コメント (0)

2019年12月 1日 (日)

実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 1

実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 Day1のエントリーです.

Day 1のSQL文のレントゲンはこれ.

TABLE ACCESS FULL

この実行計画にSQL文をイメージしてみましょう. 目を閉じて〜
どのようなSQL文が浮かびましたか？

1) select * from tab3;

where句がない、とか

2) select * from tab3 where id + 1 = 10;

id列にユニーク索引または主キー作成があったとしても、索引を利用できないような構文だったり、とか

3) select * from tab3 where id between 1 and 400000;

id列にユニーク索引または主キー索引があったとしても、索引スキャンより全表走査が効率良いのでオプティマイザが選択した場合（一般的に30%程度未満が目安ですが）とか

4) select /*+ FULL(tab3) */ * from tab3 where id between 1 and 10;

id列にユニーク索引または主キー索引ががあり、オプティマイザに任せておけば、間違いなく、索引アクセスされるはずなのに、なぜか、FULLヒントが付いている場合とか

といくつかの状況になっている可能性があります。

TABLE ACCESS FULLが妥当な状況であれば、治療不要なわけですが、それ以外の場合、患者さんのリクエストや大人の事情を考慮かつ、治療誓約書にサインいただいたうえでw、治療する必要がありますよね。

今回の実行計画をみて上記のどの状態である可能性が高いでしょうか？

答えは、明日の窓にて。

ついに今年も残すところ今日を含め31日。　今年もいろいろ激動日々だったw
そう言えば、ことしは、飲み会でしか、湘南方面に行ってなかった。

投稿日時 2019年12月 1日 (日) 00時00分 Oracle, チューニング, SQL, イベント, Advent Calendar | 固定リンク | 0 | コメント (0)

2019年11月30日 (土)

実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺） Advent Calendar 2019

なんとなく、勢いではじめてみました、実行計画は、SQLのレントゲン写真だ! (Oracle Database編)

https://adventar.org/calendars/4737

なお、12/17分のエントリーは、JPOUG Advent Calendar 2019とクロスポストします。

投稿日時 2019年11月30日 (土) 00時00分 Oracle, チューニング, SQL, イベント | 固定リンク | 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日 (木)

ハッシュパーティションでのデータの偏り / FAQ

ぼやき漫才みたいな感じですが、Oracleに限らず、ハッシュパーティションでパーティション間のデータを均一にしたいなら、ユニークな値かそれに準ずる列を選ぶべきなわけですが、なにを間違ってしまったのか、稀ではありますが、少々残念なことになっていすることもあります。

とは言え、早めに気づけば影響も小さくて済むわけで:)

というわけで、今回はそんなおはなし。

id_code列の値はユニーク

ORCL@SCOTT> select count(*),count(distinct id_code) from org; COUNT(*) COUNT(DISTINCTID_CODE) ---------- ---------------------- 400000 400000

type列の値は、一意性がなくカーディナリティーも低い、かつ、大きな偏りがある。。

ORCL@SCOTT> select type,count(1) from org group by type; type COUNT(1) ---------- ---------- 1 60000 2 60000 9 60000 0 220000

ハッシュパーティションを選択する主な理由は、パーティションへのデータの均一分散なので、列の値がユニークな列をパーティションキーとしてパーティション化することが多いわけですが、。。

以下は、ハッシュキーに一意な値を持つ列を選択した場合の例

ORCL@SCOTT> r 1 create table hash_p_tab 2 partition by hash(id_code) 3 ( 4 partition hash_p_tab_p1 5 ,partition hash_p_tab_p2 6 ,partition hash_p_tab_p3 7 ,partition hash_p_tab_p4 8 ) 9 as select 10 id_code 11 ,foo 12 ,type 13 from 14* org Table created. ORCL@SCOTT> alter table hash_p_tab add constraint gpk_hash_p_tab primary key(id_code) using index global; Table altered. ORCL@SCOTT> exec dbms_stats.gather_table_stats(ownname=>'SCOTT',tabname=>'hash_p_tab',cascade=>true,no_invalidate=>false,granularity=>'ALL'); ORCL@SCOTT> select table_name,partition_name,num_rows from user_tab_partitions order by 1,2; TABLE_NAME PARTITION_NAME NUM_ROWS ------------------------------ ------------------------------ ---------- HASH_P_TAB HASH_P_TAB_P1 99901 HASH_P_TAB HASH_P_TAB_P2 100194 HASH_P_TAB HASH_P_TAB_P3 100056 HASH_P_TAB HASH_P_TAB_P4 99849

しかし、値の分布に偏りのあるカーディナリティの低い列を選んで残念なことになっているケースも稀にあったりします。

なぜ、ハッシュキーにこの列を選んだんだ! みたいな。。。

そんな時は、設計した人に聞くしかないです。何がやりたかったのかを。。。私に聞かれてもハッシュキーの選択をミスったんですよねーたぶん、としか言えないので。

ORCL@SCOTT> r 1 create table hash_p_tab_skew 2 partition by hash(type) 3 ( 4 partition hash_p_tab_skew_p1 5 ,partition hash_p_tab_skew_p2 6 ,partition hash_p_tab_skew_p3 7 ,partition hash_p_tab_skew_p4 8 ) 9 as select 10 id_code 11 ,foo 12 ,type 13 from 14* org Table created. ORCL@SCOTT> alter table hash_p_tab_skew add constraint gpk_hash_p_tab_skew primary key(id_code) using index global; Table altered. ORCL@SCOTT> exec dbms_stats.gather_table_stats(ownname=>'SCOTT',tabname=>'hash_p_tab_skew',cascade=>true,no_invalidate=>false,granularity=>'ALL'); PL/SQL procedure successfully completed. ORCL@SCOTT> select table_name,partition_name,num_rows from user_tab_partitions where table_name = upper('hash_p_tab_skew') order by 1,2 TABLE_NAME PARTITION_NAME NUM_ROWS ------------------------------ ------------------------------ ---------- HASH_P_TAB_SKEW HASH_P_TAB_SKEW_P1 0 HASH_P_TAB_SKEW HASH_P_TAB_SKEW_P2 280000 HASH_P_TAB_SKEW HASH_P_TAB_SKEW_P3 60000 HASH_P_TAB_SKEW HASH_P_TAB_SKEW_P4 60000

で、データを均一にパーティションに分散させることをなんとなーく、イメージしつつ、上記のようなミスをしてしまうと、パラレルクエリーなどで最もデータの多いパーティションの処理時間に引っ張られて想定より処理時間が長くなるなんてことも。。。あるわけで

例がイケてないけど（気にしないでw）、パラレルサーバーのスレーブ間でbuffer gets部分を見ていただくと偏りはわかりやすいはず。(赤字部分）:)

偏りあり

orcl2@SCOTT> @sql_skew 1 select 2 /*+ 3 monitor 4 parallel(4) 5 */ 6 count(1) 7 from 8 hash_p_tab_skew t01 9 inner join hash_p_tab_skew2 t02 10 on 11 t01.id_code = t02.id_code 12* and t01.type = t02.type Parallel Execution Details (DOP=4 , Servers Allocated=4) ========================================================================================== | Name | Type | Server# | Elapsed | Cpu | Other | Buffer | Wait Events | | | | | Time(s) | Time(s) | Waits(s) | Gets | (sample #) | ========================================================================================== | PX Coordinator | QC | | 0.02 | 0.00 | 0.02 | 72 | | | p000 | Set 1 | 1 | 0.18 | 0.17 | 0.01 | 1940 | | | p001 | Set 1 | 2 | 0.05 | 0.05 | 0.00 | 448 | | | p002 | Set 1 | 3 | 0.05 | 0.05 | 0.00 | 448 | | | p003 | Set 1 | 4 | 0.00 | 0.00 | 0.00 | | | ==========================================================================================

偏りの悪影響のイメージはこんな感じ

偏りなし

orcl2@SCOTT> @sql_noskew 1 select 2 /*+ 3 monitor 4 parallel(4) 5 */ 6 count(1) 7 from 8 hash_p_tab t01 9 inner join hash_p_tab2 t02 10 on 11 t01.id_code = t02.id_code 12* and t01.type = t02.type Parallel Execution Details (DOP=4 , Servers Allocated=4) ========================================================================================== | Name | Type | Server# | Elapsed | Cpu | Other | Buffer | Wait Events | | | | | Time(s) | Time(s) | Waits(s) | Gets | (sample #) | ========================================================================================== | PX Coordinator | QC | | 0.01 | 0.00 | 0.00 | 96 | | | p000 | Set 1 | 1 | 0.08 | 0.08 | | 714 | | | p001 | Set 1 | 2 | 0.08 | 0.08 | 0.00 | 714 | | | p002 | Set 1 | 3 | 0.08 | 0.07 | 0.01 | 714 | | | p003 | Set 1 | 4 | 0.08 | 0.08 | | 712 | | ==========================================================================================

パーティション毎にぞれぞれ得手不得手があります。そこんとこを把握したうえで、有効活用したいものですよね。（パーティションもいろいろ進化してきて便利になってきたわけですが、その分わかりにくいところも増えてきて理解するのに大変だったり 18cのも差分は把握しといたほうがいいかw...:)

津島博士のパフォーマンス講座第10回パーティションについて

投稿日時 2019年3月21日 (木) 20時49分チューニング, FAQ, SQL, Oracle Database 11g Release 2, Oracle Database 12c release 1, Oracle Database 12c Release 2, Oracle Database 18c | 固定リンク | 0 | コメント (0)

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月12日 (火)

RDS Oracle 雑多なメモ#17/ FAQ

Oracle DB インスタンスの一般的な DBA タスクに記載されているAmazon RDS OracleとオンプレのOracleの操作方法の違は意外に多く、長年かけて体に染み付いていて、脊髄反応でタイプしてしまうとエラー、あ”〜っなんてこともしばしばw

仕方ないので、慣れるしかないわけですが、脊髄反応でオンプレのコマンドをタイプして、あ”〜っ！　となったことのある個人的な Top5 を備忘録として書いておきます:)
脊髄反応でそんな権限ないよーというショックなエラーうけとる回数を少しでも減らせるようAmazon RDSパッケージのタイプ練習中の日々w （いずれ、うまく切り替えられるようになれるだろうと信じてw

Oracle DB インスタンスの一般的な DBA システムタスク
 Oracle DB インスタンスの一般的な DBA データベースタスク
 Oracle DB インスタンスの一般的な DBA ログタスク
 Oracle DB インスタンスの一般的な DBA のその他のタスク

個人的に、つい、オンプレと同じ操作をして、エラーになってしまった Top5 w

1位. sysオブジェクトへ権限付与で grant文をタイプしてしまう。
2位. つい、alter system kill session をタイプしてしまう。
3位. オンラインログファイルを切り替えたり、追加、削除で、alter database add logfile..をタイプしたり、alter system switch logfileをタイプしてしまう。
4位. ディレクトリオブジェクトを作成しようとして、create directory...をタイプしてしまう。
5位. rmanの検証コマンドを使おうとして、生のrmanは使えなかった、と気づくw

私がつい、脊髄反応でオリジナルのコマンドをタイプして、エラー？　なぬ？　あ、RDSではAmazon RDS向けのパッケージ使うんだった！！と　気づく典型的な操作の数々(^^;;;;; 長年しみついた手癖で脊髄反応しちゃうのでどうしようもないのですw
みなさんはどのコマンドで、あ”！　となることが多いのでしょうか？（おそらく Top.1は、私と同じ、grant関連ではないでしょうか？w 一番使う機会が多いですからね）

話は少々脱線しますが、上記操作を行うAmazon RDSパッケージでデータベースサイズが大きくなると処理時間を要するものもそこそこあります。
Amazon RDSパッケージで提供されていても内部ではOracleの対応する機能を実行しているわけで、処理時間を要するタイプの操作を行った場合、処理の進行状況を確認確認したくなることもあります。そんな時は、v$session_longops を参照するとよいのではないかと思います。全ての機能が詳細な情報をv$session_longopsに載せてくれるわけではないですが。。（オンプレのOracle Databaseを利用していたという方でも、v$session_longops を使ったことはないなんてことも少なくないような気がします)

RDS Oracleでも　v$session_longops ビューは効果的に利用できる例として、datapumpやOracle DB インスタンスの一般的な DBA データベースタスクでも解説されているrmanの検証コマンドの実行時など、操作にそれなりの時間を要するタイプのものです。（datapumpについては、詳細なステータスを記録していないようなので、datapumpのlogを覗くほうが状況確認としては便利ではありますが、一応、datapumpもv$session_longopsには記録されます。この点はOracle由来なのでオンプレでも同じです。）

一例として、それなりに時間を要する処理の代表格、Amazon RDS プロシージャ rdsadmin.rdsadmin_rman_util.validate_database(Oracle DB インスタンスの一般的な DBA データベースタスク参照）を利用した関連ファイル検証の進行状況をv$session_longopsを利用してモニターリング:)

今回利用したRDS Oracleのデータファイルはぞれぞれ以下のようなサイズです。

SQL> r 1 select 2 tablespace_name 3 ,file_name 4 ,sum(bytes)/1024/1024 "MB" 5 from 6 dba_data_files 7 group by 8 tablespace_name 9 ,file_name 10 union all 11 select 12 tablespace_name 13 ,file_name 14 ,sum(bytes)/1024/1024 "MB" 15 from 16 dba_temp_files 17 group by 18 tablespace_name 19* ,file_name TABLESPACE_NAME FILE_NAME MB ------------------------------ ------------------------------------------------------------ ---------- SYSAUX /rdsdbdata/db/ORCL_A/datafile/o1_mf_sysaux_fxpjf1nv_.dbf 498.9375 USERS /rdsdbdata/db/ORCL_A/datafile/o1_mf_users_fxpjf3d2_.dbf 100 UNDO_T1 /rdsdbdata/db/ORCL_A/datafile/o1_mf_undo_t1_fxpjf2lx_.dbf 290 RDSADMIN /rdsdbdata/db/ORCL_A/datafile/o1_mf_rdsadmin_fxpkkz9k_.dbf 7 SYSTEM /rdsdbdata/db/ORCL_A/datafile/o1_mf_system_fxpjdxws_.dbf 500 TEMP /rdsdbdata/db/ORCL_A/datafile/o1_mf_temp_fxpjf34b_.tmp 100 ---------- sum 1495.9375

事前に作成しておいたスクリプトでAmazon RDS プロシージャ rdsadmin.rdsadmin_rman_util.validate_databaseの処理状況をモニタリングしています（スクリプトの例は後半参照のこと）

SQL> @show_validate_status レコードが選択されませんでした。 SQL> / NOW SID SERIAL# OPNAME CONTEXT SOFAR TOTALWORK % done -------------------------------- ---------- ---------- ------------------------------ ---------- ---------- ---------- ---------- 19-02-11 09:42:18.217701 +00:00 665 51783 RMAN: full datafile backup 1 123322 178680 69.02 SQL> / NOW SID SERIAL# OPNAME CONTEXT SOFAR TOTALWORK % done -------------------------------- ---------- ---------- ------------------------------ ---------- ---------- ---------- ---------- 19-02-11 09:42:19.298741 +00:00 665 51783 RMAN: full datafile backup 1 139452 178680 78.05 SQL> / NOW SID SERIAL# OPNAME CONTEXT SOFAR TOTALWORK % done -------------------------------- ---------- ---------- ------------------------------ ---------- ---------- ---------- ---------- 19-02-11 09:42:20.367723 +00:00 665 51783 RMAN: full datafile backup 1 156028 178680 87.32 SQL> / NOW SID SERIAL# OPNAME CONTEXT SOFAR TOTALWORK % done -------------------------------- ---------- ---------- ------------------------------ ---------- ---------- ---------- ---------- 19-02-11 09:42:21.289310 +00:00 665 51783 RMAN: full datafile backup 1 170428 178680 95.38 SQL> / レコードが選択されませんでした。 SQL> SQL> !cat show_validate_status.sql col "NOW" for a32 col opname for a30 SELECT systimestamp AS "NOW" ,sid ,serial# ,opname ,context ,sofar ,totalwork ,round(sofar / totalwork * 100, 2) "% done" FROM v$session_longops WHERE opname LIKE 'RMAN%' AND opname NOT LIKE '%aggregate%' AND sofar != totalwork AND totalwork != 0;

Previously on Mac De Oracle

・RDS Oracle 雑多なメモ#1 / FAQ
・RDS Oracle 雑多なメモ#2 / FAQ
・RDS Oracle 雑多なメモ#3 / FAQ
・RDS Oracle 雑多なメモ#4 / FAQ
・RDS Oracle 雑多なメモ#5 / FAQ
・RDS Oracle 雑多なメモ#6 / FAQ
・RDS Oracle 雑多なメモ#7 / FAQ
・RDS Oracle 雑多なメモ#8 / FAQ
・RDS Oracle 雑多なメモ#9 / FAQ
・RDS Oracle 雑多なメモ#10 / FAQ
・RDS Oracle 雑多なメモ#11 / FAQ
・RDS Oracle 雑多なメモ#12 / FAQ
・RDS Oracle 雑多なメモ#13 / FAQ
・RDS Oracle 雑多なメモ#14 - おまけ / FAQ
・RDS Oracle 雑多なメモ#15 - おまけのおまけ / FAQ
・RDS Oracle 雑多なメモ#16 - 再び:) / FAQ

投稿日時 2019年2月12日 (火) 01時00分 PL/SQL, FAQ, SQL, Oracle Database 11g Release 2, Oracle Database 12c release 1, Oracle Database 12c Release 2, AWS, RDS | 固定リンク | 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)

SQL*Plusでcsv出力できるんですよ / FAQ

SQL*Plusでcsv出力する簡単な方法って、意外に知られてないようなのでメモ程度に書いておきます。
自分でもコピペネタとするためにw

SQL> select * from q order by id; ID DATA ---------- ---------- 1 テスト 2 平成 3 abcdbef 4 あ 5 A SQL> set markup csv on SQL> select * from q order by id; "ID","DATA" 1,"テスト" 2,"平成" 3,"abcdbef" 4,"あ" 5,"A" SQL> set markup csv off

set markup csv on でcsv出力を簡単に取得できます。
これがなかったころはパッケージ作ったりしてましたけど、これなら手間いらず:)

スプールしてファイルに書き出すスクリプトを作っておくと便利です。
以下のスクリプトは &1 パラメータでcsv化する表名称を渡すだけ。

SQL> !cat makecsv.sql -- -- parameter 1 : table name -- set feed off set timi off set head off set termout off set veri off set markup csv on spool loaddata_&1..csv select * from &1 order by id; spo off set markup csv off set termout on set head on set feed on set veri on undefine 1

SQL> @makecsv q SQL> SQL> !cat loaddata_q.csv 1,"テスト" 2,"平成" 3,"abcdbef" 4,"あ" 5,"A"

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

2019年1月 7日 (月)

PostgreSQL向け、俺よう便利メモ

testdb=> select version(); version ----------------------------------------------------------------------------- PostgreSQL 10.5 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 4.9.3, 64-bit

以降のスクリプトの動作確認用の表定義

testdb=> \d+ hoge Table "public.hoge" Column | Type | Modifiers | Storage | Stats target | Description --------+------------------------+-----------+----------+--------------+------------- id | numeric(10,0) | not null | main | | status | numeric(2,0) | not null | main | | note | character varying(100) | | extended | | Indexes: "hoge_pkey" PRIMARY KEY, btree (id)

PL/pgSQLでPL/SQLっぽい感じの無名ブロックを書いてみた。commit/rollbackは含めふことができないってところはちょいとハマるね。Oraclerには。（なれれば問題ないって感じはするが）

testdb=> \! cat ins10000000.sql DO $$BEGIN FOR i IN 1..10000000 LOOP INSERT INTO hoge (id, status, note) VALUES( i, 0, LPAD('hoge',100,'x') ); END LOOP; END$$; testdb=> \i ins10000000.sql

まあ、いろいろ勝手が違うので、よく使いそうなSQL文も作り置きしておかないと。
以下のSQLは、Oracle Databaseだと表と索引のセグメントサイズの確認で dba_segmentsを問い合わせるのと同じイメージな。ビューは違うけど。

testdb=> \! cat show_segment_size.sql SELECT objectname , TO_CHAR(pg_relation_size(objectname::regclass), '999,999,999,999') AS bytes FROM ( SELECT tablename AS objectname FROM pg_tables WHERE schemaname = 'public' UNION SELECT indexname AS objectname FROM pg_indexes WHERE schemaname = 'public' ) AS objects ORDER BY bytes DESC ;

testdb=> \i show_segment_size.sql objectname | bytes ------------+------------------ hoge | 1,412,415,488 hoge_pkey | 224,632,832 (2 rows)

Oracle Databaseとは異なるアーキテクチャを採用しているPostgreSQLの特徴がよく見える部分。全体の30％ぐらいの行を削除して、dead tupleを確認してみたところ。
Inside vacuum - 第一回PostgreSQLプレ勉強会

testdb=> \! cat show_dead_tup_ratio.sql SELECT relname , n_live_tup , n_dead_tup , CASE WHEN n_live_tup > 0 THEN ROUND(n_dead_tup * 100 / n_live_tup, 2) ELSE NULL END AS ratio FROM pg_stat_user_tables;

testdb=> delete from hoge where id between 1 and 3000000; DELETE 3000000 testdb=> \i show_dead_tup_ratio.sql relname | n_live_tup | n_dead_tup | ratio ---------+------------+------------+------- hoge | 6973030 | 3020431 | 43.00 (1 row)

最後は、Lockの状態を確認するSQL文。この部分もOracle Databaseとは異なるとこも多いので、Lockがどうなってるか見えるようなSQL文は作り置きしておくと便利。
宣言的パーティションのロックもOracleのPartitionとは異なる部分も多いので事前に確認しておくと、あとから驚くようなことがなくて安心できる、かも。

testdb=> \! cat show_locked_objects.sql SELECT clock_timestamp() , pc.relname , pl.locktype , pl.database , pl.relation , pl.page , pl.tuple , pl.virtualtransaction , pl.pid , pl.mode , pl.granted FROM pg_locks pl INNER JOIN pg_class pc ON pl.relation = pc.oid WHERE pc.relname !~ '^pg_' AND pc.relname <> 'activelocks';

testdb=> BEGIN; BEGIN testdb=> SELECT * FROM hoge FOR UPDATE SKIP LOCKED; id | status | note ----+--------+------------------------------------------------------------------------------------------------------ 1 | 0 | xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxhogedkdkhoge (1 row)

testdb=> \i show_locked_objects.sql clock_timestamp | relname | locktype | database | relation | page | tuple | virtualtransaction | pid | mode | granted -------------------------------+-----------+----------+----------+----------+------+-------+--------------------+-------+-----------------+--------- 2019-01-07 07:45:33.742858+00 | hoge_pkey | relation | 16401 | 16405 | | | 8/11426 | 18445 | AccessShareLock | t 2019-01-07 07:45:33.742879+00 | hoge | relation | 16401 | 16402 | | | 8/11426 | 18445 | RowShareLock | t (2 rows)

投稿日時 2019年1月 7日 (月) 18時27分 FAQ, SQL, PostgreSQL, AWS, RDS | 固定リンク | 0 | コメント (0) | トラックバック (0)

SELECT ~ FOR UPDATE　その後

あけましておめでとうございます。本年もよろしくお願いいたします。

今年の初エントリーは、随分昔のネタを引っ張り出してみましたw
というのも、最近は、Oracle以外のRDBMSに関わる機会が多くなり、調べていると昔のネタに繋がっていた！　という状況も多々あり、ついでなので他のネタを織り交ぜながら書いていったほうがよいのではないか？　と遠くを眺めながら思っていますw

さて、本題です。

SELECT ~ FOR UPDATE SKIP LOCKED　その１ - @sh2ndさんのエントリの復習など
って
もう5年前のネタですが、世の中もDB業界的にもいろいろな動きがって、MySQLやPostgreSQLを利用する機会も多くなってきた。。。方々（私も含むw）多くなってきたようなので忘れかけてたことを思い出すのための確認など

最近のリリースでSELECT ~ FOR UPDATEの動きを確認

結果
Oracle READ COMMITTED

12.1.0.2.0 ID=2を取得

12.2.0.1.0 ID=2を取得

18.3.0.0.0 ID=2を取得

ところで、PostgreSQL でも　9.5からFOR UPDATE SKIP LOCKEDがサポートされていて、PostgreSQLのSKIP LOCKED動きが、Oracleとおなじだったのは興味深い発見だった :)

・SELECT ~ FOR UPDATE SKIP LOCKED　その１ - @sh2ndさんエントリの復習など
 ・SELECT ~ FOR UPDATE SKIP LOCKED　その２
 ・SELECT ~ FOR UPDATE SKIP LOCKED　その３
 ・SELECT ~ FOR UPDATE SKIP LOCKED　その4 - もしもITL不足だったら...

投稿日時 2019年1月 7日 (月) 14時18分 Oracle, SQL, PostgreSQL | 固定リンク | 0 | コメント (0) | トラックバック (0)

2018年11月 4日 (日)

RDS Oracle 雑多なメモ#16 - 再び:) / FAQ

再び忘れがちなので、備忘録。

RDS Oracleでマスターユーザー以外で、SQL*PLusの Auto trace そして、DBMS_XPLAN.DISPLAY や DBMS_XPLAN.DISPLAY_CURSOR を使おうとすると以下のようなエラーに遭遇！　
なにも準備してないと。（explain plan for文だけは準備していなくても可能なのでが）

TEST> set autot trace exp stat SP2-0618: Cannot find the Session Identifier. Check PLUSTRACE role is enabled SP2-0611: Error enabling STATISTICS report

とか

...略... TEST> select * from table(dbms_xplan.display_cursor(format=>'ALLSTATS LAST')); PLAN_TABLE_OUTPUT ------------------------------------------------------------------------------------------ User has no SELECT privilege on V$SESSION

なんてことに、

RDS Oracle、マスターユーザーでは可能なのですが、PLUSTRACEロールも作成されていない、かつ、 plustrce.sql がない.

AWSUSER> select role from dba_roles where role = 'PLUSTRACE'; no rows selected

ということで、いちいち調べるのも面倒なFAQとなっているので、備忘録として書いておきました。

マスターユーザー以外のユーザーに alter session システム権限を付与しておきます。
該当システム権限が付与されていないと、セッションレベルで　statistics_level パラメータを変更できません。
このパラメータは、dbms_xplan.display_cursor でactual planを取得する際に必要になるのですが、最悪付与されていない場合には、SQL文に以下のヒントを追加することで代替可能ではありますが、いちいちSQL文に以下のヒントを追加しなければならないので面倒。
とはいえ、alter sessionは付与したくないということもなくはなく、そんな時は以下のヒントで頑張っください。

ex.

SELECT /*+ gather_plan_statistics */ * FROM hoge WHERE id = 1;

次に必要なのは、　v$sessionなどを含むいくつかのパフォーマンスビューへのSELECTオブジェクト権限、グローバルな一時表として定義されているplan_tableへの全オブジェクト権限です。
管理面を考えてロールを作成し関連権限をロールに付与、作成したロールを対象ユーザーに付与するようにすると便利です。

alter sessionsシステム権限を含む最低限必要なオブジェクト権限とそれを付与するロール作成スクリプトの例は以下の通り。

foobar$ cat create_dev_role.sql -- create developer role create role dev_role; -- for show parameter grant alter session to dev_role; -- for dbms_xplan.display_cursor and auto trace exec rdsadmin.rdsadmin_util.grant_sys_object('V_$SESSION', 'DEV_ROLE', 'SELECT'); -- for dbms_xplan.display_cursor exec rdsadmin.rdsadmin_util.grant_sys_object('V_$SQL_PLAN_STATISTICS_ALL', 'DEV_ROLE', 'SELECT'); exec rdsadmin.rdsadmin_util.grant_sys_object('V_$PARAMETER', 'DEV_ROLE', 'SELECT'); exec rdsadmin.rdsadmin_util.grant_sys_object('V_$SQL', 'DEV_ROLE', 'SELECT'); exec rdsadmin.rdsadmin_util.grant_sys_object('V_$SQL_PLAN', 'DEV_ROLE', 'SELECT'); -- for auto trace exec rdsadmin.rdsadmin_util.grant_sys_object('V_$STATNAME', 'DEV_ROLE', 'SELECT'); exec rdsadmin.rdsadmin_util.grant_sys_object('V_$MYSTAT', 'DEV_ROLE', 'SELECT'); exec rdsadmin.rdsadmin_util.grant_sys_object('V_$SESSTAT', 'DEV_ROLE', 'SELECT'); -- for auto trace (plan_table - temporary table) exec rdsadmin.rdsadmin_util.grant_sys_object('PLAN_TABLE$', 'DEV_ROLE', 'ALL');

参考
Oracle DB インスタンスの一般的な DBA タスク

ということで、動作確認を兼ねたサンプルは以下のとおり。

まずは、RDS Oracleのマスターユーザーで.
マスターユーザー以外のユーザーの作成と権限とロールの付与（チューニングが必要とされる開発者等)を想定

foobar$ sqlplus awsuser/xxxxxxx@xxxx.xxxxxxxx.rds.amazonaws.com:1521/HOGE SQL*Plus: Release 12.1.0.2.0 Production on Fri Nov 2 22:05:14 2018 Copyright (c) 1982, 2016, Oracle. All rights reserved. Last Successful login time: Fri Nov 02 2018 22:01:24 +09:00 ...中略... AWSUSER> l 1 create user test identified by xxxxxx 2 default tablespace users 3 temporary tablespace temp 4* quota unlimited on users AWSUSER> / User created. AWSUSER> grant connect, resource to test; Grant succeeded. AWSUSER> @create_dev_role Role created. Grant succeeded. PL/SQL procedure successfully completed. PL/SQL procedure successfully completed. PL/SQL procedure successfully completed. PL/SQL procedure successfully completed. PL/SQL procedure successfully completed. PL/SQL procedure successfully completed. PL/SQL procedure successfully completed. PL/SQL procedure successfully completed. PL/SQL procedure successfully completed. AWSUSER> grant dev_role to test; Grant succeeded. AWSUSER> exit

作成したユーザーで接続して、各方法で実行計画を取得できるか確認！
クエリーを実行するため適当な表を作成してデータを登録しておく。

foobar$ sqlplus test/xxxxxxx@xxxx.xxxxxxxx.rds.amazonaws.com:1521/HOGE SQL*Plus: Release 12.1.0.2.0 Production on Fri Nov 2 22:15:23 2018 Copyright (c) 1982, 2016, Oracle. All rights reserved. ...中略... TEST> TEST> l 1 create table hoge ( 2 id number not null primary key 3 ,foobar varchar2(20) 4* ) nologging TEST> / Table created. TEST> TEST> l 1 begin 2 for i in 1..10000 loop 3 insert into 4 hoge ( 5 id 6 ,foobar 7 ) 8 values ( 9 i 10 ,to_char(i) 11 ); 12 end loop; 13 commit; 14* end; TEST> / PL/SQL procedure successfully completed.

SQL*Plusのauto traceが行えるか確認！

TEST> set autot trace exp stat TEST> select * from hoge where id = 1; Elapsed: 00:00:00.07 Execution Plan ---------------------------------------------------------- Plan hash value: 2757398040 ------------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ------------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 1 | 25 | 1 (0)| 00:00:01 | | 1 | TABLE ACCESS BY INDEX ROWID| HOGE | 1 | 25 | 1 (0)| 00:00:01 | |* 2 | INDEX UNIQUE SCAN | SYS_C005687 | 1 | | 1 (0)| 00:00:01 | ------------------------------------------------------------------------------------------- Predicate Information (identified by operation id): --------------------------------------------------- 2 - access("ID"=1) Statistics ---------------------------------------------------------- 0 recursive calls 0 db block gets 3 consistent gets 0 physical reads 0 redo size 342 bytes sent via SQL*Net to client 488 bytes received via SQL*Net from client 1 SQL*Net roundtrips to/from client 0 sorts (memory) 0 sorts (disk) 1 rows processed

参考
文のトレースについて

explain plan for文は準備なしで問題ないのですが、念のための確認！ DBMS_XPLAN.DISPLAYプロシージャを利用して実行計画を取得

TEST> TEST> explain plan for 2 select * from hoge where id = 1; explained. TEST> @show_explain PLAN_TABLE_OUTPUT ------------------------------------------------------------------------------------------ Plan hash value: 2757398040 ------------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ------------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 1 | 25 | 1 (0)| 00:00:01 | | 1 | TABLE ACCESS BY INDEX ROWID| HOGE | 1 | 25 | 1 (0)| 00:00:01 | |* 2 | INDEX UNIQUE SCAN | SYS_C005687 | 1 | | 1 (0)| 00:00:01 | ------------------------------------------------------------------------------------------- Predicate Information (identified by operation id): --------------------------------------------------- 2 - access("ID"=1) 14 rows selected. Elapsed: 00:00:00.05

スクリプト例は以下の通り。$ORACLE_HOME/rdbms/admin/utlxpls.sql や、utlxplp.sqlが利用できれば楽なんでが、それら中身は、DBMS_XPLAN.DISPLAYなので大差ない内容。

$ cat show_explain.sql set linesize 200 set long 100000 set longchunk 200 set tab off SELECT * FROM TABLE( DBMS_XPLAN.DISPLAY( format => 'ALL -PROJECTION -ALIAS' ) ) ;

Actual planをDBMS_XPLAN.DISPLAY_CURSORプロシージャで取得〜

TEST> TEST> @show_realplan NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ statistics_level string TYPICAL Session altered. *** SQL that you want to get an actual plan *** 1* select * from hoge where id = 1 *********************************************** PLAN_TABLE_OUTPUT ------------------------------------------------------------------------------------------ SQL_ID 6f67zkz43kr76, child number 1 ------------------------------------- select * from hoge where id = 1 Plan hash value: 2757398040 ----------------------------------------------------------------------------------------------------- | Id | Operation | Name | Starts | E-Rows | A-Rows | A-Time | Buffers | ----------------------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 1 | | 1 |00:00:00.01 | 3 | | 1 | TABLE ACCESS BY INDEX ROWID| HOGE | 1 | 1 | 1 |00:00:00.01 | 3 | |* 2 | INDEX UNIQUE SCAN | SYS_C005687 | 1 | 1 | 1 |00:00:00.01 | 2 | ----------------------------------------------------------------------------------------------------- Predicate Information (identified by operation id): --------------------------------------------------- 2 - access("ID"=1) 19 rows selected. Elapsed: 00:00:00.11 Session altered. NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ statistics_level string TYPICAL

Actual planを取得するスクリプト例
SQL*Plusのコマンドを駆使してはいますが、ポイントはset statistics_level = allにすることと、DBMS_XPLAN.DISPLAY_CURSORをコールする際のformatパラメータです
set termout off/onでSQL文の結果を表示しないようにしています。この設定はSQLファイルからSQL文を実行した場合にだけ有効です。（ちょっとしたTips :)

$ cat show_realplan.sql show parameter statistics_level alter session set statistics_level = all; set linesize 200 set long 100000 set longchunk 200 set tab off PROMPT *** SQL that you want to get an actual plan *** select * from hoge where id = 1 . l PROMPT *********************************************** set termout off r set termout on -- get the actual plan set timi on SELECT * FROM TABLE( DBMS_XPLAN.DISPLAY_CURSOR( format => 'ALLSTATS LAST' ) ) ; set timi off alter session set statistics_level = typical; show parameter statistics_level

参考
DBMS_XPLANサブプログラムの要約

Apple Store Ginzaで、息子が　”iPadでムービーを作ろう” に参加するので、その合間に、パタパタブログを書き、その足で英会話に向かう日曜日の午後w

Previously on Mac De Oracle

・RDS Oracle 雑多なメモ#1 / FAQ
・RDS Oracle 雑多なメモ#2 / FAQ
・RDS Oracle 雑多なメモ#3 / FAQ
・RDS Oracle 雑多なメモ#4 / FAQ
・RDS Oracle 雑多なメモ#5 / FAQ
・RDS Oracle 雑多なメモ#6 / FAQ
・RDS Oracle 雑多なメモ#7 / FAQ
・RDS Oracle 雑多なメモ#8 / FAQ
・RDS Oracle 雑多なメモ#9 / FAQ
・RDS Oracle 雑多なメモ#10 / FAQ
・RDS Oracle 雑多なメモ#11 / FAQ
・RDS Oracle 雑多なメモ#12 / FAQ
・RDS Oracle 雑多なメモ#13 / FAQ
・RDS Oracle 雑多なメモ#14 - おまけ / FAQ
・RDS Oracle 雑多なメモ#15 - おまけのおまけ / FAQ

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

2018年10月15日 (月)

備忘録 - ビット演算 / FAQ

備忘録
ビット演算こんな感じでできるはず。

orcl@SCOTT> r 1 SELECT 2 d1 3 ,d2 4 ,x1 5 ,x2 6 ,UTL_RAW.BIT_OR(x1,x2) AS x1_bitor_x2 7 FROM 8 ( 9 SELECT 10 POWER(2, 1) AS d1 11 , HEXTORAW(TO_CHAR(POWER(2, 1), 'FM0000000X')) AS x1 12 , POWER(2, 3) AS d2 13 , HEXTORAW(TO_CHAR(POWER(2, 3), 'FM0000000X')) AS x2 14 FROM 15 dual 16* ) D1 D2 X1 X2 X1_BITOR_X2 ---------- ---------- ---------- ---------- ----------- 2 8 00000002 00000008 0000000A orcl@SCOTT>

Oracle Database 12cリリース2 PL/SQL Packages and Types Reference 270.3.3 BIT_ORファンクション
 Oracle Database 12c Release 2 SQL Language Reference 7.90 HEXTORAW
Oracle Database 12c Release 2 SQL Language Reference 7.159 POWER
Oracle Database 12c Release 2 SQL Language Reference 7.237 TO_CHAR (number)
Oracle Database 12c Release 2 SQL Language Reference 2.4 Format Models 2.4.1 Number Format Models
Oracle Database 12c Release 2 SQL Language Reference 2.4 Format Models FM

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

2018年9月28日 (金)

RDS Oracle 雑多なメモ#15 - おまけのおまけ / FAQ

やっぱり、改造してしまった。おまけのおまけ編w

前回単純にMD5を取得だけのスクリプトをやっつけで作ったので、それを少し改造して、締めくくり。？（たぶん。。）

前回作成したMD5取得スクリプトを元に、ファイルが同じかどうか比較するスクリプトに作り変えました :)

21:35:35 rdsora121@BILL> @ls_dir test_dir FILENAME TYPE FILESIZE MTIME ---------------------------------------------------------------------- ---------- ---------- -------- hoge.dmp.gz file 2603349 18-09-24 hoge.log.gz file 512 18-09-24 hoge.dmp.bak file 1083412480 18-09-24 hoge.dmp.gz.bak file 2603349 18-09-24 hoge.log.bak file 1202 18-09-24 hoge.log.gz.bak file 512 18-09-24 01/ directory 4096 18-09-24 hoge.dmp file 1083412480 18-09-24 hoge.log file 904 18-09-24 9行が選択されました。

ダンプファイル（一旦圧縮したファイルを解凍したファイル）とオリジナルのダンプファイルのコピーの比較

21:35:43 rdsora121@BILL> @diff_md5 test_dir hoge.dmp hoge.dmp.bak Src : 1B84C9E09F13A4FDC6EF2F03137C0338 Dest: 1B84C9E09F13A4FDC6EF2F03137C0338 -- No difference found. -- PL/SQLプロシージャが正常に完了しました。

ダンプファイル（オリジナルを圧縮したファイル）とオリジナルダンプファイルを圧縮したファイルのコピーの比較

21:36:28 rdsora121@BILL> @diff_md5 test_dir hoge.dmp.gz hoge.dmp.gz.bak Src : D2CB26A7E75C9725F00C30A9280C1599 Dest: D2CB26A7E75C9725F00C30A9280C1599 -- No difference found. -- PL/SQLプロシージャが正常に完了しました。

異なるファイルの比較、ログファイルのコピーと、圧縮したログファイルのコピー。

21:37:35 rdsora121@BILL> @diff_md5 test_dir hoge.log.bak hoge.log.gz.bak Src : DCE17181C95EACE997F45A2537BC1DA8 Dest: 6398E040E157B4A0CEF50FCF45C76FF7 -- Difference found. -- PL/SQLプロシージャが正常に完了しました。

圧縮したログファイルとそのコピーの比較。同じでなにより：）

21:38:15 rdsora121@BILL> @diff_md5 test_dir hoge.log.gz hoge.log.gz.bak Src : 6398E040E157B4A0CEF50FCF45C76FF7 Dest: 6398E040E157B4A0CEF50FCF45C76FF7 -- No difference found. -- PL/SQLプロシージャが正常に完了しました。

異なるファイルの比較、どちらもログファイルですが、内容がことなります。

21:38:51 rdsora121@BILL> @cat_file test_dir hoge.log TEXT ------------------------------------------------------------------------------------------ マスター表"BILL"."SYS_IMPORT_TABLE_01"は正常にロード/アンロードされました "BILL"."SYS_IMPORT_TABLE_01"を起動しています: オブジェクト型TABLE_EXPORT/TABLE/TABLEの処理中ですオブジェクト型TABLE_EXPORT/TABLE/TABLE_DATAの処理中です . . "SCOTT"."HOGE" 1.008 GB 270000行がインポートされましたオブジェクト型TABLE_EXPORT/TABLE/INDEX/INDEXの処理中ですオブジェクト型TABLE_EXPORT/TABLE/CONSTRAINT/CONSTRAINTの処理中ですオブジェクト型TABLE_EXPORT/TABLE/INDEX/STATISTICS/INDEX_STATISTICSの処理中ですオブジェクト型TABLE_EXPORT/TABLE/STATISTICS/TABLE_STATISTICSの処理中ですオブジェクト型TABLE_EXPORT/TABLE/STATISTICS/MARKERの処理中ですジョブ"BILL"."SYS_IMPORT_TABLE_01"が月 9月 24 04:05:17 2018 elapsed 0 00:00:52で正常に完了しました 11行が選択されました。 21:39:38 rdsora121@BILL> @cat_file test_dir hoge.log.bak TEXT ------------------------------------------------------------------------------------------ "BILL"."EXPTABLE_HOGE"を起動しています: BLOCKSメソッドを使用して見積り中です... オブジェクト型TABLE_EXPORT/TABLE/TABLE_DATAの処理中です BLOCKSメソッドを使用した見積り合計: 2.125 GB オブジェクト型TABLE_EXPORT/TABLE/TABLEの処理中ですオブジェクト型TABLE_EXPORT/TABLE/INDEX/INDEXの処理中ですオブジェクト型TABLE_EXPORT/TABLE/CONSTRAINT/CONSTRAINTの処理中ですオブジェクト型TABLE_EXPORT/TABLE/INDEX/STATISTICS/INDEX_STATISTICSの処理中ですオブジェクト型TABLE_EXPORT/TABLE/STATISTICS/TABLE_STATISTICSの処理中ですオブジェクト型TABLE_EXPORT/TABLE/STATISTICS/MARKERの処理中です . . "SCOTT"."HOGE" 1.008 GB 270000行がエクスポートされましたマスター表"BILL"."EXPTABLE_HOGE"は正常にロード/アンロードされました ****************************************************************************** BILL.EXPTABLE_HOGEに設定されたダンプ・ファイルは次のとおりです: /rdsdbdata/userdirs/01/hoge.dmp ジョブ"BILL"."EXPTABLE_HOGE"が日 9月 23 05:36:33 2018 elapsed 0 00:00:35で正常に完了しました 16行が選択されました。 21:39:48 rdsora121@BILL> @diff_md5 test_dir hoge.log hoge.log.bak Src : 6DA2D7C6150A9C8ACD60D95D6A61C1B5 Dest: DCE17181C95EACE997F45A2537BC1DA8 -- Difference found. -- PL/SQLプロシージャが正常に完了しました。

スクリプトは以下の通り。MD5の比較には、UTL_RAW.COMPARE関数を利用しています。

21:40:05 rdsora121@BILL> !cat diff_md5.sql SET VERIFY OFF SET SERVEROUTPUT ON FORMAT WRAPPED DECLARE vDirectoryName VARCHAR2(30); vSrcFileName VARCHAR2(60); vDestFileName VARCHAR2(60); vSrcMd5 RAW(16); vDestMd5 RAW(16); PROCEDURE close_bfile ( iBfile IN OUT NOCOPY BFILE ) IS BEGIN IF DBMS_LOB.ISOPEN(iBfile) = 1 THEN DBMS_LOB.CLOSE(iBfile); END IF; END close_bfile; FUNCTION md5 ( iDirectoryName IN VARCHAR2 , iFileName IN VARCHAR2 ) RETURN RAW IS vBfile BFILE; vBlob BLOB; vMd5 RAW(16); BEGIN vBFile := BFILENAME(UPPER(iDirectoryName), iFileName); DBMS_LOB.OPEN(vBFile); DBMS_LOB.CREATETEMPORARY( lob_loc => vBlob , cache => false , dur => DBMS_LOB.SESSION ); DBMS_LOB.LOADFROMFILE( dest_lob => vBlob , src_lob => vBFile , amount => DBMS_LOB.GETLENGTH(vBFile) , dest_offset => 1 , src_offset => 1 ); vMd5 := DBMS_CRYPTO.HASH(vBlob, DBMS_CRYPTO.HASH_MD5); DBMS_LOB.FREETEMPORARY(vBlob); close_bfile(vBFile); RETURN vMd5; EXCEPTION WHEN OTHERS THEN DBMS_LOB.FREETEMPORARY(vBlob); close_bfile(vBFile); RAISE; END md5; BEGIN vDirectoryName := UPPER('&1'); vSrcFileName := '&2'; vDestFileName := '&3'; vSrcMd5 := md5(vDirectoryName, vSrcFileName); vDestMd5 := md5(vDirectoryName, vDestFileName); DBMS_OUTPUT.PUT_LINE('Src : '||vSrcMd5); DBMS_OUTPUT.PUT_LINE('Dest: '||vDestMd5); IF UTL_RAW.COMPARE(r1 => vSrcMd5, r2 => vDestMd5) = 0 THEN DBMS_OUTPUT.PUT_LINE('-- No difference found. --'); ELSE DBMS_OUTPUT.PUT_LINE('-- Difference found. --'); END IF; EXCEPTION WHEN OTHERS THEN DBMS_OUTPUT.PUT_LINE(SQLERRM()||':'||SQLCODE()); RAISE; END; / UNDEFINE 1 UNDEFINE 2 UNDEFINE 3 SET SERVEROUTPUT OFF SET VERIFY ON

たぶん、これで終わりなはず。（なにか浮かばなければw）

Previously on Mac De Oracle

・RDS Oracle 雑多なメモ#1 / FAQ
・RDS Oracle 雑多なメモ#2 / FAQ
・RDS Oracle 雑多なメモ#3 / FAQ
・RDS Oracle 雑多なメモ#4 / FAQ
・RDS Oracle 雑多なメモ#5 / FAQ
・RDS Oracle 雑多なメモ#6 / FAQ
・RDS Oracle 雑多なメモ#7 / FAQ
・RDS Oracle 雑多なメモ#8 / FAQ
・RDS Oracle 雑多なメモ#9 / FAQ
・RDS Oracle 雑多なメモ#10 / FAQ
・RDS Oracle 雑多なメモ#11 / FAQ
・RDS Oracle 雑多なメモ#12 / FAQ
・RDS Oracle 雑多なメモ#13 / FAQ
・RDS Oracle 雑多なメモ#14 - おまけ / FAQ

投稿日時 2018年9月28日 (金) 00時00分 PL/SQL, FAQ, SQL, Oracle Database 11g Release 2, Oracle Database 12c release 1, AWS, RDS | 固定リンク | 0 | コメント (0) | トラックバック (0)

2018年9月27日 (木)

RDS Oracle 雑多なメモ#14 - おまけ　/ FAQ

ということで、done ってしておきながら、おまけ（得意技w）です。

RDS Oracle限定というわけではなくなってきましたがw 勢いでさらに追加。

手作りのcpっぽいスクリプトなので、バグってないか少し不安w ということで、オリジナルファイルと同じなのか確認できるようにメッセージダイジェストを取得するスクリプトも作成しましたw

21:14:43 rdsora121@BILL> @list_dir DIRECTORY_NAME DIRECTORY_PATH ---------------------------------------- ---------------------------------------------------------------------- ADUMP /rdsdbdata/log/audit BDUMP /rdsdbdata/log/trace DATA_PUMP_DIR /rdsdbdata/datapump HOGE_DIR /rdsdbdata/userdirs/02 OPATCH_INST_DIR /rdsdbbin/oracle/OPatch OPATCH_LOG_DIR /rdsdbbin/oracle/QOpatch OPATCH_SCRIPT_DIR /rdsdbbin/oracle/QOpatch TEST_DIR /rdsdbdata/userdirs/01 8行が選択されました。 21:14:48 rdsora121@BILL> @ls_dir test_dir FILENAME TYPE FILESIZE MTIME ---------------------------------------------------------------------- ---------- ---------- -------- hoge.dmp.gz file 2603349 18-09-24 hoge.log.gz file 512 18-09-24 hoge.dmp.bak file 1083412480 18-09-24 hoge.dmp.gz.bak file 2603349 18-09-24 hoge.log.bak file 1202 18-09-24 hoge.log.gz.bak file 512 18-09-24 01/ directory 4096 18-09-24 hoge.dmp file 1083412480 18-09-24 hoge.log file 904 18-09-24 9行が選択されました。

ダンプファイルを圧縮ファイル、ログファイル、ダンプファイルなどなど、MD5が取得できるようになりました。ファイルが壊れてないか確認しやすい:)

21:14:55 rdsora121@BILL> @check_md5 test_dir hoge.dmp.gz TEST_DIR/hoge.dmp.gz MD5 : D2CB26A7E75C9725F00C30A9280C1599 PL/SQLプロシージャが正常に完了しました。 21:15:32 rdsora121@BILL> @check_md5 test_dir hoge.dmp.gz.bak TEST_DIR/hoge.dmp.gz.bak MD5 : D2CB26A7E75C9725F00C30A9280C1599 PL/SQLプロシージャが正常に完了しました。 21:15:50 rdsora121@BILL> @check_md5 test_dir hoge.log TEST_DIR/hoge.log MD5 : 6DA2D7C6150A9C8ACD60D95D6A61C1B5 PL/SQLプロシージャが正常に完了しました。 21:16:26 rdsora121@BILL> @check_md5 test_dir hoge.dmp TEST_DIR/hoge.dmp MD5 : 1B84C9E09F13A4FDC6EF2F03137C0338 PL/SQLプロシージャが正常に完了しました。 21:18:02 rdsora121@BILL> @check_md5 test_dir hoge.dmp.bak TEST_DIR/hoge.dmp.bak MD5 : 1B84C9E09F13A4FDC6EF2F03137C0338 PL/SQLプロシージャが正常に完了しました。

ざっくり作ったスクリプトは以下の通り。BFILEからファイルを読み込み、一時BLOBとしてBFILEからロード、MD5取得というながれです。
(オンプレでもそのまま使える内容にはなっちゃいましたが、勢いで作ったので：）

21:18:50 rdsora121@BILL> !cat check_md5.sql SET VERIFY OFF SET SERVEROUTPUT ON FORMAT WRAPPED DECLARE vSrcfile BFILE; vSrcBlob BLOB; vSrcDirectoryName VARCHAR2(30); vSrcFileName VARCHAR2(60); vSrcFileSize PLS_INTEGER; vSrcFileMd5 RAW(16); PROCEDURE close_bfile ( iBfile IN OUT NOCOPY BFILE ) IS BEGIN IF DBMS_LOB.ISOPEN(iBfile) = 1 THEN DBMS_LOB.CLOSE(iBfile); END IF; END close_bfile; BEGIN vSrcDirectoryName := UPPER('&1'); vSrcFileName := '&2'; vSrcFile := BFILENAME(UPPER(vSrcDirectoryName), vSrcFileName); DBMS_LOB.OPEN(vSrcFile); vSrcFileSize := DBMS_LOB.GETLENGTH(vSrcFile); DBMS_LOB.CREATETEMPORARY ( lob_loc => vSrcBlob , cache => false , dur => DBMS_LOB.SESSION ); DBMS_LOB.LOADFROMFILE ( dest_lob => vSrcBlob , src_lob => vSrcFile , amount => vSrcFileSize , dest_offset => 1 , src_offset => 1 ); vSrcFileMd5 := DBMS_CRYPTO.HASH(vSrcBlob, DBMS_CRYPTO.HASH_MD5); DBMS_LOB.FREETEMPORARY(vSrcBlob); close_bfile(vSrcFile); DBMS_OUTPUT.PUT_LINE( vSrcDirectoryName ||'/'||vSrcFileName ||' MD5 : '||vSrcFileMd5 ); EXCEPTION WHEN OTHERS THEN DBMS_LOB.FREETEMPORARY(vSrcBlob); close_bfile(vSrcFile); RAISE; END; / UNDEFINE 1 UNDEFINE 2 SET SERVEROUTPUT OFF SET VERIFY ON

ということで、done... これを元にまたまにか作るかもしれない、作らないかもしれないw

Previously on Mac De Oracle

・RDS Oracle 雑多なメモ#1 / FAQ
・RDS Oracle 雑多なメモ#2 / FAQ
・RDS Oracle 雑多なメモ#3 / FAQ
・RDS Oracle 雑多なメモ#4 / FAQ
・RDS Oracle 雑多なメモ#5 / FAQ
・RDS Oracle 雑多なメモ#6 / FAQ
・RDS Oracle 雑多なメモ#7 / FAQ
・RDS Oracle 雑多なメモ#8 / FAQ
・RDS Oracle 雑多なメモ#9 / FAQ
・RDS Oracle 雑多なメモ#10 / FAQ
・RDS Oracle 雑多なメモ#11 / FAQ
・RDS Oracle 雑多なメモ#12 / FAQ
・RDS Oracle 雑多なメモ#13 / FAQ

投稿日時 2018年9月27日 (木) 00時00分 PL/SQL, FAQ, SQL, Oracle Database 11g Release 2, Oracle Database 12c release 1, AWS, RDS | 固定リンク | 0 | コメント (0) | トラックバック (0)

2018年9月26日 (水)

RDS Oracle 雑多なメモ#13 / FAQ

メモの続きです。
前回は、圧縮したテキストファイルとダンプファイル（バイナリファイル）を解凍するスクリプトを実行したところまででした。

やっとここまできたw

今回は、解凍したファイルが使えるかなど内容確認をしてみたいと思います。

まず、解凍したログファイル（テキストファイル）の内容を確認
問題なさそうですね。

12:35:01 rdsora121@BILL> @cat_file test_dir hoge.log TEXT ---------------------------------------------------------------------------------------- "BILL"."EXPTABLE_HOGE"を起動しています: BLOCKSメソッドを使用して見積り中です... オブジェクト型TABLE_EXPORT/TABLE/TABLE_DATAの処理中です BLOCKSメソッドを使用した見積り合計: 2.125 GB オブジェクト型TABLE_EXPORT/TABLE/TABLEの処理中ですオブジェクト型TABLE_EXPORT/TABLE/INDEX/INDEXの処理中ですオブジェクト型TABLE_EXPORT/TABLE/CONSTRAINT/CONSTRAINTの処理中ですオブジェクト型TABLE_EXPORT/TABLE/INDEX/STATISTICS/INDEX_STATISTICSの処理中ですオブジェクト型TABLE_EXPORT/TABLE/STATISTICS/TABLE_STATISTICSの処理中ですオブジェクト型TABLE_EXPORT/TABLE/STATISTICS/MARKERの処理中です . . "SCOTT"."HOGE" 1.008 GB 270000行がエクスポートされましたマスター表"BILL"."EXPTABLE_HOGE"は正常にロード/アンロードされました ****************************************************************************** BILL.EXPTABLE_HOGEに設定されたダンプ・ファイルは次のとおりです: /rdsdbdata/userdirs/01/hoge.dmp ジョブ"BILL"."EXPTABLE_HOGE"が日 9月 23 05:36:33 2018 elapsed 0 00:00:35で正常に完了しました 16行が選択されました。

解凍したダンプファイルをインポートして確認する前に、元のオブジェクトの確認後、削除しておきます。

12:37:17 rdsora121@BILL> set linesize 80 12:37:20 rdsora121@BILL> desc scott.hoge 名前 NULL? 型 ----------------------------------------- -------- ---------------------------- ID NOT NULL NUMBER FOO VARCHAR2(4000) 12:37:25 rdsora121@BILL> select count(1) from scott.hoge; COUNT(1) ---------- 270000 12:39:07 rdsora121@BILL> r 1 select 2 segment_name 3 ,sum(bytes)/1024/1024/1024 "GB" 4 from 5 dba_segments 6 where 7 owner='SCOTT' 8 and segment_name in ('HOGE','PK_HOGE') 9 group by 10* segment_name SEGMENT_NAME GB ------------------------------ ---------- PK_HOGE .004882813 HOGE 2.125 12:39:17 rdsora121@BILL> set linesize 400 12:39:21 rdsora121@BILL> 12:40:02 rdsora121@BILL> drop table scott.hoge purge; 表が削除されました。

dbms_datapumpパッケージを利用したスクリプトを作成してインポート可能か確認 :)

13:03:40 rdsora121@BILL> @import_table test_dir hoge scott hoge マスター表"BILL"."SYS_IMPORT_TABLE_01"は正常にロード/アンロードされました "BILL"."SYS_IMPORT_TABLE_01"を起動しています: オブジェクト型TABLE_EXPORT/TABLE/TABLEの処理中ですオブジェクト型TABLE_EXPORT/TABLE/TABLE_DATAの処理中です . . "SCOTT"."HOGE" 1.008 GB 270000行がインポートされましたオブジェクト型TABLE_EXPORT/TABLE/INDEX/INDEXの処理中ですオブジェクト型TABLE_EXPORT/TABLE/CONSTRAINT/CONSTRAINTの処理中ですオブジェクト型TABLE_EXPORT/TABLE/INDEX/STATISTICS/INDEX_STATISTICSの処理中ですオブジェクト型TABLE_EXPORT/TABLE/STATISTICS/TABLE_STATISTICSの処理中ですオブジェクト型TABLE_EXPORT/TABLE/STATISTICS/MARKERの処理中ですジョブ"BILL"."SYS_IMPORT_TABLE_01"が月 9月 24 04:05:17 2018 elapsed 0 00:00:52で正常に完了しました PL/SQLプロシージャが正常に完了しました。

インポート成功！！！　表などの確認！

13:05:54 rdsora121@BILL> set linesize 80 13:06:00 rdsora121@BILL> desc scott.hoge 名前 NULL? 型 ----------------------------------------- -------- ---------------------------- ID NOT NULL NUMBER FOO VARCHAR2(4000) 13:06:04 rdsora121@BILL> select count(1) from scott.hoge; COUNT(1) ---------- 270000 13:07:27 rdsora121@BILL> r 1 select 2 segment_name 3 ,sum(bytes)/1024/1024/1024 "GB" 4 from 5 dba_segments 6 where 7 owner='SCOTT' 8 and segment_name in ('HOGE','PK_HOGE') 9 group by 10* segment_name SEGMENT_NAME GB ------------------------------ ---------- PK_HOGE .004882813 HOGE 2.125

スクリプトは以下の通り。　表モードのインポートをハードコードしていますが、そのあたりパラメータ化すればそこそこ使いやすくなりますかね。。

13:08:03 rdsora121@BILL> !cat import_table.sql SET VERIFY OFF SET SERVEROUTPUT ON DECLARE v4Debug VARCHAR2(50); cDirectory CONSTANT VARCHAR2(30) := UPPER('&1'); cDumpFileName CONSTANT VARCHAR2(64) := '&2'||'.dmp'; cLogFileName CONSTANT VARCHAR2(64) := '&2'||'.log'; cSchemaName CONSTANT VARCHAR2(30) := UPPER('&3'); cTableName CONSTANT VARCHAR2(30) := UPPER('&4'); i NUMBER; vDataPumpJobHandle NUMBER; vProgress_ratio NUMBER; vJobState VARCHAR2(30); oLogEntry ku$_LogEntry; oStatus ku$_Status; BEGIN DBMS_OUTPUT.ENABLE; v4Debug := 'OPEN'; vDataPumpJobHandle := DBMS_DATAPUMP.OPEN ( operation => 'IMPORT' ,job_mode => 'TABLE' ,remote_link => NULL ); v4Debug := 'ADD_FILE - dumpfile'; DBMS_DATAPUMP.ADD_FILE ( handle => vDataPumpJobHandle ,filename => cDumpFileName ,directory => cDirectory ,filetype => DBMS_DATAPUMP.KU$_FILE_TYPE_DUMP_FILE ); v4Debug := 'ADD_FILE - logfile'; DBMS_DATAPUMP.ADD_FILE ( handle => vDataPumpJobHandle ,filename => cLogFileName ,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 => '''' || cSchemaName || '''' ); v4Debug := 'METADATA_FILTER - table name'; DBMS_DATAPUMP.METADATA_FILTER ( handle => vDataPumpJobHandle ,name => 'NAME_LIST' ,value => '''' || cTableName || '''' ); v4Debug := 'START_JOB'; DBMS_DATAPUMP.START_JOB ( handle => vDataPumpJobHandle ); 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 ); 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; DBMS_DATAPUMP.DETACH(vDataPumpJobHandle); EXCEPTION WHEN OTHERS THEN DBMS_OUTPUT.PUT_LINE(sqlerrm()); DBMS_OUTPUT.PUT_LINE(v4Debug); RAISE; END; / UNDEFINE 1 UNDEFINE 2 UNDEFINE 3 UNDEFINE 4 SET SERVEROUTPUT OFF SET VERIFY ON

ということで、ひとまず、RDS Oracleの雑多なメモ　done :)

Previously on Mac De Oracle

・RDS Oracle 雑多なメモ#1 / FAQ
・RDS Oracle 雑多なメモ#2 / FAQ
・RDS Oracle 雑多なメモ#3 / FAQ
・RDS Oracle 雑多なメモ#4 / FAQ
・RDS Oracle 雑多なメモ#5 / FAQ
・RDS Oracle 雑多なメモ#6 / FAQ
・RDS Oracle 雑多なメモ#7 / FAQ
・RDS Oracle 雑多なメモ#8 / FAQ
・RDS Oracle 雑多なメモ#9 / FAQ
・RDS Oracle 雑多なメモ#10 / FAQ
・RDS Oracle 雑多なメモ#11 / FAQ
・RDS Oracle 雑多なメモ#12 / FAQ

投稿日時 2018年9月26日 (水) 00時00分 PL/SQL, FAQ, SQL, Oracle Database 11g Release 2, Cloud computing, Oracle Database 12c release 1, AWS, RDS | 固定リンク | 0 | コメント (0) | トラックバック (0)

2018年9月25日 (火)

RDS Oracle 雑多なメモ#12 / FAQ

メモの続きです。

さて、前回、cpっぽいスクリプトの問題を改善したので今回は、圧縮したファイルを解凍するスクリプトを作ろうと思います。

前回の操作でファイルが増えて見づらくなったので、解凍に必要な最小限のファイルだけに整理します

12:20:19 rdsora121@BILL> @ls_dir test_dir FILENAME TYPE FILESIZE MTIME ---------------------------------------------------------------------- ---------- ---------- -------- hoge.log file 1202 18-09-23 hoge.dmp file 1083412480 18-09-23 hoge.dmp.gz file 2603349 18-09-24 hoge.log.gz file 512 18-09-24 hoge.dmp.bak file 1083412480 18-09-24 hoge.dmp.gz.bak file 2603349 18-09-24 hoge.log.bak file 1202 18-09-24 hoge.log.gz.bak file 512 18-09-24 01/ directory 4096 18-09-24 9行が選択されました。 12:20:25 rdsora121@BILL> @rm_file test_dir hoge.log TEST_DIR/hoge.log removed. PL/SQLプロシージャが正常に完了しました。 12:21:49 rdsora121@BILL> @rm_file test_dir hoge.dmp TEST_DIR/hoge.dmp removed. PL/SQLプロシージャが正常に完了しました。 12:21:57 rdsora121@BILL> @ls_dir test_dir FILENAME TYPE FILESIZE MTIME ---------------------------------------------------------------------- ---------- ---------- -------- hoge.dmp.gz file 2603349 18-09-24 hoge.log.gz file 512 18-09-24 hoge.dmp.bak file 1083412480 18-09-24 hoge.dmp.gz.bak file 2603349 18-09-24 hoge.log.bak file 1202 18-09-24 hoge.log.gz.bak file 512 18-09-24 01/ directory 4096 18-09-24 7行が選択されました。

では圧縮したテキストファイルとダンプファイル（バイナリファイル）を解凍してみます。

12:22:06 rdsora121@BILL> @gunzip_file test_dir hoge.log.gz TEST_DIR/hoge.log.gz uncompressed to hoge.log (1202 bytes) PL/SQLプロシージャが正常に完了しました。 12:22:44 rdsora121@BILL> @gunzip_file test_dir hoge.dmp.gz TEST_DIR/hoge.dmp.gz uncompressed to hoge.dmp (1083412480 bytes) PL/SQLプロシージャが正常に完了しました。 12:23:04 rdsora121@BILL> @ls_dir test_dir FILENAME TYPE FILESIZE MTIME ---------------------------------------------------------------------- ---------- ---------- -------- hoge.dmp.gz file 2603349 18-09-24 hoge.log.gz file 512 18-09-24 hoge.dmp.bak file 1083412480 18-09-24 hoge.dmp.gz.bak file 2603349 18-09-24 hoge.log.bak file 1202 18-09-24 hoge.log.gz.bak file 512 18-09-24 hoge.log file 1202 18-09-24 01/ directory 4096 18-09-24 hoge.dmp file 1083412480 18-09-24 9行が選択されました。

できた！！！

今回の利用した解凍スクリプトも元は12年前のエントリで利用したコードのほぼ再利用です。
Mac De Oracle (PL/SQL De UNCOMPRESS)

12:24:22 rdsora121@BILL> !cat gunzip_file.sql SET VERIFY OFF SET SERVEROUTPUT ON DECLARE vSrcGzippedFile BFILE; vUncompressedBlob BLOB; vDirectoryName VARCHAR2(30); vSrcGzippedFileName VARCHAR2(60); vDestFileName VARCHAR2(60); VUncompressedSize PLS_INTEGER; PROCEDURE close_bfile ( iBfile IN OUT NOCOPY BFILE ) IS BEGIN IF DBMS_LOB.ISOPEN(iBfile) = 1 THEN DBMS_LOB.CLOSE(iBfile); END IF; END close_bfile; PROCEDURE write_blob_to_file ( iDirectoryName IN VARCHAR2, iFileName IN VARCHAR2, iSrcBlob IN OUT NOCOPY BLOB ) IS vFile UTL_FILE.FILE_TYPE; BEGIN vFile := UTL_FILE.FOPEN( UPPER(iDirectoryName), iFileName, 'wb', 32767 ); DECLARE cChunkSize CONSTANT PLS_INTEGER := 32767; vBuffer RAW(32767); vAmount PLS_INTEGER := cChunkSize; vNumOfChunk PLS_INTEGER; BEGIN vNumOfChunk := CEIL(DBMS_LOB.GETLENGTH(iSrcBlob)/cChunkSize); FOR chunk# IN 1..vNumOfChunk LOOP DBMS_LOB.READ( iSrcBlob, vAmount, (cChunkSize * (chunk# - 1)) + 1, /*offet*/ vBuffer ); UTL_FILE.PUT_RAW(vFile, vBuffer, TRUE); END LOOP; END; UTL_FILE.FCLOSE(vFile); END write_blob_to_file; BEGIN vDirectoryName := UPPER('&1'); vSrcGzippedFileName := '&2'; vDestFileName := SUBSTR('&2', 1, INSTR('&2', '.gz') - 1); vSrcGzippedFile := BFILENAME(UPPER(vDirectoryName), vSrcGzippedFileName); DBMS_LOB.OPEN(vSrcGzippedFile); vUncompressedBlob := UTL_COMPRESS.LZ_UNCOMPRESS(vSrcGzippedFile); vUncompressedSize := DBMS_LOB.GETLENGTH(vUncompressedBlob); write_blob_to_file( UPPER(vDirectoryName), vDestFileName, vUncompressedBlob ); DBMS_LOB.FREETEMPORARY(vUncompressedBlob); close_bfile(vSrcGzippedFile); DBMS_OUTPUT.PUT_LINE( vDirectoryName||'/' ||vSrcGzippedFileName ||' uncompressed to ' ||vDestFileName ||' ('||vUncompressedSize||' bytes)' ); EXCEPTION WHEN OTHERS THEN DBMS_LOB.FREETEMPORARY(vUncompressedBlob); close_bfile(vSrcGzippedFile); RAISE; END; / UNDEFINE 1 UNDEFINE 2 SET SERVEROUTPUT OFF SET VERIFY ON

ということで、次回、解凍したテキストファイルの内容確認と、解凍したダンプファイルからインポートして内容確認へつづく :)

Previously on Mac De Oracle

・RDS Oracle 雑多なメモ#1 / FAQ
・RDS Oracle 雑多なメモ#2 / FAQ
・RDS Oracle 雑多なメモ#3 / FAQ
・RDS Oracle 雑多なメモ#4 / FAQ
・RDS Oracle 雑多なメモ#5 / FAQ
・RDS Oracle 雑多なメモ#6 / FAQ
・RDS Oracle 雑多なメモ#7 / FAQ
・RDS Oracle 雑多なメモ#8 / FAQ
・RDS Oracle 雑多なメモ#9 / FAQ
・RDS Oracle 雑多なメモ#10 / FAQ
・RDS Oracle 雑多なメモ#11 / FAQ

投稿日時 2018年9月25日 (火) 00時00分 PL/SQL, FAQ, SQL, Oracle Database 11g Release 2, Oracle Database 12c release 1, AWS, RDS | 固定リンク | 0 | コメント (0) | トラックバック (0)

2018年9月24日 (月)

RDS Oracle 雑多なメモ#11 / FAQ

メモの続きです。

はじめに、
ごねんなさい、ごねんなさい

RDS Oracle 雑多なメモ#6 / FAQ
で作成したUTL_FILE.FCOPYを利用したcpっぽいスクリプトはtextファイルにしか対応できません。
理由は、UTL_FILE.FCOPYプロシージャ自体がtextファイル向けでバイナリファイルに対応していないことが理由ではあるのですが、textファイルしかコピーできないのもなんなので、バイナリファイルにも対応したバージョンに変更したいと思います。

RDS Oracle 雑多なメモ#6 / FAQで作成したスクリプトは今回作成したスクリプトで置き換えていただければ、m(_ _)m

前々回作成したダンプファイル(バイナリファイル)やテキストファイルを使ってみようと思います。

utl_file.fcopyプロシージャでコピーできる例（テキストファイル）

10:48:50 rdsora121@BILL> @ls_dir test_dir FILENAME TYPE FILESIZE MTIME ---------------------------------------------------------------------- ---------- ---------- -------- hoge.dmp file 1083412480 18-09-23 hoge.log file 1202 18-09-23 hoge.dmp.gz file 2603349 18-09-24 hoge.log.gz file 512 18-09-24 01/ directory 4096 18-09-24 11:14:42 rdsora121@BILL> @cp_file test_dir hoge.log test_dir hoge.log.bak1 source file : test_dir/hoge.log dest file : test_dir/hoge.log.bak1 copied. PL/SQLプロシージャが正常に完了しました。 11:15:10 rdsora121@BILL> @ls_dir test_dir FILENAME TYPE FILESIZE MTIME ---------------------------------------------------------------------- ---------- ---------- -------- hoge.dmp file 1083412480 18-09-23 hoge.log file 1202 18-09-23 hoge.dmp.gz file 2603349 18-09-24 hoge.log.gz file 512 18-09-24 01/ directory 4096 18-09-24 hoge.log.bak1 file 1202 18-09-24 6行が選択されました。

utl_file.fcopyプロシージャでコピーできない例（バイナリファイル）
エラーが発生し、コピー途中のゴミファイルが作成されていまいます。。。。これはこまる。。

11:15:10 rdsora121@BILL> @ls_dir test_dir FILENAME TYPE FILESIZE MTIME ---------------------------------------------------------------------- ---------- ---------- -------- hoge.dmp file 1083412480 18-09-23 hoge.log file 1202 18-09-23 hoge.dmp.gz file 2603349 18-09-24 hoge.log.gz file 512 18-09-24 01/ directory 4096 18-09-24 hoge.log.bak1 file 1202 18-09-24 11:16:51 rdsora121@BILL> @cp_file test_dir hoge.dmp test_dir hoge.dmp.bak1 -29284:ORA-29284: ファイル読取りエラーが発生しました。 PL/SQLプロシージャが正常に完了しました。 11:17:20 rdsora121@BILL> @ls_dir test_dir FILENAME TYPE FILESIZE MTIME ---------------------------------------------------------------------- ---------- ---------- -------- hoge.dmp file 1083412480 18-09-23 hoge.log file 1202 18-09-23 hoge.dmp.gz file 2603349 18-09-24 hoge.log.gz file 512 18-09-24 hoge.log.bak1 file 1202 18-09-24 hoge.dmp.bak1 file 45093 18-09-24 01/ directory 4096 18-09-24 7行が選択されました。

RDS Oracle 雑多なメモ#6 / FAQで作成したcp_file.sqlのコードは以下の通り
これでバイナリーファイルもコピーできると嬉しいのにね〜。昔からできないのでしかたない。。

11:25:20 rdsora121@BILL> !cat cp_file.sql set verify off set serveroutput on format wrapped BEGIN UTL_FILE.FCOPY( src_location => UPPER('&1') ,src_filename => '&2' ,dest_location => UPPER('&3') ,dest_filename => '&4' ); DBMS_OUTPUT.PUT_LINE(' '); DBMS_OUTPUT.PUT_LINE('source file : &1/&2'); DBMS_OUTPUT.PUT_LINE('dest file : &3/&4 copied.'); EXCEPTION WHEN OTHERS THEN DBMS_OUTPUT.PUT_LINE(SQLCODE()||':'||SQLERRM()); END; / undefine 1 undefine 2 undefine 3 undefine 4 set verify on set serveroutput off

他の手はないかな？？？　あ、dbms_file_transfer.copy_fileプロシージャを使ったらどうか？

ただし、バイナリファイルをうまくコピーできるようになりましたが、このプロシージャにはいくつか制限があります。
Oracle® Database PL/SQLパッケージおよびタイプ・リファレンス 12c リリース1 (12.1) DBMS_FILE_TRANSFER
コピーされるファイルのサイズは512バイトの倍数である必要があります。
コピーされるファイルのサイズは、2TB以下である必要があります。
コピーの進行状況を監視するには、V$SESSION_LONGOPS動的パフォーマンス・ビューを参照します。

コピーできない例
512バイトの倍数でないバイナリファイルをコピーしようとすると。。。

11:17:20 rdsora121@BILL> @ls_dir test_dir FILENAME TYPE FILESIZE MTIME ---------------------------------------------------------------------- ---------- ---------- -------- hoge.dmp file 1083412480 18-09-23 hoge.log file 1202 18-09-23 hoge.dmp.gz file 2603349 18-09-24 hoge.log.gz file 512 18-09-24 hoge.log.bak1 file 1202 18-09-24 hoge.dmp.bak1 file 45093 18-09-24 01/ directory 4096 18-09-24 7行が選択されました。 11:18:02 rdsora121@BILL> @cp_transferfile test_dir hoge.dmp.gz test_dir hoge.dmp.gz.bak1 -19505:ORA-19505: ファイル"/rdsdbdata/userdirs/01/hoge.dmp.gz"の識別に失敗しました。 ORA-27046: ファイル・サイズが論理ブロック・サイズの倍数ではありません。 Additional information: 1 PL/SQLプロシージャが正常に完了しました。

うまくコピーできる例
512バイトの倍数サイズのバイナリファイルのコピー

11:23:12 rdsora121@BILL> @cp_transferfile test_dir hoge.dmp test_dir hoge.dmp.bak2 source file : test_dir/hoge.dmp dest file : test_dir/hoge.dmp.bak2 copied. PL/SQLプロシージャが正常に完了しました。 11:24:01 rdsora121@BILL> @ls_dir test_dir FILENAME TYPE FILESIZE MTIME ---------------------------------------------------------------------- ---------- ---------- -------- hoge.dmp file 1083412480 18-09-23 hoge.log file 1202 18-09-23 hoge.dmp.gz file 2603349 18-09-24 hoge.log.gz file 512 18-09-24 hoge.log.bak1 file 1202 18-09-24 hoge.dmp.bak1 file 45093 18-09-24 01/ directory 4096 18-09-24 hoge.dmp.bak2 file 1083412480 18-09-24 8行が選択されました。

dbms_transfer_fileパッケージを利用したコードは以下の通り
これも制限が多くなければコードも短くてうれしいわけなんですが。。。しかたなし

11:24:10 rdsora121@BILL> !cat cp_transferfile.sql set verify off set serveroutput on format wrapped BEGIN DBMS_FILE_TRANSFER.COPY_FILE( source_directory_object => UPPER('&1') ,source_file_name => '&2' ,destination_directory_object => UPPER('&3') ,destination_file_name => '&4' ); DBMS_OUTPUT.PUT_LINE(' '); DBMS_OUTPUT.PUT_LINE('source file : &1/&2'); DBMS_OUTPUT.PUT_LINE('dest file : &3/&4 copied.'); EXCEPTION WHEN OTHERS THEN DBMS_OUTPUT.PUT_LINE(SQLCODE()||':'||SQLERRM()); END; / undefine 1 undefine 2 undefine 3 undefine 4 set verify on set serveroutput off

制限もあるし、使いやすいような使いにくいような...
いろいろ消化不良状態。。。なので

スクリプト長くなってめんどくさいけど、この部分楽はできない模様なので、手作り決定！

最終的に、既存プロシージャにないのなら、作っちゃえ。ということで、cp_file.sqlを全面作り変えw ました。

11:32:13 rdsora121@BILL> @ls_dir test_dir FILENAME TYPE FILESIZE MTIME ---------------------------------------------------------------------- ---------- ---------- -------- hoge.dmp file 1083412480 18-09-23 hoge.log file 1202 18-09-23 hoge.dmp.gz file 2603349 18-09-24 hoge.log.gz file 512 18-09-24 01/ directory 4096 18-09-24 11:32:21 rdsora121@BILL> @cp_file test_dir hoge.dmp test_dir hoge.dmp.bak TEST_DIR/hoge.dmp (1083412480) to TEST_DIR/hoge.dmp.bak (1083412480) PL/SQLプロシージャが正常に完了しました。 11:33:07 rdsora121@BILL> @cp_file test_dir hoge.log test_dir hoge.log.bak TEST_DIR/hoge.log (1202) to TEST_DIR/hoge.log.bak (1202) PL/SQLプロシージャが正常に完了しました。 11:33:26 rdsora121@BILL> @cp_file test_dir hoge.dmp.gz test_dir hoge.dmp.gz.bak TEST_DIR/hoge.dmp.gz (2603349) to TEST_DIR/hoge.dmp.gz.bak (2603349) PL/SQLプロシージャが正常に完了しました。 11:33:42 rdsora121@BILL> @ls_dir test_dir FILENAME TYPE FILESIZE MTIME ---------------------------------------------------------------------- ---------- ---------- -------- hoge.log file 1202 18-09-23 hoge.dmp file 1083412480 18-09-23 hoge.dmp.gz file 2603349 18-09-24 hoge.log.gz file 512 18-09-24 hoge.dmp.bak file 1083412480 18-09-24 hoge.log.bak file 1202 18-09-24 01/ directory 4096 18-09-24 hoge.dmp.gz.bak file 2603349 18-09-24 8行が選択されました。

新、cp_file.sqlのスクリプトは以下の通り。基本的に、gzip_file.sql内部で利用していたバイナリファイルのハンドリング部分を抜き出した感じです。一部違うのは DBMS_LOB.CREATETEMPORARYで一時BLOBを読んでいるところ。BFILEからBLOBをロードして、出力先ファイルへ書き出しているかしょは圧縮で利用しているコードと同じです。最後に一時BLOBの解放をお忘れなく

11:34:21 rdsora121@BILL> !cat cp_file.sql SET VERIFY OFF SET SERVEROUTPUT ON FORMAT WRAPPED DECLARE vSrcfile BFILE; vSrcBlob BLOB; vSrcDirectoryName VARCHAR2(30); vDestDirectoryName VARCHAR2(30); vSrcFileName VARCHAR2(60); vDestFileName VARCHAR2(60); vSrcFileSize PLS_INTEGER; vDestFileSize PLS_INTEGER; PROCEDURE close_bfile ( iBfile IN OUT NOCOPY BFILE ) IS BEGIN IF DBMS_LOB.ISOPEN(iBfile) = 1 THEN DBMS_LOB.CLOSE(iBfile); END IF; END close_bfile; PROCEDURE write_blob_to_file ( iDirectoryName IN VARCHAR2 , iFileName IN VARCHAR2 , iSrcBlob IN OUT NOCOPY BLOB ) IS vFile UTL_FILE.FILE_TYPE; BEGIN vFile := UTL_FILE.FOPEN( UPPER(iDirectoryName) , iFileName , 'wb' , 32767 ); DECLARE cChunkSize CONSTANT PLS_INTEGER := 32767; vBuffer RAW(32767); vAmount PLS_INTEGER := cChunkSize; vNumOfChunk PLS_INTEGER; BEGIN vNumOfChunk := CEIL(DBMS_LOB.GETLENGTH(iSrcBlob)/cChunkSize); FOR chunk# IN 1..vNumOfChunk LOOP DBMS_LOB.READ( iSrcBlob , vAmount , (cChunkSize * (chunk# - 1)) + 1 /*offset*/ , vBuffer ); UTL_FILE.PUT_RAW(vFile, vBuffer, TRUE); END LOOP; END; UTL_FILE.FCLOSE(vFile); END write_blob_to_file; BEGIN vSrcDirectoryName := UPPER('&1'); vSrcFileName := '&2'; vDestDirectoryName := UPPER('&3'); vDestFileName := '&4'; vSrcFile := BFILENAME(UPPER(vSrcDirectoryName), vSrcFileName); DBMS_LOB.OPEN(vSrcFile); vSrcFileSize := DBMS_LOB.GETLENGTH(vSrcFile); DBMS_LOB.CREATETEMPORARY ( lob_loc => vSrcBlob , cache => false , dur => DBMS_LOB.SESSION ); DBMS_LOB.LOADFROMFILE ( dest_lob => vSrcBlob , src_lob => vSrcFile , amount => vSrcFileSize , dest_offset => 1 , src_offset => 1 ); vDestFileSize := DBMS_LOB.GETLENGTH(vSrcBlob); write_blob_to_file( UPPER(vDestDirectoryName) , vDestFileName , vSrcBlob ); DBMS_LOB.FREETEMPORARY(vSrcBlob); close_bfile(vSrcFile); DBMS_OUTPUT.PUT_LINE( vSrcDirectoryName||'/'||vSrcFileName||' ('||vDestFileSize||') to ' ||vDestDirectoryName||'/'||vDestFileName||' ('||vSrcFileSize||')' ); EXCEPTION WHEN OTHERS THEN DBMS_LOB.FREETEMPORARY(vSrcBlob); close_bfile(vSrcFile); RAISE; END; / UNDEFINE 1 UNDEFINE 2 UNDEFINE 3 UNDEFINE 4 SET SERVEROUTPUT OFF SET VERIFY ON

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

Previously on Mac De Oracle

・RDS Oracle 雑多なメモ#1 / FAQ
・RDS Oracle 雑多なメモ#2 / FAQ
・RDS Oracle 雑多なメモ#3 / FAQ
・RDS Oracle 雑多なメモ#4 / FAQ
・RDS Oracle 雑多なメモ#5 / FAQ
・RDS Oracle 雑多なメモ#6 / FAQ
・RDS Oracle 雑多なメモ#7 / FAQ
・RDS Oracle 雑多なメモ#8 / FAQ
・RDS Oracle 雑多なメモ#9 / FAQ
・RDS Oracle 雑多なメモ#10 / FAQ

投稿日時 2018年9月24日 (月) 12時11分 PL/SQL, FAQ, SQL, Oracle Database 11g Release 2, Oracle Database 12c release 1, AWS, RDS | 固定リンク | 0 | コメント (0) | トラックバック (0)

RDS Oracle 雑多なメモ#10 / FAQ

メモの続きです。
前回は、dbms_datapumpパッケージを利用してエクスポートを行うスクリプトを作成しました。
今回は、作成したダンプファイル（バイナリファイルでサイズは1GB越え）をutl_compressパッケージを利用して圧縮するスクリプトを作成します。

このネタ実は、12年前の古いネタが元になっています。
Mac De Oracle (PL/SQL De COMPRESS)
Mac De Oracle (PL/SQL De UNCOMPRESS)

ということで、RDS Oracleのディレクトリオブジェクトにエクポートしたダンプファイル（バイナリファイル）圧縮してみましょう。。動くのか？。。。

ディレクトリを確認

10:48:42 rdsora121@BILL> @list_dir DIRECTORY_NAME DIRECTORY_PATH ---------------------------------------- ---------------------------------------------------------------------- ADUMP /rdsdbdata/log/audit BDUMP /rdsdbdata/log/trace DATA_PUMP_DIR /rdsdbdata/datapump HOGE_DIR /rdsdbdata/userdirs/02 OPATCH_INST_DIR /rdsdbbin/oracle/OPatch OPATCH_LOG_DIR /rdsdbbin/oracle/QOpatch OPATCH_SCRIPT_DIR /rdsdbbin/oracle/QOpatch TEST_DIR /rdsdbdata/userdirs/01 8行が選択されました。

エクスポートしたダンプファイル（バイナリファイル）とログファイル（テキストファイル）が対象ディレクトリ以下にあることを確認

10:42:05 rdsora121@BILL> @ls_dir test_dir FILENAME TYPE FILESIZE MTIME ---------------------------------------------------------------------- ---------- ---------- -------- hoge.dmp file 1083412480 18-09-23 hoge.log file 1202 18-09-23 01/ directory 4096 18-09-24

まず、ダンプファイル（バイナリファイル）を圧縮します。ダンプファイルは圧縮効率がいいんですよね。なので転送する際には圧縮するのがオススメ
圧縮はうまくいった？ようですね。解凍スクリプト編で正常に解凍できるか確認する予定なのでしばしお待ちを。

10:46:00 rdsora121@BILL> @gzip_file test_dir hoge.dmp TEST_DIR/hoge.dmp compressed to hoge.dmp.gz(99.76%) PL/SQLプロシージャが正常に完了しました。

圧縮したファイルは、.gzの拡張子をつけて出力するようにしています。

10:46:23 rdsora121@BILL> @ls_dir test_dir FILENAME TYPE FILESIZE MTIME ---------------------------------------------------------------------- ---------- ---------- -------- hoge.dmp file 1083412480 18-09-23 hoge.log file 1202 18-09-23 hoge.dmp.gz file 2603349 18-09-24 01/ directory 4096 18-09-24

次に、テキストファイルも圧縮！

10:46:32 rdsora121@BILL> @gzip_file test_dir hoge.log TEST_DIR/hoge.log compressed to hoge.log.gz(57.4%) PL/SQLプロシージャが正常に完了しました。 10:46:51 rdsora121@BILL> @ls_dir test_dir FILENAME TYPE FILESIZE MTIME ---------------------------------------------------------------------- ---------- ---------- -------- hoge.dmp file 1083412480 18-09-23 hoge.log file 1202 18-09-23 hoge.dmp.gz file 2603349 18-09-24 hoge.log.gz file 512 18-09-24 001/ directory 4096 18-09-24

スクリプトは以下の通り、utl_compressパッケージを利用しています。バイナリファイルはBFILEから読み込み、圧縮、圧縮結果のバイナリは一時BLOBで返されるので、一時BLOBをバイナリファイルとして書き出しています。最後に一時BLOBを解放してあげてゴミ掃除という流れです。

10:46:58 rdsora121@BILL> !cat gzip_file.sql SET VERIFY OFF SET SERVEROUTPUT ON FORMAT WRAPPED DECLARE vSrcfile BFILE; vCompressedBlob BLOB; vDirectoryName VARCHAR2(30); vSrcFileName VARCHAR2(60); vDestFileName VARCHAR2(60); vSrcFileSize PLS_INTEGER; vDestFileSize PLS_INTEGER; PROCEDURE close_bfile ( iBfile IN OUT NOCOPY BFILE ) IS BEGIN IF DBMS_LOB.ISOPEN(iBfile) = 1 THEN DBMS_LOB.CLOSE(iBfile); END IF; END close_bfile; PROCEDURE write_blob_to_file ( iDirectoryName IN VARCHAR2, iFileName IN VARCHAR2, iSrcBlob IN OUT NOCOPY BLOB ) IS vFile UTL_FILE.FILE_TYPE; BEGIN vFile := UTL_FILE.FOPEN( UPPER(iDirectoryName), iFileName, 'wb', 32767 ); DECLARE cChunkSize CONSTANT PLS_INTEGER := 32767; vBuffer RAW(32767); vAmount PLS_INTEGER := cChunkSize; vNumOfChunk PLS_INTEGER; BEGIN vNumOfChunk := CEIL(DBMS_LOB.GETLENGTH(iSrcBlob)/cChunkSize); FOR chunk# IN 1..vNumOfChunk LOOP DBMS_LOB.READ( iSrcBlob, vAmount, (cChunkSize * (chunk# - 1)) + 1, /*offset*/ vBuffer ); UTL_FILE.PUT_RAW(vFile, vBuffer, TRUE); END LOOP; END; UTL_FILE.FCLOSE(vFile); END write_blob_to_file; -- BEGIN vDirectoryName := UPPER('&1'); vSrcFileName := '&2'; vDestFileName := '&2'||'.gz'; vSrcFile := BFILENAME(UPPER(vDirectoryName), vSrcFileName); DBMS_LOB.OPEN(vSrcFile); vSrcFileSize := DBMS_LOB.GETLENGTH(vSrcFile); vCompressedBlob := UTL_COMPRESS.LZ_COMPRESS(vSrcFile); vDestFileSize := DBMS_LOB.GETLENGTH(vCompressedBlob); write_blob_to_file( UPPER(vDirectoryName), vDestFileName, vCompressedBlob ); DBMS_LOB.FREETEMPORARY(vCompressedBlob); close_bfile(vSrcFile); DBMS_OUTPUT.PUT_LINE( vDirectoryName ||'/'||vSrcFileName||' compressed to ' ||vDestFileName||'(' ||ROUND((1 - (vDestFileSize / vSrcFileSize)) * 100, 2)||'%)' ); XCEPTION WHEN OTHERS THEN DBMS_LOB.FREETEMPORARY(vCompressedBlob); close_bfile(vSrcFile); RAISE; END; / UNDEFINE 1 UNDEFINE 2 SET SERVEROUTPUT OFF SET VERIFY ON

できた〜

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

Previously on Mac De Oracle

・RDS Oracle 雑多なメモ#1 / FAQ
・RDS Oracle 雑多なメモ#2 / FAQ
・RDS Oracle 雑多なメモ#3 / FAQ
・RDS Oracle 雑多なメモ#4 / FAQ
・RDS Oracle 雑多なメモ#5 / FAQ
・RDS Oracle 雑多なメモ#6 / FAQ
・RDS Oracle 雑多なメモ#7 / FAQ
・RDS Oracle 雑多なメモ#8 / FAQ
・RDS Oracle 雑多なメモ#9 / FAQ

投稿日時 2018年9月24日 (月) 11時09分 PL/SQL, FAQ, SQL, Oracle Database 11g Release 2, Oracle Database 12c release 1, AWS, RDS | 固定リンク | 0 | コメント (0) | トラックバック (0)

RDS Oracle 雑多なメモ#9 / FAQ

メモの続きです。
ということで、　（どういうことだ〜っ。久々に一人、ツッコミ）

圧縮解凍ネタに進む前に、dbms_datapumpパッケージを使って、1GB越えのファイルを作っておこうかと。ここで作成したダンプファイルを圧縮解凍ネタにしようと思います。
事前にscottユーザーを作成して、hoge表を作成し、1GB程度のセグメントサイズになるようにデータを登録、その後、主キー索引を追加してあります。

14:29:48 rdsora121@BILL> desc scott.hoge 名前 NULL? 型 ----------------------------------------- -------- ---------------------------- ID NOT NULL NUMBER FOO VARCHAR2(4000) 14:31:24 rdsora121@BILL>select segment_name,sum(bytes)/1024/1024/1024 "GB" from dba_segments where owner='SCOTT' group by segment_name; SEGMENT_NAME GB ------------------------------ ---------- PK_HOGE .004882813 HOGE 2.125 経過: 00:00:00.09 14:28:59 rdsora121@BILL> @list_dir DIRECTORY_NAME DIRECTORY_PATH ---------------------------------------- ---------------------------------------------------------------------- ADUMP /rdsdbdata/log/audit BDUMP /rdsdbdata/log/trace DATA_PUMP_DIR /rdsdbdata/datapump HOGE_DIR /rdsdbdata/userdirs/02 OPATCH_INST_DIR /rdsdbbin/oracle/OPatch OPATCH_LOG_DIR /rdsdbbin/oracle/QOpatch OPATCH_SCRIPT_DIR /rdsdbbin/oracle/QOpatch TEST_DIR /rdsdbdata/userdirs/01 8行が選択されました。経過: 00:00:00.03 14:29:03 rdsora121@BILL> @ls_dir test_dir FILENAME TYPE FILESIZE MTIME ---------------------------------------------------------------------- ---------- ---------- -------- 01/ directory 4096 18-09-22

scottユーザーのhoge表を表モードでエクスポートしてダンプファイルをtest_dirへ出力させます！
以前やっつけで作ったのスクリプトの再利用なので、エクスポートモードなど他のパラメータも変更できるようにすれば、より良く改良できると思います。いまはやりませんがw
（以前の記事も参考にしてみてくさい。SQL Tuning Setのキャプチャから退避までのスクリプト（やっつけ）)
出力されたダンプファイルは約1GBってところですね。

14:35:41 rdsora121@BILL> @export_table test_dir hoge scott hoge "BILL"."EXPTABLE_HOGE"を起動しています: BLOCKSメソッドを使用して見積り中です... オブジェクト型TABLE_EXPORT/TABLE/TABLE_DATAの処理中です BLOCKSメソッドを使用した見積り合計: 2.125 GB オブジェクト型TABLE_EXPORT/TABLE/TABLEの処理中ですオブジェクト型TABLE_EXPORT/TABLE/INDEX/INDEXの処理中ですオブジェクト型TABLE_EXPORT/TABLE/CONSTRAINT/CONSTRAINTの処理中ですオブジェクト型TABLE_EXPORT/TABLE/INDEX/STATISTICS/INDEX_STATISTICSの処理中ですオブジェクト型TABLE_EXPORT/TABLE/STATISTICS/TABLE_STATISTICSの処理中ですオブジェクト型TABLE_EXPORT/TABLE/STATISTICS/MARKERの処理中です . . "SCOTT"."HOGE" 1.008 GB 270000行がエクスポートされましたマスター表"BILL"."EXPTABLE_HOGE"は正常にロード/アンロードされました ****************************************************************************** BILL.EXPTABLE_HOGEに設定されたダンプ・ファイルは次のとおりです: /rdsdbdata/userdirs/01/hoge.dmp ジョブ"BILL"."EXPTABLE_HOGE"が日 9月 23 05:36:33 2018 elapsed 0 00:00:35で正常に完了しました PL/SQLプロシージャが正常に完了しました。経過: 00:00:40.23 14:36:34 rdsora121@BILL> 14:37:04 rdsora121@BILL> @ls_dir test_dir FILENAME TYPE FILESIZE MTIME ---------------------------------------------------------------------- ---------- ---------- -------- 01/ directory 4096 18-09-23 hoge.log file 1202 18-09-23 hoge.dmp file 1083412480 18-09-23

表モードエクスポートのDataPump Exportジョブを実行するスクリプトは以下のとおり。
（表モードに固定してある部分を変更してスキーマモードにしたり、複数の表のエクスポートに対応できるように改造してやれば、より便利なスクリプトにすることもできると思います。）

14:36:34 rdsora121@BILL> !cat export_table.sql SET VERIFY OFF SET SERVEROUTPUT ON DECLARE v4Debug VARCHAR2(50); cDirectory CONSTANT VARCHAR2(30) := UPPER('&1'); cDumpFileName CONSTANT VARCHAR2(64) := '&2'||'.dmp'; cLogFileName CONSTANT VARCHAR2(64) := '&2'||'.log'; cSchemaName CONSTANT VARCHAR2(30) := UPPER('&3'); cTableName CONSTANT VARCHAR2(30) := UPPER('&4'); i NUMBER; vDataPumpJobHandle NUMBER; vProgress_ratio NUMBER; vJobState VARCHAR2(30); oLogEntry ku$_LogEntry; oStatus ku$_Status; BEGIN DBMS_OUTPUT.ENABLE; v4Debug := 'OPEN'; vDataPumpJobHandle := DBMS_DATAPUMP.OPEN ( operation => 'EXPORT' ,job_mode => 'TABLE' ,remote_link => NULL ,job_name => 'EXPTABLE_'||cTableName ,version => 'LATEST' ); v4Debug := 'ADD_FILE - dumpfile'; DBMS_DATAPUMP.ADD_FILE ( handle => vDataPumpJobHandle ,filename => cDumpFileName ,directory => cDirectory ,filetype => DBMS_DATAPUMP.KU$_FILE_TYPE_DUMP_FILE ); v4Debug := 'ADD_FILE - logfile'; DBMS_DATAPUMP.ADD_FILE ( handle => vDataPumpJobHandle ,filename => cLogFileName ,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 => '''' || cSchemaName || '''' ); v4Debug := 'METADATA_FILTER - table name'; DBMS_DATAPUMP.METADATA_FILTER ( handle => vDataPumpJobHandle ,name => 'NAME_LIST' ,value => '''' || cTableName || '''' ); v4Debug := 'START_JOB'; DBMS_DATAPUMP.START_JOB ( handle => vDataPumpJobHandle ); 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 ); 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; DBMS_DATAPUMP.DETACH(vDataPumpJobHandle); EXCEPTION WHEN OTHERS THEN DBMS_OUTPUT.PUT_LINE(sqlerrm()); DBMS_OUTPUT.PUT_LINE(v4Debug); RAISE; END; / UNDEFINE 1 UNDEFINE 2 UNDEFINE 3 UNDEFINE 4 SET SERVEROUTPUT OFF SET VERIFY ON

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

Previously on Mac De Oracle

・RDS Oracle 雑多なメモ#1 / FAQ
・RDS Oracle 雑多なメモ#2 / FAQ
・RDS Oracle 雑多なメモ#3 / FAQ
・RDS Oracle 雑多なメモ#4 / FAQ
・RDS Oracle 雑多なメモ#5 / FAQ
・RDS Oracle 雑多なメモ#6 / FAQ
・RDS Oracle 雑多なメモ#7 / FAQ
・RDS Oracle 雑多なメモ#8 / FAQ

投稿日時 2018年9月24日 (月) 00時10分 PL/SQL, FAQ, SQL, Oracle Database 11g Release 2, Oracle Database 12c release 1, Data Pump, AWS, RDS | 固定リンク | 0 | コメント (0) | トラックバック (0)

RDS Oracle 雑多なメモ#8 / FAQ

メモの続きです。
前回は、utl_fileパッケージでrmっぽいことを行うスクリプトを作成しました。
前回まででutl_fileパッケージを利用したディレクトリオブジェクト配下のファイル操作スクリリプトを作ることができました。

さて、今回はなにをしましょう？。。。。としばし考えて浮かんだのが、昔の圧縮解凍ネタとdbms_datapumpネタの組み合わせ。。。

再利用ネタ、その１は以下。
SQL Tuning Setのキャプチャから退避までのスクリプト（やっつけ
上記ネタの何を利用するかというと、DBMS_DATAPUMPパッケージ。このパッケージもディレクトリオブジェクトを利用するのでネタとしてはちょうどよさげ。

もう一つのネタはかなり古い（12年前？w）
Mac De Oracle (PL/SQL De COMPRESS)
Mac De Oracle (PL/SQL De UNCOMPRESS)
この辺りを使って、圧縮、解凍スクリプトも作っておいたら便利なんじゃないかとおもいます。

それから、kempe さんの記事も利用すればいろいろできそうですね。プライベートサブネットのVPCエンドポイント経由でS3とやりとりすればパブリックネットワークは経由しなくて良さそうですし:)
RDSとS3でファイルのやり取りを行う

なお、11.2では、aclパラメータに.xml拡張子が必要ですが、12.1以降では必要ありません（いつ変わったw）が、12c以降では以下プロシージャは非推奨で下位互換向けにのこされています）
11.2のマニュアルには aclパラメータには、.xml 拡張子が必要とは明記されていないのですが、意味不明なエラーが返されます。例のaclには.xml拡張子が付加されているのですが、パラメータの解説では一切触れられていないのでハマることがあるので注意しましょうね。

15:54:54 orcl@SYS> select version from v$instance; VERSION ----------------- 11.2.0.4.0 15:54:00 orcl@SYS> !cat test.sql begin dbms_network_acl_admin.create_acl ( acl => 'test' , description => 'acl create test' , principal => 'SCOTT' , is_grant => true , privilege => 'connect' ); end; / 15:54:07 orcl@SYS> @test begin * ERROR at line 1: ORA-46059: Invalid ACL identifier specified ORA-06512: at "SYS.DBMS_NETWORK_ACL_ADMIN", line 70 ORA-06512: at "SYS.DBMS_NETWORK_ACL_ADMIN", line 218 ORA-06512: at line 2 15:54:19 orcl@SYS> !cat test.sql begin dbms_network_acl_admin.create_acl ( acl => 'test.xml' , description => 'acl create test' , principal => 'SCOTT' , is_grant => true , privilege => 'connect' ); end; / 15:54:25 orcl@SYS> @test PL/SQL procedure successfully completed. Elapsed: 00:00:00.02 15:54:27 orcl@SYS> exec dbms_network_acl_admin.drop_acl('test.xml'); PL/SQL procedure successfully completed.

dbms_network_acl_adminについては11.2と12.1で考慮はいるかもしれません。（非推奨プロシージャはいずれ廃止されるでしょうから）

というあたりも考慮してネタを作るかどうか。。。
その前に、ファイル、圧縮解凍だけのネタを作っておくか。。

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

Previously on Mac De Oracle

・RDS Oracle 雑多なメモ#1 / FAQ
・RDS Oracle 雑多なメモ#2 / FAQ
・RDS Oracle 雑多なメモ#3 / FAQ
・RDS Oracle 雑多なメモ#4 / FAQ
・RDS Oracle 雑多なメモ#5 / FAQ
・RDS Oracle 雑多なメモ#6 / FAQ
・RDS Oracle 雑多なメモ#7 / FAQ

投稿日時 2018年9月24日 (月) 00時00分 PL/SQL, FAQ, SQL, Oracle Database 11g Release 2, Oracle Database 12c release 1, AWS, RDS | 固定リンク | 0 | コメント (0) | トラックバック (0)

2018年9月23日 (日)

RDS Oracle 雑多なメモ#7 / FAQ

メモの続きです。
前回は、utl_fileパッケージでcpっぽいことを行うスクリプトを作成しました。
今回は、ディレクトリオブジェクト以下のファイルにrmっぽい操作が行えるようなスクリプトを作ります :)

作成済みのtest_dirディレクトのファイルを再利用しています。

ディレクトリとファイルを指定してファイル削除！

17:11:54 rdsora121@BILL> @ls_dir test_dir FILENAME TYPE FILESIZE MTIME ---------------------------------------------------------------------- ---------- ---------- -------- top100_tables_v1.txt file 2277 18-09-19 top100_tables_v2.txt file 2277 18-09-21 01/ directory 4096 18-09-21 17:12:37 rdsora121@BILL> @rm_file test_dir top100_tables_v2.txt TEST_DIR/top100_tables_v2.txt removed. PL/SQLプロシージャが正常に完了しました。経過: 00:00:00.03 17:13:25 rdsora121@BILL> @ls_dir test_dir FILENAME TYPE FILESIZE MTIME ---------------------------------------------------------------------- ---------- ---------- -------- top100_tables_v1.txt file 2277 18-09-19 01/ directory 4096 18-09-22

スクリプトは以下の通り。UTL_FILE.FREMOVEを呼び出しているだけの単純なスクリプトにしてあります
第一回目にも書きましたが、スクリプトは、EC2など、SQL*Plusを起動しているクライアント側に作成します。

17:14:51 rdsora121@BILL> !cat rm_file.sql set verify off set serveroutput on BEGIN UTL_FILE.FREMOVE ( location => UPPER('&1') , filename => '&2' ); DBMS_OUTPUT.PUT_LINE(UPPER('&1')||'/&2 removed.'); EXCEPTION WHEN OTHERS THEN DBMS_OUTPUT.PUT_LINE(SQLCODE()||':'||SQLERRM()); END; / set serveroutput off undefine 1 undefine 2 set verify on

次回へ続く

Previously on Mac De Oracle

・RDS Oracle 雑多なメモ#1 / FAQ
・RDS Oracle 雑多なメモ#2 / FAQ
・RDS Oracle 雑多なメモ#3 / FAQ
・RDS Oracle 雑多なメモ#4 / FAQ
・RDS Oracle 雑多なメモ#5 / FAQ
・RDS Oracle 雑多なメモ#6 / FAQ

ところで、今年も秋葉原UDXで開催されたdb tech showcase 2018へ参加してきました。
今回、自分のセッションも司会もなしだったので、久々にゆっくりといろいろな方のセッションを聞くことがきたし、毎年このイベント合う多数のデータベースエンジニアとの交流もたのしくてたのしくてw それ以上表現のしようがないw
（ボキャ貧なのでごめんなさい、ごめんなさい）

そして、インサイトテクノロジーの社長を退かれた小幡さん、　”おもしろった！” ありがとうございました。
おいしいみかんできたら、送ってね　:)

投稿日時 2018年9月23日 (日) 00時00分 PL/SQL, FAQ, SQL, Oracle Database 11g Release 2, Oracle Database 12c release 1, AWS, RDS | 固定リンク | 0 | コメント (0) | トラックバック (0)

2018年9月22日 (土)

RDS Oracle 雑多なメモ#6 / FAQ

メモの続きです。
前回は、utl_fileパッケージでmvっぽいことを行うスクリプトを作成しました。
今回は、ディレクトリオブジェクト以下のファイルにcpっぽい操作が行えるようなスクリプトを作ります :)

ただ、　utl_file.fcopyってテキストファイルしかコピーできないんだよね。という制限付きです。いまのところ。
（バイナリ版は手作りで作ればできたような、。。。昔のネタ引っ張り出すかw）

ということで、utl_file.fcopyもdbms_transfer_fileパッケージも使わずにLOB系操作でバイナリファイルとテキストファイルをコピーするよう、cp_file.sqlスクリプトを作り変えました。

RDS Oracle 雑多なメモ#11 / FAQも合わせて参照ください。m(_ _)m

作成済みのtest_dirとhoge_dirディレクトリとファイルを再利用しています。
ざっくりめで書いたので複数ファイルの一括コピーや引数の指定方法などなど、改善したいところはあるわけですがw　適宜対応ということで。

同一ディレクトリでファイルコピー

00:44:59 SQL> @ls_dir test_dir FILENAME TYPE FILESIZE MTIME ---------------------------------------------------------------------- ---------- ---------- -------- top100_tables_v1.txt file 2277 18-09-19 01/ directory 4096 18-09-21 経過: 00:00:02.35 00:55:33 SQL> @cp_file test_dir top100_tables_v1.txt test_dir top100_tables_v2.txt source file : test_dir/top100_tables_v1.txt dest file : test_dir/top100_tables_v2.txt copied. PL/SQLプロシージャが正常に完了しました。経過: 00:00:00.04 00:57:42 SQL> @ls_dir test_dir FILENAME TYPE FILESIZE MTIME ---------------------------------------------------------------------- ---------- ---------- -------- top100_tables_v1.txt file 2277 18-09-19 top100_tables_v2.txt file 2277 18-09-21 01/ directory 4096 18-09-21

異なるディレクトリへ同一名でファイルコピー

01:01:55 SQL> @cp_file test_dir top100_tables_v2.txt hoge_dir top100_tables_v2.txt source file : test_dir/top100_tables_v2.txt dest file : hoge_dir/top100_tables_v2.txt copied. PL/SQLプロシージャが正常に完了しました。経過: 00:00:00.05 01:05:13 SQL> @ls_dir hoge_dir FILENAME TYPE FILESIZE MTIME ---------------------------------------------------------------------- ---------- ---------- -------- top100_tables_v2.txt file 2277 18-09-21 02/ directory 4096 18-09-21

異なるディレクトリへ異なるファイル名でコピー

01:06:30 SQL> @cp_file test_dir top100_tables_v2.txt hoge_dir top100_tables_v3.txt source file : test_dir/top100_tables_v2.txt dest file : hoge_dir/top100_tables_v3.txt copied. PL/SQLプロシージャが正常に完了しました。経過: 00:00:00.04 01:06:47 SQL> @ls_dir hoge_dir FILENAME TYPE FILESIZE MTIME ---------------------------------------------------------------------- ---------- ---------- -------- top100_tables_v2.txt file 2277 18-09-21 02/ directory 4096 18-09-21 top100_tables_v3.txt file 2277 18-09-21

スクリプトは以下の通り。

01:09:56 SQL> !cat cp_file.sql set verify off set serveroutput on format wrapped BEGIN UTL_FILE.FCOPY( src_location => UPPER('&1') ,src_filename => '&2' ,dest_location => UPPER('&3') ,dest_filename => '&4' ); DBMS_OUTPUT.PUT_LINE(' '); DBMS_OUTPUT.PUT_LINE('source file : &1/&2'); DBMS_OUTPUT.PUT_LINE('dest file : &3/&4 copied.'); EXCEPTION WHEN OTHERS THEN DBMS_OUTPUT.PUT_LINE(SQLCODE()||':'||SQLERRM()); END; / undefine 1 undefine 2 undefine 3 undefine 4 set verify on set serveroutput off

次回へ続く

Previously on Mac De Oracle

・RDS Oracle 雑多なメモ#1 / FAQ
・RDS Oracle 雑多なメモ#2 / FAQ
・RDS Oracle 雑多なメモ#3 / FAQ
・RDS Oracle 雑多なメモ#4 / FAQ
・RDS Oracle 雑多なメモ#5 / FAQ

投稿日時 2018年9月22日 (土) 01時23分 PL/SQL, FAQ, SQL, Oracle Database 11g Release 2, Oracle Database 12c release 1, AWS, RDS | 固定リンク | 0 | コメント (0) | トラックバック (0)

2018年9月21日 (金)

RDS Oracle 雑多なメモ#5 / FAQ

メモの続きです。
前回は、AWS提供のrdsadmin.rds_file_util.read_text_file関数でcatっぽいスクリプトを作っておきました。（改善したほうがよさげなところもありますがw）
今回は、ディレクトリオブジェクト以下のファイルにmvっぽい操作が行えるようなスクリプトを作ります。

これからの操作はファイルそのものに対しておこなうので、わかりやすくする意味もあり新たにディレクトオブジェクトを作成して、ファイルを一作っておきます。

実験用ディレクトリオブジェクトの作成

00:49:07 rdsora121@BILL> @create_dir test_dir PL/SQLプロシージャが正常に完了しました。経過: 00:00:02.04 DIRECTORY_NAME DIRECTORY_PATH ---------------------------------------- ---------------------------------------------------------------------- TEST_DIR /rdsdbdata/userdirs/01 経過: 00:00:00.03

作成したディレクトリオブジェクト以下に適当なファイル（今回はテキストファイル）を作成

01:05:30 rdsora121@BILL> @query2file.sql PL/SQLプロシージャが正常に完了しました。経過: 00:00:00.12

ここでは、”utl_file I/O” - この症状はあれの可能性が高いですね。でも紹介したUTL_FILEパッケージでディレクトオブジェクト以下にファイルを出力するサンプルを再利用してファイルを書き出しました。

01:06:02 rdsora121@BILL> !cat query2file.sql DECLARE cDIR_NAME CONSTANT VARCHAR2(30) := 'TEST_DIR'; cFILE_NAME CONSTANT VARCHAR2(128) := 'top100_tablenames__'||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_top100_tablenames IS SELECT table_name FROM dba_tables ORDER BY table_name FETCH FIRST 100 ROWS ONLY ; BEGIN OPEN cur_top100_tablenames; fileHandle := UTL_FILE.FOPEN(cDIR_NAME, cFILE_NAME, cOpenMode, cBufferSize); LOOP FETCH cur_top100_tablenames 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_top100_tablenames; EXCEPTION WHEN OTHERS THEN IF UTL_FILE.IS_OPEN(fileHandle) THEN UTL_FILE.FCLOSE(fileHandle); END IF; IF cur_top100_tablenames%ISOPEN THEN CLOSE cur_top100_tablenames; END IF; RAISE; END; /

テキストファイルがディレクトリオブジェクト以下に作成されましった！

01:06:29 rdsora121@BILL> @ls_dir test_dir FILENAME TYPE FILESIZE MTIME ---------------------------------------------------------------------- ---------- ---------- -------- top100_tablenames__180919160551.113374000.txt file 2277 18-09-19 01/ directory 4096 18-09-19

念のため中身を確認

01:06:38 rdsora121@BILL> @cat_file test_dir top100_tablenames__180919160551.113374000.txt TEXT ------------------------------------------------------------------------------------------ ACCESS$ ACLMV$ ACLMV$_REFLOG ACLMVREFSTAT$ ・・・中略・・・ AQ$_SUBSCRIBER_TABLE AQ$_SYS$SERVICE_METRICS_TAB_G AQ$_SYS$SERVICE_METRICS_TAB_H AQ$_SYS$SERVICE_METRICS_TAB_I 100行が選択されました。

同一ディレクトリ内でファイル名を変更

01:29:47 rdsora121@BILL> @mv_file test_dir top100_tablenames__180919160551.113374000.txt test_dir top100_tables.txt source file : test_dir/top100_tablenames__180919160551.113374000.txt dest file : test_dir/top100_tables.txt moved. PL/SQLプロシージャが正常に完了しました。

長いファイル名称を短く変更！

01:29:57 rdsora121@BILL> @ls_dir test_dir FILENAME TYPE FILESIZE MTIME ---------------------------------------------------------------------- ---------- ---------- -------- top100_tables.txt file 2277 18-09-19 01/ directory 4096 18-09-19

ファイル名は同じままで、別ディレクトリへファイル移動

08:05:17 rdsora121@BILL> @create_dir hoge_dir PL/SQLプロシージャが正常に完了しました。経過: 00:00:02.26 DIRECTORY_NAME DIRECTORY_PATH ---------------------------------------- ---------------------------------------------------------------------- HOGE_DIR /rdsdbdata/userdirs/02 経過: 00:00:00.04 08:05:29 rdsora121@BILL> @mv_file test_dir top100_tables.txt hoge_dir top100_tables.txt source file : test_dir/top100_tables.txt dest file : hoge_dir/top100_tables.txt moved. PL/SQLプロシージャが正常に完了しました。経過: 00:00:00.04 08:06:27 rdsora121@BILL> @ls_dir hoge_dir FILENAME TYPE FILESIZE MTIME ---------------------------------------------------------------------- ---------- ---------- -------- top100_tables.txt file 2277 18-09-19 02/ directory 4096 18-09-19 経過: 00:00:02.25 08:06:39 rdsora121@BILL> @ls_dir test_dir FILENAME TYPE FILESIZE MTIME ---------------------------------------------------------------------- ---------- ---------- -------- 01/ directory 4096 18-09-19

ファイル名を変更して、ディレクトリ移動

08:08:22 rdsora121@BILL> @mv_file hoge_dir top100_tables.txt test_dir top100_tables_v1.txt source file : hoge_dir/top100_tables.txt dest file : test_dir/top100_tables_v1.txt moved. PL/SQLプロシージャが正常に完了しました。経過: 00:00:00.02 08:09:00 rdsora121@BILL> @ls_dir hoge_dir FILENAME TYPE FILESIZE MTIME ---------------------------------------------------------------------- ---------- ---------- -------- 02/ directory 4096 18-09-19 経過: 00:00:02.05 08:09:11 rdsora121@BILL> @ls_dir test_dir FILENAME TYPE FILESIZE MTIME ---------------------------------------------------------------------- ---------- ---------- -------- top100_tables_v1.txt file 2277 18-09-19 01/ directory 4096 18-09-19 経過: 00:00:02.05

スクリプトは以下の通り

01:30:20 rdsora121@BILL> !cat mv_file.sql set verify off set serveroutput on format wrapped BEGIN UTL_FILE.FRENAME( src_location => UPPER('&1') ,src_filename => '&2' ,dest_location => UPPER('&3') ,dest_filename => '&4' ,overwrite => false ); DBMS_OUTPUT.PUT_LINE(' '); DBMS_OUTPUT.PUT_LINE('source file : &1/&2'); DBMS_OUTPUT.PUT_LINE('dest file : &3/&4 moved.'); EXCEPTION WHEN OTHERS THEN DBMS_OUTPUT.PUT_LINE(SQLCODE()||':'||SQLERRM()); END; / undefine 1 undefine 2 undefine 3 undefine 4 set verify on set serveroutput off

次回へ続く

Previously on Mac De Oracle

・RDS Oracle 雑多なメモ#1 / FAQ
・RDS Oracle 雑多なメモ#2 / FAQ
・RDS Oracle 雑多なメモ#3 / FAQ
・RDS Oracle 雑多なメモ#4 / FAQ

投稿日時 2018年9月21日 (金) 00時00分 PL/SQL, FAQ, SQL, Oracle Database 11g Release 2, Oracle Database 12c release 1, AWS, RDS | 固定リンク | 0 | コメント (0) | トラックバック (0)

2018年9月20日 (木)

RDS Oracle 雑多なメモ#4 / FAQ

メモの続きです。
前回は、AWS提供のrdsadmin.rds_file_util.listdir関数を利用したlsっぽいファイルリストスクリプトを作成しました。
今回は、同じくAWS提供のrdsadmin.rds_file_util.read_text_file関数でcatっぽいスクリプトを。

ディレクト名を確認し。。

05:10:47 rdsora121@BILL> @list_dir DIRECTORY_NAME DIRECTORY_PATH ---------------------------------------- ---------------------------------------------------------------------- ADUMP /rdsdbdata/log/audit BDUMP /rdsdbdata/log/trace DATA_PUMP_DIR /rdsdbdata/datapump OPATCH_INST_DIR /rdsdbbin/oracle/OPatch OPATCH_LOG_DIR /rdsdbbin/oracle/QOpatch OPATCH_SCRIPT_DIR /rdsdbbin/oracle/QOpatch 6行が選択されました。経過: 00:00:00.02

ファイル名を確認してから。。

05:10:50 rdsora121@BILL> @ls_dir bdump FILENAME TYPE FILESIZE MTIME ---------------------------------------------------------------------- ---------- ---------- -------- ORCL_ora_12254.trc file 4393 18-09-15 ORCL_ora_12254.trm file 202 18-09-15 ・・・中略・・・ ORCL_ora_12841.trm file 71 18-09-17 trace/ directory 12288 18-09-17 ORCL_ora_12841.trc file 990 18-09-17 alert_ORCL.log file 138516 18-09-17 ORCL_mmon_11216.trm file 118 18-09-17 ORCL_mmon_11216.trc file 1503 18-09-17 279行が選択されました。経過: 00:00:02.28

alertログファイルを覗いて見ましょう。

05:10:57 rdsora121@BILL> @cat_file bdump alert_ORCL.log TEXT ----------------------------------------------------------------------------------------------- Sat Sep 15 19:03:04 2018 Starting ORACLE instance (normal) (OS id: 12254) Sat Sep 15 19:03:04 2018 ・・・中略・・・ pga_aggregate_limit is 4809 MB 3376行が選択されました。経過: 00:00:03.09

スクリプトは以下のとおり。
ん〜。ざっくり作りすぎたかもw Top Nクエリもできるようにしたほうがいいかもねぇ〜と。思わなくもないけど、とりあえずこれで。

ちなみに、ディレクトリ名はUPPER()関数で強制的に大文字変換、ファイル名は入力されたファイル名をそのまま利用するようにしています。

05:12:04 rdsora121@BILL> !cat cat_file.sql set verify off set long 100000 set longchunk 100000 SELECT text FROM TABLE ( rdsadmin.rds_file_util.read_text_file ( p_directory => UPPER('&1') , p_filename => '&2' ) ) ; undefine 1 undefine 2 set verify on

次回へ続く

Previously on Mac De Oracle

・RDS Oracle 雑多なメモ#1 / FAQ
・RDS Oracle 雑多なメモ#2 / FAQ
・RDS Oracle 雑多なメモ#3 / FAQ

投稿日時 2018年9月20日 (木) 00時00分 FAQ, SQL, Oracle Database 11g Release 2, Oracle Database 12c release 1, AWS | 固定リンク | 0 | コメント (0) | トラックバック (0)

2018年9月19日 (水)

RDS Oracle 雑多なメモ#3 / FAQ

メモの続きです。
これまでに、ディレクトリ作成、削除、ディレクトリリストスクリプトを作成しました。

残る使用頻度の高そうなスクリプトは、ディレクトリオブジェクト以下にあるファイル操作スクリプト。
OSレイヤーに入れないRDS Oracleで、ディレクトリオブジェクト以下にあるファイルの操作に困るのは目に見えてるので。。。w

RDS Oracleでは、rdsadmin.rds_file_utilパッケージが提供されていますが、提供されている関数は以下の通り。
どう見ても全ての操作を行うに不十分なのですが、よーく思い出してみましょう。
ファイルの削除などの操作は、Oracle Databaseに昔からあるビルトインパッケージ、utl_fileパッケージを利用できちゃいそうですよね！！
ということで、これまた、いちいちタイプするのは面倒なので事前に作成しておいたほうが楽なはず。。。

13:40:16 rdsora121@BILL> desc rdsadmin.rds_file_util FUNCTION LISTDIR RETURNS RDS_FILE_LIST_T 引数名タイプ In/Out Default? ------------------------------ ----------------------- ------ -------- P_DIRECTORY VARCHAR2 IN FUNCTION READ_TEXT_FILE RETURNS RDS_TEXT_LIST_T 引数名タイプ In/Out Default? ------------------------------ ----------------------- ------ -------- P_DIRECTORY VARCHAR2 IN P_FILENAME VARCHAR2 IN

まず、上記AWSから提供されているrdsadmin.rds_file_util.listdir関数を利用したスクリプトを作成しておきます。

13:53:44 rdsora121@BILL> @list_dir DIRECTORY_NAME DIRECTORY_PATH ---------------------------------------- ---------------------------------------------------------------------- ADUMP /rdsdbdata/log/audit BDUMP /rdsdbdata/log/trace DATA_PUMP_DIR /rdsdbdata/datapump OPATCH_INST_DIR /rdsdbbin/oracle/OPatch OPATCH_LOG_DIR /rdsdbbin/oracle/QOpatch OPATCH_SCRIPT_DIR /rdsdbbin/oracle/QOpatch 6行が選択されました。経過: 00:00:00.03

ファイルの無い空のディレクトリは以下のようにリストされるか〜。
へぇ〜。

13:53:52 rdsora121@BILL> @ls_dir data_pump_dir FILENAME TYPE FILESIZE MTIME ---------------------------------------------------------------------- ---------- ---------- -------- datapump/ directory 4096 18-09-17 経過: 00:00:02.25

ディレクトオブジェクトへの読み込み権限がないと以下のようなエラーが返ります。

13:54:07 rdsora121@BILL> @ls_dir opatch_log_dir rdsadmin.rds_file_util.listdir(UPPER('OPATCH_LOG_DIR')) * 行5でエラーが発生しました。: ORA-20900: Directory OPATCH_LOG_DIR does not exist or no privileges. ORA-06512: "SYS.RDS_SYS_UTIL", 行147 ORA-06512: "SYS.RDS_SYS_UTIL", 行161 ORA-06512: "RDSADMIN.RDS_FILE_UTIL", 行38 経過: 00:00:00.05

対象ディレクトリの読み取り権限が付与され、ディレクトリオブジェクト以下になんらかのファイルがあれば、以下のようなリリストが返ります。
こんな感じにリストされるのな。:)

13:54:42 rdsora121@BILL> @ls_dir adump FILENAME TYPE FILESIZE MTIME ---------------------------------------------------------------------- ---------- ---------- -------- ORCL_ora_12254_20180915190307342858143795.aud file 805 18-09-15 ...中略... ORCL_ora_12687_20180917043000205002143795.aud file 1549 18-09-17 ORCL_ora_14013_20180917044500213934143795.aud file 1549 18-09-17 audit/ directory 16384 18-09-17 146行が選択されました。経過: 00:00:02.17

スクリプトは以下のとおり。rdsadmin.rds_file_util.listdir関数は表関数なので以下のような使い方:)

13:55:17 rdsora121@BILL> !cat ls_dir.sql set verify off col filename for a70 SELECT * FROM TABLE ( rdsadmin.rds_file_util.listdir(UPPER('&1')) ) ORDER BY mtime ; undefine 1 set verify off

次回へ続く

Previously on Mac De Oracle

・RDS Oracle 雑多なメモ#1 / FAQ
・RDS Oracle 雑多なメモ#2 / FAQ

投稿日時 2018年9月19日 (水) 00時00分 FAQ, SQL, Oracle Database 11g Release 2, Oracle Database 12c release 1, AWS, RDS | 固定リンク | 0 | コメント (0) | トラックバック (0)

2018年9月18日 (火)

RDS Oracle 雑多なメモ#2 / FAQ

メモの続き。

前回、ディレクトリリストとディレクトリオブジェクト作成スクリプトを作ったので、作り忘れてたディレクトリオブジェクト削除スクリプトを。

実行例
前回作成しておいたlist_dir.sqlでディレクトリ名を確認しながら "TEST"ディレクトリを削除しています。

13:30:25 rdsora121@BILL> @list_dir DIRECTORY_NAME DIRECTORY_PATH ---------------------------------------- ---------------------------------------------------------------------- ADUMP /rdsdbdata/log/audit BDUMP /rdsdbdata/log/trace DATA_PUMP_DIR /rdsdbdata/datapump OPATCH_INST_DIR /rdsdbbin/oracle/OPatch OPATCH_LOG_DIR /rdsdbbin/oracle/QOpatch OPATCH_SCRIPT_DIR /rdsdbbin/oracle/QOpatch TEST /rdsdbdata/userdirs/01 7行が選択されました。経過: 00:00:00.02 13:30:29 rdsora121@BILL> @drop_dir test PL/SQLプロシージャが正常に完了しました。経過: 00:00:00.02 13:30:34 rdsora121@BILL> @list_dir DIRECTORY_NAME DIRECTORY_PATH ---------------------------------------- ---------------------------------------------------------------------- ADUMP /rdsdbdata/log/audit BDUMP /rdsdbdata/log/trace DATA_PUMP_DIR /rdsdbdata/datapump OPATCH_INST_DIR /rdsdbbin/oracle/OPatch OPATCH_LOG_DIR /rdsdbbin/oracle/QOpatch OPATCH_SCRIPT_DIR /rdsdbbin/oracle/QOpatch 6行が選択されました。

スクリプトは以下の通り、rdsadmin.rdsadmin_util.drop_directoryを実行しているだけです:)

13:29:45 rdsora121@BILL> !cat drop_dir.sql set verify off exec rdsadmin.rdsadmin_util.drop_directory(p_directory_name => UPPER('&1')); undefine 1 set verify on

次回へ続く

Previously on Mac De Oracle

・RDS Oracle 雑多なメモ#1 / FAQ

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

2018年9月17日 (月)

RDS Oracle 雑多なメモ#1 / FAQ

さて、さて、ご無沙汰しておりましたw
メモも溜まってきたので、そろそろ RDS Oracle関連の雑多なメモを。。。

新たなスタートをきって1.5ヶ月目にしてRDS Oracleに触れなければいけない状況となり、オンプレのOracleの使い勝手とことなる部分にハマりつつなんとか乗り切ったのでときのメモです。
（みなさん通る道w）

ディレクトリオブジェクト周りはオンプレのOracleと勝手が違いOSレイヤーには入れないので、rdsadmin.rdsadmin_utilパッケージに慣れておく必要があり。
さらに、ファイル操作についても、rdsadmin.rds_file_utilパッケージで提供されている操作は一部なので、utl_fileパッケージを併用しないと削除、コピー、改名などもできません。
また、ダンプファイルの圧縮解答もOSレイヤーでは実行できないので、utl_compressパッケージを利用する必要もありそう。

Oracle DB インスタンスの一般的な DBA システムタスク
https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/Appendix.Oracle.CommonDBATasks.System.html

Oracle DB インスタンスの一般的な DBA ログタスク
https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/Appendix.Oracle.CommonDBATasks.Log.html

Oracle DB インスタンスの一般的な DBA データベース
https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/Appendix.Oracle.CommonDBATasks.Database.html

Oracle DB インスタンスの一般的な DBA のその他のタスク
https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/Appendix.Oracle.CommonDBATasks.Misc.html

ということで、いちいちexe~~cute~~ ほげほげってタイプするのもめんどくさいのでスクリプト化して、楽しましょう。という自分用メモシリーズです。
今後どれくらいRDS Oracleを利用する機会があるのかまったく予想できませんが、備えあれば。。。ということで　;)

まず、RDSADMIN.RDSADMIN_UTILパッケージをdescribeしてみた。
詳細は前述のマニュアルを見てもらうとして、頻繁に利用しそうなのは createdirectoryプロシージャ、drop_directoryプロシージャ、それに　rds_versionファンクション
あたりかなぁ。個人的には。
（他のものも頻繁に使いそうなら、スクリプト化しておくと便利かだと思います。）

22:55:55 rdsora121@BILL> desc rdsadmin.rdsadmin_util PROCEDURE ADD_LOGFILE 引数名タイプ In/Out Default? ------------------------------ ----------------------- ------ -------- BYTES BINARY_INTEGER IN DEFAULT PROCEDURE ADD_LOGFILE 引数名タイプ In/Out Default? ------------------------------ ----------------------- ------ -------- P_SIZE VARCHAR2 IN PROCEDURE ALTER_DB_TIME_ZONE 引数名タイプ In/Out Default? ------------------------------ ----------------------- ------ -------- P_NEW_TZ VARCHAR2 IN PROCEDURE ALTER_DEFAULT_EDITION 引数名タイプ In/Out Default? ------------------------------ ----------------------- ------ -------- EDITION_NAME VARCHAR2 IN PROCEDURE ALTER_DEFAULT_TABLESPACE 引数名タイプ In/Out Default? ------------------------------ ----------------------- ------ -------- TABLESPACE_NAME VARCHAR2 IN PROCEDURE ALTER_DEFAULT_TEMP_TABLESPACE 引数名タイプ In/Out Default? ------------------------------ ----------------------- ------ -------- TABLESPACE_NAME VARCHAR2 IN PROCEDURE ALTER_SUPPLEMENTAL_LOGGING 引数名タイプ In/Out Default? ------------------------------ ----------------------- ------ -------- P_ACTION VARCHAR2 IN P_TYPE VARCHAR2 IN DEFAULT PROCEDURE CHECKPOINT PROCEDURE CREATE_DIRECTORY 引数名タイプ In/Out Default? ------------------------------ ----------------------- ------ -------- P_DIRECTORY_NAME VARCHAR2 IN PROCEDURE DISABLE_DISTR_RECOVERY PROCEDURE DISCONNECT 引数名タイプ In/Out Default? ------------------------------ ----------------------- ------ -------- SID NUMBER IN SERIAL NUMBER IN METHOD VARCHAR2 IN DEFAULT PROCEDURE DROP_DIRECTORY 引数名タイプ In/Out Default? ------------------------------ ----------------------- ------ -------- P_DIRECTORY_NAME VARCHAR2 IN PROCEDURE DROP_LOGFILE 引数名タイプ In/Out Default? ------------------------------ ----------------------- ------ -------- GRP BINARY_INTEGER IN PROCEDURE ENABLE_DISTR_RECOVERY PROCEDURE FLUSH_BUFFER_CACHE PROCEDURE FLUSH_SHARED_POOL PROCEDURE FORCE_LOGGING 引数名タイプ In/Out Default? ------------------------------ ----------------------- ------ -------- P_ENABLE BOOLEAN IN DEFAULT PROCEDURE GRANT_APEX_ADMIN_ROLE PROCEDURE GRANT_SYS_OBJECT 引数名タイプ In/Out Default? ------------------------------ ----------------------- ------ -------- P_OBJ_NAME VARCHAR2 IN P_GRANTEE VARCHAR2 IN P_PRIVILEGE VARCHAR2 IN DEFAULT P_GRANT_OPTION BOOLEAN IN DEFAULT PROCEDURE KILL 引数名タイプ In/Out Default? ------------------------------ ----------------------- ------ -------- SID NUMBER IN SERIAL NUMBER IN METHOD VARCHAR2 IN DEFAULT FUNCTION RDS_VERSION RETURNS VARCHAR2 PROCEDURE RENAME_GLOBAL_NAME 引数名タイプ In/Out Default? ------------------------------ ----------------------- ------ -------- P_NEW_GLOBAL_NAME VARCHAR2 IN PROCEDURE RESTRICTED_SESSION 引数名タイプ In/Out Default? ------------------------------ ----------------------- ------ -------- P_ENABLE BOOLEAN IN DEFAULT PROCEDURE REVOKE_SYS_OBJECT 引数名タイプ In/Out Default? ------------------------------ ----------------------- ------ -------- P_OBJ_NAME VARCHAR2 IN P_REVOKEE VARCHAR2 IN P_PRIVILEGE VARCHAR2 IN DEFAULT PROCEDURE SET_CONFIGURATION 引数名タイプ In/Out Default? ------------------------------ ----------------------- ------ -------- NAME VARCHAR2 IN VALUE VARCHAR2 IN PROCEDURE SHOW_CONFIGURATION 引数名タイプ In/Out Default? ------------------------------ ----------------------- ------ -------- NAME VARCHAR2 IN DEFAULT PROCEDURE SWITCH_LOGFILE 22:56:11 rdsora121@BILL>

ということで、とりあえず、DBのバージョンと、RDSのバージョンを一括取得するスクリプトを作った。
実行例

23:24:14 rdsora121@BILL> @show_version VERSION ------------------------------ 12.1.0.2.0 RDS_VERSION ------------------------------ 1.2

スクリプトは以下の通り。
rdsadmin.rdsadmin_util.rds_versionファンクションを利用しています。
（ちなみに、スクリプトはクライアントとなるEC2などに作成することになります）

23:24:24 rdsora121@BILL> !cat show_version.sql col version for a30 col rds_version for a30 SELECT version FROM v$instance ; SELECT rdsadmin.rdsadmin_util.rds_version AS rds_version FROM dual ;

次は、ディレクトリ操作関連の便利スクリプト群の作成。
まずは、どんなディレクトリオブジェクトが存在するのかパスも含めて確認できると嬉しいですよね。RDS Oracleと言えど。

実行例

23:36:26 rdsora121@BILL> @list_dir DIRECTORY_NAME DIRECTORY_PATH ---------------------------------------- ---------------------------------------------------------------------- ADUMP /rdsdbdata/log/audit BDUMP /rdsdbdata/log/trace DATA_PUMP_DIR /rdsdbdata/datapump OPATCH_INST_DIR /rdsdbbin/oracle/OPatch OPATCH_LOG_DIR /rdsdbbin/oracle/QOpatch OPATCH_SCRIPT_DIR /rdsdbbin/oracle/QOpatch 6行が選択されました。経過: 00:00:00.03

スクリプトは以下のとおり。
dba_directoriesを問い合わせているだけの簡単なお仕事　:)

23:36:31 rdsora121@BILL> !cat list_dir.sql col directory_name for a40 col directory_path for a70 SELECT directory_name ,directory_path FROM dba_directories ORDER BY directory_name ;

お次は、ディレクトリオブジェクトの作成スクリプト。

23:41:24 rdsora121@BILL> @create_dir test PL/SQLプロシージャが正常に完了しました。経過: 00:00:02.12 DIRECTORY_NAME DIRECTORY_PATH ---------------------------------------- ---------------------------------------------------------------------- TEST /rdsdbdata/userdirs/01 経過: 00:00:00.06

スクリプトは以下のとおり。
rdsadmin.rdsadmin_util.create_directoryプロシージャを利用してRDS Oracleのディレクトリオブジェクトを作成後、dba_directoriesビューから作成したディレクトリオプジェクトを問い合わせています。

23:41:36 rdsora121@BILL> !cat create_dir.sql set verify off col directory_name for a40 col directory_path for a70 exec rdsadmin.rdsadmin_util.create_directory(p_directory_name => UPPER('&1')); SELECT directory_name ,directory_path FROM dba_directories WHERE directory_name = UPPER('&1') ORDER BY directory_name ; undefine 1 set verify on

次回に続く

投稿日時 2018年9月17日 (月) 12時56分 FAQ, SQL, Oracle Database 11g Release 2, Oracle Database 12c release 1, AWS, RDS | 固定リンク | 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)のころのままなので、以下のシリーズも合わせて読んでおくといいですよ：）

・Mac De Oracle なんですが、Windows(32bit)でのOracleな話
・Mac De Oracle なんですが、Windows(32bit)でのOracleな話 #2
・Mac De Oracle なんですが、Windows(32bit)でのOracleな話 #3
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #1
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #2
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #3
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #4
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #5
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #6
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #7
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #8
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #9
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #10
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #11
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #12
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #13
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #14
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #15
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #16
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #17
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #18
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #19
・_pga_max_sizeってOracle11gではどうなったっけ？　という確認。
・_pga_max_sizeってOracle11gではどうなったっけ？　という確認。シーズン２
・pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? Season2 #1
・pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? Season2 #2
・pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? Season2 #3
・pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? Season2 #4
・pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? Season2 #5
・pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? Season2 #6
・pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? Season2 #7
・pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? Season2 #8

・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。。

ということで、

次回は実際に、そんなに使えんのかよ！　という実験をしてみたいと思います :)

つづく。

10gR2(64bit)のころのままなので、以下のシリーズも合わせて読んでおくといいですよ：）
・Mac De Oracle なんですが、Windows(32bit)でのOracleな話
・Mac De Oracle なんですが、Windows(32bit)でのOracleな話 #2
・Mac De Oracle なんですが、Windows(32bit)でのOracleな話 #3
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #1
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #2
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #3
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #4
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #5
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #6
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #7
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #8
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #9
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #10
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #11
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #12
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #13
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #14
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #15
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #16
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #17
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #18
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #19
・_pga_max_sizeってOracle11gではどうなったっけ？　という確認。
・_pga_max_sizeってOracle11gではどうなったっけ？　という確認。シーズン２
・pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? Season2 #1
・pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? Season2 #2
・pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? Season2 #3
・pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? Season2 #4
・pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? Season2 #5
・pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? Season2 #6
・pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? Season2 #7
・pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? Season2 #8

・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版

投稿日時 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管理下ではどこまで増加させることができるのか？。。。。確認してみたいと思います。

・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版

投稿日時 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. ・・・略・・・

・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版（その前に少し脱線）

投稿日時 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月24日 (土)

Temp落ち #5 - pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? 12.2.0.1版（その前に少し脱線）

Previously on Mac De Oracle

手動PGA管理下で利用される4つのパラメータ(HASH_AREA_SIZE / SORT_AREA_SIZE / BITMAP_MERGE_AREA_SIZE / CREATE_BITMAP_AREA_SIZE)は、Integer型であり2,147,483,647バイト（つまり2GB - 1)までは指定可能、かつ、個々の作業領域は同程度確保されること。そのサイズを超えるデータ量の場合は一時表領域が利用される。つまり"Temp落ち"が発生するというところまでした。

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

64bit環境でInteger型なので、そんなもんでしょうね。仕様ですからね、こればっかりはどうにもならない。

で、自動PGA管理で確認しようとパタパタ準備していたところ、12.1.0.2まではなかった12.2.0.1での変更点に気付いたので、そちらを先に。
（少し脱線）

pga_aggregate_targetをscope=memoryで設定する際、物理メモリーの空きサイズ以上に設定しようとするとORA-00855エラーなり設定できないよう動作が変更されたようです。

また、spfileにのみ設定する場合には動作が異なり、設定時には、ORA-00855は発生しません。
~~アラートログファイルには、起動時のワーニングとして記録され、~~アラートログにもなにも記録されれず、正常起動しpga_aggregate_targetには指定したサイズで設定されるという、
少々分かりづらい仕様に変わったようです。　（今頃気づくとは、遅い！w

(18cではどうなるんだろう。。なんとなく、Autonomousを意識してるようなアトモスフィアを感じます..が、どうなんでしょうw？)

以下、動作確認の記録。
Guest OSのメモリーサイズは以下の通り。空いているメモリーサイズは500MB〜600MB程度です。

Oracle Database 12c Enterprise Edition Release 12.2.0.1.0 - 64bit Production に接続されました。 orcl12c@SYS> !cat /proc/meminfo | grep Mem MemTotal: 3781732 kB MemFree: 43300 kB MemAvailable: 559076 kB orcl12c@SYS> show parameter sga NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ allow_group_access_to_sga boolean FALSE lock_sga boolean FALSE pre_page_sga boolean TRUE sga_max_size big integer 2G sga_min_size big integer 0 sga_target big integer 2G unified_audit_sga_queue_size integer 1048576 orcl12c@SYS> show parameter pga_agg NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ pga_aggregate_limit big integer 2G pga_aggregate_target big integer 200M

この状態で、pga_aggregate_limitの50%のサイズでpga_aggregate_limitの制限内、pga_aggregate_target=1g としてメモリー上でのみ変更してみると

orcl12c@SYS> alter system set pga_aggregate_target=1g scope=memory; alter system set pga_aggregate_target=1g scope=memory * 行1でエラーが発生しました。: ORA-02097: 指定した値が無効なので、パラメータを変更できません。 ORA-00855: PGA_AGGREGATE_TARGET cannot be set because of insufficient physical memory.

空きメモリーサイズ以下ならどうなるか試して見ます。

orcl12c@SYS> alter system set pga_aggregate_target=500m scope=memory; システムが変更されました。

空きメモリーサイズを多少上回るサイズでは。。。（やはり、ORA-00855となります）

orcl12c@SYS> alter system set pga_aggregate_target=700m scope=memory; alter system set pga_aggregate_target=700m scope=memory * 行1でエラーが発生しました。: ORA-02097: 指定した値が無効なので、パラメータを変更できません。 ORA-00855: PGA_AGGREGATE_TARGET cannot be set because of insufficient physical memory.

scope=bothとなる状態で、空きメモリー以上のサイズを設定しようとしても同様のエラーになりますが.....

orcl12c@SYS> alter system set pga_aggregate_target=1g; alter system set pga_aggregate_target=1g * 行1でエラーが発生しました。: ORA-02097: 指定した値が無効なので、パラメータを変更できません。 ORA-00855: PGA_AGGREGATE_TARGET cannot be set because of insufficient physical memory.

scope=spfileとした場合には、エラーにならず変更可能です。このあたりの動きは、他のパラメータと同様、起動時にエラーで起動しないという動きになるのかな？？？　と思いきや.....
なんと、正常起動し、pga_aggregate_targetにはしっかり、1GBが設定されています。！！！！！　（動きが違う！！！）

orcl12c@SYS> alter system set pga_aggregate_target=1g scope=spfile; システムが変更されました。 orcl12c@SYS> shutdown immediate データベースがクローズされました。データベースがディスマウントされました。 ORACLEインスタンスがシャットダウンされました。 orcl12c@SYS> startup ORACLEインスタンスが起動しました。 Total System Global Area 2147483648 bytes Fixed Size 8794848 bytes Variable Size 603983136 bytes Database Buffers 1526726656 bytes Redo Buffers 7979008 bytes データベースがマウントされました。データベースがオープンされました。 orcl12c@SYS> orcl12c@SYS> show parameter pga_agg NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ pga_aggregate_limit big integer 2G pga_aggregate_target big integer 1G

なぜ、動作が違うんだろう........

2018/2/25訂正
以下のメッセージよくよく見たら、pga_aggregate_limitパラメータへの警告でpga_aggregate_targetのORA-00855とは無関係なワーニングでした。orz.

pga_aggregate_limitの下限値は2G、sea_max_size=2Gなのに、Guest OSへのメモリー割り当て4Gなのでそりゃでるわね。というこでした。

とはいえ、 pga_aggreagte_target scope=memoryとspfileではORA-00855エラーの有無の違いはあるようで、spfileに設定した場合にはORA-00855は発生せず、アラートログファイルには何も記録されていない（謎

なお、起動時のアラートログファイルには以下の"WARNING"メッセージが記録されます。しかも、メッセージを見る限り、pga_aggregate_limit へのワーニングと読めるが....

2018-02-24T22:16:38.907017+09:00 WARNING: pga_aggregate_limit value is too high for the amount of physical memory on the system PGA_AGGREGATE_LIMIT is 2048 MB PGA_AGGREGATE_TARGET is 1024 MB. physical memory size is 3693 MB limit based on physical memory and SGA usage is 1275 MB SGA_TARGET is 2048 MB

おまけ

12.1.0.2までは該当するメッセージはありません。

[oracle@vbgeneric ˜]$ sqlplus -version SQL*Plus: Release 12.1.0.2.0 Production [oracle@vbgeneric ˜]$ oerr ORA 855 [oracle@vbgeneric ˜]$

12.2.0.1で実装されたメッセージと機能だということがわかります。

[oracle@localhost ˜]$ sqlplus -version SQL*Plus: Release 12.2.0.1.0 Production [oracle@localhost ˜]$ oerr ORA 855 00855, 00000, "PGA_AGGREGATE_TARGET cannot be set because of insufficient physical memory." // *Cause: PGA_AGGREGATE_TARGET value was too high for the current system global area (SGA) size and amount of physical memory available. // *Action: Reduce the SGA size or increase the physical memory size.

ということで、次回こそw 自動PGA管理下での確認へ

続く。

・Temp落ち #1 - "Temp落ち" って？
・Temp落ち #2 - PGA (Program Global Area)
・Temp落ち #3 - 手動PGA管理で作業領域として指定可能な最大サイズ
・Temp落ち #4 - 手動PGA管理で作業領域として指定可能な最大サイズ de Temp落ちの確認

投稿日時 2018年2月24日 (土) 23時04分チューニング, FAQ, SQL, パフォーマンス, 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)

2018年2月15日 (木)

Temp落ち #1 - "Temp落ち" って？

ぐるぐる系に並び、一部で人気？w のある俗称、

この、”Temp落ち”とはなんなのでしょうか？（ご存知の方も多いと思いますが）

こんなイメージです。

ざっくり、言ってしまうと、
Hash JoinやSort処理などを”メモリー上”で行おうとします。その際、利用可能なメモリー不足が発生すると一時表領域（HDDやSSDなど）を作業域としてして処理を行います。
この一時表領域も利用しながらHash JoinやSort処理などを行う動きが、"Temp落ち" の正体です。

なぜ可能な限りメモリー上で完結させようとするのか？　
たとえば、HDDを利用したソートとメモリー内のみで同量のソート行ったらどちらが早く終わると思いますか？
ということを考えれば、理由はわかりますよね。

ただ、最近はメモリーも安くなり、大容量のメモリーのサーバーもあり、ぜーんぶオンメモリーでできるじゃん？
と思わなくも無いのですが、

無限にメモリーを利用できるわけでもないく（仕様などにもよる）、データ量の爆発とともに、"Temp落ち”と戦わなければならない場面も多くなってきているような気はします。
また、"Temp落ち"の辛さが認識されていない場合は、大人の事情も絡まって予想以上にめんどくさい状況になることもしばしば。。。

そういえば、某性能問題専門チームへ本格的に参画しはじめたころの最初の戦いが、
”性能試験でTemp落ちして試験にならないというプロジェクトをなんとかする”というやつでしたw （もう７年ぐらい前ですがw）

その時期に調べていた内容をまとめていたのがエントリーが以下のシリーズでした。
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

以下、津島博士のパフォーマンス講座も読んでおくとよいと思います。：）

参考）

津島博士のパフォーマンス講座 - 第36回遅くなるSQLについて

http://www.oracle.com/technetwork/jp/database/articles/tsushima/tsushima-hakushi-36-2184118-ja.html

津島博士のパフォーマンス講座 - 第45回　Temp領域について

http://www.oracle.com/technetwork/jp/database/articles/tsushima/tsushima-hakushi-45-2491038-ja.html

ちなみに、AWRレポートやstatpackレポートなど、一時表領域が利用された"Temp落ち"の有無を確認する方法はいろいろあるのですが、代表的なものをいくつか載せておきますね。

ここで紹介する機能で利用したdatabase 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

12cR2のAWRレポートのTop 10 Foreground Eventsセクションより
インスタンス全体の状態を確認できます。
上位の待機イベントから、一時表領域が多く利用されていたことを知ることができます。
direct path write temp / direct path read tempという待機イベントが上位にきています。この2つの待機イベントは一時表領域への書き込みと読み込みを示す待機イベントです。
一時表領域に書き込まれたデータは、”どのようなタイプのデータ”であるか、この情報からでは判断できませんが、一時表領域を利用する操作が全体の6割近くを占めていることは確認できます。

Top 10 Foreground Events by Total Wait Time ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Total Wait Avg % DB Wait Event Waits Time (sec) Wait time Class ------------------------------ ----------- ---------- --------- ------ -------- direct path write temp 8,688 36.9 4.24ms 50.3 User I/O DB CPU 26 35.4 direct path read temp 8,403 6.2 738.19us 8.5 User I/O direct path read 400 4.1 10.36ms 5.6 User I/O db file sequential read 1,082 1.8 1.66ms 2.4 User I/O control file sequential read 456 1.3 2.80ms 1.7 System I SQL*Net message to client 66,674 .2 2.30us .2 Network PGA memory operation 4,944 .1 25.30us .2 Other log file sync 8 .1 10.55ms .1 Commit db file scattered read 33 .1 1.69ms .1 User I/O

おなじく、12cR2のAWRレポートのPGA Aggr Target Histogramセクションより
インスタンス全体の状態を確認できます。1-Pass/M-Passの部分で一時表領域の利用した操作があったことが確認できます。
GB単位の1-Pass操作（一時表領域を利用した操作）があったことが確認できます。

PGA Aggr Target Histogram DB/Inst: ORCL12C/orcl12c Snaps: 214-216 -> Optimal Executions are purely in-memory operations Low High Optimal Optimal Total Execs Optimal Execs 1-Pass Execs M-Pass Execs ------- ------- -------------- -------------- ------------ ------------ 2K 4K 879 879 0 0 64K 128K 12 12 0 0 128K 256K 14 14 0 0 256K 512K 8 8 0 0 512K 1024K 60 60 0 0 1M 2M 40 40 0 0 2M 4M 1 1 0 0 32M 64M 1 1 0 0 1G 2G 1 0 1 0 ------------------------------------------------------

おなくじ、12cR2のAWRレポートのTop SQL with Top Row Sourcesより
以下の例では、SQLID=g95385r59bm47というSQL文の実行時間の内、50%以上がHash join操作でのdirect path write temp待機イベント（一時表領域への書き込み）であることがレポートされています。
このSQL文のHash Joinでメモリー内では処理しきれないほどの結合操作が行われたことがわかります。

Top SQL with Top Row Sources DB/Inst: ORCL12C/orcl12c Snaps: 214-216 -> Top SQL statements by DB Time along with the top row sources by DB Time for those SQLs. -> % Activity is the percentage of DB Time due to the SQL. -> % Row Source is the percentage of DB Time spent on the row source by that SQL. -> % Event is the percentage of DB Time spent on the event by the SQL executing the row source. -> Executions is the number of executions of the SQL that were sampled in ASH. SQL ID Plan Hash Executions % Activity ----------------------- -------------------- -------------------- -------------- % Row Row Source Source Top Event % Event ---------------------------------------- ------- ----------------------- ------- Container Name ------------------------------------------- g95385r59bm47 1822065247 1 100.00 HASH JOIN 66.67 direct path write temp 50.00 SELECT /*+ MONITOR LEADING(m1 m2) USE_HASH(m1 m2) */ * FROM m1 INNER JOIN m2 ON m1.id = m2.id AN D m1.rev# = m2.rev#

AWRレポート以外では、
v$tempseg_usageを問い合わせることで一時表領域の利用状況をセッション、SQL毎に確認することもできます。
この例では、ブロックサイズは、8KBとしているので、Hash一時セグメントで、3GB程の一時表領域が利用されたことがわかります。

orcl12c@SYS> select con_id,session_num,username,sql_id,segtype,contents,blocks from v$Tempseg_usage order by session_num; CON_ID SESSION_NUM USERNAME SQL_ID SEGTYPE CONTENTS BLOCKS ---------- ----------- ------------------------------ ------------- --------- --------- ---------- 3 26123 SCOTT g95385r59bm47 HASH TEMPORARY 427520

SQLモニター - REPORT_SQL_MONITORファンクション
SQLモニターのMem(Max)/Temp(Max)列でHash joinやSort処理で利用された最大メモリーサイズと最大一時表領域のサイズを確認することができます。
この例ではId=1のHash JoinでTemp(Max) = 3GB より、一時表領域がHash Join操作の作業領域として3GB利用されたことを確認できます。
また、Activity Details列で、direct path write temp / direct path read temp待機イベントの割合も高いため一時表領域へのI/O量をどうするかが性能改善へのポイントであることも確認できます。

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 | | | | 86 | +2 | 1 | 1M | | | | | . | . | 9.52 | Cpu (6) | | 1 | HASH JOIN | | 1M | 382K | 86 | +2 | 1 | 1M | 13302 | 3GB | 13302 | 3GB | 1GB | 3GB | 76.19 | Cpu (10) | | | | | | | | | | | | | | | | | | direct path read temp (4) | | | | | | | | | | | | | | | | | | direct path write temp (34) | | 2 | TABLE ACCESS FULL | M1 | 1M | 90575 | 45 | +2 | 1 | 1M | 2619 | 3GB | | | . | . | 6.35 | Cpu (3) | | | | | | | | | | | | | | | | | | direct path read (1) | | 3 | TABLE ACCESS FULL | M2 | 1M | 90574 | 24 | +46 | 1 | 1M | 2619 | 3GB | | | . | . | 7.94 | Cpu (1) | | | | | | | | | | | | | | | | | | direct path read (4) | =======================================================================================================================================================================================

最後に、SQLモニターはTuning pack と Diagnostic packの両方が必要なのですが、追加パックなしで利用できる機能として、DBMS_XPLAN.DISPLAY_CURSORでActual Planを取得して確認する方法もあります。
DBMS_XPLAN.DISPLAY_CURSOR(format=>'ALL ALLSTATS LAST')でActual Planで確認することもできます。
Used-Mem/Used-Tmpから利用されたメモリーサイズと一時表領域のサイズが確認できます。
ただ、User_Tmpのサイズ単位は、KじゃなくてMなんじゃないか？（バグ？　誰か調べてw）
前述したv$tempseg_usageとSQLモニターで実行したSQL文なのですが....ほかにも単位が変なところがあるみたい。。。まあいいか。（いいわけ無い！w）

Plan hash value: 1822065247 ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | Id | Operation | Name | Starts | E-Rows |E-Bytes|E-Temp | Cost (%CPU)| E-Time | A-Rows | A-Time | Buffers | Reads | Writes | OMem | 1Mem | Used-Mem | Used-Tmp| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | 0 | SELECT STATEMENT | | 1 | | | | 382K(100)| | 1000K|00:00:56.65 | 727K| 1079K| 412K| | | | | |* 1 | HASH JOIN | | 1 | 1000K| 4038M| 2126M| 382K (1)| 00:00:15 | 1000K|00:00:56.65 | 727K| 1079K| 412K| 2047M| 28M| 1049M (1)| 3340K| | 2 | TABLE ACCESS FULL| M1 | 1 | 1000K| 2115M| | 90575 (1)| 00:00:04 | 1000K|00:00:06.79 | 374K| 333K| 0 | | | | | | 3 | TABLE ACCESS FULL| M2 | 1 | 1000K| 1923M| | 90574 (1)| 00:00:04 | 1000K|00:00:01.68 | 352K| 333K| 0 | | | | | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

SQLモニター関連と、Actual Planを取得するサンプルスクリプト（私がよく利用してるやっつけスクリプト）
どちらを利用するかは、必要としている情報次第なのですが、利用できる環境であれば（主にライセンス）、SQLモニターとActual Planを併用することが多いです。（経験上）
SQLモニターは5秒以上の処理時間やパラレル処理を自動的にモニターできるので、利用可能な環境であれば、本番環境で今まさに終わらないSQLとなっているようなSQL文を分析するには便利です。
SQLIDは判明していても、終わらないSQL文の場合は、DBMS_XPLAN.DISPLAY_CORSORでActual Planを取得することは難しい(Actual Planの場合、SQLが正常終了しないと実行統計が取得できない）
ツール毎に、取得できる内容に多少違いがあるので、複数のツールを組み合わせて使うことが多い（ここ重要）

なお、SQLモニターは、対象とするSQL文に　MONITORヒント付加することで強制的にモニタリングすることを前提にしてあります。
（自動的にSQLモニターの対象となる条件は、5秒以上実行されているか、パラレル実行されている場合のみ）

MONITORヒント付加を前提としており、パラメータを空で渡した場合は、直前に実行されたSQLモニター対象のSQLのモニター結果をテキスト形式でレポートします。(sql_idをパラメータとして渡した場合には対象のSQL文がSQLモニターの対象となっている必要があります）
SQLモニタースクリプト

[oracle@localhost ˜]$ cat show_realmon.sql set linesize 1000 set long 1000000 set longchunksize 1000000 select dbms_sqltune.report_sql_monitor(sql_id=>'&1', type=>'text') from dual;

SQLモニタースクリプトの実行例

ORCL@SCOTT> select /*+ monitor */ * from dual; D - X Elapsed: 00:00:00.00 ORCL@SCOTT> @show_realmon '' 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 Text ------------------------------ select /*+ monitor */ * from dual Global Information ------------------------------ Status : DONE (ALL ROWS) Instance ID : 1 Session : SCOTT (123:34510) SQL ID : 2w4nk70tv7w1d SQL Execution ID : 16777216 ・・・中略・・・ Fetch Calls : 1 Global Stats ======================================= | Elapsed | Other | Fetch | Buffer | | Time(s) | Waits(s) | Calls | Gets | ======================================= | 0.00 | 0.00 | 1 | 3 | ======================================= SQL Plan Monitoring Details (Plan Hash Value=272002086) ========================================================================================================================= | Id | Operation | Name | Rows | Cost | Time | Start | Execs | Rows | Activity | Activity Detail | | | | | (Estim) | | Active(s) | Active | | (Actual) | (%) | (# samples) | ========================================================================================================================= | 0 | SELECT STATEMENT | | | | 1 | +0 | 1 | 1 | | | | 1 | TABLE ACCESS FULL | DUAL | 1 | 2 | 1 | +0 | 1 | 1 | | | =========================================================================================================================

Actual Plan取得スクリプト

ORCL@SCOTT> !cat show_actualplan.sql set linesize 1000 set long 1000000 set longchunksize 1000000 select * from table(dbms_xplan.display_cursor(format=>'ALL ALLSTATS LAST'));

Actual Plan取得スクリプトの実行例

ORCL@SCOTT> alter session set statistics_level=all; Session altered. Elapsed: 00:00:00.01 ORCL@SCOTT> select * from dual; D - X Elapsed: 00:00:00.01 ORCL@SCOTT> @show_actualplan PLAN_TABLE_OUTPUT --------------------------------------------------------------------------------------------------------------------- SQL_ID a5ks9fhw2v9s1, child number 0 ------------------------------------- select * from dual Plan hash value: 272002086 -------------------------------------------------------------------------------------------------------------------- | Id | Operation | Name | Starts | E-Rows |E-Bytes| Cost (%CPU)| E-Time | A-Rows | A-Time | Buffers | -------------------------------------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 1 | | | 2 (100)| | 1 |00:00:00.01 | 3 | | 1 | TABLE ACCESS FULL| DUAL | 1 | 1 | 2 | 2 (0)| 00:00:01 | 1 |00:00:00.01 | 3 | -------------------------------------------------------------------------------------------------------------------- Query Block Name / Object Alias (identified by operation id): ------------------------------------------------------------- 1 - SEL$1 / DUAL@SEL$1 Column Projection Information (identified by operation id): ----------------------------------------------------------- 1 - "DUAL"."DUMMY"[VARCHAR2,1] 23 rows selected.

では、つづく。（どういうながれにするかまだ、考えてないけど、ブログ書かないとw）

投稿日時 2018年2月15日 (木) 20時16分 Oracle, チューニング, SQL, Oracle Database 11g Release 2, Oracle Database 12c release 1, Oracle Database 12c Release 2 | 固定リンク | 0 | コメント (0) | トラックバック (0)

2017年11月11日 (土)

SDCLI Error Out "Failed to create the processor for command format"

昨日 Windowsの SQL Developer 17.2のsdcliコマンドで整形しようと思ったらハマったので、備忘録

SDCLI Error Out "Failed to create the processor for command format" (Doc ID 2297353.1)

Oracle SQL Developer - Version 17.2 and later
と記載されているようですが、Version4.2で発生していたのでそのまま新版でも引き続き発生してるという感じですね。
改善されるまでの間、面倒くさいので、Version 4.0.2〜4.1.5あたりをインストールしてSQLを整形したほうがイライラしなくてよいと思います。

discus-mother:bin oracle$ cat version.properties
COMPANY=Oracle
PRODUCT=SQL Developer
VERSION=4.2000170891709f
VER=4.2.0
VER_FULL=4.2.0.17.089.1709
BUILD_LABEL=17.089.1709
BUILD_NUM=17.089.1709
EDITION=
discus-mother:bin oracle$
discus-mother:bin oracle$ sdcli format intput=sample.sql output=sample_fmt.sql

Oracle SQL Developer
Copyright (c) 1997, 2017, Oracle and/or its affiliates. All rights reserved.

Failed to create the processor for command format

私の場合、SQL Developer 4.0.3をインストールしてSQL文整形オンリー使いで回避しました。

参考
SQL Developer 4の素敵なコマンドライン de SQL整形 :)

Note:
ディレクトリ指定の一括変換も動作が怪しいことがあるので、単一のSQL文整形を繰り返すようなshell作ったほうがいいかもしれません。

投稿日時 2017年11月11日 (土) 12時07分チューニング, FAQ, SQL, SQL Developer | 固定リンク | 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みて無い！！
となると、他を探すこともあまりなくなって、結局、コード書いてる場面を多く見てる＞＜　

余談

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

とりあえず、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年10月 6日 (金)

DBMS_SQLTUNE.PACK_STGTAB_SQLSETって、例外投げんのかよw

ということで、タイトル通り
マニュアル上、例外を投げるとは記載されてないのですが、テストしてたら”例外投げる”PL/SQLプロシージャ、意外と多いんですw
意図的に例外投げるよーというのは大抵マニュアルに記載されているんですが。人が書いてますからね、記載漏れも仕方ないっすねぇw　

マニュアルバグ、忘れちゃうので、自分向けFAQ and 備忘録　

Oracle® Database PL/SQLパッケージおよびタイプ・リファレンス　12c リリース1 (12.1)　B71281-05
DBMS_SQLTUNE.PACK_STGTAB_SQLSETプロシージャ

Oracle Database PL/SQL Packages and Types Reference (12.2)のマニュアルには DBMS_SQLTUNE.PACK_STGTAB_SQLSET Procedure は例外を投げるよ！という記載はないが...

DBMS_SQLTUNE.PACK_STGTAB_SQLSET Procedure
DBMS_SQLTUNE.PACK_STGTAB_SQLSET Procedure

orcl@SYS> r 1 SELECT 2 ID 3 ,NAME 4 ,OWNER 5 ,CREATED 6 ,LAST_MODIFIED 7 ,STATEMENT_COUNT 8 FROM 9 dba_sqlset 10 ORDER BY 11 OWNER 12 ,CREATED 13* ID NAME OWNER CREATED LAST_MODI STATEMENT_COUNT ---------- ------------------------------ ------------------------------ --------- --------- --------------- 1 STS201710052340431 SYS 05-OCT-17 05-OCT-17 0 2 STS201710061431151 SYS 06-OCT-17 06-OCT-17 2

statement_count=0と2の2つのSTS(SQL Tuning Set)があります。
STS(SQL Tuning Set)については、ここでは記載しませんが、何それ？　気になる、気になる〜という方は、
Oracle Database の STS(SQL Tuning Set) を活用して、SQL の性能統計や実行計画をキャプチャする。を覗いて見てください。

（次回のネタは思いっきりそこなので、予習にもなりますよ :）

例外を投げるとはマニュアルに記載されてないプロシージャが実は例外投げるじゃん！　
というケースは、dbms_sqltune.pack_stgtab_sqlset以外にもあるんですが、
急ぎのやっつけ仕事で遭遇すると、ここで見つかってよかった！！
という安堵感とともに、
ムカ〜〜〜〜っという憎悪も湧いてくるわけですw　
（何れにしてもテストはしっかりやりましょうw

以下、例外投げるとは書かれてないけど、投げるじゃん、dbms_sqltune.pack_stgtab_sqlset　の簡易テストの記録

準備として、dbms_sqltune.pack_stgtab_sqlsetは、STSを退避する為に必要なステージング表を作成します。

orcl@SYS> exec dbms_sqltune.create_stgtab_sqlset(table_name=>'TEST',schema_name=>'STSUSR'); PL/SQL procedure successfully completed.

statement_count=0つまり、STSに記録されたSQLの情報がない場合です。
ワーニングとしての意味が強いと思われますが、ORA-15701が投げつけられて、STSが空だということを教えてくれます！ :)
マニュアルには記載されてなかったので焦りますw　実際のところざっくり書いたコードではこの例外をハンドリングなんてしてませんでした。

orcl@SYS> l 1 begin 2 dbms_sqltune.pack_stgtab_sqlset( 3 sqlset_name=>'STS201710052340431' 4 ,sqlset_owner=>null 5 ,staging_table_name=>'TEST' 6 ,staging_schema_owner=>'STSUSR' 7 ); 8* end; orcl@SYS> / begin * ERROR at line 1: ORA-15701: All "SQL Tuning Set(s)" with name like "STS201710052340431" and owner like "SYS" are empty ORA-06512: at "SYS.DBMS_SQLTUNE", line 5398 ORA-06512: at "SYS.DBMS_SQLTUNE", line 7928 ORA-06512: at line 2

一方、statement_count=2でSTSに記録されたSQLがある場合、つまり、STSは空じゃない場合は正常終了します。

orcl@SYS> l 1 begin 2 dbms_sqltune.pack_stgtab_sqlset( 3 sqlset_name=>'STS201710061431151' 4 ,sqlset_owner=>null 5 ,staging_table_name=>'TEST' 6 ,staging_schema_owner=>'STSUSR' 7 ); 8* end; orcl@SYS> / PL/SQL procedure successfully completed.

STSが空だという例外を拾って、後続処理にあるであろう、ステージング表のエクスポートとかをバイパスしたりすることはできますね:)

dbms_sqltune.pack_stgtab_sqlsetは、STSが空だと例外投げるよ　というお話でした。

To be continued...

投稿日時 2017年10月 6日 (金) 19時32分 Oracle, PL/SQL, チューニング, SQL, Oracle11g R2, Oracle12c R1 | 固定リンク | 0 | コメント (0) | トラックバック (0)

2017年7月29日 (土)

SQLとPL/SQLで「モルダー、あなた疲れてるのよ」を出力する方法

もうかれこれ1年以上経過しているので、何を今更という感じがしないでもないですがw

ここ２週間くらい、SQLチューニングじゃない方向で、非常に忙しかったこともあり

気分的に疲れてしまったので、気分転換のために作ってみました。

Ruby でモルダー、あなた疲れてるのよを出力する方法

Pythonでモルダー案件

Groovyで「モルダー、あなた疲れてるのよ」に対処する

と、どう見てもPL/SQLやSQL案件ではないネタですが、PL/SQL de Python Challenge精神（どんな精神じゃw)で無理やり案件化して見ました。

疲れてる時に疲れるネタやるの？、バカなの？　
とお感じの方もお多いかと存じますが、可能ならもっと変態的なネタに発展することを願いつつ、ご挨拶と代えさせていただきます

データベースエンジニアでも、「モルダー、あなた疲れてるよの」をという文字列を出力させる無茶振り案件に突っ込まれるかもしれません。
そんなときの参考になれば幸いです。

スペースで区切ったワードをシャッフルし、「モルダー、あなた疲れてるのよ」が出力されたら終了です。

色々な「モルダー、あなた疲れてるのよ」がありますので、よろしくお願いします！

Oracle Database 12c Enterprise Edition Release 12.2.0.1.0 - 64bit Production
に接続されました。
orcl@SYSTEM> @mulder_you_tired

スカリーより
--------------------------------------------------------------------------------
1: 疲れてる、あなたのよモルダー
2: のよ、あなたモルダー疲れてる
3: モルダー、疲れてるあなたのよ
4: 疲れてる、あなたモルダーのよ
5: モルダー、あなたのよ疲れてる
6: のよ、あなたモルダー疲れてる
7: 疲れてる、モルダーあなたのよ
8: モルダー、のよ疲れてるあなた
9: のよ、疲れてるモルダーあなた
10: 疲れてる、のよモルダーあなた
11: モルダー、あなたのよ疲れてる
12: のよ、疲れてるあなたモルダー
13: モルダー、のよあなた疲れてる
14: 疲れてる、あなたのよモルダー
15: 疲れてる、あなたモルダーのよ
16: モルダー、あなたのよ疲れてる
17: のよ、あなたモルダー疲れてる
18: モルダー、あなた疲れてるのよ

コードは以下のとおり、WITH FUNCTIONで文字列を生成しCLOBで１行で返しています。
改行コード(UTL_TCP.CRLFを利用、UTL_TCPパッケージなんて使っている人は少ないと思いますがw）を付加し出力時に改行させ複数行に見せています。
WITH FUNCTIONをSELECT文のセレクトリスト部分で利用しています。(TABLE FunctionならFROM句で使えますが、TABLE Functionではないので）

09:54:34 orcl@SYSTEM> !cat mulder_you_tired.sql
set long 100000
set pagesize 10000
WITH function mulderYouAreTired (dummy char)
RETURN CLOB
IS
cMulderYouTired CONSTANT VARCHAR2(42) := 'モルダー、あなた疲れてるのよ';
vMessage VARCHAR2(42);
vMessageFromScully CLOB := EMPTY_CLOB();
line# BINARY_INTEGER := 1;
--
FUNCTION generateMessage
RETURN VARCHAR2
IS
TYPE word_arr IS TABLE OF VARCHAR2(12) INDEX BY BINARY_INTEGER;
cPunctuation CONSTANT CHAR(3) := '、';
vWords VARCHAR2(45) := 'モルダーあなた疲れてるのよ';
vMessageFromScully VARCHAR2(42);
vMessage word_arr;
vWord VARCHAR2(13);
isSetWord BOOLEAN := FALSE;
idx BINARY_INTEGER := 1;
BEGIN
--
FOR i IN 1..REGEXP_COUNT(vWords, ' ') + 1 LOOP
vMessage(i) := NULL;
END LOOP;
--
WHILE INSTR(vWords, ' ') != 0 LOOP
vWord := SUBSTR(vWords, 1, INSTR(vWords, ' '));
vWords := REPLACE(vWords, vWord);
isSetWord := FALSE;
WHILE NOT isSetWord LOOP
idx := TRUNC(DBMS_RANDOM.VALUE(vMessage.FIRST, vMessage.LAST + 1));
IF vMessage(idx) IS NULL THEN
vMessage(idx) := TRIM(vWord);
isSetWord := TRUE;
END IF;
END LOOP;
END LOOP;
--
FOR j IN vMessage.FIRST..vMessage.LAST LOOP
IF vMessage(j) IS NULL THEN
vMessage(j) := vWords;
END IF;
END LOOP;
--
FOR x IN vMessage.FIRST..vMessage.LAST LOOP
IF x = 2 THEN
vMessageFromScully := vMessageFromScully || cPunctuation;
END IF;
vMessageFromScully := vMessageFromScully || vMessage(x);
END LOOP;
RETURN vMessageFromScully;
END generateMessage;
BEGIN
LOOP
vMessage := generateMessage();
vMessageFromScully :=
vMessageFromScully || TO_CHAR(line#)
|| ': ' || vMessage || UTL_TCP.CRLF;
line# := line# + 1;
EXIT WHEN vMessage = cMulderYouTired;
END LOOP;
RETURN vMessageFromScully;
END;
SELECT
mulderYouAreTired(null) AS "スカリーより"
FROM
dual;
/

投稿日時 2017年7月29日 (土) 11時05分 PL/SQL, SQL, Oracle Database 12c release 1, Oracle Database 12c Release 2 | 固定リンク | 0 | コメント (0) | トラックバック (0)

2017年7月12日 (水)

SQLチューニング祭りの記録-随時更新（祭りじゃないのもあるけど）

Oracle DatabaseのSQLチューナーとしてのデビューは2005年ぐらいで、ちょうど12年:)
Twitterで結果報告？w　するようになったのは2011年ごろから。

なんだか当時のプロジェクトを思い出して、あんな人いたっけなー、などと思い出しながら、ニヤニヤしてましたw

SQLチューニング祭りにも色々ありますが、お祭りと化す状況だと、ほとんどの場合、

SQL文書き換えたくない

ビームが放たれることが多いんですが、
最終的に必要最低限ということで、ヒントは使えることは多いんですよね。
（外科的手術が必要なSQLの遅延もあります。。。けどね）

SPMという手もありますが、そもそもハードパースが遅いとSPMどころじゃなかったりw

疲れすぎて、twするのも忘れっちゃったりするので、twしたやつは随時更新予定:)

年月ネン＃ Before Tuning(ms) After Tuning(ms) 改善カイゼン（倍）バイ

2011/10 1 6,000 10 600

2011/10 2 5,780 10 578

2011/10 3 170 60 3

2011/11 4 30 10 3

2011/11 5 485 1 485

2011/11 6 890 10 89

2011/11 7 900,500 2,500 360

2011/11 8 170 10 17

2011/11 9 1,560 1 1,560

2011/11 10 1,890 33 57

2011/12 11 10,800,000 3,000 3,600

2012/01 12 58,000 1,000 58

2012/06 13 1,080,000 1,000 1,080

2012/08 14 1,800,000 50 36,000

2012/12 15 18,000,000 7,000 2,571

2012/12 16 7,300,000 17,000 429

2013/01 17 21,600,000 180,000 120

2013/01 18 4,000 10 400

2013/03 19 1,100 10 110

2013/06 20 234,000,000 120,000 1,950

2013/08 21 5,000 400 13

2013/08 22 50,400,000 1,620,000 31

2013/08 23 6,000,000 70,000 86

2013/09 24 32,000 420 76

2014/03 25 191 2 96

2014/05 26 14,400,000 90,000 160

2014/05 27 40,000 2,000 20

2014/05 28 320,000 8,000 40

2014/06 29 17,000 3,000 6

2016/02 30 2,000,000 10 200,000

2016/04 31 24,000 400 60

2016/05 32 10,000 40 250

合計ゴウケ 368,808,766 2,125,987 173

番外編

2011/11

つぶやき忘れてた。結果は…
分析関数で改善！ Consistent Get 1/3になった。
分析関数万歳w　
RT @discus_hamburg "んー分析関数で改善できそうな気がするが
今日は解ききれなかった残念。続けは来週:)" #SQLチューニング祭り

今日は２５本やっつけた #SQLチューニング祭り

索引オンリースキャンかつ、索引どうしのハッシュ結合にして、
パラレルヒントで締めると。今日も満足な結果 #SQLチューニング祭り

お祭りっぽくなってまいりましたよw 少しずつ #SQLチューニング祭り

さあ、SQLがそこそこ回り始めたら
Free Buffer waitsキター #SQLチューニング祭り

enq: TX - row lock contention か
プログラムつくりなおして！ #SQLチューニング祭り

なんちゃって単性能試験の成果が出て来た様ですね。
アンチパターン #SQLチューニング祭り

2011/12
ビューの使い方良くないなー、索引ないし、おまけに無駄な自己結合で7000秒超え、
分析関数と索引張ってインデックスオンリースキャンさて、どうなるか:) #SQLチューニング祭り

@discus_hamburg クエリ見ればヤバいのわかりそうなもんだが。
まぁ、だから、祭りになるわけやね。
#SQLチューニング祭り　というかAPチューニング祭りw

2012/1
楽観的すぐる楽観的排他ロックの仕様を生温かく眺める簡単なお仕事w

enq : RO - fast object reuse

local write wait

free buffer wait

DBWが過労死か、疲労骨折するんじゃないかと思う程度に働かせてるw

DBW0, DBW1, DBW2, DBW3 DBW4....DBW7 Zzzzzz

2012/2
no_indexヒントを使わずに使って欲しくない索引を使わせないチューニング #SQLチューニング祭り

ただでさえ、あれなのに、merge文禁止プロジェクトでBYPASS_UJVCはやばいっしょw

ASMM下でPGA_AGGREGATE_TARGETの上限設定できないから、SGA_TARGETを大きめに設定して抑えるか。。。

今日はoracle11g のバグ2つに体当たりされたので、ロケットドリルキックしたった

プロジェクト的にそんな状況ではないのに、
なにかしらイベントをクリアすると打ち上げとかいう偉い人は、
自分一人で宇宙まで打上ちゃってほしいと思ったよ、マジで。

結局私が金曜日に提示した案をなぞっただけこといってるのでガッカリw

だるまさんが転んだ、程度の話が、だるまさんが癌になった程度の話になってて、
アクション会議とかメール来たので。
だるまさんが転んだだけかからというメールを返しといたw

今日もindex only scan

2012/3
約 18,800,000 件（0.19 秒） index only scan

豆腐の角じゃなくて、小田さんの本の角に頭ぶつけて…以下自粛w

仕様的にどーしよーもないね。SQLもオラクルも悪くない。すべては人ですよ、人。w

grouping setsとかwindow関数とか分析関数とかいったら目が点になってたぉ。＞＜

仮想列便利な。

駆動表を見極める力は必要ね #SQLチューニング

2012/4
バグを改修したSQL文が大遅延という強敵。バグを修正するのはいいけど
性能は二の次どころか３でも４にも、かけらもない件＞＜

ボスキャラ倒せそうに無いので IQとかどうよみたいな話しにならんかな

ボスキャラを他の手段で封印したのと小物も退治したら気が抜けてドット疲れがでたので
今日は一回休みw.
大事なことなんで言っておきますが封印しただけだからね。
封印解ければ暴れるお。

ボスキャラ封印されてるので周が平和なatmosphere 😄
封印されてるだけだから油断しないようにね。
鳥居とか封印の文字書いたお札貼るとか必要かもね。
忘れないようにするために:)

2012/5
メモメモ人生フルスキャン #jpoug

2012/6
うまく使われているNULLはいい仕事してますよ。　
NULLとハサミは使いよう。
NULLとハサミは使いよう。
大切なので二回言っときました。

テーブル全舐め　(業界用語w)

XXLOGテーブルなのにバシバシUPDATEする仕様ってなんなの！。LOG改ざんw

2012/7
DBWRの数自慢が聞きたいw

大人のkill session @kouji_s_0808 #jpoug

2012/8
湘南ワンライナー

今日のチューニングはヒントと書き換えだけだったんだぉ。
Index Onlyにするまでもなかったv

use_concatだとunionに展開してくれても使えるはずの索引を使わないことがある。
そんな時は、use_concatに頼らず、男らしくunionに書き換える。
あら不思議、索引使い始めるとかね。

ERD知りませんといわれたの ><

SHA-1の結果を文字列として格納するということだが、
VARCHAR2(4000)としちゃう理由を教えてくれw

2012/9
NULLより、そのヌルポをなんとかしろ的な状況とみた。

新しく来た人達、いいね。このERDダメでしょっていってdisったら
普通に受けてて安心した。普通っていいね。

SQLの実行計画が逆劇的ビフォーアフター。何ということでしょうw

2012/11
DBWR transaction table writesすげえな

お呼ばれして、フォルダを開く＞Excelのドキュメントのアイコンが並んでる
＞嫌な予感＞開く＞ERDを頑張って書いたんだなーと泣けた
＞嫌な予感は正しかった＜イマココ

今日のチューニングポイント。隠れ肥満！

PL/SQLのSQLレビュー、2日で３００本超えた。キツイw けどひとまずやり切ったので蛙、準備など

再帰問合せと階層問合せの違いが…実行計画に現れるんですよね。Oracle :)

96503000 rows なう。

グルグル🌀系が降ってきた (@@)

2013/1
/*+ NO_MERGE NO_PUSH_PRED */ で華麗に回避 :)

ソートはないけどやっぱり遅いよな、スカラー副問い合わせがグルグルしてると。
11gr2だとdirect path readになるかどうかでも多分差はでるな

ディスクソートは強敵w

SQLの実行計画を見て欲しいと言ってもSQLは送ってきたが
接続ホストやユーザーというより接続情報が足りないというアンチパターンw

2013/2
テストケース5件じゃ足りないよねとツッコミいれて修正されてきたテストケースが50件だとーーー
どんだけ手抜いてんだ(しろめ

2013/4
CPUなんて全然使ってないI/Oバウンドなシステムなのに、
h/w入れ替えでディスクの容量増やして、
玉数へらし、CPUはいいものを入れました(キリッ！。

シリアル処理だもん、そりゃCPU1つしか使わんでしょうよ

机上のcron

だれも正解は持ってない。いくつの有益なネタを持っているだけ。
だから早く試せよ。

2013/6
no_use_hash_aggregation

2013/8
SQLチューニングの基礎を飛ばして、Exaだからという事をいうのは素人という結論。
結局、あと１０秒、２０秒というところの戦いは基本的なチューニングテクニックなんだからね！

17分に1SQL程度の速度で解析中

今日は97本のSQLをやっつけましたとさ

2013/9
人間オプティマイザもオプティマイザの一種なので、
統計情報が正確じゃないと間違った実行計画をたてちゃいますよ。と。

昨日は久々に高さ調整ヒストグラムまで見た。
ただ、それだけでは、判断できないぐらいトリッキーな仕掛けのあるエンティティである。
どうみてもRDBの設計じゃない。

2013/10
大量にデータがヒットするのにスカラー副問い合わせはダメなんだよな、黙ってouter joinしてくれた方がいい。
例外はあるけど。
scalar subquery unnesting transformationって美味しそうななんだけど。
自分で書き換えてね今はw

2014/3
1億件のシードデータを10倍にする簡単なお仕事。

2014/5
いろいろ結合順序を考えたが最初に考えたやつが最良だった:)
パズル疲れた

オプティマイザもこんなに
結合されると、むーりーな感じだし、統計情報と大きく乖離してて
dynamic sampling されてるし、もー、このクエリーバラバラにしてやるーっ。
no_mergeでね:p

2016/2
んーっ。SQL見た目は短いーーと思って油断したw
ビューの結合だらけw
これだけで今日が終わりそう orz

2016/5
unnestヒントで0.6秒にして華麗に回避w
でも、多分、今だけかと:)

2016/6
150倍の改善
#SQLチューニング
1勝1敗

ここ1ヶ月ばかり、オプティマイザ統計情報と、にらめっこしてて、
笑ってしまったので、俺の負けな感じがするw

2016/7
1秒という性能要件を意識してるとは思えないSQL w

投稿日時 2017年7月12日 (水) 07時03分 Oracle, チューニング, SQL, SQLチューニング祭り | 固定リンク | 0 | コメント (0) | トラックバック (0)

2017年6月17日 (土)

SQL Developer de Real time SQL monitoring / FAQ

Oracle Database 12c EEかつ、Diagnostic Pack / Tuning Packもあるのに
SQL real time monitoringしないのはもったいないという話から、
http://www.oracle.com/technetwork/jp/ondemand/db-basic/d-16-ssqltuning-1448439-ja.pdf

EMなくても簡単にできないのか？　

と聞かれたので

おすすめなのが、SQL Developer

SQL Developer 4.2
http://www.oracle.com/technetwork/jp/developer-tools/sql-developer/downloads/index.html

テキストよりGUIでという方にはおすすめ。

細けーはなしはいつか書くつもりですが、とりあえず、こんなことを確認できるんでっす。

！！！！！ここ重要！！！！！
以下のダイアログには、Tuning Packが必要とありますが、Tuning Packを利用するにはDiagnostic Packが必要なので、　Real time SQL monitoringを行うには、Diagnostic PackとTuning Packの両方が必要というこなので、間違わないようにしてくださいませ。マニュアルにはしっかり書かれてますが、折角ダイアログで警告してるのにコメントが残念な。
https://docs.oracle.com/cd/E57425_01/121/DBLIC/options.htm#CIHFIHFG

投稿日時 2017年6月17日 (土) 12時21分 Oracle, チューニング, FAQ, SQL, SQL Developer | 固定リンク | 0 | コメント (0) | トラックバック (0)

2017年4月 3日 (月)

CDBとPDBの間で迷子になりそう　PART3 - containers clause - その3

Previously on Mac De Oracle.

AWRでなんとか発行したSQL文以外に、containers句を元とする再帰SQL文を捕まえられたのはいいが、その再帰SQL文と元となるcontainers句を紐づけることが難しそう。
また、ヒントでチューニングするのも難しそう（これはそれっぽいのがあるけどまだ調べてないのでどこまでできるのか未知の領域）。
できるとすれば、SPMによるチューニングかな？、というところまではなんとか見えてきました。

AWRではcontainers句で生成される再帰SQL文を特定するのに難ありというところまでは見えてきたので、
最後の希望w　SQLトレースはどうなのか、気になっていたので試した見た。
（利用している表とSQL文は多少変えていますが、大きな差はありません）

SQLトレースをセッションレベルで有効化して（トレースファイルを特定しやすくしておくことをお忘れなく）、containers句を含むSQL文を実行して、SQLトレースを無効化。

orcl12c@C##HOGE> alter session set tracefile_identifier=containers;
orcl12c@C##HOGE> exec dbms_monitor.session_trace_enable(waits=>true);

PL/SQL procedure successfully completed.

orcl12c@C##HOGE> select * from containers(hoge) where id in (1,3);

ID DATA CON_ID
---------- -------------- ----------
3 test3 4
1 test1 3

orcl12c@C##HOGE> exec dbms_monitor.session_trace_disable;

ここで、前々回、SQL監視のParallel Execution Detailsセクションをみてみると、スレーブプロセスがどうなっていたかわかりやすいですね！

Parallel Execution Details (DOP=4 , Servers Allocated=4)
==========================================================================================
| Name | Type | Server# | Elapsed | Cpu | Other | Buffer | Wait Events |
| | | | Time(s) | Time(s) | Waits(s) | Gets | (sample #) |
==========================================================================================
| PX Coordinator | QC | | 0.00 | 0.00 | 0.00 | | |
| p000 | Set 1 | 1 | 0.00 | 0.00 | | | |
| p001 | Set 1 | 2 | 0.00 | | 0.00 | | |
| p002 | Set 1 | 3 | 0.00 | | 0.00 | 3 | |
| p003 | Set 1 | 4 | 0.00 | 0.00 | | 3 | |
==========================================================================================

SQLトレースファイルも各プロセスごとの取得されていることがわかります!!!
contrainers句から生成される再帰SQLはAWRレポートより見つけやすいかもしれない（個人差はあると思われるw） :)

Cp000〜p003と前述のSQL監視の情報と合わせて見ると多少は見やすいですよね。（AWRレポートのみで捉えることと比べたら遥かに面倒だとは思いますが）

[oracle@vbgeneric admin]$ cd $ORACLE_BASE/diag/rdbms/orcl12c/orcl12c/trace/
[oracle@vbgeneric trace]$ ls -l *CONTAINERS*
-rw-r----- 1 oracle oinstall 95231 4月 1 11:36 orcl12c_ora_4609_CONTAINERS.trc
-rw-r----- 1 oracle oinstall 875 4月 1 11:36 orcl12c_ora_4609_CONTAINERS.trm
-rw-r----- 1 oracle oinstall 23140 4月 1 11:36 orcl12c_p000_3375_CONTAINERS.trc
-rw-r----- 1 oracle oinstall 197 4月 1 11:36 orcl12c_p000_3375_CONTAINERS.trm
-rw-r----- 1 oracle oinstall 2942 4月 1 11:36 orcl12c_p001_3377_CONTAINERS.trc
-rw-r----- 1 oracle oinstall 149 4月 1 11:36 orcl12c_p001_3377_CONTAINERS.trm
-rw-r----- 1 oracle oinstall 98455 4月 1 11:35 orcl12c_p002_3379_CONTAINERS.trc
-rw-r----- 1 oracle oinstall 705 4月 1 11:35 orcl12c_p002_3379_CONTAINERS.trm
-rw-r----- 1 oracle oinstall 168368 4月 1 11:35 orcl12c_p003_3381_CONTAINERS.trc
-rw-r----- 1 oracle oinstall 1138 4月 1 11:35 orcl12c_p003_3381_CONTAINERS.trm
[oracle@vbgeneric trace]$

とりあえず、のぞいて見ましょう。

[oracle@vbgeneric trace]$ tkprof orcl12c_ora_4609_CONTAINERS.trc orcl12c_ora_4609_container.txt explain=system/oracle@orcl12c sys=yes waits=yes

TKPROF: Release 12.1.0.2.0 - Development on Sat Apr 1 11:47:26 2017

Copyright (c) 1982, 2014, Oracle and/or its affiliates. All rights reserved.

[oracle@vbgeneric trace]$ tkprof orcl12c_p000_3375_CONTAINERS.trc container_p000.txt explain=system/oracle@orcl12c sys=yes waits=yes

・・・中略・・・

[oracle@vbgeneric trace]$ tkprof orcl12c_p003_3381_CONTAINERS.trc container_p003.txt explain=system/oracle@orcl12c sys=yes waits=yes

TKPROF: Release 12.1.0.2.0 - Development on Sat Apr 1 11:47:26 2017

Copyright (c) 1982, 2014, Oracle and/or its affiliates. All rights reserved.

[oracle@vbgeneric trace]$ ls -l *container*
-rw-r--r-- 1 oracle oinstall 47736 4月 1 11:47 orcl12c_ora_4609_container.txt
-rw-r--r-- 1 oracle oinstall 7104 4月 1 11:47 container_p000.txt
-rw-r--r-- 1 oracle oinstall 5228 4月 1 11:47 container_p001.txt
-rw-r--r-- 1 oracle oinstall 34869 4月 1 11:47 container_p002.txt
-rw-r--r-- 1 oracle oinstall 38321 4月 1 11:48 container_p003.txt
[oracle@vbgeneric trace]$

最初にorcl12c_ora_4609_container.txtから見てみますか。
SQLトレースを有効化して、containers句を含むSQL文を発行、それに伴いいくつかの再帰SQL文、最後にSQLトレースを無効化してる流れは確認できます。
途中、再帰SQLとしてhoge表を問い合わせるために利用すると思われるSQL文をパースだけしているとみられる箇所。興味深いです:)

・・・中略・・・

SQL ID: g2nujq01pmynd Plan Hash: 0

SELECT /* */ *
FROM
"C##HOGE"."HOGE"

call count cpu elapsed disk query current rows
------- ------ -------- ---------- ---------- ---------- ---------- ----------
Parse 1 0.00 0.00 0 0 0 0
Execute 0 0.00 0.00 0 0 0 0
Fetch 0 0.00 0.00 0 0 0 0
------- ------ -------- ---------- ---------- ---------- ---------- ----------
total 1 0.00 0.00 0 0 0 0

Misses in library cache during parse: 1
Optimizer mode: CHOOSE
Parsing user id: SYS (recursive depth: 1)
********************************************************************************
・・・中略・・・

この部分実際にPDBで実行される想定の再帰SQL文に近いけど、件数カウントしてるだけ..なんですね。なんで件数が必要なんだろ

SELECT count(*)
FROM
C##HOGE."HOGE" "HOGE" WHERE "HOGE"."ID"=1 OR "HOGE"."ID"=3

call count cpu elapsed disk query current rows
------- ------ -------- ---------- ---------- ---------- ---------- ----------
Parse 1 0.00 0.00 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 0 0.00 0.00 0 0 0 0
------- ------ -------- ---------- ---------- ---------- ---------- ----------
total 2 0.00 0.00 0 0 0 0

Misses in library cache during parse: 1
Optimizer mode: CHOOSE
Parsing user id: SYS (recursive depth: 1)
Number of plan statistics captured: 1

Rows (1st) Rows (avg) Rows (max) Row Source Operation
---------- ---------- ---------- ---------------------------------------------------
0 0 0 SORT AGGREGATE (cr=0 pr=0 pw=0 time=14 us)
0 0 0 CONCATENATION (cr=0 pr=0 pw=0 time=7 us)
0 0 0 INDEX UNIQUE SCAN SYS_C0010012 (cr=0 pr=0 pw=0 time=4 us)(object id 93050)
0 0 0 INDEX UNIQUE SCAN SYS_C0010012 (cr=0 pr=0 pw=0 time=0 us)(object id 93050)

********************************************************************************
・・・中略・・・

そして実際にタイプしたSQL文の登場
実行計画は実行しているSQL文からは想像できない変わり果てた姿となっていて、実際に参照する表やオペレーションではなく、hoge表をアクセスしてる実行計画ではないのは見ての通り。

SQL ID: 25a37y74xrat4 Plan Hash: 1439328272

select *
from
containers(hoge) where id in (1,3)

call count cpu elapsed disk query current rows
------- ------ -------- ---------- ---------- ---------- ---------- ----------
Parse 1 0.00 0.00 0 3 1 0
Execute 1 0.00 0.01 0 0 0 0
Fetch 2 0.00 0.12 0 0 0 2
------- ------ -------- ---------- ---------- ---------- ---------- ----------
total 4 0.01 0.14 0 3 1 2

Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 103 (C##HOGE)
Number of plan statistics captured: 1

Rows (1st) Rows (avg) Rows (max) Row Source Operation
---------- ---------- ---------- ---------------------------------------------------
2 2 2 PX COORDINATOR (cr=0 pr=0 pw=0 time=133547 us)
0 0 0 PX SEND QC (RANDOM) :TQ10000 (cr=0 pr=0 pw=0 time=0 us cost=-9223372036854775808 size=78 card=1)
0 0 0 PX PARTITION LIST ALL PARTITION: 1 254 (cr=0 pr=0 pw=0 time=0 us cost=-9223372036854775808 size=78 card=1)
0 0 0 FIXED TABLE FULL X$CDBVW$ (cr=0 pr=0 pw=0 time=0 us cost=-9223372036854775808 size=78 card=1)

パラレルクエリーの各スレーブプロセスはどうかというと...

p000のトレース（抜粋）

rowsが0、Fetch countも0、ふーん、なるほど。

SQL ID: 25a37y74xrat4 Plan Hash: 1439328272

select *
from
containers(hoge) where id in (1,3)

call count cpu elapsed disk query current rows
------- ------ -------- ---------- ---------- ---------- ---------- ----------
Parse 1 0.00 0.00 0 0 0 0
Execute 1 0.00 0.06 0 0 0 0
Fetch 0 0.00 0.00 0 0 0 0
------- ------ -------- ---------- ---------- ---------- ---------- ----------
total 2 0.00 0.06 0 0 0 0

Misses in library cache during parse: 0
Optimizer mode: ALL_ROWS
Parsing user id: 103 (C##HOGE) (recursive depth: 1)
Number of plan statistics captured: 1

Rows (1st) Rows (avg) Rows (max) Row Source Operation
---------- ---------- ---------- ---------------------------------------------------
0 0 0 PX COORDINATOR (cr=0 pr=0 pw=0 time=0 us)
0 0 0 PX SEND QC (RANDOM) :TQ10000 (cr=0 pr=0 pw=0 time=0 us cost=-9223372036854775808 size=78 card=1)
0 0 0 PX PARTITION LIST ALL PARTITION: 1 254 (cr=2 pr=0 pw=0 time=56179 us cost=-9223372036854775808 size=78 card=1)
0 0 0 FIXED TABLE FULL X$CDBVW$ (cr=2 pr=0 pw=0 time=53500 us cost=-9223372036854775808 size=78 card=1)

AWR SQLレポートで捕まえた再帰SQL文、これで実際に表をアクセスしてデータを取得していると考えられる。
OR句は、index unique scanをUNION、ヒントだと USE_CONCATヒントを利用したのと同じ実行計画になってる。

Fetch=1で、rows=0、ふふふーん。　0件ということは、これはデータなし！、どちらのPDBにもヒットするデータが１件ある。
データがないのは、SEEDとCDBのみなので、それのいずれかということ。

そして、HOGEという表は、CDB$ROOTと残る２つのPDBにある。また、CDB$ROOTのHOGE表はcontainers句を動作させるための前提条件なので空の表！

なので、p000はROOT$CDBのHOGE表を問い合わせていることになる！！！のか？！

SQL ID: 1u03tbqvywyf8 Plan Hash: 3444470255

SELECT /*+ RESULT_CACHE (SYSOBJ=TRUE SHELFLIFE=30) */ ID,DATA
FROM
"C##HOGE"."HOGE" "HOGE" WHERE "HOGE"."ID"=1 OR "HOGE"."ID"=3

call count cpu elapsed disk query current rows
------- ------ -------- ---------- ---------- ---------- ---------- ----------
Parse 1 0.00 0.00 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 1 0.00 0.00 0 2 0 0
------- ------ -------- ---------- ---------- ---------- ---------- ----------
total 3 0.00 0.00 0 2 0 0

Misses in library cache during parse: 1
Optimizer mode: CHOOSE
Parsing user id: SYS (recursive depth: 2)
Number of plan statistics captured: 1

Rows (1st) Rows (avg) Rows (max) Row Source Operation
---------- ---------- ---------- ---------------------------------------------------
0 0 0 RESULT CACHE 2fmgs0vhj7brb4c44nkh7shu6f (cr=2 pr=0 pw=0 time=76 us)
0 0 0 CONCATENATION (cr=2 pr=0 pw=0 time=38 us)
0 0 0 TABLE ACCESS BY INDEX ROWID HOGE (cr=1 pr=0 pw=0 time=19 us)
0 0 0 INDEX UNIQUE SCAN SYS_C0010012 (cr=1 pr=0 pw=0 time=11 us)(object id 93050)
0 0 0 TABLE ACCESS BY INDEX ROWID HOGE (cr=1 pr=0 pw=0 time=10 us)
0 0 0 INDEX UNIQUE SCAN SYS_C0010012 (cr=1 pr=0 pw=0 time=2 us)(object id 93050)

p001のトレース（抜粋）

不思議ですが、これは、元のクエリーがあるけど、データを取得する SQLID=1u03tbqvywyf8（前述したRESULT_CACHEヒントのついてるクエリ）が生成されていない！！
containers句を含むクエリのみあり、rowsも0、HOGEをといあわせる再帰SQL文を生成する必要のない表。HOGE表が存在しないのは今のところSEEDのみ。
HOGE表が存在しないので、　C##HOGE.HOGE表をアクセスするSQL文を実行したらエラーですからねぇ。無駄なことはしないはず。

ふむふむふむ。

・・・中略・・・

SQL ID: 25a37y74xrat4 Plan Hash: 1439328272

select *
from
containers(hoge) where id in (1,3)

call count cpu elapsed disk query current rows
------- ------ -------- ---------- ---------- ---------- ---------- ----------
Parse 1 0.00 0.00 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 0 0.00 0.00 0 0 0 0
------- ------ -------- ---------- ---------- ---------- ---------- ----------
total 2 0.00 0.00 0 0 0 0

Misses in library cache during parse: 0
Optimizer mode: ALL_ROWS
Parsing user id: 103 (C##HOGE) (recursive depth: 1)
Number of plan statistics captured: 1

Rows (1st) Rows (avg) Rows (max) Row Source Operation
---------- ---------- ---------- ---------------------------------------------------
0 0 0 PX COORDINATOR (cr=0 pr=0 pw=0 time=0 us)
0 0 0 PX SEND QC (RANDOM) :TQ10000 (cr=0 pr=0 pw=0 time=0 us cost=-9223372036854775808 size=78 card=1)
0 0 0 PX PARTITION LIST ALL PARTITION: 1 254 (cr=0 pr=0 pw=0 time=189 us cost=-9223372036854775808 size=78 card=1)
0 0 0 FIXED TABLE FULL X$CDBVW$ (cr=0 pr=0 pw=0 time=12 us cost=-9223372036854775808 size=78 card=1)

p002のトレースファイル（抜粋）

・・・中略・・・

SQL ID: 25a37y74xrat4 Plan Hash: 1439328272

select *
from
containers(hoge) where id in (1,3)

call count cpu elapsed disk query current rows
------- ------ -------- ---------- ---------- ---------- ---------- ----------
Parse 1 0.00 0.00 0 0 0 0
Execute 1 0.00 0.05 0 0 0 0
Fetch 0 0.00 0.00 0 0 0 0
------- ------ -------- ---------- ---------- ---------- ---------- ----------
total 2 0.00 0.05 0 0 0 0

Misses in library cache during parse: 0
Optimizer mode: ALL_ROWS
Parsing user id: 103 (C##HOGE) (recursive depth: 1)
Number of plan statistics captured: 1

Rows (1st) Rows (avg) Rows (max) Row Source Operation
---------- ---------- ---------- ---------------------------------------------------
0 0 0 PX COORDINATOR (cr=0 pr=0 pw=0 time=0 us)
0 0 0 PX SEND QC (RANDOM) :TQ10000 (cr=0 pr=0 pw=0 time=0 us cost=-9223372036854775808 size=78 card=1)
1 1 1 PX PARTITION LIST ALL PARTITION: 1 254 (cr=961 pr=0 pw=0 time=121936 us cost=-9223372036854775808 size=78 card=1)
1 1 1 FIXED TABLE FULL X$CDBVW$ (cr=961 pr=0 pw=0 time=121610 us cost=-9223372036854775808 size=78 card=1)

・・・中略・・・

お！　Fetch=1で、rows=1 HOGE表から1行フェッチしているので２つのPDBのいずれかということになりますね！！
ORのUNION ALLへの書き換えがOR条件の順序通りであれば、以下の赤字部分の結果からみればたぶん、ID=3のでデータが存在している方のPDBであるはず。

SQL ID: 1u03tbqvywyf8 Plan Hash: 1725204971

SELECT /*+ RESULT_CACHE (SYSOBJ=TRUE SHELFLIFE=30) */ ID,DATA
FROM
"C##HOGE"."HOGE" "HOGE" WHERE "HOGE"."ID"=1 OR "HOGE"."ID"=3

call count cpu elapsed disk query current rows
------- ------ -------- ---------- ---------- ---------- ---------- ----------
Parse 1 0.00 0.00 0 1 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 1 0.00 0.00 0 3 0 1
------- ------ -------- ---------- ---------- ---------- ---------- ----------
total 3 0.00 0.00 0 4 0 1

Misses in library cache during parse: 1
Optimizer mode: CHOOSE
Parsing user id: SYS (recursive depth: 2)
Number of plan statistics captured: 1

Rows (1st) Rows (avg) Rows (max) Row Source Operation
---------- ---------- ---------- ---------------------------------------------------
1 1 1 RESULT CACHE 6158j5h7rmww7g9fxb6fwawgvy (cr=3 pr=0 pw=0 time=120 us)
1 1 1 CONCATENATION (cr=3 pr=0 pw=0 time=44 us)
0 0 0 TABLE ACCESS BY INDEX ROWID HOGE (cr=1 pr=0 pw=0 time=15 us)
0 0 0 INDEX UNIQUE SCAN SYS_C0014566 (cr=1 pr=0 pw=0 time=9 us)(object id 99927)
1 1 1 TABLE ACCESS BY INDEX ROWID HOGE (cr=2 pr=0 pw=0 time=18 us)
1 1 1 INDEX UNIQUE SCAN SYS_C0014566 (cr=1 pr=0 pw=0 time=5 us)(object id 99927)

p003もp002のトレース同様　Fetch=1で、rows=1 HOGE表から1行フェッチしているので２つのPDBのいずれかということになりますね！！
p003のSQLトレースファイル

・・・中略・・・

SQL ID: 25a37y74xrat4 Plan Hash: 1439328272

select *
from
containers(hoge) where id in (1,3)

call count cpu elapsed disk query current rows
------- ------ -------- ---------- ---------- ---------- ---------- ----------
Parse 1 0.00 0.00 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 0 0.00 0.00 0 0 0 0
------- ------ -------- ---------- ---------- ---------- ---------- ----------
total 2 0.00 0.00 0 0 0 0

Misses in library cache during parse: 0
Optimizer mode: ALL_ROWS
Parsing user id: 103 (C##HOGE) (recursive depth: 1)
Number of plan statistics captured: 1

Rows (1st) Rows (avg) Rows (max) Row Source Operation
---------- ---------- ---------- ---------------------------------------------------
0 0 0 PX COORDINATOR (cr=0 pr=0 pw=0 time=0 us)
0 0 0 PX SEND QC (RANDOM) :TQ10000 (cr=0 pr=0 pw=0 time=0 us cost=-9223372036854775808 size=78 card=1)
1 1 1 PX PARTITION LIST ALL PARTITION: 1 254 (cr=1793 pr=0 pw=0 time=119492 us cost=-9223372036854775808 size=78 card=1)
1 1 1 FIXED TABLE FULL X$CDBVW$ (cr=1793 pr=0 pw=0 time=119279 us cost=-9223372036854775808 size=78 card=1)

・・・中略・・・

plan hash = 0 でParse = 1なのでやはりパースだけ。

SQL ID: g2nujq01pmynd Plan Hash: 0

SELECT /* */ *
FROM
"C##HOGE"."HOGE"

call count cpu elapsed disk query current rows
------- ------ -------- ---------- ---------- ---------- ---------- ----------
Parse 1 0.00 0.00 0 0 0 0
Execute 0 0.00 0.00 0 0 0 0
Fetch 0 0.00 0.00 0 0 0 0
------- ------ -------- ---------- ---------- ---------- ---------- ----------
total 1 0.00 0.00 0 0 0 0

Misses in library cache during parse: 1
Optimizer mode: CHOOSE
Parsing user id: SYS (recursive depth: 2)
********************************************************************************

・・・中略・・・

やはり、rows=1 これも１行フェッチしているのでデータ登録済みの2PDBのいずれかで実行されているクエリだという点は間違いないらしい
そして、赤字部分のrowsからORの順番からして、ID=1のデータのあるPDBか。

SQL ID: 1u03tbqvywyf8 Plan Hash: 1990946707

SELECT /*+ RESULT_CACHE (SYSOBJ=TRUE SHELFLIFE=30) */ ID,DATA
FROM
"C##HOGE"."HOGE" "HOGE" WHERE "HOGE"."ID"=1 OR "HOGE"."ID"=3

call count cpu elapsed disk query current rows
------- ------ -------- ---------- ---------- ---------- ---------- ----------
Parse 1 0.00 0.00 0 1 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 1 0.00 0.00 0 3 0 1
------- ------ -------- ---------- ---------- ---------- ---------- ----------
total 3 0.00 0.00 0 4 0 1

Misses in library cache during parse: 1
Optimizer mode: CHOOSE
Parsing user id: SYS (recursive depth: 2)
Number of plan statistics captured: 1

Rows (1st) Rows (avg) Rows (max) Row Source Operation
---------- ---------- ---------- ---------------------------------------------------
1 1 1 RESULT CACHE 24q4fuaf71g7jf1upwg76y3a3q (cr=3 pr=0 pw=0 time=94 us)
1 1 1 CONCATENATION (cr=3 pr=0 pw=0 time=49 us)
1 1 1 TABLE ACCESS BY INDEX ROWID HOGE (cr=2 pr=0 pw=0 time=23 us)
1 1 1 INDEX UNIQUE SCAN SYS_C0010048 (cr=1 pr=0 pw=0 time=11 us)(object id 92602)
0 0 0 TABLE ACCESS BY INDEX ROWID HOGE (cr=1 pr=0 pw=0 time=11 us)
0 0 0 INDEX UNIQUE SCAN SYS_C0010048 (cr=1 pr=0 pw=0 time=5 us)(object id 92602)

SQLトレースで見たのが一番追いやすかったのですが（個人的に）、実践でこれをやるのは、少々辛いのでcontainers句を業務APで使っててチューニングという状況には遭遇したくないなw）

containers句の場合、実際にユーザ表にアクセスするために生成される再起SQL部分をいかにして特定するかが、
チューニング前の課題になってくるのは間違いなさそう。（今の所は）
SQLレポートやSQL監視が進化して、containsers句の場合は該当再起SQL文と実行計画も表示してくれたら楽かもしれないですけどね（それはAWRレポートも同様）

ということで、今日はここまで。

CDBとPDBの間で迷子になりそう　PART3 - SQL*PlusのAutotrace編

 CDBとPDBの間で迷子になりそう　PART3 - SQL*PlusのAutotrace編 - その２

 CDBとPDBの間で迷子になりそう　PART3 - containers clause

CDBとPDBの間で迷子になりそう　PART3 - containers clause - その２

投稿日時 2017年4月 3日 (月) 00時51分チューニング, SQL, Oracle Database 12c release 1, マルチテナント | 固定リンク | 0 | コメント (0) | トラックバック (0)

2017年3月24日 (金)

CDBとPDBの間で迷子になりそう　PART3 - containers clause - その２

Previously on Mac De Oracle.
CDBとPDBの間で迷子になりそう　PART3 - containers clause

昨日は、AWRで再帰SQL文として各PDBで実行されるSQL文を捉えた！ところまででした。

今日はそのAWRレポートを見てみようと思います。

それらしきSQL文は、AWRレポートのSQL ordered by User I/O Wait Timeなど幾つかのセクションで見つかった！！！（テキストフォーマットで出力しています）

元のSQL文で付加したコメントは再帰SQL文にはまったく引きづがれないので、多くのSQL文をcontainers句で実行していたら紐づけるの大変そうだろうという予感とともに、ヒントによるチューニングってほぼ無理なんじゃないかって思います。
（RDF Graph系の似たような句というか関数だと幾つかのヒントを渡せる仕組みもあるんですがねぇ、これは無理っぽい）

使えるとすればSPMかな。

で、recult cacheも使うようなので、そのあたりの待機イベントも多少気にかける必要もでてくるかもしれない。
と、とーくを見ながら...

どう使うか次第でしょうけど、もし、チューニングが必要な状態になったら辛くなりそうだ！、という気配だけは強く感じたところで、今日は時間切れ。

SQL ordered by User I/O Wait Time DB/Inst: ORCL12C/orcl12c Snaps: 71-72
-> Resources reported for PL/SQL code includes the resources used by all SQL
statements called by the code.
-> %Total - User I/O Time as a percentage of Total User I/O Wait time
-> %CPU - CPU Time as a percentage of Elapsed Time
-> %IO - User I/O Time as a percentage of Elapsed Time
-> Captured SQL account for 44.2% of Total User I/O Wait Time (s):
-> Captured PL/SQL account for 39.8% of Total User I/O Wait Time (s):

User I/O UIO per Elapsed
Time (s) Executions Exec (s) %Total Time (s) %CPU %IO SQL Id
---------- ------------ ---------- ------ ---------- ------ ------ -------------

・・・中略・・・

0.0 1 0.00 2.6 0.0 92.9 6.9 fj6g3jvma49dq
Module: SQL*Plus
select /* test01 */ * from containers(emp) where empno=7369

・・・中略・・・

0.0 1 0.00 1.1 0.0 88.2 11.4 0n3ta15r2qc98
Module: SQL*Plus
PDB: PDBORCL12C
SELECT /*+ RESULT_CACHE (SYSOBJ=TRUE SHELFLIFE=30) */ EMPNO,ENAME,JOB,MGR,HIREDA
TE,SAL,COMM,DEPTNO FROM "C##HOGE"."EMP" "EMP" WHERE "EMP"."EMPNO"=7369

0.0 1 0.00 1.1 0.0 88.2 11.4 0n3ta15r2qc98
Module: SQL*Plus
PDB: PDBORCL12C
SELECT /*+ RESULT_CACHE (SYSOBJ=TRUE SHELFLIFE=30) */ EMPNO,ENAME,JOB,MGR,HIREDA
TE,SAL,COMM,DEPTNO FROM "C##HOGE"."EMP" "EMP" WHERE "EMP"."EMPNO"=7369

0.0 1 0.00 1.0 0.0 89.8 12.0 0n3ta15r2qc98
Module: SQL*Plus
PDB: PDBORCL12CLONED
SELECT /*+ RESULT_CACHE (SYSOBJ=TRUE SHELFLIFE=30) */ EMPNO,ENAME,JOB,MGR,HIREDA
TE,SAL,COMM,DEPTNO FROM "C##HOGE"."EMP" "EMP" WHERE "EMP"."EMPNO"=7369

0.0 1 0.00 1.0 0.0 89.8 12.0 0n3ta15r2qc98
Module: SQL*Plus
PDB: PDBORCL12CLONED
SELECT /*+ RESULT_CACHE (SYSOBJ=TRUE SHELFLIFE=30) */ EMPNO,ENAME,JOB,MGR,HIREDA
TE,SAL,COMM,DEPTNO FROM "C##HOGE"."EMP" "EMP" WHERE "EMP"."EMPNO"=7369

参考までに、各SQLの実行計画を(AWR SQLレポートより）

Execution Plan
-----------------------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost | Pstart| Pstop | TQ |IN-OUT| PQ Distrib |
-----------------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | | | 1 | | | | | |
| 1 | PX COORDINATOR | | | | | | | | | |
| 2 | PX SEND QC (RANDOM) | :TQ10000 | 1 | 100 | | | | Q1,00 | P->S | QC (RAND) |
| 3 | PX PARTITION LIST ALL| | 1 | 100 | | 1 | 254 | Q1,00 | PCWC | |
| 4 | FIXED TABLE FULL | X$CDBVW$ | 1 | 100 | | | | Q1,00 | PCWP | |
-----------------------------------------------------------------------------------------------------------------

Note
-----
- cpu costing is off (consider enabling it)

Full SQL Text

SQL ID SQL Text
------------ -----------------------------------------------------------------
fj6g3jvma49d select /* test01 */ * from containers(emp) where empno=7369

Execution Plan
------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)|
------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | | | 1 (100)|
| 1 | RESULT CACHE | bxqp7vj85m72tbusfcmqynsj1t | | | |
| 2 | TABLE ACCESS BY INDEX ROWID| EMP | 1 | 87 | 0 (0)|
| 3 | INDEX UNIQUE SCAN | PK_EMP | 1 | | 0 (0)|
------------------------------------------------------------------------------------------------

Result Cache Information (identified by operation id):
------------------------------------------------------

1 -

Full SQL Text

SQL ID SQL Text
------------ -----------------------------------------------------------------
0n3ta15r2qc9 SELECT /*+ RESULT_CACHE (SYSOBJ=TRUE SHELFLIFE=30) */ EMPNO, ENAM
E, JOB, MGR, HIREDATE, SAL, COMM, DEPTNO FROM "C##HOGE"."EMP" "EM
P" WHERE "EMP"."EMPNO"=7369

次回でこのシリーズは最終回にするかも。。もう１つ２つ追加するかも。。。

To be continued.

CDBとPDBの間で迷子になりそう　PART3 - SQL*PlusのAutotrace編

 CDBとPDBの間で迷子になりそう　PART3 - SQL*PlusのAutotrace編 - その２

 CDBとPDBの間で迷子になりそう　PART3 - containers clause

投稿日時 2017年3月24日 (金) 00時28分チューニング, SQL, Oracle Database 12c release 1, マルチテナント | 固定リンク | 0 | コメント (0) | トラックバック (0)

2017年3月22日 (水)

CDBとPDBの間で迷子になりそう　PART3 - containers clause

Previously on Mac De Oracle.

CDBとPDBの間で迷子になりそう　PART3 - SQL*PlusのAutotrace編 - その２
auto traceでcontainers句の実行計画をながめたら、原型を留めないほど、変わり果てた実行計画をみて、ここから原型の実行計画をどうやったら見つけられるんだろうかと、途方にくれたところまででしたw

パラレル実行され、各pdbのemp表からempno=7369のデータがindex range scanで取得されているはず。
そして、再帰SQL文として、原文が各PDBで実行されているんだろうなぁ。
といところまではマニュアルの記述と、変わり果てた実行計画をみて、なんとなくイメージはできるんですが。。。

では、どうやったら各PDBで実行されているはずのSQL文や実行計画が見えるんだろう？？

auto traceでは見ることはできなかったので、次！、SQL監視で試してみます。（ダメだと思いますが、念のため）

C##HOGE@orcl12c> select /*+ monitor */ * from containers(emp) where empno=7369;

EMPNO ENAME JOB MGR HIREDATE SAL COMM DEPTNO CON_ID
---------- ---------- --------- ---------- -------- ---------- ---------- ---------- ----------
7369 SMITH CLERK 7902 80-12-17 800 20 4
7369 SMITH CLERK 7902 80-12-17 800 20 3

SQL監視をテキストモードで取得する自作スクリプトを実行して、実行計画を見ると....
んーっ。パラレルであるところは気づきやすいですが、やはり、原型を留めぬ変わり果てた実行計画しかみえませんねぇ。

C##HOGE@orcl12c> @show_realplan
1に値を入力してください:
旧 1: select dbms_sqltune.report_sql_monitor('&1') from dual
新 1: select dbms_sqltune.report_sql_monitor('') from dual

DBMS_SQLTUNE.REPORT_SQL_MONITOR('')
--------------------------------------
SQL Monitoring Report

SQL Text
------------------------------
select /*+ monitor */ * from containers(emp) where empno=7369

・・・中略・・・

Global Stats
=================================================
| Elapsed | Cpu | Other | Fetch | Buffer |
| Time(s) | Time(s) | Waits(s) | Calls | Gets |
=================================================
| 0.01 | 0.01 | 0.00 | 2 | 6 |
=================================================

Parallel Execution Details (DOP=4 , Servers Allocated=4)
==========================================================================================
| Name | Type | Server# | Elapsed | Cpu | Other | Buffer | Wait Events |
| | | | Time(s) | Time(s) | Waits(s) | Gets | (sample #) |
==========================================================================================
| PX Coordinator | QC | | 0.00 | 0.00 | 0.00 | | |
| p000 | Set 1 | 1 | 0.00 | 0.00 | | | |
| p001 | Set 1 | 2 | 0.00 | | 0.00 | | |
| p002 | Set 1 | 3 | 0.00 | | 0.00 | 3 | |
| p003 | Set 1 | 4 | 0.00 | 0.00 | | 3 | |
==========================================================================================

SQL Plan Monitoring Details (Plan Hash Value=1439328272)
===================================================================================================================================
| Id | Operation | Name | Rows | Cost | Time | Start | Execs | Rows | Activity | Activity Detail |
| | | | (Estim) | | Active(s) | Active | | (Actual) | (%) | (# samples) |
===================================================================================================================================
| 0 | SELECT STATEMENT | | | | 1 | +0 | 5 | 2 | | |
| 1 | PX COORDINATOR | | | | 1 | +0 | 5 | 2 | | |
| 2 | PX SEND QC (RANDOM) | :TQ10000 | 1 | | 1 | +0 | 4 | 2 | | |
| 3 | PX PARTITION LIST ALL | | 1 | | 1 | +0 | 4 | 2 | | |
| 4 | FIXED TABLE FULL | X$CDBVW$ | 1 | | 1 | +0 | 4 | 2 | | |
===================================================================================================================================

次は、AWRレポートでチャレンジ！

SYS@orcl12c> exec dbms_workload_repository.create_snapshot;

・・・中略・・・

C##HOGE@orcl12c> show con_name

CON_NAME
------------------------------
CDB$ROOT

C##HOGE@orcl12c> select * from containers(emp) where empno=7369;

・・・中略・・・

SYS@orcl12c> exec dbms_workload_repository.create_snapshot;

・・・中略・・・

SYS@orcl12c> @?/rdbms/admin/awrrpt

・・・中略・・・

....おかしいなぁ。捕まえられない！

AWRレポートで捕まえることができなかったのは環境上の影響(Shared Pool Sizeが小さ過ぎでエージアウトしちゃった、とか）もあったのかもしれません。しかもいろいろ動いていたので辛かったはず。
Shared Pool Sizeの下限値を大きめにして、

再チャレンジ。。。ん？　

こんどは取れたっぽい。原型とは多少違いますが、かなり近いSQL文が見つかりました！　そいつに違いない！！

というところで、今日は時間切れ、To be continued....

CDBとPDBの間で迷子になりそう　PART3 - SQL*PlusのAutotrace編

 CDBとPDBの間で迷子になりそう　PART3 - SQL*PlusのAutotrace編 - その２

投稿日時 2017年3月22日 (水) 23時03分 SQL, Oracle Database 12c release 1, マルチテナント | 固定リンク | 0 | コメント (0) | トラックバック (0)

2017年3月21日 (火)

CDBとPDBの間で迷子になりそう　PART3 - SQL*PlusのAutotrace編 - その２

間が空いてしまいましたが、

CDBとPDBの間で迷子になりそう　PART3 - SQL*PlusのAutotrace編

のつづきです。

前回は、共通ユーザを作成し、CDB$ROOT、及び残りの2つのPDBでauto traceができるようになって、さりげなく、containers句なんてのを試していたところまででした。

今日はcontainers句で遊びはじめるところからスタート！
まず初めに、containters句でなにができるのかマニュアルで確認しておきましょう。（マニュアル読めよ！お約束w

45.10 CONTAINERS句を使用したコンテナ間の問合せ
http://docs.oracle.com/cd/E82638_01/ADMIN/viewing-information-about-cdbs-and-pdbs-with-sql-plus.htm#GUID-B302A0DA-8A56-4C18-B140-ADD5E682DE60

45.10.1 CONTAINERS句を使用したコンテナ間の問合せの概要
http://docs.oracle.com/cd/E82638_01/ADMIN/viewing-information-about-cdbs-and-pdbs-with-sql-plus.htm#GUID-AD8C9596-67BB-47FA-A728-16F9C9B0AADF

45.10.3 アプリケーションPDB間のアプリケーション共通オブジェクトの問合せ
http://docs.oracle.com/cd/E82638_01/ADMIN/viewing-information-about-cdbs-and-pdbs-with-sql-plus.htm#GUID-7B4E4926-19C6-47A5-A4E3-6BD279F080F0

containers句を利用すると、
CDB$ROOTの共通ユーザから各PDBの同一共通ユーザにある同一表を問い合わせることができるようになる。
また、containers句を利用したクエリーから再帰SQLが生成され、デフォルトではパラレル化される。。と。
なお、パラレル化はされるが、パラレル文のキューイング対象でもない！　（え！　対象外なの？）

この時点で、癖者感がw

再帰的SQL実行と、さらり書かれているところ。。気になる気になる、気になりすぎて眠れないw

気になったら確かめないと！！

CDB$ROOTのsysユーザにて全PDBが起動していることを確認！

SYS@orcl12c> show pdbs

CON_ID CON_NAME OPEN MODE RESTRICTED
---------- ------------------------------ ---------- ----------
2 PDB$SEED READ ONLY NO
3 PDBORCL12C READ WRITE NO
4 PDBORCL12CLONED READ WRITE NO

CDB$ROOTの共通ユーザ:C##HOGEにEMP表（空）があるこを確認
CDB$ROOTにも同一名のオブジェクトが存在しないとエラーになるのでご注意を。（ここは別エントリで書くかも）

SYS@orcl12c> conn c##hoge/hoge@orcl12c
接続されました。
C##HOGE@orcl12c> select table_name from user_tables where table_name='EMP';

TABLE_NAME
------------------------------
EMP

C##HOGE@orcl12c> select count(*) from emp;

COUNT(*)
----------
0

以下、残る2つのPDBで、共通ユーザ:C##HOGEユーザにEMP表（データあり）が存在することを確認！

C##HOGE@orcl12c> conn c##hoge/hoge@pdborcl12c
接続されました。
C##HOGE@pdborcl12c> select table_name from user_tables where table_name='EMP';

TABLE_NAME
------------------------------
EMP

C##HOGE@pdborcl12c> select count(*) from emp;

COUNT(*)
----------
14

C##HOGE@pdborcl12c> conn c##hoge/hoge@pdborcl12cloned
接続されました。
C##HOGE@pdborcl12cloned> select table_name from user_tables where table_name='EMP';

TABLE_NAME
------------------------------
EMP

C##HOGE@pdborcl12cloned> select count(*) from emp;

COUNT(*)
----------
14

containers句を含む以下のクエリーをCDB$ROOTの共通ユーザ:C##HOGEユーザから実行！

SYS@orcl12c> conn c##hoge/hoge
接続されました。
C##HOGE@orcl12c> select * from containers(emp) where empno=7369;

EMPNO ENAME JOB MGR HIREDATE SAL COMM DEPTNO CON_ID
---------- ---------- --------- ---------- -------- ---------- ---------- ---------- ----------
7369 SMITH CLERK 7902 80-12-17 800 20 4
7369 SMITH CLERK 7902 80-12-17 800 20 3

auto traceでどんな実行計画なのか見てみます(CDB$ROOTでauto traceをやりたかったのはこういうことだったんでっす！w）

マニュアルに記載されている通り、パラレルクエリーになってます！
しかし、実行計画には、emp表という名前は見当たらず！！しかも、EMPNOには主キー制約があるのに、Predicate Information にはfilter("EMPNO"=7369)とある。

....."生成される再帰的SQL文ということばが浮かんで消える"：）不思議な実行計画が！！！！！！

でも、この実行計画、なんとなく見覚え.....ないですか？？？？

C##HOGE@orcl12c> set autot trace exp stat
C##HOGE@orcl12c> select * from containers(emp) where empno=7369;

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

----------------------------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Pstart| Pstop | TQ |IN-OUT| PQ Distrib |
----------------------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 100 | 0 (0)| | | | | |
| 1 | PX COORDINATOR | | | | | | | | | |
| 2 | PX SEND QC (RANDOM) | :TQ10000 | 1 | 100 | | | | Q1,00 | P->S | QC (RAND) |
| 3 | PX PARTITION LIST ALL| | 1 | 100 | | 1 | 254 | Q1,00 | PCWC | |
|* 4 | FIXED TABLE FULL | X$CDBVW$ | 1 | 100 | | | | Q1,00 | PCWP | |
----------------------------------------------------------------------------------------------------------------------

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

4 - filter("EMPNO"=7369)

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

見覚えがあると思ったら、まさにこれですよね。
12.1.0.2で突然登場した機能のようにも見えるが、実は、12.1.0.1のころからあった機能らしい。CDB$VIEW clauseとして。
実行計画もそっくり

12.1.0.2 CDB views are now using CONTAINERS()　/ dbi services BLOG
https://blog.dbi-services.com/12102-cdb-views-are-now-using-containers/

SQL> select * from v$version;

BANNER CON_ID
-------------------------------------------------------------------------------- ----------
Oracle Database 12c Enterprise Edition Release 12.1.0.1.0 - 64bit Production 0
PL/SQL Release 12.1.0.1.0 - Production 0
CORE 12.1.0.1.0 Production　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　0
TNS for Linux: Version 12.1.0.1.0 - Production 0
NLSRTL Version 12.1.0.1.0 - Production 0

SQL> show con_name

CON_NAME
------------------------------
CDB$ROOT
SQL>
SQL> select * from cdb$view(dual);

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

-----------------------------------------------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Pstart| Pstop | TQ |IN-OUT| PQ Distrib |
-----------------------------------------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 2 | 0 (0)| 00:00:01 | | | | | |
| 1 | PX COORDINATOR | | | | | | | | | | |
| 2 | PX SEND QC (RANDOM) | :TQ10000 | 1 | 2 | 0 (0)| 00:00:01 | | | Q1,00 | P->S | QC (RAND) |
| 3 | PX PARTITION LIST ALL| | 1 | 2 | 0 (0)| 00:00:01 | 1 | 254 | Q1,00 | PCWC | |
| 4 | FIXED TABLE FULL | X$CDBVW$42ae64ee | 1 | 2 | 0 (0)| 00:00:01 | | | Q1,00 | PCWP | |
-----------------------------------------------------------------------------------------------------------------------------------------

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

45.10.3 アプリケーションPDB間のアプリケーション共通オブジェクトの問合せ
これ、アプリケーションからお気軽に使っちゃってよい機能なんだろうか。。。どのようなユースケースを想定した機能なんだろう？。。。

to be continued...

投稿日時 2017年3月21日 (火) 00時51分 SQL, Oracle Database 12c release 1, マルチテナント | 固定リンク | 0 | コメント (0) | トラックバック (0)

2017年1月 9日 (月)

CDBとPDBの間で迷子になりそう　PART3 - SQL*PlusのAutotrace編

今回迷子になったのは、昔からあるSQL*PlusのAutotraceで.

Autotraceの使い方は、$ORACLE_HOME/sqlplus/admin/plustrce.sqlをSYSユーザーで実行し、PLUSTRACEロール作成されたら必要なユーザーへ該当ロールを付与。
あとは、SQL*Plusでautotraceを有効にする。

これだけです。

が、

マルチテナント（シングルテナント含む）化した途端に、迷子になりそうな場面に出会います！
（これにハマったことのあるかたは、#ローカルロール！　ってハッシュタグでtw...しなくてもいいですw）

マルチテナントでは、共通ユーザー、共通ロール、ローカルユーザー、ローカルロールという２つのタイプのユーザーとロールが登場しました。
CDB$ROOT/各PDBのディクショナリービュー同様、頭では理解したつもりでも指が勝手タイプして迷子になっちゃいうこともあるw　（実はOracleさんも？。。。だったりしてね。

余談はこれぐらいにして、とにかく試して見ましょう。

バージョンは以下のとおり

SYS@orcl12c> select * from v$version;

BANNER CON_ID
-------------------------------------------------------------------------------- ----------
Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production 0
PL/SQL Release 12.1.0.2.0 - Production 0
CORE 12.1.0.2.0 Production 0
TNS for Linux: Version 12.1.0.2.0 - Production 0
NLSRTL Version 12.1.0.2.0 - Production 0

マルチテナントにしてあります。（シングルテナントでも同じですが）

SYS@orcl12c> show pdbs

CON_ID CON_NAME OPEN MODE RESTRICTED
---------- ------------------------------ ---------- ----------
2 PDB$SEED READ ONLY NO
3 PDBORCL12C READ WRITE NO
4 PDBORCL12CLONED READ WRITE NO

今日の主役、共通ユーザを作成します。
共通ユーザーとするためには、c##（デフォルト）という接頭子をユーザ名に付加する必要があります。（なれるまで辛いw）

SYS@orcl12c> create user c##hoge identified by hoge
2 default tablespace users
3 temporary tablespace temp
4 quota unlimited on users
5 container=all;

ユーザーが作成されました。

CDB$ROOT含む全PDBにC##HOGEユーザが作成されました。
（実はシステム定義の管理ユーザーは共通ユーザー扱になっていることも忘れちゃいけないんですよね。おそらく同じ癖というか特徴はあるはず）

SYS@orcl12c> select con_id,username,common from containers(dba_users) where username in ('SYS','C##HOGE')

CON_ID USERNAME COM
---------- ------------------------------ ---
1 SYS YES
1 C##HOGE YES
4 SYS YES
4 C##HOGE YES
3 SYS YES
3 C##HOGE YES

※さりげなく、PDB CONTAINER句（赤字部分）を使ってますが、もともとそれで遊びたかっただけなんです。

今後のお遊び向けにいくつかのシステム権限の付与...

SYS@orcl12c> grant create session ,resource to c##hoge container=all;

権限付与が成功しました。

SYS@orcl12c> grant create table, create view to c##hoge container=all;

権限付与が成功しました。

SYS@orcl12c> grant create synonym to c##hoge container=all;

権限付与が成功しました。

共通ユーザーでもSQL*Plusのautotrace使いたいな〜と。
（最近はアダプティブな実行計画の影響で影が薄いAutotraceやExplain planですが、とりあえず見たい時や、実行統計を軽く見たいときには便利なんで）

と、思ったとことから、迷子になりまして、、はいw

CDB$ROOTの共通ユーザー接続して、autotraceを有効にしようとしました。
みなれたエラーがでるわけですよ。ロール作ってないので：）

”SP2-0618: セッション識別子が見つかりません。PLUSTRACEロールが有効かを確認してください。”

SYS@orcl12c> conn c##hoge/hoge
接続されました。
C##HOGE@orcl12c> show con_name

CON_NAME
------------------------------
CDB$ROOT

C##HOGE@orcl12c>
C##HOGE@orcl12c> set autot on
SP2-0618: セッション識別子が見つかりません。PLUSTRACEロールが有効かを確認してください。
SP2-0611: STATISTICSレポートを使用可能にするときにエラーが発生しました。

いつものように、$ORACLE_HOME/sqlplus/admin/plustrce.sqlを実行してPLUSTRACEロールを作成しようとすると。。。。。
なんと、ロールが作成できません！！！

そりゃ、そうですよね。CDB$ROOTには共通なものが載るわけですから、。。。
マルチテナント化してあるので、ロールも共通ロールを作成する必要があります。。。オラクルさん。。。。痛恨のミス？！w

PLUSTRACEというロールをCDB$ROOTに作成しようとするとローカルロールを作成している扱いになるので、共通ロールにしてねというエラーが返されます。

どうすんだよwこれw
と、初っ端から迷子ですw　（MOSは未確認。なにか記載されてそうな気はしますがw）

C##HOGE@orcl12c> conn / as sysdba
接続されました。
SYS@orcl12c> @?/sqlplus/admin/plustrce
SYS@orcl12c>

...中略...

1SYS@orcl12c> create role plustrace;
create role plustrace
*
行1でエラーが発生しました。:
ORA-65096: 共通ユーザーまたはロール名が無効です

共通ロールにしろというんだから、素直に共通ロールを作ってみます。
$ORACLE_HOME/sqlplus/admin/plustrce.sqlを元に、ロール名をPLUSTRACEからC##PLUSTRACEに変更したスクリプトを作成しました。

共通ロールについては、以下も参照のこと。
Oracle® Databaseセキュリティ・ガイド　12cリリース1 (12.1) 共通ロールの作成

以下のように、C##（共通ユーザやロールのデフォルト接頭子）を付加し共通ユーザ向けロールを作成すればできるようになりますよね！。使う機会があるかどうかは別ですがw

C##HOGE@orcl12c> !cat $ORACLE_HOME/sqlplus/admin/plustrce_common.sql

drop role c##plustrace;
create role c##plustrace;

grant select on v_$sesstat to c##plustrace;
grant select on v_$statname to c##plustrace;
grant select on v_$mystat to c##plustrace;
grant c##plustrace to dba with admin option;

C##PLUSTRACEの作成ログ
うまくいきました！！！

SYS@orcl12c> drop role c##plustrace;
drop role c##plustrace
*
行1でエラーが発生しました。:
ORA-01919: ロール'C##PLUSTRACE'は存在しません

SYS@orcl12c> create role c##plustrace;

ロールが作成されました。

SYS@orcl12c> grant select on v_$sesstat to c##plustrace;

権限付与が成功しました。

SYS@orcl12c> grant select on v_$statname to c##plustrace;

権限付与が成功しました。

SYS@orcl12c> grant select on v_$mystat to c##plustrace;

権限付与が成功しました。

SYS@orcl12c> grant c##plustrace to dba with admin option;

権限付与が成功しました。

作成したautotrace用共通ロールをcontainter=allで共通ユーザに付与したのですが。。。。
実は、container=allとしても。PDB側では今まで通り、$ORACLE_HOME/sqlplus/admin/plustrce.sqlを各PDBのSYSユーザー実行し、PLUSTRACEロール（ローカルロール）をPDBに存在する共通ユーザ個別に付与する必要があるようです。（面倒くさい＞＜）

SYS@orcl12c> grant c##plustrace to c##hoge container=all;

C##HOGE@orcl12c> conn / as sysdba
接続されました。
SYS@orcl12c>
SYS@orcl12c> conn c##hoge/hoge
接続されました。
C##HOGE@orcl12c> show con_name

CON_NAME
------------------------------
CDB$ROOT
C##HOGE@orcl12c> set autot trace exp stat
C##HOGE@orcl12c> select * from dual;

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

--------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
--------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 2 | 2 (0)| 00:00:01 |
| 1 | TABLE ACCESS FULL| DUAL | 1 | 2 | 2 (0)| 00:00:01 |
--------------------------------------------------------------------------

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

PDB側のC##HOGEユーザーには繼承されない。。。。。かるく迷子になってる状況。

C##HOGE@orcl12c> conn c##hoge/hoge@pdborcl12c
接続されました。
C##HOGE@pdborcl12c>
C##HOGE@pdborcl12c> show con_name

CON_NAME
------------------------------
PDBORCL12C
C##HOGE@pdborcl12c> set autot trace exp stat
SP2-0618: セッション識別子が見つかりません。PLUSTRACEロールが有効かを確認してください。
SP2-0611: STATISTICSレポートを使用可能にするときにエラーが発生しました。

各PDBのローカルユーザーは、以前からあるplustrce.sqlを各PDBごとに個別に作成、付与する必要があるみたい...もう完全に迷子w。
（本当はこれをネタしたかったわけじゃなかったんですけどね、トホホ）

C##HOGE@pdborcl12c> conn sys@pdborcl12c as sysdba
パスワードを入力してください:
接続されました。
SYS@pdborcl12c>
SYS@pdborcl12c>
SYS@pdborcl12c> show con_name

CON_NAME
------------------------------
PDBORCL12C
SYS@pdborcl12c>
SYS@pdborcl12c> @?/sqlplus/admin/plustrce

...中略...

SYS@pdborcl12c> conn c##hoge/hoge@pdborcl12c
接続されました。
C##HOGE@pdborcl12c> set autot trace exp stat
C##HOGE@pdborcl12c> select * from dual;

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

--------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
--------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 2 | 2 (0)| 00:00:01 |
| 1 | TABLE ACCESS FULL| DUAL | 1 | 2 | 2 (0)| 00:00:01 |
--------------------------------------------------------------------------

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

次回、本当に試したかったことへ、つづく....（予定）
久々にその機能本気で使うのかって、ネタになりそうで。。。いいかも（こんな展開は予想してなかっただけに；）

以上、はじめての、 Yahoo! Japan Coworking Space LODGE　より

関連エントリー
FAQ になりそうな、12c MTA環境での統計履歴管理　ー　CDBとPDBの間で迷子になりそう　PART2

投稿日時 2017年1月 9日 (月) 21時41分 SQL, Oracle Database 12c release 1, マルチテナント | 固定リンク | 0 | コメント (0) | トラックバック (0)

2016年12月17日 (土)

スタースキーマを扱う実行計画の特徴

JPOUG Advent Calendar 2016の17日目のエントリです。
昨日は、id:kenken08さんのMySQLのsql_modeにあるORACLEとは - kenken0807_DBメモでした。

第三の柴田さんのネタを見て、急遽内容を変更しました。:)
SQLチューニングと対戦格闘ゲームの類似性について語る。- JPOUG Advent Calendar 2016 Day 15 - - ねら～ITエンジニア雑記

DWH系のスタースキーマを扱う実行計画の特徴を簡単にまとめておきたいと思います。(個人的には、in-memory aggregationが今年のハイライトだったのでw）

※サンプルスキーマ：SHスキーマを利用しています。
Installing Sample Schemas

まず、ハッシュ結合とBloom Filterを利用した実行計画です。面倒な準備もなく、癖も少ないので力技でなんとかする系ではよく見かける実行計画です。
Right-Deep Join + Bloom Filter
Right-Deep Joinが可能なのはHash Joinのみです。　意図的に行う場合は、LEADING/USE_HASH/SWAP_JOIN_INPUTSを利用します。
Right-Deep Join Trees and Star Schema Queries
津島博士のパフォーマンス講座 - 第46回　パーティション・プルーニングとハッシュ結合について

スタースキーマでない結合や、NLJではLeft-Deep Joinとなるのが一般的なので見慣れない実行計画だと思う方もいると思いますが、巨大なファクト表よりサイズの小さいディメンジョン表が常にハッシュ結合のビルド表（外部表）になるように結合順序が入れ替えられています。

ハッシュ結合の実行計画としては理にかなっているのですが、超巨大なファクト表との結合がある場合、Exadataをもってしても倒すことができない敵に出会うこともありますw
弱点といえば弱点ですが、方式上難しいところでもあります。
パラレル度を増加させたとしても太刀打ちできないケースもね。。。。とほほ。

Execution Plan
----------------------------------------------------------
Plan hash value: 2503647845

------------------------------------------------------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Pstart| Pstop | TQ |IN-OUT| PQ Distrib |
------------------------------------------------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1546 | 137K| 3879 (1)| 00:00:01 | | | | | |
| 1 | PX COORDINATOR | | | | | | | | | | |
| 2 | PX SEND QC (ORDER) | :TQ10003 | 1546 | 137K| 3879 (1)| 00:00:01 | | | Q1,03 | P->S | QC (ORDER) |
| 3 | SORT GROUP BY | | 1546 | 137K| 3879 (1)| 00:00:01 | | | Q1,03 | PCWP | |
| 4 | PX RECEIVE | | 1546 | 137K| 3879 (1)| 00:00:01 | | | Q1,03 | PCWP | |
| 5 | PX SEND RANGE | :TQ10002 | 1546 | 137K| 3879 (1)| 00:00:01 | | | Q1,02 | P->P | RANGE |
| 6 | HASH GROUP BY | | 1546 | 137K| 3879 (1)| 00:00:01 | | | Q1,02 | PCWP | |
|* 7 | HASH JOIN | | 580K| 50M| 3875 (1)| 00:00:01 | | | Q1,02 | PCWP | |
| 8 | PX RECEIVE | | 23 | 621 | 2 (0)| 00:00:01 | | | Q1,02 | PCWP | |
| 9 | PX SEND BROADCAST | :TQ10000 | 23 | 621 | 2 (0)| 00:00:01 | | | Q1,00 | P->P | BROADCAST |
| 10 | PX BLOCK ITERATOR | | 23 | 621 | 2 (0)| 00:00:01 | | | Q1,00 | PCWC | |
| 11 | TABLE ACCESS INMEMORY FULL | COUNTRIES | 23 | 621 | 2 (0)| 00:00:01 | | | Q1,00 | PCWP | |
|* 12 | HASH JOIN | | 580K| 35M| 3872 (1)| 00:00:01 | | | Q1,02 | PCWP | |
| 13 | PX RECEIVE | | 55500 | 541K| 8 (13)| 00:00:01 | | | Q1,02 | PCWP | |
| 14 | PX SEND BROADCAST | :TQ10001 | 55500 | 541K| 8 (13)| 00:00:01 | | | Q1,01 | P->P | BROADCAST |
| 15 | PX BLOCK ITERATOR | | 55500 | 541K| 8 (13)| 00:00:01 | | | Q1,01 | PCWC | |
| 16 | TABLE ACCESS INMEMORY FULL| CUSTOMERS | 55500 | 541K| 8 (13)| 00:00:01 | | | Q1,01 | PCWP | |
|* 17 | HASH JOIN | | 580K| 29M| 3864 (1)| 00:00:01 | | | Q1,02 | PCWP | |
|* 18 | TABLE ACCESS INMEMORY FULL | CHANNELS | 2 | 42 | 2 (0)| 00:00:01 | | | Q1,02 | PCWP | |
|* 19 | HASH JOIN | | 1161K| 36M| 3862 (1)| 00:00:01 | | | Q1,02 | PCWP | |
| 20 | PART JOIN FILTER CREATE | :BF0000 | 1845 | 22140 | 2 (0)| 00:00:01 | | | Q1,02 | PCWP | |
|* 21 | TABLE ACCESS INMEMORY FULL| TIMES | 1845 | 22140 | 2 (0)| 00:00:01 | | | Q1,02 | PCWP | |
| 22 | PX BLOCK ITERATOR | | 3673K| 73M| 3857 (1)| 00:00:01 |:BF0000|:BF0000| Q1,02 | PCWC | |
| 23 | TABLE ACCESS FULL | SALES | 3673K| 73M| 3857 (1)| 00:00:01 |:BF0000|:BF0000| Q1,02 | PCWP | |
------------------------------------------------------------------------------------------------------------------------------------------------

Note
-----
- dynamic statistics used: dynamic sampling (level=2)
- Degree of Parallelism is 4 because of session
- 1 Sql Plan Directive used for this statement

Star Transformation
巨大なファクト表とディメンジョン表の結合が辛いなら、昔からあるスター変換だ！　
とも思うのですが、スター変換は頑固ものかつ、曲者なのが難点。

頑固さ
ディメンジョン表やファクト表にビットマップ索引や参照整合性制約作成等、利用できるようにするお膳立てができてないと、ピクリとも動きませんw
巨大なファクト表の外部キー列にビットマップ索引を１つ作成するのに、数時間w　複数作成して、さらに、ディメンジョン表との参照整合性制約まで必要なのでまともにやっていると、１日では終わらないことも＞＜
(俺を信じろ、　RELYが利用できるデータの状態であれば楽ではありますが）

スター変換の最大の弱点は、ビットマップ索引を利用したROWIDアクセス(以下の実行計画ではId=42の部分）による読み込み件数が多すぎるケースです。性能が伸びなかったり、または、悪化することもあります。
スター変換を利用するかどうかは、ディメンジョン表との結合でファクト表が十分に絞り込めるかにかかっています。

ディメンジョン表との結合キーがビットマップ索引中にあるため、ディメンジョン表とファクト表を結合することなく、ROWIDでファクト表をアクセスして集計することができます。
ファクト表のアクセス量が少ない場合はROWIDアクセスがメリットとなるわけですが、その逆のケースでは、ファクト表はROWIDで1行ごとにアクセスされることになるため、アクセスするファクト表の行数が多くなればなるほど不利になります。

ROWIDによるシングルブロックリードが数十億回繰り返されるとしたら、待機イベントのほとんどが、db file sequential readやcell single block physical read（Exadata)になってしまうことになります。

使いどころを見誤らないようにしたいものです。

Execution Plan
----------------------------------------------------------
Plan hash value: 2513598833

-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time | Pstart| Pstop | TQ |IN-OUT| PQ Distrib |
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 6490 | 627K| | 5584 (1)| 00:00:01 | | | | | |
| 1 | TEMP TABLE TRANSFORMATION | | | | | | | | | | | |
| 2 | PX COORDINATOR | | | | | | | | | | | |
| 3 | PX SEND QC (RANDOM) | :TQ10000 | 1845 | 22140 | | 2 (0)| 00:00:01 | | | Q1,00 | P->S | QC (RAND) |
| 4 | LOAD AS SELECT (TEMP SEGMENT MERGE) | SYS_TEMP_0FD9D662C_336236 | | | | | | | | Q1,00 | PCWP | |
| 5 | PX BLOCK ITERATOR | | 1845 | 22140 | | 2 (0)| 00:00:01 | | | Q1,00 | PCWC | |
|* 6 | TABLE ACCESS INMEMORY FULL | TIMES | 1845 | 22140 | | 2 (0)| 00:00:01 | | | Q1,00 | PCWP | |
| 7 | PX COORDINATOR | | | | | | | | | | | |
| 8 | PX SEND QC (ORDER) | :TQ20003 | 6490 | 627K| | 5582 (1)| 00:00:01 | | | Q2,03 | P->S | QC (ORDER) |
| 9 | SORT GROUP BY | | 6490 | 627K| 60M| 5582 (1)| 00:00:01 | | | Q2,03 | PCWP | |
| 10 | PX RECEIVE | | 6490 | 627K| | 5582 (1)| 00:00:01 | | | Q2,03 | PCWP | |
| 11 | PX SEND RANGE | :TQ20002 | 6490 | 627K| | 5582 (1)| 00:00:01 | | | Q2,02 | P->P | RANGE |
| 12 | HASH GROUP BY | | 6490 | 627K| 60M| 5582 (1)| 00:00:01 | | | Q2,02 | PCWP | |
|* 13 | HASH JOIN | | 580K| 54M| | 4334 (1)| 00:00:01 | | | Q2,02 | PCWP | |
| 14 | PX RECEIVE | | 1845 | 22140 | | 2 (0)| 00:00:01 | | | Q2,02 | PCWP | |
| 15 | PX SEND BROADCAST | :TQ20000 | 1845 | 22140 | | 2 (0)| 00:00:01 | | | Q2,00 | P->P | BROADCAST |
| 16 | PX BLOCK ITERATOR | | 1845 | 22140 | | 2 (0)| 00:00:01 | | | Q2,00 | PCWC | |
| 17 | TABLE ACCESS FULL | SYS_TEMP_0FD9D662C_336236 | 1845 | 22140 | | 2 (0)| 00:00:01 | | | Q2,00 | PCWP | |
|* 18 | HASH JOIN | | 580K| 48M| | 4332 (1)| 00:00:01 | | | Q2,02 | PCWP | |
|* 19 | TABLE ACCESS INMEMORY FULL | CHANNELS | 2 | 42 | | 2 (0)| 00:00:01 | | | Q2,02 | PCWP | |
|* 20 | HASH JOIN | | 580K| 36M| | 4329 (1)| 00:00:01 | | | Q2,02 | PCWP | |
| 21 | PX RECEIVE | | 55500 | 2005K| | 10 (10)| 00:00:01 | | | Q2,02 | PCWP | |
| 22 | PX SEND BROADCAST | :TQ20001 | 55500 | 2005K| | 10 (10)| 00:00:01 | | | Q2,01 | P->P | BROADCAST |
|* 23 | HASH JOIN | | 55500 | 2005K| | 10 (10)| 00:00:01 | | | Q2,01 | PCWP | |
| 24 | TABLE ACCESS INMEMORY FULL | COUNTRIES | 23 | 621 | | 2 (0)| 00:00:01 | | | Q2,01 | PCWP | |
| 25 | PX BLOCK ITERATOR | | 55500 | 541K| | 8 (13)| 00:00:01 | | | Q2,01 | PCWC | |
| 26 | TABLE ACCESS INMEMORY FULL | CUSTOMERS | 55500 | 541K| | 8 (13)| 00:00:01 | | | Q2,01 | PCWP | |
| 27 | VIEW | VW_ST_A44449E3 | 580K| 16M| | 4319 (1)| 00:00:01 | | | Q2,02 | PCWP | |
| 28 | NESTED LOOPS | | 580K| 28M| | 4315 (1)| 00:00:01 | | | Q2,02 | PCWP | |
| 29 | PX PARTITION RANGE SUBQUERY | | 580K| 12M| | 15 (14)| 00:00:01 |KEY(SQ)|KEY(SQ)| Q2,02 | PCWC | |
| 30 | BITMAP CONVERSION TO ROWIDS | | 580K| 12M| | 15 (14)| 00:00:01 | | | Q2,02 | PCWP | |
| 31 | BITMAP AND | | | | | | | | | Q2,02 | PCWP | |
| 32 | BITMAP MERGE | | | | | | | | | Q2,02 | PCWP | |
| 33 | BITMAP KEY ITERATION | | | | | | | | | Q2,02 | PCWP | |
| 34 | BUFFER SORT | | | | | | | | | Q2,02 | PCWP | |
|* 35 | TABLE ACCESS INMEMORY FULL| CHANNELS | 2 | 26 | | 2 (0)| 00:00:01 | | | Q2,02 | PCWP | |
|* 36 | BITMAP INDEX RANGE SCAN | SALES_CHANNEL_BIX | | | | | |KEY(SQ)|KEY(SQ)| Q2,02 | PCWP | |
| 37 | BITMAP MERGE | | | | | | | | | Q2,02 | PCWP | |
| 38 | BITMAP KEY ITERATION | | | | | | | | | Q2,02 | PCWP | |
| 39 | BUFFER SORT | | | | | | | | | Q2,02 | PCWP | |
| 40 | TABLE ACCESS FULL | SYS_TEMP_0FD9D662C_336236 | 1845 | 14760 | | 2 (0)| 00:00:01 | | | Q2,02 | PCWP | |
|* 41 | BITMAP INDEX RANGE SCAN | SALES_TIME_BIX | | | | | |KEY(SQ)|KEY(SQ)| Q2,02 | PCWP | |
| 42 | TABLE ACCESS BY USER ROWID | SALES | 1 | 29 | | 4304 (1)| 00:00:01 | ROWID | ROWID | Q2,02 | PCWP | |
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Note
-----
- dynamic statistics used: dynamic sampling (level=2)
- Degree of Parallelism is 4 because of session
- star transformation used for this statement
- 1 Sql Plan Directive used for this statement

長い前置きでしたが、やっと真打の登場です！
in-memory aggregationとして解説されていることが多いのですが、実行計画を眺めている人間からすると機能名よりvector transformationの方がイメージしやすいので、以下、Vector Tranformation/ベクター変換とします。

Vector Transformation
スター変換同様に、巨大なファクト表とディメンジョン表を直接結合しない点や、パラレル実行時も他の実行計画ではみられない（誤解をおそれずにいうと、全力投球に近いかもw）特徴があります。
索引や参照整合性制約などの作成は不要。
in-memory database関連の機能ではあるのですが、全ての表がinmemory化されていなくても発動させることができます。(inmemory_sizeパラメータの設定は必要となる模様。後述）
最強の力を発揮するのは、全てがinmemoryで動作した場合であることは間違いないわけですが、巨大過ぎるファクト表がinmemory化できるほどメモリが潤沢にあるかというと、そうじゃなかっりしますし。

ベクター変換の動きを簡単に説明すると以下のような感じです。
ディメンジョン表を元に集計結果相当の構造体(in-memory accumulatorと呼ばれる多次元構造体)をメモリ上に構築後、ファクト表を読みながらin-memory accumulator上で集計します！！！（画期的！）
ハッシュ結合が全くなくなるわけではないですが、集計終了後に読み替え目的で少量（この部分が少量じゃないと辛くなるはずなのでよーく確認しておくことをおすすめします）はのハッシュ結合が行われるだけなので、冒頭で紹介した巨大なファクト表とディメンジョン表の結合によるCPUネック部分を華麗に回避していることがわかります。
Right-Deep Join+Bloom Filterで苦しい状況になったら、in-memory aggregationのことを思い出してあげてください。

助けてくれるかもしれません。

Oracle Database In-Memory: In-Memory Aggregation - Oracle White Paper JANUARY 2015

Execution Plan
----------------------------------------------------------
Plan hash value: 3211261687

------------------------------------------------------------------------------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time | Pstart| Pstop | TQ |IN-OUT| PQ Distrib |
------------------------------------------------------------------------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 483 | 60858 | | 3840 (1)| 00:00:01 | | | | | |
| 1 | TEMP TABLE TRANSFORMATION | | | | | | | | | | | |
| 2 | LOAD AS SELECT | SYS_TEMP_0FD9D6630_336236 | | | | | | | | | | |
| 3 | PX COORDINATOR | | | | | | | | | | | |
| 4 | PX SEND QC (RANDOM) | :TQ10001 | 21 | 336 | | 3 (34)| 00:00:01 | | | Q1,01 | P->S | QC (RAND) |
| 5 | BUFFER SORT | | 21 | 336 | | 3 (34)| 00:00:01 | | | Q1,01 | PCWP | |
| 6 | VECTOR GROUP BY | | 21 | 336 | | 3 (34)| 00:00:01 | | | Q1,01 | PCWP | |
| 7 | KEY VECTOR CREATE BUFFERED | :KV0000 | 1845 | 29520 | | 3 (34)| 00:00:01 | | | Q1,01 | PCWP | |
| 8 | PX RECEIVE | | 1845 | 22140 | | 2 (0)| 00:00:01 | | | Q1,01 | PCWP | |
| 9 | PX SEND HASH | :TQ10000 | 1845 | 22140 | | 2 (0)| 00:00:01 | | | Q1,00 | P->P | HASH |
| 10 | PX BLOCK ITERATOR | | 1845 | 22140 | | 2 (0)| 00:00:01 | | | Q1,00 | PCWC | |
|* 11 | TABLE ACCESS INMEMORY FULL | TIMES | 1845 | 22140 | | 2 (0)| 00:00:01 | | | Q1,00 | PCWP | |
| 12 | LOAD AS SELECT | SYS_TEMP_0FD9D6631_336236 | | | | | | | | | | |
| 13 | PX COORDINATOR | | | | | | | | | | | |
| 14 | PX SEND QC (RANDOM) | :TQ20001 | 23 | 851 | | 12 (25)| 00:00:01 | | | Q2,01 | P->S | QC (RAND) |
| 15 | HASH GROUP BY | | 23 | 851 | 2624K| 12 (25)| 00:00:01 | | | Q2,01 | PCWP | |
| 16 | KEY VECTOR CREATE BUFFERED | :KV0001 | | | | | | | | Q2,01 | PCWP | |
| 17 | PX RECEIVE | | 55500 | 2005K| | 10 (10)| 00:00:01 | | | Q2,01 | PCWP | |
| 18 | PX SEND HASH | :TQ20000 | 55500 | 2005K| | 10 (10)| 00:00:01 | | | Q2,00 | P->P | HASH |
|* 19 | HASH JOIN | | 55500 | 2005K| | 10 (10)| 00:00:01 | | | Q2,00 | PCWP | |
| 20 | TABLE ACCESS INMEMORY FULL | COUNTRIES | 23 | 621 | | 2 (0)| 00:00:01 | | | Q2,00 | PCWP | |
| 21 | PX BLOCK ITERATOR | | 55500 | 541K| | 8 (13)| 00:00:01 | | | Q2,00 | PCWC | |
| 22 | TABLE ACCESS INMEMORY FULL | CUSTOMERS | 55500 | 541K| | 8 (13)| 00:00:01 | | | Q2,00 | PCWP | |
| 23 | LOAD AS SELECT | SYS_TEMP_0FD9D6632_336236 | | | | | | | | | | |
| 24 | PX COORDINATOR | | | | | | | | | | | |
| 25 | PX SEND QC (RANDOM) | :TQ30001 | 2 | 50 | | 3 (34)| 00:00:01 | | | Q3,01 | P->S | QC (RAND) |
| 26 | BUFFER SORT | | 2 | 50 | | 3 (34)| 00:00:01 | | | Q3,01 | PCWP | |
| 27 | VECTOR GROUP BY | | 2 | 50 | | 3 (34)| 00:00:01 | | | Q3,01 | PCWP | |
| 28 | KEY VECTOR CREATE BUFFERED | :KV0002 | 2 | 50 | | 3 (34)| 00:00:01 | | | Q3,01 | PCWP | |
| 29 | PX RECEIVE | | 2 | 42 | | 2 (0)| 00:00:01 | | | Q3,01 | PCWP | |
| 30 | PX SEND HASH | :TQ30000 | 2 | 42 | | 2 (0)| 00:00:01 | | | Q3,00 | P->P | HASH |
| 31 | PX BLOCK ITERATOR | | 2 | 42 | | 2 (0)| 00:00:01 | | | Q3,00 | PCWC | |
|* 32 | TABLE ACCESS INMEMORY FULL | CHANNELS | 2 | 42 | | 2 (0)| 00:00:01 | | | Q3,00 | PCWP | |
| 33 | PX COORDINATOR | | | | | | | | | | | |
| 34 | PX SEND QC (ORDER) | :TQ40003 | 483 | 60858 | | 3821 (1)| 00:00:01 | | | Q4,03 | P->S | QC (ORDER) |
| 35 | SORT GROUP BY | | 483 | 60858 | | 3821 (1)| 00:00:01 | | | Q4,03 | PCWP | |
| 36 | PX RECEIVE | | 483 | 60858 | | 3821 (1)| 00:00:01 | | | Q4,03 | PCWP | |
| 37 | PX SEND RANGE | :TQ40002 | 483 | 60858 | | 3821 (1)| 00:00:01 | | | Q4,02 | P->P | RANGE |
| 38 | HASH GROUP BY | | 483 | 60858 | | 3821 (1)| 00:00:01 | | | Q4,02 | PCWP | |
|* 39 | HASH JOIN | | 483 | 60858 | | 3820 (1)| 00:00:01 | | | Q4,02 | PCWP | |
| 40 | PX RECEIVE | | 23 | 851 | | 2 (0)| 00:00:01 | | | Q4,02 | PCWP | |
| 41 | PX SEND BROADCAST | :TQ40000 | 23 | 851 | | 2 (0)| 00:00:01 | | | Q4,00 | P->P | BROADCAST |
| 42 | PX BLOCK ITERATOR | | 23 | 851 | | 2 (0)| 00:00:01 | | | Q4,00 | PCWC | |
| 43 | TABLE ACCESS FULL | SYS_TEMP_0FD9D6631_336236 | 23 | 851 | | 2 (0)| 00:00:01 | | | Q4,00 | PCWP | |
|* 44 | HASH JOIN | | 483 | 42987 | | 3818 (1)| 00:00:01 | | | Q4,02 | PCWP | |
| 45 | TABLE ACCESS FULL | SYS_TEMP_0FD9D6630_336236 | 21 | 252 | | 2 (0)| 00:00:01 | | | Q4,02 | PCWP | |
|* 46 | HASH JOIN | | 483 | 37191 | | 3816 (1)| 00:00:01 | | | Q4,02 | PCWP | |
| 47 | TABLE ACCESS FULL | SYS_TEMP_0FD9D6632_336236 | 2 | 42 | | 2 (0)| 00:00:01 | | | Q4,02 | PCWP | |
| 48 | VIEW | VW_VT_AF0F4755 | 483 | 27048 | | 3814 (1)| 00:00:01 | | | Q4,02 | PCWP | |
| 49 | HASH GROUP BY | | 483 | 15939 | | 3814 (1)| 00:00:01 | | | Q4,02 | PCWP | |
| 50 | PX RECEIVE | | 483 | 15939 | | 3814 (1)| 00:00:01 | | | Q4,02 | PCWP | |
| 51 | PX SEND HASH | :TQ40001 | 483 | 15939 | | 3814 (1)| 00:00:01 | | | Q4,01 | P->P | HASH |
| 52 | VECTOR GROUP BY | | 483 | 15939 | | 3814 (1)| 00:00:01 | | | Q4,01 | PCWP | |
| 53 | HASH GROUP BY | | 483 | 15939 | | 3814 (1)| 00:00:01 | | | Q4,01 | PCWP | |
| 54 | KEY VECTOR USE | :KV0001 | 580K| 18M| | 3811 (1)| 00:00:01 | | | Q4,01 | PCWC | |
| 55 | KEY VECTOR USE | :KV0002 | 580K| 16M| | 3811 (1)| 00:00:01 | | | Q4,01 | PCWC | |
| 56 | KEY VECTOR USE | :KV0000 | 1161K| 27M| | 3811 (1)| 00:00:01 | | | Q4,01 | PCWC | |
| 57 | PX BLOCK ITERATOR | | 3673K| 73M| | 3811 (1)| 00:00:01 |KEY(SQ)|KEY(SQ)| Q4,01 | PCWC | |
|* 58 | TABLE ACCESS FULL| SALES | 3673K| 73M| | 3811 (1)| 00:00:01 |KEY(SQ)|KEY(SQ)| Q4,01 | PCWP | |
------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Note
-----
- dynamic statistics used: dynamic sampling (level=2)
- Degree of Parallelism is 4 because of session
- 2 Sql Plan Directives used for this statement
- vector transformation used for this statement

超絶必殺技にも思えるベクター変換ですが、癖がないわけではありません。（大技につきものの反動というか、なんというかw）

癖　その１）
パラレルクエリー時に割り当てられるサーバープロセスが多く、割り当てられるサーバー数は、KEY VECTORの作成数により大きく変化します。
以下、SQL MONITORのParallel Execution Detailsセクション(抜粋）の比較

並列度は同じでも割り当てるサーバー数はこんなに違う！
VECTOR TRANSFORMATION
KEY VECTORが3つ作成されるベクター変換の場合
（SQL　MONITORのParallel Execution Detailsセクションより抜粋）
Parallel Execution Details (DOP=4 , Servers Allocated=32)

KEY VECTORが2つ作成されるベクター変換の場合
Parallel Execution Details (DOP=4 , Servers Allocated=24)

STAR TRANSFORMATION
Parallel Execution Details (DOP=4 , Servers Allocated=12)

Hash Joinのみ
Parallel Execution Details (DOP=4 , Servers Allocated=8)

癖　その２）
スター変換を発動させるための索引作成や、制約作成の煩雑さは無く、全ての表がinmemoryになっていなくても発動させることはできるのですが、発動させるためは、最低限設定しなればならない（ほんと？　不具合？）パラメータが存在します。（

inmemory化する表は無くとも、inmemory_size=100m（設定可能な最小サイズ）に設定しないとVECTOR_TRANSFORMヒントが無視されるという点です。
この制限？を記載しているマニュアルなどは探し出せていないのですが、どこかに記載されているのでしょうか？（いまのところ見つけることができず。。。教えていただけるとうれしいです）

では、最後に、inmemory_size初期化パラメータの設定有無による変化をみてみましょう。

inmemory_size初期化パラメータが設定されている場合にはVECTOR_TRANSFORMヒントでベクター変換を強制できています。

10:36:23 orcl12c@SYSTEM> show parameter inmemory

NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
inmemory_clause_default string
inmemory_force string DEFAULT
inmemory_max_populate_servers integer 3
inmemory_query string ENABLE
inmemory_size big integer 512M
inmemory_trickle_repopulate_servers_ integer 1
percent
optimizer_inmemory_aware boolean TRUE

10:37:04 ORCL@SH> set autot trace exp stat
10:56:18 ORCL@SH> @sample3_2

135 rows selected.

Execution Plan
----------------------------------------------------------
Plan hash value: 3211261687

------------------------------------------------------------------------------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time | Pstart| Pstop | TQ |IN-OUT| PQ Distrib |
------------------------------------------------------------------------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 483 | 60858 | | 3967 (1)| 00:00:01 | | | | | |
| 1 | TEMP TABLE TRANSFORMATION | | | | | | | | | | | |
| 2 | LOAD AS SELECT | SYS_TEMP_0FD9D6609_33B383 | | | | | | | | | | |
| 3 | PX COORDINATOR | | | | | | | | | | | |
| 4 | PX SEND QC (RANDOM) | :TQ10001 | 21 | 336 | | 20 (5)| 00:00:01 | | | Q1,01 | P->S | QC (RAND) |
| 5 | BUFFER SORT | | 21 | 336 | | 20 (5)| 00:00:01 | | | Q1,01 | PCWP | |
| 6 | VECTOR GROUP BY | | 21 | 336 | | 20 (5)| 00:00:01 | | | Q1,01 | PCWP | |
| 7 | KEY VECTOR CREATE BUFFERED | :KV0000 | 1845 | 29520 | | 20 (5)| 00:00:01 | | | Q1,01 | PCWP | |
| 8 | PX RECEIVE | | 1845 | 22140 | | 19 (0)| 00:00:01 | | | Q1,01 | PCWP | |
| 9 | PX SEND HASH | :TQ10000 | 1845 | 22140 | | 19 (0)| 00:00:01 | | | Q1,00 | P->P | HASH |
| 10 | PX BLOCK ITERATOR | | 1845 | 22140 | | 19 (0)| 00:00:01 | | | Q1,00 | PCWC | |
|* 11 | TABLE ACCESS FULL | TIMES | 1845 | 22140 | | 19 (0)| 00:00:01 | | | Q1,00 | PCWP | |
| 12 | LOAD AS SELECT | SYS_TEMP_0FD9D660A_33B383 | | | | | | | | | | |
| 13 | PX COORDINATOR | | | | | | | | | | | |
| 14 | PX SEND QC (RANDOM) | :TQ20001 | 23 | 851 | | 122 (3)| 00:00:01 | | | Q2,01 | P->S | QC (RAND) |
| 15 | HASH GROUP BY | | 23 | 851 | 2624K| 122 (3)| 00:00:01 | | | Q2,01 | PCWP | |
| 16 | KEY VECTOR CREATE BUFFERED | :KV0001 | | | | | | | | Q2,01 | PCWP | |
| 17 | PX RECEIVE | | 55500 | 2005K| | 119 (0)| 00:00:01 | | | Q2,01 | PCWP | |
| 18 | PX SEND HASH | :TQ20000 | 55500 | 2005K| | 119 (0)| 00:00:01 | | | Q2,00 | P->P | HASH |
|* 19 | HASH JOIN | | 55500 | 2005K| | 119 (0)| 00:00:01 | | | Q2,00 | PCWP | |
| 20 | TABLE ACCESS FULL | COUNTRIES | 23 | 621 | | 2 (0)| 00:00:01 | | | Q2,00 | PCWP | |
| 21 | PX BLOCK ITERATOR | | 55500 | 541K| | 117 (0)| 00:00:01 | | | Q2,00 | PCWC | |
| 22 | TABLE ACCESS FULL | CUSTOMERS | 55500 | 541K| | 117 (0)| 00:00:01 | | | Q2,00 | PCWP | |
| 23 | LOAD AS SELECT | SYS_TEMP_0FD9D660B_33B383 | | | | | | | | | | |
| 24 | PX COORDINATOR | | | | | | | | | | | |
| 25 | PX SEND QC (RANDOM) | :TQ30001 | 2 | 50 | | 3 (34)| 00:00:01 | | | Q3,01 | P->S | QC (RAND) |
| 26 | BUFFER SORT | | 2 | 50 | | 3 (34)| 00:00:01 | | | Q3,01 | PCWP | |
| 27 | VECTOR GROUP BY | | 2 | 50 | | 3 (34)| 00:00:01 | | | Q3,01 | PCWP | |
| 28 | KEY VECTOR CREATE BUFFERED | :KV0002 | 2 | 50 | | 3 (34)| 00:00:01 | | | Q3,01 | PCWP | |
| 29 | PX RECEIVE | | 2 | 42 | | 2 (0)| 00:00:01 | | | Q3,01 | PCWP | |
| 30 | PX SEND HASH | :TQ30000 | 2 | 42 | | 2 (0)| 00:00:01 | | | Q3,00 | P->P | HASH |
| 31 | PX BLOCK ITERATOR | | 2 | 42 | | 2 (0)| 00:00:01 | | | Q3,00 | PCWC | |
|* 32 | TABLE ACCESS FULL | CHANNELS | 2 | 42 | | 2 (0)| 00:00:01 | | | Q3,00 | PCWP | |
| 33 | PX COORDINATOR | | | | | | | | | | | |
| 34 | PX SEND QC (ORDER) | :TQ40003 | 483 | 60858 | | 3821 (1)| 00:00:01 | | | Q4,03 | P->S | QC (ORDER) |
| 35 | SORT GROUP BY | | 483 | 60858 | | 3821 (1)| 00:00:01 | | | Q4,03 | PCWP | |
| 36 | PX RECEIVE | | 483 | 60858 | | 3821 (1)| 00:00:01 | | | Q4,03 | PCWP | |
| 37 | PX SEND RANGE | :TQ40002 | 483 | 60858 | | 3821 (1)| 00:00:01 | | | Q4,02 | P->P | RANGE |
| 38 | HASH GROUP BY | | 483 | 60858 | | 3821 (1)| 00:00:01 | | | Q4,02 | PCWP | |
|* 39 | HASH JOIN | | 483 | 60858 | | 3820 (1)| 00:00:01 | | | Q4,02 | PCWP | |
| 40 | PX RECEIVE | | 23 | 851 | | 2 (0)| 00:00:01 | | | Q4,02 | PCWP | |
| 41 | PX SEND BROADCAST | :TQ40000 | 23 | 851 | | 2 (0)| 00:00:01 | | | Q4,00 | P->P | BROADCAST |
| 42 | PX BLOCK ITERATOR | | 23 | 851 | | 2 (0)| 00:00:01 | | | Q4,00 | PCWC | |
| 43 | TABLE ACCESS FULL | SYS_TEMP_0FD9D660A_33B383 | 23 | 851 | | 2 (0)| 00:00:01 | | | Q4,00 | PCWP | |
|* 44 | HASH JOIN | | 483 | 42987 | | 3818 (1)| 00:00:01 | | | Q4,02 | PCWP | |
| 45 | TABLE ACCESS FULL | SYS_TEMP_0FD9D6609_33B383 | 21 | 252 | | 2 (0)| 00:00:01 | | | Q4,02 | PCWP | |
|* 46 | HASH JOIN | | 483 | 37191 | | 3816 (1)| 00:00:01 | | | Q4,02 | PCWP | |
| 47 | TABLE ACCESS FULL | SYS_TEMP_0FD9D660B_33B383 | 2 | 42 | | 2 (0)| 00:00:01 | | | Q4,02 | PCWP | |
| 48 | VIEW | VW_VT_AF0F4755 | 483 | 27048 | | 3814 (1)| 00:00:01 | | | Q4,02 | PCWP | |
| 49 | HASH GROUP BY | | 483 | 15939 | | 3814 (1)| 00:00:01 | | | Q4,02 | PCWP | |
| 50 | PX RECEIVE | | 483 | 15939 | | 3814 (1)| 00:00:01 | | | Q4,02 | PCWP | |
| 51 | PX SEND HASH | :TQ40001 | 483 | 15939 | | 3814 (1)| 00:00:01 | | | Q4,01 | P->P | HASH |
| 52 | VECTOR GROUP BY | | 483 | 15939 | | 3814 (1)| 00:00:01 | | | Q4,01 | PCWP | |
| 53 | HASH GROUP BY | | 483 | 15939 | | 3814 (1)| 00:00:01 | | | Q4,01 | PCWP | |
| 54 | KEY VECTOR USE | :KV0001 | 580K| 18M| | 3811 (1)| 00:00:01 | | | Q4,01 | PCWC | |
| 55 | KEY VECTOR USE | :KV0002 | 580K| 16M| | 3811 (1)| 00:00:01 | | | Q4,01 | PCWC | |
| 56 | KEY VECTOR USE | :KV0000 | 1161K| 27M| | 3811 (1)| 00:00:01 | | | Q4,01 | PCWC | |
| 57 | PX BLOCK ITERATOR | | 3673K| 73M| | 3811 (1)| 00:00:01 |KEY(SQ)|KEY(SQ)| Q4,01 | PCWC | |
|* 58 | TABLE ACCESS FULL| SALES | 3673K| 73M| | 3811 (1)| 00:00:01 |KEY(SQ)|KEY(SQ)| Q4,01 | PCWP | |
------------------------------------------------------------------------------------------------------------------------------------------------------------------------

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

11 - filter("T"."FISCAL_YEAR"=2000 OR "T"."FISCAL_YEAR"=2005 OR "T"."FISCAL_YEAR"=2010 OR "T"."FISCAL_YEAR"=2015 OR "T"."FISCAL_YEAR"=2016)
19 - access("C"."COUNTRY_ID"="R"."COUNTRY_ID")
32 - filter("CH"."CHANNEL_DESC"='Internet' OR "CH"."CHANNEL_DESC"='Partners')
39 - access("ITEM_13"=INTERNAL_FUNCTION("C0") AND "ITEM_14"="C4")
44 - access("ITEM_17"=INTERNAL_FUNCTION("C0") AND "ITEM_18"="C2")
46 - access("ITEM_15"=INTERNAL_FUNCTION("C0") AND "ITEM_16"="C2")
58 - filter(SYS_OP_KEY_VECTOR_FILTER("S"."TIME_ID",:KV0000) AND SYS_OP_KEY_VECTOR_FILTER("S"."CHANNEL_ID",:KV0002))

Note
-----
- dynamic statistics used: dynamic sampling (level=2)
- Degree of Parallelism is 4 because of session
- 2 Sql Plan Directives used for this statement
- vector transformation used for this statement

inmemory_size初期化パラメータを0にし、同一SQL文を実行すると。。。。なんということでしょう。ベクター変換は発動しません！

10:46:22 orcl12c@SYSTEM> show parameter inmemory

NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
inmemory_clause_default string
inmemory_force string DEFAULT
inmemory_max_populate_servers integer 0
inmemory_query string ENABLE
inmemory_size big integer 0
inmemory_trickle_repopulate_servers_ integer 1
percent
optimizer_inmemory_aware boolean TRUE

10:47:56 ORCL@SH> @sample3_2

135 rows selected.

Execution Plan
----------------------------------------------------------
Plan hash value: 2503647845

--------------------------------------------------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Pstart| Pstop | TQ |IN-OUT| PQ Distrib |
--------------------------------------------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1546 | 137K| 4006 (1)| 00:00:01 | | | | | |
| 1 | PX COORDINATOR | | | | | | | | | | |
| 2 | PX SEND QC (ORDER) | :TQ10003 | 1546 | 137K| 4006 (1)| 00:00:01 | | | Q1,03 | P->S | QC (ORDER) |
| 3 | SORT GROUP BY | | 1546 | 137K| 4006 (1)| 00:00:01 | | | Q1,03 | PCWP | |
| 4 | PX RECEIVE | | 1546 | 137K| 4006 (1)| 00:00:01 | | | Q1,03 | PCWP | |
| 5 | PX SEND RANGE | :TQ10002 | 1546 | 137K| 4006 (1)| 00:00:01 | | | Q1,02 | P->P | RANGE |
| 6 | HASH GROUP BY | | 1546 | 137K| 4006 (1)| 00:00:01 | | | Q1,02 | PCWP | |
|* 7 | HASH JOIN | | 580K| 50M| 4002 (1)| 00:00:01 | | | Q1,02 | PCWP | |
| 8 | PX RECEIVE | | 23 | 621 | 2 (0)| 00:00:01 | | | Q1,02 | PCWP | |
| 9 | PX SEND BROADCAST | :TQ10000 | 23 | 621 | 2 (0)| 00:00:01 | | | Q1,00 | P->P | BROADCAST |
| 10 | PX BLOCK ITERATOR | | 23 | 621 | 2 (0)| 00:00:01 | | | Q1,00 | PCWC | |
| 11 | TABLE ACCESS FULL | COUNTRIES | 23 | 621 | 2 (0)| 00:00:01 | | | Q1,00 | PCWP | |
|* 12 | HASH JOIN | | 580K| 35M| 3999 (1)| 00:00:01 | | | Q1,02 | PCWP | |
| 13 | PX RECEIVE | | 55500 | 541K| 117 (0)| 00:00:01 | | | Q1,02 | PCWP | |
| 14 | PX SEND BROADCAST | :TQ10001 | 55500 | 541K| 117 (0)| 00:00:01 | | | Q1,01 | P->P | BROADCAST |
| 15 | PX BLOCK ITERATOR | | 55500 | 541K| 117 (0)| 00:00:01 | | | Q1,01 | PCWC | |
| 16 | TABLE ACCESS FULL | CUSTOMERS | 55500 | 541K| 117 (0)| 00:00:01 | | | Q1,01 | PCWP | |
|* 17 | HASH JOIN | | 580K| 29M| 3882 (1)| 00:00:01 | | | Q1,02 | PCWP | |
|* 18 | TABLE ACCESS FULL | CHANNELS | 2 | 42 | 2 (0)| 00:00:01 | | | Q1,02 | PCWP | |
|* 19 | HASH JOIN | | 1161K| 36M| 3879 (1)| 00:00:01 | | | Q1,02 | PCWP | |
| 20 | PART JOIN FILTER CREATE| :BF0000 | 1845 | 22140 | 19 (0)| 00:00:01 | | | Q1,02 | PCWP | |
|* 21 | TABLE ACCESS FULL | TIMES | 1845 | 22140 | 19 (0)| 00:00:01 | | | Q1,02 | PCWP | |
| 22 | PX BLOCK ITERATOR | | 3673K| 73M| 3857 (1)| 00:00:01 |:BF0000|:BF0000| Q1,02 | PCWC | |
| 23 | TABLE ACCESS FULL | SALES | 3673K| 73M| 3857 (1)| 00:00:01 |:BF0000|:BF0000| Q1,02 | PCWP | |
--------------------------------------------------------------------------------------------------------------------------------------------

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

7 - access("C"."COUNTRY_ID"="R"."COUNTRY_ID")
12 - access("S"."CUST_ID"="C"."CUST_ID")
17 - access("S"."CHANNEL_ID"="CH"."CHANNEL_ID")
18 - filter("CH"."CHANNEL_DESC"='Internet' OR "CH"."CHANNEL_DESC"='Partners')
19 - access("S"."TIME_ID"="T"."TIME_ID")
21 - filter("T"."FISCAL_YEAR"=2000 OR "T"."FISCAL_YEAR"=2005 OR "T"."FISCAL_YEAR"=2010 OR "T"."FISCAL_YEAR"=2015 OR
"T"."FISCAL_YEAR"=2016)

Note
-----
- dynamic statistics used: dynamic sampling (level=2)
- Degree of Parallelism is 4 because of session
- 1 Sql Plan Directive used for this statement

参考
Database Virtual Box Appliance / Virtual Machine
Installing Sample Schemas
Getting started with Oracle Database In-Memory Part V - Aggregation
津島博士のパフォーマンス講座 - 第54回　Oracle Database In-Memoryについて（２）

利用したSQL
sample1_2.sql
Right-Deep Join (Right-Deep Treeにならない場合には　SWAP_JOIN_INPUTSで制御する必要がありますが、SHスキーマでオプティマイザ統計が取得されているのであれば不要.今回の例ではSWAP_JOIN_INPUTSは利用していませんが、オプティマイザは判断を誤るようであれば利用したほうがよいと思います。）

SELECT
/*+
MONITOR
LEADING(r sum)
USE_HASH(r sum)
*/
sum.fiscal_year
, r.country_name
, sum.channel_class
, sum.sales_amount
FROM
(
SELECT
t.fiscal_year
, c.country_id
, ch.channel_class
, SUM(s.amount_sold) sales_amount
FROM
sales s
, times t
, customers c
, channels ch
WHERE
s.time_id = t.time_id
AND s.cust_id = c.cust_id
AND s.channel_id = ch.channel_id
AND ch.channel_desc in ('Internet','Partners')
AND t.fiscal_year IN (
2000, 2005, 2010, 2015, 2016
)
GROUP BY
ch.channel_class
, c.country_id
, t.fiscal_year
) sum
, countries r
WHERE
sum.country_id = r.country_id
ORDER BY
sum.fiscal_year
, r.country_name
, sum.channel_class
/

sample2_2.sql
スター変換ヒントが必要です。スター変換はデフォルトでOFFに設定されています。
SHスキーマはスタースキーマかつ、スター変換をすぐに試せる環境（ファクト表の外部キーのビットマップ索引やデョメンジョン表への参照整合性制約等）になっています。

SELECT
/*+
MONITOR
LEADING(r sum)
USE_HASH(r sum)
*/
sum.fiscal_year
, r.country_name
, sum.channel_class
, sum.sales_amount
FROM
(
SELECT
/*+
STAR_TRANSFORMATION
*/
t.fiscal_year
, c.country_id
, ch.channel_class
, SUM(s.amount_sold) sales_amount
FROM
sales s
, times t
, customers c
, channels ch
WHERE
s.time_id = t.time_id
AND s.cust_id = c.cust_id
AND s.channel_id = ch.channel_id
AND ch.channel_desc in ('Internet','Partners')
AND t.fiscal_year IN (
2000, 2005, 2010, 2015, 2016
)
GROUP BY
ch.channel_class
, c.country_id
, t.fiscal_year
) sum
, countries r
WHERE
sum.country_id = r.country_id
ORDER BY
sum.fiscal_year
, r.country_name
, sum.channel_class
/

sample3_2.sql
ベクター変換の例です。ベクター変換のヒントは数種類（ファクト表を記述場合、ディメンジョン表を記述場合）あります。（詳細はv$sql_hintを参照のこと）

SELECT
/*+
MONITOR
LEADING(r sum)
USE_HASH(r sum)
*/
sum.fiscal_year
, r.country_name
, sum.channel_class
, sum.sales_amount
FROM
(
SELECT
/*+
VECTOR_TRANSFORM
*/
t.fiscal_year
, c.country_id
, ch.channel_class
, SUM(s.amount_sold) sales_amount
FROM
sales s
, times t
, customers c
, channels ch
WHERE
s.time_id = t.time_id
AND s.cust_id = c.cust_id
AND s.channel_id = ch.channel_id
AND ch.channel_desc in ('Internet','Partners')
AND t.fiscal_year IN (
2000, 2005, 2010, 2015, 2016
)
GROUP BY
ch.channel_class
, c.country_id
, t.fiscal_year
) sum
, countries r
WHERE
sum.country_id = r.country_id
ORDER BY
sum.fiscal_year
, r.country_name
, sum.channel_class
/

明日は、@yoshikawさんです！　お楽しみに！

俺のターンおわたー！:)

投稿日時 2016年12月17日 (土) 16時07分 Oracle, チューニング, FAQ, SQL, JPOUG, Oracle12c R1, Exadata Machine, Advent Calendar, Index Only Scan, SIMD | 固定リンク | 0 | コメント (0) | トラックバック (0)

2016年7月19日 (火)

DB Tech Showcase 2016 Tokyo - E35 - SQLチューニング総合診療所的予防医学のセッション資料

DB Tech Showcase 2016 Tokyo - E35 - SQLチューニング総合診療所的予防医学のセッション資料を公開しました。

ぼくとつと、性能試験データの質などのことを言い続ける感じになっていたでしょうか？w

DB Tech Showcase 2016 - E35 - SQLチューニング総合診療所的予防医学 from Hiroshi Sekiguchi

ところで、次回のJPOUG主催のイベントの開催が決まりました。セッション内容は現在準備中ですが、確定次第随時更新します。
お申し込みは以下のイベントベージよりお願いします。

JPOUG in 15 minutes #1

投稿日時 2016年7月19日 (火) 22時44分チューニング, SQL, JPOUG, Oracle12c R1, Oracle Database 12c release 1, DB Tech Showcase, パフォーマンス | 固定リンク | 0 | コメント (0) | トラックバック (0)

2016年3月27日 (日)

OracleのB*Tree索引にはNULLが含まれる場合があるんです！ - その性質を使ってチューニングすることもあるよ:)　その３

前回までのMac De Oracle

OracleのB*Tree索引にはNULLが含まれる場合があるんです！ - その性質を使ってチューニングすることもあるよ:)

OracleのB*Tree索引にはNULLが含まれる場合があるんです！ - その性質を使ってチューニングすることもあるよ:)　その２

ということで、続きで〜〜すっ。

こんな表定義で

orcl@SCOTT> desc tab01
Name Null? Type
--------- -------- --------
FOO NUMBER
BAR NUMBER
HOGE NOT NULL CHAR(2)
ID NOT NULL NUMBER

こんな索引があって

****** Index column info : tab01 ******

INDEX_NAME COLUMN_NAME DESC
------------------------------ ------------------------------ ----
IX1_TAB01 FOO ASC

IX2_TAB01 BAR ASC
FOO ASC

IX3_TAB01 ID ASC
FOO ASC

IX4_TAB01 ID ASC
BAR ASC
FOO ASC

PK_TAB01 ID ASC

こんなデータで

orcl@SCOTT> set null [NULL]
orcl@SCOTT> select * from tab01

FOO BAR HO ID
---------- ---------- -- ----------
[NULL] [NULL] ** 1
1 [NULL] ** 2
[NULL] 1 ** 3
1 1 ** 4

2列の複合索引、どちらの列もNULLだと、やはり、NULLは索引に含まれないので　IS NULL検索だと索引は利用されないですよねぇ〜。このような状態ではヒントで索引利用を強制利用させようとしても無理です。

orcl@SCOTT> r
1 select
2 /*+
3 gather_plan_statistics
4 index(tab01 ix2_tab01)
5 no_index(tab01 ix4_tab01)
6 no_index(tab01 ix3_tab01)
7 */
8 *
9 from
10 tab01
11 where
12 foo is null
13* and bar is null
　　　　　
FOO BAR HO ID
---------- ---------- -- ----------
[NULL] [NULL] ** 1

・・・略・・・
-------------------------------------------------------------------------------------
| Id | Operation | Name | Starts | E-Rows | A-Rows | A-Time | Buffers |
-------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | | 1 |00:00:00.01 | 8 |
|* 1 | TABLE ACCESS FULL| TAB01 | 1 | 1 | 1 |00:00:00.01 | 8 |
-------------------------------------------------------------------------------------

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

1 - filter(("FOO" IS NULL AND "BAR" IS NULL))

でも、NOT NUL制約の列が1列でも含まれている索引であればNULLは索引に含まれます。（前回までの復習も兼ねた確認）
第1列がWHERE句で記述されていないので索引スキップスキャンになっていますが.....IS NULL検索を索引アクセスだけで行っているのがよく分かる例の一つです：）

orcl@SCOTT> r
1 select
2 /*+
3 gather_plan_statistics
4 */
5 *
6 from
7 tab01
8 where
9 foo is null
10* and bar is null

FOO BAR HO ID
---------- ---------- -- ----------
[NULL] [NULL] ** 1

・・・略・・・
--------------------------------------------------------------------------------------------------------------------
| Id | Operation | Name | Starts | E-Rows | A-Rows | A-Time | Buffers | Reads |
--------------------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | | 1 |00:00:00.01 | 3 | 1 |
| 1 | TABLE ACCESS BY INDEX ROWID BATCHED| TAB01 | 1 | 1 | 1 |00:00:00.01 | 3 | 1 |
|* 2 | INDEX SKIP SCAN | IX4_TAB01 | 1 | 1 | 1 |00:00:00.01 | 2 | 1 |
--------------------------------------------------------------------------------------------------------------------

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

2 - access("BAR" IS NULL AND "FOO" IS NULL)
filter(("FOO" IS NULL AND "BAR" IS NULL))

最後にもう少しわかりやすい例を。

SQL文を少々書き換えてIndex Only Scanになるようにしました。索引にNULLが含まれていないと索引だけのアクセスで済むわけがないわけで、これ以上わかりやすい例はないと思います：）

まず、索引が利用できない例から。
FOO列とBAR列だけの複合索引をヒントで強制利用させようとしていますが、この索引は２列ともnullableなので２列をIS NULL検索しても索引が利用されません！
全ての列がNULLである場合、キーエントリーは索引に作成されない。単一列でも複合索引でも同じであることが確認できます。

orcl@SCOTT> r
1 select
2 /*+
3 gather_plan_statistics
4 index(tab01 ix2_tab01)
5 no_index(tab01 ix4_tab01)
6 no_index(tab01 ix3_tab01)
7 */
8 *
9 from
10 tab01
11 where
12 foo is null
13* and bar is null

FOO BAR HO ID
---------- ---------- -- ----------
[NULL] [NULL] ** 1

・・・略・・・
-------------------------------------------------------------------------------------
| Id | Operation | Name | Starts | E-Rows | A-Rows | A-Time | Buffers |
-------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | | 1 |00:00:00.01 | 8 |
|* 1 | TABLE ACCESS FULL| TAB01 | 1 | 1 | 1 |00:00:00.01 | 8 |
-------------------------------------------------------------------------------------

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

1 - filter(("FOO" IS NULL AND "BAR" IS NULL))

おっと、
大切なのを忘れてました。

FOO列(nullable(、BAR列(nullable)の複合索引を　IS NOT NULL AND IS NULLで検索した場合はどうなるか？
答えは以下の通り。IS NULL と　IS NOT NULLの組み合わせでも、索引が利用されます。:)

BAR IS NULLで範囲検索しFOO IS NOT NULLでフィルタリングしています。 NULLが含まれていないと不可能な索引レンジスキャンと索引読み時のフィルタリング！

orcl@SCOTT> r
1 select
2 /*+
3 gather_plan_statistics
4 no_index(tab01 ix3_tab01)
5 no_index(tab01 ix4_tab01)
6 */
7 foo
8 , bar
9 from
10 tab01
11 where
12 foo is not null
13* and bar is null

FOO BAR
---------- ----------
1 [NULL]

・・・略・・・
-------------------------------------------------------------------------------------------------
| Id | Operation | Name | Starts | E-Rows | A-Rows | A-Time | Buffers | Reads |
-------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | | 1 |00:00:00.02 | 1 | 1 |
|* 1 | INDEX RANGE SCAN| IX2_TAB01 | 1 | 1 | 1 |00:00:00.02 | 1 | 1 |
-------------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------

1 - access("BAR" IS NULL)
filter("FOO" IS NOT NULL)

その逆も！

orcl@SCOTT> r
1 select
2 /*+
3 gather_plan_statistics
4 no_index(tab01 ix3_tab01)
5 no_index(tab01 ix4_tab01)
6 */
7 foo
8 , bar
9 from
10 tab01
11 where
12 foo is null
13* and bar is not null

FOO BAR
---------- ----------
[NULL] 1

・・・略・・・
----------------------------------------------------------------------------------------
| Id | Operation | Name | Starts | E-Rows | A-Rows | A-Time | Buffers |
----------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | | 1 |00:00:00.01 | 2 |
|* 1 | INDEX SKIP SCAN | IX2_TAB01 | 1 | 1 | 1 |00:00:00.01 | 2 |
----------------------------------------------------------------------------------------

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

1 - access("FOO" IS NULL)
filter(("FOO" IS NULL AND "BAR" IS NOT NULL))

もういっちょ！
２列とものnullableな索引だとindex fast full scanにはできないけど、index full scanにはできるんですよ〜。

orcl@SCOTT7gt; r
1 select
2 /*+
3 gather_plan_statistics
4 no_index(tab01 ix3_tab01)
5 no_index(tab01 ix4_tab01)
6 */
7 foo
8 , bar
9 from
10 tab01
11 where
12 foo is not null
13* and bar is not null

FOO BAR
---------- ----------
1 1

・・・略・・・
----------------------------------------------------------------------------------------
| Id | Operation | Name | Starts | E-Rows | A-Rows | A-Time | Buffers |
----------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | | 1 |00:00:00.01 | 2 |
|* 1 | INDEX FULL SCAN | IX2_TAB01 | 1 | 1 | 1 |00:00:00.01 | 2 |
----------------------------------------------------------------------------------------

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

1 - filter(("FOO" IS NOT NULL AND "BAR" IS NOT NULL))

Note
-----
- statistics feedback used for this statement

~~後に、~~NOT NULL列が含まれる索引なら index fast full scanでもできるはず！
独り言；index only scan+index fast full scanなんてのもセグメントサイズが小さければ物理読み込み量削減には効果があるんですよねぇ〜　;-)

orcl@SCOTT> r
1 select
2 /*+
3 gather_plan_statistics
4 no_index(tab01 ix3_tab01)
5 index_ffs(tab01 ix4_tab01)
6 no_index(tab01 ix2_tab01)
7 */
8 foo
9 , bar
10 from
11 tab01
12 where
13 foo is not null
14* and bar is not null

FOO BAR
---------- ----------
1 1

・・・略・・・
-----------------------------------------------------------------------------------------------------
| Id | Operation | Name | Starts | E-Rows | A-Rows | A-Time | Buffers | Reads |
-----------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | | 1 |00:00:00.03 | 4 | 1 |
|* 1 | INDEX FAST FULL SCAN| IX4_TAB01 | 1 | 1 | 1 |00:00:00.03 | 4 | 1 |
-----------------------------------------------------------------------------------------------------

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

1 - filter(("FOO" IS NOT NULL AND "BAR" IS NOT NULL))

オラクルの索引にNULLは絶対含まれない、というのは都市伝説！　
IS NOT NULLは索引使えないとかIS NULLは索引使えないというというのも違うんですよね。　

OracleのB*Tree索引では、索引に含まれる全列がNULLの場合以外はNULLが含まれてまっす！　というのが正しいですよね！？

この手の問題でピンチになったら、思い出してみてください ;)
USE THE INDEX ONLY SCAN, LUKE! w

投稿日時 2016年3月27日 (日) 16時34分 Oracle, FAQ, SQL, ダウンロード, Oracle11g R2, Oracle12c R1, Index Only Scan, INDEX, B*Tree | 固定リンク | 0 | コメント (0) | トラックバック (0)

2016年3月21日 (月)

OracleのB*Tree索引にはNULLが含まれる場合があるんです！ - その性質を使ってチューニングすることもあるよ:)　その２

OracleのB*Tree索引にはNULLが含まれる場合があるんです！ - その性質を使ってチューニングすることもあるよ:)
の続きです。

念のために、もう一つの主役NULL登場してもらいましょう。

IX1_TAB01索引はNullableなFOO列だけの索引なので、このタイプの索引ではNULLは索引に格納されることはありません。
いくらヒントで索引を指定しても索引にはNULLは格納されていないので全表走査になるはず。

注）：索引が多いので意図した索引を利用するようにヒントで固定しています
例２）FOO IS NULL　で検索

orcl@SCOTT> r
1 SELECT
2 /*+
3 gather_plan_statistics
4 index(tab01 ix1_tab01)
5 no_index(tab01 ix3_tab01)
6 no_index(tab01 ix4_tab01)
7 */
8 *
9 FROM
10 tab01
11 WHERE
12* foo IS NULL

FOO BAR HO ID
---------- ---------- -- ----------
[NULL] [NULL] ** 1
[NULL] 1 ** 3

ーーー中略ーーー
Plan hash value: 2044041692

-------------------------------------------------------------------------------------
| Id | Operation | Name | Starts | E-Rows | A-Rows | A-Time | Buffers |
-------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | | 2 |00:00:00.01 | 8 |
|* 1 | TABLE ACCESS FULL| TAB01 | 1 | 2 | 2 |00:00:00.01 | 8 |
-------------------------------------------------------------------------------------

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

1 - filter("FOO" IS NULL)

想定通り。NULLは格納されていないので索引が利用できず全表走査になっています。
索引からROWIDを取得できないので全表走査してフィルタリングしている箇所がポイントです。

OracleのB*Tree索引にはNULLが入らない都市伝説の始まりはここだったんじゃないか？　とい言っている方がいたのですが、ここだけの話が広まってしまい

OracleのB*Tree索引にはNULLは絶対格納されない。

という都市伝説になってしまったのだろうと。。確かに入ってないですからねー。 (^^;;;

では、NULLが索引に含まれる一例を見てみましょう。

例３）ID列（NOT NULL)とFOO列（Nullable）で作成した複合索引を ID=1 AND FOO IS NULLで検索
注）：索引が多いので意図した索引を利用するようにヒントで固定しています

Predicate Informationセクションのaccess predicateを見るとわかると思いますが、ID=1 AND FOO IS NULLで索引をアクセスしています。
NULLが索引に含まれていない場合はこのような状況にはなりません。　
複合索引では1列でもNOT NULL制約がり他の列がNullableである場合、NULLは格納されます。

NULLは格納されることもあるんです。マニュアル上の表現は少々わかりにくいとは思いますが、このような状況を指しています。

orcl@SCOTT> r
1 SELECT
2 /*+
3 gather_plan_statistics
4 no_index(tab01 ix1_tab01)
5 index(tab01 ix3_tab01)
6 no_index(tab01 ix4_tab01)
7 */
8 *
9 FROM
10 tab01
11 WHERE
12 id = 1
13* AND foo IS NULL

FOO BAR HO ID
---------- ---------- -- ----------
[NULL] [NULL] ** 1

ーーー中略ーーー
Plan hash value: 2558346564

-----------------------------------------------------------------------------------------------------------
| Id | Operation | Name | Starts | E-Rows | A-Rows | A-Time | Buffers |
-----------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | | 1 |00:00:00.01 | 3 |
| 1 | TABLE ACCESS BY INDEX ROWID BATCHED| TAB01 | 1 | 1 | 1 |00:00:00.01 | 3 |
|* 2 | INDEX RANGE SCAN | IX3_TAB01 | 1 | 1 | 1 |00:00:00.01 | 2 |
-----------------------------------------------------------------------------------------------------------

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

2 - access("ID"=1 AND "FOO" IS NULL)

少し寄り道。

そういえば、偶になんですが、IS NOT NULLだと索引使うことはないという都市伝説も聞いたことがあります。
それも都市伝説なんですよね。
次の例は、その都市伝説を覆す一例を。

例４）FOO IS NOT NULL　で検索

IX1_TAB01索引は、NullableなFOO列だけの索引です。これまでの検証でこのタイプの索引にはNULLが格納されていないことは確認できると思います。
ようするに、NULLじゃないものは、まるっととズバッと索引に含まれているはずでっす！
なので、FOO IS NOT NULLという検索条件だと索引を使ってくれます。

このような性質を知っているとチューニングに役立つんですよ。
（この例のようなチューニング方法を使ったことは過去数度あるんですよ、苦肉の策でしたけどw　NULLの数が非常に多い場合、この手の索引のセグメントサイズは非常に小さくなります(索引に格納されるエントリそのものがNULLを除くと非常に少ない場合）。その性質を利用したチューニング法もあるんです。）

余談NOTE:
INDEX FAST FULL SCANにならない理由:索引にNOT NULL制約の列が少なくとも１列あること、という前提条件を満たせていないからです。チューニングや設計時に必要な知識なので覚えておくと何かの時に役に立つと思います：）

注）：索引が多いので意図した索引を利用するようにヒントで固定しています

orcl@SCOTT> r
1 SELECT
2 /*+
3 gather_plan_statistics
4 index(tab01 ix1_tab01)
5 no_index(tab01 ix3_tab01)
6 no_index(tab01 ix4_tab01)
7 */
8 *
9 FROM
10 tab01
11 WHERE
12* foo IS NOT NULL

FOO BAR HO ID
---------- ---------- -- ----------
1 [NULL] ** 2
1 1 ** 4

ーーー中略ーーー
Plan hash value: 2840602802

-----------------------------------------------------------------------------------------------------------
| Id | Operation | Name | Starts | E-Rows | A-Rows | A-Time | Buffers |
-----------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | | 2 |00:00:00.01 | 4 |
| 1 | TABLE ACCESS BY INDEX ROWID BATCHED| TAB01 | 1 | 2 | 2 |00:00:00.01 | 4 |
|* 2 | INDEX FULL SCAN | IX1_TAB01 | 1 | 2 | 2 |00:00:00.01 | 2 |
-----------------------------------------------------------------------------------------------------------

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

2 - filter("FOO" IS NOT NULL)

恐竜博とか＊＊博ってやつは、最後のショップがメインで博のほうはおまけなんじゃないかと最近思ってるw　子供達の目が活き活きしているのはショップに入ってからだ！w

次回へつづく。

投稿日時 2016年3月21日 (月) 16時44分 Oracle, チューニング, SQL, Index Only Scan, INDEX, B*Tree | 固定リンク | 0 | コメント (0) | トラックバック (0)

2016年3月20日 (日)

OracleのB*Tree索引にはNULLが含まれる場合があるんです！ - その性質を使ってチューニングすることもあるよ:)

先日、OracleのB*Tree索引には絶対にNULLが含まれないって思い込んでる人が意外にいるよね〜とか。
OracleのB*Tree索引には絶対NULLが含まれないって都市伝説があるのはなんでだろう。
Oracle® Database概要12cリリース1 (12.1) - 一意索引と非一意索引

みたいなことが話題になって、
ある一人が、「だよね〜、ダンプ見れば含まれてるのわかります。」って言ってて、それ、ふつ〜の人は見ないからw

と思いつつ、私の周りには、やはり、変態が多いことに改めて気づいた次第です。：）　はい。

で、
変態じゃない、ごく一般的なエンジニアの方々（ブロックダンプを華麗かつ自然にキメちゃわない方々）向けに、

OracleのB*Tree索引にNULLが含まれているか、NULLが含まれていないかの簡単な確認方法をお伝えしなければ！w

ということで、数回にわけて書いておこうかと思ってます。（予定は未定w）

（実は、このネタとほぼ同じことを１年前ぐらい前に、ローカルかつクローズドな勉強会？、でも使ってました。　最近、やってないみたいですけど）

環境は最近の定番　Oracle Database 12c R1 EE

orcl@SCOTT> select banner from v$version;

BANNER
--------------------------------------------------------------------------------
Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production
PL/SQL Release 12.1.0.2.0 - Production
CORE 12.1.0.2.0 Production
TNS for Linux: Version 12.1.0.2.0 - Production
NLSRTL Version 12.1.0.2.0 - Production

SCOTTスキーマに以下のような表と索引を作成し少ないですが、データを登録
今回の主役は索引とNULLなのでデータ量少なくても必要なパターンが登録できていれば十分です。
（データ量を増やせばチューニングのお題の元ネタにもなると思います。）

orcl@SCOTT> create table tab01 (foo number, bar number, hoge char(2) not null,id number not null);

Table created.

orcl@SCOTT> insert into tab01 values(null,null,'**',1);

1 row created.

orcl@SCOTT> insert into tab01 values(1,null,'**',2);

1 row created.

orcl@SCOTT> insert into tab01 values(null,1,'**',3);

1 row created.

orcl@SCOTT> insert into tab01 values(1,1,'**',4);

1 row created.

orcl@SCOTT> commit;

Commit complete.

orcl@SCOTT> alter table tab01 add constraint pk_tab01 primary key(id) using index;

Table altered.

orcl@SCOTT> exec dbms_stats.gather_table_stats(ownname=>'SCOTT',tabname=>'TAB01',cascade=>true,no_invalidate=>false);

PL/SQL procedure successfully completed.

orcl@SCOTT> create index ix1_tab01 on tab01 (foo);

Index created.

orcl@SCOTT> create index ix2_tab01 on tab01 (bar,foo);

Index created.

orcl@SCOTT> create index ix3_tab01 on tab01(id,foo);

Index created.

orcl@SCOTT> create index ix4_tab01 on tab01(id,bar,foo);

Index created.

FOOとBAR列はNullableにしています

orcl@SCOTT> desc tab01
Name Null? Type
----------------------------------------- -------- ----------------------------
FOO NUMBER
BAR NUMBER
HOGE NOT NULL CHAR(2)
ID NOT NULL NUMBER

主演の索引たち

NULLが索引でどう扱われるかを確認するため、事前作成の索引をたくさん用意してしました。後から作るの面倒なのでw
これだけ類似索引も含めて多数の索引があると確認時に意図した索引が利用されない可能性も高いため、検証では内容に合わせて利用する索引をヒントで指定することにします。

ちなみに、
普通の環境でこんなに索引があったら、アンチパターン：インデックスショットガンですからね。ご注意ください:) たまにこのような環境に遭遇することはありますが。。。

IX1_TAB01はnullableなFOO列だけの単一列索引
IX2_TAB01はnullableなBAR列とFOO列からなる複合索引
IX3_TAB01とTX4_TAB01は上記の列に加え主キー列のID列を第1キーとする複合索引

としてあります。

orcl@SCOTT> break on table_name on index_name skip 1
orcl@SCOTT> select table_name,index_name,column_name from user_ind_columns where table_name='TAB01' order by table_name,index_name,column_position;

TABLE_NAME INDEX_NAME COLUMN_NAME
------------------------------ ------------------------------ ------------------------------
TAB01 IX1_TAB01 FOO

IX2_TAB01 BAR
FOO

IX3_TAB01 ID
FOO

IX4_TAB01 ID
BAR
FOO

PK_TAB01 ID

登録したデータは以下の通り
NULLは索引とともに今回の主役なので、どこがNULLになっているかメモしておいてくださいませ。

orcl@SCOTT> set null [NULL]
orcl@SCOTT> select * from tab01 order by id;

FOO BAR HO ID
---------- ---------- -- ----------
[NULL] [NULL] ** 1
1 [NULL] ** 2
[NULL] 1 ** 3
1 1 ** 4

さて、索引にNULLが含まれているか、いないか、どうやって確認すると思います？　ブロックダンプを華麗にキメきめる以外の方法でw

SQLチューニングをしたことがある方なら一般的に利用してい（と思ってる）機能で簡単に確認できちゃうんですよ。これが。

SQL*Plusのautotraceや、explain plan それに、DBMS_XPLAN.DISPLAY*　なファンクションでも確認できます。
SQLclはautotraceにはまだ未対応となっているようですが、それ以外の方法ならはできるようです。
（今回はSQL*Plusを使い、dbms_xplan.display_cursor(format=>'ALLSTATS LAST'))で確認します）

どうやって、どの部分で確認するのか？　
autottraceやDBMS_XPLAN.DISPLAY*などでリストされるpredicate information部分のaccess/filter predicate部分で確認できるんです！

例１）FOO = 1　で検索した例

注）：索引が多いので意図した索引を利用するようにヒントで固定しています

おわかりでしょうか？
Predicate Infomation部分から、Id=2のINDEX RANGE SCANで　IX1_TAB01索引を　FOO=1でアクセスしていることが読み取れますよね？
つまり、1 という値が索引に含まれている（含まれる）からaccess pathとしてIX1_TAB01索引を参照しているわけです。

orcl@SCOTT> r
1 SELECT
2 /*+
3 gather_plan_statistics
4 index(tab01 ix1_tab01)
5 */
6 *
7 FROM
8 tab01
9 WHERE
10* foo = 1

FOO BAR HO ID
---------- ---------- -- ----------
1 [NULL] ** 2
1 1 ** 4

orcl@SCOTT> select * from table(dbms_xplan.display_cursor(format=>'ALLSTATS LAST'));

ーーー中略ーーー

Plan hash value: 3795960549

-----------------------------------------------------------------------------------------------------------
| Id | Operation | Name | Starts | E-Rows | A-Rows | A-Time | Buffers |
-----------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | | 2 |00:00:00.01 | 4 |
| 1 | TABLE ACCESS BY INDEX ROWID BATCHED| TAB01 | 1 | 2 | 2 |00:00:00.01 | 4 |
|* 2 | INDEX RANGE SCAN | IX1_TAB01 | 1 | 2 | 2 |00:00:00.01 | 2 |
-----------------------------------------------------------------------------------------------------------

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

2 - access("FOO"=1)

ということで、今日は馬事公苑の散歩は気持ちいいよ〜。

次回へつづく。

投稿日時 2016年3月20日 (日) 17時55分 Oracle, チューニング, FAQ, SQL, INDEX, B*Tree | 固定リンク | 0 | コメント (0) | トラックバック (0)

2016年3月19日 (土)

Relational Database Index Design and the Optimizers [Kindle版]とUSE THE INDEX, LUKE

時代は繰り返すw　のか？　という感じで何周目かのIndex only scanとかのネタを元にした資料とか作ることが多くて。。。

索引の設計って、基本的に、機械的だと思っているのですが、皆さんはどう思っているのか気になる今日この頃。
初心者ならともかく、そうでもない感じの方が、腕組みして、眉間にしわ寄せてるのをみるとちょっと心配になっちゃったり。

と昨日のtwで見かけたやつとかも含めて参考になりそうな書籍を載せておきますね。

最初は私のお気に入りの一冊（ハードカバー本でしたが、最近kindle版がでてました。そして私が買った時より高いw
この書籍は2011 db tech showcaseでTom Kyteさんが紹介していたもので、速攻でポチった記憶があります。
そしてその頃は、8,000円台でしたw(円高だったからねぇ）

この書籍ではCovering Index → FAT Index / Semi Covering Index → Semi FAT Indexと記載されています。

Web上でも読めるんですが、書籍化されPDF版もでてます。
SQLパフォーマンス詳解(原文タイトルSQL Performance Explained)

USE THE INDEX, LUKE - 開発者のためのSQLパフォーマンスの全て

投稿日時 2016年3月19日 (土) 10時41分 Oracle, Oracle以外のデータベース, その他, チューニング, SQL, 本, Index Only Scan | 固定リンク | 0 | コメント (0) | トラックバック (0)

2015年12月30日 (水)

Pipelined table function で ascii art

クリスマスも過ぎ、新年へのカウントダウンも始まっていますが、
Pipelined table functionを使って簡単なASCIIアートをJPOUG Advent Calendar 2012描画してましたが中身を公開してなかったな〜
ということで、少々手直しして公開！

公開しておくとPipelined table functionとかtable functionを書かなきゃなった時に思い出しやすいのでw　自分向けなんですけどね。 (^^;;

参考：
Oracle Database Online Documentation 12c Release 1 (12.1)
Unstructured Data and Content Management
13 Using Pipelined and Parallel Table Functions

create or replace type messageTblType as table of varchar2(300)
/

注）
以下関数ではdbms_lock.sleep()を利用しているため、事前にexecute権限を付与しておく必要があります。
また、エラー処理は端折ってます. (^^;;
　

create or replace function tree(lheight pls_integer, linterval_change_color float)
return messageTblType
pipelined
as
height_of_tree pls_integer := lheight;
center pls_integer;
i pls_integer := 1;
siz_of_trunk pls_integer := 3;
pos_of_trunk pls_integer;
interval_change_color float := linterval_change_color;
begin
center := ceil((1 + height_of_tree + ( height_of_tree - 2)) / 2);
pos_of_trunk := case when ceil(height_of_tree / 5) > 10 then 10 else ceil(height_of_tree / 5) end;
for l in 1..75 loop
pipe row(chr(27)||'[2J'||chr(27)||'[1;'||to_char(ceil(dbms_random.value(1,7))+30)||'m');
i := 1;
--draw leaves
while (i < height_of_tree) loop
pipe row(
chr(27)||'['||to_char(i,'FM0999')||';'||to_char(center - i,'FM0999')||'H'||lpad('*', i + (i - 2) + 1, '*')
);
i := i + 1;
end loop;
--draw trunk
for j in -1..pos_of_trunk loop
pipe row(
chr(27)||'['||to_char(j + height_of_tree,'FM0999')||';'||to_char(center - 2,'FM0999')||'H'||lpad('*', siz_of_trunk, '*')
);
end loop;
dbms_lock.sleep(interval_change_color);
end loop;
pipe row(chr(27)||'[0m');
return;
end;
/
show errors

以下、実行コードの例
Treeのサイズを10/20/50、色の変更感覚を0.2秒として実行してます。

set linesize 300
set pagesize 0
set array 1
select * from table(tree(10, 0.2));
select * from table(tree(20, 0.2));
select * from table(tree(50, 0.2));

実行結果はYoutubeで:)

投稿日時 2015年12月30日 (水) 23時18分 SQL, Oracle11g R2, Oracle12c R1 | 固定リンク | 0 | コメント (0) | トラックバック (0)

2015年12月26日 (土)

クリスマスのお遊び - SQL de Fractals :)

Twitterを見ていたら以下のtweetが目に入った！　お！　面白そう。

Beautiful Fractals with SQL https://t.co/7jXv1G2hjE pic.twitter.com/EqLrPFS6aG
— SQL Performance Tips (@SQLPerfTips) 2015, 12月 25

元のサイトを覗いてみたら :) w
EXPLAIN EXTENDED -
http://explainextended.com/2013/12/31/happy-new-year-5/

元ネタはPostgreSQLだったので、Oracle Database 12c R1で書き換えて遊んでみた。 :)
遊びながら覚えるSQLってのも面白いよね。久々にLISTAGGなんて使ったよw

元々あるOracleの方言、階層問合せと、11gR2から実装された階層再帰問合せを組み合わせてます。
PostgreSQLでは、generate_series()関数が利用されていますが、Oracleでは階層問合せかCUBEとrownumを組み合わせて生成するしかないのでちょいとカッコ悪いかもw
ただ、ARRAY_TO_STRING(ARRAY_AGG(s ORDER BY r), '')　の箇所は、Oracleなら LISTAGG WITHIN...と１つの関数で代替できたので判りやすいかも。

WITH
q (r, i, rx, ix, g) AS
(
SELECT
CAST(r.r AS DOUBLE PRECISION) * 0.02 AS r
, CAST(i.i AS DOUBLE PRECISION) * 0.02 AS i
, CAST(.0 AS DOUBLE PRECISION) AS rx
, CAST(.0 AS DOUBLE PRECISION) AS ix
, 0 AS g
FROM
(
SELECT
LEVEL - 61 AS r
FROM
DUAL
CONNECT BY
LEVEL <= 80
) r,
(
SELECT
LEVEL - 51 AS i
FROM
DUAL
CONNECT BY
LEVEL <= 100
) i
UNION ALL
SELECT
r
, i
, CASE
WHEN ABS(rx * rx + ix * ix) <= 2
THEN
rx * rx - ix * ix
END + r AS rx
, CASE
WHEN ABS(rx * rx + ix * ix) <= 2
THEN
2 * rx * ix
END + i AS ix
, g + 1 AS g
FROM
q
WHERE
rx IS NOT NULL
AND g < 99
)
SELECT
LISTAGG(s,'') WITHIN GROUP ( ORDER BY r ) AS Mandelbrot
FROM
(
SELECT
i
, r
, SUBSTR(' .:-=+*#%@', MAX(g) / 10 + 1, 1) s
FROM
q
GROUP BY
i
, r
) q
GROUP BY
i
ORDER BY
i
;

実行計画も載せておきますね
こんな実行計画になるのか〜〜〜面白〜い :) :) :)

Global Stats
=================================================
| Elapsed | Cpu | Other | Fetch | Buffer |
| Time(s) | Time(s) | Waits(s) | Calls | Gets |
=================================================
| 35 | 35 | 0.05 | 8 | 22M |
=================================================

SQL Plan Monitoring Details (Plan Hash Value=1659179395)
============================================================================================================================================================
| Id | Operation | Name | Rows | Cost | Time | Start | Execs | Rows | Mem | Activity | Activity Detail |
| | | | (Estim) | | Active(s) | Active | | (Actual) | (Max) | (%) | (# samples) |
============================================================================================================================================================
| 0 | SELECT STATEMENT | | | | 1 | +35 | 1 | 100 | | | |
| 1 | SORT GROUP BY | | 2 | 8 | 1 | +35 | 1 | 100 | 499K | | |
| 2 | VIEW | | 2 | 8 | 1 | +35 | 1 | 8000 | | | |
| 3 | HASH GROUP BY | | 2 | 8 | 34 | +2 | 1 | 8000 | 1M | | |
| 4 | VIEW | | 2 | 8 | 34 | +2 | 1 | 424K | | | |
| 5 | UNION ALL (RECURSIVE WITH) BREADTH FIRST | | | | 35 | +1 | 1 | 424K | 16M | 100.00 | Cpu (35) |
| 6 | MERGE JOIN CARTESIAN | | 1 | 4 | 1 | +2 | 1 | 8000 | | | |
| 7 | VIEW | | 1 | 2 | 1 | +2 | 1 | 80 | | | |
| 8 | CONNECT BY WITHOUT FILTERING | | | | 1 | +2 | 1 | 80 | 2048 | | |
| 9 | FAST DUAL | | 1 | 2 | 1 | +2 | 1 | 1 | | | |
| 10 | BUFFER SORT | | 1 | 4 | 1 | +2 | 80 | 8000 | 4096 | | |
| 11 | VIEW | | 1 | 2 | 1 | +2 | 1 | 100 | | | |
| 12 | CONNECT BY WITHOUT FILTERING | | | | 1 | +2 | 1 | 100 | 2048 | | |
| 13 | FAST DUAL | | 1 | 2 | 1 | +2 | 1 | 1 | | | |
| 14 | RECURSIVE WITH PUMP | | | | 34 | +2 | 100 | 416K | | | |
============================================================================================================================================================

追記！
$Sql_de_fractals_frost_pattern$

WITH
q (r, i, rx, ix, g) AS
(
SELECT
CAST(r.r AS DOUBLE PRECISION) * 0.0002 AS r
, CAST(i.i AS DOUBLE PRECISION) * 0.0002 AS i
, CAST(r.r AS DOUBLE PRECISION) * 0.0002 AS rx
, CAST(i.i AS DOUBLE PRECISION) * 0.0002 AS ix
, 0 AS g
FROM
(
SELECT
LEVEL - 201 AS r
FROM
DUAL
CONNECT BY
LEVEL <= 120
) r,
(
SELECT
LEVEL - 1 AS i
FROM
DUAL
CONNECT BY
LEVEL <= 100
) i
UNION ALL
SELECT
r
, i
, CASE
WHEN ABS(rx * rx + ix * ix) < 1E+8
THEN
rx * rx - ix * ix
END - 0.70176 AS rx
, CASE
WHEN ABS(rx * rx + ix * ix) < 1E+8
THEN
2 * rx * ix
END + 0.3842 AS ix
, g + 1 AS g
FROM
q
WHERE
rx IS NOT NULL
AND g < 99
)
SELECT
LISTAGG(s,'') WITHIN GROUP ( ORDER BY r ) AS frost_patterns
FROM
(
SELECT
i
, r
, SUBSTR(' .:-=+*#%@', MAX(g) / 10 + 1, 1) s
FROM
q
GROUP BY
i
, r
) q
GROUP BY
i
ORDER BY
i
;

投稿日時 2015年12月26日 (土) 03時11分 SQL, Oracle Database 12c release 1 | 固定リンク | 0 | コメント (0) | トラックバック (0)

2015年12月 4日 (金)

OTHER_XMLの中身

JPOUG Advent Calendar 2015 - 4日目のエントリーです。

役に立たないから、絶対最後まで読まないでね！！！　(^^)

さて、
みなさん、マニュアル読んでますか？　
最近は量が多いので、必要になってから、なりそうだから読むことが多いです。
Oracle® Databaseリファレンス 12cリリース1 (12.1) なんて特にそうです。
ただ、一度読み始めると、いろいろと気づくところもあるわけです...こんな情報が取れるのか！　とか。

あ〜、これは、禁断のw　マニュアルに記載されてないパラメータを指定すると見れるやつだ！！！　とか気づくこともあったり。

例えば、V$SQL_PLANやDBA_HIST_SQL_PLANのOTHER_XML列。

この列の説明には実に興味深いことが書かれています。以下の説明、読んでてワクワクしますw　
何が格納されているのでしょう？？？（もう、みんな知ってるくせに〜）

”アウトライン・データ(同じ計画の再作成に使用できる一連のオプティマイザ・ヒント)”

見たくないですか？　中身。

見たいですよね。私もそうです！

ただ、OTHER_XML列、列名の通り、CLOB型で中身はXMLです！！！
SQL*Plusで普通に表示しようとすると長すぎて読みにくいってのが難点w

ならばXMLにも対応しているSQL文で何とかしてみたいと思います。

ゴニョゴニョ、パタパタ。

できました。

dba_hist_sql_plan向けですが。(v$sql_planビューでも同様のことができます！）
（注：dba_hist_*ビューを参照するにはOracle Diagnostics Packが必要でっす。ですが、v$sql_planを参照するのならオプションはいらないですよね.）

こんな感じです

SYSTEM> !cat report_outline_hints.sql col outline for a200 set linesize 300 set pagesize 10000 set veri off SELECT '/*+' AS outline FROM DUAL UNION ALL SELECT ' '||'BEGIN_OUTLINE_DATA' FROM DUAL UNION ALL SELECT ' '||o.outlinehint FROM ( SELECT EXTRACTVALUE( VALUE(x) , '/hint/text()' ) AS outlinehint FROM XMLTABLE( '/*/outline_data/hint' PASSING( SELECT XMLTYPE(other_xml) FROM dba_hist_sql_plan WHERE other_xml IS NOT NULL AND sql_id = '&1' AND plan_hash_value = &2 ) ) x ) o UNION ALL SELECT ' '||'END_OUTLINE_DATA' FROM DUAL UNION ALL SELECT '*/' FROM DUAL / set veri on

実行すると以下のような、:)　情報を取り出すことができます！！

SYSTEM> @report_outline_hints gdtyuqcyk8x1c 2236229349 OUTLINE ------------------------------------------------------------------------------------------ /*+ BEGIN_OUTLINE_DATA IGNORE_OPTIM_EMBEDDED_HINTS OPTIMIZER_FEATURES_ENABLE('12.1.0.2') DB_VERSION('12.1.0.2') ALL_ROWS OUTLINE_LEAF(@"SEL$2") OUTLINE_LEAF(@"SEL$1") INDEX(@"SEL$1" "B"@"SEL$1" ("ILM_EXECUTION$"."EXECUTION_ID")) NO_ACCESS(@"SEL$1" "A"@"SEL$1") LEADING(@"SEL$1" "B"@"SEL$1" "A"@"SEL$1") USE_MERGE(@"SEL$1" "A"@"SEL$1") PQ_FILTER(@"SEL$1" SERIAL) INDEX(@"SEL$2" "A"@"SEL$2" ("ILM_EXECUTION$"."EXECUTION_ID")) FULL(@"SEL$2" "B"@"SEL$2") LEADING(@"SEL$2" "A"@"SEL$2" "B"@"SEL$2") USE_MERGE(@"SEL$2" "B"@"SEL$2") USE_HASH_AGGREGATION(@"SEL$2") END_OUTLINE_DATA */

表示された内容に、身に覚え、
いや、見覚えのある方も多いことと思います :) あれでね。そう、あれです。
マニュアルに記載されいないパラメータを利用しなくても取り出せるんです。

ついでなので、マニュアルに記載のないパラメータを使ったDBMS_XPLAN.DISPLAY_AWRで同じ情報をリストしてみました。DBMS_XPLAN.DISPLAY_AWR以外のDISPLAY*関数のformatパラメータでもできます:)
（注：　DISPLAY_AWRでAWRを参照するのでOracle Diagnostics Packが必要でっす。ですが、DISPLAY_CURSOR(),DISPLAY()とDISPLAY_PLAN()ならAWRは参照しないのでオプションはいらないですよね。）

PROMPT PROMPT ****** display_awr with outline option ********* SELECT plan_table_output as outline FROM TABLE(DBMS_XPLAN.DISPLAY_AWR(sql_id=>'&1',plan_hash_value=>&2,format=>'OUTLINE')) / ****** DBMS_XPLAN.DISPLAY_AWR with OUTLINE option ******* OUTLINE ------------------------------------------------------------------------------------------ SQL_ID gdtyuqcyk8x1c -------------------- SELECT B.EXECUTION_ID, NVL(A.N_COUNT,0), A.COMP_TIME FROM ( SELECT A.EXECUTION_ID, COUNT(*) N_COUNT, NVL(MAX(B.COMPLETION_TIME), SYSDATE) COMP_TIME FROM SYS.ILM_EXECUTION$ A, SYS.ILM_RESULTS$ B WHERE EXECUTION_STATE = :B7 AND A.EXECUTION_ID = B.EXECUTION_ID AND B.JOB_STATUS NOT IN (:B6 , :B5 , :B4 , :B3 , :B2 , :B1 ) GROUP BY A.EXECUTION_ID )A, ILM_EXECUTION$ B WHERE B.EXECUTION_ID = A.EXECUTION_ID (+) AND EXECUTION_STATE = :B7 AND (ROWNUM <= :B9 OR :B9 = :B8 ) Plan hash value: 2236229349 ----------------------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ----------------------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | | | 4 (100)| | | 1 | COUNT | | | | | | | 2 | FILTER | | | | | | | 3 | MERGE JOIN OUTER | | 1 | 65 | 4 (50)| 00:00:01 | | 4 | TABLE ACCESS BY INDEX ROWID | ILM_EXECUTION$ | 1 | 26 | 0 (0)| | | 5 | INDEX FULL SCAN | PK_TASKID | 1 | | 0 (0)| | | 6 | SORT JOIN | | 1 | 39 | 4 (50)| 00:00:01 | | 7 | VIEW | | 1 | 39 | 3 (34)| 00:00:01 | | 8 | HASH GROUP BY | | 1 | 65 | 3 (34)| 00:00:01 | | 9 | MERGE JOIN | | 1 | 65 | 3 (34)| 00:00:01 | | 10 | TABLE ACCESS BY INDEX ROWID| ILM_EXECUTION$ | 1 | 26 | 0 (0)| | | 11 | INDEX FULL SCAN | PK_TASKID | 1 | | 0 (0)| | | 12 | SORT JOIN | | 1 | 39 | 3 (34)| 00:00:01 | | 13 | TABLE ACCESS FULL | ILM_RESULTS$ | 1 | 39 | 2 (0)| 00:00:01 | ----------------------------------------------------------------------------------------------------- Outline Data ------------- /*+ BEGIN_OUTLINE_DATA IGNORE_OPTIM_EMBEDDED_HINTS OPTIMIZER_FEATURES_ENABLE('12.1.0.2') DB_VERSION('12.1.0.2') ALL_ROWS OUTLINE_LEAF(@"SEL$2") OUTLINE_LEAF(@"SEL$1") INDEX(@"SEL$1" "B"@"SEL$1" ("ILM_EXECUTION$"."EXECUTION_ID")) NO_ACCESS(@"SEL$1" "A"@"SEL$1") LEADING(@"SEL$1" "B"@"SEL$1" "A"@"SEL$1") USE_MERGE(@"SEL$1" "A"@"SEL$1") PQ_FILTER(@"SEL$1" SERIAL) INDEX(@"SEL$2" "A"@"SEL$2" ("ILM_EXECUTION$"."EXECUTION_ID")) FULL(@"SEL$2" "B"@"SEL$2") LEADING(@"SEL$2" "A"@"SEL$2" "B"@"SEL$2") USE_MERGE(@"SEL$2" "B"@"SEL$2") USE_HASH_AGGREGATION(@"SEL$2") END_OUTLINE_DATA */

ちなみに、11g R2でも動作します！

どうでしたか？役に立たなかったですよね？
以上、OUTLINE HINTSより愛を込めてお送りしました!

参考：　(日本語で書かれたエントリーは見当たらない。初か、もしかして！w）

Oracle SQL Plan Stability
http://blog.tanelpoder.com/oracle/performance/sql/oracle-sql-plan-stability/

Plan stability in 10g - using existing cursors to create Stored Outlines and SQL profiles
http://oracle-randolf.blogspot.jp/2009/03/plan-stability-in-10g-using-existing.html

FORCE_MATCH for Stored Outlines and/or SQL Baselines????? – follow up
https://tonyhasler.wordpress.com/2011/12/

How to hint – 1
https://jonathanlewis.wordpress.com/2011/06/08/how-to-hint-1/

dbms_xplan(3)
https://jonathanlewis.wordpress.com/2008/03/06/dbms_xplan3/

追記：

extractValueはDeprecatedです :) Oracle XML DBの新機能 https://t.co/UoCcGh3Vdc
— Kazuhiro YOSHIKAWA (@yoshikaw) 2015, 12月 3

@yoshikawさんに指摘され、EXTRACTVALUE()が11.2で非推奨になっていたとことに気づく orz.

@yoshikawさん、指摘ありがとうございます。　

XMLTABLE().... COLUMNSを使えばEXTRACTVALUE()はいらなかった！！！！　ということでEXTRACTVALUEなし版も作りました！！

ただ、CON_IDも見ないとマルチテナントに対応できず、エラーになると気づいたが、
11gにも対応しようとすると、もう一工夫必要なことに気づき、再び、orz.
つづきは、...いずれ...

変更したSQL文は以下のとおり。

SYSTEM> !cat report_outline_hints.sql col outline for a200 set linesize 300 set pagesize 10000 set veri off SELECT '/*+' AS outline FROM dual UNION ALL SELECT ' '||'BEGIN_OUTLINE_DATA' FROM DUAL UNION ALL SELECT ' '||x.outline_hint FROM XMLTABLE( '/*/outline_data/hint/text()' PASSING( SELECT XMLTYPE(other_xml) FROM dba_hist_sql_plan WHERE other_xml IS NOT NULL AND sql_id = '&1' AND plan_hash_value = &2 ) COLUMNS outline_hint PATH '/text()' ) x UNION ALL SELECT ' '||'END_OUTLINE_DATA' FROM DUAL UNION ALL SELECT '*/' FROM DUAL /

SYSTEM> @report_outline_hints gdtyuqcyk8x1c 2236229349 OUTLINE -------------------------------------------------------------------------------- /*+ BEGIN_OUTLINE_DATA IGNORE_OPTIM_EMBEDDED_HINTS OPTIMIZER_FEATURES_ENABLE('12.1.0.2') DB_VERSION('12.1.0.2') ALL_ROWS OUTLINE_LEAF(@"SEL$2") OUTLINE_LEAF(@"SEL$1") INDEX(@"SEL$1" "B"@"SEL$1" ("ILM_EXECUTION$"."EXECUTION_ID")) NO_ACCESS(@"SEL$1" "A"@"SEL$1") LEADING(@"SEL$1" "B"@"SEL$1" "A"@"SEL$1") USE_MERGE(@"SEL$1" "A"@"SEL$1") PQ_FILTER(@"SEL$1" SERIAL) INDEX(@"SEL$2" "A"@"SEL$2" ("ILM_EXECUTION$"."EXECUTION_ID")) FULL(@"SEL$2" "B"@"SEL$2") LEADING(@"SEL$2" "A"@"SEL$2" "B"@"SEL$2") USE_MERGE(@"SEL$2" "B"@"SEL$2") USE_HASH_AGGREGATION(@"SEL$2") END_OUTLINE_DATA */

JPOUG Advent Calendar 2015、12/5は、Yohei Azekatsu さんです。どんな変態ネタが飛び出すのか、乞うご期待！！

投稿日時 2015年12月 4日 (金) 00時30分 XML, チューニング, FAQ, SQL, イベント, JPOUG, Advent Calendar | 固定リンク | 0 | コメント (0) | トラックバック (0)

2015年11月21日 (土)

WITH clause in-line PL/SQL functionって....

12cの新機能でオイタをしてみたw

with句に関数仕込んで内部でSQL文を実行してオイタしてみました。

実際にこのような使い方するんでしょうか？
これをやるなら素直にスカラー副問合せの方がいいと思うんですね.....
（スカラー副問合せのように使われたら、同じく12cの新機能、Scalar subquery unnestingもできなし。）

なんでこんな機能必要なんだろう?
どのような場面で、有効なんだろう？

今の所、使いどころが思い浮かばないので、誰か教えて〜〜〜〜〜！　
とモヤモヤしてたんですが、今日はお留守番で時間だけはあったので、ごにょごにょとw

SCOTT> set serveroutput on SCOTT> set feed off SCOTT> r 1 with 2 function hoge return varchar2 3 deterministic 4 as 5 begin 6 for rec in (select empno,ename from emp order by empno) loop 7 dbms_output.put_line('**** '||rec.empno||':'||rec.ename||' ****'); 8 end loop; 9 return null; 10 end; 11 select 12 hoge 13 from 14 dual 15 where 16* hoge is not null **** 7369:SMITH **** **** 7499:ALLEN **** **** 7521:WARD **** **** 7566:JONES **** **** 7654:MARTIN **** **** 7698:BLAKE **** **** 7782:CLARK **** **** 7839:KING **** **** 7844:TURNER **** **** 7900:JAMES **** **** 7902:FORD **** **** 7934:MILLER **** 経過: 00:00:00.01

こんなことをやられると....
実行計画には現れないしw　（ちなみにスカラー副問合せは実行計画を見ただけでわかりますです。はい）

ただのチューナーいじめじゃ >< w
SQLトレースなら補足できるけど、なんぎじゃのう。げほげほ

(WITH句のインラインPL/SQLファンクション（名称あってるのかな？）内部でSQL文は実行しない方がいいと思うけど。。。。？？？)

SCOTT> SCOTT> set autot trace exp stat SCOTT> r 1 with 2 function hoge return varchar2 3 deterministic 4 as 5 begin 6 for rec in (select empno,ename from emp order by empno) loop 7 dbms_output.put_line('**** '||rec.empno||':'||rec.ename||' ****'); 8 end loop; 9 return null; 10 end; 11 select 12 hoge 13 from 14 dual 15 where 16* hoge is not null **** 7369:SMITH **** **** 7499:ALLEN **** **** 7521:WARD **** **** 7566:JONES **** **** 7654:MARTIN **** **** 7698:BLAKE **** **** 7782:CLARK **** **** 7839:KING **** **** 7844:TURNER **** **** 7900:JAMES **** **** 7902:FORD **** **** 7934:MILLER **** 経過: 00:00:00.03 実行計画 ---------------------------------------------------------- Plan hash value: 4034615273 ----------------------------------------------------------------- | Id | Operation | Name | Rows | Cost (%CPU)| Time | ----------------------------------------------------------------- | 0 | SELECT STATEMENT | | 1 | 2 (0)| 00:00:01 | |* 1 | FILTER | | | | | | 2 | FAST DUAL | | 1 | 2 (0)| 00:00:01 | ----------------------------------------------------------------- Predicate Information (identified by operation id): --------------------------------------------------- 1 - filter("HOGE"() IS NOT NULL) 統計 ---------------------------------------------------------- 1 recursive calls 0 db block gets 2 consistent gets 0 physical reads 0 redo size 363 bytes sent via SQL*Net to client 541 bytes received via SQL*Net from client 1 SQL*Net roundtrips to/from client 0 sorts (memory) 0 sorts (disk) 0 rows processed

WITH句のインラインPL/SQLファンクション内でのSQL文の実行はダークサイドな香りしかしないので、使うならデータの加工等、計算中心目的かねぇ〜。とマニュアル読んでたら見つけたw
　
(マニュアルのサンプルも加工のみ！ )

SCOTT> r 1 with 2 function hoge(eno number) return varchar2 3 deterministic 4 as 5 begin 6 dbms_output.put_line('Called'); 7 return '**** '||eno||' ****'; 8 end; 9 select 10 hoge(empno) 11 from 12* emp HOGE(EMPNO) --------------------------------------------------------------------- **** 7369 **** **** 7499 **** **** 7521 **** **** 7566 **** **** 7654 **** **** 7698 **** **** 7782 **** **** 7839 **** **** 7844 **** **** 7900 **** **** 7902 **** **** 7934 **** Called Called Called Called Called Called Called Called Called Called Called Called 経過: 00:00:00.02

Database SQL Language Reference (12.1)
Database SQL Language Reference (12.1) - SELECT

みなさん、ダークサイドに落ちないように注意しましょうね！ :)

投稿日時 2015年11月21日 (土) 15時32分 PL/SQL, チューニング, SQL, Opera, Oracle Database 12c release 1 | 固定リンク | 0 | コメント (0) | トラックバック (0)

2015年6月24日 (水)

理論から学ぶデータベース実践入門 ~リレーショナルモデルによる効率的なSQL

久々に脳にイヤな感じの汗をかいたw

一度読んだだけでは理解できず、何度か繰り返し読み、自分なりに消化する必要のあるタイプの書籍だと思います。
（日々のトレーニング向けに一冊、みたいな）

話は変わりますが、

ワンスアポンナタイム。あるところで。
神チューナーのお一人と取り組んでいたプロジェクトで、イマイチな感じのSQLsを書いてる方々向けに神チューナーが、一言。

「ド・モルガンの法則により....」

彼の一言で、場がフリーズしたのを見てニヨニヨしていた私。
（それまで、B*Treeインデックスだの、Index only scanだの、駆動表だの言っていたのにいきなりですからね！w)

そんな一言を投げかけられてもフリーズしない基礎体力をつけるには、この手の書籍はピッタリじゃないかと思うわけです。はい。

投稿日時 2015年6月24日 (水) 22時06分日記・コラム・つぶやき, SQL, 書評, Index Only Scan | 固定リンク | 0 | コメント (0) | トラックバック (0)

2015年5月17日 (日)

Meetup! JPOUG @ Oracle CloudWorld 2015

意外に心？w　時間？　に余裕がないのですが、途切れ途切れでも更新していこうかなと50%いや、60%
ぐらい思ってます。

久々の投稿ですが、一ヶ月前のネタです m(_ _)m

Meetup! JPOUG 開催報告

ショートセッション

Oracle Data Guard による高可用性 / 宇佐美さん
Oracle Database In-Memory Advisorのリアルな話 / 関さん
SQLチューニング総合診療Oracle CloudWorld出張所 / 関口 Powerd by Mac De Oracle w
Zero Data Loss Recovery Appliance / 吉田さん

スペシャル企画　「な〜んでだ？」

なーんでだ？ Meetup! JPOUG @ 2015-04-10 Oracle CloudWorld / 渡部さん
Meetup! jpoug oracle cloud world – なーんでだ / 新久保さん
Oracle cloudworld な〜んでだ？#3　/ 関口 Powered by Mac De Oracle

ショートセッションのSQLチューニング総合診療Oracle CloudWorld出張所は、db tech showcase 2014 Tokyoの続編のようなw （ような、じゃなくて、続編ですね、キッパリ

いろいろな性能病は無駄な物理I/Oや論理I/Oを削減していくことが、治療の第一歩！。

SQLチューニング総合診療Oracle CloudWorld出張所 from Hiroshi Sekiguchi

な〜んでだ？ #3は、時間が押してしまい残り５分程度で駆け足で終わらせてしまったので、「な〜んでだ？」は？な雰囲気にできなかったのが心残りでした　(笑

AWRを眺めていると、あるような、ないような時間が見えたりしてモヤモヤすることもあると思うんですよね。
そんなときの参考にならないかな？　と思ったネタでした。

Oracle cloudworld な〜んでだ？#3 from Hiroshi Sekiguchi

Oracle Databaseが雲の向こうに行っちゃっても、人工知能型オプティマイザでも登場してこないかぎり、まだ、まだ、人間のサポートが必要だと思うんだよねw
いつまで必要なのかは、わからないけど。:)

賢い人工知能型オプティマイザがうまれたとして、各インスタンスごとに性格の違うオプティマイザが成長しちゃったら面白い世界になるかもしれない。
と妄想していると、眠れなくなるので、今日はこのへんで。

投稿日時 2015年5月17日 (日) 01時25分 Oracle, チューニング, SQL, パフォーマンス, Oracle Cloud World | 固定リンク | 0 | コメント (0) | トラックバック (0)

2015年1月 2日 (金)

机上SQLチューニング、クイズ！　駆動表（外部表）はどれだ！！！！（実解答編）

JPOUG Advent Calendar 2014 17日目のエントリーで公開したクイズを実解答編です。
実際にOracle Database 12c 12.1.0.2.0を使ってどの表を駆動表（外部表）にするか確認してみます。

予想はあたるか、外れるか...どのような結果が待っているのか..ワクワクします。 :-)
Oracle® Database SQLチューニング・ガイド 12cリリース1(12.1) B71277-02 - 7 結合

前回の予想も参考に....机上SQLチューニング、クイズ！　駆動表（外部表）はどれだ！！！！（予想解答編）

問題１
次に示すSQL文の駆動表（外部表）はどれでしょうか？　

表と索引 create table a1 ( id number primary key , data varchar2(1000) ) nologging / create table a2 ( id number primary key , data varchar2(1000) ) nologging / 統計情報 TABLE_NAME INDEX_NAME NUM_ROWS DISTINCT_KEYS CLUSTERING_FACTOR -------------- -------------- ---------- ------------- ----------------- A1 SYS_C0010377 10000 10000 295 A2 SYS_C0010378 2000 2000 59 SELECT /* SQL01 */ /*+ MONITOR USE_NL(a1 a2) */ * FROM a1 INNER JOIN a2 ON a1.id = a2.id WHERE a1.id BETWEEN 1 AND 100 /

私の答え(予想）
Nested Loop結合かつ、INNER JOINですから駆動表（外部表）はデータセットの小さい方。
(Nested Loop結合でOUTER JOINだと結合順は固定されるので駆動表は見つけやすいですが...INNER JOINの場合はそうはいかないですよね。ちなみに、最近のOracleだと、OUTER JOINでHash結合だと外部表を入れれかえて最適化するケースもあります。いずれどこかでそのネタをやると思います。）

ただ、結合条件キーはどちらも主キーですし、WHERE a1.id BETWEEN 1 AND 100は、a2表にも適用されることになるでしょうから、a1、a2どちらも最大で100行ヒットする可能性はあります。
どちらでも正解になる可能性はありますが...w （最初から引っ掛けかよw

細かい条件は提示していないので、提示した情報だけで机上で駆動表（外部表）を決めるとすれば、全体のサイズが小さい、a2でいいんじゃないでしょうか？（私ならそうします。机上ですから）
（当初、もう少し詳細な情報を提示しようとしていたのですが忘れてました...なのでa1だと思った方も可能性は五分五分ですね。前提条件不足でした。...ごめんなさい。ごめんなさい。）

Oracle Database 12c 12.1.0.2.0の動き
以下、SQLモニタリングレポートをみると、駆動表は、 a2表でした。　:)
ちなみに、a1を駆動表にした場合は、若干Buffer Getsが増加していました。誤差の範囲ですが...

SQL Monitoring Report Global Stats ======================================= | Elapsed | Other | Fetch | Buffer | | Time(s) | Waits(s) | Calls | Gets | ======================================= | 0.00 | 0.00 | 3 | 37 | ======================================= SQL Plan Monitoring Details (Plan Hash Value=3695212685) ===================================================================================================================================================== | Id | Operation | Name | Rows | Cost | Time | Start | Execs | Rows | Activity | Activity Detail | | | | | (Estim) | | Active(s) | Active | | (Actual) | (%) | (# samples) | ===================================================================================================================================================== | 0 | SELECT STATEMENT | | | | 1 | +0 | 1 | 20 | | | | 1 | NESTED LOOPS | | 20 | 23 | 1 | +0 | 1 | 20 | | | | 2 | NESTED LOOPS | | 20 | 23 | 1 | +0 | 1 | 20 | | | | 3 | TABLE ACCESS BY INDEX ROWID BATCHED | A2 | 20 | 3 | 1 | +0 | 1 | 20 | | | | 4 | INDEX RANGE SCAN | SYS_C0010378 | 20 | 2 | 1 | +0 | 1 | 20 | | | | 5 | INDEX UNIQUE SCAN | SYS_C0010377 | 1 | | 1 | +0 | 20 | 20 | | | | 6 | TABLE ACCESS BY INDEX ROWID | A1 | 1 | 1 | 1 | +0 | 20 | 20 | | | =====================================================================================================================================================

問題２
次に示すSQL文の駆動表（外部表）はどれでしょうか？　
(表と索引、および、統計情報は問題１と同じです。)

SELECT /* SQL02 */ /*+ MONITOR USE_HASH(a1 a2) */ * FROM a1 INNER JOIN a2 ON a1.id = a2.id /

私の答え(予想）
Hash結合でINNER JOINかつ、WHERE句はないのでこの問題は簡単ですよね!　（これは迷わないはず！！！）

Hash結合も外部表はデータセットの小さい方ですから...この場合だと、a2が外部表になるはず。

Oracle Database 12c 12.1.0.2.0の動き
以下、SQLモニタリングレポートから....外部表は、予想通りのa2。

SQL Monitoring Report Global Stats ================================================= | Elapsed | Cpu | Other | Fetch | Buffer | | Time(s) | Time(s) | Waits(s) | Calls | Gets | ================================================= | 0.01 | 0.01 | 0.00 | 135 | 497 | ================================================= SQL Plan Monitoring Details (Plan Hash Value=1713954154) ================================================================================================================================== | Id | Operation | Name | Rows | Cost | Time | Start | Execs | Rows | Mem | Activity | Activity Detail | | | | | (Estim) | | Active(s) | Active | | (Actual) | (Max) | (%) | (# samples) | ================================================================================================================================== | 0 | SELECT STATEMENT | | | | 1 | +0 | 1 | 2000 | | | | | 1 | HASH JOIN | | 2000 | 121 | 1 | +0 | 1 | 2000 | 1M | | | | 2 | TABLE ACCESS FULL | A2 | 2000 | 19 | 1 | +0 | 1 | 2000 | | | | | 3 | TABLE ACCESS FULL | A1 | 10000 | 102 | 1 | +0 | 1 | 10000 | | | | ==================================================================================================================================

問題３
次に示すSQL文の駆動表（外部表）はどれでしょうか？　
なお、D1とD2の多重度は、D1:D2 = 1:100
(個人的にUMLの多重度表記のほうが好きなので、UML表記の多重度で記述します。）

表と索引 create table d1 ( id number , data varchar2(1000) ) nologging / alter table d1 add constraint pk_d1 primary key (id) using index nologging / create table d2 ( id number not null , seq# number not null , data varchar2(1000) ) nologging / alter table d2 add constraint pk_d2 primary key (id, seq#) using index nologging / 統計情報 TABLE_NAME INDEX_NAME NUM_ROWS DISTINCT_KEYS CLUSTERING_FACTOR -------------- -------------- ---------- ------------- ----------------- D1 PK_D1 200 200 9 D2 PK_D2 20000 20000 870 SELECT /* SQL03 */ /*+ MONITOR */ * FROM d2 WHERE EXISTS ( SELECT 1 FROM d1 WHERE d1.id = d2.id AND d1.id IN (1,5) ) /

私の答え（予想）
これはちょっと意地悪な問題ですが、わかる人ならわかるはず。だと思って（信じて）作った問題です。 :)

最近のオプティマイザは、相関副問合せを可能であれば結合に書き換える（unnest）傾向が強いのをご存知でしょうか？　
となれば、方向はだいだい見えてきます。

d1.id IN (1,5)から最大で2件ヒットすると予想できますよね。
さらに、Nested Loop結合に書き換え、d2を内部表として結合できれば無駄がない。
つまり、駆動表は d1が理想的なはず。

d2を外部表にしてしまうと、WHERE条件がないので結合に置き換えてしまうとHash結合または、d2を全表走査して相関副問合せを都度実行のいづれかになってしまうでしょうね。(unnestの傾向が強いのでHash結合になる可能性が高そう）
ヒットするデータ件数から考えると、どちらも無駄なデータアクセスが多くなる可能性は高いのではないでしょうか。

Oracle Database 12c 12.1.0.2.0の動き
おおお〜。予想通り、相関副問合せは、unnestされて結合に書き換えられています。さらに 12cの新機能であるAdaptive Joinになっています。興味深い。

で本題である、外部表はどうなっているかというと....pk_d1をindex only scanしてNested Loop結合になっています。つまり、駆動表は、予想通り、d1になっています。Yahoo!
id=1でHash結合がありますが、試行はしたようですが、実際にはNested Loop結合だったようです。

SQL Monitoring Report Global Stats ======================================= | Elapsed | Other | Fetch | Buffer | | Time(s) | Waits(s) | Calls | Gets | ======================================= | 0.01 | 0.01 | 15 | 44 | ======================================= SQL Plan Monitoring Details (Plan Hash Value=804853015) ============================================================================================================================================== | Id | Operation | Name | Rows | Cost | Time | Start | Execs | Rows | Activity | Activity Detail | | | | | (Estim) | | Active(s) | Active | | (Actual) | (%) | (# samples) | ============================================================================================================================================== | 0 | SELECT STATEMENT | | | | 1 | +0 | 1 | 0 | | | | 1 | HASH JOIN | | 200 | 5 | 1 | +0 | 1 | 0 | | | | 2 | NESTED LOOPS | | 200 | 5 | 1 | +0 | 1 | 200 | | | | 3 | NESTED LOOPS | | 200 | 5 | 1 | +0 | 1 | 200 | | | | 4 | STATISTICS COLLECTOR | | | | 1 | +0 | 1 | 1 | | | | 5 | INLIST ITERATOR | | | | 1 | +0 | 1 | 2 | | | | 6 | INDEX UNIQUE SCAN | PK_D1 | 2 | 1 | 1 | +0 | 2 | 2 | | | | 7 | INDEX RANGE SCAN | PK_D2 | 1 | 1 | 1 | +0 | 2 | 200 | | | | 8 | TABLE ACCESS BY INDEX ROWID | D2 | 100 | 2 | 1 | +0 | 200 | 200 | | | | 9 | INLIST ITERATOR | | | | | | | | | | | 10 | TABLE ACCESS BY INDEX ROWID BATCHED | D2 | 100 | 2 | | | | | | | | 11 | INDEX RANGE SCAN | PK_D2 | 1 | 1 | | | | | | | ==============================================================================================================================================

問題４
次に示すSQL文の駆動表（外部表）はどれでしょうか？　
(表と索引、および、統計情報は問題３と同じです。)

SELECT /* SQL04 */ /*+ MONITOR */ * FROM d1 INNER JOIN d2 ON d1.id > d2.id AND d2.id BETWEEN 1 AND 5 AND d2.seq# BETWEEN 2 AND 4 /

私の答え（予想）
結合条件が ">"　であることに気付きましたか？ ;)

これは、Nested Loop結合にも、Hash結合にもなりません。 Merge(sort/merge)結合が選択されます。

内部表は索引が利用できないのでソートが発生します。（ソートは避けられない）
外部表では索引を利用してソート処理が回避可能であれば、回避する。

つまりソート処理の影響を最小にしようとするはず、なので...

d1:d2=1:100という比率からd2のソート処理を重いと判断し回避するために外部表にするだろうなぁ〜〜。
私は、d2が外部表になるだろうと予想しています。
（直積じゃないMerge結合なんて最近お目にかかったことないのですが...)

余談）
Hash結合のない時代のOracleで、Merge結合の実行計画を見せられて、なんでソートしてるんですかね〜と、某ベンダーの方に質問されて一瞬固まったことを思い出したw

Oracle Database 12c 12.1.0.2.0の動き
良かったw。　予想どおりソートを回避したようで、外部表は、 d2ですね。

SQL Monitoring Report Global Stats ================================================= | Elapsed | Cpu | Other | Fetch | Buffer | | Time(s) | Time(s) | Waits(s) | Calls | Gets | ================================================= | 0.02 | 0.01 | 0.01 | 198 | 48 | ================================================= SQL Plan Monitoring Details (Plan Hash Value=705618498) ============================================================================================================================================= | Id | Operation | Name | Rows | Cost | Time | Start | Execs | Rows | Mem | Activity | Activity Detail | | | | | (Estim) | | Active(s) | Active | | (Actual) | (Max) | (%) | (# samples) | ============================================================================================================================================= | 0 | SELECT STATEMENT | | | | 1 | +0 | 1 | 2955 | | | | | 1 | MERGE JOIN | | 3966 | 10 | 1 | +0 | 1 | 2955 | | | | | 2 | TABLE ACCESS BY INDEX ROWID | D2 | 20 | 4 | 1 | +0 | 1 | 15 | | | | | 3 | INDEX RANGE SCAN | PK_D2 | 20 | 3 | 1 | +0 | 1 | 15 | | | | | 4 | SORT JOIN | | 199 | 6 | 1 | +0 | 15 | 2955 | 145K | | | | 5 | TABLE ACCESS FULL | D1 | 199 | 5 | 1 | +0 | 1 | 199 | | | | =============================================================================================================================================

問題５
次に示すSQL文の駆動表（外部表）はどれでしょうか？　

表と索引定義 create table b1 ( id number , data varchar2(1000) ) nologging / alter table b1 add constraint pk_b1 primary key(id) using index nologging / create table b3 ( id number , seq# number , data varchar2(1000) ) nologging / alter table b3 add constraint pk_b3 primary key (id, seq#) using index nologging / create table b2 ( id number , seq# number , subseq# number , data varchar2(1000) ) nologging / alter table b2 add constraint pk_b2 primary key (id ,seq#, subseq#) using index nologging / 統計情報 TABLE_NAME INDEX_NAME NUM_ROWS DISTINCT_KEYS CLUSTERING_FACTOR -------------- -------------- ---------- ------------- ----------------- B1 PK_B1 20000 20000 870 B2 PK_B2 5000 5000 228 B3 PK_B3 500 500 23 ERDと多重度 b1 : b3 = 1 : 0..2 b3 : b2 = 1 : 0..10 (UML表記の多重度で記述しています。） SELECT /* SQL05 */ /*+ MONITOR USE_HASH(b1 b3 b2) */ * FROM b1 INNER JOIN b3 ON b1.id = b3.id INNER JOIN b2 ON b3.id = b2.id AND b3.seq# = b2.seq# /

私の答え（予想）
INNER JOINでHash結合かつ、WHERE句もないので簡単な問題ですよね。

外部表は、b3

ついでに、続けると、 b3とb2を結合すると最大で5000件、b3とb1を結合した場合、最大で500件なので、結合順として理想的なのは、 b3, b1, b2 ですよね。

Oracle Database 12c 12.1.0.2.0の動き
結果は、予想通りでした〜。これは簡単だから！。

SQL Monitoring Report Global Stats ================================================= | Elapsed | Cpu | Other | Fetch | Buffer | | Time(s) | Time(s) | Waits(s) | Calls | Gets | ================================================= | 0.06 | 0.04 | 0.02 | 335 | 1476 | ================================================= SQL Plan Monitoring Details (Plan Hash Value=3711653655) =================================================================================================================================== | Id | Operation | Name | Rows | Cost | Time | Start | Execs | Rows | Mem | Activity | Activity Detail | | | | | (Estim) | | Active(s) | Active | | (Actual) | (Max) | (%) | (# samples) | =================================================================================================================================== | 0 | SELECT STATEMENT | | | | 1 | +0 | 1 | 5000 | | | | | 1 | HASH JOIN | | 5000 | 315 | 1 | +0 | 1 | 5000 | 1M | | | | 2 | HASH JOIN | | 500 | 247 | 1 | +0 | 1 | 500 | 1M | | | | 3 | TABLE ACCESS FULL | B3 | 500 | 9 | 1 | +0 | 1 | 500 | | | | | 4 | TABLE ACCESS FULL | B1 | 20000 | 238 | 1 | +0 | 1 | 20000 | | | | | 5 | TABLE ACCESS FULL | B2 | 5000 | 68 | 1 | +0 | 1 | 5000 | | | | ===================================================================================================================================

問題６
次に示すSQL文の駆動表（外部表）はどれでしょうか？　
(表と索引、および、統計情報は問題５と同じです。)

SELECT /* SQL06 */ /*+ MONITOR USE_HASH(b1 b3 b2) */ * FROM b1 LEFT OUTER JOIN b3 ON b1.id = b3.id LEFT OUTER JOIN b2 ON b3.id = b2.id AND b3.seq# = b2.seq# /

私の答え（予想）
OUTER JOINなのですが、Hash結合なので、多分、予想通りにはならないだろうな〜〜と。

最近のオプティマイザは外部結合かつHash結合の場合、外部表と内部表をデータセットサイズに応じて入れ替える傾向が強いんですよね。PGAの使用サイズが小さくなるように....

とは言っても、机上の話なので、入れ替えないとしたらどうなるだろう..と、外部結合なので、内部表は、そのまま内部表として結合したほうがわかりやすいといえばわかりやすい。
（統計情報に乖離がある場合には入れ替えないほうが良い結果だったりすることもあります。）

注）()内を先に結合するものとします。
入れ替えなかった場合は、記述したままなので、(外部表、内部表)=外部表、内部表ということで、 (b1, b3), b2
データセットの小さい順に従えば、外部表と、内部表をいれかえて、b3, b1この結果セットの最大件数は元の外部表がb1ですから20,250件、b2が5,000件なので、また外部表と内部表を入れ替えて、結果として、b2, (b3, b1)ってことに...
(内部的に結合順が入れ替えられ、Right Joinに置き換えられることが多いんですよね〜いつ頃からだろう...10gあたりか。）

で、机上ならどちらを取るかということですが、机上では、ひとまず、SQL文の通りとしておくケースが多いです。あくまで私の場合ですよ。（難しいんですよ、これ。外れる可能性大w）
オプティマイザが内部的に外部表と内部表を入れ替えて問題がなければよし、問題があれば、内部的な入れ替えをヒントで止めるというのが私の基本方針なので、この辺りは、チューナーさんのさじ加減次第じゃないかなぁ、と思っています。

あはは、むずかし過ぎたか... 机上だと orz.

Oracle Database 12c 12.1.0.2.0の動き
結果を見てみると〜〜〜〜〜っ。恐れていたw 外部表と内部表の置き換え操作(LEFT OUTERがRIGHT OUTER）になってますね〜っ。あはは、見事に、外れました....orz.

SQL Monitoring Report Global Stats ================================================= | Elapsed | Cpu | Other | Fetch | Buffer | | Time(s) | Time(s) | Waits(s) | Calls | Gets | ================================================= | 0.34 | 0.21 | 0.13 | 1651 | 2648 | ================================================= SQL Plan Monitoring Details (Plan Hash Value=1453650298) ====================================================================================================================================== | 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 | 24750 | | | | | 1 | HASH JOIN RIGHT OUTER | | 203K | 316 | 4 | +0 | 1 | 24750 | 3M | | | | 2 | TABLE ACCESS FULL | B2 | 5000 | 68 | 1 | +0 | 1 | 5000 | | | | | 3 | HASH JOIN RIGHT OUTER | | 20250 | 247 | 4 | +0 | 1 | 20250 | 1M | | | | 4 | TABLE ACCESS FULL | B3 | 500 | 9 | 1 | +0 | 1 | 500 | | | | | 5 | TABLE ACCESS FULL | B1 | 20000 | 238 | 4 | +0 | 1 | 20000 | | | | ======================================================================================================================================

問題ごとの解説をおまけで何回かに分けて、書いた方が良さそうだなw

ということで、おまけエントリーを書くかも...し、れ、な、い。

・机上SQLチューニング、クイズ！　駆動表（外部表）はどれだ！！！！
・机上SQLチューニング、クイズ！　駆動表（外部表）はどれだ！！！！（予想解答編）

投稿日時 2015年1月 2日 (金) 10時38分 Oracle, チューニング, SQL, Oracle Database 12c release 1, パフォーマンス, Index Only Scan | 固定リンク | 0 | コメント (1) | トラックバック (0)

2015年1月 1日 (木)

机上SQLチューニング、クイズ！　駆動表（外部表）はどれだ！！！！（予想解答編）

JPOUG Advent Calendar 2014 17日目のエントリーで公開したクイズの予想解答編です。
机上ですし、限られた情報しか提示していないので、実際にやってみたら違う...ということも十分ありえます。 (^^;;;;

外部表はどれがいいか予想できると、いろいろな制限のあるチューニング現場では役立つこともあるんです。LEADINGヒント等で結合順を考える場合にも役立ちますyo!
机上の予想なので間違うこともあります。オプティマイザも統計情報から予想しているわけで(Adaptiveな機能を除く）ハズすことも多いですから... (^^

Oracle® Database SQLチューニング・ガイド 12cリリース1(12.1) B71277-02 - 7 結合

問題１
次に示すSQL文の駆動表（外部表）はどれでしょうか？　

表と索引 create table a1 ( id number primary key , data varchar2(1000) ) nologging / create table a2 ( id number primary key , data varchar2(1000) ) nologging / 統計情報 TABLE_NAME INDEX_NAME NUM_ROWS DISTINCT_KEYS CLUSTERING_FACTOR -------------- -------------- ---------- ------------- ----------------- A1 SYS_C0010377 10000 10000 295 A2 SYS_C0010378 2000 2000 59 SELECT /* SQL01 */ /*+ MONITOR USE_NL(a1 a2) */ * FROM a1 INNER JOIN a2 ON a1.id = a2.id WHERE a1.id BETWEEN 1 AND 100 /

私の答え(予想）
Nested Loop結合かつ、INNER JOINですから駆動表（外部表）はデータセットの小さい方。
(Nested Loop結合でOUTER JOINだと結合順は固定されるので駆動表は見つけやすいですが...INNER JOINの場合はそうはいかないですよね）

ただ、結合条件キーはどちらも主キーですし、WHERE a1.id BETWEEN 1 AND 100は、a2表にも適用されることになるでしょうから、a1、a2どちらも最大で100行ヒットする可能性はあります。
どちらでも正解になる可能性はありますが...w （最初から引っ掛けかよw

細かい条件は提示していないので、提示した情報だけで机上で駆動表（外部表）を決めるとすれば、全体のサイズが小さい、a2でいいんじゃないでしょうか？（私ならそうします。机上ですから）
（当初、もう少し詳細な情報を提示しようとしていたのですが忘れてました...なのでa1だと思った方も可能性は五分五分ですね。前提条件不足でした。...ごめんなさい。ごめんなさい。）

問題２
次に示すSQL文の駆動表（外部表）はどれでしょうか？　
(表と索引、および、統計情報は問題１と同じです。)

SELECT /* SQL02 */ /*+ MONITOR USE_HASH(a1 a2) */ * FROM a1 INNER JOIN a2 ON a1.id = a2.id /

私の答え(予想）
Hash結合でINNER JOINかつ、WHERE句はないのでこの問題は簡単ですよね!　（これは迷わないはず！！！）

Hash結合も外部表はデータセットの小さい方ですから...この場合だと、a2が外部表になるはず。

問題３
次に示すSQL文の駆動表（外部表）はどれでしょうか？　
なお、D1とD2の多重度は、D1:D2 = 1:100
(個人的にUMLの多重度表記のほうが好きなので、UML表記の多重度で記述します。）

表と索引 create table d1 ( id number , data varchar2(1000) ) nologging / alter table d1 add constraint pk_d1 primary key (id) using index nologging / create table d2 ( id number not null , seq# number not null , data varchar2(1000) ) nologging / alter table d2 add constraint pk_d2 primary key (id, seq#) using index nologging / 統計情報 TABLE_NAME INDEX_NAME NUM_ROWS DISTINCT_KEYS CLUSTERING_FACTOR -------------- -------------- ---------- ------------- ----------------- D1 PK_D1 200 200 9 D2 PK_D2 20000 20000 870 SELECT /* SQL03 */ /*+ MONITOR */ * FROM d2 WHERE EXISTS ( SELECT 1 FROM d1 WHERE d1.id = d2.id AND d1.id IN (1,5) ) /

私の答え（予想）
これはちょっと意地悪な問題ですが、わかる人ならわかるはず。だと思って（信じて）作った問題です。 :)

最近のオプティマイザは、相関副問合せを可能であれば結合に書き換える（unnest）傾向が強いのをご存知でしょうか？　
となれば、方向はだいだい見えてきます。

d1.id IN (1,5)から最大で2件ヒットすると予想できますよね。
さらに、Nested Loop結合に書き換え、d2を内部表として結合できれば無駄がない。
つまり、駆動表は d1が理想的なはず。

d2を外部表にしてしまうと、WHERE条件がないので結合に置き換えてしまうとHash結合または、d2を全表走査して相関副問合せを都度実行のいづれかになってしまうでしょうね。(unnestの傾向が強いのでHash結合になる可能性が高そう）
ヒットするデータ件数から考えると、どちらも無駄なデータアクセスが多くなる可能性は高いのではないでしょうか。

問題４
次に示すSQL文の駆動表（外部表）はどれでしょうか？　
(表と索引、および、統計情報は問題３と同じです。)

SELECT /* SQL04 */ /*+ MONITOR */ * FROM d1 INNER JOIN d2 ON d1.id > d2.id AND d2.id BETWEEN 1 AND 5 AND d2.seq# BETWEEN 2 AND 4 /

私の答え（予想）
結合条件が ">"　であることに気付きましたか？ ;)

これは、Nested Loop結合にも、Hash結合にもなりません。 Merge(sort/merge)結合が選択されます。

内部表は索引が利用できないのでソートが発生します。（ソートは避けられない）
外部表では索引を利用してソート処理が回避可能であれば、回避する。

つまりソート処理の影響を最小にしようとするはず、なので...

d1:d2=1:100という比率からd2のソート処理を重いと判断し回避するために外部表にするだろうなぁ〜〜。
私は、d2が外部表になるだろうと予想しています。
（直積じゃないMerge結合なんて最近お目にかかったことないのですが...)

余談）
Hash結合のない時代のOracleで、Merge結合の実行計画を見せられて、なんでソートしてるんですかね〜と、某ベンダーの方に質問されて一瞬固まったことを思い出したw

問題５
次に示すSQL文の駆動表（外部表）はどれでしょうか？　

表と索引定義 create table b1 ( id number , data varchar2(1000) ) nologging / alter table b1 add constraint pk_b1 primary key(id) using index nologging / create table b3 ( id number , seq# number , data varchar2(1000) ) nologging / alter table b3 add constraint pk_b3 primary key (id, seq#) using index nologging / create table b2 ( id number , seq# number , subseq# number , data varchar2(1000) ) nologging / alter table b2 add constraint pk_b2 primary key (id ,seq#, subseq#) using index nologging / 統計情報 TABLE_NAME INDEX_NAME NUM_ROWS DISTINCT_KEYS CLUSTERING_FACTOR -------------- -------------- ---------- ------------- ----------------- B1 PK_B1 20000 20000 870 B2 PK_B2 5000 5000 228 B3 PK_B3 500 500 23 ERDと多重度 b1 : b3 = 1 : 0..2 b3 : b2 = 1 : 0..10 (UML表記の多重度で記述しています。） SELECT /* SQL05 */ /*+ MONITOR USE_HASH(b1 b3 b2) */ * FROM b1 INNER JOIN b3 ON b1.id = b3.id INNER JOIN b2 ON b3.id = b2.id AND b3.seq# = b2.seq# /

私の答え（予想）
INNER JOINでHash結合かつ、WHERE句もないので簡単な問題ですよね。

外部表は、b3

ついでに、続けると、 b3とb2を結合すると最大で5000件、b3とb1を結合した場合、最大で500件なので、結合順として理想的なのは、 b3, b1, b2 ですよね。

問題６
次に示すSQL文の駆動表（外部表）はどれでしょうか？　
(表と索引、および、統計情報は問題５と同じです。)

SELECT /* SQL06 */ /*+ MONITOR USE_HASH(b1 b3 b2) */ * FROM b1 LEFT OUTER JOIN b3 ON b1.id = b3.id LEFT OUTER JOIN b2 ON b3.id = b2.id AND b3.seq# = b2.seq# /

私の答え（予想）
OUTER JOINなのですが、Hash結合なので、多分、予想通りにはならないだろうな〜〜と。

最近のオプティマイザは外部結合かつHash結合の場合、外部表と内部表をデータセットサイズに応じて入れ替える傾向が強いんですよね。PGAの使用サイズが小さくなるように....

とは言っても、机上の話なので、入れ替えないとしたらどうなるだろう..と、外部結合なので、内部表は、そのまま内部表として結合したほうがわかりやすいといえばわかりやすい。
（統計情報に乖離がある場合には入れ替えないほうが良い結果だったりすることもあります。）

注）()内を先に結合するものとします。
入れ替えなかった場合は、記述したままなので、(外部表、内部表)=外部表、内部表ということで、 (b1, b3), b2
データセットの小さい順に従えば、外部表と、内部表をいれかえて、b3, b1。
この結果セットの最大件数は元の外部表がb1ですから20,250件、b2が5,000件なので、また外部表と内部表を入れ替えて、結果として、b2, (b3, b1)ってことに...
(内部的に結合順が入れ替えられ、Right Joinに置き換えられることが多いんですよね〜いつ頃からだろう...10gあたりか。）

で、机上ならどちらを取るかということですが、机上では、ひとまず、SQL文の通りとしておくケースが多いです。あくまで私の場合ですよ。（難しいんですよ、これ。外れる可能性大w）
オプティマイザが内部的に外部表と内部表を入れ替えて問題がなければよし、問題があれば、内部的な入れ替えをヒントで止めるというのが私の基本方針なので、この辺りは、チューナーさんのさじ加減次第じゃないかなぁ、と思っています。

あはは、むずかし過ぎたか... 机上だと orz.

結合順がほぼ想定できる場合、状況次第で変わりそうな結合順、いろいろありますよね。
オプティマイザの気持ちになって考えてみると、いろいろ気づくことも多いんじゃないかなぁ。と思います。

オプティマイザってソートが嫌いなんだ〜、とか、PGA少ない方が好きなんだ〜とか....

役に立ったか、どうなのか不明なオチになりましたが.....

本年もよろしくお願いいたします。 m(_ _)m

あ、そうそう、一つ忘れてました。

次回は、Oracle Database 12c 12.1.0.2.0を使って試したオプティマイザが選択した駆動表（外部表）がどれだったかのか公開する予定です。

・机上SQLチューニング、クイズ！　駆動表（外部表）はどれだ！！！！

投稿日時 2015年1月 1日 (木) 00時01分チューニング, SQL, JPOUG, Oracle Database 12c release 1, パフォーマンス, Advent Calendar | 固定リンク | 0 | コメント (0) | トラックバック (0)

2014年12月17日 (水)

机上SQLチューニング、クイズ！　駆動表（外部表）はどれだ！！！！

予備プラン発動中 :)

ということで、諸事情により開け忘れた窓を開けるためJPOUG Advent Calendar 2014 ２回目の登場となりました。

JPOUG Advent Calendar 2014 17日目のエントリーです。

突然ですが、

「机上SQLチューーーーーニング、クイズ〜〜〜っ！！！！！！
　駆動表（外部表）はどれだ！！！！」

なお、このクイズには次の制限があります。

別途、本ブログで解答エントリーが公開（年明けを予定）されるまで、Oracle Databaseを利用して答え求めるのは禁止。 :-)
Oracle Databaseを利用せず、机上で、どの表を駆動表（外部表）にすれば理想的な実行計画になりそうか考えてみてね。

また、解答はOracle Database 12c Release 1 12.1.0.2.0 のオプティマイザをインストールしたまま（初期化パラメータはデフォルトのまま）の環境を使って行います。
（11gでも違わないと思いますが)

というクリスマスプレゼント :)

次に示されるSQL文の駆動表（外部表）はどれでしょうか？　

前提

統計情報と実データとの間に乖離はありません。
リテラル値で指定した検索条件に該当するデータは必ず存在します。

※引っ掛け問題もあるよ！　:)

問題１
次に示すSQL文の駆動表（外部表）はどれでしょうか？　

表と索引
create table a1 (
id number primary key
, data varchar2(1000)
) nologging
/
create table a2 (
id number primary key
, data varchar2(1000)
) nologging
/

統計情報
TABLE_NAME INDEX_NAME NUM_ROWS DISTINCT_KEYS CLUSTERING_FACTOR
-------------- -------------- ---------- ------------- -----------------
A1 SYS_C0010377 10000 10000 295
A2 SYS_C0010378 2000 2000 59

SELECT
/* SQL01 */
/*+
MONITOR
USE_NL(a1 a2)
*/
*
FROM
a1
INNER JOIN a2
ON
a1.id = a2.id
WHERE
a1.id BETWEEN 1 AND 100
/

問題２
次に示すSQL文の駆動表（外部表）はどれでしょうか？　
(表と索引、および、統計情報は問題１と同じです。)

SELECT
/* SQL02 */
/*+
MONITOR
USE_HASH(a1 a2)
*/
*
FROM
a1
INNER JOIN a2
ON
a1.id = a2.id
/

問題３
次に示すSQL文の駆動表（外部表）はどれでしょうか？　
なお、D1とD2の多重度は、D1:D2 = 1:100
(個人的にUMLの多重度表記のほうが好きなので、UML表記の多重度で記述します。）

表と索引
create table d1 (
id number
, data varchar2(1000)
) nologging
/
alter table d1 add constraint pk_d1 primary key (id) using index nologging
/
create table d2 (
id number not null
, seq# number not null
, data varchar2(1000)
) nologging
/
alter table d2 add constraint pk_d2 primary key (id, seq#) using index nologging
/

統計情報
TABLE_NAME INDEX_NAME NUM_ROWS DISTINCT_KEYS CLUSTERING_FACTOR
-------------- -------------- ---------- ------------- -----------------
D1 PK_D1 200 200 9
D2 PK_D2 20000 20000 870

SELECT
/* SQL03 */
/*+
MONITOR
*/
*
FROM
d2
WHERE
EXISTS (
SELECT
1
FROM
d1
WHERE
d1.id = d2.id
AND d1.id IN (1,5)
)
/

問題４
次に示すSQL文の駆動表（外部表）はどれでしょうか？　
(表と索引、および、統計情報は問題３と同じです。)

SELECT
/* SQL04 */
/*+
MONITOR
*/
*
FROM
d1
INNER JOIN d2
ON
d1.id > d2.id
AND d2.id BETWEEN 1 AND 5
AND d2.seq# BETWEEN 2 AND 4
/

問題５
次に示すSQL文の駆動表（外部表）はどれでしょうか？　

表と索引定義
create table b1 (
id number
, data varchar2(1000)
) nologging
/
alter table b1 add constraint pk_b1 primary key(id) using index nologging
/
create table b3 (
id number
, seq# number
, data varchar2(1000)
) nologging
/
alter table b3 add constraint pk_b3 primary key (id, seq#) using index nologging
/
create table b2 (
id number
, seq# number
, subseq# number
, data varchar2(1000)
) nologging
/
alter table b2 add constraint pk_b2 primary key (id ,seq#, subseq#) using index nologging
/

統計情報
TABLE_NAME INDEX_NAME NUM_ROWS DISTINCT_KEYS CLUSTERING_FACTOR
-------------- -------------- ---------- ------------- -----------------
B1 PK_B1 20000 20000 870
B2 PK_B2 5000 5000 228
B3 PK_B3 500 500 23

ERDと多重度
b1 : b3 = 1 : 0..2
b3 : b2 = 1 : 0..10
(UML表記の多重度で記述しています。）

SELECT
/* SQL05 */
/*+
MONITOR
USE_HASH(b1 b3 b2)
*/
*
FROM
b1
INNER JOIN b3
ON
b1.id = b3.id
INNER JOIN b2
ON
b3.id = b2.id
AND b3.seq# = b2.seq#
/

問題６
次に示すSQL文の駆動表（外部表）はどれでしょうか？　
(表と索引、および、統計情報は問題５と同じです。)

SELECT
/* SQL06 */
/*+
MONITOR
USE_HASH(b1 b3 b2)
*/
*
FROM
b1
LEFT OUTER JOIN b3
ON
b1.id = b3.id
LEFT OUTER JOIN b2
ON
b3.id = b2.id
AND b3.seq# = b2.seq#
/

冬休みの宿題〜〜〜〜っ。暇つぶしにトライしてみてくださいね。（ニヤニヤ　

解答エントリーの公開は年明けを予定していま〜す。

We wish your merry christmas and a happy new year!

次の扉は、Tamie Yamamotoさんです。

投稿日時 2014年12月17日 (水) 00時10分チューニング, SQL, Opera, JPOUG, Oracle Database 12c release 1, Advent Calendar | 固定リンク | 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年7月30日 (水)

Oracle Database 12c R1 12.1.0.2.0 In-memory option　はじめの一歩。

こまけーことは置いといて、
Oracle Database 12c R1 12.1.0.2.0 In-memory optionが利用できるようになったので簡単に試してみた。

環境は以下の通り

Oracle VM VirtualBox 4.3.12 for OS X
Oracle Linux 6.4
Oracle Database 12c EE 12.1.0.2.0 for Linux x86-64

時間が無かったので、マニュアルを斜め読みしつつ、とにかくインストール....
inmemory系初期化パラメータの確認。　(12.1.0.1と12.1.0.2の初期化パラメータの差分確認はあとで：TODO)

inmemory_sizeパラメータが0なのでin-memory column storeは機能しない状態がデフォルトなのか..

Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production
With the Partitioning, OLAP, Advanced Analytics and Real Application Testing options
に接続されました。
SYS>
SYS> show parameter inmemory

NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
inmemory_clause_default string
inmemory_force string DEFAULT
inmemory_max_populate_servers integer 0
inmemory_query string ENABLE
inmemory_size big integer 0
inmemory_trickle_repopulate_servers_ integer 1
percent
optimizer_inmemory_aware boolean TRUE
SYS>

以下の表を作成してあります。 10万行のうちb='1'である行は10行だけにしてあります。

SCOTT> desc foobar
名前 NULL? 型
----------------------------------------- -------- ----------------------------
A NUMBER
B CHAR(1)

SCOTT> select count(1) from foobar;

COUNT(1)
----------
100000

今まで通りに表を作成すると、in-memory column storeはdisabledで作成されるのか! ふむふむ。

SCOTT> select table_name,inmemory from user_tables where table_name='FOOBAR';

TABLE_NAME INMEMORY
------------------------------ --------
FOOBAR DISABLED

索引は作成していないので以下のようなクエリを実行すれば、TABLE ACCESS FULLですよね。

SCOTT> select /*+ gather_plan_statistics */ count(1) from foobar where b = '1';

COUNT(1)
----------
10

SCOTT> @show_actual_plan

PLAN_TABLE_OUTPUT
------------------------------------------------------------------------------------------
SQL_ID 4zurd70pg2qna, child number 0
-------------------------------------
select /*+ gather_plan_statistics */ count(1) from foobar where b = '1'

Plan hash value: 2479556450

---------------------------------------------------------------------------------------
| Id | Operation | Name | Starts | E-Rows | A-Rows | A-Time | Buffers |
---------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | | 1 |00:00:00.01 | 191 |
| 1 | SORT AGGREGATE | | 1 | 1 | 1 |00:00:00.01 | 191 |
|* 2 | TABLE ACCESS FULL| FOOBAR | 1 | 15 | 10 |00:00:00.01 | 191 |
---------------------------------------------------------------------------------------

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

2 - filter("B"='1')

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

23行が選択されました。

in-memory column storeを利用するための準備〜〜〜。
alter table文でin-memory column storeを有効化。（簡単だな！）

SCOTT> alter table foobar inmemory;

表が変更されました。

おっと、忘れてました、 inmemory_sizeパラメータを設定しないといけないんだった...

ちなみに、inmemory_sizeパラメータは静的パラメータなので、scope=spfileを付けることをお忘れなく...

SYS> alter system set inmemory_size = 10m;
alter system set inmemory_size = 10m
*
行1でエラーが発生しました。:
ORA-02097: 指定した値が無効なので、パラメータを変更できません。 ORA-02095:
指定した初期化パラメータを変更できません。

メモリ関係のパラメータ変えて起動しなくなるって過去やらかしたことがあるので、手が勝ってに動くw

SYS> create pfile from spfile;

ファイルが作成されました。

変更できたました。
SYS> alter system set inmemory_size = 10m scope=spfile;

システムが変更されました。

SYS>

....中略....

起動してみましょう！　あらららら。

SYS> startup
ORA-64353: in-memory area size cannot be less than 100MB

ううううう、なんということでしょう！ w このパラメータ間違うと起動しないのな!!!!! 注意しないと。＞　俺

in-memory初期化パラメータは 100MB以上に設定しましょうね。マニュアルにも書いてますから。（読みましょうね。 (^^;;;;

気を取り直して、再チャレンジ :)

[oracle@emperor ˜]$ sqlplus / as sysdba

SQL*Plus: Release 12.1.0.2.0 Production on 火 7月 29 06:34:46 2014

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

アイドル・インスタンスに接続しました。

SYS> create spfile from pfile;

ファイルが作成されました。

SYS> startup
ORACLEインスタンスが起動しました。

Total System Global Area 3875536896 bytes
Fixed Size 3717856 bytes
Variable Size 2248148256 bytes
Database Buffers 1610612736 bytes
Redo Buffers 13058048 bytes
データベースがマウントされました。
データベースがオープンされました。

SYS> alter system set inmemory_size = 100m scope=spfile;

システムが変更されました。

SYS> shutdown
データベースがクローズされました。
データベースがディスマウントされました。
ORACLEインスタンスがシャットダウンされました。

SYS> startup
ORACLEインスタンスが起動しました。

Total System Global Area 3875536896 bytes
Fixed Size 3717856 bytes
Variable Size 2231371040 bytes
Database Buffers 1509949440 bytes
Redo Buffers 13058048 bytes
In-Memory Area 117440512 bytes
データベースがマウントされました。
データベースがオープンされました。
SYS>
SYS>

In-Memory Areaとリストされています。
うまくいったようなので in-memory column storeを試してみます！！！！

SCOTT> select /*+ gather_plan_statistics */ count(1) from foobar where b = '1';

COUNT(1)
----------
10

SCOTT>
SCOTT>
SCOTT> @show_actual_plan

PLAN_TABLE_OUTPUT
------------------------------------------------------------------------------------------------
SQL_ID 4zurd70pg2qna, child number 0
-------------------------------------
select /*+ gather_plan_statistics */ count(1) from foobar where b = '1'

Plan hash value: 2479556450

------------------------------------------------------------------------------------------------
| Id | Operation | Name | Starts | E-Rows | A-Rows | A-Time | Buffers |
------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | | 1 |00:00:00.01 | 8 |
| 1 | SORT AGGREGATE | | 1 | 1 | 1 |00:00:00.01 | 8 |
|* 2 | TABLE ACCESS INMEMORY FULL| FOOBAR | 1 | 15 | 10 |00:00:00.01 | 8 |
------------------------------------------------------------------------------------------------

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

2 - inmemory("B"='1')
filter("B"='1')

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

24行が選択されました。

in-memory column storeを利用しない場合、Buffer Getsが191ありましたが、in-memory column storeを利用した場合、Buffer Getsが8と大幅に減少しています！！！。データにもよるだろうけど、このケースだと、4%程度になってますね。

KEEP乗せとか手動でやらなくて済むケースあるんだろうな〜と、遠くを眺めながら.......in-memory column store初めの一歩はここまで。

つづく。

投稿日時 2014年7月30日 (水) 07時47分 SQL, Oracle Database 12c release 1, in-memory | 固定リンク | 0 | コメント (0) | トラックバック (0)

2014年7月26日 (土)

TABLE ACCESS BY INDEX ROWID BATCHED (Oracle Database 12c R1) ってなに！　#3

つづきです。
バッファキャッシュにヒットした場合はとどうかというと、物理I/Oは発生しないので、そのまんまの結果ですよね。(^^;;;

call count cpu elapsed disk query current rows ------- ------ -------- ---------- ---------- ---------- ---------- ---------- Parse 1 0.00 0.00 0 0 0 0 Execute 1 0.00 0.00 0 0 0 0 Fetch 195 0.11 0.18 0 6287 0 2907 ------- ------ -------- ---------- ---------- ---------- ---------- ---------- total 197 0.11 0.18 0 6287 0 2907 Misses in library cache during parse: 1 Optimizer mode: ALL_ROWS Parsing user id: 110 (SCOTT) Number of plan statistics captured: 1 Rows (1st) Rows (avg) Rows (max) Row Source Operation ---------- ---------- ---------- --------------------------------------------------- 2907 2907 2907 NESTED LOOPS (cr=6287 pr=0 pw=0 time=206651 us) 2907 2907 2907 NESTED LOOPS (cr=3380 pr=0 pw=0 time=116870 us cost=5362 size=1744812 card=2851) 2907 2907 2907 TABLE ACCESS BY INDEX ROWID BATCHED HIGH_CLUSTERING_FACTOR (cr=3108 pr=0 pw=0 time=42395 us cost=2861 size=872406 card=2851) 2907 2907 2907 INDEX RANGE SCAN PK_HIGH_CLUSTERING_FACTOR (cr=201 pr=0 pw=0 time=12292 us cost=8 size=0 card=2851)(object id 93727) 2907 2907 2907 INDEX UNIQUE SCAN PK_LOW_CLUSTERING_FACTOR (cr=272 pr=0 pw=0 time=36902 us cost=0 size=0 card=1)(object id 93725) 2907 2907 2907 TABLE ACCESS BY INDEX ROWID LOW_CLUSTERING_FACTOR (cr=2907 pr=0 pw=0 time=37280 us cost=1 size=306 card=1) Rows Execution Plan ------- --------------------------------------------------- 0 SELECT STATEMENT MODE: ALL_ROWS 2907 NESTED LOOPS 2907 NESTED LOOPS 2907 TABLE ACCESS MODE: ANALYZED (BY INDEX ROWID BATCHED) OF 'HIGH_CLUSTERING_FACTOR' (TABLE) 2907 INDEX MODE: ANALYZED (RANGE SCAN) OF 'PK_HIGH_CLUSTERING_FACTOR' (INDEX (UNIQUE)) 2907 INDEX MODE: ANALYZED (UNIQUE SCAN) OF 'PK_LOW_CLUSTERING_FACTOR' (INDEX (UNIQUE)) 2907 TABLE ACCESS MODE: ANALYZED (BY INDEX ROWID) OF 'LOW_CLUSTERING_FACTOR' (TABLE) Elapsed times include waiting on following events: Event waited on Times Max. Wait Total Waited ---------------------------------------- Waited ---------- ------------ SQL*Net message to client 195 0.00 0.00 SQL*Net message from client 195 0.00 0.15 SQL*Net more data to client 193 0.00 0.01 ********************************************************************************

12cで、optimizer_features_enable='11.2.0.1'にしてバッファキャッシュをクリアすれば、11gと同じ実行計画(TABLE ACCESS BY INDEX ROWID)になって、db file parallel readになるよね！

という確認もしておいた！

call count cpu elapsed disk query current rows ------- ------ -------- ---------- ---------- ---------- ---------- ---------- Parse 1 0.42 1.59 0 0 0 0 Execute 1 0.00 0.01 0 0 0 0 Fetch 195 18.34 61.02 2450 6287 0 2907 ------- ------ -------- ---------- ---------- ---------- ---------- ---------- total 197 18.77 62.63 2450 6287 0 2907 Misses in library cache during parse: 1 Optimizer mode: ALL_ROWS Parsing user id: 110 (SCOTT) Number of plan statistics captured: 1 Rows (1st) Rows (avg) Rows (max) Row Source Operation ---------- ---------- ---------- --------------------------------------------------- 2907 2907 2907 NESTED LOOPS (cr=6287 pr=2450 pw=0 time=92881090 us) 2907 2907 2907 NESTED LOOPS (cr=3380 pr=2232 pw=0 time=59488238 us cost=5362 size=1744812 card=2851) 2907 2907 2907 TABLE ACCESS BY INDEX ROWID HIGH_CLUSTERING_FACTOR (cr=3108 pr=2221 pw=0 time=31142410 us cost=2861 size=872406 card=2851) 2907 2907 2907 INDEX RANGE SCAN PK_HIGH_CLUSTERING_FACTOR (cr=201 pr=7 pw=0 time=3493710 us cost=8 size=0 card=2851)(object id 93727) 2907 2907 2907 INDEX UNIQUE SCAN PK_LOW_CLUSTERING_FACTOR (cr=272 pr=11 pw=0 time=10377721 us cost=0 size=0 card=1)(object id 93725) 2907 2907 2907 TABLE ACCESS BY INDEX ROWID LOW_CLUSTERING_FACTOR (cr=2907 pr=218 pw=0 time=13380036 us cost=1 size=306 card=1) Rows Execution Plan ------- --------------------------------------------------- 0 SELECT STATEMENT MODE: ALL_ROWS 2907 NESTED LOOPS 2907 NESTED LOOPS 2907 TABLE ACCESS MODE: ANALYZED (BY INDEX ROWID BATCHED) OF 'HIGH_CLUSTERING_FACTOR' (TABLE) 2907 INDEX MODE: ANALYZED (RANGE SCAN) OF 'PK_HIGH_CLUSTERING_FACTOR' (INDEX (UNIQUE)) 2907 INDEX MODE: ANALYZED (UNIQUE SCAN) OF 'PK_LOW_CLUSTERING_FACTOR' (INDEX (UNIQUE)) 2907 TABLE ACCESS MODE: ANALYZED (BY INDEX ROWID) OF 'LOW_CLUSTERING_FACTOR' (TABLE) Elapsed times include waiting on following events: Event waited on Times Max. Wait Total Waited ---------------------------------------- Waited ---------- ------------ SQL*Net message to client 195 0.00 0.21 Disk file operations I/O 1 0.00 0.00 db file sequential read 452 0.21 1.54 SQL*Net message from client 195 15.35 16.71 SQL*Net more data to client 193 0.00 0.47 db file parallel read 190 0.05 5.91 ********************************************************************************

整形前SQLトレースより抜粋 (db file parallel readが索引で現れている

WAIT #140513423347200: nam='db file parallel read' ela= 16615 files=1 blocks=13 requests=13 obj#=93726 tim=6258017207

straceより抜粋...io_submit()、だよね〜。:)

io_submit(140513465466880, 13, ...中略... ) = 13

最後に、11g R2 11.2.0.1で同じことを確認（確認するまでもないんだけどね）

call count cpu elapsed disk query current rows ------- ------ -------- ---------- ---------- ---------- ---------- ---------- Parse 1 0.00 0.00 0 0 0 0 Execute 1 0.00 0.00 0 0 0 0 Fetch 169 0.58 6.88 2148 5439 0 2509 ------- ------ -------- ---------- ---------- ---------- ---------- ---------- total 171 0.58 6.88 2148 5439 0 2509 Misses in library cache during parse: 0 Optimizer mode: ALL_ROWS Parsing user id: 84 (SCOTT) Rows Row Source Operation ------- --------------------------------------------------- 2509 NESTED LOOPS (cr=5439 pr=2148 pw=0 time=19292592 us) 2509 NESTED LOOPS (cr=2930 pr=1931 pw=0 time=24524478 us cost=5012 size=1530612 card=2501) 2509 TABLE ACCESS BY INDEX ROWID HIGH_CLUSTERING_FACTOR (cr=2683 pr=1922 pw=0 time=24392808 us cost=2510 size=765612 card=2502) 2509 INDEX RANGE SCAN PK_HIGH_CLUSTERING_FACTOR (cr=174 pr=5 pw=0 time=11616 us cost=8 size=0 card=2502)(object id 113222) 2509 INDEX UNIQUE SCAN PK_LOW_CLUSTERING_FACTOR (cr=247 pr=9 pw=0 time=0 us cost=0 size=0 card=1)(object id 113220) 2509 TABLE ACCESS BY INDEX ROWID LOW_CLUSTERING_FACTOR (cr=2509 pr=217 pw=0 time=0 us cost=1 size=306 card=1) Rows Execution Plan ------- --------------------------------------------------- 0 SELECT STATEMENT MODE: ALL_ROWS 2509 NESTED LOOPS 2509 NESTED LOOPS 2509 TABLE ACCESS MODE: ANALYZED (BY INDEX ROWID) OF 'HIGH_CLUSTERING_FACTOR' (TABLE) 2509 INDEX MODE: ANALYZED (RANGE SCAN) OF 'PK_HIGH_CLUSTERING_FACTOR' (INDEX (UNIQUE)) 2509 INDEX MODE: ANALYZED (UNIQUE SCAN) OF 'PK_LOW_CLUSTERING_FACTOR' (INDEX (UNIQUE)) 2509 TABLE ACCESS MODE: ANALYZED (BY INDEX ROWID) OF 'LOW_CLUSTERING_FACTOR' (TABLE) Elapsed times include waiting on following events: Event waited on Times Max. Wait Total Waited ---------------------------------------- Waited ---------- ------------ SQL*Net message to client 169 0.00 0.00 SQL*Net message from client 169 24.57 25.54 Disk file operations I/O 1 0.00 0.00 db file parallel read 167 0.09 5.66 db file sequential read 357 0.01 0.92 SQL*Net more data to client 167 0.00 0.01 ********************************************************************************

11gまでは、実行計画上には現れず実行時に内部的に行っていたI/O最適化の動きが、12cからは実行計画上でも確認できるようになったというのは分かり易くていい。
時間あったら、v$sesstatも載せるかも。 :)

さて、12c 12.1.0.2.0のダウンロードも終わったので、別の楽しみが増えましたよね、みなさん！

ダウンロード！　しましたか〜〜〜〜〜っ！　:)

みなさんの、12c ネタ祭りを楽しみにしております。 (^^

・TABLE ACCESS BY INDEX ROWID BATCHED (Oracle Database 12c R1) ってなに！　#1
・TABLE ACCESS BY INDEX ROWID BATCHED (Oracle Database 12c R1) ってなに！　#2

投稿日時 2014年7月26日 (土) 06時09分チューニング, SQL, Oracle Database 12c release 1, パフォーマンス | 固定リンク | 0 | コメント (0) | トラックバック (0)

2014年7月25日 (金)

TABLE ACCESS BY INDEX ROWID BATCHED (Oracle Database 12c R1) ってなに！　#2

Oracle Database 12c R1 12.1.0.2.0 EEが公開されましたが、12.1.0.1.0で試してあります。

注）バッファキャッシュをクリア後にSQL文を実行してあります。

SELECT /*+ leading(t2 t1) use_nl(t2 t1) index(t2 pk_high_clustering_factor) */ t2.id ,t2.name ,t1.name FROM low_clustering_factor t1 INNER JOIN high_clustering_factor t2 ON t1.id = t2.id WHERE t2.id BETWEEN 30001 AND 35000

上記のSQL文でTABLE ACCESS BY INDEX ROWID BATCHED操作を行わせてみた。

以下、SQLトレースの結果です。予想通り db file parallel readが発生しています。
高いクラスタリングファクタを持つ索引をアクセス、不連続なROWDをかき集めかき集めたROWIDをある程度まとめて１度のI/Oリクエストでバッファキャッシュへ読み込む動作ですよね！

call count cpu elapsed disk query current rows ------- ------ -------- ---------- ---------- ---------- ---------- ---------- Parse 1 0.01 0.07 6 6 0 0 Execute 1 0.00 0.00 0 0 0 0 Fetch 195 0.48 4.92 2288 6338 0 2907 ------- ------ -------- ---------- ---------- ---------- ---------- ---------- total 197 0.50 4.99 2294 6344 0 2907 Misses in library cache during parse: 1 Optimizer mode: ALL_ROWS Parsing user id: 110 (SCOTT) Number of plan statistics captured: 1 Rows (1st) Rows (avg) Rows (max) Row Source Operation ---------- ---------- ---------- --------------------------------------------------- 2907 2907 2907 NESTED LOOPS (cr=6338 pr=2288 pw=0 time=2150320 us) 2907 2907 2907 NESTED LOOPS (cr=3431 pr=2087 pw=0 time=6036546 us cost=3368 size=1159620 card=3514) 2907 2907 2907 TABLE ACCESS BY INDEX ROWID BATCHED HIGH_CLUSTERING_FACTOR (cr=3107 pr=2082 pw=0 time=5948676 us cost=1012 size=579810 card=3514) 2907 2907 2907 INDEX RANGE SCAN PK_HIGH_CLUSTERING_FACTOR (cr=201 pr=0 pw=0 time=15435 us cost=11 size=0 card=3514)(object id 93727) 2907 2907 2907 INDEX UNIQUE SCAN PK_LOW_CLUSTERING_FACTOR (cr=324 pr=5 pw=0 time=56981 us cost=0 size=0 card=1)(object id 93725) 2907 2907 2907 TABLE ACCESS BY INDEX ROWID LOW_CLUSTERING_FACTOR (cr=2907 pr=201 pw=0 time=312848 us cost=1 size=165 card=1) Rows Execution Plan ------- --------------------------------------------------- 0 SELECT STATEMENT MODE: ALL_ROWS 2907 NESTED LOOPS 2907 NESTED LOOPS 2907 TABLE ACCESS (BY INDEX ROWID BATCHED) OF　'HIGH_CLUSTERING_FACTOR' (TABLE) 2907 INDEX (RANGE SCAN) OF 'PK_HIGH_CLUSTERING_FACTOR' (INDEX (UNIQUE)) 2907 INDEX (UNIQUE SCAN) OF 'PK_LOW_CLUSTERING_FACTOR' (INDEX (UNIQUE)) 2907 TABLE ACCESS (BY INDEX ROWID) OF 'LOW_CLUSTERING_FACTOR' (TABLE) Elapsed times include waiting on following events: Event waited on Times Max. Wait Total Waited ---------------------------------------- Waited ---------- ------------ SQL*Net message to client 195 0.00 0.00 db file sequential read 209 0.03 0.32 SQL*Net message from client 195 19.95 21.21 db file parallel read 194 0.09 4.33 SQL*Net more data to client 193 0.00 0.01 ********************************************************************************

SQLトレース（整形前）のトレースログより　: db file parallel read （この時は、最小 3blocks〜15blocksの範囲で行われていた。

WAIT #139657829206792: nam='db file parallel read' ela= 64710 files=1 blocks=12 requests=12 obj#=93726 tim=4037078687

ちなみにstraceでみるとio_submitが呼び出されていて11gの頃と変わりはなかった :)

つまり、実行計画上、db file parallel readやるからね！！　物理I/Oを行うときは！　という意思が明確に表示されるようになった。　
分かり易くなっていい!!!!
これだと物理I/Oがあれば、db file parallel readやってるな〜と実行計画を見ただけで想像できますな:)

・TABLE ACCESS BY INDEX ROWID BATCHED (Oracle Database 12c R1) ってなに！　#1

投稿日時 2014年7月25日 (金) 22時09分チューニング, SQL, Oracle Database 12c release 1, パフォーマンス | 固定リンク | 0 | コメント (0) | トラックバック (0)

2014年7月23日 (水)

TABLE ACCESS BY INDEX ROWID BATCHED (Oracle Database 12c R1) ってなに！　#1

Oracle® Database SQLチューニング・ガイド 12cリリース1(12.1) - ROWIDによる表アクセス: 例にも記載され、昨年試していたときにも現れていた、table access by index rowid batched という操作って、実際のところdb file parallel readをやるよ！　と実行計画に表すようになったということだよね！　それだけだよね。

ということを確認してみた。（TODOと書いてから１年経過してしまった orz )

詳細はあした以降に書きまする。 :)

投稿日時 2014年7月23日 (水) 22時14分チューニング, SQL, Oracle Database 12c release 1, パフォーマンス | 固定リンク | 0 | コメント (0) | トラックバック (0)

2014年6月28日 (土)

InterSystems Symposia 2014に行ってきた

db tech showcase 2014 Osakaより先だったのだけど...
InterSystems Symposia 2014に行ってきた。という話。

CachéはSQLでアクセスする必要はないのだけど、RDBMSからの乗り換え~~組でSQLから乗り換え~~コストの低減目的で導入されたインターフェースだというのは間違いなし、
昔からM言語をやってきた人達からすれば、SQLアクセスだと！　はぁ〜？　的な感じも無くはないし、おまけ的なイメージは強いんだろうな。
その分のオーバーヘッドもあるしな〜。　と思ってたのですが....

最近の動きを見ているとSQLアクセスにも本気なのかな。と思わせる様子があるんだよね。

Caché SQL 最新情報の資料P3部分でダイレクトアクセス(元からあるNoSQLな部分）とSQLアクセスのメリット、デメリットの解説やビットマップインデックスのメンテナンス機能。

Caché SQL 最新情報のセッション資料は上のリンクからダウンロードできますよ！

そして、 Push Subquery Conditions into UNION LegsなどのSQL実行計画最適化、OracleのUSE_CONCAT相当など多数のヒント、パラレルクエリなど"おまけのインターフェース"とは思えなくなってきた感がある。

ちなみに、Caché自体はスパース多次元配列なので行指向、列指向のようなことはないんだけど、列指向的な加工もできちゃうわけで、それはそれで面白いかなと、勝ってに妄想してみたりw

たまには、右脳を活性化しないとね、イメージ力大事 :)

投稿日時 2014年6月28日 (土) 12時56分 Oracle以外のデータベース, SQL, イベント | 固定リンク | 0 | コメント (0) | トラックバック (0)

2014年6月13日 (金)

SQL Developer 4の素敵なコマンドライン de SQL整形 :)

Version 4.0.1ではWindowsでも同じ問題がでていたようですね。以下OTNフォーラムにも投稿されていたようです。
OS X版 Version 4.0.1でも同じだったので不具合だったようです。
https://community.oracle.com/thread/3562219

Version 4.0.2がリリースされたので改善されたか確かめてみました。 OS X版のSQLDeveloper 4.0.2 で！

OTN-JPではまだ、4.0.1のようですが、USでは 4.0.2のようです。OTN-JPでもそのうち4.0.2になるのでしょうね :)
以下はUSへリンクです。
http://www.oracle.com/technetwork/developer-tools/sql-developer/downloads/index.html

OS X版のsdcliを実行するには実行権を付与する必要があります。sdcliは以下のパスにあります。かなり深いところにあります！
(OS X版は以下深いところにあるので、SQLDeveloperのアイコン上で右クリック＞コンテクストメニュー＞パッケージの内容を表示から辿ってパスを探してもいいですし、以下のパス直接コピペでも行けます。)

discus-mother:˜ oracle$ cd /Applications/SQLDeveloper.app/Contents/Resources/sqldeveloper/sqldeveloper/bin
discus-mother:bin oracle$ chmod +x sdcli
discus-mother:bin oracle$ ll
total 672
-rw-r--r--@ 1 oracle staff 49279 5 3 02:48 SQLDeveloperIcons.icns
-rw-r--r--@ 1 oracle staff 0 5 3 02:48 jdk.conf
-rw-r--r--@ 1 oracle staff 440 5 3 02:48 logging-debug.conf
-rw-r--r--@ 1 oracle staff 363 5 3 02:48 logging.conf
-rwxrwxr-x@ 1 oracle staff 586 5 3 02:50 sdcli
-rw-r--r--@ 1 oracle staff 99 5 3 02:50 sdcli-Darwin.conf
-rw-r--r--@ 1 oracle staff 446 5 3 02:50 sdcli.boot
-rw-r--r--@ 1 oracle staff 854 5 3 02:50 sdcli.conf
-rw-r--r--@ 1 oracle staff 71205 5 3 02:48 splash.gif
-rw-r--r--@ 1 oracle staff 71205 5 3 02:48 splash.png
-r-xr-xr-x@ 1 oracle staff 3220 5 3 02:48 sqldeveloper
-rw-r--r--@ 1 oracle staff 415 5 3 02:48 sqldeveloper-Darwin.conf
-rw-r--r--@ 1 oracle staff 661 5 3 02:48 sqldeveloper-debug.conf
-rw-r--r--@ 1 oracle staff 204 5 3 02:48 sqldeveloper-nondebug.conf
-rw-r--r--@ 1 oracle staff 445 5 3 02:48 sqldeveloper.bat
-rw-r--r--@ 1 oracle staff 340 5 3 02:48 sqldeveloper.boot
-rw-r--r--@ 1 oracle staff 1175 5 3 02:48 sqldeveloper.conf
-rw-r--r--@ 1 oracle staff 83456 5 3 02:48 sqldeveloper64W.exe
-rw-r--r--@ 1 oracle staff 131 5 3 02:54 version.properties
discus-mother:bin oracle$

パスは通っていないので設定する必要があります。

discus-mother:˜ oracle$ cat .bashrc
alias ll='ls -lv'

#for SQLDeveloper sdcli
export PATH=$PATH:/Applications/SQLDeveloper.app/Contents/Resources/sqldeveloper/sqldeveloper/bin

discus-mother:˜ oracle$

Version 4.0.1では以下の状況でExceptionが発生していましたが、Version 4.0.2では解決してます！！！　

discus-mother:˜ oracle$ sdcli

Oracle SQL Developer
Copyright (c) 1997, 2014, Oracle and/or its affiliates. All rights reserved.

使用可能な機能:
cart: データベース・カート・バッチ・タスク
dba: 基本バッチDBAタスク
format: SQL Format Task
migration: Database Migration Tasks
reports: 基本バッチ・レポート・タスク
unittest: ユニット・テスト・バッチ・タスク
discus-mother:˜ oracle$

ということで、
前から試したかった SQL文の整形機能。　GUIだとSQLワークシートでSQL文整形機能が提供されているためデータベースへ接続必要だったんですよね。
機能としては素敵だったのですが、データベース接続が行えない環境では使えない機能だったんですよ。
そんな環境で読むに耐えない巨大で未整形なSQL文を渡され涙目だった日々を思い出しますw

コマンドラインならデータベース接続不要なのがいいっす！

discus-mother:˜ oracle$ sdcli format

Oracle SQL Developer
Copyright (c) 1997, 2014, Oracle and/or its affiliates. All rights reserved.

format input=<入力ファイルまたはディレクトリ> output=<出力ファイルまたはディレクトリ>
成功しました。
discus-mother:˜ oracle$

以下のようなSQL文を整形してみます。

discus-mother:˜ oracle$ cat sample_unformated.sql
select a.id,a.name,b.location,b.phone_no from foo a innter join bar b on a.id = b.id order by a.name;

意外と地味な感じの処理終了メッセージですが、整形できたようです。整形結果を確認！

discus-mother:˜ oracle$ sdcli format input=sample_unformated.sql output=sample_formated.sql

Oracle SQL Developer
Copyright (c) 1997, 2014, Oracle and/or its affiliates. All rights reserved.

成功しました。
discus-mother:˜ oracle$

いいですね〜 :) 最後の改行がないのですは、ご愛嬌ということで.

discus-mother:˜ oracle$ cat sample_formated.sql
SELECT a.id,
a.name,
b.location,
b.phone_no
FROM foo a innter
JOIN bar b
ON a.id = b.id
ORDER BY a.name;discus-mother:˜ oracle$
discus-mother:˜ oracle$

では、超便利な一括整形のテスト。以下のような未整形なSQLファイルを含むディレクトリと整形後SQLファイルを格納するディレクトリを用意して....

discus-mother:˜ oracle$ mkdir unformated_sqls
discus-mother:˜ oracle$ mkdir formated_sqls
discus-mother:˜ oracle$ dir=unformated_sqls; for fname in `ls $dir`; do echo -e \\n\\nfile : $fname; cat $dir/$fname; done;

file : sample1.sql
select a.id,a.name,b.location,b.phone_no from foo a innter join bar b on a.id = b.id order by a.name;

file : sample2.sql
select a.id,a.name,b.location,b.phone_no from foo a innter join bar b on a.id = b.id order by a.name;

一括整形の場合はディレクトリ名のみ指定すればOK!
おおおおおおおおお〜〜〜〜、できた〜〜〜〜SQL文の一括整形！！！　　素敵！！

discus-mother:˜ oracle$ sdcli format input=unformated_sqls output=formated_sqls

Oracle SQL Developer
Copyright (c) 1997, 2014, Oracle and/or its affiliates. All rights reserved.

成功しました。

かくに〜〜〜〜〜ん！！

discus-mother:˜ oracle$ dir=formated_sqls; for fname in `ls $dir`; do echo -e \\n\\nfile : $fname; cat $dir/$fname; done;

file : sample1.sql
SELECT a.id,
a.name,
b.location,
b.phone_no
FROM foo a innter
JOIN bar b
ON a.id = b.id
ORDER BY a.name;

file : sample2.sql
SELECT a.id,
a.name,
b.location,
b.phone_no
FROM foo a innter
JOIN bar b
ON a.id = b.id
ORDER BY a.name;

Good job!!!!! SQL Developer Team!

投稿日時 2014年6月13日 (金) 06時32分 Mac, Oracle SQL Developer, FAQ, SQL | 固定リンク | 0 | コメント (0) | トラックバック (0)

2014年5月24日 (土)

シーケンスでパーティションだと〜っ! （Oracle Database 12c R1ではドキュメントに記載なし...だが...) - おまけ

シーケンスでパーティションだと〜っ! （Oracle Database 12c R1ではドキュメントに記載なし...だが...) を書いた後に、もしかして、パーティション表でIdentity columnを使うと勝ってにパーティショニングされたシーケンスが自動生成されたりしないのかな〜っ。

と思って念のために試してみた。

結果は見ての通り....

次のリリースではなにかあるのかもね....。

SCOTT@nonpdb12c> select * from v$version;

BANNER CON_ID
-------------------------------------------------------------------------------- ----------
Oracle Database 12c Enterprise Edition Release 12.1.0.1.0 - 64bit Production 0
PL/SQL Release 12.1.0.1.0 - Production 0
CORE 12.1.0.1.0 Production 0
TNS for Linux: Version 12.1.0.1.0 - Production 0
NLSRTL Version 12.1.0.1.0 - Production 0

以下のように、id列をIdentity columnにし、そのid列をパーティショニングキーにしたハッシュパーティション表を作成してみた。

SCOTT@nonpdb12c> r
1 select
2 identity_column
3 ,column_name
4 ,data_type
5 ,data_default
6 from
7 user_tab_columns
8 where
9 table_name = 'HASH_PART_TABLE_USING_ID_COL'
10* order by column_id

IDE COLUMN_NAME DATA_TYPE DATA_DEFAULT
--- ------------------------------ -------------------- ------------------------------
YES ID NUMBER "SCOTT"."ISEQ$$_93596".nextval
NO DATA VARCHAR2

SCOTT@nonpdb12c> r
1 select
2 table_name
3 ,partitioning_type
4 ,partition_count
5 ,partitioning_key_count
6 from
7 user_part_tables
8 where
9* table_name = 'HASH_PART_TABLE_USING_ID_COL'

TABLE_NAME PARTITION PARTITION_COUNT PARTITIONING_KEY_COUNT
------------------------------ --------- --------------- ----------------------
HASH_PART_TABLE_USING_ID_COL HASH 4 1

SCOTT@nonpdb12c> r
1 select
2 name
3 ,object_type
4 ,column_name
5 from
6 user_part_key_columns
7 where
8* name = 'HASH_PART_TABLE_USING_ID_COL'

NAME OBJEC COLUMN_NAME
------------------------------ ----- ------------------------------
HASH_PART_TABLE_USING_ID_COL TABLE ID

対応するシーケンスはどうかというと、PARTITION_COUNTはNULLのまま....ですね。あははは。

SCOTT@nonpdb12c> select * from user_sequences where sequence_name = 'ISEQ$$_93596';

SEQUENCE_NAME MIN_VALUE MAX_VALUE INCREMENT_BY C O CACHE_SIZE LAST_NUMBER PARTITION_COUNT S K
------------------------------ ---------- --------------------------------- ------------ - - ---------- ----------- --------------- - -
ISEQ$$_93596 1 9999999999999999999999999999 1 N N 20 1 N N

投稿日時 2014年5月24日 (土) 13時15分 Oracle, SQL, Oracle Database 12c release 1 | 固定リンク | 0 | コメント (0) | トラックバック (0)

2014年4月30日 (水)

シーケンスでパーティションだと〜っ! （Oracle Database 12c R1ではドキュメントに記載なし...だが...)

Identity Columnがどのシーケンスを利用しているかを確認するディクショナリビューを調べていて見つけた、シーケンスのパーティション化！
とはいっても現時点ではマニュアルには解説はないので使い方は不明なままですが、RACとかで便利な感じとか、単にパラレル処理でいい感じになるのかとか、いろいろ想像を巡らしております。はい。

SCOTT@nonpdb12c> break on table_name skip 1
SCOTT@nonpdb12c> select table_name,has_identity from user_tables where has_identity='YES';

TABLE_NAME HAS_IDENTITY
------------------------------ ------------
TABLE_FOOBAR_IDENTITY2 YES

TABLE_FOOBAR_IDENTITY YES

SCOTT@nonpdb12c> select * from user_tab_identity_cols;

TABLE_NAME COLUMN_NAM GENERATION IDENTITY_OPTIONS
------------------------------ ---------- ---------- --------------------------------------------------------------------------------------------------------------------------------------------
TABLE_FOOBAR_IDENTITY ID BY DEFAULT START WITH: 1, INCREMENT BY: 1, MAX_VALUE: 9999999999999999999999999999, MIN_VALUE: 1, CYCLE_FLAG: N, CACHE_SIZE: 20, ORDER_FLAG: N

TABLE_FOOBAR_IDENTITY2 ID ALWAYS START WITH: 1, INCREMENT BY: 1, MAX_VALUE: 9999999999999999999999999999, MIN_VALUE: 1, CYCLE_FLAG: N, CACHE_SIZE: 20, ORDER_FLAG: N

SCOTT@nonpdb12c> select table_name,column_name,data_default,identity_column from user_tab_columns where identity_column='YES';

TABLE_NAME COLUMN_NAM DATA_DEFAULT IDENTITY_COLUMN
------------------------------ ---------- -------------------------------------------------------------------------------- ---------------
TABLE_FOOBAR_IDENTITY ID "SCOTT"."ISEQ$$_93570".nextval YES

TABLE_FOOBAR_IDENTITY2 ID "SCOTT"."ISEQ$$_93589".nextval YES

SCOTT@nonpdb12c> select * from user_sequences;

SEQUENCE_NAME MIN_VALUE MAX_VALUE INCREMENT_BY C O CACHE_SIZE LAST_NUMBER PARTITION_COUNT S K
------------------------------ ---------- ---------- ------------ - - ---------- ----------- --------------- - -
ISEQ$$_93570 1 1.0000E+28 1 N N 20 101 N N
ISEQ$$_93589 1 1.0000E+28 1 N N 20 101 N N

ん？　PARTITION_COUNTだと？　シーケンスでパーティションだと〜〜〜〜〜っ！

Oracle Database 12c R1のマニュアルの構文解説にもまったく記載されていないが..........
Oracle® Database SQL言語リファレンス 12cリリース1 (12.1) CREATE SEQUENCE

SCOTT@nonpdb12c> create sequence p_seq start with 1 maxvalue 9999999 partition 4;

順序が作成されました。

おおおおおおおおおおおおおお〜〜〜できたw Partitioned Sequence!!!!!!

SCOTT@nonpdb12c> select * from user_sequences;

SEQUENCE_NAME MIN_VALUE MAX_VALUE INCREMENT_BY C O CACHE_SIZE LAST_NUMBER PARTITION_COUNT S K
------------------------------ ---------- ---------- ------------ - - ---------- ----------- --------------- - -
ISEQ$$_93570 1 1.0000E+28 1 N N 20 101 N N
ISEQ$$_93589 1 1.0000E+28 1 N N 20 101 N N
P_SEQ 1 9999999 1 N N 20 1 4 N N

RACで効果がありそうな機能だが....、そもそも、どう使うんだ、謎。

次のリリースではなにか使えるのか...現リリースでも裏で使われているのか......

参考
dbi services Blog:Oracle Partitioned Sequences - a future new feature in 12c?

投稿日時 2014年4月30日 (水) 00時05分 Oracle, SQL, Oracle Database 12c release 1 | 固定リンク | 0 | コメント (0) | トラックバック (0)

2014年4月29日 (火)

Oracle Database 12cで実装されたidentity columnのメモ

Oracle® Database SQL言語リファレンス 12cリリース1 (12.1) CREATE TABLE identity_clause

制限事項に、「CREATE TABLE AS SELECTを使用すると、列に対するIDのプロパティが継承されなくなります。」と記載されているのでかるく確認 :)

SCOTT@nonpdb12c> CREATE TABLE table_foobar_identity2
2 (
3 id NUMBER GENERATED ALWAYS AS IDENTITY PRIMARY KEY
4 ,data VARCHAR2(10)
5 );

表が作成されました。

SCOTT@nonpdb12c> create table table_foobar_identity2_tmp as select * from table_foobar_identity2;

表が作成されました。

SCOTT@nonpdb12c> break on table_name skip 1
SCOTT@nonpdb12c> select table_name,column_name,identity_column from user_tab_columns where table_name like 'TABLE_FOOBAR%' order by table_name,column_id;

TABLE_NAME COLUMN_NAME IDE
------------------------------ ------------------------------ ---
TABLE_FOOBAR_IDENTITY2 ID YES
DATA NO

TABLE_FOOBAR_IDENTITY2_TMP ID NO
DATA NO

CREATE TABLE AS SELECTで復籍してもidentity columnは継承されてない。ふむふむ。

同マニュアルの注意には、「ID列を作成するときには、パフォーマンスを向上するために、デフォルトの20よりも大きな値を使用してCACHE句を指定してください。」
とある.
シーケンスを利用しているので注意するところは一緒ということね。

SCOTT@nonpdb12c> select * from user_sequences;

SEQUENCE_NAME MIN_VALUE MAX_VALUE INCREMENT_BY C O CACHE_SIZE LAST_NUMBER PARTITION_COUNT S K
------------------------------ ---------- ---------- ------------ - - ---------- ----------- --------------- - -
ISEQ$$_93570 1 1.0000E+28 1 N N 20 1 N N

参考
ORACLE-BASE:Identity Columns in Oracle Database 12c Release 1 (12.1)
Inside Oracle – Julian Dyke:Oracle 12c New Feature – Identity Columns

投稿日時 2014年4月29日 (火) 10時46分 Oracle, FAQ, SQL, 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でのやり取りなど....

イケテナイとか、良いとか、自由に言えるのはユーザーだからこそだと思うんだ。
セールストークじゃない生の情報って大切だ。

ということで、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年7月 8日 (月)

rownum使って満足しちゃってると.....おまけのおまけ FETCH FIRST N ROWS ONLY編

Oracle Database 12c R1 12.1.0.1.0 がリリースされたので、自分用のメモとしても使うネタから :)

実行環境は　Oracle Database 12c R1 12.1.0.1.0 EE/Oracle Linux 6.4/VirtualBox for OS X
11g R2と同じデータをインポートし統計情報を再取得しています。

まず、rownum から！

おおおおお〜、　まあ想定通りではあるのですが、11gとは違う点が一つ。

TABLE ACCESS BY INDEX ROWID BATCHEDと見慣れないオペレーションが...興味深いですね。これ :)

別途調べるTODO :)

23:14:41 SCOTT@pdborcl> r
1 select /*+ leading(tc) use_nl(tc tb ta) */ *
2 from
3 tc join tb
4 on
5 tc.version = tb.version
6 and tc.branch# = tb.branch#
7 join ta
8 on
9 tb.version = ta.version
10 where
11 tc.version between 1 and 10
12* and rownum <= 1000

1000行が選択されました。

経過: 00:00:00.13

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

-------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
-------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1000 | 2952K| 4813 (1)| 00:00:01 |
|* 1 | COUNT STOPKEY | | | | | |
| 2 | NESTED LOOPS | | | | | |
| 3 | NESTED LOOPS | | 2002 | 5910K| 4813 (1)| 00:00:01 |
| 4 | NESTED LOOPS | | 4004 | 7894K| 2810 (1)| 00:00:01 |
| 5 | TABLE ACCESS BY INDEX ROWID BATCHED| TC | 4004 | 3953K| 585 (0)| 00:00:01 |
|* 6 | INDEX RANGE SCAN | PK_TC | | | 14 (0)| 00:00:01 |
| 7 | TABLE ACCESS BY INDEX ROWID | TB | 1 | 1008 | 1 (0)| 00:00:01 |
|* 8 | INDEX UNIQUE SCAN | PK_TB | 1 | | 0 (0)| 00:00:01 |
|* 9 | INDEX UNIQUE SCAN | PK_TA | 1 | | 0 (0)| 00:00:01 |
| 10 | TABLE ACCESS BY INDEX ROWID | TA | 1 | 1004 | 1 (0)| 00:00:01 |
-------------------------------------------------------------------------------------------------

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

1 - filter(ROWNUM<=1000)
6 - access("TC"."VERSION">=1 AND "TC"."VERSION"<=10)
8 - access("TC"."VERSION"="TB"."VERSION" AND "TC"."BRANCH#"="TB"."BRANCH#")
filter("TB"."VERSION"<=10 AND "TB"."VERSION">=1)
9 - access("TB"."VERSION"="TA"."VERSION")
filter("TA"."VERSION">=1 AND "TA"."VERSION"<=10)

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

次に、Oracle Database 12c R1 12.1.0.1.0 から実装された FETCH FIRST N ROWS ONLYとの比較

FETCH FIRST N ROWS ONLYを利用した場合TCを全表走査してしまったので、rownum利用時と同じオブジェクト参照させるためヒントでPK_TC索引を利用するようチューニングしてあります
ただ..なぜか、TABLE ACCESS BY INDEX ROWID BATCHEDではなくTABLE ACCESS BY INDEX ROWIDとなっています。

さらに不思議なことに、COSTが異常に跳ね上がっています。Rowsの見積もり件数で大きな差があることが影響しているように見えるんだが、なんでこんなに違うんだろう！
いろいろ試してみると、不思議なことがおきそうな気配w

Buffer Getsはほぼ同じなので、全表走査になりやすい？場合、索引が利用できそうなら使わせたほうがいいですな。多分。

23:12:22 SCOTT@pdborcl> r
1 select /*+ leading(tc) use_nl(tc tb ta) index(tc pk_tc) */ *
2 from
3 tc join tb
4 on
5 tc.version = tb.version
6 and tc.branch# = tb.branch#
7 join ta
8 on
9 tb.version = ta.version
10 where
11 tc.version between 1 and 10
12* fetch first 1000 rows only

1000行が選択されました。

経過: 00:00:00.13

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

------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 300K| 456M| 1141K (1)| 00:00:45 |
|* 1 | VIEW | | 300K| 456M| 1141K (1)| 00:00:45 |
|* 2 | WINDOW NOSORT STOPKEY | | 300K| 864M| 1141K (1)| 00:00:45 |
| 3 | NESTED LOOPS | | | | | |
| 4 | NESTED LOOPS | | 300K| 864M| 1141K (1)| 00:00:45 |
| 5 | NESTED LOOPS | | 600K| 1155M| 841K (1)| 00:00:33 |
| 6 | TABLE ACCESS BY INDEX ROWID| TC | 1200K| 1156M| 174K (1)| 00:00:07 |
|* 7 | INDEX RANGE SCAN | PK_TC | 1200K| | 3278 (1)| 00:00:01 |
| 8 | TABLE ACCESS BY INDEX ROWID| TB | 1 | 1008 | 1 (0)| 00:00:01 |
|* 9 | INDEX UNIQUE SCAN | PK_TB | 1 | | 0 (0)| 00:00:01 |
|* 10 | INDEX UNIQUE SCAN | PK_TA | 1 | | 0 (0)| 00:00:01 |
| 11 | TABLE ACCESS BY INDEX ROWID | TA | 1 | 1004 | 1 (0)| 00:00:01 |
------------------------------------------------------------------------------------------

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

1 - filter("from$_subquery$_006"."rowlimit_$$_rownumber"<=1000)
2 - filter(ROW_NUMBER() OVER ( ORDER BY NULL )<=1000)
7 - access("TC"."VERSION">=1 AND "TC"."VERSION"<=10)
9 - access("TC"."VERSION"="TB"."VERSION" AND "TC"."BRANCH#"="TB"."BRANCH#")
filter("TB"."VERSION"<=10 AND "TB"."VERSION">=1)
10 - access("TB"."VERSION"="TA"."VERSION")
filter("TA"."VERSION">=1 AND "TA"."VERSION"<=10)

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

FETCH FISRSTを利用すると、rownumとは異なり、内部でROW_NUMBER() OVER( OVER BY NULL) <= N
のような変換が発生するんですね！！！！　

rownumの弱点はどうなったか確認してみます。

12c でも rownum は rownumですね！　という確認から。

23:37:32 SCOTT@pdborcl> r
1 select /*+ leading(tc) use_nl(tc tb ta) */ *
2 from
3 tc join tb
4 on
5 tc.version = tb.version
6 and tc.branch# = tb.branch#
7 join ta
8 on
9 tb.version = ta.version
10 where
11 tc.version between 11 and 20
12* and rownum <= 1000

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

経過: 00:00:08.21

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

-------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
-------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1000 | 2952K| 37940 (1)| 00:00:02 |
|* 1 | COUNT STOPKEY | | | | | |
| 2 | NESTED LOOPS | | | | | |
| 3 | NESTED LOOPS | | 1101 | 3250K| 37940 (1)| 00:00:02 |
| 4 | NESTED LOOPS | | 22019 | 42M| 26928 (1)| 00:00:02 |
| 5 | TABLE ACCESS BY INDEX ROWID BATCHED| TC | 38230 | 36M| 5683 (1)| 00:00:01 |
|* 6 | INDEX RANGE SCAN | PK_TC | | | 109 (0)| 00:00:01 |
| 7 | TABLE ACCESS BY INDEX ROWID | TB | 1 | 1008 | 1 (0)| 00:00:01 |
|* 8 | INDEX UNIQUE SCAN | PK_TB | 1 | | 0 (0)| 00:00:01 |
|* 9 | INDEX UNIQUE SCAN | PK_TA | 1 | | 0 (0)| 00:00:01 |
| 10 | TABLE ACCESS BY INDEX ROWID | TA | 1 | 1004 | 1 (0)| 00:00:01 |
-------------------------------------------------------------------------------------------------

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

1 - filter(ROWNUM<=1000)
6 - access("TC"."VERSION">=11 AND "TC"."VERSION"<=20)
8 - access("TC"."VERSION"="TB"."VERSION" AND "TC"."BRANCH#"="TB"."BRANCH#")
filter("TB"."VERSION">=11 AND "TB"."VERSION"<=20)
9 - access("TB"."VERSION"="TA"."VERSION")
filter("TA"."VERSION">=11 AND "TA"."VERSION"<=20)

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

FETCH FIRST N ROWS ONLYでも弱点は同じです！

23:36:02 SCOTT@pdborcl> r
1 select /*+ leading(tc) use_nl(tc tb ta) index(tc pk_tc) */ *
2 from
3 tc join tb
4 on
5 tc.version = tb.version
6 and tc.branch# = tb.branch#
7 join ta
8 on
9 tb.version = ta.version
10 where
11 tc.version between 11 and 20
12* fetch first 1000 rows only

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

経過: 00:00:07.36

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

------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 29999 | 45M| 1141K (1)| 00:00:45 |
|* 1 | VIEW | | 29999 | 45M| 1141K (1)| 00:00:45 |
|* 2 | WINDOW NOSORT STOPKEY | | 29999 | 86M| 1141K (1)| 00:00:45 |
| 3 | NESTED LOOPS | | | | | |
| 4 | NESTED LOOPS | | 29999 | 86M| 1141K (1)| 00:00:45 |
| 5 | NESTED LOOPS | | 599K| 1155M| 841K (1)| 00:00:33 |
| 6 | TABLE ACCESS BY INDEX ROWID| TC | 1200K| 1156M| 174K (1)| 00:00:07 |
|* 7 | INDEX RANGE SCAN | PK_TC | 1200K| | 3278 (1)| 00:00:01 |
| 8 | TABLE ACCESS BY INDEX ROWID| TB | 1 | 1008 | 1 (0)| 00:00:01 |
|* 9 | INDEX UNIQUE SCAN | PK_TB | 1 | | 0 (0)| 00:00:01 |
|* 10 | INDEX UNIQUE SCAN | PK_TA | 1 | | 0 (0)| 00:00:01 |
| 11 | TABLE ACCESS BY INDEX ROWID | TA | 1 | 1004 | 1 (0)| 00:00:01 |
------------------------------------------------------------------------------------------

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

1 - filter("from$_subquery$_006"."rowlimit_$$_rownumber"<=1000)
2 - filter(ROW_NUMBER() OVER ( ORDER BY NULL )<=1000)
7 - access("TC"."VERSION">=11 AND "TC"."VERSION"<=20)
9 - access("TC"."VERSION"="TB"."VERSION" AND "TC"."BRANCH#"="TB"."BRANCH#")
filter("TB"."VERSION">=11 AND "TB"."VERSION"<=20)
10 - access("TB"."VERSION"="TA"."VERSION")
filter("TA"."VERSION">=11 AND "TA"."VERSION"<=20)

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

最後に、ハッシュ結合にした場合のrownum vs fetch first n rows onlyの比較

NL結合にすべきか、ハッシュ結合にすべきかどうかは、悩むんですよ。状況に合わせて使い分ける必要があるのは、11gでも12cでも同じだと思います。理由は前回のエントリを参照のこと。

rownumでハッシュ結合にした場合、11g R2では黙っていても索引を利用していたのですが、12c R1では全表走査になる傾向が見られます。
11gの実行計画と同じオブジェクトを参照するようにヒントでチューニングしてありますが、やはりここでもTABLE ACCESS BY INDEX ROWID BATCHEDが行われていますね。

実に興味深い。

23:46:06 SCOTT@pdborcl> r
1 select /*+ leading(tc) use_hash(tc tb ta) index(ta pk_ta) */ *
2 from
3 tc join tb
4 on
5 tc.version = tb.version
6 and tc.branch# = tb.branch#
7 join ta
8 on
9 tb.version = ta.version
10 where
11 tc.version between 1 and 10
12* and rownum <= 1000

1000行が選択されました。

経過: 00:00:34.63

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

--------------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time |
--------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1000 | 4923K| | 199K (1)| 00:00:08 |
|* 1 | COUNT STOPKEY | | | | | | |
|* 2 | HASH JOIN | | 2002 | 9857K| | 199K (1)| 00:00:08 |
| 3 | TABLE ACCESS BY INDEX ROWID BATCHED | TA | 10 | 10040 | | 4 (0)| 00:00:01 |
|* 4 | INDEX RANGE SCAN | PK_TA | 10 | | | 1 (0)| 00:00:01 |
|* 5 | HASH JOIN | | 4004 | 7894K| 1170M| 199K (1)| 00:00:08 |
|* 6 | TABLE ACCESS FULL | TC | 1200K| 1156M| | 139K (1)| 00:00:06 |
| 7 | TABLE ACCESS BY INDEX ROWID BATCHED| TB | 10001 | 9844K| | 1486 (0)| 00:00:01 |
|* 8 | INDEX RANGE SCAN | PK_TB | 10000 | | | 26 (0)| 00:00:01 |
--------------------------------------------------------------------------------------------------------

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

1 - filter(ROWNUM<=1000)
2 - access("TB"."VERSION"="TA"."VERSION")
4 - access("TA"."VERSION">=1 AND "TA"."VERSION"<=10)
5 - access("TC"."VERSION"="TB"."VERSION" AND "TC"."BRANCH#"="TB"."BRANCH#")
6 - filter("TC"."VERSION"<=10 AND "TC"."VERSION">=1)
8 - access("TB"."VERSION">=1 AND "TB"."VERSION"<=10)

統計
----------------------------------------------------------
1258 recursive calls
0 db block gets
515770 consistent gets
516798 physical reads
0 redo size
1062679 bytes sent via SQL*Net to client
1270 bytes received via SQL*Net from client
68 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
1000 rows processed

FETCH FIRST N ROWS ONLYを利用した場合

00:20:36 SCOTT@pdborcl> r
1 select /*+ leading(tc) use_hash(tc tb ta) index(ta pk_ta) index(tb pk_tb) */ *
2 from
3 tc join tb
4 on
5 tc.version = tb.version
6 and tc.branch# = tb.branch#
7 join ta
8 on
9 tb.version = ta.version
10 where
11 tc.version between 1 and 10
12* fetch first 1000 rows only

1000行が選択されました。

経過: 00:00:32.69

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

-------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time |
-------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 300K| 456M| | 199K (1)| 00:00:08 |
|* 1 | VIEW | | 300K| 456M| | 199K (1)| 00:00:08 |
|* 2 | WINDOW NOSORT STOPKEY | | 300K| 864M| | 199K (1)| 00:00:08 |
|* 3 | HASH JOIN | | 300K| 864M| | 199K (1)| 00:00:08 |
| 4 | TABLE ACCESS BY INDEX ROWID | TA | 10 | 10040 | | 4 (0)| 00:00:01 |
|* 5 | INDEX RANGE SCAN | PK_TA | 10 | | | 1 (0)| 00:00:01 |
|* 6 | HASH JOIN | | 600K| 1155M| 1170M| 199K (1)| 00:00:08 |
|* 7 | TABLE ACCESS FULL | TC | 1200K| 1156M| | 139K (1)| 00:00:06 |
| 8 | TABLE ACCESS BY INDEX ROWID| TB | 10001 | 9844K| | 1486 (0)| 00:00:01 |
|* 9 | INDEX RANGE SCAN | PK_TB | 10000 | | | 26 (0)| 00:00:01 |
-------------------------------------------------------------------------------------------------

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

1 - filter("from$_subquery$_006"."rowlimit_$$_rownumber"<=1000)
2 - filter(ROW_NUMBER() OVER ( ORDER BY NULL )<=1000)
3 - access("TB"."VERSION"="TA"."VERSION")
5 - access("TA"."VERSION">=1 AND "TA"."VERSION"<=10)
6 - access("TC"."VERSION"="TB"."VERSION" AND "TC"."BRANCH#"="TB"."BRANCH#")
7 - filter("TC"."VERSION"<=10 AND "TC"."VERSION">=1)
9 - access("TB"."VERSION">=1 AND "TB"."VERSION"<=10)

統計
----------------------------------------------------------
1456 recursive calls
0 db block gets
516181 consistent gets
514506 physical reads
0 redo size
1045990 bytes sent via SQL*Net to client
1270 bytes received via SQL*Net from client
68 SQL*Net roundtrips to/from client
75 sorts (memory)
0 sorts (disk)
1000 rows processed

Top N に関してはrownumでも fetch first N rows onlyでも弱点は弱点なのでrownumと同じ考え方でチューニングの方向を決めないと、ね。

・rownum使って満足しちゃってると..... #1
・rownum使って満足しちゃってると..... #2
・rownum使って満足しちゃってると..... #3
・rownum使って満足しちゃってると..... #4
・rownum使って満足しちゃってると.....おまけ

投稿日時 2013年7月 8日 (月) 01時21分 Linux, チューニング, SQL, VirtualBox, Oracle Database 12c release 1 | 固定リンク | 0 | コメント (0) | トラックバック (0)

2013年6月23日 (日)

rownum使って満足しちゃってると.....おまけ

rownumを使っているチューニングしました！　（キリっ

と、しているのに以下の例ようにハッシュ結合が行われ残念な結果になっていることってありませんか？　（私はよく目にします (@@)

rownumの弱点を説明している実行計画をよーーーく見返してください。　ハッシュ結合にはしていません

なぜだか分かりますか？

11:14:44 SCOTT> l
1 select *
2 from
3 tc join tb
4 on
5 tc.version = tb.version
6 and tc.branch# = tb.branch#
7 join ta
8 on
9 tb.version = ta.version
10 where
11 tc.version between 1 and 10
12* and rownum <= 1000
11:14:44 SCOTT> /

1000行が選択されました。

経過: 00:00:59.08

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

------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time |
------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1000 | 4923K| | 201K (1)| 00:40:14 |
|* 1 | COUNT STOPKEY | | | | | | |
|* 2 | HASH JOIN | | 1001 | 4928K| | 201K (1)| 00:40:14 |
| 3 | TABLE ACCESS BY INDEX ROWID | TA | 10 | 10040 | | 3 (0)| 00:00:01 |
|* 4 | INDEX RANGE SCAN | PK_TA | 10 | | | 1 (0)| 00:00:01 |
|* 5 | HASH JOIN | | 2002 | 3947K| 1161M| 201K (1)| 00:40:14 |
|* 6 | TABLE ACCESS FULL | TC | 1190K| 1148M| | 141K (1)| 00:28:20 |
| 7 | TABLE ACCESS BY INDEX ROWID| TB | 10001 | 9844K| | 1456 (0)| 00:00:18 |
|* 8 | INDEX RANGE SCAN | PK_TB | | | | 26 (0)| 00:00:01 |
------------------------------------------------------------------------------------------------

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

1 - filter(ROWNUM<=1000)
2 - access("TB"."VERSION"="TA"."VERSION")
4 - access("TA"."VERSION">=1 AND "TA"."VERSION"<=10)
5 - access("TC"."VERSION"="TB"."VERSION" AND "TC"."BRANCH#"="TB"."BRANCH#")
6 - filter("TC"."VERSION"<=10 AND "TC"."VERSION">=1)
8 - access("TB"."VERSION">=1 AND "TB"."VERSION"<=10)

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

ハッシュ結合などは典型的なのですが、操作を始めるとその操作が終了するまで次の操作に移行しないんですよ。

上記の例では赤い部分のハッシュ結合が終了するまでCOUNT STOPKEY操作(Id=1の部分）つまり、rownumの効果が発揮できないわけです。（残念！

結合がありrownumを使って行数制限している場合には、”大抵の場合" Nested Loop結合にしたほうがいいんですよ！　OLTP系のようにレスポンスを重視する傾向が強い場合は... (弱点もありますが...

レスポンス重視かスループット重視か、オプティマイザが実行計画を組み立てる際に影響をパラメータがありますよね、　レースカーのフロントウイングやりやウィングのように立てたり寝かしたりするようなパラメータが.... :)

話がそれてしまいましたが...w

11:13:28 SCOTT> l
1 select /*+ leading(tc) use_nl(tc tb ta) */ *
2 from
3 tc join tb
4 on
5 tc.version = tb.version
6 and tc.branch# = tb.branch#
7 join ta
8 on
9 tb.version = ta.version
10 where
11 tc.version between 1 and 10
12* and rownum <= 1000
11:13:29 SCOTT> /

1000行が選択されました。

経過: 00:00:00.29

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

-----------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
-----------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1000 | 2952K| 3798 (1)| 00:00:46 |
|* 1 | COUNT STOPKEY | | | | | |
| 2 | NESTED LOOPS | | | | | |
| 3 | NESTED LOOPS | | 1001 | 2955K| 3798 (1)| 00:00:46 |
| 4 | NESTED LOOPS | | 2002 | 3947K| 2796 (1)| 00:00:34 |
| 5 | TABLE ACCESS BY INDEX ROWID| TC | 4004 | 3953K| 571 (0)| 00:00:07 |
|* 6 | INDEX RANGE SCAN | PK_TC | | | 13 (0)| 00:00:01 |
| 7 | TABLE ACCESS BY INDEX ROWID| TB | 1 | 1008 | 1 (0)| 00:00:01 |
|* 8 | INDEX UNIQUE SCAN | PK_TB | 1 | | 0 (0)| 00:00:01 |
|* 9 | INDEX UNIQUE SCAN | PK_TA | 1 | | 0 (0)| 00:00:01 |
| 10 | TABLE ACCESS BY INDEX ROWID | TA | 1 | 1004 | 1 (0)| 00:00:01 |
-----------------------------------------------------------------------------------------

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

1 - filter(ROWNUM<=1000)
6 - access("TC"."VERSION">=1 AND "TC"."VERSION"<=10)
8 - access("TC"."VERSION"="TB"."VERSION" AND "TC"."BRANCH#"="TB"."BRANCH#")
filter("TB"."VERSION"<=10 AND "TB"."VERSION">=1)
9 - access("TB"."VERSION"="TA"."VERSION")
filter("TA"."VERSION">=1 AND "TA"."VERSION"<=10)

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

＞結合がありrownumを使って行数制限している場合には、”大抵の場合" Nested Loop結合にしたほうがいいんですよ！　OLTP系の場合は特に. (弱点もありますが...

と書きましたが、”大抵の場合”と書いたのには理由があります。

あえてハッシュ結合にする場合もあるんです。　え！、え！、え〜〜〜〜〜っ！w

”常に遅いけど、Nested Loop結合+rownumにした場合の弱点”は絶対避けたいような場合です。

Nested Loop結合＋rownumにした場合の弱点の処理時間が、ハッシュ結合+rownumにした場合の処理時間を大幅に上回り、想定しているバッチ処理時間を超過してしまう可能性が高い場合がそれです。

状況に合わせて使い分けたいですよね。机上だけだと難しいのですが、実マシン、実データで検証を繰り返していれば対処できる問題だと思います。

・rownum使って満足しちゃってると..... #1
・rownum使って満足しちゃってると..... #2
・rownum使って満足しちゃってると..... #3
・rownum使って満足しちゃってると..... #4

投稿日時 2013年6月23日 (日) 12時12分 Oracle, チューニング, SQL | 固定リンク | 0 | コメント (0) | トラックバック (0)

2013年6月11日 (火)

rownum使って満足しちゃってると..... #4

つづきです。

前回の記事でも、まだ、ぼや〜〜〜〜んとしている方向け! :) #そうじゃない方も

以下は、リアルタムSQLモニタリングの結果ですが、rownumが効いたケース（上の結果）と効かなかったケース（下の結果）の違いは一目瞭然！
rownumの操作を示すCOUNT STOPKEYが上限の1000に満たない状態でId=4〜8のTC表とTB表の結合で100万回ループするNESTED LOOP結合が行われた後、Id=3,9でTA表と100万回ループするNESTED LOOP結合が行われているがよくわかります。

※前々回rownumが狙い通りに効いたケースのSQLリアルタイムモニタリング結果

=======================================================================================================================================================
| Id | Operation | Name | Rows | Cost | Time | Start | Execs | Rows | Read | Read | Activity | Activity Detail |
| | | | (Estim) | | Active(s) | Active | | (Actual) | Reqs | Bytes | (%) | (# samples) |
=======================================================================================================================================================
| 0 | SELECT STATEMENT | | | | 18 | +0 | 1 | 1000 | | | | |
| 1 | COUNT STOPKEY | | | | 18 | +0 | 1 | 1000 | | | | |
| 2 | NESTED LOOPS | | | | 18 | +0 | 1 | 1000 | | | | |
| 3 | NESTED LOOPS | | 1001 | 3798 | 18 | +0 | 1 | 1000 | | | | |
| 4 | NESTED LOOPS | | 2002 | 2796 | 18 | +0 | 1 | 1000 | | | | |
| 5 | TABLE ACCESS BY INDEX ROWID | TC | 4004 | 571 | 18 | +0 | 1 | 1000 | 53 | 1MB | | |
| 6 | INDEX RANGE SCAN | PK_TC | | 13 | 18 | +0 | 1 | 1000 | 3 | 49152 | | |
| 7 | TABLE ACCESS BY INDEX ROWID | TB | 1 | 1 | 18 | +0 | 1000 | 1000 | 2 | 65536 | | |
| 8 | INDEX UNIQUE SCAN | PK_TB | 1 | | 18 | +0 | 1000 | 1000 | 2 | 40960 | | |
| 9 | INDEX UNIQUE SCAN | PK_TA | 1 | | 18 | +0 | 1000 | 1000 | 1 | 8192 | | |
| 10 | TABLE ACCESS BY INDEX ROWID | TA | 1 | 1 | 18 | +0 | 1000 | 1000 | 1 | 8192 | | |
=======================================================================================================================================================

※前回rownumが狙い通りに効かなかったケースのSQLリアルタイムモニタリング結果

=========================================================================================================================================
| Id | Operation | Name | Rows | Cost | Time | Start | Execs | Rows | Activity | Activity Detail |
| | | | (Estim) | | Active(s) | Active | | (Actual) | (%) | (# samples) |
=========================================================================================================================================
| 0 | SELECT STATEMENT | | | | | | 1 | | | |
| 1 | COUNT STOPKEY | | | | | | 1 | | | |
| 2 | NESTED LOOPS | | | | | | 1 | | | |
| 3 | NESTED LOOPS | | 1000 | 37910 | 2 | +2 | 1 | 0 | | |
| 4 | NESTED LOOPS | | 20001 | 27906 | 2 | +2 | 1 | 1M | | |
| 5 | TABLE ACCESS BY INDEX ROWID | TC | 40003 | 5675 | 3 | +1 | 1 | 1M | 25.00 | Cpu (1) |
| 6 | INDEX RANGE SCAN | PK_TC | | 109 | 2 | +2 | 1 | 1M | 25.00 | Cpu (1) |
| 7 | TABLE ACCESS BY INDEX ROWID | TB | 1 | 1 | 3 | +2 | 1M | 1M | 25.00 | Cpu (1) |
| 8 | INDEX UNIQUE SCAN | PK_TB | 1 | | 2 | +2 | 1M | 1M | 25.00 | Cpu (1) |
| 9 | INDEX UNIQUE SCAN | PK_TA | 1 | | | | 1M | | | |
| 10 | TABLE ACCESS BY INDEX ROWID | TA | 1 | 1 | | | | | | |
=========================================================================================================================================

rownumって、取得する行数の制限なのであって、NESTED LOOP結合のループ回数を制限するものではないんですよね。

rownumを使っているからもう安心！　（キリっ！　

と、言えない状況もあるということはお忘れなく！

現状、この弱点を回避する方法は無いのですから....

・rownum使って満足しちゃってると..... #1
・rownum使って満足しちゃってると..... #2
・rownum使って満足しちゃってると..... #3

投稿日時 2013年6月11日 (火) 01時00分 Oracle, チューニング, SQL | 固定リンク | 0 | コメント (1) | トラックバック (0)

2013年6月10日 (月)

rownum使って満足しちゃってると..... #3

つづきです。

rownumの弱点分かりましたよね？

まだ、ぼや〜〜〜〜んとしていますか？

では、以下を見てください。

前々回rownumが狙い通りに効いたケースと、前回rownumが狙い通りに効かなかったケースの駆動表と１つ目の内部表の結合結果です。

どちらのケースでも同じ件数（buffer getsも同じです）がヒットしています。

駆動表TCと１つ目の内部表TBの結合結果は検索範囲は違いますが同じです。

※前々回rownumが狙い通りに効いたケースの駆動表TCと１つ目の内部表TBの結合結果

01:45:02 SCOTT> l
1 select count(1)
2 from
3 tc join tb
4 on
5 tc.version = tb.version
6 and tc.branch# = tb.branch#
7 where
8* tc.version between 1 and 10
01:45:03 SCOTT> /

COUNT(1)
----------
1000000

※前回rownumが狙い通りに効かなかったケースの駆動表TCと１つ目の内部表TBの結合結果

01:45:52 SCOTT> l
1 select count(1)
2 from
3 tc join tb
4 on
5 tc.version = tb.version
6 and tc.branch# = tb.branch#
7 where
8* tc.version between 11 and 20
01:45:52 SCOTT> /

COUNT(1)
----------
1000000

違いは、２つ目の内部表の結合でヒットするデータが1000件以上あったか、0件だったかの違いだけなんです。

もう少し分かりやすく説明すると、以下の赤字部分まではどちらも同じですが...

-----------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
-----------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1000 | 2952K| 37910 (1)| 00:07:35 |
|* 1 | COUNT STOPKEY | | | | | |
| 2 | NESTED LOOPS | | | | | |
| 3 | NESTED LOOPS | | 1000 | 2952K| 37910 (1)| 00:07:35 |
| 4 | NESTED LOOPS | | 20001 | 38M| 27906 (1)| 00:05:35 |
| 5 | TABLE ACCESS BY INDEX ROWID| TC | 40003 | 38M| 5675 (1)| 00:01:09 |
|* 6 | INDEX RANGE SCAN | PK_TC | | | 109 (0)| 00:00:02 |
| 7 | TABLE ACCESS BY INDEX ROWID| TB | 1 | 1008 | 1 (0)| 00:00:01 |
|* 8 | INDEX UNIQUE SCAN | PK_TB | 1 | | 0 (0)| 00:00:01 |
|* 9 | INDEX UNIQUE SCAN | PK_TA | 1 | | 0 (0)| 00:00:01 |
| 10 | TABLE ACCESS BY INDEX ROWID | TA | 1 | 1004 | 1 (0)| 00:00:01 |
-----------------------------------------------------------------------------------------

以下の赤字部分ID=3のNESTED LOOP部分でヒットするデータが1000件以上あるか、０件かが分かれ道だったんです。

-----------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
-----------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1000 | 2952K| 37910 (1)| 00:07:35 |
|* 1 | COUNT STOPKEY | | | | | |
| 2 | NESTED LOOPS | | | | | |
| 3 | NESTED LOOPS | | 1000 | 2952K| 37910 (1)| 00:07:35 |
| 4 | NESTED LOOPS | | 20001 | 38M| 27906 (1)| 00:05:35 |
| 5 | TABLE ACCESS BY INDEX ROWID| TC | 40003 | 38M| 5675 (1)| 00:01:09 |
|* 6 | INDEX RANGE SCAN | PK_TC | | | 109 (0)| 00:00:02 |
| 7 | TABLE ACCESS BY INDEX ROWID| TB | 1 | 1008 | 1 (0)| 00:00:01 |
|* 8 | INDEX UNIQUE SCAN | PK_TB | 1 | | 0 (0)| 00:00:01 |
|* 9 | INDEX UNIQUE SCAN | PK_TA | 1 | | 0 (0)| 00:00:01 |
| 10 | TABLE ACCESS BY INDEX ROWID | TA | 1 | 1004 | 1 (0)| 00:00:01 |
-----------------------------------------------------------------------------------------

え、まだ、ぼや〜〜〜〜んとしています？　

んんん〜〜〜〜〜っ

つづく。

・rownum使って満足しちゃってると..... #1
・rownum使って満足しちゃってると..... #2

投稿日時 2013年6月10日 (月) 00時26分 Oracle, チューニング, SQL | 固定リンク | 0 | コメント (0) | トラックバック (0)

2013年6月 8日 (土)

rownum使って満足しちゃってると..... #2

rownumの弱点に気付きました？

では、以下のクエリを見てください。前回の例と検索範囲は多少変えてありますがSQL文やヒントは同じです。実行計画も全く同じです。　

が、

Elapsed timeは、2670msになり、Buffer Getsは、1174942、と、すごいことになっています。

Physical readが発生していないのでこの程度の差ですが、Elapsed timeは、約１０倍、Buffer Getsは、なんと、約490倍にもなってます！

しかも、rows processedは、0 です！

なんということでしょう！０行なのに、Elapsed timeとBuffer Getsが異常に増加してる.....（ニヤニヤ

これがrownumの弱点！

01:43:17 SCOTT> l
1 select /*+ leading(tc) use_nl(tc tb ta) */ *
2 from
3 tc join tb
4 on
5 tc.version = tb.version
6 and tc.branch# = tb.branch#
7 join ta
8 on
9 tb.version = ta.version
10 where
11 tc.version between 11 and 20
12* and rownum <= 1000
01:43:17 SCOTT> /

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

経過: 00:00:02.67

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

-----------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
-----------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1000 | 2952K| 37910 (1)| 00:07:35 |
|* 1 | COUNT STOPKEY | | | | | |
| 2 | NESTED LOOPS | | | | | |
| 3 | NESTED LOOPS | | 1000 | 2952K| 37910 (1)| 00:07:35 |
| 4 | NESTED LOOPS | | 20001 | 38M| 27906 (1)| 00:05:35 |
| 5 | TABLE ACCESS BY INDEX ROWID| TC | 40003 | 38M| 5675 (1)| 00:01:09 |
|* 6 | INDEX RANGE SCAN | PK_TC | | | 109 (0)| 00:00:02 |
| 7 | TABLE ACCESS BY INDEX ROWID| TB | 1 | 1008 | 1 (0)| 00:00:01 |
|* 8 | INDEX UNIQUE SCAN | PK_TB | 1 | | 0 (0)| 00:00:01 |
|* 9 | INDEX UNIQUE SCAN | PK_TA | 1 | | 0 (0)| 00:00:01 |
| 10 | TABLE ACCESS BY INDEX ROWID | TA | 1 | 1004 | 1 (0)| 00:00:01 |
-----------------------------------------------------------------------------------------

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

1 - filter(ROWNUM<=1000)
6 - access("TC"."VERSION">=11 AND "TC"."VERSION"<=20)
8 - access("TC"."VERSION"="TB"."VERSION" AND "TC"."BRANCH#"="TB"."BRANCH#")
filter("TB"."VERSION">=11 AND "TB"."VERSION"<=20)
9 - access("TB"."VERSION"="TA"."VERSION")
filter("TA"."VERSION">=11 AND "TA"."VERSION"<=20)

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

01:43:21 SCOTT>

私が寝る時間欲しさに、データ量をケチったw のでこの程度の差しかありませんが、データ量が多ければもっと酷い結果となっていたことでしょう。

謎は解けましたよね!

　どうしたんだ、Hey , Hey, べいべ〜♪　　
　データベースエンジンはビンビンだせ〜♪
　いつものように〜、きめて、1000行までで止ようぜ〜〜♪
.....
　こんな夜に〜♪、　rownumが効かないなんて〜♪
　こんな夜に〜♪、　遅延しちまうなんて〜♪

次回へつづく。

・rownum使って満足しちゃってると..... #1

投稿日時 2013年6月 8日 (土) 00時24分 Oracle, チューニング, SQL | 固定リンク | 0 | コメント (0) | トラックバック (0)

2013年6月 7日 (金)

rownum使って満足しちゃってると..... #1

まずは、以下のクエリを見てください。（適当に作りすぎたので、よい例ではないですが...)

220秒ms程度で、Buffer Getsが2418程度あります。numrowで制限している最大件数が戻されています。

データが大量にヒットする可能性があるようですね。

rownumで返す行数を制限し、ネステッドループ結合にしてチューニングするケースは多々あります。

00:44:53 SCOTT> set autot trace exp stat
01:42:37 SCOTT> l
1 select /*+ leading(tc) use_nl(tc tb ta) */ *
2 from
3 tc join tb
4 on
5 tc.version = tb.version
6 and tc.branch# = tb.branch#
7 join ta
8 on
9 tb.version = ta.version
10 where
11 tc.version between 1 and 10
12* and rownum <= 1000
01:42:37 SCOTT> /

1000行が選択されました。

経過: 00:00:00.22

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

-----------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
-----------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1000 | 2952K| 3798 (1)| 00:00:46 |
|* 1 | COUNT STOPKEY | | | | | |
| 2 | NESTED LOOPS | | | | | |
| 3 | NESTED LOOPS | | 1001 | 2955K| 3798 (1)| 00:00:46 |
| 4 | NESTED LOOPS | | 2002 | 3947K| 2796 (1)| 00:00:34 |
| 5 | TABLE ACCESS BY INDEX ROWID| TC | 4004 | 3953K| 571 (0)| 00:00:07 |
|* 6 | INDEX RANG

	Format	Description
Scan method	`SeqScan(table)`	Forces sequential scan on the table.
	`TidScan(table)`	Forces TID scan on the table.
	`IndexScan(table[ index...])`	Forces index scan on the table. Restricts to specified indexes if any.
	`IndexOnlyScan(table[ index...])`	Forces index-only scan on the table. Restricts to specified indexes if any. Index scan may be used if index-only scan is not available.
	`BitmapScan(table[ index...])`	Forces bitmap scan on the table. Restricts to specified indexes if any.
	`IndexScanRegexp(table[ POSIX Regexp...])` `IndexOnlyScanRegexp(table[ POSIX Regexp...])` `BitmapScanRegexp(table[ POSIX Regexp...])`	Forces index scan, index-only scan (For PostgreSQL 9.2 and later) or bitmap scan on the table. Restricts to indexes that matches the specified POSIX regular expression pattern.
	`NoSeqScan(table)`	Forces to not do sequential scan on the table.
	`NoTidScan(table)`	Forces to not do TID scan on the table.
	`NoIndexScan(table)`	Forces to not do index scan and index-only scan on the table.
	`NoIndexOnlyScan(table)`	Forces to not do index only scan on the table.
	`NoBitmapScan(table)`	Forces to not do bitmap scan on the table.
Join method	`NestLoop(table table[ table...])`	Forces nested loop for the joins on the tables specified.
	`HashJoin(table table[ table...])`	Forces hash join for the joins on the tables specified.
	`MergeJoin(table table[ table...])`	Forces merge join for the joins on the tables specified.
	`NoNestLoop(table table[ table...])`	Forces to not do nested loop for the joins on the tables specified.
	`NoHashJoin(table table[ table...])`	Forces to not do hash join for the joins on the tables specified.
	`NoMergeJoin(table table[ table...])`	Forces to not do merge join for the joins on the tables specified.
Join order	`Leading(table table[ table...])`	Forces join order as specified.
	`Leading(<join pair>)`	Forces join order and directions as specified. A join pair is a pair of tables and/or other join pairs enclosed by parentheses, which can make a nested structure.
Behavior control on Join	`Memoize(table table[ table...])`	Allows the topmost join of a join among the specified tables to Memoize the inner result. Not enforced.
	`NoMemoize(table table[ table...])`	Inhibits the topmost join of a join among the specified tables from Memoizing the inner result.
Row number correction	`Rows(table table[ table...] correction)`	Corrects row number of a result of the joins on the tables specified. The available correction methods are absolute (#), addition (+), subtract (-) and multiplication (*). should be a string that strtod() can understand.
Parallel query configuration	`Parallel(table <# of workers> [soft\|hard])`	Enforces or inhibits parallel execution of the specified table. <# of workers> is the desired number of parallel workers, where zero means inhibiting parallel execution. If the third parameter is soft (default), it just changes max_parallel_workers_per_gather and leaves everything else to the planner. Hard enforces the specified number of workers.
GUC	`Set(GUC-param value)`	Sets GUC parameter to the value defined while planner is running.

Hint Name	Description	Applicable Scopes
`BKA`, `NO_BKA`	Affects Batched Key Access join processing	Query block, table
`BNL`, `NO_BNL`	Prior to MySQL 8.0.20: affects Block Nested-Loop join processing; MySQL 8.0.18 and later: also affects hash join optimization; MySQL 8.0.20 and later: affects hash join optimization only	Query block, table
`DERIVED_CONDITION_PUSHDOWN`, `NO_DERIVED_CONDITION_PUSHDOWN`	Use or ignore the derived condition pushdown optimization for materialized derived tables (Added in MySQL 8.0.22)	Query block, table
`GROUP_INDEX`, `NO_GROUP_INDEX`	Use or ignore the specified index or indexes for index scans in `GROUP BY` operations (Added in MySQL 8.0.20)	Index
`HASH_JOIN`, `NO_HASH_JOIN`	Affects Hash Join optimization (MySQL 8.0.18 only	Query block, table
`INDEX`, `NO_INDEX`	Acts as the combination of `JOIN_INDEX`, `GROUP_INDEX`, and `ORDER_INDEX`, or as the combination of `NO_JOIN_INDEX`, `NO_GROUP_INDEX`, and `NO_ORDER_INDEX` (Added in MySQL 8.0.20)	Index
`INDEX_MERGE`, `NO_INDEX_MERGE`	Affects Index Merge optimization	Table, index
`JOIN_FIXED_ORDER`	Use table order specified in `FROM` clause for join order	Query block
`JOIN_INDEX`, `NO_JOIN_INDEX`	Use or ignore the specified index or indexes for any access method (Added in MySQL 8.0.20)	Index
`JOIN_ORDER`	Use table order specified in hint for join order	Query block
`JOIN_PREFIX`	Use table order specified in hint for first tables of join order	Query block
`JOIN_SUFFIX`	Use table order specified in hint for last tables of join order	Query block
`MAX_EXECUTION_TIME`	Limits statement execution time	Global
`MERGE`, `NO_MERGE`	Affects derived table/view merging into outer query block	Table
`MRR`, `NO_MRR`	Affects Multi-Range Read optimization	Table, index
`NO_ICP`	Affects Index Condition Pushdown optimization	Table, index
`NO_RANGE_OPTIMIZATION`	Affects range optimization	Table, index
`ORDER_INDEX`, `NO_ORDER_INDEX`	Use or ignore the specified index or indexes for sorting rows (Added in MySQL 8.0.20)	Index
`QB_NAME`	Assigns name to query block	Query block
`RESOURCE_GROUP`	Set resource group during statement execution	Global
`SEMIJOIN`, `NO_SEMIJOIN`	Affects semijoin strategies; beginning with MySQL 8.0.17, this also applies to antijoins	Query block
`SKIP_SCAN`, `NO_SKIP_SCAN`	Affects Skip Scan optimization	Table, index
`SET_VAR`	Set variable during statement execution	Global
`SUBQUERY`	Affects materialization, `IN`-to-`EXISTS` subquery strategies	Query block

Oracle	READ COMMITTED
12.1.0.2.0	ID=2を取得
12.2.0.1.0	ID=2を取得
18.3.0.0.0	ID=2を取得

年月ネン	＃	Before Tuning(ms)	After Tuning(ms)	改善カイゼン（倍）バイ
2011/10	1	6,000	10	600
2011/10	2	5,780	10	578
2011/10	3	170	60	3
2011/11	4	30	10	3
2011/11	5	485	1	485
2011/11	6	890	10	89
2011/11	7	900,500	2,500	360
2011/11	8	170	10	17
2011/11	9	1,560	1	1,560
2011/11	10	1,890	33	57
2011/12	11	10,800,000	3,000	3,600
2012/01	12	58,000	1,000	58
2012/06	13	1,080,000	1,000	1,080
2012/08	14	1,800,000	50	36,000
2012/12	15	18,000,000	7,000	2,571
2012/12	16	7,300,000	17,000	429
2013/01	17	21,600,000	180,000	120
2013/01	18	4,000	10	400
2013/03	19	1,100	10	110
2013/06	20	234,000,000	120,000	1,950
2013/08	21	5,000	400	13
2013/08	22	50,400,000	1,620,000	31
2013/08	23	6,000,000	70,000	86
2013/09	24	32,000	420	76
2014/03	25	191	2	96
2014/05	26	14,400,000	90,000	160
2014/05	27	40,000	2,000	20
2014/05	28	320,000	8,000	40
2014/06	29	17,000	3,000	6
2016/02	30	2,000,000	10	200,000
2016/04	31	24,000	400	60
2016/05	32	10,000	40	250
合計ゴウケ		368,808,766	2,125,987	173

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

当サイトについて

2025年9月30日 (火)

2025年8月24日 (日)

2025年8月22日 (金)

2025年7月 4日 (金)

2025年6月25日 (水)

2025年6月18日 (水)

2025年6月17日 (火)

2025年6月 5日 (木)

2025年6月 4日 (水)

2025年6月 3日 (火)

2025年5月26日 (月)

2025年4月28日 (月)

2025年1月30日 (木)

2024年12月27日 (金)

2024年12月21日 (土)

2024年12月13日 (金)

2024年10月 2日 (水)

2024年9月 1日 (日)

2024年8月30日 (金)

2024年8月21日 (水)

2024年7月24日 (水)

2024年7月23日 (火)

2024年7月22日 (月)

2024年7月12日 (金)

2024年7月11日 (木)

2024年7月10日 (水)

2024年7月 1日 (月)

2024年6月29日 (土)

2024年6月23日 (日)

2024年6月22日 (土)

2024年5月29日 (水)

2024年5月19日 (日)

2024年5月16日 (木)

2024年3月25日 (月)

2024年2月21日 (水)

2023年12月22日 (金)

2023年12月17日 (日)

2023年12月10日 (日)

2023年12月 9日 (土)

2023年11月22日 (水)

Hint list

2023年10月11日 (水)

2023年9月28日 (木)

2023年9月23日 (土)

2023年9月 7日 (木)

2023年9月 2日 (土)

2023年9月 1日 (金)

2023年8月29日 (火)

2023年8月 7日 (月)

2023年8月 4日 (金)

2023年2月 2日 (木)

2023年1月27日 (金)

2023年1月16日 (月)

2022年12月26日 (月)

2022年12月25日 (日)

2022年12月24日 (土)

2022年12月23日 (金)

2022年12月21日 (水)

2022年12月20日 (火)

2022年12月19日 (月)

2022年12月18日 (日)

2022年12月17日 (土)

2022年12月16日 (金)

2022年12月15日 (木)

2022年12月14日 (水)