Használjon adatbázisszintű felügyelt identitást az Azure SQL Database szolgáltatással (preview)

A következőkre vonatkozik:Azure SQL Database

Az adatbázis-szintű menedzselt identitás egy Azure SQL Database-ben található adatbázisnak saját, felhasználó által hozzárendelt menedzselt identitást (UAMI) ad. Az az adatbázis, amely saját felügyelt identitással rendelkezik, saját magaként hitelesíti magát az Azure Storage felé, nem pedig az azt üzemeltető logikai szerverként.

Adatbázis-szintű identitás nélkül minden logikai szerver adatbázisa megosztja az adott szerver kezelt identitását, így mindegyik ugyanazt a tárolót éri el. Egy adatbázis-szintű identitás szűkíti ezt a hozzáférést egyetlen adatbázisra, így minden adatbázisnak csak a szükséges tárolót adhatod meg.

Az identitást egy adatbázis-hatókörű hitelesítő adatban választod ki, ugyanazt a hitelesítő adatot, amelyet az adatvirtualizációs lekérdezések használnak Parquet-, CSV- és Delta-fájlok olvasásához az Azure Blob Storage-ból vagy az Azure Data Lake Storage (ADLS) Gen2-ből. Válasszon a két hitelesítőadat-azonosító érték közül:

Hitelesítő adat azonosítója Akkor használja, ha
DATABASE MANAGED IDENTITY A tárolófiók ugyanabban a Microsoft Entra bérlőben van, mint az adatbázis.
DATABASE FEDERATED CLIENT IDENTITY A tárolófiók egy másik bérlőben van, amelyet federált identitás-hitelesítő adatokkal (FIC) érnek el.

Note

Előzetes verziójú funkcióként a cikkben bemutatott technológia a Microsoft Azure előzetes verziójának kiegészítő használati feltételeire vonatkozik.

Prerequisites

  • Egy logikai kiszolgálón lévő Azure SQL Database. Minden szolgáltatási szint és minden Azure régió támogatja ezt a funkciót.
  • Egy felhasználó által hozzárendelt menedzselt identitás ugyanabban az előfizetésben. Háttérinformációért lásd: Managed identities in Microsoft Entra for Azure SQL.
  • Engedély a szerepek kijelölésére a cél tárolófiókon, például Owner vagy User Access Administrator.
  • Egy Azure Blob Storage vagy ADLS Gen2 fiók, amely tartalmazza azokat a fájlokat, amelyeket szeretnél lekérdezni.

Important

Egy adatbázishoz csak egy felhasználó által hozzárendelt menedzselt identitás rendelhető hozzá az adatbázis szintjén, ellentétben egy logikai szerverrel, amelyhez több is hozzárendelhető. Tervezd meg az azonosítót adatbázisonként, mielőtt hozzárendeled.

Ha az adatbázis ügyfél által kezelt kulcsokat használ az adatbázis szintjén, akkor már rendelkezik adatbázis-szintű identitással, és a bérlők közötti kulcsok esetén federált ügyfélazonosítóval rendelkezik. Ez a funkció ugyanazt a két beállítást használja. Biztosíts tárolási hozzáférést a meglévő azonossághoz vagy alkalmazáshoz ahelyett, hogy újakat rendelnél. Ha más azonosítót vagy alkalmazást rendelsz hozzá, először adj neki hozzáférést a titkosítási kulcshoz. Ellenkező esetben a frissítés megbukhat, vagy az adatbázis nem férhet hozzá a kulcsához.

Válassz azonos bérlőt vagy bérlőközit

Mindkét útmutató adatbázis hatókörű hitelesítő adatot hoz létre, és külső adatokat kérdez le. Eltérnek abban, hogyan éri el az identitás a tárolófiókot.

Használj adatbázis-szintű identitást ugyanabban a bérlői környezetben

1. lépés: Felhasználó által hozzárendelt felügyelt identitás létrehozása

Hozza létre az identitást, és jegyezze fel mind az Erőforrás ID-jét, mind az Objektum (fő) ID-jét. Az identitás adatbázishoz rendeléséhez szükség van az Erőforrás-azonosítóra. Az objektum- (principal-) azonosítóra csak a cross-tenant útmutatóhoz van szükség, ahol az a föderált identitás hitelesítő adat alanyát azonosítja.

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

