Perguntas frequentes sobre a Instância Gerenciada SQL do Azure

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

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

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

Qualquer cliente é elegível para qualquer nível de serviço. As licenças das edições Standard e Enterprise cobertas com Software Assurance podem ser atribuídas ao SQL Server Database Engine utilizando o Azure Hybrid Benefit (AHB) para o nível de serviço Geral (que inclui a atualização do nível de serviço de Uso Geral de Próxima Geração), ou para o nível de serviço Business Critical. O Benefício Híbrido do Azure usa as seguintes taxas de troca: 1 edição Standard = 1 Propósito Geral, 1 edição Enterprise = 1 Business Critical, 1 Enterprise edition = 4 Propósito Geral e 4 Propósito 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 subscrição suportados, consulte Tipos de subscrição suportados.

As instâncias gerenciadas podem ser criadas na maioria das regiões do Azure; consulte Regiões com suporte para Instância Gerenciada SQL. Se você precisar de uma instância gerenciada do SQL em uma região que não é suportada no momento, envie uma solicitação de suporte por meio do portal do Azure.

A Instância Gerenciada 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 regiões. Para obter a lista de limitações de recursos regionais por tipo de assinatura, consulte a tabela de Limitação de recursos regionais. Estes limites flexíveis podem ser aumentados a pedido. Se você precisar provisionar mais instâncias gerenciadas em suas regiões atuais, envie uma solicitação de suporte para aumentar a cota usando o portal do Azure. Para obter mais informações, consulte Aumentos de cota de solicitação para o Banco de Dados SQL do Azure.

O limite de 100 bancos de dados por Instância Gerenciada SQL é um limite rígido que não pode ser alterado nas camadas de serviço de Uso Geral e Crítica de Negócios. Você pode ter até 500 bancos de dados na camada de serviço de uso geral de Next-gen.

Você pode considerar a migração para outros tipos do Azure que se adaptem à sua carga de trabalho: de Hiperescala do Banco de Dados SQL do Azure ou SQL Server em Máquinas Virtuais do Azure.

Você pode considerar a migração para o SQL Server em Máquinas Virtuais do Azure ou Banco de Dados SQL do Azure memória/cpu otimizada.

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

Para obter recursos novos e de visualização, consulte Novidades.

Você pode provisionar uma instância gerenciada SQL a partir do portal do Azure, PowerShell, CLI do Azure e modelos ARM.

Sim, você pode provisionar uma instância gerenciada 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 em relação ao regex:

^[a-zA-Z_][^\\\/\:\*\?\"\<\>\|\`\'\^]*(?<![\.\s])$

Todos os nomes que passam o regex e são nomes de sub-rede válidos são suportados no momento.

Você pode dimensionar sua instância gerenciada SQL a partir do portal do Azure, PowerShell, CLI do Azure ou modelos ARM.

Sim, tu podes. Para obter instruções, consulte Mover recursos entre regiões.

Você pode excluir instâncias gerenciadas SQL por meio do portal do Azure, PowerShell, CLI do Azure ou APIs REST do Resource Manager.

O tempo esperado para criar uma nova instância gerenciada pelo SQL ou para 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, para que seja possível restaurar durante um determinado período de retenção. Se um banco de dados for descartado antes da conclusão de uma operação de backup, a operação de descarte 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 descarte antes de recriar um banco de dados com o mesmo nome. Para obter mais informações, consulte sys.dm_operation_status. Uma vez que o estado da operação mostra Concluído, é possível RESTAURAR ou CRIAR um banco de dados com o mesmo nome.

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

• Se vários bancos de dados forem descartados e criados novamente com o mesmo nome em breve sucessão. Quando um banco de dados é descartado, o backup do tail-end restante do log de transações é feito de forma síncrona antes que a operação de descarte seja concluída, como mostra a imagem:

  de backup de log de cauda

  Não é possível criar um banco de dados com o mesmo nome até que o backup do tail-log seja feito e a operação de descarte seja concluída. A natureza sequencial da operação de drop coloca bancos de dados descartados em breve sucessão em uma fila, o que pode prolongar o processo de descartar os bancos de dados e atrasa a possibilidade de criar novos usando o mesmo nome.

• Se um banco de dados for restaurado e descartado antes que um backup completo seja 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, soltá-lo imediatamente antes da conclusão do backup completo, não será possível descartar o banco de dados e criar outro banco de dados com esse mesmo nome até que o backup completo seja feito e a operação de descarte do banco de dados seja concluída. Dependendo 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 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 reapareça.

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

Esta funcionalidade não está disponível no momento.

Sim, você pode restaurar um de 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 qualquer impacto. O desempenho que você experimenta ao usar a Instância Gerenciada SQL gratuita é idêntico ao desempenho de uma versão de produção da instância.

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

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

Atualmente, a subscrição de Estudante não é elegível. Para assinaturas qualificadas, consulte os tipos de assinatura com suporte da Instância Gerenciada SQL gratuita.

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

Sim, a zona .database.windows.net DNS padrão da Instância Gerenciada SQL pode ser alterada com a sua. No entanto, a parte do nome de host da instância gerenciada SQL de seu FQDN, incluindo a subzona 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 SQL Server Client Network Utility (CliConfg) para definir um alias. Você pode usar apenas o nome de host da instância gerenciada SQL ou o nome de host da instância gerenciada SQL seguido por um nome de domínio personalizado. A ferramenta CliConfg adiciona um alias no registro em HKLM\SOFTWARE\Microsoft\MSSQLServer\Client\ConnectTo ou 'HKLM\SOFTWARE\WOW6432Node\Microsoft\MSSQLServer\Client\ConnectTo, dependendo se você usa 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 deve se ambos para garantir que programas de 32 bits e 64 bits possam resolver o alias.
• Use o registro CNAME no DNS com o nome de host da instância gerenciada SQL apontando para o nome de domínio do ponto de extremidade VNet-local da instância gerenciada 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 no DNS com o nome de host da instância gerenciada SQL apontando para o endereço IP da instância gerenciada SQL. O uso do endereço IP não é recomendado, 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 SQL do Azure oferece os mesmos níveis de desempenho por tamanho de computação e armazenamento que outras opções de implantação do Banco de Dados SQL do Azure. Se você deseja consolidar dados em uma única instância ou precisa de um recurso suportado exclusivamente na Instância Gerenciada SQL. Você pode 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 do SQL:

• Usando fonte de dados externo
• Usando SQLPackage
• Usando BCP

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

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

Para migrar sua instância do SQL Server, consulte SQL Server to Azure SQL Managed Instance Guide.

Para obter informações sobre migração de outras plataformas, consulte Guias de migração do Banco de Dados do Azure.

Para uma comparação de desempenho entre a instância gerenciada do 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 do SQL do Azure e o SQL Server.

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

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

• de ajuste automático que fornece desempenho máximo e cargas de trabalho estáveis por meio de ajuste contínuo de desempenho baseado em IA 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 transacional e fornece insights de negócios mais rápidos.
• Aplicando algumas das práticas recomendadas para o ajuste de aplicativos e bancos de dados.
• Alternar o tipo de conexão de proxy para o modo de redirecionamento para menor latência e maior taxa de transferência, caso sua carga de trabalho consista em 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 do armazenamento em uma instância de uso geral, consulte Diretrizes de práticas recomendadas de armazenamento parade nível de uso geral .

Consulte Analisando estatísticas de espera no SQL Managed Instance. As estatísticas de espera são informações que podem ajudá-lo a entender por que a duração da consulta é longa e identificar as consultas que estão esperando por 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. Este erro na Instância Gerida SQL do Azure está relacionado com as condições gerais da infraestrutura, e não com a carga de trabalho. Em ambientes de nuvem e sistemas que utilizam armazenamento remoto, há várias camadas arquitetônicas 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 de rede transitórios 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 das solicitações de E/S para armazenamento remoto. Dependendo da carga de trabalho ou thread que inicia a solicitação de E/S, os clientes podem observar tempos limite de comando SQL e latência aumentada em cenários específicos, enquanto é improvável que outros sofram qualquer impacto. Por exemplo, nem todas as solicitações de E/S de longa duração bloqueiam operações, como, por exemplo, o acesso à página de leitura antecipada muitas vezes não é afetada.

A utilização da atualização do nível de serviço de uso geral de próxima geração pode ajudar a mitigar este problema, pois melhora o desempenho e a fiabilidade sem custos adicionais. Os clientes são incentivados a explorá-lo para melhorar a qualidade do serviço.

Se esse erro ocorrer persistentemente, considere revisar os padrões de carga de trabalho, o desempenho do armazenamento e as configurações de rede. Além disso, considere o uso da camada de serviço Business Critical projetada para aplicativos com requisitos de baixa latência de E/S.

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

Consulte Monitoramento e ajuste de desempenho.

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

Sim, o SQL Profiler tem suporte na Instância Gerenciada SQL. Para obter mais informações, consulte SQL Profiler. Em vez disso, no entanto, você deve considerar Eventos estendidos para "rastrear" atividades com menos impacto na instância monitorada. Para obter mais informações, consulte Extended Events.

Não, eles não são suportados. Você pode usar DMVs e Query Store juntamente com SQL Profiler e XEvents para monitorar seus bancos de dados.

Consulte Monitorar o uso da CPU no SQL Server e no SQLdo Azure .

Sim. Para obter instruções, consulte Criar alertas para a instância gerenciada SQL. Para obter mais dicas e truques, consulte o blog.

Não é possível, as métricas de alerta estão disponíveis apenas para uma instância gerenciada pelo SQL. As métricas de alerta para bancos de dados individuais em uma instância gerenciada pelo SQL não estão disponíveis.

O tamanho do armazenamento para a Instância Gerenciada SQL depende da camada de serviço selecionada (Finalidade Geral, Finalidade Geral de Próxima Geração ou Crítica para os Negócios). Para conhecer as limitações de armazenamento dessas camadas de serviço, consulte 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, você pode comprar armazenamento complementar, independentemente da computação, até certo ponto. Consulte de armazenamento reservado de instância Max noda Tabela .

Para otimizar o desempenho do armazenamento, consulte Práticas recomendadas de armazenamento emde uso geral .

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

Para controlar quando backups automatizados são executados em uma instância gerenciada pelo SQL, consulte Monitorar a atividade de backup.

Sim, você pode criar um backup completo somente cópia em seu Armazenamento de Blobs do Azure, mas ele só pode ser restaurado para uma instância gerenciada pelo SQL. Para obter detalhes, consulte Backups somente cópia. No entanto, o backup somente cópia é impossível se o banco de dados for criptografado pelo TDE gerenciado pelo serviço, uma vez que o certificado usado para criptografia está inacessível. Nesse caso, use o recurso de restauração point-in-time para mover o banco de dados para outra instância gerenciada pelo SQL ou alterne para a chave gerenciada pelo cliente.

Sim, ele é suportado e está disponível para versões do SQL Server 2005+. Para usar a restauração nativa, carregue seu arquivo de .bak no armazenamento de blob do Azure e execute comandos T-SQL. Para obter mais informações, consulte restauração nativa da 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 SQL do Azure sejam introduzidos que exijam alterações no formato do banco de dados, tornando os backups incompatíveis com a versão mais recente do SQL Server. O acesso a tais recursos requer consentimento explícito.

Os bancos de dados do sistema não são replicados para a instância secundária em um grupo de failover. Portanto, 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 na secundária. Para obter 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 pelo SQL e usar recursos diferentes, você precisa definir outras regras específicas de recursos e mantê-las.

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

A Instância Gerenciada 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 por serviço. Isso é para garantir o fluxo ininterrupto de tráfego de gerenciamento, a fim de cumprir um SLA.

Sim. Você pode analisar o tráfego que vem através do seu grupo de segurança de redes configurando os logs de fluxo do Inspetor de Rede.

Sim. Depois que uma instância gerenciada pelo SQL é provisionada, você pode definir o NSG que controla o acesso de entrada à porta 1433. É aconselhável que você reduza seu intervalo de IP tanto quanto possível.

Não. Isso não é suportado por vários motivos:

• 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 de tráfego para o Armazenamento do Azure seria afetado por restrições de taxa de transferência e latência, portanto, dessa forma, não poderemos fornecer a qualidade e a disponibilidade de serviço esperadas.
• Essas configurações são propensas a erros e não são suportadas.

Sim. A maneira mais simples é adicionar uma regra 0/0 a um UDR associado à sub-rede da instância gerenciada SQL 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 de rede virtual para a Instância Gerenciada do SQL, consulte Determinar o tamanho e o intervalo da sub-rede necessários para a Instância Gerenciada SQL do Azure.

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

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

Não se houver instâncias gerenciadas dentro. Esta é uma limitação da infraestrutura de rede do Azure. Você só tem permissão para adicionar espaço de endereço adicional a uma sub-rede vazia.

Sim. Uma instância gerenciada pelo SQL pode ser movida para outra sub-rede dentro da mesma rede virtual ou em uma rede virtual diferente de forma online. Saiba como mover a Instância Gerenciada SQL do Azure entre sub-redes.

Isso não é necessário. Você pode Criar uma rede virtual para a Instância Gerenciada SQL do Azure ou Configurar uma rede virtual existente para a Instância Gerenciada SQL do Azure.

Não. Atualmente, não oferecemos suporte à colocação de uma instância gerenciada SQL em uma sub-rede que já contém outros tipos de recursos.

Não, isso não é suportado. O nome do host de uma instância gerenciada SQL é mapeado para o balanceador de carga na frente do cluster virtual da instância gerenciada 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 SQL adequada sem especificar seu nome. Para obter mais informações sobre a arquitetura de cluster virtual da Instância Gerenciada SQL, consulte Arquitetura de conectividade de cluster virtual.

Atualmente, apenas pontos de extremidade privados para instâncias gerenciadas 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 pelo SQL 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. 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 de host da instância gerenciada SQL. O serviço de instância gerenciada SQL não fornece suporte a endereços IP estáticos e reserva-se 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 públicos e locais da rede virtual só devem ser acessados por meio de seus nomes de domínio associados. Desencorajamos fortemente confiar na imutabilidade do seu endereço IP, pois fazê-lo pode levar a uma indisponibilidade prolongada enquanto o serviço estiver saudável.

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 frontend e configurar uma regra NAT para converter o tráfego de entrada para o ponto de extremidade privado de uma instância gerenciada pelo 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 SQL.

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

Não, o uso de uma porta personalizada não está disponível. Para pontos de extremidade locais de rede virtual, a Instância Gerenciada do SQL usa o número de porta padrão 1433 e, para pontos de extremidade de dados públicos, a Instância Gerenciada do SQL usa o número de 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 circuitos de Rota Expressa é uma opção alternativa. Se nenhuma das opções for possível em seu ambiente, o único outro método de conectividade será uma conexão VPN Site a Site. Configure a VPN Site a Site usando ade portal do Azure, PowerShellou a CLI do Azure

O suporte para emparelhamento de rede virtual global para clusters virtuais recém-criados foi adicionado à Instância Gerenciada SQL do Azure em 22 de setembro de 2020. Como tal, o emparelhamento de rede virtual é suportado para instâncias gerenciadas criadas em sub-redes vazias após 22 de setembro de 2020. Para instâncias implantadas antes dessa data, o suporte ao emparelhamento é limitado a redes dentro da mesma região devido às restrições de do emparelhamento de rede virtual global. Para obter mais informações, consulte a seção relevante das perguntas frequentes sobre Redes Virtuais do Azure.

Para usar o emparelhamento de rede virtual global com instâncias criadas antes de setembro de 2020, considerando configurar uma janela de manutenção. Ou considere mover a instância para uma nova sub-rede. Qualquer uma das opções move a instância para um novo cluster virtual que oferece suporte ao emparelhamento de rede virtual global.

Consulte como verificar se o emparelhamento de rede virtual global é suportado no cluster virtual se necessário.

Para reduzir quaisquer riscos de exfiltração de dados, recomenda-se que os clientes apliquem um conjunto de configurações e controles de segurança:

• Ative TDE (Transparent Data Encryption) em todos os bancos de dados.
• Desative o Common Language Runtime (CLR). Essa configuração também é recomendada localmente.
• Use somente a autenticação do Microsoft Entra.
• Acesse a instância com uma conta DBA de baixo privilégio.
• Configure o acesso à jumpbox JIT para a conta sysadmin.
• Ative de auditoria SQL e integre-o com mecanismos de alerta.
• Ative de Deteção de Ameaças do pacote Microsoft Defender for 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.
• CREATE EXTERNAL TABLE AS SELECT (CETAS) está desativado por padrão. Para habilitar o CETAS por meio da opção de configuração do servidor allowPolyBaseExport, consulte CREATE EXTERNAL TABLE AS SELECT (CETAS).

Sim. Consulte Resolvendo nomes DNS privados na Instância Gerenciada SQL do Azure.

Sim. Consulte Resolvendo nomes DNS privados na Instância Gerenciada SQL do Azure.

A configuração de fuso horário pode ser definida quando uma instância gerenciada pelo SQL é provisionada pela primeira vez. Não há suporte para alterar o fuso horário de uma instância gerenciada SQL existente. Para obter detalhes, consulte Limitações de fuso horário.

As soluções alternativas incluem a criação de uma nova instância gerenciada pelo 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 point-in-time entre instâncias.

Sim, os clientes podem criar logons que são membros da função sysadmin . Os clientes que assumem o privilégio sysadmin também estão assumindo a responsabilidade pela operação da instância, o que pode afetar negativamente o compromisso de SLA. Para adicionar um logon à função de servidor sysadmin , consulte Autenticação do Microsoft Entra.

Sim, a Instância Gerenciada SQL do Azure dá suporte à Criptografia de Dados Transparente (TDE). Para obter detalhes, consulte Transparent Data Encryption for SQL Managed Instance.

Sim, o cenário Azure Key Vault for BYOK está disponível para a Instância Gerenciada SQL do Azure. Para obter detalhes, consulte Transparent Data Encryption with customer-managed key.

Sim, tu podes. Para migrar um banco de dados SQL Server criptografado, você precisa exportar e importar seus certificados existentes para a Instância Gerenciada SQL. Em seguida, faça um backup completo do banco de dados e restaure-o em uma instância gerenciada pelo SQL.

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

Você pode girar o protetor TDE para Instância Gerenciada SQL usando o Azure Cloud Shell. Para obter instruções, consulte Criptografia de dados transparente na instância gerenciada do SQL usando sua própria chave do Azure Key Vault.

Sim, você não precisa descriptografar seu banco de dados para restaurá-lo para a Instância Gerenciada SQL. Você precisa fornecer um certificado/chave usado como protetor de chave de criptografia no sistema de origem para a Instância Gerenciada do SQL para poder ler dados do arquivo de backup criptografado. Há duas maneiras possíveis de fazê-lo:

• Carregue o protetor de certificado para o SQL Managed Instance. Isso pode ser feito usando apenas o PowerShell. O script de exemplo descreve todo o processo.
• Carregue o protetor de chave assimétrico para o Cofre de Chaves do Azure e aponte a Instância Gerenciada SQL para ele. Essa abordagem se assemelha ao caso de uso do TDE traga sua própria chave (BYOK) que também usa a integração do Cofre da Chave para armazenar a chave de criptografia. Se você não quiser usar a chave como um protetor de chave de criptografia e apenas disponibilizar a chave para a Instância Gerenciada SQL restaurar bancos de dados criptografados, siga as instruções para configurar o BYOK TDE e não marque a caixa de seleção Tornar a chave selecionada o protetor TDE padrão.

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

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

Você pode 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.
• Comprometa-se com uma reserva para recursos de computação e economize até 33% com benefício Reservas do Azure. Combine esse benefício com o benefício do Azure Hybrid para economizar até 82%.
• Economize até 55% em relação aos preços de tabela com de Benefícios de Preços de Desenvolvimento/Teste do Azure que oferece tarifas com desconto para suas cargas de trabalho de desenvolvimento e teste contínuos.

Para ser elegível para o benefício de instância reservada, seu tipo de assinatura deve ser um contrato enterprise (números de oferta: MS-AZR-0017P ou MS-AZR-0148P) ou um contrato individual com preços pré-pagos (números de oferta: MS-AZR-0003P ou MS-AZR-0023P). Para obter mais informações sobre reservas, consulte de Reservas do Azure .

Você pode cancelar, trocar ou reembolsar reservas com certas limitações. Para obter mais informações, consulte Trocas e reembolsos de autoatendimento para Reservas do Azure.

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

Você pode fazer isso usando a solução Microsoft Cost Management. Navegue até Subscrições no portal do Azure e selecione Análise de Custos.

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

Você pode usar ferramentas de cliente compatíveis da Microsoft ou de terceiros para acessar a Instância Gerenciada do SQL e não serão cobrados custos adicionais em sua fatura do Azure. No entanto, se algumas das ferramentas exigirem uma licença, é necessário ter um software licenciado legalmente. Este requisito é regido por contratos separados que tem com cada fabricante de ferramentas individual.

Você obtém a mesma quantidade de espaço livre de armazenamento de backup 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 SQL não terão custo adicional e, portanto, serão gratuitos. Exceder o uso de 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 do para obter detalhes. Mais informações técnicas sobre backups automatizados de Instância Gerenciada SQL estão disponíveis em Consumo de armazenamento de backup explicado.

Você pode monitorar o custo do armazenamento de backup por meio do portal do Azure. Para obter instruções, consulte Monitorar custos para backups automatizados.

Para otimizar os custos de armazenamento de backup, consulte Ajustando os custos de armazenamento de backup na instância gerenciada do SQL.

Para entender melhor os benefícios, custos e riscos associados à implantação da Instância Gerenciada SQL do Azure, há também um estudo da Forrester: The Total Economic Impact of Microsoft Azure SQL Managed Instance databases.

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

Cada login deve definir sua senha ao entrar e alterar sua senha depois que atingir a idade máxima.

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

SELECT *
FROM sys.sql_logins

Depois disso, você pode modificar as configurações de login especificadas executando :

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

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

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

Consulte Planejar eventos de manutenção do Azure no SQL Managed Instance.

As alterações e os recursos que foram introduzidos na onda de recursos de novembro de 2022 agora estão disponíveis para todas as instâncias por padrão. Como não é mais necessário executar uma ação separada para registrar uma instância, 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 SQL ou criar uma nova ideia de melhoria no Fórum de Comentários da Instância Gerenciada SQL. Desta forma, pode contribuir para o desenvolvimento do produto e ajudar-nos a priorizar as nossas potenciais melhorias.

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

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

Não, a atualização da camada de serviço de uso geral de próxima geração não é suportada atualmente para pools de instâncias ou instâncias dentro de um pool.