Problemas conhecidos da Instância Gerenciada de SQL do Azure

Aplica-se a:Instância Gerenciada de SQL do Azure

Este artigo lista os problemas conhecidos no momento com a Instância Gerenciada de SQL do Azure, e sua data de resolução ou possível solução alternativa. Para saber mais sobre a Instância Gerenciada de SQL do Azure, consulte O que é a Instância Gerenciada de SQL do Azure?, e Quais são as novidades na Instância de 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 de SQL gratuita usando comandos da API REST, do PowerShell e da CLI do Azure . Não é possível modificar a política de retenção de backup por meio do portal do Azure.

Falha de logon secundário de leitura devido a longa espera em "HADR_DATABASE_WAIT_FOR_TRANSITION_TO_VERSIONING"

Você pode ver esse erro como uma exceção para o driver Microsoft OLE DB Driver 19 para SQL Server ao tentar se conectar a uma réplica secundária somente leitura de um grupo de failover, ou a um banco de dados replicado via link de Instância Gerenciada.

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

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

Diretrizes 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, adotando efetivamente o UTC-3 como seu horário padrão. Como resultado, os relógios não avançam 60 minutos às 00h de 23 de março de 2025, como agendado anteriormente. Essa alteração afeta o fuso horário padrão do Paraguai. A Microsoft lançou atualizações relacionadas do Windows em fevereiro e março de 2025. Atualmente, a Instância Gerenciada de 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 da Instância Gerenciada de SQL do Azure absorva a atualização no nível do sistema operacional.

Solução alternativa: caso você precise alterar fusos horários afetados para suas instâncias gerenciadas, lembre-se das limitações e siga as diretrizes da documentação.

Erro 8992 ao executar DBCC CHECKDB em um banco de dados do SQL Server que se originou da Instância Gerenciada de SQL

Você poderá 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 de SQL do Azure, como depois de restaurar um arquivo de backup ou do recurso de link da Instância Gerenciada de 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 de SQL do Azure e restaure ou vincule o banco de dados ao SQL Server 2022 novamente. Se a recriação do banco de dados da Instância Gerenciada de SQL do Azure de origem não for possível, entre em contato com o suporte da Microsoft para ajudar a resolver esse problema.

A 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 de 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 gerenciamento de backups. Quando você seleciona o link Gerenciar, um novo painel lateral é aberto com a lista de backups. Devido a um problema com a lógica de filtragem, a lista mostra backups para bancos de dados ativos e excluídos com o mesmo nome. Isso requer uma atenção maior ao selecionar os backups a serem excluídos, para evitar a exclusão de backups do banco de dados errado.

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

O procedimento sp_send_dbmail pode falhar com o parâmetro @query

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

Esse problema é causado por um bug conhecido relacionado a como sp_send_dbmail está usando a representaçã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 email 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 de SQL do Grupo de Confiança do Servidor

Os Grupos de Confiança do Servidor são usados para estabelecer a confiança entre as instâncias gerenciadas que são pré-requisitos para executar as transações distribuídas. Depois de remover a instância gerenciada de 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, que é o failover manual iniciado pelo usuário na instância gerenciada de SQL.

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

Um registro DNS de <name>.database.windows.com é gerado quando você cria um servidor lógico no Azure para Banco de Dados SQL do Azure ou uma Instância Gerenciada de SQL. O registro DNS deve ser exclusivo. Dessa forma, se você criar um servidor lógico para Banco de Dados SQL e 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 de SQL não pode ser criada com o mesmo nome do servidor lógico excluído. Como alternativa, use um nome diferente para a Instância Gerenciada de SQL ou crie um tíquete de suporte para liberar o nome do servidor lógico.

Service Principal não pode acessar Microsoft Entra ID e AKV

Em algumas circunstâncias, pode haver um problema com a Entidade de Serviço usada para acessar o Microsoft Entra ID (anteriormente Azure Active Directory) e os serviços do AKV (Azure Key Vault). Como resultado, esse problema afeta o uso da autenticação do Microsoft Entra e da TDE (Transparent Data Encryption) com a Instância Gerenciada de SQL. Você pode passar por isso ao ter um problema de conectividade intermitente ou não conseguir executar instruções como CREATE LOGIN/USER FROM EXTERNAL PROVIDER ou EXECUTE AS LOGIN/USER. A configuração da TDE com a chave gerenciada pelo cliente em uma nova Instância Gerenciada de 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 de SQL antes de executar qualquer comando de atualização ou ao ter enfrentado esse problema após os comandos de atualização, acesse a página de visão geral da Instância Gerenciada de SQL no portal do Azure. Em Configurações, selecione Microsoft Entra ID para acessar a página de administração do Microsoft Entra ID da Instância Gerenciada de SQL. Verifique se você pode ver a mensagem de erro:

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

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

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

