Originally posted by: SystemAdmin

I have used 2 big LUNs (2 x 500GB) for Oracle Database on DS4700. Many papers recommend to change queue_depth for hdisks. To change the queue depth, the DS4700 guide give the formula :

chdev -l hdiskn -a queue_depth=X -P
**X=2048 / (number of hosts * hdisks per host) if using HACMP, only count the number of active hdisks.**

In my case I have 2 HACMP nodes in mutual takeover. On each node there is an active Oracle database.

hdisk0 000544dfea1238ff rootvg active
hdisk1 000544df69426268 rootvg active
hdisk2 000544dfdbfa7a5f vg_bin active
hdisk3 000544dfdbfa7be6 vg_bin active
hdisk4 000544dfdc51c5e1 vg_dbraw concurrent
hdisk5 000544dfdc51c6b6 vg_dbraw concurrent
hdisk6 000544dfdc51c861 vg_archlog concurrent
hdisk7 000544dfdc51c929 vg_archlog concurrent
hdisk8 000544df62a4015c vg_dbprex1 concurrent
hdisk9 000544df62a4025b vg_dbprex1 concurrent
hdisk10 000544d1f3558159 vg_dbl concurrent
hdisk11 000544dfdc51cd71 vg_hb

hdisk2 to hdisk10 are on DS4700.

hdisk11 : HACMP Heartbeat VG

vg_bin (hdisk2 and hdisk3) : not shared and defined for every node.

vg_dbraw (hdisk4, hdisk5) and vg_archlog (hdisk6, hdisk7) are active on node1.

vg_dbprex1 (hdisk8, hdisk9) and vg_db1 (hdisk10) are active on node2.

How do I calculate queue_depth ?

X=2048 / (2 * 6) = 170

Is it correct ?

Thank you for your help

Originally posted by: Emittim3@Sirius

That appears correct from what I've seen in the past.

One thing to consider, however, is the segment size. The default segment size on the LUNs on the DS4700 are most likely not of an increment of the 'average' I/O on your system(s). Use a tools such as Nigel's Monitor (nmon) to gather statistics for a few days. Then check the average I/O size on the disk(s) you have Oracle on (and others). If your DS4700 segment size is 64K on the LUNs, and the average I/O is between 64K and 128K, that means that for the average I/O your OS is requesting, the DS4700 has to access more than one physical disk in the raid group. If so, then bump up the segment size (can be doubled or halved dynamically without down time) so that your average I/O operation only has to access a single physical disk.

Cheers,
Philip Greer

Originally posted by: SystemAdmin

Thank's Emittim3 for your response.

queue_depth value must be changed for all hdisks of DS4700 ?

For DS4700 segment size, I used 128K

Originally posted by: Emittim3@Sirius

For the segment size - not necessarily. It depends on the average I/O operation size to the specific disks. For instance, if hdisk3 is receiving an average I/O operation of 30K, then the corresponding lun(s) to hdisk3 on the DS4700 should have a segment size of 64K. If hdisk5 is receiving an average I/O operation of 90K, then the corresponding lun(s) on the DS4700 should have a segment size of 128K. So it depends on actual average I/O operations to each of your AIX hdisk resources. I commonly see (in Oracle environments) much smaller I/O operations to hdisk targets that have the archive logs, system tablespaces, etc. on them, and larger average I/O operations occuring to data tablespaces. So each one is tuned differently on the DS4700 side.

The queue depth is set at the fibre channel adapter level - and setting that I usually do per the formula in the DS4K tuning guide (as you originally posted).

Hope that helps.

Originally posted by: SystemAdmin

Hello Philip,

I know that num_cmd_elems for FC adapter must be tuned (for exemple 256) but the queue_depth is on hdisk with

chdev -l hdiskn -a queue_depth=X -P

Thank's

Originally posted by: Emittim3@Sirius

Yep. You're correct! My mistake - it's been a while and I should have re-checked before I posted. Queue depth is at the hdisk level, not the fibre channel adapter level.