További módszerekért lásd: Felhasználó által hozzárendelt menedzselt identitások kezelése.

2. lépés: Az identitás hozzárendelése az adatbázishoz

Az UAMI-t az adatbázishoz rendeljük, ne a logikai szerverhez. Ez a hozzárendelés ugyanazt a mechanizmust használja, mint az adatbázis-szintű átlátszó adattitkosítás (TDE) ügyfél által kezelt kulcsokkal, az Adatbázis-szintű, ügyfél által kezelt kulcsok című témakörben leírtak szerint. A hozzárendelési módszerek teljes listáját lásd itt: Felügyelt identitás lekérése vagy beállítása adatbázishoz.

Az identitás hozzárendeléséhez az Azure portálban:

  1. Menj az SQL adatbázisodhoz.
  2. A Biztonság területen válassza az Identitás lehetőséget.
  3. A User-Assigned Managed Identity alatt válassza a Add lehetőséget.
  4. Válaszd ki a létrehozott személyazonosságot, majd válaszd a Hozzáadás lehetőséget.
  5. Válassza a Mentés lehetőséget.

Az identitás hozzárendeléséhez az Azure CLI-ben használja a(z) az sql db update parancsot:

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

A PowerShell használatával történő hozzárendeléshez használd a Set-AzSqlDatabase parancsot:

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

A Resource ID azonosító úgy néz ki, mint /subscriptions/<subscription-id>/resourceGroups/<resource-group>/providers/Microsoft.ManagedIdentity/userAssignedIdentities/<identity-name>. Az Azure Portalon a felügyelt identitás Tulajdonságok lapján találja.

3. lépés: Hozzáférést biztosítsunk az identitásnak a tárolóhoz

Adj a kezelt identitásnak olvasási hozzáférést a tárolófiókhoz:

  1. Nyissa meg a tárolási fiókot.
  2. Válassza a Hozzáférés-vezérlés (IAM) lehetőséget.
  3. Válassza a Hozzáadás>Szerepkör-hozzárendelés hozzáadása lehetőséget.
  4. Válaszd ki a Storage Blob Data Reader szerepet, majd válaszd a Következő menüt.
  5. A hozzáférés hozzárendeléséhez válassza a Felügyelt identitást.
  6. Válaszd ki Tagok kiválasztása, válaszd ki a felhasználó által kijelölt menedzselt személyazonosságodat, majd Kiválasztás.
  7. Válassza a Véleményezés + hozzárendelés lehetőséget.

Az ADLS Gen2-ben finomabb hozzáféréshez állítsd be a hozzáférési vezérlőlistákat (ACL-eket) konkrét könyvtárakon a fiók szintjén történő szerepkör-hozzárendelés helyett. További információért lásd: Access control lists in Azure Data Lake Storage.

4. lépés: Létrehozza az adatbázis-hatókörű hitelesítő adatot

Csatlakozzon a felhasználói adatbázishoz, nem master, és hozza létre a hitelesítő adatot:

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

Ennek a hitelesítő adatnak nincs szüksége titokra vagy adatbázis-mesterkulcsra. A motor a lekérdezés időpontjában feloldja az adatbázishoz rendelt azonosítót.

A szerverszintű megfelelője egy másik identitásértéket használ. Összehasonlít:

-- 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';

A teljes szintaxisért lásd: CREATE DATABASE SCOPED CREDENTIAL (CREATE DATABASE SCOPED CREDENTIAL)

5. lépés: A külső adatforrás létrehozása

Hozz létre egy külső adatforrást, amely a konténeredre mutat, és csatold hozzá a hitelesítő adatokat. Használd azt az előtagot, ami megfelel a tárolótípusodnak:

Tárolási típus Helyelőhívó
Azure Blob Storage abs://
ADLS Gen2 adls:// 
CREATE EXTERNAL DATA SOURCE MyExternalStorage
WITH (
    LOCATION = 'abs://<container>@<storage-account>.blob.core.windows.net',
    CREDENTIAL = MyDBIdentityCred
);

6. lépés: Az adatok lekérdezése

Kérdezze le a fájlokat ad hoc módon a következőképpen OPENROWSET:

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

