<a href="http://g.adspeed.net/ad.php?do=clk&zid=15220&wd=468&ht=60&pair=as" target="_blank"><img style="border:0px;" src="http://g.adspeed.net/ad.php?do=img&zid=15220&wd=468&ht=60&pair=as" alt="i" width="468" height="60"/></a>
Log in
::
Register
::
Not logged in
Home
Tags
Articles
Editorials
Stairways
Forums
Scripts
Videos
Blogs
QotD
Books
Ask SSC
SQL Jobs
Training
Authors
About us
Contact us
Newsletters
Write for us
<a href="http://g.adspeed.net/ad.php?do=clk&zid=15491&wd=120&ht=300&pair=as" target="_top"><img style="border:0px;" src="http://g.adspeed.net/ad.php?do=img&zid=15491&wd=120&ht=300&pair=as" alt="i" width="120" height="300"/></a>
Recent Posts
Recent Posts
Popular Topics
Popular Topics
Home
Search
Members
Calendar
Who's On
Home
»
SQL Server 2008
»
T-SQL (SS2K8)
»
Stored Procedure looses execution plan.
14 posts, Page 1 of 2
1
2
»»
Stored Procedure looses execution plan.
Rate Topic
Display Mode
Topic Options
Author
Message
WangcChiKaBastar
WangcChiKaBastar
Posted Wednesday, December 26, 2012 9:34 AM
Valued Member
Group: General Forum Members
Last Login: Yesterday @ 2:53 PM
Points: 73,
Visits: 339
I have a stored procedure and when I run it First time it creates an execution plan and it takes long time to complete which is understandable after the first time when I run it second time, it works perfectly...
now here is the issue... If I run the proc lets say today manually then there is no issue rest of the day and application accessing it don't complain about timeout issues...
when I run the proc tomorrow it again takes forever to complete...and the applications time out on the front end...
to resolve the time out I have to manually go to SSMS run the stored proc..and then applications have no issue for the rest of the day.
my question is why is the Query execution plan getting flushed/lost next day ?
the data doesnt change much and not at all some times...
SP uses Temp table and correlated subquery.
Post #1400285
Sean Lange
Sean Lange
Posted Wednesday, December 26, 2012 9:52 AM
SSCrazy Eights
Group: General Forum Members
Last Login: Yesterday @ 2:34 PM
Points: 8,592,
Visits: 8,233
WangcChiKaBastar (12/26/2012)
I have a stored procedure and when I run it First time it creates an execution plan and it takes long time to complete which is understandable after the first time when I run it second time, it works perfectly...
now here is the issue... If I run the proc lets say today manually then there is no issue rest of the day and application accessing it don't complain about timeout issues...
when I run the proc tomorrow it again takes forever to complete...and the applications time out on the front end...
to resolve the time out I have to manually go to SSMS run the stored proc..and then applications have no issue for the rest of the day.
my question is why is the Query execution plan getting flushed/lost next day ?
the data doesnt change much and not at all some times...
SP uses Temp table and correlated subquery.
That is the nature of execution plans. They can and will be removed from the cache when sql needs the room for something else. If this data is pretty constant maybe you could use a table to hold the results instead of running your proc repeatedly.
_______________________________________________________________
Need help? Help us help you.
Read the article at
http://www.sqlservercentral.com/articles/Best+Practices/61537/
for best practices on asking questions.
Need to split a string? Try Jeff Moden's
splitter
.
Cross Tabs and Pivots, Part 1 – Converting Rows to Columns
Cross Tabs and Pivots, Part 2 - Dynamic Cross Tabs
Post #1400292
GilaMonster
GilaMonster
Posted Wednesday, December 26, 2012 12:56 PM
SSC-Dedicated
Group: General Forum Members
Last Login: Today @ 2:54 AM
Points: 37,692,
Visits: 29,951
It's probably got nothing whatsoever to do with the cached execution plan. The optimiser is not allowed (in most cases) to spend minutes optimising a query.
What's probably causing the slow-down is having to re-load the data required for the procedure into the data cache. I'd guess that something like index rebuilds, checkDB or large data loads are done at night, hence displacing the data cache.
The solution here is to tune the query, it's probably requiring more data than it should due to inefficient queries or poor indexing and you mainly see the effects of that when the data has to be pulled from disk.
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 #1400344
Bhuvnesh
Bhuvnesh
Posted Thursday, December 27, 2012 2:42 AM
SSCrazy
Group: General Forum Members
Last Login: Tuesday, March 26, 2013 8:41 AM
Points: 2,562,
Visits: 3,451
GilaMonster (12/26/2012)
The optimiser is not allowed (in most cases) to spend minutes optimising a query.
Not allowed means? what i think is optimizer will take time to generate plan regardless of time boundation.please explain
-------Bhuvnesh----------
While 1 = 1 (Learning SQL....)
Click to get fast response of your post
Post #1400516
Kum@R marlapati
Kum@R marlapati
Posted Thursday, December 27, 2012 3:02 AM
Forum Newbie
Group: General Forum Members
Last Login: Monday, May 13, 2013 5:41 AM
Points: 2,
Visits: 42
ok
Post #1400527
GilaMonster
GilaMonster
Posted Thursday, December 27, 2012 3:04 AM
SSC-Dedicated
Group: General Forum Members
Last Login: Today @ 2:54 AM
Points: 37,692,
Visits: 29,951
Bhuvnesh (12/27/2012)
what i think is optimizer will take time to generate plan regardless of time boundation.
You would be thinking incorrectly then. Google: optimiser 'reason for early termination'
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 #1400529
SQL Show
SQL Show
Posted Thursday, December 27, 2012 3:33 AM
SSC Veteran
Group: General Forum Members
Last Login: Today @ 12:57 AM
Points: 299,
Visits: 484
WangcChiKaBastar (12/26/2012)
when I run the proc tomorrow it again takes forever to complete...and the applications time out on the front end...
to resolve the time out I have to manually go to SSMS run the stored proc..and then applications have no issue for the rest of the day.
my question is why is the Query execution plan getting flushed/lost next day ?
the data doesnt change much and not at all some times....
Check Sql Error log to find what cleared your plan cache.There you can see some error messages like below.
QL Server has encountered 1 occurrence(s) of cachestore flush for the 'Object Plans' cachestore (part of plan cache) due to "" Operation.
Post #1400538
GilaMonster
GilaMonster
Posted Thursday, December 27, 2012 3:40 AM
SSC-Dedicated
Group: General Forum Members
Last Login: Today @ 2:54 AM
Points: 37,692,
Visits: 29,951
dbasql79 (12/27/2012)
Check Sql Error log to find what cleared your plan cache.There you can see some error messages like below.
QL Server has encountered 1 occurrence(s) of cachestore flush for the 'Object Plans' cachestore (part of plan cache) due to "" Operation.
That only logs complete clearing of the cache, not if single plans are aged out or invalidated.
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 #1400539
Bhuvnesh
Bhuvnesh
Posted Thursday, December 27, 2012 5:04 AM
SSCrazy
Group: General Forum Members
Last Login: Tuesday, March 26, 2013 8:41 AM
Points: 2,562,
Visits: 3,451
GilaMonster (12/27/2012)
Bhuvnesh (12/27/2012)
what i think is optimizer will take time to generate plan regardless of time boundation.
You would be thinking incorrectly then. Google: optimiser 'reason for early termination'
will this option also return value when first time exec plan get created ?
is this option gives the value of 'reason for early termination' when query tried to use same plan for last time ? like if we get "timed out" , does that mean that query coudnt able to generate new plan and used plder one ?
-------Bhuvnesh----------
While 1 = 1 (Learning SQL....)
Click to get fast response of your post
Post #1400564
GilaMonster
GilaMonster
Posted Thursday, December 27, 2012 5:13 AM
SSC-Dedicated
Group: General Forum Members
Last Login: Today @ 2:54 AM
Points: 37,692,
Visits: 29,951
Bhuvnesh (12/27/2012)
will this option also return value when first time exec plan get created ?
Yes
is this option gives the value of 'reason for early termination' when query tried to use same plan for last time ? like if we get "timed out" , does that mean that query coudnt able to generate new plan and used plder one ?
No. Did you do the research?
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 #1400569
« Prev Topic
|
Next Topic »
14 posts, Page 1 of 2
1
2
»»
Permissions
You
cannot
post new topics.
You
cannot
post topic replies.
You
cannot
post new polls.
You
cannot
post replies to polls.
You
cannot
edit your own topics.
You
cannot
delete your own topics.
You
cannot
edit other topics.
You
cannot
delete other topics.
You
cannot
edit your own posts.
You
cannot
edit other posts.
You
cannot
delete your own posts.
You
cannot
delete other posts.
You
cannot
post events.
You
cannot
edit your own events.
You
cannot
edit other events.
You
cannot
delete your own events.
You
cannot
delete other events.
You
cannot
send private messages.
You
cannot
send emails.
You
may
read topics.
You
cannot
rate topics.
You
cannot
vote within polls.
You
cannot
upload attachments.
You
may
download attachments.
You
cannot
post HTML code.
You
cannot
edit HTML code.
You
cannot
post IFCode.
You
cannot
post JavaScript.
You
cannot
post EmotIcons.
You
cannot
post or upload images.
Copyright © 2002-2013 Simple Talk Publishing. All Rights Reserved.
Privacy Policy.
Terms of Use.
Report Abuse.
