【正文】 件所花費(fèi)的時(shí)間總計(jì)（以毫秒為單位）。如果在跟蹤內(nèi)捕獲 Server Name資料列且伺服器可用，則 SQL 事件探查器將顯示資料庫名。 Column Permissions44表明是否已設(shè)置了列許可權(quán)。 該列由應(yīng)用程式傳遞的值填充，而不是由所顯示的程式名填充。對(duì)選定的資料庫伺服器進(jìn)行一定事件的跟蹤，然後另存為跟蹤文件，如下圖：可以對(duì)資料列：CPU（事件所使用的CPU事件，毫秒為單位），Reads（伺服器代表事件執(zhí)行的邏輯磁片讀取數(shù)），Writes（伺服器代表事件執(zhí)行的物理磁片寫入數(shù)），Duration（事件所花費(fèi)的事件總計(jì)，毫秒為單位）進(jìn)行查看，查找讀取或?qū)懭胛锢泶牌螖?shù)多的操作，耗時(shí)比較多的操作。主要用來跟蹤SQL語句和存儲(chǔ)過程的事件，通常情況下只要設(shè)置TSQL事件類的SQL:BatchCompleted，SQL:StmtCompleted事件和存儲(chǔ)過程事件類RPC:Completed、SP:Completed，SP:stmtCompleted事件即可。監(jiān)視 SQL Server 的性能以精細(xì)地調(diào)整工作負(fù)荷。SQL 事件探查器用於以下活動(dòng)： 逐步分析有問題的查詢以找到問題的原因。 SQL Server的事件探查器（SQLPROFILE）主要用來跟蹤資料庫的SQL執(zhí)行情況，發(fā)現(xiàn)耗時(shí)較長(zhǎng)的SQL,從而發(fā)現(xiàn)影響性能的原因,分支機(jī)搆可以使用此工具得到跟蹤檔，把跟蹤檔返回到研發(fā)，用來分析和定位問題。如果不能優(yōu)化軟體本身，升級(jí)硬體，增加CPU的個(gè)數(shù)可能是需要的。1）CPU持續(xù)100%一段時(shí)間如果發(fā)現(xiàn)資料庫CPU在某一段時(shí)間持續(xù)達(dá)到100%,成一條直線狀，這可以判斷是某項(xiàng)功能耗用了全部的CPU資源，這項(xiàng)功能如果是很少使用的計(jì)算功能或者是大資料量查詢，建議適當(dāng)安排,不要在業(yè)務(wù)高峰期運(yùn)行，如果是日常功能絕對(duì)需要優(yōu)化。是否還有別的系統(tǒng)（除K/3）消耗了寶貴的CPU和記憶體資源。一) 使用方法要打開“任務(wù)管理器”，請(qǐng)用右鍵單擊任務(wù)欄上的空白處，然後單擊“任務(wù)管理器”，或者把 “Ctrl+Alt+Delete”三個(gè)鍵同時(shí)按下，選擇“任務(wù)管理器”。 注意由於此手冊(cè)可能牽涉一些K/3在技術(shù)方面的細(xì)節(jié)，為了防止有些人用意不良，斷章取義來攻擊K/3和公司，請(qǐng)注意保密。適合對(duì)象 本手冊(cè)的主要閱讀物件是K/3系統(tǒng)研發(fā)人員、技術(shù)支援人員、實(shí)施人員、客戶服務(wù)人員和公司授權(quán)的有一定技術(shù)能力的客戶系統(tǒng)管理員。 金蝶K/3產(chǎn)品性能穩(wěn)定性優(yōu)化指導(dǎo)手冊(cè)(輔助工具)（）227?；仞伇臼謨?cè)是對(duì)研發(fā)在處理客戶性能和穩(wěn)定性問題的收集和總結(jié)，所以涉及到的面有可能還不夠。50 / 50目錄目錄 2輔助分析工具介紹 3 WINDOWS任務(wù)管理器 3 SQL Server的事件探查器（SQLPROFILE） 4 資料庫阻塞監(jiān)測(cè)工具 11 K/3性能監(jiān)控工具 13 元件服務(wù) 15 17 性能監(jiān)視器(Performance Monitor) 19 VBCheckW2k 23 ADPlus 23 COM+ SPY 26 Process Explorer 27 DebugDiag 29 WinDBG 32 32 32 Ping 32 Netstat 34 ARP（位址轉(zhuǎn)換協(xié)定） 34 Tracert 35 IPConfig 36 Route 36 nbtstat 37 使用 pathping 測(cè)試路由器 37 網(wǎng)路診斷實(shí)例： 39附錄1：應(yīng)用/測(cè)試環(huán)境 41附錄2：DTC一些資料 41附錄3 中間層COM+問題分類和處理 421．問題分類 42 COM+的掛起 42 COM+ 出現(xiàn) 100% CPU 43 COM+ 性能問題 44 COM+ 異常 44 COM+ 應(yīng)用記憶體洩漏 442. COM+問題分類分析和處理方法 46 COM+掛起 46 CPU100% 49 49 COM+ 異常 51 51輔助分析工具介紹如果系統(tǒng)出現(xiàn)問題，由於產(chǎn)生問題的原因很多，可能是COM+元件出現(xiàn)了問題，或者是SQL Server資料庫的出現(xiàn)了問題，或者作業(yè)系統(tǒng)本身就存在問題，或者是網(wǎng)路存在問題。 * 選擇“性能”選項(xiàng)卡，如下圖：可以發(fā)現(xiàn)系統(tǒng)CPU和記憶體的使用情況。下圖中可以看出SQL Server消耗了系統(tǒng)91％的CPU，K/3消耗了8%的CPU。如果能夠直接判斷是某項(xiàng)具體的功能最好，如果在併發(fā)下無法判斷到底是何功能。在這兒要說明一點(diǎn)，不能認(rèn)為CPU達(dá)到100%才是CPU資源不足。這是最有效的定位分析問題的手段。查找並診斷運(yùn)行慢的查詢。1）啟動(dòng)事件探查器工具在“開始”功能表，依次指向“程式”、“Microsoft SQL Server”，然後單擊“事件探查器”。4）選擇“資料列”選項(xiàng)卡，如下圖：在該圖中選擇要捕獲的數(shù)據(jù)列。為查找性能問題提供有力的證據(jù)，對(duì)性能優(yōu)化也具有參考的價(jià)值。 Binary Data2與在跟蹤中捕獲的事件類相關(guān)的二進(jìn)位值。分析語句文本，以確定將哪些許可權(quán)應(yīng)用到了哪些列。 通過使用 DB_ID 函數(shù)確定資料庫的值。 End Time 15事件結(jié)束時(shí)的時(shí)間。EventClass127捕獲的事件類類型。2 = 查詢超時(shí)。 Handle33ODBC、OLE DB 或 DBLibrary 所用的整數(shù)，用以協(xié)調(diào)伺服器的執(zhí)行。Index ID24受事件影響的物件上的索引 ID。 登錄憑據(jù)，格式為 DOMAIN\Username）。 Mode32不同事件所用的整數(shù)，用於描述事件已接收或要請(qǐng)求的狀態(tài)。 NT User Name16Windows NT 或 Windows 2000 用戶名。該值對(duì)應(yīng)於 sysobjects 中的 type 列。RoleName38要啟用的應(yīng)用程式角色名。Start Time114啟動(dòng)事件的時(shí)間（可用時(shí)）。0 = 失敗　例如，1 表示許可權(quán)檢查成功，0 表示該檢查失敗。TextData1與跟蹤內(nèi)捕獲的事件類相關(guān)的文本值。二. 一些使用技巧n 在選擇要跟蹤的事件時(shí)不要使用默認(rèn)設(shè)置，一定要按照上面使用方法中的描述選擇部分事件，否則會(huì)跟蹤到很多無用的連接或回話資訊。在保存時(shí)要選擇保存為跟蹤檔（默認(rèn)是這樣），保存為其他格式會(huì)丟失分析性能的資料，以前有分支機(jī)搆的人員就是保存為SQL腳本發(fā)給研發(fā)，這對(duì)分析問題毫無價(jià)值。如何跟蹤觸發(fā)器在跟蹤SQL的時(shí)候，可能會(huì)發(fā)現(xiàn)即使單條的Insert、Deleted、Update語句都會(huì)很慢。如：MasterDetail表資料結(jié)構(gòu)中，Detail表中的觸發(fā)器只能處理一條Detail中的資料。使用SQL Server Profiler是可以跟蹤到觸發(fā)器的執(zhí)行情況的，選擇事件中的存儲(chǔ)過程SP：StmtCompleted事件即可以跟蹤觸發(fā)器的運(yùn)行情況；選中NestLevel資料列則可以很好的瞭解到觸發(fā)器嵌套運(yùn)行情況?；蛘呖梢园袲uration較長(zhǎng)的SQL回饋到研發(fā)來分析。關(guān)注CPU和Duration兩列的資料對(duì)比情況，可以判斷CPU資源是否足夠，如果大多數(shù)SQL語句的CPU列資料明顯低於Duration，如果CPU曲線又很高，沒有發(fā)生嚴(yán)重的阻塞，我們可以認(rèn)為CPU的處理佇列太長(zhǎng)，需要增加CPU資源。在發(fā)生性能問題時(shí)在查詢分析中有問題的賬套上執(zhí)行如下SQL。用戶端診斷工具用於跟蹤後期綁定元件的介面物件創(chuàng)建、方法調(diào)用、運(yùn)行時(shí)間、執(zhí)行結(jié)果資訊等情況。K/3 ，遇到大量元件創(chuàng)建失敗情況，通過該工具迅速定位到創(chuàng)建失敗的元件，極大提高了解決安裝包問題的速度。n 將物件創(chuàng)建事件和方法調(diào)用事件分別用不同顏色顯示，便於識(shí)別；同時(shí)將沒有嵌套的方法調(diào)用使用一行來顯示用戶端代碼級(jí)監(jiān)測(cè)工具用於關(guān)鍵函數(shù)的運(yùn)行資訊的輸出，方便在客戶環(huán)境下定位程式問題、並提供性能資料收集。1）啟動(dòng)元件服務(wù)管理工具在“開始”功能表，依次指向“程式”、“管理工具”，然後單擊“元件服務(wù)”。介面如下圖：二) 如何找到正在執(zhí)行的資源耗用多的組件有時(shí)候如果中間層的CPU或記憶體耗用很嚴(yán)重，由於在多個(gè)客戶的併發(fā)下有時(shí)候客戶很難發(fā)現(xiàn)是那一項(xiàng)操作引發(fā)了問題，這時(shí)候可以找一下那一個(gè)元件包中的哪一個(gè)元件耗用資源比較嚴(yán)重，配合其他的觀察：如在此階段用戶都在做那些操作，有助於發(fā)現(xiàn)引發(fā)問題的功能。四) 關(guān)於STA模式COM+元件線程數(shù)限制問題對(duì)於VB編寫的COM+元件，由於不能編譯為MTA線程模型，每個(gè)元件包進(jìn)程的線程數(shù)默認(rèn)為10個(gè)，也就是說同一個(gè)元件包中所有元件功能只能最多有十個(gè)同時(shí)運(yùn)行。 修改默認(rèn)設(shè)置後，會(huì)提高中間層的併發(fā)性能。例如你觀察到 SQL Server 對(duì)某個(gè)查詢的回應(yīng)遲緩，可能需要同時(shí)觀察系統(tǒng)硬體各項(xiàng)資源的使用，SQL Server 當(dāng)時(shí)的鎖狀況，是否有錯(cuò)誤發(fā)生等等，必須要互相參照，才容易找出禍?zhǔn)?。?dāng)然，若有錯(cuò)誤，也會(huì)存放在這個(gè)檔中，SQLDiag 默認(rèn)會(huì)將這些 ErrorLog 檔一併放到輸出結(jié)果的檔內(nèi)。 l 通過 sp_who 系統(tǒng)存儲(chǔ)過程獲取當(dāng)前登錄 SQL Server 執(zhí)行實(shí)例的用戶各項(xiàng)細(xì)節(jié)。 l 通過 sp_helpextendedproc 系統(tǒng)存儲(chǔ)過程獲取擴(kuò)展存儲(chǔ)過程(extended stored procedures)的相關(guān)資訊。當(dāng)系統(tǒng)忙碌時(shí)，你可以通過它觀察到底有哪些程式在伺服器內(nèi)執(zhí)行，各用了多少資源等等。 l 通過 DBCC INPUTBUFFER (spid) 獲取各進(jìn)程正在執(zhí)行的命令。 獲取系統(tǒng)資訊是靠 工具程式取得系統(tǒng)的相關(guān)資訊，你可以直接執(zhí)行該工具程式以查看更豐富的資訊，如下圖： 點(diǎn)擊 主功能表的[檔] [導(dǎo)出]選項(xiàng)，可以將系統(tǒng)當(dāng)前的各項(xiàng)資訊導(dǎo)出成文字檔案，供你日後參考。若不指定 –I 選項(xiàng)，則連接至本機(jī)默認(rèn)的執(zhí)行實(shí)例。密碼有區(qū)分大小寫。此時(shí)，跟蹤檔案名稱仍維持原先的 和 。 C：抽取聚集信息。我們?cè)谛阅苷{(diào)校的過程中會(huì)一再地用它。性能監(jiān)視器讓你獲得證據(jù)以完成： l 支持自己的假設(shè)，或是推翻結(jié)論另尋原因。除了一般的硬體，如記憶體、硬碟、中央處理器乃至於網(wǎng)路等系統(tǒng)提供的性能計(jì)數(shù)器外，大部分微軟提供的伺服器軟體在安裝完畢後，也會(huì)註冊(cè)它自身的性能計(jì)數(shù)器，而 SQL Server 會(huì)增加相當(dāng)多類的性能計(jì)數(shù)器供你查核使用狀況，而這些性能物件皆以“SQLServer:”開頭。而一旦採用遠(yuǎn)端監(jiān)控，要先同步兩臺(tái)機(jī)器的時(shí)間才好比對(duì)結(jié)果。例如有新的資料要放到屬性已滿的緩衝區(qū)，則 SQL Server 內(nèi)部負(fù)責(zé)將緩衝區(qū)屬性更新到硬碟的 LazyWriter 程式就需要持續(xù)地執(zhí)行，好更新緩衝區(qū)的資料，並釋放較沒有使用到的記憶體區(qū)塊，這會(huì)同時(shí)讓 CPU 與硬碟忙碌起來。因此建議將三種檔分別放在不同的硬碟上。因此當(dāng)考慮加強(qiáng)中央處理器時(shí)，要看看是否是周邊設(shè)備的不足，導(dǎo)致CPU忙碌。執(zhí)行性能監(jiān)視器時(shí)間要長(zhǎng)到足以抓取到問題，一般粗略的配置綱要如下：l 記錄2小時(shí) – 每 4 秒記錄一次。另外，為減輕對(duì)電腦長(zhǎng)期的影響，若沒有特殊需求，只要記錄 2 小時(shí)就好。初次記錄時(shí)，在不傷及性能的前提下，僅可能地抽取所有的物件，供你對(duì)整個(gè)系統(tǒng)有一個(gè)全面性的概觀。 一次記錄通常無法包含所有需要的資訊，可能要多次後續(xù)不同的記錄資料。日誌檔最大極限 1 gigabyte (GB)，而單一日誌檔太大也很難處理，可行的日誌檔大小應(yīng)該在 100 megabytes (MB) 左右，建議取 50 MB。使用 的步驟如下： 1. 查看日誌檔資料：打開先前抽取的 .blg 文件。 5. 保留你有興趣的計(jì)數(shù)器，將其餘的計(jì)數(shù)器刪掉，同時(shí)把所有的格式通通刪掉，只保留如下的格式屬性： [\\Computer]\Object[Parent/InstanceIndex]\Counter 若需要多個(gè)計(jì)數(shù)器，則每個(gè)名稱間以換行符號(hào)分開，範(fàn)例如下： \\BYRON2003NB\Memory\Pages/sec \\BYRON2003NB\PhysicalDisk(_Total)\Avg. Disk Queue Length \\BYRON2003NB\Processor(_Total)\% Processor Time 其中 \\Computer 名稱可以省略。過濾的結(jié)果將以逗號(hào)分隔的一般文字存檔，也就是默認(rèn)給 Excel 看的 .csv 檔，所以結(jié)果輸出到 檔中，你可以直接通過 Excel 打開查看分析。在查看資料時(shí)，應(yīng)先繪製全部記錄的圖表，以瞭解整體的趨勢(shì)。最後要注意的是不要利用 Windows NT 的 Perfmon 讀取 Windows 2000 Sysmon 產(chǎn)生的日誌檔當(dāng)要分析記錄所得的資料時(shí)，尋找某些模式，以及不正常之高或低的計(jì)數(shù)值，這有助於瞭解什麼是“正?！敝?，對(duì)建立基線是有幫助的，如果一個(gè)計(jì)數(shù)器顯示某個(gè)問題，可尋找其他的證據(jù)以支持你的理論，例如：l % Process Time 的值持續(xù)很高，瓶頸不一定是在 CPU 。不要忘了查看 SQL Profiler 跟蹤檔、errorlog，或其他相關(guān)資訊，有助於解釋你在性能記錄所看到的現(xiàn)象。ADPlus 可以創(chuàng)建不同場(chǎng)景下的詳細(xì)的dump檔。何時(shí)使用，何時(shí)不使用在系統(tǒng)出現(xiàn)下面的情況時(shí)，可以考慮使用ADPlus：l 進(jìn)程掛起l 在單個(gè)處理器電腦上100%的CPU，在雙CPU上50%CPU，在4個(gè)CPU上25% 的CPU等待l 進(jìn)程出現(xiàn)異常或者非正常的關(guān)閉但在下面的情況不要使用ADPlusl 如果需要對(duì)程式進(jìn)行故障檢查或者進(jìn)程啟動(dòng)時(shí)異常結(jié)束l 如在crash模式下使用對(duì)執(zhí)行性能有明顯的影響應(yīng)用場(chǎng)景ADPlus應(yīng)用的場(chǎng)景主要包括以下方面：l 進(jìn)程掛起或者消耗100%的CPUl 進(jìn)程異常結(jié)束l MTS或COM+服務(wù)應(yīng)用異常結(jié)束l 在遠(yuǎn)端Crash模式下運(yùn)行l(wèi) 在Crash模