I’m not totally surprised that /*+ precompute subquery */ should produce contradictory results – especially when it appears in a cursor that’s pinned by the pl/sql cursor cache. Strangely, though, my results are different from yours despite running your test on 11.2.0.3.

I get 0 as the first result, then 1 for the next 9 results, before getting 10 – 19. The 10053 trace shows that I re-optimise the hinted SQL, getting two different plans (although the first one disappears from the library cache very promptly). The first plan is:

---------------------------------------+-----------------------------------+
| Id  | Operation            | Name    | Rows  | Bytes | Cost  | Time      |
---------------------------------------+-----------------------------------+
| 0   | SELECT STATEMENT     |         |       |       |     1 |           |
| 1   |  SORT AGGREGATE      |         |     1 |       |       |           |
| 2   |   FILTER             |         |       |       |       |           |
| 3   |    TABLE ACCESS FULL | T0001   |     1 |       |     2 |  00:00:01 |
---------------------------------------+-----------------------------------+
Predicate Information:
----------------------
2 - filter(NULL IS NOT NULL)

The second plan, that appears after two inserts is:

--------------------------------------+-----------------------------------+
| Id  | Operation           | Name    | Rows  | Bytes | Cost  | Time      |
--------------------------------------+-----------------------------------+
| 0   | SELECT STATEMENT    |         |       |       |     2 |           |
| 1   |  SORT AGGREGATE     |         |     1 |    13 |       |           |
| 2   |   TABLE ACCESS FULL | T0001   |     1 |    13 |     2 |  00:00:01 |
--------------------------------------+-----------------------------------+
Predicate Information:
----------------------
2 - filter("ID"=1)

Possibly we have some differences in dynamic sampling or cardinality feedback settings.

[oracle@SB1 ~]$ sqlplus / as sysdba

SQL*Plus: Release 11.2.0.3.0 Production on Sat Dec 29 02:20:02 2012

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


Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
With the Partitioning and Data Mining options

SQL> @sql
SQL> drop table t0001 purge;

Table dropped.

SQL> create table t0001 (id number);

Table created.

SQL> declare
  2    c number;
  3  begin
  4    for i in 1 .. 10 loop
  5      select count(*) into c from t0001 where id in (select /*+ PRECOMPUTE_SUBQUERY */ * from t0001);
  6      dbms_output.put_line(c);
  7      insert into t0001 values (1);
  8      commit;
  9    end loop;
 10    for i in 1 .. 10 loop
 11      select count(*) into c from t0001 where id in (select * from t0001);
 12      dbms_output.put_line(c);
 13      insert into t0001 values (1);
 14      commit;
 15    end loop;
 16  end;
 17  /
0
0
0
0
0
0
0
0
0
0
10
11
12
13
14
15
16
17
18
19

PL/SQL procedure successfully completed.

Thanks for the update.

drop table aaa;
create table aaa (n number, state char(1), s char(300), snew char(1) GENERATED ALWAYS AS (NVL(state,'N')) VIRTUAL);
create index aaa_i on aaa(snew);

insert into aaa(n,state,s) values(1,null,'row 1');
insert into aaa(n,state,s) values(2,null,'row 2');
commit;

Column “snew” is new virtual column with index.
I did the same locking scenario as in my previous example:

-- SESSION1:
select /*+ INDEX(aaa) */ n from aaa where NVL(state,'N') = 'N' and rownum<=1 for update;
-- SESSION2:
select /*+ INDEX(aaa) */ n from aaa where NVL(state,'N') = 'N' and rownum<=1 for update;
-- SESSION1:
update aaa set state='Y' where n=1;
commit;

In each scenario, I used different “select for update” command. They are here, together with their results:

-- scen 1
select /*+ INDEX(aaa) */ n            from aaa where NVL(state,'N') = 'N' and rownum<=1 for update;
-- result is: row 1

-- scen 2
select /*+ INDEX(aaa) */ n,state      from aaa where NVL(state,'N') = 'N' and rownum<=1 for update;
-- result is: row 2

-- scen 3
select /*+ INDEX(aaa) */ n            from aaa where snew = 'N'           and rownum<=1 for update;
-- result is: row 1

-- scen 4
select /*+ INDEX(aaa) */ n,snew       from aaa where snew = 'N'           and rownum<=1 for update;
-- result is: row 1

-- scen 5
select /*+ INDEX(aaa) */ n,snew,state from aaa where snew = 'N'           and rownum<=1 for update;
-- result is: row 2

Scenario 1 and 2 is in fact the same as FBI usage, with the same results.
Result in scenario 5 is little surprise, because the column state is not in the where clause, but it presence in select clause cause different result.
It seems, that when Oracle is forced to read this column from table, then it’s value is used to reevaluate the where clause (directly in scenario 2 and indirectly in scenario 5 by recalculationof the virtual column value).

