Mac De Oracle: 実行計画は、SQL文のレントゲン写真だ！ No.33

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

2022年4月 7日 (木) / Author : Hiroshi Sekiguchi.

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

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

Mac De Oracle

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

GaragebandとiMovieで

検索

Twitter

オンラインショッピング

気まぐれ写真館

最近の記事

最近のコメント

最近のトラックバック

バックナンバー

カテゴリー

Oracle

Apple

その他

Googleの広告

RSS

当サイトについて

2022年4月 7日 (木) / Author : Hiroshi Sekiguchi.

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

コメント

コメントを書く