Хранимые процедуры время от времени!

Question

У меня есть ряд хранимых процедур, которые я вызываю из кода с ExecuteNonQuery.

Все было хорошо, но 2 из моих хранимых процедур начали прерывисто сегодня с:

Истекло время ожидания. Период ожидания истекший до завершения операция или сервер не отвечать на запросы. Заявление было прекращено.

Если я выполню SP вручную из студии управления, все равно будет хорошо.

Ничего не изменилось в моей базе данных - тайм-аут команды по умолчанию.

Любая подсказка?

EDIT

таблица против SP работает, она огромна -> 15 гигов. Перезагрузил окно - та же проблема, но на этот раз не удается запустить sp из Management Studio.

Спасибо!

Answer 1

Management studio устанавливает бесконечное время ожидания для выполняемых запросов / команд. Ваше соединение с базой данных из кода будет иметь тайм-аут по умолчанию, который вы можете изменить в объекте команды .

Answer 2

Попробуйте перекомпилировать эти процедуры. У меня были такие проблемы несколько раз, и я не нашел причину проблемы, но перекомпиляция всегда помогает.

РЕДАКТИРОВАТЬ:

Чтобы перекомпилировать proc, перейдите в Management Studio, откройте процедуру для изменения и нажмите F5 или выполните: EXEC sp_recompile 'proc_name'

Answer 3

Это часто может относиться к:

• плохие планы запросов из-за чрезмерного повторного использования планов ( сниффинг параметров )
• различные параметры SET - в частности, ANSI_NULLS и CONCAT_NULL_YIELDS_NULL
• блокировка (у вас может быть более высокий уровень изоляции)
• индексирование необходимо перестроить / обновить статистику / etc

Параметры SET могут привести к невозможности использования определенных типов индексов (например, индексы для постоянных вычисляемых столбцов, включая «продвинутые» запросы xml / udf)

Answer 4

Установлен ли тайм-аут команды? Что-то изменилось в вашей базе данных, что заставляет этот процесс занимать больше времени?

Если вам нужно диагностировать проблемы с блокировкой, вам нужно будет использовать что-то вроде sp_lock.

Можете ли вы поделиться источником одного из ваших проков?

http://msdn.microsoft.com/en-us/library/system.data.sqlclient.sqlcommand.commandtimeout.aspx

Answer 5

Хорошо - так я исправил в конце.

Кластерный индекс таблицы с 45 миллионами записей убивал мой SQL-сервер - каждая вставка из кода приводила к неприятным таймаутам, описанным в ответе. Увеличение допустимого времени ожидания не решило бы мои проблемы с масштабируемостью, поэтому я поигрался с индексами и сделал кластеризованный индекс по первичному ключу некластеризованным , чтобы разблокировать ситуацию.

Буду признателен за комментарии по этому вопросу, чтобы лучше понять, как это решило проблему.

Answer 6

SQL Server будет ждать бесконечно, прежде чем вернуться к пользователю. Скорее всего, было установлено свойство тайм-аута на стороне клиента. Например, вы можете установить свойство timeout для объекта команды ADO .

Answer 7

Возможно, вам потребуется обновить статистику базы данных. Также изменилось ли недавно индексирование таблицы?

Проверьте план выполнения sp, чтобы увидеть, можете ли вы найти узкое место. Даже если раньше он работал нормально, его, вероятно, можно настроить для более эффективной работы.

Кроме того, сколько данных вы возвращаете? В прошлом у нас были проблемы с плохо спроектированным SQL, которые не появлялись, пока в сводном отчете не появилось больше данных в наборе результатов. Не зная, что делают ваши спы, трудно сказать, есть ли такая возможность, но стоит упомянуть, что вам стоит заняться расследованиями.

Answer 8

Получите на нем профилировщик SQL, сравните результаты между его запуском в Management studio и вашим приложением.