Verbindungsserver (Datenbank-Engine)

Gilt für: SQL Server (alle unterstützten Versionen) Azure SQL Managed Instance

Mithilfe von Verbindungsservern können SQL Server-Datenbank-Engine und Verwaltete Azure SQL-Instanz Daten aus Remotedatenquellen lesen und Befehle für Remotedatenbankserver (z. B. OLE DB-Datenquellen) außerhalb der Instanz von SQL Server ausfü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 sind in SQL Server-Datenbank-Engine und Verwaltete Azure SQL-Instanz verfügbar. In Azure SQL-Datenbank-Singletons und in Pools für elastische Datenbanken sind sie nicht aktiviert. Einschränkungen in einer verwalteten Instanz finden Sie hier.

Wann sollten Verbindungsserver verwendet werden?

Verbindungsserver ermöglichen das Implementieren verteilter Datenbanken, die Daten in anderen Datenbanken abrufen und aktualisieren können. Sie 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 von SQL Serverzuzugreifen.

  • 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 (Transact-SQL) 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 (Transact-SQL) einen Sicherheitskontext für die Verbindung bereitstellen. Einige OLE DB-Anbieter ermöglichen es 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 (MSOLEDBSQL) (PROGID: MSOLEDBSQL) der OLE DB-Standardanbieter. In früheren Versionen war dies der SQL Server Native Client OLE DB-Anbieter (SQLNCLI) (PROGID: SQLNCLI11).

Wichtig

Die SQL Server Native Client (häufig abgekürzt SNAC) wurde aus SQL Server 2022 (16.x) und SQL Server Management Studio 19 (SSMS) entfernt. Sowohl der SQL Server Native Client OLE DB-Anbieter (SQLNCLI oder SQLNCLI11) als auch der ältere Microsoft OLE DB-Anbieter für SQL Server (SQLOLEDB) werden nicht für die Neuentwicklung empfohlen. Wechseln Sie für SQL Server in Zukunft zum neuen Microsoft OLE DB-Treiber (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

SQL Server sind jedoch so entworfen, 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.

Diagramm: Client-, Server- und Datenbankserverebene

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 Instanz von SQL Servervorhanden 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 Serverregistriert 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_addlinkedserver ausfü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_dropserver ausführen. Sie können mit dieser gespeicherten Prozedur auch einen Remoteserver entfernen.

Sie können Verbindungsserver auch mithilfe von SQL Server Management Studiodefinieren. 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_namevorliegen.

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.

Verbindungsserverauthentifizierung für Azure SQL Managed Instance

Die Verbindungsserver für Azure SQL Managed Instance unterstützen sowohl die SQL-Authentifizierung als auch die Azure AD-Authentifizierung (AAD). Die zwei AAD-Authentifizierungsmodi sind die 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. Die Voraussetzungen für die Passthrough-Authentifizierung sind, dass derselbe Prinzipal als Anmeldename auf dem Remoteserver hinzugefügt wird und dass beide Instanzen Mitglieder der SQL Vertrauensgruppe sind.

Hinweis

Vorhandene Definitionen von Verbindungsservern, die für den Passthrough-Modus konfiguriert wurden, unterstützen die Azure AD-Authentifizierung. Die einzige Voraussetzung hierfür wäre das Hinzufügen verwalteter Instanzen zur Serververtrauensgruppe.

Einschränkungen der Azure AD-Authentifizierung

  • Die Azure AD-Authentifizierung wird nicht für verwaltete Instanzen in unterschiedlichen Azure AD-Mandanten unterstützt.
  • Die Azure AD-Authentifizierung für Verbindungsserver wird nur mit der OLE DB-Treiberversion 18.2.1 und höher unterstützt.
  • Die Azure AD-Authentifizierung für Verbindungsserver von der verwalteten Instanz zu SQL Server wird nur für zugeordnete lokale Anmeldungen unterstützt. Die Weitergabe von Sicherheitskontext wird nicht unterstützt. Dies bedeutet, dass die Authentifizierung der verwalteten Identität unterstützt wird, während die Passthrough-Authentifizierung nicht unterstützt wird.

Siehe auch

Nächste Schritte