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

Почему большие столбцы могут не влиять на логические чтения

Автор: Brent Ozar, Database Animations: Why Big Columns May Not Affect Logical Reads

Со временем таблицы — как и наша талия — имеют свойство увеличиваться. Мы постоянно добавляем всё новые и новые столбцы, один за другим, чтобы удовлетворить потребности приложений. Добавить «ещё один столбец» проще, чем выносить что-то в отдельную таблицу.

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

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

Два дополнительных элемента управления при включённой автоматической коррекции планов

Автор: Erin Stellato (MICROSOFT), Two additional controls with Automatic Plan Correction enabled;

Несколько недель назад я опубликовала свой первый «Пятничный отзыв» о Хранилище запросов (Query Store), и один из ответов ссылался на хранимую процедуру, которую я раньше не использовала: sp_configure_automatic_tuning. Было высказано предположение, что эта хранимая процедура не документирована и работает не так, как ожидалось. Зная, как сильно я люблю Хранилище запросов, автоматическую коррекцию планов и документацию, я отправилась на поиски. Если вы не знакомы с этой хранимой процедурой, читайте дальше.

Диагностика конкуренции за tempdb

Автор: Paul Randal, The Accidental DBA (Day 27 of 30): Troubleshooting: Tempdb Contention

Одна из самых распространённых проблем производительности, существующих в экземплярах SQL Server по всему миру, известна как конкуренция за tempdb. Что это означает? Конкуренция за tempdb относится к узкому месту для потоков, пытающихся получить доступ к страницам распределения, находящимся в памяти; это не связано с вводом-выводом.

Накопительный пакет обновления SQL Server 2022 CU26 - KB5093420

Описание: KB5093420

Скачать: SQLServer2022-KB5093420-x64.exe

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

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

Analysis Services — Версия: 16.0.43.252

Краткое описание изменений

• Добавлена более подробная информация об ошибках в журнал кластера Windows Server Failover Cluster, если ресурс группы доступности не может получить диагностические сведения о колонках.
• Добавлена поддержка удаления IP-адреса из прослушивателя группы доступности с помощью команды ALTER AVAILABILITY GROUP ... MODIFY LISTENER ... REMOVE IP.
• Исправлена уязвимость SQL-инъекции в хранимой процедуре sys.sp_MSforeachdb, позволяющая авторизованному злоумышленнику повысить привилегии через сеть.
• Исправлена проблема, из-за которой план обслуживания перестройки индекса переставал отвечать из-за длительного запроса.
• Исправлен сбой мониторинговых запросов с использованием sys.dm_exec_requests или sys.sysprocesses на вторичной реплике группы доступности (ошибки 976 или 978).
• Исправлена ошибка интерполяции в новом оценщике кардинальности для очень больших значений, из-за которой операция ALTER INDEX выбирала последовательный план.
• Удалена устаревшая криптографическая библиотека RSA32Lib в рамках модернизации шифрования.
• Исправлено нарушение доступа при выполнении ALTER PARTITION FUNCTION ... SPLIT RANGE для функции секционирования, используемой таблицей с identity-столбцом, на который ссылается кластеризованный индекс в схемно-привязанном представлении.
• Исправлено состояние «nonyielding scheduler», возникающее при записи некоторых ошибок в журнал ошибок SQL Server.
• Скорректирован коэффициент выборки для инкрементальной статистики, если последний коэффициент выборки был 100 % и в таблицу добавлено много новых строк.
• Улучшено управление памятью при компиляции запросов для индексов columnstore, что сокращает время компиляции.
• Исправлено состояние «nonyielding scheduler», возникающее при итерации sys.dm_db_index_operational_stats по большому количеству кэшированных куч или B-деревьев.

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

Описание: KB5096981

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

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

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

Analysis Services — Версия: 17.0.25.223

Краткое писание изменений

• Исправлен сбой мониторинговых запросов к вторичной реплике (ошибки 976/978) в группе доступности.
• Шифрование UCS переключено на AES-256 (вместо AES-128), если TLS не включён явно.
• Устранено состояние «non-yielding scheduler» при записи ошибки часового пояса в журнал ошибок.
• Добавлен флаг трассировки для включения TLS 1.3 (без правки реестра).
• Усилено шифрование диалогов Service Broker — теперь AES-256.
• Введено логическое ограничение для функции EDIT_DISTANCE, предотвращающее переполнение и DoS-атаки.
• Удалена поддержка устаревшего BinaryMessageFormatter (2000) в задаче Message Queue — устранена уязвимость десериализации.
• Исправлен вызов дампа при ALTER JSON INDEX REORGANIZE, если статистика существует во внутренней таблице JSON-индекса.
• Исправлен неверный расчёт смещения родительского узла, вызывавший повреждение JSON при JSON_MODIFY.
• Устранено повреждение данных и дамп-файл при операции слияния JSON_MODIFY.

Код для оценки потенциальной экономии пространства ключа кластеризации для каждой таблицы

Автор: Paul Randal, Code to list potential cluster key space savings per table

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

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

Вы можете модифицировать код по своему усмотрению. И я продолжаю использовать sp_msforeachdb, потому что это самый быстрый способ для меня написать код для вас, и это продолжает раздражать моего хорошего друга Аарона Бертрана (Aaron Bertrand) :-)

Наслаждайтесь!

Статистика ожиданий для одной операции

Автор: Paul Randal, Capturing wait stats for a single operation

