易飞程序执行效率优化.pptVIP

前言 有许多客户已经使用我们产品好几年,随着数据量逐步增大，易飞执行效率问题慢慢浮现，程序执行速度越来越慢，甚至出现白屏、死机等。 这种问题最常体现在我们关键批次与报表上面。比如存货系统中月结程序，进耗存统计表等。生产模块中批次需求计划、物料需求计划等。 在进行问题排查前有两点需要注意： 大型报表、批次，应该放到服务器上进行处理，而不应该在客户端直接处理 由于此类程序运算数据量大，需要耗用资源比较多，一般客户端配置很难达到其要求，所以杀牛焉用鸡刀，要用牛刀。 对于执行时间较长程序，其处理时间应该安排在服务器工作负荷较低时候（比如凌晨、周末等） 对于特殊程序要在特殊时段来处理。如果在服务器负荷高峰期进行这类大型程序运行，则会造成资源阻塞，不仅自身执行出现问题，其他程序也会出现变慢甚至卡住情况。 服务人员篇 在此处说明异常是指：易飞关键程序执行速度过慢而造成程序异常中止，常见异常现象如下： 批次、报表执行已经执行有一段时间但后续无反应 有诸如”Lock Time Out”或者“SQL Server 连接超时”等信息提示 当然，如果是数据本身造成异常---比如SQL追踪档提示ROLLBACK，然后放到事件查询器里面执行也提示错误等，则需要服务人员进行数据以及流程排查，不在此讨论。 步骤一：检查程序是否为最新，到PATCH区上与时俱进下，没准你所遇到问题，我们其他客户早已经遇到并做过对应优化了。 不知道怎么更新？请查看肖方成同学做易飞正确打补丁方式。 步骤二：检查易飞环境配置 1.如果是易飞60或者60以下版本，首先检查BDE设置，调整SQL最大等待时间: 可以视情况调整，比如3000 30000 300000 与TIMEOUT属性一致：可以视情况调整，比如3000 30000 300000 可以视情况调整，比如3000 30000 300000 此类错误提示： 中文提示：“没有足够内存执行该操作” 英文提示：“Insufficient memory to complete operation” 如果仍然不行，试着尝试下面措施：（如果主SQL查询结果非常大时，比如有上百万笔数据，可能错误为：Temporary Table Resource Limit 步骤二：检查程序以及环境是否更新 2.如果易飞版本为70，则从PATCH目录下更新dsado_d5.bpl文件，然后刷新到系统盘SYSTEM32目录下。 步骤三：检查客户是否有自建触发器 如果发现客户有自建触发器，处理措施请参考文档 “客户自建触发器相关事项” 如果以上措施仍然不能解决问题，就需要保存好案发现场，提供有价值信息给后方研发部门。 需要提供信息如下： 程序执行LOG档（批次、建档审核段）。 客户数据库（此点视客户数据保密性情况而定） 使用事件探查器，来追踪SQL执行情况，并将追踪文件发给后方支持部门 此处需要注意是，追踪特定数据列才会有参考价值，因此我们提供了相应追踪模板，只需要追踪时候使用该模板即可（别忘了调整该 模板限定条件-HostName为当前客户端HostName) 至于如何使用事件探查器并设定相应模板，请参考文档SQL Server Profiler.ppt。 开发人员篇 首先需要了解是程序优化是一个不断验证、渐进过程，客户应用场景比较复杂，很多时候需要逐步确认问题发生特殊时机与环境，逐步筛选出较好方案来执行。 优化顺序按照其效果与重要性排序大体如下： -业务逻辑设计优化 -数据库环境优化 -程序撰写层次优化 -SQL语句本身优化 下面篇幅就上面所说四点分别进行说明。 一.业务逻辑优化 我们优化程序往往比较复杂，因此在优化前需要了解到设计该程序目以及使用场景。因为许多规格在开立过程中，由于图省事，许多段落都是从别地方复制过来，或者逻辑本身比较庞大、前后多人开立等原因，造成业务逻辑偏差与大量冗余。 如果能做到对该程序大体逻辑与应用场景胸有成竹，则能看出并可简化掉许多不必要逻辑（许多批次、报表、建档都有此现象） 二.数据库环境优化 数据库优化目前主要使用在建立合适索引方面与索引维护方面。 此点对于大型报表与批次有比较好效果。一般对程序运行主SQL或者运行量较大SQL进行剖析。在其查询条件上进行适当索引。 索引原理讲解篇请参照杨大鹏SQL优化培训。 索引操作应用篇请参照黄长圣索引介绍。 二.数据库环境优化 一个客户实例如下：使用易飞已经几年，平时数据量很大。现在执行月结速度越来越慢。最近运行十几小时后异常中止。 剖析如下：该客户品号就有十万多笔（大家试着用品号数*仓库数*日期数来估算下数据量）。由于做月结，所以其前端选项条件只有库存年月。主要表如下： -INVLA