3 Administering ASM Instances

Initialization Parameter Files for an ASM Instance

When installing ASM for a single-instance Oracle Database, DBCA creates a separate server parameter file (SPFILE) and password file for the ASM instance. When installing ASM in a clustered ASM environment where the ASM home is shared among all of the nodes, DBCA creates an SPFILE for ASM. In a clustered environment without a shared ASM home, DBCA creates a text-based initialization parameter file (PFILE) for ASM on each node.

You can use an SPFILE or PFILE as the ASM instance parameter file. If you use an SPFILE in a clustered ASM environment, then you must place the SPFILE on a shared raw device or on a cluster file system. If you do not use a shared ASM home, then the ASM instance uses a PFILE.

The same rules for file name, default location, and search order that apply to database initialization parameter files also apply to ASM initialization parameter files. For example, in single-instance UNIX and Linux Oracle Database environments, the server parameter file for ASM has the following path:

$ORACLE_HOME/dbs/spfile+ASM.ora

Setting ASM Initialization Parameters

There are several initialization parameters that you must set for an ASM instance. You can set these parameters when you create your database using DBCA. You can also set some of these parameters after database creation using Oracle Enterprise Manager or SQL ALTER SYSTEM or ALTER SESSION statements.

The INSTANCE_TYPE initialization parameter is the only required parameter in the ASM instance parameter file. The ASM* parameters use suitable defaults for most environments. You cannot use parameters with names that are prefixed with ASM* in database instance parameter files.

Some database initialization parameters are also valid for an ASM instance initialization file. In general, ASM selects the appropriate defaults for database parameters that are relevant to an ASM instance.

ASM Parameter Setting Recommendations

This section contains information about the following parameters for ASM:

• ASM_DISKGROUPS

• ASM_DISKSTRING

• ASM_POWER_LIMIT

• ASM_PREFERRED_READ_FAILURE_GROUPS

• DB_CACHE_SIZE

• DIAGNOSTIC_DEST

• INSTANCE_TYPE

• LARGE_POOL_SIZE

• PROCESSES

• REMOTE_LOGIN_PASSWORDFILE

• SHARED_POOL_SIZE

SQL> ALTER SYSTEM SET ASM_DISKGROUPS = 'CONTROLFILE, DATAFILE, LOGFILE, STANDBY'

Setting Database Initialization Parameters for Use with ASM

When you do not use automatic memory management in a database instance, the SGA parameter settings for a database instance may require minor modifications to support ASM. When you use automatic memory management, the sizing data discussed in this section can be treated as informational only or as supplemental information to help determine the appropriate values that you should use for the SGA. Oracle highly recommends using automatic memory management.

The following are guidelines for SGA sizing on the database instance:

• PROCESSES initialization parameter—Add 16 to the current value

• LARGE_POOL_SIZE initialization parameter—Add an additional 600K to the current value

• SHARED_POOL_SIZE initialization parameter—Aggregate the values from the following queries to obtain the current database storage size that is either already on ASM or will be stored in ASM. Next, determine the redundancy type and calculate the SHARED_POOL_SIZE using the aggregated value as input.

  SELECT SUM(bytes)/(1024*1024*1024) FROM V$DATAFILE;
  SELECT SUM(bytes)/(1024*1024*1024) FROM V$LOGFILE a, V$LOG b
         WHERE a.group#=b.group#;
  SELECT SUM(bytes)/(1024*1024*1024) FROM V$TEMPFILE 
         WHERE status='ONLINE'; 
  

  • For disk groups using external redundancy, every 100 GB of space needs 1 MB of extra shared pool plus 2 MB

  • For disk groups using normal redundancy, every 50 GB of space needs 1 MB of extra shared pool plus 4 MB

  • For disk groups using high redundancy, every 33 GB of space needs 1 MB of extra shared pool plus 6 MB

Disk Group Attributes

Disk group attributes are essentially parameters that are bound to a disk group, rather than an instance. The disk group attributes are:

• AU_SIZE

  For information about allocation unit size and extents, see "Extents". For an example of the use of the AU_SIZE attribute, see Example 4-1, "Creating a Disk Group".

• COMPATIBLE.ASM

  For information about the COMPATIBLE.ASM attribute, see "COMPATIBLE.ASM".

