3 Administering Oracle ASM Instances

Initialization Parameter Files for an Oracle ASM Instance

When installing Oracle ASM in an Oracle Restart configuration, Oracle Universal Installer (OUI) creates a separate server parameter file (SPFILE) and password file for the Oracle ASM instance. When installing Oracle ASM in a clustered Oracle ASM environment where the Oracle grid infrastructure home is shared among all of the nodes, OUI creates a single SPFILE for Oracle ASM in a disk group. In a clustered environment without a shared Oracle grid infrastructure home, OUI creates a SPFILE for Oracle ASM on each node.

You can use an SPFILE or a text-based initialization parameter file (PFILE) as the Oracle ASM instance parameter file. If you use an SPFILE in a clustered Oracle ASM environment, then you must place the SPFILE in a disk group, a shared raw device, or on a cluster file system. Oracle recommends that the Oracle ASM SPFILE is placed in a disk group. You cannot use a new alias created on an existing Oracle ASM SPFILE to start up the Oracle ASM instance

If you do not use a shared Oracle grid infrastructure home, then the Oracle ASM instance can use a PFILE. The same rules for file name, default location, and search order that apply to database initialization parameter files also apply to Oracle ASM initialization parameter files.

When an Oracle ASM instance searches for an initialization parameter file, the search order is:

1. The location of the initialization parameter file specified in the Grid Plug and Play (GPnP) profile

2. If the location has not been set in the GPnP profile, the search order changes to:

   1. SPFILE in the Oracle ASM instance home

      For example, the SPFILE for Oracle ASM has the following default path in the Oracle grid infrastructure home in a Linux environment:

      $ORACLE_HOME/dbs/spfile+ASM.ora

   2. PFILE in the Oracle ASM instance home

You can administer an Oracle ASM initialization parameter files with SQL*Plus, Oracle Enterprise Manager, ASMCA, and ASMCMD commands. For information about Oracle Enterprise Manager, see "Configuring Oracle ASM Initialization Parameters with Oracle Enterprise Manager". For information about ASMCA, see Chapter 11, "Oracle ASM Configuration Assistant". For information about ASMCMD commands, see "ASMCMD Instance Management Commands".

Backing Up, Copying, and Moving an Oracle ASM Initialization Parameter File

You can back up, copy, or move an Oracle ASM SPFILE with the ASMCMD spbackup, spcopy or spmove commands. For information about these ASMCMD commands, see "spbackup", "spcopy", and "spmove".

You can also use the SQL CREATE SPFILE to create an Oracle ASM SPFILE when connected to the Oracle ASM instance.

You can copy and move an Oracle ASM PFILE with the commands available on the specific platform, such as cp for Linux.

After copying or moving a SPFILE or PFILE, you must restart the instance with the SPFILE or PFILE in the new location if you want to use that SPFILE or PFILE.

If the COMPATIBLE.ASM disk group attribute is set to 11.2 or greater for a disk group, you can create, copy, or move an Oracle ASM SPFILE into the disk group.

For example, after upgrading an Oracle ASM instance from 11g release 1 (11.1) to 11g release 2 (11.2), you could place the Oracle ASM SPFILE in a disk group that has COMPATIBLE.ASM set to 11.2.

In the following steps, assume an Oracle ASM 11g release 2 (11.2) instance is using a PFILE stored in $ORACLE_HOME/dbs/asmspfile.ora. You can use the SQL CREATE SPFILE statement to create a SPFILE from a PFILE stored in a local or shared file system. If a PFILE does not exist, then it could be created with the SQL CREATE PFILE statement.

To create a SPFILE in a disk group, perform the following steps:

1. Connect to the Oracle ASM instance.

   For example:

   $ sqlplus / as sysasm
   

2. Create a SPFILE in a disk group that has COMPATIBLE.ASM set to 11.2 with the SQL CREATE SPFILE statement.

   For example, create an Oracle ASM SPFILE from the existing PFILE.

   SQL> CREATE SPFILE = '+DATA/asmspfile.ora' 
          FROM PFILE = '$ORACLE_HOME/dbs/asmspfile.ora';
   

   The CREATE SPFILE statement also updates the Grid Plug and Play (GPnP) profile. You can check the location of the Oracle ASM SPFILE in the GPnP profile with the ASMCMD spget command. See "spget".

