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

Fun with sp_executeSQL Expand / Collapse
Author
Message
Posted Monday, January 30, 2012 10:34 PM
SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Yesterday @ 2:19 PM
Points: 2,891, Visits: 1,781
Comments posted to this topic are about the item Fun with sp_executeSQL

LinkedIn Profile
Newbie on www.simple-talk.com
Post #1244041
Posted Tuesday, January 31, 2012 3:13 AM
Grasshopper

GrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopper

Group: General Forum Members
Last Login: Monday, June 30, 2014 2:43 AM
Points: 11, Visits: 12
Excellent evidence-based article. More please.
Post #1244170
Posted Tuesday, January 31, 2012 3:28 AM
SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC Rookie

Group: General Forum Members
Last Login: Wednesday, February 1, 2012 9:59 AM
Points: 28, Visits: 59
Nice article .
Post #1244182
Posted Tuesday, January 31, 2012 5:40 AM
SSCommitted

SSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommitted

Group: General Forum Members
Last Login: Yesterday @ 10:19 AM
Points: 1,863, Visits: 2,977
Thanks David, useful article.
Post #1244265
Posted Tuesday, January 31, 2012 7:08 AM
Old Hand

Old HandOld HandOld HandOld HandOld HandOld HandOld HandOld Hand

Group: General Forum Members
Last Login: Wednesday, July 2, 2014 4:22 AM
Points: 383, Visits: 232
Nice article, but I'm missing a hint to adhoc queries and their influence on the proc cache. You can save a lot of memory by using the optimize for ad hoc workloads Option.
http://msdn.microsoft.com/en-us/library/cc645587.aspx


For more details see this blog entry from Kimberly Tripp:
http://sqlskills.com/BLOGS/KIMBERLY/post/Procedure-cache-and-optimizing-for-adhoc-workloads.aspx

Post #1244352
Posted Tuesday, January 31, 2012 7:44 AM
UDP Broadcaster

UDP BroadcasterUDP BroadcasterUDP BroadcasterUDP BroadcasterUDP BroadcasterUDP BroadcasterUDP BroadcasterUDP Broadcaster

Group: General Forum Members
Last Login: Yesterday @ 8:38 AM
Points: 1,469, Visits: 1,584
On your point regarding variable length parameters, I've seen Subsonic (ORM) do this behavior too. I figured it what was happening when I started digging into why my proc cache was 6GB. My devs changed their code to call procs (fixed-length parameters) and cut the proc cache down to 2.5GB. Happy day, my data cache hit ratio improved nicely with just a little bit of work.
Post #1244392
Posted Tuesday, January 31, 2012 8:46 AM
SSChasing Mays

SSChasing MaysSSChasing MaysSSChasing MaysSSChasing MaysSSChasing MaysSSChasing MaysSSChasing MaysSSChasing Mays

Group: General Forum Members
Last Login: Friday, July 18, 2014 1:26 PM
Points: 656, Visits: 467
Great article David. Thank you.

I thought that there were limits imposed on the various memory components based on on the total amount of memory given to SQL Server.

For example: Proc Cache limits
SQL Server 2005 SP2
75% of server memory from 0-4GB +
10% of server memory from 4Gb-64GB +
5% of server memory > 64GB
So 14GB given to a SQL SERVER 2005 SP2 would yield a 4GB Proc Cache.

Is it correct in stating that the limits do not exist and proc cache for example can consume additional memory?

Thanks
Mark


Post #1244468
Posted Tuesday, January 31, 2012 9:14 AM
SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Yesterday @ 2:19 PM
Points: 2,891, Visits: 1,781
Christoph Muthmann (1/31/2012)
Nice article, but I'm missing a hint to adhoc queries and their influence on the proc cache. You can save a lot of memory by using the optimize for ad hoc workloads Option.
http://msdn.microsoft.com/en-us/library/cc645587.aspx



Good catch, wish I'd known this 2 years ago! I've passed this one on to my colleagues.
The worry now is that I'm going to hear "we don't have to fix this because there is a DB option".


LinkedIn Profile
Newbie on www.simple-talk.com
Post #1244495
Posted Tuesday, January 31, 2012 9:16 AM
SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Yesterday @ 2:19 PM
Points: 2,891, Visits: 1,781
Mark, I haven't come across any predefined limits for proc cache but that doesn't mean to say they aren't there.

Time for further research methinks!


LinkedIn Profile
Newbie on www.simple-talk.com
Post #1244497
Posted Tuesday, January 31, 2012 9:48 AM
SSCommitted

SSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommitted

Group: General Forum Members
Last Login: Wednesday, May 28, 2014 1:35 PM
Points: 1,635, Visits: 1,970
David.Poole (1/31/2012)
Christoph Muthmann (1/31/2012)
Nice article, but I'm missing a hint to adhoc queries and their influence on the proc cache. You can save a lot of memory by using the optimize for ad hoc workloads Option.
http://msdn.microsoft.com/en-us/library/cc645587.aspx



Good catch, wish I'd known this 2 years ago! I've passed this one on to my colleagues.
The worry now is that I'm going to hear "we don't have to fix this because there is a DB option".


The only thing with that is you're still paying the cost to the query optimizer for each new compile. It's just taking less space in memory unless it's called again.

It's worth mentioning that you see the same capitalization behavior if you start using plan guides. It has to do with the fact that a hash of the query is created first and since there's potential for SQL to be capitalization sensitive it doesn't muck with capitalization before doing the hash.
Post #1244538
« Prev Topic | Next Topic »

Add to briefcase 12»»

Permissions Expand / Collapse