va7100 LUN and lv creation

[Charles McCary]

Group,

We have two N-classes connected via fiber to 3 va7100 disk arrays.

We have on large oracle production db and 3 smaller oracle db's. I am mainly concerned that the large oracle production db get the most bang for the buck regarding performance.

Is there a recommendation on how to create the LUNs and lvols for this oracle db in order to acheive this?

Can anyone point me to documentation regarding LUN creation for this type array - I know how to create them, just not strategies regarding performance.

Finally, is there some way to check bytes per second performance for a given LUN (besides dd)? I've looked at armperf but I'm not sure what metric throughput is reporting in seconds (bytes, etc?).

Any help would be appreciated.

tx,
C

[James R. Ferguson]

Hi Charles:

Essentially I'd create my logical volumes with distributed extents (see 'man lvcreate' distributed allocation) so that allocation of these extents proceeds round-robin across all members of the physical sets.

Then, assuming two alternate links to each physical volume, I'd define a primary pv-link from controller-1 with an alternate link from controller-2 for half the physical disks. On the other half of the physical disks I invert the primary and alternate links relationships to the controllers. Since LVM doesn't load-balance across pv-links, at least this arrangement provides high-availability and separates the channel loads during normal operations.

In addition, I'd mount the database filesystems with the 'mincache=direct,con
vosync=direct' mount options to maximize performance. Remember that the use of these options requires the Online JFS license.

As for monitoring performance, I'd use 'glance'.

Regards!

...JRF...

[harry d brown jr]

The easy one first: get glance/measureware and perfview to monitor you system performance - sar, iostat, and vmstat are old world utilities (I used them over 12 years ago, now I'm grown up ;-)).

The more difficult one: You have auto raid right? You can't really "force" things to go somewhere, sometimes you just have to let them do it. With glance/measureware you'll be able to determine if you have hot (heavily used) fibre ports.

live free or die
harry
http://www.hp.com/cposupport/manual_set/lpg28924.pdf

[Charles McCary]

Guys,

Couple of quick questions:

1) Is there an easy way with glance to get a bytes per second for a particular lun?

2) Any way to tell if I already have online JFS?

3) What are the advantages to mounting with the options James recommends above? What are the disadvantages?

I have implemented the pri / alt then alt / pri strategy for disks in the past so I am familiar with that, just wondering would striping be beneficial in this case?

thanks again.

C

[James R. Ferguson]

Hi Charles:

1) I don't think Glance is going to deliver the statistics you want on an individual LUN basis.

2) To discover if you have OnlineJFS, do:

# swlist|grep -i onlinejfs

3) The man pages for 'mount_vxfs' in conjunction with Knowledge Base document #KBRC00007737 (attached) offer explanations of the various mount options and the tradeoffs between data integrity and performance.

[James R. Ferguson]

Hi (again) Charles:

Sorry, my attachment didn't work for some reason and I fat-fingered the ENTER key before I finished, so:

From KBC document #KBRC00007737 (dated August 21, 2001)

/begin_quote/

HPUX OS: 10.20, 11.0 Online JFS 3.1

-o delaylog ??? Intent log writes are asynchronous. ???Double??? write will still occur but the process does not block while the intent log is being written to ?? potential performance increase.

-o tmplog ??? Intent log writes are delayed; recent changed will be lost if the system crashes. This option is recommended for temporary file systems.

-o mincache=direct ??? All reads and non O_SYNC writes are unbuffered. This degrades performance. The trade-off is to reduce the need for pages in buffer cache versus process blocking. Use for large I/O direct from the application.

-o mincache=tmpcache ??? Disable delayed writes and extent clears when file is extended; explicit fsync required to post changes. The trade-off is data integrity versus performance. This option is useful for temporary files.

-o convosync=direct ??? Converts reads and O_SYNC writes to unbuffered. Improve the performance. The trade-off is between increased
performances when source code is not available versus possible loss of data integrity.

-o nodatainlog ??? Posts O_SYNC writes of the data directly to the file. Improve performance. The trade-off is a fewer writes with possibly increased head movement versus double writes with less head moves.

Note: In order to use these options, customer must have the OnlineJFS.

/end_quote/

Regards!

...JRF...

[Carlos Sotelo Ibarra_1]

A possible strategy would be to set up two of your VA's in RAID 1/0 mode. Put your LUN's with the most hits on those two VA's, and use the third one for AutoRaid storage (and for the smaller (test?) databases).
I'm assuming you have plenty of available space, since RAID 1/0 will leave you with about 2/3 the space you would have using AutoRaid.
If space is at a premium, try setting up at least one of your VA's in RAID 1/0 and make sure you put your indexes there...
Best regards.