Verwenden Sie die verwaltete Identität auf Datenbankebene mit Azure SQL-Datenbank (Vorschau)

Gilt für:Azure SQL-Datenbank

Die verwaltete Identität auf Datenbankebene verleiht einer einzelnen Datenbank in Azure SQL-Datenbank eine eigene, benutzerzugewiesene verwaltete Identität (UAMI). Eine Datenbank, die über eine solche Identität verfügt, authentifiziert sich bei Azure Storage als sie selbst, nicht als der logische Server, der sie hostet.

Ohne eine Identität auf Datenbankebene teilt jede Datenbank auf einem logischen Server die verwaltete Identität dieses Servers, sodass sie alle denselben Speicher erreichen. Eine Identität auf Datenbankebene beschränkt diesen Zugriff auf eine einzelne Datenbank, sodass jeder Datenbank nur der benötigte Speicher gewährt werden kann.

Sie wählen die Identität in datenbankbezogenen Anmeldeinformationen aus, derselben Zugangsberechtigung, die Datenvirtualisierungsanfragen verwenden, um Parquet-, CSV- und Delta-Dateien von Azure Blob Storage oder Azure Data Lake Storage (ADLS) Gen2 zu lesen. Wählen Sie zwischen zwei Anmeldedaten-Identitätswerten:

Anmeldeinformations-ID Verwenden Sie ihn, wenn
DATABASE MANAGED IDENTITY Das Speicherkonto befindet sich im selben Microsoft Entra-Tenant wie die Datenbank.
DATABASE FEDERATED CLIENT IDENTITY Das Speicherkonto befindet sich in einem anderen Tenant, der über eine föderierte Identitätsanmeldeinformation (FIC) erreicht wird.

Note

Als Previewfunktion unterliegt die in diesem Artikel vorgestellte Technologie den zusätzlichen Nutzungsbedingungen für Microsoft Azure-Vorschauen.

Voraussetzungen

  • Eine Azure SQL-Datenbank auf einem logischen Server. Alle Service-Tiers und alle Azure-Regionen unterstützen diese Funktion.
  • Eine vom Benutzer zugewiesene verwaltete Identität im selben Abonnement. Für Hintergrundinformationen siehe Managed Identities in Microsoft Entra for Azure SQL.
  • Berechtigung zur Zuweisung von Rollen auf dem Zielspeicherkonto, wie Owner oder User Access Administrator.
  • Ein Azure Blob Storage- oder ADLS Gen2-Konto, das die Dateien enthält, die du abfragen möchtest.

Important

Eine Datenbank kann auf Datenbankebene nur eine benutzerzugewiesene verwaltete Identität haben, im Gegensatz zu einem logischen Server, der mehrere haben kann. Plane die ID pro Datenbank, bevor du sie zuweist.

Wenn die Datenbank auf Datenbankebene kundenverwaltete Schlüssel verwendet, besitzt sie bereits eine Datenbankebene-Identität, und für tenantübergreifende Schlüssel eine föderierte Client-ID. Diese Funktion verwendet dieselben beiden Einstellungen. Erteile Speicherzugriff auf die bestehende Identität oder Anwendung, anstatt neue zuzuweisen. Wenn Sie eine andere Identität oder Anwendung zuweisen, geben Sie ihr zuerst Zugriff auf den Verschlüsselungsschlüssel. Andernfalls kann das Update fehlschlagen, oder die Datenbank kann den Zugriff auf ihren Schlüssel verlieren.

Wähle Same-Tenant oder Cross-Tenant

Beide Walkthroughs erstellen eine datenbankbezogene Anmeldeinformation und fragen externe Daten ab. Sie unterscheiden sich darin, wie die Identität das Speicherkonto erreicht.

Verwenden Sie eine Identität auf Datenbankebene im selben Tenant

Schritt 1: Erstellen einer benutzerseitig zugewiesenen verwalteten Identität

Erstelle die Identität und notiere sowohl deren Ressourcen-ID als auch ihre Objekt-ID (Prinzipal). Du brauchst die Resource ID, um der Datenbank die Identität zuzuweisen. Die Objekt-(Haupt-)ID benötigt man nur für den Cross-Tenant-Walkthrough, wo sie das Subjekt der Verbundidentitäts-Anmeldeinformationen identifiziert.

az identity create \
    --name <identity-name> \
    --resource-group <resource-group> \
    --location <region>

Weitere Methoden finden Sie unter Benutzerseitig zugewiesene verwaltete Identitäten verwalten.

Schritt 2: Weisen Sie der Datenbank die Identität zu

Weise die UAMI der Datenbank zu, nicht dem logischen Server. Diese Zuweisung verwendet denselben Mechanismus wie datenbankweite transparente Datenverschlüsselung (TDE) mit kundenverwalteten Schlüsseln, beschrieben in kundenverwaltete Schlüssel auf Datenbankebene. Für den vollständigen Satz der Zuweisungsmethoden siehe Verwalten einer verwalteten Identität für eine Datenbank.

Um die Identität im Azure-Portal zuzuweisen:

  1. Geh zu deiner SQL-Datenbank.
  2. Wählen Sie unter Sicherheit die Option Identität aus.
  3. Unter User-Assigned Managed Identity wählen Sie Hinzufügen.
  4. Wählen Sie die von Ihnen erstellte Identität aus und wählen Sie dann Hinzufügen.
  5. Wählen Sie Speichern.

Um die Identität mit der Azure CLI zuzuweisen, verwenden Sie az sql db update:

az sql db update \
    --resource-group <resource-group> \
    --server <server-name> \
    --name <database-name> \
    --assign-identity \
    --user-assigned-identity-id <identity-resource-id>

Um es mit PowerShell zuzuweisen, verwenden Sie Set-AzSqlDatabase:

Set-AzSqlDatabase -ResourceGroupName <ResourceGroupName> -ServerName <ServerName> -DatabaseName <DatabaseName> -AssignIdentity -UserAssignedIdentityId <UserAssignedIdentityId>

Die Identität Ressourcen-ID sieht so aus wie /subscriptions/<subscription-id>/resourceGroups/<resource-group>/providers/Microsoft.ManagedIdentity/userAssignedIdentities/<identity-name>. Finden Sie es unter Eigenschaften bei der verwalteten Identität im Azure-Portal.

Schritt 3: Gewähren Sie der Identität Zugriff auf den Speicher

Geben Sie der verwalteten Identität Lesezugriff zum Speicherkonto:

  1. Navigieren Sie zum Speicherkonto.
  2. Wählen Sie Zugriffssteuerung (IAM).
  3. Wählen Sie Hinzufügen>Rollenzuweisung hinzufügen aus.
  4. Wählen Sie die Rolle Storage Blob Data Reader aus und wählen Sie dann Nächstes aus.
  5. Wählen Sie unter Zugriff zuweisen zu die Option Verwaltete Identität aus.
  6. Wählen Sie Mitglieder auswählen, wählen Sie Ihre vom Benutzer zugewiesene verwaltete Identität und dann Auswählen.
  7. Wählen Sie Überprüfen + zuweisen.

Für feinkörnigere Zugriffe auf ADLS Gen2 setzen Sie Zugriffskontrolllisten (ACLs) für bestimmte Verzeichnisse, anstatt eine Rolle auf Kontoebene zuzuweisen. Weitere Informationen finden Sie unter Access Control Lists in Azure Data Lake Storage.

Schritt 4: Erstellen Sie die datenbankbezogene Anmeldeinformation

Verbinden Sie sich mit Ihrer Benutzerdatenbank, nicht master, und erstellen Sie die Zugangsberechtigung:

CREATE DATABASE SCOPED CREDENTIAL MyDBIdentityCred
WITH IDENTITY = 'DATABASE MANAGED IDENTITY';

Diese Anmeldeinformation benötigt keinen Geheimniswert und keinen Datenbank-Masterschlüssel. Die Engine löst die der Datenbank zugewiesene Identität zur Abfragezeit auf.

Das Server-Äquivalent verwendet einen anderen IDENTITY-Wert. Vergleichen:

-- Server-level identity: every database on the logical server shares this access
CREATE DATABASE SCOPED CREDENTIAL MyServerIdentityCred
WITH IDENTITY = 'MANAGED IDENTITY';

-- Database-level identity: only this database has this access
CREATE DATABASE SCOPED CREDENTIAL MyDBIdentityCred
WITH IDENTITY = 'DATABASE MANAGED IDENTITY';

Für die vollständige Syntax siehe CREATE DATABASE SCOPED CREDENTIAL.

Schritt 5: Erstellen Sie die externe Datenquelle

Erstelle eine externe Datenquelle, die auf deinen Container verweist, und hänge die Zugangsdaten an. Verwenden Sie das Präfix, das zu Ihrem Speichertyp passt:

Speichertypus Speicherort-Präfix
Azure Blob Storage (Speicherdienst von Azure für unstrukturierte Daten) abs://
ADLS Gen2 adls:// 
CREATE EXTERNAL DATA SOURCE MyExternalStorage
WITH (
    LOCATION = 'abs://<container>@<storage-account>.blob.core.windows.net',
    CREDENTIAL = MyDBIdentityCred
);

Schritt 6: Abfrage der Daten

Fragen Sie die Dateien ad hoc mit OPENROWSET ab:

SELECT TOP 100 *
FROM OPENROWSET(
    BULK 'sales/2026/*.parquet',
    DATA_SOURCE = 'MyExternalStorage',
    FORMAT = 'parquet'
) AS externalData;

Oder definieren Sie eine externe Tabelle für wiederholte Abfragen:

CREATE EXTERNAL FILE FORMAT ParquetFormat
WITH (FORMAT_TYPE = PARQUET);

CREATE EXTERNAL TABLE dbo.Sales
(
    OrderId int,
    OrderDate date,
    Amount decimal(10, 2)
)
WITH (
    LOCATION = 'sales/2026/',
    DATA_SOURCE = MyExternalStorage,
    FILE_FORMAT = ParquetFormat
);

SELECT TOP 100 * FROM dbo.Sales;

Verwenden Sie eine föderierte Client-Identität mandantenübergreifend

Verwenden Sie diesen Pfad, wenn Ihre Datenbank in einem Tenant ist und das Speicherkonto in einem anderen. Eine Multitenant-Anwendungsregistrierung stellt die Vertrauensbeziehung zwischen beiden her: Das UAMI der Datenbank ist als Verbundidentitätsanmeldeinformationen für diese Anwendung konfiguriert, und der Speichertenant gewährt dem Service-Principal der Anwendung Zugriff auf die Daten.

Das Muster entspricht tenantübergreifenden kundenseitig verwalteten Schlüsseln für transparente Datenverschlüsselung, sodass das Setup vertraut aussieht, wenn Sie diese Funktion bereits nutzen.

Schritt 1: Registrieren Sie eine Multitenant-Anwendung

Im Tenant, der die Datenbank hält, registrieren Sie eine Multitenant-Anwendung in der Microsoft Entra ID und notieren Sie deren Anwendungs- (Client-)ID.

Weitere Informationen finden Sie unter Registrieren einer Anwendung bei Microsoft Identity Platform.

Schritt 2: Fügen Sie eine föderierte Anmeldeinformation hinzu

Fügen Sie dieser Anwendung eine Verbundidentitätsanmeldeinformation hinzu, damit sie der vom Benutzer zugewiesenen verwalteten Identität der Datenbank vertraut. Die Anwendung und die verwaltete Identität müssen zum selben Microsoft Entra-Tenant gehören.

  1. In der App-Registrierung wählen Sie Zertifikate & Geheimschlüssel>Föderierte Anmeldeinformationen>Anmeldeinformation hinzufügen.
  2. Für Federated Credential-Szenario wählen Sie Managed Identity.
  3. Wählen Sie die verwaltete Identität aus, die Sie in Schritt 1 des Tutorials für denselben Mandanten erstellt haben.
  4. Überprüfen Sie, dass der automatisch ausgefüllte Issuer Ihren Mandanten identifiziert. Für die öffentliche Azure-Cloud ist https://login.microsoftonline.com/<tenant-id>/v2.0der Aussteller .
  5. Stelle sicher, dass die Zielgruppeapi://AzureADTokenExchange ist, der Wert für die öffentliche Azure-Cloud.
  6. Gib einen eindeutigen Namen für die Anmeldeinformation ein und speichere diese dann.

