MS SQL Server är en klient-server-arkitektur. MS SQL Server-processen börjar med att klientapplikationen skickar en begäran. SQL Server accepterar, bearbetar och svarar på begäran med bearbetade data. Låt oss diskutera i detalj hela arkitekturen som visas nedan:
Som nedanstående diagram visar finns det tre huvudkomponenter i SQL Server Architecture:
- Protokollskikt
- Relationsmotor
- Lagringsmotor
Låt oss diskutera i detalj om alla de tre ovanstående huvudmodulerna. I den här handledningen lär du dig.
- Protokollskikt - SNI
- Delat minne
- TCP / IP
- Namngivna rör
- Vad är TDS?
- Relationsmotor
- CMD-analysator
- Optimizer
- Frågexecutor
- Lagringsmotor
- Filtyper
- Åtkomstmetod
- Buffer Manager
- Planera cache
- Dataparsning: buffertcache och datalagring
- Transaktionschef
Protokollskikt - SNI
MS SQL SERVER PROTOCOL LAYER stöder 3 typer av klientserverarkitektur. Vi börjar med " Three Type of Client Server Architecture" som MS SQL Server stöder.
Delat minne
Låt oss ompröva ett konversationsscenario tidigt på morgonen.
MAMMA och TOM - Här var Tom och hans mamma på samma logiska plats, dvs hemma. Tom kunde be om kaffe och mamma kunde servera det varmt.
MS SQL SERVER - Här tillhandahåller MS SQL- server SHARED MEMORY PROTOCOL . Här kör CLIENT och MS SQL- server på samma maskin. Båda kan kommunicera via Shared Memory-protokollet.
Analogi: Låter kartlägga enheter i ovanstående två scenarier. Vi kan enkelt mappa Tom till klient, mamma till SQL-server, hem till maskin och verbal kommunikation till delat minnesprotokoll.
Från skrivbordet för konfiguration och installation:
För anslutning till lokal DB - I SQL Management Studio kan alternativet "Servernamn" vara
"."
"lokal värd"
"127.0.0.1"
"Maskin \ Instans"
TCP / IP
Tänk nu på kvällen, Tom är på feststemning. Han vill ha en kaffe beställd från en välkänd kafé. Kaféet ligger 10 km från hans hem.
Här är Tom och Starbuck på olika fysiska platser. Tom hemma och Starbucks på den livliga marknaden. De kommunicerar via mobilnätverk. På samma sätt ger MS SQL SERVER möjlighet att interagera via TCP / IP-protokoll, där CLIENT och MS SQL Server är avlägsna från varandra och installerade på en separat maskin.
Analogi: Låter kartlägga enheter i ovanstående två scenarier. Vi kan enkelt kartlägga Tom till klient, Starbuck till SQL-server, hem / marknadsplats till fjärrplats och slutligen mobilnät till TCP / IP-protokoll.
Anteckningar från skrivbordet för konfiguration / installation:
- I SQL Management Studio - För anslutning via TCP \ IP måste alternativet "Server Name" vara "Machine \ Instance of the server."
- SQL-server använder port 1433 i TCP / IP.
Namngivna rör
Nu äntligen på kvällen ville Tom ha ett ljust grönt te som hennes granne Sierra förbereder mycket bra.
Här är Tom och hans granne , Sierra, på samma fysiska plats och är varandras granne. De kommunicerar via Intra-nätverket. På samma sätt ger MS SQL SERVER möjlighet att interagera via Named Pipe- protokollet. Här är CLIENT och MS SQL SERVER anslutna via LAN .
Analogi: Låter kartlägga enheter i ovanstående två scenarier. Vi kan enkelt mappa Tom till Client, Sierra till SQL-server, Neighbor to LAN och slutligen Intra-nätverk till Named Pipe Protocol.
Anteckningar från skrivbordet för konfiguration / installation:
- För anslutning via namngiven rör. Det här alternativet är inaktiverat som standard och måste aktiveras av SQL Configuration Manager.
Vad är TDS?
Nu när vi vet att det finns tre typer av klient-serverarkitektur, kan vi titta på TDS:
- TDS står för Tabular Data Stream.
- Alla tre protokollen använder TDS-paket. TDS är inkapslat i nätverkspaket. Detta möjliggör dataöverföring från klientmaskinen till servermaskinen.
- TDS utvecklades först av Sybase och ägs nu av Microsoft
Relationsmotor
Relationsmotorn är också känd som Query Processor. Den har SQL Server-komponenterna som avgör vad en fråga behöver göra exakt och hur det kan göras bäst. Det ansvarar för utförandet av användarfrågor genom att begära data från lagringsmotorn och bearbeta de resultat som returneras.
Som avbildat i arkitekturdiagrammet finns det tre huvudkomponenter i Relational Engine. Låt oss studera komponenterna i detalj:
CMD-analysator
Data som en gång mottagits från Protocol Layer skickas sedan till Relational Engine. "CMD Parser" är den första komponenten i Relational Engine som tar emot frågedata. CMD Parsers huvuduppgift är att kontrollera frågan för syntaktiska och semantiska fel. Slutligen genererar det ett frågeträd . Låt oss diskutera i detalj.
Syntaktisk kontroll:
- Som alla andra programmeringsspråk har MS SQL också den fördefinierade uppsättningen nyckelord. SQL Server har också sin egen grammatik som SQL-servern förstår.
- VÄLJ, INSÄTT, UPPDATERA och många andra tillhör MS SQL fördefinierade nyckelordslistor.
- CMD Parser gör syntaktisk kontroll. Om användarens inmatning inte följer dessa språksyntax- eller grammatikregler, returnerar det ett fel.
Exempel: Låt oss säga att en rysk gick till en japansk restaurang. Han beställer snabbmat på ryska. Tyvärr förstår servitören bara japanska. Vad skulle vara det mest uppenbara resultatet?
Svaret är - servitören kan inte behandla beställningen vidare.
Det bör inte finnas någon avvikelse i grammatik eller språk som SQL-servern accepterar. Om det finns kan SQL-servern inte bearbeta det och kommer därför att returnera ett felmeddelande.
Vi kommer att lära oss mer om MS SQL-frågor i kommande handledning. Men betrakta nedan de mest grundläggande Query Syntax som
SELECT * from;
För att få uppfattningen om vad syntaktik gör, säg om användaren kör den grundläggande frågan enligt nedan:
SELECR * from
Observera att istället för "VÄLJ" skrev användaren "SELECR."
Resultat: CMD-analysatorn kommer att analysera detta uttalande och kasta felmeddelandet. Eftersom "SELECR" inte följer det fördefinierade sökordets namn och grammatik. Här väntade CMD Parser "SELECT".
Semantisk kontroll:
- Detta utförs av Normalizer .
- I sin enklaste form kontrollerar den om kolumnnamn, tabellnamn som ifrågasätts finns i schemat. Och om den finns, bind den till fråga. Detta kallas också bindning .
- Komplexiteten ökar när användarfrågor innehåller VIEW. Normalizer utför ersättningen med den internt lagrade visningsdefinitionen och mycket mer.
Låt oss förstå detta med hjälp av exemplet nedan -
SELECT * from USER_ID
Resultat: CMD Parser analyserar detta uttalande för semantisk kontroll. Parsern kastar ett felmeddelande eftersom Normalizer inte hittar den begärda tabellen (USER_ID) eftersom den inte finns.
Skapa frågeträd:
- Detta steg genererar olika körningsträd där frågan kan köras.
- Observera att alla träd har samma önskade effekt.
Optimizer
Optimeringsarbetets arbete är att skapa en exekveringsplan för användarens fråga. Det här är planen som kommer att avgöra hur användarfrågan ska köras.
Observera att inte alla frågor är optimerade. Optimering görs för DML-kommandon (Data Modification Language) som SELECT, INSERT, DELETE och UPDATE. Sådana frågor markeras först och skickas sedan till optimeraren. DDL-kommandon som CREATE och ALTER är inte optimerade, men kompileras istället till en intern form. Frågekostnaden beräknas baserat på faktorer som CPU-användning, minnesanvändning och behov av in- / utdata.
Optimizers roll är att hitta den billigaste, inte den bästa, kostnadseffektiva genomförandeplanen.
Innan vi hoppar in i mer tekniska detaljer i Optimizer bör du tänka på nedan:
Exempel:
Låt oss säga att du vill öppna ett bankkonto online. Du vet redan om en bank som tar högst två dagar för att öppna ett konto. Men du har också en lista med 20 andra banker, som kan ta eller inte ta mindre än två dagar. Du kan börja samarbeta med dessa banker för att avgöra vilka banker som tar mindre än två dagar. Nu kanske du inte hittar en bank som tar mindre än två dagar, och det förloras ytterligare tid på grund av själva sökaktiviteten. Det hade varit bättre att öppna ett konto hos den första banken själv.
Slutsats: Det är viktigare att välja klokt. För att vara exakt, välj vilket alternativ som är bäst, inte det billigaste.
På samma sätt fungerar MS SQL Optimizer på inbyggda uttömmande / heuristiska algoritmer. Målet är att minimera frågetid. Alla Optimizer-algoritmer är tillhöriga Microsoft och en hemlighet. Även om , nedan är de på hög nivå steg som utförs av MS SQL Optimizer. Sökningar efter optimering följer tre faser som visas i nedanstående diagram:
Fas 0: Sök efter Trivial Plan:
- Detta är även känt som Pre-optimization stage .
- I vissa fall kan det bara finnas en praktisk, fungerande plan, känd som en trivial plan. Det finns inget behov av att skapa en optimerad plan. Anledningen är att sökning efter mer skulle resultera i att samma körtidsplan exekveras. Det också med den extra kostnaden för att söka efter en optimerad plan som inte alls krävdes.
- Om ingen trivial planen fann då en st Phase startar.
Fas 1: Sök efter planer för hantering av transaktioner
- Detta inkluderar sökandet efter enkel och komplex plan .
- Enkel plan-sökning: Tidigare data för kolumner och index som är inblandade i frågan kommer att användas för statistisk analys. Detta består vanligtvis men inte begränsat till en index per tabell.
- Om den enkla planen inte hittas, söks det fortfarande efter mer komplex plan. Det involverar flera index per tabell.
Fas 2: Parallell bearbetning och optimering.
- Om ingen av ovanstående strategier fungerar, söker Optimizer efter möjligheter för parallell bearbetning. Detta beror på maskinens bearbetningsfunktioner och konfiguration.
- Om det fortfarande inte är möjligt, börjar den slutliga optimeringsfasen. Nu är det slutliga optimeringsmålet att hitta alla andra möjliga alternativ för att utföra frågan på bästa sätt. Slutliga optimeringsfasalgoritmer är Microsoft Propriety.
Frågexecutor
Fråga executer anrop Access Method. Det ger en exekveringsplan för datahämtningslogik som krävs för körning. När data har mottagits från Storage Engine publiceras resultatet i protokolllagret. Slutligen skickas data till slutanvändaren.
Lagringsmotor
Lagringsmotorns arbete är att lagra data i ett lagringssystem som Disk eller SAN och hämta data vid behov. Innan vi djupdykar in i lagringsmotorn, låt oss ta en titt på hur data lagras i databasen och typen av tillgängliga filer.
Datafil och omfattning:
Datafil, lagrar fysiskt data i form av datasidor, varvid varje datasida har en storlek på 8KB och utgör den minsta lagringsenheten i SQL Server. Dessa datasidor är logiskt grupperade för att bilda omfattningar. Inget objekt tilldelas en sida i SQL Server.
Underhållet av objektet sker via extens. Sidan har ett avsnitt som kallas sidhuvudet med en storlek på 96 byte, med metadatainformation om sidan som sidtyp, sidnummer, storlek på använt utrymme, storlek på ledigt utrymme och pekare till nästa sida och föregående sida , etc.
Filtyper
- Primär fil
- Varje databas innehåller en primärfil.
- Den här lagrar all viktig information relaterad till tabeller, vyer, utlösare etc.
- Extension är. mdf vanligtvis men kan ha alla tillägg.
- Sekundär fil
- Databasen innehåller eller kanske inte flera sekundära filer.
- Detta är valfritt och innehåller användarspecifik data.
- Extension är. ndf vanligtvis men kan ha alla tillägg.
- Loggfil
- Även känd som Skriv fram loggar.
- Extension är. ldf
- Används för transaktionshantering.
- Detta används för att återhämta sig från oönskade instanser. Utför viktig uppgift för återställning till icke-förbundna transaktioner.
Storage Engine har 3 komponenter; låt oss granska dem i detalj.
Åtkomstmetod
Det fungerar som ett gränssnitt mellan frågexekutören och Buffer Manager / Transaction Logs.
Åtkomstmetoden i sig gör ingen exekvering.
Den första åtgärden är att avgöra om frågan är:
- Välj uttalande (DDL)
- Icke-välj uttalande (DDL & DML)
Beroende på resultatet tar åtkomstmetoden följande steg:
- Om frågan är DDL , SELECT-sats skickas frågan till bufferthanteraren för vidare bearbetning.
- Och om frågan om DDL, NON-SELECT-satsen skickas frågan till Transaction Manager. Detta inkluderar mestadels UPDATE-uttalandet.
Buffer Manager
Buffer manager hanterar kärnfunktioner för moduler nedan:
- Planera cache
- Dataparsning: buffertcache och datalagring
- Smutsig sida
Vi lär oss cache för planering, buffert och data i det här avsnittet. Vi kommer att täcka smutsiga sidor i avsnittet Transaktion.
Planera cache
- Befintlig frågeplan: Bufferthanteraren kontrollerar om exekveringsplanen finns i den lagrade Plan Cache. Om Ja används frågeplanscache och tillhörande datacache.
- Första gången Cache-plan: Var kommer befintlig Plan-cache från?
Om den första planen för körning av frågan körs och är komplicerad är det vettigt att lagra den i Plane cache. Detta säkerställer snabbare tillgänglighet nästa gång SQL-servern får samma fråga. Så det är inget annat än själva frågan vilken plankörning som lagras om den körs för första gången.
Dataparsning: buffertcache och datalagring
Bufferthanteraren ger åtkomst till de data som krävs. Nedanstående två tillvägagångssätt är möjliga beroende på om det finns data i datacachen eller inte:
Buffertcache - mjuk tolkning:
Buffer Manager letar efter data i buffert i datacache. Om det finns, används dessa data av Query Executor. Detta förbättrar prestandan eftersom antalet I / O-operationer minskas när data hämtas från cachen jämfört med att hämta data från datalagring.
Datalagring - hård analysering:
Om data inte finns i bufferthanteraren än vad som krävs söks data i datalagring. Om också lagrar data i datacachen för framtida bruk.
Smutsig sida
Den lagras som en behandlingslogik för Transaction Manager. Vi kommer att lära oss i detalj i avsnittet Transaction Manager.
Transaktionschef
Transaction Manager anropas när åtkomstmetoden avgör att Query är ett uttalande som inte väljs.
Log Manager
- Log Manager håller reda på alla uppdateringar som görs i systemet via loggar i Transaktionsloggar.
- Loggar har loggens sekvensnummer med transaktions-ID och datamodifieringspost .
- Detta används för att hålla reda på åtaganden om transaktion och återföring av transaktion .
Lock Manager
- Under transaktionen är tillhörande data i datalagring i låst tillstånd. Denna process hanteras av Lock Manager.
- Denna process säkerställer datakonsistens och isolering . Även känd som ACID-egenskaper.
Exekveringsprocess
- Log Manager startar loggning och Lock Manager låser tillhörande data.
- Datakopian sparas i buffertcache.
- Kopiering av data som ska uppdateras bibehålls i loggbuffert och alla händelser uppdaterar data i databuffert.
- Sidor som lagrar data kallas även Dirty Pages .
- Checkpoint and Write-Ahead Logging: Denna process kör och markerar hela sidan från Dirty Pages till Disk, men sidan förblir i cachen. Frekvensen är cirka 1 körning per minut, men sidan trycks först till datasidan för loggfilen från buffertloggen. Detta kallas Skriv framåt-loggning.
- Lazy Writer: Den smutsiga sidan kan finnas kvar i minnet. När SQL-servern observerar en enorm belastning och buffertminne behövs för en ny transaktion frigör det Dirty Pages från cachen. Den fungerar på LRU - Minst nyligen använt algoritm för rengöring av sida från buffertpool till disk.
Sammanfattning:
- Tre typer av klientserverarkitektur finns: 1) Delat minne 2) TCP / IP 3) Namngivna rör
- TDS, utvecklat av Sybase och ägs nu av Microsoft, är ett paket som är inkapslat i nätverkspaket för dataöverföring från klientmaskinen till servermaskinen.
- Relational Engine innehåller tre huvudkomponenter:
CMD Parser: Detta är ansvarigt för syntaktiska och semantiska fel och genererar slutligen ett frågeträd.
Optimizer: Rollen Optimizer är att hitta den billigaste, inte den bästa, kostnadseffektiva genomförandeplanen.
Query Executor: Query executer anropar Access Method och tillhandahåller körplan för datahämtningslogik som krävs för exekvering.
- Det finns tre typer av filer Primärfil, sekundärfil och loggfiler.
- Lagringsmotor: Har följande viktiga komponenter
Åtkomstmetod: Denna komponent Bestäm om frågan är Select eller Non-Select Statement. Anropar buffert- och överföringshanteraren i enlighet därmed.
Buffer Manager: Buffer manager hanterar kärnfunktioner för Plan Cache, Data Parsing & Dirty Page.
Transaction Manager: It manager Non-Select Transaction med hjälp av Log and Lock Managers. Underlättar också en viktig implementering av Write Ahead-loggning och Lazy författare.