Skip Headers
Oracle® Automatic Storage Management Administrator's Guide
12c Release 1 (12.1)

E41058-08
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Index
Index
Go to Master Index
Master Index
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
PDF · Mobi · ePub

3 Administering Oracle ASM Instances

This chapter describes how to administer Automatic Storage Management (Oracle ASM) instances. It explains how to configure Oracle ASM instance parameters and how to set Oracle Database parameters for use with Oracle ASM. The chapter also describes Oracle ASM upgrading, patching, and authentication for Oracle ASM instance access. You can also use procedures in this chapter to migrate a database to use Oracle ASM.

Administering an Oracle ASM instance is similar to administering an Oracle Database instance, but the process requires fewer procedures. You can use Oracle ASM Command Line Utility (ASMCMD) command-line interface, Oracle ASM Configuration Assistant (ASMCA), and SQL*Plus to perform Oracle ASM instance administration tasks.

This chapter contains the following topics:

For a description of an Oracle ASM instance, see "About Oracle ASM Instances".

Operating with Different Releases of Oracle ASM and Database Instances Simultaneously

Oracle Automatic Storage Management (Oracle ASM) in Oracle Database 12c Release 1 (12.1) supports Oracle Database 12c Release 1 (12.1) or older software versions, including Oracle Database 10g Release 1 (10.1).

Notes:

  • An Oracle ASM instance must be at Oracle ASM 12c Release 1 (12.1) to support Oracle Database 12c Release 1 (12.1).

  • See Oracle Exadata documentation for information about the Oracle Database versions that Oracle ASM 12c Release 1 (12.1) supports when Oracle Exadata storage is present.

There are additional compatibility considerations when using disk groups with different releases of Oracle 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 Oracle ASM functionality of the earliest release in use. For example, an Oracle Database 10g Release 1 (10.1) database instance operating with an Oracle ASM 11g Release 2 (11.2) instance supports only Oracle ASM 10g Release 1 (10.1) features.

The V$ASM_CLIENT view contains the SOFTWARE_VERSION and COMPATIBLE_VERSION columns with information about the software version number and instance compatibility level.

  • The SOFTWARE_VERSION column of V$ASM_CLIENT contains the software version number of the database or Oracle ASM instance for the selected disk group connection.

  • The COMPATIBLE_VERSION column contains the setting of the COMPATIBLE parameter of the database or Oracle ASM instance for the selected disk group connection.

You can query the V$ASM_CLIENT view on both Oracle ASM and database instances. For an example showing a query on the V$ASM_CLIENT view, see Example 6-4, "Viewing disk group clients with V$ASM_CLIENT". For more information about the V$ASM_CLIENT and V$ASM_* views, see "Views Containing Oracle ASM Disk Group Information".

Configuring Initialization Parameters for Oracle ASM Instances

This section discusses initialization parameter files and parameter settings for Oracle ASM instances. To install and initially configure an Oracle ASM instance, use Oracle Universal Installer (OUI) and Oracle ASM Configuration Assistant (ASMCA). Refer to your platform-specific Oracle Grid Infrastructure Installation Guide for details about installing and configuring Oracle ASM.

After an Oracle ASM instance has been installed on a single-instance Oracle Database or in an Oracle Real Application Clusters (Oracle RAC) environment, the final Oracle ASM configuration can be performed. Only a few Oracle ASM-specific instance initialization parameters must be configured. The default values are usually sufficient.

See Also:

The Oracle Cloud Storage page on the Oracle Technology Network website at http://www.oracle.com/technetwork/database/cloud-storage/index.html for more information about Oracle ASM best practices

This section contains the following topics:

See Also:

Initialization Parameter Files for an Oracle ASM Instance

When installing Oracle ASM in an Oracle Restart (standalone) configuration, Oracle Universal Installer (OUI) creates a separate server parameter file (SPFILE) and password file for the Oracle ASM instance. The ASM SPFILE is stored in a disk group during installation.

When installing Oracle ASM in a clustered Oracle ASM environment, OUI creates a single, shared SPFILE for Oracle ASM in a disk group.

When upgrading an Oracle ASM instance, if the ASM SPFILE was originally in a shared file system, then the upgraded Oracle ASM instance retains the SPFILE in the same location. If the original Oracle ASM instance used a PFILE, then after an upgrade the instance continues to use a PFILE.

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 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 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, then 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

Note:

A PFILE or SPFILE is required if your configuration uses nondefault initialization parameters for the Oracle ASM instance.

You can administer Oracle ASM initialization parameter files with SQL*Plus, ASMCA, and ASMCMD commands. For information about the ASMCA GUI and command-line interfaces, see Chapter 9, "Managing Oracle ASM With ASMCA". For information about ASMCMD commands for managing an Oracle ASM SPFILE; such as spbackup, spcopy, and spmove; see "ASMCMD Instance Management Commands".

See Also:

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. In addition, you can use the SQL CREATE SPFILE to create an Oracle ASM SPFILE when connected to the Oracle ASM instance.

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

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

This section contains the following topics:

For information about ASMCMD commands for managing an SPFILE, see "spbackup", "spcopy", and "spmove".

See Also:

Creating, Copying, and Moving an SPFILE Into a Disk Group

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 instance from Oracle ASM 11g Release 1 (11.1) to Oracle ASM 11g Release 2 (11.2), you could place the Oracle ASM SPFILE in a disk group that has COMPATIBLE.ASM set to 11.2. For information about disk group compatibility attributes, see "Disk Group Compatibility".

In the following steps, assume an Oracle ASM 11g Release 2 (11.2) instance is using a PFILE stored in $ORACLE_HOME/dbs/asmpfile.ora. You can use the SQL CREATE SPFILE statement to create an 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 an SPFILE in a disk group, perform the following steps:

  1. Connect to the Oracle ASM instance.

    For example:

    $ sqlplus / as sysasm
    
  2. Create an 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/asmpfile.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 reads 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".

Making a Back Up Copy of an Oracle ASM SPFILE in a Disk Group

This section describes the steps to make a back up copy of an Oracle ASM SPFILE in another disk group using the ASMCMD commands. If necessary, then the backup copy can be used to restore the Oracle ASM SPFILE.

The source and target disk groups must have the disk group attribute COMPATIBLE.ASM set to 11.2 or higher.

To make a copy of the Oracle ASM SPFILE in another disk group with the spcopy command perform the following steps:

  1. Locate the Oracle ASM SPFILE using the ASMCMD spget command.

    For example:

    ASMCMD [+] > spget
    +DATA/ASM/ASMPARAMETERFILE/registry.253.849343867
    
  2. Copy the Oracle ASM SPFILE to another disk group with spcopy command.

    For example:

    ASMCMD [+] > spcopy +DATA/ASM/ASMPARAMETERFILE/registry.253.849343867 +FRA/spfileCopyASM.ora
    

    Running spcopy without the -u option does not update the location of the Oracle ASM SPFILE. You can use spset to set the location of the Oracle ASM SPFILE in the Grid Plug and Play (GPnP) profile.

  3. List all the copies of the Oracle ASM SPFILE file contained in the FRA disk group using the ASMCMD ls command.

    For example:

    ASMCMD [+] > ls -l --absolutepath FRA/ASM/ASMPARAMETERFILE
    Type              Redund  Striped  Time             Sys  Name
    ASMPARAMETERFILE  MIRROR  COARSE   JUN 06 13:00:00  Y    +FRA/spfileCopyASM.ora => REGISTRY.253.849533009
    
  4. Verify the current location of the Oracle ASM SPFILE file with the spget command.

    For example:

    ASMCMD [+] > spget
    +DATA/ASM/ASMPARAMETERFILE/registry.253.849343867
    

In the event that the current Oracle ASM SPFILE file in a disk group has been corrupted or that disk group is not accessible, you can use spset or spcopy with the -u option to restore the Oracle ASM SPFILE file using the backup copy that you have previously created.

For example:

ASMCMD [+] > spcopy -u +FRA/spfileCopyASM.ora +DATA2/ASM/spfileASM.ora

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 parameters after database creation using SQL ALTER SYSTEM or ALTER SESSION statements.

The Oracle 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 Oracle ASM instance initialization file. In general, Oracle ASM selects the appropriate defaults for database parameters that are relevant to an Oracle ASM instance.

This section contains the following topic:

Automatic Memory Management for Oracle ASM

Automatic memory management automatically manages the memory-related parameters for both Oracle ASM and database instances with the MEMORY_TARGET parameter. Automatic memory management is enabled by default on an Oracle 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 must set for complete Oracle ASM memory management. Oracle strongly recommends that you use automatic memory management for Oracle 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 MEMORY_TARGET to 0 in the Oracle ASM parameter file or by running an ALTER SYSTEM SET MEMORY_TARGET=0 statement. When you disable automatic memory management, Oracle reverts to automatic shared memory management and automatic PGA memory management. To revert to Oracle Database 10g Release 2 (10.2) functionality to manually manage Oracle ASM SGA memory, also run the ALTER SYSTEM SET SGA_TARGET=0 statement. Unless specified, the behaviors of the automatic memory management parameters in Oracle ASM instances behave the same as in Oracle Database instances.

