Re: ASSM vs. non-ASSM

From: Mladen Gogala <gogala.REMOVETHISmladen_at_google.com>
Date: Thu, 26 Jan 2012 17:06:36 +0000 (UTC)
Message-ID: <jfs16r$lqn$1_at_solani.org>



On Thu, 26 Jan 2012 01:01:18 -0800, mhoys wrote:

> On Jan 25, 9:21 pm, "Gerard H. Pille" <g..._at_skynet.be> wrote:

>>
>> We have a couple of tables in which there are continuous inserts and
>> deletes, at a dreadful rate, and we have to rebuild the indexes every
>> week, to keep size and performance in check.
>>
>> Could not fall back to MSSM, because system is also ASSM, I seem to
>> remember.

>
> "To keep size and performance in check"; I understand the size issue,
> but how do you measure the performance of your indexes before & after
> the rebuild? Do you really have significant performance improvements
> after rebuilding the indexes?
>
> Matthias

I was actually looking for any argument against ASSM. The app to be converted uses 8i philosophy with uniform extents and manual segment management. As a result, there is a genuine tablespace zoo. Indexes and data are separated, a relict from the good old times when DBA could specify disk devices, and the tablespaces are divided in 3 categories, S,M and X. There is a bitter opposition to the idea of having auto-allocate tablespace with ASSM, one for each logical part. I wonder what kind of argument can be made in favour of such 8i organization, disguised as 10G database? So far, no argument has been presented to me, that's why I'm asking.

-- 
http://mgogala.freehostia.com
Received on Thu Jan 26 2012 - 11:06:36 CST

Original text of this message