Práticas recomendadas do SQL Server para otimizar o desempenho no Azure Stack Hub
Este artigo fornece as práticas recomendadas do SQL Server para otimizar o SQL Server e melhorar o desempenho em máquinas virtuais (VMs) do Microsoft Azure Stack Hub. Ao executar o SQL Server em VMs do Azure Stack Hub, use as mesmas opções de ajuste de desempenho do banco de dados aplicáveis ao SQL Server em um ambiente de servidor local. O desempenho de um banco de dados relacional em uma nuvem do Azure Stack Hub depende de muitos fatores, incluindo o tamanho da família de uma VM e a configuração dos discos de dados.
Ao criar imagens do SQL Server, considere provisionar suas VMs no portal do Azure Stack Hub. Baixe a extensão IaaS do SQL do Marketplace Management no portal do administrador do Azure Stack Hub e baixe as imagens de VM do SQL Server que você escolher. Estes incluem o SQL Server 2016 SP1, o SQL Server 2016 SP2 e o SQL Server 2017.
Nota
Embora o artigo descreva como provisionar uma VM do SQL Server usando o portal global do Azure, a orientação também se aplica ao Azure Stack Hub com as seguintes diferenças: O SSD não está disponível para o disco do sistema operacional e há pequenas diferenças na configuração de armazenamento.
Nas imagens de VM, para o SQL Server, você só pode usar traga sua própria licença (BYOL). Para o Windows Server, o modelo de licença padrão é o pagamento conforme o uso (PAYG). Para obter informações detalhadas sobre o modelo de licença do Windows Server na VM, consulte o artigo Perguntas frequentes sobre o Windows Server no Azure Stack Hub Marketplace.
Obter o melhor desempenho para o SQL Server em VMs do Azure Stack Hub é o foco deste artigo. Se sua carga de trabalho for menos exigente, talvez você não precise de todas as otimizações recomendadas. Considere suas necessidades de desempenho e padrões de carga de trabalho ao avaliar essas recomendações.
Nota
Para obter orientações de desempenho para o SQL Server em VMs do Azure, consulte este artigo.
Lista de verificação para práticas recomendadas do SQL Server
A lista de verificação a seguir é para o desempenho ideal do SQL Server em VMs do Azure Stack Hub:
Área | Otimizações |
---|---|
Tamanho da VM | DS3 ou superior para SQL Server Enterprise edition. DS2 ou superior para SQL Server Standard edition e Web edition. |
Armazenamento | Use uma família de VMs que ofereça suporte ao armazenamento Premium. |
Discos | Use um mínimo de dois discos de dados (um para arquivos de log e outro para arquivo de dados e TempDB) e escolha o tamanho do disco com base em suas necessidades de capacidade. Defina os locais de arquivo de dados padrão para esses discos durante a instalação do SQL Server. Evite usar o sistema operacional ou discos temporários para armazenamento ou registro em log do banco de dados. Distribua vários discos de dados do Azure para obter maior taxa de transferência de E/S usando Espaços de Armazenamento. Formato com tamanhos de alocação documentados. |
E/S | Ative a inicialização instantânea de ficheiros para os ficheiros de dados. Limite o crescimento automático nos bancos de dados com incrementos fixos razoavelmente pequenos (64 MB-256 MB). Desative a redução automática no banco de dados. Configure os locais padrão dos arquivos de backup e banco de dados em discos de dados, não no disco do sistema operacional. Habilite páginas bloqueadas. Aplique service packs e atualizações cumulativas do SQL Server. |
Características específicas | Faça backup diretamente no armazenamento de blob (se suportado pela versão do SQL Server em uso). |
Para obter mais informações sobre como e por que fazer essas otimizações, revise os detalhes e as orientações fornecidas nas seções a seguir.
Documentação de orientação dos tamanhos de VM
Para aplicativos sensíveis ao desempenho, os seguintes tamanhos de VM são recomendados:
SQL Server Enterprise edition: DS3 ou superior
SQL Server Standard edition e Web edition: DS2 ou superior
Com o Azure Stack Hub, não há diferença de desempenho entre as séries da família DS e DS_v2 VM.
Orientações de armazenamento
As VMs da série DS (juntamente com a série DSv2) no Azure Stack Hub fornecem o disco máximo do sistema operacional e a taxa de transferência de disco de dados (IOPS). Uma VM da série DS ou DSv2 fornece até 1.000 IOPS para o disco do sistema operacional e até 2.300 IOPS por disco de dados, independentemente do tipo ou tamanho do disco escolhido.
A taxa de transferência do disco de dados é determinada exclusivamente com base na série da família VM. Você pode consultar este artigo para identificar a taxa de transferência do disco de dados por série de família de VMs.
Nota
Para cargas de trabalho de produção, selecione uma VM da série DS ou DSv2 para fornecer o máximo possível de IOPS no disco do sistema operacional e nos discos de dados.
Ao criar uma conta de armazenamento no Azure Stack Hub, a opção de replicação geográfica não tem efeito porque esse recurso não está disponível no Azure Stack Hub.
Orientação de discos
Há três tipos de disco principais em uma VM do Azure Stack Hub:
Disco do sistema operacional: quando você cria uma VM do Azure Stack Hub, a plataforma anexa pelo menos um disco (rotulado como unidade C ) à VM do disco do sistema operacional. Este disco é um VHD armazenado como um blob de página no armazenamento.
Disco temporário: as VMs do Azure Stack Hub contêm outro disco chamado disco temporário (rotulado como unidade D ). Este é um disco no nó que pode ser usado para espaço de rascunho.
Discos de dados: você pode anexar discos adicionais à sua VM como discos de dados, e esses discos são armazenados no armazenamento como blobs de página.
As seções a seguir descrevem recomendações para usar esses discos diferentes.
Disco do sistema operativo
Um disco do sistema operacional é um VHD que você pode inicializar e montar como uma versão em execução de um sistema operacional e é rotulado como unidade C .
Disco temporário
A unidade de armazenamento temporário, rotulada como unidade D , não é persistente. Não armazene quaisquer dados que não esteja disposto a perder na unidade D . Isso inclui seus arquivos de banco de dados de usuário e arquivos de log de transações de usuário.
Recomendamos armazenar o TempDB em um disco de dados, pois cada disco de dados fornece um máximo de até 2.300 IOPS por disco de dados.
Discos de dados
- Use discos de dados para arquivos de dados e de log. Se você não estiver usando striping de disco, use dois discos de dados de uma VM que ofereça suporte ao armazenamento Premium, onde um disco contém os arquivos de log e o outro contém os dados e os arquivos TempDB. Cada disco de dados fornece um número de IOPS dependendo da família de VMs, conforme descrito em Tamanhos de VM com suporte no Azure Stack Hub. Se você estiver usando uma técnica de distribuição de disco, como Espaços de Armazenamento, coloque todos os dados e arquivos de log na mesma unidade (incluindo TempDB). Essa configuração oferece o número máximo de IOPS disponíveis para o SQL Server consumir, independentemente do arquivo que precisa delas em um determinado momento.
Nota
Ao provisionar uma VM do SQL Server no portal, você tem a opção de editar sua configuração de armazenamento. Dependendo da sua configuração, o Azure Stack Hub configura um ou mais discos. Vários discos são combinados em um único pool de armazenamento. Os arquivos de dados e de log residem juntos nessa configuração.
Distribuição de disco: para obter mais taxa de transferência, você pode adicionar discos de dados adicionais e usar a distribuição de disco. Para determinar o número de discos de dados necessários, analise o número de IOPS necessárias para seus arquivos de log e para seus dados e arquivos TempDB. Observe que os limites de IOPS são por disco de dados com base na família de séries de VM e não no tamanho da VM. Os limites de largura de banda da rede, no entanto, são baseados no tamanho da VM. Consulte as tabelas sobre tamanhos de VM no Azure Stack Hub para obter mais detalhes. Utilize as seguintes diretrizes:
Para o Windows Server 2012 ou posterior, use os Espaços de Armazenamento com as seguintes diretrizes:
Defina o interleave (tamanho de distribuição) como 64 KB (65.536 bytes) para cargas de trabalho OLTP (processamento de transações online) e 256 KB (262.144 bytes) para cargas de trabalho de data warehousing para evitar impacto no desempenho devido ao desalinhamento de partições. Isso deve ser definido com o PowerShell.
Definir contagem de colunas = número de discos físicos. Use o PowerShell ao configurar mais de oito discos (não a interface do usuário do Gerenciador do Servidor).
Por exemplo, o PowerShell a seguir cria um novo pool de armazenamento com o tamanho de interleave definido como 64 KB e o número de colunas como 2:
$PoolCount = Get-PhysicalDisk -CanPool $True $PhysicalDisks = Get-PhysicalDisk | Where-Object {$_.FriendlyName -like "*2" -or $_.FriendlyName -like "*3"} New-StoragePool -FriendlyName "DataFiles" -StorageSubsystemFriendlyName "Storage Spaces*" -PhysicalDisks $PhysicalDisks | New-VirtualDisk -FriendlyName "DataFiles" -Interleave 65536 -NumberOfColumns 2 -ResiliencySettingName simple -UseMaximumSize |Initialize-Disk -PartitionStyle GPT -PassThru |New-Partition -AssignDriveLetter -UseMaximumSize |Format-Volume -FileSystem NTFS -NewFileSystemLabel "DataDisks" -AllocationUnitSize 65536 -Confirm:$false
Determine o número de discos associados ao pool de armazenamento com base nas expectativas de carga. Lembre-se de que tamanhos de VM diferentes permitem números diferentes de discos de dados anexados. Para obter mais informações, consulte Tamanhos de VM suportados no Azure Stack Hub.
Para obter o máximo possível de IOPS para discos de dados, a recomendação é adicionar o número máximo de discos de dados suportados pelo tamanho da VM e usar o striping de disco.
Tamanho da unidade de alocação NTFS: Ao formatar o disco de dados, recomendamos que você use um tamanho de unidade de alocação de 64 KB para arquivos de dados e de log, bem como para o TempDB.
Práticas de gerenciamento de disco: ao remover um disco de dados, pare o serviço SQL Server durante a alteração. Além disso, não altere as configurações de cache nos discos, pois isso não fornece melhorias de desempenho.
Aviso
A falha ao parar o Serviço SQL durante essas operações pode causar corrupção do banco de dados.
Orientação de E/S
Considere habilitar a inicialização instantânea de arquivos para reduzir o tempo necessário para a alocação inicial de arquivos. Para aproveitar a inicialização instantânea de arquivos, conceda a conta de serviço do SQL Server (MSSQLSERVER) com SE_MANAGE_VOLUME_NAME e adicione-a à diretiva de segurança Executar tarefas de manutenção de volume. Se você estiver usando uma imagem de plataforma do SQL Server para o Azure, a conta de serviço padrão (NT Service\MSSQLSERVER) não será adicionada à política de segurança Executar Tarefas de Manutenção de Volume . Em outras palavras, a inicialização instantânea de arquivos não está habilitada em uma imagem da plataforma Azure do SQL Server. Depois de adicionar a conta de serviço do SQL Server à diretiva de segurança Executar Tarefas de Manutenção de Volume , reinicie o serviço do SQL Server. Pode haver considerações de segurança para usar esse recurso. Para obter mais informações, consulte Inicialização do arquivo de banco de dados.
O crescimento automático é uma contingência para um crescimento inesperado. Não gerencie seus dados e registre o crescimento no dia a dia com o crescimento automático. Se o crescimento automático for usado, aumente previamente o arquivo usando a opção Tamanho .
Certifique-se de que a redução automática está desativada para evitar sobrecarga desnecessária que pode afetar negativamente o desempenho.
Configure os locais padrão dos arquivos de backup e banco de dados. Use as recomendações neste artigo e faça as alterações na janela Propriedades do servidor. Para obter instruções, consulte Exibir ou alterar os locais padrão para dados e arquivos de log (SQL Server Management Studio). A captura de tela a seguir mostra onde fazer essas alterações:
Habilite páginas bloqueadas para reduzir E/S e quaisquer atividades de paginação. Para obter mais informações, consulte Ativar a opção Bloquear páginas na memória (Windows).
Considere compactar quaisquer arquivos de dados ao transferir entrada/saída do Azure Stack Hub, incluindo backups.
Orientação específica para recursos
Algumas implantações podem obter benefícios adicionais de desempenho usando técnicas de configuração mais avançadas. A lista a seguir destaca alguns recursos do SQL Server que podem ajudá-lo a obter um melhor desempenho:
Faça backup no armazenamento do Azure. Ao fazer backups para o SQL Server em execução em VMs do Hub de Pilha do Azure, você pode usar o Backup do SQL Server para URL. Esse recurso está disponível a partir do SQL Server 2012 SP1 CU2 e é recomendado para backup nos discos de dados anexados.
Ao fazer backup ou restaurar usando o armazenamento do Azure, siga as recomendações fornecidas em Práticas recomendadas de Backup do SQL Server para URL e Solução de problemas e restauração de backups armazenados no Microsoft Azure. Você também pode automatizar esses backups usando o Backup Automatizado para SQL Server em VMs do Azure.
Faça backup no armazenamento do Azure Stack Hub. Você pode fazer backup no armazenamento do Hub de Pilha do Azure de maneira semelhante ao backup no Armazenamento do Azure. Ao criar um backup dentro do SQL Server Management Studio (SSMS), você precisa inserir as informações de configuração manualmente. Não é possível usar o SSMS para criar o contêiner de armazenamento ou a Assinatura de Acesso Compartilhado. O SSMS só se conecta a assinaturas do Azure, não a assinaturas do Azure Stack Hub. Em vez disso, você precisa criar a conta de armazenamento, o contêiner e a Assinatura de Acesso Compartilhado no portal do Azure Stack Hub ou com o PowerShell.
Nota
A Assinatura de Acesso Compartilhado é o token SAS do portal do Azure Stack Hub, sem a entrelinha '?' na cadeia de caracteres. Se você usar a função de cópia do portal, precisará excluir a entrelinha '?' para que o token funcione no SQL Server.
Depois de ter o Destino do Backup configurado no SQL Server, você poderá fazer backup no armazenamento de blob do Hub de Pilha do Azure.
Próximos passos
Usando serviços ou criando aplicativos para o Azure Stack Hub