SQL-Server 2019

Microsoft SQL Server entstand aus einer Zusammenarbeit der beiden Unternehmen Microsoft und Sybase Ende der 1980er Jahre. 1989 wurde die erste Version fĂŒr das von Microsoft und IBM entwickelte Betriebssystem OS/2 veröffentlicht. Das Produkt entsprach prinzipiell dem Sybase SQL Server 4.0 fĂŒr Unix und VMS. 1992 erschien der Microsoft SQL Server 4.2 fĂŒr OS/2 1.3. Im Anschluss mit der Veröffentlichung von Windows NT im Jahr 1993 erschien schon bald Microsoft SQL Server 4.21, der anstatt auf OS/2 auf Windows NT als Betriebssystem setzte. In dieser Zeit lockerte sich außerdem die Kooperation zwischen Microsoft und Sybase. Im Jahr 1995 erschien mit Microsoft SQL Server 6.0 eine eigenstĂ€ndige Weiterentwicklung der Kooperation, dem 1996 die Version 6.5 folgte. Mit der Version 7.0, die im Jahr 1999 erschien, verabschiedete sich Microsoft von der mit Sybase entwickelten Codebasis und brachte eine vollkommen neue Datenbank-Engine auf den Markt. Diese war auch Basis in den darauffolgenden Versionen ab SQL Server 2000.

Ab der Version SQL Server 2017 wurde der Support fĂŒr folgende Linux-Systeme ergĂ€nzt: Red Hat Enterprise Linux, SUSE Linux Enterprise Server, Ubuntu und Docker.

Der Microsoft SQL Server ist ein relationales Datenbankmanagementsystem

Erstellen Sie intelligente, geschĂ€ftskritische Anwendungen mit einer skalierbaren Hybrid-Datenbankplattform, in die alles integriert ist – von In-Memory-Leistung und erweiterter Sicherheit bis hin zur Analyse umfangreicher DatenbestĂ€nde direkt in der Datenbank.

BranchenfĂŒhrer
Entwickeln Sie geschĂ€ftskritische, intelligente Apps zur Onlinetransaktionsverarbeitung (OLTP) mit hoher Skalierbarkeit und VerfĂŒgbarkeit.

Erweiterte Sicherheit
SchĂŒtzen Sie sowohl gespeicherte als auch ĂŒbertragene Daten. SQL Server ist seit sechs Jahren die am wenigsten anfĂ€llige Datenbank in der NIST Vulnerabilities Database.

Mobile End-to-End-BI
Verwandeln Sie Daten in verwertbare Erkenntnisse. Ermöglichen Sie Erkenntnisgewinn auf allen Online- und OfflinegerĂ€ten – zu einem FĂŒnftel der Kosten anderer Self-Service-Lösungen.

Fortschrittliches In-Database Analytics
Analysieren Sie Daten mit der beliebten Statistiksprache R direkt in Ihrer SQL Server-Datenbank – ohne die Daten verschieben zu mĂŒssen.

Entwickelt fĂŒr die Hybrid Cloud
Erhalten Sie eine konsistente Plattform und die Werkzeuge fĂŒr eine einfachere WorkloadmobilitĂ€t zwischen Rechenzentrum, Private Cloud oder Microsoft Azure.


Der SQL Server ist ein relationales Datenbankmanagementsystem, das sich am Standard der aktuellen SQL-Version orientiert. Der Microsoft SQL Server liegt in verschiedenen Editionen vor, die ein vielfĂ€ltiges Angebot abdecken. Die Editionen unterscheiden sich vor allem im Preis, ihren Funktionen und HardwareeinschrĂ€nkungen. Der MSSQL-Server kann auch als Data-Warehouse genutzt werden, indem es den Mitarbeitern in einem Unternehmen eine Sicht auf das GeschĂ€ft und dessen Daten ermöglicht. Durch seine Business-Intelligence-Plattform bietet er eine skalierbare Infrastruktur, die es der IT ermöglicht, die Nutzung von Business Intelligence im gesamten Unternehmen zu fördern und Business Intelligence dort bereitzustellen, wo Anwender es wĂŒnschen. Der SQL Server besteht aus vielen Services, wie z. B. Analysis Services, Reporting Services und Integration Services, und Tools, z. B. den SQL Server Data Tools (SSDT).

