8 Administrative Options

Databases Summary Page

This is a top-level page that shows cluster and single-instance databases. If there are cluster databases in your environment, the Databases Summary page displays "Cluster Database" in the Type column. The page also indicates cluster database availability as well as the ratio of active instances to inactive instances. Click a cluster database link and Enterprise Manager displays the Cluster Database Home Page for that database, which is described under the following heading.

Cluster Database Home Page

From the Cluster Database Home Page you can manage the cluster nodes and hosts as well as cluster subcomponents such as instances and listeners. The Cluster Database Home Page is also a summary page for cluster database management that provides an overview of cluster database activity. Enterprise Manager uses a unique database name to identify the cluster database it represents. You can use the Administration tab on this page to perform many activities such as:

• Create undo tablespaces and redo threads and assign them to specific instances, SPFILE, create a backup

• Start, stop, and relocate database services at the cluster database level

You can use the Maintenance tab on this page to perform operations such as:

• Create backup and recovery scenarios

• Toggle the archive mode on and off

• Administer recovery settings

• Manage resource plans for the database and its instances

Cluster Database Instances Pages

Instances pages show instance-specific information similar to the information that you would see on a single-instance Oracle database.

The Databases Overview Page for Real Application Clusters

The Databases Overview Page links to Cluster Home Pages and to the node or instance Home Pages.

The Cluster Home Page for Real Application Clusters

The Cluster Home Page displays an overview of activities and detailed reports at both the cluster and instance levels. The Cluster Home Page has the following sections:

• General Section—Provides a cluster status overview.

• Configuration Section—Lists the hardware platform, operating system and version, and Oracle or vendor clusterware version.

• Cluster Databases Table—Displays the cluster databases associated with a cluster, their availability, and any cluster database alerts. You can access the individual Cluster Database Home Pages from the Cluster Databases Table.

• Alerts Table—Provides alert information such as severity rating.

• Hosts Table—Displays information about the hosts or nodes in the cluster.

Administering Enterprise Manager Jobs in Real Application Clusters

You can administer Enterprise Manager jobs at both the database and instance levels. For example, you can create a job at the cluster database level and the job will run on any active instance of the target RAC database. Or you can create a job at the instance level and the job will only run on the specific instance for which you created it. In the event of a failure, recurring jobs can run on a surviving instance.

Administering Alerts in Real Application Clusters with Enterprise Manager

You can use Enterprise Manager to configure RAC environment alerts. You can also configure special RAC database tests, such as global cache converts, consistent read requests, and so on.

Enterprise Manager distinguishes between database- and instance-level alerts in RAC environments. Alert thresholds for instance level alerts, such as archive log alerts, can be set at the instance target level. This enables you to receive alerts for the specific instance if performance exceeds your threshold. You can also configure alerts at the database level, such as setting alerts for tablespaces. This enables you to avoid receiving duplicate alerts at each instance.

Performing Scheduled Maintenance Using Defined Blackouts in Enterprise Manager

You can define blackouts for all managed targets of a RAC database to prevent alerts from occurring while performing maintenance. You can define blackouts for an entire cluster database or for specific cluster database instances.

How SQL*Plus Commands Affect Instances

Most SQL statements affect the current instance. You can use SQL*Plus to start and stop instances in the RAC database. You do not need to run SQL*Plus commands as root on UNIX-based systems or as Administrator on Windows-based systems. You need only the proper database account with the privileges that you normally use for a single-instance Oracle database. Some examples of how SQL*Plus commands affect instances are:

• The statement ALTER SYSTEM SET CHECKPOINT LOCAL only affects the instance to which you are currently connected, rather than the default instance or all instances.

• ALTER SYSTEM CHECKPOINT LOCAL affects the current instance.

• ALTER SYSTEM CHECKPOINT or ALTER SYSTEM CHECKPOINT GLOBAL affects all instances in the cluster database.

• ALTER SYSTEM SWITCH LOGFILE affects only the current instance.

  • To force a global log switch, use the ALTER SYSTEM ARCHIVE LOG CURRENT statement.

  • The INSTANCE option of ALTER SYSTEM ARCHIVE LOG enables you to archive each online redo log file for a specific instance.

