易飞程序执行效率优化

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