Mac De Oracle: Advent Calendar

2026年6月
日	月	火	水	木	金	土
	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

Apple Loopとチョップだけで頑張るGarageBand DTM 全部俺 Advent Calendar 2024　#25 - フリー動画と合わせて完成

Apple Loopとチョップだけで頑張るGarageBand DTM 全部俺 Advent Calendar 2024
25日目の窓を開けました！

BarageBandではなくて、iMovieネタになっちゃいますが。
細かい動画作業ログは動画にて。（いつもの pixabay と Adobe Stock の素材を組み合わせて使う。。完成版はどうなりますか....）

完成版!
Neko Mimi Loops 2024 / N + 1 Loops

Enjoy DTM, GarageBand and iMovie

I wish you a Merry Christmas! and a Happy New Year!
C-YA! Next Articles.

投稿日時 2024年12月25日 (水) 00時00分音楽, Mac, GarageBand, Advent Calendar, iMovie, DTM, Apple Silicon ARM64 | 固定リンク | 0 | コメント (0)

Apple Loopとチョップだけで頑張るGarageBand DTM 全部俺 Advent Calendar 2024　#24 - Version.1とVersion.2の比較！

Apple Loopとチョップだけで頑張るGarageBand DTM 全部俺 Advent Calendar 2024
24日目の窓を開けました！

完成したので、Version.1 と Version.2 の比較！〜

Before ( Ver.1 - 2023年 ) : Neco Mimi Loops / N + 1 Loops

After ( Ver.2 ) : Neko Mimi Loops 2024 / N + 1 Loops

結構変わったのでヨシとするw Apple Loopとチョップだけで頑張るGarageBand DTM 全部俺 Advent Calendar 2024最終日の明日は、フリー動画（ pixabay )で見つけた動画やAdobe Stock（有料）の商用でも利用可能な動画と合わせて完成予定:)

Enjoy DTM, GarageBand and iMovie

では、また明日

投稿日時 2024年12月24日 (火) 00時00分音楽, Mac, GarageBand, Advent Calendar, iMovie, DTM, Apple Silicon ARM64 | 固定リンク | 0 | コメント (0)

Apple Loopとチョップだけで頑張るGarageBand DTM 全部俺 Advent Calendar 2024　#23 - 完成間近、各トラックのバランスとか音色調整とか　その3

Apple Loopとチョップだけで頑張るGarageBand DTM 全部俺 Advent Calendar 2024
23日目の窓を開けました！

最後にスクラッチ、ネコの鳴き声トラックの音色等を調整して完成！！！！　やった〜〜
今日調整したトラックは以下。トラックにLoop名称を利用し "トラック番号.Loop名称"にしてあるので参考にしていただければ。

07.Sunday Haze Scratch Synth Pad
08.Crate Digging Scratch FX
09.Vinyl Scratch 01
10.Scratchy Wobble Bass
14.Communication Static
15.Cat Meow 05
16.Catch Me Chop Vox
17.True Heart Chop Vox
18.Choppy Vox Lead 04
19.Around Midnight Vox Melody 01.61
20.Around Midnight Vox Melody 02

細かい作業の様子は以下の動画にて。明日は、Ver.1と今回色々変えまくったVer.2の聴き比べでも。
BGM : City Lights Loops / N + 1 Loops, Heatbeats Loops / N + 1 Loops

Enjoy DTM, GarageBand and iMovie

では、また明日。

投稿日時 2024年12月23日 (月) 00時00分音楽, Mac, GarageBand, Advent Calendar, iMovie, DTM, Apple Silicon ARM64 | 固定リンク | 0 | コメント (0)

Apple Loopとチョップだけで頑張るGarageBand DTM 全部俺 Advent Calendar 2024　#22 - 完成間近、各トラックのバランスとか音色調整とか　その2

Apple Loopとチョップだけで頑張るGarageBand DTM 全部俺 Advent Calendar 2024 22日目の窓を開けました！

レイヤー部分とかイントロの一部のシンセサイザーの音色やエコーなどを調整中
今日調整したトラックは以下。トラックにLoop名称を利用し "トラック番号.Loop名称"にしてあるので参考にしていただければ。

05.Swelling Sub Bass
06.Transport Stop Synth
11.Glow Scratchy Pad
21.Break Free Choir Pad
22.Break Free Choir Pad.1
23.Ride With Me Synth Pluck
24.Hidden Origins 01
25.Night Walk Echo Plucks
26.Night Walk Echo Plucks +12
27.Night Shift Layers
28.Night Vision Synth Layers
29.Nocturnal Phase Synth 01
30.Shine Bright Arpeggio

ちなみに、よく使っているPlug-inは、Space Desinger, Stereo Spread, Compressor, EQあたりですね。たまに、Distortion も使ったりして音のザラつき感をSaxやブラス系のLoop持たせたりすることもあります。

細かい作業はいつもの動画にて。（今回も音の確認はありません。作業の様子のみです）

BGM : Rain Loops / N + 1 Loops , Moire Loops Dub version Ver. 1.1 / N + 1 Loops

Enjoy DTM, GarageBand and iMovie

では、また明日。

投稿日時 2024年12月22日 (日) 00時00分音楽, Mac, GarageBand, Advent Calendar, iMovie, DTM, Apple Silicon ARM64 | 固定リンク | 0 | コメント (0)

Apple Loopとチョップだけで頑張るGarageBand DTM 全部俺 Advent Calendar 2024　#21 - 完成間近、各トラックのバランスとか音色調整とか　その1

Apple Loopとチョップだけで頑張るGarageBand DTM 全部俺 Advent Calendar 2024 21日目の窓を開けました！

ほぼ完成なのですが、残る作業は各トラックの音色、バランスと音量の調整ですね。
それに、Plug-inで奥行きをつけたり。。地味だけど大切なやつ。
ということで、その1回目は、リズムセクション周りの部分からやっつけちゃおうかと。

使っている機器を書いておきます。音色や音の確認って結局のところ使用機材で違ったりするので。

Apple Studio Display 27inch、基本的にこれで。

次に、イヤフォンとヘッドフォン
Bose QuietComfort Earbuds
Bose QuietComfort Ultra Headphones

おまけ(ちょい古い)
Bose SoundLink Mini II

これらで音確認してます。

今日調整したトラックは以下。トラックにLoop名称を利用し "トラック番号.Loop名称"にしてあるので参考にしていただければ。

01.Synthetic Bass House
02.Almost Electro Beat
03.Les Inferno Snare
04.Neon Dreams Snare 02
12.Aggressive Stance Bass
13.Aggressive Step Synth Bass

細かい作業はいつもの動画で、音の確認は全トラックの調整終了後に予定しているため、今回は、各トラックの音調整完了後のセッティングのまとめのみです。

BGM : Memory Loops - ver. 1.1 / N + 1 Loops

Enjoy DTM, GarageBand and iMovie

では、また明日。

投稿日時 2024年12月21日 (土) 00時00分音楽, Mac, GarageBand, Advent Calendar, iMovie, DTM, Apple Silicon ARM64 | 固定リンク | 0 | コメント (0)

帰ってきた！標準はあるにはあるが癖の多い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]

3)

SCOTT@orclpdb1> SELECT LENGTH(' ') AS "SINGLE-BYTE SPACE" FROM dual;

SINGLE-BYTE SPACE
-----------------
                1

4)

SCOTT@orclpdb1> SELECT LENGTH('　') AS "MULTI-BYTE SPACE" FROM dual;

MULTI-BYTE SPACE
----------------
               1

5)

SCOTT@orclpdb1> SELECT LENGTH('12345') AS "SINGLE-BYTE CHARs" FROM dual;

SINGLE-BYTE CHARs
-----------------
                5

6)

SCOTT@orclpdb1> SELECT LENGTH('あいうえお') AS "MULTI-BYTE CHARs" FROM dual;

MULTI-BYTE CHARs
----------------
               5

7)

SCOTT@orclpdb1> SELECT LENGTH('12345     ') AS "SINGLE-BYTE CHARs + SPACEs" FROM dual;

SINGLE-BYTE CHARs + SPACEs
--------------------------
                        10

8)

SCOTT@orclpdb1> SELECT LENGTH('あいうえお　　　　　') AS "MULTI-BYTE CHARs + MLUTI-BYTE SPACEs" FROM dual;

MULTI-BYTE CHARs + MLUTI-BYTE SPACEs
------------------------------------
                                  10

9)

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    |
+-----------+

1)

mysql> SELECT CHAR_LENGTH(null) AS "NULL";
+------+
| NULL |
+------+
| NULL |
+------+

2)
Oracle Databaseとは異なり。空文字は空文字としてカウントされています。こちらが標準の動き（Oracle Database側に癖があります）

mysql> SELECT CHAR_LENGTH('') AS "Empty String";
+--------------+
| Empty String |
+--------------+
|            0 |
+--------------+

3)

mysql> SELECT CHAR_LENGTH(' ') AS "SINGLE-BYTE SPACE";
+-------------------+
| SINGLE-BYTE SPACE |
+-------------------+
|                 1 |
+-------------------+

4)

mysql> SELECT CHAR_LENGTH('　') AS "MULTI-BYTE SPACE";
+------------------+
| MULTI-BYTE SPACE |
+------------------+
|                1 |
+------------------+

5)

mysql> SELECT CHAR_LENGTH('12345') AS "SINGLE-BYTE CHARs";
+-------------------+
| SINGLE-BYTE CHARs |
+-------------------+
|                 5 |
+-------------------+

6)

mysql> SELECT CHAR_LENGTH('あいうえお') AS "MULTI-BYTE CHARs";
+------------------+
| MULTI-BYTE CHARs |
+------------------+
|                5 |
+------------------+

7)

mysql> SELECT CHAR_LENGTH('12345     ') AS "SINGLE-BYTE CHARs + SPACEs";
+----------------------------+
| SINGLE-BYTE CHARs + SPACEs |
+----------------------------+
|                         10 |
+----------------------------+

8)

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]"です。

1)

perftestdb=> SELECT LENGTH(null) AS "NULL";
  NULL  
--------
 [null]

2)
空文字の挙動はMySQLと同じですよね。

perftestdb=> SELECT LENGTH('') AS "Empty String";
 Empty String 
--------------
            0

3)

perftestdb=> SELECT LENGTH(' ') AS "SINGLE-BYTE SPACE";
 SINGLE-BYTE SPACE 
-------------------
                 1

4)

perftestdb=> SELECT LENGTH('　') AS "MULTI-BYTE SPACE";
 MULTI-BYTE SPACE 
------------------
                1

5)

perftestdb=> SELECT LENGTH('12345') AS "SINGLE-BYTE CHARs";
 SINGLE-BYTE CHARs 
-------------------
                 5

6)

perftestdb=> SELECT LENGTH('あいうえお') AS "MULTI-BYTE CHARs";
 MULTI-BYTE CHARs 
------------------
                5

7)

perftestdb=> SELECT LENGTH('12345     ') AS "SINGLE-BYTE CHARs + SPACEs";
 SINGLE-BYTE CHARs + SPACEs 
----------------------------
                         10

8)

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)

Apple Loopとチョップだけで頑張るGarageBand DTM 全部俺 Advent Calendar 2024　#20 - イントロにもう少し追加したいその3

Apple Loopとチョップだけで頑張るGarageBand DTM 全部俺 Advent Calendar 2024
20日目の窓を開けました！

ほぼもういいかなぁ。と思い、音のバランス調整を始めたら、イントロにもう少し足したくなりましたw。こればかりは仕方ない、そういう気持ちになったのでw
要らなそうなら削除しちゃえば問題ないわけですし

Before

After

細かい作業はいつものように動画にて。（追加した部分の雰囲気の違い。気づかないような程度ですが変わってますw）。

Enjoy DTM, GarageBand and iMovie

では、また明日。

投稿日時 2024年12月20日 (金) 00時00分音楽, Mac, GarageBand, Advent Calendar, iMovie, DTM, Apple Silicon ARM64 | 固定リンク | 0 | コメント (0)

Apple Loopとチョップだけで頑張るGarageBand DTM 全部俺 Advent Calendar 2024　#19 - イントロにもう少し追加したいその2

Apple Loopとチョップだけで頑張るGarageBand DTM 全部俺 Advent Calendar 2024
19日目の窓を開けました！

効果音をイントロの一部に追加したというのが前回まででした。
これでいいかなぁ。と思って何度か聞いていると、んーw また追加したい気持ちに。w （マジで気づかない程度にイントロにレイヤーを追加してみたい。。。と。
余計だったら後から削除すればいいですしw

Before

After

細かい作業ログはいつもの動画で。後半でイントロ含め通しで音確認しています。

Enjoy DTM, GarageBand and iMovie

では、また明日。

投稿日時 2024年12月19日 (木) 00時00分音楽, Mac, GarageBand, Advent Calendar, iMovie, DTM, Apple Silicon ARM64 | 固定リンク | 0 | コメント (0)

Apple Loopとチョップだけで頑張るGarageBand DTM 全部俺 Advent Calendar 2024　#18 - イントロにもう少し追加したいその1

Apple Loopとチョップだけで頑張るGarageBand DTM 全部俺 Advent Calendar 2024 18日目の窓を開けました！

前回イントロのループにオートメーションを追加していたときに感じたイントロの物足りなさ。
ということで、イントロをもうすこににぎやかにしてみようかとw （そんな感じ〜。というだけの感じ〜、が大切だと思うのでやってみましょうw )

Before

VOX的な効果音を追加してみたけど、悪くない感じw
After

いつものようにこまけー作業ログは動画にて。後半で本日の音確認しています。

Enjoy DTM, GarageBand and iMovie

では、また明日。

投稿日時 2024年12月18日 (水) 00時00分音楽, Mac, GarageBand, Advent Calendar, iMovie, DTM, Apple Silicon ARM64 | 固定リンク | 0 | コメント (0)

Apple Loopとチョップだけで頑張るGarageBand DTM 全部俺 Advent Calendar 2024　#17 - オートメーションを追加してパンを左右に自動的に振る

Apple Loopとチョップだけで頑張るGarageBand DTM 全部俺 Advent Calendar 2024
17日目の窓を開けました！

イントロの低音のボワ〜んというところ（表現がむずいがw）xトラック目の部分にオートメーションを追加してパンを左右に自動的に振るようにしてみた。

Before

After

細かい作業は動画にて。後半で今日の作業の音確認してます。　やっぱ左右に振ったほうが面白いよなぁ。

Enjoy DTM, GarageBand and iMovie

では、また明日。

投稿日時 2024年12月17日 (火) 00時00分音楽, Mac, GarageBand, Advent Calendar, iMovie, DTM, Apple Silicon ARM64 | 固定リンク | 0 | コメント (0)

Apple Loopとチョップだけで頑張るGarageBand DTM 全部俺 Advent Calendar 2024　#16 - BASSラインをチョップして音を削除

Apple Loopとチョップだけで頑張るGarageBand DTM 全部俺 Advent Calendar 2024
16日目の窓を開けました！

BASSライン、一部無い方が良いかなぁ。という音とチョップして削除してみる。（その方が良さげな気がするw

Before

After

確認中に、最後のスクラッチのタイミングが気に入らず、ついでに調整しちゃいましたw
細かい作業ログはいつもの動画で。後半で本日の音確認もしています。

Enjoy DTM, GarageBand and iMovie

では、また明日。

投稿日時 2024年12月16日 (月) 05時22分音楽, Mac, GarageBand, Advent Calendar, iMovie, DTM, Apple Silicon ARM64 | 固定リンク | 0 | コメント (0)

Apple Loopとチョップだけで頑張るGarageBand DTM 全部俺 Advent Calendar 2024　#15 - ネコだけにScratch追加したいその4

Apple Loopとチョップだけで頑張るGarageBand DTM 全部俺 Advent Calendar 2024
15日目の窓を開けました！

できた曲をしばらく聴いていたら、ん〜。もう一つScratchのトラックを追加したくなってきたので追加してみる。

Before

Scratch音のLoopに含まれていたシンセの音がいい感じのアクセントになりそうだったので、そこだけチョップして切り出して使ってみた。
After

いつものように作業ログはYoutubeの動画にて。後半で本日の音確認やってます。

Enjoy DTM, GarageBand and iMovie

では、また明日。

投稿日時 2024年12月15日 (日) 00時00分音楽, Mac, GarageBand, Advent Calendar, iMovie, DTM, Apple Silicon ARM64 | 固定リンク | 0 | コメント (0)

Apple Loopとチョップだけで頑張るGarageBand DTM 全部俺 Advent Calendar 2024　#14 - ネコだけにScratch追加したいその3の修正

Apple Loopとチョップだけで頑張るGarageBand DTM 全部俺 Advent Calendar 2024
14日目の窓を開けました！

ネコだけにScratch追加したいということで、その3 で追加したスクラッチですが、短いかなぁ（という感じ）、なので少し長くしてみましょう。

Before

分かり難いですがw、少し長くしました。
After

細かい作業のログと、音の確認は以下にて。

Enjoy DTM, GarageBand and iMovie

では、また明日。

投稿日時 2024年12月14日 (土) 00時00分音楽, Mac, GarageBand, Advent Calendar, iMovie, DTM, Apple Silicon ARM64 | 固定リンク | 0 | コメント (0)

Apple Loopとチョップだけで頑張るGarageBand DTM 全部俺 Advent Calendar 2024　#13 - ネコだけにScratch追加したいその3

Apple Loopとチョップだけで頑張るGarageBand DTM 全部俺 Advent Calendar 2024
13日目の窓を開けました！

まだまだ引っ掻いてる音がほしーーーい気がしませんか？w 。(まだ、追加するんかーーーーーーーいw)

Before

After

いつものように細かい作業はVlogにて。後半で、本日の作業確認として全体を通して音を確認しています。

Enjoy DTM, GarageBand and iMovie

では、また明日。

投稿日時 2024年12月13日 (金) 00時00分音楽, Mac, GarageBand, Advent Calendar, iMovie, DTM, Apple Silicon ARM64 | 固定リンク | 0 | コメント (0)

実行計画は, 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)

Apple Loopとチョップだけで頑張るGarageBand DTM 全部俺 Advent Calendar 2024　#12 - ネコだけにScratch追加したいその2

Apple Loopとチョップだけで頑張るGarageBand DTM 全部俺 Advent Calendar 2024
12日目の窓を開けました！

さぁ。アドベントカレンダーも折り返し地点:)

もっとスクラッチ追加したいですよねw まだまだ寂しい気がするので。ということで、さらに追加してみる
Before

After

こまけー作業は以下の動画にて。後半で、ここまでの音を確認しています。

Enjoy DTM, GarageBand and iMovie

では、また明日。

投稿日時 2024年12月12日 (木) 00時00分音楽, Mac, GarageBand, Advent Calendar, iMovie, DTM, Apple Silicon ARM64 | 固定リンク | 0 | コメント (0)

Apple Loopとチョップだけで頑張るGarageBand DTM 全部俺 Advent Calendar 2024　#11 - ネコだけにScratch追加したいその1

Apple Loopとチョップだけで頑張るGarageBand DTM 全部俺 Advent Calendar 2024
11日目の窓を開けました！

ネコ成分、というかネコだけに、スクラッチも追加したいですよねw 爪研ぎというかw ということで何か追加してみる。。
Before

After

細かい作業の様子は動画にて。最後に本日の作業の音確認してます。完成に近づいてきた:)

そういえば、これも書いておかないと思い忘れていたのですが、その昔、GarageBand登場前と言った方が良いのかなw PlayerProというDAWとしても老舗に近いシェアウェアがありました。私も使っていたのですが、当時は画期的でしたねぇ。と思い出に浸るw

Enjoy DTM, GarageBand and iMovie

では、また明日。

投稿日時 2024年12月11日 (水) 00時00分音楽, Mac, GarageBand, Advent Calendar, iMovie, DTM, Apple Silicon ARM64 | 固定リンク | 0 | コメント (0)

Apple Loopとチョップだけで頑張るGarageBand DTM 全部俺 Advent Calendar 2024　#10 - ネコっぽい効果音をリズムに絡める　その2

Apple Loopとチョップだけで頑張るGarageBand DTM 全部俺 Advent Calendar 2024
10日目の窓を開けました！

ネコ成分、もう少し欲しいいなぁw。
ということで、もう1トラック追加してみようと思いますw

Before

After

細かい作業の様子は以下の動画で。最後に本日の作業の結果確認として音を確認しています。

Enjoy DTM, GarageBand and iMovie

では、また明日。

投稿日時 2024年12月10日 (火) 00時00分音楽, Mac, GarageBand, Advent Calendar, iMovie, DTM, Apple Silicon ARM64 | 固定リンク | 0 | コメント (0)

Apple Loopとチョップだけで頑張るGarageBand DTM 全部俺 Advent Calendar 2024　#9 - ネコっぽい効果音をリズムに絡める　その1

Apple Loopとチョップだけで頑張るGarageBand DTM 全部俺 Advent Calendar 2024
9日目の窓を開けました！

Layerを重ねてお腹いっぱいになったのでw、リズムにネコっぽい効果音を絡めて行こうと思います。（パーカッション的に使うイメージ）
猫の鳴き声ループをチョップしていい感じにできるかなぁ。
Apple Loopには、効果音として動物や生活音などいろいろな環境音もあるので、DTMにも使えるネタは結構あります。（以前作った曲で、どうしても真言宗のお経とか木魚の音を使おうとした時、適当なLoopがなくてフリーの音源を使わせてもらいましたが、オリジナルのサンプリング音をLoopライブラリへ追加して利用することもできます:)

Before

After

細かい作業風景は以下の動画で。最後に音を確認しています。
Apple Loopをそのまま利用するか、チョップして音単位で捨てたり、入れ替えたりするのは基本テクニックなので覚えちゃえば楽です。
ただ音毎に一括チョップする機能はないので、音毎にチョップするという地味な作業になってしまうわけですがw。（そのあたりはおまけでつけてくれているソフトウェアと有料版との差別化という感はありますねw）

Enjoy DTM, GarageBand and iMovie

では、また明日。

投稿日時 2024年12月 9日 (月) 00時00分音楽, Mac, GarageBand, Advent Calendar, iMovie, DTM, Apple Silicon ARM64 | 固定リンク | 0 | コメント (0)

Apple Loopとチョップだけで頑張るGarageBand DTM 全部俺 Advent Calendar 2024　#8 - Layer　どうしましょう　その4

Apple Loopとチョップだけで頑張るGarageBand DTM 全部俺 Advent Calendar 2024
8日目の窓を開けました！

欲張りすぎだろうか、気づかない程度にもう一つLayerを足したいw
（まだ追加するのかよ！〜w という感じですがw　追加しまっす！）

Before

After

こまけー作業は、これまで通りですが、一応、早送りの作業シーンと、最後に本日の音確認は以下。

Enjoy DTM, GarageBand and iMovie

では、また明日。

投稿日時 2024年12月 8日 (日) 00時00分音楽, Mac, GarageBand, Advent Calendar, iMovie, DTM, Apple Silicon ARM64 | 固定リンク | 0 | コメント (0)

Apple Loopとチョップだけで頑張るGarageBand DTM 全部俺 Advent Calendar 2024　#7 - Layer　どうしましょう　その3

Apple Loopとチョップだけで頑張るGarageBand DTM 全部俺 Advent Calendar 2024
7日目の窓を開けました！

まだ、重ねても良いかなぁ。wwww 気分というかそんな感じー、なので　：）

Before

After
もう一つLayerを追加した状態。雰囲気というかなんというか、めっちゃ変わったかというと。そうでもないですけども、このままでいきましょう。

細かい作業動画は以下にて。

Enjoy DTM, GarageBand and iMovie

では、また明日。

投稿日時 2024年12月 7日 (土) 00時00分音楽, Mac, GarageBand, Advent Calendar, iMovie, DTM, Apple Silicon ARM64 | 固定リンク | 0 | コメント (0)

Apple Loopとチョップだけで頑張るGarageBand DTM 全部俺 Advent Calendar 2024　#6 - Layer　どうしましょう　その2

Apple Loopとチョップだけで頑張るGarageBand DTM 全部俺 Advent Calendar 2024 6日目の窓を開けました！

昨日はLayerトラックを2つ追加しましたが、まだ物足りない気がしていて、もう一つLayer足してみますか。。と。

Before

Before_20241205064601

After こんな感じで、Night Vision Synth Layerが良さそうだったので追加した後の状態がこれ。

いつものように細かい作業風景は早送りも含め動画にて。動画の最後で今日追加したトラック含めた音の確認をしています。

Enjoy DTM, GarageBand and iMovie

では、また明日。

投稿日時 2024年12月 6日 (金) 00時00分音楽, Mac, GarageBand, Advent Calendar, iMovie, DTM, Apple Silicon ARM64 | 固定リンク | 0 | コメント (0)

Apple Loopとチョップだけで頑張るGarageBand DTM 全部俺 Advent Calendar 2024　#5 - Layer　どうしましょう　その1

Apple Loopとチョップだけで頑張るGarageBand DTM 全部俺 Advent Calendar 2024 5日目の窓を開けました！

昨日はざっくりBASSライン決めちゃいました。
今日は、このままだと寂しいので Layer をどうするか。というところ。
最初から最後まで裏でなってる感じトラック追加します。後でさらに足したり減らしたり試行錯誤すると思いますが。。とりあえず足していきますw

良さそうなのを見つけて、雑に置いてみるだけですけども（必要ならチョップして落としたりできますし）
手順はこれまで通り、メインとのラックを再生しつつ、良さそうなループを見つけたら同時に再生して確認。
よければそのままトラックに追加。
地味な作業の繰り返しです。

以上w

Before

After

オリジナルのループと+12半音高く調整したループの2トラックを追加しました。
Before_20241204072801

地味な作業の早送りあり、BGMあり、で最後に今日完成したところまでを聴いて、明日へ続く。
（日々聞ける感じで終わって次に繋げるので、いい感じのイテレーションでしょ？。その日のタスクは確実に実装してコミットするみたいな感じw、ゴールは Ver.2を完成させるところまで:)

Enjoy DTM, GarageBand and iMovie

では、また明日。

投稿日時 2024年12月 5日 (木) 00時00分音楽, Mac, GarageBand, Advent Calendar, iMovie, DTM, Apple Silicon ARM64 | 固定リンク | 0 | コメント (0)

Apple Loopとチョップだけで頑張るGarageBand DTM 全部俺 Advent Calendar 2024　#4 - BASSトラックどうしようその1

Apple Loopとチョップだけで頑張るGarageBand DTM 全部俺 Advent Calendar 2024 4日目の窓を開けました！

リズムセクションを固めないと次を決めにくいので、BASSトラックをざっくり決めちゃいましょう。
流れとしては、イントロ向けループを探して、試す、という地道なことの繰り返しで、イメージに近いループやなんとなくいいじゃん！、
というループを選んじゃいます。

そのまま使うこともあれば、後でチョップしたり、
一部だけ合うかなーというループはチョップして一部のみ使うとか、
色々ですね。決まりなんかないので。

Before BASSトラック追加前はこんな感じ

After 追加後はこんな感じ。今のところループの原型のまま置いているだけです（後半で、EQで調整したりチョップして音を入れ替えたり、落としたりするので今はオリジナルのまま）

いつものように作業風景を動画で。早送りや必要な部分では音の確認をしながら進めています。

Enjoy DTM, GarageBand and iMovie

では、また明日。

投稿日時 2024年12月 4日 (水) 00時00分音楽, Mac, GarageBand, Advent Calendar, iMovie, DTM, Apple Silicon ARM64 | 固定リンク | 0 | コメント (0)

Apple Loopとチョップだけで頑張るGarageBand DTM 全部俺 Advent Calendar 2024　#3 - イントロその1

Apple Loopとチョップだけで頑張るGarageBand DTM 全部俺 Advent Calendar 2024
3日目の窓を開けました！

多分、ここ使わん！というトラックをバッサリ削除したのが前回。
今日は、イントロのトラックを追加していく、その１（毎回悩みますw）

ちょい重めwのイントロ（全バージョンが軽めだったのでw）を選んで２トラック追加。

イントロトラック追加前

イントロトラック追加後
Swelling Sub Bass
Transport Stop Synth
という2つのループをそのまま（音の調整は最後にするのでとりあえず置くだけ）

作業風景w 早送りあり、最後にAfterの状態の音を確認！

Enjoy DTM, GarageBand and iMovie

では、また明日。

投稿日時 2024年12月 3日 (火) 00時00分音楽, Mac, GarageBand, Advent Calendar, iMovie, DTM, Apple Silicon ARM64 | 固定リンク | 0 | コメント (0)

Apple Loopとチョップだけで頑張るGarageBand DTM 全部俺 Advent Calendar 2024　#2 - メジャーバージョンアップするための取捨選択

Apple Loopとチョップだけで頑張るGarageBand DTM 全部俺 Advent Calendar 2024
2日目の窓を開けました！

さて、対象が決まったので、どう変えていくかですが、
もとのトラックで、ん〜。いらないかなぁ〜と思うトラックをいくつか落としてベースになるトラックだけ残すことを今日の目標にしますねw
そもそもどうするかも決まってないわけですがw

Before

After

作業風景w 早送りあり、最後にAfterの状態の音を確認！

Enjoy DTM, GarageBand and iMovie

では、また明日。

投稿日時 2024年12月 2日 (月) 00時00分音楽, Mac, GarageBand, Advent Calendar, iMovie, DTM, Apple Silicon ARM64 | 固定リンク | 0 | コメント (0)

Apple Loopとチョップだけで頑張るGarageBand DTM 全部俺 Advent Calendar 2024　#1

Apple Loopとチョップだけで頑張るGarageBand DTM 全部俺 Advent Calendar 2024
1日目の窓を開けました

一度やってみたかった、GarageBand Advent Calendar しかも全部俺で。

GarageBandなどで提供されているApple Loop、これだけを使い、打ち込み、MIDI入力もなし、サンプリングもなし（無料のお経のサンプリング音は一度利用した）でApple Loopをチョップして頑張るシリーズを初めて2年ほど。
以前からやろうと思っていた GarageBand Advent Calendar　全部俺。ついにその重い腰を上げw

で、一から作るのも大変なだったので、
昨年作ったLoopをメジャーアップデートする過程を25回に分けで書こうと思います。
元ネタは昨年思いつきで作って放置していたもので、Version 2というか2024年版へアップデート。

まずは、オリジナルはどうだったのか？、というところから。
これをどう変えていくか、それが問題だw
NecoというかNekoな。

Neco Mimi Loops / N + 1 Loops - GarageBand Edit

Enjoy DTM and GarageBand!

では、また明日。
25日間続けられるのか。。。。

投稿日時 2024年12月 1日 (日) 00時00分音楽, Mac, GarageBand, Advent Calendar, iMovie, DTM, AppleLoops, Apple Silicon ARM64 | 固定リンク | 0 | コメント (0)

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回目）

投稿日時 2023年12月22日 (金) 00時00分チューニング, SQL, PostgreSQL, パフォーマンス, Advent Calendar | 固定リンク | 0 | コメント (0)

帰ってきた！標準はあるにはあるが癖の多い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

投稿日時 2023年12月17日 (日) 00時00分 Oracle, チューニング, SQL, MySQL, PostgreSQL, JPOUG, パフォーマンス, Advent Calendar | 固定リンク | 0 | コメント (0)

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

予定外ですが、Advent Calendarのシーズンついでなので、空いていた以下のアドベントカレンダー向けエントリーとなります。
Kernel/VM Advent Calendar 2023 / Day 13

macOS / ARM64 Beta development revision 160702
https://www.virtualbox.org/wiki/Testbuilds

以前、Oracle Linux 8 and MySQL 8.0.32 on VirtualBox for Apple Silicon Test Build 7.0.97_BETA5r160167で、MySQL 8.0.32が起動した！と言うことを書きましたが、その後のBETAリリースではOS起動中にクラッシュしていました。
で、今回は、development revision 160702をダメもとで試してみました。

結果から書くと、色々もっさりしているのは仕方ないかないところですが、このrevisionでは、MySQLに加えて、PostgreSQLも起動しました！！！

VirtualBox for Apple Silicon Test Build 7.0.97_BETA5r160702
GuestOS : Oracle Linux Server release 8.5
MySQL 8.0.32 - 起動した！
PostgreSQL 13.4 - 起動した！
Oracle database 21c - 起動せず！

試した内容は前回と同じですが、Oracleについては変えています。
1) Oracle Linux 8.5 に、PostgreSQL 13.4 と MySQL 8.0.32 を構成したVMをエクスポートして ova 作成
2) 1)のOracle Linux 8.5 に、Oracle Database 21cを構成したものを ova としてエクスポート。
それぞれをVirtualBoxへインポートして検証しました。

ちなみに、
Oracle Linux 7.6のPre-Built Developer VMs (for Oracle VM VirtualBox) および、Oracle Linux 8.6に構築したOracle 23c Freeは、OS起動にクラッシュしていたので、うまく起動した1)を利用して、OS起動後にOracleの挙動を確認する方法にしましたが、Oracleがコケたと言う結果となりました。

Test Buildは、結構進んできているようで、今後が楽しみです ;)

では、また。

投稿日時 2023年12月13日 (水) 17時05分 Oracle, Linux, VirtualBox, MySQL, PostgreSQL, Advent Calendar, Apple Silicon ARM64 | 固定リンク | 0 | コメント (0)

帰ってきた！標準はあるにはあるが癖の多い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向けの準備運動的な予習（その３）はここまで。

では、また。

投稿日時 2023年12月10日 (日) 11時25分 Oracle, チューニング, SQL, MySQL, PostgreSQL, パフォーマンス, Advent Calendar | 固定リンク | 0 | コメント (0)

帰ってきた！標準はあるにはあるが癖の多い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"

予習、その３へ続く。

では、また。:)

投稿日時 2023年12月 9日 (土) 00時00分 Oracle, チューニング, SQL, MySQL, PostgreSQL, パフォーマンス, Advent Calendar | 固定リンク | 0 | コメント (0)

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

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

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

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

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

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

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

10001行が選択されました. 

経過: 00:00:01.41

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

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

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

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

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


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

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

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

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

 ...略...

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

 ...略...

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

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

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

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

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

10001行が選択されました. 

経過: 00:00:01.28

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

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

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

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

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


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

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

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

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

 ...略...

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

 ...略...

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

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

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

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

表が削除されました. 

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

表が作成されました. 

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

表が削除されました. 

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

表が作成されました. 

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

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

経過: 00:04:37.66

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

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

1000001行が選択されました. 

経過: 00:02:23.03

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

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

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

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

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


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

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

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

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

 ...略...

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

 ...略...

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

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

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

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

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

1000001行が選択されました. 

経過: 00:02:24.20

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

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

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

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

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


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

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

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

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

 ...略...

 Duration            :  223s

 ...略...

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

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

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

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

...略...

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

...略...

tmpfs               tmpfs      9.3G     0  9.3G    0% /oratemp

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

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

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

SYS@orclpdb1> alter user scott temporary tablespace hogetemp;

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

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

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

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

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

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

...略...

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

...略...

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

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

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

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

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

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

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

...略...

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

...略...

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

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

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

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

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

では, また.

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

実行計画は, 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ネタとしては, 今年はここまで）　また来年お会いしましょう. みなさん, 良いお年を！

投稿日時 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)

実行計画は, 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!

ではまた ;)

投稿日時 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)

実行計画は, 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

では, アドベントカレンダー最終日の担当も, 私です.

ではまた.

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

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

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

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

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

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

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

参考）

Oracle Database 21c SQL Tuning Guide / 9.3.4 Antijoins

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

SCOTT@orclpdb1> select banner from v$version;

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

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

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

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

...略...

          240 Government Sales
          250 Retail Sales
          260 Recruiting
          270 Payroll

16行が選択されました. 

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

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

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

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

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

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

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

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

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

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

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

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

SCOTT@orclpdb1> @day23

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

...略...

     7369 SMITH
     7566 JONES
     7902 FORD

12行が選択されました. 

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

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

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

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

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

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

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

...略...

      7369 SMITH
      7566 JONES
      7902 FORD

12行が選択されました. 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

残り2日だ.

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

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

実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 22 / No.57 / Subquery Unnesting

Previously on Mac De Oracle...

Day 21は, INLIST ITERATOR と Sub Query と STATISTICS COLLECTORを取り上げました. 古くからあるOperationを最適化する比較的新しい機能ですね. とはいえ, 現場で見たことない！　なんていうのは多そうではあります.

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

昨日の記事でちょっとだけ話題にした, Subquery Unnesting なので, Subquery Unnestingの代表的な3例を診ておきましょう.

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

SCOTT@orclpdb1> select banner from v$version;

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

まず, これも通常は, SQLを書き換えないと対応タイプですが, Oracleは結合に書き換えてくれます. 大量にデータを返すのに, スカラー副問い合わせが使われていて辛かった経験って一度ぐらいはありそうですね.
（私も過去一度だけこいつのチューニングしたことがありますが, 当時はスカラー副問い合わせをUnnestingできなかったので, SQLをOUTER JOINに書き換えてもらいました！）

以下の例では, スカラー副問い合わせが, OUTER JOINかつ, このケースではMERGE JOINに書き換えられています.

SCOTT@orclpdb1> @day22
  1  SELECT
  2    deptno
  3    ,dname
  4    ,(
  5       SELECT
  6          MAX(sal)
  7       FROM
  8          emp
  9       WHERE
 10          emp.deptno=dept.deptno
 11    ) AS max_sal
 12  FROM
 13    dept
 14  ORDER BY
 15*   deptno

    DEPTNO DNAME                                         MAX_SAL
---------- ------------------------------------------ ----------
        10 ACCOUNTING                                       5000
        20 RESEARCH                                         3000
        30 SALES                                            2850
        40 OPERATIONS

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

-----------------------------------------------------------------------------------------
| Id  | Operation                    | Name     | Rows  | Bytes | Cost (%CPU)| Time     |
-----------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT             |          |     4 |   116 |     7  (29)| 00:00:01 |
|   1 |  MERGE JOIN OUTER            |          |     4 |   116 |     7  (29)| 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 JOIN                  |          |     3 |    48 |     5  (40)| 00:00:01 |
|   5 |    VIEW                      | VW_SSQ_1 |     3 |    48 |     4  (25)| 00:00:01 |
|   6 |     HASH GROUP BY            |          |     3 |    21 |     4  (25)| 00:00:01 |
|   7 |      TABLE ACCESS FULL       | EMP      |    12 |    84 |     3   (0)| 00:00:01 |
-----------------------------------------------------------------------------------------

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

   4 - access("ITEM_1"(+)="DEPT"."DEPTNO")
       filter("ITEM_1"(+)="DEPT"."DEPTNO")

では, Scalar Subquery Unnestingされなかった場合はどう見えるでしょうか？（これが, SELECTリストで利用されたScalar subqueryの実行計画です. NO_UNNESTヒントで抑止します.
スカラーサブクエリーが実行計画の最初に現れるのが特徴です（Oracleの場合）

以下の例では, dept表の行数分, Nested Loop Joinのように, emp表へのアクセスが繰り返し実行されます. なので, 行数が多い場合は, HASH JOINなどに書き換えた方が効率が良いわけです. Scalar Subquery UnnestingはそれをOracleが内部的に実施してくれている便利な機能なんですよ.

  1  SELECT
  2    deptno
  3    ,dname
  4    ,(
  5       SELECT
  6          /*+
  7            NO_UNNEST
  8          */
  9          MAX(sal)
 10       FROM
 11          emp
 12       WHERE
 13          emp.deptno=dept.deptno
 14    ) AS max_sal
 15  FROM
 16    dept
 17  ORDER BY
 18*   deptno

    DEPTNO DNAME                                         MAX_SAL
---------- ------------------------------------------ ----------
        10 ACCOUNTING                                       5000
        20 RESEARCH                                         3000
        30 SALES                                            2850
        40 OPERATIONS

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

------------------------------------------------------------------------------------------------
| Id  | Operation                            | Name    | Rows  | Bytes | Cost (%CPU)| Time     |
------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                     |         |     4 |    52 |     8   (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_EMP  |     4 |       |     1   (0)| 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 |
------------------------------------------------------------------------------------------------

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

   3 - access("EMP"."DEPTNO"=:B1)

次は, IN条件内のサブクエリーがUnnestingされた例です.
相関関係のないIN副問合せや, IN(集計ファンクションまたはGROUP BY句を含まない場合)に書き換えるとされています. この例は, 相関関係のない副問合せにしてあります. IN LIST ITERATION等ではなく, SubqueryがUnnestingされ, Nested Loop Joinに書き換えられています！

  1  SELECT
  2    deptno
  3    ,dname
  4  FROM
  5    dept
  6  WHERE
  7    deptno IN (
  8      SELECT
  9        deptno
 10      FROM
 11        emp
 12      WHERE
 13        sal < 1000
 14    )
 15  ORDER BY
 16*   deptno

    DEPTNO DNAME
---------- ------------------------------------------
        20 RESEARCH
        30 SALES

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

------------------------------------------------------------------------------------------
| Id  | Operation                      | Name    | Rows  | Bytes | Cost (%CPU)| Time     |
------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT               |         |     1 |    20 |     4  (25)| 00:00:01 |
|   1 |  NESTED LOOPS                  |         |     1 |    20 |     4  (25)| 00:00:01 |
|   2 |   NESTED LOOPS                 |         |     1 |    20 |     4  (25)| 00:00:01 |
|   3 |    SORT UNIQUE                 |         |     1 |     7 |     2   (0)| 00:00:01 |
|*  4 |     TABLE ACCESS BY INDEX ROWID| EMP     |     1 |     7 |     2   (0)| 00:00:01 |
|   5 |      INDEX FULL SCAN           | IX_EMP  |    12 |       |     1   (0)| 00:00:01 |
|*  6 |    INDEX UNIQUE SCAN           | PK_DEPT |     1 |       |     0   (0)| 00:00:01 |
|   7 |   TABLE ACCESS BY INDEX ROWID  | DEPT    |     1 |    13 |     1   (0)| 00:00:01 |
------------------------------------------------------------------------------------------

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

   4 - filter("SAL"<1000)
   6 - access("DEPTNO"="DEPTNO")

IN条件のSubqueryのUnnestingをNO_UNNESTヒントで抑止すると元の実行計画という名のレントゲンが現れてきます.
Unnestingが抑止されたことで, 結合ではなくFILTER条件(EXISTS書き換えられ)になっていることがわかりますよね. どちらの実行計画が有利にかは状況次第ですが, 以前も書いたように, 最近の傾向では, 積極的にUnnestingしているように感じています.

  1  SELECT
  2    deptno
  3    ,dname
  4  FROM
  5    dept
  6  WHERE
  7    deptno IN (
  8      SELECT
  9        /*+
 10          NO_UNNEST
 11        */
 12        deptno
 13      FROM
 14        emp
 15      WHERE
 16        sal < 1000
 17    )
 18  ORDER BY
 19*   deptno

    DEPTNO DNAME
---------- ------------------------------------------
        20 RESEARCH
        30 SALES

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

-------------------------------------------------------------------------------------------------
| Id  | Operation                             | Name    | Rows  | Bytes | Cost (%CPU)| Time     |
-------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                      |         |     1 |    13 |     8   (0)| 00:00:01 |
|   1 |  TABLE ACCESS BY INDEX ROWID          | DEPT    |     4 |    52 |     2   (0)| 00:00:01 |
|*  2 |   INDEX FULL SCAN                     | PK_DEPT |     4 |       |     1   (0)| 00:00:01 |
|*  3 |    TABLE ACCESS BY INDEX ROWID BATCHED| EMP     |     1 |     7 |     2   (0)| 00:00:01 |
|*  4 |     INDEX RANGE SCAN                  | IX_EMP  |     4 |       |     1   (0)| 00:00:01 |
-------------------------------------------------------------------------------------------------

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

   2 - filter( EXISTS (SELECT /*+ NO_UNNEST */ 0 FROM "EMP" "EMP" WHERE "DEPTNO"=:B1 AND
              "SAL"<1000))
   3 - filter("SAL"<1000)
   4 - access("DEPTNO"=:B1)

最後は, EXISTS演算子内のサブクエリーがUnnestingされた例ですよー. こちらも同じようにUnnestingは積極的に行われているように思います. 私が関わった範囲ですけども.
なお, 書き換え条件として, EXISTS相関副問合せ(集計ファンクションまたはGROUP BY句を含まない場合)となっています. 以下の例でも, 集計ファンクション, GROUP BYを含まない相関服問い合わせにしてあります.

  1  SELECT
  2    deptno
  3    ,dname
  4  FROM
  5    dept
  6  WHERE
  7    EXISTS (
  8      SELECT
  9        1
 10      FROM
 11        emp
 12      WHERE
 13        sal < 1000
 14        AND emp.deptno = dept.deptno
 15    )
 16  ORDER BY
 17*   deptno

    DEPTNO DNAME
---------- ------------------------------------------
        20 RESEARCH
        30 SALES

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

------------------------------------------------------------------------------------------
| Id  | Operation                      | Name    | Rows  | Bytes | Cost (%CPU)| Time     |
------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT               |         |     1 |    20 |     4  (25)| 00:00:01 |
|   1 |  NESTED LOOPS                  |         |     1 |    20 |     4  (25)| 00:00:01 |
|   2 |   NESTED LOOPS                 |         |     1 |    20 |     4  (25)| 00:00:01 |
|   3 |    SORT UNIQUE                 |         |     1 |     7 |     2   (0)| 00:00:01 |
|*  4 |     TABLE ACCESS BY INDEX ROWID| EMP     |     1 |     7 |     2   (0)| 00:00:01 |
|   5 |      INDEX FULL SCAN           | IX_EMP  |    12 |       |     1   (0)| 00:00:01 |
|*  6 |    INDEX UNIQUE SCAN           | PK_DEPT |     1 |       |     0   (0)| 00:00:01 |
|   7 |   TABLE ACCESS BY INDEX ROWID  | DEPT    |     1 |    13 |     1   (0)| 00:00:01 |
------------------------------------------------------------------------------------------

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

   4 - filter("SAL"<1000)
   6 - access("EMP"."DEPTNO"="DEPT"."DEPTNO")

NO_UNNESTヒントでUnnestingを抑止してもとの実行計画を覗いています！
Plan hash valueを見ると, なんと, IN条件のNO_UNNESTヒントを付加した実行計画と同じに！

  1  SELECT
  2    deptno
  3    ,dname
  4  FROM
  5    dept
  6  WHERE
  7    EXISTS (
  8      SELECT
  9        /*+
 10          NO_UNNEST
 11        */
 12        1
 13      FROM
 14        emp
 15      WHERE
 16        sal < 1000
 17        AND emp.deptno = dept.deptno
 18    )
 19  ORDER BY
 20*   deptno

    DEPTNO DNAME
---------- ------------------------------------------
        20 RESEARCH
        30 SALES

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

-------------------------------------------------------------------------------------------------
| Id  | Operation                             | Name    | Rows  | Bytes | Cost (%CPU)| Time     |
-------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                      |         |     1 |    13 |     8   (0)| 00:00:01 |
|   1 |  TABLE ACCESS BY INDEX ROWID          | DEPT    |     4 |    52 |     2   (0)| 00:00:01 |
|*  2 |   INDEX FULL SCAN                     | PK_DEPT |     4 |       |     1   (0)| 00:00:01 |
|*  3 |    TABLE ACCESS BY INDEX ROWID BATCHED| EMP     |     1 |     7 |     2   (0)| 00:00:01 |
|*  4 |     INDEX RANGE SCAN                  | IX_EMP  |     4 |       |     1   (0)| 00:00:01 |
-------------------------------------------------------------------------------------------------

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

   2 - filter( EXISTS (SELECT /*+ NO_UNNEST */ 0 FROM "EMP" "EMP" WHERE
              "EMP"."DEPTNO"=:B1 AND "SAL"<1000))
   3 - filter("SAL"<1000)
   4 - access("EMP"."DEPTNO"=:B1)

ということで, 残り3日まで窓を開けました-　；）

安心して, 寝坊しないようにしないと.

ではまた.

参考）
Oracle Database 21c SQL Language Reference / Unnesting of Nested Subqueries

投稿日時 2022年12月22日 (木) 00時00分 Oracle, Oracle Database 12c release 1, Advent Calendar, Oracle Database 12c Release 2, Oracle Database 18c, Oracle Database 19c, Oracle Database 21c | 固定リンク | 0 | コメント (0)

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

Previously on Mac De Oracle...

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

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

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

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

SCOTT@orclpdb1> select banner from v$version;

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

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

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

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

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

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

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

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

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

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

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

6行が選択されました. 

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

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

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

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

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

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

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

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

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

Plan hash value: 4207756064

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

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

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

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

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

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

では, また　:)

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

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

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

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

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

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

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

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

SCOTT@orclpdb1> select banner from v$version;

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

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

SCOTT@orclpdb1> @day20
  1* DROP TABLE business_day_calendar

表が削除されました。

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

表が作成されました。

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

表が変更されました。

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

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

  1  SELECT
  2    DISTINCT business_date
  3  FROM
  4*   business_day_calendar

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

...略...

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

365行が選択されました。

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

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

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

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

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

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

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

...略...

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

365行が選択されました。

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

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

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

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

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

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

...略...

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

365行が選択されました。

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

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

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

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

  1* DROP TABLE case2

表が削除されました。

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

表が作成されました。

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

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

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

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

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

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

...略...

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

2000行が選択されました。

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

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

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

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

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

...略...

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

2000行が選択されました。

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

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

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

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

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

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

1行が作成されました。

  1* COMMIT

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

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

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

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

...略...

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

...略...

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

2001行が選択されました。

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

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

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

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

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

実行計画は, 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

投稿日時 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)

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

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

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

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

SCOTT@orclpdb1> select banner from v$version;

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

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

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

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

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

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

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

...略...

      2396
      2397
      2398
      2399

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

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

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

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

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

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

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

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

...略...

      2392
      2393
      2394
      2395
      2396
      2397
      2398
      2399

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

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

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

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

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

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

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

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

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

実行計画は, 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

ということで, 残念ですが, 明日も私です.
ではまた.

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

実行計画は, 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

投稿日時 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)

実行計画は, 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年ほど前, クエリー分裂症の治療の様子を見たい方はこちらのスライド見てね. :)

ということで, 明日も私です:)

投稿日時 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)

実行計画は, 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
バテ気味な感じが, しつつも, 明日も私が担当します！
では, また.

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

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

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

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

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

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

SCOTT@orclpdb1> select banner from v$version;

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

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

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

2行が作成されました.

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

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

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

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

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

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

ではでは.

Related article on Mac De Oracle

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

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

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

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

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

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

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

SCOTT@orclpdb1> select banner from v$version;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

それはさておき.

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

ではまた.

参考）

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

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

Related article on Mac De Oracle

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

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

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

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

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

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

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

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

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

SCOTT@orclpdb1> @day11
  1* drop table test1

表が削除されました. 

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

表が作成されました. 

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

表が削除されました. 

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

表が作成されました. 

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

表が削除されました. 

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

表が作成されました. 

経過: 00:00:00.05

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

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

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

経過: 00:00:00.03

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

経過: 00:00:00.01

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

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

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

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

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

  13 -  SEL$80FD2AB9
         U -  NO_MERGE

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

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

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

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

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

経過: 00:00:00.02

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

経過: 00:00:00.01

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

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

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

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

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

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

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

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

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

経過: 00:00:00.01

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

経過: 00:00:00.00

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

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

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

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

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

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

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

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

では, また.

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

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

実行計画は, 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

投稿日時 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)

実行計画は, 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　はい.

投稿日時 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)

実行計画は, 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　（全部俺）

投稿日時 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)

実行計画は, 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

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

実行計画は, 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

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

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

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

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

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

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

SCOTT@orclpdb1> select banner from v$version;

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

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

SCOTT@orclpdb1> @day5

表が削除されました. 

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

表が作成されました. 

  1* CREATE INDEX ix_for_pivot ON for_pivot(stat_name)

索引が作成されました. 

  1  SELECT
  2    *
  3  FROM
  4*   for_pivot

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

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

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

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

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


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

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

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

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

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

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

表が削除されました. 

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

表が作成されました. 

  1* COMMIT

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

  1  SELECT
  2    *
  3  FROM
  4*   for_unpivot

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

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

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

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

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

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

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

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

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

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

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

参考 SQL Language Reference / PIVOT and UNPIVOT

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

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

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

実行計画は, 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

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

実行計画は, 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

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

実行計画は, 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

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

実行計画は, 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句を付加していませんが、付けてくださいよ。ソートが必要な場合は！！！！

今回の例ではたまたま昇順に並んでいるだけですからね。

帰ってきた！　実行計画は、SQL文のレントゲン写真だ！　Oracle Database (全部俺） Advent Calendar 2022

Oracle Databaseの実行計画を中心にしていますが、他のDatabaseの実行計画も合わせて載せるかもしれません。

基本的に、全部俺で予定していますが、どうーーーしても、どうーーーしても、俺、私にも書かせろ！

という方は、ご連絡ください。:)

投稿日時 2022年11月10日 (木) 07時06分 Oracle, SQL, パフォーマンス, Advent Calendar | 固定リンク | 0 | コメント (0)

誰がどんな名前のペットを飼っているのかな？解答編 / 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)

誰がどんな名前のペットを飼っているのかな？その１ / JPOUG Advent Calendar Day 1

今年も師走の風物詩、JPOUGアドベントカレンダーがはじまりましたー。2021も残すところ１ヶ月。来年も元気にOnline, In personでお会いしたいですね！

前置きはごれぐらいにして、

今回の私のエントリー、Oracleというかデータベース使う必要はないのですが、RDBMSというかSQLで解けるじゃん、この問題！　
ということで、中二の期末試験で「時間があったらチャレンジしてね！」という問題をネタにしてみました。

なお、本エントリーと、12/23日のエントリーの二部構成にして、本エントリーではネタ振りのみです!w

SQLがからんでいればどうやって解いても良いと思っています。冬の夜長に、ワイン片手に、頭の体操するのもよいのではないでしょうか？　
皆さんも考えてみてくださいね。

この問題、中学二年の数学のおまけの問題なので、紙と鉛筆、頭の良い方は、頭の中だけでも解けるわけですがw 　
あえて、SQLで頑張ってみましょうw

