3 Administering Storage

Automatic Storage Management

ASM automatically optimizes storage to maximize performance by rebalancing the storage configuration across the disks that ASM manages. ASM spreads the storage load across all available storage within your cluster database environment for optimal performance. ASM partitions your total disk space into uniformly sized units across all disks in a disk group. ASM can also automatically mirror data to prevent data loss.

To use ASM in RAC, you only need to select ASM as your storage option when you create your database with the Database Configuration Assistant (DBCA). When your database is operating, storage management only requires you to administer disk groups as described in this section. As in single-instance Oracle databases, using ASM in RAC does not require I/O tuning.

Automatic Storage Management Components in RAC

When you use ASM, there is an ASM instance on each node of a RAC database. Each ASM instance has either an SPFILE or PFILE type parameter file. You may need to back up the parameter files and the TNS entries if you are using a nondefault Oracle Net Listener.

Modifying Disk Group Configurations for ASM in RAC

When you add disk groups in RAC, you only need to prepare the underlying operating system. ASM automatically rebalances the storage load after you add a disk group or when you delete a disk group.

When you add disk groups, you can also set a redundancy level and identify failure groups which are sets of disks that share a common resource. ASM uses failure groups to store redundant copies of your data to ensure that the loss of one failure group does not result in data loss. The default redundancy level is normal, which mirrors to two failure groups. You can also specify high redundancy for three-way mirroring. You can only use failure groups if you enable mirroring.

In RAC, each ASM instance manages all disk and failure groups for each node. In addition, each ASM instance coordinates disk and failure group information with other nodes in a RAC cluster database. As in single-instance Oracle databases, you can use the DBCA, SQL*Plus, and the Server Control Utility (SRVCTL) to administer disk groups for ASM in RAC as described in the following sections.

Administering ASM Instances and ASM Disk Groups with Enterprise Manager in RAC

You can add or administer Automatic Storage Management (ASM) disk groups with Enterprise Manager. You can also monitor ASM disk group performance and control disk group availability at the instance level. For example, the additional ASM-related Enterprise Manager tasks that you can perform in RAC are:

• When you add a disk group, the disk group definition includes a checkbox to indicate whether the disk group is automatically mounted to all of the cluster database instances.

• When you examine the default Disk Group Performance page, you can see an instance-level performance details by clicking a performance characteristic such as Write Response Time or I/O Throughput.

• When you mount and dismount ASM disk groups, you can use a checkbox to indicate which instances mount or dismount the ASM Disk Group.

Administering ASM Instances with SRVCTL in RAC

You can use the Server Control Utility (SRVCTL) to add, remove, enable, and disable an ASM instance as described in the following procedures:

Use the following syntax to add configuration information about an existing ASM instance:

srvctl add asm -n node_name -i asm_instance_name -o oracle_home

Use the following syntax to remove an ASM instance:

srvctl remove asm -n node_name [-i asm_instance_name]

Use the following syntax to enable an ASM instance:

srvctl enable asm -n node_name [-i ] asm_instance_name

Use the following syntax to disable an ASM instance:

srvctl disable asm -n node_name [-i asm_instance_name]

You can also use SRVCTL to start, stop, and obtain the status of an ASM instance as in the following examples.

Use the following syntax to start an ASM instance:

srvctl start asm -n node_name [-i asm_instance_name] [-o start_options]

Use the following syntax to stop an ASM instance:

srvctl stop asm -n node_name [-i asm_instance_name] [-o stop_options]

Use the following syntax to show the configuration of an ASM instance:

srvctl config asm -n node_name 

Use the following syntax to obtain the status of an ASM instance:

srvctl status asm -n node_name

Datafile Access in Real Application Clusters

All RAC instances must be able to access all datafiles. If a datafile needs to be recovered when the database is opened, then the first RAC instance to start performs the recovery and verifies access to the file. As other instances start up, they also verify their access to the datafiles. Similarly, when you add a tablespace or datafile or bring a tablespace or datafile online, all instances verify access to the file or files.

If you add a datafile onto a disk that other instances cannot access, then verification fails. Verification also fails if instances access different copies of the same datafile. If verification fails for any instance, then diagnose and fix the problem. Then execute the ALTER SYSTEM CHECK DATAFILES statement on each instance in your RAC database to verify datafile access.

Redo Log File Storage in Real Application Clusters

Each instance has its own online redo log groups which are called an instance's thread of online redo. Create these online redo log groups and establish group members as described in the Oracle Database Administrator's Guide.

Each instance must have at least two groups of online redo log files in its own thread. When the current group fills, an instance begins writing to the next log file group. If your database is in ARCHIVELOG mode, then each instance must save filled log files into its own archive log thread and update the control file with the status of its thread.

Automatic Undo Management in Real Application Clusters

