SQL Server Architecture (selitys)
MS SQL Server on asiakas-palvelin-arkkitehtuuri. MS SQL Server -prosessi alkaa asiakassovelluksen lähettämällä pyynnön. SQL Server hyväksyy, käsittelee ja vastaa pyyntöön käsitellyillä tiedoilla. Keskustellaan yksityiskohtaisesti koko alla näkyvästä arkkitehtuurista:
Kuten alla oleva kaavio esittää, SQL Serverissä on kolme pääkomponenttia Archirakenne:
- Protokollakerros
- Relaatiomoottori
- Varastointi Moottori

Protokollakerros – SNI
MS SQL SERVER PROTOCOL LAYER tukee kolmea asiakaspalvelintyyppiä Archirakenne. Aloitamme kanssa "Kolmen tyyppistä asiakaspalvelinta Architektuuri" jota MS SQL Server tukee.
Jaettu muisti
Mietitäänpä uudelleen aikaisen aamun keskustelun skenaariota.
ÄITI ja TOM – Täällä Tom ja hänen äitinsä olivat samassa loogisessa paikassa eli kotonaan. Tom pystyi pyytämään kahvia ja äiti pystyi tarjoamaan sen kuumana.
MS SQL PALVELIN – Tässä MS SQL palvelin tarjoaa JAETTU MUISTIN PROTOKOLLA. Tässä ASIAKAS ja MS SQL palvelin toimii samalla koneella. Molemmat voivat kommunikoida Shared Memory -protokollan kautta.
Analogia: Antaa kartoittaa entiteetit yllä olevissa kahdessa skenaariossa. Voimme helposti kartoittaa Tomin asiakaskoneeseen, äidin SQL-palvelimeen, Home to Machineen ja sanallisen viestinnän jaettuun muistiprotokollaan.
Määritys- ja asennustyöpöydältä:
Yhteyttä varten paikalliseen tietokantaan – sisään SQL Management Studio, "Palvelimen nimi" -vaihtoehto voisi olla
""
"paikallinen isäntä"
"127.0.0.1"
"kone\instanssi"
TCP / IP
Mieti nyt illalla, Tom on juhlatunnelmissa. Hän haluaa kahvin tilattua tunnetusta kahvilasta. Coffee Shop sijaitsee 10 km päässä hänen kotoaan.
Täällä Tom ja Starbuck ovat eri fyysisessä paikassa. Tom kotona ja Starbucks vilkkaalla torilla. He kommunikoivat matkapuhelinverkon kautta. Vastaavasti MS SQL SERVER tarjoaa mahdollisuuden vuorovaikutukseen TCP / IP-protokolla, jossa CLIENT ja MS SQL Server ovat toistensa etäyhteydessä ja asennettu erilliseen koneeseen.
Analogia: Antaa kartoittaa entiteetit yllä olevissa kahdessa skenaariossa. Voimme helposti kartoittaa Tomin asiakaskoneeseen, Starbuckin SQL-palvelimeen, koti-/markkinapaikan etäsijaintiin ja lopuksi matkapuhelinverkon TCP/IP-protokollaan.
Huomautuksia kokoonpanon/asennuksen työpöydältä:
- SQL Management Studiossa – Jos yhteys muodostetaan TCP\IP:n kautta, "Palvelimen nimi" -vaihtoehdon on oltava "Machine\Instance of the Server".
- SQL-palvelin käyttää porttia 1433 TCP/IP:ssä.
Nimetyt putket
Nyt vihdoin illalla Tom halusi juoda vaaleanvihreää teetä, jonka hänen naapurinsa Sierra valmistaa erittäin hyvin.
Tässä Tomi ja hänen naapuri, Sierra, ovat samassa fyysinen sijainti, olla toistensa naapureita. He kommunikoivat kautta Sisäinen verkko. Vastaavasti MS SQL PALVELIN tarjoaa mahdollisuuden olla vuorovaikutuksessa nimeltään Pipe protokollaa. Täällä ASIAKAS ja MS SQL PALVELIN ovat yhteydessä kautta LAN.
Analogia: Antaa kartoittaa entiteetit yllä olevissa kahdessa skenaariossa. Voimme helposti kartoittaa Tomin asiakaskoneeseen, Sierran SQL-palvelimeen, Neighborin lähiverkkoon ja lopuksi Intra-verkon Named Pipe Protocoliin.
Huomautuksia kokoonpanon/asennuksen työpöydältä:
- Kytketään nimetyn putken kautta. Tämä vaihtoehto on oletuksena poistettu käytöstä, ja SQL Configuration Managerin on otettava se käyttöön.
Mikä on TDS?
Nyt kun tiedämme, että asiakaspalvelimia on kolmenlaisia Architecture, anna meidän vilkaista TDS:ää:
- TDS on lyhenne sanoista Tabular Data Stream.
- Kaikki 3 protokollaa käyttävät TDS-paketteja. TDS on kapseloitu verkkopaketteihin. Tämä mahdollistaa tiedonsiirron asiakaskoneelta palvelinkoneelle.
- TDS:n kehitti ensin Sybase, ja nyt sen omistaa Microsoft
Relaatiomoottori
Relaatiomoottori tunnetaan myös kyselyprosessorina. Siinä on SQL Server osat, jotka määrittävät, mitä kyselyn on tarkalleen tehtävä ja miten se voidaan tehdä parhaiten. Se vastaa käyttäjien kyselyiden suorittamisesta pyytämällä tietoja tallennuskoneelta ja käsittelemällä palautetut tulokset.
Kuten kuvassa Archisiellä on rakenteellisia kaavioita 3 pääkomponenttia relaatiomoottorista. Tutkitaan komponentteja yksityiskohtaisesti:
CMD jäsentäjä
Protocol Layerista saatu data välitetään sitten Relational Enginelle. "CMD jäsentäjä" on ensimmäinen Relational Enginen komponentti, joka vastaanottaa kyselytiedot. CMD Parserin päätehtävä on tarkistaa kysely Syntaktinen ja semanttinen virhe. Lopulta se luo kyselypuun. Keskustellaan yksityiskohtaisesti.
Syntaktinen tarkistus:
- Kuten kaikilla muilla ohjelmointikielillä, MS SQL:llä on myös ennalta määritellyt avainsanat. Lisäksi SQL Serverillä on oma kielioppi, jonka SQL-palvelin ymmärtää.
- SELECT, INSERT, UPDATE ja monet muut kuuluvat MS SQL:n ennalta määritettyihin avainsanaluetteloihin.
- CMD Parser tekee syntaktisen tarkistuksen. Jos käyttäjien syöte ei noudata näitä kielen syntaksia tai kielioppisääntöjä, se palauttaa virheen.
Esimerkiksi: Oletetaan, että venäläinen meni japanilaiseen ravintolaan. Hän tilaa pikaruokaa venäjän kielellä. Valitettavasti tarjoilija ymmärtää vain japania. Mikä olisi ilmeisin tulos?
Vastaus on – tarjoilija ei pysty käsittelemään tilausta enempää.
Kieliopissa tai SQL-palvelimen hyväksymässä kielessä ei saa olla poikkeamia. Jos niitä on, SQL-palvelin ei voi käsitellä sitä ja palauttaa siten virheilmoituksen.
Opimme MS SQL -kyselystä lisää tulevissa opetusohjelmissa. Harkitse kuitenkin alla yksinkertaisinta kyselyn syntaksia
SELECT * from <TABLE_NAME>;
Nyt saadaksesi käsityksen siitä, mitä syntaktinen toiminta tekee, sano, suorittaako käyttäjä peruskyselyn seuraavasti:
SELECR * from <TABLE_NAME>
Huomaa, että SELECT-vaihtoehdon sijaan käyttäjä kirjoitti sanan SELECR.
Tulos: CMD-jäsennys jäsentää tämän käskyn ja lähettää virheilmoituksen. Koska "SELECR" ei noudata ennalta määritettyä avainsanan nimeä ja kielioppia. Täällä CMD Parser odotti "SELECT".
Semanttinen tarkistus:
- Tämän suorittaa Normalizer.
- Yksinkertaisimmassa muodossaan se tarkistaa, onko Schemassa olemassa Sarakkeen nimi, Kyselyn taulukon nimi. Ja jos se on olemassa, sido se Queryyn. Tämä tunnetaan myös nimellä Sitova.
- Monimutkaisuus lisääntyy, kun käyttäjän kyselyt sisältävät VIEW-sanan. Normalisoija korvaa sisäisesti tallennetun näkymän määritelmän ja paljon muuta.
Ymmärretään tämä alla olevan esimerkin avulla -
SELECT * from USER_ID
Tulos: CMD Parser jäsentää tämän lausunnon semanttista tarkistusta varten. Jäsentäjä antaa virheilmoituksen, koska Normalizer ei löydä pyydettyä taulukkoa (USER_ID), koska sitä ei ole olemassa.
Luo kyselypuu:
- Tämä vaihe luo erilaisen suorituspuun, jossa kysely voidaan suorittaa.
- Huomaa, että kaikilla eri puilla on sama haluttu tulos.
Optimizer
Optimoijan tehtävänä on luoda suoritussuunnitelma käyttäjän kyselylle. Tämä on suunnitelma, joka määrittää, kuinka käyttäjän kysely suoritetaan.
Huomaa, että kaikkia kyselyitä ei ole optimoitu. Optimointi tehdään DML-komennoille (Data Modification Language), kuten SELECT, INSERT, DELETE ja UPDATE. Tällaiset kyselyt merkitään ensin ja lähetetään sitten optimoijalle. DDL-komentoja, kuten CREATE ja ALTER, ei ole optimoitu, vaan ne käännetään sisäiseen muotoon. Kyselyn hinta lasketaan sellaisten tekijöiden perusteella, kuten suorittimen käyttö, muistin käyttö ja syöttö-/lähtötarpeet.
Optimoijan tehtävänä on löytää halvin, ei paras, kustannustehokas toteutussuunnitelma.
Ennen kuin siirrymme Optimizerin teknisiin yksityiskohtiin, harkitse alla olevaa tosielämän esimerkkiä:
Esimerkiksi:
Oletetaan, että haluat avata verkkopankkitilin. Tiedät jo yhdestä pankista, jonka tilin avaaminen kestää enintään 2 päivää. Mutta sinulla on myös luettelo 20 muusta pankista, jotka voivat kestää alle 2 päivää tai ei. Voit aloittaa yhteydenpidon näiden pankkien kanssa selvittääksesi, mitkä pankit kestävät alle 2 päivää. Nyt et ehkä löydä pankkia, joka kestää alle 2 päivää, ja lisää aikaa menetetään itse hakutoiminnan vuoksi. Olisi ollut parempi avata tili itse ensimmäiseen pankkiin.
Johtopäätös: Tärkeämpää on valita viisaasti. Tarkemmin sanottuna valitse mikä vaihtoehto on paras, ei halvin.
Samoin MS SQL Optimizer toimii sisäänrakennetuilla tyhjentävillä/heuristisilla algoritmeilla. Tavoitteena on minimoida kyselyn suoritusaika. Kaikki Optimizer-algoritmit ovat soveltuvuus Microsoft ja salaisuus. Vaikka, alla ovat korkean tason vaiheet, jotka MS SQL Optimizer suorittaa. Optimointihaku seuraa kolmea vaihetta alla olevan kaavion mukaisesti:
Vaihe 0: Etsi triviaalisuunnitelma:
- Tämä tunnetaan myös nimellä Esioptimointivaihe.
- Joissakin tapauksissa voi olla vain yksi käytännöllinen, toimiva suunnitelma, joka tunnetaan triviaalina suunnitelmana. Optimoitua suunnitelmaa ei tarvitse luoda. Syynä on se, että etsiminen lisää johtaisi saman ajonaikaisen suoritussuunnitelman löytämiseen. Myös optimoidun suunnitelman etsimisestä aiheutui ylimääräisiä kustannuksia, joita ei vaadittu ollenkaan.
- Jos triviaalia suunnitelmaa ei löydy, niin 1st Vaihe alkaa.
Vaihe 1: Etsi tapahtumankäsittelysuunnitelmat
- Tämä sisältää haun Yksinkertainen ja monimutkainen suunnitelma.
- Yksinkertainen suunnitelmahaku: Kyselyyn osallistuvan sarakkeen ja indeksin aiempia tietoja käytetään tilastolliseen analyysiin. Tämä koostuu yleensä yhdestä indeksistä taulukkoa kohden, mutta ei rajoitu siihen.
- Silti, jos yksinkertaista suunnitelmaa ei löydy, etsitään monimutkaisempi suunnitelma. Se sisältää useita indeksejä taulukkoa kohden.
Vaihe 2: Rinnakkaiskäsittely ja optimointi.
- Jos mikään yllä olevista strategioista ei toimi, Optimizer etsii rinnakkaiskäsittelymahdollisuuksia. Tämä riippuu koneen prosessointiominaisuuksista ja kokoonpanosta.
- Jos se ei vieläkään ole mahdollista, viimeinen optimointivaihe alkaa. Nyt lopullisena optimoinnin tavoitteena on löytää kaikki muut mahdolliset vaihtoehdot kyselyn suorittamiseksi parhaalla tavalla. Viimeinen optimointivaihe Algorithms olemme Microsoft Oikeutta.
Kyselyn suorittaja
Kysely suorittajan kutsuja Pääsymenetelmä. Se tarjoaa suoritussuunnitelman suorittamiseen tarvittavalle tiedonhakulogiikalle. Kun tiedot on vastaanotettu Storage Enginestä, tulos julkaistaan protokollatasolle. Lopuksi tiedot lähetetään loppukäyttäjälle.
Varastointi Moottori
Storage Enginen tehtävänä on tallentaa tietoja tallennusjärjestelmään, kuten Disk tai SAN, ja hakea tiedot tarvittaessa. Ennen kuin sukeltaamme syvälle Storage-moottoriin, katsotaanpa, kuinka tiedot tallennetaan tietokanta ja käytettävissä olevat tiedostotyypit.
Tietotiedosto ja laajuus:
Datatiedosto tallentaa tiedot fyysisesti tietosivujen muodossa, jolloin jokainen tietosivu on kooltaan 8 kt, muodostaen SQL Serverin pienimmän tallennusyksikön. Nämä tietosivut on ryhmitelty loogisesti laajuudeksi. Mitään objektia ei ole määritetty sivua SQL Serverissä.
Kohteen ylläpito hoidetaan laajojen kautta. Sivulla on osio nimeltä Sivun otsikko, jonka koko on 96 tavua ja joka sisältää metatietotiedot sivusta, kuten sivun tyyppi, sivunumero, käytetyn tilan koko, vapaan tilan koko ja osoitin seuraavalle sivulle ja edelliselle sivulle. , jne.
Tiedostotyypit
- Ensisijainen tiedosto
- Jokainen tietokanta sisältää yhden ensisijaisen tiedoston.
- Tämä tallentaa kaikki tärkeät tiedot, jotka liittyvät taulukoihin, näkymiin, triggereihin jne.
- Laajennus on.mdf yleensä, mutta voi olla mitä tahansa laajennusta.
- Toissijainen tiedosto
- Tietokanta voi sisältää useita toissijaisia tiedostoja tai ei.
- Tämä on valinnainen ja sisältää käyttäjäkohtaisia tietoja.
- Laajennus on.naf yleensä, mutta voi olla mitä tahansa laajennusta.
- Loki tiedosto
- Tunnetaan myös nimellä Kirjoita eteenpäin -lokit.
- Laajennus on.ldf
- Käytetään tapahtumien hallintaan.
- Tätä käytetään palautumiseen kaikista ei-toivotuista tapauksista. Suorita sitomattomien tapahtumien palautuksen tärkeä tehtävä.
Varastointimoottorissa on 3 osaa; tarkastellaan niitä yksityiskohtaisesti.
Käyttömenetelmä
Se toimii rajapintana kyselyn suorittajan ja Buffer Johtaja/tapahtumalokit.
Access Method itsessään ei suorita mitään.
Ensimmäinen toimenpide on määrittää, onko kysely:
- Valitse lausunto (DDL)
- Ei-valittu lausunto (DDL ja DML)
Pääsymenetelmässä on tuloksesta riippuen seuraavat vaiheet:
- Jos kysely on DDL, SELECT-lause, kysely välitetään Buffer Johtaja jatkokäsittelyä varten.
- Ja jos kysytään jos DDL, NON-SELECT -lause, kysely välitetään Transaction Managerille. Tämä sisältää enimmäkseen UPDATE-lausekkeen.
Buffer Johtaja
Buffer johtaja hallinnoi alla olevien moduulien ydintoimintoja:
- Suunnitelman välimuisti
- Tietojen jäsentäminen: Buffer välimuisti ja tietojen tallennus
- Likainen sivu
Opimme suunnittelemaan, Buffer ja Tietovälimuisti tässä osiossa. Käsittelemme Likaiset sivut Tapahtumat-osiossa.
Suunnitelman välimuisti
- Nykyinen kyselysuunnitelma: Puskurinhallinta tarkistaa, onko suoritussuunnitelma tallennetussa suunnitelmavälimuistissa. Jos Kyllä, käytetään kyselysuunnitelman välimuistia ja siihen liittyvää datavälimuistia.
- Ensimmäisen kerran välimuistisuunnitelma: Mistä olemassa oleva suunnitelman välimuisti tulee? Jos ensimmäistä kertaa kyselyn suoritussuunnitelma on käynnissä ja se on monimutkainen, on järkevää tallentaa se Plane-välimuistiin. Tämä varmistaa nopeamman käytettävyyden, kun seuraavan kerran SQL-palvelin saa saman kyselyn. Kyse ei siis ole muusta kuin itse kyselystä, mikä suunnitelman suoritus tallennetaan, jos se suoritetaan ensimmäistä kertaa.
Tietojen jäsentäminen: Buffer välimuisti ja tietojen tallennus
Buffer johtaja tarjoaa pääsyn tarvittaviin tietoihin. Seuraavat kaksi lähestymistapaa ovat mahdollisia riippuen siitä, onko dataa välimuistissa vai ei:
Buffer Välimuisti – pehmeä jäsennys:
Buffer Manager etsii tietoja sisään Buffer tietovälimuistissa. Jos niitä on, Query Executor käyttää näitä tietoja. Tämä parantaa suorituskykyä, koska I/O-toimintojen määrä vähenee haettaessa tietoja välimuistista verrattuna tietojen noutamiseen tietovarastosta.
Tietojen tallennus – Kova jäsennys:
Jos tietoja ei löydy Buffer Tarvittava johtaja Data etsitään Data Storagesta. If myös tallentaa tietoja datavälimuistiin tulevaa käyttöä varten.
Likainen sivu
Se on tallennettu Transaction Managerin käsittelylogiikkaksi. Opimme tarkemmin Transaction Manager -osiossa.
Tapahtuman johtaja
Transaction Manager käynnistyy, kun pääsymenetelmä määrittää, että kysely on Non-Select-lauseke.
Lokien hallinta
- Log Manager pitää kirjaa kaikista järjestelmässä tehdyistä päivityksistä tapahtumalokien lokien kautta.
- Lokeissa on Kirjaa järjestysnumeron tapahtumatunnuksella ja tietojen muutostietueella.
- Tätä käytetään seuraamiseen Tapahtuma sitoutunut ja tapahtuman palautus.
Lukon hallinta
- Tapahtuman aikana siihen liittyvät tiedot Data Storagessa ovat lukitustilassa. Tämän prosessin hoitaa Lock Manager.
- Tämä prosessi varmistaa tietojen johdonmukaisuus ja eristäminen. Tunnetaan myös ACID-ominaisuuksina.
Toteutusprosessi
- Log Manager aloittaa kirjaamisen ja Lock Manager lukitsee liittyvät tiedot.
- Tietojen kopiota säilytetään Buffer kätkö.
- Kopio päivitettävistä tiedoista säilyy lokipuskurissa ja kaikki tapahtumat päivittävät tiedot Datapuskurissa.
- Tietoa tallentavat sivut tunnetaan myös nimellä Likaiset sivut.
- Tarkistuspiste ja eteenpäinkirjoitus: Tämä prosessi suoritetaan ja merkitse kaikki sivut likaisista sivuista levylle, mutta sivu pysyy välimuistissa. Taajuus on noin 1 juoksu minuutissa. Mutta sivu työnnetään ensin lokitiedoston tietosivulle Buffer Hirsi. Tämä tunnetaan nimellä Kirjoita eteenpäin kirjaaminen.
- Laiska kirjoittaja: Likainen sivu voi jäädä muistiin. Kun SQL-palvelin havaitsee valtavan kuormituksen ja Buffer muistia tarvitaan uutta tapahtumaa varten, se vapauttaa likaiset sivut välimuistista. Se toimii LRU – Viimeksi käytetty algoritmi sivun puhdistamiseen puskurivarannosta levylle.
Yhteenveto
- Kolmen tyyppinen asiakaspalvelin ArchiTecture olemassa: 1) Jaettu muisti 2) TCP/IP 3) Nimetyt putket
- TDS, jonka on kehittänyt Sybase ja jonka nyt omistaa Microsoft, on paketti, joka on kapseloitu verkkopaketteihin tiedonsiirtoa varten asiakaskoneelta palvelinkoneelle.
- Relaatiomoottori sisältää kolme pääkomponenttia:CMD-jäsennys: Tämä on vastuussa syntaktisista ja semanttisista virheistä ja luo lopulta kyselypuun.Optimoija: Optimoijan tehtävänä on löytää halvin, ei paras, kustannustehokas toteutussuunnitelma.
Kyselyn suorittaja: Kyselyn suorittaja kutsuu Access Methodia ja tarjoaa suoritussuunnitelman suorittamiseen tarvittavalle tiedonhakulogiikalle.
- On olemassa kolmenlaisia tiedostoja: Ensisijainen tiedosto, Toissijainen tiedosto ja Lokitiedostot.
- Varastointimoottori: Sisältää seuraavat tärkeät komponentitPääsymenetelmä: Tämä komponentti Määrittää, onko kysely Select vai Non-Select -lauseke. Kutsuu Buffer ja Transfer Manager vastaavasti.Buffer Manager: Buffer Manager hallitsee Plan Cachen, Data Parsingin ja Dirty Pagen ydintoimintoja.
Tapahtuman johtaja: Se hallinnoi ei-valitsevia tapahtumia loki- ja lukitusjohtajien avulla. Helpottaa myös Write Ahead -kirjauksen ja Lazy-kirjoittajien tärkeää toteutusta.