# Administering an ASM Instance - Oracle 10g

The functionality of an ASM instance can be summarized as follows:

• It manages groups of disks, called disk groups.
• It protects the data within a disk group.
• It provides near-optimal I/O balancing without any manual tuning.
• It enables the user to manage database objects such as tablespaces without needing to specify and track filenames.
• It supports large files.

This section discusses the administration of an ASM instance in terms of its startup and shutdown, and its behavior and interaction with the database instance. The major part of the administration of an ASM instance, once it is started, is the creation and maintenance of disk groups and their metadata. This section contains the following topics:

• Installation of ASM
• Authentication for Accessing an ASM Instance
• Setting Initialization Parameters for an ASM Instance
• Starting Up an ASM Instance
• Shutting Down an ASM Instance
• Disk Group Fixed Tables

Installation of ASM

Automatic Storage Management is always installed by the Oracle Universal Installer when you install your database software. The Database Configuration Assistant (DBCA) determines if an ASM instance already exists, and if not, then you are given the option of creating and configuring an ASM instance as part of database creation and configuration. If an ASM instance already exists, then it is used instead. DBCA also configures your instance parameter file and password file.

Authentication for Accessing an ASM Instance

Automatic Storage Management security considerations derive from the fact that a particular ASM instance is tightly bound to one or more database instances operating on the same server. In effect, the ASM instance is a logical extension of these database instances. Both the ASM instance and the database instances must have equivalent operating system access rights (read/write) to the disk group member disks. For UNIX this is typically provided through shared UNIX group membership.

ASM instances do not have a data dictionary, so the only way to connect to one is as an administrator. This means you use operating system authentication and connect as SYSDBA or SYSOPER, or to connect remotely, use a password file.

Using operating system authentication, the authorization to connect with the SYSDBA privilege is granted through the use of an operating system group. On UNIX, this is typically the dba group. By default, members of the dba group are authorized to connect with the SYSDBA privilege on all instances on the node, including the ASM instance. Users who connect to the ASM instance with SYSDBA privilege have complete administrative access to all disk groups that are managed by that ASM instance.

Setting Initialization Parameters for an ASM Instance

Some initialization parameters are specifically relevant to an ASM instance. Of those initialization parameters intended for a database instance, only a few are relevant to an ASM instance. You can set those parameters at database creation time using Database Configuration Assistant or later using Enterprise Manager. The remainder of this section describes setting the parameters manually by editing the initialization parameter file.

Initialization Parameters for ASM Instances

The following initialization parameters relate to an ASM instance. Parameters that start with ASM_ cannot be set in database instances.

Name Description

Tuning Rebalance Operations

Oracle Database can perform one rebalance at a time on a given instance. The rebalance power is constrained by the value of the ASM _POWER _LIMIT initialization parameter. You can adjust this parameter dynamically. The higher the limit, the faster a rebalance operation may complete. Lower values cause rebalancing to take longer, but consume fewer processing and I/O resources. If the POWER clause is not specified, or when rebalance is implicitly invoked by adding or dropping a disk, the power defaults to the ASM_POWER_LIMIT.

The V$ASM _OPERATION view provides information that can be used for adjusting ASM _POWER _LIMIT and the resulting power of rebalance operations. If the DESIRED _POWER column value is less than the ACTUAL _POWER column value for a given rebalance operation, then ASM _POWER _LIMIT is impacting the rebalance. The V$ASM _OPERATION view also gives an estimate in the EST _MINUTES column of the amount of time remaining for the operation to complete. You can see the effect of changing the power of rebalance by observing the change in the time estimate.

If a rebalance is in progress because a failed disk is being dropped, increasing the power of the rebalance shortens the window during which redundant copies on the failed disk are being reconstructed on other disks. Lowering ASM _POWER _LIMIT reduces the amount of CPU and I/O bandwidth that Automatic Storage Management consumes for a rebalance. This leaves these resources available for other applications, such as the database.

The default value errors on the side of minimizing disruption to other applications. The appropriate value is dependent upon your hardware configuration as well as performance and availability requirements.

Improving Disk Discovery Time

The value for the ASM _DISKSTRING initialization parameter is an operating system dependent value used by Automatic Storage Management to limit the set of disks considered for discovery. When a new disk is added to a disk group, each ASM instance that has the disk group mounted must be able to discover the new disk using its ASM _DISKSTRING.

