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

Описание: KB5126934

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

Дата выпуска: 13 октября 2026 г.

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

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

Описание: KB5128493

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

Дата выпуска: 13 октября 2026 г.

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

Накопительный пакет обновления SQL Server 2022 CU27 - KB5104824

Описание: KB5104824

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

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

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

Analysis Services — Версия: 16.0.43.252

Краткое описание изменений

• Безопасность: устранены уязвимости в аутентификации Entra, анклавах, расширенных событиях, XML, аудите, оптимизаторе запросов, OSF и SqlDataRecord.SetBytes. 
• Сбои и дампы: исправлены падения при XML OPTION (USE PLAN), LEFT_SHIFT/RIGHT_SHIFT, OPENROWSET(BULK...)/BULK INSERT, а также в In-Memory OLTP (SUBSTRING, _VSS, nvarchar(max)). 
• Инфраструктура: повышена надёжность агента SQL, WMI, VSS, ADR/PFS, VSS WITH MOVE, устранена гонка в Linux, исправлено присоединение вторичной реплики к AG с именем 64 символа. 
• PolyBase: улучшена проверка S3-совместимых хранилищ и закрыт незащищённый TCP-прослушиватель. 
• Репликация: повышены безопасность и надёжность транзакционной репликации, репликации слиянием и подписок с обновлением в очереди. 
• Прочее: улучшена обработка Showplan, защита данных внутренней репликации и создание пользователей с Unicode-именами.

Резервные копии снимком на вторичных репликах группы доступности

Автор: Andrew Pruski, T-SQL Snapshot Backups on Availability Group Secondary Replicas

Одной из моих любимых возможностей SQL Server 2022 были резервные копии снимком (Transact-SQL snapshot backup). Возможность использовать снимки современных систем хранения для создания согласованных на уровне приложения снимков наших баз данных — это прорыв для всех, кто имеет дело с очень большими базами данных и изо всех сил пытается уложиться в RPO при заданном RTO.

Однако согласованные на уровне приложения снимки требуют, чтобы запись ввода-вывода базы данных была приостановлена/заморожена/остановлена… и (справедливо) это может заставить администраторов баз данных нервничать.

CXSYNC_PORT и перекос параллелизма: как найти неэффективный параллельный запрос в SQL Server 2022

Автор: Erik Darling, https://erikdarling.com/a-little-about-the-cxsync_port-wait-in-sql-server-2022/

Параллельный план выполнения существует ради одной идеи: разделить работу между несколькими потоками, чтобы сократить время запроса. Если запрос выполняется на DOP 8, вы ожидаете, что он будет примерно в восемь раз быстрее последовательного — с поправкой на то, что параллелизм масштабируется не всегда линейно. Но нередко бывает иначе. Запрос получает восемь потоков, а почти вся работа достаётся одному из них. Остальные семь простаивают, а вы платите за CPU и ждёте.

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

Описание: KB5122768

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

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

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

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

Описание: KB5122771

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

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

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

SQL Server 2025 показывает высокую загрузку процессоров!

Автор: Rob Farley, SQL 2025 showing crazy-high CPU;

Да, вам стоит подумать о переходе на SQL Server 2025. Но если вы используете учётные записи SQL Server, сначала проверьте это (а если вы здесь, чтобы понять, почему вдруг всё замедлилось, читайте дальше).

В большинстве случаев обновление до SQL Server 2025 проходит довольно гладко. Я бы даже сказал, что обновления до других версий SQL Server тоже проходили гладко, хотя многие пострадали от проблем с производительностью из-за изменения модели оценки кардинальности при обновлении до SQL 2014 (точнее, уровня совместимости 120). «Простым» решением тогда было вернуть уровень совместимости на 110, а затем разобраться, что именно вызывало проблемы. Но в SQL Server 2025 есть ещё одна болевая точка, обойти которую не так просто.

Два дополнительных элемента управления при включённой автоматической коррекции планов

Автор: Erin Stellato (MICROSOFT), Two additional controls with Automatic Plan Correction enabled;

Несколько недель назад я опубликовала свой первый «Пятничный отзыв» о Хранилище запросов (Query Store), и один из ответов ссылался на хранимую процедуру, которую я раньше не использовала: sp_configure_automatic_tuning. Было высказано предположение, что эта хранимая процедура не документирована и работает не так, как ожидалось. Зная, как сильно я люблю Хранилище запросов, автоматическую коррекцию планов и документацию, я отправилась на поиски. Если вы не знакомы с этой хранимой процедурой, читайте дальше.

Выметаем ядовитые планы из кэша SQL Server

