This panel shows a combination of Interconnect and Global Cache Service information, and information about the Oracle RAC database overall. It consists of information aggregated from queries sent out to the individual instances. This provides information on how well data is being shared and transferred between nodes in the cluster.
Some information displayed here is easily calculated: for example, the Total Logical Reads spinner is the sum of the individual Logical Reads values. Other components, such as Cluster Latency and Cluster Overhead, have a more complex calculation.
Spotlight uses the Global Database label to indicate alarms in one or more Oracle instances that may affect the performance of the Oracle RAC database as a whole.
The performance of the cluster interconnect is measured by monitoring the GCS (Global Cache Service) activity between instances in the cluster. Metrics that indicate how well the cluster is performing are:
Interconnect Load: Oracle uses the Interconnect for block movement and cache coherency between instances in the Oracle RAC cluster. An Interconnect Load indicates that a session is unable to find a required block on the local instance, and has to make a request for the block from the remote instance.
This indicates one of the following:
Interconnect Load may be an indication of the overall performance of the cluster.
Within an Oracle RAC cluster, the cluster interconnect transfers blocks that have been requested by sessions on one instance from other instances that currently hold those blocks. The performance of the interconnect is crucial for the performance of the Oracle RAC cluster and, more specifically, for the movement of cached data between instances.
The health of the movement of cache between instances is measured by the average elapsed time from when the requesting instance requests the block to the time when the requesting instance receives the block.
In any database instance, we can expect occasional spikes of user activity. However, when the average of such spikes continues to be high for an extended period of time, it may indicate a degradation in the overall performance of the database cluster.
When a user on a single-instance Oracle configuration requests a block, Oracle will first look for the block in its buffer; if the block is not found in the buffer, Oracle retrieves the data from disk.
In an Oracle RAC environment (where blocks are shared across multiple instances), a user on one instance can get a block being read by another session on another instance only by requesting the block from that other instance. The GCS (Global Cache Service) has to transfer the block across the interconnect, and the block can then be viewed by the user.
The additional time used to request a block from another instance is called cluster overhead and is measured as a percentage of the total time waited.
Shows the amount of memory allocated to the In-Memory column store aggregated over the instances in the RAC, and how much of that memory is in use.
Note: Oracle In-Memory is available for Oracle 12c Release 1 (184.108.40.206) and above. Data is displayed for Oracle instances where In-Memory is available and has been enabled. In-Memory is disabled by default.
|Cache Miss Rate||
When a user requests a data block, the block is cached in the SGA for reuse by other sessions until such time as the block is not used and the space is required for other data. A "cache miss" occurs when a data block requested by the user session is not found in the local SGA, and the block has to be obtained from a remote instance.
The Cache Miss Rate metric indicates the frequency of such requests, and it directly affects the overall performance of the cluster
|Global Cache||The total amount of memory currently allocated to all buffer caches across all instances in the cluster. This is derived from v$sga_dynamic_components so if automatic memory management is enabled this will reflect the actual allocation and not the value of the parameter.|
The Global Database area of the panel displays aggregated values for the following metrics across all instances in the database cluster.
The components in the Global Database panel represent the aggregated behavior of the individual nodes within the Oracle RAC cluster.
Color changes in these components (and in the Global Database heading) represent alarms from one or more nodes that may affect the overall operation of the cluster itself.
Note: The Global Database label indicates when problems in one or more instances affect the operation of the cluster AS A WHOLE.
|Total Logical Reads||
The rate of Logical I/O (LIO) performed across all instances in the Oracle RAC cluster. LIO occurs when Oracle finds data in the local buffer cache of an instance without needing to read the data from physical disk.
Reading data from the buffer is less expensive than reading it from disk, but still the cost of LIO in an Oracle environment cannot be ignored. Oracle's architecture depends on underlying operating systems for several of its operations, including performing an LIO. To read a block from buffer, Oracle requires that a lock be placed on the row. To obtain a lock, Oracle requires a latch, for which it depends on the operating system.
When the operating system has no available latches (because other processes have taken them), the Oracle process has to sleep for a while before it can acquire one. This entire operation means that the LIO operation in an Oracle architecture is not cheap.
|Total Phys IO||
The rate of physical reads and physical writes performed across ALL instances in the Oracle RAC cluster.
|Avg CPU Load||
The average CPU load across ALL active nodes in the cluster. It displays the CPU consumption by all processes across all nodes in the cluster. (Most nodes run both Oracle and non-Oracle processes, and because all processes consume CPU cycles, the tuning of non-Oracle factors can also improve Oracle performance in the cluster.)
Note: Oracle statistics report only CPU utilization by Oracle sessions, but the CPU percentage reported by Spotlight on Oracle RAC covers both Oracle and non-Oracle processes.
Because Oracle uses the CPU during several of its operations, extensive CPU usage by a few processes may cause a performance bottleneck that prevents other regular processes from using the CPU. Such processes should be identifed and tuned to avoid the bottleneck.
For example, when Oracle executes a SQL statement, it parses the statement to determine whether its syntax and contents are correct. This process can cause significant overhead and consume CPU. Once a statement has been parsed, Oracle does not parse the statement again unless the parsing information is aged from the memory cache and is no longer available. Ineffective memory-sharing among SQL statements – including insufficient shared pool size and the non-use of bind variables – is a major cause of frequent reparsing.
Oracle processes also consume significant CPU when they perform high levels of logical I/O (LIO). Wherever possible, you should tune SQL statements to avoid high LIO. See Total Logical Reads for more information.
|Total RAM||Total amount of RAM available for the Oracle RAC cluster.|
|Free RAM||The percentage of free RAM available across all nodes in the Oracle RAC cluster.|
|Total DB Storage||The total size of tablespaces in the Oracle RAC cluster.|
|Files||The total number of data files in the Oracle RAC cluster.|
|Tablespaces||The total number of tablespaces in the Oracle RAC cluster.|
|Data Guard Overhead||
This control is applicable to environments where Oracle Data Guard is installed. It shows the overhead of Data Guard on the primary database.
The design is similar to the Average Active Sessions (AAS) guage.
A value greater than the CPU limit indicates potential performance issues. This is shown on the Average Active Sessions gauge as either of the colored bars passing the vertical white line. How far the colored bar has passed the vertical white line indicates the severity of the performance issue. A value far greater than the CPU limit indicates that the database is experiencing bottlenecks.
Note: Alarms on this component are raised on the Spotlight on Oracle Data Guard Home Page, not the Spotlight on Oracle RAC home page.
This control is applicable to environments where Oracle Data Guard is installed. The apply lag measures the difference in elapsed time from when the last applied change became visible on the standby and that same change was first visible on the primary.
An alarm raised on this control indicates an alarm on Spotlight on Oracle Data Guard - NOT necessarily an alarm on the apply lag. For more information on the alarm raised, open the Spotlight on Oracle Data Guard home page(s) for this Primary database. The severity of the alarm on this control matches the highest severity alarm raised on Spotlight on Oracle Data Guard. The Standby connections are ordered in the related drilldowns list according to severity, the Standby with the highest severity alarm raised against it is listed first.
The Uptime for the Oracle RAC cluster.
Note: The Uptime for the Oracle RAC cluster is that of the database instance with the longest uptime. This may underestimate the actual uptime of the cluster.
The name of the container for the pluggable database.
Note: Applicable to Oracle 12c.
The name of the pluggable database.
When the Spotlight connection is to the container database, the displayed pluggable database is CDB$ROOT.
Note: Applicable to Oracle 12c.