3. Restart the Oracle ASM instance so that the instance will use the SPFILE in the new location.

   For information on shutting down and starting up an Oracle ASM instance, see "Starting Up an Oracle ASM Instance" and "Shutting Down an Oracle ASM Instance".

For information about disk group compatibility attributes, see "Disk Group Compatibility". For information about upgrading an Oracle ASM instance, see "Upgrading an Oracle ASM Instance With Oracle Universal Installer".

Setting Oracle ASM Initialization Parameters

There are several initialization parameters that you must set for an Oracle ASM instance. You can set these parameters with Oracle ASM Configuration Assistant (ASMCA). 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 Oracle ASM instance parameter file. The Oracle ASM* parameters use suitable defaults for most environments. You cannot use parameters with names that are prefixed with Oracle ASM* in database instance parameter files.

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

For information about setting Oracle ASM parameters with Oracle Enterprise Manager, see "Configuring Oracle ASM Initialization Parameters with Oracle Enterprise Manager".

Oracle ASM Parameter Setting Recommendations

This section contains information about the following parameters for Oracle 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 = DATA, FRA;

Setting Database Initialization Parameters for Use with Oracle 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 Oracle 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 Oracle ASM or will be stored in Oracle 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

Administering Oracle ASM Instances with Server Control Utility

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

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

• Enable, disable, start, and stop Oracle ASM instance

• Display the Oracle ASM instance configuration and status

Using Oracle Restart

Oracle Restart improves the availability of your Oracle database. When you install the Oracle grid infrastructure for a standalone server, it includes both Oracle ASM and Oracle Restart. Oracle Restart runs out of the Oracle grid infrastructure home, which you install separately from Oracle Database homes.

Oracle Restart provides managed startup and restart of a single-instance (non-clustered) Oracle Database, Oracle ASM instance, service, listener, and any other process running on the server. If an interruption of a service occurs after a hardware or software failure, Oracle Restart automatically takes the necessary steps to restart the component.

With Server Control Utility (SRVCTL) you can add a component, such as an Oracle ASM instance, to Oracle Restart. You then enable Oracle Restart protection for the Oracle ASM instance. With SRVCTL, you also remove or disable Oracle Restart protection.

Starting Up an Oracle ASM Instance

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

• To connect to a local Oracle ASM instance with SQL*Plus, set the ORACLE_SID environment variable to the Oracle ASM SID.

  The default Oracle ASM SID for a single-instance database is +ASM, and the default SID for Oracle ASM for an Oracle RAC node is +ASMnode_number where node_number is the number of the node. The ORACLE_HOME environment variable must be set the Grid Infrastructure home where Oracle ASM was installed.

• The initialization parameter file must contain the following entry:

  INSTANCE_TYPE = ASM

  This parameter indicates that an Oracle 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 Oracle ASM disk groups.

  For information about disk groups that are mounted at startup time, see "About Mounting Disk Groups at Startup".

  After the Oracle ASM instance has started, you can mount disk groups with the ALTER DISKGROUP...MOUNT command. See "Mounting and Dismounting Disk Groups" for more information.

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

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

• FORCE Parameter

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

  If an Oracle Automatic Storage Management Cluster File System (Oracle ACFS) file system is currently mounted on Oracle ADVM volumes, the file system should first be dismounted. Otherwise, applications will encounter I/O errors and Oracle ACFS user data and metadata may not be flushed to storage before the Oracle ASM storage is fenced. For information about dismounting an Oracle ACFS file system, see "Deregistering, Dismounting, and Disabling Volumes and Oracle ACFS File Systems".

• 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 Oracle 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 Oracle 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 Oracle ASM instance.

For more information about user authentication, see "Authentication for Accessing Oracle ASM Instances".

Shutting Down an Oracle ASM Instance

The Oracle 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 Oracle ASM SID so that you can connect to the local Oracle ASM instance. The default Oracle ASM SID for a single-instance database is +ASM, and the default SID for Oracle ASM for an Oracle RAC node is +ASMnode_number where node_number is the number of the node. The ORACLE_HOME environment variable must be set the Grid Infrastructure home where Oracle ASM was installed.

