Camada de computação sem servidor para Banco de Dados SQL do Azure

Aplica-se a: Banco de Dados SQL do Azure

Sem servidor é uma camada de computação para bancos de dados únicos no Banco de Dados SQL do Azure que dimensiona automaticamente a computação com base na demanda da carga de trabalho e cobra pela quantidade de computação usada por segundo. A camada de computação sem servidor também pausa os bancos de dados automaticamente durante períodos inativos quando apenas o armazenamento é cobrado e retoma automaticamente os bancos de dados quando a atividade retorna. A camada de computação sem servidor está disponível na camada de serviço de Uso Geral e na camada de serviço de Hiperescala.

Visão geral

Um intervalo de dimensionamento automático de computação e um atraso de pausa automática são parâmetros importantes para a camada de computação sem servidor. A configuração desses parâmetros forma o custo de computação e a experiência de desempenho do banco de dados.

Configuração de desempenho

• mínimo de vCores e máximo de vCores são parâmetros configuráveis que definem o intervalo de capacidade de computação disponível para o banco de dados. Os limites de memória e E/S são proporcionais ao intervalo de vCore especificado. 
• O atraso de pausa automática é um parâmetro configurável que define o período que o banco de dados deve ficar inativo antes que ele entre automaticamente em pausa. O banco de dados é retomado automaticamente quando o próximo logon ou outra atividade ocorre. Alternativamente, a pausa automática pode ser desabilitada.

Custo

• O custo de um banco de dados sem servidor é a soma do custo de computação e do custo de armazenamento.
• Quando o uso de computação está entre os limites mínimo e máximo configurados, o custo de computação baseia-se no vCore e na memória usada.
• Quando o uso de computação estiver abaixo dos limites mínimos configurados, o custo de computação se baseará no mínimo de vCores e no mínimo de memória configurada.
• Quando o banco de dados é pausado, o custo de computação é zero, e somente os custos de armazenamento são incorridos.
• O custo de armazenamento é determinado da mesma forma que na camada de computação provisionada.

Para obter mais detalhes, consulte Cobrança.

Cenários

A camada sem servidor é otimizada para preço/desempenho para bancos de dados individuais com padrões de uso intermitentes e imprevisíveis que podem gerar atraso no aquecimento de computação após períodos ociosos. Por outro lado, a camada de computação provisionada é otimizada para preço/desempenho para bancos de dados individuais ou múltiplos bancos de dados em pools elásticos com maior uso médio que não podem apresentar atrasos no aquecimento de computação.

Cenários adequados para a computação sem servidor

• Bancos de dados individuais com padrões de uso intermitentes e imprevisíveis intercalados com períodos de inatividade e menor utilização média de computação ao longo do tempo.
• Bancos de dados individuais na camada de computação provisionada que são frequentemente reescalonados e clientes que preferem delegar o reescalonamento de computação para o serviço.
• Novos bancos de dados individuais sem histórico de uso em que o escalonamento de computação é difícil ou impossível de estimar antes da implantação no Banco de Dados SQL do Azure.

Cenários adequados para computação provisionada

• Bancos de dados individuais com padrões de uso mais regulares, previsíveis e maior utilização média de computação ao longo do tempo.
• Bancos de dados que não podem tolerar compensações de desempenho resultantes do corte mais frequente de memória ou do atrasos de retomada após uma pausa.
• Vários bancos de dados com padrões de uso intermitentes e imprevisíveis que podem ser consolidados em pools elásticos para melhor otimização de preços e desempenho.

Comparar camadas de computação

A tabela a seguir resume as diferenças entre a camada de computação sem servidor e a camada de computação provisionada:

Camada de serviço e modelo de compra

A tabela a seguir descreve o suporte sem servidor com base no modelo de compra, nas camadas de serviço e no hardware:

Dimensionamento automático

Capacidade de resposta de dimensionamento

Os bancos de dados sem servidor são executados em um computador com capacidade suficiente para satisfazer as demandas de recursos sem interrupção para qualquer quantidade de computação solicitada dentro dos limites definidos pelo valor de máximo de vCores. Ocasionalmente, o balanceamento de carga ocorrerá automaticamente se o computador não puder atender à demanda de recursos dentro de alguns minutos. Por exemplo, se a demanda de recursos for 4 vCores, mas só 2 vCores estiverem disponíveis, poderá levar alguns minutos para balancear a carga antes do fornecimento de 4 vCores. O banco de dados permanece online durante o balanceamento de carga, exceto por um breve período ao final da operação, quando as conexões são perdidas.