Das Subjekt der Anmeldeinformationen ist die Objekt-ID (Prinzipal-ID) der verwalteten Identität, nicht deren Client-ID. Wenn du die Anmeldeinformationen manuell konfigurierst, kopiere die Objekt-(Haupt-)ID exakt, weil das Subjekt groß- und kleinschreibungssensitiv ist. Microsoft Entra ID akzeptiert beim Speichern der Zugangsdaten falsche Aussteller-, Subjekt- oder Audience-Werte, aber der Token-Austausch scheitert später.

Weitere Informationen finden Sie unter Konfigurieren einer Anwendung, damit sie einer verwalteten Identität vertraut.

Im Tenant, der das Speicherkonto hält:

  1. Ein Administrator stimmt der Multitenant-Anwendung zu, die einen Service Principal in diesem Tenant erstellt.
  2. Weisen Sie die Rolle Storage Blob Data Reader diesem Dienstprinzipal auf dem Speicherkonto zu. Folgen Sie Schritt 3: Gewähren Sie den Identitätszugriff auf den Speicher, aber für Zugriff zuweisen zu wählen Sie Benutzer, Gruppe oder Dienstprinzipal und dann den Dienstprinzipal der Anwendung.

Schritt 4: Setzen Sie die föderierte Client-ID für die Datenbank ein

Im Tenant, der die Datenbank hält, weisen Sie die vom Benutzer zugewiesene verwaltete Identität der Datenbank zu und setzen Sie die Anwendungs-(Client-)ID aus Schritt 1 als federierte Client-ID:

  1. Geh zu deiner SQL-Datenbank.
  2. Wählen Sie unter Sicherheit die Option Identität aus.
  3. Unter User-Assigned Managed Identity prüfen Sie, ob die Identität aus Schritt 1 des Walkthroughs für denselben Mandanten aufgeführt ist. Wenn nicht, wähle Hinzufügen, wähle die Identität und dann wähle Hinzufügen.
  4. Unter Federated Client Identity wählen Sie die Anwendung aus und wählen Sie dann Speichern.

Um sie mit der Azure CLI festzulegen:

az sql db update \
    --resource-group <resource-group> \
    --server <server-name> \
    --name <database-name> \
    --assign-identity \
    --user-assigned-identity-id <identity-resource-id> \
    --federated-client-id <application-client-id>

Um es mit PowerShell einzustellen:

Set-AzSqlDatabase -ResourceGroupName <ResourceGroupName> -ServerName <ServerName> -DatabaseName <DatabaseName> -AssignIdentity -UserAssignedIdentityId <UserAssignedIdentityId> -FederatedClientId <ApplicationClientId>

Schritt 5: Erstellen Sie die Zugangsdaten und erstellen Sie die Abfrage

CREATE DATABASE SCOPED CREDENTIAL MyCrossTenantCred
WITH IDENTITY = 'DATABASE FEDERATED CLIENT IDENTITY';

CREATE EXTERNAL DATA SOURCE PartnerStorage
WITH (
    LOCATION = 'adls://<container>@<storage-account>.dfs.core.windows.net',
    CREDENTIAL = MyCrossTenantCred
);

Erstellen Sie dann eine externe Tabelle oder führen Sie PartnerStorage genau gegen OPENROWSET aus, genau wie in Schritt 6: Abfrage der Daten.

Vergleichen Sie Server- und Datenbank-Identitäten

