Enabling AWE SQL Server 2005 64-bit

Hi All,
I'm trying to enable AWE to access more physical memory for SQL Server 2005
64-bit. I am not seeing the "Address Windowing Extensions enabled" message in
the SQL server logs when I restart services. I am following SQL documentation
to do this but am having no luck. I have done this with SQL 2000 32-bit no
worries. Are things different for 64-bit SQL 2005?
Please provide advice.
Thanks in advanced,
Cheers,
Phil
Hi Phil
AWE is not needed with 64-bit. AWE is only needed because a 32-bit address
field cannot access any memory address higher than 4GB. With 64 bits for
addressing, you can directly address all the memory on your machine.
HTH
Kalen Delaney, SQL Server MVP
www.InsideSQLServer.com
http://sqlblog.com
"philt" <philt@.discussions.microsoft.com> wrote in message
news:C97C67C8-C6EE-455E-BF13-EE139812B7E5@.microsoft.com...
> Hi All,
> I'm trying to enable AWE to access more physical memory for SQL Server
> 2005
> 64-bit. I am not seeing the "Address Windowing Extensions enabled" message
> in
> the SQL server logs when I restart services. I am following SQL
> documentation
> to do this but am having no luck. I have done this with SQL 2000 32-bit no
> worries. Are things different for 64-bit SQL 2005?
> Please provide advice.
> Thanks in advanced,
> Cheers,
> Phil
|||Thanks Kalen, that's great.
So are you saying I do nothing? eg don't enable AWE in SQL?, don't add PAE
to boot.ini don't configure min and max server memory in SQL config?
Just let SQL 2005 64bit do it's own thing?
I'm using "Windows Server 2003 standard 64bit" and "SQL Server 2005 Standard
edition 64bit".
8GB of ram on server, was wanting to reserver 6 GB for SQL.
Thanks again.
Cheers,
Phil
"Kalen Delaney" wrote:

