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

Описание: KB5075211

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

Дата выпуска: 12 февраля 2026 г.

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

Можно ли использовать динамические административные представления в режиме совместимости 80 (MSSQL 2000)?

Автор: Paul Randal, A DBA myth a day: (13/30) you cannot run DMVs when in the 80 compat mode (T-SQL Tuesday #005);

Нельзя выполнять динамические административные представления (DMV) в режиме совместимости 80.

ЛОЖЬ

Для начала, существует большая путаница относительно того, что означает режим совместимости. Означает ли это, что базу данных можно восстановить/присоединить к серверу SQL Server 2000? Нет. Это означает, что некоторые аспекты синтаксического разбора T-SQL, поведения планов запросов, подсказки и некоторые другие вещи ведут себя так же, как в SQL Server 2000 (или 2005, если вы устанавливаете значение 90 на экземпляре 2008).

У tempdb всегда должно быть по одному файлу данных на ядро процессора?

Автор: Paul Randal, A SQL Server DBA myth a day: (12/30) tempdb should always have one data file per processor core;

Этот миф я слышу снова, и снова, и снова…

У tempdb всегда должно быть по одному файлу данных на каждое ядро процессора.

ЛОЖЬ

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

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

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

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

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

Детализация прав для динамического маскирования данных в SQL Server 2022

Автор: Leonard Lobel, Granular Dynamic Data Masking (DDM) Permissions in SQL Server 2022

Динамическое маскирование данных (Dynamic Data Masking, DDM) — это функция безопасности, представленная ещё в SQL Server 2016. Она скрывает конфиденциальные данные в результирующем наборе запроса, гарантируя, что неавторизованные пользователи не увидят информацию, к которой не должны иметь доступ. Подробное введение в эту функцию можно найти в моей старой статье в блоге.

Эта статья объясняет новые возможности DDM, добавленные в SQL Server 2022, а именно — детализированные разрешения.

Оптимизация базы данных для нерегламентированных запросов

Автор: Joe Sack, Database scoped optimizing for ad hoc workloads

SQL Server предоставляет параметр оптимизации для нерегламентированных рабочих нагрузок (ad-hoc workloads), действующий в рамках всего сервера, который используется для уменьшения объёма памяти, занимаемого одиночными ad-hoc пакетами и связанными с ними планами. Когда этот параметр включён на уровне экземпляра SQL Server, при первом выполнении пакета ad-hoc для любой базы данных на экземпляре сохраняется «заглушка» скомпилированного плана с уменьшенным потреблением памяти. Эта опция сервера OPTIMIZE_FOR_AD_HOC_WORKLOADS доступна начиная с SQL Server 2019, и имет область действия на уровне базы данных.

Большое количество планов выполнения для одного запроса

Автор: Jose_Manuel_Jurado, Lesson Learned #494: High number of Executions Plans for a Single Query

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

Sniffing параметров в SQL Server

Автор: Vivek Johari, Parameter Sniffing in SQL Server

"Parameter Sniffing" (конфиденциальность параметров) в SQL Server происходит, когда план выполнения запроса генерируется с использованием конкретных значений параметров. Последующие выполнения того же запроса могут работать плохо с другими значениями параметров из-за неподходящего кэшированного плана. Вот как можно решить эту проблему:

Принудительные планы в SQL Server перезаписывают хэш запроса

Автор: Paul White, SQL Server Forced Plans Overwite the Query Hash

Если вы «принудительно» задаёте план, любым методом, включая руководство планом (Plan Guides), хранилище запросов (Query Store) и автоматическое исправление плана (Automatic Plan Correction), результирующий план будет иметь свой query_hash перезаписанным значением query_plan_hash.

Другими словами, хэш плана и хэш плана запроса получат значение хэша плана запроса. Реальное значение хэша запроса просто теряется. 🤦

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

Новое в 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, позволит вам управлять несколькими клиентскими приложениями, которые одновременно потребляют события из одного концентратора событий, каждое в своём собственном темпе, не мешая друг другу.

Новое в 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).

Журнал транзакций SQL Server, Часть 1: Основы журналирования

Автор: Paul Randal, The SQL Server Transaction Log, Part 1: Logging Basics

(Эта статья впервые появилась на SQLperformance.com четыре года назад как часть серии публикаций, до того как этот сайт был законсервирован в конце 2022 года и серия была прервана. Переопубликована здесь с разрешения, с небольшими правками.)

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

• Неуправляемый рост журнала транзакций и потенциальное исчерпание свободного места.
• Проблемы с производительностью из-за повторяющихся операций сжатия журнала транзакций.
• Проблемы с производительностью из-за явления, известного как фрагментация виртуальных файлов журнала (VLF), о котором я писал в этой статье.
• Невозможность восстановить базу данных до желаемой точки во времени с использованием резервных копий журнала транзакций.
• Невозможность выполнить резервное копирование заключительного фрагмента журнала (tail-log backup) во время аварийного восстановления (см. здесь объяснение таких копий).
• Различные проблемы, связанные с переключением при отказе (failover) и производительностью восстановления.

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