4 Administering Storage

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 is the instance that performs the recovery and verifies access to the file. As other instances start, 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 to 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 run the ALTER SYSTEM CHECK DATAFILES statement on each instance to verify datafile access.

Redo Log File Storage in Real Application Clusters

Each instance has its own online redo log groups which are referred to as 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 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 throughout the cluster environment 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.

Automatic Storage Management Components in RAC

When you create your database, Oracle creates one ASM instance on each node in your RAC environment if one does not already exist. 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 for nondefault Oracle Net Listeners.

Modifying Disk Group Configurations for ASM in RAC

When you create a disk group for a cluster or add new disks to an existing clustered disk group, you only need to prepare the underlying physical storage on shared disks. The shared disk requirement is the only substantial difference between using ASM in a RAC database compared to using it in a single-instance Oracle database. ASM automatically re-balances the storage load after you add or delete a disk or disk group.

In a cluster, each ASM instance manages its node's metadata updates to the disk groups. In addition, each ASM instance coordinates disk group metadata with other nodes in the cluster. As in single-instance Oracle databases, you can use Enterprise Manager, DBCA, SQL*Plus, and the Server Control Utility (SRVCTL) to administer disk groups for ASM in RAC. The Oracle Database Administrator's Guide explains how to use SQL*Plus to administer ASM instances. The following sections describe how to use the other tools.

Standalone ASM Disk Group Management

When you create a database using DBCA and you select the ASM storage option, DBCA creates the ASM instances for you if they do not already exist. However, you can also use the standalone ASM disk group management feature to create and manage an ASM instance and its associated disk groups independently of creating a new database. You can use Enterprise Manager or DBCA to add disks to a disk group, to mount a disk group or to mount all of the disk groups, or to create ASM instances. Additionally, you can use Enterprise Manager to dismount and drop disk groups or to delete ASM instances.

To create an ASM instance without creating a database with DBCA, select the Configure Automatic Storage Management option on the DBCA Database Options page. You can also use this option to add or mount one or more ASM disk groups. The DBCA then displays the Node Selection page on which you can identify the nodes on which you want to create the ASM instance or on which you want to manage disk groups. If necessary, the next page you must complete is the DCBA Create Instance Page on which you add the information about the ASM instance parameter file and SYS password and, for Windows-based systems, the owner of the ASM-related service.

The DBCA session provides the same ASM Disk Groups page for standalone ASM management as it does for database creation using ASM storage. Use this page to create new disk groups, to add disks to existing disk groups, or to mount disk groups that are not currently mounted. You can also use the standalone ASM feature, where you have the ability to manage ASM instances independent of the database, in DBCA silent mode to create an ASM instance or to manage ASM disk groups. The syntax for the DBCA silent mode command is:

dbca -silent -nodeList nodelist -configureASM -asmPassword asm_pwd [-diskList disk_list] [-redundancy redundancy_option] [-diskGroupName dgname]  [-diskString disk_discovery_string] [-recoveryGroupName recovery_dgname] [-recoveryRedundancy redundancy_option]

Where:

• nodelist is a comma-delimited list of nodes and these are the nodes on which you want to perform the ASM activities

• asm_pwd is the password for the SYS account in the ASM instance

• disk_list is a comma-delimited list of disks to be added to disk group

• redundancy_option is NORMAL, HIGH, or EXTERNAL

• dgname is either the name of an existing disk group, in which case the disk group is mounted on all of the selected nodes, or dgname is the name of a new disk group, in which case the disk group is created and started on all of the selected nodes

• disk_recovery_string identifies the location or identifier for the ASM-ready disks

• recovery_dgname is the name for a recovery disk group

Administering ASM Instances and Disk Groups with Enterprise Manager in RAC

You can perform administrative operations on ASM disk groups with Enterprise Manager such as adding and deleting them. You can also monitor ASM disk group performance as well as control disk group availability at the instance level. For example, some of the RAC-specific ASM-related Enterprise Manager tasks that you can perform 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.

• The default Disk Group Performance page displays instance-level performance details when you click 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 should mount or dismount a particular 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] [-c <connect_str> | -q]

Use the following syntax to stop an ASM instance:

srvctl stop asm -n node_name [-i asm_instance_name] [-o stop_options] [-c <connect_str> | -q]

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