2009-02-05 3 views
6

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

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

Время ожидания истекло. Период таймаута , прошедший до завершения операции , или сервер не ответ. Заявление было завершено .

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

Ничего недавно не изменилось в моем db - мой тайм-аут по умолчанию является значением по умолчанию.

Любой ключ?

EDIT

стол против СФСА работает это огромное -> 15 Кабриолетов. Перезагрузите коробку - та же проблема, но на этот раз вы не можете запустить sp из Management Studio.

Спасибо!

+0

Работает ли он намного дольше, чем ожидалось? Или это просто, что он работает веками **, но завершает ** в анализаторе запросов? –

+0

работает очень быстро в студии управления, поэтому я не думаю, что установка тайм-аута поможет – JohnIdol

+0

Ну, вам нужно выяснить, заблокирован ли он, или если у вас плохой план выполнения ... –

ответ

2

ОК - это то, как я исправил его в конце.

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

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

+0

Был ли PK целочисленным? Если бы это было так, не было смысла кластеризовать последовательные данные (правильно?). У меня были ситуации в SQL2000, где таблица должна была быть полностью воссоздана до того, как индекс будет «исправлен», что даже удаление/переиндексация не может быть исправлена. – Adam

+0

Да, это было целое число - по умолчанию я был кластеризован по умолчанию (я не сделал это кластером явно) – JohnIdol

3

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

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

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

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

+0

Я занимаюсь довольно крупными транзакциями - все было хорошо до нескольких часов назад - не слишком уверенная настройка более высокого тайм-аута. – JohnIdol

+0

Вы можете установить его в 0, то есть он не будет тайм-аут –

+0

Кроме того, если его быстро в студии, возможно, транзакция блокирует его. вам нужно диагностировать с помощью sp_lock –

7

студии управления устанавливает бесконечное время ожидания для запросов/команд он работает. Соединение с базой данных из кода будет иметь таймаут по умолчанию, который вы можете изменить на command object.

+0

Вы можете проверить свойства соединения, настроив трассировку в SQL Server Profiler. Отсюда вы сможете увидеть используемый по умолчанию параметр таймаута, если значение не указано явно в вашем коде –

+0

Это довольно быстро работает в студии управления (менее 1 секунды), а в моем коде - это время через 30 секунд или около того. – JohnIdol

+0

Тайм-аут соединения и тайм-аут команды не следует путать, время соединения - это максимальное время, необходимое для подключения к db –

5

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

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

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

+1

Хороший вызов фальсификатора параметров, особенно применимый к SQL Server 2000. Я понимаю, что обнюхивание пармером не является проблемой в SQL Server 2005 и далее. Хорошая статья о том, как бороться с параметром sniffing здесь http://blogs.msdn.com/khen1234/archive/2005/06/02/424228.aspx –

+0

Параметр sniffing, безусловно, все еще проблема с SQL Server (вплоть до 2012 года включительно). Я смог легко воспроизвести его во всех версиях SQL. Объявление локальной переменной для каждого сохраненного параметра proc и установка Localparam1 = Param1 фиксирует таймауты в каждом экземпляре. Это беспокоило меня годами. – Mangist

+0

@ Мангист или просто используйте подсказку 'OPTIMIZE FOR' ... –

5

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

EDIT:

Для перекомпиляции прок, вы идете в студию управления, открытую процедуру для изменения и нажмите F5 или выполнить: EXEC sp_recompile «proc_name»

+0

стоит того! как это сделать? – JohnIdol

+0

Лучше всего использовать EXEC sp_recompile 'proc_name' –

+0

Я видел, как это произошло с представлениями, где они должны быть воссозданы после изменения исходной таблицы. Определенно стоит попробовать. – Adam

1

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

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

Также, сколько данных вы возвращаете? У нас были проблемы с плохо разработанным SQL в прошлом, которые не отображались до тех пор, пока совокупный отчет не начнет иметь больше данных в наборе результатов. Не зная, что у вас есть, сложно сказать, возможно ли это, но стоит отметить, что вы должны исследовать.

1

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

0

Получите профайлер SQL на нем, сравните результаты между запуском в студии управления и через приложение.

Смежные вопросы