项目经验-牛新庄

项目一： 交通银行全国大集中 IBP （国际业务系统）项目 项目简介（功能与用途）：   交通银行自从2002年开始做全国的数据大集中，其中IBP（国际业务系统）项目，是实现交行国际业务中现有的国际结算、贸易融资，外汇管理、以及外汇资金管理服务，覆盖现有的进口，出口，汇款、融资及头寸管理等主要功能，提供总分行各种参数管理，公共控制、公共信息管理、公共业务和打印、查询、报表等辅助服务，同时，IBP系统还提供与大集中核心帐务系统（简称IBS），大集中信贷管理系统（简称CMIS）、环球同业银行金融电讯协会（简称SWIFT），以及外汇管理系统的连接。是整个大集中业务逻辑比较复杂和技术难度比较高的项目，该项目一期由神州数码公司负责程序编码。   项目难点与解决方案：   交通银行IBP（国际业务系统）是国内首个基于J2EE架构纯java的国际结算系统。后台数据库为DB2数据库，中间件为Websphere,MQ,运行在IBM AIX操作系统上，IBP系统采用Browser/Server应用系统架构，利用主流的中间件（Websphere,MQ）系统来接管通讯和交易调度，以达到交易调度的平台化。 该项目的难点主要由以下几点： 1，   由于IBP数据库表结构非常复杂（很多表有几百个字段），而且总行数据大集中后，数据量非常大，所以项目前期合理的数据库的物理设计和后期的性能调优就非常重要。 2，   由于国际业务系统采用报文传输，而且报文的长度非常大，所以数据库中传统的varchar和long varchar数据类型无法满足业务逻辑需求，所以数据库中使用大量大对象（BLOB,CLOB,DBCLOB）数据类型，由于数据库对大对象类型的访问无法通过内存，所以大对象类型的存在直接对数据访问的性能产生影响。 3，   由于并发用户非常多，所以在压力测试期间，数据库中有大量锁等待（lock wait）和死锁（deadlock）和锁升级现象产生，直接影响交易并发。 4，   应用中部分SQL语句比较复杂，而且SQL语句的写法和谓词等方面使用不当，直接造成低效率的SQL运行，占用系统I/O和内存。 5，   数据库中索引构建不合理，存在很多冗余的无用索引，很多应该创建的合理的索引没有构建。 6，   用户希望把个别频繁访问的小表放在内存中长时间运行，如何解决这个技术难题。 7，   如何把应用（J2EE），中间件（Websphere,MQ）,数据库（DB2）,操作系统（AIX）能全局的调优，不至于在某个环节造成全局的瓶颈。   对于上述问题，分别采用了如下解决方案：   1 ，在数据库的设计中，采用 DB2 中的 DMS 表空间，分别把表中的索引（ index ），常规数据（ data ）和大对象（ BLOB,CLOB,DBCLOB ）分割存放在不同的 DMS 表空间中，并且把 DMS 表空间放在 IBM ESS 存储的裸设备（ raw device ）上，这样大大提高了读写（ I/O ）的并行访问，优化了数据访问的速度；另外在缓冲池的设计上，创建了多个缓冲池，分别为索引表空间，数据表空间指定各自的缓冲池，这样可以使它们减少对一个大缓冲池的竞争，从而减少交换（ swapping ）操作，提高从缓冲池命中率（ hit ratio ），提高访问速度。下面是部分数据库设计的脚本： 缓冲池：                        IBMDEFAULTBP          1000      DATA_DMS_4K_BP       128000 INDEX_DMS_4K_BP       76800 INDEX_DMS_8K_BP       12800 BP_DMS_32K_BP         1000 DATA_DMS_8K_BP        25600 BIGTAB_DATA_4K_BP     25600 BIGTAB_INDEX_4K_BP 25600 WFW_DATA_4K_BP       12800 WFW_INDEX_4K_BP      12800 表空间： Name      = SYSCATSPACE Name      = TEMPSPACE1 Name      = USERSPACE1 Name      = LOB_DMS_8K Name      = DATA_DMS_8K Name      = LOB_DMS_4K Name      = DATA_DMS_4K Name      = INDEX_DMS_4K Name      = INDEX_DMS_8K Name      = BIGTAB_DATA_DMS Name      = BIGTAB_INDEX_DMS Name      = WFW_DATA_DMS Name      = WFW_INDEX_DMS Name      = BPBD_DMS_32K Name      = BPBD_32K_SYS_TMP Name      = BPBD_8K_SYS_TMP 同时，由于数据库中存在大量连接（join）,分组（group by）,排序（sort）操作，所以为了提高这些操作的速度，对系统临时表空间所在的文件系统预留了大量文件系统空间。 2 ，在最初的数据库物理设计中，数据库中共有 238 个大对象的字段，这个大对象类型的存在，对系统的性能和 I/O 读写直接带来性能的低下，为了减少这些大字段，和业务人员详细了解了业务需求，避免了无必要的加大大对象的长度，考虑把有些大对象用 varchar 代替（例如：原来长度为 8000 字节的大对象用两个长度为 varchar(4000) 的字段代替，最后对这两个字段再做 concat 的字符合并操作），经过 详细了解和间接的采用一些技术替代大对象后，最后数据库中只有35 个对象，大对象的减少直接带来了I/O 访问速度的提高。 3 ，系统在上线投产前期进行压力测试期间，数据库中有大量死锁和锁等待出现，为了解决上述问题，首先，需要加大相关数据库中有关锁的参数（ locklist,maxlocks,locktimeout 和 dlchktime ）等数据库配置参数；其次，为了让锁的快速释放不至于引起交易阻塞，就需要我们在表上创建合理的索引。所以，造成引起锁等待的应用程序和 SQL 语句，对这样应用和 SQL 进行合理的构建索引。   4 ，应用开发中的很多 SQL 语句运行效率低下，这些 SQL 语句在写法和谓词使用存在很多问题，例如：大量使用 select *,select count(*), 使用 not in ， not exist ，使用函数等，对于这些问题，需要对开发人员详细解释如何高效的使用 SQL ，所以给相关开发人员专门讲解三天的 SQL 使用和如何编写高效的 SQL 。 5 ，应用开发人员往往凭借自己对业务的理解在表上建立了很多索引，结果是这些索引在 SQL 执行期间根本没有使用，这些冗余索引的存在直接导致了空间存储的浪费和对插入 (insert) 操作的影响；所以，正确的做法是我们应该正确的分析该表的读写情况，分析表中 SQL 语句执行的频率，对每一条 SQL 语句做解释（ explain ）从而来评估为该表创建最合理的索引。 6 ，使用缓存（ cache ）表来解决上述问题，该特性是 DB2 数据库新增加的一个特性，要能够合理的把数据库最新的最先进的技术运用到我们的数据库设计中。 7 ，调整操作系统交换空间（ page space ） , 内核参数；调整数据库配置参数；合理的设置 websphere 的相关和数据库的接口配置，调整应用性能；最后用压力测试软件来找出引起性能的瓶颈并解决各个层面的瓶颈。 项目成功与失败的经验归纳：   IBP项目已经在2004.7.14日杭州第一家正式上线，上线近两年来，系统非常稳定和高效的运行，IBP项目的成功经验有以下几点：   1，   数据库前期的合理的架构设计（物理设计和逻辑设计）是整个项目成败的关键，合理的架构设计为整个项目稳定可靠高效运行打下了良好的基础，同时也起到了事半功倍的作用。 2，   根据系统的物理资源，对数据库的配置参数做合理的调整，保证系统物理资源（CPU,I/O ，内存和网络）和逻辑资源（裸设备，文件系统等）合理的分布和应用。 3，   在应用层，要保证编程人员编写高效的SQL ，通过对相关编程人员专门的进行SQL 培训，培养他们养成良好的编写高效SQL 的习惯；对编程人员讲解SQL 执行的原理和步骤，教会他们如何使用相关解释工具（explain ）来对SQL 进行分析解释从而来选择最合理的执行计划（access plan ）。 4，   要学会充分运用数据库中最新的数据库技术运用到实际的编程应用中（例如：DB2 V8 中的缓存表等技术）。 5，   要结合不同的数据库产品，在保证业务逻辑允许的情况下，使用合理的隔离级别（例如：UR 隔离级别）来最大程度上提高数据库的并发。 6，   对数据库创建最合理的索引（太多，影响insert 速度，浪费存储；太少，不能显著提高查询速度），尽量的多创建复合索引和包含（include ）索引。   你在项目中岗位与贡献： 负责完成交通银行IBP国际业务系统的整体数据库物理设计和逻辑设计；负责完成数据库后期的性能监控，性能调优；负责培训编程人员如何编写高效的SQL，从而使整体应用运行效率提高；负责构建数据库的索引并删除冗余的索引；负责制定IBP项目的备份和恢复策略；负责制定IBP项目的安全策略；负责培训交通银行全国各分行技术人员。

 

项目二： 梅州农信综合业务系统项目 项目简介（功能与用途）： 梅州农村信用社综合业务系统是梅州农信投资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 ；负责构建数据库的索引并删除冗余的索引。

 

 

项目三： 湖南移动业务运营支撑（ BOSS ）系统 项目简介（功能与用途）： 湖南移动通信公司业务运营支持系统（BOSS SYSTEM）系统是整合营业、计费、结算、账务、收费等业务，实现"以客户为中心、业务的开发和管理面向客户、网络管理面向业务"的运营原则，大大提高企业的营销和服务水平的核心业务支撑系统。 项目难点与解决方案：   BOSS系统从2003年初开始陆续上线，营帐系统在上线运行后出现性能问题。主要表现在对最终用户的交互响应不如预期，尤其在业务繁忙时更是无法得到及时的交互响应。从主机（AIX）系统上观察，主要表现在系统的I/O等待较大。营帐系统是由业务应用程序，Oracle数据库，AIX主机，IBM ESS存储多个部分组成，因此性能瓶颈的定位和性能的优化都比较复杂。 该项目的难点主要由以下几点： 1， 湖南移动通信BOSS SYSTEM 系统是一个大型的复杂系统。在这个系统中从上至下包括以下几个层次：应用程序、数据库、主机系统（操作系统）、SAN 网络和ESS 存储系统。在发生系统的性能问题时，性能问题的定位和调优就很复杂。 2， 数据库容量大，整个数据容量有约2120GB ，整个数据的迁移需要几十个小时的时间，而在生产系统上是不允许有很长的停机时间进行数据迁移。 3， 湖南移动BOSS 系统是7 ×24 的应用，不允许停机。 4， 应用中部分SQL 语句非常复杂，而且SQL 语句的写法和谓词等方面使用不当，直接造成低效率的SQL 运行，占用系统I/O 和内存，需要找出这些SQL 语句并对之进行调整。 5， 需要对Oracle 数据库部分参数作出调整。 6， 需要对操作系统内核参数作出调整。 7， 需要对数据库的数据在ESS 存储上的物理分布重新调整。   对于上述问题，分别采用了如下解决方案： 1 ，针对湖南移动BOSS SYSTEM系统出现的性能问题，根据湖南移动BOSS SYSTEM系统的实际应用, 借助ESS Expert和Precise等性能监测工具软件，对主机系统和存储进行了监控，调整和优化，同时对Oracle数据库和应用系统提出调优建议。 项目分为以下几个阶段： ·         检查BOSS SYSTEM系统中所有硬件系统，特别是SAN网络中的硬件。 ·         检查SAN交换机的数据流量，观察是否有通道流量不对称、数据包丢失或数据传输过程中有效验错的问题。 ·         分析ESS上的数据分布，安装和配置ESS Expert监测软件，观察是否存在有FC通道、cluster、SSA卡或SSA loop负载不平均的现象。 ·         检查并优化主机系统上AIX运行的参数，使之适合SYSTEM系统的运行。 ·         安装和配置Precise Indepth for Oracle软件，检查ORACLE数据库的参数设置，确定最影响性能的应用程序，协助软件开发商优化应用程序。 ·         两次调整在ESS存储系统上的数据分布，并通过StorWatch EXPERT软件监测ESS存储系统的性能表现； ·         利用Precise软件监测数据库和应用对系统资源的占用，对主机系统作进一步的调优，并提出对Oracle 数据库和应用程序的调优建议； ·         性能瓶颈的定位 一般的调优策略如下： 在湖南移动的调优中，在数据库的设计和应用设计不做更改的前提下，首先，对IBM存储系统和主机系统作深入细致的参数和配置调整。同时，在湖南移动计费中心技术人员的全力配合下，对ESS存储系统上的数据分布作了大规模的调整，并且通过Precise软件对Oracle数据库性能参数的监控，定位对系统CPU, I/O等资源消耗严重的瓶颈，对Oracle数据库和应用系统提出性能调优建议。 2 ，针对应用的性能状况，修改Oracle的性能参数。 ü             cursor_sharing的值从exact改为force, 减少internal lock wait. ü             spin_count的值从2000调整到5000。 ·         根据Precise的监测和分析结果，检查资源消耗最大SQL语句的逻辑设计，将排名靠前SQL语句的表数据与索引分别存储，建立合适的分区索引，提高资源消耗靠前SQL语句的并行度。 ·         通过StorWatch Expert软件持续监控ESS的使用，掌握ESS的性能表现和使用状况。 ·         通过Precise软件对Oracle和应用有限数据的分析，确定当前应用系统并没有达到理想的运行状态，建议对应用系统作相应的检查和调整。同时，为了更准确定位应用问题所在，建议收集更长时间的数据，再进行更深入的分析。 3 ， 调整数据在 ESS 上的分布。 首先将数据平均地分布在两个cluster上，之后将数据分布在尽可能多的通道上。 由于整个数据容量有约2120GB，整个数据的迁移需要几十个小时的时间，而在生产系统上是不允许有很长的停机时间进行数据迁移。 根据多个方案的论证对比，决定采用逻辑卷镜像的方案实施数据迁移。具体的步骤是先将所有的逻辑卷在目的的硬盘上建立镜像、同步数据、再将原硬盘上的镜像部分删除。整个数据迁移工作全部在系统的后台进行，共进行了60个小时，完成所有数据迁移。   4 ，对操作系统内核参数作出调整 ·         对 vmtune 的参数进行调整如下： -p       -P        -r          -R         -f       -F       -N        -W minperm maxperm minpgahead maxpgahead minfree maxfree pd_npages maxrandwrt  396414   792828       0          0        960     1024      65536        1  -M      -w      -k      -c        -b         -B           -u        -l    -d maxpin npswarn npskill numclust numfsbufs hd_pbuf_cnt lvm_bufcnt lrubucket defps 3250555   65536   16384      16    2048       2656          9      131072     1         -s              -n         -S         -L          -g           -h sync_release_ilock nokilluid v_pinshm lgpg_regions lgpg_size strict_maxperm         1               0           0           0            0        0     -t           -j              -J               -z maxclient j2_nPagesPer j2_maxRandomWrite j2_nRandomCluster  792828           32            0                  0     -Z                  -q                    -Q                -y j2_nBufferPer j2_minPageReadAhead j2_maxPageReadAhead   memory_affinity       512              2                    8                 0     -V                  -i num_spec_dataseg spec_dataseg_int       0                512 PTA balance threshold percentage = 50.0% number of valid memory pages = 4063193 maxperm=20.0% of real memory maximum pinable=80.0% of real memory    minperm=10.0% of real memory number of file memory pages = 1955960   numperm=49.3% of real memory number of compressed memory pages = 0   compressed=0.0% of real memory number of client memory pages = 0       numclient=0.0% of real memory # of remote pgs sched-pageout = 0       maxclient=20.0% of real memory ·         对 schedtune 参数的调整如下： THRASH           SUSP       FORK             SCHED -h    -p    -m      -w    -e      -f       -d       -r        -t       -s SYS PROC MULTI   WAIT GRACE   TICKS   SCHED_D SCHED_R TIMESLICE MAXSPIN  0   4     2        1      2      10       16       16         1      8192    CLOCK   SCHED_FIFO2   IDLE MIGRATION   FIXED_PRI    -c          -a            -b              -F %usDELTA   AFFINITY_LIM BARRIER/16       GLOBAL(1)  100           7             4               0 红色的为要调整的值。  5 ，检查资源消耗最大语句的逻辑设计。 l         建立合适的分区索引 l         将排名靠前语句的表数据与索引分别存储。 l         提高资源消耗靠前语句的并行度。 l         Oracle 的参数cursor_sharing设为force减少internal lock wait l         调整Latch的数量(如DB_BLOCK_LRU_LATCHES)或内存的一些参数(如SHARED_POOL_SIZE等)解决内部锁问题。 6 ， 由于数据存储调整后，系统I/O性能状况良好，系统和存储端的性能表现已调整至最佳，系统和存储端的性能调优工作已经完成。建议客户下一步的工作重点是解决应用系统的性能瓶颈，结合Precise对应用的监控结果，检查应用的逻辑设计，数据索引的建立和分布。协助应用开发商修改应用。 7 ，调整操作系统交换空间（ page space ）。   项目成功与失败的经验归纳： 在湖南移动BOSS系统的性能调优中，项目的成功经验有以下几点： 1．  数据库前期的合理的架构设计（物理设计和逻辑设计）是整个项目成败的关键，合理的架构设计为整个项目稳定可靠高效运行打下了良好的基础，同时也起到了事半功倍的作用。在湖南移动BOSS系统中就是因为数据库在ESS物理存储的不合理分布而直接导致了系统的I/O瓶颈。 2．  根据系统的物理资源，对数据库的配置参数和操作系统内核参数做合理的调整，保证系统物理资源（CPU,I/O，内存和网络）和逻辑资源（裸设备，文件系统等）合理的分布和应用。 3．  要善于借助于第三方的监控软件（如：StorWatch Expert和Precise软件），这些软件的运用可以快速的定位性能瓶颈从而更快速的作出性能调整。 4．  检查资源消耗最大SQL语句的逻辑设计，将排名靠前SQL语句的表数据与索引分别存储，建立合适的分区索引，提高资源消耗靠前SQL语句的并行度。很多性能瓶颈往往是由于“恶劣”的SQL造成的。 5．  要有一个很好的性能调整流程和性能调整方法步骤，循序渐进，一步一步定位，逐步缩小范围，知道最后定位性能瓶颈。 6．  要善于团队合作，在整个性能调整中，我负责软件调整，要和硬件调整，网络调整的技术人员通力合作。 7．  性能调整是全局的工作，涉及应用开发，中间件，数据库，操作系统，存储，网络等。需要对全局的信息架构有清晰的认识。 你在项目中岗位与贡献： 在湖南移动BOSS系统的性能调整中，我是以IBM技术顾问身份参与性能调整的，主要负责对Oracle数据库配置参数的调整；负责完成数据库后期的性能监控，性能调优；负责检查资源消耗最大SQL语句的逻辑设计，将排名靠前SQL语句的表数据与索引分别存储，建立合适的分区索引，提高资源消耗靠前SQL语句的并行度。负责在操作系统层面定位性能瓶颈（CPU,内存，I/O和网络瓶颈）并调整操作系统内核参数。负责协助开发人员对应用开发作出修改和SQL性能调整。

 

项目四： 江苏电力公司负控系统 项目简介（功能与用途）： 江苏电力公司电力负荷管理及用电监控（简称负控系统）系统是为了解决了近年来江苏的“电荒”而上线的一个电力调度系统。通过负控系统可以合理进行电力的调度从而最大程度上保证企业和用户的用电。 项目难点与解决方案： 江苏电力公司负控系统后台数据库为 DB2 数据库，中间件为 IBM CICS 交易中间件 , 运行在 IBM AIX 操作系统上，前台采用 VB 和 C 开发。 该项目的难点主要由以下几点： 1，  系统上线的时间非常紧迫，限期在江苏17 个地市上线，这就是说要确保每次每个地方上线都要成功不能失败。 2，  由于采用了IBM 的交易中间件CICS ，这就需要在应用，数据库和CICS 之间合理的调整相关配置参数，确保系统运行性能。 3，  在白天高峰期间，交易并发多，数据库性能不好。 4，  应用中部分SQL 语句比较复杂，而且SQL 语句的写法和谓词等方面使用不当，直接造成低效率的SQL 运行，占用系统I/O 和内存。 5，  各地市使用的DB2 的版本（DB2 V5,DB2 V6,DB2 V7,DB2 V8 ）不一致，使用的操作系统（AIX 4.3.3 ，AIX 5L ，AIX 5.2 ）版本也不一致，使用的CICS 版本（CICS 4.3,CICS 5.0,CICS 5.1 ）也不一致；这需要在有限的时间内在不同的版本上做调试并且只能成功。 6，  负控系统关联营销系统和调度系统并且在同一台主机上工作，所以上线需要和相关部门和省电力公司协调，必须确保不能影响别的业务系统，必须保证首先不能因为负控系统不能上线而影响别的系统，其次保证负控系统上线后不能因为应用对资源的占用而影响其它系统。 对于上述问题，分别采用了如下解决方案：   1，             CICS版本做充分的测试，确保应用万无一失。 在应用开发期间，对不同的数据库版本，不同的操作系统版本和不同的 2，             locklist,maxlocks,locktimeout和dlchktime）等数据库配置参数；其次，为了让锁的快速释放不至于引起交易阻塞，就需要我们在表上创建合理的索引。所以，造成引起锁等待的应用程序和SQL语句，对这样应用和SQL进行合理的构建索引。在业务逻辑允许的情况下，尽量使用UR(uncommit read)的隔离级别来提高读并发。 对于负控系统白天并发期间产生的大量锁现象，首先，需要加大相关数据库中有关锁的参数（ 3，             SQL语句，利用DB2监控工具（事件监视器）找出这些SQL语句并作出解释分析判断SQL语句的瓶颈，对于这些问题，对开发人员详细解释如何高效的使用SQL，协助开发人员修改应用。 对于应用开发中的很多运行效率低下 4，             CICS的接口，CICS和数据库的XA接口，在业务逻辑满足的情况下，尽量采用一阶段提交（1pc）,因为1pc的运行性能要比两阶段提交好。 对于应用程序和 5，             DB2的数据库性能调整中，详细评估系统中可以使用的资源和系统最大可能占用的资源，逐步调整数据库的配置参数并进一步监控调整的结果。 因为负控系统和营销系统，调度系统运行在同一台机器上，所以在进行 项目成功与失败的经验归纳： 江苏电力公司负控系统从2004.4 月首先在无锡上线到2004 年11 月在南通最后上线，整个系统上线期间如履薄冰，如临深渊。现在系统已经稳定运行近两年，负控系统的成功经验有以下几点： 1，               需要对企业信息架构有全局的了解，因为现在企业信息架构非常复杂，往往涉及到的不只是数据库，还有操作系统，中间件，应用，存储等，所以需要对信息架构全局有很全面的了解，这就需要不断的学习和更新新的技术。这次我们在负控系统上线期间，因为时间紧迫（一个地市只有一晚上将近10 小时时间），在这么短的时间内，很难保证很顺利的上线，如果出现问题，一定要快速的定位是在什么层面（操作系统，数据库，中间件，应用，存储等）出现的问题然后快速解决之，所以必须具备全局的对信息架构的驾驭能力。 2，               和相关业务部门的沟通和协调非常关键，很多时候我们需要他们配合才能完成相关工作，所以交流和沟通是非常关键的。国内很多垄断部门的员工往往非常牛，这就需要我们耐心的，不厌其烦的去和他们做好沟通和协调。这一点对负控系统的按时上线也非常关键。 3，               在企业内部，往往可能存在很多不同版本的数据库，操作系统，CICS 和应用版本，他们之间的兼容性非常关键。我们曾经碰到很多DB2 V8 客户端无法访问DB2 V7 服务器的情况，也碰到很多DB2 V7 客户端访问DB2 V8 服务器时出现实例crash 的现象。同样还有很多操作系统版本和CICS 版本不一致所带来的问题。这就需要我们详细了解数据库，CICS ，应用和操作系统之间的兼容性问题。 4，               在部分地市，由于使用了最新的DB2 版本，发现上线后有很多问题，后来经过问题诊断和咨询IBM ，发现是DB2 新版本bug 的问题，所以企业在使用相关软件的时候，最好不要用最新的版本而要用相对稳定的版本。 5，               在进行数据库的配置参数调整时，一定详细了解系统的物理资源和逻辑资源，以及目前系统中已经在运行的系统和应用，确保新上线的应用不影响已有的应用。 6，               要结合不同的数据库产品，在保证业务逻辑允许的情况下，使用正确的隔离级别（UR ）和CICS 的一阶段提交来最大程度上提高数据库的并发和应用的性能。   你在项目中岗位与贡献： 负责完成江苏电力公司负控系统在17 地市的上线；负责完成负控系统数据库后期的性能监控，性能调优；负责培训编程人员如何编写高效的SQL ，从而使整体应用运行效率提高；负责构建数据库的索引并删除冗余的索引；负责负控系统的数据移植；负责协调上线期间和业务部门的交流沟通；负责负控系统后期的数据库维护和技术支持。

 

项目五： 乌鲁木齐商业银行综合业务系统 项目简介（功能与用途）： 乌鲁木齐商业银行银行综合业务系统是商行的核心系统，负责处理金卡工程、电话银行、网上银行、POS、ATM 及各种自助终端，该系统稳定运行保证了联机交易和批量处理能力的可靠性和高可用性，大大地简化了业务操作，为完善乌鲁木齐商业银行的信息决策管理体系，为提高各业务部门的风险控制和科学管理水平提供了必要的保障。   项目难点与解决方案：   乌鲁木齐商业银行数据库在2003-08-13日出现系统故障，造成银行综合业务系统停机，影响了业务的正常进行，造成了经济损失和不良的社会影响。乌鲁木齐商业银行后台采用DB2数据库，运行在IBM AIX平台上，使用IBM CICS交易中间件，前台采用嵌入C编程。   该项目的难点主要由以下几点：   1，  由于系统宕机后，为了保证系统快速启动，相关的CICS日志未能保存，这给后续的问题诊断带来的困难。 2，  由于该系统涉及到应用开发商（中联），系统集成商，系统维护商和客户，所以在进行问题诊断时，大家莫衷一是，都相互推诿责任，这对准确的定位带来了困难。 3，  客户使用的DB2版本很老（DB2 V6），IBM已经停止技术支持和补丁更新。 4，  客户的应用程序编写人员已经离开应用开发商公司，这给程序的更改带来很大困难。 5，  客户希望能够快速定位问题所在，并且杜绝这种问题的重现。   对于上述问题，分别采用了如下解决方案：   1，  仔细查看操作系统日志，数据库诊断日志和 CICS 的部分日志，仔细的定位问题所在，并且详细询问客户相关技术人员在系统宕机前都做了哪些操作。 2，  协调应用开发商，系统集成商和系统维护商，大家群策群力共同定位问题所在，应用开发商负责联系以前的编程人员，了解程序。系统集成商和系统维护商在测试机上搭建模拟环境，争取在模拟环境中能够把问题重现。 3， 经过诊断发现是CICS 编程中调用了C 的malloc() 函数而引起的，这需要协助开发商修改程序。 4， 引起系统宕机的诱因是在白天做tar 磁带的操作，由于tar 磁带导致AIX 系统文件内存使用完，CICS 程序无法获取所需的资源从而导致业务系统宕机。 5， 调整AIX 的内核参数，调整文件内存和计算内存的页面替换算法所关联的vmtune 所对应的maxperm ，minperm 和maxclient 参数。 项目成功与失败的经验归纳： 通过对乌鲁木齐商业银行业务系统的宕机做问题诊断，得出以下几点经验：   1，  用户是希望能够解决问题并保证系统的稳定运行，这需要应用开发商，系统集成商和系统维护商能够通力合作共同找出问题并解决之而不是相互推卸责任。 2，  要保存好相关操作系统，CICS和数据库的诊断日志以保证系统在出现故障时准确定位，为客户编写脚本自动在机器宕机时候保存相关诊断日志。 3，  与客户相关技术人员详细沟通，沟通系统宕机前所做的操作，这一点非常重要。 4，  不但要定位问题，而且一定要有解决该问题的方法，避免该问题重现，所以必须指导相关开发人员修改程序，这需要我们具备良好的编程基础。 5，  告诫客户技术人员不要在高峰期间做compress，tar和大文件的ftp操作。 6，  在做问题诊断时，必须具备全局的操作系统，数据库，中间件和应用编程技术。这就需要我们要拓宽知识面，不断补充和学习新的技术。   你在项目中岗位与贡献： 在该项目中，我主要是客户所请的顾问，代表客户负责定位诊断引起系统停机的主要原因；负责协调应用开发商修改程序，系统集成商和系统维护商搭建模拟测试环境；负责调整相关操作系统内核参数；在找出问题的原因后负责协助开发人员修改程序并在测试系统上模拟测试并确保稳定可靠运行。

 

 

 

