Nota
O acesso a esta página requer autorização. Pode tentar iniciar sessão ou alterar os diretórios.
O acesso a esta página requer autorização. Pode tentar alterar os diretórios.
Aplica-se a: 
Azure SQL Managed Instance
Este artigo lista os problemas atualmente conhecidos com Azure SQL Managed Instance, e a sua data de resolução ou possível solução alternativa. Para saber mais sobre Azure SQL Managed Instance, veja O que é Azure SQL Managed Instance? e O que há de novo em Azure SQL Managed Instance?
Observação
Microsoft Entra ID era anteriormente conhecido como Azure Active Directory (Azure d.C.).
Problemas conhecidos
Tem solução alternativa
Falhas de operações de restauro após a migração para Instância Gerida do SQL
Se migrar uma base de dados para Azure SQL Managed Instance a partir do SQL Server 2019 e versões posteriores com recuperação acelerada da base de dados ativada, mas configurada com a persistent version store (PVS) definida para algo diferente do PRIMARY grupo de ficheiros, pode experienciar falhas nas operações de restauro na instância SQL gerida de destino.
Para contornar este problema, certifique-se de definir o armazenamento de versões persistentes (PVS) como PRIMARY na base de dados SQL Server de origem antes de migrá-lo para a Instância Gerida SQL. Se já migrou a base de dados sem definir o PVS para PRIMARY, pode defini-la na base de dados SQL Server de origem e depois remigrar a base de dados para a Instância Gerida SQL.
Não é possível usar a recuperação acelerada da base de dados após migrar para a Instância Gerida SQL
A partir do SQL Server 2019, se migrar uma base de dados para Azure SQL Managed Instance, e a base de dados de origem tiver a recuperação acelerada da base de dados desativada, não pode usar a recuperação acelerada da base de dados na instância SQL gerida de destino.
Para contornar este problema, certifique-se de ativar a recuperação acelerada da base de dados na base de dados SQL Server de origem antes de a migrar para a Instância Gerida SQL. Se já migrou a base de dados sem ativar a recuperação acelerada da base de dados, pode ativá-la na base de dados SQL Server de origem e depois remigrar a base de dados para a instância gerida em SQL.
O SQL Server 2017 e versões anteriores não suportam recuperação acelerada de bases de dados, por isso este problema não se aplica a bases de dados migradas dessas versões do SQL Server.
Não é possível usar o Service Broker após migrar para a Instância Gerida SQL
Se migrar uma base de dados para Azure SQL Managed Instance e o Service Broker estiver desativado na base de dados de origem, não pode usar o Service Broker na instância SQL gerida de destino.
Para contornar este problema, certifique-se de ativar o Service Broker na base de dados SQL Server de origem antes de o migrar para a Instância Gerida SQL. Se já migrou a base de dados sem ativar o Service Broker, pode ativá-la na base de dados SQL Server de origem e depois remigrar a base de dados para a Instância Gerida SQL.
Modificando o período de retenção de backup para a oferta gratuita
Só pode modificar a política de retenção de backups das suas bases de dados na instância gerida gratuita de SQL usando comandos REST API, PowerShell e Azure CLI. Não pode modificar a política de retenção de cópias de segurança através do portal Azure.
O login para leitura secundária falhou devido à longa espera em "HADR_DATABASE_WAIT_FOR_TRANSITION_TO_VERSIONING"
Pode ver este erro como exceção para o driver Microsoft OLE DB Driver 19 para SQL Server quando tenta ligar-se a uma réplica secundária só de leitura de um grupo failover, ou a uma base de dados replicada através do link Managed Instance.
Este erro ocorre quando a réplica secundária não está disponível para logins porque as versões de linha estão em falta para transações em andamento quando a réplica secundária foi reiniciada ou reciclada, seja para manutenção ou devido a uma ocorrência de failover. Quando uma instância reinicia ou faz failover, os dados de versão armazenados tempdb são apagados. Consultas de leitura secundárias são abortadas se existirem transações ativas de longa duração que começaram antes do failover ou do reinício.
Para resolver este problema, reverta ou comprometa 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.
Erro 8992 ao executar DBCC CHECKDB numa base de dados SQL Server que teve origem na SQL Managed Instance
Pode ver o seguinte erro ao executar o comando DBCC CHECKDB numa base de dados SQL Server 2022 depois de eliminar um índice, ou uma tabela com um índice, e a base de dados ter origem a partir de Azure SQL Managed Instance, como após restaurar um ficheiro de backup, ou a partir da funcionalidade de ligação 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 contornar o problema, primeiro retire o índice, ou a tabela com o índice, da base de dados de origem no Azure SQL Managed Instance, e depois restaure, ou ligue, a base de dados ao SQL Server 2022 novamente. Se não for possível recriar a base de dados a partir da Azure SQL Managed Instance de origem, contacte o suporte da Microsoft para ajudar a resolver este problema.
Atenção
Se você criar um índice particionado em uma tabela depois de descartar um índice conforme descrito neste cenário, a tabela se tornará inacessível.
A lista de backups de longo prazo no portal Azure mostra ficheiros de backup para bases de dados ativas e eliminadas com o mesmo nome
Backups a longo prazo podem ser listados e geridos na página Azure portal para um Azure SQL Managed Instance na aba Backups. A página lista bases de dados ativas ou eliminadas, informações básicas sobre os seus backups a longo prazo e um link para gerir 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.
Procedure sp_send_dbmail pode falhar quando o parâmetro @query é usado
O sp_send_dbmail procedimento armazenado pode falhar quando o @query parâmetro é utilizado. As falhas acontecem quando o procedimento armazenado é executado numa conta de sysadmin .
Este problema é causado por um bug conhecido relacionado com a forma como sp_send_dbmail utiliza a personificação.
Solução alternativa: Certifique-se de que chama sp_send_dbmail através de uma conta personalizada apropriada que você criou, e não de uma conta de administrador do sistema.
Aqui está um exemplo de como pode criar uma conta dedicada e modificar objetos existentes que enviam emails 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 gerida SQL do Server Trust Group ou eliminar o grupo, pode ainda conseguir executar transações distribuídas. Para garantir que as transações distribuídas estão desativadas, realize um failover manual iniciado pelo utilizador na instância gerida SQL.
Não é possível criar uma SQL Managed Instance com o mesmo nome do servidor lógico que foi eliminado anteriormente
Quando crias um servidor lógico em Azure para Azure SQL Database ou um SQL Managed Instance, o sistema cria um registo DNS para <name>.database.windows.com. Este registo DNS deve ser único. Se criares um servidor lógico para a base de dados SQL e depois o apagares, o nome fica reservado durante sete dias. Durante este período, não pode criar uma SQL Managed Instance com o mesmo nome do servidor lógico eliminado. Como solução alternativa, use um nome diferente para a SQL Managed Instance, ou crie um ticket de suporte para libertar o nome lógico do servidor.
O Service Principal não consegue aceder ao Microsoft Entra ID e AKV
Em algumas circunstâncias, existe um problema com o Principal de Serviço utilizado para aceder aos serviços Microsoft Entra ID (anteriormente Azure Active Directory) e Azure Key Vault (AKV). Como resultado, esta questão afeta a utilização da autenticação Microsoft Entra e da encriptação de dados transparentes (TDE) com o SQL Managed Instance. Pode experimentar este problema como um problema de conectividade intermitente, ou por não conseguir executar instruções como CREATE LOGIN/USER FROM EXTERNAL PROVIDER ou EXECUTE AS LOGIN/USER. Configurar o TDE com a chave gerida pelo cliente numa nova Azure SQL Managed Instance pode também não funcionar em algumas circunstâncias.
Solução alternativa: Para evitar que este problema aconteça no seu SQL Managed Instance, antes de executar quaisquer comandos de atualização, ou caso já tenha tido este problema após comandos de atualização, vá à página Visão Geral do seu SQL managed instance no portal Azure. Em Definições, selecione Microsoft Entra ID para aceder à página de administração do SQL Managed Instance Microsoft Entra ID. Procure a seguinte mensagem de erro:
Managed Instance needs a Service Principal to access Microsoft Entra ID. Click here to create a Service Principal.
Se encontrar esta mensagem de erro, selecione-a e siga as instruções passo a passo fornecidas até que este erro seja resolvido.
Erro errado retornado ao tentar remover um arquivo que não está vazio
SQL Server e SQL Managed Instance não permitem que um utilizador deixe cair um ficheiro que não esteja vazio. Se tentar remover um ficheiro de dados não vazio usando uma ALTER DATABASE REMOVE FILE instrução, o erro:
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.
As operações de alterar a camada de serviço e criar instância estã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 pontual integrada podem bloquear atualizações numa camada de serviço, ou redimensionar a instância existente e criar novas instâncias, até que o processo de restauro termine.
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 Resource Governor em uma réplica secundária legível precisa de reconfiguração após 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.
Exceder o espaço de armazenamento com pequenos ficheiros de base de dados
CREATE DATABASE, ALTER DATABASE ADD FILE e RESTORE DATABASE podem falhar porque a instância atinge o limite de Azure Storage no nível de serviço de Uso Geral, mas não no nível de serviço Next-gen General Purpose Service Tier ou no nível de serviço Crítico de Negócio.
Cada instância de uso geral do SQL Managed Instance tem até 35 TB de armazenamento reservados para o Azure Premium Disk Space. 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. Não é cobrado pelo espaço não utilizado no disco, mas a soma total dos tamanhos dos discos Azure Premium não pode ultrapassar 35 TB. Em alguns casos, uma instância gerida por SQL que não precisa de 8 TB no total pode ultrapassar o limite de 35 TB do Azure devido à fragmentação interna.
Por exemplo, uma instância de uso geral do SQL Managed Instance pode ter um ficheiro grande de 1,2 TB colocado num 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 certas circunstâncias, devido a uma distribuição específica de ficheiros, uma Instância Gerida do SQL pode atingir o limite de 35 TB reservado para um Disco Premium Azure ligado, mesmo 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. Não podes criar ou restaurar novas bases de dados porque não há espaço suficiente para novos discos rígidos, mesmo que o tamanho total de todas as bases de dados não atinja o limite de tamanho da instância. O erro retornado não é 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
Módulos CLR em SQL Managed Instance e servidores ligados ou consultas distribuídas que referenciam uma instância atual por vezes não conseguem resolver o IP de uma instância local. Este erro é um problema transitório.
Sem resolução
Mensagem de erro enganadora ao ligar-se a uma réplica de leitura usando credenciais inválidas
Quando tenta ligar-se à réplica secundária de leitura de uma instância do nível Business Critical usando ApplicationIntent=ReadOnly credenciais inválidas, a instância reporta um erro indicando que a master base de dados é apenas leitura. A instância não reporta corretamente que as credenciais são inválidas.
Backups diferenciais não são feitos quando uma instância está ligada ao SQL Server
Quando configuras um link entre o SQL Server e o Azure SQL Managed Instance, são feitos backups automáticos completos e de logs de transações na instância SQL gerida, esteja ou não na função primária. 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 Azure SQL Managed Instance cria um login de sistema para fins de replicação transacional. Pode encontrar este login no SSMS (em Object Explorer>Security>Logins) ou na vista do sistema sys.syslogins. O formato do nome de login é DBxCy\WF-abcde01234QWERT, e o login tem o papel de servidor público. Sob certas condições, este login é recriado e, devido a um problema interno, o login anterior não é apagado. Esta falha pode levar a um aumento no número de logins. Estes logins não representam uma ameaça à segurança, e pode ignorá-los em segurança. Não apague estes logins, porque pelo menos um deles está a ser usado para replicação transacional.
Os logins e utilizadores do Microsoft Entra não são suportados no SSDT
O SQL Server Data Tools não suporta totalmente os logins e utilizadores do Microsoft Entra.
Não é suportada a imitação dos tipos de login do Microsoft Entra
A personificação usando EXECUTE AS USER ou EXECUTE AS LOGIN não é suportada para os seguintes princípios Microsoft Entra:
- Utilizadores do Microsoft Entra com alias. Neste caso, a operação devolve erro
15517. - Iniciações de sessão e utilizadores do Microsoft Entra com base em aplicações ou princípios de serviço do Microsoft Entra. Neste caso, a operação devolve erros
15517e15406.
A replicação transacional deve ser reconfigurada após o failover geográfico
Se ativar a replicação transacional numa base de dados num grupo de failover, o administrador da SQL Managed Instance deve 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 erro não são persistidos
Os registos de erro disponíveis no SQL Managed Instance não são preservados, e o seu tamanho não está incluído no limite máximo de armazenamento. Os logs de erros podem ser apagados automaticamente se ocorrer failover. Podem existir lacunas no histórico do registo de erros porque o SQL Managed Instance foi movido várias vezes em várias máquinas virtuais.
Resolvido
Orientações provisórias sobre atualizações de fuso horário de 2024 para o Paraguai
(Resolvido em fevereiro de 2026)
A 14 de outubro de 2024, o governo paraguaio anunciou uma alteração permanente à política de fusos horários. O Paraguai mantém-se agora 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çaram 60 minutos às 00:00 do dia 23 de março de 2025, como estava previamente previsto. Esta alteração afeta o fuso horário padrão do Paraguai. A Microsoft lançou atualizações relacionadas Windows em fevereiro e março de 2025. As instâncias geridas por SQL que utilizam o fuso horário afetado refletem esta alteração e alinham-se com o novo deslocamento UTC-3.
Alterar o tipo de conexão não afeta as ligações através do endpoint do grupo de falha
(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 usando 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 atual da operação de escalação, os registos DNS do ouvinte são removidos do cluster virtual de origem antes de esta migrar totalmente a instância SQL gerida para o novo cluster virtual. Em algumas situações, este design leva a um período prolongado durante o qual o endereço IP da instância não pode ser resolvido usando o ouvinte. Durante este período, um cliente SQL que tente aceder à instância que está a ser escalada usando o endpoint do ouvinte pode esperar falhas de login 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) O suporte recentemente introduzido para backups msdb automáticos não contém atualmente informação de nome de utilizador.
Quando usa autenticação SQL Server, nomes de utilizador com '@' não são suportados
Nomes de utilizador que contêm o símbolo @ no meio (por exemplo, abc@xy) não conseguem iniciar sessão usando autenticação SQL Server.
A restauração do backup manual sem CHECKSUM pode falhar
(Resolvido em junho de 2020) Em certas circunstâncias, restaurar a cópia de segurança manual de bases de dados que fez numa instância gerida por SQL sem CHECKSUM pode falhar. Nesses casos, tente restaurar novamente o backup até ser bem-sucedido.
Solução alternativa: Faça backups manuais de bases de dados em instâncias geridas por SQL com CHECKSUM ativado.
Permissões no grupo de recursos não aplicadas à SQL Managed Instance
Quando aplicas o papel SQL Managed Instance Contributor Azure a um grupo de recursos (RG), não se aplica ao SQL Managed Instance e não tem efeito.
Solução alternativa: Configure um papel de Contribuidor SQL Managed Instance para os utilizadores ao nível da subscrição.
Mensagem de erro enganadora no portal do Azure sugerindo a recriação do Service Principal
A página Active Directory admin do portal 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. Click here to create a Service Principal.
Pode negligenciar esta mensagem de erro se o Service Principal para a instância gerida de SQL já existir, e/ou se a autenticação Microsoft Entra na instância gerida de SQL funcionar.
Para verificar se existe o Service Principal, navegue até à página aplicações empresariais no portal Azure, escolha Identidades Geridas na lista suspensa Tipo de Aplicação, selecione Aplicar e escreva o nome da instância gerida 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 já seguiu as instruções da mensagem de erro e selecionou o link, o Principal de Serviço da instância gerida do SQL é recriado. Nesse caso, atribuir permissões de leitura do Microsoft Entra ID ao recém-criado Service Principal para que a autenticação Microsoft Entra funcione corretamente. Também pode executar esta etapa com o Azure PowerShell seguindo as instruções.
O event_file alvo da sessão do 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 em SQL Server Management Studio (SSMS), ou seja, 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 para a leitura dos dados das sessões do SSMS. O problema não é resolvido ao ler dados de eventos através da 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. Podes contornar este problema criando o teu próprio equivalente da sessão system_health com um alvo event_file em 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.
Os diálogos do Service Broker entre bases de dados precisam de reinicialização após a atualização do nível de serviço
(Resolvido em janeiro de 2020) Os diálogos do Service Broker entre bases de dados deixam de entregar as mensagens aos serviços noutras 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 nos vCores ou no tamanho do armazenamento da instância em SQL Managed Instance faz com que um valor service_broke_guid na vista sys.databases seja alterado para todas as bases de dados. Qualquer DIALOG instrução criada usando uma instrução BEGIN DIALOG que faça referência a Service Brokers noutras bases de dados deixa de entregar mensagens ao serviço alvo.
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 as mensagens não entregues permanecerem após uma alteração de nível de serviço, leia as mensagens da fila de origem e reenvie-as para a fila de destino.
Contribua para o conteúdo
Para contribuir para a documentação Azure SQL, consulte o guia de colaboradores Docs.
Conteúdo relacionado
Para uma lista de atualizações e melhorias para o SQL Managed Instance, consulte atualizações de serviço do SQL Managed Instance.
Para atualizações e melhorias em todos os serviços Azure, consulte Atualizações de serviço.