Re: ASSM vs. non-ASSM

From: Noons <wizofoz2k_at_gmail.com>
Date: Mon, 30 Jan 2012 18:37:04 -0800 (PST)
Message-ID: <f569c0aa-91b5-4451-bf7e-4fc524529e70_at_b10g2000pbd.googlegroups.com>



On Jan 30, 9:06 pm, Randolf Geist <i..._at_sqltools-plusplus.org> wrote:
> On Jan 29, 4:28 pm, Noons <wizofo..._at_gmail.com> wrote:
>
> > Oh, I should have added that I use uniform allocation in all my
> > tablespaces, rather than automatic allocation. As such, I never get
> > any of the conditions described in Jonathan's posts on ASSM.
>
> I think this is a misbelieve - most of the issues described are
> regarding the space management within an extent/block and hence apply
> to either extent management method, no matter if uniform or auto-
> allocate. Which means these can easily be reproduced using uniform
> allocation, in fact Jonathan most of the time uses uniform 1MB
> allocation in his experiments.
>

Actually, he specifically refers in the posts mentined here to it being partly a result of auto allocation. Which quite frankly is a bad idea at best of times as it leads to fragmentation of free space if the tablespace is volatile.

I have no issues whatsoever with large numbers of uniform extents in a ASSM tablespace, and I do run reasonably large databases with TBs of data movement per day.

IME, ASSM is remarkable resilient if uniform allocation is used and care is taken to isolate and contain table volatility loads by grade/ volume. Which is a much easier proposition than fussing around with buffer busy waits and their remedies in non-ASSM storage, with the incumbent "reorgs".

The above of course assumes a patched up system - not a vanilla install. Received on Mon Jan 30 2012 - 20:37:04 CST

Original text of this message