Diferencias de T-SQL entre SQL Server y una Instancia administrada de Azure SQL

  • Artículo
  • Tiempo de lectura: 30 minutos

SE APLICA A: Azure SQL Managed Instance

Este artículo resume y explica las diferencias de sintaxis y comportamiento entre Instancia administrada de Azure SQL y SQL Server.

Instancia administrada de SQL proporciona una alta compatibilidad con el motor de base de datos de SQL Server, y la mayoría de las características se admiten en una Instancia administrada de SQL.

Migración sencilla desde SQL Server

Existen algunas limitaciones de PaaS que se introdujeron en Instancia administrada de SQL y algunos cambios de comportamiento en comparación con SQL Server. Las diferencias se dividen en las siguientes categorías:

La mayoría de estas características son restricciones de arquitectura y representan características de servicio.

En Novedades se explican los problemas temporales conocidos que se han detectado en SQL Managed Instance y que se van a resolver en el futuro.

Disponibilidad

Grupos de disponibilidad AlwaysOn

La alta disponibilidad está integrada en la Instancia administrada de SQL y no la pueden controlar los usuarios. No se admiten las siguientes instrucciones:

Copia de seguridad

La Instancia administrada de SQL tiene copias de seguridad automáticas, por lo que los usuarios pueden crear copias de seguridad COPY_ONLY de bases de datos completas. No se admiten copias de seguridad de instantáneas de archivos, de registro ni diferenciales.

  • Con una Instancia administrada de SQL, puede hacer una copia de seguridad de una base de datos de instancia solo en una cuenta de Azure Blob Storage:
    • Solo se admite BACKUP TO URL.
    • No se admiten FILE, TAPE ni dispositivos de copia de seguridad.
  • Se admite la mayoría de las opciones de WITH generales.
    • COPY_ONLY es obligatorio.
    • FILE_SNAPSHOT no se admite.
    • No se admiten las opciones de cinta REWIND, NOREWIND, UNLOAD y NOUNLOAD.
    • No se admiten las opciones específicas de registro NORECOVERY, STANDBY y NO_TRUNCATE.

Limitaciones:

  • Con una Instancia administrada de SQL, puede hacer una copia de seguridad de una base de datos de instancia en una copia de seguridad con hasta 32 franjas, lo cual es suficiente para bases de datos de hasta 4 TB si se usa la compresión de copia de seguridad.

  • No se puede ejecutar BACKUP DATABASE ... WITH COPY_ONLY en una base de datos cifrada con Cifrado de datos transparente (TDE) administrado por el servicio. TDE administrado por un servicio hace que las copias de seguridad se cifren con una clave interna de TDE. No es posible exportar la clave, por lo que no se puede restaurar la copia de seguridad. Use copias de seguridad automáticas y restauración a un momento dado, o use Cifrado de datos transparente administrado por el cliente (BYOK) en su lugar. También puede deshabilitar el cifrado en la base de datos.

  • Las copias de seguridad nativas realizadas en una Instancia administrada no se pueden restaurar en un servidor de SQL Server. Esto se debe a que la Instancia administrada tiene una versión de base de datos interna superior en comparación con cualquier versión de SQL Server.

  • Para crear una copia de seguridad o restaurar una base de datos hacia y desde un almacenamiento de Azure, es necesario crear una firma de acceso compartido (SAS) y un URI que conceda derechos de acceso restringidos a los recursos de Azure Storage. Más información. No se admite el uso de claves de acceso para estos escenarios.

  • El tamaño máximo de una franja de copia de seguridad con el uso del comando BACKUP en una Instancia administrada de SQL es de 195 GB, lo cual es el tamaño máximo del blob. Aumente el número de franjas en el comando de copia de seguridad para reducir el tamaño de las franjas y permanecer dentro de este límite.

    Sugerencia

    Para solucionar esta limitación, cuando realice una copia de seguridad de una base de datos desde un servidor de SQL Server en un entorno local o en una máquina virtual, puede:

    • Realizar la copia de seguridad en DISK en lugar de hacerlo en URL.
    • Cargar los archivos de copia de seguridad en Blob Storage.
    • Restaurar en la Instancia administrada de SQL.

    El comando Restore de una Instancia administrada de SQL admite tamaños de blob más grandes en los archivos de copia de seguridad porque se usa un tipo de blob distinto para el almacenamiento de los archivos de copia de seguridad cargados.

Para más información acerca de las copias de seguridad mediante T-SQL, consulte BACKUP.

Seguridad

Auditoría

Las principales diferencias entre la auditoría en Microsoft Azure SQL y en SQL Server son las siguientes:

  • Con Instancia administrada de SQL, la auditoría funciona en el nivel de servidor. Los archivos de registro .xel se almacenan en Azure Blob Storage.
  • En Azure SQL Database, la auditoría funciona en el nivel de base de datos. Los archivos de registro .xel se almacenan en Azure Blob Storage.
  • Con servidores de SQL Server locales o en los de máquinas virtuales, la auditoría funciona en el nivel de servidor. Los eventos se almacenan en el sistema de archivos o en los registros de eventos de Windows.