• COMPATIBLE.RDBMS

  For information about the COMPATIBLE.RDBMS attribute, see "COMPATIBLE.RDBMS".

• DISK_REPAIR_TIME

  For information about the DISK_REPAIR_TIME attribute, see "ASM Fast Mirror Resync".

Administering ASM Instances with Server Control Utility

In addition to the ASM administration procedures that this section describes, you can use Server Control Utility (SRVCTL) in clustered ASM environments to perform the following ASM administration tasks:

• Add and remove ASM instance records in the Oracle Cluster Registry (OCR)

• Enable, disable, start, and stop ASM instances

• Display the ASM instance configuration and status

Starting Up an ASM Instance

You start an ASM instance similarly to the way in which you start an Oracle database instance with some minor differences. When starting an ASM instance, note the following:

• To connect to an ASM instance with SQL*Plus, set the ORACLE_SID environment variable to the ASM SID. The default ASM SID for a single-instance database is +ASM, and the default SID for ASM for an Oracle RAC node is +ASMnode_number where node_number is the number of the node. Depending on your operating system and whether you installed ASM in a separate ASM home, you might have to change other environment variables.

• The initialization parameter file must contain the following entry:

  INSTANCE_TYPE = ASM

  This parameter indicates that an ASM instance, not a database instance, is starting.

• When you run the STARTUP command, rather than trying to mount and open a database, this command attempts to mount the disk groups specified by the initialization parameter ASM_DISKGROUPS. If you have not entered a value for ASM_DISKGROUPS, then the ASM instance starts and Oracle displays an error that no disk groups were mounted. You can then mount disk groups with the ALTER DISKGROUP...MOUNT command.

  See Also:

  "Mounting and Dismounting Disk Groups" for more information

  ASM provides a MOUNT FORCE option to enable ASM disk groups to be mounted in normal or high redundancy modes even though some ASM disks may be unavailable to the disk group at mount time. The default behavior without the FORCE option is to fail to mount a disk group that has damaged or missing disks.

  To successfully mount with the MOUNT FORCE option, ASM must be able to find at least one copy of the extents for all of the files in the disk group. In this case, ASM can successfully mount the disk group, but with potentially reduced redundancy. If all disks are available, then using the FORCE option causes the MOUNT command to fail as well. This discourages unnecessary and improper use of the feature.

  ASM puts the unavailable disks in an offline mode if ASM is unable to access them. ASM then begins timing the period that these disks are in an offline mode. If the disk offline time period exceeds the timer threshold, then ASM permanently drops those disks from the disk group. You can change the offline timer after a disk is put in an offline state by using the ALTER DISKGROUP OFFLINE statement.

  The MOUNT FORCE option is useful in situations where a disk is temporarily unavailable and you want to mount the disk group with reduced redundancy while you correct the situation that caused the outage.

  Note:

  An ASM instance mounts an incomplete disk group differently depending on the specified compatibility as discussed under the heading "Disk Group Compatibility".

• The associated Oracle database instance does not need to be running when you start the associated ASM instance.

The following list describes how ASM interprets SQL*Plus STARTUP command parameters.

• FORCE Parameter

  Issues a SHUTDOWN ABORT to the ASM instance before restarting it.

• MOUNT or OPEN Parameter

  Mounts the disk groups specified in the ASM_DISKGROUPS initialization parameter. This is the default if no command parameter is specified.

• NOMOUNT Parameter

  Starts up the ASM instance without mounting any disk groups.

• RESTRICT Parameter

  Starts up an instance in restricted mode that enables access only to users with both the CREATE SESSION and RESTRICTED SESSION system privileges. The RESTRICT clause can be used in combination with the MOUNT, NOMOUNT, and OPEN clauses.

  See Also:

  "About Restricted Mode" for more information

  In restricted mode, database instances cannot use the disk groups. In other words, databases cannot open files that are in that disk group. Also, the disk group cannot be mounted by any other instance in the cluster. Mounting the disk group in restricted mode enables only one ASM instance to mount the disk group. This mode is useful to mount the disk group for repairing configuration issues.

The following is a sample SQL*Plus session for starting an ASM instance.

Shutting Down an ASM Instance

