在我们虚拟化系列文章的数据库测试中，我们看到了数据库的测试过程会用到大量的内存，这很容易达到32bit Windows的一处限制：进程内存被限制为2GB，而通常服务器里面4GB或更多的内存很是常见，这么多内存是怎么应用的呢？它们怎么在数据库应用方面发挥力量呢？我们下面的测试可以解答相关的一系列问题。

SQL Server 2005是一个流行的关系数据库系统

程序只能使用2GB内存的这个限制是32位操作系统架构引起的。传统意义上的32bit操作系统使用32bit的内存地址，这样寻址范围就已经被限制为4GB——4G也就是2的32次方，然而通常操作系统的设计上为了安全性的考虑，应用程序和内核所处的内存地址空间是互相独立的，也就是说，应用程序和内核各自能访问2GB的内存空间。虽然不同的操作系统实现具有不同的值，不过多数现在的操作系统在这一点上都很一致。

为了让程序突破2GB寻址的限制，近代Windows NT核心提供了一个变通的方案：4GB内存调整优化技术，通过这个技术，可以将用户模式的寻址空间扩大至3GB，这样核心寻址空间便被限制为1GB了，需要超大内存容量的应用程序可以从这个特性中获得性能改善，如SQL Server数据库这种类型。要使用这个4GB内存优化技术，用户需要在Windows Server操作系统的启动参数中加入/3GB开关。这个特性同时需要操作系统打开DEP（数据执行保护，其实/3GB开关需要的是PAE的支持）。

AWE可以让32位操作系统下的进程提供64GB的地址空间

然而让用户模式程序能多寻址1GB毕竟还算是治标不治本，于是Microsoft还在自己的操作系统提供了一个比较重要的特性：AWE（Address Windowing Extension，地址窗口扩展） API集，这个API集的原理其实是基于这样的一个事实：所有的支持PAE的操作系统都有能让IA32处理器直接寻址64GB物理地址的API，回想前面的内容，物理地址是CPU处理的地址，而每个程序私有的2GB内存地址被称为虚地址范围。

每个支持PAE的操作系统都具有这种API，差别只是在于这些API能否提供如内存共享、进程间通讯、分页等等这些功能，微软在Windows上提供了一个简单明了的API组——也就是AWE地址窗口扩展API组，它仅仅由5个API调用组成，包括了核心级和用户级调用，使用AWE分配得到的内存是非分页、锁定的，其他程序无法访问，也无法交换到页面文件（虚拟内存）上去，对性能具有很大的提升。

通过使用AWE API，核心模式/用户模式可以轻易地突破2GB容量的限制，最高可以达到64GB，如SQL Server就使用了这个AWE API（可设定），从而提高对大容量内存的能力，大大提升了应用软件/系统的性能。

64bit系统中不存在这个问题，实际上，64bit系统不需要PAE的支持，也不支持AWE API，用户模式和核心模式的程序都可以直接访问非常大容量（8TB）的内存空间，可惜的是，32bit平台上遗留的大量资源，让64bit应用迄今尚未开始流行。

数据库技术是作为数据处理的一门技术而发展起来的，所研究的问题就是如何科学地组织和存储数据，如何高效地获取和处理数据。在数据库中用数据模型来抽象、表示和处理现实世界中的数据。数据库即是模拟现实世界中某应用环境（一个企业、单位或部门）所涉及的数据的集合，它不仅要反映数据本身的内容，而且要反映数据之间的联系。大部分的服务器应用都同数据库有着密切的联系。

我们采用了一组60台客户端的千兆网络环境进行了数据库测试，由于客户端所有的资源都用来产生数据库操作，因此可以给服务器施加相当大的测试压力。

Benchmark Factory 运行报告

Benchmarkfactory 4.6

我们选择了Benchmark Factory 4.6软件和Microsoft SQL2005 Enterprise来测试不同的硬件平台在数据库应用中的表现。

我们选择了BF内置的标准测试脚本AS3AP，这项测试可用于对于ANSI结构化查询语言（SQL）关系型数据库进行测试，它可用于测试DBMS（单用户微机数据库管理系统），也可用于测试高性能并行或者分布式数据库。关系性数据库就是用二维表格结构来表示实体及实体之间联系模型的数据库形式。 (责任编辑：admin)