Производительность SQL Server и статистика обновлений - PullRequest
3 голосов
/ 17 августа 2010

У нас есть сайт в разработке, и, когда мы развернули его на рабочем сервере клиента, мы начали получать тайм-ауты запросов через пару часов.

Это было с одним пользователем, тестирующим его, и на нашем сервере (который идентичен с точки зрения номера версии Sql Server - 2005 SP3) у нас никогда не было той же проблемы.

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

Пару часов спустя возникла та же проблема. Поэтому мы снова вручную обновили статистику и снова проблема ушла. Мы проверили свойства базы данных и, конечно же, автоматическое обновление статистики - ИСТИНА.

В качестве временной меры мы поставили задачу периодически обновлять статистику, но ясно, что это не очень хорошее решение.

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

Мы рассмотрели установку SQL-сервера на их db-сервере, и это не то, что я бы назвал нормальным. Хотя у них установлен SQL 2005 (а не 2008), в каталоге установки есть пустая папка «100». Существует также MSQL.1, MSQL.2, MSQL.3 и MSQL.4 (где фактически хранятся исполняемые файлы и данные).

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

Большое спасибо

Tony

Ответы [ 2 ]

4 голосов
/ 17 августа 2010

Несогласие с Remus ...

Отслеживание параметров позволяет SQL Server угадывать оптимальный план для широкого диапазона входных значений.Иногда это неправильно, и план плохой из-за нетипичного значения или неправильно выбранного значения по умолчанию.

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

Обновление статистики приведет к аннулированию плана.Таким образом, запрос будет скомпилирован и кэширован при следующем использовании

Обходные пути являются следующими:

  • маскирование параметров
  • использование OPTIMIZE FOR UNKNOWN подсказка
  • дубликат "default"

См. Эти вопросы SO

Теперь Ремус работает в команде разработчиков SQL Server.Однако это явление хорошо задокументировано Microsoft на их собственном веб-сайте, поэтому обвинять разработчиков в несправедливости

4 голосов
/ 17 августа 2010

Разве статистика не устарела? Что происходит, когда вы обновляете статистику, все планы становятся недействительными, а некоторые плохо кэшированные планы выселяются. Все идет гладко, пока плохой план не будет снова кэширован и приведет к медленному выполнению.

Реальный вопрос - , почему у вас плохие планы , чтобы начать с? Мы можем получить длительные технические и философские аргументы о том, должен ли процессор запросов создавать плохой план для начала, но дело в том, что когда приложения написаны определенным образом, могут возникнуть плохие планы. Типичным примером является предложение where, например (@somevaribale is null) or (somefield= @somevariable). В конечном итоге 99% плохих планов можно отнести к разработчикам, пишущим запросы, которые имеют процедурное ожидание в стиле C вместо звуковой, основанной на множестве, реляционной обработки.

Что вам нужно сделать сейчас, это выявить неверных запросов. Это действительно просто, просто отметьте sys.dm_exec_query_stats, плохие запросы будут выделяться в терминах total_elapsed_time и total_logical_reads. После того, как вы определили неверный план, вы можете принять корректирующие меры, которые зависят от запроса к запросу.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...