| Print | Contents | Close |

Oracle Database 11g Architecture

Learning objective

After completing this topic, you should be able to identify the characteristics of elements
of the Oracle Database 11g architecture.

1. The Oracle database

Disclaimer
Although certain aspects of the Oracle 11g Database are case and spacing insensitive, a
common coding convention has been used throughout all aspects of this course.
This convention uses lowercase characters for schema, role, user, and constraint names,
and for permissions, synonyms, and table names (with the exception of the DUAL table).
Lowercase characters are also used for column names and user-defined procedure,
function, and variable names shown in code.
Uppercase characters are used for Oracle keywords and functions, for view, table,
schema, and column names shown in text, for column aliases that are not shown in
quotes, for packages, and for data dictionary views.
The spacing convention requires one space after a comma and one space before and
after operators that are not Oracle-specific, such as +, -, /, and <. There should be no
space between an Oracle-specific keyword or operator and an opening bracket, between
a closing bracket and a comma, between the last part of a statement and the closing
semicolon, or before a statement.
String literals in single quotes are an exception to all of the convention rules provided
here. Please use this convention for all interactive parts of this course.
End of Disclaimer
The Oracle Relational Database Management System (RDBMS) is a database
management system that provides an open, comprehensive, integrated approach to
information management. A database is a collection of data treated as a unit. The
purpose of a database is to store and retrieve related information.
An Oracle Database reliably manages a large amount of data in a multi-user environment
so that many users can concurrently access the same data. This is accomplished while
delivering high performance. At the same time, the database prevents unauthorized
access and provides efficient solutions for failure recovery.

An Oracle Database consists of an instance and its associated databases. The instance
consists of memory structures and background processes. Every time an instance is
started, a shared memory area called the System Global Area (SGA) is allocated and the
background processes are started.
The database consists of both physical structures and logical structures. Because the
physical and logical structures are separate, the physical storage of data can be
managed without affecting access to logical storage structures.
Connection and session are closely related to user process but are very different in
meaning.
A connection is a communication pathway between a user process and an Oracle
Database instance. A communication pathway is established using either of the following
two mechanisms:

available inter-process communication mechanisms on a computer that runs both the user
process and Oracle Database

network software when different computers run the database application and Oracle Database,
and communicate through a network
A session represents the state of a current user login to the database instance. For
example, when a user starts SQL*Plus, the user must provide a valid username and
password, and then a session is established for that user.
A session lasts from the time the user connects until the time the user disconnects or
exits the database application.
In the case of a dedicated connection, the session is serviced by a permanent dedicated
process. The session is serviced by an available server process selected from a pool,
either by the middle tier or by the Oracle shared server architecture.
Multiple sessions can be created and exist concurrently for a single Oracle Database user
using the same username. For example, a user with the username/password of HR/HR
can connect to the same Oracle Database instance several times.
After starting an instance, the Oracle software associates the instance with a specific
database. This is called mounting the database. The database is then ready to be
opened, which makes it accessible to authorized users.
Multiple instances can execute concurrently on the same computer, each accessing its
own physical database.
You can look at the Oracle Database architecture as various interrelated structural
components.

An Oracle instance uses memory structures and processes to manage and access the
database. All memory structures exist in the main memory of the computers that
constitute the database server.
Processes are jobs that work in the memory of these computers. A process is defined as
a "thread of control" or a mechanism in an operating system that can run a series of
steps.

2. Structures and architecture

Oracle Database creates and uses memory structures for various purposes. For example,
memory stores program code being run, data shared among users, and private data
areas for each connected user.
Two basic memory structures are associated with an instance:

System Global Area (SGA)

Program Global Areas (PGAs)

System Global Area (SGA)
The System Global Area (SGA) is a group of shared memory structures, known as SGA
components, that contain data and control information for one Oracle Database instance.
The SGA is shared by all server and background processes. Examples of data stored in
the SGA include cached data blocks and shared SQL areas.
Program Global Areas (PGAs)
The Program Global Areas (PGAs) are memory regions that contain data and control
information for a server or background process. A PGA is non-shared memory created by
Oracle Database when a server or background process is started. Access to the PGA is
exclusive to the server process. Each server process and background process has its own
PGA.
The SGA is the memory area that contains data and control information for the instance.
The SGA includes the following data structures:

database buffer cache

redo log buffer

shared pool

large pool

Java pool

Streams pool
database buffer cache
The database buffer cache caches blocks of data retrieved from the database.

redo log buffer

The redo log buffer caches redo information used for instance recovery until it can be
written to the physical redo log files stored on the disk.
shared pool
The shared pool caches various constructs that can be shared among users.
large pool
The large pool is an optional area that provides large memory allocations for certain large
processes, such as Oracle backup and recovery operations, and I/O server processes.
Java pool
The Java pool is used for all session-specific Java code and data within the Java Virtual
Machine (JVM).
Streams pool
The Streams pool Is used by Oracle Streams to store information required by capture and
apply.
When you start the instance by using Enterprise Manager or SQL*Plus, the amount of
memory allocated for the SGA is displayed.
A Program Global Area (PGA) is a memory region that contains data and control
information for each server process. An Oracle server process services a client's
requests. Each server process has its own private PGA that is created when the server
process is started. Access to the PGA is exclusive to that server process, and the PGA is
read and written only by the Oracle code acting on its behalf.
With the dynamic SGA infrastructure, the size of the database buffer cache, the shared
pool, the large pool, the Java pool, and the Streams pool changes without shutting down
the instance.
The Oracle database uses initialization parameters to create and configure memory
structures. For example, the SGA_TARGET parameter specifies the total size of the SGA
components. If you set SGA_TARGET to 0, Automatic Shared Memory Management is
disabled.
The processes in an Oracle Database system can be categorized into two major groups:

User processes that run the application or Oracle tool code.

Oracle Database processes that run the Oracle database server code. They include server
processes and background processes.
When a user runs an application program or an Oracle tool such as SQL*Plus, Oracle
Database creates a user process to run the user's application. Oracle Database also
creates a server process to execute the commands issued by the user process.

In addition, the Oracle server has a set of background processes for an instance that
interact with each other and with the operating system to manage the memory structures
and asynchronously perform I/O to write data to disk, and perform other required tasks.
The process structure varies for different Oracle Database configurations, depending on
the operating system and the choice of Oracle Database options. The code for connected
users can be configured as a dedicated server or a shared server.
With a dedicated server, for each user, the database application is run by a user process
that is served by a dedicated server process that executes Oracle database server code.
A shared server eliminates the need for a dedicated server process for each connection.
A dispatcher directs multiple incoming network session requests to a pool of shared
server processes. A shared server process serves any client request.
Oracle Database creates server processes to handle the requests of user processes
connected to the instance.
In some situations when the application and Oracle Database operate on the same
computer, it is possible to combine the user process and corresponding server process
into a single process to reduce system overhead.
However, when the application and Oracle Database operate on different computers, a
user process always communicates with Oracle Database through a separate server
process.
Server processes created on behalf of each user's application can perform one or more
of these tasks:

parsing and running SQL statements issued through the application

reading necessary data blocks from data files on disk into the shared database buffers of the
SGA, if the blocks are not already present in the SGA
returning results in such a way that the application can process the information
To maximize performance and accommodate many users, a multi-process Oracle
Database system uses some additional Oracle Database processes called background
processes. An Oracle Database instance can have many background processes.
The background processes commonly seen in non-RAC non-ASM environments can
include these:

Database Writer process (DBWn)

Log Writer process (LGWR)

Checkpoint process (CKPT)

System Monitor process (SMON)

Process Monitor process (PMON)

Recoverer process (RECO)

Job Queue processes

Archiver processes (ARCn)

Queue Monitor processes (QMNn)

Other background processes may be found in more advanced configurations such as
RAC. You can query the V$BGPROCESS view for more information about the background
processes. On many operating systems, background processes are created automatically
when an instance is started.
The files that constitute an Oracle database are organized into

control files

data files

online redo log files

control files
Control files contain data about the database itself that is, physical database structure
information. These files are critical to the database. Without them, you cannot open data
files to access the data within the database.
data files
Data files contain the user or application data of the database, as well as metadata and the
data dictionary.
online redo log files
Online redo log files allow for instance recovery of the database. If the database server
crashes and does not lose any data files, then the instance can recover the database with
the information in these files.
Further Oracle Database files are depicted.

parameter file

password file

backup files

archived redo log files

trace files

alert log file

parameter file
The parameter file is used to define how the instance is configured when it starts up.