Vagy definiáljunk külső táblázatot ismétlődő lekérdezésekhez:

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;

Használj föderált kliensidentitást bérlőkön átívelően

Használd ezt az útvonalat, amikor az adatbázisod az egyik bérlőben van, a tárolófiók pedig a másikban. A többbérlős alkalmazásregisztráció megteremti a köztük lévő bizalmi kapcsolatot: az adatbázis UAMI-ja az alkalmazás federált identitás-hitelesítő adatának alanya, és a tároló bérlő hozzáférést biztosít az alkalmazás szolgáltatásnevének az adatokhoz.

A minta megfelel a bérlők közötti, ügyfél által felügyelt kulcsoknak az átlátszó adattitkosításhoz, így a beállítás ismerősnek tűnik, ha már használod ezt a funkciót.

1. lépés: Regisztrálj egy többbérlős alkalmazást

Az adatbázist tartalmazó bérlőben regisztráljon egy több-bérlős alkalmazást a Microsoft Entra ID-ben, és jegyezze fel annak alkalmazás- (ügyfél-) azonosítóját.

További információ: Alkalmazás regisztrálása az Microsoft identitásplatformon.

2. lépés: Föderált identitás-hitelesítő adat hozzáadása

Adj hozzá egy föderált identitás hitelesítő adatot az alkalmazáshoz, hogy az alkalmazás megbízzon az adatbázis felhasználó által hozzárendelt felügyelt identitásában. Az alkalmazásnak és a kezelt identitásnak ugyanahhoz a Microsoft Entra bérlőhöz kell tartoznia.

  1. Az alkalmazás regisztrációjában válaszd a Tanúsítványok és titkok>Federált hitelességek>Hitelesítő adat hozzáadása.
  2. A Federated credential forgatókönyvhöz válassza a Managed Identity lehetőséget.
  3. Válaszd ki azt a kezelt identitást, amelyet az azonos bérlőhöz tartozó útmutató 1. lépésében hoztál létre.
  4. Ellenőrizze, hogy az automatikusan kitöltött Issuer azonosítja a bérlői környezetét. Az Azure nyilvános felhő esetén a kibocsátó https://login.microsoftonline.com/<tenant-id>/v2.0.
  5. Győződj meg róla, hogy az Audience értéke api://AzureADTokenExchange, az Azure nyilvános felhő értéke.
  6. Írj be egy egyedi nevet a hitelesítő adathoz, majd mentsd el.

A hitelesítő adat tárgya a felügyelt identitás objektumának (rendszerbiztonsági tag) azonosítója, nem pedig az ügyfélazonosítója. Ha manuálisan konfigurálod a hitelesítő adatot, pontosan másold le az objektum (fő) azonosítót, mert a tárgy kis- és nagybetűre érzékeny. A Microsoft Entra ID elfogadja a helytelen kibocsátói, alanyi vagy címzettértékeket a hitelesítő adat mentésekor, de a tokencsere később meghiúsul.

További információért lásd: Alkalmazás konfigurálása úgy, hogy megbízzon egy felügyelt identitásban.

Abban a bérlői környezetben, amely a tárfiókot tartalmazza:

  1. A rendszergazda hozzájárul a több-bérlős alkalmazáshoz, amely egyszerű szolgáltatást hoz létre az adott bérlőben.
  2. Rendeld hozzá a Storage Blob Data Reader szerepet az adott szolgáltatásnévhez a tárolófiókon. Kövesse a 3. lépést: Engedélyezze az identitás hozzáférését a tárolóhoz, de a Hozzáférés hozzárendelése ehhez beállításnál válassza a Felhasználó, csoport vagy szolgáltatásnév lehetőséget, majd válassza ki az alkalmazás szolgáltatásnevét.

4. lépés: Állítsd be a föderált kliensazonosítót az adatbázisban

Az adatbázist tartalmazó bérlőben rendelje hozzá a felhasználó által hozzárendelt felügyelt identitást az adatbázishoz, és állítsa be az 1. lépésből származó alkalmazás- (ügyfél-) azonosítót Federated Client ID-ként:

  1. Menj az SQL adatbázisodhoz.
  2. A Biztonság területen válassza az Identitás lehetőséget.
  3. User-Assigned Managed Identity alatt ellenőrizd, hogy az azonos bérlőhöz tartozó útmutató 1. lépésében szereplő azonosító fel van-e sorolva. Ha nem, válaszd az Add-t, válaszd ki az identitást, majd az Add-t.
  4. Összevont ügyfélidentitás alatt válaszd ki az alkalmazást, majd válaszd a Mentést.

A beállításhoz használja az Azure CLI-t:

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>

A PowerShell használatával történő beállításhoz:

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

5. lépés: Hozza létre a hitelesítő adatokat és futtassa a lekérdezést

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
);

Ezután hozz létre egy külső táblát, vagy futtasd a(z) OPENROWSET elemet a(z) PartnerStorage ellen pontosan úgy, mint a 6. lépésben: Az adatok lekérdezése.

Hasonlítsuk össze szerver- és adatbázisszintű identitásokat

Characteristic Szerverszintű menedzselt identitás Adatbázis-szintű menedzselt identitás
Identitás hatóköre Logikai kiszolgáló Önálló adatbázis
Hitelesítési szintaxis IDENTITY = 'MANAGED IDENTITY' IDENTITY = 'DATABASE MANAGED IDENTITY'
Bérlők közötti tároló-hozzáférés Nem támogatott. Használj helyette megosztott hozzáférési aláírást Az adatbázisban beállított Federated client ID, amelyet a IDENTITY = 'DATABASE FEDERATED CLIENT IDENTITY' elemmel használnak
A tárterületi RBAC részletessége Egy azonosító a kiszolgálón lévő minden adatbázishoz Egy azonosító adatbázisonként
Az expozíció mértéke A kiszolgálón lévő összes adatbázis osztozik a hozzáférésen Egy adatbázisra korlátozva
Identitástípusok Rendszer által hozzárendelt vagy felhasználó által hozzárendelt Csak felhasználó által hozzárendelt
Adatbázis főkulcs szükséges No No

Mindkét típusú hitelesítési adat együtt létezhet ugyanazon a logikai szerveren és annak adatbázisaiban. Válaszd ki azt a hitelesítő adatot, amely leginkább megfelel a biztonsági követelményeidnek.

Georeplikáció és failover

Az identitást egy adatbázishoz rendeled, így minden replika saját hozzárendelést kap. Konfiguráld a geo-másodlagos rendszert ugyanúgy, mint a primert, mielőtt feladatátvételt végeznél:

  • Rendelje hozzá ugyanazt a felhasználó által hozzárendelt felügyelt identitást a másodlagos adatbázishoz, mint amelyet az elsődleges használ.
  • Adja meg ennek az identitásnak ugyanazt a tárolóhozzáférést, amelyet a 3. lépés: Az identitás tárolóhozzáférésének megadása ismertet.
  • A bérlőkközi hozzáféréshez ugyanazt a Federated kliensazonosítót állítsd be a másodlagos adatbázisban.

Ha mindkét replikát így konfigurálod, az adatbázis-hatókörű hitelesítő adatokat használó lekérdezések a failover után is működnek. A követelmény egyezik az adatbázis-szintű, ügyfél által kezelt kulcsokkal, amelyekhez az identitásnak minden replikán is meg kell lennie.

Ugyanez a konfiguráció érvényes mind az aktív georeplikációra , mind a failover csoportokra is.

Limitations

  • Csak Azure SQL Database. Azure SQL Managed Instance, SQL Server és Azure Synapse Analytics nem támogatják ezeket a hitelesítőadat-identitásokat.
  • Csak kimenő hitelesítés. Ez a funkció nem változtatja meg, hogyan autentikálják a felhasználók és az alkalmazások az adatbázishoz.
  • A(z) master adatbázisban nem támogatott. Hozd létre a hitelesítő adatot egy felhasználói adatbázisban.
  • Csak a felhasználó által hozzárendelt menedzselt identitások. A rendszer által hozzárendelt menedzselt identitás a logikai szerverre van korlátozva, így nem működhet adatbázis-szintű identitásként.
  • Adatbázisonként egy felhasználó által kijelölt menedzselt identitás.
  • Ez az előzetes csak az adatvirtualizációt fedi le: CREATE EXTERNAL TABLE, valamint OPENROWSET a következővel: DATA_SOURCE. Más kimenő funkciók, mint sp_invoke_external_rest_endpointpéldául , nem tartoznak a hatókörbe.

