Perguntas frequentes (FAQ) sobre a Instância Gerenciada de SQL do Azure

Para obter uma lista dos recursos com suporte na Instância Gerenciada de SQL, consulte recursos de Instância Gerenciada de SQL do Azure.

Para obter diferenças na sintaxe e no comportamento entre a Instância Gerenciada de SQL do Azure e o SQL Server, consulte Diferenças de T-SQL do SQL Server.

Para obter as características de hardware disponíveis, veja as Diferenças técnicas em configurações de hardware. Para as camadas de serviço disponíveis e suas características, consulte as Diferenças técnicas entre as camadas de serviço.

Qualquer cliente é qualificado para qualquer camada de serviço. As edições Standard e Enterprise abrangidas pelo Software Assurance podem ser alteradas ao usar o Benefício Híbrido do Azure (AHB) para a camada Uso Geral (que inclui a atualização da camada de serviço Uso Geral de Última Geração, atualmente em preview) ou Comercialmente Crítico usando as seguintes taxas de troca: uma edição Standard = uma camada Uso Geral, uma edição Enterprise = uma camada Comercialmente Crítico, uma edição Enterprise = quatro camadas Uso Geral, e quatro camadas Uso Geral = uma Edição Enterprise. Para obter mais informações, consulte Direitos específicos do AHB.

Para obter a lista de tipos de assinatura com suporte, consulte Tipos de assinatura com suporte.

As Instâncias Gerenciadas podem ser criadas na maioria das regiões do Azure; consulte Regiões com suporte para Instância Gerenciada de SQL. Se precisar de uma Instância Gerenciada em uma região que não tenha suporte atualmente, envie uma solicitação de suporte por meio do portal do Azure.

A Instância Gerenciada de SQL tem dois limites padrão: o limite do número de sub-redes que podem ser usadas e o limite do número de vCores que podem ser provisionados. Os limites variam entre os tipos de assinatura e as regiões. Para obter a lista de limitações de recursos regionais por tipo de assinatura, consulte tabela de Limitação de recursos regionais. Esses são exemplos de limites flexíveis que podem ser aumentados sob demanda. Caso precise provisionar instâncias mais gerenciadas em suas regiões atuais, envie uma solicitação de suporte para aumentar a cota usando o portal do Azure. Para mais informações, consulte Solicitar aumentos de cotas para Banco de Dados SQL do Azure.

O limite de cem bancos de dados por Instância Gerenciada de SQL é um limite rígido que não pode ser alterado nas camadas de serviço Uso Geral e Comercialmente Crítico. É possível ter até 500 bancos de dados na camada de serviço Uso Geral de Última Geração.

É possível considerar a migração para outras variantes do Azure que atendam à sua carga de trabalho: Hiperescala do Banco de Dados SQL do Azure ou SQL Server em Máquinas Virtuais do Azure.

É possível considerar a migração para SQL Server em Máquinas Virtuais do Azure ou para memória/CPU do Banco de Dados SQL do Azure otimizada.

Para defeitos de produto e problemas conhecidos, consulte Problemas conhecidos.

Para a nova versão e versão prévia do recurso, confira Novidades.

É possível provisionar uma instância gerenciada no portal do Azure, no PowerShell, na CLI do Azure e no modelos do ARM.

Sim, será possível provisionar uma instância gerenciada em uma assinatura existente se essa assinatura pertencer aos Tipos de assinatura com suporte.