password file
The password file allows sysdba/sysoper/sysasm to connect remotely to the database and
perform administrative tasks.
backup files
Backup files are used for database recovery. You typically restore a backup file when a
media failure or user error has damaged or deleted the original file.
archived redo log files
Archived redo log files contain an ongoing history of the data changes redo that are
generated by the instance. Using these files and a backup of the database, you can
recover a lost data file. That is, archive logs enable the recovery of restored data files.
trace files
Each server and background process can write to an associated trace file. When an
internal error is detected by a process, the process dumps information about the error to its
trace file. Some of the information written to a trace file is intended for the database
administrator, whereas other information is for Oracle Support Services.
alert log file
Alert log files are special trace entries. The alert log of a database is a chronological log of
messages and errors. Each instance has one alert log file. Oracle recommends that you
review this periodically.

Question
Which files constitute an Oracle database?
Options:
1.

Archive redo log files

2.

Control files

3.

Data files

4.

Online redo log files

5.

Parameter files

Answer
Control files, data files, and online redo log files are the three files that constitute
an Oracle Database 11g database.
Option 1 is incorrect. Archive redo logs contain a history of data changes
generated by the instance. They can be used to recover a lost data file. However,
archive redo logs are not essential in the everyday use of the database.

Option 2 is correct. Control files are small binary files which are necessary to start
and use the database. If control files are missing or corrupt, then you cannot open
the data files to access the data.
Option 3 is correct. A tablespace is made up of at least one data file. A data file
can be assigned to only one tablespace and only a single database. The data file
contains essential information such as user and application data.
Option 4 is correct. Online redo logs are essential for instance recovery for the
database. The redo logs are used to recover modified data which was not written
to the data files prior to a failure.
Option 5 is incorrect. Parameter files are important to successfully run an Oracle
database. However, they do not make up the actual database. Parameter files are
used to define how the instance is configured when it starts up.

3. Logical and physical database structures

The database has logical structures and physical structures.
A database is divided into logical storage units called tablespaces, which group related
logical structures together. For example, tablespaces commonly group all of an
application's objects to simplify some administrative operations.
You may have a tablespace for application data and an additional one for application
indexes.
Each database is logically divided into one or more tablespaces. One or more data files
are explicitly created for each tablespace to physically store the data of all logical
structures in a tablespace. If it is a TEMPORARY tablespace, then instead of a data file, the
tablespace has a temporary file.
A schema is a collection of database objects that are owned by a database user. Schema
objects are the logical structures that directly refer to the database's data.
Schema objects include such structures as tables, views, sequences, stored procedures,
synonyms, indexes, clusters, and database links. In general, schema objects include
everything that your application creates in the database.
At the finest level of granularity, an Oracle database's data is stored in data blocks. One
data block corresponds to a specific number of bytes of physical database space on the
disk. A database uses and allocates free database space in Oracle data blocks.
The next level of logical database space is called an extent. An extent is a specific
number of contiguous data blocks (obtained in a single allocation) that are used to store a
specific type of information.

The level of logical database storage above an extent is called a segment. A segment is a
set of extents allocated for a certain logical structure. The different types of segments
include

data segments

index segments

undo segments

temporary segments
data segments
Each non-clustered, non-index-organized table has a data segment with the exception of
external tables, global temporary tables, and partitioned tables where each table has one
or more segments.
All of the table's data is stored in the extents of its data segment. For a partitioned table,
each partition has a data segment. Each cluster has a data segment. The data of every
table in the cluster is stored in the cluster's data segment.
index segments
Each index has an index segment that stores all of its data. For a partitioned index, each
partition has an index segment.
undo segments
One UNDO tablespace is created per database instance that contains numerous undo
segments to temporarily store undo information.
The information in an undo segment is used to generate read-consistent database
information and, during database recovery, to roll back uncommitted transactions for users.
temporary segments
Temporary segments are created by the Oracle database when a SQL statement needs a
temporary work area to complete execution.
When the statement finishes execution, the temporary segment's extents are returned to
the instance for future use. You specify a default temporary tablespace for every user or a
default temporary tablespace, which is used databasewide.
The Oracle database dynamically allocates space. When the existing extents of a
segment are full, additional extents are added. Because extents are allocated as needed,
the extents of a segment may or may not be contiguous on the disk.
A database is divided into logical storage units called tablespaces, which can be used to
group related logical structures together.
Each database is logically divided into one or more tablespaces. One or more data files

are explicitly created for each tablespace to physically store the data of all logical
structures in a tablespace. Data files belong to only one tablespace.
You can also create bigfile tablespaces. These tablespaces can have only a single file,
which is often very large.

Note
The file may be any size up to maximum that the row ID architecture will permit.
The maximum size is the block size for the tablespace times 2 to the 36th power,
or 128 TB for a 32 KB block size. The traditional smallfile tablespaces (which are
the default) usually contain multiple data files, but the files cannot be as large.
Each Oracle database must contain a SYSTEM tablespace and a SYSAUX tablespace.
They are automatically created when the database is created.
The system default is to create a smallfile tablespace. You can also create bigfile
tablespaces, which enable the Oracle database to manage ultralarge files up to 8
exabytes in size.
A tablespace can be online (accessible) or offline (not accessible). The SYSTEM
tablespace is always online when the database is open. It stores tables that support the
core functionality of the database, such as the data dictionary tables.
The SYSAUX tablespace is an auxiliary tablespace to the SYSTEM tablespace. The
SYSAUX tablespace stores many database components, and it must be online for the
correct functioning of all database components.

Note
The SYSAUX tablespace may be taken offline to do tablespace recovery, whereas
this is not possible for the SYSTEM tablespace. Neither of them may be made
read-only.
Database objects, such as tables and indexes, are stored as segments in tablespaces.
Each segment contains one or more extents. An extent consists of contiguous data
blocks, which means that each extent can exist only in one data file. Data blocks are the
smallest unit of I/O in the database.
When the database requests a set of data blocks from the operating system (OS), the OS
maps this to an actual file system or disk block on the storage device. Because of this,
you need not know the physical address of any of the data in your database. This also
means that a data file can be striped or mirrored on several disks.

The size of the data block is defined by the DB_BLOCK_SIZE parameter. The default size
of 8 KB is adequate for most databases. If your database supports a data warehouse
application that has large tables and indexes, then a larger block size may be beneficial.
If your database supports a transactional application where reads and writes are random,
then specifying a smaller block size may be beneficial. The maximum block size depends
on your OS. You can have tablespaces with a non-standard block size.
The structural components of Oracle Database are

memory structures

process structures

storage structures
memory structures
Memory structures are

System Global Area (SGA) database buffer cache, redo buffer, and various pools

Program Global Area (PGA)

process structures
Process structures are

user process and server process

background processes SMON, PMON, DBWn, CKPT,LGWR, ARCn, and so on

storage structures
Storage structures are

logical database, schema, tablespace, segment, extent, and Oracle block

physical data files, control files, and redo log files

Question
Which are logical structures in Oracle Database 11g?
Options:
1.

A data file

2.

An operating system block

3.

A schema

4.

A tablespace

Answer
Schemas and tablespaces are logical storage structures in Oracle Database 11g.

Option 1 is incorrect. Data files are physical structures that store the data of all the
logical structures in a tablespace.
Option 2 is incorrect. An operating system block is a physical structure. It is the
smallest storage unit used to store the actual data for a database and its size is
dependent upon the operating system itself.
Option 3 is correct. A schema is a collection of database objects that are owned
by a database user. Schema objects are logical structures that refer to a
database's data.
Option 4 is correct. An Oracle Database 11g database is divided into logical
storage units called tablespaces. A tablespace groups related logical structures
together.

Question
What statements are true regarding the SYSTEM tablespace in Oracle Database
11g?
Options:
1.

The SYSTEM tablespace can be taken offline

2.

The SYSTEM tablespace is automatically created when the database is created

3.

The SYSTEM tablespace is optional

4.

The SYSTEM tablespace stores tables that support the core functionality of the
database

Answer
The SYSTEM tablespace is automatically created when the database is created. It
stores tables that support the core functionality of the database.
Option 1 is incorrect. Although the SYSAUX tablespace can be taken offline for
tablespace recovery, the SYSTEM tablespace cannot. The SYSTEM tablespace
must be online for the database to function.
Option 2 is correct. When an Oracle Database 11g database is created, both the
SYSTEM and SYSAUX tablespaces are created automatically for you. These
tablespaces store information needed for the correct functioning of the database.
Option 3 is incorrect. Each Oracle Database 11g database must contain a SYSTEM
and SYSAUX tablespace. The SYSTEM tablespace is a mandatory tablespace
required for the core functionality of the database.

