Introduction
在这篇专栏里，我们将从开发者的角度来探讨SQL Server内存管理内幕。就是说，我们将讨论SQL Server使用API和操作系统功能管理内存的方式及其工作原理。通过这种方式探讨一个产品，将有助于我们理解产品开发者的思路，以及他们所设计的使用方法。理解一个产品的工作原理和它的设计用途，是掌握这个产品的关键。
我们将从一些基础的Windows内存管理基本原理介绍开始。和所有的32位Windows应用程序一样，SQL Server使用Windows内存管理功能分配、释放、管理内存资源。正如所有其它的Windows应用程序，SQL Server调用Win32内存管理API函数，与操作系统提供的内存资源进行交互。
由于SQL Server中几乎所有的内存分配都使用虚拟内存（不是内存堆），因此绝大部分内存分配代码最终都是通过调用Win32的VirtualAlloc或者是VirtualFree函数完成。SQL Server调用VirtualAlloc保留、提交分配的虚拟内存，调用VirtualFree释放虚拟内存。
Virtual Memory vs Physical Memory
在x86系列处理器上，Windows为所有进程提供一个4GB虚拟内存工作空间。用"虚拟"这个词，意思是这个内存并不是通常意义上的内存，它只是一个地址范围，并没有和物理存储单元关联在一起。当进程请求内存分配时，这些地址空间才被使用，和具体的物理存储单元关联起来。然而这些物理存储单元并不一定是物理内存，它通常可能会是磁盘空间，确切的说，是操作系统的分页文件（System Paging Files）。这就是为什么多个应用程序可以同时运行在一个128M内存的系统上，每个应用程序都有一个4GB的虚拟内存地址空间－－它不是真正的内存，但对应用程序来说可以理解为内存。Windows透明的处理paging files的数据拷贝，以使应用程序能够使用的内存可以超过机器的实际物理内存，并使应用程序能够公平的存取机器的物理内存。
这个4GB的地址空间被分成两部分：user mode部分和kernal mode部分。默认情况下，每个部分的大小为2GB，在Windows NT系列的操作系统上，可以通过BOOT.INI中的开关来改变这个默认设置（Windows NT, Windows 2000, Windows XP和Windows Server 2003属于Windows NT系列，Windows 9x和Windows ME不属于）。
图1：Windows将进程的虚拟地址空间分成user mode（应用程序）和kernal mode（操作系统）两个部分
每个应用程序拥有自己的虚拟内存地址空间，但操作系统和设备驱动程序共享同一个私有地址空间。每一个虚拟内存页（memory page）都和特定的处理器模式（processor mode）相关联，为了存取某个虚拟内存页，处理器必须工作在要求的模式下。这意味着应用程序不能直接存取kernal mode的虚拟内存，系统必须切换到kernal mode才能存取kernal mode的内存空间。
Application Memory Tuning
3GB启动选项（Windows 2000的Advanced Server和DataCenter及后续Windows版本中可用）允许改变这两个地址空间部分的默认大小。它允许将进程的user mode地址空间从2GB扩展到3GB，相应的代价是kernal mode的地址空间从2GB减小到1GB。用Windows的说法，这个功能叫做Application Memory Tuning或者是4GB Tuning（4GT）。你可以通过在BOOT.INI文件的[Operating Systems]部分添加/3GB开关启用应用Application Memory Tuning。通常情况下，人们通过设置BOOT.INI文件的[Operating Systems]部分，将系统配置为可以使用3GB或者不使用3GB启动，以使在系统启动时可以进行选择。
警告：你也可以在Windows 2000 Professional和Windows 2000 Server上使用/3GB开关，这样做的负面结果是，将kernal mode的空间减小到了1GB，但并不会增加user mode的空间。换句话说，你减小了kernal mode的空间但并没有获得任何好处。
注意：Windows XP和Windows Server 2003引入了一个新的启动选项/USERVA，和/3GB一起使用，比单独使用/3GB能够更好的控制。你在BOOT.INI中添加/3GB的时候可以同时添加/USERVA，/USERVA比单独使用/3GB的优点是它允许你指定一个准确的地址空间大小值供user mode存取。例如，/USERVA=2560为user mdoe配置2.5G的空间，剩余的1.5G用于kernal mode。上面的警告信息在使用/USERVA选项时同样适用。
Large-Address-Aware Executables
在/3GB支持加入Windows之前，应用程序无法使用指针的最高位，User mode的应用程序只能够对32位指针的前31位表示的地址空间进行存取。对于剩下的1位，一些聪明的开发者不希望浪费进程空间里的这1个位，把它用于了其它的目的，例如用于标识那些应用程序特定的地址分配类型的指针。这在引入/3GB后带来一个难题，因为这种类型的应用程序无法区分引用2GB以上内存的指针，和那些引用2GB以下内存但是最高位由于其它原因而被设置的指针。基本上，使用/3GB启动机器，会使这样的应用程序崩溃。为了解决这个问题，微软在Win32 PE文件格式（定义Windows下可执行文件Exe和Dll结构的格式）的Characteristics字段加入一个新标识位的支持，用于指示应用程序是否支持大的寻址能力。设置可执行文件头中Characteristics字段的第32位启用IMAGE_FILE_LARGE_ADDRESS_AWARE标识位。通过设置应用程序头的这个标识位，表明应用程序能够处理那些最高位被设置的指针，不会由于这个位带来任何多意性。当设置了这个标识位，在正确的Windows版本上使用/3GB选项启动，系统将为进程提供一个私有的扩展user mode地址空间。你可以使用DumpBin、ImageCfg等可以分析可执行文件头的工具，查看应用程序是否启用了这个标识位。Visual C++通过/LARGEADDRESSAWARE连接开关提供对IMAGE_FILE_LARGE_ADDRESS_AWARE的支持。SQL Server启用了这个标识位，因此当你在正确的Windows版本上使用/3GB开关启动，系统将扩展SQL Server的user mode地址空间。
注意：Windows在进程启动时检查IMAGE_FILE_LARGE_ADDRESS_AWARE标识，忽略Dll的标识。对那些最高位被设置的指针，dll代码必须能够正确处理。