問題は以下の通り。

Hiro, Larry, Scott, Steveは、Cat, Dog, Snake, Turtleのうち、どれか 1 種類のペットを飼っています。同じ種類のペットおよび、同じ名前のペットを飼っている人はいません。 4 人のペットの名前は、Lisa, Taro, TIger, Wendyのいずれかです。

Hiro　:「僕が飼っているのは、Tiger だよ。 Turtle じゃないよ」
Larry : 「Snake の名前は、Lisa じゃないよ」
Scott : 「僕は Snake を飼っているよ」
Steve : 「Dog の名前は Wendy だよ。僕は Dog はかってないけど」

誰がどんな名前のペットを飼っているのかな？

答え合せは12/23の窓で行う予定です。

みなさん、お好きな方法で解いてみてください。。 :)

ちなみに、私は、愚直な方法でw　答えを導きだすつもりです。　みなさんは、よりスマートな方法を考えてみるのもおもしろいかもしれませんね！

答えではないですが、私がパッと考えている脳内イメージをアウトプットしておきます。（私のイメージにこだわる必要はないので、みなさんは自由な発想で取り組んでいただければと思います）

問題から、ざっくりとエンティティをイメージしてみると３つ。

ペットのオーナー
ペットの名前
動物の種類

ただ、これだと、多：多の関係になってしまうので、関連エンティティぐらいは作ったほうが無難ですよね。そのままデカルト演算して答えを導きだすツワモノもいるかもしれませんがw　

で、関連エンティティをこれまた、ざっくりイメージしてみると、こちらも3つありそうですよね。問題文をよーく読み込んでみてください。3つ見えますよー。

「ペットのオーナー」と「ペットの名前」を関連づけるエンティティ
「ペットの名前」と「動物の種類」を関連づけるエンティティ
「ペットのオーナー」と「動物の種類」を関連づけるエンティティ

こんな感じ、で6つのエンティティが浮かんだのですが、みなさんはどうみえますか？

少々悩んだののですが、この問題を解くために、後半の3つのエンティティを表で実装するか、ビューで実装するかってところもあるかなぁと。表にしなくてもビューでもいいかーと。

ということで、私は、以下を3表を元に、

ペットのオーナー
ペットの名前
動物の種類

関連は、以下の3つのビューで実装してみようかなーと。（妄想中）

「ペットのオーナー」と「ペットの名前」を関連づけるビュー
「ペットの名前」と「動物の種類」を関連づけるビュー
「ペットのオーナー」と「動物の種類」を関連づけるビュー

3つの表と3つのビューを駆使してw　SQLだけで、愚直に、解く予定ですw

なお、元になる3エンティティに対応した表のDDLとデータは以下のような感じで。

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

では、12/23の答え合せまで、みなさんも、ワイングラス片手に、（お酒が苦手な方はウィルキンソンでもw）自由にあそんでみてください :)

明日は、12/2、二つ目の窓は、渡部さんです。お楽しみにーっ。

投稿日時 2021年12月 1日 (水) 00時00分 Oracle, Oracle以外のデータベース, JPOUG, Advent Calendar | 固定リンク | 0 | コメント (0)

標準はあるにはあるが癖の多い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

投稿日時 2020年12月26日 (土) 00時00分 Oracle, FAQ, SQL, MySQL, PostgreSQL, Advent Calendar | 固定リンク | 0 | コメント (0)

標準はあるにはあるが癖の多い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のムービーで）

投稿日時 2020年12月25日 (金) 00時00分 Oracle, FAQ, SQL, MySQL, PostgreSQL, Advent Calendar, AWS | 固定リンク | 0 | コメント (0)

標準はあるにはあるが癖の多い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

投稿日時 2020年12月24日 (木) 00時00分 Oracle, FAQ, SQL, MySQL, PostgreSQL, Advent Calendar | 固定リンク | 0 | コメント (0)

標準はあるにはあるが癖の多い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）

投稿日時 2020年12月23日 (水) 00時00分 Oracle, FAQ, SQL, MySQL, PostgreSQL, Advent Calendar | 固定リンク | 0 | コメント (0)

標準はあるにはあるが癖の多い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

投稿日時 2020年12月22日 (火) 00時00分 Oracle, FAQ, SQL, MySQL, PostgreSQL, Advent Calendar | 固定リンク | 0 | コメント (0)

標準はあるにはあるが癖の多い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)

あと少し :)

投稿日時 2020年12月21日 (月) 04時02分 Oracle, FAQ, SQL, MySQL, PostgreSQL, Advent Calendar | 固定リンク | 0 | コメント (0)

標準はあるにはあるが癖の多い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　よろしくおねがいします！

投稿日時 2020年12月20日 (日) 00時00分 Oracle, FAQ, SQL, MySQL, PostgreSQL, Advent Calendar | 固定リンク | 0 | コメント (0)

標準はあるにはあるが癖の多い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　(^^;;;;;

投稿日時 2020年12月19日 (土) 16時46分 Oracle, FAQ, SQL, MySQL, PostgreSQL, Advent Calendar, AWS | 固定リンク | 0 | コメント (0)

標準はあるにはあるが癖の多い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　(^^;;;;;

投稿日時 2020年12月18日 (金) 22時36分 Oracle, FAQ, SQL, MySQL, PostgreSQL, Advent Calendar, AWS | 固定リンク | 0 | コメント (0)

標準はあるにはあるが癖の多い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

投稿日時 2020年12月17日 (木) 19時52分 Oracle, FAQ, SQL, MySQL, PostgreSQL, Advent Calendar, AWS | 固定リンク | 0 | コメント (0)

標準はあるにはあるが癖の多い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

投稿日時 2020年12月16日 (水) 00時00分 Oracle, FAQ, SQL, MySQL, PostgreSQL, Advent Calendar | 固定リンク | 0 | コメント (0)

標準はあるにはあるが癖の多い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そのものではないけど、重要なはず。

投稿日時 2020年12月15日 (火) 11時53分 Oracle, FAQ, SQL, MySQL, PostgreSQL, Advent Calendar | 固定リンク | 0 | コメント (0)

標準はあるにはあるが癖の多い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)

ということで、今日は、役に立つような立たないような、でも何かの役に立ちそうなネタにしてみました。:)

投稿日時 2020年12月14日 (月) 01時18分 FAQ, SQL, Opera, MySQL, PostgreSQL, Advent Calendar | 固定リンク | 0 | コメント (0)

標準はあるにはあるが癖の多い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

投稿日時 2020年12月13日 (日) 03時10分 Oracle, FAQ, SQL, MySQL, PostgreSQL, Advent Calendar, AWS | 固定リンク | 0 | コメント (0)

標準はあるにはあるが癖の多い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

投稿日時 2020年12月12日 (土) 06時14分 Oracle, FAQ, SQL, MySQL, PostgreSQL, Advent Calendar, AWS | 固定リンク | 0 | コメント (0)

標準はあるにはあるが癖の多い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

投稿日時 2020年12月11日 (金) 00時00分 Oracle, FAQ, SQL, MySQL, PostgreSQL, Advent Calendar, AWS | 固定リンク | 0 | コメント (1)

標準はあるにはあるが癖の多い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

投稿日時 2020年12月10日 (木) 00時00分 Oracle, FAQ, SQL, MySQL, PostgreSQL, Advent Calendar, NULL | 固定リンク | 0 | コメント (0)

標準はあるにはあるが癖の多い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

投稿日時 2020年12月 9日 (水) 00時00分 Oracle, SQL, MySQL, PostgreSQL, Advent Calendar | 固定リンク | 0 | コメント (0)

標準はあるにはあるが癖の多い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)

標準はあるにはあるが癖の多い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)

標準はあるにはあるが癖の多い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)

標準はあるにはあるが癖の多い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)

標準はあるにはあるが癖の多い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)

実行計画は、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つかくかも

投稿日時 2019年12月28日 (土) 23時00分 Oracle, チューニング, SQL, Advent Calendar | 固定リンク | 0 | コメント (0)

実行計画は、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 をよろしくお願いいたします。

では、皆様、メリークリスマス、そして、良いお年をお迎えください。

投稿日時 2019年12月25日 (水) 02時10分 Oracle, チューニング, SQL, イベント, Advent Calendar | 固定リンク | 0 | コメント (0)

実行計画は、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 へつづく

投稿日時 2019年12月24日 (火) 00時00分 Oracle, チューニング, SQL, イベント, Advent Calendar | 固定リンク | 0 | コメント (0)

実行計画は、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 へつづく

投稿日時 2019年12月23日 (月) 00時00分 Oracle, チューニング, SQL, イベント, Advent Calendar | 固定リンク | 0 | コメント (0)

実行計画は、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 へつづく

投稿日時 2019年12月22日 (日) 00時00分 Oracle, チューニング, SQL, イベント, Advent Calendar | 固定リンク | 0 | コメント (0)

実行計画は、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 へつづく

投稿日時 2019年12月21日 (土) 00時00分 Oracle, チューニング, SQL, イベント, Advent Calendar | 固定リンク | 0 | コメント (0)

実行計画は、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 へつづく

投稿日時 2019年12月20日 (金) 00時00分 Oracle, チューニング, SQL, イベント, Advent Calendar | 固定リンク | 0 | コメント (0)

実行計画は、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 へつづく

投稿日時 2019年12月19日 (木) 00時00分 Oracle, チューニング, SQL, イベント, Advent Calendar | 固定リンク | 0 | コメント (0)

実行計画は、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書き換えという手術が必要なのか判断できるポイントになるからです!!!

たいせつなので二度書きました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 へつづく

投稿日時 2019年12月18日 (水) 00時00分 Oracle, チューニング, SQL, イベント, Advent Calendar | 固定リンク | 0 | コメント (0)

実行計画は、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 へつづく

投稿日時 2019年12月17日 (火) 00時00分 Oracle, チューニング, SQL, イベント, JPOUG, Advent Calendar | 固定リンク | 0 | コメント (0)

実行計画は、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 へつづく

投稿日時 2019年12月16日 (月) 00時00分 Oracle, チューニング, SQL, イベント, Advent Calendar | 固定リンク | 0 | コメント (0)

実行計画は、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 へつづく

投稿日時 2019年12月15日 (日) 00時00分 Oracle, チューニング, SQL, イベント, Advent Calendar | 固定リンク | 0 | コメント (0)

実行計画は、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 へつづく

投稿日時 2019年12月14日 (土) 00時00分 Oracle, チューニング, SQL, イベント, Advent Calendar | 固定リンク | 0 | コメント (0)

実行計画は、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 へつづく

投稿日時 2019年12月13日 (金) 00時00分 Oracle, チューニング, SQL, イベント, Advent Calendar | 固定リンク | 0 | コメント (0)

実行計画は、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 へつづく

投稿日時 2019年12月12日 (木) 00時00分 Oracle, チューニング, SQL, イベント, Advent Calendar | 固定リンク | 0 | コメント (0)

実行計画は、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 へつづく

投稿日時 2019年12月11日 (水) 00時00分 Oracle, チューニング, SQL, イベント, Advent Calendar | 固定リンク | 0 | コメント (0)

実行計画は、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 へつづく

投稿日時 2019年12月10日 (火) 00時00分 Oracle, SQL, ダウンロード, イベント, Advent Calendar | 固定リンク | 0 | コメント (0)

実行計画は、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 へつづく

投稿日時 2019年12月 9日 (月) 00時00分 Oracle, チューニング, SQL, イベント, Advent Calendar | 固定リンク | 0 | コメント (0)

実行計画は、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)

実行計画は、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)

実行計画は、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)

実行計画は、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)

実行計画は、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)

実行計画は、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)

実行計画は、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)

実行計画は、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)

JPOUG Advent Calendar 2019 / event

JPOUG Advent Calendar 2019 残り4枠となりました。

師走の風物詩、参加お待ちしております :)
https://adventar.org/calendars/4154

投稿日時 2019年11月15日 (金) 06時39分イベント, JPOUG, Advent Calendar | 固定リンク | 0 | コメント (0)

”utl_file I/O” - この症状はあれの可能性が高いですね。

JPOUG Advent Calendar 2017の4日目のエントリーです。

さて、最近あまりお目にかかってなかったUTL_FILEパッケージで表データをcsvに書きだすネタにしました。

先日、UTL_FILEパッケージを利用した処理が想定以上に遅いという相談をうけました。
AWRレポートをみると、上位の待機イベントは、”utl_file I/O"。

！！！！おーーーこれは、珍しいというか、久々にみた病気w

UTL_FILEパッケージを利用したI/Oをグルグルしているとか、でかいファイル読み書きしているかの、どちらかですよねw
ということで、この症状の治療法を考えてみます。

＜参考 - 環境＞

MacBook:˜ system_profiler SPHardwareDataType | grep -E 'Model|Processor|Cores|Memory'
      Model Name: MacBook
      Model Identifier: MacBook9,1
      Processor Name: Intel Core m5
      Processor Speed: 1.2 GHz
      Number of Processors: 1
      Total Number of Cores: 2
      Memory: 8 GB

ホストOS
MacBook:˜ discus$ sw_vers
ProductName:	Mac OS X
ProductVersion:	10.13.1
BuildVersion:	17B1003

MacBook:˜ discus$ VBoxManage -version
5.1.30r118389


ゲストOSとOracle Database
orcl@SYS> !uname -a
Linux localhost.localdomain 4.1.12-94.3.6.el7uek.x86_64 #2 SMP Tue May 30 19:25:15 PDT 2017 x86_64 x86_64 x86_64 GNU/Linux

orcl@SYS> !cat /etc/oracle-release
Oracle Linux Server release 7.3

orcl@SYS> 
orcl@SYS> select * from v$version;

BANNER                                                                               CON_ID
-------------------------------------------------------------------------------- ----------
Oracle Database 12c Enterprise Edition Release 12.2.0.1.0 - 64bit Production              0
PL/SQL Release 12.2.0.1.0 - Production                                                    0
CORE	12.2.0.1.0	Production                                                            0
TNS for Linux: Version 12.2.0.1.0 - Production                                            0
NLSRTL Version 12.2.0.1.0 - Production                                                    0

UTL_FILEでファイル出力する際、ちょっとした手順の漏れが性能差として現れてしまうことがあります。
表の行長は数百バイト程度ですが、行数は数千万〜数億行なんていう状況だと、性能差が顕著に現れてしまうので注意が必要です。

以下の表、セグメントサイズは1GB程度ですが、行数は1千万行以上あります。
この表データをUTL_FILEパッケージを利用してcsvに出力してみます。

ORCL@SCOTT> select segment_name,sum(bytes)/1024/1024/1024 "GB" from user_segments group by segment_name;

SEGMENT_NAME                           GB
------------------------------ ----------
ABOUT_100BYTES_ROWS              .9140625
PK_ABOUT_100BYTES_ROWS            .171875


ORCL@SCOTT> select count(1) from about_100bytes_rows;

  COUNT(1)
----------
  10737420

表の1行は100bytes(改行コード含）です。

ORCL@SCOTT%gt; r
  1  SELECT
  2  	LENGTH(
  3  		TO_CHAR(id,'FM000000000000000000000000000009')
  4  		||','||FOO
  5  	) row_length
  6  FROM
  7  	about_100bytes_rows
  8  WHERE
  9* 	rownum <= 1

ROW_LENGTH
----------
        99

次の2つのコードの赤太文字部分に着目してください。
その部分が異なるだけで処理時間に大きな差が出ます。

DECLARE
	cDIR_NAME CONSTANT VARCHAR2(30) := 'FILES_DIR';
	cFILE_NAME CONSTANT VARCHAR2(128) := 'no_writebuffering_'||TO_CHAR(systimestamp, 'rrmmddhh24miss.ff')||'.txt';
	cBufferSize CONSTANT BINARY_INTEGER := 32767;
	cOpenMode CONSTANT VARCHAR2(2) := 'w';
	fileHandle UTL_FILE.FILE_TYPE;
	
	cBulkReadLimit CONSTANT PLS_INTEGER := 324;
	TYPE tBulkReadArray IS TABLE OF VARCHAR2(8192) INDEX BY BINARY_INTEGER;
	bulkReadArray tBulkReadArray;
	CURSOR cur_about100bytesRow IS
		SELECT
			TO_CHAR(id,'FM000000000000000000000000000009')
			||','||FOO
			AS csvrow
		FROM
			about_100bytes_rows
		;
BEGIN
	OPEN cur_about100bytesRow;
	fileHandle := UTL_FILE.FOPEN(cDIR_NAME, cFILE_NAME, cOpenMode, cBufferSize);
	LOOP
		FETCH cur_about100bytesRow
			BULK COLLECT INTO bulkReadArray
			LIMIT cBulkReadLimit;
		
		EXIT WHEN bulkReadArray.COUNT = 0;
		
		FOR i IN bulkReadArray.FIRST..bulkReadArray.LAST LOOP
			UTL_FILE.PUT_LINE(
				file => fileHandle
				, buffer => bulkReadArray(i)
				, autoflush => true
			);
		END LOOP;
	END LOOP;
	UTL_FILE.FFLUSH(fileHandle);
	UTL_FILE.FCLOSE(fileHandle);
	CLOSE cur_about100bytesRow;
EXCEPTION
	WHEN OTHERS THEN
		IF UTL_FILE.IS_OPEN(fileHandle) THEN
			UTL_FILE.FCLOSE(fileHandle);
		END IF;
		
		IF cur_about100bytesRow%ISOPEN THEN
			CLOSE cur_about100bytesRow;
		END IF;
		RAISE;
END;
/


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

経過: 00:02:27.05

DECLARE
	cDIR_NAME CONSTANT VARCHAR2(30) := 'FILES_DIR';
	cFILE_NAME CONSTANT VARCHAR2(128) := 'writebuffering_'||TO_CHAR(systimestamp, 'rrmmddhh24miss.ff')||'.txt';
	cBufferSize CONSTANT BINARY_INTEGER := 32767;
	cOpenMode CONSTANT VARCHAR2(2) := 'w';
	fileHandle UTL_FILE.FILE_TYPE;
	buffer VARCHAR2(32767);
	
	cBulkReadLimit CONSTANT PLS_INTEGER := 324;
	TYPE tBulkReadArray IS TABLE OF VARCHAR2(8192) INDEX BY BINARY_INTEGER;
	bulkReadArray tBulkReadArray;
	CURSOR cur_about100bytesRow IS
		SELECT
			TO_CHAR(id,'FM000000000000000000000000000009')
			||','||FOO
			AS csvrow
		FROM
			about_100bytes_rows
		;
BEGIN
	OPEN cur_about100bytesRow;
	fileHandle := UTL_FILE.FOPEN(cDIR_NAME, cFILE_NAME, cOpenMode, cBufferSize);
	LOOP
		FETCH cur_about100bytesRow
			BULK COLLECT INTO bulkReadArray
			LIMIT cBulkReadLimit;
		
		EXIT WHEN bulkReadArray.COUNT = 0;
	
		buffer := NULL;	
		FOR i IN bulkReadArray.FIRST..bulkReadArray.LAST LOOP
			buffer := buffer || bulkReadArray(i) || UTL_TCP.CRLF;   
 		END LOOP;
		UTL_FILE.PUT(fileHandle, buffer);
		UTL_FILE.FFLUSH(fileHandle);
	END LOOP;
	UTL_FILE.FFLUSH(fileHandle);
	UTL_FILE.FCLOSE(fileHandle);
	CLOSE cur_about100bytesRow;
EXCEPTION
	WHEN OTHERS THEN
		IF UTL_FILE.IS_OPEN(fileHandle) THEN
			UTL_FILE.FCLOSE(fileHandle);
		END IF;
		
		IF cur_about100bytesRow%ISOPEN THEN
			CLOSE cur_about100bytesRow;
		END IF;
		RAISE;
END;
/


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

経過: 00:00:43.96

何が違うかお分ですよね！
UTL_FILE.PUT_LINE/UTL_FILE.PUTが違う！！w
その部分は重要ではなく、100Bytes単位に書き込んでいるか、約32KB単位で書き込んでいるかが重要なんです。

UTL_FILEは最大32767バイトのバッファを利用できますが、前者はバッファを有効利用せず、100Bytes毎に書き出しています。後者は約32KB単位で書き出しています。

その差はAWRレポートからも見えてきます。

AWRレポート（一部抜粋）
UTL_FILEパッケージによるI/Oの待機は、”utl_file I/O”という待機イベントで現れます。

Avg Waitは短いですが、理由は100バイト単位の小さいなサイズの書き込みを繰り返しているわけなので、そんなとこでしょう。

Top 10 Foreground Events by Total Wait Time

                                           Total Wait       Avg   % DB Wait
Event                                Waits Time (sec)      Wait   time Class
------------------------------ ----------- ---------- --------- ------ --------
DB CPU                                          147.4             99.3
utl_file I/O                    32,212,266       49.5    1.54us   33.3 User I/O
direct path read                     1,881        1.2  620.61us     .8 User I/O
resmgr:cpu quantum                       1         .1   85.85ms     .1 Schedule
db file sequential read                 17          0     .98ms     .0 User I/O
PGA memory operation                    90          0   35.13us     .0 Other
latch: shared pool                       1          0    1.05ms     .0 Concurre
control file sequential read            80          0   12.83us     .0 System I
Disk file operations I/O                 6          0   73.67us     .0 User I/O
SQL*Net message to client                2          0    9.00us     .0 Network

一方、約32KB単位でバッファリングして書き出している場合、Waits回数が激減しています。
Avg Waitsは大きくなっていますが、書き出しサイズにほぼ比例しているので想定通りというところ。

Top 10 Foreground Events by Total Wait Time

                                           Total Wait       Avg   % DB Wait
Event                                Waits Time (sec)      Wait   time Class
------------------------------ ----------- ---------- --------- ------ --------
DB CPU                                             45             98.5
utl_file I/O                        66,288       27.4  413.54us   60.1 User I/O
direct path read                     1,881          1  550.71us    2.3 User I/O
db file sequential read                 88          0  443.38us     .1 User I/O
direct path write                        2          0    4.69ms     .0 User I/O
control file sequential read            80          0   33.25us     .0 System I
latch: shared pool                       1          0    2.38ms     .0 Concurre
Disk file operations I/O                 4          0  323.50us     .0 User I/O
PGA memory operation                    79          0   15.73us     .0 Other
SQL*Net message to client                4          0   20.25us     .0 Network

utl_file.put/put_lineでcsvを出力しているdeviceのiostat(util%)
まだまだ余裕があるのでI/Oで詰まっているのではなく、UTL_FILE.PUT/PUT_LINEの使い方の影響が大きいということですね。

最後に、
UTL_FILEパッケージの入出力時にはバッファの有効利用をお忘れなく。(つい忘れちゃうこともあるので、急いでるときとかw）
扱うデータが多い場合は得に。

そして、みなさま、
メリークリスマス（まだエントリーを書くかもしれませんがw）
#JPOUG

投稿日時 2017年12月 4日 (月) 00時10分 PL/SQL, チューニング, FAQ, Oracle Database 11g, Oracle Database 11g Release 2, JPOUG, Oracle Database 12c release 1, Advent Calendar, Oracle Database 12c Release 2 | 固定リンク | 0 | コメント (0) | トラックバック (0)

スタースキーマを扱う実行計画の特徴

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)

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)

机上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)

机上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)

私のチューニング、アダプティブなオプティマイザにも、今のところ勝てそうな気がするぞ〜〜〜っ。と思った師走のある日。

このエントリは JPOUG Advent Calendar 2014 9日目のエントリです。昨日のエントリは wmo6hashさんの Goodbye, Patch Set. さよなら、PSR。でした。

アダプティブなオプティマイザ関連のアドベントカレンダーネタに、ついカッとなったところで、アダプティブな結合を試してみようと、一杯の珈琲を飲み、気持ちを落ち着けたアカウントがこちらになりますw

環境は以下の通り。

Oracle Linux Server release 6.6
Linux 3.8.13-44.1.3.el6uek.x86_64 #2 SMP Wed Oct 15 19:53:10 PDT 2014 GNU/Linux


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

以下のような２表を用意しました。他のネタに作った表なのですごーく適当ですが、ID列は単一列の主キー制約があります。その他に索引はありません。

SCOTT> desc maybe_driving_tab
 名前                                    NULL?    型
 ----------------------------------------- -------- ----------------------------
 ID                                        NOT NULL NUMBER
 ALTID                                              NUMBER
 DATA                                               VARCHAR2(2000)
 STATUS                                    NOT NULL NUMBER(2)

SCOTT> desc maybe_inner_tab
 名前                                    NULL?    型
 ----------------------------------------- -------- ----------------------------
 ID                                        NOT NULL NUMBER
 ALTID                                              NUMBER
 DATA                                               VARCHAR2(2000)
 STATUS                                    NOT NULL NUMBER(2)

そして、これまた適当にデータを登録して統計を取っちゃいます。

SCOTT> truncate table maybe_driving_tab;
SCOTT> truncate table maybe_inner_tab;
SCOTT> insert into maybe_driving_tab values(1,1,1,1);
SCOTT> insert into maybe_driving_tab values(2,1,1,1);
SCOTT> insert into maybe_inner_tab select * from maybe_driving_tab;
SCOTT> commit;
SCOTT> exec dbms_stats.gather_table_stats(ownname=>'SCOTT',tabname=>'MAYBE_DRIVING_TAB',cascade=>true,no_invalidate=>false,);
SCOTT> exec dbms_stats.gather_table_stats(ownname=>'SCOTT',tabname=>'MAYBE_INNER_TAB',cascade=>true,no_invalidate=>false);

この時点で代表的な統計情報を見てみると、こんな感じです。

SCOTT> select table_name,index_name,num_rows,distinct_keys,clustering_factor from user_indexes where table_name like 'MAYBE%'

TABLE_NAME                     INDEX_NAME                       NUM_ROWS DISTINCT_KEYS CLUSTERING_FACTOR
------------------------------ ------------------------------ ---------- ------------- -----------------
MAYBE_DRIVING_TAB              PK_MAYBE_DRIVING_TAB                    2             2                 1
MAYBE_INNER_TAB                PK_MAYBE_INNER_TAB                      2             2                 1

今回、主役となるid列は、連番で登録します。このタイプはクラスタリングファクタも低くなりindex range scanの有効範囲が広めになる傾向があります。しかし、このデータを登録する前に統計情報を取得（２件の時に）したため、実データと統計情報は大きく乖離しています。Oracle Database 12c 12.1.0.2.0 のオプティマイザにちょっとした意地悪をしています。

BEGIN
    FOR i IN 3..200000 LOOP
        INSERT INTO maybe_driving_tab VALUES(
            i
            ,CEIL(DBMS_RANDOM.VALUE(1,400001))
            ,LPAD(i,500,'*')
            ,MOD(i,2))
    	;
        INSERT INTO maybe_inner_tab VALUES(
            i
            ,CEIL(DBMS_RANDOM.VALUE(1,400001))
            ,LPAD(i,500,'*')
            ,MOD(i,2))
    	;
        IF MOD(i,100) = 0 THEN
            COMMIT;
        END IF;
    END LOOP;
   	COMMIT;
END;
/

統計取得後に、これだけ大量のデータを登録していれば....統計情報は失効しています

SCOTT> select table_name,num_rows,stale_stats from user_tab_statistics where table_name like 'MAYBE%';

TABLE_NAME                       NUM_ROWS STA
------------------------------ ---------- ---
MAYBE_DRIVING_TAB                       2 YES
MAYBE_INNER_TAB                         2 YES

統計情報上は2行ですが...実際は20万行あります (^^;; かなり意地の悪い状況にしてありますが、状況的になくもないと思います。

SCOTT> select count(1) from maybe_driving_tab;

  COUNT(1)
----------
    200000

SCOTT> select count(1) from maybe_inner_tab;

  COUNT(1)
----------
    200000

はい、準備はできました。ここからが本題ですよ〜〜っ。

次のようなSQL文を実行してみます。
AUTOTRACEのNote部分に、12cから登場したadaptive planが適用されていることが示されてます。（見逃さないでくださいよ。
adaptiveな機能が多くなり、リテラル値を使っていても実際の実行計画とは異なる実行計画が示されることが多くなってきてるんです。
dbms_xplan.display_cursor(format=>'ALLSTATS LAST')、SQLトレース、または、SQL監視機能を使って実際に選択されている実行計画の確認が重要になった、ということですからね！！　これ大事ですよ。

SCOTT> r
  1  SELECT
  2  	/* SQL101 */
  3  	/*+
  4  		MONITOR
  5  	*/
  6  	*
  7  FROM
  8  	maybe_driving_tab t1
  9  	INNER JOIN maybe_inner_tab t2
 10  	ON
 11  		t1.id = t2.id
 12  WHERE
 13* 	t1.id BETWEEN 1 and 30000

30000行が選択されました。

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

--------------------------------------------------------------------------------------------------------------
| Id  | Operation                             | Name                 | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                      |                      |     2 |    44 |     4   (0)| 00:00:01 |
|   1 |  NESTED LOOPS                         |                      |     2 |    44 |     4   (0)| 00:00:01 |
|   2 |   NESTED LOOPS                        |                      |     2 |    44 |     4   (0)| 00:00:01 |
|   3 |    TABLE ACCESS BY INDEX ROWID BATCHED| maybe_driving_tab    |     2 |    22 |     2   (0)| 00:00:01 |
|*  4 |     INDEX RANGE SCAN                  | PK_maybe_driving_tab |     2 |       |     1   (0)| 00:00:01 |
|*  5 |    INDEX UNIQUE SCAN                  | PK_maybe_inner_tab   |     1 |       |     0   (0)| 00:00:01 |
|   6 |   TABLE ACCESS BY INDEX ROWID         | maybe_inner_tab      |     1 |    11 |     1   (0)| 00:00:01 |
--------------------------------------------------------------------------------------------------------------

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

   4 - access("T1"."ID">=1 AND "T1"."ID"<=30000)
   5 - access("T1"."ID"="T2"."ID")
       filter("T2"."ID">=1 AND "T2"."ID"<=30000)

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


統計
----------------------------------------------------------
          0  recursive calls
          0  db block gets
       8573  consistent gets
       2159  physical reads
          0  redo size
   31686000  bytes sent via SQL*Net to client
      22541  bytes received via SQL*Net from client
       2001  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
      30000  rows processed

では、実際に実行された実行計画をSQL監視機能(オプションが必要な機能です）を使って見てみます。

11gまでは見たこともない不思議な光景になっていますよね。これがAdaptive Joinの実行計画。ほうほうって感じです。

この実行計画の中には２つの実行計画が混在しています。実際に実行された操作もあれば、実行されない操作も含まれています。

どの操作が実行されたかみるには、Execs列をみます。

ね、ね、ね。　
Nested Loop結合じゃなくて、Hash結合が実行されています。
はじめは、Nested Loop結合をやろうとしてるのわかりますか？

ID=４のStatistics Collectorとう操作で実行時の統計（このケースでは行数でしょうかね？？？　想像ですが）をみて、Nested Loop結合を寸止めして（妥当な表現かあやしいが）、ハッシュ結合に切り替えた様子が見えますよね。。。。ちょいと感動したw

ただし、index range scanするには行数的に微妙な状況になりつつありそうなところだと思います。

======================================================================================================================================================================================
| 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                          |                      |         |      |         5 |     +0 |     1 |    30000 |      |       |       |          |                 |
|  1 |   HASH JOIN                               |                      |       2 |    4 |         5 |     +0 |     1 |    30000 |      |       |   20M |          |                 |
|  2 |    NESTED LOOPS                           |                      |       2 |    4 |           |        |     1 |          |      |       |       |          |                 |
|  3 |     NESTED LOOPS                          |                      |       2 |    4 |           |        |     1 |          |      |       |       |          |                 |
|  4 |      STATISTICS COLLECTOR                 |                      |         |      |         1 |     +0 |     1 |        0 |      |       |       |          |                 |
|  5 |       TABLE ACCESS BY INDEX ROWID BATCHED | maybe_driving_tab    |       2 |    2 |         1 |     +0 |     1 |    30000 |      |       |       |          |                 |
|  6 |        INDEX RANGE SCAN                   | PK_maybe_driving_tab |       2 |    1 |         1 |     +0 |     1 |    30000 |      |       |       |          |                 |
|  7 |      INDEX UNIQUE SCAN                    | PK_maybe_inner_tab   |       1 |      |           |        |       |          |      |       |       |          |                 |
|  8 |     TABLE ACCESS BY INDEX ROWID           | maybe_inner_tab      |       1 |    1 |           |        |       |          |      |       |       |          |                 |
|  9 |    TABLE ACCESS BY INDEX ROWID BATCHED    | maybe_inner_tab      |       1 |    1 |         5 |     +0 |     1 |    30000 | 2108 |  16MB |       |          |                 |
| 10 |     INDEX RANGE SCAN                      | PK_maybe_inner_tab   |       1 |      |         5 |     +0 |     1 |    30000 |   51 | 408KB |       |          |                 |
======================================================================================================================================================================================

さらに、取得件数を倍にしてみました。

どうなるでしょう。

割合的には、30%の範囲検索です。（統計情報次第では全表走査＋ハッシュ結合に切り替わることも無くはない状況ですが.....)

SELECT
	/* SQL102 */
	/*+
		MONITOR
	*/
	*
FROM
	maybe_driving_tab t1
 	INNER JOIN maybe_inner_tab t2
 	ON
 		t1.id = t2.id
WHERE
	t1.id BETWEEN 1 and 60000
/

60000行が選択されました。

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

--------------------------------------------------------------------------------------------------------------
| Id  | Operation                             | Name                 | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                      |                      |     2 |    44 |     4   (0)| 00:00:01 |
|   1 |  NESTED LOOPS                         |                      |     2 |    44 |     4   (0)| 00:00:01 |
|   2 |   NESTED LOOPS                        |                      |     2 |    44 |     4   (0)| 00:00:01 |
|   3 |    TABLE ACCESS BY INDEX ROWID BATCHED| maybe_driving_tab    |     2 |    22 |     2   (0)| 00:00:01 |
|*  4 |     INDEX RANGE SCAN                  | PK_maybe_driving_tab |     2 |       |     1   (0)| 00:00:01 |
|*  5 |    INDEX UNIQUE SCAN                  | PK_maybe_inner_tab   |     1 |       |     0   (0)| 00:00:01 |
|   6 |   TABLE ACCESS BY INDEX ROWID         | maybe_inner_tab      |     1 |    11 |     1   (0)| 00:00:01 |
--------------------------------------------------------------------------------------------------------------

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

   4 - access("T1"."ID">=1 AND "T1"."ID"<=60000)
   5 - access("T1"."ID"="T2"."ID")
       filter("T2"."ID">=1 AND "T2"."ID"<=60000)

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


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

全体の30%の範囲検索でもギリギリ、Index range scanしているようです。 index rowid batchedとう操作が効いているためでしょうか。そのあとに、ハッシュ結合をしています。
index rowid batchedという不連続ブロックの一括読み込みを繰り返して、全体の30%程度のindex range scanを 1度のオペレーションで行っている箇所(ID=5や9)は興味深いですよね。
(クラスタリングファクタが低いと、実はtable full scanと大差なかったりして〜〜〜と思ったり、思わなかったり）

======================================================================================================================================================================================
| 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                          |                      |         |      |         9 |     +0 |     1 |    60000 |      |       |       |          |                 |
|  1 |   HASH JOIN                               |                      |       2 |    4 |         9 |     +0 |     1 |    60000 |      |       |   36M |          |                 |
|  2 |    NESTED LOOPS                           |                      |       2 |    4 |         1 |     +0 |     1 |        1 |      |       |       |          |                 |
|  3 |     NESTED LOOPS                          |                      |       2 |    4 |         1 |     +0 |     1 |        1 |      |       |       |          |                 |
|  4 |      STATISTICS COLLECTOR                 |                      |         |      |         1 |     +0 |     1 |    60000 |      |       |       |          |                 |
|  5 |       TABLE ACCESS BY INDEX ROWID BATCHED | maybe_driving_tab    |       2 |    2 |         1 |     +0 |     1 |    60000 | 4615 |  36MB |       |          |                 |
|  6 |        INDEX RANGE SCAN                   | PK_maybe_driving_tab |       2 |    1 |         1 |     +0 |     1 |    60000 |      |       |       |          |                 |
|  7 |      INDEX UNIQUE SCAN                    | PK_maybe_inner_tab   |       1 |      |           |        |       |          |      |       |       |          |                 |
|  8 |     TABLE ACCESS BY INDEX ROWID           | maybe_inner_tab      |       1 |    1 |           |        |       |          |      |       |       |          |                 |
|  9 |    TABLE ACCESS BY INDEX ROWID BATCHED    | maybe_inner_tab      |       1 |    1 |         9 |     +0 |     1 |    60000 | 4615 |  36MB |       |          |                 |
| 10 |     INDEX RANGE SCAN                      | PK_maybe_inner_tab   |       1 |      |         9 |     +0 |     1 |    60000 |      |       |       |          |                 |
======================================================================================================================================================================================

次に、全体の40%程度の範囲検索にしてみます。
全表走査＋ハッシュ結合が理想だと思うのですが、adaptive joinでhash結合になっているので、全表走査になりそうな予感はしますが...

SELECT
	/* SQL103 */
	/*+
		MONITOR
	*/
	*
FROM
	maybe_driving_tab t1
 	INNER JOIN maybe_inner_tab t2
 	ON
 		t1.id = t2.id
WHERE
	t1.id BETWEEN 1 and 80000
/

80000行が選択されました。

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

--------------------------------------------------------------------------------------------------------------
| Id  | Operation                             | Name                 | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                      |                      |     2 |    44 |     4   (0)| 00:00:01 |
|   1 |  NESTED LOOPS                         |                      |     2 |    44 |     4   (0)| 00:00:01 |
|   2 |   NESTED LOOPS                        |                      |     2 |    44 |     4   (0)| 00:00:01 |
|   3 |    TABLE ACCESS BY INDEX ROWID BATCHED| maybe_driving_tab    |     2 |    22 |     2   (0)| 00:00:01 |
|*  4 |     INDEX RANGE SCAN                  | PK_maybe_driving_tab |     2 |       |     1   (0)| 00:00:01 |
|*  5 |    INDEX UNIQUE SCAN                  | PK_maybe_inner_tab   |     1 |       |     0   (0)| 00:00:01 |
|   6 |   TABLE ACCESS BY INDEX ROWID         | maybe_inner_tab      |     1 |    11 |     1   (0)| 00:00:01 |
--------------------------------------------------------------------------------------------------------------

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

   4 - access("T1"."ID">=1 AND "T1"."ID"<=80000)
   5 - access("T1"."ID"="T2"."ID")
       filter("T2"."ID">=1 AND "T2"."ID"<=80000)

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


統計
----------------------------------------------------------
          4  recursive calls
          0  db block gets
      22856  consistent gets
       3393  physical reads
          0  redo size
   84528237  bytes sent via SQL*Net to client
      59215  bytes received via SQL*Net from client
       5335  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
      80000  rows processed

ん〜〜〜〜〜っ。adaptive joinでhash結合にはなるもの全表走査にはなかなかなってくれません。むむむ。

==============================================================================================================================================================================================================
| 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                          |                      |         |      |        12 |     +0 |     1 |    80000 |      |       |       |       |       |       |          |                 |
|  1 |   HASH JOIN                               |                      |       2 |    4 |        12 |     +0 |     1 |    80000 |   21 |   2MB |    21 |   2MB |   48M |    3M |          |                 |
|  2 |    NESTED LOOPS                           |                      |       2 |    4 |         1 |     +0 |     1 |        1 |      |       |       |       |       |       |          |                 |
|  3 |     NESTED LOOPS                          |                      |       2 |    4 |         1 |     +0 |     1 |        1 |      |       |       |       |       |       |          |                 |
|  4 |      STATISTICS COLLECTOR                 |                      |         |      |         1 |     +0 |     1 |    80000 |      |       |       |       |       |       |          |                 |
|  5 |       TABLE ACCESS BY INDEX ROWID BATCHED | maybe_driving_tab    |       2 |    2 |         1 |     +0 |     1 |    80000 | 1539 |  12MB |       |       |       |       |          |                 |
|  6 |        INDEX RANGE SCAN                   | PK_maybe_driving_tab |       2 |    1 |         1 |     +0 |     1 |    80000 |      |       |       |       |       |       |          |                 |
|  7 |      INDEX UNIQUE SCAN                    | PK_maybe_inner_tab   |       1 |      |           |        |       |          |      |       |       |       |       |       |          |                 |
|  8 |     TABLE ACCESS BY INDEX ROWID           | maybe_inner_tab      |       1 |    1 |           |        |       |          |      |       |       |       |       |       |          |                 |
|  9 |    TABLE ACCESS BY INDEX ROWID BATCHED    | maybe_inner_tab      |       1 |    1 |        12 |     +0 |     1 |    80000 | 1539 |  12MB |       |       |       |       |          |                 |
| 10 |     INDEX RANGE SCAN                      | PK_maybe_inner_tab   |       1 |      |        12 |     +0 |     1 |    80000 |      |       |       |       |       |       |          |                 |
==============================================================================================================================================================================================================

ちょっと、ここで寄り道してみます。
adaptive joinを無効にしたら、多分、一番だめな感じのNested Loop結合になるはずなので確認しておきましょう。
隠しパラメータを %adaptive%で検索して見つけたのがそのものズバリの隠しパラメータそ使つかいます。　:)

AUTOTRACEから adaptive planというNoteが消えましたねぇ。(^^

SELECT
	/* SQL104 */
	/*+
		MONITOR
		OPT_PARAM('_optimizer_nlj_hj_adaptive_join' 'false')
	*/
	*
FROM
	maybe_driving_tab t1
 	INNER JOIN maybe_inner_tab t2
 	ON
 		t1.id = t2.id
WHERE
	t1.id BETWEEN 1 and 80000
/


80000行が選択されました。

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

--------------------------------------------------------------------------------------------------------------
| Id  | Operation                             | Name                 | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                      |                      |     2 |    44 |     4   (0)| 00:00:01 |
|   1 |  NESTED LOOPS                         |                      |     2 |    44 |     4   (0)| 00:00:01 |
|   2 |   NESTED LOOPS                        |                      |     2 |    44 |     4   (0)| 00:00:01 |
|   3 |    TABLE ACCESS BY INDEX ROWID BATCHED| maybe_driving_tab    |     2 |    22 |     2   (0)| 00:00:01 |
|*  4 |     INDEX RANGE SCAN                  | PK_maybe_driving_tab |     2 |       |     1   (0)| 00:00:01 |
|*  5 |    INDEX UNIQUE SCAN                  | PK_maybe_inner_tab   |     1 |       |     0   (0)| 00:00:01 |
|   6 |   TABLE ACCESS BY INDEX ROWID         | maybe_inner_tab      |     1 |    11 |     1   (0)| 00:00:01 |
--------------------------------------------------------------------------------------------------------------

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

   4 - access("T1"."ID">=1 AND "T1"."ID"<=80000)
   5 - access("T1"."ID"="T2"."ID")
       filter("T2"."ID">=1 AND "T2"."ID"<=80000)


統計
----------------------------------------------------------
          0  recursive calls
          0  db block gets
     102603  consistent gets
      12608  physical reads
          0  redo size
   84528237  bytes sent via SQL*Net to client
      59215  bytes received via SQL*Net from client
       5335  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
      80000  rows processed

統計情報との乖離が大きいので、Nested Loop結合でindex range scanしてますねぇ〜。駆動表はtable access index rowid batchedになっていますが....
内部表は8万回もindex ~~index~~unique scanされてますね。

=============================================================================================================================================================
| Id |                Operation                |         Name         |  Rows   | Cost |   Time    | Start  | Execs |   Rows   | Activity | Activity Detail |
|    |                                         |                      | (Estim) |      | Active(s) | Active |       | (Actual) |   (%)    |   (# samples)   |
=============================================================================================================================================================
|  0 | SELECT STATEMENT                        |                      |         |      |        11 |     +0 |     1 |    80000 |          |                 |
|  1 |   NESTED LOOPS                          |                      |       2 |    4 |        11 |     +0 |     1 |    80000 |          |                 |
|  2 |    NESTED LOOPS                         |                      |       2 |    4 |        11 |     +0 |     1 |    80000 |          |                 |
|  3 |     TABLE ACCESS BY INDEX ROWID BATCHED | maybe_driving_tab    |       2 |    2 |        11 |     +0 |     1 |    80000 |          |                 |
|  4 |      INDEX RANGE SCAN                   | PK_maybe_driving_tab |       2 |    1 |        11 |     +0 |     1 |    80000 |          |                 |
|  5 |     INDEX UNIQUE SCAN                   | PK_maybe_inner_tab   |       1 |      |        11 |     +0 | 80000 |    80000 |          |                 |
|  6 |    TABLE ACCESS BY INDEX ROWID          | maybe_inner_tab      |       1 |    1 |        11 |     +0 | 80000 |    80000 |          |                 |
=============================================================================================================================================================

寄り道はここまでにして、
オプティマイザがやってくれないなら、ヒントでチューニングしちゃいましょ。
hash結合＋全表走査になるように....

SELECT
	/* SQL105 */
	/*+
		MONITOR
		OPT_PARAM('_optimizer_nlj_hj_adaptive_join' 'false')
		FULL(t1)
		FULL(t2)
		USE_HASH(t1 t2)
	*/
	*
FROM
	maybe_driving_tab t1
 	INNER JOIN maybe_inner_tab t2
 	ON
 		t1.id = t2.id
WHERE
	t1.id BETWEEN 1 and 80000
/

80000行が選択されました。

いい感じになったような気がしますが、consistent getsは、index range scan + table access bby index rowid batchedの方が少ないんですねぇ〜。
実データのクラスタリングファクタが高かったら違う結果になるような気がします。
今回は試しませんが。

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

----------------------------------------------------------------------------------------
| Id  | Operation          | Name              | Rows  | Bytes | Cost (%CPU)| Time     |
----------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT   |                   |     2 |    44 |     6   (0)| 00:00:01 |
|*  1 |  HASH JOIN         |                   |     2 |    44 |     6   (0)| 00:00:01 |
|*  2 |   TABLE ACCESS FULL| maybe_driving_tab |     2 |    22 |     3   (0)| 00:00:01 |
|*  3 |   TABLE ACCESS FULL| maybe_inner_tab   |     2 |    22 |     3   (0)| 00:00:01 |
----------------------------------------------------------------------------------------

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

   1 - access("T1"."ID"="T2"."ID")
   2 - filter("T1"."ID">=1 AND "T1"."ID"<=80000)
   3 - filter("T2"."ID">=1 AND "T2"."ID"<=80000)


統計
----------------------------------------------------------
          0  recursive calls
          0  db block gets
      33390  consistent gets
      30906  physical reads
          0  redo size
   84528237  bytes sent via SQL*Net to client
      59215  bytes received via SQL*Net from client
       5335  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
      80000  rows processed


==============================================================================================================================================================
| 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     |                   |         |      |        12 |     +0 |     1 |    80000 |      |       |       |          |                 |
|  1 |   HASH JOIN          |                   |       2 |    6 |        11 |     +0 |     1 |    80000 |      |       |   50M |          |                 |
|  2 |    TABLE ACCESS FULL | maybe_driving_tab |       2 |    3 |         1 |     +0 |     1 |    80000 |  252 | 121MB |       |          |                 |
|  3 |    TABLE ACCESS FULL | maybe_inner_tab   |       2 |    3 |        11 |     +0 |     1 |    80000 |  251 | 121MB |       |          |                 |
==============================================================================================================================================================

統計との乖離があるのは確かなので統計情報を取り直してみます。（オプティマイザはどういった計画を導きだすか....)

SCOTT> exec dbms_stats.gather_table_stats(ownname=>'SCOTT',tabname=>'MAYBE_DRIVING_TAB',no_invalidate=>false,cascade=>true);
SCOTT> exec dbms_stats.gather_table_stats(ownname=>'SCOTT',tabname=>'MAYBE_INNER_TAB',no_invalidate=>false,cascade=>true);

実行！

SELECT
	/* SQL108 */
	/*+
		MONITOR
	*/
	*
FROM
	maybe_driving_tab t1
 	INNER JOIN maybe_inner_tab t2
 	ON
 		t1.id = t2.id
WHERE
	t1.id BETWEEN 1 and 80000
/

80000行が選択されました。


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

------------------------------------------------------------------------------------------------
| Id  | Operation          | Name              | Rows  | Bytes |TempSpc| Cost (%CPU)| Time     |
------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT   |                   | 80000 |    78M|       | 12776   (1)| 00:00:01 |
|*  1 |  HASH JOIN         |                   | 80000 |    78M|    40M| 12776   (1)| 00:00:01 |
|*  2 |   TABLE ACCESS FULL| maybe_driving_tab | 80000 |    39M|       |  4398   (1)| 00:00:01 |
|*  3 |   TABLE ACCESS FULL| maybe_inner_tab   | 80000 |    39M|       |  4398   (1)| 00:00:01 |
------------------------------------------------------------------------------------------------

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

   1 - access("T1"."ID"="T2"."ID")
   2 - filter("T1"."ID"<=80000 AND "T1"."ID">=1)
   3 - filter("T2"."ID"<=80000 AND "T2"."ID">=1)

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


統計
----------------------------------------------------------
          0  recursive calls
          0  db block gets
      35859  consistent gets
      15453  physical reads
          0  redo size
   84528237  bytes sent via SQL*Net to client
      59215  bytes received via SQL*Net from client
       5335  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
      80000  rows processed
      
      
===========================================================================================================================================================================
| 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                |                    |         |       |        12 |     +0 |     1 |    80000 |      |       |       |          |                 |
|  1 |   HASH JOIN                     |                    |   80000 | 12776 |        11 |     +0 |     1 |    80000 |      |       |   51M |          |                 |
|  2 |    NESTED LOOPS                 |                    |   80000 | 12776 |           |        |     1 |          |      |       |       |          |                 |
|  3 |     NESTED LOOPS                |                    |         |       |           |        |     1 |          |      |       |       |          |                 |
|  4 |      STATISTICS COLLECTOR       |                    |         |       |         1 |     +0 |     1 |        0 |      |       |       |          |                 |
|  5 |       TABLE ACCESS FULL         | maybe_driving_tab  |   80000 |  4398 |         1 |     +0 |     1 |    80000 |  252 | 121MB |       |          |                 |
|  6 |      INDEX UNIQUE SCAN          | PK_maybe_inner_tab |         |       |           |        |       |          |      |       |       |          |                 |
|  7 |     TABLE ACCESS BY INDEX ROWID | maybe_inner_tab    |       1 |  4398 |           |        |       |          |      |       |       |          |                 |
|  8 |    TABLE ACCESS FULL            | maybe_inner_tab    |   80000 |  4398 |        11 |     +0 |     1 |    80000 |      |       |       |          |                 |
===========================================================================================================================================================================

うん、やっと、オプティマイザと私の意見が一致したようだw
おら、オプティマイザより先にこの結果想定してたんだ！　アダプティブなオプティマイザにちょっとだけ勝ったw ぞ〜〜〜〜っ.　（クレヨン　シンちゃん風に...)

そして....
table access by index rowid batched って状況次第ではあるものの、意外にいいかも。と思ったのであった。 (^^/
....今後の為に、さらにネタを集めたほうがいいかもしれない...

最後に、adaptiveな機能が多くなっていますが、その基礎になるのはやはり、統計情報と、その向こうにあるデータです。
機能に目が移りがちですが忘れちゃいけないのが、これらです。

以上、役に立つような、立たないようなネタでした。

あ、一つ忘れてました〜〜っ。
optimizer_dynamic_samplingが効きそうな気もしますが、今回はデフォルト（2)だったので結果は未確認です。だれかやってみて〜〜:)

