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

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

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

Características de configuração de hardware

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

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

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

² Dependente de o número de vCores.

³ Apenas as principais regiões pode fornecer 16 TB de armazenamento. Regiões menores limitam o armazenamento disponível a 5,5 TB.

Suportes regionais para hardware de série premium otimizado para memória e para hardware de série premium com armazenamento de 16 TB

O suporte para o hardware da série premium com armazenamento de 16 TB tem a mesma disponibilidade que o suporte para o hardware da série premium otimizado para memória. Os suportes para o hardware da série premium com otimização de memória e para o hardware da série premium com armazenamento de 16 TB estão atualmente disponíveis apenas nestas regiões específicas:

Espaço disponível OLTP na memória

A quantidade de espaço OLTP na memória em camada de serviço Business Critical depende do número de vCores e da configuração de hardware. A tabela a seguir lista os limites de memória que podem ser usados para objetos OLTP na memória.

Características da camada de serviço

A Instância Gerenciada SQL tem duas camadas de serviço : Finalidade Geral e Crítica de Negócios. Você pode optar por usar a camada de serviço de uso geral (visualização) de Next-gen atualizada.

Número de vCores

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

Memória máxima

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

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

¹ Apenas as principais regiões pode fornecer 16 TB de armazenamento para o hardware da série premium para esses números vCore da CPU. Regiões menores limitam o armazenamento disponível a 5,5 TB.

² Somente as principais regiões pode fornecer 8 TB de armazenamento para o hardware otimizado de memória da série premium para esses números vCore da CPU. Regiões menores limitam o armazenamento disponível a 5,5 TB.

Comparação de recursos

¹ Este é um intervalo médio. Embora a grande maioria das durações de solicitação de IO caia abaixo do topo da faixa, são possíveis outliers que excedam o intervalo.

Considerações adicionais

• O tamanho de armazenamento de instância atualmente disponível é a diferença entre o tamanho da instância reservada e o espaço de armazenamento usado.

• Os dados e o tamanho do arquivo de log nos bancos de dados do usuário e do sistema são incluídos no tamanho de armazenamento da instância que é comparado com o limite máximo de tamanho de armazenamento. Use a visualização sys.master_files sistema para determinar o espaço total usado pelos bancos de dados. Os logs de erro 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 taxa de transferência e IOPS na camada de Propósito Geral também dependem do tamanho do arquivo e não são explicitamente limitadas pela Instância Gerenciada SQL.

• As IOPS máximas da instância dependem do layout do arquivo e da distribuição da carga de trabalho. Por exemplo, se você criar 7 x arquivos de 1 TB com máximo de 5 K 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. Algumas IOPS também são usadas para backups automáticos.

• Você pode criar outra réplica legível em uma região diferente do Azure usando grupos de failover

• Os nomes dos ficheiros tempdbnão podem ter mais de 16 carateres.

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

IOPS

Para as camadas de serviço de uso geral de próxima geração e críticas para os negócios, as IOPS disponíveis são ditadas pelo número de vCores:

• Camada de serviço de uso geral de próxima geração: valor fixo de IOPS com base no número de vCores. O preço do armazenamento inclui o IOPS mínimo. Se você ultrapassar o mínimo, será cobrado da seguinte forma: 1 IOPS = preço de armazenamento (por região) dividido por três. Por exemplo, se 1 GB de armazenamento custar 0,115, então 1 IOPS = 0,115/3 = 0,038 por IOPS.
• Business Critical service tier: usa uma fórmula (4000 IOPS/vCore) para determinar os limites de IOPS.

A tabela a seguir lista o máximo de IOPS disponível 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 recebe 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 vir que IOPS/taxa de transferência está atingindo o limite, poderá melhorar o desempenho aumentando o tamanho do arquivo.

Há também um limite no nível da instância na taxa de transferência máxima de gravação de log (consulte a tabela anterior para obter valores, por exemplo, 22 MiB/s), portanto, talvez não seja possível alcançar o arquivo máximo em todo o arquivo de log porque está atingindo o limite de taxa de transferência da instância.

Armazenamento de dados e logs

Os fatores a seguir afetam a quantidade de armazenamento usada para dados e arquivos de log e se aplicam às camadas de uso geral e críticas para os negócios.

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

Para monitorar o tamanho total de armazenamento de instância consumido para Instância Gerenciada SQL, use a métrica storage_space_used_mb. Para monitorar o tamanho de armazenamento atual alocado e usado de dados individuais e arquivos de log em um banco de dados usando T-SQL, use a visualizaçã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 ao de restauração point-in-time (PITR) e recursos de de retenção de longo prazo (LTR) da Instância Gerenciada SQL. Esse armazenamento é separado do armazenamento de dados e arquivos de log e é cobrado separadamente.

• PITR: Nas camadas de uso geral e crítica para os negócios, os backups de bancos de dados individuais são copiados para de armazenamento com redundância geográfica (RA-GRS) de acesso de leitura automaticamente. O tamanho do armazenamento aumenta dinamicamente à medida que novos 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 SQL. Uma quantidade de armazenamento de backup igual ao tamanho máximo de dados configurado é fornecida sem custo extra.

• 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 LTR, esses backups serão armazenados no armazenamento RA-GRS automaticamente, mas você poderá controlar a frequência com que os backups serão copiados. Para atender a diferentes requisitos de conformidade, você pode selecionar diferentes períodos de retenção para backups semanais, mensais e/ou anuais. A configuração escolhida determina quanto armazenamento é usado para backups LTR. Para obter mais informações, consulte Retenção de longo prazo - Banco de Dados SQL do Azure e Instância Gerenciada SQL do Azure.

Regiões suportadas

A Instância Gerenciada SQL pode ser criada somente em regiões com suporte. Para criar uma Instância Gerenciada SQL em uma região que não é suportada no momento, você pode enviar uma solicitação de suporte por meio do portal do Azure.

Tipos de subscrição suportados

Atualmente, a Instância Gerenciada SQL oferece suporte à implantação somente nos seguintes tipos de assinaturas:

• Enterprise Agreement (EA)
• pré-pago
• Provedor de Serviços de Nuvem (CSP)
• Enterprise Dev/Test
• de desenvolvimento/teste pré-pago
• Subscrições com crédito mensal do Azure para subscritores do Visual Studio
• Versão experimental gratuita
• Azure para estudantes
• Azure no Open

Limitações de recursos regionais

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

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

A tabela a seguir mostra os limites regionais padrão para tipos de assinatura suportados (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 Business Critical (BC) requer quatro (4) vezes mais capacidade vCore do que a camada de serviço de uso geral (GP). 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 vCore em todas as sub-redes na região onde a Instância Gerenciada SQL é implantada e compare os resultados com os limites de unidade de instância para seu tipo de assinatura. número máximo de unidades vCore limite se aplica a cada assinatura em uma região. Não há limite por sub-redes individuais, exceto que a soma de todos os vCores implantados em várias sub-redes deve ser menor ou igual a número máximo de unidades vCore.

² Limites maiores de sub-rede e vCore estão disponíveis 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, Europa Ocidental, Oeste dos EUA 2.

Solicite um aumento de cota

Se você precisar de mais instâncias em suas regiões atuais, envie uma solicitação de suporte para estender 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 e a Instância Gerenciada do SQL.

Conteúdo relacionado

• O que é a Instância Gerenciada SQL do Azure?
• de preços da Instância Gerenciada SQL
• o guia de início rápido
• SLA para o de Instância Gerenciada SQL do Azure