Problemas conocidos de Azure SQL Managed Instance
Se aplica a: 
Azure SQL Managed Instance
En este artículo se enumeran los problemas conocidos actualmente de Azure SQL Managed Instance, así como 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 Novedades de Azure SQL Managed Instance
Nota:
Microsoft Entra ID era conocido anteriormente como Azure Active Directory (Azure AD).
Problemas conocidos
Tiene solución alternativa
La 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 la página de Azure Portal para una Azure SQL Managed Instance en la pestaña Copias de seguridad. 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, utilice comandos de PowerShell Get-AzSqlInstanceDatabaseLongTermRetentionBackup y Remove-AzSqlInstanceDatabaseLongTermRetentionBackup o 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 mediante el parámetro DatabaseState y el valor devuelto DatabaseDeletionTime para filtrar las copias de seguridad de una base de datos.
No se puede acceder al destino event_file de la sesión de eventos de system_health
Al intentar leer el contenido del destino event_file de la sesión de eventos system_health, se obtiene el error 40538, "Se requiere una dirección URL válida que comienza por "https://" como valor para cualquier ruta de archivo especificada". Esto ocurre en SQL Server Management Studio o al leer los datos de sesión mediante la función sys.fn_xe_file_target_read_file.
Este cambio de comportamiento es una consecuencia imprevista de una corrección de seguridad necesaria reciente. Estamos investigando la viabilidad de un cambio adicional que permitiría a los clientes seguir usando la sesión system_health en Azure SQL Managed Instance de forma segura. Mientras tanto, los clientes pueden solucionar este problema creando su propio equivalente de la sesión system_health con un destino 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.
Se puede producir un error en el procedimiento sp_send_dbmail con el parámetro @query
Se puede producir un error en el procedimiento sp_send_dbmail cuando se usa el parámetro @query. Los errores se producen cuando el procedimiento almacenado se ejecuta en la cuenta sysadmin.
Este problema se debe a un error conocido relacionado con la forma en que sp_send_dbmail usa la suplantación.
Solución alternativa: asegúrate de llamar a sp_send_dbmail en la cuenta personalizada adecuada que has creado y no en la cuenta sysadmin.
Este es un ejemplo de cómo puedes 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
EXEC 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.
EXEC 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
EXEC msdb.dbo.sysmail_add_principalprofile_sp @principal_name=N'user_name', @profile_name=N'profile_name', @is_default=0
GO
Guía provisional sobre las actualizaciones de zona horaria de 2022 para Chile
El 8 de agosto de 2022, el gobierno chileno hizo un anuncio oficial sobre un cambio de zona horaria Daylight-Saving hora (DST). A partir de las 12:00 a.m. sábado, 10 de septiembre de 2022, hasta las 12:00 a.m. sábado, 1 de abril de 2023, la hora oficial se adelantará 60 minutos. El cambio afecta a las tres zonas horarias siguientes: Hora estándar del Pacífico SA, Hora estándar de la Isla de Pascua y Hora estándar de Magallanes. Las instancias de Azure SQL Managed Instance que usan zonas horarias afectadas no reflejarán los cambios hasta que Microsoft publique una actualización del sistema operativo que lo admita y el servicio Azure SQL Managed Instance servicio absorba la actualización en el nivel de sistema operativo.
Solución alternativa: Si necesita modificar las zonas horarias afectadas de las instancias administradas, tenga en cuenta las limitaciones y siga las instrucciones de la documentación.
Cambiar el tipo de conexión no afecta a las conexiones mediante el punto de conexión del grupo de conmutación por error
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.
Solución alternativa: quitar y volver a crear el grupo de conmutación por error después de cambiar el tipo de conexión.
Se puede producir un error transitorio en el procedimiento sp_send_dbmail cuando se usa el parámetro @query
Se puede producir un error transitorio en el procedimiento sp_send_dbmail cuando se usa el parámetro @query. Cuando se produce este problema, todas las ejecuciones del procedimiento sp_send_dbmail devuelven el error Msg 22050, Level 16, State 1 y el mensaje Failed to initialize sqlcmd library with error number -2147467259. Para poder ver este error correctamente, se debe llamar al procedimiento con el valor predeterminado 0 del parámetro @exclude_query_output; de lo contrario, el error no se propagará.
Este problema se debe a un error conocido relacionado con la forma en que sp_send_dbmail usa la suplantación y la agrupación de conexiones.
Para evitar este problema, encapsule el código para el envío de un correo electrónico en una lógica de reintento que dependa del parámetro de salida @mailitem_id. Si se produce un error en la ejecución, el valor del parámetro será NULL, lo que indicará que se debe llamar una vez más a sp_send_dbmail para enviar correctamente el correo electrónico. Este es un ejemplo de esta lógica de reintento:
CREATE PROCEDURE send_dbmail_with_retry AS
BEGIN
DECLARE @miid INT
EXEC msdb.dbo.sp_send_dbmail
@recipients = 'name@mail.com', @subject = 'Subject', @query = 'select * from dbo.test_table',
@profile_name ='AzureManagedInstance_dbmail_profile', @execute_query_database = 'testdb',
@mailitem_id = @miid OUTPUT
-- If sp_send_dbmail returned NULL @mailidem_id then retry sending email.
--
IF (@miid is NULL)
EXEC msdb.dbo.sp_send_dbmail
@recipients = 'name@mail.com', @subject = 'Subject', @query = 'select * from dbo.test_table',
@profile_name ='AzureManagedInstance_dbmail_profile', @execute_query_database = 'testdb',
END
Se pueden ejecutar transacciones distribuidas después de quitar la instancia administrada 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 una instancia administrada del grupo de confianza del servidor o de eliminar el grupo, es posible que pueda seguir ejecutando transacciones distribuidas. Existe una solución alternativa que se puede aplicar para asegurarse de que las transacciones distribuidas están deshabilitadas: la conmutación por error manual iniciada por el usuario en la instancia administrada.
No se pueden ejecutar transacciones distribuidas después de la operación de escalado de la instancia administrada
Las operaciones de escalado de SQL Managed Instance que incluyen un cambio de nivel de servicio o del número de núcleos virtuales restablecen la configuración del grupo de confianza del servidor en el back-end y deshabilitan la ejecución de transacciones distribuidas. Como solución alternativa, elimine y cree un grupo de confianza de servidor en Azure Portal.
No se puede crear una instancia de SQL Managed Instance con el mismo nombre que el servidor lógico eliminado anteriormente
Se crea un registro de DNS de <name>.database.windows.com cuando se crea un servidor lógico en Azure para Azure SQL Database, y cuando se crea una instancia de SQL Managed Instance. El registro de DNS debe ser único. Así, si crea un servidor lógico para SQL Database y luego lo elimina, hay un período de umbral de siete días para que el nombre se libere de los registros. Durante ese período no se puede crear ninguna instancia de SQL Managed Instance con el mismo nombre que el servidor lógico eliminado. Como solución alternativa, use otro nombre para la instancia de SQL Managed Instance o cree una incidencia de soporte técnico para liberar el nombre del servidor lógico.
La entidad de servicio no puede acceder a Microsoft Entra ID ni AKV
En algunas circunstancias, es posible que exista un problema con la entidad de servicio que se utiliza para acceder a los servicios Microsoft Entra ID (anteriormente Azure Active Directory) y Azure Key Vault (AKV). Como resultado, este problema afecta al uso de la autenticación de Microsoft Entra y al cifrado de datos transparente (TDE) con SQL Managed Instance. Esto podría experimentarse como un problema de conectividad intermitente o no podría ejecutar instrucciones como CREATE LOGIN/USER FROM EXTERNAL PROVIDER o EXECUTE AS LOGIN/USER. La configuración de TDE con clave administrada por el cliente en una nueva Instancia administrada de SQL de Azure también podría no funcionar en algunas circunstancias.
Solución alternativa: Para evitar que se produzca este problema en SQL Managed Instance antes de ejecutar cualquier comando de actualización, o en caso de que ya se haya experimentado este problema después de actualizar los comandos, vaya a la página de Información general de SQL Managed Instance en Azure Portal. En Configuración, seleccione Microsoft Entra ID para acceder a la página de administración de Microsoft Entra ID de SQL Managed Instance. Compruebe si puede ver el mensaje de error "Instancia administrada necesita una entidad de seguridad para acceder a Microsoft Entra ID. Haga clic aquí para crear una entidad de servicio". En caso de que aparezca este mensaje de error, selecciónelo y siga las instrucciones paso a paso que se proporcionan hasta que se resuelva el error.
Limitación de la conmutación por error manual a través del portal para grupos de conmutación por error
Si un grupo de conmutación por error abarca instancias de distintas suscripciones o grupos de recursos de Azure, la conmutación por error manual no se puede iniciar desde la instancia principal del grupo de conmutación por error.
Solución alternativa: inicie la conmutación por error mediante el portal desde la base de datos geográfica secundaria.
Los roles del Agente SQL necesitan permisos de ejecución (EXECUTE) explícitos para los inicios de sesión que no sean sysadmin
Si los inicios de sesión que no son de sysadmin se agregan a cualquiera de los roles fijos de base de datos del Agente SQL, existe un problema en el que los permisos EXECUTE explícitos deben concederse a los tres procedimientos almacenados en la base de datos master para que estos inicios de sesión funcionen. Si se encuentra este problema, se muestra el mensaje de error The EXECUTE permission was denied on the object <object_name> (Microsoft SQL Server, Error: 229).
Solución alternativa: Una vez que agregue inicios de sesión a un rol fijo de base de datos del Agente SQL (SQLAgentUserRole, SQLAgentReaderRole o SQLAgentOperatorRole), para cada uno de los inicios de sesión agregados a estos roles, ejecute el siguiente script de T-SQL para conceder explícitamente permisos EXECUTE a los procedimientos almacenados que se enumeran.
USE [master];
GO
CREATE USER [login_name] FOR LOGIN [login_name];
GO
GRANT EXECUTE ON master.dbo.xp_sqlagent_enum_jobs TO [login_name];
GRANT EXECUTE ON master.dbo.xp_sqlagent_is_starting TO [login_name];
GRANT EXECUTE ON master.dbo.xp_sqlagent_notify TO [login_name];
No se aplican límites de memoria de OLTP en memoria
En algunos casos, el nivel de servicio Crítico para la empresa no aplicará correctamente los límites de memoria máximos para los objetos optimizados para memoria. SQL Managed Instance puede permitir que la carga de trabajo use más memoria para las operaciones de OLTP en memoria, lo que puede afectar a la disponibilidad y la estabilidad de la instancia. Es posible que las consultas de OLTP en memoria que alcanzan los límites no generen errores de inmediato. Las consultas que usan más memoria de OLTP en memoria producirán un error antes si llegan a los límites.
Solución alternativa: Supervise el uso de almacenamiento de OLTP en memoria mediante SQL Server Management Studio para asegurarse de que la carga de trabajo no esté usando más memoria de la disponible. Aumente los límites de memoria que dependen del número de núcleos virtuales, u optimice la carga de trabajo para usar menos memoria.
Error devuelto al intentar eliminar un archivo que no está vacío
SQL Server y SQL Managed Instance no permiten al usuario quitar un archivo que no está vacío. Si intenta quitar un archivo de datos no vacío mediante una instrucción ALTER DATABASE REMOVE FILE, el error Msg 5042 – The file '<file_name>' cannot be removed because it is not empty no se devuelve inmediatamente. SQL Managed Instance seguirá intentando quitar el archivo y se producirá un error en la operación después de 30 minutos con 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
La instrucción RESTORE en curso, el proceso de migración del servicio de migración de datos y la restauración a un momento dado integrada bloquearán la actualización de un nivel de servicio o 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 verán afectadas. No se producirán errores 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 haya completado o cancelado.
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.
Es posible que sea necesario volver a configurar Resource Governor en el nivel de servicio Crítico para la empresa después de la conmutación por error
La característica Resource Governor que le permite limitar los recursos asignados a la carga de trabajo de usuario puede clasificar incorrectamente alguna carga de trabajo de usuario después de una conmutación por error o un cambio de nivel de servicio iniciado por el usuario (por ejemplo, el cambio de número máximo de núcleos virtuales o tamaño máximo de almacenamiento de instancia).
Solución alternativa: Ejecute ALTER RESOURCE GOVERNOR RECONFIGURE periódicamente o como parte de un trabajo del Agente SQL que ejecuta la tarea de SQL cuando la instancia se inicia si usa Resource Governor.
Los cuadros de diálogo de Service Broker entre bases de datos se deben volver a inicializar después de la actualización del nivel de servicio
Los cuadros de diálogo de Service Broker entre bases de datos dejarán de enviar mensajes a los servicios de otras bases de datos después de la operación para cambiar el nivel de servicio. Los mensajes no se pierden y se pueden encontrar en la cola del remitente. Todos los cambios de tamaño de almacenamiento en núcleos virtuales o instancias de SQL Managed Instance harán que cambie un valor service_broke_guid de la vista sys.databases para todas las bases de datos. Todos los elementos DIALOG creados con la instrucción BEGIN DIALOG que hace referencia a las instancias de Service Broker de otra base de datos dejarán 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 quedan mensajes que no se entregaron después del cambio de nivel de servicio, lea los mensajes de la cola de origen y vuelva a enviarlos a la cola de destino.
Exceder el espacio de almacenamiento con archivos de base de datos pequeños
Se puede producir un error en las instrucciones CREATE DATABASE, ALTER DATABASE ADD FILE y RESTORE DATABASE porque la instancia puede alcanzar el límite de almacenamiento de Azure.
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. El espacio no utilizado en el disco no se cobra, pero la suma total de los tamaños de disco Premium de Azure no puede superar los 35 TB. En algunos casos, una instancia administrada que no necesita 8 TB en total puede superar los 35 TB de límite de Azure en tamaño de almacenamiento debido a la fragmentación interna.
Por ejemplo, una instancia de uso general de SQL Managed Instance puede tener un archivo grande de 1,2 TB almacenado 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 ilustra 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 prémium de Azure conectado, cuando no era de esperar.
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 se podrían crear ni restaurar nuevas bases de datos porque no hay suficiente espacio para nuevas unidades de disco, incluso si el tamaño total de todas las bases de datos no alcanza el límite de tamaño de la instancia. El error que se devuelve en ese caso 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: Use la vista sys.databases para resolver el nombre real de la base de datos del nombre de la base de datos física, especificado en forma de identificadores de base de datos GUID:
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 de CLR en SQL Managed Instance y las consultas distribuidas o los servidores vinculados que hacen referencia a una instancia actual en algún momento no pueden resolver la dirección IP de una instancia local. Este error es un problema transitorio.
No se admite el ámbito de transacción en dos bases de datos de la misma instancia
(Se resuelve en marzo de 2020) La clase TransactionScope de .NET no funciona si dos consultas se envían a dos bases de datos de la misma instancia en el mismo ámbito de transacción:
using (var scope = new TransactionScope())
{
using (var conn1 = new SqlConnection("Server=quickstartbmi.neu15011648751ff.database.windows.net;Database=b;User ID=myuser;Password=<password>;Encrypt=true"))
{
conn1.Open();
SqlCommand cmd1 = conn1.CreateCommand();
cmd1.CommandText = string.Format("insert into T1 values(1)");
cmd1.ExecuteNonQuery();
}
using (var conn2 = new SqlConnection("Server=quickstartbmi.neu15011648751ff.database.windows.net;Database=b;User ID=myuser;Password=<password>;Encrypt=true"))
{
conn2.Open();
var cmd2 = conn2.CreateCommand();
cmd2.CommandText = string.Format("insert into b.dbo.T2 values(2)"); cmd2.ExecuteNonQuery();
}
scope.Complete();
}
Solución alternativa (no es necesaria desde marzo de 2020) : use SqlConnection.ChangeDatabase(String) para utilizar otra base de datos en un contexto de conexión en lugar de usar dos conexiones.
No hay ninguna resolución
Las copias de seguridad diferenciales no se toman cuando una instancia está vinculada a SQL Server
Al configurar un vínculo entre SQL Server y Azure SQL Managed Instance, las copias de seguridad automatizadas completas y del registro de transacciones se realizan en la instancia administrada, independientemente de si se encuentra o no en el rol principal. 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 está creando el inicio de sesión del sistema para la replicación transaccional. Este inicio de sesión se puede encontrar en SSMS (en el Explorador de objetos en la sección Seguridad, Inicios de sesión) o en la vista del sistema sys.syslogins. El formato de 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 vuelve a crearse y, por un error en el sistema, el inicio de sesión anterior no se elimina. Esto puede dar lugar a un mayor número de inicios de sesión. Dichos inicios de sesión no representan una amenaza a la seguridad. Pueden ignorarse sin ningún problema. Estos inicios de sesión no deben eliminarse porque al menos uno de ellos se usa para la replicación transaccional.
Los inicios de sesión y los usuarios de Microsoft Entra no se admiten en SSDT
SQL Server Data Tools no es totalmente compatible con los inicios de sesión y los usuarios de Microsoft Entra.
No se admite la suplantación de tipos de inicio de sesión de Microsoft Entra
No se admite la suplantación con EXECUTE AS USER o EXECUTE AS LOGIN de las siguientes entidades de seguridad de Microsoft Entra:
- Usuarios de Microsoft Entra con alias. Se devuelve el error siguiente en este caso:
15517. - Inicios de sesión y usuarios de Microsoft Entra basados en aplicaciones o entidades de servicio de Microsoft Entra. Se devuelven los errores siguientes en este caso:
15517y15406.
La replicación transaccional debe volver a configurarse después de la conmutación por error geográfica
Si la replicación transaccional está habilitada en una base de datos de un grupo de conmutación por error, el administrador de la instancia de SQL Managed Instance debe limpiar todas las publicaciones de la base de datos principal anterior y volver a configurarlas en la nueva base de datos principal después de que se produzca una conmutación por error a otra región. Para más información, consulte Replicación.
Se vuelve a crear la estructura y el contenido de tempdb
La base de datos tempdb siempre se divide en 12 archivos de datos y la estructura de archivos no se puede cambiar. No se puede cambiar el tamaño máximo por archivo y no se pueden agregar nuevos archivos a tempdb. La base de datos tempdb siempre se vuelve a crear como base de datos vacía cuando se inicia la instancia o se realiza una conmutación por error. Cualquier cambio que se realice en tempdb no se conservará.
Los registros de errores no se conservan
Los registros de errores que están disponibles en la Instancia administrada de SQL no se conservan y su tamaño no está incluido en el límite de almacenamiento máximo. Es posible que se borren automáticamente los registros de errores en caso de conmutación por error. Puede haber huecos en el historial del registro de errores porque la Instancia administrada de SQL se ha migrado varias veces en varias máquinas virtuales.
Inaccesibilidad de instancia temporal mediante el agente de escucha del grupo de migración tras error durante la operación de escalado
El escalado de la instancia administrada 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 participa en un grupo de migración tras error, el registro DNS correspondiente a su agente de escucha del grupo de migración tras error asociado (agente de escucha de lectura y escritura, si la instancia es la principal de replicación geográfica actual; agente de escucha de solo lectura, si la instancia es la secundaria de replicación geográfica actual) se mueve al nuevo clúster virtual.
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 que la propia instancia administrada se migre completamente al nuevo clúster virtual, lo que en algunas situaciones puede provocar un tiempo prolongado durante el cual la dirección IP de la instancia no se puede resolver mediante el agente de escucha. Durante este tiempo, un cliente SQL que intenta acceder a la instancia que se escala mediante el punto de conexión del agente de escucha puede esperar errores de inicio de sesión con el siguiente mensaje de error: "Error 40532: No se puede abrir el servidor ‘xxx.xxx.xxx.xxx’ solicitado por el inicio de sesión. Error de inicio de sesión. (Microsoft SQL Server, error: 40532)".
El problema se solucionará mediante el rediseño de la operación de escalado.
Resuelto
La tabla para copias de seguridad manuales en msdb no conserva el nombre de usuario
(Resuelto en agosto de 2023) Recientemente se introdujo compatibilidad con copias de seguridad automáticas en msdb, pero la tabla no contiene actualmente información de nombre de usuario.
Se produce un error al consultar la tabla externa con el mensaje de error "no admitido"
La consulta de tablas externas puede generar un mensaje de error que dice que las consultas en tablas externas no se admiten en el nivel de servicio o nivel de rendimiento actual de esta base de datos. Considere actualizar el nivel de servicio o nivel de rendimiento de la base de datos". El único tipo de tabla externa que se admite en Azure SQL Managed Instance son las tablas externas de PolyBase (en versión preliminar). Para permitir consultas de tablas externas de PolyBase, debe habilitar PolyBase en una instancia administrada mediante la ejecución del comando sp_configure.
Las tablas externas relacionadas con la característica Consulta elástica de Azure SQL Database no se admiten en SQL Managed Instance, aunque no se bloqueara explícitamente su creación y consulta. Con la compatibilidad con tablas externas de PolyBase, se han introducido nuevas comprobaciones que bloquean las consultas de cualquier tipo de tabla externa en la instancia administrada a menos que PolyBase esté habilitado.
Si usa tablas externas de consulta elástica no admitidas para consultar datos en Azure SQL Database o Azure Synapse desde la instancia administrada, debe usar la característica de servidor vinculado en su lugar. Para establecer una conexión de servidor vinculado de SQL Managed Instance a SQL Database, siga las instrucciones de este artículo. Para establecer la conexión del servidor vinculado de SQL Managed Instance a Synapse SQL, consulte estas instrucciones detalladas. Puesto que la configuración y prueba de la conexión del servidor vinculado tarda un poco, puede usar una solución alternativa como solución temporal para habilitar la consulta de tablas externas relacionadas con la característica de consulta elástica:
Solución alternativa: Ejecute los siguientes comandos (uno por instancia) que permiten consultas en tablas externas:
sp_configure 'polybase enabled', 1;
GO
RECONFIGURE;
GO
Al usar la autenticación de SQL Server, no se admiten nombres de usuario con "@"
Los nombres de usuario que contienen el símbolo "@" en el medio (por ejemplo, 'abc@xy') no pueden iniciar sesión mediante la autenticación de SQL Server.
La restauración de la copia de seguridad manual sin CHECKSUM puede devolver un error
(Resuelto en junio de 2020) En determinadas circunstancias, es posible que no se restaure la copia de seguridad manual de las bases de datos que se realizó en una instancia administrada 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 las bases de datos en instancias administradas con CHECKSUM habilitado.
El agente deja de responder al modificar, deshabilitar o habilitar los trabajos existentes
En determinadas circunstancias, la modificación, deshabilitación o habilitación de un trabajo existente puede hacer que el agente deje de responder. El problema se mitiga automáticamente tras la detección, lo que da como resultado un reinicio del proceso del agente.
Permisos en el grupo de recursos no aplicados a la Instancia administrada de SQL
Cuando el rol de Azure del colaborador de SQL Managed Instance se aplica a un grupo de recursos (RG), no se aplica a SQL Managed Instance y no tiene ningún efecto.
Solución alternativa: configure un rol de colaborador de SQL Managed Instance para los usuarios en el nivel de suscripción.
Los trabajos del Agente SQL pueden ser interrumpidos por el reinicio del proceso del agente
(Se resuelve en marzo de 2020) El Agente SQL crea una sesión cada vez que se inicia un trabajo, lo que aumenta gradualmente el consumo de memoria. Para evitar alcanzar el límite de memoria interna, lo que bloquearía la ejecución de los trabajos programados, el proceso del agente se reiniciará una vez que el consumo de memoria alcance el umbral. Puede provocar interrumpir la ejecución de los trabajos que se ejecutan en el momento del reinicio.
@queryNo se admite el parámetro en sp_send_db_mail
El @queryparámetro del procedimiento sp_send_db_mail no funciona.
Mensaje de error engañoso en Azure Portal que sugiere la recreación de la entidad de servicio
La página Administrador de Active Directory de Azure Portal para Azure SQL Managed Instance puede mostrar el siguiente mensaje de error, aunque la entidad de servicio ya exista:
"Instancia administrada necesita una entidad de seguridad para acceder a Microsoft Entra ID (anteriormente Azure Active Directory). Haga clic aquí para crear una entidad de servicio".
Puede ignorar este mensaje de error si la entidad de servicio de la instancia administrada ya existe o la autenticación de Microsoft Entra en la instancia administrada funciona.
Para comprobar si existe una entidad de servicio, vaya a la página Aplicaciones empresariales en Azure Portal, seleccione Identidades administradas en la lista desplegable Tipo de aplicación, seleccione Aplicar y escriba el nombre de la instancia administrada 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 vínculo del mensaje de error, se habrá vuelto a crear la entidad de servicio de la instancia administrada. En ese caso, asigne permisos de lectura de Microsoft Entra ID a la entidad de servicio recién creada para que la autenticación de Microsoft Entra funcione correctamente. Para ello, siga estas instrucciones mediante Azure PowerShell.
Contribución al contenido
Para colaborar en la documentación de Azure SQL, consulte la Guía para colaboradores de Microsoft Docs.
Contenido relacionado
Para obtener una lista de actualizaciones y mejoras de SQL Managed Instance, vea las actualizaciones del servicio SQL Managed Instance.
Para ver las actualizaciones y mejoras de todos los servicios de Azure, consulte las actualizaciones de los servicios.