Есть ли ошибка или ограничение в LINQ to SQL, которое может привести к превышению времени ожидания хранимых процедур?

Question

Я использую .NET Framework 4.0, C # и SQL Server 2008 R2 в Windows Server 2008 R2.Мой контекст данных LINQ to SQL находится в отдельной библиотеке, а соответствующий код выполняется в службе Windows.

У меня есть хорошо протестированная, критически важная хранимая процедура, которая принимает около 19 параметров (я знаю, что язнать), выполняет некоторую простую логику «если», строит несколько переменных и вставляет данные в 3 таблицы.Он не использует курсоры или временные таблицы.Я описал, что делает SP, поскольку я не вправе публиковать код sql.

Я вижу много сообщений в Интернете о SqlException из-за тайм-аута команды, и ответы редко выходят за рамкиmsgstr "увеличить время ожидания команды". Пример

Я получил вышеупомянутое исключение, поэтому попытался увеличить время ожидания команды при создании контекста данных до 10 минут .Я все еще получаю исключение после того, как он сидел там в ожидании этих 10 минут.Затем я добавил журналы отладки для захвата вывода из LINQ to SQL и запустил SP в SQL Server Management studio с теми же значениями параметров.Он успешно завершился за долю секунды .

Вот вывод LINQ to SQL Log (с таймаутами по умолчанию), смешанный с некоторыми другими выводами журнала, я запутал SPимя в этом сообщении:

16:01:37 15269 Irrelevant log line, deleted for StackOverflow
EXEC @RETURN_VALUE = [dbo].[NAMEHIDDENONSTACKOVERFLOW] @Eastings = @p0, @Northings = @p1, @Speed = @p2, @UpdateDate = @p3, @UserId = @p4, @Postion = @p5, @Direction = @p6, @VehicleId = @p7, @Status = @p8, @Confidence = @p9, @Latitude = @p10, @Longitude = @p11, @PosLatitude = @p12, @PosLongitude = @p13, @WatchBoxId = @p14, @LastWatchBoxId = @p15, @WatchBoxIdAlert = @p16, @ImbolizationState = @p17, @TowAwayAlertState = @p18
-- @p0: Input Int (Size = -1; Prec = 0; Scale = 0) [560120]
-- @p1: Input Int (Size = -1; Prec = 0; Scale = 0) [5754714]
-- @p2: Input Int (Size = -1; Prec = 0; Scale = 0) [0]
-- @p3: Input DateTime (Size = -1; Prec = 0; Scale = 0) [02/08/2011 20:45:08]
-- @p4: Input Int (Size = -1; Prec = 0; Scale = 0) [11]
-- @p5: Input NVarChar (Size = 4000; Prec = 0; Scale = 0) [Swindon United Kingdom]
-- @p6: Input NVarChar (Size = 4000; Prec = 0; Scale = 0) [5]
-- @p7: Input Int (Size = -1; Prec = 0; Scale = 0) [15269]
-- @p8: Input Int (Size = -1; Prec = 0; Scale = 0) [901]
-- @p9: Input Int (Size = -1; Prec = 0; Scale = 0) [0]
-- @p10: Input Float (Size = -1; Prec = 0; Scale = 0) [51.939899]
-- @p11: Input Float (Size = -1; Prec = 0; Scale = 0) [-2.125414]
-- @p12: Input Float (Size = -1; Prec = 0; Scale = 0) [51.9333333]
-- @p13: Input Float (Size = -1; Prec = 0; Scale = 0) [-2.1]
-- @p14: Input Int (Size = -1; Prec = 0; Scale = 0) [-1]
-- @p15: Input Int (Size = -1; Prec = 0; Scale = 0) [-1]
-- @p16: Input Int (Size = -1; Prec = 0; Scale = 0) [0]
-- @p17: Input Int (Size = -1; Prec = 0; Scale = 0) [0]
-- @p18: Input Int (Size = -1; Prec = 0; Scale = 0) [0]
-- @RETURN_VALUE: Output Int (Size = -1; Prec = 0; Scale = 0) [Null]
-- Context: SqlProvider(Sql2008) Model: AttributedMetaModel Build: 4.0.30319.1

