Perguntas frequentes sobre a Base de Dados SQL do Azure Hyperscale

Um banco de dados Hyperscale é um banco de dados no Banco de dados SQL que é apoiado pela tecnologia de armazenamento scale-out Hyperscale. A base de dados Hyperscale suporta até 100 TB de dados e proporciona um débito e desempenho elevados, assim como dimensionamento rápido para se adaptar aos requisitos da carga de trabalho. A conectividade, o processamento de consultas, os recursos do mecanismo de banco de dados e assim por diante, funcionam como qualquer outro banco de dados no Banco de Dados SQL do Azure.

O escalão de serviço Hyperscale só está disponível para bases de dados individuais com o modelo de compra baseado em vCore na Base de Dados SQL do Azure. Não está disponível no modelo de compra baseado em DTU.

As camadas de serviço baseadas em vCore são diferenciadas com base na disponibilidade do banco de dados e no tipo de armazenamento, desempenho e tamanho máximo de armazenamento, conforme descrito na comparação de limites de recursos.

O escalão de serviço Hyperscale é para todos os clientes que precisam de mais desempenho e disponibilidade, cópias de segurança e restauro rápidos e/ou rapidez no armazenamento e escalabilidade computacional. Tal inclui clientes que estão a mudar para a cloud para modernizarem as aplicações e clientes que já estão a utilizar outros escalões de serviço na Base de Dados SQL do Azure. Com o Hyperscale, obtém:

• Tamanho do banco de dados de até 100 TB.
• Backups rápidos de banco de dados, independentemente do tamanho do banco de dados (os backups são baseados em instantâneos de armazenamento).
• Restaurações rápidas de banco de dados, independentemente do tamanho do banco de dados (as restaurações são de snapshots de armazenamento).
• Maior taxa de transferência de log, independentemente do tamanho do banco de dados e do número de vCores.
• Expansão de leitura usando uma ou mais réplicas somente leitura, usadas para descarregamento de leitura ou como bancos de dados em espera ativa.
• Um aumento vertical rápido da computação, com tempo constante, para um acomodamento mais potente da carga de trabalho elevada e, em seguida, uma redução vertical, com tempo constante. As operações de dimensionamento levam minutos de um dígito para computação provisionada e menos de um segundo para computação sem servidor, independentemente do tamanho do banco de dados.

A camada de serviço Hyperscale está disponível em todas as regiões onde o Banco de Dados SQL do Azure está disponível.

Sim. Para obter mais informações e limites sobre o número de bancos de dados por servidor, consulte Limites de recursos do Banco de dados SQL para bancos de dados únicos e agrupados em um servidor.

A arquitetura Hyperscale oferece alto desempenho e taxa de transferência, ao mesmo tempo em que suporta grandes tamanhos de banco de dados.

O Hyperscale fornece escalabilidade rápida com base na sua demanda de carga de trabalho.

• Escalando para cima/para baixo

  Com o Hyperscale, você pode aumentar o tamanho da computação primária em termos de recursos como CPU e memória e, em seguida, reduzir a escala em tempo constante. Como o armazenamento é remoto, o dimensionamento e a redução não são um tamanho de operação de dados.

  O suporte para computação sem servidor fornece escalonamento e redução automáticos, e a computação é cobrada com base no uso.

• Entrada e saída de escala

  Com o Hyperscale, você pode usar três tipos de réplicas secundárias para atender aos requisitos de expansão de leitura, alta disponibilidade e replicação geográfica. O que está incluído:

  • Até quatro réplicas de alta disponibilidade com o mesmo tamanho de computação que a principal. Eles servem como réplicas em espera quente para fazer failover rápido do primário. Você também pode usá-los para descarregar cargas de trabalho de leitura do primário.
  • Até 30 réplicas nomeadas com o mesmo tamanho de computação ou tamanho diferente do principal, para atender a vários cenários de expansão de leitura.
  • Uma réplica geográfica em uma região diferente do Azure para proteger contra interrupções regionais e permitir a expansão de leitura geográfica.

Sim, pode.

Não, seu modelo de programação de aplicativo permanece o mesmo que para qualquer outro banco de dados MSSQL. Você usa sua cadeia de conexão como de costume e as outras maneiras regulares de interagir com seu banco de dados Hyperscale. Depois de usar o Hyperscale, seu aplicativo pode aproveitar recursos como réplicas secundárias.

Na réplica primária, o nível de isolamento de transação padrão é RCSI (Read Committed Snapshot Isolation). Nas réplicas secundárias de Expansão de Leitura, o nível de isolamento padrão é Instantâneo. Isso é o mesmo que em qualquer outro banco de dados SQL do Azure.

Sim, o Benefício Híbrido do Azure está disponível para Hyperscale apenas na camada de computação provisionada. Cada núcleo do SQL Server Standard pode ser mapeado para um vCores Hyperscale. Cada núcleo do SQL Server Enterprise pode ser mapeado para quatro vCores de hiperescala. Você não precisa de uma licença SQL para réplicas secundárias. O preço do Benefício Híbrido do Azure é aplicado automaticamente a réplicas de Expansão de Leitura (secundárias). Consulte computação sem servidor para obter uma opção de cobrança alternativa com base no uso. Nota: Preços simplificados para o SQL Database Hyperscale em breve. Consulte o blog de preços do Hyperscale para obter detalhes.

A hiperescala funciona bem para todos os tipos de carga de trabalho, incluindo cargas de trabalho OLTP, híbridas (HTAP) e analíticas (data mart).

Se você estiver executando consultas de análise interativas usando o SQL Server como um data warehouse, o Hyperscale é uma ótima opção porque você pode hospedar armazéns de dados de pequeno e médio porte (como alguns TB até 100 TB) a um custo mais baixo e pode migrar suas cargas de trabalho de data warehouse do SQL Server para o Hyperscale com alterações mínimas no código T-SQL.

Se você estiver executando análises de dados em grande escala com consultas complexas e taxas de ingestão sustentadas superiores a 100 MB/s ou usando PDW (Parallel Data Warehouse), Teradata ou outros armazéns de dados MPP (Massively Parallel Processing), o Azure Synapse Analytics pode ser a melhor escolha.

Neste momento, não. No entanto, você pode dimensionar sua computação e o número de réplicas para reduzir o custo fora dos horários de pico, ou usar serverless para dimensionar automaticamente a computação com base no uso.

Para cargas de trabalho de leitura, você pode criar uma réplica nomeada com um tamanho de computação maior (mais núcleos e memória) do que a principal. Para obter mais informações sobre tamanhos de computação disponíveis, consulte Armazenamento em hiperescala e tamanhos de computação.

Para cargas de trabalho de leitura, isso pode ser feito usando réplicas nomeadas.

Você pode dimensionar o número de réplicas secundárias de HA entre 0 e 4 usando o portal do Azure ou a API REST. Além disso, você pode criar até 30 réplicas nomeadas para muitos cenários de expansão de leitura.

Em bancos de dados Hyperscale, a resiliência de dados é fornecida no nível de armazenamento. Você só precisa de uma réplica (a principal) para fornecer resiliência. Quando a réplica de computação está inativa, uma nova réplica é criada automaticamente sem perda de dados.

No entanto, se houver apenas a réplica primária, pode levar um ou dois minutos para criar uma nova réplica após o failover, em vez de segundos no caso em que uma réplica secundária HA estiver disponível. A nova réplica terá caches frios inicialmente, o que pode resultar em maior latência de armazenamento e desempenho de consulta reduzido imediatamente após o failover.

Para aplicativos de missão crítica que exigem alta disponibilidade com impacto mínimo de failover, você deve provisionar pelo menos uma réplica secundária de HA para garantir que uma réplica de espera ativa esteja disponível para servir como destino de failover.

100 TB.

No Hyperscale, o log de transações é praticamente infinito, com uma restrição de que a parte ativa do log não pode exceder 1 TB. A parte ativa do log pode crescer devido a transações de longa duração ou devido ao processamento do Change Data Capture não acompanhar a taxa de alteração de dados. Evite transações desnecessariamente longas e grandes para ficar abaixo desse limite. Além dessa restrição, você não precisa se preocupar em ficar sem espaço de log em um sistema que tenha alta taxa de transferência de log. No entanto, a taxa de geração de logs pode ser limitada para cargas de trabalho contínuas de gravação agressiva. A taxa de geração de log sustentada de pico é de 100 MB/s.

Seu tempdb banco de dados está localizado no armazenamento SSD local e é dimensionado proporcionalmente ao tamanho de computação (o número de núcleos) que você provisiona. O tamanho do tempdb não é configurável e é gerenciado para você. Para determinar o tamanho máximo tempdb do banco de dados, consulte Tamanhos de computação e armazenamento em hiperescala.

