Re: Change db_block_size

But that's what the Recycle Pool is for, in the first place. Tucking BLOB data out of the way so that it doesn't interfere with the rest of your cache is already possible (and has been since 8.0), and it doesn't require it to be *physically* stored in a block size that is inefficient to retrieve from the word go.

Put it another way: whatever is the block size that makes for optimal retrieval of LOB data will also be the block size that makes for optimal retrieval of any other form of data. Sure, place them in different bits of the cache so that your LRU list is not overwhelmed, but placement is a separate issue.

I can see years ahead of me, having to deal with people who think variable block size is the answer to all their woes!! Grrrrr. Just think 'transportable tablespaces', and the feature makes sense. Outside of that....

Regards
HJR

--
Resources for OracleT: www.geocities.com/howardjr2000
=========================================


"Nuno Souto" <nsouto_at_optushome.com.au.nospam> wrote in message
news:3bc82c33.2572658_at_news...


> In a valiant and sublime effort,Howard J. Rogers

> dipped a thumbnail in soot and doodled:

>

> >useful feature.  First, there's no keep or recycle pools for new block

> >sizes, only for the one you started out with.

>

> Let's hope that makes it to the next version...

>

> > And second, there *is* a

> >"correct" block size for your operating system and file system, and

picking


> >any other one will impact on performance.

> >

>

> Sure. But what about databases where you HAVE to keep BLOB/CLOB stuff

> as well as other normal data?  I'd rather have a TS reserved for the

> large data with a large block size and the rest with an optimal block

> size for normal processing.  That way I can keep the BLOB stuff from

> upsetting the performance of the rest of my data cache.

>

>

> Cheers

> Nuno Souto

> nsouto_at_optushome.com.au.nospam