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

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

207

积分

1

好友

4

主题
1#
发表于 2012-12-27 14:19:03 | 查看: 3733| 回复: 2
如题,本来是2个节点的HP-UX  B.11.23 U ia64+10.2.0.4,如今节点2由于更换硬件为完成所以未开启,只剩下了1个节点。
附上awr报告,13:00-14:00的。

QQ截图20121227141646.png (78.1 KB, 下载次数: 374)

QQ截图20121227141646.png

93.html

340.67 KB, 下载次数: 678

爱老婆,爱FM,爱音乐;挨踢,爱折腾,爱Oracle
2#
发表于 2012-12-27 14:26:35
Event
Waits
Time(s)
Avg Wait(ms)
% Total Call Time
Wait Class
read by other session
130,623
15,516
119
14.0
User I/O
CPU time
13,839
12.5
db file sequential read
259,491
9,547
37
8.6
User I/O
log file sync
16,077
9,108
567
8.2
Commit
db file scattered read
82,229
8,054
98
7.3
User I/O




IO较差, 单块读平均37ms,多块读98ms

Per Second
Per Transaction
Redo size:
12,123.20
2,648.70
Logical reads:
68,541.05
14,974.99
Block changes:
55.63
12.15
Physical reads:
429.86
93.92
Physical writes:
9.07
1.98
User calls:
136.08
29.73
Parses:
50.72
11.08
Hard parses:
0.34
0.07
Sorts:
14.61
3.19
Logons:
0.09
0.02
Executes:
61.97
13.54
Transactions:
4.58



实际每秒的物理读写都不多


table scans (long tables)
29
0.01
0.00
table scans (short tables)
32,736
9.03
1.97



大表扫描不多, buffer cache 7392MB

主要等待类型是IO

Wait Class
Waits
%Time -outs
Total Wait Time (s)
Avg wait (ms)
Waits /txn
User I/O
477,457
0.00
33,604
70
28.76
Commit
16,077
1.24
9,108
567
0.97
Concurrency
22,645
17.82
8,965
396
1.36
System I/O
22,322
0.00
5,567
249
1.34
Application
3,575
5.01
870
243
0.22
Other
28,852
57.67
360
12
1.74
Configuration
90
48.89
106
1176
0.01
Network
360,736
0.00
14
0
21.73
Cluster
489
0.00
12

Physical Reads
Executions
Reads per Exec
%Total
CPU Time (s)
Elapsed Time (s)
SQL Id
SQL Module
SQL Text
562,446
0
36.07
42.61
3365.66
5g7j8a21fr14b DECLARE job BINARY_INTEGER := ...
562,445
0
36.07
42.61
3365.16
1rbdshj6h2ru1 INSERT INTO T_RBT_USER_BEING (...
474,874
4
118,718.50
30.46
14.32
3284.87
7cddggs1rvtfsJDBC Thin Clientselect receiversm0_.MSG_ID as ...
236,503
52
4,548.13
15.17
22.14
5693.37
2ht08a4ctcv8gJDBC Thin Clientselect feedaction2_.USER_ID as...
170,743
4
42,685.75
10.95
40.00
2871.77
360dut0ds5n1dJDBC Thin Clientselect tt.content, tt.ct, rown...




SQL 1rbdshj6h2ru1          7cddggs1rvtfs耗了对多的物理读

对应表 T_RBT_ORDER_TONE_LOGS  和  T_RBT_RECEIVE_SM

总结:

1. Io能力较差, 请找存储工程师确认这一点
2. 部分SQL消耗较多CPU 导致 IO等待和 read by other session

回复 只看该作者 道具 举报

3#
发表于 2012-12-27 14:56:19
多谢,我找下该存储相关资料看看,打800

回复 只看该作者 道具 举报

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

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

GMT+8, 2024-12-26 01:35 , Processed in 0.051420 second(s), 23 queries .

Powered by Discuz! X2.5

© 2001-2012 Comsenz Inc.

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