O tamanho do banco de dados aumenta automaticamente à medida que você insere/ingere mais dados.

10 GB. Um banco de dados Hyperscale é criado com um tamanho inicial de 10 GB e cresce conforme necessário em blocos de 10 GB.

Cada arquivo de dados cresce 10 GB. Vários arquivos de dados podem crescer ao mesmo tempo.

No Hyperscale, os arquivos de dados são armazenados no armazenamento padrão do Azure. Os dados são totalmente armazenados em cache no armazenamento SSD local, em servidores de página remotos para réplicas de computação. Além disso, as réplicas de computação têm caches de dados no SSD local e na memória, para reduzir a frequência de busca de dados de servidores de página remotos.

N.º Os arquivos de dados são adicionados automaticamente ao PRIMARY grupo de arquivos. Os motivos comuns para criar grupos de arquivos adicionais não se aplicam na arquitetura de armazenamento de hiperescala ou no Banco de Dados SQL do Azure de forma mais ampla.

N.º

Neste momento, não.

Sim, assim como em qualquer outro banco de dados do Banco de Dados SQL do Azure. Isso inclui a compactação de linha, página e columnstore.

Sim. As páginas de dados associadas a uma determinada tabela podem acabar em vários arquivos de dados, que fazem parte do mesmo grupo de arquivos. O mecanismo de banco de dados MSSQL usa a estratégia de preenchimento proporcional para distribuir dados em arquivos de dados.

Sim. Você pode mover seus bancos de dados existentes no Banco de Dados SQL do Azure para o Hyperscale. Para provas de conceito (POCs), recomendamos que você faça uma cópia do seu banco de dados e migre a cópia para o Hyperscale.

O tempo necessário para mover um banco de dados existente para o Hyperscale consiste no tempo para copiar dados e o tempo para reproduzir as alterações feitas no banco de dados de origem durante a cópia de dados. O tempo de cópia dos dados é proporcional ao tamanho dos dados. O tempo para reproduzir as alterações será menor se a mudança for feita durante um período de baixa atividade de gravação.

Obtenha código de exemplo para migrar Bancos de Dados SQL do Azure existentes para Hyperscale no portal do Azure, CLI do Azure, PowerShell e Transact-SQL em Migrar um banco de dados existente para Hyperscale.

A migração reversa para a camada de serviço de Propósito Geral permite que os clientes que migraram recentemente um banco de dados existente no Banco de Dados SQL do Azure para a camada de serviço Hyperscale voltem, caso o Hyperscale não atenda às suas necessidades. Embora a migração reversa seja iniciada por uma alteração na camada de serviço, ela é essencialmente uma operação de tamanho de dados entre diferentes arquiteturas. Da mesma forma que a migração para o Hyperscale, a migração reversa será mais rápida se feita durante um período de baixa atividade de gravação. Conheça as limitações da migração inversa.

Se você tiver migrado anteriormente um Banco de Dados SQL do Azure existente para a camada de serviço Hyperscale, poderá revertê-lo para a camada de serviço de Propósito Geral dentro de 45 dias da migração original para Hyperscale. Se desejar migrar o banco de dados para outra camada de serviço, como Business Critical, primeiro faça a migração reversa para a camada de serviço de uso geral e, em seguida, modifique a camada de serviço. A migração reversa é um tamanho de operação de dados.

Os bancos de dados criados na camada de serviço Hyperscale não podem ser movidos para outras camadas de serviço.

Saiba como reverter a migração do Hyperscale, incluindo as limitações da migração reversa e as políticas de backup afetadas.

Sim. Alguns recursos do Banco de Dados SQL do Azure ainda não têm suporte no Hyperscale. Se alguns desses recursos estiverem habilitados para seu banco de dados, a migração para o Hyperscale poderá ser bloqueada ou esses recursos deixarão de funcionar após a migração. Esperamos que estas limitações sejam temporárias. Para obter detalhes, consulte Limitações conhecidas.

Sim. Você pode usar muitas tecnologias de migração existentes para migrar para o Hyperscale, incluindo replicação transacional e quaisquer outras tecnologias de movimentação de dados (Bulk Copy, Azure Data Factory, Azure Databricks, SSIS). Consulte também o Serviço de Migração de Banco de Dados do Azure, que dá suporte a muitos cenários de migração.

