SQL Server Architectură (explicată)

Note de la biroul de configurare/instalare:

• Pentru conectare prin conductă numită. Această opțiune este dezactivată implicit și trebuie să fie activată de Managerul de configurare SQL.

Ce este TDS?

Acum că știm că există trei tipuri de Client-Server Architectura, permiteți-ne să aruncăm o privire asupra TDS:

• TDS înseamnă Tabular Data Stream.
• Toate cele 3 protocoale folosesc pachete TDS. TDS este încapsulat în pachete de rețea. Aceasta permite transferul de date de la computerul client la computerul server.
• TDS a fost dezvoltat pentru prima dată de Sybase și acum este deținut de Microsoft

Motor relațional

Motorul relațional este cunoscut și sub numele de Procesor de interogări. Are SQL Server componente care determină exact ce trebuie să facă o interogare și cum poate fi realizată cel mai bine. Este responsabil pentru executarea interogărilor utilizatorilor prin solicitarea datelor de la motorul de stocare și procesarea rezultatelor care sunt returnate.

După cum este descris în ArchiDiagrama tecturală există 3 componente majore al Motorului Relațional. Să studiem componentele în detaliu:

Analizor CMD

Datele odată primite de la Stratul de protocol sunt apoi transmise motorului relațional. „Analizator CMD” este prima componentă a motorului relațional care primește datele de interogare. Sarcina principală a CMD Parser este de a verifica interogarea pentru Eroare sintactică și semantică. În cele din urmă, acesta generează un arbore de interogări. Să discutăm în detaliu.

Verificare sintactică:

• Ca orice alt limbaj de programare, MS SQL are, de asemenea, setul predefinit de Cuvinte cheie. De asemenea, SQL Server are propria sa gramatică pe care SQL Server o înțelege.
• SELECT, INSERT, UPDATE și multe altele aparțin listelor de cuvinte cheie predefinite MS SQL.
• CMD Parser efectuează verificarea sintactică. Dacă introducerea utilizatorilor nu respectă aceste reguli gramaticale sau sintaxa limbii, aceasta returnează o eroare.

Exemplu: Să presupunem că un rus a mers la un restaurant japonez. El comandă fast-food în limba rusă. Din păcate, chelnerul înțelege doar japoneză. Care ar fi rezultatul cel mai evident?

Răspunsul este – chelnerul nu poate procesa comanda în continuare.

Nu ar trebui să existe nicio abatere în gramatică sau limbă acceptată de serverul SQL. Dacă există, serverul SQL nu îl poate procesa și, prin urmare, va returna un mesaj de eroare.

Vom afla mai multe despre interogarea MS SQL în tutorialele viitoare. Cu toate acestea, luați în considerare mai jos cea mai simplă sintaxă a interogării ca

SELECT * from <TABLE_NAME>;

Acum, pentru a obține percepția despre ceea ce face sintactica, spuneți dacă utilizatorul rulează interogarea de bază, după cum urmează:

SELECR * from <TABLE_NAME>

Rețineți că, în loc de „SELECT”, utilizatorul a tastat „SELECR”.

Rezultat: Analizorul CMD va analiza această declarație și va arunca mesajul de eroare. Deoarece „SELECR” nu urmează numele și gramatica predefinite ale cuvântului cheie. Aici CMD Parser se aștepta la „SELECT”.

Verificare semantică:

• Aceasta este realizată de Normalizator.
• În cea mai simplă formă, verifică dacă Numele coloanei, Numele tabelului interogat există în Schema. Și dacă există, legați-l la Query. Acest lucru este cunoscut și ca Obligatoriu.
• Complexitatea crește atunci când interogările utilizatorilor conțin VIEW. Normalizer efectuează înlocuirea cu definiția vizualizării stocate intern și multe altele.

Să înțelegem asta cu ajutorul exemplului de mai jos -

SELECT * from USER_ID

Rezultat: Analizorul CMD va analiza această declarație pentru verificarea semantică. Analizatorul va trimite un mesaj de eroare, deoarece Normalizer nu va găsi tabelul solicitat (USER_ID), deoarece nu există.

