用友股份-LE服务支持部技术方案--《NC技术问题解决之效率问题》建立日期：2013-01-01修改日期：xxxx-xx-xx文档属性：客户文控编号：LE-DY-JS-2013-00042/37文档控制创建记录审阅人姓名所属部门职位审阅签字发布人姓名所属部门发布时间日期作者所属部门邮件地址版本2013-01-01V1.03目录1.入库调整单批次号参照效率问题............................................................................42.NC系统运行缓慢，表“SO_SQUARE_B”，“SO_ACCOUNTMNY”常被锁死.......43.二次开发异步处理导致的问题................................................................................74.总账模块查询多个辅助余额的bug问题.................................................................85.ORACLE驱动问题.....................................................................................................96.ORACLE11g的统计信息问题..................................................................................107.重建索引解决效率问题..........................................................................................128.单据查询效率慢.....................................................................................................159.客商档案效率优化................................................................................................1510.数据库CPU100%技术问题解决案例...................................................................2011.报表查询效率优化案例.......................................................................................3441.入库调整单批次号参照效率问题系统环境：nc56、Oracle10g问题描述：在自制入库调整单时启用批次管理的存货需要输入批次号，但是不管是点放大镜选择批次号还是手输批次号效率都很低，每次都卡住在那要等待很长时间，点放大镜选择批次号时发现显示出来的批次号非常多，包括早期已经没有库存的批次号检查分析：NMC监控可知该操作主要为SQL效率低下，通过执行计划可知IA_BILL_B表CINVENTORYID字段缺少索引，添加索引解决；解决方法：createindexIA_BILL_B_JSZC_01ONIA_BILL_B(CINVENTORYID)nologging2.NC系统运行缓慢，表“SO_SQUARE_B”，“SO_ACCOUNTMNY”常被锁死系统环境：Oracle10.2.0.1问题描述：该用户在使用过程中出现的两个核心的问题是月结中操作非常缓慢甚至无法进行。直接的原因是数据库死锁导致，锁死的表为“SO_SQUARE_B”，“SO_ACCOUNTMNY”导致死锁的原因很可能是操作执行过于冗长，占用表时间过长导致。例如：“发票审核”操作的后台监控结果见下图5该操作已经执行了40501条SQL，总执行时间10363秒（两个半小时），但平均每条SQL执行时间不到1秒，可见从执行效率上看，每条语句的执行效率不存在大问题，但是该功能调用如此多的SQL（到此时执行还未结束），是否正常还需要开发此业务的部门进行确认。类似该现象的还有操作“做出库单签字”：6该操作执行了非常多的update语句，每组执行800条，执行了30多组，每次执行都需要执行45s左右，导致总的操作需要20分钟，该问题需要开发此业务的部门进行确认。以上可见在月结过程中会有多人来做如上的操作导致占用大量的CPU资源和引发很高的磁盘IO，如下图7解决方法：1、对于业务操作是否正常还需要业务开发部门进行确认2、可将数据库从oracle10.2.0.1升级至10.2.0.4，可避免一些已知的性能问题和BUG3、可调整数据库运行参数将SGA从目前的7G调整为10G，可小幅提升性能3.二次开发异步处理导致的问题系统环境:NC502问题描述：输入条件查询，反复点“查询”按钮，窗体“假死”，无法继续操作检查分析：1、一个用户营业厅的客户反馈，其中的一台机器没有出现过这个问题，其余的机器都出现过这个问题,该功能节点做过2次开发2、没有出现问题的机器是台新PC，我查看配置是双核，4g内存3、最终确认客户二次开发部分设计到异步操作，怀疑是多线程应用造成的问题解决方法：取消此处的异步处理操作。结论：最终问题是异步处理造成客户端线程锁引起的问题84.总账模块查询多个辅助余额的bug问题问题描述：应用服务器和数据库服务器为同一台机器，客户反映目前服务器CPU使用率100%，客户服务器16核，每个CPU都是100%的状态，其中java进程占CPU99%以上检查分析：1、考虑到CPU主要是由java进程耗费，打开NMC监控工具2、发现存在多个耗时特别久的线程，该种情况通常多数由网络原因造成，而该服务器同时为应用服务器和数据库服务器，不存在网络问题3、查看远程调用方法，基本上所有的耗时线程都是同一个类的同一个方法，而线程的当前事件为endreadresults事件，表示后台无sql执行，应该是数据返回后，前台存在死循环之类的问题4、查看线程堆栈，所有线程堆栈相同，拷贝其中一个线程堆栈给开发人员看，开发人员反馈为程序bug9解决方法：开发人员出补丁解决。5.ORACLE驱动问题问题描述：系统迁移到新服务器后，正式环境使用WAS集群，某操作异常，现场使用NC中间件正常检查分析：首先使用NMC录制前后台日志，并无异常信息，后调整后台日志模式，分析后台日志发现如上页异常信息，通过分析报错可知为数据库驱动问题。10解决方法：改用中间件驱动正常问题收获：该问题在NC正常，WAS不正常，表名看起来像是中间件问题，实则不然，其根本原因为NC中间件使用的数据库驱动和WAS下的数据库驱动不一致。NC中间件使用Oracle驱动包在lib文件夹下，而WAS使用驱动包在DRIVER目录下。该问题通过NMC录制日志并无异常信息，可见并不能完全依赖NMC录制日志功能6.ORACLE11g的统计信息问题问题描述：据顾问反映，有两个操作最近突然变慢，而正式库导出的数据搭建的测试库则无此问题检查分析：使用NMC工具，定位到SQL，执行该SQL，速度特别快，而且该SQL不包含临时表。但该SQL在后台一直执行，速度较慢。通过查询该SQLID，添加绑定变量参数后，获取到两个不同的执行计划，其中一条很慢11注意执行计划的最下面包含了一行信息12-cardinalityfeedbackusedforthisstatement如图所示，cardinalityfeedback是oracle11g的新特性，默认开启，但该特性有可能会导致系统效率低下，可以关闭。解决方法：关闭此特性，方式如下：Disablecardinalityfeedback,set_optimizer_use_feedbacktofalse.该问题最根本的原因在于客户的数据库很久没有做统计信息更新，致使oracle11g采用该参数去获取统计信息。7.重建索引解决效率问题问题描述：客户进行服务器和数据库软硬件升级，数据库从以前的10g升级到现在的11g，升级后硬件比原硬件好很多，但部分操作反而变慢检查分析：获取问题SQLselect*fromia_billh,ia_bill_bbwhereh.dr=0andb.dr=0andh.cbillid=b.cbillidandh.bdisableflag='N'andh.pk_corp='1002'andb.pk_corp='1002'andb.cfirstbillid='1002A1100000003KYGBI'andb.cfirstbillitemid='1002A1100000003KYGBM'andh.cbilltypecodein('IJ','II')13andb.cbilltypecodein('IJ','II');14旧库和新库走的执行计划不同，对考虑到新库为11g，当时设置compatible参数为10gAltersystemsetcompatible=10.2.0.4;对比旧库执行计划可以发现，两个执行计划相同，但逻辑读差距百倍，直接查询条件设置为"B"."CFIRSTBILLITEMID"='1002A1100000003KYGBM'AND“B”.“CFIRSTBILLID”=‘1002A1100000003KYGBI’，走I_IA_BILL_B_FIRST索引时逻辑读跟新库修改参数后的逻辑多差不多，怀疑该索引有问题。解决方法：重建该索引后正常问题思考：考虑到该库刚从旧库迁移过来，数据位全新导入，不存在索引碎片的现象。考虑可能是数据库统计信息出问题，因重建索引会更新统计信息，故下次遇到该情况建议首先更新统计信息，如问题依旧，再考虑重建索引158.单据查询效率慢问题描述：某项目单据查询效率慢检查分析：通过NMC找到慢的SQL发现缺少相关索引。解决方法：createindexi_arap_djfb_jszc01onarap_djfb(fph,billdate)9.客商档案效率优化系统环境：NC版本NC5616日常在线人数400人目前数据量大小50G数据库类型及版本Oracle10.2.0.1数据库服务器型号配置1台HPLD580G5:8个CPU，32G内存数据库服务器操作系统WindowsServer2003问题描述：信贷管理模块，内部借款合同，点击查询，查询条件中的借款单位的放大镜操作，该操作耗时几分钟检查分析：利用NMC工具，抓取SQL如下<查询列名由……替代>：selectdistinctcustcode,……from((selectbd_cubasdoc.pk_cubasdocpk_cubasdoc,……frombd_cubasdoc,bd_cumandocwherebd_cubasdoc.pk_cubasdoc=bd_cumandoc.pk_cubasdoc)union(selectpk_bankdocpk_cubasdoc,17……frombd_bankdoc,bd_banktypewherebd_bankdoc.pk_banktype=bd_banktype.pk_banktypeand(banktypecode<>'9999'andexists(select1frombd_bankaccbaswhereownercorp='1360'andpk_bankdoc=bd_bankdoc.pk_bankdoc))))alliounitwhere((pk_corp='1360'andcustprop<>0andpk_corp1isnotnullAND(custflag='0'ORcustflag='1'ORcustflag='2'))orbanktypecode='9999')orderbycustcode其对应执行计划如下：18看执行计划可知，客商档案表和客商管理档案表通过客商档案主键关联，而且两张关联表走的都是全表扫描，由蓝色标注出可知客商管理档案表只查询1360单位的客商管理档案，因其又通过客商档案主键关联，可推出客商档案也应只需查询1360单位的客商档案即可。故修改原SQL红色标注出来的部分，修改成如下：wherebd_cubasdoc.pk_cubasdoc=bd_cumandoc.pk_cubasdocandbd_cumandoc.pk_corp='1360'修改后的SQL执行计划如下：19由执行计划可知，此时已走索引，经验证，实际速度由原来的数分钟提高到几秒，逻辑读也有155523降低到4073解决方法：修改原SQL红色标注出来的部分，修改成如下：wherebd_cubasdoc.pk_cubasdoc=bd_cumandoc.pk_cubasdocandbd_cumandoc.pk_corp='1360'其他：对于修改SQL的情况，一定要确认修改SQL后，查询结果是否与原始SQL一致，本例修改后SQL与原始SQL一直，都是358行。附件为SQL优化的完整执行计划华西集团SQL优化.txt2010.数据库CPU100%技术问题解决案例系统环境：NC版本NC56日常在线人数330人总的客户端数1000个目前数据量大小6G数据库类型及版本Oracle10.2.0.4数据库服务器型号配置2台IBM,8204-E8A:4个CPU，32G内存数据库服务器操作系统AIX5.3数据库服务器集群方式RAC问题描述：客户描述现象：WAS其中一个SERVER宕掉以后，所有的操作都会慢下来，他们认为WAS有问题，希望我们能够尽快排查原因。现场实际现象：NC登陆耗时很久，所有操作都很慢，通过NMC监控截图如下21检查分析：由NMC线程监控截图可知，程序目前有大量正在执行的SQL，且正常情况下这些SQL执行很快，说明此时数据库有严重的效率问题。登陆数据库，发现此时两台服务器CPU消耗都在95%以上，多数时间高达99%，由此可以初步确定该问题与WAS无关，应该是Oracle数据库问题，下面对Oracle数据库进行查找分析原因。优化操作一：<去除Oracle数据库bug>查看后台进程执行SQL：selectcount(*),eventfromv$sessiongroupbyevent;22kksfbc是Oracle数据库的bug，需要手工从操作系统kill掉：selectinst_id,sid,paddrfromgv$sessionwhereeventlike'kksfbc%';selectspidfromgv$processwhereinst_id=2andaddrin(selectpaddrfromgv$sessionwheresidin(478,399)andinst_id=2);kill-9717240kill-9602270执行该操作之后，CPU有所下降23检测后台等待事件：执行SQL：selectcount(*),eventfromv$sessiongroupbyevent;24优化操作二：<去除NMC监控SQL造成消耗CPU过高的问题>导出AWR报告25查看CPU耗时SQL排行可知，耗时最多的SQL由红色标注出，其SQL语句如下：select*from(selecthash_value||'***'||rpad('|'||substr(lpad('',1*(depth-1))||operation||decode(options,null,'',''||options),1,32),33,'')||'|'||rpad(decode(id,0,'-----'||to_char(hash_value)||'-----',substr(decode(substr(object_name,1,7),'SYS_LE_',null,object_name)||'',1,20)),21,'')||'|'||lpad(decode(cardinality,null,'',decode(sign(cardinality-1000),-1,cardinality||'',decode(sign(cardinality-1000000),-1,trunc(cardinality/1000)||'K',decode(sign(cardinality-1000000000),-1,trunc(cardinality/1000000)||'M',trunc(cardinality/1000000000)||'G')))),7,'')||'|'||lpad(decode(bytes,null,'',decode(sign(bytes-1024),-1,bytes||'',decode(sign(bytes-1048576),-1,trunc(bytes/1024)||'K',decode(sign(bytes-1073741824),-1,trunc(bytes/1048576)||'M',26trunc(bytes/1073741824)||'G')))),6,'')||'|'||lpad(decode(cost,null,'',decode(sign(cost-10000000),-1,cost||'',decode(sign(cost-1000000000),-1,trunc(cost/1000000)||'M',trunc(cost/1000000000)||'G'))),8,'')||'|'as"Explainplan"fromv$sql_planwherehash_valuein(selects.sql_hash_valuefromv$sessionswheres.username=upper('ljnc')ands.status='ACTIVE'ands.last_call_et>10))该SQL为NMC监控语句，关闭NMC监控语句，关闭后topas监控到的CP使用率如下：2728由topas可知，此时CPU消耗很不稳定，该种情况多数是由个别SQL性能有问题造成的优化操作三：<找出自定义查询问题>由图可知，PID为647248的oracle进程消耗CPU比重占24.8%，执行下面SQL，查询该进程对应的SQL：selectsql_idfromgv$sessionwhereinst_id=2andpaddrin(selectaddrfromgv$processandinst_id=2andspid=647248);抓取到SQL如下：29其SQL语句如下：selectv_lj_cmp_busibill_Sum.方案字表id,v_lj_cmp_busibill_sum.累计核报金额fromv_lj_cmp_busibill_sumwherev_lj_cmp_busibill_sum.方案字表idin('1004AA1000000011Z20M')因v_lj_cmp_busibill_sum是视图，其内容如下：selectmax(bb.djbh)as单据号码,max(bb.ddhh)as方案子表id,sum(bb.jfybje)as累计核报金额fromcmp_busibill_bbbwherenvl(bb.dr,0)=0groupbybb.ddhh该SQL有问题，每次查询会消耗大量的CPU，建议修改到如下方式：30select*from(selectmax(bb.djbh)as单据号码,max(bb.ddhh)as方案子表id,sum(bb.jfybje)as累计核报金额fromcmp_busibill_bbbwherenvl(bb.dr,0)=0andddhhin()groupbyddhh)where方案子表idin()修改SQL，保持视图内容不变，将过滤条件直接传递到表中。类似问题SQL如下，下面两个SQL，每个SQL查询消耗20%左右的CPU使用，而且下面两个SQL查询非常频繁。SELECTv_nc_cmp_ysrygy.核报FROMv_nc_cmp_ysrygyWHEREv_nc_cmp_ysrygy.办事处ID=:1ANDv_nc_cmp_ysrygy.报销人ID=:2SELECTv_nc_cmp_ysrygy.结余FROMv_nc_cmp_ysrygyWHEREv_nc_cmp_ysrygy.办事处ID=nullANDv_nc_cmp_ysrygy.报销人ID=null;优化方式：修改SQL，取消视图使用，直接使用SQL查询，并将查询条件，办事处ID，报销人ID传递到表中。31优化操作四：<优化部分可以即时优化的SQL>后台有大量SQL在查询HEPLUB_TERMPRODUCT_B表，查看对应SQL的执行计划：由执行计划可知，HEPLUB_TERMPRODUCT_B表走全表扫描，查看pk_terminal列过滤行数：32该行可以建索引，创建索引：createindexi_HEPLUB_TERMPRODUCT_B_jszconHEPLUB_TERMPRODUCT_B(pk_terminal)nologgingparallel;alterindexi_HEPLUB_TERMPRODUCT_B_jszcnoparallel;类似SQL效率问题还有三个SQL，已全部优化：selectdistinctpk_wf_actinstance,activitydefid,actstatusfrompub_wf_actinstancewherepk_wf_instance=:1createindexi_pub_wf_actinstancesrc_jszconpub_wf_actinstancesrc(target_actinstance)nologgingparallel;alterindexi_pub_wf_actinstancesrc_jszcnoparallel;selecta.pk_wf_actinstance,a.pk_wf_instance,a.activityDefID,a.actstatus,a.actresult,a.createtime,a.modifytime,a.reachjoins,b.processDefID,c.src_actinstancefrompub_wf_actinstancealeftouterjoinpub_wf_actinstancesrcconc.target_actinstance=a.pk_wf_actinstance,pub_wf_instancebwherea.pk_wf_instance=:1anda.pk_wf_instance=b.pk_wf_instance;createindexi_PUB_WF_ACTINSTANCE_jszconPUB_WF_ACTINSTANCE(PK_WF_INSTANCE)nologgingparallel;alterindexi_PUB_WF_ACTINSTANCE_jszcnoparallel;33SELECTcmp_busibill.ybjeFROMcmp_busibillWHEREcmp_busibill.dr=:1ANDcmp_busibill.djbh=:2createindexi_cmp_busibill_jszc_01oncmp_busibill(djbh)nologgingparallel;alterindexi_cmp_busibill_jszc_01noparallel;解决方法：selectdistinctpk_wf_actinstance,activitydefid,actstatusfrompub_wf_actinstancewherepk_wf_instance=:1selecta.pk_wf_actinstance,a.pk_wf_instance,a.activityDefID,a.actstatus,a.actresult,a.createtime,a.modifytime,a.reachjoins,b.processDefID,c.src_actinstancefrompub_wf_actinstancealeftouterjoinpub_wf_actinstancesrcconc.target_actinstance=a.pk_wf_actinstance,pub_wf_instancebwherea.pk_wf_instance=:1anda.pk_wf_instance=b.pk_wf_instance;SELECTcmp_busibill.ybjeFROMcmp_busibillWHEREcmp_busibill.dr=:1ANDcmp_busibill.djbh=:2这三个有问题的SQL可以通过添加索引等优化方式优化，目前已经优化。SELECTv_nc_cmp_ysrygy.核报FROMv_nc_cmp_ysrygyWHEREv_nc_cmp_ysrygy.办事处ID=:1ANDv_nc_cmp_ysrygy.报销人ID=:2SELECTv_nc_cmp_ysrygy.结余FROMv_nc_cmp_ysrygyWHEREv_nc_cmp_ysrygy.办事处ID=nullANDv_nc_cmp_ysrygy.报销人ID=null;selectv_lj_cmp_busibill_Sum.方案字表id,v_lj_cmp_busibill_sum.累计核报金额fromv_lj_cmp_busibill_sumwherev_lj_cmp_busibill_sum.方案字表idin('')这三个有问题的SQL为自定义查询SQL。34优化方式：修改SQL，取消视图使用，直接使用SQL查询，并将查询条件，办事处ID，报销人ID传递到对表的查询SQL中。其他：该问题经常发生在WAS中间件有节点宕掉的时候，致使客户误以为是WAS原因导致，实则为数据库问题11.报表查询效率优化案例系统环境：NC版本NC502数据库服务器型号配置1台HPDL580G4:8个CPU，16G内存数据库服务器操作系统WindowsServer200364bit数据库类型及版本Oracle10.2.0.1目前数据量大小3G问题描述：业务：报表数据—录入—web方式录入—数据—计算，最近一个月左右，该操作变得特别慢，大约需要10分钟35检查分析：原始SQL：select/*+0.943166708225807*/gl_voucher.pk_glorgbook,gl_detail.pk_accsubj,gl_detail.assid,sum(gl_detail.debitquantity)debitquantitysum,sum(gl_detail.creditquantity)creditquantitysum,sum(gl_detail.debitamount)debitamountsum,sum(gl_detail.creditamount)creditamountsum,sum(gl_detail.fracdebitamount)fracdebitamountsum,sum(gl_detail.fraccreditamount)fraccreditamountsum,sum(gl_detail.localdebitamount)localdebitamountsum,sum(gl_detail.localcreditamount)localcreditamountsumfromgl_detailgl_detail,gl_vouchergl_voucher,glTMP_assORAID,tmptabsubjORAwheregl_detail.pk_accsubj=tmptabsubjORA.pk_accsubjandgl_voucher.year='2012'andgl_voucher.free1>='00'andgl_voucher.free1<='08'36andgl_voucher.pk_glorgbook='0001A41000000000014O'andgl_voucher.discardflag='N'andgl_voucher.dr=0andgl_voucher.voucherkind<>255andgl_voucher.pk_manager='N/A'andgl_detail.pk_voucher=gl_voucher.pk_voucherandgl_detail.assid=glTMP_assORAID.assidgroupbygl_voucher.pk_glorgbook,gl_detail.pk_accsubj,gl_detail.assidorderbygl_voucher.pk_glorgbook,gl_detail.pk_accsubj,gl_detail.assid通过查看执行计划可知：红色标注处rows为1，有可能统计信息被收集，查看该表的统计信息：37由结果可知，统计信息被收集，临时表的统计信息不应被收集，故删除统计信息，如下图：删除后执行那个业务正常，效率从以前的10分钟提高到2S解决方法：删除临时表的统计信息其他：临时表不应被统计信息更新