The ASM shutdown process is initiated when you run the SHUTDOWN command in SQL*Plus. Before you run this command, ensure that the ORACLE_SID environment variable is set to the ASM SID so that you can connect to the ASM instance. Depending on your operating system and whether you installed ASM in a separate ASM home, you might have to change other environment variables before starting SQL*Plus. Oracle strongly recommends that you shut down all database instances that use the ASM instance before attempting to shut down the ASM instance.

The following list describes the SHUTDOWN modes and describes the behavior of the ASM instance in each mode.

• NORMAL Clause

  ASM waits for any in-progress SQL to complete before performing an orderly dismount of all of the disk groups and shutting down the ASM instance. Before the instance is shut down, ASM waits for all of the currently connected users to disconnect from the instance. If any database instances are connected to the ASM instance, then the SHUTDOWN command returns an error and leaves the ASM instance running. NORMAL is the default shutdown mode.

• IMMEDIATE or TRANSACTIONAL Clause

  ASM waits for any in-progress SQL to complete before performing an orderly dismount of all of the disk groups and shutting down the ASM instance. ASM does not wait for users currently connected to the instance to disconnect. If any database instances are connected to the ASM instance, then the SHUTDOWN command returns an error and leaves the ASM instance running. Because the ASM instance does not contain any transactions, the TRANSACTIONAL mode is the same as the IMMEDIATE mode.

• ABORT Clause

  The ASM instance immediately shuts down without the orderly dismount of disk groups. This causes recovery to occur upon the next ASM startup. If any database instance is connected to the ASM instance, then the database instance aborts.

ASM Background Processes

The following background processes are an integral part of Automatic Storage Management:

• ARBn performs the actual rebalance data extent movements in an Automatic Storage Management instance. There can be many of these processes running at a time, named ARB0, ARB1, and so on.

• ASMB runs in a database instance that is using an ASM disk group. ASMB communicates with the ASM instance, managing storage and providing statistics. ASMB can also run in the ASM instance. ASMB runs in ASM instances when the ASMCMD cp command runs or when the database instance first starts if the SPFILE is stored in ASM.

• GMON maintains disk membership in ASM disk groups.

• MARK marks ASM allocation units as stale following a missed write to an offline disk. This essentially tracks which extents require resync for offline disks.

• RBAL runs in both database and ASM instances. In the database instance, it does a global open of ASM disks. In an ASM instance, it also coordinates rebalance activity for disk groups.

The processes described in the previous list are important for the ASM instance and should not be modified. In addition to the processes listed in this section, there are additional processes that run in both the ASM and database instances, such as database writer process (DBWn), log writer process (LGWR), Process Monitor Process (PMON), and System Monitor Process (SMON).

Also, there are ASM slave processes that run periodically to perform a specific task. For example, the Snnn transient slave process is responsible for performing the resync of extents at the time that the disk is brought online. The slave processes are not technically background processes.

For more information about Oracle database background processes, see the discussion about background processes in Oracle Database Concepts. For a description of the V$BGPROCESS view that displays information about background processes, see the Oracle Database Reference.

About the SYSASM Privilege for ASM

SYSASM is a system privilege that enables the separation of the SYSDBA database administration privilege from the ASM storage administration privilege. Access to the SYSASM privilege is granted by membership in an operating system group that is designated as the OSASM group. This is similar to SYSDBA and SYSOPER privileges, which are system privileges granted through membership in the groups designated as the OSDBA and OSOPER operating system groups. You can designate one group for all of these system privileges, or you can designate separate groups for each operating system privilege.

You can divide system privileges during ASM installation, so that database administrators, storage administrators, and database operators each have distinct operating system privilege groups. Use the Custom Installation option to designate separate operating system groups as the operating system authentication groups for privileges on ASM. Table 3-1 lists the operating system authentication groups for ASM, and the privileges that their members are granted:

If you do not want to divide system privileges access into separate operating system groups, then you can designate one operating system group as the group whose members are granted access as OSDBA, OSOPER, OSASM, and OSDBA for ASM, and OSOPER for ASM privileges. The default operating system group name for all of these is dba. You can also specify OSASM, OSDBA for ASM, and OSOPER for ASM when you perform a custom installation of ASM. Furthermore, you can specify OSDBA and OSOPER when performing a custom database installation.

