Вот интересный вопрос, который прислал мне мой друг Стив Джонс из SQL Server Central — будет ли один процессор с двумя ядрами работать лучше, чем два одноядерных процессора? Оба варианта имеют два вычислительных ядра, но аппаратная архитектура разная — какой из них обеспечит лучшую производительность SQL Server? Что ж, однозначного ответа нет — всё зависит от многих факторов! Я обсуждал эту тему с Джеромом Халмансом, бывшим коллегой по команде Storage Engine в SQL Server, и с его разрешения я основываю эту статью на нашем обсуждении.
MS SQL Server дело тонкое...
24.4.26
Работают ли многоядерные процессоры лучше, чем одноядерные?
23.4.26
Проверка состояния TempDB за 45 секунд
В этой статье я покажу вам, как обнаружить нагрузку на TempDB менее чем за 45 секунд и, что ещё важнее, — как правильно её интерпретировать.
Потому что выявление истинного узкого места — это то, что отличает реактивных администраторов баз данных от инженеров по производительности.
Когда сервер работает медленно, но метрики CPU и ввода-вывода выглядят нормально. Когда планы выполнения выглядят приемлемо, но что-то всё равно не так. Когда запросы нестабильны — то быстры, то еле ползут — и пользователи жалуются, хотя вы не видите ничего очевидного...
Вот где многие администраторы баз данных тратят часы.
👉 Помните: TempDB часто оказывается замешана, но почти никогда не является первопричиной.
22.4.26
Ошибка в 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
Индексы под всеми углами: Как определить, используется ли индекс?
Когда бы я ни обсуждал обслуживание индексов, и в частности фрагментацию, я всегда подчёркиваю: «Прежде чем что-либо делать с фрагментацией, убедитесь, что индекс используется».
Если индекс используется не очень активно, но при этом имеет очень низкую плотность страниц (много свободного места на страницах индекса), то он будет занимать гораздо больше дискового пространства, чем мог бы, и, возможно, его стоит уплотнить (с помощью перестроения или реорганизации), чтобы вернуть это дисковое пространство. Однако обычно нет особого смысла тратить ресурсы на устранение какой бы то ни было фрагментации, когда индекс не используется. Это особенно верно для тех, кто перестраивает все индексы каждую ночь или каждую неделю.
20.4.26
Чтение заголовков файлов SQL Server с помощью DBCC FILEHEADER
Недавно я глубоко погрузился в изучение дисковых структур SQL Server, и одно из моих любимых направлений — это перечитывание серии статей Пола Рэндала (Paul Randal) о страницах заголовков файлов. Если вы её не читали, сделайте это прямо сейчас. В ней рассказывается о том, что такое страницы заголовков файлов, что они содержат и что происходит при их повреждении. Эта статья развивает эту концепцию. Я буду использовать DBCC FILEHEADER для чтения заголовка каждого файла пользовательской базы данных на сервере и отвечу на вопрос, который возникает чаще, чем можно подумать: можно ли определить, какие файлы принадлежат одной базе данных, исключительно по заголовку файла, без обращения к sys.databases?
Короткий ответ — да, и поле, которое делает это возможным, называется BindingId. Давайте разбираться.
19.4.26
"Все" мифы о резервном копировании
Пришло время грандиозного финала!
Хотя было весело развенчивать все эти мифы, это было немного напряжённо — каждый день находить интересный и полезный миф для разоблачения.
В завершение я представляю вам 30 мифов о резервном копировании — по одному на каждый день апреля. Вчера вечером я сел писать эту статью и не добрал несколько мифов, поэтому обратился за помощью к великолепному сообществу SQL в Twitter — слишком много людей, чтобы перечислять (вы знаете, кто вы) — я благодарю вас!
Я очень надеюсь, что вам понравилась эта серия, и что множество мифов и заблуждений были развеяны раз и навсегда — я знаю, что многие из вас используют эти объяснения в качестве аргументов против сторонних поставщиков, разработчиков и других администраторов баз данных, которые настаивают на неправильных практиках.
Итак, поехали, последний выпуск…
17.4.26
Мифы о модели восстановления BULK_LOGGED
Модель восстановления BULK_LOGGED продолжает сбивать людей с толку…
Накопительный пакет обновлений CU4 для SQL Server 2025 - KB5081495
Описание: KB5081495
Скачать: SQLServer2025-KB5081495-x64.exe
Дата выпуска: 16 апреля 2026 г.
SQL Server 2025 — Версия: 17.0.4035.5
16.4.26
Представления производительности в реальном времени, которые упрощают устранение неполадок
Запрос, который вчера выполнялся за 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
