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»: утилита интерпретирует страницу и представит данные учёта распределения в удобочитаемом виде.

Какая часть журнала транзакций попадает в 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-байтовые теги версионирования. Правда это или миф? Давайте проверим.

Когда после 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 байт в файле. Ниже — упрощённая иллюстрация базовой структуры: