This chapter describes how to administer Automatic Storage Management (ASM) instances. It explains how to configure ASM instance parameters as well how to set Oracle Database parameters for use with ASM. The chapter also describes ASM instance administration as well as upgrading, patching, and authentication for ASM instance access. You can also use procedures in this chapter to migrate a database to use ASM.
Administering an 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 ASM instance administration tasks. This chapter contains the following topics:
See Also:"About ASM Instances" for a description of an ASM instance and Chapter 6, "Administering ASM with Oracle Enterprise Manager" for information about using Enterprise Manager to administer ASM
Automatic Storage Management (ASM) in Oracle Database 11g supports both older and newer software versions of Oracle database instances, including Oracle Database 10g. Both forward and backward compatibility is maintained between Oracle Database 10g and 11g, enabling combinations of 10.1, 10.2 and 11.1 releases for ASM and database instances to successfully interoperate. For compatibility between Oracle Clusterware and ASM, the Oracle Clusterware release must be greater than or equal to the ASM release.
There are additional compatibility considerations when using disk groups with different releases of ASM and database instances. For information about disk group compatibility attributes settings, see "Disk Group Compatibility".
When using different software versions, the database instance supports ASM functionality of the earliest release in use. For example:
A 10.1 database instance operating with an 11.1 ASM instance supports only ASM 10.1 features.
An 11.1 database instance operating with a 10.1 ASM instance supports only ASM 10.1 features.
V$ASM_CLIENT view contains the
COMPATIBLE_VERSION columns with information about the software version number and instance compatibility level.
SOFTWARE_VERSION column of
V$ASM_CLIENT contains the software version number of the database or ASM instance for the selected disk group connection.
COMPATIBLE_VERSION column contains the setting of
COMPATIBLE parameter of the database or ASM instance for the selected disk group connection.
You can query the
V$ASM_CLIENT view on both ASM and database instances. For an example showing a query on the
V$ASM_CLIENT view, see Example 4-4. For more information about the
V$ASM_* views, see "Using Views to Obtain ASM Information".
This section discusses initialization parameter files and parameter settings for ASM instances. To install and initially configure an ASM instance, use Oracle Universal Installer (OUI) and Database Configuration Assistant (DBCA). Refer to your platform-specific Oracle Database Installation Guide for details about installing and configuring ASM.
After an ASM instance has been installed on a single-instance Oracle Database or in an Oracle Real Application Clusters (Oracle RAC) environment, the final ASM configuration can be performed. You only need to configure a few ASM-specific instance initialization parameters. The default values are sufficient in most cases.
See Also:The Oracle Cloud Storage page on the Oracle Technology Network Web site at
http://www.oracle.com/technetwork/database/cloud-storage/index.htmlfor more information about Oracle ASM best practices
This section contains the following topics:
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:
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
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.
See Also:"Configuring ASM Initialization Parameters" for information about setting
ASM*parameters with Oracle Enterprise Manager
Automatic memory management automatically manages the memory-related parameters for both ASM and database instances with the
MEMORY_TARGET parameter. Automatic memory management is enabled by default on an ASM instance, even when the
MEMORY_TARGET parameter is not explicitly set. The default value used for
MEMORY_TARGET is acceptable for most environments. This is the only parameter that you need to set for complete ASM memory management. Oracle strongly recommends that you use automatic memory management for ASM.
If you do not set a value for
MEMORY_TARGET, but you do set values for other memory related parameters, Oracle internally calculates the optimum value for
MEMORY_TARGET based on those memory parameter values. You can also increase
MEMORY_TARGET dynamically, up to the value of the
MEMORY_MAX_TARGET parameter, just as you can do for the database instance.
Although it is not recommended, you can disable automatic memory management by either setting the value for
0 in the ASM parameter file or by running an
=0 statement. When you disable automatic memory management, Oracle reverts to auto shared memory management and automatic PGA memory management. If you want to revert to Oracle Database 10g release 2 (10.2) functionality to manually manage ASM SGA memory, also run the
SGA_TARGET=0 statement. You can then manually manage ASM memory using the information in "ASM Parameter Setting Recommendations", that discusses ASM memory-based parameter settings. Unless specified, the behaviors of all of the automatic memory management parameters in ASM instances is the same as in Oracle Database instances.
Note:For a Linux environment, automatic memory management cannot work if
/dev/shmis not available or is undersized. For more information, see Oracle Database Administrator's Reference for Linux and UNIX. For information about platforms that support automatic memory management, see Oracle Database Administrator's Guide.
MEMORY_TARGETfor ASM is 256 MB. If you set
MEMORY_TARGETto 100 MB, then Oracle increases the value for
MEMORY_TARGETto 256 MB automatically.
This section contains information about the following parameters for ASM:
ASM_DISKGROUPS initialization parameter specifies a list of the names of disk groups that an ASM instance mounts at startup. Oracle ignores the value that you set for
ASM_DISKGROUPS when you specify the
NOMOUNT option at startup or when you issue the
MOUNT statement. The default value of the
ASM_DISKGROUPS parameter is a
NULL string. If the parameter value is
NULL or is not specified, then ASM does not mount any disk groups.
ASM_DISKGROUPS parameter is dynamic. If you are using a server parameter file (SPFILE), then you should not need to manually alter the value of
ASM_DISKGROUPS. ASM automatically adds a disk group to this parameter when the disk group is successfully created or mounted. ASM also automatically removes a disk group from this parameter when the disk group is dropped or dismounted. The following is an example of setting the
ASM_DISKGROUPS parameter dynamically:
SQL> ALTER SYSTEM SET ASM_DISKGROUPS = 'CONTROLFILE, DATAFILE, LOGFILE, STANDBY'
When using a text initialization parameter file (PFILE), you must edit the initialization parameter file to add the name of any disk group that you want mounted automatically at instance startup. You must remove the name of any disk group that you no longer want automatically mounted. The following is an example of the
ASM_DISKGROUPS parameter in the initialization file:
ALL DISMOUNTcommands does not affect the value of
ASM_DISKSTRING initialization parameter specifies a comma-delimited list of strings that limits the set of disks that an ASM instance discovers. The discovery strings can include wildcard characters. Only disks that match one of the strings are discovered. The same disk cannot be discovered twice.
The discovery string format depends on the ASM library and the operating system that are in use. Pattern matching is supported; refer to your operating system-specific installation guide for information about the default pattern matching. For example, on a Linux server that does not use ASMLIB, to limit the discovery process to only include disks that are in the
/dev/rdsk/ directory, set
The asterisk is required. To limit the discovery process to only include disks that have a name that ends in
? character, when used as the first character of a path, expands to the Oracle home directory. Depending on the operating system, when you use the
? character elsewhere in the path, it is a wildcard for one character.
The default value of the
ASM_DISKSTRING parameter is a
NULL string. A
NULL value causes ASM to search a default path for all disks in the system to which the ASM instance has read and write access. The default search path is platform-specific. Refer to your operating system specific installation guide for more information about the default search path.
ASM cannot use a disk unless all of the ASM instances in the cluster can discover the disk through one of their own discovery strings. The names do not need to be the same on every node, but all disks must be discoverable by all of the nodes in the cluster. This may require dynamically changing the initialization parameter to enable adding new storage.
See Also:Oracle Database Reference for more information about the
ASM_POWER_LIMIT initialization parameter specifies the default power for disk rebalancing. The default value is
1 and the range of allowable values is
11 inclusive. A value of
0 disables rebalancing. Higher numeric values enable the rebalancing operation to complete more quickly, but might result in higher I/O overhead.
ASM_PREFERRED_READ_FAILURE_GROUPS initialization parameter value is a comma-delimited list of strings that specifies the failure groups that should be preferentially read by the given instance. This parameter is generally used only for clustered ASM instances and its value can be different on different nodes. For example:
ASM_PREFERRED_READ_FAILURE_GROUPS parameter setting is instance specific. This parameter is only valid for clustered ASM instances and the default value is
ASM_PREFERRED_READ_FAILURE_GROUPSparameter is valid only in Oracle RAC environments.
"Preferred Read Failure Groups" for more information about
Oracle Real Application Clusters Administration and Deployment Guide for more information about configuring preferred disks in extended clusters
Oracle Database Reference for more information about the
ASM_PREFERRED_READ_FAILURE_DISKGROUPS initialization parameter
The setting for the
DB_CACHE_SIZE parameter determines the size of the buffer cache. This buffer cache is used to store metadata blocks. The default value for this parameter is suitable for most environments.
For an ASM instance,
db_name defaults to
INSTANCE_TYPE initialization parameter must be set to
ASM for an ASM instance. This is a required parameter and cannot be modified. The following is an example of the
INSTANCE_TYPE parameter in the initialization file:
See Also:Oracle Database Reference for more information about the
The setting for the
LARGE_POOL_SIZE parameter is used for large allocations. The default value for this parameter is suitable for most environments.
PROCESSES initialization parameter affects ASM, but generally you do not need to modify the setting. The default value provided is usually suitable.
The setting for the
SHARED_POOL_SIZE parameter determines the amount of memory required to manage the instance. The setting for this parameter is also used to determine the amount of space that is allocated for extent storage. The default value for this parameter is suitable for most environments.
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
For information about the
COMPATIBLE.ASM attribute, see "COMPATIBLE.ASM".
For information about the
COMPATIBLE.RDBMS attribute, see "COMPATIBLE.RDBMS".
For information about the
DISK_REPAIR_TIME attribute, see "ASM Fast Mirror Resync".
The following section describes how to administer ASM instances under the following topics:
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
See Also:The Oracle Real Application Clusters Administration and Deployment Guide for detailed information about administering ASM instances with
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
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
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
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
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.
SHUTDOWN ABORT to the ASM instance before restarting it.
Mounts the disk groups specified in the
ASM_DISKGROUPS initialization parameter. This is the default if no command parameter is specified.
Starts up the ASM instance without mounting any disk groups.
Starts up an instance in restricted mode that enables access only to users with both the
SESSION system privileges. The
RESTRICT clause can be used in combination with the
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.
Total System Global Area 71303168 bytes
Fixed Size 1069292 bytes
Variable Size 45068052 bytes
ASM Cache 25165824 bytes
ASM disk groups mounted
See Also:"Authentication for Accessing ASM Instances" for more information about user authentication
Oracle Database Administrator's Guide for more information about using environment variables to select instances
Oracle Database Administrator's Guide for more information about starting up and shutting down Oracle instances
Oracle Real Application Clusters Administration and Deployment Guide for information about starting an ASM instance with
SRVCTL in Oracle RAC
You can use the
RESTRICT command to control access to an ASM instance while you perform maintenance. When an ASM instance is active in this mode, all of the disk groups that are defined in the
ASM_DISKGROUPS parameter are mounted in
RESTRICTED mode. This prevents databases from connecting to the ASM instance. In addition, the restricted clause of the
SYSTEM statement is disabled for the ASM instance. The
MOUNT statement is extended to enable ASM to mount a disk group in restricted mode.
When you mount a disk group in
RESTRICTED mode, the disk group can only be mounted by one instance. Clients of ASM on that node cannot access that disk group while the disk group is mounted in
RESTRICTED mode. The
RESTRICTED mode enables you to perform maintenance tasks on a disk group in the ASM instance without interference from clients.
Rebalance operations that occur while a disk group is in
RESTRICTED mode eliminate the lock and unlock extent map messaging that occurs between ASM instances in an Oracle RAC environment. This improves the overall rebalance throughput. At the end of a maintenance period, you must explicitly dismount the disk group and remount it in normal mode.
The Cluster Synchronization Services (CSS) daemon provides cluster services for ASM, communication between the ASM and database instances, and other essential services. When DBCA creates a database, the CSS daemon is usually started and configured to start upon restart. If DBCA created the database, then you must ensure that the CSS daemon is running before you start the ASM instance.
To determine if the CSS daemon is running, run the command
cssd. If Oracle displays the message
healthy, then the CSS daemon is running. Otherwise, to start the CSS daemon and configure the host to always start the daemon upon restart, do the following:
Log in to the host as the
Ensure that the entry
$ORACLE_HOME/bin is in your
PATH environment variable.
Run the following command:
You can also use the
localconfig commands to check the status of the CSS daemon or to start it. To use Windows GUI tools to determine whether the CSS daemon is properly configured and running, double-click the Services icon in the Windows Control Panel and locate the OracleCSService service. The service's status should be
Started and its startup type should be
Note:Refer to your Windows documentation for information about how to start a Windows service and how to configure it for automatic startup.
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.
SQL> CONNECT SYS
SQL> SHUTDOWN NORMAL
See Also:"Authentication for Accessing ASM Instances" for more information about use authentication
The following list describes the
SHUTDOWN modes and describes the behavior of the ASM instance in each mode.
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.
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
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.
See Also:"Authentication for Accessing ASM Instances" for more information about user authentication on ASM instance
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.
ASM rolling upgrades enable you to independently upgrade or patch clustered ASM nodes without affecting database availability, thus providing greater uptime. Rolling upgrade means that all of the features of a clustered ASM environment function when one or more of the nodes in the cluster uses different software versions.
Note:Rolling upgrades only apply to clustered ASM instances, and you can only perform rolling upgrades on environments with Oracle Database 11g or later. In other words, you cannot use this feature to upgrade from Oracle Database 10g to Oracle Database 11g.
To perform a rolling upgrade, your environment must be prepared. If you are using Oracle Clusterware, then your Oracle Clusterware must be fully upgraded to the next patch or release version before you start the ASM rolling upgrade. In addition, you should prepare your Oracle Clusterware in a rolling upgrade manner to ensure high availability and maximum uptime.
Before you patch or upgrade the ASM software on a node, you must place the ASM cluster into rolling upgrade mode. This enables you to begin an upgrade and operate your environment in multiversion software mode. Do this by issuing the following SQL statement where
number includes the version number, release number, update number, port release number, and port update number. Enter these values for
number in a decimal-separated string enclosed in single quotation marks, for example,
'184.108.40.206.0', to perform the upgrade as in the following example
ALTER SYSTEM START ROLLING MIGRATION TO '220.127.116.11.0';
The instance from which you run this statement verifies whether the value that you specified for number is compatible with the current installed version of your software. When the upgrade begins, the behavior of the clustered ASM environment changes, and only the following operations are permitted on the ASM instance:
Disk group mount and dismount
Database file open, close, resize, and delete
Limited access to fixed views and fixed packages
Note:You can query fixed views and run anonymous PL/SQL blocks using fixed packages, such as
DBMS_DISKGROUP. However, only local views are available; Oracle disables all global views when a clustered ASM environment is in rolling upgrade mode.
After the rolling upgrade has been started, you can shut down each ASM instance and perform the software upgrade. On start up, the updated ASM instance can rejoin the cluster. When you have migrated all of the nodes in your clustered ASM environment to the latest software version, you can end the rolling upgrade mode.
If a disk goes offline when the ASM instance is in rolling upgrade mode, then the disk remains offline until the rolling upgrade has ended. Also, the timer for dropping the disk is stopped until the ASM cluster is out of rolling upgrade mode.
See Also:"ASM Fast Mirror Resync" for more information about using fast mirror resync during a rolling upgrade
You can also use the same procedure to roll back node upgrades if you encounter problems with the upgrade. The ASM functionality is compatible with the lowest software version that is on any of the nodes in the cluster during an upgrade.
The upgrade fails if there are rebalancing operations occurring anywhere in the cluster. You must wait until the rebalance completes before attempting to start a rolling upgrade. In addition, as long as there is one instance active in the cluster, the rolling upgrade state is preserved.
New instances that join the cluster immediately switch to a rolling upgrade state on startup. In other words, if a rolling upgrade is in progress in a clustered ASM environment and if any new ASM instance joins the cluster, then the new ASM instance is notified that the cluster is in rolling upgrade mode. You can use the following SQL function to query the state of a clustered ASM environment:
SELECT SYS_CONTEXT('sys_cluster_properties', 'cluster_state') FROM DUAL;
If all of the instances in a clustered ASM environment stop running, then when any of the ASM instances restart, the restarted instance will not be in rolling upgrade mode. To perform the upgrade after your instances restart, you must re-run the commands to restart the rolling upgrade operation. When the rolling upgrade completes, run the following SQL statement:
ALTER SYSTEM STOP ROLLING MIGRATION;
After you run this statement, Oracle performs the following operations:
Validates that all of the members of the cluster are at the same software version. If there are one or more ASM instances that have different versions, then Oracle displays an error and the cluster continues to be in rolling upgrade mode.
Updates the cluster-wide state so that the ASM instances are no longer in rolling upgrade mode; the ASM instances begin supporting the full clustered ASM functionality.
Rebalance operations that were pending are restarted if the setting for the
ASM_POWER_LIMIT parameter enables this.
See Also:"ASM_POWER_LIMIT" for more information about using the
For Oracle RAC environments, if you configure ASM in a home that is separate from the Oracle Database home, then when you apply patches you must apply them in a specific order. You must first ensure that your Oracle Clusterware version is at least equal to the version of the patch that you are applying. This may require you to patch the Oracle Clusterware home first. Then apply the patch to the ASM home, and finally, apply the patch to the Oracle Database home.
Note:You must apply the patch to the ASM home before you apply it to the Oracle Database home.
The ASM and database instances must have equivalent operating system access rights. For example, the ASM instance and the database instance must have identical read and write permissions for the disks that comprise the related ASM disk group. For UNIX systems, this is typically provided through shared UNIX group membership. On Windows systems, the ASM service can run as Administrator.
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,
SYSOPER. There are three modes of connecting to ASM instances:
Local connection using operating system authentication
Local connection using password authentication
Note:If you create an ASM instance using Database Configuration Assistant (DBCA), or if you create the ASM instance using Database Upgrade Assistant (DBUA), then the user
SYSshould have SYSASM privileges.
See Also:Your operating system-specific Oracle Database installation guide for information about how to ensure that the ASM and database instances have member disk access
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:
|Group||Privilege Granted to Members|
SYSASM privilege, which provides full administrative privilege for the ASM instance.
OSDBA for ASM
SYSDBA privilege on the ASM instance. This privilege grants access to data stored on ASM, and in the current release, grants the SYSASM administrative privileges.
OSOPER for ASM
SYSOPER privilege on the ASM instance.
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.
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.
SYSuser is created by default by DBCA during installation process with all three system privileges.
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
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.
When you are logged in to an ASM instance as SYSASM, you can use the combination of
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
USER command. The following example describes how to perform these operations for the user identified as
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;
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.
Note:The user who is the software owner for the Oracle Database home, that Oracle documentation describes as the oracle user must be a member of the group that is designated as the OSDBA group for the ASM home. This is automatically configured when ASM and an Oracle Database share the same Oracle home. If you install the ASM and database instances in separate homes, then you must ensure that you create a separate OSDBA group for ASM, and that you designate the correct group memberships for each OSDBA group. Otherwise, the database instance will not be able to connect to the ASM instance.
See Also:Oracle Database Administrator's Guide for more information about using operating system authentication
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.
Oracle Database Administrator's Guide for information about creating and maintaining a password file
Oracle Database Security Guide for information about database security
Oracle Database Reference for information about the
V$PWFILE_USERS view which lists users who have been granted
SYSOPER privileges as derived from the password file.
With a new installation of Oracle Database and ASM, you can initially create your database and select the ASM storage option. If you have an existing Oracle database that stores database files in the operating system file system or on raw devices, then you can migrate some or all of your datafiles to ASM storage.
Oracle provides several methods for migrating your database to ASM. Using ASM will enable you to realize the benefits of automation and simplicity in managing your database storage. You can use the following methods to migrate to ASM as described in this section:
Note:You must upgrade to at least Oracle Database 10g before migrating your database 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.
See Also:Chapter 6, "Administering ASM with Oracle Enterprise Manager" for more information about using Enterprise Manager to upgrade to ASM
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.
See Also:Oracle Database Backup and Recovery User's Guide. for detailed instructions about migrating ASM data using RMAN
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
See Also:For information about Oracle ASM best practices for migrating to Oracle ASM from environments that do not use Oracle ASM, refer to the documentation at the MAA link on Oracle Technology Network: