Работают ли многоядерные процессоры лучше, чем одноядерные?

Автор: Paul Randal, Search Engine Q&A #5: Do multi-core CPUs perform better than single-core CPUs?

Вот интересный вопрос, который прислал мне мой друг Стив Джонс из SQL Server Central — будет ли один процессор с двумя ядрами работать лучше, чем два одноядерных процессора? Оба варианта имеют два вычислительных ядра, но аппаратная архитектура разная — какой из них обеспечит лучшую производительность SQL Server? Что ж, однозначного ответа нет — всё зависит от многих факторов! Я обсуждал эту тему с Джеромом Халмансом, бывшим коллегой по команде Storage Engine в SQL Server, и с его разрешения я основываю эту статью на нашем обсуждении.

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

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

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

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

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

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

Ошибка в 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 и прошедшее время.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Мифы о модели восстановления BULK_LOGGED

Автор: Paul Randal, A SQL Server DBA myth a day: (28/30) BULK_LOGGED recovery model

Модель восстановления BULK_LOGGED продолжает сбивать людей с толку…

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

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

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

Исправление безопасности для 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

Исправление безопасности для SQL Server 2019 CU32 - KB5084816

Описание: KB5084816

Скачать: SQLServer2019-KB5084816-x64.exe

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

SQL Server 2019 — версия: 15.0.4465.1

Исправление безопасности для SQL Server 2017 CU31 - KB5084818

Описание: KB5084818

Скачать: SQLServer2017-KB5084818-x64.exe

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

SQL Server 2017 — версия: 14.0.3525.1

Миф об использовании BACKUP WITH CHECKSUM для замены DBCC CHECKDB

Автор: Paul Randal, A SQL Server DBA myth a day: (27/30) use BACKUP WITH CHECKSUM to replace DBCC CHECKDB

Сегодня короткая статья, так как я занят работой с клиентами и сортировкой заявок на выступления для SQL Connections!

Исправление безопасности для SQL Server 2016 SP3 - KB5084821

Описание: KB5084821

Скачать: SQLServer2016-KB5084821-x64.exe

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

SQL Server 2016 — версия: 13.0.6485.1

Миф про то, что вложенные транзакции реальны

Автор: Paul Randal, A SQL Server DBA myth a day: (26/30) nested transactions are real

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

Мифы о коэффициенте заполнения (fill factor)

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

Я выдохся после прошлой статьи с мифами о восстановлении, так что сегодня короткая статья, разоблачающая некоторые мифы о коэффициенте заполнения (fill factor), которые я развенчал ещё в SQL Server 2005 в Books Online.

Двадцать шесть мифов о восстановлении

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

Одна область, которую я ещё не затронул в этой серии, — это RESTORE (восстановление), и здесь существует тонна заблуждений (так много, на самом деле, что я не могу охватить их все в одной статье!). В одной статье было разоблачено 6 мифов о контрольных суммах страниц, а в другой — 5 мифов о FILESTREAM, так что сегодня мне нужно их превзойти.

Миф о том, что эскалация блокировок происходит сначала с уровня строки на уровень страницы, а затем с уровня страницы на уровень таблицы

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

Миф №23: эскалация блокировок происходит сначала с уровня строки на уровень страницы, а затем с уровня страницы на уровень таблицы.

ЛОЖЬ

Нет, никогда. Эскалация блокировок в SQL Server  всегда переходит непосредственно к блокировке таблицы.