Início / dba / Perguntas / 140863
Accepted
Tarzan
Asked: 2016-06-10 08:07:59 +0800 CST

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?

  • 772

Preciso fornecer dados em tempo real, ou quase em tempo real, para relatórios do SSRS e do Tableau. Não quero que o sistema OLTP de produção seja afetado negativamente por consultas de execução longa. 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?

sql-server sql-server-2014

1 respostas

  1. Best Answer

    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 que você usou ao configurar o grupo de disponibilidade - sincronizado ou assíncrono!

    Na réplica secundária , todas as transações usam APENAS o nível de isolamento de instantâneo 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 de thread REDO ao executar relatórios de carga de trabalho na réplica secundária

    Embora mapear a carga de trabalho de relatório para o isolamento de instantâneo 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, ele 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 em 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 encadeamento de redo 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 confirmar localmente e pode acabar em tempos limite, bloqueio ou impasse.

        O thread REDO pode ser visto no secundário legível como o DB STARTUPcomando em sys.dm_exec_requests. Se esse thread estiver sendo bloqueado, sua carga de trabalho de leitura no secundário pode 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 pela confirmação do secundário. Um problema de bloqueio no secundário é apenas isolado para o secundário, em que a fila de refazer crescerá no secundário até que os bloqueios sejam limpos e o encadeamento de redo seja capaz de aplicar os blocos de log. Isso não afetará a réplica primária.

    Sua definição de "tempo real ou quase em tempo real" precisa de mais atenção, tendo em mente o método de sincronização usado, a latência da rede e quão ocupada está 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

    • 13

relate perguntas