Azure SQL Database を使用したデータ仮想化 (プレビュー)

2025-06-21

Azure SQL Database のデータ仮想化機能を使用すると、CSV (区切りテキストを使用する必要はありません)、Parquet、デルタ (1.0) などの一般的なデータ形式でデータを格納するファイルに対して、Transact-SQL (T-SQL) クエリを実行できます。このデータは、Azure Data Lake Storage Gen2 または Azure Blob Storage でクエリを実行し、結合を使用してローカルに格納されたリレーショナルデータと組み合わせることができます。こうすることで、外部データ (読み取り専用モード内) を元の形式と場所に保持したまま透過的にアクセスすることができます。これはデータの仮想化とも呼ばれています。

概要

データ仮想化では、さまざまなシナリオのセットを対象としたファイルのクエリを実行する 2 つの方法が提供されます。

OPENROWSET 構文 – ファイルのアドホッククエリ用に最適化されています。通常は、新しいファイルセットのコンテンツと構造をすばやく調べるために使用されます。
CREATE EXTERNAL TABLE 構文 – データがデータベースにローカルに保存されているのと同じ構文で、ファイルを繰り返しクエリするために最適化されています。外部テーブルでは、OPENROWSET 構文と比較していくつかの準備ステップが必要ですが、データアクセスの制御をより強化することができます。外部テーブルは、通常、分析ワークロードとレポートに使用されます。

どちらの場合も、この記事で示すように、T-SQL の CREATE EXTERNAL DATA SOURCE 構文を使って外部データソースを作成する必要があります。

ファイル形式

Parquet 形式と区切りテキスト (CSV) ファイル形式が直接サポートされています。 JSON ファイル形式は、クエリがすべてのドキュメントを個別の行として返す CSV ファイル形式を指定することで間接的にサポートされます。 JSON_VALUE と OPENJSON を使用して、行をさらに解析できます。

ストレージの種類

ファイルは、Azure Data Lake Storage Gen2 または Azure Blob Storage に格納できます。ファイルのクエリを実行するには、特定の形式で場所を指定し、次の例のように、外部ソースとエンドポイントまたはプロトコルの種類に対応する場所の種類のプレフィックスを使用する必要があります。

--Blob Storage endpoint
abs://<container>@<storage_account>.blob.core.windows.net/<path>/<file_name>.parquet
--or
abs://<storage_account_name>.blob.core.windows.net/<container_name>/

--Data Lake endpoint
adls://<container>@<storage_account>.dfs.core.windows.net/<path>/<file_name>.parquet
--or
adls://<storage_account_name>.dfs.core.windows.net/<container_name>/

Von Bedeutung

常にエンドポイント固有のプレフィックスを使用します。指定された場所の種類のプレフィックスは、通信に最適なプロトコルを選び、特定のストレージの種類によって提供される高度な機能を利用するために使用されます。

ジェネリック https:// プレフィックスは、 BULK INSERTでのみサポートされますが、 OPENROWSET や EXTERNAL TABLEを含む他のユースケースではサポートされません。

始めましょう

データの仮想化が初めてで、機能をすばやくテストしたい場合は、匿名アクセスを許可する Bing COVID-19 データセットなど、Azure Open Datasets で利用可能なパブリックデータセットをクエリすることから始めます。

次のエンドポイントを使用して、Bing COVID-19 データセットにクエリを実行します。

寄木細工： abs://public@pandemicdatalake.blob.core.windows.net/curated/covid-19/bing_covid-19_data/latest/bing_covid-19_data.parquet
CSV: abs://public@pandemicdatalake.blob.core.windows.net/curated/covid-19/bing_covid-19_data/latest/bing_covid-19_data.csv

クイックスタートでは、この単純な T-SQL クエリを実行して、データセットに関する最初の分析情報を取得します。このクエリでは、OPENROWSET を使用して、公開されているストレージアカウントに格納されているファイルに対してクエリを実行します。

