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

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

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

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

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

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

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

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

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

Автор: Aaron Bertrand , Managing Underused Indexes in SQL Server Availability Groups – Part 1
В рамках оптимизации производительности я оцениваю использование индексов на множестве экземпляров и в разных базах данных. Часто обнаруживается, что некоторые индексы используются нечасто или, по крайней мере на первый взгляд, кажутся неиспользуемыми. Поскольку мы используем группы доступности (AG), разные рабочие нагрузки выполняются на репликах в разных ролях. Все операции записи, разумеется, происходят на первичной. Однако некоторые запросы выполняются только на вторичных репликах для чтения (либо за счёт маршрутизации чтения, либо потому, что отдельные процессы вручную направляются на конкретные вторичные, либо же и то и другое). К сожалению, статистика использования индексов нигде не агрегируется по всем репликам сразу. Это значит, что анализ только первичной реплики даёт неполную картину. Как убедиться, что я учитываю активность индексов везде, а не только на первичной?

Включаем умный параллелелизм вставки с помощью OPTIMIZE_FOR_SEQUENTIAL_KEY

Автор: Chandan Shukla, Unlocking High-Concurrency Inserts in SQL Server with OPTIMIZE_FOR_SEQUENTIAL_KEY

Системы с высокой параллельностью на бумаге всегда выглядят впечатляюще. Вы добавляете десятки процессорных ядер, увеличиваете объём памяти, проектируете схему с «лёгкими» вставками и с удовлетворением думаете: «Всё полетит». И, по правде говоря, при небольшой нагрузке так и выходит. Одна сессия, вставляющая строки в простую таблицу, даже не заставляет SQL Server напрячься.

Но картина меняется, как только вы начинаете нагружать систему сотнями параллельных вставок. Внезапно вся вычислительная мощь перестаёт иметь значение, потому что каждый поток бьётся за одно крошечное место в памяти: последнюю страницу кластерного индекса. Это классическая проблема «last-page insert contention problem». Она возникает всякий раз, когда ключ кластерного индекса последовательный — типичные IDENTITY, DATETIME или NEWSEQUENTIALID(). Каждая новая строка естественным образом «тянется» в конец B-дерева. Это звучит упорядоченно и эффективно, но при конкуренции — это ловушка. Вместо распределения вставок по нескольким страницам все они наваливаются на одну «горячую» страницу.

Доступ к 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 — Подсчитывает количество совпадений шаблона регулярного выражения в строке.

Всё, что нужно знать про управление ключами 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 не потребуется.

Новое в 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. Но вместо замены на основе статического разделителя, она может заменять несколько (или конкретное) значение, совпадающее с регулярным выражением. Все мои примеры в этой статье будут использовать просто переменную со значением, над которым мы работаем, так что создавать или загружать объекты не нужно.

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

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

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

Эта функция очень похожа на STRING_SPLIT. И, в отличие от таких функций, как REGEXP_LIKE, в простых случаях здесь можно использовать те же основные параметры, что и у STRING_SPLIT. Но далее возможности становятся практически безграничными, потому что можно определить почти любые разделители. Конечно, у функции есть и недостатки, но об этом поговорим позже.

Новое в SQL Server 2025: Поиск совпадений с помощью функций регулярных выражений

Автор: Louis Davidson, Viewing Multiple Matches in SQL Server Regular Expression Functions

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

Существует несколько функций, которые позволяют в выводе результата показать несколько совпадений фрагмента строки или шаблона:

• REGEXP_REPLACE – возвращает измененную исходную строку, замененную строкой замены, в которой найдено вхождение шаблона регулярного выражения. Если совпадения не найдены, функция возвращает исходную строку.
• REGEXP_SUBSTR – возвращает одно вхождение подстроки в анализируемой строке, которое соответствует шаблону регулярного выражения. Если совпадение не найдено, возвращается NULL.
• REGEXP_INSTR – возвращает начальную или конечную позицию соответствующей подстроки в зависимости от значения аргумента return_option.
• REGEXP_COUNT – подсчитывает количество совпадений шаблона регулярного выражения в строке.
• REGEXP_SPLIT_TO_TABLE – используется аналогично функции SPLIT_TO_TABLE, но возвращает таблицу строк, разделенную шаблоном регулярных выражений. Если шаблон не соответствует, функция возвращает строку.
• REGEXP_MATCHES – возвращает таблицу захваченных подстрок, которые соответствуют шаблону регулярного выражения строке. Если совпадение не найдено, функция не возвращает строку.

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

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

Функция REGEXP_SUBSTR извлекает части строки на основе шаблона регулярного выражения. Она имеет сходство с функцией SUBSTRING, но есть и важные (и интересные) различия. Эта функция возвращает N-ое вхождение подстроки, которая соответствует регулярному выражению.

Когда я начал писать десятую статью в серии о регулярных выражениях в SQL Server, я должен признаться: я не знал заранее, что именно эта функция делает. Классическая функция SUBSTRING принимает строго позиционные параметры. Задана строка, указываешь начальную позицию и количество символов — и получаешь результат. Никакого сопоставления с шаблоном. К счастью для вас, изучение этого материала у меня заняло совсем немного времени.

