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

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

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

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

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

SQL Server 2025 показывает высокую загрузку процессоров!

Автор: Rob Farley, SQL 2025 showing crazy-high CPU;

Да, вам стоит подумать о переходе на SQL Server 2025. Но если вы используете учётные записи SQL Server, сначала проверьте это (а если вы здесь, чтобы понять, почему вдруг всё замедлилось, читайте дальше).

В большинстве случаев обновление до SQL Server 2025 проходит довольно гладко. Я бы даже сказал, что обновления до других версий SQL Server тоже проходили гладко, хотя многие пострадали от проблем с производительностью из-за изменения модели оценки кардинальности при обновлении до SQL 2014 (точнее, уровня совместимости 120). «Простым» решением тогда было вернуть уровень совместимости на 110, а затем разобраться, что именно вызывало проблемы. Но в SQL Server 2025 есть ещё одна болевая точка, обойти которую не так просто.

Полное руководство по xEvents

Автор: Vivek Johari, Extended Events (xEvents) in SQL Server & Azure SQL: Complete Guide;

Каждому администратору баз данных рано или поздно приходится сталкиваться с этим: приходит заявка в службу поддержки с сообщением «приложение работает медленно» и без каких-либо других подробностей, и ваша задача — выяснить, какая из тысячи вещей, происходящих внутри SQL Server, на самом деле является виновником. Это была блокировка? Плохой план? Шквал входов в систему? Чей-то ситуативный запрос, в котором забыли условие WHERE и который сейчас сканирует одиннадцать миллионов строк?

Долгое время ответом на вопрос «давайте посмотрим, что происходит в реальном времени» был SQL Server Profiler, работающий поверх SQL Trace. Он работал, но работал так, как работает прожектор, когда на самом деле вам нужен был фонарик — он захватывал всё без разбора, выполнялся на стороне клиента и мог заметно замедлить загруженный рабочий сервер просто фактом своего включения. Достаточно много администраторов баз данных имеют историю о том, как благонамеренная трассировка Profiler ухудшала состояние и без того перегруженного сервера, что в конечном итоге привело к тому, что Microsoft перестала рекомендовать его вообще.

Расширенные события (Extended Events, xEvents) пришли на смену, и это не просто незначительное обновление, — это принципиально иная архитектура, и это инструмент, который экзамен DP-300 требует знать досконально. Эта статья описывает, что это такое, почему он превосходит старые инструменты и — что действительно важно в повседневной работе — как использовать его для отслеживания блокировок, взаимоблокировок, медленных запросов, таймаутов, высокой загрузки ЦП, сбоев входа в систему и статистики ожиданий.

Почему одни статистики остаются устаревшими, в то время как другие обновляются автоматически

Автор: Jose Manuel Jurado (MICROSOFT), Lessons Learned #547:Some SQL DB Statistics Remain Outdated While Others Are Automatically Updated;

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

• Более старую дату last_updated.
• Высокое значение modification_counter.
• Количество строк, значительно меньшее, чем текущее количество строк в таблице.

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

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

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

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

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

Автор: Hugo Kornelis, Storage structures 6 – JSON indexes;

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

Microsoft представила ограниченную поддержку JSON в SQL Server 2016. Однако только в SQL Server 2025 появились собственный тип данных json и JSON-индексы. Итак, давайте посмотрим, как они работают «под капотом».

Как и когда сжимать файлы журналов SQL Server: рекомендации

Автор: Steve Stedman, How and When to Shrink SQL Server Log Files: Best Practices

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

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

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

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

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

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

Производительность DBCC CHECKDB и индексы на вычисляемых столбцах

Автор: Paul Randal, DBCC CHECKDB performance and computed-column indexes

[Примечание 2016 г.: Команда разработчиков «исправила» проблему в SQL Server 2016, отключив проверку согласованности этих индексов, если не используется параметр WITH EXTENDED_LOGICAL_CHECKS.]

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

Проблема возникает, когда существует некластерный индекс, в котором вычисляемый столбец является частью ключа индекса или одним из включённых столбцов (INCLUDE), и влияет на DBCC CHECKDB, DBCC CHECKFILEGROUP и DBCC CHECKTABLE.

Наиболее распространённые классы кратких блокировок и их значение

Автор: Paul Randal, Most common latch classes and what they mean

Я проводил опрос о распространённых кратких блокировках (их ещё называют защёлками - latch) на экземплярах SQL Server по всему миру. Я получил информацию почти с 600 серверов, и если вы помните, я дал вам код для вывода основных нестраничных защёлок, ожидаемых во время ожиданий LATCH_XX. Нестраничные защёлки — это те, которые не являются ни PAGELATCH_XX (ожидание доступа к копии страницы файла данных в памяти), ни PAGEIOLATCH_XX (ожидание чтения страницы файла данных с диска в память).

Накопительный пакет обновления 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.