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 den verarbeiteten Daten. Im Folgenden wird die gesamte Architektur detailliert erläutert:

Wie das folgende Diagramm zeigt, besteht SQL Server aus drei Hauptkomponenten. ArchiStruktur:

1. Protokollschicht
2. Relationale Engine
3. Speicher-Engine

Protokollschicht – SNI

Die SQL Server-Protokollschicht, auch bekannt als Server-Netzwerkschnittstelle (SNI), unterstützt drei Arten von Client-Server-Architekturen. Jedes Protokoll dient einem anderen Netzwerkszenario. Das Verständnis dieser Protokolle ist unerlässlich, bevor man untersucht, wie Abfragen intern verarbeitet werden.

Geteilte Erinnerung

Stellen Sie sich ein Gespräch am frühen Morgen vor. Tom und seine Mutter befinden sich am selben Ort, nämlich zu Hause. Tom bestellt Kaffee, und seine Mutter serviert ihn ihm. Ähnlich verhält es sich mit SQL Server: Hierfür bietet das Shared-Memory-Protokoll die Möglichkeit, Client und Server auf demselben Rechner auszuführen. Beide kommunizieren über den gemeinsam genutzten Speicher, ohne dass Netzwerk-Overhead entsteht.

Analogie: Tom ist dem Client zugeordnet, Mom dem SQL Server, Home dem Rechner und die verbale Kommunikation dem Shared-Memory-Protokoll.

Konfigurationshinweise: In SQL Management StudioBei der Option „Servername“ für eine lokale Verbindung kann „.“, „localhost“, „127.0.0.1“ oder „Machine\Instance“ angegeben werden.

TCP / IP

Nehmen wir nun an, Tom möchte in einem 10 km entfernten Café einen Kaffee trinken. Tom ist zu Hause, und das Café befindet sich auf einem belebten Marktplatz. Die Kommunikation erfolgt über ein Mobilfunknetz. Ähnlich verhält es sich mit SQL Server. TCP / IP-Protokoll wenn sich Client und SQL Server auf separaten Rechnern befinden, die über ein Netzwerk verbunden sind.

Analogie: Tom wird dem Client zugeordnet, das Café dem SQL Server, das Zuhause und der Marktplatz entfernten Standorten und das Mobilfunknetz dem TCP/IP-Protokoll.

Konfigurationshinweise: In SQL Server Management Studio muss die Option „Servername“ für eine TCP/IP-Verbindung auf „Rechner\Instanz des Servers“ eingestellt sein. SQL Server verwendet standardmäßig Port 1433 für TCP/IP-Verbindungen.

Named Pipes

Schließlich möchte Tom grünen Tee von seiner Nachbarin Sierra. Da sie Nachbarn sind, befinden sie sich am selben Ort und kommunizieren über ein internes Netzwerk. Ähnlich verhält es sich mit dem Named-Pipe-Protokoll, das SQL Server bereitstellt, wenn Client und Server über ein lokales Netzwerk (LAN) verbunden sind.

Analogie: Tom ist dem Client zugeordnet, Sierra dem SQL Server, die Nachbarschaft dem LAN und das Intra-Netzwerk dem Named Pipe-Protokoll.

Konfigurationshinweise: Named Pipes ist standardmäßig deaktiviert und muss über den SQL-Konfigurationsmanager aktiviert werden.

Was ist TDS?

Nachdem die drei Arten von Client-Server-Architekturen nun klar sind, werfen wir einen Blick auf TDS:

• TDS steht für Tabular Data Stream.
• Alle drei Protokolle verwenden TDS-Pakete.
• TDS wird in Netzwerkpakete eingebettet, wodurch die Datenübertragung vom Client-Rechner zum Server-Rechner ermöglicht wird.
• TDS wurde ursprünglich von Sybase entwickelt und befindet sich jetzt im Besitz von Microsoft.

Die folgende Tabelle vergleicht die drei SQL Server-Verbindungsprotokolle:

Funktion	Geteilte Erinnerung	TCP / IP	Named Pipes
Netzwerkbereich	Gleiche Maschine	Fernzugriff (WAN/Internet)	Nur LAN
Standardport	N / A	1433	445
Leistung	Am schnellsten (kein Netzwerk-Overhead)	Gut (optimiert für WAN)	Gut (optimiert für LAN)
Standardmäßig aktiviert	Ja	Ja	Nein
besten Use Case	Lokale Entwicklung und Erprobung	Fernzugriff auf die Produktion	Vertrauenswürdige LAN-Umgebungen

Nachdem die Protokollschicht die Netzwerkkommunikation übernimmt, besteht der nächste Schritt in der SQL-Server-Architektur in der Verarbeitung der Abfrage selbst. Hier kommt die relationale Engine zum Einsatz.

Relationale Engine

Die relationale Engine wird auch als Abfrageprozessor bezeichnet. Sie enthält die SQL-Server-Komponenten, die festlegen, was eine Abfrage leisten soll und wie sie am effizientesten ausgeführt werden kann. Sie ist für die Ausführung von Benutzerabfragen verantwortlich, indem sie Daten von der Speicher-Engine anfordert und die zurückgegebenen Ergebnisse verarbeitet.

Wie im Architekturdiagramm dargestellt, besteht die Relationale Engine aus drei Hauptkomponenten:

CMD-Parser

Die von der Protokollschicht empfangenen Daten werden an die relationale Engine weitergeleitet. Der CMD-Parser ist die erste Komponente, die die Abfragedaten empfängt. Seine Hauptaufgabe besteht darin, die Abfrage auf syntaktische und semantische Fehler zu prüfen und anschließend einen Abfragebaum zu generieren.

Syntaktische Prüfung: Wie jede andere Programmiersprache verfügt auch SQL Server über einen vordefinierten Satz von Schlüsselwörtern und Grammatikregeln. SELECT, INSERT, UPDATE und viele andere gehören zu dieser Liste. Der CMD-Parser überprüft, ob die Eingabe diesen Regeln entspricht. Weicht die Benutzereingabe von der erwarteten Syntax ab, gibt der Parser eine Fehlermeldung zurück.

Ejemplo: Stellen Sie sich einen Russen vor, der ein japanisches Restaurant betritt und auf Russisch bestellt. Der Kellner versteht nur Japanisch und kann die Bestellung nicht aufnehmen. Genauso verhält es sich, wenn ein Benutzer „SELECR“ statt „SELECT“ eingibt: Der CMD-Parser gibt eine Fehlermeldung aus, da er das Schlüsselwort nicht erkennt.

Semantische Prüfung: Dies wird vom Normalisierer durchgeführt. Er prüft, ob die abgefragten Spaltennamen, Tabellennamen und andere Objekte im Schema vorhanden sind. Falls ja, bindet der Normalisierer sie an die Abfrage. Dieser Vorgang wird auch als Bindung bezeichnet. Enthält eine Benutzerabfrage eine Ansicht (VIEW), ersetzt der Normalisierer diese durch die intern gespeicherte Ansichtsdefinition.

Ejemplo: Laufen SELECT * from USER_ID würde dazu führen, dass der Parser während der semantischen Prüfung einen Fehler ausgibt, wenn die Tabelle USER_ID in der Datenbank nicht existiert.

Abfragebaum erstellen: Dieser Schritt erzeugt verschiedene Ausführungsbäume, die die unterschiedlichen Möglichkeiten zur Ausführung einer Abfrage darstellen. Alle Bäume liefern das gleiche gewünschte Ergebnis.

Optimierer

Der Optimizer erstellt einen Ausführungsplan für die Benutzerabfrage. Dieser Plan legt fest, wie die Abfrage ausgeführt wird. Nicht alle Abfragen werden optimiert. Die Optimierung bezieht sich auf DML-Befehle (Data Modification Language) wie SELECT, INSERT, DELETE und UPDATE. DDL-Befehle wie CREATE und ALTER werden nicht optimiert, sondern intern kompiliert.

Die Abfragekosten werden anhand von Faktoren wie CPU-Auslastung, Speichernutzung und Ein-/Ausgabebedarf berechnet. Die Aufgabe des Optimierers besteht darin, den kostengünstigsten Ausführungsplan zu finden, nicht unbedingt den absolut besten.

Ejemplo: Stellen Sie sich vor, Sie möchten ein Online-Bankkonto eröffnen. Eine Bank benötigt maximal zwei Tage. Sie haben außerdem eine Liste mit 20 anderen Banken, die möglicherweise schneller sind. Die Suche bei allen 20 Banken führt unter Umständen nicht zu einer schnelleren Option und kostet zudem Zeit. Es wäre besser gewesen, gleich die erste Bank zu wählen. Ähnlich verhält es sich mit dem SQL-Optimierer: Er verwendet sowohl vollständige als auch heuristische Algorithmen, um die Laufzeit von Abfragen zu minimieren.

Der Optimizer sucht in drei Phasen:

Phase 0: Suche nach einem trivialen Plan

Dies ist die Voroptimierungsphase. Für manche Anfragen existiert nur ein einziger praktikabler Ausführungsplan, der sogenannte triviale Plan. Eine weitere Suche ist nicht nötig, da jede zusätzliche Suche denselben Ausführungsplan nur mit Mehraufwand finden würde.

Phase 1: Suche nach Transaktionsverarbeitungsplänen

Dies umfasst die Suche nach einfachen und komplexen Speicherplänen. Die Suche nach einfachen Plänen nutzt eine statistische Analyse von Spalten- und Indexdaten, typischerweise beschränkt auf einen Index pro Tabelle. Wird kein einfacher Speicherplan gefunden, wird eine komplexere Suche unter Einbeziehung mehrerer Indizes pro Tabelle durchgeführt.

Phase 2: Parallelverarbeitung und Optimierung

Falls die vorherigen Strategien keinen geeigneten Plan liefern, sucht der Optimierer basierend auf den Rechenkapazitäten des Rechners nach Möglichkeiten der Parallelverarbeitung. Ist Parallelverarbeitung nicht möglich, beginnt eine abschließende Optimierungsphase, in der alle verbleibenden Optionen genutzt werden, um den bestmöglichen Ausführungsplan zu finden.

Abfrageausführer

Der Abfrageausführer ruft die Zugriffsmethode der Speicher-Engine auf. Er stellt einen Ausführungsplan bereit, der die für die Ausführung erforderliche Datenabruflogik enthält. Sobald die Daten von der Speicher-Engine empfangen wurden, wird das Ergebnis an die Protokollschicht übermittelt und an den Endbenutzer gesendet.

Nachdem die relationale Engine die Ausführung einer Abfrage festgelegt hat, übernimmt die Speicher-Engine die physischen Datenoperationen. Diese Schicht verwaltet, wie Daten gespeichert, zwischengespeichert und von der Festplatte abgerufen werden.

Speicher-Engine

Die Speicher-Engine ist für die Speicherung von Daten in einem Speichersystem wie einer Festplatte oder einem SAN und deren Abruf bei Bedarf zuständig. Bevor wir die Komponenten der Speicher-Engine untersuchen, ist es wichtig zu verstehen, wie Daten physisch gespeichert werden.

Datendateien und Extents

Datendateien speichern Daten physisch in Form von Datenseiten, wobei jede Seite eine Größe von 8 KB hat. Dies ist die kleinste Speichereinheit in SQL ServerDatenseiten sind logisch in Extents gruppiert. Kein Objekt wird direkt einer einzelnen Seite zugeordnet; die Verwaltung erfolgt stattdessen über Extents. Jede Seite verfügt über einen Seitenkopf (96 Byte), der Metadaten wie Seitentyp, Seitennummer, belegten Speicherplatz, freien Speicherplatz und Verweise auf die nächste und vorherige Seite enthält.

Datentypen

Primärdatei: Jede Datenbank enthält eine Hauptdatei. Diese speichert alle wichtigen Daten zu Tabellen, Ansichten, Triggern und anderen Objekten. Die Dateiendung ist üblicherweise .mdf, kann aber beliebig sein.

Sekundärdatei: Eine Datenbank kann mehrere sekundäre Dateien enthalten, muss dies aber nicht. Diese sind optional und enthalten benutzerspezifische Daten. Die Dateiendung ist üblicherweise .ndf, kann aber jede beliebige sein.

