Oracle AWR report AnalysisTable of contents ORACLE AWRREPORTANALYS! 2.1 Ti SSAMHON DEAS 7 3 2.3 Ton 3 Te Foiscoun Eves : 4 . co Fie Mel Siac 3 2s89L Sno : z ‘ 7 253 Teal CPvTine 7 2.53 Teal Bufor Gots 7 350 Feal io Re 2.56 Parse Calls : s BRR Veraion Coe °1. Introduction “This document wil introduce and explah the main parts of an Oracle AWR report. 2. AWR report parts 2.1 The snapshot details ‘his s normaly shown at the beginning ofthe report Begin Snap) 7556 19-Oct-12 247 449) | anos nanan: [7858] 1s-0ee42 249, 416 23:00:14 IL | Elapsed: 120.14 (mins) DB Time: 1228.38 (mins) Elapsed (tine) isthe interval of time between the start and end snapshots. Another Important quantity is database D3 Time which isthe sum of working sessions’ time. [DB Time = sum of database CPU time + valts, In systems with multiple concurrent ‘active sessions DB Time can be larger than the elapsed time. This is because OB. “Time Isa sum of over all active seasons that are using CPU(s) ar wating for an. ‘evert. Note that Background processes are not included In that. 2.2 Load Profile petne(s: be crus) [Reto are: ans, Lit veaas: 022,277.2 nea) Beckaages “aa =Prysia wrnes 10.2 nal L = L 226, 33 L WA We processed ae o8 I ars [ 160.8 22 i Transactions: [ 73.4 L ‘The Load Profile § ane of the most important parts h the AWR report. Of particular ‘sgnificance are the physical /0 rates and hard parses'. & high hard parse rate usually is a result of not using bind variables’. you see a high hard parse rate per second for logons, it usually means that your applications aren't using persistent connections. A high mum! ‘of logens oF an unusually high umber of transactions tells yousomething unusual Is happening In your DB. However, the only way you will know the numbers are unusual is if you ragularly check the AWR reports in a properly functioning DB. 2.3 Top 5 Timed Foreground Events ‘This is probably one of the mest mportant sections of AWR report. ‘his section is where you can usually spot the problem, by showing you why the s2ssions are ‘walling’. The top 5 events information shows the total waits for all caccions. Usually one or two sessions are recponcible for most of the waite CPU and 1/0 asthe top walk In e nicely performing DB, you should a "hard parca Onl hast do hard para wha asain scutes an QL titer that doce at eee ered el AS apnea eat rae uppers when a azon aceenan SA >in varabes a place-hltervarabie in 2 SQL state ant that mst be eplaced wha va alse (0 lara ofa vale) Boor the statement can sues) execute,{If any wait events from the concurrent wait class such as latches’ show up in the top wait events, investigate these events further. nae 7a al 3a In above 62% of database time was spent waiting for db file sequential read. However, the average wait time was zero. Anather 8.9% of the tme was spent waiting for oF using CPU time. tonth of databace time used by DB CPU aver’ is not bad ot all. {In general High CPU usage Is often @ symptom of poorly tuned SQL. 2.4 The time model statistics Time Model Statistics "Latch ast, inexpesive and non-sephitented lock, The teh i used when you need to sera acess 1s operating, fucuna and dat stcturea rade. They oe ment tobe hel ta very aor ierg arse (Suariny cera) aapseatime | 7598, OL cxsnemion managument cll eapsed ime 14.00 og ‘Time model statistics glve you an idea about how the DB has spent ts time, Including the time itspent on executing SQL statements as against parsing ‘Satements. If parsing time Is very high, or Ifhant parsing is significant, you must Investigate it further {In the above example, 9,223.70 seconds CPU time was used forall user sessions. ‘This was just under 65% of database resources. In total there was 14363 seconds ‘database time used. The total walt event time can be calculated as 14363 ~ $223.70 = 5129.3 eeconde. the lion share af database time (86 45%) was epant on executing ‘jl which is 9 goed sign. The totel parse tine was 035.61 seconds of which 884.73 ‘seconds was hard parsing. The rest of stabstes Is tiny In this case 2.5 SQL Section 1 any SQL statement appears inthe top 5 state 1s a prime candidate for tuning. The sections are: nts in two oF more areas below, I Total Elapsed Time Total CPU Time Total Buffer Gets ‘Total isk Reads Total Executions Total Parse Calls Total Sharable Memory Total Version Count Let us try to see what these mean.2.5.1 Total Elapsed Time ‘otal Elapsed Time = CPU Time + Walt Time. If 2 SQL statement appears in the total lapsed time area of the report this means its CPU time plus any other wat times ‘made Itpop to the top of the pile. Excessive Flapsed Time could be due to excessive CPU usage or excessive wat times. 2.5.2 Total CPU Time When a statement appears in the Total CPU Time area this Incicates 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 ‘ould be looking at this section for SQL tuning candidates include high CPU percentages in the service section for the service astociated with this SQL (a hint, if ‘the SQL is uppercase it probably eames from a user or application; Wits loweresse It usually comes from the Internal or background precesses). To reduce total CPU time, reduce sorting by using compesite Indexes that can cover sorting and use bing varlables to reduce parse times, 2.5.3 Total Buffer Gets ‘Total buffer gats mean a SQL statements reading a lot of data from the db block buffers. Generally speating buffer gets (AKA logical 10 or LIO) are Ok, except when they become excassve, To reduce exceceve bulfer gets, optimize SQL to use ‘appropriate indexes and reduce full table scans. You can also look at impreving the Indexing strategy and consider deploy ng partkioning. 2.5.4 Total Disk Reads High total disk reads mean a SQL statement is reading a let of data from cisks rather than being able to azcess that data from the éb block buffers. High physical readsafter a server reboot are expected as the cache is cold and data i fetched from the ‘disk, However, disk reads (or physical reads) are undesirable in an OLTP* system, ‘especially when they become excessive. Excessive disk reads cause performance eoues, To reduce excessive disk reads, consider parttloning, 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. Ihave also seen situations where autosys jobs fire duplicate ‘codes erronecusiy 1 the database has excessive physical and logical reads or excessive 10 wait times, then lock at the SQL statements that show excessive executions and show high physical and logical veags. 2.5.6 Parse Calls ‘Whenever a statement is issued by a user oF process, regardless of whether itis in the SQL pool t 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. Ifthe statement is using what are krown as unsafe bind variables then the statement will be reparsed exch time. Ifthe 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 amouat of the Shared Poo! for ther execution. ‘nine Waraecion processing, c OLTP, cers toa as of systems that fatale and manage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 lt of Information about these statements OR 2. big number of child cursors exist for those parent cursors 3. combination of 182 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 usaoge. 2.5.8 Version Count High version counts are usually due to multiple iéentical-schema databases, unsafe bind variables, or Oracle bugs.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 lt of Information about these statements OR 2. big number of child cursors exist for those parent cursors 3. combination of 182 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 usaoge. 2.5.8 Version Count High version counts are usually due to multiple iéentical-schema databases, unsafe bind variables, or Oracle bugs.