Re: Change db_block_size

"Nuno Souto" <nsouto_at_optushome.com.au.nospam> wrote in message news:3bc9a119.2229393_at_news...
> 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.

We'll agree to disagree, then. Where you have a file system buffer to keep happy, anything other than that as a block size will induce additional I/O, even on single reads.

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

Er... it's still a question of efficient I/O, and that still comes down to file system buffer size, or larger where possible because of a lack of such a buffer (ie, raw).

If you have a series of 16K blobs, read individually, it is surely going to be better to have 16K blocks and do one i/o reads per blob than 8k blocks and two.

Whatever, huh?
HJR
>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 - 15:13:59 CDT