En Instancia administrada de SQL, la auditoría de XEvent admite Azure Blob Storage como destino. No se admiten archivos ni registros de Windows.

Las principales diferencias en la sintaxis de CREATE AUDIT para la auditoría en Azure Blob Storage son:

  • Se proporciona una nueva sintaxis de TO URL que puede usar para especificar la dirección URL del contenedor de Azure Blob Storage donde se colocarán los archivos .xel.
  • La sintaxis TO FILE no se admite porque la Instancia administrada de SQL no puede acceder a los recursos compartidos de archivos de Windows.

Para más información, consulte:

Certificados

Una Instancia administrada de SQL no puede acceder a los recursos compartidos de archivos ni a las carpetas de Windows, por lo que se aplican las siguientes restricciones:

  • El archivo CREATE FROM/BACKUP TO no se admite para certificados.
  • No se admite el certificado CREATE/BACKUP de FILE/ASSEMBLY. No se pueden usar archivos de clave privada.

Consulte CREATE CERTIFICATE y BACKUP CERTIFICATE.

Solución alternativa: En lugar de crear una copia de seguridad del certificado y restaurar la copia de seguridad, obtenga el contenido binario del certificado y la clave privada, almacénelo como archivo .sql y cree a partir del binario:

CREATE CERTIFICATE  
   FROM BINARY = asn_encoded_certificate
WITH PRIVATE KEY (<private_key_options>)

Credential:

Solo se admiten identidades de Azure Key Vault y SHARED ACCESS SIGNATURE. No se admiten usuarios de Windows.

Consulte CREATE CREDENTIAL y ALTER CREDENTIAL.

Proveedores de servicios criptográficos

Una Instancia administrada de SQL no puede acceder a archivos, por lo que no se pueden crear proveedores de servicios criptográficos:

Inicios de sesión y usuarios

  • Se admiten los inicios de sesión de SQL creados con FROM CERTIFICATE, FROM ASYMMETRIC KEY y FROM SID. Consulte CREATE LOGIN.

  • Se admiten las entidades de seguridad (inicios de sesión) del servidor de Azure Active Directory (Azure AD) creadas con la sintaxis CREATE LOGIN o la sintaxis CREATE USER FROM LOGIN [Azure AD Login]. Estos inicios de sesión se crean en el nivel de servidor.

    La Instancia administrada de SQL admite las entidades de seguridad de la base de datos de Azure AD con la sintaxis CREATE USER [AADUser/AAD group] FROM EXTERNAL PROVIDER. Esta característica también se conoce como usuarios de bases de datos independientes de Azure AD.

  • No se admiten los inicios de sesión de Windows creados con la sintaxis CREATE LOGIN ... FROM WINDOWS. Use los usuarios e inicios de sesión de Azure Active Directory.

  • El administrador de Azure AD de la instancia tiene privilegios de administrador sin restricciones.

  • Los usuarios de nivel de base de datos de Azure AD que no son administradores pueden crearse con la sintaxis CREATE USER ... FROM EXTERNAL PROVIDER. Consulte CREATE USER ... FROM EXTERNAL PROVIDER.

  • Las entidades de seguridad (inicios de sesión) del servidor de Azure AD admiten las características SQL en una única Instancia administrada de SQL. No se admiten las características que requieren una interacción entre instancias, con independencia de que se encuentren en el mismo inquilino de Azure AD o en inquilinos diferentes, para los usuarios de Azure AD. Ejemplos de estas características son los siguientes:

    • Replicación transaccional de SQL.
    • Servidor de vínculos.

  • No se admite el establecimiento de un inicio de sesión de Azure AD asignado a un grupo de Azure AD como propietario de la base de datos. Un miembro del grupo de Azure AD puede ser propietario de la base de datos, incluso si el inicio de sesión no se ha creado en la base de datos.

  • Se admite la suplantación de las entidades de seguridad en el nivel de servidor de Azure AD mediante otras entidades de seguridad de Azure AD, como la cláusula EXECUTE AS. Las limitaciones de EXECUTE AS son:

    • No se admite la cláusula EXECUTE AS USER para usuarios de Azure AD cuando el nombre es diferente del nombre de inicio de sesión. Por ejemplo, cuando el usuario se crea mediante la sintaxis CREATE USER [myAadUser] FROM LOGIN [john@contoso.com] y se intenta suplantar la identidad mediante EXEC AS USER = myAadUser. Cuando cree un usuario en USER a partir de una entidad de seguridad (inicio de sesión) de un servidor de Azure AD, especifique un valor de user_name igual que el valor de login_name que se obtiene de LOGIN.

    • Solo las entidades de seguridad (inicios de sesión) a nivel de servidor SQL que forman parte del rol sysadmin pueden ejecutar las siguientes operaciones dirigidas a las entidades de seguridad de Azure AD:

      • EXECUTE AS USER
      • EXECUTE AS LOGIN

    • Para suplantar a un usuario con la instrucción EXECUTE AS, el usuario se debe asignar directamente a la entidad de seguridad (inicio de sesión) del servidor de Azure AD. Los usuarios que son miembros de grupos de Azure AD asignados a entidades de seguridad del servidor de Azure AD no se pueden suplantar eficazmente con la instrucción EXECUTE AS, aunque el autor de la llamada tenga permisos de suplantación en el nombre de usuario especificado.

  • Se admite la exportación e importación de bases de datos con archivos bacpac para usuarios de Azure AD en una Instancia administrada de SQL mediante SSMS V18.4 o una versión posterior o SQLPackage.exe.

    • Se admiten las siguientes configuraciones mediante el uso del archivo bacpac de la base de datos:
      • Exportar o importar una base de datos entre diferentes instancias administradas en el mismo dominio de Azure AD.
      • Exportar una base de datos desde una Instancia administrada de SQL e importarla a SQL Database en el mismo dominio de Azure AD.
      • Exportar una base de datos desde SQL Database e importarla a una Instancia administrada de SQL en el mismo dominio de Azure AD.
      • Exportar una base de datos desde una Instancia administrada de SQL e importarla a SQL Server (versión 2012 o posterior).
        • En esta configuración, todos los usuarios de Azure AD se crean como entidades de seguridad de base de datos de SQL Server (usuarios) sin inicios de sesión. El tipo de usuarios se muestra como SQL y es visible como SQL_USER en sys.database_principals). Sus permisos y roles se conservan en los metadatos de la base de datos de SQL Server y se pueden usar para la suplantación. Sin embargo, no se pueden usar para obtener acceso e iniciar sesión en SQL Server con sus credenciales.

  • Solo el inicio de sesión de la entidad de seguridad a nivel de servidor (el que crea el proceso de aprovisionamiento de la Instancia administrada de SQL), los miembros de los roles de servidor, como securityadmin o sysadmin, u otros inicios de sesión con permiso ALTER ANY LOGIN en el nivel de servidor pueden crear entidades de seguridad (inicios de sesión) de servidor de Azure AD en la base de datos maestra para la Instancia administrada de SQL.

  • Si el inicio de sesión es una entidad de seguridad de SQL, solo los inicios de sesión que forman parte del rol sysadmin pueden utilizar el comando create para crear inicios de sesión para una cuenta de Azure AD.

  • El inicio de sesión de Azure AD debe ser miembro de una instancia de Azure AD dentro del mismo directorio que se usa para la Instancia administrada de Azure SQL.

  • Las entidades de seguridad (inicio de sesión) del servidor de Azure AD son visibles en el explorador de objetos a partir de la versión preliminar 5 de SQL Server Management Studio 18.0.

  • Una entidad de seguridad de servidor con el nivel de acceso sysadmin se crea automáticamente para la cuenta de administrador de Azure AD una vez habilitada en una instancia.

  • Durante la autenticación, se aplica la siguiente secuencia para resolver la entidad de seguridad de autenticación:

    1. Si la cuenta de Azure AD existe como directamente asignada a la entidad de seguridad (inicio de sesión) del servidor de Azure AD que está presente en sys.server_principals como tipo "E", conceda acceso y aplique los permisos de la entidad de seguridad (inicio de sesión) del servidor de Azure AD.
    2. Si la cuenta de Azure AD es un miembro de un grupo de Azure AD que está asignado a la entidad de seguridad (inicio de sesión) del servidor de Azure AD (presente en sys.server_principals como tipo "X"), conceda acceso y aplique los permisos del inicio de sesión del grupo de Azure AD.
    3. Si la cuenta de Azure AD existe como directamente asignada a un usuario de Azure AD de una base de datos, presente en sys.database_principals como tipo "E", conceda acceso y aplique los permisos del usuario de la base de datos de Azure AD.
    4. Si la cuenta de Azure AD es un miembro de un grupo de Azure AD que está asignado a un usuario de Azure AD de una base de datos, presente en sys.database_principals como tipo "X", conceda acceso y aplique los permisos del usuario del grupo de Azure AD.

Clave maestra de servicio y clave de servicio

Configuración

Extensión del grupo de búferes

Intercalación

La intercalación de la instancia predeterminada es SQL_Latin1_General_CP1_CI_AS y puede especificarse como un parámetro de creación. Consulte Intercalaciones.

Niveles de compatibilidad

  • Los niveles de compatibilidad admitidos son 100, 110, 120, 130, 140 y 150.
  • No se admiten los niveles de compatibilidad menores que 100.
  • El nivel de compatibilidad predeterminado es 140 para las bases de datos nuevas. Para las bases de datos restauradas, el nivel de compatibilidad no cambiará si era 100 o superior.

Consulte Nivel de compatibilidad de ALTER DATABASE.

Creación de reflejo de la base de datos

No se admite la creación de reflejo de la base de datos.

  • Las opciones ALTER DATABASE SET PARTNER y SET WITNESS no se admiten.
  • CREATE ENDPOINT … FOR DATABASE_MIRRORING no se admite.

Para más información, consulte ALTER DATABASE SET PARTNER y SET WITNESS y CREATE ENDPOINT … FOR DATABASE_MIRRORING.

Opciones de base de datos

  • No se permite usar varios archivos de registro.
  • No se admiten objetos en memoria caché en el nivel de servicio de uso general.
  • Hay un límite de 280 archivos por instancia de uso general, lo cual implica un máximo de 280 archivos por base de datos. Los datos y archivos de registro en el nivel de uso general cuentan para este límite. El nivel Crítico para la empresa admite 32 767 archivos por base de datos.
  • La base de datos no puede contener grupos de archivos que contengan datos de secuencia de archivos. Se producirá un error en la restauración si el archivo .bak contiene datos FILESTREAM.
  • Todos los archivos se colocan en Azure Blob Storage. La E/S y el rendimiento por archivo dependen del tamaño de cada archivo individual.

Instrucción CREATE DATABASE

Se aplican las siguientes limitaciones a CREATE DATABASE:

  • No se pueden definir archivos y grupos de archivos.

  • La opción CONTAINMENT no se admite.

  • Las opciones WITH no se admiten.

    Sugerencia

    Como alternativa, use ALTER DATABASE después de CREATE DATABASE para establecer las opciones de la base de datos para agregar archivos o establecer el contenedor.

  • La opción FOR ATTACH no se admite.

  • La opción AS SNAPSHOT OF no se admite.

Para más información, consulte CREATE DATABASE.

instrucción ALTER DATABASE

Algunas propiedades de archivo no se pueden establecer ni cambiar:

  • No se puede especificar una ruta de acceso del archivo en la instrucción T-SQL ALTER DATABASE ADD FILE (FILENAME='path'). Quite FILENAME del script porque una Instancia administrada de SQL coloca automáticamente los archivos.
  • El nombre del archivo no se puede cambiar mediante la instrucción ALTER DATABASE.

Las siguientes opciones se establecen de forma predeterminada y no se pueden cambiar:

  • MULTI_USER
  • ENABLE_BROKER
  • AUTO_CLOSE OFF

Las opciones siguientes no se pueden modificar:

  • AUTO_CLOSE
  • AUTOMATIC_TUNING(CREATE_INDEX=ON|OFF)
  • AUTOMATIC_TUNING(DROP_INDEX=ON|OFF)
  • DISABLE_BROKER
  • EMERGENCY
  • ENABLE_BROKER
  • FILESTREAM
  • HADR
  • NEW_BROKER
  • OFFLINE
  • PAGE_VERIFY
  • PARTNER
  • READ_ONLY
  • RECOVERY BULK_LOGGED
  • RECOVERY_SIMPLE
  • REMOTE_DATA_ARCHIVE
  • RESTRICTED_USER
  • SINGLE_USER
  • WITNESS

Es posible que algunas instrucciones ALTER DATABASE (por ejemplo, SET CONTAINMENT) no se puedan realizar de forma transitoria, por ejemplo, durante la copia de seguridad automatizada o justo después de crear una base de datos. En este caso, la instrucción ALTER DATABASE debe volver a intentarse. Para obtener más información sobre los mensajes de error relacionados, consulte la sección Comentarios.

Para más información, consulte ALTER DATABASE.

