Showing posts with label ghz. Show all posts
Showing posts with label ghz. Show all posts

Thursday, March 8, 2012

AWE Question

What would be the optimal max server memory setting for the following
machine?
Dedicated SQL Server:
Intel Xeon MP 3.3 GHz (4 physical Processors)
136 GB (C Drive)
8.0 GB RAM
Microsoft Windows 2003 Enterprise Edition Service Pack 1 Build 3790
SQL Server Enterprise 2000, with SP3
The machine has following database sizes. All databases are being accessed
all the time by around 300+ concurrent users.
DB#1 - 536.44 MB
DB#2 - 1.09 GB
DB#3 - 3.27 GB
DB#4 - 4.92 GB
DB#5 - 5.29 GB
DB#6 - 15.09 GB
DB#7 - 50.13 GB
I am still learning the ins and outs of configuring higher end db servers.
Are there any other non-default server settings that I should change?"Isaac Alexander" <isaacNOSPAM@.goNOSPAMprocura.com> wrote in message
news:uqJkBN9uGHA.4756@.TK2MSFTNGP04.phx.gbl...
> What would be the optimal max server memory setting for the following
> machine?
> Dedicated SQL Server:
> Intel Xeon MP 3.3 GHz (4 physical Processors)
> 136 GB (C Drive)
> 8.0 GB RAM
> Microsoft Windows 2003 Enterprise Edition Service Pack 1 Build 3790
> SQL Server Enterprise 2000, with SP3
> The machine has following database sizes. All databases are being accessed
> all the time by around 300+ concurrent users.
> DB#1 - 536.44 MB
> DB#2 - 1.09 GB
> DB#3 - 3.27 GB
> DB#4 - 4.92 GB
> DB#5 - 5.29 GB
> DB#6 - 15.09 GB
> DB#7 - 50.13 GB
> I am still learning the ins and outs of configuring higher end db servers.
>
Does each user access all databases or does each database have its own set
of users?
If the different databsaes represent seperate applications, you should
consider dividing the server into multiple SQL instances to divide up the
memory on the box and optionally the CPU's into 2 or 3 different resource
pools. 32bit SQL Server works more efficiently when it doesn't have to use
AWE to access memory, and multiple instances allow you to easilly partition
memory and CPU resources between the workloads.
David|||>
> Does each user access all databases or does each database have its own set
> of users?
All databases are the same application (different clients on each db similar
to an ASP service).
Each user usually accesses only a single database. Admin users would need
access to all.

> If the different databsaes represent seperate applications, you should
> consider dividing the server into multiple SQL instances to divide up the
> memory on the box and optionally the CPU's into 2 or 3 different resource
> pools. 32bit SQL Server works more efficiently when it doesn't have to
> use AWE to access memory, and multiple instances allow you to easilly
> partition memory and CPU resources between the workloads.
>
Interesting option. Your making me think about that.
You mention that 32bit SQL Server works more efficiently when it doesn't use
AWE. Does it affect performance that much?
My concern is the 50 GB database itself would benefit from more then 2 GB of
RAM.
You also mention that you can configure CPUs into different resource pools.
How does this work? Do you have a knowledge base link?|||"Isaac Alexander" <isaacNOSPAM@.goNOSPAMprocura.com> wrote in message
news:%23MUPzp9uGHA.4160@.TK2MSFTNGP06.phx.gbl...
> All databases are the same application (different clients on each db
> similar to an ASP service).
> Each user usually accesses only a single database. Admin users would need
> access to all.
>
> Interesting option. Your making me think about that.
> You mention that 32bit SQL Server works more efficiently when it doesn't
> use AWE. Does it affect performance that much?
> My concern is the 50 GB database itself would benefit from more then 2 GB
> of RAM.
Yes it would, but you have 7 databses and only 8G of ram. How much ram can
you afford to allocate for that one workload. And using the /3GB switch you
can give a SQL instance access to 3GB of memory without using AWE.
Also you will have one procedure cache per instance, and on 32bit SQL is
strictly limited in size. Multiple instances would have multiple procedure
caches.
"On 32-bit platforms configured with 4 GB or more of physical memory, you
can either use Address Windowing Extensions (AWE) or use multiple instances
of SQL Server as a way to fully utilize the large amount of physical memory.
AWE may work well for some scenarios; however, you should be aware that AWE
memory can only be used for data cache. The memory for procedure cache,
connections, locks, and other internal resources of SQL Server must come
from the 2 GB (or 3GB, depending on the settings used) portion of the
virtual memory. On systems needing to support a large number of databases
and user connections, multiple instances of SQL Server may be a better
approach to fully alleviate the 2 GB or 3GB memory constraint imposed by the
32-bit platform for these data structures."
http://www.microsoft.com/technet/pr...on.ms
px

> You also mention that you can configure CPUs into different resource
> pools. How does this work? Do you have a knowledge base link?
>
Simple partition of CPU's to SQL Instances should be done with the "affinity
mask" server option.
SQL Server 2005 Books Online
affinity mask Option
http://msdn2.microsoft.com/en-us/library/ms187104.aspx
Dynamic CPU allocation policies can be implemented with WSRM:
Windows System Resource Manager
http://www.microsoft.com/technet/do...nsrvr/wsrm.mspx
David|||"David Browne" <davidbaxterbrowne no potted meat@.hotmail.com> wrote in
message news:O$v%232B%23uGHA.3428@.TK2MSFTNGP02.phx.gbl...
> "Isaac Alexander" <isaacNOSPAM@.goNOSPAMprocura.com> wrote in message
> news:%23MUPzp9uGHA.4160@.TK2MSFTNGP06.phx.gbl...
> Yes it would, but you have 7 databses and only 8G of ram. How much ram
> can you afford to allocate for that one workload. And using the /3GB
> switch you can give a SQL instance access to 3GB of memory without using
> AWE.
> Also you will have one procedure cache per instance, and on 32bit SQL is
> strictly limited in size. Multiple instances would have multiple
> procedure caches.
> "On 32-bit platforms configured with 4 GB or more of physical memory, you
> can either use Address Windowing Extensions (AWE) or use multiple
> instances of SQL Server as a way to fully utilize the large amount of
> physical memory. AWE may work well for some scenarios; however, you should
> be aware that AWE memory can only be used for data cache. The memory for
> procedure cache, connections, locks, and other internal resources of SQL
> Server must come from the 2 GB (or 3GB, depending on the settings used)
> portion of the virtual memory. On systems needing to support a large
> number of databases and user connections, multiple instances of SQL Server
> may be a better approach to fully alleviate the 2 GB or 3GB memory
> constraint imposed by the 32-bit platform for these data structures."
> http://www.microsoft.com/technet/pr...on.
mspx
>
> Simple partition of CPU's to SQL Instances should be done with the
> "affinity mask" server option.
> SQL Server 2005 Books Online
> affinity mask Option
> http://msdn2.microsoft.com/en-us/library/ms187104.aspx
>
> Dynamic CPU allocation policies can be implemented with WSRM:
> Windows System Resource Manager
> http://www.microsoft.com/technet/do...nsrvr/wsrm.mspx
> David
>
Thanks David. This info is very helpful.|||Isaac
> Dedicated SQL Server:
> Intel Xeon MP 3.3 GHz (4 physical Processors)
> 136 GB (C Drive)
> 8.0 GB RAM
I'd consider (based on your description) MAX Memory 7GB
"Isaac Alexander" <isaacNOSPAM@.goNOSPAMprocura.com> wrote in message
news:%23$AxxK%23uGHA.4752@.TK2MSFTNGP02.phx.gbl...
> "David Browne" <davidbaxterbrowne no potted meat@.hotmail.com> wrote in
> message news:O$v%232B%23uGHA.3428@.TK2MSFTNGP02.phx.gbl...
> Thanks David. This info is very helpful.
>|||"Uri Dimant" <urid@.iscar.co.il> wrote in message
news:uYF1sPEvGHA.724@.TK2MSFTNGP05.phx.gbl...
> Isaac
>
> I'd consider (based on your description) MAX Memory 7GB
>
Thanks Uri.

AWE Question

