Любопытный случай… карты прерванных XDES

Автор: Paul Randal, The Curious Case of… the aborted xdes map

На прошлой неделе мне по электронной почте задали вопрос о странных сообщениях в журнале ошибок, похожих на эти:

[DbId:12]. Removing xdes id: 0000:8112c9d0 from aborted xdes map.
[DbId:12]. Removing xdes id: 0000:8112b45e from aborted xdes map.
[DbId:12]. Removing xdes id: 0000:8112b403 from aborted xdes map.

Прежде всего, XDES — это структура данных (и класс C++) в механизме хранения (Storage Engine), представляющий транзакцию; это сокращение от «transaction descriptor» (дескриптор транзакции). Идентификатор XDES — это тот же самый идентификатор, который вы видите в столбце Transaction ID в выводе функции fn_dblog для изучения содержимого журнала транзакций (см. примеры здесь).

Эти сообщения безвредны и связаны с внутренней работой функции Ускоренного восстановления баз данных (Accelerated Database Recovery, ADR), которая позволяет мгновенно откатывать транзакции с помощью умного механизма версионности.

Любопытный случай… ограничения размера строки в 8060 байт

Автор: Paul Randal, The Curious Case of… the 8060-byte row size limit

На прошлой неделе мне задали вопрос о том, почему существует ограничение в 8060 байт на размер строки и почему страницы файлов данных иногда показывают более 8060 байт свободного места при просмотре с помощью DBCC PAGE.

Прежде чем объяснять, позвольте мне прояснить, что ограничение в 8060 байт касается только той части записи, которая хранится на странице данных или индекса в единице распределения «внутристроковых данных» (in-row data). Запись может иметь множество столбцов LOB, которые хранятся вне строки в единице распределения «данных LOB» (например, столбцы varchar(max) или FILESTREAM), и/или не-LOB столбцов переменной длины, которые были вытеснены из строки для хранения в единице распределения «переполнения строки» (например, столбцы char(1-8000), nchar(1-4000) или sqlvariant). Таким образом, фактический размер строки практически не ограничен.

Я мог бы перефразировать исходный вопрос так: учитывая, что размер страницы составляет 8192 байта, и только 96 байт используется для заголовка страницы, почему размер внутристроковой записи ограничен 8060 байтами? Куда деваются остальные 36 байт доступного пространства?

Любопытный случай… восстановления таблицы в другую базу данных

Автор: Paul Randal, The Curious Case of… restoring a table into a different database

(«Любопытный случай…» раньше был частью нашей двухнедельной рассылки, но мы решили сделать его обычной записью в блоге, чтобы он мог выходить иногда чаще. Он рассказывает о чём-то интересном, с чем столкнулся один из нас при работе с клиентом, проведении тестов или в случайном вопросе от сообщества.)

В одном списке рассылки, на который я подписан, сегодня кто-то поинтересовался возможностью реализации восстановления таблицы в другую базу данных, в которой уже есть свои данные. Это интересное умственное упражнение, поэтому я написал ответ для списка, а потом подумал, что из него получится хорошая запись в блоге.

Восстановление таблицы в другую базу данных, где уже есть данные, на самом деле гораздо сложнее, чем может показаться.

Ленивое усечение журнала, или почему VLF могут оставаться со статусом 2 после очистки журнала

Автор: Paul Randal, Lazy log truncation or why VLFs might stay at status 2 after log clearing

Ранее мне прислали интересный вопрос о том, почему человек видит множество VLF (виртуальных файлов журнала) в журнале со статусом = 2 (что означает «активный») после очистки (также известной как «усечение») журнала, при том что log_reuse_wait_desc показывает NOTHING.

Я немного покопался и всё, что смог найти, — это старая запись в блоге от 2013 года, которая демонстрирует это поведение и упоминает, что оно происходит при зеркальном отображении и в группах доступности. Я не слышал об этом поведении раньше, но предположил причину и подтвердил её с командой SQL Server.

Новое значение статуса VLF

Автор: Paul Randal, New VLF status value

По крайней мере с тех пор, как я начал работать в команде SQL Server (сразу после выхода версии 7.0) и до недавнего времени, существовало всего два кода статуса VLF (виртуального файла журнала):

• 0 = VLF не активен (т.е. его можно (повторно) активировать и перезаписать)
• 1 = не используется, и, кажется, никто не помнит, что это раньше означало
• 2 = VLF активен, потому что хотя бы одна запись журнала в нём «требуется» SQL Server по какой-либо причине (например, ещё не была включена в резервную копию журнала или не просканирована репликацией)

Несколько недель назад я узнал о новом коде статуса VLF, который был добавлен ещё в SQL Server 2012, но не был широко известен до недавнего времени (по крайней мере, я никогда с ним не сталкивался в реальных условиях). Я провёл несколько обсуждений с другом из Microsoft (Шоном Галларди, PFE и MCM из Тампа), которому удалось покопаться в коде, чтобы выяснить, когда он используется.

Read committed не гарантирует многого…

Автор: Paul Randal, Read committed doesn’t guarantee much…

Некоторое время назад я участвовал в переписке по электронной почте, где люди обсуждали некоторое «странное» поведение SQL Server. Проблема возникала в SQL Server 2016 при использовании уровня изоляции по умолчанию — read committed. Сценарий был следующим:

1. Создать таблицу с несколькими столбцами
2. Пакет 1: В одном окне SSMS выполнить следующее (что занимает 10 секунд):
   • Начать транзакцию
   • Вставить 1000 строк в таблицу с задержкой WAITFOR DELAY 0.01 секунды между каждой вставкой
   • Зафиксировать транзакцию
3. Пакет 2: Во втором окне SSMS:
   • Выполнить SELECT * из таблицы

«Странное» поведение заключается в том, что когда выборка «Пакета 2» завершается после того, как была заблокирована транзакцией «Пакета 1», она возвращает не все 1000 строк (даже несмотря на то, что «Пакет 1» завершился). Более того, в зависимости от того, когда была запущена выборка «Пакета 2» в течение 10 секунд выполнения «Пакета 1», «Пакет 2» возвращает разное количество строк. Такое поведение также сообщалось и в более ранних версиях SQL Server. Это легко воспроизвести в SQL Server 2016/2017 и можно воспроизвести во всех более ранних версиях с одним изменением конфигурации (подробнее чуть позже).

Диагностика проблем с производительностью репликации транзакций

Автор: VinaySarangam, Troubleshooting Replication Performance Issues

Этот документ помогает диагностировать или решать проблемы, связанные с производительностью репликации.

Почему в моей таблице-куче много пустых страниц?

Автор: Paul Randal, SQLskills SQL101: Why does my heap have a bunch of empty pages?

У SQLskills есть инициатива вести блог на базовые темы, которую мы называем SQL101. Мы все пишем о вещах, которые часто делаются неправильно, технологиях, используемых неверно, или случаях, когда существует множество заблуждений, ведущих к серьёзным проблемам.

Вот вопрос, который мне часто задают (перефразирую):

«У меня есть большая таблица-куча, в которой пространство не освобождается, когда я удаляю большое количество записей, но когда я сжимаю базу данных, размер кучи уменьшается. Можете объяснить?»

Как оператор SELECT может изменить базу данных?

Автор: Paul Randal, SQLskills SQL101: How can a SELECT cause a database to change?

Как писала в блоге Кимберли, SQLskills начинает инициативу — ведение блога на базовые темы, которую мы называем SQL101. Мы все будем писать о вещах, которые часто делаются неправильно, о технологиях, используемых неверно, или о случаях, когда существует множество заблуждений, ведущих к серьёзным проблемам.

Это интересное заблуждение, о котором меня спрашивали на прошлой неделе: (перефразируя) «Наверняка операция SELECT не может привести к изменению базы данных, потому что она просто читает данные, а не изменяет их каким-либо образом, верно?».

