Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
 SOS_SCHEDULER_YIELD  [new]
beginner_dba
Member

Откуда: Киев
Сообщений: 331
Сегодня запрос, который ранее выполнялся 30 секунд, висит уже около 2 часов.
Процедура sp_who возвращает статус runnable
табличка sysprocesses возвращает вот такое вот значение.
Что можно предпринять?
7 апр 11, 13:02    [10485065]     Ответить | Цитировать Сообщить модератору
 Re: SOS_SCHEDULER_YIELD  [new]
Crimean
Member

Откуда:
Сообщений: 13147
кильнуть, обновить статистики, запустить опять
вэлкам в клуб любителей оптимизатора
7 апр 11, 13:53    [10485591]     Ответить | Цитировать Сообщить модератору
 Re: SOS_SCHEDULER_YIELD  [new]
beginner_dba
Member

Откуда: Киев
Сообщений: 331
Crimean
кильнуть, обновить статистики, запустить опять
вэлкам в клуб любителей оптимизатора


Так и делаю. Еще устанавливаю последний хот-фикс
7 апр 11, 14:49    [10486070]     Ответить | Цитировать Сообщить модератору
 Re: SOS_SCHEDULER_YIELD  [new]
beginner_dba
Member

Откуда: Киев
Сообщений: 331
Проблема решилась после обновления статистки. Интересно, но все ж таки, что было?
7 апр 11, 15:28    [10486371]     Ответить | Цитировать Сообщить модератору
 Re: SOS_SCHEDULER_YIELD  [new]
Crimean
Member

Откуда:
Сообщений: 13147
beginner_dba
Проблема решилась после обновления статистки. Интересно, но все ж таки, что было?


любят 2005 и 2008 (особенно) свалить запрос в абсолютно невменяемый план и долго-долго выполнять его. внешне при этом процесс немеряно жрет проц, практически не жрет диск и работает часами. хорошо, если там в цикле хранимка выполняется - можно сделать sp_recompile и со следующей итерацией все стабилизируется, но если это просто один стейтмент - приплыли, ждать нереально, когда отработает..
7 апр 11, 15:41    [10486475]     Ответить | Цитировать Сообщить модератору
 Re: SOS_SCHEDULER_YIELD  [new]
beginner_dba
Member

Откуда: Киев
Сообщений: 331
Crimean
beginner_dba
Проблема решилась после обновления статистки. Интересно, но все ж таки, что было?


любят 2005 и 2008 (особенно) свалить запрос в абсолютно невменяемый план и долго-долго выполнять его. внешне при этом процесс немеряно жрет проц, практически не жрет диск и работает часами. хорошо, если там в цикле хранимка выполняется - можно сделать sp_recompile и со следующей итерацией все стабилизируется, но если это просто один стейтмент - приплыли, ждать нереально, когда отработает..

Это проблема решается, если еженедельно обновлять статистику?
7 апр 11, 19:02    [10487916]     Ответить | Цитировать Сообщить модератору
 Re: SOS_SCHEDULER_YIELD  [new]
Crimean
Member

Откуда:
Сообщений: 13147
личная рекомендация - обновлять статистику "принудительно" по всем таблицам раз в день. я это делаю через + sp_msforeachtable. несколько раз в день - через sp_updatestats, она обновляет только то, что нужно
автообновление в моем случае неактуально, но в некоторых ситуациях может помочь и оно
на самом деле обновление нужно подстраивать под характер нагрузки и статистики добавления / модификации данных
7 апр 11, 20:02    [10488130]     Ответить | Цитировать Сообщить модератору
 Re: SOS_SCHEDULER_YIELD  [new]
beginner_dba
Member

