易飞程序执行效率优化(操作篇).ppt
《易飞程序执行效率优化(操作篇).ppt》由会员分享,可在线阅读,更多相关《易飞程序执行效率优化(操作篇).ppt(26页珍藏版)》请在三一文库上搜索。
1、前言,有许多的客户已经使用我们的产品好几年,随着数据量的逐步增大,易飞执行效率问题慢慢浮现,程序执行速度越来越慢,甚至出现白屏、死机等。 这种问题最常体现在我们关键的批次和报表上面。比如存货系统中的月结程序,进耗存统计表等。生产模块中的批次需求计划、物料需求计划等。,在进行问题排查前有两点需要注意: 大型的报表、批次,应该放到服务器上进行处理,而不应该在客户端直接处理 由于此类程序运算的数据量大,需要耗用的资源比较多,一般的客户端的配置很难达到其要求,所以杀牛焉用鸡刀,要用牛刀。 对于执行时间较长的程序,其处理的时间应该安排在服务器工作负荷较低的时候(比如凌晨、周末等) 对于特殊的程序要在特殊
2、的时段来处理。如果在服务器的负荷高峰期进行这类大型程序的运行,则会造成资源阻塞,不仅自身执行出现问题,其他的程序也会出现变慢甚至卡住的情况。,服务人员篇,在此处说明的异常是指:易飞关键程序执行速度过慢而造成程序异常中止,常见异常现象如下: 批次、报表执行已经执行有一段时间但后续无反应 有诸如”Lock Time Out”或者“SQL Server 连接超时”等信息提示 当然,如果是数据本身造成的异常-比如SQL追踪档提示ROLLBACK,然后放到事件查询器里面执行也提示错误等,则需要服务人员进行数据以及流程排查,不在此讨论。,步骤一:检查程序是否为最新,到PATCH区上与时俱进下,没准你所遇到
3、的问题,我们其他客户早已经遇到并做过对应优化了。 不知道怎么更新?请查看肖方成同学做的易飞正确打补丁方式。,步骤二:检查易飞的环境配置 1.如果是易飞60或者60以下版本,首先检查BDE的设置,调整SQL最大等待时间:,可以视情况调整,比如3000 30000 300000,与TIMEOUT属性一致:可以视情况调整,比如3000 30000 300000,可以视情况调整,比如3000 30000 300000,此类错误提示: 中文提示:“没有足够的内存执行该操作” 英文提示:“Insufficient memory to complete operation”,如果仍然不行,试着尝试下面的措施
4、:(如果主SQL查询结果非常大时,比如有上百万笔数据,可能错误为:Temporary Table Resource Limit,步骤二:检查程序以及环境是否更新 2.如果易飞版本为70,则从PATCH目录下更新dsado_d5.bpl文件,然后刷新到系统盘的SYSTEM32目录下。,步骤三:检查客户是否有自建触发器 如果发现客户有自建触发器,处理措施请参考文档 “客户自建触发器相关事项”,如果以上措施仍然不能解决问题,就需要保存好案发现场,提供有价值的信息给后方的研发部门。 需要提供的信息如下: 程序执行的LOG档(批次、建档审核段)。 客户数据库(此点视客户数据保密性情况而定) 使用事件探查
5、器,来追踪SQL的执行情况,并将追踪文件发给后方支持部门 此处需要注意的是,追踪特定数据列才会有参考价值,因此我们提供了相应的追踪模板,只需要追踪的时候使用该模板即可(别忘了调整该 模板的限定条件-HostName为当前客户端的HostName) 至于如何使用事件探查器并设定相应模板,请参考文档SQL Server Profiler.ppt。,开发人员篇,首先需要了解的是程序优化是一个不断验证、渐进的过程,客户的应用场景比较复杂,很多时候需要逐步确认问题发生的特殊时机和环境,逐步筛选出较好的方案来执行。 优化顺序按照其效果和重要性排序大体如下: -业务逻辑的设计优化 -数据库环境优化 -程序撰
6、写层次优化 -SQL语句本身的优化 下面的篇幅就上面所说的四点分别进行说明。,一.业务逻辑的优化,我们优化的程序往往比较复杂,因此在优化前需要了解到设计该程序的目的以及使用场景。因为许多规格在开立过程中,由于图省事,许多段落都是从别的地方复制过来,或者逻辑本身比较庞大、前后多人开立等原因,造成业务逻辑的偏差和大量冗余。 如果能做到对该程序的大体逻辑和应用场景胸有成竹,则能看出并可简化掉许多的不必要逻辑(许多的批次、报表、建档都有此现象),二.数据库环境的优化,数据库优化目前主要使用在建立合适的索引方面和索引维护方面。 此点对于大型报表和批次有比较好的效果。一般对程序运行的主SQL或者运行量较大
7、的SQL进行分析。在其查询条件上进行适当的索引。 索引的原理讲解篇请参照杨大鹏的SQL优化培训。 索引的操作应用篇请参照黄长圣的索引介绍。,二.数据库环境的优化,一个客户实例如下:使用易飞已经几年,平时数据量很大。现在执行月结速度越来越慢。最近运行十几小时后异常中止。 分析如下:该客户品号就有十万多笔(大家试着用品号数*仓库数*日期数来估算下数据量)。由于做月结,所以其前端选项条件只有库存年月。主要的表如下: -INVLA交易明细信息 (KEY:来源单别、单号、序号、出入别) -INVLB品号每月统计单头(KEY:品号、库存年月) -INVLC品号每月统计单身(KEY:品号、库存年月、仓库)
8、-INVLE品号每月统计子单身(KEY:品号、库存年月、仓库、库位、批号) 在2-003里面没有看到针对库存年月的索引。因此在INVLB/INVLC/INVLE上对库存年月建立了聚集索引,在INVLA上对交易日期建立了聚集索引。 按照此方法执行后,执行效率有较多的提升。(该客户具体SQL方面也做了优化,后续进行说明) 如果客户表的数据量特别大,在企业管理器里面进行索引操作速度会比较慢,可以用SQL命令的方式来执行,三.程序撰写层次优化,尘世间最悲痛的事情莫过于明明一个SQL其实执行一次就OK,你却将它放到了一个多层循环的最内层来跑。 大家在上数据结构的时候就计算过类似的东西(一个多层循环假定为
9、4层好了,每层执行1000次,那么其最终执行次数为为万亿次)。所以该项原则其实很简单:对于某段SQL(可别忘了COUNTER也是SQL哈),在不影响到业务逻辑情况下,能转到循环外层就转。,四.SQL语句本身的优化,撰写SQL语句的原则有三条: 只选出满足需求的最少数据,增一点则多,减一点则错。 如果SQL有多部分组成,每部分的原则请参考第一条。 请参考前两条。,四.SQL语句本身的优化,原理性东西大家可以多看看SQL的相关文档,这里主要说一些小的方法和注意事项。 能对所有的SQL进行优化是最好,但成本很高。我们就SQL的重要性和执行频率、目前耗时等因素来量化分析。(此处需要服务或者客户提供的S
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 程序 执行 效率 优化 操作
链接地址:https://www.31doc.com/p-2177228.html