Oracle strongly recommends that you shut down all database instances that use the Oracle ASM instance and dismount all file systems mounted on Oracle ASM Dynamic Volume Manager (Oracle ADVM) volumes before attempting to shut down the Oracle ASM instance.

For more information about user authentication, see "Authentication for Accessing Oracle ASM Instances".

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

• NORMAL Clause

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

• IMMEDIATE or TRANSACTIONAL Clause

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

• ABORT Clause

  The Oracle ASM instance immediately shuts down without the orderly dismount of disk groups. This causes recovery to occur upon the next Oracle ASM startup.

  If any database instance is connected to the Oracle ASM instance, then the database instance aborts.

  If any Oracle Automatic Storage Management Cluster File System (Oracle ACFS) file systems are currently mounted on Oracle ADVM volumes, those file systems should first be dismounted. Otherwise, applications will encounter I/O errors and Oracle ACFS user data and metadata may not be flushed to storage before the Oracle ASM storage is fenced. For information about dismounting an Oracle ACFS file system, see "Deregistering, Dismounting, and Disabling Volumes and Oracle ACFS File Systems". For more information about user authentication on Oracle ASM instance, see "Authentication for Accessing Oracle ASM Instances".

Upgrading an Oracle ASM Instance With Oracle Universal Installer

This section discusses the process to upgrade an Oracle ASM instance to an Oracle Restart 11g release 2 (11.2) configuration. The recommended practice is to upgrade an Oracle ASM instance with Oracle grid infrastructure Oracle Universal Installer (OUI). OUI automatically defaults to upgrade mode when it detects an Oracle ASM instance at a previous release level. Before you make any changes to the Oracle software, Oracle recommends that you create a backup of the Oracle software.

The following procedure describes how to upgrade an Oracle ASM instance from 11g release 1 (11.1) to 11g release 2 (11.2) in an Oracle Restart configuration. In this scenario:

• The Oracle ASM and Oracle Database instances 11g release 1 (11.1) exist in separate homes.

• The Oracle grid infrastructure 11g release 2 (11.2) is to be installed in a separate home and the Oracle ASM instance 11g release 2 (11.2) is to be set up as an Oracle Restart (single-instance) configuration.

1. Shut down the Oracle Enterprise Manager agent, Oracle Database instances, Oracle ASM instance, and the listener the in the older database and Oracle ASM homes.

   • Run emctl stop dbconsole to stop the Oracle Enterprise Manager agent.

   • Connect to the database instances with SQL*Plus as a privileged user and issue the SHUTDOWN command.

   • Connect to the Oracle ASM instance with SQL*Plus as a privileged user and issue the SHUTDOWN command.

   • Run lsnrctl and enter the STOP command to stop the listener.

   For information about shutting down an Oracle ASM instance, see "Shutting Down an Oracle ASM Instance".

   See Also:

   • Oracle Enterprise Manager manuals and online help for information about starting and stopping the Oracle Enterprise Manager agent

   • Oracle Database Administrator's Guide for more information about starting up and shutting down Oracle instances

   • Oracle Database Net Services Administrator's Guide for information about configuring a listener

2. Start the Oracle grid infrastructure OUI and select the Upgrade Oracle grid infrastructure option.

3. Complete the screens in the OUI installer and run the scripts as prompted by the OUI installer.

   For example, on Linux you must run the root.sh script as the root user.

   # GRID_HOME/root.sh
   

   See Also:

   Oracle Grid Infrastructure Installation Guide for information about installing and upgrading Oracle grid infrastructure

4. Confirm that the listener and Oracle ASM instance are running in the Oracle grid infrastructure home and ensure that the Oracle Database instance and Oracle Enterprise Manager agent are running in the old database home.

   • Confirm that the listener is running.

     Otherwise start the listener with Server Control Utility (SRVCTL).

     For example:

     $ svrctl start listener
     

   • Confirm that the Oracle ASM instance is running.

     For example:

     $ srvctl status listener
     $ srvctl status asm
     

     Otherwise start the Oracle ASM instance with SRVCTL.

     For example:

     $ svrctl start asm
     

   • Ensure that the database instances are running; otherwise connect to the database instances with SQL*Plus as a privileged user and issue the STARTUP command.

   • Ensure that the Oracle Enterprise Manager agent is running; otherwise start the Oracle Enterprise Manager agent with emctl start dbconsole.

