Base de Dados SQL do Azure sem servidor

Aplica-se a: Base de Dados SQL do Azure

Sem servidor é um escalão de computação para bases de dados individuais na Base de Dados Azure SQL do Azure que dimensiona automaticamente a computação com base na procura da carga de trabalho e nas fatura a quantidade de computação utilizada por segundo. O nível de computação sem servidor também coloca automaticamente em pausa as bases de dados durante períodos inativos quando apenas o armazenamento é faturado e retoma automaticamente as bases de dados quando a atividade é retomada.

Escalão de serviço de computação sem servidor

O nível de cálculo sem servidor para bases de dados individuais em SQL do Azure Database é parametrizado por uma gama de autoscaling computacional e por um atraso de pausa automática. A configuração destes parâmetros molda a experiência de desempenho da base de dados e o custo do cálculo.

faturação sem servidor

Configuração de desempenho

  • Os vCores mínimos e os vCores máximos são parâmetros configuráveis que definem a gama de capacidade de computação disponível para a base de dados. Os limites de memória e IO são proporcionais à gama vCore especificada. 
  • O atraso de pausa automática é um parâmetro configurável que define o período de tempo em que a base de dados deve estar inativa antes de ser automaticamente interrompida. A base de dados é retomada automaticamente quando ocorre o próximo login ou outra atividade. Alternativamente, a pausa automática pode ser desativada.

Custo

  • O custo de uma base de dados sem servidor é a soma do custo de cálculo e do custo de armazenamento.
  • Quando a utilização do cálculo está entre os limites min e máximo configurados, o custo do cálculo baseia-se no vCore e na memória utilizada.
  • Quando a utilização do cálculo está abaixo dos limites min configurados, o custo do cálculo baseia-se no min vCores e na memória min configurada.
  • Quando a base de dados é interrompida, o custo do cálculo é zero e apenas os custos de armazenamento são incorridos.
  • O custo de armazenagem é determinado da mesma forma que no nível de cálculo previsto.

Para mais detalhes sobre custos, consulte Billing.

Cenários

O escalão Sem servidor está otimizado para uma relação preço/desempenho das bases de dados individuais com padrões de utilização imprevisíveis ou intermitentes que se podem permitir ter algum atraso no aquecimento da computação após períodos de inatividade. Em contrapartida, o escalão de computação aprovisionada está otimizado para uma relação preço/desempenho das bases de dados individuais ou das bases de dados múltiplas em conjuntos elásticos com uma utilização acima da média que não se podem permitir ter nenhum tipo de atraso no aquecimento da computação.

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

  • Bases de dados individuais com padrões de utilização intermitentes e imprevisíveis intercalados com períodos de inatividade e uma utilização abaixo da média da computação ao longo do tempo.
  • Bases de dados individuais no escalão de computação aprovisionada que são frequentemente redimensionadas e clientes que preferem delegar o redimensionamento da computação ao serviço.
  • Novas bases de dados individuais sem histórico de utilização onde o dimensionamento da computação é difícil ou impossível de estimar antes da implementação na Base de Dados SQL.

Cenários adequados para o cálculo a provisionado

  • Bases de dados individuais com padrões de utilização mais regulares e previsíveis e uma utilização média mais elevada ao longo do tempo.
  • Bases de dados que não podem tolerar compensações de desempenho resultantes de aparações de memória mais frequentes ou atrasos no recomeço de um estado de pausa.
  • Múltiplas bases de dados com padrões de utilização intermitentes e imprevisíveis que podem ser consolidados em piscinas elásticas para uma melhor otimização do desempenho do preço.

Comparação com o nível de cálculo previsto

O quadro que se segue resume as distinções entre o nível de computação sem servidor e o nível de computação previsto:

Computação sem servidor Cálculo provisionado
Padrão de utilização da base de dados Uso intermitente e imprevisível com menor utilização média do cálculo ao longo do tempo. Padrões de utilização mais regulares com uma utilização média mais alta ao longo do tempo, ou várias bases de dados usando piscinas elásticas.
Esforço de gestão de desempenho Mais baixo Mais alto
Escala de cálculo Automático Manual
Capacidade de resposta computacional Menor após períodos inativos Imediata
Granularidade de faturação Por segundo Por hora

