ITPub博客

首页 > Linux操作系统 > Linux操作系统 > 一次关于APEX应用的问题

一次关于APEX应用的问题

原创 Linux操作系统 作者:JohnTam10 时间:2011-06-09 21:13:26 0 删除 编辑
        某天一客户反映公司网站响应缓慢,请求帮忙对后台数据库进行性能检查跟调优,我的第一反应是获取告警日志进行检查,整理出十个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/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论

注册时间:2010-09-10

  • 博文量
    40
  • 访问量
    89014