Re: To use SAME or NOT for High End Storage Setup ?

Don't have an answer for the adding drives to a stripe but we have discussed stripe size here before. If I remember correctly, the answer was that optimal stripe size was a function of concurrent, active users. If you had a "small" number of concurrent, active users then you wanted a large stripe size so that the I/O request could be serviced by as many heads as possible and the possibility that all the data needed would be found in one stripe. If you had a "large" number of concurrent, active users then you want a small stripe size so that as many concurrent I/O requests as possilbe can be accomodated at the same time.

For your answer, I would treat BLOBs as concurrent, active users. Is the problem due to the I/O from retrieving a single BLOB? If so, then large stripes. Maybe even get the BLOB into a single stripe. If the problem is because you're trying to retrieve many BLOBs, then small stripes. The response time for each single I/O request will go up but the system response time will go down (as long as you don't hit a CPU bottleneck).

While thinking about this I was lead to ask: Should stripe size be correlated with number of latches and the latch spin time? That is, "fewer" latches with longer spin times should go with large stripes and "more" latches with shorter spin times should go with small stripes.

I have no ability to quantify any of that "small", "large", "fewer", and "more" in the above. They are all relative for each installation.

What happens to random I/O service time when add drives to a stripe
> and/or increase/decrease the stripe size?
> Is it the same, different, and why?
>
> The reson I ask is that I have a warehouse design that is making heavy
> use of Oracle's spatial data (R-Tree) indexing and it seems to bottom
> out on db_file_sequential_read events. It appears that the spatial index
> processing does a lot of random reads, by rowid, to retrieve a blob,
> which evidently contains more rowids... Anyway I'd like to know if
> there are any optinions on how to improve this sort of performance,
> short of upgrading to 15KRPM drives.
>
> thanks,
> --Peter
> --
> http://www.freelists.org/webpage/oracle-l
>
>
>

--
http://www.freelists.org/webpage/oracle-l