If you do not want to divide the privileges for system 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, and OSASM for Oracle ASM privileges. The default operating system group name for all of these is usually dba and that group is typically chosen for the default configuration.

Table 3-1 shows an example of a Linux deployment without separated privileges for Oracle ASM users.

You can designate separate operating system groups as the operating system authentication groups for privileges on Oracle ASM. The following list describes the separate operating system authentication groups for Oracle ASM and the privileges that their members are granted.

• OSASM group (for example: asmadmin)

  This group is granted the SYSASM privilege, which provides full administrative privileges for the Oracle ASM instance.

• OSDBA for Oracle ASM group (for example: asmdba)

  This group is granted the SYSDBA privilege on the Oracle ASM instance, which grants access to data stored on Oracle ASM. This group has a subset of the privileges of the OSASM group.

  When you implement separate administrator privileges, choose an OSDBA group for the Oracle ASM instance that is different than the group that you select for the database instance (dba).

• OSOPER for Oracle ASM group (for example: asmoper)

  This group is granted the SYSOPER privilege on the Oracle ASM instance, which provides operations such as startup, shutdown, mount, dismount, and check disk group. This group has a subset of the privileges of the OSASM group.

When you implement separate Oracle ASM and database administrator duties, this configuration requires different group and different software owners. Implicitly this implementation requires that the OSASM and OSDBA are different groups. For this configuration, you must create an OSDBA for Oracle ASM group and a database instance must be a member of that group to access the Oracle ASM instance.

In an installation that has been configured as Oracle Grid Infrastructure, the Oracle ASM user, such as grid, does not have to be a member of the Oracle Database OSDBA group, such as dba1 or dba2, because the Oracle Clusterware database agent runs as the database owner and can use SYSDBA to connect to the database.

However, in an Oracle Restart configuration, the Oracle ASM user (grid) must be a member of the OSDBA group (dba1, dba2, ...) of every database. This requirement is necessary because Oracle Restart software runs as the Oracle ASM user (grid) and this user must be able to start and stop the databases using the CONNECT / AS SYSDBA authentication.

Additionally, the owner of the operating system disk devices should be the same as the owner of the Oracle ASM software.

Table 3-2 shows an example of a Linux deployment using separate operating system privilege groups for Oracle ASM users.

SYSASM is a system privilege that enables the separation of the SYSDBA database administration privilege from the Oracle 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 also grant the SYSASM privilege with password file authentication, as discussed in Password File Authentication for Oracle ASM.

To connect locally as SYSASM using password authentication with SQL*Plus, use the following statement:

sqlplus SYS AS SYSASM
...
Enter password:

To connect remotely as SYSASM using password authentication with SQL*Plus, use the following statement:

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

In the previous example, +ASM is the service name of the Oracle ASM instance.

To connect locally as SYSASM to an Oracle ASM instance using operating system authentication with SQL*Plus, use the following statement:

sqlplus / AS SYSASM

You can connect as SYSDBA to use SQL*Plus or ASMCMD commands to manage Oracle ASM components associated with the database. When running SQL or ASMCMD operations with the SYSDBA privilege, connect to the database instance rather than the Oracle ASM instance.

Connecting as SYSDBA to the database instance has a limited set of Oracle ASM privileges. For example, you cannot create a disk group when connected with the SYSDBA privilege.

When connected as SYSDBA to the database instance, the Oracle ASM operations are limited to:

• Create and delete files, aliases, directories, and templates

• Examine various Oracle ASM instance views

• Operate on files that were created by this user or only access files to which another user had explicitly granted access

• Granting Oracle ASM File Access Control to other users

An individual password file for Oracle Database or Oracle ASM can reside on a designated Oracle ASM disk group. Having the password files reside on a single location accessible across the cluster reduces maintenance costs and situations where passwords become out of sync.

You can use a password file located on a disk group for authentication only if the Oracle ASM instance is running and the designated disk group is mounted. Otherwise, operating system authentication must be used to bootstrap the startup of the Oracle ASM instance and stack.

The COMPATIBLE.ASM disk group attribute must be set to 12.1 or higher for the disk group where the password is to be located. The SYSASM privilege is required to manage the Oracle ASM password file. The SYSDBA privilege on Oracle ASM is required to manage the database password file.

The shared password file in a disk group is managed by ASMCMD commands, the ORAPWD tool, and SRVCTL commands. ORAPWD supports the creation of password files on an Oracle ASM disk group. All other password file manipulation is performed with ASMCMD or SRVCTL commands.

