Login or Sign Up to become a member!

EXPERTS, INFORMATION, IDEAS & KNOWLEDGE

Social bookmarker Add this

Your profile

Search

November 2008
Mon Tue Wed Thu Fri Sat Sun
 << <   > >>
          1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30

XML Feeds

« How to Rebuild System Databases in SQL Server 2008SQL Server 2008 Express with Advanced Services And SQL Server 2008 Express With Tools Now Available For Download »
The Data Management Journal

LINQ to SQL queries involving strings cause SQL Server procedure cache bloat

by SQLDenis


Permalink 28 Aug 2008 10:12 , Categories: Data Modelling & Design Tags: bug, linq, performance

Adam Machanic created an item on connect explaining how LINQ to SQL queries involving strings cause SQL Server procedure cache bloat

If an application is using LINQ to SQL and the queries involve the use of strings that can be highly variable in length, the SQL Server procedure cache will become bloated with one version of the query for every possible string length. For example, consider the following very simple queries created against the Person.AddressTypes table in the AdventureWorks2008 database:

  1. var p =
  2.                 from n in x.AddressTypes
  3.                 where n.Name == "Billing"
  4.                 select n;
  5.  
  6.             var p =
  7.                 from n in x.AddressTypes
  8.                 where n.Name == "Main Office"
  9.                 select n;

If both of these queries are run, we will see two entries in the SQL Server procedure cache: One bound with an NVARCHAR(7), and the other with an NVARCHAR(11). Now imagine if there were hundreds or thousands of different input strings, all with different lengths. The procedure cache would become unnecessarily filled with all sorts of different plans for the exact same query. Even worse, imagine if a query used two or three different string parameters. The procedure cache could end up with hundreds of thousands or even millions of entries, the only differences being the variable lengths

Wow that is bad indeed, please go to the connect site and vote for this so that Microsoft ‘fixes’ this. Here is the URL: https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=363290

4 comments »Send a trackback » 1161 views

Trackback address for this post

Trackback URL (right click and copy shortcut/link location)

4 comments

Comment from: chrissie1 [Member] Email
I have a feelig they released Linq a bit to early. On the other hand it is a complicated system. So it was bounf to have some bugs.
08/28/08 @ 14:30
Comment from: SQLDenis [Member] Email
Yep, RAM - proc cache = free ram for other stuff. If your proc cache is too big you won't have that much RAM left unless you want to run DBCC FREEPROCACHE every 10 minutes :-0
08/28/08 @ 14:33
Comment from: coolcoder [Visitor] Email · http://sqldev.wordpress.com
****-
Is this still the case in SP1?, I know they made changes to LINQ to SQL specifically in the service pack.
08/29/08 @ 01:57
Comment from: SQLDenis [Member] Email
Coolcoder, the connect item shows Visual Studio 2008 Service Pack 1
08/29/08 @ 03:53

Leave a comment


Your email address will not be revealed on this site.

Your URL will be displayed.
PoorExcellent
(Line breaks become <br />)
(Name, email & website)
(Allow users to contact you through a message form (your email will not be revealed.)