Microsoft SQL Server verwendet fĂŒr Datenbankabfragen die SQL-Variante T-SQL (Transact-SQL). T-SQL fĂŒgt hauptsĂ€chlich zusĂ€tzliche Syntax zum Gebrauch in Stored Procedures und Transaktionen hinzu. Weiterhin unterstĂŒtzt MSSQL OLE DB und ODBC (Open Database Connectivity).

Seit SQL Server 2005 (Codename „Yukon“) werden unter anderem Programmiersprachen, welche auf der .NET CLR laufen, fĂŒr das Erstellen von Stored Procedures unterstĂŒtzt. Mit Visual Studio wird seit 2005 auch eine passende IDE mitgeliefert.

In einer Windows-Installation (sowohl auf Servern als auch auf Individualsystemen) können gleichzeitig mehrere (gleiche oder unterschiedliche) MSSQL-Server laufen, die als Instanzen bezeichnet werden. Jede Instanz kann wiederum mehrere Datenbanken enthalten.


Microsoft bietet eine Reihe von Techniken an, um Daten redundant zu speichern.

 

Clustering

Replication

Log Shipping

Mirroring

AlwaysOn
Availability Groups

AlwaysOn
Failover Cluster Instance

EinfĂŒhrung

SQL Server 6.5

SQL Server 7.0

SQL Server 2000

SQL Server 2005

SQL Server 2012

SQL Server 2012

Mindest. Lizenz

Standard / (Web)

Enterprise: Peer-To-Peer
Standard: Snapshot /Transactional / Merge

Standard / (Web)

Standard

Enterprise

Standard

Max. Anzahl Kopien

15

unbegrenzt

unbegrenzt

1

3

unbegrenzt

ZusÀtzliche Infrastruktur

geteilte Netzwerkresource

(Distributor Server)

Monitoring Server
(Optional)

Witness Server
(Optional)

—

geteilte Netzwerkresource

Failover

manuell /
automatisch

nur manuell

nur manuell

manuell /
automatisch

manuell /
automatisch

manuell /
automatisch

Bezeichnung Quelle

Node

Publisher

Primary

Principal

Primary

Node

Bezeichnung Kopie

Node

Subscriber

Secondary

Mirror

Secondary

Node

Sicherung von

Server / Instanz

Datenbank(-objekten)

Datenbank

Datenbank

Datenbank(-gruppe)

Server / Instanz

Es ist möglich, gewisse Redundanztechnologien gleichzeitig parallel zu betreiben – zum Beispiel die Datenbankreplikation zusammen mit einer AlwaysOn-Availability-Group. Die „Datenbankreplikation“ teilt sich weiterhin in die Untervarianten „Snapshot Replication“, „Transactional Replication“, „Merge Replication“ und „Peer-To-Peer-Replication“


Es ist nun auch möglich, SQL-Server-Datendateien in Azure abzulegen und eine SQL-Server-Datenbank auf einem virtuellen Computer in Azure zu hosten. VerschlĂŒsselung von Sicherungen wĂ€hrend des Sicherungsvorganges mittels AES 128, AES 192, AES 256 und Triple DES wurde hinzugefĂŒgt.

Die UnterstĂŒtzung von Failoverclusterinstanzen wurde verbessert.


Erstellen Sie geschÀftskritische intelligente Anwendungen

Das neue SQL Server 2016 bietet bahnbrechende geschĂ€ftskritische In-Memory-Leistung, Betriebsanalyse in Echtzeit, tiefere Einblicke in Ihre Daten dank integrierter moderner Analysen und neuen umfangreichen Visualisierungen auf allen mobilen GerĂ€ten. Es ist die erste in der Cloud erstellte Datenbank und sie setzt neue MaßstĂ€be bei der Innovationsgeschwindigkeit. Diese Hybridcloud-Plattform unterstĂŒtzt Sie bei der Erstellung von Lösungen, mit denen Kunden ihre vorhandenen Investitionen vor Ort ergĂ€nzen können.


AbhĂ€ngig von der Version des Microsoft SQL Servers gibt es verschiedene Editionen des Produkts. Die Editionen unterscheiden sich entweder in ihrem Funktionsumfang oder der maximalen HardwareunterstĂŒtzung. So steht höherwertigen Editionen der Zugriff auf mehr Arbeitsspeicher oder mehr Prozessoren zur VerfĂŒgung, wodurch sie mehr Leistung bieten. Der jeweilige Name einer Edition deutet dabei auf seinen angedachten Einsatzort, respektive Einsatzzweck hin. So wird beispielsweise die unter SQL Server 2008 teuerste Version Datacenter-Edition fĂŒr große Rechenzentren verwendet, wĂ€hrend die SQL Server Web Edition speziell fĂŒr Webhoster oder Websites gedacht ist.