Creați arbore de interogări:

• Acest pas generează un arbore de execuție diferit în care poate fi rulată interogarea.
• Rețineți că, toți copacii diferiți au aceeași ieșire dorită.

Instrumentul de optimizare a

Lucrarea optimizatorului este de a crea un plan de execuție pentru interogarea utilizatorului. Acesta este planul care va determina modul în care va fi executată interogarea utilizatorului.

Rețineți că nu toate interogările sunt optimizate. Optimizarea se face pentru comenzile DML (Data Modification Language) precum SELECT, INSERT, DELETE și UPDATE. Astfel de interogări sunt mai întâi marcate, apoi trimise la optimizator. Comenzile DDL precum CREATE și ALTER nu sunt optimizate, dar sunt compilate într-o formă internă. Costul interogării este calculat pe baza unor factori precum utilizarea CPU, utilizarea memoriei și nevoile de intrare/ieșire.

Rolul optimizatorului este de a găsi cel mai ieftin, nu cel mai bun, plan de execuție rentabil.

Înainte de a trece la mai multe detalii tehnice despre Optimizer, luați în considerare exemplul din viața reală de mai jos:

Exemplu:

Să presupunem că doriți să deschideți un cont bancar online. Știți deja despre o bancă care are nevoie de maximum 2 zile pentru a deschide un cont. Dar, ai și o listă cu alte 20 de bănci, care poate dura sau nu mai puțin de 2 zile. Puteți începe să interacționați cu aceste bănci pentru a determina care bănci durează mai puțin de 2 zile. Acum, este posibil să nu găsiți o bancă care durează mai puțin de 2 zile și se pierde timp suplimentar din cauza activității de căutare în sine. Ar fi fost mai bine să deschizi un cont chiar la prima bancă.

Concluzie: Este mai important să alegi cu înțelepciune. Pentru a fi precis, alegeți care opțiunea este cea mai bună, nu cea mai ieftină.

În mod similar, MS SQL Optimizer funcționează pe algoritmi exhaustivi/euristici încorporați. Scopul este de a minimiza timpul de rulare a interogării. Toți algoritmii Optimizer sunt proprietatea de Microsoft si un secret. Cu toate ca, mai jos sunt pașii de nivel înalt efectuati de MS SQL Optimizer. Căutările de optimizare urmează trei faze, așa cum se arată în diagrama de mai jos:

Faza 0: Căutare plan trivial:

• Acesta este, de asemenea, cunoscut sub numele de Etapa de pre-optimizare.
• În unele cazuri, ar putea exista un singur plan practic, funcțional, cunoscut sub numele de plan trivial. Nu este nevoie să creați un plan optimizat. Motivul este că căutarea mai mult ar duce la găsirea aceluiași plan de execuție pentru timpul de execuție. Și asta cu costul suplimentar de căutare a unui plan optimizat, care nu era deloc necesar.
• Dacă nu s-a găsit niciun plan Trivial, atunci 1^st Începe faza.

Etapa 1: Căutați planuri de procesare a tranzacțiilor

• Aceasta include căutarea pentru Plan simplu și complex.
• Căutare simplă în plan: Datele anterioare ale coloanei și indexului implicate în interogare vor fi utilizate pentru analiza statistică. Acesta constă de obicei, dar nu se limitează la un singur index pe tabel.
• Totuși, dacă planul simplu nu este găsit, atunci se caută un plan mai complex. Acesta implică index multiplu per tabel.

Faza 2: Procesare și optimizare paralelă.

• Dacă niciuna dintre strategiile de mai sus nu funcționează, Optimizer caută posibilități de procesare paralelă. Acest lucru depinde de capacitățile de procesare și de configurație ale mașinii.
• Dacă acest lucru nu este încă posibil, atunci începe faza finală de optimizare. Acum, scopul final de optimizare este găsirea tuturor celorlalte opțiuni posibile pentru a executa interogarea în cel mai bun mod. Faza finală de optimizare Algorithms sunt Microsoft Proprietatea.

Executor de interogări

