Visão geral dos limites de recursos da Instância Gerenciada de SQL do Azure

Aplica-se a: Instância Gerenciada de SQL do Azure

Este artigo apresenta uma visão geral das características técnicas e dos limites de recursos para a Instância Gerenciada de SQL do Azure e fornece informações sobre como solicitar um aumento desses limites.

Características de configuração de hardware

Instância Gerenciada de SQL tem características e limites de recursos que dependem da infraestrutura e arquitetura subjacentes. Instância Gerenciada de SQL pode ser implantada em várias gerações de hardware.

As gerações de hardware têm características diferentes, conforme descritas na tabela a seguir:

¹ A implantação de uma instância de 2 vCore só é possível em um pool de instâncias.
² Dependente do número de vCores.
³ Somente as principais regiões podem fornecer 16 TB de armazenamento. As regiões menores limitam o armazenamento disponível a 5,5 TB.

Suporte regional para o hardware com otimização de memória da série Premium e para o hardware com armazenamento de 16 TB da série Premium

O suporte para o hardware com armazenamento de 16 TB da série Premium tem uma disponibilidade semelhante ao suporte para o hardware com otimização de memória da série Premium. No momento, o suporte para o hardware com otimização de memória da série Premium e para o hardware com armazenamento de 16 TB da série Premium está disponível somente nestas regiões específicas:

Espaço disponível no OLTP in-memory

A quantidade de espaço OLTP in-memory na camada de serviço Comercialmente Crítico depende do número de vCores e da configuração do hardware. A tabela a seguir lista os limites de memória que pode ser usados para objetos OLTP In-memory.

Características de camada de serviço

A Instância Gerenciada de SQL tem duas camadas de serviço: Uso Geral e Comercialmente Crítico. É possível escolher usar a camada de serviço Uso Geral de Última Geração (Preview) atualizada.

Número de vCores

¹ A implantação de uma instância de 2 vCore só é possível em um pool de instâncias.

Memória máxima

¹ A relação entre memória/vCore apenas está disponível em até 80 vCores para hardwares da série Premium e 64 vCores para a série Premium otimizada para memória. A memória máxima é limitada a 560 GB para vCores da série Premium acima de 80 e 870,4 GB para vCores da série Premium otimizada para memória acima de 64.

Tamanho máximo de armazenamento de instância (reservado)

¹ Somente as principais regiões podem fornecer 16 TB de armazenamento para o hardware da série Premium para esses números de vCore de CPU. As regiões menores limitam o armazenamento disponível a 5,5 TB.
² Somente as principais regiões podem fornecer 8 TB de armazenamento para o hardware com otimização de memória da série Premium para esses números de vCore de CPU. As regiões menores limitam o armazenamento disponível a 5,5 TB.

Comparação de recursos

Considerações adicionais:

• O tamanho de armazenamento de instância disponível atualmente é a diferença entre o tamanho da instância reservada e o espaço de armazenamento usado.
• O tamanho do arquivo de log e de dados nos bancos de dados de sistema e de usuário são incluídos no tamanho de armazenamento de instância que é comparado ao limite de tamanho de armazenamento máximo. Usar a exibição do sistema sys. master_files para determinar o total o espaço usado pelos bancos de dados. Os logs de erros não são persistentes e não estão incluídos no tamanho. Os backups não estão incluídos no tamanho do armazenamento.
• A produtividade e a IOPS na camada Uso Geral também dependem do tamanho do arquivo e não têm limites explícitos fornecidos pela Instância Gerenciada de SQL.
• A IOPS de instância máxima depende do layout do arquivo e da distribuição da carga de trabalho. Por exemplo, se você criar sete arquivos de 1 TB com um máximo de 5 mil IOPS cada e sete arquivos pequenos (menores que 128 GB) com 500 IOPS cada, poderá obter 38500 IOPS por instância (7x5000 + 7x500) se sua carga de trabalho puder usar todos os arquivos. Observe que algumas IOPS também são usadas para backups automáticos.
• Você pode criar outra réplica legível em uma região do Azure diferente usando grupos de failover
• Os nomes dos arquivos tempdb não podem ter mais de 16 caracteres.

Encontre mais informações sobre os limites de recursos em pools de Instância Gerenciada de SQL neste artigo.

IOPS

Para as camadas de serviço Uso Geral de Última Geração e Comercialmente Crítico, as IOPS disponíveis são determinadas pelo número de vCores:

• Camada de serviço Uso Geral de Última Geração: valor fixo de IOPS com base no número de vCores. O preço do armazenamento inclui um valor de IOPS mínimo. Se você ultrapassar o valor mínimo, terá cobranças da seguinte forma: 1 IOPS = preço de armazenamento (por região) dividido por três. Por exemplo, se o custo de 1 GB de armazenamento é US$ 0,115, então 1 IOPS = 0,115/3 = US$ 0,038 por IOPS.
• Camada de serviço Comercialmente Crítico: usa uma fórmula (4.000 IOPS/vCore) para determinar os limites de IOPS.

A tabela apresentada a seguir lista o número máximo de IOPS disponíveis para cada camada de serviço com base no número de vCores:

Características de E/S de arquivo na camada de Uso Geral

Na camada de serviço de Uso Geral, cada arquivo de banco de dados obtém IOPS dedicadas e taxa de transferência que dependem do tamanho do arquivo. Arquivos maiores obtêm mais IOPS e taxa de transferência. As características de e/s dos arquivos de banco de dados são mostradas na tabela a seguir:

Se você notar alta latência de E/S em algum arquivo de banco de dados ou perceber que a IOPS/taxa de transferência está atingindo o limite, poderá melhorar o desempenho aumentando o tamanho do arquivo.

Além disso, há um limite em nível de instância para a produtividade máxima de gravação de logs (veja a tabela anterior para obter os valores, por exemplo, 22 MiB por segundo). Portanto, talvez não seja possível alcançar o arquivo máximo no arquivo de registro em logs porque você está atingindo o limite de produtividade da instância.

Armazenamento de dados e de log

Os fatores a seguir afetam a quantidade de armazenamento usada para arquivos de log e dados e se aplicam às camadas Uso Geral e Comercialmente Crítico.

• Na camada de serviço de uso geral, o tempdb usa o armazenamento SSD local, e esse custo de armazenamento é incluído no preço do vCore.
• Na camada de serviço Comercialmente Crítico, tempdb compartilha o armazenamento SSD local com dados e arquivos de log, e o custo de armazenamento tempdb está incluído no preço do vCore.
• O tamanho de armazenamento máximo de uma Instância Gerenciada de SQL precisa ser especificado em múltiplos de 32 GB.

Para monitorar o tamanho total de armazenamento consumido da instância para a Instância Gerenciada de SQL, use a métrica storage_space_used_mb. Para monitorar o atual tamanho de armazenamento alocado e usado de dados individuais e arquivos de log em um banco de dados usando o T-SQL, use a exibição sys.database_files e a função FILEPROPERTY(... , 'SpaceUsed').

Backups e armazenamento

O armazenamento para backups de banco de dados é alocado para dar suporte a funcionalidades de PITR (restauração pontual) e de LTR (retenção de longo prazo) da Instância Gerenciada de SQL. Esse armazenamento é separado do armazenamento de arquivos de dados e de log e é cobrado separadamente.

• PITR: nas camadas Uso Geral e Comercialmente Crítico, backups de banco de dados individuais são copiados para o armazenamento RA-GRS (armazenamento com redundância geográfica com acesso de leitura) automaticamente. O tamanho do armazenamento aumenta dinamicamente conforme backups são criados. O armazenamento é usado por backups completos, diferenciais e de log de transações. O consumo de armazenamento depende da taxa de alteração do banco de dados e do período de retenção configurado para backups. Você pode configurar um período de retenção separado para cada banco de dados entre 1 e 35 dias para a Instância Gerenciada de SQL. Uma quantidade de armazenamento de backup igual ao tamanho de dados máximo configurado é fornecida sem encargos extras.
• LTR: você também tem a opção de configurar a retenção de longo prazo de backups completos por até 10 anos. Se você configurar uma política de LTR, esses backups serão armazenados no armazenamento RA-GRS automaticamente, mas você poderá controlar com que frequência os backups serão copiados. Para atender a diferentes requisitos de conformidade, é possível selecionar diferentes períodos de retenção para backups semanais, mensais e/ou anuais. A configuração escolhida determina a quantidade de armazenamento que é usada para backups de LTR. Para obter mais informações, confira Retenção de backup de longo prazo.

Regiões com suporte

As Instância Gerenciada de SQL pode ser criado somente em regiões com suporte. Para criar uma Instância Gerenciada de SQL em uma região atualmente sem suporte, você pode enviar uma solicitação de suporte por meio do portal do Azure.

Tipos de assinatura com suporte

No momento, Instância Gerenciada de SQL oferece suporte à implantação apenas nos seguintes tipos de inscrição:

• Enterprise Agreement (EA)
• Pago conforme o uso
• Provedor de Serviços de Nuvem (CSP)
• Desenvolvimento/Teste Enterprise
• Desenvolvimento/Teste Pago Conforme o Uso
• Assinaturas com crédito Azure mensal para assinantes do Visual Studio
• Teste Gratuito
• Azure for Students
• Azure via Open

Limitações de recursos regionais

Os tipos de assinatura suportados podem conter um número limitado de recursos por região. A Instância Gerenciada de SQL tem dois limites padrão por região do Azure (que podem ser aumentados sob demanda ao criar uma solicitação de suporte especial no portal do Azure) dependendo do tipo de assinatura:

• Limite de sub-rede: o número máximo de sub-redes nas quais as Instância Gerenciada de SQL são implantadas em uma única região.
• limite de unidade VCORE: o número máximo de unidades vCore que podem ser implantadas em todas as instâncias em uma única região. Um vCore da GP usa uma unidade vCore e um vCore de BC usa quatro unidades vCore. O número total de instâncias não é limitado, desde que esteja dentro dos limites da unidade de vCore.

A tabela a seguir mostra os limites regionais padrão para tipos de assinatura com suporte (os limites padrão podem ser estendidos usando uma solicitação de suporte):

* Ao planejar implantações, leve em consideração que a camada de serviço BC (Comercialmente Crítico) requer quatro (4) vezes mais capacidade de vCore do que a camada de serviço de GP (Uso Geral). Por exemplo: 1 GP vCore = 1 unidade vCore e 1 BC vCore = 4 vCore. Para simplificar sua análise de consumo em relação aos limites padrão, resuma as unidades de vCore em todas as sub-redes da região em que a Instância Gerenciada de SQL está implantada e compare os resultados com os limites da unidade da instância para o seu tipo de assinatura. O limite de número máximo de unidades vCore se aplica a cada assinatura em uma região. Não há limites por sub-redes individuais, exceto que a soma de todos os vCores implantados em várias sub-redes deve ser inferior ou igual ao número máximo de unidades de vCore.

** Limites maiores de sub-rede e vCore estão disponíveis atualmente nas seguintes regiões: Leste da Austrália, Leste dos EUA, Leste dos EUA 2, Norte da Europa, Centro-Sul dos EUA, Sudeste Asiático, Sul do Reino Unido, Oeste da Europa, Oeste dos EUA 2.

Solicitar um aumento de cota

Se você precisar de mais instâncias nas regiões atuais, envie uma solicitação de suporte para estender a cota usando o portal do Azure. Para mais informações, consulte Solicitar aumentos de cotas para Banco de Dados SQL do Azure.

Próximas etapas

• Para obter informações sobre a Instância Gerenciada de SQL, confira o que é uma Instância Gerenciada de SQL?.
• Para saber mais sobre preços,confira preços de Instância Gerenciada de SQL.
• Para saber como criar sua primeira Instância Gerenciada de SQL, confira o guia de início rápido.
• SLA para a Instância Gerenciada de SQL do Azure