Как работают JSON-индексы в SQL Server

Автор: Brent Ozar, Database Animations: How SQL Server’s JSON Indexes Work

По многочисленным просьбам в SQL Server 2025 добавили JSON-индексы. Вы можете съесть торт возможности хранить практически не имеющие схемы JSON-блобы как часть каждой строки и при этом получить его, быстро запрашивая конкретные значения.

Ещё больше ЗОЖ для журнала транзакций

Автор: Paul Randal, Trimming More Transaction Log Fat

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

Программа похудения для журнала транзакций

Автор: Paul Randal, Trimming the Transaction Log Fat

Для многих рабочих нагрузках SQL Server, особенно OLTP, журнал транзакций базы данных может быть узким местом, увеличивающим время завершения транзакции. Большинство людей предполагают, что реальным узким местом является подсистема ввода-вывода, которая не справляется с объёмом журнала транзакций, генерируемого рабочей нагрузкой.

Проблемы конфигурации журнала транзакций

Автор: Paul Randal, Transaction Log Configuration Issues

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

Примечание переводчика: начиная с SQL Server 2022 описываемое в этой статье поведение журнала транзакций претерпело значительное изменение.

Soft NUMA, потоки завершения ввода-вывода, рабочие процессы Lazy Writer и узлы памяти - как это работает

Автор: mssql-support, How It Works: Soft NUMA, I/O Completion Thread, Lazy Writer Workers and Memory Nodes

Похоже, существует некоторая семантическая путаница в описании SOFT NUMA в документации Books Online. Область путаницы — это раздел SQL Server 2008 Books Online, показанный ниже.

NUMA и soft-NUMA в SQL Server: Получение дополнительных потоков ввода-вывода

Автор: Sarjen Haque, NUMA and soft-NUMA in SQL Server: To get additional I/O threads

Производительность может быть значительно улучшена, если ядро SQL Server обнаруживает физические узлы NUMA в системе Windows. Наряду с аппаратным NUMA, Microsoft также представила архитектуру soft-NUMA (программный NUMA) для создания дополнительных виртуальных узлов NUMA внутри SQL OS. Начиная с SQL Server 2016 (13.x), если ядро базы данных обнаруживает более восьми «физических ядер на узел NUMA» или более восьми «сокетов», узлы soft-NUMA создаются автоматически. Создание узлов soft-NUMA позволяет ядру базы данных SQL Server создавать больше потоков ввода-вывода для повышения производительности требовательных транзакционных рабочих нагрузок SQL Server.

Убивают ли задержки ввода-вывода вашу производительность?

Автор: Paul Randal, Are I/O latencies killing your performance?

В этой статье я объясняю некоторые методы исследования и снижения задержек ввода-вывода для tempdb и журнала транзакций, которые могут серьёзно препятствовать производительности вашей рабочей нагрузки.

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

Что происходит с данными и журналом при сбросах в tempdb

Автор: Paul Randal, Understanding data vs log usage for spills in tempdb

В списке рассылки SQL MCM (в котором участвуют все действующие инструкторы MCM) было обсуждение, где пытались понять огромное несоответствие между использованием файлов данных tempdb и файлов журнала. Я объяснил ответ и решил поделиться им со всеми вами.

Асинхронная репликация снимков из пода ActiveCluster на ещё одну систему хранения

Автор: Anthony Nocentino, Asynchronous Replication of Snapshots from an ActiveCluster Pod to a Third Array

Я восстанавливал свою трёхсайтовую демонстрационную лабораторию SQL Server и столкнулся с тем, чего давно хотел. Если вы когда-либо проектировали среду SQL Server на ActiveCluster, вам знаком этот сценарий: два FlashArray, работающие с синхронно реплицируемым модулем (pod) для нулевой точки восстановления (RPO) между сайтами, и третья система хранения где-то ещё для более длительного хранения и копии для аварийного восстановления. Проблема была в том, что вы не могли получить данные на эту третью систему хранения напрямую из пода Группы защиты внутри растянутого пода просто не могли иметь целью систему хранения.

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

В этой статье я покажу, как настроить это «от начала до конца» с помощью Pure Storage PowerShell SDK2, чтобы вы могли автоматизировать этот процесс. Поехали.

Разница между сжатием строк и сжатием страниц

Автор: Brent Ozar, Database Animations: The Difference Between Row Compression and Page Compression

В чём разница между сжатием строк (row compression) и сжатием страниц (page compression) в SQL Server, и когда имеет смысл применять каждое из них?

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

Чтобы увидеть это более подробно, давайте запустим одну из моих Database Animations.

Управление кешем планов SQL Server: диагностика и решение проблем

Кеш планов SQL Server — это критически важный компонент, который хранит планы выполнения запросов для повторного использования. Однако неправильное использование этого механизма может привести к серьезным проблемам производительности. В этой статье мы рассмотрим:

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

Фантомы в журнале транзакций

Автор: Martyn Jones, A Better Fire Alarm Is Still a Fire

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

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

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

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

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

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

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

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

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

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

Диагностика конкуренции за 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.

Как происходят сбросы (spills) данных и журнала в tempdb

Автор: Paul Randal, Understanding data vs log usage for spills in tempdb

Сегодня утром я заметил обсуждение в списке рассылки SQL MCM (в котором участвуют все оригинальные инструкторы MCM), где пытались понять причину огромного расхождения между использованием файлов данных и файлов журнала tempdb. Я объяснил ответ и подумал, что поделюсь им и с вами.

Код для оценки потенциальной экономии пространства ключа кластеризации для каждой таблицы

Автор: Paul Randal, Code to list potential cluster key space savings per table

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

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

Вы можете модифицировать код по своему усмотрению. И я продолжаю использовать sp_msforeachdb, потому что это самый быстрый способ для меня написать код для вас, и это продолжает раздражать моего хорошего друга Аарона Бертрана (Aaron Bertrand) :-)

Наслаждайтесь!

Page Life Expectancy — это не то, что вы думаете…

Автор: Paul Randal, Page Life Expectancy isn’t what you think…

Существует много споров о счётчике производительности Buffer Manager — Page Life Expectancy, в основном вокруг того, что люди продолжают цитировать 300 в качестве порога для начала беспокойства о проблеме (что в наши дни является полной ерундой). Это слишком низкое значение, чтобы быть точкой, на которой стоит начинать беспокоиться, если ваш PLE падает и остаётся на этом уровне. Джонатан предложил лучшее число, основанное на размере вашего буферного пула — см. нижнюю часть его статьи здесь.

Но не поэтому я пишу сегодня: я хочу объяснить, почему в настоящее время Page Life Expectancy в большинстве случаев не даёт вам полезной информации.

Проблемы производительности из-за неэффективного использования памяти буферного пула

Автор: Paul Randal, Performance issues from wasted buffer pool memory

В апреле я запустил опрос, в котором просил вас прислать информацию о ваших буферных пулах — сколько памяти используется для страниц файлов данных и какая часть этой памяти хранит пустое пространство. Я получил данные с 1394 серверов по всему миру — спасибо!

Причина, по которой меня это интересует и должна интересовать вас, заключается в том, что память — один из важнейших ресурсов, используемых SQL Server. Если у вас недостаточно памяти, ваша рабочая нагрузка будет страдать, потому что:

• Вы будете выполнять больше операций чтения ввода-вывода, поскольку большая часть рабочей нагрузки не может поместиться в буферном пуле.
• Вы будете выполнять больше операций записи ввода-вывода, так как «ленивому писателю» (lazywriter) придётся вытеснять грязные страницы из буферного пула.
• Вы можете столкнуться с ожиданиями RESOURCE_SEMAPHORE, потому что запросы не могут получить необходимые им назначения памяти для выполнения запросов.
• Вы можете вызвать чрезмерное количество перекомпиляций планов, если кэш планов слишком ограничен.
• И целый ряд других проблем.

Одной из проблем с памятью, которую Кимберли подробно обсуждала в прошлом году (и подробно обучает этому на наших курсах по настройке производительности), является раздувание кэша однократно используемых планов (single-use plan cache bloat), когда большая часть кэша планов заполнена планами, которые используются один раз и никогда больше не пригодятся. Вы можете прочитать об этом в трёх постах в её категории Plan Cache, а также о том, как выявить раздувание кэша планов и что с этим можно сделать.

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