JPOUG Advent Calendar 2014、
明日は、yoku0825さんです。お楽しみに〜。

投稿日時 2014年12月 9日 (火) 00時05分 Oracle, JPOUG, Advent Calendar | 固定リンク | 0 | コメント (4) | トラックバック (0)

DROP SHADOW CTRL

GaragebandとiMovieで

検索

Twitter

最近の記事

最近のコメント

最近のトラックバック

カテゴリー

Oracle

Apple

その他

Googleの広告

RSS

当サイトについて

2024年12月25日 (水)

2024年12月24日 (火)

2024年12月23日 (月)

2024年12月22日 (日)

2024年12月21日 (土)

2024年12月20日 (金)

2024年12月19日 (木)

2024年12月18日 (水)

2024年12月17日 (火)

2024年12月16日 (月)

2024年12月15日 (日)

2024年12月14日 (土)

2024年12月13日 (金)

2024年12月12日 (木)

2024年12月11日 (水)

2024年12月10日 (火)

2024年12月 9日 (月)

2024年12月 8日 (日)

2024年12月 7日 (土)

2024年12月 6日 (金)

2024年12月 5日 (木)

2024年12月 4日 (水)

2024年12月 3日 (火)

2024年12月 2日 (月)

2024年12月 1日 (日)

2023年12月22日 (金)

2023年12月17日 (日)

2023年12月13日 (水)

2023年12月10日 (日)

2023年12月 9日 (土)

2023年1月16日 (月)

2022年12月26日 (月)

2022年12月25日 (日)

2022年12月24日 (土)

2022年12月23日 (金)

2022年12月22日 (木)

2022年12月21日 (水)

2022年12月20日 (火)

2022年12月19日 (月)

2022年12月18日 (日)

2022年12月17日 (土)

2022年12月16日 (金)

2022年12月15日 (木)

2022年12月14日 (水)

2022年12月13日 (火)

2022年12月12日 (月)

2022年12月11日 (日)

2022年12月10日 (土)

2022年12月 9日 (金)

2022年12月 8日 (木)

2022年12月 7日 (水)

2022年12月 6日 (火)

2022年12月 5日 (月)

2022年12月 4日 (日)

2022年12月 3日 (土)

2022年12月 2日 (金)

2022年12月 1日 (木)

2022年11月10日 (木)

2021年12月23日 (木)

2021年12月 1日 (水)

2020年12月26日 (土)

2020年12月25日 (金)

2020年12月24日 (木)

2020年12月23日 (水)

2020年12月22日 (火)