金蝶K/3产品性能稳定性案例集金蝶金蝶K/3K/3产品性能稳定性案例集产品性能稳定性案例集 金蝶软件(中国)有限公司K/3产品事业部.设计部解释目的本案例集是我们在处理K/3系统应用过程中遇到性能问题的解决方法与方案总结,旨在帮助技术支持人员、分支机构实施服务人员以及客户更快速解决相关性能问题；同时也指导我们的实施服务人员和客户在实施中如何预防和避免将来可能发生的性能稳定性问题。适合对象本案例集的主要阅读对象是K/3系统研发人员、技术支持人员、实施人员、客户服务人员和公司授权的有一定技术能力的客户系统管理员。导读本案例集首先是按照网络、数据库、中间层、客户端层次来介绍实际遇到的通用案例,包括问题的描述,分析以及解决方案，接着以K/3产品发展的主线分版本来列举对应的案例以及处理方案，请您根据您的需要选择相应的章节阅读。注意:由于此案例集可能牵涉一些K/3在技术方面的细节，为了防止有些人用意不良，断章取义来攻击K/3产品和公司，请注意保密。金蝶K/3产品性能稳定性案例集目录1.性能案例总体分析步骤.12.总体通用性能问题案例.32.1网络与Citrix性能问题案例..32.1.1通用案例1—-网络架构问题..32.1.2通用案例2—-病毒导致网络问题..32.1.3通用案例3—-Citrix服务端内存问题..32.1.4通用案例4—-应用Citrix打印问题..42.2数据库性能问题案例..62.2.1通用案例1—-数据库日志文件过大..62.2.2通用案例2—-数据文件大小不正常..62.2.3通用案例3—-Tempdb日志过大.72.2.4通用案例4—-数据库服务器硬件问题.72.2.5通用案例5—-系统整体运行速度非常慢.92.3中间层COM+性能问题案例.102.3.1通用案例1—-COM+挂起.102.3.2通用案例2—-COM+配置/环境的问题..122.3.3通用案例3—-CPU100%..232.3.4通用案例4—-COM+性能问题.232.3.5通用案例5—-COM+安全性的问题.242.3.6通用案例6—-COM+其他的问题.252.4客户端性能问题案例..282.4.1通用案例1—-客户端突然出现全面的死机现象.282.4.2通用案例2—-客户端出现“新事务不能登记到指定的事务处理器中”..292.4.3通用案例3—-USER组用户权限问题.323.各历史版本性能问题案例.333.1.K/3V9.1性能问题案例.333.1.1在打开往来对帐时速度非常慢,服务器CPU占用100%.333.2.K/3V10.0性能问题案例.333.2.1K/3数据授权导致F7、单据查看、序时簿查看、选单关联速度很慢(工业类型账套).333.2.2出入库单据丟失.343.2.3应收冲应付的单据生成凭证时导致数据库服务器死锁.343.3.K/3V10.1性能问题案例.343.3.1K/3数据授权导致F7、单据查看、序时簿查看、选单关联速度很慢(工业类型账套).353.3.2凭证录入性能问题.363.3.3报表查询时数据库服务器CPU占用100%.363.3.4进行匹配内部往来机构时速度特别慢.363.3.5采购订单执行情况汇总表和采购订单执行情况明细表查询慢.363.3.6采购收货单序时簿查询慢、销售发票序时簿慢的问题（商业类型账套）金蝶K/3产品性能稳定性案例集..373.3.7销售发票生成凭证慢的问题（商业类型账套）.373.4.K/3V10.2性能问题案例.373.4.7物料需求计划性能优化.423.4.8员工异动、入职、工资导入性能慢.423.5.K/3V10.3性能问题案例.423.5.1单据上下查功能..423.5.2启用折扣管理后性能不理想.433.6.K/3V10.4性能问题案例.433.6.1信用管理不能启用..433.6.2进出口、应收应付某些BOS单据加载、保存、F7多选返回时速度很慢43金蝶K/3产品性能稳定性案例集1.性能案例总体分析步骤作为服务人员或实施人员，遇到客户的性能或稳定性问题时，请您不要着急,可参考如下步骤:第一步：引导客户了解具体问题；第二步：收集用户计算机信息；自动收集服务器的事件日志，系统配置环境，操作系统版本等信息。对与中间层服务器使用MPSRPT_Alliance_X86.EXE，对于数据库服务器使用MPSRPT_SQL.exe工具位置：MPSRPT_Alliance_X86.exe：http://www.microsoft.com/downloads/details.aspx?familyid=cebf3c7c-7ca5-408f-88b7-f9c79b7306c0&displaylang=en；MPSRPT_SQL.exe：http://download.microsoft.com/download/b/b/1/bb139fcb-4aac-4fe5-a579-30b0bd915706如果现场问题需要总部支持的话，请使用上面的工具收集计算机的信息。MPSRPT_SQL.exe运行后：将会生成CAB文件，CAB会被生成在%systemroot%\MPSReports\SQLServer\<ReportType>\Cab目录。通常名字为%COMPUTERNAME%_SQL_MPSReports_XXXXXXXXXX_X.CAB。(%systemroot%为Windows系统目录，比如C:\WindowsorC:\Winnt)第三步：判断是否网络问题，网络是否丢包等；由于病毒也是导致网络不稳定的一个原因，所以需要确定是否存在病毒；建议:网络推荐至少百兆网，全交换更好，推荐采用域结构，域服务器不要跟K/3服务器装在一起。关于客户端和中间层不在同一域的问题，最好是配置客户端和中间层在同一域中，如果无法配置在同一域中。可以修改组件服务中COM+组件的安全验证选项，如下图所示。降低身份验证级别，能够在一定程度上改善调用中间层组件的性能。1金蝶K/3产品性能稳定性案例集附丢包率判断方法：丢包率通过客户端192.168.1.205,对中间层192.168.1.2,做如下操作:(1)ping192.168.1.2–n1000–l2000(2)pathping192.168.1.2(1)time<1ms,sent=1000,received=999,lost=1(0%loss),Min=0ms,Max=9ms,Average=0ms(2)for25secondstatistics中,Pct=Lost/Sent=0%即:无丢包,丢包率0%.第四步：检查用户操作系统，如果是WINDOWS2003是否安装SP1,SQL2000是否打上SP4,请参照文档：第五步：定期维护和优化帐套，具体参见《金蝶K/3产品性能稳定性优化指导手册》。第六步：数据库表结构不合理，常见有：二次开发的表没有索引,造成性能隐患；不恰当的触发器和游标的使用，大数据表缺少聚集索引。第七步：寻找合适的补丁。第八步：与K/3开发部沟通，获得解决方案。2金蝶K/3产品性能稳定性案例集2.总体通用性能问题案例本章主要对目前K/3系统在实际运行过程中遇到的一些通用性能案例进行介绍分析,具体内容按照网络、数据库、中间层、客户端层次结构来组织。2.1网络与Citrix性能问题案例2.1.1通用案例1—-网络架构问题1、问题描述：使用某一台交换机的所有使用K/3的机器（该交换机为第三级），出现客户端挂起的情况，K/3系统使用不稳定。2、问题分析：1)将出现问题的客户端机器的网线拔掉，过5-10秒再重新插入后，系统挂起现象解决，K/3可以正常使用；2)通过PINGxxx.xxx.xxx.xxx–l1024–n100后，发现统计信息中存在丢包的现象；3)接到另外一台交换机（该交换机为第一级）上后，发现K/3系统使用稳定，但总体性能下降，分析原因为网线的距离过长，从而导致了数据传输上的损失3、解决方法：重新部署网络架构2.1.2通用案例2—-病毒导致网络问题1、问题描述：所有机器使用K/3同一个功能时，快的时候6-7秒，慢的时候要1分多钟（已经排除数据量和查询数据范围的问题）。2、问题分析：客户端网络使用光纤接入，使用PINGxxx.xxx.xxx.xxx–l1024–n100检查，发现都存在丢包的现象，但如果整个网络只存在一台计算机时，系统使用正常。怀疑是病毒原因。使用杀毒软件进行杀毒后，发现有多台客户端有病毒。由于感染病毒后会疯狂发包，导致路由器NAT连接很快占满，从而导致性能问题。3、解决方法：丢包掉线可能原因：1)局域网中的某台或者多台机器感染了病毒，在疯狂发包，导致路由器NAT连接很快占满。建议方案：试着断开某台交换机，进行逐一排查，进行隔离杀毒，找到该台机器，将其隔离。2)可能是交换机长时间没有重启其内存已用光，导致交换数据速度缓慢，或受网络风暴影响导致阻塞或交换机的某一个或几个接口模块损坏，或交换机故障引发的网络内暴。建议方案：关闭局域网内所有交换机4-5分钟后，重新接通电源，观察网络是否恢复正常。3金蝶K/3产品性能稳定性案例集2.1.3通用案例3—-Citrix服务端内存问题1、问题描述：某集团在培训练习过程中（同时登陆的有40台机器,使用的CITRIX登陆），发现系统使用速度非常慢，在一段时间不操作机器的情况下，K/3客户端会报错误，后自动退出。服务器配置为：CPU为Xeon5160双核3.0G,内存为1GB，Citrix服务端耗用内存2GB多。2、问题分析：一般去除操作系统和Citrix服务器的的消耗，每个CitrixK/3客户端大概耗用50兆左右内存。因此对于30个客户端的并发，可能需要30*50+500(操作系统和Citrix服务器的消耗)=2000(M)的内存。如果内存不足时，操作系统将会自动进行换页处理，这时需要空余的磁盘空间作为交换文件，但也会极大影响程序的性能。3、解决方法：增加服务器内存(建议加到4GB)。2.1.4通用案例4—-应用Citrix打印问题1、问题描述：某客户在应用CITRIX进行K/3应用的过程中存在下面问题：问题一：打印的单据打印到了别的客户端的打印机上问题二：HP1020,1000等USB打印机在CITRIX模式不能正常打印，但在微软终端模式下一切正常问题三：在服务器和客户端都设好缺省纸张，但在打印时仍然报纸张错误。2、问题分析：问题一：Citrix在每台客户端打印机前面都会加//clinet_name/Printer_name来区分各不同的打印机，所以实际上这些打印机是分得清楚的，即使是相同型号的打印机，由于使用了这种长串识别，也是不可能完全相同的。目前碰到最多的串打问题，是客户自己在使用时分不清楚哪台是自己的打印机，所以会打错。解决该问题的最佳方法，就是将客户端用户降为Users组成员，这样他将无法看到其它客户端连接上来的打印机，也就不会发生串打了。问题二：经跟踪分析与打印机的启用双向支持有关，需要进行相关的设置，见解决方法。问题三：在Citrix里可以设置延用客户端打印机设置，即在客户端本地设置的打印机属性，连接Citrix服务器后，打印时可以延用该属性设置。在K/3V10.2以后的版本，K/3已经实现按用户来记录不同的打印设置，该问题可以得到解决。3、解决方法：问题一：Citrix串打问题。将客户端用户设为USER用户，运行Regedt32在权限管理中对下面注册表项赋予USER组完全控制的权限:HKEY_LOCAL_MACHINE\SOFTWAREHKEY_CLASSES_ROOT\AppIDHKEY_CLASSES_ROOT\KdSvrmgr.clsAct对于Win2003，可以直接使用Regedit进行权限授予，对于Win2000及以前，必须使用Regedt32.问题二：USB打印机问题。在CITRIX模式下HP1020打印机打印不正常，主要表现是映射正常，打印数据文件也能正常传输到客户端，但在客户端的打印任务管理器始4金蝶K/3产品性能稳定性案例集终不打印，端口也正常映射到USB口。但在WINDOWS终端模式下打印正常，在CITRIX终端GUI与WEB模式都不能打印。在服务器上安装HP1020打印驱动，如下图配置：在客户端按上设置即可，重新登陆.问题三：缺省纸张的问题。1)必须使用本地打印驱动，即在服务器上安装客户端打印机的驱动，而不是使用通用驱动打印。ManagementConsole—>PrinterManagement—>Properties—>Drivers—>NativeDriversonly(如无特殊打印机最好选择此项)，缺省为：5金蝶K/3产品性能稳定性案例集Useuniversaldriveronlyifnativedriverunavailab2)启用设置套打格式。3)纸张的设置可在客户端的打印机上设置。请检查以下设置：ManagementConsole——>PrinterManagement——>Properties——>Printers——>inheritclientprinter'ssettingforkeepingprintereddocuments是否勾选？选择该项，可延用客户端的打印设置。2.2数据库性能问题案例2.2.1通用案例1—-数据库日志文件过大1、问题描述：客户数据库的LOG文件非常大，达到680M（实体文件是2.6G左右），做过数据库压缩、数据库剥离，重新建了日志文件后速度变快，如此反复了两次，现在又慢了下来。导致客户端运行速度非常慢，严重时连一个客户端都进不去。2、问题分析：该问题是由于没有把数据库的故障还原设置为简单，导致数据库LOG文件很大，影响数据库性能，可以对数据库做一些优化设置来处理。3、解决方法：1)把数据库的故障还原设置为“简单”(注意:该故障还原模式下数据库不能进行事务日志备份)。2)数据库分离附加〔采用日志分离的方式减少日志文件的大小：首先在“SQLSERVER企业管理器”分离数据库,然后删除此数据库的日志文件(*.ldf),最后再重新附加数据库〕。3)数据库收缩（在数据库服务器进行数据库实体收缩）。4)检查二次开发的触发器和存储过程是否存在批量更新数据库不严谨造成日志文件增大（关键）。5)执行下面附件的SQL，核对一下是否有的表占用的空间过大没有释放，可以优化一下此表的索引结构，保存此表后可以把过多的空间释放出来。2.2.2通用案例2—-数据文件大小不正常1、问题描述：SQLServer的数据文件变得不正常，大小和客户的数据量从经验上很不相符，这种异常会很大地影响系统性能，还有可能引发错误。2、问题分析：该问题主要是由于有些表没有建立聚集索引引发，需要运行工具来分析检查。3、解决方法：运行下面工具：6金蝶K/3产品性能稳定性案例集它可以生成一个EXCEL表格K/3DATA.xls，记载了数据库中所有表的使用空间大小，重点关注Reserved,Unused列，如果发现与记录数应有的数据量有很大的差异，可以看看这些表是否有聚集索引，如果没有,则建立聚集索引，收缩数据库，数据库的数据文件会缩小很多。注意:此工具需要在安装有K/3客户端的机器上运行。2.2.3通用案例3—-Tempdb日志过大1、问题描述：Tempdb数据库文件出现大幅度增长，甚至达到3-4GB，从而导致K/3整体功能下降2、问题分析：SQLServer2000对于TempDB的处理是采用SQLServerCacheBufferManager来管理，而不再是象SQLServer7.0一样可以使用TempDBInRAM的，这样，在高并发情况下，由于SQLServer的后台进程不能及时调度，造成TempDB的容量迅速增大（由初始的8MB增长到性能测试时的800MB），从而导致CacheHitRation迅速下降造成对TempDB的PagesReads/Sec和PagesWrites/Sec狂飙造成的。TEMPDB增长的同时也会导致内存使用的增长，由于内存以及物理空间的资源使用从而导致系统的整体性能下降。3、解决方法：收缩TEMPDB数据库，可以采用下面几种方式，最好做一个定期执行计划方法一重启SQLSERVER服务ALTERDATABASEtempdbMODIFYFILE(NAME='tempdev',SIZE=需要收缩的大小)ALTERDATABASEtempdbMODIFYFILE(NAME='templog',SIZE=需要收缩的大小)方法二sp_spaceused@updateusage=truedbccshrinkdatabase(tempdb,'百分比')方法三dbccshrinkfile(tempdev,'需要收缩的大小')dbccshrinkfile(templog,'需要收缩的大小')4、建议1)将tempdb数据库文件的初始大小设置为合理的大小，以避免当需要更多空间时文件自动扩展。如果tempdb数据库扩展得过于频繁，性能会受不良影响。2)如果需要使用数据库文件按百分比增长，将文件增长增量百分比设置为合理的大小，以避免tempdb数据库文件按太小的值增长。如果文件增长幅度与写入tempdb数据库的数据量相比太小，则tempdb数据库可能需要始终扩展，因而将妨害性能。3)最好设置数据库文件的增长方式为按指定的字节数方式，建议设置为200MB。4)将tempdb数据库放在快速I/O子系统上以确保好的性能。在多个磁盘上条带化tempdb数据库以获得更好的性能。使用文件组将tempdb数据库放在除用户7金蝶K/3产品性能稳定性案例集数据库所使用的磁盘之外的磁盘上。2.2.4通用案例4—-数据库服务器硬件问题1、问题描述：物流的出入库单据都不能保存。2、问题分析：根据现场描述的情况，进行同样的操作，发现业务能正常处理，怀疑数据库服务器存在问题，让现场提供数据库服务器的事件日志和数据库日志，发现存在下面的错误信息。事件日志：Envetid:17055Envetid:17052错误:823，严重度:24，状态:2I/Oerror(badpageID)detectedduringreadatoffset0x0000000224a000infile'E:\DataBase\AIS20050529165714_Data.mdf'.Eventid:19011SuperSocket信息:ConnectionListen(Shared-Memory(LPC)):Error5。事件ID(4194)的描述(在资源(COM+)中)无法找到。本地计算机可能没有必要的注册信息或消息DLL文件来从远程计算机显示消息。您可能可以使用/AUXSOURCE=标识来检索词描述；查看帮助和支持以了解详细信息。下列信息是事件的一部分:组件ProgID:服务器应用程序ID:{DAE39E2A-3C8D-49DC-9BFB-1611078F4940}服务器应用程序名称:eboK/3该错误的严重性已导致进程终止。异常:C0000005地址:0x6A388318调用堆栈:,MSVBVM60!__vbaVarDup+0x6C4EOLEAUT32!DispCallFunc+0x15DMSVBVM60!BASIC_CLASS_Invoke+0x259MSVBVM60!BASIC_CLASS_Invoke+0x52OLEAUT32!UserEXCEPINFO_free_local+0x57DEnvetid:4193Source:msdtc资源管理器执行了恢复操作并调用了ReenlistmentComplete，说明恢复过程已完成。但至少一个通过资源管理器登记的事务的状态仍然是“不确定”数据库：2006-03-1708:53:28.64spid16表错误:对象ID1384001053，索引ID0，页(1:41775)。测试（IS_ON(BUF_IOERR,bp->bstat)&&bp2006-03-1708:53:28.64spid16表错误:对象ID1384001053，索引ID0，页(1:41775)。测试（IS_ON(BUF_IOERR,bp->bstat)&&bp2006-03-1708:53:28.65spid16表错误:IAM页(1:41775)（对象ID8金蝶K/3产品性能稳定性案例集1384001053，索引ID0）超出了此数据库的范围。使用DBCCCHECKDB出现下面信息：2006-03-1712:57:55.95spid15表错误:分配页(0:67108864)的IAM_PAGE页首结构值无效。类型为0。请检查该页上的类型、对象ID和页ID。3、解决方法：根据上面的日志，查看微软网站相应的说明，由于使用DBCCCHECKDB存在无法修复的情况，这种情况可以排除是数据系统本身的原因，因为在硬件系统方面。建议客户将服务给硬件提供商检查，检查后发现导致该问题的原因在于硬盘系统存在问题。微软网站关于错误的说明文档见：http://support.microsoft.com/default.aspx?scid=kb;en-us;828339http://support.microsoft.com/kb/q221926/2.2.5通用案例5—-系统整体运行速度非常慢1、问题描述：客户反馈，当前网速为10M，整体系统运行速度非常慢，例如审核一张单据，从查到该单据，到审核完毕，时间在5分钟左右才可以完成，中间仍会经常断掉，需要重新登陆，已经制约了部分业务的进行。2、问题分析：1)K/3系统数据全部都在一个数据库中，长期以来，积累了大量的数据，包括：仓存管理业务数据、作业成本数据、财务数据等等信息，都在里面长期存放，目前数据库已有8G（包括日志文件）；2)网速目前为10M，可能对此有部分影响，但已满足系统运行要求；3)作业成本的数据表设计是否存在性能问题，账套一直在无限地增加数据量，这里讨论是一种加速度的增加，即每年账套数据量增加呈递增状。3、解决方法：1)请事先备份好数据（如果数据是完全备份，不是增量备份和日志备份），再把数据库属性在企业管理器里的故障还原设置为“简单”；2)执行【BACKUPLOG数据库名withnolog】截断日志；3)打开“企业管理器”点击右键－>所有任务－>收缩数据库；4)在中间层优化账套（打开“账套管理”－>数据库－>优化账套）,或者通过建立索引维护计划进行优化账套；5)用户操作建议:单据查询时，设置精确的过滤条件，以提高查询效率，尽可能避免由于大数据量的读取IO操作导致性能下降；修改序时簿的过滤条件，取消关联标志，钩稽标志等的显示，因为这块耗时过多，特别是涉及到多单据的关联字段；尽量在序时簿里把不重要的字段隐藏不显示。；6)检查表t_locktable是否存在主键，如果没有，请设置FinterID做为主键；7)执行下面附件的SQL，核对一下是否有的表占用的空间过大没有释放，可以优化一下该类表的索引结构，把过多的空间释放出来；8)对于查询比较慢的单据可以把SQL跟踪出来，然后用查询分析器运行索引优化向导，序时簿相关关联表增加索引；9金蝶K/3产品性能稳定性案例集9)考虑结转新账套；10)增加数据库服务器硬件配置。2.3中间层COM+性能问题案例2.3.1通用案例1—-COM+挂起2.3.1.1K/3在WIN2KSRV客户端+WIN2KSRV服务器运行环境下MTS事务不能提交,出现挂起1、问题描述：K/3在WIN2KSRV客户端+WIN2KSRV服务器运行环境下MTS事务不能提交,出现组件挂起。COM+中组件的调用时间不断增加，客户端提示“正在调用中间层”。组件服务图如下所示：客户端提示：2、应用环境：WIN2KSRV客户端+WIN2KSRV服务器3、问题分析：问题出现后，首先通过各种测试对问题进行排查和分析，包括：10金蝶K/3产品性能稳定性案例集1)通过sp_lock以及usemasterselect*fromsysprocesses查询，发现数据库并没有出现阻塞；2)COM+中有事务的组件出现挂起，调用时间不断增加；3)编写程序通过连接串连接数据库没有问题；4)中间层组件能够被成功创建；5)编写程序直接通过中间层组件取数没有问题；6)通过中间层创建中间层调用时出现-正在调用中间层-，发生挂起，测试代码说明如下：对问题进行排查后发现通过中间层创建中间层调用时出现挂起，但其他环境应用并没有此问题，因而初步确定应该是环境问题，通过尝试修改DIIHOST的MAXTHREAD依然没有效果。进一步了解后得知机器是克隆的，由于MSDTC协调器都有一个GUID唯一标识，但是克隆机器也把GUID同时克隆了，这样在网络中找到两个同一标识的MSDTC服务器，从而导致出现问题，引起事务提交没有反映，出现挂起现象。通过咨询微软专家建议不要使用克隆机器应用于生产环境中，建议完全安装服务器进行测试。可以使用DTCPING.exe进行排查，来检查GUID是否一样。工具地址：http://www.microsoft.com/downloads/thankyou.aspx?familyId=5e325025-4dcd-4658-a549-1d549ac17644&displayLang=en4、解决方案：重新安装MSDTC1)卸载：运行msdtc–uninstall，重启；2)安装：msdtc–install，问题解决。注意：请不要使用克隆的机器做为服务器，客隆机器若出现COM+挂起可以尝试重装MSDTC来解决。2.3.1.2K/3运行有时出现COM+组件挂起的异常问题1、问题描述：K/3运行有时出现COM+组件挂起的异常问题（整个包或某个组件挂起，需要关闭启动或重新安装才正常）2、问题分析：一般产生COM+挂起的原因有：1)com+进程出现UI；即组件弹出UI对话框，需要人为“确定”才能继续。2)出现进程外等待；包括数据库被锁定（可以查数据库锁定情况）或等待其他进程（一个DLLHOST调用另外一个DLLHOST）。3)出现死锁；如A等待B，B等待C，C等待A（例如一个进程打开数据库进行UPDATE，此时DTC会锁定相应的表,同时另一个进程访问同一个表,出现死锁）。3、解决方案：11金蝶K/3产品性能稳定性案例集按COM+挂起的处理方法通过抓dump文件(每隔3-5分钟抓一个,连续抓几个)进行分析,看问题是在环境还是在自己的组件中.从dump文件具体分析是哪一个函数哪个SQL出问题,如果多个dump文件都发现问题在某个函数上,可以确认问题是该函数引起。同时建议：1)中间层服务器安装VB6sp6Runtime,sp6改正了在中间层服务器出现消息或打印命令会造成COM+组件死锁等的问题,同时防止COM+组件的内存泄露；2)定时地更新微软COM+的ServicePack,微软每个月会更新COM+hotfixes,解决出现的COM+问题,是一个COM+的问题和解决方案库,这些ServicePack一般会包含在微软的安全性补丁中,可以从微软获取；3)Vc组件中不要定义全局的t-bstr类变量，否则会造成死锁。注意：中间层服务器安装最新的VBRUNTIME，同时定时更新微软的ServicePack。2.3.1.3客户端在日常处理中，偶发性出现“组件正在调用中间层…”的提示1、问题描述：客户端在日常处理中，偶发性出现“组件正在调用中间层…”的提示，出现该提示后，客户端K/3无响应，无法做任何操作。而且一台客户端出现该问题后，其他客户端也相继会出现该问题，最后只有重启COM＋服务，问题才能解决。该问题一天偶尔出现一次，有时几天出现一次。有时一个用户使用，也会出现该问题。2、问题分析：出现该问题时：1)客户端，用户无法操作，做任何操作，都提示“组件正在调用中间层…”，等候一会，仍然无法使用。2)中间层，所有组件运行无异常（没有耗时特别长的组件）3)数据库，无堵塞，无死锁，无耗时很长的SQL。4)重启中间层后，问题可以解决。分析：“组件正在调用中间层…”的提示，表示系统出现了挂起。根据问题的初步分析，估计和COM＋有关，并且和使用Win2003系统有关系。分别抓取了客户端KdMain的Dump文件，和中间层eboK/3的Dump文件，然后和微软工程师联系，将Dump文件发给他们。客户端Dump表明，客户端出现了挂起，同时中间层Dump表明，Rpc调用出现挂起。该现象属于微软已经确认的一个BUG，需要安装微软已经发出的补丁解决，或安装Win2003Sp1。3、解决方案：在K/3中间层安装了Win2003Sp1后，问题解决。(注意:安装Win2003SP1后，需要进行相关的COM＋安全设置，才能正常使用，需要修改的选项：COM＋设置中，增加了“远程激活”和“远程启动”权限，Everyone的该权限默认会被取消，必须选上)2.3.2通用案例2—-COM+配置/环境的问题2.3.2.1COM+SystemApplication服务意外地终止1、问题描述：表现为客户端挂起，用户无法操作，有的时候会提示“组件正在调用中间层…”，12金蝶K/3产品性能稳定性案例集有的时候没有任何信息，必须手工杀掉进程才能继续使用。查看中间层的组件服务，表现正常。2、问题分析：出现这个问题后，查看中间层服务器上的系统事件日志，事件日志,有下面的信息:7031ServiceControlManagerCOM+SystemApplication服务意外地终止，这种情况已经出现了1次。以下的修正操作将在1000毫秒内运行:重新启动服务。7034ServiceControlManager服务COM+SystemApplication意外停止。这发生了3次。7032ServiceControlManager在COM+SystemApplication服务意外终止后，“服务控制管理器”试着进行修正操作(重新启动服务)，但这个操作失败，错误是:服务的范例已在运行中。原因:1)“有些系统文件被损坏”；2)“文件权限问题”；3)组件服务中的程序有BUG；4)微软操作系统的BUG等。相关事件号的描述可以查阅微软网站。3、解决方案：如果出现这样的问题，可以确定是中间层的COM+服务已经崩溃，此时只能重新安装操作系统解决。注：文件的破坏很多时候可能是由于病毒引起的，所以定期更新病毒库和杀毒非常重要。2.3.2.2K/3V10.2登录时提示“路径/文件访问错误”K/3V10.2，如果登陆出现“路径/文件访问错误”错误，请修改COM+包的kdsvrmgr的标识为交互式用户。如下图：13金蝶K/3产品性能稳定性案例集此外，如果是帐套管理无法登陆，也是该问题。2.3.2.3K/3系统在Win2003环境的设置指南WindowsServer2003是迄今为止微软最强大的Windows服务器操作系统，它在运行效率、可靠性、安全性方面均有了巨大的进步与提高，针对WebServices、网络应用、企业级高端计算等方面有更强大的功能支持。为了支持该优秀平台，K/3系统在Win2003环境下进行了大量的测试，除了证明K/3系统完全支持Win2003，还验证了该Win2003的强大特性，K/3系统在该环境下运行性能更加稳定，更加充分发挥三层结构的优势。K/3V10.2版本前，在WIN2003装K/3系统需要启用网络DTC访问，网络COM+访问，IIS等环境并进行一些简单配置，安装后也需要对COM+，IIS等进行一些配置才能运行K/3系统，相关配置请参考下面文档说明：注意：WindowsServer2003SP1/SP2的相关设置与未装SP1/SP2的2003不一样，2003SP1/SP2的用户请参阅下一节《Win2003系统安装SP1后K/3系统不能使用的解决方法》2.3.2.4Win2003系统安装SP1后K/3系统不能使用的解决方法微软推出Win2003操作系统以来，其良好的性能及稳定性获得大量用户的好评，但如此庞大的一个系统无可避免会在安全性上有漏洞，微软及时推出相应的SP1。SP1通过提供诸如安全配置向导之类的新安全工具增强了安全基础结构，它有助于确保服务器的基于角色的操作的安全、通过数据执行保护提高纵深防御能力并通过后安装安全更新向导提供安全可靠的第一次引导方案。但SP1的相关安全设置也导致了K/3在应用上出现错误，需要对其进行相应的配14金蝶K/3产品性能稳定性案例集置，相关配置请参考下面文档进行：注意：K/3V10.2以前版本在WIN2003操作系统上安装时没有自动进行2003环境配置，需要参照该文档进行2.3.2.32.3.2.5登录出现“automation”错误1、问题描述：进入主控台出现“automation”错误。2、问题分析：一般主控台登录出现“automation”错误有两种情况造成，一是客户端本机装有K/3中间层的包或卸载不干净，另一是没有卸载老版本K/3就直接安装安装新版本造成的（或者老版本卸载时有问题），导致客户端的注册表混乱造成的。3、解决方案：“冲击波”病毒出现后、微软出了针对性补丁加强了系统安全，这时客户端若远程连接中间层，必须确保本机不能有K/3中间层的包，否则会出现“automation”错误。针对没有卸载老版本K/3就直接安装安装新版本造成的（或者老版本卸载时有问题），导致客户端的注册表混乱造成的，请参照下面方法处理：1)确认客户端kdsvrmgr.vbr和中间层kdsvrmgr.exe最后修改时间一致。2)把老版本的kdsvrmgr.vbr拷贝到system32目录下,在客户端先执行clireg32-u-nologox:\winnt\system32\kdsvrmgr.vbr，清除老版本组件的注册信息3)把新版本的kdsvrmgr.vbr拷贝到system32目录下,在客户端再执行clireg32-d-nologo-sxx.xx.xx.xxx:\winnt\system32\kdsvrmgr.vbr，注册新版本组件的客户端信息(xx.xx.xx.xx指中间层的IP地址)4)若问题不能解决，请在客户端执行一下RegClear清除K/3注册信息再安装K/3。注意：“冲击波”病毒出现后、微软出了针对性补丁加强了系统安全，这时客户端若远程连接中间层，必须确保本机不能有K/3中间层的包。2.3.2.6COM+在组件服务中被多次注册1、问题描述：K/3中的同一个组件服务，在COM+组件服务中被同时注册了多次，从而导致K/3系统运行发生错误。2、特点：Prog标识相同，但CLSID不一致15金蝶K/3产品性能稳定性案例集3、解决方法：删除重复的组件.