Before running commands, such as ORAPWD, to create a password file, ensure that the ORACLE_SID and ORACLE_HOME environmental variables have been set properly. For example, before setting the password file for Oracle ASM, set the ORACLE_SID and ORACLE_HOME environmental variables to ensure that you can connect to the local Oracle ASM instance. For information about environmental variables and connecting to an Oracle ASM instance, refer to Connecting To and Starting Up an Oracle ASM Instance.

SRVCTL provides commands to manage a password file in a disk group, such as the following commands for updating and displaying the location of the password file:

$ srvctl modify asm -pwfile location
$ srvctl modify database -db dbname -pwfile location
$ srvctl config asm

You can use orapwd to create a password file in a specified Oracle ASM disk group.

• To create an Oracle Database password file in a disk group from the existing password file on the file system, run orapwd with the dbuniquename switch. The dbuniquename switch specifies to create an Oracle Database password file for the database instance identified by orcl.

  1. Determine that the Oracle Database password file is currently located on the file system.

     SQL>  SELECT file_name FROM V$PASSWORDFILE_INFO; 
     FILE_NAME 
     ---------------------------------------------------------------------- 
      /u01/app/oracle/product/19.1.0/db_home1/dbs/orapworcl

  2. Run orapwd to move the password file to an Oracle ASM disk group.

     $ orapwd file='+data/ORCL/orapwdb' dbuniquename='orcl'
     
     Enter password for SYS:
     

  3. After the password file has been moved, update the password metadata cache with the ALTER SYSTEM statement and then confirm the new password file location.

     SQL>  ALTER SYSTEM FLUSH PASSWORDFILE_METADATA_CACHE;
     System altered.
     
     SQL>  SELECT file_name FROM v$passwordfile_info; 
     FILE_NAME 
     ---------------------------------------------------------------------- 
     +DATA/ORCL/orapwdb

• To create an Oracle ASM password file in a disk group, run orapwd with the asm switch set to y.

  $ orapwd file='+data/ASM/orapwasm' asm=y
  
  Enter password for SYS:
  

• To create an Oracle ASM password file in an Oracle ASM disk group from an existing password file, run orapwd with the input_file switch and the asm switch set to y.

  $ orapwd input_file='/oraclegrid/dbs/orapwasm' file='+data/ASM/orapwasm' asm=y
  
  Enter password for SYS:

You can make a backup of the Oracle ASM password file, and if the Oracle ASM password file is lost or the disk group becomes inaccessible, then you can restore the backup password file.

1. Locate the password file using the ASMCMD pwget command.

   For example:

   ASMCMD [+] > pwget --asm
   +DATA/orapwasm
   

2. Back up the password file to another disk group with the pwcopy command.

   For example:

   ASMCMD [+] > pwcopy +DATA/orapwasm +FRA/my_pwfile_backup
   

   Using pwcopy without the --asm or --dbuniquename option does not change the current location of the password file. If necessary after the copy is made, you can set the current password file location with the pwset command.

3. Verify which password file is in the current location after making a backup with the pwcopy command.

   For example:

   ASMCMD [+] > pwget --asm
   +DATA/orapwasm
   

4. Verify the backup password file was created.

   For example:

   ASMCMD [+] > ls +fra/my_pwfile_backup
   my_pwfile_backup
   

5. To restore the Oracle ASM password file, you can use pwset or pwcopy.

   To restore the Oracle ASM password file from the backup and use the existing location, use the pwset command with the --asm option.

   For example:

   ASMCMD [+] > pwset --asm +FRA/my_pwfile_backup
   

   To restore the Oracle ASM password file from the backup to another disk group, use the pwcopy command with the --asm option.

   For example:

   ASMCMD [+] > pwcopy --asm +FRA/my_pwfile_backup +DATA2/my_orapwasm
   

   The --asm option with the pwset and pwcopy command sets the password location for the Oracle ASM instance.

6. Verify the location of the current password file with the pwget command if you have changed the location.

   For example:

   ASMCMD [+] > pwget --asm
   +DATA2/my_orapwasm

   If the location of the current password file displayed is not the expected location, then flush the password metadata cache to refresh the password file information.

   SQL>  ALTER SYSTEM FLUSH PASSWORDFILE_METADATA_CACHE;
   System altered.