次の方法で共有


Azure SQL Managed Instance によるデータ仮想化

適用対象:Azure SQL Managed Instance

この記事では、Azure SQL Managed Instance のデータ仮想化機能について説明します。 データ仮想化を使用すると、Azure Data Lake Storage Gen2 または Azure Blob Storage の一般的なデータ形式でデータを格納するファイルに対して、Transact-SQL (T-SQL) クエリを実行できます。 結合を使用して、このデータをローカルに格納されたリレーショナル データと組み合わせることができます。 データ仮想化を使用すると、元の形式と場所に保ちながら、読み取り専用モードで外部データに透過的にアクセスできます。

概要

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

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

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

CREATE EXTERNAL TABLE AS SELECT 構文 は、Azure SQL Managed Instance でも使用できます。 これは、T-SQL SELECT ステートメントの結果を Azure Blob Storage または Azure Data Lake Storage (ADLS) Gen 2 の Parquet または CSV ファイルにエクスポートし、それらのファイルの上に外部テーブルを作成するためです。

ファイル形式

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

ストレージの種類

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

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

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

重要

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

概要

データ仮想化を初めて使用し、機能をすばやくテストする場合は、まず、匿名アクセスを許可する Bing COVID-19 データセットなど、Azure Open Datasets で使用可能なパブリック データ セットに対してクエリを実行します。

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

  • Parquet: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

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

SQL マネージド インスタンスで最初のクエリが失敗した場合、そのインスタンスの Azure ストレージ アカウントへのアクセスが制限されている可能性があります。 クエリを続行する前に、ネットワークの専門家に問い合わせてアクセスを有効にしてください。

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

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

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

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

  • マネージド ID
  • 共有アクセス署名 (SAS)

マネージド ID は、Microsoft Entra ID で管理される ID を使用して、Azure SQL Managed Instance などの Azure サービスを提供する、Microsoft Entra ID (旧称 Azure Active Directory) の機能です。 この ID を使用して、非パブリック ストレージ アカウントのデータ アクセス要求を承認できます。 Azure SQL Managed Instance などのサービスには、システム割り当てマネージド ID が設定されています。さらに 1 つまたは複数のユーザー割り当てマネージド ID を設定することがもきます。 Azure SQL Managed Instance によるデータ仮想化の場合は、システム割り当てマネージド ID またはユーザー割り当てマネージド ID のいずれかを使用できます。

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

  1. Azure portal のストレージ アカウントの [Access Control (IAM)] ページで、[ロールの割り当ての追加] を選択します。
  2. 組み込みの Azure RBAC ロールである [ストレージ BLOB データ閲覧者] を選択します。 このロールは、必要な Azure Blob Storage コンテナーのマネージド ID への読み取りアクセスを提供します。
    • [ストレージ BLOB データ閲覧者] Azure RBAC ロールをマネージド ID に付与するのではなく、ファイルのサブセットに対してさらに細かいアクセス許可を付与することもできます。 このデータ内の個々のファイルを 読み取 るアクセス権を必要とするすべてのユーザーには、ルート (コンテナー) までのすべての親フォルダーに対する 実行 アクセス許可も必要です。 詳細については、「 Azure Data Lake Storage Gen2 での ACL の設定」を参照してください。
  3. 次のページでは、[マネージド ID][アクセス権の割り当て] を選択します。 [ + メンバーの選択] を選択し、[ マネージド ID ] ドロップダウン リストで目的のマネージド ID を選択します。 詳細については、Azure portal を使用して Azure ロールを割り当てる方法に関するページを参照してください。
  4. 次に、マネージド ID 認証用のデータベース スコープ資格情報を作成します。 次の例では、'Managed Identity' がハードコーディングされた文字列であることに注意してください。
-- Optional: Create MASTER KEY if it doesn't exist in the database:
-- CREATE MASTER KEY ENCRYPTION BY PASSWORD = '<Some Very Strong Password Here>'
GO
CREATE DATABASE SCOPED CREDENTIAL MyCredential
WITH IDENTITY = 'Managed Identity'

外部データ ソース

外部データ ソースは、複数のクエリにわたるファイルの場所への簡単な参照を提供する抽象化です。 パブリックの場所を照会するには、外部データ ソースを作成するときにファイルの場所を指定します。

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 that points to the file path, and that references a database scoped credential:
CREATE EXTERNAL DATA SOURCE MyPrivateExternalDataSource
WITH (
    LOCATION = 'abs://public@pandemicdatalake.blob.core.windows.net/curated/covid-19/bing_covid-19_data/latest'
        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;
--List all paths:
SELECT DISTINCT filerows.filepath(1) as [Year_Folder], filerows.filepath(2) as [Month_Folder]
FROM OPENROWSET(
 BULK 'yellow/puYear=*/puMonth=*/*.parquet',
 DATA_SOURCE = 'NYCTaxiExternalDataSource',
 FORMAT = 'parquet') AS filerows;

パラメーターを指定せずに呼び出した場合、filepath()関数は行の元となるファイルパスを返します。 DATA_SOURCEOPENROWSETで使用されている場合は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
)
GO

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

外部テーブルを作成した後は、他のテーブルと同様にクエリを実行できます。

SELECT TOP 10 *
FROM tbl_TaxiRides;

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

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