For information about copying and moving an Oracle ASM instance initialization parameter file after upgrading, see "Backing Up, Copying, and Moving an Oracle ASM Initialization Parameter File".

Downgrading an Oracle ASM Instance

This section discusses the process to downgrade an Oracle ASM instance that has been upgraded to an Oracle Restart configuration.

Before you make any changes to the Oracle software, Oracle recommends that you create a backup of the Oracle software.

The following procedure describes how to downgrade an Oracle ASM instance from 11g release 2 (11.2) to 11g release 1 (11.1). In this scenario, the Oracle ASM instance was previously upgraded from an 11g release 1 (11.1) home to an Oracle Restart (single-instance) 11g release 2 (11.2) configuration. The 11g release 1 (11.1) home was not removed.

1. Determine disk group compatibility attribute settings.

   If compatibility attributes have been advanced, then the disk groups must be recreated using compatibility attributes that allow access by the downgraded Oracle ASM and Oracle Database instances. A new disk group must be created with the old compatibility attributes and then you must restore the database files that were in the disk group.

   When you revert to a new disk group with the old compatibility attribute settings, the latest Oracle ASM features might not be available. For example, if you revert the disk group compatibility to a pre-11.2 value, Oracle ACFS functionality is not available.

   Copy or move an Oracle ASM SPFILE in a disk group to the file system before reverting disk group compatibility. Check the initialization parameters to ensure they are compatible with Oracle ASM 11g release 1 (11.1).

   For information about reverting disk group compatibility, see "Reverting Disk Group Compatibility". For information about moving data files between disk groups, see "Moving Data Files Between Oracle ASM Disk Groups Using RMAN".

2. Downgrade any client databases from 11g release 2 (11.2) down to 11g release 1 (11.1).

   See Also:

   Oracle Database Upgrade Guide for information about downgrading an Oracle Database and Oracle Enterprise Manager

3. Shut down the Oracle Enterprise Manager agent, Oracle Database instance, Oracle ASM instance, and the listener the in the database and Oracle ASM homes.

   • Run emctl stop dbconsole to stop the Oracle Enterprise Manager agent.

   • Connect to the database instances with SQL*Plus as a privileged user and issue the SHUTDOWN command.

   • Shut down the Oracle ASM instance with Server Control Utility (SRVCTL).

     $ svrctl stop asm
     

   • Stop the listener with SVRCTL.

     $ svrctl stop listener
     

   For information about shutting down an Oracle ASM instance, see "Shutting Down an Oracle ASM Instance".

   See Also:

   • Oracle Enterprise Manager manuals and online help for information about starting and stopping the Oracle Enterprise Manager agent

   • Oracle Database Administrator's Guide for more information about starting up and shutting down Oracle instances

   • Oracle Database Net Services Administrator's Guide for information about configuring a listener

   • Oracle Real Application Clusters Administration and Deployment Guide for information about Server Control Utility (SRVCTL)

4. Deconfigure the Oracle Restart 11g release 2 (11.2) configuration.

   Run the roothas.pl script as root.

   For example, on Linux:

   # GRID_HOME/crs/install/roothas.pl -delete
   

   The 11g release 2 (11.2) inittab and init* scripts should be removed with the deconfiguration of Oracle Clusterware.

5. Unload the Oracle ACFS drivers.

   For example, on Linux run acfsload stop as root.

   # GRID_HOME/bin/acfsload stop
   

   For information about Oracle ACFS driver resource management, see "Oracle ACFS Drivers Resource Management".

6. Recreate the Oracle ASM 11g release 1 (11.1) resources.

   Run localconfig as root to add the resources to the Oracle ASM 11g release 1 (11.1) home.

   For example, on Linux:

   # ORACLE_ASM_11.1_HOME/bin/localconfig add
   

   If localconfig add fails, use the reset option followed by the ORACLE_HOME to reset the existing resources.

   For example, on Linux:

   # localconfig reset ORACLE_ASM_11.1_HOME
   

7. Confirm that the Oracle ASM PFILE and listerner.ora files are present in the Oracle ASM 11g release 1 (11.1) home.

   If the Oracle ASM 11g release 1 (11.1) home has not been removed, the files should be available.