Автор: Luca Biondi, Check SQL Server Plan Cache Pollution (II) in 45 Seconds

Вы исправили ad-hoc запросы, но ваш сервер всё ещё «колбасит»? В этой статье я расскажу, почему даже идеальная параметризация может привести к «токсичности повторного использования» (reuse toxicity) и массовым скачкам ЦП.

В двух словах

• Параметризованное засорение (Parameterized Pollution): Засорение кэша — это не только «слишком много планов», но и повторно используемый «неправильный план». 
• Токсичность повторного использования (Reuse Toxicity): План, оптимизированный для одной строки, принудительно применяется к набору из миллиона строк, убивая производительность.
• Нестабильность планов (Plan Instability): Резкие колебания между min_worker_time и max_worker_time указывают на войну, вызванную Sniffing'ом параметров.
• Решение: Используйте Query Store, идентификацию по query_hash и оптимизацию PSP в SQL Server 2022.

В предыдущей части этой серии мы очистили кэш от «мусорных» планов. Но горькая правда в том, что чистый код не гарантирует чистый кэш. Даже когда ваше приложение на 100% параметризовано, SQL Server всё ещё может страдать от другого вида засорения — логической токсичности. Это происходит, когда движок повторно использует неоптимальный план выполнения, потому что во время компиляции он «унюхал» (sniffed) непредставительный параметр.

«Нет, мы не обновляемся. Что мы упускаем?»

Автор: Thomas Rushton, “No, we’re not upgrading. What are we missing out on?”

SQL Server 2016 — покойся с миром, RIP, скатертью дорога (хотя последнее звучит как-то слишком сурово). SQL Server 2016 выходит из расширенной поддержки (extended support) 14 июля — в День взятия Бастилии, без комментариев — 2026 года. Это следует из политики фиксированного жизненного цикла Microsoft (Fixed Lifecycle Policy): выпуск, примерно пять лет основной поддержки (mainstream support), в течение которой вы получаете исправления, обновления безопасности, улучшения производительности и функциональности, и ещё примерно пять лет расширенной поддержки (extended support), в течение которой вы получаете обновления безопасности и не многое другое. После этой даты Microsoft крайне редко выпускает какие-либо обновления за пределами платной программы расширенных обновлений безопасности (Extended Security Update, ESU), поэтому продолжение использования продукта, срок поддержки которого истёк (EOL product), следует рассматривать как экстренную меру только для краткосрочного использования.

Бывают дни, когда я хочу бросить всё это с кэшем планов и Хранилищем запросов!

Автор: Brent Ozar, There Are Days When I Feel Like Giving Up on the Plan Cache and Query Store

В теории мониторинг производительности SQL Server довольно прост:

1. Изучите главные типы ожиданий (wait types) на сервере.
2. Найдите запросы, вызывающие эти типы ожиданий.
3. Исправьте эти запросы или улучшите реакцию сервера на них (индексы, настройки и т.д.).

Но на практике шаг 2 ужасен, потому что:

• Приложения отправляют на сервер баз данных непараметризованные строки.
• Пользователи Entity Framework строят запросы с FromSqlRaw или string.Format().
• Пользователи Entity Framework пишут запросы с .Contains, который создаёт непараметризованный список IN, даже когда ищут всего одно значение (в EF9 стало лучше).
• Люди пишут неаккуратный динамический SQL, который просто вставляет значения прямо в строку запроса.
• Разработчики SaaS-решений помещают каждого клиента в собственную базу данных, и планы не переиспользуются между базами данных.

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

Описание: KB5089900

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

Дата выпуска: 12.05.2026

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

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

Описание: KB5091158

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

Дата выпуска: 12.05.2026

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

Автоматическое исправление планов (Automatic Plan Correction) в SQL Server

Автор: theSQLSith (Дерек, MICROSOFT), Query plan regressions got you down? Here's how can Automatic Plan Correction turns it around

Регрессии планов запросов донимают? Вот как автоматическое исправление планов (Automatic Plan Correction) может всё изменить.

Автоматическое исправление планов (Automatic Plan Correction, APC) — это одна из тех функций, о которой я довольно часто беседую с заказчиками, инженерами поддержки и широким сообществом SQL. Она входит в семейство автоматической настройки (Automatic Tuning) и незаметно выполняет свою работу, начиная с SQL Server 2017, обнаруживая регрессии планов запросов и автоматически принудительно применяя ранее известный хороший план для восстановления производительности. Но один из частых вопросов звучит так: как же APC на самом деле решает, произошла ли регрессия? И насколько оно уверено в этом решении?

