23.4.26

Проверка состояния TempDB за 45 секунд

Автор: Luca Biondi, SQL Server Parameter Sniffing: The Bug That Isn’t a Bug (But Breaks Everything)

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

Когда сервер работает медленно, но метрики CPU и ввода-вывода выглядят нормально. Когда планы выполнения выглядят приемлемо, но что-то всё равно не так. Когда запросы нестабильны — то быстры, то еле ползут — и пользователи жалуются, хотя вы не видите ничего очевидного...

Вот где многие администраторы баз данных тратят часы.

👉 Помните: TempDB часто оказывается замешана, но почти никогда не является первопричиной.

22.4.26

Ошибка в sys.dm_exec_query_plan_stats

Автор: Brent Ozar, There’s a Bug in sys.dm_exec_query_plan_stats.

Когда вы включаете последние актуальные планы в SQL Server 2019 и новее:

ALTER DATABASE SCOPED CONFIGURATION SET LAST_QUERY_PLAN_STATS = ON;

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

21.4.26

Индексы под всеми углами: Как определить, используется ли индекс?

Автор: Paul Randal, Indexes From Every Angle: How can you tell if an index is being used?

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

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

20.4.26

Чтение заголовков файлов SQL Server с помощью DBCC FILEHEADER

Автор: Anthony Nocentino, Reading SQL Server File Headers with DBCC FILEHEADER

Недавно я глубоко погрузился в изучение дисковых структур SQL Server, и одно из моих любимых направлений — это перечитывание серии статей Пола Рэндала (Paul Randal) о страницах заголовков файлов. Если вы её не читали, сделайте это прямо сейчас. В ней рассказывается о том, что такое страницы заголовков файлов, что они содержат и что происходит при их повреждении. Эта статья развивает эту концепцию. Я буду использовать DBCC FILEHEADER для чтения заголовка каждого файла пользовательской базы данных на сервере и отвечу на вопрос, который возникает чаще, чем можно подумать: можно ли определить, какие файлы принадлежат одной базе данных, исключительно по заголовку файла, без обращения к sys.databases?

Короткий ответ — да, и поле, которое делает это возможным, называется BindingId. Давайте разбираться.

19.4.26

"Все" мифы о резервном копировании

Автор: Paul Randal, A SQL Server DBA myth a day: (30/30) backup myths

Пришло время грандиозного финала!

Хотя было весело развенчивать все эти мифы, это было немного напряжённо — каждый день находить интересный и полезный миф для разоблачения.

В завершение я представляю вам 30 мифов о резервном копировании — по одному на каждый день апреля. Вчера вечером я сел писать эту статью и не добрал несколько мифов, поэтому обратился за помощью к великолепному сообществу SQL в Twitter — слишком много людей, чтобы перечислять (вы знаете, кто вы) — я благодарю вас!

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

Итак, поехали, последний выпуск…

16.4.26

Представления производительности в реальном времени, которые упрощают устранение неполадок

Автор: Pinal Dave, Real-Time Performance Views That Make Troubleshooting Easier

Запрос, который вчера выполнялся за 200 миллисекунд, сегодня выполняется 14 секунд. Команда приложения заметила это раньше, чем инструмент мониторинга. К тому моменту, когда кто-то открывает сервер базы данных, в представлении активных запросов находится 47 сеансов, три из них заблокированы, и один из них удерживает блокировку, которая открыта уже шесть минут. Никто не может сказать вам, что делает этот сеанс, кому он принадлежит и безопасно ли его завершить. Это не проблема оборудования. Это проблема видимости. И она встречается чаще, чем следовало бы. Давайте поговорим о представлениях производительности в реальном времени, которые упрощают устранение неполадок.

15.4.26

Исправление безопасности для SQL Server 2025 CU3 - KB5083245

Описание: KB5083245

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

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

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

Исправление безопасности для SQL Server 2025 GDR - KB5084814

Описание: KB5084814

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

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

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

Исправление безопасности для SQL Server 2022 CU24 - KB5083252

Описание: KB5083252

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

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

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

Исправление безопасности для SQL Server 2022 GDR - KB5084815

Описание: KB5084815

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

Дата выпуска: 14.04.2026.

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