In Oracle AWR reports, the Time Model Statistics section greatly simplifies a DBA’s task by revealing where the database spends its time from the user’s perspective.

In most cases, “sql execute elapsed time” is dominant component of DB Time. Since Oracle databases are built to execute SQL, one may expect it to be close to DB Time. However, in practice, a significant gap between these two metrics often exists. What accounts for the gap?

The answer lies in how Oracle classifies certain SQL-like operations. Not all SQL statements are included in “SQL execute elapsed time.” Notably, COMMIT and ROLLBACK—despite being valid SQL—are excluded from SQL execution time. Their runtime is still part of DB Time, but not of “SQL execute elapsed time”. This can be corroborated by the fact that you won’t find COMMIT or ROLLBACK entries in dynamic performance views like V$SQL, nor do they appear in the “SQL Statistics” section of an AWR report. If COMMITs were counted as ordinary SQL, they would likely appear among the top SQLs due to their high frequency in many workloads.

In this example, “sql execute elapsed time” accounts for only 68% of DB Time. This suggests that commit operations are likely responsible for much of the remaining 32%.

Supporting this assumption, the “log file sync” wait event consumes approximately 30% of DB Time in the Top Events section, which aligns closely with the observed gap.

Leave a comment

I’m Yuan

Welcome to the blog of a performance maven in Oracle & MySQL. Feel free to contact me to share and discuss database knowledge.

My 20 Oracle Certifications

A screenshot from certview.oracle.com

My Book

MySQL 8.0 Operations and Optimization

Let’s connect