一个问题项目的拯救过程

一个问题项目的拯救过程
【IT168技术分析评论】
　　梅州农村信用社综合业务系统是梅州农信投资2000多万实施的一个电子商务系统，梅州农信综合业务系统的实施，将实现梅州农信现有业务的电子化网络联接， 并把梅州农信的综合业务系统建成为梅州银行业领先的综合业务系统，为提高梅州农信的竞争能力和业务经营决策及科学管理的水平做出积极贡献，并能够利用信息 技术为客户提供金融服务和帐务管理，尽快实现网络综合业务系统。
　　项目难点与解决方案：
        梅州农信综合业务系统后台数据库为DB2数据库，前台应用采用java开发,运行在IBM AIX操作系统上。
　　该项目的难点和存在的问题主要由以下几点：
　　1 由于国内的银行核心业务系统后台核心大多采用c或c++开发，而梅州农信综合业务系统后台采用java开发，而java应用开发不太适合做银行后 台的核心交易处理，而且java比较占用内存资源，所以该项目难点是在整体架构设计不能改变的情况下，注定了后续的工作只能是“打补丁”的工作。
　　2 数据库架构不合理，数据库的物理设计和逻辑设计不合理，需要做数据迁移。
　　3 数据库做并发交易非常慢。
　　4 数据库装载数据和数据移植慢。
　　5 晚上做批处理的处理时间太长。
　　6 报表查询时间太长，无法满足实际业务需求。
　　7 数据库安全规划不合理，存在安全隐患。
　　8 数据库备份和恢复策略不合理。
　　对于上述问题，分别采用了如下解决方案：
　　1  由于前台应用采用java开发，java应用开发不太适合做银行后台的核心交易处理，而且java比较占用内存资源，针对java比较占用内存资源的情况，需要对应用作出优化，尤其需要在应用中对java的内存使用进行垃圾回收。
　　2  梅州农信综合业务系统数据库架构设计不合理，数据库设计采用了SMS表空间，而且表中索引，常规数据和大对象数据没有分割存放;SMS表空间采用目 录方式访问，并且使用大量操作系统调用(system call),读写效率低下。所以为了保证数据库高性能并发I/O，需要对原有的数据库进行重新物理架构设计并对现有数据进行数据迁移。
　　3  梅州农信综合业务系统在上线初期，数据库的并发非常慢，数据库中经常存在锁表的现象，有大量的死锁(deadlock)，锁等待(lock wait)和锁升级(lock escation)出现，为了解决这些问题，采用了如下解决方案：一是首先调整数据库中和锁相关的配置参数 (locklist,maxlocks,dlchktime)等参数，其次是找出系统是哪些应用和SQL长时间的持有锁，对这些应用和SQL作出调整。
　　4  梅州农信综合业务系统在上线初期，需要对以往的历史数据进行移植和装载到新的数据库中，在初期他们采用了import方式来进行数据移植和装载数 据;在DB2数据库中有import和load两种数据入库方式，import的方式是非常慢的，所以采用import方式根本无法定期按时上线。为此， 重新用load编写移植脚本，这样保证了系统定期按时上线。所以，一定要采用数据库中最合理的技术来进行相应的操作。
　　5  系统在上线初期，每天晚上做批处理的时间特别长(大概7个小时)左右，这是不合理的，对批处理进行监控发现批处理中存在很多对数据库的大表的 delete操作;指导应用开发人员在开发中用load的API函数来代替delete，因为直接delete会产生很多日志和锁，删除速度慢并且容易出 现表的“碎片”。经过上述调整后，批处理时间减少为3小时左右。
　　6  在每天晚上的报表处理时候，报表处理速度非常慢，往往处理一张报表需要几个小时，经过分析发现报表的SQL语句非常复杂，这些SQL语句一是没有经 过调优，运行效率低下;二是对这条复杂的SQL语句没有创建最合理的索引。经过调优SQL和创建索引后，报表的速度减少为几分钟。
　　7  梅州农信综合业务系统上线后，数据库安全和操作系统安全都是缺省的设置，没有经过合理的安全规划，存在严重的安全隐患。为此，对相关用户进行角色划 分并进行合理的权限分配，同时对每一个用户进行安全的审查(audit)工作，这样保证了系统安全可靠的运行。
　　8  梅州农信综合业务系统上线后，数据库没有一个很好的安全和备份策略，这样存在很大的数据丢失风险。根据梅州农信数据库特点，编写相关脚本，每天晚上 对数据库做批前备份和批后备份，并把备份好的数据库和数据库日志tar到IBM 3583带库中并定期做恢复的模拟演练。
　　项目成功与失败的经验归纳：
　　梅州农信综合业务系统从2002年开始实施到2003年系统上线，系统虽然现在稳定的运行，不过项目中出现的一些问题还是值得后续项目深思的。
　　1.业务系统前期的选型和架构设计是非常关键的，这是一个方向性的问题，成功的选型和架构设计是成功的一半，由于梅州农信选用了java平台，而java 应用开发不太适合银行业务系统后台核心帐务处理，这直接导致了运行效率的低下和对资源的消耗，如果前期他们有一个很好的高级数据库架构设计工程师也许可以 避免这些问题的出现。
　　2.应用编程人员需要对业务需求有详细的了解，应该充分做好前期的业务需求分析，在梅州农信综合业务系统中经常出现很多由于前期业务需求没有做好而导致后 期重新“返工”现象，这直接影响了项目的按时上线。所以，编程人员和数据库工程师需要对企业的业务需求有更详尽的了解和分析。
　　3.需要一个全面数据库人才来做数据库的物理设计和逻辑设计，梅州农信由于前期数据库物理设计和逻辑设计不合理，导致系统未能充分的利用物理资源和逻辑资源，所以后期需要对数据库重新做架构设计，而这些需要做数据迁移，这无疑增加了系统的风险性。
　　4.由于前期的架构设计和选型不当，直接导致了后续的工作只能是“打补丁”的工作，这些导致了后续项目的被动性以及和其它银行系统和新上线系统的兼容性。
　　5.应该为企业信息系统制定合理的安全规范以消除潜在的安全隐患。
　　6.需要为企业的信息系统制定一个合理的备份恢复和灾备策略。
　　 总结：由于梅州农信综合业务系统的前期我并没有参加，所以在整个项目的后期出项性能问题的时候，我主要在现在的架构和选型上保证业务系统能够安全，可靠，稳定的 运行。主要负责完成梅州农信综合业务系统历史数据移植;负责完成梅州农信综合业务系统的数据库性能监控，性能调优;负责制定梅州农信数据库安全策略;负责 制定信息系统的备份和恢复策略，负责制定信息系统的异地灾难备份策略;负责完成原有的数据库的重新物理设计和数据迁移工作;负责指导编程人员编写高效的 SQL;负责构建数据库的索引并删除冗余的索引。