Problemas conhecidos com a Instância Gerenciada SQL do Azure

Aplica-se a:Instância Gerida SQL do Azure

Este artigo lista os problemas atualmente conhecidos com Instância Gerenciada SQL do Azuree sua data de resolução ou possível solução alternativa. Para saber mais sobre a Instância Gerenciada SQL do Azure, consulte O que é a Instância Gerenciada SQL do Azure?e O que há de novo na Instância Gerenciada SQL do Azure?

Problemas conhecidos

Tem solução alternativa

Modificando o período de retenção de backup para a oferta gratuita

Você só pode modificar a política de retenção de backup de seus bancos de dados na instância gerenciada SQL gratuita usando comandos REST API,PowerShell e CLI do Azure . Não é possível modificar a política de retenção de backup por meio do portal do Azure.

O login para leitura-secundária falhou devido à longa espera em "HADR_DATABASE_WAIT_FOR_TRANSITION_TO_VERSIONING"

Você poderá ver este erro como uma exceção para o driver Microsoft OLE DB Driver 19 para SQL Server quando tentar conectar-se a uma réplica secundária somente leitura de um grupo de transição de erro ou a um banco de dados replicado através do link de Instância Gerida.

Esse erro ocorre quando a réplica secundária não está disponível para logons porque faltam versões de linha para transações que estavam em andamento quando uma réplica secundária foi reiniciada ou reciclada, seja para manutenção ou devido a um failover. Quando uma instância é reiniciada ou faz failover, os dados de controle de versão armazenados em tempdb são limpos para que as consultas de leitura secundárias sejam anuladas se houver transações ativas de longa duração que foram iniciadas antes do failover ou reinício.

Para resolver este problema, reverta ou confirme as transações ativas na réplica principal. Para evitar esse erro, minimize as transações de gravação de longa duração na réplica primária.

Orientações provisórias sobre atualizações de fuso horário de 2024 para o Paraguai

Em 14 de outubro de 2024, o governo paraguaio anunciou uma mudança permanente na política de fuso horário do país. O Paraguai permanece no horário de verão (DST) durante todo o ano, efetivamente adotando o UTC-3 como seu horário padrão. Como resultado, os relógios não avançam 60 minutos às 12h00 do dia 23 de março de 2025, como programado anteriormente. Esta alteração afeta o fuso horário padrão do Paraguai. A Microsoft lançou atualizações relacionadas ao Windows em fevereiro e março de 2025. Atualmente, a Instância Gerenciada SQL do Azure não reflete essa atualização. As instâncias que usam o fuso horário afetado não refletem as alterações até que o serviço de Instância Gerenciada SQL do Azure absorva a atualização no nível do sistema operacional.

Solução alternativa: Se você precisar alterar os fusos horários afetados para suas instâncias gerenciadas, esteja ciente das limitações e siga as orientações da documentação.

Erro 8992 ao executar DBCC CHECKDB em um banco de dados do SQL Server originado da instância gerenciada do SQL

Você pode ver o seguinte erro ao executar o DBCC CHECKDB comando em um banco de dados do SQL Server 2022 depois de excluir um índice ou uma tabela com um índice e o banco de dados originado da Instância Gerenciada SQL do Azure, como depois de restaurar um arquivo de backup, ou do recurso de link Instância Gerenciada SQL:

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 contornar o problema, primeiro solte o índice ou a tabela com o índice do banco de dados de origem na Instância Gerenciada SQL do Azure e, em seguida, restaure ou vincule o banco de dados ao SQL Server 2022 novamente. Se não for possível recriar a base de dados a partir da Instância Gerida SQL do Azure de origem, contacte o suporte da Microsoft para ajudar a resolver este problema.

Lista de backups de longo prazo no portal do Azure mostra arquivos de backup para bancos de dados ativos e excluídos com o mesmo nome