Whether you create separate operating system privilege groups or use one group to provide operating system authentication for all system privileges, you should use SYSASM to connect to and administer an ASM instance. In Oracle 11g release 1, both SYSASM and SYSDBA are supported privileges; however, if you use the SYSDBA privilege to administer an ASM instance, then Oracle will write warning messages to the alert log, indicating that the SYSDBA privilege is deprecated on an ASM instance for administrative commands. In a future release, the privilege to administer an ASM instance with SYSDBA will be removed.

Operating system authentication using membership in the group or groups designated as OSDBA, OSOPER, and OSASM is valid on all Oracle platforms. Connecting to an ASM instance as SYSASM grants you full access to all of the available ASM disk groups and management functions.

Accessing an ASM Instance

This section describes how to connect to an ASM instance. In the examples where you provide a user name, you are prompted for a password.

Use the following statement to connect locally to an ASM instance using operating system authentication:

sqlplus / AS SYSASM

Use the following statement to connect locally using password authentication:

sqlplus SYS AS SYSASM

Use the following statement to connect remotely using password authentication:

sqlplus sys@\"myhost.mydomain.com:1521/asm\" AS SYSASM

Use the following statement to connect to an ASM instance with SYSDBA privilege:

sqlplus / AS SYSDBA

Oracle writes messages to the alert log if you issue ASM administrative commands that will be accessible only to the SYSASM privilege in future releases.

Creating Users with the SYSASM Privilege

When you are logged in to an ASM instance as SYSASM, you can use the combination of CREATE USER and GRANT SQL statements to create a new user who has the SYSASM privilege. These commands update the password file for the local ASM instance. Similarly, you can revoke the SYSASM privilege from a user using the REVOKE command, and you can drop a user from the password file using the DROP USER command. The following example describes how to perform these operations for the user identified as new_user:

REM create a new user, then grant the SYSASM privilege
SQL> CREATE USER new_user IDENTIFIED by new_user_passwd;
SQL> GRANT SYSASM TO new_user;

REM connect the user to the ASM instance
SQL> CONNECT new_user AS SYSASM;
Enter password:

REM revoke the SYSASM privilege, then drop the user
SQL> REVOKE SYSASM FROM new_user;
SQL> DROP USER new_user;

Operating System Authentication for ASM

Membership in the operating system group designated as the OSASM group provides operating system authentication for the SYSASM system privilege. OSASM is provided exclusively for ASM. Initially, only the user that installs ASM is a member of the OSASM group, if you use a separate operating system group for that privilege. However, you can add other users. Members of the OSASM group are authorized to connect using the SYSASM privilege and have full access to ASM, including administrative access to all disk groups that are managed by that ASM instance.

On Linux and UNIX systems, the default operating system group designated as OSASM, OSOPER, and OSDBA is dba. On Windows systems, the default name designated as OSASM, OSOPER, and OSDBA is ora_dba.

Password File Authentication for ASM

Password file authentication for ASM can work both locally and remotely. To enable password file authentication, you must create a password file for ASM. A password file is also required to enable Oracle Enterprise Manager to connect to ASM remotely.

If you select the ASM storage option, then DBCA creates a password file for ASM when it initially configures the ASM disk groups. Similar to a database password file, the only user added to the password file when DBCA creates it is SYS. To add other users to the password file, you can use the CREATE USER and GRANT commands as described previously in the section titled "About the SYSASM Privilege for ASM".

If you configure an ASM instance without using DBCA, then you must manually create a password file and GRANT the SYSASM privilege to user SYS.

Using Oracle Enterprise Manager to Migrate Databases to ASM

Enterprise Manager enables you to perform cold and hot database migration with a GUI. You can access the migration wizard from the Enterprise Manager Home page under the Change Database heading.

Manually Migrating to ASM Using Oracle Recovery Manager

You can use Oracle Recovery Manager (RMAN) to manually migrate to ASM. You can also use RMAN to migrate a single tablespace or datafile to ASM.

Migrating to ASM Best Practices White Papers on Oracle Technology Network (OTN)

The Oracle Maximum Availability Architecture (MAA) Web site provides excellent best practices technical white papers based on different scenarios, such as:

• Minimal Downtime Migration to ASM

• Platform Migration using Transportable Tablespaces

• Platform Migration using Transportable Database