Agente SQL Server

  • La habilitación o deshabilitación del Agente SQL Server no se admite actualmente en la Instancia administrada de SQL. El Agente SQL se ejecuta de forma continua.
  • No se admite el desencadenador de programación de trabajos basado en una CPU inactiva.
  • La configuración del Agente SQL Server es de solo lectura. El procedimiento sp_set_agent_properties no se admite en la Instancia administrada de SQL.
  • Trabajos
    • Se admiten los pasos de trabajo de T-SQL.
    • Se admiten los siguientes trabajos de replicación:
      • Lector del registro de transacciones
      • Instantánea
      • Distribuidor.
    • Se admiten los pasos de trabajo de SSIS.
    • Actualmente no se admiten estos otros tipos de pasos de trabajo:
      • No se admite el paso de trabajo de replicación de mezcla.
      • No se admite el lector de colas.
      • Aún no se admite el shell de comandos.
    • La Instancia administrada de SQL no puede acceder a los recursos externos como, por ejemplo, a los recursos compartidos de red a través de robocopy.
    • No se admite SQL Server Analysis Services.
  • Las notificaciones se admiten parcialmente.
  • Se admite la notificación por correo electrónico, aunque es necesario configurar un perfil de Correo electrónico de base de datos. Agente SQL Server solo puede usar un perfil de Correo electrónico de base de datos y se debe llamar AzureManagedInstance_dbmail_profile.
    • El buscapersonas no se admite.
    • No se admite NetSend.
    • Aún no se admiten las alertas.
    • No se admiten los servidores proxy.
  • No se admite EventLog.
  • El usuario debe estar asignado directamente a la entidad de seguridad del servidor (inicio de sesión) de Azure AD para crear, modificar o ejecutar trabajos del Agente SQL. Los usuarios que no estén directamente asignados, por ejemplo, los que pertenezcan a un grupo de Azure AD que tenga derechos para crear, modificar o ejecutar trabajos del Agente SQL, no podrán realizar estas acciones de forma eficaz. Esto se debe a la suplantación de Instancia administrada y las limitaciones de EXECUTE AS.
  • No se admite la característica de administración multiservidor para los trabajos de maestro y destino (MSX/TSX).

Para más información acerca del Agente SQL Server, consulte Agente SQL Server.

Tablas

No se admiten los siguientes tipos de tablas:

Para más información sobre cómo crear y modificar tablas, consulte CREATE TABLE y ALTER TABLE.

Funcionalidades

BULK INSERT/OPENROWSET

Una Instancia administrada de SQL no puede acceder a los recursos compartidos de archivos ni carpetas de Windows, por lo que los archivos se deben importar desde Azure Blob Storage:

  • DATASOURCE es necesario en el comando BULK INSERT durante la importación de archivos desde Azure Blob Storage. Consulte BULK INSERT.
  • DATASOURCE se necesita en la función OPENROWSET cuando se lee el contenido de un archivo desde Azure Blob Storage. Consulte OPENROWSET.
  • OPENROWSET se puede usar para leer datos de Azure SQL Database, Instancia administrada de Azure SQL o instancias de SQL Server. No se admiten otros orígenes, como bases de datos de Oracle o archivos de Excel.

CLR

Una Instancia administrada de SQL no puede acceder a los recursos compartidos de archivos ni a las carpetas de Windows, por lo que se aplican las siguientes restricciones:

Correo electrónico de base de datos: (db_mail)

  • sp_send_dbmail no puede enviar datos adjuntos con el parámetro @file_attachments. El sistema de archivos local y los recursos compartidos externos, o Azure Blob Storage, no son accesibles con este procedimiento.
  • Vea los problemas conocidos relacionados con el parámetro @query y la autenticación.

DBCC

La Instancia administrada de SQL no admite instrucciones DBCC no documentadas que estén habilitadas en SQL Server.

  • Solo se admite un número limitado de marcas de seguimiento globales. No se admiten las Trace flags en el nivel de sesión. Consulte Marcas de seguimiento.
  • DBCC TRACEOFF y DBCC TRACEON funcionan con el número limitado de marcas trace-flags globales.
  • No se puede usar DBCC CHECKDB con las opciones REPAIR_ALLOW_DATA_LOSS, REPAIR_FAST y REPAIR_REBUILD porque la base de datos no se puede establecer en el modo SINGLE_USER. Consulte las diferencias de ALTER DATABASE. El equipo de soporte técnico de Azure se encarga de los posibles daños en la base de datos. Póngase en contacto con el soporte técnico de Azure si hay algún signo de daños en la base de datos.

Distributed transactions

La compatibilidad parcial con las transacciones distribuidas está actualmente en versión preliminar pública. Las transacciones distribuidas se admiten en las siguientes condiciones (se deben cumplir todas):

  • todos los participantes son instancias de Azure SQL Managed Instance que forman parte del grupo de confianza de servidor.
  • las transacciones se inician desde .NET (clase TransactionScope) o Transact-SQL.

Actualmente, Azure SQL Managed Instance no admite otros escenarios que se admiten con regularidad en el Coordinador de transacciones distribuidas local o en Azure Virtual Machines.

Eventos extendidos

No se admiten algunos destinos específicos de Windows para Extended Events (XEvents):

  • No se admite el destino etw_classic_sync. Almacene los archivos .xel en Azure Blob Storage. Consulte Destino etw_classic_sync.
  • No se admite el destino event_file. Almacene los archivos .xel en Azure Blob Storage. Consulte Destino event_file.

Bibliotecas externas

Las bibliotecas externas de R y Python en base de datos se admiten en la versión preliminar pública limitada. Consulte Machine Learning Services de Azure SQL Managed Instance (versión preliminar).

