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 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.
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.
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.