Scribd
Upload
156 views

Automatic Storage Management

Oracle ASM uses disk groups to store and manage database files across multiple disks. Disk groups contain metadata and allocate storage in allocation units and extents which are distributed and mirrored across disks and failure groups. ASM provides redundancy, performance and scalability benefits over traditional storage.

Uploaded by

Vratkatha
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
156 views

Automatic Storage Management

Oracle ASM uses disk groups to store and manage database files across multiple disks. Disk groups contain metadata and allocate storage in allocation units and extents which are distributed and mirrored across disks and failure groups. ASM provides redundancy, performance and scalability benefits over traditional storage.

Uploaded by

Vratkatha
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 8

Brief Notes on Automatic storage Management

Oracle ASM uses disk groups to store data files. An ASM disk group is a collection of
disks managed as a unit. Within a disk group, ASM exposes a file system interface for
Oracle database files. The content of files that are stored in a disk group is evenly
distributed to eliminate hot spots and to provide uniform performance across the
disks. The performance is comparable to the performance of raw devices. [From
Oracle Automatic Storage Management Administrators Guide 11g Release 2].

ASM Disk Groups


An ASM disk group consists of one or more disks and is the fundamental object that
ASM manages. Each disk group is self contained and has its own ASM metadata. It is
that ASM metadata that an ASM instance manages.
The idea with ASM is to have small number of disk groups. In ASM versions before
11.2, two disk groups should be sufficient one for datafiles and one for
backups/archive logs. In 11.2 you would want to create a separate disk group for ASM
spfile, Oracle Cluster Registry (OCR) and voting disks provided you opt to place those
objects in an ASM disk group.

ASM Disks

Disks to be used by ASM have to be set up and provisioned by OS/storage


administrator before ASM installation/setup. Disks can be local physical devices (IDE,
SATA, SCSI, etc), SAN based LUNs (iSCSI, FC, FCoE, etc) or NAS/NFS based disks. Disks
to be used for ASM should be partitioned. Even if the whole disk is to be used by ASM,
it should have a single partition.
The above is true for all environments except for Exadata where ASM makes use
of grid disks, created from cell disks and presented to ASM via LIBCELL interface.
An ASM disk group can have up to 10,000 disks. Maximum size for an individual ASM
disk is 2 TB. Due to bug 6453944, it is possible to add disks over 2 TB to an ASM disk
group. The fix for bug 6453944 is in 10.2.0.4, 11.1.0.7 and 11.2. MOS Doc ID 736891.1
has more on that.
ASM looks for disks in the OS location specified by ASM_DISKSTRING initialization
parameter. All platforms have the default value, so this parameter does not have to
be specified. In a cluster, ASM disks can have different OS names on different nodes.
In fact, ASM does not care about the OS disk names, as those are not kept in ASM
metadata.

ASM Files
Any ASM file is allocated from and completely contained within a single disk group.
However, a disk group might contain files belonging to several databases and a single
database can have files in multiple disk groups.

ASM can store all Oracle database file types datafiles, control files, redo logs,
backup sets, data pump files, etc but not binaries or text files. In addition to that,
ASM also stores its metadata files within the disk group. ASM has its own file
numbering scheme independent of database file numbering. ASM file numbers under
256 are reserved for ASM metadata files.
ASM Cluster File System (ACFS), introduced in 11.2, extends ASM support to database
and application binaries, trace and log files, and in fact any files that can be stored
on a traditional file systems. And most importantly, the ACFS is a cluster file system.

ASM Allocation Units


An ASM allocation unit (AU) is the fundamental space unit within an ASM
disk group . Every ASM disk is divided into allocation units.
When a disk group is created, the allocation unit size can be set with the disk
group attributeAU_SIZE (in ASM versions 11.1 and later). The AU size can be 1, 2, 4, 8,
16, 32 or 64 MB. If not explicitly set, the AU size defaults to 1 MB (4MB in Exadata).
AU size is a disk group attribute, so each disk group can have a different AU size.
ASM Extents
An ASM extent consists of one or more allocation units. An ASM file consists
of one or more ASM extents.

We distinguish between physical and virtual extents. A virtual extent, or an extent set,
consists of one physical extent in an external redundancy disk group, at least two
physical extents in a normal redundancy disk group and at least three physical extents
in a high redundancy disk group.
Before ASM version 11.1 we had uniform extent size. ASM version 11.1 introduced the
variable sized extents that enable support for larger data files, reduce (ASM and
database) SGA memory requirements for very large databases, and improve
performance for file create and open operations. The initial extent size equals the disk
group AU_SIZE and it increases by a factor of 4 or 16 at predefined thresholds. This
feature is automatic for newly created and resized data files with disk group
compatibility attributes COMPATIBLE.ASM and COMPATIBLE.RDBMS set to 11.1 or
higher.
The extent size of a file varies as follows:

Extent size always equals the disk group AU_SIZE for the first 20,000
extent sets
Extent size equals 4*AU_SIZE for the next 20,000 extent sets
Extent size equals 16*AU_SIZE for the next 20,000 and higher extent sets

Together combined allocation unit and Extent size the distribution of extents is like
somewhat below, Each extent is copied /created in each disk evenly,
Note the size of the extents may vary in the disks but in the files & Also observe the
Cyan color boxes are the ASM Metadata content.

ASM Mirroring
ASM mirroring protects data integrity by storing multiple copies of the same data on
different disks. When a disk group is created, ASM administrator can specify the disk
group redundancy as follows:

External no ASM mirroring

Normal 2-way mirroring

High 3-way mirroring

ASM mirrors extents it does not mirror disks or blocks. ASM file mirroring is the
result of mirroring of the extents that constitute the file . In ASM we can specify
the redundancy level per file. For example, one file in a normal redundancy disk group,
can have its extents mirrored once (default behavior). Another file, in the same disk
group, can be triple mirrored provided there are at least three failgroups in the disk
group. In fact all ASM metadata files are triple mirrored in a normal redundancy disk
group provided there are at least three failgroups.
ASM Failgroups
ASM disks within a disk group are partitioned into failgroups (also referred to as failure
groups or fail groups). The failgroups are defined at the time the disk group is created.
If we omit the failgroup specification, then ASM automatically places each disk into its
own failgroup. The only exception is Exadata, where all disks from the same storage
cell are automatically placed in the same failgroup.
Normal redundancy disk groups require at least two failgroups. High redundancy disk
groups require at least three failgroups. Disk groups with external redundancy do not
have failgroups.
When an extent is allocated for a mirrored file, ASM allocates a primary copy and a
mirror copy. Primary copy is store on one disk and the mirror copy on some other
disk in a different failgroup.

When adding disks to an ASM disk group for which failgroups are manually specified, it
is imperative to add the disks to the correct failgroup.
The brown colour boxes are metadata headers of the disk, each disk contain the
metadata header in failuregroup containing the distribution of extents spread across in
the disk
Further, The Red color boxes are the extents in failure group 1, called as primary
extents and the purple ones are the secondary extents a mirrored copy of the primary
extents.
In case of High redudancy the extents of secondary were two as it contains three
failure groups.

You might also like