FileStream y FileTable

  • No se admiten datos de secuencia de archivos.
  • La base de datos no puede contener grupos de archivos con datos FILESTREAM.
  • FILETABLE no se admite.
  • Las tablas no pueden tener tipos FILESTREAM.
  • No se admiten las siguientes funciones:
    • GetPathLocator()
    • GET_FILESTREAM_TRANSACTION_CONTEXT()
    • PathName()
    • GetFileNamespacePat)
    • FileTableRootPath()

Para más información, consulte FILESTREAM y FileTables.

Búsqueda semántica de texto completo

No se admite la búsqueda semántica.

Servidores vinculados

Los servidores vinculados en SQL Managed Instance admiten un número limitado de destinos:

  • Los destinos admitidos son SQL Managed Instance, SQL Database, grupos de Azure Synapse SQL sin servidor y dedicados e instancias de SQL Server.
  • Las transacciones de escritura distribuidas solo son posibles entre instancias administradas. Vea Transacciones distribuidas para obtener más información. Sin embargo, no se admite MS DTC.
  • Destinos no admitidos: archivos, Analysis Services y otros RDBMS. Intente usar la importación de CSV nativa desde Azure Blob Storage mediante BULK INSERT o OPENROWSET como alternativa para la importación de archivos, o cargue los archivos mediante un grupo de SQL sin servidor en Azure Synapse Analytics.

Operaciones:

  • Las transacciones de escritura entre instancias solo se admiten para las instancias administradas.
  • Se admite sp_dropserver para quitar un servidor vinculado. Consulte sp_dropserver.
  • La función OPENROWSET se puede usar para ejecutar consultas solo en instancias de SQL Server. Se pueden administrar de forma local o en máquinas virtuales. Consulte OPENROWSET.
  • La función OPENDATASOURCE se puede usar para ejecutar consultas solo en instancias de SQL Server. Se pueden administrar de forma local o en máquinas virtuales. Solo se admiten los valores SQLNCLI, SQLNCLI11 y SQLOLEDB como proveedor. Un ejemplo es SELECT * FROM OPENDATASOURCE('SQLNCLI', '...').AdventureWorks2012.HumanResources.Employee. Consulte OPENDATASOURCE.
  • Los servidores vinculados no se pueden usar para leer archivos (Excel y CSV) de los recursos compartidos de red. Intente usar BULK INSERT, OPENROWSET que lee los archivos CSV de Azure Blob Storage o un servidor vinculado que hace referencia a un grupo de SQL sin servidor en Synapse Analytics. Realice un seguimiento de estas solicitudes en el elemento de comentarios de la Instancia administrada de SQL|.

Los servidores vinculados de Azure SQL Managed Instance admiten tanto la autenticación de SQL como la autenticación de AAD.

PolyBase

El trabajo para habilitar la compatibilidad con PolyBase en SQL Managed Instance está en curso. Mientras tanto, como solución alternativa, puede usar servidores vinculados a un grupo de SQL sin servidor en Synapse Analytics o a SQL Server para consultar datos de archivos almacenados en Azure Data Lake o Azure Storage.
Para obtener información general acerca de PolyBase, consulte PolyBase.

Replicación

  • Se admiten los tipos de replicación de instantánea y bidireccional. No se admite la replicación de mezcla, la replicación punto a punto y las suscripciones actualizables.
  • La replicación transaccional está disponible para la versión preliminar pública en la Instancia administrada de SQL con algunas restricciones:
    • Todos los tipos de participantes de la replicación (editor, distribuidor, suscriptor de extracción y suscriptor de inserción) se pueden colocar en una Instancia administrada de SQL, pero el editor y el distribuidor deben estar tanto en la nube como en el entorno local.
    • La Instancia administrada de SQL puede comunicarse con las versiones recientes de SQL Server. Para obtener más información, consulte la matriz de versiones compatibles.
    • La replicación transaccional tiene algunos requisitos de red adicionales.

Para obtener más información sobre la configuración de la replicación transaccional, vea los siguientes tutoriales:

Instrucción RESTORE

  • Sintaxis admitida:
    • RESTORE DATABASE
    • RESTORE FILELISTONLY ONLY
    • RESTORE HEADER ONLY
    • RESTORE LABELONLY ONLY
    • RESTORE VERIFYONLY ONLY
  • Sintaxis no admitida:
    • RESTORE LOG ONLY
    • RESTORE REWINDONLY ONLY
  • Origen:
    • La única opción admitida es FROM URL (Azure Blob Storage).
    • No se admite FROM DISK/TAPE/dispositivo de copia de seguridad.
    • No se admiten los conjuntos de copia de seguridad.
  • Las opciones WITH no se admiten. Los intentos de restauración que incluyan WITH, como DIFFERENTIAL, STATS, REPLACE, etc., generarán errores.
  • ASYNC RESTORE: la restauración continúa aunque se interrumpa la conexión con el cliente. Si la conexión se interrumpe, puede usar sys.dm_operation_status para ver el estado de una operación de restauración y para crear y eliminar una base de datos. Consulte sys.dm_operation_status.

