Introduction
Oracle has optimized (this is just my term) index maintenance mechanism used in some kind of DMLs. I call it “optimized” because in this case Oracle applies each change to an index as array of keys. It is also the reason why you may encounter that a session executing the simplest statement like this

delete 
  from t
 where col = :val

Described optimized index maintenance is performed in:
1. Direct-path insert.
2. Delete / Update / Merge if access path to the data is via b-tree Index Range Scan or Index Full Scan.

The first point is better known. When data inserting is finished durnig direct-path insert index maintenance is peformed. But there is no (or almost no) information about the same process during Update/Delete and conditions when it can be performed.

Note: If you are not interested in internal details you can jump to the section “How it works” below.

There was a topic on sql.ru where the author asked why Oracle uses Index Fast Full Scan instead of an Index Fast Full Scan on simple DML. Let’s check it.

Data preparation

SQL> select * from v$version where rownum = 1;

BANNER
--------------------------------------------------------------------------------
Oracle Database 11g Enterprise Edition Release 11.1.0.7.0 - 64bit Production

SQL> create table t as select * from all_objects;

Table created

SQL> create index i on t(object_id);

Index created

SQL> exec dbms_stats.gather_table_stats(user, 'T', estimate_percent => 100, cascade => true);

PL/SQL procedure successfully completed

SQL> select object_name, object_id from user_objects where object_name in ('T', 'I');

OBJECT_NAME      OBJECT_ID
--------------- ----------
I                    81755
T                    81754

Let’s check what Oracle thinks about following statement

  delete
    from t
   where object_id <> 0;

SQL> explain plan for
  2    delete
  3      from t
  4     where object_id <> 0;

Explained

SQL> @plan

-------------------------------------------------------------------------
| Id  | Operation        | Name | Rows  | Bytes | Cost (%CPU)| Time     |
-------------------------------------------------------------------------
|   0 | DELETE STATEMENT |      | 65919 |   321K|   149   (2)| 00:00:02 |
|   1 |  DELETE          | T    |       |       |            |          |
|*  2 |   INDEX FULL SCAN| I    | 65919 |   321K|   149   (2)| 00:00:02 |
-------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
   2 - filter("OBJECT_ID"<>0)

So, Oracle has choosen Index Full Scan.

Let’s check what Oracle thinks about Index Fast Full Scan

SQL> explain plan for
  2    delete --+ index_ffs(t i)
  3      from t
  4     where object_id <> 0;

Explained

SQL> @plan;

------------------------------------------------------------------------------
| Id  | Operation             | Name | Rows  | Bytes | Cost (%CPU)| Time     |
------------------------------------------------------------------------------
|   0 | DELETE STATEMENT      |      | 65919 |   321K|    35   (3)| 00:00:01 |
|   1 |  DELETE               | T    |       |       |            |          |
|*  2 |   INDEX FAST FULL SCAN| I    | 65919 |   321K|    35   (3)| 00:00:01 |
------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
   2 - filter("OBJECT_ID"<>0)

The cost in IFFS case is 35 when the cost in IFS case is 149.
If we check 10053 we will see than Index Fast Full Scan is not considered at all.
Looks like CBO oddity.

Let’s execute both statements.

SQL> begin
  2
  3      dbms_monitor.session_trace_enable;
  4
  5      delete
  6        from t
  7       where object_id <> 0;
  8
  9      rollback;
 10
 11      delete --+ index_ffs(t i)
 12        from t
 13       where object_id <> 0;
 14
 15      rollback;
 16
 17  end;
 18  /

PL/SQL procedure successfully completed

DELETE FROM T
WHERE
 OBJECT_ID <> 0

call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        1      0.00       0.00          0          0          0           0
Execute      1      2.15       3.16       2135        155      77120       65920
Fetch        0      0.00       0.00          0          0          0           0
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total        2      2.15       3.16       2135        155      77120       65920

Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 9511     (recursive depth: 1)

Rows     Row Source Operation
-------  ---------------------------------------------------
      0  DELETE  T (cr=155 pr=2135 pw=0 time=0 us)
  65920   INDEX FULL SCAN I (cr=147 pr=0 pw=0 time=0 us cost=149 size=329595 card=65919)(object id 81755)

....

DELETE --+ index_ffs(t i)
 FROM T WHERE OBJECT_ID <> 0

call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        1      0.00       0.00          0          0          0           0
Execute      1      3.42       4.61       2697        165     210070       65920
Fetch        0      0.00       0.00          0          0          0           0
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total        2      3.42       4.61       2697        165     210070       65920

Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 9511     (recursive depth: 1)

Rows     Row Source Operation
-------  ---------------------------------------------------
      0  DELETE  T (cr=165 pr=2697 pw=0 time=0 us)
  65920   INDEX FAST FULL SCAN I (cr=153 pr=0 pw=0 time=0 us cost=35 size=329595 card=65919)(object id 81755)

Pay attention 77120 current gets in Index Full Scan case and 210070 current gets in Index Fast Full Scan case.
What is going on?

The answer we can found in redo log dump (similar info you can find in undo changes dump, event 10221).
But before let’s look on the dtracelio output. Note that current version of dtracelio contains mode_held for current gets (db block gets), also it monitors calls of function kcbget which also increment statistic “db block gets” and calculated in “cu=” figures in 10046 trace.

DtraceLIO
Below is an excerpt from Index Full Scan case. The most part of the output (~99%) looks like following (it is only small excerpt):

...
kcbgcur(0xFFFFFFFF7CE5A4E8,2,952,0) [tsn: 5 rdba: 0x1410ec7 (5/69319) obj: 81754 dobj: 81754] where: 952 mode_held: 2
kcbgcur(0xFFFFFFFF7CE5A4E8,2,952,0) [tsn: 5 rdba: 0x1410ec7 (5/69319) obj: 81754 dobj: 81754] where: 952 mode_held: 2
kcbgcur(0xFFFFFFFF7CE5A4E8,2,952,0) [tsn: 5 rdba: 0x1410ec7 (5/69319) obj: 81754 dobj: 81754] where: 952 mode_held: 2
kcbgcur(0xFFFFFFFF7CE5A4E8,2,952,0) [tsn: 5 rdba: 0x1410ec7 (5/69319) obj: 81754 dobj: 81754] where: 952 mode_held: 2
kcbgcur(0xFFFFFFFF7CE5A4E8,2,952,0) [tsn: 5 rdba: 0x1410ec7 (5/69319) obj: 81754 dobj: 81754] where: 952 mode_held: 2
kcbgcur(0xFFFFFFFF7CE5A4E8,2,952,0) [tsn: 5 rdba: 0x1410ec7 (5/69319) obj: 81754 dobj: 81754] where: 952 mode_held: 2
kcbgcur(0xFFFFFFFF7CE5A4E8,2,952,0) [tsn: 5 rdba: 0x1410ec7 (5/69319) obj: 81754 dobj: 81754] where: 952 mode_held: 2
kcbgcur(0xFFFFFFFF7FFF5C48,2,258,0) [tsn: 5 rdba: 0x1410e81 (5/69249) obj: 81754 dobj: 81754] where: 258 mode_held: 2
kcbgcur(0xFFFFFFFF7CE5A4E8,2,952,0) [tsn: 5 rdba: 0x1410ec8 (5/69320) obj: 81754 dobj: 81754] where: 952 mode_held: 2
kcbgcur(0xFFFFFFFF7CE5A4E8,2,952,0) [tsn: 5 rdba: 0x1410ec8 (5/69320) obj: 81754 dobj: 81754] where: 952 mode_held: 2
kcbgcur(0xFFFFFFFF7CE5A4E8,2,952,0) [tsn: 5 rdba: 0x1410ec8 (5/69320) obj: 81754 dobj: 81754] where: 952 mode_held: 2
kcbgcur(0xFFFFFFFF7CE5A4E8,2,952,0) [tsn: 5 rdba: 0x1410ec8 (5/69320) obj: 81754 dobj: 81754] where: 952 mode_held: 2
kcbgcur(0xFFFFFFFF7CE5A4E8,2,952,0) [tsn: 5 rdba: 0x1410ec8 (5/69320) obj: 81754 dobj: 81754] where: 952 mode_held: 2
kcbgcur(0xFFFFFFFF7FFF5C48,2,258,0) [tsn: 5 rdba: 0x1410e81 (5/69249) obj: 81754 dobj: 81754] where: 258 mode_held: 2
kcbgcur(0xFFFFFFFF7CE5A4E8,2,952,0) [tsn: 5 rdba: 0x1410ee0 (5/69344) obj: 81754 dobj: 81754] where: 952 mode_held: 2
kcbgcur(0xFFFFFFFF7CE5A4E8,2,952,0) [tsn: 5 rdba: 0x1410ee0 (5/69344) obj: 81754 dobj: 81754] where: 952 mode_held: 2
kcbgcur(0xFFFFFFFF7CE5A4E8,2,952,0) [tsn: 5 rdba: 0x1410ee0 (5/69344) obj: 81754 dobj: 81754] where: 952 mode_held: 2
kcbgcur(0xFFFFFFFF7CE5A4E8,2,952,0) [tsn: 5 rdba: 0x1410ee0 (5/69344) obj: 81754 dobj: 81754] where: 952 mode_held: 2
kcbgcur(0xFFFFFFFF7FFF5C48,2,258,0) [tsn: 5 rdba: 0x1410e81 (5/69249) obj: 81754 dobj: 81754] where: 258 mode_held: 2
kcbgcur(0xFFFFFFFF7CE5A4E8,2,952,0) [tsn: 5 rdba: 0x1410ee1 (5/69345) obj: 81754 dobj: 81754] where: 952 mode_held: 2
...

Object 81754 is the table.
We can see here
* blocks 5/69319, 5/69320, 5/69344, 5/69345 (table data blocks) are read by kcbgcur calls from where: 952 (“kddwh01: kdddel”, delete row)
* block 5/69249 (first level bitmap block, ASSM) is read by kcbgcur calls from where: 258 is “ktspfwh12: ktspstchg”

These calls delete rows from the table.

after that:

...
kcbgcur(0xFFFFFFFF7FFF5258,1,816,0) [tsn: 5 rdba: 0x140281b (5/10267) obj: 81755 dobj: 81755] where: 816 mode_held: 1
kcbget(0xFFFFFFFF7FFF5258,2,820,0) [tsn: 5 rdba: 0x140281c (5/10268) obj: 81755 dobj: 81755] where: 820 mode_held: 2
kcbgcur(0xFFFFFFFF7FFF2C30,2,38,0) [tsn: 2 rdba: 0xc00100 (3/256) obj: 0 dobj: -1] where: 38 mode_held: 2
kcbgcur(0x461B36078,2,10,0) [tsn: 2 rdba: 0xc81bc9 (3/531401) obj: 0 dobj: -1] where: 10 mode_held: 2
kcbgcur(0xFFFFFFFF7FFF5258,1,816,0) [tsn: 5 rdba: 0x140281b (5/10267) obj: 81755 dobj: 81755] where: 816 mode_held: 1
kcbget(0xFFFFFFFF7FFF5258,2,820,0) [tsn: 5 rdba: 0x140281c (5/10268) obj: 81755 dobj: 81755] where: 820 mode_held: 2
kcbgcur(0xFFFFFFFF7FFF3498,2,258,0) [tsn: 5 rdba: 0x1402818 (5/10264) obj: 81755 dobj: 81755] where: 258 mode_held: 2
...

Object 81755 is the index.
* Block 5/10267 (index root block) is read four times by kcbgcur calls in SHARED mode (mode_held = 1) from where: 816 is “kdiwh17: kdifind” (Finds the appropriate index block to store the key ?).
* Blocks 5/10268 and 5/10269 (index leaf blocks) are read by kcbget in EXCLUSIVE mode (mode_held = 2) from where: 820 is “kdiwh22: kdifind”.
* Block 5/10264 (first level bitmap block, ASSM) is read from where: 258 is “ktspfwh12: ktspstchg”.

Note:
the index in the example has blevel=1, the only root block and leaf blocks. Below I show that all branches are also read before each leaf block.

