MS SQL Server je arhitektura klijent-poslužitelj. Proces MS SQL Server započinje klijentskom aplikacijom koja šalje zahtjev. SQL Server prihvaća, obrađuje i odgovara na zahtjev obrađenim podacima. Razmotrimo detaljno cjelokupnu arhitekturu prikazanu u nastavku:
Kao što donji dijagram prikazuje, postoje tri glavne komponente u arhitekturi SQL Server:
- Sloj protokola
- Relacijski motor
- Storage Engine
Razmotrimo detaljno o sva tri gore navedena glavna modula. U ovom ćete tutorijalu naučiti.
- Sloj protokola - SNI
- Zajedničko sjećanje
- TCP / IP
- Imenovane cijevi
- Što je TDS?
- Relacijski motor
- CMD parser
- Optimizator
- Izvršitelj upita
- Storage Engine
- Vrste datoteka
- Način pristupa
- Upravitelj međuspremnika
- Planiraj predmemoriju
- Raščlanjivanje podataka: Predmemorija međuspremnika i pohrana podataka
- Upravitelj transakcija
Sloj protokola - SNI
MS SQL SERVER PROTOCOL LAYER podržava 3 vrste arhitekture klijentskog poslužitelja. Započet ćemo s " Arhitekturom tri tipa klijentskog poslužitelja" koju MS SQL Server podržava.
Zajedničko sjećanje
Preispitajmo scenarij razgovora rano jutro.
MAMA i TOM - Ovdje su Tom i njegova mama bili na istom logičnom mjestu, tj. U svom domu. Tom je mogao zatražiti kavu, a mama je poslužila vruću.
MS SQL SERVER - Ovdje MS SQL poslužitelj nudi PROTOKOL DIJELJENE PAMĆI . Ovdje se KLIJENT i MS SQL poslužitelj izvode na istom stroju. Oboje mogu komunicirati putem protokola zajedničke memorije.
Analogija: Omogućuje mapiranje entiteta u gornja dva scenarija. Toma možemo lako preslikati na klijenta, mamu na SQL poslužitelj, Home to Machine i verbalnu komunikaciju na protokol zajedničke memorije.
Sa stola za konfiguraciju i instalaciju:
Za povezivanje s lokalnim DB-om - u programu SQL Management Studio opcija "Ime poslužitelja" može biti
"."
"lokalni domaćin"
"127.0.0.1"
"Stroj \ Instance"
TCP / IP
Sad razmislite navečer, Tom je raspoložen za zabavu. Želi kavu naručenu iz poznatog kafića. Kavana se nalazi 10 km od njegove kuće.
Tom i Starbuck su ovdje na različitim fizičkim mjestima. Tom kod kuće i Starbucks na prometnoj tržnici. Komuniciraju putem mobilne mreže. Slično tome, MS SQL SERVER pruža mogućnost interakcije putem TCP / IP protokola, gdje su CLIENT i MS SQL Server međusobno udaljeni i instalirani na zasebnom stroju.
Analogija: Omogućuje mapiranje entiteta u gornja dva scenarija. Toma možemo lako preslikati na klijenta, Starbuck na SQL poslužitelj, dom / tržište na udaljeno mjesto i na kraju celularnu mrežu na TCP / IP protokol.
Bilješke sa stola za konfiguraciju / instalaciju:
- U SQL Management Studiju - Za povezivanje putem TCP \ IP, opcija "Naziv poslužitelja" mora biti "Strojna \ Instanca poslužitelja."
- SQL poslužitelj koristi port 1433 u TCP / IP.
Imenovane cijevi
Sad napokon noću, Tom je htio popiti svijetlozeleni čaj koji je njezina susjeda Sierra jako dobro pripremila.
Ovdje Tom i njegov susjed , Sierra, u istoj fizičkoj lokaciji, kao svaki drugi susjed. Komuniciraju putem Intra mreže. Slično tome, MS SQL SERVER pruža mogućnost interakcije putem protokola Named Pipe . Ovdje su KLIJENT i MS SQL SERVER povezani putem LAN-a .
Analogija: Omogućuje mapiranje entiteta u gornja dva scenarija. Toma možemo lako preslikati na klijenta, Sierru na SQL poslužitelj, susjeda na LAN i konačno Intra mrežu na Named Pipe Protocol.
Bilješke sa stola za konfiguraciju / instalaciju:
- Za povezivanje putem imenovane cijevi. Ova je opcija onemogućena prema zadanim postavkama i mora je omogućiti SQL Configuration Manager.
Što je TDS?
Sad kad znamo da postoje tri vrste arhitekture klijent-poslužitelj, omogućuje nam da pogledamo TDS:
- TDS je skraćenica od Tabelarni tok podataka.
- Sva 3 protokola koriste TDS pakete. TDS je enkapsuliran u mrežne pakete. To omogućuje prijenos podataka s klijentskog stroja na poslužiteljski stroj.
- TDS je prvi razvio Sybase, a sada je u vlasništvu Microsofta
Relacijski motor
Relacijski mehanizam poznat je i kao procesor upita. Sadrži komponente SQL Servera koje određuju što točno upit treba učiniti i kako to najbolje može učiniti. Odgovorna je za izvršavanje korisničkih upita zahtijevajući podatke iz mehanizma za pohranu i obrađujući rezultate koji se vraćaju.
Kao što je prikazano na Arhitektonskom dijagramu, postoje 3 glavne komponente relacijskog motora. Proučimo komponente detaljno:
CMD parser
Podaci jednom primljeni iz sloja protokola zatim se prosljeđuju u relacijski stroj. "CMD Parser" prva je komponenta Relacijskog mehanizma koja prima podatke upita. Glavni posao CMD Parsera je provjera upita za sintaksičku i semantičku pogrešku. Konačno, generira stablo upita . Razgovarajmo detaljno.
Sintaktička provjera:
- Kao i svaki drugi programski jezik, MS SQL također ima unaprijed definirani skup ključnih riječi. Također, SQL Server ima vlastitu gramatiku koju SQL poslužitelj razumije.
- SELECT, INSERT, UPDATE i mnogi drugi pripadaju MS SQL unaprijed definiranim popisima ključnih riječi.
- CMD Parser vrši sintaktičku provjeru. Ako se unos korisnika ne pridržava ovih sintaksa jezika ili gramatičkih pravila, vraća pogrešku.
Primjer: Recimo da je Rus otišao u japanski restoran. Naručuje brzu hranu na ruskom jeziku. Nažalost, konobar razumije samo japanski. Koji bi bio najočitiji rezultat?
Odgovor je - konobar ne može dalje obrađivati narudžbu.
Ne bi trebalo postojati nikakvo odstupanje u gramatici ili jeziku koje SQL poslužitelj prihvaća. Ako postoje, SQL poslužitelj ga ne može obraditi i stoga će vratiti poruku o pogrešci.
O MS SQL upitu saznat ćemo više u nadolazećim vodičima. Ipak, uzmite u obzir najosnovniju sintaksu upita kao
SELECT * from;
Sada, da biste shvatili što čini sintaksika, recite da li korisnik pokreće osnovni upit kao u nastavku:
SELECR * from
Imajte na umu da je umjesto "SELECT" korisnik upisao "SELECR."
Rezultat: Analizator CMD raščlanit će ovu izjavu i izbacit će poruku o pogrešci. Kako "SELECR" ne slijedi unaprijed definirano ime i gramatiku ključne riječi. Ovdje je CMD Parser očekivao "SELECT".
Semantička provjera:
- To izvodi Normalizer .
- U svom najjednostavnijem obliku provjerava postoje li u stupcu naziv stupca i naziv tablice. A ako postoji, vežite ga za Query. Ovo je također poznato kao Vezanje .
- Složenost se povećava kada korisnički upiti sadrže VIEW. Normalizer izvodi zamjenu s interno pohranjenom definicijom pogleda i mnogo više.
Shvatimo to uz pomoć donjeg primjera -
SELECT * from USER_ID
Rezultat: Analizator CMD raščlanit će ovu izjavu za semantičku provjeru. Analizator će poslati poruku o pogrešci jer Normalizer neće pronaći traženu tablicu (USER_ID) jer ne postoji.
Stvori stablo upita:
- Ovaj korak generira različito stablo izvršenja u kojem se upit može pokrenuti.
- Imajte na umu da sva različita stabla imaju isti željeni izlaz.
Optimizator
Posao optimizatora je stvoriti plan izvršenja za korisnikov upit. Ovo je plan koji će odrediti kako će se izvršavati korisnički upit.
Imajte na umu da nisu svi upiti optimizirani. Optimizacija se vrši za naredbe DML (jezik za promjenu podataka) poput SELECT, INSERT, DELETE i UPDATE. Takvi se upiti prvo označavaju, a zatim šalju optimizatoru. DDL naredbe poput CREATE i ALTER nisu optimizirane, već su umjesto toga kompilirane u interni obrazac. Trošak upita izračunava se na temelju čimbenika kao što su uporaba CPU-a, korištenje memorije i ulazno / izlazne potrebe.
Uloga optimizatora je pronaći najjeftiniji, a ne najbolji, isplativ plan izvršenja.
Prije nego što skočimo u tehničke detalje Optimizer-a, razmotrite donji primjer iz stvarnog života:
Primjer:
Recimo, želite otvoriti mrežni bankovni račun. Već znate za jednu banku kojoj treba najviše 2 dana da otvori račun. Ali, također imate popis 20 drugih banaka, što može potrajati manje od 2 dana. Možete započeti interakciju s tim bankama kako biste utvrdili kojim bankama treba manje od 2 dana. Sada možda nećete pronaći banku koja traje manje od 2 dana, a dodatno je izgubljeno vrijeme zbog same aktivnosti pretraživanja. Bilo bi bolje otvoriti račun kod same prve banke.
Zaključak: Važnije je odabrati pametno. Da budemo precizni, odaberite koja je opcija najbolja, a ne najjeftinija.
Slično tome, MS SQL Optimizer radi na ugrađenim iscrpnim / heurističkim algoritmima. Cilj je smanjiti vrijeme izvođenja upita. Svi algoritmi za optimizaciju svojstvo su Microsofta i tajna. Iako su u nastavku koraci na visokoj razini koje je izveo MS SQL Optimizer. Pretrage optimizacije slijede tri faze kako je prikazano na donjem dijagramu:
Faza 0: Traženje trivijalnog plana:
- To je također poznato kao faza pred-optimizacije .
- U nekim slučajevima mogao bi postojati samo jedan praktičan, izvediv plan, poznat kao trivijalan plan. Nema potrebe za stvaranjem optimiziranog plana. Razlog je taj što bi traženje više rezultiralo pronalaženje istog plana izvršenja. To isto uz dodatne troškove traženja optimiziranog plana koji uopće nisu bili potrebni.
- Ako nema Trivial plana pronašao, a zatim 1 st faza počinje.
Faza 1: Traženje planova obrade transakcija
- To uključuje potragu za jednostavnim i složenim planom .
- Jednostavno pretraživanje plana: Prošli podaci stupca i indeksa koji su uključeni u upit, koristit će se za statističku analizu. To se obično sastoji, ali nije ograničeno na jedan indeks po tablici.
- Ipak, ako jednostavni plan nije pronađen, pretražuje se složeniji plan. Uključuje višestruki indeks po tablici.
Faza 2: Paralelna obrada i optimizacija.
- Ako niti jedna od gore navedenih strategija ne uspije, Optimizer traži mogućnosti paralelne obrade. To ovisi o mogućnostima obrade stroja i konfiguraciji.
- Ako to još uvijek nije moguće, započinje završna faza optimizacije. Sada je konačni cilj optimizacije pronaći sve druge moguće mogućnosti za izvršavanje upita na najbolji način. Algoritmi faze konačne optimizacije su Microsoftova vlastitost.
Izvršitelj upita
Izvršitelj upita poziva metodu pristupa. Pruža plan izvršenja za logiku dohvaćanja podataka potrebnu za izvršavanje. Jednom kad se podaci prime iz Storage Enginea, rezultat se objavljuje na sloju Protocol. Napokon, podaci se šalju krajnjem korisniku.
Storage Engine
Posao Storage Enginea je pohranjivanje podataka u sustav za pohranu poput diska ili SAN-a i dohvaćanje podataka po potrebi. Prije nego što dublje zaronimo u Storage engine, pogledajmo kako se podaci pohranjuju u bazu podataka i vrstu dostupnih datoteka.
Datoteka i opseg podataka:
Datoteka podataka fizički pohranjuje podatke u obliku stranica podataka, pri čemu svaka podatkovna stranica ima veličinu od 8 KB, što čini najmanju jedinicu za pohranu u SQL Serveru. Te su stranice podataka logički grupirane da tvore ekstenzije. Nijednom objektu nije dodijeljena stranica u SQL Serveru.
Održavanje objekta vrši se putem ekstenzija. Stranica ima odjeljak pod nazivom Zaglavlje stranice, veličine 96 bajtova, koji sadrži podatke o metapodacima o stranici, poput vrste stranice, broja stranice, veličine korištenog prostora, veličine slobodnog prostora i pokazivača na sljedeću stranicu i prethodnu stranicu. itd.
Vrste datoteka
- Primarna datoteka
- Svaka baza podataka sadrži jednu primarnu datoteku.
- Ovdje se pohranjuju svi važni podaci koji se odnose na tablice, poglede, okidače itd.
- Proširenje je. mdf obično, ali može biti bilo kojeg proširenja.
- Sekundarna datoteka
- Baza podataka može sadržavati ili ne sadržavati više sekundarnih datoteka.
- To nije obavezno i sadrži podatke specifične za korisnika.
- Proširenje je. ndf obično, ali može biti bilo kojeg produžetka.
- Datoteka zapisnika
- Poznati i kao Dnevnici pisanja unaprijed.
- Proširenje je. ldf
- Koristi se za upravljanje transakcijama.
- To se koristi za oporavak od neželjenih slučajeva. Izvršite važan zadatak vraćanja na neobrađene transakcije.
Storage Engine ima 3 komponente; razmotrimo ih detaljno.
Način pristupa
Djeluje kao sučelje između izvršitelja upita i Upravitelja međuspremnika / Dnevnika transakcija.
Način pristupa sam po sebi ne izvršava.
Prva radnja je utvrditi je li upit:
- Odaberite izjavu (DDL)
- Izbor koji nije odabran (DDL i DML)
Ovisno o rezultatu, metoda pristupa poduzima sljedeće korake:
- Ako je upit DDL , SELECT naredba, upit se prosljeđuje Upravitelju međuspremnika na daljnju obradu.
- A ako je upit DDL, izraz NON-SELECT , upit se prosljeđuje Transaction Manageru. To uglavnom uključuje UPDATE izraz.
Upravitelj međuspremnika
Upravitelj međuspremnika upravlja osnovnim funkcijama za donje module:
- Planiraj predmemoriju
- Raščlanjivanje podataka: Predmemorija međuspremnika i pohrana podataka
- Prljava stranica
U ovom ćemo odjeljku naučiti predmemoriju planiranja, međuspremnika i podataka. Pokrivat ćemo Prljave stranice u odjeljku Transakcija.
Planiraj predmemoriju
- Postojeći plan upita: Upravitelj međuspremnika provjerava postoji li plan izvršenja u pohranjenoj predmemoriji plana. Ako je odgovor da, tada se koristi predmemorija plana upita i pripadajuća predmemorija podataka.
- Prvi put predmemorija: odakle dolazi postojeća predmemorija plana?
Ako se prvi put izvodi plan za izvršavanje upita i složen je, ima smisla pohraniti ga u predmemoriju Plane. To će osigurati bržu dostupnost kada sljedeći put SQL poslužitelj dobije isti upit. Dakle, to nije ništa drugo nego sam upit koje izvršenje plana se pohranjuje ako se izvodi prvi put.
Raščlanjivanje podataka: Predmemorija međuspremnika i pohrana podataka
Upravitelj međuspremnika omogućuje pristup potrebnim podacima. Moguća su dva pristupa, ovisno o tome postoje li podaci u predmemoriji podataka ili ne:
Predmemorija međuspremnika - Meko raščlanjivanje:
Upravitelj međuspremnika traži podatke u međuspremniku u predmemoriji podataka. Ako su prisutni, izvršitelj upita koristi ove podatke. To poboljšava izvedbu jer se broj I / O operacija smanjuje prilikom dohvaćanja podataka iz predmemorije u usporedbi s dohvaćanjem podataka iz pohrane podataka.
Pohrana podataka - teško raščlanjivanje:
Ako podaci nisu prisutni u Upravitelju međuspremnika, nego što je potrebno, podaci se pretražuju u Pohrani podataka. Ako također pohranjuje podatke u predmemoriju podataka za buduću upotrebu.
Prljava stranica
Pohranjen je kao logika obrade Transaction Manager-a. Detaljno ćemo naučiti u odjeljku Transaction Manager.
Upravitelj transakcija
Transaction Manager poziva se kada metoda pristupa utvrdi da je Query izraz koji nije odabran.
Upravitelj dnevnika
- Log Manager vodi evidenciju svih ažuriranja izvršenih u sustavu putem dnevnika u Dnevnicima transakcija.
- Zapisnici imaju redni broj zapisnika s ID-om transakcije i zapisom izmjene podataka .
- To se koristi za praćenje izvršenih transakcija i vraćanja transakcija .
Lock Manager
- Tijekom Transakcije povezani podaci u Pohrani podataka nalaze se u zaključanom stanju. Ovim postupkom upravlja Lock Manager.
- Ovaj postupak osigurava dosljednost i izolaciju podataka . Poznata i kao ACID svojstva.
Proces izvršenja
- Log Manager započinje bilježenje, a Lock Manager zaključava povezane podatke.
- Kopija podataka čuva se u predmemoriji međuspremnika.
- Kopija podataka koja bi se trebala ažurirati održava se u međuspremniku dnevnika, a svi događaji ažuriraju podatke u međuspremniku podataka.
- Stranice koje pohranjuju podatke poznate su i pod nazivom Prljave stranice .
- Kontrolna točka i zapisivanje unaprijed: Ovaj se postupak izvodi i označava svu stranicu od Prljavih stranica do Diska, ali stranica ostaje u predmemoriji. Frekvencija je približno 1 pokretanje u minuti. Ali stranica se prvo gura na stranicu podataka datoteke dnevnika iz dnevnika međuspremnika. Ovo je poznato kao Zapisivanje unaprijed.
- Lijeni pisac: Prljava stranica može ostati u sjećanju. Kad SQL poslužitelj primijeti veliko opterećenje i kad je za novu transakciju potrebna memorija međuspremnika, oslobađa Prljave stranice iz predmemorije. Djeluje na LRU - Najmanje nedavno korišten algoritam za čišćenje stranice od spremišta spremišta na disk.
Sažetak:
- Postoje tri vrste arhitekture klijentskog poslužitelja: 1) zajednička memorija 2) TCP / IP 3) imenovane cijevi
- TDS, koji je razvio Sybase, a sada je u vlasništvu Microsofta, paket je koji je enkapsuliran u mrežne pakete za prijenos podataka s klijentskog računala na poslužiteljski stroj.
- Relacijski motor sadrži tri glavne komponente:
CMD Parser: Ovo je odgovorno za sintaktičku i semantičku pogrešku i konačno generira stablo upita.
Optimizer: Uloga optimizatora je pronaći najjeftiniji, a ne najbolji, isplativ plan izvršenja.
Izvršitelj upita: Izvršitelj upita poziva pristupnu metodu i pruža plan izvršenja za logiku dohvaćanja podataka potrebnu za izvršavanje.
- Postoje tri vrste datoteka Primarna datoteka, Sekundarna datoteka i Dnevnik.
- Storage Engine: Sadrži sljedeće važne komponente
Način pristupa: Ova komponenta Odredite je li upit Izbor ili Izbor koji nije odabran. Priziva me uspremnik i upravitelja prijenosa u skladu s tim.
Upravitelj međuspremnika: Upravitelj međuspremnika upravlja osnovnim funkcijama za predmemoriju plana, raščlanjivanje podataka i prljavu stranicu.
Upravitelj transakcija: Upravlja transakcijama koje nisu odabrane uz pomoć upravitelja dnevnika i zaključavanja. Također, olakšava važnu implementaciju evidentiranja Write Ahead i Lazy Writers.