Las siguientes opciones de base de datos se establecen o invalidan, y no se pueden cambiar más adelante:

  • NEW_BROKER si el agente no está habilitado en el archivo .bak.
  • ENABLE_BROKER si el agente no está habilitado en el archivo .bak.
  • AUTO_CLOSE=OFF si una base de datos en el archivo .bak tiene AUTO_CLOSE=ON.
  • RECOVERY FULL si una base de datos en el archivo .bak tiene los modos de recuperación SIMPLE o BULK_LOGGED.
  • Se agrega un grupo de archivos optimizado para memoria y se le asigna el nombre XTP si aún no se encuentra en el archivo .bak de origen.
  • Se cambia el nombre de todos los grupos de archivos optimizados para memoria existentes a XTP.
  • Las opciones SINGLE_USER y RESTRICTED_USER se convierten en MULTI_USER.

Limitaciones:

  • Las copias de seguridad de las bases de datos dañadas pueden restaurarse en función del tipo de daños, pero no se realizarán copias de seguridad automatizadas mientras no se corrija el daño. Asegúrese de ejecutar DBCC CHECKDB en la Instancia administrada de SQL de origen y de usar la copia de seguridad WITH CHECKSUM para evitar este problema.
  • La restauración de un archivo .BAK de una base de datos que contenga alguna de las limitaciones descritas en este documento (por ejemplo, objetos FILESTREAM o FILETABLE) no se puede llevar a cabo en la Instancia administrada de SQL.
  • Los archivos .BAK que contienen varios conjuntos de copia de seguridad no se pueden restaurar.
  • Los archivos .BAK que contienen varios archivos de registro no se pueden restaurar.
  • Las copias de seguridad que contienen bases de datos con un tamaño superior a 8 TB, objetos OLTP en memoria activos o una cantidad de archivos superior a 280 por instancia no se pueden restaurar en una instancia de Uso general.
  • Las copias de seguridad que contienen bases de datos con un tamaño superior a 4 TB u objetos OLTP en memoria con un tamaño total superior al descrito en los límites de recursos no se pueden restaurar en una instancia de tipo Crítico para la empresa. Para más información acerca de las instrucciones Restore, consulte Instrucciones RESTORE.

Importante

Las mismas limitaciones se aplican a una operación de restauración a un momento dado integrada. Por ejemplo, no es posible restaurar una base de datos de Uso general de más de 4 TB en una instancia de tipo Crítico para la empresa. Una base de datos de tipo Crítico para la empresa con archivos OLTP en memoria o más de 280 archivos no se puede restaurar en la instancia de Uso general.

Service Broker

El intercambio de mensajes de Service Broker entre instancias solo se admite entre instancias de Azure SQL Managed Instance:

  • CREATE ROUTE: no puede usar CREATE ROUTE con ADDRESS que no sea LOCAL o el nombre DNS de otra instancia de SQL Managed Instance. El puerto siempre es 4022.
  • ALTER ROUTE: no puede usar ALTER ROUTE con ADDRESS que no sea LOCAL o el nombre DNS de otra instancia de SQL Managed Instance. El puerto siempre es 4022.

Se admite la seguridad de transporte, pero no la seguridad de diálogo:

  • No se admite CREATE REMOTE SERVICE BINDING.

Service Broker está habilitado de forma predeterminada y no se puede deshabilitar. No se admiten las siguientes opciones de ALTER DATABASE:

  • ENABLE_BROKER
  • DISABLE_BROKER

Procedimientos almacenados, funciones y desencadenadores

  • NATIVE_COMPILATION no se admite en el nivel De uso general.
  • No se admiten las siguientes opciones de sp_configure:
    • allow polybase export
    • allow updates
    • filestream_access_level
    • remote access
    • remote data archive
    • remote proc trans
    • scan for startup procs
  • Las siguientes opciones de sp_configure se omiten y no tienen ningún efecto:
    • Ole Automation Procedures
  • sp_execute_external_scripts no se admite. Consulte sp_execute_external_scripts.
  • xp_cmdshell no se admite. Consulte xp_cmdshell.
  • Extended stored procedures no se admiten, esto incluye sp_addextendedproc y sp_dropextendedproc. Esta funcionalidad no se admitirá porque está en una ruta en desuso para SQL Server. Para obtener más información, consulte Procedimientos almacenados extendidos.
  • No se admiten sp_attach_db, sp_attach_single_file_db, y sp_detach_db. Consulte sp_attach_db, sp_attach_single_file_db, y sp_detach_db.

Variables y funciones del sistema

Las siguientes variables, funciones y vistas devuelven resultados diferentes:

  • SERVERPROPERTY('EngineEdition') devuelve el valor 8. Esta propiedad identifica de forma única una Instancia administrada de SQL. Consulte SERVERPROPERTY.
  • SERVERPROPERTY('InstanceName') devuelve NULL, porque el concepto de instancia tal y como existe para SQL Server no se aplica a una Instancia administrada de SQL. Consulte SERVERPROPERTY('InstanceName').
  • @@SERVERNAME devuelve el nombre DNS completo "conectable", por ejemplo, my-managed-instance.wcus17662feb9ce98.database.windows.net. Consulte @@SERVERNAME.
  • SYS.SERVERS devuelve un nombre DNS completo "conectable", por ejemplo, myinstance.domain.database.windows.net, para las propiedades "name" y "data_source". Consulte SYS.SERVERS.
  • @@SERVICENAME devuelve NULL, porque el concepto de servicio tal y como existe para SQL Server no se aplica a una Instancia administrada de SQL. Consulte @@SERVICENAME.
  • SUSER_ID es compatible. Devuelve NULL si el inicio de sesión de Azure AD no está en sys.syslogins. Consulte SUSER_ID.
  • SUSER_SID no se admite. Se devuelven los datos incorrectos, lo cual es un problema temporal conocido. Consulte SUSER_SID.

Restricciones del entorno

Subnet

  • No se puede colocar ningún otro recurso (por ejemplo, máquinas virtuales) en la subred en la que ha implementado la Instancia administrada de SQL. Implemente estos recursos con una subred diferente.
  • La subred debe tener un número de direcciones IP disponibles suficiente. El mínimo es tener al menos 32 direcciones IP en la subred.
  • El número de núcleos virtuales y tipos de instancias que se pueden implementar en una región tiene algunas restricciones y límites.
  • Hay una configuración de red que se debe aplicar en la subred.

VNET

  • La red virtual se puede implementar mediante el modelo con Resource Manager. No se admite el modelo clásico.
  • Después de crear una Instancia administrada de SQL, no se admite el traslado de dicha Instancia administrada de SQL o la red virtual a otro grupo de recursos o suscripción.
  • En el caso de las instancias administradas de SQL hospedadas en clústeres virtuales que se crean antes del 22/9/2020, el emparejamiento global no se admite. Se puede conectar a estos recursos a través de ExpressRoute o de red virtual a red virtual a través de puertas de enlace de red virtuales.

Grupos de conmutación por error

Las bases de datos del sistema no se replican en la instancia secundaria de un grupo de conmutación por error. Por lo tanto, los escenarios que dependen de objetos de las bases de datos del sistema serán imposibles en la instancia secundaria, a menos que los objetos se creen manualmente en la secundaria.

TEMPDB

  • El tamaño máximo del archivo tempdb no puede ser mayor de 24 GB por núcleo en un nivel De uso general. El tamaño máximo de tempdb en un nivel Crítico para la empresa está limitado por el tamaño de almacenamiento de la Instancia administrada de SQL. El tamaño del archivo de registro Tempdb está limitado a 120 GB en el nivel de uso general. Algunas consultas podrían devolver un error si necesitan más de 24 GB por núcleo en tempdb o si producen datos de registro superiores a 120 GB.
  • Tempdb siempre se divide en 12 archivos de datos: 1 principal, también denominado archivo de datos principal, y 11 archivos de datos no principales. La estructura de archivos no se puede modificar y los archivos nuevos no se pueden agregar a tempdb.
  • Los metadatos tempdb optimizados para memoria, una característica nueva de base de datos en memoria de SQL Server 2019, no son compatibles.
  • Los objetos creados en la base de datos modelo no se pueden crear automáticamente en tempdb después de un reinicio o una conmutación por error, porque tempdb no obtiene su lista de objetos inicial de la base de datos modelo. Debe crear los objetos en tempdb manualmente después de cada reinicio o de una conmutación por error.

MSDB

Los siguientes esquemas MSDB de la Instancia administrada de SQL deben ser propiedad de sus respectivos roles predefinidos:

Importante

El cambio de los nombres de roles predefinidos, los nombres de esquema y los propietarios de esquemas por parte de los clientes afectará al funcionamiento normal del servicio. Los cambios que se realicen en estos se revertirán a los valores predefinidos en cuanto se detecten, o bien en la siguiente actualización del servicio en la última para garantizar el funcionamiento normal del servicio.

Registros de error

Una Instancia administrada de SQL coloca información detallada en los registros de errores. Existen muchos eventos internos del sistema que se archivan en el registro de errores. use un procedimiento personalizado para leer los registros de errores que filtran algunas entradas que no son pertinentes. Para obtener más información, vea Instancia administrada de SQL – sp_readmierrorlog o Extensión de Instancia administrada de SQL (versión preliminar) para Azure Data Studio.

Pasos siguientes