В предыдущей статье обсуждалась функция ROW_NUMBER. Сейчас же мы рассмотрим другие функции ранжирования: RANK, DENSE_RANK и NTILE. Начнем с RANK и DENSE_RANK. Эти функции по функциональности и реализации аналогичны ROW_NUMBER. Разница в том, что ROW_NUMBER присваивает уникальное (возрастающее) значение каждой строке без учета связей в значениях ORDER BY, а функции RANK и DENSE_RANK присваивают одно и то же значение строкам, имеющим одинаковое значение ORDER BY. Разница между функциями RANK и DENSE_RANK заключается в том, как значения присваиваются строкам. Проще всего проиллюстрировать разницу между всеми этими функциями на простом примере:

Эта статья о том, что нового появилось в SQL Server Management Studio 20 (SSMS), и является второй из серии статей на эту тему. Первую статью можно почитать тут: Upcoming changes for SQL Server Management Studio (SSMS) — Part 1.Заключительной статьёй в серии является: Upcoming changes for SQL Server Management Studio (SSMS) — Part 3. SSMS 20 может удивить Вас сразу после установки, когда вдруг обнаружится что по умолчанию предполагается шифрованное соединение SSMS с сервером баз данных. На то, чтобы помочь пользователям SSMS справится с этой проблемой и добиться лучшей защиты соединения с помощью новых механизмов шифрования SQL Server 2022, как раз и направлена эта статья.

Четыре функции ранжирования: ROW_NUMBER, RANK, DENSE_RANK и NTILE появились в SQL Server 2005 и отличаются от обычных скалярных функций тем, что результат, который они выдают для строки, зависит от других строк выборки. От агрегатных функций они отличаются тем, что возвращают только одну строку для каждой строки на входе, т. е. они не объединяют набор строк в одну. В этой статье мы рассмотрим ROW_NUMBER — самую простую из всех функций ранжирования.

В предыдущей статье Внутренняя оптимизация операций изменения для индексов было рассказано о том, что планы запроса для UPDATE состоят из двух частей: курсора чтения, который выбирает строки, которые необходимо изменить, и курсора записи, который и выполняет изменения. SQL Server использует такую логику изменения, следуя которой курсоры чтения и записи в плане с UPDATE выполняются двумя отдельными шагами или фазами. Другими словами, фактическое изменение в строке не должно влиять на выбор строк изменения. С этим связана описанная ниже проблема, для преодоления которой нужно обеспечить такую работу курсора записи в плане с UPDATE, чтобы он не влиял на курсор чтения, эта проблема известна под названием «Halloween Protection». Такое имя она получила поскольку была обнаружена исследователями IBM более 30 лет назад в Хэллоуин.

В нескольких предыдущих статьях обсуждалось, как в SQL Server реализована агрегация, были рассмотрены операторы агрегирования потока и хеш-агрегат. Я также использовал хеш-агрегат в качестве примера в статье Введение в распараллеливание исполнения запроса. В этой статье мы рассмотрим частичную агрегацию. Частичная агрегация — это метод, который SQL Server использует для оптимизации параллельной агрегации. Прежде чем начать, я хочу отметить, что рассуждения о частичной агрегацию можно найти в книге Inside Microsoft SQL Server 2005 : Query Tuning and Optimization (см. страницу 187 внизу).

Одним из наиболее важных применений CTE являются рекурсивные запросы, для которых CTE является фактически единственным средством реализации. Как отмечалось в предыдущей статье, в Books Online есть несколько примеров использования CTE, включая и рекурсивный CTE. Тут мы будем использовать эти примеры из Books Online, используя один из ранних образов базы данных AdventureWorks.

Рекурсивные CTE все сделаны по одному шаблону. Тело CTE представляет собой запрос с UNION ALL, который объединяет один или несколько подзапросов называемых закреплёнными элементами, которые заполняют набор результатов. Кроме закреплённых элементов есть один или несколько рекурсивных подзапросов, называемых рекурсивными элементами, которые возвращают оставшуюся часть результирующего набора. Эти рекурсивные подзапросы ссылаются на сам рекурсивный CTE. Получается, у нас есть один или несколько закреплённых подзапросов и один или несколько рекурсивных подзапросов, объединенных UNION ALL. 

Common Table Expressions (CTE) или обобщенное табличное выражение, впервые появилось в версии SQL Server 2005, и это простой способ разбить сложный запрос T-SQL на несколько запросов, что придаёт больше гибкости и управляемости. CTE во многом очень похожи на представления. В отличие от представления, которое можно создать один раз и потом использовать в других запросах, CTE привязан только к одному запросу. В Books Online есть несколько отличных примеров CTE, включая и рекурсивные CTE. Вместо того, чтобы продемонстрировать их устройство на своих примерах, в этой статье будут использоваться примеры из Books Online. Чтобы попробовать эти примеры у себя, используйте один из ранних образов базы данных AdventureWorks.

В двух последних статьях приводились примеры агрегации WITH ROLLUP и WITH CUBE. В SQL Server 2008 появился новый, более мощный синтаксис, совместимый с ANSI SQL 2006. В этой статье будет рассказано об этих изменениях.

