对于上述问题，分别采用了如下解决方案：

　　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带库中并定期做恢复的模拟演练。