Возможная бесконечная перекомпиляция была обнаружена для SQLHANDLE

10

Я нашел странные сообщения об ошибках в журнале ошибок SQL:

Bocss: один и тот же тупик происходит каждый час - требует расследования

Кроме того, множество перекомпиляций перечислены в журнале ошибок для других SPID согласно следующим примерам:

09/04/2015 14: 30: 10, spid64, Неизвестный, возможная бесконечная перекомпиляция была обнаружена для SQLHandle 0x0200000059631A288882589E0C54B76404CAE1B97E08D3680000000000000000000000000000000000000000 PlanHandle 0x0600040059631A2860A62B654100000001000000000000000000000000000000000000000000000000000000 начального смещение 1038 конечного смещения 2600. Причина последней перекомпиляции было 2. 09/04/2015 14:30:10 , spid150, Unknown, возможная бесконечная перекомпиляция была обнаружена для SQLHandle 0x02000000EF886F018C4E0B163812B8B20150FE8FC7E6A06A0000000000000000000000000000000000000000 PlanHandle 0x06000400EF886F01901A816E0600000001000000000000000000000000000000000000000000000000000000 начального смещения 998 конечного смещение 2520. причина последней перекомпиляции было 2. 09/04/2015 14: 30: 09, spid67, Unknown,Возможная бесконечная перекомпиляция была обнаружена SQLHandle 0x0200000057C4C632D9052275CFF2B683B80F29501EE91D730000000000000000000000000000000000000000 PlanHandle 0x0600040057C4C63200EAC2BE3000000001000000000000000000000000000000000000000000000000000000 начиная смещение 1064 конечное смещение 2652. Причина последней перекомпиляции было 2. 09/04/2015 14: 30: 09, spid163, Unknown, возможная бесконечная перекомпиляция была обнаружена для SQLHandle 0x02000000E7C7BF0E5D70DE55759C7842860272AD474D69AB0000000000000000000000000000000000000000 PlanHandle 0x06000400E7C7BF0EF0EB68A52C000000010000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 начальное смещение 1028 конечное смещение 2580. Последней причиной перекомпиляции было 2.

что могло вызвать это?

Похоже, у меня больше нет планов в кеше. введите описание изображения здесь

следуя совету этого поста http://www.sqlservercentral.com/Forums/Topic1479420-146-1.aspx

затем в качестве меры безопасности отключили полнотекстовые каталоги, это не имело никакого значения, поэтому я полностью откатил изменения (удалил новые объекты и т. д.). Это также не имело никакого значения, в конце концов, единственное, что, казалось, остановило его, это перезапуск экземпляров SQL, это немедленно решило проблему.

это также меня разобрало, но я все еще должен найти причину этого беспорядка?

Марчелло Миорелли
источник
2
Ваше сообщение об ошибке не означает, что план больше не находится в кеше. Я считаю, что вы неправильно скопировали дескриптор плана, и это либо одно значение слишком длинное, либо одно слишком короткое. Я могу запустить SELECTна с dm_exec_sql_textпомощью ручки , которая находится в сообщении об ошибке, не получив ошибку
Марк Sinkinson
+1 хорошо заметили
Марчелло Миорелли

Ответы:

11

Согласно сообщению Infinite о перекомпиляции в журнале ошибок в блоге группы разработчиков SQL Programmability & API, это сообщение запускается, когда оператор в пакете перекомпилируется 100 раз подряд.

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

Вам следует начать с определения оператора запуска по предоставленной информации и оценить его в контексте числового кода, указывающего причину перекомпиляции. В нескольких местах в Books Online есть таблица этих кодов и их значений, в том числе в классе событий SP: Recompile .

Более подробная информация доступна в разделе «Планирование кэширования и перекомпиляции» в SQL Server 2012 .

Таблица значений

Пол Уайт 9
источник