Oracle Wait Events and Their Solutions in Oracle Database

I will explain Oracle Database Wait Events and Their Solutions in this article.

 

 

 

Oracle Database Wait Events

I will describe some of the wait events that cause performance problems in Oracle Databases. You can find the top 5 wait events in the AWR reports. In this article, I will tell you about the most frequently encountered Wait events in AWR reports.

 

If you don’t know what is the AWR report and how to generate it, read following article before this.

How to Generate AWR ( Automatic Workload Repository ) Report via SQL*Plus, Enterprise Manager and Toad in Oracle

 

Oracle Wait Events and Their Solutions

Db file sequential read

Db file sequential read: This event occurs when a user tries to perform a Physical I/O while waiting for sequential reads from the Buffer cache. This type of situation usually occurs when the data on the table is accessed by using index, not full table scan, as a result of single block reading.

 

If this event occurs,  possible reasons are wrong index usage, index fragmentation, excessive I/O traffic on specific disks. To Solve this problem, Query should use Right index and fragmented indexes should be defragmented with Rebuild Index operation.

When you encounter this wait event, which appears very frequently in AWR and ADDM reports, we cannot always say that there is a problem. However, if this wait event takes place, if the database have ‘Enqueue’ and Latch Free and they are spending too much time, then database should be monitored

 

 

 

Db file scattered read

Db file scattered read: This wait event occurs getting multiblock of physical blocks that are not physically close to each other (neighbors) into buffer cache Scattered, or during a full scan to the buffer cache. So Db file scattered read is to read multiple blocks I/O during the fast full scan.

 

Small tables can be cached to avoid this wait event.

 

Direct path read

 

Direct path read: This event occurs when Oracle Instance query data from the Datafiles asynchronously and puts this data into PGA  instead of Buffer Cache in SGA.

 

This type of event usually occurs during the use of Temporary ( Temp ) Tablespace in the Sorting operations, during the creation of Lob segments, and when multiple sessions Full table scan in parallel.

In order to solve this problem, the memory should be increased, parallel operations should not be done unless required, and pay attention to Lob segments reads.

 

 

 

 

DB CPU

DB CPU: This event represents the total time spent of the users’ queries on the CPU.  Oracle’s Background processes (SMON, PMON ..) are not included in this total time.

If this value is high, it means that the Oracle instance spends most of the time on the CPU. To reduce this wait event, the SQLs in the SQL ordered by CPU section in the AWR report must be TUNE.

 

Log file sync

Log file sync: This event is known as the time lost as a result of the LGWR process waiting while users initiate a Transaction Commit or Rollback.

If this wait event is available continuously, I/O performance of the LGWR process is probably poor, or Commit is coming too often by the application. The solution to this problem is not to commit too much, if necessary, and to examine the I/O performance of the disk on which the Redo log files are located, and to use a high performance disk such as an SSD disk if necessary.

 

Enq: TX – row lock contention

Enq: TX – row lock contention:  This type of event occurs when a user session is trying to update or delete a row held by another session, which is an application design problem. Normally, when a transaction is finished, commit or rollback must be executed to release related rows.

The solution to this problem is that if the session that holds the row is active, then execute commit statement, if it is not active, kill the session or execute rollback the session.

 

ARCH wait on SENDREQ: This wait event is the total time taken by the Archiver Processes to archive the Standby in the Dataguard and to write these archives to the local disks.

The main reason why this value is high is that the archives sent to the Standby side arrive late due to the network. To solve this problem, it is necessary to optimize the Network and set the DEFAULT_SDU_SIZE parameter in the sqlnet.ora file to an optimized value (32767).

 

Gc current block busy:  This wait event occurs between the nodes of the Cluster database ( Real Application Cluster ). When a transaction requests a block, that request sent to the master instance. Normally, this request is performed by a cache fusion.

However, in some cases, this block transfer is delayed because the corresponding instance is held by the other instance or because the corresponding transaction records cannot be written to the redo logs immediately, in which case this wait event is triggered.

This can be solved by tune the wait event Log Writer process or Solving network problem between Cluster nodes.

 

Gc cr block busy wait: This wait event occurs like the gc current block busy wait event above. The only difference is that while the above event is running in current mode, this wait event runs in CR mode. This can be solved by tune the wait event Log Writer process.

 

 

 

Do you want to learn Oracle Database Performance Tuning detailed, then Click this link.