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 licenças das edições Standard e Enterprise cobertas pelo Software Assurance podem ser alocadas para o Mecanismo de Banco de Dados do SQL Server usando o AHB (Benefício Híbrido do Azure) para a camada de serviço uso geral (que inclui a atualização da camada de serviço uso geral de próxima geração) ou para a camada de serviço Comercialmente Crítico. O Benefício Híbrido do Azure usa as seguintes taxas de troca: 1 Edição Standard = 1 Uso Geral, 1 Edição Enterprise = 1 Business Critical, 1 Edição Enterprise = 4 Uso Geral e 4 Uso Geral = 1 Enterprise Edition. Para obter mais informações, consulte direitos específicos do Benefício Híbrido do Azure.

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 você precisar de uma instância gerenciada de SQL em uma região que não tem suporte no momento, envie uma solicitação de suporte por meio do portal do Azure.

A Instância Gerenciada de SQL tem dois limites padrão: um limite no número de sub-redes que você pode usar e um limite no número de vCores que você pode provisionar. 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 a tabela da limitação de recurso regional. Esses limites suaves 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.

Você pode provisionar uma instância gerenciada de SQL no portal do Azure, no PowerShell, na CLI do Azure e nos modelos do ARM.

Sim, você pode provisionar uma instância gerenciada de SQL em uma assinatura existente se essa assinatura pertencer aos tipos de assinatura com suporte.

Iniciar um nome de sub-rede com um dígito é uma limitação atual de um componente subjacente que verifica o nome da sub-rede no 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.

Você pode dimensionar sua instância gerenciada de SQL no portal do Azure, no PowerShell, na CLI do Azure ou nos modelos do ARM.

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

Você pode excluir instâncias gerenciadas de SQL 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 de SQL ou alterar as camadas 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 a faixa de oferta gratuita reaparecer.

É provável que você tenha ficado sem créditos para o mês. Acesse sua instância gerenciada de SQL no portal do Azure e verifique o estado. Veja 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, examine os tipos de assinatura gratuitos da Instância Gerenciada de SQL.

Não há suporte para alterar um nome de instância gerenciada de SQL.

Sim, a zona .database.windows.net DNS padrão da Instância Gerenciada de SQL pode ser alterada com sua própria. No entanto, a parte do nome do host da instância gerenciada de SQL de seu FQDN, incluindo a subzone aleatória (ex: sqlmiFQDN.randomized-subzone antes do .database.windows.net) deve 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 de host da instância gerenciada de SQL ou o nome de host da instância gerenciada do SQL seguido por um nome de domínio personalizado. A ferramenta CliConfg adiciona um alias no registro HKLM\SOFTWARE\Microsoft\MSSQLServer\Client\ConnectTo em 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). Você também pode adicionar um alias usando a política de grupo ou um script, mas você deve se somar para garantir que 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 de SQL apontando para o nome de domínio do ponto de extremidade VNet-local da instância gerenciada de SQL. Nesse caso, HostNameInCertificate=<VNet-local endpoint domain name> (recomendado) ou TrustServerCertificate=TRUE é necessário ao usar a autenticação do Microsoft Entra.
• Use um registro em DNS com o nome do host da instância gerenciada de SQL apontando para o endereço IP da instância gerenciada de SQL. Não é recomendável usar o endereço IP, pois ele pode ser alterado sem aviso prévio. Nesse caso, HostNameInCertificate=<VNet-local endpoint domain name> (recomendado) ou TrustServerCertificate=TRUE é 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 única instância ou precisar de um recurso com suporte exclusivo na Instância Gerenciada de SQL. Você pode migrar seus dados usando a funcionalidade BACPAC (exportação/importação). 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 abordagem é recomendada se o banco de dados for 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 sobre migração de outras plataformas, consulte os Guias de Migração de Banco de Dados do Azure.

Para uma comparação de desempenho entre a instância gerenciada de SQL e o SQL Server, um bom ponto de partida é o artigo Práticas recomendadas 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.

Você pode otimizar o desempenho da instância gerenciada de SQL:

• 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.

MSSQLSERVER_833 indica que uma solicitação de E/S levou mais de 15 segundos para ser concluída. Esse erro na Instância Gerenciada de SQL do Azure está relacionado às condições gerais de infraestrutura e não à carga de trabalho. Em ambientes de nuvem e sistemas que utilizam o armazenamento remoto, há várias camadas de arquitetura que afetam uma única solicitação de E/S. Esse comportamento é esperado e uma limitação conhecida do serviço que normalmente resulta de problemas transitórios de rede ou recursos de armazenamento do Azure ficando temporariamente indisponíveis. O sistema geralmente se recupera sem intervenção.

Essa ocorrência é rara e não afeta a latência média de solicitações de E/S para o armazenamento remoto. Dependendo da carga de trabalho ou thread que inicia a solicitação de E/S, os clientes podem observar os tempos limite de comando do SQL e a latência aumentada em cenários específicos, enquanto outras pessoas dificilmente sofrerão qualquer impacto. Por exemplo, nem todas as operações de bloco de solicitações de E/S de execução longa, como, por exemplo, o acesso de página com antecedência de leitura geralmente não é afetado.

O uso da atualização da camada de serviço de uso geral de próxima geração pode ajudar a mitigar esse problema, pois melhora o desempenho e a confiabilidade sem custo adicional. Os clientes são incentivados a explorá-lo para melhorar a qualidade do serviço.

Se esse erro ocorrer persistentemente, considere examinar padrões de carga de trabalho, desempenho de armazenamento e configurações de rede. Além disso, considere o uso da camada de serviço Comercialmente Crítica projetada para aplicativos com requisitos de latência de E/S baixos.

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 é possível, as métricas de alerta estão disponíveis apenas para uma instância gerenciada de SQL. As métricas de alerta para bancos de dados individuais em uma instância gerenciada de SQL não estão disponíveis.

