Страницы IAM, цепочки IAM и единицы распределения

Автор: Paul Randal, Inside the Storage Engine: IAM pages, IAM chains, and allocation units

Это компиляция из ранее опубликованного материала с добавлением новых фрагментов вывода DBCC PAGE.

Анатомия экстента

Автор: Paul Randal, Inside the Storage Engine: Anatomy of an extent

В предыдущей публикации я рассказал о страницах базы данных — их структуре и некоторых разновидностях страниц. Теперь я хотел бы объяснить, как страницы объединяются в т.н. экстенты. Экстент представляет собой группу из восьми физически последовательных страниц в файле данных. Экстенты всегда выравниваются по границам 64 КБ (то есть по границам 8 страниц), начиная с начала файла. Экстенты и все их свойства остаются неизменными во всех версиях, но способы их использования различаются. Существует два типа экстентов: смешанные экстенты и однородные (uniform) экстенты.

Использование DBCC PAGE и DBCC IND для доказательства, что расщепление не откатывается

Автор: Paul Randal, Inside the Storage Engine: Using DBCC PAGE and DBCC IND to find out if page splits ever roll back

Прежде чем переходить к механизму работы, хочу разобрать две команды, которые я буду часто использовать — DBCC PAGE и DBCC IND. Обе они (на момент написания статьи) являются недокументированными и не поддерживаются официально, но абсолютно безопасны в применении, так как активно используются внутри и вне Microsoft при диагностике. Тем не менее, используйте их на свой страх и риск. Эти команды хорошо известны в сообществе MSSQL, я и другие специалисты уже рассказывали о них ранее.

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

Анатомия страницы с помощью DBCC PAGE

Автор: Paul Randal, Inside the Storage Engine: Anatomy of a page

Очередная статья из серии «Inside the Storage Engine» посвящена устройству страниц баз данных. Страницы нужны для хранения записей — это блок размером 8192 байта (8 КБ) в файле данных базы. Они выровнены по границам 8 КБ внутри файлов данных, начиная со смещения 0 байт в файле. Ниже — упрощённая иллюстрация базовой структуры:

Доступ к Kubernetes API из SQL Server 2025

Автор: dbafromthecold.com, Accessing the Kubernetes API from SQL Server 2025

Хранимая процедура sp_invoke_external_rest_endpoint, появившаяся в версии SQL Server 2025, позволяет обращаться к внешним конечным точкам REST API прямо из SQL Server. Это открывает множество интересных возможностей. Недавно я задумался: ведь Kubernetes тоже предоставляет REST API. Можно ли обратиться к нему напрямую из SQL Server?

Давайте посмотрим, как это сделать. Пошагово план такой:

1. Создать локальный центр сертификации (CA), приватный RSA-ключ и подписанный сертификат
2. Развернуть обратный прокси в Kubernetes
3. Настроить SQL Server для обращения к прокси
4. Использовать хранимую процедуру для вызова Kubernetes API через прокси

Новое в SQL Server 2025: REGEXP_INSTR и REGEXP_COUNT

Автор: Louis Davidson, And the rest – REGEXP_INSTR, and REGEXP_COUNT

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

В этой статье мы рассмотрим:

• REGEXP_INSTR — Возвращает начальную или конечную позицию соответствующей подстроки в зависимости от значения аргумента return_option.
• REGEXP_COUNT — Подсчитывает количество совпадений шаблона регулярного выражения в строке.

Новое в SQL Server 2025: sys.dm_os_memory_health_history

Автор: SQLYARD, Meet sys.dm_os_memory_health_history in SQL Server 2025

В SQL Server 2025 компания Microsoft представила новое динамическое административное представление (DMV) sys.dm_os_memory_health_history. Ключевые моменты:

• Оно фиксирует снимки состояния использования и «здоровья» памяти во времени.
• Каждая строка — это один снимок.
• Снимки содержат различные метрики: сколько памяти доступно для новых распределений, сколько используется освобождаемыми кешами, какие диспетчеры памяти потребляют больше всего, а также «уровень серьёзности», показывающий, насколько здоровым (или перегруженным) является состояние памяти.
• Это функция в режиме предварительного просмотра — схема или поведение могут измениться в будущих обновлениях SQL Server 2025. 

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

Автор: PieterVanhove, Everything you need to know about TDE key management for database restore

Прозрачное шифрование данных (TDE) в Azure SQL с ключом, управляемым клиентом (Customer-Managed Key, CMK), поддерживает сценарий «принеси свой ключ» (Bring Your Own Key — BYOK) для защиты данных в состоянии покоя и даёт возможность разделения обязанностей по управлению ключами и данными. При клиентском управлении TDE пользователь отвечает за жизненный цикл ключей (создание, загрузка, ротация, удаление), права на их использование и аудит операций с ключами. Ключ, используемый для шифрования ключа шифрования базы данных (Database Encryption Key, DEK), называемый TDE-протектором, — это асимметричный ключ, которым управляет клиент и который хранится в Azure Key Vault.

