Re: OS block size

"Dave Haas" <davidh_at_--nospam--hotmail.com> wrote in message news:sUUv6.62876$tr5.6742177_at_news1.telusplanet.net...
> Hi all.
>
> Block size and tablespace size not really related (let the flaming begin
 ...
> :)
>
> The block size of the database is essentially determined from a
 guesstimate
> of the type of load the server will be experiencing. A smaller block size
> (say 4k) increases the number of buffers that can be held in a given
 buffer
> cache and reduces the likelihood of concurrent processes needing the same
> block at the same time. However, it isn't good for ramming sheer amounts
 of
> data through the system. So, the general rule of thumb is smaller blocks
> for OLTP and bigger for something like a warehouse.
>
> Technically the block has to be one of 2k, 4k, 8k, 16k, 32k and on some
> platforms you can get 64k blocks (although I have never seen a system come
> anywhere near that).

Just out of interest:
Ever used the Database Configuration Assistant? It offers a much wider choice of block sizes. There's a little spin control that adjusts the block size to weird options, such as 10128 bytes (something like that, anyway). So the binary powers you list are most definitely not the only options you have (though I agree they are the only really sensible ones).

HJR
>Yes, it should be a multiple of the drive access
> minimum read buffer, but even then, with the caching controllers these
 days
> that's not an issue. Most controllers employ a mechanism that will read
> more off the platter in a single read into the internal drive buffer,
> irregardless of what you actually requested.
>
> HTH,
>
> Dave Haas
>
>
> "Daniel A. Morgan" <dmorgan_at_exesolutions.com> wrote in message
> news:3ABFF1F3.E0F2D9A0_at_exesolutions.com...
> > > The DB_BLOCK_SIZE is meant to be a multiple of the OS block size. But
 how
> > > can one find out the block size for NT/Unix for example?
> >
> > It is the block size of your tablespaces ... not of the O/S.
> >
> > Look in your init.ora file.
> >
> > Daniel A. Morgan
> >
>
>
Received on Tue Mar 27 2001 - 06:35:55 CST