Lascon StorageCookie PolicyContact usSearch this Site

HOME
Backups

CLOSE






Hardware

CLOSE






Mainframe

CLOSE





Windows

CLOSE




Databases

CLOSE





Strategy
 CLOSE


Click on the grey buttons above to open an overlay menu that shows the areas in each major section.
Click on the yellow buttons to the right to move between pages in this area.

ORACLE ASM

Overview
An Oracle database will typically consist of hundreds of files, and managing these files can be a problem,
especially for multiple databases or very large databases. Sometimes files need to be placed to ensure
adequate performance or ensure a service will survive a disk failure, and this requires detailed knowledge
of the underlying disk system to ensure the files are placed correctly.
ASM (Automatic Storage Management) is designed to simplify this management by combining disks into
groups, so the administrator manages a small number of disk groups, rather than managing individual
disks or files. ASM also looks after I/O balancing by evenly distributed files to eliminate hot spots and so
to optimise the database performance. Oracle claims that ASM performance is comparable to the
performance of raw devices.
Templates are used to allocate new disks, different templates select different striping and mirroring
options, and ASM does the rest.
Oracle uses ASM metadata to control the disk groups and stores that metadata resides within the disk
group. This ASM metadata includes the following:
 The disks that belong to a disk group
 The amount of space that is available in a disk group
 The file names of the files in a disk group
 The location of disk group data file extents
 A redo log that records information about atomically changing metadata blocks
 Oracle ADVM volume information
Oracle ASM is essentially a volume manager and file system designed for Oracle Database files. It
supports both single-instance Oracle Database and Oracle RAC clusters. Oracle stores the files it needs
to operate in ASM disk groups, including those listed on the Oracle files page. Each Oracle ASM file is
contained within a single Oracle ASM disk group.
ASM runs as a separate instance and it must be started before the database instance, otherwise the
database will not be able to find its files. RMAN is the only way to backup ASM disks.
ASM uses a kernel module called Oracle ASM Filter Driver or Oracle ASMFD, which intercepts all I/O that
is directed to Oracle ASM disks. Oracle ASM uses the filter driver to validate write I/O requests to Oracle
ASM disks. If any of these I/Os are invalid, for example if they come from outside of Oracle, then ASMFD
will reject them. This prevents external writes from corrupting your databases. ASMFD also simplifies the
configuration and management of disk devices by eliminating the need to rebind disk devices used with
Oracle ASM each time the system is restarted.
Oracle 11g introduced the ASM Cluster File System (ACFS), which is touted as a 'multi-platform, scalable
file system, and storage management technology that extends Oracle ASM functionality to support
customer files maintained outside of Oracle Database'. It supports all those non-database files that an
Oracle database needs to operate, such as logs, trace files, executables and configuration files. It also
supports general-purpose application files. This non-database data can be accessed by using native
operating system file system APIs and command-line interface tools.
The advantage of doing this is that Oracle ACFS uses 64-bit file and file system data structure sizes
which means that it could support exabyte size files and file systems on 64 bit platforms. Other
advantages are built in performance tuning, metadata checksums for data intergrity and journaling for fast
recovery.

Disk Groups
Disk groups are the ASM unit of management and basically consist of groups of disks that are lumped
together and managed as a single entity. Data is striped within a disk group and should be mirrored
between disk groups.