Gerenciamento de memória

Nas camadas de serviço de uso geral e de Hiperescala, a memória de bancos de dados sem servidor é recuperada com mais frequência do que para bancos de dados de computação provisionados. Esse comportamento é importante para controlar os custos na camada sem servidor e pode afetar o desempenho.

Recuperação de cache

Ao contrário dos bancos de dados de computação provisionada, a memória de cache SQL é recuperada de um banco de dados sem servidor quando a utilização de CPU ou de cache ativo for baixa.

• A utilização do cache ativo é considerada baixa quando o tamanho total das entradas de cache usadas mais recentemente fica abaixo de um limite durante um período.
• Quando a recuperação do cache é disparada, o tamanho do cache de destino é reduzido incrementalmente para uma fração do tamanho anterior, e a recuperação só continua se o uso permanece baixo.
• Quando ocorre a recuperação do cache, a política para selecionar entradas de cache a serem removidas é a mesma política de seleção que para bancos de dados de computação provisionados quando a pressão de memória é alta.
• O tamanho do cache nunca é reduzido abaixo do limite mínimo de memória, conforme definido pelo mínimo de vCores.

Em bancos de dados de computação sem servidor e provisionados, as entradas de cache poderão ser removidas se toda a memória disponível for usada.

Quando a utilização da CPU é baixa, a utilização do cache ativo pode ficar alta dependendo do padrão de uso e impedir a recuperação da memória. Além disso, pode haver outros atrasos depois que a atividade do usuário parar antes que a recuperação de memória ocorra, devido a processos periódicos em segundo plano que respondem à atividade anterior do usuário. Por exemplo, operações de exclusão e tarefas de limpeza de Repositório de Consultas geram registros fantasmas que são marcados para exclusão, mas não são excluídos fisicamente até que o processo de limpeza fantasma seja executado. A limpeza de fantasma poderia envolver a leitura de páginas de dados no cache.

Hidratação de cache

O cache de memória do SQL aumenta à medida que os dados são obtidos do disco da mesma forma e com a mesma velocidade dos bancos de dados provisionados. Quando o banco de dados está ocupado, o cache pode aumentar sem restrições enquanto houver memória disponível.

Gerenciamento de cache de disco

No nível de serviço de Hiperescala tanto nas camadas de computação provisionadas e sem servidor, cada réplica de computação usa um cache RBPEX (Extensão do Pool de Buffers Resilientes), que armazena páginas de dados no SSD local para melhorar o desempenho de E/S. No entanto, na camada de computação sem servidor da Hiperescala, o cache RBPEX para cada réplica de computação aumenta e diminui automaticamente em resposta ao aumento e diminuição da demanda de carga de trabalho. O tamanho máximo que o cache RBPEX pode atingir é três vezes a memória máxima configurada para o banco de dados. Para obter detalhes sobre a memória máxima e os limites de dimensionamento automático RBPEX sem servidor, confira os limites de recursos de Hiperescala sem servidor.

Pausa e retomada automáticas

Atualmente, a pausa e a retomada automáticas sem servidor têm suporte apenas na camada de uso geral.

Pausa automática

A pausa automática será ativada se todas as seguintes condições forem verdadeiras durante o atraso de pausa automática:

• Número de sessões = 0
• CPU = 0 para a carga de trabalho do usuário em execução no pool de recursos do usuário

Há uma opção para desativar a pausa automática, se desejado.

Os seguintes recursos não oferecem suporte à pausa automática, mas oferecem suporte ao dimensionamento automático. Se qualquer um dos recursos a seguir for usado, a pausa automática deverá ser desabilitada e o banco de dados permanecerá online, independentemente da duração da inatividade do banco de dados:

• Replicação geográfica (replicação geográfica ativa e grupos de failover).
• Retenção de backup de longo prazo (LTR).
• O banco de dados de sincronização usado na sincronização de dados SQL oferecem suporte à pausa automática, ao contrário dos bancos de dados de sincronização, os bancos de dados de hub e de membros.
• Alias DNS criado para o servidor lógico que contém um banco de dados sem servidor.
• Trabalhos Elásticos, o banco de dados sem servidor habilitado para pausa automática não pode ser usado como um Banco de Dados de Trabalho. Bancos de dados sem servidor direcionados a trabalhos elásticos dão suporte à pausa automática. As conexões de trabalho retomarão um banco de dados.

A pausa automática é evitada temporariamente durante a implantação de algumas atualizações de serviço que exigem que o banco de dados esteja online. Nesses casos, a pausa automática será permitida novamente após o término da atualização do serviço.

Solução de problemas de pausa automática

Se a pausa automática estiver habilitada e os recursos que bloqueiam a pausa automática não forem usados, mas um banco de dados não pausar automaticamente após o período de atraso, as sessões do aplicativo ou do usuário podem estar impedindo a pausa automática.

Para ver se há qualquer aplicativo ou sessões de usuário conectadas ao banco de dados no momento, conecte-se ao banco de dados usando qualquer ferramenta de cliente e execute a seguinte consulta:

SELECT session_id,
       host_name,
       program_name,
       client_interface_name,
       login_name,
       status,
       login_time,
       last_request_start_time,
       last_request_end_time
FROM sys.dm_exec_sessions AS s
INNER JOIN sys.dm_resource_governor_workload_groups AS wg
ON s.group_id = wg.group_id
WHERE s.session_id <> @@SPID
      AND
      (
          (
          wg.name like 'UserPrimaryGroup.DB%'
          AND
          TRY_CAST(RIGHT(wg.name, LEN(wg.name) - LEN('UserPrimaryGroup.DB') - 2) AS int) = DB_ID()
          )
      OR
      wg.name = 'DACGroup'
      );

• Se o conjunto de resultados não estiver vazio, ele indicará que há sessões impedindo a pausa automática no momento.
• Se o conjunto de resultados estiver vazio, ainda é possível que as sessões tenham sido abertas, possivelmente por um curto período, em algum momento anterior durante o período de atraso de pausa automática. Para verificar atividades durante o período de atraso, você pode usar a auditoria de SQL do Azure e examinar os dados de auditoria para o período relevante.

Retomada automática

A retomada automática será ativada se uma das seguintes condições for verdadeira em algum momento:

O monitoramento, o gerenciamento ou outras soluções que executam qualquer uma das operações listadas acima vão disparar a retomada automática. A retomada automática também é disparada durante a implantação de algumas atualizações de serviço que exigem que o banco de dados esteja online.

Conectividade

Se um banco de dados sem servidor estiver em pausa, a primeira tentativa de conexão retomará o banco de dados e gerará um erro informando que o banco de dados está indisponível, com o código de erro 40613. Depois que o banco de dados for retomado, o logon deve ser repetido para estabelecer a conectividade. Os clientes de banco de dados que seguem uma recomendações de lógica de repetição de conexão não devem ser modificados. Para obter opções e recomendações de lógica de repetição de conexão, consulte:

• Lógica de repetição de conexão no SqlClient
• Lógica de repetição de conexão no Banco de Dados SQL usando o Entity Framework Core
• Lógica de repetição de conexão no Banco de Dados SQL usando o Entity Framework 6
• Lógica de repetição de conexão no Banco de dados SQL usando o ADO.NET

Latency

A latência para a retomada e a pausa automática de um banco de dados sem servidor geralmente é uma ordem de 1 minuto para retomar automaticamente e 1 a 10 minutos após a expiração do período de atraso para pausar automaticamente.

Transparent Data Encryption (BYOK) gerenciada pelo cliente

Exclusão ou revogação de chave

Se estiver usando a Transparent Data Encryption (BYOK) gerenciada pelo cliente, e o banco de dados sem servidor for pausado automaticamente quando ocorrer a exclusão ou a revogação da chave, o banco de dados permanecerá no estado de pausa automática. Nesse caso, depois que o banco de dados for retomado, o banco de dados se tornará inacessível dentro de aproximadamente 10 minutos. Quando o banco de dados se tornar inacessível, o processo de recuperação será o mesmo para bancos de dados de computação provisionados. Se o banco de dados sem servidor estiver online quando ocorrer a exclusão ou a revogação de chave, o banco de dados também se tornará inacessível dentro de aproximadamente 10 minutos da mesma forma que com os bancos de dados de computação provisionados.

Alteração de chaves

Se estiver usando a criptografia de dados transparente (BYOK) gerenciada pelo cliente e a pausa automática sem servidor estiver habilitada, o banco de dados será retomado automaticamente sempre que as chaves forem alteradas e, posteriormente, pausado automaticamente quando as condições de pausa automática forem satisfeitas.

Criar um banco de dados sem servidor

Criar um novo banco de dados ou mover um banco de dados existente para uma camada de computação sem servidor segue o mesmo padrão que criar um novo banco de dados em uma camada de computação provisionada e envolve as duas etapas a seguir:

1. Especificar o objetivo de serviço. O objetivo de serviço prescreve a camada de serviço, a configuração de hardware e o máximo de vCores. Para obter as opções de objetivo de serviço, veja Limites de recursos sem servidor

2. Opcionalmente, especifique o atraso de pausa automática e o mínimo de vCores para alterar seus valores padrão. A tabela a seguir mostra os valores disponíveis para esses parâmetros.

   Parâmetro	Opções de valor	Valor padrão
   Mínimo de vCores	Depende do máximo de vCores configurado. Consulte limites de recursos.	vCores de 0,5
   Atraso de pausa automática	Mínimo: 15 minutos Máximo: 10.080 minutos (7 dias) Incrementos: 1 minuto Desabilitar pausa automática: -1	60 minutos

Os exemplos seguintes criam um novo banco de dados na camada de computação sem servidor.

Usar o portal do Azure

Confira Início Rápido: Criar um banco de dados individual no Banco de Dados SQL do Azure usando o portal do Azure.

Usar o PowerShell

New-AzSqlDatabase -ResourceGroupName $resourceGroupName -ServerName $serverName -DatabaseName $databaseName `
  -Edition GeneralPurpose -ComputeModel Serverless -ComputeGeneration Gen5 `
  -MinVcore 0.5 -MaxVcore 2 -AutoPauseDelayInMinutes 720

New-AzSqlDatabase -ResourceGroupName $resourceGroupName -ServerName $serverName -DatabaseName $databaseName ` 
  -Edition Hyperscale -ComputeModel Serverless -ComputeGeneration Gen5 ` 
  -MinVcore 0.5 -MaxVcore 2

New-AzSqlDatabase -ResourceGroupName $resourceGroupName -ServerName $serverName -DatabaseName $databaseName `
  -Edition Hyperscale -ComputeModel Serverless -ComputeGeneration Gen5 `
  -MinVcore 0.5 -MaxVcore 2 `
  -HighAvailabilityReplicaCount 1 -BackupStorageRedundancy Zone -ZoneRedundant

Usar a CLI do Azure

az sql db create -g $resourceGroupName -s $serverName -n $databaseName `
  -e GeneralPurpose --compute-model Serverless -f Gen5 `
  --min-capacity 0.5 -c 2 --auto-pause-delay 720

az sql db create -g $resourceGroupName -s $serverName -n $databaseName ` 
  -e Hyperscale --compute-model Serverless -f Gen5 `
  --min-capacity 0.5 -c 2 

az sql db create -g $resourceGroupName -s $serverName -n $databaseName `
  -e Hyperscale --compute-model Serverless -f Gen5 `
  --min-capacity 0.5 -c 2 `
  --ha-replicas 1 --backup-storage-redundancy Zone --zone-redundant

Usar o Transact-SQL (T-SQL)

Quando você usa T-SQL para criar um novo banco de dados sem servidor, os valores padrão são aplicados para o mínimo de vCores e atraso de pausa automática. Seus valores podem ser alterados posteriormente no portal do Azure ou por meio da API, incluindo PowerShell, CLI do Azure e REST.

Para obter detalhes, consulte CREATE DATABASE.

CREATE DATABASE testdb
( EDITION = 'GeneralPurpose', SERVICE_OBJECTIVE = 'GP_S_Gen5_1' ) ;

ALTER DATABASE testdb  
MODIFY ( SERVICE_OBJECTIVE = 'HS_S_Gen5_2') ; 

Mover um banco de dados entre camadas de computação ou camadas de serviço

Um banco de dados pode ser movido entre a camada de computação provisionada e a camada de computação sem servidor.

Um banco de dados sem servidor também pode ser movido da camada de serviço de Uso Geral para a camada de serviço de Hiperescala. Examine Gerenciar bancos de dados de Hiperescala para saber mais.

Ao mover um banco de dados entre camadas de computação, especifique o parâmetro de modelo de computação como Serverless ou Provisioned ao usar o PowerShell ou a CLI do Azure, ou SERVICE_OBJECTIVE ao usar T-SQL. Revise os limites de recursos para identificar o objetivo de serviço apropriado.

Os exemplos a seguir movem um banco de dados existente de computação provisionada para computação sem servidor.

Usar o PowerShell

Set-AzSqlDatabase -ResourceGroupName $resourceGroupName -ServerName $serverName -DatabaseName $databaseName `
  -Edition GeneralPurpose -ComputeModel Serverless -ComputeGeneration Gen5 `
  -MinVcore 1 -MaxVcore 4 -AutoPauseDelayInMinutes 1440

Set-AzSqlDatabase -ResourceGroupName $resourceGroupName -ServerName $serverName -DatabaseName $databaseName ` 
  -Edition Hyperscale -ComputeModel Serverless -ComputeGeneration Gen5 ` 
  -MinVcore 1 -MaxVcore 4 

Usar a CLI do Azure

az sql db update -g $resourceGroupName -s $serverName -n $databaseName `
  --edition GeneralPurpose --compute-model Serverless --family Gen5 `
  --min-capacity 1 --capacity 4 --auto-pause-delay 1440

az sql db update -g $resourceGroupName -s $serverName -n $databaseName ` 
  --edition Hyperscale --compute-model Serverless --family Gen5 `
  --min-capacity 1 --capacity 4 

Usar o Transact-SQL (T-SQL)

Quando você usa T-SQL para mover um banco de dados entre camadas de computação, os valores padrão são aplicados ao mínimo de vCores e atraso de pausa automática. Seus valores podem ser alterados posteriormente no portal do Azure ou por meio da API, incluindo PowerShell, CLI do Azure e REST. Para saber mais, confira ALTERAR BANCO DE DADOS.

ALTER DATABASE testdb 
MODIFY ( SERVICE_OBJECTIVE = 'GP_S_Gen5_1') ;

ALTER DATABASE testdb  
MODIFY ( SERVICE_OBJECTIVE = 'HS_S_Gen5_2') ; 

Modificar a configuração sem servidor

Usar o PowerShell

Use Set-AzSqlDatabase para modificar os vCores máximos ou mínimos e o atraso da pausa automática. Use os argumentos MaxVcore, MinVcore e AutoPauseDelayInMinutes. A pausa automática sem servidor não tem suporte atualmente na camada de Hiperescala. Portanto, o argumento de atraso da pausa automática só é aplicável à camada de uso geral.

Usar a CLI do Azure

Use az sql db update para modificar o máximo ou mínimo de vCores e o atraso da pausa automática. Use os argumentos capacity, min-capacity e auto-pause-delay. A pausa automática sem servidor não tem suporte atualmente na camada de Hiperescala. Portanto, o argumento de atraso da pausa automática só é aplicável à camada de uso geral.

Monitor

Recursos usados e cobrados

Os recursos de um banco de dados sem servidor incluem o pacote do aplicativo, instância do SQL e entidades do pool de recursos do usuário.

Pacote do Aplicativo

O pacote do aplicativo é o limite externo de gerenciamento de recursos de um banco de dados, independentemente de se o banco de dados está em uma camada de computação sem servidor ou provisionada. O pacote do aplicativo contém a instância do SQL e os serviços externos, como pesquisa de texto completo, que, juntos, englobam todos os recursos de usuário e do sistema usados por um banco de dados no Banco de Dados SQL. Em geral, a instância do SQL domina a utilização geral de recursos no pacote do aplicativo.

Pool de recursos do usuário

O pool de recursos do usuário é um limite interno de gerenciamento de recursos de um banco de dados, independentemente de se o banco de dados está em uma camada de computação sem servidor ou provisionada. O pool de recursos do usuário engloba CPU e E/S para cargas de trabalho do usuário geradas por consultas DDL (CREATE e ALTER) e DML (INSERT, UPDATE, DELETE e MERGE e SELECT). Essas consultas geralmente representam a proporção mais substancial de utilização dentro do pacote do aplicativo.

Métricas

A tabela a seguir inclui métricas de monitoramento do uso de recursos do pacote de aplicativos e o pool de recursos do usuário de um banco de dados sem servidor, incluindo quaisquer réplicas geográficas:

Pausar e retomar status

No caso de um banco de dados sem servidor com a pausa automática habilitada, o status relatado inclui os seguintes valores:

Usar o portal do Azure

No portal do Azure, o status do banco de dados é exibido na página visão geral do banco de dados e do servidor. Também no portal do Azure, o histórico de pausas e os eventos de retomada de um banco de dados sem servidor podem ser exibidos no log de atividades.

Usar o PowerShell

Exiba o status atual do banco de dados usando o seguinte exemplo do PowerShell:

Get-AzSqlDatabase -ResourceGroupName $resourcegroupname -ServerName $servername -DatabaseName $databasename `
  | Select -ExpandProperty "Status"

Usar a CLI do Azure

Exiba o status atual do banco de dados usando o seguinte exemplo da CLI do Azure:

az sql db show --name $databasename --resource-group $resourcegroupname --server $servername --query 'status' -o json

Limites de recursos

Para limites de recursos, consulte camada de computação sem servidor.

Cobrança

A quantidade de computação cobrada por um banco de dados sem servidor é o máximo de CPU e memória usados a cada segundo. Se a quantidade de CPU e memória usada for menor que a quantidade mínima provisionada para cada recurso, a quantidade provisionada será cobrada. Para comparar a CPU com a memória para fins de cobrança, a memória é normalizada em unidades de vCores redimensionando o número de GB em 3 GB por vCore.

• Recurso cobrado: CPU e memória
• Valor cobrado: preço unitário de vCore * máximo (mínimo de vCores, vCores usados, GB de memória mínimo * 1/3, GB de memória usados * 1/3)
• Frequência de cobrança: Por segundo

O preço unitário de vCore é o custo por vCore por segundo.

Consulte a página de preços do Banco de Dados SQL do Azure para obter os preços unitários específicos em uma determinada região.

A quantidade de computação cobrada sem servidor para um banco de dados de uso geral ou uma réplica primária ou nomeada de Hiperescala é exposta pela seguinte métrica:

• Métrica: app_cpu_billed (segundos de vCore)
• Definição: máximo (mínimo de vCores, vCores usados, mínimo de memória em GB * 1/3, GB de memória usados * 1/3)
• Frequência de relatório: por minuto com base em medidas por segundo agregadas ao longo de 1 minuto.

A quantidade de computação cobrada sem servidor para réplicas de HA em Hiperescala pertencentes à réplica primária ou a qualquer réplica nomeada é exposta pela seguinte métrica:

• Métrica: app_cpu_billed_HA_replicas (segundos de vCore)
• Definição: soma do máximo (mínimo de vCores, vCores usados, minínimo de memória em GB * 1/3, memória em GB usada * 1/3) para quaisquer réplicas de HA pertencentes ao recurso pai.
• Recurso pai e ponto de extremidade de métrica: a réplica primária e qualquer réplica nomeada expõem separadamente essa métrica que mede a computação cobrada para quaisquer réplicas HA associadas.
• Frequência de relatório: por minuto com base em medidas por segundo agregadas ao longo de 1 minuto.

Fatura de computação mínima

Se um banco de dados sem servidor for pausado, a fatura de computação será zero. Se um banco de dados sem servidor não estiver pausado, a fatura de computação mínima não será menor que a quantidade de vCores com base no máximo (vCores mínimos, mínimo de memória em GB * 1/3).

Exemplos:

• Suponhamos que um banco de dados na camada de Uso Geral sem servidor não seja pausado e configurado com máximo de 8 vCores e mínimo de 1 vCore correspondente a 3,0 GB de memória mínima. Assim, a conta de computação mínima é baseada no máximo (1 vCore, 3,0 GB * 1 vCore/3 GB) = 1 vCore.
• Suponha que um banco de dados sem servidor na camada de Uso Geral não esteja em pausa e esteja configurado com máximo de 4 vCores e 0,5 mínimo de vCores correspondentes a 2,1 GB de memória mínima. Assim, a conta de computação mínima é baseada no máximo (0,5 vCore, 2,1 GB * 1 vCore/3 GB) = 0,7 vCores.
• Suponha que um banco de dados sem servidor na camada de Hiperescala tenha uma réplica primária com uma réplica de HA e uma réplica nomeada sem réplicas de HA. Suponha que cada réplica seja configurada com máximo de 8 vCores e mínimo de 1 vCore correspondente a 3 GB min de memória. Em seguida, a fatura mínima de computação para a réplica primária, de HA e nomeada são baseadas no máximo (1 vCore, 3 GB * 1 vCore / 3 GB) = 1 vCore.

A calculadora de preços do banco de dados SQL do Azure para sem servidor pode ser usada para determinar a memória mínima configurável com base no número de máximo e mínimo de vCores configurado. Como regra, se mínimo de vCores configurado for superior a 0,5 vCores, a conta de computação mínima será independente da memória mínima configurada e baseada apenas no número mínimo de vCores configurado.

Exemplos de cenário

Benefício Híbrido do Azure e capacidade reserva

O Benefício Híbrido do Azure (AHB) e os descontos de capacidade reservada não se aplicam à camada de computação sem servidor.

Regiões disponíveis

O modo sem servidor para camadas Uso Geral e de Hiperescala com suporte para até 40 vCores estão disponíveis em todo o mundo, exceto nas seguintes regiões:

• Leste da China
• Norte da China
• Alemanha Central
• Nordeste da Alemanha
• US Gov Central (Iowa)

Regiões com suporte a no máximo 80 vCores sem zonas de disponibilidade para Uso Geral e Hiperescala

No momento, há suporte ao máximo de 80 vCores em camadas sem servidor para Uso Geral e Hiperescala nas seguintes regiões:

• Austrália Central 1
• Austrália Central 2
• Leste da Austrália
• Sudeste da Austrália
• Brazil South
• Sudeste do Brasil
• Canadá Central
• Leste do Canadá
• Centro dos EUA
• Leste da China 2
• Leste da China 3
• Norte da China 2
• Norte da China 3
• Leste da Ásia
• Leste dos EUA
• Leste dos EUA 2
• França Central
• Sul da França
• Norte da Alemanha
• Centro-Oeste da Alemanha
• Centro da Índia
• Sul da Índia
• Israel Central
• Norte da Itália
• Leste do Japão
• Oeste do Japão
• Jio India Central
• Jio Oeste da Índia
• Coreia Central
• Sul da Coreia
• Maylaysia South
• México Central
• Centro-Norte dos EUA
• Norte da Europa
• Leste da Noruega
• Oeste da Noruega
• Polônia Central
• Catar Central
• Norte da África do Sul
• Oeste da África do Sul
• Centro-Sul dos Estados Unidos
• Sudeste Asiático
• Espanha Central
• Suécia Central
• Sul da Suécia
• Norte da Suíça
• Oeste da Suíça
• Norte de Taiwan
• Noroeste de Taiwan
• EAU Central
• Norte dos EAU
• Sul do Reino Unido
• Oeste do Reino Unido
• US Gov East
• US Gov Southcentral
• US Gov Southwest
• Europa Ocidental
• Centro-Oeste dos EUA
• Oeste dos EUA
• Oeste dos EUA 2
• Oeste dos EUA 3

Regiões com suporte a no máximo 80 vCores com zonas de disponibilidade para Uso Geral e Hiperescala

No momento, há suporte ao máximo de 80 vCores com zona de disponibilidade sem servidor para as camadas de Uso Geral e Hiperescala oferecido nas seguintes regiões (com plano de adição de mais regiões):

• Leste da Austrália
• Brazil South
• Canadá Central
• Centro dos EUA
• Leste da Ásia
• Leste dos EUA
• Leste dos EUA 2
• França Central
• Centro-Oeste da Alemanha
• Centro da Índia
• Leste do Japão
• Coreia Central
• Norte da Europa
• Norte da África do Sul
• Centro-Sul dos Estados Unidos
• Sudeste Asiático
• Suécia Central
• Norte dos EAU
• Sul do Reino Unido
• US Gov East
• Europa Ocidental
• Oeste dos EUA 2
• Oeste dos EUA 3

Conteúdo relacionado

• Para começar, confira Início rápido: Criar um banco de dados individual - Banco de Dados SQL do Azure.
• Para opções de camada de serviço sem servidor, consulte Uso Geral e Hiperescala.