Option 4 is correct. The SYSTEM tablespace contains the information needed by

the Oracle Database 11g database to function properly. This information is stored
in tables such as the data dictionary tables.

Summary
A database is a collection of data treated as a unit. It consists of both physical structures
and logical structures.
Oracle Database creates and uses memory structures for various purposes. System
Global Area (SGA) and Program Global Areas (PGAs) are basic memory structures
associated with an instance.
A database is divided into logical storage units called tablespaces. Each Oracle database
must contain a SYSTEM tablespace and a SYSAUX tablespace. The SYSAUX tablespace is
an auxiliary tablespace to the SYSTEM tablespace.

Table of Contents
| Top of page |
| Learning objective |
| 1. The Oracle database |
| 2. Structures and architecture |
| 3. Logical and physical database structures |
| Summary |
Copyright 2007 SkillSoft. All rights reserved.
SkillSoft and the SkillSoft logo are trademarks or registered trademarks
of SkillSoft in the United States and certain other countries.
All other logos or trademarks are the property of their respective owners.

| Print | Contents | Close |

ASM and Disk Groups Overview

Learning objective

After completing this topic, you should be able to recognize the steps for managing
database files using Automatic Storage Management (ASM) and disk groups.

1. Automatic Storage Management (ASM)

Automatic Storage Management (ASM) provides a vertical integration of the file system
and the volume manager that is specifically built for the Oracle database files.
ASM can provide management for single symmetric multiprocessor (SMP) machines, or
across multiple nodes of a cluster for Oracle Real Application Clusters (RAC) support.
A single ASM instance can provide support for many Oracle databases simultaneously.
ASM distributes I/O load across all available resources to optimize performance while
removing the need for manual I/O tuning.
ASM helps DBAs to manage a dynamic database environment by allowing them to
increase the database size without having to shut down the database to adjust the
storage allocation.
ASM can maintain redundant copies of data to provide fault tolerance, or it can be built on
top of vendor-supplied reliable storage mechanisms.
ASM may use virtual raw volumes provided in a storage area network (SAN) environment
or zero-padded files on a network attached storage (NAS) filer in addition to using local
raw devices.
Data management is done by selecting the desired reliability and performance
characteristics for classes of data rather than with human interaction on a per file basis.
ASM capabilities save DBAs' time by automating manual storage and thereby increasing
their ability to manage larger databases and more of them with increased efficiency.
ASM divides files into allocation units (AUs) and spreads the AUs for each file evenly
across all the disks.
ASM uses an index technique to track the placement of each AU. When your storage
capacity changes, ASM does not restripe all of the data, but moves an amount of data
proportional to the amount of storage added or removed to evenly redistribute the files
and maintain a balanced load across the disks. This is done while the database is up.
You can increase the speed of a rebalance operation, or lower it to reduce the impact on
the I/O subsystem.
ASM provides mirroring protection without the need to purchase a third-party Logical
Volume Manager. One unique advantage of ASM is that the mirroring is applied on a file
basis, rather than on a volume basis. Therefore, the same disk group can contain a
combination of files protected by mirroring, along with those that are not protected at all.

ASM supports data files, log files, control files, archive logs, temp files, archive log files,
SPFILEs, RMAN backup sets, and other Oracle database file types.
ASM supports Real Application Clusters and eliminates the need for a Cluster Logical
Volume Manager or a Cluster File System.

Question
How does Automatic Storage Management (ASM) benefit database administrators
(DBAs)?
Options:
1.

It enables them to manage larger and more databases with increased efficiency

2.

It forces databases to be shut down before adjusting storage allocation

3.

It provides more human interaction on a per file basis

4.

It provides support for only a single Oracle database

Answer
ASM enables DBAs to manage larger and more databases with increased
efficiency.
Option 1 is correct. By automating manual storage, ASM capabilities save DBAs
time. This increases their ability to manage larger and more databases with
increased efficiency.
Option 2 is incorrect. ASM allows DBAs to manage dynamic databases, including
adjusting the storage allocation without shutting down the databases first.
Option 3 is incorrect. ASM's data management is done by selecting the desired
reliability and performance characteristics for classes of data. This prevents the
DBA from working with data on a per file basis.
Option 4 is incorrect. A single ASM instance can provide simultaneous support for
many Oracle Database 11g databases.

2. Creating an ASM instance

To use ASM, you must start a special instance, called an ASM instance, before you start
your database instance.
ASM instances do not mount databases instead they manage the metadata needed to
make ASM files available to ordinary database instances.

Both ASM instances and database instances have access to some common set of disks
called disk groups. Database instances access the contents of ASM files directly,
communicating with an ASM instance only to get information about the layout of these
files.
An ASM instance starts several background processes specific to ASM. One process
coordinates rebalance activity for disk groups. It is called RBAL.
The second one performs the actual rebalance AU movements. There can be many of
these at a time, and they are called ARB0, ARB1, and so forth.
The GMON process, or Group Monitor, is used for partner and status table, and node
membership. An ASM instance also has some of the same background processes as a
database instance, including SMON, PMON, LGWR, DBWR, and CKPT.
Each database instance using ASM has two extra background processes called ASMB
and RBAL.
RBAL performs global opens of the disks in the disk groups. At database instance startup,
ASMB connects as a foreground process to the ASM instance. Communication between
the database and the ASM instance is performed via this bridge. This includes physical
file changes such as data file creation and deletion.
Over this connection, periodic messages are exchanged to update statistics and to verify
that both instances are healthy.
You create an ASM instance by running the Database Configuration Assistant (DBCA).
On the first page, you select the Configure Automatic Storage Management option, and
then follow the steps.
The ASM instance is created and started for you. Then you are guided through the
process of defining disk groups for the instance.
As part of the ASM instance creation process, the DBCA automatically creates an entry
into the oratab file. This entry is used for discovery purposes.
On the Windows platform where a services mechanism is used, the DBCA automatically
creates an Oracle Service and the appropriate registry entry to facilitate the discovery of
ASM instances.
In addition, you are prompted to run the localconfig script that configures Cluster
Synchronization Services to manage the ASM instance. When an ASM instance is
configured, the DBCA creates an ASM instance parameter file and an ASM instance
password file.

If you were to create an ASM-enabled database, the DBCA determines whether an ASM
instance already exists on your host. If ASM instance discovery returns an empty list, the
DBCA creates a new ASM instance.

Question
What is the purpose of the ASMB background process that is created for each
database instance using Automatic Storage Management (ASM)?
Options:
1.

It coordinates rebalance activity for disk groups

2.

It mounts the database that will use ASM

3.

It performs the actual rebalance movements of the allocation units

4.

It provides communication between the database and the ASM instance

Answer
The purpose of the ASMB background process is to provide communication
between the database and the ASM instance.
Option 1 is incorrect. The background process RBAL coordinates rebalance
activity for disk groups. This process is started when the ASM instance is started.
Option 2 is incorrect. The ASMB process does not mount the database. It provides
communication between the ASM instance and the database instance.
Option 3 is incorrect. The actual rebalance movements are performed by a
number of processes, including ARB0, ARB1, and others.
Option 4 is correct. The ASMB process connects to the ASM instance when the
database instance starts. Communication between the database and the ASM
instance is performed by this process, including physical file changes, such as
creation and deletion.

Question
Which is a correct statement about an ASM instance?
Options:
1.

After the ASM instance is started, the database will be mounted

2.

Once the ASM instance has been created, you must define your disk groups
manually

3.

The ASM instance can share the same disk group as your database

4.

The ASM instance must be started manually after it has been created by the DBCA

Answer
It is true that the ASM instance can share the same disk group as your database.
Option 1 is incorrect. An ASM instance will not mount any databases. An ASM
instance only manages metadata that makes the ASM files available to a
database instance.
Option 2 is incorrect. Once the database configuration assistant has completed
creating the ASM instance, then it will guide you through the process defining your
disk groups. It is not necessary to do this manually.
Option 3 is correct. An ASM instance and database instance can both share a
common set of disks. In Oracle Database 11g, a common set of disks is known as
a disk group.
Option 4 is incorrect. Once the database configuration assistant has completed
creating the ASM instance, it will start the instance for you.

3. ASM disk groups

