老鳥為了重點栽培菜鳥，決定交給菜鳥一個艱巨而光榮的任務。這天，菜鳥剛到公司還未坐下，老鳥便劈頭蓋臉的問道：“你知道，我們如何trace sql server執行語句嗎？怎麼手動分析這些trace檔案？如何将trace file與windows的性能螢幕結合，看到每個語句執行時的性能開銷？以及如何自動分析sql server trace檔案？”。
菜鳥還沒有反應過來，就被殺死了99%的老細胞，下意識的回答：“啊？”。
“去研究下吧”，這個周給我答複就好了，老鳥看出來了菜鳥的困惑，心理暗自驕傲。
菜鳥懷着一顆萬事不着急，先問g哥的平穩心态，開始瘋狂的問g哥，如何“手動trace sql server”。g哥開始調動億萬個神經細胞，搜尋着散落在地球上每一個角落的問題與答案，哦，原來使用sql server profiler工具：
start => all programs => microsoft sql server r2 => performance tools => sql server profiler
或者是： start => run => profiler
打開sql server profiler後， file => new trace => server type: database engine => server name: xxxx => login: xxxx => password: xxxx => connect
連接配接完畢以後，設定trace properties：
events selection => show all events => 選擇要trace的事件和字段 => run。一個簡單的demo長相如下：
trace啟動後，一會兒就有被抓到的語句跑出來：
歐耶，手動部署sql server trace很簡單嘛，搞定。菜鳥迫不及待的問g哥，“如何手動部署windows性能螢幕”。
g哥心想，這兩個是關聯問題吧，早知道你要問這個問題了，早已在你問第一個問題時，已經幫你做了最佳推薦：
start => run => perfmon => user defined => right click on the right side blank space => new => data collector set => type name: perfmon_base => create manually(advanced) => next
create data logs => performance counter => event trace data => next => select counters from computer => 展開性能名額分類，比如：sql server:buffer manager => page read/sec, page writes/sec等 => add => ok
next => root directory => finish
性能螢幕建立完畢後，最後一個步驟需要啟動這個性能螢幕，來抓取sql server性能名額。選擇剛才建立的資料收集器 => 右鍵點選 => start。
當菜鳥完成手動搜集windows性能螢幕以後，信心大增。再回過頭來問g哥，哪知道g哥早已推薦他：“sql server trace file與性能螢幕log檔案關聯”。g哥是何等聰明絕頂啊。
當sql trace檔案與性能螢幕log檔案關聯以後，畫面為分為四個區域：
查詢語句區域：檢視和選擇查詢語句
性能名額做圖區域：可以看到選中的查詢語句對應的各項性能名額做圖（性能名額做圖區域中紅色的豎線）
性能名額選擇區域：性能名額選擇區域選中或者取消相關的性能名額
查詢語句顯示區域：檢視被選中的相關查詢語句詳情
菜鳥能夠将sql server trace檔案與性能螢幕log檔案關聯在一起分析，是巨大的進步啊。可是，他還是不滿足于現狀，覺得一個個去點選查詢語句，太過于原始，效率很難提升，而且不友善過濾出自己關心的查詢語句。比如過濾出cpu占用最高的top 5查詢；i/o最高的top 5查詢；執行最為頻繁的查詢語句top 5等。
于是菜鳥想到了将sql server trace file檔案通過系統函數将其讀出來，存到一個表裡面。這樣，就可以利用資料庫強大的篩選，過濾，聚合功能得到自己關心的查詢語句了。
到目前為止，菜鳥已經找到了人生努力的方向，成為高富帥，迎娶白富美是指日可待了。可是菜鳥在分析性能的過程中逐漸意識到，由于查詢語句或者存儲過程的參數值是“亂七八糟”的，很難做有效的聚合統計。
革命尚未成功，同志還需努力，到底如何實作自動化分析trace檔案呢？菜鳥又想到了g哥，g哥很豪爽并不加思索的說“用rml utilities for sql server啊”。看來現在g哥已是菜鳥的救火隊長了，度娘表示很受傷，羨慕滴妒恨。
rml（replay markup language）utilities是ms sql server産品支援服務團隊内部開發使用的一個trace檔案分析工具。支援sql server 2005，2008，2008r2，2012和sql server 2014。
主要的功能包括以下幾個個方面：
分析最消耗sql server系統資源的應用和查詢
去除參數幹擾，統計彙總查詢性能消耗
生成可視化報表，性能消耗大戶一目了然
首先從下面的位址下載下傳對應的版本，分為x86的32位版和64位版：
rml安裝檔案(rmlsetup_amd64.msi)是基于windows msi的檔案。是以安裝過程你懂的，非常簡單，在此不一一截屏說明安裝步驟了。安裝完畢後，rml的預設安裝目錄會在"c:program filesmicrosoft corporationrmlutils"
打開rml command：start => all programs => rml utilities for sql server => rml cmd prompt
執行如下指令：
readtrace的參數是區分大小寫的，并且輸入檔案和輸出目錄不能夠在同一個目錄下。詳情參見readtrace -?的參數描述，這條語句的參數說明：
-i: 輸入的trace檔案目錄和檔案名
-o: 日志檔案輸出目錄
-s: 資料存放的資料庫伺服器
-d: 資料庫名字
-e: windows認證模式連結資料庫
-f: 不用生成每一個會話和請求的詳細rml輸出檔案
指令執行完畢後會自動化生成以下的分類報表：
performance overview
performance overview分類報表包括其他分類報表的入口，資源使用率的統計，性能總覽的詳細資訊。
application name
按照應用程式名稱做分類統計，這個統計報表可以知道每個應用程式對sql server系統資源的消耗情況。利用這個報表，我們很輕松就可以找到資源使用的大戶，針對性的采取必要的措施。
unique batches
這個分類報表非常有價值，在這個報表中，我們非常輕松的就可以發現占用cpu，run duration，io read，io write top batches語句塊。這個為我們優化具體的sql語句塊提供了非常友善的統計彙總。
interesting events
針對sql server資料庫事件的統計分類報表。
database id
按照資料庫辨別id的分類報表，從這個報表，我們可以很容易發現哪個資料庫的壓力比較大，可以選擇作為我們重點優化的資料庫。
unique statements
這個與unique batches分類統計報表類似，也是非常有價值的報表，隻不過這個是針對特定語句的分類統計報表，而不是針對語句塊，是以，這兩個報表的分析方式非常類似。
這個報表分别從cpu，duration，reads和writes四個角度統計出查詢語句執行次數及所占百分比。當我們檢視具體的執行語句的時候（點選處的執行語句），會打開下圖中的unique statement details頁面。這個頁面展示了相應查詢語句非常詳細的資訊，包括：執行語句模版，按照cpu，duration，reads和writes的統計彙總圖展示，按照時間順序的統計彙總表格，格式化後的查詢語句。
既然拿到top unique query語句，接下來的要做的事情就是花80%的時間和精力去優化這20%的top query并加以改善到産品環境，這樣我們sql server性能問題就可以解決了。
data lineage
這個報表是readtrace資料導入的日志資訊統計，包含你使用的參數資訊和rml的錯誤警告資訊等。比如，這裡就提示，我們的sql server trace檔案少了sp:stmtstarting事件的跟蹤。
login name
按照登入使用者聚合的分類統計報表，從這報表我們可以很容易發現哪些使用者是資料庫系統資源的大戶。
總結來看，rml utilities for sql server是一款與sql profiler結合得非常好的自動化trace檔案分析工具。利用這個工具強大的統計彙總功能，使得我們可以非常容易從多角度，多視野，多元度來發現問題，分析問題，解決問題，真正做到工欲善其事必先利其器的效果。
當菜鳥把這份心得呈現在老鳥面前的時候，老鳥簡直驚呆了：“不錯啊，來，給你十三個贊，每月一個贊”。
“每年不是十二個月嗎？”，菜鳥疑惑的問道。
“多的一個是十三薪”，老鳥一邊走着一邊回答。留着菜鳥一個人在風中淩亂。