Эта статья о настройке производительности, которая давно была в моём списке задач. Анализ статистики ожиданий — отличный способ изучить симптомы проблем с производительностью (см. мой каталог Wait Stats для получения дополнительной информации), но использование DMV sys.dm_os_wait_stats показывает всё, что происходит на сервере. Если вы хотите увидеть, какие ожидания возникают из-за одного запроса или операции в рабочей системе (например, влияние подсказок MAXDOP на количество и продолжительность ожиданий CXPACKET для запроса), то использование DMV обычно нецелесообразно — вам пришлось бы очистить статистику ожиданий и убедиться, что в системе не выполняется ничего, кроме исследуемого запроса/операции. Наиболее правильный способ сделать это — использовать расширенные события (Extended Events).

Структуры хранения #5 – XML-индексы

Автор: Hugo Kornelis, Storage structures 5 – XML indexes;

После рассмотрения дискового строчного хранения, индексов columnstore, оптимизированных для памяти структур и оптимизированных для памяти columnstore, пришло время обратить внимание на структуры хранения, которые используются только для определённых типов данных. Первой «жертвой» станет XML-индекс.

Оптимизация запросов: выражения в предложении WHERE, не допускающие поиска по индексу

Автор: Paul Randal, Adventures in query tuning: non-seekable WHERE clause expressions

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

Я подготовлю тестовый пример, чтобы показать, что я имею в виду.

Отслеживание тяжёлых запросов с помощью расширенных событий

Автор: Paul Randal, Tracking expensive queries with extended events in SQL 2008

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

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

Автор: Paul Randal, Important considerations when performance tuning

Что, по вашему мнению, является самым важным аспектом при настройке производительности, если бы пришлось выбрать что-то одно? Суть в том, что в общем случае ответ всегда «зависит», но некоторые вещи оказываются главной проблемой чаще, чем другие. Давайте пройдёмся по каждому возможному ответу и посмотрим, как сильно они могут повлиять на производительность, если что-то не так. Это ни в коем случае не исчерпывающий список того, что может вызвать проблемы, а просто мои размышления в конце воскресенья, как обычно.

Настройка производительности CDC

Автор: Штеффен Краузе (Steffen Krause)

Соавторы: Санджай Мишра (Sanjay Mishra), Гопал Ашок (Gopal Ashok), Грег Ивкофф (Greg Yvkoff), Жуй Ван (Rui Wang)

Технические рецензенты: Бурзин Патель (Burzin Patel), Денни Ли (Denny Lee), Гленн Берри (Glenn Berry, MVP SQL Server), Джозеф Сак (Joseph Sack), Линдси Аллен (Lindsey Allen), Майкл Редман (Michael Redman), Майк Рутрафф (Mike Ruthruff), Пол С. Рэндал (Paul S. Randal, SQLskills.com), Tuning the Performance of Change Data Capture in SQL Server 2008

Краткое содержание: Отслеживание изменений данных (Change Data Capture, CDC) — это новая функция в SQL Server, которая предоставляет простой способ отслеживания изменений данных в наборе таблиц базы данных для последующей передачи этих изменений во вторую систему, например, в хранилище данных. В этом документе содержатся рекомендации по настройке параметров отслеживания изменений данных для максимальной производительности захвата данных при минимальном влиянии на производительность производственной нагрузки. Область действия этого документа ограничена захватом изменяемых данных и процессом очистки. Запрос изменённых данных не входит в область действия данного технического документа.

Форматирование T-SQL запросов в SSMS 22.7

Автор: Chad Callihan , SQL Formatting in SSMS 22.7

Форматирование кода может быть деликатной темой. Иногда существуют чёткие правила, определяющие правильное и неправильное, а иногда их нет. Пробелы против табуляции, что выбрать?

Как ни удивительно, но в SQL Server Management Studio никогда не было встроенного средства форматирования SQL. Пользователям всегда приходилось пользоваться сторонними инструментами или форматировать вручную. Но с выходом последней версии SSMS 22.7 форматирование SQL наконец стало встроенной функцией.

Давайте рассмотрим несколько примеров и посмотрим, как она работает.

Могут ли ключи кластерного индекса с типом GUID вызывать фрагментацию некластерных индексов?

Автор: Paul Randal, Can GUID cluster keys cause non-clustered index fragmentation?

На встрече пользовательской группы я потратил некоторое время на объяснение того, как GUID могут вызывать фрагментацию как в кластерных, так и в некластерных индексах, даже если GUID специально не включён в ключ некластерного индекса. GUID — это, по сути, случайные значения (псевдослучайные в диапазонах, если генерируются с помощью NEWSEQUENTIALID), которые также уникальны. Их уникальность делает их привлекательными для многих разработчиков в качестве значения ключа, не понимая при этом того хаоса, который они могут вызвать в производственной среде с точки зрения фрагментации и низкой производительности запросов.

Насколько сложно выбрать правильные некластерные индексы?

Автор: Paul Randal, How hard is it to pick the right non-clustered indexes?

На собрании группы разработчиков .NET в Редмонде, и во время того, как Кимберли рассказывала о пропущенных и лишних индексах, возник следующий вопрос:

«Какой некластерный индекс лучше всего использовать для запроса с условием WHERE lastname = 'Randal' AND firstname = 'Paul' AND middleinitial = 'S'?»

Кимберли сказала, что для этого случая порядок ключей не имеет значения. Я подумал секунду, а затем возразил, сказав, что наиболее селективный столбец должен быть первым. Мы согласились обсудить это с группой в конце, но я подумал ещё немного и понял (и признался группе), что она права – мне следовало бы знать, что не стоит подвергать сомнению знания Кимберли об индексировании… :-)

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

Описание: KB5093421

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

Дата выпуска: 17 июня 2026 г.

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