После включения TDE с использованием ключа из Key Vault новые резервные копии продолжают шифроваться с использованием того же TDE-протектора. Смена TDE-протектора не изменяет уже созданные резервные копии — чтобы восстановить резервную копию, зашифрованную ключом Key Vault, необходимо, чтобы материал соответствующего ключа был доступен серверу, на который выполняется восстановление. Особенность реализации TDE требует, чтобы для успешного восстановления были доступны как текущий, так и предыдущие TDE-протекторы. Рекомендуется сохранять все предыдущие версии протектора в хранилище ключей, чтобы иметь возможность восстановить резервные копии базы данных.

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

Новое в SQL Server 2025: REST API и переосмысливание резервного копирования снимков

Автор: Anthony Nocentino, T-SQL REST API Integration in SQL Server 2025: Streamlining T-SQL Snapshot Backups

В этой статье я покажу, как с помощью T-SQL-скрипта создавать согласованные с приложениями моментальные снимки на Pure Storage FlashArray прямо из SQL Server, без использования внешних инструментов. В SQL Server 2025 появилась мощная новая возможность: хранимая процедура sp_invoke_external_rest_endpoint. Она значительно облегчает вызов REST API напрямую из T-SQL. В сочетании с API Pure Storage эта функция позволяет полностью автоматизировать процесс создания снимков без внешних скриптов и инструментов.

Если вы следили за моей серией публикаций Using T-SQL Snapshot Backup, вы знаете, что данная технология особенно полезна в крупных базах данных. Сегодня мы рассмотрим, как реализовать её непосредственно в T-SQL, используя возможность SQL Server обращаться к REST API. PowerShell не потребуется.

Репликация между различными СУБД — что использовать, когда и как обходить ограничения

Автор: SQLYARD, Replication Across Engines — What to Use, When, and How to Mitigate Their Limitations

Репликация данных лежит в основе многих современных систем: обеспечение непрерывной работы (высокая доступность), катастрофоустойчивость (восстановление после сбоев), наполнение аналитических конвейеров или хранилищ, выполнение миграций или поддержка глобальных приложений и мульти-региональных требований к данным. Но не все инструменты и стратегии репликации одинаковы. Зачастую, вы сталкиваетесь с компромиссами, которые могут определять:

• Как фиксируются изменения (на основе журнала/логов, триггеры, загрузки изменений, пакетные загрузки);
• Насколько «в реальном времени» должна быть синхронизация (подойдут ли минуты, или нужен почти мгновенный обмен);
• Используют ли источник и приёмник одну и ту же СУБД или разные («гомогенная» vs «гетерогенная» репликация);
• Как вы справляетесь с различиями в схемах, эволюцией схем, идентификаторами/последовательностями, вычисляемыми полями и т. п.;
• Какие конфликты могут возникнуть при наличии более чем одного пишущего узла и как их разрешать;
• Операционная сложность, мониторинг, стоимость, лицензирование и т. д.

Каждая крупная реляционная СУБД (SQL Server, PostgreSQL, Oracle, MySQL…) использует свои внутренние механизмы (redo-журналы, журналы транзакций, binlog, WAL и т. п.), имеет нюансы типов данных и собственные ограничения. Репликация между разными СУБД часто усиливает эти несоответствия (например, SQL Server NVARCHAR(MAX) vs PostgreSQL TEXT; Oracle NUMBER vs SQL Server DECIMAL; MySQL JSON vs SQL Server JSON).

Ниже — сравнение ведущих инструментов (включая варианты, которые часто упускают), где они подходят, чего следует избегать и как смягчать типичные проблемы. Поскольку эта статья об SQL Server, для каждого инструмента приведена пометка о совместимости с SQL Server.

Оптимизация чувствительных к параметрам планов исполнения в SQL Server 2022

Автор: Deepam Ghosh, Parameter Sensitive Plan Optimization in SQL Server 2022

SQL Server 2022 включает множество усовершенствований и новых возможностей по сравнению с предыдущими версиями. Среди них новые роли сервера, улучшенный Query Store, повышение производительности TempDB, интеллектуальная обработка запросов, автономные группы доступности, Database Ledger и многое другое.

В сегодняшней статье мы рассмотрим практическую демонстрацию одной из таких возможностей — оптимизации планов, чувствительных к параметрам (Parameter Sensitive Plan Optimization, PSPO). Мы увидим, какие трудности создают параметризованные хранимые процедуры в старых версиях и как оптимизация PSPO решает эти проблемы и улучшает планы выполнения запросов в новой версии.

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

Новое в SQL Server 2025: Функция REGEXP_REPLACE

Автор: Louis Davidson, REGEXP_ Functions in SQL Server 2025 – REGEXP_REPLACE

Мы уже рассмотрели столько способов фильтрации с помощью регулярных выражений, сколько, на мой взгляд, реализовано в SQL Server 2025. Теперь пришло время сосредоточиться на функциях, которые не являются REGEXP_LIKE. Мы уже говорили о REGEXP_MATCHES, которая пригодится в дальнейшем.

Я начну с REGEXP_REPLACE, которая похожа на обычную функцию SQL REPLACE. Но вместо замены на основе статического разделителя, она может заменять несколько (или конкретное) значение, совпадающее с регулярным выражением. Все мои примеры в этой статье будут использовать просто переменную со значением, над которым мы работаем, так что создавать или загружать объекты не нужно.