Почему буферный пул содержит так много «грязных» страниц tempdb?

Автор: Paul Randal, Why does the buffer pool contain so many dirty tempdb?

Грег задал вопрос по поводу скрипта для анализа содержимого буферного пула (передаю по смыслу): почему на загруженных промышленных системах в буферном пуле оказывается столь высокая доля «грязных» страниц tempdb?

Ответ связан с возможностью восстановления базы tempdb. Одна из причин существования контрольной точки (checkpoint) — ограничить длительность фазы «redo» при восстановлении после сбоя: это этап, когда записи журнала заново «прокручиваются» на находящихся на дисках страницах, для которых модифицированный образ страницы так и не был записан на диск после фиксации транзакций. Для этого в базах данных выполняются автоматические контрольные точки.

Однако tempdb после сбоя не восстанавливается — он заново создаётся. Это означает, что время восстановления tempdb не является проблемой, а значит, нет и необходимости в автоматических контрольных точках. Иными словами, для tempdb срабатывает лишь один триггер автоматической контрольной точки: когда его файл журнала заполняется примерно на 70%.

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

Что находится в буферном пуле?

Автор: Paul Randal, Inside the Storage Engine: What’s in the buffer pool?

Это короткая статья, навеянная вопросом из письма (спасибо, Маркос!), и заодно отличный повод показать DMV, о котором я давно хотел написать. А ещё сейчас в Редмонде ужасная погода, так что на улицу не выйти — блогинг послужит стратегией уклонения от работы этим днём :-).

(В пересказе) вопрос таков: Контрольная точка — это процесс, который записывает все «грязные» страницы на диск и работает в разрезе базы данных. Но если кеш данных может хранить страницу из любой базы, как же контрольная точка понимает, какие страницы проверять на «грязность»? Она просматривает буферный пул в поисках страниц конкретной базы X и обрабатывает только их? Или кеш данных как‑то разделён по базам? Хотелось бы лучше понимать, как это устроено «под капотом».

Контроль состояния распределённой группы доступности: T-SQL и Zabbix

Автор: Pablo Echeverria, Distributed Availability Group Health: T-SQL and Zabbix

После создания распределённой группы доступности по шагам из моей статьи «SQL Server 2022: Распределённая группа доступности без кластера», как проверить, что синхронизация между дата-центрами в порядке?

В SQL Server Management Studio, если щёлкнуть правой кнопкой по распределённой группе доступности, вы заметите, что нет панели мониторинга, подтверждающей корректную синхронизацию данных между дата-центрами:

Даже если проверять панели первичного и вторичного дата-центров по отдельности, вы не увидите, есть ли проблема «между ними».

Повреждения баз данных SQL Server: обнаружение, причины и некоторые подробности о DBCC CHECKDB

Автор: MSFTPawelM, SQL Server Database Corruption: Causes, Detection, and some details behind DBCC CHECKDB

Повреждение базы данных в SQL Server бывает редко, но почти всегда имеет серьёзные последствия. Когда оно возникает, под угрозой оказываются требования ACID — фундамент транзакционной целостности — и это может привести к простоям, потере данных и операционным рискам. В этой статье рассматриваются:

• распространённые причины повреждений;
• как «под капотом» работает DBCC CHECKDB;
• рекомендации по настройке производительности при запуске CHECKDB;
• типовые сообщения об ошибках и их смысл;
• лучшие практики предотвращения и восстановления.

Повреждение страницы заголовка файла

Автор: Paul Randal, Search Engine Q&A #21: File header pages, and file header corruption

Итак, что такое страница заголовка файла? В каждом файле данных самая первая страница 8КБ (то есть страница 0 в файле) отведена для хранения всех метаданных об этом файле. Как и для загрузочной страницы, вы можете посмотреть её содержимое с помощью DBCC PAGE — команда интерпретирует все поля, — либо воспользоваться командой DBCC FILEHEADER, которая делает это ещё удобнее. Эта команда недокументирована и не поддерживается (точно так же, как DBCC DBINFO для просмотра загрузочной страницы базы), но о ней уже писали и говорили в интернете, так что её существование не секрет.

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

Автор: Aaron Bertrand , Managing Underused Indexes in SQL Server Availability Groups – Part 2

В первой части статьи «Малоиспользуемые индексы в группах доступности – Часть 1» я показал, как с помощью динамического SQL собрать статистику использования индексов для заданной таблицы со всех реплик в группе доступности. Знать использование по всем нагрузкам, безусловно, лучше, чем смотреть только на первичную или на одну вторичную. Но что если я хочу принимать ещё более взвешенные решения, добавив к выводу количество строк, размер и столбцы индексов?

Boot Page и их повреждения

Автор: Paul Randal, Search Engine Q&A #20: Boot pages, and boot page corruption

Для начала: что такое загрузочная страница (boot page)? В каждой базе данных есть единственная страница, на которой хранится критически важная информация о самой базе. Это всегда страница 9 в файле 1 (первый файл в файловой группе PRIMARY). Её можно посмотреть с помощью DBCC PAGE — команда интерпретирует все поля. Есть и другая команда, DBCC DBINFO, которая тоже выдаёт всю эту информацию (фактически, код DBCC PAGE вызывает тот же внутренний код дампа). Команда недокументирована и не поддерживается, но широко известна и «задокументирована» во множестве мест в сети — и, поскольку использует тот же код, что и DBCC PAGE, по моему мнению, она столь же безопасна в использовании.

Отключается ли "torn page detection" при включении "page checksums"?

Автор: Paul Randal, Inside The Storage Engine: Does turning on page checksums discard any torn-page protection?

Это действительно интересный вопрос, который возник на курсе Microsoft Certified Architect, который я сейчас веду: если в базе данных включена защита от «оборванных» страниц (torn-page protection), а затем включаются контрольные суммы страниц (page checksums), теряется ли при этом действующая проверка на torn-page?

Вопрос важный, потому что включение контрольных сумм страниц не приводит к мгновенному появлению checksum на всех уже выделенных страницах (контрольная сумма появится лишь после того, как страница будет прочитана в буферный пул, изменена и затем записана на диск). Если бы существующая torn-page‑защита полностью «отбрасывалась» при включении контрольных сумм, страницы оставались бы без защиты до тех пор, пока на них не появятся checksums. Я не помнил точного ответа, поэтому провёл эксперимент!

От тушения пожаров к созиданию будущего: 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), разные рабочие нагрузки выполняются на репликах в разных ролях. Все операции записи, разумеется, происходят на первичной. Однако некоторые запросы выполняются только на вторичных репликах для чтения (либо за счёт маршрутизации чтения, либо потому, что отдельные процессы вручную направляются на конкретные вторичные, либо же и то и другое). К сожалению, статистика использования индексов нигде не агрегируется по всем репликам сразу. Это значит, что анализ только первичной реплики даёт неполную картину. Как убедиться, что я учитываю активность индексов везде, а не только на первичной?