Problemas conhecidos com o Azure SQL Managed Instance

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

Este artigo lista os problemas atualmente conhecidos com a Instância Gerenciada SQL do Azure e sua data de resolução ou possível solução alternativa. Para saber mais sobre a Instância Gerenciada SQL do Azure, consulte a visão geral e as novidades.

Problemas conhecidos

Tem solução alternativa

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

Quando você tenta ler o conteúdo do destino da sessão de evento, você recebe o event_file system_health erro 40538, "Uma URL válida começando com 'https://' é necessária 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 recente necessária. Estamos investigando a viabilidade de uma alteração adicional que permitiria que os clientes continuassem usando a system_health sessão na instância gerenciada 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 blob do Azure. Para obter mais informações, incluindo um script T-SQL para criar a sessão que pode ser modificada para criar seu próprio equivalente do , consulte Usar a system_health sessão system_healthsystem_health.

A sp_send_dbmail de procedimento pode falhar quando @query o parâmetro é usado em instâncias gerenciadas habilitadas para nov22FW

O procedimento sp_send_dbmail pode falhar quando @query o parâmetro é usado, e isso afeta instâncias que têm a onda de recursos de novembro de 2022 habilitada. 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 representação.

Solução alternativa: certifique-se de ligar 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
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

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

Em 8 de agosto de 2022, o governo chileno fez um anúncio oficial sobre uma mudança de fuso horário de verão (DST). A partir das 12h00 de sábado, 10 de setembro de 2022, até às 12h00 de sábado, 1 de abril de 2023, o horário oficial avançará 60 minutos. A alteração afeta os seguintes três fusos horários: Hora Padrão Pacific SA, Hora Padrão da Ilha de Páscoa e Hora Padrão Magallanes. As Instâncias Gerenciadas SQL do Azure que usam fusos horários afetados não refletem as alterações até que a Microsoft lance uma atualização do sistema operacional para dar suporte a isso e 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.

Alterar o tipo de conexão não afeta as conexões através 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 terá efeito para as conexões estabelecidas por meio do ponto de extremidade de escuta do grupo de failover.

Solução alternativa: Solte e recrie o grupo de failover depois de alterar o tipo de conexão.

Procedimento sp_send_dbmail pode falhar transitoriamente quando @query o parâmetro é usado

O procedimento sp_send_dbmail pode falhar transitoriamente quando @query o parâmetro é usado. Quando esse problema ocorre, 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 será propagado.

Esse problema é causado por um bug conhecido relacionado a como sp_send_dbmail está usando representação e pool de conexões.

Para contornar esse problema, use o código wrap para enviar e-mails para uma lógica de repetição que depende do parâmetro @mailitem_idde saída. Se a execução falhar, o valor do parâmetro será NULL, indicando sp_send_dbmail que deve ser chamado mais uma vez para enviar um e-mail com êxito. Aqui está 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 confiança entre instâncias gerenciadas que é pré-requisito para a execução de transações distribuídas. Depois de remover a instância gerenciada 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.

As transações distribuídas não podem ser executadas após a operação de dimensionamento de instância gerenciada

As operações de dimensionamento da Instância Gerenciada 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 de transações distribuídas. Como solução alternativa, exclua e crie um novo Grupo de Confiança do Servidor no portal do Azure.

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 é 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 <name>.database.windows.com 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, use um nome diferente para a Instância Gerenciada SQL ou crie um tíquete de suporte para liberar o nome do servidor lógico.

A entidade de serviço não consegue aceder ao Microsoft Entra ID e 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 são 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 o portal do Azure, acesse a página de administração do Ative Directory da Instância Gerenciada do SQL. Verifique se você pode ver a mensagem de erro "A instância gerenciada precisa de uma entidade de serviço para acessar a ID do Microsoft Entra. Clique aqui para criar uma entidade de serviço". Caso tenha encontrado 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 via portal para grupos de failover

Se um grupo de failover se estender entre instâncias em diferentes assinaturas do Azure ou grupos de recursos, 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 através do portal a partir da instância geosecundária.

As funções do SQL Agent precisam de permissões EXECUTE explícitas para inícios de sessão não sysadmin

Se logons não-sysadmin forem adicionados a qualquer função de banco de dados fixa do SQL Agent, haverá um problema no qual permissões explícitas EXECUTE precisam ser concedidas a três procedimentos armazenados no master banco de dados para que esses logons funcionem. Se esse problema for encontrado, a mensagem The EXECUTE permission was denied on the object <object_name> (Microsoft SQL Server, Error: 229) de erro 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 seguinte script T-SQL 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 Business Critical não aplica corretamente limites máximos de memória para objetos otimizados para memória em alguns casos. A Instância Gerenciada SQL pode permitir que a carga de trabalho use mais memória para operações OLTP na memória, 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 na memória falham mais cedo se atingirem os limites.

Solução alternativa: monitore o uso do armazenamento OLTP na memória 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 errado retornado ao tentar remover um arquivo que não está vazio

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

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 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 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 da camada de serviço não falham nem atingem o tempo limite. Eles 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 mais alta.

O Administrador de Recursos na camada de serviço Crítica para os Negócios pode precisar ser reconfigurado após o failover

