Secundárias ativas: réplicas secundárias legíveis (Grupos de Disponibilidade AlwaysOn)

Os recursos secundários ativos do Grupos de Disponibilidade AlwaysOn incluem suporte para acesso somente leitura para uma ou mais réplicas secundárias (réplicas secundárias legíveis). Uma réplica secundária legível permite acesso somente leitura a todos os seus bancos de dados secundários. No entanto, os bancos de dados secundários legíveis não são definidos como somente leitura. Eles são dinâmicos. Um banco de dados secundário determinado muda conforme as alterações nos dados do banco de dados primário correspondente são aplicadas ao banco de dados secundário. Para uma réplica secundária típica, os dados nos bancos de dados secundários estão quase em tempo real. Além disso, os índices de texto completo são sincronizados com os bancos de dados secundários. Em muitas circunstâncias, a latência de dados entre um banco de dados primário e o banco de dados secundário correspondente é de somente alguns segundos.

Configurações de segurança que ocorrem nos bancos de dados primários para os bancos de dados secundários são permitidas. Isso inclui os usuários, as funções de banco de dados e de aplicativos junto com suas permissões respectivas e a TDE (criptografia de dados transparente), se habilitada no banco de dados primário.

Observação
Embora você não possa gravar dados nos bancos de dados secundários, é possível gravar em bancos de dados de leitura e gravação na instância de servidor que hospeda a réplica secundária, incluindo bancos de dados de usuário e do sistema, como tempdb.

O Grupos de Disponibilidade AlwaysOn também dá suporte ao reencaminhamento de solicitações de conexão de intenção de leitura para uma réplica secundária legível (roteamento somente leitura). Para obter informações sobre roteamento somente leitura, consulte Usando um ouvinte para conectar-se a uma réplica secundária somente leitura (roteamento somente leitura).

Neste tópico:

• Benefícios

• Pré-requisitos para o grupo de disponibilidade

• Limitações e restrições

• Considerações sobre desempenho

• Considerações sobre o planejamento de capacidade

• Tarefas relacionadas

• Conteúdo relacionado

Benefícios

Direcionar conexões somente leitura a réplicas secundárias legíveis tem os seguintes benefícios:

• Descarrega suas cargas de trabalho somente leitura secundárias de sua réplica primária, o que conserva seus recursos para cargas de trabalho críticas. Se você tiver missão carga de trabalho de leitura crítica ou que não possa tolerar latência, execute-a na primária.

• Melhora seu retorno de investimento para os sistemas que hospedam réplicas secundárias legíveis.

Além disso, secundárias legíveis fornecem suporte robusto para operações somente leitura, como segue:

• Estatísticas temporárias sobre o banco de dados secundário legível otimizam as consultas somente leitura. Para obter informações, consulte Estatísticas para bancos de dados somente leitura, mais adiante neste tópico.

• As cargas de trabalho somente leitura usam o controle de versão de linha para remover a contenção de bloqueio nos bancos de dados secundários. Todas as consultas executadas nos bancos de dados secundários são mapeadas automaticamente para o nível de transação de isolamento de instantâneo, até mesmo quando outros níveis de isolamento de transação são definidos explicitamente. Além disso, todas as dicas de bloqueio são ignoradas. Isso elimina a contenção do leitor/gravador.

[Início]

Pré-requisitos para o grupo de disponibilidade

• Réplicas secundárias legíveis (obrigatório)

  O administrador de banco de dados precisa configurar uma ou mais réplicas de forma que, ao ser executado sob a função secundária, eles permitem todas as conexões (apenas para acesso somente leitura) ou apenas conexões de intenção de leitura.

  Observação
  Como opção, o administrador de banco de dados pode configurar qualquer réplica de disponibilidade para excluir conexões somente leitura ao executar sob a função primária.

  Para obter mais informações, consulte Sobre Acesso de conexão de cliente a réplicas de disponibilidade (SQL Server).

• Ouvinte de grupo de disponibilidade

  Para dar suporte a roteamento somente leitura, um grupo de disponibilidade deve ter um ouvinte de grupo de disponibilidade. O cliente somente leitura deve direcionar suas solicitações de conexão para este ouvinte e a cadeia de conexão do cliente deve especificar a intenção do aplicativo como "somente leitura." Ou seja, elas devem ser solicitações de conexão de intenção de leitura.

