Исправление безопасности для 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, хотя некоторые умудряются довести журнал до полутора миллионов. Это уже не повод для гордости, а повод взяться за настройки.

2NF и BCNF: весь ключ и ничего, кроме ключа

Автор: Lee Asher, 2NF and BCNF explained: the whole key, nothing but the key

«Нормальные формы» — это правила нормализации баз данных, предназначенные для предотвращения дублирования данных и аномалий при изменении информации в реляционных базах данных.

Вторая нормальная форма (2NF) требует, чтобы каждый столбец зависел от всего ключа таблицы, а не только от его части. Нормальная форма Бойса — Кодда (BCNF) ужесточает это требование: никакой столбец не должен зависеть ни от чего, кроме ключа.

Классическая мнемоническая фраза «ключ, весь ключ и ничего, кроме ключа» объединяет все три нормальные формы в одной строке. В этом руководстве мы подробно разберём, что именно означает каждое правило, и рассмотрим практические примеры, которые можно применить при проектировании собственных структур данных.

Влияние 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 на вторичных репликах