Dimensionar recursos de base de dados individual na Base de Dados SQL do Azure

Este artigo descreve como dimensionar 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 faturas por segundo para a computação usada.

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
• CLI do Azure
• API REST

Importante

Em algumas circunstâncias, pode ser necessário reduzir um banco de dados para recuperar espaço não utilizado. Para obter mais informações, consulte Gerenciar espaço de arquivo no Banco de Dados SQL do Azure.

Nota

Microsoft Entra ID é o novo nome para o Azure Ative Directory (Azure AD). Estamos atualizando a documentação neste momento.

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. Roteamento de switch 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 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 de camada de serviço e tamanho de computação, os arquivos de banco de dados são desanexados e reanexados durante o switch. 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 pode levar mais tempo para recuperar transações abortadas. A recuperação acelerada do banco de dados pode reduzir o impacto do cancelamento de transações de longa execução.

Importante

Nenhum dado é perdido durante qualquer etapa do fluxo de trabalho. Verifique se você implementou alguma lógica de repetição nos aplicativos e componentes que estão usando o Banco de Dados SQL do Azure enquanto a camada de serviço é alterada.

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:

Latência de dimensionamento de banco de dados	Para banco de dados único básico, banco de dados único padrão (S0-S1)	Para banco de dados único padrão (S2-S12), banco de dados único de uso geral, banco de dados elástico em pool básico, banco de dados em pool elástico padrão, banco de dados em pool de uso geral	Para banco de dados único Premium ou banco de dados agrupado, banco de dados único crítico para negócios ou banco de dados em pool	Para hiperescalar banco de dados único ou banco de dados em pool
Do banco de dados único básico, banco de dados único padrão (S0-S1)	• Latência de tempo constante independente do espaço utilizado. • Normalmente, menos de 5 minutos.	• Latência proporcional ao espaço de banco de dados utilizado devido à cópia de dados. • Normalmente, menos de 1 minuto por GB de espaço utilizado.	• Latência proporcional ao espaço de banco de dados utilizado devido à cópia de dados. • Normalmente, menos de 1 minuto por GB de espaço utilizado.	• Latência proporcional ao espaço de banco de dados utilizado devido à cópia de dados. • Normalmente, menos de 1 minuto por GB de espaço utilizado.
Do banco de dados agrupado básico,Banco de dados único padrão (S2-S12),Banco de dados em pool padrão,Banco de dados único de uso geral ou banco de dados em pool	• Latência proporcional ao espaço de banco de dados utilizado devido à cópia de dados. • Normalmente, menos de 1 minuto por GB de espaço utilizado.	• Para bases de dados únicas, latência de tempo constante independente do espaço utilizado. • Normalmente, menos de 5 minutos para bancos de dados únicos. • Para pools elásticos, proporcional ao número de bancos de dados.	• Latência proporcional ao espaço de banco de dados utilizado devido à cópia de dados. • Normalmente, menos de 1 minuto por GB de espaço utilizado.	• Latência proporcional ao espaço de banco de dados utilizado devido à cópia de dados. • Normalmente, menos de 1 minuto por GB de espaço utilizado.
De banco de dados único Premium ou banco de dados agrupado, banco de dados único crítico para negócios ou banco de dados em pool	• Latência proporcional ao espaço de banco de dados utilizado devido à cópia de dados. • Normalmente, menos de 1 minuto por GB de espaço utilizado.	• Latência proporcional ao espaço de banco de dados utilizado devido à cópia de dados. • Normalmente, menos de 1 minuto por GB de espaço utilizado.	• Latência proporcional ao espaço de banco de dados utilizado devido à cópia de dados. • Normalmente, menos de 1 minuto por GB de espaço utilizado.	• Latência proporcional ao espaço de banco de dados utilizado devido à cópia de dados. • Normalmente, menos de 1 minuto por GB de espaço utilizado.
Do banco de dados único Hyperscale ou banco de dados em pool	N/A	Consulte Migração reversa do Hyperscale para cenários e limitações suportados.	N/A	• Latência de tempo constante independente do espaço utilizado. • Normalmente, menos de 2 minutos.

Nota

• Além disso, para bancos de dados Standard (S2-S12) e de uso geral, a latência para mover um banco de dados para dentro/para fora de um pool elástico ou entre pools elásticos será proporcional ao tamanho do banco de dados se o banco de dados estiver usando armazenamento PFS (Premium File Share).
• No caso de mover um banco de dados de/para um pool elástico, somente o espaço usado pelo banco de dados afeta a latência, não o espaço usado pelo pool elástico.
• Para determinar se um banco de dados está usando armazenamento PFS, execute a seguinte consulta no contexto do banco de dados. Se o valor na coluna AccountType for PremiumFileStorage ou PremiumFileStorage-ZRS, o banco de dados está usando armazenamento PFS.

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');

Nota

• A propriedade redundante de zona permanecerá a mesma por padrão ao dimensionar um único banco de dados da camada Business Critical para a camada General Purpose.
• A latência da operação de dimensionamento quando a redundância de zona é alterada para um banco de dados único de uso geral é proporcional ao tamanho do banco de dados.

Gorjeta

Para monitorar operações em andamento, consulte: Gerenciar operações usando a API REST do SQL, Gerenciar operações usando CLI, Monitorar operações usando T-SQL e estes dois comandos do PowerShell: Get-AzSqlDatabaseActivity e Stop-AzSqlDatabaseActivity.

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.

Portal do Azure

Na página Visão geral do banco de dados SQL, procure o banner indicando que uma operação de dimensionamento está em andamento e selecione o link Ver mais para a implantação em andamento.

Na página Operações em curso resultante, selecione Cancelar esta operação.

PowerShell

Para invocar os comandos do PowerShell em um computador, o pacote Az versão 9.7.0 ou uma versão mais recente deve ser instalado localmente. Ou, considere usar o Azure Cloud Shell para executar o Azure PowerShell no shell.azure.com.

Primeiro, inicie sessão no Azure e defina o contexto adequado para a sua subscrição:

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

Para monitorar operações em um banco de dados, incluindo operações de dimensionamento, use Get-AzSqlDatabaseActivity. O exemplo a seguir retorna um OperationId para cada operação em execução no momento.

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

Para cancelar uma operação assíncrona como uma escala de banco de dados, identifique a operação e use Stop-AzSqlDatabaseActivity com um , específico OperationId, como no exemplo a seguir.

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

CLI do Azure

Em um terminal de shell de nuvem, use o comando de exemplo a seguir para identificar as operações em execução no momento. Em um terminal de shell de nuvem, defina as $resourceGroupNamevariáveis , $serverNamee $databaseName execute o seguinte comando:

$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

Para interromper uma operação assíncrona, como uma escala de banco de dados, a partir de um terminal de shell de nuvem, defina as $resourceGroupNamevariáveis , $serverNamee $databaseName execute o seguinte comando:

$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, um 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 do Microsoft Entra do servidor, um membro da função de banco de dados dbmanager no , um membro da função de banco de dados db_owner no masterbanco 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 RBAC do Azure de Colaborador do SQL Server. Para obter mais informações, visite Funções internas do RBAC do Azure.

Considerações adicionais

• Se atualizar para um nível de serviço ou tamanho da computação mais elevado, o tamanho máximo da base de dados não aumentará, exceto se especificar um tamanho maior (maxsize) de forma explícita.
• 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 do nível Premium para o nível Standard, um custo de armazenamento extra se aplica se (1) o tamanho máximo do banco de dados for suportado no tamanho de computação de destino e (2) o tamanho máximo exceder a quantidade de armazenamento incluída do 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 Banco de Dados SQL do Azure. 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 replicação geográfica habilitada, 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 fazer downgrade de um banco de dados com replicação geográfica habilitada, faça o downgrade de seus bancos de dados primários para a camada de serviço desejada e o tamanho de computação antes de fazer downgrade do banco de dados secundário (orientação geral para 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 restauro diferem entre os vários escalões de serviço. Se você estiver fazendo downgrade para a camada Básica , haverá um período de retenção de backup menor. Consulte Backups do 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 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 recuperação acelerada de banco de dados (ADR), 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 escala, 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 uma base de dados individual pode ser aprovisionado ao aumentar ou diminuir o seu tamanho máximo através do portal do Azure, Transact-SQL, PowerShell, CLI do Azure ou API REST. Se o valor do tamanho máximo for especificado em bytes, tem de ser um múltiplo de 1 GB (1073741824 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, o Banco de Dados SQL do Azure adiciona automaticamente 30% mais armazenamento a ser usado para o log de transações. 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á de 10 GB * 30% = 3 GB e a quantidade total de armazenamento faturável será de 10 GB + 3 GB = 13 GB.

  Nota

  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 tempdb banco de dados. tempdb está localizado no armazenamento SSD local em todos os níveis de serviço. O custo de está incluído no preço de um único banco de dados ou de tempdb um pool elástico.

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

Importante

Em algumas circunstâncias, pode ser necessário reduzir um banco de dados para recuperar espaço não utilizado. Para obter mais informações, consulte Gerenciar espaço de arquivo no Banco de Dados SQL do Azure.

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. Pode ser aprovisionado armazenamento extra que ultrapasse a quantidade incluída mediante um custo adicional. Este aprovisionamento tem um limite de tamanho máximo de 250 GB de incrementos até chegar a 1 TB. Depois de ultrapassar 1 TB, os incrementos serão de 256 GB. Para obter as quantidades de armazenamento incluídas e os limites de tamanho máximo, consulte Banco de dados único: tamanhos de armazenamento e tamanhos de computação.
• O armazenamento de dados extra para uma base de dados individual pode ser aprovisionado ao aumentar o respetivo tamanho máximo através do 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 de armazenamento extra do nível de serviço. Para obter detalhes sobre o preço do armazenamento extra, consulte Preços do Banco de Dados SQL do Azure.

Importante

Em algumas circunstâncias, pode ser necessário reduzir um banco de dados para recuperar espaço não utilizado. Para obter mais informações, consulte Gerenciar espaço de arquivo no Banco de Dados SQL do Azure.

Base de dados georreplicadas

Para alterar o tamanho da base de dados de uma base de dados secundária replicada, altere o tamanho da base de dados principal. Esta alteração também será, em seguida, replicada e implementada na base de dados secundária.

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. Noutras regiões, o armazenamento máximo no escalão Premium está 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. Posteriormente, 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údos relacionados

Para limites gerais de recursos, consulte Limites de recursos baseados em vCore do Banco de Dados SQL do Azure - bancos de dados únicos e Limites de recursos baseados em DTU do Banco de Dados SQL do Azure - bancos de dados únicos.