O tempo de inatividade para a migração para o Hyperscale é o mesmo que o tempo de inatividade quando você migra seus bancos de dados para outras camadas de serviço do Banco de Dados SQL do Azure. Você pode usar a replicação transacional para minimizar o tempo de inatividade da migração para bancos de dados de até alguns TB de tamanho. Para bancos de dados muito grandes (10+ TB), você pode considerar a implementação do processo de migração usando ADF, Spark ou outras tecnologias de movimentação de dados em massa.

O Hyperscale é capaz de consumir 100 MB/s de dados novos/alterados, mas o tempo necessário para mover dados para bancos de dados no Banco de Dados SQL do Azure também é afetado pela taxa de transferência de rede disponível, velocidade de leitura de origem e o objetivo de nível de serviço do banco de dados de destino.

Você pode fazer com que um aplicativo cliente leia dados do Armazenamento do Azure e carregue a carga de dados em um banco de dados Hyperscale (assim como você pode fazer com qualquer outro banco de dados no Banco de Dados SQL do Azure). Atualmente, não há suporte para o Polybase no Banco de Dados SQL do Azure. Como alternativa para fornecer carregamento rápido, você pode usar o Azure Data Factory ou usar um trabalho do Spark no Azure Databricks com o conector Spark para SQL. O conector Spark para SQL suporta inserção em massa.

Também é possível ler dados em massa do repositório de Blobs do Azure usando BULK INSERT ou OPENROWSET: Exemplos de acesso em massa a dados no Armazenamento de Blobs do Azure.

Não há suporte para recuperação simples ou modelo de log em massa no Hyperscale. O modelo de recuperação completa é necessário para fornecer alta disponibilidade e recuperação point-in-time. No entanto, a arquitetura de log do Hyperscale fornece uma melhor taxa de ingestão de dados em comparação com outras camadas de serviço do Banco de Dados SQL do Azure.

N.º A hiperescala é uma arquitetura simétrica de multiprocessamento (SMP) e não é um processamento paralelo maciço (MPP) ou uma arquitetura multimestre. Você só pode criar várias réplicas para expandir cargas de trabalho somente leitura.

Sim. O Serviço de Migração de Banco de Dados do Azure dá suporte a muitos cenários de migração.

Consulte SLA para o Banco de Dados SQL do Azure. Recomendamos adicionar réplicas secundárias de HA para cargas de trabalho críticas. Isso proporciona failover mais rápido e reduz o impacto potencial no desempenho imediatamente após o failover.

Sim.

Sim, o Hyperscale suporta configuração redundante de zona. Pelo menos uma réplica secundária de HA e o uso de armazenamento com redundância de zona ou geozona são necessários para habilitar a configuração redundante de zona para Hyperscale.

Não existem cópias de segurança tradicionais completas, diferenciais e de registos de transações para bases de dados Hyperscale. Em vez disso, há instantâneos de armazenamento regulares de arquivos de dados, com uma cadência de instantâneo separada para cada arquivo. O registo de transações gerado é mantido tal como está durante o período de retenção configurado. No momento da restauração, os registros de log de transações relevantes são aplicados aos snapshots de armazenamento restaurados. Independentemente da cadência do snapshot, isso resulta em um banco de dados transacionalmente consistente sem qualquer perda de dados a partir do point-in-time especificado dentro do período de retenção. Na verdade, o backup de banco de dados no Hyperscale é contínuo.

Sim.

O RPO para restauração point-in-time é de 0 min. A maioria das operações de restauração point-in-time é concluída em 60 minutos, independentemente do tamanho do banco de dados. O tempo de restauração pode ser maior para bancos de dados maiores e se o banco de dados tiver tido uma atividade de gravação significativa antes e até o ponto de restauração. Alterar a redundância de armazenamento ao emitir uma restauração pode resultar em tempos de restauração mais longos, pois a restauração é o tamanho dos dados e, portanto, o tempo será proporcional ao tamanho do banco de dados.

N.º Os backups são gerenciados pelo subsistema de armazenamento e usam snapshots de armazenamento. Eles não afetam as cargas de trabalho do usuário.

Sim. A restauração geográfica é totalmente suportada se o armazenamento com redundância geográfica for usado. Este é o padrão para novos bancos de dados. Ao contrário da restauração point-in-time, a restauração geográfica requer uma operação de tamanho de dados. Os arquivos de dados são copiados em paralelo, portanto, a duração dessa operação depende principalmente do tamanho do maior arquivo no banco de dados, em vez do tamanho total do banco de dados. O tempo de restauração geográfica será significativamente menor se o banco de dados for restaurado na região do Azure emparelhada com a região do banco de dados de origem.