8. Configure additional configuration files in the Oracle ASM 11g release 1 (11.1) home.

   For example, update files in the /etc directory on the Linux machine.

   Update the Oracle ASM entry in /etc/oratab to point to the Oracle ASM 11g release 1 (11.1) home.

   +ASM:/ORACLE_ASM_11.1_HOME/product/11.1.0/asm_1:N

   The 11g release 2 (11.2) inittab and init* scripts should be removed with the deconfiguration of Oracle Clusterware.

9. Ensure that the listener, Oracle ASM instance, Oracle Database instance, and Oracle Enterprise Manager agent are running in the 11g release 1 (11.1) Oracle ASM and database homes.

   • Start the listener with lsnrctl and enter the START option.

     If necessary, start Network Configuration Assistant (NETCA) in the Oracle ASM 11g release 1 (11.1) home with netca. Follow the prompts in the wizard to reconfigure the listener.

   • Connect to the Oracle ASM instance with SQL*Plus as a privileged user and issue the STARTUP command.

   • Connect to the database instances with SQL*Plus as a privileged user and issue the STARTUP command.

   • Start the Oracle Enterprise Manager agent with emctl start dbconsole.

     Oracle Enterprise Manager may need to be reconfigured after the Oracle ASM instance has been downgraded.

Active Session History Sampling for Oracle ASM

Active Session History sampling is now available on Oracle ASM instances. This activity is exposed in the dynamic V$ACTIVE_SESSION_HISTORY view. Active Session History sampling requires a diagnostic pack license for the Oracle ASM instance.

About Privileges for Oracle ASM

During Oracle ASM installation, you can use one operating system group for all users or divide system privileges so that database administrators, storage administrators, and database operators each have distinct operating system privilege groups.

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 administer an Oracle ASM instance. The SYSDBA privilege cannot be used to administer an Oracle ASM instance. If you use the SYSDBA privilege to run administrative commands on an Oracle ASM instance, the operation is results in an error. The SYSDBA privilege is intended to be used by the database to access disk groups.

Oracle also recommends that the use of a less privileged user, such as ASMSNMP with SYSDBA privileges that is created during installation, for monitoring the Oracle ASM instance.

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 Oracle ASM instance as SYSASM grants you full access to all of the available Oracle ASM disk groups and management functions.

This section contains these topics:

• Using One Operating System Group for Oracle ASM Users

• Using Separate Operating System Groups for Oracle ASM Users

• The SYSASM Privilege for Administering Oracle ASM

• The SYSDBA Privilege for Managing Oracle ASM Components

For information about privileges and Oracle ACFS, see "Oracle ACFS and File Access and Administration Security".

sqlplus SYS AS SYSASM
...
Enter password:

sqlplus sys@\"myhost.mydomain.com:1521/+ASM\" AS SYSASM
...
Enter password:

sqlplus / AS SYSASM

Creating Users with the SYSASM Privilege

When you are logged in to an Oracle 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. You also 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 SQL 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;

For information about creating a user with Oracle ASM command-line utility (ASMCMD), see "orapwusr". For information about creating a user with Oracle Enterprise Manager, see "Managing Oracle ASM Users with Oracle Enterprise Manager".

Operating System Authentication for Oracle 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 Oracle 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 Oracle ASM, including administrative access to all disk groups that are managed by that Oracle ASM instance.

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

SQL*Plus commands, ASMCMD commands, and ASMCA use operating system authentication.

Password File Authentication for Oracle ASM

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

If you select the Oracle ASM storage option, then ASMCA creates a password file for Oracle ASM when it initially configures the Oracle ASM disk groups. Similar to a database password file, the only user added to the password file when ASMCA 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 Privileges for Oracle ASM".

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

SQL*Plus commands and Oracle Enterprise Manager use password file authentication.

Using Oracle Enterprise Manager to Migrate Databases to Oracle ASM

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

For more information about using Oracle Enterprise Manager to upgrade to Oracle ASM, see Chapter 9, "Administering Oracle ASM with Oracle Enterprise Manager".

Using Oracle Recovery Manager to Migrate Databases to Oracle ASM

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

For more information, see Chapter 8, "Performing Oracle ASM Data Migration With RMAN".

Best Practices White Papers on Migrating to Oracle ASM

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 Oracle ASM

• Platform Migration using Transportable Tablespaces

• Platform Migration using Transportable Database