Problemas conocidos con Azure SQL Managed Instance

Applies to:Azure SQL Managed Instance

En este artículo se enumeran los problemas conocidos actualmente con Azure SQL Managed Instance y su fecha de resolución o posible solución alternativa. Para obtener más información sobre Azure SQL Managed Instance, consulte ¿Qué es Azure SQL Managed Instance? y ¿Qué novedades de Azure SQL Managed Instance?

Problemas conocidos

Tiene solución alternativa

Errores de operación de restauración después de migrar a SQL Managed Instance

Si migra una base de datos a Azure SQL Managed Instance desde SQL Server 2019 y versiones posteriores con recuperación de base de datos acelerada habilitada, pero configurada con el almacén de versiones persistente (PVS) establecido en algo distinto del grupo de archivos PRIMARY, puede experimentar errores de operación de restauración en la instancia gestionada de SQL de destino.

Para solucionar este problema, asegúrese de establecer el almacén de versiones persistent (PVS) en PRIMARY en la base de datos de SQL Server de origen antes de migrarlo a SQL Managed Instance. Si ya ha migrado la base de datos sin establecer el PVS en PRIMARY, puede establecerla en la base de datos de SQL Server de origen y, a continuación, volver a migrar la base de datos a SQL Managed Instance.

No se puede usar la recuperación acelerada de bases de datos después de migrar a SQL Managed Instance

A partir de SQL Server 2019, si migra una base de datos a Azure SQL Managed Instance y la base de datos de origen tiene recuperación de base de datos sincronizada deshabilitada, no puede usar la recuperación acelerada de bases de datos en la instancia administrada de SQL de destino.

Para solucionar este problema, asegúrese de enable recuperación acelerada de la base de datos en la base de datos de SQL Server de origen antes de migrarla a SQL Managed Instance. Si ya ha migrado la base de datos sin habilitar la recuperación acelerada de bases de datos, puede habilitarla en la base de datos de origen SQL Server y, a continuación, volver a migrar la base de datos a la instancia administrada de SQL.

SQL Server 2017 y versiones anteriores no admiten la recuperación acelerada de bases de datos, por lo que este problema no se aplica a las bases de datos migradas desde esas versiones de SQL Server.

No se puede usar Service Broker después de migrar a SQL Managed Instance

Si migra una base de datos a Azure SQL Managed Instance y Service Broker está deshabilitado en la base de datos de origen, no puede usar Service Broker en la instancia administrada de SQL de destino.

Para solucionar este problema, asegúrese de habilitar Service Broker en la base de datos de SQL Server de origen antes de migrarla a SQL Managed Instance. Si ya ha migrado la base de datos sin habilitar Service Broker, puede habilitarla en la base de datos de origen SQL Server y, a continuación, volver a migrar la base de datos a SQL Managed Instance.

Modificación del período de retención de copia de seguridad para la oferta gratuita

Solo puede modificar la directiva de retención de copia de seguridad de las bases de datos en la instancia administrada de SQL gratuita mediante REST API, PowerShell y comandos CLI de Azure. No puede modificar la directiva de retención de copia de seguridad a través del portal Azure.

No se pudo iniciar sesión en el secundario de lectura debido a una espera prolongada en "HADR_DATABASE_WAIT_FOR_TRANSITION_TO_VERSIONING"

Es posible que vea este error como una excepción para el Microsoft OLE DB Driver 19 para SQL Server al intentar conectarse a una réplica secundaria de solo lectura de un grupo de conmutación por error o una base de datos replicada a través del enlace de instancia administrada.

Este error se produce cuando la réplica secundaria no está disponible para los inicios de sesión porque faltan versiones de fila para las transacciones que estaban en curso cuando se reinicia o recicla una réplica secundaria, ya sea por mantenimiento o debido a una conmutación por error. Cuando una instancia se reinicia o conmuta por error, se borran los datos de control de versiones almacenados en tempdb. Las consultas de lectura secundarias se anulan si hay transacciones activas de larga duración que se iniciaron antes de la conmutación por error o el reinicio.

Para resolver este problema, revierta o confirme las transacciones activas en la réplica principal. Para evitar este error, minimice las transacciones de escritura de larga duración en la réplica primaria.

Error 8992 al ejecutar DBCC CHECKDB en una base de datos de SQL Server que se originó en SQL Managed Instance

Es posible que vea el siguiente error al ejecutar el comando DBCC CHECKDB en una base de datos SQL Server 2022 después de eliminar un índice o una tabla con un índice, y la base de datos se originó en Azure SQL Managed Instance, como después de restaurar un archivo de copia de seguridad, o desde la característica de vínculo SQL Managed Instance:

Msg 8992, Level 16, State 1, Line <Line_Number>
Check Catalog Msg 3853, State 1: Attribute (%ls) of row (%ls) in sys.sysrowsetrefs does not have a matching row (%ls) in sys.indexes.

Para solucionar el problema, quite primero el índice o la tabla con el índice, de la base de datos de origen en Azure SQL Managed Instance y, a continuación, restaure o vincule la base de datos a SQL Server 2022 de nuevo. Si no es posible volver a crear la base de datos desde el Azure SQL Managed Instance de origen, póngase en contacto con Microsoft soporte técnico para ayudar a resolver este problema.

Error 1412 al crear un vínculo de Instancia administrada

Cuando se crea un vínculo por primera vez, la primera parte del proceso inicializa una copia de seguridad completa de la base de datos desde la réplica principal a la réplica secundaria. Una vez completada la propagación de la copia de seguridad completa, el vínculo comienza a replicar datos aplicando los datos diferenciales de la réplica principal a la réplica secundaria. Este proceso continúa indefinidamente hasta que se emite un comando de conmutación por error o se quita el enlace.

Si se produce una copia de seguridad del registro de transacciones en la réplica principal durante la inicialización de la copia de seguridad completa, el registro de transacciones se trunca. Al crear el vínculo, se produce el error 1412, ya que los datos del registro de transacciones necesarios para la propagación inicial ya no están disponibles.

Si ve el error 1412 en el registro de errores SQL Server en Azure SQL Managed Instance, debe eliminar y volver a crear el enlace. Para evitar este problema de forma preventiva, pause las copias de seguridad del log de transacciones durante la fase inicial de siembra. Si las copias de seguridad del registro de transacciones son necesarias durante la fase inicial de propagación, inicie una transacción abierta para evitar el truncamiento del registro. Para obtener más información, revise Error 1412 al crear un vínculo de Instancia administrada en la guía de solución de problemas de la característica de vínculo.

Lista de copias de seguridad a largo plazo en Azure portal muestra los archivos de copia de seguridad de las bases de datos activas y eliminadas con el mismo nombre

Las copias de seguridad a largo plazo se pueden enumerar y administrar en Azure página del portal de una Azure SQL Managed Instance en la pestaña Backups. En la página se enumeran las bases de datos activas o eliminadas, la información básica sobre sus copias de seguridad a largo plazo y el vínculo para administrar las copias de seguridad. Al seleccionar el vínculo Administrar, se abre un nuevo panel lateral con la lista de copias de seguridad. Debido a un problema con la lógica de filtrado, la lista muestra las copias de seguridad de la base de datos activa y las bases de datos eliminadas con el mismo nombre. Esto requiere una atención especial al seleccionar copias de seguridad para su eliminación, para evitar eliminar copias de seguridad de una base de datos incorrecta.

Solución alternativa: utilice la información de hora de copia de seguridad (UTC) mostrada en la lista para diferenciar las copias de seguridad pertenecientes a bases de datos con el mismo nombre que existieron en la instancia en distintos periodos. Como alternativa, use los comandos de PowerShell Get-AzSqlInstanceDatabaseLongTermRetentionBackup y Remove-AzSqlInstanceDatabaseLongTermRetentionBackup, o los comandos de la CLI az sql midb ltr-backup list y az sql midb ltr-backup delete para administrar copias de seguridad a largo plazo. Utilice el parámetro DatabaseState y el valor devuelto DatabaseDeletionTime para filtrar las copias de seguridad de una base de datos.

Es posible que se produzca un error en el procedimiento sp_send_dbmail cuando se use @query parámetro

Puede fallar el procedimiento almacenado cuando se utiliza el parámetro sp_send_dbmail. Los errores se producen cuando el procedimiento almacenado se ejecuta en una cuenta sysadmin .

Este problema se debe a un error conocido relacionado con el uso de la suplantación por parte de sp_send_dbmail.

Solución alternativa: asegúrese de llamar a sp_send_dbmail en una cuenta personalizada adecuada que cree y no en una cuenta sysadmin .

Este es un ejemplo de cómo puede crear una cuenta dedicada y modificar los objetos existentes que envían correo electrónico a través de sp_send_dbmail.

USE [msdb];
GO

-- Step 1: Create a user mapped to a login to specify as a runtime user.
CREATE USER [user_name] FOR LOGIN [login_name];
GO

EXECUTE msdb.dbo.sp_update_jobstep
    @job_name = N'db_mail_sending_job',
    @step_id = db_mail_sending_job_id,
    @database_user_name = N'user_name';
GO

-- Step 2: Grant DB Mail permissions to the user who created it.
ALTER ROLE [DatabaseMailUserRole] ADD MEMBER [user_name];
GO

-- Step 3: If the database of the job step is not msdb, the permission error cannot be avoided even if it is a member of the role, so set it to msdb.
EXECUTE msdb.dbo.sp_update_jobstep
    @job_name = N'db_mail_sending_job',
    @step_id = db_mail_sending_job_id,
    @database_name = N'msdb';
GO

-- Step 4: Set a principal in the email profile
EXECUTE msdb.dbo.sysmail_add_principalprofile_sp
    @principal_name = N'user_name',
    @profile_name = N'profile_name',
    @is_default = 0;
GO

Las transacciones distribuidas se pueden ejecutar después de quitar la instancia administrada de SQL del grupo de confianza del servidor

Los grupos de confianza del servidor se usan para establecer confianza entre instancias administradas, lo que constituye un requisito previo para ejecutar transacciones distribuidas. Después de quitar la instancia administrada de SQL del grupo de confianza del servidor o eliminar el grupo, es posible que todavía pueda ejecutar transacciones distribuidas. Para garantizar que las transacciones distribuidas estén deshabilitadas, realice una conmutación por error manual iniciada por el usuario en la instancia administrada de SQL.

No se puede crear SQL Managed Instance con el mismo nombre que el servidor lógico eliminado anteriormente

Al crear un servidor logical en Azure para Azure SQL Database o un SQL Managed Instance, el sistema crea un registro DNS para <name>.database.windows.com. Este registro DNS debe ser único. Si crea un servidor lógico para SQL Database y, a continuación, elimínelo, el nombre permanece reservado durante siete días. Durante este período, no se puede crear un SQL Managed Instance con el mismo nombre que el servidor lógico eliminado. Como solución alternativa, use un nombre diferente para el SQL Managed Instance o cree una incidencia de soporte técnico para liberar el nombre del servidor lógico.

El Service Principal no puede acceder a Microsoft Entra ID y AKV

En algunas circunstancias, existe un problema con el Principal de servicio que se usa para acceder a los servicios Microsoft Entra ID (anteriormente conocido como Azure Active Directory) y Azure Key Vault (AKV). Como resultado, este problema impacta el uso de la autenticación de Microsoft Entra y el cifrado de datos transparente (TDE) con la Instancia Administrada de SQL. Puede experimentar este problema como un problema de conectividad intermitente o no poder ejecutar instrucciones como o CREATE LOGIN/USER FROM EXTERNAL PROVIDEREXECUTE AS LOGIN/USER. La configuración de TDE con clave administrada por el cliente en una nueva Azure SQL Managed Instance también podría no funcionar en algunas circunstancias.

Workaround: Para evitar que este problema se produzca en el SQL Managed Instance, antes de ejecutar comandos de actualización o, en caso de que ya haya experimentado este problema después de los comandos de actualización, vaya a la página Overview de la SQL managed instance en el portal de Azure. En Settings, seleccione Microsoft Entra ID para acceder a la página de administración de SQL Managed Instance Microsoft Entra ID. Busque el siguiente mensaje de error:

Managed Instance needs a Service Principal to access Microsoft Entra ID. Click here to create a Service Principal.

Si encuentra este mensaje de error, selecciónelo y siga las instrucciones paso a paso proporcionadas hasta que se resuelva este error.

Error devuelto al intentar eliminar un archivo que no está vacío

SQL Server y SQL Managed Instance no permiten que un usuario elimine un archivo que no esté vacío. Si intenta quitar un archivo de datos no vacío mediante una ALTER DATABASE REMOVE FILE instrucción , el error:

Msg 5042 - The file '<file_name>' cannot be removed because it is not empty` isn't immediately returned. SQL Managed Instance keeps trying to drop the file, and the operation fails after 30 minutes with `Internal server error.

Las operaciones de cambio de nivel de servicio y creación de instancia se bloquean con la restauración en curso de la base de datos

Una instrucción en curso RESTORE, un proceso de migración del Data Migration Service y una restauración integrada a un momento dado pueden bloquear las actualizaciones en un nivel de servicio, el redimensionamiento de la instancia existente y la creación de nuevas instancias hasta que finalice el proceso de restauración.

El proceso de restauración bloqueará estas operaciones en las instancias administradas y en los grupos de instancias de la misma subred en la que se ejecute el proceso de restauración. Las instancias de los grupos de instancias no se ven afectadas. No se produce ningún error en las operaciones de creación o cambio del nivel de servicio ni se agotará su tiempo de espera. Continuarán una vez que el proceso de restauración se complete o cancele.

Solución alternativa: espere a que finalice el proceso de restauración; también puede cancelarlo si la operación de creación o actualización del nivel de servicio tiene mayor prioridad.

Resource Governor en una réplica secundaria legible necesita reconfiguración después de la conmutación por error

La característica Regulador de recursos que permite limitar los recursos asignados a la carga de trabajo de usuario podría clasificar incorrectamente algunas cargas de trabajo de usuario después de la conmutación por error o un cambio iniciado por el usuario del nivel de servicio (por ejemplo, el cambio de tamaño máximo de almacenamiento de instancia o núcleo virtual máximo).

Solución alternativa: ejecute ALTER RESOURCE GOVERNOR RECONFIGURE periódicamente o como parte de un trabajo del Agente SQL que ejecute la tarea SQL cuando la réplica secundaria legible se inicie si usa gobernador de recursos.

Superar el límite de almacenamiento con archivos pequeños de base de datos

CREATE DATABASE, ALTER DATABASE ADD FILE y RESTORE DATABASE podrían fallar porque la instancia alcanza el límite de almacenamiento de Azure en el nivel de servicio General Purpose, pero no en el nivel de servicio General Purpose de Next-gen o en el nivel de servicio Business Critical.

Cada instancia de uso general de SQL Managed Instance tiene hasta 35 TB de almacenamiento reservado para el espacio en disco Premium de Azure. Cada archivo de base de datos se coloca en un disco físico independiente. Los posibles tamaños de disco son: 128 GB, 256 GB, 512 GB, 1 TB o 4 TB. No se le cobra por el espacio no utilizado en el disco, pero la suma total de los tamaños de discos Premium de Azure no puede superar los 35 TB. En algunos casos, una instancia administrada de SQL que no necesita 8 TB en total podría superar el límite de 35 TB Azure en el tamaño de almacenamiento debido a la fragmentación interna.

Por ejemplo, una instancia de uso general de SQL Managed Instance podría tener un archivo grande que tenga un tamaño de 1,2 TB colocado en un disco de 4 TB. También podría tener 248 archivos cada uno de 1 GB situados en discos independientes de 128 GB. En este ejemplo:

• El tamaño de almacenamiento total del disco es de 1 x 4 TB + 248 x 128 GB = 35 TB.
• El espacio total reservado para las bases de datos en la instancia es de 1 x 1,2 TB + 248 x 1 GB = 1,4 TB.

En este ejemplo se muestra que, en determinadas circunstancias, debido a una distribución específica de archivos, una instancia de SQL Managed Instance podría alcanzar el límite de 35 TB que está reservado para un disco premium de Azure conectado, cuando es posible que no lo espere.

En este ejemplo, las bases de datos existentes seguirán funcionando y pueden crecer sin ningún problema, siempre y cuando no se agreguen nuevos archivos. No puede crear ni restaurar bases de datos nuevas porque no hay suficiente espacio para las unidades de disco nuevas, aunque el tamaño total de todas las bases de datos no alcance el límite de tamaño de instancia. El mensaje de error devuelto no está claro.

También puede identificar el número de archivos restantes mediante el uso de vistas del sistema. Si se alcanza este límite, intente vaciar y eliminar algunos de los archivos más pequeños mediante la instrucción DBCC SHRINKFILE o cambie al nivel Crítico para la empresa, que no tiene este límite.

Se muestran valores de GUID en lugar de nombres de base de datos

Varias vistas del sistema, contadores de rendimiento, mensajes de error, XEvents y entradas de registro de errores muestran identificadores de base de datos GUID en lugar de los nombres reales de base de datos. No confíe en estos identificadores de GUID porque se reemplazarán por los nombres reales de las bases de datos en el futuro.

Solución alternativa: Usa la vista sys.databases para obtener el nombre real de la base de datos a partir del nombre físico de la base de datos, especificado en forma de identificadores GUID de bases de datos:

SELECT name AS ActualDatabaseName,
       physical_database_name AS GUIDDatabaseIdentifier
FROM sys.databases
WHERE database_id > 4;

Los módulos de CLR y los servidores vinculados en algún momento no pueden hacer referencia a una dirección IP local.

Los módulos CLR de SQL Managed Instance y servidores vinculados o consultas distribuidas que hacen referencia a una instancia actual a veces no pueden resolver la dirección IP de una instancia local. Este error es un problema transitorio.

No hay ninguna resolución

Mensaje de error confuso al conectarse a una réplica de lectura mediante credenciales inválidas

Cuando intenta conectarse a la réplica secundaria de lectura de una instancia del nivel Crítico de Negocios mediante ApplicationIntent=ReadOnly con credenciales no válidas, la instancia notifica un error que indica que la master base de datos es de solo lectura. La instancia no informa correctamente de que las credenciales no son válidas.

Las copias de seguridad diferenciales no se toman cuando una instancia está vinculada a SQL Server

Al configurar un enlace entre SQL Server y Azure SQL Managed Instance, las copias de seguridad automatizadas completas y de registros de transacciones se realizan en la instancia administrada de SQL, independientemente de su rol principal o no. Sin embargo, las copias de seguridad diferenciales no se llevan a cabo actualmente, cuando pueden provocar tiempos de restauración más largos de los esperados.

Aumento del número de inicios de sesión del sistema usados para la replicación transaccional

El servicio Azure SQL Managed Instance crea un inicio de sesión del sistema con fines de replicación transaccional. Puede encontrar este inicio de sesión en SSMS (en Explorador de objetos>Security>Logins) o en la vista del sistema sys.syslogins. El formato del nombre de inicio de sesión es similar a DBxCy\WF-abcde01234QWERT, y el inicio de sesión tiene el rol de servidor público. En determinadas condiciones, este inicio de sesión se vuelve a crear y, debido a un problema interno, no se elimina el inicio de sesión anterior. Este error puede provocar un aumento del número de inicios de sesión. Estos inicios de sesión no representan una amenaza de seguridad y puede omitirlos de forma segura. No elimine estos inicios de sesión, ya que al menos uno de ellos se usa para la replicación transaccional.

Microsoft Entra inicio de sesión y usuarios no son compatibles en SSDT

SQL Server Data Tools no son totalmente compatibles con los inicios de sesión y los usuarios de Microsoft Entra.

No se admite la suplantación de los tipos de inicio de sesión de Microsoft Entra

La suplantación mediante EXECUTE AS USER o EXECUTE AS LOGIN no está soportada para los siguientes principios de Microsoft Entra:

• Usuarios con alias de Microsoft Entra. En este caso, la operación devuelve el error 15517.
• Microsoft Entra gestiona los inicios de sesión y usuarios basados en sus aplicaciones o principales de servicio. En este caso, la operación devuelve errores 15517 y 15406.

La replicación transaccional se debe volver a configurar después de la conmutación por error geográfica

Si habilita la replicación transaccional en una base de datos de un grupo de conmutación por error, el administrador de SQL Managed Instance debe limpiar todas las publicaciones de la base de datos principal antigua y volver a configurarlas en la nueva principal después de que se produzca una conmutación por error a otra región. Para más información, consulte Replicación.

Los registros de errores no se conservan

Los registros de errores que están disponibles en SQL Managed Instance no se conservan y su tamaño no se incluye en el límite máximo de almacenamiento. Es posible que se borren automáticamente los registros de errores si ocurre un cambio de sistema. Es posible que existan lagunas en el historial de registros de errores porque SQL Managed Instance se movió varias veces en varias máquinas virtuales.

Resuelto

Guía provisional sobre las actualizaciones de zona horaria de 2024 para Paraguay

(Resuelto en febrero de 2026)

El 14 de octubre de 2024, el gobierno paraguayo anunció un cambio permanente en la política de zona horaria. Paraguay ahora permanece en horario de verano (DST) durante todo el año, adoptando eficazmente UTC-3 como hora estándar. Como resultado, los relojes no avanzaron en 60 minutos a las 12:00 a.m. el 23 de marzo de 2025, según lo programado anteriormente. Este cambio afecta a la zona horaria estándar de Paraguay. Microsoft ha publicado actualizaciones relacionadas de Windows en febrero y marzo de 2025. Las instancias administradas de SQL que usan la zona horaria afectada reflejan este cambio y se alinean con el nuevo desplazamiento UTC-3.

Cambiar el tipo de conexión no afecta a las conexiones a través del punto de conexión del grupo de conmutación por error.

(Resuelto en noviembre de 2025)

Si una instancia participa en un grupo de conmutación por error, el cambio del tipo de conexión de la instancia no afecta a las conexiones establecidas a través del punto de conexión del agente de escucha del grupo de conmutación por error.

Inaccesibilidad temporal de instancias con el cliente de escucha del grupo de conmutación por error durante la operación de escalado

(Resuelto en abril de 2025)

El escalado de instancia administrada de SQL a veces requiere mover la instancia a un clúster virtual diferente, junto con los registros DNS mantenidos por el servicio asociados. Si la instancia administrada de SQL participa en un grupo de conmutación por error, el registro DNS correspondiente a su agente de escucha del grupo de conmutación por error asociado se mueve al nuevo clúster virtual. Esto ocurre si la instancia es el agente de escucha de lectura y escritura principal geográfica actual o si es el agente de escucha de solo lectura geográfica secundaria actual.

En el diseño actual de la operación de escalado, los registros DNS del agente de escucha se quitan del clúster virtual de origen antes de migrar completamente la instancia administrada de SQL al nuevo clúster virtual. En algunas situaciones, este diseño lleva a un tiempo prolongado durante el cual la dirección IP de la instancia no se puede resolver usando el listener. Durante este tiempo, un cliente de SQL que intenta acceder a la instancia que se está escalando mediante el endpoint del oyente puede esperar errores de inicio de sesión con el siguiente mensaje de error:

Error 40532: Cannot open server "xxx.xxx.xxx.xxx" requested by the login. The login failed. (Microsoft SQL Server, Error: 40532).

El problema se solucionará mediante el rediseño de la operación de escalado.

La tabla para copias de seguridad manuales en msdb no conserva el nombre de usuario

(Resuelto en agosto de 2023) La compatibilidad introducida recientemente para las copias de seguridad automáticas en msdb no contiene actualmente información de nombre de usuario.

Cuando se usa la autenticación SQL Server, no se admiten nombres de usuario con '@'

Los nombres de usuario que contienen el símbolo @ en el centro (por ejemplo, abc@xy) no pueden iniciar sesión con la autenticación SQL Server.

Es posible que se produzca un error al restaurar la copia de seguridad manual sin CHECKSUM

(Resuelto en junio de 2020) En determinadas circunstancias, puede fallar al restaurar la copia de seguridad manual de bases de datos que realizó en una instancia administrada de SQL sin CHECKSUM. En tal caso, vuelva a intentar restaurar la copia de seguridad hasta que complete el proceso correctamente.

Solución alternativa: realice copias de seguridad manuales de bases de datos en instancias administradas de SQL con CHECKSUM habilitadas.

Permisos en el grupo de recursos no se aplican a SQL Managed Instance

Cuando se aplica el rol de colaborador de SQL Managed Instance Azure a un grupo de recursos (RG), no se aplica a SQL Managed Instance y no tiene ningún efecto.

Workaround: Configure un rol de "SQL Managed Instance Contributor" para los usuarios en el nivel de suscripción.

Mensaje de error engañoso en el portal de Azure que sugiere la recreación de la entidad de servicio

La página Active Directory admin del portal de Azure para Azure SQL Managed Instance podría mostrar el siguiente mensaje de error, aunque el Principal del servicio ya está presente:

Managed Instance needs a Service Principal to access Microsoft Entra ID. Click here to create a Service Principal.

Puede ignorar este mensaje de error si la entidad de servicio para la instancia administrada de SQL ya existe o si la autenticación de Microsoft Entra en la misma instancia funciona.

Para comprobar si existe la entidad de servicio, vaya a la página Aplicaciones empresariales en el portal de Azure, elija Identidades Administradas en la lista desplegable Tipo de aplicación, seleccione Aplicar y escriba el nombre de la instancia administrada de SQL en el cuadro de búsqueda. Si el nombre de instancia aparece en la lista de resultados, la entidad de servicio ya existe y no se necesitan más acciones.

Si ya ha seguido las instrucciones del mensaje de error y ha seleccionado el enlace, el Service Principal de la instancia gestionada de SQL se ha recreado. En ese caso, asigne los permisos de lectura de Microsoft Entra ID al principal de servicio recién creado para que la autenticación de Microsoft Entra funcione correctamente. También puede ejecutar este paso con Azure PowerShell siguiendo las instructions.

No se puede acceder al destino del *event_file* de la sesión de eventos de *system_health*.

(Resuelto parcialmente en mayo de 2025) Al intentar leer el contenido del destino de event_file la system_health sesión de eventos, se produce el error 40538: "Se requiere una dirección URL válida que comienza con https:// como valor para cualquier ruta de archivo especificada".

Originalmente, este problema se produjo en SQL Server Management Studio (SSMS) o al leer los datos de sesión mediante la función sys.fn_xe_file_target_read_file.

En mayo de 2025, este problema se resolvió para leer datos de sesión de SSMS. El problema no se resuelve al leer datos de eventos mediante la sys.fn_xe_file_target_read_file función .

Este cambio de comportamiento es una consecuencia imprevista de una corrección de seguridad necesaria. Puede solucionar este problema creando su propio equivalente de la sesión de system_health con un destino de event_file en Azure Blob Storage. Para obtener más información, incluido un script de T-SQL para crear la sesión system_health que se puede modificar para crear su propio equivalente de system_health, consulta Uso de la sesión de system_health.

Los cuadros de diálogo de Service Broker entre bases de datos necesitan reinicialización después de la actualización del nivel de servicio

(Resuelto en enero de 2020) Los cuadros de diálogo de Service Broker entre bases de datos dejan de entregar los mensajes a los servicios de otras bases de datos después de cambiar la operación del nivel de servicio. Los mensajes no se pierden y se pueden encontrar en la cola del remitente. Cualquier cambio de vCores o tamaño de almacenamiento de instancias en SQL Managed Instance provoca que un valor en la vista sys.databases cambie para todas las bases de datos. Cualquier DIALOG creado con una instrucción BEGIN DIALOG que haga referencia a Agentes de servicio en otras bases de datos deja de entregar mensajes al servicio de destino.

Solución alternativa: detenga todas las actividades que usen conversaciones con cuadros de diálogo de Service Broker entre bases de datos antes de actualizar un nivel de servicio y vuelva a inicializarlos después. Si los mensajes no entregados permanecen después de un cambio en el nivel de servicio, lea los mensajes de la cola de origen y vuelva a enviarlos a la cola de destino.

Contribución al contenido

Para contribuir a la documentación de Azure SQL, consulte la guía de colaborador Docs.

Contenido relacionado

• Para obtener una lista de actualizaciones y mejoras de SQL Managed Instance, consulte SQL Managed Instance actualizaciones del servicio.

• Para obtener actualizaciones y mejoras en todos los servicios de Azure, consulte actualizaciones de Service.