Os backups de longo prazo podem ser listados e gerenciados na página do portal do Azure para uma Instância Gerenciada SQL do Azure na guia Backups . A página lista bancos de dados ativos ou excluídos, informações básicas sobre seus backups de longo prazo e link para gerenciar backups. Quando você seleciona o link Gerenciar, um novo painel lateral é aberto com uma lista de backups. Devido a um problema com a lógica de filtragem, a lista mostra backups para bancos de dados ativos e bancos de dados excluídos com o mesmo nome. Isso requer uma atenção especial ao selecionar backups para exclusão, para evitar a exclusão de backups para um banco de dados errado.

Solução alternativa: Use as informações exibidas Tempo de backup (UTC) na lista para diferenciar backups pertencentes a bancos de dados com o mesmo nome que existiam na instância em períodos diferentes. Alternativamente, utilize os comandos do PowerShell Get-AzSqlInstanceDatabaseLongTermRetentionBackup e Remove-AzSqlInstanceDatabaseLongTermRetentionBackup ou os comandos da CLI az sql midb ltr-backup list e az sql midb ltr-backup delete para gerir backups de longo prazo usando o parâmetro DatabaseState e o valor de retorno DatabaseDeletionTime para filtrar os backups de um banco de dados.

O procedimento sp_send_dbmail pode falhar quando o parâmetro @query é utilizado.

O procedimento sp_send_dbmail pode falhar quando @query parâmetro é usado. As falhas acontecem quando o procedimento armazenado é executado na conta sysadmin.

Esse problema é causado por um bug conhecido relacionado a como sp_send_dbmail está usando a impersonificação.

Solução alternativa: Certifique-se de chamar sp_send_dbmail na conta personalizada apropriada que você criou, e não na conta sysadmin.

Aqui está um exemplo de como você pode criar uma conta dedicada e modificar objetos existentes que estão enviando e-mail via 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

As transações distribuídas podem ser executadas após a remoção da instância gerenciada SQL do Grupo de Confiança do Servidor

Grupos de Confiança do Servidor são usados para estabelecer confiança entre instâncias geridas como pré-requisito para a execução de transações distribuídas . Depois de remover a instância gerenciada SQL do Grupo de Confiança do Servidor ou excluir o grupo, você ainda poderá executar transações distribuídas. Há uma solução alternativa que você pode aplicar para ter certeza de que as transações distribuídas estão desabilitadas e que é o failover manual iniciado pelo usuário na instância gerenciada do SQL.

Não é possível criar a Instância Gerenciada SQL com o mesmo nome do servidor lógico excluído anteriormente

Um registro DNS de <name>.database.windows.com é criado quando você cria um servidor lógico no Azure para o Banco de Dados SQL do Azure e quando cria uma Instância Gerenciada do SQL. O registro DNS deve ser exclusivo. Como tal, se você criar um servidor lógico para o Banco de dados SQL e, em seguida, excluí-lo, haverá um período limite de sete dias antes que o nome seja liberado dos registros. Nesse período, uma Instância Gerenciada SQL não pode ser criada com o mesmo nome do servidor lógico excluído. Como solução alternativa, utilize um nome diferente para a Instância Gerida SQL ou crie um pedido de suporte para libertar o nome do servidor lógico.

A entidade de serviço não consegue aceder ao Microsoft Entra ID e ao Azure Key Vault (AKV)

Em algumas circunstâncias, pode existir um problema com a Entidade de Serviço usada para acessar os serviços Microsoft Entra ID (anteriormente Azure Ative Directory) e Azure Key Vault (AKV). Como resultado, esse problema afeta o uso da autenticação do Microsoft Entra e da criptografia de dados transparente (TDE) com a Instância Gerenciada SQL. Isso pode ser visto como um problema de conectividade intermitente ou não ser capaz de executar instruções como CREATE LOGIN/USER FROM EXTERNAL PROVIDER ou EXECUTE AS LOGIN/USER. Configurar TDE com chave gerenciada pelo cliente em uma nova Instância Gerenciada SQL do Azure também pode não funcionar em algumas circunstâncias.

Solução alternativa: Para evitar que esse problema ocorra em sua Instância Gerenciada do SQL, antes de executar qualquer comando de atualização, ou caso você já tenha enfrentado esse problema após os comandos de atualização, vá para a página Visão Geral do da sua instância gerenciada do SQL no portal do Azure. Em Configurações, selecione Microsoft Entra ID para aceder à página de administração do Microsoft Entra ID da Instância Gerenciada do SQL . Verifique se consegue ver a mensagem de erro:

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

Caso tenha encontrado essa mensagem de erro, selecione-a e siga as instruções passo a passo fornecidas até que esse erro seja resolvido.

Erro errado retornado ao tentar remover um arquivo que não está vazio

O SQL Server e o SQL Managed Instance não permitem que um usuário solte um arquivo que não esteja vazio. Se tentar remover um ficheiro de dados não vazio usando uma instrução ALTER DATABASE REMOVE FILE, o erro Msg 5042 – The file '<file_name>' cannot be removed because it is not empty não é imediatamente retornado. A Instância Gerida SQL continuará a tentar eliminar o ficheiro, e a operação falhará após 30 minutos com Internal server error.

As operações de alteração da camada de serviço e criação de instância são bloqueadas pela restauração contínua do banco de dados

Uma instrução contínua RESTORE , um processo de migração do Serviço de Migração de Dados e uma restauração point-in-time integrada, bloqueiam a atualização de uma camada de serviço ou o redimensionamento da instância existente e a criação de novas instâncias até que o processo de restauração seja concluído.

O processo de restauração bloqueia essas operações nas instâncias gerenciadas e pools de instâncias na mesma sub-rede em que o processo de restauração está sendo executado. As instâncias em pools de instâncias não são afetadas. Criar ou alterar operações de camada de serviço não falha nem atinge o tempo limite. As operações prosseguem assim que o processo de restauração é concluído ou cancelado.

Solução alternativa: aguarde até que o processo de restauração seja concluído ou cancele o processo de restauração se a operação de criação ou atualização da camada de serviço tiver prioridade superior.

O Administrador de Recursos em uma réplica secundária legível precisa ser reconfigurado após seu failover

O recurso Administrador de recursos que permite limitar os recursos atribuídos à carga de trabalho do usuário pode classificar incorretamente algumas cargas de trabalho do usuário após failover ou uma alteração da camada de serviço iniciada pelo usuário (por exemplo, a alteração do tamanho máximo de armazenamento vCore ou máximo da instância).

Solução alternativa: execute ALTER RESOURCE GOVERNOR RECONFIGURE periodicamente ou como parte de um trabalho do SQL Agent que executa a tarefa SQL quando a réplica secundária legível é iniciada se estiver a usar o Gestor de Recursos.

Os diálogos do Service Broker entre bancos de dados devem ser reinicializados após a atualização do nível de serviço.

Os diálogos do Service Broker entre bases de dados deixam de entregar as mensagens aos serviços em outras bases de dados após a operação de alteração do nível de serviço. As mensagens não são perdidase podem ser encontradas na fila do remetente. Qualquer alteração de vCores ou do tamanho de armazenamento da SQL Managed Instance altera o valor de service_broke_guid na vista sys.databases de para todos os bancos de dados. Qualquer DIALOG criado usando uma instrução BEGIN DIALOG que faz referência a corretores de serviço noutros bancos de dados deixa de entregar mensagens ao serviço de destino.

Solução alternativa: Pare qualquer atividade que use conversas de diálogo entre bancos de dados do Service Broker antes de atualizar uma camada de serviço e reinicialize-as depois. Se houver mensagens restantes que não foram entregues após uma alteração na camada de serviço, leia as mensagens da fila de origem e reenvie-as para a fila de destino.

Exceder o espaço de armazenamento com pequenos ficheiros de base de dados

CREATE DATABASE, ALTER DATABASE ADD FILEe RESTORE DATABASE as instruções podem falhar porque a instância pode atingir o limite de Armazenamento do Azure na camada de serviço de Propósito Geral, mas não a atualização da camada de serviço de Finalidade Geral de Próxima geração ou a camada de serviço Crítica para os Negócios.

Cada instância de uso geral da Instância Gerenciada SQL tem até 35 TB de armazenamento reservado para espaço em disco Premium do Azure. Cada arquivo de banco de dados é colocado em um disco físico separado. Os tamanhos de disco podem ser 128 GB, 256 GB, 512 GB, 1 TB ou 4 TB. O espaço não utilizado no disco não é cobrado, mas a soma total dos tamanhos de Disco Premium do Azure não pode exceder 35 TB. Em alguns casos, uma instância gerenciada pelo SQL que não precisa de 8 TB no total pode exceder o limite de 35 TB do Azure no tamanho do armazenamento devido à fragmentação interna.

Por exemplo, uma instância de uso geral da instância gerenciada do SQL pode ter um arquivo grande de 1,2 TB colocado em um disco de 4 TB. Ele também pode ter 248 arquivos de 1 GB cada e que são colocados em discos separados de 128 GB. Neste exemplo:

• O tamanho total de armazenamento em disco alocado é 1 x 4 TB + 248 x 128 GB = 35 TB.
• O espaço total reservado para bancos de dados na instância é 1 x 1,2 TB + 248 x 1 GB = 1,4 TB.

Este exemplo ilustra que, em determinadas circunstâncias, devido a uma distribuição específica de ficheiros, uma SQL Managed Instance pode atingir o limite de 35 TB reservado para um Disco Premium anexado do Azure, quando não se espera.

Neste exemplo, os bancos de dados existentes continuam a funcionar e podem crescer sem qualquer problema, desde que novos arquivos não sejam adicionados. Novos bancos de dados não podem ser criados ou restaurados porque não há espaço suficiente para novas unidades de disco, mesmo que o tamanho total de todos os bancos de dados não atinja o limite de tamanho da instância. O erro retornado nesse caso não está claro.

Você pode identificar o número de arquivos restantes usando exibições do sistema. Se atingir este limite, tente esvaziar e apagar alguns dos arquivos menores usando a instrução DBCC SHRINKFILE ou alterne para o nível Business Critical, que não tem este limite.

Valores GUID mostrados em vez de nomes de banco de dados

Várias exibições do sistema, contadores de desempenho, mensagens de erro, XEvents e entradas de log de erros exibem identificadores de banco de dados GUID em vez dos nomes reais do banco de dados. Não confie nesses identificadores GUID porque eles podem ser substituídos por nomes de banco de dados reais no futuro.

Solução alternativa: Use sys.databases visualização para resolver o nome real do banco de dados a partir do nome físico do banco de dados, especificado na forma de identificadores GUID de banco de dados:

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

Módulos CLR e servidores vinculados às vezes não podem fazer referência a um endereço IP local

Os módulos CLR na Instância Gerenciada SQL e servidores vinculados ou consultas distribuídas que fazem referência a uma instância atual às vezes não conseguem resolver o IP de uma instância local. Este erro é um problema transitório.

Sem resolução

Os backups diferenciais não são feitos quando uma instância é vinculada ao SQL Server

Quando você configura um link entre o SQL Server e a Instância Gerenciada SQL do Azure, backups completos e de log de transações automatizados são feitos na instância gerenciada do SQL, esteja ela na função principal ou não. No entanto, atualmente não são feitos backups diferenciais, o que pode levar a tempos de restauração mais longos do que o esperado.

Aumento do número de logins do sistema usados para replicação transacional

