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

SQL*Plus -Fastオプション / FAQ

Previously on Mac De Oracle.
前回は、アドベントカレンダーのおまけのおまけwでした

今日は、そこで仕込んでおいたネタを使い、SQL*Plusも機能拡張されてたのすっかり忘れていた！　ので、
高Fetch圧症の話に絡めてSQL*Plusの-F[ast]オプション書いておこうと思います。

軽めですが。

Fetch回数削減に効果があるので、多数の行をFetchするような時は思い出すと良いですね。
Client/Server間のrount tripが減ることに繋がるわけで、そこが慢性病の原因なら少しでも楽になれたら良いと思いますし。
（ということで、Fetch Sizeも忘れないでね。という気持ちを込めて。）

最初は、-Fastオプションなしで。arraysizeのデフォルトは 15です。なお、この -F[ast]オプションは、Oracle Database 12c 12.2以降でサポートされています。

[oracle@localhost ~]$ sqlplus scott/tiger@orclpdb1

...略...

Oracle Database 21c Enterprise Edition Release 21.0.0.0.0 - Production
Version 21.3.0.0.0
に接続されました。
SCOTT@orclpdb1> @dayx2
  1  WITH
  2  t1 AS
  3  (
  4    SELECT
  5      pkey
  6      , CASE
  7          WHEN col2 IS NULL
  8            THEN col1
  9            ELSE col2
 10      END AS join_key
 11      ,description
 12    FROM
 13      nikoichi_mitaina_subtype
 14    WHERE
 15      col1 IS NOT NULL
 16      OR col2 IS NOT NULL
 17  )
 18  SELECT *
 19  FROM
 20    supertype st
 21    LEFT OUTER JOIN t1
 22    ON
 23*     st.pkey = t1.join_key

1000001行が選択されました。

経過: 00:02:18.83

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

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

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

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


統計
----------------------------------------------------------
       1297  recursive calls
          0  db block gets
     229599  consistent gets
     374715  physical reads
          0  redo size
 1551273711  bytes sent via SQL*Net to client
     735146  bytes received via SQL*Net from client
      66668  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
    1000001  rows processed


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

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

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

Global Information
------------------------------

...略...

   Duration            :  173s

 ...略...

   Fetch Calls         :  66668

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

SQL Plan Monitoring Details (Plan Hash Value=2223315184)
==============================================================================================================================================================================================================
| Id |      Operation       |           Name           |  Rows   | Cost  |   Time    | Start  | Execs |   Rows   | Read | Read  | Write | Write |  Mem  | Temp  | Activity |         Activity Detail         |
|    |                      |                          | (Estim) |       | Active(s) | Active |       | (Actual) | Reqs | Bytes | Reqs  | Bytes | (Max) | (Max) |   (%)    |           (# samples)           |
==============================================================================================================================================================================================================
|  0 | SELECT STATEMENT     |                          |         |       |       172 |     +2 |     1 |       1M |      |       |       |       |     . |     . |          |                                 |
|  1 |   HASH JOIN OUTER    |                          |      1M |  119K |       173 |     +1 |     1 |       1M | 5169 |   1GB |  5169 |   1GB | 184MB |   1GB |    76.92 | Cpu (9)                         |
|    |                      |                          |         |       |           |        |       |          |      |       |       |       |       |       |          | SQL*Net more data to client (1) |
|  2 |    TABLE ACCESS FULL | SUPERTYPE                |      1M | 19593 |         1 |     +2 |     1 |       1M |  575 | 559MB |       |       |     . |     . |          |                                 |
|  3 |    TABLE ACCESS FULL | NIKOICHI_MITAINA_SUBTYPE |    750K | 38796 |        47 |     +2 |     1 |       1M | 1134 |   1GB |       |       |     . |     . |    15.38 | Cpu (2)                         |
==============================================================================================================================================================================================================

次に、-F[ast]オプションで接続します。このオプションにより、ARRAYSIZE = 100に設定されます。それ以外にも3.5.1.5 FASTオプションいくつかの設定が変更されます。

[oracle@localhost ~]$ sqlplus -Fast scott/tiger@orclpdb1

...略...

Oracle Database 21c Enterprise Edition Release 21.0.0.0.0 - Production
Version 21.3.0.0.0
に接続されました。
SCOTT@orclpdb1> @dayx2
  1  WITH
  2  t1 AS
  3  (
  4    SELECT
  5      pkey
  6      , CASE
  7          WHEN col2 IS NULL
  8            THEN col1
  9            ELSE col2
 10      END AS join_key
 11      ,description
 12    FROM
 13      nikoichi_mitaina_subtype
 14    WHERE
 15      col1 IS NOT NULL
 16      OR col2 IS NOT NULL
 17  )
 18  SELECT *
 19  FROM
 20    supertype st
 21    LEFT OUTER JOIN t1
 22    ON
 23*     st.pkey = t1.join_key

1000001行が選択されました。

経過: 00:01:55.03

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

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

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

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


統計
----------------------------------------------------------
       1297  recursive calls
          0  db block gets
     216797  consistent gets
     374715  physical reads
          0  redo size
 1539940308  bytes sent via SQL*Net to client
     110262  bytes received via SQL*Net from client
      10001  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
    1000001  rows processed


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

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

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

Global Information
------------------------------

...略...

   Duration            :  146s

 ...略...

   Fetch Calls         :  10001

Global Stats
============================================================================================
| Elapsed |   Cpu   |    IO    |  Other   | Fetch  | Buffer | Read | Read  | Write | Write |
| Time(s) | Time(s) | Waits(s) | Waits(s) | Calls  |  Gets  | Reqs | Bytes | Reqs  | Bytes |
============================================================================================
|      17 |      14 |     1.76 |     1.72 |  10001 |   216K | 6878 |   3GB |  5169 |   1GB |
============================================================================================

SQL Plan Monitoring Details (Plan Hash Value=2223315184)
==============================================================================================================================================================================================================
| Id |      Operation       |           Name           |  Rows   | Cost  |   Time    | Start  | Execs |   Rows   | Read | Read  | Write | Write |  Mem  | Temp  | Activity |         Activity Detail         |
|    |                      |                          | (Estim) |       | Active(s) | Active |       | (Actual) | Reqs | Bytes | Reqs  | Bytes | (Max) | (Max) |   (%)    |           (# samples)           |
==============================================================================================================================================================================================================
|  0 | SELECT STATEMENT     |                          |         |       |       145 |     +2 |     1 |       1M |      |       |       |       |     . |     . |          |                                 |
|  1 |   HASH JOIN OUTER    |                          |      1M |  119K |       146 |     +1 |     1 |       1M | 5169 |   1GB |  5169 |   1GB | 184MB |   1GB |   100.00 | Cpu (14)                        |
|    |                      |                          |         |       |           |        |       |          |      |       |       |       |       |       |          | SQL*Net more data to client (4) |
|  2 |    TABLE ACCESS FULL | SUPERTYPE                |      1M | 19593 |         1 |     +2 |     1 |       1M |  575 | 559MB |       |       |     . |     . |          |                                 |
|  3 |    TABLE ACCESS FULL | NIKOICHI_MITAINA_SUBTYPE |    750K | 38796 |        42 |     +2 |     1 |       1M | 1134 |   1GB |       |       |     . |     . |          |                                 |
==============================================================================================================================================================================================================

-Fastオプションなしの場合と比較してみるとSQL*Net roundtrips to/from clientなど減ってますよね:)
このround tripは、待機イベントSQL*Net more data to clientなどで現れます。(SQL監視のActivity Detailsにも現れていますので、覚えておくと良いと思います)

-Fastオプションなし（auto trace)

1551273711  bytes sent via SQL*Net to client
    735146  bytes received via SQL*Net from client
     66668  SQL*Net roundtrips to/from client

-Fastオプションあり（auto trace)

1539940308  bytes sent via SQL*Net to client
    110262  bytes received via SQL*Net from client
     10001  SQL*Net roundtrips to/from client

-Fastオプションなし（SQL監視)

Global Information
------------------------------
...略...
Duration            :  173s
...略...
Fetch Calls         :  66668

-Fastオプションあり（auto trace)

Global Information
------------------------------
...略...
Dration             :  146s
...略...
Fetch Calls         :  10001

早く、ポカポカ陽気にならないかなぁ。

と思う寒い日々。

では、また。

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

実行計画は, 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 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 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 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 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文のレントゲン写真だ！ No.35 - 似て非なるもの USE_CONCAT と OR_EXPANDヒントとパラレルクエリー

Previously on Mac De Oracle
前回は、その前のエントリーの流れから、標準はあるにはあるが癖の多いSQL - #27 LNNVL is 何？と思った方向けでちょいと脱線してました。
今日は、話を元に戻しますw

USE_CANTATとOR_EXPAND、レントゲン（実行計画）をみて、どこがどう違うのかは理解できたのではないかと思います。ではなぜ、今後使うとしたら、OR_EXPANDなのかは、USE_CONCATとより言うことを聞いてくれやすいという他にもう一つあるのですが、それは何かわかりますか？
大人の事情で、しばらく関わりが薄かった時期（w　にこのヒントの効果を知ったのですが、もう一つのメリットまでは知らなかったんですよw。　斜め読みだけしてると取りこぼしちゃいますねw

答えはパラレルクエリーにした場合の違い。

OR_EXPANDによる書き換えとUNION-ALLへの内部的な書き換えの効果で、パラレルクエリーとの相性が良くなっているんですよね。

早速、レントゲンをみてみましょう　:)
（あ、書き忘れてましたが、Oracle Database 21cを使ってます）

USE_CONCATを使ってCONCATENATION(Id=1のoperation)を強制してかつパラレルクエリーにしています。PX COORDINATOR が Id=2とId=9に現れているのでUNIONの各SELECT文はシリアルに実行されているようですね。この挙動は変わってなさそうです。

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

経過: 00:00:00.44

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

