Thanks for all the follow-ups and links. It’s fascinating how small variations in SQL can find different paths through the Oracle code for “no apparent reason”. I particularly like the way you’ve managed to strip the problem down to such a tiny example in the last post – have you tried sending it in as an SR to see what Oracle Corp. say about it ?

drop table t1 purge;

create table t1 as select 'X' small_vc from dual connect by level <= 2;

--alter session set events '10221 trace name context forever, level 7'; 

update  t1 set small_vc = (select max('1') from dual group by 1);
commit;
 
update  t1 set small_vc = (select max('1') from dual /*group by 1*/);
commit;

And we can find in the trace that for the first update “array update” is used, while for the second – LKR+URP.

SQL> update  t1
  2  set small_vc = (
  3          select
  4              max(small_vc)
  5          from
  6              t2
  7          where   t2.id = t1.id
  8          group by 1
  9      )
 10  where
 11      mod(id,100) = 0
 12  ;

100 rows updated.


Execution Plan
----------------------------------------------------------
Plan hash value: 3230996198

---------------------------------------------------------------------------------------
| Id  | Operation                     | Name  | Rows  | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------------------
|   0 | UPDATE STATEMENT              |       |   100 |  1500 |   351  (29)| 00:00:05 |
|   1 |  UPDATE                       | T1    |       |       |            |          |
|*  2 |   TABLE ACCESS FULL           | T1    |   100 |  1500 |    51   (0)| 00:00:01 |
|   3 |   SORT GROUP BY NOSORT        |       |     1 |    15 |     2   (0)| 00:00:01 |
|   4 |    TABLE ACCESS BY INDEX ROWID| T2    |     1 |    15 |     2   (0)| 00:00:01 |
|*  5 |     INDEX RANGE SCAN          | T2_I1 |     1 |       |     1   (0)| 00:00:01 |
---------------------------------------------------------------------------------------

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

   2 - filter(MOD("ID",100)=0)
   5 - access("T2"."ID"=:B1)

Statistics
----------------------------------------------------------
          0  recursive calls
        106  db block gets
        489  consistent gets
          0  physical reads
      34564  redo size
        682  bytes sent via SQL*Net to client
        746  bytes received via SQL*Net from client
          3  SQL*Net roundtrips to/from client
          1  sorts (memory)
          0  sorts (disk)
        100  rows processed

http://www.sql.ru/forum/actualthread.aspx?tid=833618

http://www.sql.ru/forum/actualthread.aspx?tid=843081

The certain mechanics of the restart isn’t important (I try to get dynamic snapshots for v$rollstat and dba_undo_extents). It’s only one important conclusion – the probability of restart tends to 1 with growth of undo.

Triggers in this context are only the method to disable “array update” with “heavy” restart for that.

And it is not the case of “write consistency” restart. It’s general code for restart that can be initialized by different way.

I know two type of the restart – for all statement and row-level. Undo-restart had row-level signs (without significant additional redo generation) until “array update” appeared in 11g.

Thanks for the two observations – the one about the impact of triggers is one that I don’t think I’ve seen mentioned anywhere in the last 10 years or so, since Steve Adams first mentioned it. It’s definitely time for someone to take a closer look at it and expand on his short note on Trigger Performance.

The peculiarity of a long update (by tablescan, at least) resulting in a rollback and restart is one that appeared in 10.1, I think. It looks almost like an example of Tom Kyte’s “write consistency” problem – but I’ve never got around to looking at it closely. If you’ve written anything more about it (even if it’s in Russian), please feel free to supply a URL.

Here is the test

drop table t purge;

create table t  as
select level id, lpad(level,40,' ') padding
from dual connect by level <= 10000;

exec dbms_stats.gather_table_stats(user, 't', estimate_percent => null, method_opt => 'for all columns size 1')

--alter session set events '10221 trace name context forever, level 3';
--alter session set events '10014 trace name context forever; name savepoints';

update /*+ dynamic_sampling(0) gather_plan_statistics */ t set padding = padding;
commit;

select * from table(dbms_xplan.display_cursor(null,null,'ALLSTATS LAST'));

And this is result from 11.2.0.1:

  
SQL_ID  8jud166qmnbxb, child number 0
-------------------------------------
update /*+ dynamic_sampling(0) gather_plan_statistics */ t set padding = padding
 
Plan hash value: 931696821
 
-------------------------------------------------------------------------------------
| Id  | Operation          | Name | Starts | E-Rows | A-Rows |   A-Time   | Buffers |
-------------------------------------------------------------------------------------
|   0 | UPDATE STATEMENT   |      |      3 |        |      0 |00:00:01.70 |   10618 |
|   1 |  UPDATE            | T    |      3 |        |      0 |00:00:01.70 |   10618 |
|   2 |   TABLE ACCESS FULL| T    |      3 |  10000 |  22427 |00:00:00.02 |     166 |
-------------------------------------------------------------------------------------

So here 22427 = 21(???) + 2406(Array update before restart (from trace)) + 10000(LCR after rollback) + 10000(Array update after locking).