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?
Observação
O Microsoft Entra ID era anteriormente conhecido como Azure Active Directory (Azure AD).
Problemas conhecidos
Tem solução alternativa
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 os bancos de dados ativos ou excluídos, as informações básicas sobre os backups de longo prazo e o link para gerenciar os 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 Get-AzSqlInstanceDatabaseLongTermRetentionBackup e Remove-AzSqlInstanceDatabaseLongTermRetentionBackup do PowerShell ou os comandos az sql midb ltr-backup list e az sql midb ltr-backup delete de CLI para gerenciar 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 destino event_file da sessão de evento system_health não está acessível
Quando você tenta ler o conteúdo do event_file destino da system_health sessão de evento, você recebe o erro 40538, "Um URL válido começando com 'https://' é necessário como valor para qualquer caminho de arquivo especificado." Isso ocorre no SQL Server Management Studio ou ao ler os dados da sessão usando a função sys.fn_xe_file_target_read_file.
Essa alteração no comportamento é uma consequência não intencional de uma correção de segurança necessária recente. Estamos investigando a viabilidade de uma alteração adicional que permita que os clientes continuem usando a system_health sessão na Instância Gerenciada de SQL do Azure com segurança. Enquanto isso, os clientes podem contornar esse problema criando seu próprio equivalente da system_health sessão com um event_file destino no Armazenamento de Blobs do Azure. Para obter mais informações, incluindo um script T-SQL para criar a system_health sessão que pode ser modificada para criar seu próprio equivalente do system_health, veja Use a sessão system_health.
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
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
Diretrizes provisórias sobre as atualizações de fuso horário de 2022 para o Chile
Em 8 de agosto de 2022, o governo chileno divulgou um comunicado oficial sobre uma mudança de fuso horário devido ao horário de verão. A partir da 0h de sábado em 10 de setembro de 2022 à 0h de sábado em 1º de abril de 2023, a hora oficial será adiantada em 60 minutos. A alteração afeta os três seguintes fusos horários: Horário Padrão do Pacífico SA, Horário Padrão da Ilha de Páscoa e Horário Padrão de Magallanes. As Instâncias Gerenciadas de SQL do Azure que usam os fusos horários afetados não refletem as alterações até que a Microsoft libere uma atualização do sistema operacional para dar suporte a isso e até que a Instância Gerenciada de SQL do Azure serviço absorva a atualização no 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.
A alteração do tipo de conexão não afeta as conexões por meio do ponto de extremidade do grupo de failover
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.
Solução alternativa: descarte e recrie o grupo de failover após alterar o tipo de conexão.
O procedimento sp_send_dbmail pode falhar temporariamente quando o parâmetro @query é usado
O procedimento sp_send_dbmail pode falhar temporariamente quando o parâmetro @query é usado. Quando esse problema ocorre, a cada segunda execução do procedimento sp_send_dbmail falha com erro Msg 22050, Level 16, State 1 e mensagem Failed to initialize sqlcmd library with error number -2147467259. Para poder ver esse erro corretamente, o procedimento deve ser chamado com o valor padrão 0 para o parâmetro @exclude_query_output, caso contrário, o erro não é propagado.
Esse problema é causado por um bug conhecido relacionado a como sp_send_dbmail está usando a representação e o pool de conexão.
Para contornar esse problema, coloque o código de envio de email em uma lógica de repetição que depende do parâmetro de saída @mailitem_id. Se a execução falhar, o valor do parâmetro é NULO, indicando que sp_send_dbmail deve ser chamado mais uma vez para enviar um email com sucesso. Veja aqui um exemplo dessa lógica de repetição:
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
As transações distribuídas podem ser executadas após a remoção da instância gerenciada 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 do grupo de confiança do servidor ou de excluir o grupo, você ainda pode executar as transações distribuídas. Há uma solução alternativa que você pode aplicar para garantir que as transações distribuídas sejam desabilitadas e que seja um failover manual iniciado pelo usuário na instância gerenciada.
As transações distribuídas não podem ser executadas após a operação de escalonamento da instância gerenciada
As operações de escalonamento da Instância Gerenciada de SQL que incluem a alteração da camada de serviço ou do número de vCores redefinirão as configurações do Grupo de Confiança do Servidor no back-end e desabilitarão a execução das transações distribuídas. Como alternativa, exclua e crie um novo Server Trust Group no portal do Azure.
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.
A entidade de serviço não pode acessar o Microsoft Entra ID e o AKV
Em algumas circunstâncias, pode haver um problema com a entidade de serviço usada para acessar os serviços do Microsoft Entra (antigo Azure Active Directory) e do Azure Key Vault (AKV). Como resultado, esse problema afeta o uso da autenticação do Microsoft Entra e da Transparent Data Encryption (TDE) 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ê consegue ver a mensagem de erro "A instância gerenciada precisa de uma entidade de serviço para acessar o Microsoft Entra ID. Clique aqui para criar uma entidade de serviço". Caso você encontre essa mensagem de erro, selecione-a e siga as instruções passo a passo fornecidas até que esse erro seja resolvido.
Limitação de failover manual por meio do portal para grupos de failover
Se o grupo de failover se estender entre instâncias em diferentes assinaturas ou grupos de recursos do Azure, o failover manual não poderá ser iniciado a partir da instância primária no grupo de failover.
Solução alternativa: inicie o failover por meio do portal a partir da instância geográfica secundária.
As funções do SQL Agent precisam de permissões EXECUTE explícitas para logons não sysadmin
Se logons diferentes de sysadmin forem adicionados a quaisquer funções de banco de dados fixas do SQL Agent, haverá um problema em que as permissões EXECUTE explícitas precisarão ser concedidas aos três procedimentos armazenados no banco de dados master para que esses logons funcionem. Se esse problema for encontrado, a mensagem de erro The EXECUTE permission was denied on the object <object_name> (Microsoft SQL Server, Error: 229) será mostrada.
Solução alternativa: depois de adicionar logons a uma função de banco de dados fixa do SQL Agent (SQLAgentUserRole, SQLAgentReaderRole ou SQLAgentOperatorRole), para cada um dos logons adicionados a essas funções, execute o script T-SQL a seguir para conceder explicitamente permissões EXECUTE aos procedimentos armazenados listados.
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];
Os limites de memória OLTP na memória não são aplicados
A camada de serviço comercialmente crítica não aplicará corretamente os limites máximos de memória para objetos com otimização de memória em alguns casos. A Instância Gerenciada de SQL pode permitir que a carga de trabalho use mais memória para operações OLTP in-memory, o que pode afetar a disponibilidade e a estabilidade da instância. As consultas OLTP na memória que estão atingindo os limites podem não falhar imediatamente. As consultas que usam mais memória OLTP in-memory falharão mais cedo se atingirem os limites.
Solução alternativa: monitore o uso do armazenamento do OLTP in-memory usando o SQL Server Management Studio para garantir que a carga de trabalho não esteja usando mais do que a memória disponível. Aumente os limites de memória que dependem do número de vCores ou otimize sua carga de trabalho para usar menos memória.
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
A instrução RESTORE contínua, o processo de migração do Serviço de Migração de Dados e a restauração pontual interna bloquearão 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 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. As operações de criação ou alteração da camada de serviço não falharão nem atingirão o tempo limite. Elas continuarão assim que o processo de restauração for 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 Resource Governor na camada de serviço comercialmente crítica talvez precise 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 alguma carga de trabalho do usuário após o failover ou uma alteração da camada de serviço iniciada pelo usuário (por exemplo, a alteração do vCore máximo ou do tamanho máximo do armazenamento da instância).
Solução alternativa: execute ALTER RESOURCE GOVERNOR RECONFIGURE periodicamente ou como parte do trabalho do SQL Agent que executa a tarefa SQL quando a instância for iniciada se você estiver usando o Resource Governor.
As caixas de diálogo de Service Broker de banco de dados cruzado devem ser reinicializadas após a atualização da camada de serviço
As caixas de diálogo de Service Broker de banco de dados cruzado deixarão de entregar as mensagens para os serviços em outros bancos de dados após a operação de alteração da 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 conversas de caixa de diálogo de Service Broker de banco de dados cruzado antes de atualizar uma camada de serviço e reinicialize-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.
Excedendo o espaço de armazenamento com arquivos de banco de dados pequenos
As instruções CREATE DATABASE, ALTER DATABASE ADD FILE e RESTORE DATABASE podem falhar porque a instância pode alcançar o limite de armazenamento do Azure.
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 que não precisa de 8 TB no total pode exceder o limite de 35 TB do Azure em tamanho de 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 da Instância Gerenciada de SQL pode alcançar o limite de 35 TB reservados para o Disco Premium do Azure anexado quando talvez isso não seja esperado.
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 entradas de exibições do sistema, contadores de desempenho, mensagens de erro, XEvents e logs de erros exibem identificadores do banco de dados GUID 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.
O escopo de transação em dois bancos de dados dentro da mesma instância não é compatível
(Resolvido em Março de 2020) A classe TransactionScope em .NET não funciona se duas consultas são enviadas para os dois bancos de dados dentro da mesma instância no mesmo escopo de transação:
using (var scope = new TransactionScope())
{
using (var conn1 = new SqlConnection("Server=quickstartbmi.neu15011648751ff.database.windows.net;Database=b;User ID=myuser;Password=mypassword;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=mypassword;Encrypt=true"))
{
conn2.Open();
var cmd2 = conn2.CreateCommand();
cmd2.CommandText = string.Format("insert into b.dbo.T2 values(2)"); cmd2.ExecuteNonQuery();
}
scope.Complete();
}
Solução alternativa (não é necessária desde março de 2020) : use SqlConnection.ChangeDatabase(String) para usar outro banco de dados no contexto de conexão em vez de usar duas conexões.
Sem resolução
Os backups diferenciais não são feitos quando uma instância está vinculada ao SQL Server
Ao configurar uma vinculação entre o SQL Server e a Instância Gerenciada de SQL do Azure, os backups de log de transações completos e automatizados são feitos na instância gerenciada, independentemente de ela 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 de identificação do logon se parece com 'DBxCy\WF-abcde01234QWERT' e ele tem função pública de servidor. Em determinadas condições, esse logon é recriado e devido a uma falha no logon anterior do sistema, 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 usurpação de identidade dos tipos de logon do Microsoft Entra
Não há suporte para a usurpação de identidade 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 aplicações ou entidades de serviço do Microsoft Entra. Os seguintes erros são retornados nesse caso:
15517e15406.
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.
A estrutura e o conteúdo do tempdb são recriados
O banco de dados tempdb sempre é dividido em 12 arquivos de dados, e a estrutura do arquivo não pode ser alterada. Esse tamanho máximo por arquivo não pode ser alterado e não possível adicionar novos arquivos a tempdb. tempdb é sempre recriado como um banco de dados vazio quando a instância inicia ou faz failover, e eventuais alterações feitas em tempdb não são preservadas.
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.
Inacessibilidade temporária da instância usando o ouvinte do grupo de failover durante a operação de dimensionamento
O dimensionamento da instância gerenciada à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 participar de um grupo de failover, o registro DNS correspondente ao ouvinte do grupo de failover associado (ouvinte de leitura/gravação, se a instância for a área geográfica primária atual ouvinte somente leitura, se a instância for a área geográfica secundária atual) será movido para o novo cluster virtual.
No design atual da operação de dimensionamento, os registros DNS do ouvinte são removidos do cluster virtual de origem antes que a própria instância gerenciada 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 de ouvinte pode esperar falhas de logon com a seguinte mensagem de erro: "Erro 40532: Não é possível abrir o servidor "xxx.xxx.xxx.xxx" solicitado pelo logon. Falha no logon. (Microsoft SQL Server, Erro: 40532)."
O problema será resolvido por meio do redesenho da operação de dimensionamento.
Resolvido
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.
A consulta a uma tabela externa falha com a mensagem de erro sem suporte
A consulta a uma tabela externa pode falhar com a mensagem de erro genérica "Não há suporte para consultas a tabelas externas com a camada de serviço ou o nível de desempenho atual deste banco de dados. Considere aumentar a camada de serviço ou o nível de desempenho do banco de dados”. O único tipo de tabela externa com suporte na Instância Gerenciada de SQL do Azure são as tabelas externas do PolyBase (em versão prévia). Para permitir consultas em tabelas externas do PolyBase, você precisa habilitar o PolyBase em instância gerenciada executando o comando sp_configure.
Tabelas externas relacionadas ao recurso de Consulta Elástica do Banco de Dados SQL do Azure não têm suporte na Instância Gerenciada de SQL, mas a criação e a consulta delas não foram bloqueadas explicitamente. Com o suporte às tabelas externas do PolyBase, foram introduzidas novas verificações, o que bloqueou a consulta a qualquer tipo de tabela externa na instância gerenciada a menos que o PolyBase esteja habilitado.
Se você estiver usando tabelas externas de Consulta Elástica sem suporte para consultar dados no Banco de Dados SQL do Azure ou no Azure Synapse a partir da sua instância gerenciada, deverá usar o recurso Servidor Vinculado. Para estabelecer a conexão do Servidor Vinculado da Instância Gerenciada de SQL ao Banco de Dados SQL, siga as instruções deste artigo. Para estabelecer a conexão do Servidor Vinculado da Instância Gerenciada de SQL ao SQL Synapse, verifique asinstruções de passo a passo. Como a configuração e o teste da conexão do Servidor Vinculado levam algum tempo, você pode usar uma solução alternativa de maneira temporária para habilitar a consulta a tabelas externas relacionadas ao recurso de consulta elástica:
Solução alternativa: execute os seguintes comandos (uma vez por instância) que permitirão consultas em tabelas externas:
sp_configure 'polybase enabled', 1;
GO
RECONFIGURE;
GO
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.
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 feito em uma instância gerenciada sem CHECKSUM pode falhar ao ser restaurado. Nesses casos, tente restaurar o backup novamente até obter sucesso.
Solução alternativa: faça backups manuais de bancos de dados nas instâncias gerenciadas com CHECKSUM habilitada.
O agente não responde após a modificação, desabilitação ou habilitação de trabalhos existentes
Em certas circunstâncias, modificar, desabilitar ou habilitar um trabalho existente pode fazer com que o agente pare de responder. O problema é mitigado automaticamente após a detecção, resultando na reinicialização do processo do agente.
Permissões no grupo de recursos não aplicadas à Instância Gerenciada de SQL
Quando a função do Azure de Colaborador da Instância Gerenciada de SQL é 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.
Os trabalhos do SQL Agent podem ser interrompidos pela reinicialização do processo do agente
(Resolvido em março de 2020) O SQL Agent cria uma nova sessão toda vez que o trabalho é iniciado, aumentando gradualmente o consumo de memória. Para evitar atingir o limite de memória interna, o que bloquearia a execução de trabalhos agendados, o processo do Agent será reiniciado assim que seu consumo de memória atingir o limite. Isso pode resultar na interrupção da execução de trabalhos em execução no momento da reinicialização.
@query parâmetro sem suporte no sp_send_db_mail
O @queryparâmetro no procedimento sp_send_db_mail não funciona.
Mensagem de erro equivocada no portal do Azure sugerindo a recriação da Entidade de Serviço
A página de 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:
"A instância gerenciada precisa de uma entidade de serviço para acessar o Microsoft Entra ID (antigo Azure Active Directory). Clique aqui para criar uma Entidade de Serviço"
Você pode ignorar essa mensagem de erro se a entidade de serviço para a instância gerenciada já existir e se a autenticação do Microsoft Entra na instância gerenciada funcionar.
Para verificar se a Entidade de Serviço existe, navegue até a página Aplicativos empresariais no portal do Azure, escolha Identidades Gerenciadas na lista suspensa Tipo de aplicativo, selecione Aplicar e digite o nome da instância gerenciada na caixa de pesquisa. Se o nome da instância aparecer na lista de resultados, significa que a Entidade de Serviço já existe; nenhuma outra ação é necessária.
Se você já seguiu as instruções da mensagem de erro e selecionou o link da mensagem de erro, isso significa que Entidade de Serviço da instância gerenciada foi recriada. Nesse caso, atribua permissões de leitura do Microsoft Entra ID à entidade de serviço recém-criada para que a autenticação do Microsoft Entra funcione corretamente. Isso pode ser feito pelo Azure PowerShell seguindo estas instruções.
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.