Die folgende Tabelle listet eine Übersicht verschiedener SQL-Server-Versionen und ihrer erhĂ€ltlichen Editionen:

Version

Enterprise

Datacenter

Business Intelligence

Standard

Express

Workgroup

Web

Developer

SQL Server 2017

Ja

Nein

Nein

Ja

Ja

Nein

Ja

Ja

SQL Server 2016

Ja

Nein

Nein

Ja

Ja

Nein

Ja

Nein

SQL Server 2014

Ja

Nein

Ja

Ja

Ja

Nein

Ja

Nein

SQL Server 2012

Ja

Nein

Ja

Ja

Ja

Nein

Ja

Nein

SQL Server 2008 / 2008 R2

Ja

Ja

Nein

Ja

Ja

Ja

Ja

Nein

SQL Server 2005

Ja

Nein

Nein

Ja

Ja

Ja

Nein

Nein

SQL Server 2000

Ja

Nein

Nein

Ja

Ja (MSDE)

Ja

Nein

Nein


Die Protokollschicht implementiert die externe Schnittstelle zu SQL Server. Alle Operationen, die auf SQL Server aufgerufen werden können, werden ĂŒber ein Microsoft-definiertes Format, das als Tabular Data Stream (TDS) bezeichnet wird, an dieses ĂŒbertragen. TDS ist ein Anwendungsschichtprotokoll, das zum Übertragen von Daten zwischen einem Datenbankserver und einem Client verwendet wird. UrsprĂŒnglich von Sybase Inc. fĂŒr ihre Sybase SQL Server-relationale Datenbank-Engine im Jahr 1984 entworfen und entwickelt, und spĂ€ter von Microsoft in Microsoft SQL Server, können TDS-Pakete in andere physische transportabhĂ€ngige Protokolle eingebettet werden, einschließlich TCP / IP, Named Pipes und Shared Erinnerung. Folglich ist der Zugriff auf SQL Server ĂŒber diese Protokolle möglich. DarĂŒber hinaus ist die SQL Server-API auch ĂŒber Webdienste verfĂŒgbar.
Datenspeicher

Datenspeicher ist eine Datenbank, bei der es sich um eine Sammlung von Tabellen mit typisierten Spalten handelt. SQL Server unterstĂŒtzt verschiedene Datentypen, einschließlich primitiver Typen wie Integer, Float, Decimal, Char (einschließlich Zeichenketten), Varchar (Zeichenketten variabler LĂ€nge), BinĂ€r (fĂŒr unstrukturierte Datenblobs), Text (fĂŒr Textdaten) und anderen . Das Runden von Gleitkommazahlen auf Ganzzahlen verwendet entweder die symmetrische arithmetische Rundung oder die symmetrische Abrundung (fix) abhĂ€ngig von Argumenten: SELECT Runde (2.5, 0) ergibt 3.

Mit Microsoft SQL Server können auch benutzerdefinierte Verbundtypen (UDTs) definiert und verwendet werden. Außerdem werden Serverstatistiken als virtuelle Tabellen und Sichten (Dynamic Management Views oder DMVs) verfĂŒgbar gemacht. ZusĂ€tzlich zu Tabellen kann eine Datenbank auch andere Objekte enthalten, einschließlich Sichten, gespeicherten Prozeduren, Indizes und EinschrĂ€nkungen, zusammen mit einem Transaktionslog. Eine SQL Server-Datenbank kann maximal 231 Objekte enthalten und kann mehrere Dateien auf Betriebssystemebene mit einer maximalen DateigrĂ¶ĂŸe von 260 Byte (1 Exabyte) umfassen. Die Daten in der Datenbank werden in primĂ€ren Dateien mit der Erweiterung .mdf gespeichert. SekundĂ€re Datendateien, die mit der Endung .ndf gekennzeichnet sind, ermöglichen die Verteilung der Daten einer einzelnen Datenbank auf mehrere Dateien und optional auf mehrere Dateisysteme. Protokolldateien werden mit der Erweiterung .ldf gekennzeichnet.

