<a href="http://hi.baidu.com/anydb/blog/item/3e9ff2c062d07c140ef4778f.html">SQL Server dump 介紹</a>
之前聽同僚們之間交流經常會聽到dump這個詞，但是一直不明白dump是什麼東西，今天特地整理一下這方面的資料。我們稱dump為轉儲，但這邊我們說的dump不是SQL Server本身的DUMP備份指令，而是指通過sqldumper.exe中的dump。那什麼是dump呢，dump指的是将某種内容轉換為另外一種更具可讀性的方式。在ORACLE中，有專門的dump指令可以dump出資料檔案等的内容，其trace也相當于另外一種dump。通過dump，我們便可以了解整個系統的運作原理。SQL Server這方面的資料很少，當然，這也符合了微軟不開源的政策。不過這幾年來，關于這方面的資料比較多了，通過google可以獲得相關的内容。
最早對此感興趣的是碰到了很多人經常問的.mdmp檔案，mdmp的叫mini dmp，也可以叫memory dmp，這是由于SQL Server 在運作過程中，遇到了一些bug或者錯誤而進行轉儲以便記錄出錯資訊的檔案。一般對這類檔案的處理，都是建議打包後送出給微軟分析的。在無法獲得微軟幫助的情況，就需要自己對此類檔案進行分析了，然後找出問題原因，進而進行解決。
前面介紹了SQL Server 會在運作時自動産生一些dump檔案，我們也可以手工産生dump檔案，産生dump檔案的方式，就是通過Sqldumper來進行的。自 SQL Server 2000 Service Pack 3 (SP3) 起，Microsoft SQL Server 2000 中開始附帶 Sqldumper.exe。Sqldumper.exe 可根據任一 Microsoft Windows 應用程式的需要生成轉儲檔案。Sqldumper.exe不僅可以轉儲SQL Server，還可以轉儲其他的windows application。
我使用的環境是SQL Server 2012，是以SQLDumper位于C:\Program Files\Microsoft SQL Server\110\Shared下，我們可以運作SQLDumper /? 檢視其使用方法，16進制代碼是控制辨別符。查詢SQLDumper用處的代碼如下所示：
從上面的指令可以看出，要想對某一application進行dump，需要先找出其pid(processes id)，然後加上一些Flags的控制辨別來控制dump内容。比如，我現在想對SQL Server 進行dump，先找到SQL Server 的pid 為1672（可以在sql server configure management中找到sql server 2012服務的ProcessID），想dump所有的記憶體資訊，那就可以用下面的指令來進行：
其中，0x0010 表示all_memory，這樣，在C:\Program Files\Microsoft SQL Server\110\Shared目錄下會産生SQLDmpr0001.mdmp和SQLDUMPER_ERRORLOG.log這兩個檔案，這就是轉儲檔案(.mdmp)。
以下是幾個比較常見的dump 辨別：
使用Sqldumper隻是手工産生dump檔案的一種方式，當然，産生dmp檔案的方式還是很多的，SQL Server内部也提供了這樣的工具。主要是DBCC STACKDUMP 和DBCC dumptrigger 這兩個指令。當然還可以通過TraceFlag來控制是否産生dmp檔案或者遇到什麼錯誤時才産生檔案。比如，我們想産生一個Full Dump，必須打開Trace Flag 2544 和 2546，然後執行DBCC STACKDUMP ，指令如下：
在執行完上述指令以後，我們會發現在D:\Program Files\Microsoft SQL Server\MSSQL11.SQL2012\MSSQL\Log（我将sqlserver2012的示例安裝在了D盤）目錄下多出了如下圖所示的三個檔案：
再次執行上述指令，又會多出下圖所示的三個檔案：
而SQLDUMPER_ERRORLOG.log和ERRORLOG這兩個檔案是公用的。
如果想讓SQL Server 隻針對 某個錯誤而産生轉儲檔案，可以使用dbcc dumptrigger，下面是一個例子
執行上述指令以後，在SSMS中顯示如下資訊：
以上隻是介紹了mdmp的産生，以及如何自己手工産生mdmp檔案，但如何對mdmp檔案進行分析才是重點。曾經對其進行了一些分析，但道行有限，能獲得的資訊不多。把如何分析mdmp檔案的過程分享出來，希望更厲害的人能從中找到一些SQL Server的運作原理。
由于SQL Server 也是在windows平台是運作的一款程式，有問題時，把它當成一款普通的windows程式來進行調試就行了。在windows上，有兩方面的調試，一個是核心模式調試，一個是使用者模式調試。核心調試是針對Windows作業系統進行調試的，反應windows OS内部和硬體裝置的運作。使用者模式的調試就是對應用程式進行調試，因為應用程式就是運作在使用者模式上的。二者的調試是不同的，這邊就不做過多的介紹，有疑問，就google吧。
調試還有另外一個差別：是在程式運作時對其調試(live-debugging)，還是讀取mdmp分析調試(post-mortem debugging)。這二者也是不一樣的。在live-debugging時會使程式挂起，然後設定bp(break point)，觀察程式的運作行為。這邊主要介紹post-mortem debugging.
在調試過程中，我們最常見的是分析線程(thread)的堆棧(stack)的跟蹤資訊。因為在windows平台上，application是以process來運作的，而一個process又包含了thread，thread才是真正在運作一些函數功能。我們可以通過如下指令來看運作SQL Server的線程資訊：
查詢結果如下：
檢視線程資訊也可以通ProcessExplorer檢視，如下圖所示：
在了解上述知識後，就可以使用windbg來進行分析了。
到微軟的網站下載下傳windbg後直接安裝，安裝完成後，需要配置symbols的path，打開windbg，File --> Symbols File Path 在彈出的對話框輸入
其中D:\app\symbols是本地硬碟的檔案夾，在使用時，windbg會到http://msdl.microsoft.com/download/symbols下載下傳相關的symbols，我這邊下載下傳的一共有6.27MB大小。
打開windbg，File --> Open Crash Dump，選擇mdump檔案，在彈出的對話框裡點選yes，這裡我選擇的是在C:\Program Files\Microsoft SQL Server\110\Shared目錄下會産生SQLDmpr0001.mdmp。
在下面的對話框輸入“~”，如下圖所示：
敲回車以後會出現線程的資訊，資訊如下：
View Code
windbg的功能是很強大的，是通往sql server内部一個強大工具。要想了解的話，估計得好好研究下<windows internal>，有興趣的可以自行深入。
本文轉自xwdreamer部落格園部落格，原文連結：http://www.cnblogs.com/xwdreamer/archive/2012/07/02/2572715.html，如需轉載請自行聯系原作者