金蝶K3产品性能稳定性优化指导手册

1、 金蝶K/3產品性能穩定性優化指導手冊(輔助工具)（V3.0）ã金蝶軟體(中國)有限公司研發中心K/3產品事業部.設計部解釋目的本手冊在於指導技術支援人員、分支機搆實施服務人員和客戶處理K/3系統應用過程中產生的性能問題、中間層伺服器問題等；同時也指導我們的實施服務人員和客戶在實施中如何避免將來可能發生的性能問題和中間層問題。讓研發人員、技術支援人員和分支機搆實施人員一起共同提高工作能力，快速反應快速解決客戶的問題。適合對象本手冊的主要閱讀物件是K/3系統研發人員、技術支援人員、實施人員、客戶服務人員和公司授權的有一定技術能力的客戶系統管理員。回饋本手冊是對研發在處理客戶性能和穩定性

2、問題的收集和總結，所以涉及到的面有可能還不夠。完善本手冊，提供一個更加完整的客戶問題解決指導方案，離不開大家的支持，所以大家在碰到相關的問題時，請回饋K/3設計部，我們將及時對手冊更新。導讀本手冊包括資料庫、中間層、用戶端和輔助分析工具介紹四大篇，分別介紹K/3客戶性能和穩定性問題的處理方法、案例以及輔助工具，請您根據您的需要選擇相應的章節閱讀。 注意由於此手冊可能牽涉一些K/3在技術方面的細節，為了防止有些人用意不良，斷章取義來攻擊K/3和公司，請注意保密。目錄目錄2輔助分析工具介紹31.1 WINDOWS任務管理器31.2 SQL Server的事件探查器（SQL-PROFILE）41.3

3、 資料庫阻塞監測工具111.4 K/3性能監控工具131.5 元件服務151.6 SQLDiag.exe171.7 性能監視器(Performance Monitor)191.8 VBCheckW2k231.9 ADPlus231.10 COM+ SPY261.11 Process Explorer271.12 DebugDiag291.13 WinDBG321.14收集電腦資訊工具321.15檢查網路工具321.15.1 Ping321.15.2 Netstat341.15.3 ARP（位址轉換協定）341.15.4 Tracert351.15.5 IPConfig361.15.6 Rout

4、e361.15.7 nbtstat371.15.8 使用 pathping 測試路由器371.15.9 網路診斷實例：39附錄1：應用/測試環境41附錄2：DTC一些資料41附錄3 中間層COM+問題分類和處理421問題分類421.1 COM+的掛起421.2 COM+ 出現 100% CPU431.3 COM+ 性能問題441.4 COM+ 異常441.5 COM+ 應用記憶體洩漏442. COM+問題分類分析和處理方法462.1 COM+掛起462.2 CPU100%492.3性能問題492.4 COM+ 異常512.5記憶體洩露51輔助分析工具介紹如果系統出現問題，由於產生問題的原因很多

5、，可能是COM+元件出現了問題，或者是SQL Server資料庫的出現了問題，或者作業系統本身就存在問題，或者是網路存在問題。所以我們需要綜合多個可能的因素，使用一些輔助工具對系統進行跟蹤檢測，然後分析跟蹤的結果，最終找到問題所在。下面就常見的一些輔助工具作一個簡單的介紹：1.1 WINDOWS任務管理器如果K/3系統很慢，是不是系統沒有可用的CPU和記憶體等資源了？Windows任務管理器可以幫助我們發現系統資源的使用情況。一)使用方法要打開“任務管理器”，請用右鍵單擊任務欄上的空白處，然後單擊“任務管理器”，或者把 “Ctrl+Alt+Delete”三個鍵同時按下，選擇“任務管理器”。 *

6、 選擇“性能”選項卡，如下圖：可以發現系統CPU和記憶體的使用情況。在系統出現性能問題時，監測一段時間系統資源的使用情況。* 選擇“進程”選項卡，如下圖：如果在上圖中發現CPU或者記憶體的使用率比較高，通過該圖，可以發現資源究竟被哪些進程所消耗。是否還有別的系統（除K/3）消耗了寶貴的CPU和記憶體資源。下圖中可以看出SQL Server消耗了系統91的CPU，K/3消耗了8%的CPU。二)資料庫伺服器CPU曲線的一些典型結論由於資料庫是K/3系統的瓶頸，我們主要觀察資料庫伺服器的性能，通過觀察資料庫伺服器CPU的運行曲線，可以得出一些典型結論。特別說明要觀察一段時間的CPU運行狀態，而不是看

7、一瞬間的狀態。1）CPU持續100%一段時間如果發現資料庫CPU在某一段時間持續達到100%,成一條直線狀，這可以判斷是某項功能耗用了全部的CPU資源，這項功能如果是很少使用的計算功能或者是大資料量查詢，建議適當安排,不要在業務高峰期運行，如果是日常功能絕對需要優化。如果能夠直接判斷是某項具體的功能最好，如果在併發下無法判斷到底是何功能。可以通過SQL-PROFILE跟蹤執行時間較長的SQL。2）CPU大多數時間保持在40%以上如果資料庫伺服器CPU長期保持在40%以上，系統的運行速度時快時慢，這表示CPU的負荷已經很重。如果不能優化軟體本身，升級硬體，增加CPU的個數可能是需要的。在這兒要說

