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 edições Standard e Enterprise cobertas com o Software Assurance podem ser trocadas usando o do Benefício Híbrido do Azure (AHB) do para a Finalidade Geral (que inclui a atualização da camada de serviço de Propósito Geral de , atualmente em visualização) ou a camada de serviço Crítica para os Negócios usando as seguintes relações de troca 1 Edição Standard = 1 Finalidade Geral, 1 Edição Enterprise = 1 Crítica para os Negócios, 1 edição Enterprise = 4 Propósito Geral e 4 Finalidade Geral = 1 Enterprise Edition. Para obter mais informações, consulte Direitos específicos do AHB.

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 em uma região que não é suportada no momento, enviar uma solicitação de suporte por meio do portal do Azure.

A Instância Gerenciada SQL tem dois limites padrão: 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 de limitação de recursos regionais . Trata-se de limites suaves que 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 do portal do Azure, PowerShell, da CLI do Azure e modelos ARM.

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

Esta é uma limitação atual no 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 a partir de do portal do Azure, PowerShell, da 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 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 ou alterar 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 para ver 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 pré-requisitos de oferta Instância Gerenciada SQL gratuita.

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

Sim, a zona DNS padrão da Instância Gerenciada SQL .database.windows.net pode ser alterada com a sua. No entanto, a parte do nome de host da instância gerenciada de seu FQDN 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 ou o nome de host da instância gerenciada seguido por um nome de domínio personalizado. A ferramenta CliConfg apenas adiciona 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 possa ser feito usando a política de grupo ou um script também. Use ambos para garantir que programas de 32 bits e 64 bits possam resolver o alias.
• Use registro de 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 (anteriormente Azure Ative Directory).
• Use um registro no DNS com o nome do host da instância gerenciada apontando para o endereço IP da instância gerenciada. O uso do endereço IP não é recomendado, pois ele pode ser alterado sem aviso prévio. Nesse caso, 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ê quiser consolidar dados em uma única instância ou simplesmente precisar de um recurso suportado exclusivamente na Instância Gerenciada 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 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 é a 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 Guia de Migração do 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 é artigo Práticas recomendadas para comparação de desempenho entre a Instância Gerenciada 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:

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

O uso do de atualização da camada de serviço de uso geral de Next-gen (atualmente em visualização pública) 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 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 Crítica para os Negócios, pois ela foi 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. As métricas de alerta para bancos de dados individuais em uma instância gerenciada 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. 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 foram 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ó poderá ser restaurado para uma instância gerenciada. Para obter detalhes, consulte de backup 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 ou alternar 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.

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

As regras NSG e UDR necessárias são documentadas em de configuração auxiliada por serviço de sub-rede e definidas automaticamente pelo serviço. Por favor, tenha em mente que essas regras são apenas as que precisamos para manter o serviço. Para se conectar à instância gerenciada e usar recursos diferentes, você precisará definir regras adicionais específicas de recursos que você precisa manter.

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. Isso é conseguido por meio da funcionalidade chamada configuração de sub-rede assistida 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 é provisionada, você pode definir o NSG que controla o acesso de entrada à porta 1433. É aconselhável reduzir o 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 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 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 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 é 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 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 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 novode 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 do host da instância gerenciada. O serviço de instância gerenciada 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.

Pela razão acima, 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. 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 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 o ponto de extremidade local de rede virtual, a Instância Gerenciada do SQL usa o número de porta padrão 1433 e, para o ponto 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 (emparelhamento VNet) e 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 (emparelhamento VNet) 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 global de VNet com instâncias criadas antes de setembro de 2020, considerar configurar uma janela de manutenção de ou mover a instância para um novo de sub-rede, pois qualquer uma das opções moverá a instância para um novo cluster virtual que ofereça 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). Isso também é recomendado no local.
• 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 é provisionada pela primeira vez. Não há suporte para alterar o fuso horário de uma instância gerenciada 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 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 de 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 do SQL e, em seguida, fazer um backup completo do banco de dados e restaurá-lo para uma instância gerenciada.

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 de 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 TDEe 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 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 isso 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. Isso é regido por contratos separados que você tem com cada fabricante de ferramenta 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 para você, 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 Ajuste fino de backup no SQL Managed Instance.

Estudos de caso da Instância Gerenciada SQL:

• Komatsu
• KMD
• PowerDETAILS
• Allscripts

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 mantém a instância gerenciada. No momento, não é possível alterar nenhuma dessas configurações, pois elas são definidas pelo Azure e herdadas pela instância gerenciada.

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.

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.

As alterações e os recursos que foram introduzidos na onda de recursos de novembro de 2022 foram integrados à maioria das instâncias e agora 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 a onda de recursos de novembro de 2022 foram removidas do portal do Azure.

A onda de recursos está disponível para instâncias em sub-redes qualificadas. Se você não vir novos recursos, é provável que a sub-rede que contém sua instância gerenciada SQL não esteja qualificada, pois ainda está no processo de registro. As instâncias em sub-redes não inscritas na onda continuam a ver a página Feature Wave 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, ou de, a camada de Propósito Geral de Próxima geração. Você deve primeiro 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, 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.