Merkmal verwaltete Identität auf Serverebene Verwaltete Identität auf Datenbankebene
Identitätsbereich Logischer Server Einzeldatenbank
Syntax für Anmeldedaten IDENTITY = 'MANAGED IDENTITY' IDENTITY = 'DATABASE MANAGED IDENTITY'
Tenantübergreifender Speicherzugang Nicht unterstützt. Verwenden Sie stattdessen eine Shared-Access-Signatur Föderierte Client-ID in der Datenbank festgelegt, verwendet mit IDENTITY = 'DATABASE FEDERATED CLIENT IDENTITY'
Speicher-RBAC-Granularität Eine eigene Identität für jede Datenbank auf dem Server Eine Identität pro Datenbank
Umfang der Exponierung Jede Datenbank auf dem Server hat denselben Zugriff Beschränkt auf eine einzige Datenbank
Identitätstypen Vom System zugewiesene oder vom Benutzer zugewiesene Nur vom Benutzer zugewiesen
Datenbank-Masterschlüssel erforderlich No No

Beide Arten von Zugangsdaten können auf demselben logischen Server und innerhalb seiner Datenbanken koexistieren. Wählen Sie die Anmeldeinformation, die am besten zu Ihren Sicherheitsanforderungen passt.

Geo-Replikation und Failover

Man weist einer Datenbank eine Identität zu, sodass jede Replik ihre eigene Zuweisung hat. Konfigurieren Sie das Geo-Sekundärsystem genauso wie das Primärsystem, bevor Sie ein Failover machen:

  • Weisen Sie der sekundären Datenbank dieselbe benutzerzugewiesene verwaltete Identität zu, die die primäre Datenbank verwendet.
  • Gewähren Sie dieser Identität denselben Speicherzugriff, der in Schritt 3: Gewähren Sie der Identität Zugriff auf den Speicher beschrieben wird.
  • Für den Tenant-übergreifenden Zugriff setzen Sie dieselbe föderierte Client-Identität auf der sekundären Datenbank.

Wenn du beide Repliken so konfigurierst, funktionieren Abfragen, die datenbankbezogenen Zugangsdaten verwenden, auch nach einem Failover weiter. Die Anforderung stimmt mit kundenverwalteten Schlüsseln auf Datenbankebene überein, die ebenfalls die Identität auf jeder Replik benötigen.

Die gleiche Konfiguration gilt sowohl für aktive Georeplikation als auch für Failover-Gruppen.

Limitations

  • Nur Azure SQL-Datenbank. Azure SQL Managed Instance, SQL Server und Azure Synapse Analytics unterstützen diese Anmeldeidentitäten nicht.
  • Nur ausgehende Authentifizierung. Diese Funktion ändert nicht, wie Nutzer und Anwendungen sich bei der Datenbank authentifizieren.
  • Wird in der master Datenbank nicht unterstützt. Erstelle die Anmeldeinformation in einer Benutzerdatenbank.
  • Nur benutzerseitig zugewiesene verwaltete Identitäten. Eine systemzugeordnete verwaltete Identität ist auf den logischen Server beschränkt, sodass sie nicht als Datenbank-Identität agieren kann.
  • Eine benutzerzugewiesene verwaltete Identität pro Datenbank.
  • Diese Vorschau deckt nur die Datenvirtualisierung ab: CREATE EXTERNAL TABLE und OPENROWSET mit DATA_SOURCE. Andere ausgehende Funktionen wie sp_invoke_external_rest_endpoint liegen nicht im Geltungsbereich.

Troubleshoot

Das Erstellen einer datenbankbezogenen Anmeldeinformation bestätigt nicht, dass die Datenbankidentität ein Token erhalten oder auf Speicher zugreifen kann. Fehler treten später auf, wenn Sie eine externe Datenquelle erstellen oder eine Abfrage ausführen, die die Anmeldeinformationen verwendet.

Datenbankidentität ist nicht konfiguriert (Fehler 15858)

Sie können eine Anmeldeinformation mit IDENTITY = 'DATABASE MANAGED IDENTITY' erstellen, bevor Sie der Datenbank eine vom Benutzer zugewiesene verwaltete Identität zuweisen. Wenn eine Abfrage dann die Zugangsdaten verwendet und die Datenbank keine Identität hat, um ein Token zu erhalten, schlägt die Abfrage mit dem Fehler 15858 fehl:

Cannot obtain a Microsoft Entra ID token to access storage. Error message: 'Azure SQL Server or Database identity is not configured. Please follow the steps in "Assign a Microsoft Entra managed identity to your Azure SQL" (https://aka.ms/SQLDBMSI)'.

