This appendix provides an overview of Oracle Real Application Clusters (RAC). This chapter contains the following topics:
Real Application Clusters (RAC) is a technology that links one or more individual computers so that they function as one system. RAC enables each computer, or node, that is a member of a cluster database to share access to the Oracle database. If one cluster node fails or is taken offline, then the other cluster nodes continue operating and the entire RAC database remains available. This means that two or more inexpensive computers appear to applications as if they were a much more powerful, and more expensive, computer.
To increase the performance of a two-node RAC database, you can add cluster nodes. Each additional node can help speed up application processing, support more users or processes, or both. In addition, you can also add cluster nodes to increase the availability and reliability of a two-node RAC database. The more nodes that your RAC environment has, the less the effect that the loss of any individual node has on the database.
Note:You can include up to four single-processor nodes or two dual-processor nodes in an Oracle Database Standard Edition installation with RAC. You must upgrade to the Oracle Database Enterprise Edition to add additional nodes.
A RAC database requires three components: cluster nodes, shared storage, and Oracle Clusterware. Although you can choose how many nodes your cluster should have and what type of shared storage to use, this appendix is based on one specific configuration, which is the recommended configuration for two-computer, or two-node, clusters. This recommended two-node configuration uses Automatic Storage Management (ASM) for storage and Recovery Manager (RMAN) for the backup and recovery strategy. In addition, the instructions for the Enterprise Edition interface tasks use the Enterprise Manager Database Control console. This appendix does not provide cluster database installation and configuration procedures.
See Also:The Oracle Real Application Clusters installation guide for your operating system and the Oracle Database Oracle Clusterware and Oracle Real Application Clusters Administration and Deployment Guide
Most administration tasks are the same for Oracle single-instance and RAC databases. This appendix provides additional instructions for some of the RAC-specific database administration tasks, as well as some recommendations for managing RAC databases.
This section describes how Oracle Enterprise Manager Console enables you to monitor your RAC database at the cluster level, for a high-level view of activity, and at the instance level, where tuning is similar to single-instance database tuning. This section contains the following topics:
See Also:Oracle Database Oracle Clusterware and Oracle Real Application Clusters Administration and Deployment Guide for more detailed information about RAC database management and administration with Enterprise Manager
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.
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.
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
Note:You can drilldown to problematic instances by way of the roll up pages. This enables you to directly access instances to perform tuning or diagnostics without navigating through individual instance performance pages.
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
See Also:Oracle Database Oracle Clusterware and Oracle Real Application Clusters Administration and Deployment Guide for details about the use and interpretation of the Oracle Enterprise Manager pages discussed in this section
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.
See Also:Oracle Database Oracle Clusterware and Oracle Real Application Clusters Administration and Deployment Guide for more information about initialization parameters in RAC environments
To start or stop RAC databases using Enterprise Manager, you must first ensure that the Enterprise Manager console is up. If you are not sure how to access the console, then review the section "Starting and Stopping the Oracle Enterprise Manager Console" in Chapter 3, "Getting Started with Oracle Enterprise Manager".
Typically, you start up and shut down the cluster from the Enterprise Manager Cluster Database Home page. By using this page for cluster database startup and shutdown operations, you ensure that all of the instances that belong to the RAC database are in a consistent state. This enables you to more easily manage a RAC database. You can also start and stop individual instances in a RAC database. However, starting and stopping one instance in a RAC database does not stop or start other instances. To completely stop a RAC database, you must shut down all of its instances.
Use Oracle Enterprise Manager to start and stop the entire RAC database, or to start and stop individual instances, as described in the following sections:
The following procedures describe how to start and stop an entire RAC database, as well as each cluster database instance:
Log in to Oracle Enterprise Manager Database Control.
On the Cluster Database Home page in the General view, click Startup if the database is down, or Shutdown if the database is up.
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.
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.
On the Startup/Shutdown: Confirmation page, click Yes.
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.
Note:You can also start up and shut down individual instances from each instance's home page. However, it is easier to perform instance startup and shutdown operations directly from the Database Startup and Shutdown page.
Managing backup and recovery in RAC database environments is similar to managing backup and recovery in single-instance Oracle database environments. This section provides an overview of some of the additional concepts and procedures for backup and recovery in RAC environments. This section contains the following topics:
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:
Go to the Cluster Database Home Page, and click the Administration tab.
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.
See Also:Oracle Database Oracle Clusterware and Oracle Real Application Clusters Administration and Deployment Guide for additional information about redo log threads in a RAC database environment, and "Online Redo Log Files"
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:
Go to the Cluster Database Home Page, and click the Maintenance tab.
On the Cluster Database Maintenance page, under the Backup/Recovery column, select Schedule Backup.
Follow the backup procedures outlined in Chapter 9, "Performing Backup and Recovery".
See Also:Oracle Database Oracle Clusterware and Oracle Real Application Clusters Administration and Deployment Guide for additional information about backing up RAC databases
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.
See Also:Oracle Database Backup and Recovery Basics for additional information about basic recovery and restoration procedures and Oracle Database Oracle Clusterware and Oracle Real Application Clusters Administration and Deployment Guide
To recover a RAC database:
Go to the Cluster Database Home Page and click the Maintenance tab.
On the Cluster Database Maintenance page, under the Backup/Recovery column, select Perform Recovery.
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.
See Also:Oracle Database Oracle Clusterware and Oracle Real Application Clusters Administration and Deployment Guide for more information about using Flash Recovery Areas in RAC
Oracle by Example (OBE) has a series about the Oracle Database 2 Day DBA book. This OBE guides you through the tasks that this appendix describes and the OBE includes annotated screen shots. To view the Real Application Clusters OBE, direct your browser to the following location: