Perguntas Frequentes sobre a Hiperescala do Banco de Dados SQL do Azure

Um banco de dados de Hiperescala é um Banco de Dados SQL que é apoiado pela tecnologia de armazenamento de expansão da Hiperescala. Um banco de dados Hiperescala suporta até 100 TB de dados e oferece alto rendimento e desempenho, bem como escalonamento rápido para se adaptar aos requisitos de carga de trabalho. Conectividade, processamento de consultas, recursos do mecanismo de banco de dados etc. funcionam como qualquer outro banco de dados no banco de dados SQL do Azure.

A camada de serviço Hiperescala está disponível apenas para bancos de dados individuais usando o modelo de compra baseado em vCore no Banco de Dados SQL do Azure. Ele 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 e no tipo de armazenamento do banco de dados, no desempenho e no tamanho máximo do armazenamento, conforme descrito na comparação de limite de recursos.

A camada de serviço de Hiperescala é para todos os clientes que exigem maior desempenho e disponibilidade, backup e restauração rápidos e/ou escalabilidade de computação e armazenamento rápidos. Isso inclui clientes que estão migrando para a nuvem para modernizar os aplicativos e clientes que já estão usando outras camadas de serviço no Banco de Dados SQL do Azure. Com em Hiperescala, você 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 do banco de dados, independentemente do tamanho do banco de dados (as restaurações são feitas a partir de instantâneos de armazenamento).
• Maior taxa de transferência de logs, 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.
• Escala vertical rápida de computação, de forma constante, para conseguir acomodar a carga de trabalho pesada e depois reduzir verticalmente, de forma constante. As operações de escala levam minutos de um só 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 de Hiperescala está disponível em todas as regiões em que o Banco de Dados SQL do Azure está disponível.

Sim. Para obter mais informações e ver os limites do número de bancos de dados por servidor, confira Limites de recursos do Banco de Dados SQL para bancos de dados individuais e em pool em um servidor.

A arquitetura da Hiperescala oferece alto desempenho e taxa de transferência, dando suporte a grandes banco de dados.

A Hiperescala fornece escalabilidade rápida com base na demanda de carga de trabalho.

• Dimensionamento para cima/para baixo

  A Hiperescala permite escalar verticalmente o tamanho da computação primária em termos de recursos como CPU e memória e, em seguida, reduzir verticalmente em tempo constante. Como o armazenamento é remoto, o aumento e a redução não representam o tamanho da operação de dados.

  O suporte para computação sem servidor fornece ajuste automático de aumento ou redução da escala na vertical, com a computação sendo cobrada com base no uso.

• Dimensionamento In/Out

  Com a hiperescala, 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. Isso inclui:

  • Até quatro réplicas de alta disponibilidade com o mesmo tamanho da computação que as réplicas primárias. Elas servem como réplicas em espera ativa para fazer failover rapidamente da réplica primária. Você também pode usá-las para descarregar cargas de trabalho de leitura da réplica primária.
  • Até 30 réplicas nomeadas tendo um tamanho da computação igual ou diferente da réplica primária, para atender a diversos 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 habilitar a expansão de leitura geográfica.

Sim, você pode.

Não, seu modelo de programação de aplicativo permanece igual em qualquer outro banco de dados MSSQL. Você usa a cadeia de conexão como de costume e os outros modos regulares para interagir com o banco de dados da Hiperescala. Depois de usar o banco de dados de Hiperescala, seu aplicativo pode aproveitar recursos como réplicas secundárias.

Na réplica primária, o nível de isolamento da transação é RCSI (Isolamento de Instantâneo de Leitura Confirmada). Nas réplicas secundárias de escala de leitura, o nível de isolamento padrão é Instantâneo. Isso é o mesmo que ocorre em qualquer outro banco de dados SQL do Azure.

Com o novo preço simplificado em vigor desde 15 de dezembro de 2023, o preço da computação para bancos de dados de Hiperescala recém-criados, para todos os bancos de dados de Hiperescala sem servidor e para todos os pools elásticos de Hiperescala foi reduzido. Com o novo preço simplificado, não há necessidade de aplicar o AHB (Benefício Híbrido do Azure) para obter economias equivalentes. O Benefício Híbrido do Azure (AHB) só pode ser aplicado a bancos de dados únicos Hyperscale mais antigos (criados antes de 15 de dezembro de 2023) com computação provisionada. Para esses bancos de dados mais antigos, o AHB só é aplicável até dezembro de 2026, após o qual esses bancos de dados também serão cobrados conforme o novo preço simplificado. Para obter mais informações, consulte Blog de preços de Hiperescala e Hiperescala do Banco de Dados SQL do Azure – preços mais baixos e simplificados!.

A Hiperescala funciona bem com 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 analíticas interativas no momento, usando o SQL Server como um data warehouse, a Hiperescala é uma ótima opção, pois você pode hospedar data warehouses pequenos e médios (como de alguns TB até 100 TB) a um custo menor e pode migrar a carga de trabalho do data warehouse para a Hiperescala com alterações mínimas no código T-SQL.

Se você estiver executando a análise de dados em grande escala com consultas complexas e taxas de ingestão consistentemente superiores a 100 MB/s ou usando PDW (Parallel Data Warehouse), o Teradata ou outros data warehouses de MPP (Massively Parallel Processing), o Azure Synapse Analytics poderá ser a melhor opção.

Não no momento. No entanto, é possível reduzir a escala de sua computação e o número de réplicas para diminuir o custo fora dos horários de pico, ou usar a tecnologia sem servidor 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 da computação maior (mais núcleos e memória) do que a réplica primária. Para obter mais informações sobre tamanhos de computação disponíveis, confira Armazenamento e tamanhos da computação de Hiperescala.

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

Você pode escalar 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.

Nos bancos de dados da Hiperescala, a resiliência de dados é fornecida no nível de armazenamento. Você só precisa de uma réplica (a primária) para fornecer resiliência. Quando a réplica de cálculo está inativa, uma nova réplica é criada automaticamente sem perda de dados.

No entanto, se houver apenas a réplica primária, a criação de uma réplica após o failover poderá levar um minuto ou dois, ou segundos, caso haja uma réplica secundária de HA disponível. Inicialmente, a nova réplica terá caches frios, o que pode resultar em maior latência de armazenamento e desempenho de consulta reduzido imediatamente após o failover.

Para aplicativos críticos 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 em espera ativa esteja disponível para servir como meta de failover.

100 TB.

Em Hiperescala, 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 aumentar devido a transações com execução prolongada ou se o processamento da Captura de dados de alterações não conseguir acompanhar a taxa de alteração de dados. Evite transações desnecessariamente muito longas e grandes para você 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 com alta taxa de transferência de log. No entanto, a taxa de geração de log pode ser reduzida para cargas de trabalho de gravação agressivamente contínuas. A taxa de pico da geração de log sustentada é de 100 MB/s.

O banco de dados tempdb está localizado no armazenamento SSD local e é dimensionado proporcionalmente ao tamanho da computação (o número de núcleos) provisionada. O tamanho de tempdb não é configurável, sendo gerenciado para você. Para determinar o tamanho máximo de tempdb do banco de dados, confira Armazenamento da hiperescala e tamanhos da computação.

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

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

Cada arquivo de dados aumenta em 10 GB. É possível ter vários arquivos de dados aumentando ao mesmo tempo.

Na Hiperescala, 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 com réplicas de computação remotas. 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 nos servidores de página remotos.

Não. Os arquivos de dados são adicionados automaticamente ao grupo de arquivos PRIMARY. Os motivos comuns para a criação de grupos de arquivos adicionais não se aplicam à arquitetura de armazenamento de Hiperescala nem ao Banco de Dados SQL do Azure mais amplamente.

Não.

Não no momento.

Sim, assim como em qualquer outro banco de dados SQL do Azure. Isso inclui 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 do MSSQL usa a estratégia de preenchimento proporcional para distribuir dados nos arquivos de dados.

Sim. Você pode migrar os bancos de dados existentes no Banco de Dados SQL do Azure para a Hiperescala. Para POCs (provas de conceito), é recomendável fazer uma cópia do banco de dados e migrar a cópia para a Hiperescala.

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

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

A migração reversa para a camada de serviço de Uso 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 de Hiperescala retornem caso a Hiperescala não atenda às necessidades deles. Embora a migração reversa seja iniciada por uma alteração da camada de serviço, é essencialmente uma operação de dimensionamento dos dados entre arquiteturas diferentes. Da mesma forma que a migração para a Hiperescala, a migração reversa será mais rápida se realizada durante um período de baixa atividade de gravação. Conheça as limitações para migração reversa.

Se você já migrou um Banco de Dados SQL do Azure existente para a camada de serviço de Hiperescala, é possível reverter a migração para a camada de serviço de Uso Geral até 45 dias após a migração original para a Hiperescala. Se você quiser migrar o banco de dados para outra camada de serviço, como Comercialmente Crítico, 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 da operação de dados.

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

Saiba como fazer a migração reversa da Hiperescala, incluindo as limitações da migração reversa e as políticas de backup.

Sim. Alguns recursos do Banco de Dados SQL do Azure ainda não são compatíveis com a Hiperescala. Se alguns desses recursos estiverem habilitados no banco de dados, a migração para a Hiperescala poderá ser bloqueada ou esses recursos deixarão de funcionar após a migração. Esperamos que essas limitações sejam temporárias. Para obter detalhes, confira Limitações conhecidas.

Sim. Você pode usar muitas tecnologias de migração existentes para migrar para a Hiperescala, incluindo a replicação transacional e todas as outras tecnologias de movimentação de dados (cópia em massa, Azure Data Factory, Azure Databricks, SSIS). Confira também o Serviço de Migração de Banco de Dados do Azure, que dá suporte a vários cenários de migração.

O tempo de inatividade da migração para a Hiperescala é igual ao tempo de inatividade da migração dos 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 a migração do tempo de inatividade para bancos de dados com poucos TB de tamanho. Para bancos de dados muito grandes (mais de 10 TB), considere implementar o processo de migração usando ADF, Spark ou outras tecnologias de movimentação de dados em massa.

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

Você pode fazer com que um aplicativo cliente leia os dados do Armazenamento do Azure e carregue a carga de dados em um banco de dados da Hiperescala (assim como você pode fazer com qualquer outro banco de dado no Banco de Dados SQL do Azure). No momento, o Polybase não é compatível com o Banco de Dados SQL do Azure. Como alternativa para fornecer carga rápida, você pode usar o Azure data Factory ou um trabalho do Spark no Azure Databricks com o conector do Spark para SQL. O conector do Spark SQL dá suporte à inserção em massa.

Também é possível ler em massa os dados do Armazenamento de Blobs do Azure usando BULK INSERT ou OPENROWSET: exemplos de acesso em massa aos dados no Armazenamento de Blobs do Azure.

A recuperação simples ou o modelo de log em massa não é suportada na Hiperescala. O modelo de recuperação completa é necessário para fornecer alta disponibilidade e recuperação pontual. No entanto, a arquitetura de log da Hiperescala fornece uma melhor taxa de ingestão de dados em comparação a outras camadas de serviço do Banco de Dados SQL do Azure.

Não. A Hiperescala é uma arquitetura de SMP (multiprocessamento simétrico) e não de MPP (processamento paralelo massivo) ou uma arquitetura de vários mestres. Você só pode criar várias réplicas para dimensionar cargas de trabalho somente leitura.

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

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

Sim.

Sim, a Hiperescala dá suporte à configuração com redundância de zona. É necessário pelo menos uma réplica secundária de HA e o uso de armazenamento com redundância de zona ou do armazenamento com redundância de zona geográfica para habilitar a configuração redundante de zona para Hiperescala. O suporte para réplicas nomeadas Hiperescala redundantes de zona está atualmente em versão prévia.

Sim. Os pools elásticos de Hiperescala estão atualmente em versão prévia. Os pools elásticos de Hiperescala com redundância de zona também estão atualmente em versão prévia.

Não há backups tradicionais completos, diferenciais e de log de transações para bancos de dados da Hiperescala. 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 log de transações gerado é mantido no estado em que se encontram no período de retenção configurado. No momento da restauração, os registros de log de transações relevantes são aplicados aos instantâneos de armazenamento restaurados. Independentemente da cadência do instantâneo, isso resulta em um banco de dados com consistência transacional sem perda de dados no momento especificado dentro do período de retenção. Na verdade, o backup de banco de dados na Hiperescala é contínuo.

Sim.

O RPO para restauração pontual é de 0 min. A maioria das operações de restauração pontual é concluída em 60 minutos, independentemente do tamanho do banco de dados. O tempo de restauração pode ser mais longo para bancos de dados maiores e se o banco de dados enfrentar níveis significativos de atividade de gravação antes e até o ponto de restauração no tempo. Alterar a redundância de armazenamento ao emitir uma restauração pode resultar em tempos de restauração mais longos, pois a restauração corresponde ao tamanho dos dados e, portanto, o tempo será proporcional ao tamanho do banco de dados.

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

Sim. A restauração geográfica terá suporte total se o armazenamento com redundância geográfica for usado. Esse é o padrão para novos bancos de dados. Diferentemente da restauração pontual, a restauração geográfica requer uma operação do tamanho dos dados. Os arquivos de dados são copiados paralelamente, de modo que 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 de Hiperescala.

Não. O formato de armazenamento dos bancos de dados da Hiperescala é diferente de qualquer versão de lançamento do SQL Server e você não controla os backups nem tem acesso a eles. Para retirar seus dados de um banco de dados de Hiperescala, 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 serão cobrados com base no armazenamento de backup consumido e na redundância de armazenamento selecionada, de acordo com as taxas capturadas na página de preços do Banco de Dados SQL do Azure. Para bancos de dados em Hiperescala criados antes de 4 de maio de 2022, só haverá cobrança de backups se a retenção de backup estiver definida para ser superior a 7 dias. Para saber mais, confira Backups e redundância de armazenamento de Hiperescala.

Os detalhes sobre como medir o tamanho do armazenamento de backup estão disponíveis em Backups automatizados.

Para determinar sua 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 em um período de tempo, multiplique o tamanho do armazenamento de backup faturável em cada hora do período pela taxa de armazenamento de backup e adicione todos os valores por hora. Para consultar as métricas relevantes do Azure Monitor de vários intervalos por hora de modo programático, use a API REST do Azure Monitor. A cobrança de backup na camada de computação sem servidor é a mesma da camada de computação provisionada.

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

Os detalhes sobre como minimizar os custos de armazenamento de backup estão disponíveis 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 da Hiperescala. 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 uma capacidade de computação suficiente na réplica de computação primária para produzir o log de registro a essa taxa.

O IOPS e a latência de E/S variam dependendo dos padrões de carga de trabalho. Se os dados acessados forem armazenados em cache no RBPEX da réplica de computação, você observará um desempenho de E/S semelhante ao das camadas de serviço Comercialmente Crítico ou Premium.

Não. A computação é separada 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 entre as réplicas de computação primárias e secundárias, a produtividade na réplica primária será diretamente afetada pela adição de réplicas secundárias. No entanto, pode haver a restrição de cargas de trabalho de gravação contínuas e agressivas na réplica primária para permitir que o log seja aplicado nas réplicas secundárias e que os servidores de página atualizem. Isso evita que haja um desempenho de leitura ruim em réplicas secundárias e uma recuperação longa após o failover para uma réplica secundária de HA.

Sim. No entanto, assim como em outros bancos de dados SQL do Azure, as conexões podem ser encerradas por erros transitórios pouquíssimo frequentes, que podem anular consultas com execução prolongada 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 dos 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.

Na maioria dos problemas de desempenho, principalmente os que não são baseados no desempenho do armazenamento, as etapas comuns de diagnóstico e solução de problemas do SQL se aplicam. Para diagnósticos de armazenamento específicos da Hiperescala, confira Diagnóstico de solução de problemas de desempenho da Hiperescala do SQL.

O valor máximo de memória que um banco de dados sem servidor pode escalar verticalmente é 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. Confira Limites de recursos da Hiperescala sem servidor para saber mais.

A expansão ou redução vertical na camada de computação provisionada geralmente demora até dois minutos, independentemente do tamanho dos dados. Na camada de computação sem servidor, na qual a computação é dimensionada automaticamente com base na demanda da carga de trabalho, normalmente o tempo de dimensionamento é inferior a um segundo. Ocasionalmente, pode demorar tanto quanto o dimensionamento na computação provisionada.

Não. Um banco de dados permanece online durante operações de aumento ou redução.

A expansão ou redução da computação provisionada resulta na remoção de conexões em caso de um failover no final da operação de dimensionamento. Na computação sem servidor, a escala automática normalmente não resulta na remoção de uma conexão, mas isso pode ocorrer ocasionalmente. A adição ou remoção de réplicas secundárias não resulta em quedas de conexão na primária.

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

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

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

A Hiperescala dá suporte para réplicas de HA (alta disponibilidade), réplicas nomeadas e réplicas geográficas. Confira mais detalhes em Réplicas secundárias da Hiperescala.

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

Você pode se conectar a essas réplicas de computação adicionais somente leitura configurando a propriedade ApplicationIntent na cadeia de conexão como ReadOnly. Todas as conexões marcadas com ReadOnly são roteadas automaticamente para uma das réplicas secundárias de HA, se houver. Para obter detalhes, confira 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 será 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 precisa ser definido como o nome do seu banco de dados, não como o banco de dados master.

Não. 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ão. Uma nova conexão com a intenção somente leitura é redirecionada para uma réplica secundária de HA arbitrária.

