RE: To use SAME or NOT for High End Storage Setup ? .... StripeUnit Size 32 MB Vs. 64 KB ?

GREAT REPLIES MARK, KEVIN, FOLKS. MY REPLIES IN CAPITALS BELOW -----Original Message-----
From: oracle-l-bounce_at_freelists.org
[mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Mark W. Farnham Sent: Monday, May 15, 2006 10:06 PM
To: kevinc_at_polyserve.com; oracle-l_at_freelists.org

Mark Wrote:-

I *think* this means that a LUN has 4 pairwise mirrored disks and that the
stripe width is 256KB (4*64K)
at the hardware level.

CORRECT Since you wrote 32 MB stripe unit size across the 46 LUNs using the Volume
Manager, I *think* this means a stripe WIDTH of 32MB*46, which is huge.(If you meant a stripe WIDTH of 32 MB, then your
stripe unit size is a little less than 3 quarters of a MB.) I also *think* this means that if an object is 16MB in size, then it
has a 50-50 chance of living in one chunk on a single LUN, and likewise a 50-50 chance of being in 2 pieces on two LUNs.
Small objects compared to 32 MB will reside in 1 or 2 LUNs in this configuration, while big objects compared to 32 MB will
be spread across more LUNs.

So if you have hot objects that are relatively small, you've got a good chance they'll be on 1 or 2 LUNs, and it won't take too much bad luck to get several small hot objects on the same LUN.

WILL ANSWER ON OBJECT SIZES IN MY NEXT E-MAIL PLEASE There is a good chance that any such potential hot spots are handled in the
cache, because they only pertain to relatively small objects. Those objects will be in cache if they are hot (unless of course they are
hot with regard to writing).

But you're still only going to see the write degradation if the hot objects
on a single LUN overrun cache and the ability of four drives to keep up DB_WRITER. STORAGE CACHE SIZE IS 128 GB Then again, I'm not sure what overhead you incur if a single read references
multiple LUNs, anyway. At that point it is software volume manager, and it
is
not clear to me whether there is any different penalty from referencing two
physical platters from a single LUN versus the last platter of one LUN and
the
first platter of the next LUN. That would depend on whether the hardware is
capable of overlapping seeks and the chain of software reaching the platter
triggers that capability.

If I'm wrong, we need to clarify your meaning of the terminology as regards
"stripe unit size" with regard to both the hardware LUN creation and the volume
manager creation of volumes as seen at the file system level or raw partition level.

IBM IS RECOMMENDING STRIPE UNIT SIZE OF 32 MB ACROSS THE LUNs. WE HAVE ASKED THEM WHY SO & ARE AWAITING THEIR EXPLANATION. I'm also curious whether you're re-mirroring on the 46 LUNs. I'm guessing
NOT, but I could take your meaning that way from the indicating that you're
using SAME across the 46 LUNs. I *think* you've mirrored pairwise at the underlying hardware level and you're simply creating volumes striped across
46 of the resulting LUNs.

CORRECT .
ADDITIONALLY FILESYSTEM IS JFS2(CIO)

• - -
• - -
• - -

Regards,

mwf

• CAUTION - Disclaimer ***************** This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for the use of the addressee(s). If you are not the intended recipient, please notify the sender by e-mail and delete the original message. Further, you are not to copy, disclose, or distribute this e-mail or its contents to any other person and any such actions are unlawful. This e-mail may contain viruses. Infosys has taken every reasonable precaution to minimize this risk, but is not liable for any damage you may sustain as a result of any virus in this e-mail. You should carry out your own virus checks before opening the e-mail or attachment. Infosys reserves the right to monitor and review the content of all messages sent to or from this e-mail address. Messages sent to or from this e-mail address may be stored on the Infosys e-mail system. ***INFOSYS******** End of Disclaimer ********INFOSYS*** -- http://www.freelists.org/webpage/oracle-l