A execução de uma consulta grande em um banco de dados secundário em um grupo de disponibilidade afetará o desempenho da transação no banco de dados primário?

Preciso fornecer dados em tempo real ou quase em tempo real para os relatórios do SSRS e do Tableau. Não quero que o sistema OLTP de produção seja impactado negativamente por consultas de longa execução. A execução de uma consulta grande em um banco de dados secundário em um grupo de disponibilidade afetará o desempenho da transação no banco de dados primário?

A execução de uma consulta grande em um banco de dados secundário em um grupo de disponibilidade afetará o desempenho da transação no banco de dados primário?

Depende do modo de sincronização usado ao configurar o grupo de disponibilidade - Sincronização ou Async!

Na réplica secundária , todas as transações usam SOMENTE o nível de isolamento de captura instantânea e todas as dicas de bloqueio também são ignoradas. É por isso que é importante testar sua carga de trabalho ao adotar o AlwaysON.

De: minimizando o bloqueio do encadeamento REDO ao executar a carga de trabalho de relatório na réplica secundária

Embora o mapeamento da carga de trabalho de relatório para o isolamento de captura instantânea elimine o bloqueio entre a carga de trabalho DML conforme aplicada pelo encadeamento REDO na réplica secundária e a carga de trabalho de leitura ou relatório, ela não elimina o possível bloqueio do encadeamento REDO ao executar uma operação DDL .

Se estiver usando

• Modo síncrono

  • O problema de bloqueio na sua réplica secundária afetará o desempenho de suas consultas na réplica primária. Portanto, uma carga de trabalho de leitura (seleção) executada no secundário pode impedir que o thread refazer aplique as alterações provenientes da réplica primária. Isso significa que a réplica primária precisa aguardar que as alterações sejam aplicadas a todas as réplicas SYNC secundárias antes de se confirmar localmente e pode terminar em tempos limite ou em bloqueio ou deadlock.

    O encadeamento REDO pode ser visto no Secundário legível como o DB STARTUP comando no sys.dm_exec_requests. Se esse encadeamento estiver sendo bloqueado, sua carga de trabalho de leitura no secundário poderá estar causando um impacto no primário.

    Para obter mais detalhes, verifique - Cenário 1: REDO bloqueado devido a uma grande consulta na réplica secundária

• Modo assíncrono

  • O primário não espera pelo reconhecimento do secundário. Um problema de bloqueio no secundário é apenas isolado para o secundário, em que a fila de refazer aumentará no secundário até que os bloqueios sejam limpos e o encadeamento refazer seja capaz de aplicar os blocos de log. Isso não afetará a réplica primária.

Sua definição de "em tempo real ou quase em tempo real" precisa de mais consideração, tendo em mente o método de sincronização usado, a latência da rede e o quão ocupado é a réplica primária e a atividade de log que precisa ser transportada secundária.

O SQL Server 2016 fez alguns aprimoramentos importantes no domínio AlwaysON, por exemplo

• Algoritmos de compactação aprimorados e compactação paralela de dados de bloco de log
• Melhoria de 4x a 5x na taxa de transferência de transporte de bloco de log
• e muitos outros - é apenas mais rápido !