TABLE ACCESS BY INDEX ROWID BATCHED (Oracle Database 12c R1) ってなに！ #2 Tweet

Oracle Database 12c R1 12.1.0.2.0 EEが公開されましたが、12.1.0.1.0で試してあります。

注）バッファキャッシュをクリア後にSQL文を実行してあります。

SELECT
        /*+
                leading(t2 t1)
                use_nl(t2 t1)
                index(t2 pk_high_clustering_factor)
        */
        t2.id
        ,t2.name
        ,t1.name
FROM
        low_clustering_factor t1
        INNER JOIN high_clustering_factor t2
        ON
                t1.id = t2.id
WHERE
        t2.id BETWEEN 30001 AND 35000

上記のSQL文でTABLE ACCESS BY INDEX ROWID BATCHED操作を行わせてみた。

以下、SQLトレースの結果です。予想通り db file parallel readが発生しています。
高いクラスタリングファクタを持つ索引をアクセス、不連続なROWDをかき集めかき集めたROWIDをある程度まとめて１度のI/Oリクエストでバッファキャッシュへ読み込む動作ですよね！

call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        1      0.01       0.07          6          6          0           0
Execute      1      0.00       0.00          0          0          0           0
Fetch      195      0.48       4.92       2288       6338          0        2907
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total      197      0.50       4.99       2294       6344          0        2907

Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 110  (SCOTT)
Number of plan statistics captured: 1

Rows (1st) Rows (avg) Rows (max)  Row Source Operation
---------- ---------- ----------  ---------------------------------------------------
      2907       2907       2907  NESTED LOOPS  (cr=6338 pr=2288 pw=0 time=2150320 us)
      2907       2907       2907   NESTED LOOPS  (cr=3431 pr=2087 pw=0 time=6036546 us cost=3368 size=1159620 card=3514)
      2907       2907       2907    TABLE ACCESS BY INDEX ROWID BATCHED HIGH_CLUSTERING_FACTOR (cr=3107 pr=2082 pw=0 time=5948676 us cost=1012 size=579810 card=3514)
      2907       2907       2907     INDEX RANGE SCAN PK_HIGH_CLUSTERING_FACTOR (cr=201 pr=0 pw=0 time=15435 us cost=11 size=0 card=3514)(object id 93727)
      2907       2907       2907    INDEX UNIQUE SCAN PK_LOW_CLUSTERING_FACTOR (cr=324 pr=5 pw=0 time=56981 us cost=0 size=0 card=1)(object id 93725)
      2907       2907       2907   TABLE ACCESS BY INDEX ROWID LOW_CLUSTERING_FACTOR (cr=2907 pr=201 pw=0 time=312848 us cost=1 size=165 card=1)


Rows     Execution Plan
-------  ---------------------------------------------------
      0  SELECT STATEMENT   MODE: ALL_ROWS
   2907   NESTED LOOPS
   2907    NESTED LOOPS
   2907     TABLE ACCESS (BY INDEX ROWID BATCHED) OF　'HIGH_CLUSTERING_FACTOR' (TABLE)
   2907      INDEX (RANGE SCAN) OF 'PK_HIGH_CLUSTERING_FACTOR' (INDEX (UNIQUE))
   2907     INDEX (UNIQUE SCAN) OF 'PK_LOW_CLUSTERING_FACTOR' (INDEX (UNIQUE))
   2907    TABLE ACCESS (BY INDEX ROWID) OF 'LOW_CLUSTERING_FACTOR' (TABLE)


Elapsed times include waiting on following events:
  Event waited on                             Times   Max. Wait  Total Waited
  ----------------------------------------   Waited  ----------  ------------
  SQL*Net message to client                     195        0.00          0.00
  db file sequential read                       209        0.03          0.32
  SQL*Net message from client                   195       19.95         21.21
  db file parallel read                         194        0.09          4.33
  SQL*Net more data to client                   193        0.00          0.01
********************************************************************************

SQLトレース（整形前）のトレースログより　: db file parallel read （この時は、最小 3blocks〜15blocksの範囲で行われていた。

WAIT #139657829206792: nam='db file parallel read' ela= 64710 files=1 blocks=12 requests=12 obj#=93726 tim=4037078687

ちなみにstraceでみるとio_submitが呼び出されていて11gの頃と変わりはなかった :)

つまり、実行計画上、db file parallel readやるからね！！　物理I/Oを行うときは！　という意思が明確に表示されるようになった。　
分かり易くなっていい!!!!
これだと物理I/Oがあれば、db file parallel readやってるな〜と実行計画を見ただけで想像できますな:)

---

・TABLE ACCESS BY INDEX ROWID BATCHED (Oracle Database 12c R1) ってなに！　#1