Однажды мы с Полом обсуждали ожидания SOS_SCHEDULER_YIELD и пытались разобраться, могут ли показатели этих ожиданий в SQL Server искажаться из-за проблем с планированием выполнения виртуальной машины гипервизором.
Я провёл первые эксперименты в своей лаборатории виртуальных машин, используя как Hyper-V, так и VMware. В результате удалось воспроизвести именно ту ситуацию, о которой говорил Пол и которую он описал в своей статье.
Автор: Paul Randal, Increased SOS_SCHEDULER_YIELD waits on virtual machines
Во время обучения работе со статистикой ожиданий, меня спросили, существуют ли какие-либо ожидаемые различия в этой статистике при работе SQL Server внутри виртуальной машины.
Я ответил утвердительно: время ожиданий может оказаться больше, если что-то мешает виртуальной машине выполнять работу. Дело в том, что продолжительность ожидания определяется разницей значений счётчика __rdtsc (по сути, счётчика тактов процессора) в момент начала и окончания ожидания.
Это восьмая часть серии статей, посвящённой внутреннему устройству структур хранения данных. Рассмотрев стандартные типы хранения, традиционные построчные структуры данных, колоночные индексы, структуры с оптимизацией для работы в памяти и колоночные структуры с оптимизацией для работы в памяти, я перешёл к более специализированным структурам хранения. В пятой, шестой и седьмой частях речь шла об индексах XML, JSON и пространственных данных. Теперь настала очередь типа индексов, который появился в продукте совсем недавно — векторные индексы.
Предположим, вы работаете с копией большой базы данных 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.
Почему же запрос не выполняется параллельно?
Автор: Paul Randal, Who is overriding MAXDOP 1 on the instance?
Мне пришёл вопрос по электронной почте: «как могут возникать ожидания латча ACCESS_METHODS_DATASET_PARENT, когда MAXDOP экземпляра установлен в 1?» Этого не должно происходить, так как эта краткая блокировка используется только для координации между потоками, выполняющими параллельное сканирование таблицы или индекса. Однако то, что MAXDOP экземпляра установлен в 1, не означает, что параллелизм не может возникнуть.
Любой может переопределить настройку MAXDOP экземпляра с помощью подсказки запроса.
Автор: Pinal Dave, The Nightly Index Rebuild Job, 1998 to 2026: An Obituary
Ночное задание по перестроению индексов скончалось после долгой болезни. Оно родилось в 1998 году для жёсткого диска, который не умел эффективно перемещать головки для поиска. Оно так и не поверило, что диск заменили. Его пережила плотность страниц, которая, как выяснилось, всё это время выполняла основную часть его работы. Это было задание по привычке. Каждую ночь в два часа, независимо от того, изменилось ли что-нибудь, оно перестраивало каждый индекс в базе данных. Каждое утро база данных была ровно такой же быстрой, как и прошлой ночью. Никто не помнит, кто его запланировал. Все помнят, что им говорили его не убирать.
Описание: KB5125471
Скачать: SQLServer2025-KB5125471-x64.exe
Дата выпуска: 22 октября 2026 г.
SQL Server 2025 — Версия: 17.0.5035.5
Analysis Services — Версия: 17.0.25.223
~40 фиксов в одном обновлении, главное:
🔒 Безопасность (критично)
⚙️ Движок
🐧 Linux
🔄 Репликация и CES
🔗 Прочее
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 миллисекунд. Никто не редактировал код жертвы, индексы или статистику.
Тема внезапно стала мейнстримом: в датацентры иногда прилетает, и тогда очень хочется иметь копию не «где-то там», а на альтернативной площадке. И чтобы её никто не прочитал. Погнали.
Автор: Pinal Dave, SQL Server Deadlock: Build One With Your Own Hands
Взаимоблокировка SQL Server возникает, когда сеансы образуют цикл зависимостей и ни один не может продолжить, тупиковая ситуация. Этот пример позволяет вам создать цикл, изучить его и устранить.
Transaction (Process ID 57) was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction.
SQL Server разрешает цикл, выбирая одну транзакцию в качестве жертвы, откатывая её и возвращая ошибку 1205. Выжившая транзакция затем может продолжить.
Иногда случается, что службы SQL Server могут по-прежнему существовать на сервере, но связанные записи SQL Server отсутствуют в «Программах и компонентах». Это может происходить из-за отсутствующих или повреждённых записей реестра, неполного удаления или неудачных действий по установке исправлений.