Когда используется быстрое восстановление?

Автор: Paul Randal, When is fast recovery used?

Разберёмся с вопросом, возникшем в рассылке MCM. Речь шла о быстром восстановлении (подробно я объяснял его в заметке «Логирование блокировок и быстрое восстановление»), а если кратко — это возможность редакции Enterprise предоставить доступ к базе данных после завершения фазы REDO (повторное применение зафиксированных транзакций) восстановления после сбоя и до завершения фазы UNDO (отмена незавершённых транзакций) восстановления после сбоя. Идея в том, что UNDO может занимать намного больше времени, чем REDO, поэтому ранний доступ к базе — благо; именно поэтому это возможность редакции Enterprise (начиная с SQL Server 2005).

Суть вопроса: когда используется быстрое восстановление?

Удаляются ли смешанные страницы при перестроении индекса?

Автор: Paul Randal, Are mixed pages removed by an index rebuild?

Это вопрос, который всплыл на нашем курсе IE1, и я решил оформить ответ в виде статьи в блоге, потому что в нём есть пара тонкостей.

Первые 8 страниц, выделяемые для единицы распределения, — это смешанные страницы из смешанных экстентов, если не включён флаг трассировки 1118.

Новое в SQL Server 2022: снимки баз и интеграция с S3

Автор: Chetna Bhalla, SQL Server 2022: Transforming Storage with Snapshots and S3 Integration

В SQL Server 2022 появились снимки на уровне хранилища для почти мгновенного восстановления и встроенную поддержку совместимых с S3 хранилищ объектов для масштабируемых и экономичных резервных копий и запросов к внешним данным.

Microsoft SQL Server уже давно является одним из лидеров корпоративного управления данными, обеспечивая работу критически важных приложений в самых разных отраслях. С выпуском SQL Server 2022 компания Microsoft сделала смелый шаг к модернизации взаимодействия баз данных с подсистемами хранения. Новшества сосредоточены на мгновенном восстановлении с помощью снимков и на нативной интеграции с хранилищами объектов, совместимыми с S3, — обе возможности призваны удовлетворить растущие потребности гибридных облачных сред, аналитики по большим данным и систем высокой доступности.

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

Как вычисляются идентификаторы единиц распределения?

Автор: Paul Randal, Inside the Storage Engine: How are allocation unit IDs calculated?

Давненько я не писал о чистой «внутренней кухне», но меня время от времени спрашивают, как вычисляется идентификатор единицы распределения по полям m_objId и m_indexId, которые хранятся в заголовке каждой страницы.

Когда DBCC PAGE выводит содержимое заголовка страницы, она выполняет необходимые вычисления и обращения к метаданным, чтобы показать идентификатор единицы распределения, идентификатор секции (partition), идентификатор табличного объекта и идентификатор индекса.

Идентификатор родительской транзакции в выводе fn_dblog

Автор: Paul Randal, Parent transaction ID in 2012 fn_dblog output

В SQL Server 2012 в вывод различных динамических представлений управления (DMV), функций и команд добавили множество небольших, но полезных сведений.

Одно из новшеств, которое я обнаружил и которому очень рад (да, мне бы почаще выбираться из пещеры :-), — это появление в выводе fn_dblog идентификатора родительской транзакции. Благодаря этому можно видеть, какая транзакция является родительской для вложенных системных транзакций и других подтранзакций.

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

Новое в SQL Server 2025 - Завораживающие возможности RegEx – множественные фильтры

Автор: Louis Davidson, Awesome Use of RegEx in SQL Server – Multiple Filters

Поскольку на этой неделе проходят Microsoft Ignite и PASS Summit, я решил, что стоит написать быстрый пост о RegEx. Буду удивлён, если SQL Server 2025 не выйдет на этой неделе, а с этим релизом появится функция, которую я жду больше всего — RegEx в SQL Server.

Одно из практических применений RegEx — это более мощная фильтрация. Один из проектов, над которыми я работаю (очень медленно) — это размещение некоторых SQL-утилит на GitHub. Утилиты для просмотра метаданных таблицы, поиска столбцов, размеров баз данных и так далее. Обычно я использую LIKE для фильтрации данных, что позволяет мне просто использовать поиск по равенству, или я также могу выполнять поиск по частичному значению, когда не знаю точно, что ищу.

