Administration of ASM

Administering ASM

Administering an Oracle ASM instance is similar to administering an Oracle Database instance, but the process requires fewer procedures. You can use Oracle Enterprise Manager and SQL*Plus to perform Oracle ASM instance administration tasks.

Oracle ASM is installed in the Oracle Grid Infrastructure home separate from the Oracle Database home. Only one Oracle ASM instance is supported on a server. When managing an Oracle ASM instance, the administration activity must be performed in the Oracle Grid Infrastructure home.

Objectives

• Explain and apply Automatic Storage Management (ASM) initialization parameters
• Manage ASM instances and associated processes
• Monitor ASM using the V$ASM dynamic performance views

Topics

1. ASM Overview
2. Administration - ASM
3. ASM Components ASM Instance
4. ASM and ASM Cluster File System
5. Starting Up an Oracle ASM Instance
6. Shutting Down an Oracle ASM Instance
7. Oracle Automatic Storage Management 11g Release 2 (11.2.0.2) New Features
8. Configuring Initialization Parameters for Oracle ASM Instances
9. Setting Oracle ASM Initialization Parameters
10. Viewing ASM Disk Statistics
11. Preferred Read Failure Groups
12. ASM Fast Mirror Resync
13. Viewing ASM Disk Groups
14. Disk Group Attributes
15. Administering ASM Disk Groups
16. ASM_POWER_LIMIT
17. Disk Groups Mounted at Startup
18. ASM System Privileges

Refer the links below:

Administering Oracle ASM Instances

Viewing ASM Disk Statistics

V$ASM_DISK_IOSTAT displays information about disk I/O statistics for each ASM client.
If V$ASM_DISK_IOSTAT is queried from a database instance, only the rows relating to that instance are shown.
ASMCMD lsdsk --statistics shows just the disk statistics.
ASMCMD iostat shows a subset of the statistics depending on the option.

SQL> SELECT INSTNAME, G.NAME DISKGROUP, SUM(READS) READS,

  2    SUM(BYTES_READ) BYTES_READ, SUM(WRITES) WRITES,

  3    SUM(BYTES_WRITTEN) BYTES_WRITTEN

  4  FROM V$ASM_DISK_IOSTAT I, V$ASM_DISKGROUP G

  5  WHERE I.GROUP_NUMBER = G.GROUP_NUMBER

  6  GROUP BY INSTNAME, G.NAME;

The following query quickly shows the presence of any I/O errors reported by ASM. If this query returns a value other than zero, further investigation may be undertaken:

SQL> SELECT SUM(READ_ERRS)+SUM(WRITE_ERRS) ERRORS

  

             2  FROM V$ASM_DISK;

Preferred Read Failure Groups

In a multisite cluster, with separate storage at each site, preferred read failure groups allow every node in the cluster to read from its local disks resulting in better performance.

Before Oracle Database 11g, ASM always read the primary copy of a mirrored extent. It may be more efficient for a node to read from a failure group extent that is closest to the node, even if it is a secondary extent. This is especially true in extended (multisite) cluster configurations where reading from a local copy of an extent provides improved performance.

With Oracle Database 11g, you can do this by configuring the preferred mirror read using the new initialization parameter, ASM_PREFERRED_READ_FAILURE_GROUPS. The disks in the identified failure groups become the preferred read disks. Thus, every node can be configured to read from its local extent copy. This results in higher efficiency and performance, and reduced network traffic. The setting for this parameter is instance specific.

If there is more than one mirrored copy and you have set a value for the ASM_PREFERRED_READ_FAILURE_GROUPS parameter, ASM first reads the copy that resides on a preferred read disk. If that read fails, ASM attempts to read from another mirrored copy that might not be on a local preferred read disk.

You can use the PREFERRED_READ column in the V$ASM_DISK view to determine whether a particular disk belongs to a preferred read failure group.

To identify performance issues with the ASM preferred read failure groups, use the V$ASM_DISK_IOSTAT view. This view displays input/output statistics for each ASM client.

+ASM1.ASM_PREFERRED_READ_FAILURE_GROUPS = DG1.F1, DG2.F3

+ASM2.ASM_PREFERRED_READ_FAILURE_GROUPS = DG1.F2, DG2.F4

ASM Fast Mirror Resync

Enabled when COMPATIBLE.RDBMS >= 11.1

Whenever ASM is unable to write an extent, ASM takes the associated disk offline. If the corresponding disk group uses ASM mirroring (NORMAL or HIGH redundancy), at least one mirror copy of the same extent exists on another disk in the disk group.

Before Oracle Database 11g, ASM assumed that an offline disk contains only stale data and no longer reads from such disks. Shortly after a disk is put offline, ASM drops it from the disk group by re-creating the extents allocated to the disk on the remaining disks in the disk group using mirrored extent copies. This process is quite resource intensive and can take hours to complete. If the disk is replaced or the failure is repaired, the disk must be added again and another rebalance operation must take place.

ASM fast mirror resync significantly reduces the time required to resynchronize a transient failure of a disk. When a disk goes offline following a transient failure, ASM tracks the extents that are modified during the outage. When the transient failure is repaired, ASM can quickly resynchronize only the ASM disk extents that have been affected during the outage.

Using ASM fast mirror resync, the failed disk is taken offline but not dropped if you have set the DISK_REPAIR_TIME attribute for the corresponding disk group. The setting for this attribute determines the duration of disk outage that ASM will tolerate while still being able to resynchronize after you complete the repair. Note that the tracking mechanism uses one bit for each modified extent and is very efficient.

Viewing ASM Disk Groups

SQL> SELECT NAME, TYPE, TOTAL_MB, FREE_MB, 
  2  REQUIRED_MIRROR_FREE_MB RMFM, USABLE_FILE_MB
  3  FROM V$ASM_DISKGROUP;


$ asmcmd lsdg

Disk Group Attributes

First introduced in Oracle Database 11g, disk group attributes govern various aspects of how a disk group functions.

AU_SIZE specifies the allocation unit size, which is the fundamental unit of space within a disk group. It is also the stripe size for coarse-grained striping. This attribute can be set only during disk group creation.

DISK_REPAIR_TIME specifies the amount of time ASM will wait from when a disk goes offline until ASM drops it and rebalances the disk group. This attribute enables the fast mirror resync feature, whereby ASM keeps track of pending changes on an offline disk during an outage and the extents are automatically resynced when the disk is brought back online.

There are three compatibility attributes. COMPATIBLE.RDBMS specifies the minimum software version required for a database instance to use files in this disk group, whereas COMPATIBLE.ASM specifies the minimum software version required for an ASM instance to mount this disk group. The compatibility attributes are discussed in greater detail later in this lesson.

The value for the disk group COMPATIBLE.ADVM attribute determines whether the disk group can contain Oracle ASM volumes. The COMPATIBLE.ASM must be set to 11.2 first, and the ASM Dynamic Volume Manager (ADVM) drivers must be loaded.



ACCESS_CONTROL.ENABLED and ACCESS_CONTROL.UMASK are discussed in more detail in the lesson tilted “Administering ASM Files, Directories, and Templates.” Both attributes can be set after the disk group is created.

SECTOR_SIZE is used to support 4KB sector disk drives.

From Oracle Database 11g version 11.1.0.7, there is a new attribute, CELL.SMART_SCAN_CAPABLE, that enables smart scan predicate offload processing if all disks in the disk group are Exadata Grid Disks.

$ asmcmd lsattr -lm -G DATA

Group_Name  Name                     Value       RO  Sys 
DATA        access_control.enabled   FALSE       N   Y   
DATA        access_control.umask     066         N   Y   
DATA        au_size                  1048576     Y   Y   
DATA        cell.smart_scan_capable  FALSE       N   N   
DATA        compatible.asm           11.2.0.0.0  N   Y   
DATA        compatible.rdbms         10.1.0.0.0  N   Y   
DATA        disk_repair_time         3.6h        N   Y   
DATA        sector_size              512         Y   Y   

Administering ASM Disk Groups

Creating a New Disk Group