Что ж, нет. На самом деле существует довольно много побочных эффектов у запросов, которые только читают данные и никогда не выполняют изменения данных (не считая, конечно, SELECT ... INTO). Вот четыре, которые сразу приходят на ум…

Производительность REGEX в SQL Server 2025 не так уж плоха!

Автор: Brent Ozar, Update: SQL Server 2025’s REGEX Performance Isn’t So Bad!

Ещё в марте 2025 года, когда Microsoft впервые анонсировала поддержку REGEX в SQL Server 2025 и Azure SQL DB, я провёл быстрое тестирование, и производительность была ужасающей. Она была плохой в трёх разных аспектах:

1. Использование ЦП было ужасным — сжигалось 60 секунд процессорного времени для проверки нескольких миллионов строк
2. Он отказывался использовать индекс
3. Оценка кардинальности была ужасной, жёстко закодирована на уровне 30% от таблицы

После комментария Эрланда Соммарског в этом месяце я вернулся и снова запустил тесты с релизной версией SQL Server 2025. Отличные новости! Microsoft исправила 1 из проблем, и... ну, одна из них немного хитрая. Для демонстрации я собираюсь использовать большую базу данных Stack Overflow за апрель 2024 года, чтобы создать наихудший сценарий, затем начать с индекса на небольшой таблице Users и запросить её через regex, как мы делали в статье от марта 2025 года.

Как хранятся значения по умолчанию?

Автор: Paul Randal, How are default column values stored?

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

Почему страницы PFS нельзя восстановить

Автор: Paul Randal, Why PFS pages cannot be repaired

В Twitter состоялось краткое обсуждение того, почему страницы PFS (повреждённый заголовок, а не отдельные байты PFS) нельзя восстановить (поводом стал вопрос #sqlhelp о том, почему для них невозможно восстановление отдельной страницы, в отличие от других карт распределения базы данных). Для справки: их также нельзя исправить с помощью автоматического восстановления страниц с зеркала или в группе доступности (AG).

Страницы PFS встречаются каждые 8088 страниц в каждом файле данных и хранят байт информации о себе и о следующих 8087 страницах. Самая важная информация, которую они хранят, — это то, выделена ли страница (используется) или нет. Подробнее о страницах PFS и других картах распределения базы данных можно прочитать в этой записи блога.

Итак, почему их не может восстановить DBCC CHECKDB, когда все остальные карты распределения базы данных могут?

Что такое ожидания LOGMGR_RESERVE_APPEND?

Автор: Paul Randal, What are LOGMGR_RESERVE_APPEND waits?

Мне прислали вопрос по электронной почте о причине возникновения ожиданий LOGMGR_RESERVE_APPEND, и в следующем выпуске рассылки Insider я дал краткое объяснение. Это очень необычный тип ожидания, чтобы видеть его в качестве основного на сервере, и, по сути, его вообще редко встречают.

Код для анализа иерархии транзакций в журнале

Автор: Paul Randal, Code to analyze the transaction hierarchy in the log

В рассылке для MVP было обсуждение представления sys.dm_tran_database_transactions и того, как с его помощью нельзя точно определить, сколько журнала сгенерировала операция, поскольку оно не предоставляет сводных метрик для подтранзакций внутри внешней транзакции. Это делает его вывод несколько неинтуитивным.

Это обсуждение побудило меня написать код, который я давно собирался сделать, ещё когда в SQL Server 2012 появилось поле в записях журнала LOP_BEGIN_XACT, отслеживающее идентификатор родительской транзакции, что позволяет исследовать иерархию транзакций.

Он предоставляет две хранимые процедуры, sp_SQLskillsAnalyzeLog и sp_SQLskillsAnalyzeLogInner, где первая использует вторую, а вторая рекурсивно вызывает саму себя.

Сравнение одноколоночных, многоколоночных и фильтрованных статистик в SQL Server

Автор: Kendra Little, Comparing Single Column, Multi-Column, and Filtered Statistics in SQL Server

Статистики в SQL Server теоретически просты: они помогают оптимизатору оценить, сколько строк может вернуть запрос.

На практике? Всё быстро становится странным. Особенно когда вы начинаете фильтровать по нескольким столбцам или задаётесь вопросом, почему оптимизатор думает, что вернутся миллионы строк, когда вы знаете, что их всего несколько сотен тысяч.

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

Восстановление данных: странные сбои SELECT при повреждении

Автор: Paul Randal, Data recovery: investigating weird SELECT failures around corruption

В списке рассылки MCM возникла интересная проблема с повреждением, и после того, как я её разобрал, подумал, что из этого получится хорошая статья в блоге на случай, если кто-то столкнётся с подобной проблемой.

В двух словах, проблема заключалась в таком повреждении, что простой запрос SELECT * завершался ошибкой, а запрос SELECT * с предложением ORDER BY работал.

Давайте разбираться!

Использование fn_dblog, fn_dump_dblog и восстановление с STOPBEFOREMARK до LSN

Автор: Paul Randal, Using fn_dblog, fn_dump_dblog, and restoring with STOPBEFOREMARK to an LSN

Я уже много писал в блоге о недокументированной функции fn_dblog, в написании которой я помогал (и мне ещё многое предстоит :-)), но вот одна функция, которую я ранее не упоминал в блоге: fn_dump_dblog (хотя я рассказывал о ней на конференциях).

