oracle itanium vs. pa-risc performance

[Yogeeraj_1]

hi tony,

I am no expert in this field. But, unless and until you have a properly tuned database and applications running on the your server, you won't be able to reep the benefits of it being state-of-the-art...

My point is that it should be RIGHT-SIZED. Clay mentioned a good point about I/O which is much more important than the CPU when you are talking about Oracle RDBMS.

Should we consider support, lifetime and upgradability? Lots of questions...

Hope experts in this field clarify these myths...

good luck

regards
Yogeeraj

[Tony Drake_2]

Jeff:

How did you determine that the solution was to add more fiber cards?

I have been trying for more than 6 months to find a way to determine fiber card saturation, to no avail.

I have glance, Measureware, PV, etc, but have been unable to do it.

Thanks again all for the comments. They are well taken and very helpful!

[Alzhy]

Tony.. it may not be fibre bandwidth saturation that you will be addressing by providing more Fibre Channels between your server and your storage front-ends but rather a possibility that the array's front-end's queue capacity may be saturated. I/O is the undeniable beast that hinders true database performance (or comparisons). I am in total agreement that tuning queries and Oracle most often provides performance increases but with the tools both external and internal to current releases of Oracle - even the novice DBA will certainly take notice that there is something wrong with a query or a DB operation. Most of the dramatic performance leaps I've seen in Oracle environments in the last 3 years have been in the arena of proper provisioning (and layout) of storage. By this I mean - lumping and spreading out I/O so that it matches your storage architecture. If your using say an XP/HDS array - then the recipe should be to stripe accross however many LUNS from each array group presented on different HBA's/FC paths. I've seen and helped configurations wherein stripes are even accross arrays.

So for purposes of comparing one architecture to another (ie. DB benchmarking) - it is important that whateevr I/O configurationand layout you have on one platformis exactly the same as the other. With PARISC - Itanium comparisons - it is just a matter of providing the same number and kind of HBA's since data is compatible between the architectures.

[Jeff Schussele]

Hi (again) Tony,

It was simply the fact that I/O wait times & queueing on specific FC devices clearly showed that the I/O needed to be spread out.
For Example we had 12 table/index filesystems each on this server across 4 FC cards to start & started seeing higher & higher times/queues on 1/2 of them. BUT it was across several filesystems. SOOOOO we added more cards & spread that load out. That helped. but, we were running on V-class systems & it's bus was not keeping up so we then moved to rp8400 & we are now able to sustain the intermitent burst rates necessary.

Rgds,
Jeff

[Tony Drake_2]

jeff:

How did you measure the wait time and queuing on the FC devices?

Thats what I was asking about, because I have not found any way to look at an FC device directly. Only disk and filesystem metrics seem to be available, which really don't help pinpoint if its the fiber cards or not.

We are working to get EMC control center in so we can see the SAN better, but I would like to be able to see the FC's on each server if thats possible.

[Alzhy]

glance -u
sar -d 5 100

will give you an overall picture of your storage - if you've busy LUNs or if the array front -end are flooded - so queuing will be manifesting in the form of greater than 0 "avque" values.

[Dan Copeland]

Tony,

FC throughput measurement via PV -- doc attached.

Dan