SQL Server-Architektur (erklärt)

MS SQL Server ist eine Client-Server-Architektur. Der MS SQL Server-Prozess beginnt damit, dass die Clientanwendung eine Anfrage sendet. Der SQL Server nimmt die Anfrage entgegen, verarbeitet sie und antwortet mit verarbeiteten Daten. Lassen Sie uns die gesamte unten gezeigte Architektur im Detail besprechen:

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

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

Protokollschicht – SNI

MS SQL SERVER PROTOCOL LAYER unterstützt 3 Arten von Client-Server-Architekturen. Wir beginnen mit „Drei Arten von Client-Server-Architekturen“ welche MS SQL Server unterstützt.

Geteilte Erinnerung

Betrachten wir noch einmal ein Gesprächsszenario am frühen Morgen.

Protokollschicht – SNI

MOM und TOM – Hier waren Tom und seine Mutter am selben logischen Ort, nämlich bei ihnen zu Hause. Tom konnte um Kaffee bitten und Mama konnte ihn heiß servieren.

MS SQL-SERVER – Hier MS SQL Server bereitstellt Shared-Memory-Protokoll. Hier KLIENT und MS SQL Server laufen auf demselben Rechner. Beide können über das Shared-Memory-Protokoll kommunizieren.

Analogie: Lassen Sie uns Entitäten in den beiden oben genannten Szenarien zuordnen. Wir können Tom problemlos dem Client, Mom dem SQL-Server, Home der Maschine und verbale Kommunikation dem Shared Memory Protocol zuordnen.

Von der Konfigurations- und Installationstheke aus:

Für die Verbindung zur lokalen Datenbank – In SQL Management Studio, Option „Servername“ könnte sein

""

„lokaler Host“

"127.0.0.1"

„Maschine\Instanz“

Protokollschicht – SNI

TCP / IP

Nun bedenken Sie, dass Tom am Abend in Partylaune ist. Er möchte einen Kaffee in einem bekannten Café bestellen. Das Café liegt 10 km von seinem Zuhause entfernt.

TCP / IP

Hier befinden sich Tom und Starbuck an unterschiedlichen physischen Standorten. Tom zu Hause und Starbucks auf dem belebten Marktplatz. Sie kommunizieren über ein Mobilfunknetz. Ebenso bietet MS SQL SERVER die Möglichkeit zur Interaktion über TCP / IP-Protokoll, wobei CLIENT und MS SQL Server voneinander entfernt sind und auf einem separaten Computer installiert sind.

Analogie: Lassen Sie uns Entitäten in den beiden oben genannten Szenarien zuordnen. Wir können ganz einfach Tom dem Client, Starbuck dem SQL-Server, den Heim-/Marktplatz dem entfernten Standort und schließlich das Mobilfunknetz dem TCP/IP-Protokoll zuordnen.

Notizen vom Schreibtisch Konfiguration/Installation:

  • In SQL Management Studio – Für die Verbindung über TCP\IP muss die Option „Servername“ „Maschine\Instanz des Servers“ lauten.
  • SQL Server verwendet Port 1433 in TCP/IP.

TCP / IP

Named Pipes

Jetzt wollte Tom endlich abends einen leichten grünen Tee trinken, den ihre Nachbarin Sierra sehr gut zubereitete.

Named Pipes

Hier Tom und seinem Nachbar, Sierra, sind im selben physikalisch Standort, gegenseitiges Nächstensein. Sie kommunizieren über Intra-Netzwerk. Ebenso MS SQL-SERVER Bietet die Möglichkeit, über das zu interagieren Benannte Pfeife Protokoll. Hier der KUNDE und MS SQL-SERVER stehen in Verbindung über LAN.

Analogie: Lassen Sie uns Entitäten in den beiden oben genannten Szenarien zuordnen. Wir können Tom problemlos dem Client, Sierra dem SQL-Server, Neighbor dem LAN und schließlich dem Intra-Netzwerk dem Named Pipe Protocol zuordnen.

Notizen vom Schreibtisch Konfiguration/Installation:

  • Zur Verbindung über Named Pipe. Diese Option ist standardmäßig deaktiviert und muss vom SQL-Konfigurationsmanager 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-Rechner zum Server-Rechner.
  • TDS wurde zuerst von Sybase entwickelt und ist jetzt im Besitz von Microsoft

Relationale Engine

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

Wie im Architekturdiagramm dargestellt, gibt es sie 3 Hauptkomponenten der Relational Engine. Schauen wir uns die Komponenten im Detail an:

CMD-Parser

Sobald die Daten von der Protokollschicht empfangen wurden, werden sie an die Relational Engine weitergeleitet. „CMD-Parser“ ist die erste Komponente der Relational Engine, die die Abfragedaten empfängt. Die Hauptaufgabe des CMD-Parsers besteht darin, die Abfrage zu überprüfen Syntaktischer und semantischer Fehler. Schließlich ist es generiert einen Abfragebaum. Lassen Sie uns im Detail besprechen.

