http://sqlblog.com/blogs/argenis_fernandez/archive/2012/12/30/the-myth-around-32-bit-sql-server-instances-on-64-bit-operating-systems-and-awe.aspx(I’m taking a break from my DBA Best Practices blog series to talk about this today – the series continues after the Holidays!) I love to be proved wrong. Really, I do. Recently we had a discussion in an distribution list where somebody asked whetherenCommunityServer 2.1 SP2 (Build: 61129.1)http://sqlblog.com/blogs/argenis_fernandez/archive/2012/12/30/the-myth-around-32-bit-sql-server-instances-on-64-bit-operating-systems-and-awe.aspx#46893Sun, 30 Dec 2012 23:56:07 GMT21093a07-8b3d-42db-8cbf-3350fcbf5496:46893Greg Low<p>Great (and clear) post Argenis. Thanks for sharing it.</p>http://sqlblog.com/blogs/argenis_fernandez/archive/2012/12/30/the-myth-around-32-bit-sql-server-instances-on-64-bit-operating-systems-and-awe.aspx#46894Mon, 31 Dec 2012 00:00:37 GMT21093a07-8b3d-42db-8cbf-3350fcbf5496:46894Ian Yates<p>You're right about the bad documentation - a lot of bloggers don't consider x86 SQL Server on x64 Windows and neither does much of the Microsoft documentation. </p> <p>We have been taking advantage of this for a couple of years on several customer sites because we need to integrate SQL with some legacy DBs via linked servers that only have 32 bit drivers. Enabling AWE at least lets us take advantage some of that RAM. Unfortunately other issues still exist such as bad backup utilities and DB drivers depleting the &quot;memtoleave&quot; area put aside for their operation in the x86 address space. </p> <p>Great post 😊</p> http://sqlblog.com/blogs/argenis_fernandez/archive/2012/12/30/the-myth-around-32-bit-sql-server-instances-on-64-bit-operating-systems-and-awe.aspx#46899Mon, 31 Dec 2012 06:15:52 GMT21093a07-8b3d-42db-8cbf-3350fcbf5496:46899Greg Linwood<p>Nice post Argenis &amp; Happy New Year to you too.</p> <p>I like the way you posted the remaining columns in the dm_os_process_memory output as they reveal a few other interesting points. </p> <p>Note that the process still has a Virtual Address Space even when using AWE? This is because only a couple of memory managers use AWE in SQL 2008 whilst many of the others use regular Virtual Memory. This is something that has changed in SQL 2012 so it would be interesting to see the same output from SQL 2012 vs SQL 2008. </p> <p>Also, there is more physical memory in use than locked allocations. &quot;In use&quot; isn't exactly the same as &quot;allocated&quot; but the difference between these two is roughly what physical memory has been allocated to back the virtual memory. The relationship between all of these can also be influenced by other settings such as -g startup switch, which is also something you need to consider when using AWE under x86 SQL systems..</p> http://sqlblog.com/blogs/argenis_fernandez/archive/2012/12/30/the-myth-around-32-bit-sql-server-instances-on-64-bit-operating-systems-and-awe.aspx#46967Wed, 02 Jan 2013 15:26:08 GMT21093a07-8b3d-42db-8cbf-3350fcbf5496:46967Joseph<p>Nice article, Argenis!</p>