O serviço de Instância Gerenciada SQL do Azure está criando o logon do sistema para fins de replicação transacional. Este login pode ser encontrado no SSMS (em Pesquisador de objetos, em Security, Logins) ou na visualização do sistema sys.syslogins. O formato do nome de login se parece com 'DBxCy\WF-abcde01234QWERT'e o login tem função de servidor público. Sob certas condições, este login é recriado e, devido a uma falha no sistema, o login anterior não é excluído. Isso pode levar ao aumento do número de logins. Esses logins não representam uma ameaça à segurança. Eles podem ser ignorados com segurança. Esses logins não devem ser excluídos porque pelo menos um deles está sendo usado para replicação transacional.

Os logins e usuários do Microsoft Entra não são suportados no SSDT

O SQL Server Data Tools não oferece suporte total a logins e usuários do Microsoft Entra.

Não é suportada a personificação de tipos de login do Microsoft Entra

A imitação usando EXECUTE AS USER ou EXECUTE AS LOGIN dos seguintes principais do Microsoft Entra não é suportada:

• Utilizadores com alias no Microsoft Entra. O seguinte erro é retornado neste caso: 15517.
• Inícios de sessão e utilizadores do Microsoft Entra baseados em aplicações ou entidades de serviço do Microsoft Entra. Os seguintes erros são retornados neste caso: 15517 e 15406.

A replicação transacional deve ser reconfigurada após o failover geográfico

Se a replicação transacional estiver habilitada em um banco de dados em um grupo de failover, o administrador da Instância Gerenciada SQL deverá limpar todas as publicações no primário antigo e reconfigurá-las no novo primário após ocorrer um failover para outra região. Para obter mais informações, consulte Replication.

Os logs de erros não são persistentes

Os logs de erro disponíveis na Instância Gerenciada SQL não são persistentes e seu tamanho não está incluído no limite máximo de armazenamento. Os logs de erros podem ser apagados automaticamente se ocorrer failover. Pode haver lacunas no histórico do log de erros porque a Instância Gerenciada SQL foi movida várias vezes em várias máquinas virtuais.

Resolvido

Alterar o tipo de conexão não afeta as conexões através do ponto de extremidade do grupo de failover

(Resolvido em novembro de 2025)

Se uma instância participar num grupo de failover , alterar o tipo de conexão da instância não terá efeito sobre as ligações estabelecidas através do ponto de escuta do grupo de failover.

Inacessibilidade temporária da instância ao usar o listener do grupo de failover durante a operação de dimensionamento

(Resolvido em abril de 2025)

Às vezes, o dimensionamento da instância gerenciada pelo SQL requer a movimentação da instância para um cluster virtual diferente, juntamente com os registros DNS mantidos pelo serviço associado. Se a instância gerida do SQL participar de um grupo de failover, o registo DNS correspondente ao ouvinte do grupo de failover associado (ouvinte de leitura-escrita, se a instância for a geoprimária atual; ou ouvinte somente leitura, se a instância for a geosecundária atual) será movido para o novo cluster virtual.

No design da operação de dimensionamento atual, os registros DNS do ouvinte são removidos do cluster virtual de origem antes que a própria instância gerenciada pelo SQL seja totalmente migrada para o novo cluster virtual, o que, em algumas situações, pode levar a um tempo prolongado durante o qual o endereço IP da instância não pode ser resolvido usando o ouvinte. Durante esse tempo, um cliente SQL tentando acessar a instância que está sendo dimensionada usando o ponto de extremidade do ouvinte pode esperar falhas de logon com a seguinte mensagem de erro:

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

O problema será resolvido por meio do redesenho da operação de dimensionamento.

Tabela para backups manuais no msdb não preserva o nome de usuário

(Resolvido em agosto de 2023) Introduzimos recentemente o suporte para backups automáticos no msdb, mas a tabela atualmente não contém informações de nome de usuário.

Ao usar a autenticação do SQL Server, não há suporte para nomes de usuário com '@'

Os nomes de usuário que contêm o símbolo '@' no meio (por exemplo, 'abc@xy') não podem entrar usando a autenticação do SQL Server.

A restauração do backup manual sem CHECKSUM pode falhar

(Resolvido em junho de 2020) Em determinadas circunstâncias, o backup manual de bancos de dados que foi feito em uma instância gerenciada SQL sem CHECKSUM pode falhar ao ser restaurado. Nesses casos, tente restaurar novamente o backup até ser bem-sucedido.

Solução alternativa: Faça backups manuais de bancos de dados em instâncias gerenciadas SQL com CHECKSUM habilitado.

Permissões no grupo de recursos não foram aplicadas à SQL Managed Instance

Quando a função de Colaborador da Instância Gerida do SQL no Azure é aplicada a um grupo de recursos (RG), não é aplicada à Instância Gerida do SQL e não tem efeito.

Solução Alternativa: configure uma função de Colaborador de Instância Gerenciada SQL para usuários no nível de assinatura.

Mensagem de erro enganosa no portal do Azure que sugere a recriação do Principal de Serviço

A página de administração de Active Directory do portal do Azure para Azure SQL Managed Instance pode mostrar a seguinte mensagem de erro, mesmo que o Service Principal já exista:

Managed Instance needs a Service Principal to access Microsoft Entra ID ([formerly Azure Active Directory](/entra/fundamentals/new-name)). Click here to create a Service Principal

Você pode ignorar esta mensagem de erro se o Principal de Serviço para a instância gerida de SQL já existir, e/ou a autenticação do Microsoft Entra na instância gerida de SQL estiver a funcionar.

Para verificar se o Principal de Serviço existe, navegue até à página Aplicações Empresariais no portal do Azure, escolha Identidades Geridas no menu pendente Tipo de Aplicação, selecione Aplicar e digite o nome da instância gerida do SQL na caixa de pesquisa. Se o nome da instância aparecer na lista de resultados, o Principal de Serviço já existe e não são necessárias ações adicionais.

Se você já seguiu as instruções da mensagem de erro e selecionou o link da mensagem de erro, a entidade de serviço da instância gerenciada SQL foi recriada. Nesse caso, atribua permissões de leitura do ID do Microsoft Entra à entidade de serviço recém-criada para que a autenticação do Microsoft Entra funcione corretamente. Isso pode ser feito por meio do Azure PowerShell seguindo instruções.

O destino event_file da sessão de evento system_health não está acessível

(Parcialmente resolvido em maio de 2025) Quando tenta ler o conteúdo do event_file destino da system_health sessão do evento, recebe o erro 40538, "É necessário um URL válido que comece por 'https://' como valor para qualquer caminho de ficheiro especificado."

Originalmente, este problema ocorria no SQL Server Management Studio (SSMS), ou ao ler os dados da sessão usando a função sys.fn_xe_file_target_read_file .

Em maio de 2025, esta questão foi resolvida na leitura dos dados das sessões do SSMS. O problema não é resolvido ao ler dados de eventos usando a sys.fn_xe_file_target_read_file função.

Esta mudança de comportamento é uma consequência não intencional de uma correção de segurança necessária. Os clientes podem contornar este problema criando o seu próprio equivalente da sessão system_health com um alvo event_file no Azure Blob Storage. Para obter mais informações, incluindo um script T-SQL para criar a sessão de system_health que pode ser modificada para criar o seu próprio equivalente de system_health, consulte Utilize a sessão system_health.

Contribua para o conteúdo

Para contribuir com a documentação do SQL do Azure, consulte o guia do colaborador do Docs.

Conteúdo relacionado

• Para obter uma lista de atualizações e melhorias da Instância Gerenciada SQL, consulte atualizações do serviço Instância Gerenciada SQL.

• Para obter atualizações e melhorias para todos os serviços do Azure, consulte Atualizações de serviço.