上面说到的程序有共同的特点,那么便是要用到数据库,很多PHP页面实际上都是数据库驱动的,要连接数据库才能显示出来,而响应时间过长的原因便在于PHP 5.3连接数据库的方式有所改变。目前我们配置数据库信息时都类似这样的“$dbhost=‘localhost’ ”这本身是没有问题的,只是PHP 5.3会考虑是IPv4还是IPv6,面对localhost会犹豫,因此出现响应时间过长的情况。
如果你查看过服务器处理PHP的时间,你会发现处理PHP的时间很短,等待处理前的时间很长。目前这种响应时间过长的情况只出现在IIS 7及IIS 7.5升级PHP 5.3系列版本后,至于数据库版本是多少没多大影响。
简单普及一下知识,windows 2008分为32位和64位,自带IIS 7,windows 2008 R2自带IIS 7.5,R2版本的系统只有64位。如果你用的IIS 6或者Linux系统什么的,目前还没存在这样的问题,主要是windows 2008系统。
希望可以帮到你当在 Oracle Database 10g 中回滚长期运行的事务时,无论是并行实例恢复会话还是用户执行的回滚语句。您所需做的一切就是查看视图 V$SESSION_LONGOPS 并评估还需要多少时间。
项目中该数据库每月定期要导入大量数据。通过对导入数据期间LGWR switch出现频率的观察,发现LGWR switch切换过于频繁,需要对redo File进行优化,建议设置16个group,每个group member大小为200M。
另外,需要对导入脚本进行优化,
imp dw/cnfj_bts_dw file=call_gaa_551_200906.dmp full=y ignore=y feedback=50000 buffer=10240000 commit=y indexes=n log=’/home/imp200909.log’附录:
1、停止并行回滚,减少IO请求,快速提升系统响应能力
如果你没时间等待回滚进程完成回滚 *** 作,可根据如下提示进行 *** 作。
最后在google上根据ora_p001, wait for a undo record 的关键字,找到了一些信息,以下信息引起了我的注意:
Oracle工程师首先怀疑是临时表空间空间不足导致,经检查临时表空间没有空间不足的情况,仔细观察日志发现重做日志文件不断切换,分析应该是有较多的事务没有完成提交或者有较多没有提交的事务完成回滚。现在面临的问题是我们没有很多时间去等待所有的事务去完成回滚或提交。解决问题的思路就是如何尽快结束这些事务的回滚或提交。
1) 查看spfile文件中是否有fast_start_parallel_rollback参数的设置,检查结果G网数据库没有设置该参数。如果没有显式设置,则该参数的默认值为low。修改该参数值为false
2) 将数据库启动到nomount状态:startup nomount
3) 修改改参数值:alter system set fast_start_parallel_rollback = FALSE scope=spfile
4) shutdown immediate关闭数据库
5) startup启动
6) 查看该参数是否生效:show parameter fast_start_parallel_rollback
7) 等待一段时间
8) shutdown immediate数据库可以关闭
因为Windows Server 2008进行的修改主要是针对一些兼容性问题进行了打补丁,所以相对于Windows Server 2003会稍微感觉慢一些,但是会更安全(慢也是几乎所有安全性更新的缺点)。如果坚持用Windows Server 2008,可以尝试升级SQL软件或改进硬件配置(如CPU);如果不是坚持使用Windows Server 2008,可以尝试恢复至Windows Server 2003或升级至Windows Server 2012。欢迎分享,转载请注明来源:内存溢出
评论列表(0条)