一次关于APEX应用的问题

        某天一客户反映公司网站响应缓慢，请求帮忙对后台数据库进行性能检查跟调优，我的第一反应是获取告警日志进行检查，整理出十个ORA-错误左右，事后证实这个方向发生了偏差。既然是性能问题，首要的当然是生成获取一份awr报告，观察数据库究竟出了什么问题了。
        在观察报告的时候，又犯了一个错误，只是着眼于top 5事件的理解与思考，又忽略了问题sql的检查。只是在死抠排名第一的等待事件：virtual circuit wait。

eygle提示说，我很明显是忽略了第三个等待事件，多块读过于频繁，造成了虚拟环路的等待次数和时间过多，于是回awr报告寻找问题sql。

后来发现两运行时间较多的sql，分析第一条，并无执行计划，观察第二条的执行计划发现

发现某视图关联的两个表有多达两百万条记录，并快速增长。于是按照eygle建议进行truncate。系统响应速度有一定提升。

好景不长。今天客户打爆电话，说网站再次响应缓慢。上去一看，第一事件
virtual circuit wait还是占用dbtime的大部分大部分时间。而db file scattered read已然消失在top 5 列上。
没有办法，buffer hit差不多达到100%，开头怀疑采用了自动内存管理，而应用使用了APEX,和shared server 模式，于是先尝试关掉库的自动内存管理模式，并将sga调大，pga调小（我想是尽量使内存不集中于某个客户连接）。更改参数重启，依然无效。最后，小罗回到昨天曾经想过的问题--聚焦于明显长时间的等待事件virtual circuit wait上，搜索my oraclesupport 终于发现这有可能是使用APEX的一个bug（在11.1.0.7上出现，至今未修复）上：
问题详见：High Virtual Circuit Waits When Working with the Apex Application Using XDB

表现为：When working with the APEX application using XDB there are a high number of virtual circuit waits, which are consuming CPU.

起因为：This behavior. is due to the HTTP or FTP requests which are expected to tie up a shared server for a period of time.

解决方法：

To resolve the problem, decrease the call-timeout value on the XDB server.

1. Connect through the SQL Plus as the SYS User.

2. Execute the following command to change the on the XDB server:

Call dbms_xdb.cfg_update( updatexml( dbms_xdb.cfg_get(), '/xdbconfig/sysconfig/call-timeout/text()', '300', 'xmlns="http://xmlns.oracle.com/xdb/xdbconfig.xsd"'));

3. Restart the Database.

OR

1. Go to EM Console

2. Change the call-timeout Value to 3

3. Restart the database.

原因应该为客户端发起的连接较多，而采用了shared server模式，造成连接空闲造成的等待增多。而time out时间又是默认的60秒，造成并不能及时释放连接与数据库资源。改为3秒，即大大缓解等待的时间，系统响应速度再次提速！

top5 .jpg

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/24582392/viewspace-697524/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/24582392/viewspace-697524/