Speicherplatz, der einer Datenbank zugewiesen ist, ist in sequenziell nummerierte Seiten von jeweils 8 KB GrĂ¶ĂŸe unterteilt. Eine Seite ist die Basiseinheit von E / A fĂŒr SQL Server-Operationen. Eine Seite ist mit einem 96-Byte-Header markiert, der Metadaten ĂŒber die Seite einschließlich Seitenzahl, Seitentyp, freiem Speicherplatz auf der Seite und die ID des Objekts speichert, das sie besitzt. Der Seitentyp definiert die auf der Seite enthaltenen Daten: in der Datenbank gespeicherte Daten, Index, Zuweisungskarte, die Informationen darĂŒber enthĂ€lt, wie Seiten Tabellen und Indizes zugeordnet sind, Karte Ă€ndern, die Informationen ĂŒber die Änderungen enthĂ€lt, die seit der letzten Sicherung oder Protokollierung an anderen Seiten vorgenommen wurden oder große Datentypen wie Bild oder Text enthalten. WĂ€hrend die Seite die Grundeinheit einer E / A-Operation ist, wird der Speicherplatz tatsĂ€chlich in einem Umfang verwaltet, der aus 8 Seiten besteht. Ein Datenbankobjekt kann entweder alle 8 Seiten in einem Umfang ("uniform extent") oder einen Umfang mit bis zu 7 weiteren Objekten ("mixed extent") umfassen. Eine Zeile in einer Datenbanktabelle kann nicht mehr als eine Seite umfassen und ist daher auf 8 KB beschrĂ€nkt. Wenn die Daten jedoch 8 KB ĂŒberschreiten und die Zeile Varchar- oder Varbinary-Daten enthĂ€lt, werden die Daten in diesen Spalten auf eine neue Seite (oder möglicherweise eine Folge von Seiten, eine Zuordnungseinheit genannt) verschoben und durch einen Zeiger auf die Daten ersetzt.

FĂŒr die physische Speicherung einer Tabelle sind ihre Zeilen in eine Reihe von Partitionen (nummeriert von 1 bis n) unterteilt. Die PartitionsgrĂ¶ĂŸe ist benutzerdefiniert; StandardmĂ€ĂŸig befinden sich alle Zeilen in einer einzelnen Partition. Eine Tabelle ist in mehrere Partitionen aufgeteilt, um eine Datenbank ĂŒber einen Computer-Cluster zu verteilen. Zeilen in jeder Partition werden entweder in der B-Struktur oder in der Heap-Struktur gespeichert. Wenn die Tabelle einen zugeordneten gruppierten Index zum schnellen Abrufen von Zeilen enthĂ€lt, werden die Zeilen entsprechend ihrer Indexwerte in einer Reihenfolge gespeichert, wobei ein B-Baum den Index bereitstellt. Die Daten befinden sich im Blattknoten der BlĂ€tter und andere Knoten speichern die Indexwerte fĂŒr die Blattdaten, die von den jeweiligen Knoten erreichbar sind. Wenn der Index nicht gruppiert ist, werden die Zeilen nicht nach den IndexschlĂŒsseln sortiert. Eine indizierte Sicht hat die gleiche Speicherstruktur wie eine indizierte Tabelle. Eine Tabelle ohne Clustered-Index wird in einer ungeordneten Heap-Struktur gespeichert. Die Tabelle kann jedoch nicht gruppierte Indizes enthalten, um ein schnelles Abrufen von Zeilen zu ermöglichen. In einigen Situationen hat die Heapstruktur Leistungsvorteile gegenĂŒber der Clusterstruktur. Sowohl Heaps als auch B-Trees können mehrere Zuordnungseinheiten umfassen.


SQL Server puffert Seiten im RAM, um DatentrĂ€ger-E / A zu minimieren. Jede 8-KB-Seite kann im Speicher gepuffert werden, und die Menge aller momentan gepufferten Seiten wird als Puffer-Cache bezeichnet. Die Menge an Speicher, die fĂŒr SQL Server verfĂŒgbar ist, entscheidet darĂŒber, wie viele Seiten im Speicher zwischengespeichert werden. Der Puffer-Cache wird vom Puffer-Manager verwaltet. Entweder das Lesen von oder das Schreiben auf irgendeine Seite kopiert es in den Puffercache. Nachfolgende Lese- oder SchreibvorgĂ€nge werden auf die In-Memory-Kopie und nicht auf die On-Disc-Version umgeleitet. Die Seite wird nur dann vom Puffermanager auf der Disk aktualisiert, wenn der In-Memory-Cache seit einiger Zeit nicht mehr referenziert wurde. Beim Schreiben von Seiten zurĂŒck auf die Platte wird asynchrone E / A verwendet, wobei die E / A-Operation in einem Hintergrundthread ausgefĂŒhrt wird, so dass andere Operationen nicht auf den Abschluss der E / A-Operation warten mĂŒssen. Jede Seite wird zusammen mit ihrer PrĂŒfsumme geschrieben, wenn sie geschrieben wird. Beim Lesen der Seite wird ihre PrĂŒfsumme erneut berechnet und mit der gespeicherten Version abgeglichen, um sicherzustellen, dass die Seite in der Zwischenzeit nicht beschĂ€digt oder manipuliert wurde.
NebenlÀufigkeit und Sperren

SQL Server ermöglicht mehreren Clients, dieselbe Datenbank gleichzeitig zu verwenden. Daher muss der gleichzeitige Zugriff auf gemeinsam genutzte Daten gesteuert werden, um die DatenintegritĂ€t sicherzustellen - wenn mehrere Clients die gleichen Daten aktualisieren oder Clients versuchen, Daten zu lesen, die gerade von einem anderen Client geĂ€ndert werden. SQL Server bietet zwei Modi der Steuerung des gemeinsamen Zugriffs: pessimistische NebenlĂ€ufigkeit und optimistische ParallelitĂ€t. Wenn pessimistische Gleichzeitigkeitskontrolle verwendet wird, steuert SQL Server den gleichzeitigen Zugriff mithilfe von Sperren. Sperren können entweder gemeinsam oder exklusiv sein. Die exklusive Sperre gewĂ€hrt dem Benutzer exklusiven Zugriff auf die Daten - kein anderer Benutzer kann auf die Daten zugreifen, solange die Sperre gehalten wird. Freigegebene Sperren werden verwendet, wenn Daten gelesen werden - mehrere Benutzer können Daten lesen, die mit einer gemeinsamen Sperre gesperrt sind, aber keine exklusive Sperre erhalten. Letzterer mĂŒsste warten, bis alle freigegebenen Sperren freigegeben wurden.

Sperren können auf verschiedenen GranularitĂ€tsebenen angewendet werden - auf ganzen Tabellen, Seiten oder sogar pro Reihe auf Tabellen. Bei Indizes kann es sich entweder um den gesamten Index oder um IndexblĂ€tter handeln. Die zu verwendende GranularitĂ€t wird vom Datenbankadministrator fĂŒr jede Datenbank festgelegt. Ein feingranulares Schließsystem ermöglicht zwar mehr Benutzern die gleichzeitige Verwendung der Tabelle oder des Indexes, erfordert jedoch mehr Ressourcen und fĂŒhrt daher nicht automatisch zu einer höheren Leistung. SQL Server enthĂ€lt außerdem zwei leichtere Lösungen zum gegenseitigen Ausschluss - Latches und Spinlocks -, die weniger robust sind als Sperren, aber weniger Ressourcenintensiv sind. SQL Server verwendet sie fĂŒr DMVs und andere Ressourcen, die normalerweise nicht ausgelastet sind. SQL Server ĂŒberwacht auch alle Worker-Threads, die Sperren erhalten, um sicherzustellen, dass sie nicht in Deadlocks enden. In diesem Fall ergreift SQL Server Abhilfemaßnahmen, die in vielen FĂ€llen einen der in einem Deadlock verwickelten Threads beenden und zurĂŒcksetzen die Transaktion, die es begonnen hat. Um das Sperren zu implementieren, enthĂ€lt SQL Server den Sperrmanager. Der Sperrmanager unterhĂ€lt eine speicherinterne Tabelle, die die Datenbankobjekte verwaltet und diese ggf. zusammen mit anderen Metadaten ĂŒber die Sperre sperrt. Der Zugriff auf ein beliebiges gemeinsam genutztes Objekt wird durch den Sperrmanager vermittelt, der entweder Zugriff auf die Ressource gewĂ€hrt oder sie blockiert.