Sim. A replicação geográfica pode ser configurada para bancos de dados Hyperscale.

N.º O formato de armazenamento para bancos de dados Hyperscale é diferente de qualquer versão lançada do SQL Server e você não controla backups nem tem acesso a eles. Para retirar seus dados de um banco de dados Hyperscale, você pode extrair dados usando qualquer tecnologia de movimentação de dados, ou seja, Azure Data Factory, Azure Databricks, SSIS, etc.

Sim. A partir de 4 de maio de 2022, os backups de todos os novos bancos de dados são cobrados com base no armazenamento de backup consumido e na redundância de armazenamento selecionada com taxas capturadas na página de preços do Banco de Dados SQL do Azure. Para bancos de dados Hyperscale criados antes de 4 de maio de 2022, os backups serão cobrados somente se a retenção de backup estiver definida como superior a sete dias. Para saber mais, consulte Backups em hiperescala e redundância de armazenamento.

Os detalhes sobre como medir o tamanho do armazenamento de backup são capturados em Backups automatizados.

Para determinar a fatura de armazenamento de backup, o tamanho do armazenamento de backup é calculado periodicamente e multiplicado pela taxa de armazenamento de backup e pelo número de horas desde o último cálculo. Para estimar sua fatura de backup para um período de tempo, multiplique o tamanho de armazenamento de backup faturável para cada hora do período pela taxa de armazenamento de backup e adicione todos os valores por hora. Para consultar métricas relevantes do Azure Monitor para vários intervalos horários programaticamente, use a API REST do Azure Monitor. O faturamento de backup na camada de computação sem servidor é o mesmo que na camada de computação provisionada.

Os custos de backup serão maiores para cargas de trabalho que adicionam, modificam ou excluem grandes volumes de dados no banco de dados. Por outro lado, cargas de trabalho que são principalmente somente leitura podem ter custos de backup menores.

Os detalhes sobre como minimizar os custos de armazenamento de backup são capturados em backups automatizados.

O limite de taxa de transferência do log de transações é definido como 100 MB/s para qualquer tamanho de computação Hyperscale. A capacidade de atingir essa taxa depende de vários fatores, incluindo, entre outros, o tipo de carga de trabalho, a configuração e o desempenho do cliente, e ter capacidade de computação suficiente na réplica de computação primária para produzir registros de log nessa taxa.

A latência de IOPS e IO variará dependendo dos padrões de carga de trabalho. Se os dados acessados estiverem armazenados em cache no RBPEX na réplica de computação, você verá um desempenho de E/S semelhante ao das camadas de serviço Business Critical ou Premium.

N.º A computação é dissociada da camada de armazenamento. Isso elimina o impacto no desempenho do backup.

Como o armazenamento é compartilhado e não há replicação física direta acontecendo entre réplicas de computação primárias e secundárias, a taxa de transferência na réplica primária não será diretamente afetada pela adição de réplicas secundárias. No entanto, cargas de trabalho de gravação contínuas e agressivas podem ser limitadas no primário para permitir que a aplicação de log em réplicas secundárias e servidores de página se atualizem. Isso evita um desempenho de leitura ruim em réplicas secundárias e recuperação longa após o failover para uma réplica secundária HA.

Sim. No entanto, assim como em outros bancos de dados do Banco de Dados SQL do Azure, as conexões podem ser encerradas por erros transitórios muito pouco frequentes, que podem abortar consultas de longa execução e reverter transações. Uma causa de erros transitórios é quando o sistema muda rapidamente o banco de dados para um nó de computação diferente para garantir a disponibilidade contínua de recursos de computação e armazenamento ou para executar a manutenção planejada. A maioria desses eventos de reconfiguração termina em menos de 10 segundos. Os aplicativos que se conectam ao seu banco de dados devem ser criados para esperar e tolerar esses erros transitórios pouco frequentes implementando a lógica de repetição. Além disso, considere configurar uma janela de manutenção que corresponda à sua agenda de carga de trabalho para evitar erros transitórios devido à manutenção planejada.