I don’t think it has anything to do with row updating (when size of row is increasing), nor CHOOSE/ALL_ROWS

1. we were not using CHOOSE in 9.2.0.8
2. the FBI was used in hint in our application in 9.2.0.8 (but Vladimir didn’t add hints to synthetic testcace), so CBO was used to generate execution plan even in 9.2.0.8

Sure, row will be copied to block free space and pointer in row directory will be changed. But if you drop FBI and create classic B-tree index, session 2 will select row number 2 as well.

It seems oracle forgets to restart SELECT FOR UPDATE statement in this specific situation. Statement generates less consistent and current gets as it should

Regards
Pavol Babel

That is an interesting test case. I experimented with it for a bit over an hour using Oracle Database 11.2.0.2.

* Setting the OPTIMIZER_FEATURES_ENABLE parameter at the session level in session 2 to a value of less than or equal to 9.2.0.8 results in session 2 selecting the number 2 (rather than 1):
ALTER SESSION SET OPTIMIZER_FEATURES_ENABLE=’9.2.0.8′;

* Setting the OPTIMIZER_FEATURES_ENABLE parameter back to 11.2.0.2, and changing the OPTIMIZER_MODE from the 11.2.0.2 default of ALL_ROWS to CHOOSE in session 2 results in session 2 selecting the number 2 (rather than 1):
ALTER SESSION SET OPTIMIZER_FEATURES_ENABLE=’11.2.0.2′;
ALTER SESSION SET OPTIMIZER_MODE=’CHOOSE’;

* Setting the OPTIMIZER_MODE from ALL_ROWS to CHOOSE in both sessions, results in session 1 selecting the number 1, while session 2 selects the number 2 (rather than 1).

* Collecting the table statistics using DBMS_STATS.GATHER_TABLE_STATS with OPTIMIZER_MODE set to CHOOSE results in both sessions selecting the number 1.

The execution plan with the OPTIMIZER_MODE set to CHOOSE (the same seen with OPTIMIZER_FEATURES_ENABLE=’9.2.0.8′ and no statistics for table AAA) (the RULE based optimizer cannot use function based indexes, if I recall correctly):

Plan hash value: 2311360649
 
-------------------------------------
| Id  | Operation            | Name |
-------------------------------------
|   0 | SELECT STATEMENT     |      |
|   1 |  FOR UPDATE          |      |
|   2 |   BUFFER SORT        |      |
|*  3 |    COUNT STOPKEY     |      |
|*  4 |     TABLE ACCESS FULL| AAA  |
-------------------------------------
 
Predicate Information (identified by operation id):
---------------------------------------------------
   3 - filter(ROWNUM<=1)
   4 - filter(NVL("STATE",'N')='N')
 
Note
-----
   - rule based optimizer used (consider using cbo)

The execution plan with OPTIMIZER_MODE set to ALL_ROWS:

Plan hash value: 3492588397
 
----------------------------------------------------------------------------------------
| Id  | Operation                      | Name  | Rows  | Bytes | Cost (%CPU)| Time     |
----------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT               |       |       |       |     1 (100)|          |
|   1 |  FOR UPDATE                    |       |       |       |            |          |
|   2 |   BUFFER SORT                  |       |       |       |            |          |
|*  3 |    COUNT STOPKEY               |       |       |       |            |          |
|   4 |     TABLE ACCESS BY INDEX ROWID| AAA   |     1 |    15 |     1   (0)| 00:00:01 |
|*  5 |      INDEX RANGE SCAN          | AAA_I |     1 |       |     1   (0)| 00:00:01 |
----------------------------------------------------------------------------------------
 
Predicate Information (identified by operation id):
---------------------------------------------------
   3 - filter(ROWNUM<=1)
   5 - access("AAA"."SYS_NC00004$"='N')
 
Note
-----
   - dynamic sampling used for this statement (level=2)

So, it appears that the switch of the OPTIMIZER_MODE from CHOOSE to ALL_ROWS resulted in a change of the execution plan – rather than the rows being access in index order, the rows are accessed in the order in which the rows appear in the table’s blocks.

Jonathan, could this change in which row is selected be caused by the row moving its physical location in the block because the row is now longer than before (a NULL was set to a value of ‘Y’)? I am having trouble remembering if your latest book mentioned something along the lines that if there is sufficient free space in the block, that the row could be moved within the block with only a pointer change needed, thus saving the work of relocating the other rows in that block (I could very well be incorrectly remembering this concept).

select n, state from aaa where NVL(state,'N') = 'N' and rownum<=1 for update;