Какие первые проблемы нужно проверить при оптимизации существующей базы данных?

Question

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

Я бы хотел разделить этот вопрос на следующие категории (в порядке интереса для меня):

1. нужно показать повышение производительности (улучшения) в кратчайшие сроки. то есть наиболее экономически эффективные методы / действия;
2. неинтрузивные или наименее хлопотные наиболее эффективные методы (без изменения существующих схем и т. Д.)
3. навязчивые методы

Обновление:
Предположим, у меня есть копия базы данных на компьютере разработчика без доступа к производственной среде для наблюдения статистики, наиболее часто используемых запросов, счетчиков производительности и т. Д. В реальном использовании.
Это вопрос, связанный с развитием, но не связанный с DBA.
Update2:
Предположим, что база данных была разработана другими и была передана мне для оптимизации (проверки) перед ее отправкой в ​​производство.
Обычно аутсорсинговая разработка отделена от конечных пользователей.

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

Update3: Спасибо всем ответчикам! Вы все подтолкнули меня на открытие подвопроса
Как вы локально загружаете базу данных разработчика (сервер)?

Answer 1

• Создание базового уровня производительности (не навязчивый, используйте счетчики производительности)

• Определение самых дорогих запросов (не навязчивый, используйте SQL Profiler)

• Определите наиболее часто выполняемые запросы (не навязчивый, используйте SQL Profiler)

• Определите любые слишком сложные запросы или те, которые используют медленно выполняемые конструкции илиузоры.(не навязчиво идентифицировать, использовать SQL Profiler и / или проверки кода; возможно, навязчиво при изменении может потребовать существенного повторного тестирования)

• Оценка вашего оборудования

• Определите индексы, которые будут полезны для измеряемой рабочей нагрузки (не навязчиво, используйте SQL Profiler)

• Измерьте и сравните с вашей базовой линией.

• Если у вас очень большие базы данных или экстремальные условия работы (например, круглосуточная работа или сверхвысокая загрузка запросов), обратите внимание на функции высшего класса, предлагаемые вашей СУБД, такие как разбиение таблиц / индексов.

Это может представлять интерес: Как мне войти в систему и найти самые дорогие запросы?

Answer 2

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

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

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

Итак, основные шаги ..

Предполагается, что вы ведете пожарную борьбу:

• журналы сервера
• Журналы SQL Server
• sys.sysprocesses, например, ASYNC_NETWORK_IO ожидает

Медленный ответ:

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

Вещи, которые вы должны иметь:

• Резервные копии
• Проверенное восстановление вышеупомянутых резервных копий
• Регулярное ведение индексов и статистики
• Регулярные проверки DBCC и целостности

Редактировать: после обновления

• Статический анализтолько лучшие практики: вы не можете оптимизировать для использования.Это все, что вы можете сделать.Это ответ marc_s.

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

• Во многих магазинах разработчики предоставляют некоторую поддержку, либо напрямую, либо в виде * 3-й строки "

• Если вы получили БД для проверка другой командой, которую вы передаете другой команде для развертывания: это странно.

Answer 3

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

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

1. нормализация - это структура таблицы, нормализованная ктретья нормальная форма?(по крайней мере, большую часть времени - могут быть некоторые исключения)

2. все таблицы имеют первичный ключ?(«если у него нет первичного ключа, это не таблица», в конце концов)

3. Для SQL Server: все ли таблицы имеют хорошо индекс кластеризации?Уникальный, узкий, статический и, желательно, постоянно увеличивающийся кластеризованный ключ - в идеале INT IDENTITY, и, определенно, не большой сложный индекс из многих полей, без GUID и без больших полей VARCHAR (см. отличные сообщения в блоге Кимберли Триппа по темам для подробностей)

4. есть ли какие-либо проверки и ограничения по умолчанию для таблиц базы данных?

5. - все поля внешнего ключаподкреплена некластеризованным индексом для ускорения запросов JOIN?

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

Но опять же: без реальной статистики времени выполнения вы весьма ограничены в том, что вы можете сделать с точки зрения «статического анализа».Реальная оптимизация действительно может произойти только тогда, когда у вас есть рабочая нагрузка от обычного рабочего дня, чтобы увидеть, какие запросы часто используются, и поставить наибольшую нагрузку на вашу базу данных -> использовать контрольный список Митча для проверки этих точек.

Answer 4

Самое важное, что нужно сделать, это собрать актуальную статистику.Производительность базы данных зависит от:

• схемы;
• данных в базе данных;и
• выполняемые запросы.

Просмотр любого из них изолированно гораздо менее полезен, чем целое.

Как только вы соберете статистику, затем вы начинаете определять операции, которые находятся ниже подпункта.

Для чего стоит, подавляющее большинство проблем с производительностью, которые мы исправили, были либо добавлением индексов, добавлением дополнительных столбцов и триггеров вперенести стоимость вычислений с select на insert/update и тактично информировать пользователей о том, что их запросы, скажем так, не оптимальны: -)

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