Исправление безопасности для SQL Server 2022 GDR - KB5122771

Описание: KB5122771

Скачать: SQLServer2022-KB5122771-x64.exe

Дата выпуска: 8 сентября 2026 г.

SQL Server 2022 — Версия: 16.0.1200.5

Исправление безопасности для SQL Server 2019 CU32 - KB5122772

Описание: KB5122772

Скачать: SQLServer2019-KB5122772-x64.exe

Дата выпуска: 8 сентября 2026 г.

SQL Server 2019 — версия: 15.0.4490.9

Исправление безопасности для SQL Server 2019 GDR - KB5122773

Описание: KB5122773

Скачать: SQLServer2019-KB5122773-x64.exe

Дата выпуска: 8 сентября 2026 г.

SQL Server 2019 — версия: 15.0.2190.7

Исправление безопасности для SQL Server 2017 CU31 - KB5122774

Описание: KB5122774

Скачать: SQLServer2017-KB5122774-x64.exe

Дата выпуска: 8 сентября 2026 г.

SQL Server 2017 — версия: 14.0.3550.4

Исправление безопасности для SQL Server 2017 GDR - KB5122775

Описание: KB5122775

Скачать: SQLServer2017-KB5122775-x64.exe

Дата выпуска: 8 сентября 2026 г.

SQL Server 2017 — версия: 14.0.2130.4

Выясняем причину длительных ожиданий ASYNC_IO_COMPLETION

Автор: Paul Randal, A cause of high-duration ASYNC_IO_COMPLETION waits

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

Официальное определение ASYNC_IO_COMPLETION: «Происходит, когда задача ожидает завершения операций ввода-вывода.» Очень полезно — НЕТ!

Что такое остаточный предикат (residual predicate) и почему это плохо?

Автор: Brent Ozar, Database Animations: What’s a Residual Predicate and Why Is It Bad?

Обычно, когда вы смотрите на план выполнения и видите поиск по индексу (index seek), за которым следует поиск по ключу (key lookup), это означает, что запрос выполняется относительно быстро.

Уровень совместимости и оценщик кардинальности в SQL Server

Автор: Vivek Johari, Compatibility Level vs. Cardinality Estimator in SQL Server: A Complete Guide;

Если вы когда-либо занимались настройкой производительности SQL Server, вы почти наверняка сталкивались с двумя терминами, которые постоянно путают: уровень совместимости (Compatibility Level, CL) и оценщик кардинальности (Cardinality Estimator, CE). Они звучат так, будто могут быть одним и тем же, поскольку изменение одного часто влияет на поведение другого. Но это два разных понятия в ядре SQL Server, и понимание того, где они пересекаются, а где расходятся, необходимо для всех, кто занимается обновлениями, миграциями или настройкой запросов.

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

Промежуточная материализация (Query Memory Spills)

Автор: Klaus Aschenbrenner, Query Memory Spills

Иногда, когда вы смотрите на планы выполнения, вы можете увидеть, что у оператора SELECT иногда есть так называемый грант памяти (Memory Grant). Этот грант памяти указывается в килобайтах и необходим для выполнения запроса, когда некоторым операторам (например, Sort/Hash) в планах выполнения требуется память для выполнения — так называемая память запроса (Query Memory).

Новое в SQL Server 2025: Мультипликативная агрегация с функцией PRODUCT

Автор: Leonard Lobel, Multiplicative Aggregates with the PRODUCT Function in SQL Server 2025

В этой статье блога рассматривается новая функция PRODUCT в SQL Server 2025, которая вычисляет произведение набора числовых значений — аналогично тому, как SUM и AVG работают для сложения и усреднения, но для умножения.

До появления SQL Server 2025 в SQL Server не было встроенного способа вычисления произведения значений в наборе. Приходилось использовать обходные пути, такие как циклы или определяемые пользователем агрегаты. С PRODUCT это теперь простое однострочное выражение.

PRODUCT поддерживает как агрегатную, так и аналитическую (оконную) формы и работает как со значениями ALL (по умолчанию), так и с DISTINCT. Значения NULL игнорируются, и функция совместима со всеми числовыми типами, кроме bit.

Ещё больше ЗОЖ для журнала транзакций

Автор: Paul Randal, Trimming More Transaction Log Fat

В моей предыдущей статье об оптимизации операций с журналом транзакций я обсудил две наиболее распространённые причины генерации лишних записей журнала: «мёртвый груз» от неиспользуемых некластерных индексов и операции разделения страниц (которые вызывают фрагментацию индексов). Предполагая, что вы прочитали это, я упомянул, что существуют более тонкие проблемы, которые могут негативно влиять на производительность журнала транзакций, и я собираюсь рассмотреть их здесь.

Программа похудения для журнала транзакций

Автор: Paul Randal, Trimming the Transaction Log Fat

Для многих рабочих нагрузках SQL Server, особенно OLTP, журнал транзакций базы данных может быть узким местом, увеличивающим время завершения транзакции. Большинство людей предполагают, что реальным узким местом является подсистема ввода-вывода, которая не справляется с объёмом журнала транзакций, генерируемого рабочей нагрузкой.