Para a maioria dos problemas de desempenho, particularmente aqueles que não estão enraizados no desempenho do armazenamento, aplicam-se etapas comuns de diagnóstico e solução de problemas do SQL. Para diagnósticos de armazenamento específicos do Hyperscale, consulte SQL Hyperscale performance troubleshooting diagnostics.

A quantidade máxima de memória que um banco de dados sem servidor pode escalar é de 3 GB/vCore vezes o número máximo de vCores configurados, em comparação com mais de 5 GB/vCore vezes o mesmo número de vCores na computação provisionada. Analise os limites de recursos do Hyperscale sem servidor para obter detalhes.

O dimensionamento para cima ou para baixo na camada de computação provisionada normalmente leva até 2 minutos, independentemente do tamanho dos dados. Na camada de computação sem servidor, onde a computação é dimensionada automaticamente com base na demanda de carga de trabalho, o tempo de dimensionamento normalmente é de subsegundo, mas ocasionalmente pode levar tanto tempo quanto ao dimensionamento da computação provisionada.

N.º Um banco de dados permanece on-line durante operações de aumento ou redução de escala.

O dimensionamento da computação provisionada para cima ou para baixo resulta na desativação de conexões quando ocorre um failover no final da operação de dimensionamento. Na computação sem servidor, o dimensionamento automático normalmente não resulta na queda de uma conexão, mas pode ocorrer ocasionalmente. Adicionar ou remover réplicas secundárias não resulta em quedas de conexão na principal.

O dimensionamento na computação provisionada é realizado pelo usuário final. O dimensionamento automático na computação sem servidor é realizado pelo serviço.

Sim. O tamanho do banco de dados e do tempdb cache RBPEX nos nós de computação aumenta automaticamente à medida que o número de núcleos é aumentado. Para obter detalhes, consulte Armazenamento em hiperescala e tamanhos de computação.

N.º Somente a réplica de computação primária aceita solicitações de leitura/gravação. As réplicas de computação secundárias só aceitam solicitações somente leitura.

O Hyperscale oferece suporte a réplicas de alta disponibilidade (HA), réplicas nomeadas e réplicas geográficas. Consulte Réplicas secundárias de hiperescala para obter detalhes.

Entre 0 e 4. Se quiser ajustar o número de réplicas, você pode fazer isso usando o portal do Azure ou a API REST.

Você pode se conectar a essas réplicas de computação somente leitura adicionais definindo a ApplicationIntent propriedade em sua cadeia de conexão como ReadOnly. Todas as conexões marcadas com ReadOnly são automaticamente roteadas para uma das réplicas secundárias de HA, se houver. Para obter detalhes, consulte Usar réplicas somente leitura para descarregar cargas de trabalho de consulta somente leitura.

Você pode executar a seguinte consulta T-SQL: SELECT DATABASEPROPERTYEX ('<database_name>', 'Updateability'). O resultado é READ_ONLY se você estiver conectado a uma réplica secundária somente leitura e READ_WRITE se estiver conectado à réplica primária. O contexto do banco de dados deve ser definido como o nome do seu banco de dados, não para o master banco de dados.

N.º Você só pode se conectar a réplicas secundárias de HA especificando ApplicationIntent=ReadOnly. No entanto, você pode usar pontos de extremidade dedicados para réplicas nomeadas.

N.º Uma nova conexão com intenção somente leitura é redirecionada para uma réplica secundária de HA arbitrária.

Não na camada de computação provisionada. As réplicas secundárias de HA são usadas como destinos de failover de alta disponibilidade, portanto, precisam ter a mesma configuração que a principal para fornecer o desempenho esperado após o failover. No serverless, a computação é dimensionada automaticamente para cada réplica de HA com base em sua demanda de carga de trabalho individual. Cada HA secundária ainda pode ser dimensionada automaticamente para os núcleos máximos configurados para acomodar sua função pós-failover. As réplicas nomeadas oferecem a capacidade de dimensionar cada réplica de forma independente.

N.º Seu tempdb banco de dados é configurado com base no tamanho de computação provisionado, suas réplicas secundárias de HA têm o mesmo tamanho, incluindo tempdb, como a computação primária. Em réplicas nomeadas, é dimensionado de acordo com o tamanho de computação da réplica, portanto, tempdb pode ser menor ou maior do que tempdb na primária.

