Исправление безопасности для SQL Server 2025 CU10 - KB5129299

Описание: KB5129299

Скачать: SQLServer2025-KB5129299-x64.exe

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

SQL Server 2025 — Версия: 17.0.5045.3

Краткий перечень исправлений:

• SQL Connectivity: устранено out-of-bounds чтение при обработке клиентских подключений.
• Integration Services: XSLT-скрипты отключены по умолчанию; исправлены проблемы доступа к памяти и переполнения в OLE DB, HTTP Connection Manager и Raw File Source.
• Replication: большой блок усиления валидации и безопасности — merge/tran replication, Log Reader/Queue Reader, WebSync, conflict metadata, xp_decodequeuecmd, повышение привилегий.
• Programmability: XML/JSON — heap overflow, длинные пути JSON-индексов, >128 уровней вложенности, повреждение при merge JSON-массивов, утечка памяти в JSON_VALUE; SQL Trace; DBCC + PERSISTED computed column на native json.
• Storage / Access Methods: проверки row-compressed записей, sparse columns, offsets, безопасность индексов и журналирования.
• Прочее: EXTERNAL MODEL permissions, XA-транзакции, backup/restore metadata, PolyBase, Management Services, Agent job steps.
• SQLdiag: длинные и Unicode-имена БД.

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

Описание: KB5132748

Скачать: SQLServer2025-KB5132748-x64.exe

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

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

Краткий перечень исправлений:

• SQL Connectivity: устранено out-of-bounds чтение при обработке клиентских подключений.
• Integration Services: XSLT-скрипты отключены по умолчанию; исправлены проблемы доступа к памяти и переполнения в OLE DB, HTTP Connection Manager и Raw File Source.
• Replication: большой блок усиления валидации и безопасности — merge/tran replication, Log Reader/Queue Reader, WebSync, conflict metadata, xp_decodequeuecmd, повышение привилегий.
• Programmability: XML/JSON — heap overflow, длинные пути JSON-индексов, >128 уровней вложенности, повреждение при merge JSON-массивов, утечка памяти в JSON_VALUE; SQL Trace; DBCC + PERSISTED computed column на native json.
• Storage / Access Methods: проверки row-compressed записей, sparse columns, offsets, безопасность индексов и журналирования.
• Прочее: EXTERNAL MODEL permissions, XA-транзакции, backup/restore metadata, PolyBase, Management Services, Agent job steps.
• SQLdiag: длинные и Unicode-имена БД.

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

Описание: KB5129300

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

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

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

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

Описание: KB5132747

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

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

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

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

Описание: KB5132745

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

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

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

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

Описание: KB5132751

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

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

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

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

Описание: KB5132746

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

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

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

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

Описание: KB5132749

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

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

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

Добавление базы данных в группу доступности AG (автоматическая инициализация) и контроль хода инициализации

Автор: Dr. Hasan Dalmaz, Añadir una base de datos a un AG (automatic seeding) y monitorear el progreso del seeding

В этой статье вы узнаете, как добавляется база данных в группу доступности AG, и происходит передача её на вторичные реплики через конечную точку (VDI), без необходимости вручную создавать резервную копию и восстанавливать её. Также, вы узнаете, как отслеживать производительность инициализации, расчётное время её завершения и причину возможного сбоя.

AG Direct Seeding: расширенные события и динамические административные представления

Автор: Erik Darling, Availability Group Direct Seeding: Extended Events and DMVs

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

VLF: когда журнал транзакций превращается в коммуналку

VLF — это виртуальные файлы журнала. Пока их немного, они тихо делают свою работу. Но стоит им расплодиться, как журнал транзакций начинает напоминать коммунальную квартиру с бесконечными чуланами: нужную коробку вроде бы видно, а чтобы до неё добраться, приходится открывать дверь за дверью.

Чем больше VLF, тем заметнее просадка производительности. Страдают, причём дружно, почти все участники процесса:

• резервное копирование журнала — вместо одного крупного блока приходится перебирать гору мелких;
• восстановление базы данных — и без того не мгновенное, с массой VLF превращается в марафон;
• очистка журнала и его усечение — буксует из-за фрагментации;
• репликация — агент чтения журнала пробирается через дебри VLF, доставка изменений замедляется;
• восстановление после сбоя — система приходит в себя дольше;
• откаты транзакций — процедура становится ещё томительнее;
• обычные операции изменения данных — даже они ощущают на себе тяжесть раздробленного журнала;
• запуск базы данных — при миллионах мелких VLF старт может затянуться.

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

Влияние CPU Ready на ожидания SOS_SCHEDULER_YIELD

Автор: Jonathan Kehayias, CPU Ready Impact on SOS_SCHEDULER_YIELD

Однажды мы с Полом обсуждали ожидания SOS_SCHEDULER_YIELD и пытались разобраться, могут ли показатели этих ожиданий в SQL Server искажаться из-за проблем с планированием выполнения виртуальной машины гипервизором.

Я провёл первые эксперименты в своей лаборатории виртуальных машин, используя как Hyper-V, так и VMware. В результате удалось воспроизвести именно ту ситуацию, о которой говорил Пол и которую он описал в своей статье.

Увеличение количества ожиданий SOS_SCHEDULER_YIELD на виртуальных машинах

Автор: Paul Randal, Increased SOS_SCHEDULER_YIELD waits on virtual machines

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

Я ответил утвердительно: время ожиданий может оказаться больше, если что-то мешает виртуальной машине выполнять работу. Дело в том, что продолжительность ожидания определяется разницей значений счётчика __rdtsc (по сути, счётчика тактов процессора) в момент начала и окончания ожидания.

Структуры хранения #8 — векторные индексы

Автор: Hugo Kornelis, Storage structures 8 – Vector indexes

Это восьмая часть серии статей, посвящённой внутреннему устройству структур хранения данных. Рассмотрев стандартные типы хранения, традиционные построчные структуры данных, колоночные индексы, структуры с оптимизацией для работы в памяти и колоночные структуры с оптимизацией для работы в памяти, я перешёл к более специализированным структурам хранения. В пятой, шестой и седьмой частях речь шла об индексах XML, JSON и пространственных данных. Теперь настала очередь типа индексов, который появился в продукте совсем недавно — векторные индексы.

Почему при запросе всей таблицы SQL Server не использует параллелизм

Автор: Brent Ozar, Why You Don’t Get Parallelism When You Ask for The Whole Table

Предположим, вы работаете с копией большой базы данных Stack Overflow и хотите получить сведения обо всех пользователях, например для экспорта данных. SQL Server не распараллеливает такой запрос — даже если использовать подсказку, которая требует построить параллельный план:

SELECT Id FROM dbo.Users;

SELECT Id FROM dbo.Users
    OPTION (USE HINT('ENABLE_PARALLEL_PLAN_PREFERENCE'));

Здесь я выбираю только идентификаторы, поскольку в больших копиях базы данных Stack Overflow таблица Users занимает более 1 ГБ. SQL Server Management Studio требуется очень много времени, чтобы отобразить в сетке результатов данные такого объёма. А демонстрировать медленную работу SSMS — не моя цель. Если вы собираетесь повторять этот пример, убедитесь, что используете актуальную версию SQL Server Management Studio: я не хочу, чтобы во время экспериментов у вас закончилась оперативная память, как это могло происходить в старых версиях SSMS.

Почему же запрос не выполняется параллельно? 

Кто поменял MAXDOP 1 на экземпляре?

Автор: Paul Randal, Who is overriding MAXDOP 1 on the instance?

Мне пришёл вопрос по электронной почте: «как могут возникать ожидания латча ACCESS_METHODS_DATASET_PARENT, когда MAXDOP экземпляра установлен в 1?» Этого не должно происходить, так как эта краткая блокировка используется только для координации между потоками, выполняющими параллельное сканирование таблицы или индекса. Однако то, что MAXDOP экземпляра установлен в 1, не означает, что параллелизм не может возникнуть.

Любой может переопределить настройку MAXDOP экземпляра с помощью подсказки запроса.

Некролог на ночное задание по перестроению индексов, 1998–2026

Автор: Pinal Dave, The Nightly Index Rebuild Job, 1998 to 2026: An Obituary

