16.5.25

Подробнее о неявных преобразованиях

Автор: Craig Freedman More on Implicit Conversions

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

DECLARE @a INT
DECLARE @b DATE
SET @a = @b

Msg 206, Level 16, State 2, Line 3
Operand type clash: date is incompatible with int

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

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

Описание: KB5054531

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

Дата выпуска: 15 мая 2025 г.

25.4.25

Неявные преобразования (Implicit Conversions)

Автор: Craig Freedman Implicit Conversions

В нескольких статьях я уже показывал, как явные преобразования могут приводить к ошибкам. В этой статье рассмотрим некоторые проблемы, связанные с неявными преобразованиями. SQL Server добавляет неявные преобразования, когда в одном выражении запроса используются колонки, переменные и/или параметры с разными (но совместимыми) типами данных. Например, если нужно сравнить колонки с типами INT и FLOAT, INT необходимо преобразовать в FLOAT. Если вы напишете "C_INT = C_FLOAT", SQL Server перепишет это выражение как "CONVERT (FLOAT, C_INT) = C_FLOAT".

21.4.25

Новое в SQL Server 2022: CDC Extended Events

Автор: Mukesh Kumar - MICROSOFT Monitoring CDC using Extended Events in SQL Server 2022

В этой статье очень подробно описывается, как максимально полно контролировать и оперативно устранять проблемы в работе и производительности Change Data Capture (CDC), если использовать сбор расширенных событий xEvents. За работой CDC можно наблюдать с помощью двух расширенных событий CDC, которые появились в SQL Server 2022:

  • repl_logscan_session
  • cdc_cleanup_job_status

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.