Рассмотрим сценарий: кто-то удалил таблицу, и вы хотите выяснить, когда это произошло и, возможно, кто это сделал. Трассировка по умолчанию также переполнилась, поэтому вы больше не можете получить оттуда информацию об операции DDL.

Как работали бы индексы на читаемых вторичных репликах групп доступности (AG)?

Автор: Paul Randal, How would indexes on AG readable secondaries work?

В рассылке MVP появилось предложение ввести временные некластерные индексы на читаемых вторичных репликах AG — по аналогии с временной статистикой. Я ответил, что, на мой взгляд, реализовать это чрезвычайно трудно, и пообещал объяснить почему. Ниже — моя аргументация. Замечу: это не исчерпывающий перечень, а лишь основные проблемы, которые я вижу.

Незавершённые контрольные точки и восстановление

Автор: Paul Randal, Incomplete checkpoints and recovery

Ещё в 2009 году я писал о том, как работают контрольные точки (см. How do checkpoints work and what gets logged), и недавно получил по почте вопрос, который, как мне показалось, стоит оформить в короткую статью.

Вопрос (пересказ): Что произойдёт, если контрольная точка начнётся, но не успеет завершиться до сбоя? Будет ли она использована при восстановлении после сбоя?

Важное изменение алгоритма создания VLF в SQL Server 2014

Автор: Paul Randal, Important change to VLF creation algorithm in SQL Server 2014

После выхода SQL Server 2014 ходили разговоры об изменениях в количестве VLF, создаваемых при увеличении или автоувеличении журнала (далее буду говорить «автоувеличение», так как это самый распространённый сценарий). Я немного поэкспериментировал и решил, что разгадал изменение алгоритма. Оказалось, нет. В рассылке MVP вопрос вспыхнул с новой силой, и мы коллективно пришли к выводу, что алгоритм ведёт себя недетерминированно… иначе говоря, мы не понимали, что он делает. Я написал друзьям в CSS, которые изучили код (спасибо, Bob Ward и Suresh Kandoth!) и объяснили изменение.

Изменение весьма существенное: оно нацелено на то, чтобы многочисленные автоувеличения не создавали гигантские количества VLF. Это здорово, потому что слишком много VLF (зависит от размера журнала, но многие тысячи — это слишком много) способны вызвать целый ворох проблем с производительностью при резервном копировании, восстановлении, очистке журнала, репликации, восстановлении после сбоя, откатах и даже при обычных операциях DML.