金蝶K/3產品性能穩定性案例集金蝶金蝶K/3K/3產品性能穩定性案例集產品性能穩定性案例集 金蝶軟體(中國)有限公司K/3產品事業部.設計部解釋目的本案例集是我們在處理K/3系統應用過程中遇到性能問題的解決方法與方案總結,旨在幫助技術支援人員、分支機搆實施服務人員以及客戶更快速解決相關性能問題；同時也指導我們的實施服務人員和客戶在實施中如何預防和避免將來可能發生的性能穩定性問題。適合對象本案例集的主要閱讀物件是K/3系統研發人員、技術支援人員、實施人員、客戶服務人員和公司授權的有一定技術能力的客戶系統管理員。導讀本案例集首先是按照網路、資料庫、中間層、用戶端層次來介紹實際遇到的通用案例,包括問題的描述,分析以及解決方案，接著以K/3產品發展的主線分版本來列舉對應的案例以及處理方案，請您根據您的需要選擇相應的章節閱讀。注意:由於此案例集可能牽涉一些K/3在技術方面的細節，為了防止有些人用意不良，斷章取義來攻擊K/3產品和公司，請注意保密。1金蝶K/3產品性能穩定性案例集目錄目錄..-2-1.性能案例總體分析步驟.-4-2.總體通用性能問題案例.62.1網路與Citrix性能問題案例..62.1.1通用案例1—-網路架構問題..62.1.2通用案例2—-病毒導致網路問題..62.1.3通用案例3—-Citrix服務端記憶體問題..62.1.4通用案例4—-應用Citrix列印問題..72.2資料庫性能問題案例..92.2.1通用案例1—-資料庫日誌檔過大..92.2.2通用案例2—-資料檔案大小不正常..92.2.3通用案例3—-Tempdb日誌過大.102.2.4通用案例4—-資料庫伺服器硬體問題.102.2.5通用案例5—-系統整體運行速度非常慢.122.3中間層COM+性能問題案例.122.3.1通用案例1—-COM+掛起.132.3.2通用案例2—-COM+配置/環境的問題..152.3.3通用案例3—-CPU100%..242.3.4通用案例4—-COM+性能問題.252.3.5通用案例5—-COM+安全性的問題.252.3.6通用案例6—-COM+其他的問題.272.4用戶端性能問題案例..292.4.1通用案例1—-用戶端突然出現全面的死機現象.292.4.2通用案例2—-用戶端出現“新事務不能登記到指定的事務處理器中”..302.4.3通用案例3—-USER組用戶許可權問題..333.各歷史版本性能問題案例.343.1.K/3V9.1性能問題案例.343.1.1在打開往來對帳時速度非常慢,伺服器CPU佔用100%.343.2.K/3V10.0性能問題案例.343.2.1K/3資料授權導致F7、單據查看、序時簿查看、選單關聯速度很慢(工業類型賬套).343.2.2出入庫單據丟失.343.2.3應收沖應付的單據生成憑證時導致資料庫伺服器鎖死.353.3.K/3V10.1性能問題案例.353.3.1K/3資料授權導致F7、單據查看、序時簿查看、選單關聯速度很慢(工業類型賬套).353.3.2憑證錄入性能問題.363.3.2報表查詢時資料庫伺服器CPU佔用100%.363.3.3進行匹配內部往來機構時速度特別慢.363.3.4採購收貨單序時簿查詢慢、銷售發票序時簿慢的問題（商業類型賬套）2金蝶K/3產品性能穩定性案例集..373.3.5銷售發票生成憑證慢的問題（商業類型賬套）.373.4.K/3V10.2性能問題案例.373.4.7物料需求計劃性能優化.413.4.8員工異動、入職、工資導入性能慢.413.5.K/3V10.3性能問題案例.423.5.1單據上下查功能..423.5.2啟用折扣管理後性能不理想.423.6.K/3V10.4性能問題案例.423.6.1信用管理不能啟用..423.6.2進出口、應收應付某些BOS單據載入、保存、F7多選返回時速度很慢433金蝶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+元件的安全驗證選項，如下圖所示。降低身份驗證級別，能夠在一定程度上改善調用中間層元件的性能。4金蝶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開發部溝通，獲得解決方案。5金蝶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分鐘後，重新接通電源，觀察網路是否恢復正常。2.1.3通用案例3—-Citrix服務端記憶體問題6金蝶K/3產品性能穩定性案例集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印表機列印不正常，主要表現是映射正常，列印資料檔案也能正常傳輸到用戶端，但在用戶端的列印任務管理7金蝶K/3產品性能穩定性案例集器始終不列印，埠也正常映射到USB口。但在WINDOWS終端模式下列印正常，在CITRIX終端GUI與WEB模式都不能列印。在伺服器上安裝HP1020列印驅動，禁用【啟用雙向支持】：在用戶端按上設置即可，重新登陸.問題三：缺省紙張的問題。1)必須使用本地列印驅動，即在伺服器上安裝用戶端印表機的驅動，而不是使用通用驅動列印。ManagementConsole—>PrinterManagement—>Properties—>Drivers—>NativeDriversonly(如無特殊印表機最好選擇此項)，缺省為：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的資料檔案變得不正常，大小和客戶的資料量從經驗上很不相符，8金蝶K/3產品性能穩定性案例集這種異常會很大地影響系統性能，還有可能引發錯誤。2、問題分析：該問題主要是由於有些表沒有建立聚集索引引發，需要運行工具來分析檢查。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資9金蝶K/3產品性能穩定性案例集料庫的資料量相比太小，則tempdb資料庫可能需要始終擴展，因而將妨害性能。3)最好設置資料庫檔的增長方式為按指定的位元組數方式，建議設置為200MB。4)將tempdb資料庫放在快速I/O子系統上以確保好的性能。在多個磁片上條帶化tempdb資料庫以獲得更好的性能。使用檔組將tempdb資料庫放在除用戶資料庫所使用的磁片之外的磁片上。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，說明恢復過程已完成。但至少一個通過資源管理器登記的事務的狀態仍然是“不確定”資料庫：10金蝶K/3產品性能穩定性案例集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)（物件ID1384001053，索引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，核對一下是否有的表佔用的空間過大沒有釋放，可以優化一下該類表的索引結構，把過多的空間釋放出來；11金蝶K/3產品性能穩定性案例集8)對於查詢比較慢的單據可以把SQL跟蹤出來，然後用查詢分析器運行索引優化嚮導，序時簿相關關聯表增加索引；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、問題分析：問題出現後，首先通過各種測試對問題進行排查和分析，包括：1)通過sp_lock以及usemasterselect*fromsysprocesses查詢，發現資料庫並沒有出現阻塞；2)COM+中有事務的元件出現掛起，調用時間不斷增加；3)編寫程式通過連接串連接資料庫沒有問題；4)中間層組件能夠被成功創建；5)編寫程式直接通過中間層元件取數沒有問題；6)通過中間層創建中間層調用時出現-正在調用中間層-，發生掛起，測試代碼說明如下：對問題進行排查後發現通過中間層創建中間層調用時出現掛起，但其他環境應用並沒有此問題，因而初步確定應該是環境問題，通過嘗試修改DIIHOST的MAXTHREAD依然沒有效果。進一步瞭解後得知機器是克隆的，由於MSDTC協調器都有一個GUID唯一標識，12金蝶K/3產品性能穩定性案例集但是克隆機器也把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、解決方案：按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、問題描述：用戶端在日常處理中，偶發性出現“元件正在調用中間層…”的提示，出現該提示13金蝶K/3產品性能穩定性案例集後，用戶端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、問題描述：表現為用戶端掛起，用戶無法操作，有的時候會提示“元件正在調用中間層…”，有的時候沒有任何資訊，必須手工殺掉進程才能繼續使用。查看中間層的元件服務，表現正常。2、問題分析：出現這個問題後，查看中間層伺服器上的系統事件日誌，事件日誌,有下面的資訊:7031ServiceControlManagerCOM+SystemApplication服務意外地終止，這種情況已經出現了1次。以下的修正操作將在1000毫秒內運行:重新啟動服務。7034ServiceControlManager服務COM+SystemApplication意外停止。這發生了3次。7032ServiceControlManager在COM+SystemApplication服務意外終止後，“服務控制管理器”試著進行修正操作(重新啟動服務)，但這個操作失敗，錯誤是:服務的範例已在運行中。原因:1)“有些系統檔被損壞”；14金蝶K/3產品性能穩定性案例集2)“文件許可權問題”；3)元件服務中的程式有BUG；4)微軟作業系統的BUG等。相關事件號的描述可以查閱微軟網站。3、解決方案：如果出現這樣的問題，可以確定是中間層的COM+服務已經崩潰，此時只能重新安裝作業系統解決。注：檔的破壞很多時候可能是由於病毒引起的，所以定期更新病毒庫和殺毒非常重要。2.3.2.2K/3V10.2登錄時提示“路徑/檔訪問錯誤”K/3V10.2，如果登陸出現“路徑/檔訪問錯誤”錯誤，請修改COM+包的kdsvrmgr的標識為互動式用戶。如下圖：此外，如果是帳套管理無法登陸，也是該問題。2.3.2.3K/3系統在Win2003環境的設置指南WindowsServer2003是迄今為止微軟最強大的Windows伺服器作業系統，它在運行效率、可靠性、安全性方面均有了巨大的進步與提高，針對WebServices、網路應用、企業級高端計算等方面有更強大的功能支持。為了支援該優秀平臺，K/3系統在Win2003環境下進行了大量的測試，除了證明K/3系統完全支援Win2003，還驗證了該Win2003的強大特性，K/3系統在該環境下運行性能更加穩定，更加充分發揮三層結構的優勢。15金蝶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在應用上出現錯誤，需要對其進行相應的配置，相關配置請參考下面文檔進行：注意：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，註冊新版本元16金蝶K/3產品性能穩定性案例集件的用戶端資訊(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不一致3、解決方法：刪除重複的元件，重新加入到元件服務中。注意：在編譯COM+元件的時候，注意.
