Comparation between ASM note [ID 373242.1] and note [ID 452924.1]

Question:
Oracle Support on the note “Lun Size And Performance Impact With Asm [ID 373242.1]” and on the note “How to Prepare Storage for ASM [ID 452924.1]” say that in other things:

– Maximize the number of disks in a disk group for maximum data distribution and higher I/O bandwidth
– Size alone should not affect the performance of a LUN. The underlying hardware is what counts.
There is no magic number for the LUN size
– For larger LUNs it is recommended using a large ALLOCATION UNIT.

The provieder of the Storage EMC-Vmax say that the LUNS size can be 200 GB for database OLTP.

We believe that the premise or EMC_Vmax contradicts to ORACLE so instead of maximize the disks they pretend minimize the disks
of the DISK GROUP.

You believe that this is to be true for Storage EMC-Vmax.

Answer:
As mentioned in the document 373242.1.LUN size alone should not affect the performance.

Size alone should not affect the performance of a LUN. The underlying hardware is what counts. There is no magic number for the LUN size. Seek the advice of the storage vendor to recommend the best configuration from a raid 1 or 5 perspective for performance and availability since this may vary between vendors. Given a database size and storage hardware you have available, our best practice recommends creating larger LUNs (if possible to reduce LUN management for the sys admins) and create LUNs from separate set of storage arrays (drives) so that LUNs are not sharing drives if possible.

For larger LUNs it is recommended using a large ALLOCATION UNIT.

Comments

  1. admin says

    Lun Size And Performance Impact With Asm

    QUESTION

    What is the maximum LUN size we can use without performance degradation? For example, is 1 TB or 2TB sized LUNs perform the same as 100 GB or 200 GB sized LUNs?

    We are using the ASM feature of Oracle DB 10g release 2 on 64-bit Solaris 9 or Solaris 10.

    Solution

    ANSWER

    Size alone should not affect the performance of a LUN. The underlying hardware is what counts. There is no magic number for the LUN size. Seek the advice of the storage vendor to recommend the best configuration from a raid 1 or 5 perspective for performance and availability since this may vary between vendors. Given a database size and storage hardware you have available, our best practice recommends creating larger LUNs (if possible to reduce LUN management for the sys admins) and create LUNs from separate set of storage arrays (drives) so that LUNs are not sharing drives if possible.

    For larger LUNs it is recommended using a large ALLOCATION UNIT.

  2. admin says

    How to Prepare Storage for ASM

    Applies to:
    Oracle Server – Enterprise Edition – Version: 10.1.0.2 to 11.2.0.2.0 – Release: 10.1 to 11.2
    Information in this document applies to any platform.
    Oracle Server Enterprise Edition – Version: 10.1.0.2 to 11.2.0.2

    ***Checked for relevance on 03-Dec-2010***
    Goal
    This document describes how to prepare your storage sub-system before you configure Automatic Storage Management (ASM). When preparing your storage to use ASM, first determine the storage option for your system and then prepare the disk storage for the specific operating system environment.
    Solution

    A) You can create an ASM diskgroup using one of the following storage resources:

    1) Raw disk partition—A raw partition can be the entire disk drive or a section of a disk drive.
    However, the ASM disk cannot be in a partition that includes the partition table because the
    partition table can be overwritten.

    2) Logical unit numbers (LUNs)—Using hardware RAID functionality to create LUNs is a recommended
    approach. Storage hardware RAID 0+1 or RAID5, and other RAID configurations, can be provided to
    ASM as ASM disks.

    3) Raw logical volumes (LVM)—LVMs are supported in less complicated configurations where an LVM
    is mapped to a LUN, or an LVM uses disks or raw partitions. LVM configurations are not recommended
    by Oracle because they create a duplication of functionality. Oracle also does not recommended
    using LVMs for mirroring because ASM already provides mirroring.

    4) NFS files—NFS files are suitable for testing, but are not a recommended configuration for production environments. Using NFS files with ASM duplicates ASM functionality. Though, NetApp as an NFS vendor certifies its product with ASM. So there are customers using NFS and ASM together.

    B) The procedures for preparing storage resources for ASM are:

    1) Identify or create the storage devices for ASM by identifying all of the storage resource
    device names that you can use to create an ASM disk group. For example, on Linux systems, device
    names are typically presented from the /dev directory with the /dev/device_name_identifier name
    syntax.

    2) Change the ownership and the permissions on storage device resources. For example, the
    following steps are required on Linux systems:

    2.1) Change the user and group ownership of devices to oracle:dba
    2.2) Change the device permissions to read/write
    2.3) On older Linux versions, you must configure raw device binding

    After you have configured ASM, ensure that disk discovery has been configured correctly by setting
    the ASM_DISKSTRING initialization parameter.

    Note: Setting the ownership to oracle:dba is just one example that corresponds to the default
    settings. A non-default installation may require different settings. In general, the owner of the
    disk devices should be the same as the owner of the Oracle binary. The group ownership should be
    OSDBA of the ASM instance, which is defined at installation.

    C) Recommendations for Storage Preparation. The following are guidelines for preparing storage for
    use with ASM:

    1) Configure two disk groups, one for the datafile and the other for the Flash Recovery Area. For
    availability purposes, one is used as a backup for the other.

    2) Ensure that LUNs, which are disk drives of partitions, that ASM disk groups use have similar
    storage performance and availability characteristics. In storage configurations with mixed speed
    drives, such as 10K and 15K RPM, I/O distribution is constrained by the slowest speed drive.

    3) Be aware that ASM data distribution policy is capacity-based. LUNs provided to ASM have the
    same capacity for each disk group to avoid an imbalance.

    4) Use the storage array hardware RAID 1 mirroring protection when possible to reduce the
    mirroring overhead on the server. Use ASM mirroring redundancy in the absence of a hardware RAID,
    or when you need host-based volume management functionality, such as mirroring across storage
    systems. You can use ASM mirroring in configurations when mirroring between
    geographically-separated sites over a storage interface.

    Hardware RAID 1 in some lower-cost storage products is inefficient and degrades the performance of
    the array. ASM redundancy delivers improved performance in lower-cost storage products.

    5) Maximize the number of disks in a disk group for maximum data distribution and higher I/O
    bandwidth.

    6) Create LUNs using the outside half of disk drives for higher performance. If possible, use
    small disks with the highest RPM.

    7) Create large LUNs to reduce LUN management overhead.

    8) Minimize I/O contention between ASM disks and other applications by dedicating disks to ASM
    disk groups for those disks that are not shared with other applications.

    9) Choose a hardware RAID stripe size that is a power of 2 and less than or equal to the size of
    the ASM allocation unit.

    10) Avoid using a Logical Volume Manager (LVM) because an LVM would be redundant. However, thereare situations where certain multipathing or third party cluster solutions require an LVM. In
    these situations, use the LVM to represent a single LUN without striping or mirroring to minimize
    the performance impact.

    11) For Linux, when possible, use the Oracle ASMLIB feature to address device naming and
    permission persistency.

    12) ASMLIB provides an alternative interface for the ASM-enabled kernel to discover and access
    block devices. ASMLIB provides storage and operating system vendors the opportunity to supply
    extended storage-related features. These features provide benefits such as improved performance
    and greater data integrity.

Trackbacks

  1. […] Comparation between ASM note [ID 373242.1] and note [ID 452924.1] […]

  2. […] Comparation between ASM note [ID 373242.1] and note [ID 452924.1] […]

Comment

*

沪ICP备14014813号-2

沪公网安备 31010802001379号