Chatta subito con l'assistenza
Chat con il supporto

Foglight for Oracle (Cartridge) 6.1.0.10 - User Guide

Installing and Configuring Agents Using Foglight for Oracle
Viewing the Databases Dashboard Assigning Instances to Users Selecting an Instance to Monitor Foglight for Oracle Overview Dashboard Overview view Advisories view SQL Performance Investigator (SQL PI) Oracle Activity Drilldown Pluggable Databases Drilldown Storage Drilldown Reviewing Configuration Settings Reviewing the Alert Log Reviewing Monitored Data Guard Environments Reviewing ASM Instances Reviewing Exadata-related Information
Administering Foglight for Oracle Reporting Reference Glossary

CPU Usage

When SQL statements and other types of calls are made to Oracle, processing the calls requires spending a certain amount of CPU time. Whereas processing average calls requires a small amount of CPU time, a SQL statement involving a large amount of data or a runaway query can consume a much larger amount, thereby reducing the CPU time available for other processing.

CPU utilization is a key operating system statistic in the tuning process. Excessive CPU usage can result from an inadequately-sized system, untuned SQL statements, or inefficient application programs.

CPU Wait

CPU wait events take place when the session is waiting in the system's run queue to be granted for CPU cycles. The length of these wait events (the amount of time spent) depends upon the number of concurrent processes and threads requesting CPU time.

This metric’s value should be inspected in conjunction with the value of the Run Queue Length.

Cursors

Extensions to result sets that provide the mechanism for working with individual rows, or a small block of rows, in a table.

Because a cursor points to a currently selected set of records, they can be used by only one connection at a time. However, the compiled plan to which the cursor is linked can be used simultaneously by multiple connections.

DataGuard

Oracle Data Guard ensures high availability, data protection, and disaster recovery for enterprise data.

Using Data Guard’s set of services for creating, maintaining, managing, and monitoring one or more standby databases, enables production Oracle databases to survive disasters and data corruptions. These standby databases are then maintained as transactionally-consistent copies of the production database. If the production database is unavailable due to outage (either planned or unplanned), these copies enable Data Guard to switch any standby database to the production role, thereby minimizing the downtime associated with the outage.

Related Documents

The document was helpful.

Seleziona valutazione

I easily found the information I needed.

Seleziona valutazione