--Quick query on a file stored in a publicly available storage account:
SELECT TOP 10 *
FROM OPENROWSET(
 BULK 'abs://public@pandemicdatalake.blob.core.windows.net/curated/covid-19/bing_covid-19_data/latest/bing_covid-19_data.parquet',
 FORMAT = 'parquet'
) AS filerows;

最初のクエリの結果セットに基づいて、 WHERE、 GROUP BY 、およびその他の句を追加することで、データセットの探索を続行できます。

パブリックデータセットのクエリに慣れたら、資格情報の提供、アクセス権の付与、ファイアウォール規則の構成を必要とする非パブリックデータセットへの切り替えを検討してください。多くの実世界のシナリオでは、主にプライベートデータセットを操作します。

非パブリックストレージアカウントにアクセスする

Azure SQL Database にログインしているユーザーは、非パブリックストレージアカウントに格納されているファイルにアクセスしてクエリを実行する権限を持っている必要があります。承認手順は、Azure SQL Database がストレージを認証する方法によって異なります。認証の種類と関連するパラメーターは、各クエリで直接提供されるわけではありません。これらは、ユーザーデータベースに格納されているデータベーススコープ資格情報オブジェクトにカプセル化されます。資格情報は、クエリが実行されるたびにストレージアカウントにアクセスするためにデータベースで使用されます。

Azure SQL Database では、次の認証の種類がサポートされています。

Shared Access Signature (SAS)
マネージド ID
ユーザー ID を使用した Microsoft Entra パススルー認証

Shared Access Signature (SAS) は、ストレージアカウント内のファイルへの委任されたアクセスを提供します。 SAS では、有効期間、許可されたアクセス許可、許容できる IP アドレス範囲など、付与するアクセスの種類をきめ細かく制御できます。作成された SAS トークンは取り消したり削除したりできず、有効期間が切れるまでアクセスを許可します。

SAS トークンは、複数の方法で取得できます。
- ストレージアカウント ->Shared アクセス署名 -> アクセス許可の構成 -> SAS と接続文字列の生成を>、Azure portal に移動します。詳細については、Shared Access Signature の作成に関するページを参照してください。
- Azure Storage Explorer を使用して SAS を作成して構成します。
- SAS トークンは、PowerShell、Azure CLI、.NET、REST API を使用してプログラムで作成できます。詳細については、「Shared Access Signatures (SAS) を使用して Azure Storage リソースへの制限付きアクセスを許可する」を参照してください。
外部データにアクセスするには、SAS を介して [読み取り] および [リスト] アクセス許可を付与します。現在、Azure SQL Database でのデータ仮想化は読み取り専用です。
Azure SQL Database でデータベーススコープの資格情報を作成するには、まずデータベースマスターキーを作成する必要があります (まだ存在しない場合)。資格情報に SECRETが必要な場合は、データベースマスターキーが必要です。
```
-- Create MASTER KEY if it doesn't exist in the database:
CREATE MASTER KEY 
ENCRYPTION BY PASSWORD = '<Some Very Strong Password Here>';
```
SAS トークンが生成されると、トークンの先頭に疑問符 (?) が含まれます。このトークンを使用するには、資格情報の作成時につけられた疑問符 (?) を削除する必要があります。例えば次が挙げられます。
```
CREATE DATABASE SCOPED CREDENTIAL MyCredential
WITH IDENTITY = 'SHARED ACCESS SIGNATURE',
SECRET = 'sv=secret string here';
```

マネージド ID は、Microsoft Entra ID (旧称 Azure Active Directory) の機能であり、Azure サービス (Azure SQL データベースなど) に Microsoft Entra ID で管理される ID を提供します。この ID は、非パブリックストレージアカウントでのデータアクセスの要求を承認するために使用できます。 Azure SQL データベースには、システム割り当てマネージド ID と、1 つ以上のユーザー割り当てマネージド ID を持つことができます。ただし、一度に使用できるマネージド ID は 1 つだけです。

