故障：应用保存失败，这种情况不是每次都发生，所以查起来比较麻烦。
这是使用maxgauge解决的第一个问题。maxgauge确实象介绍的那么强大。
通过把所有操作重现，可以很好的把偶然发生的问题记录下来，供以后分析研究。
不能保存的最终原因是，主从表，从表的外键上没有索引。 这个应用是用form开发的，每次修改记录时，主表的主键都在update语句里面，及时不修改主键。这样每次update主表时，因为从表没有外键的索引， 从表整个表被lock，其他session试图对从表的任何dml都将被堵塞，表现为不能保存。
具体分析参看附件
点击下载文件
早上赶到客户那里. 服务器cpu 0% idle. 满负荷运行. 连接数达到800.
2cpu, 8G ram. hp-ux , oracle 9202.
三层架构应用. 没有使用weblogic的连接池.
通过v$system_event,发现大量 cache buffers chains等待. 应该是有热块.
col owner for a20
col segment_name for a20
col segment_type for a5
select distinct a.owner,a.segment_name,a.segment_type from
dba_extents a,
(select dbarfil,dbablk
from (select dbarfil,dbablk
from x$bh order by tch desc) where rownum < 11) b
where a.RELATIVE_FNO = b.dbarfil
and a.BLOCK_ID <= b.dbablk and a.block_id + a.blocks > b.dbablk;
查到几个表.
数据量不大的放到buffer里面.重启数据库.
把weblogic启用连接池,启动100,最多300. 明天看效果.
注意:
1. 开始就使用statspack报告.便于前后比较.
2.调优过程中,始终运行osw.记录os情况,比如cpu,io.便于后面分析.
环境:hpux 11.11,oracle 9204 rac.
应用:2层架构. 150-200个session. 7x24小时.
性能问题: 突然客户端速度慢.不能忍受.
1.检查cpu, io
top, iostat
cpu使用率70%左右, 不是瓶颈.
iostat,有一个硬盘Io特别严重,其他压力不大. 对比以前正常情况的数据,基本正常.
2.沟通,了解到, 有新增应用.但是已经2个月了,都比较正常.
3.针对是2层架构情况,在测试机器上启动客户端,用dbms_system.set_ev跟踪10046事件,在客户端做简单操作,看等待情况.
发现排在前面的都是一个查询语句,走得是全表扫描.
查此表数据量,二十多万,查此表索引,发现没有索引.
初步判断与此相关.
跟踪一个正常的客户端,跟踪15分钟,再按照fchelc排序,耗时最长的大部分也是这个语句.
最长达6秒. 基本确定是全表扫描引起.
沟通发现,这个表数据量在3个月内增加到二十多万. 和实际情况相符. 随着数据量增大,全表扫描已经成为瓶颈.
建议: 在此字段上创建索引.
效果:创建后,客户端响应时间明显检查.