16:02:23 0 Error in DoPoll 1 Timeout expired.  The timeout period elapsed prior to completion of the operation or the server is not responding.

Единственная подсказка, которую я получаю при поиске переполнения стека, заключается в том, что может быть проблема с чем-то, называемым «прослушивание параметров», но я все еще читаю эторазберись, о чем идет речь.

Это действительно критически важно, и я получу много хлопот, если он выйдет из строя, поэтому я испытываю желание откатить LINQ и вернуться к vanilla ADO.Мой вопрос: есть ли что-то не так с моим подходом (иначе говоря: я идиот?) Или есть какая-то проблема или ошибка в LINQ to SQL, которая может вызывать эту проблему?Есть ли что-нибудь, что я могу сделать, чтобы устранить это, или лучше вернуться к ванильному ADO?

Answer 1

Я сделаю предположение, что вы пытались увеличить время ожидания вашего контекста данных Linq, поскольку вы упомянули, что большинство найденных вами постов предположили, что.

Однако ...

В таких случаях, как этот, сбивает с толку многих людей, особенно веб-сервер, особенно если вы запускаете его на IIS7.выяснить, где что-то происходит, только чтобы исправить это за пять секунд, изменив значения времени ожидания для серверного приложения на панели управления IIS7.

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

Если вы хотитечтобы попробовать, войдите на компьютер, на котором работает веб-сервер, разверните сервер / веб-сайт в левой панели, чтобы перейти к приложению, из которого запущен ваш сохраненный процесс.

На данный момент у вас есть несколько мест, чтобы посмотреть.Если вы вернетесь на уровень веб-сайта EG: «Веб-сайт по умолчанию» и щелкните по нему, а затем щелкните по расширенным настройкам в крайнем правом углу и откроете пределы подключения, вы можете установить количество секунд для всего веб-сайта.

Если вы вызываете своего SP из классического файла ASP, щелкните свое веб-приложение и дважды щелкните значок ASP на центральной панели, разверните «Свойства ограничений» и измените значение времени ожидания сценария в соответствии с требованиями.

Наконец, если вы делаете это с помощью какой-либо операции CGI, щелкните свое веб-приложение, затем дважды щелкните CGI и измените время там.

Последнее, но не в последнюю очередь, если ни один изВ приведенной выше справке вы можете попробовать добавить следующий фрагмент XML-кода в файл web.config вашего приложения в соответствующем месте, чтобы контролировать время выполнения скрипта .NET:

    <system.web>
      <httpRuntime executionTimeout="180"/>
    <\system.web>

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

Answer 2

Я вернулся к vanila ADO и получил то же исключение, поэтому ответ должен быть «нет, это не ошибка LINQ to SQL».Я также рефакторинг SP в соответствии со статьями сниффинга параметров, и это не помогло.Поскольку код снова начал работать, я могу только представить, что это была временная системная проблема или сбой базы данных.В интересах других, у которых есть похожие проблемы и которые позже найдут этот вопрос с помощью поиска, я обновлю его, если найду что-нибудь еще, поскольку коллега вскоре протестирует код в другой системе.системная проблема;в частности, мой диск VMWare нуждался в дефрагментации.

(В соответствии с рекомендациями по метамоделию я должен опубликовать собственный ответ, а не обновить вопрос).

Answer 3

LINQ-to-SQL использует ванильный ADO.NET под одеялом.По крайней мере, что касается ADO.NET и SQL Server, вы не близки к тому, чтобы максимально увеличить количество параметров, которые они могут обработать.LINQ-to-SQL очень удобен для хранимых процедур, если хранимый процесс не делает ничего ужасного, например, создание динамического SQL внутри процесса или возврат результатов из временных таблиц.

Как вы создаетеваше сопоставление Linq-SQL для хранимых процедур?В SDK Visual Studio есть инструмент командной строки под названием «SQLMETAL», который создает .dbml и .cs и, если это указано переключателем командной строки, также отображает хранимые процедуры.Он достаточно анализирует хранимые процедуры, чтобы убедиться, что LINQ to SQL будет их обрабатывать, и выдаст вам сообщения об ошибках для хранимых процедур, которые не соответствуют его стандартам.Попробуйте запустить SQLMETAL и посмотрите, какие сообщения вы получаете.