Failure Groups
Failure groups are groups of disks that can potentially all fail at the same time, for example, because they
share the same SCSI controller. If your ASM redundancy policy is for 2-way mirroring, then the data on
each side of the mirror must be on different failure groups. Then if any component fails in one failure
group, the data on the other failure group is not affected. Triple redundancy requires three failure groups,
and ASM can then tolerate concurrent failures in any two groups.
Flex Disk Groups were introduced in Oracle 12. In previous versions, redundancy options like striping and
mirroring applied to the whole disk group. For an example, the disk group could be 2-way mirrored. Once
the was defined, it could not be changed, so if you needed 3-way mirroring for a special database you
had to define a new disk group.
With a flex disk group, you can apply different redundancy levels by file type or database, all in the same
group. Also, if you change your mind, you can alter the redundancy level after creation.
ASM with Flex Disk Groups has the ability to create instantaneous clones of databases without needing
any storage subsystem snapshot technology. If a storage administrator had to do this using snapshots,
they would need to work out exactly what files were required, where they were located, then snap all the
bits and pieces. ASM can do all the work itself. It does this by using the ASM redundancy components
that ASM used to protect a database from data loss due to hardware errors. As Flex Disk Groups can
have up to five redundant copies, ASM is able to split one of these redundant copies off, and so create an
independent copy of the database. The process sounds very similar to the EMC approach for creating a
BCV, where the BCV needs to be created first, before it can be split off as an independent copy.
From Oracle Database 12c, ASM added a new feature called Extended Disk Groups. Previously, an
extended Oracle RAC system could have up to two Failure Groups, though they could be in different
datacenters. Extended Disk Groups are an extension of Flex Disk Groups, and now you can have multiple
Failure Groups, such as mirroring within your primary datacenter, combined with mirroring to a remote
datacenters. You could also mirror between three datacenters.
Oracle Database 19c added parity protection as extra option for write-once files such as archive logs and
backup sets. Previously, these files could be either unprotected or mirrored. Parity protection gives the
option of protecting these files without incurring the full expense of mirroring. Parity protection is not
available for databases or other read-write files.
How much saving you get depends on how many failure groups you have. You must have at least three
failure groups, and three or four failure groups will save 50% capacity over mirroring, while five or more
failure groups have four data extents and so save 75% capacity.
If you modify a file group from mirroring to parity, existing files are not reallocated, so there will be no
space saving on them, but new files will be added in the new configuration.

Templates
Templates are used to simplify creating files and mapping them to the correct disk group. Templates
consist of attributes that a file can have, for example, UNPROTECTED or MIRROR, which are used to
describe no redundancy or a 2 way mirror. COARSE and FINE are a little less obvious, they describe the
granularity used for striping. Fine-grained striping is appropriate for log files as they require low latency.
This allows larger I/Os to be split and processed in parallel by multiple disks and so speeding up
response times.
ASM provides a set of default templates, for example ONLINELOG provides file redundancy and striping
for redo log files. It is also possible to write your own templates for your own site needs

Redundancy and Striping

ASM stripes its files across all the disks that belong to a disk group using a version of RAID 3, RAID3 is
used because it is much easier to add or remove disk from a RAID3 system than RAID5 or RAID6.
Ideally, all the disks in a disk group should be the same size.
However, don't confuse this striping with redundancy. The striping is for performance reasons,
redundancy involves mirroring data between disk groups. Disk groups can have no external redundancy,
two-way mirroring or three-way mirroring. These last two are often called normal and high mirrors. If
possible, the disk groups should run under different controllers to provide failover for controller errors.
ASM automatically handles changes to the disk count within a group, whether this is down to a disk
failure, or disks being added or removed, and does this while the database is operating. The rebalancing
process happens in the background with minimal impact on database performance.
If you add a disk, ASM will automatically redistribute the data so that it is evenly spread across all disks in
the disk group, including the new disk. When you request to remove a disk, ASM will first relocate all the
file extents from the disk being removed to the other disks in the disk group. The data is spread evenly to
conserve the I/O balance.

Aliases
ASM gives DBAs the ability to refer to ASM files with user-friendly names, rather than the fully qualified
ASM filenames. This is bad news for a storage person as if they get problems you then have to translate
between what they call the file, and the real file name. If you get problems locating a file, ask your DBA to
check if he is using an alias or not.

Oracle Storage
 Oracle Files
 Oracle RMAN
 Oracle RAC
 Dataguard
 Oracle ASM

Lascon updTES
I retired 2 years ago, and so I'm out of touch with the latest in the data storage world. The Lascon site has
not been updated since July 2021, and probably will not get updated very much again. The site hosting is
paid up until early 2023 when it will almost certainly disappear.
Lascon Storage was conceived in 2000, and technology has changed massively over those 22 years. It's
been fun, but I guess it's time to call it a day. Thanks to all my readers in that time. I hope you managed
to find something useful in there.
All the best
DISCLAIMER - By entering and using this site, you accept the conditions and limitations of use
Click here to see the Full Site Index       Click here to see the Cookie Policy       Click here to see
the Privacy Policy                             ©2019 and later, A.J.Armstrong