Escalar recursos de banco de dados individual no Banco de Dados SQL do Azure

Este artigo descreve como escalar os recursos de computação e armazenamento disponíveis para um Banco de Dados SQL do Azure na camada de computação provisionada. Como alternativa, a camada de computação sem servidor fornece dimensionamento automático de computação e cobra por segundo de computação usada.

Depois de escolher inicialmente o número de vCores ou DTUs, você poderá escalar verticalmente e de forma dinâmica um banco de dados individual com base na experiência real usando:

• Transact-SQL
• Portal do Azure
• PowerShell
• CLI do Azure
• REST API

Impacto

Alterar a camada de serviço ou o tamanho da computação envolve principalmente o serviço executando as seguintes etapas:

1. Criar nova instância de computação para o banco de dados.

   Uma nova instância de computação é criada com a camada de serviço e o tamanho de computação solicitados. Para algumas combinações de alterações de tamanho de computação e camada de serviço, uma réplica do banco de dados deve ser criada na nova instância de computação que envolve a cópia de dados e pode influenciar muito a latência em geral. Ainda assim, o banco de dados permanece online durante essa etapa, e as conexões continuam a ser direcionadas para o banco de dados na instância de computação original.

2. Alternar o roteamento de conexões para uma nova instância de computação.

   As conexões existentes com o banco de dados na instância de computação original são removidas. Todas as conexões novas são estabelecidas com o banco de dados na nova instância de computação. Para algumas combinações de alterações de tamanho de computação e camada de serviço, os arquivos de banco de dados são desanexados e reanexados durante a alternância. Ainda assim, a alternância pode resultar em uma breve interrupção do serviço quando o banco de dados estiver indisponível por menos de 30 segundos e geralmente dura apenas alguns segundos. Se houver transações de execução prolongada ativas quando as conexões forem removidas, a duração dessa etapa poderá levar mais tempo para recuperar as transações anuladas. A Recuperação Acelerada de Banco de Dados pode reduzir o impacto da anulação de transações de execução prolongada.

Latency

A latência estimada para alterar a camada de serviço, dimensionar o tamanho de computação de um único banco de dados ou pool elástico, mover um banco de dados para dentro/fora de um pool elástico ou mover um banco de dados entre pools elásticos é parametrizada da seguinte maneira:

SELECT s.file_id,
       s.type_desc,
       s.name,
       FILEPROPERTYEX(s.name, 'AccountType') AS AccountType
FROM sys.database_files AS s
WHERE s.type_desc IN ('ROWS', 'LOG');

Monitorar ou cancelar as alterações de escala

Uma operação de alteração de camada de serviço ou redimensionamento de computação pode ser monitorada e cancelada.

Login-AzAccount
$SubscriptionID = "<YourSubscriptionIdHere>"
Select-AzSubscription -SubscriptionName $SubscriptionID

Get-AzSqlDatabaseActivity -ResourceGroupName "ResourceGroup01" -ServerName "Server01" -DatabaseName "Database01"

Stop-AzSqlDatabaseActivity -ResourceGroupName "ResourceGroup01" -ServerName "Server01" -DatabaseName "Database01" -OperationId af97005d-9243-4f8a-844e-402d1cc855f5

$resourceGroupName = "<resource group name>"
$serverName = "<server name>"
$databaseName = "<sql database name>"
az sql db op list --resource-group $resourceGroupName --server $serverName --database $databaseName --query "[?state=='InProgress'].name" --out tsv

$resourceGroupName = "<resource group name>"
$serverName = "<server name>"
$databaseName = "<sql database name>"
$operationName = (az sql db op list --resource-group $resourceGroupName --server $serverName --database $databaseName --query "[?state=='InProgress'].name" --out tsv)
if (-not [string]::IsNullOrEmpty($operationName)) {
    (az sql db op cancel --resource-group $resourceGroupName --server $serverName --database $databaseName --name $operationName)
        "Operation " + $operationName + " has been canceled"
}
else {
    "No service tier change or compute rescaling operation found"
}

Permissões

Para dimensionar bancos de dados via Transact-SQL, ALTER DATABASE é usado. Para escalar um banco de dados, um logon precisa ser o logon do administrador do servidor (criado quando o servidor lógico do banco de dados SQL do Azure foi provisionado), o administrador do Microsoft Entra do servidor, um membro da função de banco de dados dbmanager em master, um membro da função de banco de dados db_owner no banco de dados atual ou dbo do banco de dados. Para saber mais, confira ALTERAR BANCO DE DADOS.