O recurso Administrador de Recursos 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 failover ou uma alteração iniciada pelo usuário da camada de serviço (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 instância é iniciada se você estiver usando o Administrador de Recursos.

As caixas de diálogo do Service Broker entre bancos de dados devem ser reinicializadas após a atualização da camada de serviço

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

Solução alternativa: interrompa 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 ficheiros de base de dados pequenos

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.

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 ficheiro de base de dados é colocado num disco físico separado. Os tamanhos dos discos 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 do Disco Premium do Azure não pode exceder os 35 TB. Em alguns casos, uma instância gerida que não necessite do total de 8 TB 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 arquivos, uma instância da Instância Gerenciada do SQL pode atingir o limite de 35 TB reservado para um Disco Premium do Azure anexado, quando você pode não esperar.

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.

Pode identificar o número de ficheiros restantes com as vistas de sistema. Se atingir este limite, tente esvaziar e eliminar alguns dos ficheiros mais pequenos com a instrução DBCC SHRINKFILE ou mude para o escalão Crítico para a Empresa, 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 o modo de exibição para resolver o nome real do banco de dados a partir do nome do banco de dados físico, 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;

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.

Não há suporte para o escopo da transação em dois bancos de dados na mesma instância

(Resolvido em março de 2020) A TransactionScope classe no .NET não funciona se duas consultas são enviadas para dois bancos de dados dentro da mesma instância sob o 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 em um contexto de conexão em vez de usar duas conexões.

Sem resolução

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. Esse login pode ser encontrado no SSMS (no Pesquisador de objetos na seção Segurança, Logons) ou na visualização sys.sysloginsdo sistema. O formato do nome de login é semelhante 'DBxCy\WF-abcde01234QWERT'ao , 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 a um aumento no 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.

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

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.

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 há suporte para a representação de tipos de login do Microsoft Entra

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

• Usuários do Microsoft Entra com alias. O seguinte erro é retornado neste caso: 15517.
• Logins e usuários do Microsoft Entra com base em aplicativos 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 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 Replicação.

tempdb Estrutura e conteúdo são recriados

O tempdb banco de dados é sempre dividido em 12 arquivos de dados, e a estrutura do arquivo não pode ser alterada. O tamanho máximo por arquivo não pode ser alterado e novos arquivos não podem ser adicionados ao tempdb. O tempdb banco de dados é sempre recriado como um banco de dados vazio quando a instância é iniciada ou failover, e quaisquer alterações feitas não tempdb são preservadas.

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.

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

Às vezes, o dimensionamento da instância gerenciada 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 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 geoprimária atual, ou seja, 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 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: "Erro 40532: Não é possível abrir o servidor "xxx.xxx.xxx.xxx" solicitado pelo login. O início de sessão falhou. (Microsoft SQL Server, erro: 40532)".

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

Resolvido

A consulta da tabela externa falha com a mensagem de erro Não suportado

Consultar tabela externa pode falhar com mensagem de erro genérica "Consultas sobre tabelas externas não são suportadas com a camada de serviço atual ou nível de desempenho deste banco de dados. Considere atualizar o escalão de serviço ou o nível de desempenho da base de dados”. O único tipo de tabela externa suportada no Azure SQL Managed Instance são as tabelas externas PolyBase (em pré-visualização). Para permitir consultas em tabelas externas do PolyBase, você precisa habilitar o PolyBase na instância gerenciada executando sp_configure o comando.

Não há suporte para tabelas externas relacionadas ao recurso Consulta Elástica do Banco de Dados SQL do Azure na Instância Gerenciada do SQL, mas a criação e consulta delas não foi explicitamente bloqueada. Com suporte para tabelas externas PolyBase, novas verificações foram introduzidas, bloqueando a consulta de qualquer tipo de tabela externa na instância gerenciada, a menos que o PolyBase esteja habilitado.

Se você estiver usando tabelas externas do Elastic Query sem suporte para consultar dados no Banco de Dados SQL do Azure ou na Sinapse do Azure a partir de sua instância gerenciada, use o recurso Servidor Vinculado. Para estabelecer a conexão do Servidor Vinculado da Instância Gerenciada SQL para o Banco de Dados SQL, siga as instruções deste artigo. Para estabelecer a conexão do Servidor Vinculado da Instância Gerenciada do SQL para o SQL Synapse, verifique as instruções passo a passo. Como configurar e testar a conexão do Servidor Vinculado leva algum tempo, você pode usar uma solução alternativa como uma solução temporária para habilitar a consulta de tabelas externas relacionadas ao recurso Elastic Query:

Solução alternativa: execute os seguintes comandos (uma vez por instância) que habilitam consultas em tabelas externas:

sp_configure 'polybase enabled', 1;
GO

RECONFIGURE;
GO

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

Em determinadas circunstâncias, o backup manual de bancos de dados que foi feito em uma instância gerenciada 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 com CHECKSUM habilitado.

O agente deixa de responder ao modificar, desativar ou habilitar trabalhos existentes

Em determinadas circunstâncias, modificar, desabilitar ou habilitar um trabalho existente pode fazer com que o agente pare de responder. O problema é automaticamente atenuado após a deteção, resultando em uma reinicialização do processo do agente.

Permissões no grupo de recursos não aplicadas à Instância Gerenciada SQL

Quando a função do Azure Colaborador da Instância Gerenciada do SQL é aplicada a um grupo de recursos (RG), ela não é aplicada à Instância Gerenciada 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.

Os trabalhos do SQL Agent podem ser interrompidos pela reinicialização do processo do Agent

(Resolvido em março de 2020) O SQL Agent cria uma nova sessão cada vez que um 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 agente é reiniciado assim que o 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 não suportado no sp_send_db_mail

O @query parâmetro no procedimento sp_send_db_mail não funciona.

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

A página de administração do Ative Directory do portal do Azure para Instância Gerenciada SQL do Azure pode mostrar 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 (anteriormente Azure Ative Directory). Clique aqui para criar uma entidade de serviço"

Você pode negligenciar essa mensagem de erro se a Entidade de Serviço para a instância gerenciada já existir e/ou 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 corporativos 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, a Entidade de Serviço já existe e nenhuma ação adicional é necessária.

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 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 as instruções.

Contribuir para o conteúdo

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

Próximos passos

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.