Взаимоблокировка SQL Server: создайте её сами

Автор: Pinal Dave, SQL Server Deadlock: Build One With Your Own Hands

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

Transaction (Process ID 57) was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction.

SQL Server разрешает цикл, выбирая одну транзакцию в качестве жертвы, откатывая её и возвращая ошибку 1205. Выжившая транзакция затем может продолжить.

Знакомьтесь sqlsimtools - инструмент для проектирования рабочих нагрузок SQL

Автор: Bob Ward, Microsoft, Introducing sqlsimtools

Много лет назад в далёкой-далёкой галактике мои коллеги из службы поддержки Кит Элмор и Роберт Дорр создали инструмент под названием ostress.exe. На протяжении десятилетий он менял то, как мы воспроизводили проблемы клиентов для SQL Server. Команда разработчиков использовала его, и до недавнего времени я использовал его для демонстраций, книг и примеров. Его магия была простой: ostress мог имитировать множество одновременных пользователей, выполняющих SQL-запросы или скрипты.

Я решил переосмыслить ostress для сегодняшнего мира SQL, и результатом стал sqlsimtools, теперь в публичной предварительной версии по адресу microsoft.github.io/sqlsimtools/. Это бесплатный набор инструментов моделирования рабочих нагрузок с открытым исходным кодом для SQL Server 2019, 2022 и 2025, Azure SQL Database, Azure SQL Managed Instance и SQL database в Microsoft Fabric. Я создавал его некоторое время и использовал на мероприятиях и в демонстрациях. Теперь я хочу, чтобы он был у всех.

Новое в SQL Server 2025: оптимизация плана с опциональными параметрами (OPPO)

Автор: Luca Biondi, SQL SERVER 2025 Optional Parameter Plan Optimization (OPPO). What It Is and Benchmarks — Internal Part 1 Series

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

Структуры хранения #7 – Пространственные индексы

Автор: Hugo Kornelis, Storage structures 7 – Spatial indexes

С возвращением в серию о внутреннем устройстве структур хранения. Я начал с обзора стандартных типов хранения в выпусках о дисковом rowstore, колоночных индексах, оптимизированном для памяти хранилище и оптимизированных для памяти колоночных хранилищах, а затем перешёл к специализированным структурам хранения в частях об XML-индексах и JSON-индексах. Теперь пришло время рассмотреть пространственные индексы.

Динамическое маскирование данных — что это, чем оно не является и как использовать его эффективно

Автор: Madhumita Tripathy MSFT, Dynamic Data Masking – What it is, What it isn’t, and How to use it effectively

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

Обменяйте устойчивость на производительность

Автор: Aaron Bertrand, Delayed Durability in SQL Server 2014

Отложенная устойчивость (Delayed Durability) — это появившаяся в последний момент в SQL Server 2014, но интересная возможность; её краткая суть в лифтовой презентации звучит буквально так:

«Обменяйте устойчивость на производительность».

Сначала немного предыстории. По умолчанию SQL Server использует журнал упреждающей записи (write-ahead log, WAL), что означает, что изменения записываются в журнал до того, как им разрешено быть зафиксированными. В системах, где записи в журнал транзакций становятся узким местом и где есть умеренная терпимость к потере данных, у вас теперь есть возможность временно приостановить требование ждать сброса журнала и подтверждения. Это буквально убирает букву D из ACID, по крайней мере для небольшой части данных (подробнее об этом позже).

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

Ваш план обслуживания перестраивает индексы, которыми никто не пользуется

Автор: Pinal Dave, Your Index Rebuild Maintenance Plan Is Rebuilding Indexes Nobody Uses

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

Резервные копии снимком на вторичных репликах группы доступности

Автор: Andrew Pruski, T-SQL Snapshot Backups on Availability Group Secondary Replicas

Одной из моих любимых возможностей SQL Server 2022 были резервные копии снимком (Transact-SQL snapshot backup). Возможность использовать снимки современных систем хранения для создания согласованных на уровне приложения снимков наших баз данных — это прорыв для всех, кто имеет дело с очень большими базами данных и изо всех сил пытается уложиться в RPO при заданном RTO.

Однако согласованные на уровне приложения снимки требуют, чтобы запись ввода-вывода базы данных была приостановлена/заморожена/остановлена… и (справедливо) это может заставить администраторов баз данных нервничать.

Как работают JSON-индексы в SQL Server

Автор: Brent Ozar, Database Animations: How SQL Server’s JSON Indexes Work

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

Что такое остаточный предикат (residual predicate) и почему это плохо?

Автор: Brent Ozar, Database Animations: What’s a Residual Predicate and Why Is It Bad?

Обычно, когда вы смотрите на план выполнения и видите поиск по индексу (index seek), за которым следует поиск по ключу (key lookup), это означает, что запрос выполняется относительно быстро.

Уровень совместимости и оценщик кардинальности в SQL Server

Автор: Vivek Johari, Compatibility Level vs. Cardinality Estimator in SQL Server: A Complete Guide;

Если вы когда-либо занимались настройкой производительности SQL Server, вы почти наверняка сталкивались с двумя терминами, которые постоянно путают: уровень совместимости (Compatibility Level, CL) и оценщик кардинальности (Cardinality Estimator, CE). Они звучат так, будто могут быть одним и тем же, поскольку изменение одного часто влияет на поведение другого. Но это два разных понятия в ядре SQL Server, и понимание того, где они пересекаются, а где расходятся, необходимо для всех, кто занимается обновлениями, миграциями или настройкой запросов.

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

Промежуточная материализация (Query Memory Spills)

Автор: Klaus Aschenbrenner, Query Memory Spills

Иногда, когда вы смотрите на планы выполнения, вы можете увидеть, что у оператора SELECT иногда есть так называемый грант памяти (Memory Grant). Этот грант памяти указывается в килобайтах и необходим для выполнения запроса, когда некоторым операторам (например, Sort/Hash) в планах выполнения требуется память для выполнения — так называемая память запроса (Query Memory).

Новое в SQL Server 2025: Мультипликативная агрегация с функцией PRODUCT

Автор: Leonard Lobel, Multiplicative Aggregates with the PRODUCT Function in SQL Server 2025

В этой статье блога рассматривается новая функция PRODUCT в SQL Server 2025, которая вычисляет произведение набора числовых значений — аналогично тому, как SUM и AVG работают для сложения и усреднения, но для умножения.

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

PRODUCT поддерживает как агрегатную, так и аналитическую (оконную) формы и работает как со значениями ALL (по умолчанию), так и с DISTINCT. Значения NULL игнорируются, и функция совместима со всеми числовыми типами, кроме bit.

Проблемы производительности из-за ORDER BY/GROUP BY — сбросы в tempdb

Автор: Sarjen Haque, Performance issues from ORDER BY/GROUP BY - spills in tempdb

Совершенно обычно и ожидаемо видеть запрос, содержащий предложение ORDER BY или GROUP BY для целей отображения или группировки. Также часто разработчики используют предложение ORDER BY по привычке, не задумываясь о его необходимости. В результате запросы со временем замедляются по мере увеличения количества записей.

Когда происходят сбросы (spill) для Hash, Sort и Exchange

Автор: Remus Rusanu, Understanding Hash, Sort and Exchange Spill events

Некоторые операции при выполнении запросов SQL Server рассчитаны на наилучшую производительность при использовании (относительно) большого объёма памяти в качестве промежуточного хранилища. Оптимизатор запросов выбирает план и оценивает стоимость, основываясь на том, что эти операторы используют эту «черновую» память. Но это, конечно, лишь оценка. Во время выполнения оценки могут оказаться неверными, и план должен продолжить работу, несмотря на нехватку памяти. В таком случае эти операторы выполняют сброс на диск (spill). Когда происходит сброс, «черновая» память сбрасывается в tempdb, и новые данные размещаются в (теперь) свободной памяти. Когда данные, сброшенные в tempdb, снова нужны, они читаются с диска. Само собой разумеется, сброс в tempdb на порядок медленнее, чем использование только «черновой» памяти. Мониторинг сбросов особенно важен в ETL-задачах, поскольку эти случаи могут растянуть выполнение ETL на многие минуты, а иногда даже часы. Для исчерпывающего обсуждения ETL, включая некоторые ссылки на сбросы, см. Руководство по производительности загрузки данных.

Что происходит с данными и журналом при сбросах в tempdb

Автор: Paul Randal, Understanding data vs log usage for spills in tempdb

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

Расчёт задержки в сети между репликами группы доступности Always On

Автор: Paul Ou Yang, Calculating Network Latency Between Always On Availability Group Replicas

У нас было бизнес-требование добавить облачную асинхронную реплику к локальной группе доступности SQL Server Always On. После добавления высоконагруженной базы данных в группу доступности мы заметили, что очередь отправки журнала начала быстро расти.

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

Один из полезных подходов — использовать трассировку Extended Events для перемещения данных Always On, описанную в статье Microsoft: Устранение задержек перемещения данных между группами доступности AlwaysOn с синхронной фиксацией

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

Управление кешем планов SQL Server: диагностика и решение проблем

Кеш планов SQL Server — это критически важный компонент, который хранит планы выполнения запросов для повторного использования. Однако неправильное использование этого механизма может привести к серьезным проблемам производительности. В этой статье мы рассмотрим:

• Как работают корзины (buckets) в кеше планов
• Как диагностировать проблемы с неравномерным распределением планов
• Как выявлять проблемные запросы и процедуры
• Стратегии решения проблем без использования регламентированных запросов

Адаптивный мониторинг актуальности статистики в SQL Server

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

Лучшая пожарная сигнализация — всё равно пожар

Автор: Pinal Dave, A Better Fire Alarm Is Still a Fire

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