Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase ««12

Optimize ad hoc workloads Expand / Collapse
Author
Message
Posted Tuesday, February 05, 2013 5:41 PM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Wednesday, April 16, 2014 9:25 AM
Points: 7,070, Visits: 12,523
SQLRNNR (2/5/2013)
sqlfriends (2/5/2013)
Thanks ALL.

I read a tutorial and recommend this option should be enabled for all instances. Read and still a little confusing about when I should enable or disable it.

I will dig more.


Cite that article please.

I wouldn't agree that it is something that must be done on all instances. Test it first for your environment and then make a decision whether or not to implement it in prod - but certainly not just a blanket yes for all instances.

Glenn Berry talks about it as a standard config. In general may tend to agree with it although I suppose it could take a little while longer before the plan cache "warms up." I'll typically enable it by default unless I have a captive audience where I know all data access is done through stored procs or prepared statements:

Some Suggested SQL Server 2008 R2 Instance Configuration Settings

Optimize for ad-hoc workloads
Optimize for ad-hoc workloads is a new instance level setting that was added in SQL Server 2008 which is designed to help control the amount of memory that is used by single-use, ad-hoc query plans in the procedure cache. It allows SQL Server to only store a small stub of an ad-hoc query plan in the procedure cache the first time the ad-hoc plan is executed, which reduces the memory required by the plan in the procedure cache.

With SQL Server 2005, it was very common to see very large amounts of memory being used by single-use, ad-hoc query plans (often in the 6 to 8 GB range). Later builds of SQL Server have changes that reduced this problem somewhat, but it was still a big issue. Interestingly, one of the biggest offenders that generated ad-hoc query plans in SQL Server 2005 was SQL Server Agent! Another big offender was SharePoint.

In my opinion, you should always enable this setting on SQL Server 2008 and above. I really cannot think of a good reason not to do this.


__________________________________________________________________________________________________
There are no special teachers of virtue, because virtue is taught by the whole community. --Plato

Believe you can and you're halfway there. --Theodore Roosevelt

Everything Should Be Made as Simple as Possible, But Not Simpler --Albert Einstein

The significant problems we face cannot be solved at the same level of thinking we were at when we created them. --Albert Einstein

1 apple is not exactly 1/8 of 8 apples. Because there are no absolutely identical apples. --Giordy
Post #1416179
Posted Wednesday, February 06, 2013 12:02 AM


SSC-Forever

SSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-Forever

Group: General Forum Members
Last Login: Yesterday @ 11:52 AM
Points: 41,530, Visits: 34,446
opc.three (2/5/2013)
SQLRNNR (2/5/2013)
sqlfriends (2/5/2013)
Thanks ALL.

I read a tutorial and recommend this option should be enabled for all instances. Read and still a little confusing about when I should enable or disable it.

I will dig more.


Cite that article please.

I wouldn't agree that it is something that must be done on all instances. Test it first for your environment and then make a decision whether or not to implement it in prod - but certainly not just a blanket yes for all instances.

Glenn Berry talks about it as a standard config. In general may tend to agree with it although I suppose it could take a little while longer before the plan cache "warms up." I'll typically enable it by default unless I have a captive audience where I know all data access is done through stored procs or prepared statements:


Grant and Jonathan I think as well. It's pretty harmless as settings go.



Gail Shaw
Microsoft Certified Master: SQL Server 2008, MVP
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability

We walk in the dark places no others will enter
We stand on the bridge and no one may pass

Post #1416268
« Prev Topic | Next Topic »

Add to briefcase ««12

Permissions Expand / Collapse