What would be the optimal max server memory setting for the following
machine?
Dedicated SQL Server:
Intel Xeon MP 3.3 GHz (4 physical Processors)
136 GB (C Drive)
8.0 GB RAM
Microsoft Windows 2003 Enterprise Edition Service Pack 1 Build 3790
SQL Server Enterprise 2000, with SP3
The machine has following database sizes. All databases are being accessed
all the time by around 300+ concurrent users.
DB#1 - 536.44 MB
DB#2 - 1.09 GB
DB#3 - 3.27 GB
DB#4 - 4.92 GB
DB#5 - 5.29 GB
DB#6 - 15.09 GB
DB#7 - 50.13 GB
I am still learning the ins and outs of configuring higher end db servers.
Are there any other non-default server settings that I should change?"Isaac Alexander" <isaacNOSPAM@.goNOSPAMprocura.com> wrote in message
news:uqJkBN9uGHA.4756@.TK2MSFTNGP04.phx.gbl...
> What would be the optimal max server memory setting for the following
> machine?
> Dedicated SQL Server:
> Intel Xeon MP 3.3 GHz (4 physical Processors)
> 136 GB (C Drive)
> 8.0 GB RAM
> Microsoft Windows 2003 Enterprise Edition Service Pack 1 Build 3790
> SQL Server Enterprise 2000, with SP3
> The machine has following database sizes. All databases are being accessed
> all the time by around 300+ concurrent users.
> DB#1 - 536.44 MB
> DB#2 - 1.09 GB
> DB#3 - 3.27 GB
> DB#4 - 4.92 GB
> DB#5 - 5.29 GB
> DB#6 - 15.09 GB
> DB#7 - 50.13 GB
> I am still learning the ins and outs of configuring higher end db servers.
>
Does each user access all databases or does each database have its own set
of users?
If the different databsaes represent seperate applications, you should
consider dividing the server into multiple SQL instances to divide up the
memory on the box and optionally the CPU's into 2 or 3 different resource
pools. 32bit SQL Server works more efficiently when it doesn't have to use
AWE to access memory, and multiple instances allow you to easilly partition
memory and CPU resources between the workloads.
David|||>
> Does each user access all databases or does each database have its own set
> of users?
All databases are the same application (different clients on each db similar
to an ASP service).
Each user usually accesses only a single database. Admin users would need
access to all.
> If the different databsaes represent seperate applications, you should
> consider dividing the server into multiple SQL instances to divide up the
> memory on the box and optionally the CPU's into 2 or 3 different resource
> pools. 32bit SQL Server works more efficiently when it doesn't have to
> use AWE to access memory, and multiple instances allow you to easilly
> partition memory and CPU resources between the workloads.
>
Interesting option. Your making me think about that.
You mention that 32bit SQL Server works more efficiently when it doesn't use
AWE. Does it affect performance that much?
My concern is the 50 GB database itself would benefit from more then 2 GB of
RAM.
You also mention that you can configure CPUs into different resource pools.
How does this work? Do you have a knowledge base link?|||"Isaac Alexander" <isaacNOSPAM@.goNOSPAMprocura.com> wrote in message
news:%23MUPzp9uGHA.4160@.TK2MSFTNGP06.phx.gbl...
> >
>> Does each user access all databases or does each database have its own
>> set of users?
> All databases are the same application (different clients on each db
> similar to an ASP service).
> Each user usually accesses only a single database. Admin users would need
> access to all.
>> If the different databsaes represent seperate applications, you should
>> consider dividing the server into multiple SQL instances to divide up the
>> memory on the box and optionally the CPU's into 2 or 3 different resource
>> pools. 32bit SQL Server works more efficiently when it doesn't have to
>> use AWE to access memory, and multiple instances allow you to easilly
>> partition memory and CPU resources between the workloads.
> Interesting option. Your making me think about that.
> You mention that 32bit SQL Server works more efficiently when it doesn't
> use AWE. Does it affect performance that much?
> My concern is the 50 GB database itself would benefit from more then 2 GB
> of RAM.
Yes it would, but you have 7 databses and only 8G of ram. How much ram can
you afford to allocate for that one workload. And using the /3GB switch you
can give a SQL instance access to 3GB of memory without using AWE.
Also you will have one procedure cache per instance, and on 32bit SQL is
strictly limited in size. Multiple instances would have multiple procedure
caches.
"On 32-bit platforms configured with 4 GB or more of physical memory, you
can either use Address Windowing Extensions (AWE) or use multiple instances
of SQL Server as a way to fully utilize the large amount of physical memory.
AWE may work well for some scenarios; however, you should be aware that AWE
memory can only be used for data cache. The memory for procedure cache,
connections, locks, and other internal resources of SQL Server must come
from the 2 GB (or 3GB, depending on the settings used) portion of the
virtual memory. On systems needing to support a large number of databases
and user connections, multiple instances of SQL Server may be a better
approach to fully alleviate the 2 GB or 3GB memory constraint imposed by the
32-bit platform for these data structures."
http://www.microsoft.com/technet/prodtechnol/sql/2000/deploy/32bitconsolidation.mspx
> You also mention that you can configure CPUs into different resource
> pools. How does this work? Do you have a knowledge base link?
>
Simple partition of CPU's to SQL Instances should be done with the "affinity
mask" server option.
SQL Server 2005 Books Online
affinity mask Option
http://msdn2.microsoft.com/en-us/library/ms187104.aspx
Dynamic CPU allocation policies can be implemented with WSRM:
Windows System Resource Manager
http://www.microsoft.com/technet/downloads/winsrvr/wsrm.mspx
David|||"David Browne" <davidbaxterbrowne no potted meat@.hotmail.com> wrote in
message news:O$v%232B%23uGHA.3428@.TK2MSFTNGP02.phx.gbl...
> "Isaac Alexander" <isaacNOSPAM@.goNOSPAMprocura.com> wrote in message
> news:%23MUPzp9uGHA.4160@.TK2MSFTNGP06.phx.gbl...
>> >
>> Does each user access all databases or does each database have its own
>> set of users?
>> All databases are the same application (different clients on each db
>> similar to an ASP service).
>> Each user usually accesses only a single database. Admin users would need
>> access to all.
>>
>> If the different databsaes represent seperate applications, you should
>> consider dividing the server into multiple SQL instances to divide up
>> the memory on the box and optionally the CPU's into 2 or 3 different
>> resource pools. 32bit SQL Server works more efficiently when it doesn't
>> have to use AWE to access memory, and multiple instances allow you to
>> easilly partition memory and CPU resources between the workloads.
>>
>> Interesting option. Your making me think about that.
>> You mention that 32bit SQL Server works more efficiently when it doesn't
>> use AWE. Does it affect performance that much?
>> My concern is the 50 GB database itself would benefit from more then 2 GB
>> of RAM.
> Yes it would, but you have 7 databses and only 8G of ram. How much ram
> can you afford to allocate for that one workload. And using the /3GB
> switch you can give a SQL instance access to 3GB of memory without using
> AWE.
> Also you will have one procedure cache per instance, and on 32bit SQL is
> strictly limited in size. Multiple instances would have multiple
> procedure caches.
> "On 32-bit platforms configured with 4 GB or more of physical memory, you
> can either use Address Windowing Extensions (AWE) or use multiple
> instances of SQL Server as a way to fully utilize the large amount of
> physical memory. AWE may work well for some scenarios; however, you should
> be aware that AWE memory can only be used for data cache. The memory for
> procedure cache, connections, locks, and other internal resources of SQL
> Server must come from the 2 GB (or 3GB, depending on the settings used)
> portion of the virtual memory. On systems needing to support a large
> number of databases and user connections, multiple instances of SQL Server
> may be a better approach to fully alleviate the 2 GB or 3GB memory
> constraint imposed by the 32-bit platform for these data structures."
> http://www.microsoft.com/technet/prodtechnol/sql/2000/deploy/32bitconsolidation.mspx
>> You also mention that you can configure CPUs into different resource
>> pools. How does this work? Do you have a knowledge base link?
> Simple partition of CPU's to SQL Instances should be done with the
> "affinity mask" server option.
> SQL Server 2005 Books Online
> affinity mask Option
> http://msdn2.microsoft.com/en-us/library/ms187104.aspx
>
> Dynamic CPU allocation policies can be implemented with WSRM:
> Windows System Resource Manager
> http://www.microsoft.com/technet/downloads/winsrvr/wsrm.mspx
> David
>
Thanks David. This info is very helpful.|||Isaac
> Dedicated SQL Server:
> Intel Xeon MP 3.3 GHz (4 physical Processors)
> 136 GB (C Drive)
> 8.0 GB RAM
I'd consider (based on your description) MAX Memory 7GB
"Isaac Alexander" <isaacNOSPAM@.goNOSPAMprocura.com> wrote in message
news:%23$AxxK%23uGHA.4752@.TK2MSFTNGP02.phx.gbl...
> "David Browne" <davidbaxterbrowne no potted meat@.hotmail.com> wrote in
> message news:O$v%232B%23uGHA.3428@.TK2MSFTNGP02.phx.gbl...
>> "Isaac Alexander" <isaacNOSPAM@.goNOSPAMprocura.com> wrote in message
>> news:%23MUPzp9uGHA.4160@.TK2MSFTNGP06.phx.gbl...
>> >
>> Does each user access all databases or does each database have its own
>> set of users?
>> All databases are the same application (different clients on each db
>> similar to an ASP service).
>> Each user usually accesses only a single database. Admin users would
>> need access to all.
>>
>> If the different databsaes represent seperate applications, you should
>> consider dividing the server into multiple SQL instances to divide up
>> the memory on the box and optionally the CPU's into 2 or 3 different
>> resource pools. 32bit SQL Server works more efficiently when it
>> doesn't have to use AWE to access memory, and multiple instances allow
>> you to easilly partition memory and CPU resources between the
>> workloads.
>>
>> Interesting option. Your making me think about that.
>> You mention that 32bit SQL Server works more efficiently when it doesn't
>> use AWE. Does it affect performance that much?
>> My concern is the 50 GB database itself would benefit from more then 2
>> GB of RAM.
>> Yes it would, but you have 7 databses and only 8G of ram. How much ram
>> can you afford to allocate for that one workload. And using the /3GB
>> switch you can give a SQL instance access to 3GB of memory without using
>> AWE.
>> Also you will have one procedure cache per instance, and on 32bit SQL is
>> strictly limited in size. Multiple instances would have multiple
>> procedure caches.
>> "On 32-bit platforms configured with 4 GB or more of physical memory, you
>> can either use Address Windowing Extensions (AWE) or use multiple
>> instances of SQL Server as a way to fully utilize the large amount of
>> physical memory. AWE may work well for some scenarios; however, you
>> should be aware that AWE memory can only be used for data cache. The
>> memory for procedure cache, connections, locks, and other internal
>> resources of SQL Server must come from the 2 GB (or 3GB, depending on the
>> settings used) portion of the virtual memory. On systems needing to
>> support a large number of databases and user connections, multiple
>> instances of SQL Server may be a better approach to fully alleviate the 2
>> GB or 3GB memory constraint imposed by the 32-bit platform for these data
>> structures."
>> http://www.microsoft.com/technet/prodtechnol/sql/2000/deploy/32bitconsolidation.mspx
>> You also mention that you can configure CPUs into different resource
>> pools. How does this work? Do you have a knowledge base link?
>>
>> Simple partition of CPU's to SQL Instances should be done with the
>> "affinity mask" server option.
>> SQL Server 2005 Books Online
>> affinity mask Option
>> http://msdn2.microsoft.com/en-us/library/ms187104.aspx
>>
>> Dynamic CPU allocation policies can be implemented with WSRM:
>> Windows System Resource Manager
>> http://www.microsoft.com/technet/downloads/winsrvr/wsrm.mspx
>> David
> Thanks David. This info is very helpful.
>|||"Uri Dimant" <urid@.iscar.co.il> wrote in message
news:uYF1sPEvGHA.724@.TK2MSFTNGP05.phx.gbl...
> Isaac
>> Dedicated SQL Server:
>> Intel Xeon MP 3.3 GHz (4 physical Processors)
>> 136 GB (C Drive)
>> 8.0 GB RAM
>
> I'd consider (based on your description) MAX Memory 7GB
>
Thanks Uri.