Notes:

  • For a Linux environment, automatic memory management cannot work if /dev/shm is not available or is undersized. For more information, see Oracle Database Administrator's Reference for Linux and UNIX-Based Operating Systems. For information about platforms that support automatic memory management, see Oracle Database Administrator's Guide.

  • The minimum MEMORY_TARGET for Oracle ASM is 1 GB. If you set MEMORY_TARGET lower, then Oracle increases the value for MEMORY_TARGET to 1 GB automatically.

  • For the recommended settings of memory initialization parameters in an Oracle Exadata environment, refer to the Oracle Exadata documentation.

See Also:

Recommended Settings for Oracle ASM Initialization Parameters

This section contains information about the following initialization parameters for Oracle ASM:

See Also:

Oracle Database Administrator's Guide for more information about creating and maintaining an initialization parameter file

ASM_DISKGROUPS

The ASM_DISKGROUPS initialization parameter specifies a list of disk group names that an Oracle ASM instance mounts at startup when the SQL ALTER DISKGROUP ALL MOUNT statement is issued. The Oracle ASM instance startup process executes ALTER DISKGROUP ALL MOUNT unless the NOMOUNT startup option is specified.

The default value of the ASM_DISKGROUPS parameter is a NULL string. For information about disk groups that are mounted at startup time, see "About Mounting Disk Groups at Startup".

The ASM_DISKGROUPS parameter is dynamic. If you are using a server parameter file (SPFILE), then you do not have to manually alter the value of ASM_DISKGROUPS. Oracle ASM automatically adds a disk group to the parameter when the disk group is successfully created or mounted. Oracle ASM also automatically removes a disk group from the 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 = DATA, FRA;

When using a text initialization parameter file (PFILE), you may edit the initialization parameter file to add the name of any disk group so that it is 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:

ASM_DISKGROUPS = DATA, FRA

Note:

Issuing the ALTER DISKGROUP...ALL MOUNT or ALTER DISKGROUP...ALL DISMOUNT commands does not affect the value of ASM_DISKGROUPS.

For additional information about mounting Oracle ASM disk groups, see "Mounting and Dismounting Disk Groups".

For Oracle Database 12c Release 1 or later, Oracle ASM configurations support up to 511 disk groups. Oracle ASM configurations with Oracle Database releases before 12c Release 1 can only support up to 63 disk groups.

See Also:

Oracle Database Reference for more information about the ASM_DISKGROUPS initialization parameter

ASM_DISKSTRING

The ASM_DISKSTRING initialization parameter specifies a comma-delimited list of strings that limits the set of disks that an Oracle 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 Oracle 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, to limit the discovery process to only include disks that are in the /dev/rdsk/mydisks directory for an Oracle ASM instance that does not use Oracle ASM Filter Driver (Oracle ASMFD) or ASMLIB, set the ASM_DISKSTRING initialization parameter to:

/dev/rdsk/mydisks/*

The asterisk is required.

To limit the discovery process to only include disks that have a name that ends in disk3 or disk4, you could set ASM_DISKSTRING as follows on a Linux system:

ASM_DISKSTRING = '/dev/rdsk/*disk3', '/dev/rdsk/*disk4'

The ? 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 Oracle ASM to search a default path for all disks in the system to which the Oracle 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.

Oracle ASM cannot use a disk unless all of the Oracle ASM instances in the cluster can discover the disk through one of their own discovery strings. The names do not have 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.

For additional information about discovering disks, see "Oracle ASM Disk Discovery".

See Also:

  • Oracle Exadata documentation for information about the Oracle ASM discovery string format for Oracle Exadata

  • Oracle Database Reference for more information about the ASM_DISKSTRING initialization parameter

ASM_POWER_LIMIT

The ASM_POWER_LIMIT initialization parameter specifies the default power for disk rebalancing in a disk group. The range of values is 0 to 1024. The default value is 1. 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 and more rebalancing processes.

  • For disk groups that have the disk group ASM compatibility set to 11.2.0.2 or higher (for example, COMPATIBLE.ASM = 11.2.0.2), the operational range of values is 0 to 1024 for the rebalance power.

  • For disk groups that have the disk group ASM compatibility set to less than 11.2.0.2, the operational range of values is 0 to 11 inclusive. If the value for ASM_POWER_LIMIT is larger than 11, a value of 11 is used for these disk groups.

You can also specify the power of the rebalancing operation in a disk group with the POWER clause of the SQL ALTER DISKGROUP .. REBALANCE statement. The range of allowable values for the POWER clause is the same for the ASM_POWER_LIMIT initialization parameter. If the value of the POWER clause is specified larger than 11 for a disk group with ASM compatibility set to less than 11.2.0.2, then a warning is displayed and a POWER value equal to 11 is used for rebalancing.

The specification of the power of the rebalancing operation in a disk group only affects rebalance operations, not new allocations to a disk group.

For information about the ASM_POWER_LIMIT initialization parameter, and the POWER clause, refer to "Manually Rebalancing Disk Groups" and "Tuning Rebalance Operations". For information about disk group compatibility, see "Disk Group Compatibility".

See Also:

ASM_PREFERRED_READ_FAILURE_GROUPS

The 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. The ASM_PREFERRED_READ_FAILURE_GROUPS parameter setting is instance specific. The default value is NULL. This parameter is generally used for clustered Oracle ASM instances and its value can be different on different nodes.

For example:

diskgroup_name1.failure_group_name1, ...

For more information about ASM_PREFERRED_READ_FAILURE_GROUPS, refer to "Preferred Read Failure Groups".

See Also:

DB_CACHE_SIZE

You do not have to set a value for the DB_CACHE_SIZE initialization parameter if you use automatic memory management. The setting for the DB_CACHE_SIZE parameter determines the size of the buffer cache. This buffer cache stores metadata blocks. The default value for this parameter is suitable for most environments.

See Also:

DIAGNOSTIC_DEST

The DIAGNOSTIC_DEST initialization parameter specifies the directory where diagnostics for an instance are located. The default value for an Oracle ASM instance is the $ORACLE_BASE directory for the Oracle Grid Infrastructure installation.

Example 3-1 shows an example of the diagnostic directory for an Oracle ASM instance.

Example 3-1 Sample diagnostic directory for an Oracle ASM instance

$ ls $ORACLE_BASE/diag/asm/+asm/+ASM
alert  cdump  hm  incident  incpkg  ir  lck  metadata  stage  sweep  trace

See Also:

INSTANCE_TYPE

The INSTANCE_TYPE initialization parameter is optional for an Oracle ASM instance in an Oracle Grid Infrastructure home.

The following is an example of the INSTANCE_TYPE parameter in the initialization file:

INSTANCE_TYPE = ASM

In addition to values asm and rdbms, INSTANCE_TYPE can be set to asmproxy in an Oracle Flex ASM configuration. For more information about Oracle Flex ASM, refer to "Managing Oracle Flex ASM".

See Also:

Oracle Database Reference for more information about the INSTANCE_TYPE parameter

LARGE_POOL_SIZE

You do not have to set a value for the LARGE_POOL_SIZE initialization parameter if you use automatic memory management.

The setting for the LARGE_POOL_SIZE parameter is used for large allocations. The default value for this parameter is suitable for most environments.

See Also:

PROCESSES

The PROCESSES initialization parameter affects Oracle ASM, but the default value is usually suitable. However, if multiple database instances are connected to an Oracle ASM instance, then you can use the following formulas, where n is the number of database instances connecting to the Oracle ASM instance.

In a non-Exadata environment, the recommended settings are:

  • For n < 10, PROCESSES = 50*n + 50

  • For n >= 10, PROCESSES = 10*n + 450

In an Oracle Exadata environment, the recommended setting is PROCESSES = MAX(450 + 10*n, 1024).

See Also:

REMOTE_LOGIN_PASSWORDFILE

The REMOTE_LOGIN_PASSWORDFILE initialization parameter specifies whether the Oracle ASM instance checks for a password file. This parameter operates the same for Oracle ASM and database instances.

See Also:

SHARED_POOL_SIZE

You do not have to set a value for the SHARED_POOL_SIZE initialization parameter if you use automatic memory management. 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.

See Also:

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.

See Also:

The following are configuration 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 on Oracle ASM or 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

See Also:

Managing Oracle ASM Instances

Oracle ASM is typically installed in an Oracle Grid Infrastructure home separate from the Oracle Database home. Only one Oracle ASM instance is supported on a server in a standard configuration; however, Oracle Flex ASM provides additional configuration options.

When managing an Oracle ASM instance, the administration activity should be performed in the Oracle Grid Infrastructure home.

This section describes how to administer Oracle ASM instances under the following topics:

Managing Oracle Flex ASM

Oracle Flex ASM enables Oracle ASM instances to run on a separate physical server from the database servers. This section discusses Oracle Flex ASM in the following topics:

See Also:

Oracle Clusterware Administration and Deployment Guide for information about Oracle Flex Cluster support

Overview of Oracle Flex ASM

An Oracle ASM instance can operate in several configurations in Oracle Flex ASM, as shown in Figure 3-1. This illustration shows the distinct modes of operation which are available for Oracle Flex ASM in Oracle ASM 12c Release 1 (12.1).

Figure 3-1 Oracle Flex ASM Configurations

Description of Figure 3-1 follows
Description of "Figure 3-1 Oracle Flex ASM Configurations"

Oracle Flex ASM enables an Oracle ASM instance to run on a separate physical server from the database servers. With this deployment, larger clusters of Oracle ASM instances can support more database clients while reducing the Oracle ASM footprint for the overall system.

When using Oracle Flex ASM, Oracle ASM clients are configured with direct access to storage.

With Oracle Flex ASM, you can consolidate all the storage requirements into a single set of disk groups. All these disk groups are mounted by and managed by a small set of Oracle ASM instances running in a single cluster. You can specify the number of Oracle ASM instances with a cardinality setting. The default is three instances.

A cluster is a set of nodes that provide group membership services. Each cluster has a name that is globally unique. Every cluster has one or more Hub nodes. The Hub nodes have access to Oracle ASM disks. Every cluster has at least one private network and one public network. If the cluster is going to use Oracle ASM for storage, it has at least one Oracle ASM network. A single network can be used as both a private and an Oracle ASM network. For security reasons, an Oracle ASM network should never be public. There can be only one Oracle Flex ASM configuration running within a cluster.

The configurations of Oracle ASM in Oracle Flex ASM are:

  • Local Oracle ASM clients with direct access to Oracle ASM disks

    With this mode (Standard Oracle ASM cluster), Oracle ASM continues to support existing standard architecture in which database clients are running with an Oracle ASM instance on the same host computer. The local client architecture is only supported on a Hub node. This mode is labeled A in Figure 3-1.

    In this configuration, the database instances are on the same Hub node as the Oracle ASM instance and are referred to as local Oracle ASM client instances. Oracle ASM metadata moves between Oracle ASM and the database instances. This client has direct I/O access to Oracle ASM disks.

    Local mode does not use Oracle Flex ASM, so clusters configured with local Oracle ASM do not require an Oracle ASM network, nor do they contain other Oracle Flex ASM services.

  • Oracle Flex ASM clients with direct access to Oracle ASM disks

    With this mode, database clients that are running on Hub nodes of the Oracle ASM cluster access Oracle ASM remotely for metadata, but perform block I/O operations directly to Oracle ASM disks. The hosts running the Oracle ASM server and the remote database client must both be Hub nodes. A Hub node is a node in an Oracle ASM cluster that is tightly connected with other servers and has direct access to a shared disk. This mode is labeled B in Figure 3-1.

    In this configuration, the database instances are on different host computers than the nearby Oracle ASM instance and are referred to as Oracle ASM client instances. This Oracle ASM instance is shown on the node labeled C in Figure 3-1. The databases are in the same Oracle ASM cluster as the Oracle ASM instance and the database instances are located on a Hub node. Oracle ASM metadata moves between Oracle ASM and the database instance. This client has direct I/O access to Oracle ASM disks.

    Depending on the distribution of database instances and Oracle ASM instances, a database client may access Oracle ASM locally on the same node or remotely over the Oracle ASM network. This mode of operation is used by database clients on Hub nodes in the Oracle ASM cluster. Direct access mode is also the only Oracle Flex ASM configuration supported by Oracle ASM cluster file system.

  • Oracle ACFS access through the Oracle ASM proxy instance

    An Oracle ASM proxy instance is an Oracle instance running on a Hub node with a direct Oracle ASM client. Oracle Automatic Storage Management Cluster File System (Oracle ACFS) and Oracle ASM Dynamic Volume Manager (Oracle ADVM) are supported with an Oracle ASM proxy instance. This configuration is shown in Figure 3-2.

    The INSTANCE_TYPE initialization parameter is set to ASMPROXY for Oracle ASM proxy instances.

Figure 3-2 shows the configuration of Oracle ACFS and Oracle ADVM in Oracle Flex ASM.

Figure 3-2 Oracle ACFS and Oracle ADVM in Oracle Flex ASM

Description of Figure 3-2 follows
Description of "Figure 3-2 Oracle ACFS and Oracle ADVM in Oracle Flex ASM"

Setting Up Oracle Flex ASM

During the installation process with Oracle Universal Installer (OUI), you can choose the type of the Oracle Clusterware that should be installed. The Oracle Clusterware can be an Oracle Flex ASM deployment that manages its own storage or a regular Oracle ASM cluster.

Notes:

  • If you choose to install an Oracle Flex Cluster, Oracle Flex ASM is enabled by default because an Oracle Flex Cluster requires Oracle Flex ASM.

  • Clients based on releases before Oracle Database 12c Release 1 (12.1) require the local Oracle ASM clients configuration described in "Overview of Oracle Flex ASM" or an Oracle Flex ASM configuration with the Oracle ASM instance count (cardinality) set to ALL.

    For information about administering Oracle Flex ASM with SRVCTL commands, refer to "Administering Oracle Flex ASM".

  • Oracle does not support changing Oracle Flex ASM to a standard Oracle ASM configuration.

To install an Oracle Flex ASM deployment, note the following:

  • Categorize the networks and choose the list of networks for use as Oracle ASM networks.

    If you choose Oracle Flex ASM during a new installation, OUI requires you to choose the Oracle ASM networks.

    The Oracle ASM listener resource is automatically created for each Oracle ASM network and then started on all nodes.

  • Enable Oracle Flex ASM if necessary.

    Run Oracle ASM Configuration Assistant (ASMCA) to enable Oracle Flex ASM in a standard Oracle ASM cluster. This functionality is only available in an Oracle Grid Infrastructure configuration, not an Oracle Restart configuration. For information about converting to Oracle Flex ASM, refer to "Converting to Oracle Flex ASM".

    To determine whether an Oracle Flex ASM has been enabled, use the ASMCMD showclustermode command. For information about showclustermode, refer to "showclustermode".

    The ASMCA GUI utility steps through the requirements and changes all dependencies as required, including dependencies on Oracle ACFS. ASMCA informs you if additional tasks, such as moving a server parameter file (SPFILE) or password file (ORAPWD file) to a disk group, are required before the conversion. For information about those tasks, refer to "Backing Up, Copying, and Moving an Oracle ASM Initialization Parameter File" and "Managing a Shared Password File in a Disk Group".

See Also:

Oracle Grid Infrastructure Installation Guide for information about Oracle Clusterware installation

Administering Oracle Flex ASM

Oracle Flex ASM is managed by ASMCA, CRSCTL, SQL*Plus, and SRVCTL. The INSTANCE_TYPE initialization parameter specifies the type of instance.

The INSTANCE_TYPE initialization parameter has an additional value ASMPROXY, in addition to ASM and RDBMS, to identify Oracle ASM proxy instances. An Oracle ASM proxy instance has its parameter set to ASMPROXY.

You can use the ASMCMD showclustermode command to determine whether Oracle Flex ASM is enabled. For example:

$ asmcmd showclustermode
ASM cluster : Flex mode enabled 

SRVCTL is extended to enable an administrator to create or change attributes of Oracle Clusterware resources. You can use SRVCTL to determine the status of the instances in an Oracle Flex ASM configuration. For example:

$ srvctl status asm -detail
ASM is running on mynoden02,mynoden01
ASM is enabled.

You can also use SRVCTL to determine whether Oracle Flex ASM is enabled. If enabled, then srvctl config asm displays the number of Oracle ASM instances that has been specified for use with the Oracle Flex ASM configuration. For example:

$ srvctl config asm
ASM instance count: 3

You can modify the Oracle ASM instance count, or cardinality, with the SRVCTL modify asm command. For example:

$ srvctl modify asm -count 4

$ srvctl modify asm -count ALL

You can view Oracle Flex ASM connections with SQL*Plus and ASMCMD commands. Fore example:

SQL> SELECT instance_name, db_name, status FROM V$ASM_CLIENT;
INSTANCE_NAME   DB_NAME  STATUS
--------------- -------- ------------
+ASM1           +ASM     CONNECTED
orcl1           orcl     CONNECTED
orcl2           orcl     CONNECTED

$ asmcmd lsct data
DB_Name  Status    Software_Version  Compatible_version  Instance_Name  Disk_Group
+ASM     CONNECTED       12.1.0.0.2          12.1.0.0.2  +ASM           DATA
orcl     CONNECTED       12.1.0.0.2          12.0.0.0.0  orcl1          DATA
orcl     CONNECTED       12.1.0.0.2          12.0.0.0.0  orcl2          DATA

Clients are automatically relocated to another instance if an Oracle ASM instance fails. If necessary, clients can be manually relocated using the ALTER SYSTEM RELOCATE CLIENT command. For example:

SQL> ALTER SYSTEM RELOCATE CLIENT 'client-id';

In the previous SQL statement, client-id is of the form instance_name:db_name. The INSTANCE_NAME and DB_NAME columns are contained in the V$ASM_CLIENT view. You must connect as SYSASM to the Oracle ASM instance to run the SQL statement. When you issue this statement, the connection to the client is terminated and the client fails over to the least loaded instance. If the client is currently connected to the least loaded instance, then the connection to the client is terminated and the client fails over to that same instance.

Every database user must have a wallet with credentials to connect to Oracle ASM. CRSCTL commands can be used by the database user to manage this wallet. All Oracle ASM user names and passwords are system generated.

There are no new initialization parameters specifically for instances in an Oracle Flex ASM configuration; however, the settings of existing parameters should be reviewed and possibly adjusted for the Oracle Flex ASM environment. Refer to "Recommended Settings for Oracle ASM Initialization Parameters".

See Also:

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.

See Also:

Starting Up an Oracle ASM Instance

This section describes how to start Oracle ASM instances under the following topics:

Connecting To and 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 system identifier (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 to the Grid Infrastructure home where Oracle ASM was installed.

    Note:

    Oracle recommends that you do not change the default Oracle ASM SID name.
  • 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 have 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 encounter I/O errors and Oracle ACFS user data and metadata may not be written 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. You can use the RESTRICT clause 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.


SQLPLUS /NOLOG
SQL> CONNECT SYS AS SYSASM
Enter password: sys_password
Connected to an idle instance.

SQL> STARTUP
ASM instance started

Total System Global Area   71303168 bytes
Fixed Size                 1069292 bytes
Variable Size              45068052 bytes
ASM Cache                  25165824 bytes
ASM disk groups mounted

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

See Also:

Starting Up an Oracle ASM instance with an Incorrect SPFILE Path

If the SPFILE path in the GPnP profile is incorrect, you can start the Oracle ASM instance as follows:

  1. Create a PFILE with one line in it that identifies the path to the SPFILE.

    For example:

    Create the /oracle/dbs/spfileasm_init.ora file that contains:

    SPFILE='+DATA/asm/asmparameterfile/asmspfile.ora'

  2. Start up the instance using the initialization parameter file.

    For example:

    SQL> STARTUP PFILE=/oracle/dbs/spfileasm_init.ora

  3. After the instance is running, use the ASMCMD spset command to update the SPFILE path in the GPnP profile. See "spset".

    For example:

    ASMCMD> spset +DATA/asm/asmparameterfile/asmspfile.ora

See Also:

Oracle Database Administrator's Guide for more information about using STARTUP with a nondefault server parameter file

About Mounting Disk Groups at Startup

At startup, the Oracle ASM instance attempts to mount the following disk groups:

  • Disk groups specified in the ASM_DISKGROUPS initialization parameter

  • Disk group used by Cluster Synchronization Services (CSS) for voting files

  • Disk groups used by Oracle Clusterware for Oracle Cluster Registry (OCR)

  • Disk group used by the Oracle ASM instance to store the ASM server parameter file (SPFILE)

If no disk groups are found in the previous list, then the Oracle ASM instance does not mount any disk groups at startup. After the Oracle ASM instance has started, you can mount disk groups with the ALTER DISKGROUP...MOUNT command. For more information, see "Mounting and Dismounting Disk Groups".

About Restricted Mode

You can use the STARTUP RESTRICT command to control access to an Oracle ASM instance while you perform maintenance. When an Oracle 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 Oracle ASM instance. In addition, the restricted clause of the ALTER SYSTEM statement is disabled for the Oracle ASM instance. The ALTER DISKGROUP diskgroup MOUNT statement is extended to enable Oracle 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 Oracle 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 Oracle 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 Oracle 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.

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 to the Grid Infrastructure home where Oracle ASM was installed.

If you are not using Oracle Flex ASM, 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. If you are using Oracle Flex ASM, Oracle Flex ASM clients move to other running Oracle ASM instances if an Oracle ASM instance is shut down.

If Oracle Cluster Registry (OCR) or voting files are stored in a disk group, the disk group can only be dismounted by shutting down the Oracle ASM instance as part of shutting down the clusterware on a node. To shut down the clusterware, run crsctl stop crs.

See Also:

To shut down an Oracle ASM instance, perform the following steps:


SQLPLUS /NOLOG
SQL> CONNECT SYS AS SYSASM
Enter password: sys_password
Connected.
SQL> SHUTDOWN NORMAL

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

The following list describes the SHUTDOWN modes and 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 behaves the same as 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 encounter I/O errors and Oracle ACFS user data and metadata may not be written 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".

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 the Oracle ASM Oracle Clusterware (CRS) resource in Oracle Cluster Registry (OCR)

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

  • Display the Oracle ASM instance configuration and status

See Also:

The Oracle Real Application Clusters Administration and Deployment Guide for information about administering Oracle ASM instances with SRVCTL

Out of Place Upgrades

With an out-of-place upgrade, the installer installs the newer version of Oracle Grid Infrastructure in a separate Oracle Grid Infrastructure home.

An in-place upgrade of Oracle Grid Infrastructure 11g Release 2 (11.2) is not supported. For example, an upgrade of Oracle Grid Infrastructure 11g Release 2 (11.2.0.1) to Oracle Grid Infrastructure 11g Release 2 (11.2.0.2) must be an out of place upgrade.

See Also:

Oracle Grid Infrastructure Installation Guide for information about installing Oracle Grid Infrastructure, out of place upgrades, and performing rolling upgrades of Oracle Grid Infrastructure and Oracle ASM

Configuring Oracle Grid Infrastructure with the Configuration Wizard

The Oracle Grid Infrastructure configuration wizard can update the configuration of an Oracle Grid Infrastructure environment after the software has been installed. The configuration wizard accepts your input, validates the input, and populates the configuration data into the CRSCONFIG_PARAMS file. If additional scripts must be run, the configuration wizard directs you to run those scripts.

See Also:

Oracle Clusterware Administration and Deployment Guide for information about the Oracle Grid Infrastructure configuration wizard.

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.

See Also:

Oracle Home User on Windows

Oracle Database supports the use of an Oracle home user, which can be specified at installation time. The Oracle home user is associated with an Oracle home and it cannot be changed after installation. Different Oracle homes on a system can share the same Oracle home user or use different Oracle home user names.

In previous releases on Windows operating systems, Oracle services were required to run as Local System privileges, which are fully privileged. This feature enables the database, listener, and job scheduler services to run with low and non-administrative user privileges to allow tighter control of security.The Oracle home user can be a built-in account or a Windows user account. A Windows user account should be a low privileged (non-Administrator) account to ensure that the Oracle home user has a limited set of privileges, ensuring that Oracle Database services have only those privileges required to run Oracle products. The Windows user account can be a Local User, a Domain User, or a Managed Services Account in general. However, Oracle RAC, Oracle Restart, and Oracle Grid Infrastructure installations require the use of the Domain User as the Oracle home user because a clusterwide identity is necessary.

See Also:

Oracle Database Platform Guide for Microsoft Windows for information about running Oracle services on Windows platforms and different types of Windows user accounts

Upgrading and Patching Oracle ASM

This section contains the following topics:

Note:

  • For Oracle RAC environments, the Oracle Clusterware version number must be at least equal to the version number of the patch that you are applying to the Oracle Database.

  • You must apply the patch to the Oracle Grid Infrastructure home before you apply it to the Oracle Database home.

Using Oracle ASM Rolling Upgrade

Oracle ASM rolling upgrade enables you to independently upgrade or patch clustered Oracle ASM nodes without affecting database availability, thus providing greater uptime. Rolling upgrade means that some features of a clustered Oracle ASM environment continue to function when one or more of the nodes in the cluster uses different software versions. Oracle recommends that you perform an Oracle ASM rolling upgrade when performing an Oracle Clusterware rolling upgrade.

To perform a rolling upgrade, your environment must be prepared. Oracle Clusterware must be fully upgraded to the next patch or release version before you start the Oracle ASM rolling upgrade. In addition, you should prepare your Oracle Clusterware in a rolling upgrade manner to ensure high availability and maximum uptime.

Note that Oracle ASM is upgraded with Oracle Clusterware for Oracle 11g Release 2 (11.2) or later as both are in the Oracle Grid Infrastructure home.

Notes:

  • Rolling upgrades only apply to clustered Oracle ASM instances, and you can only perform rolling upgrades on environments with Oracle Database 11g or later. You cannot use this feature to upgrade from Oracle Database 10g to Oracle Database 11g.

  • See Oracle Exadata documentation for information about performing a rolling upgrading of an Oracle ASM instance when Oracle Exadata storage is present.

See Also:

Using Oracle ASM Rolling Patches

You can apply patches in a clusteredOracle ASM environment to update one node at a time to the latest patch level without affecting the overall availability of the Oracle ASM cluster or the database clusters using Oracle ASM for storage.

The ALTER SYSTEM ROLLING PATCH SQL statement enables you to start and stop rolling patches. For example:

SQL> ALTER SYSTEM START ROLLING PATCH;

SQL> ALTER SYSTEM STOP ROLLING PATCH;

You can determine if the cluster is in rolling patch mode by executing a SYS_CONTEXT SQL query for Cluster State. A new state (In Rolling Patch) is added to informing the user that the cluster is in rolling patch mode.

The queries in Example 3-2 display information about rolling patches. To run these queries, you must be connected to the Oracle ASM instance in the Grid home, and the Grid Infrastructure home must be configured with the Oracle Clusterware option for an Oracle RAC environment.

Example 3-2 Determining rolling patch mode and patch level

SELECT SYS_CONTEXT('SYS_CLUSTER_PROPERTIES', 'CLUSTER_STATE') FROM DUAL;

SELECT SYS_CONTEXT('SYS_CLUSTER_PROPERTIES', 'CURRENT_PATCHLVL') FROM DUAL;

You can view all the patch Ids applied on the node and cluster by querying the V$PATCHES view.

ASMCMD commands for rolling patches include:

  • showclusterstate

  • showpatches

  • showversion

For information about ASMCMD commands to monitor upgrade operations on an Oracle ASM instance, refer to "ASMCMD Instance Management Commands".

See Also:

Converting to Oracle Flex ASM

You can convert an Oracle ASM configuration to an Oracle Flex ASM using ASMCA. This functionality is only available in an Oracle Grid Infrastructure 12c configuration. For information about using ASMCA, refer to "Getting Started With the ASMCA GUI Tool". For

Note:

  • If you plan to introduce databases before Oracle Database 12c Release 1 (12.1) into a cluster configured with Oracle Flex ASM, you must ensure that Oracle ASM instances are running on all nodes in the cluster, including nodes that are added in the future. To ensure this requirement for the Oracle Flex ASM configuration, you must set the count of Oracle ASM instances to ALL with the SRVCTL modify asm command. For information about administering Oracle Flex ASM with SRVCTL commands, refer to "Administering Oracle Flex ASM".

  • For additional considerations, refer to the Notes in "Setting Up Oracle Flex ASM".

Before you convert an Oracle ASM configuration to an Oracle Flex ASM, you must ensure the following:

ASMCA informs you if any requirement, such as storing an ORAPWD file in a disk group, has not been met before starting the conversion.

Figure 3-3 shows the Configure ASM: ASM Instances page that enables you to perform operations on selected Oracle ASM instances.

Figure 3-3 Oracle ASM Configuration Assistant Configure ASM Instances Page

Description of Figure 3-3 follows
Description of "Figure 3-3 Oracle ASM Configuration Assistant Configure ASM Instances Page"

Figure 3-4 shows the Convert to Oracle Flex ASM dialog box that enables you to specify the listener port and network interface for the conversion to Oracle Flex ASM.

Figure 3-4 Oracle ASM Configuration Assistant Convert to Oracle Flex ASM Dialog Box

Description of Figure 3-4 follows
Description of "Figure 3-4 Oracle ASM Configuration Assistant Convert to Oracle Flex ASM Dialog Box"

To complete the Oracle Flex ASM conversion, ASMCA generates the converttoFlexASM.sh script that must be run as privileged user only on the local node where ASMCA is running. Figure 3-5 shows the ASM Conversion dialog box with the script that must be run.

Figure 3-5 Oracle ASM Configuration Assistant ASM Conversion Dialog Box

Description of Figure 3-5 follows
Description of "Figure 3-5 Oracle ASM Configuration Assistant ASM Conversion Dialog Box"

For information about the ASMCA command-line option for converting to Oracle Flex ASM, refer to "Convert to Oracle Flex ASM".

For information about Oracle Flex ASM, refer to "Managing Oracle Flex ASM".

See Also:

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

Administering Oracle ASM Filter Driver

Note:

This feature is available on Linux systems starting with Oracle Database 12c Release 1 (12.1.0.2).

Oracle ASM Filter Driver (Oracle ASMFD) is a kernel module that resides in the I/O path of the Oracle ASM disks. Oracle ASM uses the filter driver to validate write I/O requests to Oracle ASM disks.

The Oracle ASMFD simplifies the configuration and management of disk devices by eliminating the need to rebind disk devices used with Oracle ASM each time the system is restarted.

The Oracle ASM Filter Driver rejects any I/O requests that are invalid. This action eliminates accidental overwrites of Oracle ASM disks that would cause corruption in the disks and files within the disk group. For example, the Oracle ASM Filter Driver filters out all non-Oracle I/Os which could cause accidental overwrites.

After installation of Oracle Grid Infrastructure, you can optionally configure Oracle ASMFD for your system. If ASMLIB is configured for an existing Oracle ASM installation, then you must explicitly migrate the existing ASMLIB configuration to Oracle ASMFD.

Note:

In the steps of the procedures in this section, the $ORACLE_HOME environmental variable is set to the directory path of the Oracle Grid Infrastructure home. Commands that show # as the operating system prompt must be run as the root user. Commands that show $ as the operating system prompt should be run as the owner of Oracle Grid Infrastructure home.

For information about the ASMCMD commands for administering Oracle ASMFD, refer to "ASMCMD Oracle ASM Filter Driver Management Commands".

For information about all the ASMCMD commands, refer to "About ASMCMD".

For information about using Oracle Enterprise Manager to administer Oracle ASMFD, refer to "Managing Oracle ASM Filter Driver With Oracle Enterprise Manager".

See Also:

Oracle Grid Infrastructure Installation Guide for your operating system for information about installing and configuring Oracle Grid Infrastructure

This section contains the following topics:

Deciding Between Oracle ASMLIB and Oracle ASM Filter Driver

Oracle ASM Filter Driver (Oracle ASMFD) is installed with an Oracle Grid Infrastructure installation. If you have an existing Oracle ASM library driver (Oracle ASMLIB) configuration, then depending on whether you want to use Oracle ASMLIB or Oracle ASMFD, consider the following scenarios:

  • If you use Oracle ASMLIB to manage your Oracle ASM devices and you want to continue to use Oracle ASMLIB, then upgrade to Oracle Grid Infrastructure 12c Release 1 (12.1.0.2).

    Although Oracle ASMFD is installed, Oracle ASMLIB continues to be used for device persistence.

  • If you use Oracle ASMLIB to manage your Oracle ASM devices and you want to migrate to Oracle ASMFD, then perform the following steps:

    1. Upgrade to Oracle Grid Infrastructure 12c Release 1 (12.1.0.2).

      This process installs Oracle ASMFD.

    2. Migrate from Oracle ASMLIB to Oracle ASMFD.

      Refer to "Configuring Oracle ASM Filter Driver" to remove Oracle ASMLIB and configure your Oracle ASM devices to use Oracle ASMFD for device persistence.

  • If Oracle ASMLIB is installed, but you do not use Oracle ASM because Oracle Grid Infrastructure is not installed, and want to use Oracle ASMFD, then follow these steps:

    1. Deinstall Oracle ASMLIB.

      See Also:

      Oracle Grid Infrastructure Installation Guide for your operating system for information about installing and deinstalling Oracle ASMLIB
    2. Install Oracle Grid Infrastructure 12c Release 1 (12.1.0.2).

      This process installs Oracle ASMFD.

    3. Configure your Oracle ASM devices to use Oracle ASMFD for device persistence.

      Refer to "Configuring Oracle ASM Filter Driver".

    4. Create disk labels to enable migration of Oracle ASM disk groups to Oracle ASMFD.

      Refer to "Migrating to Oracle ASM Filter Driver From ASMLIB".

You can also set udev rules, in addition to or instead of Oracle ASMFD and Oracle ASMLIB, for device persistence.

Configuring Oracle ASM Filter Driver

After installing Oracle Grid Infrastructure 12c Release 1 (12.1.0.2), you can configure your Oracle ASM devices to use Oracle ASM Filter Driver (ASMFD) for device persistence.

This section contains the following topics:

See Also:

Oracle Clusterware Administration and Deployment Guide for information about using CRSCTL commands

Configuring Oracle ASM in an Oracle Grid Infrastructure Clusterware Environment

To configure Oracle ASMFD in an Oracle Clusterware environment, follow these steps:

  1. As the Oracle Grid Infrastructure owner update the Oracle ASM disk discovery string to enable Oracle ASMFD to discover devices in the future.

    For example, check the current value of the Oracle ASM disk discovery string and then update the value.

    $ $ORACLE_HOME/bin/asmcmd dsget
    
    $ $ORACLE_HOME/bin/asmcmd dsset old_diskstring, 'AFD:*'
    

    The value of old_diskstring is the current Oracle ASM disk discovery string value.

    For information about updating the Oracle ASM discovery string, refer to "Updating the Oracle ASM ASM_DISKSTRING Parameter for Oracle ASM Filter Driver Disks".

  2. As the Oracle Grid Infrastructure owner list the nodes and node roles in your cluster:

    $ $ORACLE_HOME/bin/olsnodes -a
    
  3. On each Hub node, do the following, either in rolling or non-rolling mode:

    1. Log in as the root user and stop Oracle Grid Infrastructure:

      # $ORACLE_HOME/bin/crsctl stop crs
      

      If the command returns an error, then stop Oracle Grid Infrastructure forcibly as follows:

      # $ORACLE_HOME/bin/crsctl stop crs -f
      
    2. As root, configure Oracle ASMFD to filter at the node level:

      # $ORACLE_HOME/bin/asmcmd afd_configure
      
    3. As the Oracle Grid Infrastructure owner verify the status of Oracle ASMFD:

      $ $ORACLE_HOME/bin/asmcmd afd_state
      ASMCMD-9526: The AFD state is 'LOADED' and filtering is 'ENABLED' on host 'myhost'
      

      For information about checking on the state of the Oracle ASM Filter Driver, refer to "Determining Whether Oracle ASM Filter Driver Has Been Configured".

    4. As root, start the Oracle Clusterware stack on the node:

      # $ORACLE_HOME/bin/crsctl start crs
      
    5. As the Oracle Grid Infrastructure owner set the Oracle ASMFD discovery disk string to the original Oracle ASM disk discovery string value that was retrieved in Step 1:

      $ $ORACLE_HOME/bin/asmcmd afd_dsset old_diskstring
      

      The value of old_diskstring is the old disk discovery string value without the AFD: (Oracle ASMFD) path.

      For information about updating the Oracle ASM Filter Driver discovery disk discovery string, refer to "Updating the Oracle ASM Filter Driver AFD_DISKSTRING Parameter".

      For information about updating the Oracle ASM discovery disk discovery string, refer to "Updating the Oracle ASM ASM_DISKSTRING Parameter for Oracle ASM Filter Driver Disks".

Oracle ASM Filter Driver should identify and start managing disks previously managed by Oracle ASMLIB.

Configuring Oracle ASM in an Oracle Grid Infrastructure Standalone (Oracle Restart) Environment

To configure Oracle ASMFD in a standalone environment, follow these steps:

  1. As the Oracle Grid Infrastructure standalone server owner update the Oracle ASM disk discovery string to enable Oracle ASMFD to discover disk devices.

    For example, check the current value of the Oracle ASM disk discovery string and then update the value.

    $ $ORACLE_HOME/bin/asmcmd dsget
    
    $ $ORACLE_HOME/bin/asmcmd dsset old_diskstring, 'AFD:*'
    

    Where old_diskstring is the current disk discovery string value.

    For information about updating the Oracle ASM discovery string, refer to "Updating the Oracle ASM ASM_DISKSTRING Parameter for Oracle ASM Filter Driver Disks".

  2. Log in as the root user and stop Oracle Grid Infrastructure for a standalone server using the following command:

    # $ORACLE_HOME/bin/crsctl stop has -f
    
  3. As root, configure Oracle ASMFD using the following command:

    # $ORACLE_HOME/bin/asmcmd afd_configure
    

    This command configures Oracle ASMFD and deconfigures Oracle ASMLIB, if it exists.

  4. As the Oracle Grid Infrastructure standalone server owner verify the Oracle ASMFD status:

    $ $ORACLE_HOME/bin/asmcmd afd_state
    
    ASMCMD-9526: The AFD state is 'LOADED' and filtering is 'ENABLED' on host 'myhost'
    

    For information about checking on the state of the Oracle ASM Filter Driver, refer to "Determining Whether Oracle ASM Filter Driver Has Been Configured".

  5. As root, start Oracle Grid Infrastructure for a standalone server:

    # $ORACLE_HOME/bin/crsctl start has
    
  6. As the Oracle Grid Infrastructure standalone server owner set the Oracle ASMFD disk discovery string to the original value of the Oracle ASM disk discovery string that was retrieved in Step 1:

    $ $ORACLE_HOME/bin/asmcmd afd_dsset disk_string
    

Oracle ASM Filter Driver should identify and start managing disks previously managed by Oracle ASMLIB.

Migrating to Oracle ASM Filter Driver From ASMLIB

If Oracle ASMLIB was installed, but not used earlier, you must create disk labels to enable migration of Oracle ASM disk groups to Oracle ASM Filter Driver (Oracle ASMFD) after installing Oracle Grid Infrastructure 12c Release 1 (12.1.0.2).

Oracle recommends that you temporarily move Oracle Cluster Registry (OCR) and voting files to another disk group if one is available, as described in "Migrating Oracle ASM Disk Groups without Oracle Cluster Registry or Voting Files", and migrate the diskgroup to use Oracle ASMFD. After migrating the disk group to use Oracle ASMFD, move OCR and voting files back to the disk group. You can similarly migrate any other disk groups if they contain OCR or voting files to ensure online migration of all disk groups to Oracle ASMFD.

This section contains the following topics:

See Also:

Migrating Oracle ASM Disk Groups without Oracle Cluster Registry or Voting Files

To migrate Oracle ASM disk groups without Oracle Cluster Registry (OCR) or voting files to Oracle ASMFD:

  1. Log in as the Oracle Grid Infrastructure owner on any node to run the commands in this procedure.

  2. List the existing disk groups:

    $ $ORACLE_HOME/bin/asmcmd lsdg
    
  3. List the associated disks:

    $ $ORACLE_HOME/bin/asmcmd lsdsk -G diskgroup
    
  4. Check if Oracle ASM is active:

    $ $ORACLE_HOME/bin/srvctl status asm
    
  5. Stop the databases and dismount the disk group on all nodes:

    $ $ORACLE_HOME/bin/srvctl stop diskgroup -diskgroup diskgroup -f
    
  6. Label all existing disks in the disk group by running the following command for each disk on a Hub node:

    $ $ORACLE_HOME/bin/asmcmd afd_label disk_path label --migrate
    
  7. Scan the disks on all Hub nodes:

    $ $ORACLE_HOME/bin/asmcmd afd_scan 
    
  8. Start the databases and mount the disk group on all nodes:

    $ $ORACLE_HOME/bin/srvctl start diskgroup -diskgroup diskgroup
    

Migrating Oracle ASM Disk Groups with Oracle Cluster Registry or Voting Files

To migrate Oracle ASM disk groups with Oracle Cluster Registry (OCR) or voting files to Oracle ASM Filter Driver (Oracle ASMFD):

  1. Log in as the root user and list the disk groups with OCR and voting files by running the following commands on one node:

    # $ORACLE_HOME/bin/ocrcheck -config
    
    # $ORACLE_HOME/bin/crsctl query css votedisk
    
  2. As the Oracle Grid Infrastructure owner list the disks associated with the disk groups:

    $ $ORACLE_HOME/bin/asmcmd lsdsk -G disk_group 
    
  3. As root, stop the databases and Oracle Clusterware on all nodes:

    # $ORACLE_HOME/bin/crsctl stop cluster -all
    
  4. As the Oracle Grid Infrastructure owner label all existing disks in the disk group by running the following command for each disk on a Hub node:

    $ $ORACLE_HOME/bin/asmcmd afd_label disk_path label 
    
  5. As the Oracle Grid Infrastructure owner rescan the disks on all Hub nodes by running the following command on all of the Hub nodes:

    $ $ORACLE_HOME/bin/asmcmd afd_scan
    
  6. As root, start the Oracle Clusterware stack on all nodes and mount the OCR and voting files disk groups and databases:

    # $ORACLE_HOME/bin/crsctl start cluster -all
    

Migrating Oracle ASM Disk Groups in an Oracle Grid Infrastructure Standalone (Oracle Restart) Environment

To migrate your existing Oracle ASM disk groups to Oracle ASM Filter Driver in an Oracle Grid Infrastructure standalone environment, perform the following steps:

  1. Log in as the Oracle Grid Infrastructure standalone server owner to run the steps in this procedure.

  2. List the existing disk groups:

    $ $ORACLE_HOME/bin/asmcmd lsdg 
    
  3. List the existing disks:

    $ $ORACLE_HOME/bin/asmcmd lsdsk -G diskgroup_name
    
  4. Check if the status of your Oracle ASM instance is active:

    $ $ORACLE_HOME/bin/srvctl status asm
    
  5. Stop all the databases and dismount all disk groups. For each database, run the following commands:

    $ $ORACLE_HOME/bin/srvctl stop database -db db_unique_name
    
    $ /$ORACLE_HOME/bin/srvctl stop diskgroup -diskgroup diskgroup_name -f
    
  6. Label all existing disks in the disk group by running the following command for each disk:

    $ $ORACLE_HOME/bin/asmcmd afd_label disk_path label --migrate
    
  7. Rescan the disks:

    $ $ORACLE_HOME/bin/asmcmd afd_scan
    
  8. Start the database and mount the disk group:

    $ $ORACLE_HOME/bin/srvctl start diskgroup -diskgroup diskgroup_name
    

Determining Whether Oracle ASM Filter Driver Has Been Configured

The value of the AFD_STATE parameter of SYS_ASMFD_PROPERTIES specifies whether Oracle ASMFD is configured for the Oracle ASM instance.

You can check the state of Oracle ASMFD with the ASMCMD afd_state command. For example:

$ $ORACLE_HOME/bin/asmcmd afd_state
ASMCMD-9526: The AFD state is 'LOADED' and filtering is 'DEFAULT' on host 'myhost'

For information about using the ASMCMD afd_state command to determine the state of Oracle ASMFD, refer to "afd_state".

To determine if Oracles ASMFD is present on the host, you can also display the value of AFD_STATE from SYS_CONTEXT. You must run the query on the Oracle ASM instance.

If the value of AFD_STATE is equal to NOT AVAILABLE, then Oracle ASMFD is not configured.

SQL> SELECT SYS_CONTEXT('SYS_ASMFD_PROPERTIES', 'AFD_STATE') FROM DUAL;
SYS_CONTEXT('SYS_ASMFD_PROPERTIES','AFD_STATE')
--------------------------------------------------------------------------------
NOT AVAILABLE

A value of CONFIGURED means that Oracle ASMFD is completely set up and the Oracle ASM instance can register with the driver.

SQL> SELECT SYS_CONTEXT('SYS_ASMFD_PROPERTIES', 'AFD_STATE') FROM DUAL;
SYS_CONTEXT('SYS_ASMFD_PROPERTIES','AFD_STATE')
--------------------------------------------------------------------------------
CONFIGURED

Updating the Oracle ASM Filter Driver AFD_DISKSTRING Parameter

The AFD_DISKSTRING parameter specifies the Oracle ASMFD disk discovery string that is used to identify the disks to be managed by Oracle ASMFD.

You can set and display the AFD_DISKSTRING parameter with the ASMCMD afd_dsset and afd_dgset commands. For example:

$ $ORACLE_HOME/bin/asmcmd afd_dsset '/dev/rdsk/mydisks/*'

$ $ORACLE_HOME/bin/asmcmd afd_dsget
AFD discovery string: /dev/rdsk/mydisks/*

For information about ASMCMD commands to display and set the Oracle ASMFD disk discovery string, refer to "afd_dsget" and "afd_dsset".

You can also set the AFD_DISKSTRING with the ALTER SYSTEM SQL statement. A label is created in the disk header of those disks identified by the Oracle ASMFD disk discovery string.

SQL> ALTER SYSTEM AFD_DISKSTRING SET '/dev/disk0','/dev/disk1','/devices/dsk/*';
System altered.

You can retrieve the value of AFD_DISKSTRING parameter with the following query.

SQL> SELECT SYS_CONTEXT('SYS_ASMFD_PROPERTIES', 'AFD_DISKSTRING') FROM DUAL;
SYS_CONTEXT('SYS_ASMFD_PROPERTIES','AFD_DISKSTRING')
--------------------------------------------------------------------------------
'/dev/disk0','/dev/disk1','/devices/dsk/*'

Updating the Oracle ASM ASM_DISKSTRING Parameter for Oracle ASM Filter Driver Disks

You can update the Oracle ASM disk discovery string to add or remove Oracle ASMFD disk label names to and from the ASM_DIKSTRING initialization parameter.

For example, you can add the Oracle ASMFD disks to the ASM_DIKSTRING initialization parameter as follows:

ASM_DISKSTRING = 'AFD:DISK0', 'AFD:DISK1', '/dev/rdsk/mydisks/*'

Or you can set the ASM_DIKSTRING initialization parameter as follows:

ASM_DISKSTRING = 'AFD:*', '/dev/rdsk/mydisks/*'

You can display and set the Oracle ASM disk discovery string with the ASMCMD dsget and dsset commands. For example, you can set the Oracle ASM disk discovery string to add Oracle ASMFD disks as follows:

$ $ORACLE_HOME/bin/asmcmd dsset 'AFD:*','/dev/rdsk/mydisks/*'

You can remove previously added Oracle ASMFD disks as follows:

$ $ORACLE_HOME/bin/asmcmd dsset '/dev/rdsk/mydisks/*'

For information about ASMCMD commands to display and set the Oracle ASM disk discovery string, refer to "dsget" and "dsset".

For information about the ASM_DISKSTRING initialization parameter, refer to "ASM_DISKSTRING".

Setting, Clearing, and Scanning Oracle ASM Filter Driver Labels

Setting a label provisions a disk to be used by Oracle ASMFD. After the label is set, the specified disk is managed by Oracle ASMFD.

You can add, remove, and scan labels with the ASMCMD afd_label, afd_unlabel, and afd_scan commands. For example:

$ $ORACLE_HOME/bin/asmcmd afd_label 'disk0' '/dev/rdsk/mydisks/disk0'

$ $ORACLE_HOME/bin/asmcmd afd_unlabel 'disk0'

$ $ORACLE_HOME/bin/asmcmd afd_scan '/dev/rdsk/mydisks/*'

For information about ASMCMD commands to add and remove labels on Oracle ASMFD disks, refer to "afd_label", "afd_unlabel", and "afd_scan". In addition, ASMCA provides support for adding and removing labels on Oracle ASMFD disks. For information about using ASMCA to administer disk groups, refer to "Managing Disk Groups with ASMCA".

You can also manage labels with SQL statements. You can set a label with the ALTER SYSTEM LABEL SET SQL statement. For example:

SQL> ALTER SYSTEM LABEL SET 'disk0' TO '/dev/disk0';
System altered.

SQL> SELECT UPPER(path) FROM V$ASM_DISK ORDER BY PATH;
UPPER(PATH)
--------------------------------------------------------------------------------
AFD:DISK0

When you run the statement, you can use the optional RENAME or MIGRATE option. If a disk was previously provisioned for Oracle ASMFD, you can rename the label with the RENAME option. Note that the device should not be managed with Oracle ASMFD when the command is run. If a disk was previously used for an Oracle ASM disk group and the disk group has been dismounted, then you can label this disk using the MIGRATE option.

You can use ALTER SYSTEM LABEL CLEAR to remove the label from a device and stop Oracle ASMFD from managing the device. For example:

SQL> ALTER SYSTEM LABEL CLEAR 'disk0';
System altered.

You can use ALTER SYSTEM LABEL SCAN on remote nodes after the ALTER SYSTEM LABEL SET command is run on the local node.

Because ALTER SYSTEM LABEL SET statement writes the label on the disk header and the disk is shared across nodes, the same statement is not run on other nodes of the cluster. Instead, ALTER SYSTEM LABEL SCAN is run with device path so that Oracle ASMFD on that node starts managing the device. If the device-path is not specified, then the statement uses the AFD_DISKSTRING parameter value to perform the scan operation.

SQL> ALTER SYSTEM LABEL SCAN 'disk0'

Deconfiguring Oracle ASM Filter Driver

You can deconfigure Oracle ASM Filter Driver (Oracle ASMFD) if it has been configured on your system.

This section contains the following topics:

For information about the ASMCMD commands for administering Oracle ASMFD, refer to "ASMCMD Oracle ASM Filter Driver Management Commands".

See Also:

Oracle Clusterware Administration and Deployment Guide for information about using CRSCTL commands

Deconfiguring Oracle ASM Filter Driver in an Oracle Grid Infrastructure Clusterware Environment

Perform the following steps to deconfigure Oracle ASM Filter Driver in an Oracle Clusterware environment:

  1. Update the Oracle ASM disk discovery string to enable Oracle ASM to discover disk devices after Oracle ASMFD is deconfigured.

    For information about updating the Oracle ASM disk discovery string, refer to "Updating the Oracle ASM ASM_DISKSTRING Parameter for Oracle ASM Filter Driver Disks".

  2. As the Oracle Grid Infrastructure owner list the nodes and node roles in your cluster by running the following command on any node:

    $ $ORACLE_HOME/bin/olsnodes -a
    
  3. On each Hub node, do the following, either in rolling or non-rolling mode:

    1. Log in as the root user and stop Oracle Grid Infrastructure:

      # $ORACLE_HOME/bin/crsctl stop crs
      

      If the command returns any error, then stop Oracle Grid Infrastructure forcibly as follows:

      # $ORACLE_HOME/bin/crsctl stop crs -f
      
    2. As root, stop Oracle ACFS kernel modules to ensure the most reliable shutdown:

      # $ORACLE_HOME/bin/acfsload stop
      

      For information about the acfsload command, refer to "acfsload".

    3. As root, deconfigure Oracle ASMFD:

      # $ORACLE_HOME/bin/asmcmd afd_deconfigure
      
    4. As root, start ACFS kernel modules:

      # $ORACLE_HOME/bin/acfsload start
      

      For information about the acfsload command, refer to "acfsload".

    5. As root, start the Oracle Clusterware stack on the node:

      # $ORACLE_HOME/bin/crsctl start crs
      
    6. As the Oracle Grid Infrastructure owner verify the status of Oracle ASMFD:

      $ $ORACLE_HOME/bin/asmcmd afd_state
      

      For information about checking on the state of the Oracle ASM Filter Driver, refer to "Determining Whether Oracle ASM Filter Driver Has Been Configured".

  4. As the Oracle Grid Infrastructure owner update the Oracle ASM discovery string to remove the Oracle ASMFD path:

    $ $ORACLE_HOME/bin/asmcmd dsget
    
    $ $ORACLE_HOME/bin/asmcmd dsset old_diskstring
    

    Check the current value of the Oracle ASM disk discovery string before updating the value. The old_diskstring value is the old disk discovery string value before updating with the AFD: (Oracle ASMFD) paths.

    For information about updating the Oracle ASM discovery string, refer to "Updating the Oracle ASM ASM_DISKSTRING Parameter for Oracle ASM Filter Driver Disks".

    For information about updating the Oracle ASM Filter Driver discovery disk discovery string, refer to "Updating the Oracle ASM Filter Driver AFD_DISKSTRING Parameter".

Deconfiguring Oracle ASM Filter Driver in an Oracle Grid Infrastructure Standalone (Oracle Restart) Environment

Perform the following steps to deconfigure Oracle ASM Filter Driver in an Oracle Grid Infrastructure standalone environment:

  1. Update the Oracle ASM disk discovery string to enable Oracle ASM to discover disk devices after Oracle ASMFD is deconfigured.

    For information about updating the Oracle ASM disk discovery string, refer to "Updating the Oracle ASM ASM_DISKSTRING Parameter for Oracle ASM Filter Driver Disks".

  2. Log in as the root user and stop Oracle Grid Infrastructure for a standalone server using the following command:

    # $ORACLE_HOME/bin/crsctl stop has
    

    If the previous command returns an error, then use the following command:

    # $ORACLE_HOME/bin/crsctl stop has -f
    
  3. As root, stop Oracle ACFS kernel modules to ensure the most reliable shutdown:

    # $ORACLE_HOME/bin/acfsload stop
    

    For information about the acfsload command, refer to "acfsload".

  4. As root, deconfigure Oracle ASMFD:

    # $ORACLE_HOME/bin/asmcmd afd_deconfigure
    
  5. As root, start ACFS kernel modules:

    # $ORACLE_HOME/bin/acfsload start
    

    For information about the acfsload command, refer to "acfsload".

  6. As root, start Oracle Grid Infrastructure for a standalone server:

    # $ORACLE_HOME/bin/crsctl start has
    
  7. As the Oracle Grid Infrastructure standalone server owner verify the Oracle ASMFD status:

    $ $ORACLE_HOME/bin/asmcmd afd_state
    

    For information about checking on the state of the Oracle ASM Filter Driver, refer to "Determining Whether Oracle ASM Filter Driver Has Been Configured".

  8. As the Oracle Grid Infrastructure standalone server owner update the Oracle ASM disk discovery string to remove the Oracle ASMFD paths:

    $ $ORACLE_HOME/bin/asmcmd dsget
    
    $ $ORACLE_HOME/bin/asmcmd dsset old_diskstring
    

    Check the current value of the Oracle ASM disk discovery string before updating the value. The old_diskstring value is the old disk discovery string value before updating with the AFD: (Oracle ASMFD) paths.

    For information about updating the Oracle ASM discovery string, refer to "Updating the Oracle ASM ASM_DISKSTRING Parameter for Oracle ASM Filter Driver Disks".

    For information about updating the Oracle ASM Filter Driver discovery disk discovery string, refer to "Updating the Oracle ASM Filter Driver AFD_DISKSTRING Parameter".

Authentication for Accessing Oracle ASM Instances

An Oracle ASM instance does not have a data dictionary, so the only way to connect to an Oracle ASM instance is by using one of three system privileges, SYSASM, SYSDBA, or SYSOPER. There are three modes of connecting to Oracle ASM instances:

  • Local connection using operating system authentication

  • Local connection using password authentication

  • Remote connection by way of Oracle Net Services using password authentication

See Also:

Your operating system-specific Oracle Grid Infrastructure Installation Guide for information about how to ensure that the Oracle ASM and database instances have member disk access

This section describes the following topics:

The Oracle ASM and database instances must have read/write operating system access rights to disk groups. For example, the Oracle ASM instance and the database instance must have identical read and write permissions for the disks that comprise the related Oracle ASM disk group. For Linux and UNIX systems, this is typically provided through shared Linux and UNIX group membership (OSASM group). On Windows systems, the Oracle ASM service must be run as Administrator. For information about file permissions and Oracle ASM File Access Control, see "Managing Oracle ASM File Access Control for Disk Groups".

See Also:

Oracle Database Security Guide for information about maintaining database security, including assigning passwords

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 results in an error. The SYSDBA privilege is intended to be used by the database to access disk groups.

Oracle also recommends 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:

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

Using One Operating System Group for Oracle ASM Users

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.

Table 3-1 One operating system group and one set of privileges for all Oracle ASM users

Role/Software Owner User Group/Privilege

Oracle ASM administrator/Oracle Grid Infrastructure home

oracle

dba/SYSASM, SYSDBA, SYSOPER

Database administrator 1/Database home 1

oracle

dba/SYSASM, SYSDBA, SYSOPER

Database administrator 2/Database home 2

oracle

dba/SYSASM, SYSDBA, SYSOPER

Operating system disk device owner

oracle

dba


Using Separate Operating System Groups 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

    This group is granted the SYSASM privilege, which provides full administrative privileges for the Oracle ASM instance. For example, the group could be asmadmin.

  • OSDBA for Oracle ASM group

    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, such as dba. For example, the group could be asmdba.

  • OSOPER for Oracle ASM group

    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. For example, the group could be asmoper.

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.

Table 3-2 Separated operating system groups and privileges for Oracle ASM users

Role/Software Owner User Group/Privilege

Oracle ASM administrator/Oracle Grid Infrastructure home

grid

asmadmin (OSASM)/SYSASM

asmdba (OSDBA for ASM)/SYSDBA

asmoper (OSOPER for ASM)/SYSOPER

dba1, dba2, ... (OSDBA for the databases when in an Oracle Restart configuration)

Database administrator 1/Database home 1

oracle1

asmdba (OSDBA for ASM)/SYSDBA

oper1 (OSOPER for database 1)/SYSOPER

dba1 (OSDBA for database 1)/SYSDBA

Database administrator 2/Database home 2

oracle2

asmdba (OSDBA for ASM)/SYSDBA

oper2 (OSOPER for database 2)/SYSOPER

dba2 (OSDBA for database 2)/SYSDBA

Operating system disk device owner

grid

asmadmin (OSASM)


The SYSASM Privilege for Administering Oracle ASM

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

The SYSDBA Privilege for Managing Oracle ASM Components

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

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 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.

Note:

These commands update the password file for the local Oracle ASM instance only.

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;

When you revoke the last privilege of a user in an Oracle ASM password file, the user is not automatically deleted as is done in the Oracle Database password file. You must run DROP USER to delete a user with no privileges in an Oracle ASM password file.

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

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, dba is the default operating system group designated as OSASM, OSOPER, and OSDBA for Oracle ASM.

On Windows systems, ORA_ASMADMIN, ORA_ASMDBA, and ORA_ASMOPER are the operating system groups designated for OSASM, OSDBA and OSOPER respectively for Oracle ASM.

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

See Also:

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.

If you select the Oracle ASM storage option, then ASMCA creates a password file for Oracle ASM with initial users (SYS and ASMSNMP) when ASMCA configures the Oracle ASM disk groups. 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 use password file authentication.

See Also:

Managing a Shared Password File in a Disk Group

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 at least 12.1 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

This sections contains these topics:

For information about ASMCMD commands to manage an Oracle ASM or database instance password file in a disk group; such as pwcopy, pwcreate, and pwmove; refer to "ASMCMD Instance Management Commands".

See Also:

Creating a Password File in a Disk Group

When using orapwd to create a database password file in a disk group, you must specify the disk group location and database unique name.

For example:

$ orapwd file='+data/ORCL/orapwdb' dbuniquename='orcl'

Enter password for SYS:

The asm switch specifies that orapwd create an Oracle ASM password file rather than a database password file.

For example:

$ orapwd file='+data/ASM/orapwasm' asm=y

Enter password for SYS:

You can create a new password file in a disk group using a password file from a previous release.

For example:

$ orapwd input_file='/oraclegrid/dbs/orapwasm' file='+data/ASM/orapwasm' asm=y

Enter password for SYS:

Backing Up and Restoring an Oracle ASM Password File in a Disk Group

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.

This section describes the steps to back up the Oracle ASM password file to a disk group and the steps to restore the Oracle ASM password file.

The source and target disk groups must have the disk group attribute COMPATIBLE.ASM set to 12.1 or higher.

  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
    

Migrating a Database to Use Oracle ASM

With a new installation of Oracle Database and Oracle ASM, you can initially create your database and select the Oracle ASM storage option. If you have an existing Oracle Database that stores database files in the operating system file system, then you can migrate some or all of your data files to Oracle ASM storage.

Oracle provides several methods for migrating your database to Oracle ASM. Using Oracle ASM enables you to realize the benefits of automation and simplicity in managing your database storage. To migrate to Oracle ASM, you can use the methods described in the following sections:

Note:

You must upgrade to at least Oracle Database 10g before migrating your database to Oracle ASM.

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) website 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

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:

http://www.oracle.com/technetwork/database/features/availability/maa-096107.html