Новое в SQL Server 2025: функции кодирования и декодирования Base64

Автор: Leonard Lobel, Base64 Encoding and Decoding in SQL Server 2025 and Azure SQL Database

SQL Server 2025 добавляет встроенную поддержку кодирования и декодирования Base64 с помощью двух T-SQL-функций: BASE64_ENCODE и BASE64_DECODE. Эти функции значительно упрощают преобразование двоичных данных в дружественные к тексту представления и обратное преобразование строк в двоичные данные, когда это необходимо.

Это полезно во многих повседневных сценариях: встраивание двоичного содержимого в JSON, создание URL данных для HTML, передача двоичных полезных нагрузок через текстовые протоколы и создание безопасных для URL токенов. Раньше разработчикам часто приходилось полагаться на XML-трюки, код на стороне приложения, CLR-функции или собственную логику преобразования. Теперь эта функциональность доступна непосредственно в T-SQL.

Важно: Base64 — это формат кодирования, а не механизм шифрования. Он делает двоичные данные дружественными к тексту, но не обеспечивает безопасность или скрытие основных данных.

Как влияет сжатие резервных копий на загрузку процессоров

Автор: Paul Randal, SQL Server 2008: Backup Compression CPU Cost

Я давно обещал написать о встроенном сжатии резервных копий (Backup Compression). Для этой статьи я расширил базу данных AdventureWorks до 322 МБ (случайный размер, но достаточно большой, чтобы получить приемлемое время выполнения на моём сервере). Я использовал системный монитор (System Monitor) для измерения времени ЦП в пользовательском режиме (%user-mode CPU time), а также пропускной способности резервного копирования и восстановления для сжатой и несжатой операций резервного копирования, а затем и восстановления.

Cколько времени займёт выполнение CHECKDB?

Автор: Paul Randal, CHECKDB From Every Angle: How long will CHECKDB take to run?

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

Отслеживание DOP Feedback с помощью Extended Events

Автор: Vivek Janakiraman, SQL Server 2025 Series : Degree Of Parallelism (DOP) Feedback Explained with Real-Time Demo!

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

С выходом SQL Server 2025 эта задача значительно упрощается благодаря обратной связи по степени параллелизма (Degree of Parallelism Feedback, DOP Feedback) — мощной функции интеллектуальной обработки запросов, которая автоматически оптимизирует выполнение параллельных запросов.

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

• Что такое DOP Feedback
• Как отслеживать её с помощью расширенных событий (Extended Events)
• Демонстрацию в реальном времени с несколькими сценариями
• Как проверить, работает ли DOP Feedback на вашем сервере

Когда процессоры голодают

Автор: Luca Biondi, SQL SERVER. A deep analysis on CPU Starvation

Почему сервер при загрузке ЦП 40% может вести себя как при полностью утилизированных процессорах

Глубокое погружение в справедливость планировщика SOS, сборку мусора Hekaton, сканирование хэш-индексов и почему накопительное обновление CU5 для SQL Server имеет гораздо большее значение, чем думает большинство администраторов баз данных.

В двух словах

• SQL Server использует кооперативное планирование через планировщик SOS (SOS Scheduler), и рабочие процессы должны добровольно уступать ЦП (yield).
• Накопительное обновление SQL Server CU5 улучшает справедливость планировщика (scheduler fairness) во время сканирования сборки мусора хэш-индексов в In-Memory OLTP. 
• Голодание ЦП (CPU starvation) может происходить даже тогда, когда общее использование ЦП выглядит умеренным. 
• Неправильный размер корзин (bucket sizing) хэш-индексов и длинные цепочки версий могут резко увеличить затраты на обход сборщика мусора. 
• Постоянный рост runnable_tasks_count часто опаснее, чем процент загрузки ЦП. 

Структуры хранения #4 – Memory-optimized columnstore

Автор: Hugo Kornelis, Storage structures 4 – Memory-optimized columnstore;

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

