NUMA и soft-NUMA в SQL Server: Получение дополнительных потоков ввода-вывода

Автор: Paul Randal, NUMA and soft-NUMA in SQL Server: To get additional I/O threads

Производительность может быть значительно улучшена, если ядро SQL Server обнаруживает физические узлы NUMA в системе Windows. Наряду с аппаратным NUMA, Microsoft также представила архитектуру soft-NUMA (программный NUMA) для создания дополнительных виртуальных узлов NUMA внутри SQL OS. Начиная с SQL Server 2016 (13.x), если ядро базы данных обнаруживает более восьми «физических ядер на узел NUMA» или более восьми «сокетов», узлы soft-NUMA создаются автоматически. Создание узлов soft-NUMA позволяет ядру базы данных SQL Server создавать больше потоков ввода-вывода для повышения производительности требовательных транзакционных рабочих нагрузок SQL Server.

Убивают ли задержки ввода-вывода вашу производительность?

Автор: Paul Randal, Are I/O latencies killing your performance?

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

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

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

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

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

Строки подключения к SQL Server: Microsoft SqlClient Data Provider for SQL Server

Авторы, SQL Server connection strings

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

Как правильно писать "Data Source=(local)" в строках подключения SQL Server

Автор: Dan Benediktson, Understanding “Data Source=(local)” in SQL Server Connection Strings
Мы заметили множество недопониманий, связанных с использованием ключевого слова Data Source в строках подключения, вызванных тем, что люди обобщают пример, демонстрирующий строку подключения для локального соединения, и создают свою собственную строку подключения для удалённого соединения. 

Асинхронная репликация снимков из пода ActiveCluster на ещё одну систему хранения

Автор: Anthony Nocentino, Asynchronous Replication of Snapshots from an ActiveCluster Pod to a Third Array

Я восстанавливал свою трёхсайтовую демонстрационную лабораторию SQL Server и столкнулся с тем, чего давно хотел. Если вы когда-либо проектировали среду SQL Server на ActiveCluster, вам знаком этот сценарий: два FlashArray, работающие с синхронно реплицируемым модулем (pod) для нулевой точки восстановления (RPO) между сайтами, и третья система хранения где-то ещё для более длительного хранения и копии для аварийного восстановления. Проблема была в том, что вы не могли получить данные на эту третью систему хранения напрямую из пода Группы защиты внутри растянутого пода просто не могли иметь целью систему хранения.

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

В этой статье я покажу, как настроить это «от начала до конца» с помощью Pure Storage PowerShell SDK2, чтобы вы могли автоматизировать этот процесс. Поехали.

Разница между сжатием строк и сжатием страниц

Автор: Brent Ozar, Database Animations: The Difference Between Row Compression and Page Compression

В чём разница между сжатием строк (row compression) и сжатием страниц (page compression) в SQL Server, и когда имеет смысл применять каждое из них?

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

Чтобы увидеть это более подробно, давайте запустим одну из моих Database Animations.

Устранение задержек перемещения данных между группами доступности AlwaysOn с синхронной фиксацией

Автор: Simon Su, Troubleshooting data movement latency between synchronous-commit AlwaysOn Availability Groups
Технические рецензенты: Pam Lahoud, Sourabh Agarwal, Tejas Shah

В узлах группы доступности (AG) с синхронной фиксацией иногда можно наблюдать, что ваши транзакции ожидают в состоянии HADR_SYNC_COMMIT. Ожидания HADR_SYNC_COMMIT указывают на то, что SQL Server ожидает сигнала от удалённых реплик для фиксации транзакции. Чтобы понять задержку фиксации транзакций, вы можете обратиться к следующим статьям:

• Troubleshooting High HADR_SYNC_COMMIT wait type with AlwaysOn Availability Groups
• SQL Server 2012 AlwaysOn – Part 12 – Performance Aspects and Performance Monitoring II

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

• SQL Server:Database Replica –> Transaction Delay
• SQL Server:Database Replica –> Mirrored Write Transactions/sec

Например, предположим, что есть плохо работающие узлы AG, и вы видите, что «SQL Server:Database Replica –> Transaction Delay» составляет 1000 мс, а «SQL Server:Database Replica –> Mirrored Write Transactions/sec» равно 50. Это означает, что в среднем каждая транзакция имеет задержку 1000 мс / 50 = 20 мс.

Учитывая приведённый пример, можем ли мы узнать, откуда берётся задержка в 20 мс? Какие факторы вызывают эту задержку? Чтобы найти ответы на такие вопросы, нам нужно понять, как работает синхронная фиксация: AlwaysOn HADRON Learning Series: How does AlwaysOn process a synchronous-commit request?

Расчёт задержки в сети между репликами группы доступности 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 2025 CU8 - KB5104822

Описание: KB5104822

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

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

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

Analysis Services — Версия: 17.0.25.223

Известные проблемы:

• SESSION_CONTEXT в параллельных планах → неверные результаты или AV-ошибки.
• Запросы к связанным серверам через MSDASQL → ошибка 7416.
• Запросы к sys.dm_exec_requests во время восстановления БД → AV и дамп

Исправления (выборочно):

• Долгое восстановление VSS с сотнями БД.
• Шифрование gRPC для PolyBase на Linux.
• Зависание перестройки индексов.
• Неверная рекомендация памяти при установке.
• Проблемы с JSON_MODIFY и OPENJSON (спецсимволы, массивы > 65535 элементов).
• Ошибки с Hekaton, collation на Linux, репликацией и DBCC CHECKTABLE.

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

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