Beruflich Dokumente
Kultur Dokumente
If time spent on wait is significant compared to CPU time then we need to analyze wait
event.
From EM:
CPU bottlenecks:
Waits related to memory structures:
Are the Oracle memory structures—such as the SGA, PGA, and buffer
cache—adequately sized?
First we will check the system memory:
If this option is not working then we can use the OSWatcher ( No graphs)
Or Linux monitor tools such as ganeria
From AWR:
Begin End
Buffer Cache: 448M 448M Std Block Size: 8K
Shared Pool Size: 960M 960M Log Buffer: 14,356K
Should be between 75 – 90 %
From EM:
Av Av Av Av Buffer Av Buf
Tablespace Reads Writes
Reads/s Rd(ms) Blks/Rd Writes/s Waits Wt(ms)
PROJ_LARGE 329 0 2.10 1.00 359 0 0 0.00
SYSAUX 299 0 3.58 1.05 253 0 0 0.00
UNDOTBS1 2 0 0.00 1.00 435 0 0 0.00
PROJ_XLARGE 235 0 0.00 1.00 75 0 0 0.00
SYSTEM 206 0 4.56 1.00 39 0 0 0.0
Waits relate to Suboptimal use of Oracle Database by the application:
establishing new database connection repeatedly,
AWR:
Logons: 2.68/s
Review the listener log:
Will show the time and module.
excessive SQL parsing,
From AWR:
% Non-Parse CPU: 92.26
Should be over 90%
and highlevel of contention for a small amount of data
buffer busy wait
Need to identify the area for contention
waits related to Concurrency issues:
A high degree of concurrent activities might result in
contention for shared resources that can manifest in the forms of locks or waits for
latches.
Interconnect:
Statspack latency name Lower bound (ms) Typical (ms) Upper bound (ms)
Ave receive time for CR block 0.3 3 12
Ave receive time for current block 0.3 8 30
From AWR:
Avg global cache cr block receive time (ms): 3.7
Avg global cache current block receive time (ms): 7.1
From AWR:
Avg global enqueue get time (ms): 2.7
Degradation of database performance over time:
Compare our results with the baseline and point out any changes and try to found out.
Resource intensive SQL( logical reads , execution plan , execution time , …)
CPU utilization
Memory utlization
I/O response time
RAC interconnect