包钢宽厚板MES系统优化

开篇：润墨网以专业的文秘视角，为您筛选了一篇包钢宽厚板MES系统优化范文，如需获取更多写作素材，在线客服老师一对一协助。欢迎您的阅读与分享！

【摘要】文章介绍了包钢薄板厂宽厚板mes系统运行情况和出现的问题，并详细阐述了针对整个系统的优化方式和原理。

【关键词】MES；数据库；中间件；优化

1.问题的提出

包钢宽厚板MES于2007年年底与生产同步上线，系统的投入运行在生产质量控制方面起着举足轻重的作用，但随着系统的的使用，新需求的提出和改进再所难免，上下互联的系统间的交互业务非常频繁，用户多，访问量非常大。作为业务支撑的软件系统也处于不断的改进和变化之中。该系统数据库经过一段时间的运行以后，随着数据库表规模的不断扩大，数据量的不断积累和增加，应用程序访问的改进和变化，其性能随着使用时间的延长而逐步呈现下降的趋势，所以对该系统数据库的性能优化有着重要的意义。

2.MES系统构成

宽厚板MES系统的主机平台采用两台IBM公司UNIX小型机P55A，组成集群（Cluster）结构的高可用硬件平台，一台作为数据库服务器，另一台作为应用服务器。每台服务器配置4路1.65GHz CPU，内存为8GB，内置2块73GB硬盘。两台P55A服务器采用双机热备份的方式，当一台服务器故障时，由HACMP集群软件提供的自动切换功能使另一台服务器可自动接管故障服务器的功能，保证整个主机系统不间断地运行。两台服务器之间用专用快速通道互连构成Cluster集群系统的高速心跳线，并共享一套磁盘阵列，以保证应用系统的高可用性。数据库采用ORACLE公司的10g企业版数据库，极大地提高了系统的可靠性及处理能力，保证系统持续运行。系统中间件软件采用BEA公司TUXEDO 8.1交易中间件。与相关外部系统之间的通信采用基于TCP/IP SOCKET协议的XCOM通讯中间件进行电文通讯，软件则是采用C/M/S三层架构方式，前台采用流行的.net开发，实现用户UI画面，操作简便易行，前台把用户的请求转化为与TUXEDO中间件的数据交互。中间件TUXEDO，它具有高可靠性，负载平衡等优点，它屏蔽了底层操作系统的复杂性，使程序开发人员变得简单统一，大大减少程序设计的复杂性。客户和服务器之间、服务器和服务器之间的通讯，异构平台之间的数据变换，以及服务器和数据库之间的集成和事务控制都由TUXEDO来完成。数据库后台开发采用PROC C，采用固定模板针对业务逻辑进行数据的转换和处理，把获取的数据传递给TUXEDO，来实现相应的业务逻辑功能。

3.服务器优化

宽厚板MES系统初期使用了两台服务器，由于资金限制只购买了两台服务器，一台运行数据库和应用，另外一台作为测试和开发平台使用。自2007年上线后，随着生产的稳定运行，信息数据量逐步增加，服务器的负荷也越来越大，在使用高峰时CPU使用率为55～78%左右，明显感觉到应用的迟滞不流畅，鉴于这种情况，我们在2010年申请又购置了两台服务器，把应用和数据库彻底分离，新购服务器一台替换原先的测试开发平台，另一台则作为系统数据库备份。分开后的的数据库服务器和应用服务器，其CPU在使用率上没有超过50%，系统运行效率明显得到提高。

4.TUXEDO优化

宽厚板MES系统在运行某些占用时间较长的应用时，多个人同时操作，会出现长时间的等待后，前台画面会报一个“后台程序调用失败”的错误，经过我们分析，原来在中间件TUXEDDO系统中每个服务SERVER默认只启动了一个进程，这样导致当多个请求同时发起时，一些请求会因为超时导致调用失败，查找资料，我们发现服务SERVER可以启动多个进程，假如原来某个SERVER所启动的进程数较少，可适当增加它的进程数，以下所示：

"qmhppsrv"SRVGRP="GROUP4"SRVID=3 MIN=1 MAX=1

RQADDR="qmhppsrv"REPLYQ=Y

改成

"qmhppsrv"SRVGRP="GROUP4"SRVID=3 MIN=1 MAX=4

RQADDR="qmhppsrv"REPLYQ=Y

我们针对使用频度较高的服务SERVER这样更改之后，出现调用失败的几率大大降低。

5.前台程序优化

当数据库结构固定不变的情况下，前台程序操作数据库的优化核心目标是减少数据的返回量，主要措施是限制查询条件来减少返回的数据量。由于系统代码由多人完成，每个人的水平和编程习惯不同，造成我们后期使用中发现大量性能上的问题，对此我们做了大量修正。

比如：没有采取后台分页技术，直接在返回全部数据后再在前台上做分页，这样导致数据库和网络负荷的增加，效率低下，操作时间一般在几十秒以上，通过修改后操作时间基本是原时间的十分之一左右。还有就是经常使用的一些数据字典小表，每次操作都要从后台再获取一遍，效率较低，改动的办法是当进入该UI画面时只获取一次，这样也减少了系统负荷。另外针对一些多个数据表关联，大数据量操作的应用，做了业务拆分，分画面分步骤实现。

总之，前台优化总体把握就是减少数据量的操作和访问的原则，在这个前提下的优化工作基本上难度不大，且效果显著。

6.数据库SQL优化

系统后台程序的优化工作主要是SQL语句的优化，从获取的大量资料来看，SQL语句的优化是数据库最有成效的一个手段，因此SQL语句的影响非常大，系统往往因为一个小的SQL语句不够优化，导致数据库性能急剧下降，应用服务器断连、超时，严重影响业务的正常运行。宽厚板MES系统中发生多次性能危机中，90%都是SQl语句使用不当造成。

这里我们借助使用第三方Oracle工具TOAD，进行系统问题的查找定位，具体方法如下：

首先通过数据库系统性能的监控，定位出现性能危机时的准确时间。

根据时间段通过导出ORACLE的AWR报告，分析其中I/O、CPU占用较高的SQL语句

通过TOAD中执行计划具体分析SQL语句的cost，cost的高低决定数据库执行的效率，cost越小效率越高。

使用ORACLE中SQL优化功能建议，结合实际情况，对后台程序进行优化。

下面列举一些常用的手段和方法。

6.1 建立必要的索引

必须熟悉数据库应用程序中的所有SQL语句，从中分析、归纳出作为Where条件子句的字段及其组合方式；在这一基础上可以初步判断出哪些表的哪些字段应该建立索引，索引对SQL语句的性能会产生举足轻重的影响。

建立索引常用的规则如下：

表的主键、外键必须有索引；

经常与其他表进行连接的表，在连接字段上应该建立索引；

经常出现在Where子句中的字段，特别是大表的字段，应该建立索引；

索引应该建在选择性高的字段上；

索引应该建在小字段上，对于大的文本字段甚至超长字段，不要建索引；

复合索引的建立需要进行仔细分析；尽量考虑用单字段索引代替：

频繁进行数据操作的表，不要建立太多的索引；

删除无用的索引，避免对执行计划造成负面影响；

由于许多索引未建，导致全表扫描，尤其当数据量大时，基本上查询时间需要几分钟左右都不一定完成，所以，建立合适的索引非常重要。

6.2 提高使用索引的效率

虽然建立了索引，但实际编程过程中，不同的SQL语句的写法，会导致索引无效。

避免对列的操作，任何对列的操作都可能导致全表扫描，这里所谓的操作包括数据库函数、计算表达式等等，查询时要尽可能将操作移至等式的右边，甚至去掉函数。

增加查询的范围限制，避免全范围的搜索。从而提高查询效率。

尽量去掉“IN”、“OR”，对含有“N”、“OR”的Where子句常会使用工作表，使索引失效；如果不产生大量重复值，可以考虑把子句拆开；拆开的子句中应该包含索引。然后再做一个简单的加法，与原来的SQL语句相比，查询速度更快。

分解复杂查询，用常量代替变量，对于复杂的Where条件组合，Where中含有多个带索引的字段，考虑用IF语句分情况进行讨论；同时，去掉不必要的外来参数条件，减低复杂度，以便在不同情况下用不同字段上的索引。

like子句尽量前端匹配，因为like参数使用的非常频繁，因此如果能够对like子句使用索引，将很高的提高查询的效率。在做like查询时，应该尽量使查询的匹配端是具体值，例如使用like‘512%’。

应尽量避免在where子句中对字段进行表达式操作，这将导致引擎放弃使用索引而进行全表扫描。

在使用索引字段作为条件时，如果该索引是复合索引，那么必须使用到该索引中的第一个字段作为条件时才能保证系统使用该索引，否则该索引将不会被使用，并且应尽可能的，让字段顺序与索引顺序相一致。

索引并不是越多越好，索引固然可以提高相应的select的效率，但同时也降低了insert及update的效率，因为insert或update时有可能会重建索引，所以怎样建索引需要慎重考虑，视具体情况而定。

任何地方都不要使用select*from t，用具体的字段列表代替“*”，数据的提取速度就会有相应的提升。

尽量避免大事务操作，提高系统并发能力。

以上的方法，是完全可以相互结合同时运用的。而且各种方法之间相互影响，紧密联系。这种联系既存在一致性，也可能带来冲突，当冲突发生时，需要根据实际情况进行选择，没有固定的模式。

7.数据库备份系统

宽厚板MES系统运行到目前已经有6年多了，数据随着时间不断增长，部分数据表的量已达几千万，历史数据的查询使用由于数据量大会直接影响系统的正常稳定运行，原系统没有历史数据导出备份功能，因此，做为优化系统性能重要一部分工作内容，我们自主开发了历史数据导出备份系统，将其中的历史数据，按照合同关系的逻辑，从订单开始到发货结束进行打包归档，减轻在线系统的负荷，目前备份系统已经投入运行。

8.结束语

应用系统的性能调整与优化是一个系统工程，涉及的方面很多，是一个长期不懈、不断比较分析和调整的过程，需要全面系统地规划考虑才能对数据库运行状况做出一个综合评估。只有深入领会和掌握Oracle数据库系统所提供的强大功能，正确观察和分析系统运行中提供的各种信息，充分结合实际应用特点，才能合理制定出良好的优化策略，目前，本系统数据库经过长期的研究开发、推敲测试和调整优化，数据库性能已有较大的提高，较好的满足了本系统众多软件程序的访问使用，本系统数据库表现出了较高的稳定性和较好的使用性能，从而验证了所述采取的若干优化措施是切实可行有效的。

当然存在的问题也不少，有一部分应用由于业务逻辑复杂，优化有一定的难度，光从SQL语句单一优化已经提高不了多少效率，将来只能从业务逻辑拆分，简化分步流程来实现优化的目的。

参考文献

[1]王勇.基于SQL数据库的性能优化问题分析[J].电脑知识与技术，2008，15：1004-1007.

[2]吕华，杜忠军.数据库性能优化[J].计算机应用，2003， 23（06）.

[3]郭卫华，刘卫东.宋佳兴.已有Oracle系统的性能调整优化[J].计算机工程与应用，2001，37（04）.

[4]许平格.数据库管理系统中查询优化的设计和实现[D].杭州：浙江大学计算机科学和技术学院，2005.