Comments on: SQL SERVER – SOS_SCHEDULER_YIELD – Wait Type – Day 8 of 28

By: prince rastogi

prince rastogi — Wed, 20 Mar 2013 15:58:59 +0000

Excessive CPU use may be the reason of Spinning and backoff..

By: Matt Newman

Matt Newman — Wed, 27 Feb 2013 20:47:08 +0000

Instead of dropping the procedure or blowing away the cache, you could first try exec sp_recompile [storedProcedureName]; to recompile the execution plan. Sounds like a potential parameter sniffing matter on your proc or change in statistics for your table when a better plan could be reached. Overall, sounds like a bad execution plan.

By: lasri

lasri — Sat, 23 Feb 2013 16:44:53 +0000

I had the same issue, and fixed by drop and create the sp
how this can be explained ?

By: Yassine, Lasri

Yassine, Lasri — Sat, 23 Feb 2013 16:43:34 +0000

I had the same situation and just fixed the issue by dropping and recreating the sp. what was behind ?

By: Bojan Jekic

Bojan Jekic — Thu, 21 Feb 2013 09:58:35 +0000

I have situation:
SP work good from query, but not work from Excel (sos_scheduler_yield).

I FOUND RESOLUTION !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
–> Just ReCreate this SP.

But, I can’t explain this? Pinal?

By: SQL SERVER – Weekly Series – Memory Lane – #015 « SQL Server Journey with SQL Authority

Sat, 09 Feb 2013 01:31:22 +0000

[...] SOS_SCHEDULER_YIELD – Wait Type – Day 8 of 28 [...]

By: firasatahmed

firasatahmed — Tue, 29 Jan 2013 22:42:45 +0000

You basically cleared the cache from your system. Most likely there must be a bad execution plan which occasionally works good for few values out of the sproc, could also be issue of parameter sniffing.

By: Bhavisha Patel

Bhavisha Patel — Sun, 15 Apr 2012 02:27:43 +0000

I have same issue in production while running SSI sin for each loop which query million of rows. I am seeing this king of wait in “last wait type” session is showing Insert as running ststement but count in table is 0. As soon i as I kill session everthing start working as it should….Please suggest.

By: stanleyjohns

stanleyjohns — Wed, 13 Jul 2011 20:02:16 +0000

I had this wait recently on one of our systems. Clients were reporting slow responses from the server. Doing a DBCC freeproccache and a DBCC freesystemcache fixed the issue.

By: BigDave

BigDave — Sun, 13 Feb 2011 11:30:20 +0000

I’ve often observed SOS_SCHEDULER_YIELD as “last_wait_type” instead of “wait_type”, where a unique session is consuming 100% of 1 cpu for hours (due to stale stats incurring nested loops between huge tables).
In this situation (no IO, lock, latch, network nor any other waits), SOS_SCHEDULER_YIELD is the only event waited on, which means… no wait all all, am I right ?