8、明一點，不能認為CPU達到100%才是CPU資源不足。3）良好的CPU狀態良好的CPU狀態是CPU能夠經常跌落到40%以下，並且可以跌落到0。三)判斷資料庫記憶體是否夠用的一種簡單方法在任務管理器中選擇查看-顯示內核時間，會顯示一條紅線，可以理解為磁片讀寫的時間，如果紅線很高證明大量的磁片讀寫操作，說明記憶體可能不夠，需要大量的記憶體切換。1.2 SQL Server的事件探查器（SQL-PROFILE）主要用來跟蹤資料庫的SQL執行情況，發現耗時較長的SQL,從而發現影響性能的原因,分支機搆可以使用此工具得到跟蹤檔，把跟蹤檔返回到研發，用來分析和定位問題。這是最有效的定位分析問題的手段。一.

9、使用方法K/3出現性能問題，很多都是與SQL Sever資料相關。是否是一次查詢了太多的資料造成資料庫負載過大，出現性能問題？使用該工具可以使我們發現是哪些SQL 語句消耗了SQL Server資料庫的資源，對於發現性能問題會很有幫助，特別是給研發的軟體工程師們。SQL 事件探查器用於以下活動： 逐步分析有問題的查詢以找到問題的原因。查找並診斷運行慢的查詢。捕獲導致某個問題的一系列 SQL 語句。然後用所保存的跟蹤在某台測試伺服器上複製此問題，接著在該測試伺服器上診斷問題。監視 SQL Server 的性能以精細地調整工作負荷。1）啟動事件探查器工具在“開始”功能表，依次指向“程式”、“Mic

10、rosoft SQL Server”，然後單擊“事件探查器”。 2）打開該程式後選擇“檔”功能表的“新建”的子功能表“跟蹤”，打開如下的介面：選擇SQL Server伺服器名稱（或者輸入IP位址，如果是本機器可以輸入“.”英文句號），然後輸入SQL Server的身份驗證登陸名和密碼，可以和資料庫管理員聯繫。3）選擇“事件”選項卡n 在該圖中設置需要跟蹤的SQL Server事件類。主要用來跟蹤SQL語句和存儲過程的事件，通常情況下只要設置TSQL事件類的SQL:BatchCompleted，SQL:StmtCompleted事件和存儲過程事件類RPC:Completed、SP:Complet

11、ed，SP:stmtCompleted事件即可。4）選擇“資料列”選項卡，如下圖：在該圖中選擇要捕獲的數據列。建議把左邊的資料列全部添加到選定的資料列表中，捕獲完整，充分的資訊。設置完上面的資訊後，點擊“運行”按鈕。對選定的資料庫伺服器進行一定事件的跟蹤，然後另存為跟蹤文件，如下圖：可以對資料列：CPU（事件所使用的CPU事件，毫秒為單位），Reads（伺服器代表事件執行的邏輯磁片讀取數），Writes（伺服器代表事件執行的物理磁片寫入數），Duration（事件所花費的事件總計，毫秒為單位）進行查看，查找讀取或寫入物理磁片次數多的操作，耗時比較多的操作。為查找性能問題提供有力的證據，對性能優

12、化也具有參考的價值。各個資料列的具體含義列舉如下表，以供參考查閱。數據列列號描述Application Name110創建與 SQL Server 實例的連接的用戶端應用程式名。 該列由應用程式傳遞的值填充，而不是由所顯示的程式名填充。 Binary Data2與在跟蹤中捕獲的事件類相關的二進位值。 ClientProcessID19由主機電腦分配給進程的 ID，在該進程中客戶應用程式正在運行。如果用戶端提供用戶端進程 ID，則填充此資料列。 Column Permissions44表明是否已設置了列許可權。分析語句文本，以確定將哪些許可權應用到了哪些列。 CPU 18事件所使用的 CPU 時

13、間總計（以毫秒為單位）。 Database ID13USE database 語句所指定的資料庫 ID，如果沒有對給定實例發出過 USE database 語句，則是默認資料庫。如果在跟蹤內捕獲 Server Name資料列且伺服器可用，則 SQL 事件探查器將顯示資料庫名。 通過使用 DB_ID 函數確定資料庫的值。 DatabaseName35正在運行用戶語句的資料庫的名稱。 DBUserName140用戶端的 SQL Server 用戶名。Duration 13事件所花費的時間總計（以毫秒為單位）。 End Time 15事件結束時的時間。啟動事件的事件類（如 SQL:BatchStar

14、ting 或 SP:Starting）的該列不填充。 Error31給定事件的錯誤號。通常是存儲在 sysmessages 中的錯誤號。EventClass127捕獲的事件類類型。 EventSubClass121事件子類的類型，提供有關每個事件類的進一步資訊。例如，Execution Warning 事件類的事件子類值代表執行警告的類型： 1 = 查詢等待。查詢必須等待資源（如記憶體）才能執行。2 = 查詢超時。查詢在等待執行所需的資源時超時。所有事件類的該資料列均不填充。FileName36所修改的檔的邏輯名稱。 Handle33ODBC、OLE DB 或 DB-Library 所用的整數