O SQL Server e a Instância Gerenciada não permitem que o usuário descarte um arquivo que não esteja vazio. Se você tentar remover um arquivo 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 será retornado imediatamente. A Instância Gerenciada de SQL continuará tentando descartar o arquivo, e a operação falhará após 30 minutos com Internal server error.

A alteração da camada de serviço e a criação de operações de instância são bloqueadas pela restauração de banco de dados em andamento

Uma instrução contínua RESTORE, um processo de migração do Serviço de Migração de Dados e uma restauração interna ponto-a-ponto bloqueiam a atualização de uma camada de serviço, 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 bloqueará essas operações nas instâncias gerenciadas e nos pools de instância na mesma sub-rede em que o processo de restauração está em execução. As instâncias em pools de instâncias não são afetadas. Criar ou alterar operações da camada de serviço não falha ou o tempo limite. Eles prosseguem quando 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 mais alta.

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

O recurso Resource Governor 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 o failover ou uma alteração iniciada pelo usuário na camada de serviço (por exemplo, a alteração do tamanho máximo de armazenamento da instância ou do valor máximo de vCore).

Solução alternativa: execute ALTER RESOURCE GOVERNOR RECONFIGURE periodicamente, ou como parte de um trabalho do SQL Agent que executa a tarefa SQL ao iniciar a réplica secundária legível, se você estiver usando o Resource Governor.

Diálogos do Service Broker entre bancos de dados devem ser reinicializados após a atualização da camada de serviço.

Os diálogos do Service Broker entre diferentes bancos de dados param de entregar as mensagens para os serviços em outros bancos de dados após a operação de mudança de camada de serviço. As mensagens não são perdidas e podem ser encontradas na fila do remetente. Qualquer alteração de tamanho de armazenamento de instância ou de vCores na Instância Gerenciada de SQL fará com que um valor service_broke_guid na exibição sys.databases seja alterado para todos os bancos de dados. Qualquer DIALOG criado usando uma instrução BEGIN DIALOG que faz referência aos Service Brokers em outro banco de dados irá parar de entregar mensagens ao serviço de destino.

Solução alternativa: interrompa qualquer atividade que use diálogos do Service Broker entre bancos de dados antes de atualizar o nível de serviço e reinitialize-as depois. Se houver mensagens restantes que não são entregues após a alteração da camada de serviço, leia as mensagens da fila de origem e reenvie-as para a fila de destino.

Ultrapassando o limite de espaço de armazenamento com pequenos arquivos de banco de dados

CREATE DATABASE, ALTER DATABASE ADD FILE e 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 Uso Geral, mas não na atualização da camada de serviço Uso Geral de próxima geração ou na camada de serviço Crítico para Negócios.

Cada instância de Uso Geral da Instância Gerenciada de 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. 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 de SQL que não precisa de 8 TB no total pode exceder o limite do Azure de 35 TB no tamanho do armazenamento devido à fragmentação interna.

Por exemplo, uma instância de Uso Geral da Instância Gerenciada de SQL pode ter um arquivo grande de 1,2 TB de tamanho colocado em um disco de 4 TB. Ela também pode ter 248 arquivos de 1 GB cada, colocados em discos separados de 128 GB. Neste exemplo:

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

Esse exemplo ilustra que, em determinadas circunstâncias, devido a uma distribuição específica de arquivos, uma Instância Gerenciada de SQL pode alcançar o limite de 35 TB reservados para o Disco Premium do Azure anexado, mesmo quando não se esperaria isso.

Neste exemplo, bancos de dados existentes continuarão a funcionar e podem crescer sem problemas, desde que não sejam adicionados novos arquivos. No entanto os novos bancos de dados não podem ser criados ou restaurados porque não há espaço suficiente para novas unidades de disco, mesmo se o tamanho total de todos os bancos de dados não alcançar o limite de tamanho de instância. O erro retornado nesse caso não é claro.

Você pode identificar o número de arquivos restantes usando exibições do sistema. Se você atingir esse limite, tente esvaziar e excluir alguns dos arquivos menores usando a instrução DBCC SHRINKFILE ou alterne para a Camada comercialmente crítica, que não tem esse limite.

Valores de GUID mostrados em vez de nomes de banco de dados

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

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

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

Os módulos CLR e os servidores vinculados às vezes não podem fazer referência ao endereço IP local

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

Sem resolução

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

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

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

O serviço da Instância Gerenciada de SQL do Azure cria um logon do sistema para fins de replicação transacional. Esse logon pode ser encontrado no SSMS (no Pesquisador de Objetos em Segurança, Logons) ou na exibição do sistema sys.syslogins. O formato do nome de login se parece com 'DBxCy\WF-abcde01234QWERT' e o logon possui a função de servidor público. Em determinadas condições, esse login é recriado e, devido a uma falha no sistema, o logon anterior não é excluído. Isso pode levar ao aumento do número de logons. Esses logons não representam uma ameaça à segurança. Eles podem ser ignorados com segurança. Esses logons não devem ser excluídos porque pelo menos um deles está sendo usado para a replicação transacional.

