2012-01-16 2 views
0

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

Отчет представляет собой простой простой выбор из SQL, возвращающий приблизительно 25 столбцов, , а наш диапазон дат может быть 3-6 месяцев, возвращаясь вокруг строк 10k, поэтому мы не говорим о большом количестве данных.

Вот Что происходит, когда отчет запускается, то таймаут с нашего сайта, в консоли, это занимает от 13-18 минут до конца, ждать, кажется, происходит в

da.Fill(ds);

сейчас это странная вещь, она работает примерно 1-3 секунды в SQL Server Management Studio, и когда наши разработчики Delphi создают аналогичное приложение, это также займет несколько секунд, это происходит только с использованием .NET.

Мы попробовали переход от набора данных к загрузке в datareader, с использованием этого кода.

 
using (var dr = _command.ExecuteReader()) 
{ 
    if (dr.HasRows) 
    { 
    int i = 0; 
    while (dr.Read()) 
    { 
     var startRead = DateTime.Now; 
     Console.Write("{2}\t{0}\t{1}\t", dr.GetInt32(0), dr.GetString(1), i); 
     var tookRead = DateTime.Now.Subtract(startRead); 
     Console.WriteLine("Took: " + tookRead); 
     i++; 
    } 
}
Однако это не помогло, он просто отображается в патронах, но имеет частые задержки. Я думаю о его SQL, но не могу объяснить, почему он отлично работает в Delphi и в SQL Management Studio.

Я пробовал использовать .NET 2.0, 3.5 и 4, происходит во всех фреймворках.

Вот мой код

 
public static DataSet GetData() 
{ 
    var now = DateTime.Now; 
    var _command = new SqlCommand(); 
    var _connection = new SqlConnection(); 

    try 
    { 
    _connection.ConnectionString = connectionString; 

    _command.Connection = _connection; 
    _command.CommandText = storedProcedure; 
    _command.CommandType = CommandType.StoredProcedure; 
    _command.CommandTimeout = 60; 

    if (string.IsNullOrEmpty(_connection.ConnectionString)) { throw new Exception("Connection String was not supplied"); } 

    _command.Parameters.Add(new SqlParameter("DateFrom", dateFrom)); 
    _command.Parameters.Add(new SqlParameter("DateTo", dateTo)); 

    SqlDataAdapter da; 
    var ds = new DataSet(); 

    _connection.Open(); 

    var done = DateTime.Now; 

    da = new SqlDataAdapter(_command); 
    da.Fill(ds); 

    if (ds == null) { throw new Exception("DataSet is null."); } 
    if (ds.Tables.Count == 0) { throw new Exception("Table count is 0"); } 

    var took = done.Subtract(now); 

    return ds; 

    } 
    catch (Exception ex) 
    { 
    File.WriteAllText(Path.Combine(Application.StartupPath, String.Format("Exception{0:MMddyyyy_HHmmss}.log", DateTime.Now)), ex.ToString()); 
    } 
    finally 
    { 
    if (_connection.State != ConnectionState.Closed) { _connection.Close(); } 
    } 

    return null; 
} 

Любые идеи? Наша DBA винит рамки, я на самом деле что-то винить в SQL .. (может быть, статистика, или поврежденную дБ)

+0

Как вы думаете, что это SQL, если запрос выполняется отлично в SSMS? – JNK

+0

прокручиваются до последней строки в SQL Management studion после выполнения инструкции SQL? – Yahia

+1

Посмотрите эту тему: http://stackoverflow.com/questions/250713/sqldataadapter-fill-method-slow – granaker

ответ

0

предоставленная вами информация не содержит достаточно деталей, чтобы действительно помочь ...

IF SSMS действительно намного быстрее, чем причина может быть некоторым параметром сеанса/соединения. SSMS использует тонкие настройки по сравнению с .NET.

Для некоторого объяснения и намеки на то, что может быть различным/неправильно и т.д. см http://www.sommarskog.se/query-plan-mysteries.html

1

Различия в производительности SQL между .NET и другими клиентами (SQL Management Studio), как правило, вплоть до соединения быть настроены по-разному - частые виновниками являются ANSI_NULLS; ANSI_PADDING.

Попробуйте посмотреть, как настроено соединение в SQL Management Studio, а затем повторите то же самое в своем приложении .NET.

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