Erklärte SQL Server-Architektur: Named Pipes, Optimierer, Puffermanager

Inhaltsverzeichnis:

Anonim

MS SQL Server ist eine Client-Server-Architektur. Der MS SQL Server-Prozess beginnt damit, dass die Clientanwendung eine Anforderung sendet. Der SQL Server akzeptiert, verarbeitet und antwortet auf die Anforderung mit verarbeiteten Daten. Lassen Sie uns die gesamte unten gezeigte Architektur im Detail diskutieren:

Wie das folgende Diagramm zeigt, gibt es drei Hauptkomponenten in der SQL Server-Architektur:

  1. Protokollschicht
  2. Relationale Engine
  3. Speicher-Engine
SQL Server-Architekturdiagramm

Lassen Sie uns alle drei oben genannten Hauptmodule ausführlich besprechen. In diesem Tutorial lernen Sie.

  • Protokollschicht - SNI
    • Geteilte Erinnerung
    • TCP / IP
    • Named Pipes
    • Was ist TDS?
  • Relationale Engine
    • CMD-Parser
    • Optimierer
    • Query Executor
  • Speicher-Engine
    • Datentypen
    • Zugriffsmethode
    • Puffermanager
    • Cache planen
    • Datenanalyse: Puffercache und Datenspeicherung
    • Transaktionsmanager

Protokollschicht - SNI

MS SQL SERVER PROTOCOL LAYER unterstützt 3 Arten von Client Server-Architekturen. Wir beginnen mit " Drei Arten von Client-Server-Architekturen", die von MS SQL Server unterstützt werden.

Geteilte Erinnerung

Lassen Sie uns ein Gesprächsszenario am frühen Morgen noch einmal überdenken.

MOM und TOM - Hier waren Tom und seine Mutter am selben logischen Ort, dh bei ihnen zu Hause. Tom konnte nach Kaffee fragen und Mama konnte ihn heiß servieren.

MS SQL Server - Hier bietet MS SQL Server SHARED MEMORY PROTOCOL . Hier werden CLIENT und MS SQL Server auf demselben Computer ausgeführt. Beide können über das Shared Memory-Protokoll kommunizieren.

Analogie: Ermöglicht die Zuordnung von Entitäten in den beiden oben genannten Szenarien. Wir können Tom problemlos dem Client, Mom dem SQL Server, Home to Machine und Verbal Communication to Shared Memory Protocol zuordnen.

Vom Schreibtisch der Konfiguration und Installation:

Für die Verbindung zur lokalen Datenbank - In SQL Management Studio kann die Option "Servername" verwendet werden

"."

"localhost"

127.0.0.1

"Maschine \ Instanz"

TCP / IP

Denken Sie jetzt abends daran, dass Tom in Partystimmung ist. Er möchte einen Kaffee, der in einem bekannten Café bestellt wurde. Das Café befindet sich 10 km von seinem Haus entfernt.

Hier befinden sich Tom und Starbuck an unterschiedlichen physischen Orten. Tom zu Hause und Starbucks auf dem geschäftigen Marktplatz. Sie kommunizieren über ein Mobilfunknetz. In ähnlicher Weise bietet MS SQL SERVER die Möglichkeit, über das TCP / IP-Protokoll zu interagieren, wobei CLIENT und MS SQL Server voneinander entfernt und auf einem separaten Computer installiert sind.

Analogie: Ermöglicht die Zuordnung von Entitäten in den beiden oben genannten Szenarien. Wir können Tom problemlos dem Client, Starbuck dem SQL Server, dem Home / Market Place dem Remote-Standort und schließlich dem Mobilfunknetz dem TCP / IP-Protokoll zuordnen.

Notizen vom Schreibtisch der Konfiguration / Installation:

  • In SQL Management Studio - Für die Verbindung über TCP \ IP muss die Option "Servername" "Computer \ Instanz des Servers" sein.
  • SQL Server verwendet Port 1433 in TCP / IP.

Named Pipes

Jetzt endlich in der Nacht wollte Tom einen hellgrünen Tee haben, den ihre Nachbarin Sierra sehr gut zubereitet.