15、，用以協調伺服器的執行。 Host Name18正運行用戶端的電腦名。如果用戶端提供主機名，則填充此資料列。若要確定主機名，請使用 HOST_NAME 函數。Index ID24受事件影響的物件上的索引 ID。若要確定物件的索引 ID，請使用 sysindexes 系統表的 indid 列。 Integer Data25與在跟蹤中捕獲的事件類相關的整型值。 LoginName11用戶的登錄名（SQL Server 安全登錄或 Microsoft Windows® 登錄憑據，格式為 DOMAINUsername）。LoginSid141登錄用戶的安全標識號 (SID)。可以在 mast

16、er 資料庫的 sysxlogins 表中找到該資訊。對於伺服器中的每個登錄，SID 是唯一的。 Mode32不同事件所用的整數，用於描述事件已接收或要請求的狀態。 NestLevel29表示 NESTLEVEL 所返回的資料的整數。 NT Domain Name17用戶所屬的 Microsoft Windows NT® 4.0 或 Windows 2000 域。 NT User Name16Windows NT 4.0 或 Windows 2000 用戶名。Object ID22系統分配的物件 ID。ObjectName34引用的對象名。ObjectType28表示事件中涉及的物件

17、類型的值。該值對應於 sysobjects 中的 type 列。Owner Name37物件所有者的資料庫用戶名稱。Permissions19表示所檢查的許可權類型的整型值。取值為： 1 = SELECT ALL2 = UPDATE ALL4 = REFERENCES ALL8 = INSERT16 = DELETE32 = EXECUTE（僅限於過程）4096 = SELECT ANY （至少一列）8192 = UPDATE ANY16384 = REFERENCES ANYReads16伺服器代表事件執行的邏輯磁片讀取數。RoleName38要啟用的應用程式角色名。Server Name1

18、26跟蹤的 SQL Server 實例名。Severity20異常錯誤的嚴重級別。 SPID112SQL Server 指派的與客戶端相關的伺服器進程 ID。Start Time114啟動事件的時間（可用時）。State30等同於錯誤狀態代碼。Success23表示事件是否成功。取值包括： 1 = 成功。0 = 失敗例如，1 表示許可權檢查成功，0 表示該檢查失敗。TargetLoginName42對於以登錄為目標的操作（例如，添加新登錄），是目標登錄的名稱。TargetLoginSid43對於以目標為登錄的操作（例如，添加新登錄），是目標登錄的 SID。TargetUserName39對於以

19、資料庫用戶為目標的操作（例如授予用戶許可權），是該用戶的名稱。TextData1與跟蹤內捕獲的事件類相關的文本值。但是，如果正在跟蹤參數化查詢，則不以 TextData 列中的資料值顯示變數。Transaction ID4系統分配的事務 ID。Writes17伺服器代表事件執行的物理磁片寫入數。二.一些使用技巧n 在選擇要跟蹤的事件時不要使用默認設置，一定要按照上面使用方法中的描述選擇部分事件，否則會跟蹤到很多無用的連接或回話資訊。選擇SQL:BatchCompleted，SQL:StmtCompleted事件和存儲過程事件類RPC:Completed、SP:Completed，SP:stmt

20、Completed即可。如果發現某一段時間有規律的發生性能問題，需要事先跟蹤，跟蹤一段時間，而不是問題已經發生了再去跟蹤。跟蹤一段時間後，約1-2小時保存一次，否則跟蹤檔太大，耗用太多的記憶體會影響伺服器的記憶體。在保存時要選擇保存為跟蹤檔（默認是這樣），保存為其他格式會丟失分析性能的資料，以前有分支機搆的人員就是保存為SQL腳本發給研發，這對分析問題毫無價值。跟蹤檔可能會很大，但是壓縮比例很高，壓縮後作為K/3性能問題診斷模版的一部分回饋給研發。為了不使跟蹤檔過大，在篩選條件上選擇Duration>=200的事件，因為執行週期很短的SQL不是我們在性能分析中關注的重點物件，同時全部SQ

21、L都跟蹤會很多，設置如下。附件是一個跟蹤檔的模版，SQL Server 本身也帶有很多的模版，在SQL Server安裝目錄80ToolsTemplatesSQL Profiler路徑下，如果有興趣也可以學習使用。如何跟蹤觸發器在跟蹤SQL的時候，可能會發現即使單條的Insert、Deleted、Update語句都會很慢。這種情況下，有可能是請求的資源被鎖定或者CPU等硬體資源不足等。除此之外，還可以檢查是否是觸發器造成的。有些觸發器工作不良好：如使用游標來處理資料，或者由於觸發器的位置不對，使得本來可以批量處理的情況，只能單條處理。如：Master-Detail表資料結構中，Detail表中

