Tablespace with too many extents are evil for performance

Question

I think the tablespace with too many extents are not bad for performance after introduction of LMT tablespace?? May be true with DMT tablespace(earlier versions). This is just observation after reading the LMT vs DMT tablespaces.
Experts - Please comment on your thoughts.

Answer 1

Indeed, I work in an environment where there is over 50 databases to be administered and so we have lots of DBAs interacting with each other.
I'm stunned by this myth of "reorganization". Most of the DBAs move tables + rebuild indexes regularly generating huge redo  on a monthly basis. Also provoking indexes to do all the splits again generating even more redo. They claim "it helps performance a lot" however not one is able to quantify and quite justify it other than "less extents less I/O, good". Even when I bring up the existence of shrink they say "do not like it, prefer the classic move". People really have a way of holding on to their good ol' practices of Oracle 8i.
For full table scans (which should never be done on a OLTP scenario) this extent issue would be relevant IF data on the table is the victim of large deles and Oracle hasn't re-used that space yet. If your multiblock reads is a multiple of your extent size, than there won't be any overhead of I/O call, no matter the number of your extents. For OLTP this is not relevant because Oracle will access the table via ROWID.
I rarely have ever seen an index benefit from a rebuild significantly. In my experience what people often understand as "index fragmentation" is often just an unoptimized execution plan due to cardinality issues where oracle ends up fetching a large percentage of the table via single reads on that index.