Azure Storage の管理者が、データにアクセスするためのアクセス許可をマネージド ID に付与する必要があります。他の Microsoft Entra ユーザーにアクセス許可が付与されるのと同じ方法で、SQL データベースのシステム割り当てマネージド ID にアクセス許可を付与します。例えば次が挙げられます。

Azure portal のストレージアカウントに移動します。
ストレージアカウントの [アクセス制御 (IAM)] ページで、[ロールの 割り当ての追加] を選択します。
ストレージ BLOB データ閲覧者の Azure RBAC ロールを選択します。 [次へ] を選択します。このロールは、必要な Azure Blob Storage コンテナーのマネージド ID への読み取りアクセスを提供します。
- マネージド ID のストレージ BLOB データ閲覧者 Azure RBAC ロールにメンバーシップを付与する代わりに、ファイルのサブセットに対してより詳細なアクセス許可を付与することもできます。このコンテナー内の個々のファイルを読み取るためにアクセスする必要があるすべてのユーザーには、ルート (コンテナー) までのすべての親フォルダーに対する実行アクセス許可も必要です。詳細については、「 Azure Data Lake Storage Gen2 での ACL の設定」を参照してください。
次のページの [アクセス権の割り当て先] で [マネージド ID] を選びます。
[+ メンバーの選択] を選択します。マネージド ID を検索して選択します。詳細については、Azure portal を使用して Azure ロールを割り当てる方法に関するページを参照してください。
CREATE DATABASE SCOPED CREDENTIAL (Transact-SQL) を使用して、Azure SQL データベースでマネージド ID 認証用のデータベーススコープ資格情報を作成します。次の例では、 IDENTITY = 'Managed Identity' はハードコーディングされた文字列です。システム割り当てマネージド ID とユーザー割り当てマネージド ID の両方に同じ IDENTITY = 'Managed Identity' が使用されます。マネージド ID では、資格情報に SECRETが含まれていないため、データベースマスターキーは必要ありません。
```
CREATE DATABASE SCOPED CREDENTIAL MyCredential
WITH IDENTITY = 'Managed Identity';
```

ユーザー ID ("Microsoft Entra パススルー" とも呼ばれます) は、Azure SQL Database にアクセスできる Microsoft Entra ユーザーの ID を持つ承認の種類です。

Microsoft Entra ID ユーザー ID にアクセス許可を付与します。
- ID を使用してデータにアクセスするには、ストレージ BLOB データ所有者、ストレージ BLOB データ共同作成者、またはストレージ BLOB データ閲覧者ロールのメンバーである必要があります。
- または、細かい設定が可能な ACL 規則を指定して、ファイルやフォルダーにアクセスすることもできます。ストレージアカウントの所有者であっても、Storage Blob データのいずれかのロールに自分自身を追加する必要があります。 Azure Data Lake Store Gen2 でのアクセス制御の詳細については、Azure Data Lake Storage Gen2 でのアクセス制御に関するページを参照してください。
- Microsoft Entra パススルー認証では、SQL 認証ログインの種類はサポートされていません。
Azure SQL Database にアクセスできる Microsoft Entra ID アカウントのデータベーススコープ資格情報を作成します。 identity-<random string>など、ID の名前を<UserCredential>に置き換える。次の例では、 IDENTITY = 'User Identity' はハードコーディングされた文字列です。マネージドユーザー ID では、資格情報に SECRETが含まれていないため、データベースマスターキーは必要ありません。
```
CREATE DATABASE SCOPED CREDENTIAL <UserCredential>
WITH IDENTITY = 'User Identity';
```

Von Bedeutung