Summary section:

=============================== Summary =========================
object_id    data_object_id  function   mode_held  where    count
81755        81755           kcbgtcr               1048     1
81755        81755           kcbgtcr               1047     1
0            -1              kcbgcur    2          168      2
0            -1              kcbgtcr               643      2
1            -1              kcbgcur    1          744      2
1            -1              kcbgcur    2          715      2
1            -1              kcbgcur    2          745      2
17           17              kcbgtcr               765      2
44           44              kcbgtcr               815      2
44           44              kcbgtcr               1047     2
0            -1              kcbgcur    1          48       4
0            -1              kcbgcur    1          39       6
81754        81754           kcbgcur    2          325      63
81755        81755           kcbgtcr               814      145
81755        81755           kcbgcur    2          258      146
81755        81755           kcbgcur    1          816      291
81755        81755           kcbget     2          820      291
0            -1              kcbgcur    2          10       2134
0            -1              kcbgcur    2          38       2139
81754        81754           kcbgcur    2          258      3975
81754        81754           kcbgcur    2          952      65922

We can see here
65922 calls of kcbgcur from where: 952 (“kddwh01: kdddel” delete row)
291 calls of kcbgcur from where: 816 in shared mode (index root block)
291 calls of kcbget from where: 820 in exclusive mode (leaf blocks)

Index Fast Full Scan:
The most part of output looks following:

...
kcbgcur(0xFFFFFFFF7FFF67F8,1,816,0) [tsn: 5 rdba: 0x140281b (5/10267) obj: 81755 dobj: 81755] where: 816 mode_held: 1
kcbget(0xFFFFFFFF7FFF67F8,2,820,0) [tsn: 5 rdba: 0x140281c (5/10268) obj: 81755 dobj: 81755] where: 820 mode_held: 2
kcbgcur(0xFFFFFFFF7CE6BFB0,2,952,0) [tsn: 5 rdba: 0x140272b (5/10027) obj: 81754 dobj: 81754] where: 952 mode_held: 2
kcbgcur(0xFFFFFFFF7FFF67F8,1,816,0) [tsn: 5 rdba: 0x140281b (5/10267) obj: 81755 dobj: 81755] where: 816 mode_held: 1
kcbget(0xFFFFFFFF7FFF67F8,2,820,0) [tsn: 5 rdba: 0x140281c (5/10268) obj: 81755 dobj: 81755] where: 820 mode_held: 2
kcbgcur(0xFFFFFFFF7CE6BFB0,2,952,0) [tsn: 5 rdba: 0x140272b (5/10027) obj: 81754 dobj: 81754] where: 952 mode_held: 2
kcbgcur(0xFFFFFFFF7FFF67F8,1,816,0) [tsn: 5 rdba: 0x140281b (5/10267) obj: 81755 dobj: 81755] where: 816 mode_held: 1
kcbget(0xFFFFFFFF7FFF67F8,2,820,0) [tsn: 5 rdba: 0x140281c (5/10268) obj: 81755 dobj: 81755] where: 820 mode_held: 2
kcbgcur(0xFFFFFFFF7CE6BFB0,2,952,0) [tsn: 5 rdba: 0x140272b (5/10027) obj: 81754 dobj: 81754] where: 952 mode_held: 2
kcbgcur(0xFFFFFFFF7FFF67F8,1,816,0) [tsn: 5 rdba: 0x140281b (5/10267) obj: 81755 dobj: 81755] where: 816 mode_held: 1
kcbget(0xFFFFFFFF7FFF67F8,2,820,0) [tsn: 5 rdba: 0x140281c (5/10268) obj: 81755 dobj: 81755] where: 820 mode_held: 2
kcbgcur(0xFFFFFFFF7CE6BFB0,2,952,0) [tsn: 5 rdba: 0x140272b (5/10027) obj: 81754 dobj: 81754] where: 952 mode_held: 2
kcbgcur(0xFFFFFFFF7FFF67F8,1,816,0) [tsn: 5 rdba: 0x140281b (5/10267) obj: 81755 dobj: 81755] where: 816 mode_held: 1
kcbget(0xFFFFFFFF7FFF67F8,2,820,0) [tsn: 5 rdba: 0x140281c (5/10268) obj: 81755 dobj: 81755] where: 820 mode_held: 2
kcbgcur(0xFFFFFFFF7CE6BFB0,2,952,0) [tsn: 5 rdba: 0x140272b (5/10027) obj: 81754 dobj: 81754] where: 952 mode_held: 2
...

We can see here
block 5/10267 (index root block) is read by kcbgcur calls from where: 816 in shared mode.
block 5/10268 (index leaf) is read by kcbget calls from where: 820 in exclusive mode.
block 5/10027 (table data block) is read by kcbgcur calls from where: 952 (kddwh01: kdddel, delete row) in exclusive mode.

=============================== Summary =========================
object_id    data_object_id  function   mode_held  where    count
0            -1              kcbgcur    2          6        1
81755        81755           kcbgtcr               644      2
0            -1              kcbgcur    2          168      3
0            -1              kcbgtcr               643      3
1            -1              kcbgcur    1          744      3
1            -1              kcbgcur    2          715      3
1            -1              kcbgcur    2          745      3
17           17              kcbgtcr               765      3
44           44              kcbgtcr               815      3
44           44              kcbgtcr               1047     3
81755        81755           kcbgtcr               645      4
0            -1              kcbgcur    1          48       5
0            -1              kcbgcur    1          39       8
81754        81754           kcbgcur    2          325      63
81755        81755           kcbgcur    2          258      146
81755        81755           kcbgtcr               872      147
0            -1              kcbgcur    2          10       2696
0            -1              kcbgcur    2          38       2703
81754        81754           kcbgcur    2          258      3975
81755        81755           kcbgcur    1          816      65921
81755        81755           kcbget     2          820      65921
81754        81754           kcbgcur    2          952      65922

We can see here
65921 calls of kcbgcur from where: 816 (index root blocks were read by these calls)
65921 calls of kcbgcur from where: 820 (index leaf blocks were read by these calls)
65921 calls of kcbgcur from where: 952 (table data block were read by these calls)

Redo log dump
And below is an excerpt containing “index undo for leaf key operations” from redo log dump:

Index Full Scan

REDO RECORD - Thread:1 RBA: 0x00002c.0000c7af.0118 LEN: 0x0ff8 VLD: 0x01
SCN: 0x09d8.6f140f23 SUBSCN:  1 12/20/2011 18:13:04
CHANGE #1 TYP:0 CLS:35 AFN:3 DBA:0x00c00110 OBJ:4294967295 SCN:0x09d8.6f140f21 SEQ:  1 OP:5.2 ENC:0
ktudh redo: slt: 0x001f sqn: 0x00000000 flg: 0x000a siz: 3380 fbi: 0
            uba: 0x00c82c4b.0392.01    pxid:  0x0000.000.00000000
CHANGE #2 TYP:1 CLS:36 AFN:3 DBA:0x00c82c4b OBJ:4294967295 SCN:0x09d8.6f140f22 SEQ:  1 OP:5.1 ENC:0
ktudb redo: siz: 3380 spc: 1238 flg: 0x000a seq: 0x0392 rec: 0x01
            xid:  0x000a.01f.00014438
ktubu redo: slt: 31 rci: 0 opc: 10.22 objn: 81755 objd: 81755 tsn: 5
Undo type:  Regular undo       Undo type:  Last buffer split:  No
Tablespace Undo:  No
             0x00c82c4a
index undo for leaf key operations
KTB Redo
op: 0x04  ver: 0x01
compat bit: 4 (post-11) padding: 1
op: L  itl: xid:  0xffff.000.00000000 uba: 0x00000000.0000.00
                      flg: C---    lkc:  0     scn: 0x09d8.6f13d63f
Dump kdilk : itl=2, kdxlkflg=0x25 sdc=0 indexid=0x140281a block=0x0140281c
(kdxlre): restore leaf row (clear leaf delete flags)
number of keys: 255
key sizes:
 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10
 10 10 10 10 10 10 10 10 10 10 10 10 10 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11
 11 11 11 11 11 11 11 11 11 11 11 11 10 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11
key :(2705):
 02 c1 03 06 01 40 27 2b 00 1a 02 c1 04 06 01 40 27 2b 00 04 02 c1 05 06 01
 40 27 2b 00 1f 02 c1 06 06 01 40 27 2b 00 16 02 c1 07 06 01 40 27 2b 00 03
 02 c1 08 06 01 40 27 2b 00 12 02 c1 09 06 01 40 27 2b 00 2e 02 c1 0a 06 01
 40 27 2b 00 20 02 c1 0b 06 01 40 27 2b 00 37 02 c1 0c 06 01 40 27 2b 00 02
...
selflock: (32):
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 00 00 00 00 00 00 00
bitmap: (32):
 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
 ff ff ff ff ff ff ff
CHANGE #3 TYP:0 CLS: 1 AFN:5 DBA:0x0140281c OBJ:81755 SCN:0x09d8.6f140727 SEQ:232 OP:10.4 ENC:0
index redo (kdxlde):  delete leaf row
KTB Redo
op: 0x01  ver: 0x01
compat bit: 4 (post-11) padding: 1
op: F  xid:  0x000a.01f.00014438    uba: 0x00c82c4b.0392.01
REDO: ARRAY / -- / --
itl: 2, sno: 0, row size 3725
number of keys: 255
slots:
 0 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 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49
 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 12
 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190
 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254

Pay attention, CHANGE #2 (index undo) and CHANGE #3 (index redo) contain ARRAY of changes, 255 index keys in each change.

Index Fast Full Scan

REDO RECORD - Thread:1 RBA: 0x00002e.00000005.0020 LEN: 0x00e8 VLD: 0x01
SCN: 0x09d8.6f141196 SUBSCN:  1 12/20/2011 18:20:45
CHANGE #1 TYP:0 CLS:36 AFN:3 DBA:0x00c82d1f OBJ:4294967295 SCN:0x09d8.6f141195 SEQ:  1 OP:5.1 ENC:0
ktudb redo: siz: 100 spc: 3982 flg: 0x0022 seq: 0x0392 rec: 0x1d
            xid:  0x000a.019.00014416
ktubu redo: slt: 25 rci: 28 opc: 10.22 objn: 81755 objd: 81755 tsn: 5
Undo type:  Regular undo       Undo type:  Last buffer split:  No
Tablespace Undo:  No
             0x00000000
index undo for leaf key operations
KTB Redo
op: 0x04  ver: 0x01
compat bit: 4 (post-11) padding: 1
op: L  itl: xid:  0xffff.000.00000000 uba: 0x00000000.0000.00
                      flg: C---    lkc:  0     scn: 0x09d8.6f13d63f
Dump kdilk : itl=2, kdxlkflg=0x1 sdc=0 indexid=0x140281a block=0x0140281c
(kdxlre): restore leaf row (clear leaf delete flags)
key :(10):  02 c1 03 06 01 40 27 2b 00 1a
CHANGE #2 TYP:0 CLS: 1 AFN:5 DBA:0x0140281c OBJ:81755 SCN:0x09d8.6f140fbb SEQ:  2 OP:10.4 ENC:0
index redo (kdxlde):  delete leaf row
KTB Redo
op: 0x01  ver: 0x01
compat bit: 4 (post-11) padding: 1
op: F  xid:  0x000a.019.00014416    uba: 0x00c82d1f.0392.1d
REDO: SINGLE / -- / --
itl: 2, sno: 0, row size 14

...

REDO RECORD - Thread:1 RBA: 0x00002e.00000006.007c LEN: 0x00d0 VLD: 0x01
SCN: 0x09d8.6f141196 SUBSCN:  3 12/20/2011 18:20:45
CHANGE #1 TYP:0 CLS:36 AFN:3 DBA:0x00c82d1f OBJ:4294967295 SCN:0x09d8.6f141196 SEQ:  2 OP:5.1 ENC:0
ktudb redo: siz: 84 spc: 3662 flg: 0x0022 seq: 0x0392 rec: 0x1f
            xid:  0x000a.019.00014416
