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

Окончание поддержки 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 миллисекунд. Никто не редактировал код жертвы, индексы или статистику.

Как зашифровать бэкапы и не поседеть при восстановлении

Тема внезапно стала мейнстримом: в датацентры иногда прилетает, и тогда очень хочется иметь копию не «где-то там», а на альтернативной площадке. И чтобы её никто не прочитал. Погнали.