SQL Server bietet auch den optimistischen Mechanismus zur Kontrolle des gemeinsamen Zugriffs, der dem in anderen Datenbanken verwendeten Multiversions-Concurrency-Steuerelement Ă€hnelt. Der Mechanismus ermöglicht das Erzeugen einer neuen Version einer Zeile, wann immer die Zeile aktualisiert wird, im Gegensatz zum Überschreiben der Zeile, d. H. Eine Zeile wird zusĂ€tzlich durch die ID der Transaktion identifiziert, die die Version der Zeile erzeugt hat. Sowohl die alte als auch die neue Version der Zeile werden gespeichert und verwaltet, obwohl die alten Versionen aus der Datenbank in eine Systemdatenbank mit dem Namen Tempdb verschoben werden. Wenn eine Zeile gerade aktualisiert wird, werden alle anderen Anforderungen nicht blockiert (im Gegensatz zum Sperren), sondern in der Ă€lteren Version der Zeile ausgefĂŒhrt. Wenn es sich bei der anderen Anfrage um eine Update-Anweisung handelt, ergeben sich zwei verschiedene Versionen der Zeilen. Beide werden von der Datenbank gespeichert und durch die entsprechenden Transaktions-IDs identifiziert.


Der Hauptmodus zum Abrufen von Daten aus einer SQL Server-Datenbank fragt nach. Die Abfrage wird unter Verwendung einer Variante von SQL ausgedrĂŒckt, die T-SQL genannt wird, ein Dialekt, den Microsoft SQL Server aufgrund seines VermĂ€chtnisses mit Sybase SQL Server teilt. Die Abfrage gibt deklarativ an, was abgerufen werden soll. Es wird vom Abfrageprozessor verarbeitet, der die Abfolge der Schritte ermittelt, die zum Abrufen der angeforderten Daten erforderlich sind. Die Reihenfolge der Aktionen, die zum AusfĂŒhren einer Abfrage erforderlich sind, wird als Abfrageplan bezeichnet. Es gibt möglicherweise mehrere Möglichkeiten, dieselbe Abfrage zu verarbeiten. FĂŒr eine Abfrage, die eine Join-Anweisung und eine Select-Anweisung enthĂ€lt, fĂŒhrt das AusfĂŒhren von Join in beiden Tabellen und das anschließende AusfĂŒhren von Select fĂŒr die Ergebnisse zu demselben Ergebnis wie das AuswĂ€hlen aus jeder Tabelle und dann AusfĂŒhren des Joins, fĂŒhrt jedoch zu einer anderen AusfĂŒhrung PlĂ€ne. In diesem Fall wĂ€hlt SQL Server den Plan aus, von dem erwartet wird, dass er die Ergebnisse in der kĂŒrzest möglichen Zeit liefert. Dies wird Abfrageoptimierung genannt und wird vom Abfrageprozessor selbst durchgefĂŒhrt.

SQL Server enthĂ€lt einen kostenbasierten Abfrageoptimierer, der versucht, die Kosten im Hinblick auf die Ressourcen zu optimieren, die zum AusfĂŒhren der Abfrage benötigt werden. Bei einer Abfrage prĂŒft der Abfrageoptimierer das Datenbankschema, die Datenbankstatistiken und die Systemauslastung zu diesem Zeitpunkt. Es entscheidet dann, welche Sequenz auf die in der Abfrage genannten Tabellen zugreift, welche Sequenz die Operationen ausfĂŒhrt und welche Zugriffsmethode fĂŒr den Zugriff auf die Tabellen verwendet wird. Wenn die Tabelle beispielsweise einen zugehörigen Index hat, sollte der Index verwendet werden oder nicht: Wenn sich der Index in einer Spalte befindet, die fĂŒr die meisten Spalten nicht eindeutig ist (geringe "SelektivitĂ€t"), ist die Verwendung möglicherweise nicht sinnvoll der Index fĂŒr den Zugriff auf die Daten. Schließlich entscheidet es, ob die Abfrage gleichzeitig ausgefĂŒhrt wird oder nicht. WĂ€hrend eine gleichzeitige AusfĂŒhrung in Bezug auf die gesamte Prozessorzeit teurer ist, kann die AusfĂŒhrung, da sie tatsĂ€chlich auf verschiedene Prozessoren aufgeteilt wird, bedeuten, dass sie schneller ausgefĂŒhrt wird. Sobald ein Abfrageplan fĂŒr eine Abfrage generiert wurde, wird er vorĂŒbergehend zwischengespeichert. FĂŒr weitere Aufrufe derselben Abfrage wird der zwischengespeicherte Plan verwendet. Ungenutzte PlĂ€ne werden nach einiger Zeit verworfen.

