MS SQL Server on kliendi-serveri arhitektuur. MS SQL Serveri protsess algab kliendirakenduse päringu saatmisega. SQL Server aktsepteerib, töötleb ja vastab päringule töödeldud andmetega. Arutleme üksikasjalikult kogu allpool näidatud arhitektuuri:
Nagu allpool toodud diagramm kujutab, on SQL Serveri arhitektuuris kolm peamist komponenti:
- Protokollikiht
- Relatsioonimootor
- Salvestusmootor
Arutame üksikasjalikult kõigi kolme ülaltoodud peamise mooduli üle. Selles õpetuses saate teada.
- Protokollikiht - SNI
- Jagatud mälu
- TCP / IP
- Nimega torud
- Mis on TDS?
- Relatsioonimootor
- CMD parser
- Optimeerija
- Päringu täitja
- Salvestusmootor
- Failitüübid
- Juurdepääsumeetod
- Puhvrihaldur
- Plaani vahemälu
- Andmete parsimine: puhvri vahemälu ja andmete salvestamine
- Tehingute haldur
Protokollikiht - SNI
MS SQL-i serveri protokollikiht toetab kolme tüüpi kliendiserveri arhitektuuri. Alustame " Kolm tüüpi kliendiserveri arhitektuurist", mida MS SQL Server toetab.
Jagatud mälu
Vaatame üle varahommikuse vestluse stsenaariumi.
EMA ja TOM - Siin olid Tom ja tema ema samas loogilises kohas, st oma kodus. Tom suutis kohvi küsida ja ema suutis seda kuumalt pakkuda.
MS SQL Server - siin pakub MS SQL server JAGATUD MÄLU PROTOKOLLI . Siin töötab KLIENT ja MS SQL server samas masinas. Mõlemad saavad suhelda jagatud mälu protokolli kaudu.
Analoogia: võimaldab kaardistada üksusi ülaltoodud kahes stsenaariumis. Saame hõlpsalt kaardistada Tomi kliendi, ema SQL-serveri, kodu-masina ja verbaalse suhtluse jagatud mäluprotokolliga.
Konfigureerimise ja installimise töölaualt:
Kohaliku DB-ga ühenduse loomiseks - SQL Management Studios võiks olla valik "Serveri nimi"
"."
"kohalik host"
"127.0.0.1"
"Machine \ instance"
TCP / IP
Mõelge nüüd õhtul, Tom on peomeeleolus. Ta soovib tuntud kohvikust tellitud kohvi. Kohvik asub tema kodust 10 km kaugusel.
Siin on Tom ja Starbuck erinevas füüsilises asukohas. Tom kodus ja Starbucks hõivatud turul. Nad suhtlevad mobiilsidevõrgu kaudu. Samamoodi pakub MS SQL Server võimalust suhelda TCP / IP-protokolli kaudu, kus KLIENT ja MS SQL Server on üksteisest kaugel ja installitakse eraldi masinasse.
Analoogia: võimaldab kaardistada üksusi ülaltoodud kahes stsenaariumis. Saame hõlpsalt kaardistada Tomi kliendini, Starbucki SQL-serverisse, kodu / turuplatsi kaugesse asukohta ja lõpuks mobiilsidevõrgu TCP / IP-protokolli.
Märkused konfiguratsiooni / installi töölaualt:
- SQL Management Studios - TCP \ IP kaudu ühenduse loomiseks peab "Serveri nimi" olema "Masina \ serveri eksemplar".
- SQL server kasutab TCP / IP-s porti 1433.
Nimega torud
Nüüd lõpuks öösel tahtis Tom saada helerohelist teed, mida tema naaber Sierra väga hästi valmistas.
Siin on Tom ja tema naaber Sierra samas füüsilises asukohas, olles üksteise naaber. Nad suhtlevad sisevõrgu kaudu . Samamoodi pakub MS SQL Server võimalust suhelda Named Pipe protokolli kaudu. Siin on KLIENT ja MS SQL Server ühendatud LAN-i kaudu .
Analoogia: võimaldab kaardistada üksusi ülaltoodud kahes stsenaariumis. Saame Tomi hõlpsalt kaardistada kliendiga, Sierra SQL-serveriga, naaber LAN-iga ja lõpuks sisevõrk Named Pipe Protocoliga.
Märkused konfiguratsiooni / installi töölaualt:
- Nimega toru kaudu ühendamiseks. See valik on vaikimisi keelatud ja selle peab lubama SQL Configuration Manager.
Mis on TDS?
Nüüd, kui teame, et klient-server arhitektuuri on kolme tüüpi, võimaldame meil pilgu heita TDS-ile:
- TDS tähistab tabeliandmete voogu.
- Kõik kolm protokolli kasutavad TDS-pakette. TDS on kapseldatud võrgupakettidesse. See võimaldab andmete edastamist kliendimasinast serverimasinasse.
- TDS töötati esmakordselt välja Sybase poolt ja nüüd kuulub see Microsoftile
Relatsioonimootor
Relatsioonimootorit tuntakse ka kui päringuprotsessorit. Sellel on SQL Serveri komponendid, mis määravad, mida päring täpselt teha peab ja kuidas seda kõige paremini teha. Ta vastutab kasutajapäringute täitmise eest, taotledes andmeid salvestusmootorilt ja töödeldes tagastatud tulemusi.
Nagu on kujutatud arhitektuuriskeemil , on Relatsioonimootoril 3 peamist komponenti . Uurime komponente üksikasjalikult:
CMD parser
Pärast protokollikihist saadud andmeid edastatakse seejärel Relational Engine'ile. "CMD parser" on Relatsioonimootori esimene komponent, mis päringu andmeid vastu võtab. CMD Parseri peamine ülesanne on kontrollida süntaktiliste ja semantiliste vigade päringut . Lõpuks genereerib see päringupuu . Arutame üksikasjalikult.
Süntaktiline kontroll:
- Nagu igal teisel programmeerimiskeelel, on ka MS SQLil eelnevalt määratletud märksõnade komplekt. Samuti on SQL Serveril oma grammatika, millest SQL server saab aru.
- SELECT, INSERT, UPDATE ja paljud teised kuuluvad MS SQL-i eelnevalt määratletud märksõnaloenditesse.
- CMD parser teeb süntaktilist kontrolli. Kui kasutajate sisend ei järgi neid keele süntaksi- või grammatikareegleid, tagastab see tõrke.
Näide: Oletame, et venelane käis Jaapani restoranis. Ta tellib vene keeles kiirtoitu. Kahjuks saab kelner aru ainult jaapani keelest. Mis oleks kõige ilmsem tulemus?
Vastus on - kelner ei suuda tellimust edasi töödelda.
Grammatikas ega keeles, mida SQL server aktsepteerib, ei tohiks olla kõrvalekaldeid. Kui neid on, ei saa SQL server seda töödelda ja tagastab seega tõrketeate.
MS SQL-i päringu kohta saame rohkem teada järgmistest õpetustest. Mõelge allpool kõige põhilisemale päringusüntaksile
SELECT * from;
Nüüd, et mõista, mida süntaktika teeb, öelge, kas kasutaja käivitab põhipäringu järgmiselt:
SELECR * from
Pange tähele, et „SELECT” asemel sisestas kasutaja „SELECR”.
Tulemus: CMD parser sõelub selle lause ja viskab tõrketeate. Kuna "SELECR" ei järgi eelnevalt määratletud märksõna nime ja grammatikat. Siin ootas CMD parser "SELECT".
Semantiline kontroll:
- Seda teostab Normalizer .
- Lihtsamas vormis kontrollib see, kas skeemil on olemas veeru nimi, küsitav tabeli nimi. Ja kui see on olemas, siduge see päringuga. Seda nimetatakse ka siduvaks .
- Keerukus suureneb, kui kasutaja päringud sisaldavad VIEW. Normalizer täidab sisemiselt salvestatud vaate määratlusega ja palju muud.
Mõistame seda allpool toodud näite abil -
SELECT * from USER_ID
Tulemus: CMD parser sõelub selle lause semantilise kontrolli jaoks. Parser viskab veateate, kuna Normalizer ei leia soovitud tabelit (USER_ID), kuna seda pole olemas.
Loo päringupuu:
- See samm loob erineva täitmispuu, milles saab päringut käivitada.
- Pange tähele, et kõigil erinevatel puudel on sama soovitud väljund.
Optimeerija
Optimeerija tööks on kasutaja päringu täitmisplaani loomine. See on plaan, mis määrab, kuidas kasutaja päring täidetakse.
Pange tähele, et kõiki päringuid pole optimeeritud. Optimeerimine on tehtud DML (Data Modification Language) käskude jaoks, näiteks SELECT, INSERT, DELETE ja UPDATE. Sellised päringud märgitakse kõigepealt ja seejärel saadetakse optimeerijale. DDL-i käske nagu CREATE ja ALTER ei optimeerita, vaid need kompileeritakse hoopis sisemisse vormi. Päringu maksumus arvutatakse selliste tegurite põhjal nagu protsessori kasutamine, mälukasutus ning sisend- ja väljundvajadused.
Optimeerija ülesanne on leida odavaim, mitte parim, kulutõhus teostusplaan.
Enne kui läheme optimeerija tehnilisematesse üksikasjadesse, kaaluge allpool tegeliku näite näidet:
Näide:
Oletame, et soovite avada veebipanga konto. Te juba teate ühe panga kohta, mille konto avamiseks kulub maksimaalselt 2 päeva. Kuid teil on ka 20 teise panga nimekiri, mis võib võtta vähem kui 2 päeva või mitte. Võite alustada nende pankadega suhtlemist, et teha kindlaks, millistel pankadel kulub vähem kui 2 päeva. Nüüd ei pruugi te leida panka, mis võtab vähem kui 2 päeva, ja otsingutegevuse tõttu on kaotatud täiendav aeg. Parem oleks olnud avada konto esimeses pangas endas.
Kokkuvõte: Tähtsam on valida tark. Täpsustuseks valige, milline variant on parim, mitte kõige odavam.
Samamoodi töötab MS SQL Optimizer sisseehitatud ammendavate / heuristiliste algoritmidega. Eesmärk on minimeerida päringu käitamise aega. Kõik optimeerija algoritmid on Microsofti sobivus ja saladus. Kuigi , allpool on kõrgetasemelise samme astub MS SQL Optimizer. Optimeerimise otsingud toimuvad kolmel etapil, nagu on näidatud alloleval diagrammil:
0. etapp: prooviversiooni otsimine:
- Seda nimetatakse ka eeloptimeerimise etapiks .
- Mõnel juhul võiks olla ainult üks praktiline ja toimiv plaan, mida nimetatakse tühiseks plaaniks. Optimeeritud plaani pole vaja luua. Põhjus on see, et kui rohkem otsida, leitaks sama tööaja täitmisplaan. Ka optimeeritud plaani otsimise lisakuludega, mida polnud üldse vaja.
- Kui ei triviaalne kava leitud, siis 1 silmus etapp algab.
1. etapp: tehingute töötlemise plaanide otsimine
- See hõlmab lihtsa ja keeruka plaani otsimist .
- Lihtne plaanipärane otsing: päringus osalenud veeru ja indeksi varasemaid andmeid kasutatakse statistiliseks analüüsiks. See koosneb tavaliselt, kuid ei piirdu ühe indeksiga tabeli kohta.
- Siiski, kui lihtsat plaani ei leita, siis otsitakse keerukamat plaani. See hõlmab mitu indeksit tabeli kohta.
2. etapp: paralleelne töötlemine ja optimeerimine.
- Kui ükski ülaltoodud strateegiatest ei toimi, otsib Optimizer paralleelse töötlemise võimalusi. See sõltub Masina töötlemisvõimalustest ja konfiguratsioonist.
- Kui see pole ikka veel võimalik, algab viimane optimeerimise etapp. Nüüd on optimeerimise viimane eesmärk leida kõik muud võimalikud võimalused päringu parimal viisil täitmiseks. Lõpliku optimeerimise faasi algoritmid on Microsoft Propriety.
Päringu täitja
Päringu täitekõnede juurdepääsumeetod. See annab täitmiseks vajaliku andmete toomise loogika täitmisplaani. Kui Storage Engine'ilt on andmed saadud, avaldatakse tulemus protokollikihis. Lõpuks saadetakse andmed lõpptarbijale.
Salvestusmootor
Storage Engine'i ülesanne on andmete salvestamine sellisesse mälusüsteemi nagu Disk või SAN ja vajadusel andmete hankimine. Enne kui läheme põhjalikult sukelduma mälumootorisse, vaatame, kuidas andmeid andmebaasis salvestatakse, ja saadaolevate failide tüüpi.
Andmefail ja ulatus:
Andmefail salvestab andmeid füüsiliselt andmelehtede kujul, kusjuures iga andmelehe suurus on 8KB, moodustades SQL Serveri väikseima salvestusüksuse. Need andmelehed on loogiliselt rühmitatud, et moodustada ulatus. SQL Serveris pole lehele määratud ühtegi objekti.
Objekti hooldamine toimub ulatusega. Sellel lehel on jaotis nimega Lehe päis suurusega 96 baiti, mis sisaldab lehe metaandmete teavet, näiteks Lehe tüüp, Lehe number, Kasutatud ruumi suurus, Vaba ruumi suurus ja Kursor järgmisele ja eelmisele lehele , jne.
Failitüübid
- Esmane fail
- Igas andmebaasis on üks esmane fail.
- See salvestab kõik olulised tabelite, vaadete, käivitajate jms andmed.
- Pikendamine on. mdf tavaliselt, kuid võib olla mis tahes laiendiga.
- Teisene fail
- Database may or may not contains multiple Secondary files.
- This is optional and contain user-specific data.
- Extension is .ndf usually but can be of any extension.
- Log file
- Also known as Write ahead logs.
- Extension is .ldf
- Used for Transaction Management.
- This is used to recover from any unwanted instances. Perform important task of Rollback to uncommitted transactions.
Storage Engine has 3 components; let's look into them in detail.
Access Method
It acts as an interface between query executor and Buffer Manager/Transaction Logs.
Access Method itself does not do any execution.
The first action is to determine whether the query is:
- Select Statement (DDL)
- Non- Select Statement (DDL & DML)
Depending upon the result, the Access Method takes the following steps:
- If the query is DDL, SELECT statement, the query is pass to the Buffer Manager for further processing.
- And if query if DDL, NON-SELECT statement, the query is pass to Transaction Manager. This mostly includes the UPDATE statement.
Buffer Manager
Buffer manager manages core functions for modules below:
- Plan Cache
- Data Parsing: Buffer cache & Data storage
- Dirty Page
We will learn Plan, Buffer and Data cache in this section. We will cover Dirty pages in the Transaction section.
Plan Cache
- Existing Query plan: The buffer manager checks if the execution plan is there in the stored Plan Cache. If Yes, then query plan cache and its associated data cache is used.
- First time Cache plan: Where does existing Plan cache come from?
If the first-time query execution plan is being run and is complex, it makes sense to store it in in the Plane cache. This will ensure faster availability when the next time SQL server gets the same query. So, it's nothing else but the query itself which Plan execution is being stored if it is being run for the first time.
Data Parsing: Buffer cache & Data Storage
Buffer manager provides access to the data required. Below two approaches are possible depending upon whether data exist in the data cache or not:
Buffer Cache - Soft Parsing:
Buffer Manager looks for Data in Buffer in Data cache. If present, then this Data is used by Query Executor. This improves the performance as the number of I/O operation is reduced when fetching data from the cache as compared to fetching data from Data storage.
Data Storage - Hard Parsing:
If data is not present in Buffer Manager than required Data is searched in Data Storage. If also stores data in the data cache for future use.
Dirty Page
It is stored as a processing logic of Transaction Manager. We will learn in detail in Transaction Manager section.
Transaction Manager
Transaction Manager is invoked when access method determines that Query is a Non-Select statement.
Log Manager
- Log Manager keeps a track of all updates done in the system via logs in Transaction Logs.
- Logs have Logs Sequence Number with the Transaction ID and Data Modification Record.
- This is used for keeping track of Transaction Committed and Transaction Rollback.
Lock Manager
- During Transaction, the associated data in Data Storage is in the Lock state. This process is handled by Lock Manager.
- This process ensures data consistency and isolation. Also known as ACID properties.
Execution Process
- Log Manager start logging and Lock Manager locks the associated data.
- Data's copy is maintained in the Buffer cache.
- Copy of data supposed to be updated is maintained in Log buffer and all the events updates data in Data buffer.
- Pages which store the data is also known as Dirty Pages.
- Checkpoint and Write-Ahead Logging: This process run and mark all the page from Dirty Pages to Disk, but the page remains in the cache. Frequency is approximately 1 run per minute.But the page is first pushed to Data page of the log file from Buffer log. This is known as Write Ahead Logging.
- Lazy Writer: The Dirty page can remain in memory. When SQL server observes a huge load and Buffer memory is needed for a new transaction, it frees up Dirty Pages from the cache. It operates on LRU - Least recently used Algorithm for cleaning page from buffer pool to disk.
Summary:
- Three Type of Client Server Architecture exist: 1) Shared Memory 2) TCP/IP 3)Named Pipes
- TDS, developed by Sybase and now owned by Microsoft, is a packet which is encapsulated in Network packets for data transfer from the client machine to the server machine.
- Relational Engine contains three major components:
CMD Parser: This is responsible for Syntactic and Semantic error & finally generate a Query Tree.
Optimizer: Optimizer role is to find the cheapest, not the best, cost-effective execution plan.
Query Executor: Query executer calls Access Method and provides execution plan for data fetching logic required for execution.
- Three type of files exists Primary file, Secondary file, and Log files.
- Storage Engine: Has following important components
Access Method: This Component Determine whether the query is Select or Non-Select Statement. Invokes Buffer and Transfer Manager accordingly.
Buffer Manager: Buffer manager manages core functions for Plan Cache, Data Parsing & Dirty Page.
Tehingute haldur: see haldab mittevalivat tehingut logi- ja lukuhaldurite abiga. Samuti hõlbustab Write Ahead logimise ja Lazy kirjutajate olulist rakendamist.