参考文献
前言
之前听同事们之间交流经常会听到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或者错误而进行转储以便记录出错信息的文件。一般对这类文件的处理，都是建议打包后提交给微软分析的。在无法获得微软帮助的情况，就需要自己对此类文件进行分析了，然后找出问题原因，从而进行解决。
一、SQLDumper.exe介绍
前面介绍了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用处的代码如下所示：
C:\Program Files\Microsoft SQL Server\110\Shared>SqlDumper.exe /? Usage: SqlDumper.exe [ProcessID [ThreadId [Flags[:MiniDumpFlags] [SqlInfoPtr [DumpDir [ExceptionRecordPtr [ContextPtr [ExtraFile]]]]]]]] [-I<InstanceName>] [-S<ServiceName>][-remoteservers:[print|dump|freeze|resume|remote:guid\dumporigin\signature\localId\port\operationType]] Flags: dbgbreak = 0x0001 nominidump = 0x0002 validate_image = 0x0004 referenced_memory = 0x0008 all_memory = 0x0010 dump_all_threads = 0x0020 match_file_name = 0x0040 no_longer_used_flag = 0x0080 verbose = 0x0100 wait_at_exit = 0x0200 send_to_watson = 0x0400 defaultflags = 0x0800 maximumdump = 0x1000 mini_and_maxdump = 0x2000 force_send_to_watson = 0x4000 full_filtered_dump = 0x8000 no_auto_remote_dump_invocation = 0x40000 MiniDumpFlags: Normal = 0x0000 WithDataSegs = 0x0001 WithFullMemory = 0x0002 WithHandleData = 0x0004 FilterMemory = 0x0008 ScanMemory = 0x0010 WithUnloadedModules = 0x0020 WithIndirectlyReferencedMemory = 0x0040 FilterModulePaths = 0x0080 WithProcessThreadData = 0x0100 WithPrivateReadWriteMemory = 0x0200 WithoutOptionalData = 0x0400 WithFullMemoryInfo = 0x0800 WithThreadInfo = 0x1000
从上面的命令可以看出，要想对某一application进行dump，需要先找出其pid(processes id)，然后加上一些Flags的控制标识来控制dump内容。比如，我现在想对SQL Server 进行dump，先找到SQL Server 的pid 为1672（可以在sql server configure management中找到sql server 2012服务的ProcessID），想dump所有的内存信息，那就可以用下面的命令来进行：
C:\Program Files\Microsoft SQL Server\110\Shared>SqlDumper.exe 1672 0x0010
其中，0x0010 表示all_memory，这样，在C:\Program Files\Microsoft SQL Server\110\Shared目录下会产生SQLDmpr0001.mdmp和SQLDUMPER_ERRORLOG.log这两个文件，这就是转储文件(.mdmp)。
以下是几个比较常见的dump 标识：
0x0120 - Minidump --这个flag只dump 一个Process的堆栈和载入模块的信息，这是最小的转储方式，也是SQL Server自动产生dump文件的方式。 0x01100 – Full Dump --这个flag会转储Process的整块信息，如果在64位的系统上，其文件大小还是很大的。 0x8100 – Filtered Dump --这个flag用来转储用于于其他服务器用途（包括过程缓存）的内存信息
二、SQL Server方式的DUMP
使用Sqldumper只是手工产生dump文件的一种方式，当然，产生dmp文件的方式还是很多的，SQL Server内部也提供了这样的工具。主要是DBCC STACKDUMP 和DBCC dumptrigger 这两个命令。当然还可以通过TraceFlag来控制是否产生dmp文件或者遇到什么错误时才产生文件。比如，我们想产生一个Full Dump，必须打开Trace Flag 2544 和 2546，然后执行DBCC STACKDUMP ，命令如下：
--DBCC stackdump dbcc traceon(2544, -1) go dbcc traceon(2546, -1) go dbcc stackdump dbcc traceon(2544, -1) go dbcc traceon(2546, -1) go
在执行完上述命令以后，我们会发现在D:\Program Files\Microsoft SQL Server\MSSQL11.SQL2012\MSSQL\Log（我将sqlserver2012的示例安装在了D盘）目录下多出了如下图所示的三个文件：
再次执行上述命令，又会多出下图所示的三个文件：
而SQLDUMPER_ERRORLOG.log和ERRORLOG这两个文件是公用的。
如果想让SQL Server 只针对 某个错误而产生转储文件，可以使用dbcc dumptrigger，下面是一个例子
--DBCC dumptrigger --设置dump的触发器为错误802 dbcc dumptrigger('set', 802) go -- 查看当期的dump触发器内容 dbcc traceon(3604, -1) go dbcc dumptrigger('display') go dbcc traceoff(3604, -1) go -- 关闭当期的dump触发器。 dbcc dumptrigger('clear', 802) go
执行上述命令以后，在SSMS中显示如下信息：
DBCC execution completed. If DBCC printed error messages, contact your system administrator. DBCC execution completed. If DBCC printed error messages, contact your system administrator. Dump Triggers DebugBreak = 0 CExDumpTriggers @0x00000001ECBD4140 Exception = 802 DBCC execution completed. If DBCC printed error messages, contact your system administrator. DBCC execution completed. If DBCC printed error messages, contact your system administrator. DBCC execution completed. If DBCC printed error messages, contact your system administrator.
三、分析mdmp文件的一些知识说明
以上只是介绍了mdmp的产生，以及如何自己手工产生mdmp文件，但如何对mdmp文件进行分析才是重点。曾经对其进行了一些分析，但道行有限，能获得的信息不多。把如何分析mdmp文件的过程分享出来，希望更厉害的人能从中找到一些SQL Server的运行原理。
1、调试
由于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的线程信息：
use master select spid,kpid from sys.sysprocesses
查询结果如下：
spid kpid ------ ------ 1 3260 2 3356 3 3352 4 3252 5 3256 6 3236 7 3368 8 3372 10 0 11 3436 12 3380 13 3264 14 4016 15 3768 16 3348 17 3284 18 0 19 0 20 0 21 0 22 0 23 0 24 3576 25 4024 26 0 28 4020 29 2368 30 2556 31 4028 51 0 52 3364 53 0 56 0 57 0
查看线程信息也可以通ProcessExplorer查看，如下图所示：
不过这得windbg的支持才可以，windbg可以在Download and Install Debugging Tools for Windows下载到，我使用的是Install Debugging Tools for Windows as a Standalone Component，也就将windbg作为一个单独的组件进行安装。
四、使用windbg
在了解上述知识后，就可以使用windbg来进行分析了。
1、windbg环境的配置
到微软的网站下载windbg后直接安装，安装完成后，需要配置symbols的path，打开windbg，File --> Symbols File Path 在弹出的对话框输入
srv*D:\app\symbols*http://msdl.microsoft.com/download/symbols
其中D:\app\symbols是本地硬盘的文件夹，在使用时，windbg会到http://msdl.microsoft.com/download/symbols下载相关的symbols，我这边下载的一共有6.27MB大小。
2、打开mdmp文件
打开windbg，File --> Open Crash Dump，选择mdump文件，在弹出的对话框里点击yes，这里我选择的是在C:\Program Files\Microsoft SQL Server\110\Shared目录下会产生SQLDmpr0001.mdmp。
3、分析mdmp
在下面的对话框输入“~”，如下图所示：
敲回车以后会出现线程的信息，信息如下：
View Code
3、其他
windbg的功能是很强大的，是通往sql server内部一个强大工具。要想了解的话，估计得好好研究下<windows internal>，有兴趣的可以自行深入。
本文转自xwdreamer博客园博客，原文链接：http://www.cnblogs.com/xwdreamer/archive/2012/07/02/2572715.html，如需转载请自行联系原作者