SQL Server ermöglicht auch die Definition gespeicherter Prozeduren. Gespeicherte Prozeduren sind parametrisierte T-SQL-Abfragen, die im Server selbst gespeichert sind (und nicht wie bei allgemeinen Abfragen von der Client-Anwendung ausgegeben werden). Gespeicherte Prozeduren können Werte akzeptieren, die vom Client als Eingabeparameter gesendet werden, und Ergebnisse als Ausgabeparameter zurĂŒcksenden. Sie können definierte Funktionen und andere gespeicherte Prozeduren aufrufen, einschließlich derselben gespeicherten Prozedur (bis zu einer festgelegten Anzahl von Malen). Sie können selektiv Zugang zu erhalten. Im Gegensatz zu anderen Abfragen haben gespeicherte Prozeduren einen zugeordneten Namen, der zur Laufzeit in die tatsĂ€chlichen Abfragen aufgelöst wird. Auch weil der Code nicht jedes Mal vom Client gesendet werden muss (da er ĂŒber den Namen aufgerufen werden kann), reduziert er den Netzwerkverkehr und verbessert die Leistung etwas. AusfĂŒhrungsplĂ€ne fĂŒr gespeicherte Prozeduren werden bei Bedarf ebenfalls zwischengespeichert.


T-SQL (Transact-SQL) ist das sekundĂ€re Mittel zur Programmierung und Verwaltung von SQL Server. Es stellt SchlĂŒsselwörter fĂŒr die Operationen zur VerfĂŒgung, die auf SQL Server ausgefĂŒhrt werden können. Dazu gehören das Erstellen und Ändern von Datenbankschemas, das Eingeben und Bearbeiten von Daten in der Datenbank sowie das Überwachen und Verwalten des Servers selbst. Clientanwendungen, die Daten verbrauchen oder den Server verwalten, nutzen die SQL Server-FunktionalitĂ€t, indem sie T-SQL-Abfragen und -Anweisungen senden, die dann vom Server verarbeitet werden und Ergebnisse (oder Fehler) an die Clientanwendung zurĂŒckgeben. SQL Server ermöglicht die Verwaltung mit T-SQL. Dazu werden schreibgeschĂŒtzte Tabellen verfĂŒgbar gemacht, aus denen Serverstatistiken gelesen werden können. Die VerwaltungsfunktionalitĂ€t wird ĂŒber systemdefinierte gespeicherte Prozeduren verfĂŒgbar gemacht, die aus T-SQL-Abfragen zur DurchfĂŒhrung der Verwaltungsoperation aufgerufen werden können. Es ist auch möglich, verbundene Server mit T-SQL zu erstellen. VerknĂŒpfte Server ermöglichen eine einzelne Abfrage zum Verarbeiten von Operationen, die auf mehreren Servern ausgefĂŒhrt werden.
Nativer SQL Server-Client

SQL Server Native Client ist die native clientseitige Datenzugriffsbibliothek fĂŒr Microsoft SQL Server ab Version 2005. Es implementiert nativ die UnterstĂŒtzung fĂŒr die SQL Server-Funktionen einschließlich der Implementierung des tabellarischen Datenstroms, UnterstĂŒtzung fĂŒr gespiegelte SQL Server-Datenbanken, vollstĂ€ndige UnterstĂŒtzung aller von SQL Server unterstĂŒtzten Datentypen, asynchrone Operationen, Abfragebenachrichtigungen, VerschlĂŒsselungsunterstĂŒtzung sowie das Empfangen mehrerer Ergebnismengen in einer einzigen Datenbanksitzung. SQL Server Native Client wird von SQL Server-Plug-Ins fĂŒr andere Datenzugriffstechnologien wie ADO oder OLE DB verwendet. Der SQL Server Native Client kann auch direkt verwendet werden, wobei die generischen Datenzugriffsebenen umgangen werden.

 2011 wurde eine Vorschauversion des SQL Server ODBC-Treibers fĂŒr Linux veröffentlicht.