CMD-Parser

Syntaktische Prüfung:

  • Wie jede andere Programmiersprache verfügt auch MS SQL über vordefinierte Schlüsselwörter. Außerdem verfügt SQL Server über eine eigene Grammatik, die der SQL Server versteht.
  • SELECT, INSERT, UPDATE und viele andere gehören zu den vordefinierten Schlüsselwortlisten von MS SQL.
  • CMD Parser führt eine syntaktische Prüfung durch. Wenn die Eingaben der Benutzer nicht diesen Sprachsyntax- oder Grammatikregeln entsprechen, wird dies der Fall sein gibt einen Fehler zurück.

Beispiel: Nehmen wir an, ein Russe ging in ein japanisches Restaurant. Er bestellt Fastfood 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 vom SQL Server akzeptiert wird. Wenn dies der Fall ist, kann der SQL-Server es nicht verarbeiten und gibt daher eine Fehlermeldung zurück.

In den kommenden Tutorials erfahren Sie mehr über MS SQL-Abfragen. Betrachten Sie jedoch im Folgenden die grundlegendste Abfragesyntax als

SELECT * from <TABLE_NAME>;

Um nun einen Eindruck davon zu bekommen, was Syntax bewirkt, nehmen wir an, dass der Benutzer die grundlegende Abfrage wie folgt ausführt:

SELECR * from <TABLE_NAME>

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 vordefinierten Grammatik folgt. Hier erwartete CMD Parser „SELECT“.

Semantische Prüfung:

  • Dies wird durchgeführt von Normalizer.
  • In seiner einfachsten Form prüft es, ob der abgefragte Spaltenname und Tabellenname im Schema vorhanden ist. Und wenn es existiert, binden Sie es an Query. Dies wird auch als bezeichnet Buchbindung.
  • Mitplexity erhöht sich, wenn Benutzerabfragen VIEW enthalten. Normalizer führt die Ersetzung 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 zur semantischen Prüfung. Der Parser gibt eine Fehlermeldung aus, da der Normalizer die angeforderte Tabelle (USER_ID) nicht findet, da sie nicht existiert.

Abfragebaum erstellen:

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

Optimierer

Die Aufgabe des Optimierers besteht darin, einen Ausführungsplan für die Abfrage des Benutzers 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 zunächst 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 auf der Grundlage von Faktoren wie CPU-Auslastung, Speichernutzung und Eingabe-/Ausgabeanforderungen berechnet.

Die Rolle des Optimierers besteht darin, das zu finden günstigster, nicht bester, kostengünstigster Ausführungsplan.

Bevor wir näher auf die technischen Details des Optimizers eingehen, betrachten wir das folgende Beispiel aus der Praxis:

Beispiel:

Nehmen wir an, Sie möchten ein Online-Bankkonto eröffnen. Sie kennen bereits eine Bank, bei der die Kontoeröffnung maximal 2 Tage dauert. Sie haben aber auch eine Liste mit 20 anderen Banken, was weniger als 2 Tage dauern kann oder auch nicht. Sie können mit diesen Banken Kontakt aufnehmen, um herauszufinden, welche Banken weniger als 2 Tage benötigen. Nun kann es sein, dass Sie keine Bank finden, was weniger als zwei Tage dauert, und durch die Suchaktivität selbst geht zusätzliche Zeit verloren. Besser wäre es 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 aus Die Option ist die beste, nicht die billigste.

Ebenso MS SQL Optimizer arbeitet mit integrierten erschöpfenden/heuristischen Algorithmen. Das Ziel besteht darin, die Laufzeit der Abfrage zu minimieren. Alle Optimiereralgorithmen sind Eigentum von Microsoft und ein Geheimnis. Obwohl, Nachfolgend sind die allgemeinen Schritte aufgeführt, die vom MS SQL Optimizer ausgeführt werden. Optimierungssuchen erfolgen in drei Phasen, wie im folgenden Diagramm dargestellt:

Optimierer

Phase 0: Suche nach trivialem Plan:

  • Dies ist auch bekannt als Voroptimierungsphase.
  • In einigen Fällen kann es nur einen praktischen, umsetzbaren Plan geben, der als Trivialplan 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. Hinzu kommen die zusätzlichen Kosten für die Suche nach einem optimierten Plan, der überhaupt nicht erforderlich war.
  • Wenn kein Trivialplan gefunden wird, dann 1st Phase beginnt.

Phase 1: Suche nach Transaktionsverarbeitungsplänen

  • Dazu gehört auch die Suche nach Einfach und Complex Planen.
  • 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 aber nicht darauf beschränkt.
  • Wenn der einfache Plan jedoch nicht gefunden wird, dann mehr complex Plan wird gesucht. Es umfasst mehrere Indizes pro Tabelle.

