金蝶金蝶K/3K/3產品性能穩定性優化指導手冊產品性能穩定性優化指導手冊((輔助工具輔助工具))（（V3.0V3.0）） 金蝶軟體(中國)有限公司研發中心K/3產品事業部.設計部解釋目的本手冊在於指導技術支援人員、分支機搆實施服務人員和客戶處理K/3系統應用過程中產生的性能問題、中間層伺服器問題等；同時也指導我們的實施服務人員和客戶在實施中如何避免將來可能發生的性能問題和中間層問題。讓研發人員、技術支援人員和分支機搆實施人員一起共同提高工作能力，快速反應快速解決客戶的問題。適合對象本手冊的主要閱讀物件是K/3系統研發人員、技術支援人員、實施人員、客戶服務人員和公司授權的有一定技術能力的客戶系統管理員。回饋本手冊是對研發在處理客戶性能和穩定性問題的收集和總結，所以涉及到的面有可能還不夠。完善本手冊，提供一個更加完整的客戶問題解決指導方案，離不開大家的支持，所以大家在碰到相關的問題時，請回饋K/3設計部，我們將及時對手冊更新。導讀本手冊包括資料庫、中間層、用戶端和輔助分析工具介紹四大篇，分別介紹K/3客戶性能和穩定性問題的處理方法、案例以及輔助工具，請您根據您的需要選擇相應的章節閱讀。注意由於此手冊可能牽涉一些K/3在技術方面的細節，為了防止有些人用意不良，斷章取義來攻擊K/3和公司，請注意保密。-1-金蝶K/3產品性能穩定性優化指導手冊（輔助工具）目錄目錄..2輔助分析工具介紹..31.1WINDOWS任務管理器..31.2SQLServer的事件探查器（SQL-PROFILE）..41.3資料庫阻塞監測工具.111.4K/3性能監控工具..131.5元件服務..151.6SQLDiag.exe.171.7性能監視器(PerformanceMonitor)..191.8VBCheckW2k.231.9ADPlus..231.10COM+SPY.261.11ProcessExplorer.271.12DebugDiag..291.13WinDBG.321.14收集電腦資訊工具.321.15檢查網路工具.321.15.1Ping..321.15.2Netstat..341.15.3ARP（位址轉換協定）..341.15.4Tracert..351.15.5IPConfig.361.15.6Route..361.15.7nbtstat.371.15.8使用pathping測試路由器..371.15.9網路診斷實例：..39附錄1：應用/測試環境..41附錄2：DTC一些資料..41附錄3中間層COM+問題分類和處理..421．問題分類..421.1COM+的掛起.421.2COM+出現100%CPU.431.3COM+性能問題..441.4COM+異常..441.5COM+應用記憶體洩漏..442.COM+問題分類分析和處理方法.462.1COM+掛起.462.2CPU100%.492.3性能問題.492.4COM+異常..51-2-金蝶K/3產品性能穩定性優化指導手冊（輔助工具）2.5記憶體洩露.51輔助分析工具介紹如果系統出現問題，由於產生問題的原因很多，可能是COM+元件出現了問題，或者是SQLServer資料庫的出現了問題，或者作業系統本身就存在問題，或者是網路存在問題。所以我們需要綜合多個可能的因素，使用一些輔助工具對系統進行跟蹤檢測，然後分析跟蹤的結果，最終找到問題所在。下面就常見的一些輔助工具作一個簡單的介紹：1.1WINDOWS任務管理器如果K/3系統很慢，是不是系統沒有可用的CPU和記憶體等資源了？Windows任務管理器可以幫助我們發現系統資源的使用情況。一)使用方法要打開“任務管理器”，請用右鍵單擊任務欄上的空白處，然後單擊“任務管理器”，或者把“Ctrl+Alt+Delete”三個鍵同時按下，選擇“任務管理器”。*選擇“性能”選項卡，如下圖：可以發現系統CPU和記憶體的使用情況。在系統出現性能問題時，監測一段時間系統資源的使用情況。*選擇“進程”選項卡，如下圖：如果在上圖中發現CPU或者記憶體的使用率比較高，通過該圖，可以發現資源究竟被哪些進程所消耗。是否還有別的系統（除K/3）消耗了寶貴的CPU和記憶體資源。下圖中可以看出SQLServer消耗了系統91％的CPU，K/3消耗了8%的CPU。-3-金蝶K/3產品性能穩定性優化指導手冊（輔助工具）二)資料庫伺服器CPU曲線的一些典型結論由於資料庫是K/3系統的瓶頸，我們主要觀察資料庫伺服器的性能，通過觀察資料庫伺服器CPU的運行曲線，可以得出一些典型結論。特別說明要觀察一段時間的CPU運行狀態，而不是看一瞬間的狀態。1）CPU持續100%一段時間如果發現資料庫CPU在某一段時間持續達到100%,成一條直線狀，這可以判斷是某項功能耗用了全部的CPU資源，這項功能如果是很少使用的計算功能或者是大資料量查詢，建議適當安排,不要在業務高峰期運行，如果是日常功能絕對需要優化。如果能夠直接判斷是某項具體的功能最好，如果在併發下無法判斷到底是何功能。可以通過SQL-PROFILE跟蹤執行時間較長的SQL。2）CPU大多數時間保持在40%以上如果資料庫伺服器CPU長期保持在40%以上，系統的運行速度時快時慢，這表示CPU的負荷已經很重。如果不能優化軟體本身，升級硬體，增加CPU的個數可能是需要的。在這兒要說明一點，不能認為CPU達到100%才是CPU資源不足。3）良好的CPU狀態良好的CPU狀態是CPU能夠經常跌落到40%以下，並且可以跌落到0。三)判斷資料庫記憶體是否夠用的一種簡單方法在任務管理器中選擇查看-顯示內核時間，會顯示一條紅線，可以理解為磁片讀寫的時間，如果紅線很高證明大量的磁片讀寫操作，說明記憶體可能不夠，需要大量的記憶體切換。1.2SQLServer的事件探查器（SQL-PROFILE）主要用來跟蹤資料庫的SQL執行情況，發現耗時較長的SQL,從而發現影響性能的原因,-4-金蝶K/3產品性能穩定性優化指導手冊（輔助工具）分支機搆可以使用此工具得到跟蹤檔，把跟蹤檔返回到研發，用來分析和定位問題。這是最有效的定位分析問題的手段。一.使用方法K/3出現性能問題，很多都是與SQLSever資料相關。是否是一次查詢了太多的資料造成資料庫負載過大，出現性能問題？使用該工具可以使我們發現是哪些SQL語句消耗了SQLServer資料庫的資源，對於發現性能問題會很有幫助，特別是給研發的軟體工程師們。SQL事件探查器用於以下活動：逐步分析有問題的查詢以找到問題的原因。查找並診斷運行慢的查詢。捕獲導致某個問題的一系列SQL語句。然後用所保存的跟蹤在某台測試伺服器上複製此問題，接著在該測試伺服器上診斷問題。監視SQLServer的性能以精細地調整工作負荷。1）啟動事件探查器工具在“開始”功能表，依次指向“程式”、“MicrosoftSQLServer”，然後單擊“事件探查器”。2）打開該程式後選擇“檔”功能表的“新建”的子功能表“跟蹤”，打開如下的介面：選擇SQLServer伺服器名稱（或者輸入IP位址，如果是本機器可以輸入“.”英文句號），然後輸入SQLServer的身份驗證登陸名和密碼，可以和資料庫管理員聯繫。3）選擇“事件”選項卡在該圖中設置需要跟蹤的SQLServer事件類。主要用來跟蹤SQL語句和存儲過程的事件，通常情況下只要設置TSQL事件類的SQL:BatchCompleted，SQL:StmtCompleted事件和存儲過程事件類RPC:Completed、SP:Completed，SP:stmtCompleted事件即可。-5-金蝶K/3產品性能穩定性優化指導手冊（輔助工具）4）選擇“資料列”選項卡，如下圖：在該圖中選擇要捕獲的數據列。建議把左邊的資料列全部添加到選定的資料列表中，捕獲完整，充分的資訊。-6-金蝶K/3產品性能穩定性優化指導手冊（輔助工具）設置完上面的資訊後，點擊“運行”按鈕。對選定的資料庫伺服器進行一定事件的跟蹤，然後另存為跟蹤文件，如下圖：可以對資料列：CPU（事件所使用的CPU事件，毫秒為單位），Reads（伺服器代表事件執行的邏輯磁片讀取數），Writes（伺服器代表事件執行的物理磁片寫入數），Duration（事件所花費的事件總計，毫秒為單位）進行查看，查找讀取或寫入物理磁片次數多的操作，耗時比較多的操作。為查找性能問題提供有力的證據，對性能優化也具有參考的價值。各個資料列的具體含義列舉如下表，以供參考查閱。-7-金蝶K/3產品性能穩定性優化指導手冊（輔助工具）數據列列號描述ApplicationName110創建與SQLServer實例的連接的用戶端應用程式名。該列由應用程式傳遞的值填充，而不是由所顯示的程式名填充。BinaryData2與在跟蹤中捕獲的事件類相關的二進位值。ClientProcessID19由主機電腦分配給進程的ID，在該進程中客戶應用程式正在運行。如果用戶端提供用戶端進程ID，則填充此資料列。ColumnPermissions44表明是否已設置了列許可權。分析語句文本，以確定將哪些許可權應用到了哪些列。CPU18事件所使用的CPU時間總計（以毫秒為單位）。DatabaseID13USEdatabase語句所指定的資料庫ID，如果沒有對給定實例發出過USEdatabase語句，則是默認資料庫。如果在跟蹤內捕獲ServerName資料列且伺服器可用，則SQL事件探查器將顯示資料庫名。通過使用DB_ID函數確定資料庫的值。DatabaseName35正在運行用戶語句的資料庫的名稱。DBUserName140用戶端的SQLServer用戶名。Duration13事件所花費的時間總計（以毫秒為單位）。EndTime15事件結束時的時間。啟動事件的事件類（如SQL:BatchStarting或SP:Starting）的該列不填充。Error31給定事件的錯誤號。通常是存儲在sysmessages中的錯誤號。EventClass127捕獲的事件類類型。EventSubClass121事件子類的類型，提供有關每個事件類的進一步資訊。例如，ExecutionWarning事件類的事件子類值代表執行警告的類型：1=查詢等待。查詢必須等待資源（如記憶體）才能執行。2=查詢超時。查詢在等待執行所需的資源時超時。所有事件類的該資料列均不填充。FileName36所修改的檔的邏輯名稱。Handle33ODBC、OLEDB或DB-Library所用的整數，用以協調伺服器的執行。HostName18正運行用戶端的電腦名。如果用戶端提供主機名，則填充此資料列。若要確定主機名，請使用HOST_NAME函數。IndexID24受事件影響的物件上的索引ID。若要確定物件的索引ID，請使用sysindexes系統表的indid列。IntegerData25與在跟蹤中捕獲的事件類相關的整型值。LoginName11用戶的登錄名（SQLServer安全登錄或MicrosoftWindows®登錄憑據，格式為DOMAIN\Username）。LoginSid141登錄用戶的安全標識號(SID)。可以在master資料庫的sysxlogins表中找到該資訊。對於伺服器中的每個登錄，SID是唯一的。Mode32不同事件所用的整數，用於描述事件已接收或要請求的狀態。NestLevel29表示@@NESTLEVEL所返回的資料的整數。-8-金蝶K/3產品性能穩定性優化指導手冊（輔助工具）NTDomainName17用戶所屬的MicrosoftWindowsNT®4.0或Windows2000域。NTUserName16WindowsNT4.0或Windows2000用戶名。ObjectID22系統分配的物件ID。ObjectName34引用的對象名。ObjectType28表示事件中涉及的物件類型的值。該值對應於sysobjects中的type列。OwnerName37物件所有者的資料庫用戶名稱。Permissions19表示所檢查的許可權類型的整型值。取值為：1=SELECTALL2=UPDATEALL4=REFERENCESALL8=INSERT16=DELETE32=EXECUTE（僅限於過程）4096=SELECTANY（至少一列）8192=UPDATEANY16384=REFERENCESANYReads16伺服器代表事件執行的邏輯磁片讀取數。RoleName38要啟用的應用程式角色名。ServerName126跟蹤的SQLServer實例名。Severity20異常錯誤的嚴重級別。SPID112SQLServer指派的與客戶端相關的伺服器進程ID。StartTime114啟動事件的時間（可用時）。State30等同於錯誤狀態代碼。Success23表示事件是否成功。取值包括：1=成功。0=失敗例如，1表示許可權檢查成功，0表示該檢查失敗。TargetLoginName42對於以登錄為目標的操作（例如，添加新登錄），是目標登錄的名稱。TargetLoginSid43對於以目標為登錄的操作（例如，添加新登錄），是目標登錄的SID。TargetUserName39對於以資料庫用戶為目標的操作（例如授予用戶許可權），是該用戶的名稱。TextData1與跟蹤內捕獲的事件類相關的文本值。但是，如果正在跟蹤參數化查詢，則不以TextData列中的資料值顯示變數。-9-金蝶K/3產品性能穩定性優化指導手冊（輔助工具）TransactionID4系統分配的事務ID。Writes17伺服器代表事件執行的物理磁片寫入數。二.一些使用技巧在選擇要跟蹤的事件時不要使用默認設置，一定要按照上面使用方法中的描述選擇部分事件，否則會跟蹤到很多無用的連接或回話資訊。選擇SQL:BatchCompleted，SQL:StmtCompleted事件和存儲過程事件類RPC:Completed、SP:Completed，SP:stmtCompleted即可。如果發現某一段時間有規律的發生性能問題，需要事先跟蹤，跟蹤一段時間，而不是問題已經發生了再去跟蹤。跟蹤一段時間後，約1-2小時保存一次，否則跟蹤檔太大，耗用太多的記憶體會影響伺服器的記憶體。在保存時要選擇保存為跟蹤檔（默認是這樣），保存為其他格式會丟失分析性能的資料，以前有分支機搆的人員就是保存為SQL腳本發給研發，這對分析問題毫無價值。跟蹤檔可能會很大，但是壓縮比例很高，壓縮後作為《K/3性能問題診斷模版》的一部分回饋給研發。為了不使跟蹤檔過大，在篩選條件上選擇Duration>=200的事件，因為執行週期很短的SQL不是我們在性能分析中關注的重點物件，同時全部SQL都跟蹤會很多，設置如下。附件是一個跟蹤檔的模版，SQLServer本身也帶有很多的模版，在[SQLServer安裝目錄]\80\Tools\Templates\SQLProfiler路徑下，如果有興趣也可以學習使用。-10-金蝶K/3產品性能穩定性優化指導手冊（輔助工具）如何跟蹤觸發器在跟蹤SQL的時候，可能會發現即使單條的Insert、Deleted、Update語句都會很慢。這種情況下，有可能是請求的資源被鎖定或者CPU等硬體資源不足等。除此之外，還可以檢查是否是觸發器造成的。有些觸發器工作不良好：如使用游標來處理資料，或者由於觸發器的位置不對，使得本來可以批量處理的情況，只能單條處理。如：Master-Detail表資料結構中，Detail表中的觸發器只能處理一條Detail中的資料。而一般情況下，可以成批次處理Detail中的資料。通常開發人員也很少留意觸發器嵌套調用關係，因而對嵌套造成的後果，也很少考慮。種種原因，提醒我們值得去留意觸發器對SQLServer的影響。使用SQLServerProfiler是可以跟蹤到觸發器的執行情況的，選擇事件中的存儲過程SP：StmtCompleted事件即可以跟蹤觸發器的運行情況；選中NestLevel資料列則可以很好的瞭解到觸發器嵌套運行情況。附件中是一個跟蹤觸發器的模版。三.主要跟蹤資料的解釋我們主要通過跟蹤資料中Duration(執行週期)列的資料來發現那些耗用資料庫伺服器CPU特別嚴重的SQL,然後去優化他們的實現。如果你比較瞭解SQL,可以試著把SQL拷貝到查詢分析器，通過分析查詢計畫，建立合適的索引來優化性能。或者可以把Duration較長的SQL回饋到研發來分析。我們還需要關注Reads資料列，它代表磁片的邏輯讀次數，如果很多SQL語句的Reads次數都很高（達到幾十萬幾百萬甚至幾千萬次），這有可能是兩方面的原因。一方面有可能是記憶體不足，SQLServer頻繁切換記憶體資料。另一個可能的原因就是表和索引的存儲碎片太多，這可以通過在賬套管理中賬套優化操作來解決，這個功能可以理解為磁片整理。關注CPU和Duration兩列的資料對比情況，可以判斷CPU資源是否足夠，如果大多數SQL語句的CPU列資料明顯低於Duration，如果CPU曲線又很高，沒有發生嚴重的阻塞，我們可以認為CPU的處理佇列太長，需要增加CPU資源。1.3資料庫阻塞監測工具有時候資料庫伺服器的CPU耗用很低，但是系統的整體性能很差，有可能是資料庫發生阻塞，在這兒有一個監測工具可以得到阻塞情況。在查詢分析器上打開工具->選項，修改結果的設置選項把每列最多字元數修改為8000。-11-金蝶K/3產品性能穩定性優化指導手冊（輔助工具）把查詢結果改為文本顯示。在發生性能問題時在查詢分析中有問題的賬套上執行如下SQL。把執行結果保存為檔回饋到研發，研發人員會根據此結果得出一定的結論。-12-金蝶K/3產品性能穩定性優化指導手冊（輔助工具）1.4K/3性能監控工具工具路徑：\ProgramFiles\Kingdee\K/3ERP\KDMainDbg.exe(或KDLogMonitor.exe)K/3性能檢測工具包括三個部分：1、用戶端診斷工具2、用戶端代碼及跟蹤3、COM+跟蹤工具.已在K/3V10.2中廣泛應用並與K/3集成，幫助分析解決了一些性能問題，大大提高了開發效率。目前元件級跟蹤和COM+跟蹤，適用於K/3所有版本，甚至包括其他任何使用VB開發程式的產品，包括U8。1、用戶端診斷工具用於跟蹤後期綁定元件的介面物件創建、方法調用、運行時間、執行結果資訊等情況。以下是明細功能介紹:可以跟蹤物件創建的時間。VB本身對於物件創建出錯，一般用物件創建失敗或者Automation錯誤提示。無法確定知道具體哪個元件出現問題，該工具可以明確標識出創建失敗的組建名稱。K/3V10.2安裝包調整過程中，遇到大量元件創建失敗情況，通過該工具迅速定位到創建失敗的元件，極大提高了解決安裝包問題的速度。提供了查找功能。方便了開發人員對於自己關心元件的查找，定位。增強了過濾功能，能將調用時間比較長的事件用藍色字體突出顯示，同時過濾掉調用時間很小的事件。將物件創建事件和方法調用事件分別用不同顏色顯示，便於識別；同時將沒有嵌套的方法調用使用一行來顯示-13-金蝶K/3產品性能穩定性優化指導手冊（輔助工具）2、用戶端代碼級監測工具用於關鍵函數的運行資訊的輸出，方便在客戶環境下定位程式問題、並提供性能資料收集。3、COM+跟蹤工具利用COM+本身的事件發佈模型，監控COM+元件的方法調用，運行結果資訊。主要用於COM+伺服器端的資訊跟蹤，查看哪個中間層元件調用時間長或記憶體消耗打，以確定性能問題或其他問題所在。（1）選擇要跟蹤的COM+應用套裝程式-14-金蝶K/3產品性能穩定性優化指導手冊（輔助工具）（2）確定進行跟蹤1.5元件服務主要用來分析中間層的性能表現一)使用方法使用元件服務管理工具可以配置和管理COM元件及COM+應用程式，在K/3中間層伺服器監視元件的使用情況。1）啟動元件服務管理工具在“開始”功能表，依次指向“程式”、“管理工具”，然後單擊“元件服務”。2）檢查K/3中間層元件是否在運行如下圖，選擇“Com+應用程式”可以發現哪些元件正在運行；選擇工具條上的“狀態查詢”能夠更加直觀的查找哪些元件在運行中。-15-金蝶K/3產品性能穩定性優化指導手冊（輔助工具）如果用戶端用戶比較多或者網路速度比較慢的情況下，中間層伺服器有可能出現服務，從而引起性能問題。可以通過元件服務的事件列表檢查是否有比較多的事件在排隊等待。介面如下圖：二)如何找到正在執行的資源耗用多的組件有時候如果中間層的CPU或記憶體耗用很嚴重，由於在多個客戶的併發下有時候客戶很難發現是那一項操作引發了問題，這時候可以找一下那一個元件包中的哪一個元件耗用-16-金蝶K/3產品性能穩定性優化指導手冊（輔助工具）資源比較嚴重，配合其他的觀察：如在此階段用戶都在做那些操作，有助於發現引發問題的功能。首先在任務管理器的進程選頁簽上尋找耗用資源較多的DLLHOST進程，在這兒說明一下，每一個中間層元件包在運行時有一個DLLHOST進程，每一個包包含很多元件。找到耗用資源較多的DLLHOST，找對應的PID(進程標示號)，根據PID在元件管理中可以找到對應的元件包，然後在對元件包下面尋找調用時間長的元件，把此元件的資訊和其他用戶操作資訊回饋到研發，可以定位到具體的功能。三)如何判斷中間層的阻塞對於中間層伺服器，有可能發生阻塞，這時候主要看上面所描述的元件伺服器中事務列表中的元件排隊情況，如果有較長的排隊情況，就代表出現阻塞，可以考慮把組塞較多的元件分離出來重新放到一個新建的包中，因為每一個COM+元件包有一個進程。四)關於STA模式COM+元件線程數限制問題對於VB編寫的COM+元件，由於不能編譯為MTA線程模型，每個元件包進程的線程數默認為10個，也就是說同一個元件包中所有元件功能只能最多有十個同時運行。對此問題，微軟提供了一個修改線程數量限制的方法，那就是修改註冊表選項，可以讓線程數達到100。此項改進在V10.0已經在安裝包做了修改，如果是以前版本的客戶可以直接修改中間層伺服器註冊表選項。可以直接把以下註冊表檔導入。修改默認設置後，會提高中間層的併發性能。1.6SQLDiag.exeSQLDiag.exe工具程式默認的檔路徑位於<系統磁碟機>:\ProgramFiles\MicrosoftSQLServer\MSSQL\Binn目錄之下，產生出來的日誌檔默認放在<系統磁碟機>:\ProgramFiles\MicrosoftSQLServer\MSSQL\LOG目錄之下，檔案名為SQLDiag.txt。它可以在同一時間、一次幫你收集相當多的資訊。在相同的時間區段內，收集各種方面的資訊非常重要。例如你觀察到SQLServer對某個查詢的回應遲緩，可能需要同時觀察系統硬體各項資源的使用，SQLServer當時的鎖狀況，是否有錯誤發生等等，必須要互相參照，才容易找出禍首。SQLDiag.exe就可以在同一時間搜集到相當多的資訊，它必須在SQLServer伺服器本身執行，而不能在用戶端工作站執行。輸出的相關資料列述如下： 獲取記錄檔，若是SQLServer2000的版本，這些記錄檔默認是位於“<系統磁碟機>\ProgramFiles\MicrosoftSQLServer\MSSQL\LOG”目錄下，名稱為ERRORLOG及副檔名是數字的先前版本，如Errorlog.1、Errorlog.2一直到Errorlog.6等等，若版本是SQLServer7.0，則這些記錄檔路徑默認是<系統磁碟機>\MSSQL7\log\。這些日誌檔是文本類型，雖然名稱是ErrorLog，但放的不儘然是錯誤，SQLServer會將一些資訊，如啟動時所完成的動作，放在這個檔中。當然，若有錯誤，也會存放在這個檔中，SQLDiag默認會將這些ErrorLog檔一併放到輸出結果的檔內。 獲取相關的註冊(registry)資訊。 獲取相關程式庫(dlllibrary)的版本資訊。 通過sp_configure系統存儲過程獲取SQLServer執行實例的各項配置。 通過sp_who系統存儲過程獲取當前登錄SQLServer執行實例的用戶各項細節。 通過sp_lock系統存儲過程獲取鎖的相關資訊。 通過sp_helpdb系統存儲過程獲取SQLServer執行實例內各資料庫的相關資訊。-17-金蝶K/3產品性能穩定性優化指導手冊（輔助工具） 通過xp_msver擴展存儲過程獲取軟硬體平臺的簡要資訊。 通過sp_helpextendedproc系統存儲過程獲取擴展存儲過程(extendedstoredprocedures)的相關資訊。由於擴展存儲過程是以DLL的形式與SQLServer的核心執行在同一個程式中，若有任何閃失，輕則造成記憶體洩露，重則導致服務程式當掉。通過這個系統存儲過程會表列出所有的擴展存儲過程，你可以將它的輸出與一般安裝的SQLServer做個比較，看看是否有用戶自行安裝的擴展存儲過程，造成系統的不穩定。 從master.dbo.Sysprocesses系統資料表獲取程式(process)的相關資訊。當系統忙碌時，你可以通過它觀察到底有哪些程式在伺服器內執行，各用了多少資源等等。搭配其他的系統存儲過程，如sp_who、sp_who2、sp_lock等等，可以獲得整體的狀況。例如通過waittime欄位知道有哪些程式已經等待很久，從cpu、physical_io以及memusage欄位可以看出哪些程式在耗CPU、磁片輸出入或記憶體資源。以及打開了事務，但執行狀況卻是sleeping的不當事務管理。 通過DBCCINPUTBUFFER(spid)獲取各進程正在執行的命令。 獲取鎖鏈接的起始者(headblocker)。 通過MSInfo32.exe獲取系統的細節資料，這需要耗掉一些時間。 最後100個查詢和異常狀況(Exception)。SQLDiag.exe獲取系統資訊是靠MSInfo32.exe工具程式取得系統的相關資訊，你可以直接執行該工具程式以查看更豐富的資訊，如下圖：點擊MSInfo32.exe主功能表的[檔]-[導出]選項，可以將系統當前的各項資訊導出成文字檔案，供你日後參考。由於導出屬性包含軟硬體的各項細節資訊，所以按下[導出]後可能要稍等一下。SQLDiag.exe是一個相當容易執行的工具程式，若要參照它的使用方式，可以進入“命-18-金蝶K/3產品性能穩定性優化指導手冊（輔助工具）令提示符”程式，轉到SQLDiag.exe所在的目錄下執行SQLDiag/?(SQLDiag.exe默認目錄是<系統磁碟機>:\ProgramFiles\MicrosoftSQLServer\MSSQL\Binn)，以顯示各項參數，或是在SQLServer所附的“聯機文檔”利用SQLDiag關鍵字找尋使用的細節，URL是：mk:@MSITStore:C:\Program%20Files\Microsoft%20SQL%20Server\80\Tools\Books\coprompt.chm::/cp_sqldiag_96k9.htm以下簡述它各項參數的使用方式：-?：顯示使用說明。-I<SQLServer執行實例名稱>：指定要連接的本機SQLServer執行實例(Instance)。若不指定–I選項，則連接至本機默認的執行實例。-U<帳號>：指定登錄SQLServer的帳號。-P<密碼>：上述帳號對應的密碼。若指定-P選項但不賦予值，則SQLDiag認定密碼為空。密碼有區分大小寫。-E：使用信任連接，也就是以當前登錄作業系統的帳號來連接SQLServer。-O<導出檔案名稱>：將SQLDiag的導出重新導向到指定的檔。若未指定-O選項，則默認輸出檔名稱為SQLDiag.txt。此時，跟蹤檔案名稱仍維持原先的blackbox.trc和blackbox_01.trc。若指定-O選項，則SQLDiag根據你配置的名稱，重新命名跟蹤文件blackbox.trc和blackbox_01.trc(例如，若output_file指定為MyDiagnostics.txt，跟蹤檔將分別重新命名為MyDiagnostics.trc和MyDiagnostics_01.trc)。-X：排除錯誤日誌檔。-M：執行DBCC堆疊列印(stackdump)。-C：抽取聚集信息。執行範例如下：SQLDiag-E-Odiag.log通過–E參數，會以登錄作業系統的帳號登錄SQLServer，而–Odiag.log參數則會產生名稱為diag.log的輸出。1.7性能監視器(PerformanceMonitor)WindowsNT之後所附的性能監視器是顯示各種性能資料非常詳盡的工具。你可以用它來觀測伺服器當前的運行，記錄整個系統多台機器上的各種性能計數器，以找出整個系統的瓶頸。我們在性能調校的過程中會一再地用它。WindowsNT之後，就直接提供性能監視器(PerformanceMonitor)，一般是用來查看、跟蹤在整個系統中，是否有哪個部分顯示資源不足的狀態，或是系統的使用狀況、演變的趨勢等等。而性能計數器代表的是一種指標，它本身不是問題，某些背後隱含的問題導致該指標的變化。因此不要看到單一性能計數器的值就下定論，一定要建立推論：是什麼原因導致該性能計數器有當前的值，若該原因是真的，那同時哪些性能計數器應該顯示什麼現象？而你當然應該再進一步分析與推論相關的計數器。性能監視器讓你獲得證據以完成： 支持自己的假設，或是推翻結論另尋原因。 獲取電腦全盤的狀態，讓你可以發現電腦發生了什麼狀況(WHAT)，而不是為何(WHY)或如何(HOW)發生這種狀況。 抽取電腦變化的狀態，有基線以供比較是非常重要的，它讓你可以知道什麼是正常，而什麼不是。如果無法獲取基線，則尋找記錄中的變化，查看計數器相對的-19-金蝶K/3產品性能穩定性優化指導手冊（輔助工具）值而非絕對的值，並與先前的使用經驗做一個比較。除了一般的硬體，如記憶體、硬碟、中央處理器乃至於網路等系統提供的性能計數器外，大部分微軟提供的伺服器軟體在安裝完畢後，也會註冊它自身的性能計數器，而SQLServer會增加相當多類的性能計數器供你查核使用狀況，而這些性能物件皆以“SQLServer:”開頭。在要抽取性能的記錄之前，儘量將不相關的、當前不需要的服務先停掉，如IIS，系統掃毒等等。如果需要調校的電腦可能會當機，則要採用遠端記錄，避免資料未記錄到就掛了。相反地，若網路有問題，當然需要在本機完成記錄。而一旦採用遠端監控，要先同步兩台機器的時間才好比對結果。你可以在命令提示視窗中，通過以下的命令同步系統之間的時間：NETTIME\\RemoteMachine/SET就SQLServer的使用特性來說，依其重要程度，觀察硬體資源不足的順序依序是：記憶體、硬碟、中央處理器乃至於網路。SQLServer是非常耗用記憶體的軟體，因為它凡用過的資料必先留在記憶體中，除非資源不足，否則不輕易從緩衝區清掉，讓資料庫的運行儘量少使用硬碟。當記憶體不足時，會連帶地影響硬碟和中央處理器。例如有新的資料要放到屬性已滿的緩衝區，則SQLServer內部負責將緩衝區屬性更新到硬碟的LazyWriter程式就需要持續地執行，好更新緩衝區的資料，並釋放較沒有使用到的記憶體區塊，這會同時讓CPU與硬碟忙碌起來。也就是說，當CPU和硬碟性能不足時，有可能源頭是記憶體不足造成的。磁片子系統的性能不佳，也一定會讓SQLServer性能好不起來，畢竟它需要大量讀寫存在硬碟上資料庫內的資料。若你沒錢購置RAID，最好也多買幾顆硬碟，讓Log檔、資料庫檔以及Windows作業系統用做虛擬記憶體的交換檔分在不同的硬碟上，因為這三種檔的設計目的不同，存取的習性與頻率也不同，當三者在同一顆硬碟上時，有可能因為多個人存取資料庫，有的做更新，有的查詢，這些運行讓作業系統要配置虛擬記憶體，因此硬碟要同時存取三種檔，這會導致磁頭忙碌地移動，讓硬碟的存取大多是隨機讀取，無法做循序讀取，導致硬碟性能降低。因此建議將三種檔分別放在不同的硬碟上。硬碟的性能遲緩，必定導致資料庫的查詢與資料異動.