AWE Memory

I am having a problem with SQL using the memory that should be available to it.
I have the following configuration:
Hardware:
CPU: 4 XEON 2.0 GHZ (with HT) - acts like 8
MEMORY: 8 GB RAM
OS: Windows 2003 Advanced Server (PAE is enabled in boot.ini)
SQL: SQL 2000 Enterprise
AWE is enabled
The user account for SQL has Lock Pages in Memory rights
My issue:
I have review the related threads on this site and compared the recommended
settings to my system. I have not found any differences. However the size of
the SQL working memory set will not increase beyond 1.7 GB.
I found a reference on MSDN that stated that when AWE is enabled an entry
"Address Windowing Extension Enabled" is added to the SQL Error Log. I find
no such entry in my log.
I seems as though AWE is not actually running even though all my setting
seem to be ok.
What have I missed?
Atvar
Atvar,
You also have to set the /3GB switch in boot.ini for SQL Server EE to use
the extra 1GB below the 4GB boundary. Even then it will report something
like 2.7GB used.
See KB 274750, "How to configure memory for more than 2 GB in SQL Server"
http://support.microsoft.com/default...b;en-us;274750
Hope this helps,
Ron
Ron Talmage
SQL Server MVP
"Atvar" <Atvar@.discussions.microsoft.com> wrote in message
news:741D40E0-A2C4-4529-9F64-56041A96C704@.microsoft.com...
> I am having a problem with SQL using the memory that should be available
to it.
> I have the following configuration:
> Hardware:
> CPU: 4 XEON 2.0 GHZ (with HT) - acts like 8
> MEMORY: 8 GB RAM
> OS: Windows 2003 Advanced Server (PAE is enabled in boot.ini)
> SQL: SQL 2000 Enterprise
> AWE is enabled
> The user account for SQL has Lock Pages in Memory rights
> My issue:
> I have review the related threads on this site and compared the
recommended
> settings to my system. I have not found any differences. However the size
of
> the SQL working memory set will not increase beyond 1.7 GB.
> I found a reference on MSDN that stated that when AWE is enabled an entry
> "Address Windowing Extension Enabled" is added to the SQL Error Log. I
find
> no such entry in my log.
> I seems as though AWE is not actually running even though all my setting
> seem to be ok.
> What have I missed?
> --
> Atvar
|||I thought the /3GB switch was not required and was just an option. Is this
not correct?
"Ron Talmage" wrote:

> Atvar,
> You also have to set the /3GB switch in boot.ini for SQL Server EE to use
> the extra 1GB below the 4GB boundary. Even then it will report something
> like 2.7GB used.
> See KB 274750, "How to configure memory for more than 2 GB in SQL Server"
> http://support.microsoft.com/default...b;en-us;274750
> Hope this helps,
> Ron
> --
> Ron Talmage
> SQL Server MVP
> "Atvar" <Atvar@.discussions.microsoft.com> wrote in message
> news:741D40E0-A2C4-4529-9F64-56041A96C704@.microsoft.com...
> to it.
> recommended
> of
> find
>
>
|||It is not required but a good idea in this case. It is not the reason you
are seeing what you say though. I would go back and start from scratch and
ensure you really have Enterprise SQL, WIn2003 Advanced, PAE and AWE turned
on and lock pages in memory for the right account. Verify each, don't just
assume.
Andrew J. Kelly SQL MVP
"Atvar" <Atvar@.discussions.microsoft.com> wrote in message
news:97FEA326-585E-460E-AE8D-6910CB4E9345@.microsoft.com...[vbcol=seagreen]
>I thought the /3GB switch was not required and was just an option. Is this
> not correct?
>
> "Ron Talmage" wrote:
|||Thanks for the response.
I did review things as you suggested. The server is running WIn2003
Enterprise (not called advanded in 2003) and the PAE and AWE are set.
However it turn out that the SQL is standard and not Enterprise. This site
uses several SQL servers and the install was done by their IT department.
This server was specified for SQL Enterprise and the license was purchased.
It appears that the wrong license was installed by the IT department. I
think this is my issue as I understand that SQL standard is limited to 2 GB
of memory.
"Andrew J. Kelly" wrote:

> It is not required but a good idea in this case. It is not the reason you
> are seeing what you say though. I would go back and start from scratch and
> ensure you really have Enterprise SQL, WIn2003 Advanced, PAE and AWE turned
> on and lock pages in memory for the right account. Verify each, don't just
> assume.
> --
> Andrew J. Kelly SQL MVP
>
> "Atvar" <Atvar@.discussions.microsoft.com> wrote in message
> news:97FEA326-585E-460E-AE8D-6910CB4E9345@.microsoft.com...
>
>
|||Yes that is it. Standard SQL will only use 2GB regardless of how much the
server has.
Andrew J. Kelly SQL MVP
"Atvar" <Atvar@.discussions.microsoft.com> wrote in message
news:433230CD-B250-4CB0-AEAE-9ED0A3F954C8@.microsoft.com...[vbcol=seagreen]
> Thanks for the response.
> I did review things as you suggested. The server is running WIn2003
> Enterprise (not called advanded in 2003) and the PAE and AWE are set.
> However it turn out that the SQL is standard and not Enterprise. This
> site
> uses several SQL servers and the install was done by their IT department.
> This server was specified for SQL Enterprise and the license was
> purchased.
> It appears that the wrong license was installed by the IT department. I
> think this is my issue as I understand that SQL standard is limited to 2
> GB
> of memory.
>
> "Andrew J. Kelly" wrote:

AWE Memory