Oracle automatically manages undo segments within a specific undo tablespace that is assigned to an instance. Only the instance assigned to the undo tablespace can modify the contents of that tablespace. However, all instances can always read all undo blocks for consistent read purposes. Also, any instance can update any undo tablespace during transaction recovery, as long as that undo tablespace is not currently used by another instance for undo generation or transaction recovery. You assign undo tablespaces in your RAC database by specifying a different value for the UNDO_TABLESPACE parameter for each instance in your SPFILE or individual PFILEs. You cannot simultaneously use automatic undo management and manual undo management in a RAC database. In other words, all instances of a RAC database must operate in the same undo mode.

Switching Undo Tablespaces for Instances in Real Application Clusters

You can dynamically switch undo tablespace assignments. Redirect the assignment for an instance by executing the ALTER SYSTEM SET UNDO_TABLESPACE statement. You might do this during planned maintenance to redirect an instance to use an idle undo tablespace. For example, assume that you have specified instances db1 and db2 to access undo tablespaces undotbs01 and undotbs02 respectively, and that you have an idle undo tablespace undotbs03. To redirect instance db1 to use undo tablespace undotbs03, execute the following SQL statement from instance db1:

ALTER SYSTEM SET UNDO_TABLESPACE = undotbs3 SID=1;

In this example, the previously used undo tablespace undotbs01 remains assigned to instance db1 until the instance's last active transaction commits. User transactions proceed while Oracle performs the switching operation as follows:

• The switching process does not wait for all user transactions to commit.

• Oracle places the previous undo tablespace in a pending-offline state if there are active transactions in that tablespace. This means that the pending-offline tablespace may be unavailable for other instances until all transactions against that tablespace are committed.

Refer to the Oracle Database Administrator's Guide for more information about the ALTER SYSTEM SET UNDO_TABLESPACE statement and information about setting the undo retention period and dropping undo tablespaces.

Administering the Oracle Cluster Registry in Real Application Clusters

This section describes how to administer the Oracle Cluster Registry (OCR). The OCR contains cluster and database configuration information for RAC and Cluster Ready Services (CRS). Some of this information includes the cluster node list, cluster database instance-to-node mapping information, and the CRS application resource profiles.

There are two methods of copying OCR content and to use the content for recovery. The first method uses automatically generated physical OCR file copies and the second method uses manually created logical OCR export files as described in the following sections:

• Administering Oracle Cluster Registry Backup Files in Real Application Clusters

• Restoring the Oracle Cluster Registry from Automatically Generated OCR Backups

• Restoring the Oracle Cluster Registry on UNIX-Based Systems

• Restoring the Oracle Cluster Registry on Windows-Based Systems

• Moving the Oracle Cluster Registry on UNIX-Based Systems

• Moving the Oracle Cluster Registry on Windows-Based Systems

CRS Home/cdata/cluster name

You can change this location using the following syntax:

ocrconfig -backuploc directory name

Administering the Oracle Cluster Registry with OCR Exports

In addition to using the automatically created OCR backup files, you should also export the OCR contents before and after making significant configuration changes. Do this by using the ocrconfig -export command. This enables you to restore the OCR if your configuration changes cause errors. For example, if you have unresolvable configuration problems, or if you are unable to restart your clusterware, restore your configuration using one of the following platform-specific procedures:

• Importing Oracle Cluster Registry Content on UNIX-Based Systems

• Importing Oracle Cluster Registry Content on Windows-Based Systems

  
  

  Note: You cannot import an exported OCR backup file using the -restore option. You must instead use the -import option.

The ocrconfig Tool Command Syntax and Options

Execute OCR commands with administrative privileges on UNIX-based platforms or as a user with Administrator privileges on Windows-based systems. The OCR command syntax is as follows where options is one of the verbs shown in the Option column of Table 3-1:

ocrconfig -option

For example, to export the OCR contents to a binary file, use the ocrconfig command with the following syntax where file_name is the file to which you want to export the OCR contents as follows:

ocrconfig -export file_name

Do not attempt to edit the export file. If OCR clients such as the clusterware are running, then Oracle reports an error.

Implementing the Oracle Hardware Assisted Resilient Data Initiative for the OCR

The Oracle Hardware Assisted Resilient Data (HARD) initiative prevents data corruptions before they occur. With HARD enabled, the OCR writes HARD-compatible blocks. To determine whether the device used by the OCR supports HARD and enable it, review the Oracle HARD white paper at:

http://otn.oracle.com/deploy/availability/htdocs/HARD.html

Upgrading and Downgrading the OCR Configuration in Real Application Clusters

When you install CRS, Oracle automatically executes the ocrconfig -upgrade command. To downgrade, follow the downgrade instructions for each component and also downgrade the OCR using the ocrconfig -downgrade command.