The Basics
Automatic Storage Management (ASM) provides vertical integration of the file system and the volume manager for Oracle database files. ASM can provide management for single symmetric multiprocessing (SMP) machines or across multiple nodes of a cluster for Oracle Real Application Clusters (RAC) support.
Oracle ASM Cluster File System (ACFS) is a multi-platform, scalable file system, and storage management technology that extends ASM functionality to support application files outside of the Oracle Database such as executables, reports, BFILEs, video, audio, text, images, and other general-purpose application file data.
ASM distributes input/output (I/O) load across all available resources to optimize performance while removing the need for manual I/O tuning. ASM helps database administrators (DBAs) manage a dynamic database environment by enabling them to increase the database size without having to shut down the database to adjust storage allocation.
ASM can maintain redundant copies of data to provide fault tolerance, or it can be built on top of vendor-supplied storage mechanisms. 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 the DBA’s time by automating manual storage and thereby increasing the administrator’s ability to manage more and larger databases with increased efficiency.
ASM Instance
Every time ASM or a database is started, a shared memory area called the system global area (SGA) is allocated and Oracle ASM or database background processes are started. The combination of the background processes and the SGA is called an Oracle ASM instance or an Oracle Database instance. The instance represents the CPU and RAM components of a running ASM environment. The SGA in an ASM instance is different in memory allocation and usage than the SGA in a database instance. The SGA in the ASM instance is divided into four primary areas as follows:
- Shared Pool: Used for metadata information
- Large Pool: Used for parallel operations
- ASM Cache: Used for reading and writing blocks during rebalance operations
- Free Memory: Unallocated memory available
The minimum recommended amount of memory for an ASM instance is 256 MB. Automatic memory management is enabled by default on an ASM instance and will dynamically tune the sizes of the individual SGA memory components. The amount of memory that is needed for an ASM instance will depend on the amount of disk space being managed b ASM will amount by ASM. The second part of the ASM instance is background processes. An ASM instance can have many background processes; not all of which are always present.
There are required background processes and optional background processes. Some of these processes may include the following:
- ARCn: The archiver processes
- CKPT: The checkpoint process
- DBWn: The database writer processes
- DIAG: The diagnosability process
- Jnnn: Job queue processes
- LGWR: The log writer process
- PMON: The process monitor process
- PSP0: The process spawner process
- QMNn: The queue monitor processes
- RECO: The recoverer process
- SMON: The system monitor process
- VKTM: The virtual keeper of time process
- MMAN: The memory manager process
- LREG: The listener registration process
The above list of processes is not complete. For the ASM instance, these processes will not always perform the same tasks as they would in a database instance. For example, the LGWR process in a database instance is responsible for copying change vectors from the log buffer section of the SGA to the online redo logs on disk. The ASM instance does not contain a log buffer in its SGA, nor does it use online redo logs. The LGWR process in an ASM instance copies logging information to an ASM disk group.
If ASM is clustered, then additional processes related to cluster management will be running in the ASM instance. Some of these processes include the following:
- LMON: The global enqueue service monitor process
- LMDn: The global enqueue service daemons
- LMSn: The global cache service processes
- LCKn: The lock processes
ASM Components – Primary Processes
The ASM instance uses dedicated background processes for much of its functionality. The RBAL process coordinates rebalance activity for disk groups in an Automatic Storage Management instance. It performs a global open on Automatic Storage Management disks. The ARBn processes perform the actual rebalance data extent movements in an Automatic Storage Management instance. There can be many of these at a time, called ARB0, ARB1, and so on. The GMON process maintains disk membership in ASM disk groups. The MARK process marks ASM allocation units as stale following a missed write to an offline disk. The Onnn processes represent the server side of a client/server connection. These processes will appear the moment the instance is started and will disappear after that. They form a pool of connections to the ASM instance for exchanging messages and only appear when needed.
| Process | Description |
|---|---|
| RBAL | Opens all device files as part of the discovery and coordinates the rebalance activity |
| ARBn | One or more slave processes that do the rebalance activity |
| GMON | Responsible for managing the disk-level activities such as drop or offline and advancing the ASM disk group compatibility |
| MARK | Marks ASM allocation units as stale when needed |
| Onnn | One or more ASM slave processes forming a pool of connections to the ASM instance for exchanging messages |
Interaction Between Database Instances and ASM
The file creation process provides an illustration of the interactions that take place between database instances and ASM. The file creation process occurs as follows:
- The database requests file creation.
- An foreground process creates a Continuing Operation Directory entry and allocates space for the new file across the disk group.
- The ASMB database process receives an extent map for the new file.
- The file is now open and the database process initializes the file directly.
- After initialization, the database process requests that the file creation is committed. This causes the ASM foreground process to clear the COD entry and mark the file as created.
- Acknowledgment of the file commit implicitly closes the file. The database instance will need to reopen the file for future I/O.
This example reinforces two important points about the architecture of ASM:
– The Database Instance and ASM Instance work together in a coordinated fashion. A Database instance must interact with ASM to map database files to ASM extents. A Database instance also receives a constant stream of messages relating to ASM operations (such as disk group rebalancing) that may lock or move ASM extents.
– The database I/O is not channeled through the ASM instance. In fact, the database conducts I/O operations directly against ASM files, as illustrated in step 4 in the slide.
Oracle Automatic Storage Management (Oracle ASM) Tools
You can use Oracle ASM Configuration Assistant (ASMCA) to install and configure Oracle ASM instances, disk groups, volumes, and Oracle Automatic Storage Management Cluster File System (Oracle ACFS). Oracle ASM Command-Line Utility (ASMCMD) is a command-line utility that you can use to manage:
- Oracle ASM instances
- Disk groups
- File access control for disk groups
- Files and directories within disk groups
- Templates for disk groups
- Volumes