ファイルの数やクエリできるデータの量に厳しい制限はありませんが、クエリのパフォーマンスは、データの量、データ形式、データの編成方法、クエリと結合の複雑さによって異なります。

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

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

次のクエリ サンプルでは、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 句ではサポートされません。 次の例に示すように、計算列で使用する場合は、 filename または filepath でフィルター処理できます。

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,
 [Year]  AS CAST(filepath(1) AS INT), --use filepath() for partitioning
 [Month]  AS CAST(filepath(2) AS INT) --use filepath() for partitioning
)
WITH (
 LOCATION = 'yellow/puYear=*/puMonth=*/*.parquet',
 DATA_SOURCE = NYCTaxiExternalDataSource,
 FILE_FORMAT = DemoFileFormat
);
GO

SELECT *
      FROM tbl_TaxiRides
WHERE
      [year]=2017
      AND [month] in (10,11,12);

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

Statistics

外部データの統計を収集することは、クエリの最適化のために実行できる最も重要なことの1つです。 インスタンスがデータについて知れば知るほど、クエリを高速に実行することができます。 SQL エンジンのクエリ オプティマイザーは、コストベースのオプティマイザーです。 オプティマイザーでは、さまざまなクエリ プランのコストが比較されて、最も低コストのプランが選択されます。 多くの場合、最も高速に実行されるプランが選択されます。

統計の自動作成

Azure SQL Managed Instance では、欠落している統計情報について、受信したユーザー クエリを分析します。 統計が足りない場合、クエリ プランに対するカーディナリティ評価を改善するために、クエリ オプティマイザーによって、クエリ述語または結合条件内の個々の列に関して統計が自動的に作成されます。 統計の自動作成は同期的に行われるため、列に統計がない場合、クエリのパフォーマンスが多少低下する可能性があります。 1 つの列の統計を作成する時間は、ターゲットとされるファイルのサイズに依存します。

OPENROWSET の手動統計

OPENROWSET パスの単一列統計は、sys.sp_create_openrowset_statistics ストアド プロシージャを使用して作成できます。パラメーターとして 1 つの列を持つ select クエリを渡します。

EXEC sys.sp_create_openrowset_statistics N'
SELECT pickup_datetime
FROM OPENROWSET(
 BULK ''abs://public@pandemicdatalake.blob.core.windows.net/curated/covid-19/bing_covid-19_data/latest/*.parquet'',
 FORMAT = ''parquet'') AS filerows
';

デフォルトでは、インスタンスはデータセットに指定されたデータの 100% を使用して統計を作成します。 オプションでTABLESAMPLEオプションを使用して、サンプル サイズをパーセンテージとして指定できます。 複数の列の単一列統計を作成するには、各列の sys.sp_create_openrowset_statistics を実行します。 OPENROWSETパスの複数列統計を作成することはできません。

既存の統計を更新するには、まずsys.sp_drop_openrowset_statisticsストアド プロシージャを使用して削除し、sys.sp_create_openrowset_statisticsを使用して再作成します。

EXEC sys.sp_drop_openrowset_statistics N'
SELECT pickup_datetime
FROM OPENROWSET(
 BULK ''abs://public@pandemicdatalake.blob.core.windows.net/curated/covid-19/bing_covid-19_data/latest/*.parquet'',
 FORMAT = ''parquet'') AS filerows
';

外部テーブルの手動統計

外部テーブルに統計を作成するための構文は、通常のユーザー テーブルに使用される構文に似ています。 列の統計を作成するには、統計オブジェクトの名前と列の名前を指定します。

CREATE STATISTICS sVendor
ON tbl_TaxiRides (vendorID)
WITH FULLSCAN, NORECOMPUTE;

WITHオプション は必須であり、サンプル サイズの場合、FULLSCANSAMPLE nパーセントのオプションが許可されています。

  • 複数の列の単一列統計を作成するには、各列の CREATE STATISTICS を実行します。
  • 複数列の統計はサポートされていません。

トラブルシューティング

通常、クエリの実行に関する問題は、SQL マネージド インスタンスがファイルの場所にアクセスできない場合に発生します。 関連するエラー メッセージでは、アクセス権が不十分であること、存在しない場所、別のプロセスで使用されているファイル、またはそのディレクトリを一覧表示できない可能性があります。 ほとんどの場合、これらのエラーは、ネットワーク トラフィック制御ポリシーによってファイルへのアクセスがブロックされているか、ユーザーにアクセス権がないことを示しています。 次の項目を確認します。

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

SELECT として外部テーブルを作成する (CETAS)

CREATE EXTERNAL TABLE AS SELECT (CETAS) を使用すると、SQL マネージド インスタンスから外部ストレージ アカウントにデータをエクスポートできます。 CETAS を使用して、Azure Blob Storage または Azure Data Lake Storage (ADLS) Gen2 の Parquet または CSV ファイルの上に外部テーブルを作成できます。 CETAS は、T-SQL SELECT ステートメントの結果を、作成された外部テーブルに並行してエクスポートすることもできます。 これらの機能ではデータ流出リスクが発生する可能性があるため、Azure SQL Managed Instance では既定で CETAS が無効になります。 有効にするには、「CREATE EXTERNAL TABLE AS SELECT (CETAS)」を参照してください。

制限事項

既知の問題

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