Troubleshoot

Az adatbázis-alapú hitelesítő adatok létrehozása nem erősíti meg, hogy az adatbázis identitása tokenhez juthat vagy hozzá tud férni a tárolóhoz. A hibák később jelennek meg, amikor külső adatforrást hozol létre vagy olyan lekérdezést futtatsz, amely a hitelesítő adatokat használja.

Az adatbázis identitása nincs konfigurálva (hiba: 15858)

Létrehozhatsz egy hitelesítő adatot IDENTITY = 'DATABASE MANAGED IDENTITY' mielőtt a felhasználó által kijelölt menedzselt identitást rendelnél az adatbázishoz. Ha egy lekérdezés ezután használja a hitelesítő adatot, és az adatbázisnak nincs identitása token beszerzéséhez, a lekérdezés 15858-as hibával sikertelen lesz:

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)'.

Rendelj hozzá egy felhasználó által hozzárendelt menedzselt identitást az adatbázishoz a 2. lépés szerint, adj hozzáférést a tárolófiókhoz, majd próbáld meg újra a lekérdezést. Az identitás kizárólag a logikai szerverhez való rendelése nem konfigurál adatbázis-szintű identitást. Ha az adatbázis-hozzárendelés megvan, és a hiba továbbra is fennáll, vegye fel a kapcsolatot a Microsoft ügyfélszolgálatatal, hogy megvizsgálják az adatbázis-identitás kiépítését.

Note

A 4675-ös nyomkövetési jelző és a Biztonsági mentés és visszaállítás URL-re felügyelt identitások használatával című cikkben ismertetett törlési és újbóli létrehozási lépés az Azure-beli virtuális gépeken futó SQL Serverre vonatkoznak. Ezek nem vonatkoznak az adatbázis-szintű menedzselt identitásra az Azure SQL Database-ben.

A hitelesítő adat nem található meg, vagy nem lehet rá hivatkozni (46516-os hiba)

Amikor külső adatforrást hozol létre, az Azure SQL Database ellenőrzi, hogy a hitelesítő adat létezik-e a jelenlegi adatbázisban, és hogy jogosult vagy rá hivatkozni. Ha bármelyik ellenőrzés sikertelen, akkor 46516 hiba jelentkezik:

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

Hozd létre a hitelesítő adatot abban az adatbázisban, amely tartalmazza a külső adatforrást, ellenőrizd a hitelesítő adat nevét, és győződj meg róla, hogy jogosult vagy hivatkozni a hitelesítő adatra.

A token beszerzése meghibásodott (hiba 15858)

Ha az adatbázis nem tud Microsoft Entra tokent kapni, és a token szolgáltató indokot ad vissza, a 15858-as hiba tartalmazza ezt az indokot:

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

Használd a beágyazott hibaüzenetet, hogy megtudd, miért bukott meg a token kérés. A bérlők közötti hozzáféréshez ellenőrizd az alkalmazást, a tárolóbérlőben megadott rendszergazdai hozzájárulást és a föderált identitás hitelesítő adatait, ahogyan az Alkalmazás konfigurálása úgy, hogy megbízzon egy felügyelt identitásban című részben is szerepel.

A külső adatok olvasásához az identitásnak tárolóadat-szerepre is szüksége van. Ugyanazon bérlőhöz való hozzáféréshez adja meg a Storage Blob Data Reader szerepkört a konténeren vagy a tárolófiókon az adatbázis felhasználó által hozzárendelt felügyelt identitásának. Bérlők közötti hozzáféréshez adja meg azt az alkalmazás szolgáltatásnevének a tárolóbérlőben. További információ: Azure-szerepkör hozzárendelése blobadatokhoz való hozzáféréshez.

A fájl nem létezik, vagy nem érhető el (4860-as hiba)

Ha egy fájl hiányzik vagy nem olvasható, akkor 4860-as hiba jelentkezik:

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.

Ellenőrizd, hogy a fájl létezik-e a konfigurált helyen. Ezután ellenőrizze, hogy a kérés által használt azonosító hozzáfér-e ehhez egy Storage-adatszerepkörön keresztül, vagy ADLS Gen2 esetén az elérési úton lévő hozzáférés-vezérlési listákon (ACL-eken) keresztül.

