FAQ
Is that true if you are using external redundancy?

On Fri, Aug 13, 2010 at 7:49 AM, David Robillard
wrote:
Hello George,

One thing to keep in mind with ASM is that all LUNs in your disk
groups must be of equal size.
So if you use, say, 100 GB LUNs with ASM. Then when your database
needs more storage, you'll need to add a 100 GB LUN to your disk
group.

There was an interesting presentation on ASM on
http://www.oracleracsig.org. Do a search for %ASM% in the documents
section of the site.

HTH,
David
--
http://www.freelists.org/webpage/oracle-l

--
Andrew W. Kerber

'If at first you dont succeed, dont take up skydiving.'

--
http://www.freelists.org/webpage/oracle-l

Search Discussions

  • David Robillard at Aug 13, 2010 at 2:32 pm
    Hello Andrew,
    Is that true if you are using external redundancy?
    Yes. You need LUNs of equal size for all types of redundancy with ASM.

    When you use either high or normal redundancy, what you do is simply
    activate the mirroring capbability of ASM. While if you use external
    redundancy, you don't use it. But in all three types of redundancy,
    ASM prefers LUNs of equal sizes.

    Note that you're not forced to use LUNs of equal sizes. ASM will not
    complain. But performance will suffer and you might end up wasting
    disk space.

    So in the end, you're better off using LUNs of equal sizes;)

    David
    On Fri, Aug 13, 2010 at 7:49 AM, David Robillard wrote:


    Hello George,

    One thing to keep in mind with ASM is that all LUNs in your disk
    groups must be of equal size.
    So if you use, say, 100 GB LUNs with ASM. Then when your database
    needs more storage, you'll need to add a 100 GB LUN to your disk
    group.

    There was an interesting presentation on ASM on
    http://www.oracleracsig.org. Do a search for %ASM% in the documents
    section of the site.

    HTH,
    David
    --
    http://www.freelists.org/webpage/oracle-l
  • Jeremy Schneider at Aug 19, 2010 at 3:53 pm
    IMHO, the big question revolves around capacity management: what if you
    need to expand an existing diskgroup? Generally I've seen two strategies:

    Storage-based capacity management.

    When possible, use a single LUN per diskgroup. (More only if exceeding
    ASM limitations - but really try to avoid this.) The storage admin -
    who knows a lot about this sort of thing - can be responsible for
    keeping a balanced configuration. Last time I was involved in setting a
    large-scale strategy for ASM was about 1.5 years ago. At that time,
    during my conversations with storage guys, it seemed that their storage
    systems really didn't handle LUN expansion very well for heavy workloads
    and resulted in data being a bit unevenly spread (and thus more
    potential hotspots). But we used this strategy at a smaller company I
    worked with; it works quite nicely for smaller environments that aren't
    very I/O intensive because it's very simple and easy to manage.

    One note... there might be some snags with partition tables on Linux and
    hot resizing. The 11.2 docs claim that ASM will only detect
    partitions. ASMlib might negate that. Test first. :) I think that
    this is really a great option for small and mid-size environments.

    2) VolumeManager-based capacity management.

    For very large/intensive environments I think this is the preferred
    approach. Historically there was an OS-based dynamic volume manager -
    but it's really best NOT to layer ASM on top of these. (I've had a heck
    of a time convincing OS teams at large orgs about this!!) I think I
    remember some places in the Oracle docs that reinforce this
    recommendation too. ASM *is* a volume manager, best not to layer two
    volume managers on top of each other. Makes troubleshooting a bear.

    With VolMgr-based capacity management, you choose one or several
    "standard" storage building-block configurations. For example, 50G
    "type A" LUNs (where "type A" refers to a specific underlying disk
    type). The storage guy only gives you storage in 50G chunks. If you
    want a 2TB volume then you request 40 of them. The policy says that you
    can't mix underlying storage types in a single volume/DiskGroup. At one
    company I've worked with, they had gold, silver and bronze storage with
    different chargeback rates. Clever naming scheme I think - and helped
    app teams understand what they were requesting. :)

    But for VolumeManager-based capacity management, you need a much better
    grasp of your requirements so you can properly architect the
    building-block configuration. There isn't one correct answer.

    As far as underlying storage config -- I am a proponent of the BAARF
    initiative, but otherwise I think you can work with the storage team and
    let them be the experts. Make sure they know your stripe size. (Oracle
    defaults to 1MB but explicitly recommends a 4MB stripe size in the 11.2
    docs! And you can go bigger for DWs.)

    Hope this helps a little,
    Jeremy

    Jeremy Schneider wrote:
    Sorry for the late response...

    This is not true. All LUNs do not have to be the same size in ASM.

    However, it is a best practice (and I have recommended it to people
    before). Mainly because it's quite easy to mess things up with ASM and
    storage if everything isn't the same in a diskgroup.

    But the actual important thing is not size - it's that the underlying
    storage is balanced. ASM stripes based on capacity. If two LUNS are
    the same size but one uses 7200 rpm drives and the other uses 15000 rpm
    drives, then this can cause difficult-do-diagnose performance oddities.
    (Not to mention different RAID levels!!) But if two LUNS are different
    sizes but both are RAID10 arrays of the exact same size/speed disks,
    then actually ASM will handle it quite well and the data will end up
    being spread evenly across all disk heads. There's storage network
    pipes to think about too, but that's not usually an issue because a
    single LUN typically is a small percentage of the traffic.

    -Jeremy


    David Robillard wrote:
    Hello George,

    One thing to keep in mind with ASM is that all LUNs in your disk
    groups must be of equal size.
    So if you use, say, 100 GB LUNs with ASM. Then when your database
    needs more storage, you'll need to add a 100 GB LUN to your disk
    group.

    There was an interesting presentation on ASM on
    http://www.oracleracsig.org. Do a search for %ASM% in the documents
    section of the site.

    HTH,
    David
    --
    http://www.ardentperf.com
    +1 312-725-9249

    Jeremy Schneider
    Chicago

    --
    http://www.freelists.org/webpage/oracle-l

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouporacle-l @
categoriesoracle
postedAug 13, '10 at 12:57p
activeAug 19, '10 at 3:53p
posts3
users3
websiteoracle.com

People

Translate

site design / logo © 2022 Grokbase