Microsoft Entra 認証トークンは、クライアントアプリケーションによってキャッシュされる場合があります。たとえば、Power BI では Microsoft Entra トークンをキャッシュし、同じトークンを 1 時間にわたって再利用します。実行時間の長いクエリは、クエリ実行の途中でトークンの有効期限が切れると、失敗する可能性があります。クエリの途中で有効期限が切れる Microsoft Entra アクセストークンによってクエリエラーが発生する場合は、マネージド ID または Shared Access Signature (SAS) への切り替えを検討してください。

匿名アカウントを使用したパブリックストレージへのアクセス

目的のデータセットでパブリックアクセス (匿名アクセスとも呼ばれます) が許可されている場合、Azure Storage が適切に構成されている限り、資格情報は必要ありません。コンテナーと BLOB の匿名読み取りアクセスの構成に関するページを参照してください。

外部データソース

外部データソースは、複数のクエリ間でファイルの場所を簡単に参照できるように抽象化したものです。パブリックの場所に対してクエリを実行する場合、外部データソースの作成時に指定する必要があるのはファイルの場所だけです。

CREATE EXTERNAL DATA SOURCE MyExternalDataSource
WITH (
    LOCATION = 'abs://public@pandemicdatalake.blob.core.windows.net/curated/covid-19/bing_covid-19_data/latest'
);

非パブリックストレージアカウントにアクセスする場合は、場所と共に、カプセル化された認証パラメーターを使用してデータベーススコープの資格情報を参照する必要もあります。次のスクリプトは、ファイルパスを指し、データベーススコープの資格情報を参照する外部データソースを作成します。

--Create external data source pointing to the file path, and referencing database-scoped credential:
CREATE EXTERNAL DATA SOURCE MyPrivateExternalDataSource
WITH (
    LOCATION = 'abs://<privatecontainer>@privatestorageaccount.blob.core.windows.net/dataset/' 
       CREDENTIAL = [MyCredential]
);

OPENROWSET を使用してデータソースのクエリを実行する

OPENROWSET 構文を使用すると、必要な最小限の数のデータベースオブジェクトだけを作成しながら、アドホッククエリをすぐに実行できます。

OPENROWSET は、外部ファイル形式と外部テーブル自体を必要とする外部テーブルアプローチとは対照的に、外部データソース（および場合によっては資格情報）を作成するだけで済みます。

DATA_SOURCEパラメーター値が BULK パラメーターの前に自動的に付加され、ファイルへの完全なパスが形成されます。

OPENROWSETを使用する場合は、次の例のように、ファイルの形式を指定して1 つのファイルに対してクエリを実行します。

SELECT TOP 10 *
FROM OPENROWSET(
 BULK 'bing_covid-19_data.parquet',
 DATA_SOURCE = 'MyExternalDataSource',
 FORMAT = 'parquet'
) AS filerows;

複数のファイルおよびフォルダーに対してクエリを実行する

この OPENROWSET コマンドを使用すると、BULK パスでワイルドカードを使用して複数のファイルまたはフォルダーに対してクエリを実行することもできます。

次の例では、NYC の黄色いタクシーの乗車レコードのオープンデータセットを使用します。

まず、外部データソースを作成する。

--Create the data source first:
CREATE EXTERNAL DATA SOURCE NYCTaxiExternalDataSource
WITH (LOCATION = 'abs://nyctlc@azureopendatastorage.blob.core.windows.net');

これで、フォルダー内の .parquet 拡張子を持つすべてのファイルをクエリできるようになりました。たとえば、ここでは名前パターンに一致するファイルのみをクエリします。

--Query all files with .parquet extension in folders matching name pattern:
SELECT TOP 10 *
FROM OPENROWSET(
 BULK 'yellow/puYear=*/puMonth=*/*.parquet',
 DATA_SOURCE = 'NYCTaxiExternalDataSource',
 FORMAT = 'parquet'
) AS filerows;

複数のファイルまたはフォルダーに対してクエリを実行する場合、1 つのOPENROWSETでアクセスされるファイルはすべて、同じ構造 (同じ数の列やデータ型など) を持っている必要があります。フォルダーを再帰的に走査することはできません。

