Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.server -> Re: Segment management auto clause

Re: Segment management auto clause

From: Richard Foote <richard.foote_at_bigpond.com>
Date: Thu, 15 May 2003 07:27:15 +1000
Message-ID: <Dgywa.34488$1s1.500662@newsfeeds.bigpond.com>


Hi again,

Comments embedded

"Howard J. Rogers" <howardjr2000_at_yahoo.com.au> wrote in message news:J%wwa.34465$1s1.499923_at_newsfeeds.bigpond.com...

>
> Your earlier comment is nearer the mark: for big tables, the overhead (of
> space utilisation) as a proportion reduces. For small tables, the overhead
> can be significant. Sweeping statement, I realise (so yes, you can call
this
> one a generalisation if you like): but where are you likely to have large
> tables? In a RAC. So where is the space overhead going to be minimised?
Er,
> in a RAC. And where have I said ASSM is an excellent solution to a
> particular problem? Stone me, but in a RAC.

What the ??

What does RAC have to do with large tables ??

We have some very large tables at my current site and ummmm, no RAC. I'm sure that there are many, many, many other sites with large tables that are RACless.

Like most ..

I wouldn't call your statement a sweeping generalisation, but an incorrect one :)

>
> > > Again, an obvious big depends.
>
> In life, most things depend.
>
> Right now, there's not a word in any Oracle material about the potential
> costs of ASSM. It's all presented as an unmitigated blessing. Your test
> shows blessings, mine have repeatedly shown costs. All I have done since
> last August (if it was then, and I take your word) is point out here and
in
> the classroom that ASSM is not a straightforward, no-brainer, one-way bet
of
> a decision that Oracle's own material makes it out to be (or that LMT is
> these days, either). That it definitely has its uses. That I would
> unhesitatingly recommend it over multiple freelists as a cure for FLC. But
> that it has potentially enormous costs (disk space not being the major one
> by a long shot).

What you have done since August (from my perception which I admit could be wrong) is to suggest that ASSM is no good, don't ever touch it, your mad if you do, unless it's RAC or similar (just like you again said to the OP).

I guess I'm just waving a little flag and suggesting it's not necessarily as simple as that ...

>
> There are now two sets of results out there which appear to conflict.
That's
> no bad thing, because people can always repeat published tests for
> themselves and see how their systems behave. But I don't report results
> which are one-offs, but only those which are repeatable. And repeatable.
And
> repeatable.
>
> Now, if you find ASSM a good thing, fine by me. But I haven't, and my
> research on this matter has not been confined to just two test runs and a
> benchmarking environment.

I don't know what testing you've done but I guess this is what I find so strange. I find it surprising that with all the testing you've done, you've not come across scenarios in your testing where ASSM does NOT have "significant overheads". I have come across countless such scenarios and that why my position is so "one-sided" on this issue.

With most things (although I agree not all) things really do depend and ASSM is one such thing. And the it depends is not just limited to quote "unless you happen to be suffering from extreme free list contention (which commonly happens in a RAC environment)".

"Significant overheads" quote again, is not necessarily the case.

Cheers

Richard Received on Wed May 14 2003 - 16:27:15 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US