Virtualización de datos con Azure SQL Database (versión preliminar)

2025-06-21

La característica de virtualización de datos de Azure SQL Database permite ejecutar consultas Transact-SQL (T-SQL) en archivos que almacenan datos en formatos de datos comunes como CSV (sin necesidad de usar texto delimitado), Parquet y Delta (1.0). Puede consultar estos datos en Azure Data Lake Storage Gen2 o Azure Blob Storage y combinarlos con datos relacionales almacenados localmente mediante combinaciones. De este modo, puede acceder a los datos externos (en el modo de solo lectura) de manera transparente y conservar su formato y ubicación originales, un proceso que también se conoce como "virtualización de datos".

Información general

La virtualización de datos proporciona dos maneras de consultar archivos destinados a diferentes conjuntos de escenarios:

Sintaxis de OPENROWSET: optimizada para la consulta ad hoc de archivos. Por lo general, se usa para explorar rápidamente el contenido y la estructura de un conjunto nuevo de datos.
Sintaxis de CREATE EXTERNAL TABLE: optimizada para la consulta repetitiva de archivos con una sintaxis idéntica a la que existiría si los datos estuviesen almacenados localmente en la base de datos. La preparación de las tablas externas requiere de varios pasos en comparación con la sintaxis de OPENROWSET, pero permite controlar más el acceso a los datos. Por lo general, las tablas externas se utilizan para la generación de informes y cargas de trabajo analíticas.

En cualquier caso, se debe crear un origen de datos externo mediante la sintaxis CREATE EXTERNAL DATA SOURCE de Transact-SQL, como se muestra en este artículo.

Formatos de archivo

Se admiten directamente los formatos de archivo Parquet y de texto delimitado (CSV). El formato de archivo JSON se admite indirectamente al especificar el formato de archivo CSV en el que las consultas devuelven cada documento como una fila independiente. Puede analizar las filas con JSON_VALUE y OPENJSON.

Tipos de almacenamiento

Los archivos se pueden almacenar en Azure Data Lake Storage Gen2 o Azure Blob Storage. Para consultar archivos, debe proporcionar la ubicación en un formato específico y usar el prefijo de tipo de ubicación correspondiente al tipo de origen externo y punto de conexión o protocolo, como los ejemplos siguientes:

--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>/

Importante

Use siempre prefijos específicos del punto de conexión. El prefijo de tipo de ubicación proporcionado se usa para elegir el protocolo óptimo para la comunicación y aprovechar las funcionalidades avanzadas que ofrece el tipo de almacenamiento determinado.

El prefijo genérico https:// solo se admite para BULK INSERT, pero no para otros casos de uso, incluidos OPENROWSET o EXTERNAL TABLE.

Comienza

Si es primera vez que utiliza la virtualización de datos y quiere probar rápidamente la funcionalidad, empieza por consultar conjuntos de datos públicos en Azure Open Datasets, como el conjunto de datos Bing COVID-19, que permite un acceso anónimo.

Use los puntos de conexión siguientes para consultar los conjuntos de datos 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

Para empezar rápido, ejecute esta consulta de T-SQL sencilla para obtener la primera información sobre el conjunto de datos. Esta consulta usa OPENROWSET para consultar un archivo almacenado en una cuenta de almacenamiento disponible públicamente:

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

Puede continuar la exploración del conjunto de datos anexando WHEREy GROUP BY otras cláusulas en función del conjunto de resultados de la primera consulta.

Una vez que se haya familiarizado con la consulta de conjuntos de datos públicos, considere la posibilidad de cambiar a conjuntos de datos no públicos que requieren proporcionar credenciales, conceder derechos de acceso y configurar reglas de firewall. En muchos escenarios reales, operará principalmente con conjuntos de datos privados.

Acceso a cuentas de almacenamiento no públicas

Un usuario que haya iniciado sesión en una instancia de Azure SQL Database debe estar autorizado para acceder a los archivos de consulta almacenados en cuentas de almacenamiento no públicas. Los pasos de autorización dependen de cómo Azure SQL Database autentica el almacenamiento. Los tipos de autenticaciones y los parámetros relacionados no se proporcionan directamente con cada consulta. Se encapsulan en el objeto de credencial con ámbito de base de datos almacenado en la base de datos de usuario. La base de datos usa la credencial para acceder a la cuenta de almacenamiento en cualquier momento en que se ejecute la consulta.

Azure SQL Database admite los siguientes tipos de autenticación:

Firma de acceso compartido (SAS)
Identidad administrada
Autenticación de paso a través de Microsoft Entra a través de la identidad de usuario

Una firma de acceso compartido (SAS) proporciona acceso delegado a los archivos de una cuenta de almacenamiento. SAS proporciona control pormenorizado sobre el tipo de acceso que concede, incluido el intervalo de validez, los permisos concedidos y el intervalo de direcciones IP aceptables. Una vez creado el token de SAS, no se puede revocar ni eliminar y permite el acceso hasta que expire su período de validez.

Puede obtener un token de SAS de varias maneras:
- Vaya a Azure Portal:> la cuenta de almacenamiento ->Firma de acceso compartido -> Configuración de permisos -> Generación de SAS y cadena de conexión. Para más información, consulte Generación de una firma de acceso compartido.
- Cree y configure una SAS con el Explorador de Azure Storage.
- Puede crear un token de SAS mediante programación a través de PowerShell, la CLI de Azure, .NET y la API REST. Para obtener más información, consulte Otorgar acceso limitado a recursos de Azure Storage con firmas de acceso compartido (SAS).
Conceda permisos de lectura y lista a través de la SAS para acceder a datos externos. Actualmente, la virtualización de datos con Azure SQL Database es de solo lectura.
Para crear una credencial con ámbito de base de datos en Azure SQL Database, primero debe crear la clave maestra de base de datos, si aún no existe una. Se requiere una clave maestra de base de datos cuando la credencial requiere SECRET.
```
-- Create MASTER KEY if it doesn't exist in the database:
CREATE MASTER KEY 
ENCRYPTION BY PASSWORD = '<Some Very Strong Password Here>';
```
Cuando se genera un token de SAS, incluye un signo de interrogación (?) al principio del token. Para usar el token, debe quitar el signo de interrogación (?) al crear una credencial. Por ejemplo:
```
CREATE DATABASE SCOPED CREDENTIAL MyCredential
WITH IDENTITY = 'SHARED ACCESS SIGNATURE',
SECRET = 'sv=secret string here';
```

Una identidad administrada es una característica de Microsoft Entra ID (anteriormente Azure Active Directory) que proporciona servicios de Azure, como bases de datos de Azure SQL, con una identidad administrada en el identificador de Microsoft Entra. Esta identidad se puede usar para autorizar solicitudes de acceso a datos en cuentas de almacenamiento no públicas. Las bases de datos de Azure SQL pueden tener una identidad administrada asignada por el sistema y una o varias identidades administradas asignadas por el usuario. Pero solo se puede usar una identidad administrada a la vez.

Para acceder a los datos, el administrador de almacenamiento de Azure primero debe conceder permisos a la identidad administrada. Conceda permisos a la identidad administrada asignada por el sistema de la base de datos SQL de la misma manera que los permisos se conceden a cualquier otro usuario de Microsoft Entra. Por ejemplo:

En Azure Portal, vaya a la cuenta de almacenamiento.
En la página Control de acceso (IAM) de una cuenta de almacenamiento, seleccione Agregar asignación de roles.
Elija el rol RBAC de Azure Lector de datos de blobs de almacenamiento . Seleccione Siguiente. Este rol proporciona acceso de lectura a la identidad administrada para los contenedores de Azure Blob Storage necesarios.
- En lugar de conceder la pertenencia al rol RBAC de Azure Lector de datos de Storage Blob para la identidad administrada, también puede conceder permisos más pormenorizados en un subconjunto de archivos. Todos los usuarios que necesitan acceso para leer archivos individuales de este contenedor también deben tener el permiso Ejecutar en todas las carpetas primarias hasta la raíz (el contenedor). Para más información, consulte Establecimiento de ACL en Azure Data Lake Storage Gen2.
En la página siguiente, para Asignar acceso a, seleccione Identidad administrada.
Seleccione + Seleccionar miembros. Busque y seleccione la identidad administrada. Para más información, consulte Asignación de roles de Azure mediante Azure Portal.
Cree la credencial con ámbito de base de datos para la autenticación de identidad administrada en la base de datos de Azure SQL mediante CREATE DATABASE SCOPED CREDENTIAL (Transact-SQL). En el ejemplo siguiente, IDENTITY = 'Managed Identity' es una cadena codificada de forma rígida. Lo mismo IDENTITY = 'Managed Identity' se usa tanto para una identidad administrada asignada por el sistema como para una identidad administrada asignada por el usuario. Con una identidad administrada, no se requiere una clave maestra de base de datos porque la credencial no contiene .SECRET
```
CREATE DATABASE SCOPED CREDENTIAL MyCredential
WITH IDENTITY = 'Managed Identity';
```

La identidad de usuario, también conocida como "paso a través de Microsoft Entra", es un tipo de autorización donde la identidad del usuario de Microsoft Entra con acceso a Azure SQL Database.

Conceda permisos a la identidad de usuario del identificador de Entra de Microsoft.
- Debe ser miembro del rol Propietario de datos de Storage Blob, Colaborador de datos de Storage Blob o Lector de datos de Storage Blob para usar su identidad para acceder a los datos.
- Como alternativa, puede establecer reglas de ACL específicas para acceder a archivos y carpetas. Incluso si es propietario de una cuenta de almacenamiento, deberá agregarse a uno de los roles de datos del blob de almacenamiento. Para más información sobre el control de acceso en Azure Data Lake Store Gen2, consulte Control de acceso en Azure Data Lake Storage Gen2.
- La autenticación de paso a través de Microsoft Entra no admite tipos de inicio de sesión autenticados de SQL.
Cree una credencial con ámbito de base de datos para una cuenta de Id. de Microsoft Entra con acceso a Azure SQL Database. Sustituya <UserCredential> por el nombre de la identidad, como identity-<random string>. En el ejemplo siguiente, IDENTITY = 'User Identity' es una cadena codificada de forma rígida. Con una identidad de usuario administrada, no se requiere una clave maestra de base de datos porque la credencial no contiene .SECRET
```
CREATE DATABASE SCOPED CREDENTIAL <UserCredential>
WITH IDENTITY = 'User Identity';
```

Importante

Las aplicaciones cliente pueden almacenar en caché un token de autenticación de Microsoft Entra. Por ejemplo, Power BI almacena en caché tokens de Microsoft Entra y reutiliza el mismo token durante una hora. Puede producirse un error en las consultas de larga duración si el token expira en mitad de la ejecución de la consulta. Si experimenta errores de consulta causados por el token de acceso de Microsoft Entra que expira en medio de la consulta, considere la posibilidad de cambiar a una identidad administrada o a una firma de acceso compartido (SAS).

Acceso al almacenamiento público a través de cuentas anónimas

Si el conjunto de datos deseado permite el acceso público (también conocido como acceso anónimo), no se requiere ninguna credencial siempre y cuando Azure Storage esté configurado correctamente, consulte Configuración del acceso de lectura anónimo para contenedores y blobs.

Origen de datos externo

Un origen de datos externo es una abstracción que permite hacer referencia fácilmente a una ubicación de archivo en varias consultas. Para consultar ubicaciones públicas, lo único que debe especificar al crear un origen de datos externo es la ubicación del archivo:

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

Al acceder a cuentas de almacenamiento no públicas, junto con la ubicación, también debe hacer referencia a una credencial con ámbito de base de datos con parámetros de autenticación encapsulados. El script siguiente crea un origen de datos externo que apunta a la ruta de acceso del archivo y hace referencia a una credencial con ámbito de base de datos.

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

Consulta de orígenes de datos mediante OPENROWSET