• Roteamento somente leitura

  Roteamento somente leitura refere-se à capacidade de o SQL Server rotear solicitações de conexão de intenção de leitura, que são direcionadas para um ouvinte de grupo de disponibilidade, para uma réplica secundária legível disponível. Os pré-requisitos para roteamento somente leitura são os seguintes:

  • Para dar suporte a roteamento somente leitura, uma réplica secundária legível exigirá uma URL de roteamento somente leitura. Esta URL só entra em vigor quando a réplica local estiver sendo executada sob a função secundária. A URL do roteamento somente leitura deve ser especificada réplica por réplica, quando necessário. Cada URL de roteamento somente leitura é usado para solicitações de conexão de intenção de leitura para uma réplica secundária legível específica. Normalmente, toda réplica secundária legível é atribuída uma URL de roteamento somente leitura.

  • Cada réplica de disponibilidade que deve dar suporte a roteamento somente leitura quando é a réplica primária exige uma lista de roteamento somente leitura. Uma determinada lista de roteamento somente leitura só entra em vigor quando a réplica local estiver sendo executada em uma função primária. Essa lista deve ser especificada réplica por réplica, quando necessário. Normalmente, cada lista de roteamento somente leitura deveria conter todas as URLs de roteamento somente leitura, com a URL da réplica local no final da lista.

    Observação
    As solicitações e conexão de intenção de leitura são roteadas para a primeira réplica secundária legível disponível na lista de roteamento somente leitura da réplica primária atual. Não há nenhum balanceamento de carga.

  Para obter mais informações, consulte Configurar o roteamento somente leitura para um grupo de disponibilidade (SQL Server).

Observação
Para obter informações sobre ouvintes de grupo de disponibilidade e mais informações sobre roteamento somente leitura, consulte Ouvintes de grupo de disponibilidade, conectividade de cliente e failover de aplicativo (SQL Server).

[Início]

Limitações e restrições

Algumas operações não têm suporte total, como segue:

• Assim que uma réplica secundária legível ingressa no grupo de disponibilidade, ela pode começar a aceitar conexões com seus bancos de dados secundários. Porém, se houver transações ativas em um banco de dados primário, as versões de linha não estarão completamente disponíveis de imediato no banco de dados secundário correspondente. As transações ativas que existiam na réplica primária quando a réplica secundária foi configurada devem ser confirmadas ou revertidas. Até que esse processo termine, o mapeamento do nível de isolamento da transação no banco de dados secundário ficará incompleto e as consultas serão bloqueadas temporariamente.

  Observação
  Executar transações longas afetará o número de linhas com versão mantidas.

• Não há suporte para o controle de alterações e a captura de dados de alterações em bancos de dados secundários que pertencem a uma réplica secundária legível:

  • O controle de alterações é desabilitado explicitamente em bancos de dados secundários.

  • A captura de dados de alterações pode ser habilitada em um banco de dados secundário, mas não há suporte para isso.

• Como as operações de leitura são mapeadas para nível de transação de isolamento de instantâneo, a limpeza de registros fantasmas na réplica primária pode ser bloqueada por transações em uma ou mais réplicas secundárias. A tarefa de limpeza de registro fantasma limpará automaticamente os registros fantasmas na réplica primária quando eles não forem mais necessários nas réplicas secundárias. Isso é similar ao que é acontece quando você executa transações na réplica primária. Em caso extremo no banco de dados secundário, você precisará eliminar consultas de leitura de longa execução que bloqueiam a limpeza fantasma. Observe que a limpeza fantasma pode ser bloqueada se a réplica secundária for desconectada ou quando a movimentação de dados for suspensa no banco de dados secundário. Este estado também impede truncamento de logs. Portanto, se este estado persistir, recomendaremos que você remova este banco de dados secundário do grupo de disponibilidade.

• A operação DBCC SHRINKFILE poderá falhar na réplica primária se o arquivo contiver registros fantasmas que ainda são necessários em uma réplica secundária.

Observação

Se você consultar a exibição de gerenciamento dinâmico sys.dm_db_index_physical_stats em uma instância de servidor que está hospedando uma réplica secundária legível, poderia encontrar um impedimento REDO. Isto ocorre porque esta exibição de gerenciamento dinâmico adquire um bloqueio de IS na tabela de usuário especificada ou exibição que pode bloquear solicitações por um thread REDO para um bloqueio de X naquela exibição ou tabela de usuário.

[Início]

Considerações sobre desempenho

Esta seção aborda várias considerações sobre desempenho de bancos de dados secundários legíveis

Nesta seção:

• Latência de dados

• Impacto da carga de trabalho somente leitura

• Indexação

• Estatísticas de bancos de dados de acesso somente leitura

Latência de dados

A implementação do acesso somente leitura a réplicas secundárias é útil se você suas cargas de trabalho somente leitura puderem tolerar certa latência de dados. Nas situações em que a latência de dados é inaceitável, considere executar cargas de trabalho somente leitura na réplica primária.

A réplica primária envia registros de log de alterações no banco de dados primário para as réplicas secundárias. Em cada banco de dados secundário, um thread de restauração dedicado aplica os registros de log. Em um banco de dados secundário de acesso de leitura, uma determinada alteração de dados não aparece nos resultados da consulta até que o registro de log que contém a alteração seja aplicado ao banco de dados secundário e a transação seja confirmada no banco de dados primário.

Isso significa que há alguma latência, normalmente apenas uma questão de segundos, entre as réplicas primárias e secundárias. No entanto, em casos incomuns, como quando problemas de rede reduzem a taxa de transferência, a latência pode se tornar significativa. A latência aumenta quando ocorrem afunilamentos de E/S e quando a movimentação de dados é suspensa. Para monitorar a movimentação de dados suspensa, você pode usar o Painel AlwaysOn ou a exibição de gerenciamento dinâmico sys.dm_hadr_database_replica_states.

Impacto da carga de trabalho somente leitura

Ao configurar uma réplica secundária para acesso somente leitura, suas cargas de trabalho somente leitura nos bancos de dados secundários consomem recursos do sistema, como CPU e E/S de threads de restauração, especialmente se as cargas de trabalho somente leitura consumirem muitos recursos de E/S.

Além disso, as cargas de trabalho somente leitura nas réplicas secundárias podem bloquear alterações de DDL (linguagem de definição de dados) aplicadas por meio de registros de log. Mesmo que as operações de leitura não usem bloqueios compartilhados devido ao controle de versão de linha, essas operações usam bloqueios de estabilidade de esquema (Sch-S), o que pode bloquear operações de refazer que estejam aplicando alterações DDL.

Fique atento às práticas recomendadas referentes à criação de consultas e use-as nos bancos de dados secundários. Por exemplo, agende consultas de longa execução, como agregações de dados durante horários de baixa atividade.

Observação
Se um thread de restauração for bloqueado por consultas em uma réplica secundária, o XEvent sqlserver.lock_redo_blocked será gerado.

Indexação

Para otimizar cargas de trabalho somente leitura nas réplicas secundárias legíveis, talvez você queira criar índices nas tabelas nos bancos de dados secundários. Como você não pode fazer alterações de esquema ou de dados nos bancos de dados secundários, crie índices nos bancos de dados primários e permita que as alterações sejam transferidas para o banco de dados secundário por meio do processo de refazer.

Para monitorar a atividade de uso de índice em uma réplica secundária, consulte as colunas user_seeks, user_scans euser_lookups da exibição de gerenciamento dinâmico sys.dm_db_index_usage_stats.

Estatísticas de bancos de dados de acesso somente leitura

As estatísticas em colunas de tabelas e exibições indexadas são usadas para otimizar os planos da consulta. Para grupos de disponibilidade, as estatísticas que são criadas e mantidas nos bancos de dados primários são automaticamente persistidas nos bancos de dados secundários como parte da aplicação dos registros dos logs de transação. No entanto, a carga de trabalho somente leitura nos bancos de dados secundários talvez precise de estatísticas diferentes daquelas criadas nos bancos de dados primários. No entanto, como os bancos de dados secundários são restritos ao acesso somente leitura, não é possível criar estatísticas nos bancos de dados secundários.

Para resolver esse problema, a réplica secundária cria e mantém estatísticas temporárias para bancos de dados secundários em tempdb. O sufixo _readonly_database_statistic é anexado ao nome das estatísticas temporárias para diferenciá-las das permanentes que persistem do banco de dados primário.

Somente o SQL Server pode criar e atualizar estatísticas temporárias. No entanto, você pode excluir estatísticas temporárias e monitorar suas propriedades usando as mesmas ferramentas que você utiliza para estatísticas permanentes:

• Exclua estatísticas temporárias usando a instrução Transact-SQL DROP STATISTICS.

• Monitore as estatísticas usando as exibições de catálogo sys.stats e sys.stats_columns. sys_stats inclui uma coluna, is_temporary, para indicar quais estatísticas são permanentes e quais são temporárias.

Para obter mais informações sobre estatísticas do SQL Server, consulte Estatísticas.

Nesta seção:

• Estatísticas permanentes obsoletas em bancos de dados secundários

