问题数据库的AWR报告，请诸神帮忙指导一下

thinking

问题数据库的AWR报告，请诸神帮忙指导一下，谢谢！

gdpr-dba

加大内存，优化sql，特别是cskchu9q06xcu和1ydutttka8dqk，分析LOCK TABLE操作的合理性，另外你的存储IO性能比较差。

Maclean Liu(刘相兵

Elapsed:                  59.14 (mins)                  
DB Time:                  85.65 (mins)

DB TIME不高 。 有3个TOP SQL 占中DB TIME 的80%:


Elapsed Time (s)        Executions        Elapsed Time per Exec (s)        %Total        %CPU        %IO         SQL Id        SQL Module        SQL Text
1,897.78        1        1,897.78        36.93        14.84        89.52        cskchu9q06xcu         offline_engine Data Direct JDBC Driver        insert /*NOA_INSERT_UDX_LOOKUP...
1,623.93        0                 31.60        15.97        89.07        1ydutttka8dqk         offline_engine Data Direct JDBC Driver        insert /*NOA_INSERT_UDX_LOOKUP...
893.95        1        893.95        17.39        0.00        0.00        17mk575wk60xw         offline_engine Data Direct JDBC Driver        LOCK TABLE RUM_ACTIONS_L_ACTIO...

不清楚你说的问题 存在于哪里

thinking

日志文件、控制文件都有写等待，不知是存储I/O性能较差，还是I/O资源被物理读严重的TOP SQL给抢占了。

thinking

gdpr-dba 发表于 2013-7-15 20:47
加大内存，优化sql，特别是cskchu9q06xcu和1ydutttka8dqk，分析LOCK TABLE操作的合理性，另外你的存储IO性 ...

谢谢，之前我就怀疑存储I/O性能较差，您能指出那几个指标能证明此存储存在性能问题吗？

不了峰

我武断一点,根本不是IO差的问题. 而是不良SQL的引起的大量的物理读~

机器的性能根本没有发挥

gdpr-dba

thinking 发表于 2013-7-16 09:07
谢谢，之前我就怀疑存储I/O性能较差，您能指出那几个指标能证明此存储存在性能问题吗？ ...

Load Profile

	Per Second	Per Transaction	Per Exec	Per Call
DB Time(s):	1.5	1.4	0.05	0.06
DB CPU(s):	0.2	0.2	0.01	0.01
Redo size:	82,588.5	79,831.9
Logical reads:	3,598.9	3,478.8
Block changes:	239.5	231.5
Physical reads:	2,770.7	2,678.2
Physical writes:	711.6	687.8
User calls:	23.8	23.0
Parses:	18.9	18.2
Hard parses:	0.4	0.4
W/A MB processed:	2.6	2.5
Logons:	0.1	0.1
Executes:	28.9	28.0
Rollbacks:	0.0	0.0
Transactions:	1.0

File IO Stats

• ordered by Tablespace, File
  

Tablespace	Filename	Reads	Av Reads/s	Av Rd(ms)	Av Blks/Rd	Writes	Av Writes/s	Buffer Waits	Av Buf Wt(ms)
BSM	/app/bsmdata/bsm9.dbf	9,424	3	9.98	104.94	528	0	0	0.00
BSM	/app/bsmdata/bsm9_1.dbf	10,683	3	8.49	122.35	105	0	0	0.00
BSM	/app/bsmdata/bsm9_2.dbf	10,369	3	10.00	123.51	9	0	0	0.00
BSM	/app/bsmdata/bsm9_3.dbf	12,990	4	10.70	123.78	11	0	0	0.00
BSM	/app/bsmdata/bsm9_4.dbf	13,699	4	10.84	123.39	32	0	0	0.00
BSM	/app/bsmdata/bsm9_5.dbf	10,235	3	11.12	114.64	247	0	0	0.00
BSM	/app/bsmdata/bsm9_6.dbf	4,272	1	15.21	92.36	1,809	1	0	0.00
BSM	/app/bsmdata/bsm9_7.dbf	5,129	1	21.59	1.78	11,380	3	0	0.00
BSM_TEMP	/app/bsmdata/bsm9_temp.dbf	43,890	12	0.00	31.00	79,511	22	0
SYSAUX	/app/bsmdata/bsm/sysaux01.dbf	2,358	1	20.38	1.73	1,979	1	0	0.00
SYSTEM	/app/bsmdata/bsm/system01.dbf	9,304	3	5.22	2.39	221	0	0	0.00
TEMP	/app/bsmdata/bsm/temp01.dbf	1	0	0.00	1.00	1	0	0
UNDOTBS1	/app/bsmdata/bsm/undotbs01.dbf	11	0	7.27	1.00	2,002	1	4	0.00
USERS	/app/bsmdata/bsm/users01.dbf	2	0	20.00	1.00	0	0	0	0.00

每秒的IO数据量不到30M，每秒的IO次数几十次，这么低的IO负载情况下平均每次读取时间基本都超过了10ms，有的甚至到了20ms，理想的速度应该在5ms以内的。

gdpr-dba

不了峰 发表于 2013-7-16 09:30
我武断一点,根本不是IO差的问题. 而是不良SQL的引起的大量的物理读~

机器的性能根本没有发挥 ...

其实物理读并没有多大，系统的负载也比较低，不过SQL写得不好却是真的，同一张表重复扫描了三四次，实际上可能扫描一次就出可以了。

thinking

学习了。。。谢谢大家！