A disk group is a collection of disks managed as a logical unit. Storage is added and
removed from disk groups in units of ASM disks.
Every ASM disk has an ASM disk name, which is a name common to all nodes in a
cluster. The ASM disk name abstraction is required because different hosts can use
different names to refer to the same disk.
ASM administers disk groups, not files.
An ASM file can begin with 1 MB extents and as the file size increases, the extent size
also increases to 8 MB and 64 MB at a predefined number of extents. Therefore, the size
of extent map defining a file can be smaller by a factor of 8 and 64 depending on the size
of the file.
The initial extent size is equal to the AU size and it increases by the 8 and 64 factor at
predefined thresholds. This is automatic for newly created files after the
COMPATIBLE.ASM and COMPATIBLE.RDBMS parameters have been advanced to 11.1.
ASM partitions total disk space into uniform sized units. ASM always spreads files evenly
across all the disks in a disk group. This is called coarse striping. That way, ASM
eliminates the need for manual disk tuning. However, disks in a disk group should have
similar size and performance characteristics to obtain optimal I/O.
For most installations, there is only a small number of disk groups for instance, one disk
group for a work area, and one for a recovery area. For files, such as log files, that

require low latency, ASM provides fine-grained (128 KB) striping. Fine striping stripes
each AU.
ASM uses coarse- or fine-grain striping on the basis of file type.
Fine striping breaks up medium-sized I/O operations into multiple smaller I/O operations
that execute in parallel. While the number of files and disks increase, you have to
manage only a constant number of disk groups.
From a database perspective, disk groups can be specified as the default location for files
created in the database.

Note
Each disk group is self-describing, containing its own file directory and disk
directory.
Suppose you want to upgrade the database storage from file system files to ASM. To do
this, you use DBCA to create an ASM instance called +ASM and configure two disk
groups, DATA and FRA.
The DATA disk group uses four 3 GB raw slices employing normal redundancy. The FRA
disk group uses four 6 GB slices employing external redundancy.
There are 13 steps you must perform to upgrade the database storage to ASM. The first
two steps are:
Step 1: You invoke the Database Configuration Assistant (DBCA) and you click Next on
the Welcome screen to get started.
Step 2: On the next page, you select Configure Automatic Storage Management from
the list of possible operations, and then click Next to continue.
The next three steps to upgrade the database storage to ASM are:
Step 3: You are asked to run the localconfig script to set up local Cluster
Synchronization Service (CSS) for high availability purposes.
Step 4: You open a terminal window and run the localconfig add script as root.
When the script has completed, you click OK to dismiss the localconfig dialog box.
Step 5: After returning to the Operations page, you click Next to continue.
The next three steps are:

Step 6: The new ASM instance must have a password for the SYS account. You use
oracle for the password and you click Next.
Step 7: You click OK to start the ASM instance and wait a few moments while the
instance starts.
Step 8: Next the disk groups must be created. You click the Create New button to begin.
The next three steps are:
Step 9: You enter DATA for the Disk Group Name and select Normal redundancy. You
select the first four raw slices that are 3 GB in size, and you click OK.
Step 10: You click Create New to create the next diskgroup for the flash recovery area.
Step 11: You enter FRA for the Disk Group Name and you select External Redundancy.
There will be four raw slices of 3 GB left. You select them and click OK to continue.
The final two steps to upgrade the database storage to ASM are:
Step 12: Both diskgroups should be mounted at this stage. You click Finish to continue.
Step 13: You click No when prompted to perform another DBCA operation.
A failure group is a set of disks, inside one particular disk group, sharing a common
resource whose failure needs to be tolerated.
An example of a failure group is a string of SCSI disks connected to a common SCSI
controller. A failure of the controller leads to all the disks on its SCSI bus becoming
unavailable, although each of the individual disks is still functional.
What constitutes a failure group is site specific. It is largely based upon failure modes that
a site is willing to tolerate. By default, ASM assigns each disk to its own failure group.
When creating a disk group or adding a disk to a disk group, administrators may specify
their own grouping of disks into failure groups. After failure groups are identified, ASM can
optimize file layout to reduce the unavailability of data due to the failure of a shared
resource.
ASM has three disk group types that support different types of mirroring:

external-redundancy

normal-redundancy

high-redundancy
external-redundancy

External redundancy does not provide mirroring. You use an external-redundancy disk
group if you use hardware mirroring or if you can tolerate data loss as the result of a disk
failure. Failure groups are not used with this type of disk group.
normal-redundancy
Normal redundancy supports two-way mirroring.
high-redundancy
High redundancy provides triple mirroring.
ASM does not mirror disks rather, it mirrors AUs. As a result, you need only spare
capacity in your disk group.
When a disk fails, ASM automatically reconstructs the contents of the failed disk on the
surviving disks in the disk group by reading the mirrored contents from the surviving
disks. This spreads the I/O hit from a disk failure across several disks.
When ASM allocates a primary AU of a file to one disk in a disk group, it allocates a mirror
copy of that AU to another disk in the disk group.
Primary AUs on a given disk can have their mirror copies on one of several partner disks
in the disk group. ASM ensures that a primary AU and its mirror copy never reside in the
same failure group.
If you define failure groups for your disk group, ASM can tolerate the simultaneous failure
of multiple disks in a single failure group.
With ASM, the rebalance process is very easy and happens without any intervention from
the DBA or system administrator. ASM automatically rebalances a disk group whenever
disks are added or dropped. However, rebalancing will be delayed when disk groups are
dropped because of errors.
By using index techniques to spread AUs on the available disks, ASM does not need to
restripe all of the data, but instead needs to only move an amount of data proportional to
the amount of storage added or removed to evenly re-distribute the files and maintain a
balanced I/O load across the disks in a disk group.
With the I/O balanced whenever files are allocated and whenever the storage
configuration changes, the DBA never needs to search for hot spots in a disk group and
manually move data to restore a balanced I/O load. However, because the database
needs to resync cached ASM metadata, rebalances will have less impact if done in quiet
periods.
It is more efficient to add or drop multiple disks at the same time so that they are
rebalanced as a single operation. This avoids unnecessary movement of data. With this
technique, it is easy to achieve online migration of your data. All you need to do is add the
new disks in one operation and drop the old ones in one operation.

You can control how much of a load the rebalance operation has on the system by setting
the ASM_POWER_LIMIT parameter. Its range of values is 1 through 11. The lower the
number, the lighter the load a higher setting has more of a load and finishes sooner.

Summary
Automatic Storage Management (ASM) provides a vertical integration of the file system
and the volume manager that is specifically built for the Oracle database files.
To use ASM, you must start a special instance, called an ASM instance, before you start
your database instance. ASM instances manage the metadata needed to make ASM files
available to ordinary database instances.
A disk group is a collection of disks managed as a logical unit. Storage is added and
removed from disk groups in units of ASM disks. ASM has three disk group types that
support different types of mirroring external-redundancy, normal-redundancy, and highredundancy.

Table of Contents
| Top of page |
| Learning objective |
| 1. Automatic Storage Management (ASM) |
| 2. Creating an ASM instance |
| 3. ASM disk groups |
| Summary |
Copyright 2006 SkillSoft. All rights reserved.
SkillSoft and the SkillSoft logo are trademarks or registered trademarks
of SkillSoft in the United States and certain other countries.
All other logos or trademarks are the property of their respective owners.

| Print | Contents | Close |

Managing Disk Groups

Learning objective

After completing this topic, you should be able to identify ways to manage disk groups
and their attributes and also configure and manage ASM instances.

1. Managing disk groups

The main goal of an ASM instance is to manage disk groups and protect their data. ASM
instances also communicate file layout to database instances. In this way, database
instances can directly access files stored in disk groups.
There are several disk group administrative commands. They all require the SYSASM or
SYSDBA privilege and must be issued from an ASM instance. You can add new disk
groups. You can also modify existing disk groups to add new disks, remove existing ones,
and perform many other operations. You can remove existing disk groups.
You can use the SQL*Plus to manage disk groups. Assume that ASM disk discovery
identified the following disks in the /devices directory: A1, A2, A3, B1, B2, and B3. Also,
assume that disks A1, A2, and A3 are on a separate SCSI controller from disks B1, B2,
and B3. The first example illustrates how to configure a disk group called DGROUPA with
two failure groups CONTROLLER1 and CONTROLLER2.
The example also uses the default redundancy characteristic, NORMAL REDUNDANCY, for
the disk group.
CREATE DISKGROUP dgroupA NORMAL REDUNDANCY
FAILGROUP controller1 DISK
'/devices/A1' NAME diskA1 SIZE 120G FORCE,
'/devices/A2',
'/devices/A3'
FAILGROUP controller2 DISK
'/devices/B1',
'/devices/B2',
'/devices/B3';
You can optionally provide a disk name and size for the disk. If you do not supply this
information, ASM creates a default name and attempts to determine the size of the disk. If
the size cannot be determined, an error is returned. FORCE indicates that a specified disk
should be added to the specified disk group even though the disk is already formatted as
a member of an ASM disk group. Using the FORCE option for a disk that is not formatted
as a member of an ASM disk group returns an error.
You can delete a disk group along with all its files. To avoid accidental deletions, the
INCLUDING CONTENTS option must be specified if the disk group still contains any files
besides internal ASM metadata. The disk group must be mounted in order for it to be
dropped.
After ensuring that none of the disk group files are open, the group and all its drives are
removed from the disk group. Then the header of each disk is overwritten to eliminate the
ASM formatting information.