Оптимизированные для памяти колоночные индексы были представлены в SQL Server 2016. За это время я видел несколько эффектных маркетинговых презентаций Microsoft, в которых много говорилось о «аналитике в реальном времени» (real-time operational analytics). Новая тенденция, согласно которой аналитическая обработка больше не должна выполняться на устаревшей копии данных в отдельном хранилище, а непосредственно в OLTP-базе данных. Отчёты всегда были бы полностью актуальными, необходимость в ETL-конвейере отпала бы, а благодаря сочетанию оптимизированных для памяти структур для OLTP-нагрузок и колоночных индексов для аналитической обработки всё всегда было бы быстро. В теории.

Я больше не слышал термин «аналитика в реальном времени» после первоначального выпуска SQL Server 2016. А начиная с внедрения SQL Server 2017, я не припомню, чтобы слышал от кого-либо из сотрудников Microsoft использование терминов «оптимизированный для памяти» и «колоночный» в одном докладе, не говоря уже об одном предложении.

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

Что такое XXE-атака и почему администраторам SQL Server следует об этом беспокоиться?

Автор: Luca Biondi, What Is an XXE Attack and Why Should SQL Server DBAs Care?

XML-уязвимости больше не являются проблемой только веб-разработчиков. XXE-атаки могут напрямую влиять на среду SQL Server, пакеты SSIS, отчёты SSRS и рабочие процессы обработки XML. В этой статье я покажу вам, что именно представляет собой XXE-атака (XML External Entity), почему она всё ещё актуальна сегодня и как она может напрямую повлиять на SQL Server через SSIS, обработку XML и SSRS.

Если ваша инфраструктура SQL Server обрабатывает XML где-либо в конвейере, это не теоретический шум о безопасности. Это реальная поверхность атаки.

В двух словах

• XXE — это уязвимость в парсерах XML, обрабатывающих недоверенные внешние сущности.
• SQL Server может быть косвенно подвержен атаке через SSIS, SSRS, тип данных XML и внешние XML-рабочие процессы.
• Злоумышленники могут читать конфиденциальные файлы, инициировать SSRF-атаки или истощать ЦП/ОЗУ с помощью DoS-атаки «Миллиард смайликов».
• Основная защита — отключение DTD и разрешения внешних сущностей в парсерах XML.

Представляем расширение StatisticsParser для SSMS

Автор: Brent Ozar, Announcing the SSMS StatisticsParser Extension

Если вы много занимаетесь настройкой запросов, то, вероятно, сталкивались с StatisticsParser.com от Ричи Рамп (Richie Rump). Теперь пользоваться им стало ещё проще.

Скачайте и установите расширение, затем выполните ваш запрос с включёнными SET STATISTICS IO, TIME ON, и после завершения щёлкните правой кнопкой мыши в окне запроса и выберите Parse Statistics.

Обходим шторм компиляций стороной

Автор: Luca Biondi, Check SQL Server Plan Cache Pollution (III) in 45 Seconds

Вы когда-нибудь задумывались, почему ваш ЦП достигает 100% при низком объёме запросов? В этой статье я разберу механизм «Штормов компиляции» (Compilation Storms) и покажу, как обнаружить узкие места типа SOS_CACHESTORE менее чем за минуту.

В двух словах

• Стоимость компиляции (Compilation Cost): Такты ЦП тратятся впустую, когда SQL Server выполняет «Полную оптимизацию» (Full Optimization) многократно.
• Тривиальные планы (Trivial Plans): Быстрый путь к выполнению, который пропускает оптимизацию на основе стоимости для простых запросов.
• Триггеры перекомпиляции (Recompilation Triggers): Плохая статистика и изменения схемы (DDL) являются основными подозреваемыми в нестабильности кэша.
• Предупреждение о спинблокировке (Spinlock Warning): Высокое время ожидания SOS_CACHESTORE означает интенсивную конкуренцию за кэш планов.

