Dimensionar recursos de banco de dados único no Banco de Dados SQL do Azure

Aplica-se a: do Banco de Dados SQL do Azure

Este artigo descreve como dimensionar os recursos de computação e armazenamento disponíveis para o Banco de Dados SQL do Azure na camada de computação provisionada. Como alternativa, a camada de computação sem servidor oferece dimensionamento automático e faz a faturação por segundo com base na utilização da computação.

Depois de selecionar inicialmente o número de vCores ou DTUs, você pode dimensionar um único banco de dados dinamicamente para cima ou para baixo com base na experiência real usando:

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

Impacto

A alteração da camada de serviço ou do tamanho de computação envolve principalmente o serviço executando as seguintes etapas:

1. Crie uma 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 solicitada e o tamanho da computação. Para algumas combinações de alterações na camada de serviço e no tamanho da computação, uma réplica do banco de dados deve ser criada na nova instância de computação, o que envolve a cópia de dados e pode influenciar fortemente a latência geral. Independentemente disso, o banco de dados permanece online durante esta etapa e as conexões continuam a ser direcionadas para o banco de dados na instância de computação original.

2. Redirecionar o roteamento das 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 descartadas. Quaisquer novas conexões são estabelecidas com o banco de dados na nova instância de computação. Para algumas combinações de alterações na camada de serviço e no tamanho de computação, os ficheiros da base de dados são separados e reconectados durante a mudança. Independentemente disso, o switch pode resultar em uma breve interrupção do serviço quando o banco de dados está indisponível geralmente por menos de 30 segundos e, muitas vezes, por apenas alguns segundos. Se houver transações de longa duração em execução quando as conexões forem descartadas, a duração desta etapa poderá levar mais tempo para recuperar transações abortadas. A recuperação acelerada do banco de dados pode reduzir o impacto da anulação de transações de longa execução.

Latência

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/para 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 alterações de dimensionamento

Uma operação de alteração da camada de serviço ou reescalonamento 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 dimensionar um banco de dados, o logon deve ser o logon de administrador do servidor (criado quando o servidor lógico do Banco de Dados SQL do Azure foi provisionado), o administrador 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 obter mais informações, consulte ALTER DATABASE.

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

Considerações adicionais

• Se você estiver atualizando para uma camada de serviço ou tamanho de computação mais alto, o tamanho máximo do banco de dados não aumentará, a menos que você especifique explicitamente um tamanho maior (maxsize).
• Para fazer downgrade de um banco de dados, o espaço usado do banco de dados deve ser menor do que o tamanho máximo permitido da camada de serviço de destino e do tamanho de computação.
• Ao fazer o downgrade de Premium para o nível Standard, aplica-se um custo extra de armazenamento se (1) o tamanho máximo do banco de dados for suportado no tamanho de computação de destino, e (2) se o tamanho máximo exceder a quantidade de armazenamento incluída no tamanho de 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, já que o S3 suporta um tamanho máximo de 1 TB e sua quantidade de armazenamento incluída é de apenas 250 GB. Assim, a quantidade de armazenamento extra é de 500 GB – 250 GB = 250 GB. Para obter preços de armazenamento extra, consulte preços do Azure SQL Database. Se a quantidade real de espaço usada for menor do que a quantidade de armazenamento incluída, esse custo extra pode ser evitado reduzindo o tamanho máximo do banco de dados para a quantidade incluída.
• Ao atualizar um banco de dados com de replicação geográfica habilitado, atualize seus bancos de dados secundários para a camada de serviço desejada e o tamanho de computação antes de atualizar o banco de dados primário (orientação geral para melhor desempenho). Ao atualizar para uma edição diferente, é necessário que o banco de dados secundário seja atualizado primeiro.
• Ao reduzir um banco de dados com replicação geográfica habilitada, reduza os seus bancos de dados primários para a camada de serviço desejada e o tamanho de computação antes de reduzir o banco de dados secundário (como orientação geral para um melhor desempenho). Ao fazer o downgrade para uma edição diferente, é necessário que o banco de dados primário seja rebaixado primeiro.
• As ofertas de serviço de recuperação são diferentes para os vários níveis de serviço. Se está a fazer downgrade para a camada Basic, haverá um período de retenção de backup menor. Consulte Backups automatizados no Banco de Dados SQL do Azure.
• As novas propriedades do banco de dados não são aplicadas até que as alterações sejam concluídas.
• Quando a cópia de dados é necessária para dimensionar um banco de dados (consulte Latency) 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 recuperação acelerada de banco de dados, a reversão de transações de longa execução não é uma fonte significativa de atraso, 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 para tamanhos de computação menores.

Faturação

Você é cobrado por cada hora que um banco de dados existe usando a camada de serviço mais alta + tamanho de computação aplicado durante essa hora, independentemente do uso ou se o banco de dados esteve ativo por menos de uma hora. Por exemplo, se você criar um único banco de dados e excluí-lo cinco minutos depois, sua fatura refletirá uma cobrança por uma hora de banco de dados.

Alterar o tamanho do armazenamento

Modelo de compra baseado em vCore

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

• O armazenamento de dados para um único banco de dados pode ser provisionado aumentando ou diminuindo seu tamanho máximo usando odo portal do Azure, Transact-SQL, PowerShell, da CLI do Azure ou API REST. Se o valor de tamanho máximo for especificado em bytes, ele deverá ser um múltiplo de 1 GB (1.073.741.824 bytes).

• A quantidade de dados que podem ser armazenados nos arquivos de dados de um banco de dados é limitada pelo tamanho máximo de armazenamento de dados configurado. Além desse armazenamento, a Base de Dados SQL do Azure adiciona automaticamente mais 30% de armazenamento para ser utilizado no log de transação. O preço do armazenamento para um único banco de dados ou um pool elástico é a soma dos valores de armazenamento de dados e de log de transações multiplicado pelo preço unitário de armazenamento do nível de serviço. Por exemplo, se o armazenamento de dados estiver definido como 10 GB, o armazenamento adicional do log de transações será 10 GB * 30% = 3 GBe 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 do tempdb está incluído no preço de um único banco de dados ou de um pool elástico.

• Para obter detalhes sobre o preço de armazenamento, consulte a tabela de preços do Banco de Dados SQL do Azure em .

Modelo de compra baseado em DTU

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

Banco de dados replicado geograficamente

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

Restrições P11 e P15 quando o tamanho máximo é superior a 1 TB

Mais de 1 TB de armazenamento no nível Premium está atualmente 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 no nível Premium é limitado a 1 TB. As seguintes considerações e limitações aplicam-se a bases 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 tiver sido definido para um valor maior que 1 TB, ele só poderá ser restaurado ou copiado para um banco de dados P11 ou P15. Mais tarde, 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 reescalonamento não exceda os limites máximos de tamanho do novo tamanho de computação.
• Para cenários de replicação geográfica ativa:
  • Configurando uma relação de replicação geográfica: se o banco de dados primário for P11 ou P15, o(s) secundário(s) também deve(m) ser P11 ou P15. Tamanhos de computação mais baixos são rejeitados como secundários, uma vez que não são capazes de suportar 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 dispara a mesma alteração no banco de dados secundário. Ambas as atualizações devem ser bem-sucedidas para que a alteração no primário entre em vigor. Aplicam-se limitações de região para a opção de mais de 1 TB. Se o secundário estiver em uma região que não suporta 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 SqlPackage para importar e exportar dados.

Conteúdo relacionado

• Limites de recursos para bancos de dados únicos usando o modelo de compra vCore
• Limites de recursos para bancos de dados únicos usando o modelo de compra DTU - Banco de Dados SQL do Azure