DROP DISKGROUP dgroupA INCLUDING CONTENTS;

To add disks to a disk group, you execute an ALTER DISKGROUP ADD DISK command.
The first statement adds four new disks to the DGROUPA disk group.
ALTER DISKGROUP dgroupA ADD
'/dev/rdsk/c0t4d0s2' NAME
'/dev/rdsk/c0t5d0s2' NAME
'/dev/rdsk/c0t6d0s2' NAME
'/dev/rdsk/c0t7d0s2' NAME

DISK
A5,
A6,
A7,
A8;

The second statement demonstrates the interactions of discovery strings. Consider this
configuration:
- /devices/A1 is a member of disk group DGROUPA
- /devices/A2 is a member of disk group DGROUPA
- /devices/A3 is a member of disk group DGROUPA
- /devices/A4 is a candidate disk
The second command adds A4 to the DGROUPA disk group. It ignores the other disks,
even though they match the discovery string, because they are already part of the
DGROUPA disk group. When you add a disk to a disk group, the ASM instance ensures
that the disk is addressable and usable. The disk is then formatted and rebalanced.
ALTER DISKGROUP dgroupA ADD DISK '/devices/A*';
The rebalance process is time consuming because it moves AUs from every file onto the
new disk.
ALTER DISKGROUP dgroupA ADD DISK '/devices/A*';

Note
Rebalancing does not block any database operations. The main impact that a
rebalance process has is on the I/O load on the system. The higher the power of
the rebalance, the more I/O load it puts on the system. Thus less I/O bandwidth is
available for database I/Os.
There are two kinds of compatibility applicable to ASM disk groups dealing with the
persistent data structures that describe a disk group, and the capabilities of the clients
consumers of disk groups. These attributes are called ASM compatibility and RDBMS
compatibility, respectively.
The compatibility of each disk group is independently controllable. This is required to
enable heterogeneous environments with disk groups from both Oracle Database 10g
and Oracle Database 11g.

RDBMS compatibility refers to the minimum compatible version of the RDBMS instance
that would allow the instance to mount the disk group. This compatibility dictates the
format of messages that are exchanged between the ASM and database (RDBMS)
instances. An ASM instance has the capability to support different RDBMS clients running
at different compatibility settings. The database compatible version setting of each
instance must be greater than or equal to the RDBMS compatibility of all disk groups
used by that database.
Database instances are typically run from a different Oracle home than the ASM instance.
This implies that the database instance may be running a different software version than
the ASM instance. When a database instance first connects to an ASM instance, it
negotiates the highest version that they both can support. The compatibility parameter
setting of the database, software version of the database, and the RDBMS compatibility
setting of a disk group determine whether a database instance can mount a given disk
group.
ASM compatibility refers to the persistent compatibility setting controlling the format of
data structures for ASM metadata on disk. The ASM compatibility level of a disk group
must always be greater than or equal to the RDBMS compatibility level of the same disk
group. ASM compatibility is concerned only with the format of the ASM metadata.
The format of the file contents is up to the database instance. For example, the ASM
compatibility of a disk group can be set to 11.0 while its RDBMS compatibility could be
10.1. This implies that the disk group can be managed only by ASM software whose
software version is 11.0 or higher, whereas any database client whose software version is
higher than or equal to 10.1 can use that disk group.
The compatibility of a disk group needs to be advanced only when there is a change to
either persistent disk structures or protocol messaging. However, advancing disk group
compatibility is an irreversible operation. You can set the disk group compatibility by using
either the CREATE DISKGROUP or ALTER DISKGROUP commands.

Note
In addition to the disk group compatibilities, the compatible parameter database
compatible version determines the features that are enabled. It applies to the
database or ASM instance depending on the instance_type parameter. For
example, setting it to 10.1 would preclude use of any features introduced in Oracle
Database 11g disk online/offline, variable extents, and so on.
Whenever you create or alter an ASM disk group, you have the ability to change its
attributes using the new ATTRIBUTE clause of the CREATE DISKGROUP and ALTER
DISKGROUP commands.

CREATE DISKGROUP DATA NORMAL REDUNDANCY

DISK '/dev/raw/raw1','/dev/raw/raw2'
ATTRIBUTE 'compatible.asm'='11.1';
ASM enables the use of different allocation unit (AU) sizes that you can specify when you
create a disk group. The AU can be 1, 2, 4, 8, 16, 32, or 64 MB in size.
You can specify the DISK_REPAIR_TIME in units of minute (M), hour (H), or day (D). If
you omit the unit, then the default is H. If you omit this attribute, then the default is 3.6H.
You can override this attribute with an ALTER DISKGROUP ... DISK OFFLINE
statement.
You can also specify the redundancy attribute of the specified template, the striping
attribute of the specified template, RDBMS compatibility, and ASM compatibility.

Note
For each defined disk group, you can look at all defined attributes through the
V$ASM_ATTRIBUTE fixed view.
Enterprise Manager provides a simple way to store and retrieve environment settings
related to disk groups.
On the Disk Groups tabbed page of the Automatic Storage Management page, you click
the disk name DATA.
You then click the Edit button.
You can set the compatible attributes from both the create disk group page and the Edit
Advanced Attributes for Disk Group: Data page. The disk_repair_time attribute is
added to the Edit Advanced Attributes for Disk Group: Data page only.

Note
For pre-11g ASM instances, the default ASM compatibility and client compatibility
is 10.1. For 11g ASM instances, the default ASM compatibility is 10.1 and
database compatibility is 10.1.

2. ASM instances
The SYSASM role is specifically intended for performing ASM administration tasks. Using
the SYSASM role instead of the SYSDBA role improves security by separating ASM
administration from database administration.
In Oracle Database 11g Release 1, the OS group for SYSASM and SYSDBA is the same,

and the default installation group for SYSASM is dba. In a future release, separate groups
will have to be created, and SYSDBA users will be restricted in ASM instances. Currently,
as a member of the dba group you can connect to an ASM instance using the first
statement.
SQL>
SQL>
SQL>
SQL>
SQL>

CONNECT / AS SYSASM
CREATE USER ossysasmusername IDENTIFIED by passwd;
GRANT SYSASM TO ossysasmusername;
CONNECT ossysasmusername / passwd AS SYSASM;
DROP USER ossysasmusername;

Note
In Oracle Database 11g Release 1, if you log in to an ASM instance as SYSDBA,
warnings are written in the corresponding alert.log file.
You can also use the combination of CREATE USER and GRANT SYSASM SQL
statements from an ASM instance to create a new SYSASM user. This is possible as long
as the name of the user is an existing OS username. These commands update the
password file of each ASM instance, and do not need the instance to be up and running.
Similarly, you can revoke the SYSASM role from a user using the REVOKE command, and
you can drop a user from the password file using the DROP USER command. The
V$PWFILE_USERS view includes a new column called SYSASM that indicates whether the
user can connect with SYSASM privileges TRUE or not FALSE.
ASM instances are started similarly to database instances except that the initialization
parameter file contains the entry INSTANCE_TYPE=ASM. When this parameter is set to
the value ASM, it informs the Oracle executable that an ASM instance is starting, not a
database instance. Also, the ORACLE_SID variable must be set to the ASM instance
name. When the ASM instance starts up, the mount stage attempts to mount the disk
groups specified by the ASM_DISKGROUPS initialization parameter rather than mounting a
database, as is done with non-ASM instances.
Other STARTUP clauses have comparable interpretation for ASM instances as they do for
database instances. OPEN is invalid for an ASM instance. NOMOUNT starts up the ASM
instance without mounting the database.
$ export ORACLE_SID='+ASM'
$ sqlplus /nolog
SQL> CONNECT / AS sysasm
Connected to an idle instance.
SQL> STARTUP;
Total System Global Area 284565504 bytes
Fixed Size
1299428 bytes