Para dimensionar bancos de dados por meio do portal do Azure, PowerShell, CLI do Azure ou API REST, são necessárias permissões RBAC do Azure, especificamente as funções do Azure RBAC Colaborador, Colaborador do BD SQL ou Colaborador do SQL Server. Para obter mais informações, confira Funções internas do Azure RBAC.

Considerações adicionais

• Se você estiver atualizando para uma camada de serviço ou tamanho da computação maior, o tamanho máximo do banco de dados não aumentará, a menos que você especifique explicitamente um tamanho maior (tamanho máximo).
• Para fazer downgrade de um banco de dados, o espaço usado dele deve ter um tamanho menor do que o máximo permitido para a camada de serviço e o tamanho da computação de destino.
• Ao fazer o downgrade da camada Premium para a camada Standard, um custo de armazenamento extra será aplicado se (1) o tamanho máximo do banco de dados tiver suporte no tamanho da computação de destino e (2) o tamanho máximo ultrapassar a quantidade de armazenamento incluída de tamanho da computação de destino. Por exemplo, se um banco de dados P1 com um tamanho máximo de 500 GB for reduzido para S3, um custo de armazenamento extra será aplicado, pois S3 dá suporte a um tamanho máximo de 1 TB, e a quantidade de armazenamento incluída é somente de 250 GB. Assim, a quantidade de armazenamento extra será 500 GB – 250 GB = 250 GB. Para obter o preço do armazenamento adicional, confira Preços do Banco de Dados SQL do Azure. Se a quantidade real de espaço usado for menor do que a quantidade de armazenamento incluído, esse custo extra poderá ser evitado por meio da redução do tamanho máximo do banco de dados para a quantidade incluída.
• Ao atualizar um banco de dados com replicação geográfica habilitada, atualize seus bancos de dados secundários para a camada de serviço e o tamanho da computação desejados antes de atualizar o banco de dados primário (orientação geral para o melhor desempenho). Ao atualizar para uma edição diferente, é obrigatório que o banco de dados secundário seja atualizado primeiro.
• Ao fazer downgrade de um banco de dados com replicação geográfica habilitada, faça downgrade dos seus bancos de dados primários para a camada de serviço e o tamanho da computação desejados antes de atualizar o banco de dados secundário (orientação geral para o melhor desempenho). Ao fazer downgrade para uma edição diferente, é obrigatório fazer downgrade do banco de dados primário antes.
• As ofertas de serviço de restauração são diferentes para as várias camadas de serviço. Se você estiver fazendo downgrade para a camada Básica, haverá um período de retenção de backup inferior. Consulte Backups de Banco de Dados SQL do Azure.
• As novas propriedades do banco de dados não serão aplicadas até que as alterações sejam concluídas.
• Quando a cópia de dados é necessária para escalar um banco de dados (confira Latência) ao alterar a camada de serviço, a alta utilização de recursos simultânea à operação de dimensionamento pode causar tempos de dimensionamento mais longos. Com a ADR (Recuperação Acelerada de Banco de Dados), a reversão de transações de longa execução não é uma fonte de atraso significativa, mas o alto uso simultâneo de recursos pode deixar menos recursos de computação, armazenamento e largura de banda de rede para dimensionamento, especialmente em tamanhos de computação menores.

Cobrança

Você será cobrado pelas horas em que um banco de dados existir usando a camada de serviço mais alta e o tamanho da computação aplicado durante essas horas, independentemente do uso ou se o banco de dados ficou ativo por menos de uma hora. Por exemplo, se você criar um banco de dados individual e o excluir depois de cinco minutos, sua fatura apresentará uma cobrança referente a uma hora de banco de dados.

Alterar o tamanho de armazenamento

Modelo de compra baseado em vCore

• O armazenamento pode ser provisionado até o limite de tamanho máximo de armazenamento de dados com incrementos de 1 GB. O armazenamento de dados configurável mínimo é de 1 GB. Para limites máximos de tamanho do armazenamento de dados em cada objetivo de serviço, consulte as páginas da documentação de limite de recursos para Limites de recursos para bancos de dados individuais usando o modelo de compra vCore e Limites de recursos para bancos de dados individuais usando o modelo de compra DTU.

• É possível provisionar o armazenamento de dados para um único banco de dados aumentando ou diminuindo seu tamanho máximo usando o Portal do Azure, o Transact-SQL, o PowerShell, a CLI do Azure ou a API REST. Se o valor do tamanho máximo for especificado em bytes, ele deverá ser um múltiplo de 1 GB (1073741824 bytes).

