Re: locally managed tablespace & dictionary managed tablespace

"Richard Foote" <richard.foote_at_bigpond.com> wrote in message news:KYeR9.15746$jM5.43862_at_newsfeeds.bigpond.com...
>
> "Howard J. Rogers" <howardjr2000_at_yahoo.com.au> wrote in message
> news:BbQP9.12506$jM5.34484_at_newsfeeds.bigpond.com...
> <big snip to try and improve my OCR ratio !!>
>
> > However, once I'd shown said colleague that UNIFORM SIZE could take
> > arguments like 64K, 256K, 1M and 8M (and once he'd edited the install
> script
> > to direct each table to the right tablespace) we brought that
installation
> > down to a mere 94MB. Still a bit bigger than what he'd got in DMT, but
> only
> > by 10MB.
> >
>
> Hi Howard,
>
> I just thinking out loud here so forgive me if this resembles a pile of
the
> steamy stuff...
>
> Just to follow on from the above, if you have a whole stack of very small
> lookup tables, this could be a good reason for using a small block sized
> tablespace (9i of course).
>

It's no good having good disk space usage if loading said lookup tables is performed inefficiently.

But we've been down this road before.

So let's not go there again, eh?!

Cheers,
HJR
> By having a 2K block size, you then can have a LMT with a uniform size of
> 4K. If you have many tables in this category, you can potentially reduce
> space consumption by an amount.
>
> But also, as you must also have a corresponding 2K buffer cache which can
> only be used by these objects, by sizing the buffer cache appropriately,
you
> have just invented another KEEP pool (of sorts). All these small,
> potentially heavily accessed objects can be cached in memory improving
> performance by ensuring the 2K buffer cache is big enough. I/O could also
be
> more advantages as you also read what's required and little it is too.
>
> Another reason (possibly) why LMT are mmmmmmmmaaaa (big wet kiss kinda
> sound).
>
> Hope Santa was good to you ;)
>
> Richard
>
>
Received on Fri Jan 03 2003 - 08:22:43 CST