I am having a problem with SQL using the memory that should be available to it.
I have the following configuration:
Hardware:
CPU: 4 XEON 2.0 GHZ (with HT) - acts like 8
MEMORY: 8 GB RAM
OS: Windows 2003 Advanced Server (PAE is enabled in boot.ini)
SQL: SQL 2000 Enterprise
AWE is enabled
The user account for SQL has Lock Pages in Memory rights
My issue:
I have review the related threads on this site and compared the recommended
settings to my system. I have not found any differences. However the size of
the SQL working memory set will not increase beyond 1.7 GB.
I found a reference on MSDN that stated that when AWE is enabled an entry
"Address Windowing Extension Enabled" is added to the SQL Error Log. I find
no such entry in my log.
I seems as though AWE is not actually running even though all my setting
seem to be ok.
What have I missed?
--
AtvarAtvar,
You also have to set the /3GB switch in boot.ini for SQL Server EE to use
the extra 1GB below the 4GB boundary. Even then it will report something
like 2.7GB used.
See KB 274750, "How to configure memory for more than 2 GB in SQL Server"
http://support.microsoft.com/default.aspx?scid=kb;en-us;274750
Hope this helps,
Ron
--
Ron Talmage
SQL Server MVP
"Atvar" <Atvar@.discussions.microsoft.com> wrote in message
news:741D40E0-A2C4-4529-9F64-56041A96C704@.microsoft.com...
> I am having a problem with SQL using the memory that should be available
to it.
> I have the following configuration:
> Hardware:
> CPU: 4 XEON 2.0 GHZ (with HT) - acts like 8
> MEMORY: 8 GB RAM
> OS: Windows 2003 Advanced Server (PAE is enabled in boot.ini)
> SQL: SQL 2000 Enterprise
> AWE is enabled
> The user account for SQL has Lock Pages in Memory rights
> My issue:
> I have review the related threads on this site and compared the
recommended
> settings to my system. I have not found any differences. However the size
of
> the SQL working memory set will not increase beyond 1.7 GB.
> I found a reference on MSDN that stated that when AWE is enabled an entry
> "Address Windowing Extension Enabled" is added to the SQL Error Log. I
find
> no such entry in my log.
> I seems as though AWE is not actually running even though all my setting
> seem to be ok.
> What have I missed?
> --
> Atvar|||I thought the /3GB switch was not required and was just an option. Is this
not correct?
"Ron Talmage" wrote:
> Atvar,
> You also have to set the /3GB switch in boot.ini for SQL Server EE to use
> the extra 1GB below the 4GB boundary. Even then it will report something
> like 2.7GB used.
> See KB 274750, "How to configure memory for more than 2 GB in SQL Server"
> http://support.microsoft.com/default.aspx?scid=kb;en-us;274750
> Hope this helps,
> Ron
> --
> Ron Talmage
> SQL Server MVP
> "Atvar" <Atvar@.discussions.microsoft.com> wrote in message
> news:741D40E0-A2C4-4529-9F64-56041A96C704@.microsoft.com...
> > I am having a problem with SQL using the memory that should be available
> to it.
> >
> > I have the following configuration:
> >
> > Hardware:
> >
> > CPU: 4 XEON 2.0 GHZ (with HT) - acts like 8
> > MEMORY: 8 GB RAM
> >
> > OS: Windows 2003 Advanced Server (PAE is enabled in boot.ini)
> >
> > SQL: SQL 2000 Enterprise
> >
> > AWE is enabled
> > The user account for SQL has Lock Pages in Memory rights
> >
> > My issue:
> >
> > I have review the related threads on this site and compared the
> recommended
> > settings to my system. I have not found any differences. However the size
> of
> > the SQL working memory set will not increase beyond 1.7 GB.
> >
> > I found a reference on MSDN that stated that when AWE is enabled an entry
> > "Address Windowing Extension Enabled" is added to the SQL Error Log. I
> find
> > no such entry in my log.
> >
> > I seems as though AWE is not actually running even though all my setting
> > seem to be ok.
> >
> > What have I missed?
> >
> > --
> > Atvar
>
>|||It is not required but a good idea in this case. It is not the reason you
are seeing what you say though. I would go back and start from scratch and
ensure you really have Enterprise SQL, WIn2003 Advanced, PAE and AWE turned
on and lock pages in memory for the right account. Verify each, don't just
assume.
--
Andrew J. Kelly SQL MVP
"Atvar" <Atvar@.discussions.microsoft.com> wrote in message
news:97FEA326-585E-460E-AE8D-6910CB4E9345@.microsoft.com...
>I thought the /3GB switch was not required and was just an option. Is this
> not correct?
>
> "Ron Talmage" wrote:
>> Atvar,
>> You also have to set the /3GB switch in boot.ini for SQL Server EE to use
>> the extra 1GB below the 4GB boundary. Even then it will report something
>> like 2.7GB used.
>> See KB 274750, "How to configure memory for more than 2 GB in SQL Server"
>> http://support.microsoft.com/default.aspx?scid=kb;en-us;274750
>> Hope this helps,
>> Ron
>> --
>> Ron Talmage
>> SQL Server MVP
>> "Atvar" <Atvar@.discussions.microsoft.com> wrote in message
>> news:741D40E0-A2C4-4529-9F64-56041A96C704@.microsoft.com...
>> > I am having a problem with SQL using the memory that should be
>> > available
>> to it.
>> >
>> > I have the following configuration:
>> >
>> > Hardware:
>> >
>> > CPU: 4 XEON 2.0 GHZ (with HT) - acts like 8
>> > MEMORY: 8 GB RAM
>> >
>> > OS: Windows 2003 Advanced Server (PAE is enabled in boot.ini)
>> >
>> > SQL: SQL 2000 Enterprise
>> >
>> > AWE is enabled
>> > The user account for SQL has Lock Pages in Memory rights
>> >
>> > My issue:
>> >
>> > I have review the related threads on this site and compared the
>> recommended
>> > settings to my system. I have not found any differences. However the
>> > size
>> of
>> > the SQL working memory set will not increase beyond 1.7 GB.
>> >
>> > I found a reference on MSDN that stated that when AWE is enabled an
>> > entry
>> > "Address Windowing Extension Enabled" is added to the SQL Error Log. I
>> find
>> > no such entry in my log.
>> >
>> > I seems as though AWE is not actually running even though all my
>> > setting
>> > seem to be ok.
>> >
>> > What have I missed?
>> >
>> > --
>> > Atvar
>>|||Thanks for the response.
I did review things as you suggested. The server is running WIn2003
Enterprise (not called advanded in 2003) and the PAE and AWE are set.
However it turn out that the SQL is standard and not Enterprise. This site
uses several SQL servers and the install was done by their IT department.
This server was specified for SQL Enterprise and the license was purchased.
It appears that the wrong license was installed by the IT department. I
think this is my issue as I understand that SQL standard is limited to 2 GB
of memory.
"Andrew J. Kelly" wrote:
> It is not required but a good idea in this case. It is not the reason you
> are seeing what you say though. I would go back and start from scratch and
> ensure you really have Enterprise SQL, WIn2003 Advanced, PAE and AWE turned
> on and lock pages in memory for the right account. Verify each, don't just
> assume.
> --
> Andrew J. Kelly SQL MVP
>
> "Atvar" <Atvar@.discussions.microsoft.com> wrote in message
> news:97FEA326-585E-460E-AE8D-6910CB4E9345@.microsoft.com...
> >I thought the /3GB switch was not required and was just an option. Is this
> > not correct?
> >
> >
> > "Ron Talmage" wrote:
> >
> >> Atvar,
> >>
> >> You also have to set the /3GB switch in boot.ini for SQL Server EE to use
> >> the extra 1GB below the 4GB boundary. Even then it will report something
> >> like 2.7GB used.
> >>
> >> See KB 274750, "How to configure memory for more than 2 GB in SQL Server"
> >> http://support.microsoft.com/default.aspx?scid=kb;en-us;274750
> >>
> >> Hope this helps,
> >> Ron
> >> --
> >> Ron Talmage
> >> SQL Server MVP
> >>
> >> "Atvar" <Atvar@.discussions.microsoft.com> wrote in message
> >> news:741D40E0-A2C4-4529-9F64-56041A96C704@.microsoft.com...
> >> > I am having a problem with SQL using the memory that should be
> >> > available
> >> to it.
> >> >
> >> > I have the following configuration:
> >> >
> >> > Hardware:
> >> >
> >> > CPU: 4 XEON 2.0 GHZ (with HT) - acts like 8
> >> > MEMORY: 8 GB RAM
> >> >
> >> > OS: Windows 2003 Advanced Server (PAE is enabled in boot.ini)
> >> >
> >> > SQL: SQL 2000 Enterprise
> >> >
> >> > AWE is enabled
> >> > The user account for SQL has Lock Pages in Memory rights
> >> >
> >> > My issue:
> >> >
> >> > I have review the related threads on this site and compared the
> >> recommended
> >> > settings to my system. I have not found any differences. However the
> >> > size
> >> of
> >> > the SQL working memory set will not increase beyond 1.7 GB.
> >> >
> >> > I found a reference on MSDN that stated that when AWE is enabled an
> >> > entry
> >> > "Address Windowing Extension Enabled" is added to the SQL Error Log. I
> >> find
> >> > no such entry in my log.
> >> >
> >> > I seems as though AWE is not actually running even though all my
> >> > setting
> >> > seem to be ok.
> >> >
> >> > What have I missed?
> >> >
> >> > --
> >> > Atvar
> >>
> >>
> >>
>
>|||Yes that is it. Standard SQL will only use 2GB regardless of how much the
server has.
--
Andrew J. Kelly SQL MVP
"Atvar" <Atvar@.discussions.microsoft.com> wrote in message
news:433230CD-B250-4CB0-AEAE-9ED0A3F954C8@.microsoft.com...
> Thanks for the response.
> I did review things as you suggested. The server is running WIn2003
> Enterprise (not called advanded in 2003) and the PAE and AWE are set.
> However it turn out that the SQL is standard and not Enterprise. This
> site
> uses several SQL servers and the install was done by their IT department.
> This server was specified for SQL Enterprise and the license was
> purchased.
> It appears that the wrong license was installed by the IT department. I
> think this is my issue as I understand that SQL standard is limited to 2
> GB
> of memory.
>
> "Andrew J. Kelly" wrote:
>> It is not required but a good idea in this case. It is not the reason
>> you
>> are seeing what you say though. I would go back and start from scratch
>> and
>> ensure you really have Enterprise SQL, WIn2003 Advanced, PAE and AWE
>> turned
>> on and lock pages in memory for the right account. Verify each, don't
>> just
>> assume.
>> --
>> Andrew J. Kelly SQL MVP
>>
>> "Atvar" <Atvar@.discussions.microsoft.com> wrote in message
>> news:97FEA326-585E-460E-AE8D-6910CB4E9345@.microsoft.com...
>> >I thought the /3GB switch was not required and was just an option. Is
>> >this
>> > not correct?
>> >
>> >
>> > "Ron Talmage" wrote:
>> >
>> >> Atvar,
>> >>
>> >> You also have to set the /3GB switch in boot.ini for SQL Server EE to
>> >> use
>> >> the extra 1GB below the 4GB boundary. Even then it will report
>> >> something
>> >> like 2.7GB used.
>> >>
>> >> See KB 274750, "How to configure memory for more than 2 GB in SQL
>> >> Server"
>> >> http://support.microsoft.com/default.aspx?scid=kb;en-us;274750
>> >>
>> >> Hope this helps,
>> >> Ron
>> >> --
>> >> Ron Talmage
>> >> SQL Server MVP
>> >>
>> >> "Atvar" <Atvar@.discussions.microsoft.com> wrote in message
>> >> news:741D40E0-A2C4-4529-9F64-56041A96C704@.microsoft.com...
>> >> > I am having a problem with SQL using the memory that should be
>> >> > available
>> >> to it.
>> >> >
>> >> > I have the following configuration:
>> >> >
>> >> > Hardware:
>> >> >
>> >> > CPU: 4 XEON 2.0 GHZ (with HT) - acts like 8
>> >> > MEMORY: 8 GB RAM
>> >> >
>> >> > OS: Windows 2003 Advanced Server (PAE is enabled in boot.ini)
>> >> >
>> >> > SQL: SQL 2000 Enterprise
>> >> >
>> >> > AWE is enabled
>> >> > The user account for SQL has Lock Pages in Memory rights
>> >> >
>> >> > My issue:
>> >> >
>> >> > I have review the related threads on this site and compared the
>> >> recommended
>> >> > settings to my system. I have not found any differences. However the
>> >> > size
>> >> of
>> >> > the SQL working memory set will not increase beyond 1.7 GB.
>> >> >
>> >> > I found a reference on MSDN that stated that when AWE is enabled an
>> >> > entry
>> >> > "Address Windowing Extension Enabled" is added to the SQL Error Log.
>> >> > I
>> >> find
>> >> > no such entry in my log.
>> >> >
>> >> > I seems as though AWE is not actually running even though all my
>> >> > setting
>> >> > seem to be ok.
>> >> >
>> >> > What have I missed?
>> >> >
>> >> > --
>> >> > Atvar
>> >>
>> >>
>> >>
>>