• A quantidade de dados que pode ser armazenada nos arquivos de um banco de dados é limitada pelo tamanho máximo do armazenamento de dados configurado. Além desse armazenamento, o Banco de Dados SQL do Azure adiciona automaticamente 30% a mais de armazenamento a ser usado para o log de transações. O preço de armazenamento para um único banco de dados ou um pool elástico é a soma das quantidades de armazenamento de dados e armazenamento de log de transações multiplicada pelo preço unitário do armazenamento da camada de serviço. Por exemplo, se o armazenamento de dados estiver definido como 10 GB, o armazenamento adicional do log de transações será de 10 GB * 30% = 3 GB e a quantidade total de armazenamento faturável será 10 GB + 3 GB = 13 GB.

  Observação

  O tamanho máximo do arquivo de log de transações é gerenciado automaticamente e, em alguns casos, pode ser maior que 30% do tamanho máximo de armazenamento de dados. Isso não aumenta o preço do armazenamento para o banco de dados.

• O Banco de Dados SQL do Azure aloca automaticamente 32 GB por vCore para o banco de dados tempdb. tempdb está localizado no armazenamento SSD local em todas as camadas de serviço. O custo de tempdb está incluído no preço de um único banco de dados ou um pool elástico.

• Para obter detalhes sobre o preço de armazenamento, confira Preços do Banco de Dados SQL do Azure.

Modelo de compra baseado em DTU

• O preço de DTU para um único banco de dados inclui uma determinada quantidade de armazenamento sem custo adicional. O armazenamento extra além da quantidade incluída pode ser provisionado mediante um custo adicional até o limite máximo de tamanho, em incrementos de 250 GB até 1 TB e, em seguida, em incrementos de 256 GB além de 1 TB. Para conhecer as quantidades de armazenamento incluídas e os limites máximos de tamanho, confira Banco de dados individual: tamanhos de armazenamento e tamanhos de computação.
• É possível provisionar o armazenamento extra para um único banco de dados aumentando seu tamanho máximo usando o Portal do Azure, Transact-SQL, PowerShell, CLI do Azure ou API REST.
• O preço do armazenamento extra para um único banco de dados é a quantidade de armazenamento extra multiplicada pelo preço unitário do armazenamento extra da camada de serviço. Para obter detalhes sobre o preço de armazenamento extra, confira Preços do Banco de Dados SQL do Azure.

Banco de dados replicado geograficamente

Para alterar o tamanho de um banco de dados secundário replicado, altere o tamanho do banco de dados primário. Essa alteração será replicada e implementada também no banco de dados secundário.

Limitações do P11 e P15 quando o tamanho máximo for maior que 1 TB

Atualmente, há mais de 1 TB de armazenamento na camada Premium disponível em todas as regiões, exceto Leste da China, Norte da China, Alemanha Central e Nordeste da Alemanha. Nessas regiões, o armazenamento máximo na camada Premium é limitado a 1 TB. As seguintes considerações e limitações se aplicam aos bancos de dados P11 e P15 com um tamanho máximo superior a 1 TB:

• Se o tamanho máximo de um banco de dados P11 ou P15 for definido como um valor maior que 1 TB, ele só poderá ser restaurado ou copiado para um banco de dados P11 ou P15. Subsequentemente, o banco de dados pode ser redimensionado para um tamanho de computação diferente, desde que a quantidade de espaço alocado no momento da operação de redimensionamento não exceda os limites de tamanho máximo do novo tamanho de computação.
• Para cenários com replicação geográfica ativa:
  • Configurar uma relação de replicação geográfica: se o banco de dados primário for P11 ou P15, os secundários também deverão ser P11 ou P15. Tamanhos de computação inferiores são rejeitados como secundários, pois não são capazes de dar suporte a mais de 1 TB.
  • Atualizando o banco de dados primário em uma relação de replicação geográfica: alterar o tamanho máximo para mais de 1 TB em um banco de dados primário disparará a mesma alteração no banco de dados secundário. As duas atualizações devem ser bem-sucedidas para que a alteração no primário entre em vigor. Há limitações de região para a opção superior a 1 TB. Se o secundário estiver em uma região que não dá suporte a mais de 1 TB, o primário não será atualizado.
• Não há suporte para o uso do serviço de Importação/Exportação para carregar bancos de dados P11/P15 com mais de 1 TB. Use o SqlPackage para importar e exportar dados.

Conteúdo relacionado

Para saber os limites gerais de recursos, confira Limites de recursos baseados em vCore do Banco de Dados SQL do Azure – bancos de dados individuais e Limites de recursos baseados em DTU do Banco de Dados SQL do Azure – bancos de dados individuais.