Меня эта возможность чрезвычайно заинтересовала, поэтому отсутствие документации на момент написания статьи меня не остановило. С тех пор как появились группы доступности, регулярно возникают вопросы о том, как автоматизировать присоединение (seeding) новых баз данных. Все предлагавшиеся решения сводились к довольно неуклюжим сценариям: создать резервную копию, восстановить её, присоединить базу к группе и так далее. Описываемая тут функциональность призвана избавить нас от всей этой возни.
VLF — это виртуальные файлы журнала. Пока их немного, они тихо делают свою работу. Но стоит им расплодиться, как журнал транзакций начинает напоминать коммунальную квартиру с бесконечными чуланами: нужную коробку вроде бы видно, а чтобы до неё добраться, приходится открывать дверь за дверью.
Чем больше VLF, тем заметнее просадка производительности. Страдают, причём дружно, почти все участники процесса:
Порогом тревоги обычно считают тысячу VLF, хотя некоторые умудряются довести журнал до полутора миллионов. Это уже не повод для гордости, а повод взяться за настройки.
«Нормальные формы» — это правила нормализации баз данных, предназначенные для предотвращения дублирования данных и аномалий при изменении информации в реляционных базах данных.
Вторая нормальная форма (2NF) требует, чтобы каждый столбец зависел от всего ключа таблицы, а не только от его части. Нормальная форма Бойса — Кодда (BCNF) ужесточает это требование: никакой столбец не должен зависеть ни от чего, кроме ключа.
Классическая мнемоническая фраза «ключ, весь ключ и ничего, кроме ключа» объединяет все три нормальные формы в одной строке. В этом руководстве мы подробно разберём, что именно означает каждое правило, и рассмотрим практические примеры, которые можно применить при проектировании собственных структур данных.
Однажды мы с Полом обсуждали ожидания 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 миллисекунд. Никто не редактировал код жертвы, индексы или статистику.