On my side I tested how much UNDO is generated for an UPDATE statement (updating a single integer column).

Running these queries:

SELECT to_char(sysdate, ‘HH24:MI:SS’), b.used_urec, b.used_ublk

2 FROM v$session a inner join v$transaction b ON a.saddr = b.ses_addr

3* WHERE a.sid = 1081

Give us back:

41867461 undo records used and 529654 undo block used.

AND:

SELECT to_char(sysdate, ‘HH24:MI:SS’), a.sid, b.name, a.value

2 FROM v$sesstat a inner join v$statname b ON a.statistic# = b.statistic#

3 WHERE a.statistic# = 208 AND

4 a.sid = 1081;

Give us back:

4216598256 for the value of “undo change vector size”.

How a table of 2.2GB that uses 292224 blocks can require about 4GB of undo space to be updated (and 529654 undo block)?

We have tested on 10G R2 and on 11G with both using automatic UNDO management.

Best regards.

Carl

Thanks for the response.

It’s been a while and I am at a different work site now, I do not have access to the specific details related to this. IIRC, there were no special adjustments to the spfile, I recall the database was set up for Automatic Undo, the tablespace for the table was in LMT (possibly with ASSM).

The only thing I am not sure is, I might have set up the database for supplemental logging as I was testing some stuff related to Oracle Streams.

Regards,
Arul

Since your rows are about 40 bytes, you should have about 200 per 8Kb block, which means about 5,000 blocks in the table – so I would expect to see about 5,000 records in the 10.2.0.3 test. (And this is what I got when I repeated your test – although I got 200,000 when I recreated the table as an index organized table with both columns in the primary key).

Have you installed your database with any special adjustments to the spfile ?

Regards
Jonathan Lewis
http://jonathanlewis.wordpress.com
http://www.jlcomp.demon.co.uk