Откуда: Киев
Сообщений: 331
Судя по документации, данный статус означает, что "задача добровольно стоит в очереди к планировщику". План был построен, правда ворк тайм был самый максимальный, но он был.
Собственно вопрос в чем: почему при построенном плане, в котором указано 38 сек. работы, без обновления статистики запрос входил в ступор. Это проблема в кривом запросе? или это проблема в огрехах оптимизатора? Почему когда я обновил статистику все нормально заработало. Что мешало оптимизатору сделать нормальный план при не обновленной статистке?
7 апр 11, 22:33    [10488641]     Ответить | Цитировать Сообщить модератору
 Re: SOS_SCHEDULER_YIELD  [new]
beginner_dba
Member

Откуда: Киев
Сообщений: 331
Crimean
личная рекомендация - обновлять статистику "принудительно" по всем таблицам раз в день. я это делаю через + sp_msforeachtable. несколько раз в день - через sp_updatestats, она обновляет только то, что нужно
автообновление в моем случае неактуально, но в некоторых ситуациях может помочь и оно
на самом деле обновление нужно подстраивать под характер нагрузки и статистики добавления / модификации данных


sp_msforeachtable -это обновление всех таблиц с игнорированием "не нуждается", а sp_updatestat - только, что нужно верно?
В 2005 SQL Server вышеназванной проблемы не было почему-то, про SOS.
16 апр 11, 08:27    [10527452]     Ответить | Цитировать Сообщить модератору
 Re: SOS_SCHEDULER_YIELD  [new]
Knyazev Alexey
Member

Откуда: Екб -> Мск
Сообщений: 10233
Блог
beginner_dba
Почему когда я обновил статистику все нормально заработало. Что мешало оптимизатору сделать нормальный план при не обновленной статистке?


план строится по статистике, для устаревшей статистики может и был "нормальный план"
16 апр 11, 12:05    [10527664]     Ответить | Цитировать Сообщить модератору
 Re: SOS_SCHEDULER_YIELD  [new]
beginner_dba
Member

Откуда: Киев
Сообщений: 331
Knyazev Alexey
beginner_dba
Почему когда я обновил статистику все нормально заработало. Что мешало оптимизатору сделать нормальный план при не обновленной статистке?


план строится по статистике, для устаревшей статистики может и был "нормальный план"


А что собственно в себе хранит статистка?
16 апр 11, 13:10    [10527828]     Ответить | Цитировать Сообщить модератору
 Re: SOS_SCHEDULER_YIELD  [new]
step_ks
Member

Откуда:
Сообщений: 936
Использование статистики для повышения производительности запросов

Использование статистики оптимизатором запросов Microsoft SQL Server 2005
16 апр 11, 14:20    [10527978]     Ответить | Цитировать Сообщить модератору
 Re: SOS_SCHEDULER_YIELD  [new]
juwdoks
Member

Откуда:
Сообщений: 144
Похожая ситуация. Сегодня второй раз за неделю появился висящий запрос, который все время runnable c Wait Type = SOS_SHEDULER_YIELD. Неделю назад решения не нашли, снять процесс получилось только перезагрузкой сервера. Сейчас обновили статистику чтобы такое больше не повторялось, но как все-таки снять этот самый процесс? Вызов был от linked сервера, попробовали и на linked и на local сделать kill, они встали на KILLED/ROLLBACK и продолжают висеть, кушая cpu. Сам запрос - хранимка с набором селектов (такой же запрос, как в этом процессе, выполняется мгновенно, если просто его прогнать).

По выборке из sys.dm_exec_requests приложил к посту результат и красным выделил проблемную строчку.
select wait_type, wait_time, blocking_session_id,  * from sys.dm_exec_requests
where wait_time>0

Можно как-то снять этот процесс?

В Activity Monitor у этого процесса Net Address стоит 000000000000, но хост видно правильно.
В приложенном файле еще добавил строку с данными Activity Monitor по хранимке sp_WhoIsActive от Adam Machanic.

К сообщению приложен файл (wait_time.xlsx - 13Kb) cкачать
12 ноя 11, 15:34    [11586906]     Ответить | Цитировать Сообщить модератору
Все форумы / Microsoft SQL Server Ответить