От тушения пожаров к созиданию будущего: SQL Server 2025 и новое мышление DataOps

Автор: Chris, From Firefighting to Future‑Building: SQL Server 2025 and the New DataOps Mindset

В технологии бывают моменты, когда почва словно уходит из‑под ног. Когда инструменты, которые мы считали надёжными утилитами, внезапно становятся двигателями преобразований. SQL Server 2025 — один из таких.

Годами специалисты по данным жили в режиме постоянного тушения пожаров. Мы ставили заплаты по ночам. Мы настраивали запросы до ряби в глазах. Мы строили конвейеры, которые напоминали скорее хрупкие мостики, чем надёжные магистрали. Мы много работали, но слишком часто — «в тумане», в мелочах.

Теперь, с SQL Server 2025, этот «туман» рассеивается. Мы вступаем в новую эпоху, где внимание сосредоточено не на механике данных, а на их смысле. Это восхождение декларативного DataOps.

Недокументированная функция sys.fn_PhysLocCracker

Автор: Paul Randal, SQL Server 2008: New (undocumented) physical row locator function

Один из минусов того, что я больше не в команде SQL в Microsoft, — я не знаю обо всех недокументированных возможностях следующего релиза и, как и все, вынужден их выискивать :-(

Итак, ковыряясь в SSMS в 2008 CTP‑6, я заметил функцию под названием sys.fn_PhysLocCracker, о которой никогда не слышал. Выполнив sp_helptext для неё, получил такой вывод:

— Name: sys.fn_PhysLocCracker
—
— Description:
— Cracks the output of %%physloc%% virtual column
—
— Notes:
——————————————————————————-
create function sys.fn_PhysLocCracker (@physical_locator binary (8))
returns @dumploc_table table
(
 [file_id] int not null,
 [page_id] int not null,
 [slot_id] int not null
)

GAM, SGAM, PFS и другие карты распределения

Автор: Paul Randal, Inside The Storage Engine: GAM, SGAM, PFS and other allocation maps

Это обновлённая версия статьи из моего прежнего блога о механизме хранения; теперь она также охватывает страницы карт DIFF и ML.

В предыдущих статьях этой серии я разобрал основы хранения в файлах базы данных:

• Анатомия страницы/Анатомия записи
• Анатомия экстента
• Страницы IAM, цепочки IAM и единицы распределения (allocation units)

Последние элементы в «головоломке» распределения — это прочие страницы-карты учёта распределения: страницы GAM, SGAM, PFS, ML map и DIFF map. Всё, что описано ниже, справедливо для версий на сегодня. Для любой из этих страниц можно выполнить дамп DBCC PAGE в режиме «dump style 3»: утилита интерпретирует страницу и представит данные учёта распределения в удобочитаемом виде.

Малоиспользуемые индексы в группах доступности – Часть 1

Автор: Aaron Bertrand , Managing Underused Indexes in SQL Server Availability Groups – Part 1
В рамках оптимизации производительности я оцениваю использование индексов на множестве экземпляров и в разных базах данных. Часто обнаруживается, что некоторые индексы используются нечасто или, по крайней мере на первый взгляд, кажутся неиспользуемыми. Поскольку мы используем группы доступности (AG), разные рабочие нагрузки выполняются на репликах в разных ролях. Все операции записи, разумеется, происходят на первичной. Однако некоторые запросы выполняются только на вторичных репликах для чтения (либо за счёт маршрутизации чтения, либо потому, что отдельные процессы вручную направляются на конкретные вторичные, либо же и то и другое). К сожалению, статистика использования индексов нигде не агрегируется по всем репликам сразу. Это значит, что анализ только первичной реплики даёт неполную картину. Как убедиться, что я учитываю активность индексов везде, а не только на первичной?

Какая часть журнала транзакций попадает в FULL BACKUP

Автор: Paul Randal, More on how much transaction log a full backup includes

В одной из статей я развенчал миф о том, какой объём журнала транзакций включает полная резервная копия. В комментариях мне задали вопрос (передаю по смыслу):

Полная резервная копия должна включать весь журнал транзакций от begin LSN самой старой активной транзакции на момент завершения части резервного копирования, читающей данные, и до LSN, на котором эта часть чтения данных заканчивается. Если этот begin LSN по времени позже LSN контрольной точки, которую резервное копирование делает в самом начале, то зачем полной резервной копии включать весь журнал транзакций между контрольной точкой и begin LSN? Для чего он нужен?

Я ответил шуткой, что проще объяснить это на доске с временной шкалой, — и с энтузиазмом сделал картинку в PowerPoint, чтобы показать нагляднее.

Когда добавляются теги версионирования?

Автор: Paul Randal, Inside the Storage Engine: When do versioning tags get added?

Ходит популярное мнение, что если включить моментальные снимки (snapshot isolation), а затем перестроить индексы, то все строки таблицы получат дополнительные 14-байтовые теги версионирования. Правда это или миф? Давайте проверим.

Новое в SQL Server 2025: Виртуализация данных с PolyBase

Автор: HugoQueiroz_MSFT, Data Virtualization with PolyBase for SQL Server 2025

Microsoft SQL Server 2025 представляет серьёзные улучшения в PolyBase, нацеленные на упрощение, повышение безопасности и лучшую совместимость между платформами. Опираясь на новшества, представленные в SQL Server 2022, SQL Server 2025 развивает виртуализацию данных, делая упор на удобство использования, укрепление безопасности за счёт расширенных вариантов аутентификации и улучшенную поддержку Linux.

Включаем умный параллелелизм вставки с помощью OPTIMIZE_FOR_SEQUENTIAL_KEY

Автор: Chandan Shukla, Unlocking High-Concurrency Inserts in SQL Server with OPTIMIZE_FOR_SEQUENTIAL_KEY

Системы с высокой параллельностью на бумаге всегда выглядят впечатляюще. Вы добавляете десятки процессорных ядер, увеличиваете объём памяти, проектируете схему с «лёгкими» вставками и с удовлетворением думаете: «Всё полетит». И, по правде говоря, при небольшой нагрузке так и выходит. Одна сессия, вставляющая строки в простую таблицу, даже не заставляет SQL Server напрячься.

Но картина меняется, как только вы начинаете нагружать систему сотнями параллельных вставок. Внезапно вся вычислительная мощь перестаёт иметь значение, потому что каждый поток бьётся за одно крошечное место в памяти: последнюю страницу кластерного индекса. Это классическая проблема «last-page insert contention problem». Она возникает всякий раз, когда ключ кластерного индекса последовательный — типичные IDENTITY, DATETIME или NEWSEQUENTIALID(). Каждая новая строка естественным образом «тянется» в конец B-дерева. Это звучит упорядоченно и эффективно, но при конкуренции — это ловушка. Вместо распределения вставок по нескольким страницам все они наваливаются на одну «горячую» страницу.

Интеграция SQL Server 2025 с S3

Автор: Anthony Nocentino, Setting up SQL Server S3 Object Storage Integration using MinIO with Docker Compose (Updated for SQL Server 2025)
Эта статья и репозиторий GitHub были обновлены для SQL Server 2025 RC1 и Ubuntu 24.04.
Новое в SQL Server 2025: Вам больше не нужно устанавливать службу PolyBase для работы с файлами Parquet в S3. Ранее, с SQL Server 2022, приходилось создавать пользовательский контейнер или вручную устанавливать PolyBase. Теперь интеграция с объектами S3 и поддержка Parquet работают прямо из коробки!

Когда после TRUNCATE страницы станут доступны для повторного использования?

Автор: Paul Randal, Search Engine Q&A #10: When are pages from a truncated table reused?

Это вопрос, который мне когда-то прислали — если таблица усекается внутри транзакции, что защищает целостность страниц таблицы в случае отката транзакции? Давайте выясним.

Подробно об очистке фантомных строк

Автор: Paul Randal, Inside the Storage Engine: Ghost cleanup in depth

За годы работы в команде Storage Engine я наблюдал много холивара на различных форумах по поводу задачи ghost cleanup. В предыдущих версиях с ней было несколько проблем (см. например, статью базы знаний — KB932115), и небыло доступно достаточно информации об этом. По какой-то причине я не добрался до публикации об этом в своём старом блоге, но сегодня я хочу подробно разобраться со всем этим.

Доказательство того, что записи не всегда физически хранятся в порядке ключа индекса

Автор: Paul Randal, Inside the Storage Engine: Proof that records are not always physically stored in index key order

Я упоминал это в публикации «Анатомия страницы» — существует распространённое заблуждение, будто записи в индексе ВСЕГДА хранятся в том же физическом порядке, что и логический порядок, определяемый ключом индекса. Вот доказательство того, что это неверно (и заодно небольшое знакомство с другими стилями дампа для DBCC PAGE).