Популярная среди администраторов баз данных SQL Server Management Studio (SSMS) для подключения к серверам баз данных (по версию 18.12.1 включительно) использовала System.Data.Sqlclient (SDS). Новая версия SQL Server теперь поставляется с библиотеками Microsoft.Data.Sqlclient (MDS). Пакет Microsoft.Data.SqlClient теперь доступен на NuGet и становится основным способом доступа к данным для SQL Server. Этот пакет поддерживает как .NET Core, так и .NET Framework. Создание нового SqlClient в новом пространстве имен позволяет старому System.Data.SqlClient и новому Microsoft.Data.SqlClient жить бок о бок, хотя это и не происходит автоматически.

В предыдущей статье говорилось о том как  работает агрегат WITH ROLLUP. В этой статье мы рассмотрим, как реализована агрегация WITH CUBE. Как и предложение WITH ROLLUP, предложение WITH CUBE позволяет просчитать несколько «уровней» агрегации в одном операторе. Разницу между двумя этими агрегатами давайте рассмотрим на примере. Мы будем использовать те же вымышленные данные о продажах, что и в прошлый раз.

SQL Server поддерживает работу с данными типа JSON, и имеет для этого необходимый функционал, в который входит функция ISJSON, для проверки, соответствует ли значение типу JSON. Она вернет 0, если это не правильный JSON, и 1, если JSON правильный. Если JSON содержит недопустимые данные, функция помогает это обнаружить.

Новая опция WAIT_AT_LOW_PRIORITY в команде DBCC SHRINKDATABASE предоставляет возможность снизить конкуренцию за блокировки во время сжатия базы или файла, заставляя сжатие пережидать окончание других операций на сервере, блокирующих сжатие. Это похоже на опцию WAIT_AT_LOW_PRIORITY для онлайн операций с индексами, но с некоторыми отличиями.

Технология Intel® QuickAssist (Intel QAT) в SQL Server 2022 призвана обеспечить аппаратное ускорение и возможности разгрузки процессоров от функций сжатия и распаковки резервных копий баз данных. Использование этой технологии даёт заметное снижение нагрузки на процессоры, времени создания резервных копий, а также уменьшает занимаемое под хранение копий место.

В SQL Server 2022 интегрированы возможности сжатия/распаковки с помощью библиотеки QATzip и связанной с ней библиотеки Intel Intelligent Storage Acceleration Library (ISA-L). Intel ISA-L устанавливается вместе с QATzip, и наличие их является необходимым условием для включения аппаратного ускорения Intel QAT на уровне экземпляра.

QATzip в настоящее время поддерживает передачу нагрузки резервного копирования на мощности периферийного аппаратного устройства в виде адаптера PCIe, либо на встроенный чипсет, а если этого нет, может обеспечивать программное сжатие по тем же алгоритмам.

В новой версии SSRS мы проделали значительную работу по обеспечению лучшего уровня доступности, и добавили новые возможности, которые включают в себя:

• Расширенную поддержку Windows Narrator¹ для новых клиентских операционных систем Windows и Windows Server.

• Улучшения в безопасности.

• Улучшения производительности браузера с помощью Angular.

• Исправлены баги, ухудшавшие доступность.

• Поддержка каталога сервера отчетов для экземпляров SQL Server 2022².

•  Повышена надежность.

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

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

Сканирование буферного пула — это распространённая внутренняя операция, потенциально требующая перебора миллионов буферов. Например, экземпляр SQL Server с пространством буфера в 1 ТБ требует просмотра всего буферного пула с перебором больше 130 миллионов буферов. Это справедливо для любой редакции SQL Server, независимо от использования буферного пространства, поскольку, чтобы найти буферы определенной базы данных, просмотр буферного пула всегда перебирает весь массив дескрипторов буферов.

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

В SQL Server 2022 появилась замечательная возможность\функция, которая называется: Parameter Sensitive Plan Optimization (оптимизация плана с учетом параметров, для краткости - PSP). Как следует из названия, её задача обеспечить производительность параметризованных запросов. Появилась возможность создания несколько планов исполнения для параметризованного запроса, каждый из которых оптимизирован для разных значений параметров. Это позволяет оптимизатору SQL Server выбирать наилучший план выполнения для определенных значений параметров, используемых при исполнении конкретного запроса.

Когда я впервые узнал о том, что SQL Server 2022 будет поддерживать мгновенную инициализацию файлов журнала транзакций, я был заинтригован. Когда позже выяснилось, что это относится только к   автоматическому приращению и только с размером не больше 64 МБ, интрига несколько потеряла свой «блеск». Из-за этих ограничений я скептически отнесся к тому, что новая стратегия сможет заменить сложившуюся практику автоматического увеличения файлов журналов на 1 ГБ — по крайней мере, с тех пор, как SSD и другие современные хранилища получили достаточное распространение.

Но поигравшись с этим новшеством, я проникся.

Это новая концепция обеспечения идентичности ограниченного набора системных объектов и сущностей, которой до этого очень недоставало. Администраторам баз данных приходилось «вручную» синхронизировать логины, задания агента, планы обслуживания и множество других системных сущностей, которые описывались в таблицах системных баз данных master и msdb. Теперь появился способ возложить это на SQL Server 2022, но ждать этой возможности нам пришлось 10 лет…

Резервное копирование и восстановление из объектного хранилища S3 — это новая функция, появившаяся с выпуском SQL Server 2022. Резервное копирование или восстановление можно делать в S3, расположенное локально или в облаке.