Disk i/o problem: suggestions needed

Question

Oracle Version: 10G Release 2
OS : HP-UX
Physical RAM:16G
Number of users accessing the db on peak time: 250
Due to high Disk i/o I've been asked to do a hardware review on two of our servers.
So this what i am going to do
1. At unix(HP-UX) level, i am going to issue the following command
$ sar -d 10 7
and analyze the results
2. Analyse the results of the following query
SELECT d.name,
f.phyrds reads,
f.phywrts wrts,
(f.readtim / decode(f.phyrds,0,-1,f.phyrds)) readtime,
(f.writetim / decode(f.phywrts,0,-1,phywrts)) writetime
FROM
v$datafile d,
v$filestat f
WHERE
d.file# = f.file#
ORDER BY
d.name
/3. Make sure that Tables and its related Indexes are on different tablespaces which exist on different physical disks.
4. Make sure that datafiles and redo-log files are on different disks
I don't know much about file striping and DB_FILE_MULTIBLOCK_READ_COUNT parameter. So i going to learn about it soon.
Anything you guys want to suggest?

Answer 1

A couple of comments.
HP-UX Glance is an invaluable analysis tool. That is always one of the 1st tools I grab when dealing with what seems to be a performance issue on a HP-UX platform. (it also enables you to write scripts for capturing performance data for analysis - a very useful feature)
What can Glance tell you? The most important fact - is there a real I/O bottleneck, or is this merely a perceived problem from end-users/developers?
I hate wasting my time chasing a non-existing performance problem. Which is why I always harp (in these forums and elsewhere) that. The #1 Step In Performance Tuning/Analysis is -=IDENTIFY THE PROBLEM!=-
Is I/O really the problem? Are the I/O channels being hit hard? Or maybe it is swap space that is being hit hard which in turn not only add I/O (which makes it seem that I/O is the problem), but cause a viscous page swapping and trashing cycle.
On the Oracle side, I/O counts are neither here not there. Just because datafile is being hit harder than another datafile does not necessarily indicate a performance problem.
What is important in my view is WHAT those Oracle sessions is WAITING on? Every single wait means an impact on just how fast that session can do its job.
Is the sessions waiting on I/O? Maybe not.. maybe it is a log buffer waits with the DB Writer being slow as async I/O is not working. Or maybe waiting on redo log switches as the redo logs are too few and small. Or anyone of a 1000+1 other possibilities.
In my view it is imperative to first accurately identify the problem.. and not assume that high disk I/O is the problem. It could very well just be a symptom. And toubleshooting that could very well be a frustrating and wasted exercise.