Начиная с SQL Server 2022 CU4 и продолжая в SQL Server 2025, мы внесли значительные улучшения в статистическую модель, которую APC использует для обнаружения регрессий. В этой статье мы рассмотрим, что изменилось, почему это важно и как вы можете этим воспользоваться.

SQL Server Deprecated Features: 25-летняя хронология и руководство по обеспечению совместимости с будущими версиями

Автор: Steve Stedman, SQL Server Deprecated Features: A 25-Year Timeline and Future-Proofing Guide

За последние 25 лет Microsoft SQL Server значительно эволюционировал, внедряя мощные инструменты и функциональные возможности, одновременно отказываясь от других. В рамках этой эволюции многие возможности были помечены как устаревшие — они по-прежнему работают в текущих версиях, но планируются к удалению в будущих выпусках. Понимание этих устаревших возможностей имеет решающее значение для администраторов баз данных и разработчиков, чтобы обеспечить долгосрочную совместимость и избежать потенциальных сбоев в своих системах.

Объявление возможности устаревшей служит сигналом от Microsoft о необходимости перехода от устаревших или менее эффективных технологий к современным альтернативам. От изменений синтаксиса до целых компонентов — в каждой версии SQL Server появлялись возможности, которые выходили из употребления по мере адаптации платформы к новым отраслевым стандартам и потребностям пользователей. Этот непрерывный процесс помогает поддерживать надёжную, безопасную и высокопроизводительную среду баз данных, но требует проактивного планирования, чтобы избежать зависимости от инструментов, которые вскоре станут неактуальными.

В этой статье мы рассмотрим подробную хронологию устаревших возможностей в различных версиях SQL Server, начиная с SQL Server 2000 и заканчивая последними выпусками. Изучив эти изменения, вы сможете лучше подготовиться к обновлениям, реорганизовать устаревший код и принять рекомендуемые практики, чтобы сохранить вашу инфраструктуру баз данных готовой к будущему. Давайте углубимся в ключевые возможности, которые были исключены за эти годы, и разберёмся с их заменами.

Накопительный пакет обновлений для SQL Server 2022 CU24 - KB5080999

Описание: KB5080999

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

Дата выпуска: 12 марта 2026 г.

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

Детализация прав для динамического маскирования данных в SQL Server 2022

Автор: Leonard Lobel, Granular Dynamic Data Masking (DDM) Permissions in SQL Server 2022

Динамическое маскирование данных (Dynamic Data Masking, DDM) — это функция безопасности, представленная ещё в SQL Server 2016. Она скрывает конфиденциальные данные в результирующем наборе запроса, гарантируя, что неавторизованные пользователи не увидят информацию, к которой не должны иметь доступ. Подробное введение в эту функцию можно найти в моей старой статье в блоге.

Эта статья объясняет новые возможности DDM, добавленные в SQL Server 2022, а именно — детализированные разрешения.

Принудительные планы в SQL Server перезаписывают хэш запроса

Автор: Paul White, SQL Server Forced Plans Overwite the Query Hash

Если вы «принудительно» задаёте план, любым методом, включая руководство планом (Plan Guides), хранилище запросов (Query Store) и автоматическое исправление плана (Automatic Plan Correction), результирующий план будет иметь свой query_hash перезаписанным значением query_plan_hash.

Другими словами, хэш плана и хэш плана запроса получат значение хэша плана запроса. Реальное значение хэша запроса просто теряется. 🤦

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

Крутые возможности в SQL Server, которые я упустил… DATE_BUCKET

Автор: Louis Davidson, Cool features in SQL Server I missed…DATE_BUCKET

Я продолжаю находить или слышать о весьма полезных функциях, которые я просто упустил. Планирую перечитать все записи о «новых возможностях» для SQL Server (ну, по крайней мере, разделы Transact-SQL!) и посмотреть, что ещё я пропустил, а также другие функции, которые я использовал недостаточно, но которые кажутся полезными.

Узнал я об этой функции несколько недель назад из публикации Джована Поповича в LinkedIn.

И я мгновенно понял, что он имел в виду, говоря о том, насколько полезна будет функция DATE_BUCKET (появившаяся в SQL Server 2022)!

Используя эту функцию, вы можете легко группировать данные в различные временные интервалы, такие как год, месяц, день (что, конечно, достаточно стандартно), но также и в интервалы вроде 2 дней, 6,4 недель и т.д. Я не считаю, что это должно заставить вас отказаться от измерения дат в вашем хранилище данных, но она великолепна, когда вы просто исследуете данные и хотите легко поэкспериментировать с разными интервалами.