-----------------------------------------------------------------------------------------------------------------------------------------------
| Id  | Operation                              | Name                    | Rows  | Bytes | Cost (%CPU)| Time     |    TQ  |IN-OUT| PQ Distrib |
-----------------------------------------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                       |                         |     4 |  1076 |     8   (0)| 00:00:01 |        |      |            |
|   1 |  CONCATENATION                         |                         |       |       |            |          |        |      |            |
|   2 |   PX COORDINATOR                       |                         |       |       |            |          |        |      |            |
|   3 |    PX SEND QC (RANDOM)                 | :TQ20001                |     2 |   538 |     4   (0)| 00:00:01 |  Q2,01 | P->S | QC (RAND)  |
|   4 |     TABLE ACCESS BY INDEX ROWID BATCHED| TAB311                  |     2 |   538 |     4   (0)| 00:00:01 |  Q2,01 | PCWP |            |
|   5 |      BUFFER SORT                       |                         |       |       |            |          |  Q2,01 | PCWC |            |
|   6 |       PX RECEIVE                       |                         |     1 |       |     3   (0)| 00:00:01 |  Q2,01 | PCWP |            |
|   7 |        PX SEND HASH (BLOCK ADDRESS)    | :TQ20000                |     1 |       |     3   (0)| 00:00:01 |        | S->P | HASH (BLOCK|
|*  8 |         INDEX RANGE SCAN               | TAB311_IX_SUB_ITEM_CODE |     1 |       |     3   (0)| 00:00:01 |        |      |            |
|   9 |   PX COORDINATOR                       |                         |       |       |            |          |        |      |            |
|  10 |    PX SEND QC (RANDOM)                 | :TQ10001                |     2 |   538 |     4   (0)| 00:00:01 |  Q1,01 | P->S | QC (RAND)  |
|  11 |     TABLE ACCESS BY INDEX ROWID BATCHED| TAB311                  |     2 |   538 |     4   (0)| 00:00:01 |  Q1,01 | PCWP |            |
|  12 |      BUFFER SORT                       |                         |       |       |            |          |  Q1,01 | PCWC |            |
|  13 |       PX RECEIVE                       |                         |     1 |       |     3   (0)| 00:00:01 |  Q1,01 | PCWP |            |
|  14 |        PX SEND HASH (BLOCK ADDRESS)    | :TQ10000                |     1 |       |     3   (0)| 00:00:01 |        | S->P | HASH (BLOCK|
|* 15 |         INDEX RANGE SCAN               | TAB311_PK               |     1 |       |     3   (0)| 00:00:01 |        |      |            |
-----------------------------------------------------------------------------------------------------------------------------------------------

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

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

Note
-----
   - dynamic statistics used: dynamic sampling (level=AUTO (SYSTEM))
   - Degree of Parallelism is 4 because of hint

OR_EXPANDでU内部的にUNION-ALLに書き換えてパラレルクエrーにすると。。。。。。おーーーーー。違う！！！ Id=1にあるPX COORDINATOR だけになってますね。各SELECT文もパラレル化されているようです。:)
結構違いますね。やはり、使うなら、USE_CANTATよりOR_EXPANDのようが良さそうですね。これで思い出した！　ORDERED　と LEADINGヒントのような感じですかねー。同じ機能を持つ後発ヒントの方が色々と使い勝手が良くなってることって意外に多いです！

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

経過: 00:00:00.14

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

-------------------------------------------------------------------------------------------------------------------------------------------------
| Id  | Operation                                | Name                    | Rows  | Bytes | Cost (%CPU)| Time     |    TQ  |IN-OUT| PQ Distrib |
-------------------------------------------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                         |                         |     4 |  1160 |     8   (0)| 00:00:01 |        |      |            |
|   1 |  PX COORDINATOR                          |                         |       |       |            |          |        |      |            |
|   2 |   PX SEND QC (RANDOM)                    | :TQ10002                |     4 |  1160 |     8   (0)| 00:00:01 |  Q1,02 | P->S | QC (RAND)  |
|   3 |    BUFFER SORT                           |                         |     4 |  1160 |            |          |  Q1,02 | PCWP |            |
|   4 |     VIEW                                 | VW_ORE_5F0E22D2         |     4 |  1160 |     8   (0)| 00:00:01 |  Q1,02 | PCWP |            |
|   5 |      UNION-ALL                           |                         |       |       |            |          |  Q1,02 | PCWP |            |
|   6 |       TABLE ACCESS BY INDEX ROWID BATCHED| TAB311                  |     2 |   538 |     4   (0)| 00:00:01 |  Q1,02 | PCWP |            |
|   7 |        BUFFER SORT                       |                         |       |       |            |          |  Q1,02 | PCWC |            |
|   8 |         PX RECEIVE                       |                         |     1 |       |     3   (0)| 00:00:01 |  Q1,02 | PCWP |            |
|   9 |          PX SEND HASH (BLOCK ADDRESS)    | :TQ10000                |     1 |       |     3   (0)| 00:00:01 |  Q1,00 | S->P | HASH (BLOCK|
|  10 |           PX SELECTOR                    |                         |       |       |            |          |  Q1,00 | SCWC |            |
|* 11 |            INDEX RANGE SCAN              | TAB311_PK               |     1 |       |     3   (0)| 00:00:01 |  Q1,00 | SCWP |            |
|* 12 |       TABLE ACCESS BY INDEX ROWID BATCHED| TAB311                  |     2 |   538 |     4   (0)| 00:00:01 |  Q1,02 | PCWP |            |
|  13 |        BUFFER SORT                       |                         |       |       |            |          |  Q1,02 | PCWC |            |
|  14 |         PX RECEIVE                       |                         |     1 |       |     3   (0)| 00:00:01 |  Q1,02 | PCWP |            |
|  15 |          PX SEND HASH (BLOCK ADDRESS)    | :TQ10001                |     1 |       |     3   (0)| 00:00:01 |  Q1,01 | S->P | HASH (BLOCK|
|  16 |           PX SELECTOR                    |                         |       |       |            |          |  Q1,01 | SCWC |            |
|* 17 |            INDEX RANGE SCAN              | TAB311_IX_SUB_ITEM_CODE |     1 |       |     3   (0)| 00:00:01 |  Q1,01 | SCWP |            |
-------------------------------------------------------------------------------------------------------------------------------------------------

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

  11 - access("UNIQUE_ID"=1)
  12 - filter(LNNVL("UNIQUE_ID"=1))
  17 - access("SUB_ITEM_CODE"='0001000000')

Note
-----
   - dynamic statistics used: dynamic sampling (level=AUTO (SYSTEM))
   - Degree of Parallelism is 4 because of hint

前々回手動でunionに書き換えたSQLをパラレルにするとどうなるだろう。。。
ほう。

select
  /*+
    parallel(4)
  */
  *
from
  tab311
where
  unique_id = 1
union
select
  *
from
  tab311
where
  sub_item_code = '0001000000';

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

---------------------------------------------------------------------------------------------------------------------------------------------------
| Id  | Operation                                  | Name                    | Rows  | Bytes | Cost (%CPU)| Time     |    TQ  |IN-OUT| PQ Distrib |
---------------------------------------------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                           |                         |     5 |  1345 |    11  (19)| 00:00:01 |        |      |            |
|   1 |  PX COORDINATOR                            |                         |       |       |            |          |        |      |            |
|   2 |   PX SEND QC (RANDOM)                      | :TQ10003                |     5 |  1345 |    11  (19)| 00:00:01 |  Q1,03 | P->S | QC (RAND)  |
|   3 |    HASH UNIQUE                             |                         |     5 |  1345 |    11  (19)| 00:00:01 |  Q1,03 | PCWP |            |
|   4 |     PX RECEIVE                             |                         |     5 |  1345 |    11  (19)| 00:00:01 |  Q1,03 | PCWP |            |
|   5 |      PX SEND HASH                          | :TQ10002                |     5 |  1345 |    11  (19)| 00:00:01 |  Q1,02 | P->P | HASH       |
|   6 |       HASH UNIQUE                          |                         |     5 |  1345 |    11  (19)| 00:00:01 |  Q1,02 | PCWP |            |
|   7 |        UNION-ALL                           |                         |       |       |            |          |  Q1,02 | PCWP |            |
|   8 |         TABLE ACCESS BY INDEX ROWID BATCHED| TAB311                  |     3 |   807 |     4   (0)| 00:00:01 |  Q1,02 | PCWP |            |
|   9 |          PX RECEIVE                        |                         |     3 |       |     3   (0)| 00:00:01 |  Q1,02 | PCWP |            |
|  10 |           PX SEND HASH (BLOCK ADDRESS)     | :TQ10000                |     3 |       |     3   (0)| 00:00:01 |  Q1,00 | S->P | HASH (BLOCK|
|  11 |            PX SELECTOR                     |                         |       |       |            |          |  Q1,00 | SCWC |            |
|* 12 |             INDEX RANGE SCAN               | TAB311_PK               |     3 |       |     3   (0)| 00:00:01 |  Q1,00 | SCWP |            |
|  13 |         TABLE ACCESS BY INDEX ROWID BATCHED| TAB311                  |     2 |   538 |     5   (0)| 00:00:01 |  Q1,02 | PCWP |            |
|  14 |          PX RECEIVE                        |                         |     2 |       |     3   (0)| 00:00:01 |  Q1,02 | PCWP |            |
|  15 |           PX SEND HASH (BLOCK ADDRESS)     | :TQ10001                |     2 |       |     3   (0)| 00:00:01 |  Q1,01 | S->P | HASH (BLOCK|
|  16 |            PX SELECTOR                     |                         |       |       |            |          |  Q1,01 | SCWC |            |
|* 17 |             INDEX RANGE SCAN               | TAB311_IX_SUB_ITEM_CODE |     2 |       |     3   (0)| 00:00:01 |  Q1,01 | SCWP |            |
---------------------------------------------------------------------------------------------------------------------------------------------------

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

  12 - access("UNIQUE_ID"=1)
  17 - access("SUB_ITEM_CODE"='0001000000')

Note
-----
   - dynamic statistics used: dynamic sampling (level=AUTO (SYSTEM))
   - Degree of Parallelism is 4 because of hint

同じく、前々回手動でunion all + フィルタ条件追加に書き換えたSQLをパラレルにするとどうなるだろう。。。
おおおおおーーーーーーっと。これはCONCATENATIONの実行計画にそっくりですね。CONCATENATIONの部分がUNION-ALLになっている程度の違い。2つのPX COORDINATOR がある点も共通しています。。。むむ。

このSQLをOR_EXPANDの実行計画と同じようにするには......あ！　あれだ！

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

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

-----------------------------------------------------------------------------------------------------------------------------------------------
| Id  | Operation                              | Name                    | Rows  | Bytes | Cost (%CPU)| Time     |    TQ  |IN-OUT| PQ Distrib |
-----------------------------------------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                       |                         |     4 |  1076 |     9   (0)| 00:00:01 |        |      |            |
|   1 |  UNION-ALL                             |                         |       |       |            |          |        |      |            |
|   2 |   PX COORDINATOR                       |                         |       |       |            |          |        |      |            |
|   3 |    PX SEND QC (RANDOM)                 | :TQ10001                |     3 |   807 |     4   (0)| 00:00:01 |  Q1,01 | P->S | QC (RAND)  |
|   4 |     TABLE ACCESS BY INDEX ROWID BATCHED| TAB311                  |     3 |   807 |     4   (0)| 00:00:01 |  Q1,01 | PCWP |            |
|   5 |      BUFFER SORT                       |                         |       |       |            |          |  Q1,01 | PCWC |            |
|   6 |       PX RECEIVE                       |                         |     3 |       |     3   (0)| 00:00:01 |  Q1,01 | PCWP |            |
|   7 |        PX SEND HASH (BLOCK ADDRESS)    | :TQ10000                |     3 |       |     3   (0)| 00:00:01 |  Q1,00 | S->P | HASH (BLOCK|
|   8 |         PX SELECTOR                    |                         |       |       |            |          |  Q1,00 | SCWC |            |
|*  9 |          INDEX RANGE SCAN              | TAB311_PK               |     3 |       |     3   (0)| 00:00:01 |  Q1,00 | SCWP |            |
|  10 |   PX COORDINATOR                       |                         |       |       |            |          |        |      |            |
|  11 |    PX SEND QC (RANDOM)                 | :TQ20001                |     1 |   269 |     5   (0)| 00:00:01 |  Q2,01 | P->S | QC (RAND)  |
|* 12 |     TABLE ACCESS BY INDEX ROWID BATCHED| TAB311                  |     1 |   269 |     5   (0)| 00:00:01 |  Q2,01 | PCWP |            |
|  13 |      BUFFER SORT                       |                         |       |       |            |          |  Q2,01 | PCWC |            |
|  14 |       PX RECEIVE                       |                         |     2 |       |     3   (0)| 00:00:01 |  Q2,01 | PCWP |            |
|  15 |        PX SEND HASH (BLOCK ADDRESS)    | :TQ20000                |     2 |       |     3   (0)| 00:00:01 |  Q2,00 | S->P | HASH (BLOCK|
|  16 |         PX SELECTOR                    |                         |       |       |            |          |  Q2,00 | SCWC |            |
|* 17 |          INDEX RANGE SCAN              | TAB311_IX_SUB_ITEM_CODE |     2 |       |     3   (0)| 00:00:01 |  Q2,00 | SCWP |            |
-----------------------------------------------------------------------------------------------------------------------------------------------

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

   9 - access("UNIQUE_ID"=1)
  12 - filter(LNNVL("UNIQUE_ID"=1))
  17 - access("SUB_ITEM_CODE"='0001000000')

Note
-----
   - dynamic statistics used: dynamic sampling (level=AUTO (SYSTEM))
   - Degree of Parallelism is 4 because of hint

ということで、
前々回手動でunion all + フィルタ条件追加に書き換えたSQLを単純にパラレルクエリーにしてもイマイチだったので、OR_EXPANDのような実行計画にするために、インラインビューにしてみました！！！　どうでしょう？　OR_EXPANDの実行計画と同じようになりました。
ポイントは、前々回のOR_EXPANDの実行計画中に現れるインラインビュー　VW_ORE_5F0E22D2　です。内部的にインラインビューを追加してるんですよね！　OR_EXPANDのUNION ALL書き換え。
インラインビュー化したことで、Id=4にビューが登場しています。OR_EXPANDでは、VW_ORE_*　と名付けられるOR_EXPANDトランスフォームにより追加されるインラインビューと同じ役割を持っていますが、内部的に書き換えられて追加されるインラインビューとは異なり動的に名称が付加されません。

インラインビューが決めて！　というか、意外と忘れがちなので注意しないとね。

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

経過: 00:00:00.03

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

-------------------------------------------------------------------------------------------------------------------------------------------------
| Id  | Operation                                | Name                    | Rows  | Bytes | Cost (%CPU)| Time     |    TQ  |IN-OUT| PQ Distrib |
-------------------------------------------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                         |                         |     4 |  1160 |     9   (0)| 00:00:01 |        |      |            |
|   1 |  PX COORDINATOR                          |                         |       |       |            |          |        |      |            |
|   2 |   PX SEND QC (RANDOM)                    | :TQ10002                |     4 |  1160 |     9   (0)| 00:00:01 |  Q1,02 | P->S | QC (RAND)  |
|   3 |    BUFFER SORT                           |                         |     4 |  1160 |            |          |  Q1,02 | PCWP |            |
|   4 |     VIEW                                 |                         |     4 |  1160 |     9   (0)| 00:00:01 |  Q1,02 | PCWP |            |
|   5 |      UNION-ALL                           |                         |       |       |            |          |  Q1,02 | PCWP |            |
|   6 |       TABLE ACCESS BY INDEX ROWID BATCHED| TAB311                  |     3 |   807 |     4   (0)| 00:00:01 |  Q1,02 | PCWP |            |
|   7 |        BUFFER SORT                       |                         |       |       |            |          |  Q1,02 | PCWC |            |
|   8 |         PX RECEIVE                       |                         |     3 |       |     3   (0)| 00:00:01 |  Q1,02 | PCWP |            |
|   9 |          PX SEND HASH (BLOCK ADDRESS)    | :TQ10000                |     3 |       |     3   (0)| 00:00:01 |  Q1,00 | S->P | HASH (BLOCK|
|  10 |           PX SELECTOR                    |                         |       |       |            |          |  Q1,00 | SCWC |            |
|* 11 |            INDEX RANGE SCAN              | TAB311_PK               |     3 |       |     3   (0)| 00:00:01 |  Q1,00 | SCWP |            |
|* 12 |       TABLE ACCESS BY INDEX ROWID BATCHED| TAB311                  |     1 |   269 |     5   (0)| 00:00:01 |  Q1,02 | PCWP |            |
|  13 |        BUFFER SORT                       |                         |       |       |            |          |  Q1,02 | PCWC |            |
|  14 |         PX RECEIVE                       |                         |     2 |       |     3   (0)| 00:00:01 |  Q1,02 | PCWP |            |
|  15 |          PX SEND HASH (BLOCK ADDRESS)    | :TQ10001                |     2 |       |     3   (0)| 00:00:01 |  Q1,01 | S->P | HASH (BLOCK|
|  16 |           PX SELECTOR                    |                         |       |       |            |          |  Q1,01 | SCWC |            |
|* 17 |            INDEX RANGE SCAN              | TAB311_IX_SUB_ITEM_CODE |     2 |       |     3   (0)| 00:00:01 |  Q1,01 | SCWP |            |
-------------------------------------------------------------------------------------------------------------------------------------------------

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

  11 - access("UNIQUE_ID"=1)
  12 - filter(LNNVL("UNIQUE_ID"=1))
  17 - access("SUB_ITEM_CODE"='0001000000')

Note
-----
   - dynamic statistics used: dynamic sampling (level=AUTO (SYSTEM))
   - Degree of Parallelism is 4 because of hint

4月はじめだと言うのに、夏日とか、北の方面の友人からは31度だとか、最近の異常気象ほんとに農家泣かせな感じ。最近は天気予想が細かい範囲ででるので以前より対応しやすいのかもしれないけど。
こんな、陽気だとぶらりと湘南あたりからリモートワークしたいw

ではまた。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

         1 0001000001                     fooooooooooooo1                                             0

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

手動書き換え　UNION

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

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

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

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

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

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

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

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

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

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

では、次回へつづく

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

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

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

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

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

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

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

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

SCOTT@orclpdb1> select count(1) from tab311

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

経過: 00:00:00.09

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

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

経過: 00:00:00.01

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

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

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

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

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

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

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

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

経過: 00:00:00.00

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

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

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

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


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

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

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

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

Oracle vagrant-projects

今日は約3ヶ月振りにVIrtualBoxの起動やら、Oracle VMの起動でハマって、このあたりの環境どうしようかなあぁ

と思いつつ 21cとかもあるしなぁと考えていたら。横目でみつつも、大人の事情でスルーしていたやつが結構育ってて来てたので、これやるのもいいかなぁと。まだ軽く調べ始めたところだが、来月早々にメインマシン変えるからそのあとな。

ひとまず、メモ

Oracle Vagrant-projects

https://github.com/oracle/vagrant-projects

投稿日時 2022年3月21日 (月) 20時40分 Oracle Database 11g Release 2, VirtualBox, Oracle Database 12c release 1, Oracle Database 12c Release 2, Oracle Database 18c, Oracle Database 19c, Oracle Database 21c, Vagrant | 固定リンク | 0 | コメント (0)

Difference of Initialization Parameters between 11gR2 (11.2.0.4.0) and 19c (19.3.0.0.0) - including hidden params

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

ということで、今回はめでたくサポート終了となった11gR2と19cのパラメータ差分を確認してみた（何年振りだろうこれw）。21cがでたらまたやる予定。

11gR2 : 11.2.0.4.0
19c   : 19.3.0.0.0

で比較した結果は以下

Difference of Initialization Parameters between 11gR2 (11.2.0.4.0) and 19c (19.3.0.0.0)

どうやればこの差分が作れるかというと、DBリンクでもできるけどそんなことしてません。というかやりたくないw　ので、旧リリースでパラメータをcsv出力して(comma区切りではないですがw)、19c側で外部表として参照して差分を出力.

パラメータの取り出し。linesizeは適当に調整する必要はあるかも

ORACLE-ORCLCDB@SYS> !cat paramout.sql
set linesize 300
set trimspool on
set head off
set feedback off
set timi off
set termout off
set time off
set timi off
set pagesize 0
spo &1..csv


SELECT
   TRIM(a.ksppinm)
  ||'|'||TRIM(a.ksppdesc)||'|'
FROM
  x$ksppi a
/
spo off
undefine 1

上記スクリプトの実行、結果の例

ORACLE-ORCLCDB@SYS> @paramout 11.2.0.4.0_parameters
ORACLE-ORCLCDB@SYS> !cat 11.2.0.4.0_parameters.csv
_appqos_qt|System Queue time retrieval interval|
_ior_serialize_fault|inject fault in the ior serialize code|
_shutdown_completion_timeout_mins|minutes for shutdown operation to wait for sessions to complete|
_inject_startup_fault|inject fault in the startup code|
_latch_recovery_alignment|align latch recovery structures|
_spin_count|Amount to spin waiting for a latch|
_latch_miss_stat_sid|Sid of process for which to collect latch stats|
_max_sleep_holding_latch|max time to sleep while holding a latch|
_max_exponential_sleep|max sleep during exponential backoff|
_other_wait_threshold|threshold wait percentage for event wait class Other|
_other_wait_event_exclusion|exclude event names from _other_wait_threshold calculations|
・・・略・・・

外部表の元ネタであるファイル置き場用ディレクト作製とディレクトリオブジェクトの作製、そして、元ネタの配置は以下の通り

ORACLE-ORCLCDB@SYS> !pwd
/home/oracle
ORACLE-ORCLCDB@SYS> !ls -l exttab
合計 488
-rw-rw-r--. 1 oracle oracle 194319  3月 29 21:26 11.2.0.4_parameters.csv

ORACLE-ORCLCDB@SYS> CREATE DIRECTORY ext_tab AS '/home/oracle/exttab';

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

ORACLE-ORCLCDB@SYS> l
  1  CREATE TABLE ksppi_11_2_0_4_0 (
  2  	ksppinm VARCHAR2(80)
  3  	,ksppdesc VARCHAR2(255)
  4  )
  5  ORGANIZATION EXTERNAL (
  6  	TYPE ORACLE_LOADER
  7  	DEFAULT DIRECTORY ext_tab
  8  	ACCESS PARAMETERS (
  9  		RECORDS DELIMITED BY NEWLINE
 10  		FIELDS TERMINATED BY '|'
 11  			(
 12  				ksppinm
 13  				,ksppdesc
 14  			)
 15  		)
 16  	LOCATION (
 17  		'11.2.0.4_parameters.csv'
 18  	)
 19* )
ORACLE-ORCLCDB@SYS> /

表が作成されました。

ORACLE-ORCLCDB@SYS> SELECT COUNT(1) FROM ksppi_11_2_0_4_0;

  COUNT(1)
----------
      2915

以下のスクリプトでcdb$rootのx$ksppiと前述の外部表をfull outer joinして差分をhtml形式で出力すればできあがり

col "11g R2 11.2.0.4.0" for a17
col "19c 19.3.0.0.0" for a17
set pagesize 10000
set timi off
set feed off
set markup html on spool on
spo param-diff.html
SELECT
	CASE
		WHEN prev.ksppinm = curr.ksppinm
		OR (
			prev.ksppinm IS NULL
			AND curr.ksppinm IS NOT NULL
		)
		THEN curr.ksppinm
		ELSE prev.ksppinm
	END AS ksppinm
	,CASE
		WHEN prev.ksppinm = curr.ksppinm THEN '○'
		WHEN prev.ksppinm IS NOT NULL AND curr.ksppinm IS NULL THEN '○'
		ELSE 'n/a'
	END AS "11g R2 11.2.0.4.0"
	,CASE
		WHEN prev.ksppinm = curr.ksppinm THEN '○'
		WHEN prev.ksppinm IS NULL AND curr.ksppinm IS NOT NULL THEN '○'
		ELSE 'n/a'
	END AS "19c 19.3.0.0.0"
	,CASE
		WHEN prev.ksppdesc = curr.ksppdesc THEN curr.ksppdesc
		WHEN prev.ksppinm IS NULL AND curr.ksppinm IS NOT NULL THEN curr.ksppdesc
		WHEN prev.ksppinm iS NOT NULL AND curr.ksppinm IS NULL
			THEN prev.ksppdesc
			ELSE prev.ksppdesc
	END AS kspdesc
	,CASE
		WHEN prev.ksppdesc = curr.ksppdesc
			OR (prev.ksppinm IS NULL AND curr.ksppinm IS NOT NULL)
			OR (prev.ksppinm IS NOT NULL AND curr.ksppinm IS NULL)
		THEN NULL
		ELSE curr.ksppdesc
	END AS "New description"
FROM
	(
		SELECT * FROM x$ksppi WHERE con_id = 0
	) curr
FULL OUTER JOIN ksppi_11_2_0_4_0 prev
ON
	curr.ksppinm = prev.ksppinm
ORDER BY
	1
;
spool off
set feed on
set set markup html off

露天風呂♨️行きたい...

・Difference of Initialization Parameters between 11g r1 (11.1.0.6.0) and 12c r1 (12.1.0.1.0) - including hidden params
・Difference of Initialization Parameters between 11g and 12c #2
・19cの初期化パラメータ数や隠しパラメータ数などどう変化したのか、久々に確認してみた

投稿日時 2021年3月31日 (水) 00時00分 Oracle, FAQ, Oracle Database 12c Release 2, Oracle Database 19c | 固定リンク | 0 | コメント (0)

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

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

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

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

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

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

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

経過: 00:00:00.06

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

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

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

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

all/dba/user_tab_columns

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

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

どこかわかります？

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

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

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

LONG型

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

以下のような感じで。

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

Table created.

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

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

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

ではまた。

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

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

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

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

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

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


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

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

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

PL/SQL procedure successfully completed.

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

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

Function created.

SQL>

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

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

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

SQL>

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

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

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

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

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

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

Table created.

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

Table altered.

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

PL/SQL procedure successfully completed.

Elapsed: 00:00:12.28

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

PL/SQL procedure successfully completed.

Elapsed: 00:00:02.51

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

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

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

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

Elapsed: 00:00:00.06

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

Explained.

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

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

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

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

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

Explained.

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

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

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

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

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

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

ハッシュパーティションでのデータの偏り / FAQ

ぼやき漫才みたいな感じですが、Oracleに限らず、ハッシュパーティションでパーティション間のデータを均一にしたいなら、ユニークな値かそれに準ずる列を選ぶべきなわけですが、なにを間違ってしまったのか、稀ではありますが、少々残念なことになっていすることもあります。

とは言え、早めに気づけば影響も小さくて済むわけで:)

というわけで、今回はそんなおはなし。

id_code列の値はユニーク

ORCL@SCOTT> select count(*),count(distinct id_code) from org;

  COUNT(*) COUNT(DISTINCTID_CODE)
---------- ----------------------
    400000                 400000

type列の値は、一意性がなくカーディナリティーも低い、かつ、大きな偏りがある。。

ORCL@SCOTT> select type,count(1) from org group by type;

    type   COUNT(1)
---------- ----------
         1      60000
         2      60000
         9      60000
         0     220000

ハッシュパーティションを選択する主な理由は、パーティションへのデータの均一分散なので、列の値がユニークな列をパーティションキーとしてパーティション化することが多いわけですが、。。

以下は、ハッシュキーに一意な値を持つ列を選択した場合の例

ORCL@SCOTT> r
  1  create table hash_p_tab
  2  partition by hash(id_code)
  3  (
  4    partition hash_p_tab_p1
  5    ,partition hash_p_tab_p2
  6    ,partition hash_p_tab_p3
  7    ,partition hash_p_tab_p4
  8  )
  9  as select
 10    id_code
 11    ,foo
 12    ,type
 13  from
 14*   org

Table created.

ORCL@SCOTT> alter table hash_p_tab add constraint gpk_hash_p_tab primary key(id_code) using index global;

Table altered.

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


ORCL@SCOTT> select table_name,partition_name,num_rows from user_tab_partitions order by 1,2;

TABLE_NAME                     PARTITION_NAME                   NUM_ROWS
------------------------------ ------------------------------ ----------
HASH_P_TAB                     HASH_P_TAB_P1                       99901
HASH_P_TAB                     HASH_P_TAB_P2                      100194
HASH_P_TAB                     HASH_P_TAB_P3                      100056
HASH_P_TAB                     HASH_P_TAB_P4                       99849

しかし、値の分布に偏りのあるカーディナリティの低い列を選んで残念なことになっているケースも稀にあったりします。

なぜ、ハッシュキーにこの列を選んだんだ! みたいな。。。

そんな時は、設計した人に聞くしかないです。何がやりたかったのかを。。。私に聞かれてもハッシュキーの選択をミスったんですよねーたぶん、としか言えないので。

ORCL@SCOTT> r
  1  create table hash_p_tab_skew
  2  partition by hash(type)
  3  (
  4    partition hash_p_tab_skew_p1
  5    ,partition hash_p_tab_skew_p2
  6    ,partition hash_p_tab_skew_p3
  7    ,partition hash_p_tab_skew_p4
  8  )
  9  as select
 10    id_code
 11    ,foo
 12    ,type
 13  from
 14*   org

Table created.

ORCL@SCOTT> alter table hash_p_tab_skew add constraint gpk_hash_p_tab_skew primary key(id_code) using index global;
 
Table altered.

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

PL/SQL procedure successfully completed.

ORCL@SCOTT> select table_name,partition_name,num_rows from user_tab_partitions where table_name = upper('hash_p_tab_skew') order by 1,2

TABLE_NAME                     PARTITION_NAME                   NUM_ROWS
------------------------------ ------------------------------ ----------
HASH_P_TAB_SKEW                HASH_P_TAB_SKEW_P1                      0
HASH_P_TAB_SKEW                HASH_P_TAB_SKEW_P2                 280000
HASH_P_TAB_SKEW                HASH_P_TAB_SKEW_P3                  60000
HASH_P_TAB_SKEW                HASH_P_TAB_SKEW_P4                  60000

で、データを均一にパーティションに分散させることをなんとなーく、イメージしつつ、上記のようなミスをしてしまうと、パラレルクエリーなどで最もデータの多いパーティションの処理時間に引っ張られて想定より処理時間が長くなるなんてことも。。。あるわけで

例がイケてないけど（気にしないでw）、パラレルサーバーのスレーブ間でbuffer gets部分を見ていただくと偏りはわかりやすいはず。(赤字部分）:)

偏りあり

orcl2@SCOTT> @sql_skew
  1  select
  2    /*+
  3      monitor
  4      parallel(4)
  5    */
  6    count(1)
  7  from
  8    hash_p_tab_skew t01
  9    inner join hash_p_tab_skew2 t02
 10    on
 11      t01.id_code = t02.id_code
 12*     and t01.type = t02.type


Parallel Execution Details (DOP=4 , Servers Allocated=4)
==========================================================================================
|      Name      | Type  | Server# | Elapsed |   Cpu   |  Other   | Buffer | Wait Events |
|                |       |         | Time(s) | Time(s) | Waits(s) |  Gets  | (sample #)  |
==========================================================================================
| PX Coordinator | QC    |         |    0.02 |    0.00 |     0.02 |     72 |             |
| p000           | Set 1 |       1 |    0.18 |    0.17 |     0.01 |   1940 |             |
| p001           | Set 1 |       2 |    0.05 |    0.05 |     0.00 |    448 |             |
| p002           | Set 1 |       3 |    0.05 |    0.05 |     0.00 |    448 |             |
| p003           | Set 1 |       4 |    0.00 |    0.00 |     0.00 |        |             |
==========================================================================================

偏りの悪影響のイメージはこんな感じ
20190321-165450

偏りなし

orcl2@SCOTT> @sql_noskew
  1  select
  2    /*+
  3      monitor
  4      parallel(4)
  5    */
  6    count(1)
  7  from
  8    hash_p_tab t01
  9    inner join hash_p_tab2 t02
 10    on
 11      t01.id_code = t02.id_code
 12*     and t01.type = t02.type


Parallel Execution Details (DOP=4 , Servers Allocated=4)
==========================================================================================
|      Name      | Type  | Server# | Elapsed |   Cpu   |  Other   | Buffer | Wait Events |
|                |       |         | Time(s) | Time(s) | Waits(s) |  Gets  | (sample #)  |
==========================================================================================
| PX Coordinator | QC    |         |    0.01 |    0.00 |     0.00 |     96 |             |
| p000           | Set 1 |       1 |    0.08 |    0.08 |          |    714 |             |
| p001           | Set 1 |       2 |    0.08 |    0.08 |     0.00 |    714 |             |
| p002           | Set 1 |       3 |    0.08 |    0.07 |     0.01 |    714 |             |
| p003           | Set 1 |       4 |    0.08 |    0.08 |          |    712 |             |
==========================================================================================

パーティション毎にぞれぞれ得手不得手があります。そこんとこを把握したうえで、有効活用したいものですよね。（パーティションもいろいろ進化してきて便利になってきたわけですが、その分わかりにくいところも増えてきて理解するのに大変だったり 18cのも差分は把握しといたほうがいいかw...:)

津島博士のパフォーマンス講座第10回パーティションについて

投稿日時 2019年3月21日 (木) 20時49分チューニング, FAQ, SQL, Oracle Database 11g Release 2, Oracle Database 12c release 1, Oracle Database 12c Release 2, Oracle Database 18c | 固定リンク | 0 | コメント (0)

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

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

まずは、以下のSQL文を。

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

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

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

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

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

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

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

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

Explained.

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

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

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

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

   1 - access("ORDER_ID"<2400)

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

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

Explained.

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

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

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

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

   1 - access("ORDER_ID"<2400)

13 rows selected.

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

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

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

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

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

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

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

ORCL@OE> alter table orders disable constraint orders_customer_id_fk;

Table altered.

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

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

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

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

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

Explained.

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

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

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

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

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

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

ではまた。

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

Wait Events

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

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

Oracle Database Wait Events

PostgreSQL Wait Events

MySQL : 25.12.15.1 Wait Event Summary Tables

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

RDS Oracle 雑多なメモ#17/ FAQ

Oracle DB インスタンスの一般的な DBA タスクに記載されているAmazon RDS OracleとオンプレのOracleの操作方法の違は意外に多く、長年かけて体に染み付いていて、脊髄反応でタイプしてしまうとエラー、あ”〜っなんてこともしばしばw

仕方ないので、慣れるしかないわけですが、脊髄反応でオンプレのコマンドをタイプして、あ”〜っ！　となったことのある個人的な Top5 を備忘録として書いておきます:)
脊髄反応でそんな権限ないよーというショックなエラーうけとる回数を少しでも減らせるようAmazon RDSパッケージのタイプ練習中の日々w （いずれ、うまく切り替えられるようになれるだろうと信じてw

Oracle DB インスタンスの一般的な DBA システムタスク
 Oracle DB インスタンスの一般的な DBA データベースタスク
 Oracle DB インスタンスの一般的な DBA ログタスク
 Oracle DB インスタンスの一般的な DBA のその他のタスク

個人的に、つい、オンプレと同じ操作をして、エラーになってしまった Top5 w

1位. sysオブジェクトへ権限付与で grant文をタイプしてしまう。
2位. つい、alter system kill session をタイプしてしまう。
3位. オンラインログファイルを切り替えたり、追加、削除で、alter database add logfile..をタイプしたり、alter system switch logfileをタイプしてしまう。
4位. ディレクトリオブジェクトを作成しようとして、create directory...をタイプしてしまう。
5位. rmanの検証コマンドを使おうとして、生のrmanは使えなかった、と気づくw

私がつい、脊髄反応でオリジナルのコマンドをタイプして、エラー？　なぬ？　あ、RDSではAmazon RDS向けのパッケージ使うんだった！！と　気づく典型的な操作の数々(^^;;;;; 長年しみついた手癖で脊髄反応しちゃうのでどうしようもないのですw
みなさんはどのコマンドで、あ”！　となることが多いのでしょうか？（おそらく Top.1は、私と同じ、grant関連ではないでしょうか？w 一番使う機会が多いですからね）

話は少々脱線しますが、上記操作を行うAmazon RDSパッケージでデータベースサイズが大きくなると処理時間を要するものもそこそこあります。
Amazon RDSパッケージで提供されていても内部ではOracleの対応する機能を実行しているわけで、処理時間を要するタイプの操作を行った場合、処理の進行状況を確認確認したくなることもあります。そんな時は、v$session_longops を参照するとよいのではないかと思います。全ての機能が詳細な情報をv$session_longopsに載せてくれるわけではないですが。。（オンプレのOracle Databaseを利用していたという方でも、v$session_longops を使ったことはないなんてことも少なくないような気がします)

RDS Oracleでも　v$session_longops ビューは効果的に利用できる例として、datapumpやOracle DB インスタンスの一般的な DBA データベースタスクでも解説されているrmanの検証コマンドの実行時など、操作にそれなりの時間を要するタイプのものです。（datapumpについては、詳細なステータスを記録していないようなので、datapumpのlogを覗くほうが状況確認としては便利ではありますが、一応、datapumpもv$session_longopsには記録されます。この点はOracle由来なのでオンプレでも同じです。）

一例として、それなりに時間を要する処理の代表格、Amazon RDS プロシージャ rdsadmin.rdsadmin_rman_util.validate_database(Oracle DB インスタンスの一般的な DBA データベースタスク参照）を利用した関連ファイル検証の進行状況をv$session_longopsを利用してモニターリング:)

今回利用したRDS Oracleのデータファイルはぞれぞれ以下のようなサイズです。

SQL> r
  1  select
  2    tablespace_name
  3    ,file_name
  4    ,sum(bytes)/1024/1024 "MB"
  5  from
  6    dba_data_files
  7  group by
  8    tablespace_name
  9    ,file_name
 10  union all
 11  select
 12    tablespace_name
 13    ,file_name
 14    ,sum(bytes)/1024/1024 "MB"
 15  from
 16    dba_temp_files
 17  group by
 18    tablespace_name
 19*   ,file_name

TABLESPACE_NAME                FILE_NAME                                                            MB
------------------------------ ------------------------------------------------------------ ----------
SYSAUX                         /rdsdbdata/db/ORCL_A/datafile/o1_mf_sysaux_fxpjf1nv_.dbf       498.9375
USERS                          /rdsdbdata/db/ORCL_A/datafile/o1_mf_users_fxpjf3d2_.dbf             100
UNDO_T1                        /rdsdbdata/db/ORCL_A/datafile/o1_mf_undo_t1_fxpjf2lx_.dbf           290
RDSADMIN                       /rdsdbdata/db/ORCL_A/datafile/o1_mf_rdsadmin_fxpkkz9k_.dbf            7
SYSTEM                         /rdsdbdata/db/ORCL_A/datafile/o1_mf_system_fxpjdxws_.dbf            500
TEMP                           /rdsdbdata/db/ORCL_A/datafile/o1_mf_temp_fxpjf34b_.tmp              100
                                                                                            ----------
sum                                                                                          1495.9375

事前に作成しておいたスクリプトでAmazon RDS プロシージャ rdsadmin.rdsadmin_rman_util.validate_databaseの処理状況をモニタリングしています（スクリプトの例は後半参照のこと）

SQL> @show_validate_status

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

SQL> /

NOW                                     SID    SERIAL# OPNAME                            CONTEXT      SOFAR  TOTALWORK     % done
-------------------------------- ---------- ---------- ------------------------------ ---------- ---------- ---------- ----------
19-02-11 09:42:18.217701 +00:00         665      51783 RMAN: full datafile backup              1     123322     178680      69.02

SQL> /

NOW                                     SID    SERIAL# OPNAME                            CONTEXT      SOFAR  TOTALWORK     % done
-------------------------------- ---------- ---------- ------------------------------ ---------- ---------- ---------- ----------
19-02-11 09:42:19.298741 +00:00         665      51783 RMAN: full datafile backup              1     139452     178680      78.05

SQL> /

NOW                                     SID    SERIAL# OPNAME                            CONTEXT      SOFAR  TOTALWORK     % done
-------------------------------- ---------- ---------- ------------------------------ ---------- ---------- ---------- ----------
19-02-11 09:42:20.367723 +00:00         665      51783 RMAN: full datafile backup              1     156028     178680      87.32

SQL> /

NOW                                     SID    SERIAL# OPNAME                            CONTEXT      SOFAR  TOTALWORK     % done
-------------------------------- ---------- ---------- ------------------------------ ---------- ---------- ---------- ----------
19-02-11 09:42:21.289310 +00:00         665      51783 RMAN: full datafile backup              1     170428     178680      95.38

SQL> /

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

SQL> 
SQL> !cat show_validate_status.sql
col "NOW" for a32
col opname for a30
SELECT
  systimestamp AS "NOW"
  ,sid
  ,serial#
  ,opname
  ,context
  ,sofar
  ,totalwork
  ,round(sofar / totalwork * 100, 2) "% done"
FROM
  v$session_longops
WHERE
  opname LIKE 'RMAN%'
  AND opname NOT LIKE '%aggregate%'
  AND sofar != totalwork
  AND totalwork != 0;

投稿日時 2019年2月12日 (火) 01時00分 PL/SQL, FAQ, SQL, Oracle Database 11g Release 2, Oracle Database 12c release 1, Oracle Database 12c Release 2, AWS, RDS | 固定リンク | 0 | コメント (0) | トラックバック (0)

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

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

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

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

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

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

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

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

SQL> 
SQL> !echo $NLS_LANG
Japanese_Japan.AL32UTF8

SQL> !echo $LANG
ja_JP.UTF-8

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

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

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

6行が選択されました。

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

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

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

6行が選択されました。

SQL> set null ""

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

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

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

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

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

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

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

SQL*Plusでcsv出力できるんですよ / FAQ

SQL*Plusでcsv出力する簡単な方法って、意外に知られてないようなのでメモ程度に書いておきます。
自分でもコピペネタとするためにw

SQL> select * from q order by id;

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

SQL> set markup csv on
SQL> select * from q order by id;

"ID","DATA"
1,"テスト"
2,"平成"
3,"abcdbef"
4,"あ"
5,"A"

SQL> set markup csv off

set markup csv on でcsv出力を簡単に取得できます。
これがなかったころはパッケージ作ったりしてましたけど、これなら手間いらず:)

スプールしてファイルに書き出すスクリプトを作っておくと便利です。
以下のスクリプトは &1 パラメータでcsv化する表名称を渡すだけ。

SQL> !cat makecsv.sql
-- 
-- parameter 1 : table name
-- 
set feed off
set timi off
set head off
set termout off
set veri off
set markup csv on
spool loaddata_&1..csv
select * from &1 order by id;
spo off
set markup csv off
set termout on
set head on
set feed on
set veri on
undefine 1

SQL> @makecsv q
SQL> 
SQL> !cat loaddata_q.csv
1,"テスト"
2,"平成"
3,"abcdbef"
4,"あ"
5,"A"

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

備忘録 - ビット演算 / FAQ

備忘録
ビット演算こんな感じでできるはず。

orcl@SCOTT> r
  1  SELECT
  2    d1
  3    ,d2
  4    ,x1
  5    ,x2
  6    ,UTL_RAW.BIT_OR(x1,x2) AS x1_bitor_x2
  7  FROM
  8  (
  9    SELECT
 10      POWER(2, 1) AS d1
 11      , HEXTORAW(TO_CHAR(POWER(2, 1), 'FM0000000X')) AS x1
 12      , POWER(2, 3) AS d2
 13      , HEXTORAW(TO_CHAR(POWER(2, 3), 'FM0000000X')) AS x2
 14    FROM
 15      dual
 16* )

        D1         D2 X1         X2         X1_BITOR_X2
---------- ---------- ---------- ---------- -----------
         2          8 00000002   00000008   0000000A

orcl@SCOTT>

Oracle Database 12cリリース2 PL/SQL Packages and Types Reference 270.3.3 BIT_ORファンクション
 Oracle Database 12c Release 2 SQL Language Reference 7.90 HEXTORAW
Oracle Database 12c Release 2 SQL Language Reference 7.159 POWER
Oracle Database 12c Release 2 SQL Language Reference 7.237 TO_CHAR (number)
Oracle Database 12c Release 2 SQL Language Reference 2.4 Format Models 2.4.1 Number Format Models
Oracle Database 12c Release 2 SQL Language Reference 2.4 Format Models FM

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

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

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

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

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

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

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

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

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

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

なーんでだ？！

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

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

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

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

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

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

Twitterでのやり取り....

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

追加資料1（遅延時）
top

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

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

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

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

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

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

その後のやりとり　（Twitter）

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

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

ふむふむ。

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

追加資料4
strace -c -p

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Dead Connection Detection (FAQ)

最近あまりお目にかかったことなく忘れかけてたのと、12cでは改善されてたのでメモ

12cだと、11g以前に比べ、Dead Connection Detection (DCD) までの時間が大幅に短縮されているよ。
というホワイトペーパー

Dead Connection Detection
http://www.oracle.com/technetwork/database/enterprise-edition/oraclenetdcd-2179641.pdf

投稿日時 2018年4月18日 (水) 10時29分 FAQ, Oracle Database 11g Release 2, Oracle Database 12c Release 2, SQL*Net | 固定リンク | 0 | コメント (0) | トラックバック (0)

textフォーマットのAWRレポートの各セクションをcsvファイル化する際のポイント（メモ）

土日は土日で子供とマイクラのマルチプレイ、平日は平日でなんだか余裕ないぞー。（なんだこれw）　ということで、
Temp落ちネタはFBのTLコピペすれば終わりそうなんだが。。。w
再び、別のネタ。気分転換にはなってないけどwww

textフォーマットのAWRレポートをcsvファイル化する際、各セクションの最終行判定が面倒だったのでメモ（12.2版）
（どんな言語で作ってもこの部分、レポートの文字コード、それに、日付書式でハマることが多い印象w、それに、12.2では、 Timeはsecのみではなく、us/msなど時間の単位の扱いが追加されたので変換を忘れるとハマる）

例えば、Top 10 Foreground Events by Total Wait Timeの場合、
"Top 10 Foreground Events by Total Wait Time"というセクションヘッダーから、次のセクションヘッダーの"Wait Classes by Total Wait Time"の直前の行までを、Top 10 Wait Eventとしてcsv化する。

この場合、”Wait Classes by Total Wait Time”の直前の行は、2バイトで<FF><LF>なので、<FF><LF>の行が"Top 10 Foreground Events by Total Wait Time"セクションの終わり。

なのだが、"Top 10 Foreground Events by Total Wait Time"セクションの直前の行は、1バイトで<LF>のみとなり、 <FF>を含まないケースもある.....
各セクションの最終行の判定は、2バイトで<FF><LF>または、1バイトで<LF> で判定する必要がある。と。

TextフォーマットのAWRレポートの例
viでTextフォーマットのAWRレポートを開いて、eol部分を!で表示。

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~!
            Buffer Nowait %:   99.99       Redo NoWait %:  100.00!
            Buffer  Hit   %:   97.86    In-memory Sort %:  100.00!
            Library Hit   %:   90.46        Soft Parse %:   93.77!
         Execute to Parse %:   62.59         Latch Hit %:   99.82!
Parse CPU to Parse Elapsd %:   75.51     % Non-Parse CPU:   89.49!
          Flash Cache Hit %:    0.00!
!
Top 10 Foreground Events by Total Wait Time!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~!
                                           Total Wait       Avg   % DB Wait!
Event                                Waits Time (sec)      Wait   time Class!
------------------------------ ----------- ---------- --------- ------ --------!
DB CPU                                            3.5            167.2!
library cache: mutex X                  81         .1    1.15ms    4.4 Concurre!
PX Deq: Slave Session Stats            229         .1  231.53us    2.5 Other!
log file sync                           10          0    2.11ms    1.0 Commit!
library cache: bucket mutex X            3          0    4.96ms     .7 Concurre!
db file sequential read                 24          0  583.13us     .7 User I/O!
PGA memory operation                   600          0   11.39us     .3 Other!
enq: BF - allocation contentio           6          0  390.50us     .1 Other!
latch: call allocation                   3          0  240.67us     .0 Other!
latch: shared pool                       3          0  226.33us     .0 Concurre!
^L!
Wait Classes by Total Wait Time!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~!
                                                          Avg             Avg!
                                        Total Wait       Wait   % DB   Active!
Wait Class                  Waits       Time (sec)       Time   time Sessions!
---------------- ---------------- ---------------- ---------- ------ --------!
DB CPU                                           4             167.2      0.0!
System I/O                  3,469                3   734.15us  120.9      0.0!
Other                       3,482                2   689.81us  114.0      0.0!
User I/O                    1,261                1   421.44us   25.2      0.0!
Concurrency                    95                0     1.20ms    5.4      0.0!
Commit                         14                0     2.40ms    1.6      0.0!
Configuration                   1                0   108.00us     .0      0.0!
!
Host CPU!
~~~~~~~~                  Load Average!
 CPUs Cores Sockets     Begin       End     %User   %System      %WIO     %Idle!
----- ----- ------- --------- --------- --------- --------- --------- ---------!
   12    12       1      0.14      0.12       0.1       0.0       0.0      99.8!
!
Instance CPU!
~~~~~~~~~~~~!
              % of total CPU for Instance:       0.1!
              % of busy  CPU for Instance:      82.3!
  %DB time waiting for CPU - Resource Mgr:       0.0!
:set listchars=eol:!

おまけ。上記、テキスト部分のバイナリダンプ
<LF>部分の確認

<FF><LF>部分の確認

Textモードで出力したAWRレポートをCSV化しようなんて、めんどくさい事しないほうがいいよね。
悪いことは言わないから、htmlで出力してCSV化した方が楽だからw 絶対！
ちなみに、わたしは、Top 10 wait eventセクションだけしかやりませんでしたw（時間ないし）

投稿日時 2018年4月 8日 (日) 23時09分その他, FAQ, AWR, Oracle Database 12c Release 2 | 固定リンク | 0 | コメント (0) | トラックバック (0)

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

Previously on Mac De Oracle

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

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

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

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

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

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

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

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

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

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

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

ORCL@SCOTT> @auto_sortwk2gb_optimal.sql

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

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

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

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

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

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

・・・中略・・・

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

2GBのハッシュ結合

ORCL@SCOTT> @auto_hashwk2gb_optimal.sql

・・・中略・・・

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

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

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

・・・中略・・・

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

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

ORCL@SCOTT> @auto_sortwk4gb_optimal.sql

・・・中略・・・

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

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

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

・・・中略・・・

SQL Plan Monitoring Details (Plan Hash Value=2686238998)
============================================================================================================================================================
| Id |       Operation       | Name |  Rows   | Cost  |   Time    | Start  | Execs |   Rows   | Read | Read  |  Mem  | Activity |     Activity Detail      |
|    |                       |      | (Estim) |       | Active(s) | Active |       | (Actual) | Reqs | Bytes | (Max) |   (%)    |       (# samples)        |
============================================================================================================================================================
|  0 | SELECT STATEMENT      |      |         |       |        40 |     +2 |     1 |       2M |      |       |     . |    27.78 | Cpu (5)                  |
|  1 |   SORT ORDER BY       |      |      2M |  182K |        41 |     +1 |     1 |       2M |      |       |   4GB |    38.89 | Cpu (6)                  |
|    |                       |      |         |       |           |        |       |          |      |       |       |          | PGA memory operation (1) |
|  2 |    UNION-ALL          |      |         |       |        12 |     +2 |     1 |       2M |      |       |     . |          |                          |
|  3 |     TABLE ACCESS FULL | M1   |    855K | 90828 |         6 |     +2 |     1 |     850K | 2633 |   3GB |     . |    22.22 | Cpu (2)                  |
|    |                       |      |         |       |           |        |       |          |      |       |       |          | direct path read (2)     |
|  4 |     TABLE ACCESS FULL | M1   |    855K | 90828 |         6 |     +8 |     1 |     850K | 2633 |   3GB |     . |    11.11 | Cpu (2)                  |
============================================================================================================================================================

4GBのハッシュ結合 最大3GBのPGAが消費されていますが、Temp落ちしないサイズ、つまり、optimalで処理する場合には、最大2GBが最大サイズとなっています。以下を3GBのハッシュ結合にすると、2GBまでPGAを消費し、一時表領域が3GB利用されます。

ORCL@SCOTT> @auto_hashwk4gb_optimal.sql
old   1: select dbms_sqltune.report_sql_monitor(sql_id=>'&1', type=>'text') from dual
new   1: select dbms_sqltune.report_sql_monitor(sql_id=>'', type=>'text') from dual

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

・・・中略・・・

SQL Plan Monitoring Details (Plan Hash Value=3532417599)
=========================================================================================================================================================================================
| Id |       Operation        | Name |  Rows   | Cost  |   Time    | Start  | Execs |   Rows   | Read  | Read  | Write | Write |  Mem  | Temp  | Activity |       Activity Detail       |
|    |                        |      | (Estim) |       | Active(s) | Active |       | (Actual) | Reqs  | Bytes | Reqs  | Bytes | (Max) | (Max) |   (%)    |         (# samples)         |
=========================================================================================================================================================================================
|  0 | SELECT STATEMENT       |      |         |       |       216 |     +2 |     1 |       3M |       |       |       |       |     . |     . |     4.49 | Cpu (7)                     |
|  1 |   HASH JOIN            |      |      2M |  670K |       217 |     +1 |     1 |       3M | 18091 |   4GB | 18091 |   4GB |   3GB |   4GB |    79.49 | Cpu (87)                    |
|    |                        |      |         |       |           |        |       |          |       |       |       |       |       |       |          | direct path read temp (19)  |
|    |                        |      |         |       |           |        |       |          |       |       |       |       |       |       |          | direct path write temp (18) |
|  2 |    VIEW                |      |      2M |  182K |         9 |     +2 |     1 |       2M |       |       |       |       |     . |     . |          |                             |
|  3 |     UNION-ALL          |      |         |       |         9 |     +2 |     1 |       2M |       |       |       |       |     . |     . |          |                             |
|  4 |      TABLE ACCESS FULL | M1   |    752K | 90828 |         5 |     +2 |     1 |     750K |  2633 |   3GB |       |       |     . |     . |     1.92 | Cpu (3)                     |
|  5 |      TABLE ACCESS FULL | M1   |    752K | 90828 |         4 |     +7 |     1 |     750K |  2633 |   3GB |       |       |     . |     . |     1.92 | Cpu (3)                     |
|  6 |    VIEW                |      |      2M |  181K |        78 |    +99 |     1 |       2M |       |       |       |       |     . |     . |     0.64 | Cpu (1)                     |
|  7 |     UNION-ALL          |      |         |       |        78 |    +99 |     1 |       2M |       |       |       |       |     . |     . |          |                             |
|  8 |      TABLE ACCESS FULL | M2   |    759K | 90581 |        50 |    +92 |     1 |     750K |  2618 |   3GB |       |       |     . |     . |     9.62 | Cpu (2)                     |
|    |                        |      |         |       |           |        |       |          |       |       |       |       |       |       |          | direct path read (13)       |
|  9 |      TABLE ACCESS FULL | M2   |    759K | 90581 |        36 |   +141 |     1 |     750K |  2618 |   3GB |       |       |     . |     . |     1.92 | Cpu (2)                     |
|    |                        |      |         |       |           |        |       |          |       |       |       |       |       |       |          | direct path read (1)        |
=========================================================================================================================================================================================

では、最後に
ソートやハッシュ結合のサイズが8GB程度ならどうでしょうか？
結果は、ソートは4GBを使い切ったのち、Temp落ち、ハッシュ結合は、やはり、3GBまで利用したのちTemp落ちでした。なんと！（ちょっとわざとらしいリアクションしてすみませんw）

8GBのソート

ORCL@SCOTT> @auto_sortwk8gb_optimal.sql

・・・中略・・・

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

  1  SELECT
  2      /*+
  3          MONITOR
  4      */
  5      *
  6  FROM
  7      m1
  8  WHERE
  9      id <= 'C090000'
 10  UNION ALL
 11  SELECT *
 12  FROM
 13      m1 m12
 14  WHERE
 15      id <= 'C090000'
 16  UNION ALL
 17  SELECT *
 18  FROM
 19      m1 m13
 20  WHERE
 21      id <= 'C090000'
 22  UNION ALL
 23  SELECT *
 24  FROM
 25      m1 m14
 26  WHERE
 27      id <= 'C090000'
 28  ORDER BY
 29*     1, 2
old   1: select dbms_sqltune.report_sql_monitor(sql_id=>'&1', type=>'text') from dual
new   1: select dbms_sqltune.report_sql_monitor(sql_id=>'', type=>'text') from dual

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

・・・中略・・・

SQL Plan Monitoring Details (Plan Hash Value=946172832)
=========================================================================================================================================================================================
| Id |       Operation       | Name |  Rows   | Cost  |   Time    | Start  | Execs |   Rows   | Read  | Read  | Write | Write |  Mem  | Temp  | Activity |       Activity Detail        |
|    |                       |      | (Estim) |       | Active(s) | Active |       | (Actual) | Reqs  | Bytes | Reqs  | Bytes | (Max) | (Max) |   (%)    |         (# samples)          |
=========================================================================================================================================================================================
|  0 | SELECT STATEMENT      |      |         |       |       279 |     +2 |     1 |       4M |       |       |       |       |     . |     . |     5.79 | Cpu (6)                      |
|    |                       |      |         |       |           |        |       |          |       |       |       |       |       |       |          | PGA memory operation (1)     |
|    |                       |      |         |       |           |        |       |          |       |       |       |       |       |       |          | local write wait (7)         |
|  1 |   SORT ORDER BY       |      |      4M |  363K |       279 |     +2 |     1 |       4M | 38603 |   8GB | 32072 |   8GB |   4GB |   8GB |    84.30 | Cpu (49)                     |
|    |                       |      |         |       |           |        |       |          |       |       |       |       |       |       |          | PGA memory operation (1)     |
|    |                       |      |         |       |           |        |       |          |       |       |       |       |       |       |          | direct path read temp (28)   |
|    |                       |      |         |       |           |        |       |          |       |       |       |       |       |       |          | direct path write temp (126) |
|  2 |    UNION-ALL          |      |         |       |       176 |     +2 |     1 |       4M |       |       |       |       |     . |     . |          |                              |
|  3 |     TABLE ACCESS FULL | M1   |    907K | 90828 |        16 |     +1 |     1 |     900K |  2633 |   3GB |       |       |     . |     . |     4.55 | Cpu (2)                      |
|    |                       |      |         |       |           |        |       |          |       |       |       |       |       |       |          | direct path read (9)         |
|  4 |     TABLE ACCESS FULL | M1   |    907K | 90828 |         8 |    +17 |     1 |     900K |  2633 |   3GB |       |       |     . |     . |     2.48 | Cpu (5)                      |
|    |                       |      |         |       |           |        |       |          |       |       |       |       |       |       |          | direct path read (1)         |
|  5 |     TABLE ACCESS FULL | M1   |    907K | 90828 |        79 |    +26 |     1 |     900K |  2633 |   3GB |       |       |     . |     . |     2.48 | Cpu (2)                      |
|    |                       |      |         |       |           |        |       |          |       |       |       |       |       |       |          | direct path read (4)         |
|  6 |     TABLE ACCESS FULL | M1   |    907K | 90828 |        72 |   +106 |     1 |     900K |  2633 |   3GB |       |       |     . |     . |     0.41 | Cpu (1)                      |
=========================================================================================================================================================================================

8GBのハッシュ結合

ORCL@SCOTT> @auto_hashwk8gb_optimal.sql

・・・中略・・・

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

  1  SELECT
  2      /*+
  3          MONITOR
  4          LEADING(m1 m2)
  5          USE_HASH(m2)
  6      */
  7      *
  8  FROM
  9      (
 10          SELECT * FROM m1 m11
 11          UNION ALL
 12          SELECT * FROM m1 m12
 13          UNION ALL
 14          SELECT * FROM m1 m13
 15      ) m1
 16      INNER JOIN
 17      (
 18          SELECT * FROM m2 m21
 19          UNION ALL
 20          SELECT * FROM m2 m22
 21          UNION ALL
 22          SELECT * FROM m2 m23
 23      ) m2
 24      ON
 25          m1.id = m2.id
 26          AND m1.rev# = m2.rev#
 27  WHERE
 28*     m1.id <= 'C075000'
old   1: select dbms_sqltune.report_sql_monitor(sql_id=>'&1', type=>'text') from dual
new   1: select dbms_sqltune.report_sql_monitor(sql_id=>'', type=>'text') from dual

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

・・・中略・・・

SQL Plan Monitoring Details (Plan Hash Value=2506347387)
=========================================================================================================================================================================================
| Id |       Operation        | Name |  Rows   | Cost  |   Time    | Start  | Execs |   Rows   | Read  | Read  | Write | Write |  Mem  | Temp  | Activity |       Activity Detail       |
|    |                        |      | (Estim) |       | Active(s) | Active |       | (Actual) | Reqs  | Bytes | Reqs  | Bytes | (Max) | (Max) |   (%)    |         (# samples)         |
=========================================================================================================================================================================================
|  0 | SELECT STATEMENT       |      |         |       |       350 |     +2 |     1 |       7M |       |       |       |       |     . |     . |     9.18 | Cpu (18)                    |
|    |                        |      |         |       |           |        |       |          |       |       |       |       |       |       |          | PGA memory operation (1)    |
|  1 |   HASH JOIN            |      |      5M |    1M |       350 |     +2 |     1 |       7M | 31032 |   7GB | 31032 |   7GB |   3GB |   8GB |    67.15 | Cpu (81)                    |
|    |                        |      |         |       |           |        |       |          |       |       |       |       |       |       |          | direct path read temp (36)  |
|    |                        |      |         |       |           |        |       |          |       |       |       |       |       |       |          | direct path write temp (22) |
|  2 |    VIEW                |      |      2M |  272K |        27 |     +2 |     1 |       2M |       |       |       |       |     . |     . |          |                             |
|  3 |     UNION-ALL          |      |         |       |        27 |     +2 |     1 |       2M |       |       |       |       |     . |     . |     0.97 | Cpu (2)                     |
|  4 |      TABLE ACCESS FULL | M1   |    752K | 90828 |        16 |     +1 |     1 |     750K |  2633 |   3GB |       |       |     . |     . |     7.25 | Cpu (3)                     |
|    |                        |      |         |       |           |        |       |          |       |       |       |       |       |       |          | direct path read (12)       |
|  5 |      TABLE ACCESS FULL | M1   |    752K | 90828 |         5 |    +18 |     1 |     750K |  2633 |   3GB |       |       |     . |     . |     1.45 | Cpu (2)                     |
|    |                        |      |         |       |           |        |       |          |       |       |       |       |       |       |          | direct path read (1)        |
|  6 |      TABLE ACCESS FULL | M1   |    752K | 90828 |         7 |    +23 |     1 |     750K |  2633 |   3GB |       |       |     . |     . |     1.93 | Cpu (2)                     |
|    |                        |      |         |       |           |        |       |          |       |       |       |       |       |       |          | direct path read (2)        |
|  7 |    VIEW                |      |      2M |  272K |       130 |    +97 |     1 |       2M |       |       |       |       |     . |     . |          |                             |
|  8 |     UNION-ALL          |      |         |       |       130 |    +97 |     1 |       2M |       |       |       |       |     . |     . |     0.48 | Cpu (1)                     |
|  9 |      TABLE ACCESS FULL | M2   |    759K | 90581 |        47 |    +88 |     1 |     750K |  2618 |   3GB |       |       |     . |     . |     4.83 | Cpu (3)                     |
|    |                        |      |         |       |           |        |       |          |       |       |       |       |       |       |          | direct path read (7)        |
| 10 |      TABLE ACCESS FULL | M2   |    759K | 90581 |        41 |   +134 |     1 |     750K |  2618 |   3GB |       |       |     . |     . |     4.35 | Cpu (5)                     |
|    |                        |      |         |       |           |        |       |          |       |       |       |       |       |       |          | direct path read (4)        |
| 11 |      TABLE ACCESS FULL | M2   |    759K | 90581 |        53 |   +174 |     1 |     750K |  2618 |   3GB |       |       |     . |     . |     2.42 | Cpu (1)                     |
|    |                        |      |         |       |           |        |       |          |       |       |       |       |       |       |          | direct path read (4)        |
=========================================================================================================================================================================================

これ、Linuxのカーネルパラメータのvm.max_map_count

/proc/sys/vm/max_map_count

65530

が絡んでるよねという話と、隠しパラメータの realfree_heap関連のパラメータでも調整できそうだよね。という話はあるんですが...それはPL/SQLのはなし...で


_realfree_heap_pagesize                        65536                          TRUE
_use_realfree_heap                             TRUE                           TRUE

とりあえず、
vm/max_map_countを196608

にして
_realfree_heap_pagesize=65536 や
_realfree_heap_pagesize=256K

などとして戯れてみましたが

ソートやハッシュ結合で利用可能なサイズは、それらで制御できるものでもありません。いまのところ。

ORCL@SCOTT> @auto_sortwk8gb_optimal.sql

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

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

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

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

/proc/sys/vm/max_map_count
196608

  1  SELECT
  2      /*+
  3          MONITOR
  4      */
  5      *
  6  FROM
  7      m1
  8  WHERE
  9      id <= 'C090000'
 10  UNION ALL
 11  SELECT *
 12  FROM
 13      m1 m12
 14  WHERE
 15      id <= 'C090000'
 16  UNION ALL
 17  SELECT *
 18  FROM
 19      m1 m13
 20  WHERE
 21      id <= 'C090000'
 22  UNION ALL
 23  SELECT *
 24  FROM
 25      m1 m14
 26  WHERE
 27      id <= 'C090000'
 28  ORDER BY
 29*     1, 2
old   1: select dbms_sqltune.report_sql_monitor(sql_id=>'&1', type=>'text') from dual
new   1: select dbms_sqltune.report_sql_monitor(sql_id=>'', type=>'text') from dual

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

・・・中略・・・

SQL Plan Monitoring Details (Plan Hash Value=946172832)
=========================================================================================================================================================================================
| Id |       Operation       | Name |  Rows   | Cost  |   Time    | Start  | Execs |   Rows   | Read  | Read  | Write | Write |  Mem  | Temp  | Activity |       Activity Detail        |
|    |                       |      | (Estim) |       | Active(s) | Active |       | (Actual) | Reqs  | Bytes | Reqs  | Bytes | (Max) | (Max) |   (%)    |         (# samples)          |
=========================================================================================================================================================================================
|  0 | SELECT STATEMENT      |      |         |       |       295 |     +2 |     1 |       4M |       |       |       |       |     . |     . |     3.38 | Cpu (8)                      |
|  1 |   SORT ORDER BY       |      |      4M |  363K |       297 |     +1 |     1 |       4M | 38603 |   8GB | 38600 |   8GB |   4GB |   8GB |    91.56 | Cpu (43)                     |
|    |                       |      |         |       |           |        |       |          |       |       |       |       |       |       |          | direct path read temp (12)   |
|    |                       |      |         |       |           |        |       |          |       |       |       |       |       |       |          | direct path write temp (162) |
|  2 |    UNION-ALL          |      |         |       |       205 |     +2 |     1 |       4M |       |       |       |       |     . |     . |     0.84 | Cpu (2)                      |
|  3 |     TABLE ACCESS FULL | M1   |    907K | 90828 |         6 |     +2 |     1 |     900K |  2633 |   3GB |       |       |     . |     . |     2.11 | Cpu (1)                      |
|    |                       |      |         |       |           |        |       |          |       |       |       |       |       |       |          | direct path read (4)         |
|  4 |     TABLE ACCESS FULL | M1   |    907K | 90828 |         7 |     +8 |     1 |     900K |  2633 |   3GB |       |       |     . |     . |     0.42 | Cpu (1)                      |
|  5 |     TABLE ACCESS FULL | M1   |    907K | 90828 |       100 |    +14 |     1 |     900K |  2633 |   3GB |       |       |     . |     . |     0.84 | Cpu (2)                      |
|  6 |     TABLE ACCESS FULL | M1   |    907K | 90828 |        94 |   +113 |     1 |     900K |  2633 |   3GB |       |       |     . |     . |     0.84 | Cpu (2)                      |
=========================================================================================================================================================================================

ちなみに、PL/SQLで巨大なPGAメモリーを利用する場合は、しっかり9GBとか...やばい状態になったら、pga_aggregate_limitで抑えてくれると思いますが.....

[oracle@localhost ˜]$ ulimit -v -m
virtual memory          (kbytes, -v) unlimited
max memory size         (kbytes, -m) unlimited

orcl12c@SYS> @show_param

KSPPINM                                        KSPPSTVL                       KSPPSTDF
---------------------------------------------- ------------------------------ ------------------------------
_pga_max_size                                  4398046511103                  FALSE
_realfree_heap_pagesize                        65536                          TRUE
_use_realfree_heap                             TRUE                           TRUE
pga_aggregate_limit                            0                              FALSE
pga_aggregate_target                           4398046511103                  FALSE


/proc/sys/vm/max_map_count
65530

PGAを大量に消費するスクリプトは以下のブログを参考に
Max PGA Research: Check that a process can allocate a large volume of memory / Yury's Blog


ORCL@SCOTT> @plsql_pga8gb 8192
old   2: c_count number := 1024*&1;
new   2: c_count number := 1024*8192;

PL/SQL procedure successfully completed.

実際に確保されたPGAサイズなど。。。

ORCL@SCOTT> r
  1  select
  2  	vss.value/1024/1024/1024 "GB"
  3  	,vsn.name
  4  	,vss.sid
  5  from
  6  	v$sesstat vss
  7  	inner join v$statname vsn
  8  	on
  9  		vss.statistic# = vsn.statistic#
 10  		and vss.con_id = vsn.con_id
 11  		and (vsn.name like '%pga%' or vsn.name like '%uga%')
 12  where
 13  	sid IN (select sid from v$session where username='SCOTT')
 14  order by
 15* 	sid,name

        GB NAME                                                                    SID
---------- ---------------------------------------------------------------- ----------
9.49698084 session pga memory                                                      321
9.49698084 session pga memory max                                                  321
1.48221001 session uga memory                                                      321
3.99991362 session uga memory max                                                  321

[oracle@localhost ˜]$ free -h
              total        used        free      shared  buff/cache   available
Mem:            22G        1.0G        9.6G         11G         11G         10G
Swap:          4.0G        8.7M        4.0G

・・・中略・・・

[oracle@localhost ˜]$ free -h
              total        used        free      shared  buff/cache   available
Mem:            22G         10G        128M         11G         11G        705M
Swap:          4.0G        8.8M        4.0G

ここまでくればおわかりだと思いますが、global memory bound (約839GB)からは巨大なPGAサイズになりそうに思えますが、Temp落ちせずにソート可能なサイズは、隠しパラメータを調整した場合でも最大4GB、ハッシュ結合は、2GBが上限、となっています。いまのところ。。。。

ということは、2014年の以下のプレゼンでも話題になっていましたよね。:)
Overcome Oracle PGA Memory Limits Mar.5.2014 Alex Fatkulin / Enkatic

だったら、どのようにして、Temp落ち　に立ち向かえばいいんだろう.....次回へ続く　:)

10gR2(64bit)のころのままなので、以下のシリーズも合わせて読んでおくといいですよ：）

・Temp落ち #1 - "Temp落ち" って？
・Temp落ち #2 - PGA (Program Global Area)
・Temp落ち #3 - 手動PGA管理で作業領域として指定可能な最大サイズ
・Temp落ち #4 - 手動PGA管理で作業領域として指定可能な最大サイズ de Temp落ちの確認
・Temp落ち #5 - pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? 12.2.0.1版（その前に少し脱線）
・Temp落ち #6 - pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? 12.2.0.1版
・Temp落ち #7 - 自動PGA管理で到達可能な最大サイズ de Temp落ちの確認 12.2.0.1版
・Temp落ち #8 - 自動PGA管理でパラメータ上設定可能な最大サイズは？（実際に利用可能なサイズとは限りませんが。意味深） 12.2.0.1版

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

Temp落ち #8 - 自動PGA管理でパラメータ上設定可能な最大サイズは？（実際に利用可能なサイズとは限りませんが。意味深） 12.2.0.1版

Previously on Mac De Oracle

自動PGA管理下では、SQL Work Areaサイズは、pga_aggregate_targetのサイズに応じて変化し、最大1GBまで調整され、それのサイズ以上のソートやハッシュ結合は、もれなく、"Temp落ち" する。
手動PGA管理下では、最大2GBまで指定できました。。自動だと1GBまでなのか。。。と残念がる声が、昔は海だった方面から聞こえた気がしましたが、たぶん、気のせいw

というところまででした。

今日は、自動PGA管理下ではそれが最大なのか？　のか？　自己責任で試してみることにしますw

まずはこれまでの復習。

自動PGA管理で、SQL Work Areaサイズの算出に関わるパラメータは以下の通り

pga_aggregate_target = 10MB 〜 4TB - 1
_pga_max_size = 200MB 〜　2GB
（Oracleが動的に値を調整している_pga_max_sizeパラメータへユーザーが値を設定してしまうとOracleの自動調整が無効化され、設定した値で固定されてしまうので注意が必要です。）

私の観測範囲だとおおよそ以下のように変化します。最近は大量のメモリーを搭載したサーバーが多いので、pga_aggregate_targetが10GB以上という状況も普通になってきたので、自動PGA管理下のSQL Work Areaサイズは最大1GBとざっくり丸暗記しても困ることは思いますw（ちょっと乱暴かw）

pga_aggregate_target = 10MB〜10GB - 1 :
_pga_max_size = 200MB 〜　2047MB
GREATEST(pga_aggregate_target*0.2 ,200MB)

pga_aggregate_target = 10GB以上〜4TB-1 :
_pga_max_size = 2GB
LEAST(pga_aggregate_target*0.2 ,2GB)

_pga_max_sizeはpga_aggregate_targetの値に応じて動的に変化し、それらを元に _smm_max_size が算出される

LEAST(pga_aggregate_target * 0.2, _pga_max_size * 0.5)

pga_aggregate_target = 10MB〜10GB-1
_pga_max_size = 200MB〜2047MB
_smm_max_size = 2MB〜1023MB

pga_aggregate_target = 10GB〜4TB-1
_pga_max_size = 2048MB
_smm_max_size = 1024MB

_smm_max_sizeは、v$pgastatのglobal memory boundだろうということは確からしいということまでは確認しました。

いままでの結果をまとめると
PGAのSQL Work Areaサイズの最大サイズを示す global memory boundは、pga_aggregate_targetが10MB〜10GB-1までは2MB〜1023MBで調整され、pga_aggregate_targetが10GB〜4TB-1では、1024MB (1GB) で固定されている、というのが、Oracle 10GR2〜12cR2まで動きであることは間違いなさそう:)

自動PGA管理下でSQL Work Areaを1GBを超えるサイズにするにはどのパラメータをどのような値に設定すればよいか。。。
その鍵を握るパラメータは

_pga_max_size

(いまいちピンとこないという方は、過去のエントリーを参照していただけるとスッキリすると思います。）

ただ、冒頭にも書きましたが（昔それでハマったw）、（Oracleが動的に値を調整している_pga_max_sizeパラメータへユーザーが値を設定してしまうとOracleの自動調整が無効化され、設定した値で固定されてしまうので注意が必要です。）
という点はお忘れなく。また、今後も同仕様のままである保証はなく、世界中のOracle使いの方達が調べ上げた結果、現状はこんな感じ。
という状況だと認識しておいたほうが無難だと思っています。

とはいえ、実際どこまで設定可能なのか？　　1GBを以上使えるのか？　知りたいですよね...

長い前置きはこれぐらいにして、
実際にSQL Work Areaサイズに対応したメモリーが実際にどの程度割り当てられるのかということの確認は後回しですが、パラメータの上では、どこまで設定できるのかというところを確認しました。

なお、
以下のエラーメッセージから、_pga_max_sizeに設定可能な値は、pga_aggregate_targetと同様（Big Integer）、10MB〜4TB-1までであると思われます。

orcl12c@SYS> show parameter _pga_max_size

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
_pga_max_size                        big integer 2G

orcl12c@SYS> alter system set "_pga_max_size" = 4T scope=memory;
alter system set "_pga_max_size" = 4T scope=memory
*
行1でエラーが発生しました。:
ORA-02097: 指定した値が無効なので、パラメータを変更できません。 ORA-00093:
_pga_max_sizeは、10Mから4096G-1の間に設定する必要があります。

ということで、
_pga_max_sizeを1GB/10GB/100GB/1TB/4T-1のそれぞれに設定したうえで、Temp落ち #6 - pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? 12.2.0.1版で利用したスクリプトを利用し、global memory boundやその他パラメータの変化を確認しました。

ログの例

orcl12c@SYS> alter system set "_pga_max_size" = 10m scope=both;

システムが変更されました。

orcl12c@SYS> show parameter _pga_max_size

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
_pga_max_size                        big integer 10m


orcl12c@SYS> @dotest_auto_workarea
<< 10m >>
接続されました。
  1* alter system set pga_aggregate_target=&1 scope=spfile
旧   1: alter system set pga_aggregate_target=&1 scope=spfile
新   1: alter system set pga_aggregate_target=10m scope=spfile

システムが変更されました。

データベースがクローズされました。
データベースがディスマウントされました。
ORACLEインスタンスがシャットダウンされました。
ORACLEインスタンスが起動しました。

Total System Global Area 2147483648 bytes
Fixed Size                  8794848 bytes
Variable Size             603983136 bytes
Database Buffers         1526726656 bytes
Redo Buffers                7979008 bytes
データベースがマウントされました。
データベースがオープンされました。
+++ initial parameters +++

KSPPINM                                        KSPPSTVL                       KSPPSTDF
---------------------------------------------- ------------------------------ ------------------------------
__pga_aggregate_target                         16777216                       FALSE

・・・中略・・・

pga_aggregate_limit                            0                              FALSE
pga_aggregate_target                           10485760                       FALSE

50行が選択されました。

/proc/sys/vm/max_map_count

65530

+++ v$pgastat +++

NAME                                                                  VALUE UNIT             CON_ID
---------------------------------------------------------------- ---------- ------------ ----------
aggregate PGA target parameter                                           10 MB                    0
aggregate PGA auto target                                                 4 MB                    0
global memory bound                                                       2 MB                    0

・・・中略・・・

結果は以下のグラフと表にまとめたとおり。
_pga_max_size=4TB-1、pga_aggregate_target=4TB-1の時のglobal memory bound (v$pgastat) = _smm_max_size が最大となり、約839GBとなることがわかりました。
パラメータ上は839GB程度まで増加しますが、ほんとうにPGAがそんなサイズまで利用可能なのでしょうか？....（怪しいです。答え、知ってるんですけどねw。。

ということで、

次回は実際に、そんなに使えんのかよ！　という実験をしてみたいと思います :)

つづく。

・Temp落ち #1 - "Temp落ち" って？
・Temp落ち #2 - PGA (Program Global Area)
・Temp落ち #3 - 手動PGA管理で作業領域として指定可能な最大サイズ
・Temp落ち #4 - 手動PGA管理で作業領域として指定可能な最大サイズ de Temp落ちの確認
・Temp落ち #5 - pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? 12.2.0.1版（その前に少し脱線）
・Temp落ち #6 - pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? 12.2.0.1版
・Temp落ち #7 - 自動PGA管理で到達可能な最大サイズ de Temp落ちの確認 12.2.0.1版

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

Temp落ち #7 - 自動PGA管理で到達可能な最大サイズ de Temp落ちの確認 12.2.0.1版

Previously on Mac De Oracle

自動PGA管理で利用可能なSQL Work Areaサイズはいくつなのか？の確認でした。
これまで同様、隠しパラメータ等の変更をしないデフォルトの設定では最大1GBまで到達することを確認しました。
また、手動PGA管理で利用可能な最大サイズより小さいことも再確認しました。

今日は自動PGA管理下ではオンメモリーで処理可能なサイズは1GBまでなのか、それを超えた場合はもれなく　"Temp落ち" なのか確認することにします。

確認用データおよび方法は前々回のエントリーを参照ください。

自動PGA管理でGlobal Memory Bound = 1GB（自動PGA管理での最大 Sort作業領域サイズ）

メモリーソートで1GBぐらいまで利用していることが確認できます。（ソートされるデータ量は1GB以下程度に制限しています。）

ORCL@SCOTT> @auto_sortwk1gb_optimal

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

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

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

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

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

・・・中略・・・

Global Stats
===========================================================================
| Elapsed |   Cpu   |    IO    |  Other   | Fetch | Buffer | Read | Read  |
| Time(s) | Time(s) | Waits(s) | Waits(s) | Calls |  Gets  | Reqs | Bytes |
===========================================================================
|    4.78 |    3.85 |     0.34 |     0.59 | 30001 |   334K | 2633 |   3GB |
===========================================================================

SQL Plan Monitoring Details (Plan Hash Value=3534657201)
==================================================================================================================================================
| Id |      Operation       | Name |  Rows   | Cost  |   Time    | Start  | Execs |   Rows   | Read | Read  |  Mem  | Activity | Activity Detail |
|    |                      |      | (Estim) |       | Active(s) | Active |       | (Actual) | Reqs | Bytes | (Max) |   (%)    |   (# samples)   |
==================================================================================================================================================
|  0 | SELECT STATEMENT     |      |         |       |        10 |     +2 |     1 |     450K |      |       |     . |    33.33 | Cpu (2)         |
|  1 |   SORT ORDER BY      |      |    456K |  302K |        11 |     +1 |     1 |     450K |      |       |   1GB |    33.33 | Cpu (2)         |
|  2 |    TABLE ACCESS FULL | M1   |    456K | 90827 |         3 |     +2 |     1 |     450K | 2633 |   3GB |     . |    33.33 | Cpu (2)         |
==================================================================================================================================================

Temp落ちする程度のデータ量でソートさせた場合も、PGAの作業領域は最大1GBまで利用されていたことが確認できます。

ORCL@SCOTT> @auto_sortwk1gb_mpass    

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

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

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

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

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

・・・中略・・・

Global Stats
===========================================================================================
| Elapsed |   Cpu   |    IO    |  Other   | Fetch | Buffer | Read | Read  | Write | Write |
| Time(s) | Time(s) | Waits(s) | Waits(s) | Calls |  Gets  | Reqs | Bytes | Reqs  | Bytes |
===========================================================================================
|      16 |    6.91 |     7.91 |     0.71 | 33335 |   334K | 7996 |   4GB |  4431 |   1GB |
===========================================================================================

SQL Plan Monitoring Details (Plan Hash Value=3534657201)
=====================================================================================================================================================================================
| Id |      Operation       | Name |  Rows   | Cost  |   Time    | Start  | Execs |   Rows   | Read | Read  | Write | Write |  Mem  | Temp  | Activity |      Activity Detail       |
|    |                      |      | (Estim) |       | Active(s) | Active |       | (Actual) | Reqs | Bytes | Reqs  | Bytes | (Max) | (Max) |   (%)    |        (# samples)         |
=====================================================================================================================================================================================
|  0 | SELECT STATEMENT     |      |         |       |        22 |     +2 |     1 |     500K |      |       |       |       |     . |     . |     6.25 | Cpu (1)                    |
|  1 |   SORT ORDER BY      |      |    507K |  326K |        22 |     +2 |     1 |     500K | 5363 |   1GB |  4431 |   1GB |   1GB |   1GB |    68.75 | Cpu (4)                    |
|    |                      |      |         |       |           |        |       |          |      |       |       |       |       |       |          | direct path read temp (1)  |
|    |                      |      |         |       |           |        |       |          |      |       |       |       |       |       |          | direct path write temp (6) |
|  2 |    TABLE ACCESS FULL | M1   |    507K | 90828 |        13 |     +1 |     1 |     500K | 2633 |   3GB |       |       |     . |     . |    25.00 | Cpu (3)                    |
|    |                      |      |         |       |           |        |       |          |      |       |       |       |       |       |          | direct path read (1)       |
=====================================================================================================================================================================================

自動PGA管理でGlobal Memory Bound = 1GB（自動PGA管理での最大 Hash作業領域サイズ）

Hash Joinの場合も、自動PGA管理の最大サイズ程度まで利用されていることが確認できます。（Temp落ちしない程度のデータ量にしています。）

ORCL@SCOTT> @auto_hashwk1gb_optimal

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

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

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

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

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

・・・中略・・・

Global Stats
===========================================================================
| Elapsed |   Cpu   |    IO    |  Other   | Fetch | Buffer | Read | Read  |
| Time(s) | Time(s) | Waits(s) | Waits(s) | Calls |  Gets  | Reqs | Bytes |
===========================================================================
|    7.29 |    5.05 |     0.68 |     1.55 | 28001 |   695K | 5251 |   5GB |
===========================================================================

SQL Plan Monitoring Details (Plan Hash Value=1822065247)
==================================================================================================================================================
| Id |      Operation       | Name |  Rows   | Cost  |   Time    | Start  | Execs |   Rows   | Read | Read  |  Mem  | Activity | Activity Detail |
|    |                      |      | (Estim) |       | Active(s) | Active |       | (Actual) | Reqs | Bytes | (Max) |   (%)    |   (# samples)   |
==================================================================================================================================================
|  0 | SELECT STATEMENT     |      |         |       |        14 |     +2 |     1 |     420K |      |       |     . |    22.22 | Cpu (2)         |
|  1 |   HASH JOIN          |      |    423K |  268K |        15 |     +1 |     1 |     420K |      |       |   1GB |    22.22 | Cpu (2)         |
|  2 |    TABLE ACCESS FULL | M1   |    432K | 90827 |         2 |     +2 |     1 |     420K | 2633 |   3GB |     . |    11.11 | Cpu (1)         |
|  3 |    TABLE ACCESS FULL | M2   |    423K | 90580 |        13 |     +3 |     1 |     420K | 2618 |   3GB |     . |    44.44 | Cpu (4)         |
==================================================================================================================================================

Hash Joinの場合もSort時と同じように、一時表領域も利用が必要となるデータ量になると、一旦、自動PGA管理の最大サイズ程度まで利用したうえでTemp落ちしていることが確認できます。

ORCL@SCOTT> @auto_hashwk1gb_mpass

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

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

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

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

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

・・・中略・・・

Global Stats
============================================================================================
| Elapsed |   Cpu   |    IO    |  Other   | Fetch | Buffer | Read  | Read  | Write | Write |
| Time(s) | Time(s) | Waits(s) | Waits(s) | Calls |  Gets  | Reqs  | Bytes | Reqs  | Bytes |
============================================================================================
|      24 |    7.18 |       15 |     1.99 | 36668 |   687K | 10829 |   6GB |  5578 |   1GB |
============================================================================================

SQL Plan Monitoring Details (Plan Hash Value=1822065247)
======================================================================================================================================================================================
| Id |      Operation       | Name |  Rows   | Cost  |   Time    | Start  | Execs |   Rows   | Read | Read  | Write | Write |  Mem  | Temp  | Activity |       Activity Detail       |
|    |                      |      | (Estim) |       | Active(s) | Active |       | (Actual) | Reqs | Bytes | Reqs  | Bytes | (Max) | (Max) |   (%)    |         (# samples)         |
======================================================================================================================================================================================
|  0 | SELECT STATEMENT     |      |         |       |        33 |     +2 |     1 |     550K |      |       |       |       |     . |     . |    14.29 | Cpu (4)                     |
|  1 |   HASH JOIN          |      |    551K |  293K |        33 |     +2 |     1 |     550K | 5578 |   1GB |  5578 |   1GB |   1GB |   1GB |    67.86 | Cpu (8)                     |
|    |                      |      |         |       |           |        |       |          |      |       |       |       |       |       |          | direct path read temp (1)   |
|    |                      |      |         |       |           |        |       |          |      |       |       |       |       |       |          | direct path write temp (10) |
|  2 |    TABLE ACCESS FULL | M1   |    551K | 90828 |        16 |     +1 |     1 |     550K | 2633 |   3GB |       |       |     . |     . |     7.14 | Cpu (1)                     |
|    |                      |      |         |       |           |        |       |          |      |       |       |       |       |       |          | direct path read (1)        |
|  3 |    TABLE ACCESS FULL | M2   |    557K | 90580 |        16 |    +16 |     1 |     550K | 2618 |   3GB |       |       |     . |     . |    10.71 | Cpu (3)                     |
======================================================================================================================================================================================

PGAの最大サイズは異なりますが、自動PGA管理、手動PGA管理いずれでの場合でも制限値を超えた場合は、もれなく　"Temp落ち" するということはご理解いただけたのではないかと思います。

では、次回は恒例？w の隠しパラメータと戯れた場合、自動PGA管理下ではどこまで増加させることができるのか？。。。。確認してみたいと思います。

・Temp落ち #1 - "Temp落ち" って？
・Temp落ち #2 - PGA (Program Global Area)
・Temp落ち #3 - 手動PGA管理で作業領域として指定可能な最大サイズ
・Temp落ち #4 - 手動PGA管理で作業領域として指定可能な最大サイズ de Temp落ちの確認
・Temp落ち #5 - pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? 12.2.0.1版（その前に少し脱線）
・Temp落ち #6 - pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? 12.2.0.1版

投稿日時 2018年3月 8日 (木) 22時08分チューニング, FAQ, SQL, Oracle Database 11g, Oracle Database 11g Release 2, Oracle Database 12c release 1, パフォーマンス, Oracle Database 12c Release 2 | 固定リンク | 0 | コメント (0) | トラックバック (0)

Temp落ち #6 - pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? 12.2.0.1版

Previously on Mac De Oracle
pga_aggregate_target scope=memory or bothでそれまでとはことなる動きとエラーは発生するところの話でした。

きょうは、自動PGA管理下ではどうなるか確認しておきます。
以前、簡単に確認した範囲結果から、これまでの仕様と大きな違いはないとみています。（変わっていないと思っていたのでブログでも書いていなかったのですが、"Temp落ち"ネタの準備運動も兼ね現状を確認しながら進めてみたいと思います）

まず環境情報から、
確認に利用するインスタンスのPGA以外のパラメータは以下の通りです。
（隠しパラメータは必要がある場合には適宜変更します。また、いくつかのパラメータは確認の都合上物理メモリーサイズ以上に設定することがあります。それらの変更が必要な場合には事前に解説する予定です。）

OS等の情報は以前のエントリーを参照のこと。

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
sga_max_size                         big integer 12G
sga_min_size                         big integer 0
sga_target                           big integer 12G

今回の主役である自動PGA管理のパラメータの初期設定は以下の通り（隠しパラメータを除く）
pga_aggregate_limit = 0 に設定し、pga_aggregate_targetの上限値制限を仕様上のサイズ4096GB - 1まで利用できるようにしておきます。（以前と同様の手順で確認するために、pga_aggregate_limitによる制限を無効化しています。なお、pga_aggregate_limitを0以外に設定して行う場合には、pga_aggregate_targetを4TB - 1まで設定することを考慮すると、pga_aggregate_limitは、8TB以上に設定する必要があります。）

orcl12c@SYS> show parameter pga_aggregate

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
pga_aggregate_limit                  big integer 0
pga_aggregate_target                 big integer 10M

上記設定からスタートして、pga_aggregate_targetを10MB/50MB/100MB/500MB/1GB/5GB/10GB/50GB/100GB/500GB/1T/4TB - 1と増加させながら、pgaサイズおよび、関連する隠しパラメータ(_pga_max_sizeや_smm_*など）がどのように変化するか、pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? Season2 #8の手順で確認します。

昔のように実行ログをペタペタ貼っていると長くなるので、確認結果を表とグラフにしました。
想定通り以前と変わっていませんでした:)

デフォルト設定のままであれば、pga_aggregate_targetを限界値まで大きく増やしたとしても、10GB以降、個々のソート操作やハッシュ結合操作で利用できるPGAのSQL work areaサイズはv$pgastatのglobal memory boundの示す通り、1GB（シリアル実行時）が最大であることが確認できます。　えーーー。手動PGA管理より最大サイズ小さいじゃんと、今更驚かないようにしましょうねw （以前からそうなのですからw）
つまり、自動PGA管理の場合、特定の隠しパラメータを変更しない限り、1GBを超えるソート処理はやハッシュ結合操作は全て、"Temp落ち" する宿命にあるわけです。12cR2であっても。
え"〜〜〜〜〜っ！　と一応、驚いておきましょうw。　メモリーを沢山積んでるマシンは最近多いわけですが、このあたりはなぜか変わってません。

ちなみに、v$pgastatの示すglobal memory boundは、どこから？　という確認がしたくて、　_smm_max_sizeの変化と比較しているグラグも作成しておきました。
_smm_max_sizeパラメータはpga_aggregate_targetのサイズ変化に伴い変化する隠しパラメータですが、このパラメータがglobal memory boundの元になっているのは確からしいですね。

最後のグラフは、pga_aggregate_targetの値とv$pgastatのglobal memory boundの変化をまとめたグラフです。
global memory boundで示されるPGAのSQL Work Areaサイズの最大サイズには上限があることがわかります：）

次回は、自動PGA管理では、1GBを超えるソートやハッシュ結合はもれなく"Temp落ち"するのか確認してみることにします。

参考：このエントリーで利用したスクリプト
（今後の確認も兼ねてw このエントリーでネタにしている以外で関連しそうなパラメータも取得して変化を確認できるようにしてあります。）

orcl12c@SYS> !cat show_param.sql
set linesize 200
col ksppinm for a46
col ksppstvl for a30
col ksppstdf for a30
select
   a.ksppinm
  ,b.ksppstvl
  ,b.ksppstdf
from
  x$ksppi a join x$ksppcv b
  on a.indx = b.indx
where
  a.ksppinm in (
	'pga_aggregate_target'
	,'pga_aggregate_limit'
	,'_use_realfree_heap'
	,'_realfree_heap_pagesize'
  )
or a.ksppinm like '%\_smm%' escape '\'
or a.ksppinm like '%\_pga%' escape '\'
order by
  a.ksppinm
/

!echo /proc/sys/vm/max_map_count
!more /proc/sys/vm/max_map_count

orcl12c@SYS> !cat show_pgstat.sql
select
  name
 ,case
    when unit='bytes' then
      value/1024/1024
    else value
  end "VALUE"
 ,case
    when unit='bytes' then
      'MB'
    else unit
  end "UNIT"
 ,con_id
from
  v$pgastat
where
  name in (
    'aggregate PGA target parameter'
    ,'aggregate PGA auto target'
    ,'global memory bound'
    ,'total PGA used for auto workareas'
    ,'maximum PGA used for auto workareas'
    ,'total PGA used for manual workareas'
    ,'maximum PGA used for manual workareas'
  )  
;

orcl12c@SYS> !cat auto_workarea.sql
conn sys/oracle@orcl12c as sysdba
alter system set pga_aggregate_target=&1 scope=spfile
.
r
shutdown immediate
startup

prompt +++ initial parameters +++
@show_param

prompt +++ v$pgastat +++
@show_pgstatå

orcl12c@SYS> !cat doTest_auto_workarea.sql
prompt << 10m >>
@auto_workarea 10m

prompt << 50m >>
@auto_workarea 50m

prompt << 100m >>
@auto_workarea 100m

prompt << 500m >>
@auto_workarea 500m

prompt << 1g >>
@auto_workarea 1g

prompt << 5g >>
@auto_workarea 5g

prompt << 10g >>
@auto_workarea 10g

prompt << 50g >>
@auto_workarea 50g

prompt << 100g >>
@auto_workarea 100g

prompt << 500g >>
@auto_workarea 500g

prompt << 1t >>
@auto_workarea 1t

prompt << 4t - 1 >>
@auto_workarea 4398046511103

実行例

orcl12c@SYS> @doTest_auto_workarea.sql
<< 10m >>
Connected.
  1* alter system set pga_aggregate_target=&1 scope=spfile
old   1: alter system set pga_aggregate_target=&1 scope=spfile
new   1: alter system set pga_aggregate_target=10m scope=spfile

System altered.

Database closed.
Database dismounted.
ORACLE instance shut down.
ORACLE instance started.

Total System Global Area 1.2885E+10 bytes
Fixed Size                  8807168 bytes
Variable Size            1375735040 bytes
Database Buffers         5033164800 bytes
Redo Buffers               24743936 bytes
In-Memory Area           6442450944 bytes
Database mounted.
Database opened.
+++ initial parameters +++

KSPPINM                                        KSPPSTVL                       KSPPSTDF
---------------------------------------------- ------------------------------ ------------------------------
__pga_aggregate_target                         33554432                       FALSE

・・・略・・・

pga_aggregate_limit                            0                              FALSE
pga_aggregate_target                           10485760                       FALSE

50 rows selected.

/proc/sys/vm/max_map_count

65530

+++ v$pgastat +++

NAME                                                                  VALUE UNIT             CON_ID
---------------------------------------------------------------- ---------- ------------ ----------
aggregate PGA target parameter                                           10 MB                    0
aggregate PGA auto target                                                 4 MB                    0
global memory bound                                                       2 MB                    0
total PGA used for auto workareas                                .106445313 MB                    0
maximum PGA used for auto workareas                              .106445313 MB                    0
total PGA used for manual workareas                                       0 MB                    0
maximum PGA used for manual workareas                                     0 MB                    0

7 rows selected.

・・・略・・・

・Temp落ち #1 - "Temp落ち" って？
・Temp落ち #2 - PGA (Program Global Area)
・Temp落ち #3 - 手動PGA管理で作業領域として指定可能な最大サイズ
・Temp落ち #4 - 手動PGA管理で作業領域として指定可能な最大サイズ de Temp落ちの確認
・Temp落ち #5 - pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? 12.2.0.1版（その前に少し脱線）

投稿日時 2018年3月 7日 (水) 16時17分チューニング, FAQ, SQL, Oracle Database 11g, Oracle Database 11g Release 2, Oracle Database 12c release 1,

GaragebandとiMovieで

検索

Twitter

オンラインショッピング

最近の記事

最近のコメント

最近のトラックバック

カテゴリー

Oracle

Apple

その他

Googleの広告

RSS

当サイトについて

2023年1月27日 (金)

2023年1月16日 (月)

2022年12月26日 (月)

2022年12月25日 (日)

2022年12月23日 (金)

2022年12月22日 (木)

2022年12月21日 (水)

2022年12月20日 (火)

2022年12月19日 (月)

2022年12月18日 (日)

2022年12月16日 (金)

2022年12月15日 (木)

2022年12月13日 (火)

2022年12月12日 (月)

2022年12月11日 (日)

2022年12月10日 (土)

2022年12月 9日 (金)

2022年12月 8日 (木)

2022年12月 5日 (月)

2022年4月11日 (月)

2022年4月 9日 (土)

2022年4月 7日 (木)

2022年3月21日 (月)

Oracle Vagrant-projects

2021年3月31日 (水)

2021年3月22日 (月)

2019年9月30日 (月)

2019年8月25日 (日)

2019年3月22日 (金)

2019年3月21日 (木)

2019年2月21日 (木)

2019年2月12日 (火)

2019年2月11日 (月)

2018年10月15日 (月)

2018年5月 2日 (水)

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

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

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

2018年4月18日 (水)

2018年4月 8日 (日)

2018年3月18日 (日)

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

だったら、どのようにして、Temp落ち に立ち向かえばいいんだろう.....次回へ続く :)

2018年3月12日 (月)

_pga_max_size

次回は実際に、そんなに使えんのかよ！ という実験をしてみたいと思います :)

2018年3月 8日 (木)

2018年3月 7日 (水)

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

だったら、どのようにして、Temp落ち　に立ち向かえばいいんだろう.....次回へ続く　:)

次回は実際に、そんなに使えんのかよ！　という実験をしてみたいと思います :)