SQL Server Architecture Explained: Named Pipes, Optimizer, Buffer Manager

Innholdsfortegnelse:

Anonim

MS SQL Server er en klient-server-arkitektur. MS SQL Server-prosessen starter med at klientapplikasjonen sender en forespørsel. SQL Server godtar, behandler og svarer på forespørselen med behandlede data. La oss diskutere i detalj hele arkitekturen vist nedenfor:

Som diagrammet nedenfor viser, er det tre hovedkomponenter i SQL Server Architecture:

  1. Protokolllag
  2. Relasjonsmotor
  3. Lagringsmotor
SQL Server-arkitekturdiagram

La oss diskutere i detalj om alle de tre hovedmodulene ovenfor. I denne veiledningen vil du lære.

  • Protokolllag - SNI
    • Delt minne
    • TCP / IP
    • Navngitte rør
    • Hva er TDS?
  • Relasjonsmotor
    • CMD-parser
    • Optimizer
    • Spørringseksekutør
  • Lagringsmotor
    • Filtyper
    • Tilgangsmetode
    • Buffer Manager
    • Planlegg hurtigbuffer
    • Dataparsering: Bufferbuffer og datalagring
    • Transaksjonssjef

Protokolllag - SNI

MS SQL SERVER PROTOCOL LAYER støtter 3 Type Client Server Architecture. Vi starter med " Three Type of Client Server Architecture" som MS SQL Server støtter.

Delt minne

La oss revurdere et samtalescenario tidlig om morgenen.

MAMMA og TOM - Her var Tom og moren hans på det samme logiske stedet, altså hjemme hos dem. Tom var i stand til å be om kaffe og mor klarte å servere den varm.

MS SQL SERVER - Her gir MS SQL server Delt minneprotokoll . Her kjører CLIENT og MS SQL server på samme maskin. Begge kan kommunisere via delt minneprotokoll.

Analogi: Lar kartlegge enheter i de to ovennevnte scenariene. Vi kan enkelt kartlegge Tom til klient, mamma til SQL server, Hjem til maskin og verbal kommunikasjon til delt minneprotokoll.

Fra skrivebordet for konfigurasjon og installasjon:

For tilkobling til lokal DB - I SQL Management Studio kan alternativet "Servernavn" være

"."

"lokal vert"

"127.0.0.1"

"Machine \ Instance"

TCP / IP

Tenk nå om kvelden, Tom er i feststemning. Han vil ha en kaffe bestilt fra en velkjent kaffebar. Kaffebaren ligger 10 km fra hjemmet hans.

Her er Tom og Starbuck forskjellige fysiske steder. Tom hjemme og Starbucks på den travle markedsplassen. De kommuniserer via mobilnettverket. På samme måte gir MS SQL SERVER muligheten til å samhandle via TCP / IP-protokoll, der CLIENT og MS SQL Server er fjernt til hverandre og installert på en egen maskin.

Analogi: Lar kartlegge enheter i de to ovennevnte scenariene. Vi kan enkelt kartlegge Tom til klient, Starbuck til SQL-server, Hjem / markedsplass til ekstern plassering og til slutt mobilnett til TCP / IP-protokoll.

Merknader fra skrivebordet til konfigurasjon / installasjon:

  • I SQL Management Studio - For tilkobling via TCP \ IP må alternativet "Servernavn" være "Maskin \ Forekomst av serveren."
  • SQL server bruker port 1433 i TCP / IP.

Navngitte rør

Nå endelig om natten ønsket Tom å ha en lys grønn te som naboen Sierra, forberedte veldig godt.

Her er Tom og naboen , Sierra, på samme fysiske sted, og er hverandres nabo. De kommuniserer via Intra-nettverket. På samme måte gir MS SQL SERVER muligheten til å samhandle via Named Pipe- protokollen. Her er CLIENT og MS SQL SERVER i forbindelse via LAN .

Analogi: Lar kartlegge enheter i de to ovennevnte scenariene. Vi kan enkelt kartlegge Tom til klient, Sierra til SQL-server, nabo til LAN og til slutt Intra-nettverk til Named Pipe Protocol.

Merknader fra skrivebordet til konfigurasjon / installasjon:

  • For tilkobling via navngitt rør. Dette alternativet er deaktivert som standard og må aktiveres av SQL Configuration Manager.

Hva er TDS?

Nå som vi vet at det er tre typer klient-serverarkitektur, kan vi ta et blikk på TDS:

  • TDS står for Tabular Data Stream.
  • Alle 3 protokollene bruker TDS-pakker. TDS er innkapslet i nettverkspakker. Dette muliggjør dataoverføring fra klientmaskinen til servermaskinen.
  • TDS ble først utviklet av Sybase og eies nå av Microsoft

Relasjonsmotor

Relational Engine er også kjent som Query Processor. Den har SQL Server-komponentene som bestemmer hva en spørring trenger å gjøre og hvordan den kan gjøres best. Det er ansvarlig for utførelsen av brukerhenvendelser ved å be om data fra lagringsmotoren og behandle resultatene som returneres.

Som avbildet i arkitektonisk diagram er det tre hovedkomponenter i Relational Engine. La oss studere komponentene i detalj:

CMD-parser

Data en gang mottatt fra Protocol Layer overføres deretter til Relational Engine. "CMD Parser" er den første komponenten i Relational Engine som mottar spørringsdataene. Hovedoppgaven til CMD Parser er å sjekke spørringen for syntaktisk og semantisk feil. Til slutt genererer det et spørretre . La oss diskutere i detalj.

Syntaktisk sjekk:

  • Som alle andre programmeringsspråk har MS SQL også det forhåndsdefinerte settet med nøkkelord. SQL Server har også sin egen grammatikk som SQL server forstår.
  • SELECT, INSERT, UPDATE og mange andre tilhører MS SQL forhåndsdefinerte søkeordlister.
  • CMD Parser gjør syntaktisk sjekk. Hvis brukernes innspill ikke følger disse språksyntaksene eller grammatikkreglene, returnerer det en feil.

Eksempel: La oss si at en russer gikk til en japansk restaurant. Han bestiller hurtigmat på russisk. Dessverre forstår servitøren bare japansk. Hva ville være det mest åpenbare resultatet?

Svaret er - servitøren klarer ikke å behandle bestillingen videre.

Det skal ikke være noe avvik i grammatikk eller språk som SQL-server godtar. Hvis det er det, kan ikke SQL-serveren behandle det, og vil dermed returnere en feilmelding.

Vi vil lære om MS SQL-spørring mer i kommende opplæringsprogrammer. Tenk likevel under de mest grunnleggende spørringssyntaksene som 

SELECT * from ;

Nå, for å få oppfatningen av hva syntaktisk gjør, si om brukeren kjører den grunnleggende spørringen som nedenfor:

SELECR * from

Merk at i stedet for 'VELG' skrev brukeren "SELECR."

Resultat: CMD Parser vil analysere denne påstanden og kaste feilmeldingen. Da "SELECR" ikke følger det forhåndsdefinerte søkeordnavnet og grammatikken. Her ventet CMD Parser "SELECT".

Semantisk sjekk:

  • Dette utføres av Normalizer .
  • I sin enkleste form sjekker den om kolonnenavn, tabellnavn som blir spurt, finnes i skjemaet. Og hvis den eksisterer, bind den til spørring. Dette er også kjent som Binding .
  • Kompleksiteten øker når brukerforespørsler inneholder VIEW. Normalizer utfører erstatningen med den internt lagrede visningsdefinisjonen og mye mer.

La oss forstå dette ved hjelp av eksemplet nedenfor -

SELECT * from USER_ID

Resultat: CMD Parser vil analysere denne uttalelsen for semantisk sjekk. Parseren vil kaste en feilmelding da Normalizer ikke finner den forespurte tabellen (USER_ID) da den ikke eksisterer.

Lag spørretre:

  • Dette trinnet genererer forskjellige kjøringstreet der spørringen kan kjøres.
  • Merk at alle de forskjellige trærne har samme ønskede utgang.

Optimizer

Arbeidet til optimalisereren er å lage en utførelsesplan for brukerens forespørsel. Dette er planen som vil bestemme hvordan brukerforespørselen skal utføres.

Merk at ikke alle spørsmål er optimalisert. Optimalisering gjøres for DML-kommandoer (Data Modification Language) som SELECT, INSERT, DELETE og UPDATE. Slike spørsmål blir først merket og deretter sendt til optimalisereren. DDL-kommandoer som CREATE og ALTER er ikke optimalisert, men de blir i stedet kompilert til en intern form. Spørringskostnaden beregnes ut fra faktorer som CPU-bruk, minnebruk og behov for inngang / utgang.

Optimizers rolle er å finne den billigste, ikke den beste, kostnadseffektive gjennomføringsplanen.

Før vi går inn i mer tekniske detaljer om Optimizer, kan du vurdere eksemplet nedenfor:

Eksempel:

La oss si at du vil åpne en online bankkonto. Du vet allerede om en bank som tar maksimalt to dager å åpne en konto. Men du har også en liste over 20 andre banker, som kan ta eller ikke ta mindre enn to dager. Du kan begynne å snakke med disse bankene for å finne ut hvilke banker som tar mindre enn to dager. Nå kan det hende du ikke finner en bank som tar mindre enn to dager, og det er ekstra tid som går tapt på grunn av selve søkeaktiviteten. Det hadde vært bedre å åpne en konto i den første banken selv.

Konklusjon: Det er viktigere å velge klokt. For å være presis, velg hvilket alternativ som er best, ikke det billigste.

Tilsvarende fungerer MS SQL Optimizer på innebygde uttømmende / heuristiske algoritmer. Målet er å minimere spørringstid. Alle Optimizer-algoritmene er Microsoft og en hemmelighet. Selv om , nedenfor er de høyt nivå trinn utført av MS SQL Optimizer. Søk etter optimalisering følger tre faser som vist i diagrammet nedenfor:

Fase 0: Søk etter Trivial Plan:

  • Dette er også kjent som Pre-optimization stage .
  • I noen tilfeller kan det bare være en praktisk, gjennomførbar plan, kjent som en triviell plan. Det er ikke behov for å lage en optimalisert plan. Årsaken er at søk etter mer vil resultere i å finne den samme utførelsesplanen for kjøretid. Det også med de ekstra kostnadene ved å søke etter optimalisert plan som ikke var nødvendig i det hele tatt.
  • Hvis ingen Trivial plan funnet, så en st fase starter.

Fase 1: Søk etter planer for prosesseringsbehandling

  • Dette inkluderer søket etter enkel og kompleks plan .
  • Enkel plansøk: Tidligere data for kolonne og indeks involvert i spørring, vil bli brukt til statistisk analyse. Dette består vanligvis, men ikke begrenset til, en indeks per tabell.
  • Likevel, hvis den enkle planen ikke blir funnet, blir det søkt etter mer kompleks Plan. Det involverer flere indekser per tabell.

Fase 2: Parallell prosessering og optimalisering.

  • Hvis ingen av de ovennevnte strategiene fungerer, søker Optimizer etter muligheter for parallellbehandling. Dette avhenger av maskinens prosesseringsmuligheter og konfigurasjon.
  • Hvis det fremdeles ikke er mulig, starter den siste optimaliseringsfasen. Nå er det endelige optimaliseringsmålet å finne alle andre mulige alternativer for å utføre spørringen på den beste måten. Endelig optimaliseringsfase Algoritmer er Microsoft Propriety.

Spørringseksekutør

Forespørsel kjører anrop Access Method. Det gir en utførelsesplan for henting av data som kreves for utføring. Når data er mottatt fra Storage Engine, blir resultatet publisert i protokolllaget. Til slutt sendes data til sluttbrukeren.

Lagringsmotor

Arbeidet med Storage Engine er å lagre data i et lagringssystem som Disk eller SAN og hente dataene når det er nødvendig. Før vi dykker ned i lagringsmotoren, la oss ta en titt på hvordan data lagres i databasen og hvilken type filer som er tilgjengelige.

Datafil og omfang:

Datafil, lagrer data fysisk i form av datasider, hvor hver dataside har en størrelse på 8 KB, og danner den minste lagringsenheten i SQL Server. Disse datasidene er logisk gruppert for å danne omfang. Ingen objekter er tildelt en side i SQL Server.

Vedlikeholdet av objektet gjøres via utvidelser. Siden har en seksjon kalt sidehode med en størrelse på 96 byte, som bærer metadatainformasjonen om siden, for eksempel sidetype, sidetall, størrelse på brukt plass, størrelse på ledig plass og peker til neste side og forrige side , etc.

Filtyper

  1. Primærfil
  • Hver database inneholder en primærfil.
  • Denne lagrer alle viktige data relatert til tabeller, visninger, utløsere osv.
  • Utvidelse er. mdf vanligvis, men kan være av hvilken som helst utvidelse.
  1. Sekundærfil
  • Databasen inneholder kanskje ikke flere sekundære filer.
  • Dette er valgfritt og inneholder brukerspesifikke data.
  • Utvidelse er. ndf vanligvis, men kan være av hvilken som helst utvidelse.
  1. Loggfil
  • Også kjent som Skriv frem logger.
  • Utvidelse er. ldf
  • Brukes til transaksjonsstyring.
  • Dette brukes til å gjenopprette fra uønskede tilfeller. Utfør viktig oppgave med tilbakeføring til ikke-forpliktede transaksjoner.

Storage Engine har 3 komponenter; la oss se nærmere på dem.

Tilgangsmetode

Den fungerer som et grensesnitt mellom spørringsutføreren og Buffer Manager / Transaction Logs.

Selve tilgangsmetoden utfører ikke noe.

Den første handlingen er å avgjøre om spørringen er:

  1. Velg uttalelse (DDL)
  2. Ikke-velg uttalelse (DDL & DML)

Avhengig av resultatet tar tilgangsmetoden følgende trinn:

  1. Hvis spørringen er DDL , SELECT-setning, sendes spørringen til Buffer Manager for videre behandling.
  2. Og hvis spørring hvis DDL, NON-SELECT-setning , blir spørringen sendt til Transaction Manager. Dette inkluderer for det meste UPDATE-uttalelsen.

Buffer Manager

Buffer manager administrerer kjernefunksjoner for moduler nedenfor:

  • Planlegg hurtigbuffer
  • Dataparsering: Bufferbuffer og datalagring
  • Skitten side

Vi lærer plan-, buffer- og datacache i denne delen. Vi vil dekke skitne sider i Transaksjonen.

Planlegg hurtigbuffer

  • Eksisterende spørringsplan: Bufferebehandleren sjekker om utførelsesplanen er der i den lagrede planbufferen. Hvis Ja, brukes hurtigbuffer for spørring og tilhørende databuffer.
  • Første gang hurtigbufferplan: Hvor kommer eksisterende planbuffer fra?

    Hvis planleggingen for første gangs spørringsutførelse kjøres og er kompleks, er det fornuftig å lagre den i flybufferen. Dette vil sikre raskere tilgjengelighet når neste gang SQL-server får den samme spørringen. Så det er ingenting annet enn spørringen i seg selv hvilken planutførelse blir lagret hvis den kjøres for første gang.

Dataparsering: Bufferbuffer og datalagring

Buffer manager gir tilgang til de nødvendige dataene. Nedenfor er to tilnærminger mulig, avhengig av om det finnes data i databufferen eller ikke:

Buffer Cache - myk parsing:

Buffer Manager ser etter Data i Buffer i Data cache. Hvis data er til stede, brukes disse dataene av spørringsutføreren. Dette forbedrer ytelsen ettersom antall I / O-operasjoner reduseres når data hentes fra hurtigbufferen sammenlignet med henting av data fra datalagring.

Datalagring - hard parsing:

Hvis data ikke er tilstede i Buffer Manager enn nødvendig, blir det søkt etter data i datalagring. Hvis også lagrer data i databufferen for fremtidig bruk.

Skitten side

Den lagres som en behandlingslogikk av Transaction Manager. Vi vil lære mer om dette i Transaction Manager-delen.

Transaksjonssjef

Transaction Manager påkalles når tilgangsmetoden bestemmer at Query er en ikke-Select-setning.

Loggbehandling

  • Log Manager holder oversikt over alle oppdateringer som er gjort i systemet via logger i Transaction Logs.
  • Logger har loggsekvensnummer med transaksjons-ID og datamodifikasjonspost .
  • Dette brukes til å holde oversikt over forpliktende transaksjoner og tilbakeføring av transaksjoner .

Låsesjef

  • Under transaksjonen er de tilknyttede dataene i datalagring i låsestatus. Denne prosessen håndteres av Lock Manager.
  • Denne prosessen sikrer datakonsistens og isolasjon . Også kjent som ACID-egenskaper.

Utførelsesprosess

  • Log Manager begynner å logge og Lock Manager låser de tilknyttede dataene.
  • Datakopien opprettholdes i bufferbufferen.
  • Kopi av data som skal oppdateres opprettholdes i Loggbuffer, og alle hendelsesoppdateringsdataene i Databuffer.
  • Sider som lagrer dataene er også kjent som Dirty Pages .
  • Sjekkpunkt- og skrivelogglogging: Denne prosessen kjører og merker hele siden fra skitne sider til disk, men siden forblir i hurtigbufferen. Frekvensen er omtrent 1 kjøring per minutt, men siden skyves først til datasiden i loggfilen fra bufferloggen. Dette er kjent som Skriv fremover logging.
  • Lazy Writer: Den skitne siden kan forbli i minnet. Når SQL-server observerer en enorm belastning og bufferminne er nødvendig for en ny transaksjon, frigjør den skitne sider fra hurtigbufferen. Den fungerer på LRU - Minst nylig brukte algoritme for å rense siden fra bufferbasseng til disk.

Sammendrag:

  • Tre typer klientserverarkitektur eksisterer: 1) Delt minne 2) TCP / IP 3) Navngitte rør
  • TDS, utviklet av Sybase og nå eid av Microsoft, er en pakke som er innkapslet i nettverkspakker for dataoverføring fra klientmaskinen til servermaskinen.
  • Relational Engine inneholder tre hovedkomponenter:

    CMD Parser: Dette er ansvarlig for syntaktisk og semantisk feil og genererer til slutt et spørretre.

    Optimizer: Optimizer-rollen er å finne den billigste, ikke den beste, kostnadseffektive gjennomføringsplanen.

    Query Executor: Query executer anrop Access Method og gir utførelsesplan for datahentingslogikk som kreves for utføring.

  • Det finnes tre typer filer Primærfil, Sekundærfil og Loggfiler.
  • Lagringsmotor: Har følgende viktige komponenter

    Tilgangsmetode: Denne komponenten Bestemmer om spørringen er Select eller Non-Select Statement. Påkaller Buffer and Transfer Manager deretter.

    Buffer Manager: Buffer manager administrerer kjernefunksjoner for Plan Cache, Data Parsing & Dirty Page.

    Transaction Manager: It manager Non-Select Transaction ved hjelp av Log and Lock Managers. Fasiliterer også viktig implementering av Write Ahead-logging og Lazy forfattere.