Управление высококонкурентной средой SQL Server — это игра на миллиметры. Мы часто говорим о «быстрых запросах», но редко говорим о налоге, который движок платит до того, как запрос вообще начнётся: о компиляции. Когда ваш кэш планов нестабилен, SQL Server входит в «Шторм компиляции», превращая ваши высококлассные ЦП в дорогие обогреватели. Давайте заглянем под капот.

Поддержка регулярных выражений для LOB-типов в T-SQL — доступно в SQL Server 2025 CU5

Автор: abhimantiwari, Regex support for LOB types in T-SQL—available in Azure SQL & SQL Server 2025

Краткий обзор. Собственные функции регулярных выражений (regex) в T-SQL теперь принимают входные данные типа varchar(max) и nvarchar(max) размером до 2 МБ во всех семи функциях регулярных выражений, включая две табличные функции (REGEXP_MATCHES и REGEXP_SPLIT_TO_TABLE). Эта возможность поставляется в SQL Server 2025 CU5. Вам больше не нужно разбивать файлы журналов, HTML-документы или большие JSON-нагрузки на 8000-байтовые фрагменты только для того, чтобы выполнить сопоставление с шаблоном.

Выметаем ядовитые планы из кэша SQL Server

Автор: Luca Biondi, Check SQL Server Plan Cache Pollution (II) in 45 Seconds

Вы исправили ad-hoc запросы, но ваш сервер всё ещё «колбасит»? В этой статье я расскажу, почему даже идеальная параметризация может привести к «токсичности повторного использования» (reuse toxicity) и массовым скачкам ЦП.

В двух словах

• Параметризованное засорение (Parameterized Pollution): Засорение кэша — это не только «слишком много планов», но и повторно используемый «неправильный план». 
• Токсичность повторного использования (Reuse Toxicity): План, оптимизированный для одной строки, принудительно применяется к набору из миллиона строк, убивая производительность.
• Нестабильность планов (Plan Instability): Резкие колебания между min_worker_time и max_worker_time указывают на войну, вызванную Sniffing'ом параметров.
• Решение: Используйте Query Store, идентификацию по query_hash и оптимизацию PSP в SQL Server 2022.

В предыдущей части этой серии мы очистили кэш от «мусорных» планов. Но горькая правда в том, что чистый код не гарантирует чистый кэш. Даже когда ваше приложение на 100% параметризовано, SQL Server всё ещё может страдать от другого вида засорения — логической токсичности. Это происходит, когда движок повторно использует неоптимальный план выполнения, потому что во время компиляции он «унюхал» (sniffed) непредставительный параметр.

Проверка кэша SQL Server на засорение одноразовыми планами

Автор: Luca Biondi, Check SQL Server Plan Cache Pollution (I) in 45 Seconds

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

В двух словах

• Загрязнение кэша планов (Plan Cache Pollution) происходит, когда непараметризованные запросы создают тысячи бесполезных одноразовых планов выполнения. 
• Вымывание памяти (Memory Starvation): Эти планы крадут пространство у буферного пула, вытесняя данные из памяти и увеличивая ввод-вывод. 
• Исправление: Используйте параметризацию, sp_executesql или включите настройку «Optimize for Ad Hoc Workloads». 
• SQL-запрос «Wow!»: Определите, какие именно ad-hoc запросы прямо сейчас засоряют ваш кэш. 

За 25 лет настройки производительности я видел, как миллионы долларов, вложенных в оборудование, оказывались бесполезными из-за плохих привычек кодирования. Один из самых распространённых молчаливых убийц — засорение кэша планов. Это технический эквивалент заполнения библиотеки идентичными книгами, в которых меняется только одна страница. Каждый раз, когда ваше приложение отправляет запрос вроде WHERE Id = 1, а затем WHERE Id = 2 без параметризации, SQL Server обрабатывает их как совершенно новую логику.