4 Administering Database Instances and Cluster Databases

Parameters that Must Have Identical Settings on All Instances

Certain initialization parameters that are critical at database creation or that affect certain database operations must have the same value for every instance in an Oracle RAC database. Specify these parameter values in the SPFILE, or within the individual PFILEs for each instance. The following list contains the parameters that must be identical on every instance:

• ACTIVE_INSTANCE_COUNT

• ARCHIVE_LAG_TARGET

• CLUSTER_DATABASE

• CLUSTER_DATABASE_INSTANCES

• COMPATIBLE

• CONTROL_FILES

• DB_BLOCK_SIZE

• DB_DOMAIN

• DB_FILES

• DB_NAME

• DB_RECOVERY_FILE_DEST

• DB_RECOVERY_FILE_DEST_SIZE

• DB_UNIQUE_NAME

• INSTANCE_TYPE (RDBMS or ASM)

• PARALLEL_MAX_SERVERS

• REMOTE_LOGIN_PASSWORD_FILE

• UNDO_MANAGEMENT

The setting for DML_LOCKS must be identical on every instance only if set to zero.

Parameters that Must Have Unique Settings on All Instances

Oracle RAC uses the INSTANCE_NUMBER parameter to distinguish among instances at startup. Oracle RAC uses the number value of the THREAD parameter to assign redo log groups to specific instances. To simplify administration, use the same number for both the THREAD and INSTANCE_NUMBER parameters for each instance.

If you use the ROLLBACK_SEGMENTS parameter to specify the names of the rollback segments to be used for storing the undo of each instance, then Oracle recommends you use the instance SID as part of each unique rollback segment name. If the parameter UNDO_MANAGEMENT is set to AUTO, automatic undo management mode is used by the Oracle RAC database, and the setting of ROLLBACK_SEGMENTS is ignored. When using automatic undo management, Oracle Database generates unique names for the undo segments used by each instance.

If you use automatic undo management in your Oracle RAC database, then set the UNDO_TABLESPACE parameter to a different undo tablespace for each instance.

Parameters that Should Have Identical Settings on All Instances

Oracle recommends that you set the values for the following parameters to the same value on all instances. Although you can have different settings for these parameters on different instances, setting each parameter to the same value on all instances simplifies administration:

• ARCHIVE_LAG_TARGET

  Different values for instances in your Oracle RAC database are likely to increase overhead because of additional automatic synchronization performed by the database processing.

  When using Oracle Streams with your Oracle RAC database, the value should be greater than zero.

• LICENSE_MAX_USERS

  This parameter determines a databasewide limit on the number of users defined in the database and it is useful to have the same value on all instances of your database so you can see the current value no matter which instance you are using. Setting different values may cause additional warning messages to be generated during instance startup or cause commands related to database user management to fail on some instances.

• LOG_ARCHIVE_FORMAT

  If you do not use the same value for all your instances, then you unnecessarily complicate media recovery. The recovering instance expects the required archive log file names to have the format defined by its own value of LOG_ARCHIVE_FORMAT, regardless of which instance created the archive log files.

  Databases that support Oracle Data Guard, either to send or receive archive log files, must use the same value of LOG_ARCHIVE_FORMAT for all instances.

• SPFILE

  If this parameter does not identify the same file to all instances, then each instance may act differently and unpredictably in failover, load-balancing, or standard operations. Additionally, a change you make to the SPFILE with an ALTER SYSTEM SET or ALTER SYSTEM RESET command is saved only in the SPFILE used by the instance where you run the command. Your change will not be reflected in instances using different SPFILEs.

  If the SPFILE values are different in instances for which the values were set by the server, then you should restart the instances that are not using the default SPFILE.

• UNDO_RETENTION

  By setting different values for UNDO_RETENTION in each instance, you are likely to reduce scalability and encounter unpredictable actions following a failover. Therefore, you should carefully consider whether or not you will accrue any benefits before you assign different values for this parameter to the instances in your Oracle RAC database.

Modifying Initialization Parameter for Oracle RAC Using the Current Tab

Click the Current tab of the Initialization Parameters page in Enterprise Manager to manage the initialization parameter settings for your cluster database. The initialization parameters file contains a list of configuration parameters for that instance and database. You can set these parameters to particular values to initialize many of the memory and process settings of an Oracle instance.

You can filter the Initialization Parameters page to show only those parameters that meet the criteria of the filter you enter in the Filter by name field. Optionally, you can select Show All to display on one page all parameters currently used by the running instance(s).

The Instance column shows the instances for which the parameter has the value listed in the table. An asterisk (*) indicates that the parameter has the same value for all remaining instances of the cluster database. For example, if open_cursors = 200 for docrac1 and docrac2, and open_cursors = 275 for docrac3, then the Instance column for open_cursors = 200 displays an asterisk, while displaying "docrac3" for open_cursors = 275. This shorthand saves space for cluster databases with many instances.

To modify the parameter values, select a parameter from the Select column and do one of the following:

• Click Add to add the selected parameter to a different instance. Enter a new instance name and value in the newly created row in the table.

• Click Reset to reset the value of the selected parameter. Note that you may only reset only parameters that do not have an asterisk in the Instance column. The value of the selected column is reset to the value of the remaining instances (that is, the row with the asterisk).

After you make changes to one or more of the parameters, click Apply to accept and invoke the changes.

Modifying Initialization Parameter for Oracle RAC Using the SPFile Tab

