Long IO Latency

Hi All,

I'm an application developer on a huge OLTP/DSS product. During my performance tuning efforts using Statspack, I happened to notice huge latencies under the "Tablespace I/O" and "Disk I/O" sections. The delays sometimes were as huge as 700ms even for Undo Tablespace. I immediately took up this with the client's DBA team.

And I found that they use RAID-5 for all their ".dbf" files. I know that that is a strict no-no. The client's DBA team seems to agree. Just wanted to know from you all, how difficult will it be to migrate all disks down to RAID 0+1? Are there any best-of-breed methods to do it?

Just one more question, while reading the I/O latency in the Statspack report, how slow is slow? I mean lets say the latency is 50ms, how do I determine that it is slow?

I multiplied the "Avg Blocks/Read" field with DB Block Size to arrive at "Avg Bytes/Read" and then used the below equation: (("Avg Bytes/Read" * 1000)/("Av Rd")) = X Bytes/Second.

I then compared this X with the disk manufacturer's specification to determine if its slow or not.

Could anyone advise me on how to write test scripts/programs to test disk latency? I've written a multi-threaded C++ program that does a lot of I/O on available disks. But, when I ran it on the same system, the delays my program observed were much smaller than what Statspack showed. Is my approach correct? Are there any other parameters that I should also consider, like our partitioning policy, separate RAID levels for log and undo tablespaces?

Thanks,
Shiva

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