“so although it reports “1 table scan rows gotten”, if i grep ^nrow= on the 11.2.0.3 trace file, i still see 894 pieces.”

should be

“so although it reports “1 table scan rows gotten”, if i grep ^nrow= on the 11.2.0.3 trace file, i still see 8092 pieces.”

112 blocks in segment;

select * from t2;

1 opened cursors cumulative
3 user calls
10113 session logical reads
2 CPU used when call started
2 CPU used by this session
2 DB time
1 global enqueue gets sync
1 global enqueue releases
10113 consistent gets
10113 consistent gets from cache
5 calls to get snapshot scn: kcmgss
10109 no work – consistent read gets
1 table scans (short tables)
10095 table scan rows gotten
109 table scan blocks gotten
9999 table fetch continued row
1 cursor authentications
10000 buffer is not pinned count
1 parse count (total)
1 execute count
508 bytes sent via SQL*Net to client
273 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client

grep ^nrow=, add up gives 10001 pieces.

and on 11.2.0.3 64 bit linux, bs=8192 (2 node RAC, crs=11.2.0.3)

112 blocks in segment;

2 Requests to/from client
1 opened cursors cumulative
3 user calls
10113 session logical reads
2 CPU used when call started
2 CPU used by this session
2 DB time
14 non-idle wait count
2 global enqueue gets sync
2 global enqueue releases
10113 consistent gets
10113 consistent gets from cache
9933 consistent gets from cache (fastpath)
82845696 logical read bytes from cache
4 calls to kcmgcs
1 calls to get snapshot scn: kcmgss
10109 no work – consistent read gets
1 table scans (short tables)
1 table scan rows gotten
109 table scan blocks gotten
9999 table fetch continued row
1 cursor authentications
10109 buffer is not pinned count
1 parse time cpu
1 parse time elapsed
1 parse count (total)
1 execute count
100523 bytes sent via SQL*Net to client
298 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client

so although it reports “1 table scan rows gotten”, if i grep ^nrow= on the 11.2.0.3 trace file, i still see 894 pieces.
also, the table fetch continued row is the same as on 10.2.0.5.

so the fix seems to be just in changing the def for “table scan rows gotten”, or i am missing a patch?

Very clever – and I like the way you’ve used the ‘collapse=”true”‘ on the results, it makes the whole thing tidier and easier to read.

I ran your test on 11.2.0.3 and it still produced the 10,000 pieces – but I was using an 8KB block size rather than the 16KB you mentioned in your follow-up.

I suspect, but haven’t tested yet, that you could reproduce the effect in th 16KB block size if you created the table with 4 populated columns (which would give you an immediate chain) then added, updated, and dropped 5 columns at a time, so that each update introduced a new chain and the drop had to apply to the previous block in the chain.

drop table t2 purge;
create table t2 (v0 varchar2(4000));
insert into t2 values(lpad(1,4000));
declare
  j number := 1e4;
begin
  for i in 1 .. j loop
    execute immediate 'alter table t2 add v'||i||' varchar(4000)';
    execute immediate 'update t2 set v'||i||' = lpad(1,4000)';
    execute immediate 'alter table t2 drop column v'||(i-1);
  end loop;
  execute immediate 'alter table t2 add n number(1)';
  execute immediate 'alter table t2 drop column v'||j;
  execute immediate 'update t2 set n = 1';
end;
/
desc t2
select blocks from user_segments where segment_name = 'T2';
begin
  for rec in 
  (
    select file_id fn, block_id minbn, block_id + blocks  - 1 maxbn
    from dba_extents 
    where owner = user and segment_name = 'T2'
  ) loop
    execute immediate 'alter system dump datafile '||rec.fn||' block min '||rec.minbn||' block max '||rec.maxbn;
  end loop;
end;
/
set autot on
select * from t2;

As result I had table with 1 row and col that had 10k pieces.
When I cheked it on 11.2.0.3 – there was only one piece, i.e. Oracle fixed this.
Here is the result for 11.2.0.1:

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

