Este artigo fornece uma lista de verificação rápida com algumas melhores práticas e diretrizes para otimizar o desempenho do SQL Server em VMs (Máquinas Virtuais) do Azure.
Para vídeos sobre os recursos mais recentes para otimizar o desempenho da VM do SQL Server e automatizar o gerenciamento, examine os seguintes vídeos sobre dados expostos:
Durante a execução do SQL Server em máquinas virtuais do Azure, continue usando as mesmas opções de ajuste de desempenho de banco de dados aplicáveis ao SQL Server em ambientes de servidor local. No entanto, o desempenho de um banco de dados relacional em uma nuvem pública depende de muitos fatores, como o tamanho da máquina virtual e a configuração dos discos de dados.
Normalmente, há uma compensação entre a otimização de custos e a otimização de desempenho. Esta série de melhores práticas de desempenho tem como foco obter o melhor desempenho do SQL Server em Máquinas Virtuais do Azure. Se a sua carga de trabalho tem menos demanda, talvez você não precise realizar todas as otimizações recomendadas. Considere suas necessidades de desempenho, custos e padrões de carga de trabalho ao avaliar essas recomendações.
Use imagens do Azure Marketplace para implantar suas VMs do SQL Server à medida que as configurações do SQL Server e as opções de armazenamento são configuradas para um desempenho ideal.
Use tamanhos de VM com 4 ou mais vCPUs.
Use tamanhos de máquina virtual com otimizado para memória para obter o melhor desempenho das cargas de trabalho do SQL Server.
As séries Edsv5 e Msv3 e Mdsv3 oferecem uma taxa ideal de memória para vCore recomendada para cargas de trabalho OLTP.
As VMs da série Mbdsv3 oferecem o melhor desempenho para cargas de trabalho do SQL Server em VMs do Azure. Considere esta série primeiro para cargas de trabalho críticas do OLTP e do SQL Server do data warehouse.
A série Ebdsv5 fornece uma alta taxa de transferência de E/S para vCore, juntamente com uma taxa de memória para vCore de 8:1. Essa série oferece o melhor desempenho de preço para cargas de trabalho do SQL Server em VMs do Azure. Considere essas VMs primeiro para a maioria das cargas de trabalho do SQL Server.
A família da série M oferece VMs com a maior alocação de memória no Azure.
As VMs das séries Mbsv3 e Mbdsv3 fornecem uma alocação de memória alta e a maior taxa de transferência de E/S para vCore dentro da família da série M, juntamente com uma taxa de memória para vCore consistente de pelo menos 8:1.
Inicie ambientes de desenvolvimento com as séries D, B ou Av2 de camada inferior e aumente o seu ambiente ao longo do tempo.
Se disponível, configure os tempdb. A extensão do Agente de IaaS do SQL administra a pasta e as permissões necessárias no reprovisionamento.
Para otimizar o desempenho de armazenamento, planeje obter a IOPS mais alta não armazenada em cache disponível e use o cache de dados como um recurso de desempenho para leituras de dados, evitando a utilização de limite em discos e na máquina virtual.
Ao usar as VMs do SQL Server das séries Ebdsv5 ou Ebsv5, use o SSD Premium v2 para obter o melhor desempenho de preço. Você pode implantar sua VM do SQL Server com o SSD Premium v2 usando o portal do Azure (atualmente em versão prévia).
Coloque os arquivos de dados, log e tempdb em unidades separadas.
Na unidade de dados, use discos P30 e P40 premium ou menores para garantir a disponibilidade do suporte de cache. Ao usar a série de VMs Ebdsv5, use o SSD Premium v2, que fornece melhor relação preço/desempenho para cargas de trabalho que exigem alta taxa de transferência de E/S e IOPS.
Para a unidade de log, planeje o desempenho de capacidade e teste em relação ao custo ao avaliar os discos SSD Premium v2 ou SSD Premium P30 – P80
Se uma latência de armazenamento inferior a um milissegundo for necessária, use os discos SSD Premium v2 ou Discos Ultra do Azure para o log de transações.
Para implantações de máquinas virtuais da série M, considere usar o acelerador de gravação, em vez dos discos ultra do Azure.
Coloque tempdb no disco temporário (o disco temporário é efêmero e assume D:\ como padrão) para a maioria das cargas de trabalho do SQL Server que não fazem parte de uma FCI (instância de cluster de failover) depois de escolher o tamanho ideal da VM.
Se a capacidade da unidade local não for suficiente para tempdb, considere aumentar o tamanho da VM. Confira Políticas de cache de arquivo de dados para obter mais informações.
Para FCIs (instâncias de cluster de failover), coloque tempdb no armazenamento compartilhado.
Se a carga de trabalho da FCI for altamente dependente do desempenho do disco tempdb, usando uma configuração avançada coloque tempdb na unidade SSD efêmera local (D:\ padrão), que não faz parte do armazenamento da FCI. Essa configuração precisa de monitoramento e ação personalizados para garantir que a unidade SSD efêmera local (D:\ padrão) esteja disponível o tempo todo, pois as falhas dessa unidade não disparam uma ação da FCI.
Distribua vários discos de dados do Azure usando Espaços de Armazenamento para aumentar a largura de banda de E/S até os limites da IOPS e de taxa de transferência da máquina virtual de destino.
Defina o cache do host como somente leitura para discos de arquivo de dados.
Defina o cache do host como nenhum para discos de arquivo de log.
Não habilite o cache de leitura/gravação em discos que contêm dados ou arquivos de log do SQL Server.
Sempre interrompa o serviço do SQL Server antes de alterar as configurações de cache do disco.
Ao migrar várias cargas de trabalho diferentes para a nuvem, o Azure Elastic SAN pode ser uma solução de armazenamento consolidada econômica. No entanto, ao usar o Azure Elastic SAN, a obtenção das IOPS e da taxa de transferência desejadas para cargas de trabalho do SQL Server geralmente requer capacidade de superprovisionamento. Embora normalmente não seja apropriado para cargas de trabalho únicas do SQL Server, você pode obter uma solução econômica ao combinar cargas de trabalho de baixo desempenho com o SQL Server.
Para cargas de trabalho de desenvolvimento e teste e arquivamento de backup de longo prazo, considere o uso do armazenamento padrão. Não recomendamos o uso do HDD/SSD Standard para cargas de trabalho de produção.
O bursting de disco baseado em crédito (P1-P20) só deve ser considerado para cargas de trabalho de desenvolvimento/teste menores e sistemas departamentais.
Para otimizar o desempenho de armazenamento, planeje obter a IOPS mais alta não armazenada em cache disponível e use o cache de dados como um recurso de desempenho para leituras de dados, evitando a limitação/utilização de limite em discos e na máquina virtual.
Formate o disco de dados para usar o tamanho da unidade de alocação de 64 KB para todos os arquivos de dados colocados em uma unidade que não seja a unidade D:\ temporária (que tem um padrão de 4 KB). As VMs do SQL Server implantadas por meio do Azure Marketplace são fornecidas com discos de dados formatados com o tamanho da unidade de alocação e a intercalação para o pool de armazenamento definido como 64 KB.
Configure a conta de armazenamento na mesma região da VM do SQL Server.
Desabilite o armazenamento com redundância geográfica (replicação geográfica) do Azure e use o LRS (armazenamento com redundância local) na conta de armazenamento.
Habilite a Avaliação de Melhores Práticas do SQL para identificar possíveis problemas de desempenho e avaliar se a sua VM do SQL Server está configurada para seguir as melhores práticas.
Os recursos e capacidades do SQL Server fornecem métodos de proteção de dados no nível do banco de dados que podem ser combinados com recursos de segurança no nível da infraestrutura. Juntos, esses recursos fornecem defesa em profundidade no nível da infraestrutura para soluções híbridas e baseadas em nuvem. Além disso, com as medidas de segurança do Azure, é possível criptografar dados confidenciais, proteger máquinas virtuais contra vírus e malware, proteger o tráfego de rede, identificar e detectar ameaças, atender aos requisitos de conformidade e fornecer um único método de administração e relatórios para qualquer necessidade de segurança na nuvem híbrida.
Use o Microsoft Defender para SQL para descobrir e atenuar possíveis vulnerabilidades de banco de dados, bem como detectar atividades anormais que possam indicar uma ameaça à sua instância do SQL Server e à camada do banco de dados.
A avaliação de vulnerabilidade é uma parte do Microsoft Defender para SQL que pode descobrir e ajudar a corrigir riscos potenciais em seu ambiente de SQL Server. Ela fornece visibilidade sobre o estado de segurança e inclui etapas acionáveis para resolver problemas de segurança.
Use as VMs confidenciais do Azure para reforçar a proteção dos dados em uso e dos dados inativos contra o acesso do operador do host. As VMs confidenciais do Azure permitem que você armazene com confiança os dados confidenciais na nuvem e atenda a requisitos rígidos de conformidade.
Se você está no SQL Server 2022, considere usar a autenticação do Microsoft Entra para se conectar à instância do SQL Server.
O Assistente do Azure analisa a telemetria de uso e a configuração do recurso e, depois, recomenda soluções que podem ajudar você a melhorar a economia, o desempenho, a alta disponibilidade e a segurança de seus recursos do Azure. Use o Assistente do Azure na máquina virtual, no grupo de recursos ou no nível da assinatura para ajudar a identificar e aplicar as melhores práticas para otimizar as implantações do Azure.
Use o Azure Disk Encryption quando as necessidades de conformidade e segurança exigirem que você criptografe os dados de ponta a ponta usando suas chaves de criptografia, incluindo a criptografia do disco efêmero (localmente conectado temporariamente).
Managed Disks são criptografados no modo inativo por padrão, usando a Criptografia do Serviço de Armazenamento do Azure, em que as chaves de criptografia são chaves gerenciadas pela Microsoft armazenadas no Azure.
As portas de gerenciamento devem ser fechadas em suas máquinas virtuais – abrir as portas de gerenciamento remoto expõe sua VM a um alto nível de risco de ataques baseados na Internet. Estes ataques tentam obter credenciais por força bruta para obter acesso de administrador à máquina.
Use o Azure Bastion em protocolo RDP (Área de Trabalho Remota).
Bloqueie as portas e permita apenas o tráfego de aplicativos necessários usando o Firewall do Azure, que é um firewall gerenciado como serviço (FaaS) que concede/nega acesso ao servidor com base no endereço IP de origem.
Use os Grupos de segurança de aplicativos para agrupar servidores com requisitos de filtragem de porta semelhantes, com funções semelhantes, como servidores Web e servidores de banco de dados.
Para servidores Web e de aplicativos, use a Proteção contra DDoS (negação de serviço distribuído) do Azure. Ataques de DDoS são projetados para sobrecarregar e esgotar recursos de rede, tornando os aplicativos lentos ou sem resposta. É comum que os DDos sejam direcionados às interfaces do usuário. A proteção contra DDoS do Azure corrige o tráfego de rede indesejado, antes de impactar a disponibilidade do serviço
Use as extensões de VM para ajudar a lidar com antimalware, estado desejado, detecção de ameaças, prevenção e correção, a fim de resolver ameaças no sistema operacional, no computador e na rede:
Avalie extensões de terceiros, como o Symantec Endpoint Protection para VM do Windows (/azure/virtual-machines/extensions/symantec)
Use o Azure Policy para criar regras de negócios que possam ser aplicadas ao seu ambiente. As políticas do Azure avaliam os recursos do Azure comparando as propriedades desses recursos em relação às regras definidas no formato JSON.
O Azure Blueprints permite que arquitetos de nuvem e grupos centrais de tecnologia da informação definam um conjunto repetível de recursos do Azure que implementa e adere aos padrões e requisitos de uma organização. Os Azure Blueprints são diferentes das políticas do Azure.
Use o Windows Server 2019 ou o Windows Server 2022 para estar em conformidade com o FIPS com o SQL Server em VMs do Azure.
recursos do SQL Server
Confira uma lista de verificação rápida das práticas recomendadas para definições de configuração do SQL Server ao executar suas instâncias do SQL Server em uma máquina virtual do Azure em produção:
Use o Azure Monitor para coletar, analisar e agir com base nos dados telemétricos de seu ambiente do SQL Server. Isso inclui a identificação de problemas de infraestrutura com o Insights da VM e dados de monitoramento com o Log Analytics para um diagnóstico mais profundo.
Implemente uma solução HADR (alta disponibilidade e recuperação de desastre) que atenda aos seus SLAs de continuidade de negócios, confira as Opções de HADR disponíveis para SQL Server em VMs do Azure.
Use o portal do Azure (suporte + solução de problemas) para avaliar a integridade e o histórico de recursos; envie novas solicitações de suporte quando necessário.
Configuração do HADR
A lista de verificação nesta seção aborda as melhores práticas de HADR para SQL Server em VMs do Azure.
Os recursos de HADR (alta disponibilidade e recuperação de desastre), como o Grupos de Disponibilidade AlwaysOn e a instância de cluster de failover, dependem da tecnologia subjacente de cluster de failover do Windows Server. Examine as melhores práticas para modificar as configurações do HADR para dar melhor suporte ao ambiente de nuvem.
Para o seu cluster do Windows, considere estas práticas recomendadas:
Implante suas VMs do SQL Server em várias sub-redes sempre que possível para evitar a dependência de um Azure Load Balancer ou um DNN (nome de rede distribuída) para rotear o tráfego para a solução de HADR.
Altere o cluster para parâmetros menos agressivos para evitar interrupções inesperadas devido a falhas de rede transitórias ou manutenção da plataforma do Azure. Para saber mais, confira configurações de pulsação e limite. Para o Windows Server 2012 e versões posteriores, use os seguintes valores recomendados:
SameSubnetDelay: 1 segundo
SameSubnetThreshold: 40 pulsações
CrossSubnetDelay: 1 segundo
CrossSubnetThreshold: 40 pulsações
Coloque suas VMs em um conjunto de disponibilidade ou em zonas de disponibilidade diferentes. Para saber mais, confira configurações de disponibilidade da VM.
Use uma única NIC por nó de cluster.
Configure a votação de quorum do cluster para usar um número ímpar de três votos ou mais. Não atribua votos a regiões de DR.
Monitore cuidadosamente os limites de recursos para evitar reinicializações ou failovers inesperados devido a restrições de recursos.
Verifique se o sistema operacional, drivers de SO e SQL Server estão nos builds mais recentes.
Otimize o desempenho para SQL Server em VMs do Azure. Examine as outras seções deste artigo para saber mais.
Reduza ou distribua a carga de trabalho para evitar limites de recursos.
Mova para uma VM ou disco com limites mais altos para evitar restrições.
Para seu grupo de disponibilidade SQL Server ou instância de cluster de failover, considere estas melhores práticas:
Se você estiver enfrentando falhas inesperadas frequentes, siga as melhores práticas de desempenho descritas no restante deste artigo.
Se a otimização do desempenho da VM do SQL Server não resolver os failovers inesperados, considere reduzir o monitoramento do grupo de disponibilidade ou da instância de cluster de failover. No entanto, isso pode não tratar da origem subjacente do problema e pode mascarar os sintomas ao reduzir a probabilidade de falha. Talvez você ainda precise investigar e resolver a causa raiz subjacente. Para o Windows Server 2012 ou superior, use os seguintes valores recomendados:
Tempo limite de concessão: use essa equação para calcular o valor máximo de tempo limite de concessão: Lease timeout < (2 * SameSubnetThreshold * SameSubnetDelay).
Comece com 40 segundos. Se você estiver usando os valores SameSubnetThreshold e SameSubnetDelay reduzidos recomendados anteriormente, não exceda 80 segundos no valor de tempo limite de concessão.
Máximo de falhas em um período especificado: defina esse valor como 6.
Ao usar o VNN (nome da rede virtual) e um Azure Load Balancer para se conectar à solução de HADR, especifique MultiSubnetFailover = true na cadeia de conexão, mesmo que o cluster abranja apenas uma sub-rede.
Se o cliente não der suporte a MultiSubnetFailover = True, poderá ser necessário definir RegisterAllProvidersIP = 0 e HostRecordTTL = 300 para armazenar as credenciais do cliente em cache em caso de durações mais curtas. No entanto, isso pode causar consultas adicionais ao servidor DNS.
Para se conectar à sua solução de HADR usando o nome de rede distribuída (DNN), considere o seguinte:
Você deve usar um driver de cliente que dê suporte ao MultiSubnetFailover = True e esse parâmetro deve estar na cadeia de conexão.
Use uma porta DNN exclusiva na cadeia de conexão ao conectar-se ao ouvinte DNN para um grupo de disponibilidade.
Use uma cadeia de conexão de espelhamento de banco de dados para um grupo de disponibilidade básico para ignorar a necessidade de um balanceador de carga ou DNN.
Valide o tamanho do setor de seus VHDs antes de implantar sua solução de alta disponibilidade para evitar ter E/Ss desalinhadas. Confira KB3009974 para saber mais.
Se o mecanismo de banco de dados do SQL Server, o ouvinte do grupo de disponibilidade Always On ou a investigação de integridade da instância de cluster de failover estiver configurado para usar uma porta entre 49.152 e 65.536 (o intervalo de portas dinâmicas padrão para TCP/IP), adicione uma exclusão para cada porta. Isso impedirá que outros sistemas sejam atribuídos dinamicamente à mesma porta. O exemplo a seguir cria uma exclusão para a porta 59999: netsh int ipv4 add excludedportrange tcp startport=59999 numberofports=1 store=persistent
Solucionar problemas de desempenho
A seguir, temos uma lista dos recursos que ajudam você a solucionar problemas de desempenho do SQL Server.
Administrar uma infraestrutura de banco de dados do SQL Server para bancos de dados relacionais de nuvem, locais e híbridos usando as ofertas de banco de dados relacional do Microsoft PaaS.