Re: Change db_block_size

In a valiant and sublime effort,Howard J. Rogers dipped a thumbnail in soot and doodled:

>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

Yeah, the problem is that there is only one recycle pool. If I have various types of application running in a single instance, I want finer control than just a single "bit bucket". It's only too easy to overwhelm the current three, jointly or "severally" (how's that for borrowing a banking term?). :-)

>
>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.

Hmmm, disagree. In general, BLOB stuff will be retrieved/processed one by one. Which is completely different from the requirements of, say, a data mart. Where full scans combined with short indexed retrieves may be required. Each requires a different strategy for best block size. Even with today's boxes. Not saying that tomorrow that won't change, mind you!

>
>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....
>

Yeah, unfortunately people will always look for "silver bullets" that will "solve" all problems. Been like that for ages. Still well remember the fragmentation one. We are gonna see databases with block sizes galore for sure.
<groan>

Cheers
Nuno Souto
nsouto_at_optushome.com.au.nospam Received on Sun Oct 14 2001 - 09:37:05 CDT