• Limitações e restrições

Estatísticas permanentes obsoletas em bancos de dados secundários

O SQL Server detecta quando as estatísticas permanentes em um banco de dados secundário estão obsoletas. Mas alterações não podem ser feitas nas estatísticas permanentes, exceto por alterações no banco de dados primário. Para a otimização das consultas, o SQL Server cria estatísticas temporárias no banco de dados secundário e usa essas estatísticas em vez das estatísticas permanentes obsoletas.

Quando as estatísticas permanentes são atualizadas no banco de dados primário, elas persistem automaticamente no banco de dados secundário. Em seguida, o SQL Server usa as estatísticas permanentes atualizadas, que são mais atuais que as estatísticas temporárias.

Se o grupo de disponibilidade passar por failover, as estatísticas temporárias serão excluídas em todas as réplicas secundárias.

Limitações e restrições

• Como as estatísticas temporárias são armazenadas em tempdb, uma reinicialização do serviço SQL Server faz com que todas as estatísticas temporárias desapareçam.

• O sufixo _readonly_database_statistic fica reservado para estatísticas geradas pelo SQL Server. Você não pode usar esse sufixo na criação de estatísticas em um banco de dados primário. Para obter mais informações, consulte Estatísticas.

[Início]

Considerações sobre o planejamento de capacidade

• As réplicas secundárias legíveis pode exigir espaço no tempdb por duas razões:

  • O nível de isolamento do instantâneo copia as versões de linha no tempdb.

  • As estatísticas temporárias para bancos de dados secundários são criadas e mantidas no tempdb. As estatísticas temporárias podem causar um leve aumento no tamanho do tempdb. Para obter informações, consulte Estatísticas para bancos de dados somente leitura, posteriormente nesta seção.

• Quando você configura o acesso de leitura para uma ou mais réplicas secundárias, os bancos de dados primários adicionam 14 bytes de sobrecarga nas linhas de dados excluídas, modificadas ou inseridas para armazenar ponteiros para versões de linha nos bancos de dados secundários. Essa sobrecarga de 14 bytes transferida aos bancos de dados secundários. Como a sobrecarga de 14 bytes é adicionada a linhas de dados, podem ocorrer divisões de página.

  Os dados de versão de linha não são gerados pelos bancos de dados primários. Em vez disso, os bancos de dados secundários geram as versões de linha. No entanto, o controle de versão de linha aumenta o armazenamento de dados nos bancos de dados primários e secundários.

  A adição dos dados de versão de linha depende do isolamento de instantâneo ou da configuração de nível de isolamento do instantâneo (RCSI) confirmada por leitura no banco de dados primário. A tabela abaixo descreve o comportamento do controle de versão em um banco de dados secundário legível em configurações diferentes.

  Réplica secundária legível?	O isolamento do instantâneo ou nível RCSI está habilitado?	Banco de dados primário	Banco de dados secundário
  Não	Não	Nenhuma versão de linha ou sobrecarga de 14 bytes	Nenhuma versão de linha ou sobrecarga de 14 bytes
  Não	Sim	Versões de linha e sobrecarga de 14 bytes	Nenhuma versão de linha, mas sobrecarga de 14 bytes
  Sim	Não	Nenhuma versão de linha, mas sobrecarga de 14 bytes	Versões de linha e sobrecarga de 14 bytes
  Sim	Sim	Versões de linha e sobrecarga de 14 bytes	Versões de linha e sobrecarga de 14 bytes

[Início]

Tarefas relacionadas

• Configurar o acesso somente leitura em uma réplica de disponibilidade (SQL Server)

• Configurar o roteamento somente leitura para um grupo de disponibilidade (SQL Server)

• Criar ou configurar um ouvinte de grupo de disponibilidade (SQL Server)

• Monitorar grupos de disponibilidade (Transact-SQL)

• Exibir as propriedades da réplica de disponibilidade (SQL Server)

• Usar a caixa de diálogo Novo Grupo de Disponibilidade (SQL Server Management Studio)

[Início]

Conteúdo relacionado

• Blog da equipe do AlwaysOn do SQL Server: o blog oficial da equipe do AlwaysOn do SQL Server

[Início]

Consulte também

Conceitos

Visão geral de grupos de disponibilidade AlwaysOn (SQL Server)

Sobre Acesso de conexão de cliente a réplicas de disponibilidade (SQL Server)

Ouvintes de grupo de disponibilidade, conectividade de cliente e failover de aplicativo (SQL Server)

Estatísticas