Microsoft SQL Server 2005 enthĂ€lt eine Komponente namens SQL CLR ("Common Language Runtime"), ĂŒber die sie in .NET Framework integriert ist. Im Gegensatz zu den meisten anderen Anwendungen, die .NET Framework verwenden, hostet SQL Server selbst die .NET Framework-Laufzeit, d. H. Speicher-, Thread- und Ressourcenmanagementanforderungen von .NET Framework werden von SQLOS selbst und nicht vom zugrunde liegenden Windows-Betriebssystem erfĂŒllt. SQLOS bietet Deadlock-Erkennungs- und -Ablösungsdienste fĂŒr .NET-Code. Mit SQL CLR können gespeicherte Prozeduren und Trigger in jeder verwalteten .NET-Sprache geschrieben werden, einschließlich C # und VB.NET. Verwalteter Code kann auch verwendet werden, um UDTs (benutzerdefinierte Typen) zu definieren, die in der Datenbank bestehen bleiben können. Der verwaltete Code wird in CLI-Assemblys kompiliert und nach der ÜberprĂŒfung auf Typsicherheit in der Datenbank registriert. Danach können sie wie jede andere Prozedur aufgerufen werden. Es ist jedoch nur eine Teilmenge der Basisklassenbibliothek verfĂŒgbar, wenn Code unter SQL CLR ausgefĂŒhrt wird. Die meisten APIs fĂŒr die BenutzeroberflĂ€chenfunktionalitĂ€t sind nicht verfĂŒgbar.

Wenn Sie Code fĂŒr SQL CLR schreiben, können Sie auf Daten zugreifen, die in SQL Server-Datenbanken gespeichert sind, indem Sie die ADO.NET-APIs wie jede andere verwaltete Anwendung verwenden, die auf SQL Server-Daten zugreift. Dadurch wird jedoch eine neue Datenbanksitzung erstellt, die sich von der unterscheidet, in der der Code ausgefĂŒhrt wird. Um dies zu vermeiden, bietet SQL Server dem ADO.NET-Anbieter einige Verbesserungen, die es ermöglichen, dass die Verbindung zu derselben Sitzung umgeleitet wird, die bereits den laufenden Code hostet. Solche Verbindungen werden als Kontextverbindungen bezeichnet und durch Festlegen des Kontextverbindungsparameters in der Verbindungszeichenfolge auf true festgelegt. SQL Server bietet der ADO.NET-API weitere Verbesserungen, einschließlich Klassen fĂŒr die Arbeit mit Tabellendaten oder einer einzelnen Datenzeile sowie Klassen fĂŒr die Arbeit mit internen Metadaten zu den in der Datenbank gespeicherten Daten. Es bietet auch Zugriff auf die XML-Funktionen in SQL Server, einschließlich der XQuery-UnterstĂŒtzung. Diese Verbesserungen sind auch in T-SQL-Prozeduren als Folge der EinfĂŒhrung des neuen XML-Datentyps (Abfrage, Wert, Knotenfunktionen) verfĂŒgbar.


Zeittafel Microsoft SQL Server

Versions-ID

Jahr

Release Name

Projektbezeichnung

1.0
(OS/2)

1989

SQL Server 1.0
(16bit)

—

1.1
(OS/2)

1990

SQL Server 1.1
(16bit)

—

1.11
(OS/2)

1991

SQL Server 1.1
(16bit)

—

4.2
(OS/2)

1992

SQL Server 4.2
(16bit)

—

4.21
(WinNT)

1993

SQL Server 4.21

SQLNT

6.0

1995

SQL Server 6.0

SQL95

6.5

1996

SQL Server 6.5

Hydra

7.0

1998

SQL Server 7.0

Sphinx

—

1999

SQL Server 7.0
OLAP Tools

Plato

8.0

2000

SQL Server 2000

Shiloh

8.0

2003

SQL Server 2000
64-bit Edition

Liberty

9.0

2005

SQL Server 2005

Yukon

10.0

2008

SQL Server 2008

Katmai

10.25

2010

SQL Azure

Matrix (aka CloudDB)

10.5

2010

SQL Server 2008 R2

Kilimanjaro (aka KJ)

11.0

2012

SQL Server 2012

Denali

12.0

2014

SQL Server 2014

Hekaton

13.0

2016

SQL Server 2016

 

14.0

2017

SQL Server 2017

SQL Server vNext