B Overview of Real Application Clusters

Overview of the Cluster Database Home Page

Log in to the RAC database Oracle Enterprise Manager Console from a client browser as described in the section "Starting and Stopping the Oracle Enterprise Manager Console" in Chapter 3, "Getting Started with Oracle Enterprise Manager". When you log in to the Oracle Enterprise Manager Console, Enterprise Manager displays the Cluster Database Home page for the RAC database.

The Cluster Database Home page looks similar to a single-instance Database Control Home Page. However, on the Cluster Database Home page, Oracle Enterprise Manager displays the system state and availability of the entire RAC database. This includes a summary about alerts and job activity as well as links to all of the database and ASM instances.

The Cluster Database Home page shows the status as UP for any database instances that are running. The page shows the statuses for non-running instances as DOWN. You can start the non-running instances or stop the running instances as needed using the Startup and Shutdown buttons respectively that appear in the General section of the page.

Click the Performance tab to see detailed RAC database metrics. If critical or warning alerts appear in the Severity column, then you can analyze them by clicking directly on the alert.

The Alerts table is displayed under the metrics section on the Cluster Database Home Page. The Alerts table lists cluster-wide database alerts in order of severity, sorted by database components. For more information about an alert, click the text in the Message column. This takes you to the specific page that measures the system state of the process that triggered the alert.

On the Cluster Database Home Page level, you can select the Performance, Administration, and Maintenance tabs at the top of the page or you can select the same tabs from just above the Instances table. These three links enable you to perform clusterwide administration tasks. You can obtain help to understand the task options and metric definitions by clicking the Help link next to the Database tab. After you navigate to individual metrics displays, or to return to the Cluster Database Home Page, click the Database tab in the upper right-hand corner of the page.

Viewing Real Application Clusters Database Targets

On the Cluster Database Page, a target can be a cluster, a database instance, or an Oracle utility, such as a listener. The console obtains metrics that provide information about the current states of the targets. The Cluster Database page displays these metrics in separate section headings for each target.

On the Cluster Database Cluster Home page, Oracle Enterprise Manager displays high-level metrics about the state of the cluster. You can navigate to more detailed pages that display metrics about the target that you have selected by clicking the names of individual targets on the page. Links to the database instances and ASM instances appear at the bottom of the Cluster Home page. You can easily view all of the instance targets by clicking these links without navigating to the database and ASM instance detailed home pages.

Navigating to Oracle Enterprise Manager Cluster-Related Pages

You can monitor various activities in your cluster database environment with the other pages in Oracle Enterprise Manager that this section describes. The Cluster Database Performance page, that you access by clicking the Performance tab from the Cluster Database Home page, provides a brief summary of the performance statistics for all of the instances of the database. In other words, statistics are rolled up across all of the instances in a RAC database and shown on the Database Performance page.

Using the links that are next to the charts at the bottom of the page, you can drill down to perform the following tasks:

• Identify and resolve the causes of performance issues

• Decide whether you need to add or re-distribute resources

• Tune your SQL plan and schema for better optimization

For performance information about individual instances, you can use the Cluster Database Instance Performance page. To reach this page for a particular instance, click the Performance tab on the Cluster Database Home page, then click the name of the instance that you want to monitor at the bottom of the page. You can drill down from links beside the charts or at the bottom of the Database Instance Performance page to perform the following tasks:

• Identify and resolve the cause of performance issues

• Decide whether you need to add or re-distribute resources

• Tune your SQL plan and schema for better optimization

Use the Cluster Performance Page to see utilization statistics, such as CPU, Memory, and Disk reads and writes, during the past hour for all of the nodes of your cluster. Access the Cluster Performance page by clicking the Cluster link in the General section of the Cluster Database Performance page, then click the Performance tab from the Cluster Home page. With these statistics, you can determine whether resources need to be added, suspended, or re-distributed. From this page, you can view the CPU, Memory, and Disk I/O charts for each node individually by clicking the host name in the legend to the right of the charts. The resulting Host page also shows statistics for CPU load, memory scan page rate, and longest service time.

The Cluster Interconnects page enables you to monitor interconnects and to identify configuration and transfer rate-related issues, including excess traffic. Use the information on the Cluster Interconnects page to determine how the instances and databases affect the interconnect load. Sometimes you can immediately identify interconnect delays that are due to applications that are outside of the Oracle database. To access the Cluster Interconnects page, click the Cluster link in the General section of the Cluster Database Home page, then click the Interconnects tab. The tables on the Interconnects page enable you to do the following:

• View all interfaces that are configured across the cluster

• View statistics for the interfaces, such as absolute transfer rates and errors

• Determine the type of interfaces, such as private or public

• Determine whether the instance is using a public or private network

• Determine which database instance is currently using which interface

• Determine how much the instance is contributing to the transfer rate on the interface

Viewing and Modifying Real Application Clusters Initialization Parameters

Managing initialization parameters across an Oracle RAC database is essentially the same as managing them for a single-instance Oracle database. Note the following differences for parameters in RAC databases:

• Parameters that are cluster-specific are identified in the Category column with the designation Cluster Database

• Parameters that are duplicated on each instance in the RAC database are identified in the Instance column with an asterisk (*)

• Parameters that you can set differently on each instance of a RAC database are listed by instance number

The administration of initialization parameters in RAC environments is slightly different from single-instance database parameter administration. For example, if you change a parameter setting that is marked by an asterisk, which indicates that the parameter is a cluster-wide database initialization parameter, then you change that parameter's setting for all of the instances in your RAC database. If you change a numbered initialization parameter, which indicates an instance-specific initialization parameter, then the change only affects the instance that corresponds to the number; the change does not affect the parameter's settings on other database instances.

Starting and Stopping Real Application Clusters Databases

The following procedures describe how to start and stop an entire RAC database, as well as each cluster database instance:

1. Log in to Oracle Enterprise Manager Database Control.

2. On the Cluster Database Home page in the General view, click Startup if the database is down, or Shutdown if the database is up.

3. On the Startup/Shutdown: Specify Credentials page, enter the cluster database host credentials for the database nodes. The host credentials are the user name and password for a user who is a member of the OSDBA or OSOPER system privileges group.

4. On the Startup/Shutdown: Select Operation page, click Startup All to start all of the instances, or click Shutdown All to stop all of the instances.

5. On the Startup/Shutdown: Confirmation page, click Yes.

Starting and Stopping Individual Instances in Real Application Clusters Databases

To start and stop individual instances, navigate to the RAC Database Startup and Shutdown page and select the instance that you want to start or stop. Then start or stop the instance as needed.

Redo Log Groups and Redo Threads in Real Application Cluster Databases

Redo logs contain a record of changes that have been made to datafiles. In a single-instance Oracle database environment, redo logs generated by database datafile changes 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 a RAC database, each instance requires its own set of redo log groups, which is known as its thread of redo. 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.

Each redo log 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 a RAC database with two instances, each instance could have a thread of redo that contains five redo log groups. This is a total of ten redo log groups for the database. Each of these groups could contain two members: a redo log and its mirrored copy. If you create your RAC database with the Database Configuration Assistant (DBCA), then your RAC database automatically implements a configuration that meets the Oracle recommendations.

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

In a RAC database that uses ASM, all of the redo log files reside on shared storage. In addition, each instance has transparent access to the redo log files of all of the other instances in the cluster.

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 thread to which a redo log file belongs.

Backing Up Real Application Clusters Databases

When you use ASM to manage database files, Oracle recommends that you use RMAN for backup. You must have both database (SYSDBA) credentials and host operating system (OSDBA) credentials to perform backup and recovery.

In addition, if you log in to Enterprise Manager with SYSDBA privileges, any valid host operating system user who has execute permission for the RMAN command line client can perform backups. However, if you log in as a non-SYSDBA user, then you must provide an operating system user name that is a member of the OSDBA group.

To back up a RAC database:

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

2. On the Cluster Database Maintenance page, under the Backup/Recovery column, select Schedule Backup.

3. Follow the backup procedures outlined in Chapter 9, "Performing Backup and Recovery".

Overview of Restore and Recovery Operations for a Real Application Clusters Database

This section discusses both instance recovery and media recovery. Instance recovery in RAC is automatic. Instance recovery can occur while a database is running. If a RAC instance fails, then a surviving database instance processes the online redo logs generated by the failed instance to ensure that the database contents are in a consistent state. The more nodes that are in a RAC environment, the shorter the duration of the automatic instance recovery. When recovery completes, the Oracle Clusterware attempts to restart the failed instance automatically.

Media recovery is a manual process that occurs while a database is closed, typically to recover and restore database files after catastrophic disk failures, block corruption, or user errors. Media recovery is always done by one instance in the cluster.

With RMAN, the process of recovering and restoring a RAC database is essentially the same as for a single-instance Oracle databases, except that you access RMAN from the Maintenance page at the cluster database level, instead of at the instance level.

To recover a RAC database:

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

2. On the Cluster Database Maintenance page, under the Backup/Recovery column, select Perform Recovery.

3. Follow the recovery procedures outlined in "Performing Restore and Recovery Operations" in Chapter 9, "Performing Backup and Recovery".

Using a Flash Recovery Area with a Real Application Clusters Database

To use a flash recovery area with a RAC database, the recovery area must be shared by all of the instances. To accomplish this, Oracle recommends that you place the flash recovery area on the shared ASM disks. In addition, you must set the DB_RECOVERY_FILE_DEST and DB_RECOVERY_FILE_DEST_SIZE parameters to the same values on all instances.

To use Flash Recovery, you must first configure the flash recovery area, as described in "Configuring the Flash Recovery Area" in Chapter 9, "Performing Backup and Recovery".