N.º Os bancos de dados de hiperescala têm armazenamento compartilhado, o que significa que todas as réplicas de computação veem as mesmas tabelas, índices e outros objetos de banco de dados. Se quiser índices adicionais otimizados para leituras no secundário, você deve adicioná-los no primário. Você ainda pode criar tabelas temporárias (nomes de tabela prefixados com # ou ##) em cada réplica secundária para armazenar dados temporários. As tabelas temporárias são leitura-gravação.

A latência de dados desde o momento em que uma transação é confirmada no primário até o momento em que é legível em um secundário depende da taxa de geração de log atual, do tamanho da transação, da carga na réplica e de outros fatores. A latência de dados típica para pequenas transações é de dezenas de milissegundos, no entanto, não há limite superior para a latência de dados. Os dados em uma determinada réplica secundária são sempre transacionalmente consistentes, portanto, transações maiores levam mais tempo para se propagar. No entanto, em um determinado momento, a latência de dados e o estado do banco de dados podem ser diferentes para réplicas secundárias diferentes. As cargas de trabalho que precisam ler dados confirmados imediatamente devem ser executadas na réplica primária.

Não, as réplicas nomeadas não podem ser usadas como destinos de failover para a réplica primária. Adicione réplicas HA para essa finalidade.

Como cada réplica nomeada pode ter um objetivo de nível de serviço diferente e, portanto, ser usada para diferentes casos de uso, não há uma maneira interna de direcionar o tráfego somente leitura enviado para o primário para um conjunto de réplicas nomeadas. Por exemplo, você pode ter oito réplicas nomeadas e talvez queira direcionar a carga de trabalho OLTP apenas para réplicas nomeadas de 1 a 4, enquanto as cargas de trabalho analíticas do Power BI usam réplicas nomeadas 5 e 6 e a carga de trabalho de ciência de dados usa réplicas 7 e 8. Dependendo da ferramenta ou linguagem de programação usada, as estratégias para distribuir essa carga de trabalho podem variar. Para obter um exemplo de criação de uma solução de roteamento de carga de trabalho para permitir que um back-end REST seja dimensionado, revise o exemplo de expansão OLTP.

Não, como as réplicas nomeadas usam os mesmos servidores de página da réplica primária, elas devem estar na mesma região.

Uma réplica nomeada não pode afetar a disponibilidade da réplica primária. É improvável que réplicas nomeadas, em circunstâncias normais, afetem o desempenho do primário, mas isso pode acontecer se houver cargas de trabalho intensivas em execução. Assim como uma réplica HA, uma réplica nomeada é mantida em sincronia com a principal por meio do serviço de log de transações. Se uma réplica nomeada, por qualquer motivo, não for capaz de consumir o log de transações com rapidez suficiente, ela começará a pedir à réplica primária para diminuir (acelerar) sua geração de log, para que possa recuperar o atraso. Embora esse comportamento não afete a disponibilidade do primário, ele pode afetar o desempenho de cargas de trabalho de gravação no principal. Para evitar essa situação, certifique-se de que suas réplicas nomeadas tenham espaço suficiente para recursos – principalmente CPU – para processar o log de transações sem demora. Por exemplo, se o primário estiver processando várias alterações de dados, é recomendável ter réplicas nomeadas com pelo menos o mesmo Objetivo de Nível de Serviço que o principal, para evitar saturar a CPU nas réplicas e, assim, forçar o primário a ficar mais lento.

As réplicas nomeadas ainda estarão disponíveis para acesso somente leitura, como de costume.

Por padrão, as réplicas nomeadas não têm réplicas HA próprias. Um failover de uma réplica nomeada requer a criação de uma nova réplica primeiro, o que normalmente leva cerca de 1 a 2 minutos. No entanto, as réplicas nomeadas também podem se beneficiar de maior disponibilidade e failovers mais curtos fornecidos pelas réplicas HA. Para adicionar réplicas HA para uma réplica nomeada, você pode usar o parâmetro com AZ CLI ou o parâmetro ha-replicasHighAvailabilityReplicaCount com PowerShell ou a propriedade com API highAvailabilityReplicaCount REST. O número de réplicas HA pode ser definido durante a criação de uma réplica nomeada e pode ser alterado – somente por meio da AZ CLI, PowerShell ou API REST – a qualquer momento após a réplica nomeada ter sido criada. O preço das réplicas HA para réplicas nomeadas é o mesmo das réplicas HA para bancos de dados Hyperscale regulares.

Conteúdos relacionados

Para obter mais informações sobre a camada de serviço Hyperscale, consulte Hyperscale service tier.