Автор: 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, показанный ниже.
Автор: 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 для агрегации данных. Вот они.
Автор: Paul Randal, Understanding data vs log usage for spills in tempdb
В списке рассылки SQL MCM (в котором участвуют все действующие инструкторы MCM) было обсуждение, где пытались понять огромное несоответствие между использованием файлов данных tempdb и файлов журнала. Я объяснил ответ и решил поделиться им со всеми вами.
Я восстанавливал свою трёхсайтовую демонстрационную лабораторию SQL Server и столкнулся с тем, чего давно хотел. Если вы когда-либо проектировали среду SQL Server на ActiveCluster, вам знаком этот сценарий: два FlashArray, работающие с синхронно реплицируемым модулем (pod) для нулевой точки восстановления (RPO) между сайтами, и третья система хранения где-то ещё для более длительного хранения и копии для аварийного восстановления. Проблема была в том, что вы не могли получить данные на эту третью систему хранения напрямую из пода Группы защиты внутри растянутого пода просто не могли иметь целью систему хранения.
Это изменилось, и это возможно уже дольше, чем многие из нас осознают. Вы можете создать группу защиты внутри модуля ActiveCluster, добавить третий FlashArray в качестве цели и асинхронно реплицировать на него снимки по расписанию. Ваши синхронно реплицируемые данные получают третью копию, и вам не нужно создавать параллельный набор томов вне пода, а затем клонировать их в эти тома, чтобы добиться этого.
В этой статье я покажу, как настроить это «от начала до конца» с помощью Pure Storage PowerShell SDK2, чтобы вы могли автоматизировать этот процесс. Поехали.
В чём разница между сжатием строк (row compression) и сжатием страниц (page compression) в SQL Server, и когда имеет смысл применять каждое из них?
Чтобы увидеть это более подробно, давайте запустим одну из моих Database Animations.
Кеш планов SQL Server — это критически важный компонент, который хранит планы выполнения запросов для повторного использования. Однако неправильное использование этого механизма может привести к серьезным проблемам производительности. В этой статье мы рассмотрим:
В прошлой статье было показано, как включить и отключить задачу очистки фантомных записей (ghost cleanup) и как фантомные записи представлены на странице данных. В этой статье мы переходим к тому, как процесс удаления, включая пометку фантомных записей, регистрируется в журнале транзакций.
Со временем таблицы — как и наша талия — имеют свойство увеличиваться. Мы постоянно добавляем всё новые и новые столбцы, один за другим, чтобы удовлетворить потребности приложений. Добавить «ещё один столбец» проще, чем выносить что-то в отдельную таблицу.
Когда вы работаете лишь с несколькими строками за раз, например, при вставке, обновлении, удалении или выборке одной строки по идентификатору, накладные расходы на дополнительные столбцы незначительны. SQL Server может нырнуть в эту одну строку и просто извлечь её, и поскольку она всё равно находится на одной странице размером 8 КБ, количество столбцов не влияет на операции с одной строкой.
Однако, когда вам нужно прочитать много строк, чем больше строк вы читаете, тем сильнее дополнительные столбцы влияют на накладные расходы операции.
Пришло время продолжить серию статей о внутреннем устройстве структур хранения. Я уже рассмотрел более стандартные типы хранения в частях, посвящённых дисковому строчному хранению, columnstore индексам, оптимизированным для памяти структурам и оптимизированным для памяти columnstore, а в прошлом выпуске этой серии я начал рассматривать специализированные структуры хранения, изучив XML-индексы.
Microsoft представила ограниченную поддержку JSON в SQL Server 2016. Однако только в SQL Server 2025 появились собственный тип данных json и JSON-индексы. Итак, давайте посмотрим, как они работают «под капотом».
Автор: Paul Randal, The Accidental DBA (Day 27 of 30): Troubleshooting: Tempdb Contention
Одна из самых распространённых проблем производительности, существующих в экземплярах SQL Server по всему миру, известна как конкуренция за tempdb. Что это означает? Конкуренция за tempdb относится к узкому месту для потоков, пытающихся получить доступ к страницам распределения, находящимся в памяти; это не связано с вводом-выводом.
Автор: 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.
Автор: 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) :-)
Наслаждайтесь!
Автор: 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. Если у вас недостаточно памяти, ваша рабочая нагрузка будет страдать, потому что:
RESOURCE_SEMAPHORE, потому что запросы не могут получить необходимые им назначения памяти для выполнения запросов.Одной из проблем с памятью, которую Кимберли подробно обсуждала в прошлом году (и подробно обучает этому на наших курсах по настройке производительности), является раздувание кэша однократно используемых планов (single-use plan cache bloat), когда большая часть кэша планов заполнена планами, которые используются один раз и никогда больше не пригодятся. Вы можете прочитать об этом в трёх постах в её категории Plan Cache, а также о том, как выявить раздувание кэша планов и что с этим можно сделать.
Эта статья посвящена памяти, которую буферный пул использует для хранения страниц файлов данных, и тому, насколько эффективно она используется.
После рассмотрения дискового строчного хранения, индексов columnstore, оптимизированных для памяти структур и оптимизированных для памяти columnstore, пришло время обратить внимание на структуры хранения, которые используются только для определённых типов данных. Первой «жертвой» станет XML-индекс.
Автор: Paul Randal, SOS_SCHEDULER_YIELD waits and the LOCK_HASH spinlock
В этой статье я хотел бы показать пример возникновения ожиданий SOS_SCHEDULER_YIELD и того, как может показаться, что причиной является спин-блокировка.
Первоначально я опубликовал эту статью, а затем обсудил его с моим хорошим другом Бобом Уордом (Bob Ward) из службы поддержки продуктов, который усомнился в моих выводах, основываясь на своём опыте (спасибо, Боб!). После более глубокого исследования я обнаружил, что моя первоначальная версия была неверной, поэтому это исправленная версия.
Автор: Paul Randal, How to examine IO subsystem latencies from within SQL Server
За последние несколько месяцев я читал лекции на курсах и конференциях о том, как получить представление SQL Server о подсистеме ввода-вывода и какие задержки она испытывает, так что пришло время написать об этом в блоге, чтобы помочь всем остальным.
Автор: Paul Randal, Important considerations when performance tuning
Что, по вашему мнению, является самым важным аспектом при настройке производительности, если бы пришлось выбрать что-то одно? Суть в том, что в общем случае ответ всегда «зависит», но некоторые вещи оказываются главной проблемой чаще, чем другие. Давайте пройдёмся по каждому возможному ответу и посмотрим, как сильно они могут повлиять на производительность, если что-то не так. Это ни в коем случае не исчерпывающий список того, что может вызвать проблемы, а просто мои размышления в конце воскресенья, как обычно.