Large Uniform Extent Size = Slow TRUNCATE?

Question

Here's the scenario...
We have a a tablespace with the following storage parameter:
EXTENT MANAGEMENT LOCAL UNIFORM SIZE 32M
Users were complaining about slow TRUNCATE performance. I saw the same when I created a table with 30,000 rows - same as the user was complaining about - in the same tablespace.
I proceeded to move the objects from the schema the user was referencing to a tablespace with:
EXTENT MANAGEMENT LOCAL AUTOALLOCATE
... and the TRUNCATE executed in the expected time (less than a second) for the same amount of rows in the same table structure.
Why does a large UNIFORM extent size (such as 32M in this case) cause for slow TRUNCATE performance? I wasn't able to find an exact cause of this in the forums or on Metalink thus far.
Version: Oracle DB 10.2.0.3
System Info:
Linux ilqaos01c 2.6.9-55.0.12.ELsmp #1 SMP Wed Oct 17 08:15:59 EDT 2007 x86_64
Thanks.

Answer 1

Robert Sislow wrote:
The Metalink article was helpful, however, the database we're on is version 10.2.0.3, and the article is referencing 9.2.0.4.
Additionally, the last few responses in this thread are referring to concurrent TRUNCATE operations. The TRUNCATE that we're running is a single-thread TRUNCATE on a very small table - about 8000 rows.
After executing a 10046 level 12 trace, and using the Trace Analyzer tool, we've found that the "local write wait" event is taking up ~90% of the statement's activity for each run. Once again, all we can find that's causing this is the fact the the extent size in the tablespace with the table where we're seeing the slowness is set to UNIFORM size of 32M.
You're using ASSM (automatic segment space management), which means you have a number of bitmap space management blocks scattered through the object.
If you're running with 32MB uniform extents, the first extent will be 4096 blocks, and there will be one level 2 bitmap, 64 level 1 bitmaps, and the segment header block at the start of the extent. With autoallocate, the first extent will start with one level 2 bitmap, one (or possibly 2) level 1 bitmap(s) and the segment header block.
When you truncate an object, all the space managment blocks in the first extent (and any extents you keep) have to be reset to show 100% free space - this means they may all have to be read into the buffer cache before being updated and written back with local writes (i.e. writes by the process, not by dbwr).
So you have to wait for 66 reads and writes in one case and 3 (or 4) reads and writes in the other case. This helps to explain part of the difference. However, a local write wait should NOT take the best part of a second - so there must be a configuration problem somewhere in your setup. (e.g. issues with async I/O, or RAID configuration).
Regards
Jonathan Lewis