Re: Segment management auto clause

"Richard Foote" <richard.foote_at_bigpond.com> wrote in message news:Dgywa.34488$1s1.500662_at_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 ??

Get off the case, Richard! You like ASSM? Be my guest.

What does RAC have to do with large tables? You're likely to have large tables in a RAC. That's all. No smart-arse comments needed. Of course you can have large tables *not* in a RAC, and I didn't suggest otherwise.

But if a RAC is characterised by large tables, then it stands to reason that ASSM might be a go-er, because the % overhead is not going to be significant.

But all of that is beside the point anyway, because with my shares in Seagate, I really don't give two hoots about 3% extra disk space utilisation. It's full table scan times and kiss-goodbye-to-the-buffer-cache that I dislike.

>
> 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 :)
>

Yes, well you would, wouldn't you. Never let the words I write get in the way of a good argument, huh?

HJR Received on Wed May 14 2003 - 23:33:38 CDT