La sintaxis de OPENROWSET permite realizar consultas ad hoc instantáneas a la vez que solo se crea la cantidad mínima necesaria de objetos de base de datos.

OPENROWSET solo requiere crear el origen de datos externo (y, posiblemente, la credencial), a diferencia del enfoque de tabla externa, que requiere un formato de archivo externo y la tabla externa misma.

El valor del parámetro DATA_SOURCE se antepone automáticamente al parámetro BULK para formar la ruta de acceso completa al archivo.

Cuando utilice OPENROWSET, proporcione el formato del archivo, como en el ejemplo siguiente, en el que se consulta un archivo único:

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

Consulta de varios archivos y carpetas

El comando OPENROWSET también permite consultar varios archivos o carpetas mediante el uso de caracteres comodín en la ruta de acceso BULK.

En el ejemplo siguiente, se usa el conjunto de datos abierto de registros de viajes NYC Yellow Taxi.

En primer lugar, cree el origen de datos externo:

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

Ahora podemos consultar todos los archivos con la extensión .parquet en carpetas. Por ejemplo, aquí solo consultaremos los archivos que coincidan con un patrón de nombre:

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

Cuando se consultan varios archivos o carpetas, todos los archivos a los que se accede con OPENROWSET único deben tener la misma estructura (como la misma cantidad de columnas y tipos de datos). Las carpetas no se pueden recorrer de manera recursiva.

Inferencia de esquemas

La inferencia automática de esquemas ayuda a escribir rápidamente consultas y a explorar los datos cuando no se conocen los esquemas de archivo. La inferencia de esquemas solo funciona con los archivos de formato Parquet.

Aunque es conveniente, los tipos de datos inferidos pueden ser mayores que los tipos de datos reales, ya que podría haber suficiente información en los archivos de origen para asegurarse de que se usa el tipo de datos adecuado. Esto puede provocar un rendimiento deficiente de las consultas. Por ejemplo, los archivos Parquet no contienen metadatos sobre la longitud máxima de la columna de caracteres, por lo que la instancia se infiere como varchar(8000).

Utilice el procedimiento almacenado sp_describe_first_results_set para comprobar los tipos de datos resultantes de su consulta, como en el ejemplo siguiente:

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

Una vez que conoce los tipos de datos, puede especificarlos con la cláusula WITH para mejorar el rendimiento:

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;

Como el esquema de los archivos CSV no se puede determinar automáticamente, debe especificar siempre las columnas con la cláusula 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;

Funciones de metadatos del archivo

Al consultar varios archivos o carpetas, puede usar las funciones filepath() y filename() para leer los metadatos de los archivos y obtener parte de la ruta de acceso (o la ruta de acceso completa) y el nombre del archivo del que se origina la fila del conjunto de resultados:

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

Cuando se la llama sin ningún parámetro, la función filepath() devuelve la ruta de acceso al archivo del que se origina la fila. Cuando se usa DATA_SOURCE en OPENROWSET, devuelve la ruta de acceso relativa a DATA_SOURCE; de lo contrario, devuelve la ruta de acceso completa al archivo.

Cuando se la llama con un parámetro, devuelve la parte de la ruta de acceso que coincide con el carácter comodín en la posición especificada del parámetro. Por ejemplo, el valor 1 del parámetro devolvería la parte de la ruta de acceso que coincide con el primer carácter comodín.

La función filepath() también se puede usar para filtrar y agregar filas:

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;

Creación de una vista sobre OPENROWSET

Puede crear y usar vistas para encapsular las consultas OPENROWSET a fin de reutilizar fácilmente la consulta subyacente:

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

También resulta conveniente agregar columnas con los datos de ubicación del archivo a una vista mediante la función filepath() para lograr un filtrado más sencillo y con mejor rendimiento. El uso de las vistas puede disminuir el número de archivos y la cantidad de datos que la consuma sobre la vista debe leer y procesar cuando se filtra en función de cualquiera de esas columnas:

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;

Las vistas también permiten que herramientas de informes y análisis, como Power BI, consuman los resultados de OPENROWSET.

Tablas externas

