AWE Memory

By : Brad McGehee Apr 28, 2006

If you are using SQL Server 2000 Standard Edition under Windows NT 4.0, Windows 2000 (any version), or Windows 2003 (any version), or are running SQL Server 2000 Enterprise Edition under the Standard Edition Windows NT 4.0, Windows 2000, or Windows 2003, or if your server has 4GB or less of RAM, the "awe enabled" option should always be left to the default value of 0, which means that AWE memory is not being used. The AWE (Advanced Windowing Extensions) API allows applications (that are written to use the AWE API) to run under Windows 2000 Advanced Server or Windows 2000 Datacenter Server (or Windows 2003 Enterprise and Datacenter Editions) to access more than 4GB of RAM. SQL Server 2000 and SQL Server 2005 Enterprise Edition (not SQL Server 2000 or 2005 Standard Edition) are AWE-enabled and can take advantage of RAM in a server of 4GB or more. If the operating system is Windows 2000 Advanced Server, SQL Server 2000 Enterprise Edition can us up to 8GB of RAM. If the operating system is Windows 2000 Datacenter Server, SQL Server 2000 Enterprise can use up to 64GB of RAM. SQL Server 2005 Enterprise Edition supports AWE memory, allowing the use of physical memory over 4 gigabytes (GB) on 32-bit versions of Microsoft Windows operating systems. Up to 64 GB of physical memory is supported. In order for the operating system and SQL Server 2000 or SQL Server 2005 Enterprise Edition to take advantage of the additional RAM, two steps must be completed. Exactly how you configure AWE memory support depends on how much RAM your server has. To configure Windows 2000 or 2003, you must enter one of the following switches in the boot line of the boot.ini file, and reboot the server:

4GB RAM: /3GB (AWE support is not used) 8GB RAM: /3GB /PAE 16GB RAM: /3GB /PAE 16GB + RAM: /PAE

The /3GB switch is used to tell SQL Server to take advantage of 3GB out of the base 4GB of RAM that Windows 2000 supports natively. If you don't specify this option, then SQL Server will only take advantage of 2GB of the first 4GB of RAM in the server, essentially wasting 1GB of RAM. AWE memory technology is used only for the RAM that exceeds the base 4GB of RAM, that's why the /3GB switch is needed to use as much of the RAM in your server as possible. If your server has 16GB or less of RAM, then using the /3GB switch is important. But if your server has more than 16GB of RAM, then you must not use the /3GB switch. The reason for this is because the 1GB of additional RAM provided by adding the /3GB switch is needed by the operating system in order to take advantage of all of the extra AWE memory. In other words, the operating system needs 2GB of RAM itself to mange the AWE memory if your server has more than 16GB of RAM. If 16GB or less of RAM is in a server, then the operating system only needs 1GB of RAM, allowing the other 1GB of RAM for use by SQL Server. Once this step is done, the next step is to set the "awe enabled" option to 1 within SQL Server 2000 or 2005 Enterprise Edition, and then restart the SQL Server service. Only at this point will SQL Server be able to use the additional RAM in the server. One caution about using the "awe enabled" setting is that after turning it on, SQL Server no longer dynamically manages memory. Instead, it takes all of the available RAM (except about 128MB which is left for the operating system). If you want to prevent SQL Server from taking all of the RAM, you must set the "max server memory" option (described in more detail later in this article) to a figure that limits SQL Server to the amount or RAM you specify. (7.0, 2000, 2005) Updated 1-2-2004

***** If you find that you are running into a memory bottleneck, and assuming you have the money to spend, SQL Server 2000 and SQL Server 2005 Enterprise Edition can support up to 64GB of RAM. How much RAM SQL Server 2000 or SQL Server 2005 Enterprise Edition can use depends on which version of Windows 2000 or Windows 2003 you are using and how much RAM your server can support. Assuming your server can handle it, SQL Server 2000 Enterprise Edition supports up to 8GB under Windows Advanced Server 2000 and Windows 2003 Enterprise, and up to 64GB under Windows Data Center for both Windows 2000 and Windows 2003. Normally, 32-bit CPUs, such as the Pentium family of processors, can only support up to 4GB of RAM because of its limited address space. To get around this limitation, SQL Server 2000 and SQL Server 2005 Enterprise Edition supports a feature called AWE (Address Windowing Extensions) that allows up to 64GB of RAM to be addressed. Assuming you configure the appropriate hardware and software, AWE support is not turned automatically on, you have to do this step manually. To turn AWE support on, you must change the "awe enabled" advanced SQL Server 2000 or 2005 option from 0 to 1. For example, to turn on AWE support: SP_CONFIGURE 'show advanced options', 1 RECONFIGURE GO SP_CONFIGURE 'awe enabled', 1 RECONFIGURE GO AWE memory cannot be dynamically managed, like memory is normally managed in SQL Server. This means that SQL Server will automatically grab all the RAM it can when it starts (except for about 128MB, which is reserved for the operating system), but it will not release any of this RAM until SQL Server is turned off. If your server is a dedicated SQL Server, then this might be OK. But if you are running other software on the server, or are running multiple instances of SQL Server, then you must specify the maximum amount of RAM that

SQL Server can grab when it is started. This can be done using the "max server memory" configuration option. If you change this setting, you will have to stop and start the mssqlserver service in order for the new setting to take affect. To set the maximum amount of memory that AWE memory can access, you can use SQL Server's "max server memory" configuration option. For example: SP_CONFIGURE 'max server memory', 4096 RECONFIGURE GO In the above example, we are telling SQL Server to only use 4GB of RAM, leaving any other RAM available in the server free for other applications. While multiple instances of SQL Server can be used with AWE memory, you probably won't want to, as it can be a headache to manage. In fact, running multiple instances of SQL Server in AWE memory defeats the purpose of more RAM in the first place. Generally, your goal of using AWE memory should be to support a single, very large instance of SQL Server, not lots of smaller instances running on a single server. Assuming you have the budget, adding large amounts of RAM to your server can greatly speed up many databases. [7.0, 2000, 2005] Updated 1-2-2004 Microsoft considers AWE a premium feature, and because of this, it is not offered in all versions of Windows 2000 and SQL Server 2000. Below is a chart showing the various versions of Windows 2000 and SQL Server 2000 that support AWE memory. SQL Server 2000 Windows Version Windows 2000 Datacenter Server 64GB 2GB 2GB 64GB Enterprise Edition SQL Server 2000 Standard Edition SQL Server 2000 Personal Edition SQL Server 2000 Developer's Edition

Windows 2000 Advanced Server Windows 2000 Server Windows 2000 Professional 4GB 2GB 2GB 4GB 8GB 2GB 2GB 8GB

N.A.

N.A.

2GB

2GB

Any combination above of 4GB or more is supported via AWE memory. So if you want to take advantage of AWE memory, you have no choice to purchase Microsoft's premiumpriced software. [2000] ***** If you use AWE memory, you can track its performance characteristics using some special Performance Monitor counters found under the SQL Server Buffer Manager object. They include: AWE Lookup Maps/Sec: This counter measures how many times that a specific database page was requested by SQL Server, was found in the buffer pool, and then was mapped as AWE memory (or the server's virtual address space). This would be a combination of the AWE Stolen Maps/Sec and AWE Write Maps/Sec described later. AWE Stolen Maps/Sec: This counter measures how many times that a free database buffer was taken by SQL Server and mapped as AWE memory. AWE Write Maps/Sec: When SQL Server runs out of free buffers to map to AWE memory, it has to write to a dirty buffer instead, which hurts performance because a disk write has to occur to clean up the dirty buffer before it can be used. This counter measures the number of times that SQL Server has to map a dirty buffer. If this figure is high, more memory should be considered.

AWE Unmap Call/Sec: Sometimes SQL Server will unmap buffers from AWE memory (because they have not been used lately). This counter measures how many times SQL Server calls for an unmap operation, which can affect one or more buffers at the same time.

AWE Unmap Pages/Sec: Closely related to the above counter, this counter specifically measures the number of SQL Server buffers that are unmapped.