Home » RDBMS Server » Performance Tuning » AWR analysis
AWR analysis [message #479104] Thu, 14 October 2010 10:21 Go to next message
dba1234
Messages: 1
Registered: October 2010
Junior Member
DB Name	DB Id	Instance	Inst num	Startup Time	Release	RAC
	2725233562		1	31-Aug-10 13:08	11.1.0.7.0	NO
Host Name	Platform	CPUs	Cores	Sockets	Memory (GB)
sgpmv070	Linux x86 64-bit	2	 	 	1.84
	Snap Id	Snap Time	Sessions	Cursors/Session
Begin Snap:	4494	23-Sep-10 14:00:47	50	8.2
End Snap:	4495	23-Sep-10 15:00:01	51	8.2
Elapsed:	 	59.22 (mins)	 	 
DB Time:	 	123.48 (mins)	 	 

Cache Sizes 
	Begin	End		
Buffer Cache:	184M	184M	Std Block Size:	16K
Shared Pool Size:	304M	304M	Log Buffer:	6,504K
Load Profile 
	Per Second	Per Transaction	Per Exec	Per Call
DB Time(s):	2.1	49.7	1.01	0.74
DB CPU(s):	1.7	39.6	0.80	0.59
Redo size:	757.7	18,068.5	 	 
Logical reads:	5,618.7	133,983.5	 	 
Block changes:	2.1	49.8	 	 
Physical reads:	2,992.6	71,361.3	 	 
Physical writes:	1,275.7	30,419.2	 	 
User calls:	2.8	67.0	 	 
Parses:	1.8	44.0	 	 
Hard parses:	0.0	0.3	 	 
W/A MB processed:	2,453,233.4	58,500,034.2	 	 
Logons:	0.0	0.7	 	 
Executes:	2.1	49.3	 	 
Rollbacks:	0.0	0.0	 	 
Transactions:	0.0	 	 	 
Instance Efficiency Percentages (Target 100%) 
Buffer Nowait %:	100.00	Redo NoWait %:	100.00
Buffer Hit %:	99.82	In-memory Sort %:	85.62
Library Hit %:	99.06	Soft Parse %:	99.34
Execute to Parse %:	10.82	Latch Hit %:	100.00
Parse CPU to Parse Elapsd %:	0.00	% Non-Parse CPU:	99.99
Shared Pool Statistics 
	Begin	End
Memory Usage %:	89.00	89.04
% SQL with executions>1:	89.61	89.59
% Memory for SQL w/exec>1:	85.55	84.35

Top 5 Timed Foreground Events 
Event	Waits	Time(s)	Avg wait (ms)	% DB time	Wait Class
DB CPU	 	5,893	 	79.54	 
direct path write temp	1,139,089	1,331	1	17.96	User I/O
direct path read temp	6,440,066	92	0	1.24	User I/O
direct path read	415,397	36	0	0.49	User I/O
db file sequential read	16,639	21	1	0.28	User I/O
Host CPU (CPUs: 2 Cores: Sockets: ) 
Load Average Begin	Load Average End	%User	%System	%WIO	%Idle
2.50	2.17	80.6	3.5	12.2	15.2
Instance CPU 
%Total CPU	%Busy CPU	%DB time waiting for CPU (Resource Manager)
82.9	97.7	0.0
Memory Statistics 
	Begin	End
Host Mem (MB):	1,883.4	1,883.4
SGA use (MB):	520.0	520.0
PGA use (MB):	386.2	354.5
% Host Mem used for SGA+PGA:	48.12	48.12

Time Model Statistics
•	Total time in database user-calls (DB Time): 7408.6s 
•	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	7,251.80	97.88
DB CPU	5,892.52	79.54
PL/SQL execution elapsed time	10.81	0.15
parse time elapsed	7.17	0.10
hard parse elapsed time	5.54	0.07
Java execution elapsed time	2.77	0.04
hard parse (sharing criteria) elapsed time	1.88	0.03
connection management call elapsed time	1.01	0.01
failed parse elapsed time	0.00	0.00
repeated bind elapsed time	0.00	0.00
DB time	7,408.56	 
background elapsed time	33.94	 
background cpu time	1.35	 

1. Parse CPU to parse elapsed is 0%. This means that Oracle waits for resources during parsing of SQL statements. But my non parse CPU % is 99.99% and soft parse % 99.34. What is the impact of this parse CPU to parse elapsed being 0%?

2. execute to parse % is also too low? so which means parsing is done and not executing properly. what should be looked in for this?

3. My timed model statistics show sql execute elapsed time on the top with 97%. Can i conclude the SQL execution taking up almost all DB time and look for SQL under "SQL ordered by Elapsed Time"?

Can you please let me know what else should be looked into?


[Updated on: Thu, 14 October 2010 10:24] by Moderator

Report message to a moderator

Re: AWR analysis [message #479796 is a reply to message #479104] Tue, 19 October 2010 06:18 Go to previous message
kamkan
Messages: 27
Registered: April 2007
Location: Chennai, INDIA
Junior Member
Hi,
Look for the Top 5 Timed Foreground Events. Investigate what is triggering these events? (Ignore idle events)

SQL ordered by Elapsed Time => Always helps to find the time consuming sql (Observe the elapsed time as well as number of executions also).
SQL ordered by Reads should also be noticed for I/O intensive queries.
Previous Topic: Full tablescan eventhough join is on indexed field
Next Topic: MV refresh with atomic_refresh false
Goto Forum:
  


Current Time: Wed May 15 12:33:40 CDT 2024