Apelurile executantului de interogări Metoda de acces. Acesta oferă un plan de execuție pentru logica de preluare a datelor necesară pentru execuție. Odată ce datele sunt primite de la Storage Engine, rezultatul este publicat în stratul Protocol. În cele din urmă, datele sunt trimise utilizatorului final.

Motor de stocare

Munca motorului de stocare este de a stoca date într-un sistem de stocare precum Disk sau SAN și de a prelua datele atunci când este necesar. Înainte de a ne aprofunda în motorul de stocare, să aruncăm o privire la modul în care sunt stocate datele Baza de date si tipul de fișiere disponibile.

Fișier de date și extindere:

Data File, stochează fizic datele sub formă de pagini de date, fiecare pagină de date având o dimensiune de 8KB, formând cea mai mică unitate de stocare din SQL Server. Aceste pagini de date sunt grupate în mod logic pentru a forma întinderi. Niciun obiect nu i se atribuie o pagină în SQL Server.

Întreținerea obiectului se face prin extensii. Pagina are o secțiune numită Antet de pagină cu o dimensiune de 96 de octeți, care conține informații despre metadate despre pagină, cum ar fi tipul paginii, numărul paginii, dimensiunea spațiului utilizat, dimensiunea spațiului liber și indicatorul către pagina următoare și pagina anterioară. , etc.

Tipuri de fisiere

1. Fișierul principal

• Fiecare bază de date conține un fișier primar.
• Acesta stochează toate datele importante legate de tabele, vizualizări, declanșatoare etc.
• Extensia este.MDF de obicei, dar poate avea orice extensie.

2. Dosar secundar

• Baza de date poate sau nu conține mai multe fișiere secundare.
• Acesta este opțional și conține date specifice utilizatorului.
• Extensia este.NDF de obicei, dar poate avea orice extensie.

3. Fișier jurnal

• De asemenea, cunoscut sub numele de jurnalele Scriere înainte.
• Extensia este.ldf
• Folosit pentru gestionarea tranzacțiilor.
• Acesta este folosit pentru a recupera din orice instanțe nedorite. Efectuați sarcina importantă de Rollback la tranzacțiile neangajate.

Storage Engine are 3 componente; hai să le analizăm în detaliu.

Metoda de acces

Acționează ca o interfață între executorul de interogări și Buffer Manager/Jurnalele tranzacțiilor.

Metoda de acces în sine nu face nicio execuție.

Prima acțiune este de a determina dacă interogarea este:

1. Selectați Declarație (DDL)
2. Declarație Non-Select (DDL și DML)

În funcție de rezultat, Metoda de acces ia următorii pași:

1. Dacă interogarea este DDL, instrucțiunea SELECT, interogarea este transmisă la Buffer Manager pentru prelucrare ulterioară.
2. Și dacă interogați dacă DDL, instrucțiune NON-SELECT, interogarea este transmisă la Managerul de tranzacții. Aceasta include în mare parte declarația UPDATE.

Buffer Manager

Buffer managerul gestionează funcțiile de bază pentru modulele de mai jos:

• Cache de planuri
• Analiza datelor: Buffer cache și stocare de date
• Pagina murdară

Vom învăța Plan, Buffer și Cache de date în această secțiune. Vom acoperi paginile murdare în secțiunea Tranzacție.

Cache de planuri

• Plan de interogare existent: Managerul buffer-ului verifică dacă planul de execuție este acolo în memoria cache a planului stocată. Dacă da, atunci se utilizează memoria cache a planului de interogare și memoria cache a datelor asociată.
• Planul cache pentru prima dată: De unde provine planul cache existent? Dacă planul de execuție a interogării pentru prima dată este rulat și este complex, este logic să îl stocați în cacheul Plane. Acest lucru va asigura o disponibilitate mai rapidă la data viitoare când serverul SQL primește aceeași interogare. Deci, nu este altceva decât interogarea în sine care execuția Planului este stocată dacă este rulată pentru prima dată.

Analiza datelor: Buffer cache și stocare de date

Buffer managerul oferă acces la datele necesare. Mai jos sunt posibile două abordări, în funcție de faptul dacă datele există sau nu în memoria cache:

Buffer Cache – Analiză soft:

Buffer Managerul caută date în Buffer în cache de date. Dacă sunt prezente, atunci aceste date sunt utilizate de Query Executor. Acest lucru îmbunătățește performanța, deoarece numărul de operațiuni I/O este redus la preluarea datelor din memoria cache, în comparație cu preluarea datelor din stocarea datelor.

Stocarea datelor – Hard Parsing:

Dacă datele nu sunt prezente în Buffer Manager decât este necesar Datele sunt căutate în Data Storage. Dacă stochează și date în memoria cache de date pentru utilizare ulterioară.

Pagina murdară

Este stocat ca o logică de procesare a Transaction Manager. Vom afla în detaliu în secțiunea Manager de tranzacții.

Manager de tranzacții

Managerul de tranzacții este invocat atunci când metoda de acces determină că Interogarea este o instrucțiune Non-Select.

Manager de jurnal

• Log Manager ține evidența tuturor actualizărilor efectuate în sistem prin intermediul jurnalelor din jurnalele de tranzacții.
• Jurnalele au Înregistrează numărul de secvență cu ID-ul tranzacției și înregistrarea modificării datelor.
• Acesta este folosit pentru a ține evidența Tranzacție angajată și derulare a tranzacției.

Manager de blocare

• În timpul tranzacției, datele asociate din stocarea datelor sunt în starea Blocare. Acest proces este gestionat de Lock Manager.
• Acest proces asigură consistența și izolarea datelor. De asemenea, cunoscut sub numele de proprietăți ACIDE.

Procesul de execuție

• Log Manager începe înregistrarea și Lock Manager blochează datele asociate.
• Copia datelor este păstrată în Buffer cache.
• Copia datelor care ar trebui să fie actualizate este menținută în memoria tampon de jurnal și toate evenimentele actualizează datele în tamponul de date.
• Paginile care stochează datele sunt cunoscute și ca Pagini murdare.
• Înregistrare punct de control și scriere anticipată: Acest proces rulează și marchează toată pagina de la Dirty Pages la Disk, dar pagina rămâne în cache. Frecvența este de aproximativ 1 alergare pe minut. Dar pagina este mai întâi împinsă la pagina de date a fișierului jurnal de la Buffer Buturuga. Aceasta este cunoscută ca Scrieți înainte de înregistrare.
• Scriitor leneș: Pagina Dirty poate rămâne în memorie. Când serverul SQL observă o încărcare uriașă și Buffer memorie este necesară pentru o nouă tranzacție, eliberează paginile murdare din cache. Funcționează pe LRU – Algoritmul folosit cel mai puțin recent pentru curățarea paginii din pool-ul de buffer pe disc.

Rezumat

• Trei tipuri de client server Archiexistă: 1) memorie partajată 2) TCP/IP 3) conducte denumite
• TDS, dezvoltat de Sybase și acum deținut de Microsoft, este un pachet care este încapsulat în pachete de rețea pentru transferul de date de la mașina client la mașina server.
• Motorul relațional conține trei componente majore:Analizor CMD: Acesta este responsabil pentru erorile sintactice și semantice și în cele din urmă generează un arbore de interogări.Optimizator: Rolul optimizatorului este de a găsi cel mai ieftin, nu cel mai bun, plan de execuție rentabil.

  Executor de interogări: Executorul de interogări apelează Metoda de acces și oferă un plan de execuție pentru logica de preluare a datelor necesară pentru execuție.

• Există trei tipuri de fișiere: fișier primar, fișier secundar și fișiere jurnal.
• Motor de stocare: are următoarele componente importanteMetoda de acces: Această componentă Stabiliți dacă interogarea este Instrucțiune Select sau Non-Select. Invocă Buffer și Transfer Manager în consecință.Buffer Manager: Buffer managerul gestionează funcțiile de bază pentru Plan Cache, Data Parsing și Dirty Page.

  Manager de tranzacții: Gestionează tranzacțiile non-selectate cu ajutorul managerilor de jurnal și blocare. De asemenea, facilitează implementarea importantă a jurnalizării Write Ahead și a scriitorilor leneși.