SQL Clone
SQLServerCentral is supported by Redgate
Log in  ::  Register  ::  Not logged in



Marios Philippopoulos
Marios Philippopoulos
SSCarpal Tunnel
SSCarpal Tunnel (4.7K reputation)SSCarpal Tunnel (4.7K reputation)SSCarpal Tunnel (4.7K reputation)SSCarpal Tunnel (4.7K reputation)SSCarpal Tunnel (4.7K reputation)SSCarpal Tunnel (4.7K reputation)SSCarpal Tunnel (4.7K reputation)SSCarpal Tunnel (4.7K reputation)

Group: General Forum Members
Points: 4730 Visits: 3758
Wilfred van Dijk (5/28/2008)
If you don't enable AWE on a 64bit server you can get errors like "A significant part of sql server process memory has been paged out. This may result in performance degradation". for example, this can happen if you copy a lage filebackup to another server.
As a result, al your SQL processes are suspending, but I would say dying (I've had that experience) Blush

Read the following articles:


I see your point.

What percentage of physical memory should be apportioned to AWE use then?
AWE benefits only the buffer cache, and we would need to ensure other operations, such as sorts, indexing, plan caching, the SQL CLR etc., have adequate memory.

Also, there are some performance concerns regarding AWE in this link:


Although AWE makes execution of memory-intensive applications possible when otherwise impossible, AWE imposes overhead, adds initialization time, and can face performance challenges under various processing conditions. These issues are eliminated on the 64-bit platform when directly addressing memory.
AWE does not increase Virtual Address Space
A 32-bit system limits the virtual address space (the address space used by Windows to manage memory allocations) to 2 GB. Since AWE does not eliminate this virtual address space (VAS) limitation, many users try to raise the ceiling for this 32-bit limitation of only 2 GB of VAS by using the /3GB switch in the boot.ini file. This increases the VAS to 3 GB, thereby leaving only 1 GB for the operating system. This results in the reduction of the addressable physical memory of a single instance of Windows Server 2003 Enterprise and Datacenter editions to 16 GB. When not using the /3GB switch on Windows Server 2003 Enterprise Edition, the maximum memory addressable is 32 GB. For the Datacenter edition, it is 64 GB. This is because Windows requires more than 1 GB of VAS to manage more than 16 GB of total physical memory in one instance. So, using the switch may impose an artificial ceiling, thereby diminishing the capacity of your hardware and operating system.

For all practical purposes, the use of AWE in a 32-bit environment is only for data caching. This is because data pages use relative addressing (a requirement for AWE usage), while other components do not. Consequently, other components, operating within a relatively small VAS of either 2 or 3 GB could be significantly blocked in larger systems that have complex workloads or many concurrent users even when running on high end servers with abundant memory.

For example, the plan cache (cache of query plans) in SQL Server 2005 resides in the VAS. In cases of VAS memory pressure, query plans and execution contexts with costs of zero (0) are deleted from the plan cache. In high transaction environments, this could lead to poor performance due to the time and CPU resources that are needed to compile the query plans again. Conversely, on 64-bit systems, VAS is, for all practical purposes, unlimited. The result is faster performance because no additional time is taken up re-creating a query plan. This results in less CPU loading since the CPU is not working to compile a new plan as frequently. Such incidences can occur even on servers with large amounts of memory (such as 8 GB or more) because the plan cache (and other components except data pages) cannot take advantage of AWE memory.

Another example of the limitations of AWE concerns support in SQL Server 2005 for the common language runtime (CLR). Although the CLR uses some memory allocations from the buffer pool (single-page allocator) where AWE is most useful, most SQL Operating System (SQLOS) memory allocations (multipage allocator) on behalf of the CLR are from the VAS. For customers who are considering more than moderate use of the CLR within SQL Server 2005, an additional reason to adopt 64-bit would be to prevent loss of performance from VAS memory pressure.

SQL Server 2016 Columnstore Index Enhancements - System Views for Disk-Based Tables
Persisting SQL Server Index-Usage Statistics with MERGE
Turbocharge Your Database Maintenance With Service Broker: Part 2
Valued Member
Valued Member (73 reputation)Valued Member (73 reputation)Valued Member (73 reputation)Valued Member (73 reputation)Valued Member (73 reputation)Valued Member (73 reputation)Valued Member (73 reputation)Valued Member (73 reputation)

Group: General Forum Members
Points: 73 Visits: 113
Hi Everybody, eve ni have same issues with 32 Bit & 64 Bit Server. I'll come up clearly with issues in a day or two.


You can't post new topics.
You can't post topic replies.
You can't post new polls.
You can't post replies to polls.
You can't edit your own topics.
You can't delete your own topics.
You can't edit other topics.
You can't delete other topics.
You can't edit your own posts.
You can't edit other posts.
You can't delete your own posts.
You can't delete other posts.
You can't post events.
You can't edit your own events.
You can't edit other events.
You can't delete your own events.
You can't delete other events.
You can't send private messages.
You can't send emails.
You can read topics.
You can't vote in polls.
You can't upload attachments.
You can download attachments.
You can't post HTML code.
You can't edit HTML code.
You can't post IFCode.
You can't post JavaScript.
You can post emoticons.
You can't post or upload images.

Select a forum