22、的觸發器只能處理一條Detail中的資料。而一般情況下，可以成批次處理Detail中的資料。通常開發人員也很少留意觸發器嵌套調用關係，因而對嵌套造成的後果，也很少考慮。種種原因，提醒我們值得去留意觸發器對SQL Server的影響。使用SQL Server Profiler是可以跟蹤到觸發器的執行情況的，選擇事件中的存儲過程SP：StmtCompleted事件即可以跟蹤觸發器的運行情況；選中NestLevel資料列則可以很好的瞭解到觸發器嵌套運行情況。附件中是一個跟蹤觸發器的模版。三.主要跟蹤資料的解釋我們主要通過跟蹤資料中Duration(執行週期)列的資料來發現那些耗用資料庫伺服器CPU特

23、別嚴重的SQL,然後去優化他們的實現。如果你比較瞭解SQL,可以試著把SQL拷貝到查詢分析器，通過分析查詢計畫，建立合適的索引來優化性能。或者可以把Duration較長的SQL回饋到研發來分析。我們還需要關注Reads資料列，它代表磁片的邏輯讀次數，如果很多SQL語句的Reads次數都很高（達到幾十萬幾百萬甚至幾千萬次），這有可能是兩方面的原因。一方面有可能是記憶體不足，SQL Server頻繁切換記憶體資料。另一個可能的原因就是表和索引的存儲碎片太多，這可以通過在賬套管理中賬套優化操作來解決，這個功能可以理解為磁片整理。關注CPU和Duration兩列的資料對比情況，可以判斷CPU資源是否足

24、夠，如果大多數SQL語句的CPU列資料明顯低於Duration，如果CPU曲線又很高，沒有發生嚴重的阻塞，我們可以認為CPU的處理佇列太長，需要增加CPU資源。1.3 資料庫阻塞監測工具有時候資料庫伺服器的CPU耗用很低，但是系統的整體性能很差，有可能是資料庫發生阻塞，在這兒有一個監測工具可以得到阻塞情況。在查詢分析器上打開工具->選項，修改結果的設置選項把每列最多字元數修改為8000。把查詢結果改為文本顯示。在發生性能問題時在查詢分析中有問題的賬套上執行如下SQL。把執行結果保存為檔回饋到研發，研發人員會根據此結果得出一定的結論。1.4 K/3性能監控工具工具路徑：Program Fi

25、lesKingdeeK/3ERPKDMainDbg.exe(或KDLogMonitor.exe)K/3性能檢測工具包括三個部分：1、用戶端診斷工具 2、用戶端代碼及跟蹤 3、COM+跟蹤工具.已在K/3V10.2中廣泛應用並與K/3集成，幫助分析解決了一些性能問題，大大提高了開發效率。目前元件級跟蹤和COM+跟蹤，適用於K/3所有版本，甚至包括其他任何使用VB開發程式的產品，包括U8。1、用戶端診斷工具用於跟蹤後期綁定元件的介面物件創建、方法調用、運行時間、執行結果資訊等情況。以下是明細功能介紹:n 可以跟蹤物件創建的時間。VB本身對於物件創建出錯，一般用物件創建失敗或者Automation錯

26、誤提示。無法確定知道具體哪個元件出現問題，該工具可以明確標識出創建失敗的組建名稱。K/3 V10.2安裝包調整過程中，遇到大量元件創建失敗情況，通過該工具迅速定位到創建失敗的元件，極大提高了解決安裝包問題的速度。n 提供了查找功能。方便了開發人員對於自己關心元件的查找，定位。n 增強了過濾功能，能將調用時間比較長的事件用藍色字體突出顯示，同時過濾掉調用時間很小的事件。n 將物件創建事件和方法調用事件分別用不同顏色顯示，便於識別；同時將沒有嵌套的方法調用使用一行來顯示2、用戶端代碼級監測工具用於關鍵函數的運行資訊的輸出，方便在客戶環境下定位程式問題、並提供性能資料收集。3、COM+跟蹤工具利用C

27、OM+本身的事件發佈模型，監控COM+元件的方法調用，運行結果資訊。主要用於COM+伺服器端的資訊跟蹤，查看哪個中間層元件調用時間長或記憶體消耗打，以確定性能問題或其他問題所在。（1）選擇要跟蹤的COM+應用套裝程式（2）確定進行跟蹤1.5 元件服務主要用來分析中間層的性能表現一)使用方法使用元件服務管理工具可以配置和管理 COM 元件及 COM+ 應用程式，在K/3中間層伺服器監視元件的使用情況。1）啟動元件服務管理工具在“開始”功能表，依次指向“程式”、“管理工具”，然後單擊“元件服務”。 2）檢查K/3中間層元件是否在運行如下圖，選擇“Com+應用程式”可以發現哪些元件正在運行；選擇工具