Hier befinden sich Tom und sein Nachbar Sierra am selben physischen Ort und sind die Nachbarn des anderen. Sie kommunizieren über das Intra-Netzwerk. In ähnlicher Weise bietet MS SQL SERVER die Möglichkeit, über das Named Pipe- Protokoll zu interagieren . Hier sind CLIENT und MS SQL SERVER über LAN verbunden .

Analogie: Ermöglicht die Zuordnung von Entitäten in den beiden oben genannten Szenarien. Wir können Tom problemlos dem Client, Sierra dem SQL Server, Neighbor dem LAN und schließlich dem Intra-Netzwerk dem Named Pipe-Protokoll zuordnen.

Notizen vom Schreibtisch der Konfiguration / Installation:

  • Für die Verbindung über Named Pipe. Diese Option ist standardmäßig deaktiviert und muss vom SQL Configuration Manager aktiviert werden.

Was ist TDS?

Nachdem wir nun wissen, dass es drei Arten von Client-Server-Architekturen gibt, werfen wir einen Blick auf TDS:

  • TDS steht für Tabular Data Stream.
  • Alle 3 Protokolle verwenden TDS-Pakete. TDS ist in Netzwerkpaketen gekapselt. Dies ermöglicht die Datenübertragung vom Client-Computer zum Server-Computer.
  • TDS wurde zuerst von Sybase entwickelt und gehört jetzt Microsoft

Relationale Engine

Die relationale Engine wird auch als Abfrageprozessor bezeichnet. Es enthält die SQL Server-Komponenten, die bestimmen, was genau eine Abfrage tun muss und wie sie am besten ausgeführt werden kann. Es ist für die Ausführung von Benutzerabfragen verantwortlich, indem Daten von der Speicher-Engine angefordert und die zurückgegebenen Ergebnisse verarbeitet werden.

Wie im Architekturdiagramm dargestellt, gibt es drei Hauptkomponenten der Relational Engine. Lassen Sie uns die Komponenten im Detail untersuchen:

CMD-Parser

Daten, die einmal von der Protokollschicht empfangen wurden, werden dann an Relational Engine übergeben. "CMD Parser" ist die erste Komponente von Relational Engine, die die Abfragedaten empfängt. Die Hauptaufgabe von CMD Parser besteht darin, die Abfrage auf syntaktische und semantische Fehler zu überprüfen . Schließlich wird ein Abfragebaum generiert . Lassen Sie uns im Detail diskutieren.

Syntaktische Prüfung:

  • Wie jede andere Programmiersprache verfügt auch MS SQL über einen vordefinierten Satz von Schlüsselwörtern. Außerdem verfügt SQL Server über eine eigene Grammatik, die SQL Server versteht.
  • SELECT, INSERT, UPDATE und viele andere gehören zu vordefinierten MS SQL-Schlüsselwortlisten.
  • CMD Parser führt syntaktische Überprüfungen durch. Wenn die Benutzereingaben nicht diesen Sprachsyntax- oder Grammatikregeln entsprechen, wird ein Fehler zurückgegeben.

Beispiel: Nehmen wir an, ein Russe ging in ein japanisches Restaurant. Er bestellt Fast Food in russischer Sprache. Leider versteht der Kellner nur Japanisch. Was wäre das offensichtlichste Ergebnis?

Die Antwort lautet: Der Kellner kann die Bestellung nicht weiter bearbeiten.

Es sollte keine Abweichung in der Grammatik oder Sprache geben, die SQL Server akzeptiert. Wenn dies der Fall ist, kann SQL Server es nicht verarbeiten und gibt daher eine Fehlermeldung zurück.

Weitere Informationen zu MS SQL-Abfragen finden Sie in den kommenden Tutorials. Betrachten Sie im Folgenden jedoch die grundlegendste Abfragesyntax als 

SELECT * from ;

Um einen Eindruck davon zu bekommen, was syntaktisch funktioniert, sagen Sie, ob der Benutzer die grundlegende Abfrage wie folgt ausführt:

SELECR * from

Beachten Sie, dass der Benutzer anstelle von 'SELECT' "SELECR" eingegeben hat.

Ergebnis: Der CMD-Parser analysiert diese Anweisung und gibt die Fehlermeldung aus. Da "SELECR" nicht dem vordefinierten Schlüsselwortnamen und der Grammatik folgt. Hier erwartete CMD Parser "SELECT".

Semantische Prüfung:

  • Dies wird vom Normalisierer durchgeführt .
  • In seiner einfachsten Form wird geprüft, ob der Spaltenname und der abgefragte Tabellenname im Schema vorhanden sind. Und wenn es existiert, binden Sie es an Query. Dies wird auch als Bindung bezeichnet .
  • Die Komplexität steigt, wenn Benutzerabfragen VIEW enthalten. Normalizer führt das Ersetzen durch die intern gespeicherte Ansichtsdefinition und vieles mehr durch.

Lassen Sie uns dies anhand des folgenden Beispiels verstehen -

SELECT * from USER_ID

Ergebnis: Der CMD-Parser analysiert diese Anweisung für die semantische Prüfung. Der Parser gibt eine Fehlermeldung aus, da der Normalisierer die angeforderte Tabelle (USER_ID) nicht findet, da sie nicht vorhanden ist.

Abfragebaum erstellen:

  • Dieser Schritt generiert einen anderen Ausführungsbaum, in dem die Abfrage ausgeführt werden kann.
  • Beachten Sie, dass alle verschiedenen Bäume dieselbe gewünschte Ausgabe haben.

Optimierer

Die Arbeit des Optimierers besteht darin, einen Ausführungsplan für die Benutzerabfrage zu erstellen. Dies ist der Plan, der bestimmt, wie die Benutzerabfrage ausgeführt wird.

Beachten Sie, dass nicht alle Abfragen optimiert sind. Die Optimierung erfolgt für DML-Befehle (Data Modification Language) wie SELECT, INSERT, DELETE und UPDATE. Solche Abfragen werden zuerst markiert und dann an den Optimierer gesendet. DDL-Befehle wie CREATE und ALTER werden nicht optimiert, sondern in eine interne Form kompiliert. Die Abfragekosten werden basierend auf Faktoren wie CPU-Auslastung, Speicherauslastung und Eingabe- / Ausgabeanforderungen berechnet.

Die Aufgabe des Optimierers besteht darin, den günstigsten und nicht den besten und kostengünstigsten Ausführungsplan zu finden.

Bevor wir auf weitere technische Details des Optimierers eingehen, betrachten Sie das folgende Beispiel aus der Praxis:

Beispiel:

Angenommen, Sie möchten ein Online-Bankkonto eröffnen. Sie kennen bereits eine Bank, die maximal 2 Tage benötigt, um ein Konto zu eröffnen. Sie haben aber auch eine Liste von 20 anderen Banken, die weniger als 2 Tage dauern können oder nicht. Sie können mit diesen Banken in Kontakt treten, um festzustellen, welche Banken weniger als 2 Tage benötigen. Jetzt finden Sie möglicherweise keine Bank, die weniger als 2 Tage dauert, und aufgrund der Suchaktivität selbst geht zusätzliche Zeit verloren. Es wäre besser gewesen, ein Konto bei der ersten Bank selbst zu eröffnen.

Fazit: Es ist wichtiger, mit Bedacht auszuwählen. Um genau zu sein, wählen Sie, welche Option die beste und nicht die billigste ist.

In ähnlicher Weise arbeitet MS SQL Optimizer mit integrierten umfassenden / heuristischen Algorithmen. Ziel ist es, die Laufzeit der Abfrage zu minimieren. Alle Optimizer-Algorithmen sind Eigentum von Microsoft und ein Geheimnis. Obwohl , unten sind die High-Level - Schritte , die von MS SQL - Optimierer durchgeführt. Die Suche nach Optimierung erfolgt in drei Phasen, wie in der folgenden Abbildung dargestellt:

Phase 0: Suche nach Trivial Plan:

  • Dies wird auch als Voroptimierungsphase bezeichnet .
  • In einigen Fällen könnte es nur einen praktischen, praktikablen Plan geben, der als trivialer Plan bezeichnet wird. Es ist nicht erforderlich, einen optimierten Plan zu erstellen. Der Grund dafür ist, dass eine weitere Suche dazu führen würde, dass derselbe Laufzeitausführungsplan gefunden wird. Auch das mit den zusätzlichen Kosten für die Suche nach einem optimierten Plan, die überhaupt nicht erforderlich waren.
  • Wenn kein Trivial Plan gefunden, dann 1 st Phase beginnt.

Phase 1: Suche nach Transaktionsverarbeitungsplänen

  • Dies beinhaltet die Suche nach einem einfachen und komplexen Plan .
  • Einfache Plansuche: Frühere Daten der an der Abfrage beteiligten Spalte und des Index werden für die statistische Analyse verwendet. Dies besteht normalerweise aus einem Index pro Tabelle, ist jedoch nicht darauf beschränkt.
  • Wenn der einfache Plan jedoch nicht gefunden wird, wird nach einem komplexeren Plan gesucht. Es handelt sich um mehrere Indizes pro Tabelle.

Phase 2: Parallele Verarbeitung und Optimierung.

  • Wenn keine der oben genannten Strategien funktioniert, sucht Optimizer nach Möglichkeiten für die parallele Verarbeitung. Dies hängt von den Verarbeitungsfunktionen und der Konfiguration des Geräts ab.
  • Ist dies immer noch nicht möglich, beginnt die letzte Optimierungsphase. Das endgültige Optimierungsziel besteht nun darin, alle anderen möglichen Optionen für die bestmögliche Ausführung der Abfrage zu finden. Letzte Optimierungsphase Algorithmen sind Microsoft Propriety.

Query Executor

Query Executer ruft die Zugriffsmethode auf. Es bietet einen Ausführungsplan für die Datenabruflogik, die für die Ausführung erforderlich ist. Sobald Daten von Storage Engine empfangen wurden, wird das Ergebnis in der Protokollschicht veröffentlicht. Schließlich werden Daten an den Endbenutzer gesendet.

Speicher-Engine

Die Arbeit der Storage Engine besteht darin, Daten in einem Speichersystem wie Disk oder SAN zu speichern und bei Bedarf abzurufen. Bevor wir uns eingehend mit der Speicher-Engine befassen, werfen wir einen Blick darauf, wie Daten in der Datenbank gespeichert werden und welche Dateitypen verfügbar sind.

Datendatei und Umfang:

In der Datendatei werden Daten physisch in Form von Datenseiten gespeichert, wobei jede Datenseite eine Größe von 8 KB hat und die kleinste Speichereinheit in SQL Server bildet. Diese Datenseiten sind logisch gruppiert, um Bereiche zu bilden. In SQL Server wird keinem Objekt eine Seite zugewiesen.

Die Wartung des Objekts erfolgt über Extents. Die Seite enthält einen Abschnitt namens Seitenkopf mit einer Größe von 96 Byte, der die Metadateninformationen zur Seite wie Seitentyp, Seitenzahl, Größe des verwendeten Speicherplatzes, Größe des freien Speicherplatzes und Zeiger zur nächsten Seite und vorherigen Seite enthält , usw.

Datentypen

  1. Primärdatei
  • Jede Datenbank enthält eine Primärdatei.
  • Hier werden alle wichtigen Daten zu Tabellen, Ansichten, Triggern usw. gespeichert.
  • Erweiterung ist. mdf normalerweise aber kann von beliebiger erweiterung sein.
  1. Sekundärdatei
  • 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.
  1. 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:

  1. Select Statement (DDL)
  2. Non- Select Statement (DDL & DML)

Depending upon the result, the Access Method takes the following steps:

  1. If the query is DDL, SELECT statement, the query is pass to the Buffer Manager for further processing.
  2. 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.

    Transaktionsmanager: Er verwaltet nicht ausgewählte Transaktionen mithilfe von Protokoll- und Sperrmanagern. Erleichtert außerdem die wichtige Implementierung der Write Ahead-Protokollierung und der Lazy Writer.