Weisen Sie der Datenbank eine benutzerseitig zugewiesene verwaltete Identität zu, wie in Schritt 2 beschrieben, gewähren Sie ihr Zugriff auf das Speicherkonto und versuchen Sie die Abfrage erneut. Die Zuweisung einer Identität nur für den logischen Server konfiguriert keine Identität auf Datenbankebene. Wenn die Datenbankzuweisung vorhanden ist und der Fehler weiterhin besteht, wenden Sie sich an Microsoft-Support, um die Bereitstellung der Datenbankidentität zu untersuchen.

Note

Das Trace-Flag 4675 und der Delete-and-Recreate-Schritt in Backup and restore to URL using managed identities gelten für SQL Server auf Azure-VMs. Sie gelten nicht für verwaltete Identitäten auf Datenbankebene in Azure SQL-Datenbank.

Anmeldeinformation kann nicht gefunden oder referenziert werden (Fehler 46516)

Wenn du eine externe Datenquelle erstellst, prüft die Azure SQL-Datenbank, ob die Anmeldeinformationen in der aktuellen Datenbank vorhanden sind und dass du über die Berechtigung verfügst, darauf zu verweisen. Wenn eine der Prüfungen fehlschlägt, erhalten Sie den Fehler 46516:

The specified credential cannot be found or the user does not have permission to perform this action.

Erstellen Sie die Anmeldeinformation in der Datenbank, die die externe Datenquelle enthält, überprüfen Sie den Namen der Anmeldeinformation und stellen Sie sicher, dass Sie die Berechtigung haben, auf die Anmeldeinformation zu verweisen.

Tokenerwerb fehlgeschlagen (Fehler 15858)

Wenn die Datenbank kein Microsoft Entra-Token erhalten kann und der Token-Anbieter einen Grund zurückgibt, enthält Fehler 15858 diesen Grund:

Cannot obtain a Microsoft Entra ID token to access storage. Error message: '<details>'.

Verwenden Sie die verschachtelte Fehlermeldung, um herauszufinden, warum die Token-Anfrage fehlgeschlagen ist. Für den tenantübergreifenden Zugriff überprüfen Sie die Anwendung, die Administratorzustimmung im Speichertenant und die föderierte Identitätsanmeldeinformation, wie in Konfigurieren einer Anwendung zum Vertrauen einer verwalteten Identität beschrieben.

Um externe Daten zu lesen, benötigt die Identität außerdem eine Speicherdatenrolle. Für den Zugriff innerhalb desselben Tenants weisen Sie der benutzerseitig zugewiesenen verwalteten Identität der Datenbank auf dem Container oder dem Speicherkonto die Rolle Storage Blob Data Reader zu. Für den Tenant-übergreifenden Zugriff gewähren Sie ihn dem Service Principal der Anwendung im Storage Tenant. Weitere Informationen finden Sie unter Zuweisen einer Azure-Rolle für den Zugriff auf Blobdaten.

Datei existiert nicht oder kann nicht abgerufen werden (Fehler 4860)

Wenn eine Datei fehlt oder nicht gelesen werden kann, erhält man den Fehler 4860:

Cannot bulk load. The file "<path>" does not exist or you don't have file access rights. See https://go.microsoft.com/fwlink/?LinkId=2374938 for more information.

Überprüfen Sie, ob die Datei am konfigurierten Speicherort existiert. Dann wird überprüft, ob die von der Anfrage verwendete Identität darauf zugreifen kann, über eine Speicherdatenrolle oder, für ADLS Gen2, über Zugriffskontrolllisten (ACLs) auf dem Pfad.

Netzwerkzugriff ist blockiert (Fehler 42121 und 16539)

Wenn der logische Server mit einem Netzwerksicherheitsperimeter verknüpft ist, der keinen ausgehenden Datenverkehr zum Speicherkonto zulässt, erhält man den Fehler 42121:

The operation could not be completed because attempts to connect were denied by the configured Network Security Perimeter.