项目六： 海口美兰机场离港系统 项目简介（功能与用途）： 海口美兰机场离港系统（Departure Control System 简称DCS）主要提供办理登机、航班控制和配载平衡三大功能。离港系统是机场和旅客直接接触最主要的系统之一，牵涉到旅客办理登机手续、行李托运等各个环节。   项目难点与解决方案： 海口美兰机场离港系统（Departure Control System 简称DCS）后台数据库为DB2数据库，双机热备软件HACMP,网管软件为Netview，运行在IBM AIX操作系统上，前台采用Delphi开发。 该项目的难点主要由以下几点： 海口美兰机场离港系统（Departure Control System 简称DCS）是我参与开发的软件，该系统在2001年四月份上线后先后出现的性能问题。为此需要对数据库配置参数作出调整。 对于上述问题，分别采用了如下解决方案：     在 2001 年五月一日早上 8:30 左右，由于离港系统数据库运行性能非常低下，我决定对数据库配置参数作出调整，于是我在没有详细考虑的情况下，对 DB2 数据库的相关配置参数作出了等于原来 10 倍的调整，数据库配置参数生效后，大概在 8:33 分左右，离港系统小型机宕机，直接造成了从早上 8:33 分到 9:40 分这将近一小时的停机，直接影响了旅客的登机，办理值机手续，广播，电话和航显，造成了很大的影响。 项目成功与失败的经验归纳： 从这次失败的的经过中，我得到如下经验：   1，               系统（操作系统，数据库，中间件，应用）性能调整需要循序渐进，不可一蹴而就。 2，               调整相关配置参数时，需要对该配置参数有深刻的理解，当然这需要不断的补充理论知识。 3，               在性能调整时，要做好系统备份和数据库备份，要胆大心细，小心谨慎。 4，               在数据库配置调整时，一定要有最坏的打算，做好失败冗余和恢复方案。 5，               不可完全相信所谓的经验法则，那只是提供一种参考，我就是看了书上说的把缓冲池调整为系统内存的70％这条经验法则才间接导致系统停机的。 6，               在系统运行高峰期间，如果能够忍受，尽量保持系统的平衡稳定运行，否则可以尝试先在备机或测试机上调整。 7，               要不断的认真总结经验，积累。 8，               要把在书上看到的理论和在实践中碰到的实际问题结合起来。 你在项目中岗位与贡献： 失败的经验是一种宝贵的财富，它对我后期从事性能调整产生了很深远的影响，所以有时候要好好的总结失败并从中汲取经验教训。