Новое в SQL Server 2025: Always On, AG и FCI

Автор: David Levy, Announcing General Availability of the mssql-python Driver

Дата релиза SQL Server 2025: 18 ноября 2025 г.

В этой статье собран подробный обзор нововведений Always On в SQL Server 2025: быстрый фейловер при устойчивых проблемах, ускорение синхронизации при переключениях, улучшения отказоустойчивости после кратковременной потери кворума, усиление безопасности соединений (TLS 1.3 и TDS 8.0), гибкость управления прослушивателями и маршрутизацией трафика, а также поддержка полноценных резервных копий на вторичных репликах. Материал ориентирован на проектирование, внедрение и эксплуатацию HA/DR решений. Подготовлено с помощью GPT5.

Ошибка SQL Server 1813 при присоединении базы данных: причины и способы устранения

Автор: Andrew Jackson, SQL Server Error 1813 Attach Database: Understanding Causes and Fixes

Столкнуться с ошибкой при работе с базой данных SQL Server для администратора БД — всё равно что кошмар наяву. Одна из таких ошибок — SQL Server error 1813 при присоединении базы данных: она напрямую затрагивает саму базу, не давая пользователям получить доступ к ней и к хранимым данным. В этом техническом материале мы подробно разберём эту ошибку, её причины и решения, которые помогут её устранить.

Где хранятся настройки sp_configure? Ещё одна причина делать резервные копии master…

Автор: Paul Randal, Where are sp_configure settings stored? Another reason to backup master…How are per-column modification counts tracked?

Как-то я опубликовал заметку в нашем блоге журнала "SQL Server Pro" о ложных срабатываниях проверки на повреждения, которые вы гарантированно увидите, если восстановите резервную копию базы master как пользовательскую базу и запустите DBCC CHECKDB на её копии. Это может быть частью переноса проверок целостности на другой сервер или валидации того, что ваши бэкапы корректно восстанавливаются и содержат неповреждённую базу. Впервые увидев такие ложные срабатывания, вы наверняка испугаетесь и решите, что ваш настоящий master повреждён!

Накопительный пакет обновления 22 для SQL Server 2022 - KB5068450

Описание: KB5068450

Скачать: SQLServer2022-KB5068450-x64.exe

SQL Server 2022 — Версия: 16.0.4225.2

Analysis Services — Версия: 16.0.43.252

Дата выпуска: 13 ноября 2025г.

Как отслеживаются изменения по колонкам таблиц?

Автор: Paul Randal, How are per-column modification counts tracked?

Сегодня в рассылке MVP задали вопрос о том, как SQL Server ведёт учёт изменений по каждому столбцу таблицы.

Начиная с версии 2008, скрытая системная таблица sys.sysrscols отслеживает изменения столбцов таблицы с помощью столбца rcmodified. Скрытые системные таблицы (появившиеся в 2005 году, когда мы полностью переписали систему управления метаданными) доступны только при подключении через соединение администратора (DAC), о чём я уже много раз писал. Это означает подключение с помощью SQLCMD -A или префикса admin: в строке подключения.

Эти данные также доступны во представлении каталога sys.system_internals_partition_columns, для которого DAC не требуется. (Я об этом подзабыл — спасибо моему другу Remus Rusanu за напоминание!)

Имейте в виду: всё ниже — выведенное поведение, основанное на моих знаниях и наблюдениях, и в будущих версиях оно может полностью измениться. Всё это не документировано, поэтому не стоит строить на этом программные решения. Если я этого не скажу, мой хороший друг Conor Cunningham при встрече меня отшлёпает :-)

Как работает DBCC CHECKDB WITH ESTIMATEONLY?

Автор: Paul Randal, How does DBCC CHECKDB WITH ESTIMATEONLY work?