スキーマ推論

スキーマの自動推論を使用すると、ファイルスキーマを知らなくてもクエリをすばやく作成し、データを探索することができます。スキーマ推論は parquet ファイルでのみ機能します。

便利ではありますが、推論されるデータ型は、実際のデータ型よりも大きくなる可能性があります。これは、適切なデータ型が使用されていることを確認するのに十分な情報がソースファイルに存在するためです。これにより、クエリのパフォーマンスが低下する可能性があります。たとえば、Parquet ファイルは最大文字列長のメタデータを含まず、インスタンスはこれを varchar (8000) として推論します。

次の例のように sp_describe_first_results_set ストアドプロシージャを使用して、クエリの結果のデータ型を確認します。

EXEC sp_describe_first_result_set N'
 SELECT
 vendorID, tpepPickupDateTime, passengerCount
 FROM
 OPENROWSET(
  BULK ''yellow/*/*/*.parquet'',
  DATA_SOURCE = ''NYCTaxiExternalDataSource'',
  FORMAT=''parquet''
 ) AS nyc';

データ型を確認したら、 WITH 句を使用してデータ型を指定し、パフォーマンスを向上させることができます。

SELECT TOP 100
 vendorID, tpepPickupDateTime, passengerCount
FROM
OPENROWSET(
 BULK 'yellow/*/*/*.parquet',
 DATA_SOURCE = 'NYCTaxiExternalDataSource',
 FORMAT='PARQUET'
 )
WITH (
vendorID varchar(4), -- we're using length of 4 instead of the inferred 8000
tpepPickupDateTime datetime2,
passengerCount int
) AS nyc;

CSV ファイルのスキーマは自動的に決定できないので、WITH 句を使用して常に列を指定する必要があります。

SELECT TOP 10 id, updated, confirmed, confirmed_change
FROM OPENROWSET(
 BULK 'bing_covid-19_data.csv',
 DATA_SOURCE = 'MyExternalDataSource',
 FORMAT = 'CSV',
 FIRSTROW = 2
)
WITH (
 id int,
 updated date,
 confirmed int,
 confirmed_change int
) AS filerows;

ファイルメタデータ関数

複数のファイルまたはフォルダーに対してクエリを実行する場合は、 filepath()とfilename()関数を使用して、ファイルメタデータを読み取り、結果セット内の行の元のファイルのパスの一部または完全なパスと名前を取得できます。

--Query all files and project file path and file name information for each row:
SELECT TOP 10 filerows.filepath(1) as [Year_Folder], filerows.filepath(2) as [Month_Folder],
filerows.filename() as [File_name], filerows.filepath() as [Full_Path], *
FROM OPENROWSET(
 BULK 'yellow/puYear=*/puMonth=*/*.parquet',
 DATA_SOURCE = 'NYCTaxiExternalDataSource',
 FORMAT = 'parquet') AS filerows;

パラメーターを指定せずに呼び出した場合、filepath()関数は行の元となるファイルパスを返します。 DATA_SOURCEがOPENROWSETで使用されている場合はDATA_SOURCEからの相対パスを返し、そうでない場合はファイルの完全なパスを返します。

パラメーターを指定して呼び出すと、パラメーターで指定した位置にあるワイルドカードと一致するパスの一部が返されます。たとえば、パラメーター値 1 の場合は、最初のワイルドカードと一致するパスの一部が返されます。

また、filepath()関数は行のフィルタリングや集計に使用することができます。

SELECT
 r.filepath() AS filepath
 ,r.filepath(1) AS [year]
 ,r.filepath(2) AS [month]
 ,COUNT_BIG(*) AS [rows]
FROM OPENROWSET(
 BULK 'yellow/puYear=*/puMonth=*/*.parquet',
DATA_SOURCE = 'NYCTaxiExternalDataSource',
FORMAT = 'parquet'
 ) AS r
