Oracle Wait Events and Their Solutions in Oracle Database

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

 

AWR Wait Events

 

 

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_sequential_read

 

 

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.

 

pfgrf210

 

 

 

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.

About Mehmet Salih Deveci

I am Founder of SysDBASoft IT and IT Tutorial and Certified Expert about Oracle & SQL Server database, Goldengate, Exadata Machine, Oracle Database Appliance administrator with 10+years experience.I have OCA, OCP, OCE RAC Expert Certificates I have worked 100+ Banking, Insurance, Finance, Telco and etc. clients as a Consultant, Insource or Outsource.I have done 200+ Operations in this clients such as Exadata Installation & PoC & Migration & Upgrade, Oracle & SQL Server Database Upgrade, Oracle RAC Installation, SQL Server AlwaysOn Installation, Database Migration, Disaster Recovery, Backup Restore, Performance Tuning, Periodic Healthchecks.I have done 2000+ Table replication with Goldengate or SQL Server Replication tool for DWH Databases in many clients.If you need Oracle DBA, SQL Server DBA, APPS DBA,  Exadata, Goldengate, EBS Consultancy and Training you can send my email adress [email protected].-                                                                                                                                                                                                                                                 -Oracle DBA, SQL Server DBA, APPS DBA,  Exadata, Goldengate, EBS ve linux Danışmanlık ve Eğitim için  [email protected] a mail atabilirsiniz.

3 comments

  1. It is very useful for learning. If possible, please explain how to identify performance issues by using AWR report.

  2. Excellent stuff for DBA’s, thank you sir. Keep posting this kind of stuff.

Leave a Reply

Your email address will not be published. Required fields are marked *