Какая часть журнала транзакций попадает в 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).

Страницы IAM, цепочки IAM и единицы распределения

Автор: Paul Randal, Inside the Storage Engine: IAM pages, IAM chains, and allocation units

Это компиляция из ранее опубликованного материала с добавлением новых фрагментов вывода DBCC PAGE.

Анатомия экстента

Автор: Paul Randal, Inside the Storage Engine: Anatomy of an extent

В предыдущей публикации я рассказал о страницах базы данных — их структуре и некоторых разновидностях страниц. Теперь я хотел бы объяснить, как страницы объединяются в т.н. экстенты. Экстент представляет собой группу из восьми физически последовательных страниц в файле данных. Экстенты всегда выравниваются по границам 64 КБ (то есть по границам 8 страниц), начиная с начала файла. Экстенты и все их свойства остаются неизменными во всех версиях, но способы их использования различаются. Существует два типа экстентов: смешанные экстенты и однородные (uniform) экстенты.

Использование DBCC PAGE и DBCC IND для доказательства, что расщепление не откатывается

Автор: Paul Randal, Inside the Storage Engine: Using DBCC PAGE and DBCC IND to find out if page splits ever roll back

Прежде чем переходить к механизму работы, хочу разобрать две команды, которые я буду часто использовать — DBCC PAGE и DBCC IND. Обе они (на момент написания статьи) являются недокументированными и не поддерживаются официально, но абсолютно безопасны в применении, так как активно используются внутри и вне Microsoft при диагностике. Тем не менее, используйте их на свой страх и риск. Эти команды хорошо известны в сообществе MSSQL, я и другие специалисты уже рассказывали о них ранее.

Чтобы показать, как они работают, я приведу простой сценарий, доказывающий, что расщепления страниц никогда не откатываются. У меня был спор на эту тему, и ответ всегда один — нет. Расщепление страницы происходит тогда, когда вставка или обновление должны произойти в определённом месте индексной страницы, но там не хватает места для новой или обновлённой записи. Расщепления выполняются как отдельные «системные» транзакции. После того как системная транзакция зафиксирована, она не может быть отменена — даже если откатывается пользовательская транзакция, частью которой она была.

Анатомия страницы с помощью DBCC PAGE

Автор: Paul Randal, Inside the Storage Engine: Anatomy of a page

Очередная статья из серии «Inside the Storage Engine» посвящена устройству страниц баз данных. Страницы нужны для хранения записей — это блок размером 8192 байта (8 КБ) в файле данных базы. Они выровнены по границам 8 КБ внутри файлов данных, начиная со смещения 0 байт в файле. Ниже — упрощённая иллюстрация базовой структуры: