По материалам статьи Craig Freedman: Stream Aggregate

Когда мы имеем дело с предложением GROUP BY, SQL Server для вычисления агрегатов использует два оператора. Один из этих операторов - агрегат потока, который, как Вы помните, был рассмотрен в предыдущей статье, и который используется для скалярных агрегатов. Другой оператор, это агрегат хэша (Hash Aggregate). В этой статье, я более подробно рассмотрю то, как работает агрегат потока.

По материалам статьи Craig Freedman: Aggregation

Агрегация относится к таким операциям, когда больший набор строк свёртывается в меньший. Типичные агрегатные функции - COUNT, MIN, MAX, SUM и AVG. SQL Server поддерживает также и другие агрегаты, типа STDEV и VAR.

Я собираюсь посвятить этой теме несколько статей. В этой статье, я сосредоточусь на "Скалярных Агрегатах". Скалярные агрегаты - запросы с агрегатными функциями в списке оператора SELECT и без предложения GROUP BY. Скалярные агрегаты всегда возвращают одну строку.

По материалам статьи Craig Freedman: Subqueries: ANDs and ORs

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

По материалам статьи Craig Freedman: Subqueries in CASE Expressions

В этой статье будет рассмотрено, как SQL Server обрабатывает подзапросы в выражении CASE. Кроме того, будут рассмотрены несколько экзотических возможностей соединений.

По материалам статьи Craig Freedman: Summary of Join Properties

Следующая таблица суммирует характеристики трех операторов соединения, которые были описаны в моих трех предшествующих статьях.

Когда Вы встречаете случай использования оператора Hash Join (хэш-соединение), это говорит о наличии тяжелого запроса. В отличие то соединения Nested Loops Join, которое хорошо для относительно маленьких наборов данных, и от соединения Merge Join, которое помогает при умеренных размерах наборов данных, хэш-соединение превосходит другие типы соединений при необходимости соединения огромных наборов данных. Хэш-соединения распараллеливается и масштабируется лучше любого другого соединения и сильно выигрывает при большой производительности информационных хранилищ (я вернусь к обсуждению параллельного выполнения запросов в следующей серии статей).

Хэш-соединение имеет много общего с соединением слиянием. Подобно соединению слиянием, для него требуются не менее одного предиката объединения по эквивалентности, оно поддерживает остаточные предикаты, а также все внешние соединения и полусоединения. В отличие от соединения слиянием, для него не требуется наличие упорядоченных входных потоков и для поддержки полного внешнего соединения требуется наличие предиката соединения по эквивалентности.

По материалам статьи Craig Freedman: Merge Join

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

Этот алгоритм в псевдокоде можно выразить следующим образом:

Эта статья посвящена физическому оператору соединения - соединению слиянием (Merge Join или MJ). В отличие от Nested Loops Join, которое поддерживает любые предикаты соединения, соединение слиянием требует существования не менее одного предиката соединения по эквивалентности. Кроме того, получаемые соединением слиянием данные должны быть отсортированы по ключу соединения. Например, если мы имеем предикат соединения "T1.a = T2.b", таблица T1 должна быть отсортирована по T1.a, а таблица T2 должна быть сортирована по T2.b.

По материалам статьи Craig Freedman: Nested Loops Join

SQL Server поддерживает три физические оператора соединений: соединение вложенных циклов, соединение слиянием и хэш-соединение. В этой статье я опишу соединение вложенных циклов - Nested Loops Join (или NL-соединение, для краткости).

По материалам статьи Craig Freedman: Introduction to Joins

Можно соединить две таблицы явно, перечислив обе таблицы в предложении FROM запроса. Также можно соединить две таблицы, используя для этого всё разнообразие подзапросов. Наконец, SQL Server во время оптимизации может добавить соединение в план запроса, преследуя свои цели.

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

Соединение (JOIN) - одна из самых важных операций, выполняемых реляционными системами управления базами данных (РСУБД). РСУБД используют соединения для того, чтобы сопоставить строки одной таблицы строкам другой таблицы. Например, соединения можно использовать для сопоставления продаж - клиентам или книг - авторам. Без соединений, имелись бы раздельные списки продаж и клиентов или книг и авторов, но невозможно было бы определить, какие клиенты что купили, или какой из авторов был заказан.

По материалам статьи Craig Freedman

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

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

С индексами по одному столбцу всё довольно просто. SQL Server может их использовать для самых простых сравнений, например, равенства и неравенства (больше чем, меньше чем, и т.д.). Более сложные выражения, такие как функции по столбцу и предикаты "LIKE" с символами подстановки, будут в таких случаях создавать трудности для использования поиска по индексу.

По материалам статьи Craig Freedman

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

По материалам статьи Craig Freedman: The Building Blocks of Query Execution

SQL Server декомпозирует запросы, преобразуя их в набор стандартных блоков-примитивов, которые принято называть операторами или итераторами. Каждый итератор служит для выполнения одной операции, например, просмотр (сканирование), изменение, фильтрация или соединение данных таблиц, а также соединение двух наборов данных. Всего известно несколько дюжин таких примитивных итераторов. Итераторы могут иметь одну или несколько дочерних записей и могут объединяться в деревья, которые принято называть планом исполнения запроса. Любая инструкция SQL выполняется по соответствующему плану запроса. Для одной инструкции на практике может существовать много правильных планов исполнения запроса. Оптимизатор запросов старается найти лучший (например, самым дешевый) план запроса для каждой инструкции.

По материалам статьи Craig Freedman: Semi-join Transformation