O tamanho do armazenamento da Instância Gerenciada de SQL depende da camada de serviço selecionada (Uso Geral, Uso Geral de Próxima 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 espaço de armazenamento da instância gerenciada de SQL. 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 são executados em uma instância gerenciada de SQL, examine a atividade de backup do Monitor.

Sim, você pode criar um backup completo somente cópia no Armazenamento de Blobs do Azure, mas ele só pode ser restaurado para uma instância gerenciada de SQL. Para obter detalhes, consulte backups 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 restauração pontual para mover o banco de dados para outra instância gerenciada de SQL ou alternar 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.

As regras NSG e UDR necessárias são documentadas na configuração de sub-rede auxiliada pelo serviço e definidas automaticamente pelo serviço. Tenha em mente que essas regras são apenas as que precisamos para manter o serviço. Para se conectar a uma instância gerenciada de SQL e usar recursos diferentes, você precisa definir outras regras específicas do recurso e mantê-las.

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. As regras são definidas por meio da funcionalidade chamada configuração de sub-rede auxiliada pelo 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 de SQL for provisionada, você poderá definir o NSG que controla o acesso de entrada à porta 1433. É recomendável que você reduza o 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 é adicionar uma regra 0/0 a uma UDR associada à sub-rede da instância gerenciada de SQL para rotear o tráfego por meio da NVA.

A sub-rede deve ter um número suficiente de endereços IP disponíveis. Para determinar o tamanho da sub-rede de rede virtual 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. Atualmente, não há suporte para colocar uma instância gerenciada de SQL em uma sub-rede que já contém outros tipos de recursos.

Não há suporte para isso. O nome do host de uma instância gerenciada de SQL é mapeado para o balanceador de carga na frente do cluster virtual da instância gerenciada de SQL. Como um cluster virtual pode hospedar várias instâncias gerenciadas, uma conexão não pode ser roteada para a instância gerenciada de SQL adequada sem especificar seu 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, somente pontos de extremidade privados para instâncias gerenciadas de SQL garantem endereços IP estáticos.

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

Por esse motivo, 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 traduzir o tráfego de entrada para o ponto de extremidade privado de uma instância gerenciada de SQL. 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 de SQL.

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 pontos de extremidade locais da VNet, a Instância Gerenciada de SQL usa o número de porta padrão 1433 e, para pontos de extremidade de dados públicos, a Instância Gerenciada de SQL usa o número da porta padrão 3342.

O 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 para emparelhamento de rede virtual global para 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 de rede virtual global com instâncias criadas antes de setembro de 2020, considere configurar uma janela de manutenção. Ou considere mover a instância para uma nova sub-rede. Qualquer opção move 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). Essa configuração também é recomendada localmente.
• 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 de SQL é provisionada pela primeira vez. Não há suporte para alterar o fuso horário de uma instância gerenciada de SQL 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 de SQL com o fuso horário adequado e, em seguida, a execução de um backup e restauração manual, ou o que recomendamos, a execução de uma restauração pontual entre instâncias.

Sim, os clientes podem criar logons que sejam membros da função sysadmin . Os clientes que assumem o privilégio sysadmin também estão assumindo a responsabilidade por operar a instância, o que pode afetar negativamente o compromisso do SLA. Para adicionar um logon à função de servidor sysadmin , consulte a 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, você precisa exportar e importar seus certificados existentes para a Instância Gerenciada de SQL. Em seguida, faça um backup completo do banco de dados e restaure-o para uma instância gerenciada de SQL.

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 se assemelha ao caso de uso de TDE byOK (bring-your-own-key) que também usa a integração do Key Vault para armazenar a chave de criptografia. Se você não quiser usar a chave como um protetor de chave de criptografia e apenas quiser disponibilizar a chave para a Instância Gerenciada de SQL restaurar bancos de dados criptografados, siga as instruções para configurar o TDE 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 para recursos de computação e economize até 33% com as Reservas do Azure benefício. Combine esse benefício com o benefício híbrido do Azure para economias de 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 obter mais informações sobre reservas, consulte de Reservas do Azure.

É 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. Esse requisito é regido por acordos separados que você tem com cada fabricante de ferramentas individual.

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 gratuito alocado, os backups automatizados na Instância Gerenciada de SQL não serão custos adicionais para você e, portanto, serão gratuitos. Exceder o uso do armazenamento de backup acima do espaço livre resulta em custo adicional. 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 Ajustar os custos de armazenamento de backup na Instância Gerenciada de SQL.

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 herda as políticas de plataforma do Azure que são aplicadas às VMs que formam o cluster virtual que contém a instância gerenciada de SQL. No momento, não é possível alterar nenhuma dessas configurações, pois essas configurações são definidas pelo Azure e herdadas pela instância gerenciada de SQL.

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. Você pode 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.

As alterações e os recursos introduzidos na onda de recursos de novembro de 2022 agora estão disponíveis para todas as instâncias por padrão. Como a ação separada para registrar uma instância não é mais necessária, as opções que mencionam a onda de recursos de novembro de 2022 foram removidas do portal do Azure.

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, confira Como criar uma solicitação de suporte do Azure.

Para instâncias dentro de um grupo de failover, a alteração da camada de serviço para, ou a partir, da camada de Uso Geral da Próxima Geração não tem suporte. 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.

No momento, não há suporte para redundância de zona para a camada de serviço uso geral de próxima geração.

Não, atualmente, não há suporte para a atualização da camada de serviço de Uso Geral da Próxima Geração para Pools de Instâncias ou instâncias dentro de um pool.