CREATE DISKGROUP diskgroup_name
[ { HIGH | NORMAL | EXTERNAL } REDUNDANCY ]
{ [ FAILGROUP failgroup_name ]
DISK qualified_disk_clause [, qualified_disk_clause]...
} ...
[ ATTRIBUTE { 'attribute_name' = 'attribute_value' }... ]
;
qualified_disk_clause ::= search_string
[ NAME disk_name ]
[ SIZE size_clause ]
[ FORCE | NOFORCE ]

Example:

CREATE DISKGROUP FRA NORMAL REDUNDANCY
DISK 'ORCL:SDD11' NAME 'FRA_DISK1' SIZE 977 M,
'ORCL:SDD12' NAME 'FRA_DISK2' SIZE 977 M;



Creating a disk group (in ASM) with a 4 KB sector size:

CREATE DISKGROUP mydgroup1 NORMAL REDUNDANCY
FAILGROUP mycontroller1 DISK
'/devices/diska1',
'/devices/diska2',
'/devices/diska3',
'/devices/diska4'
FAILGROUP mycontroller2 DISK
'/devices/diskb1',
'/devices/diskb2',
'/devices/diskb3',
'/devices/diskb4'
ATTRIBUTE 'sector_size'='4096';




Creating an ASM Disk Group with ASMCA

 

ASM_POWER_LIMIT

The ASM_POWER_LIMIT initialization parameter specifies the default power for disk rebalancing.

• Default is 1.
• Meaning ASM conducts rebalancing operations using minimal system resources
• Allowable range is 0 to 1024.
• 0 disables rebalancing operations.
• Lower values use fewer system resources but result in slower rebalancing operations.
• Higher values use more system resources to achieve faster rebalancing operations.
• •It can be set dynamically using ALTER SYSTEM or ALTER SESSION.

Disk Groups Mounted at Startup

At startup, the Oracle ASM instance attempts to mount the following disk groups:

• Disk groups specified in the ASM_DISKGROUPS initialization parameter
• Disk group used by Cluster Synchronization Services (CSS) for voting files
• Disk groups used by Oracle Clusterware for the Oracle Cluster Registry (OCR)
• Disk group used by the Oracle ASM instance to store the ASM server parameter file (SPFILE)

ASM System Privileges

An ASM instance does not have a data dictionary, so the only way to connect to an ASM instance is by using one of three system privileges: SYSASM, SYSDBA, or SYSOPER.

The SYSDBA privilege on the ASM instance grants access to data stored on ASM. To use SQL*Plus commands to manage ASM components associated with the database, connect as SYSDBA to the database instance rather than the ASM instance. 

 

• Users connected as SYSDBA can create and delete files, aliases, directories, and templates; examine various ASM instance views; operate on files that were created by this user; access files to which another user has explicitly granted access; and grant ASM file access control to other users. 
•  Users connected with the SYSDBA privilege cannot create or resize a disk group.
• Note: By default, ASMCMD attempts to connect as SYSDBA based on the OS group.

Users who are granted the SYSOPER privilege on the ASM instance are allowed to start up, shut down, mount, dismount, and check disk groups (but not repair). 

 

• Other operations, such as CREATE DISKGROUP and ADD/DROP/RESIZE DISK, require the SYSASM privilege and are not allowed with the SYSOPER privilege. The SYSOPER privilege does not allow access to system views—for example, v$asm_*.

During installation, the ASMSNMP user with SYSDBA privileges is created for monitoring the Oracle ASM instance.

ASM Components 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 background processes are started. 

The combination of the background processes and the SGA is called an Oracle ASM 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 by ASM.

The second part of the ASM instance is the background processes. An ASM instance can have many background processes; not all are always present.

• 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

The preceding list of processes is not complete. There can be hundreds of database instance background processes running depending on the database options and configuration of the instance. 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 copies 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, 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

Additional processes are started when ADVM volumes are configured.

• VDBG: The Volume Driver Background process forwards ASM requests to lock or unlock an extent for volume operations to the Dynamic Volume Manager driver. The VDBG is a fatal background process so the termination of this process brings down the ASM instance.

• VBGn: Volume Background processes wait for requests from the Dynamic Volume Manager driver, which need to be coordinated with the ASM instance. An example of such a request would be opening or closing an ASM volume file when the Dynamic Volume Manager driver receives an open for a volume (possibly due to a file system mount request) or close for an open volume (possibly due to a file system unmount request). The unplanned death of any of these processes does not have an effect on the ASM instance.

• VMB: Volume Membership Background (VMB) coordinates cluster membership with the ASM instance.

ASM Components: Configuration Files

ASM instance configuration files include: 

• SPFILE
• –orapw+ASM, which is the binary password file used for remote authentication to the ASM instance

Node listener configuration files include:

• –listener.ora, a text file that defines the node listener
• –sqlnet.ora, an optional text file that provides additional listener options

Other miscellaneous text configuration files include:

• –/etc/oratab, which lists all the instances on the host machine
• –/etc/oraInst.loc, which defines the Oracle inventory directory  

Oracle Clusterware is responsible for:

• Starting and stopping ASM instances
• Starting and stopping dependent database instances
• Mounting and dismounting disk groups
• Mounting and dismounting ACFS volumes 

ASM Components: ASM Disk Group

The ASM disk group is the fundamental object that ASM manages.It: 

• Consists of one or more ASM disks that provide space
• Includes self-contained metadata and logging information for management of space within each disk group
• Is the basis for storage of ASM files
• Supports three disk group redundancy levels:
• Normal defaults to internal two-way mirroring of ASM files.
• High defaults to internal three-way mirroring of ASM files.
• External uses no ASM mirroring and relies on external disk hardware or redundant array of inexpensive disks (RAID) to provide redundancy.
• Supports ASM files from multiple databases

ASM Disk Group: Failure Groups 

A failure group is a subset of the disks in a disk group, which could fail at the same time because of shared hardware.

• Failure groups enable the mirroring of metadata and user data.
• The default failure group creation puts every disk in its own failure group.
• Multiple disks can be placed in a singe failure group at disk group creation.
• Failure groups apply only to normal and high redundancy disk groups.
• A normal redundancy disk group requires at least two failure groups to implement two-way mirroring of files.
• A high redundancy disk group requires at least three failure groups to implement three-way mirroring of files.

ASM Components: ASM Disks

ASM disks are the storage devices provisioned to ASM disk groups.

• Are formed from five sources as follows:
• A disk or partition from a storage array
• An entire physical disk or partitions of a physical disk
• Logical volumes (LV) or logical units (LUN)
• Network-Attached Files (NFS)
• Exadata grid disk
• Are named when added to a disk group using a different name than the operating system device name
• May use different operating system device names on different nodes in a cluster for the same ASM disk
• Are divided into allocation units (AU) with sizes 1, 2, 4, 8, 16, 32, or 64 MB allowed

ASM Components: ASM Files

Control files	Flashback logs	Data Pump dump sets
Data files	DB SPFILE	Data Guard configuration
Temporary data files	RMAN backup sets	Change tracking bitmaps
Online redo logs	RMAN data file copies	OCR files
Archive logs	Transport data files	ASM SPFILE

ASM and ASM Cluster File System

• In Oracle Database 11g Release 2, ASM Dynamic Volume Manager (ADVM) is available to support ASM Cluster File System (ACFS) as a general-purpose file system.
• ASM distributes input/output (I/O) load across all available disk resources within a disk group to optimize performance while removing the need for manual I/O tuning.
• ASM helps DBAs 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.
• ACFS allows storage managers to extend ASM advantages to general file storage needs.
• The capabilities of ASM and ACFS save administrators time by automating storage management and thereby increase their ability to manage larger databases (and more of them) and file systems with increased efficiency.
• ADVM with ACFS eliminates the need for a separate cluster file system for shared nondatabase files.
• ASM is a complete solution. 

ASM Key Features and Benefits

• Stripes files rather than logical volumes
• Provides redundancy on a file basis
• Enables online disk reconfiguration and dynamic rebalancing
• Reduces the time significantly to resynchronize a transient failure by tracking changes while the disk is offline
• Provides adjustable rebalancing speed
• Is cluster-aware
• Supports reading from mirrored copy instead of primary copy for extended clusters
• Is automatically installed as part of the Grid Infrastructure