Variable Size
ASM Cache
ASM diskgroups mounted

258100252 bytes
25165824 bytes

An ASM instance is controlled by a parameter file in the same way as a regular database
instance. Parameters commonly set there include

INSTANCE_TYPE

DB_UNIQUE_NAME

ASM_POWER_LIMIT

ASM_DISKSTRING

ASM_DISKGROUPS
INSTANCE_TYPE
INSTANCE_TYPE should be set to ASM for ASM instances. This is the only parameter that
must be defined.
DB_UNIQUE_NAME
DB_UNIQUE_NAME specifies the service provider name for which this ASM instance
manages disk groups.
ASM_POWER_LIMIT
ASM_POWER_LIMIT controls the speed for a rebalance operation. Values range from 1
through 11, with 11 being the fastest. If omitted, this value defaults to 1.
ASM_DISKSTRING
ASM_DISKSTRING is an operating systemdependent value used by ASM to limit the set
of disks considered for discovery.
ASM_DISKGROUPS
ASM_DISKGROUPS is the list of names of disk groups to be mounted by an ASM instance
at startup, or when the ALTER DISKGROUP ALL MOUNT command is used.
Automatic memory management is enabled by default on ASM instances, even when the
MEMORY_TARGET parameter is not explicitly set.
INSTANCE_TYPE = ASM
DB_UNIQUE_NAME = +ASM
ASM_POWER_LIMIT = 1
ASM_DISKSTRING = '/dev/rdsk/*s2', '/dev/rdsk/c1*'
ASM_DISKGROUPS = dgroupA, dgroupB
SPFILE = '+DATA/ORCL/orclspfile.ora_1'

Note

This is the only parameter that you need to set for complete ASM memory
management. Oracle Corporation strongly recommends that you use automatic
memory management for ASM.
ASM instances do not have a data dictionary, so the only way to connect to one is by
using OS authentication, that is, SYSASM, SYSDBA, or SYSOPER. To connect remotely, a
password file must be used. Users who connect to the ASM instance with the SYSASM or
SYSDBA privileges have administrative access to all disk groups in the system. The
SYSOPER privilege is supported in ASM instances and limits the set of allowable SQL
commands to the minimum required for basic operation of an already configured system.
These commands are available to SYSOPER users:

STARTUP/SHUTDOWN

ALTER DISKGROUP MOUNT/DISMOUNT

ALTER DISKGROUP ONLINE/OFFLINE DISK

ALTER DISKGROUP REBALANCE

ALTER DISKGROUP CHECK

SELECT all V$ASM_* views

All other commands, such as CREATE DISKGROUP, ADD/DROP/RESIZE DISK require
the SYSASM or SYSDBA privilege and are not allowed with the SYSOPER privilege.
When you attempt to shut down an ASM instance in the NORMAL, IMMEDIATE, or
TRANSACTIONAL modes, it succeeds only if there are no database instances connected
to the ASM instance. If there is at least one connected instance, you receive an error.
ORA-15097: cannot SHUTDOWN ASM instance with connected RDBMS
instance
If you perform a SHUTDOWN ABORT on the ASM instance, it shuts down, and it will require
recovery at the time of the next startup. Any connected database instances will also
eventually shut down, reporting an error.
ORA-15064: communication failure with ASM instance
In a single-ASM instance configuration, if the ASM instance fails while disk groups are
open for update, then after the ASM instance reinitializes, it reads the disk group's log
and recovers all transient changes. With multiple ASM instances sharing disk groups, if
one ASM instance fails, another ASM instance automatically recovers transient ASM
metadata changes caused by the failed instance.
The failure of a database instance does not affect ASM instances. The ASM instance
should be started automatically whenever the host is rebooted. The ASM instance is

expected to use the automatic startup mechanism supported by the underlying operating
system. File system failure usually crashes a node.
Enterprise Manager allows you to manage the users who access the ASM instance
through remote connection, using password file authentication. These users are reserved
exclusively for the ASM instance.
You have this functionality only when you are connected as the SYSASM user. It is hidden
if you connect as SYSDBA or SYSOPER users.
You click the Create button.
The Create User page is displayed.

Note
Oracle Database 11g adds the SYSASM role to the ASM instance login page.
You can edit an existing user by selecting the Select checkbox, then clicking the Edit
button.
The Edit User page is displayed.
On the Users page, you click the Delete button to delete the created users.

Question
Which parameter must be defined in an ASM parameter file?
Options:
1.

ASM_DISKSTRING

2.

ASM_POWER_LIMIT

3.

DB_UNIQUE_NAME

4.

INSTANCE_TYPE

Answer
The only parameter that must be defined in an ASM parameter file is
INSTANCE_TYPE.
Option 1 is incorrect. The ASM_DISKSTRING parameter is optional and is an
operating system-dependent value used by ASM to limit the set of disks
considered for discovery.

Option 2 is incorrect. ASM_POWER_LIMIT is an optional parameter that controls

the speed for a rebalance operation and can have values from 1 through 11. If
omitted, the default value is 1.
Option 3 is incorrect. DB_UNIQUE_NAME is an optional parameter that specifies
the service provider name for which this ASM instance manages disk groups.
Option 4 is correct. For ASM instances, the INSTANCE_TYPE parameter should
be set to ASM. This is the only parameter that must be defined.

Question
What is the purpose of the ASM_DISKGROUPS parameter in an ASM parameter
file?
Options:
1.

Informing the Oracle executable that an ASM instance is starting

2.

Opening the ASM instance

3.

Specifying the disk group to attempt to mount at startup

4.

Specifying the set of disks considered for discovery

Answer
The purpose of the ASM_DISKGROUPS parameter in an ASM parameter file is to
specify the disk group to attempt to mount at startup.
Option 1 is incorrect. The parameter file entry INSTANCE_TYPE = ASM informs
the Oracle executable that an ASM instance is starting, not the ASM_DISKGROUPS
parameter.
Option 2 is incorrect. An ASM instance is started not opened. Unlike other
STARTUP clauses that have comparable interpretations for ASM instances as they
do for database instances, the OPEN clause is invalid for an ASM instance.
Option 3 is correct. When an ASM instance starts up, the mount stage attempts to
mount the disk groups specified by the ASM_DISKGROUPS initialization parameter.
Option 4 is incorrect. The initialization parameter ASM_DISKSTRING is used by
ASM to limit the set of disks considered for discovery, not the ASM_DISKGROUPS
parameter.

Question

Different users have different levels of administrative access when connected to

an ASM instance.
Which user has limited administrative access when connected to an ASM
instance?
Options:
1.

SYSASM

2.

SYSDBA

3.

SYSOPER

Answer
A SYSOPER user has the minimum required administrative access when connected
to an ASM instance.
Option 1 is incorrect. Users who have the SYSASM privileges have administrative
access to all disk groups in the system. And they can perform all operations
necessary for maintaining the ASM instance.
Option 2 is incorrect. The SYSDBA privilege provides full administrative access to
all the disk groups for the ASM instance. Users with this privilege can perform all
necessary operations on the ASM instance.
Option 3 is correct. The SYSOPER privilege limits the set of allowable SQL
commands to the minimum required for the basic operation of an already
configured system.

Summary
To manage disk groups, there are several disk group administrative commands available
which require the SYSASM or SYSDBA privilege. There are two compatibility settings that
are attributes of each ASM disk group RDBMS compatibility, and ASM compatibility.
Whenever you create or alter an ASM disk group, you have the ability to change its
attributes.
The SYSASM role is specifically intended for performing ASM administration tasks. An
ASM instance is controlled by a parameter file in the same way as a regular database
instance. The failure of a database instance does not affect ASM instances. The ASM
instance should be started automatically whenever the host is rebooted.

Table of Contents

| Top of page |
| Learning objective |
| 1. Managing disk groups |
| 2. ASM instances |
| Summary |
Copyright 2006 SkillSoft. All rights reserved.
SkillSoft and the SkillSoft logo are trademarks or registered trademarks
of SkillSoft in the United States and certain other countries.
All other logos or trademarks are the property of their respective owners.

| Print | Contents | Close |

ASM Storage
Learning objective

After completing this topic, you should be able to recognize the steps for managing ASM
storage, scalability, and performance using the ALTER command and also the ASMCMD
utility.

