Увеличение времени ожидания вызова хранимой процедуры LINQ to SQL

Question

Я вызываю хранимую процедуру через Linq-to-SQL. Эта хранимая процедура просто обрабатывает данные, которые я уже вставил в другую таблицу. На больших наборах данных я получаю исключение тайм-аута:

"Timeout expired. The timeout period elapsed prior to completion of the operation
 or the server is not responding."

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

Это не веб-приложение; хранимая процедура вызывается из фонового потока в обычной службе Windows. Фоновый поток запускается вызовом WCF, и клиент периодически запрашивает результат фонового потока.

К сожалению, хранимая процедура занимает слишком много времени, и вызов GetDataContext().spRunStoredProcedure() выдает TimeoutException, хотя хранимая процедура работает нормально.

Можно ли увеличить время ожидания только для этого вызова хранимой процедуры? Или есть способ заставить хранимую процедуру возвращать «Я еще не умер», чтобы предотвратить тайм-аут соединения?

Answer 1

В DataContext установите для свойства .CommandTimeout гораздо большее значение секунд. Значение по умолчанию для SQL Server составляет 30 секунд, и вы можете установить его на 0, чтобы оно не превышало тайм-аут.

Answer 2

Поскольку речь идет о перемещении данных, и поскольку на самом деле это занимает так много времени, что время ожидания истекает: может ли это быть решением, чтобы убрать это из Интернета и сделать это запланированным заданием SQL?

Кроме этого, действительно, нет запросов, которые нельзя оптимизировать; особенно не среди тех, кто перестал Увеличение времени ожидания не очень хорошее решение. Даже перемещение данных из одной таблицы в другую обычно может быть довольно поспешным. Посмотрите на ваши индексы, как вы выбираете данные, ваши блокировки и вашу статистику. Запустите запрос, который обычно является длинным, в Management Studio с включенным планом выполнения, и посмотрите, что отвечает за большую часть нагрузки (обычно он может быть сведен к одному или двум факторам узкого места), и посмотрите, есть ли что-нибудь, что вы можете сделать о них.