SQL> create table t2 (v0 varchar2(4000));

Table created.

SQL> insert into t2 values(lpad(1,4000));

1 row created.

SQL> declare
  2    j number := 1e4;
  3  begin
  4    for i in 1 .. j loop
  5      execute immediate 'alter table t2 add v'||i||' varchar(4000)';
  6      execute immediate 'update t2 set v'||i||' = lpad(1,4000)';
  7      execute immediate 'alter table t2 drop column v'||(i-1);
  8    end loop;
  9    execute immediate 'alter table t2 add n number(1)';
 10    execute immediate 'alter table t2 drop column v'||j;
 11    execute immediate 'update t2 set n = 1';
 12  end;
 13  /

PL/SQL procedure successfully completed.

SQL> desc t2
 Name  Null?  Type
 ----- ------ ---------
 N            NUMBER(1)

SQL> select blocks from user_segments where segment_name = 'T2';

    BLOCKS
----------
       120

SQL> begin
  2    for rec in
  3    (
  4      select file_id fn, block_id minbn, block_id + blocks  - 1 maxbn
  5      from dba_extents
  6      where owner = user and segment_name = 'T2'
  7    ) loop
  8      execute immediate 'alter system dump datafile '||rec.fn||' block min '||rec.minbn||' block max '||rec.maxbn;
  9    end loop;
 10  end;
 11  /

PL/SQL procedure successfully completed.

/***************************************************/
block_row_dump:
tab 0, row 0, @0x16d7
tl: 9 fb: --H-F--- lb: 0x31  cc: 0
nrid:  0x01002755.0
tab 0, row 1, @0x16ce
tl: 9 fb: -------- lb: 0x0  cc: 0
nrid:  0x01002755.1

...

tab 0, row 68, @0x169b
tl: 9 fb: -------- lb: 0x0  cc: 0
nrid:  0x01012ad5.44
tab 0, row 69, @0x6ef
tl: 6 fb: -----L-- lb: 0xa  cc: 1
col  0: [ 2]  c1 02
/***************************************************/

SQL> set autot on
SQL> select * from t2;

         N
----------
         1

...

Statistics
----------------------------------------------------------
          4  recursive calls
          0  db block gets
      10181  consistent gets
          0  physical reads
          0  redo size
     100523  bytes sent via SQL*Net to client
        520  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          1  rows processed

On 11.2.0.1, if I didn’t add the update statement for the last col I would get “ORA-03106: fatal two-task communication protocol error”, it also happens in the simpler situation (and I’ve seen similar bugs for 11.2.0.1 on MOS):

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

SQL> create table t1 (v0 varchar2(4000));

Table created.

SQL> insert into t1 values(lpad(1,4000));

1 row created.

SQL> alter table t1 add v1 varchar(4000);

Table altered.

SQL> update t1 set v1 = lpad(1,4000);

1 row updated.

SQL> alter table t1 drop column v0;

Table altered.

SQL> alter table t1 add n number(1);

Table altered.

SQL> alter table t1 drop column v1;

Table altered.

SQL> select * from t1;
select * from t1
*
ERROR at line 1:
ORA-03106: fatal two-task communication protocol error

SQL> update t1 set n = 1;

1 row updated.

SQL> select * from t1;

         N
----------
         1

I’ve just done a quick search on MOS and found note 238519.1, dated August 2004: “Updating a Row with More Than 255 Columns Causes Row Chaining [ID 238519.1]“ One of the suggested fixes is to ensure that the last column of the row is populated on insert. It’s easy to make a good case for not doing this, and it probably won’t stop all sorts of odd chaining and migration effects relating to lots of null columns being updated to non-null, but it might stop some of the extreme cases like my 746 block chain.

“Moreover it is sufficient to have only 1 ROW in the table”
?

i mentioned the SR because i was really surprised to see this, and the behaviour appears to be ‘stupid’ at first sight. I did not mean it literally :D

thx for this fun example!