Why use uniform extent allocation?

Question

version- 11.2.0.2.0
Hello guys, I've been reading UNIFORM vs AUTOALLOCATE extent allocation.
I've read the following articles.
https://blogs.oracle.com/datawarehousing/entry/parallel_load_uniform_or_autoallocate
Ask Tom: On Loading and Extents
https://forums.oracle.com/thread/2518951
From what I understood, autoallocate trumps the uniform in all scenarios (unless I am missing something).
In the thread "AUTOALLOCATE vs UNIFORM SIZE"
for the benefits of autoallocate and uniform size allocation Kh$n wrote
Benefits of AUTOALLOCATE
* Prevents space fragmentation.
Benefits of UNIFORM extent sizes
* Prevents fragmentation. 
(I dont understand what is the difference between those two fragmentation prevention, are those benefits one and the same?)
even in scenarios where we know exactly how much data will be loaded, there is always a chance of extent wastage and with out extent trimming that space will be unusable.
Can someone please explain in which cases we use uniform extent allocation?
for suppose we use uniform extent allocation and we have lot of unused space from the extent allocation, can that space be reclaimed using shrink space command for tables and indexes?
Thank You

Answer 1

Extent trimming, to the best of my knowledge, is something that only happens when you are using parallel query to do large loads, not something that happens during normal OLTP type operations.  As with anything called "automatic" in Oracle, though, the internals are subject to change across versions (and patchsets) and are not necessarily documented, so it is entirely possible for behaviors to change over time.  Relying on specific internal behaviors is generally not a good idea.
The example I gave (assuming you reverse the truncating of A and the loading of C, as Hemant pointed out) produces "fragentation" when you're using automatic extent management.  It's not a particularly realistic scenario, but it is possible.  If you never delete data, never truncate tables, (and, presumably, never shrink tables), extents would never be deallocated and there would, therefore, never be holes.  That is just as true of ancient dictionary managed tablespaces as well as locally managed tablespaes whether you're using uniform or autoallocated extents.
Shrinking a table has nothing to do with defragmenting a tablespace.  It is simply compacting the data in the table and then potentially deallocating extents.  You can do that with any locally managed tablespace.  There is still the possibility, of course, that you have just enough data in the table that you need to allocate 1 extra extent when you only need space for 1 row in 1 block.  So there may be some number of MB of "wasted" space per segment (though, again, this is generally not something that is a practical concern since the data in tables generally changes over time and it's generally not worth the effort of worrying about a few MB).
Justin
For your third question, assuming both extents are part of the same segment, assuming that the space is actually usable based on things like the PCTUSED setting of the table, and assuming a nice, simple conventional path insert in a single-user, Oracle would use the free space in the extent for new inserts before allocating a new extent.  Oracle generally doesn't allocate new extents unless it needs to (there are caveats to this-- if the only blocks with free space have a relatively large fraction of their space used such that a particular new insert only fits in 1 of the 1 million blocks in the currently allocated extents, Oracle will potentially give up before finding the 1 in a million block that it would need an may allocate a new extent).
Message was edited by: JustinCave