From the Initialization Parameters page for cluster databases, select the SPFile tab to display and change the parameters for the current server parameter file. A server parameter file is a type of repository for initialization parameters that is maintained on the server where the Oracle database server runs. It is a server-side initialization parameter file. Initialization parameters stored in a server parameter file are persistent, in that any changes made to the parameters while an instance is running can persist across instance shutdown and startup. Click Apply changes in SPFile mode... to apply the changes to the running instance.

Select Running to show the parameters for the current running instance of the initialization parameters file. For more information about each parameter, click the parameter name in the Name column.

Similar to the Current tab, you can Add or Reset parameters. Note that resetting parameters in the SPFile tab is different than resetting them in the Current tab: Reset deletes the selected parameter entry from the SPFILE and applies to both asterisk and non-asterisk parameters. If you reset a parameter with an asterisk in the Instance column, the entry will be deleted from both the SPFILE and the table. Only parameters for non-asterisk instances will remain. If you reset the remaining entry for a parameter, it will be deleted from both the SPFILE and the table, but will be replaced by a dummy parameter with an empty value field and an asterisk in the Instance column; this enables you to specify a new value, add new entries, and so on.

Resetting a parameter with only one instance resets the value of that parameter.

Example: Modifying the OPEN_CURSORS Parameter

Suppose that the open_cursors parameter has two entries in the SPFILE:

*.open_cursors = 200 
docrac1.open_cursors = 250

If you click Reset for *.open_cursors, then Enterprise Manager deletes that entry from both the SPFILE and the displayed list of parameters, leaving only docrac1.open_cursors = 250 displayed. If you click Reset for docrac1.open_cursors, Enterprise Manager also deletes this parameter entry from both the SPFILE and the displayed list of parameters, but then a new entry, *.open_cursors = <EMPTY> is added to the displayed list of parameters in place of the reset parameter.

Modifying the SERVICE_NAMES Parameter for Oracle RAC

The SERVICE_NAMES initialization parameter specifies one or more names by which clients can connect to the instance. The instance registers its service names with the Listener. When a client requests a service, the Listener determines which instances offer the requested service and routes the client to the appropriate instance.

In an Oracle RAC database, you should not modify this parameter directly. Instead, define services for your database and database instances using the Clustered Managed Database Services page in Enterprise Manager. If you need to change a service, you can use either Enterprise Manager or SRVCTL.

About Automatic Storage Management Components in Oracle RAC

When you create your database, Oracle Database creates one ASM instance on each node in your Oracle RAC environment if one does not already exist. Each ASM instance has either an SPFILE or PFILE type parameter file. For the environment described in this guide, the ASM instances use PFILEs.

Modifying Disk Group Configurations for ASM in Oracle RAC

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

In a cluster, each ASM instance manages the metadata updates to the disk groups for the node on which it is running. 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 SRVCTL to administer disk groups for ASM in an Oracle RAC environment.

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.

Administering ASM Instances and Disk Groups with Enterprise Manager

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 Oracle RAC-specific features for ASM that are provided by Enterprise Manager are:

• When you add a disk group, the disk group definition includes a check box to indicate whether or not the disk group is automatically mounted to all 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 check box to indicate which instances should mount or dismount a particular ASM Disk Group.

About Redo Log Groups and Redo Threads in Oracle RAC Databases

Redo logs contain a record of changes that have been made to datafiles. In a single-instance Oracle database, redo logs are stored in two or more redo log file groups. Each of these groups contains a redo log file and possibly one or more mirrored copies of that file. In an Oracle RAC database, each instance requires its own set of redo log groups, which is known as a redo thread. Mirrored copies of the redo log files provide your system with extra protection against data loss that is due to hardware failures or data corruption. If a redo log file is unreadable, then the Oracle Database attempts to access its mirrored copy. You should place the redo log file mirrors on different disk devices from the primary redo log files.

Each instance's redo thread must contain at least two redo log groups. Oracle recommends that each of your instances has a redo thread that contains the same number of redo log groups and, as with single-instance Oracle databases, each group should contain the same number of members. For example, in an Oracle RAC database with two instances, each instance could have a redo thread that contains five redo log groups. This is a total of 10 redo log groups for the database. Each of these redo log groups could contain two members: a redo log and its mirrored copy. If you create your Oracle RAC database with DBCA, then your Oracle RAC database automatically implements a configuration that meets the Oracle recommendations.

In an Oracle RAC database, each instance writes and archives the redo log groups in its redo thread in the same manner that single-instance Oracle databases do. However, in recovery mode, the instance performing the recovery is able to read and process all the redo threads for the database, regardless of which instance generated the redo thread. This enables a running instance to recover the work completed by one or more failed instances. This also enables users to continue their work without waiting for the failed instance to be restarted. For example, assume that you have an Oracle RAC database with two instances, instance A and instance B. If instance A is down, then instance B can read the redo log files for both instance A and B to ensure a successful recovery.

In an Oracle RAC database, all the redo log files reside on shared storage. In addition, each instance must have access to the redo log files of all the other instances in the cluster. If your Oracle RAC database uses ASM, then ASM manages the shared storage for the redo log files and the access to those files.

Using Enterprise Manager to View and Create Online Redo Log Files

To access the redo log file groups with Enterprise Manager:

1. Go to the Cluster Database Home Page, and click the Administration tab.

2. On the Cluster Database Administration page, under the Storage column, select Redo Log Groups.

On the Redo Log Groups page, you can create additional redo log groups and add members to the redo log group. The Thread column identifies the instance, or redo thread, to which a redo log file belongs.