MS SQL Server - це архітектура клієнт-сервер. Процес MS SQL Server починається з того, що клієнтська програма надсилає запит. SQL Server приймає, обробляє та відповідає на запит з обробленими даними. Давайте детально обговоримо всю архітектуру, показану нижче:
Як показано на діаграмі нижче, в архітектурі SQL Server є три основні компоненти:
- Рівень протоколу
- Реляційний двигун
- Механізм зберігання
Давайте детально обговоримо всі три вищезазначені основні модулі. У цьому підручнику ви дізнаєтесь.
- Рівень протоколу - SNI
- Спільна пам’ять
- TCP / IP
- Іменовані труби
- Що таке TDS?
- Реляційний двигун
- Парсер CMD
- Оптимізатор
- Виконавець запитів
- Механізм зберігання
- Типи файлів
- Метод доступу
- Менеджер буферів
- Кеш плану
- Розбір даних: кешування буфера та зберігання даних
- Менеджер транзакцій
Рівень протоколу - SNI
MS SQL SERVER PROTOCOL LAYER підтримує 3 типи архітектури клієнтського сервера. Ми почнемо з " Архітектури трьох типів клієнтських серверів", яку підтримує MS SQL Server.
Спільна пам’ять
Давайте переглянемо сценарій розмови рано вранці.
МАМА і ТОМ - Тут Том та його мама були в одному логічному місці, тобто вдома. Том зміг попросити кави, а мама подала її гарячою.
MS SQL SERVER - Тут сервер MS SQL забезпечує ПРОТОКОЛ СПІЛЬНОЇ ПАМ’ЯТІ . Тут КЛІЄНТ і сервер MS SQL працюють на одній машині. Обидва можуть спілкуватися через протокол спільної пам'яті.
Аналогія: Давайте відобразимо сутності у вищезазначених двох сценаріях. Ми можемо легко зіставити Тома з клієнтом, маму з сервером SQL, будинок для машини та вербальну комунікацію з протоколом спільної пам'яті.
З бюро конфігурації та встановлення:
Для підключення до локальної БД - у SQL Management Studio може бути параметр "Ім'я сервера"
"."
"localhost"
"127.0.0.1"
"Машина \ Екземпляр"
TCP / IP
А тепер подумайте ввечері, у Тома вечірка. Він хоче замовити каву у відомій кав’ярні. Кав'ярня знаходиться в 10 км від його дому.
Тут Том і Старбак знаходяться в різному фізичному розташуванні. Том вдома, а Starbucks на жвавому ринку. Вони спілкуються через стільникову мережу. Подібним чином, MS SQL SERVER надає можливість взаємодії через протокол TCP / IP, де КЛІЄНТ і MS SQL Server віддалені один від одного і встановлені на окремій машині.
Аналогія: Давайте відобразимо сутності у вищезазначених двох сценаріях. Ми можемо легко зіставити Тома з клієнтом, Starbuck із сервером SQL, домашньою / ринковою мережею для віддаленого розташування і, нарешті, стільникову мережу за протоколом TCP / IP.
Примітки зі столу конфігурації / інсталяції:
- У SQL Management Studio - для підключення через TCP \ IP параметр "Ім'я сервера" має бути "Machine \ Instance of the server".
- SQL-сервер використовує порт 1433 в TCP / IP.
Іменовані труби
Тепер нарешті вночі Том хотів випити світло-зеленого чаю, який її сусідка Сьєрра дуже добре готувала.
Тут Том і його сусід , Сьєрра, знаходяться в одному фізичному місці, будучи сусідами один одного. Вони спілкуються через внутрішню мережу. Подібним чином, MS SQL SERVER надає можливість взаємодії за допомогою протоколу Named Pipe . Тут КЛІЄНТ і MS SQL SERVER з'єднані через локальну мережу .
Аналогія: Давайте відобразимо сутності у вищезазначених двох сценаріях. Ми можемо легко зіставити Тома з клієнтом, Сьєрру з сервером SQL, сусід з локальною мережею та, нарешті, внутрішню мережу з протоколом Named Pipe.
Примітки зі столу конфігурації / інсталяції:
- Для підключення через іменовану трубу. Цей параметр вимкнено за замовчуванням, і його має вмикати диспетчер конфігурацій SQL.
Що таке TDS?
Тепер, коли ми знаємо, що існує три типи архітектури клієнт-сервер, ми можемо поглянути на TDS:
- TDS розшифровується як Табличний потік даних.
- Усі 3 протоколи використовують пакети TDS. TDS інкапсульовано в мережеві пакети. Це дозволяє передавати дані з клієнтської машини на серверну машину.
- TDS вперше був розроблений Sybase, і зараз він належить Microsoft
Реляційний двигун
Реляційний движок також відомий як процесор запитів. У ньому є компоненти SQL Server, які визначають, що саме потрібно робити запиту і як це можна зробити найкраще. Він відповідає за виконання запитів користувачів, запитуючи дані з механізму зберігання та обробляючи результати, які повертаються.
Як зображено на Архітектурній схемі, є 3 основні компоненти Реляційного двигуна. Давайте детально вивчимо компоненти:
Парсер CMD
Дані, отримані від рівня протоколу, потім передаються в Relational Engine. "CMD Parser" - це перший компонент Relational Engine, який отримує дані запиту. Основною роботою CMD Parser є перевірка запиту на наявність синтаксичної та семантичної помилок. Нарешті, він генерує дерево запитів . Давайте обговоримо детально.
Синтаксична перевірка:
- Як і будь-яка інша мова програмування, MS SQL також має заздалегідь визначений набір ключових слів. Крім того, SQL Server має власну граматику, яку розуміє SQL-сервер.
- SELECT, INSERT, UPDATE та багато інших належать до заздалегідь визначених списків ключових слів MS SQL.
- CMD Parser виконує синтаксичну перевірку. Якщо користувальницькі дані не відповідають цим мовним синтаксисом або граматичним правилам, це повертає помилку.
Приклад: Скажімо, росіянин ходив до японського ресторану. Він замовляє фаст-фуд російською мовою. На жаль, офіціант розуміє лише японську мову. Який би був найбільш очевидний результат?
Відповідь така - офіціант не може обробити замовлення далі.
У граматиці чи мові, яку приймає сервер SQL, не повинно бути відхилень. Якщо такі є, сервер SQL не може їх обробити, і, отже, поверне повідомлення про помилку.
Про запити MS SQL ми дізнаємось більше в наступних навчальних посібниках. Тим не менш, розглянемо нижче основний синтаксис запиту як
SELECT * from;
Тепер, щоб зрозуміти, що робить синтаксис, скажіть, якщо користувач запускає основний запит, як показано нижче:
SELECR * from
Зверніть увагу, що замість 'SELECT' користувач набрав "SELECR."
Результат: Синтаксичний аналізатор CMD проаналізує це твердження та видасть повідомлення про помилку. Оскільки "SELECR" не відповідає визначеним назвам ключових слів та граматиці. Тут CMD Parser очікував "SELECT".
Семантична перевірка:
- Це виконує Normalizer .
- У найпростішій формі він перевіряє, чи існує в Схемі ім’я стовпця, ім’я таблиці, яке запитується. А якщо воно існує, прив’яжіть його до Query. Це також відомо як Зв'язування .
- Складність зростає, коли запити користувачів містять VIEW. Normalizer виконує заміну за допомогою внутрішньо збереженого визначення подання та багато іншого.
Давайте зрозуміємо це за допомогою наведеного нижче прикладу -
SELECT * from USER_ID
Результат: Синтаксичний аналізатор CMD проаналізує це твердження для семантичної перевірки. Синтаксичний аналізатор видасть повідомлення про помилку, оскільки Normalizer не знайде запитану таблицю (USER_ID), оскільки вона не існує.
Створити дерево запитів:
- Цей крок генерує різне дерево виконання, в якому можна виконати запит.
- Зверніть увагу, що всі різні дерева мають однаковий бажаний результат.
Оптимізатор
Робота оптимізатора полягає у створенні плану виконання запиту користувача. Це план, який визначатиме спосіб виконання запиту користувача.
Зверніть увагу, що не всі запити оптимізовані. Оптимізація виконується для команд DML (Data Modification Language), таких як SELECT, INSERT, DELETE та UPDATE. Такі запити спочатку позначаються, а потім надсилаються на оптимізатор. Команди DDL, такі як CREATE та ALTER, не оптимізовані, але замість цього вони компілюються у внутрішню форму. Вартість запиту розраховується на основі таких факторів, як використання центрального процесора, використання пам'яті та потреби вводу / виводу.
Роль оптимізатора полягає у пошуку найдешевшого, не найкращого, економічно ефективного плану виконання.
Перш ніж перейти до більш технічних деталей Оптимізатора, розглянемо нижче реальний приклад:
Приклад:
Скажімо, ви хочете відкрити банківський рахунок в Інтернеті. Ви вже знаєте про один банк, який займає максимум 2 дні для відкриття рахунку. Але у вас також є список з 20 інших банків, що може зайняти менше 2 днів. Ви можете почати взаємодію з цими банками, щоб визначити, яким банкам потрібно менше 2 днів. Зараз ви можете не знайти банк, який займає менше 2 днів, і додатковий час втрачається через саму пошукову діяльність. Краще було б відкрити рахунок у самому першому банку.
Висновок: Важливіше вибирати розумно. Точніше, виберіть, який варіант найкращий, а не найдешевший.
Подібним чином, MS SQL Optimizer працює над вбудованими вичерпними / евристичними алгоритмами. Мета - мінімізувати час виконання запиту. Всі алгоритми Оптимізатора є належністю Microsoft і секретом. Незважаючи на те , нижче наведені кроки високого рівня , що виконуються MS SQL Optimizer. Пошуки оптимізації проходять три етапи, як показано на діаграмі нижче:
Фаза 0: Пошук тривіального плану:
- Це також відомо як етап попередньої оптимізації .
- У деяких випадках може існувати лише один практичний, дієвий план, відомий як тривіальний план. Немає необхідності створювати оптимізований план. Причина полягає в тому, що пошук більше призведе до пошуку того самого плану виконання часу виконання. Це теж з додатковими витратами на пошук оптимізованого плану, які взагалі не потрібні.
- Якщо тривіального плану не знайдено, починається перша фаза.
Етап 1: Пошук планів обробки транзакцій
- Сюди входить пошук простого та складного плану .
- Простий пошук за планом: Дані минулих стовпців та індексів, задіяних у запиті, будуть використані для статистичного аналізу. Зазвичай це складається, але не обмежується одним показником на таблицю.
- І все ж, якщо простого плану не знайдено, шукається більш складний План. Він включає кілька індексів на таблицю.
Фаза 2: Паралельна обробка та оптимізація.
- Якщо жодна з наведених стратегій не працює, Optimizer шукає можливості паралельної обробки. Це залежить від можливостей обробки та конфігурації Машини.
- Якщо це все ще неможливо, то починається остаточна фаза оптимізації. Тепер остаточною метою оптимізації є пошук усіх інших можливих варіантів найкращого виконання запиту. Кінцева фаза оптимізації Алгоритми - це Microsoft Propriety.
Виконавець запитів
Виконавець запиту викликає метод доступу. Він надає план виконання логіки отримання даних, необхідної для виконання. Після отримання даних із Storage Engine результат опубліковується на рівні протоколу. Нарешті, дані надсилаються кінцевому користувачеві.
Механізм зберігання
Робота Storage Storage полягає у зберіганні даних у такій системі зберігання, як Disk або SAN, та за необхідності отримувати дані. Перш ніж глибоко заглибитися в механізм зберігання, давайте подивимось, як дані зберігаються в базі даних та тип доступних файлів.
Файл даних і обсяг:
Файл даних фізично зберігає дані у вигляді сторінок даних, причому кожна сторінка даних має розмір 8 КБ, утворюючи найменший блок зберігання в SQL Server. Ці сторінки даних логічно згруповані для формування екстентів. Жодному об’єкту не присвоєна сторінка в SQL Server.
Обслуговування об'єкта здійснюється за допомогою екстентів. Сторінка має розділ, названий заголовком сторінки, розміром 96 байт, що містить інформацію про метадані сторінки, наприклад, тип сторінки, номер сторінки, розмір використовуваного простору, розмір вільного простору та вказівник на наступну сторінку та попередню сторінку тощо
Типи файлів
- Первинний файл
- Кожна база даних містить один основний файл.
- Тут зберігаються всі важливі дані, що стосуються таблиць, подань, тригерів тощо.
- Розширення є. mdf, як правило, але може мати будь-яке розширення.
- Вторинний файл
- База даних може містити чи не містити кілька вторинних файлів.
- Це необов’язково і містить дані, що стосуються користувачів.
- Розширення є. ndf, як правило, але може мати будь-яке розширення.
- Файл журналу
- Також відомий як журнали запису вперед.
- Розширення є. ldf
- Використовується для управління транзакціями.
- Це використовується для відновлення від небажаних випадків. Виконайте важливе завдання відкату до незавершених транзакцій.
Storage Engine має 3 компоненти; давайте розглянемо їх докладно.
Метод доступу
Він виступає інтерфейсом між виконавцем запитів та диспетчером буферів / журналами транзакцій.
Сам метод доступу не виконує жодного виконання.
Перша дія - визначити, чи є запит:
- Виберіть виписку (DDL)
- Заява про невибір (DDL і DML)
Залежно від результату, метод доступу робить такі кроки:
- Якщо запитом є оператор DDL , SELECT, запит передається до диспетчера буферів для подальшої обробки.
- І якщо запит якщо оператор DDL, NON-SELECT , запит передається в Transaction Manager. Це переважно включає оператор UPDATE.
Менеджер буферів
Менеджер буферів керує основними функціями для модулів нижче:
- Кеш плану
- Розбір даних: кешування буфера та зберігання даних
- Брудна сторінка
У цьому розділі ми вивчимо кеш плану, буфера та даних. Ми охопимо Брудні сторінки в розділі Транзакції.
Кеш плану
- Існуючий план запитів: Менеджер буферів перевіряє, чи є план виконання у збереженому кеші плану. Якщо так, тоді використовується кеш плану запитів та пов'язаний з ним кеш даних.
- Перший план кешування: звідки береться існуючий кеш плану?
Якщо план виконання запиту, який вперше виконується, є складним, має сенс зберігати його в кеш-пам’яті Plane. Це забезпечить швидшу доступність, коли наступного разу SQL Server отримає той самий запит. Отже, це не що інше, як сам запит, яке виконання плану зберігається, якщо воно виконується вперше.
Розбір даних: кешування буфера та зберігання даних
Менеджер буферів надає доступ до необхідних даних. Можливі два підходи, залежно від того, чи існують дані в кеші даних:
Буферний кеш - м'який синтаксичний аналіз:
Менеджер буферів шукає дані в буфері в кеші даних. Якщо вони є, тоді ці Дані використовуються виконавцем запитів. Це покращує продуктивність, оскільки кількість операцій вводу-виводу зменшується під час отримання даних із кешу порівняно з отриманням даних із сховища даних.
Зберігання даних - жорсткий синтаксичний аналіз:
Якщо даних немає в диспетчері буферів, ніж потрібно, здійснюється пошук даних у сховищі даних. Якщо також зберігає дані в кеші даних для подальшого використання.
Брудна сторінка
Він зберігається як логіка обробки Transaction Manager. Ми детально дізнаємось у розділі Transaction Manager.
Менеджер транзакцій
Менеджер транзакцій викликається, коли метод доступу визначає, що Query є оператором Non-Select.
Менеджер журналів
- Log Manager веде облік усіх оновлень, здійснених у системі, через журнали в журналах транзакцій.
- Журнали мають порядковий номер журналу з ідентифікатором транзакції та записом модифікації даних .
- Це використовується для відстеження здійсненої транзакції та відкоту транзакції .
Менеджер блокування
- Під час транзакції пов'язані дані у сховищі даних перебувають у стані блокування. Цим процесом керує Lock Manager.
- Цей процес забезпечує узгодженість та ізоляцію даних . Також відомий як властивості кислоти.
Процес виконання
- Log Manager запускає журналювання, а Lock Manager блокує пов’язані дані.
- Копія даних зберігається в кеші буфера.
- Копія даних, яку слід оновити, зберігається в буфері журналу, а всі події оновлюють дані в буфері даних.
- Сторінки, на яких зберігаються дані, також відомі як брудні сторінки .
- Журнал контрольної точки та записування вперед: Цей процес запускається та позначає всю сторінку від брудних сторінок до диска, але сторінка залишається в кеші. Частота становить приблизно 1 запуск на хвилину, але сторінка спочатку переходить на сторінку даних файлу журналу з журналу буфера. Це відоме як запис журналу вперед.
- Ледачий письменник: Брудна сторінка може залишитися в пам'яті. Коли SQL-сервер спостерігає величезне навантаження і для нової транзакції потрібна буферна пам'ять, він звільняє брудні сторінки з кешу. Він працює на LRU - найменш нещодавно використаний алгоритм для очищення сторінки з буферного пулу на диск.
Короткий зміст:
- Існує три типи архітектури клієнтського сервера: 1) спільна пам’ять 2) TCP / IP 3) іменовані канали
- TDS, розроблений Sybase і в даний час належить Microsoft, - це пакет, який інкапсульований у мережеві пакети для передачі даних з клієнтської машини на серверну машину.
- Реляційний двигун містить три основні компоненти:
Синтаксичний аналізатор CMD: це відповідає за синтаксичну та семантичну помилки і, нарешті, генерує дерево запитів.
Оптимізатор: Роль оптимізатора полягає у пошуку найдешевшого, не найкращого, економічно ефективного плану виконання.
Виконавець запитів: Виконавець запиту викликає метод доступу та надає план виконання логіки отримання даних, необхідної для виконання.
- Існує три типи файлів: Первинний файл, Вторинний файл та Файли журналів.
- Механізм зберігання: має такі важливі компоненти
Метод доступу: Цей компонент визначає, чи є запит оператором Select або Non-Select. Відповідно викликає буфер та диспетчер передачі.
Менеджер буферів: Менеджер буферів керує основними функціями кешування плану, аналізу даних та брудної сторінки.
Менеджер транзакцій: Це менеджер, що не вибирає транзакції, за допомогою менеджерів журналів та блокувань. Крім того, сприяє важливому впровадженню журналів Write Ahead та Lezy Writers.