Modelo de compra e nível de serviço

Atualmente, a Base de Dados SQL sem servidor é suportada apenas no escalão de serviço Fins Gerais no hardware da Geração 5 no modelo de compra de vCores.

Dimensionamento automático

Capacidade de resposta de escalonamento

Em geral, as bases de dados sem servidor são executadas numa máquina com capacidade suficiente para satisfazer a procura de recursos sem interrupção por qualquer quantidade de cálculo solicitada dentro dos limites definidos pelo valor máximo vCores. Ocasionalmente, o equilíbrio da carga ocorre automaticamente se a máquina não conseguir satisfazer a procura de recursos dentro de poucos minutos. Por exemplo, se a procura de recursos for de 4 vCores, mas apenas 2 vCores estão disponíveis, então pode levar até alguns minutos para carregar o equilíbrio antes de 4 vCores serem fornecidos. A base de dados permanece on-line durante o equilíbrio de carga, exceto por um breve período no final da operação quando as ligações são largadas.

Gestão da memória

A memória para bases de dados sem servidor é recuperada com mais frequência do que para bases de dados computacional a provisionadas. Este comportamento é importante para controlar os custos em servidores sem servidor e pode ter impacto no desempenho.

Recuperação de cache

Ao contrário das bases de dados de computação a provisionadas, a memória da cache SQL é recuperada a partir de uma base de dados sem servidor quando a CPU ou a utilização de cache ativa são baixas.

  • A utilização ativa da cache é considerada baixa quando o tamanho total das entradas de cache mais recentemente utilizadas fica abaixo de um limiar por um período de tempo.
  • Quando a recuperação da cache é desencadeada, o tamanho da cache alvo é reduzido gradualmente para uma fração do seu tamanho anterior e a recuperação só continua se o uso permanecer baixo.
  • Quando ocorre a recuperação de cache, a política de seleção de entradas de cache para despejar é a mesma política de seleção que para bases de dados de computação a provisionadas quando a pressão da memória é elevada.
  • O tamanho da cache nunca é reduzido abaixo do limite de memória min como definido por min vCores, que pode ser configurado.

Tanto nas bases de dados de computação sem servidor como nas bases de dados de computação a provisionadas, as entradas em cache podem ser despejadas se for utilizada toda a memória disponível.

Quando a utilização do CPU é baixa, a utilização ativa da cache pode permanecer elevada dependendo do padrão de utilização e impedir a recuperação da memória. Além disso, pode haver outros atrasos após a paragem da atividade do utilizador antes que a recuperação da memória ocorra devido a processos periódicos de fundo que respondem à atividade prévia do utilizador. Por exemplo, eliminar operações e tarefas de limpeza da Loja de Consultas geram registos fantasma que estão marcados para eliminação, mas não são fisicamente eliminados até que o processo de limpeza fantasma seja executado. A limpeza fantasma pode envolver a leitura de páginas de dados adicionais em cache.

Hidratação em cache

A cache SQL cresce à medida que os dados são recolhidos do disco da mesma forma e com a mesma velocidade que para bases de dados a provisionadas. Quando a base de dados está ocupada, a cache é permitida a crescer sem restrições até ao limite máximo de memória.

Pausa automática e retoma automática

Pausa automática

A pausa automática é desencadeada 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 utilizador em execução no agrupamento de recursos do utilizador

É fornecida uma opção para desativar a pausa automática, se desejar.

As seguintes funcionalidades não suportam a pausa automática, mas suportam a auto-dimensionamento. Se alguma das seguintes funcionalidades forem utilizadas, então a pausa automática deve ser desativada e a base de dados permanecerá on-line independentemente da duração da inatividade da base de dados:

A pausa automática é temporariamente impedida durante a implementação de algumas atualizações de serviço que exigem que a base de dados esteja online. Nesses casos, a pausa automática torna-se novamente permitida assim que a atualização do serviço estiver concluída.

Resolução automática de problemas

