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

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:

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.