山上有风

故障：应用保存失败，这种情况不是每次都发生，所以查起来比较麻烦。
这是使用maxgauge解决的第一个问题。maxgauge确实象介绍的那么强大。

通过把所有操作重现，可以很好的把偶然发生的问题记录下来，供以后分析研究。
不能保存的最终原因是，主从表，从表的外键上没有索引。 这个应用是用form开发的，每次修改记录时，主表的主键都在update语句里面，及时不修改主键。这样每次update主表时，因为从表没有外键的索引， 从表整个表被lock，其他session试图对从表的任何dml都将被堵塞，表现为不能保存。

具体分析参看附件
点击下载文件

今天在压力大时做statspack,分析下 library cache 等待位于top 1. 每秒 hard parse 17, parse 90
使用三层架构,但没有使用连接池(真是少见).
判断是soft parse, hard parse 过多引起library cache严重等待.

1)减少hard parse.
修改程序。
2）减少soft parse.
修改应用。尽量使用sp. 客户端调用sp.
3）启用连接缓冲池。可以减少soft parse.

早上赶到客户那里. 服务器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. 7×24小时.
性能问题: 突然客户端速度慢.不能忍受.

1.检查cpu, io
top, iostat
cpu使用率70%左右, 不是瓶颈.
iostat,有一个硬盘Io特别严重,其他压力不大. 对比以前正常情况的数据,基本正常.
2.沟通,了解到, 有新增应用.但是已经2个月了,都比较正常.
3.针对是2层架构情况,在测试机器上启动客户端,用dbms_system.set_ev跟踪10046事件,在客户端做简单操作,看等待情况.

发现排在前面的都是一个查询语句,走得是全表扫描.
查此表数据量,二十多万,查此表索引,发现没有索引.
初步判断与此相关.

跟踪一个正常的客户端,跟踪15分钟,再按照fchelc排序,耗时最长的大部分也是这个语句.
最长达6秒. 基本确定是全表扫描引起.
沟通发现,这个表数据量在3个月内增加到二十多万. 和实际情况相符. 随着数据量增大,全表扫描已经成为瓶颈.

建议: 在此字段上创建索引.
效果:创建后,客户端响应时间明显检查.