Se a pausa automática estiver ativa, mas uma base de dados não para automaticamente após o período de atraso e as funcionalidades acima enumeradas não são utilizadas, a aplicação ou sessões de utilizador podem estar a impedir a pausa automática. Para ver se existem quaisquer sessões de utilizador ou aplicação atualmente ligadas à base de dados, ligue-se à base de dados através de qualquer ferramenta do 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'
      );

Dica

Depois de executar a consulta, certifique-se de que desliga a base de dados. Caso contrário, a sessão aberta utilizada pela consulta evitará a pausa automática.

Se o conjunto de resultados não estiver vazio, significa que existem sessões atualmente que estão a impedir a pausa automática.

Se o conjunto de resultados estiver vazio, ainda será possível que as sessões estivessem abertas, possivelmente durante um curto período de tempo, em algum momento anteriormente durante o período de atraso da pausa automática. Para ver se tal atividade ocorreu durante o período de atraso, pode utilizar a Auditoria de SQL do Azure e analisar os dados de auditoria do período relevante.

A presença de sessões abertas, com ou sem utilização simultânea da CPU no conjunto de recursos do utilizador, é o motivo mais comum para uma base de dados sem servidor não fazer ser colocada em pausa automática como esperado.

Retoma automática

O reinício automático é desencadeado se alguma das seguintes condições for verdadeira a qualquer momento:

Funcionalidade Gatilho de currículo automático
Autenticação e autorização Iniciar sessão
Deteção de ameaças Ativar/desativar definições de deteção de ameaças ao nível da base de dados ou do servidor.
Modificar definições de deteção de ameaças ao nível da base de dados ou do servidor.
Deteção e classificação de dados Adicionar, modificar, eliminar ou visualizar rótulos de sensibilidade
Auditoria Ver registos de auditoria.
Atualizar ou ver a política de auditoria.
Máscara de dados Adicionar, modificar, eliminar ou ver regras de mascaramento de dados
Encriptação de dados transparente Visualização do estado ou estado da encriptação transparente de dados
Avaliação de vulnerabilidades Exames ad hoc e exames periódicos se ativados
Arquivo de dados (de desempenho) de consulta Modificar ou visualizar definições de lojas de consultas
Recomendações de desempenho Visualização ou aplicação de recomendações de desempenho
Ajuste automático Aplicação e verificação de recomendações de afinação automática, tais como auto-indexação
Cópia de base de dados Criar base de dados como cópia.
Exportar para um ficheiro BACPAC.
Sincronização de dados SQL Sincronização entre bases de dados do hub e dos membros que funcionam num horário configurável ou são realizadas manualmente
Modificar determinados metadados de base de dados Adicionando novas etiquetas de base de dados.
Alterar max vCores, min vCores ou atraso de pausa automática.
SQL Server Management Studio (SSMS) A utilização de versões SSMS antes de 18.1 e a abertura de uma nova janela de consulta para qualquer base de dados no servidor retomará qualquer base de dados auto-pausada no mesmo servidor. Este comportamento não ocorre se utilizar a versão SSMS 18.1 ou posterior.

A monitorização, gestão ou outras soluções que efetuem qualquer uma das operações acima enumeradas desencadeará o reinício automático.

O reinício automático também é desencadeado durante a implementação de algumas atualizações de serviço que exigem que a base de dados esteja online.

Conectividade

Se uma base de dados sem servidor for colocada em pausa, o primeiro início de sessão retomará a base de dados e devolverá um erro a indicar que a base de dados está indisponível com o código de erro 40613. Assim que a base de dados for retomada, o início de sessão terá de ser repetido para estabelecer conectividade. Os clientes da base de dados com lógica de repetição de ligação não devem ser modificados. Para redatórias opções lógicas de ligação que sejam incorporadas ao condutor sqlClient, consulte a lógica de relíndis configurável em SqlClient.

Latência

A latência para retomar automaticamente e fazer uma pausa automática numa base de dados sem servidor é geralmente a ordem de 1 minuto para o currículo automático e 1-10 minutos após o termo do período de atraso para a pausa automática.

Encriptação de dados transparente gerida pelo cliente (BYOK)

Se utilizar a encriptação de dados transparente gerida pelo cliente (BYOK) e a base de dados sem servidor for pausada automaticamente quando ocorre a eliminação ou revogação da chave, então a base de dados permanece no estado de pausa automática. Neste caso, após o recomeço da base de dados, a base de dados torna-se inacessível dentro de aproximadamente 10 minutos. Uma vez que a base de dados se torne inacessível, o processo de recuperação é o mesmo que para bases de dados de computação a provisionadas. Se a base de dados sem servidor estiver on-line quando ocorre a eliminação ou revogação da chave, então a base de dados também se torna inacessível dentro de aproximadamente 10 minutos, da mesma forma que com bases de dados de computação a provisionadas.

Embarque no nível de computação sem servidor

Criar uma nova base de dados ou mover uma base de dados existente para um nível de computação sem servidor segue o mesmo padrão que a criação de uma nova base de dados no nível de computação a provisionado e envolve os dois passos seguintes.

  1. Especifique o objetivo de serviço. O objetivo de serviço prescreve o nível de serviço, configuração de hardware e max vCores. Para opções objetivas de serviço, consulte os limites de recursos sem servidor

  2. Opcionalmente, especifique os min vCores e o atraso de pausa automática para alterar os seus valores predefinidos. A tabela a seguir mostra os valores disponíveis para estes parâmetros.

    Parâmetro Escolhas de valor Valor predefinido
    Min vCores Depende do máximo vCores configurados - ver limites de recursos. 0.5 vCores
    Atraso da automatização Mínimo: 60 minutos (1 hora)
    Máximo: 10080 minutos (7 dias)
    Incrementos: 10 minutos
    Desativar a autopausa: -1
    60 minutos

Criar uma nova base de dados no nível de computação sem servidor

Os exemplos a seguir criam uma nova base de dados no nível de computação sem servidor.

Utilizar o portal do Azure

Consulte Quickstart: Crie uma única base de dados na base de dados SQL do Azure utilizando o portal do Azure.

Utilizar o PowerShell

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

Utilizar a CLI do Azure

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

Utilizar Transact-SQL (T-SQL)

Ao utilizar o T-SQL, são aplicados valores predefinidos para os vcores min e para o atraso da utilização automática. Podem ser posteriormente alterados a partir do portal ou através de outras APIs de gestão (PowerShell, Azure CLI, REST API).

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

Para mais informações, consulte a BASE DE DADOS CREATE.

Mover uma base de dados do nível de computação provisionado para o nível de computação sem servidor

Os exemplos a seguir movem uma base de dados do nível de computação provisionado para o nível de computação sem servidor.

Utilizar o PowerShell

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

Utilizar a CLI do Azure

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

Utilizar Transact-SQL (T-SQL)

Ao utilizar o T-SQL, são aplicados valores predefinidos para os vcores min e para o atraso de pausa automática. Podem ser posteriormente alterados a partir do portal ou através de outras APIs de gestão (PowerShell, Azure CLI, REST API).

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

Para mais informações, consulte a BASE DE DADOS ALTER.

Mover uma base de dados do nível de computação sem servidor para o nível de computação provisionado

Uma base de dados sem servidor pode ser transferida para um nível de computação a provisionado da mesma forma que mover uma base de dados de computação a provisionada para um nível de computação sem servidor.

Modificar a configuração sem servidor

Utilizar o PowerShell

Modificar os vCores máximos ou mínimos e o atraso de utilização automática é realizado utilizando o comando Set-AzSqlDatabase em PowerShell utilizando o MaxVcore, MinVcoree AutoPauseDelayInMinutes os argumentos.

Utilizar a CLI do Azure

Modificar os vCores máximos ou mínimos, e o atraso de automatização, é realizado utilizando o comando de atualização az sql db em Azure CLI utilizando o capacity, min-capacitye auto-pause-delay argumentos.

Monitorização

Recursos utilizados e faturados

Os recursos de uma base de dados sem servidor são encapsulados por pacote de aplicações, instância SQL e entidades de pool de recursos de utilizador.

Pacote de aplicações