Não há suporte para logons e usuários do Microsoft Entra no SSDT

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

Não há suporte para a representação de tipos de logon do Microsoft Entra

Não há suporte para a representação usando EXECUTE AS USER ou EXECUTE AS LOGIN das seguintes entidades de segurança do Microsoft Entra:

• Usuários do Microsoft Entra com alias. O seguinte erro é retornado nesse caso: 15517.
• Logons e usuários do Microsoft Entra com base em aplicativos ou entidades de serviço do Microsoft Entra. Os seguintes erros são retornados nesse 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 de SQL deverá limpar todas as publicações no antigo primário e reconfigurá-las no novo primário após a ocorrência de um failover em outra região. Para obter mais informações, consulte Replicação.

Os logs de erros não são persistentes

Os logs de erros disponíveis na Instância Gerenciada de SQL não são persistentes e seu tamanho não está incluído no limite de armazenamento máximo. Os logs de erros podem ser apagados automaticamente no caso de failover. Pode haver lacunas no histórico do log de erros porque a Instância Gerenciada de 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 endpoint do grupo de failover

(Resolvido em novembro de 2025)

Se uma instância participar de um grupo de failover, a alteração do tipo de conexão da instância não entrará em vigor para as conexões estabelecidas por meio do ponto de extremidade do ouvinte do grupo de failover.

Inacessibilidade temporária de instância usando o ouvinte do grupo de failover durante a operação de dimensionamento

(Resolvido em abril de 2025)

O dimensionamento da instância gerenciada de SQL às vezes requer mover a instância para um cluster virtual diferente, juntamente com os registros DNS mantidos pelo serviço associados. Se a instância gerenciada de SQL participar de um grupo de failover, o registro DNS correspondente ao ouvinte do grupo de failover associado (ouvinte de leitura/gravação, caso a instância seja o geo-primário atual; ou ouvinte somente leitura, caso a instância seja o geo-secundário atual) será movido para o novo cluster virtual.

No design da operação de dimensionamento atual, os registros DNS do listener são removidos do cluster virtual de origem antes que a própria instância gerenciada do SQL seja completamente migrada para o novo cluster virtual, o que em algumas situações pode levar a um período prolongado em que o IP da instância não pode ser resolvido usando o listener. Durante esse tempo, um cliente SQL que tenta 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.

A tabela para backups manuais em msdb não preserva o nome de usuário

(Resolvido em agosto de 2023) Recentemente, introduzimos 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 SQL Server autenticação, 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 autenticação do SQL Server.

Restaurar o 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 de SQL sem CHECKSUM pode não ser restaurado. Nesses casos, tente restaurar o backup novamente até obter sucesso.

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

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

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

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

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

A página Administrador do Active Directory do portal do Azure para a Instância Gerenciada de SQL do Azure pode exibir a seguinte mensagem de erro, mesmo que a entidade de serviço 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 essa mensagem de erro se o Principal de Serviço para a instância gerenciada de SQL já existir e/ou a autenticação do Microsoft Entra na instância gerenciada de SQL estiver funcionando.

Para verificar se o Principal de Serviço existe, navegue até a página Aplicativos Empresariais no portal do Azure, escolha Identidades Gerenciadas no menu suspenso do tipo de Aplicativo, clique em Aplicar e digite o nome da instância gerenciada de SQL na caixa de pesquisa. Se o nome da instância aparecer na lista de resultados, o Principal de Serviço já existe e nenhuma outra ação é necessária.

Se você já seguiu as instruções da mensagem de erro e clicou no link da mensagem de erro, o Principal de Serviço da instância gerenciada de SQL foi recriado. Nesse caso, atribua permissões de leitura do Microsoft Entra ID à entidade de serviço recém-criada para garantir que a autenticação do Microsoft Entra funcione corretamente. Isso pode ser feito pelo Azure PowerShell seguindo estas 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 você tenta ler o conteúdo do destino da sessão de evento event_file, obtém o erro 40538: "Uma URL válida começando com 'https://' é necessária como valor para qualquer caminho de arquivo especificado."

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

Em maio de 2025, esse problema foi resolvido para ler dados de sessão do SSMS. O problema não é resolvido ao ler dados de evento usando a sys.fn_xe_file_target_read_file função.

Essa alteração no comportamento é uma consequência não intencional de uma correção de segurança necessária. Os clientes podem solucionar esse problema criando uma versão equivalente da system_health sessão com um event_file alvo no Armazenamento de Blobs do Azure. Para obter mais informações, incluindo um script T-SQL para criar a sessão system_health que pode ser modificada para criar seu próprio equivalente de system_health, confira Usar a sessão system_health.

Contribuir com 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 das atualizações e melhorias na Instância Gerenciada de SQL, confira Atualizações de serviço da Instância Gerenciada de SQL.

• Para encontrar atualizações e melhorias para outros serviços do Azure, confira Atualizações de serviço.