Чувствительность к регистру при запросе SQL Server 2005 из .NET с использованием OleDB

Question

У меня есть запрос, который я выполняю из приложения .NET в базу данных SQL Server, и кажется, что он занимает довольно много времени (5+ минут). Я создал тестовое приложение в C #, чтобы попытаться увидеть, что говорит так долго (запрос должен вернуться быстро).

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

Кто-нибудь видел это раньше? Мне интересно, есть ли службы на нашем сервере (поскольку у коллеги есть такая же проблема) или на наших компьютерах.

Заранее спасибо за любую помощь в этом.

Пример кода ниже (Разница в первой строке запроса в конце (fk_source и fk _Source):

//Original
    OleDbCommand comm = new OleDbCommand("select min(ctc.serial_no) as MIN_INTERVAL from countstypecode ctc, source s, countstype ct, counts c where ct.value_id=c.value_id and s.c_id=ct.fk_source and " +
      "ct.timeinterval=ctc.typename and ct.timeinterval in ('15min','1h','1day') and c.time_stamp >=  CONVERT(datetime,'01-01-2008',105)  and c.time_stamp < " +
      "CONVERT(datetime,'01-01-2009',105)  and s.c_id = '27038dbb19ed93db011a315297df3b7a'", dbConn);

//Rebuilt
    OleDbCommand comm = new OleDbCommand("select min(ctc.serial_no) as MIN_INTERVAL from countstypecode ctc, source s, countstype ct, counts c where ct.value_id=c.value_id and s.c_id=ct.fk_Source and " +
      "ct.timeinterval=ctc.typename and ct.timeinterval in ('15min','1h','1day') and c.time_stamp >= CONVERT(datetime,'01-01-2008',105) and c.time_stamp < " +
      "CONVERT(datetime,'01-01-2009',105) and s.c_id='27038dbb19ed93db011a315297df3b7a'", dbConn);

Answer 1

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

Ради интереса я проверил кэш процедур, выполнил запрос adhoc, еще раз проверил, затем запустил тот же запрос с другой капитализацией, и я был удивлен, увидев число процедур выше.

Попробуйте это ....

Подключение к SQL Server Management Studio.

DBCC MemoryStatus

Select Columns... From TABLES.... Where....

dbcc MemoryStatus

Select Columns... From tables.... Where....

dbcc MemoryStatus

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

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

Answer 2

Я не вижу различий в ваших запросах, которые могут повлиять на производительность - как насчет кэширования или изменений индекса / статистики между запусками? План выполнения мог измениться из-за статистики или изменений индекса.

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

Answer 3

Поскольку вы используете SQL Server 2005, пробовали ли вы использовать объект SqlCommand вместо объекта OleDbCommand?

Answer 4

Спасибо G Mastros за самый полный ответ, хотя в ретроспективе Cade предложила обновить статистику. Однако решение G Mastos лучше соответствовало моему уровню опыта работы с SQL Server.

Спасибо за помощь всем!

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

Answer 5

спасибо за все ваши ответы, я отвечу на каждый по очереди:

1) Расс, я согласен, что SQLConnection будет лучше, но, к сожалению, я не могу установить тип соединения. Я только что создал небольшое приложение для проверки этого запроса, но запрос динамически создается в гораздо большем приложении.

2) gbjbaanb, это не проблема сервера, я думаю, потому что я могу выполнить оба запроса из студии управления примерно в одно и то же время, это только проблема, если запустить через oledb в .net (1.1 и 2.0) , Мы запустили на нем профилировщик, и файл трассировки подтвердил, что для выполнения запроса при таком вызове потребовалось более 5 минут.

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

4) Cade Roux, разница очень воспроизводима, поэтому я не думаю, что это проблема с изменениями индекса или кэшированием, так как я запускал тесты с одинаковыми результатами и занимал примерно одинаковое время в SQL Server для запуска.

Answer 6

Если бы у меня был запрос, который занимал "5+ минут", я бы не беспокоился о тех 100 миллисекундах, которые требуются, чтобы соответствовать регистру строки.

Answer 7

во-первых, вы на 100% уверены, что запрос идет неправильно? Проверьте профиль трассировки на сервере sql и посмотрите, сколько времени он занимает в БД.

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