WHERE
 r.filepath(1) IN ('2017')
 AND r.filepath(2) IN ('10', '11', '12')
GROUP BY
 r.filepath()
 ,r.filepath(1)
 ,r.filepath(2)
ORDER BY
 filepath;

OPENROWSET の上にビューを作成する

OPENROWSET クエリをラップするビューを作成および使用することで、基盤となるクエリを簡単に再利用できます。

CREATE VIEW TaxiRides AS
SELECT *
FROM OPENROWSET(
 BULK 'yellow/puYear=*/puMonth=*/*.parquet',
 DATA_SOURCE = 'NYCTaxiExternalDataSource',
 FORMAT = 'parquet'
) AS filerows;

また、filepath() 関数を使用して、ファイルの場所データを含む列をビューに追加して、より簡単でパフォーマンスの高いフィルタリングを行うことができます。ビューを使用すると、これらの列のいずれかでフィルタリングされたときに、ビューの上部にあるクエリが読み取って処理する必要のあるファイルの数とデータの量を減らすことができます。

CREATE VIEW TaxiRides AS
SELECT *
 , filerows.filepath(1) AS [year]
 , filerows.filepath(2) AS [month]
FROM OPENROWSET(
 BULK 'yellow/puYear=*/puMonth=*/*.parquet',
 DATA_SOURCE = 'NYCTaxiExternalDataSource',
 FORMAT = 'parquet'
) AS filerows;

ビューはまた、Power BI のようなレポートや分析ツールでOPENROWSETの結果を使用できます。

外部テーブル

外部テーブルはファイルへのアクセスをカプセル化し、ユーザーテーブルに格納されたローカルリレーショナルデータへのクエリとほぼ同じ操作性を実現します。外部テーブルを作成するには、外部データソースと外部ファイル形式オブジェクトが存在する必要があります。

--Create external file format
CREATE EXTERNAL FILE FORMAT DemoFileFormat
WITH (
 FORMAT_TYPE=PARQUET
);

--Create external table:
CREATE EXTERNAL TABLE tbl_TaxiRides(
 vendorID VARCHAR(100) COLLATE Latin1_General_BIN2,
 tpepPickupDateTime DATETIME2,
 tpepDropoffDateTime DATETIME2,
 passengerCount INT,
 tripDistance FLOAT,
 puLocationId VARCHAR(8000),
 doLocationId VARCHAR(8000),
 startLon FLOAT,
 startLat FLOAT,
 endLon FLOAT,
 endLat FLOAT,
 rateCodeId SMALLINT,
 storeAndFwdFlag VARCHAR(8000),
 paymentType VARCHAR(8000),
 fareAmount FLOAT,
 extra FLOAT,
 mtaTax FLOAT,
 improvementSurcharge VARCHAR(8000),
 tipAmount FLOAT,
 tollsAmount FLOAT,
 totalAmount FLOAT
)
WITH (
 LOCATION = 'yellow/puYear=*/puMonth=*/*.parquet',
 DATA_SOURCE = NYCTaxiExternalDataSource,
 FILE_FORMAT = DemoFileFormat
);

外部テーブルが作成されると、他のテーブルと同様にクエリを実行できます。

SELECT TOP 10 *
FROM tbl_TaxiRides;

OPENROWSETと同様に、外部テーブルを使用すると、ワイルドカードを使用して複数のファイルとフォルダーのクエリを実行できます。スキーマ推論は、外部テーブルではサポートされていません。

パフォーマンスに関する考慮事項

クエリを実行できるファイルの数やデータの量にハード制限はありませんが、クエリのパフォーマンスは、データの量、データ形式、データの整理方法、およびクエリと結合の複雑さによって異なります。

パーティション分割されたデータに対してクエリを実行する

