Click here to monitor SSC
SQLServerCentral is supported by Redgate
Log in  ::  Register  ::  Not logged in
Home       Members    Calendar    Who's On

Add to briefcase

chache queries Expand / Collapse
Posted Wednesday, April 30, 2014 4:37 AM
Valued Member

Valued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued Member

Group: General Forum Members
Last Login: Friday, January 8, 2016 3:56 AM
Points: 68, Visits: 192
Hi ,

Do you happen to know of a way to invalidate cached query plans?
I would rather target a specific query instead of invalidating all of them.

Also do you know of any sql server setting that will cause cached query plans to invalidate even though only one character in the queries has changed?

exec sp_executesql N'select
cast(5 as int) as DisplaySequence,
mt.Description + '' '' + ct.Description as Source,
c.FirstName + '' '' + c.LastName as Name,
cus.CustomerNumber Code,
c.companyname as "Company Name",
cphone.PhoneNumber as Phone,
cfax.PhoneNumber as Fax,
ccell.PhoneNumber as Cell,
cemail.EmailAddress as Email,
wa.WebAddress as Web,
cl.Id as Id,
c.Id as ContactId
contactlink cl
left join ContactTypes ct on = cl.ContactTypeID
left join Contacts c on c.ID = cl.ContactID
left join Customers cus on = cl.CustomerID
left join MasterTypes mt on = ct.MasterTypeID
left join contactaddresslink cal on cal.ContactID =
left join Addresses a on = cal.AddressID
left join StatesProvinces sp on = a.StateProvinceID
left join ContactPhoneLink cpl_phone on cpl_phone.ContactID = and cpl_phone.PhoneTypeID = 1
left join phones cphone on
left join ContactPhoneLink cpl_fax on cpl_fax.ContactID = and cpl_fax.PhoneTypeID = 2
left join phones cFax on
left join ContactPhoneLink cpl_cell on cpl_cell.ContactID = and cpl_cell.PhoneTypeID = 3
left join phones cCell on
left join ContactEmailLink cel on cel.ContactID =
left join Emails cEmail on = cel.EmailID
left join ContactWebLink cwl on cwl.ContactID =
left join WebAddresses wa on = cwl.WebAddressID
where = @customerId
',N'@CustomerId int',@CustomerId=1065

In this query we have seen (on some databases) simply changing ‘@CustomerId int',@CustomerId=1065’ too ‘@customerId int',@customerId=1065’ fixed the a speed problem….just changed the case on the Customer bind parameter. On other servers this has no effect. I’m thinking the server is using an old cached query plan, but don’t know for sure.

Post #1566298
Posted Wednesday, April 30, 2014 4:37 AM
Valued Member

Valued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued Member

Group: General Forum Members
Last Login: Friday, January 8, 2016 3:56 AM
Points: 68, Visits: 192
The query seems to have gone bad again on my machine with or without a capital ‘C’
I found a way to target and delete specific query plans, but it still is running slow from within .net.
I am trying to find out why it is slow sometimes and fast at other times, any help would be greatly appreciated.

Here is what I found

Find cached plans
SELECT plan_handle, st.text
FROM sys.dm_exec_cached_plans
CROSS APPLY sys.dm_exec_sql_text(plan_handle) AS st
WHERE text LIKE N' = cwl.WebAddressID%'

Remove specific plan
DBCC FREEPROCCACHE (0x06001E00AC6A672F90961F6C0400000001000000000000000000000000000000000000000000000000000000
Post #1566299
Posted Wednesday, April 30, 2014 4:58 AM



Group: General Forum Members
Last Login: Today @ 10:55 AM
Points: 45,613, Visits: 44,143
Please don't start multiple new threads for single problem.

No replies to this thread please, direct replies to

Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
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 #1566307
Posted Wednesday, April 30, 2014 5:02 AM



Group: General Forum Members
Last Login: Today @ 11:34 AM
Points: 17,171, Visits: 32,131
It sounds like you're hitting bad parameter sniffing. But, without seeing the "good" and "bad" execution plans, it's hard to know for sure. You need to capture both plans and then look to the SELECT operator. There you'll find the compile time parameters. Look at the values there and compare those to your statistics to understand why you're getting a plan that is less than optimal. It has to do with the distribution of your data, or, possibly, the age of your statistics, or, again, possibly, how your statistics are generated (sampled vs. a full scan). I can't tell you much more than that based on the information presented.

To address the bad parameter sniffing, you need to determine if you need a single plan all the time, in which case using OPTIMIZE FOR some value would work. Or, if you need a specific plan every time the query runs, in which case using RECOMPILE is the way to go (depending of course on the compile time). Or, if you need a generic plan not based on specific values, in which case OPTIMIZE FOR UNKNOWN is the way to go. But again, I don't know what applies here since I can't see the plans, your statistics, or their sample rate.

"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood..." Theodore Roosevelt
The Scary DBA
Author of:
SQL Server Query Performance Tuning
SQL Server Execution Plans

Product Evangelist for Red Gate Software
Post #1566309
« Prev Topic | Next Topic »

Add to briefcase

Permissions Expand / Collapse