金蝶产品性能稳定性优化指导手册模板.doc

金蝶K/3產品性能穩定性優化指導手冊(輔助工具)（V3.0）金蝶軟體(中國)研發中心K/3產品事業部.設計部解釋目标本手冊在於指導技術支援人員、分支機搆實施服務人員和客戶處理K/3系統應用過程中產生性能問題、中間層伺服器問題等；同時也指導我們實施服務人員和客戶在實施中怎样避免將來可能發生性能問題和中間層問題。讓研發人員、技術支援人員和分支機搆實施人員一起共同提升工作能力，快速反應快速解決客戶問題。適合對象本手冊关键閱讀物件是K/3系統研發人員、技術支援人員、實施人員、客戶服務人員和企业授權有一定技術能力客戶系統管理員。回饋本手冊是對研發在處理客戶性能和穩定性問題搜集和總結，所以包含到面有可能還不夠。完善本手冊，提供一個愈加完整客戶問題解決指導方案，離不開大家支持，所以大家在碰到相關問題時，請回饋K/3設計部，我們將及時對手冊更新。導讀本手冊包含資料庫、中間層、用戶端和輔助分析工具介紹四大篇，分別介紹K/3客戶性能和穩定性問題處理方法、案例和輔助工具，請您根據您需要選擇相應章節閱讀。 注意由於此手冊可能牽涉部分K/3在技術方面細節，為了预防有些人用意不良，斷章取義來攻擊K/3和企业，請注意保密。目錄目錄2輔助分析工具介紹31.1 WINDOWS任務管理器31.2 SQL Server事件探查器（SQL-PROFILE）41.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 Route361.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輔助分析工具介紹假如系統出現問題，由於產生問題原因很多，可能是COM+元件出現了問題，或是SQL Server資料庫出現了問題，或作業系統本身就存在問題，或是網路存在問題。所以我們需要綜合多個可能原因，使用部分輔助工具對系統進行跟蹤檢測，然後分析跟蹤結果，最終找到問題所在。下面就常見部分輔助工具作一個簡單介紹：1.1 WINDOWS任務管理器假如K/3系統很慢，是不是系統沒有可用CPU和記憶體等資源了？Windows任務管理器能够幫助我們發現系統資源使用情況。一)使用方法要打開“任務管理器”，請用右鍵單擊任務欄上空白處，然後單擊“任務管理器”，或把 “Ctrl+Alt+Delete”三個鍵同時按下，選擇“任務管理器”。 * 選擇“性能”選項卡，以下圖：能够發現系統CPU和記憶體使用情況。在系統出現性能問題時，監測一段時間系統資源使用情況。* 選擇“進程”選項卡，以下圖：假如在上圖中發現CPU或記憶體使用率比較高，通過該圖，能够發現資源到底被哪些進程所消耗。是否還有別系統（除K/3）消耗了寶貴CPU和記憶體資源。下圖中能够看出SQL Server消耗了系統91CPU，K/3消耗了8%CPU。二)資料庫伺服器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.2 SQL Server事件探查器（SQL-PROFILE）关键用來跟蹤資料庫SQL執行情況，發現耗時較長SQL,從而發現影響性能原因,分支機搆能够使用此工具得到跟蹤檔，把跟蹤檔返回到研發，用來分析和定位問題。這是最有效定位分析問題手段。一.使用方法K/3出現性能問題，很多全部是與SQL Sever資料相關。是否是一次查詢了太多資料造成資料庫負載過大，出現性能問題？使用該工具能够使我們發現是哪些SQL 語句消耗了SQL Server資料庫資源，對於發現性能問題會很有幫助，特別是給研發軟體工程師們。SQL 事件探查器用於以下活動： 逐步分析有問題查詢以找到問題原因。查找並診斷運行慢查詢。捕獲導致某個問題一系列 SQL 語句。然後用所保留跟蹤在某台測試伺服器上複製此問題，接著在該測試伺服器上診斷問題。監視 SQL Server 性能以精細地調整工作負荷。1）啟動事件探查器工具在“開始”功效表，依次指向“程式”、“Microsoft SQL Server”，然後單擊“事件探查器”。 2）打開該程式後選擇“檔”功效表“新建”子功效表“跟蹤”，打開以下介面：選擇SQL Server伺服器名稱（或輸入IP位址，假如是本機器能够輸入“.”英文句號），然後輸入SQL Server身份驗證登陸名和密碼，能够和資料庫管理員聯繫。3）選擇“事件”選項卡n 在該圖中設置需要跟蹤SQL Server事件類。关键用來跟蹤SQL語句和存儲過程事件，通常情況下只要設置TSQL事件類SQL:BatchCompleted，SQL:StmtCompleted事件和存儲過程事件類RPC:Completed、SP:Completed，SP:stmtCompleted事件即可。4）選擇“資料列”選項卡，以下圖：在該圖中選擇要捕獲數據列。建議把左邊資料列全部添加到選定資料列表中，捕獲完整，充足資訊。設置完上面資訊後，點擊“運行”按鈕。對選定資料庫伺服器進行一定事件跟蹤，然後另存為跟蹤文件，以下圖：能够對資料列：CPU（事件所使用CPU事件，毫秒為單位），Reads（伺服器代表事件執行邏輯磁片讀取數），Writes（伺服器代表事件執行物理磁片寫入數），Duration（事件所花費事件總計，毫秒為單位）進行查看，查找讀取或寫入物理磁片次數多操作，耗時比較多操作。為查找性能問題提供有力證據，對性能優化也含有參考價值。各個資料列具體含義列舉以下表，以供參考查閱。數據列列號描述Application Name110創建與 SQL Server 實例連接用戶端應用程式名。 該列由應用程式傳遞值填充，而不是由所顯示程式名填充。 Binary Data2與在跟蹤中捕獲事件類相關二進位值。 ClientProcessID19由主機電腦分配給進程 ID，在該進程中客戶應用程式正在運行。假如用戶端提供用戶端進程 ID，則填充此資料列。 Column Permissions44表明是否已設置了列許可權。分析語句文本，以確定將哪些許可權應用到了哪些列。 CPU 18事件所使用 CPU 時間總計（以毫秒為單位）。 Database ID13USE database 語句所指定資料庫 ID，假如沒有對給定實例發出過 USE database 語句，則是默認資料庫。假如在跟蹤內捕獲 Server Name資料列且伺服器可用，則 SQL 事件探查器將顯示資料庫名。 通過使用 DB_ID 函數確定資料庫值。 DatabaseName35正在運行用戶語句資料庫名稱。 DBUserName140用戶端 SQL Server 用戶名。Duration 13事件所花費時間總計（以毫秒為單位）。 End Time 15事件結束時時間。啟動事件事件類（如 SQL:BatchStarting 或 SP:Starting）該列不填充。 Error31給定事件錯誤號。通常是存儲在 sysmessages 中錯誤號。EventClass127捕獲事件類類型。 EventSubClass121事件子類類型，提供有關每個事件類進一步資訊。比如，Execution Warning 事件類事件子類值代表執行警告類型： 1 = 查詢等候。查詢必須等候資源（如記憶體）才能執行。2 = 查詢超時。查詢在等候執行所需資源時超時。全部事件類該資料列均不填充。FileName36所修改檔邏輯名稱。 Handle33ODBC、OLE DB 或 DB-Library 所用整數，用以協調伺服器執行。 Host Name18正運行用戶端電腦名。假如用戶端提供主機名，則填充此資料列。若要確定主機名，請使用 HOST_NAME 函數。Index ID24受事件影響物件上索引 ID。若要確定物件索引 ID，請使用 sysindexes 系統表 indid 列。 Integer Data25與在跟蹤中捕獲事件類相關整型值。 LoginName11用戶登錄名（SQL Server 安全登錄或 Microsoft Windows 登錄憑據，格式為 DOMAINUsername）。LoginSid141登錄用戶安全標識號 (SID)。能够在 master 資料庫 sysxlogins 表中找到該資訊。對於伺服器中每個登錄，SID 是唯一。 Mode32不一样事件所用整數，用於描述事件已接收或要請求狀態。 NestLevel29表示 NESTLEVEL 所返回資料整數。 NT Domain Name17用戶所屬 Microsoft Windows NT 4.0 或 Windows 域。 NT User Name16Windows NT 4.0 或 Windows 用戶名。Object ID22系統分配物件 ID。ObjectName34引用對象名。ObjectType28表示事件中包含物件類型值。該值對應於 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 Name126跟蹤 SQL Server 實例名。Severity20異常錯誤嚴重級別。 SPID112SQL Server 指派與客戶端相關伺服器進程 ID。Start Time114啟動事件時間（可用時）。State30等同於錯誤狀態代碼。Success23表示事件是否成功。取值包含： 1 = 成功。0 = 失敗比如，1 表示許可權檢查成功，0 表示該檢查失敗。TargetLoginName42對於以登錄為目標操作（比如，添加新登錄），是目標登錄名稱。TargetLoginSid43對於以目標為登錄操作（比如，添加新登錄），是目標登錄 SID。TargetUserName39對於以資料庫用戶為目標操作（比如授予用戶許可權），是該用戶名稱。TextData1與跟蹤內捕獲事件類相關文本值。不过，假如正在跟蹤參數化查詢，則不以 TextData 列中資料值顯示變數。Transaction ID4系統分配事務 ID。Writes17伺服器代表事件執行物理磁片寫入數。二.部分使用技巧n 在選擇要跟蹤事件時不要使用默認設置，一定要根据上面使用方法中描述選擇部分事件，否則會跟蹤到很多無用連接或回話資訊。選擇SQL:BatchCompleted，SQL:StmtCompleted事件和存儲過程事件類RPC:Completed、SP:Completed，SP:stmtCompleted即可。假如發現某一段時間有規律發生性能問題，需要事先跟蹤，跟蹤一段時間，而不是問題已經發生了再去跟蹤。跟蹤一段時間後，約1-2小時保留一次，否則跟蹤檔太大，耗用太多記憶體會影響伺服器記憶體。在保留時要選擇保留為跟蹤檔（默認是這樣），保留為其它格式會丟失分析性能資料，以前有分支機搆人員就是保留為SQL腳本發給研發，這對分析問題毫無價值。跟蹤檔可能會很大，不过壓縮百分比很高，壓縮後作為K/3性能問題診斷模版一部分回饋給研發。為了不使跟蹤檔過大，在篩選條件上選擇Duration=200事件，因為執行週期很短SQL不是我們在性能分析中關注重點物件，同時全部SQL全部跟蹤會很多，設置以下。附件是一個跟蹤檔模版，SQL Server 本身也帶有很多模版，在SQL Server安裝目錄80ToolsTemplatesSQL Profiler路徑下，假如有興趣也能够學習使用。怎样跟蹤觸發器在跟蹤SQL時候，可能會發現即使單條Insert、Deleted、Update語句全部會很慢。這種情況下，有可能是請求資源被鎖定或CPU等硬體資源不足等。除此之外，還能够檢查是否是觸發器造成。有些觸發器工作不良好：如使用游標來處理資料，或由於觸發器位置不對，使得本來能够批量處理情況，只能單條處理。如：Master-Detail表資料結構中，Detail表中觸發器只能處理一條Detail中資料。而通常情況下，能够成批次處理Detail中資料。通常開發人員也极少留心觸發器嵌套調用關係，所以對嵌套造成後果，也极少考慮。種種原因，提醒我們值得去留心觸發器對SQL Server影響。使用SQL Server Profiler是能够跟蹤到觸發器執行情況，選擇事件中存儲過程SP：StmtCompleted事件即能够跟蹤觸發器運行情況；選中NestLevel資料列則能够很好瞭解到觸發器嵌套運行情況。附件中是一個跟蹤觸發器模版。三.关键跟蹤資料解釋我們关键通過跟蹤資料中Duration(執行週期)列資料來發現那些耗用資料庫伺服器CPU特別嚴重SQL,然後去優化她們實現。假如你比較瞭解SQL,能够試著把SQL拷貝到查詢分析器，通過分析查詢計畫，建立合適索引來優化性能。或能够把Duration較長SQL回饋到研發來分析。我們還需要關注Reads資料列，它代表磁片邏輯讀次數，假如很多SQL語句Reads次數全部很高（達到幾十萬幾百萬甚至幾千萬次），這有可能是兩方面原因。首先有可能是記憶體不足，SQL Server頻繁切換記憶體資料。另一個可能原因就是表和索引存儲碎片太多，這能够通過在賬套管理中賬套優化操作來解決，這個功效能够了解為磁片整理。關注CPU和Duration兩列資料對比情況，能够判斷CPU資源是否足夠，假如大多數SQL語句CPU列資料明顯低於Duration，假如CPU曲線又很高，沒有發生嚴重阻塞，我們能够認為CPU處理佇列太長，需要增加CPU資源。1.3 資料庫阻塞監測工具有時候資料庫伺服器CPU耗用很低，不过系統整體性能很差，有可能是資料庫發生阻塞，在這兒有一個監測工具能够得到阻塞情況。在查詢分析器上打開工具-選項，修改結果設置選項把每列最多字元數修改為8000。把查詢結果改為文本顯示。在發生性能問題時在查詢分析中有問題賬套上執行以下SQL。把執行結果保留為檔回饋到研發，研發人員會根據此結果得出一定結論。1.4 K/3性能監控工具工具路徑：Program FilesKingdeeK/3ERPKDMainDbg.exe(或KDLogMonitor.exe)K/3性能檢測工具包含三個部分：1、用戶端診斷工具 2、用戶端代碼及跟蹤 3、COM+跟蹤工具.已在K/3V10.2中廣泛應用並與K/3集成，幫助分析解決了部分性能問題，大大提升了開發效率。现在元件級跟蹤和COM+跟蹤，適用於K/3全部版本，甚至包含其它任何使用VB開發程式產品，包含U8。1、用戶端診斷工具用於跟蹤後期綁定元件介面物件創建、方法調用、運行時間、執行結果資訊等情況。以下是明細功效介紹:n 能够跟蹤物件創建時間。VB本身對於物件創建出錯，通常见物件創建失敗或Automation錯誤提醒。無法確定知道具體哪個元件出現問題，該工具能够明確標識出創建失敗組建名稱。K/3 V10.2安裝包調整過程中，碰到大量元件創建失敗情況，通過該工具快速定位到創建失敗元件，極大提升了解決安裝包問題速度。n 提供了查找功效。方便了開發人員對於自己關心元件查找，定位。n 增強了過濾功效，能將調用時間比較長事件用藍色字體突出顯示，同時過濾掉調用時間很小事件。n 將物件創建事件和方法調用事件分別用不一样顏色顯示，便於識別；同時將沒有嵌套方法調用使用一行來顯示2、用戶端代碼級監測工具用於關鍵函數運行資訊輸出，方便在客戶環境下定位程式問題、並提供性能資料搜集。3、COM+跟蹤工具利用COM+本身事件發佈模型，監控COM+元件方法調用，運行結果資訊。关键用於COM+伺服器端資訊跟蹤，查看哪個中間層元件調用時間長或記憶體消耗打，以確定性能問題或其它問題所在。（1）選擇要跟蹤COM+應用套裝程式（2）確定進行跟蹤1.5 元件服務关键用來分析中間層性能表現一)使用方法使用元件服務管理工具能够配置和管理 COM 元件及 COM+ 應用程式，在K/3中間層伺服器監視元件使用情況。1）啟動元件服務管理工具在“開始”功效表，依次指向“程式”、“管理工具”，然後單擊“元件服務”。 2）檢查K/3中間層元件是否在運行以下圖，選擇“Com+應用程式”能够發現哪些元件正在運行；選擇工具條上“狀態查詢”能夠愈加直觀查找哪些元件在運行中。假如用戶端用戶比較多或網路速度比較慢情況下，中間層伺服器有可能出現服務，從而引发性能問題。能够通過元件服務事件列表檢查是否有比較多事件在排隊等候。介面以下圖：二)怎样找到正在執行資源耗用多組件有時候假如中間層CPU或記憶體耗用很嚴重，由於在多個客戶併發下有時候客戶很難發現是那一項操作引發了問題，這時候能够找一下那一個元件包中哪一個元件耗用資源比較嚴重，配合其它觀察：如在此階段用戶全部在做那些操作，有助於發現引發問題功效。首先在任務管理器進程選頁簽上尋找耗用資源較多DLLHOST進程，在這兒說明一下，每一個中間層元件包在運行時有一個DLLHOST進程，每一個包包含很多元件。找到耗用資源較多DLLHOST，找對應PID(進程標示號)，根據PID在元件管理中能够找到對應元件包，然後在對元件包下面尋找調用時間長元件，把此元件資訊和其它用戶操作資訊回饋到研發，能够定位到具體功效。三)怎样判斷中間層阻塞對於中間層伺服器，有可能發生阻塞，這時候关键看上面所描述元件伺服器中事務列表中元件排隊情況，假如有較長排隊情況，就代表出現阻塞，能够考慮把組塞較多元件分離出來重新放到一個新建包中，因為每一個COM+元件包有一個進程。四)關於STA模式COM+元件線程數限制問題對於VB編寫COM+元件，由於不能編譯為MTA線程模型，每個元件包進程線程數默認為10個，也就是說同一個元件包中全部元件功效只能最多有十個同時運行。對此問題，微軟提供了一個修改線程數量限制方法，那就是修改註冊表選項，能够讓線程數達到100。此項改進在V10.0已經在安裝包做了修改，假如是以前版本客戶能够直接修改中間層伺服器註冊表選項。能够直接把以下註冊表檔導入。 修改默認設置後，會提升中間層併發性能。1.6 SQLDiag.exeSQLDiag.exe 工具程式默認檔路徑位於 : Program FilesMicrosoft SQL ServerMSSQLBinn 目錄之下，產生出來日誌檔默認放在:Program FilesMicrosoft SQL ServerMSSQLLOG 目錄之下，檔案名為 SQLDiag.txt。它能够在同一時間、一次幫你搜集相當多資訊。在相同時間區段內，搜集各種方面資訊很关键。比如你觀察到 SQL Server 對某個查詢回應遲緩，可能需要同時觀察系統硬體各項資源使用，SQL Server 當時鎖狀況，是否有錯誤發生等等，必須要相互參照，才轻易找出禍首。 SQLDiag.exe 就能够在同一時間搜集到相當多資訊，它必須在 SQL Server 伺服器本身執行，而不能在用戶端工作站執行。輸出相關資料列述以下：l 獲取記錄檔，若是 SQL Server 版本，這些記錄檔默認是位於“Program FilesMicrosoft SQL ServerMSSQLLOG”目錄下，名稱為 ERRORLOG 及副檔名是數字先前版本，如 Errorlog.1、Errorlog.2 一直到 Errorlog.6 等等，若版本是 SQL Server 7.0，則這些記錄檔路徑默認是 MSSQL7log。 這些日誌檔是文本類型，雖然名稱是 ErrorLog，但放不儘然是錯誤，SQL Server 會將部分資訊，如啟動時所完成動作，放在這個檔中。當然，若有錯誤，也會存放在這個檔中，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 擴展存儲過程獲取軟硬體平臺簡要資訊。 l 通過 sp_helpextendedproc 系統存儲過程獲取擴展存儲過程(extended stored procedures)相關資訊。由於擴展存儲過程是以 DLL 形式與 SQL Server 关键執行在同一個程式中，若有任何閃失，輕則造成記憶體洩露，重則導致服務程式當掉。通過這個系統存儲過程會表列出全部擴展存儲過程，你能够將它輸出與通常安裝 SQL Server 做個比較，看看是否有用戶自行安裝擴展存儲過程，造成系統不穩定。 l 從 master.dbo.Sysprocesses 系統資料表獲取程式(process)相關資訊。當系統忙碌時，你能够通過它觀察到底有哪些程式在伺服器內執行，各用了多少資源等等。搭配其它系統存儲過程，如 sp_who、sp_who2、sp_lock 等等，能够獲得整體狀況。比如通過 waittime 欄位知道有哪些程式已經等候很久，從 cpu、physical_io 和 memusage 欄位能够看出哪些程式在耗 CPU、磁片輸出入或記憶體資源。和打開了事務，但執行狀況卻是 sleeping 不當事務管理。 l 通過 DBCC INPUTBUFFER (spid) 獲取各進程正在執行命令。 l 獲取鎖鏈接起始者(head blocker)。 l 通過 MSInfo32.exe 獲取系統細節資料，這需要耗掉部分時間。 l 最後 100 個查詢和異常狀況 (Exception)。 SQLDiag.exe 獲取系統資訊是靠 MSInfo32.exe 工具程式取得系統相關資訊，你能够直接執行該工具程式以查看更豐富資訊，以下圖： 點擊 MSInfo32.exe 主功效表檔 - 導出選項，能够將系統當前各項資訊導出成文字檔案，供你日後參考。由於導出屬性包含軟硬體各項細節資訊，所以按下導出後可能要稍等一下。SQLDiag.exe 是一個相當轻易執行工具程式，若要參照它使用方法，能够進入“命令提醒符”程式，轉到 SQLDiag.exe 所在目錄下執行 SQLDiag /?(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 執行實例 (Instance)。若不指定 I 選項，則連接至本機默認執行實例。 -U ：指定登錄 SQL Server 帳號。 -P ：上述帳號對應密碼。若指定 -P 選項但不賦予值，則 SQLDiag 認定密碼為空。密碼有區分大小寫。 -E：使用信任連接，也就是以當前登錄作業系統帳號來連接 SQL Server。 -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 -O diag.log 通過 E 參數，會以登錄作業系統帳號登錄 SQL Server，而 O diag.log 參數則會產生名稱為 diag.log 輸出。1.7 性能監視器(Performance Monitor)Windows NT 之後所附性能監視器是顯示各種性能資料很詳盡工具。你能够用它來觀測伺服器當前運行，記錄整個系統多台機器上各種性能計數器，以找出整個系統瓶頸。我們在性能調校過程中會一再地用它。Windows NT 之後，就直接提供性能監視器(Performance Monitor)，通常是用來查看、跟蹤在整個系統中，是否有哪個部分顯示資源不足狀態，或是系統使用狀況、演變趨勢等等。而性能計數器代表是一種指標，它本身不是問題，一些背後隱含問題導致該指標變化。所以不要看到單一性能計數器值就下定論，一定要建立推論：是什麼原因導致該性能計數器有當前值，若該原因是真，那同時哪些性能計數器應該顯示什麼現象？而你當然應該再進一步分析與推論相關計數器。性能監視器讓你獲得證據以完成： l 支持自己假設，或是推翻結論另尋原因。 l 獲取電腦全盤狀態，讓你能够發現電腦發生了什麼狀況(WHAT) ，而不是為何(WHY)或怎样(HOW)發生這種狀況。 l 抽取電腦變化狀態，有基線以供比較是很关键，它讓你能够知道什麼是正常，而什麼不是。假如無法獲取基線，則尋找記錄中變化，查看計數器相對值而非絕對值，並與先前使用經驗做一個比較。除了通常硬體，如記憶體、硬碟、中央處理器乃至於網路等系統提供性能計數器外，大部分微軟提供伺服器軟體在安裝完畢後，也會註冊它本身性能計數器，而 SQL Server 會增加相當多類性能計數器供你查核使用狀況，而這些性能物件皆以“SQLServer:”開頭。在要抽取性能記錄之前，儘量將不相關、當前不需要服務先停掉，如 IIS，系統掃毒等等。假如需要調校電腦可能會當機，則要採用遠端記錄，避免資料未記錄到就掛了。相反地，若網路有問題，當然需要在本機完成記錄。而一旦採用遠端監控，要先同时兩台機器時間才好比對結果。你能够在命令提醒視窗中，通過以下命令同时系統之間時間：NET TIME RemoteMachine /SET就 SQL Server 使用特征來說，依其关键程度，觀察硬體資源不足順序依序是：記憶體、硬碟、中央處理器乃至於網路。SQL Server 是很耗用記憶體軟體，因為它凡用過資料必先留在記憶體中，除非資源不足，否則不輕易從緩衝區清掉，讓資料庫運行儘量少使用硬碟。當記憶體不足時，會連帶地影響硬碟和中央處理器。比如有新資料要放到屬性已滿緩衝區，則 SQL Server 內部負責將緩衝區屬性更新到硬碟 LazyWriter 程式就需要持續地執行，好更新緩衝區資料，並釋放較沒有使用到記憶體區塊，這會同時讓 CPU 與硬碟忙碌起來。也就是說，當 CPU 和硬碟性能不足時，有可能源頭是記憶體不足造成。 磁片子系統性能不佳，也一定會讓 SQL Server 性能好不起來，畢竟它需要大量讀寫存在硬碟上資料庫內資料。若你沒錢購置 RAID，最好也多買幾顆硬碟，讓 Log 檔、資料庫檔和 Windows 作業系統用做虛擬記憶體交換檔分在不一样硬碟上，因為這三種檔設計目标不一样，存取習性與頻率也不一样，當三者在同一顆硬碟上時，有可能因為多個人存取資料庫，有做更新，有查詢，這些運行讓作業系統要配置虛擬記憶體，所以硬碟要同時存取三種檔，這會導致磁頭忙碌地移動，讓硬碟存取大多是隨機讀取，無法做循序讀取，導致硬碟性能降低。所以建議將三種檔分別放在不一样硬碟上。 硬碟性能遲緩，肯定導致資料庫查詢與資料異動延遲(這兩種動作分別是存取資料庫檔與 Log 檔)，這又造成事務要花較長時間才能結束，進而讓鎖資源無法釋放，多人存取系統相互等候資源，進入大家全部被延遲慘況。CPU性能关键性不用強調了吧，它慢，週邊設備再快全部沒有用。但要注意是，我們當前電腦設計往往是中央處理器極快，但週邊運行緩慢，導致CPU無法有效發揮它能力。所以當考慮加強中央處理器時，要看看是否是周邊設備不足，導致CPU忙碌。通常來說，啟動性能監視器後，只要記錄資訊而不需要做圖。以較穩定方法抽取電腦完整狀態，由於在事前你很難預料判斷瓶頸時，會需要哪些資料，所以儘量記錄全部計數器5。如圖3.5 所表示，除了通過默認視窗觀察系統當前情況外，最好還要通過添加記錄方法，對系統作較長時間監控。執行性能監視器時間要長到足以抓取到問題，通常粗略配置綱要以下：l 記錄2小時 每 4 秒記錄一次。 l 記錄1天 每 30 秒記錄一次。 l 記錄1天 每 180 秒記錄一次。活動中圖形只能顯示瞬間系統狀況，長時間記錄資料才能看出趨勢 時間間隔不要小於 4 秒，以免記錄這個動作本身就傷害電腦性能，除非是要抽取磁片 I/O 性能，最高頻率也勿超過每 2 秒記錄一次。另外，為減輕對電腦長期影響，若沒有特殊需求，只要記錄 2 小時就好。假如需要話，執行diskperf y 以抽取磁片性能資訊。首次記錄時，在不傷及性能前提下，僅可能地抽取全部物件，供你對整個系統有一個全方面性概觀。縮略表列通常要記錄物件以下(假如不可能取得全部物件)： l Cache, memory, objects, paging file, physical disk, logical disk, process, thread, processor, server, system。 l 全部 SQL Server 物件。 l 假如有網路相關問題，全部與網路相關物件 (Protocol Stack Objects)。 一次記錄通常無法包含全部需要資訊，可能要数次後續不一样記錄資料。另外，在記錄上还有其它考量，如每個記錄存成一個檔，在記錄停止後，下次打開一個新檔。檢查記錄檔所花硬碟空間。若某個日誌檔屬性太大，而你只需要其中关键部分，重新建立記錄(Re-logging)可能會很有用。日誌檔最大極限 1 gigabyte (GB)，而單一日誌檔太大也很難處理，可行日誌檔大小應該在 100 megabytes (MB) 左右，建議取 50 MB。若你需要長時間記錄，而系統是在 Windows NT 上，考慮以 script 自動停掉並重起記錄，以減低記錄檔大小。若在 Windows 則能够利用 Sysmon 計畫任務，定時停掉並重起記錄，以分成多個日誌檔。 使用Windows XP 或 Windows ，能够通過 Relog.exe 工具程式對事件重新建立記錄，它能够將日誌檔轉換成不一样格式，並在新建立日誌檔中包含較少計數器數目。使用 relog.exe 步驟以下： 1. 查看日誌檔資料：打開先前抽取 .blg 文件。 2. 選擇你要繪圖計數器。 3. 圖表上以滑鼠右鍵選擇“另存新檔”，格式為 H