ktubu redo: slt: 25 rci: 30 opc: 10.22 objn: 81755 objd: 81755 tsn: 5
Undo type:  Regular undo       Undo type:  Last buffer split:  No
Tablespace Undo:  No
             0x00000000
index undo for leaf key operations
KTB Redo
op: 0x02  ver: 0x01
compat bit: 4 (post-11) padding: 1
op: C  uba: 0x00c82d1f.0392.1d
Dump kdilk : itl=2, kdxlkflg=0x1 sdc=0 indexid=0x140281a block=0x0140281c
(kdxlre): restore leaf row (clear leaf delete flags)
key :(10):  02 c1 04 06 01 40 27 2b 00 04
CHANGE #2 TYP:0 CLS: 1 AFN:5 DBA:0x0140281c OBJ:81755 SCN:0x09d8.6f141196 SEQ:  1 OP:10.4 ENC:0
index redo (kdxlde):  delete leaf row
KTB Redo
op: 0x02  ver: 0x01
compat bit: 4 (post-11) padding: 1
op: C  uba: 0x00c82d1f.0392.1f
REDO: SINGLE / -- / --
itl: 2, sno: 1, row size 14

Here each change contains only one index key.

As we can see in the IFS case Oracle is able to delete index keys by a few calls as ARRAY.
And in the IFFS case Oracle deletes index keys as SINGLE records, one by one.

Conclusion
So, the conclusion – probably it is not CBO bug, but feature, heuristic

How it works:
Workarea with operation_type “IDX MAINTENANCE (SORT)” where index keys are sorted and stored is created for each index (btree, non-reverse) whose keys are changed by the DML. So, number of workareas will be equivalent number of appropriate indexes. After data changes is finished index keys from workareas are applied by ARRAYs to the existent indexes.
Thus, be careful, if Oracle does not have required PGA for these workareas these sortings will be spilled on the disk.

Described optimization, ARRAY redo/undo, is applied to ALL appropriate (b-tree, non-reverse) indexes which are changed during DML if access path to changed table is via Index Full/Range Scan.
Let’s look at the the first example:

SQL> explain plan for
  2    delete
  3      from t
  4     where object_id <> 0;

Explained

SQL> @plan

-------------------------------------------------------------------------
| Id  | Operation        | Name | Rows  | Bytes | Cost (%CPU)| Time     |
-------------------------------------------------------------------------
|   0 | DELETE STATEMENT |      | 65919 |   321K|   149   (2)| 00:00:02 |
|   1 |  DELETE          | T    |       |       |            |          |
|*  2 |   INDEX FULL SCAN| IDX  | 65919 |   321K|   149   (2)| 00:00:02 |
-------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
   2 - filter("OBJECT_ID"<>0)

Let’s suggest that index IDX is a reverse index. In this case ARRAY optimization is not applied for this exact index.
All redo/undo changes will be SINGLE, row by row. As in Full Table Scan or Index Fast Full Scan cases.

But what if there are N more normal b-tree indexes on the table T?
In this case ARRAY optimization will be applied for all these indexes except reverse index IDX, although the execution plan contains Index Full Scan on reverse index IDX.

Additional points
I would like to emphasize some points which are described in this post

1. I’ve learnt that Jonathan Lewis wrote about this phenomenon in 2006(!)
http://jonathanlewis.wordpress.com/2006/11/22/tuning-updates/

2. Note, how index blocks are read during DML.
Before leaf block is read for change (to change a key from kdifind, in fact you can see many another block gets especially during update statement) index root block and all index branch blocks above that leaf are also read.
Without ARRAY optimization (Full Table Scan, Index Fast Full Scan, reverse index, IOT, etc) it is caused for each row change.
And with ARRAY optimization it is caused (leaf block read) for each array batch operation.
This is especially important for indexes with high blevel.

The index in the example above has blevel=1, so the only root block and leaf blocks.
Let’s look at an excerpt of dtracelio output of the similar index changes in index with blevel=4.
Here we can see two array changes for two leaf blocks.

...
kcbgcur(0xFFFFFFFF7FFF5258,1,816,0) [tsn: 31 rdba: 0x1e8a32c4 (122/668356) obj: 82756 dobj: 82756] where: 816 mode_held: 1
kcbget(0xFFFFFFFF7FFF5258,1,820,0) [tsn: 31 rdba: 0x1e8a328c (122/668300) obj: 82756 dobj: 82756] where: 820 mode_held: 1
kcbget(0xFFFFFFFF7FFF5258,1,820,0) [tsn: 31 rdba: 0x1d894f8e (118/610190) obj: 82756 dobj: 82756] where: 820 mode_held: 1
kcbget(0xFFFFFFFF7FFF5258,1,820,0) [tsn: 31 rdba: 0x1f09a0ec (124/631020) obj: 82756 dobj: 82756] where: 820 mode_held: 1
kcbget(0xFFFFFFFF7FFF5258,2,820,0) [tsn: 31 rdba: 0x1e8a328f (122/668303) obj: 82756 dobj: 82756] where: 820 mode_held: 2
kcbgcur(0xFFFFFFFF7FFF5258,1,816,0) [tsn: 31 rdba: 0x1e8a32c4 (122/668356) obj: 82756 dobj: 82756] where: 816 mode_held: 1
kcbget(0xFFFFFFFF7FFF5258,1,820,0) [tsn: 31 rdba: 0x1e8a328c (122/668300) obj: 82756 dobj: 82756] where: 820 mode_held: 1
kcbget(0xFFFFFFFF7FFF5258,1,820,0) [tsn: 31 rdba: 0x1d894f8e (118/610190) obj: 82756 dobj: 82756] where: 820 mode_held: 1
kcbget(0xFFFFFFFF7FFF5258,1,820,0) [tsn: 31 rdba: 0x1f09a0ec (124/631020) obj: 82756 dobj: 82756] where: 820 mode_held: 1
kcbget(0xFFFFFFFF7FFF5258,2,820,0) [tsn: 31 rdba: 0x1f09a0e0 (124/631008) obj: 82756 dobj: 82756] where: 820 mode_held: 2
...

In the case without array optimization these gets (root, branches, leaf) will be read for each index key change.

3. The optimization is not performed on IOTs itself, but performed on additional indexes on IOT.

4. It does not work for whole DML when access path is Index Range/Full Scan Descending (as in an example below),

SQL> explain plan for
  2      delete --+ index_desc(t)
  3        from t
  4       where object_id <> 0;
 
Explained
 
SQL> @planb
--------------------------------------------
| Id  | Operation                   | Name |
--------------------------------------------
|   0 | DELETE STATEMENT            |      |
|   1 |  DELETE                     | T    |
|   2 |   INDEX FULL SCAN DESCENDING| IDX  |
--------------------------------------------

5. It also does not work in the following case:

SQL> explain plan for
  2      delete --+ all_rows
  3        from t
  4       where object_id <> 0
  5         and rownum < 999999999999;   
Explained   

