MS SQL Server дело тонкое...: Engine

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

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

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

Дальше »

13.7.26

Избыточное и недостаточное индексирование — насколько всё плохо на самом деле?

Автор: Paul Randal, Over and under indexing – how bad is it out there?

Как-то я запустил опрос, в котором предложил выполнить код для получения сводного списка количества таблиц на вашем сервере с различным числом некластерных индексов. Я получил результаты с более чем 1000 серверов по всему миру — огромное спасибо всем, кто прислал мне данные!

Победители:

Наибольшее количество некластерных индексов на одном кластерном индексе: 1032
Наибольшее количество некластерных индексов на одной куче: 148
Наибольшее количество кластерных индексов с нулевым количеством некластерных индексов на одном сервере: 185237
Наибольшее количество куч с нулевым количеством некластерных индексов на одном сервере: 88042

Вау!

Теперь перейдём к некоторым деталям…

Дальше »

12.7.26

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, Capturing wait stats for a single operation

Эта статья о настройке производительности, которая давно была в моём списке задач. Анализ статистики ожиданий — отличный способ изучить симптомы проблем с производительностью (см. мой каталог Wait Stats для получения дополнительной информации), но использование DMV sys.dm_os_wait_stats показывает всё, что происходит на сервере. Если вы хотите увидеть, какие ожидания возникают из-за одного запроса или операции в рабочей системе (например, влияние подсказок MAXDOP на количество и продолжительность ожиданий CXPACKET для запроса), то использование DMV обычно нецелесообразно — вам пришлось бы очистить статистику ожиданий и убедиться, что в системе не выполняется ничего, кроме исследуемого запроса/операции. Наиболее правильный способ сделать это — использовать расширенные события (Extended Events).

Дальше »

11.7.26

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

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

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

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

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

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

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

Дальше »

9.7.26

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

Автор: Hugo Kornelis, Storage structures 5 – XML indexes;

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

Дальше »

8.7.26

Ожидания SOS_SCHEDULER_YIELD и спин-блокировка LOCK_HASH

Автор: Paul Randal, SOS_SCHEDULER_YIELD waits and the LOCK_HASH spinlock

В этой статье я хотел бы показать пример возникновения ожиданий SOS_SCHEDULER_YIELD и того, как может показаться, что причиной является спин-блокировка.

Первоначально я опубликовал эту статью, а затем обсудил его с моим хорошим другом Бобом Уордом (Bob Ward) из службы поддержки продуктов, который усомнился в моих выводах, основываясь на своём опыте (спасибо, Боб!). После более глубокого исследования я обнаружил, что моя первоначальная версия была неверной, поэтому это исправленная версия.

Дальше »

7.7.26

Продвинутая настройка производительности SQL Server

Автор: Paul Randal, Advanced SQL Server performance tuning

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

Обычно вы или они будете использовать четыре динамических административных представления (DMV), которые дают всё более продвинутую информацию о происходящем для диагностики производительности:

sys.dm_os_wait_stats
sys.dm_os_waiting_tasks
sys.dm_os_latch_stats
sys.dm_os_spinlock_stats (этот вообще не документирован и упоминается лишь в нескольких местах в Интернете)

В этой статье я немного объясню эти DMV, уделив основное внимание защёлкам (кратким блокировкам) и спин-блокировкам.

Дальше »

6.7.26

Как исследовать задержки подсистемы ввода-вывода изнутри SQL Server

Автор: Paul Randal, How to examine IO subsystem latencies from within SQL Server

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

Дальше »

5.7.26

Оптимизация запросов: выражения в предложении WHERE, не допускающие поиска по индексу

Автор: Paul Randal, Adventures in query tuning: non-seekable WHERE clause expressions

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

Я подготовлю тестовый пример, чтобы показать, что я имею в виду.

Дальше »

4.7.26

Отслеживание тяжёлых запросов с помощью расширенных событий

Автор: Paul Randal, Tracking expensive queries with extended events in SQL 2008

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

Дальше »

MS SQL Server дело тонкое...

15.7.26

Исправление безопасности для SQL Server 2025 CU6 - KB5101346

Исправление безопасности для SQL Server 2025 GDR - KB5102333

Исправление безопасности для SQL Server 2022 CU25 - KB5101347

Исправление безопасности для SQL Server 2022 GDR - KB5102334

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

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

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

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

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

14.7.26

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

13.7.26

Избыточное и недостаточное индексирование — насколько всё плохо на самом деле?

12.7.26

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

Статистика ожиданий для одной операции

11.7.26

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

9.7.26

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

8.7.26

Ожидания SOS_SCHEDULER_YIELD и спин-блокировка LOCK_HASH

7.7.26

Продвинутая настройка производительности SQL Server

6.7.26

Как исследовать задержки подсистемы ввода-вывода изнутри SQL Server

5.7.26

Оптимизация запросов: выражения в предложении WHERE, не допускающие поиска по индексу

4.7.26

Отслеживание тяжёлых запросов с помощью расширенных событий

Архив блога

Ярлыки

www.sql-ex.ru