Phase 2: Parallelverarbeitung und Optimierung.

  • Wenn keine der oben genannten Strategien funktioniert, sucht Optimizer nach Möglichkeiten der Parallelverarbeitung. Dies hängt von den Verarbeitungsfähigkeiten und der Konfiguration der Maschine ab.
  • Sollte dies immer noch nicht möglich sein, 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. Die Algorithmen der letzten Optimierungsphase sind Microsoft Anstand.

Abfrageausführer

Abfrageausführer

Aufrufe des Abfrageausführers Zugriffsmethode. Es stellt einen Ausführungsplan für die für die Ausführung erforderliche Datenabruflogik bereit. Sobald Daten von der Storage Engine empfangen werden, wird das Ergebnis auf der Protokollebene veröffentlicht. Schließlich werden die Daten an den Endbenutzer gesendet.

Speicher-Engine

Die Aufgabe der Storage Engine besteht darin, Daten in einem Speichersystem wie einer Festplatte oder einem SAN zu speichern und bei Bedarf abzurufen. Bevor wir uns eingehend mit der Speicher-Engine befassen, werfen wir einen Blick darauf, wie Daten darin gespeichert werden Datenbase und Art der verfügbaren Dateien.

Datendatei und Umfang:

Speicher-Engine

Datendatei speichert Daten physisch in Form von Datenseiten, 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 Pflege des Objekts erfolgt über Extents. Die Seite verfügt über einen Abschnitt namens „Seitenkopf“ mit einer Größe von 96 Byte, der die Metadateninformationen über die Seite wie Seitentyp, Seitennummer, Größe des verwendeten Speicherplatzes, Größe des freien Speicherplatzes und Zeiger auf die nächste und vorherige Seite enthält , usw.

Dateitypen

Dateitypen

  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, kann aber jede beliebige Ausdehnung haben.
  1. Sekundärdatei
  • Die Datenbank kann mehrere Sekundärdateien enthalten oder auch nicht.
  • Dies ist optional und enthält benutzerspezifische Daten.
  • Erweiterung ist .Naf normalerweise, kann aber jede beliebige Ausdehnung haben.
  1. Logdatei
  • Auch als Write-Ahead-Protokolle bekannt.
  • Erweiterung ist .ldf
  • Wird für die Transaktionsverwaltung verwendet.
  • Dies wird verwendet, um unerwünschte Instanzen wiederherzustellen. Führen Sie eine wichtige Aufgabe des Rollbacks auf nicht festgeschriebene Transaktionen durch.

Storage Engine besteht aus 3 Komponenten; Schauen wir sie uns im Detail an.

Zugriffsmethode

Es fungiert als Schnittstelle zwischen dem Abfrageausführer und dem Puffermanager/Transaktionsprotokollen.

Die Zugriffsmethode selbst führt keine Ausführung durch.

Die erste Aktion besteht darin, festzustellen, ob es sich bei der Abfrage um Folgendes handelt:

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

Abhängig vom Ergebnis geht die Zugriffsmethode wie folgt vorwing Schritte:

  1. Wenn die Abfrage ist DDL, SELECT-Anweisung, die Abfrage wird an die übergeben Puffermanager zur Weiterverarbeitung.
  2. Und wenn abfragen, ob DDL, NON-SELECT-Anweisung, wird die Abfrage an Transaction Manager übergeben. Dazu gehört vor allem die UPDATE-Anweisung.

Zugriffsmethode

Puffermanager

Der Puffermanager verwaltet Kernfunktionen für die folgenden Module:

  • Plan-Cache
  • Datenanalyse: Puffercache und Datenspeicherung
  • Schmutzige Seite

In diesem Abschnitt lernen wir Plan, Puffer und Datencache kennen. Wir werden schmutzige Seiten im Abschnitt „Transaktionen“ behandeln.

Puffermanager

Plan-Cache

  • Vorhandener Abfrageplan: Der Puffermanager prüft, ob der Ausführungsplan im gespeicherten Plan-Cache vorhanden ist. Wenn „Ja“, werden der Abfrageplan-Cache und der zugehörige Daten-Cache verwendet.
  • Erstmaliger Cache-Plan: Woher kommt der vorhandene Plan-Cache? Wenn der Plan zur erstmaligen Abfrageausführung ausgeführt wird und com istplex, ist es sinnvoll, es im Plane-Cache zu speichern. Dadurch wird eine schnellere Verfügbarkeit gewährleistet, wenn der SQL-Server das nächste Mal dieselbe Abfrage erhält. Es handelt sich also um nichts anderes als die Abfrage selbst, welche Planausführung gespeichert wird, wenn sie zum ersten Mal ausgeführt wird.

Datenanalyse: Puffercache und Datenspeicherung

