Oracle数据库数据恢复、性能优化

找回密码
注册
搜索
热搜: 活动 交友 discuz
发新帖

351

积分

0

好友

8

主题
1#
发表于 2013-6-3 17:15:11 | 查看: 3494| 回复: 2
Load Profile

Per Second
Per Transaction
Redo size:
44,651.64
7,595.11
Logical reads:
152,770.06
25,985.74
Block changes:
159.07
27.06
Physical reads:
2,685.41
456.78
Physical writes:
96.42
16.40
User calls:
4,909.25
835.05
Parses:
1,026.06
174.53
Hard parses:
18.57
3.16
Sorts:
55.59
9.46
Logons:
911.99
155.13
Executes:
1,111.61
189.08
Transactions:
5.88

Top 5 Timed Events

Event
Waits
Time(s)
Avg Wait(ms)
% Total Call Time
Wait Class
CPU time
43,444
4.7
latch: cache buffers chains
6,434,918
14,987
2
1.6
Concurrency
latch: library cache
137,747
4,116
30
.4
Concurrency
PX Deq Credit: send blkd
2,005,501
3,855
2
.4
Other
latch: row cache objects
92,550
3,204
35
.3
Concurrency


Time Model Statistics
  • Total time in database user-calls (DB Time): 921961.4s
  • 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
45,134.71
4.90
DB CPU
43,443.63
4.71
parse time elapsed
9,175.67
1.00
hard parse elapsed time
803.34
0.09
PL/SQL execution elapsed time
41.97
0.00
hard parse (sharing criteria) elapsed time
7.22
0.00
PL/SQL compilation elapsed time
4.92
0.00
connection management call elapsed time
2.43
0.00
hard parse (bind mismatch) elapsed time
0.21
0.00
failed parse elapsed time
0.21
0.00
repeated bind elapsed time
0.18
0.00
sequence load elapsed time
0.16
0.00
DB time
921,961.37
background elapsed time
533.26
background cpu time
134.23


两个问题:
1)为什么每秒登录900多次,但从connection management call elapsed time看消耗在连接上的时间才2秒?
2)从top5和time model看顶级时间加起来的百分比不到10%,其他的DB TIME消耗到哪去了?难道全部都在CPU的等待队列上了?


awrrpt_1_70252_70256.rar

51.93 KB, 下载次数: 1358

2#
发表于 2013-6-3 17:22:16
如果真有这么高的负载 mmon、mmnl 都未必能正常工作 ,所以 已经不能完全相信 AWR了

alert.log、mmon、mmnl的trace上传看看

connection management call elapsed time 作为statistics , 也依赖于 session存在之后才能积累, 实际在这个session出现之前 OS上fork 一个server process的成本 也是不低的, 甚至于存在fork 了process 却仍记不上session statistics的可能。

回复 只看该作者 道具 举报

3#
发表于 2013-6-3 17:45:09
Maclean Liu(刘相兵 发表于 2013-6-3 17:22
如果真有这么高的负载 mmon、mmnl 都未必能正常工作 ,所以 已经不能完全相信 AWR了

alert.log、mmon、mmn ...

这份报告是其他网友的,所以拿不到trace。

“实际在这个session出现之前 OS上fork 一个server process的成本 也是不低的”

操作系统fork server process也算入db time吗?如果算的话是算等待事件还是CPU TIME呢?谢谢。

回复 只看该作者 道具 举报

您需要登录后才可以回帖 登录 | 注册

QQ|手机版|Archiver|Oracle数据库数据恢复、性能优化

GMT+8, 2024-11-16 15:52 , Processed in 0.057663 second(s), 23 queries .

Powered by Discuz! X2.5

© 2001-2012 Comsenz Inc.

回顶部
TEL/電話+86 13764045638
Email service@parnassusdata.com
QQ 47079569