9.2. Understanding an ASM Instance

ASM instances cannot be accessed using the methods available with a traditional database. In the following sections, we will talk about the privileges available to you that connect with SYSDBA and SYSOPER privileges. We will also distinguish an ASM instance by the new and expanded initialization parameters available only for an ASM instance. Finally, we will describe the procedures for starting and stopping an ASM instance and the dependencies between ASM instances and the traditional RDBMS database instances that they serve.

9.2.1. Creating an ASM Instance

ASM requires a dedicated instance to manage the disk groups. An ASM instance generally has a smaller memory footprint in the range of 60MB to 100MB and is automatically configured when ASM is specified as the database's file storage option when installing the Oracle software and an existing ASM instance does not already exist (see Figure 9.2).

As an example, suppose your Linux server has a number of raw disk devices with the capacities listed in Table 9.1.

Figure 9.2. Specifying ASM for database file storage

Configure the first disk group within the Oracle Universal Installer (OUI), as shown in Figure 9.3.

Figure 9.3. Specifying disk group member disks

The name of the first disk group is DATA1, and you will be using /dev/raw/raw1 and /dev/ raw/raw2 to create the normal redundancy disk group. After the database has been created, both the regular instance and the ASM instance are started.

An ASM instance has a few other unique characteristics. While it does have an initialization parameter file and a password file, it has no data dictionary or control file. Therefore, all connections to an ASM instance are via SYS and SYSTEM using operating system authentication only. Disk group commands such as CREATE DISKGROUP, ALTER DISKGROUP, and DROP DISKGROUP are valid only from an ASM instance. Finally, an ASM instance is in either a MOUNT state or a NOMOUNT state; it can never be in an OPEN state. The only difference between the MOUNT state and the NOMOUNT state is that the MOUNT state mounts the ASM disk groups and makes them available to other instances.

9.2.2. Connecting to an ASM Instance

As mentioned in the previous section, an ASM instance does not have a data dictionary, so access to the instance is restricted to users who can authenticate with the operating system—in other words, connecting as SYSDBA or SYSOPER by an operating system user that is in the dba group.

Users who connect to an ASM instance as SYSDBA can perform all ASM operations such as creating and deleting disk groups as well as adding and removing disks from disk groups.

The SYSOPER users have a much more limited set of commands available in an ASM instance. In general, the commands available to SYSOPER commands give only enough privileges to perform routine operations for an already configured and stable ASM instance. The following list contains the operations available as SYSOPER:

• Starting up and shutting down an ASM instance

• Mounting or dismounting a disk group

• Altering a disk group's disk status to ONLINE or OFFLINE

• Rebalancing a disk group

• Performing an integrity check of a disk group

• Accessing V$ASM_* dynamic performance views

9.2.3. Starting Up and Shutting Down an ASM Instance

An ASM instance is started much like a database instance, except that the STARTUP command defaults to STARTUP MOUNT. Because there is no control file, database, or data dictionary to mount, the ASM disk groups are mounted instead of a database. STARTUP NOMOUNT starts up the instance but does not mount any ASM disks. In addition, you can specify STARTUP RESTRICT to temporarily prevent database instances from connecting to the ASM instance to mount disk groups. If an ASM instance is already started, you can use this command in an ASM instance to prevent other database instances from connecting to the ASM instance:

SQL> alter system enable restricted session;
System altered.

Similarly, you can re-enable connections as in this example:

SQL> alter system disable restricted session;

System altered.

Performing a SHUTDOWN command on an ASM instance performs the same SHUTDOWN command on any database instances using the ASM instance; before the ASM instance finishes a shutdown, it waits for all dependent databases to shut down. The only exception to this is if you use the SHUTDOWN ABORT command on the ASM instance, the ASM instance does not pass the ABORT command to the dependent databases. However, all dependent databases immediately perform a SHUTDOWN ABORT because there is no longer an ASM instance available to manage the database's storage.

For multiple ASM instances sharing disk groups, such as in a RAC environment, the failure of an ASM instance does not cause the database instances to fail. Instead, another ASM instance performs a recovery operation for the failed instance.