O pacote de aplicações é o limite de gestão de recursos mais externo para uma base de dados, independentemente de a base de dados estar num nível de computação sem servidor ou aprovisionado. O pacote de aplicações contém a instância SQL e serviços externos como a Pesquisa de texto completo que todos os conjuntos aplicam todos os recursos do utilizador e do sistema utilizados por uma base de dados em Base de Dados SQL. A instância SQL geralmente domina a utilização global de recursos em todo o pacote de aplicações.

Piscina de recursos do utilizador

O conjunto de recursos do utilizador é um limite de gestão de recursos interno para uma base de dados, independentemente de a base de dados estar num nível de computação sem servidor ou provisionado. O conjunto de recursos do utilizador aplica CPU e IO para a carga de trabalho do utilizador gerada por consultas DDL tais como CREATE e ALTER, consultas DML tais como INSERT, UPDATE, DELETE e MERGE, e consultas SELECT. Estas consultas geralmente representam a proporção mais substancial de utilização dentro do pacote de aplicações.

Métricas

As métricas para monitorizar a utilização de recursos do pacote de aplicações e o conjunto de recursos do utilizador de uma base de dados sem servidor estão listadas na seguinte tabela:

Entidade Metric Descrição Unidades
Pacote de aplicações app_cpu_percent Percentagem de vCores utilizados pela aplicação relativa ao máximo vCores permitido para a aplicação. Percentagem
Pacote de aplicações app_cpu_billed A quantidade de cálculo faturada para a app durante o período de reporte. O valor pago durante este período é o produto desta métrica e do preço unitário vCore.

Os valores desta métrica são determinados agregando ao longo do tempo o máximo de CPU utilizado e a memória utilizada a cada segundo. Se o montante utilizado for inferior ao montante mínimo previsto pela memória min vCores e min, então o montante mínimo previsto é faturado. De modo a comparar a CPU à memória para fins de faturação, a memória é normalizada em unidades de vCores ao redimensionar a quantidade de memória em GB por 3 GB por vCore.
vCore segundos
Pacote de aplicações app_memory_percent Percentagem de memória utilizada pela aplicação relativa à memória máxima permitida para a aplicação. Percentagem
Piscina de recursos do utilizador cpu_percent Percentagem de vCores utilizados pela carga de trabalho do utilizador relativamente ao máximo vCores permitido para a carga de trabalho do utilizador. Percentagem
Piscina de recursos do utilizador data_IO_percent Percentagem de dados IOPS utilizados pela carga de trabalho do utilizador em relação aos dados máximos que o IOPS permitiu para a carga de trabalho do utilizador. Percentagem
Piscina de recursos do utilizador log_IO_percent Percentagem de registo MB/s utilizado pela carga de trabalho do utilizador relativamente ao registo máximo MB/s permitido para a carga de trabalho do utilizador. Percentagem
Piscina de recursos do utilizador workers_percent Percentagem de trabalhadores utilizados pela carga de trabalho dos utilizadores relativamente aos trabalhadores máximos permitidos para a carga de trabalho dos utilizadores. Percentagem
Piscina de recursos do utilizador sessions_percent Percentagem de sessões utilizadas pela carga de trabalho do utilizador em relação às sessões máximas permitidas para a carga de trabalho do utilizador. Percentagem

Pausa e retomar estado

No portal do Azure, o estado da base de dados é apresentado no painel de visão geral do servidor que lista as bases de dados que contém. O estado da base de dados também é apresentado no painel geral da base de dados.

Utilizando os seguintes comandos para consultar a pausa e retomar o estado de uma base de dados:

Utilizar o PowerShell

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

Utilizar a 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 o nível de cálculo sem servidor.

Faturação

A quantidade de computação faturada é o máximo de CPU utilizada e de memória utilizada a cada segundo. Se a quantidade de CPU utilizada e de memória utilizada for inferior à quantidade mínima aprovisionada para cada, será faturada a quantidade mínima aprovisionada. De modo a comparar a CPU à memória para fins de faturação, a memória é normalizada em unidades de vCores ao redimensionar a quantidade de memória em GB por 3 GB por vCore.

  • Recurso faturado: CPU e memória
  • Valor faturado: vCore preço unitário * max (min vCores, vCores usados, min memory GB * 1/3, memória GB usada * 1/3)
  • Frequência de faturação: Por segundo

