С какими тремя проблемами производительности вы сталкиваетесь с вашими серверами SQL?

Я студент из университета Фонтис в Эйндховене, и в настоящее время я провожу серию интервью, чтобы помочь с разработкой инструмента SQL Server, и я хотел бы получить отзывы от экспертов в этой области.

Один из моих вопросов:

С какими тремя проблемами производительности вы сталкиваетесь с вашими экземплярами SQL Server и как вы их идентифицируете?

Особенно меня интересуют сценарии и инструменты, используемые для измерения этого.

Сверху головы - три проблемы с запросами:

• Неявные преобразования
• Плохие стратегии индексации (слишком много или недостаточно или неправильный вид)
• Использование SELECT * вместо названия только нужных вам полей

Существует гораздо больше проблем, связанных с конфигурацией на уровне сервера, проблемами со схемой базы данных, проблемами с оборудованием и т. Д. Я написал скрипт для быстрого анализа серверов в поисках таких проблем:

http://www.brentozar.com/blitz/

• Плохой дизайн / запросы / индексация
• Не разрешено покупать правильное оборудование
• Braindead ORMs (он же «SQL мертв»)

Не топ-3, но думал, что упомяну еще не упомянутые вещи:

1. SQL ставится на виртуальные машины без каких-либо подробностей / прозрачности, предоставляемых администратору базы данных. Хост-сервер будет динамически изменять настройки гостевых машин, вызывая падение производительности и оставляя администратора базы данных без подсказки. Такие функции, как гиперпоточность, объединение в сеть и раздувание памяти, делают счетчики производительности движущейся целью для мониторинга.Tools: sysmon/perfmon, DMVs, maintaining a history of performance counters in tables.
2. Точно так же нет прозрачности / проверяемости настроек SAN, предоставленных администратору базы данных. У меня были LUN с различными настройками чтения / записи, но я сказал, что они все одинаковые.Tools: IO DMVs, SQLIO.
3. Плохая архитектура БД: как размер и размещение данных и файлов журналов, и база данных tempdb. Неправильное использование параллелизма. Создание нескольких файловых групп на одних и тех же физических дисках.Tools: experience.

Еще один инструмент, который я сейчас проверяю, это Project Lucy . Кажется аккуратным

• не хватает правильных показателей
• использование с nolock в productioncode кем-то, чтобы попытаться решить проблемы с производительностью. Особенно плохо, если код изменяет данные в таблицах
• Приложение выбирает больше данных, чем необходимо, в большее количество раз, чем необходимо. Например, двоичный файл возвращается каждый раз, даже если вы просто хотите получить текстовые данные из той же таблицы.

Запросы, которые плохо масштабируются (получают все заказы за X лет для всех клиентов и т. Д., Включая все строки заказов, включая суммированные данные и другие средние данные, плохо рассчитанные)

Просто запрашиваю все сразу.

Таблицы, содержащие «дескриптивные» поля varchar / text, которые необходимо искать в каждом запросе.

• Неправильное обслуживание, т. Е. Отсутствие переоценки индекса, статистики, резервного копирования журнала
• Отсутствующие индексы
• Плохо написанные запросы

• Плохая база данных и дизайн приложения
• слабое использование преимуществ платформы (разработчики хотели иметь зависящий от платформы код доступа к базе данных. Нет SP, нет функций и т. д.)
• плохая индексация, конечно.

• специальные запросы к данным о продуктах - да, разработчики считают, что это необходимо, а некоторые могут даже иметь доступ :-)
• плохой дизайн приложения, использующего базу данных - например: слишком много данных добавлено и никогда не удаляется, даже если в этом больше нет необходимости (что приводит к проблемам с производительностью, потому что резервные копии растут большими, задачи обслуживания занимают больше времени и т. д.)
• все файлы базы данных в одном и том же рейде или, что еще хуже, на одном диске (например, системные dbs, tempdb, пользовательские dbs все вместе на одном диске / raid)

• Плохой дизайн базы данных
• Плохая стратегия индексации (включая слишком много индексов, отсутствующие индексы и отсутствие обслуживания индексов)
• Плохие аппаратные архитектурные решения

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

1. Слишком много поездок в БД. Болтливость - одна из основных проблем с производительностью, которую я вижу.
2. Получение правильных границ транзакций. Выполнение каждой операции INSERT / UPDATE / DELETE может привести к значительному снижению производительности.
3. Неспособность оптимизировать аппаратную часть; в частности, размещение журнала БД на другом томе, чем данные БД.

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