28、條上的“狀態查詢”能夠更加直觀的查找哪些元件在運行中。如果用戶端用戶比較多或者網路速度比較慢的情況下，中間層伺服器有可能出現服務，從而引起性能問題。可以通過元件服務的事件列表檢查是否有比較多的事件在排隊等待。介面如下圖：二)如何找到正在執行的資源耗用多的組件有時候如果中間層的CPU或記憶體耗用很嚴重，由於在多個客戶的併發下有時候客戶很難發現是那一項操作引發了問題，這時候可以找一下那一個元件包中的哪一個元件耗用資源比較嚴重，配合其他的觀察：如在此階段用戶都在做那些操作，有助於發現引發問題的功能。首先在任務管理器的進程選頁簽上尋找耗用資源較多的DLLHOST進程，在這兒說明一下，每一個中間層元件包

29、在運行時有一個DLLHOST進程，每一個包包含很多元件。找到耗用資源較多的DLLHOST，找對應的PID(進程標示號)，根據PID在元件管理中可以找到對應的元件包，然後在對元件包下面尋找調用時間長的元件，把此元件的資訊和其他用戶操作資訊回饋到研發，可以定位到具體的功能。三)如何判斷中間層的阻塞對於中間層伺服器，有可能發生阻塞，這時候主要看上面所描述的元件伺服器中事務列表中的元件排隊情況，如果有較長的排隊情況，就代表出現阻塞，可以考慮把組塞較多的元件分離出來重新放到一個新建的包中，因為每一個COM+元件包有一個進程。四)關於STA模式COM+元件線程數限制問題對於VB編寫的COM+元件，由於不能

30、編譯為MTA線程模型，每個元件包進程的線程數默認為10個，也就是說同一個元件包中所有元件功能只能最多有十個同時運行。對此問題，微軟提供了一個修改線程數量限制的方法，那就是修改註冊表選項，可以讓線程數達到100。此項改進在V10.0已經在安裝包做了修改，如果是以前版本的客戶可以直接修改中間層伺服器註冊表選項。可以直接把以下註冊表檔導入。 修改默認設置後，會提高中間層的併發性能。1.6 SQLDiag.exeSQLDiag.exe 工具程式默認的檔路徑位於 <系統磁碟機>: Program FilesMicrosoft SQL ServerMSSQLBinn 目錄之下，產生出來的日誌檔

31、默認放在<系統磁碟機>:Program FilesMicrosoft SQL ServerMSSQLLOG 目錄之下，檔案名為 SQLDiag.txt。它可以在同一時間、一次幫你收集相當多的資訊。在相同的時間區段內，收集各種方面的資訊非常重要。例如你觀察到 SQL Server 對某個查詢的回應遲緩，可能需要同時觀察系統硬體各項資源的使用，SQL Server 當時的鎖狀況，是否有錯誤發生等等，必須要互相參照，才容易找出禍首。 SQLDiag.exe 就可以在同一時間搜集到相當多的資訊，它必須在 SQL Server 伺服器本身執行，而不能在用戶端工作站執行。輸出的相關資料列述如下

32、：l 獲取記錄檔，若是 SQL Server 2000 的版本，這些記錄檔默認是位於“<系統磁碟機>Program FilesMicrosoft SQL ServerMSSQLLOG”目錄下，名稱為 ERRORLOG 及副檔名是數字的先前版本，如 Errorlog.1、Errorlog.2 一直到 Errorlog.6 等等，若版本是 SQL Server 7.0，則這些記錄檔路徑默認是 <系統磁碟機> MSSQL7log。 這些日誌檔是文本類型，雖然名稱是 ErrorLog，但放的不儘然是錯誤，SQL Server 會將一些資訊，如啟動時所完成的動作，放在這個檔中。當

33、然，若有錯誤，也會存放在這個檔中，SQLDiag 默認會將這些 ErrorLog 檔一併放到輸出結果的檔內。 l 獲取相關的註冊(registry)資訊。 l 獲取相關程式庫(dll library)的版本資訊。 l 通過 sp_configure 系統存儲過程獲取 SQL Server 執行實例的各項配置。 l 通過 sp_who 系統存儲過程獲取當前登錄 SQL Server 執行實例的用戶各項細節。 l 通過 sp_lock 系統存儲過程獲取鎖的相關資訊。 l 通過 sp_helpdb 系統存儲過程獲取 SQL Server 執行實例內各資料庫的相關資訊。 l 通過 xp_msver 擴

34、展存儲過程獲取軟硬體平臺的簡要資訊。 l 通過 sp_helpextendedproc 系統存儲過程獲取擴展存儲過程(extended stored procedures)的相關資訊。由於擴展存儲過程是以 DLL 的形式與 SQL Server 的核心執行在同一個程式中，若有任何閃失，輕則造成記憶體洩露，重則導致服務程式當掉。通過這個系統存儲過程會表列出所有的擴展存儲過程，你可以將它的輸出與一般安裝的 SQL Server 做個比較，看看是否有用戶自行安裝的擴展存儲過程，造成系統的不穩定。 l 從 master.dbo.Sysprocesses 系統資料表獲取程式(process)的相關資訊。

