В этой статье я хочу развенчать распространённый миф о том, что null bitmap содержит биты только для допускающих NULL столбцов. Это не так — там по одному биту на каждый столбец в определении таблицы, при условии, что в таблице есть хотя бы один допускающий NULL столбец. «Неиспользуемые» биты всегда равны 1, то есть означают «NULL».
Правка 2016: Этот флаг трассировки требуется во всех версиях SQL Server включая SQL Server 2014. На каждом экземпляре SQL Server в мире он должен быть включён. В SQL Server 2016 поведение, включаемое этим флагом, стало значением по умолчанию, поэтому сам TF1118 больше не требуется и не оказывает эффекта.
Вокруг флага трассировки TF1118 существует немало путаницы и заблуждений. Он переключает выделение страниц в tempdb: вместо одиночных распределений для первых 8 страниц они сразу выделяются как экстент (8 страниц). Он применяется, чтобы при высокой нагрузке ослабить конкуренцию за карты распределения (allocation bitmap contention) в tempdb, которая бывает связана, например, с массовым созданием и удалением маленьких временных таблиц.
Есть несколько мест, которые способны вызвать путаницу, на каждом из которых я остановлюсь по порядку. Затем я докажу, что TF1118 по‑прежнему работает во всех версиях SQL Server вплоть до 2014 включительно.
В предыдущих статьях о FILESTREAM я разбирал структуру каталогов контейнера данных FILESTREAM и то, как сопоставлять каталоги с таблицами и столбцами базы данных. В этой статье я объясню, как и когда работает процесс сборки мусора FILESTREAM, поскольку, похоже, нигде это не задокументировано (даже в статье FILESTREAM Storage in SQL Server 2008, которую я писал для Microsoft — предполагаемая глубина не включала такой низкий уровень деталей). Похоже, существует немало путаницы вокруг того, как выполняются обновления данных FILESTREAM и когда удаляются старые версии файлов FILESTREAM. Я объясню, как всё устроено, а затем покажу на примере.
Периодически (ладно, честно говоря, очень часто) мой внутренний список «надо бы об этом написать» разрастается до таких размеров, что меня охватывает почти непреодолимое желание. К счастью, эти порывы заканчиваются тем, что я публикую сразу несколько записей — иначе кто знает, в какие неприятности я мог бы вляпаться? :-)
Для начала сегодня — довольно глубокие внутренности о том, как работает журнал транзакций в одной конкретной ситуации. Этот вопрос всплывал несколько раз на последних курсах по внутреннему устройству и обслуживанию, которые я вёл, в модуле про журнал транзакций, так что я решил написать статью, подтверждающую, что мой ответ верен. Проще всего сформулировать вопрос с картинкой, позаимствованной из моей статьи в журнале TechNet Magazine (Ведение журнала и восстановление в SQL Server).
Ещё в первых статьях блога я написал подробное описание «фантомных» записей (ghost records) и процесса их очистки — см. статью «Подробно об очистке фантомных строк». На занятии возник вопрос, который стоит разобрать отдельно: возникают ли «фантомные» записи в кучах (heap)? Ответ — нет, не при обычной работе.
После того как я написал FILESTREAM Whitepaper для Microsoft, мне стали часто задавать вопросы о структуре контейнера данных FILESTREAM. Контейнер данных FILESTREAM — это технический термин для структуры каталогов NTFS, где хранятся все данные FILESTREAM.
Каждый раз, когда я веду курс, меня удивляет, сколько администраторов баз данных не знают о мгновенной инициализации файлов (instant file initialization). Не желая повторять публикации, уже написанные другими, кратко: эта возможность позволяет создавать или увеличивать файл «мгновенно», без заполнения нового пространства в файле нулями. Это особенно полезно в сценариях аварийного восстановления, когда перед восстановлением базы данные файлы могут понадобиться впервые — с включённой мгновенной инициализацией исключается лишняя задержка. Подробности см. в записи Кимберли «Instant Initialization – What, Why and How?».
А теперь — к причине появления это статьи: хочу развеять несколько заблуждений, которые продолжаю слышать.
Этот вопрос прозвучал на одном из моих недавних занятий: если массив смещений столбцов переменной длины в записи хранит только смещения, то как механизм хранения находит конкретный столбец переменной длины?
Сомнение возникает потому, что в самой записи нет пометки, какой столбец переменной длины где расположен — как это работает? Ответ состоит из двух частей: это и NULL‑битовая карта (null bitmap) в записи, и метаданные таблицы/индекса, хранящиеся в системных таблицах. Все столбцы переменной длины имеют фиксированную «позицию» внутри переменной части записи в том случае, если их значение не равно NULL. Давайте покажу, что это значит.
Грег задал вопрос по поводу скрипта для анализа содержимого буферного пула (передаю по смыслу): почему на загруженных промышленных системах в буферном пуле оказывается столь высокая доля «грязных» страниц tempdb?
Ответ связан с возможностью восстановления базы tempdb. Одна из причин существования контрольной точки (checkpoint) — ограничить длительность фазы «redo» при восстановлении после сбоя: это этап, когда записи журнала заново «прокручиваются» на находящихся на дисках страницах, для которых модифицированный образ страницы так и не был записан на диск после фиксации транзакций. Для этого в базах данных выполняются автоматические контрольные точки.
Однако tempdb после сбоя не восстанавливается — он заново создаётся. Это означает, что время восстановления tempdb не является проблемой, а значит, нет и необходимости в автоматических контрольных точках. Иными словами, для tempdb срабатывает лишь один триггер автоматической контрольной точки: когда его файл журнала заполняется примерно на 70%.
По этой причине на загруженных системах пользовательские базы будут проходить контрольные точки гораздо чаще, чем tempdb. А на системе, где tempdb тоже используется активно, в буферном пуле в любой момент времени будет заметно больше «грязных» страниц именно из tempdb.
Это короткая статья, навеянная вопросом из письма (спасибо, Маркос!), и заодно отличный повод показать DMV, о котором я давно хотел написать. А ещё сейчас в Редмонде ужасная погода, так что на улицу не выйти — блогинг послужит стратегией уклонения от работы этим днём :-).
(В пересказе) вопрос таков: Контрольная точка — это процесс, который записывает все «грязные» страницы на диск и работает в разрезе базы данных. Но если кеш данных может хранить страницу из любой базы, как же контрольная точка понимает, какие страницы проверять на «грязность»? Она просматривает буферный пул в поисках страниц конкретной базы X и обрабатывает только их? Или кеш данных как‑то разделён по базам? Хотелось бы лучше понимать, как это устроено «под капотом».
Повреждение базы данных в SQL Server бывает редко, но почти всегда имеет серьёзные последствия. Когда оно возникает, под угрозой оказываются требования ACID — фундамент транзакционной целостности — и это может привести к простоям, потере данных и операционным рискам. В этой статье рассматриваются:
Итак, что такое страница заголовка файла? В каждом файле данных самая первая страница 8КБ (то есть страница 0 в файле) отведена для хранения всех метаданных об этом файле. Как и для загрузочной страницы, вы можете посмотреть её содержимое с помощью DBCC PAGE — команда интерпретирует все поля, — либо воспользоваться командой DBCC FILEHEADER, которая делает это ещё удобнее. Эта команда недокументирована и не поддерживается (точно так же, как DBCC DBINFO для просмотра загрузочной страницы базы), но о ней уже писали и говорили в интернете, так что её существование не секрет.
Для начала: что такое загрузочная страница (boot page)? В каждой базе данных есть единственная страница, на которой хранится критически важная информация о самой базе. Это всегда страница 9 в файле 1 (первый файл в файловой группе PRIMARY). Её можно посмотреть с помощью DBCC PAGE — команда интерпретирует все поля. Есть и другая команда, DBCC DBINFO, которая тоже выдаёт всю эту информацию (фактически, код DBCC PAGE вызывает тот же внутренний код дампа). Команда недокументирована и не поддерживается, но широко известна и «задокументирована» во множестве мест в сети — и, поскольку использует тот же код, что и DBCC PAGE, по моему мнению, она столь же безопасна в использовании.
Это действительно интересный вопрос, который возник на курсе Microsoft Certified Architect, который я сейчас веду: если в базе данных включена защита от «оборванных» страниц (torn-page protection), а затем включаются контрольные суммы страниц (page checksums), теряется ли при этом действующая проверка на torn-page?
Вопрос важный, потому что включение контрольных сумм страниц не приводит к мгновенному появлению checksum на всех уже выделенных страницах (контрольная сумма появится лишь после того, как страница будет прочитана в буферный пул, изменена и затем записана на диск). Если бы существующая torn-page‑защита полностью «отбрасывалась» при включении контрольных сумм, страницы оставались бы без защиты до тех пор, пока на них не появятся checksums. Я не помнил точного ответа, поэтому провёл эксперимент!
Один из минусов того, что я больше не в команде 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
)Это обновлённая версия статьи из моего прежнего блога о механизме хранения; теперь она также охватывает страницы карт DIFF и ML.
В предыдущих статьях этой серии я разобрал основы хранения в файлах базы данных:
Последние элементы в «головоломке» распределения — это прочие страницы-карты учёта распределения: страницы GAM, SGAM, PFS, ML map и DIFF map. Всё, что описано ниже, справедливо для версий на сегодня. Для любой из этих страниц можно выполнить дамп DBCC PAGE в режиме «dump style 3»: утилита интерпретирует страницу и представит данные учёта распределения в удобочитаемом виде.
В одной из статей я развенчал миф о том, какой объём журнала транзакций включает полная резервная копия. В комментариях мне задали вопрос (передаю по смыслу):
Полная резервная копия должна включать весь журнал транзакций от begin LSN самой старой активной транзакции на момент завершения части резервного копирования, читающей данные, и до LSN, на котором эта часть чтения данных заканчивается. Если этот begin LSN по времени позже LSN контрольной точки, которую резервное копирование делает в самом начале, то зачем полной резервной копии включать весь журнал транзакций между контрольной точкой и begin LSN? Для чего он нужен?
Я ответил шуткой, что проще объяснить это на доске с временной шкалой, — и с энтузиазмом сделал картинку в PowerPoint, чтобы показать нагляднее.
Ходит популярное мнение, что если включить моментальные снимки (snapshot isolation), а затем перестроить индексы, то все строки таблицы получат дополнительные 14-байтовые теги версионирования. Правда это или миф? Давайте проверим.
Это вопрос, который мне когда-то прислали — если таблица усекается внутри транзакции, что защищает целостность страниц таблицы в случае отката транзакции? Давайте выясним.
За годы работы в команде Storage Engine я наблюдал много холивара на различных форумах по поводу задачи ghost cleanup. В предыдущих версиях с ней было несколько проблем (см. например, статью базы знаний — KB932115), и небыло доступно достаточно информации об этом. По какой-то причине я не добрался до публикации об этом в своём старом блоге, но сегодня я хочу подробно разобраться со всем этим.