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

GaragebandとiMovieで

検索

検索用語を入力

Web Blog内

検索フォームを送信

プロフィール

Twitter

Tweets by @discus_hamburg

オンラインショッピング

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

最近のトラックバック

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

Oracle

OTN US

Apple

その他

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

Googleの広告

RSS

RSSを表示する

当サイトについて

プライバシーポリシー

プライバシーポリシー

「個人情報の保護に関する法律」に基づき、「個人情報保護の基本方針（プライバシーポリシー）」を
定め個人情報の適切な管理・保護に努めることを表明します。

個人情報保護の基本方針（プライバシーポリシー）

1.　個人情報の利用目的をできるだけ特定し、特定された利用目的の達成に必要な範囲を超えて利用
　　することはありません。
2.　個人情報を偽りその他不正な手段による取得しません。取得したときは、本人に速やかに利用目的
　　を通知又は公表します。
3.　個人情報を利用目的の範囲内で正確かつ最新の内容に保つように努めます。
4.　個人情報の漏洩や滅失を防ぐために、必要かつ適切な安全管理措置を講じます。
5.　あらかじめ本人の同意を得ないで第三者に個人情報を提供することはありません。
　　ただし、法令に基づく場合、人の生命、身体又は財産の保護に必要な場合、公衆衛生・児童の健全育成に
　　特に必要な場合、国等に協力する場合は除きます。

2022年12月20日 (火) / Author : Hiroshi Sekiguchi.

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

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

Mac De Oracle

MacOS X で動作する Oracle　が正式にリリースされたのだ！ 1996年にリリースされた、Personal Oracle7 for MacOS以来、封印されていたMacOS版が、（2005年）９年ぶりに正式リリースされたのでいろいろあそんでみたくなった！

GaragebandとiMovieで

検索

Twitter

オンラインショッピング

気まぐれ写真館

最近の記事

最近のコメント

最近のトラックバック

バックナンバー

カテゴリー

Oracle

Apple

その他

Googleの広告

RSS

当サイトについて

2022年12月20日 (火) / Author : Hiroshi Sekiguchi.

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

コメント

コメントを書く

Mac De Oracle

GaragebandとiMovieで

検索

Twitter

オンラインショッピング

気まぐれ写真館

最近の記事

最近のコメント

最近のトラックバック

バックナンバー

カテゴリー

Oracle

Apple

その他

Googleの広告

RSS

当サイトについて

2022年12月20日 (火) / Author : Hiroshi Sekiguchi.

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

コメント

コメントを書く

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