Re: type of striping

>> Just thought I'd mention that in fact, things were and are, precisely
>> the opposite way around. In a multi-file tablespace in 8.0, for example,
>> Oracle would allocate the initial extent on file 1, the next on file 2,
>> the next on file 3, then back to file 1, 2, and so on. It would, in
>> short, "round robin" the extents.
>>
>> In locally-managed tablespace, it hammers disk 1 to death and only moves
>> on to disk 2 when no more space is available on disk 1 *IF* the
>> tablespace is AUTOALLOCATE LMT. If you do UNIFORM SIZE LMT, then the
>> round robin behaviour is unchanged.

> 
> 
> That's all I ever use is uniform size LMT's. IIRC however the behavior 
> in v7 (which only had DMT's) was to fill one datafile before moving to 
> the next.

Not true. I used to demo it all the time: poor man's striping, I used to call it. It was true for 7 and 8 and 8i. And I've literally just tested it on a 9i Solaris database in class, with extent management dictionary, and it's still exactly the same behaviour.

> Thanks for the info on the different behavior with auto allocate LMT's. > For me, that's one more reason to avoid them.

Oracle's not like that. You shouldn't say "I'll avoid X" or "I'll not make use of Y", unless it's PCTINCREASE. Easy answers are usually no answers at all, and the correct approach should be to weigh up any feature's pros and cons.

Autoallocate is probably my preferred way of creating LMTs.

Sure, they have this one 'side effect'. That's not a reason for avoiding autoallocates, though: it's merely one more piece of evidence to weigh before making an intelligent assessment about them.

And when one bears in mind that (I would guess) most Oracle databases on the planet use some sort of hardware striping, the lack of round-robin extent allocations in autoallocate LMT is probably of no significance. If you have no hardware striping capability, however, then sure: it's definitely a factor to consider.

Regards
HJR Received on Tue Dec 07 2004 - 16:00:41 CST