Once I've got in trouble when striping conflicted with each other.
It was for redo logs that are striped with fine striping in ASM (128K)
and this collided with stripe size of underlying volume so that one
disk was usually a bottleneck. But that's rather an exception.
I can imagine (and see it "on the paper") it's also possible to have
collision with other 1 MB stripe size but I haven't experienced that.
On the other hand, I should admit that statement "ASM works best if
you can avoid striped volumes" is *too* bold perhaps. :)
I should have said *usually* the best. One reason is that no stripe
collision would be possible. Another reason is that it's easy to
provision space to disk group (add/remove disks) providing that all
disks are the same. With chunks taken from the common RAID pool you
have all chances to get one LUN from a more loaded pool. Another
"unfortunate" placement would be to get a chunk from beginning of the
disks in the pool and another chunks from the end - you would have
different performance from them but most important it would force disk
head jump over the whole disk back and force.
Also, I admit that there are arguably different stripe sizes that
better fit certain IO patterns and that might not fit within two
standard 128K and 1M stripe sizes so in some rare cases striping
behind ASM might be appropriate. I've personally seen that 64K stripe
size was the best for one case where we were able to compare it with
all others on the real workload. However, this brings additional
things to keep in mind while provisioning the space and, to some
extent, defeats the main benefit of ASM - simplified storage
management.
A very good paper I can point to
http://www.oracle.com/technology/products/database/asm/pdf/take%20the%20guesswork%20out%20of%20db%20tuning%2001-06.pdf
It has more details and, actually, benchmark there points to even
slight increase of performance with introduction of hardware striping.
But those are artificial tests and ideal layout used while in the real
life storage admins tend to abstract themselves and, of course, DBAs
from physical layout.
On 7/10/07, Randy Johnson <randyjo@xxxxxxxxxxxxx> wrote:
> Thanks Alex. Can you provide some documentation to support your "no SAN
> striping" point?
>
> -Randy
>
>
> Randy Johnson
> Sr. Technical Consultant
> Enkitec, LLP
>
> Office ..... 817-255-3580
> Mobile .... 817-564-6583
> Email ..... randy.johnson@xxxxxxxxxxx
>
>
> -----Original Message-----
> From: gorbyx@xxxxxxxxx [mailto:gorbyx@xxxxxxxxx] On Behalf Of Alex
Gorbachev
> Sent: Monday, July 09, 2007 5:30 PM
> To: randyjo@xxxxxxxxxxxxx; oracle-l@xxxxxxxxxxxxx
> Subject: Re: Creation of ASM Disk Group on Solaris 10 ?
>
> Good answer for RTFM question Randy.
> Just a little comment about striping over striping. ASM works best if
you
> can avoid striped volumes but, instead, can give separate physical
spindle
> as the LUN. This is how it was designed to work.
> Unfortunately, in real life storage admins often can't be bothered.
> :-(
>
>
> On 7/9/07, Randy Johnson <randyjo@xxxxxxxxxxxxx> wrote:
> > Vivek,
> > This is the kind of question that if you have to ask you are not ready
> > for the answer. The best advice I could give you is to read Nitin
> > Vengurlekar's "ASM Best Practices" white paper and refer you to
> > Oracle's Cluster Ready ServicesInstallation Guide. If you've never
> > done this before you should brace yourself for some heavy reading.
> >
> > In short to answer your questions the raw devices (LUN's) you want to
> > use for ASM must be shared and visible to all nodes. This is generally
> > done using HBA (host bus adapter) cards that allow your servers to
> > "see and interact with" the SAN storage array. There are some
> > specifics in configuring ASM on Solaris (which slices you can/should
> > use) and which slice to never use. Regarding commands for SAME. This
> > is done by having your storage administrator stripe the volumes across
> several physical devices.
> > Then you as the DBA come through and configure your ASM volume groups
> > as a combination of these "striped" LUN's. In other words the LUNS are
> > striped on the SAN and the ASM Diskgroups provide a second layer of
> striping.
> >
> > -Randy
> >
> >
> >
> > Randy Johnson
> > Sr. Technical Consultant
> > Enkitec, LLP
> >
> > Office ..... 817-255-3580
> > Mobile .... 817-564-6583
> > Email ..... HYPERLINK
> > "mailto:randy.johnson@xxxxxxxxxxx"randy.johnson@xxxxxxxxxxx
> >
> >
> >
> > _____
> >
> > From: oracle-l-bounce@xxxxxxxxxxxxx
> > [mailto:oracle-l-bounce@xxxxxxxxxxxxx]
> > On Behalf Of VIVEK_SHARMA
> > Sent: Monday, July 09, 2007 3:09 AM
> > To: oracle-l@xxxxxxxxxxxxx
> > Subject: Creation of ASM Disk Group on Solaris 10 ?
> >
> >
> >
> > Folks
> >
> >
> >
> > Need to Setup a 2 Instance ASM-RAC Database from scratch for an
> > internal Test Benchmark.
> >
> >
> >
> > * What Commands are used to create an External ASM Disk Group on
> > Solaris 10?
> >
> > * Any Additional Solaris Commands to make the SAME Disk Group
Visible
> > to BOTH SUN Nodes?
> >
> >
> >
> > NOTE - Disk Group to use External Hardware RAID (10) provided by the
> > Storage Box
> >
> >
> >
> > Oracle 10gR2 on Solaris 10
> >
> >
> >
> > Any Docs, Links will help
> >
> >
> >
> > Cheers & Thanks indeed
> >
> >
> >
> > Vivek
> >
> >
> >
> >
> >
> >
> >
> > **************** 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***
> >
> >
> >
> > No virus found in this incoming message.
> > Checked by AVG Free Edition.
> > Version: 7.5.476 / Virus Database: 269.10.2/891 - Release Date:
> > 7/8/2007
> > 6:32 PM
> >
> >
> >
> > No virus found in this outgoing message.
> > Checked by AVG Free Edition.
> > Version: 7.5.476 / Virus Database: 269.10.2/891 - Release Date:
> > 7/8/2007
> > 6:32 PM
> >
> >
>
>
> --
> Alex Gorbachev, Oracle DBA Brewer, The Pythian Group
> http://www.pythian.com/blogs/author/alex http://blog.oracloid.com BAAG
party
> - www.BattleAgainstAnyGuess.com
>
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.5.476 / Virus Database: 269.10.2/891 - Release Date: 7/8/2007
> 6:32 PM
>
>
> No virus found in this outgoing message.
> Checked by AVG Free Edition.
> Version: 7.5.476 / Virus Database: 269.10.2/891 - Release Date: 7/8/2007
> 6:32 PM
>
>
>
--
Alex Gorbachev, Oracle DBA Brewer, The Pythian Group
http://www.pythian.com/blogs/author/alex http://www.oracloid.com
BAAG party - www.BattleAgainstAnyGuess.com
--
//www.freelists.org/webpage/oracle-l