SQL> @plan
--------------------------------------------------------------------------
| Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------
|   0 | DELETE STATEMENT  |      | 65919 |   321K|   149   (2)| 00:00:02 |
|   1 |  DELETE           | T    |       |       |            |          |
|*  2 |   COUNT STOPKEY   |      |       |       |            |          |
|*  3 |    INDEX FULL SCAN| I    | 65919 |   321K|   149   (2)| 00:00:02 |
--------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
   2 - filter(ROWNUM   3 - filter("OBJECT_ID"<>0)

6. From the other hand this optimization works in more complicated execution plans as following cases:

delete
  from t1
 where exists (select 1 from t2 where t2.id = t1.id)

---------------------------------------
| Id  | Operation              | Name |
---------------------------------------
|   0 | DELETE STATEMENT       |      |
|   1 |  DELETE                | T1   |
|   2 |   HASH JOIN SEMI       |      |
|   3 |    INDEX FULL SCAN     | PK1  |
|   4 |    INDEX FAST FULL SCAN| PK2  |
---------------------------------------

------------------------------------
| Id  | Operation           | Name |
------------------------------------
|   0 | DELETE STATEMENT    |      |
|   1 |  DELETE             | T1   |
|   2 |   NESTED LOOPS SEMI |      |
|   3 |    INDEX FULL SCAN  | PK1  |
|   4 |    INDEX UNIQUE SCAN| PK2  |
------------------------------------

P.S.
Btw, are you aware that there is Dtrace for Oracle Linux ( http://blogs.oracle.com/wim/entry/trying_out_dtrace )?
I have not touched yet, you have a chance, enjoy!

This is the DTrace script: dtracelio.d

Short description:
This tool allows to see:
– details of each call (consistent/current get)
– details of blocks been read
– function from which call been performed without investigating of call stack (“where”)
– aggregation of performed calls

The tool can be especially helpful in 11g because x$kcbuwhy (x$kcbsw in 10g) is not populated properly there.
Note: Examples of using views x$kcbsw/x$kcbuwhy:
- Investigating Logical I/O by Jonathan Lewis
- Finding the reasons for excessive logical IOs by Tanel Poder

Current version of the script monitors execution of two Kernel Cache Layer functions:
kcbgtcr – Kernel Cache Buffer Get Consistent Read. Number of calls of this function we can see as statistic “consistent gets” and in 10046 trace as “cr=”.
kcbgcur – Kernel Cache Buffer Get Current Read. Number of calls of this function we can see as statistic “db block gets” in 10046 trace as “cu=”.
upd:
statistic “db block gets” is incremented not only by kcbgcur, but also by kcbget (included in current version of dtracelio.d), kcbnew (coming soon), and some others. But kcbgcur is most often used.

In the both functions:
- the first argument is a pointer on the structure which describes a block;
- the second argument is unknown, but I could suggest that this is lock_mode (from MOS bug 7109078);
- the third argument (the least significant bits) is “where” (x$kcbwh), that is a module where the function is called.

Usage:
dtracelio.d PID [show_each_call]

PID – unix process ID
show_each_call – if 0 then output of each call will be disabled, else details of each call will be shown

A little example of usage. Let’s try to see what is going on during select on very small table:

SQL> @spid
 
       SID ORACLE_DEDICATED_PROCESS CLIENTPID
---------- ------------------------ ------------------------
        41 18949                    900:408
 
SQL> create table dualcopy as select * from dual;
 
Table created
 
SQL> select * from dualcopy;
 
DUMMY
-----
X

Let’s execute dtracelio

dtracelio.d 18949

Now I am executing our query:

SQL> select * from dualcopy;
 
DUMMY
-----
X

And this is an output of dtracelio

kcbgtcr(0xFFFFFD7FFFDFB0F0,0,742,0) [tsn: 4 rdba: 0x100060a (4/1546) obj: 79218 dobj: 79218] where: 742
kcbgtcr(0xFFFFFD7FFFDFAED0,0,743,0) [tsn: 4 rdba: 0x100060a (4/1546) obj: 79218 dobj: 79218] where: 743
kcbgtcr(0xFFFFFD7FFDC3B2E0,0,860,0) [tsn: 4 rdba: 0x100060b (4/1547) obj: 79218 dobj: 79218] where: 860

You can see here:
kcbgtcr(0xFFFFFD7FFFDFB0F0,0,742,0) – it is function call with 3 arguments,
tsn: 4 – a tablespace number, ts# from v$tablespace
rdba: 0x100060a – a relative dba (data block address)
(4/1546) – file 4 block 1546
obj: 79218 – dictionary object number, object_id from dba_objects
dobj: 79218 – data object number, data_object_id from dba_objects
where: 742 – location from function (kcbgtcr in this case) was executed. This is INDX from x$kcbwf.

SQL> select indx, kcbwhdes from x$kcbwh where indx in (742, 743, 860);
 
      INDX KCBWHDES
---------- ----------------------------------------------------------------
       742 ktewh25: kteinicnt
       743 ktewh26: kteinpscan
       860 kdswh01: kdstgr

kcbgtcr(0xFFFFFD7FFFDFB0F0,0,742,0) [tsn: 4 rdba: 0x100060a (4/1546) obj: 79218 dobj: 79218] where: 742

              oracle`kcbgtcr
              oracle`ktecgshx+0x3f6
              oracle`kteinicnt1+0x1cf
              oracle`qertbFetch+0xc2a
              oracle`opifch2+0xaa2
              oracle`opifch+0x3a
              oracle`opiodr+0x433
              oracle`ttcpip+0x599
              oracle`opitsk+0x600
              oracle`opiino+0x675
              oracle`opiodr+0x433
              oracle`opidrv+0x32e
              oracle`sou2o+0x57
              oracle`opimai_real+0x219
              oracle`ssthrdmain+0x14e
              oracle`main+0xcb
              oracle`0x159e67c

kcbgtcr(0xFFFFFD7FFFDFAED0,0,743,0) [tsn: 4 rdba: 0x100060a (4/1546) obj: 79218 dobj: 79218] where: 743

              oracle`kcbgtcr
              oracle`ktecgshx+0x3f6
              oracle`kteinpscan+0x1b6
              oracle`kteiniscan+0x2c
              oracle`kdselini+0x2f
              oracle`kdsirs1+0x792
              oracle`kdsirs+0x2b
              oracle`qertbFetch+0xbb0
              oracle`opifch2+0xaa2
              oracle`opifch+0x3a
              oracle`opiodr+0x433
              oracle`ttcpip+0x599
              oracle`opitsk+0x600
              oracle`opiino+0x675
              oracle`opiodr+0x433
              oracle`opidrv+0x32e
              oracle`sou2o+0x57
              oracle`opimai_real+0x219
              oracle`ssthrdmain+0x14e
              oracle`main+0xcb

kcbgtcr(0xFFFFFD7FFDC3B2E0,0,860,0) [tsn: 4 rdba: 0x100060b (4/1547) obj: 79218 dobj: 79218] where: 860

              oracle`kcbgtcr
              oracle`ktrget2+0x27d
              oracle`kdstgr+0x46b
              oracle`qertbFetch+0x466
              oracle`opifch2+0xaa2
              oracle`opifch+0x3a
              oracle`opiodr+0x433
              oracle`ttcpip+0x599
              oracle`opitsk+0x600
              oracle`opiino+0x675
              oracle`opiodr+0x433
              oracle`opidrv+0x32e
              oracle`sou2o+0x57
              oracle`opimai_real+0x219
              oracle`ssthrdmain+0x14e
              oracle`main+0xcb
              oracle`0x159e67c

So, 3 consistent gets, 3 logical reads were performed.
Two times block (4/1546) – this is segment header – has been read. The first time from function kteinicnt and the second time from function kteinpscan.
And the third get is block (4/1547) – this is data block – was read from function kdstgr.

After that, if you push Ctrl+C, dtracelio script will be finished, and you will see Summary section:

^C

========================= Summary ==========================
object_id    data_object_id  function     where        count
79218        79218           kcbgtcr      742          1
79218        79218           kcbgtcr      743          1
79218        79218           kcbgtcr      860          1

example 2
There was question on sql.ru. The author asked “why number of current gets (db block gets) during update in distributed transaction is more then in usual, non-distributed transaction?”.
In his case it were:
3070178 current gets in non-distributed transaction
6070211 current gets in distributed transaction

So, let’s find out what exactly is read during distributed transaction and is not read in usual, non-distributed transaction.

SQL> select * from v$version;
 
BANNER
--------------------------------------------------------------------------------
Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - 64bit Production
PL/SQL Release 11.2.0.2.0 - Production
CORE	11.2.0.2.0	Production
TNS for Solaris: Version 11.2.0.2.0 - Production
NLSRTL Version 11.2.0.2.0 - Production

SQL> @spid
 
       SID ORACLE_DEDICATED_PROCESS CLIENTPID
---------- ------------------------ ------------------------
         1 16727                    900:408

SQL> create table test as select * from all_objects;
 
Table created

SQL> alter session set optimizer_dynamic_sampling=0;
 
Session altered

SQL> @10046
 
Session altered

Here we are executing dtracelio.d:

dtracelio.d 16727 0

1st update, without distributed transaction

SQL> begin
  2      update test set owner = owner;
  3      commit;
  4  end;
  5  /
 
PL/SQL procedure successfully completed

After the update has been completed we can push Ctrl+C to finish the DTrace and see the Summary section:

^C
========================= Summary ==========================
object_id    data_object_id  function     where        count
...
0            -1              kcbgcur      48           16
0            -1              kcbgcur      156          16
17           17              kcbgtcr      869          18
0            -1              kcbgcur      51           253
0            -1              kcbgcur      79           1365
79204        79204           kcbgcur      878          1656
0            -1              kcbgcur      50           2357
-1           79204           kcbgcur      859          2357
79204        79204           kcbgtcr      869          2726
79204        79204           kcbgcur      1053         75105

An excerpt from raw 10046 trace:

=====================
PARSING IN CURSOR #18446741324891442008 len=60 dep=0 uid=0 oct=47 lid=0 tim=229288260276 hv=2516922591 ad='88f557c0' sqlid='6sj578yb0ac6z'
begin
    update test set owner = owner;
    commit;
end;
END OF STMT
....
EXEC #18446741324891442008:c=2780000,e=4884618,p=0,cr=2776,cu=84545,mis=0,r=1,dep=0,og=1,plh=0,tim=229293144944

Now let’s execute the same update within distributed transaction

SQL> declare
  2    i integer;
  3  begin
  4  
  5    select count(*) into i from dual@dblink;
  6    update test set owner = owner;
  7    commit;
  8  
  9  end;
 10  /

PARSING IN CURSOR #18446741324891442008 len=122 dep=0 uid=0 oct=47 lid=0 tim=229346672450 hv=1954107067 ad='88f04bc0' sqlid='arss8t9u7kmpv'
declare
  i integer;
begin
  select count(*) into i from dual@dblink;
  update test set owner = owner;
  commit;
end;
END OF STMT
...
EXEC #18446741324891442008:c=2950000,e=3432722,p=0,cr=2298,cu=159479,mis=0,r=1,dep=0,og=1,plh=0,tim=229350105247

As we can see cu=159479, about in two times more then in previous execution.

dtracelio.d output:

========================= Summary ==========================
object_id    data_object_id  function     where        count
...
0            -1              kcbgcur      48           16
0            -1              kcbgcur      156          16
17           17              kcbgtcr      869          18
0            -1              kcbgcur      51           49
0            -1              kcbgcur      50           442
-1           79204           kcbgcur      859          442
0            -1              kcbgcur      79           1161
79204        79204           kcbgcur      878          1177
79204        79204           kcbgtcr      869          2248
79204        79204           kcbgcur      1053         75105
0            -1              kcbgcur      109          79853

Pay attention on the last row

0            -1              kcbgcur      109          79853

If we take a look at the output of dtracelio.d with enabled output of each call we will see something like this:

...
kcbgcur(0xFFFFFD7FFDC42D68,2,1053,0) [tsn: 0 rdba: 0x4186e6 (1/100070) obj: 79204 dobj: 79204] where: 1053
kcbgcur(0xFFFFFD7FFFDF46A0,1,109,0) [tsn: 2 rdba: 0xc000f0 (3/240) obj: 0 dobj: -1] where: 109
kcbgcur(0xFFFFFD7FFDC42D68,2,1053,0) [tsn: 0 rdba: 0x4186e6 (1/100070) obj: 79204 dobj: 79204] where: 1053
kcbgcur(0xFFFFFD7FFFDF46A0,1,109,0) [tsn: 2 rdba: 0xc000f0 (3/240) obj: 0 dobj: -1] where: 109
kcbgcur(0xFFFFFD7FFDC42D68,2,1053,0) [tsn: 0 rdba: 0x4186e6 (1/100070) obj: 79204 dobj: 79204] where: 1053
kcbgcur(0xFFFFFD7FFFDF46A0,1,109,0) [tsn: 2 rdba: 0xc000f0 (3/240) obj: 0 dobj: -1] where: 109
kcbgcur(0xFFFFFD7FFDC42D68,2,1053,0) [tsn: 0 rdba: 0x4186e6 (1/100070) obj: 79204 dobj: 79204] where: 1053
kcbgcur(0xFFFFFD7FFFDF46A0,1,109,0) [tsn: 2 rdba: 0xc000f0 (3/240) obj: 0 dobj: -1] where: 109
kcbgcur(0xFFFFFD7FFDC42D68,2,1053,0) [tsn: 0 rdba: 0x4186e6 (1/100070) obj: 79204 dobj: 79204] where: 1053
kcbgcur(0xFFFFFD7FFFDF46A0,1,109,0) [tsn: 2 rdba: 0xc000f0 (3/240) obj: 0 dobj: -1] where: 109
kcbgcur(0xFFFFFD7FFDC42D68,2,1053,0) [tsn: 0 rdba: 0x4186e6 (1/100070) obj: 79204 dobj: 79204] where: 1053
...

Let’s try to look at inside the block.

alter system dump datafile 3 block 240;

...
Block dump from disk:
buffer tsn: 2 rdba: 0x00c000f0 (3/240)
scn: 0x0000.0015240d seq: 0x02 flg: 0x04 tail: 0x240d2602
frmt: 0x02 chkval: 0x54dc type: 0x26=KTU SMU HEADER BLOCK
...

What is “where: 109″? “Where” means location in code, let’s try to find function name with indx 109

SQL> select indx, kcbwhdes from x$kcbwh where indx = 109;
 
      INDX KCBWHDES
---------- ----------------------------------------------------------------
       109 ktuwh87: ktugus:ktuGetExtTxnInfo

 
 0000000002c63d01 kcbgcur () + 1
 00000000029272d4 ktuGetExtTxnInfo () + 174
 00000000028f5193 ktugti () + 13
 00000000028e2561 ktuchg2 () + 1971
 0000000002944d2f ktbchg2 () + 12f
 0000000001b04809 kdu_array_flush_retry () + c69
 0000000001b01f42 kdu_array_buf () + 522
 0000000001af5390 kduurp () + 460
 0000000001adea00 kdusru () + 13e0
 0000000001ac6c12 kauupd () + 1b2
 0000000005a3370c updrow () + a5c
 0000000007b8bd27 qerupFetch () + 397
 000000000367cfdc qerstFetch () + 58c
 0000000005a3f2fe updaul () + 4ce
 0000000005a4469d updThreePhaseExe () + 1cd
 0000000005a43abd updexe () + 1ed
 000000000447b2c5 opiexe () + 2455
...

It were for 11.2.0.2. In my 10.2.0.5 all these additional calls are with “where: 383″, “ktuwh02: ktugus” which Jonathan Lewis called “Get Undo Segment header for commit” (Seems it is not correct descriptoin).
And following call stack is during these calls

              oracle`kcbgcur
              oracle`ktugusc+0x321
              oracle`ktugti+0xf2
              oracle`ktuchg+0x139a
              oracle`ktbchg2+0x115
              oracle`kddchg+0x2c2
              oracle`kddlok+0x7da
              oracle`kddlkr+0x16a
              oracle`updrow+0x2417
              oracle`qerupRowProcedure+0x4f
              oracle`qerupFetch+0x339
              oracle`updaul+0x481
              oracle`updThreePhaseExe+0xc72
              oracle`updexe+0x171
              oracle`opiexe+0xf1b
              oracle`opipls+0x98e
              oracle`opiodr+0x433
              oracle`rpidrus+0xde
              oracle`skgmstack+0x80
              oracle`rpidru+0x86

Conclusion
We have determined what exactly are extra current gets within distributed transaction.
Why Oracle 79853 times reads undo header is a topic for further research. I would prefer to write another post about it.

Little oftopic, but interesting point is that Oracle opens distributed transaction (binds undo header, transaction appears in v$transaction, v$global_transaction) for PLSQL block with dblinks during hard parsing. If hard parsing is not performed then during parsing/execution of statement with dblink.
It follows that if you will execute a statement like this

declare
    i integer;
begin
    DML;
    DML;
    DML;
    if 1=0 then
        select count(*) into i from dual@dblink;
    end if;
end;

p.s.
Attention!
I am still looking for additional information about
* structure kcbds,
* argments of functions kcbgtcr
* argments of functions kcbgcur
If you have this information please let me know.

Update 06.12.2011
Note: The following effects appear only with Index Full Scan and does not exist with Index Range Scan.

This post related with a question on sql.ru which I answered a coulpe days ago.

Preparing of data:

SQL> create table test (id not null, val) pctfree 99
  2    as select level, level
  3         from dual
  4      connect by level <= 1000;

Table created

SQL> create index test_idx on test(id);

Index created

First, I try to use row_number() = 1

SQL> select id, val
  2    from (select --+ index(t test_idx)
  3                 id,
  4                 val,
  5                 row_number() over(order by id) as rn
  6            from test t)
  7   where rn = 1;

        ID        VAL
---------- ----------
         1          1

runtime execution plan of the query:

-------------------------------------------------------------------------------------------
| Id  | Operation                     | Name     | Starts | A-Rows |   A-Time   | Buffers |
-------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT              |          |      1 |      1 |00:00:00.01 |       3 |
|*  1 |  VIEW                         |          |      1 |      1 |00:00:00.01 |       3 |
|*  2 |   WINDOW NOSORT STOPKEY       |          |      1 |      1 |00:00:00.01 |       3 |
|   3 |    TABLE ACCESS BY INDEX ROWID| TEST     |      1 |      2 |00:00:00.01 |       3 |
|   4 |     INDEX FULL SCAN           | TEST_IDX |      1 |      2 |00:00:00.01 |       2 |
-------------------------------------------------------------------------------------------

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

   1 - filter("RN"=1)
   2 - filter(ROW_NUMBER() OVER ( ORDER BY "ID")<=1)

As we can see, step 2 WINDOW NOSORT STOPKEY returns 1 row to parent rowsource after getting of 2 rows from child rowsource.

Now compare this with construction “row_number() < 2″ which some developers prefer to use.

SQL> select id, val
  2    from (select --+ index(t test_idx)
  3                 id,
  4                 val,
  5                 row_number() over(order by id) as rn
  6            from test t)
  7   where rn < 2;

        ID        VAL
---------- ----------
         1          1

And runtime execution plan of the query:

-------------------------------------------------------------------------------------------
| Id  | Operation                     | Name     | Starts | A-Rows |   A-Time   | Buffers |
-------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT              |          |      1 |      1 |00:00:00.01 |       3 |
|*  1 |  VIEW                         |          |      1 |      1 |00:00:00.01 |       3 |
|*  2 |   WINDOW NOSORT STOPKEY       |          |      1 |      2 |00:00:00.01 |       3 |
|   3 |    TABLE ACCESS BY INDEX ROWID| TEST     |      1 |      3 |00:00:00.01 |       3 |
|   4 |     INDEX FULL SCAN           | TEST_IDX |      1 |      3 |00:00:00.01 |       2 |
-------------------------------------------------------------------------------------------

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

   1 - filter("RN"<2)
   2 - filter(ROW_NUMBER() OVER ( ORDER BY "ID")<2)

In this case step 2 “WINDOW NOSORT STOPKEY” returns 2 rows to parent rowsource after getting of 3 rows from child rowsource.

Obviously in some cases this little difference (just one row) can lead to the large difference in the amount of work and, consequently, possible performance degradation of a query.
One example provided in thread on sql.ru. Child rowsource is “GROUP BY NOSORT” which needs to read N additional rows from an index and a table to return the third grouped value.
Another example (below) shows case where for return the third row Oracle should read and filter a lot of rows thanks to filter predicates.

SQL> select id, val
  2    from (select --+ index(t test_idx)
  3                 id,
  4                 val,
  5                 row_number() over(order by id) as rn
  6            from test t
  7           where val <= 2 or val > 900)
  8   where rn < 2;

        ID        VAL
---------- ----------
         1          1

-------------------------------------------------------------------------------------------
| Id  | Operation                     | Name     | Starts | A-Rows |   A-Time   | Buffers |
-------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT              |          |      1 |      1 |00:00:00.01 |     180 |
|*  1 |  VIEW                         |          |      1 |      1 |00:00:00.01 |     180 |
|*  2 |   WINDOW NOSORT STOPKEY       |          |      1 |      2 |00:00:00.01 |     180 |
|*  3 |    TABLE ACCESS BY INDEX ROWID| TEST     |      1 |      3 |00:00:00.01 |     180 |
|   4 |     INDEX FULL SCAN           | TEST_IDX |      1 |    901 |00:00:00.01 |       3 |
-------------------------------------------------------------------------------------------

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

   1 - filter("RN"<2)
   2 - filter(ROW_NUMBER() OVER ( ORDER BY "ID")<2)
   3 - filter(("VAL"<=2 OR "VAL">900))

Pay attention, 901 rows were fetched from the table, 3 + 180 logical reads were done, to check predicate “filter((“VAL”<=2 OR “VAL”>900))” and return the third row.

Compare the same query with rn = 1 instead of rn < 2

SQL> select id, val
  2    from (select --+ index(t test_idx)
  3                 id,
  4                 val,
  5                 row_number() over(order by id) as rn
  6            from test t
  7           where val <= 2 or val > 900)
  8   where rn = 1;

        ID        VAL
---------- ----------
         1          1

-------------------------------------------------------------------------------------------
| Id  | Operation                     | Name     | Starts | A-Rows |   A-Time   | Buffers |
-------------------------------------------------------------------------------------------
|*  1 |  VIEW                         |          |      1 |      1 |00:00:00.01 |       3 |
|*  2 |   WINDOW NOSORT STOPKEY       |          |      1 |      1 |00:00:00.01 |       3 |
|*  3 |    TABLE ACCESS BY INDEX ROWID| TEST     |      1 |      2 |00:00:00.01 |       3 |
|   4 |     INDEX FULL SCAN           | TEST_IDX |      1 |      2 |00:00:00.01 |       2 |
-------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
   1 - filter("RN"=1)
   2 - filter(ROW_NUMBER() OVER ( ORDER BY "ID")<=1)
   3 - filter(("VAL"<=2 OR "VAL">900))

p.s.
By the way, usual rownum and COUNT STOPKEY read only 1 row from child rowsource in both cases.

SQL> select id, val
  2    from (select --+ index(t test_idx)
  3                 id,
  4                 val
  5            from test t
  6           where val <= 2 or val > 900)
  7   where rownum < 2;

        ID          N
---------- ----------
         1          1

------------------------------------------------------------------------------------------
| Id  | Operation                    | Name     | Starts | A-Rows |   A-Time   | Buffers |
------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT             |          |      1 |      1 |00:00:00.01 |       3 |
|*  1 |  COUNT STOPKEY               |          |      1 |      1 |00:00:00.01 |       3 |
|*  2 |   TABLE ACCESS BY INDEX ROWID| TEST     |      1 |      1 |00:00:00.01 |       3 |
|   3 |    INDEX FULL SCAN           | TEST_IDX |      1 |      1 |00:00:00.01 |       2 |
------------------------------------------------------------------------------------------

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

   1 - filter(ROWNUM<2)
   2 - filter(("VAL"<=2 OR "VAL">900))

create table test as select * from all_objects;
create index idx on test(object_name);
alter table test modify(object_name null);
exec dbms_stats.gather_table_stats(user, 'test', estimate_percent=>100, cascade => true);
explain plan for select max(object_name) from test;
select * from table(dbms_xplan.display);

10.2.0.4

SQL> create table test as select * from all_objects;

Table created

SQL> create index idx on test(object_name);

Index created

SQL> alter table test modify(object_name null);

Table altered

SQL> exec dbms_stats.gather_table_stats(user, 'test', estimate_percent=>100, cascade => true);

PL/SQL procedure successfully completed

SQL> explain plan for select max(object_name) from test;

Explained

select * from table(dbms_xplan.display);

-----------------------------------------------------------------------------------
| Id  | Operation                  | Name | Rows  | Bytes | Cost (%CPU)| Time     |
-----------------------------------------------------------------------------------
|   0 | SELECT STATEMENT           |      |     1 |    24 |   460  (15)| 00:00:01 |
|   1 |  SORT AGGREGATE            |      |     1 |    24 |            |          |
|   2 |   INDEX FULL SCAN (MIN/MAX)| IDX  | 53773 |  1260K|            |          |
-----------------------------------------------------------------------------------

Notice, that cardinality of step 2 = 53773 (should be = 1 obviously) and more important(!) cost = 460.
Real cost of this operation is much less. Access path INDEX FULL SCAN (MIN/MAX) means that only leftmost or rightmost index block will be read. Thus cost of this operation should be equal blevel+1.
This problem is investigated below.

11.1.0.6

-----------------------------------------------------------------------------------
| Id  | Operation                  | Name | Rows  | Bytes | Cost (%CPU)| Time     |
-----------------------------------------------------------------------------------
|   0 | SELECT STATEMENT           |      |     1 |    25 |     3   (0)| 00:00:01 |
|   1 |  SORT AGGREGATE            |      |     1 |    25 |            |          |
|   2 |   INDEX FULL SCAN (MIN/MAX)| IDX  | 65965 |  1610K|     3   (0)| 00:00:01 |
-----------------------------------------------------------------------------------

Notice, that the cost is correct. However cardinality of step 2 is still not correct. It should not affect anything becasuse cardinality of parent step SORT AGGREGATE or FIRST ROW is 1.

11.2.0.2

-----------------------------------------------------------------------------------
| Id  | Operation                  | Name | Rows  | Bytes | Cost (%CPU)| Time     |
-----------------------------------------------------------------------------------
|   0 | SELECT STATEMENT           |      |     1 |    11 |     3   (0)| 00:00:01 |
|   1 |  SORT AGGREGATE            |      |     1 |    11 |            |          |
|   2 |   INDEX FULL SCAN (MIN/MAX)| IDX  |     1 |    11 |     3   (0)| 00:00:01 |
-----------------------------------------------------------------------------------

10.2.0.4 more details
Let’s return to 10.2.0.4. In this case such high cost is a real problem.
Execution plan with runtime statistics confirms this

------------------------------------------------------------------------------------------------------
| Id  | Operation                  | Name | Starts | E-Rows | A-Rows |   A-Time   | Buffers | Reads  |
------------------------------------------------------------------------------------------------------
|   1 |  SORT AGGREGATE            |      |      1 |      1 |      1 |00:00:00.01 |       3 |      1 |
|   2 |   INDEX FULL SCAN (MIN/MAX)| IDX  |      1 |  53773 |      1 |00:00:00.01 |       3 |      1 |
------------------------------------------------------------------------------------------------------
Note
-----
   - rule based optimizer used (consider using cbo)

The problem is that if there will exist another access path with cost less than 460 (in our case) Oracle chooses that cheaper access path instead of MIN/MAX optimization which is the best way obviously.

For example, let’s create another index containing column object_name:

SQL> create index idx2 on test(owner, object_name);

Index created

SQL> explain plan for select max(object_name) from test;

Explained

SQL> @plan

------------------------------------------------------------------------------
| Id  | Operation             | Name | Rows  | Bytes | Cost (%CPU)| Time     |
------------------------------------------------------------------------------
|   0 | SELECT STATEMENT      |      |     1 |    24 |   199  (20)| 00:00:01 |
|   1 |  SORT AGGREGATE       |      |     1 |    24 |            |          |
|   2 |   INDEX FAST FULL SCAN| IDX2 | 53773 |  1260K|   199  (20)| 00:00:01 |
------------------------------------------------------------------------------

Workaround is in addition “is not null” condition.

SQL> explain plan for select max(object_name) from test where object_name is not null;

Explained

SQL> @plan
--------------------------------------------------------------------------------
Plan hash value: 1520840685
------------------------------------------------------------------------------------
| Id  | Operation                   | Name | Rows  | Bytes | Cost (%CPU)| Time     |
------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT            |      |     1 |    24 |     3   (0)| 00:00:01 |
|   1 |  SORT AGGREGATE             |      |     1 |    24 |            |          |
|   2 |   FIRST ROW                 |      | 53773 |  1260K|     3   (0)| 00:00:01 |
|   3 |    INDEX FULL SCAN (MIN/MAX)| IDX  | 53773 |  1260K|     3   (0)| 00:00:01 |
------------------------------------------------------------------------------------

But how and why this cost was calculated?
Below is an excerpt from 10053 trace

BASE STATISTICAL INFORMATION
***********************
Table Stats::
  Table: TEST  Alias: TEST
    #Rows: 53773  #Blks:  1571  AvgRowLen:  97.00
Index Stats::
  Index: IDX  Col#: 2
    LVLS: 2  #LB: 538  #DK: 29266  LB/K: 1.00  DB/K: 1.00  CLUF: 27735.00
***************************************
SINGLE TABLE ACCESS PATH
  -----------------------------------------
  BEGIN Single Table Cardinality Estimation
  -----------------------------------------
  Table: TEST  Alias: TEST
    Card: Original: 53773  Rounded: 53773  Computed: 53773.00  Non Adjusted: 53773.00
  -----------------------------------------
  END   Single Table Cardinality Estimation
  -----------------------------------------
  Access Path: TableScan
    Cost:  459.51  Resp: 459.51  Degree: 0
      Cost_io: 392.00  Cost_cpu: 18270051
      Resp_io: 392.00  Resp_cpu: 18270051
  Best:: AccessPath: TableScan
         Cost: 459.51  Degree: 1  Resp: 459.51  Card: 53773.00  Bytes: 0
***************************************
OPTIMIZER STATISTICS AND COMPUTATIONS
***************************************
GENERAL PLANS
***************************************
Considering cardinality-based initial join order.
Permutations for Starting Table :0
***********************
Join order[1]:  TEST[TEST]#0
***********************
Best so far: Table#: 0  cost: 459.5053  card: 53773.0000  bytes: 1290552
(newjo-stop-1) k:0, spcnt:0, perm:1, maxperm:80000
*********************************
Number of join permutations tried: 1
*********************************
Final - All Rows Plan:  Best join order: 1
  Cost: 459.5053  Degree: 1  Card: 53773.0000  Bytes: 1290552
  Resc: 459.5053  Resc_io: 392.0000  Resc_cpu: 18270051
  Resp: 459.5053  Resp_io: 392.0000  Resc_cpu: 18270051
kkoipt: Query block SEL$1 (#0)
******* UNPARSED QUERY IS *******
SELECT MAX("TEST"."OBJECT_NAME") "MAX(OBJECT_NAME)" FROM "SA"."TEST" "TEST"
kkoqbc-subheap (delete addr=ffffffff7cf18940, in-use=11424, alloc=11872)
kkoqbc-end
          : call(in-use=7936, alloc=32712), compile(in-use=35976, alloc=36536)
apadrv-end: call(in-use=7936, alloc=32712), compile(in-use=36760, alloc=40552)

sql_id=1rq6zdmdax2c0.
Current SQL statement for this session:
explain plan for select max(object_name) from test

============
Plan Table
============
----------------------------------------------+-----------------------------------+
| Id  | Operation                   | Name    | Rows  | Bytes | Cost  | Time      |
----------------------------------------------+-----------------------------------+
| 0   | SELECT STATEMENT            |         |       |       |   460 |           |
| 1   |  SORT AGGREGATE             |         |     1 |    24 |       |           |
| 2   |   INDEX FULL SCAN (MIN/MAX) | IDX     |   53K | 1260K |       |           |
----------------------------------------------+-----------------------------------+
Predicate Information:
----------------------

We can see that 460 is the cost of full table scan. And declarated best access path is also TableScan. However as a result access path is INDEX FULL SCAN (MIN/MAX).

I suggest that hint is in “notes” section of runtime execution plan:

---------------------------------------------------------------------------------------------
| Id  | Operation                  | Name | Starts | E-Rows | A-Rows |   A-Time   | Buffers |
---------------------------------------------------------------------------------------------
|   1 |  SORT AGGREGATE            |      |      1 |      1 |      1 |00:00:00.01 |       3 |
|   2 |   INDEX FULL SCAN (MIN/MAX)| IDX  |      1 |  53773 |      1 |00:00:00.01 |       3 |
---------------------------------------------------------------------------------------------
Note
-----
   - rule based optimizer used (consider using cbo)

Pay attention “rule based optimizer used”. Looks like the bug 8467123 or 8323407.
Seems some exception is caused during CBO optimization and Oracle switches to RBO although cost also present in “explained” plan.

Checked in versions 10.2.0.4, 10.2.0.5 – reproduced. 11.1.0.7 – not (partially, see update below. For IOT reproduced in 11.1, 11.2).
Thus, this bug could be considered as not actual, but may shed light on internals of IRS.

Let’s create a table with 100 rows, n = 1..100 and simple non-deterministic function.

SQL> create table test as select rownum n,
  2                              rownum m,
  3                              'n# ' || rownum rown
  4                         from dual
  5                      connect by level <= 100 
  6  / 
Table created 

SQL> create index idx on test(n,m) -- not unique index
  2  /

Index created

SQL> create or replace function f  return integer
  2  as
  3    n integer;
  4  begin
  5    n := dbms_random.VALUE(1, 100);
  6    dbms_output.put_line('function f called. result = ' || n);
  7    return n;
  8  end;
  9  /

Function created

How many times function f will be executed in the query below?

SQL> explain plan for
  2  select n,
  3         m,
  4         rown
  5    from test
  6   where n = f
  7  /

Explained

SQL> select * from table(dbms_xplan.display(null,null,'basic +predicate'));

PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------
Plan hash value: 4092295894
--------------------------------------------
| Id  | Operation                   | Name |
--------------------------------------------
|   0 | SELECT STATEMENT            |      |
|   1 |  TABLE ACCESS BY INDEX ROWID| TEST |
|*  2 |   INDEX RANGE SCAN          | IDX  |
--------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
   2 - access("N"="F"())

Let’s check it.

SQL> begin
  2    dbms_random.seed(2); -- 2 is just a suitable number to reproduce tests
  3  end;
  4  /

PL/SQL procedure successfully completed

SQL> select n,
  2         m,
  3         rown
  4    from test
  5   where n = f;

         N          M ROWN
---------- ---------- -------------------------------------------

function f called. result = 10
function f called. result = 68

Function f was executed twice and select has not returned anything.

One more attempt:

SQL> select n,
  2         m,
  3         rown
  4    from test
  5   where n = f;

         N          M ROWN
---------- ---------- -------------------------------------------
         9          9 n# 9
         9         10 n# 10
         9         11 n# 11
         9         12 n# 12
         9         13 n# 13

function f called. result = 13
function f called. result = 9

The function has been executed twice again and five rows have been returned.
Seems Oracle executes function the first time to determine the right border (13 in our case) of range and the second for the left border (9 in our case). As if “equal” would converted in “between”.
Returned values (except of column N) correspond with range. Column N which has exactly been in condition with function is the same as the last execution of function.

UPDATE 27.03.2011
Looks like the problem has been fixed in 11g for normal indexes, but still exists for IOT in particular.
executed in 11.1.0.7 and 11.2.0.2:

SQL> create table test_iot (n,m,rown, primary key(n,m)) organization index
  2                     as select rownum n,
  3                               rownum m,
  4                               'n# ' || rownum rown
  5                          from dual
  6                       connect by level <= 100
  7  /
 
Table created

SQL> begin
  2    dbms_random.seed(2); -- just a suitable number to reproduce tests
  3  end;
  4  /
 
PL/SQL procedure successfully completed

SQL> select n,
  2         m,
  3         rown
  4    from test_iot
  5   where n = f;
 
         N          M ROWN
---------- ---------- -------------------------------------------
 
function f called. result = 10
function f called. result = 68

SQL> select n,
  2         m,
  3         rown
  4    from test_iot
  5   where n = f;
 
         N          M ROWN
---------- ---------- -------------------------------------------
         9          9 n# 9
        10         10 n# 10
        11         11 n# 11
        12         12 n# 12
        13         13 n# 13
 
function f called. result = 13
function f called. result = 9

Just a couple links with good explanation of this event from Miladin Modrakovic and Tanel Poder.
http://oraclue.com/2009/03/24/oracle-event-sql_trace-in-11g/
http://blog.tanelpoder.com/2010/06/23/the-full-power-of-oracles-diagnostic-events-part-2-oradebug-doc-and-11g-improvements

Below is a simple example.

SQL> create table test as select * from all_objects where 1=0;

Table created

Executed in 0,344 seconds

SQL> create index idx on test(owner, object_name);

Index created

SQL> insert into test select * from all_objects;

53779 rows inserted

SQL> delete from test;

53779 rows deleted

SQL> commit;

Commit complete

> select * from test where owner='SYS';
no rows selected

------------------------------------------------------------------------
| Id  | Operation                   | Name | Starts | A-Rows | Buffers |
------------------------------------------------------------------------
|   1 |  TABLE ACCESS BY INDEX ROWID| TEST |      1 |      0 |     348 |
|*  2 |   INDEX RANGE SCAN          | IDX  |      1 |      0 |     348 |
------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------
   2 - access("OWNER"='SYS')

Pay attention, 348 logical reads during index range scan which does not found any rows.
This especially actual for the tables whose lifecycle consists regular inserting and deleting of rows. E.g. the AQ tables.

One of option to determine how many deleted entries consists an index is to use the statement:

analyze index  validate structure;
select lf_rows, del_lf_rows from index_stats;

In our example

SQL> analyze index idx validate structure;

Index analyzed

SQL> select lf_rows, del_lf_rows from index_stats;

   LF_ROWS DEL_LF_ROWS
---------- -----------
     40599       40599

Thus, our index consists of 40599 leaf rows and all of them are deleted.

Let try to rebuild index and execute the same query

> select * from test where owner='SYS';

no rows selected

------------------------------------------------------------------------
| Id  | Operation                   | Name | Starts | A-Rows | Buffers |
------------------------------------------------------------------------
|   1 |  TABLE ACCESS BY INDEX ROWID| TEST |      1 |      0 |       1 |
|*  2 |   INDEX RANGE SCAN          | IDX  |      1 |      0 |       1 |
------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------
   2 - access("OWNER"='SYS')

Now only 1 logical read.

Update 26.02.2011:
The point of this post is not crazy idea to always rebuild indexes.
Just pay attention when Index (Fast) Full Scan on almost empty table or Index Range Scan without filter predicates return a few rows and does hundreds or thouthands logical reads.
Sometimes myth about degraded indexes is not a myth, and can lead to significant overhead during index scans.

There is data lifecycle pattern which I often meet. There is a table (either heap or IOT) which used for regular inserting and deleting (FIFO/queue like AQ). Normally enqueued/dequeued a little number of rows. And there are periods (or was one period in the past) when a lot amount of data is inserted without dequeuing. For example, when dequeueing is temporary disabled or all enqueuing is perfromed in one transaction. Obviously, after dequeuing will be enabled and rows will be dequeued/deleted index will consists a lot of “empty” leaf blocks.

Below is an example from one production OLTP database. This is the query which executed inside dbms_aq.dequeue:

select tab.row_id,
       tab.msgid,
       tab.corrid,
       tab.priority,
       tab.delay,
       tab.expiration,
       tab.retry_count,
       tab.exception_qschema,
       tab.exception_queue,
       tab.chain_no,
       tab.local_order_no,
       tab.enq_time,
       tab.time_manager_info,
       tab.state,
       tab.enq_tid,
       tab.step_no,
       tab.sender_name,
       tab.sender_address,
       tab.sender_protocol,
       tab.dequeue_msgid,
       tab.user_prop,
       tab.user_data
  from AQ$_SOMEAQTAB_F tab
 where q_name = :1
   and (state = :2)

---------------------------------------------------------------------------------------------------------
| Id  | Operation                   | Name                     | Starts | A-Rows |   A-Time   | Buffers |
---------------------------------------------------------------------------------------------------------
|   1 |  TABLE ACCESS BY INDEX ROWID| SOMEAQTAB                |      1 |      1 |00:00:00.15 |   19959 |
|*  2 |   INDEX RANGE SCAN          | AQ$_SOMEAQTAB_I          |      1 |      1 |00:00:00.15 |   19958 |
---------------------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
   2 - access("QT"."Q_NAME"=:1 AND "QT"."STATE"=:2)

Notice, 20K logical reads during index range scan which has only access predicates and return 1 row to parent operation.

The index consists thouthands of empty (rrow=0) index leaf blocks
treedump:

----- begin tree dump
branch: 0x405e912 67496210 (0: nrow: 14, level: 3)
   branch: 0x32067894 839284884 (-1: nrow: 37, level: 2)
      branch: 0x6ecbd82f 1858852911 (-1: nrow: 26, level: 1)
         leaf: 0x5363dd92 1399053714 (-1: nrow: 28 rrow: 0)
         leaf: 0x7f472d2a 2135371050 (0: nrow: 20 rrow: 0)
         leaf: 0x5363dd91 1399053713 (1: nrow: 0 rrow: 0)
         leaf: 0x5363dd94 1399053716 (2: nrow: 29 rrow: 0)
         leaf: 0x5363dd93 1399053715 (3: nrow: 30 rrow: 0)
         leaf: 0x5363db51 1399053137 (4: nrow: 10 rrow: 0)
         leaf: 0x5363db52 1399053138 (5: nrow: 0 rrow: 0)
         leaf: 0x5363db54 1399053140 (6: nrow: 0 rrow: 0)
         leaf: 0x5363db53 1399053139 (7: nrow: 30 rrow: 0)
         leaf: 0x5363db57 1399053143 (8: nrow: 31 rrow: 0)
         leaf: 0x5363db58 1399053144 (9: nrow: 27 rrow: 0)
         leaf: 0x5363db71 1399053169 (10: nrow: 6 rrow: 0)
         leaf: 0x5363db7a 1399053178 (11: nrow: 0 rrow: 0)
         leaf: 0x5363db83 1399053187 (12: nrow: 26 rrow: 0)
         leaf: 0x5363db8d 1399053197 (13: nrow: 28 rrow: 0)
         leaf: 0x6ecbd818 1858852888 (14: nrow: 31 rrow: 0)
         leaf: 0x6ecbd81e 1858852894 (15: nrow: 31 rrow: 0)
         leaf: 0x6ecbd825 1858852901 (16: nrow: 31 rrow: 0)
         leaf: 0x6ecbd830 1858852912 (17: nrow: 31 rrow: 0)
         leaf: 0x6ecbd674 1858852468 (18: nrow: 31 rrow: 0)
         leaf: 0x6ecbd67f 1858852479 (19: nrow: 29 rrow: 0)
         leaf: 0x6ecbd688 1858852488 (20: nrow: 29 rrow: 0)
         leaf: 0x6ecbd68f 1858852495 (21: nrow: 30 rrow: 0)
         leaf: 0x5363db1b 1399053083 (22: nrow: 28 rrow: 0)
         leaf: 0x5363db21 1399053089 (23: nrow: 31 rrow: 0)
         leaf: 0x5363db2e 1399053102 (24: nrow: 30 rrow: 0)
      branch: 0x6ecbd3bc 1858851772 (0: nrow: 48, level: 1)
         leaf: 0x5363db49 1399053129 (-1: nrow: 31 rrow: 0)
         leaf: 0x6ecbd618 1858852376 (0: nrow: 0 rrow: 0)
         leaf: 0x6ecbd628 1858852392 (1: nrow: 31 rrow: 0)
         leaf: 0x6ecbd62f 1858852399 (2: nrow: 8 rrow: 0)
         leaf: 0x6ecbd634 1858852404 (3: nrow: 31 rrow: 0)
         ...
         ...

The query had gotten from an OLTP database where it executed a few times in second!

p.s.
Useful presentation about index internals from Richard Foote:
http://richardfoote.files.wordpress.com/2007/12/index-internals-rebuilding-the-truth-ii.pdf

Update 03.03.2011
Note 271855.1

1. Estimation of cardinality can depends on size (in blocks) of a segment.
First, I will create table with two partitions with different size.

-- Creation of the table
SQL>
  2  create table test
  3  ( state    varchar2(10)  not null,
  4    val      number(4)     not null
  5  )
  6  partition by list (state)
  7  (
  8    partition p1 values ('Open'),
  9    partition p2 values ('Closed')
 10  );

Table created

-- Populating of the table
SQL>
  2
  3  insert into test
  4      select 'Open',
  5             decode(mod(rownum, 10), 0, 0, 1)
  6        from dual
  7     connect by level <= 10000;   10000 rows inserted SQL>
  2  insert into test
  3      select 'Closed',
  4             100 + mod(rownum, 10)
  5        from dual
  6     connect by level <= 90000;   

90000 rows inserted 

SQL> commit;

Commit complete

SQL>
  2  begin
  3      dbms_stats.gather_table_stats(user,
  4                                    'test',
  5                                    cascade          => true,
  6                                    granularity      => 'ALL',
  7                                    estimate_percent => 100,
  8                                    method_opt       => 'for all columns size 10'
  9                                    );
 10  end;
 11  /

PL/SQL procedure successfully completed

At this point we have a table with two partitions – P1 and P2 with gathered histograms on all coumns. The partition P1 consists of 1000 rows with column VAL = 0 and 9000 rows with VAL = 1.
Let’s try to see estimation of cardinality

SQL>
  2  explain plan for
  3  SELECT t.*
  4    FROM test t
  5   WHERE t.state = 'Open'
  6     AND t.val = 1;

Explained

SQL> select * from table(dbms_xplan.display);

----------------------------------------------------------------------------------------------
| Id  | Operation             | Name | Rows  | Bytes | Cost (%CPU)| Time     | Pstart| Pstop |
----------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT      |      |  8999 | 62993 |    23  (48)| 00:00:01 |       |       |
|   1 |  PARTITION LIST SINGLE|      |  8999 | 62993 |    23  (48)| 00:00:01 |   KEY |   KEY |
|*  2 |   TABLE ACCESS FULL   | TEST |  8999 | 62993 |    23  (48)| 00:00:01 |     1 |     1 |
----------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
   2 - filter("T"."VAL"=1)

Oracle correctly estimates cardinality = 8999 (only 1 was lost during rounding).
In this case cardinality of FTS calculated as
selectivity(state = ‘Open’) * selectivity(val = 1) * num_rows (all from P1)
Selectivities are calculated on the basis of histograms.

Let’s create a local index and look at the plan of the same query.

SQL> create index testidx on test(val) local;

Index created

SQL>
  2  begin
  3      dbms_stats.gather_index_stats(user,
  4                                    'testidx',
  5                                    granularity      => 'ALL',
  6                                    estimate_percent => 100
  7                                    );
  8  end;
  9  /

PL/SQL procedure successfully completed

SQL>
  2  explain plan for
  3  SELECT --+ index(t)
  4         t.*
  5    FROM test t
  6   WHERE t.state = 'Open'
  7     AND t.val = 1;

Explained

SQL> select * from table(dbms_xplan.display);

---------------------------------------------------------------------------------------------------
| Id  | Operation                          | Name    | Rows  | Bytes | Cost (%CPU)| Pstart| Pstop |
---------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                   |         |  8999 | 62993 |   119  (14)|       |       |
|   1 |  PARTITION LIST SINGLE             |         |  8999 | 62993 |   119  (14)|   KEY |   KEY |
|   2 |   TABLE ACCESS BY LOCAL INDEX ROWID| TEST    |  8999 | 62993 |   119  (14)|     1 |     1 |
|*  3 |    INDEX RANGE SCAN                | TESTIDX |   818 |       |    43  (17)|     1 |     1 |
---------------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
   3 - access("T"."VAL"=1)

Cardinality of INDEX RANGE SCAN is 818. Trace 10053 does not contain any info about how this value is calculated.

BASE STATISTICAL INFORMATION
***********************
Table Stats::
  Table: TEST  Alias:  T  Partition [0]
    #Rows: 10000  #Blks:  40  AvgRowLen:  7.00
    #Rows: 10000  #Blks:  40  AvgRowLen:  7.00
Index Stats::
  Index: TESTIDX  Col#: 2  PARTITION [0]
    LVLS: 1  #LB: 40  #DK: 2  LB/K: 20.00  DB/K: 37.00  CLUF: 74.00
    LVLS: 1  #LB: 40  #DK: 2  LB/K: 20.00  DB/K: 37.00  CLUF: 74.00
    User hint to use this index
***************************************
SINGLE TABLE ACCESS PATH
  -----------------------------------------
  BEGIN Single Table Cardinality Estimation
  -----------------------------------------
  Column (#1): STATE(VARCHAR2)  Part#: 0
    AvgLen: 5.00 NDV: 1 Nulls: 0 Density: 5.0000e-05
    Histogram: Freq  #Bkts: 1  UncompBkts: 10000  EndPtVals: 1
  Column (#1): STATE(VARCHAR2)
    AvgLen: 5.00 NDV: 1 Nulls: 0 Density: 5.0000e-05
    Histogram: Freq  #Bkts: 1  UncompBkts: 10000  EndPtVals: 1
  Column (#2): VAL(NUMBER)  Part#: 0
    AvgLen: 3.00 NDV: 2 Nulls: 0 Density: 0.05 Min: 0 Max: 1
    Histogram: Freq  #Bkts: 2  UncompBkts: 10000  EndPtVals: 2
  Column (#2): VAL(NUMBER)
    AvgLen: 3.00 NDV: 2 Nulls: 0 Density: 0.05 Min: 0 Max: 1
    Histogram: Freq  #Bkts: 2  UncompBkts: 10000  EndPtVals: 2
  Table: TEST  Alias: T
    Card: Original: 10000  Rounded: 8999  Computed: 8999.05  Non Adjusted: 8999.05
  -----------------------------------------
  END   Single Table Cardinality Estimation
  -----------------------------------------
  Access Path: index (AllEqRange)
    Index: TESTIDX
    resc_io: 103.00  resc_cpu: 4291511
    ix_sel: 0.89995  ix_sel_with_filters: 0.89995
    Cost: 118.86  Resp: 118.86  Degree: 1
  Best:: AccessPath: IndexRange  Index: TESTIDX
         Cost: 118.86  Degree: 1  Resp: 118.86  Card: 8999.05  Bytes: 0
***************************************
OPTIMIZER STATISTICS AND COMPUTATIONS
***************************************
GENERAL PLANS
***************************************
Considering cardinality-based initial join order.
Permutations for Starting Table :0
***********************
Join order[1]:  TEST[T]#0
***********************
Best so far: Table#: 0  cost: 118.8565  card: 8999.0500  bytes: 62993
(newjo-stop-1) k:0, spcnt:0, perm:1, maxperm:80000
*********************************
Number of join permutations tried: 1
*********************************
Final - All Rows Plan:  Best join order: 1
  Cost: 118.8565  Degree: 1  Card: 8999.0000  Bytes: 62993
  Resc: 118.8565  Resc_io: 103.0000  Resc_cpu: 4291511
  Resp: 118.8565  Resp_io: 103.0000  Resc_cpu: 4291511
kkoipt: Query block SEL$1 (#0)
******* UNPARSED QUERY IS *******
SELECT /*+ INDEX ("T") */ "T"."STATE" "STATE","T"."VAL" "VAL" FROM "SA"."TEST" "T" WHERE "T"."VAL"=1
kkoqbc-subheap (delete addr=ffffffff7cf189b8, in-use=12592, alloc=16040)
kkoqbc-end
          : call(in-use=20992, alloc=49080), compile(in-use=41208, alloc=44568)
apadrv-end: call(in-use=20992, alloc=49080), compile(in-use=42008, alloc=44568)

sql_id=7vvtk89y1v5zb.
Current SQL statement for this session:
explain plan for
SELECT --+ index(t)
       t.*
  FROM test t
 WHERE t.state = 'Open'
   AND t.val = 1

============
Plan Table
============
------------------------------------------------------+-----------------------+---------------+
| Id  | Operation                           | Name    | Rows  | Bytes | Cost  | Pstart| Pstop |
------------------------------------------------------+-----------------------+---------------+
| 0   | SELECT STATEMENT                    |         |       |       |   119 |       |       |
| 1   |  PARTITION LIST SINGLE              |         |  8999 |   62K |   119 | KEY   | KEY   |
| 2   |   TABLE ACCESS BY LOCAL INDEX ROWID | TEST    |  8999 |   62K |   119 | 1     | 1     |
| 3   |    INDEX RANGE SCAN                 | TESTIDX |   818 |       |    43 | 1     | 1     |
------------------------------------------------------+-----------------------+---------------+
Predicate Information:
----------------------
3 - access("T"."VAL"=1)

In fact Oracle corrects cardinality of INDEX RANGE SCAN by proportion of numblocks(P1) in numblocks(table).

Cardinality in this case calculated as:
Cardinality = estimated cardinality multiplied by numblocks(P1)/numblocks(table)

SQL> select partition_name,
  2         blocks
  3    from dba_tab_statistics s
  4   where table_name = 'TEST'
  5     and (partition_name is null or partition_name = 'P1')
  6  ;

PARTITION_NAME                     BLOCKS
------------------------------ ----------
P1                                     40
                                      440

Thus, cardinality of IRS = 8999 * 40/440 = 818

It is strange, especially with gathered histograms. In fact figures from histograms gathered inside partitions is enough in this case.
(It is important to note, if column val would be “nullable” this effect disappears).
It is the first.

And the second, notice, that step 2 “TABLE ACCESS BY LOCAL INDEX ROWID” has right cardinality and cost.
It, as expected, calculated as
blevel + (leaf_blocks + cluf) * selectivity + cpu_cost/(cpuspeed*sreadtim*1000) = 1 + (40 + 74)*0.89995 + cpu_cost/(cpuspeed*sreadtim*1000) = 119
(I’ve ommitted some minor details)
Looks like that wrong cardinality of IRS is not a big problem, because parent step has right figures.

The script is used in this part:

drop table test;

-- Creation of the table
create table test
( state    varchar2(10)  not null,
  val      number(4)     not null
)
partition by list (state)
(
  partition p1 values ('Open'),
  partition p2 values ('Closed')
);


insert into test
    select 'Open',
           decode(mod(rownum, 10), 0, 0, 1)
      from dual 
   connect by level <= 10000;

insert into test
    select 'Closed',
           100 + mod(rownum, 10)
      from dual 
   connect by level <= 90000;

commit;

begin
    dbms_stats.gather_table_stats(user, 
                                  'test', 
                                  cascade          => true, 
                                  granularity      => 'ALL', 
                                  estimate_percent => 100,
                                  method_opt       => 'for all columns size 10'
                                  ); 
end;
/

explain plan for
SELECT t.*
  FROM test t
 WHERE t.state = 'Open'
   AND t.val = 1;

select * from table(dbms_xplan.display);

-- Let’s create a local index and look at the plan of the same query.
create index testidx on test(val) local;

begin 
    dbms_stats.gather_index_stats(user, 
                                  'testidx', 
                                  granularity      => 'ALL', 
                                  estimate_percent => 100
                                  ); 
end;
/

explain plan for
SELECT --+ index(t)
       t.*
  FROM test t
 WHERE t.state = 'Open'
   AND t.val = 1;

select * from table(dbms_xplan.display);

Two little additional points:
2. An oddity with Index Fast Full Scan when table access is not required
What if we change the query to avoid the table lookup and to scan only the index?
as this

    SELECT count(*)
      FROM test t
     WHERE t.state = 'Open'
       AND t.val = 1;

Let’s try to force Oracle to use Index Fast Full Scan:

SQL> explain plan for
  2      SELECT --+ index_ffs(t testidx)
  3             count(*)
  4        FROM test t
  5       WHERE t.state = 'Open'
  6         AND t.val = 1;
 
Explained

SQL> select * from table(dbms_xplan.display);

----------------------------------------------------------------------------------------------
| Id  | Operation             | Name | Rows  | Bytes | Cost (%CPU)| Time     | Pstart| Pstop |
----------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT      |      |  8999 | 62993 |    23  (48)| 00:00:01 |       |       |
|   1 |  PARTITION LIST SINGLE|      |  8999 | 62993 |    23  (48)| 00:00:01 |   KEY |   KEY |
|*  2 |   TABLE ACCESS FULL   | TEST |  8999 | 62993 |    23  (48)| 00:00:01 |     1 |     1 |
----------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
   2 - filter("T"."VAL"=1)

3. An oddity with the cost of the statement
Fortunately it is enough smart to use Index Range Scan here, for the same query as above, without table access.
From examples above we can expect cost of TABLE ACCESS FULL is 23 and the cost of INDEX RANGE SCAN is 43 for the following query:

    SELECT count(*)
      FROM test t
     WHERE t.state = 'Open'
       AND t.val = 1;

SQL> declare
  2    i integer;
  3  begin
  4
  5    dbms_stats.set_table_stats(user, 'TEST', 'P1', numblks => 200);
  6
  7  end;
  8  /

PL/SQL procedure successfully completed

SQL> explain plan for
  2  SELECT count(*)
  3    FROM test t
  4   WHERE t.state = 'Open'
  5     AND t.val = 1;

Explained

SQL> select * from table(dbms_xplan.display);

------------------------------------------------------------------------------------
| Id  | Operation              | Name | Rows  | Bytes | Cost (%CPU)| Pstart| Pstop |
------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT       |      |     1 |     7 |     65  (0)|       |       |
|   1 |  SORT AGGREGATE        |      |     1 |     7 |            |       |       |
|   2 |   PARTITION LIST SINGLE|      |  8999 | 62993 |     65  (0)|   KEY |   KEY |
|*  3 |    TABLE ACCESS FULL   | TEST |  8999 | 62993 |     65  (0)|     1 |     1 |
------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
   3 - filter("T"."VAL"=1)

Let’s try to force Oracle use index:

SQL> explain plan for
  2  SELECT --+ index(t)
  3         count(*)
  4    FROM test t
  5   WHERE t.state = 'Open'
  6     AND t.val = 1;

Explained

SQL> select * from table(dbms_xplan.display);

---------------------------------------------------------------------------------------
| Id  | Operation              | Name    | Rows  | Bytes | Cost (%CPU)| Pstart| Pstop |
---------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT       |         |     1 |     7 |   119   (1)|       |       |
|   1 |  SORT AGGREGATE        |         |     1 |     7 |            |       |       |
|   2 |   PARTITION LIST SINGLE|         |  8999 | 62993 |    43   (0)|   KEY |   KEY |
|*  3 |    INDEX RANGE SCAN    | TESTIDX |  8999 | 62993 |    43   (0)|     1 |     1 |
---------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
   3 - access("T"."VAL"=1)

Personally I consider this as a bug. Oracle uses CLUF in the estimations for a plan without TABLE ACCESS BY INDEX ROWID, it is absolutely wrong.

SQL> create table all_obj as
  2    select rownum id,
  3           rownum n
  4      from all_objects
  5     where rownum <= 10000;
 
Table created

SQL> create index idx on all_obj(n);
 
Index created

SQL> explain plan for
  2    select *
  3      from all_obj
  4     where n = :1;
 
Explained

SQL> select * from table(dbms_xplan.display);
 
PLAN_TABLE_OUTPUT
-------------------------------------------------------
| Id  | Operation                   | Name    | Rows  |
-------------------------------------------------------
|   0 | SELECT STATEMENT            |         |   100 |
|   1 |  TABLE ACCESS BY INDEX ROWID| ALL_OBJ |   100 |
|*  2 |   INDEX RANGE SCAN          | IDX     |    40 |
-------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
   2 - access("N"=TO_NUMBER(:1))
Note
-----
   - dynamic sampling used for this statement
 

There are two questions:
1. Cardinality of INDEX RANGE SCAN less(!) than TABLE ACCESS BY INDEX ROWID
2. How cardinality of INDEX RANGE SCAN is calculated

The answer and other usefull CBO defaults were found here:
http://www.mail-archive.com/oracle-l@fatcity.com/msg24731.html

=========================================================
/* defaults */

/* 
Default selectivities are set low to
1. keep cost values low for future resource limiter use
2. keep cost values low for permutation cutoff in kko
Defaults are used for bind variables, general expressions and
unanalyzed tables, except for equality where defaults are not
needed for bind variables.
*/

#define KKEDSREL 0.05 /* default selectivity for < <= > >= */
#define KKEDSEQ 0.01 /* default selectivity for = */
#define KKEDSNE 0.05 /* default selectivity for != */
#define KKEDSDF 0.05 /* default selectivity for all other ops */
#define KKEDSIRL 0.009 /* default selectivity for relation on indexed col */
#define KKEDSBRL 0.009 /* def sel for relation with bind var on index col*/
#define KKEDSIEQ 0.004 /* default selectivity for = on indexed col */
#define KKEDMBR 8 /* default multiblock read factor */
#define KKEDMBW 8 /* default multiblock write factor */
#define KKEDFNR 100.0 /* default - fixed table cardinality */
#define KKEDFRL 20 /* default - fixed table row length */
#define KKEDDNR 2000.0 /* default - remote table cardinality */
#define KKEDDRL 100 /* default - remote table avg row length */
#define KKEDDNB 100 /* default - default # of blocks */
#define KKEDDSC 13.0 /* default - default scan cost */
#define KKEDILV 1 /* default - default index levels */
#define KKEDILB 25 /* default - number of index leaf blocks */
#define KKEDLBK 1 /* default - number leaf blocks/key */
#define KKEDDBK 1 /* default - number of data blocks/key */
#define KKEDKEY 100 /* default - number of distinct keys */
#define KKEDCLF (KKEDDNB*8) /* default - clustering factor */
#define KKECRI 1.5 /* remote table access cost increase factor */
#define KKECFSC 1.0 /* fixed table scan cost */
#define KKECFNB 0 /* fixed table number of blocks */
#define KKECMXB 15 /* maximum byte length for normalization */
#define KKECBBS 256.0 /* base for byte sequence normalization */
#define KKECSPC ' ' /* space byte value */
#define KKECSPD 86400.0 /* seconds per day */
#define KKESROH 10.0 /* sort per row overhead in bytes */
#define KKESAUT 0.75 /* sort area utilization */
#define KKESROP 0.10 /* sort row overhead percent */
#define KKESRML 2.0 /* sort run multiple */
#define KKESTP 0x01 /* single table predicate */
#define KKETEQ 0x02 /* equi join */
#define KKETBCPJ 0x04 /* Cartesian product join */
#define KKESOK 0x08 /* input swap ok */
#define KKESWP 0x10 /* inputs swapped */
#define KKEEQP 0x20 /* equipartitioned */
#define KKELKNWC 0x01 /* LIKE no wild card */
#define KKELKTWC 0x02 /* LIKE trailing wild card */
#define KKELKEWC 0x04 /* LIKE embedded wild card */
#define KKELKLWC 0x08 /* LIKE leading wild card */
#define KKELKOWC 0x10 /* LIKE only wild card */
==================================================================

Oracle uses different constants for estimation of default selectivity of a table and an index range scan:

#define KKEDSEQ 0.01 /* default selectivity for = */
#define KKEDSIEQ 0.004 /* default selectivity for = on indexed col */

-------------------------------------------------------
| Id  | Operation                   | Name    | Rows  |
-------------------------------------------------------
|   0 | SELECT STATEMENT            |         |   100 |
|   1 |  TABLE ACCESS BY INDEX ROWID| ALL_OBJ |   100 |
|*  2 |   INDEX RANGE SCAN          | IDX     |    40 |
-------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
   2 - access("N"=TO_NUMBER(:1))

10000 is number of rows in the table getting during dynamic sampling.