Las tablas externas encapsulan el acceso a los archivos, lo que hace que la experiencia de consulta sea casi idéntica a la consulta de datos relacionales almacenados en tablas de usuario. Para crear una tabla externa, se requiere el origen de datos externo y los objetos de formato de archivo externo:

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

Una vez que se crea la tabla externa, puede consultarla tal como lo haría con cualquier otra tabla:

SELECT TOP 10 *
FROM tbl_TaxiRides;

Al igual que OPENROWSET, las tablas externas permiten consultar varios archivos y carpetas mediante el uso de caracteres comodín. No se admite la inferencia de esquemas con tablas externas.

Consideraciones sobre el rendimiento

No hay ningún límite estricto en cuanto al número de archivos o la cantidad de datos que se pueden consultar, pero el rendimiento de la consulta depende de la cantidad de datos, el formato de los datos y la complejidad de las consultas y las combinaciones.

Consulta de datos con particiones

Los datos a menudo se organizan en subcarpetas también denominadas particiones. Puede indicar a la consulta que lea solo carpetas y archivos concretos. De este modo, se reduce el número de archivos y la cantidad de datos que la consulta tiene que leer y procesar, lo que proporciona un mejor rendimiento. Este tipo de optimización de consultas se conoce como eliminación de particiones. Puede eliminar las particiones de la ejecución de consultas mediante la función filepath() de metadatos en la WHERE cláusula de la consulta.

En el ejemplo de consulta siguiente se leen archivos de datos de NYC Yellow Taxi solo para los últimos tres meses de 2017:

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;

Si los datos almacenados no tienen particiones, considere la posibilidad de crear particiones para mejorar el rendimiento de las consultas.

Si usa tablas externas, se admiten las funciones filepath() y filename() pero no en la cláusula WHERE.

Solución de problemas

Los problemas con la ejecución de consultas suelen deberse a que Azure SQL Database no puede acceder a la ubicación del archivo. Los mensajes de error relacionados pueden informar de derechos de acceso insuficientes, una ubicación o ruta de acceso de archivo no existente, un archivo utilizado por otro proceso o que no se puede mostrar ese directorio. En la mayoría de los casos, esto indica que el acceso a los archivos está bloqueado por directivas de control de tráfico de red o debido a la falta de derechos de acceso. Revise lo siguiente:

Si la ruta de acceso a la ubicación es incorrecta o está mal escrita.
La validez de la clave SAS: es posible que haya expirado, puede contener un error tipográfico o quizás comienza con un signo de interrogación.
Permisos de clave SAS permitidos: como mínimo, permiso de lectura. También el permiso de lista, si se utilizan caracteres comodín.
Es posible que el tráfico entrante esté bloqueado en la cuenta de almacenamiento. Consulte Administración de reglas de red virtual para Azure Storage.
Derechos de acceso de identidad administrada: asegúrese de que a la identidad administrada de Azure SQL Database se le conceden derechos de acceso a la cuenta de almacenamiento.
El nivel de compatibilidad de la base de datos debe ser 130 o superior para que funcionen las consultas de virtualización de datos.

Limitaciones

Actualmente, no se admiten estadísticas en tablas externas en Azure SQL Database.
Actualmente, CREATE EXTERNAL TABLE AS SELECT no está disponible en Azure SQL Database.
La característica de seguridad de nivel de fila no se admite con tablas externas.
No se puede definir una regla de enmascaramiento dinámico de datos para una columna de una tabla externa.
La identidad administrada no admite escenarios entre inquilinos, si la cuenta de Azure Storage está en otro inquilino, la firma de acceso compartido es el método admitido.

Problemas conocidos

Cuando la parametrización para Always Encrypted está habilitada en SQL Server Management Studio (SSMS), las consultas de virtualización de datos generan un mensaje de error Incorrect syntax near 'PUSHDOWN'.

OPENROWSET T-SQL
CREATE EXTERNAL TABLE (CREAR TABLA EXTERNA)
CREAR FORMATO DE ARCHIVO EXTERNO
CREAR FUENTE DE DATOS EXTERNA