Monitoring Performance

Learn how to monitor and tune the performance of your Oracle Real Application Clusters (Oracle RAC) database.

Monitoring and Tuning Oracle RAC Databases

Oracle Enterprise Manager provides cluster-aware monitoring through the Cluster Database Home, Interconnects, and Cluster Database Performance pages, enabling administrators to review cluster status, alerts, services, cache coherency, network activity, host load, active sessions, throughput, wait classes, services, and instances. Standard database tuning practices also apply to RAC, while the Database Reliability Framework continuously detects cross-layer issues and can automatically correct problems by adjusting memory structures or process priorities.

Verifying the Interconnect Settings for Oracle RAC

Interconnect configuration affects Cache Fusion performance through its bandwidth, latency, and IPC efficiency. Query V$CLUSTER_INTERCONNECTS and V$CONFIGURED_INTERCONNECTS to verify the connected instance’s private and public interfaces, addresses, and configuration sources; use GV$CLUSTER_INTERCONNECTS to inspect all cluster instances.

Influencing Interconnect Processing

Interconnect hardware performance cannot usually be changed after deployment, but IPC buffer sizes can influence protocol efficiency. Oracle Clusterware stores interconnect information in the OCR, which can be inspected or modified with OIFCFG or OCRDUMP; the CLUSTER_INTERCONNECTS parameter can also assign a private address or NIC when necessary. Supported clusters may use multiple private networks with either IPv4 or IPv6, but the same protocol must be used consistently.

Performance Views in Oracle RAC

Oracle RAC provides instance-specific V$ dynamic performance views and cluster-wide GV$ views. GV$ views combine qualified instances’ V$ data and add the INST_ID column, allowing administrators to identify the originating instance or restrict queries, such as selecting lock information from specific instances.

Creating Oracle RAC Data Dictionary Views with CATCLUST.SQL

RAC databases created without Database Configuration Assistant may lack required RAC-related data dictionary views and tables. In that situation, an account with SYSDBA privileges must run the CATCLUST.SQL script to complete the RAC data dictionary configuration.

Oracle RAC Performance Statistics

Oracle RAC performance statistics are reported as message request counters or timed statistics. Message counters quantify activities such as block mode conversions, while timed statistics measure total or average wait time for specific read and write I/O operations.

Automatic Workload Repository in Oracle RAC Environments

AWR creates hourly snapshots containing synchronized performance data from all active RAC instances, storing values separately by instance rather than as cluster-wide aggregates. ADDM can analyze this data across the entire cluster, a single instance, or a selected subset of instances through RAC, Local, or Partial ADDM modes, using Enterprise Manager or PL/SQL packages.

Active Session History Reports for Oracle RAC

ASH reports diagnose RAC performance by sampling active sessions across instances, focusing on sessions using CPU or waiting on non-idle events and thereby limiting data to workload-related activity. RAC-specific sections include Top Cluster Events, which identifies events and instances responsible for cluster wait activity, and Top Remote Instance, which identifies instances contributing most to prolonged cluster waits.

Monitoring Oracle RAC Statistics and Wait Events

RAC performance analysis uses AWR, Statspack, dynamic performance views, ASH, ADDM, and GCS/GES statistics to evaluate global cache activity, enqueue messaging, block transfers, remote requests, and wait behavior. Cluster wait events distinguish normal cache traffic from issues involving hot blocks, contention, load, interconnect misconfiguration, or excessive SQL block access; analysis should correlate wait time, affected objects and instances, SQL cluster wait time, CPU and network conditions, and service times to determine corrective actions such as SQL tuning, workload redistribution, or additional capacity.