Der Puffermanager bietet Zugriff auf die erforderlichen Daten. Die folgenden zwei Ansätze sind möglich, je nachdem, ob Daten im Datencache vorhanden sind oder nicht:

Puffercache – Soft Parsing:

Puffercache – Soft Parsing

Buffer Manager sucht im Datencache nach Daten im Puffer. Falls vorhanden, werden diese Daten vom Query Executor verwendet. Dies verbessert die Leistung, da die Anzahl der E/A-Vorgänge beim Abrufen von Daten aus dem Cache im Vergleich zum Abrufen von Daten aus dem Datenspeicher reduziert wird.

Datenspeicherung – Hard Parsing:

Datenspeicherung – Hartes Parsen

Wenn im Buffer Manager keine Daten vorhanden sind, werden die erforderlichen Daten im Datenspeicher gesucht. Außerdem speichert es Daten im Datencache für die zukünftige Verwendung.

Schmutzige Seite

Es wird als Verarbeitungslogik des Transaction Managers gespeichert. Im Abschnitt „Transaktionsmanager“ erfahren Sie mehr darüber.

Transaktionsmanager

Transaktionsmanager

Der Transaktionsmanager wird aufgerufen, wenn die Zugriffsmethode feststellt, dass es sich bei der Abfrage um eine Nicht-Select-Anweisung handelt.

Log-Manager

  • Log Manager verfolgt alle im System durchgeführten Aktualisierungen über Protokolle in Transaktionsprotokollen.
  • Protokolle haben Protokolliert die Sequenznummer mit der Transaktions-ID und dem Datenänderungsdatensatz.
  • Dies dient der Nachverfolgung Transaktion festgeschrieben und Transaktions-Rollback.

Sperrmanager

  • Während der Transaktion befinden sich die zugehörigen Daten im Datenspeicher im Sperrstatus. Dieser Vorgang wird vom Lock Manager durchgeführt.
  • Dieser Prozess stellt sicher Datenkonsistenz und -isolation. Auch als ACID-Eigenschaften bekannt.

Ausführungsprozess

  • Log Manager startet die Protokollierung und Lock Manager sperrt die zugehörigen Daten.
  • Die Kopie der Daten wird im Puffercache gespeichert.
  • Eine Kopie der zu aktualisierenden Daten wird im Protokollpuffer gespeichert und alle Ereignisse aktualisieren die Daten im Datenpuffer.
  • Seiten, die die Daten speichern, werden auch als bezeichnet Schmutzige Seiten.
  • Checkpoint- und Write-Ahead-Protokollierung: Dieser Prozess wird ausgeführt und markiert alle Seiten von Dirty Pages bis zur Festplatte, aber die Seite bleibt im Cache. Die Häufigkeit beträgt etwa 1 Lauf pro Minute. Die Seite wird jedoch zuerst vom Pufferprotokoll auf die Datenseite der Protokolldatei übertragen. Dies ist bekannt als Write-Ahead-Protokollierung.
  • Fauler Autor: Die Dirty-Seite kann im Speicher verbleiben. Wenn der SQL-Server eine große Auslastung feststellt und Pufferspeicher für eine neue Transaktion benötigt wird, werden Dirty Pages aus dem Cache freigegeben. Es funktioniert weiter LRU – Zuletzt verwendeter Algorithmus zum Bereinigen der Seite vom Pufferpool auf die Festplatte.

Zusammenfassung

  • Es gibt drei Arten von Client-Server-Architekturen: 1) Shared Memory 2) TCP/IP 3) Named Pipes
  • TDS, entwickelt von Sybase und jetzt im Besitz von Microsoftist ein Paket, das in Netzwerkpaketen für die Datenübertragung vom Client-Computer zum Server-Computer gekapselt ist.
  • Relational Engine enthält drei Hauptkomponenten:CMD-Parser: Dies ist für syntaktische und semantische Fehler verantwortlich und generiert schließlich einen Abfragebaum.Optimierer: Die Rolle des Optimierers besteht darin, den günstigsten und nicht den besten kosteneffizienten Ausführungsplan zu finden.

    Abfrageausführer: Der Abfrageausführer ruft die Zugriffsmethode auf und stellt einen Ausführungsplan für die für die Ausführung erforderliche Datenabruflogik bereit.

  • Es gibt drei Dateitypen: Primärdatei, Sekundärdatei und Protokolldateien.
  • Speicher-Engine: Hat folgendeswing wichtige KomponentenZugriffsmethode: Diese Komponente bestimmt, ob es sich bei der Abfrage um eine Select- oder Non-Select-Anweisung handelt. Ruft den Buffer and Transfer Manager entsprechend auf.Puffermanager: Der Puffermanager verwaltet Kernfunktionen für Plan-Cache, Datenanalyse und Dirty Page.

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