В одной из предыдущих статей, где речь шла о REGEXP_MATCHES, я показывал, как можно увидеть все совпадения, которые регулярное выражение находит в строке. REGEXP_SUBSTR в своей простой форме возвращает скалярный результат — то есть одно совпадение.

Страсти по SQL Server 2025: ускоренное восстановление базы данных не исправляет проблему NOLOCK!!!

Автор: Brent Ozar, No, Accelerated Database Recovery Doesn’t Fix NOLOCK

Я никогда не видел в T-SQL такой фразы, которую так же любят использовать, как NOLOCK. Мне постоянно кажется, что я написал уже достаточно публикаций об этом, но вот недавно клиент высказал новую идею:

Мы используем Accelerated Database Recovery в SQL Server 2022, который хранит версии строк внутри таблицы. К тому же мы не используем транзакции — наши операции вставки, обновления и удаления выполняются над одной таблицей за раз, а ваши демонстрации всегда используют транзакции, поэтому нас это не затрагивает.

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

Автор: Koen Verbeeck, SQL Server 2025 REGEXP_COUNT Function to Count Occurrences in Text

Бывает необходимо подсчитать, сколько раз определенная строка встречается в тексте. Однако формат этой строки может меняться. Например, существует несколько способов записи одного и того же номера телефона, и все они являются допустимыми форматами. Возможно ли это сделать в T-SQL? Давайте рассмотрим, как может помочь функция REGEXP_COUNT.

2025 год: инструменты для администрирования MSSQL

Автор: SQLYARD, Tools & Connectivity with SQL Server in 2025: The Smart DBA’s Guide

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

Новое в SQL Server 2025: функция PRODUCT()

Автор: Edward Pollack, How to Use the New PRODUCT() Function in SQL Server 2025

С каждой версией SQL Server появляются новые возможности, за которые мы благодарны — наконец-то появляется доступ к полезным функциям, которые уже были в других системах.

В SQL Server 2025 CTP 1.3 была представлена функция PRODUCT(). Она ведёт себя похоже на SUM(), но умножает значения вместо того, чтобы их складывать. Это агрегатная функция в SQL Server, следовательно, она действует на набор данных, а не на скалярные значения.

Новое в SQL Server 2025: Кардинальность и REGEXP_LIKE

Автор: Louis Davidson, Cardinality and REGEXP_LIKE

Я читал пост Брента Озара о регулярных выражениях в SQL Server 2025 (T-SQL Has Regex in SQL Server 2025. Don’t Get Too Excited) и о том, почему они работают так, как работают. В комментариях кто-то упомянул несколько подсказок (hints), которые якобы должны улучшить ситуацию. О них написано немного, поэтому я решил сам проверить, как они себя ведут. Речь идёт о: ASSUME_FIXED_MAX_SELECTIVITY_FOR_REGEXP и ASSUME_FIXED_MIN_SELECTIVITY_FOR_REGEXP. Они работают, корректируя ожидаемое количество строк, возвращаемых условием с оператором REGEXP.

T-SQL получил Regex в SQL Server 2025. Но не спешите радоваться

Автор: Brent Ozar. T-SQL Has Regex in SQL Server 2025. Don’t Get Too Excited

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

Этот пост не про сложность, а про производительность regex в Azure SQL DB и SQL Server 2025.

Regex как Everclear

Everclear — это марка алкоголя. Звучит заманчиво: без запаха, вкуса и цвета. Но на самом деле это 95% чистого спирта, настолько крепкий, что во многих штатах США его просто запретили. Даже в Неваде, где разрешены казино, оружие и марихуана.

Функция REGEXP_LIKE в SQL Server 2025

Автор: Koen Verbeeck. REGEXP_LIKE Function in SQL Server 2025

Мне нужно выполнить проверку данных в базе SQL Server. Однако правила слишком сложные для функции T-SQL LIKE, и не удаётся реализовать их через PATINDEX или что-то подобное. Я хотел бы использовать регулярные выражения, так как они мощнее. В SQL Server 2025 для этого теперь есть функция REGEXP_LIKE.

Подробнее о неявных преобразованиях

Автор: Craig Freedman More on Implicit Conversions

Меня попросили прокомментировать алгоритм, который SQL Server использует для выбора неявных преобразований. Когда SQL Server сталкивается в выражении с несовпадающими типами, он может выполнить запрос с неявным преобразованием или может завершить запрос ошибкой. Прежде чем углубляться в сценарий неявного преобразования, давайте кратко рассмотрим случай с ошибкой. Если неявное преобразование невозможно, возможны два варианта ошибки. Если оба типа данных несовместимы (то есть, если между двумя типами не допускается преобразование, неявное или явное), SQL Server сгенерирует следующую ошибку:

DECLARE @a INT
DECLARE @b DATE
SET @a = @b

Msg 206, Level 16, State 2, Line 3
Operand type clash: date is incompatible with int