White Papers

SC Series array and Oracle storage management
71 Dell EMC SC Series: Oracle Best Practices | CML1114
For improved I/O bandwidth, create disk groups with an even number of LUNs having the same performance
characteristics and capacity, with LUNs evenly distributed between the dual SC controllers. Under normal
conditions, the LUNs should also belong to the same SC storage type, SC storage profile, and have the same
SC volume characteristics. An even number of LUNS per disk group also allows the database server to take
advantage of ASM stripe and Mirror Everything (S.A.M.E) methodology, and allows throughput and IOPS be
distributed between dual SC controllers. If two LUNS per disk group do not satisfy database capacity
requirements, consider initially creating larger LUNs. Dell EMC recommends creating disk groups with fewer
larger volumes rather than many small volumes. For information on maximum LUN sizes for ASM see section
3.25. In Oracle’s ASM Administrator’s guides, Oracle recommends the number of LUNs per ASM disk group
be at least equal to four times the number of active I/O paths. This may not be necessary for all environments
and should be evaluated before implementing.
For LUNs intended for ASM, there are several tools, at the OS level, that can be used to manage them and
provide consistent device naming and permission persistency: ASMLib, ASM Filter Driver (ASMFD), and
UDEV. Each will be discussed in sections 6.2, 6.3, and 6.4 respectfully.
Starting with Oracle 11g, ASM disks are owned by the Grid Infrastructure (GI) owner which belongs to system
group OSASM. Any user belonging to group OSASM, can read and write ASM disks. In some cases, this can
be a concern and can lead to a data security breach and possible accidental data corruption of the ASM
disks. In situations like this, ASMFD can be used to mitigate these concerns from occurring. In the 12c ASM
Administrator’s guide, Oracle recommends using ASMFD.
Benefits of using ASM
Benefit
Description
Simplifies storage administration
ASM is essentially a volume manager and integrated cluster files
system, so it eliminates the need for third-party volume managers
and file systems. Additionally, there is no need to specify and
manage filenames. Wherever a file is traditionally specified in
Oracle, an ASM disk group can be specified instead. Every new file
automatically gets a new unique name. This prevents using the
same filename in two different databases. Disk group naming
avoids using two different names for the same file.
Provides storage reliability features
and database availability
A reliability policy is applied on a file basis, rather than on a volume
basis. Hence, the same disk group can contain a combination of
files protected by mirroring, parity, or not protected at all.
Improved and predictable
performance
ASM maximizes performance by automatically distributing
database files across all disks in a disk group while removing the
need for manual I/O tuning (spreading out the database files to
avoid hotspots). It has the performance of raw disk I/O without the
inconvenience of managing raw disks. It also eliminates the
overhead at the file system layer. Unlike logical volume managers,
ASM maintenance operations do not require that the database be
shut down. This allows adding or dropping disks while the disks are
in use.
Improved storage flexibility and
scalability
ASM helps DBAs manage a dynamic database environment by
allowing them to increase or decrease storage allocation without a
database outage.