Одним из крупнейших потребителей места в tempdb может быть DBCC CHECKDB. Эта команда генерирует всевозможные сведения о том, что она видит в базе данных (они называются фактами), и складывает их в большую рабочую таблицу. Фактами могут быть, к примеру, сообщения вроде «мы прочитали страницу F» или «запись X на странице Y указывает на выведённый за пределы строки столбец LOB в записи A на странице B», или даже целая битовая карта IAM‑страницы. Обычно объём памяти, требуемый для рабочей таблицы, превышает доступный объём, поэтому рабочая таблица проливается в tempdb.

DBCC CHECKDB вынуждена использовать такой механизм генерации фактов, потому что она читает страницы файлов данных не в логическом порядке и не в глубину, а в порядке распределения (allocation order), что быстрее всего. Более того, создаются несколько потоков, и каждый из них читает свой набор страниц, отчего во время работы I/O‑подсистема загружается по максимуму — специальный readahead выполняет упреждающее чтение, выжимая из диска всё, что можно. По мере того как каждый поток генерирует факты, он передаёт их процессору запросов, который сортирует их по ключу, заданному DBCC CHECKDB (идентификаторы страницы, объекта, индекса и т. п.), и вставляет в рабочую таблицу.

Начальные номера последовательностей VLF и размер файла журнала по умолчанию

Автор: Paul Randal, Initial VLF sequence numbers and default log file size

Мы проводим двухнедельное корпоративное обучение у финансового клиента в Нью‑Йорке, и на сегодняшней сессии по архитектуре журнала транзакций меня спросили, почему номера последовательностей VLF (virtual log file) в новой базе не начинаются с единицы.

Правда ли, что изменения ключей индекса выполняются «по месту»?

Автор: Paul Randal, Do changes to index keys really do in-place updates?

Сегодня утром в Twitter развернулась интересная дискуссия (её начал мой хороший друг Erin Stellato) о «встроенных» обновлениях (in‑place updates) записей индекса, когда значение ключа меняется, но запись остаётся на той же странице. Разные источники, включая книгу SQL Server 2008 Internals (стр. 361 — этот фрагмент я не писал и не рецензировал :-) ), описывают процесс — увы, неверно. Там говорится, что запись останется ровно в той же позиции на странице и изменятся лишь байты, хранящие ключ.

Это не так. Настоящие in‑place‑обновления значений ключей индекса не выполняются, начиная с версии 2005. Давайте нырнём в кроличью нору…

Фрагментация кучи лечится созданием и удалением кластерного индекса - миф!

Автор: Paul Randal, A SQL Server DBA myth a day: (29/30) fixing heap fragmentation

Миф №29: исправить фрагментацию кучи можно, создав и затем удалив кластерный индекс.

Неееееет!!!

Это одно из худших действий, которые только можно совершить, если не считать сжатия базы данных.

Три мифа о коэффициенте заполнения (fill factor)

Автор: Paul Randal, A SQL Server DBA myth a day: (25/30) fill factor

Это короткая статья о мифах вокруг коэффициента заполнения (fill factor) — тему, которую я настойчиво прояснял ещё в Books Online для SQL Server 2005.

Миф №25: разные заблуждения о коэффициенте заполнения.

Все ложные

Исправление безопасности для SQL Server 2022 CU21 - KB5068406

Описание: KB5068406

Скачать: SQLServer2022-KB5068406-x64.exe

SQL Server 2022 — версия: 16.0.4212.1

Дата выпуска: 11.11.2025

Исправление безопасности для SQL Server 2022 GDR - KB5068407

Описание: KB5068407

Скачать: SQLServer2022-KB5068407-x64.exe

SQL Server 2022 — версия: 16.0.1160.1

Дата выпуска: 11.11.2025

Исправление безопасности для SQL Server 2019 GDR - KB5068405

Описание: KB5068405

Скачать: SQLServer2019-KB5068405-x64.exe

SQL Server 2019 — версия: 15.0.2155.2

Дата выпуска: 11.11.2025

Исправление безопасности для SQL Server 2019 CU32 - KB5068404

Описание: KB5068404

Скачать: SQLServer2019-KB5068404-x64.exe

SQL Server 2019 — версия: 15.0.4455.2

Дата выпуска: 11.11.2025