データは、多くの場合、パーティションとも呼ばれるサブフォルダーに整理されます。特定のフォルダーとファイルのみを読み取るクエリを指示できます。そうすれば、クエリで読み込んで処理する必要があるファイルの数とデータの量が減り、パフォーマンスが向上します。この種類のクエリ最適化は、パーティションプルーニングまたはパーティションの削除と呼ばれます。クエリのWHERE句でメタデータ関数filepath()を使用して、クエリの実行からパーティションを削除できます。

次のクエリサンプルでは、2017 年の過去 3 か月間についてのみ、NYC イエロータクシーのデータファイルが読み取られます。

SELECT
    r.filepath() AS filepath
    ,r.filepath(1) AS [year]
    ,r.filepath(2) AS [month]
    ,COUNT_BIG(*) AS [rows]
FROM OPENROWSET(
        BULK 'yellow/puYear=*/puMonth=*/*.parquet',
        DATA_SOURCE = 'NYCTaxiExternalDataSource',
        FORMAT = 'parquet'
    )
WITH (
    vendorID INT
) AS [r]
WHERE
    r.filepath(1) IN ('2017')
    AND r.filepath(2) IN ('10', '11', '12')
GROUP BY
    r.filepath()
    ,r.filepath(1)
    ,r.filepath(2)
ORDER BY
    filepath;

格納されているデータがパーティション分割されていない場合は、クエリのパフォーマンスを向上させるためにパーティション分割することを検討してください。

外部テーブルを使用している場合、関数 filepath() と filename() はサポートされていますが、WHERE 句ではサポートされていません。

トラブルシューティング

クエリの実行に関する問題は、通常、Azure SQL Database がファイルの場所にアクセスできないことが原因で発生します。関連するエラーメッセージで、アクセス権が十分ではない、場所またはファイルパスが存在しない、ファイルが別のプロセスで使われている、あるいはディレクトリの一覧を取得できない、などが報告される場合があります。ほとんどの場合、ネットワークトラフィックコントロールポリシーやアクセス権の欠如により、ファイルへのアクセスがブロックされていることを示します。これが確認すべきことです。

ロケーションパスが誤っているか、または入力ミスがあります。
SAS キーの有効性: 有効期限が切れている、タイプミスが含まれている、疑問符で始まっている可能性があります。
SAS キーのアクセス許可: 少なくとも読み取りアクセス許可、およびワイルドカードが使用されている場合はリストのアクセス許可が必要です。
ストレージアカウントでインバウンドトラフィックがブロックされました。 Azure Storage の仮想ネットワーク規則の管理を確認します。
マネージド ID アクセス権: Azure SQL Database のマネージド ID にストレージアカウントへのアクセス権が付与されていることを確認します。
データ仮想化クエリを機能させるには、データベースの互換性レベルを 130 以上とする必要があります。

制限事項

現時点では、外部テーブルの統計は Azure SQL Database ではサポートされていません。
現時点では、 CREATE EXTERNAL TABLE AS SELECT は Azure SQL Database では使用できません。
行レベルのセキュリティ機能は、外部テーブルではサポートされていません。
外部テーブルの列に対して、動的データマスクルールを定義することはできません。
マネージド ID はテナント間のシナリオをサポートしていません。Azure Storage アカウントが別のテナントにある場合、Shared Access Signature がサポートされている方法です。

既知の問題

Always Encrypted のパラメーター化が SQL Server Management Studio (SSMS) で有効になっている場合、データ仮想化クエリが失敗し、エラーメッセージ Incorrect syntax near 'PUSHDOWN' が表示されます。

次の方法で共有

Azure SQL Database を使用したデータ仮想化 (プレビュー)

概要

ファイル形式

ストレージの種類

始めましょう

非パブリック ストレージ アカウントにアクセスする

匿名アカウントを使用したパブリック ストレージへのアクセス

外部データ ソース

OPENROWSET を使用してデータ ソースのクエリを実行する