1. ASM storage concepts

ASM does not eliminate any existing database functionality. Existing databases are able
to operate as they always have. New files may be created as ASM files, whereas existing
ones are administered in the old way or can be migrated to ASM.
There are new concepts introduced by ASM in Oracle Database 10g to describe file
storage. These concepts do not replace any existing concepts such as segments and
tablespaces. With ASM, database files can now be stored as ASM files. At the top of the
new hierarchy are ASM disk groups.
Any single ASM file is contained in only one disk group. However, a disk group may
contain files belonging to several databases, and a single database may use storage
from multiple disk groups.
One disk group is made up of ASM disks, and each ASM disk belongs to only one disk
group. Also, ASM files are always spread across all the ASM disks in the disk group. ASM
disks are partitioned in allocation units (AUs) of one megabyte each. An AU is the
smallest contiguous disk space that ASM allocates. ASM does not allow physical blocks
to be split across AUs.

You have already used DBCA to create an ASM instance called +ASM and configure two
diskgroups, DATA and FRA. You now need to migrate your database storage to use ASM.
You connect to Enterprise Manager using the URL https://your_host_name:1158/em. You
enter sys as your username and oracle as your password, and connect as SYSDBA.
On the Database home page, you click the Server tab.
You then click the Migrate to ASM link in the Storage section.
You enter the Target Name as +ASM_your_host_name. The ASM ORACLE_HOME should
be the same as your database, /u01/app/oracle/product/11.1.0/db_1. Next,
you provide the SYS password, oracle. The port should be 1521 and the SID should be
+ASM.
You enter the host credentials next oracle/oracle and you click Continue.
The Migration Options page is displayed.
In the Files to Be Migrated section, you select the Database Files and Recovery-related
Files checkboxes. The working directory should be the same as the database home,
/u01/app/oracle/product/11.1.0/db_1/dbs.
In the Parallelism section, you select the Parallelize File Copy Operations checkbox.
You click Next to continue.
In the Database Area section, you enter DATA in the Database Area field.
In the Flash Recovery Area section, you enter FRA in the Flash Recovery Area field and
change the Flash Recovery Area Size to 4096. You select Setup Flash Recovery Area
and Migrate Recovery-related Files and you then click Next to continue.
On the Migrate Database To ASM: Schedule page, you select Immediately in the Start
section and you click Next to continue.
On the Migrate Database To ASM: Review page, you examine your selections. If you
have made any errors, you use the Back button to go back and correct them. You click
Submit Job when you are ready.
After the job has been submitted, you click the View Status button to monitor the job's
progress. It takes several minutes to complete.
The Job Activity page is displayed. When the job finishes, you will be disconnected from
Enterprise Manager.

You wait a few moments and log back in to Enterprise Manager. You click the ASM link
on the database home page.
On the +ASM home page, the DATA diskgroup is associated with the orcl instance
storage.
After the database has been migrated to ASM, you can remove all the files that were
stored in the traditional file system.

2. ALTER commands
This statement shows how to remove one of the disks from the DGROUPA disk group.
ALTER DISKGROUP dgroupA DROP DISK A5;
ALTER DISKGROUP dgroupA
DROP DISK A6
ADD FAILGROUP fred
DISK '/dev/rdsk/c0t8d0s2' NAME A9;
ALTER DISKGROUP dgroupA UNDROP DISKS;
This statement shows how you can add and drop a disk in a single command. The big
advantage in this case is that rebalancing is not started until the command completes.
ALTER DISKGROUP dgroupA DROP DISK A5;
ALTER DISKGROUP dgroupA
DROP DISK A6
ADD FAILGROUP fred
DISK '/dev/rdsk/c0t8d0s2' NAME A9;
ALTER DISKGROUP dgroupA UNDROP DISKS;
This statement shows how to cancel a disk drop operation. The UNDROP command
operates only on pending drops of disks it has no effect on drops that have completed.
ALTER DISKGROUP dgroupA DROP DISK A5;
ALTER DISKGROUP dgroupA
DROP DISK A6
ADD FAILGROUP fred
DISK '/dev/rdsk/c0t8d0s2' NAME A9;
ALTER DISKGROUP dgroupA UNDROP DISKS;

This statement rebalances the DGROUPB disk group, if necessary.

This command is generally not necessary because it is automatically done as disks are
added, dropped, or resized. However, it is useful if you want to use the POWER clause to
override the default speed defined by the initialization parameter ASM_POWER_LIMIT.
You can change the power level of an ongoing rebalance operation by reentering the
command with a new level. A power level of zero causes rebalancing to halt until the
command is either implicitly or explicitly reinvoked.
ALTER DISKGROUP dgroupB REBALANCE POWER 5;
This statement dismounts DGROUPA.
The MOUNT and DISMOUNT options allow you to make one or more disk groups available
or unavailable to the database instances. The ability to manually unmount and mount is
useful in a clustered ASM environment supporting a single instance, when that instance is
failed over to a different node.
ALTER DISKGROUP dgroupA DISMOUNT;

Question
You want to drop disk C3 from the disk group named DGROUPB.
Which SQL statement would you use?
Options:
1.

ALTER DISKGROUP dgroupb DROP C3;

2.

ALTER DISKGROUP dgroupb DROP DISK C3;

3.

ALTER DISKGROUP DROP DISK C3;

4.

ALTER GROUP dgroupb DROP DISK C3;

Answer
To drop a disk from a disk group, you use this command:
ALTER DISKGROUP dgroupb DROP DISK C3;
Option 1 is incorrect. You must include the DROP DISK command to drop a disk
from a disk group.

Option 2 is correct. To drop a disk, you use ALTER DISKGROUP and include the
disk group's name, followed by the DROP DISK command and the name of the
disk you wish to drop.
Option 3 is incorrect. To drop a disk, the SQL statement must include the name of
the disk group to which the disk belongs.
Option 4 is incorrect. You use ALTER DISKGROUP to drop a disk, not ALTER
GROUP.

Question
You want to make disk group DGROUPB unavailable to the database instances.
Which SQL statement would you use?
Options:
1.

ALTER DISK dgroupb DISMOUNT;

2.

ALTER DISKGROUP dgroupb DISMOUNT;

3.

ALTER DISKGROUP DISMOUNT;

4.

ALTER GROUP dgroupb DISMOUNT;

Answer
To make a disk group unavailable to the database instances, you use the
DISMOUNT option of the ALTER DISKGROUP command.
Option 1 is incorrect. The correct command to make a disk group unavailable is
ALTER DISKGROUP, not ALTER DISK.
Option 2 is correct. The DISMOUNT option of the ALTER DISKGROUP command
makes the specified disk group unavailable to the database instances. This is
useful in a clustered ASM environment supporting a single instance, when that
instance is failed over to a different node.
Option 3 is incorrect. When using the ALTER DISKGROUP command to dismount
a disk group, you must specify the name of the disk group.
Option 4 is incorrect. The correct command to make a disk group unavailable is
ALTER DISKGROUP, not ALTER GROUP.

3. ASMCMD utility

ASMCMD is a command line utility that you can use to view and manipulate files and
directories within ASM disk groups. ASMCMD can list the contents of disk groups,
perform searches, create and remove directories and aliases, display space utilization,
and more. ASMCMD works with ASM files, directories, and aliases.
Every file created in ASM gets a system-generated file name, otherwise known as a fully
qualified file name. This is the same as a complete path name in a local file system. As in
other file systems, an ASM directory is a container for files, and an ASM directory can be
part of a tree structure of other directories. The fully qualified file name represents a
hierarchy of directories in which the plus sign (+) represent the root directory.
SQL> CREATE TABLESPACE tbsasm DATAFILE '+DGROUP1' SIZE 100M;
Tablespace created.
SQL> CREATE TABLESPACE hrapps DATAFILE '+DGROUP1' SIZE 10M;
Tablespace created.
$ export ORACLE_SID=+ASM
$ asmcmd
ASMCMD> ls -l DGROUP1/ORCL/DATAFILE
Type
Redund Striped Time
Sys Name
DATAFILE MIRROR COARSE OCT 05 21:00:00 Y
HRAPPS.257.570923611
DATAFILE MIRROR COARSE OCT 05 21:00:00 Y
TBSASM.256.570922917
ASMCMD>
You can create your own directories as subdirectories of the system-generated directories
using the ASMCMD mkdir command.
ASMCMD> mkdir +dgroup1/sample/mydir
ASMCMD can perform ASM metadata backup and restore functionality. This provides the
ability to re-create a pre-existing ASM disk group with the exact same template and alias
directory structure.
The lsdsk command lists ASM disk information. This command can run in two modes
connected and non-connected. In connected mode, ASMCMD uses the V$ and GV$
views to retrieve disk information. In non-connected mode, ASMCMD scans disk headers
to retrieve disk information, using an ASM disk string to restrict the discovery set. The
connected mode is always attempted first.
ASMCMD> md_backup b /tmp/dgbackup070222 g admdsk1 g asmdsk2
ASMCMD> md_restore t full g asmdsk1 i backup_file
ASMCMD> lsdsk -k DATA *_0001
Bad block repair is a new feature that runs automatically on normal or high redundancy
disk groups. When a normal read from an ASM disk group fails with an I/O error, ASM
attempts to repair that block by reading from the mirror copy and write to it and by

relocating it if the copy failed to produce a good read. This whole process happens
automatically only on blocks that are read.
It is possible that some blocks and extents on an ASM disk group are seldom read.
One prime example is the secondary extents. The ASMCMD's repair command is
designed to trigger a read on these extents, so the resulting failure in I/O can start the
automatic block repair process. One can use the ASMCMD's repair interface if the
storage array returns an error on a physical block, then the ASMCMD repair can initiate a
read on that block to trigger the repair.
ASM Variable Size Extents is an automated feature that enables ASM to support larger
file size while improving memory usage efficiency. An ASM file begins with an extent
equal to one AU.
As the file size increases, the extent size also increases to 8 AU and then to 64 AU at a
predefined number of extents. The size of the extent map that defines a file can be
smaller by a factor of 8 and 64 depending on the file size. The initial extent size is equal
to the allocation unit size and it increases by a factor of 8 and 64 at predefined
thresholds.
Fewer extent pointers are needed to describe the file and less memory is required to
manage the extent maps in the shared pool, which would have been prohibitive in large
file configurations. Extent size can vary both across files and within files.
Variable size extents also enable you to deploy Oracle databases using ASM storage that
are several hundred TB even several PB in size. The management of variable size
extents is completely automated and does not require manual administration.
However, external fragmentation may occur when a large number of non-contiguous
small data extents have been allocated and freed, and no additional contiguous large
extents are available. A defragmentation operation is integrated as part of the rebalance
operation. So, as a DBA, you always have the possibility to defragment your disk group
by executing a rebalance operation.
ASM imposes some limits:

63 disk groups in a storage system

10,000 ASM disks in a storage system

4 petabyte maximum storage for each ASM disk

40 exabyte maximum storage for each storage system

1 million files for each disk group

maximum files sizes depending on the redundancy type of the disk groups used
ASM imposes a maximum file size of

140 PB for external redundancy the value is currently greater than the possible database file
size

42 PB for normal redundancy

15 PB for high redundancy

Question
What can the ASMCMD utility be used for?
Options:
1.

Altering ASM disk groups

2.

Creating ASM disk groups

3.

Starting up an ASM instance

4.

Viewing and manipulating ASM files and directories

Answer
ASMCMD is a command line utility that can be used for viewing and manipulating
ASM files and directories.
Option 1 is incorrect. You use SQL*Plus to issue ALTER commands for ASM disk
groups. You must be a member of the SYSASM, SYSDBA, or SYSOPER roles to be
able to issue alter commands.
Option 2 is incorrect. ASM disk groups can be created from the SQL prompt using
SQL*Plus. You must be a member of the SYSASM or SYSDBA roles to be able to
issue the create command.
Option 3 is incorrect. Members of the SYSASM, SYSDBA, or SYSOPER roles can
start up or shut down an ASM from the SQL prompt using SQL*Plus, not
ASMCMD.
Option 4 is correct. The ASMCMD command line utility can be used to view and
manipulate files and directories within ASM disk groups. ASMCMD can list the
contents of disk groups, perform searches, create and remove directories, and
more.

Summary
ASM storage does not eliminate any existing database functionality. New files may be
created as ASM files, and existing ones are administered in the old way or can be
migrated to ASM. ASM files are always spread across all the ASM disks in a disk group.

You can remove a disk from a disk group by using the ALTER DISKGROUP and DROP
DISK commands. You can cancel a disk drop operation by using the UNDROP command.
The MOUNT and DISMOUNT options allow you to make one or more disk groups available
or unavailable to the database instances.
ASMCMD is a command line utility that you can use to view and manipulate files and
directories within ASM disk groups. ASMCMD can perform ASM metadata backup and
restore functionality. ASM Variable Size Extents is an automated feature that enables
ASM to support larger file size while improving memory usage efficiency.

Table of Contents
| Top of page |
| Learning objective |
| 1. ASM storage concepts |
| 2. ALTER commands |
| 3. ASMCMD utility |
| Summary |
Copyright 2007 SkillSoft. All rights reserved.
SkillSoft and the SkillSoft logo are trademarks or registered trademarks
of SkillSoft in the United States and certain other countries.
All other logos or trademarks are the property of their respective owners.

| Print | Contents | Close |

Creating an ASM Instance and Disk Groups

Learning objective

After completing this topic, you should be able to create an ASM instance and disk group
and use the ASMCMD to view disk group data.

Exercise overview
In this exercise, you're required to use DBCA to create an ASM instance and configure
two disk groups for the ASM instance. You are also required to use ASMCMD commands
to view and manage files stored in the ASM disk groups.
This involves the following tasks:

creating an ASM instance

creating disk groups

using ASMCMD

Task 1: Creating an ASM instance

Start the Database Configuration Assistant and create an ASM instance. When prompted
to run the localconfig add script, minimize the DBCA and open a new terminal window.
Type "su" to switch to the root user and specify "oracle" as the password. Run the script
using the "/u01/app/oracle/product/11.1.0/db_1/bin/localconfig add" command. Return to
the DBCA, confirm the SYS password is "oracle" and start the ASM instance.

Steps list
Instructions
1. Type dbca and press Enter
2. On the Database Configuration Assistant : Welcome page, click Next
3. On the Operations page, select Configure Automatic Storage Management and click Next
4. Click OK and click the Minimize icon
5. Double-click the Terminal icon
6. Type su and press Enter and type oracle and press Enter
7. Type /u01/app/oracle/product/11.1.0/db_1/bin/localconfig add and press Enter
8. Click the Minimize icon
9. Click Next, type oracle in the SYS password and Confirm SYS password text boxes and click Next
10. Click OK

Task 2: Creating disk groups

Configure two disk groups called "DATA" and "FRA." Specify that the DATA disk group
uses four 2.8 GB raw slices - raw1, raw2, raw3, and raw4 - and employs normal
redundancy. Specify that the FRA disk group uses four 2.8 GB slices - raw5, raw6, raw7,
and raw8 - and employs external redundancy. Ensure that both databases are mounted
and do not perform other DBCA operations.

Steps list
Instructions
1. On the ASM Disk Groups page, click Create New
2. In the Create Disk Group dialog box, type DATA in the Disk Group Name text box and press Enter
3. Select the checkboxes for the raw1, raw2, raw3, and raw4 disk paths in the Select Member Disks section and

Steps list
Instructions
click OK
4. Click Create New
5. In the Create Disk Group dialog box, type FRA in the Disk Group Name text box and select External
6. Click the Select All checkbox to select the four disk paths and click OK
7. Click Finish
8. On the Database Configuration Assistant dialog box, click No

Task 3: Using ASMCMD

Start ASMCMD and view the contents of the +DATA disk group using the command "ls
+DATA/*." List the contents of the DATAFILE directory using the command "ls
+DATA/ORCL/DATAFILE." Create a new directory called jmw in the DATA disk group
using the command "mkdir +DATA/jmw." Then use ASMCMD to back up ASM metadata
for the DATA disk group using the command "md_backup -g data."

Steps list
Instructions
1. Type asmcmd and press Enter
2. Type ls +DATA/* and press Enter
3. Type ls +DATA/ORCL/DATAFILE and press Enter
4. Type mkdir +DATA/jmw and press Enter
5. Type md_backup -g data and press Enter

Table of Contents
| Top of page |
| Learning objective |
| Exercise overview |
| Task 1: Creating an ASM instance |
| Task 2: Creating disk groups |
| Task 3: Using ASMCMD |

Copyright 2008 SkillSoft. All rights reserved.

SkillSoft and the SkillSoft logo are trademarks or registered trademarks
of SkillSoft in the United States and certain other countries.
All other logos or trademarks are the property of their respective owners.