Ужасная производительность чтения SQL (статистика обновления виновника?)

Question

Я работаю на SQL Server 2008 R2 и пытаюсь настроить производительность.Я сделал все от меня зависящее:

• Проверка кода кода SQL
• Создание или удаление индексов, если я считаю это целесообразным
• Автоматическое создание статистики ВКЛ
• Автоматическое обновление статистики ВКЛ
• Автоматическое обновление статистики асинхронное ВКЛ

У меня есть система 24/7, которая постоянно хранит данные.Иногда мы читаем, и вот в чем проблема.Иногда чтение занимает пару секунд или меньше (что было бы ожидаемым и приемлемым для нас).В других случаях считывание занимает несколько секунд, а до завершения хранимой процедуры может потребоваться до минуты, и мы визуализируем данные в пользовательском интерфейсе.

Если мы сделаем чтение еще раз, это будет быстрее.Профилировщик SQL будет отслеживать конкретную хранимую процедуру или запрос, который занимает несколько секунд.Мы бы приблизились к этой хранимой процедуре и сделали бы все возможное, чтобы оптимизировать ее, если сможем.

Я также проследил событие автоматической статистики и событие перекомпиляции.Трудно сказать, обновляется ли статистика, что приводит к длительному чтению, или перекомпиляция вызвала его.Иногда я вижу, что профилировщик отслеживает перекомпиляцию запроса на чтение, которая занимает несколько неприемлемых минут, в других случаях он не отслеживает перекомпиляцию.

Я пытался запретить оптимизатору запросов блокировать чтение, пока он не перекомпилируетили обновляет статистику, используя опцию использования плана XML и т. д. Но я столкнулся с ошибками компиляции, жалуясь на то, что план запроса XML недействителен;это может быть правдой, потому что запрос тихий: select + объединения, которые включают локальную таблицу var.Я вроде взломал XML и, возможно, поэтому он счел его недействительным.Поэтому я отказался от использования подсказки плана.

Мы пытались периодически (каждые 15 минут) запускать статистику обновления вручную, чтобы поддерживать статистику как можно более актуальной, но это ухудшало производительность.updatestats блокирует запись, и я уверен, что даже читает;updatestats, казалось, поддерживал кучу статистики, и в среднем это занимало около 80-90 секунд.Чтение, которое ждет так долго, недопустимо.

Таким образом, идея состоит в том, чтобы позволить чтению произойти и предотвратить ситуацию, когда статистика перекомпиляции / обновления блокирует его, правильно?Имеет ли смысл вообще отключать авто статистику?Или, возможно, отключить автоматическое создание статистики после удаления всех автоматически созданных статистических данных?

Возможно, это идет вразрез с рекомендациями Microsoft, так как они по умолчанию включают автоматическое создание статистики и автоматическое обновление статистики, и производительность может пострадать, но любые идеи / советыВы можете дать будет оценена.

Answer 1

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

1. Вы выполняете физическое чтение.Быстрый способ избежать этого - увеличить объем оперативной памяти, которую вы выбрасываете в коробку.Вы не упомянули технические характеристики вашего сервера.Пожалуйста, добавьте подробности.
2. Если вы отслеживаете вызовы SQL, вы можете легко выяснить, почему произошел РЕКОММЕНТ.Посмотрите на EventSubClass, чтобы выяснить причину и работать над ее устранением.ref: http://msdn.microsoft.com/en-us/library/ms187105.aspx
3. Вы упомянули переменные таблицы.Они печально известны тем, что вызывают проблемы с производительностью, когда НЕ используются в нужном месте.Если вы используете табличные переменные в JOIN, о параллельном плане не может быть и речи.Я НЕ уверен, как и где вы используете, но попробуйте заменить их временными таблицами.Начиная с SQL Server 2005, вы получите в лучшем случае только перекомпиляцию STMT, а НЕ полную перекомпиляцию SP, как это произошло в 2000 году.
4. Вы упомянули опцию Update Stats ASYNC, и это не заблокирует запрос.
5. Что такое TOP WAIT STATS на этом сервере?Определили ли вы дорогостоящие процедуры, основанные на ЦП, логических чтениях и количестве выполнений?
6. Вы смотрели ожидаемую продолжительность жизни страницы, количество операций ввода-вывода с использованием статистики виртуальных файлов DMV?
7. Обновление статистики каждые 15 минутНЕ хороший план.Как часто данные вводятся в систему?Какую частоту дискретизации вы используете?Какова ваша стратегия обслуживания индексов?
8. Вы смотрели на отсутствующие индексы DMV?

Существует множество хороших запросов для более детального выявления проблем с помощью приведенных ниже запросов.

ref: http://dl.dropbox.com/u/13748067/SQL%20Server%202008%20Diagnostic%20Information%20Queries%20%28April%202011%29.sql

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

Answer 2

Хорошо, вот мой ИМХО улов на этом:

• DBCC INDEXDEFRAG стоит попробовать и является функцией ONLINE, следовательно, может использоваться в реальной системе

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

• Обычный трюкpartitioningВы пишете в таблицу, чье распределение индекса выглядит совсем не так, как это было несколько часов назад, что снижает производительность.Это массовая запись, такую ​​таблицу можно разделить на ежедневную запись и остальные данные с ночными пакетами движущихся материалов.

• Все больше и больше людей обращаются к CQRS .Вы можете быть следующим.Это решает проблему, отделяя операции чтения от записи (очень упрощенное объяснение).