Essa é uma limitação atual do componente adjacente que verifica nome de sub-rede relacionado ao regex ^[a-zA-Z_][^\/:*?"<>|`'^]*(?<![.\s])$. Todos os nomes que passam o regex e são nomes de sub-rede válidos atualmente têm suporte.

É possível dimensionar sua instância gerenciada no portal do Microsoft Azure, PowerShell, CLI do Azure ou nos modelos de ARM.

Sim, você pode. Para mais instruções, consulte Mover recursos entre regiões.

É possível excluir as instâncias gerenciadas por meio do portal do Azure, do PowerShell, da CLI do Azure ou das APIs REST do Resource Manager.

O tempo esperado para criar uma nova Instância Gerenciada ou alterar a camada de serviço (vCores, armazenamento) depende de vários fatores. Consulte Operações de gerenciamento.

A restauração de cada banco de dados é garantida durante todo o período de retenção definido - até mesmo bancos de dados que foram criados e excluídos após apenas alguns segundos. Quando um banco de dados é criado, excluído ou restaurado, os backups são feitos em intervalos diferentes para preservar os dados e assim tornar possível restaurá-lo durante o período de retenção determinado. Se um banco de dados for removido antes da conclusão de uma operação de backup, a operação de remoção poderá ser bloqueada com o seguinte erro:

Message database 'backup_restore_db_lkg_native_restore' already exists. Choose a different database name.

Para evitar esse erro, verifique o estado da operação de remoção antes de recriar um banco de dados com o mesmo nome. Para obter mais informações, consulte sys.dm_operation_status. Depois que o estado da operação mostrar Concluído, vai ser possível RESTAURAR ou CRIAR um banco de dados com o mesmo nome.

Os seguintes casos de uso comuns provavelmente encontrarão este erro:

• Se vários bancos de dados forem removidos e recriados com o mesmo nome em uma rápida sequência. Quando um banco de dados é removido, é feito o backup da parte final do log de transações que sobrou de forma síncrona antes que a operação de remoção seja finalizada, como mostra a imagem:

  

  Não é possível criar um banco de dados com o mesmo nome enquanto o backup da parte final não for feito e a operação de remoção não estiver concluída. A natureza sequencial da operação de remoção posiciona os bancos de dados removidos em uma rápida sequência em uma fila, o que pode prolongar o processo de remoção dos bancos de dados e atrasa a possibilidade de criar novos bancos de dados usando o mesmo nome.

• Se um banco de dados for restaurado e descartado antes de um backup completo ser criado. Quando um banco de dados é restaurado, a primeira etapa do processo de restauração é fazer um novo backup completo do banco de dados. Se você tentar restaurar um banco de dados e, em seguida, descartá-lo imediatamente antes que o backup completo seja concluído, você não poderá descartar o banco de dados e criar outro com esse mesmo nome até que o backup completo seja feito e que a operação de descarte do banco de dados esteja concluída. A depender do tamanho do banco de dados, o backup completo pode levar horas.

É possível que sua assinatura não esteja qualificada para a Instância Gerenciada de SQL gratuita. Caso contrário, há um limite de uma instância gratuita por assinatura. Você precisa remover uma instância gratuita existente para criar outra. Se você excluiu recentemente sua instância gratuita, pode levar até uma hora para que o banner de oferta gratuita apareça novamente.

É provável que você tenha ficado sem créditos para o mês. Vá para sua instância gerenciada de SQL no portal do Azure e verifique o estado para ver se sua instância está em um estado parado devido a créditos insuficientes.

Essa função não está disponível no momento.

Sim, você pode restaurar um backup automatizado do armazenamento do Azure ou pode Restaurar um backup de banco de dados usando o SQL Server Management Studio (SSMS).

Apesar das limitações de recursos, o SQL Managed gratuito foi projetado para permitir que você teste suas cargas de trabalho sem nenhum impacto. O desempenho que você experimenta ao usar a instância gerenciada de SQL gratuita é idêntica ao desempenho de uma versão de produção da instância.

A Instância Gerenciada de SQL gratuita oferece 4 e 8 opções de vCore. Se sua empresa precisar de uma instância com mais recursos, crie uma Instância Gerenciada de SQL paga de pleno direito.

As opções de backup não podem ser alteradas para a Instância Gerenciada de SQL gratuita.

Atualmente, a assinatura de Estudante é inelegível. Para assinaturas qualificadas, revise os pré-requisitos da oferta de Instância Gerenciada de SQL gratuita.

Não há suporte para a alteração do nome da Instância Gerenciada.

Sim, a zona DNS padrão da Instância Gerenciada de SQL .database.windows.net pode ter seu prefixo alterado. No entanto, a parte do nome do host da instância gerenciada do seu FQDN deverá permanecer a mesma.

Para usar outra zona DNS em vez do padrão, por exemplo, .contoso.com:

• Use o Utilitário de rede do cliente do SQL Server (CliConfg) para definir um alias. Você pode usar apenas o nome do host da instância gerenciada ou o nome do host da instância gerenciada seguido por um nome de domínio personalizado. A ferramenta CliConfg apenas adiciona o alias no registro em "HKLM\SOFTWARE\Microsoft\MSSQLServer\Client\ConnectTo" ou "HKLM\SOFTWARE\WOW6432Node\Microsoft\MSSQLServer\Client\ConnectTo", dependendo se você usar a versão de 64 bits (C:\Windows\System32\cliconfg.exe) ou a versão de 32 bits (C:\Windows\SysWOW64\cliconfg.exe), para que isso também possa ser feito usando a política de grupo ou um script. Use ambos para garantir que os programas de 32 bits e 64 bits possam resolver o alias.
• Use o registro CNAME no DNS com o nome do host da instância gerenciada apontando para o FQDN da instância gerenciada. Nesse caso, TrustServerCertificate=TRUE é necessário ao usar a autenticação com o Microsoft Entra ID (antigo Azure Active Directory).
• Use o registro A no DNS com o nome do host da instância gerenciada apontando para o endereço IP da instância gerenciada. Não é recomendável usar o endereço IP, pois ele pode ser alterado sem aviso prévio. Nesse caso, TrustServerCertificate=TRUE será necessário ao usar a autenticação do Microsoft Entra.

A Instância Gerenciada de SQL do Azure oferece os mesmos níveis de desempenho por computação e tamanho do armazenamento que outras opções de implantação do Banco de Dados SQL do Azure. Se você quiser consolidar dados em uma instância ou se simplesmente precisar de um recurso com suporte exclusivo na Instância Gerenciada de SQL, poderá migrar seus dados usando a funcionalidade de exportação/importação (BACPAC). Aqui estão outras maneiras de considerar a migração do Banco de Dados SQL para a Instância Gerenciada de SQL:

• Usando a Fonte de Dados Externa
• Usando o SQLPackage
• Usando BCP

Uma opção é exportar o banco de dados para um BACPAC e, em seguida, importar o arquivo BACPAC. Essa é a abordagem recomendada caso o banco de dados seja menor que 100 GB.

A replicação transacional poderá ser usada se todas as tabelas no banco de dados tiverem chaves primárias e não houver objetos OLTP na memória do banco de dados.

Para migrar sua instância de SQL Server, confira SQL Server para o Guia de Instância Gerenciada de SQL do Azure.

Para obter informações de migração sobre como migrar de outras plataformas, confira o Guia de Migração de Banco de Dados do Azure.

Para uma comparação de desempenho entre a instância gerenciada e o SQL Server, um bom ponto de partida é o artigoMelhores práticas para comparação de desempenho entre a Instância Gerenciada de SQL do Azure e o SQL Server.

Consulte Principais causas das diferenças de desempenho entre a Instância Gerenciada de SQL e o SQL Server. O tamanho do arquivo de log de transações pode afetar o desempenho do Uso Geral da Instância Gerenciada de SQL. Para obter mais informações, confira Impacto do tamanho do arquivo de log no Uso Geral.

É possível otimizar o desempenho da Instância Gerenciada através de:

• Ajuste automático, que oferece o desempenho ideal e cargas de trabalho estáveis por meio do ajuste contínuo do desempenho baseado em inteligência artificial e aprendizado de máquina.
• OLTP na memória, que melhora a taxa de transferência e a latência em cargas de trabalho de processamento transacionais e fornece informações de negócios mais rápidas.
• Como aplicar algumas das melhores práticas ao ajuste de aplicativo e banco de dados.
• Alternar o tipo de conexão do proxy para o modo de redirecionamento para latência mais baixa e taxa de transferência mais alta, caso a sua carga de trabalho seja composta por muitas transações pequenas.

Para melhorar o desempenho em uma instância de Uso Geral, considere aumentar o tamanho do arquivo de dados. Para otimizar o desempenho de armazenamento em uma instância de Uso Geral, confira Diretrizes de melhores práticas de armazenamento para uma camada de Uso Geral.

Confira Como analisar estatísticas de espera na Instância Gerenciada de SQL. Estatísticas de espera são informações que podem ajudar você a entender por que a duração da consulta é longa e identificar as consultas que estão aguardando algo no mecanismo de banco de dados.

Para todas as opções possíveis para monitorar e alertar sobre o consumo e o desempenho da Instância Gerenciada de SQL, consulte Postagem do blog de opções de monitoramento de Instância Gerenciada de SQL do Azure. Para o monitoramento de desempenho em tempo real da Instância Gerenciada de SQL, consulte Monitoramento de desempenho em tempo real da Instância Gerenciada de SQL do Azure.

Consulte Monitoramento e ajuste de desempenho.

Consulte Monitoramento de desempenho em tempo real da Instância Gerenciada de SQL do Azure.

Sim, há suporte para o SQL Profiler na Instância Gerenciada de SQL. Para obter mais informações, consulte SQL Profiler. Em vez disso, no entanto, você deverá considerar os Eventos Estendidos para "rastreamento" de atividade com menos impacto na instância monitorada. Para obter mais informações, consulte Eventos Estendidos.

Não, não há suporte para eles. É possível utilizar DMVs e Repositório de Consultas junto com o SQL Profiler e o XEvents para monitorar seus bancos de dados.

Confira Monitorar o uso da CPU no SQL Server e no SQL do Azure.

Sim. Para obter instruções, consulte Criar alertas para a Instância Gerenciada de SQL. Para obter mais dicas e truques, confira o blog.

Não. As métricas de alerta estão disponíveis apenas para uma instância gerenciada. As métricas de alerta de bancos de dados individuais na instância gerenciada não estão disponíveis.

O tamanho do armazenamento para a Instância Gerenciada de SQL depende da camada de serviço selecionada (Uso Geral, Uso Geral de Última Geração ou Comercialmente Crítico). Para conhecer as limitações de armazenamento dessas camadas de serviço, confira Limites de recursos.

A quantidade mínima de armazenamento disponível em uma instância é de 32 GB. O armazenamento pode ser adicionado em incrementos de 32 GB até o tamanho máximo de armazenamento. Os primeiros 32 GB são gratuitos.

Sim, é possível comprar o armazenamento complementar, independentemente da computação, até certo ponto. Consulte Armazenamento reservado de instância máxima na tabela.

Para otimizar o desempenho do armazenamento, consulte práticas recomendadas de armazenamento em Uso Geral.

Não, o armazenamento de backup não é deduzido do seu espaço de armazenamento de instância gerenciada. O armazenamento de backup é independente do espaço de armazenamento da instância e não é limitado em tamanho. O armazenamento de Backup do Microsoft Azure é limitado pelo período de tempo para reter o backup dos bancos de dados de instância, configuráveis até 35 dias. Para mais detalhes, consulte Backups automatizados.

Para acompanhar quando os backups automatizados foram feitos em uma instância gerenciada SQL, examine Monitorar a atividade de backup.

Sim, é possível criar um backup completo somente cópia no Armazenamento de Blobs do Azure, mas somente será restaurável para uma instância gerenciada. Para mais detalhes, consulte Backup somente cópia. No entanto, o backup somente cópia será impossível se o banco de dados for criptografado pelo TDE gerenciado pelo serviço, uma vez que o certificado usado para criptografia é inacessível. Nesse caso, use o recurso de recuperação pontual para mover o banco de dados para outra instância gerenciada ou alterne para a chave gerenciada pelo cliente.

Sim, ela possui suporte e está disponível para versões do SQL Server 2005+. Para utilizar a restauração nativa, carregue o arquivo .bak no armazenamento de Blobs do Azure e execute comandos T-SQL. Para obter mais informações, consulte Restauração nativa pela URL.

Sim, mas apenas para o SQL Server 2022, durante o período de suporte base do SQL Server 2022. É possível que, no futuro, alguns recursos da Instância Gerenciada de SQL do Azure talvez sejam introduzidos e que exijam alterações no formato de banco de dados, tornando os backups incompatíveis com a última versão do SQL Server. O acesso a esses recursos requer aceitação explícita.

Os bancos de dados do sistema não são replicados para a instância secundária em um grupo de failover. Portanto, os cenários que dependem de objetos dos bancos de dados do sistema são impossíveis na instância secundária a menos que os objetos sejam criados manualmente nela. Para solução alternativa, consulte Habilitar cenários dependentes do objeto dos bancos de dados do sistema.

Quais são as restrições atuais do NSG de entrada/saída na sub-rede da instância gerenciada?

As regras necessárias de NSG e UDR são documentadas na configuração auxiliada por serviço da sub-rede e definidas automaticamente pelo serviço. Tenha em mente que essas regras são apenas aquilo que precisamos para manter o serviço. Para se conectar à Instância Gerenciada e utilizar recursos diferentes, é preciso definir regras adicionais específicas do recurso, que precisam ser mantidas.

Como posso definir regras de NSG de entrada em portas de gerenciamento?

A Instância Gerenciada de SQL é responsável por definir regras em portas de gerenciamento. Isso é obtido através da funcionalidade chamada configuração de sub-rede auxiliada por serviço. Isso é para garantir o fluxo ininterrupto do tráfego de gerenciamento a fim de atender a um SLA.

Sim. É possível analisar o tráfego proveniente do grupo de segurança de suas redes configurando logs de fluxo do Observador de Rede.

Sim. Depois que uma instância gerenciada for provisionada, será possível definir NSG que controla o acesso de entrada à porta 1433. É aconselhável restringir seu intervalo de IP o máximo possível.

Não. Isso não possui suporte por diversas razões:

• O tráfego de roteamento que representa uma resposta a uma solicitação de gerenciamento de entrada seria assimétrico e não poderia funcionar.
• O roteamento do tráfego para o Armazenamento do Azure seria afetado pelas restrições de taxa de transferência e pela latência. Dessa forma, não poderemos fornecer a qualidade e a disponibilidade esperadas do serviço.
• Essas configurações são propensas a erros e não são suportáveis.

Sim. A maneira mais simples de conseguir isso é adicionar a regra 0/0 a um UDR associado à sub-rede da instância gerenciada para rotear o tráfego por meio do NVA.

A sub-rede deve ter um número suficiente de endereços IP disponíveis. Para determinar o tamanho da sub-rede VNet para a Instância Gerenciada de SQL, consulte Determinar o tamanho e o intervalo de sub-rede necessários para a Instância Gerenciada de SQL do Azure.

Caso não haja endereços IP suficientes na sub-rede em que sua instância gerenciada SQL é provisionada, criar uma sub-rede e mover a instância gerenciada SQL para essa sub-rede. Também sugerimos que a nova sub-rede seja criada com mais endereços IP alocados para que as operações de atualização futuras evitem uma situação semelhante. Saiba como mover a Instância Gerenciada de SQL do Azure entre sub-redes.

Não. Você pode usar ou uma sub-rede vazia ou uma sub-rede que já contenha instâncias gerenciadas.

Não, se houver instâncias gerenciadas contidas. Esta é uma limitação da infraestrutura de rede do Azure. Há permissão apenas para adicionar mais espaço de endereço a uma sub-rede vazia.

Sim. Uma instância gerenciada SQL pode ser movida online para outra sub-rede na mesma rede virtual ou para outra rede virtual. Saiba como mover a Instância Gerenciada de SQL do Azure entre sub-redes.

Isso não é necessário. É possível Criar uma rede virtual para a Instância Gerenciada de SQL do Azure ou Configurar uma rede virtual existente para a Instância Gerenciada de SQL do Azure.

Não. No momento não há suporte para colocar uma instância gerenciada em uma sub-rede que já contenha outros tipos de recursos.

Não há suporte para isso. O nome de host de uma instância gerenciada é mapeado para o balanceador de carga na frente do cluster virtual da instância gerenciada. Como um cluster virtual pode hospedar várias instâncias gerenciadas, uma conexão não pode ser roteada para a Instância Gerenciada apropriada sem especificar o nome. Para obter mais informações sobre a arquitetura de cluster virtual de Instância Gerenciada de SQL, consulte Arquitetura de conectividade de cluster virtual.

Atualmente, apenas pontos de extremidade privados para instâncias gerenciadas garantem endereços IP estáticos.

Em situações raras, mas necessárias, podemos fazer uma migração online de uma instância gerenciada para um novo cluster virtual ou um grupo de máquinas virtuais diferente dentro do cluster virtual, devido a alterações na pilha de tecnologia que visam melhorar a segurança e a confiabilidade do serviço. Migrar para um novo grupo de máquinas virtuais ou cluster virtual resulta na alteração do endereço IP que é mapeado para o nome do host da instância gerenciada. O serviço de instância gerenciada não dá suporte a endereços IP estáticos e se reserva o direito de alterar o endereço IP sem aviso prévio, como parte dos ciclos de manutenção regulares.

Pelo motivo acima, os pontos de extremidade locais e públicos da VNet só devem ser acessados por meio de seus nomes de domínio associados. Desencorajamos fortemente a confiança na imutabilidade de seu endereço IP, pois isso pode levar à indisponibilidade prolongada enquanto o serviço estiver íntegro.

Se você precisar de um endereço IP estático acessível de fora da rede virtual, poderá implantar o Firewall do Azure com um endereço IP público de front-end e configurar uma regra NAT para converter o tráfego de entrada para o ponto de extremidade privado de uma instância gerenciada. Em seguida, configure a resolução DNS ou configure aliases de cliente para que os clientes SQL se conectem ao endereço IP público do firewall por meio do nome de domínio totalmente qualificado da instância gerenciada.

Sim, um ponto de extremidade público pode ser habilitado para habilitar o tráfego de entrada da Internet para acessar a Instância Gerenciada de SQL. Para obter mais informações, confira Usar a Instância Gerenciada de SQL com pontos de extremidade públicos e Configurar um ponto de extremidade público na Instância Gerenciada de SQL.

Não, o uso de uma porta personalizada não está disponível. Para o ponto de extremidade local da VNet, a Instância Gerenciada de SQL usa o número da porta padrão 1433 e para o ponto de extremidade de dados públicos, a Instância Gerenciada de SQL usa o número da porta padrão 3342.

O Emparelhamento VET (emparelhamento de rede virtual) global e a WAN Virtual do Azure são métodos recomendados para conectar duas instâncias gerenciadas em regiões diferentes. O emparelhamento de circuito do ExpressRoute é uma opção alternativa. Se nenhuma das opções for possível no seu ambiente, o único outro método de conectividade será uma conexão VPN site a site. Configurar uma VPN site a site usando o portal do Azure, o PowerShell ou a CLI do Azure

O suporte ao emparelhamento VNet (emparelhamento de rede virtual) global em clusters virtuais recém-criados foi adicionado à Instância Gerenciada de SQL do Azure em 22 de setembro de 2020. Portanto, há suporte ao emparelhamento de rede virtual nas instâncias gerenciadas criadas em sub-redes vazias após 22/09/2020. Para as instâncias implantadas antes dessa data, o suporte ao emparelhamento é limitado às redes na mesma região devido às restrições do emparelhamento de rede virtual global. Para obter mais informações, confira a seção relevante das Perguntas frequentes sobre as Redes Virtuais do Azure.

Para usar o emparelhamento VNet global com instâncias criadas antes de setembro 2020, considerar a possibilidade de configurar uma janela de manutenção ou de mover a instância para uma nova sub-rede, pois qualquer uma dessas opções moverá a instância para um novo cluster virtual que dá suporte ao emparelhamento de rede virtual global.

Confira como verificar se há suporte ao emparelhamento de rede virtual global no cluster virtual, se necessário.

Para reduzir os riscos de vazamento de dados, é recomendável que os clientes apliquem um conjunto de configurações e controles de segurança:

• Ative a Transparent Data Encryption (TDE) em todos os bancos de dados.
• Desative o CLR (Common Language Runtime). Isso também é recomendado no local.
• Use somente a autenticação do Microsoft Entra.
• Acesse a instância com uma conta de DBA com poucos privilégios.
• Configure o acesso ao JIT jumpbox para a conta sysadmin.
• Ative a auditoria do SQL e integre-a nos mecanismos de alerta.
• Ative a Detecção de Ameaças do pacote do Microsoft Defender para SQL.
• Aplique uma política de ponto de extremidade de serviço à sub-rede para controlar o tráfego de saída para o Armazenamento do Azure.
• CETAS (CREATE EXTERNAL TABLE AS SELECT) está desabilitado por padrão. Para habilitar a CETAS por meio da opção de configuração do servidor allowPolyBaseExport, consulte CREATE EXTERNAL TABLE AS SELECT (CETAS).

Sim. Confira Resolver nomes DNS privados na Instância Gerenciada de SQL do Azure.

Sim. Confira Resolver nomes DNS privados na Instância Gerenciada de SQL do Azure.

A configuração de fuso horário pode ser definida quando uma instância gerenciada é provisionada pela primeira vez. Não há suporte para a alteração do fuso horário de uma Instância Gerenciada existente. Para mais detalhes, consulte Limitações de fuso horário.

As soluções alternativas incluem a criação de uma nova Instância Gerenciada com o fuso horário adequado. Em seguida, execute um backup e restauração manual ou, o que é recomendável, execute uma restauração pontual de instância cruzada.

Sim, os clientes podem criar logins que compõe a função sysadmin. Os clientes que assumem o privilégio sysadmin também pressupõem a responsabilidade de operar a instância, o que pode afetar negativamente o compromisso do SLA. Para adicionar um logon à função de servidor sysadmin, confira Autenticação do Microsoft Entra.

Sim, a Instância Gerenciada de SQL do Azure dá suporte à TDE (Transparent Data Encryption). Para detalhes, consulte Transparent Data Encryption para Instância Gerenciada de SQL.

Sim, o Azure Key Vault para o cenário BYOK está disponível para a Instância Gerenciada de SQL do Azure. Para detalhes, consulte Transparent Data Encryption com chave gerenciada pelo cliente.

Sim, você pode. Para migrar um banco de dados criptografado do SQL Server, será necessário exportar e importar os certificados existentes para a Instância Gerenciada de SQL, fazer um backup completo do banco de dados e restaurá-lo em uma instância gerenciada.

Você também pode utilizar o Serviço de Migração de Banco de Dados do Azure para migrar os bancos de TDE criptografados.

Você pode alternar o protetor de TDE para a Instância Gerenciada de SQL usando o Azure Cloud Shell. Para obter instruções, consulte Transparent Data Encryption em uma Instância Gerenciada de SQL usando sua própria chave do Azure Key Vault.

Sim, não é preciso descriptografar seu banco de dados para restaurá-lo na Instância Gerenciada de SQL. É necessário fornecer um certificado/chave usado como protetor de chave de criptografia no sistema de origem para a Instância Gerenciada de SQL para poder ler dados do arquivo de backup criptografado. Há duas maneiras possíveis de fazer isso:

• Carregar o protetor de certificado para a Instância Gerenciada de SQL. Isso só pode ser feito usando o PowerShell. O script de exemplo descreve todo o processo.
• Carregue o protetor de chave assimétrica em Azure Key Vault e aponte para ele a Instância Gerenciada de SQL. Essa abordagem é semelhante ao caso de uso da TDE do BYOK (traga sua própria chave), que também usa a integração do Key Vault para armazenar a chave de criptografia. Caso não queira utilizar a chave como um protetor de chave de criptografia e apenas quiser disponibilizar a chave para a Instância Gerenciada de SQL para restaurar bancos de dados criptografados, siga as instruções para configurar o TDE do BYOK e não marque a caixa de seleção Tornar a chave selecionada o protetor de TDE padrão.

Depois de disponibilizar o protetor de criptografia para a Instância Gerenciada de SQL, pode prosseguir com o procedimento de restauração do banco de dados padrão.

A Instância Gerenciada de SQL oferece um modelo de compra baseado em vCore.

É possível economizar custos com os benefícios do SQL do Azure das seguintes maneiras:

• Maximize os investimentos existentes em licenças locais e economize até 55% com Benefício Híbrido do Azure.
• Confirme uma reserva de recursos de computação e economize até 33% com Benefício de Instância Reservada. Combine isso com o benefício Híbrido do Azure para economizar até 82%.
• Economize até 55% versus preços de lista com o Benefício de Preço de Desenvolvimento/Teste do Azure que oferece tarifas com desconto para suas cargas de trabalho de desenvolvimento e teste em andamento.

Para se qualificar para o benefício da instância reservada, o tipo de assinatura deve ser um Enterprise Agreement (números de oferta: MS-AZR-0017P ou MS-AZR-0148P) ou um contrato individual com preço pago conforme o uso (números de oferta: MS-AZR-0003P ou MS-AZR-0023P). Para mais informações sobre reservas, consulte Benefício da Instância Reservada.

É possível cancelar, trocar ou reembolsar reservas com determinadas limitações. Para saber mais, confira Trocas e reembolsos via autoatendimento para Reservas do Azure.

Para explorar as opções de preços da Instância Gerenciada de SQL, consulte Página de preços.

Você pode fazer isso usando a Solução de Gerenciamento de Custos da Microsoft. Navegue até Assinaturas no portal do Azure e selecione Análise de Custo.

Use a opção Custos acumulados e, em seguida, filtre pelo Tipo de recurso como microsoft.sql/managedinstances.

É possível usar ferramentas de cliente ou de terceiros compatíveis da Microsoft para acessar a Instância Gerenciada de SQL, e nenhum custo adicional será cobrado na sua fatura do Azure. No entanto, se algumas das ferramentas exigirem uma licença, você é obrigado a ter uma licença legítima do software. Isso é regido por contratos separados que você tem com cada fabricante de ferramentas.

Você obtém a mesma quantidade de espaço de armazenamento de backup livre que o espaço de armazenamento de dados reservado adquirido, independentemente do período de retenção de backup definido. Se o consumo de armazenamento de backup estiver dentro do espaço de armazenamento de backup livre alocado, os backups automatizados na Instância Gerenciada de SQL não têm nenhum custo adicional para você, portanto, serão gratuitos. Exceder o uso do armazenamento de backup acima do espaço livre resulta em custos adicionais. Consulte a seção Armazenamento de backup da página de preços para ver detalhes. Mais informações técnicas sobre backups automatizados da Instância Gerenciada de SQL estão disponíveis em Consumo de armazenamento de backup explicado.

É possível monitorar o custo de armazenamento de backup por meio de portal do Azure. Para instruções, consulte Monitorar custos de backups automatizados.

Para otimizar os custos de armazenamento de backup, consulte Ajuste fino de backup na Instância Gerenciada de SQL.

Estudos de caso da Instância Gerenciada de SQL:

• Komatsu
• KMD
• PowerDETAILS
• Allscripts

Para entender melhor os benefícios, os custos e os riscos associados à implantação da Instância Gerenciada de SQL do Azure, há também um estudo da Forrester: O impacto econômico total dos bancos de dados de Instância Gerenciada de SQL do Microsoft Azure.

A política de senha da Instância Gerenciada de SQL para logons do SQL herdam as políticas da plataforma do Azure que são aplicadas às VMs que formam o cluster virtual que mantém a Instância Gerenciada. No momento não é possível alterar essas configurações, pois elas são definidas pelo Azure e herdadas pela Instância Gerenciada.

Cada logon deverá definir a senha ao entrar e alterá-la após atingir a idade máxima.

Sim, é possível controlar os campos CHECK_POLICY e CHECK_EXPIRATION no nível de logon. É possível verificar as configurações atuais executando o seguinte comando T-SQL:

SELECT *
FROM sys.sql_logins

Depois disso, é possível modificar as configurações de logon especificadas executando:

ALTER LOGIN <login_name> WITH CHECK_POLICY = OFF;
ALTER LOGIN <login_name> WITH CHECK_EXPIRATION = OFF;

(Substitua 'test' pelo nome de logon desejado e ajuste os valores de política e expiração.)

Consulte Rotação de certificado para Banco de Dados SQL do Azure e Instância Gerenciada de SQL.

Consulte Planejar eventos de manutenção do Azure na Instância Gerenciada de SQL.

Você pode votar em um novo recurso de Instância Gerenciada de SQL ou criar uma nova ideia de aperfeiçoamento no Fórum de comentários da Instância Gerenciada de SQL. Dessa forma, é possível contribuir para o desenvolvimento do produto e nos ajudar a priorizar nossas possíveis melhorias.

Para saber como criar uma solicitação de Suporte do Azure, consulte Como criar uma solicitação de suporte do Azure.

As alterações e as capacidades lançadas no ciclo de recursos de novembro de 2022 estão integrados à maioria das instâncias e já estão disponíveis por padrão. Como não é mais necessário executar uma ação separada para registrar uma instância, as opções que mencionam o ciclo de recursos de novembro de 2022 foram removidas do portal do Azure.

O ciclo de recursos está disponível para instâncias em sub-redes qualificadas. Se você não estiver vendo novos recursos, é provável que a sub-rede que contém sua instância gerenciada de SQL não esteja qualificada, pois ainda está no processo de registro. As instâncias em sub-redes não registradas no ciclo continuam vendo a página Ciclo de Recursos no Portal do Azure.

Para instâncias dentro de um grupo de failover, não há suporte para alterar a camada de serviço para a (ou da) camada de Uso Geral de Última Geração. Primeiro, você deve excluir o grupo de failover antes de modificar qualquer réplica e, em seguida, recriar o grupo de failover depois que a alteração entrar em vigor.

Atualmente, a redundância de zona não tem suportepara a camada de serviço Uso Geral de Última Geração.

Não, o upgrade da camada de serviço Uso Geral de Última Geração não tem suporte atualmente para Pools de Instâncias ou instâncias dentro de um pool.