SQL Server Archiтектура (объяснение)

Примечания со стола настройки/установки:

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

Что такое TDS?

Теперь, когда мы знаем, что существует три типа клиент-сервера Architecture, давайте взглянем на TDS:

• TDS означает поток табличных данных.
• Все три протокола используют пакеты TDS. TDS инкапсулируется в сетевые пакеты. Это позволяет передавать данные с клиентского компьютера на серверный компьютер.
• TDS был впервые разработан компанией Sybase и сейчас принадлежит Microsoft

Реляционный движок

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

Как изображено на Archiструктурная схема есть 3 основных компонента реляционной машины. Изучим компоненты подробно:

CMD-парсер

Данные, полученные от уровня протокола, затем передаются в реляционный механизм. «CMD-парсер» — это первый компонент реляционного механизма, который получает данные запроса. Основная задача CMD Parser — проверить запрос на наличие Синтаксическая и семантическая ошибка. Наконец, это генерирует дерево запросов. Давайте обсудим подробно.

Синтаксическая проверка:

• Как и любой другой язык программирования, MS SQL также имеет предопределенный набор ключевых слов. Кроме того, SQL Server имеет собственную грамматику, которую понимает SQL-сервер.
• SELECT, INSERT, UPDATE и многие другие входят в предопределенные списки ключевых слов MS SQL.
• CMD Parser выполняет синтаксическую проверку. Если вводимые пользователем данные не соответствуют этим правилам синтаксиса или грамматики языка, это возвращает ошибку.

Пример: Допустим, россиянин зашёл в японский ресторан. Он заказывает фаст-фуд на русском языке. К сожалению, официант понимает только японский. Какой результат будет наиболее очевидным?

Ответ: официант не может дальше обрабатывать заказ.

Не должно быть никаких отклонений в грамматике или языке, который принимает SQL-сервер. Если они есть, SQL-сервер не сможет их обработать и, следовательно, вернет сообщение об ошибке.

Мы узнаем больше о запросах MS SQL в следующих руководствах. Тем не менее, рассмотрим ниже основной синтаксис запроса:

SELECT * from <TABLE_NAME>;

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

SELECR * from <TABLE_NAME>

Обратите внимание, что вместо «SELECT» пользователь набрал «SELECR».

Результат: Анализатор CMD проанализирует этот оператор и выдаст сообщение об ошибке. Поскольку «SELECR» не соответствует заранее определенному названию ключевого слова и грамматике. Здесь CMD Parser ожидал «SELECT».

Семантическая проверка:

• Это выполняется нормализ.
• В своей простейшей форме он проверяет, существуют ли в схеме имя столбца и имя запрашиваемой таблицы. И если он существует, привяжите его к Query. Это также известно как Переплет.
• Сложность возрастает, когда пользовательские запросы содержат VIEW. Нормализатор выполняет замену с помощью внутренне сохраненного определения представления и многое другое.

Давайте поймем это с помощью приведенного ниже примера –

SELECT * from USER_ID

Результат: Синтаксический анализатор CMD проанализирует этот оператор для семантической проверки. Анализатор выдаст сообщение об ошибке, поскольку Normalizer не найдет запрошенную таблицу (USER_ID), поскольку она не существует.

Создать дерево запросов:

• На этом этапе создается другое дерево выполнения, в котором можно выполнить запрос.
• Обратите внимание, что все разные деревья имеют одинаковый желаемый результат.

Оптимизатор

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

Обратите внимание, что не все запросы оптимизированы. Оптимизация выполняется для команд DML (язык модификации данных), таких как SELECT, INSERT, DELETE и UPDATE. Такие запросы сначала маркируются, а затем отправляются оптимизатору. Команды DDL, такие как CREATE и ALTER, не оптимизированы, а вместо этого компилируются во внутреннюю форму. Стоимость запроса рассчитывается на основе таких факторов, как загрузка ЦП, использование памяти и потребности ввода-вывода.

Задача оптимизатора – найти самый дешевый, но не лучший и экономически эффективный план реализации.

Прежде чем мы перейдем к более техническим деталям Оптимизатора, рассмотрим ниже пример из реальной жизни:

Это критически важно для анализа и выбора наиболее эффективных ключевых слов для улучшения рейтинга вашего сайта.

Допустим, вы хотите открыть счет в онлайн-банке. Вы уже знаете об одном банке, в котором открытие счета занимает максимум 2 дня. Но у вас также есть список из 20 других банков, который может занять или не занять менее 2 дней. Вы можете начать сотрудничать с этими банками, чтобы определить, какие банки занимают менее 2 дней. Теперь вы можете не найти банк, что займет менее 2-х дней, и дополнительно потеряно время из-за самой поисковой активности. Лучше было бы открыть счет в самом первом банке.

Вывод: Гораздо важнее сделать разумный выбор. Точнее, выберите, какой вариант лучший, а не самый дешевый.

Аналогично, МС SQL Optimizer работает на основе встроенных исчерпывающих/эвристических алгоритмов. Цель состоит в том, чтобы минимизировать время выполнения запроса. Все алгоритмы оптимизатора уместность Microsoft и секрет. Несмотря на то, что, ниже приведены шаги высокого уровня, выполняемые оптимизатором MS SQL. Поиск оптимизации состоит из трех этапов, как показано на диаграмме ниже:

Фаза 0: Поиск тривиального плана:

• Это также известно как Этап предварительной оптимизации.
• В некоторых случаях может быть только один практический и работоспособный план, известный как тривиальный план. Нет необходимости создавать оптимизированный план. Причина в том, что больший поиск приведет к обнаружению того же плана выполнения во время выполнения. Это также с дополнительными затратами на поиск оптимизированного плана, который вообще не требовался.
• Если Тривиальный план не найден, то 1^st Фаза начинается.

Этап 1: Поиск планов обработки транзакций

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

Этап 2: Параллельная обработка и оптимизация.

• Если ни одна из вышеперечисленных стратегий не работает, оптимизатор ищет возможности параллельной обработки. Это зависит от возможностей обработки и конфигурации Машины.
• Если это по-прежнему невозможно, начинается заключительный этап оптимизации. Теперь конечная цель оптимизации — найти все другие возможные варианты выполнения запроса наилучшим образом. Заключительный этап оптимизации Algorithms Microsoft Приличие.

Исполнитель запросов

Вызовы исполнителя запросов Метод доступа. Он предоставляет план выполнения логики выборки данных, необходимой для выполнения. Как только данные получены из Storage Engine, результат публикуется на уровне протокола. Наконец, данные отправляются конечному пользователю.

Механизм хранения

Работа Storage Engine заключается в хранении данных в системе хранения, такой как Disk или SAN, и извлечении данных при необходимости. Прежде чем мы углубимся в механизм хранения, давайте посмотрим, как данные хранятся в База данных и тип доступных файлов.

Файл данных и объем:

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

Обслуживание объекта осуществляется через экстенты. На странице есть раздел, называемый заголовком страницы, размером 96 байт, содержащий метаданные о странице, такие как тип страницы, номер страницы, размер используемого пространства, размер свободного пространства и указатель на следующую и предыдущую страницы. , и т. д.

Типы файлов

1. Основной файл

• Каждая база данных содержит один первичный файл.
• Здесь хранятся все важные данные, связанные с таблицами, представлениями, триггерами и т. д.
• Расширение есть.МДФ обычно, но может иметь любое расширение.

2. Вторичный файл

• База данных может содержать или не содержать несколько вторичных файлов.
• Это необязательно и содержит данные, специфичные для пользователя.
• Расширение есть.NDF обычно, но может иметь любое расширение.

3. Журнальный файл

• Также известен как журналы опережающей записи.
• Расширение есть.LDF
• Используется для управления транзакциями.
• Это используется для восстановления после любых нежелательных экземпляров. Выполните важную задачу по откату к незафиксированным транзакциям.

Storage Engine состоит из 3 компонентов; давайте рассмотрим их подробно.

Метод доступа

Он действует как интерфейс между исполнителем запроса и Buffer Менеджер/Журналы транзакций.

Сам метод доступа не выполняет никакого выполнения.

Первое действие — определить, является ли запрос:

1. Выбрать оператор (DDL)
2. Оператор без выбора (DDL и DML)

В зависимости от результата метод доступа выполняет следующие шаги:

1. Если запрос DDL, SELECT, запрос передается Buffer Менеджер для дальнейшей обработки.
2. И если запрос, если DDL, оператор NON-SELECT, запрос передается диспетчеру транзакций. В основном это включает в себя оператор UPDATE.

Buffer Менеджер

Buffer менеджер управляет основными функциями модулей ниже:

• Кэш плана
• Анализ данных: Buffer кэш и хранилище данных
• Грязная страница

Мы научимся Плану, Buffer и Кэш данных в этом разделе. Мы рассмотрим «Грязные страницы» в разделе «Транзакции».

Кэш плана

• Существующий план запроса: Диспетчер буферов проверяет, имеется ли план выполнения в сохраненном кэше планов. Если да, то используется кеш плана запроса и связанный с ним кеш данных.
• План кэширования при первом использовании: Откуда берется существующий кэш плана? Если план выполнения первого запроса запускается и является сложным, имеет смысл сохранить его в кэше плана. Это обеспечит более быструю доступность, когда SQL-сервер в следующий раз получит тот же запрос. Таким образом, это не что иное, как сам запрос, в котором хранится выполнение плана, если он запускается впервые.

Анализ данных: Buffer кэш и хранилище данных

Buffer Менеджер обеспечивает доступ к необходимым данным. Ниже возможны два подхода в зависимости от того, существуют ли данные в кэше данных или нет:

Buffer Кэш – мягкий анализ:

Buffer Менеджер ищет данные в Buffer в Кэше данных. Если они присутствуют, то эти данные используются исполнителем запросов. Это повышает производительность, поскольку количество операций ввода-вывода уменьшается при извлечении данных из кэша по сравнению с получением данных из хранилища данных.

Хранение данных – жесткий анализ:

Если данные отсутствуют в Buffer Менеджер, чем требуется. Поиск данных осуществляется в хранилище данных. If также сохраняет данные в кэше данных для будущего использования.

Грязная страница

Он хранится как логика обработки диспетчера транзакций. Подробно мы узнаем в разделе «Диспетчер транзакций».

Менеджер транзакций

Диспетчер транзакций вызывается, когда метод доступа определяет, что запрос не является оператором выбора.

Диспетчер журналов

• Менеджер журналов отслеживает все обновления, выполненные в системе, через журналы транзакций.
• Журналы имеют Регистрирует порядковый номер с идентификатором транзакции и записью изменения данных..
• Это используется для отслеживания Подтверждение транзакции и откат транзакции.

Менеджер блокировки

• Во время транзакции связанные данные в хранилище данных находятся в состоянии блокировки. Этот процесс обрабатывается Lock Manager.
• Этот процесс обеспечивает согласованность и изоляция данных. Также известны как свойства ACID.

Процесс исполнения

• Диспетчер журналов начинает регистрацию, а диспетчер блокировок блокирует связанные данные.
• Копия данных хранится в Buffer кэш.
• Копия данных, которые должны быть обновлены, сохраняется в буфере журнала, а все события обновляют данные в буфере данных.
• Страницы, на которых хранятся данные, также известны как Грязные страницы.
• Контрольная точка и журнал упреждающей записи: Этот процесс запускается и помечает все страницы с «Грязных страниц» на диск, но страница остается в кеше. Частота примерно 1 запуск в минуту. Но страница сначала помещается на страницу данных файла журнала из Buffer бревно. Это известно как Запись вперед.
• Ленивый писатель: Грязная страница может остаться в памяти. Когда SQL-сервер обнаруживает огромную нагрузку и Buffer память нужна для новой транзакции, она освобождает Dirty Pages из кеша. Он действует на ЛРУ – Последний раз использовался алгоритм очистки страницы из пула буферов на диск.

Резюме

• Три типа клиент-сервера ArchiСуществуют следующие технологии: 1) Общая память 2) TCP/IP 3) Именованные каналы
• TDS, разработанный Sybase и ныне принадлежащий Microsoft, — это пакет, инкапсулированный в сетевые пакеты для передачи данных с клиентского компьютера на серверный компьютер.
• Реляционный движок содержит три основных компонента:CMD-парсер: Это отвечает за синтаксическую и семантическую ошибку и, наконец, создает дерево запросов.Оптимизатор: Роль оптимизатора состоит в том, чтобы найти самый дешевый, а не самый лучший и экономически эффективный план выполнения.

  Исполнитель запроса: Исполнитель запроса вызывает метод доступа и предоставляет план выполнения логики выборки данных, необходимой для выполнения.

• Существует три типа файлов: первичный файл, вторичный файл и файлы журнала.
• Механизм хранения: имеет следующие важные компоненты.Метод доступа: Этот компонент определяет, является ли запрос оператором выбора или невыбора. Вызывает Buffer и Менеджер по трансферам соответственно.Buffer Менеджер: Buffer Менеджер управляет основными функциями Plan Cache, Data Parsing и Dirty Page.

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