Long IO Latency
- From: Shivanischal A <shivan@xxxxxxxxxxxxxxxx>
- To: oracle-l@xxxxxxxxxxxxx
- Date: Tue, 16 Aug 2005 16:22:58 +0530
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
--
//www.freelists.org/webpage/oracle-l
Other related posts:
