Выявление запросов с ожиданиями SOS_SCHEDULER_YIELD

Автор: Paul Randal, Identifying queries with SOS_SCHEDULER_YIELD waits

Одна из проблем с типом ожидания SOS_SCHEDULER_YIELD заключается в том, что это на самом деле не тип ожидания. Когда возникает этот тип ожидания, это происходит потому, что поток исчерпал свой 4-миллисекундный квант планирования и добровольно уступил ЦП, перейдя непосредственно в конец очереди выполнения (Runnable Queue) для планировщика, минуя список ожидания (Waiter List). Однако ожидание должно быть зарегистрировано, когда поток покидает процессор, поэтому используется SOS_SCHEDULER_YIELD.

Советы и хитрости для высокой производительности FILESTREAM

Автор: Paul Randal, High-performance FILESTREAM tips and tricks

У меня было много вопросов о производительности FILESTREAM и о том, как заставить NTFS хорошо масштабироваться. Я только что закончил писать 30-страничный технический документ о FILESTREAM для команды SQL Server, который должен быть опубликован до конференции PASS 2008 в ноябре. Хотя мой технический документ не совсем о производительности, в нём есть длинный раздел о настройке системы для достижения высокой производительности FILESTREAM. В этой статье я хочу дать список рекомендаций, которые помогут вам добиться хорошей производительности. Все они более подробно описаны в техническом документе.

Могут ли ключи кластерного индекса с типом 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'?»

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

Разочарование от обобщений

Автор: Paul Randal, The frustration of sweeping generalizations – follow on from Search Engine Q&A #12

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

Некоторые примеры вопросов, которые порождают обобщения:

• Следует ли создавать кластерные индексы для всех таблиц? (Известный спор о кластерных индексах, как его любит называть Кимберли.)
• Следует ли перестраивать или реорганизовать индексы для устранения фрагментации?
• Какое решение высокой доступности следует использовать?

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

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

Описание: KB5093421

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

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

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

Журнал транзакций SQL Server. Часть 4: записи журнала

Автор: Paul Randal, The SQL Server Transaction Log, Part 4: Log Records

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

Следует ли создавать несколько файлов для пользовательской базы данных на многопроцессорном сервере?

Автор: Paul Randal, Search Engine Q&A #12: Should you create multiple files for a user DB on a multi-core box?

На сайте SQLServerCentral.com развернулась очень интересная дискуссия о том, стоит ли создавать несколько файлов для пользовательской базы данных, потому что на сервере несколько ЦП. Я написал пару длинных ответов в ходе дискуссии и хотел продублировать их здесь, так как считаю, что это представляет широкий интерес.

Горячее добавление ЦП и маска привязки

Автор: Paul Randal, SQL Server 2008: Hot-Add CPU (and affinity masks)

Короткая заметка сегодня, так как я готовлюсь к выступлению на собрании пользовательской группы SQL Server в Тихоокеанском Северо-Западе сегодня вечером в кампусе Microsoft в Редмонде.

SQL Server 2005 представил концепцию горячего добавления памяти (hot-add memory) для динамической обработки рабочей нагрузки. SQL Server 2008 расширяет эти возможности, добавляя также горячее добавление ЦП (hot-add CPU). Начиная с SQL Server 2025 (17.x), функция горячего добавления ЦП не рекомендуется и планируется удалить в будущей версии SQL Server. «Горячее добавление» означает возможность установить ЦП в работающую машину и затем перенастроить SQL Server для использования этого ЦП ONLINE (т.е. без какого-либо простоя приложения).

И вот однажды RCSI сделал результаты запросов более точными

Автор: Brent Ozar, And Then There Was The Time RCSI Actually Made Query Results More Accurate

Обычно, когда я рассказываю людям об оптимистичных уровнях изоляции SQL Server — Read Committed Snapshot Isolation (RCSI) и Snapshot Isolation (SI) — мне приходится произносить небольшую речь о том, что им нужно тестировать свои запросы, потому что результаты могут измениться.

Однако недавно я работал с клиентом, который получал неверные результаты запросов при использовании пессимистичного уровня изоляции по умолчанию — и мы переключились на RCSI, чтобы это исправить! Я не буду объяснять здесь RCSI или SI — используйте ссылку выше для ознакомления с основами — вместо этого я сосредоточусь на демонстрационном скрипте, который я написал, чтобы показать проблему, с которой они столкнулись, и то, как RCSI её решил.

Новое в SQL Server 2025: функции кодирования и декодирования Base64

Автор: Leonard Lobel, Base64 Encoding and Decoding in SQL Server 2025 and Azure SQL Database

SQL Server 2025 добавляет встроенную поддержку кодирования и декодирования Base64 с помощью двух T-SQL-функций: BASE64_ENCODE и BASE64_DECODE. Эти функции значительно упрощают преобразование двоичных данных в дружественные к тексту представления и обратное преобразование строк в двоичные данные, когда это необходимо.

Это полезно во многих повседневных сценариях: встраивание двоичного содержимого в JSON, создание URL данных для HTML, передача двоичных полезных нагрузок через текстовые протоколы и создание безопасных для URL токенов. Раньше разработчикам часто приходилось полагаться на XML-трюки, код на стороне приложения, CLR-функции или собственную логику преобразования. Теперь эта функциональность доступна непосредственно в T-SQL.

Важно: Base64 — это формат кодирования, а не механизм шифрования. Он делает двоичные данные дружественными к тексту, но не обеспечивает безопасность или скрытие основных данных.

Как влияет сжатие резервных копий на загрузку процессоров

Автор: Paul Randal, SQL Server 2008: Backup Compression CPU Cost

Я давно обещал написать о встроенном сжатии резервных копий (Backup Compression). Для этой статьи я расширил базу данных AdventureWorks до 322 МБ (случайный размер, но достаточно большой, чтобы получить приемлемое время выполнения на моём сервере). Я использовал системный монитор (System Monitor) для измерения времени ЦП в пользовательском режиме (%user-mode CPU time), а также пропускной способности резервного копирования и восстановления для сжатой и несжатой операций резервного копирования, а затем и восстановления.