3123, 10:46 PM Document 1359094. ‘Copytight(¢) 2028, Oade, A rights reserved, Orade Confidential How to Use AWR Reports to Diagnose Database Performance Issues (Doc ID 1359094.1) In this Document Goal Best Practices Pro*Active Problem Avoidance and Diagnostic Collection ‘Ask Questions, Get Help, And Share Your Experiences With This Art ‘Top 5 Timed Events ‘SQL Statistics Analysis: Other SQL Statistic Sections Load Profile Instance Efficiency CPU time events Analysis: Actions: Other Potential CPU related Issues: Check to see if other waits follow the high CPU timed event, High External CPU usage ‘Troubleshooting CPU usage ‘Log file sync! waits Buffer busy waits Waits for ‘Cursor: mutex/ ‘Troubleshooting Other Issues Use of ADDM Reports alongside AWR Other AWR reference Articles Statspack Discuss Diagnosis of Performance Issues Using AWR Reports References (Oracle Financials Accounting Hub - Version 12.1.3 and later Oracle Database - Enterprise Edition - Version 10.2.0.1 and later Oracle Net Services « Version 10,2,0.5 to 10.2.0.5 [Release 10.2] Oracle Database Cloud Schema Service - Version N/A and later Gen 1 Exadata Cloud at Customer (Oracle Exadata Database Cloud Machine) - Version N/A and later Information in this document applies to any platform. This article aims to provide guidance on how to interpret AWR information specifically for Database Performance issues. hitpsIsupportoracle.comfepmosifaces/DacumentDisplay?_adct-state=19czqhiw00_48i 350004.1 wie3123, 10:46 PM Document 1359094. Please remember in order to produce reports, access AWR views, or use the diagnostic information from any part of the ‘Automatic Workload Repository, the Diagnostic Pack License is required. This includes the production of AWR reports, ADDM reports and ASH reports even if these are requested by product support or other agencies, NOTE: Oracle Diagnostics Pack (and Oracle Tuning Pack) is available with Enterprise Edition ONLY. For further details of pack licensing see: Oracle® Database Licensing Information 12c Release 1 (12.1) Part number €17614-08 Chapter 1 1 Oracle Database Editions Feature Availabilty by Edition hhttp://docs.oracle.com/database/ 121/DBLIC/options.htm#DBLIC139 Best Practices Pro-Active Problem Avoidance and Diagnostic Collection ‘Although some problems may be unforeseen, in many cases problems may be avoidable if signs are detected early enough. Additionally, if an issue does occur, itis no use collecting information about that issue after the event. AWR reports are one of the support recommend methods for collecting such diagnostics. For information on suggested uses, ‘other proactive preparations and diagnostics, see: Document 148281 1.1 Best Practices: Proactively Avoiding Database and Query Performance Issues Document 1477599.1 Best Practices Around Data Collection For Performance Issues Ask Questions, Get Help, And Share Your Experiences With This Ar Would you like to explore this topic further with other Oracle Customers, Oracle Employees, and Industry Experts? Click here to join the discussion where you can ask questions, get help from others, and share your experiences with this specific article. Discover discussions about other articles and helpful subjects by clicking here to access the main My Oracle Support Community page for Database Tuning AWR reports are an extremely useful diagnostic tool for the determination of the potential cause of database wide performance issues. ‘Typically when a performance issue is detected, you would collect an AWR report covering the period of the poor performance. It is best to use a reporting period no longer than 1 hour as atherwise specifics can be lost. For information regarding collecting AWR reports refer t Document 1363422.1 Automatic Workload Repository (AWR) Reports - Start Point Itis also prudent to Gather AWR reports during times when performance is acceptable to provide baselines for comparison when there is a problem. Ensure that the baseline snapshot duration is the same as the problem duration to facilitate tke with like comparison NOTE: We would also recommend using a matched ADDM report initially to give a pointer to the main issues. Reading the corresponding ADDM report as a first step to tuning can save a lot of time because It immediately points at the hitps:Isupportoracle.comfepmosifaces/DacumentDisplay?_adt ct-state=19czqhlw00_48id=1350004.1 ane3123, 10:46 PM Document 1359094. main user as compared to trying to understand what an AWR report is presenting, See: Use of ADDM Reports along side AWR AWR Webcast ‘There are some extremely useful AWR overview webcasts available for download in the Webcast Archive. Particularly: + "Troubleshooting DB Performance issues with AWR" You can download this from the following document: Document 1456176.1 Oracle Database Advisor Webcast Archives Interpretation When looking to interpret the reasons for poor database performance, we recommend that you work through the checklist in the following article prior to working through this section: Document 1628089.1 AWR Report Interpretation Checklist for Diagnosing Database Performance Issues This document provides guidance on some background information to bear in mind when examining the detail of this section that can help by framing the context of the problem. Since we are looking at a performance issue, our primary concern is what the database is waiting for. ‘When processes wait, they are being prevented from doing an activity because of some other factor. the highest benefit when wait times are reduced and as such are a good focus. ‘The Top Wait information provides such information and allows us to focus on the main problem areas without wasting time investigating areas that are not causing significant delay, igh waits provide + Top 5 Timed Events ‘As mentioned, the Top waits section is the most important single section in the whole report being as it quantifies and allows comparison of the primary diagnostic: what each session is waiting for. An example output is provided below: op 5 Times Ever svg rota Event ests Tine (5) (es) Tine katt class le scattene reas 568 «81,327 «BS 29.6 User 2/0 File sequential read pavs283 Tia 77-8 User 1/0 read by other session 4,397,338 33,4558 42.2 User 1/0 ‘The Top 5 Waits section reports on a number of useful topics related to Events. It records the number of waits encountered in the period and the total time spent waiting together with the average time waited for each event. ‘The section is ordered by the %age of the total call time that each Event is responsible for Dependent on what is seen in this section, other report sections may need to be referenced in order to quantify or check the findings. For example, the wait count for a particular event needs to be assessed based upon the duration of the reporting period and also the number of users on the database at the time; 10 Million waits in 10, minutes is far more significant than 10 Million in 10 hours, or if shared among 10 users as opposed to 10,000. In this example report, almost 60% of the time is spent waiting for 1/0 related reads, © Event 'db file scattered read "is typically used when fetching blocks for a full table scan index fast full scan and performs multi-block IO. © Event 'db file sequential read! is a single block read and is typically engaged for any activity where multi block 10 is unavailable (for example index reads). ‘Another 20% of the time is spent waiting for or using CPU time. High CPU usage is often a symptom of poorly hitpsIsupportoracle.comfepmosifaces/DacumentDisplay?_adct-state=19czqhiw00_48i 350004.1 ane3123, 10:46 PM Document 1359094. tuned SQL (or at least SQL which has potential to take less resource) of which excessive I/O can also be a symptom. More on CPU usage follows later. Based on this, we would investigate whether these waits indicate a problem or not. If so, resolve the problem, if not, move on to the next wait to determine if that is a potential cause. ‘There are 2 main reasons why I/O related waits are going to be top of the waits: © The database is doing lots of reads © The individual reads are slow ‘The Top 5 events show us information that helps us here © Is the database doing lots of reads?: The section shows > 10 Million reads for each of these events in the period. Whether ths is a lot depends on whether the report duration is 1 hour or 1 minute. Check the report duration to asses thi If the reads do seem excessive, then why Would the database do a lot of reads? ‘The database only reads data because the execution of SQL statements has instructed it to do so. To investigate further refer to the SQL Statistics Section. © Are the individual reads slow? The section shows waits of <=8 ms for the 2 1/0 related events. Whether this is fast or slow is dependent on the hardware underlying the I/O subsystem, but typically anything under 20 ms is acceptable. If the 1/0 was slow, then you can get further information from the 'Tablespace IO Stats section: Tablespace 10 stats Duytnsts VMRED/VMMRED Soaps: 1-15, S>ordered by 10s (Reads + writes) desc Tablespace Reads Reads/s Ra(es) B1ks/Ad Waits Wes) Specifically, look for the timing under Rd(ms). If it is higher than 20 milliseconds per read and reads are high, then you may want to start investigating a potential 1/O bottleneck from the os. NOTE: You should ignore relatively idle tablespaces/files as you can get high values due to disk spin-up etc, which are not relevant. If you have an issue with 10 million reads being slow it is unlikely that a tablespace/file with 10 reads has caused the problem! For further investigation, the following Document may be helpful: Document 223117.1 Troubleshooting 1/O-related waits Although high waits for ‘db file scattered read’ and ‘db file sequential read! can be I/O related, it is actually more common to find that these waits are relatively ‘normal’ based on the SQL that the database is being asked to run. In fact, on a well tuned database, you would want these events to be top of the waits, since that would mean that no ‘problem’ events were there instead! hitpsIsupportoracle.comfepmosifaces/DacumentDisplay?_adct-state=19czqhiw00_48i 350004.1 ana3123, 10:46 PM Document 1359094. The trick is being able to assess whether the high waits is indicative of some SQL statements are not using ‘optimal paths (as mentioned earlier) or otherwise. If there are high waits for ‘db file scattered read’, then ‘SQL may not be using optimal access paths and so are tending to do Full Table Scans as opposed to. indexes (or there may be missing indexes or not optimal indexes). Furthermore, high waits for ‘db file sequential read’ may indicate SQL statements are using unselective indexes and there for reading more index blocks than necessary or using the wrong indexes. So these waits may point to poor execution plans for SQL(s).. In either case, the next step would be to check the top resource consuming SQL(s) from the AWR report to determine whether these look excessive or whether improvements can be made, To do this look at the SQL Statistics Section. ‘As mentioned, 20% of the time is spent waiting for or using CPU time. This should also be looked at when looking at the SQL Statistics Remember that the next step to take following the Top 5 Waits is dependent upon the findings within that section. In the example above, 3 of the waits paint towards potentially Sub-optimal SQL so that should be the section investigated next. Equally, if you do not see any latch waits, then latches are not causing a significant problem on your instance and 0 you do not need to investigate latch waits further. Generally, if the database is slow, and the Top 5 timed events include "CPU" and "db file sequential read” and "db file scattered read” in any order, then it is usually worth jumping to the Top SQL (by logical and physical reads) section of an AWR report and calling the SQL Tuning Advisor on them (or tune them manually) just to make sure that they are running efficiently. + SQL Statistics ‘WR Reports show a number of different SQL statistics SQk Statistics © SQ ordered by Elapsed Time ‘SOL ordered by CPU Time ‘SQL ordered by User VO Wait Time SOL ordered by Geta ‘SQL ordered by Reads SQL ordered by Physic SQL ordered by Executions ‘SQL ordered by Parse Calls ‘SQL ordered by Sharable Memory ‘SQL ordered by Version Count ‘SOL ordered by Cluster Wait Time Complete List of SOL Text (unopt ‘The different SQL. statistic sub sections should be examined based upon the Tap Wait events seen In the Top 5 Section, In our example, we saw top waits as ‘db file scattered read! , ‘db file sequential read and CPU. For these, we are most interested in SQL ordered by CPU Time, Gets and Reads. These sections actually duplicate some information adding other specifies as appropriate to the topic. Often looking at 'SQL ordered by gets' is a convenient stating point as statements with high buffer gets are usually good candidates for tuning : SQl ordered by Get “> Resources reported for PL/SQL code includes the resources used by all SOL "Total suffer Gets: 4,745, 943,805 TS Captured SQL account for 132.2% of Tota sets PU Elapsed utter Get per beee Total Tine (s) Tine (5) SQL Te ‘SELECT ADORESSID", CURRENTS, "ADORESSTYPEID" ,CURRENTSUBRENTS. ‘RRENIS. "CITY", CORRENTS. "21", CURRENTS. °STATE™ CURRENTS. “PHONECOUNTRVCODE™, (CURRENTS. "PHONCRAMBER", CURRENTS. "PHONEENTENSION, CURRENTS. "FAXCOU hitps:Isupportoracle.comfepmosifaces/DacumentDisplay?_adct-tate=19czqhiw00_48i 350004.1 5ii270123, 10:46 PM Document 1359094. INERT INTO "ADDRES. OOMLY” ("ADORESSID","AODRESSPEID", CUSTORERD", 154,038,223 268 5,083,543, 28.0 $723.50 7458.95 tat coxshnz SELECT *CuSToMCRIO™ cuRRENTS.*ISACTIVE:, CURRENTS. “FERSTIAME™ CURRENTS. “LASTIAN™ Cc RENTS "ORGANIZATION" ,CORRENS, “OATEREGISTERED” CURRENTS. CUSTOMERSTATUSIO™ CURR ENTS. *LASIMOOIFIEDDATE® CURRENTS. "SOURCE" CURRENTS. EMPL OVEEDEPT™, CURRENTS Tuning can either be performed either manually ar by calling the SQL Tuning Advisor on them: Document 271196.1 Automatic SQL Tuning - SQL Profiles. Document 262687.1 How to use the Sql Tuning Advisor. Document 276103.1 PERFORMANCE TUNING USING ADVISORS AND MANAGEABILITY FEATURES: AWR, ASH, and ADDM and Sql Tuning Advisor, NOTE: Use of the SQL Tuning Advisor requires the Oracle Tuning Pack License: hhttp://docs.oracle.com/database/ 121/DBLIC/options,htm#DBLIC139 Analysis: © -> Total Buffer Gets: 4,745,943,815 On the assumption that this is an hour long report, this is @ significant number of gets and as such this Confirms that itis worth investigating the top SQL statements to make sure they are taking optimal paths, © Individual Buffer Gets The buffer gets for the individual statements shown are very high with the lowest being 850 Million, These 3 statements actually point towards 2 different reasons for the large number of buffers: = Excessive Buffer Gets/Execution SQL_IDs 'Stlyinvmwp2! and '4at7cbxBhnz' are only executed 168 times, but each execution reads over 5 Million buffers, This SQL statement is a prime candidate for tuning since the number of buffers read in each execution is s0 high. = Excessive Executions On the other hand SQL_ID ‘grr4mg7msB1" only reads 16 buffers for each execution. Tuning the individual statement may not be able to reduce that significantly. However, the issue with this statement is caused by the number of times itis executed - 65 Million Changing the way in which the statement is called is likely to have the largest impact here - itis likely that the statement is called in a loop, once per record, if it could be called so as to process multiple records at once then there is potential for significant economies of scale. Remember that these numbers may be ‘normal’ for this environment (since some are very busy). By ‘comparing this report against a baseline, you can see whether these SQL statements also read this much data when the database performs well. If they do then they are not the cause of the issue and can be ignored (although there may be benefit generally in improving them). Other SQL Statistic Sections ‘As mentioned previously, there are a number of different report sections that help for specific causes. If you do not have the particular cause, then there is likely to be little benefit in looking at these. The following section outlines some potential causes and uses: + Load Profile Dependent on the waits, the load profile section either provides useful general background information or specific details related to potential issues. Logical reaes ee) 63 15,026.07 Block changes 40,028.57 27,536.71 Physical writes 3,939.97 2,720.25 hitps:Isupportoracle.comfepmosifaces/DacumentDisplay?_adt ct-state=19czqhiw00_48id=1350004.1 ane70123, 10:46 PM Document 1359094. % stocks changes per Rese: 42.50 99.9 In the example, the waits section shows potential for issues with the execution of SQL so the load profile can be checked for details in this area, although it is not the primary source of such information. If you were looking at the AWR report for general tuning, you might pick up that the load section shows relatively high redo activity with high physical writes. There are more writes than reads on this load with 42% block changes. Furthermore, there is less hard parsing compared the soft parses. If there was a mutex wait as top wait such as ‘library cache: mutex X’, then statistics such as the overall parse rate Would be more relevant, ‘Again, comparing to a baseline will provide the best information, for example, checking to see if the load has changed by comparing redo size, users calls, and parsing. + Instance Efficiency ‘Again, instance efficiency stats are more use for general tuning as opposed to addressing specific issues (unless waits point at these). edo owas X: 100.00 2 ‘Soft parse X: 94.48 71.23% Non-Parse CPU: 99.88 ‘The most important Statistic presented here from the point of view of our example is the '% Non-Parse CPU" because this indicates that almost all the CPU time that we see in the Top Waits section Is attributable to Execution and not parse, which means that tuning SQL may help to improve this. If we were tuning, then 94.48% soft parse rate would show a small proportion of hard parsing which is desirable ‘The high execute to parse % indicates good usage of cursors. Generally, we want the statistics here close to 100%, but remember that a few percent may not be relevant dependent on the application. For example, in a data warehouse environment, hard parsing may be higher due to usage of materialized views and, or histograms. So again comparing to baseline report when performance was good is important. + Latch Activity In the example, we are not seeing significant waits for latches so this section could be ignored, However, if latch waits were significant, then we would be looking for high latch sleeps under Latch Sleep Breakdown for latch free waits: Laten Steep Breaksoun * onderes by misses dese Get Requests laser Sleeps Spin Gete Sleep Sleap2 Sleeps ma hitps:Isupportoracle.comfepmosifaces/DacumentDisplay?_adct-state=19czqhiw00_48i70123, 10:46 PM Document 1359094. cacne buffers Inv chain Here the top latch is cache buffers chains, Cache Buffers Chains latches protect the buffers in the buffer cache that hold data that we have retrieved from disk. This is a perfectly normal latch to see when data is being read. When this becomes stressed, the sleeps figure tends to rise as sessions start to wait to get the buffers they require, Contention can be caused by poorly tuned SQL reading the same buffers, In our example, although the gets are high at 2.8 billion buffer gets, the sleeps at 41,336 is low. Average number of sleeps per miss ratio (Avg Sips/Miss) is low. The reason for this is that the server is able to deal with this volume of data and so there is no significant contention on Cache Buffers Chains latches at this point. For other latch free waits, review the following Document to identify what type of latches to investigate: Document 413942.1 How to Identify Which Latch is Associated with a "latch free" wait Notable timed and wait events: + CPU time events Just because CPU comes as top timed event in AWR may not indicate a problem. However, if performance is slow with high CPU usage, then start investigating the wait. First, check to see if a sql is taking most CPU under SQL. ordered by CPU Time in AWR: SQL ordered by Cru Tine SS hesourees reported for PL/SQL code includes the resources used by all 5Qt nts calles by the code. al is the CPU Tine divided into the Total CPU Tine tines 200 tal COU Tine (2): 50,207 3 Captures SQL account for "214.6% of Total cou elapsed PU per x70 Tine (3) Time (3). Executions Exec (5) X Total DB Tine SQt 9.4. Tobhgayivsens DECLARE job BINARY INTEGER :~ :Job; next_date TIMESTAMP NITH TIME ZONE :~ zyda te; broken aQOLEaN”:~ FALSC; job. mane VARCIAR2(20) --vJobnane) job subane vatcunta(Ge) = Job subrane;_ Job owner VARCHARZ( 3) = TIMESTAMP WITH TIME ZONE i= Job_start; Job_scheduled_star Job_ouners, job start Analysis: © => Total CPU Time (s): 56,207 This represents 15 minutes of CPU time in total. Whether this is significant depends on the report duration. © The top CPU using SQL uses 20,349 second (around 5 minutes), © Total DB of time this represents is 9.1%, © Executions is 168 - being as this execution count is the same as 2 of the 3 SQLs identified earlier, these may be related and this task may well be the scheduling job that runs the SQLs. Actions: Once you have identified the SQL statements that are using the highest CPU, investigate the reason for this usage. © Look at the number of executions and see whether that is appropriate for this statement, Excessive executions might indicate that the statement is being called too frequently and it might be possible to execute it for a group of rows rather than row by row (i.e, execute it in a batch). © Is the amount of CPU per execution excessive - this might indicate that the statement itself is inefficient. © Additionally, look at the other SQL Statistics in the AWR report to see if the SQLID(s) in question show excessive values for any of those, then deal with the statement appropriately. Other Potential CPU related Issues: hitps:iIsupportoracle.comfepmosifaces/DacumentDisplay?_adt ct-state=19czqhlw00_48id=1350004.1 ane3123, 10:46 PM Document 1359094. © Check to see if other waits follow the high GPU timed event. For example, cursor: pin waits may cause the high CPU with following known issue: Document 6904068.8 Bug 6904068 - High CPU usage when there are "cursor: pin S" waits © High External CPU usage If a process outside of the database is taking high CPU, then this could be preventing database processes from getting the CPU they require and affecting the database performance. In this case, run oswatcher or ‘ther os diagnostic tools to find which process is taking high CPU. Document 433472.1 OS Watcher For Windows (OSWFW) User Guide © Troubleshooting CPU usage ‘The following Document outlines how to further diagnose high CPU usage: Document 164768.1 Troubleshooting: High CPU Utilization * ‘Log file sync’ waits When a user session commits or rolls back, the log writer flushes the redo from log buffer to the redo logs. AWR reports are very useful for determination if this is a problem and whether the cause of the problem is 1/O or in some other area. The following articles deal specifically with this symptom: Document 1376916.1 Troubleshooting: "Log File Sync” Waits Document 34592.1WAITEVENT: "log file sync” + Buffer busy waits This is he event waited on when a session is trying to get a buffer from the buffer cache but the buffer is busy - either being read by another session or another session is holding it in incompatible mode. In order to find which block is busy and why, use the following Documents: Document 155971.1 Resolving Intense and "Random" Buffer Busy Wait Performance Problems Document 34405.1 WAITEVENT: “buffer busy waits” + Waits for ‘Cursor: mutex/pin* If there are mutex waits such such as ‘Cursor: pin S wait on X’ or 'Cursor: mutex X' etc , then these are indicative of parsing issues. On this basis look for statements with high parse counts or high version counts under 'SQL ordered by Parse Calls’ and ‘SQL ordered by Version Count’ as these are most likely to be the causes of problems. The following Documents can assist further: Document 1356828.1 FAQ: ‘cursor: mutex..." / ‘cursor: pin ..’/ ‘library cache: mutex ..' Type Wait Events Document 1349387.1 Troubleshooting ‘cursor: pin S wait on X' waits. Troubleshooting Other Issues hitps:iIsupportoracle.comfepmosifaces/DacumentDisplay?_adt ct-state=19czqhlw00_48id=1350004.1 one13/23, 10:46 PM Document 1259094.1 For guidance troubleshooting other performance issues see: Document 1377446.1 Troubleshooting Performance Issues Use of ADDM Reports along: je AWR ADM reports can be reviewed along with AWR to assist in diagnosis since they provide specific recommendations which can help point at potential problems, The following is a sample ADDM report taken from: Document 250655. 1How to use the Automatic Database Diagnostic Monitor: Example Output: DETAILED ADDM REPORT FOR TASK 'SCOTT_ADDM' WITH 1D 5 Analysis Period: 17-NOV-2003 from 09:50:21 te 10:95:47 Database ID/Instance: 494687018/1 Snapshot Range: from 1 to 3 Database Tine: 4215 seconde Average Database Load: 5 active sessions FINDING 1: 65% impact (2734 seconds) PL/SQL execution consumed significant database time. RECOMMENDATION 1: SQL Tuning, 65% benefit (2734 seconds} ACTION: Tune the PL/SQL block with SQL_ID fixalvplyntmr. Refer to the "Tuning PL/SQL Applications" chapter of Oracle's "PL/SQL User's Guide and Reference” RELEVANT OBJECT: SQL, statement with SQL_ID fjxalvpayhtme BEGIN BMD NOTIFICATION. QUEUE_READY(:1, 2, :3)7 END; % impact (1496 seconds) FINDING 2: SQL statements consuming significant database time were found. RECOMMENDATION 1: SQL Tuning, 25% benefit (1456 seconds} ACTION: Run SQL Tuning Advisor on the SQL statement with SOL ID gt 9anqgas inm2 RELEVANT OBJECT: SQL statement with SQL_ID gU9ahqgaS{an2 and PLAN_AASH 547793521 UPDATE bigenp SET empno ~ ROWNUM FINDING 3: 20% impact. ‘The throughput of the I/O subsystem was significantly lower than expected RECOMMENDATION 1: Host Configuration, 20% benefit (B36 seconds) ACTION: Consider increasing the throughput of the 1/0 subsysten. Oracle's recommended solution is to stripe all data file using the SAME methodology. You might also need to increase the number of disks for beter performance. RECOMMENDATION 2: Host Configuration, 14% benefit (584 se ACTION: The performance of file D:\ORACLE\ORADATA\V1010\UNDOTBSO1.DBF wae significantly worse than other files. If striping all files using the SAME nethedology is not possible, consider striping this file over multiple disks. RELEVANT OBJECT: database file "D: \ORACLE\ORADATA\W1010\UNDOTBSO1.. DBF" nds) hitps:Isupportoracle.comfepmosifaces/DacumentDisplay?_adt ct-state=19czqhiw00_48id=1350004.1 sone3123, 10:46 PM Document 1359094. Wait class "User 1/0" was consuming significant database tine (G48 impact (1450 seconds!) FIM seconds) unde 1/0 was a G41 2be mp ficant portion (33%) of the total database T, NO RECOMMENDATIONS AVATLABi SYMPTOMS THAT LED TO THE FINDING he throughput of 10 su expected. (20% impact [836 second: Wait clase "User 1/0" was (G48 impact (1450 FINDING 5: 9.98 impact (416 seconds) ache writes due to small log time es were consuming signi: ACTION, ase the size of the log east 20 minutes do information onfiguration, 9.9% benefit (416 second: es to 196 M to hold 'ADDM report gives possible recommendations in more readable format than AWR. However, ADDM should be interpreted along with AWR statistics for accurate diagnostics Other AWR reference Articles ‘The following documents can assist when reading other sections of AWR reports and for other purposed: Document 786554.1 How to Read PGA Memory Advisory Section in AWR and Statspack Reports Document 754639,1 How to Read Buffer Cache Advisory Section in AWR and Statspack Reports Document 1301503.1 Troubleshooting: AWR Snapshot Collection issues Document 1363422.1 Automatic Workload Repository (AWR) Reports - Start Point Statspack AWNR reports supersede legacy reports such as statspack and bstat/estat. For reference, the following is a link to and artide outlining how to read statspack reports: http://www oracle,com/technetwork/database/focus-areas/performance/statspack-opm4-134117.pdt ‘Additional information can be found in the following articles: Document 94224.1 FAQ- Statspack Complete Reference Statistics Package (STATSPACK) Guide Document 149113.1. Installing and Configuring StatsPack Package Document 149121.1 Gathering a StatsPack snapshot Document 228913.1 Systemwide Tuning using STATSPACK Reports Discuss Diagnosis of Performance Issues Using AWR Reports Still have questions? Consider posting a discussion in the Database Tuning Community. hitps:iIsupportoracle.comfepmosifaces/DacumentDisplay?_adt ct-state=19czqhlw00_48id=1350004.1 ame3123, 10:46 PM Document 1359094. NOTE:1301503.1 - Troubleshooting: Missing Automatic Workload Repository (AWR) Snapshots and Other Collection Issues NOTE:1363422,1 - Automatic Workload Repository (AWR) Reports - Main Information Sources NOTE:276103.1 - Performance Tuning Using Advisors and Manageability Features: AWR, ASH, ADDM and SQL Tuning ‘Advisor NOTE:250655.1 - How to Use the Automatic Database Diagnostic Monitor NOTE:228913.1 - Systemwide Tuning Using STATSPACK Reports Didnt find what you are looking for? 350004.1 sane hitpsIsupportoracle.comfepmosifaces/DacumentDisplay?_adct-state=19czqhiw00_48i