Показаны сообщения с ярлыком SQL Server 2025. Показать все сообщения
Показаны сообщения с ярлыком SQL Server 2025. Показать все сообщения

2.6.26

Структуры хранения #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 использование терминов «оптимизированный для памяти» и «колоночный» в одном докладе, не говоря уже об одном предложении.

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

1.6.26

Что такое 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.

27.5.26

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


Автор: abhimantiwari, Regex support for LOB types in T-SQL—available in Azure SQL & SQL Server 2025
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-байтовые фрагменты только для того, чтобы выполнить сопоставление с шаблоном.

21.5.26

Когда TempDB растёт «вширь»: как RCSI и длинные транзакции незаметно разрушают SQL Server


Автор: Steve Stedman, When TempDB Grows “Up and to the Right”: How RCSI and Open Transactions Quietly Break SQL Server

Одна из самых опасных проблем SQL Server — та, которую вы не замечаете, пока диск не заполнится, а производственная система не упадёт. TempDB особенно хороша в таком типе отказа — она незаметно растёт в фоновом режиме, пока внезапно не становится проблемой для всех.

Недавно мы просматривали отчёт о распределении пространства TempDB (TempDB Allocation History Report), и он прекрасно проиллюстрировал проблему, с которой мы сталкиваемся всё чаще по мере того, как растёт применение READ COMMITTED Snapshot Isolation (RCSI). RCSI обычно является правильным выбором, но когда что-то идёт не так, TempDB может расти взрывным образом, и большинство команд не понимают почему, пока не становится слишком поздно.

Накопительный пакет обновления SQL Server 2025 CU5 - KB5084896

Описание: KB5084896

Скачать: SQLServer2025-KB5084896-x64.exe

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

SQL Server 2025 — Версия: 17.0.4045.5

20.5.26

«Нет, мы не обновляемся. Что мы упускаем?»

Автор: Thomas Rushton, “No, we’re not upgrading. What are we missing out on?”

SQL Server 2016 — покойся с миром, RIP, скатертью дорога (хотя последнее звучит как-то слишком сурово). SQL Server 2016 выходит из расширенной поддержки (extended support) 14 июля — в День взятия Бастилии, без комментариев — 2026 года. Это следует из политики фиксированного жизненного цикла Microsoft (Fixed Lifecycle Policy): выпуск, примерно пять лет основной поддержки (mainstream support), в течение которой вы получаете исправления, обновления безопасности, улучшения производительности и функциональности, и ещё примерно пять лет расширенной поддержки (extended support), в течение которой вы получаете обновления безопасности и не многое другое. После этой даты Microsoft крайне редко выпускает какие-либо обновления за пределами платной программы расширенных обновлений безопасности (Extended Security Update, ESU), поэтому продолжение использования продукта, срок поддержки которого истёк (EOL product), следует рассматривать как экстренную меру только для краткосрочного использования.

13.5.26

Бывают дни, когда я хочу бросить всё это с кэшем планов и Хранилищем запросов!

Автор: Brent Ozar, There Are Days When I Feel Like Giving Up on the Plan Cache and Query Store

В теории мониторинг производительности SQL Server довольно прост:

  1. Изучите главные типы ожиданий (wait types) на сервере.
  2. Найдите запросы, вызывающие эти типы ожиданий.
  3. Исправьте эти запросы или улучшите реакцию сервера на них (индексы, настройки и т.д.).

Но на практике шаг 2 ужасен, потому что:

  • Приложения отправляют на сервер баз данных непараметризованные строки.
  • Пользователи Entity Framework строят запросы с FromSqlRaw или string.Format().
  • Пользователи Entity Framework пишут запросы с .Contains, который создаёт непараметризованный список IN, даже когда ищут всего одно значение (в EF9 стало лучше).
  • Люди пишут неаккуратный динамический SQL, который просто вставляет значения прямо в строку запроса.
  • Разработчики SaaS-решений помещают каждого клиента в собственную базу данных, и планы не переиспользуются между базами данных.

Исправление безопасности для SQL Server 2025 CU4 - KB5089899

Описание: KB5089899

Скачать: SQLServer2025-KB5089899-x64.exe

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

SQL Server 2025 — Версия: 17.0.4040.1

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

Описание: KB5091223

Скачать: SQLServer2025-KB5091223-x64.exe

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

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

11.5.26

Создание баз данных через прослушивателя контейнерной группы доступности

Автор: Attinder_Pal_Singh. Creating a Contained Availability Group and Enabling Database Creation via CAG Listener

Контейнерная группа доступности (Contained Availability Group, CAG) предназначена для упрощения высокодоступности и аварийного восстановления путём инкапсуляции системных баз данных (master, msdb) непосредственно внутри самой группы доступности. Это означает, что учётные записи (логины), задания агента SQL Server, учётные данные и прочие метаданные автоматически реплицируются между репликами, устраняя необходимость ручной синхронизации и снижая эксплуатационную сложность.

Начиная с SQL Server 2025 CU1, вы можете создавать или восстанавливать базы данных напрямую через прослушиватель CAG — без подключения к физическому экземпляру — включая специальный ключ контекста сеанса.

29.4.26

Автоматическое исправление планов (Automatic Plan Correction) в SQL Server

Автор: theSQLSith, Query plan regressions got you down? Here's how can Automatic Plan Correction turns it around

Регрессии планов запросов донимают? Вот как автоматическое исправление планов (Automatic Plan Correction) может всё изменить.

Автоматическое исправление планов (Automatic Plan Correction, APC) — это одна из тех функций, о которой я довольно часто беседую с заказчиками, инженерами поддержки и широким сообществом SQL. Она входит в семейство автоматической настройки (Automatic Tuning) и незаметно выполняет свою работу, начиная с SQL Server 2017, обнаруживая регрессии планов запросов и автоматически принудительно применяя ранее известный хороший план для восстановления производительности. Но один из частых вопросов звучит так: как же APC на самом деле решает, произошла ли регрессия? И насколько оно уверено в этом решении?

Начиная с SQL Server 2022 CU4 и продолжая в SQL Server 2025, мы внесли значительные улучшения в статистическую модель, которую APC использует для обнаружения регрессий. В этой статье мы рассмотрим, что изменилось, почему это важно и как вы можете этим воспользоваться.

2.4.26

SQL Server Deprecated Features: 25-летняя хронология и руководство по обеспечению совместимости с будущими версиями

Автор: Steve Stedman, SQL Server Deprecated Features: A 25-Year Timeline and Future-Proofing Guide

За последние 25 лет Microsoft SQL Server значительно эволюционировал, внедряя мощные инструменты и функциональные возможности, одновременно отказываясь от других. В рамках этой эволюции многие возможности были помечены как устаревшие — они по-прежнему работают в текущих версиях, но планируются к удалению в будущих выпусках. Понимание этих устаревших возможностей имеет решающее значение для администраторов баз данных и разработчиков, чтобы обеспечить долгосрочную совместимость и избежать потенциальных сбоев в своих системах.

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

В этой статье мы рассмотрим подробную хронологию устаревших возможностей в различных версиях SQL Server, начиная с SQL Server 2000 и заканчивая последними выпусками. Изучив эти изменения, вы сможете лучше подготовиться к обновлениям, реорганизовать устаревший код и принять рекомендуемые практики, чтобы сохранить вашу инфраструктуру баз данных готовой к будущему. Давайте углубимся в ключевые возможности, которые были исключены за эти годы, и разберёмся с их заменами.

26.3.26

Десять лучших практик настройки производительности SQL Server

Автор: Paul Randal, SQL101: Top Ten SQL Server Performance Tuning Best Practices

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

25.3.26

Прекратите дефрагментировать индексы! Доступна для предварительного изучения функция Auto Index Compaction

Автор: Luca Biondi, Stop Defragmenting indexes: Auto Index Compaction feature preview in SQL Server – This Feature will Kills Index Maintenance Jobs!

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

👉 Если вы пропустили, посмотрите здесь:
SQL Server 2025 CU3 – Скрытое улучшение производительности, о котором никто не говорит

В этой же статье мы представим удивительную новость в мире SQL Server, которую я называю функцией автоматического уплотнения индексов (Auto Index Compaction).

25.2.26

Как оптимизировать переключение реплик групп доступности SQL Server

Автор: Aaron Bertrand , Serializing Deletes From Clustered Columnstore Indexes

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

Сокращение даже нескольких секунд из этого процесса может улучшить взаимодействие с приложением и конечным пользователем; это также может значительно снизить количество оповещений или, по крайней мере, сократить время, в течение которого оповещения должны быть отключены. Существует множество материалов о том, как правильно выполнять переключения в AG (без потери данных), но гораздо меньше тех, которые сосредоточены на сокращении окна прерывания доступности. Разница обычно заключается в некоторой комбинации объёма повторного выполнения (redo), поведения контрольных точек, открытых транзакций и готовности вторичной реплики.

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

10.2.26

Нечёткое сопоставление строк в SQL Server 2025

Автор: Leonard Lobel, Fuzzy String Matching in SQL Server 2025

Нечёткое сопоставление строк (Fuzzy String Matching) — это процесс поиска строк, которые приблизительно равны, а не точно совпадают. Это критически важная возможность для очистки данных, дедупликации, простого поиска по естественному языку и сопоставления пользовательского ввода с известными значениями.

До сих пор возможности нечёткого сопоставления в SQL Server были ограничены фонетическими сравнениями. Но теперь SQL Server 2025 представляют набор современных функций сходства строк, которые можно запускать напрямую в T-SQL с гораздо большей точностью.

5.2.26

Новое в SQL Server 2025: Change Event Streaming (Часть 2: Собирание событий)

Автор: Leonard Lobel, Getting Started with Change Event Streaming in SQL Server 2025 (Part 2: Consuming Events)

Во второй части статьи о новой функции потоковой передачи событий изменений (Change Event Streaming, CES) в SQL Server 2025 я покажу, как собираются события, генерируемые CES. В Части 1 мы подготовили концентратор событий Azure, сгенерировали токен SAS для доступа к нему, создали демонстрационную базу данных CesDemo и включили CES в базе данных. Затем мы добавили таблицы в группу потоков событий, специально подбирая параметры @include_old_values и @include_all_columns. Теперь CES передаёт DML-изменения (операции вставки, обновления и удаления) из этих таблиц в концентратор событий.

Примечание: Эта статья основана на SQL Server 2025 CTP 2.1. Синтаксис и поведение могут претерпеть незначительные изменения к моменту выпуска продукта. Потоковая передача событий изменений (CES) в конечном итоге будет поддерживаться во всех редакциях SQL Server, включая SQL Server 2025 для Windows, SQL Server 2025 для Linux, Azure SQL Database и Managed Instance.

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

Во-первых, CES лишь записывает данные в концентраторы событий (Event Hubs). Она не знает (и её это не волнует), кто слушает. Задача вашего клиентского приложения (или приложений) — впоследствии потреблять эти события. Наше демонстрационное приложение на C# будет использовать клиентский SDK концентраторов событий (а именно EventProcessorClient) для прослушивания событий.

Каждому клиенту CES нужно где-то записывать прогресс обработки событий. Это называется контрольной точкой (checkpoint), которая работает как «закладка». Используя контрольные точки, клиентские приложения могут останавливаться, а затем возобновлять работу с того места, где они остановились, не обрабатывая повторно уже обработанные события. SDK использует для этого хранилище BLOB-объектов Azure (Azure Blob Storage).

Вы также встретите термин группа потребителей (consumer group). Представьте группу потребителей как «представление» потока с собственной контрольной точкой. Используя несколько групп потребителей (по одной на клиентское приложение), каждое приложение может поддерживать собственную контрольную точку для отметки своего места в потоке событий. Тарифный план Basic позволяет использовать только одну группу потребителей. Переход на (и оплата) более высокого тарифа, чем Basic, позволит вам управлять несколькими клиентскими приложениями, которые одновременно потребляют события из одного концентратора событий, каждое в своём собственном темпе, не мешая друг другу.

4.2.26

Новое в SQL Server 2025: Change Event Streaming (Часть 1: Установка и настройка)

Автор: Leonard Lobel, Getting Started with Change Event Streaming in SQL Server 2025 (Part 1: Setup and Configuration)

Потоковая передача событий изменений (Change Event Streaming, CES) — одна из самых ожидаемых новых функций, которая появится в SQL Server 2025. Она позволяет непрерывно передавать поэтапные изменения из ваших таблиц напрямую в Azure Event Hubs, где несколько приложений-потребителей могут подписываться на данные событий в реальном времени.

Примечание: Эта статья основана на SQL Server 2025 CTP 2.1. Синтаксис и поведение могут претерпеть незначительные изменения к моменту выпуска продукта. Потоковая передача событий изменений (CES) в конечном итоге будет поддерживаться во всех редакциях SQL Server, включая SQL Server 2025 для Windows, SQL Server 2025 для Linux, Azure SQL Database и Managed Instance.

В этой серии из двух частей я покажу, как настроить и сконфигурировать CES (Часть 1), а затем как создать приложение-потребитель для обработки передаваемых изменений (Часть 2).