> Hi Phil
> AWE is not needed with 64-bit. AWE is only needed because a 32-bit address
> field cannot access any memory address higher than 4GB. With 64 bits for
> addressing, you can directly address all the memory on your machine.
> --
> HTH
> Kalen Delaney, SQL Server MVP
> www.InsideSQLServer.com
> http://sqlblog.com
>
> "philt" <philt@.discussions.microsoft.com> wrote in message
> news:C97C67C8-C6EE-455E-BF13-EE139812B7E5@.microsoft.com...
>
>
|||configuring min / max is good. I'm using it on all my servers.
AWE will not offer any performance advantage.
PAE mean nothing for an x64 server.
"philt" <philt@.discussions.microsoft.com> wrote in message
news:0DA946FF-AF53-4D7A-910A-99C088997C49@.microsoft.com...[vbcol=seagreen]
> Thanks Kalen, that's great.
> So are you saying I do nothing? eg don't enable AWE in SQL?, don't add PAE
> to boot.ini don't configure min and max server memory in SQL config?
> Just let SQL 2005 64bit do it's own thing?
> I'm using "Windows Server 2003 standard 64bit" and "SQL Server 2005
> Standard
> edition 64bit".
> 8GB of ram on server, was wanting to reserver 6 GB for SQL.
> Thanks again.
> Cheers,
> Phil
> "Kalen Delaney" wrote:
|||I saw a question like this: "If we do not need AWE in x64 then why it is
still exists?"
And I saw the answer for this question which was about AWE is not just for
address extention in x86 systems and it has other purposes too however that
was too technical and I didn't understand indeed. I hope I'll manage to find
a simplified answer for this one day =)
So what would your answer be to this question Kalen?
Ekrem nsoy
"Kalen Delaney" <replies@.public_newsgroups.com> wrote in message
news:elNSnmuMIHA.4740@.TK2MSFTNGP02.phx.gbl...
> Hi Phil
> AWE is not needed with 64-bit. AWE is only needed because a 32-bit address
> field cannot access any memory address higher than 4GB. With 64 bits for
> addressing, you can directly address all the memory on your machine.
> --
> HTH
> Kalen Delaney, SQL Server MVP
> www.InsideSQLServer.com
> http://sqlblog.com
>
> "philt" <philt@.discussions.microsoft.com> wrote in message
> news:C97C67C8-C6EE-455E-BF13-EE139812B7E5@.microsoft.com...
>
|||Correct - you need to do nothing but set max/min memory. I think it is best
practice to set at least some spread between max and min. Assuming there
isn't anything else running on the box, 2GB left for the OS should be
sufficient.
Kevin G. Boles
TheSQLGuru
Indicium Resources, Inc.
"philt" <philt@.discussions.microsoft.com> wrote in message
news:0DA946FF-AF53-4D7A-910A-99C088997C49@.microsoft.com...[vbcol=seagreen]
> Thanks Kalen, that's great.
> So are you saying I do nothing? eg don't enable AWE in SQL?, don't add PAE
> to boot.ini don't configure min and max server memory in SQL config?
> Just let SQL 2005 64bit do it's own thing?
> I'm using "Windows Server 2003 standard 64bit" and "SQL Server 2005
> Standard
> edition 64bit".
> 8GB of ram on server, was wanting to reserver 6 GB for SQL.
> Thanks again.
> Cheers,
> Phil
> "Kalen Delaney" wrote:
|||Ekrem
My answer to the question "Why does AWE exist in x64" would be that MS just
didn't remove it from the metadata and the GUI because it is still needed
for 32-bit. Are there other config options or GUI properties that are
different between 32 and 64 bit? I do not have a 64-bit system to test this
out on.
The only issue with AWE that might apply here, that I am aware of, is that
with AWE enabled SQL Server will commit your max (or target) memory
immediately on startup and not wait until the system needs to use that much.
Again, I do not have a 64 bit machine, so anything I say would just be based
on things I have read.
HTH
Kalen Delaney, SQL Server MVP
www.InsideSQLServer.com
http://sqlblog.com
"Ekrem nsoy" <ekrem@.btegitim.com> wrote in message
news:B2358AFA-38B1-48E3-B8FC-64FF72EA9834@.microsoft.com...
>I saw a question like this: "If we do not need AWE in x64 then why it is
>still exists?"
> And I saw the answer for this question which was about AWE is not just for
> address extention in x86 systems and it has other purposes too however
> that was too technical and I didn't understand indeed. I hope I'll manage
> to find a simplified answer for this one day =)
> So what would your answer be to this question Kalen?
> --
> Ekrem nsoy
>
> "Kalen Delaney" <replies@.public_newsgroups.com> wrote in message
> news:elNSnmuMIHA.4740@.TK2MSFTNGP02.phx.gbl...
>
|||Hi all,
Although you can't enable AWE directly in the x64 version if you give
the service account the "lock pages in memory" advanced user right in
windows SQL Server will use AWE to access the memory. The only reason
for doing this is if you see a message like "a large portion of SQL
Server memory has been paged out" in the SQL Server error log.
Enabling this means that windows can't page out SQL Server's memory
(just like AWE on 32-bit) and is a fairly recent Microsoft best
practice but guidance has just changed over the last few days. The
best practice now is only to enable it to if you see the "paged out"
error message in the log.
Regards,
Christian Bolton - Database Architect
http://coeo.com - The SQL Server Experts
http://sqlblogcasts.com/blogs/christian
|||I found an answer to this question in the BOL. In a note, they say the
following:
- Note that the sp_configure awe enabled option is present on 64-bit SQL
Server, but it is ignored. It is subject to removal in future releases or
service packs of 64-bit SQL Server.
Link: http://msdn2.microsoft.com/en-us/library/ms187499.aspx
For reference.
Ekrem nsoy
"Ekrem nsoy" <ekrem@.btegitim.com> wrote in message
news:8AAA5BC9-3D05-406C-BBD7-59977F9E43E6@.microsoft.com...
> Hi Kalen,
> Thanks for sharing your thought with us.
> Well, the question "Why does AWE exist in x64" goes to the x64 version of
> SQL Server. As x64 version and x86 versions are different, this option
> could be removed from the x64 version' s SSMS. By the way I don't know if
> there is any difference between the x86 and x64' s SSMS' ? Or you might be
> right, SSMS is the same SSMS in all systems. If this is the situation,
> then the question is going to be kinda answered. However, if SSMSs are
> different in different architectures then I'd love to learn why AWE option
> is still there, in x64's SSMS.
> Unfortunately I don't have a x64 system either.
> --
> Ekrem nsoy
>
> "Kalen Delaney" <replies@.public_newsgroups.com> wrote in message
> news:ugAL923MIHA.1204@.TK2MSFTNGP03.phx.gbl...
>