I only received a few responses, but the general consensus was what I
somewhat expected -- play with it and see what works best.
Alan says he's worked with IO sizes up into the megabyte range and hasn't
seen any problems (so it seems I don't have to worry too much about a
block request not being handled by a single IO request). He says most of
the recommendations he's seens suggest a stripe size of 10-20 times the
average IO size; you generally want to make sure that a single request can
be handled by a single disk in the set, so that other disks can handle
other incoming requests concurrently. However, if IO is mostly sequential
with large IO requests it may be possible to get better performance going
the other way (assuming well aligned accesses) and making stripe size
smaller than IO so that you can take advantage of more disks serving a
single request.
He also noted that using large chunks may put excessive IO on a single
disk and negate advantage from striping.
Matthew Huff added that while it used to be that there were potential
problems with limits on the number of extents with small blocks under
oracle, this is no longer the case. Also depending on the application,
different stripe sizes will work better. Larger will generally work
better for OLTP vs smaller for decision support. He suggested setting
up scripts to time operations and rebuilding the database with different
sizes. Additionally he stated that the oracle block size should
typically be a multiple of the stripe size (although the article
from Cary V. Millsap states the converse; that you should generally have
a stripe size that is at least two times as large as the oracle block
size. This seems to be a concurrency issue; for fewer, larger queries it
is probably best to have a fairly small stripe size to distribute things
across disks; for more, smaller queries it's probably best to have a
larger stripe size).
Thanks for the responses; now on to do some testing :)
-Tymm
My original message follows:
> Date: Fri, 31 Mar 2000 13:58:22 -0500
> From: Tymm Twillman <tymm_at_netcreations.com>
> To: tru64-unix-managers_at_ornl.gov
> Followup-To: poster
> Subject: Oracle, raw partitions and block sizes
>
> Hi,
>
> We're working on optimizing a large Oracle database on a couple of
> GS140's running Tru64 Unix 4.0F (with all recent patches applied). We're
> using Qlogic ISP 1020A SCSI controllers (4 per system) connected to 4
> shared MTI 9000 arrays (utilizing TruCluster and OPS for
> failover/balancing), using raw partitions for all database storage. In
> addition we have all filesystem-based storage on local disks hanging
> off of 53C810 based controllers (note: these are all Compaq parts, I'm
> just really bad with Compaq part #'s :) ). I'm trying to figure out the
> optimal block size to use for striping across the MTI arrays, and in the
> process trying to find the maximum block read/write sizes that Tru64 will
> support at the hardware level with the 1020A's in this configuration. Also
> any other configuration tips from folks that have dealt with the same or
> similar setups would be appreciated.
>
> RTFM is an answer I'll gladly accept, given someone can tell me where to
> find the FM :) At this point I'm working from the Cary V. Millsap paper
> ("Configuring Oracle Server for VLDB") and playing with configuration
> options based on the recommendations therein.
>
> Thanks in advance,
>
> -Tymm
>
Received on Mon Apr 03 2000 - 21:00:01 NZST