In many cases, the default value is sufficient. Using a more restrictive value may reduce the time required for Automatic Storage Management to perform discovery, and thus improve disk group mount time or the time for adding a disk to a disk group. It may be necessary to dynamically change the ASM_DISKSTRING before adding a disk so that the new disk will be discovered through this parameter.

If your site is using a third-party vendor ASMLIB, that vendor may have discovery string conventions that should be used for ASM_DISKSTRING.

Behavior of Database Initialization Parameters in an ASM Instance

If you specify a database instance initialization parameter in an ASM initialization parameter file, it can have one of three effects:

• If the parameter is not valid in the ASM instance, it produces a ORA-15021 error.
• Some database parameters can be specified and are valid in an ASM instance, for example those relating to dump destinations and some buffer cache parameters. In general, Oracle will select appropriate defaults for any database parameters that are relevant to the ASM instance.

If you specify any of the ASM specific parameters (names start with ASM_) in a database instance parameter file, you will receive an ORA-15021 error.

Starting Up an ASM Instance

ASM instances are started similarly to Oracle database instances with some minor differences. These are:

• The initialization parameter file, which can be a server parameter file, must contain:
INSTANCE_TYPE = ASM

This parameter signals the Oracle executable that an ASM instance is starting and not a database instance. Using a server parameter file is recommended because it eliminates the need to make manual changes to a text initialization parameter file.

• For ASM instances, STARTUP tries to mount the disk groups specified by the initialization parameter ASM _DISKGROUPS and not the database.

Further, the SQL*Plus STARTUP command parameters are interpreted by Automatic Storage Management as follows:

The following is a sample SQL*Plus session where an ASM instance is started:

% sqlplus /nolog
SQL> CONNECT / AS sysdba Connected to an idle instance. SQL> STARTUP ASM instance started Total System Global Area 147936196 bytes Fixed Size 324548 bytes Variable Size 96468992 bytes Database Buffers 50331648 bytes Redo Buffers 811008 bytes ASM diskgroups mounted

ASM Instance Memory Requirements

ASM instances are smaller than database instances. A 64 MB SGA should be sufficient for all but the largest ASM installations.

Disk Discovery

When an ASM instance initializes, ASM is able to discover and look at the contents of all of the disks in the disk groups that are pointed to by the ASM_DISKSTRING initialization parameter. This saves you from having to specify a path for each of the disks in the disk group.

Disk group mounting requires that an ASM instance doing disk discovery be able to access all the disks within the disk group that any other ASM instance having previously mounted the disk group believes are members of that disk group. It is vital that any disk configuration errors be detected before a disk group is mounted. Automatic Storage Management attempts to identify the following configuration errors:

1. A single disk with different mount points is presented to an ASM instance. This can be caused by multiple paths to a single disk. In this case, if the disk in question is part of a disk group, disk group mount fails. If the disk is being added to a disk group with ADD DISK or CREATE DISKGROUP, the command fails. To correct the error, restrict the disk string so that it does not include multiple paths to the same disk.
2. Multiple ASM disks, with the same ASM label, passed to separate ASM instances as the same disk. In this case, disk group mount fails.
3. Disks that were not intended to be ASM disks are passed to an ASM instance by the discovery function. ASM does not overwrite a disk if it recognizes the header as that of an Oracle object.

Disk Group Recovery

When an ASM instance fails, then all Oracle database instances on the same node as that ASM instance and that use a disk group managed by that ASM instance also fail. In a single ASM instance configuration, if the ASM instance fails while ASM metadata is open for update, then after the ASM instance reinitializes, it reads the disk group log and recovers all transient changes.

With multiple ASM instances sharing disk groups, if one ASM instance should fail, another ASM instance automatically recovers transient ASM metadata changes caused by the failed instance. The failure of an Oracle database instance is not significant here because only ASM instances update ASM metadata.

Shutting Down an ASM Instance

Using SQL*Plus, Automatic Storage Management shutdown is initiated by issuing the SHUTDOWN command. For example:

% sqlplus /nolog SQL> CONNECT / AS sysdba Connected. SQL> SHUTDOWN NORMAL

The table that follows lists the SHUTDOWN modes and describes the behavior of the ASM instance in each mode.

Disk Group Fixed Tables

A number of fixed tables, visible from both the ASM and database instances are provided for administrative and debugging purposes.