SQL Server Architecture (forklaret)

Bemærkninger fra skrivebordet for konfiguration/installation:

• Til tilslutning via navngivet rør. Denne indstilling er deaktiveret som standard og skal aktiveres af SQL Configuration Manager.

Hvad er TDS?

Nu hvor vi ved, at der er tre typer klient-servere Architecture, lader os få et blik på TDS:

• TDS står for Tabular Data Stream.
• Alle 3 protokoller bruger TDS-pakker. TDS er indkapslet i netværkspakker. Dette muliggør dataoverførsel fra klientmaskinen til servermaskinen.
• TDS blev først udviklet af Sybase og ejes nu af Microsoft

Relationel motor

Den relationelle motor er også kendt som forespørgselsprocessoren. Det har SQL Server komponenter, der bestemmer præcis, hvad en forespørgsel skal gøre, og hvordan den bedst kan gøres. Den er ansvarlig for udførelsen af ​​brugerforespørgsler ved at anmode om data fra lagermotoren og behandle de resultater, der returneres.

Som afbildet i Architekturdiagram der er 3 hovedkomponenter af den relationelle motor. Lad os studere komponenterne i detaljer:

CMD Parser

Når data er modtaget fra Protocol Layer, sendes derefter til Relational Engine. "CMD Parser" er den første komponent i Relational Engine, der modtager forespørgselsdataene. CMD Parsers hovedopgave er at tjekke forespørgslen efter Syntaktisk og semantisk fejl. Endelig det genererer et forespørgselstræ. Lad os diskutere i detaljer.

Syntaktisk kontrol:

• Som alle andre programmeringssprog har MS SQL også det foruddefinerede sæt nøgleord. SQL Server har også sin egen grammatik, som SQL server forstår.
• SELECT, INSERT, UPDATE og mange andre tilhører MS SQL foruddefinerede søgeordslister.
• CMD Parser udfører syntaktisk kontrol. Hvis brugernes input ikke følger disse sprogsyntaks eller grammatikregler, er det returnerer en fejl.

Eksempel: Lad os sige, at en russer gik på en japansk restaurant. Han bestiller fastfood på det russiske sprog. Desværre forstår tjeneren kun japansk. Hvad ville være det mest oplagte resultat?

Svaret er - tjeneren er ikke i stand til at behandle ordren yderligere.

Der bør ikke være nogen afvigelse i grammatik eller sprog, som SQL-serveren accepterer. Hvis der er, kan SQL-serveren ikke behandle det og vil derfor returnere en fejlmeddelelse.

Vi vil lære mere om MS SQL-forespørgsler i kommende selvstudier. Overvej dog den mest grundlæggende forespørgselssyntaks nedenfor

SELECT * from <TABLE_NAME>;

For at få en opfattelse af, hvad syntaktisk gør, skal du sige, om brugeren kører den grundlæggende forespørgsel som nedenfor:

SELECR * from <TABLE_NAME>

Bemærk, at brugeren i stedet for 'SELECT' skrev "SELECR."

Resultat: CMD-parseren vil parse denne sætning og sender fejlmeddelelsen. Da "SELECR" ikke følger det foruddefinerede søgeordsnavn og grammatik. Her forventede CMD Parser "SELECT."

Semantisk kontrol:

• Dette udføres af Normalisator.
• I sin enkleste form kontrollerer den, om kolonnenavn, tabelnavn, der forespørges på, findes i skemaet. Og hvis det findes, skal du binde det til Query. Dette er også kendt som Binding.
• Kompleksiteten øges, når brugerforespørgsler indeholder VIEW. Normalizer udfører udskiftningen med den internt lagrede visningsdefinition og meget mere.

Lad os forstå dette ved hjælp af nedenstående eksempel -

SELECT * from USER_ID

Resultat: CMD Parser vil parse denne erklæring til semantisk kontrol. Parseren sender en fejlmeddelelse, da Normalizer ikke finder den anmodede tabel (USER_ID), da den ikke eksisterer.

Opret forespørgselstræ:

• Dette trin genererer et andet udførelsestræ, hvor forespørgslen kan køres.
• Bemærk, at alle de forskellige træer har det samme ønskede output.

Optimizer

Optimizerens arbejde er at lave en eksekveringsplan for brugerens forespørgsel. Dette er planen, der bestemmer, hvordan brugerforespørgslen vil blive udført.

Bemærk, at ikke alle forespørgsler er optimeret. Optimering udføres for DML (Data Modification Language) kommandoer som SELECT, INSERT, DELETE og UPDATE. Sådanne forespørgsler markeres først og sendes derefter til optimeringsværktøjet. DDL-kommandoer som CREATE og ALTER er ikke optimeret, men de er i stedet kompileret til en intern form. Forespørgselsomkostningerne beregnes baseret på faktorer som CPU-brug, hukommelsesforbrug og input/output-behov.

Optimizers rolle er at finde billigste, ikke den bedste, omkostningseffektive udførelsesplan.

Inden vi går ind i flere tekniske detaljer om Optimizer, skal du overveje nedenstående eksempel fra det virkelige liv:

Eksempel:

Lad os sige, at du vil åbne en online bankkonto. Du kender allerede til én bank, som tager maksimalt 2 dage at åbne en konto. Men du har også en liste over 20 andre banker, som kan eller ikke kan tage mindre end 2 dage. Du kan begynde at tale med disse banker for at afgøre, hvilke banker der tager mindre end 2 dage. Nu kan du muligvis ikke finde en bank, som tager mindre end 2 dage, og der er yderligere tabt tid på grund af selve søgeaktiviteten. Det ville have været bedre at åbne en konto i den første bank selv.

konklusion: Det er vigtigere at vælge klogt. For at være præcis, vælg hvilken muligheden er bedst, ikke den billigste.

Tilsvarende har MS SQL Optimizer fungerer på indbyggede udtømmende/heuristiske algoritmer. Målet er at minimere forespørgselskørselstid. Alle Optimizer-algoritmerne er sømmelighed af Microsoft og en hemmelighed. Skønt, nedenfor er trinene på højt niveau udført af MS SQL Optimizer. Søgninger efter optimering følger tre faser som vist i nedenstående diagram:

Fase 0: Søg efter triviel plan:

• Dette er også kendt som Foroptimeringsstadiet.
• I nogle tilfælde kunne der kun være én praktisk, brugbar plan, kendt som en triviel plan. Der er ikke behov for at lave en optimeret plan. Årsagen er, at søgning efter mere ville resultere i at finde den samme køretidsudførelsesplan. Det også med de ekstra omkostninger ved at søge efter optimeret plan, som slet ikke var påkrævet.
• Hvis der ikke findes en triviel plan, så 1^st Fasen starter.

Fase 1: Søg efter transaktionsbehandlingsplaner

• Dette inkluderer søgning efter Enkel og kompleks plan.
• Simpel plansøgning: Tidligere data for kolonne og indeks involveret i forespørgsel, vil blive brugt til statistisk analyse. Dette består normalt, men ikke begrænset til, et indeks pr. tabel.
• Alligevel, hvis den simple plan ikke findes, søges der efter mere kompleks plan. Det involverer flere indeks pr. tabel.

Fase 2: Parallel behandling og optimering.

• Hvis ingen af ​​ovenstående strategier virker, søger Optimizer efter muligheder for parallel behandling. Dette afhænger af maskinens behandlingsmuligheder og konfiguration.
• Hvis det stadig ikke er muligt, starter den sidste optimeringsfase. Nu er det endelige optimeringsmål at finde alle andre mulige muligheder for at udføre forespørgslen på den bedste måde. Afsluttende optimeringsfase Algorithms er Microsoft Anstændighed.

Forespørgselsudøver

Forespørgselsudøveren kalder Adgangsmetode. Det giver en eksekveringsplan for datahentningslogik, der kræves til eksekvering. Når data er modtaget fra Storage Engine, offentliggøres resultatet til protokollaget. Til sidst sendes data til slutbrugeren.

Opbevaringsmotor

Storage Engines arbejde er at gemme data i et lagersystem som Disk eller SAN og hente dataene, når det er nødvendigt. Før vi dykker ned i Storage Engine, lad os se på, hvordan data gemmes i Database og type tilgængelige filer.

Datafil og omfang:

Data File, gemmer fysisk data i form af datasider, hvor hver dataside har en størrelse på 8KB, der udgør den mindste lagerenhed i SQL Server. Disse datasider er logisk grupperet for at danne omfang. Intet objekt er tildelt en side i SQL Server.

Vedligeholdelsen af ​​objektet sker via udstrækninger. Siden har en sektion kaldet Sidehovedet med en størrelse på 96 bytes, der fører metadataoplysningerne om siden som sidetype, sidetal, størrelse på brugt plads, størrelse på ledig plads og markør til næste side og forrige side , etc.

Filtyper

1. Primær fil

• Hver database indeholder en primær fil.
• Dette gemmer alle vigtige data relateret til tabeller, visninger, triggere osv.
• Udvidelse er.MDF normalt, men kan have en hvilken som helst forlængelse.

2. Sekundær fil

• Databasen kan indeholde flere sekundære filer eller ikke.
• Dette er valgfrit og indeholder brugerspecifikke data.
• Udvidelse er.NDF normalt, men kan have en hvilken som helst forlængelse.

3. Logfil

• Også kendt som Write ahead logs.
• Udvidelse er.ldf
• Anvendes til transaktionsstyring.
• Dette bruges til at gendanne fra eventuelle uønskede tilfælde. Udfør en vigtig opgave med Rollback til ikke-forpligtede transaktioner.

Storage Engine har 3 komponenter; lad os se nærmere på dem.

Adgangsmetode

Det fungerer som en grænseflade mellem query executor og Buffer Manager/Transaktionslogs.

Adgangsmetoden udfører ikke selv nogen udførelse.

Den første handling er at bestemme, om forespørgslen er:

1. Vælg erklæring (DDL)
2. Ikke-valgt erklæring (DDL & DML)

Afhængigt af resultatet tager adgangsmetoden følgende trin:

1. Hvis forespørgslen er DDL, SELECT-sætning, sendes forespørgslen til Buffer Manager til videre behandling.
2. Og hvis forespørgsel hvis DDL, NON-SELECT-sætning, sendes forespørgslen til Transaction Manager. Dette inkluderer for det meste UPDATE-erklæringen.

Buffer Manager

Buffer leder administrerer kernefunktioner for nedenstående moduler:

• Plan cache
• Dataparsing: Buffer cache og datalagring
• Beskidt side

Vi vil lære Plan, Buffer og Datacache i dette afsnit. Vi vil dække beskidte sider i Transaktionssektionen.

Plan cache

• Eksisterende forespørgselsplan: Buffermanageren tjekker, om eksekveringsplanen er der i den gemte plancache. Hvis Ja, bruges forespørgselsplanens cache og dens tilhørende datacache.
• Første gang cache plan: Hvor kommer den eksisterende Plan-cache fra? Hvis planen for udførelse af forespørgsler for første gang køres og er kompleks, giver det mening at gemme den i Plane-cachen. Dette vil sikre hurtigere tilgængelighed, næste gang SQL-serveren får den samme forespørgsel. Så det er ikke andet end selve forespørgslen, hvilken Plan-udførelse gemmes, hvis den køres for første gang.

Dataparsing: Buffer cache og datalagring

Buffer manager giver adgang til de nødvendige data. Nedenfor er to tilgange mulige afhængigt af, om data findes i datacachen eller ej:

Buffer Cache – blød parsing:

Buffer Manager søger efter Data i Buffer i datacache. Hvis de er til stede, bruges disse data af Query Executor. Dette forbedrer ydeevnen, da antallet af I/O-operationer reduceres, når der hentes data fra cachen sammenlignet med at hente data fra datalageret.

Datalagring – hård parsing:

Hvis data ikke er til stede i Buffer Manager end påkrævet Data søges i Data Storage. If gemmer også data i datacachen til fremtidig brug.

Beskidt side

Det er gemt som en behandlingslogik i Transaction Manager. Vi vil lære mere detaljeret i afsnittet Transaction Manager.

Transaktionsleder

Transaction Manager påkaldes, når adgangsmetoden bestemmer, at Query er en Non-Select-sætning.

Log Manager

• Log Manager holder styr på alle opdateringer udført i systemet via logfiler i Transaction Logs.
• Logs har Logfører sekvensnummer med transaktions-id og dataændringspost.
• Dette bruges til at holde styr på Transaktion Committed og Transaction Rollback.

Låsemanager

• Under transaktionen er de tilknyttede data i datalageret i låst tilstand. Denne proces håndteres af Lock Manager.
• Denne proces sikrer datakonsistens og isolation. Også kendt som ACID-egenskaber.

Udførelsesproces

• Log Manager begynder at logge, og Lock Manager låser de tilknyttede data.
• Datas kopi vedligeholdes i Buffer cache.
• Kopi af data, der formodes at blive opdateret, vedligeholdes i logbuffer, og alle hændelser opdaterer data i databuffer.
• Sider, der gemmer data, er også kendt som Beskidte sider.
• Checkpoint og Write Ahead-logning: Denne proces kører og markerer hele siden fra Dirty Pages til Disk, men siden forbliver i cachen. Frekvensen er cirka 1 løb i minuttet. Men siden skubbes først til Data-siden i logfilen fra Buffer log. Dette er kendt som Skriv Ahead-logning.
• Doven forfatter: Den beskidte side kan forblive i hukommelsen. Når SQL server observerer en enorm belastning og Buffer hukommelse er nødvendig for en ny transaktion, frigør det Dirty Pages fra cachen. Den opererer videre LRU – Senest brugt algoritme til at rense side fra bufferpulje til disk.

Resumé

• Tre typer klientserver ArchiTecture eksisterer: 1) Delt hukommelse 2) TCP/IP 3) Navngivne rør
• TDS, udviklet af Sybase og nu ejet af Microsoft, er en pakke, som er indkapslet i netværkspakker til dataoverførsel fra klientmaskinen til servermaskinen.
• Relationel motor indeholder tre hovedkomponenter:CMD-parser: Dette er ansvarligt for syntaktiske og semantiske fejl og genererer endelig et forespørgselstræ.Optimizer: Optimizers rolle er at finde den billigste, ikke den bedste, omkostningseffektive eksekveringsplan.

  Forespørgselsudøver: Forespørgselseksekutor kalder Access Method og giver en eksekveringsplan for datahentningslogik, der kræves til eksekvering.

• Der findes tre typer filer Primær fil, Sekundær fil og Logfiler.
• Lagermotor: Har følgende vigtige komponenterAdgangsmetode: Denne komponent Bestem, om forespørgslen er Select eller Non-Select Statement. Påberåber sig Buffer og Transfer Manager i overensstemmelse hermed.Buffer Manager: Buffer manager administrerer kernefunktioner for Plan Cache, Data Parsing & Dirty Page.

  Transaktionsleder: It-manager ikke-valgt transaktion ved hjælp af log- og låseadministratorer. Letter også vigtig implementering af Write Ahead-logning og Lazy writers.