A hálózati hozzáférés blokkolva van (42121 és 16539 hiba)

Ha a logikai szerver egy hálózati biztonsági perimeterhez van kötve, amely nem engedi a kimenő forgalmat a tárolófiókba, akkor 42121 hiba következik:

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

Adj hozzá egy kimenő hozzáférési szabályt a tárolófiók állomásnevéhez a peremprofilhoz, vagy társítsd a tárolófiókot ugyanahhoz a periméterhez. További információért lásd: Network security perimeter for Azure SQL Database.

Ha a logikai szerveren korlátozott a kimenő hálózat, és a tárolófiók nincs a szerver kimenő tűzfal szabályaiban, akkor 16539-es hiba jelentkezik:

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.

Adj hozzá egy kimenő tűzfalszabályt a külső adatforrás helyén található pontos tároló hosztnévre. További információért lásd: Az Azure SQL Database és az Azure Synapse Analytics kimenő tűzfalszabályai.

A bérlők közötti konfiguráció hiányzik vagy hibás (16561 és 16562 hibák)

Egy keresztbérlős lekérdezés meghiúsulhat ezen hibák bármelyikével, vagy a 4860-as hibával:

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.

Ezek a hibák azt jelentik, hogy a lekérdezés nem tudta elérni a fájlokat. Az identitás nem rendelkezik a szükséges tárolószerepkel, a hálózati hozzáférés blokkolva lehet, a tárolási hely vagy cím nem oldható fel, vagy a token rossz bérlőhöz tartozik. A hiba kijavítása:

  • Adja meg a megfelelő Storage-adatszerepkört.
  • Engedélyezd a tárolófiók hálózati hozzáférését.
  • Vedd fel a konténert a külső adatforrás helyén.
  • Használd DATABASE FEDERATED CLIENT IDENTITY, és állítsd be a Federated Client ID-t az adatbázisban, ahogy a 4. lépésben leírtuk.
  • Győződjön meg róla, hogy a szövetségesidentitás-hitelesítő adat alanya pontosan egyezik a kezelt identitás Object (principal) ID-jével.

Lekérdezések meghibásodnak a failover után

Ha a lekérdezések token vagy authorizációs hibákkal kudarcot szenvednek a failover után, az új elsődleges nem feltétlenül rendelkezik ugyanazzal a felhasználó által rendelt menedzselt identitással, mint amit az eredeti elsődleges alkalmazott. Vagy lehet, hogy az identitásnak nincs szerepkiosztása a tárolófiókon. Ugyanazt az identitást rendelje mindkét replikához, és adjon neki tárolási hozzáférést, ahogy azt a Geo-replikáció és a failover című részben leírjuk.

Gyakori kérdések

Létezhetnek-e szerver- és adatbázisszintű hitelesítő adatok együtt ugyanazon a szerveren?

Igen, ugyanazon logikai szerveren és ugyanabban az adatbázisban. Az egyes hitelesítő adatok IDENTITY értéke határozza meg, melyik identitást használja a lekérdezés: MANAGED IDENTITY a szerver identitását használja, és DATABASE MANAGED IDENTITY az adatbázis identitását.

Használhatok rendszerhez rendelt menedzselt identitást?

No. A rendszer által hozzárendelt menedzselt identitás a logikai szerverhez tartozik, így nem lehet egyetlen adatbázisra korlátozni. Használj egy felhasználó által kijelölt menedzselt identitást.

Mely szolgáltatási szintek és régiók támogatják ezt az előzetes verziót?

Az Azure SQL Database összes szolgáltatási szintje minden Azure-régióban.

Szükségem van egy adatbázis-főkulcsra?

No. Sem a DATABASE MANAGED IDENTITY, sem a DATABASE FEDERATED CLIENT IDENTITY nem fogad el titkos kulcsot, így nincs szükség mesterkulcsra.

Ez a funkció működik a következővel: sp_invoke_external_rest_endpoint?

Ebben az előnézetben nem érhető el. Az előnézet az adatvirtualizációt fedi le.

Kapcsolódó tartalom

  • Utolsó frissítés időpontja: