Autonumber field: setting

Showing posts with label setting. Show all posts

Sunday, March 11, 2012

AWE SQL Performance Problem

We recently enabled AWE on a SQL Server cluster. Each box has 8CPU and 8GB R
AM. The setting seems to have made the difference in RAM usage, but we are e
xperiencing extremely high CPU utilization and overall the system does not s
eem to be any faster. If an
ything, it seems to have slowed down some. There are a lot of variables, but
I was wondering of anyone has had adverse effects with the AWE setting.From BOL.
<<
To enable AWE, set awe enabled to 1. SQL Server will reserve almost all
available memory, leaving 128 megabytes (MB) or less, unless a value has
been specified for max server memory.
What is your max memory setting? Leaving 128M for the OS probably isn't a
good idea.
BTW... Profiler may be helpful in understanding the CPU usage.
Brian Moran
Principal Mentor
Solid Quality Learning
SQL Server MVP
http://www.solidqualitylearning.com
"Phil Appel" <phil@.chileinc.com> wrote in message
news:774F1405-0770-4A4F-B551-9CC330AE9CE4@.microsoft.com...
> We recently enabled AWE on a SQL Server cluster. Each box has 8CPU and 8GB
RAM. The setting seems to have made the difference in RAM usage, but we are
experiencing extremely high CPU utilization and overall the system does not
seem to be any faster. If anything, it seems to have slowed down some. There
are a lot of variables, but I was wondering of anyone has had adverse
effects with the AWE setting.|||We had some CPU spin and server instability issues that were instantaneously
and permenantly solved by turning off the /3GB switch and reducing max
server mem to 1.5GB less than physical. PSS said there was potential kernel
memory starvation with /3GB and max server memory set to near physical. Not
sure if this applies to your scenario.
"Phil Appel" <phil@.chileinc.com> wrote in message
news:774F1405-0770-4A4F-B551-9CC330AE9CE4@.microsoft.com...
> We recently enabled AWE on a SQL Server cluster. Each box has 8CPU and 8GB
RAM. The setting seems to have made the difference in RAM usage, but we are
experiencing extremely high CPU utilization and overall the system does not
seem to be any faster. If anything, it seems to have slowed down some. There
are a lot of variables, but I was wondering of anyone has had adverse
effects with the AWE setting.|||Hi Phil,
I am viewing your post and since we have not heard from you for some time
and I wonder how things go on your side. To disable the AWE to check if the
performance issue is related to the AWE is the method to narrow down
performance problems to AWE. Also, you could refer to the link of the
followings for reference:
How To Gather Information for Effective Troubleshooting of Performance
Issues
http://support.microsoft.com/defaul...microsoft.com:
80/support/kb/articles/Q175/6/58.ASP&NoWebContent=1
http://support.microsoft.com/defaul...kb;en-us;298475
Also, if the case is critical and it should be troubleshot by some advanced
tools which are not supported in the newsgroup. Therefore, we probably will
not be able to resolve the issue through the newsgroups. I'd recommend
opening a Support incident with Microsoft Support Services, so that a
dedicated Support Professional can assist with your advisory case. Please
be advised that contacting phone support will be a charged call.
To obtain the phone numbers for specific technology request please take a
look at the web site listed below.
http://support.microsoft.com/defaul...US;PHONENUMBERS
If you are outside the US please see http://support.microsoft.com for
regional support phone numbers.
Thanks.
Hope this helps.
Best regards
Baisong Wei
Microsoft Online Support
----
Get Secure! - www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.
Please reply to newsgroups only. Thanks.

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...
> >
>> 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.

Wednesday, March 7, 2012

AWE enable and SQL Server 2005 x64 bits

Hello,

I am setting up a new server with Windows Server 2003 x64 bits and SQL Server 2005 x64 bits. Under 32 bits of Windows we normally use /3GB and enable AWE under SQL Server (both SQL 2000 and SQL 2005) and allocate 6 GB of fixed memory to SQL Server.

Does any one know whether I should do the same thing under the x64 bits platform. I read some articles on the web that it is no longer required to use AWE under SQL 2005 x64 bits?

Please advise.

Thanks.

You don't need to enable AWE via sp_configure if you are running the 64bit version on x64, as 64bit SQL doesn't need to use the AWE api to address the larger memory space.

It is recommended to grant the SQL service account the OS privilege "Lock pages in memory". By doing this you are preventing the OS from swapping SQL's memory pages to disk and allowing SQL itself to reduce it's working set when the OS requires it to do so. This should give you a performance benefit under tight memory situations. One of the odd results of using "lock pages in memory" is that we will use the AWE api to map the virtual address space into and out of physical memory (in fact the "lock pages in memory" privilege is a requirement for using AWE with 32bit). As a result the "AWE allocated" value from dbcc memorystatus will show a value, indicating that AWE is enabled even though it is disabled in sp_configure.

In summary, the 64bit version of SQL Server can address all the memory on the server without having to use AWE. A perf benefit may be observed when "lock pages in memory" is enabled and this results in the use of AWE internally, irrespective of the sp_configure setting.

thx, Simon.

|||

Hi Simon

Thanks you for your advice. Are you suggesting that we should turn on "local pages in memory" under x64 bits platform as well even though SQL can address all the memory on the server?

One more question, do you know if I need /PAE under x64 bits of Windows?

Thanks.

|||

I just found an article under MS and according to this article from MS, PAE is not available in Windows x64...

Thanks..

|||Do you still need the /3GB switch in a 2005 x64 install if you have 16GB of memory?|||No

AWE enable and SQL Server 2005 x64 bits

Hello,

Does any one know whether I should do the same thing under the x64 bits platform. I read some articles on the web that it is no longer required to use AWE under SQL 2005 x64 bits?

Please advise.

Thanks.

You don't need to enable AWE via sp_configure if you are running the 64bit version on x64, as 64bit SQL doesn't need to use the AWE api to address the larger memory space.

thx, Simon.

|||

Hi Simon

Thanks you for your advice. Are you suggesting that we should turn on "local pages in memory" under x64 bits platform as well even though SQL can address all the memory on the server?

One more question, do you know if I need /PAE under x64 bits of Windows?

Thanks.

|||

I just found an article under MS and according to this article from MS, PAE is not available in Windows x64...

Thanks..

|||Do you still need the /3GB switch in a 2005 x64 install if you have 16GB of memory?|||No

AWE and the max momory setting

Having read this excellent post on AWE and the max momory setting:

http://www.sqlteam.com/forums/topic.asp?TOPIC_ID=55191

Which states:

"Optional to limit the amount of memory the SQL Server will use, because SQL Server will not dynamically allocate/deallocate memory when AWE is enabled.
Leave about 500 MB available for OS"

Subsequently I have read:

http://searchsqlserver.techtarget.com/tip/0,289483,sid87_gci1210563,00.html

Which states:

"For instance, SQL Server 2005 will have memory buffer pool problems if the max server memory setting is not set to its default 2147483647 (i.e., all available memory)."

So what should I set my max. memory to on 2K5 when I have AWE enabled.

I am not sure about the comment in the second article that you have mentioned. That comment is not precise at all.

With regards to MAX Server Memory setting, it depends how much memory does your machine have and if you run other apps (Analysis/Reporting Services, etc) on the server.

Say if your server has 16GB and you only use the server for SQL Server, you should set the MAX Server Memory to 14GB.

regards

Jag

|||

I agree the 2nd article is not precise, which is why I ahve restricted by max memory. I have 8GB and have restricted SQL Server to 7.5GB as only the OS is running on that server.

|||

I would restrict SQL Server to 6.5GB if I had 8GB on my machine. With OS only having 500MB You might experience backup errors if SQL Server 2K5 uses all what it is configured for.

|||Thanks for the advice.

Saturday, February 25, 2012

Avoiding Setting xp_cmdshell in SQL 2005

Would anyone know, how to work around a potential problem of not using xp_cmdshell.

For our users, We are using xp_cmdshell to look up the xml files in a particular folder and process them into Database. xp_cmdshell is used to read the contents of the file and build up the string for the stored procedure parameter input.

In SQL 2000, xp_cmdshell was set by default. in SQL 2005 not set by default and some of my users doesn't want to set it suggesting security concerns.

Thanks.

You could use OPENROWSET with BULK option for upload xml file as sigle blob into one database field. For example:

Code Snippet

INSERT INTO myTable(Document)
SELECT * FROM OPENROWSET(BULK N'C:\data.xml', SINGLE_BLOB) AS Document

Then you could use xml data type functions for split data. See xml.value, xml.nodes in BOL

Sunday, March 11, 2012

AWE SQL Performance Problem

Thursday, March 8, 2012

AWE Question

AWE Question

Wednesday, March 7, 2012

AWE enable and SQL Server 2005 x64 bits

AWE enable and SQL Server 2005 x64 bits

AWE and the max momory setting

Saturday, February 25, 2012

Avoiding Setting xp_cmdshell in SQL 2005

Autonumber field

Blog Archive

About Me