Параллельный план выполнения существует ради одной идеи: разделить работу между несколькими потоками, чтобы сократить время запроса. Если запрос выполняется на DOP 8, вы ожидаете, что он будет примерно в восемь раз быстрее последовательного — с поправкой на то, что параллелизм масштабируется не всегда линейно. Но нередко бывает иначе. Запрос получает восемь потоков, а почти вся работа достаётся одному из них. Остальные семь простаивают, а вы платите за CPU и ждёте.
Обычно, когда вы смотрите на план выполнения и видите поиск по индексу (index seek), за которым следует поиск по ключу (key lookup), это означает, что запрос выполняется относительно быстро.
Если вы когда-либо занимались настройкой производительности SQL Server, вы почти наверняка сталкивались с двумя терминами, которые постоянно путают: уровень совместимости (Compatibility Level, CL) и оценщик кардинальности (Cardinality Estimator, CE). Они звучат так, будто могут быть одним и тем же, поскольку изменение одного часто влияет на поведение другого. Но это два разных понятия в ядре SQL Server, и понимание того, где они пересекаются, а где расходятся, необходимо для всех, кто занимается обновлениями, миграциями или настройкой запросов.
В этой статье разбирается, что представляет собой каждое из этих понятий, как они связаны друг с другом, что и когда менялось, а также как диагностировать и исправлять проблемы, вызванные регрессиями, связанными с оценщиком кардинальности.
Автор: Klaus Aschenbrenner, Query Memory Spills
Иногда, когда вы смотрите на планы выполнения, вы можете увидеть, что у оператора SELECT иногда есть так называемый грант памяти (Memory Grant). Этот грант памяти указывается в килобайтах и необходим для выполнения запроса, когда некоторым операторам (например, Sort/Hash) в планах выполнения требуется память для выполнения — так называемая память запроса (Query Memory).
Автор: Paul Randal, Trimming More Transaction Log Fat
В моей предыдущей статье об оптимизации операций с журналом транзакций я обсудил две наиболее распространённые причины генерации лишних записей журнала: «мёртвый груз» от неиспользуемых некластерных индексов и операции разделения страниц (которые вызывают фрагментацию индексов). Предполагая, что вы прочитали это, я упомянул, что существуют более тонкие проблемы, которые могут негативно влиять на производительность журнала транзакций, и я собираюсь рассмотреть их здесь.
Автор: Paul Randal, Trimming the Transaction Log Fat
Для многих рабочих нагрузках SQL Server, особенно OLTP, журнал транзакций базы данных может быть узким местом, увеличивающим время завершения транзакции. Большинство людей предполагают, что реальным узким местом является подсистема ввода-вывода, которая не справляется с объёмом журнала транзакций, генерируемого рабочей нагрузкой.
Автор: Sarjen Haque, Performance issues from ORDER BY/GROUP BY - spills in tempdb
Совершенно обычно и ожидаемо видеть запрос, содержащий предложение ORDER BY или GROUP BY для целей отображения или группировки. Также часто разработчики используют предложение ORDER BY по привычке, не задумываясь о его необходимости. В результате запросы со временем замедляются по мере увеличения количества записей.
Автор: Remus Rusanu, Understanding Hash, Sort and Exchange Spill events
Некоторые операции при выполнении запросов SQL Server рассчитаны на наилучшую производительность при использовании (относительно) большого объёма памяти в качестве промежуточного хранилища. Оптимизатор запросов выбирает план и оценивает стоимость, основываясь на том, что эти операторы используют эту «черновую» память. Но это, конечно, лишь оценка. Во время выполнения оценки могут оказаться неверными, и план должен продолжить работу, несмотря на нехватку памяти. В таком случае эти операторы выполняют сброс на диск (spill). Когда происходит сброс, «черновая» память сбрасывается в tempdb, и новые данные размещаются в (теперь) свободной памяти. Когда данные, сброшенные в tempdb, снова нужны, они читаются с диска. Само собой разумеется, сброс в tempdb на порядок медленнее, чем использование только «черновой» памяти. Мониторинг сбросов особенно важен в ETL-задачах, поскольку эти случаи могут растянуть выполнение ETL на многие минуты, а иногда даже часы. Для исчерпывающего обсуждения ETL, включая некоторые ссылки на сбросы, см. Руководство по производительности загрузки данных.
Автор: Paul Randal, Understanding data vs log usage for spills in tempdb
В списке рассылки SQL MCM (в котором участвуют все действующие инструкторы MCM) было обсуждение, где пытались понять огромное несоответствие между использованием файлов данных tempdb и файлов журнала. Я объяснил ответ и решил поделиться им со всеми вами.
Кеш планов SQL Server — это критически важный компонент, который хранит планы выполнения запросов для повторного использования. Однако неправильное использование этого механизма может привести к серьезным проблемам производительности. В этой статье мы рассмотрим:
Автоматическое обновление статистики в SQL Server — мощный механизм, но для очень больших таблиц его стандартный порог может оказаться недостаточно чувствительным. В этой статье мы рассмотрим подход к адаптивному отслеживанию статистики, который дополняет встроенный механизм и позволяет вовремя выявлять устаревшие статистики даже в самых крупных таблицах.
Многие инциденты с SQL Server, по которым меня вызывают, можно было предотвратить с помощью средств, уже имеющихся в среде заказчика. Вот аудит, который я хотел бы видеть выполненным до того, как прозвучал пейджер, — с полным T-SQL.
В ходе анализа одного инцидента производительности SQL Server мы заметили интересный шаблон обновления статистики в большой таблице. Несколько статистик были недавно обновлены в разное время, в то время как группа автоматически созданных статистик _WA_Sys_ не была обновлена, эти статистики показывали
last_updated.modification_counter.На первый взгляд это могло бы указывать на то, что AUTO_UPDATE_STATISTICS работает некорректно. Однако более детальный анализ показал, что такой шаблон может полностью соответствовать ожидаемому поведению SQL Server.
Несколько недель назад я опубликовала свой первый «Пятничный отзыв» о Хранилище запросов (Query Store), и один из ответов ссылался на хранимую процедуру, которую я раньше не использовала: sp_configure_automatic_tuning. Было высказано предположение, что эта хранимая процедура не документирована и работает не так, как ожидалось. Зная, как сильно я люблю Хранилище запросов, автоматическую коррекцию планов и документацию, я отправилась на поиски. Если вы не знакомы с этой хранимой процедурой, читайте дальше.
Автор: Paul Randal, The Accidental DBA (Day 27 of 30): Troubleshooting: Tempdb Contention
Одна из самых распространённых проблем производительности, существующих в экземплярах SQL Server по всему миру, известна как конкуренция за tempdb. Что это означает? Конкуренция за tempdb относится к узкому месту для потоков, пытающихся получить доступ к страницам распределения, находящимся в памяти; это не связано с вводом-выводом.
Автор: Paul Randal, Code to list potential cluster key space savings per table
Чем больше ключ кластеризации в вашей таблице, тем больше пространства тратится впустую во всех строках некластерных индексов.
Я подготовил код, который выполнит обход всех ваших баз данных и покажет для каждой таблицы, сколько места занимают ключи кластеризации в некластерных индексах, а также потенциальную экономию пространства, если преобразовать ключ кластеризации в один 8-байтовый bigint.
Вы можете модифицировать код по своему усмотрению. И я продолжаю использовать sp_msforeachdb, потому что это самый быстрый способ для меня написать код для вас, и это продолжает раздражать моего хорошего друга Аарона Бертрана (Aaron Bertrand) :-)
Наслаждайтесь!
Автор: Paul Randal, Over and under indexing – how bad is it out there?
Как-то я запустил опрос, в котором предложил выполнить код для получения сводного списка количества таблиц на вашем сервере с различным числом некластерных индексов. Я получил результаты с более чем 1000 серверов по всему миру — огромное спасибо всем, кто прислал мне данные!
Победители:
Вау!
Теперь перейдём к некоторым деталям…
Автор: Paul Randal, Capturing wait stats for a single operation
Эта статья о настройке производительности, которая давно была в моём списке задач. Анализ статистики ожиданий — отличный способ изучить симптомы проблем с производительностью (см. мой каталог Wait Stats для получения дополнительной информации), но использование DMV sys.dm_os_wait_stats показывает всё, что происходит на сервере. Если вы хотите увидеть, какие ожидания возникают из-за одного запроса или операции в рабочей системе (например, влияние подсказок MAXDOP на количество и продолжительность ожиданий CXPACKET для запроса), то использование DMV обычно нецелесообразно — вам пришлось бы очистить статистику ожиданий и убедиться, что в системе не выполняется ничего, кроме исследуемого запроса/операции. Наиболее правильный способ сделать это — использовать расширенные события (Extended Events).
После рассмотрения дискового строчного хранения, индексов columnstore, оптимизированных для памяти структур и оптимизированных для памяти columnstore, пришло время обратить внимание на структуры хранения, которые используются только для определённых типов данных. Первой «жертвой» станет XML-индекс.
Автор: Paul Randal, Adventures in query tuning: non-seekable WHERE clause expressions
За последние пару месяцев я выполнил много работы по настройке производительности, и в эти выходные обнаружил нечто, очень распространённое в реальных системах. Кимберли помогала мне оптимизировать один сложный план запроса и заметила в коде то, чего я не увидел, — это приводило к просмотру индекса вместо поиска по индексу. Несмотря на то, что план запроса использовал покрывающий некластерный индекс, способ написания кода заставлял индекс сканироваться.
Я подготовлю тестовый пример, чтобы показать, что я имею в виду.