December 26, 2017 at 9:50 am
Running Idera DM and got some alerts for high signal waits and cpu was at 40 (usually 12)%. Found sp which runs all the time and looked fine but was killing it. Recompiled sp and problem fixed. Question is never seen high signal waits (over 12000 MS). Anyone seen (I am guessing query plan went off the rails after index rebuild) this signal wait cause serious issues?
December 26, 2017 at 10:06 am
tcronin 95651 - Tuesday, December 26, 2017 9:50 AMRunning Idera DM and got some alerts for high signal waits and cpu was at 40 (usually 12)%. Found sp which runs all the time and looked fine but was killing it. Recompiled sp and problem fixed. Question is never seen high signal waits (over 12000 MS). Anyone seen (I am guessing query plan went off the rails after index rebuild) this signal wait cause serious issues?
There's no way to know without knowing more about it, but my first guess would be the bad kind of parameter sniffing. If you rebuilt the index, the engine generates a new plan the next time it runs. If that query was fired with a non-typical value, you may have been using a sub-optimal plan for the typical runs of the query. When you recompiled your procedure, it invalidated the plan again and it sounds like you got a typical value that resulted in a better plan for the majority of your executions.
Like I said, this is just a guess and there's no way to know without a whole lot more information.
December 26, 2017 at 12:26 pm
seen this before after an index rebuild, plan becomes a mess, the sql and the indexes did not change, write it off as a feature of MS
December 28, 2017 at 4:18 am
Bad parameter sniffing, or some form of unstable plan. Almost always the result of the way stored procedures are written, and fixable by making sure that procedures only have one possible stable plan.
These are three of the more common causes I've seen, plus the theory as to why this happens: https://www.red-gate.com/simple-talk/sql/t-sql-programming/how-to-confuse-the-sql-server-query-optimizer/
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
December 28, 2017 at 6:33 am
problem is this is a 3rd party app, no re-write possible (it is bad code) but has not changed in 2 years. However recompiling the bad stored proc did solve problem
December 28, 2017 at 7:15 am
Recompiling it made the problem go away temporarily. It hasn't fixed it. Fixing will require changing the code or using plan guides or query store forced plans (if an upgrade to SQL 2016 is an option) to ensure there's only one possible plan choice for the procedure.
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
December 28, 2017 at 7:52 am
already in plan to upgrade
Viewing 7 posts - 1 through 6 (of 6 total)
You must be logged in to reply to this topic. Login to reply