基干MES系统业务逻辑性能优化.docVIP

  1. 1、原创力文档(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。。
  2. 2、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载
  3. 3、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
  4. 4、该文档为VIP文档,如果想要下载,成为VIP会员后,下载免费。
  5. 5、成为VIP后,下载本文档将扣除1次下载权益。下载后,不支持退款、换文档。如有疑问请联系我们
  6. 6、成为VIP后,您将拥有八大权益,权益包括:VIP文档下载权益、阅读免打扰、文档格式转换、高级专利检索、专属身份标志、高级客服、多端互通、版权登记。
  7. 7、VIP文档为合作方或网友上传,每下载1次, 网站将根据用户上传文档的质量评分、类型等,对文档贡献者给予高额补贴、流量扶持。如果你也想贡献VIP文档。上传文档
查看更多
基于MES系统业务逻辑的性能优化   [摘 要]MES是面向制造企业车间执行层的生产信息化管理系统,在系统初期由于数据量小、系统压力轻,其系统的缺点不易暴露出来。随着时间的推移,各种问题都会出现。在性能调优的方法中最常用的方法是SQL调优,但是有的SQL已经是最优,只能通过修改业务逻辑来实现调优的目的。本文列举几个比较经典的案例,以期为MES系统开发和维护人员提供帮助 [关键词]MES系统;业务逻辑;性能;优化 doi:10.3969/j.issn.1673 - 0194.2016.16.000 [中图分类号]TP311.52 [文献标识码]A [文章编号]1673-0194(2016)16-00-02 MES系统的性能直接关系到工厂一线的生产,性能低下的系统功能会直接影响到工厂的生产进度,从而间接影响到产能。因此,高效的业务执行在MES系统中至关重要,在生产总数据量庞大、单位时间内业务处理量高的繁忙系统中更加明显。本文将结合生产制造行业的MES系统特征,以实际业务系统中出现的业务查询和更新时性能问题作为出发点,结合业务逻辑,有效地实现了业务处理性能的改善 1 SimpleJdbcCall――增加对参数类型赋值,避免调用元数据 应用的SQL性能一般通过AWR报告来分析,出现报告中Top SQL上的语句一般需要进行性能分析。通过观察AWR发现有两条查询占用33.7%的DB Time,其SQL是用来查询系统表的数据,且使用者是用户 经分析,这两条SQL是应用使用SimpleJdbcCall调用存储过程或者函数产生的。SimpleJdbcCall是一个多线程、可重用,用来调用存储过程或者函数的工具,它通过提供元数据的处理方式来简化对基本存储过程和函数的访问。在执行存储过程或者函数时,只需要提供执行存储过程或函数的名字和用Map表示的相应的参数,这些参数的名字将会与创建存储过程或者函数时定义的参数名进行匹配 这种方式为应用程序开发者简化了代码,但是对于存储过程或者函数使用较多的系统,则会出现资源争用的情况。SimpleJdbcCall提供的addDeclaredParameter方法来指定每个变量的类型,就可以避免SimpleJdbcCall在执行存储过程或者函数时先调用元数据的过程。因此,将应用上所有的函数中增加了addDeclaredParameter这个方法,完成优化后不但提高业务的处理速度,也降低对DB资源的争用情况,两个查询从Top SQL中消失 2 索引列使用默认值代替NULL值 笔者观察AWR发现有一条SQL,它的平均执行时间为0.2S,占了接近1.73%的DB Time,但是对应表是一个20M的小表,这样的查询出现在Top SQL中绝对是有问题的。分析其执行计划,CBO选择IDX_01,Cost数值为653 对数据及查询结果进行分析,此表总数据约为24万条,此查询的结果返回13条基准信息。IDX_01索引列名为(FACTORYNAME),而整张表中此列值相同,没有任何选择度;其次,此表还有一个基于(SUPERAREANAME)列的索引IDX_02,而要查询出来的数据所对应的SUPERAREANAME为NULL值。即使在Where条件上SUPERAREANAME的筛选条件,基于以上数据分布和Oracle的特性,该CBO不会选择IDX_02。综合业务分析,最终将这13条数据的SUPERAREANAME列填写具有区分度的数据,并将此列加到Where条件中。再次分析执行计划,Cost数值由652降低为2。再次查看AWR,此条SQL从Top SQL中消失了 以上案例可以看到,对单表进行查询优化时,先对数据和现有的Index进行分析,有时候不需要建立额外的Index,而是对数据稍作变动,就能解决问题。由于B*Tree索引不存储Null值,所以查询NULL值数据时,Oracle会因为Null值的存在而放弃索引。为了此种情况发生,使用默认值代替NULL值,或者在建立index时使用联合索引而非独立索引 3 大量查询――小表替换大表 用户一直反应某个查询较慢,经常因为查询时间较长而收到超时错误。分析此查询的SQL语句,语句并不复杂,当前使用的索引也是最优的。通过tkprof工具对Trace文件进行分析,发现SQL执行的主要时间是花费在数据获取(fetch)上,total数据为:disk(51163)、query(76985)、current(0)、rows(1764),平均每行所需的block数=(query+current)/rows,此查询平均读取每行需要的Block数约为44块。正常情况,访问一条数据的速度由索引的高度和回表查询的IO决定,一般索引高度都在3层以下

文档评论(0)

linsspace + 关注
实名认证
文档贡献者

该用户很懒,什么也没介绍

1亿VIP精品文档

相关文档