AWR AND ADDM

REPORT ANALYSIS
 What Is AWR

 A background process
 A set of tables
 A set of reports
 Takes snapshots of statistics every hour
 Takes snapshot of high-cost SQL every hour
Top-Down Approach

● Report starts with settings overview

● Next provides Top-5 waits
●
Use the Waits to guide further investigation
AWR Report Header

In above scenario " DB time " metric is higher than elapsed time .
which is not a concern.But if it is Reverse then session are waiting
for something.
Load Profile Section:
1.How many Hard Parse are happening
2.How much Redo is generated
3.How many Physical Reads are happening etc
4.How many Sorts are happening
Wait Classes :

"DB CPU(s)" per second=0.6

No of CPU core=2.

DB CPU(s)" per second < cores

In this case, 0.6<2 . So, this is not a CPU bound case.

DB Time= CPU Time + Non IDLE wait time.

Non IDLE wait time=4683mins-4382mins>0 which means no waiting for cpu

What Are Your Efficiencies

● Should be close to 100%

● Parse issues usually are a result of:
– Bad bind variable usage
– Insufficient memory
– Will also be co-indicated by low percentage of
memory for multiple SQL execution
Instance Efficieny Percentages:
As per the thumb rule, Instance Efficieny Percentages
should be ideally above 90%.

Parse CPU to Parse Elapsd : parse cpu time /parse Elapsed time :
Here it is only 6.90 means more cpu time used for parsing.which is not
good.
Here low % indicate some bottleneck is there related to parsing.
 Execute to Parse: When execute is more than parse, the
figure will be positive. The ratio goes down if there are
more parses than the execute. Some of the queries are
parsed, but less or never executed!

* High number of sessions were being established during that

problem hours. Check connections/sessions established per
minute.
* There might be no "Prepared Statement caching" in java layer
or in jdbc connection pool
* There might be the case, before the execution of a query, the
cursor was closed
* There might not be enough "session cached cursors" to hold
the queries to reuse
* There might be the case where new queries were coming to
play quite frequently
* There might be connection interruptions
 Top 5 Timed Foreground Events

1. first of all check for wait class if wait class is User I/O , System I/O, Others etc this could be fine but if wait
class has value "Concurrency" then there could be some serious problem.
2.Next to look at is Time (s) which show how many times DB was waiting in this class and then Avg Wait (ms).
If Waits are high but Avg Wait (ms) is low then you can ignore this. If both are high or Avg Wait (ms) is high
then this has to further investigate.
In the above screen shot, most of the %DB time on Concurrency but Avg wait is 0.381min.So ignore it.
CPU and Memory

● Watch for number of CPUs

● Pay attention to changes in Memory
size
● An idle CPU can be a bad thing
● Always look at IO Wait verses CPU
usage
● If the system is IO bound CPU will be
idle!
Shared pool Statistics

The values should not be very high (preferably less than 75%).
Time Model Statistics:
1.If Hard parse elapsed time took more %of DB time then we have to
find out incorrect use of Bindvariable
2.Here Sql execute elapsed time took 96% of DB time . So we can look
into Top SQL to Tune it.
Operating System Statistics

system is 63.99 and 73.44% idle at time of report taken, So, there is
no resource crunch at system level. But if, you found low idle % that
means System is waiting for Some Resource.
SQL Statistics

● SQL ordered by Elapsed Time

●

● SQL ordered by CPU Time

ADDM Report

Analysis Period:
AWR snapshot range from 78950 to 78952.

Time period starts at 24-JUN-19 04.30.22 PM

Time period ends at 24-JUN-19 06.30.28 PM

Summary of Findings
-------------------
Description ActiveSessions Recommendations PercentofActivity
-------------------- -------- ----------- -----------
1 Top SQL Statements 36.58 | 93.81 2
2 Buffer Cache Latches 6.58 | 16.86 1
Findings and Recommendations
----------------------------

Finding 1: Top SQL Statements

Impact is 36.58 active sessions, 93.81% of total activity.
Recommendation 1: SQL Tuning
Estimated benefit is 29.38 active sessions, 75.35% of total activity.
---------------------------------------------------------------------
Action
Run SQL Tuning Advisor on the SELECT statement with SQL_ID "axnwpg3qwza4k".
SQL statement with SQL_ID axnwpg3qwza4k.
SELECT REQUEST_STATUS,MATCH_COUNT,NODE2_MATCH_COUNT,COUNTER,NODE1_MAT
CH_COUNT,NEGATIVE_MATCH_COUNT FROM PSX_NSP_REQUEST WHERE
REQUEST_ID=:1
Rationale
The SQL spent 82% of its database time on CPU, I/O and Cluster waits.
This part of database time may be improved by the SQL Tuning Advisor.
Rationale
Database time for this SQL was divided as follows: 100% for SQL
execution, 0% for parsing, 0% for PL/SQL execution and 0% for Java
execution.
Rationale
SQL statement with SQL_ID "axnwpg3qwza4k" was executed 142771 times and
had an average elapsed time of 1.8 seconds.
Additional Information
---------------------------------------

Miscellaneous Information
---------------------------------------
● Wait class "Application" was not consuming significant database time.
● Wait class "Commit" was not consuming significant database time.
● Wait class "Configuration" was not consuming significant database time.
● CPU was not a bottleneck for the instance.
● Wait class "Network" was not consuming significant database time.
● Wait class "User I/O" was not consuming significant database time.
● Session connect and disconnect calls were not consuming significant database time.
● Hard parsing of SQL statements was not consuming significant database time.
THANK YOU