Não está na camada de computação provisionada. As réplicas secundárias de HA são usadas como destinos de failover de alta disponibilidade, portanto, elas precisam ter a mesma configuração que as réplicas primárias para fornecer o desempenho esperado após o failover. No caso da camada sem servidor, a computação é dimensionada automaticamente para cada réplica de HA com base na demanda de carga de trabalho individual. Cada réplica secundária de HA ainda pode ser dimensionada automaticamente para os núcleos máximos configurados a fim de acomodar a função pós-failover. As réplicas nomeadas permitem dimensionar cada réplica de modo independente.

Não. O banco de dados tempdb é configurado com base no tamanho da computação provisionada. As réplicas secundárias de HA são do mesmo tamanho que a computação primária, incluindo tempdb. Em réplicas nomeadas, tempdb é dimensionado de acordo com o tamanho da computação da réplica, portanto, ela pode ser menor ou maior do que tempdb na primária.

Não. 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 você quiser índices adicionais otimizados para leituras nas secundárias, deve adicioná-los na primária. 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 de leitura-gravação.

A latência de dados do momento em que uma transação é confirmada na primária até o momento em que pode ser lida em uma secundária 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 normal para transações pequenas ocorre em dezenas de milissegundos, no entanto, não há limite superior na latência de dados. Os dados de uma determinada réplica secundária têm sempre consistência transacional, portanto, transações maiores levam mais tempo para serem propagadas. No entanto, em determinado momento, a latência de dados e o estado do banco de dados pode ser diferente em 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 as réplicas de alta disponibilidade 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 forma interna de direcionar o tráfego somente leitura enviado às réplicas primárias 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 somente para réplicas nomeadas de 1 a 4, enquanto as cargas de trabalho analíticas do Power BI usam as réplicas nomeadas 5 e 6 e a carga de trabalho de ciência de dados usa as réplicas 7 e 8. Dependendo de qual ferramenta ou linguagem de programação você usa, as estratégias para distribuir tal carga de trabalho podem variar. Para ver um exemplo de criação de uma solução de roteamento de carga de trabalho para permitir que um back-end REST seja escalado horizontalmente, confira a amostra de expansão de OLTP.

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

Uma réplica nomeada não pode afetar a disponibilidade da réplica primária. É improvável que as réplicas nomeadas, sob circunstâncias normais, afetem o desempenho das principais, mas isso poderá acontecer se houver cargas de trabalho intensivas em execução. Assim como uma réplica de HA, uma réplica nomeada é mantida em sincronia com a primária por meio do serviço de log de transações. Se uma réplica nomeada, por qualquer motivo, não puder consumir o log de transações rápido o suficiente, ela começará a pedir à réplica primária que reduza (restringir) a geração de log, para que possa ser atualizada. Embora esse comportamento não afete a disponibilidade da primária, ele poderá afetar o desempenho das cargas de trabalho de gravação na primária. Para evitar essa situação, verifique se as réplicas nomeadas têm reserva dinâmica de recursos suficiente, principalmente a CPU, para processar o log de transações sem atraso. Por exemplo, se a primária estiver processando várias alterações de dados, é recomendável que as réplicas nomeadas tenham pelo menos o mesmo Objetivo de Nível de Serviço da primária para evitar a saturação da CPU nas réplicas e, assim, forçar a primária a desacelerar.

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 possuem suas próprias réplicas de alta disponibilidade. Um failover de uma réplica nomeada requer primeiro a criação de uma nova réplica, o que normalmente leva cerca de 1 a 2 minutos. No entanto, as réplicas nomeadas também podem tirar proveito da maior disponibilidade e dos failovers mais curtos fornecidos pelas réplicas de alta disponibilidade. Para adicionar réplicas de alta disponibilidade, você pode usar o parâmetro ha-replicas com a CLI do AZ, ou o parâmetro HighAvailabilityReplicaCount com o PowerShell, ou a propriedade highAvailabilityReplicaCount com a API REST. O número de réplicas de alta disponibilidade pode ser definido durante a criação de uma réplica nomeada e pode ser alterado (somente por meio da CLI do AZ, do PowerShell ou da API REST) a qualquer momento, depois que a réplica nomeada tiver sido criada. O preço das réplicas de alta disponibilidade para réplicas nomeadas é o mesmo das réplicas de alta disponibilidade para bancos de dados de Hiperescala regulares.

Conteúdo relacionado

Para obter mais informações sobre a camada de serviço da Hiperescala, confira Camada de serviço da Hiperescala.