Ночное задание по перестроению индексов скончалось после долгой болезни. Оно родилось в 1998 году для жёсткого диска, который не умел эффективно перемещать головки для поиска. Оно так и не поверило, что диск заменили. Его пережила плотность страниц, которая, как выяснилось, всё это время выполняла основную часть его работы. Это было задание по привычке. Каждую ночь в два часа, независимо от того, изменилось ли что-нибудь, оно перестраивало каждый индекс в базе данных. Каждое утро база данных была ровно такой же быстрой, как и прошлой ночью. Никто не помнит, кто его запланировал. Все помнят, что им говорили его не убирать.

Накопительный пакет обновления SQL Server 2025 CU10 - KB5125471

Описание: KB5125471

Скачать: SQLServer2025-KB5125471-x64.exe

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

SQL Server 2025 — Версия: 17.0.5035.5

Analysis Services — Версия: 17.0.25.223

~40 фиксов в одном обновлении, главное:

🔒 Безопасность (критично)

• Уязвимости в VDI (Backup/Restore) — выход за границы памяти
• RCE и утечки в PolyBase и ML Services (SQLSatellite)
• Повышение привилегий через метаданные бэкапа
• Множество дыр в Replication (включая Log Reader Agent и sp_replcounters)

⚙️ Движок

• Порча XML при сжатии (off-row)
• Падение при JSON-индексах с Unicode >8000 байт
• OOB-чтение в SQL Trace (LoginSid)
• Утечки памяти в AI_GENERATE_EMBEDDINGS и SqlDataRecord.SetBytes

🐧 Linux

• Ошибка 1803 при создании contained AG после смены collation

🔄 Репликация и CES

• Buffer overflow в merge replication (>250 XML-ников)
• Падения при сериализации в Change Event Streaming

🔗 Прочее

• Сбой linked server (MSDASQL) без UID
• Валидация Delta Lake и FILESTREAM на вторичных репликах

Окончание поддержки SQL Server 2016: как выбрать путь обновления

Автор: Greg Low, SQL Server 2016 end of support: how to choose your upgrade path

SQL Server 2016 достиг окончания расширенной поддержки в июле 2026 года, что означает, что он больше не получает регулярных обновлений безопасности, если вы не платите за расширенные обновления безопасности (ESU). Ваши реалистичные варианты — обновиться до SQL Server 2025, обновиться до SQL Server 2022 или купить ESU на срок до трёх дополнительных лет (до июля 2029 года), независимо от того, запускаете ли вы SQL Server локально или в Microsoft Azure. Для большинства производственных систем я рекомендую параллельную миграцию на SQL Server 2025, если только поставщик приложения или удалённый из последней версии функционал не исключают это. Правильный подход в конечном счёте зависит от совместимости приложений, ограничений инфраструктуры, допустимого простоя, затрат на лицензирование и того, как долго новая среда должна оставаться поддерживаемой.

В этой статье я рассмотрю ключевые решения (обновление на месте vs параллельная миграция, SQL Server 2022 vs SQL Server 2025, локально vs Microsoft Azure и ESU), а также контрольный список перед обновлением и советы по откату, чтобы снизить риск.

Поиск первопричины медленных запросов

Автор: Pinal Dave, Finding the Root Cause of Slow Queries

Поиск первопричины медленных запросов начинается с разделения работы и ожиданий, а затем проверки теорий на планах и истории. Вот вам пример показательного вторника. В 10:12 поиск заказа, который обычно возвращался за 180 миллисекунд, занял 14,8 секунды. Сорок три сеанса накопились за пять минут, и команда приложения захотела новый индекс ещё до обеда. CPU оставался скромным, логические чтения оставались привычными, а кэшированный план совпадал со вчерашним быстрым планом. Запрос провёл почти всю свою жизнь в ожидании LCK_M_S. Ночной процесс инвентаризации оставил открытой транзакцию обновления. Видимый запрос был жертвой, а не виновником. Команда проследовала по blocking_session_id, пока цепочка не закончилась на спящем сеансе. Его последний пакет показывал обновление инвентаризации, и данные транзакции подтвердили незафиксированную работу. Как только этот владелец безопасно зафиксировал транзакцию, задержка упала ниже 200 миллисекунд. Никто не редактировал код жертвы, индексы или статистику.