Проблема производительности хранимых процедур в SQL Server 2005

Question

У меня есть следующая проблема: когда из моего приложения вызывается сохраненный процесс, то время от времени (например, 1 раз из 1000 вызовов) для завершения требуется 10-30 секунд. Как правило, sproc работает менее чем за секунду. Это довольно простой процесс с одним выбором, который связывает несколько таблиц. Все имена таблиц устанавливаются с подсказкой (NOLOCK), поэтому она, вероятно, не блокируется. Все индексы тоже на месте, иначе все время будет медленным.

Проблема в том, что я не могу воспроизвести эту проблему в SSMS (поскольку она всегда выполняется за секунду), независимо от того, сколько раз он запускает sproc, но я вижу проблему, когда указываю профилировщику пользователю, который запускает мое приложение , План запросов в SSMS кажется правильным, но проблема сохраняется.

Куда мне идти отсюда? Как мне отладить эту проблему?

Answer 1

Некоторые опции:

• Что говорит профилировщик или SET STATISTICS xx ON? Есть ли просто ресурсное голодание, скажем CPU

• Двигатель решает, что статистика устарела. Изменяются ли таблицы на 10% (количество правил). Для проверки:

  SELECT
      name AS stats_name, 
      STATS_DATE(object_id, stats_id) AS statistics_update_date
  FROM
      sys.stats 
  WHERE
      object_id IN (OBJECT_ID('relevanttable1'), OBJECT_ID('relevanttable2'))
  

• Что еще происходит на сервере? пример: перестроение индекса: не блокирование, только ресурсоемкий.

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

Answer 2

• Автостранички в базе данных? Проверьте наличие сообщений в журналах ошибок SQL.
• Разделение страницы из-за вставленных записей? Проверьте фрагментацию таблицы с помощью DBCC SHOWCONTIG
• Антивирус сканирует? Не.
• Статистика устарела? Не полагайтесь на статистику автоматического обновления таблиц, которые сильно меняются.
• Не исключайте проблемы на стороне клиента или в сети между ними.
• Запуск профилировщика с фильтром по продолжительности, захват только событий с продолжительностью> 10 секунд, поиск шаблонов в параметрах, клиентах, времени суток.

Answer 3

Я бы настроил трассировку в SQL Server Profiler, чтобы увидеть, какие настройки параметров SET используются вашим приложением для подключения и какие настройки используются в SSMS. Под настройками параметров SET я имею в виду

ARITHABORT
ANSI_NULLS
CONCAT_NULL_YIELDS_NULL
//etc

Посмотрите на MSDN для таблицы параметров

Я уже видел проблему, когда параметры настройки, используемые SSMS и приложением, были разными (в данном конкретном случае это было ARITHABORT), а разница в производительности была огромной (фактически приложение определенно истекло запросы, в зависимости от значений параметров).

Здесь я бы рекомендовал начать расследование. Установив трассировку, вы сможете увидеть, какие конкретные вызовы занимают больше времени и какие параметры используются.

Answer 4

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

Я бы также следил за приведением типов данных. то есть я видел похожие проблемы, когда сравнивали параметр varchar (60) и индексировали данные varchar (80). В некоторых случаях, подобных этому, SQL Server теряет рассудок и заставляет сканировать, а не искать, хотя я полагаю, что в подобных случаях вы обычно видите, что такого рода вещи происходят в плане выполнения.

К сожалению, еще один потенциальный преступник (и я немного опасаюсь выбросить его, потому что это может быть красная сельдь) - гиперпоточность. Я видел, что это делало ОЧЕНЬ похожие вещи в прошлом [ 1 ].

1 http://sqladvice.com/blogs/repeatableread/archive/2007/02/13/Burned-again-by-HyperThreading-on-SQL-Server-2000.aspx

Answer 5

Вы абсолютно уверены, что это запрос к базе данных, а не какая-то другая смежная логика в вашем коде? (т. е. ставили ли вы отметки времени «следы» непосредственно перед и после?)

Answer 6

На медленных трассах есть что-нибудь другое в параметрах, передаваемых в proc?

Answer 7

У меня также похожая проблема с производительностью. Помогло добавление С RECOMPILE к SP.

Это не то решение, которое я искал, но пока не нашел лучшего ...

См: Низкая производительность SqlDataReader

Answer 8

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