Diferencias de T-SQL entre SQL Server y Azure SQL Managed Instance

  • Artículo

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.

Diagram showing the easy migration from 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.

Nota:

Microsoft Entra ID era conocido anteriormente como Azure Active Directory (Azure AD).

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

Azure SQL Managed Instance 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.
    • No se admiteFILE_SNAPSHOT ni CREDENTIAL .
    • 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 SQL Managed Instance solo se pueden restaurar en una instancia de SQL Server 2022. Esto se debe a que SQL Managed Instance tiene una versión de base de datos interna superior en comparación con otras versiones de SQL Server. Para obtener más información, consulte Restauración de una copia de seguridad de base de datos de SQL Managed Instance en SQL Server 2022.

  • Para crear una copia de seguridad de una base de datos de un almacenamiento de Azure o restaurarla desde allí, se puede realizar la autenticación mediante una identidad administrada o una firma de acceso compartido (SAS), que es un identificador URI que le concede derechos de acceso restringido 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 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 identidad administrada, 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. Las entidades de seguridad de servidor (inicios de sesión) se crean en el nivel de servidor y los usuarios (entidades de seguridad de base de datos) se crean en el nivel de base de datos. Se admiten los inicios de sesión de Microsoft Entra creados con la sintaxis CREATE LOGIN y los usuarios de Microsoft Entra creados con la sintaxis CREATE USER FROM LOGIN. Al crear un usuario y especificar FROM LOGIN, ese usuario se asocia al inicio de sesión y hereda los roles de servidor y los permisos que se le asignen.

    SQL Managed Instance admite la creación de usuarios de base de datos independientes en función de identidades de Microsoft Entra con la sintaxis CREATE USER [AADUser/AAD group] FROM EXTERNAL PROVIDER. Los usuarios creados de esta manera no están asociados a entidades de seguridad de servidor, incluso si existe una entidad de seguridad de servidor con el mismo nombre en la base de datos master.

  • No se admiten los inicios de sesión de Windows creados con la sintaxis CREATE LOGIN ... FROM WINDOWS. Use inicios de sesión y usuarios de Microsoft Entra.

  • El administrador de Microsoft Entra de la instancia tiene privilegios de administrador sin restricciones.

  • Algunas características no admiten el uso de inicios de sesión de Microsoft Entra en interacciones entre instancias, sino solo dentro de una sola instancia de SQL Managed Instance, como la replicación de SQL Server, por ejemplo. Pero la característica de servidor vinculado admite la autenticación entre instancias mediante entidades de seguridad (inicios de sesión) del servidor de Microsoft Entra.

  • No se admite establecer un inicio de sesión de Microsoft Entra asignado a un grupo de Microsoft Entra como propietario de la base de datos. Un miembro del grupo de Microsoft Entra 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 Microsoft Entra mediante otras entidades de seguridad de Microsoft Entra, como la cláusula EXECUTE AS. Las limitaciones de EXECUTE AS son:

    • No se admite la cláusula EXECUTE AS USER para usuarios de Microsoft Entra 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 una instancia de USER a partir de un inicio de sesión de Microsoft Entra, especifique el nombre de usuario como el mismo nombre de inicio de sesión desde LOGIN.

    • Solo los inicios de sesión de nivel de SQL Server que forman parte del rol sysadmin pueden ejecutar las siguientes operaciones dirigidas a las entidades de seguridad de Microsoft Entra:

      • EXECUTE AS USER
      • EXECUTE AS LOGIN

    • Para suplantar a un usuario con la instrucción EXECUTE AS, el usuario se debe asignar directamente al inicio de sesión de Microsoft Entra. Los usuarios que son miembros de grupos de Microsoft Entra asignados a entidades de seguridad de servidor de Microsoft Entra 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 Microsoft Entra en SQL Managed Instance mediante SSMS V18.4 o una versión posterior o SqlPackage.

    • Se admiten las siguientes configuraciones mediante el uso del archivo bacpac de base de datos:
      • Exportar o importar una base de datos entre diferentes instancias administradas en el mismo dominio de Microsoft Entra.
      • Exportar una base de datos desde una instancia administrada de SQL e importarla a SQL Database en el mismo dominio de Microsoft Entra.
      • Exportar una base de datos desde SQL Database e importarla a una instancia administrada de SQL en el mismo dominio de Microsoft Entra.
      • 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 Microsoft Entra se crean como entidades de seguridad de base de datos de SQL Server (usuarios) sin inicios de sesión. El tipo de usuarios es 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. Pero no se pueden usar para acceder e iniciar sesión en SQL Server con sus credenciales.

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

  • A los inicios de sesión basados en autenticación de SQL se les debe asignar el rol sysadmin a fin de crear inicios de sesión para identidades de Microsoft Entra.

  • El inicio de sesión debe ser miembro del mismo inquilino de Microsoft Entra en el que se hospeda la instancia de Azure SQL Managed Instance.

  • Las entidades de seguridad (inicios de sesión) de servidor de Microsoft Entra 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 el administrador de Microsoft Entra una vez que se habilita 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 Microsoft Entra se asigna directamente a un inicio de sesión de Microsoft Entra, que está presente en sys.server_principals como tipo "E", conceda acceso y aplique permisos de ese inicio de sesión.
    2. Si la cuenta de Microsoft Entra es miembro de un grupo que se asigna a un inicio de sesión de Microsoft Entra, que está presente en sys.server_principals como tipo "X", conceda acceso y aplique permisos de ese inicio de sesión.
    3. Si la cuenta de Microsoft Entra existe como directamente asignada a un usuario de Microsoft Entra de una base de datos, presente en sys.database_principals como tipo "E", conceda acceso y aplique los permisos del usuario de base de datos de Microsoft Entra.
    4. Si la cuenta de Microsoft Entra es miembro de un grupo de Microsoft Entra asignado a un usuario de Microsoft Entra de una base de datos, presente en sys.database_principals como tipo "X", conceda acceso y aplique los permisos del usuario del grupo de Microsoft Entra.

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, 150 y 160.
  • No se admiten los niveles de compatibilidad menores que 100.
  • El nivel de compatibilidad predeterminado es 150 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 FILESTREAM. Se produce un error en la restauración si .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.

  • Se agregan automáticamente un grupo de archivos y un archivo optimizados para memoria y se denominan XTP.

  • 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.
  • No se permite modificar el archivo XTP ni el grupo de archivos.

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 al inicio de sesión del servidor de Microsoft Entra 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 Microsoft Entra 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 SQL Managed Instance 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; vea 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

Las transacciones distribuidas basadas en T-SQL y .NET entre instancias administradas están disponibles con carácter general. Otros escenarios, como transacciones XA, transacciones distribuidas entre instancias administradas y otros participantes, etc., se admiten con DTC para Azure SQL Managed Instance, que está disponible en versión preliminar pública.

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 FILESTREAM.
  • 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.
  • 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:

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

PolyBase

La virtualización de datos con Azure SQL Managed Instance permite ejecutar consultas de Transact-SQL (T-SQL) en datos de archivos almacenados en Azure Data Lake Storage Gen2 o Azure Blob Storage, y combinarlos con datos relacionales almacenados localmente mediante combinaciones. 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. Use JSON_VALUE y OPENJSON para analizar aún más las filas. Para obtener información general acerca de PolyBase, consulte PolyBase.

Además, CREATE EXTERNAL TABLE AS SELECT (CETAS) le permite exportar datos de la instancia administrada de SQL a una cuenta de almacenamiento externa. Puede usar CETAS para crear una tabla externa a partir de archivos Parquet o CSV en Azure Blob Storage o Azure Data Lake Storage (ADLS) Gen2. CETAS también puede exportar, en paralelo, los resultados de una instrucción SELECT de T-SQL en la tabla externa creada.

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 SQL Managed Instance 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 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
    • RESTORE HEADERONLY
    • RESTORE LABELONLY
    • RESTORE VERIFYONLY
  • Sintaxis no admitida:
    • RESTORE LOGONLY
    • RESTORE REWINDONLY
  • 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.

Una operación de restauración de base de datos es asincrónica y se puede reintentar en Azure SQL Managed Instance. Es posible que se genere un error en SSMS si se produce un error en la conexión o si expira el tiempo de espera. Azure SQL Managed Instance seguirá intentando restaurar la base de datos en segundo plano y se podrá realizar un seguimiento del progreso de la restauración mediante las vistas sys.dm_exec_requests y sys.dm_operation_status de administración dinámica.

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 el modelo 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 realizan 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 SQL Managed Instance.
  • 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:

  • CREATE REMOTE SERVICE BINDING no se admite.

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 se admite solo para Machine Learning Services para SQL MI; de lo contrario, sp_execute_external_scripts no se admite para SQL Managed Instance. 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, vea 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 un 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 Microsoft Entra 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 SQL Managed Instance. 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.

Red virtual

  • La red virtual se puede implementar mediante el modelo de recursos. El modelo clásico no admite la implementación de red virtual.
  • Después de crear una instancia de SQL Managed Instance, no se admite el traslado de esa instancia o la red virtual a otro grupo de recursos o suscripción.
  • En el caso de las instancias de SQL Managed Instance hospedadas en clústeres virtuales creados antes del 22 de septiembre de 2020, no se admite el emparejamiento global de redes virtuales. 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 son imposibles en la instancia secundaria, a menos que los objetos se creen manualmente en la secundaria.

tempdb

  • El tamaño máximo del archivo de la base de datos del sistema de 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 master, 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.
  • Metadatos TempDB optimizados para memoria, una característica nueva de base de datos en memoria de SQL Server 2019, no se admite.
  • Los objetos creados en la base de datos model 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 model. Debe crear los objetos en tempdb manualmente después de cada reinicio o de una conmutación por error.

msdb

Los siguientes esquemas de la base de datos del sistema de msdb en SQL Managed Instance 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.

No se admite cambiar el número de registros de errores retenidos.

Contenido relacionado