SqlDataAdapter.Fill() Тайм-аут - базовый Sproc Возвращает быстро

Question

У меня есть SqlDataAdapter, который заполняется 21 строкой данных (4 столбца). Sproc, который управляет им, возвращается через пару секунд в SQL Mgmt Studio, но .Fill() занимает 5 минут.

ArrayList ret = new ArrayList(); 
    SqlDataAdapter da = null; 
    SqlCommand cmd = null; 
     cmd = base.GetStoredProc("usp_dsp_Stuff"); //Returns immediately in MSSMS. 
     cmd.CommandTimeout = 3600; // Set to 6 min - debug only 
     base.AddParameter(ref cmd, "@Param1", ParameterDirection.Input, SqlDbType.BigInt, 8, 19, 0, theParam1); 
     base.AddParameter(ref cmd, "@Param2", ParameterDirection.Input, SqlDbType.BigInt, 8, 19, 0, theParam2); 
     base.AddParameter(ref cmd, "@Param3", ParameterDirection.Input, SqlDbType.Char, 1, 'C'); 
     da = new SqlDataAdapter(cmd); 
     DataTable dt = new DataTable(); 
     da.Fill(dt); //Takes 5 minutes. 

Любые идеи?

Заранее благодарен! -Chris

Answer 1

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

Используйте SQL Profiler для определения того, что действительно отправляет SQL .NET при выполнении Fill().

Если посылает много операторов SET, такие как

 
set concat_null_yields_null on 
set cursor_close_on_commit off 
set implicit_transactions off 

etc... 

.. затем положить те же набор заявлений в хранимую процедуру может ускорить процесс.

Answer 2

Благодарим за помощь. Решение этой проблемы в том, чтобы дополнить (NOLOCK) отчетность на стыках, что sproc использовал:

ОТ category_tbl с внутренним соединением dbo.categoryItem_LNK сл С (NOLOCK) ПО c.categoryid = cl.categoryid

Я не знаю, почему мы рассматривали ухудшение при использовании SqlDataAdapter, но это изменило проблему сразу.

Еще раз спасибо, Крис

Answer 3

Я ненавижу разорвать новости, но (NOLOCK) не является решением проблемы, он просто создает new problems, такие как грязное чтение, отсутствуют/дублированные данные, и даже прерванные запросы. Замки в базе данных SQL - ваш друг.

Если блокировка (или, что еще хуже, блокировка) заставляет ее работать медленно, вы сравниваете параметры соединения, выполняемые через SSMS, и те, которые используются вашим приложением. Используйте SQL Profiler, чтобы узнать, как выполняется код.

Если какое-либо из этих полей является крупным объектом, имейте в виду, что SSMS автоматически извлекает только несколько сотен символов по умолчанию. Дополнительные данные могут быть фактором.

Answer 4

Плохие планы запросов и параметры нюхания. Для хранимой процедуры, и особенно в тех случаях, когда параметры будут дико настраивать прочитанные строки, причиной является неправильный план выполнения от поиска входящих параметров. Это не происходит в SQL Management Studio из-за разных параметров SET.

Эта нить суммирует проблему красиво: http://social.msdn.microsoft.com/Forums/en-US/transactsql/thread/9fd72536-f714-422a-b4c9-078e2ef365da/

Это типичный случай параметра фырканье. Ваша заявка, скорее всего, работает с различными параметрами SET (набор API-интерфейсом клиента) и использует другой план выполнения , чем один , созданный в SSMS. Что происходит, когда ваша процедура вызывает первое раз через ваше приложение создает план выполнения на основе параметров .Однако этот план выполнения может быть неприемлем для другого набора параметров , что может привести к ухудшению производительности при выполнении другого набора параметров . См следующие для более подробной информации и различных решений: http://pratchev.blogspot.com/2007/08/parameter-sniffing.html

Вот еще на внутренностях кэширования плана и повторное использование плана запроса:
http://technet.microsoft.com/en-us/library/cc966425.aspx

Answer 5

Я знаю, что это слишком поздно, как 7 лет слишком поздно! но сегодня я столкнулся с этой проблемой и хотел поделиться своим решением. В моем случае данные, которые были вытащены из SQL, были табличной функцией. Функция с оценкой таблицы возвращала только около 3500 строк и занимала менее 1 секунды, но она была рассчитана на Fill() в коде C#. Я не знаю, кто и как это работает, но сброс и повторное создание функции исправили ее. Я думаю, что это как-то связано с тем, как .NET читает данные, данные SQL, подобно тому, как нужно просматривать представление, если вы вносите изменения в него после того, как он использовался в отчете. Опять я, м, не на 100% уверен, Что происходит за кулисами, но для меня это было быстро исправить

Answer 6

da = new SqlDataAdapter(cmd); 
da.SelectCommand.CommandTimeout = 1800;