Truncate performance on 10g vs. 8/9i

Question

Has anyone experienced better truncate performance on 10g vs. earlier versions? We've had crippling episodes on 8i and are hoping for a noticeable improvement.

Answer 1

One thing a truncate does is to require dbwr to write any cached buffers of the table to disk prior to the object being truncated. At first consideration this may not appear to make sense to someone, however when the requirement to support time based forward recovery to the moment just prior to the truncate command being issued then this does indeed make perfect sense. Dirty blocks for the target table and indexes have to be flushed to disk prior to the object header(s) being marked as empty.
Then under dictionary management uet$ and fet$ have to be updated for the extents. The single ST lock on the database is used to single thread access to these two tables so multiple concurent truncates, Create tables, Drop tables and the resulting extent allocations that have to happen for each of these tasks is potentially bad news as each session attempts to grab the single ST lock.
To eliminate contention for the ST lock is why Oracle introduced temporary table locks (used with sort segments)
and part of the reason behing locally managed tablespaces.
Under dictionary management you can help lession contention for the ST lock by first defining your temporary tablespace to be of mode temporary (create tablespace temp temporary) or to use the newest form of create temporary tablespace temp tempfile 'xx' and by assigning extent sizes to minimize the number of extents allocated per time period. Conversion of tablespaces to being locally managed is a big help here also.
HTH -- Mark D Powell --