Analyzing awr report
- 1. Oracle AWR report Analysis
- 2. Table of contents ORACLE AWR REPORT ANALYSIS........................................................................................................1 TABLE OF CONTENTS...............................................................................................................................2 1. INTRODUCTION......................................................................................................................................3 2. AWR REPORT PARTS.............................................................................................................................3 2.1 THE SNAPSHOT DETAILS.........................................................................................................................3 2.2 LOAD PROFILE........................................................................................................................................3 2.3 TOP 5 TIMED FOREGROUND EVENTS.....................................................................................................4 ......................................................................................................................................................................5 2.4 THE TIME MODEL STATISTICS.................................................................................................................5 Time Model Statistics..............................................................................................................................5 2.5 SQL SECTION.........................................................................................................................................6 2.5.1 Total Elapsed Time ................................................................................................................................................................7 2.5.2 Total CPU Time.............................................................................................................................7 2.5.3 Total Buffer Gets ................................................................................................................................................................7 2.5.4 Total Disk Reads ................................................................................................................................................................7 2.5.5 Total Executions............................................................................................................................8 2.5.6 Parse Calls ................................................................................................................................................................8 2.5.7 Sharable Memory ................................................................................................................................................................8 2.5.8 Version Count................................................................................................................................9
- 3. 1. Introduction This document will introduce and explain the main parts of an Oracle AWR report. 2. AWR report parts 2.1 The snapshot details This is normally shown at the beginning of the report. Snap Id Snap Time Sessions Cursors/Session Begin Snap: 7556 19-Oct-12 21:00:05 247 41.9 End Snap: 7558 19-Oct-12 23:00:14 249 41.6 Elapsed: 120.14 (mins) DB Time: 239.38 (mins) Elapsed (time) is the interval of time between the start and end snapshots. Another important quantity is database DB Time which is the sum of working sessions’ time. DB Time = sum of database CPU time + waits. In systems with multiple concurrent active sessions DB Time can be larger than the elapsed time. This is because DB Time is a sum of over all active sessions that are using CPU(s) or waiting for an event. Note that Background processes are not included in that. 2.2 Load Profile Per Second Per Transaction Per Exec Per Call DB Time(s): 2.0 0.0 0.01 0.01 DB CPU(s): 1.3 0.0 0.01 0.00 Redo size: 31,071.8 423.5 Logical reads: 1,022,277.2 13,933.4 Block changes: 174.3 2.4
- 4. Physical reads: 493.9 6.7 Physical writes: 10.2 0.1 User calls: 301.1 4.1 Parses: 22.6 0.3 Hard parses: 0.7 0.0 W/A MB processed: 12.8 0.2 Logons: 0.2 0.0 Executes: 160.6 2.2 Rollbacks: 66.9 0.9 Transactions: 73.4 The Load Profile is one of the most important parts in the AWR report. Of particular significance are the physical I/O rates and hard parses1 . A high hard parse rate usually is a result of not using bind variables2 . If you see a high hard parse rate per second for logons, it usually means that your applications aren’t using persistent connections. A high number of logons or an unusually high number of transactions tells you something unusual is happening in your DB. However, the only way you will know the numbers are unusual is if you regularly check the AWR reports in a properly functioning DB. 2.3 Top 5 Timed Foreground Events This is probably one of the most important sections of AWR report. This section is where you can usually spot the problem, by showing you why the sessions are ‘waiting’. The top 5 events information shows the total waits for all sessions. Usually one or two sessions are responsible for most of the waits. In a nicely performing DB, you should see CPU and I/O as the top wait events. 1 Hard parse – Oracle has to do a hard parse when a session executes an SQL statement that does not exist in the shared pool. AS opposed to Soft parse that happens when a session executes an SQL statement that exists in the shared pool and there is a version of the statement that can be used. 2 Bind variables is a place-holder variable in a SQL statement that must be replaced with a valid value (or address of a value) before the statement can successfully execute.
- 5. If any wait events from the concurrent wait class such as latches3 show up in the top wait events, investigate these events further. Event Waits Time(s) Avg wait (ms) % DB time Wait Class db file sequential read 2,817,676 810 0 62.0 User I/O DB CPU 130 9.9 free buffer waits 5,505 70 13 5.3 Configurat log file sync 142 46 324 3.5 Commit log buffer space 371 36 97 2.7 Configurat In above 62% of database time was spent waiting for db file sequential read. However, the average wait time was zero. Another 9.9% of the time was spent waiting for or using CPU time. A tenth of database time used by DB CPU event is not bad at all. In general High CPU usage is often a symptom of poorly tuned SQL. 2.4 The time model statistics Time Model Statistics • Total time in database user-calls (DB Time): 14363s • Statistics including the word "background" measure background process time, and so do not contribute to the DB time statistic • Ordered by % or DB time desc, Statistic name Statistic Name Time (s) % of DB Time sql execute elapsed time 12,416.14 86.45 DB CPU 9,223.70 64.22 parse time elapsed 935.61 6.51 hard parse elapsed time 884.73 6.16 failed parse elapsed time 821.39 5.72 PL/SQL execution elapsed time 153.51 1.07 3 Latch - fast, inexpensive and non-sophisticated lock. The latch is used when you need to serialize access to operations, functions and data structures in Oracle. They are meant to be held for a very short time.
- 6. hard parse (sharing criteria) elapsed time 25.96 0.18 connection management call elapsed time 14.00 0.10 hard parse (bind mismatch) elapsed time 4.74 0.03 PL/SQL compilation elapsed time 1.20 0.01 repeated bind elapsed time 0.22 0.00 sequence load elapsed time 0.11 0.00 DB time 14,362.96 background elapsed time 731.00 background cpu time 72.00 Time model statistics give you an idea about how the DB has spent its time, including the time it spent on executing SQL statements as against parsing statements. If parsing time is very high, or if hard parsing is significant, you must investigate it further. In the above example, 9,223.70 seconds CPU time was used for all user sessions. This was just under 65% of database resources. In total there was 14363 seconds database time used. The total wait event time can be calculated as 14363 – 9223.70 = 5139.3 seconds. The lion share of database time (86.45%) was spent on executing sql which is a good sign. The total parse time was 935.61 seconds of which 884.73 seconds was hard parsing. The rest of statistics is tiny in this case 2.5 SQL Section If any SQL statement appears in the top 5 statements in two or more areas below, it is a prime candidate for tuning. The sections are: • Total Elapsed Time • Total CPU Time • Total Buffer Gets • Total Disk Reads • Total Executions • Total Parse Calls • Total Sharable Memory • Total Version Count Let us try to see what these mean.
- 7. 2.5.1 Total Elapsed Time Total Elapsed Time = CPU Time + Wait Time. If a SQL statement appears in the total elapsed time area of the report this means its CPU time plus any other wait times made it pop to the top of the pile. Excessive Elapsed Time could be due to excessive CPU usage or excessive wait times. 2.5.2 Total CPU Time When a statement appears in the Total CPU Time area this indicates it used excessive CPU cycles during its processing. Excessive CPU processing time can be caused by sorting, excessive function usage or long parse times. Indicators that you should be looking at this section for SQL tuning candidates include high CPU percentages in the service section for the service associated with this SQL (a hint, if the SQL is uppercase it probably comes from a user or application; if it is lowercase it usually comes from the internal or background processes). To reduce total CPU time, reduce sorting by using composite indexes that can cover sorting and use bind variables to reduce parse times. 2.5.3 Total Buffer Gets Total buffer gets mean a SQL statement is reading a lot of data from the db block buffers. Generally speaking buffer gets (AKA logical IO or LIO) are OK, except when they become excessive. To reduce excessive buffer gets, optimize SQL to use appropriate indexes and reduce full table scans. You can also look at improving the indexing strategy and consider deploying partitioning. 2.5.4 Total Disk Reads High total disk reads mean a SQL statement is reading a lot of data from disks rather than being able to access that data from the db block buffers. High physical reads
- 8. after a server reboot are expected as the cache is cold and data is fetched from the disk. However, disk reads (or physical reads) are undesirable in an OLTP4 system, especially when they become excessive. Excessive disk reads cause performance issues. To reduce excessive disk reads, consider partitioning, use indexes and look at optimizing SQL to avoid excessive full table scans. 2.5.5 Total Executions High total executions need to be reviewed to see if they are genuine executions or loops in SQL code. I have also seen situations where autosys jobs fire duplicate codes erroneously. If the database has excessive physical and logical reads or excessive IO wait times, then look at the SQL statements that show excessive executions and show high physical and logical reads. 2.5.6 Parse Calls Whenever a statement is issued by a user or process, regardless of whether it is in the SQL pool it undergoes a parse. As explained under Parsing, the parse can be a hard parse or a soft parse. Excessive parse calls usually go with excessive executions. If the statement is using what are known as unsafe bind variables then the statement will be reparsed each time. If the headers parse ratios are low look here and in the version count areas (2.5.8). 2.5.7 Sharable Memory Sharable Memory refers to Shared Pool memory area in SGA, hence, this particular section in AWR Report states about the SQL STATEMENT CURSORS which consumed the maximum amount of the Shared Pool for their execution. 4 Online transaction processing, or OLTP, refers to a class of systems that facilitate and manage transaction-oriented applications, typically for data entry and retrieval transaction processing.
- 9. In general, high values for Sharable Memory doesn’t necessary imply there is an issue, it simply means that: 1. These SQL statements are big or complex and Oracle has to keep lots of information about these statements OR 2. big number of child cursors exist for those parent cursors 3. combination of 1 & 2 In case of point 2, it may be due to poor coding such as bind variables mismatch, security mismatch or overly large SQL statements that join many tables. Usually large statements will result in excessive parsing, recursion, and large CPU usage. 2.5.8 Version Count High version counts are usually due to multiple identical-schema databases, unsafe bind variables, or Oracle bugs.
- 10. In general, high values for Sharable Memory doesn’t necessary imply there is an issue, it simply means that: 1. These SQL statements are big or complex and Oracle has to keep lots of information about these statements OR 2. big number of child cursors exist for those parent cursors 3. combination of 1 & 2 In case of point 2, it may be due to poor coding such as bind variables mismatch, security mismatch or overly large SQL statements that join many tables. Usually large statements will result in excessive parsing, recursion, and large CPU usage. 2.5.8 Version Count High version counts are usually due to multiple identical-schema databases, unsafe bind variables, or Oracle bugs.