O preço unitário do vCore é o custo por vCore por segundo. Veja a página de preços da Base de Dados SQL do Azure para obter os preços unitários específicos numa determinada região.

A quantidade de computação faturada é exposta pela seguinte métrica:

  • Métrica: app_cpu_billed (vCore segundos)
  • Definição: máx (min vCores, vCores usados, memória min GB * 1/3, memória GB usada * 1/3)
  • Frequência de reporte: Por minuto

Esta quantidade é calculada a cada segundo e agregada durante um minuto.

Conta de computação mínima

Se uma base de dados sem servidor for interrompida, a conta de cálculo é zero. Se uma base de dados sem servidor não for pausada, então a conta de cálculo mínima não é inferior à quantidade de vCores com base no máximo (min vCores, min memory GB * 1/3).

Exemplos:

  • Suponha que uma base de dados sem servidor não seja pausada e configurada com 8 vCores máximos e 1 min vCore correspondente a memória de 3,0 GB min. Em seguida, a conta mínima do cálculo baseia-se no máximo (1 vCore, 3.0 GB * 1 vCore / 3 GB) = 1 vCore.
  • Suponha que uma base de dados sem servidor não seja pausada e configurada com 4 vCores máximos e 0,5 min vCores correspondentes a 2,1 GB de memória. Em seguida, a conta mínima de cálculo baseia-se no máximo (0,5 vCores, 2.1 GB * 1 vCore / 3 GB) = 0,7 vCores.

A calculadora de preços da base de dados SQL do Azure para sem servidor pode ser utilizada para determinar a memória min configurável com base no número de max e min vCores configurados. Em regra, se o min vCores configurado for superior a 0.5 vCores, então a conta de cálculo mínima é independente da memória min configurada e baseada apenas no número de min vCores configurados.

Cenário de exemplo

Considere uma base de dados sem servidor configurada com 1 min vCore e 4 max vCores. Esta configuração corresponde a cerca de 3 GB de memória e memória máxima de 12 GB. Suponha que o atraso de pausa automática esteja definido para 6 horas e a carga de trabalho da base de dados esteja ativa durante as primeiras 2 horas de um período de 24 horas e de outra forma inativa.

Neste caso, a base de dados é faturada para cálculo e armazenamento durante as primeiras 8 horas. Apesar de a base de dados estar inativa a partir da segunda hora, ainda é faturada para cálculo nas 6 horas seguintes com base no cálculo mínimo previsto enquanto a base de dados está online. Apenas o armazenamento é faturado durante o resto do período de 24 horas enquanto a base de dados é interrompida.

Mais precisamente, a conta de cálculo neste exemplo é calculada da seguinte forma:

Intervalo de tempo vCores usados a cada segundo GB usado a cada segundo Dimensão do cálculo faturada vCore segundos faturados ao longo do intervalo de tempo
0:00-1:00 4 9 vCores usados 4 vCores * 3600 segundos = 14400 vCore segundos
1:00-2:00 1 12 Memória utilizada 12 GB * 1/3 * 3600 segundos = 14400 vCore segundos
2:00-8:00 0 0 Memória min a provisionada 3 GB * 1/3 * 21600 segundos = 21600 vCore segundos
8:00-24:00 0 0 Sem cálculo faturado enquanto pausado 0 vCore segundos
Total de segundos vCore faturados ao longo de 24 horas 50400 vCore segundos

Suponha que o preço unitário do cálculo seja $0.000145/vCore/segundo. Em seguida, o cálculo faturado para este período de 24 horas é o produto do preço unitário do cálculo e dos segundos vCore cobrados: $0.000145/vCore/segundo * 50400 vCore segundos ~ $7,31.

Benefício Híbrido do Azure e capacidade reservada

Benefício Híbrido do Azure (AHB) e descontos de capacidade reservados não se aplicam ao nível de computação sem servidor.

Regiões disponíveis

O nível de computação sem servidores está disponível em todo o mundo, exceto as seguintes regiões: China East, China North, Germany Central, Germany Northeast, e US Gov Central (Iowa).

Passos seguintes