Protokolldatei: Auch bekannt als Write-Ahead-Logs. Die Dateiendung ist .ldf. Protokolldateien werden für die Transaktionsverwaltung, die Wiederherstellung nach unerwünschten Vorgängen und das Rollback nicht abgeschlossener Transaktionen verwendet.

Die Speicher-Engine besteht aus drei Hauptkomponenten. Jede von ihnen spielt eine spezifische Rolle bei der Verwaltung des Datenzugriffs und der Datenintegrität.

Zugriffsmethode

Die Zugriffsmethode fungiert als Schnittstelle zwischen dem Abfrageausführer und dem Buffer Manager oder Transaktionsprotokolle. Es führt die Ausführung nicht selbst durch, sondern bestimmt den Abfragetyp:

• Wenn die Abfrage eine SELECT-Anweisung (DML), es wird weitergegeben an Buffer Manager für die weitere Bearbeitung.
• Wenn die Abfrage eine Nicht-SELECT-Anweisung (DDL und DML)Sie wird an den Transaktionsmanager übergeben. Dies umfasst hauptsächlich UPDATE-, INSERT- und DELETE-Anweisungen.

Buffer Geschäftsführer

Das Buffer Manager verwaltet Kernfunktionen für Plan Cache, Datenanalyse und die Behandlung geänderter Seiten.

Plan-Cache

Vorhandener Abfrageplan: Das Buffer Der Manager prüft, ob der Ausführungsplan im gespeicherten Plancache vorhanden ist. Falls ja, werden der zwischengespeicherte Abfrageplan und der zugehörige Datencache direkt verwendet.

Erstmaliger Cache-Plan: Ist ein Ausführungsplan für eine erstmalige Abfrage komplex, wird er im Plancache gespeichert. Dies gewährleistet eine schnellere Verfügbarkeit, wenn SQL Server die gleiche Abfrage das nächste Mal empfängt.

Datenanalyse: Buffer Cache und Datenspeicherung

Das Buffer Der Manager ermöglicht den Zugriff auf die benötigten Daten. Je nachdem, ob Daten im Cache vorhanden sind, sind zwei Vorgehensweisen möglich:

Buffer Cache – Soft Parsing

Das Buffer Der Manager sucht nach Daten in der Buffer Cache. Sind die Daten vorhanden, verwendet der Abfrageausführer sie direkt. Dies verbessert die Leistung, da das Abrufen von Daten aus dem Cache weniger E/A-Operationen erfordert als das Abrufen vom Festplattenspeicher.

Datenspeicherung – Hard Parsing

Wenn keine Daten vorhanden sind Buffer Im Cache werden die benötigten Daten im Datenspeicher auf der Festplatte gesucht. Die Daten werden dann auch im Datencache zur späteren Verwendung gespeichert.

Transaktionsmanager

Der Transaktionsmanager wird aufgerufen, wenn die Zugriffsmethode feststellt, dass eine Abfrage keine SELECT-Anweisung ist. Er gewährleistet Datenkonsistenz und -beständigkeit durch mehrere Unterkomponenten:

Log-Manager

Der Protokollmanager speichert track aller im System durchgeführten Aktualisierungen werden in Transaktionsprotokollen gespeichert. Jeder Protokolleintrag enthält eine Protokollsequenznummer, die Transaktions-ID und den Datensatz zur Datenänderung. Dieser Mechanismus tracks bestätigte und rückgängig gemachte Transaktionen.

Sperrmanager

Während einer Transaktion werden die zugehörigen Daten im Speicher gesperrt. Der Sperrmanager steuert diesen Prozess und gewährleistet so Datenkonsistenz und -isolation. Diese Eigenschaften werden auch als ACID (Actualized Content Delivery Network) bezeichnet.AtomEisigkeit, Konsistenz, Isolation, Haltbarkeit).

Ausführungsprozess

Der Ausführungsprozess umfasst folgende Schritte:

1. Der Log-Manager startet die Protokollierung und der Sperrmanager sperrt die zugehörigen Daten.
2. Eine Kopie der Daten wird im Buffer Zwischenspeicher.
3. Eine Kopie der zu aktualisierenden Daten wird im Protokoll geführt. Bufferund alle Ereignisse aktualisieren die Daten in den Daten Buffer.
4. Seiten, die geänderte Daten speichern, werden als Seiten bezeichnet Schmutzige Seiten.

Checkpoint- und Write-Ahead-Protokollierung

Der Prüfpunktprozess läuft etwa einmal pro Minute und markiert alle geänderten Seiten zum Schreiben auf die Festplatte. Die Seite wird jedoch zuerst von der Protokolldatei auf die Datenseite geschrieben. Buffer Protokollierung. Dieser Mechanismus wird als Write-Ahead-Logging bezeichnet. Die geänderten Seiten bleiben auch nach dem Schreiben auf die Festplatte im Cache erhalten.

Faul Writer

Wenn SQL Server eine hohe Last feststellt und Pufferspeicher für neue Transaktionen benötigt wird, gibt er geänderte Seiten aus dem Cache frei. Writer arbeitet mit dem LRU-Algorithmus (Least Recently Used), um Seiten aus dem Pufferpool auf die Festplatte zu schreiben.

Wie SQL Server eine Abfrage von Anfang bis Ende verarbeitet

Das Verständnis jeder einzelnen Schicht ist wertvoll, aber erst das Verständnis ihres Zusammenspiels verdeutlicht das Gesamtbild. Wenn eine Clientanwendung eine SQL-Abfrage sendet, läuft folgende Sequenz ab:

Das Protokollschicht empfängt die Anfrage über Shared Memory, TCP/IP oder Named Pipes und verpackt sie in ein TDS-Paket. Relationale Engine Anschließend übernimmt der CMD-Parser: Er prüft Syntax und Semantik, der Optimizer generiert den günstigsten Ausführungsplan, und der Query Executor beginnt mit dem Datenabruf.

Der Abfrageausführer ruft den Speichermodul Zugriffsmethode, die SELECT-Abfragen an die Buffer Manager- und Änderungsanfragen an den Transaktionsmanager. Buffer Der Manager prüft den Plancache und Buffer Zunächst werden die Daten zwischengespeichert (Soft Parsing). Sind die Daten nicht zwischengespeichert, erfolgt ein Lesevorgang von der Festplatte (Hard Parsing). Bei Schreibvorgängen koordiniert der Transaktionsmanager den Protokollmanager, den Sperrmanager und den Prüfpunktprozess, um die ACID-Konformität sicherzustellen.

Sobald die Speicher-Engine die angeforderten Daten zurückgibt, formatiert die relationale Engine das Ergebnis-Set, und die Protokollschicht liefert es über dasselbe TDS-Protokoll an die Client-Anwendung zurück.

Wie man das richtige Protokoll für SQL Server-Verbindungen auswählt

Die Wahl des richtigen Protokolls hängt von der physischen Beziehung zwischen Client und Server sowie von den Leistungsanforderungen ab.

Gemeinsamen Speicher verwenden Wenn die Clientanwendung auf demselben Rechner wie der SQL Server ausgeführt wird, ist dies die schnellste Option, da der gesamte Netzwerk-Overhead entfällt. Sie eignet sich ideal für die lokale Entwicklung, das Testen und die Bereitstellung auf einem einzelnen Rechner.

Verwenden Sie TCP/IP. Wenn sich Client und Server auf unterschiedlichen Rechnern befinden, die über ein WAN oder das Internet verbunden sind, kommt dieses Protokoll zum Einsatz. Es ist das am häufigsten verwendete Protokoll in Produktionsumgebungen. SQL Server lauscht standardmäßig auf Port 1433, und dieses Protokoll unterstützt verschlüsselte Verbindungen via TLS.

Benannte Pipes verwenden Wenn sich Client und Server im selben vertrauenswürdigen LAN befinden und die Leistung in internen Netzwerken Priorität hat, sind Named Pipes standardmäßig deaktiviert und müssen über den SQL Server-Konfigurationsmanager aktiviert werden. In modernen Bereitstellungen ist diese Funktion weniger verbreitet, aber für ältere Intranet-Anwendungen weiterhin nützlich.

Häufig gestellte Fragen