Füge eine Outbound-Zugriffsregel für den Hostnamen des Speicherkontos dem Perimeterprofil hinzu oder verknüpfe das Speicherkonto mit demselben Perimeter. Weitere Informationen finden Sie unter Network Security Perimeter für Azure SQL-Datenbank.

Wenn das ausgehende Netzwerk auf dem logischen Server eingeschränkt ist und das Speicherkonto nicht in den Outbound-Firewall-Regeln des Servers steht, erhält man den Fehler 16539:

Operation failed since the external data source '<external-data-source>' has underlying storage account that is not in the list of Outbound Firewall Rules on the server. Please add this storage account to the list of Outbound Firewall Rules on your server and retry the operation.

Fügen Sie eine Outbound-Firewall-Regel für den genauen Speicher-Hostnamen im Speicherort der externen Datenquelle hinzu. Weitere Informationen finden Sie unter Ausgehende Firewallregeln für Azure SQL-Datenbank und Azure Synapse Analytics.

Die Cross-Tenant-Konfiguration fehlt oder ist falsch (Fehler 16561 und 16562)

Eine Cross-Tenant-Abfrage kann mit einem dieser Fehler oder mit Fehler 4860 fehlschlagen:

External table '<table-name>' is not accessible because content of directory cannot be listed.

External table '<table-name>' is not accessible because location does not exist or it is used by another process.

Diese Fehler bedeuten, dass die Abfrage die Dateien nicht erreichen konnte. Die Identity könnte nicht die erforderliche Speicherrolle haben, der Netzwerkzugang könnte blockiert sein, der Speicherort kann nicht aufgelöst werden oder das Token könnte für den falschen Tenant sein. So beheben Sie dies:

  • Gewähren Sie die entsprechende Speicherdatenrolle.
  • Erlaube Netzwerkzugriff auf das Speicherkonto.
  • Fügen Sie den Container in den Speicherort der externen Datenquelle ein.
  • Verwenden Sie DATABASE FEDERATED CLIENT IDENTITY, und setzen Sie die Federated Client ID in der Datenbank, wie in Schritt 4 beschrieben.
  • Bestätigen Sie, dass das Subjekt der föderierten Identitätsanmeldeinformationen exakt mit der Objekt-(Prinzipal-)ID der verwalteten Identität übereinstimmt.

Abfragen scheitern nach einem Failover

Wenn Abfragen nach einem Failover mit Token- oder Autorisierungsfehlern ausfallen, kann es sein, dass die neue primäre Instanz nicht dieselbe benutzerzugewiesene verwaltete Identität hat wie die ursprüngliche primäre Instanz. Oder diese Identität hat vielleicht keine Rollenzuweisung im Speicherkonto. Weisen Sie beiden Repliken dieselbe Identität zu und gewähren Sie ihnen Speicherzugriff, wie in Geo-Replikation und Failover beschrieben.

Häufig gestellte Fragen

Können Server- und Datenbankzugangsdaten auf demselben Server koexistieren?

Ja, auf demselben logischen Server und in derselben Datenbank. Der IDENTITY Wert jeder Zugangsberechtigung bestimmt, welche Identität eine Abfrage verwendet: MANAGED IDENTITY verwendet die Identität des Servers und DATABASE MANAGED IDENTITY die Identität der Datenbank.

Kann ich eine vom System zugewiesene verwaltete Identität verwenden?

No. Eine vom System zugewiesene verwaltete Identität gehört zum logischen Server, daher kann man sie nicht auf eine einzige Datenbank limitieren. Verwenden Sie eine vom Benutzer zugewiesene verwaltete Identität.

Welche Servicestufen und Regionen unterstützen diese Vorschau?

Alle Azure SQL-Datenbank-Service-Tiers, in allen Azure-Regionen.

Brauche ich einen Datenbank-Masterschlüssel?

No. Weder DATABASE MANAGED IDENTITY noch DATABASE FEDERATED CLIENT IDENTITY verwendet ein Secret, daher ist kein Masterschlüssel erforderlich.

Funktioniert diese Funktion mit sp_invoke_external_rest_endpoint?

Nicht in dieser Vorschau. Die Vorschau behandelt Datenvirtualisierung.

Verwandte Inhalte

  • Zuletzt aktualisiert um