Table 8-1 describes how SQL*Plus commands affect instances.

Verifying that Instances are Running

To verify that instances are running, on any node from a SQL*Plus prompt enter:

CONNECT SYS/password as SYSDBA
SELECT * FROM V$ACTIVE_INSTANCES;

Oracle returns output similar to the following:

INST_NUMBER INST_NAME          
-----------  ----------------- 
           1 db1-sun:db1  
           2 db2-sun:db2  
           3 db3-sun:db3  

The output columns for this example are shown in Table 8-2.

Quiesced State and Cold Backups

You cannot use the quiesced state to take a cold backup. This is because Oracle background processes may still perform updates for Oracle internal purposes even while the database is in quiesced state. In addition, the file headers of online datafiles continue to look like they are being accessed. They do not look the same as if a clean shutdown were done. You can still take online backups while the database is in a quiesced state. Refer to the Oracle Database Administrator's Guide for details on the quiesce database feature and the Oracle Database Reference for more information about the ALTER SYSTEM QUIESCE RESTRICTED syntax.

Defining Network Interfaces with OIFCFG

The specification for a network interface uniquely identifies it using the interface name, its associated subnet, and interface type. The interface type indicates the purpose for which the network is configured. The supported interface types are:

• Public—An interface that can be used for communication with components external to RAC instances, such as Oracle Net and Virtual Internet Protocol (VIP) addresses

• Cluster interconnect—A private interface used for the cluster interconnect to provide inter-instance or Cache Fusion communication

• Storage—A disk interface used for high-speed file I/O

A network interface can be stored as a global interface or as a node-specific interface. An interface is stored as a global interface when all the nodes of a RAC cluster have the same interface connected to the same subnet (recommended). It is stored as a node-specific interface only when there are some nodes in the cluster that have a different set of interfaces and subnets. If an interface is configured as both a global and a node-specific interface, the node-specific definition takes precedence over the global definition. A network interface specification is in the form of:

interface_name/subnet:interface_type. 

For example, the following identifies qfe0 as a cluster interconnect located at the address 204.152.65.32:

qfe0/204.152.65.32:cluster_interconnect

Syntax and Commands for the OIFCFG Command-Line Tool

Use the oifcfg -help command to display online help for OIFCFG. The elements of OIFCFG commands, some of which are optional depending on the command, are:

• nodename—Name of the CRS node as listed in the output from the olsnodes command

• if_name—Name by which the interface is configured in the system

• subnet—Subnet address of the interface

• if_type—Type of interface: public or cluster_interconnect

You can use OIFCFG to list the interface names and the subnets of all the interfaces available on the local node by executing the iflist keyword as shown in this example:

oifcfg iflist
hme0     139.185.141.0
qfe0     204.152.65.16

You can also retrieve specific OIFCFG information with a getif command using the following syntax:

oifcfg getif [ [-global | -node nodename] [-if if_name[/subnet]] [-type if_type] ]

To store a new interface use the setif keyword. For example, to store the interface hme0, with the subnet 139.185.141.0, as a global interface (to be used as an interconnect for all the RAC instances in your cluster), you would use the command:

oifcfg setif -global hme0/139.185.141.0:cluster_interconnect

For a cluster interconnect that exists between only two nodes, for example rac1 and rac2, you could create the cms0 interface with the following commands, assuming 139.185.142.1 and 139.185.142.2 are the subnet addresses for the interconnect on rac1 and rac2 respectively:

oifcfg setif -node rac1 cms0/139.185.142.1:cluster_interconnect
oifcfg setif -node rac2 cms0/139.185.142.2:cluster_interconnect

Use the OIFCFG delif command to delete the stored configuration for global or node-specific interfaces. A specific node-specific or global interface can be deleted by supplying the interface name, with an optional subnet, on the command line. Without the -node or -global options, the delif keyword deletes either the given interface or all the global and node-specific interfaces on all the nodes in the cluster. For example, the following command deletes the global interface named qfe0 for the subnet 204.152.65.16:

oifcfg delif -global qfe0/204.152.65.16

On the other hand, the next command deletes all the global interfaces stored with OIFCFG:

oifcfg delif -global