Исследуем fn_dblog(): недокументированная функция SQL Server для чтения журнала транзакций

Автор: SQLYARD, Exploring fn_dblog(): The Undocumented SQL Server Function That Reads the Transaction Log

SQL Server ведёт детальную запись каждого изменения в журнале транзакций. Обычно вы взаимодействуете с ним косвенно — через резервные копии, репликацию или восстановление. Но существует скрытая, недокументированная функция fn_dblog(), которая позволяет напрямую запрашивать активный журнал транзакций.

Эта функция может помочь вам:

• Расследовать удаления и изменения данных.
• Отслеживать активность DDL и DML.
• Устранять проблемы вроде случайной потери данных.
• Анализировать поведение репликации и восстановления.

Поскольку функция недокументирована, Microsoft её официально не поддерживает и она может измениться без предупреждения. Тем не менее, для администраторов БД и специалистов по расследованию инцидентов это мощный инструмент.

Структура каталога FILESTREAM

Автор: Paul Randal, FILESTREAM directory structure

После того как я написал FILESTREAM Whitepaper для Microsoft, мне стали часто задавать вопросы о структуре контейнера данных FILESTREAM. Контейнер данных FILESTREAM — это технический термин для структуры каталогов NTFS, где хранятся все данные FILESTREAM.

Заблуждения вокруг мгновенной инициализации файлов

Автор: Paul Randal, Misconceptions around instant file initialization

Каждый раз, когда я веду курс, меня удивляет, сколько администраторов баз данных не знают о мгновенной инициализации файлов (instant file initialization). Не желая повторять публикации, уже написанные другими, кратко: эта возможность позволяет создавать или увеличивать файл «мгновенно», без заполнения нового пространства в файле нулями. Это особенно полезно в сценариях аварийного восстановления, когда перед восстановлением базы данные файлы могут понадобиться впервые — с включённой мгновенной инициализацией исключается лишняя задержка. Подробности см. в записи Кимберли «Instant Initialization – What, Why and How?».

А теперь — к причине появления это статьи: хочу развеять несколько заблуждений, которые продолжаю слышать.

Как Storage Engine находит столбцы переменной длины?

Автор: Paul Randal, Search Engine Q&A #27: How does the storage engine find variable-length columns?

Этот вопрос прозвучал на одном из моих недавних занятий: если массив смещений столбцов переменной длины в записи хранит только смещения, то как механизм хранения находит конкретный столбец переменной длины?

Сомнение возникает потому, что в самой записи нет пометки, какой столбец переменной длины где расположен — как это работает? Ответ состоит из двух частей: это и NULL‑битовая карта (null bitmap) в записи, и метаданные таблицы/индекса, хранящиеся в системных таблицах. Все столбцы переменной длины имеют фиксированную «позицию» внутри переменной части записи в том случае, если их значение не равно NULL. Давайте покажу, что это значит.

Почему буферный пул содержит так много «грязных» страниц 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. Я не помнил точного ответа, поэтому провёл эксперимент!