Показаны сообщения с ярлыком Engine. Показать все сообщения
Показаны сообщения с ярлыком Engine. Показать все сообщения

28.3.25

Maximum Row Size and Query Hints

Автор: Craig Freedman Maximum Row Size and Query Hints

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

CREATE TABLE T (A INT, B CHAR(8000), C CHAR(8000))

Msg 1701, Level 16, State 1, Line 1

Creating or altering table 'T' failed because the minimum row size would be 16011, including 7 bytes of internal overhead. This exceeds the maximum allowable table row size of 8060 bytes.

Какое же отношение ограничение размера записи имеет к подсказкам оптимизатору?

11.3.25

Index Rebuilds Make Even Less Sense with ADR & RCSI

Автор: Brent Ozar Index Rebuilds Make Even Less Sense with ADR & RCSI

Ускоренное восстановление базы данных (Accelerated Database Recovery - ADR) — это новая функция базы данных в SQL Server 2022, которая делает откат транзакций практически мгновенным. Без ADR при изменении записи SQL Server копирует старые значения в журнал транзакций и обновляет строку по месту. Если вы откатываете эту транзакцию, SQL Server должен извлечь старые значения из журнала транзакций, а затем применить их к записи на том же месте. Чем больше строк изменения затронули, тем больше времени займет эта транзакция. Когда у базы данных SQL Server включена ADR, в таблицу записывается новая версию записи, а старая версия остаётся на прежнем месте. Как вы догадываетесь, хранение нескольких версий строки внутри одной таблицы наверняка приведёт к проблемам с их хранением: размер нашей таблицы будет быстро увеличиваться. Однако проблема еще масштабнее, и она начинается с самого начала, когда мы ещё загружаем данные.

18.2.25

Подразумеваемые (Implied) предикаты

Автор: Craig Freedman Implied Predicates and Query Hints

В этой статье будут рассмотрены некоторые странности с предикатами в планах запросов. Рассмотрим следующую тривиальную схему и запрос:

CREATE TABLE T1 (A INT, B INT)

CREATE TABLE T2 (A INT, B INT)

 

SELECT *

FROM T1 INNER JOIN T2 ON T1.A = T2.A

WHERE T1.B = 0

OPTION (HASH JOIN)

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

  |--Hash Match(Inner Join, HASH:([T1].[A])=([T2].[A]), RESIDUAL:([T2].[A]=[T1].[A]))

       |--Table Scan(OBJECT:([T1]), WHERE:([T1].[B]=(0)))

       |--Table Scan(OBJECT:([T2]))

На самом деле, этот запрос получит такой план с подсказкой или без нее. Теперь давайте внесем небольшое изменение в предложение WHERE и посмотрим, что произойдет:

SELECT *

FROM T1 INNER JOIN T2 ON T1.A = T2.A

WHERE T1.A = 0

OPTION (HASH JOIN)

Теперь этот запрос выдает сообщение об ошибке:

Msg 8622, Level 16, State 1, Line 1

Query processor could not produce a query plan because of the hints defined in this query. Resubmit the query without specifying any hints and without using SET FORCEPLAN.

6.2.25

Накопительный пакет обновления 17 для SQL Server 2022 - KB5048038

SQL Server 2022 — Версия: 16.0.4175.1

Описание: KB5048038

Скачать: SQLServer2022-KB5048038-x64.exe

Дата выпуска: 16 января 2025 г.

Накопительный пакет обновления 30 для SQL Server 2019 - KB5046365

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

Описание: KB5049235 

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

Дата выпуска: 12 декабря 2024 г.

Накопительный пакет обновления 29 для SQL Server 2019 - KB5046365

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

Описание: KB5046365 

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

Дата выпуска: 31 октября 2024 г.

Исправлени безопасности для SQL Server: 2016 SP3; 2017 CU31; 2019 CU29; 2022 CU15

KB5046856. Описание обновления для системы безопасности для SQL Server 2016 с пакетом обновления 3 (SP3) Azure Connect Feature Pack: 12 ноября 2024 г.
Версия: 13.0.7050.2

KB5046858. Описание обновления для системы безопасности для SQL Server 2017 CU31: 12 ноября 2024 г.
Версия: 14.0.3485.1

KB5046860. Описание обновления для системы безопасности для SQL Server 2019 CU29: 12 ноября 2024 г.
Версия: 15.0.4410.1

KB5046862. Описание обновления для системы безопасности для SQL Server 2022 CU15: 12 ноября 2024 г.
Версия: 16.0.4155.4

Исправление безопасности для GDR SQL Server 2016/17/19/22 - 12 ноября 2024 г.

KB5046855. Описание обновления для системы безопасности для GDR SQL Server 2016 с пакетом обновления 3 (SP3): 12 ноября 2024 г.
Версия: 13.0.6455.2

KB5046857. Описание обновления для системы безопасности для GDR SQL Server 2017 г.: 12 ноября 2024 г.
Версия: 14.0.2070.1

KB5046859. Описание обновления для системы безопасности для GDR SQL Server 2019 г.: 12 ноября 2024 г.
Версия: 15.0.2130.3

KB5046861. Описание обновления для системы безопасности для GDR SQL Server 2022 г.: 12 ноября 2024 г.
Версия: 16.0.1135.2

Накопительный пакет обновления 16 для SQL Server 2022 - KB5048033

SQL Server 2022 — Версия: 16.0.4165.4

Описание: KB5048033

Скачать: SQLServer2022-KB5048038-x64.exe

Дата выпуска: 14 ноября 2024 г.

OPTIMIZED Nested Loops Joins

Автор: Craig Freedman OPTIMIZED Nested Loops Joins

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

3.2.25

Optimizing I/O Performance by Sorting – Part 2

Автор: Craig Freedman Optimizing I/O Performance by Sorting – Part 2

В предыдущей части мы рассмотрели, как SQL Server использует сортировку для преобразования случайных операций ввода-вывода в последовательные. В этой части давайте наглядно продемонстрируем, как такая сортировка может повлиять на производительность. Для проверки я буду использовать ту же базу данных размером 3 ГБ, которая была создана в первой части.

27.1.25

Новое в SQL Server 2022: Improved RCSI Ghost Cleanup

Автор: Paul White https://www.sql.kiwi/2024/12/improved-ghosts-2022/

Уровень изоляции моментального снимка с фиксированным чтением (Read Committed Snapshot Isolation, далее: RCSI) даёт много преимуществ. Главное из них в том, что читатели не будут блокировать писателей (и наоборот). Каждый оператор видит снимок данных на определенный момент времени (за исключением некоторых случаев, таких как использование non-inlined функций, которые оптимизатор не может развернуть внутри запроса). С другой стороны, появляются затраты на поддержание версий строк, необходимых для реализации RCSI.

Речь идет не только о том, чтобы убедиться, что база данных tempdb (или пользовательская база данных (если используется ADR - ACCELERATED_DATABASE_RECOVERY) достаточно велика и может справиться с дополнительной параллельной активностью:

  • Писатели, изменяющие (а иногда и добавляющие) данные, должны создавать версии строк.
  • Система должна уметь проверять и поддерживать компактность хранилища версий в фоновом режиме.
  • Читателям необходимо найти правильную для них версию каждой строки выборки.

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

26.12.24

Предикаты поиска

Автор: Craig Freedman Seek Predicates

Перед тем, как SQL Server приступит к поиску по индексу, он должен определить, являются ли ключи индекса подходящими для оценки предиката запроса.

Примеры полезности индексов

Автор: Craig Freedman Index Examples and Tradeoffs

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

23.12.24

Различия между sys.dm_db_index_usage_stats и sys.dm_db_index_operational_stats

Автор: Craig Freedman What is the difference between sys.dm_db_index_usage_stats and sys.dm_db_index_operational_stats?

В SQL Server есть два административных представления (DMV) - sys.dm_db_index_usage_stats и sys.dm_db_index_operational_stats - которые очень полезны для мониторинга использования индексов. Оба DMV выдают схожие статистические данные о количестве просмотров, поисков и изменений в индексах. Однако важно понимать разницу между ними.

2.12.24

Random Prefetching

Автор: Craig Freedman Random Prefetching

В предыдущей статье мы рассмотрели важность для повышения производительности асинхронного ввода-вывода и последовательного упреждающего чтения (sequential read ahead). В этой статье мы рассмотрим, как SQL Server использует случайную упреждающую (random prefetching) выборку. Давайте начнем с простого примера плана запроса, в котором много случайных операций ввода-вывода. Как и в предыдущей статье, все примеры используют базу данных TPC-H с коэффициентом масштабирования 1ГБ. Следующий запрос возвращает количество позиций, связанных с заказами, размещенным 15 марта 1998г.

26.11.24

Ещё одна «засада» на уровне изоляции Read Uncommitted

Автор: Craig Freedman Query Failure with Read Uncommitted

В предыдущих статьях были рассмотрены практически все уровни изоляции, за исключением Read Uncommitted или NOLOCK. Эта статья завершает серию обсуждением того, что может приключиться, если читать данные ещё не зафиксированных транзакций. О вреде NOLOCK написано уже немало. Например, вы могли об этом почитать у Любора Коллара (Lubor Kollar) из «SQL Server Development Customer Advisory Team» и в (ныне уже недоступном) блоге Тони Роджерсона (Tony Rogerson).