Verbindungsserver (Datenbank-Engine)
Gilt für: 
SQL Server Azure SQL Managed Instance
Verbindungsserver ermöglichen der SQL Server-Datenbank-Engine und Azure SQL Managed Instance, Daten aus den Remotedatenquellen zu lesen und Befehle für die Remotedatenbankserver (z. B. OLE DB-Datenquellen) außerhalb der SQL Server-Instanz auszuführen. Normalerweise werden Verbindungsserver so konfiguriert, dass die Datenbank-Engine eine Transact-SQL-Anweisung ausführen kann, die Tabellen in einer anderen Instanz von SQL Server oder einem anderen Datenbankprodukt wie Oracle enthält. Viele Typen von OLE DB-Datenquellen können als Verbindungsserver konfiguriert werden, darunter Datenbank-Drittanbieter und Azure Cosmos DB.
Hinweis
Verbindungsserver stehen in SQL Server und in Azure SQL Managed Instance (mit einigen Einschränkungen) zur Verfügung. In der Azure SQL-Datenbank stehen Verbindungsserver nicht zur Verfügung.
Wann sollten Verbindungsserver verwendet werden?
Verbindungsserver ermöglichen das Implementieren verteilter Datenbanken, die Daten in anderen Datenbanken abrufen und aktualisieren können. Verbindungsserver sind eine gute Lösung für Szenarien, in denen Sie Datenbanksharding implementieren müssen, ohne benutzerdefinierten Anwendungscode erstellen oder direktes Laden aus Remotedatenquellen ausführen zu müssen. Verbindungsserver bieten die folgenden Vorteile:
Die Fähigkeit, auf Daten von außerhalb des SQL Servers zuzugreifen.
Die Fähigkeit, verteilte Abfragen, Updates, Befehle und Transaktionen auf heterogenen Datenquellen im gesamten Unternehmen auszugeben.
Die Möglichkeit, verschiedene Datenquellen ähnlich zu adressieren.
Ein Verbindungsserver kann mit SQL Server Management Studio oder mit der Anweisung sp_addlinkedserver konfiguriert werden. OLE DB-Anbieter variieren stark in Hinblick auf Typ und Anzahl der erforderlichen Parameter. Bei manchen Anbietern müssen Sie beispielsweise über sp_addlinkedsrvlogin einen Sicherheitskontext für die Verbindung bereitstellen. Einige OLE DB-Anbieter ermöglichen es dem SQL Server, Daten in der OLE DB-Quelle zu aktualisieren. Andere Anbieter stellen nur schreibgeschützten Datenzugriff bereit. Informationen zu den einzelnen OLE DB-Anbietern finden Sie in der jeweiligen Dokumentation des OLE DB-Anbieters.
Verbindungsserverkomponenten
Eine Verbindungsserverdefinition gibt die folgenden Objekte an:
Einen OLE DB-Anbieter.
Eine OLE DB-Datenquelle.
Ein OLE DB-Anbieter ist eine DLL (Dynamic Link Library), die mit einer bestimmten Datenquelle interagiert und sie verwaltet. Eine OLE DB-Datenquelle identifiziert die spezielle Datenbank, auf die über OLE DB zugegriffen werden kann. Obwohl es sich bei Datenquellen, die über Verbindungsserverdefinitionen abgefragt werden, normalerweise um Datenbanken handelt, sind OLE DB-Anbieter für eine Vielzahl von Dateien und Dateiformaten verfügbar. Dazu gehören Textdateien, Kalkulationstabellendaten und die Ergebnisse aus Volltextsuchläufen.
Ab SQL Server 2019 (15.x) ist der Microsoft OLE DB-Treiber für SQL Server (PROGID: MSOLEDBSQL) der standardmäßige OLE DB-Anbieter. In früheren Versionen war der SQL Server Native Client (PROGID: SQLNCLI11) der standardmäßige OLE DB-Anbieter.
Wichtig
Der SQL Server Native Client (häufig abgekürzt mit SNAC) wurde aus SQL Server 2022 (16.x) und SQL Server Management Studio 19 (SSMS) entfernt. Sowohl der OLE DB-Anbieter für den SQL Server Native Client (SQLNCLI oder SQLNCLI11) als auch der Microsoft OLE DB-Legacyanbieter für SQL Server (SQLOLEDB) werden für Neuentwicklungen nicht empfohlen. Verwenden Sie in Zukunft den neuen Microsoft OLE DB-Treiber für SQL Server (MSOLEDBSQL).
Verbindungsserver für Microsoft Access- und Excel-Quellen werden von Microsoft nur bei Verwendung des 32-Bit-OLE DB-Anbieters „Microsoft.JET.OLEDB.4.0“ unterstützt.
Hinweis
Verteilte Abfragen des SQL Servers sind so konzipiert, dass sie mit jedem OLE DB-Anbieter zusammenarbeiten, der die erforderlichen OLE DB-Schnittstellen implementiert. Getestet wurde SQL Server jedoch für den OLE DB-Standardanbieter.
Einzelheiten zu Verbindungsservern
Die folgende Abbildung zeigt die Grundlagen einer Verbindungsserverkonfiguration.
Verbindungsserver werden in der Regel für die Verarbeitung verteilter Abfragen verwendet. Führt eine Clientanwendung eine verteilte Abfrage über einen Verbindungsserver aus, analysiert SQL Server den Befehl und sendet Anforderungen an OLE DB. Für eine Rowsetanforderung kann eine Abfrage für den Anbieter ausgeführt oder eine Basistabelle vom Anbieter geöffnet werden.
Hinweis
Damit eine Datenquelle Daten über einen Verbindungsserver zurückgibt, muss der OLE DB-Anbieter (DLL) für diese Datenquelle auf demselben Server wie die SQL Server-Instanz vorhanden sein.
Wichtig
Wenn ein OLE DB-Anbieter verwendet wird, müssen dem Konto, mit dem der SQL Server-Dienst ausgeführt wird, Lese- und Ausführungsberechtigungen für das Verzeichnis (und alle Unterverzeichnisse) erteilt worden sein, in dem der Anbieter installiert ist. Dies schließt den Anbieter von Microsoft und alle Anbieter von Drittanbietern ein.
Hinweis
Verbindungsserver unterstützen bei der vollständigen Delegierung die Passthrough-Authentifizierung von Active Directory. Ab SQL Server 2017 (14.x) CU17 wird auch die Passthrough-Authentifizierung mit eingeschränkter Delegierung unterstützt; die ressourcenbasierte eingeschränkte Delegierung wird jedoch nicht unterstützt.
Verwalten von Anbietern
Eine Gruppe von Optionen steuert, wie SQL Server OLE DB-Anbieter lädt und verwendet, die in der Registrierung angegeben werden.
Verwalten von Verbindungsserverdefinitionen
Beim Einrichten eines Verbindungsservers sollten die Verbindungsinformationen und Datenquelleninformationen in SQL Server registriert werden. Nach der Registrierung kann über einen einzelnen logischen Namen auf diese Datenquelle verwiesen werden.
Sie können gespeicherte Prozeduren und Katalogsichten zum Verwalten von Verbindungsserverdefinitionen verwenden:
Erstellen Sie eine Verbindungsserverdefinition, indem Sie
sp_addlinkedserverausführen.Zeigen Sie Informationen zu den in einer bestimmten Instanz von SQL Server definierten Verbindungsservern an, indem Sie eine Abfrage der
sys.servers-Systemkatalogsicht ausführen.Löschen Sie eine Verbindungsserverdefinition, indem Sie
sp_dropserverausführen. Sie können mit dieser gespeicherten Prozedur auch einen Remoteserver entfernen.
Sie können Verbindungsserver auch mit SQL Server Management Studio definieren. Klicken Sie im Objekt-Explorer mit der rechten Maustaste auf Serverobjekte, klicken Sie auf Neu, und klicken Sie dann auf Verbindungsserver. Sie können eine Verbindungsserverdefinition löschen, indem Sie mit der rechten Maustaste auf den Namen des Verbindungsservers und dann auf Löschenklicken.
Wenn Sie eine verteilte Abfrage auf einem Verbindungsserver ausführen, sollten Sie einen vollqualifizierten vierteiligen Tabellennamen für jede Datenquelle einschließen, die abgefragt werden soll. Dieser vierteilige Name muss in der Form linked_server_name.catalog.schema.object_name vorliegen.
Hinweis
Verbindungsserver können so definiert werden, dass sie zurück auf den Server zeigen, auf dem sie definiert sind (zurücklaufen = loop back). Loopbackserver sind sehr nützlich, um eine Anwendung, von der verteilte Abfragen verwendet werden, in einem Netzwerk mit einem einzelnen Server zu testen. Loopbackverbindungsserver sind für Tests bestimmt und werden für viele Vorgänge, z. B. verteilte Transaktionen, nicht unterstützt.
Verbindungsserver mit Azure SQL Managed Instance
Verbindungsserver von Azure SQL Managed Instance unterstützen sowohl die SQL-Authentifizierung als auch die Authentifizierung mit Microsoft Entra ID (früher Azure Active Directory).
Um mithilfe von SQL-Agent-Aufträgen in Azure SQL Managed Instance einen Remoteserver über einen Verbindungsserver abzufragen, erstellen Sie mit sp_addlinkedsrvlogin eine Zuordnung von einer Anmeldung auf dem lokalen Server zu einer Anmeldung auf dem Remoteserver. Wenn der SQL-Agent-Auftrag über den Verbindungsserver eine Verbindung mit dem Remoteserver herstellt, wird die T-SQL-Abfrage im Kontext der entfernten Anmeldung ausgeführt. Weitere Informationen finden Sie unter SQL-Agent-Aufträge mit Azure SQL Managed Instance.
Microsoft Entra-Authentifizierung
Zwei unterstützte Microsoft Entra-Authentifizierungsmodi sind: verwaltete Identität und Passthrough. Die Authentifizierung mit verwalteter Identität kann verwendet werden, um lokalen Anmeldungen das Abfragen von Remoteverbindungsservern zu ermöglichen. Die Passthrough-Authentifizierung ermöglicht einem Prinzipal, der sich mit einer lokalen Instanz authentifizieren kann, über einen Verbindungsserver auf eine Remoteinstanz zuzugreifen.
Um die Passthrough-Authentifizierung von Microsoft Entra für einen Verbindungsserver in Azure SQL Managed Instance zu nutzen, müssen folgende Voraussetzungen gegeben sein:
- Derselbe Prinzipal wird als Anmeldung auf dem Remoteserver hinzugefügt.
- Beide Instanzen sind Mitglieder der SQL-Vertrauensgruppe.
Hinweis
Vorhandene Definitionen von Verbindungsservern, die für den Passthrough-Modus konfiguriert wurden, unterstützen die Microsoft Entra-Authentifizierung. Die einzige Voraussetzung hierfür wäre das Hinzufügen von SQL Managed Instance zur Serververtrauensgruppe.
Die folgenden Einschränkungen gelten für die Microsoft Entra-Authentifizierung für Verbindungsserver in Azure SQL Managed Instance:
- Die Microsoft Entra-Authentifizierung wird für verwaltete Instanzen von SQL in verschiedenen Microsoft Entra-Mandanten nicht unterstützt.
- Die Microsoft Entra-Authentifizierung für Verbindungsserver wird nur mit der OLE DB-Treiberversion 18.2.1 und höher unterstützt.
MSOLEDBSQL19 und Verbindungsserver
Derzeit verhindert MSOLEDBSQL19 die Erstellung von Verbindungsservern ohne Verschlüsselung und vertrauenswürdiges Zertifikat (ein selbstsigniertes Zertifikat reicht nicht aus). Wenn Verbindungsserver erforderlich sind, verwenden Sie die vorhandene unterstützte Version von MSOLEDBSQL.