В предыдущих статьях я приводил примеры полу-соединений (semi-joins). Вспомним, что полу-соединение возвращает строку из таблицы, если для этой строки есть хотя бы одна совпадающая строка во второй таблице. Вот простой пример:

По материалам статьи из блога Craig Freedman: Parallel Nested Loops Join

SQL Server распараллеливает соединение вложенных циклов (Nested Loops Join), распределяя в случайном порядке строки внешней таблицы по потокам вложенных циклов. В данном случае, речь идёт о строках, которые поступают первыми, и мы их видим вверху, на графическом плане запроса. Например, если на входе соединения вложенных циклов имеется два потока, каждый поток получит приблизительно половину строк. Потоки проходятся по строкам внутренней таблицы соединения (то есть, по строкам, поданным во вторую очередь, мы их видим ниже в плане запроса), точно по такому же алгоритму, как это было бы реализовано в сценарии с последовательной обработкой строк. Таким образом, для каждой обрабатываемой потоком строки внешней таблицы, поток обеспечивает соединение своей внутренней таблицы, используя эту строку в качестве источника коррелированных параметров. Это позволяет потокам работать независимо друг от друга. При этом для внутренней таблицы соединения вложенных циклов SQL Server не добавляет операторы параллелизма и работу с ней не распараллеливает.

Перевод Ирины Наумовой

_{Эта статья была опубликована на SQL.RU Другие опубликованные там статьи на тему MS SQL Server можно найти в блоге https://mssqlforever.blogspot.com/ Telegram-канал блога тут: https://t.me/mssqlhelp}

По материалам статьи: «Resolving PAGELATCH Contention on Highly Concurrent INSERT Workloads».

Авторы: Thomas Kejser, Lindsey Allen, Arvind Rao и Michael Thomassy

Недавно, мы проводили лабораторные испытания в Microsoft Enterprise Engineering Center, при которых использовалась большая рабочая нагрузка, характерная для OLTP систем. Целью этой лабораторной работы было определить, что случится при увеличении числа процессоров с 64 до 128, при обслуживании Microsoft SQL Server интенсивной рабочей нагрузки (примечание: эта конфигурация была ориентирована на релиз Microsoft SQL Server 2008 R2). Рабочая нагрузка представляла собой хорошо распараллеленные операции вставки, направляемые в несколько больших таблиц.

Рабочая нагрузка масштабировалась до 128 процессорных ядер, но в статистике ожиданий было очень много кратких блокировок PAGELATCH_UP и PAGELATCH_EX. Средняя продолжительность ожидания была десятки миллисекунд, и таких ожиданий было очень много. Такое их количество оказалось для нас неожиданностью, ожидалось, что продолжительность не будет превышать несколько миллисекунд.

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

_{Эта статья была опубликована на SQL.RU Другие опубликованные там статьи на тему MS SQL Server можно найти в блоге https://mssqlforever.blogspot.com/ Telegram-канал блога тут: https://t.me/mssqlhelp}

По материалам технической статьи Майкрософт: A Case Study: Fast and Reliable Backup and Restore of a VLDB over the Network

^{Статья была опубликована рание на SQL.RU Публикуется повторно ввиду недоступности сайта.}

Автор: Томас Грохсер (Thomas H. Grohser)

При содействии: Линдсей Аллен (Lindsey Allen)

Техническая экспертиза статьи: Sanjay Mishra, Lubor Kollar, Stuart Ozer, Thomas Kejser, Juergen Thomas, James Podgorski, Burzin Patel

Перевод: Александр Гладченко,  Ирина Наумова

Дата издания: июнь 2009г.

Тематика статьи: SQL Server 2008

 Резюме: Размер базы данных непрерывно растёт, темп этого роста, а также её доступность и готовность фиксируется в соглашение о качестве сервиса - SLA. Одновременно с ростом повышается важность быстрого и надежного резервного копирования и планового восстановления в текущем окружении. Этот документ посвящён проблемам проектирования устойчивого резервного копирования и решений по восстановлению очень больших баз данных (VLDB). На реальном примере, в этой статье демонстрируется, как лучше всего использовать резервное копирование и возможности по восстановлению, которыми обладает SQL Server 2008, что должно помочь при создании планов резервного копирования и восстановления VLDB по сети.

По материалам статьи Джо Чанг (Joe Chang): I/O Queue Depth Strategy for Peak Performance (IO Queue Depth Strategy)

^{Статья была опубликована рание на SQL.RU Публикуется повторно ввиду недоступности сайта.}

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

Автор, наконец, нашёл время для тестирования массива твердотельных дисков (SSD), собирая в массивы от нескольких до 20 устройств, управляемых двумя контроллерами с 4x4 портами Serial Attached SCSI (SAS). Во время предварительных тестов, когда глубина очереди обращения к дискам была очень высокой, он наблюдал большую задержку обращения к дискам, которая во время проведения ряда операций для чтения превышала 100ms и достигала более 400ms для операций записи.

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

Опубликовано 23 февраля 2022 года
Автор статьи Gianluca Sartori

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

По материалам статьи Sean Gallardy «Demystifying Dumps: Non-Yielding Scheduler

23 августа 2021 г

Одним из наиболее распространенных случаев, приводящих к генерации дампа памяти в SQL Server, является «ступор» при выполнении задачи на планировщике: non-yielding scheduler (для краткости называемый NYS). Что же это значит? Почему он вызывает дамп памяти? Где можно найти что-нибудь, что можно исследовать для поиска источника ступора? Хорошие вопросы, давайте на них ответим.