35、當系統忙碌時，你可以通過它觀察到底有哪些程式在伺服器內執行，各用了多少資源等等。搭配其他的系統存儲過程，如 sp_who、sp_who2、sp_lock 等等，可以獲得整體的狀況。例如通過 waittime 欄位知道有哪些程式已經等待很久，從 cpu、physical_io 以及 memusage 欄位可以看出哪些程式在耗 CPU、磁片輸出入或記憶體資源。以及打開了事務，但執行狀況卻是 sleeping 的不當事務管理。 l 通過 DBCC INPUTBUFFER (spid) 獲取各進程正在執行的命令。 l 獲取鎖鏈接的起始者(head blocker)。 l 通過 MSInfo32.exe

36、 獲取系統的細節資料，這需要耗掉一些時間。 l 最後 100 個查詢和異常狀況 (Exception)。 SQLDiag.exe 獲取系統資訊是靠 MSInfo32.exe 工具程式取得系統的相關資訊，你可以直接執行該工具程式以查看更豐富的資訊，如下圖： 點擊 MSInfo32.exe 主功能表的檔 - 導出選項，可以將系統當前的各項資訊導出成文字檔案，供你日後參考。由於導出屬性包含軟硬體的各項細節資訊，所以按下導出後可能要稍等一下。SQLDiag.exe 是一個相當容易執行的工具程式，若要參照它的使用方式，可以進入“命令提示符”程式，轉到 SQLDiag.exe 所在的目錄下執行 SQLDi

37、ag /?(SQLDiag.exe 默認目錄是 <系統磁碟機>:Program FilesMicrosoft SQL ServerMSSQLBinn)，以顯示各項參數，或是在 SQL Server 所附的“聯機文檔”利用 SQLDiag 關鍵字找尋使用的細節，URL 是：mk:MSITStore:C:Program%20FilesMicrosoft%20SQL%20Server80ToolsBooks coprompt.chm:/cp_sqldiag_96k9.htm以下簡述它各項參數的使用方式： -?：顯示使用說明。 -I <SQL Server 執行實例名稱>：指定

38、要連接的本機 SQL Server 執行實例 (Instance)。若不指定 I 選項，則連接至本機默認的執行實例。 -U <帳號>：指定登錄 SQL Server 的帳號。 -P <密碼>：上述帳號對應的密碼。若指定 -P 選項但不賦予值，則 SQLDiag 認定密碼為空。密碼有區分大小寫。 -E：使用信任連接，也就是以當前登錄作業系統的帳號來連接 SQL Server。 -O <導出檔案名稱>：將 SQLDiag 的導出重新導向到指定的檔。若未指定 -O 選項，則默認輸出檔名稱為 SQLDiag.txt。此時，跟蹤檔案名稱仍維持原先的 blackbox.

39、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 -O diag.log 通過 E 參數，會以登錄作業系統的帳號登錄 SQL Server，

40、而 O diag.log 參數則會產生名稱為 diag.log 的輸出。1.7 性能監視器(Performance Monitor)Windows NT 之後所附的性能監視器是顯示各種性能資料非常詳盡的工具。你可以用它來觀測伺服器當前的運行，記錄整個系統多台機器上的各種性能計數器，以找出整個系統的瓶頸。我們在性能調校的過程中會一再地用它。Windows NT 之後，就直接提供性能監視器(Performance Monitor)，一般是用來查看、跟蹤在整個系統中，是否有哪個部分顯示資源不足的狀態，或是系統的使用狀況、演變的趨勢等等。而性能計數器代表的是一種指標，它本身不是問題，某些背後隱含的問題

41、導致該指標的變化。因此不要看到單一性能計數器的值就下定論，一定要建立推論：是什麼原因導致該性能計數器有當前的值，若該原因是真的，那同時哪些性能計數器應該顯示什麼現象？而你當然應該再進一步分析與推論相關的計數器。性能監視器讓你獲得證據以完成： l 支持自己的假設，或是推翻結論另尋原因。 l 獲取電腦全盤的狀態，讓你可以發現電腦發生了什麼狀況(WHAT) ，而不是為何(WHY)或如何(HOW)發生這種狀況。 l 抽取電腦變化的狀態，有基線以供比較是非常重要的，它讓你可以知道什麼是正常，而什麼不是。如果無法獲取基線，則尋找記錄中的變化，查看計數器相對的值而非絕對的值，並與先前的使用經驗做一個比較。除

42、了一般的硬體，如記憶體、硬碟、中央處理器乃至於網路等系統提供的性能計數器外，大部分微軟提供的伺服器軟體在安裝完畢後，也會註冊它自身的性能計數器，而 SQL Server 會增加相當多類的性能計數器供你查核使用狀況，而這些性能物件皆以“SQLServer:”開頭。在要抽取性能的記錄之前，儘量將不相關的、當前不需要的服務先停掉，如 IIS，系統掃毒等等。如果需要調校的電腦可能會當機，則要採用遠端記錄，避免資料未記錄到就掛了。相反地，若網路有問題，當然需要在本機完成記錄。而一旦採用遠端監控，要先同步兩台機器的時間才好比對結果。你可以在命令提示視窗中，通過以下的命令同步系統之間的時間：NET TIME

43、 RemoteMachine /SET就 SQL Server 的使用特性來說，依其重要程度，觀察硬體資源不足的順序依序是：記憶體、硬碟、中央處理器乃至於網路。SQL Server 是非常耗用記憶體的軟體，因為它凡用過的資料必先留在記憶體中，除非資源不足，否則不輕易從緩衝區清掉，讓資料庫的運行儘量少使用硬碟。當記憶體不足時，會連帶地影響硬碟和中央處理器。例如有新的資料要放到屬性已滿的緩衝區，則 SQL Server 內部負責將緩衝區屬性更新到硬碟的 LazyWriter 程式就需要持續地執行，好更新緩衝區的資料，並釋放較沒有使用到的記憶體區塊，這會同時讓 CPU 與硬碟忙碌起來。也就是說，當

44、CPU 和硬碟性能不足時，有可能源頭是記憶體不足造成的。 磁片子系統的性能不佳，也一定會讓 SQL Server 性能好不起來，畢竟它需要大量讀寫存在硬碟上資料庫內的資料。若你沒錢購置 RAID，最好也多買幾顆硬碟，讓 Log 檔、資料庫檔以及 Windows 作業系統用做虛擬記憶體的交換檔分在不同的硬碟上，因為這三種檔的設計目的不同，存取的習性與頻率也不同，當三者在同一顆硬碟上時，有可能因為多個人存取資料庫，有的做更新，有的查詢，這些運行讓作業系統要配置虛擬記憶體，因此硬碟要同時存取三種檔，這會導致磁頭忙碌地移動，讓硬碟的存取大多是隨機讀取，無法做循序讀取，導致硬碟性能降低。因此建議將三種檔

45、分別放在不同的硬碟上。 硬碟的性能遲緩，必定導致資料庫的查詢與資料異動延遲(這兩種動作分別是存取資料庫檔與 Log 檔)，這又造成事務要花較長的時間才能結束，進而讓鎖的資源無法釋放，多人存取的系統彼此等待資源，進入大家都被延遲的慘況。CPU性能的重要性不用強調了吧，它慢，週邊設備再快都沒有用。但要注意的是，我們當前電腦的設計往往是中央處理器極快，但週邊運行緩慢，導致CPU無法有效發揮它的能力。因此當考慮加強中央處理器時，要看看是否是周邊設備的不足，導致CPU忙碌。一般來說，啟動性能監視器後，只要記錄資訊而不需要做圖。以較穩定的方式抽取電腦完整的狀態，由於在事前你很難預料判斷瓶頸時，會需要哪些資

46、料，所以儘量記錄所有的計數器5。如圖3.5 所示，除了通過默認的視窗觀察系統當前的情況外，最好還要通過添加記錄的方式，對系統作較長時間的監控。執行性能監視器時間要長到足以抓取到問題，一般粗略的配置綱要如下：l 記錄2小時 每 4 秒記錄一次。 l 記錄1天 每 30 秒記錄一次。 l 記錄1天 每 180 秒記錄一次。活動中的圖形只能顯示瞬間的系統狀況，長時間記錄的資料才能看出趨勢 時間間隔不要小於 4 秒，以免記錄這個動作本身就傷害電腦的性能，除非是要抽取磁片 I/O 的性能，最高頻率也勿超過每 2 秒記錄一次。另外，為減輕對電腦長期的影響，若沒有特殊需求，只要記錄 2 小時就好。如果需要的

47、話，執行'diskperf y ' 以抽取磁片的性能資訊。初次記錄時，在不傷及性能的前提下，僅可能地抽取所有的物件，供你對整個系統有一個全面性的概觀。縮略表列一般要記錄的物件如下(如果不可能取得全部物件)： l Cache, memory, objects, paging file, physical disk, logical disk, process, thread, processor, server, system。 l 所有的 SQL Server 物件。 l 如果有網路相關的問題，所有與網路相關的物件 (Protocol Stack Objects)。 一次記錄通

48、常無法包含所有需要的資訊，可能要多次後續不同的記錄資料。另外，在記錄上尚有其他的考量，如每個記錄存成一個檔，在記錄停止後，下次打開一個新的檔。檢查記錄檔所花的硬碟空間。若某個日誌檔屬性太大，而你只需要其中重要的部分，重新建立記錄(Re-logging)可能會很有用。日誌檔最大極限 1 gigabyte (GB)，而單一日誌檔太大也很難處理，可行的日誌檔大小應該在 100 megabytes (MB) 左右，建議取 50 MB。若你需要長時間記錄，而系統是在 Windows NT 上，考慮以 script 自動停掉並重起記錄，以減低記錄檔大小。若在 Windows 2000 則可以利用 Sysm

49、on 的計畫任務，定時停掉並重起記錄，以分成多個日誌檔。 使用Windows XP 或 Windows 2003，可以通過 Relog.exe 工具程式對事件重新建立記錄，它可以將日誌檔轉換成不同的格式，並在新建立的日誌檔中包含較少的計數器數目。使用 relog.exe 的步驟如下： 1. 查看日誌檔資料：打開先前抽取的 .blg 文件。 2. 選擇你要繪圖的計數器。 3. 圖表上以滑鼠右鍵選擇“另存新檔”，格式為 HTML。 4. 將新建的 html 檔以附屬應用程式的“記事本”打開。 5. 保留你有興趣的計數器，將其餘的計數器刪掉，同時把所有的格式通通刪掉，只保留如下的格式屬性： Comp

50、uterObjectParent/Instance#IndexCounter 若需要多個計數器，則每個名稱間以換行符號分開，範例如下： BYRON2003NBMemoryPages/sec BYRON2003NBPhysicalDisk(_Total)Avg. Disk Queue Length BYRON2003NBProcessor(_Total)% Processor Time 其中 Computer 名稱可以省略。 6. 以一般文字檔案格式 ANSI 編碼存檔，或許換個檔案名比較合適，例如以 .txt 為副檔名。要小心的是默認“Windows System Monitor”將 HTML

51、 格式的配置檔是以 Unicode 存檔，“記事本”會依照原編碼格式也就是 Unicode 存檔，而 Relog.exe 看不懂這種檔格式。 命令執行範例如下： relog SQLPerformance.blg -cf General.txt -f CSV -o General.csv 在範例中，原始日誌性能的檔案名稱是 SQLPerformance.blg，而該檔以二進位格式存放性能日誌資料，而我們只取部分的計數器，定義在 General.txt 文件中。過濾的結果將以逗號分隔的一般文字存檔，也就是默認給 Excel 看的 .csv 檔，所以結果輸出到 General.csv 檔中，你可以直

52、接通過 Excel 打開查看分析。 上述步驟的相關細節可以參閱微軟支援網站，查詢檔“Q195654 Methods for Condensing a Performance Monitor Log File”，或是執行範例光碟第3章“重新過濾 Log”目錄下的myRelog.cmd 批次檔案來測試錄製完一段時間的系統執行狀況後，接著要做的是顯示以及替日誌檔繪圖，Windows NT 所附的 Perfmon 受限在只能畫到 100%，而 Windows 2000 之後的 Sysmon 則可以超過這個範圍。若系統間有不同時區的差異，Sysmon 會做調整，Perfmon 則不會。若要與其他的資料做

53、比較而時區不同，如 SQL Profiler 的跟蹤檔，可能會造成混淆。在查看資料時，應先繪製全部記錄的圖表，以瞭解整體的趨勢。對於同一個日誌檔可以繪製多個圖表，以避免單一圖表顯示過多的資訊。為不同的記錄 instance 配置不同的值域範圍(range)，若要突顯圖表中某個 instance 的線條，可以在下方區塊選到該線條後按快捷鍵 Ctrl+H。查看圖形時，利用時間範圍 slider 來取得特定趨勢時段的細節，並利用鍵盤上的左右箭頭一次移動一個點，若偶有一兩個點遠高出邊界，可能是除零運算的結果，可以忽略不計。最後要注意的是不要利用 Windows NT 的 Perfmon 讀取 Wind

54、ows 2000 Sysmon 產生的日誌檔當要分析記錄所得的資料時，尋找某些模式，以及不正常之高或低的計數值，這有助於瞭解什麼是“正常”值，對建立基線是有幫助的，如果一個計數器顯示某個問題，可尋找其他的證據以支持你的理論，例如：l % Process Time 的值持續很高，瓶頸不一定是在 CPU 。也可能因實體記憶體不足，為了處理 page faults 造成很高的 %Privilege Time。 l SQL Server Total Server Memory 持續飆高不一定是 memory leak。Buffer Pool 會在 SQL Server 尚未用到記憶體限制或極限時，持續

55、增加。不要忘了查看 SQL Profiler 跟蹤檔、errorlog，或其他相關資訊，有助於解釋你在性能記錄所看到的現象。當特定的計數值走高時：l SQL Profiler 是否同時抽取到值得注意的現象？是否有大量的 recompile 和 compile 事件？ l 是否有特別的查詢或批次處理工作在執行？ l 是否在 errorlog 中看到任何錯誤或資訊？性能監視器就介紹到此，我們接著要討論的是針對個別問題需要進一步研究時，可以採用的工具程式。1.8 VBCheckW2k用於檢查使用VB編寫的DLL編譯是否正確，可以檢查整個系統中的COM+元件物件、IIS Web 應用程式以及單個的DL

56、L檔l 使用方法：vbchkw2k /sc or dllname 參數說明：1：/sc 掃描IIS（進程中），OOP Pooled、以及安裝在COM+元件和COM+目錄下的獨立的應用程式；（由於K/3系統相應的DLL比較多，可以把內容輸出成一個日誌檔，然後在進行分析，方式在後面加上” >log.txt “）2：dllname 掃描指定的DLL3：無 掃描IIS（進程中），OOP Pooled、以及安裝在COM+元件下的獨立的應用程式；l 示例命令：vbchkw2k /sc >log.txt結果：Scanning dllhost.exe (PID:828) kdsvrmgrC:WINNTsystem32KDCOMKdsv